# Platform integrations **Whisper sits beside the vehicle stack you already run and anchors exactly one thing: a routable, verifiable identity at the cloud/IP boundary. That's the layer where a stolen token or a scraped API today looks identical to the real thing.** Everything below is a **proposed** integration pattern (our design, not a vendor endorsement), and every one is written the same way: *Whisper complements the mechanism you have; it never replaces it.* We do not sit inside SecOC, we do not touch the V2X/SCMS air interface, and we do not intercept the ISO 15118 charging handshake. Those live on the bus and at the plug, and they are already someone's job. Whisper's job is the network identity of whatever is talking to your cloud: the TCU, the ECU, the fleet-API consumer, the neutral server. It's expressed as an IPv6 `/128` that DNSSEC, DANE and RDAP can prove and one call can revoke. > **One spine under all six.** Each integration below reuses the same shipped primitive: a deterministic `/128` derived from a device's *public* key plus its VIN ([Vehicle & ECU identity](/docs/industries/auto/vehicle-identity)), published with a DANE pin and an RDAP record, verifiable by anyone with no account. The integrations differ only in *where in your stack* that identity is bound and checked. ## Anchor the boundary, not the plug A connected vehicle carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular vehicle, ECU, or sanctioned data consumer, and the receiver has only a bearer token or a shared-CA certificate to go on. | Layer | Owner / mechanism | Whisper's role | |---|---|---| | In-vehicle bus (CAN/CAN-FD) | SecOC MAC + freshness | **none**: never touches the bus authenticator | | V2X air interface | SCMS / IEEE 1609.2 pseudonym certs | **none**: adjacent PKI, different medium | | EV charging handshake | ISO 15118 Plug & Charge contract certs | **none**: anchors the car↔cloud backhaul, not the plug | | Vehicle ↔ cloud (IP) | vendor device CA + mTLS / OAuth bearer | **anchors here**: an out-of-tenancy `/128` the caller *is*, provable without the vendor's CA | Read the last row as the whole thesis: at the IP boundary, identity today is a *claim* carried in a header. Whisper turns it into a *network fact*: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP. ## COVESA uProtocol: the keystone uProtocol addresses every entity in a software-defined vehicle with a `UUri`, and its `authority_name` field is explicitly allowed to be a domain name, a VIN, *or an IPv6 address*. That last option is the keystone: a Whisper `/128` is a near-literal drop-in for a uProtocol authority. It's a globally unique, routable name that already resolves, already reverse-resolves, and already carries a DANE pin. The integration is to let the authority a uEntity announces be its Whisper identity instead of an unverifiable string. Nothing in uProtocol's transport, its VSS data model, or its Zenoh/SOME/IP bindings changes; you are only making `authority_name` a name a third party can independently confirm. ```bash # A uEntity announces authority_name = its Whisper /128. Anyone can confirm it: # no account, no uProtocol library, just forward-confirmed reverse DNS. dig -x 2a04:2a01:cafe:beef::a323:d40d +short acef2002a323d40d4..agents.whisper.online. dig AAAA acef2002a323d40d4..agents.whisper.online +short 2a04:2a01:cafe:beef::a323:d40d # forward matches reverse → FCrDNS holds ``` > **Complements uProtocol, does not replace it.** Whisper does not define your service topology, your uEntity IDs, or your resource catalog. That stays yours. It only makes the *authority* half of a `UUri` a resolvable, DNSSEC-anchored, revocable identity instead of a string you have to take on faith. ## AWS IoT FleetWise & IoT Core On AWS IoT, every device authenticates into your account with an X.509 certificate and mutual TLS, and your account's IoT registry is the certificate authority. That is exactly right for getting the vehicle *into your tenant*. It says nothing to anyone *outside* your AWS account (a partner, an auditor, a fleet buyer, a neutral server) who wants to confirm that a given endpoint really is that vehicle without being handed your private CA. Whisper adds that out-of-tenancy identity *beside* the vendor mTLS, not in place of it. The device keeps its AWS IoT certificate and its MQTT mTLS untouched; you additionally derive a `/128` from the same hardware key and publish its DANE pin and RDAP record in public DNS. Now the AWS-internal trust and the externally-verifiable trust share one root: the device's key. But no one outside needs your CA to check the second one. ```bash # Anyone outside your AWS account verifies the endpoint trustlessly: # DNSSEC + DANE + a signed ledger entry, Whisper's own API NOT trusted. whisper verify --trustless acef2002a323d40d4..agents.whisper.online dnssec pass DNSSEC-root AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root dane pass DNSSEC-root served leaf SPKI-SHA256 == TLSA pin ledger pass DNSSEC-root entry present, signature verifies CRYPTOGRAPHICALLY PROVEN · trust anchor: DNSSEC root (IANA) + DANE-EE # Or the keyless RDAP record for the address: who holds it, since when. curl https://whisper.online/ip/2a04:2a01:cafe:beef::a323:d40d ``` > **Complements the AWS IoT device CA + mTLS, does not replace it.** Your IoT registry stays the authority for admission to your tenant. Whisper is the identity a party who is *not* in your AWS account can verify, using nothing but the public DNSSEC root. IoT FleetWise campaigns and IoT Core MQTT are unchanged. ## IEEE 802.1AR & TPM: the birth certificate This is the shipped spine the other five build on. An 802.1AR IDevID, a TPM, or an in-vehicle secure element gives a device a hardware birth certificate: a key that was generated on the silicon and whose private half never leaves it. Whisper derives the vehicle or ECU `/128` from that device's *public* `SubjectPublicKeyInfo` plus its VIN (and, optionally, an ECU serial). The private key stays sealed where it was born; only the public SPKI is ever presented. The derivation is deterministic and tenant-bound: the same key and VIN always yield the same `/128` (idempotent re-provisioning), the mapping is unlinkable to outsiders so a fleet can't be enumerated from its addresses, and the result is DNSSEC-anchored, DANE-EE `3 1 1` pinned, and RDAP-registered the instant it's minted. ``` # Provision the /128 for a vehicle from the key it already holds + its VIN. # identity_public_key is the device's PUBLIC SPKI (base64): the IDevID/TPM key. CALL whisper.agents({op:'connect', args:{ tier: 'wireguard', identity_public_key: '', vin: '1HGCM82633A004352' }}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error ``` Send it with stock tools. The control plane is one HTTP endpoint, and the key travels only in the header: ```bash curl -s https://graph.whisper.security/api/query \ -H "X-API-Key: whisper_live_xxx" \ -H "content-type: application/json" \ -d @connect.json | jq . # connect.json = {"query":"CALL whisper.agents({op:'connect', ...})"} {"ok": true, "status": 200, "result": { "address": "2a04:2a01:cafe:beef::a323:d40d", "wireguard": { "…": "…" }}} # → the deterministic /128 + a WireGuard config ``` The behaviour is honest and predictable, which is the point: | Re-provision with… | Result | |---|---| | the *same* key + VIN | `200`: the **same** `/128` returns (idempotent) | | a *different* VIN on the same tenant's key | `409`: the identity is already bound; no silent rebind | | a non-string VIN | `400`: a clear input error, never an opaque 500 | Tear it down worldwide at DNS-TTL speed with one call. The `/128`, its PTR, and its DANE pin all go together: ``` CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:cafe:beef::a323:d40d'}}) YIELD op, ok, status, error RETURN op, ok, status, error ``` > **Complements the IDevID / TPM, does not replace it.** The birth certificate stays exactly where it was born. The private key never leaves the secure element, because Whisper only ever consumes the *public* SPKI. The full derivation, unlinkability property and DANE mechanics are on [Vehicle & ECU identity](/docs/industries/auto/vehicle-identity). ## AUTOSAR Adaptive: SOME/IP & DDS An AUTOSAR Adaptive platform runs IP-native inside the car: services discover each other over SOME/IP or DDS on automotive Ethernet, and those endpoints already terminate TLS or DTLS. The integration is to publish the endpoint certificate's key as a DANE `TLSA` record, so a peer pins the exact leaf key from DNSSEC-signed DNS instead of trusting a shared CA bundle. It's the same profile the rest of Whisper uses: DANE-EE `3 1 1`, SPKI/SHA-256. ```bash # Pin the SOME/IP endpoint's leaf key in DNSSEC-signed DNS: no shared CA. dig +dnssec TLSA _443._tcp.acef2002a323d40d4..agents.whisper.online ;; flags: qr rd ra ad ← ad = DNSSEC-authenticated ;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d ``` > **Complements SecOC, does not replace it, and never touches the CAN authenticator.** SecOC protects messages on the in-vehicle bus with a MAC and a freshness value; that is a different layer with a different threat model, and Whisper does not go there. Whisper anchors the *IP endpoint's* TLS/DTLS certificate at the Ethernet/service boundary. The two are complementary and non-overlapping: bus integrity below, endpoint identity above. See [DANE & TLSA](/docs/dane) for the byte-for-byte record. ## Android Automotive OS A modern cockpit runs many apps and in-car agents, and each one makes its own outbound calls: maps, voice, media, telemetry, model APIs, OTA. Android's permission model governs what an app may *do* on the device; it says little about *where its traffic goes* once it leaves. Whisper's role here is per-app egress governance: source-bind an app or agent's outbound flows to a dedicated `/128`, route its DNS through the graph-first resolver, and apply a per-app or per-fleet policy (category and geography blocks, plus attribution and logging keyed to the address that made the call). ```bash # Set the outbound policy for one app/agent identity (keyed, one call). whisper policy --agent 2a04:2a01:cafe:beef::a323:d40d \ --block-category ads,malware --allow-geo eu policy updated · effective at DNS-TTL speed across both servers ``` Because every flow is attributed to an address, you can ask the attribution graph what a given endpoint has been talking to (read-only, over the public API with your key). There is no `whisper identify` CLI subcommand; it's a Cypher call: ```bash 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(\"2a04:2a01:cafe:beef::a323:d40d\")"}' | jq . ``` > **Complements the Android permission model, does not replace it.** App permissions still gate device capabilities; Whisper governs the *network egress* of the identity behind each app. See [Egress governance](/docs/egress-governance) and [Connect & egress](/docs/connect) for the transport tiers. ## ISO 20078 ExVe: the neutral server ISO 20078 (Extended Vehicle) standardises how an OEM exposes vehicle data to third parties, typically through a neutral server that brokers access under consent and contract. The consent and contract model is the standard's job and stays untouched. What Whisper adds is a way to anchor the neutral server's own TLS endpoint (and each sanctioned consumer's identity), so a data buyer can confirm they are talking to the real broker, and the broker can confirm a request comes from an allowlisted network identity rather than a stolen API key replayed from anywhere. Give the neutral server (and each authorised consumer) a `/128` with a published DANE pin; the consumer verifies the broker trustlessly, the broker allowlists the consumer's source address. A reverse-engineered client from a random IP simply has no Whisper identity to present. ```bash # A data consumer confirms the ExVe neutral server before sending a request. whisper verify --trustless neutral-server..agents.whisper.online # …and the keyless HTTP form, for a stranger with no CLI: curl https://whisper.online/verify-identity/2a04:2a01:cafe:beef::a323:d40d {"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { … }} ``` > **Complements ISO 20078's consent/contract model, does not replace it.** Who may access what, and under whose consent, stays with the ExVe framework. Whisper anchors the *transport identity* on both sides so the contract is enforced against a network fact, not a portable secret. The fleet-API angle is worked in full on [Fleet-API-abuse cure](/docs/industries/auto/fleet-api-abuse-cure). ## Shipped today vs proposed Honesty about what runs matters more here than anywhere. The *identity primitive* under every integration is live and provable right now; the *integration guides* themselves are proposed patterns for wiring that primitive into each platform. | Building block | Status | |---|---| | Deterministic `/128` from a device's public key + VIN | **shipped, live** | | Provision via the control plane (`op:'connect'`, WireGuard tier) | **shipped, live** | | Keyless verify: `whisper verify --trustless`, `/verify-identity`, `dig -x`, RDAP | **shipped, live** | | Revoke: `/128` + PTR + DANE torn down at DNS-TTL speed | **shipped, live** | | Attribution graph over the public API (`CALL whisper.identify(…)`) | **shipped, live** | | The six integration *guides* on this page (uProtocol, AWS IoT, 802.1AR, AUTOSAR, AAOS, ISO 20078) | **proposed** (our design, not a vendor endorsement) | > The `--vin` CLI flag is not shipped yet. Vehicle provisioning today goes through the control-plane call shown in the 802.1AR section above, which *is* live. The CLI verbs that exist are `whisper verify --trustless`, `whisper create --register`, `whisper kill --revoke`, `whisper policy` and `whisper logs`. ## On the roadmap These feed vehicle-security evidence into the tools a VSOC already runs. They are **roadmap: not yet shipped**, listed here so you can see where this goes: - **Microsoft Sentinel connector**: *shipped today*, alongside the **Splunk** connector. - **OpenCTI** threat-intelligence integration: *shipped today*. - **STIX/TAXII + Auto-ISAC ATM JSON export**: *roadmap*. Maps identity and egress evidence onto the Automotive Threat Matrix and standard TI transports for R155 continuous-monitoring workflows. ## Next - [Vehicle & ECU identity](/docs/industries/auto/vehicle-identity): the shipped derivation these integrations all build on - [Fleet-API-abuse cure](/docs/industries/auto/fleet-api-abuse-cure), the primary wedge: identity at the fleet-API ingress - [R155 · ISO 21434 · ATM](/docs/industries/auto/automotive-compliance): where the evidence lands for type approval