Device & IDevID identity

Give a device a routable IPv6 /128 derived from the IEEE 802.1AR IDevID key it already holds and its serial. The address is the device: forge-proof, tenant-private, DNSSEC-anchored, and revocable by the owner in one publicly verifiable call.

This is the spine of the embedded vertical, and it is shipped and live. Everything else (the passwordless-auth story, the platform integrations, the compliance evidence) builds on the one idea below: a device's network address stops being a disposable label a proxy can rotate and becomes a cryptographic fact only that device's silicon can stand behind.

The address is the device

Almost every device backend authenticates a claim, never a device. A bearer token, a static API-key header, a certificate chain: each says "the holder of this artifact may act," and an artifact travels. It can be dumped over UART or JTAG, lifted from a firmware image, and presented from any IP on earth. That is the root cause behind the whole family of device-fleet abuses: fleet-scale impersonation, poisoned telemetry, broken object-level authorization (BOLA), one operator quietly wearing thousands of copied faces from a residential-proxy swarm. The API is used exactly as designed; the last IP your SOC records means nothing, because the caller was never the device.

Whisper closes the gap by making the network address itself the credential. A device gets a real, routable /128 out of 2a04:2a01::/32 (announced by AS219419) that is a deterministic function of the hardware key the device was born with and its serial. Because the address is derived from a key only that device holds, you cannot present a device identity whose key you don't have. One dump mapping to a whole fleet becomes physically impossible; a copied credential off the wrong silicon is inert; and every forgery is a DNSSEC/DANE inconsistency any verifier catches for free.

The key already has a name in your architecture documents: the 802.1AR IDevID, the initial device identifier your secure element (a Microchip ATECC608, an NXP EdgeLock SE050, an Infineon OPTIGA Trust M) or on-chip OTP/PUF storage was put on the board to hold. BRSKI (RFC 8995) bootstraps that IDevID into an owner relationship; Whisper projects the same key onto the public namespace, where anyone can check it.

How the derivation works

The /128 is not assigned from a pool and written into a database. It is computed, the same way on every node, from inputs the device already has:

Those inputs are combined by a one-way derivation (with a Whisper-held secret mixed in) into a stable, unguessable interface identifier scoped to your fleet:

# inputs -> a stable, forge-proof interface identifier
derive( device public key,  device_id [, component serial],  your fleet )  -->  64 uniform bits

# the /64 prefix is your tenant block; the low 64 bits are the derived id
/128 = < your tenant /64 prefix > : < derived interface id >

Four properties fall straight out of that derivation, and each one is load-bearing:

• Deterministic. The same (key, id) yields a byte-identical /128 every time, on every server: exactly one candidate, never a random retry. A reconnecting device re-derives its own address; both of our authoritative nodes mint the identical identity with zero replication between them.
• Forge-proof. The address is a function of a key only the device holds. An attacker with a serial and even the device's public key still cannot become that device: the server-side secret and the DANE pin (below) are the parts they can never produce, and the device's proof is a signature only the chip can make.
• Tenant-bound & fleet-unlinkable. Your tenant's own /64 is folded into the derivation. The same key+id under a different tenant produces a different address, so an outsider cannot derive or enumerate a device's address in a fleet they don't control, and the classic serial-enumeration walk is a dead end.
• Liberal in, strict out. The identifier is accepted generously, whitespace stripped and case-folded, then held to its canonical form. A malformed identifier fails closed with a clear message, never a silent wrong address.

The moment the address is derived it is published as a full identity, atomically: an AAAA, a forward-confirmed PTR, and a DANE-EE TLSA 3 1 1 record that pins the device's leaf key directly. All of it is DNSSEC-signed to the IANA root and registered in RDAP. That TLSA pin is what turns "the address is derived from a key" into "the address is provable against that key by anyone." See DANE & TLSA for the byte-for-byte record and DNSSEC for the chain it hangs from.

Provision a device identity

Provisioning is one control-plane call: whisper.agents with op:'connect', tier:'wireguard', the device's public SPKI, and optionally the device identifier. It returns the deterministic /128 and a ready WireGuard configuration so the device's traffic sources from its own identity. The endpoint is POST https://graph.whisper.security/api/query, authed with an X-API-Key header. No key ever travels in the body.

CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SubjectPublicKeyInfo of the device key>',
  device_id:           'GW00427A310B55EF2'   // optional: the 17-character device identifier rides here today
  // ecu_serial: 'MOD-7F31'   // optional: a distinct /128 per sub-module
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error

With stock tools: just curl, no Whisper software. A quoted heredoc keeps the Cypher single-quotes intact so it pastes and runs as-is:

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d @- <<'JSON' | jq .
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...<SPKI>...', device_id:'GW00427A310B55EF2'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON

The response is the standard envelope; result carries the derived address and the transport. Because the device holds its own key, no private key is ever returned. Only the public identity and the config that binds egress to it:

{
  "op": "connect", "ok": true, "status": 200,
  "result": {
    "tier":               "wireguard",
    "address":            "2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2",   // the deterministic /128
    "fqdn":               "04d0c85f3a1b77e2.<tenant>.agents.whisper.online",
    "server_public_key":  "…",
    "endpoint":           "…:51820",
    "dns":                "2a04:2a01:0:53::53",
    "wireguard_config":   "[Interface] …"
  },
  "error": null
}

