1. Authority-mode Secret Protection (SP) architecture
Paper and slides from:
Jeffrey Dwoskin & Ruby Lee, “Hardware-rooted Trust for Secure Key Management and Transient Trust”, ACM Conference on Computer and Communications Security (CCS), October
Princeton Architecture Lab for Multimedia and Security (PALMS)
Department of Electrical Engineering
Princeton University
I will describe our new Authority-mode SP architecture,
A system for key management and establishing trust in devices used remotely,
Based on storing some master secrets on-chip, and using a small set of trusted software.

2. Introduction Crisis Management Authority Authority … SP Device 1K1 K2 Kn
____
____
We start with a trust model where a central authority owns multiple devices
Used remotely, called remote trust
Each a “Secret-Protecting” device – cell phone/pda or laptop (which has our new hardware)
Authority shares secrets and cryptographic keys with the devices
Control how keys and data are used on remote device.
Protect use of 3rd party secrets that don’t belong to the user
Crisis-response example
Crisis management authority and a network of responders in the field
Paramedics, fire fighters, police officers, etc
Access medical records, evacuation plans, building schematics, satellite maps, etc
Other scenarios – corporate networks, military systems, special-purpose appliances (cell phone), etc
Authority establishes trust relationship with each device
Shared secret, in hardware, as basis for future trust – hardware support for trust relationship
SP Device 1
SP Device 2
SP Device n … K2 Kn K1
SP = Secret Protection architecture

3. Trust Model Crisis Management Authority Authority … 3rd Party AKA
3rd Party B KB
Crisis Management
Authority
Authority K1 … Kn KA KB
Extend - 3rd party sources of data - access control delegated to authority.
Actual data encrypted – manage keys for encr/sign.
Controlled transitive trust – relationship w/each 3rd party. Delegates policy to devices. Devices get data directly, policy controlled by authority.
Extend basic remote trust to include multiple 3rd parties
Sources of the data – various owners with their databases – manage own access control for day-to-day use
Delegate access control (for a crisis) to the authority, which can determine which devices need which data
Assume actual data is kept & transferred in encrypted form, so we need to securely manage the keys for encryption and MACing/signing
So that plaintext is only available on a legitimate device which has the keys
Controlled Transitive trust –
auth sets up indiv relationships with each third party (with shared keys or certificates)
policy-delegation from 3rd party to auth to devices
devices and 3rd parties communicate directly to access data
But the relationship & permissions/policies are managed by the authority
SP Device 1 K1
SP Device 2 K2
SP Device n Kn …

4. Threat Model Software attacks Physical attacks OS & Apps
Install any software, replace OS
Offline modification of storage
Probe buses, change memory, DMA
Security boundary
Software Attacks
Physical Attacks – lost or stolen devices
“some hardware attacks”
security boundary – don’t trust whole box but assume probing the chip is difficult
-- UNLIKE TPM
We consider attacks on the confidentiality & integrity of keys and their assoc. policies,
But not concerned with protecting availability

5. Architecture Overview
Authority App
User App 1
User App 2
Trusted
Software
Module
Operating System
At end – these 2 master secrets are the hw roots of trust for the security we provide.
TSM is software that is flexible – can do any function using these hw roots of trust – “hw trust anchors”
TSM – whose execution is protected by hw
TSM manages storage struct. using master keys for encryption & integrity
we derive keys from the Device Root Key so the master key itself is not used directly – less exposed
Sw – persistent secure storage – also protected by the SRH
Will explain each in more detail…
Start with base system – hardware components & simple software stack
Add the authority’s software
Of which part of the app is trusted code – the Trusted Software Module
-- code is signed for integrity, using the master secret on chip (shared by authority)
-- integrity is verified during operations, and execution is concealed using CEM
-- TSM+CEM is based on our previous work on the SP architecture which we explain later
In software, the TSM (and only the TSM) can create new keys derived in hardware from the Device Root Key
It uses these to encrypt and MAC
Master secrets on chip (shared w/authority)
Trusted part of app + CEM hardware
Derived keys & storage structure on disk – for use by TSM – encrypted
Disk
Processor Chip
Concealed
Execution
Mode
RAM
Storage Root Hash
Device Root Key
User I/O

6. Outline Trust Model Threat Model Architecture Overview
Secure Storage & Communications
Derived Keys
Hardware Architecture
Usage/Crisis Response

