Title: SOLVING THE TIME PROBLEM BY TCG ATTESTATED SERVICE ACCESS POINTS

The authenticated service access points are an answer to the danger of an attack which is present due to time differences between the platform attestation and the service utilization. The essential difference from a usual identity-based authentication of a service provider here is that a formerly attested service application is authenticated before its utilization. The identity and also other attributes of a service provider can of course be authenticated, which can additionally contribute to the increase in accountability.  

The solution of the time problem is necessary as the attestation of the service platform does not allow any conclusions about the service application to be used (cf. section 5.3.2). The approach to the solution of the time problem prevents the premature obsolescence of the entire platform attestation and ensures at least its partial correctness. In addition, the introduction of a service-dependent association between the attestation and individual services leads to an enquirer being able to ascertain whether he is communicating with the desired and previously attested service or has unexpectedly got into contact with another service application. This preserves the service user from both internal and external attacks and thereby ensures that he can safely contact a service application which, in his view, is classified as trustworthy.  

In section , it was illustrated that the attestation of a platform differs from the view communicated to the enquirer in the execution of further applications or in a downloading of libraries and in this form therefore no longer constitutes the suitable basis for a verification of security.

Not all entries lose their validity however when examining the attestation at process level. Assuming that the underlying operating system effectively isolates processes from one another and thereby ensures their persistence, applications started at later points in time do not have any influence on already existing processes. Under this condition, individual attestation entries are valid up to the end of the corresponding processes, although the attestation no longer reflects the current platform state.  

It is thus necessary to identify to external enquirers the entries, whose validity remains through the start of further service applications and produce a verifiable allocation in the attestation entries between the service access points and the pertaining applications. 

Linking of Attestation and Service Access Points

In this section, a linking between the attestation of a platform and its service access points is described. This enables the user to determine whether he has contacted a service which was previously part of the attestation and therefore the security verification. Internal and external attacks can thus be detected on the part of the user and consequences drawn. 

A verifiable allocation of service access points and attestation entries can be realized by a cryptographic key pair which produces a verifiable linking between the view of the service access points and the attestation. This key pair forms the basis for the service user being able to authenticate the intended service after an evaluation of the attestation. To facilitate that only the original service can successfully authenticate itself to the service user and services of external as well as internal attackers are not in a position to do so, the following properties must be fulfilled for the authentication. 

1. Uniqueness: It is to be ensured that authentication secrets are unique for the duration of a service application. A clear allocation of service access point and associated process would not be possible if the secret were to be used for the authentication of several services.

2. Unpredictability: The schema for the selection of authentication secrets may not generate, or generate only extremely difficultly predictable key pairs for authentication. The use of the generator implemented on the TPM can be used instead of a software-based implementation for the generation of random numbers and key pairs.

3. Authentic transport: The generated authentication secrets must be authentically and integer communicated to a user. This means that an attack on the transmission, such as a modification for instance, may not be possible or must be recognized without any doubt.

The requirement of uniqueness and unpredictability of a key pair is required by many cryptographic protocols and is implemented by a careful disposal of used key material and by scientifically discussed algorithms for key generation. 

The current methods for the authentication of a service system or its transmitted data are based on certification authorities and signed server certificates. An authentic and integer transport of the key material could therefore be authentically and integer communicated in this case too. 

The employment of an additional certification authority should however be abstained from to avoid further complexity. Instead of this, the required security goals can be mapped with the trust relations already existing, which are available for the operation of trusted computer platforms. 

Authentic Transport through Platform Attestation

It is to be definitely ensured that a user is able to authenticate the attested service applications of a platform. The authentication of the platform is thereby initially second place. Platforms complying with the TCG specification can authentically convey the state or the configuration externally by way of the remote attestation and thereby have an authentic transport channel. This channel is however restricted in the way it can only authentically transport contents of the PC registers. 

These must therefore, if data, as keys for authentication, is to be authentically communicated in this way, go via the same way as applications to be executed or configurations whose checksums are filed in the PC registers. Via this loop way, the checksums of keys for the authentication of service access points can be published analogous to the checksum of applications.

For this, a public/private key serves as authentication key. The relationship of this key pair to precisely this platform becomes verifiable for a user through the publication of the checksum of the pertaining public key. The user receives the public part of the key at the start of the service utilization and can examine whether the service platform can correctly answer an encrypted query. 

Instead of the integrity measurement of executable applications as described in the TCG specification 1.1, the checksum of the authentication key is extended into a PC register of the TPM. The TCG specification in Version 1.2 provides for more flexible handling of the PC registers: 

The decision of whether a PCR contains a standard measurement or if the PCR is available for general use is deferred to the platform-specific specification (Trusted Computing Group, 2003b). 

