Cumulative Attestation Kernels for Embedded Systems

1
Cumulative Attestation Kernels for Embedded
Systems

• Michael LeMay and Carl A. Gunter

2
Cumulative Attestation

• Instantaneous Attestation

• Cumulative Attestation

• Multiple Platform Configuration Registers (PCRs)
  measure various parts of the current system state

• A comprehensive chronological log of the firmware
  images is maintained

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 RAM12KiB 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
File 1
File 2
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.as
  p

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