7. Storage Root Hash (SRH)
Secure Storage
Device Root Key (DRK)
Storage Root Hash (SRH)
Root
Derived Keys
Item
Data
Keychain
Key
Policy
Item
Data
Keychain
Key
Policy
Encrypt &
MAC
TSM maintains in SW.
Keys and policy protect auth’s data, form a hierarchy – available only to the TSM.
Only TSM can access keys & therefore data – will always enforce the authority’s policies.
Nodes encrypted w/derived keys – generated from DRK.
Derived keys also used to MAC at each level – embedded hash tree – root on-chip.
Provides integrity. on-chip=prevent replay – reliable revocation…
TSM can provide Transient access to data, and reliably enforce policy-controlled use of the keys
TSM maintains a storage structure in software.
Contains keys and policies for the data protected by the TSM, forming a hierarchy.
Only the TSM can access the structure (and therefore the data), and it is designed to always enforce the authority’s policies
The nodes of the structure are encrypted, using derived keys – generated from the device root key.
The structure contains hashes at each level, forming an embedded hash tree, and the root is stored on-chip as the SRH
Provides integrity, so malicious modifications will be detected.
Since root is on-chip, we prevent replay of the structure
allows for reliable revocation. Once a key is deleted or a policy changed, the SRH is updated and the old values are no longer valid to the TSM.
Thus the TSM can provide Transient access to data, and reliably enforce policy-controlled use of the keys

8. Derived Keys Derive_Key (DRK, Constants, Nonces); Storage
Communications
Device Root Key (DRK)
MAC
New instr to create derived keys, available only to the TSM
Done in hardware…
never use the DRK directly, one of the hardware roots of trust
The TSM specifies different constants when generating keys for different purposes to distinguish the keys.
The TSM also provides nonces for freshness and to generate multiple keys for each purpose.
If the same nonces and constants are used, the TSM can regenerate the same derived key
– for example to create encryption keys for storage in one session and regenerate them later during another session for decryption.
Nonces
Constants
Storage
Keys
Communication
Keys

9. Derived Keys & Communications
Storage key for encryption of node i:
KSi-Enc = MACDRK(CStorage, CENC, NSi)
Storage key for MAC of node i:
KSi-MAC = MACDRK(CStorage, CMAC, NSi)
Comm. key for Authority to Device:
KA→D = MACDRK(CComm, CA, NA, ND)
Comm. key for Device to Authority:
KD→A = MACDRK(CComm, CD, ND, NA)
Storage
Nonce for each node/item to be protected
Generate keys for encryption & MAC
Store data (encr) along with nonce (plaintext)
Use nonce later to regenerate the keys to decrypt & verify
Communication keys
Exchange nonces
Generate comm key for each direction
Sign a message (nonces) and send MAC
Verify on each recipient – prove knowledge of DRK

10. Secure Communications
Exchange Nonces: NA, ND
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)
KA→D
KD→A
KA→D
KD→A
Mutual authentication – using hardware root of trust
Verify session keys – proves that both side know the DRK – the master secret, and therefore authenticate each other, which is unique to each SP device (which only the authority and device know)
Setup comm. Channels, exchange nonces
Generate keys, send message, verify
Both sides prove knowledge of DRK, which authenticates since no other parties know the shared secret.
Setup comm using standard protocols such as TLS w/preshared key
Mutual Authentication
Secure Communications

11. Secure Storage
Persistent - Secure storage structure – maintained by TSM
Items contain keys or data
Hierarchical structure – data and policy at each level (inherited-down policy)
Using derived keys – only accessible to TSM with valid DRK – each node encrypted
Incorporates hash tree
Implementation/contents is application-specific

12. Storage Item Structure

13. Secure Storage Data can only be used on this device
Changes are permanent because root hash is on-chip
TSM will only read data by following tree with correct hashes
Readable only with keys based on device’s DAK
Directory nodes form structure of the tree
Uniquely identify each node, its type and where to find it on permanent storage
Store MAC, nonce for encryption key
Root is broken up
Root DN stores first level of hierarchy and is a full DN, but its parent is split up
Its MAC is on-chip and rest is stored at known location

14. Outline Trust Model Threat Model Architecture Overview
Secure Storage & Communications
Hardware Architecture
Usage/Crisis Response

15. Hardware Architecture
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
Master Secrets – non-volatile in hardware, restricted to access only by TSM code
The original core is the entire processor, and on the chip there are 2 levels of caches – level 1 and level 2 caches.
The new registers we add on the left are actually very small compared to the rest of the processor core and caches.
CIC – dynamic checking of TSM code
CEM – protection of intermediate data for TSM
Master Secrets
Code Integrity Checking (CIC)
Concealed Execution Mode (CEM)

16. Runtime Code Integrity Checking of Trusted Software Module (TSM)
DRK
TSM
Addr 1
Addr 2
Addr 3
Addr 4
MAC
Addr 5
TSM
Storage Root Hash
Original
Core
L1 Instr
Cache
w/ Tags L2
Cache
w/ Tags
Secure BIOS
Cache miss rate of level 2 is very small (1-2%) – very rarely have to fetch data off the chip, and then takes hundreds of cycles, so doing extra crypto is not very expensive
Insert slides – step by step CIC & CEM,
Master Secrets
CIC – dynamic - embedded hashes, cache tags,
CEM
Secure load/store
Register Interrupt protection
Access to Derived Keys & SRH L
Device Root Key
Encrypt/
Hash
Engine
Derived Keys
L1 Data
Cache
w/ Tags
Int Addr
Mode
RAM
BIOS
Interrupt Hash

