USENIX AssociationProceedings of the12th USENIX Security SymposiumWashington, D.C., USAAugust 4–8, 2003THE ADVANCED COMPUTING SYSTEMS ASSOCIATION© 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association:Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.orgRights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes.This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.12th USENIX Security Symposium USENIX Association295Establishing the Genuinity of Remote Computer SystemsRick Kennell & Leah H. JamiesonPurdue University School of Electrical and Computer Engineering{kennell,lhj}@purdue.eduAbstractA fundamental problem in distributed computing envi-ronments involves determining whether a remote com-puter system can be trusted to autonomously access se-cure resources via a network. In this paper, we describea means by which a remote computer system can bechallenged to demonstrate that it is genuine and trust-worthy. Upon passing a test, it can be granted access todistributed resources and can serve as a general-purposehost for distributed computation so long as it remainsin contact with some certifying authority. The test wedescribe is applicable to consumer-grade computer sys-tems with a conventional network interface and requiresno additional hardware. The results of the test can beconveyed over an unsecured network; no trusted humanintermediary is needed to relay the results. We examinepotential attacks and weaknesses of the system and showhow they can be avoided. Finally, we describe an imple-mentation of a genuinity test for a representative set ofcomputer systems.1 IntroductionFor most types of valuable real-world objects, there aregenerally accepted methods of assessing their genuin-ity in a non-destructive fashion. Archimedes determinedthat King Heiron’s crown was not made of pure gold bynoticing that the mass and volume of the crown did notmatch the known density of gold. We can discern realdiamonds from imitations by examining their electricalcharacteristics and their indices of refraction. We can de-termine that money is not counterfeit by carefully study-ing its watermarks and other identifying features.Unfortunately, we have few such measures for computersystems. When answering the question of whether acomputer system is real, we can only verify that it lookslike a computer and acts like a computer. Unfortunatelythe dynamic nature of a programmable computer meansthat it may not always behave the same in the future.Furthermore, when that computer system is moved fromour immediate presence, we have few guarantees that ithas not been physically modified or reprogrammed.We introduce the need for a remote system genuinity testwith a motivating example: Suppose Alice is the consci-entious administrator of a network of computer systemsthat rely on a central NFS [42] server. Only trusted sys-tems are allowed to act as NFS clients. Bob and Mal-lory use the systems in the network for large distributedapplications that manipulate data on the file server. Inaddition to accomplishing normal work, Mallory wouldlike to either steal or corrupt Bob’s data by subverting anNFS client. Mallory has a deadline to perform an espe-cially large computation and has made an arrangementwith a distant colleague to borrow several hundred newcomputers to join the computer network temporarily inorder to assist with the work. This necessarily meansthat they must also be able to access his data on the NFSserver.How can Alice determine which systems should be givenaccess to the NFS server? She could travel to the loca-tion of each of the new systems in order to configure andphysically secure them, but this might take more timethan she is able to commit. Allowing Mallory to specifythe systems eligible to be NFS clients would give himan opportunity to deliberately misconfigure a system inorder to allow him to access Bob’s data. Knowing theidentity of the remote systems gives Alice no assuranceof how the systems will behave.What Alice really wants is an automated way of deter-mining that a remote system has been properly config-ured before it is granted access to the NFS server. For thespecific case of NFS, “properly configured” means thatonly Alice has administrative control over the client. Ina broader sense, it means that the system’s hardware andsoftware will act in a deterministic fashion that corre-sponds with Alice’s expectations. To measure this de-terminism, it is necessary for Alice to be able to de-cide whether the system’s hardware and software aregenuine. For instance, it is easy to see that the correctsystem software running in the context of a simulatorcan not always be trusted because it cannot be known12th USENIX Security Symposium USENIX Association296whether the simulator will always act the same as realhardware. Moreover, anyone who controls the simula-tor will be able to spy on or manipulate the data residentin the simulated environment. The same lack of trust-worthiness is more obviously apparent for compromisedsoftware running on real hardware.We demonstrate a method by which we can simultane-ously measure the genuinity of a system’s hardware andsoftware, remotely, without the need for a trusted humanintermediary. This method can be used to decide on alevel of trust that can be imparted to the system in ques-tion. Our mention of NFS (without special encryption orcredential support) in the previous example is deliberate.In Section 5 we describe our implementation of a gen-uinity test that allows us to trust a remote system for useas an NFS client. Although attacks against our methodare possible, their risk may be acceptable in some envi-ronments.This paper is organized as follows. In Section 2 we ex-amine the basic methods for determining the genuinityof software, hardware and combinations thereof. In Sec-tion 3 we show how the results of such a test can bedelivered through an insecure network to an observer.Section 4 describes several forms of attack against thesystem as well as our methods for reducing the risk ofthose attacks. Section 5 shows various results of an im-plementation of our system. We conclude our paper withan overview of related work in Section 6 and a summaryof our results and future plans in