Trusted Virtual Domains on OKL4: Secure Information Sharing on Smartphones

This is the title of a paper I have written together with Lucas Davi, Alexandra Dmitrienko and Christoph Kowalski, and it was presented at ACM STC 2011. It is on of our first attempts to bring the idea of Trusted Virtual Domains (TVD) as a security model to smartphones. Since smartphones are often used both for private and business purposes, it is crucial to separate the data and applications of these different security domains.

In the paper we present the design and implementation of the TVD security architecture for smartphones. Therefore, we have implemented a TVD framework on top of the OKL4 microkernel, which provides the basic isolation properties that are necessary to run different execution environments isolated from each other on the same device. As execution environments we use instances of the Android operating system. Essentially, our approach is (to the best of our knowledge) the first realization of the TVD policy enforcement for Android. In particular, we present the design and implementation of the TVD framework on top of the OKL4 microkernel, and we support to run Android operating system instances and Android applications in isolated environments. Moreover, we have developed a policy mapping tool that translates the general TVD policy rules to specific security mechanisms of the OKL4 kernel.

More information: [Paper]

Uni-directional Trusted Path (UTP): Transaction Confirmation on Just One Device

This is the title of a paper I have written together with Atanas Filyanov, Jonathan M. McCune, and Ahmad-Reza Sadeghi. It was published and presented at DSN 2011. In this paper we address the question whether a trusted path from a system to a user has to be bidirectional for all use cases, i.e., authenticating the system to the user and authenticating the user to the system. The answer is no, there are use cases that allow a uni-directional trusted path (UTP), just from the user to the system. We identified use cases such as transaction confirmation in online purchases or CAPTCHAs as possible applications.

Essentially, our approach allows users to confirm a transaction without the need to having them know that the application they are interacting with is actually trustworthy or not. Recent hardware offers compelling features for remote attestation and isolated code execution, however, these mechanisms are not widely used in deployed systems to date. We show how to leverage these mechanisms to establish a "one-way" trusted path allowing service providers to gain assurance that users' transactions were indeed submitted by a human operating the computer, instead of by malware such as transaction generators.

Based on the concept of a uni-directional trusted path, we architect a trusted confirmation and optionally authentication agent that executes in CPU-provided isolation. The trusted computing base (TCB) of the trusted agent is relatively small compared to prior works (a few thousand lines of code), and remains compatible with users' existing operating system and application environments. The following picture shows the high-level design of UTP.

When the client requests an action from the server that requires a confirmation of the user's intent, the server establishes the uni-directional trusted path by sending a message to the client (and a random nonce for the purpose of preventing replay attacks). The (untrusted) client program invokes the execution of the UTP Agent in the CPU's secure execution mode. This mode ensures that the UTP Agent executes isolated from other software and successfully takes control of the user-centric I/O devices. The UTP Agent displays the message provided by the server (e.g., a transaction summary) to the user. Once the user has viewed the message and acted as required (e.g., confirmed their intention to submit the transaction), the UTP Agent assembles the necessary data to generate an attestation
that these events transpired while in the secure execution mode. This information is cryptographically signed by a keypair that is accessible only while the isolated execution environment is active, in order to demonstrate its authenticity and integrity. The data and its signature are then sent to the server. The server can verify the signature with the provided
and certified public key of the client platform, and subsequently verifies the attestation information in order to get
assurance about the execution of the UTP Agent. Note that this is more than just TCG-style attestation. If the verification succeeds, the server knows that a uni-directional trusted path to the human user has been established and that the transaction can be processed.

More information [Paper] [Slides]

Trusted Virtual Domains on OpenSolaris: Usable Secure Desktop Environments

This is the title of a paper I wrote together with Hans Löhr, Thomas Pöppelmann, Johannes Rave, and Martin Steegmans (all from Ruhr-University Bochum). I presented the paper at ACM STC 2010 in Chicago last year. I think it's worth to share the main idea here, too. Moreover, below you find the links to the paper and the slides of my talk.

Trusted Virtual Domains (TVDs) are a new framework for the implementation of secure multi-domain / single-infrastructure computer networks like centralized data centers or single organizational LANs that span over different physical places. A Trusted Virtual Domain is a set of virtual hosts that are distributed across multiple physical machines and that share a common security policy. Computational resources from different owners share the same physical infrastructure, while strong isolation is enforced between members of different TVDs by the underlying security framework.

Since most existing TVD implementations are research prototypes, not available for the public, and focus on servers and data centers, there are only few efforts on secure desktop environments. To fill this gap, we present in this paper an open-source implementation of TVDs based on the OpenSolaris operating system. We leverage several of its existing features (e.g., lightweight virtualization, security labels and a secure graphical user interface) and extend OpenSolaris with components for automated management and policy enforcement to create a usable desktop implementation of TVDs. This includes the transparent encryption of external storage and home directories of users, restriction of copy-and-paste according to the TVD policy, efficient deployment of images for user environments, and a central management interface for the administration.



The picture above shows the architecture of our TVD on OpenSolaris implementation. The general idea of our architecture is to use the built-in lightweight virtualization features of OpenSolaris, i.e., the zones, to separate the different TVDs from each other. The global zone executes the necessary management code, and deploys and starts the virtualized environments (zones)
representing a TVD. Our system relies on the OpenSolaris kernel which enforces and provides security features such as mandatory and discretionary access control. For intra-TVD communication, our TVD layer establishes logical links between the virtualized environments on different platforms that belong to the same TVD. This logical network is completely isolated from any network traffic from outside that TVD, thus establishing secure channels between the TVD members. The transmission of policies and keys, as well as management messages, is separated in another logical network which cannot be accessed by any TVD. This management network is also used for accessing the network storage that is provided to every user as persistent storage mechanism.

