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. 389-400, October 2007.