--- title: "Automotive Security — Reference · VORNAC Research" description: "Vehicle attack surface map: in-cabin networks, telematics gateway, software-update channel, supplier dependency graph." url: https://www.vornac.com/en/research/ot-embedded/automotive-security lang: en published: 2026-06-02 updated: 2026-06-02 alternate_de: https://www.vornac.com/research/ot-embedded/automotive-security --- [Research Index](https://www.vornac.com/en/research) / [4 · Operational Technology & Embedded](https://www.vornac.com/en/research/ot-embedded) / Automotive Security — Reference Background · [4 Operational Technology & Embedded](https://www.vornac.com/en/research/ot-embedded) # Automotive Security — Reference. Vehicle attack surface map: in-cabin networks, telematics gateway, software-update channel, supplier dependency graph. ## In-cabin networks - **CAN (classical).** Multi-master broadcast, 1 Mbit/s, no auth, no encryption. Every node sees every message. Spoof = send arbitrary CAN ID at higher priority and win arbitration. `candump can0`, `cansend can0 123#DEADBEEF` from `can-utils`. - **CAN FD.** Same protocol, higher bitrate (5 Mbit/s typical), larger payload (64 bytes). Same lack of auth. - **Automotive Ethernet.** 100/1000BASE-T1 single-pair. Some deployments add MACsec for L2 authentication; many don't. - **LIN, FlexRay, MOST.** Lower-rate buses for body electronics, X-by-wire, infotainment. Each has own bus + own quirks. - **Domain bridges.** The control units that gateway between buses are the choke point. Compromise the gateway = cross-domain control. ## Telematics gateway / TCU - **External surfaces.** Cellular modem (LTE/5G), Bluetooth (BLE pairing flow), Wi-Fi hotspot, sometimes V2X. - **Backend API.** Vehicle authenticates to OEM cloud with per-vehicle cert + token. App-side API for mobile companion app. Both are HTTP services — same web-app review applies. - **Famous failure patterns.** Cellular telematics with publicly resolvable internal hostnames; vehicle-side token reused across the entire fleet; flat backend API where vehicle-ID is the only authz. - **Partitioning.** Modern gateway separates infotainment domain from powertrain domain via hypervisor or dedicated MCU. Bypass = exploit hypervisor escape or find unintended bridge (USB, BT-to-CAN debug, supplier diagnostic port). ## Diagnostics — UDS / OBD-II - **OBD-II port.** Physical access, mandated worldwide. Direct CAN access. Aftermarket dongles often leave it permanently bridged to Bluetooth/Wi-Fi. - **UDS (ISO 14229).** Diagnostic protocol layered on CAN. Service IDs: 0x10 DiagnosticSessionControl, 0x27 SecurityAccess (seed/key challenge), 0x34/0x36/0x37 RequestDownload/TransferData/RequestTransferExit for firmware flashing. - **SecurityAccess weakness.** Seed→key algorithm historically reverse-engineerable from one tool DLL or one captured pair. Modern AUTOSAR uses crypto + per-ECU keys; legacy doesn't. - **Engineering services left enabled.** ECUs in production with engineering-mode UDS services unlocked. Diagnostic protocol becomes RCE chain. ## OTA update channel - **Uptane reference framework.** Two metadata roles (director + image repo), per-vehicle targeting, rollback protection. Adoption uneven. - **Common failures.** Update package signed but rollback-protection missing (downgrade attack); per-vehicle targeting absent (push attacker payload to one vehicle by spoofing VIN); supplier-signed ECU images accepted by gateway without cross-OEM check. - **Test.** Capture update flow with man-in-the-middle on the TCU's HTTPS. Without proper cert pinning, you can substitute the image. ## Supplier dependency graph - A modern vehicle has 50–150 ECUs from dozens of Tier-1 suppliers. Each supplier has their own code base, debug interfaces, key management. - OEM security posture is bounded by the weakest Tier-1. UNECE R155 (cybersecurity) and R156 (software update) push OEMs to track supplier posture; coverage in practice varies. - Recurring finding: Tier-1 ECU ships with debug shell, OEM integration doesn't disable it. **Rule of thumb**Automotive engagements always start with the TCU and its backend API. That's where remote exploitation is possible; everything in-cabin (CAN replay, UDS abuse) requires physical access and is mostly relevant for theft scenarios, not for remote compromise. Domain [4 · Operational Technology & Embedded](https://www.vornac.com/en/research/ot-embedded) Tier Background Engagement phases Reporting Published 2 June 2026 Looking up an acronym? [Open the Glossary](https://www.vornac.com/en/glossary) ## Related notes in this domain - [Reference Wi-Fi Attack & Detection](https://www.vornac.com/en/research/ot-embedded/wifi-attack-mindmap) - [Background ICS & IoT — Security Reference](https://www.vornac.com/en/research/ot-embedded/ics-and-iot-security) [Previous note ICS & IoT — Security Reference](https://www.vornac.com/en/research/ot-embedded/ics-and-iot-security) [Back to domain](https://www.vornac.com/en/research/ot-embedded) From reference to evidence ## Run this against your own environment.