PRIVATO

Summary

Attesting the goodness of the code running on a third party platform is one of the hardest security problems ever. For an e-commerce client it is important to be assured that the e-commerce service does not leak his credit card. For a grid client it is important to be assured that both his job and the data resulting from it are not tampered by the grid platform. For a media producer it is important that their clients do not violate copyright agreements by, for example, making illegal copies of the media.

One of the most promising technologies which tries to solve this problem is Trusted Computing (a.k.a. Trustworthy Computing or TC). TC uses a combination of hardware and software to attest code safety to a third party. This combination acts as a trustworthy agent inside the distrusted platform which verifies the goodness of the running software and informs a third party. The two major problems with this approach are the loss of privacy of users and the potential los of document ownership. Users loose their privacy because a third party platform becomes aware of the applications and operating systems running on the attested platform. Owners may loose document ownership because documents may become bound to the application that has created them.

Our approach is to do attestation based on application properties. Services should be able to discriminate users running badly behaved applications, but they should not be able to discriminate users based on the exact applications they are running. Moreover, we believe that to ensure that everyone is able to write and deploy software to the protected environment, the verification and attestation of application properties should be done automatically, without requiring expensive accreditation processes.

We propose building a small TC platform which is able to verify the goodness of an application and attest it to a third party without revealing more information than necessary and without bounding data to applications. This will be done using the state of the art TC hardware platforms to maintain the project as simple as possible and to minimize the impact on current operating systems performance.

Scientific and technological objectives of the project and state of the art Many of the security problems on current distributed applications are related with trust on third-party code. For instance, for an e-commerce client it is important to be assured that the e-commerce service does not leak his credit card. For a grid client it is important to be assured that both his job and the data resulting from it are not tampered by the grid platform. For a media producer it is important that their clients do not violate copyright agreements by, for example, making illegal copies of the media. This type of problems can be solved using code attestation. Code attestation can be done in several ways, but one of the most promising is Trusted Computing (TC). However, trusted computing has a number of privacy and ownership problems, which have raised an enormous amount of discussion and prevented it to be widely used.

In this project we propose a platform which uses TC, but does not have the privacy and ownership problems of standard TC. The platform uses a simple monitor running in a hardware-protected environment which mediates every communication between protected applications and the outside world and verifies the safety properties of such applications using a data flow model.

In the remaining of this document we will describe briefly Trusted Computing and the problems of current TC solutions. In section 1.3, we will describe the proposed platform. Finally, in section 1.4, we will conclude with some related work.

Trusted Computing

TC is a hardware/software solution that promises a higher security standard by providing some hardware controls that cannot be circumvented using simple administrative operations.

The fundamental properties provided by the new hardware are:

1. Curtained memory – a special CPU mode where secure applications run protected even from kernel code;
2. Secure I/O – special secure channel protecting USB and graphic I/O from tampering (implemented either with cryptography or with an extra secure bit on the bus);
3. Attestation – proves to a remote service that a system cannot enter in an insecure state.
4. Sealing – cryptographic keys and other secrets are kept safely by the TC hardware and are disclosed only if the system is in a secure state.

The first two properties are provided by the processor and the last two are provided by an extra module, called the Trusted Platform Module (TPM) which is connected to the processor by an implementation dependent bus. Currently there are no processors implementing the first two properties although several projects by major vendors are scheduled for next year (Intel, AMD, and ARM). Conversely, several TPM chips exist, by several vendors, and they all obey to a standard specification provided by the Trusted Computing Group (TCG).

Several PC platforms already contain the TPM module, but in order to use it, the operating system needs to be changed. In fact, the whole set of hardware changes may have a significant impact on operating systems. We expect that this impact will be at least similar to the one provided by the introduction of protected memory. Several projects started to implement these changes at operating system level: TLC [1], TrouSers [2], Perseus [3], NGSCB [10], Nexus [14], and Trusted Zone [4]. From these the NGSCB (planned to be part of Windows Vista) and the TrustedZone are the only ones that are not open source, and are also the only ones that use all the new hardware features. From the remaining ones, only Perseus and Nexus have privacy and ownership considerations.

