# Platform integrations **Whisper sits beside the embedded stack you already run and anchors exactly one thing: a routable, verifiable identity at the device/cloud IP boundary. That's the layer where an extracted credential today looks identical to the real device.** Everything below is written the same way: *Whisper complements the mechanism you have; it never replaces it.* We do not touch secure boot, the RTOS, or a radio protocol's own security layer (Matter fabric credentials, LoRaWAN OTAA, Thread). Whisper's job is the network identity of whatever is talking to your cloud, expressed as an IPv6 `/128` that DNSSEC, DANE and RDAP can prove and one owner-thrown call can revoke. > **One spine under everything.** Each integration reuses the same shipped primitive: a deterministic `/128` derived from a device's *public* key ([Device & IDevID identity](/docs/device-identity)), published with a DANE pin and an RDAP record, verifiable by anyone with no account. ## First, the honest capability matrix Not every microcontroller can run this, and this page will not pretend otherwise. The keyless *verification* surface needs only a TLS + HTTPS client. The *resolver* path (DoH, RFC 8484) is a small HTTP exchange whose real cost is the TLS engine: roughly **20-60KB of flash and 25-63KB of peak handshake RAM**. The *routed identity* path (WireGuard from the device's own `/128`) is an OS-integration question. | Device class | Keyless verify | DoH resolver | Routed /128 (WireGuard) | Status | |---|---|---|---|---| | **8-bit MCU** (AVR / ATmega328, Arduino Uno) | via gateway | **no: no TLS budget** | via gateway | **Gateway pattern** (below). An ATmega328 does not speak DoH; the node authenticates locally to a gateway that holds the /128. | | **ESP32 / ESP-IDF** | yes, today (esp-tls + HTTP client) | yes: Espressif's `esp_dns` component does DoH natively today | userspace ports exist; not our supported path yet | Works with vendor parts today; the packaged **Whisper ESP-IDF component is roadmap**. | | **Cortex-M4/M33 + RTOS** (Zephyr · nRF Connect SDK · STM32Cube) | yes, today (mbedTLS + an HTTP client) | yes: the TLS budget fits; the DoH client on top is small | platform-dependent | Works with vendor parts today; the packaged **Whisper Zephyr module is roadmap** (it also covers nRF Connect). Do not start a new design on Arm Mbed OS: its end of life is July 2026. | | **Embedded Linux** (Raspberry Pi · Yocto · OpenWrt · Zynq · PolarFire SoC) | yes, today | yes, today | **yes, today**: kernel WireGuard or `wireproxy` | **Shipped.** The `whisper` CLI and the control plane run as-is. | ## The gateway pattern: identity for the devices that can't hold one Below the TLS line (8-bit AVR, tiny LoRa nodes, legacy RS-485 sensors), the device cannot carry the identity, so the **gateway carries it for the segment**: an embedded-Linux (or ESP32-class) concentrator holds its own secure-element-derived `/128`, authenticates the local nodes with whatever the local bus already uses, and everything crossing the IP boundary sources from the gateway's provable identity with default-deny egress. This is shipped today, because the gateway is Linux-class: ```sh # the gateway is the identity boundary: one provable /128, default-deny egress whisper policy --agent 2a04:2a01:1c0::e51d \ --default deny --allow telemetry.example-maker.com,ota.example-maker.com # what did the segment actually reach last night? Per-identity, one keyed call: CALL whisper.agents({op:'logs', args:{agent:'', kind:'dns', from:'-24h'}}) ``` > **Complements the local bus, does not replace it.** Node↔gateway auth stays with the bus (LoRaWAN OTAA, Modbus, BLE bonding). Whisper anchors the gateway↔cloud IP boundary above it. ## Azure IoT Hub + DPS, and AWS IoT Core The pattern is **parallel identity**: the device keeps its DPS/JITP enrollment for in-tenant auth, and the same secure-element key also derives its Whisper `/128`, giving the device an identity that exists *outside* the tenant: one your partners, your customers' auditors, and your own multi-cloud backends can verify with stock tools, and one that survives any single platform's lifecycle. ```sh # the backend (or a partner's) checks the out-of-tenancy identity, keylessly: curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 {"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { … }} ``` > **Complements DPS / fleet provisioning, does not replace them.** Authorization inside the tenant (hub policies, thing shadows, IAM) stays with the cloud. Proposed pattern, not a vendor endorsement. ## Matter: DAC at commissioning, /128 for the service life Matter's Device Attestation Certificate, checked against the CSA's Distributed Compliance Ledger, answers "was this device made by whom it claims" *inside the fabric, at join time*. What Matter deliberately doesn't provide is an *operational, internet-facing* identity for the device's whole service life. That's the slot the Whisper `/128` fills, derived from the same class of secure element the DAC already lives in. > **Complements the DAC and DCL, does not replace them.** Whisper issues no Matter credentials, never touches commissioning, and doesn't join the fabric. Proposed pattern, not a CSA endorsement. ## MQTT brokers & device APIs: the DANCE check The integration is the [DANCE pattern](/docs/device-secret-cure): the client presents the cert whose key sits in its secure element, and the broker verifies the presented leaf against the device's DNSSEC-signed `TLSA 3 1 1` pin instead of a password table. ```sh # the records the broker checks are published and live today, per identity: dig +short TLSA _443._tcp.04d0c85f3a1b77e2..agents.whisper.online 3 1 1 b653a4ef…fcb82d1d ``` > **Honest status.** The per-device TLSA records and DNSSEC chain: **shipped, live**. The packaged broker-side recipe (Mosquitto/EMQX configuration) and the MQTT-DANCE end-to-end recipe: **roadmap**, each to be proven with a full end-to-end test before it is documented as installable. ## OTA infrastructure: verify the server, attribute the client **Downstream**, the device confirms it is talking to the genuine update host before it fetches an image: a DANE pin comparison any TLS-capable device can do today, alongside your existing image signing (which stays exactly where it is). **Upstream**, every fetch arrives from the device's own `/128`, so your CDN logs become a per-device record instead of a NAT blur. ```sh # on the device, before fetching: is this the genuine OTA endpoint? dig +short TLSA _443._tcp.ota..agents.whisper.online openssl s_client -connect ota..agents.whisper.online:443 /dev/null \ | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der \ | openssl dgst -sha256 # must equal the TLSA pin above ``` > **Complements image signing, does not replace it.** Signed firmware answers "is this image genuine"; the DANE check answers "is this server genuine"; the per-/128 sourcing answers "which device fetched it." ## LPWAN & cellular concentrators A LoRaWAN gateway or cellular concentrator is a small Linux computer behind a carrier NAT. LoRaWAN's OTAA keys authenticate the *sensors to the network server*; nothing authenticates the *gateway to the internet*. The integration is the shipped gateway pattern above: one `/128` per concentrator, default-deny egress, per-identity logs. ## Shipped today vs roadmap The *identity primitive* under every integration is live and provable right now; the per-platform *SDKs and packaged recipes* are phase-2 deliverables, and none will be documented as installable until it has passed a full end-to-end test (provision a real device, run it, verify the routable `/128` with `dig -x` and RDAP, prove the egress). | Building block | Status | |---|---| | Deterministic `/128` from a device's public key (+ optional `device_id` binding) | **shipped, live** | | Provision via the control plane (`op:'connect'`, WireGuard tier) | **shipped, live** | | Keyless verify (`whisper verify --trustless`, `/verify-identity`, `dig -x`, RDAP) from any TLS-capable client | **shipped, live** | | Routed /128 + default-deny egress + per-device logs on embedded Linux / gateways | **shipped, live** | | Revoke: `/128` + PTR + DANE torn down at DNS-TTL speed, owner-thrown | **shipped, live** | | Attribution graph over the public API (`CALL whisper.identify(…)`) | **shipped, live** | | Dependency-free **C SDK** (CMake core) | **roadmap** (phase 2) | | **ESP-IDF component** (wrapping `esp_dns`) | **roadmap** (phase 2) | | **Arduino library** (BearSSL + ATECC608; ESP/ARM-class boards, never 8-bit) | **roadmap** (phase 2) | | **Zephyr module** (also covers Nordic nRF Connect SDK) | **roadmap** (phase 2) | | **Yocto layer** (embedded Linux + Zynq / PolarFire SoC) | **roadmap** (phase 2) | | **OpenWrt package + Buildroot external** (gateway /128 egress) | **roadmap** (phase 2) | | **pico-sdk library** | **roadmap** (phase 2) | | **Manufacture-line provisioning recipe** and **MQTT-DANCE broker recipe** | **roadmap** (phase 2) | > The integration patterns on this page are **proposed** designs at the cloud/IP boundary: our designs, not vendor endorsements. What you can run today without waiting for any SDK: the keyless verify surface from any TLS-capable device, and the full control plane + routed `/128` from any Linux-class device or gateway. ## Next - [Device & IDevID identity](/docs/device-identity): the shipped derivation these integrations all build on - [Passwordless device auth](/docs/device-secret-cure): the DANCE model the broker integration applies - [Embedded compliance](/docs/embedded-compliance): where the evidence lands for the EU CRA, 62443 and EN 303 645