Title: TCG BASED MONITORING OF UNCERTIFIED SERVICES

This section examines the utilization of a non-certified service application. The application was not examined by an independent entity and therefore a user has no information whether a confidential processing of protection-worthy data takes place within this application. The service application can therefore also be regarded as a so-called black box (see ), about the insides of which no information is obtainable. The behaviour of a service application with regard to use, storage and transmission of personal data is not transparent to the user.

If no technical measures are used for the protection of personal data, the user must trust a service application and its operator that processing only takes place within the framework of the agreement. In the following, the processing of protection-worthy data is therefore to be made transparent to the user. Even if a misuse of data thereby cannot be prevented, it can be established after service utilization whether confidential processing has taken place. Possible violations can thus be later identified and lay the foundation for further steps, e.g. legal sanctioning. 

It is assumed that a service provider behaves according to the prevailing regulations and user requirements, in order to not risk any detriment through possible misconduct in the form of legal steps, a customer withdrawal or the loss of his reputation. Even if a remaining risk of misuse through a subsequent evaluation of the processing of personal data cannot be dispelled, the transparency of a processing provides the incentive for a service provider to behave according to a published policy or one prescribed by the user. 

Figure View of the service application as unknown application.

From the point of view of a service provider, the observation of the execution of a service application offers several advantages compared with a certification or the publishing of the source code of a service application:  

1. No necessity for certification of the application: It is not necessary to subject a service application to an intricate certification or a test.

2. Applications can be modified: Due to the unrequired certification, a re-certification is dispensed with, which is necessary for a service application modification.

3. Flexible implementation of a data protection guideline: It is left to the service provider as to how he enforces his data protection guideline.

4. Publication of the source code is unnecessary: The publication of the source code and the related drawbacks can be avoided.

5. Test of the user’s observance of a policy: The service provider can use a transparent processing to examine his own service application for confidential processing. Possible violations of a data protection guideline can be hereby detected and subsequently dealt with.

As a user draws on the protocol of the execution as an indication of the confidential processing of protection-worthy data, its authenticity must be ensured. This involves the authentic generation and recording by a generally accepted component for monitoring, whose function mode is confirmed by an independent certifier. Furthermore, it involves the authentic transport of data to the user by a secure logging protocol. The authentic transport of log data is described in (Accorsi, 2005) and is not closely examined here. 

The solution approach presented in the following examines the logging of the processing of protection-worthy data in a certified service application by a certified monitoring component. This constitutes the basis for a transparent processing and evaluation, which can detect a possible misconduct of the service provider.  

Service Application as a Black Box

It is assumed that a service application is available in binary code and does not allow any insight into the application logic so that the behaviour with regard to the application, storage and transmission can be drawn or derived. The application is therefore regarded as a black box.

For already existing and non-certified applications, only the observation of the behaviour during execution remains. The aim thereby is to observe and protocol (generation of a log) the application flow as precisely as possible. Possible violations with regard to the application, storage and transmission can thus be later analyzed through an audit of the generated log data. 

A further requirement is the execution of the service application in a sealed environment. This protects the application itself from unauthorized read/write access and a readout or modification of its memory areas. A monitor that controls the service application and logs its events is to be especially protected from unauthorized access. Otherwise, the quality of the logging cannot be ensured.  

Encapsulation of the Service Application

If one assumes a compiled service application, there are only limited possibilities to gain information from the binary code about the behaviour with regard to collection, storage and delegation of personal data. The remaining possibility is to let the application run in an environment that observes the execution and protocols a log. This environment, referred to in the following as encapsulation, can, however, only log events that are detectable from its point of view. In the case of a compiled application, these are system calls to the operating system for storage and transmission, but not via the use of data within the application. shows the encapsulation of a service application in an execution environment. A monitor between the application and the interfaces of the underlying operating system observes the communication. Outsiders, such as the user of an encapsulated service application, must thereby be able to rely on the quality of the data collection through the monitor. The monitor must log all events and prepare them in such a way that a subsequent modification or removal of individual log entries is not possible or at least detectable (Schneier and Kelsey, 1999; Accorsi, 2005).

Authentication of the Encapsulation

Encapsulation with the respective monitor forms the basis for the logging of the application execution and is responsible for the quality of the log generated. A user must therefore be able to assure himself of the presence of an encapsulation which satisfies his requirements of a protocol. The user can authenticate a certified encapsulation to that effect with a service application executed therein through the TC-authenticated service access points.  

