Navigating Security Tradeoffs in Embedded Linux Systems
summary
File system encryption defends against direct disk reads (the “evil maid”) but fails if the device is live or a cold‑boot attack recovers keys; key provisioning and recovery risk are the main costs. Secure Boot prevents bootloader/kernel tampering but does not stop userland RCEs. dm-verity prevents persistent userland modifications by checking a signed root hash which forces dm-verity requires a verifiable root hash and effectively read-only rootfs and complicates updates and A/B schemes. Hardware enclaves like ARM TrustZone isolate secrets and reduce exfiltration risk but impose TrustZone secure world isolates secrets but adds substantial development and maintenance cost, more auditing, and no guarantee against side‑channel or kernel compromises.
AI-written summary · about
chapters (9)
- 0:00Embedded Linux security tradeoffs
- 1:24Security critical concern
- 3:10Security gradient not binary
- 5:39Threat modeling embedded systems
- 9:14File system encryption use
- 19:16Secure boot limitations
- 24:23Root fs verification dm-verity
- 33:56Secure enclaves TrustZone
- 39:18Summary
related talks
34mAuthenticated and Encrypted Storage on Embedded Linux
53mSecure Embedded Linux Product - A Success Story
42mBecoming a tyrant: Implementing secure boot in embedded devices
32mELC 2013 Security: Best Practices for Embedded Systems
41mProtecting Your System from the Scum of the Universe
40mKeeping secrets in your opponent's hands
32mEmbedded Linux Security: Dr Jekyll and Mr Hyde
59mGetting Started with Embedded Linux Security