1. Architecture Support for Secure Computing Mikel Bezdek Chun Yee Yu CprE 585 Survey Project 12/10/04

2. Presentation Outline Motivation Assumptions Attacks Proposed Solutions Pending questions and future research

3. Motivation Currently piracy of software and digital media is a huge problem Attempts to solve with software solutions have proven easy to foil Adding support at the hardware level is a promising solution

4. Assumptions All solutions assume processor and on chip storage to be secure Operating system and all peripherals, including off chip memory, are untrusted Processor OS Memory I/O Devices

5. Points of Attack Because of untrusted memory attacks can occur on any transfers to or from external memory Because of untrusted OS, attacks could occur at context switches, when OS takes control of operation

6. Memory Attacks Adversaries may try to gain information from unprotected off chip memory by:  Modifying data Spoofing, Splicing, and Replay Attacks  Monitoring data access pattern (address bus)

7. Solutions Basic XOM architecture XOM using One Time Pad Encryption Hash Trees Aegis Processor HIDE Architecture

8. XOM (Execute-Only Memory) Tamper Resistant Software  Software is encrypted using symmetric encryption, its key is encrypted using asymmetric encryption Asymmetric Encryption - public key used by vendor, private key used by XOM chip Symmetric Encryption - the private key is unique to each program, also called the XOM ID Secured Computing  Enforces access restrictions using tagged and encrypted storage  Encrypted code execution using on-chip decryption

9. XOM Internal Security L2 Cache lines tagged with XOM ID with valid bits for each word in cache line L1 Cache lines are tagged with a XOM ID Registers are tagged with a XOM ID XOM ID is kept in a table in the XOM chip

10. XOM Context Switches Involves 4 special registers:  Data register - Data is packaged into movable (by the interrupting application), read-write protected data. A mutating key and XOM ID is used for packaging.  Hash registers (2) - 128 bit hash is made from the package, stored in two 64 bit registers  XOM ID register - storing XOM tag

11. XOM and External Memory Encrypts data with XOM ID and creates a hash (MAC) Message Authentication Code – a keyed one way hash, protects against spoofing and slicing attacks

12. XOM Performance Issues Optimizations:  Use a reversible CRC instead of MAC  Dedicated, pipelined DES encryption/decryption hardware. Max of 50% slowdown assuming a 48 cycle Triple DES implementation and 100 cycle memory access latency.

13. XOM with One-Time Pad Average XOM slowdown is 16.7% on SPEC 2000 benchmarks Around 30% slowdown on memory intensive programs One-Time Pad encryption can be used to remove encryption/decryption from critical path

14. XOM with OTP Proposed OTP solution  Cipher = plain  encrypted key (address + seq)  Plain = cipher  encrypted key (address + seq) key = XOM ID address = virtual address of data/instruction seq = mutating sequence number encrypted key (address + seq) is concurrent with memory access Encryption/decryption requires a one cycle XOR operation

15. XOM with OTP  Cipher = plain  encrypted key (address + seq)  Plain = cipher  encrypted key (address + seq) key = XOM ID address = virtual address of data/instruction seq = mutating sequence number

16. XOM with OTP Sequence Number Cache (SNC)  Stores sequence numbers for each cache line  Accessed by virtual address of cache line  Limited size Use replacement – store parts of SNC in unsecured memory No replacement – OTP on some data, can’t use OTP on rest of data

17. XOM with OTP Sequence Number Cache operation  Hits – sequence number is accessed and passed on to the encryption unit  Misses No replacement – default back to original XOM, where encryption is performed after memory access. Costs 100 + 50 cycles With replacement – fetch sequence number memory, then perform encryption

18. XOM with OTP SNC and Context Switching  Dump to memory with encryption  Tag SNC entries with XOM ID

19. XOM with OTP Performance  16.7% XOM average slowdown  4.59% XOM w/ OTP – No Replacement  1.28% XOM w/ OTP – With Replacement 1.035% max additional memory traffic

20. Hash Trees Memory Integrity Verification  Allows the secure processor to ensure that the data it reads from memory matches the data most recently written Protection  Spoofing  Splicing  Replay

21. Hash Tree - Details Works by calculating a hash of data Hash is easy to compute given data, but hard to find data which will result in an equivalent hash Data HHHHHHHH HHHH H HH Secure