OpenSolaris offers several interesting features, the most prominent ones we used are the filesystem ZFS for our zone image deployment, and the secure graphical user interface (Secure GUI). The screenshot below shows the graphical desktop environment with the trusted path functionality: The GUI system always shows to which TVD a window or virtual screen belongs to (red TVD or green TVD in this example), and this information cannot be faked as the top-most menu bar, the trusted stripe, is under control of the Secure GUI system. Applications running in the TVD zones cannot modify or fake this information.



In this work, we have shown that it is possible to implement TVDs for end-user desktop systems based on OpenSolaris. Our TVD framework features integrated management and transparent data encryption, an efficient deployment of zone images, and puts a particular focus on the ease of administration. Our implementation adds a TVD layer to the OpenSolaris system without any modification of the existing kernel or core security features. Demo videos and source code will be available on the project website.

Paper | Slides

A Note on the Security in the Card Management System of the German E-Health Card

This is a paper I wrote about the German E-Health Card ("Gesundheitskarte"), where I've analyzed the security implications of the Card Management System (CMS). I presented the paper at eHealth 2010 in Casablanca, Morocco, last week. While previous work did a lot of security analysis concerning the German Healthcare Telematics infrastructure -- including network security, access control, peripheral parts, and platform security -- the card management system was neglected and got less or no notice from security experts. However, taking a closer look into the specifications from Gematik, one can find serious security flaws and conflicting requirements that ultimately lead to a loss of data sovereignty of the patient, i.e., the patient is not under control of his/her data stored in electronic health records (EHR) any more. The good news are that the deployment of the CMS and especially the EHR within the telematics is currently on hold. But the bad news are that the specification of the CMS is still in an insecure state and might be used in future when EHR systems are going to be deployed that use the eHC.

From the abstract:
The German compulsory health insurance system will introduce an electronic health card (eHC) in the near future. The eHC is supposed to enable new applications like securely storing electronic health records of patients in a central data center infrastructure so that health professionals can access these data via a common network. In this context, the card management system (CMS) is of special interest since it is used to personalize, issue, and maintain the cards. In this paper, we analyze the functional requirements specification of the CMS in Germany and identify several conflicting and ambiguous requirements. As the most important result, the specification defines technical measures that are insufficient to protect the data and data sovereignty of the patient. We discuss the resulting consequences, which might be helpful to improve the system design before its final deployment.

More information: [Paper] [Slides]

Securing the E-Health Cloud

This is the title of a paper I wrote together with Hans Löhr and Ahmad-Reza Sadeghi. Today, I have presented it at IHI 2010 in Arlington, Virginia, USA. In this paper, we point out several shortcomings of current e-health solutions and standards, particularly they do not address the client platform security, which is a crucial aspect for the overall security of e-health systems. To fill this gap, we present a security architecture for establishing privacy domains in e-health infrastructures. Our solution provides client platform security and appropriately combines this with network security concepts.

We present two models of e-health clouds: a simple one pertaining Personal Health Records (PHRs), and an advanced one pertaining Electronic Health Records (EHRs). We point out the difference in the paper, and discuss three major security problem areas: (i) data storage and processing, (ii) infrastructure management, and (iii) usability.

To solve on of the problems, i.e., that of client platform security, we propose to construct privacy domains for the patients’ medical data as a technical measure to support the enforce- ment of privacy and data protection policies: Systems (e.g., a client PC) must be able to partition execution environ- ments for applications into separate domains that are iso- lated from each other. Data is kept within a privacy domain, and the domain infrastructure ensures that only authorized entities can join this domain. Moreover, data leakage from the domain is prevented by the security architecture and the domain infrastructure. Therefore, the same system can be used for different work flows that are strictly isolated. The following picture shows the architecture:



Moreover, we discuss in the paper open research challenges in e-health scenarios, in particular those related to healthcare telematics infrastructures.

[Paper] [Slides]

Patterns for Secure Boot and Secure Storage in Computer Systems

This is a paper I wrote together with Hans Löhr and Ahmad-Reza Sadeghi. It was presented at the SPattern 2010 workshop, co-located to the ARES 2010 conference. This paper describes two fundamental concepts of trusted computing in terms of security patterns, namely the Secure Boot pattern and the Secure Storage pattern. Although security patterns exist for operating system security, access control, and authentication, there have not been any on trusted computing particularly (to the best of our knowledge). Secure boot is at the heart of most security solutions and secure storage is fundamental for application-level security: it ensures that the integrity of software is verified before accessing stored data. Our paper aims at complementing existing system security patterns by presenting the common patterns underlying the different realizations of secure boot and secure storage.

[Paper] [Slides]

A Pattern for Secure Graphical User Interface Systems

This is a paper I wrote together with Thomas Fischer and Ahmad-Reza Sadeghi. It was presented at SPattern 2009 workshop in Linz. Several aspects of secure operating systems have been analyzed and described as security patterns. However, previous patterns do not cover explicitly the secure interaction of users with the user interface of applications. A secure user interface system has to provide a trusted path between the user and the application the user intends to use. The trusted path must be able to ensure integrity and confidentiality of the transmitted data, and must allow for the verification of the authenticity of the end points. Our paper presents a pattern for secure graphical user interface systems and evaluates its use in different implementations. This pattern shows how to fulfill the security requirements of a trusted path while preserving, in a policy-driven way, the flexibility that graphical user interfaces generally demand.

The central idea is to mediate all user input/output through a Secure User Interface (SUI) system, and to separate the content drawn by applications from what is actually displayed on the screen. The SUI controls solely the graphics rendering hardware and the input events from the user input devices (typically, keyboard and mouse). The picture shows the participating elements.

[Paper] [Slides]