1 / 22

Cumulative Attestation Kernels for Embedded Systems

Cumulative Attestation Kernels for Embedded Systems. Michael LeMay and Carl A. Gunter. Cumulative Attestation. Instantaneous Attestation. Cumulative Attestation. A comprehensive chronological log of the firmware images is maintained:.

clea
Download Presentation

Cumulative Attestation Kernels for Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cumulative Attestation Kernels for Embedded Systems Michael LeMay and Carl A. Gunter

  2. Cumulative Attestation Instantaneous Attestation Cumulative Attestation A comprehensive chronological log of the firmware images is maintained: • Multiple Platform Configuration Registers (PCRs) measure various parts of the current system state: PCR 0 = H(FW 4.0) … H(FW 1) H(FW 2) H(FW 3) H(FW 4) PCR n = H(FW 4.n) FW 1 FW 2 FW 3 FW 4 FW 1 FW 2 FW 3 FW 4 Time

  3. Contributions • Design & prototype of Cumulative Attestation Kernel for Flash MCUs with MPUs • Experimental performance evaluation of prototype • Formal verification that prototype satisfies important correctness and fault-tolerance properties

  4. Security Requirements • Comprehensiveness: Audit log must represent all firmware ever active on system • Accuracy: Active firmware must be recorded as latest entry in audit log • Must be possible to verify devices remotely over high-latency network • Offloading attacks must be considered

  5. Threat Model • Prevents remote attacks over network from scaling • Sample demand response attack: • Millions of meters slowly compromised • At some point in future, all cut off power at the same time • Bad effects on grid!

  6. Other Potential Target Systems Intelligent Electronic Device: - Monitors and controls state of electric power grid - Physically protected, but potentially network accessible Pay-As-You-Drive (PAYD) Auto Insurance: - Records data used as input to critical financial processes - Located in unprotected, hostile environment - Occasional network connectivity

  7. Platform-Imposed Requirements • Cost-effectiveness • Energy-efficiency • Suitability forhardware protections • Fault-Tolerance/Robustness

  8. Target Platform: 32-bit Flash MCUs • 8-bit Flash MCUs: • Atmel AVR MEGA 1280: • 128KiB Flash • 8KiB RAM • 4KiB EEPROM • 16 MIPS • 32-bit Flash MCUs: • Atmel AVR32 UC3A0512 (April 2007): • 512KiB Flash • 64KiB RAM • 91 MIPS • Memory Protection Unit

  9. Design/Prototype Characteristics • Kernel RAM:12KiB out of 64KiB 191.5KiB 512KiB 40KiB (107events/upgrades) 88KiB

  10. Lack of FW Upgrade Fault-Tolerance Segment #0 Segment #0 Segment #1 Segment #1 Segment #2 Segment #2 Segment #3 Segment #3 Firmware Buffer Application Firmware

  11. Fault-Tolerant FW Upgrades Staging Area UpgradeProgressPointer Segment #0 Segment #0 Segment #1 Segment #1 Segment #2 Segment #2 Segment #3 Segment #3 Firmware Buffer Application Firmware System State Staging Backup Finishing

  12. Fault-Tolerant Flash FS Persistent Copy Persisted Working Copy File #1 File #1 File #2 File #2 File #n File #n Working Copy File #1 File #2 File #n

  13. Verification Challenges • Ideal goal: Verify important properties using specification derived directly from implementation code • Challenges in achieving goal: • C has ill-defined semantics and code tends to be more verbose and less-organized than that of higher-level languages • Attempted to use subset of C# compiled to native code to implement system • Finally implemented system in C++ and manually derived model

  14. Experimental Results - Time

  15. TPM Power Measurements

  16. Prototype Results – Energy Efficiency TPM idle power consumption: 10.6 mW

  17. Power Efficiency Implications • SCE deploying 5.3 million meters • Annual TPM idle energy consumption: ~500MWh (~45 average US households)* * http://tonto.eia.doe.gov/ask/electricity_faqs.asp

  18. Verification Overview • Object-oriented Maude with continuations • Model checker, using Linear Temporal Logic to express theorems

  19. Model Assumptions • Flash write and program upgrade operations can be interrupted at any time by a reset operation • Recovery operations subsequent to such an interruption can also be repeatedly interrupted (but not forever!) • Memory write operations result in unpredictable (“garbage”) data in the destination location when interrupted

  20. Verification Strategy • Phase 1: Verify complex system interactions, assuming that storage primitives are fault tolerant • Firmware upgrades and rollbacks • Corresponding audit log operations • Phase 2: Verify storage primitive fault tolerance • Static flash filesystem fault tolerance • Firmware upgrade fault tolerance • Attempting to merge the two phases overloads the Maude model checker (segfault)

  21. Proof Generation Methodology • Expressed theorems in Linear-Temporal-Logic • Automatically checked theorems using Maude model checker

  22. Conclusion • Cumulative Attestation Kernels address the need for strong remote firmware integrity monitoring of flash MCUs with memory protection hardware • Developed efficient prototype CAK • Verified correctness and fault-tolerance properties using model checker

More Related