architecture for protecting critical secrets in microprocessors ruby lee peter kwan patrick mcgregor...

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!