Educación Sexual

If a trusted platform is to be used in a networked environment, it is impor- tant that it can prove its status to an outside party. This requires two main functionalities:

9 Trusted Platforms 125 • The trusted hardware needs to know what state the attested platform is

in,

• The trusted hardware must be able to identify itself as such to an outside party.

If the trusted hardware only needs to attest itself, e.g., a smartcard with a banking application that executes largely independently of the host platform, the first functionality can be implemented rather easily by means of a certi- fication from the producer. Otherwise, one usually uses some form of trusted boot – once the trusted hardware observes the boot sequence, it does know what state the platform is in. There are two largely unsolved problems though: Firstly, if the system becomes corrupted after startup, the trusted hardware usually does not notice such corruption, though research in the area of runtime observation is currently underway [6]. Secondly, if the configuration attested to is itself so complex that it cannot be trusted (as is the case with most mod- ern operating systems), or if there are too many good configurations to keep track of (e.g., different kernel versions and patch levels), the value of such an attestation is limited. Mainly, it is reduced to recognizing known states, e.g., in a large organization to prescribe a standard configuration for user PCs.

The ability to identify the trusted hardware as such initially posed more of a political problem than a technical one. While hardware identities provide no problem in a military or commercial environment, using a unique platform identifier to attest platform properties to outside parties causes problems in the consumer area. The first attempt to this end, the processor serial number in the Pentium III, had to be revoked after massive consumer protests [7].

To prove it is genuinly secure hardware according to specification, a TPM needs some certificate. It is, however, required that such a certificate can be revoked, for example if an individual TPM is hacked and its keys are extracted. The TCG therefore originally decided to give each TPM its own identity, the endorsement key, (a public key encryption key), but to avoid exposure of this key to outside parties. Rather than using it directly to prove the genuineness of the TPM, an indirection is used. The user proposes a pseudonym (an attestation identity key) to a trusted third party (TTP), which verifies the TPM identity and then certifies the pseudonym. The certificate is then encrypted in a way that only the TPM with the original endorsement key can decrypt it again. Thus, only the TPM is able to use the attestation identity key. As long as the user trusts the TTP not to abuse the information it gathers, and verifiers of the platform trust the TTP to verify correctly, this provides users with a way to attest their platform status without giving up their anonymity.

Unfortunately, the concept of anonymizing the TPM by means of a trusted third party quickly reached its limits if applied on a large scale. It never be- came clear who would operate the trusted third parties under which con- ditions, and the mere existence of a platform identity was sufficient to cre- ate user outrage. Thus, the latest version of the TPM specification offers a

126 K. Kursawe

zero-knowledge proof based attestation protocol, direct anonymous attesta- tion(DAA) [8]. This is a highly advanced cryptographic protocol that allows a TPM to prove knowledge of a certificate, without the need to show the certificate itself. Revocation is still possible to a limited extend; if the verifier knows the TPM’s secrets, e.g., because an illegal software emulation appears on the Internet that used that secrets, it can recognize (and thus invalidate) that TPM. Furthermore, TPMs are recognizable if they access the same ver- ifier twice in a short time period – a TPM making 10 requests from five countries within an hour can thus be detected, though not identified. In ad- dition to offering an anonymous authentication mechanism, users may now permanently delete the endorsement key and thus the only unique identity of the platform. This deletion does, however, take the TPM out of the TCG trust infrastructure. The TPM cannot prove anymore that it is real, unless some trusted party issues a new certificate.

In practice, attestation on arbitrary PC platforms still faces significant limits. It does work well to detect changes to a previously known platform, e.g., a computer in a large organization or an embedded system. If the concept is to be extended to remotely verify properties of generic PCs, however, the verifier has to take into account every plausible version of BIOS and operating system, including various patch levels. Furthermore, the amount of informa- tion transmitted creates a privacy problem, and opens the door for abuse. As the verifier receives all data from the platform and then locally decides if this platform configuration is good, it is possible to discriminate against plat- forms running, for example, a competitor’s operating system – a possibility that caused massive criticism. One solution to both problems is property- based attestation [9,10]. In this model, the platform receives a certificate for properties a verifier might be interested in, and uses the security hardware to ensure that the certificates can only be accessed if the platform is actually in the configuration that was certified. The verifier then asks for a certificate for the property he is interested in, and receives exactly this information. Thus, the user does not need to tell the verifier everything about the platform, and the verifier needs to be open about the requirements; denying a service to a platform for questionable reasons immediately exposes the verifier.