1. 1 ISENET: Integrated Security for the Expanded Internet Gookwon Edward Suh Massachusetts Institute of Technology

2. 2 The Next Internet The Internet is expanding into the physical world Billions of devices will be “on the Internet” –Devices on this Expanding Net will sense properties of the real world, process and store data, and even take physical action Internet Cell phone network Home network Car network Sensor network

3. 3 New Applications Cell phones controlling physical objects through the Internet –Connect to home appliance network Traffic control –Congestion/usage-based real-time tolls –Traffic light control system based on real-time info Sensor networks for environmental monitoring –Energy usage in buildings –Disaster response More responsibilities mean more risk –Security is a key enabling factor to these new applications

4. 4 Attacks on the Expanded NET Software Attacks (traditional): –Break in by exploiting one application’s security holes –Infect other applications Devices are disseminated, unsupervised, and physically exposed Physical Attacks –Install malicious software –Invasive probing –Non-invasive measurement –Environmental attacks

5. 5 Traditional Approaches Don’t Work Cryptographic primitives assume keys remain secret Security protocols assume channels are protected against eavesdroppers Firewall approach does not work for disseminated devices –Anyone in range can communicate with wireless device –No natural place to put firewall TPM TPM CPU System Flash

6. 6 What is ISENET? Fundamental research on security of Expanding Net –Many ideas will apply to more conventional nets as well Need an Integrated effort to Secure the Expanding NET –Security efforts isolated to a particular layer may easily be subverted by attacks carried out at a different layer Hardware System Software Distributed Services Distributed Services Distributed Applications System Software Discover Secret key Spoof Network Server node

7. 7 ISENET Research Areas Hardware System Software Distributed Services Distributed Applications Theory Privacy and Policy Hardware System Software Distributed Services

8. 8 ISENET Research Goals Tamper-Resistant Hardware Isolate Untrusted Distributed Software Secure Distributed Applications Provable Security Anonymity Policy-Aware Systems Tamper-Resistant Hardware Isolate Untrusted Distributed Software

9. 9 Key Ideas and Techniques in ISENET Aegis: Single-Chip Secure Processor (PUFs) Distributed Compartments (AsbestOS) Runtime system and Query language Correlation Engine to secure distributed application against environmental attacks Physical Security Theory: Providing security with partially leaky hardware Policy-Aware Systems where users negotiate appropriate anonymity agreements Aegis: Single-Chip Secure Processor (PUFs) Distributed Compartments (AsbestOS) Probing Attacks Measurement Attacks Malicious software agents Malicious users Compromised Nodes/Data

10. 10 Tamper-resistant hardware System software Networking, distributed computing Theory and cryptography Privacy and policy Applications ISENET Research Thrust Teams Devadas, Micali, Anderson, van Dijk Kaashoek, Morris, Liskov, Lynch, Kohler, Mazières Morris, Balakrishnan, Abelson, Katabi, Liskov, Madden Rivest, Goldwasser, Micali, Devadas, Lysyanskaya, Lynch, van Dijk Weitzner, Abelson, Anderson, Lysyanskaya Madden, Kohler, Balakrishnan, Kaashoek, Weitzner

11. 11 Center for Information Security and Privacy (CISP) http://cisp.csail.mit.edu/ 22 faculty associated with the Center and over 50 graduate students Research projects in cryptography, secure distributed systems, Internet security and software security Current partners: ITRI, Nokia, Quanta, RSA, Sun Likely additional partners (9/2005): Cisco, BT, Philips

12. 12 Tamper-Resistant Platform

13. 13 ISENET Secure Computing Platform How can we “trust” remote computation? Need a secure platform –Authenticate “itself (device)” –Authenticate “software” –Guarantee the integrity and privacy of “execution” Aegis Processor

14. 14 Existing Approaches Sensors to detect attacks Expensive Continually battery-powered Tamper-Proof Package: IBM 4758 Trusted Platform Module (TPM) A separate chip (TPM) for security functions Decrypted “secondary” keys can be read out from the bus

15. 15 Our Approach Build a secure platform with a “single-chip” processor (AEGIS) as the only trusted hardware component Protected Environment Memory I/O Security Kernel (trusted part of an OS) A single chip is easier and cheaper to protect The processor authenticates itself, identifies the security kernel, and protects program state in off-chip memory Protect Identify

