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 Vasudevan
Presented 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 manin-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 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.
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 nonvolatile 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 timeintegrity
– 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. Coprocessor could be included to improve speed,
tighter control, and increased security.
Questions?
References:
•
•
•
•
•
•
•
•
•
•
•
•
•
Lich:
http://img3.wikia.nocookie.net/__cb20120912004917/adventuretimewithfinnandjake/images/4/4
8/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/2
e/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/UtiGhcmuSI/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