Embedded

A secret extracted from one flash dump shouldn't be able to speak for every device you ship, and a fleet's identity shouldn't die with a vendor console.

A device backend authenticates a claim: a password, an API key, a certificate chain. It never authenticates the silicon on the other end. Whisper closes that gap with one primitive: the device's address is its identity. This page is the embedded front door to the Whisper docs. The full technical library (DNSSEC, DANE, RDAP, the control-plane API) sits one click down the sidebar, shared verbatim with whisper.online.

The problem: copyable credentials, and the console behind them

Embedded fleets authenticate with what manufacturing could afford. Generation zero was the default password, and Mirai showed at 600k-device scale what that costs; ETSI EN 303 645 and the UK PSTI Act have since outlawed it. Generation one is the shared secret in firmware: an API key or a line-wide certificate, where one flash dump (UART, JTAG/SWD, or a desoldered SPI part) yields a genuine credential for the whole product line. Generation two is per-device X.509 into a cloud provisioning service: genuinely better, and still verifiable only inside that tenant, revoked through CRL/OCSP machinery verifiers soft-fail past, and anchored to a console whose lifetime is shorter than the hardware's; when Google Cloud IoT Core retired in August 2023, console-anchored fleets had to re-home their identity mid-life. The root cause is constant across all three: OWASP broken authentication / BOLA. The credential authenticates a claim, never the device.

Detection will always be a step behind a credential that is genuinely valid: the extracted copy is byte-identical to the original. The strictly-stronger move is to change what the backend trusts.

The cure: the address is the device

Whisper gives each device a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), derived deterministically from the device's public key: its SubjectPublicKeyInfo, from the IEEE 802.1AR IDevID key in its secure element (a Microchip ATECC608, an NXP EdgeLock SE050, an Infineon OPTIGA Trust M) or on-chip OTP/PUF storage, with the device serial or EUI-64 as the domain separator. The private key never leaves the chip; only its public SPKI is an input. The result is DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered. Anyone with dig can verify it, and the device proves control by signing with the key, the one operation a flash dump can never counterfeit.

device public key (SPKI)      ──derive · domain-sep = serial──▶   /128                  ──DNSSEC + DANE-EE 3 1 1──▶   a name anyone verifies
the 802.1AR IDevID key in                                        2a04:2a01:1c0::e51d          RDAP-registered           whisper verify --trustless
the secure element / OTP                                         routable, tenant-bound                                 op:'revoke' → owner-thrown, public
(private key stays on-chip)

Because the derivation is tenant-bound, the same key under two different fleets yields two unrelated /128s: an outsider cannot link a device across fleets. And because the domain separator is the serial, a serial alone yields nothing. You cannot go serial → /128 without the key, there is no enumerable directory, and RDAP and reverse-DNS return the registry object, never the device's location.

What becomes true the moment a device holds one:

• "One dump → a whole fleet" becomes physically impossible. You cannot present device-identities whose keys you don't hold; every forgery is a DNSSEC/DANE inconsistency any verifier catches.
• IP rotation becomes irrelevant. Identity is not the source IP. The "last IP" was never the credential.
• Extracted firmware fails. A byte-perfect copy of the flash, minus the secure element, authenticates to nothing.
• One revoke, thrown by the owner, retires a device's identity worldwide at DNS-TTL speed: no CRL you hope every verifier fetched, and the act is publicly checkable in DNS.

Additive, never a replacement. Whisper complements the anchors embedded engineering already ships: the 802.1AR IDevID, BRSKI (RFC 8995) onboarding, Matter's DAC where you run it, secure boot, and the X.509 mTLS the device cloud already speaks. It is the publicly verifiable, DNSSEC/DANE-anchored layer on top, anchoring the device↔cloud boundary. And the standards story runs deeper: the IETF DANCE work (draft-ietf-dance-client-auth) makes a device's DNS name + DANE-TLSA record its TLS client credential, exactly the model Whisper's identity plane deploys; the lineage before that is CGA (RFC 3972), the 2005 proof that an address can be a one-way function of a key. See Passwordless device auth for the whole story.

Provision a device identity

Provisioning is one control-plane call over the public API: POST https://graph.whisper.security/api/query with your X-API-Key. Hand it the device's base64 SPKI; optionally bind a device identifier as the domain separator. Today that identifier rides the live device_id argument, which is held to a 17-character canonical form (the same shipped derivation the automotive vertical uses, in the VIN alphabet: A-H J-N P R-Z 0-9), plus an optional free-form ecu_serial component separator; a variable-length device-native serial/EUI-64 argument is on the roadmap and labelled as such below.

CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the device key>',
  device_id:'GW00427A310B55EF2'   // optional: a 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

Send it with your key. The heredoc keeps the single-quoted Cypher literals intact, so this runs as-is:

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

# response
{ "op": "connect", "ok": true, "status": "created",
  "result": {
    "address": "2a04:2a01:1c0::e51d",
    "fqdn":    "sn-gw00427a310b55ef2.fleet.<tenant>.agents.whisper.online",
    "wireguard": { /* peer, keys, allowed-ips */ }
  } }

The call is idempotent and liberal in what it accepts, strict in what it returns: re-running with the same key and identifier returns the same /128; a different identifier for a key already registered on your tenant is a clear 409, not a silent overwrite; a non-string identifier is a 400 that tells you exactly what was wrong, never an opaque 500.

Verify it yourself: no account needed

Every device identity is checkable with no key and no login, from the internet's own records, by any client with a TLS stack. That includes your customer, your partner's backend, and a researcher. The whisper CLI does the full walk in one call:

whisper verify --trustless sn-gw00427a310b55ef2.fleet.<tenant>.agents.whisper.online

✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) leaf matches the identity's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED (our own API was never trusted)

Or reach for the raw records directly: the same answer, from stock tools:

# the public verify endpoint: evidence chain in JSON
curl -s https://whisper.online/verify-identity/2a04:2a01:1c0::e51d | jq
{ "is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { /* … */ } }

# the address is the device: forward-confirmed reverse DNS names it
dig -x 2a04:2a01:1c0::e51d +short
sn-gw00427a310b55ef2.fleet.<tenant>.agents.whisper.online.

# the registry object: who holds the address, and under which allocation
curl -s https://whisper.online/ip/2a04:2a01:1c0::e51d | jq

None of these calls Whisper as an authority: --trustless re-derives the proof against the public DNSSEC root, exactly as any resolver could. See Verify an agent for the full keyless check and DANE & TLSA for the pin, byte for byte.

Revoke, worldwide, owner-thrown

A compromised unit, an RMA, a resale, a decommission. One call tears down the /128, its PTR, and its DANE pin everywhere at DNS-TTL speed, and the act is publicly checkable: the same dig that proved the identity existed proves it is gone.

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:1c0::e51d'}})

# after the TTL: dig -x returns nothing, verify returns false
whisper kill --revoke 2a04:2a01:1c0::e51d

Contrast the alternative: rotating a leaked shared credential across a fielded fleet is a recall-grade OTA campaign, and a cloud registry flag reaches only the verifiers inside that cloud. Whisper's revoke reaches every verifier on the internet at once, and the blast radius is one leaf key, never a shared root.

Attribution: name whoever is wearing your devices' faces

Identity stops the next impostor; the graph names the operator behind the credentials already in your logs. That attribution survives IP rotation because it fingerprints the operator and the tooling, not the ephemeral egress IP. Run it as read-only Cypher over the same public API with your key (there is no CLI subcommand for this; it is the graph API directly):

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H 'content-type: application/json' \
  -d '{"query":"CALL whisper.identify(\"34.90.x.x\")"}'
# operator fingerprinted across AWS / GCP / Azure; residential swarm collapsed by JA4

The read-only verbs (identify, origins, walk, variants, history) each return a reproducible, replayable JSON evidence chain your SOC, PSIRT, and a regulator can replay. More in Graph & cognition.

What ships today, and what's on the roadmap

We label these honestly so you can plan against them. The keyless verify surface works from any device with a TLS + HTTPS stack today; the control plane and routed /128 run today on Linux-class devices and gateways; the MCU-native SDKs are phase-2 roadmap items.

The integration guides below describe proposed integrations at the cloud and IP boundary. They're designed to complement the stack you already run, not endorsed by any vendor, and they never present an unshipped SDK as installable.

The five Embedded guides

The embedded story, in depth: each page is self-contained and honest about shipped-vs-roadmap on every step.

The full technical library

Embedded rides on the same address-is-identity platform as every other agent on the network, so the whole shared library applies here unchanged, and every page has a clean Markdown twin at the same path + .md. Start with these; the rest is in the sidebar.