architecture for protecting critical secrets in microprocessors ruby lee peter kwan patrick mcgregor...
TRANSCRIPT
Architecture for Protecting Architecture for Protecting Critical Secrets in Critical Secrets in MicroprocessorsMicroprocessors
Ruby LeePeter Kwan
Patrick McGregorJeffrey Dwoskin
Zhenghong Wang
Princeton Architecture Laboratory for Multimedia and Security Department of Electrical Engineering
Princeton University
One User, Many Documents/Keys, Multiple Devices
1
Secure I/O
Reduced security perimeter:From the box to the chip
Attacks on Devices
• Security vulnerabilities:– Software– Physical (device theft)
Processor chip
Registers
On-chip cacheVideo
Off-chip cache
Main memory
Network
Other I/O
Disk
SW Access in supervisor mode
SW Access in OS Interrupt Handler
SW Access to hard
disk
Physical probing
2
Past Work
• Distributed software-based key management – Involves multiple servers
• Secure coprocessors and crypto tokens (deployed)– Tamper-resistant crypto modules (IBM’s 4758) and
smartcards
• Trusted Computing Group (TPM recently available)– Industry: Microsoft NGSCB, Intel LaGrande.
• Recent secure processor proposals (research)– XOM, AEGIS, VSCoP
• Our approach– Lower cost, high performance, no auxiliary hardware, no
permanent secret and requires minimal trusted software
3
Secret Protected (SP) Architecture
1. New Trust Model – Most SW and HW untrusted
2. Trusted software module (TSM)– Securely perform operations using the keys
3. Encrypted keychain– Reduce the amount of secrets needing protection
4. Concealed execution mode (CEM)– Protect the execution environment of TSM
5. New processor features– Very small additions to ISA– Secure I/O – input of the user key.
Security Goal:Keep user’s keys private to the user
4
Core
L2unifiedcache
L1 datacache
L1 instr.Cache
New registers:
CEM Status Flags (2)
User Master Key (128)
Device Master Key (128)
CEM Return Address (64)
CEM Interrupt Hash (128)
Encryption/hashingengine
Secure I/Ologic
Small additions to the processor
Core
SecureI/O
logic
Encryption/hashingengine
L2unifiedcache
L1 datacache
L1 instr.Cache
Externalmemory
LEDs,buttons,keyboard
New registers:
CEM Status Flags (2)
User Master Key (128)
Device Master Key (128)
CEM Return Address (64)
CEM Interrupt Hash (128)
5
New Trust Model
Disjoint region of trust wrt CPU protection rings
Unprivileged Software
Privileged Software
OS Kernel
Trusted SoftwareModule
User Secrets
User Secrets
6
TSM API
1,000’s keys are secured by protecting 1
User Master Key
K1 K2
Hash()Pass-phrase
K3 K4 K5
7
HW Supporting the Key Chain
Core
SecureI/O
logic
Encryption/hashingengine
L2unifiedcache
L1 datacache
L1 instr.Cache
Externalmemory
LEDs,buttons,keyboard
New registers:
CEM Status Flags (2)
User Master Key (128)
Device Master Key (128)
CEM Return Address (64)
CEM Interrupt Hash (128)
8
Secret Protected (SP) Architecture
1. New Trust Model– Orthogonal to protection rings
2. Hierarchical keychain– Reduce amount of secrets needing protection
3. Trusted software module (TSM)– Carry out operations using the keys
4. Concealed execution mode (CEM)– Protect TSM program integrity– Protect TSM data in main memory and caches– Protect registers on interrupts
5. New processor features– Very little addition to achieve the goal
9
Instructions MAC
1648 bytes
Instructions MAC …….
64-byte cache line
MAC
Protect TSM program integrity
• Device Master Key
• Provide keyed hash (Message Authentication Code) per cache line
TSM code
Device Master Key
MAC
TSM code
Keyed_hash()
Code address
10
Basic Approach for protecting TSM data
11
Processor chip
On-chip cache
DRAM
Off-chip cache
Outside security perimeter:• data exists as ciphertext• Use Encryption and hashing
Inside security perimeter:• data exists as plaintext• Use Tagging
Secure Data 2 Secure Data 2
Decryption &integrity check
Protection over the entire memory hierarchy
• Cache line tagging – separating secure from nonsecure, and data from code.
Secure Instruction Tags
Secure Data Tags
L1 Instr Cache
L1 Data Cache
L2 Unified Cache
Secure Code 1
Code 3
Secure Code 2
Secure Data 2
Data 1
=
Main Memory
Data 3
Secure Data 2
Secure Code 1
Secure Code 2
Data 1
Code 3
Data 3
Secure Code 1
Secure Code 2
Secure Data 2
Code 3
Data 1
Code 3
Data 1Data 3
Secure Code 1Secure Code 2
Secure Code 1Secure Code 2
Secure Data 2
Secure Code 1
Secure Code 2
Code 3
Data 1
Data 3
Data 3
YN
12
HW Supporting memory protection
Core
SecureI/O
logic
Encryption/hashingengine
L2unifiedcache
L1 datacache
L1 instr.Cache
Externalmemory
LEDs,buttons,keyboard
New registers:
CEM Status Flags (2)
User Master Key (128)
Device Master Key (128)
CEM Return Address (64)
CEM Interrupt Hash (128)
Registers
13
R0 R1 R2 R31......
One Plaintext message
Protecting register values during interrupts
• “In situ” registers encryption– no change required in OS interrupt handler
• Store hash on-chip
• Return address trigger
R0 R1 R2 R31......
Encryption()
One Ciphertext message
R0 R1 R2 R31......
R0 R1 R2 R31......
R0 R1 R2 R31
New registers:
CEM Status Flags (2)
User Master Key (128)
Device Master Key (128)
CEM Return Address (64)
CEM Interrupt Hash (128)
Hash()
CEM Return Address (64)
CEM Interrupt Hash (128)
Device Master Key (128)
14
Device and User Initialization
Device Initialization- Secure Bootup- TSM installationUser Initialization
SecureI/O
logic
User Master Key (128)
Device Master Key (128)Device Master Key (128)
User Master Key (128)
15
Execution environment on device
Architectural summary
User Master KeyprotectsSecure I/O
Trusted softwaremodule
Operates upon
Device Master KeyDevice initialization
protects
CodeMemoryRegisters
16
Contributions and Conclusions
• Minimalist SP-architecture protects critical secrets (keys) which then protectother sensitive data
• Decouples users from devicesmore convenient and realistic usage model
• No permanent secretdefends against factory database compromise
• Master keys are symmetric keys faster and less storage
• Security without compromising performance, cost, usability
Core
L2unifiedcache
L1 datacache
L1 instr.Cache
17
Opportunities for Future Research
• Other uses of SP architecture
• Alternative programming models using SP
• Secure I/O
• Attestation
• Security verification
• Extension to multicore processors
18
Thank you!