1. Architectural Support for Copy and Tamper Resistant Software David Lie, Chandu Thekkath, Mark Mitchell, Patrick Lincoln, Dan Boneh, John Mitchell and Mark Horowitz Computer Systems Laboratory Stanford University Reference: http://www-vlsi.stanford.edu/~lie/Papers/xom-oakland-2002.pdf

2. XOM uXOM: eXecute Only Memory uProtect programs from copying and tampering Prevent software theft –Mark software for specific machine Guarantee pay-per-use –Program contains usage meter –Program sends payment to distributor –Cannot proceed until receipt is received Fraud detection in embedded apps –Cell phone id, etc. Software Distributor Customer Program XOM Compartment

3. Software Distribution Method DistributorCustomer Customer wishes to purchase software Customer sends public key Encrypted Code Randomly Selected Symmetric Key Program Code Encrypted Code Symmetric key is encrypted with public key Customer receives encrypted code with encrypted key Encrypt Program

4. Loading Secure Code Executable Code Encrypted Symmetric Key Encrypted Code Symmetric Decryption Module Decrypted Symmetric Key (Session Key) Private Key Secure Execution Engine Secure XOM Machine Insecure Main Memory XOM Key Table Asymmetric Decryption Module

5. A Simple XOM Machine

6. Two problems uMemory is insecure All sensitive program data must fit in registers Too restrictive a programming model uPrograms can’t read or write data that doesn’t belong to them But OS needs to do this when doing a context switch uUse encryption to solve both problems Same technique used to protect sensitive code

7. Supporting Main Memory store_secure instruction Data To Insecure Main Memory Tag Encrypt Data before storing in memory Currently executing XOM ID Check that the currently executing XOM ID matches the tag XOM Key Table

8. Supporting Main Memory load_secure instruction Data From Insecure Main Memory Tag Currently executing XOM ID Target register tag is set to XOM ID Decrypt Data XOM Key Table

9. Supporting Interrupts save_secure instruction Data To Insecure Main Memory Tag Currently executing XOM ID Look up session key based on Tag Encrypt Data XOM Key Table

10. Supporting Interrupts restore_secure instruction Data From Insecure Main Memory Tag Currently executing XOM ID Decrypt Data XOM Key Table Executing Program indicates which XOM ID to use Target register tag is set to XOM ID

11. Spoofing Attacks uSpoofing attack: Adversary tries to substitute fake ciphertext to alter behavior uTags are able to catch spoofed attacks because tag ID changes uEncryption alone is not sufficient for memory Data Adversary swaps data DataFalse Data Encrypt and store to memory Junk Decrypts to Junk but alters program behavior

12. Spoofing Prevention uSolution is to add an integrity hash to the encryption Message Authentication Code (MAC) Data Adversary swaps data False Data Encrypt and store to memory with added hash Hash does not match data so exception is thrown !

13. Splicing Attacks and Replay Attacks uSplicing Attacks Attacker moves valid data from one location to another location Add position dependent hash: –Virtual Address for secure load/stores –Register number for secure save/restores uReplay Attacks Attack records and reuses old register and memory values Add a regenerative key to Key Table that is used for save/restores Use protected registers to protect memory values

14. Required Hardware Micro-code or Virtual Machine for control

15. XOM Provides Isolation Secure XOM Machine Compartments Ownership Tags Program 2 Tag 2Data Register 2 ???Data Register 3 Program 1 Tag 1Data Register 1 Tag 2Data Register 3 Tag 1Data Register 3 Program 1 Tag 1Data Register 1 !

16. Performance Issues uPerformance hit is going to come from the cryptographic operations XOM start-up Instruction load path from memory Data loads and stores to and from memory Register saves and restores to and from memory uThe accesses to memory occur the most often uWe want to speed up the symmetric and hashing operations, as well as optimize access to memory

17. Additional Hardware uCache decrypted data Add tags to caches uSpeed up symmetric operations Add special symmetric cryptography hardware uSpeed up hash calculation Select a fast hash calculation such as 128 bit CRC

18. Full XOM Machine

