Bennet's Research Summary

The theme of my research is applying cryptography to operating system security and exploring the practical limitations of these techniques. In the Strongbox project, I examined how security assumptions about the underlying operating system may be minimized by judicious use of cryptography. In the Dyad project, I examined how standard cryptology assumptions -- the ability to compute securely with the cryptographic keys -- may be grounded in distributed systems by using a secure coprocessor, and I examined how the use of physical security, in conjunction with cryptography, can enhance the security of distributed applications and make them practical. In the Sanctuary project, I addressed the problem of secure remote execution, using a combination of physical security, cryptography, and trust management to allow users of a mobile agent system to remotely run their agent code securely.

The Strongbox Project

In the Strongbox project, I examined how to build a secure distributed operating environment while making minimal assumptions about the security of the underlying Mach operating system. In Strongbox, filesystem contents as well as network communications were assumed to be subject to attack, so the underlying operating system provided neither filesystem access controls nor communications security. (Perhaps the disk could be temporarily removed, placed inside another computer, and modified, bypassing normal access controls.) In Strongbox, the only security assumptions made are that (1) processes can compute in private without interference from unrelated processes, which permitted processes to perform computations using cryptographic keys; (2) that the basic Mach process control and virtual memory manipulation mechanisms for manipulating child processes are correct; and (3) that cryptographic intractibility assumptions (breaking DES is hard; the quadratic residuosity decision problem is difficult) hold.

There are two distinguished processes on every host that form the core of the Strongbox system. The first is a secure loader and the second is a white pages server. In Strongbox's system bootstrap process, a trusted system operator is assumed to be available to enter in an initial cryptographic key using a trusted communication path to each computer's secure loader.

The secure loader uses Mach virtual memory primitives to load the initial memory contents of new processes from files. These virtual memory primitives are assumed to work correctly. To maintain system integrity, all file contents are verified to be untampered by verifying that the contents match the secure cryptographic checksums (fingerprints). These checksums are in turn protected by the initial bootstrap key, so even though the underlying filesystem do not provide any real security guarantees (e.g., NFS), system (and data) integrity is maintained.

In addition to initializing memory contents of new processes, the secure loader provided them with freshly generated cryptographic authentication secrets (created using a cryptographically secure pseudo-random number generator). The authentication protocol in Strongbox is based on the Feige-Fiat-Shamir zero knowledge authentication protocol. The secure loader registers the authentication data with a per-node white pages server to enable authenticated communications.

This white pages server is the second distinguished process in Strongbox, and it provides name service to provide a mapping between symbolic names and authentication information. The white pages servers also possess authentication secrets so their identities can be checked; these secrets are privacy protected by an operator-entered key in much the same way that the file fingerprints are integrity-protected by an operator-entered key. The name space is partitioned and controlled according to user IDs from the underlying operating system.

The Dyad Secure Coprocessor Project

The Dyad Secure Coprocessor Project demostrated the flexibility and power of using secure coprocessors to protect the security critical computation in a distributed system. Secure coprocessors are essentially specially designed microcomputers that are packaged with tamper-sensors, so that any attempt to physically probe the internal state of the secure coprocessor will result in a complete resetting of the secure coprocessor's internal state, keeping secrets secret by erasing memory. Secure coprocessors plug into a host system, and make use of host-side resources such as networking and disk storage.

Secure coprocessors permit the bootstrapping of highly secure systems such as Strongbox, since no trusted operator is required to protect cryptographic keys. Furthermore, because secure coprocessors permit arbitrary computations -- rather than just protecting or verifying file fingerprints -- to be performed, they permit a much more general form of secure distributed computation: a process running inside of a secure coprocessor has an execution environment that is protected by the manufacturer of the secure coprocessor, which we assume is a widely trusted third party.

In the Dyad work, I ported the Mach microkernel operating system to Citadel, a prototype secure coprocessor from IBM research, and demonstrated the ability to run very secure applications in that environment, using the hardware-provided tamper-sensing security to derive higher level security properties. Each secure coprocessor has its own unique public key which is certified by its manufacturer. Applications can be partitioned to have a portion of their computation occur only within a particular secure coprocessor by having the code for that computation encrypted with the public key of that secure coprocessor.