Instead of authenticating a service application, the encapsulation with the service application executed within is authenticated. The use of TC-authenticated service access points ensures the confidential delivery of protection-worthy data to the service application executed within the encapsulation. At the same time, it gives the certainty of transferring data into an environment that provides assertions about the processing. 

Figure Encapsulation of an unknown application in an execution environment.

The shows an unknown application (therefore considered to be a black box application) which runs in a sealed execution environment. A monitor controls the incoming and outgoing communication of the execution environment and protocols the events in a log. In order that outside users can make an assertion about the data quality of the monitor, it is necessary to be able to authenticate this in the form of a service application. An available TPM and the TC-authenticated service access points, serve for this, which provide this evidence and allow the authentication of the execution environment when utilizing its service access points. The monitor of the execution environment must thereby control all available communication channels. The generated log can be analyzed by an audit.

Criteria for an Authenticated Encapsulation

An authenticated encapsulation must fulfil important requirements in order to make a possible anomaly noticeable when processing user data with individual user preferences. As the observance of an application by the monitor of the encapsulation cannot avoid but only log any anomalous processing, it is additionally necessary to be able to identify the service provider. 

1. Identification of the service provider: The identity of the service provider must be able to be clearly established in order to be able to bring him to account in the event of a violation. The authentication of the application alone, as with the collection and processing through a certified service application, is not adequate in this case as violations owing to non-certified applications are possible. The execution environment and the monitor must be authentifiable however, as they are responsible for the provision of an authentic base data.

2. Identification and monitoring of the communication contents: The encapsulation must be in a position to consistently monitor the communication led by the application and its contents. This includes the communication via networks and the protocols used thereby, so-called Pipes, Shared Memory, Semaphores and the communication via files. All ways suitable for transmitting information are basically of significance. However, a monitoring inevitably comes up against boundaries as it can observe known communication channels only. So-called Covert Channels are not thereby detectable. Service applications that were designed with regard to an execution in a sealed environment could theoretically use different variants of concealed channels in order to avoid identification and thus the monitoring of a communication.

3. Identification of the communication end points: The encapsulation must be in a position to clearly identify the end points of a communication like source/destination service access points of a network communication and of pipes, semaphores etc.

4. Classification of confidential data channels: The extent of the collection of data via the communication activity of the encapsulated application can depend on the communication end points and the classification of their trustworthiness. The classification of communication partners into trustworthy or untrustworthy partners thus reflects in the amount of log data and can serve to reduce data emergence. The communication channel between the encapsulated service application and an unknown communication end point is to be observed more precisely, for instance, than the communication channel between the user and the encapsulated application.

Furthermore, the encapsulation of a service application should have properties which enable a collection or an allocation of events to a service session. 

1. Relating a service application to the user: The logged events of a service application must be able to be connected with the user responsible. By this is implied that a service application may only serve one session with one service user simultaneously. Alternatively, a service application serving several sessions simultaneously could make an allocation of logged events itself. This means, however, that responsibilities and the functionality for generating a log are hereby shifted into the application. However, this endangers the independency of the monitor from the application.

The events of the encapsulated application must be authentic and be integer transmitted to the user. For this, the generation and the transport of the log must satisfy the following requirements: 

1. Generation of authentic log data: The monitor in the encapsulation displays the events of the application carried out. It is of interest to a user that a monitor is used that implements the set requirements. One therefore only relies on the log of a monitor, to which the observance of the set requirements is confirmed or certified. The presence of an encapsulation with certified monitor can be verified with the TC-authenticated service access points presented.

2. Authentic and integer transport of the log data: The log data collected is to be made available to the user. The authenticity and integrity of the data during transport, e.g. through previous checksum formation, signature and time stamp, is to be thereby ensured (Hohl, 2006).

Evaluation of a Service Usage Log

The monitor of an encapsulated service application records all communication and storage events. Excluded from this are non-detectable side channels which the monitor cannot detect. However, no assertion can thereby be made as to whether protection-worthy data has left the application by an unobserved communication or storage.  

