1. Hardware-rooted Trust for Secure Key Management & Transient Trust
Jeffrey Dwoskin and Ruby B. Lee Princeton Architecture Laboratory for Multimedia and Security
Department of Electrical Engineering, Princeton University
Background and Motivation
Architecture Overview
Threat Model
Crisis Response Scenario
Software attacks – Compromise OS & apps
Physical attacks – Security boundary of μ-chip
Replace SW; Access disk, memory, buses; etc.
Day-to-day use with initial secrets
Crisis Preparation
Negotiate with 3rd parties for access to data
Determine key-distribution and usage policies for various potential crises
Setup certificates to distribute to each device
Crisis Begins
Determine delegation to devices based on actual crisis at-hand
Authenticate each device; distribute keys & policies
Crisis Operations
Retrieve data from 3rd parties
Negotiate additional authorizations as needed
Post-crisis Revocation
Policy-controlled secrets have expiration/limits
Direct revocation by authority to each device
End crisis with 3rd parties to stop sending data
Our new Authority-mode SP (Secret Protection) architecture provides key management and trust in portable devices used remotely
A few master secrets stored on-chip, as hardware roots of trust, supported by small trusted software
One example is Crisis Response, where a crisis management authority wants to manage keys and data (secrets) shared with first responders.
Two master secrets on-chip are HW roots of trust
Trusted Software Module (TSM) is flexible SW provided by authority to protect data, keys, policies in Secure Storage, using master secrets
HW Concealed Execution Mode protects TSM
Hardware Architecture
Master secrets in non-volatile registers, restricted to access only by TSM code
Device Root Key, Storage Root Hash
New registers and instructions are very small additions to base processor (not shown to scale)
Disk
RAM
User I/O
Operating System
User App 1
Processor Chip
Storage Root Hash
Authority App
Trusted
Software
Module
Device Root Key
Concealed
Execution
Mode
User App 2
Trust Models
‘Remote Trust’ model with a central authority owning multiple SP devices used remotely in the field by first responders
Authority wants to share keys and data with the devices, but maintain control over how they are used.
These secrets are owned by 3rd parties, not by the users
Each SP device shares a key with authority, protected by hardware, as basis of trust
‘Transitive Trust’ model
3rd party data owners delegate to authority for access control of keys and policies. Data sent directly to devices, which enforce policies.
Storage Root Hash
Derived Keys
Device Root Key L
Interrupt Hash
Int Addr
Mode
Original
Core
L1 Instr
Cache
w/ Tags
L1 Data L2
Encrypt/
Hash
Engine
Secure BIOS
BIOS
RAM
Secure Storage
Secure storage managed by TSM
Protected with keys derived from DRK in HW
Concealed Execution Mode (CEM)
Related and Future Work
Authority
SP Device 1 2 n …
Crisis Management
____ K1 K2 Kn
Code Integrity Checking (CIC)
Runtime checking of TSM code
TSM code broken into cache-line sized blocks and “signed” with MAC from Device Root Key in advance
Code integrity is verified by CEM HW as blocks are fetched into on-chip caches
Execution protection for TSM
Protection of general registers on interrupts
Registers encrypted; hash & interrupt address stored in registers on-chip; reverse on return from interrupt
Protections of intermediate data in memory
Explicit Secure Load/Store instructions for TSM code
Tagged in on-chip caches, encrypt/MAC off-chip
Derived Keys
Device Root Key (DRK)
Root
Storage Root Hash (SRH)
Item
Data
Keychain
Key
Policy
Encrypt &
MAC
Sensor-mode SP
Scaled-down architecture for key management in tiny sensor nodes using same roots of trust
SecureCore
Integrate Authority-mode SP into clean-slate security architecture design with partitioned security-kernel.
Implementation
Software emulation of SP hardware and virtual machine implementation in progress
TSM
DRK
Addr 1
Addr 2
Addr 3
Addr 4
MAC
Addr 5
Secure Communications
Summary and Conclusions
Mutual authentication using derived keys to setup secure communication channel
Authority can send new keys & policies or revoke existing keys.
SP architecture enables:
Remote trust
Transitive trust: protect use of 3rd party keys that don’t belong to the user
Transient trust: support for access to keys on a temporary basis
Policy-controlled use of keys, enforced by authority’s software
Flexible TSM SW for many usage scenarios
Using only two HW roots of trust, no burnt-in secrets, and only symmetric key cryptography
Defends against SW & HW attacks
Authority SP
Device
Generate Session Keys
Comm. key for Authority to Device:
KA→D = MACDRK(Constants, NA, ND)
Comm. key for Device to Authority:
KD→A = MACDRK(Constants, ND, NA)
Exchange Nonces: NA, ND
Mutual Authentication
Secure Communications
KA→D
KD→A …
Crisis Management
Authority
SP Device 1 K1
3rd Party A KA KB B 2 K2 n Kn
Initialization
Authority initializes each device at a secure depot
Authority has secure servers and databases
Generate Device Root Key and save on-chip and in authority’s database
Verify and sign TSM code (with Device Root Key)
Install system software and TSM
Initialize secure storage with initial secrets, policy
Jeffrey S Dwoskin, Ruby B. Lee, "Hardware-rooted Trust for Secure Key Management and Transient Trust", ACM Conference on Computer and Communications Security (CCS) 2007, Alexandria, VA, pp , October 2007.