Implementing an Untrusted Operating System on Trusted Hardware

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

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

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

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

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

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

The Original XOM Architecture Master secret is used to support

compartments Each is immune to modification and observation

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

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

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

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

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

Implementing Compartments (6)

secure store, secure load For non-NULL compartments

move from NULL, move to NULL

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

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

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

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

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

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

Handling Program State (6)

Incorrectly written program can still leak secrets

XOM assures that correct programs can secure their secrets

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

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

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

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

XOM Key Table System Calls (2) Similarly for exit xom

xinval Privileged Mark the register key entry invalid

xexit Return to the NULL compartment

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

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

Shared Libraries

Unencrypted for dynamic linking by various applications

Libraries that perform security sensitive routines should be statically linked and encrypted OpenSSL

Process Creation

Need xom_fork() Create two sets of register keys Share the same compartment key

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

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

Implementation Effort

Added 1,900 lines to the IRIX 6.5 Ran applications in the SimOS simulator

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

Operating System Overhead

Larger memory footprint Additional I/O for storing and retrieving

hashes

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

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…