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

By Emmanuel Owusu, Jorge Guajardo, Jonathan McCune, Jim Newsome, Adrian

Perrig, and Amit VasudevanPresented by Ben Summers

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

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

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?

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

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

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

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

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.

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

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

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

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.

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.

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.

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

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

OASIS Functions and InstructionsFunctions 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.

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.

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 keypair using the two primes.

– RSA private key is encrypted.– Data store containing asym

keys and msg authentication code is returned.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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 Set extensions 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.

Questions?

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/im

ages/2/2e/Cloud_people.png• Finn and Jake fist bump – • https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbss4qm3OC1retsvlo

1_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/t

humbnail_54083.png• Finn Questioning –• http://www.8cn.tv/sites/default/files/dt1.png