OASIS: On Achieving a Sanctuary for Integrity and Secrecy on Untrusted Platforms

1. OASIS: On Achieving a Sanctuary for Integrity and Secrecy on Untrusted Platforms By Emmanuel Owusu, Jorge Guajardo, Jonathan McCune, Jim Newsome, Adrian Perrig, and AmitVasudevan Presented by Ben Summers

2. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

3. Introduction • Recent attacks on TCG (Trusted Computing Groups) have not spurred secure execution environments. • Lack of end-to-end app. Software that benefit from TCG • Lack of trust in TPM (Trusted Platform Module) vendors • Lack of protection against local adversaries • Concerns over poor performance

4. Introduction (Cont.) • Isolated Execution Environment (IEE) have been proposed but a question is posed: • What minimal additions must be made to achieve highly efficient isolated execution environments with remote attestation properties? PROBLEM: How can we design an IEE for untrusted platforms that is inexpensive, secure, and easy to adopt and deploy on current systems?

5. Deployment Model • Three parties with different roles and levels of trust • Hardware manufacturers (HWM) – Trusted to manufacture CPU to initialize the CPU with a Physically Unclonable Function • Service Provider (P) that offers a device as a platform to customers who wish to lease them • User (or cloud customer) (V) who wishes to lease • interested in verifying trustworthiness of devices

6. Adversary Model • Can introduce malware into platform, has access to external ports. • Probe and tamper with low-speed and high-speed buses. • Cannot perform attacks that require scrutinized access for long periods. • Assume that the CPU on P is not malicious and is tamper resistant

7. Desired Properties of OASIS • Secure • Externally Verifiable • Key Code Binding – unique key to isolated environment • Program State Binding – data to code • Device Transferability – ownership of chip switch without leakage • Limited trust – HWM should not have access to device secrets • Economical • Low-cost – no substantial increase of cost • Self-contained – no additional hardware • Essential • Minimal TCB – trustworthy computing primitives entirely within CPU • Minimal Interface – Minimal controls which present a usable abstraction • Minimal Setup – Expensive operations are bypassed during repeated invocation

8. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

9. Hardware Building Blocks - PUFS • Physical Unclonable Function (PUF) – functions where relationship between input (challenge) and output (response) is defined via a physical system. • Unclonability originates from random variations in a device’s manufacturing process • In applications where PUF response is used as a key, algorithms known as fuzzy extractors leverage non-secret data to work around noisy nature of PUFs.

10. PUF Keys The PUF embedded in the IC generates a response. If the response matches the one stored in the secure database, the IC is authentic. To prevent man-in-the-middle attacks, each challenge and response pair is used only once. Source: http://studiopresence.com/client/verayo/technology

11. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

12. OASIS CPU Instruction Set • OASIS is a set of new CPU Instructions that enable an IEE contained entirely on chip by leveraging CAR (Cache-as-RAM) mode execution and by creating a secret key only available to the CPU. • Advantages: • Static RAM (SRAM) is already available on CPUs in the form of cache • SRAM PUFs need to be powered to generate secret keys so they are resistant to offline attacks • Tamper-evident • Decreased cost of production

13. Root of Trust • Key material is unique per physical device and per device owner • Device owner derives a key unique to themselves and the device via a key derivation function. This master processor secret can be used to derive symmetric keys. • All keys are stored inside the CPU in a set of special purpose cache registers which are only available within the OASIS environment and only by OASIS instructions. • Key hierarchy is based on an owner seed, enabling personalization and device transferability.

14. ISE Overview and Flow – Stage 1 • Three stages in life cycle of CPU • After manufacture, HWM initializes master process by calling init – outputting helper data and a hash to anyone using the device. • Init can only be called once or limited times to prevent attacks. It enables the limited trust, low cost, self-contained, and minimal TCB properties we desire.

15. ISE Overview and Flow – Stage 2 • Setup of key hierarchy for OASIS performed by device owner • Create is called – derive symmetric- and asymmetric keys. • Keys are used to exchange confidential and authentication messages. Main output is a public key and a secret seed. • Seed allows for transferability.

