Title: TIME PROBLEM

The security vulnerability arises through the time division of both events of the platform attestation, which presents a log (Mercuri, 2003) and of the service usage, which for security reasons can only take place after an evaluation or audit of this log. The time necessary for the evaluation of the attestation is dependent upon how much information can still be procured by the user for successful evaluation. Even if all the necessary information is available in the equipment used by the user due to earlier local interactions with this service provider, this time span will become smaller but always be present. In detail, the evaluation can comprise the examination of the following points:

1. Verification of the authenticity of the platform configuration: With a signature of the configuration generated by an AIK, the validity of the AIK certificate is to be verified. For this, an enquiry is to be directed to the issuer, who gives information about whether the certificate has been meanwhile marked as revoked. If it is a question of an attestation by means of DAA, i.e. the platform configuration is signed with a TPM-generated key pair, this source is to be verified by DAA. For this, no further query of a third party is required.

2. Verification of the platform configuration: In this step, it is to be verified that the service platform was not influenced by applications or components which change the properties of the service application. This task can be very complex and require the employment of a Property Based Attestation Proxy (Poritz, Schunter, Herreweghen and Waidner, 2004) for mapping. For this task, additional processing time accumulates which lies between a platform attestation and the service utilization.

illustrates the fact that the attestation can already be outdated during the transmission to the user. The evaluation requires additional time. If this runs successfully, it does not relate to the point in time of the completed evaluation, but to the point in time of the last raised entries of the platform attestation.

Figure Log and audit collection.

From this, it can be derived that a service user uses a platform whose current state remains unverified. A service user could merely maintain that the platform was in a certain state at an earlier point in time. As this state must no longer prevail, all assertions about the system at the point in time of the attestation lose their validity due to lacking verifiability. Despite the possibility of authenticating service applications of the service-providing system and drawing conclusions from this about the behaviour of the service system, the user no longer has a secure assertion about the confidentiality at the point in time of service utilization. 

This security vulnerability can be exploited by two attacks, as illustrated in the following section. 

Attacks

Personal data that is to be transmitted during service utilization can be intercepted by an attacker and used elsewhere. The user would be unable to enforce his security preferences particularly when he wishes to transmit sensitive data such as biometric attributes to a third trustworthy service but an attacker manages to divert this to untrustworthy services. By an attacker trying to use system states that are consistent with the state expected by the user in order to divert the service utilization to his own unverified service applications after successful verification of the platform, he gains access to data of the service user. 

This attack can take place both internally, i.e. within the platform as well as externally, i.e. from outside the platform.

Internal Attack 

An internal attacker can, for example, use the time for the verification of the platform through a service user to replace ongoing service applications with his own applications. For this, it is not absolutely necessary for an attacker to have special rights in the system. By using this same service, the attacker could terminate it in order to replace it with his own service. This attack could lead to a service user utilizing a service which was not the object of the security check performed. Another service application could have collected personal-related data of the user. 

The concept used in many operating systems, so-called privileged service access points restricts the registration of services for users of the system with insufficient rights. This concept does not however present a satisfactory solution.

Attacks on the operating system by internal attackers are not taken into consideration here. It is assumed that the operating system used isolates users and their data and processes from one another. An isolation of ongoing processes and their storage areas safeguards against attacks on data and application code during operating time. Furthermore, it is the basic prerequisite in order that the checksum calculation of an application, as the TCG specification states, can be associated with its execution. A checksum calculation for the verification of execution would be senseless if this application could be executed in a modified way after its measurement. Present-day operating systems do not yet generally have effective isolation of memory. Approaches expected in the future that are based on micro kernels and on virtualization on the hardware side promise improvements within this context.  

External Attack 

An attack through an externally operating attacker constitutes a classical man-in-the-middle attack. The external attacker thereby uses the attestation communicated by a service system to his favour by diverting the communication to his own system after successful verification. shows a man-in-the-middle attack and the point in time from which the communication can be taken over by the attacker. An attacker who has the possibility of placing himself in the communication range between the service user and a service platform which is to be attested can abuse an attestation of an external platform for his own purposes. After the successful communication of the service platform attestation to the service user (steps 1 and 2), the attacker brings the original service system to a halt in a wireless network through a flooding attack (denial of service) (step 3). The attacker now takes on the role of the original service provider with his own service applications (step 4).