19. XOM architecture Summary uImplement compartments with architectural support uTrust only the processor; assume memory, OS are insecure uUse: Data tagging on-chip Crypto off-chip uRequired hardware is modest Private Memory and Key XOM Tags on registers uAdditional hardware can be added to improve performance Symmetric hardware XOM Tags in caches

20. Model Checking XOM uXOM Model is a state machine: State Vector –A set of all things on the chip that can hold state –Based on the Processor Hardware Next-State Functions –A set of state transitions that the hardware can have –Derived from the instructions that can be executed on the processor Invariants –Define the correct operation of the XOM processor –Two Goals: Prevent observation and modification

21. XOM Processor Hardware Cache Register File XOM Tags Crypto Units Plain Text in Processor Encrypted Text in Memory Memory DataHash

22. Modeling XOM uDefining the state space: Hardware units are modeled as arrays of elements Number of elements is scaled down u3 Registers: u3 Cache Lines: u3 Memory Words: DataTag r i = {Data, Tag, Key, Hash} DataTag c j = {Data, Addr, Tag} Addr Tag Data m k = {Data, Hash, Key} KeyHash

23. XOM User Instructions InstructionDescription Register UseReading a register Register DefineWriting a register StoreStore data to memory LoadLoad data from memory

24. XOM Kernel Instructions uWe assume an adversarial operating system Operating system can execute user instructions and privileged kernel instructions InstructionDescription Register SaveEncrypt a user register for saving Register RestoreDecrypt a user register for restore Prefetch CacheMove data from memory into the cache Write CacheOverwrite data in the caches Flush CacheFlush a cache line into memory TrapInterrupt User Return from TrapReturn execution to User

25. State Transitions uState Transitions derived from instruction set User has access to user level instructions Adversary has access to kernel level instructions  Example: Store r i  m j if r i.tag = user then reset else if j is in cache then c k = {data = r i.data, addr = j, tag = r i.tag} else pick a free c c free = {data = r i.data, addr = j, tag = r i.tag}

26. No Observation Invariant 1.Program data cannot be read by adversary XOM machine performs tag check on every access Make sure that owner of data always matches the tag if r i.data is user data then check that: r i.tag = user else check that: r i.tag = adversary Adversary DataAdversary Tag User DataUser Tag

27. No Modification Invariant 2.Adversary cannot modify the program without detection Adversary may modify state by copying or moving user data Need a “ideal” correct model to check against For Memory: if xom.m i.data = user data then check that: ideal.m i.data = xom.m i.data Adversary Program XOM Model Ideal Model =

28. Checking for Correctness uModel checker helped us find bugs and correct them 2 old errors were found 2 new errors were found and corrected uExample: Case where it’s possible to replay a memory location This was due to the write to memory and hash of the memory location not being atomic

29. Memory Replay uOptimization 1: Only update hash on cache write-back On-chip cache is protected by tags PrincipalAction$MHash Program Writes A into Cache A--H =  MachineFlushes Cache--AH = h(A) ProgramWrites B into CacheBAH = h(A) AdversaryInvalidates Cache--AH = h(A) ProgramReads Memory--AH = h(A) Fix by making write and hash calculation atomic!

30. Reducing Complexity uFewer operations makes logic simpler uExhaustively remove actions from the next-state functions If a removed action does not result in a violation of an invariant then the action is extraneous Example: DataTag Secure Load: Tag and Data is copied from cache Tag Check: Make sure the tag matches the user DataTag CachesRegisters Register Use: Check that tag matches user Check Happens Anyways!

31. Liveness uA weak form of forward progress guarantee: At all times operating system or user can always execute an instruction All instructions can be executed somewhere in the state space uConstrain the operating system so that: 1.Operating system always restores user state 2.Operating system does not overwrite user data uCheck that within the state-space: 1.User is never halted due to access violation 2.User and operating system are able to execute every instruction

32. Conclusions uModel Checkers are an effective tool for verifying security of processors Hardware blocks define state vector Instructions define next-state functions uCan be used to verify: Tamper-resistance by checking consistency between an “ideal” model and “actual” model Minimal Complexity by checking that every action is necessary for correctness Liveness by making the adversary cooperative and showing that both are always able to execute actions