To verify this, application-dependent filters would be required which also have insight into the contents of the communication and detect the transmission of protection-worthy data. However, the encapsulation would lose its independency of the application. Furthermore, application-dependent filters would have to have the necessary algorithms and keys for decipherment when an encrypted communication takes place. This also poses an intervention in the encapsulated application. 

As the content of a communication or memory cannot be more closely classified, it must be assumed that not only the communication between the service user and the encapsulated application, but any other communication transports and transmits protection-worthy data. 

The conceptional weakness of the encapsulation of non-certified service applications bases on the fact that suspicious factors can only be dispelled by an absence of events. Observance of the information flows of protection-worthy data within the service application is not possible. 

Proof through Communication not Taking Place 

In the following, utilization restrictions when processing personal data are listed whose observance can be verified by means of the log generated. It is assumed that these restrictions were formulated in the form of a security guideline by the user before service utilization or an existing guideline was accepted. The specification language used must be at least able to specify the following cases: 

1. No permission for transmission: A transmission of data after the utilization of a service can be ruled out beyond any doubt if no communication to other computers or processes has taken place. Storage of data on persistent data carriers only presents a problem in this connection if data access of written data is not limited to the encapsulated application. A cryptographic binding of encapsulated application and its data can guarantee this.

2. No permission for persistent storage: A persistent storage of data, which can include personal attributes of the user, can be detected through the absence of write accesses to persistent data carriers. However, the case is to be considered where data was transmitted. The restriction of non-persistent storage is consequently also transmitted to sub-services. One possibility for the inclusion of sub-services is shown in . The log of all service platforms involved may therefore not contain any entries about the storage of data. Provision for this is that:

1. 1. trustworthy log data also is generated on the sub-services. The primary service can examine each sub-service by a platform attestation and classify the communication channels as trustworthy if the service applications of the sub-services are likewise executed in encapsulated execution environments with monitors.  

   2. the log data of all sub-services involved is also accessible to the user for verification. 

1. No permission for transmission and storage: The implementation of this requirement can be detected by the absence of entries on the communication and on the storage in the log of the encapsulated application on the service-providing platform. The inclusion of sub-services is excluded.

Figure Service with Sub-Services.

If the service utilized by the user is based on so-called sub-services, formulated user requirements, such as no persistent storage of the data are transmitted to these services. In order that an evaluation of the logging can subsequently take place, all platforms involved must execute their services in a logging environment and the generated log must be made accessible to the user. 

Uncertainty with Existent Communication 

The restrictions when monitoring a communication from the standpoint of an external monitor make it difficult or impossible to make an assertion whether protection-worthy data is an integral part of the content of a communication. A monitor could be fitted with a row of filters for standard protocols to get a detailed insight into the events. This may be possible for a few protocols. However, due to the multitude of protocols, this approach is too involved and fails even when using encryption. Moreover, no easy to filter and general format for presenting personal data is known which meets the requirements of various applications and could be used accordingly.  

Definite assertions can therefore only be derived from the absence of events concerning transmission and storage. Even if services, which are dependent on the communication with other services for carrying out a job, do not communicate any personal data, a suspicious factor is roused by the pertaining log. 

Model: The Oblivious Terminal

The model of an oblivious system was applied to a service in a hospital environment. In the example scenario, a patient can take a look at protection-worthy data, such as his hospital records, at a public terminal. In this example, this does not endanger the privacy of the patient, irrespective of the software used in the terminal. 

In contrast to an encapsulation which only observes, a functionally limited encapsulation is used here. This prevents unwanted information flows and ensures confidential processing, irrespective of the software used. Resource restrictions and the functionality of the encapsulation are thus transmitted to the service application executed therein. Through the verification of such restrictions, properties regarding the protection of protection-worthy data are recognizable. 

This was achieved by the use of an encapsulation that does not have any outgoing data channels other than those for the communication with the user, and only has limited storage capacity. The application executed therein is not in a position to store or transmit protection-worthy data over the period in time of several sessions. Instead, storage space must be again released. Obliviousness is thereby inevitably implicated. Owing to the service capacity of present-day systems that are equipped with extensive storage capacity and communication possibilities, an artificial restriction must be applied. Analogous to virtualization approaches such as VMWare, chroot or jail, an encapsulation is mapped and implemented on a high-capacity system through an additional abstraction level between application and system.

A prototype of a service for the retrieval of protection-worthy data was realized by means of a Unix operating system. An attested encapsulation with limited storage and communication possibilities was thereby implemented and is consequently unable to persistently store and transmit data.

