Establishing Users' Trust in Their Trusted Platforms

This section concentrates on using a smart card to challenge a platform in order to determine whether it is a TP, and whether it is in an acceptable state for the user's purpose. A user's confidence in a computing platform is dependent upon whether he or she is able to find out whether the BIOS, the OS loader, the OS, etc., in the platform can be trusted to behave as expected. If the stages described in this section are carried out satisfactorily (i.e., the user trusts a smart card, the smart card is able to verify the integrity of the platform, and the smart card can convey the result to the user in a trusted fashion), then the user can directly infer to what degree the platform may be trusted for the intended purpose. If the user decides that the platform can be trusted, the user can safely present his or her authentication information to the platform, knowing that the platform will not misuse that data.

Challenging a Platform with a Smart Card

As described in the introduction, only a computing engine can perform the operations that verify the evidence produced by a TP. First consider the case where a smart card is that computing device. Normally, a smart card is a slave device, controlled by its host platform, so using a smart card to challenge a platform requires a change in the status of a smart card attached to a platform. For the purpose of this chapter, it is sufficient to note that a platform can treat a smart card as a peer, and the smart card can initiate transactions with the platform, instead of being a slave to the platform. The details of the change, named Intelligent Adjunct (IA) in the paper where the paradigm was originally introduced, are outside the scope of this book. (The interested reader is referred to [Balacheff et al. 2000a]. Additional discussion about how IA-enabled smart cards can securely make use of the facilities provided on the corresponding platforms to access off-card resources is given in [Balacheff et al. 2000b].)

A smart card can be used to establish trust between a user and his or her TP through a three-stage process whereby:

These aspects are considered in more detail below.

User Trust in the Smart Card

First of all, the user has to be sure that his or her smart card works correctly. (See [Banerjee et al. 1999] for background information.) This trust will typically come from the user getting the smart card from a trusted party, such as a corporate IT department, or under contract with a Service Provider. The user of the smart card may then be able to further configure the smart card to operate according to his or her own preferences.

Establishing Trust Between the Smart Card and the Local Platform

The local platform, even if it is a TP, may be in an untrusted state. A smart card can interact with the platform in the following ways, in order to determine whether the local platform is a genuine TP, and to establish its own level of trust in that local platform, prior to this being communicated to the user:

The Smart Card Identifies the Platform

One way to do this is for the IA-enabled smart card to be aware in advance of the identity of the platform. The smart card might know a public key for a TPM identity that can be used to identify the platform as a genuine TP, for example. Alternatively, the smart card might rely on a Certification Authority (such as a Privacy-CA in the TCPA model) that it trusts to certify TP TPM identities. The smart card might trust a third party server to which it will delegate verification of platform identity certificates. Methods of identifying TPs have already been discussed in detail earlier in this book (see Chapters 5 and 12).

The Smart Card Checks the Integrity of the Platform

If the local platform is a TP, the integrity check includes the boot process, the OS loader, and so on, and is carried out via an integrity challenge.

The smart card must implement IA functionality, mentioned earlier in this chapter, to issue an integrity challenge to the platform. As a result of the information it receives, the smart card can assess whether or not the local platform is a TP and, if so, the degree of trustworthiness of the state in which it is currently (the integrity challenge process is described in Chapter 12). However, certain checks also need to be made throughout the period of interaction between the user and the local platform. It is essential that, after identifying the platform, the smart card ensures that all communications with the local platform continue to be identified as coming from that same platform. This is the only way of ensuring that the smart card carries on communicating with the same TPM that it has identified and challenged. This could be done by establishing a shared secret with trusted software on the host platform. Such a shared secret could even be sealed to a known software state of that platform, in order to be confident that it will only ever be available on that platform in a known “good” state. Alternatively, for a small number of interactions, the platform's TPM could be required to digitally sign every interaction. Another option would be that the smart card may wish to challenge a TP periodically in order to ensure that it does not move from a trusted state to an untrusted state.

After a smart card has identified and verified the integrity of the platform, it needs to establish that this platform is indeed the local platform to which it is connected. How this is done, and whether it is necessary, will depend on the application domain in which the smart card is involved. Examples of how to achieve this include the following:

• The smart card will only interact with an application on the presumed-local platform if it is satisfied that the software it has identified to be running on this machine operates with a smart card inserted in a reader local to the platform. Let us consider the example of smart card logon. The smart card could always verify integrity of the platform before consenting to release credentials for smart card logon. The smart card may also require that this integrity verification must provide evidence that the version of the software on the local platform will only accept logon credentials from a smart card that is local to the system.

• The smart card will use the mechanism described in the 'Explicit feedback' subsection below to ask the user to enter a PIN number to confirm that the user has seen a “secret" image displayed on the local platform. This equates to delegating to the smart card user the responsibility of identifying whether the smart card is indeed communicating with the local platform to which it is connected.

Conveying the Smart Card's Findings to the User

A conventional smart card lacks a direct input and output interface for its user. So after the smart card completes authentication and integrity checking of the platform, how can it convey to the user, in a trusted manner, the decision whether the platform can be trusted for the intended purpose? Obviously, because the local platform might not be trustworthy, its display facilities cannot be used directly to display messages from the smart card, as they might get altered en route.

There are a number of different solutions to this problem. The following are three examples of how the trust relationship between the smart card and the platform can be conveyed to the user.

Implicit Feedback

It is possible to program the smart card such that it will refuse to interact with an application unless it can first authenticate and satisfy itself as to the integrity of the computing platform to which it is connected. Such an interaction might be for authentication, for provision of cryptographic services, or for provision of any other services.

