Applying a Security Kernel Framework to Smart Meter Gateways

This is the title of a paper I wrote together with Michael Gröne, and which I presented at ISSE 2012. As part of my work at Sirrix we developed this security architecture for smart meter gateways and leveraged earlier work on security architectures for distributed IT systems, as we did in the EMSCB and OpenTC projects, i.e., building on the Turaya security framework.

Smart grids are a heavily discussed topic in the European Union and many other countries. Smart Meter Systems are going to be deployed worldwide. However, due to their complexity and interconnectivity, they have to deal with strict security and privacy requirements. As a result, German regulatory bodies decided a proactive approach and developed a protection profile for Common Criteria evaluation, i.e., specifying explicitly security requirements for gateway components. In this paper, we describe the challenges and requirements that have to be fulfilled to build a smart meter gateway according to the BSI protection profile in Germany. Moreover, we present and discuss a modular secu-rity framework approach that can be used to realize such gateways in order to fulfill the requirements of the protection profile. This security framework is based on a security kernel approach that has been developed within various other projects. The proposed security kernel framework offers a solution to meet these security requirements while keeping the architecture modular and flexible to be used for other implementations as well.

The figure above shows the architecture of the approach. A key feature of the security kernel framework is that it allows executing isolated application domains on top of it. Applications belonging to one domain can communicate freely with each other. A communication to other domains is prevented by default. If communication between domains (or to external systems) should be allowed, then this must be stated in the security policy of the system. In the instantiation of our framework for the smart meter gateway, we isolate the execution of all services that are used to realize the logical functions of the gateway. In particular, we de- fine four security domains, one for each of the logical main functions, and in addition one se- curity domain for the basic services of our security kernel. As other applications might be in- troduces later, we can define further security domains to separate them from the main logical functions and the basic security services. As one possible instantiation of the framework, we use type enforcement mechanism to provide mandatory access control and labeling of all data and network connections. This is enhanced by additional components (security services) that control all incoming and outgoing network connections and those that enforce the information flow control of the software com- ponents within the gateway.

More information: [Slides]

Flexible Patient-Controlled Security for Electronic Health Records

This is a paper I wrote together with Thomas Hupperich, Hans Löhr, and Ahmad-Reza Sadeghi. I presented a poster on it at the 2nd ACM SIGHIT International Health Informatics Symposium (IHI 2012) in Florida, USA. In this paper we present a new security architecture for Electronic Health Records (EHR) systems in which we let the patients control the confidentiality of their EHR data in an easy an flexible way. Existing approaches to protect the privacy of EHRs are either insufficient with respect to strict privacy laws or they are too restrictive in their usage. For example, smartcard-based encryption systems require the patient to be always present to authorize access to medical records. In our approach, we propose a security architecture for EHR infrastructures that provides more flexibility but retains the security of patient-controlled encryption. In our proposal patients are able to authorize access to their records remotely (e.g. via phone) and time-independent for later processing by the physician. The security of our approach relies on modern cryptographic schemes, in particular Attribute-Based Encryption, and their incorporation into an EHR infrastructure.

The key idea of our approach is to avoid the use of smartcards as a direct input for encrypting and decrypting EHRs. Before medical data is to be stored on an EHR server, the patient provides his smartcard only to generate a transac- tion code (TAC) which will be used as authorization secret. The encryption key is only based on the TAC and the pa- tient’s identity. When the EHR is to be read again, the patient gives the TAC to the health professional who needs to access the EHR. The novelty in this approach is that pa- tients do not need to be present with their smartcards for decryption, but can provide the TAC via, e.g., phone.

More information: [Paper]

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]