Problems of Current TC solutions

Privacy and ownership are the key concerns of TC. Because of the potential to break privacy and ownership, TC has been called “Treacherous Computing” [6] and much has been written about it. Although, many scary scenarios of privacy and ownership violation have been described in newspapers and magazines [15], the fundamental problems behind all those scenarios can be resumed to three, namely:

1. Remote attestation gives to an outside service the identity of the computer – although this is not the identity of the user, this information would allow several services to correlate information about the user actions violating his privacy.
2. Remote attestation gives to an outside service the exact configuration of the computer – this would allow a service to ban certain configurations (e.g. allowing only some browsers or some media players).
3. Sealing may be used to bind data to applications, which opens a Pandora box for all kinds of treacherous activities. Namely,

• documents produced by certain applications are bound to them and not to the author;
• media bound to DRM applications may be controlled remotely by the application owner, e.g. the owner may decide how many times a music may be listen on that computer.

The TPM specification version 1.2 tackles the first problem by using a zero-knowledge protocol to prove the ownership of a valid certificate, thus avoiding giving away the computer public key. However, in order to prevent stolen keys from being used for attesting impersonating machines, the TPM protocol is implemented in such a way that it opens a temporal window in which the usage of duplicate keys can be detected[1]. This solution, does not solve the problem because inside the temporal window undesired correlation can take place, and introduces a new problem – stolen keys can be used provided they are not used to access the same services inside the temporal window.

The usual method to deal with stolen keys is to attach to each key an expiration date, forcing the periodical renewing of keys before they expire. Camenisch [6] describes a zero-knowledge protocol to prove possession of a certificate with a time validity option, which may be used for this purpose. However, renewing the master key and renegotiating a new certificate is a sensible operation, in terms of security, privacy and reliability. The design of a communication architecture and protocol to ensure safe renegotiation of master keys for the TPM is an open issue, and is one of the goals of this project.

Perseus uses an interesting approach to avoid problems 2 and 3. Instead of building a signed package with the digest (SHA-1) of every application in the software stack, from the system boot to the current running application, Perseus builds a signed package with the properties of every application in the same software stack. This strategy removes most current TC privacy problems (namely problems 2 and 3) but creates a democracy problem. In Perseus, properties are attested by external accreditation institutions, thus a developer whishing to deploy a TPM enabled application needs to submit that software to an expensive accreditation process which may only be available to some powerful developers.

The proposed platform

The proposed solution uses extensively the curtain memory feature present in the next generation processors. The most important result of this feature is the ability to run protected applications on unchanged operating systems. In current hardware platforms the non-interference between insecure code (e.g. general purpose operating systems and applications) and protected code is ensured by a combination of a secure boot process and a small secure microkernel, on top of which both the protected applications and modified versions of current operating systems run. The secure boot ensures the safety of the microkernel, and the microkernel ensures the containment of protected applications.

In hardware platforms with curtained memory the secure boot process is replaced by a special new instruction which starts a verification process anchored in firmware. This process verifies the security of a protected kernel/monitor, which in turn is responsible for loading and attesting the security of every protected application.

The TC ARM project [4] is one of the few that uses curtained memory. The ARM project is composed by a TC enabled ARM processor and two microkernels, one running below the operating system and the other running in protected memory to manage protected applications. The microkernel running in protected memory communicates directly with every I/O device, while the microkernel running below the operating system uses a special communication channel to use the I/O primitives of the protected microkernel. This ensures that protected I/O takes precedence to non protected I/O, but it imposes a performance bottleneck to current operating systems.

Platform architecture

Our approach differs in two ways. First, our solution does not contain any microkernel. There is only a small monitor to load, and attest a protected application. Second, all the I/O is done through the standard operating system. The protected monitor provides only a communication channel to the operating system. The security of the I/O is assured by encryption, and the insecure operating system is seen as another element in an insecure channel. The data should leave the protected area encrypted with a key only known to the receiver. The advantages of this solution are obvious. First the standard operating system does not need to be modified, and second the monitor running in protected memory is much smaller than any of the microkernels in the ARM project, which makes it much more verifiable and secure.