22. Hash Tree - Details Calculated when accessing memory  No need to calculate hash for a cache hit Data can be given speculatively to the processor while hash is generated and checked Speculative commits  Allowed using fetched but unverified data  Exception raised by hash checker does not need to be recovered from Stalls on hash checker when using processor’s secret key Simulations done show that with caching of hashes an average overhead of less than 20% can be achieved

23. Aegis Architecture Uses concepts from XOM and hash trees to create a “private and authenticated tamper-resistant environment” for the processor to run in This means that data is private from any observers and that any tampering will be detected

24. Aegis Architecture Allows a user to trust the results from a program  System Authentication  Program Authentication  Message Authentication This is accomplished by the sign_msg instruction, which encrypts a message and a hash of the program with the processor’s secret key before sending back to the user

25. Aegis Architecture To provide environment, 3 key things must be done  Memory Integrity Verification  Encryption/Decryption of off-chip memory  Context Switches managed securely

26. Aegis – Memory Integrity Verification Accomplished using hash trees Introduces new twist on hash trees, log hash In log hash, only memory accesses leading up to a sign_msg instruction are verified Greatly reduces cost of verification while not sacrificing much security

27. Aegis – Off chip memory Data stored in the off chip memory is encrypted and decrypted using the one time pad xom scheme to hide latency Pads are generated using the address of the data combined with a time stamp, incremented at every write-back Time stamps are needed before calculation of pad can begin, so caching of timestamps is a good idea

28. Aegis – secure context switches Uses a Secure Context Manager Maintains a table of all processes Table entry contains: secure process ID (SPID), program hash, register values, and hash for off- chip memory verification Table stored in memory, but can be cached for recent processes In addition, cache entries are tagged with SPID to ensure a process cannot gain access to another process’s data

29. Aegis - Overhead Overhead of SCM in negligible, main slow down comes from integrity verification and encryption of memory Using l-hashes and OTP encryption, authors were able to see an average overhead of < 25%, with a worst case of 55% of tested benchmarks

30. HIDE - Motivation Addresses the problem of secure information leaking due to monitoring of the address bus Access patterns reveal information about branching  Can be compared with known branching patterns to identify IP reused in secure process

31. HIDE – Critical Idea Addresses from the processor are remapped before being sent to memory Mapping is done using a permutation function to ensure a random mapping Current mapping (permutation vector) must be stored on chip

32. HIDE - Implementation To ensure that attackers cannot see patterns in memory accesses, each access from a current pv must happen once Implemented with locking cache blocks

33. HIDE – Hide Cache Modified L2 cache Cache hits (R and W) unmodified When a block is loaded on a cache miss, it is locked A locked block cannot be replaced When all blocks are locked, permutation must be done, which unlocks all blocks

34. HIDE – Permutation Steps A new pv is created mapping set of all current memory addresses to new addresses Blocks are loaded sequentially from memory and stored in their new location (pv[i]) in an on- chip buffer Buffer is written back sequentially to memory If on-chip buffer size S is less then memory size, M, process must be repeated M/S times

35. HIDE - Improvements Since permutation is a lengthy operation, don’t want to wait until all cache blocks are locked Idea of pre-permutation – start permutation when half of cache blocks are locked

36. HIDE - Improvements Instead of permuting entire memory at once, permute chunks at a time Chunk size is one or more pages Memory accesses within a chunk preserve security, only accesses across chunks leak information. Reduce by:  Larger chunk size  Store code to minimize inter-chunk access Requires maintaining info about each page

37. HIDE - Results Simulated using super scalar on SPEC2K benchmarks Average slowdown was only 1.3% Memory bandwidth used was on average 9% of total

38. HIDE - Conclusions Provides high level of security without imposing must loss in performance Requires slight modification to L2 cache, addition of permutation hardware Will not work for multiprocessor systems, since the pv and locking info must be communicated on unsecured bus

39. In Summary Supporting software security with hardware is a developing field Assumes basic model of secure processor with private half of public-private key pair XOM with OTP keeps memory private, hashes ensure memory is tamper free, and permutation scheme can be used to secure address bus When combined, allows users to trust results from a secure processor and software developers to create copy-proof software

40. Pending Questions Will users accept performance losses in order to gain security Will vendors support secure processing Problems relating to secret (private) key stored on processor