The utilization of the PC registers for the checksums of authentication keys does not affect the utilization of the registers in their original function of storing application checksums. Through a clear identification marking and differentiation of keys and applications, the list can be successively validated and tested for consistency with loaded applications. 

Linking of Service and Authentication Keys

An allocation is to be made between the checksums of executed applications contained in a platform attestation and the checksums of generated authentication keys. An authentication key can thus be allocated to each application that serves a service access point. Only if a clear allocation is given a service user can determine the checksum pertaining to the authentication key on the basis of the service intended and verify this at the start of the service utilization. As the TP module is not able to do this due to functional limitation, this lies in the task and trust area of the operating system. Two variants are conceivable as to how this allocation can be made: 

1. Explicit Linking: Through an explicit naming of the authentication key pertaining to an attested application, these can be brought into contact. It is to be noted, however, that the presentation of this linking must be clear and signed. As the platform attestation only signs the data stored in the PC registers, but the application names recorded in the invocation history by the operating system are not signed by the TPM, a further key would be required. This should however be avoided in favour of a more simple solution. shows the chain of checksums signed by the TP module through the attestation and its application names in the centre column of the table, which are to be signed by a further key. In addition, a signature of the program names should not imply correct names of applications and applications.

Figure Explicit linking of the attestation of a process and its authentication key.

1. Implicit Linking: An explicit naming of an authentication key can be dispensed with if its allocation to the application is clear without additional information. Thus, both the explicit linking and the necessity for its signature are inapplicable. An implicit linking can be expressed by immediate succession of the authentication key onto the application in the invocation history. Implicit linking is shown in . The entry of the pertaining authentication key directly follows the entry of an2 application in the invocation history. A signature of the names of the hashed applications and objects can therefore be dispensed with.

Figure Implicit linking of the attestation of a process and its authentication key.

As no additional key material and thus no further trust relationship is required for implicit linking, this approach is pursued in the following for reasons of simplicity. 

The requirements of uniqueness and unpredictability of an authentication secret are achieved through the use of suitable key generators. The requirement of authentic transport is achieved by the loop way of communicating the checksums of the authentication keys authentically via the attestation. Through an attestation, the actual state of the register is signed and therewith implicitly also the chain of the checksums, which have led to this state.

It is only disadvantageous here that an authentication key pair must be generated for each application, irrespective of whether this registers a service access point. 

Linking permits a user the authentication of the desired service application for the operating period. Owing to the process isolation anyway required for TC platforms, the start of further applications and hence the modification of the platform has no effects on an ongoing application. The user ensures by way of the authentication that it is a question of a service application which has flowed into the platform attestation and thereby also into a connected security verification. External and internal attackers who confront a user with a service application other than the original cannot be successfully authenticated by the user and are thereby recognizable as untrustworthy. 

This means that a user can only successfully authenticate services which have also flowed into the platform attestation and have not been terminated. A further reason for an unsuccessful authentication can therefore be, in addition to the external and internal attacks mentioned, a terminated and restarted service with newly generated key material. This case can be counteracted with by a repeated attestation which then has to bear the checksum of the authentication key pertaining to this service. 

Integration of Authentication in the Service Session

The service is to be authenticated at the start of the service session. For this, the public part of the key, whose checksum has in fact flowed into the attestation but has not yet been published, must be conveyed to the service user. The service then counts as being authenticated when the checksums coincide and the platform can correctly reproduce an encrypted challenge of the user. The actual service utilization subsequently follows in this session. 

It is therefore necessary to integrate the authentication to be performed into the service or its service session. In order to keep the investment into the implementation of the service authentication low, it is desirable for the following requirements to be fulfilled: 

1. Protocol-independency: The implementation should provide authentication to be used by the service irrespective of the protocols applied (i.e. does not necessitate a modification of the protocols).

2. Independency of various authentication mechanisms: An implementation should enable service-specific authentication mechanisms, provided that these do not interact.

3. Support of existing implementations: An implementation should enable already existing service application implementations to be able to be used via authenticated service access points without being modified.

Network security protocols which are based on the session layer for the configuration of encrypted channels are suitable for this. They can enable the authentication of the session participants. It is therefore merely to be ensured that the generated key material for the authentication is used in the security protocol applied and that the utilization of such a protocol is essential when registering a service access point. illustrates at which point in the area of responsibility of the operating system the application is possible. The Transport Layer Security (TLS) (Dierks and Allen, 1999) and Secure SHell Protocol (SSH) (Ylonen, 1996) are suitable network security protocols. There is no need for their modification in the registration and utilization of service access points for the service application.

Figure Application of a network security protocol through the operating system.

In summary, two individual steps are established that are necessary up to the registration of a service access point of an application. These are: 

    1.    The start of the service application on the service platform is subdivided into:

