1. AEGIS: Secure Processor for Certified Execution
G. Edward Suh, Dwaine Clarke,
Blaise Gassend, Marten van Dijk,
Srinivas Devadas
Massachusetts Institute of Technology
BARC 2003: 1

2. Security Problems in Computing
Music/Movie
Conventional security
Protect users from malicious
software attacks; trusted users
New security challenges
Protect digital content from
malicious users
Digital Rights Management
Software Licensing
Collaboration of mutually
untrusted computers/users
Distributed Computing:
Peer-to-Peer Network
Software-only solutions do not work
Untrusted OS
Physical attacks
Make
Illegal Copies
Software
Program
Incorrect Results;
Break the System
Distributed Computing,
Peer-to-Peer Network
BARC 2003: 2

3. Architectural Support for Security
Security advantages of hardware processors
Physically secure
Very difficult to change or monitor internal
processor states
Easier to trust a processor than a system
A closed system; users cannot modify
Only a few manufacturers
Other ongoing attempts
Microsoft Palladium
Protects software from software
Vulnerable to physical attacks
XOM Architecture
Software copy protection; encrypted software can only executes on one processor
Security holes
Have to encrypt both instructions and data  performance degradation
BARC 2003: 3

4. Certified Execution: Can Processors GUARANTEE a valid program execution?
A secure processor guarantees a valid execution and the identity of a program; no privacy
Enable trusted collaboration of untrusted systems
Protect against physical attacks and untrusted OS
Tamper-evident execution
Any software or physical tampering to alter the program behavior should be detected
Required protections
Initial start-up
Registers on a context switch
On-chip/Off-chip memory integrity
Message authentication
To be useful, a processor needs an authenticated communication with another system
Outgoing messages: prove it is from a valid secure processor with a valid program
Incoming message: check it is from a trusted party
BARC 2003: 4

5. Secure Context Manager (SCM)
A notion of secure processes
Assign a secure process ID (SPID) for each certified process
Secure context manager (SCM)
Implements new instructions
enter_cert: start certified execution
sign_msg: sign a message
Maintains secure table
Even operating systems cannot modify
Large # of certified processes
Not enough on-chip space
Store the table in memory with a cache in SCM
Verify with hash trees
Standard Processor
SCM
Processor
Core
Regs
SPID … L1
Instruction
cache L1
Data
cache
On-Chip L2
Cache
Off-Chip Memory
BARC 2003: 5

6. Protection Mechanisms: Initial Start-Up
enter_cert code_end, data_start, data_end,
sp_bound
‘enter_cert’ instruction
Allocate a new entry in the SCM table
Start protecting the program with the memory integrity verification mechanism
Compute the hash of the code and initial data: H(Prog)
Store H(Prog) in a secure table
Check the stack pointer is above sp_bound (e.g. x86)
Tampering of the initial PC
Results in a different H(Prog)
Will be detected!!
Program
.text
enter_cert
EKey1 = 0xA4523BC2E435D;
EKey2 = 0xB034D2C654F32;
E1Msg = …
Secret=GetSecret(Challenge);
Key1=Decrypt(EKey1, Secret);
Key2=Decrypt(EKey2, Secret);
CheckMAC(Key1, Key2, MAC);
Msg = Decrypt(E1Msg, Key1);
E2Msg = Encrypt(Msg, Key2);
Output(E2Msg);
H(Prog)
SCM Table
SHA-1
Code Segment
Data Segment
.data
EKey1 = 0xA4523BC2E435D;
EKey2 = 0xB034D2C654F32;
EKey3 = 0xA4523BC2E435D;
EKey4 = 0xB034D2C654F32;
EKey5 = 0xA4523BC2E435D;
EKey6 = 0xB034D2C654F32;
E1Msg = …
EKey7 = 0xA4523BC2E435D;
EKey8 = 0xB034D2C654F32;
...
BARC 2003: 6

7. Protection Mechanisms: Context Switching
Untrusted operating systems can tamper with registers
SCM remembers and verifies registers on a context switch
Interrupt (Program  OS)
Compute the hash of register values H(Regs)
Store H(Regs) in the SCM table
Resume execution (OS  Program)
Compute the hash of restored register values H’(Regs)
Verify the restored register values (H’(Regs)=?H(Regs))
Standard Processor
SCM
Processor
Core
SHA-1
Regs
SPID …
H(Prog)
H(Regs)
SHA-1 ≠?
Exception!! L1
Instruction
cache L1
Data
cache
On-Chip L2
Cache
Off-Chip Memory
BARC 2003: 7

8. Protection Mechanisms: On-Chip Caches
Attacks on the on-chip caches
No Physical attack is possible
Untrusted OS and other processes can change the value in the cache
Protect on-chip cache integrity with SPID tags
When accessed, tag a cache block with the active SPID; 0 for regular processes
For an access by a certified process, evict and reload a block if the tag does not match the active SPID  incur off-chip integrity checking
Standard Processor
SCM
Processor
Core
Regs
SPID …
H(Prog)
H(Regs) L1
Instruction
cache
SPID Tags L1
Data
cache
SPID Tags
On-Chip L2
Cache
SPID Tags
Off-Chip Memory
BARC 2003: 8

9. Protection Mechanisms: Off-Chip Memory
Verify virtual memory space of each certified process
should return the most recent value stored in that virtual address by the process
Mechanisms
Hash trees (HPCA’9)
Check after each memory access
Log hash (LCS TR 872)
Check a sequence of accesses
Optimistic execution
Use values from memory before they are verified unless there is a signing instruction
Background integrity checking
Standard Processor
SCM
Processor
Core
Regs
SPID …
H(Prog)
H(Regs)
Hash L1
Instruction
cache
SPID Tags L1
Data
cache
SPID Tags
On-Chip L2
Cache
SPID Tags
Integrity
Checker
Off-Chip Memory
BARC 2003: 9

10. Message Authentication
Outgoing messages: Processor  Another system
A secure processor holds a private/public key pair (Sproc, Pproc)
Never reveals the private key (Sproc)
The processor signs a message (sign_msg M): {H(Prog), M}Sproc
Unique for each program cause H(Prog) is always included
Only signs for the processes in the certified execution mode
Incoming messages: Another system  Processor
Embed the user’s public key in a program
Incoming messages are signed with the user’s private key
Program with Puser
{Message}Suser
{H(Prog), Message}Sproc
BARC 2003: 10

11. Performance Implication
Major performance degradation is from off-chip integrity checking
Start-up and context switches are infrequent
no performance overhead for on-chip tagging
Log Hash w/ infrequent siging:
Worst case 15% degradation
Most cases < 5% degradation
Hash Trees:
Worst case 50% degradation
Most cases < 25% degradation
BARC 2003: 11

12. Summary
Many applications require protection from physical attacks and untrusted operating systems
Architectural support is essential to achieve this goal
A secure processor can provide trusted execution environment for a program with acceptable overhead
Secure start-up, context switches, and memory integrity
Processor signs a message with its private key
Enables trusted collaboration of untrusted systems
Ongoing work
Complete architecture description (LCS TR 883 forthcoming)
Certified execution architecture
Add privacy to the certified execution architecture
Required for DRM and software licensing
Fast encryption mechanisms
BARC 2003: 12

13. Questions?
BARC 2003: 13