AEGIS Secure Processor

Transcription

1 AEGIS Secure Processor G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, Srinivas Devadas L C S

2 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 UntrustedOS Physical attacks Music/Movie Make Illegal Copies Incorrect Results; Break the System Program Software Distributed Computing, Peer-to-Peer Network

3 Conventional Tamper-Proof Packages Processing system in a tamper-proof package (IBM 4758) Expensive: many detecting sensors Inflexible: cannot upgrade the system in the package $2,690 in 2001 Memory 99MHz 486 Source: IBM website

4 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 Untrusted OS Identify or Protect against Trusted Environment Check Integrity, Encrypt I/O Memory

5 AEGIS: High-Level Architecture L C S

6 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

7

8 Program Start-Up enter_aegis : TE mode Start protecting the integrity of a program Compute and store the hash of the stub code: H(Prog) Tampering of a program results in a different hash Stub code verifies the rest of the code and data set_aegis_mode Start PTR mode on top of the TE mode enter_aegis code_end SHA-1 H(Prog) Protected Table Program.text enter_aegis EKey1 = 0xA4523BC2E435D; EKey2 = 0xB034D2C654F32; E1Msg = Secret=GetSecret(Challenge); Key1=Decrypt(EKey1, Stub Segment Secret); Key2=Decrypt(EKey2, Secret); CheckMAC(Key1, Key2, MAC); Msg = Decrypt(E1Msg, Key1); E2Msg = Encrypt(Msg, Key2); Output(E2Msg); 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);

9 On-Chip Protection Registers on interrupts SCM saves Regs on interrupts, and restore on resume On-chip caches Need to protect against software attacks Use SPID tags and virtual memory address Allow accesses from the cache only if both SPID and the virtual address match Standard Processor Regs L1 Instruction cache Processor Core SPID Tags Resume L1 Data cache On-Chip L2 Cache Interrupt SPID Tags SPID Tags SPID H(Prog) Regs SCM Off-Chip Memory

10 program Memory Encryption Processor ENCRYPT write Untrusted RAM DECRYPT read Trusted State Fast hardware encryption based on one-time pads Hides decryption latency

11 program Memory Encryption Processor Trusted State V E R IF Y ENCRYPT DECRYPT write read Untrusted RAM 0x45: E(124), MAC(124, 0x45) E(120), MAC(120, 0x45) Can t simply encrypt and MAC on writes, and check MAC s on reads Replay attacks Hash-tree and log schemes to verify integrity

12 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

13 L C S Applications

14 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 Job Dispatcher Processor Program, Data, PKm 1 Compute H(Program) 7 Verify signature 8 Verify hash 2 Program program executes 6 {H(Program), Out} SKp, {PKp} SKm SKp, PKp, {PKp} SKm 3 Start: enter_aegis: Processor computes H(Program) 4 Execute Out 5 Sign: sign_msg

15 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 Content Provider Customer s Processor Secure Player, Content, PKm 2 Secure Player SKp, PKp, {PKp} SKm 1 Compute H(Player) 6 Pick random nonce 5 Set up SSL connection 7 nonce 9 {h, nonce} SKp, {PKp} SKm 3 Start: enter_aegis, set_aegis_mode PTR Compute h=h(player) 4 seed=random( ) 10 Verify signatures and hash 11 Order / deliver content 8 sign_msg(nonce) 12 Decode and play Analog Output

16 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 Memory encryption only provides partial privacy Privacy is expensive but not necessary for all applications Palladium/NGCSG: 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).

17 Summary Physical attacks are becoming more prevalent DRM, software licensing, distributed computing, etc. Single-chip secure processors provide trusted execution environments with acceptable overhead Tamper-Evident environment, Private Tamper-Resistant environment Simulation results show 5-15% overhead for TE, 10-25% overhead for PTR processing Significant development effort underway Complete AEGIS architecture description (ICS 03) FPGA/ASIC implementation of AEGIS processor

18 L C S Performance

19 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 Log Hash w/ infrequent checks: Worst case 15% degradation Most cases < 5% degradation Normalized IPC Hash Trees: Worst case 45% degradation Most cases < 25% degradation CHTree LHash gcc gzip mcf twolf vortex vpr applu art swim 1MB L2 Cache with 64B blocks

20 Performance Implication: PTR processing Major performance degradation is from off-chip integrity checking and encryption CHTree+Direct LHash+OTP Log Hash w/ OTP encryption: Worst case 25% degradation Most cases < 15% degradation Normalized IPC Hash Trees w/ CBC encryption: Worst case 55% degradation Most cases < 40% degradation gcc gzip mcf twolf vortex vpr applu art swim 1MB L2 Cache with 64B blocks