cumulative attestation kernels for embedded systems
DESCRIPTION
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:. - PowerPoint PPT PresentationTRANSCRIPT
Cumulative Attestation Kernels for Embedded Systems
Michael LeMay and Carl A. Gunter
Cumulative Attestation
Instantaneous Attestation
• Multiple Platform Configuration Registers (PCRs) measure various parts of the current system state:
Cumulative Attestation
• A comprehensive chronological log of the firmware images is maintained:
2
FW 1
Time
FW 2 FW 3 FW 4 FW 1 FW 2 FW 3 FW 4
PCR 0 = H(FW 4.0)
PCR n = H(FW 4.n)
…H(FW 1) H(FW 2) H(FW 3) H(FW 4)
• 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
Contributions
3
• 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
Security Requirements
4
• 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!
Threat Model
5
Other Potential Target Systems
6
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
• Cost-effectiveness
• Energy-efficiency
• Suitability forhardware protections
• Fault-Tolerance/Robustness
Platform-Imposed Requirements
7
• 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
Target Platform: 32-bit Flash MCUs
8
Design/Prototype Characteristics
9
88KiB
512KiB40KiB (107events/upgrades)
191.5KiB
Kernel RAM:12KiB out of 64KiB
Lack of FW Upgrade Fault-Tolerance
10
Segment #0
Segment #1
Segment #2
Segment #3
Segment #0
Segment #1
Segment #2
Segment #3
Firmware Buffer Application Firmware
Fault-Tolerant FW Upgrades
11
Segment #0
Segment #1
Segment #2
Segment #3
Segment #0
Segment #1
Segment #3
Firmware Buffer Application Firmware
Staging Area
System State
UpgradeProgressPointer
Staging
Backup
Finishing
Segment #2
Fault-Tolerant Flash FS
12
Persistent CopyFile #1 File #2 File #n
Working CopyFile #1 File #2 File #n
Persisted Working CopyFile #1 File #2 File #n
• 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
Verification Challenges
13
Experimental Results - Time
14
TPM Power Measurements
15
Prototype Results – Energy Efficiency
TPM idle power consumption: 10.6 mW16
• 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
Power Efficiency Implications
17
• Object-oriented Maude with continuations• Model checker, using Linear Temporal Logic to
express theorems
Verification Overview
18
• 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
Model Assumptions
19
• 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)
Verification Strategy
20
• Expressed theorems in Linear-Temporal-Logic• Automatically checked theorems using Maude
model checker
Proof Generation Methodology
21
• 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
Conclusion
22