Resources
- Identity Use Cases & Scenarios.
- FIDIS Deliverables.
- Identity of Identity.
- Interoperability.
- Profiling.
- Forensic Implications.
- HighTechID.
- Privacy and legal-social content.
- D13.1: Identity and impact of privacy enhancing technologie.
- D13.1 Addendum: Identity and impact of privacy enhancing technologies.
- D13.3: Study on ID number policies.
- D13.6 Privacy modelling and identity.
- D13.7: Workshop Privacy.
- D14.1: Workshop on Privacy in Business Processes.
- D14.2: Study on Privacy in Business Processes by Identity Management.
- D14.3: Study on the Suitability of Trusted Computing to support Privacy in Business Processes.
- D14.4: Workshop on “From Data Economy to Secure.
- D16.3: Towards requirements for privacy-friendly identity management in eGovernment.
- Mobility and Identity.
- Other.
- IDIS Journal.
- FIDIS Interactive.
- Press & Events.
- In-House Journal.
- Booklets
- Identity in a Networked World.
- Identity R/Evolution.
This section investigates on the employment of the so-called information flow analysis (Tse and Zdancewic, 2004) for an encapsulation of a service application for logging events. The aim is to obtain information about the contents of a communication and storage. By this, a communication or storage of non-protection-worthy data should be differentiated from protection-worthy data. The number of suspicious factors should be reduced and distinguishable from actual cases of misuse.
The technical prerequisite for this is that a security typed programming language has been used for implementing the service application. The aim is to trace the information flows in the application in order to be able to better classify communication channels.
A decisive feature of a typed language is the so-called type inference. This means that the type of each function or each printout can be concluded from their individual criteria without having to explicitly specify this. Irrespective of whether it involves a static or dynamic type inference, this task is derived during the transmission period of an application or during execution.
Security typed languages extend typing with security types. Academic representatives of these application languages are FlowCAML (Simonet, 2002) and JIF (Myers and Liskov, 2000). Typed languages which differentiate between the types of variables and objects, types for designating confidentiality or integrity are used for security typed languages. By means of this marking, the flow of information through the application can be analyzed via the type inference. Data once provided with a type carry this during the entire application execution. The analysis of the information flow takes place on the basis of the security types. It thereby becomes apparent whether information has flowed to or from a typed date or object. The information flow can be traced on this basis and is also controllable via an arrangement of the security types. The information flow analysis thus forms an access control model for confidentiality at variable or object level.
Applied to objects in which protection-worthy data is filed, the type inference ensures that security types are continued and derived irrespective of the processing of data carried out. It is therefore necessary to mark data objects for storing confidential data at the outset by a security type suited to the confidentiality. In , a security type must be allocated for the user data collected that can be recognized again by the monitor during a communication.
The prerequisite of this approach is a proper functioning of the type inference and the initial allocation of security types. Through the use of TCPs, it can be verified to the user whether certified software is used that implements an execution environment with type inference and an initial allocation of security types. The application does not have to be an integral part of the software components to be certified, whereby the certification outlay is restricted to one execution environment with information flow analysis and to the allocation of security types.
Solution Approach
The execution of non-certified applications likewise takes place in a sealed execution environment. However, the monitor has an information flow analysis with which the information flow of typed objects and communication interfaces can be monitored. For this, the service application must be written in an application language with support for the security types. The presence of this execution environment must be verifiable and have the following functionalities:
Allocation of security labels: The execution environment allocates security types to objects before processing to indicate their confidentiality level.
Type inference: The type inference takes care of the transmission of security types to objects that are dependent on confidential data and could flow off via the personal data.
Monitor: The monitor in the execution environment supervises information flowing away via communication channels by means of allocated or derived security types. Objects that are designated with a confidential security type can be regarded as confidential information flowing away.
The certified execution environment with the initial allocation of security types for indicating protection-worthy data must, in turn, be authentifiable by the user. The quality of the entries of the log produced depends on this. Certified execution environments are identified by the Remote Attestation functionality of a TCG-compliant platform. The TC-authenticated service access points serve to prevent possible attacks when transmitting protection-worthy data.
The execution environment of the encapsulated service application supports the information flow analysis. With the communication of data into the encapsulation, personal data of the user is provided with security types. The type inference ensures a continuation of the security types during processing through the application. If sensitive data is communicated by the application, this can be detected by the security label types and logged. Confidential contents are distinguishable from non-confidential contents on account of the security types and the log precision improves. The proper allocation of security types and type inference must be ensured. The use of Trusted Computing platforms serves here for identifying the components for this task.
Figure Encapsulation of an Application with Information Flow Analysis and Security Types.
Experiment: Tariff Calculation
On the basis of a sample application, the suitability of the information flow analysis as monitor for supervising a service application was examined. For this, a personalised service was produced which constitutes a tariff calculator for a life insurance and takes into account protection-worthy user data when generating the tariff. A user of this service is, in addition to an individual tariff generation, also interested in his transmitted attributes being confidentially processed. Furthermore, he wants to have the opportunity of acquiring knowledge as to whether data about him is being stored or transmitted.
To realize the sample application, the information flow analysis of the FlowCAML application language was used. With the aid of type inference, the security types and an access control model can be mapped on the basis of a hierarchical arrangement of the security labels. This arrangement determines the information flows permitted. It is formulated in the form of a so-called flow statement. With the static information flow analysis, allocations are examined at the point in time of the application compilation on the basis of the hierarchical arrangement of security types. An inadmissible allocation is then excluded during the application cycle. As the previous information analysis included all possible information flows compared to the hierarchical arrangement of the types at the point in time of the compilation, the information flow analysis was not used in the experiment at the point in time of compilation.
The information flows that took place during the execution that are caused by the processed instructions on the execution path are of interest. The interactive type inference interpreter, which derives the security types, serves to determine the actual information flows. The application is thereby executed up to an assertion where the information flow analysis determines an unauthorized allocation owing to a security type. This violation is written down in the log and the execution continued.
An allocation of security types which classify incoming data was consequently made for all input and output channels. This step is of wide significance, since the results of the service application cannot be interpreted with incomplete allocation or an allocation of the security types unsuitable to the application situation. Therefore, not only do network interfaces represent communication channels, but also the input/output of the consoles and read and write accesses to persistent data memory.
Classification of Security Types
Protection-worthy data is transmitted via the communication channel from the user to the encapsulated service application. Before processing, it is to be allocated a security type, by means of which the type inference can determine the flow of the data transmitted in the application. Since it is conceivable that protection-worthy data contains attributes which allow a direct reference (e.g. via a bank connection) or an indirect one (e.g. via gender), the transmitted data was divided into confidential and less confidential attributes. This enables the transmission of attributes not classified as confidential to sub-services without inference to the user concerned. Classification of the attributes can thereby depend on the application scenario and was organized as follows in the scenario of the sample application.
Attributes such as name, age, address, income and bank data were classified by the confidential security type. The attributes of marital status, occupation, gender, smoking habits and sporting activities were classed as less confidential by the security type unclassified. illustrates this.
This classification is further refined analogous to . A separate security type is thereby allocated to each attribute in order to get a more exact assertion about the information flows that have taken place.
Logging by Information Flow Analysis
For the generation of a log of the data flows during an application, an interactive tool was used for the derivation of type inferences. The sample applications were executed stepwise therein and the log of the information flows presented in and generated. Since FlowCAML makes access control decisions on the basis of security labels and their hierarchical ranking, no ranking was defined for this experiment in the first instance. During execution of the application, operations and accesses to objects are detected that are not permitted due to a non-specified information flow. At the same time, the type inference system derives the policy necessary for this instruction. It leads to the log of the information flow that has taken place. Subsequently, the information flow which led to the violation is allowed in order to be able to carry out the instruction.
Protection-worthy personal data are classified according to their confidentiality with the security type confidential and the type unclassified. The objects of the insurance are marked with the security type insurance and the standard output channel with the security type stdout. The underlying application for the log in reads in some personal data of the user and by case differentiation on the basis of certain attributes calculates a tariff, which is subsequently issued. The left side shows the processing steps and the personal-related attributes involved. The log of the information flow that has taken place is illustrated in on the right-hand side.
shows the information flows from objects with the type confidential and the type unclassified, which have influenced objects of the insurance type and were released via the standard output channel. A more precise utilization of individual attributes of the service user is not attainable with the rough classification of user attributes into two security type categories. A more exact allocation of security labels in solves this problem and indicates or eliminates a flow of confidential information through the log of the output channels. This permits a differentiated view in contrast to the observation of the communication and storage of an encapsulated application without information flow analysis.
Instead of the classification of several attributes through one security type (as in ), each individual attribute was provided with its own security type. This has direct effects on the generated log, which is a transcript about the attributes used. It can now be detected, particularly by the communication and storage of the tariff, whether data is transmitted with a security type and which data it concerns.
The first step in shows the influence of the tariff through personal attributes of a user. Since the attribute income is evaluated with the type vertraulich/confidential, a flow of data of the type vertraulich/confidential to data of the type versicherung/insurance is logged. Further access to objects of the same type leads to the same output. They do not contribute to the later evaluation of the log (step 2). An alteration of the log is triggered by the evaluation of an attribute with another security type (step 3). As the output channels are also provided with a security type, a communication has an impact on the log too. The tariff output via the standard output (in step 4) leads to a flow of data marked with the type insurance into the standard output channel stdout. Since the user data previously flowed into the calculation of the insurance tariff, this is also logged. Information flows into communication channels and persistent memories are hence loggable.
Figure Information flow report expands during the course of the application execution.
Figure Refined Logging of the Information Flows.
Personal data is provided in turn with security types for storing objects. However, instead of a subdivision of the attributes into the categories of confidential and unclassified, a more refined subdivision with individual security types for each attribute is introduced. The log of the information flow that has taken place thus reflects the influence of objects through individual attributes and enables a more precise logging. The log of the execution now shows attribute-related information flows accessed that are extended by the attribute type (steps 1 to 3). During the communication of several attributes for the purpose of a statistic collection, the log shows the information flow that does not communicate any data regarded as confidential (step 4). Through the storage of the tariff in step 5, data flows from objects with the security type insurance to a persistent data carrier that is labelled by the type diskwrite. The object concerned was influenced by information from objects with the types sport, smoker, income. The log from step 3 is therefore extended by the flow to diskwrite (step 5). The concluding log thus consists of entries from steps 4 and 5.
The individual allocation of one security type per attribute shows in detail the information flows through the log. The communicated content can be checked for confidential attributes with data exchange that has taken place and is no longer to be compulsory equated with a potential transmission of data.
At the same time, the information flow analysis shows which data is used and processed for the service provision. No precise assertion about the actual application of an attribute can be derived and it remains unclear whether an attribute in a typed object was transmitted into an object without loss of information, or whether the flow materialized through an operation with a reduction of information. However, the context in which typed attributes are used is shown.
Conclusion
The application of the information flow analysis presents an effective extension of the encapsulation of non-certified service applications. Suspicious factors created by a communication or storage can thus be avoided. The processing of an application can be made transparent with regard to the requirements. The following prerequisites are necessary for this:
Allocation of security types for input and output: Incoming and outgoing data must be provided with a security type. Particularly for outgoing information flows, e.g. to sub-services, it must be ensured through the encapsulation that a security type is inseparably transmitted with the data. Furthermore, the transmitting communication partner must be convinced that:
with the recipient a service application is present in an execution environment with information flow analysis
security types are continued in his system.
An execution environment that has these attributes can be authenticated via the TC-authenticated service access points presented.
Standard terminology and semantics of security types: For the allocation of security types for variables and objects that store personal-related attributes, it must be ensured that the service providers involved and the service user have a common understanding about the significance and use the same terminology of the security types. If no generally accepted ontology is found for this, misunderstandings can arise during the evaluation of the execution protocol.
The type inference detects information flows which take place within a service application and lead out from the application. From the point of view of privacy, not only can threats arise for a person whose confidential data is published without authorization, but also when individual objects that are each classified as non-confidential are merged together as one. Through a combination of this non-confidential data, a specific property vector can be produced which adequately describes a user and is suitable, for example, for recognizing the person concerned (Sweeney, 2002).
It is therefore interesting to examine whether a security type is to be allocated to a quantity of objects typed as non-confidential that is rated higher than the types of the individual objects for identifying a threat. The underlying models of current approaches for analyzing information flows (FlowCAML, JIF) do not consider this aspect.
30 / 39 |