On an embedded-Linux device or gateway, drop the returned wireguard_config in place (or feed it to wireproxy for a no-root, userspace tunnel) and every packet it sends now sources from its own /128. The backend authorizes on that address (a forge-proof, attributable, revocable network identity) instead of an artifact anyone could carry. For the full transport mechanics and the SOCKS5 alternatives, see Connect & egress; for every other op on this same endpoint, the Control plane reference.

Idempotent, with honest errors

Because the address is derived, provisioning is naturally idempotent, and the failure modes are clear rather than surprising, Postel all the way down:

Verify: keyless, no account

The identity half is public on purpose: anyone (a backend allowlisting sanctioned endpoints, an auditor, a distributor, the customer who owns the device) can prove a device's /128 without a Whisper account and without trusting Whisper's word. Four independent checks, and the first three need nothing but a TLS-capable HTTP client, which is exactly what makes them reachable from most embedded systems today:

# 1. Forward-confirmed reverse DNS: the address names the device, the name resolves back
dig -x 2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 +short
04d0c85f3a1b77e2.<tenant>.agents.whisper.online.

# 2. The keyless verdict endpoint (takes an address or an FQDN; ?ip=<target> also accepted)
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 | jq .
{
  "is_whisper_agent": true,
  "dane_ok": true,
  "jws_ok": true,
  "evidence": { "aaaa": "...", "ptr": "...", "tlsa": "3 1 1 b653a4ef…fcb82d1d" }
}

# 3. The registry record: RDAP, IP-anchored to the /128
curl -s https://whisper.online/ip/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 | jq '.handle, .parentHandle'

# 4. The full chain re-derived on YOUR machine, against the IANA root: Whisper NOT in the trust path
whisper verify --trustless 04d0c85f3a1b77e2.<tenant>.agents.whisper.online

A target that isn't a Whisper identity gets a clean 200 {"is_whisper_agent": false}. A negative verdict is a successful answer, not an error; only genuinely malformed input draws a 400, never a 500. --trustless is the strong form: it validates DNSSEC from the root in-process, on your resolver, so the proof holds even for a party that won't take Whisper's word for anything. The full seven-proof walk lives in Verify an agent.

Revoke: worldwide, owner-thrown, in one call

A compromised, RMA'd, resold or decommissioned device is one revoke away from having no network identity anywhere. The call tears down the /128, its PTR, and its DANE pin across both authoritative servers, and the change propagates at DNS-TTL speed:

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2'}})

# prove it, zero Whisper software, the same stock tools that proved it existed:
dig -x 2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 +short           # -> nothing
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2
# -> {"is_whisper_agent": false, ...}

Revocation isn't a database flag you have to trust; it's provable the same way the identity was: the reverse lookup goes empty and the keyless verdict flips to false for everyone, everywhere, at once. Compare the alternatives an embedded fleet actually has: a CRL that most verifiers soft-fail past, or a shared-secret rotation that means a recall-grade OTA campaign. On resale or RMA, one revoke plus a re-register under the new owner moves the trust relationship with the title.

Where this fits (and where it doesn't)

Whisper anchors the device's identity at the device↔cloud IP boundary: the network endpoint your backend authorizes. It is additive: it complements the roots of trust you already run and does not try to replace them, and it deliberately stops at the die.

• Secure element / TPM / OTP. The device's birth key is the input to the derivation. Whisper adds a routable, DNSSEC/DANE-provable name on top of the silicon root of trust. It complements that root; it does not replace it.
• 802.1AR / BRSKI. The IDevID stays the initial device identifier; BRSKI (RFC 8995) stays the onboarding ceremony where you run it. The derived /128 is the same identity's public, internet-facing counterpart, verifiable by parties who were never part of the enrollment.
• Cloud DPS / device clouds. There the cloud is the CA and mutual TLS rides X.509. Whisper adds an out-of-tenancy identity the backend can allowlist and any third party, a partner, an auditor, a customer, can verify against DANE without cross-signing. It complements the vendor CA; it does not replace it.
• Where Whisper does not go. Not into secure boot, not into the RTOS, not into a radio protocol's own security layer (Matter fabric credentials, LoRaWAN OTAA, Thread). Whisper is the network identity of the endpoint on the IP fabric: the doorway, not the die.

For mapping these identities to EU CRA, IEC 62443, EN 303 645 and 802.1AR evidence and SOC export, see Embedded compliance. The Splunk, Microsoft Sentinel and OpenCTI connectors are shipped; STIX/TAXII export is on the roadmap and labelled as such there. No specific vendor or platform is named, endorsed, or implicated as a breach victim anywhere in these docs; the abuse patterns cited are the public, cross-industry ones.

Next

• Passwordless device auth: this identity, applied as the DANCE-style TLS client credential it was built to be
• Platform integrations: dropping the /128 into cloud DPS, Matter, MQTT, LPWAN, and the honest capability matrix
• DANE & TLSA: the byte-for-byte record that makes the address provable against the device key