16. ISE Overview and Flow – Stage 3 • Execution of code on the device by the user by issuing launch. • Populates the CR registers with keys derived from the PUF helper data (stage 1), Seed (stage 2) and public key (stage 2). • Unbind checks integrity. Asymmetric option is used first time to transmit secret key known only to user. • Code is executed in IEE, state is saved and integrity computed using bind. • OASIS cleared out and control returned to OS

17. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

18. OASIS Functions and Instructions Functions are internally available to instructions and instructions are externally available for call by executing software. f_read_PUF simply outputs the raw PUF response. f_init_PUF accepts a raw PUF response and a random value, and outputs helper data and hash. f_fuzzy_extract_PUF outputs a uniformly random value to be used as a key.Can also check for correctness of key. If key is wrong, OASIS clears all registers and aborts execution.

19. OASIS Function 1 • Loads the helper params and hash into memory. • PUF is read and fuzzy extractor invoked to generate sym secret key. • Checks whether input and generated key match reconstructed value. • The sym secret key and seed are used to derive Master processor secret. • Key is used for four things: • Platform binding secret • Authenticating data residing in untrusted storage • Encrypting data • Used to derive code-specific keys.

20. OASIS Function 2 • Generates the processor asym keys. • Picks a random seed value and begins search until prime is found. Repeated for second prime. • Generates a keypairusing the two primes. • RSA private key is encrypted. • Data store containing asym keys and msg authentication code is returned.

21. OASIS Function 2b • Alternative way to create asym keys. • More efficient since there is no prime search. • Small area overhead, if support for asym operations is at hardware level. • Increase in time to perform signature verification operation.

22. OASIS Function 3 • Checks tag to ensure that input data has not been tampered with. • If the verification passes, the function decrypts the private binding to key, using the sym key.

23. OASIS Instruction 1 • Uses helper data to denoise raw SRAM PUF value. • f_read_PUF and f_init_PUF read the raw PUF value and instantiate the helper data. • Hardware-generated random number is used to introduce entropy in the resulting helper data’s value. • Rand must be secret, helper can only be set once (or limited) and fuzzy extractors do not require any secure non-volatile memory

24. OASIS Instruction 2 • Generates a hierarchy of crypto keys from raw PUF response and creates sym and asym keys. • Encrypted authentication information which is verified internally by OASIS using a key derived from PUF and seed is attached to the asym keys generated. • Performed when device changes ownership or if a user desires to setup the environment for future use.

25. OASIS Instruction 3 • The launch instruction is designed to setup the OASIS environment for code C and populate all necessary registers. • Sets up a clean-slate CAR environment, including disabling interrupts and hardware debugging access. • It reads and loads registers with crypto key material for further processing and other instruction. • If we want to make public binding key available outside, Instruction 2 must be called first. • Does not verify the signature every time it executes where Instruction 2 does. • Launch stores a hash and a sym key is generated. Sym key is used for encrypting and authenticating the executing code’s state for local storage.

26. OASIS Instruction 4 • Unbind assures that the inputs will only be released to the code with measurement PCR_ver. • Sym keys should be used for bulk encryption operations and public binding key for storing bulk encryption key. • Must carefully pick an asym encryption scheme to prevent attacker from using ciphertext– encryption scheme must be non-malleable; i.e., an attacker cannot use one ciphertext to generate a second ciphertext.

27. OASIS Instruction 5 • Bind instruction prepares data for transfer to untrusted code. Should be called by executing code before returning. • Ciphertext are stored in local memory and sent to verifier. • Bind enable program code C updates – checks whether the updated has been encrypted and authenticated with shared secret. • This clears out the registers of OASIS.

28. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

29. Secure Remote Execution Step 1 – Verifier (V) initiates an isolated execution session with the platform. V generates an encrypt key and binds hash with key – enables the V to encrypt using public part of the platform key while ensuring that the only correct code running in execution env can access the data. Step 2 – OS calls the hardware instruction launch using food, the verifier input V.inp and previously stored state. Step 3 – IEE first checks inputs. Releases shared encryption key using unbind and decrypts any private inputs. Application code is executed. Steps 4 & 5 – parameters released to OS and verifier. Step 5 provides evidence to the verifier that the computation was performed and not manipulated by OASIS.

30. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion - Limitations • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