Applications of secure coprocessors include (1) secure bootstrap, where the secure coprocess aids the host operating system in its boot process to ensure system integrity; (2) strong copy protection for software; (3) and general private computation.

The Sanctuary Secure Mobile Agent System

The goal of the Sanctuary secure mobile agent system is to develop practical techniques to make mobile agent systems secure. Using mobile code is an attractive method for structuring widely distributed systems, since its use can help hide communications latency as well as increase system flexibility and mask transient faults or loss of connectivity. Hiding latency is critical as individual system performance improves, since latency will become the critical bottleneck for distributed system performance. While there is no "killer app" for mobile code, ever increasing system performance and available bandwidth will make latency an increasingly critical barrier to distributed performance, and remote execution will become increasingly attractive and necessary.

A mobile code system, however, is also a new source of security weaknesses: a malicious or compromised mobile code execution engine can easily cause mobile code to generate invalid results.

Unlike other mobile agent systems, Sanctuary is designed from the ground up to be as secure as possible. Critical to Sanctuary's design is the confluence of several ideas:

To make writing mobile code less error prone, a "migrate" primitive for strong process migration is added to Java via a source-to-source precompiler. This does not require any changes to the semantics of the underlying bytecodes (i.e., no change to the JVM). This is important for several reasons. First, the language-level protection mechanisms offered by Java cannot be weakened, since standard Java compilers and JVMs are used to process the output of the precompiler. Second, because the precompiler is a standalone tool and not integrated into Java compilers, technology improvements in standard Java compilers, JVMs, or JITs will benefit Sanctuary agents without requiring that migration-related modifications be re-integrated with every new Java tool. Third, the results of highly-stylized transformations can easily be hand inspected, so the tool for performing the transforms is not part of the trusted computing base.
This work has recently resulted in the Mojo migration precompiler, which is being used internally by the Sanctuary group.
Each user of the agent system will trust agent servers differently, depending on whether the users have prior (contractual) relationships with the server administrator, whether the user believes that the server hosts are secure, etc. And there are various reasons that a server might be secure: the host may incorporate a secure coprocessor, so that agents run inside an environment provided by a trusted third party, the agent server may be running on a host that is trusted because it is protected by armed guards or lock and key, or because the operation center undergoes periodic security audits.
In order to exploit the security advantages of hosting agents on physically secured, tamper resistant hardware (secure coprocessors) or on sites that are otherwise more secure, security attribute certification is used to allow decentralized agent-centric trust management, where agents can be programmed to autonomously decide not only when they wish to migrate to a different host, but also whether it is appropriate to migrate.
To capture the notion of delegating access rights within the agent system, SDSI certificates can be used as non-transferrable capabilities that are cryptographically bound to the mobile code. Here, instead of the usual notion of delegation to a key in a "speaks-for" relationship, where the key is used by some principal, we are delegating directly to an agent's code. This removes the separation of principal and key -- if the agent does not possess a key to which there is delegated authority, then there is no way for an attacker to steal that (non-existent) key.

Current Status of Sanctuary

The Sanctuary system is currently in "early alpha" release status. We have a working mobile agent server, and it can run both on a normal workstation host and within a secure coprocessor card. The Mojo precompiler is running and it is being integrated into the agent system. We plan on making a public alpha release soon.

The Sanctuary system is joint work with Matthew Hohlfeld, Edward Elliott, and Robert Miller.

The Triton Internet Ticket System

The Triton Internet ticket system was designed and built as a demonstration of how movie tickets or other event tickets can be sold over the Internet. The ticket system design took advantage of properties of event ticketing and simplified and streamlined the design used in the US Postal Service's Information-Based Indicia system (earlier work with Tygar and Heintze) for use with event ticketing. With Triton, the consumers uses their web browsers to enter credit card information, using SSL to protect the confidentiality of the data, just as any other on-line retail web site, and the tickets are immediately returned as 2-D barcode images that the consumers then print out and later bring to the event. At the event admission, the data is scanned in and verified to be authentic and unique. This system was tested in a public demonstration at the Birch Aquarium, and the web site is currently archived at http://philby.ucsd.edu/triton/.

The Triton system is joint work with Noriya Kobayashi (NEC).

bsy+www@bennetyee.org, last updated Mon Dec 13 23:22:08 PST 2004. Copyright 2004 Bennet Yee.
email bsy.