Abstract. Unsecure computational environments threaten many nancial cryptography implementations, and other sensitive computation. High-performance secure coprocessors can address these threats. However, using this technology for practical security solutions requires overcoming numerous technical and business obstacles. These obstacles motivate building a high-performance secure coprocessor that balances security with easy third-party programmability|but these obstacles also provide many design challenges. This paper discusses some of issues we faced when attempting to build such a device. 1

The views and conclusions in this document are those of the authors and do not necessarily represent the official policies or endorsements of any of the research sponsors. How do we build distributed systems that are secure? Cryptographic techniques can be used to secure the communications between physically separated systems, but this is not enough: we must be able to guarantee the privacy of the cryptographic keys and the integrity of the cryptographic functions, in addition to the integrity of the security kernel and access control databases we have on the machines. Physical security is a central assumption upon which secure distributed systems are built; without this foundation even the best cryptosystem or the most secure kernel will crumble. In this thesis, I address the distributed security problem by proposing the addition of a small, physically secure hardware module, a secure coprocessor, to standard workstations and PCs. My central axiom is that secure coprocessors are able to maintain the privacy of the data they process. This thesis attacks the distributed security problem from multiple sides. First, I analyze the security properties of existing system components, both at the hardware and

The Sanctuary project at UCSD is building a secure infrastructure for mobile agents, and examining

The Dyad project at Carnegie Mellon University is using physically secure coprocessors to achieve new protocols and systems addressing a number of perplexing security problems. These coprocessors can be produced as boards or integrated circuit chips and can be directly inserted in standard workstations or PC-style computers. This paper presents a set of security problems and easily implementable solutions that exploit the power of physically secure coprocessors: (1) protecting the integrity of publicly accessible workstations, (2) tamper-proof accounting/audit trails, (3) copy protection, and (4) electronic currency without centralized servers. We outline the architectural requirements for the use of secure coprocessors. 1 Introduction and Motivation The Dyad project at Carnegie Mellon University is using physically secure coprocessors to achieve new protocols and systems addressing a number of perplexing security problems. These coprocessors can be produced as boards or integrated ...

Many researchers believe electronic wallets (secure storage devices that maintain account balances) are the solution to electronic commerce challenges. This paper argues for a more powerful model --- a secure coprocessor --- that can run a small operating system, run application programs, and also keep secure storage for cryptographic keys and balance information. We have built a system called Dyad, on top of a port of the Mach 3.0 microkernel to the IBM Citadel secure coprocessor. This paper describes the abstract architecture of Dyad and a general discussion of secure coprocessor implementations of a variety of electronic commerce applications: ffl Copy protection for software ffl Electronic cash (including a critique of proposed solutions for point-of-sale electronic wallet systems) ffl Electronic contracts ffl Secure postage 1 Introduction Many researchers believe electronic wallets (secure storage devices that maintain account balances) are the solution to electronic commerc...

Cerium is a trusted computing architecture that protects a program's execution from being tampered while the program is running. Cerium uses a physically tamperresistant CPU and a -kernel to protect programs from each other and from hardware attacks. The -kernel partitions programs into separate address spaces, and the CPU applies memory protection to ensure that programs can only use their own data; the CPU traps to the -kernel when loading or evicting a cache line, and the -kernel cryptographically authenticates and copyprotects each program's instructions and data when they are stored in the untrusted off-chip DRAM. The Cerium CPU signs certificates that securely identify the CPU and its manufacturer, the BIOS and boot loader, the -kernel, the running program, and any data the program wants signed. These certificates tell a user what program executed and what hardware and software environment surrounded the program, which are key facts in deciding whether to trust a program's output.

Too often, “security of Web transactions ” reduces to “encryption of the channel”—and neglects to address what happens at the server on the other end. This oversight forces clients to trust the good intentions and competence of the server operator—but gives clients no basis for that trust. In this paper, we apply secure coprocessing and cryptography to solve this real problem in Web technology. We present a vision: using secure coprocessors to establish trusted coservers at Web servers and moving sensitive computations inside these co-servers; we present a prototype implementation of this vision that scales to realistic workloads; and we validate this approach by building a simple E-voting application on top of our prototype. By showing the real potential of COTS secure coprocessing technology to establish trusted islands of computation in hostile environments—such as at web servers with risk of insider attack—this work also helps demonstrate that “secure hardware ” can be more than synonym for “cryptographic accelerator.’ 1

Partial order time expresses issues central to many problems in asynchronous distributed systems, but suffers from inherent security and privacy risks. Secure partial order clocks provide a general method to develop application protocols that transparently protect against these risks. Our previous Signed Vector Timestamp protocol provides a partial order time service with some security: no one can forge dependence on an honest process. However, that protocol still permits some forgery of dependence, permits all denial of precedence, and leaks private information. This paper uses secure coprocessors to improve the vector protocol: our new Sealed Vector Timestamp protocol detects both the presence and absence of causal paths even in the presense of malicious processes, and protects against some privacy risks as well. By solving these previously open security problems, our new protocol provides a foundation for incorporating security and privacy into distributed application protocols bas...

Secure coprocessors provide a foundation for many exciting electronic commerce applications, as previous work [20, 21] has demonstrated. As our recent work [6, 13, 14] has explored, building a high-end secure coprocessor that can be easily programmed and deployed by a wide range of third parties can be an important step toward realizing this promise. But this step requires trusting trusted hardware -- and achieving this trust can be difficult in the face of a problem and solution space that can be surprisingly complex and subtle. Formal methods provide one means to express, verify, and analyze such solutions (and would be required for such a solution to be certified at FIPS 140-1 Level 4). This paper discusses our current efforts to apply these principles to the architecture of our secure coprocessor. We present formal statements of the security goals our architecture needs to provide; we argue for correctness by enumerating the architectural properties from which these goals can be proven; we argue for conciseness by showing how eliminating properties causes the goals to fail; but we discuss how simpler versions of the architecture can satisfy weaker security goals. We view this work as the beginning of developing formal models to address the trust challenges arising from using trusted hardware for electronic commerce.

The views and conclusions contained in this document are those of the authors and should not be interpreted as