Time of Check Time of Use Problem
- Software manipulated after attestation (and before execution)
- Verifier not aware of the change in the state
SMART
- Secure Minimal Architecture for (Establishing a Dynamic) Root of Trust
- A hardware architecture, which enables the deployment of the security objectives
- Goal: Remote code attestation
-> Addresses TOCTOU problem
-> Provides prove of execution, enhancing system integrity and security
SMART adversary model
- Full control over software
- No invasive hardware attacks
- No side-channel attacks
SMART System assumptions
- Immutable memory (ROM)
- Memory (RAM) erased at reset
SMART attestation
- Shared key between prover and verifier ensures secure communication
- Key only accessible from attestation code, enhancing confidentiality
- Attestation code:
-> no bugs/no information leakage (static analysis)
-> Atomic execution (attestation code then attested code) -> integrity
-> Entrance only at first address, exit only at last address (mitigate code reuse attacks)
SMART protocol parameters passed to prover
- Is: Start of code region to attest
- Ie: End of code region to attest
- entry: Entry of the code (first instruction) to execute
- flagx: Whether or not to execute the code (specified by entry) after the attestation process
- Nonce
SMART protocol
1) Attestation is issued by verifier
2) Determine output address where to store HMAC, start SMART attestation (execution is non-interruptible)
3) HMAC of code section and parameters authenticated with key
4) Verify valid key access (if false, reset)
5) Result is written to RAM
6) Remove all intermediate values
7) Start execution of the attested code (if flag is set)
8) Send HASH value to verifier
SMART Advantages
- Prove of Execution: Execution of attested code is triggered after SMART (uninterrupted in absence of hardware attacks)
- Minimal changes to CPU/MPU
SMART Disadvantages
- Limited flexibility
-> Attestation code not changeable/updateable - Non-interruptible execution/reset on violation
-> Limits scope of measured code
-> Limited runtime for measured code in real-time-systems
TrustLite
- A Security Architecture for Tiny Embedded Devices
- Goal: Generalization of Execution-Aware Memory Protection Unit
-> Free configurable protection memory-regions (Trustlets)
-> No new/special CPU instructions
TrustLite Adversary Model
- Full control over software (except loader)
- No hardware and side-channel attacks
TrustLite System assumptions
- Device Key shared with device owner
- memory-mapped I/O for all peripheral access
- TrustLite aware Exception Engine
TrustLite Features
- Generalization of Execution Aware Memory Protection Unit
-> Not based on privilege level, directly associates data & code regions
-> Free configurable protection regions (Trustlets)
-> No additional CPU instructions required - Secure Exception Handling
-> Interruptible Trustlets with secure context saving - Secure Loading
-> Secure loading of Trustlets and setup of MPU - Inter Process Communication (IPC)
-> Secure IPC between mutually authenticated Trustlets with one-round handshake
TrustLite: Trustlet Loading
1) Load Trustlets into the main memory
2) Protect MPU configuration itself, MPU marked as read-only. From this point it is immutable until system reboot
3) Load operating system
TrustLite: Exception Handling
1) Interrupt while Trustlet is executed
2) State saved on Trustlet stack
3) Update Trustlet table
4) Load OS Stack
5) Load Interrupt Service Routine
-> Each Trustlet has its own stack stored in its own memory region
-> CPU state (context) is not maintained (is erased) when switching between Trustlets (specific Trustlet is restored for execution)
TrustLite: Attestation Trustlet
1) Verifier sends nonce to the device
2) Attestation Trustlet calculates HASH over code region, the nonce and the device key
3) Result is sent to the verifier
TrustLite Advantages
- Flexible
-> Trustlets execution is interruptible
-> Protection regions freely configurable - Update is possible
- Peripheral devices access
-> Access to hardware components can be limited to certain Trustlets - Isolation of arbitrary code
TrustLite Disadvantages
- Trustlets loader is trusted (part of the Trusted Computing Base TCB)
- Static Trustlet code region-allocation required for inter process communication
- Number of allowed rules in the MPU is fixed at manufacturing time
Attestation Solutions Comparison: Authentication of Prover
- SMART
-> Key access exclusive to ROM-code
-> One specific execution aware MPU rule - TrustLite
-> Key access exclusive to Attest Trustlet and Key access restricted via EA-MPU
-> General EA-MPU rule
Attestation Solutions Comparison: Freshness of Attestation
- SMART and TrustLite: Verifier challenges Prover with nonce
Attestation Solutions Comparison: Integrity of Attestation
- SMART
-> On ROM-code entry interrupts are disabled
-> Platform reset on (non-maskable) interrupt - TrustLite
-> Option 1: Interrupts disabled while Attest Trustlet executes
-> Option 2: Attest Trustlet is interruptible
–> Attest Trustlet state does not leak confidential information due to exception handling of TrustLite
–> Attestation target must be immutable until attestation is complete, e.g., set MPU rules for attested code to read-only
Jeep Hack
- Inject IPC messages over the network
-> e.g. override SSH key and start SSH service - Reflash proxy Controller with modified firmware
- Send CAN messages to control the car
Software-based Attestation
- Exploits computational constraints of prover
- Only memory checksum can produce desired result in time
- No security hardware or root of trust