16. 16 Authenticating the Processor Each processor should be unique (has a secret key) so that a user can authenticate the processor Sign/MAC a message the key  A user can authenticate the processor Encrypt for the processor key  Only the processor can decrypt Key challenge  Embedding secrets in the processor in a way that is resistant to physical attacks

17. 17 Problem EEPROM/ROM Processor Probe Adversaries can physically extract secret keys from EEPROM while processor is off Trusted party must embed and test secret keys in a secure location EEPROM adds additional complexity to manufacturing Storing digital information in a device in a way that is resistant to physical attacks is difficult and expensive.

18. 18 Our Solution: Physical Random Functions (PUFs) Generate keys from a complex physical system Security Advantage –Keys are generated on demand  No non-volatile secrets –No need to program the secret –Can generate multiple master keys What can be hard to predict, but easy to measure? Physical System Processor Challenge (c-bits) configure characterize Response (n-bits) Use as a secret Can generate many secrets by changing the challenge Hard to fully characterize or predict

19. 19 Silicon PUF – Concept Because of random process variations, no two Integrated Circuits even with the same layouts are identical –Variation is inherent in fabrication process –Hard to remove or predict –Relative variation increases as the fabrication process advances Experiments in which identical circuits with identical layouts were placed on different ICs show that path delays vary enough across ICs to use them for identification. Combinatorial Circuit Challenge c-bits Response n-bits

20. 20 A (Simple) Silicon PUF [VLSI’04] Each challenge creates two paths through the circuit that are excited simultaneously. The digital response of 0 or 1 is based on a comparison of the path delays by the arbiter We can obtain n-bit responses from this circuit by either duplicate the circuit n times, or use n different challenges Only use standard digital logic  No special fabrication … c-bit Challenge Rising Edge 1 if top path is faster, else 0 DQ 1 1 0 0 1 1 0 0 1 1 0 0 101001 01 G

21. 21 PUF Experiments Fabricated 200 “identical” chips with PUFs in TSMC 0.18  on 5 different wafer runs Security –What is the probability that a challenge produces different responses on two different PUFs? Reliability –What is the probability that a PUF output for a challenge changes with temperature? –With voltage variation?

22. 22 Inter-Chip Variation Apply random challenges and observe 100 response bits Measurement noise for Chip X = 0.9 bits Distance between Chip X and Y responses = 24.8 bits Can identify individual ICs

23. 23 Environmental Variations What happens if we change voltage and temperature? Measurement noise at 125C (baseline at 20C) = 3.5 bits Measurement noise with 10% voltage variation = 4 bits Even with environmental variation, we can still distinguish two different PUFs

24. 24 Reliable PUFs PUF n Challenge PUFs can be made more secure and reliable by adding extra control logic c Response k One-Way Hash Function New Response Hash function (SHA-1,MD5) precludes PUF “model-building” attacks since, to obtain PUF output, adversary has to invert a one-way function Syndrome BCH Encoding n - k Error Correcting Code (ECC) can eliminate the measurement noise without compromising security BCH Decoding Syndrome For calibrationFor Re-generation

25. 25 Authentication The processor identifies security kernel by computing the kernel’s hash (on the l.enter.aegis instruction) –Similar to ideas in TCG TPM and Microsoft NGSCB –Security kernel identifies application programs H(SKernel) is included in a signature by the processor –Security kernel includes H(App) in the signature H(Skernel), H(App) in a signature  A server can authenticate the processor, the security kernel, and the application Application (DistComp) Security Kernel H(SKernel) H(App)

26. 26 Off-Chip Memory Protection

27. 27 Microsoft Xbox Xbox is a Trusted PC Platform –All executables are digitally signed and verified before execution Trusted (encrypted) bootloader/OS prevents from –Using copied or imported games –Online game cheating –Using Xbox as a stock PC

28. 28 Inside Xbox: How was It Broken? Southbridge ASIC –Secure boot code –128-bit secret key Flash ROM –Encrypted Bootloader Broken by tapping bus –Read the 128-bit key –Cost about $50 From Andrew “Bunnie” Huang’s Webpage Bootloader/OSSecure boot RC4/128-bit key Observation - Adversary can easily read anything on off- chip bus