1. The operating system calculates the checksum of the application. It initiates an extension of the PC register intended for applications in the TPM and supplements the invocation history with new entries. It starts the application in an isolated execution environment. 

2. The operating system generates a key pair for the service application for authentication. The checksum of the public part is likewise extended in the TPM and added analogous to the invocation history. This key pair is made available for the security protocol applied. As an implicit allocation of key to the application is used, the succession of the PC register extensions in the TPM must be guaranteed. 

3. The service application registers service access points. The operating system prompts the service access points to be secured in the security protocol through tunnelling. 

    2.    The platform is available for use with service applications.

1. The user requests the attestation of the platform. 

2. The user analyses the attestation information and conducts a security verification of the platform or initiates this. 

    3.    A user decides for or against utilization of the platform.

1. If the user has decided for utilization, he authenticates the intended application via the service access points and ensures that he has contacted the desired and attested service. 

Attacks on the confidentiality when collecting data through internal or external attackers can be recognized by a failed authentication. For this, the mechanisms of the trusted computer platform according to the TCG specification form a supporting element.  

Discussion of the Solution Approach at Issue

In addition to the implementation presented, further approaches for avoiding successful attacks when collecting data are conceivable, which are compared in the following. Some appear to offer a solution, but on closer examination prove to be inadequate or complex to realize. 

Authentic notification of service access points

In order to not unintentionally connect with an undesired service, it is not adequate for an attested platform to disclose the access points in an authentic way, as this is no guarantee that this state still prevails at the point in time of service utilization and that the desired services are still at the original place. The following attacks are possible: 

1. An internal attacker could replace the original service application in the meantime with a defective application and register at the same service access point. 

2. An external attacker could divert the service utilization to another system by a man-in-the-middle attack.

Re-Attestation

A renewed attestation of the platform after service utilization allows limited conclusions about an orderly application flow. This solution can, however, only take effect afterwards and, furthermore, does not provide any clear indication whether an attack has taken place during the collection of personal data. 

A subsequent security check in the form of a renewed attestation provides the enquirer with the history of the accessed service applications. In order to enable an enquirer to conclude from this that no attack has taken place, the following possibilities must be given: 

1. All applications executed by the platform are to be verified: Due to an unclear producible allocation between the session of the user with his service application or the remaining applications, no applications should have been on the platform that allows data collection beyond the intended service application. As the assurance of individual attributes of an application is complex, this complex process would additionally have to extend to all applications. If more than two similar service applications are executed on the same service platform, whereby the user only wishes to start a session with one selected application, applications are available on the service platform that enable a collection of data beyond the intended application. A subsequent verification is therefore not possible in every case.

2. The identification of the service platform must be possible: As the service platform does not generate any authentication parameter, an authentication of the platform on the basis of an identity, which is based on a certificate for example, must be substantiated. The authentication thereby serves to avoid a man-in-the-middle attack.

Sealing

The TCG specification describes the so-called sealing functionality. This functionality enables the binding of data to a platform and its state. This means that formerly sealed data can only be used by the platform concerned and at the same time is under a predetermined configuration.  

With this functionality, a secret (secret key with pertaining certificate) on the authentication of the platform can only be made accessible if this is in a predetermined trustworthy state.

A disadvantage of this solution is that the platform configurations, under which access to secrets on authentication takes place, must be known in advance and that this configuration is preserved during operation. The start of further applications however changes a platform configuration and thereby has an impact on the accessibility of a sealed secret. Since not all PC registers must compulsorily serve as basis for an access control decision about a sealed object, more objects could be available on a narrowly limited scale for a longer period of time. A recording of further platform modifications would then however have to be filed in PC registers, which are not used as access control criterion for sealed objects.

The sealing functionality therefore forms a suitable means of attesting the long-term state of a platform. However, it is only suitable to a limited degree for representing application-related states. 

Integration of the Attestation and service-specific Protocol

It would be technically conceivable to unite the attestation and the service utilization in one session and one protocol. Through this combination, the service utilization immediately follows an attestation and possible inconsistencies between the actual state and the view from outside are not present. There still remains a threat, however, if no clear allocation can be made with the service access point used or its pertaining application from an attestation within the session. An extension is therefore necessary in this case, which ensures this before utilization of the service protocols in the same session. 

It is additionally disadvantageous that for each protocol an extension is to be specified which carries out a platform attestation and the authentication of the application before the actual service utilization. Existing implementations are to be accordingly adjusted by this extension on the server side as well as the client side. This is a very complex undertaking and reason for the development of so-called wrapper protocols. There are no further benefits with regard to security through the integration of attestation in service-specific protocols. The investment for implementation is, however, distinctly higher.