The user of the terminal initiates a service session by inserting the health chip card. Before the health chip card of the patient guarantees the terminal access to the stored content, the card first examines the terminal and for this purpose demands a disclosure of the state. If the terminal can authenticate itself successfully towards the health chip card as a terminal which only provides the contents of the health chip card with an encapsulation with the above-mentioned restrictions, the interaction is continued. The obliviousness of the system was technically implemented by a virtual machine which has the named restrictions and after termination of the session, or on removal of the health chip card, performs a cessation of the session by overwriting the used memory area.

In , the technical setup is shown that initiates a service application in an encapsulated environment on the Unix derivate NetBSD and makes its checksums accessible to the health chip card. The figure shows the prototypical setup of an oblivious terminal. The application of the terminal is thereby carried out within a sealed environment which cannot be overcome by internally running applications. The properties of the sealed environment are thereby transmitted to the executed application. The health card of a patient examines the configuration of the terminal and of the execution of the application in the sealed environment. The card only ensures access to stored data when this step has been successfully completed. If the terminal cannot prove the presence of a sealed environment, the communication is terminated.

Figure Prototypical realization of an oblivious terminal.

The course of the communication is shown in and shows the verification of the execution environment through the user’s card. If the execution environment of the terminal does not correspond to an expected value known to the card, access to the card is not given and the transaction is thus discontinued.

Figure Course of the communication with oblivious terminal.

The figure illustrates the card and terminal outputs. The functionality of the card was thereby mapped on a standard operating system. The card examines the execution environment (step 1) of the terminal. If this or its checksum is known to the card, a read only access of the terminal to data stored on the card is allowed. In addition, the communication and storage possibilities of the execution environment are limited (step 2) and the service initiated (step 3). If the execution environment of the terminal cannot authenticate itself successfully to the card, access is denied.  

Through the encapsulation restrictions which are transmitted to the executed application, a permanent storage, transmission and thereby also use of protection-worthy user data elsewhere is prevented, irrespective of the service application used. An encapsulation that identifies and logs precisely these data channels can prove to a service user whether protection-worthy data was stored or transmitted. 

It is therefore adequate for a user to be able to examine in advance whether his data is collected through an encapsulated application with the aforesaid restrictions. However, a functionally restricted encapsulation cannot be used with service applications that, for service provision, have to access persistently stored data or are dependent on a communication with other services. 

Conclusion

The encapsulation of an application in a sealed environment allows the observation of the communication and in this way enables the logging of the workflow. Provided that the service application is only available in the binary code, this appears to be the only possibility for a service user to gain insight into the processing.  

The logged execution of a service application can be used for applications with simple communication behaviour and proves to its users that their protection-worthy data was not stored or transmitted. The encapsulation provides a tool for these applications which can improve the acceptance of this application due to the certified reporting through the monitor and analyzability. 

The aim of being able to trace the processing of protection-worthy data in a way that processing deviating from a policy can be established beyond any doubt cannot be completely achieved. The log generated from the view of system invocations is too inaccurate to be able to evaluate more closely the cases where a communication has taken place and uncertainty about the contents transmitted exists. For this, approaches are necessary that allow assertions about the incoming and outgoing contents of a communication. 

It would then be possible to make an assertion whether protection-worthy and indicated data has been transmitted to a communication interface or a persistent memory. On the one hand, this allows an exact logging and evaluation of a log with regard to storage and transmission for frequently communicating applications. On the other hand, the number of suspicious factors declines, as the communication becomes classifiable into protection-worthy and protection-unworthy data. The employment of the information flow analysis examines this case in the following section. 

A conceptual weakness of the monitoring and logging of events is the uncertainty as to when an application has concluded the processing of a service. This point in time must not necessarily coincide with the point in time of the completion of a session and could lie temporally behind this. The evaluation of an incomplete log can therefore not detect a dangerous situation due to lacking entries. A further restriction is that during the execution of the service applications, only one service user can be served. When dealing with several users simultaneously, the clear allocation of the log of a session to the respective service user cannot be ensured. The monitor of the execution environment can detect several users merely by means of several communication relations. A subsequent allocation of further events is not possible. Service applications are therefore to be laid out in such a way that each session is operated by a separate service application.