Vehicle cybersecurity: ISO 21434 and secure boot
A connected vehicle is a target. The basics of threat analysis, secure boot, message authentication and diagnostic security.
Why it became important
As telematics, Bluetooth, Wi-Fi and OTA connected the car to the outside, cases of remote attack appeared. Under UN Regulation R155 a cybersecurity management system became a type-approval requirement, and ISO/SAE 21434 is the standard for the development process.
Threat analysis (TARA)
Assets (firmware, keys, communication) → threat scenarios (injecting forged CAN messages, tampering with firmware) → attack paths and feasibility → risk → security goals and measures.
Representative techniques
| Technique | What it prevents |
|---|---|
| Secure boot | Running unsigned firmware |
| Secure update | Installing tampered or downgraded images |
| SecOC | Forged CAN messages (MAC + freshness value) |
| Hardened diagnostic security access | Writing memory through the diagnostic port |
| HSM | Key storage and cryptographic operations in isolated hardware |
| Gateway firewall | Access from external to internal networks |
Secure boot flow
The boot ROM verifies the bootloader's signature → the bootloader verifies the application's signature → the application runs. The public key for verification is kept in an area that cannot be changed (OTP, HSM). The private signing key is used only on a protected signing server, never on a development PC.
Developer habits
Lock the debug port (JTAG/SWD) before release, no hard-coded passwords or keys, and check the length and range of communication input. Together with functional safety, it is one of the two pillars of vehicle software quality.