Automotive

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), 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.

# 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.<tenant>.agents.whisper.online.

dig AAAA acef2002a323d40d4.<tenant>.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.

# 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.<tenant>.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: '<base64 SPKI of the device 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:

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.

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.

# Pin the SOME/IP endpoint's leaf key in DNSSEC-signed DNS: no shared CA.
dig +dnssec TLSA _443._tcp.acef2002a323d40d4.<tenant>.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 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).

# 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:

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 and Connect & egress 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.

# A data consumer confirms the ExVe neutral server before sending a request.
whisper verify --trustless neutral-server.<tenant>.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.

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.

Vehicle & ECU identity: the shipped derivation these integrations all build on
Fleet-API-abuse cure, the primary wedge: identity at the fleet-API ingress
R155 · ISO 21434 · ATM: where the evidence lands for type approval

← Fleet-API-abuse cure R155 · ISO 21434 · ATM →