17. Concealed Execution Mode
Encr
Secure Load
Secure Store PC +4
Register
File
Hash
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 Load/Store – distinguish persistent data in storage struct from TSMs temporary data during execution.
CEM – protect intermediate data during execution
Register values protected on interrupts
- encry + hash + return address
Secure data with cache tags & encry+MAC
TSM starts  change mode + CIC + CEM + access to derived keys

18. New Instructions GR TO DRK DRK LOCK GR TO SRH SRH TO GR DRK DERIVE
Description
New Authority Mode SP Instructions
GR TO DRK
Sets Device Root Key register from GRs.
DRK LOCK
Sets DRK_Lock register to 1, disabling GR TO DRK instruction.
GR TO SRH
Sets Storage Root Hash register from GRs.
SRH TO GR
Reads the Storage Root Hash register into GRs.
DRK DERIVE
Derives a key from DRK by computing a keyed hash over a nonce and constants
Instructions for providing a Concealed Execution Mode for TSM code
BEGIN CEM
Enter CEM for next instruction.
END CEM
End CEM for next instruction.
SECURE STORE
Secure store from GR to memory.
SECURE LOAD
Secure load to GR from memory.

19. Outline Trust Model Threat Model Architecture Overview
Secure Storage & Communications
Hardware Architecture
Usage/Crisis Response
Initialization
Crisis Response

20. Authority’s Trusted Depot
Initialization
Authority’s Trusted Depot
SP Device n
Secure Servers
Processor Chip
Root Hash
CEM HW K P
Storage Structure
Random
Number
Generator
DRK n
DRK n
MAC
DRK n
Derived Keys K P K P
Disk
--If attacker replaces DRK, can replace TSM, but lose access to the old storage--
Generate DRK on server  database  device
TSM unsigned code  server  sign  transfer to device
Create initial storage structure
Install system software
Transfer secure storage to device & tell TSM to set SRH
======
At authority’s depot – secure – check devices from manufacturer
Shared secret – random, unique – boot secure BIOS & save. Save in authority DB
TSM code – verify, sign for device
System sw (OS, untrusted apps), transfer TSM
Initial secrets – initialize storage, transfer secrets & policy, setup user authentication
Reboot & lock DRK, load reg BIOS & system
========
Generate shared secret
Prepare TSM code
Install software & TSM
Initial secrets
Regular operation
Secure Database
Keys
Operating System
User
App
TSM
TSM
Standard
System
Software
Standard
System
Software
Initial Data

21. Crisis Response Day-to-day use Preparation Crisis begins
Additional access required
Negotiate with 3rd parties
Keys and usage policies
Certificates
Plan for potential crises
Crisis begins
Delegation
Authentication & secure communications
Distribution
Gone through all the mechanisms – put together to show how these can be used for preparation, during, and after a crisis.
Menetion secure storage and secure communications
(keys and usage policies stored in the persistent storage described earlier)\
(mutual auth uses secure communications we described)
Additional access needed for crisis
Authority prepares policy rules for many possible crises
Negotiate rights with 3rd parties in advance
Decide on delegation of rights to individual devices and users
Authority-owned secrets pre-packaged as encrypted storage nodes
Crisis begins
delegate: determine precisely which responders get which information (what is affected, who responding,).
Determine policies and expirations. Encrypt nodes for each device
Create & sign certs, tagged with crisis ID and reasonable expiration
Attest devices and distribute certs & initial data

22. Crisis Response Crisis Operations Post-crisis Revocation
Data from 3rd parties
Additional authorizations
User authentication
Post-crisis Revocation
Policy-controlled
Direct revocation
End crisis
Devices contact 3rd parties to retrieve sensitive data as needed
3rd parties verify device’s cert against authority CA
Devices request additional access from authority while in field
Unanticipated circumstances
Access beyond pre-authorized data
e.g. “need to know” may be determined in the field
Authority-TSM periodically re-authenticates user
Balance risk of loss vs convenience during emergency
TSM enforces which data is displayed and how data can be operated on
==========
Policy-controlled
Limits on number of uses, expiration dates, etc
Direct revocation by authority per device
Authority can instruct TSM to delete secrets or modify policy
Cut-off access to new secrets/data
Authority tells 3rd party to cut-off access, revoke certs/delegation
Disable entire crisis ID
Revoke crisis-certs for individual devices
Authority itself stops sending new secrets

23. Summary Designed the Authority-mode SP architecture with:
Two hardware roots of trust
Flexible Trusted Software Module protected by hardware
Concealed Execution Mode
No burnt-in secrets
Requiring only symmetric keys
Can be implemented in any microprocessor or embedded processor
Hw roots of trust allow flexible usage because of flexible TSM – itself protected by CEM

24. Conclusions SP architecture enables: Defends against SW & HW attacks
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
Defends against SW & HW attacks
SP arch, a combination of hardware and software.
SP is very flexible and can be used in a number of usage scenarios as we have described. In particular it provides…