David Lie

Overview

XOM stands for eXecute Only Memory.   It is an idea that grew out of the desire to create copy and tamper resistant software that would exist in a kind of memory that could not be read or modified, but   only executed.  There have been many attempts to create copy and tamper resistant software in the past and all have failed to achieve their overall goals.   The problem is that software only solutions are inherently inadequate simply because by having a machine be able to execute the software, it means the software can be read and understood.  XOM tries to achieve copy and tamper resistance by adding a small amount of hardware support to modern general purpose processors.  The goal is to devise the kind of hardware and software modifications necessary to achieve copy and tamper resistance, while noting the tradeoffs with complexity and performance.

High Level System Description

This is a high level description of how a XOM executable is run on a XOM machine.   Every XOM processor has a public/private key pair.  The private key is kept in hardware and known only to the processor, not to the owner of the processor or anyone else.  The public key is available to the owner.  When XOM software is purchased, the software is encrypted with a symmetric key and the symmetric key is encrypted with the public key of the processor that belongs to the purchasing party.

The executable is decrypted by the machine just before execution and the unencrypted version never leaves the processor chip.  Data is also likewise protected, either by tagging when it is on the processor chip, or encryption when it is stored in memory.   A full XOM machine would have hardware to support fast encryption and decryption from memory, tags on architecturally accessible registers. as well as storage space for the decrypted symmetric keys and the private key.

Security

XOM makes several strong security guarantees.  First it can protect applications from tampering and observations in spite of a malicious operating system.   It does this by giving each program a unique tag that is associated with the key used to decrypt the program's code.  In this way, the operating system can never read data or registers that is tagged with another program's ID.

However, there's a problem!  The operating system has to be able to manage resources.  This means the operating system has to be able to pre-empt programs and save their state -- meaning it has to be able to access registers of the interrupted program.  To solve this, the XOM machine allows the operating system to copy and save register values ONLY after it has encrypted and hashed the appropriately.  

Another guarantee XOM makes is that memory, disk and any other off-chip storage need not be trusted.  Rather XOM will authenticate encrypted values stored off chip with the use of hashes.  This is done efficiently by exploiting locality and using fast cryptographic algorithms.  Tagging the on-chip caches means that cryptographic operating occur with less frequency -- only when values are evicted or brought into the caches on-chip.  In addition, by using fast, pipelined   hardware running ciphers such as Rijndael, the AES cipher, we can encrypt and decrypt data moving between the processor and memory without impacting the memory bus throughput.   Thus the cost is paid only in longer latencies to memory.  For a fully pipelined Rijndael implementation, this results in 14 additional cycles to memory -- essentially one cycle per round.

Implementation

Currently, XOM is being simulated under the SimOS simulation system.  A in order MIPS processor model has been converted to include XOM simulated hardware.  The IRIX 6.5.5 operating system has been ported over to the XOM architecture so that it runs, but is untrusted by applications.  An application that uses  OpenSSL to securely sign certificates was the written and tested on the XOM simulator.  The signing keys and operations are guarded by the XOM hardware and cannot be observed or tampered with by any adversary including the operating system.  XOM has undergone formal verification with a model checker.

What about Palladium and TCPA?

XOM has much in common with Palladium and TCPA (The Trusted Computing Platform Alliance).   Like these two industry initiatives, it seeks to support trusted computing by protecting software from tampering.  It also requires hardware modifications and uses hardware as the root of it's trust.  It differs in that it makes much stronger guarantees.  It does not depend on the operating system and does not assume that memory is tamper-free.  It also does not rely on secure boot, but continually monitors the authenticity and integrity of code and data so that tampering cannot occur even after the secure boot attestation.  On the other hand, XOM requires more modifications to the main processor than either of these other two initiatives.   Currently, I am pursuing efforts to move much of XOM into a trusted virtual machine.  Such a virtual machine could be authenticated at boot and made in accessible at run-time with the aid of hardware.