An increasing number of systems, from pay-TV to electronic purses, rely on the tamper resistance of smartcards and other security processors. We describe a number of attacks on such systems -- some old, some new and some that are simply little known outside the chip testing community. We conclude that trusting tamper resistance is problematic; smartcards are broken routinely, and even a device that was described by a government signals agency as `the most secure processor generally available' turns out to be vulnerable. Designers of secure systems should consider the consequences with care.

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 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.

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 potential of secure coprocessing to address many emerging security challenges and to enable new applications has been a long-standing interest of many members of the Computer Research and Applications Group, including this author. The purpose of this paper is to summarize this thinking, by presenting a taxonomy of some potential applications and by summarizing what we regard as some particularly interesting research questions.

Introduction Security is a pressing problem for distributed systems. Distributed systems exchange data among a variety of users over a variety of sites, which may be geographically separated. A user who stores important data on processor A must trust not just processor A but also the processors B; C;D; . . . with which A communicates. The distributed security problem is difficult, and few major distributed systems attempt to address it. In fact, conventional approaches to computer security are so complex that they actually discourage designers from trying to build a secure distributed system: A software engineer who wishes to build a secure distributed data application finds that he or she must depend on the security of a distributed database which depends on the security of a distributed file system which depends on the security of a distributed operating system kernel, etc. Under