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

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: SETI@home 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

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

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

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

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

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

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

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

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

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

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

Questions? BARC 2003: 13