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