Attestation process

We believe that attesting software properties instead of software identity is the correct way of attestation. A server should be allowed to discriminate clients based on their honesty, but it should not be allowed to discriminate clients based on the browser or operating system they use. However, software properties should be extracted automatically from the software by the TPM or other equally trusted entity, and not derived by an accreditation process, in order to ensure democracy, even if the attested properties are much less expressive than the ones that could be attested by an accreditation process.

In our solution the monitor, running in protected memory, is responsible for loading, verifying and attesting the properties of the protected application running over it. It is also responsible for providing several types of communication channels for the protected application to the outside world. We intend to label each communication channel with the type of safety provided. For instance, a channel encrypting data with a key known only to the TPM is considered a safe deposit; a channel receiving data from another TPM is labeled with the id of the other TPM. Each protected application planning to ensure some kind of property will ask the monitor to attest it using static data flow analysis. With data flow analysis we will be able to verify if the application may leak protected data to an unprotected channel. Whenever a remote service requires attestation of some property the secure monitor will provide it based on the verification done earlier and on the privacy policy of the application (e.g. applications can decide to provide proofs of property compliance to a service and deny it to another one). The types of communication channels required and the way to express properties is still an open issue which we intend to solve.

Target applications

In order to test our platform we plan to design safe versions of three classes of applications: e-voting, grid platform (or peer-to-peer) and DRM. The development of each type of these applications is complex enough to be a project on its own. However, it is important that the design of our TC solution takes into account the specificities of each of these classes of applications and be tested with, at least, a small prototype of one of them.

For example, a media distributor would require from a DRM application that it does not leak to the outside of the protected environment:

• the key used to decrypt the media;
• the unencrypted media;
• or any data resulting from a non secure transformation of the unencrypted media.

In fact, the media distributor does not need to be aware of the identity of the application and what it does with the media, provided that the media does not leave the control of that TPM. Therefore, instead of attesting the digest of the application to the DRM distributor, the TPM should attest that the DRM application has the above properties.

On Grid platforms the problem is very similar. Currently, most Grid platforms offer protection to its own resources against badly behaved jobs submitted by foreign agents, but none offers protection against badly behaved grid platforms. In fact, both the data submitted by the job and its results can be leaked and even modified by a badly behaved platform. We would like to ensure (attest) to a job submitter that the platform on which the job is run does not leak or tamper with the job data. We would also like to attest that the reported CPU elapsed time used to run the job is trustful.

On e-voting applications the problem is slightly more complex, because the target of the attestation is the voter himself, not a machine. We would like to ensure to the voter that the e-voting client running on his platform behaves as expected. The expected behavior depends on the e-voting protocol. In Revs [8], the client application is expected to:

• not leak the voter password used to login into the election administrators;
• securely store the voter ballot during the election;
• communicate only with certified voting services.

Due to the complexity of the properties to be attested we intend to use the voting services to attest the properties of the voting application, and communicate that attestation to the voter through an out-of-band channel or a covert in-band channel.

Related work

The problem of achieving trust in code running on a third party platform or, in the opposite perspective, the problem of attesting the good behavior of code to a third party, has been studied by several projects. Some do not rely on any kind of specific hardware, others require a TPM chip to do attestation and sealing, and others require not only the TPM chip but also a modified processor.

Pionner [13] does not rely on any kind of special hardware to perform attestation. In Pionner the root of trust is a self-certified piece of code which is able to compute a cryptographic checksum on its instructions in response to an attestation request with a challenger. The challenger prevents an impersonator to reply with a previous checksum, and timing constraints prevent an impersonator to redirect the verification process to code different from the one which is running.

