AEGIS: Architecture for Tamper-Evident and Tamper-Resistant - PowerPoint PPT Presentation

AEGIS: Architecture for Tamper-Evident and Tamper-Resistant Processing G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, Srinivas Devadas Massachusetts Institute of Technology L C S

Cases for Physical Security • Applications on untrusted hosts with untrusted owners – Digital Rights Management (DRM), Software licensing – Distributed computation on Internet – Mobile agents • New challenges – Untrusted OS – Physical attacks Music/Movie Make Incorrect Results; Illegal Copies Break the System Program Distributed Computing, Peer-to-Peer Network Software G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Conventional Tamper-Proof Packages • Processing system in a tamper-proof package (IBM 4758) – Expensive: many detecting sensors – Needs to be continuously powered: battery-backed RAM $2,690 in 2001 Memory 99MHz 486 Source: IBM website G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Single-Chip Secure Processors • Only trust a single chip: tamper-resistant – Off-chip memory: verify the integrity and encrypt – Untrusted OS: identify a core part or protect against OS attacks • Cheap, Flexible, High Performance Identify or Protect against Check Integrity, Encrypt Trusted Environment Untrusted OS I/O Memory G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Related Research • XOM (eXecution Only Memory): David Lie et al – Stated goal: Protect integrity and privacy of code and data – Operating system is completed untrusted – Memory integrity checking does not prevent replay attacks – Privacy is expensive but not necessary for all applications • Palladium/NGSCB: Microsoft – Stated goal: Protect from software attacks – Combination of hardware and software mechanisms – Adds "curtained" memory to avoid DMA attacks – Uses a security kernel (Nexus) – Memory integrity and privacy are assumed (only software attacks). G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

AEGIS: High-Level Architecture L C S

Secure Execution Environments • Tamper-Evident (TE) environment – Guarantees a valid execution and the identity of a program; no privacy – Any software or physical tampering to alter the program behavior should be detected • Private Tamper-Resistant (PTR) environment – TE environment + privacy – Encrypt instructions and data – Assume programs do not leak information via memory access patterns • Implementation – Either have a trusted part of the OS or completely untrust the OS – Secure context manager, encryption and integrity verification G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Secure Context Manager (SCM) • A specialized module in the processor Standard Processor SCM • Assign a secure process ID Processor (SPID) for each secure Core SPID … Regs process … … • Implements new instructions L1 L1 Instruction Data … – enter_aegis cache cache – set_aegis_mode – random On-Chip L2 – sign_msg Cache • Maintains a secure table – Even operating system cannot modify Off-Chip Memory G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

SCM: Program Start-Up • ‘ enter_aegis ’: TE mode – Start protecting the enter_aegis integrity of a program code_end Program – Compute and store the .text enter_aegis EKey1 = 0xA4523BC2E435D; hash of the stub code: EKey2 = 0xB034D2C654F32; E1Msg = … H(Prog) Secret=GetSecret(Challenge); Stub Segment Key1=Decrypt(EKey1, Secret); Key2=Decrypt(EKey2, Secret); CheckMAC(Key1, Key2, MAC); SHA-1 � Tampering of a program Msg = Decrypt(E1Msg, Key1); E2Msg = Encrypt(Msg, Key2); Output(E2Msg); results in a different hash Secret=GetSecret(Challenge); Key1=Decrypt(EKey1, Secret); Key2=Decrypt(EKey2, Secret); H(Prog) CheckMAC(Key1, Key2, MAC); – Stub code verifies the rest Msg = Decrypt(E1Msg, Key1); E2Msg = Encrypt(Msg, Key2); of the code and data Output(E2Msg); Protected Table • ‘ set_aegis_mode ’ – Start PTR mode on top of the TE mode G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

SCM: On-Chip Protection • Registers on interrupts Standard Processor SCM – SCM saves Regs on interrupts, and restore on Processor resume Core Interrupt SPID … Regs H(Prog) … Regs … Resume • On-chip caches … SPID Tags SPID Tags L1 L1 – Need to protect against Instruction Data cache cache software attacks – Use SPID tags and virtual memory address SPID Tags On-Chip L2 – Allow accesses from the Cache cache only if both SPID and the virtual address match Off-Chip Memory G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Memory Encryption Untrusted RAM Processor Program write ENCRYPT DECRYPT read Trusted State • Encrypt on an L2 cache block granularity – Use symmetric key algorithms with CBC mode – Randomize initial vectors G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Integrity Verification Untrusted RAM Processor Program write Address 0x45 V ENCRYPT E E(124), R MAC(0x45, 124) I F DECRYPT Y read E(120), Trusted IGNORE MAC(0x45, 120) State Cannot simply MAC on writes and check the MAC on reads � Replay attacks Hash trees for integrity verification G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Hash Trees Processor root = h(h 1 .h 2 ) VERIFY Logarithmic overhead h 1 =h(V 1 .V 2 ) h 2 =h(V 3 .V 4 ) for every cache miss VERIFY � Low performance L2 block � Cached hash trees Data Values V 1 V 2 V 3 V 4 MISS READ Untrusted Memory G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Cached Hash Trees (HPCA’03) Processor root = h(h 1 .h 2 ) VERIFY h 1 =h(V 1 .V 2 ) h 2 =h(V 3 .V 4 ) Cache hashes in L2 VERIFY In L2 VERIFY DONE!!! � L2 is trusted � Stop checking earlier � Less overhead In L2 V 1 V 2 V 3 V 4 MISS MISS Untrusted Memory G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Message Authentication • Processor � Other systems – The processor signs a message for a program � sign_msg M : {H(Prog), M} SKproc – Unique for each program because H(Prog) is always included • Other systems � Processor – Embed the user’s public key in a program – Incoming messages are signed with the user’s private key Program with P user {Message} Suser {H(Prog), Message} Sproc G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Applications L C S

Certified Execution • Execution certified by the secure processor – Dispatcher provides a program and data – Processor returns the results with the signature • Requires the TE environment � enter_aegis � Verify results � Execute - H(Prog) � Get results - signature Program, Data RESULT Processor’s Processor’s Private Key Public Key RESULT Job Dispatcher Secure Processor G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Digital Rights Management • Protects digital contents from illegal copying – Trusted software (player) on untrusted host – Content provider only gives contents to the trusted player • Requires the PTR environment � Verify � Run Player - H(Player) - nonce - enter_aegis - signature - enter PTR Player Content Random nonce Signed nonce Processor’s Processor’s Public Key Private Key Content Provider Authenticated & Encrypted Secure Processor Channel (SSL) G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Performance L C S

Performance Implication: TE processing • Major performance degradation is from off-chip integrity checking – Start-up and context switches are infrequent – no performance overhead for on-chip tagging 1.2 256KB 1MB 4MB 1 Worst case 50% degradation Most cases < 25% degradation 0.8 Normalized IPC 0.6 0.4 0.2 L2 Caches with 64B blocks 0 gcc gzip mcf twolf vortex vpr applu art swim (a) 64B G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003

Performance Implication: PTR processing • Major performance degradation is from off-chip integrity checking and encryption 1.2 256KB 1MB 4MB 1 0.8 Worst case 60% degradation Normalized IPC Most cases < 40% degradation 0.6 0.4 0.2 L2 Caches with 64B blocks 0 gcc gzip mcf twolf vortex vpr applu art swim G. Edward Suh — MIT Lab for Computer Science International Conference on Supercomputing — June 23-26, 2003