While an attacker requires access to the network infrastructure for redirecting data in cable-bound networks, the technical barriers are smaller in cable-free networks, e.g. WLAN/WiFi. Through a denial of service attack, the connectivity of the service system can be disrupted and an attacker can direct the entire communication to himself through an address conversion.

Figure External attack: man-in-the-middle

It is thus possible for a service user to utilize a service which was not the object of the security verification performed. This means that it cannot be guaranteed that the user contacts his intended service and that the confidentiality of his data is endangered through release to an unintended service. 

Time Problem in Detail

In the following section, the time problem and its effects on the validity of the attestation of a platform is examined in detail. For a clear presentation, the problem is divided into two perspectives. On the one hand, this is the view of the platform configuration of the service system itself; on the other hand, this is the view of the platform of the service system produced by an attestation of an enquirer. The view of the enquirer is always behind the current platform configuration. The externally visible service access points (SAP) also form part of this perspective. presents the view of the platform at the point in time of the attestation. The figure illustrates the state of the platform to be attested and the view of this platform from outside by a service user. The top half of the figure shows the current state of the ongoing processes and applications on this platform as well as the number of processes no longer existent (currently empty). In the table column of the view from outside, the invocation history of the applications and software components is presented in shortened form, whose checksums are extended in the PC registers in the TPM. The lower half of the figure illustrates the view of the service user of the platform from outside. This comprises the service access points accessible to him and the system state after an attestation of the platform.

The view of the platform therefore coincides with the view from outside. The invocation history of the platform and its attestation is presented in the form of an abbreviated list that itemizes the application names invoked. The number of ongoing processes reflects a partial amount of the applications invoked. The number of processes no longer existent merely serves as an illustration of the further process flow. 

Figure Platform view and view through attestation of the platform at the point in time t.

The state of the attested platform should be “frozen”, which is only lifted again with service utilization. This is, however, not a good idea for several reasons. All activities of the platform, even those that are not primarily required for the execution of the desired services, must be halted. This results in 

1. waiting states which adversely affect the system efficiency and make it vulnerable to denial-of-service attacks and

2. a system providing several and varied services that is unable to make any assurance about the quality of the provision of service, such as guaranteed maximum response times.  

In the following, a possible development of the platform is illustrated, which can be produced by an internal attacker. The illustrated modification of the platform results in a service user contacting a service access point which was formerly registered by another service and thereby starts transferring personal data to an unintended service. If this platform modification is carried out deliberately, this can constitute an attack on the confidentiality of user data. schematically illustrates this modification. With regard to , the state of the platform has changed, whereas the view from outside is unchanged, but in the meantime no longer corresponds to the actual circumstances. The decision to use a service on the part of the service user is therefore based on a no longer valid context. The inconsistency of the platform and the user perspectives can be exploited for an attack, whereby an internal attacker registers unverified applications (malexec) with the service access point of verified service applications (service_0).

Figure Platform view at the point in time t+t’ and view from outside (by attestation) at point in time t.

An internal attacker can try to bring service applications to an end for example (shown in by the set of dead processes), so that the opportunity exists of registering the temporarily released service access point through his own service application.

The information required for the security evaluation at the point in time of service utilization shows the entries that were added after the platform attestation and therefore did not flow into the security verification. The possible difference between the platform view and the view of the enquirer is presented in via a PC register of the TPM. This problem basically concerns every PC register. Through the possibility of loading and executing applications, the platform changes continually. The view from outside can only be extended by a renewed attestation. This is done by means of a selected PC register which records the hash values of executed applications. Since an allocation is to be made, only a few registers are affected by a change through the start of an application.

Figure Difference between the two views.

The security verification of the platform based on the platform’a attestation is therefore no longer applicable. At the same time, not every modification of the platform causes the platform to be no longer in a trustworthy state. This should be made clear so that an external enquirer can recognize such modifications without any doubt and evaluate them.