# Passwordless device auth **No password, no shared secret, no fleet-wide certificate: the device's DNS name and its DANE-TLSA record become its TLS client credential, and the device proves itself by signing with a key that never leaves the chip. This is the IETF DANCE model, and Whisper's identity plane is that model deployed.** This page is the cure for the device secret: the thing manufacturing flashes because provisioning has to finish, the thing one flash dump turns into a fleet-wide credential, the thing you cannot rotate once it's soldered into the field. The cure is not a better place to hide the secret. It is removing the secret from the firmware image entirely, so there is nothing in the dump worth stealing. > Two tiers, per Postel's Law. **With no API key**, any party can verify a device's published TLSA pin and DNSSEC chain from stock tools, which is the whole point of putting the credential in public DNS. **With your key**, you provision the identities and govern their egress. Verification never needs an account. ## The device secret, and why it can't be saved Every generation of device credential so far has been an *artifact*: bytes that exist outside the silicon and therefore travel. | Generation | The credential | How it dies | |---|---|---| | 0 · default password | the same string in every unit | Mirai recruited 600k devices with a short list of these; ETSI EN 303 645 and the UK PSTI Act now ban them outright | | 1 · shared secret in firmware | an API key or line-wide cert + private key in flash | one dump (UART, JTAG/SWD, desoldered SPI) forges the fleet; rotation means a recall-grade OTA campaign | | 2 · per-device X.509 into a cloud | a unique cert whose CA is the vendor console | verifiable only in-tenant; revocation rides CRL/OCSP verifiers soft-fail past; the scheme's lifetime is the console's (see IoT Core, Aug 2023) | The constant flaw: the verifier trusts the artifact, never the silicon. The fix has two halves: put the private key where it physically cannot be copied (the secure element your BOM already carries), and put the *public* credential where anyone can check it without asking a vendor (the DNS, signed to the root). ## DANCE: the credential moves into the DNS The IETF's **DANCE** working group (DANE Authentication for Network Clients Everywhere) exists to do for TLS *clients* what DANE (RFC 6698) did for servers: publish the party's key in a DNSSEC-signed `TLSA` record, so the peer verifies the presented certificate against the DNS instead of against a private CA list or a password table. *draft-ietf-dance-client-auth* defines the client half, and its motivating use cases are exactly this page's: IoT devices, MQTT clients, machine-to-machine auth at fleet scale. Under that model, a device's identity is its DNS name; its credential is the `TLSA` record pinning its key; and the trust anchor is the DNSSEC root, not any vendor. Whisper's identity plane is this architecture, live on real address space: every provisioned device identity gets a name, a forward-confirmed `PTR`, and a **DANE-EE `TLSA 3 1 1`** record pinning the device's own leaf key, all DNSSEC-signed to the IANA root, published today. ```sh # the device's client credential, in public DNS, signed to the root: dig +short TLSA _443._tcp.04d0c85f3a1b77e2..agents.whisper.online 3 1 1 b653a4ef…fcb82d1d # DANE-EE: the SHA-256 of the device key's SPKI # what a peer checks: the presented leaf's SPKI hash equals the DNSSEC-signed pin whisper verify --trustless 04d0c85f3a1b77e2..agents.whisper.online dane pass DNSSEC-root served leaf SPKI-SHA256 == TLSA pin ``` ## How the handshake works, with no secret in firmware The private key lives in the secure element and signs the TLS handshake in place; the firmware image carries only public material. A peer authenticates the device in four moves: 1. **The device connects** (TLS, or mTLS toward an MQTT broker / device API) and presents its leaf certificate: the one whose key is sealed in the chip. 2. **The device signs** the handshake with that key on-chip. This is the step no flash dump can reproduce: the dump never contained the key. 3. **The peer resolves the device's name** (or reverse-resolves its source `/128`) and fetches its `TLSA 3 1 1` record, DNSSEC-validated to the IANA root. 4. **The peer compares**: presented-leaf SPKI hash == the pinned hash. Match ⇒ this session is cryptographically that device. Mismatch, or no record ⇒ no authority, before any application logic runs. Note what fell away: no password table on the broker, no CA bundle pushed to every unit, no vendor console in the verification path, and nothing secret in the firmware image at all. ## Revocation: TTL beats CRL Where the credential lives determines how it dies. A CRL or OCSP responder is a second, out-of-band system that verifiers famously soft-fail past; a cloud registry flag reaches only that cloud's own checks. A DNS-published credential dies *in the same channel it lived in*: one owner-thrown `revoke` tears down the `AAAA`, the `PTR` and the `TLSA` pin, and every verifier on the internet sees it inside the record's TTL, because the *absence* is DNSSEC-proven too (authenticated denial of existence; see [DNSSEC](/docs/dnssec)). ``` CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2'}}) # within the TTL, everywhere on earth: dig +short TLSA _443._tcp.04d0c85f3a1b77e2..agents.whisper.online # -> nothing (signed denial) ``` ## The lineage: CGA, completed None of this is a novel trust model; it is an old, good one finally made operational. **CGA** (Cryptographically Generated Addresses, RFC 3972, 2005) bound an IPv6 address to a public key by construction: address = one-way function of the key, no certificate authority anywhere. What CGA lacked was everything around it: the addresses weren't allocated from routable space, there was no registry to look one up in, and there was no revocation story. Whisper keeps the derivation idea and supplies the missing operational three: **routability** (real announced space, `2a04:2a01::/32` on AS219419), **registration** (an RDAP object per `/128`), and **revocation** (the DNS-TTL teardown above). And where CGA verification needed the verifier to run CGA, Whisper's verification is stock `dig` and `curl`. ## The MQTT/broker pattern (and its honest status) The natural first application is the fleet's own broker: replace the password file / static-credential list with a DANE check on the client certificate. > **Shipped vs roadmap, precisely.** The *records the broker would check* (per-device TLSA, DNSSEC chain, keyless verify endpoints) are **shipped and live** for every provisioned identity. The *packaged broker-side recipe* (a Mosquitto/EMQX plugin configuration that performs the DANE check) and the *device-side C SDK* are **roadmap**, phase-2 deliverables, each to be proven end-to-end before it is documented as installable. Until then, a backend can already implement the check directly: resolve the TLSA, compare the SPKI hash, four lines in any language with a DNS and a crypto library. ``` # what the broker-side check does, spelled out (implementable today in any backend): pin = dnssec_resolve_tlsa("_443._tcp." + client_name) # 3 1 1 leaf = tls_session.peer_leaf_certificate() ok = sha256(leaf.spki_der) == pin.hash # match ⇒ that device, provably ``` ## What this removes from your threat model - **Firmware-dump credential theft**: the image holds no secret; the key never leaves the chip. - **Default and shared passwords**: gone entirely, which is also the EN 303 645 / PSTI requirement, met structurally rather than procedurally. - **Fleet-wide blast radius**: one leaf per device; a compromise is one `revoke`, not a line-wide rotation. - **Vendor-console dependency**: the credential and its revocation live in public DNS, which does not get retired with a product line. - **CRL/OCSP soft-fail**: absence of the pin is a signed, provable fact, not a fetch that might time out. ## Next - [Device & IDevID identity](/docs/industries/embed/device-identity): the derivation that mints the identity this page authenticates with - [DANE & TLSA](/docs/dane): the `3 1 1` record, byte for byte - [Embedded recipes](/docs/industries/embed/embedded-recipes): the runnable recipes, each labelled shipped-vs-roadmap