Terra [7] takes the virtual machine monitor based approach. It builds upon the secure boot process provided by TPM to attest the security of a full blown virtual machine monitor. The virtual machine monitor runs one or several operating systems and protected applications isolated from each other. One of the problems of attestation with code digests is how to handle updates, because updates break the digest and it is necessary to redistribute another valid digest. In Terra attestation is perform for the complete virtual machine monitor that may be large enough to imply several updates. On the other hand, Terra does not take into consideration any privacy problems, and normal unprotected applications suffer a performance penalty by being used on top of a virtual machine.

Perseus [3] and Nexus [14] use a small microkernel together with the TPM secure boot process to establish a root of trust, on which they run modified versions of Linux and protected applications isolated from each other. Both Perseus and Nexus avoid the use of digests to attest the safety of protected applications due to the privacy problems (cf. section 1.2). Perseus uses certificates issued by third parties, and Nexus uses behavior information to label applications (e.g. number of key strokes for an email application, or number of forward packets for a peer-to-peer application).

Proof-carrying code techniques could be used to extract these application properties [9]. Unfortunately, these techniques are not currently able to handle complex programs or extract complex properties, other than memory boundaries. Recently, Barthe [5] proposed the use of compilers to translate high level assertions, inserted in source code, to low level assertions, verifiable at load time using the application opcodes. Although it promises a higher expressiveness than the original proof-carrying code, it still lacks the expressivity required for our purpose. Model-carrying code is another recently proposed solution [12], but some models are not expressive enough and others can only be enforced at run time which poses an extra penalty on applications.

Bibliography

[1] Safford, D. and M. Zohar A Trusted Linux Client (TLC), T.J. Watson Research Center, IBM.

[2] (2005). TrouSers, http://trousers.sourceforge.net/faq.html.

[3] Sadeghi, A.-R. and C. Stüble (2005 ). Property-based attestation for computing platforms: caring about properties, not mechanisms, Proc. of the 2004 NSP, Nova Scotia, Canada ACM Press: 67-77

[4] Alves, T. and D. Felton (2004). TrustZone: Integrated Hardware and Software Security, ARM.

[5] Barthe, G., A. Basu, et al. (2004). Security Types Preserving Compilation. 5th International Conference, VMCAI. B. S. a. G. Levi, Springer-Verlag. 2937: 2-15.

[6] Camenisch and Lysyanskaya (2001). An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation. Advances in Cryptology: Proceedings of EUROCRYPT.

[7] Garfinkel, T., B. Pfaff, et al. (2003). Terra: a virtual machine-based platform for trusted computing. SOSP: 193-206.

[8] Joaquim, R., A. Zúquete, et al. (2003). "REVS – A Robust Electronic Voting System." IADIS - International Journal of WWW/Internet.

[9] Necula, G. and P. Lee (1997). Research on Proof-Carrying Code for Untrusted-Code Security. Proceedings of the 1997 Conference on Security and Privacy (S&P 97). Los Alamitos, IEEE Press.

[10] Peinado, Chen, et al. (2004). NGSCB: A Trusted Open System. ACISP: Information Security and Privacy: Australasian Conference.

[11] Richard, S. (2002). Can you trust your computer? Selected Essays of Richard M. Stallman., F. Society.

[12] Sekar, R., V. N. Venkatakrishnan, et al. 2003. Model-carrying code: a practical approach for safe execution of untrusted applications. Proceedings of the nineteenth ACM symposium on Operating systems principles. New York, ACM Press. 37, 5: 15--28.

[13] Seshadri, A., M. Luk, et al. 2005. Pioneer: Verifying Integrity and Guaranteeing Execution of Code on Legacy Platforms. Proceedings of the 20th ACM Symposium on Operating Systems Principles (SOSP'03). Brighton, UK, ACM. 1--16.

[14] Shieh, A., D. Williams, et al. (2005). Nexus: A New Operating System for Trustworthy Computing. SOSP, Brighton, UK, ACM.

[15] Anderson, R. J. (2003). TCPA/Palladium Frequently Asked Questions.

Sponsoring bodies: FCT

Coordinator: Carlos Ribeiro

Partners: INESC-ID

Homepage: N/A