How not to secure your embedded system, lessons from automotive testing
summary
About 90 pentests so far uncover repeated, concrete failures: read-only XCP allowed full flash and key extraction by incremental CRC/brute-force; RNG outputs identical across power cycles and across ECU instances so cryptographic nonces and debug passwords are predictable; software update flow accepts a trailing “all is okay” message that validates manipulated firmware, and certificates are writable or accepted without proper root verification; HSM/secure-boot checks are bypassable by placing code in unchecked flash and tweaking boot config. Recommendations: test randomness over power cycles and units, fuzz certificate parsers, keep dev controls enabled with dev keys, and lock down read/write services.
AI-written summary · about
chapters (7)
- 0:00Automotive security testing intro
- 1:25Common vulnerabilities in automotive ECUs
- 3:53Weak RNG and passwords
- 6:01Security access flaws
- 7:03Update and cert flaws
- 9:50Secure boot and HSMs
- 11:34Engaging pentesters
related talks
35mPatterns and Anti-Patterns in Embedded Development: What Security Incidents...
41mPanel: Tackling Automotive Hardware Vulnerabilities
17mEmbedded Security's Weakest Link: Lessons From Simple Mistakes
32mELC 2013 Security: Best Practices for Embedded Systems
24mIf They Can Touch It, They Own It: The Stories We Tell...
20mSecurity and Safety in the Modern Vehicles
21mIndustrial IoT security issues and countermeasures
47mTop 10 Secure Boot Mistakes