Implementing an Untrusted Operating System on Trusted Hardware
-
Upload
august-schmidt -
Category
Documents
-
view
26 -
download
4
description
Transcript of Implementing an Untrusted Operating System on Trusted Hardware
![Page 1: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/1.jpg)
Implementing an Untrusted Operating System on Trusted Hardware
![Page 2: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/2.jpg)
Introduction
Tamper-resistant software Combat piracy Mobile code
However, SW-based solutions are easier to attack than HW-based solutions
To implement tamper-resistant hardware Challenge: use untrusted OS to manage trusted
HW
![Page 3: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/3.jpg)
XOM: eXecute Only Memory
HW support for tamper-resistant software Does not trust OS and memory content Many design implications
Time-slicing Process forking User-level signal handling
Prototyped via SimOS
![Page 4: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/4.jpg)
The XOM Trust Model
Protect against attackers who have physical access to the HW
Does not trust OS OS performs only resource management Only can perform denial-of-service attacks against
its applications Does not trust main memory
Values stored in memory are encrypted, along with their hashes of values and virtual addresses
![Page 5: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/5.jpg)
Implications of the XOM Trust Model XOM prevents programs from tampering with
each other by placing them in separate compartments Enforced by HW data tagging and cryptography
OS runs in a separate compartment OS should be able to manage resources without
having to interpret data values in transit OS cannot read or modify process data
![Page 6: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/6.jpg)
Related Work
Secure booting CPU has a tamper-resistant secret Used to authenticate the next layer (e.g.,
firmware) Which in turn authenticates the next layer
XOM trusts neither OS nor memory OS bugs cannot undermine the security of
applications running on it XOM can detect tampering of code or data at all
times
![Page 7: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/7.jpg)
The Original XOM Architecture XOM uses tamper-resistant HW to protect a
master secret that is unique for each processor Which is used to encrypt keys that encrypt various
software All operations that use the master secret must be
implemented on processor
![Page 8: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/8.jpg)
The Original XOM Architecture Master secret is used to support
compartments Each is immune to modification and observation
![Page 9: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/9.jpg)
Implementing Compartments (1) Use cryptography to implement
compartments XOM HW holds the private key Each compartment uses XOM’s public key to
encrypt its compartment key Which is used to encrypt the compartment content Compartment keys are stored in an encrypted
program
![Page 10: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/10.jpg)
Implementing Compartments (2) Implications on SW distributions
A distributor must encrypt its software key with the public key of a XOM processor
Occurs when a user registers the software Data generated by a program are isolated in
its compartment Data are encrypted when they leave the CPU
chip Cached data are stored in plain text
![Page 11: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/11.jpg)
Implementing Compartments (3) XOM Key Table
Maps compartment keys and ownerships If a piece of data is encrypted, it’s in a
compartment NULL compartment
Not encrypted Insecure data sharing among programs
![Page 12: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/12.jpg)
Implementing Compartments (4) To protect against tampering of data in
memory Use cryptographic hash to verify data integrity A hash is generated each time a cache line is
written to memory (a function of the cache line and its address)
Both hash and the cache lines are encrypted
![Page 13: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/13.jpg)
Implementing Compartments (5) New XOM HW instructions are introduced
enter xom Decrypt the compartment key Enter the key into the XOM Key Table All instructions following enter xom must be decrypted
before execution exit xom
Compartment key to be unloaded from the XOM Key Table
Return to the NULL compartment
![Page 14: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/14.jpg)
Implementing Compartments (6)
secure store, secure load For non-NULL compartments
move from NULL, move to NULL
![Page 15: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/15.jpg)
Implementing Compartments (7)
Encrypted Symmetric
Key
Encrypted Code (sym)
ExecutableCode
Symmetric Decryption
Module
XOM Processor
Main Memory
UnencryptedCode
Enter XOMExit XOM
Private Key
XOM Key Table
Asymmetric Decryption
Module Currently executing XOM ID and Key
![Page 16: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/16.jpg)
Handling Program State (1)
Since OS cannot access registers tagged by other compartments Need a new way to save and restore contexts
New XOM instructions save register
Encrypt the register Create a hash of the register Store both to memory
![Page 17: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/17.jpg)
Handling Program State (2)
Data Tag
OS XOM ID
Look up program
key based on Tag
XOM Key Table
Encrypt Data
Data Store encrypted data and hash to
memory
Hash
![Page 18: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/18.jpg)
Handling Program State (3)
restore register Takes an encrypted register value and hash Verifies the hash Restores them back to the original register, setting their
ownership tags appropriately
To prevent the OS from replaying encrypted register values/hashes Revoke the register key used to encrypt and hash
register values each time a XOM compartment is interrupted
![Page 19: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/19.jpg)
Handling Program State (4)
To protect memory from replay attacks Store a hash of memory in a register
XOM currently rely on applications to track memory hashes Otherwise, too expensive in terms of performance
(25%) Each virtual address needs a hash tree Virtual to physical address mapping maintained
by OS XOM needs to interact with OS closely
![Page 20: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/20.jpg)
Handling Program State (5)
Data Tag
Registers Caches Memory
Data Tag
Secure Store: Tag is copied from register
to cache
XOM Key Table
Writeback: Look up Tag, Encrypt and
Hash
Data
Hash
Relocate data and hashes together
![Page 21: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/21.jpg)
Handling Program State (6)
Incorrectly written program can still leak secrets
XOM assures that correct programs can secure their secrets
![Page 22: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/22.jpg)
Supporting an Operating System (1) Requirements
Good OS should be able to manage resources efficiently
Bad OS cannot violate the isolation of a compartment
An OS must adhere to XOM compartments when moving resources Need to use XOM instructions
![Page 23: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/23.jpg)
Supporting an Operating System (2) XOM limitations
External debugging impossible Shared memory and IPCs have to go through the
NULL compartment They need to be secured through separate mechanisms
![Page 24: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/24.jpg)
XOM Key Table System Calls (1) enter xom and exit xom insufficient when
frequently called Encryption/decryption everytime If enter xom is privileged, a program has to cross
the kernel boundary every time If enter xom is not privileged, a malicious
application can allocate all key entries to deny services
![Page 25: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/25.jpg)
XOM Key Table System Calls (2) enter xom is splitted into multiple calls
xalloc Privileged Allocate a register key
xentr Not privileged Enter a compartment
![Page 26: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/26.jpg)
XOM Key Table System Calls (2) Similarly for exit xom
xinval Privileged Mark the register key entry invalid
xexit Return to the NULL compartment
![Page 27: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/27.jpg)
Saving and Restoring Context An OS needs xgetid to decrypt the ownership
of a cache line Exception frame must be enlarged to
accommodate additional XOM and encrypted states
Certain things are revealed to the OS TLB misses Status bits that indicate whether a thread is in
kernel mode
![Page 28: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/28.jpg)
Paging Encrypted Pages
Hashes are stored separately A bad OS needs to forge both data and the
corresponding hash Hashes are paged in and out with the
corresponding data
![Page 29: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/29.jpg)
Shared Libraries
Unencrypted for dynamic linking by various applications
Libraries that perform security sensitive routines should be statically linked and encrypted OpenSSL
![Page 30: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/30.jpg)
Process Creation
Need xom_fork() Create two sets of register keys Share the same compartment key
![Page 31: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/31.jpg)
Process Creation
Process
XOM ID
Process
Pre-fork:Allocate a new
XOM Key Table Entry
XOM ID XOM ID
Child
Parent
Fork: Child uses one XOM ID, the Parent uses other
XOM ID
XOM ID
![Page 32: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/32.jpg)
User Defined Signal Handlers Need to enlarge the signal context field for
encrypted data Signal key must be refreshed at each call to
avoid replay attacks by an OS
![Page 33: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/33.jpg)
Implementation Effort
Added 1,900 lines to the IRIX 6.5 Ran applications in the SimOS simulator
![Page 34: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/34.jpg)
Basic Processor Model Parameters Encryption added 15 cycles to the memory
access time On cache misses and flushes
xalloc required 400,000 cycles to perform public key decryption
![Page 35: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/35.jpg)
Operating System Overhead
Larger memory footprint Additional I/O for storing and retrieving
hashes
![Page 36: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/36.jpg)
End-to-End Application Overhead Turns out that granularity has little impact on
performance overhead! Overheads for most applications turn out to
be less than 5% If cache behavior is similar
![Page 37: Implementing an Untrusted Operating System on Trusted Hardware](https://reader035.fdocuments.us/reader035/viewer/2022070402/56813866550346895da01607/html5/thumbnails/37.jpg)
Questions….
What if the CPU is dead? And you want to move a hard drive to another
machine? Backups are useless unless the original
private key is also duplicated.…in hardware…