29. 29 Off-Chip Memory Protection Privacy Protection [MICRO36] –Encrypt private information on off-chip memory Integrity Verification [HPCA’03,MICRO36,IEEE S&P ’05] –Check if a value from external memory is the most recent value stored at the address by the processor Processor External Memory write read INTEGRITY VERIFICATION ENCRYPT / DECRYPT

30. 30 Previous Work (1): Use Message Authentication Code (MAC) Hash Function MAC Input Secret Key Hash Functions –Functions such as MD5 or SHA-1 –Given an output, hard to find what input produced it –Also, hard to find two inputs with the same output Message Authentication Code (MAC) can be seen as a keyed hash function –Only an entity with the correct key can generate a valid MAC –An entity with the correct key can verify the MAC

31. 31 Previous Work (1): MAC-based Integrity Verification Algorithm Store MAC(address, value) on writes, and check the MAC on reads (used by XOM architecture by David Lie) Does NOT work  Replay attacks Need to securely remember the off-chip memory state MAC Key Processor Untrusted RAM write read VERIFYVERIFY 124, MAC(0x45, 124) Address 0x45 120, MAC(0x45, 120) IGNORE

32. 32 Previous Work (2): Hash Trees (Merkle Trees) V1V1 V3V3 V4V4 L2 block Untrusted Memory Processor Data Values MISS V2V2 READ VERIFY h 1 =h(V 1.V 2 )h 2 =h(V 3.V 4 ) root = h(h 1.h 2 ) VERIFY Construct a hash tree On-chip Storage: 16-20 Bytes Read/Write Cost: logarithmic  10x slowdown

33. 33 cache Cached Hash Trees [HPCA’03] V1V1 V2V2 V3V3 V4V4 Untrusted Memory Processor cache MISS cache h 1 =h(V 1.V 2 )h 2 =h(V 3.V 4 ) root = h(h 1.h 2 ) VERIFY MISS VERIFY DONE!!! Cache hashes on-chip  On-chip cache is trusted  Stop checking earlier

34. 34 Hardware Implementation Issue [ISCA’05] What happens if a new block evicts a dirty one?  write-back If we cache all hashes … Each access can cause another read and a write-back  Need a large buffer Cache hashes only if we have buffer space available Untrusted Memory Processor CacheBuffer for IV Data A Hash K Data B Data C Hash J Hash I WRITE-BACK Hash J MISS Hash JData D READ UPDATE Parent Hash WRITE-BACK Hash KHash H READ Hash HData D Hash K Hash H

35. 35 Hiding Verification Latency Integrity verification takes at least 1 hash computation –SHA-1 has 80 rounds  80 cycles to compute Should we wait for integrity verification to complete? No need for precise integrity violation exceptions; they should never happen. If they do, we simply abort Memory verification can be performed in the background, so no latency is added except for instructions that can compromise security Load data load r0,(r1) addi r0,r0,#3 store (r1),r0 Integrity Verification Use data Store Result Exception?

36. 36 Simulated Performance Assume that the entire program and data protected If we add encryption, the overhead is 27% on average and 56% in the worst case L2 Caches with 64B blocks Worst case 50% degradation Most cases < 25% degradation Normalized Performance (IPC)

37. 37 Implementation

38. 38 Implementation Fully-functional system on an FPGA board [ICS’03][ISCA’05] –AEGIS (Virtex2 FPGA), Memory (256MB SDRAM), I/O (RS-232) –Based on openRISC 1200 (a simple 4-stage pipelined RISC) –AEGIS instructions are implemented as special traps Processor (FPGA) External Memory RS-232

39. 39 Area Estimate Synopsys DC with TSMC 0.18u lib New instructions and PUF add 30K gates, 2KB mem (1.12x larger) Off-chip protection adds 200K gates, 20KB memory (1.8x larger total) The area can be further optimized Core I-Cache (32KB) 0.512mm 2 1.815mm 2 D-Cache (32KB) 2.512mm 2 I/O (UART, SDRAM ctrl, debug unit) 0.258mm 2 IV Unit (5 SHA-1) 1.075mm 2 Encryption Unit (3 AES) 0.864mm 2 Cache (16KB) 1.050mm 2 0.086mm 2 Cache (4KB) 0.504mm 2 Code ROM (11KB) 0.138mm 2 Scratch Pad (2KB) 0.261mm 2 PUF 0.027mm 2

