Embedded Security Architectures Flashcards
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)