31. Discussion – Linkable Code Blocks • For applications greater than the cache, a hash tree is computed and the tree’s root value is bound to the application state. • Hash tree extends state protection and load time-integrity • Small TCB (trusted computing base) • Efficient execution because code bloc may be safely executed before entire application has been hashed.

32. Discussion – Rollback Prevention • Rollback attack is when an old state is presented to the IEE. Since stale state is consistent, an IEE without rollback prevention will incorrectly accept it. • Suggestions: • Protected monotonic counter as part of the state. • Trusted summary of the expected state • Include a summary state (hash) • Unbind is invoked to decrypt any state belonging to code C. After execution, bind instruction is invoked to protect state, which contains a summary of current state. The verifier includes the state summary as input during the next invocation. If the state matches, the code executes.

33. Discussion – Distributed Deployment • Rollback is insufficient if multiple verifiers collaborate through remote service provider. • A compromised OS can launch forking attacks by concealing the operations of one verifier from another. • For consistency ensures all verifiers see the same operations log before an omission but no verifier can see any other verifiers operations.

34. Discussion – Device Transferability • Device owner selects seed value “S” during key generation. Seed enables derivation of owner-specific processor keys. • Customization precludes previous device owners. Secrets linked to the hardware are derived from an identity seed – a master signing key is derived from root secret and identity seed S. • The device generates a fresh seed value and computes a MAC address over it using a key derived from the root and identity. This ensures that chosen values of S cannot be correlated with a response.

35. Outline • Introduction • Hardware Building Blocks • Oasis CPU Instruction Set • Oasis Functions and Instructions • Secure Remote Execution • Discussion • Linkable Code Blocks • Rollback Prevention • Distributed Deployment • Device Transferability • Performance • Conclusion

36. Performance • OASIS init is 800+ times faster than DRTM key generation. • OASIS Create is 10 times faster than DRTM’s parallel function. • OASIS Launch and Unbind with encrypted input is 100+ times faster than DRTM’s seal and unseal functions the first time it is called and 3 times faster for repeated invocations. • Benefits from running on processor core instead of a TPM--avoids costly overheads by implementing crypto on a chip, and provides remote attestation, binding, and sealing capabilities.

37. Related Work • SMART is similar to OASIS as it establishes a root of trust in remote devices – OASIS uses high-end processors instead of remote embedded devices. • TEE (Trusted Execution Environment) provides capabilities for isolated execution and verification. OASIS uses a CAR mode to support applications of a much larger size. • Memory cloaking, which provides secrecy and integrity of application data by limiting the OS’s access to ciphertext, is used by SecureMe – OASIS suspends OS for forced isolation / manufacturer and device owner both contribute for root of trust. • AEGIS also uses PUFs but consigns security-sensitive OS functionality to another kernel – OASIS uses PUFs to encrypt and has a smaller TCB.

38. Conclusion • OASIS offers a stronger degree of protection from most TPM-based solutions through highly efficient isolate and no hardware dependencies outside the CPU. • Further work: Intel Instruction Setextensions can be modified to provide high-security assurance at low cost in terms of platform security. Co-processor could be included to improve speed, tighter control, and increased security.

39. Questions?

40. References: • Lich: http://img3.wikia.nocookie.net/__cb20120912004917/adventuretimewithfinnandjake/images/4/48/The_Lich_King.png • Cloud Kingdom • http://adventuretime.wikia.com/wiki/Cloud_Kingdom?file=Bg_s1e9_clouds.png • Cloud People • http://img1.wikia.nocookie.net/__cb20120723064928/adventuretimewithfinnandjake/images/2/2e/Cloud_people.png • Finn and Jake fist bump – • https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbss4qm3OC1retsvlo1_500.gif • BMO happy - https://4.bp.blogspot.com/-1n4V2XLqyTk/UtiGh-cmuSI/AAAAAAAAASk/aSrH4M2r260/s1600/Bmo_with_tutorial_by_pianogirl613-d5d3xvb.png • BMO insides - http://img2.wikia.nocookie.net/__cb20130726015033/adventuretimewithfinnandjake/images/2/2f/S5e28_BMO%27s_innards.png • BMO and GINO – • http://i.cdn.turner.com/toon/video/repository/8a250ab02578da2201257a603d960035/thumbnail_54083.png • Finn Questioning – • http://www.8cn.tv/sites/default/files/dt1.png