This is achieved in the following way. Whenever a user uses his or her smart card to log on to a platform or a service, he or she will insert the smart card into the smart card reader. Then the smart card will communicate with the TPM inside the local platform, identify the TPM as a genuine TPM, and check the integrity of the platform, as described earlier. The smart card could also require identification of a specific TPM, rather than simply verifying that the local platform is a genuine TP.

If the smart card is satisfied with the result of identification of the TPM and/or integrity verification of the platform, it will go ahead and present its credentials to the platform. As a consequence, the user will be logged in or the service will be provided. From this, the user can infer that the smart card was satisfied with the platform's integrity. If, however, the smart card is not satisfied with the result of identification of the TPM and/or integrity verification of the platform, it will refuse to present the user's credentials for logon or service provision. In this case the expected logon or service provision will not occur, and the user can infer either that the smart card does not trust the platform, or that the smart card was unable to provide the service for some other reason. (Differentiating between the two requires a separate trusted display interface for the smart card to communicate to the user.)

Service providers can use this technology by providing customers with a smart card that only operates correctly when the smart card can verify that the computing platform to which it is connected has passed various integrity checks (previously specified on the smart card by the corresponding service provider). This can be used in a number of different ways. For example, a user's smart card could protect the user from connecting to a spoof service. It could also provide the user with functionality to be used off-line that can still be protected through the use of the smart card.

Explicit Feedback

An alternative approach uses the platform's display as an off-card resource in order to relay information describing the computer platform's state. If the smart card trusts the platform, it exports an image to the platform, which displays it on the platform's monitor. The platform should have no other way of obtaining the image data except by satisfying the user's smart card integrity verification and platform identification requests. A difficult-to-obtain picture is ideal, but there are other possibilities, such as another form of secret (a number or phrase, for instance) known only to the user. The user should choose these images in an unpredictable manner to make it unlikely that a rogue platform can guess the current image. Preferably, the user changes the image used depending on the context in which this functionality is used.

By simple visual inspection, the user can identify with a high degree of accuracy that the image is the expected image. He or she can conclude that the smart card trusts the local platform—otherwise, the platform would not have the image.

Trusted Display Controller

If the TPM is integrated into the display circuitry, such that it becomes a Trusted Display Controller (TDC), the TPM can have exclusive control over what is shown on the display and can prevent platform software from reading what is on the display. This provides a more reliable method of indicating to the user the level of trust between the smart card and the platform.

The concept is an extension of that described earlier, where an image is stored on the user's smart card and displayed on the platform's monitor only if the smart card trusts the platform. In this case, the smart card can store an additional image that indicates that the smart card has discovered a TDC. The smart card encrypts this image so that it can be decrypted only by the TDC, and sends it to the TDC. The process is conceptually simple after the smart card has identified and accepted the TDC as a genuine TPM: a temporary symmetric key is exchanged between the smart card and the TDC, and used for encryption of the image. When the TDC receives the encrypted image from the smart card, it is decrypted and displayed on the platform's monitor. The user knows that his smart card releases this image only to genuine TDCs, and that software processes on the platform cannot read displayed data. Hence, the user knows that when he or she sees this image, the smart card trusts the platform and the platform has a TDC.

Using a Portable Security Challenger with a Built-in User Interface

A portable security challenger with a proper user interface can also be used to enhance a user's confidence in TPs. The portable challenger could be a mobile phone, PDA, smart card reader, biometrics reader, etc. Being personalized devices, portable challengers can be more easily trusted by their owners than other open computing platforms (such as PCs) because they are easier to control. It is also possible to constrain software that is executed on a portable challenger (i.e., such a device could even have known and fixed software/firmware). If a portable challenger is a more open platform that allows downloading and executing arbitrary software, it should itself be a TP, permitting control to be kept over its software state.

An advantage of using such a portable challenger is that it helps solve the problem of establishing a trusted communication path between the challenging device and the user. The portable challenger can act as the IA-enabled smart card for the purposes discussed in this chapter, and communicate its findings to its user through its own user interface.

Trusting a Platform with Biometric Information

Biometric technology is used in many applications instead of a password-based identity (see, for example, [Davida et al. 1998]; [Jain et al. 1999]; [Seidman 1986] and [Shu & Zhang 1998]). Their main advantage is their convenience, because it is hard to forget physical characteristics! A biometric reader is part of an authentication process that does a soft comparison between a Biometric Code (BC) (a registered template of individual's biometric information) and the Biometric Data (BD) (recently captured biometric information), and decides whether there is a match. The authentication process then releases authorization information, perhaps a random string or just a simple Boolean pass/fail value. Biometric readers have their drawbacks, such as false acceptance and false rejection, but the most fundamental is that a user's biometric information, such as face, fingerprint, hand, iris, etc., is unchangeable [Woodward 1997]. After biometric information has leaked, its owner is at a potential disadvantage because the owner can't change his or her biometric measurements. Another problem is that a remote entity cannot trust the results of a biometric authentication unless the correct BC is used, the BD is gathered properly, the comparison is done properly, and any authorization information is stored properly. It follows that biometric authentication should be done by a trusted device. This can be a trusted biometric reader per se, but a TP that incorporates an ordinary biometric reader provides a convenient alternative.

To implement a trusted biometric authentication process, a smart card or Portable Security Challenger should verify correctness of the platform, including the biometric reader, and display the results to the user as described above. If the check passes, the user knows that it is safe to use the biometric reader because the platform will not misuse any information that it gathers. A third party knows that it can trust the biometric authentication process because it was performed by a TP in a particular state. The BC could be stored on the smart card or on the platform. If stored on the smart card, the BC should be revealed to the platform only if the smart card trusts the platform. If stored on the platform, the BC should be sealed to a safe software environment, so that it cannot be interpreted unless there is minimal risk that the data will be misused or subverted. More detailed information about this approach can be found in [Chen et al. 2000] and [Pearson et al. 2000].