40. 40 EEMBC/SPEC Performance Performance overhead comes from off-chip protections 5 EEMBC kernels and 1 SPEC benchmark EEMBC kernels have negligible slowdown –Low cache miss-rate –Only ran 1 iteration SPEC twolf also has reasonable slowdown Benchmark Slowdown (%) Integrity Integrity + Privacy routelookup 0.00.3 ospf 0.23.3 autocor 0.11.6 conven 0.11.3 fbital 0.00.1 twolf (SPEC) 7.115.5

41. 41 Security Review Have we built a secure computing system? Flash Kernel SDRAM Secure - Verified using hashes Secure - Integrity verification and encryption With PUFs, attacks should be carried out while the processor is running - Probing on-chip memory - Side channels (address bus, power, electromagnetic fields)  Can be further secured using techniques from smartcards

42. 42 Related Projects XOM (eXecution Only Memory) –Stated goal: Protect integrity and privacy of code and data –Operating system is completely untrusted –Memory integrity checking does not prevent replay attacks –Privacy enforced for all code and data TCG TPM / Intel LaGrande / Microsoft NGSCB / ARM TrustZone –Protects from software attacks –Off-chip memory integrity and privacy are assumed AEGIS provides “higher security” with “smaller Trusted Computing Base (TCB)”

43. 43 Summary Physical attacks are becoming more prevalent –Untrusted owners, physically exposed devices –Requires secure hardware platform to trust remote computation The trusted computing base should be small to be secure and cheap –Hardware: single-chip secure processor Physical Random functions Memory protection mechanisms AMD and ARM currently evaluating PUF technology with a view toward building PUFs in CPUs

44. 44 Questions?

45. 45 Performance Slowdown Performance overhead comes from off-chip protections Synthetic benchmark –Reads 4MB array with a varying stride –Measures the slowdown for a varying cache miss-rate Slowdown is reasonable for realistic miss-rates –Less than 20% for integrity –5-10% additional for encryption D-Cache miss-rate Slowdown (%) Integrity Integrity + Privacy 6.25%3.88.3 12.5%18.925.6 25%31.540.5 50%62.180.3 100%130.0162.0

46. 46 Protecting Program States On-chip registers and caches –Security kernel handles context switches –Virtual memory permission checks in MMU Off-chip memory –Memory Encryption [MICRO36] Counter-mode encryption –Integrity Verification [HPCA’03,MICRO36,IEEE S&P ’05] Hash trees and Log-hash schemes Swapped pages in secondary storage –Security kernel encrypts and verifies the integrity

47. 47 A Simple Protection Model How should we apply the authentication and protection mechanisms? What to protect? –All instructions and data –Both integrity and privacy What to trust? –The entire program code –Any part of the code can read/write protected data Program Code (Instructions) Initialized Data (.rodata,.bss) Uninitialized Data (stack, heap) Memory Space Encrypted & Integrity Verified Hash  Program Identity

48. 48 What Is Wrong? Large Trusted Code Base –Difficult to verify to be bug-free –How can we trust shared libraries? Applications/functions have varying security requirements –Do all code and data need privacy? –Do I/O functions need to be protected?  Unnecessary performance and power overheads Architecture should provide flexibility so that software can choose the minimum required trust and protection

49. 49 Distributed Computation Example If Func(x) is a private computation –Needs both privacy and integrity Calling a signing system call to security kernel –Only needs integrity Receiving the input and sending the result (I/O) –No need for protection –No need to be trusted DistComp() { x = Receive(); result = Func(x); sig = sys_pksign(x,result); Send(result,sig); } Func(…) { … } Receive() { … } Send(…) { … }

50. 50 AEGIS Memory Protection Architecture provides five different memory regions –Applications choose how to use Static (read-only) –Integrity verified –Integrity verified & encrypted Dynamic (read-write) –Integrity verified –Integrity verified & encrypted Unprotected Only authenticate code in the verified regions Memory Space Static Verified Dynamic Encrypted Dynamic Verified Static Encrypted Unprotected Receive(), Send() Receive(), Send() data DistComp(), Func() DistComp() data Func() data

51. 51 Suspended Secure Processing (SSP) Two security levels within a process –Untrusted code such as Receive() and Send() should have less privilege Architecture ensures that SSP mode cannot tamper with secure processing –No permission for protected memory –Only resume secure processing at a specific point STD TE/PTR SSP Start-up Secure Modes Insecure (untrusted) Modes Compute Hash Suspend Resume