DRAFT Credentials and Beliefs in Remote Trusted Platforms Attestation Andrea Bottoni and Gianluca Dini University of Pisa Dept. of Information Engineering I-56122 Pisa, Italy Email: {a.bottoni,g.dini}@iet.unipi.it Evangelos Kranakis Carleton University School of Computer Science Ottawa, ON K1S 5B6, Canada Email: kranakis@scs.carleton.ca Abstract— Remote attestation in trusted computing is about the ability of a local platform to authenticate the hardware and the software stack running on a remote trusted platform. We say that this process is successful, if a local application is able to authenticate each layer in the remote stack; it is meaningful if, by using this information, the local application can make its own evaluation on the safety of the platform environment where the remote application is running. In this paper we analyze the credentials and beliefs that are necessary to a local application in order for the remote attestation process to be both successful and meaningful. I. I NTRODUCTION Computer platforms are becoming widely available and are fundamental to the successful spreading of electronic business and commerce. This makes the need to protect information even more impelling, particularly on the type of platforms we use directly (e.g., PCs). The need for stronger trust and confidence in computer plat- forms increases with connectivity and physical mobility. In addition to threats associated with connecting to the Internet, physical mobility increases the risk of unau- thorized access to the platforms including actual theft. Trusted platform technology provides mechanisms that are useful in both circumstances, by allowing systems to extend trust to clients running on these platforms. Trusted platforms are computer platforms character- ized by specialized hardware designed for security oper- ations. Various initiatives in trusted computing [6] aim at designing software building blocks and interfaces that exploit the functionalities of the trusted platform technol- ogy. Among the several security-related functionalities that these platforms offer, remote attestation allows a local platform to authenticate a combination of hardware and software stack running in a remote platform. A local platform, by determining the environment of a remote platform, is in the position to better evaluate the amount of trust it is willing to extend on the remote one. In this paper we focus on the process of remote attestation which is done by means of digital signatures, as in [4] and [3], and that rely on the existence of a hierarchical public key infrastructure for identity, certifi- cates and key management. In this context, we analyze the credentials and beliefs that are necessary to a local application in order for the remote attestation process to be both successful and meaningful. We say that a remote attestation process is successful if, by combining the trust that a local platform has in different certification authorities, and the content of all the certificates making up the various chains, the local platform is able to identify the composition of the remote platform. On the other hand, the remote attestation process can be said to be meaningful if, by using the information obtained during the remote platform authentication and the beliefs of the local platform, the latter is able to consider the environment of the former as safe. To the best of our knowledge, this aspect has never been addressed before. For simplicity, but without loss of generality, we will assume that the remote platform is made up of three layers, that is, the application A, which runs on top of the operating system OS, which runs on top of the dedicated security hardware, the trusted platform module (TPM). The rest of the paper is structured as follows: we start by recalling the main constructs used by the theory employed in our analysis (Section II). Then, we ana- lyze the credentials and beliefs that are needed when authenticating a single remote layer (Section III), and we generalize the discussion to a set of layers making up the remote platform hardware and software stack (Section IV). Finally, we analyze the credentials and be- liefs needed to make the attestation process meaningful (Section V).