A few hundred lines of code.
Every car already has a crypto library for secure boot and TLS. We're adding one function: encrypt the telematics payload before transmit. The owner holds the key.
1. The vehicle's MCU generates an encryption key at first registration and exports it to the owner's phone or hardware wallet.
2. All telematics data (GPS, speed, behavior) is encrypted with that key before cellular transmission. The OEM cloud receives ciphertext it cannot read.
3. OBD-II port remains cleartext by default — all legacy tools, scan tools, and repair equipment work unchanged.
Sensors → ECU/BCM → TCU → Cellular (cleartext) → OEM Cloud (reads everything)
↓
Data Brokers, Insurers,
Law Enforcement, Anyone
Sensors → ECU/BCM → TCU → [ENCRYPT PII] → Cellular (ciphertext) → OEM Cloud (opaque blobs)
↑ ↓
Owner Key Can't read. Can't sell.
(in secure element) Can't share. Can't lose.
OBD-II Port → Cleartext (unchanged) → Any scan tool, any mechanic, any owner
| Encrypted (PII — cellular uplink) | Clear (Non-PII — OBD-II + cellular) |
| GPS coordinates | Engine RPM, oil temp, coolant |
| Speed / velocity | Diagnostic Trouble Codes (DTCs) |
| Acceleration / braking events | Fuel consumption rate |
| Route history | Tire pressure, battery voltage |
| Driver behavior scoring | Emissions sensor readings |
| Idle time / dwell locations | Odometer |
Rule: If it answers "where did you go?" or "how did you drive?" — encrypted. If it answers "how is the engine running?" — clear.
This is not a rewrite. It is an addition to existing telematics firmware.
| Component | Lines of Code | Notes |
| Key generation (AES-256 in secure element) | ~20 lines | Crypto library already exists for TLS/secure boot |
| Key export (one-time hash envelope via BLE/OBD-II) | ~30 lines | BLE GATT characteristic or OBD-II extended PID |
| PII field identification (classify before encrypt) | ~40 lines | Config table: which CAN IDs are PII vs. non-PII |
| Encrypt PII payload before cellular transmit | ~50 lines | AES-256-GCM on the telematics message buffer |
| Key rotation on ownership transfer | ~30 lines | Generate new, export, erase old |
| Optional OBD-II encryption (with timer) | ~40 lines | Conditional encrypt on OBD-II response, auto-expire |
| Post-quantum upgrade path (ML-KEM-1024) | ~80 lines | Key encapsulation wrapper, algorithm-agile design |
| TOTAL | ~290 lines | In existing MCU firmware with existing crypto libs |
Context: A typical automotive TCU firmware is 500,000 - 2,000,000 lines of code. The R2E module is 0.01% - 0.06% of the existing codebase. The crypto primitives (AES, SHA-256) are already linked for TLS and secure boot. This is not new technology — it is one new function call on an existing path.
MCU advertises a BLE GATT service during registration. Owner's phone app connects, authenticates (PIN on dashboard display), receives encrypted key material. Same pattern as phone-as-key systems already deployed by Ford, BMW, Tesla.
Best for: Consumer vehicles, new models with BLE already integrated.
Owner connects a Rootz hardware dongle or compatible scan tool to OBD-II port. MCU responds to an extended PID request with the wrapped key material. Owner's device stores key in wallet.
Best for: Fleet vehicles, aftermarket retrofit, older models, maximum compatibility.
MCU generates ephemeral DH keypair. Public half displayed as QR on dashboard or transmitted via BLE. Owner's phone uses it to establish shared secret. Key material encrypted to shared secret. Delivered back to confirm. Zero plaintext key exposure.
Best for: High-security applications (government, executive protection, high-value cargo).
Every car gets a wallet. The wallet holds the key. The owner controls the wallet.
Vehicle Data Wallet (Polygon)
├── VIN: [hashed, privacy-preserving identifier]
├── Owner: [owner's wallet address — transfers on sale]
├── Encryption Key: [encrypted to owner, stored as Note]
├── Access Grants:
│ ├── Fleet Manager: [team key — operational access]
│ ├── Insurer: [purpose-limited, time-bounded, revocable]
│ ├── Mechanic: [service-visit scoped, auto-expires]
│ └── Regulatory: [attested compliance channel]
├── History:
│ ├── Service records (signed Notes from shops)
│ ├── Trip attestations (FreightProof receipts)
│ ├── Inspection records (photo + hash)
│ └── Ownership transfers (key rotation events)
└── Post-Quantum: [ML-KEM-1024 wrapped key for long-term archive]
No new protocol needed. The vehicle key is stored in a Rootz Data Wallet. Sharing uses the existing team mechanism:
While we're adding encryption, we also capture what's already there: the measured boot hash. This gives every data record a proof of origin.
Every modern automotive MCU performs a measured boot sequence for secure boot validation. The firmware image is hashed (SHA-256) and verified against a reference before execution. This hash — the firmware attestation code — uniquely identifies the exact software version running on the TCU.
We're not adding attestation. We're recording what the MCU already computes.
After measured boot, the MCU includes its firmware attestation hash in the first telematics message of each session. This is recorded in the vehicle's on-chain wallet.
Result: every data record links back to a specific firmware version running on a specific MCU. You can prove not just WHAT was recorded, but that the recording came from THIS vehicle running THIS verified software.
MCU Secure Boot:
1. Boot ROM loads bootloader → hash verified against OEM root key
2. Bootloader loads firmware → hash verified (this is the attestation code)
3. Firmware starts → attestation hash recorded in first uplink message
4. Vehicle Data Wallet receives attestation → records on Polygon
Every subsequent data record references this attestation:
"Data from VIN [hash] | Firmware: [attestation_hash] | Session: [timestamp]"
Verification:
- Anyone can verify the firmware hash against OEM's published reference
- Proves: untampered firmware produced this data
- Proves: no man-in-the-middle injected false data
- Proves: this specific physical vehicle generated this record
Why this matters for litigation: A cryptographically attested data record from a measured-boot MCU is the strongest possible digital evidence. It's not "the fleet says this happened." It's "the hardware, running verified firmware, signed this record." That's beyond reasonable doubt for electronic evidence.
Why this matters for the standard: We're proposing that OEMs publish their firmware attestation reference hashes — the same way they publish VIN decoder specs. Any verifier can confirm: "yes, this data came from a genuine Ford TCU running firmware version X." This becomes the root of trust for all vehicle data.
This is exactly what the Trusted Computing Group designed TPM Platform Configuration Registers (PCRs) for in 2003. Measured boot → hash chain → attestation quote → remote verification. The automotive MCU is a simpler version of the same pattern. We're applying 23 years of proven standards to a new substrate.
| Component | Lines |
| Key generation + secure element storage | ~20 |
| Key export (BLE/OBD-II one-time envelope) | ~30 |
| PII field classification (config table) | ~40 |
| Encrypt PII payload (AES-256-GCM) | ~50 |
| Key rotation on ownership transfer | ~30 |
| Firmware attestation recording | ~30 |
| Optional OBD-II encryption (timer) | ~40 |
| PQ upgrade path (ML-KEM-1024 wrapper) | ~80 |
| TOTAL | ~320 lines |
320 lines. Encryption + attestation + post-quantum readiness. In a firmware that's already 500K-2M lines. Using crypto libraries that are already linked.
Vehicle data has a 20+ year operational lifespan. Data encrypted today must resist quantum attack in 2046.
Standard encryption (AES-256-GCM): Used for real-time telematics. Fast, hardware-accelerated on every modern MCU. Quantum-resistant for symmetric operations.
Key encapsulation (ML-KEM-1024, NIST FIPS 203): Used for key exchange and long-term archive. Resists "harvest now, decrypt later" attacks.
Algorithm agility: The MCU spec uses a key_type field. When PQ algorithms become mandatory (CNSA 2.0 timeline: 2030), a firmware update swaps the KEM without changing the data format.
The Rootz @rootz/pq-crypto package (v1.1.0) implements ML-KEM-1024 + ML-DSA-65 today. Level 4 — beyond Apple PQ3.
OBD-II dongle or CAN bus tap that intercepts telematics data, encrypts PII fields, and transmits to owner's archive instead of (or alongside) OEM cloud.
Hardware: AutoPi, Macchina M2, CANedge, or custom PCB (STM32 + secure element + cellular)
Limitation: Cannot encrypt what the OEM TCU already transmits. This is a parallel encrypted copy, not a replacement of the OEM stream.
Value: Owner gets sovereign archive immediately. OEM stream still exists but owner has the better record.
~290 lines added to existing TCU firmware. Deployed via OTA update. Owner opts in during next software update cycle.
Trigger: Regulatory requirement (FAR clause, FCC Cyber Trust Mark, state legislation) or competitive pressure (first OEM to offer gets fleet procurement preference).
Value: Native encryption. No aftermarket device. OEM cloud receives ciphertext from day one.
Vehicle ships with sovereign identity. Key generated at factory, bound to first owner at delivery. Like receiving house keys at closing.
Trigger: OEM partnership + standards adoption. Paccar, Daimler Truck, or Volvo first mover.
Value: Born sovereign. No retrofit. No opt-in. Default architecture.
FAR clause (federal vehicles), state legislation (MA Act III), or FCC Cyber Trust Mark requirement makes owner-controlled encryption mandatory for connected vehicles.
Trigger: Political will + working reference implementation + industry coalition.
Value: Universal. Every connected vehicle. The default for all future robots.
| To the OEM | ~$0 incremental hardware cost (crypto libs already present). One-time firmware development (~290 lines). OTA deployment on existing update infrastructure. |
| To the owner | Free. Key generation is automatic. Storage is in their existing phone/wallet. |
| To the OEM (saved) | Reduced PII compliance cost (CCPA, GDPR, EU Data Act). Reduced breach liability. Reduced class-action exposure. Reduced discovery burden. |
| To insurers | Clean consent chain for UBI. No LexisNexis-style intermediary liability. |
| To fleets | Evidentiary sovereignty. Owner-controlled disclosure. Defensible litigation posture. |
The sovereign architecture is cheaper than the surveillance architecture once compliance, breach, and litigation costs are properly accounted.
That's all that separates the current architecture — where the manufacturer owns your operational data — from the correct one — where you hold the keys to data produced by property you own.
The crypto primitives exist. The secure elements exist. The OTA update infrastructure exists. The wallet infrastructure exists. The constitutional right exists.
The only thing missing is the requirement.