html/Open_TC_D05.2_SecServicesPoC

D05.2 Proof of Concept of the Security

Services

Project number

IST-027635

Project acronym

Open_TC

Project title

Open Trusted Computing

Deliverable type

Report (see p 84/85 Annex 1 - Nature)

Deliverable reference number

IST-027635/D05.2/Final

Deliverable title

Proof of Concept of the Security Services

WP contributing to the deliverable

WP05

Due date

Oct 2007 - M24

Actual submission date

November 23, 2007

Responsible Organisation

IBM

Authors

IBM (Matthias Schunter), KUL (Dries
Schellekens)

Abstract

This report describes the design of core
components of the OpenTC 2007
demonstrator for “Corporate Computing at
Home”. It is based on the research
documented in Deliverable D05.1 "Basic
Security Services” and is accompanied by
source code documented in Deliverable
D05.3.

Keywords

Security management, isolation policy, policy
enforcement, corporate computing at home,
2007 demonstrator

Dissemination level

Public

Revision

Final

Instrument

Start date of the
project

November 2005

Thematic Priority

IST

Duration

42 months

Contents

Corporate Computing at Home Scenario Analysis

1.1

Basic Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Threats

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Xen Security Services

2.1

Xen Security Services Overview and Implementation Status

. . . . .

2.1.1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2

TVD network infrastructure . . . . . . . . . . . . . . . . . .

2.1.3

Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.4

Virtual Private Network

. . . . . . . . . . . . . . . . . . . .

2.1.5

VM admission control . . . . . . . . . . . . . . . . . . . . .

2.1.6

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Xen Virtual Networking Devices . . . . . . . . . . . . . . . . . . . .

2.2.1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2

Background . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3

Virtual Switch

. . . . . . . . . . . . . . . . . . . . . . . . .

2.2.4

Linux Dom0 Prototype . . . . . . . . . . . . . . . . . . . . .

2.3

Management of Trusted Virtual Networking Domains . . . . . . . . .

2.3.1

Auto-deployment of TVDs . . . . . . . . . . . . . . . . . . .

2.4

Xen Hierarchical Integrity Management . . . . . . . . . . . . . . . .

2.4.1

Our Solution . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.2

Use Cases for Dynamic Registers . . . . . . . . . . . . . . .

2.4.3

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5

Xen Cross-resource Policy Validation . . . . . . . . . . . . . . . . .

2.5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.2

Formal Integrity Model for Virtual Machines . . . . . . . . .

2.5.3

The PEV Integrity Architecture . . . . . . . . . . . . . . . .

2.5.4

Realisation using Xen and Linux . . . . . . . . . . . . . . . .

2.5.5

Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.6

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6

Xen Secure GUI Services . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1

An Example Secure GUI Use Case

. . . . . . . . . . . . . .

2.6.2

Current State . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.3

Prototype Design . . . . . . . . . . . . . . . . . . . . . . . .

2.6.4

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 1

Corporate Computing at Home
Scenario Analysis

M. Unger (RUB)

This chapter presents the security requirements of the Corporate Computing at

Home (CC@H) scenario from a security infrastructure perspective. The corresponding
prototype will be presented at the 2007 project review meeting.

1.1

Basic Setting

The background of corporate computing at home is that employees often have more
powerful computers at home as compared to the office. Furthermore, computing is
ubiquitous and employees get increasingly mobile. As a consequence, it would be
desirable to perform potentially confidential corporate tasks on arbitrary computers.
The envisioned main usage is to expand the corporate network to a home computer
such that the home computer is guaranteed to enforce corporate policies.

Within the CC@H demonstrator an employee has to be able to work at home using

his own computer and to access, e.g., the company’s intranet (see Figure 1.1). For
that purpose a special, trusted corporate compartment runs on top of a virtualisation
layer on the employee’s computer. This compartment has to be secure against certain
attacks (see 1.2) and fully independent of OSes or applications running in parallel on
the virtualisation layer. The virtualisation layer either consists of the Xen hypervisor
and its security services or the L4 microkernel and security services.

The corporate compartment has to be able to set up a secure connection between

itself and a server of the company, e.g., a VPN gateway. While setting up this secure
connection, attestation is done to ensure that the client’s corporate compartment run-
ning on the employee’s computer is in a proper state and can be given allowance to
connect to the company’s intranet.

On the server-side no special virtualisation techniques are used in this prototype

scenario. But of course mechanisms to verify the client’s state and to mediate access
according to the results of this verification have to be in place.

In the following section we enlist the possible threats that have to be countered by

the security services. How this is done is described within the security considerations
sections of the Xen (see chapter 2) or L4 security services (cf. chapter 3), respectively.

OpenTC D05.2 – Proof of Concept of the Security Services

Hypervisor

Internet + Game overlay network

Corporate network

Resource Isolating

Corporate
Trusted Virtual Domain

Internet

Figure 1.1: Basic Setting: Corporate and game computers hosted on a single home
computer.

1.2

Threats

The following threats have to be addressed by the security services or by the architec-
ture as a whole.

Threats to the Corporation

There are threats that have to be addressed with regard to corporate data:

•

The PC of the employee gets lost, and the finder/thief is able to read confidential
corporate data stored on the computer.

•

An attacker gains illegitimate access to the network of the corporation using its
own or an employee’s computer. This includes replacing the trusted computing
base (e.g., hypervisor) with a bogus version to obtain secret information.

•

An employee deletes corporate data accidentally or on purpose*.

Threats to the Employee

Threats that have to be considered from the perspective of the employee:

•

The employee’s system is altered by the installation of the corporate compart-
ment resulting in a situation that the computer is no longer usable for private
purposes because of, e.g., restrictive security guidelines.

•

Access to private data stored on the employee’s system may be possible for other
company members, e.g., the administrator.

Threats marked with * are not related to the security services. These have to be considered generally

and thus are not included within the security considerations of the security services.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

that a TVD is residing on. This means that on a physical host one TVD proxy is running
for each TVD that can deploy VMs on that specific host.

Each TVD proxy gets its portion of the needed TVD policies from the TVD Master

that manage all policies for a specific TVD. Policies sent to a TVD proxy include al-
lowed VMs, their reference measurements, extra configuration, TVD network settings,
and configuration for secure channels if TVD spans several physical hosts.

2.1.2

TVD network infrastructure

The TVD networking functionality enables a network infrastructure than can inter-
connect multiple virtual machines running on multiple physical hosts.

The implemented network infrastructure enables a private virtual network for each

TVD and ensures network separation by inter-connecting VMs at the Ethernet level.
This means that logically, we provide a separate virtual wiring for each TVD. As a
consequence, different TVDs do not share any virtual cables to prevent that packets
from different TVDs are traversing any shared routing tables and TCP/IP stacks. It also
gives the freedom to deploy a wide range of networking solutions on top of the TVD
network infrastructure. Network address allocations, transport protocols and other ser-
vices are then fully customizable by the TVD owner and work transparently as if the
VMs were in an isolated physical network.

To maintain secrecy and confidentiality of network data when a TVD network spans

several physical hosts the data is transferred over encrypted VPN tunnels. This enables
the use of untrusted networks between physical hosts that contains VMs within the
same TVD to provide a seamless view of the TVD network.

TVD1

VM1

VM2

VM3

TVD2

VM1

VM2

VM3

TVD1

VM4

VM5

TVD2

VM4

Host 1

Host 2

LAN/WAN

Bridge

VPN

Bridge

VPN

Bridge

VPN

Bridge

VPN

Figure 2.1: TVD Network Overview

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

2.1.3

Bridge

For bridging VMs within a physical host there are two options, either using the Linux
Kernel Ethernet Bridge functionality or the OpenTC vSwitch from HP Labs.

Both work in a similar way when it comes to plugging in VMs, and it is done

by attaching a VM’s back-end virtual network interface (vif) to the bridge/vSwitch
at Ethernet level and therefore all ingoing and outgoing packets from a VM will be
directly going to/from the attached bridge only and bypassing all higher level packet
routing/mangling/filtering outside the TVD network infrastructure.

Each bridge works in the same way as a physical Ethernet switch does by main-

taining MAC tables (with age counters) for each port (in this case connected vifs) to
keep track of where to route packets.

The Linux bridge can also handle the link management protocol STP (Spanning

Tree Protocol, IEEE 802.1D) to handle multiple hops and avoid cyclic routes if a more
complex TVD network layout is deployed. This is useful when several local TVD
networks on different physical hosts are inter-connected via multiple secure channels.

The vSwitch has capability to do VLAN tagging (IEEE 802.1Q) which is useful

when inter-connecting physical hosts with several TVDs over a trusted network such a
internal Data Center network. It works by adding tag information in the Ethernet frame
header that identifies to which VLAN a frame belongs and then send out the frame on
a shared network. Receiver and intermediate VLAN-enabled switches can then apply
rules and routing depending on which VLAN a frame belongs to. This enables better
network separation but not confidentiality.

2.1.4

Virtual Private Network

To add confidentiality to data between VMs, that belong to the same TVD but are
located on different physical hosts, the data is transferred over a secure channel between
the local bridges on each physical host.

The relaying is done on Ethernet level to keep the TVD network transparent no

matter if the VMs are residing on the same or on different physical hosts. The imple-
mented solution of secure channels uses point-to-point VPN tunnels with OpenVPN
that are configured via the TVD proxy from the TVD policies. This enables reconfigu-
ration of topology and the involved VPNs within a TVD from a single administration
point, the TVD Master.

The TVD policies distributed from the TVD Master to the TVD proxy also include

the secret key for the VPN along with other VPN specific settings. On a physical
host the VPN’s endpoint is represented as a local virtual network interface (vif) that is
plugged into the appropriate bridge controlled by the TVD proxy. The bridge’s MAC
tables are then updated in the same fashion as physical switches learn what port they
need to send on for a specific host.

2.1.5

VM admission control

When a VM is about to join a TVD its state will be verified by the local TVD proxy to
see if it complies to the policies of that TVD. If it is accepted then it will be connected
to the TVD network.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

vSwitch/

Bridge

eth0

vif1.0

eth0

vif2.0

Dom0

DomT1

(paravirt)

DomU

DomT2

(fully virt.)

eth0

tap0

Def.

Bridge

peth0

VPN

eth

udp/ip

eth

Dom0

stack

Untrusted network

Figure 2.2: TVD Network Modules within Physical Host

In the implementation this is done by having the Compartment Manager (Comp-

Mgr) do a two step interaction with the TVD proxy during startup of a VM, namely
compartment attest and compartment network attach . This is done over a socket con-
nection using the Compartment Admission Protocol (CAP) specifically designed for
this purpose.

The CompMgr makes use of a module called Integrity Service Manager to measure

the state of the VM to start. The measurements can include state of VM configuration,
kernel and disk(s) that are going to be attached to the VM.

Compartment attestation:

1. CompMgr loads the VM configuration and applies security directives such as

measuring compartment image (with help of Integrity Service Manager), unseal-
ing key and setting up encrypted storage (with help of SVDM ) and checks if
VM should be part of a TVD.

2. If security directives state that the VM should be part of TVD network then the

CompMgr sends prior to VM startup an attestation request to the TVD proxy
containing the measurements of the VM.

3. The TVD proxy looks up the settings for the VM in the policies and validates

the measurements and returns accept or deny depending on the validation result
along with optional extra settings (such a MAC address) that TVD proxy wants
CompMgr to apply on VM at startup.

Compartment network attach:

4. Once the CompMgr has started the VM it sends an attach request to the TVD

proxy containing the virtual network interface (vif) of the newly started VM that
should be part of the TVD network, and also the measurements of the VM.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

5. The TVD proxy once again verifies the VM measurements and if everything is

according to TVD policies then connects the vif to the bridge of the local part of
the TVD network and returns that attachment was successful.

The CompMgr will not start the VM if the TVD proxy returns deny during the

attestation procedure.

If the attestation step would be skipt and the CompMgr requests the TVD proxy

to attach a started VM with “bad” measurements to the TVD network then the TVD
proxy will respond saying that it failed and leave the vif unconnected, thus leaving the
TVD network unreachable by the VM by not attaching it the bridge.

The admission control protocol is depicted in Figure 2.3. The implementation de-

tails are depicted in Figure 2.4.

Compartment Manager

TVD Proxy

(Listens on TCP port 6150)

Query: Attest Compartment (Comp. ID, Comp. Meas.)

Response: Attest Granted (Comp. ID, MAC addr.)

Response: Attest Denied (Comp. ID)

TCP Socket

Query: Attach Compartment (Comp. ID, Comp. Meas., vif)

Response: Attach Ok (Comp. ID)

Response: Attach Fail (Comp. ID)

Step 1

Attestation

Step 2

Attaching

Query: Detach Compartment (Comp. ID)

Response: Detach Ok (Comp. ID)

Response: Detach Fail (Comp. ID)

Step 3

Detaching

Figure 2.3: Compartment Admission Protocol towards TVD

The extended implementation added a couple of modules to the original Security

Services architecture. Most notable is the TVD proxy that handles the enforcing of
TVD policies on a physical host. The enforcing covers accept/deny of starting a VM
depending on measurements and also admission to TVD network.

The TVD proxy further contains sub-modules that handles various networking

tasks needed to be able to provide the TVD networking infrastructure to attached VMs.
It includes modules for controlling Kernel bridge, vSwitch and VPN.

Compartment Manager

This module

•

Manages starting and stopping of VMs.

•

Verifies VM image and configuration towards TPM.

•

Sets up needed resources for a VM, such as memory, encrypted storage and so
on.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Compartment Manager

(starting/stopping VM)

TVD Proxy

(Enforcing TVD policies, controlling

vNet)

TVD Master

(Web-server containing

policy XML-file)

vSwitch ctrl.

(userland lib interfacing

kernel module)

VPN ctrl.

OpenVPN

(TCP interface to daemon)

GUI user auth.

Bridge ctrl.

(interfacing kernel

module via user-land lib)

SVDM

Secure Virtual Device Manager

(Resource allocation & setup)

Integrity Service Manager

(Measuring cfg., kernel, disks)

New implementation

Extended implementation

Not implemented

Linked function call

Protocol over socket

Figure 2.4: Implementation module details

•

Interacts with Xen (via command-line interaction) for loading a VM, starting it
and stopping it.

•

Asks TVD-proxy for VM attestation and network access via the CAP protocol.

TVD proxy

The TVD proxy runs as a separate process controlling the network re-

sources on a physical host.

It loads and parses the polices at startup and then waits for requests from the Cmp-

Mgr. The policies are specified in XML and can be read from file or remotely over any
protocol that the Linux Curl library can handle (http, https, ftp and so on).

The TVD proxy sets up the Kernel bridge or vSwitch at startup and then later starts

the VPN when the first VM is attached.

Controlling of the VPN is done via command-line interaction and using the Open-

VPN management interface which runs over a TCP socket.

2.1.6

Summary

The current implementation of the Security Services can handle at least the following:

•

Integrity enforcement of compartment configuration, kernel and system image.
The parts to be included in measurement are configurable (config, kernel, sys.
Image ). Measurements can extend a PCR in the TPM for later use in unsealing
of keys.

•

System image and additional disks to attach can be encrypted and key(s) sealed
to TPM’s base PCRs and optional an extra PCR to include earlier selected mea-
surements.

•

Compartment Manager handles running VMs paravirtualised and fully virtu-
alised. VMs stated to be part of a TVD will be attested and attached against
the TVD proxy.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

•

The TVD proxy reads policies in XML format from file or remote via HTTP,
which should be over an prior setup secure tunnel (like a TLS tunnel using a
remote attestation protocol).

•

The TVD proxy handles using both the Kernel Bridge and the vSwitch (se-
lectable) is the local bridge for the TVD network.

•

OpenVPN is used as VPN tunnel and is setup on demand and controlled by the
TVD-proxy.

2.2

Xen Virtual Networking Devices

S. Bleikertz, S. Cabuk (editor) (HPL)

This section provides details on the virtual networking prototype developed by

HPL. The prototype was fully incorporated into the demonstrator to help isolate the
corporate networking from a non-corporate one (with the difference that in the demo
OpenVPN is used instead of IPSec).

2.2.1

Overview

Virtualisation technology can be applied to several different resources in an IT envi-
ronment and is nowadays popularly used for server consolidation. Another area of
virtualisation in IT environments and datacenters is network virtualisation, which is
used to create virtual networks on top of the physical infrastructure independently of
the physical topology. Several virtual networks, each with a different topology, can be
deployed simultaneously on the same physical network, which allows consolidation of
networks and a flexible topology configuration.

A typical use case for virtual networking in datacenter environments is when sev-

eral customers share the physical resources such as servers and network infrastructure,
but each customer wants to configure and operate a network for her own servers. With-
out virtualisation technology each customer would need a dedicated physical network
infrastructure and servers to do so, which is cost-intensive and inflexible. Virtualisation
of servers and network allows the sharing of physical resources with strong isolation,
which increases the overall datacenter utilisation and reduces the costs for the cus-
tomers.

Virtualisation allows customers to specify a flexible configuration of their network

topology and server arrangement. This is because, thanks to virtualisation, no physical
reconfiguration such as changing cabling or adding new servers to a rack is needed.
This is beneficial for customers in order to rapidly react to growing demands of their
IT infrastructure.

Customers have a high demand for strong isolation to protect their confidential busi-

ness information from other parties sharing the same physical resources. Virtualisation
does not provide the same isolation as dedicated physical resources do, but allows the
introduction of further security mechanisms due to the gained flexibility of virtualisa-
tion. This section discusses how network virtualisation can be utilised to implement a
security mechanism for fine-grained isolation and policy enforcement.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

2.2.2

Background

Switch Functionality

A switch, compared to a hub, only sends incoming packets to the port, where the
destination host is connected, and not to all ports. In order to make this decision, the
switch has to know which host is connected to which port and manages this mapping
in a table. A physical Ethernet switch manages a MAC table, which maps a Layer 2
address (MAC) to a physical port.

Switch table management consists of two procedures for adding a new table entry

and removing an old one, which are called Learning and Ageing. In the Learning pro-
cedure every incoming packet is analysed and the source MAC address is extracted.
The switch knows on which port the packet was received and adds a new or updates
an existing table entry for the source MAC address with this port number. The Ageing
procedure removes obsolete entries from the table by using a time stamp for each en-
try, which indicates when the entry was lastly updated. If a certain time difference is
reached, the entry will be removed from the table. In order to have an efficient packet
transportation within the switch, these two procedures keep the table consistent and
accurate. A special case is when the destination MAC address of an incoming packet
is not in the table yet. In this case, the switch can not decide to which port the packet
have to be forwarded, so it will broadcast it to all ports, in order to try to reach the
destination host. If the host is connected to the switch it might send a response, which
the switch can use to add the table entry for this host.

Link Modes

As depicted in Figure 2.5, vSwitches are linked to each other using several different
protocols depending on the type of link between them. This section gives an overview
of these protocols, describing their functionalities, and best usage scenarios.

EtherIP

is a protocol for tunnelling Ethernet and 802.3 packets via IP, which allows

the expansion of a LAN over a Wide or Metropolitan Area Networks. Each tunnel end-
point uses a special network device provided by the operating system, which encapsu-
lates the whole outgoing Ethernet/802.3 packet in a new IP packet and then transmits
it to the other side of the tunnel. From incoming packets the embedded Ethernet/802.3
packet is extracted and transmitted to the LAN.

EtherIP does not provide confidentiality or integrity, which makes it only suitable

for routed and trusted networks in a corporate or datacenter environment, for example
when two vSwitches are located in a datacenter, but are hosted on different servers,
which are not connected on the same VLAN switch.

VLAN tagging

is a well-established standard for network isolation on physical net-

work equipment in datacenters. The standard is described in IEEE 802.1Q and uses
tagging of Ethernet packets for isolation between networks. As an example, a host in
the VLAN 42 uses a special network device provided by the operating system to apply

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

tives for implementing higher-level security policies for networking and it needs to be
configured by a higher-level management layer (e.g., security services management) .

Architecture

Figure 2.5 illustrates the general architecture of virtual networking and how several
vSwitches are linked together in a sample environment. In this scenario we have three
physical hosts, which are connected to each other using different networks and hosting
VMs of different customers or TVDs. The green TVD consists of VM 2 and VM 3
hosted on A and B, which are connected to each other using a local VLAN switch. The
isolation of the green TVD to other parties connected to this switch is realised using
the built-in VLAN tagging with the TVD ID as VLAN ID. VM 1 and VM 4 of the blue
TVD, also located on the physical hosts A and B, are using EtherIP encapsulation over
an IP-based Metropolitan Area Network (MAN), like a routed corporate network. The
members of the red TVD VM 5 and VM 6 are on physical hosts, which are connected
only through a Wide Area Network (WAN), like the Internet, and an IPSec channel is
needed, in order to ensure confidentiality and integrity.

The goal is that every VM thinks it is on the same LAN with the other VMs of its

TVD and all traffic is transmitted in an efficient and secure manner depending on the
link type and the chosen protocol. Security issues, such as communicating securely
over a WAN link, are addressed by the network infrastructure and the VMs can rely on
this mechanism and do not have to address these issues themselves.

2.2.4

Linux Dom0 Prototype

The first version of the vSwitch prototype is realised as a Linux kernel module for the
vSwitch core component and a stack of user land configuration tools. This vSwitch
is intended to operate from a Linux-based dom0, which acts as a net-backend for the
VMs and has access to the physical network interface. The current implementation is
limited to VLAN Tagging and EtherIP encapsulation as vSwitch linking modes. An
additional VPN module is employed to provide IPSec encapsulation functionality.

Implementation in Xen

Figure 2.6 depicts the Linux-based implementation of the vSwitch on a Xen platform.
The Xen dom0 acts as a net-backend for the VMs on the same host and has virtual
network interfaces called vif, where each vif has a corresponding net-frontend device
in the VM. A VM can be associated with a vSwitch using the appropriate vif device
and all traffic for a VM is processed by the vSwitch, in particular outgoing traffic is
tagged or encapsulated.

There exists two versions of the vSwitch implementation, which differs in the im-

plementation of VLAN tagging. The first version uses the pseudo device for VLAN
tagging provided by the Linux kernel. The second one has its own functionality for
VLAN and EtherIP processing, making the architecture for packet processing more
consistent. The latter also prevents the extra overhead for transmitting packets through
another networking layer.

From an implementation point of view this vSwitch version is highly coupled to

dom0 and Linux. Communication with the connected VMs is realised through the
Linux dom0 bridging and its hooks for packet interception. Furthermore, the vSwitch
registers several handlers for VLAN and EtherIP handling within the Linux kernel’s

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Host A

Dom 1

Dom 0

encap.

module

VLAN

tagging
module

Policy

Engine

vSwitches

eth0

vif2.0

vif1.0

eth0

eth0.

front-end devices

back-end

devices

physical
NIC

VLAN-capable

physical switch

Host B

Dom 1

Dom 0

encap.

module

VLAN

tagging
module

Policy

Engine

vSwitches

eth0

vif2.0

vif1.0

eth0

front-end devices

back-end

devices

physical
NIC

Host C

eth0

physical NIC

(VLAN un-aware)

Dom 2

eth0.

Figure 2.6: Prototype Implementation of the vSwitch.

networking subsystem. The vSwitch consists of the general switch functionality, im-
plementing the learning and ageing procedure for a table mapping MAC addresses to
virtual ports.

Configuration

The configuration of the vSwitch is also done within dom0. The vSwitch kernel module
provides two interfaces, one for issuing configuration commands and another one for
configuration examination. For configuration commands the vSwitch provides a device
called

/dev/hplvnet0

, which can be used to issue the following ioctl commands:

VNET_IOC_ADD_NET Create a new virtual network

VNET_IOC_DEL_NET Delete a virtual network

VNET_IOC_ADD_PORT_IF Assign a VM’s NIC to a VNet

VNET_IOC_DEL_PORT_IF Remove a VM’s NIC of a VNet

These commands allow a basic vSwitch management.
The configuration can be examined through two sysfs directories located in

/sys/class/vswitch/

and

/sys/class/vport/

The vSwitch class

is ordered by VNet IDs, like

/sys/class/vswitch/0x00000017/

where

0x00000017 is the VNet ID 23 in hex, and each entry holds specific VNet information
and links to the associated VM’s NICs such as

/sys/class/vport/vif10.0/

These two interfaces are normally not used directly by the user, but through a bunch

of user land configuration tools. These tools provide an easy to use configuration in-
terface, abstract the issuing of ioctl commands and interpret the hierarchy of the sysfs
entries.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

vnet_add id saddr daddr Create a new VNet with the given ID, source and destina-

tion IP address

vnet_control Interactive configuration shell

vnet_list List all configured VNets

vnet_remove id Remove VNet with given ID

vnet_show id Show information of a VNet with the given ID

vport_add id devname Add the VM’s NIC given by devname to a VNet with the

given ID

vport_remove devname Remove a VM’s NIC

vport_show devname Show information of a VM’s NIC

Problems

The main problem with this solution is that it operates within the privileged domain,
which should be kept minimal and only for VM management purposes. For stronger
isolation between the VMs, a disaggregation of dom0 is desired by splitting up the
functionality of dom0 into several VMs. The future versions of the vSwitch prototype
will focus on building a vSwitch as a lightweight VM only for networking purposes.

2.3

Management of Trusted Virtual Networking Do-
mains

S. Cabuk (HPL), K. Eriksson, H. Ramasamy, M. Schunter (IBM)

We now describe the infrastructure for managing our virtual networks. The core con-
cept is the notion of a Trusted Virtual Domain (TVD). The entities managing each TVD
are called TVD Master and TVD proxy.

The TVD master plays a central role in the management and auto-deployment of

TVDs. There is one TVD master per TVD. We refer to the TVD master as a single
logical entity, although its implementation may be a distributed one. The TVD master
is trusted by the rest of the TVD infrastructure and the VPEs that are members of the
TVD. Known techniques based on Trusted Computing [36] can be used to determine
the trustworthiness of the TVD master by verifying its software configuration. The
TVD master can be hosted on a physical machine or a virtual machine. In the case of a
VM implementation, the PEV (protection, enforcement, verification) architecture pro-
posed by Jansen et. al. [14] can be used to obtain policy enforcement and compliance
proofs for the purpose of assessing the TVD master’s trustworthiness.

The TVD policy is defined at the TVD master by the system administrator (e.g.,

the administrator of a data center hosting multiple TVDs, each belonging to a different
customer). The TVD master has the following main responsibilities:

1. distributing the TVD policy and other TVD credentials (such as VPN key) to the

TVD proxies and informing them of any updates,

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

2. determining the suitability of a platform to host a TVD proxy (described below),

and thereafter, periodically assessing the platform’s continued suitability to host
VPEs belonging to the TVD,

3. maintaining an up-to-date view of the TVD membership, which includes a list

of TVD proxies and the VPEs hosted on their respective platforms.

TVD proxy

On every host that may potentially host a VM belonging to the TVD,

there is a local delegate of the TVD master, called the TVD proxy. Like the TVD
master, the TVD proxy is also trusted. The TVD proxy is the local enforcer of the
TVD policies on a given physical platform. At the time of its creation, the TVD proxy
receives the TVD policy from the TVD master. Upon an update to the TVD policy (by
a system administrator), renewal of TVD credentials, or refresh of TVD VPN keys at
the TVD master, the master conveys the update to the TVD proxies.

The TVD proxies on a given platform are independent. Although TVD proxies

are trusted, TVD proxies on the same platform should be sufficiently isolated from
each other. For example, a TVD proxy should not be able to access private TVD
information (such as policies, certificates, and VPN keys) belonging to another TVD
proxy. For improved isolation, each TVD proxy on the platform may be hosted in
a separate infrastructure VM, which is different from a VM hosting regular services,
called production VM. On a platform with the Trusted Platform Module or TPM [37],
isolation can further be improved by TPM virtualisation [3], assigning a separate virtual
TPM to each infrastructure VM, and using the virtual TPM as the basis for storing
private TVD information.

A TVD proxy must only be able to interact with VMs hosted on the platform be-

longing to the same TVD. As we describe below, that requirement is enforced by the
Local Common TVD Coordinator (LCTC).

The main responsibilities of the TVD proxy are:

Configuration of the Local TVD vSwitch The TVD proxy configures the local TVD

vSwitch based on the TVD policy. For example, if the TVD policy specifies that
information confidentiality is an objective, then the TVD proxy enables all traffic
through the vSwitch to pass through the VPN module and provides the VPN key
to the module.

Maintenance of Private TVD Information The TVD proxy maintains private TVD

information such as policies, certificates, and VPN keys.

Status Reports to the TVD Master Upon request or periodically, the TVD proxy

provides a platform status report to the TVD master. The report includes in-
formation such as the number of VMs belonging to the TVD and their unique
addressable identifiers and the current vSwitch configuration. The status report
also serves as an “I am alive” message to the TVD master, and helps the TVD
master to keep an updated list of TVD proxies that are connected to it.

Enforcement of Admission Requirements for VMs into the TVD A VM’s virtual

NIC is attached to a vSwitch only after the TVD proxy checks that the VM
satisfies TVD membership requirements.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Enforcement of Co-Location Restrictions The Local Common TVD Coordinator

(LCTC) checks with each TVD proxy already existing on the platform for co-
location compatibility before instantiating a new TVD proxy.

Enforcement of Multi-TVD Membership Restrictions A VM may belong to multi-

ple TVDs simultaneously. However, approval from TVD proxies corresponding
to the TVDs in which the VM holds membership is needed before the VM can
join a new TVD.

Continuous Enforcement of TVD Policy The TVD proxy is responsible for contin-

uous enforcement of the TVD policy despite updates to the policy and changing
configuration of the platform and member VMs. Upon receiving an update to
the TVD policy from the TVD master, the TVD proxy may re-configure the
vSwitch, and re-assess member VMs’ status to reflect the updated policy. Even
without any policy update, the TVD proxy may be required by the TVD policy
to periodically do such re-configuration and re-assessment.

Local Common TVD Coordinator (LCTC)

The Local Common TVD Coordinator

or LCTC is present on every platform (hence, the word local in the name) on which a
TVD element has to be hosted. The LCTC itself does not belong to any single TVD
(hence, the word common in the name). The LCTC is part of the minimal TCB

every TVD-enabled platform.

The LCTC is the entity that a TVD master or a system administrator contacts to

create a new TVD proxy on the platform. For this purpose, the LCTC must be made
publicly addressable and knowledgeable about the identities of the entities that may
potentially request the creation.

The LCTC has three main responsibilities, namely (1) creation of new TVD proxies

on the local platform, (2) determining whether a new TVD proxy can be co-hosted
along with TVD proxies already existing on the platform, and (3) restricting access of
TVD proxies only to VMs belonging to their respective TVDs. The LCTC maintains a
list of VMs currently hosted on the platform, a list of TVD proxies currently hosted on
the platform, and a mapping between the VMs and the TVDs they belong to.

The actual creation of the TVD proxy is preceded by a prepare phase, which in-

volves

1. Mutual authentication and authorisation between the LCTC and the entity (e.g.,

the TVD master or system administrator) requesting the creation of the TVD
proxy,

2. Determining the suitability of the platform for hosting the new TVD proxy, from

the point of view of both the requesting TVD master and the TVDs already
hosted on the platform.

The second step above involves determining whether a new TVD proxy can be

co-hosted along with TVD proxies already existing on the platform. The LCTC is a
thin implementation; it simply asks each TVD proxy whether a new TVD proxy can
be co-hosted on the platform. Based on their internal security policies, the individual
TVD proxies simply return a “yes” or “no” answer. The LCTC replies positively to the

On a Xen-based platform, the minimal TCB consists of the LCTC, Xen Dom0, the Xen hypervisor, and

the underlying hardware.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

TVD Master

DomU

Dom0

TVD proxy

TVD-specific

Modules

EtherIP VLAN

…..

Policy

Engine

TVD-specific

Modules

EtherIP VLAN

…..

Policy

Engine

vNICs

…

TVD object

←

create TVD (TVD requirements, policy model)

create TVD Proxy (Master URL)

connect VM to TVD (TVD object)

Figure 2.7: Steps in Populating a TVD

requesting TVD master only if all TVD proxies said “yes”; otherwise, it returns a neg-
ative reply to the requesting TVD master. The LCTC includes a list of existing TVD
proxies with a positive response. Additionally, if required, the LCTC may include the
attestation of the platform characteristics along with a positive response. The prepare
phase concludes with the response from the LCTC. Based on the response, the request-
ing TVD master can determine whether its own policies allow co-hosting with the list
of existing TVD proxies on the platform and whether the platform configuration is in
accordance with the TVD requirements. If that is the case, then the TVD master sends
a request to the LCTC to start the TVD proxy along with its own URL. In this way, the
conflict manager helps ensure that a new TVD proxy is hosted on the platform only if
it is compatible with the policies of TVDs already hosted on the platform as well as
with those of the new TVD.

The LCTC does the actual creation of the TVD proxy, and initialises the proxy

with the TVD master’s URL. Thereafter, the TVD proxy contacts the TVD master
and establishes a direct secure, authenticated communication channel (using standard
techniques like IPSec or TLS) with the TVD master bypassing the LCTC. The TVD
proxy obtains the TVD policy and other credentials from the TVD master through the
channel, and configures the networking components according to TVD policy.

2.3.1

Auto-deployment of TVDs

Figure 2.8 shows the steps involved in automatic deployment of secure virtual infras-
tructures as TVD configurations. Figure 2.7 shows the steps involved in the establish-
ment and management of a single TVD.

First, the virtual infrastructure topology must be decomposed into constituent

TVDs, along with associated security requirements and policy model. Second, a capa-
bility model of the physical infrastructure must be developed. Capability modelling is
essentially the step of taking stock of existing mechanisms that can be directly used to
satisfy the TVD security requirements. In this paper, we consider the case where both
steps are done manually in an offline manner; future extensions will focus on automat-
ing them and on dynamically changing the capability models based on actual changes

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Security

Policy

Per-host

Extensions

Global

Configuration

TVD
Requirements

Mechanisms
Required

Deployment Planning
& Management

TVD Policy

Model

Capability

Model

Revised Requirements,
Policies, or Capabilities

Figure 2.8: Steps in Auto-Deployment of TVDs.

to the capabilities.

Capability Modelling of the Physical Infra-structure

Capability modelling of the physical infrastructure considers both functional and secu-
rity capabilities. The functional capabilities of a host may be modelled using a function

← {

V LAN, Ethernet, IP

}

, to describe whether a host has VLAN, Ethernet,

or IP support. Modelling of security capabilities includes two orthogonal aspects: the
set of security properties and the assurance that these properties are actually provided.
Table 2.1 lists some examples of security properties and Table 2.2 gives examples of
the types of evidence that can be used to support security property claims.

TVD Establishment and Population

When the set of TVDs have been identified, the next step is to actually establish them.
The initial step for establishing a TVD is to create the TVD master (step 0 in Figure 2.7)
and initialise the master with the TVD requirements (as formalised above) and the
policy model. The step involves the derivation of a comprehensive set of TVD policies,
which are maintained at the TVD master. The output of the step is a TVD object that
contains the TVD’s unique identifier, i.e., the TVD master’s URL.

Once the TVD master has been initialised, the TVD is ready for being populated

with member entities, such as VMs. A VM becomes admitted to a TVD after the
successful completion of a multi-step protocol (steps 1 and 2 in Figure 2.7).

1. A local representative of the TVD, called TVD proxy, is created and initialised

with the URL of the TVD master.

2. The TVD proxy sets up a secure, authenticated channel with the TVD master

using standard techniques.

3. The TVD proxy indicates the security and functional capabilities of the physical

machine. Using the capability model, the TVD master determines which addi-
tional mechanisms must be provided at the level of the virtual infrastructure. For
example, if a TVD requirements specification includes isolation and the physi-
cal infrastructure does not have that capability, then special (VLAN tagging or

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Property

Description

TVD Isola-
tion

Flow control policies in place for a TVD.

Network

The actual topology of a virtual network
in a physical machine.

Network
Policy

Security policies for the network, such as
firewall rules and isolation rules stating
which subnets can be connected.

Storage Pol-
icy

Policies for storage security, such as
whether the disks are encrypted and what
VMs have permission to mount a particu-
lar disk.

Virtual Ma-
chines

The life-cycle protection mechanisms of
the individual VMs, e.g., pre-conditions
for execution of a VM.

Hypervisor

Binary integrity of the hypervisor.

Users

The roles and associated users of a ma-
chine, e.g., who can assume the role of
administrator of the TVD master.

Table 2.1: Examples of Security Properties used in Capability Modelling

EtherIP) modules must be instantiated within the Dom0 of physical machines
hosting VMs that are part of the TVD.

4. The TVD master then replies to the TVD proxy with the TVD security policy

(such as flow control policies between VMs belonging to different TVDs hosted
on the same physical machine) and additional mechanisms that must be provided
at the virtualization level.

5. The TVD proxy then instantiates and configures the required TVD-specific mod-

ules (e.g., vSwitch, VLAN tagging module, encapsulation module, VPN module,
policy engine, etc.) according to the TVD policy. After this step, the physical
machine is ready to host a VM belonging to the TVD.

6. As shown by step 2 in Figure 2.7, a command is issued at the VM to join the

TVD (active membership model. This results in the VM contacting the TVD
proxy. Based on the TVD security policies, the TVD proxy may carry out an
assurance assessment of the VM (e.g., whether the VM has all required software
properly configured). Once the required verification of the VM is successful, the
TVD proxy may connect the vNICs of the VM to the appropriate TVD vSwitch.
At this point, the VM is part of the TVD.

Instantiation of the Right Networking Modules

The TVD proxy uses the instructions given to it by the TVD master to determine the
right protection mechanisms to instantiate on the local platform for the TVD network
traffic, and accordingly configures the local TVD vSwitch.

Suppose that isolation of TVD traffic is a requirement. Then, VLAN tagging alone

would suffice provided the TVD spans only the LAN and the physical switches on the

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Past State

Description

Trust

A user believes that an entity has certain
security properties.

Mutable Log

The entity provides log-file evidence (e.g.,
audits) that indicates that the platform
provides certain properties.

Immutable Logs

The entity has immutable logging systems
(e.g., a TPM-quote [36]) for providing ev-
idence. Since the log cannot modified by
the entity itself, the resulting assurance is
stronger than when mutable logs are used.

Present State

Description

Evaluations

Evaluation of a given state, e.g., Common
Criteria evaluations [21].

Introspection

Introspection of a system by executing se-
curity tests, e.g., virus scanner.

Future State

Description

Policies

By providing policies and evidence of
their enforcement, a system can justify
claims about its future behaviour. e.g.,
DRM policies and VM life-cycle protec-
tion policy.

Audit

By guaranteeing regular audits, organisa-
tions can claim that certain policies will
be enforced in the future.

Table 2.2: Assurance for Past, Present, and Future States used in Capability Modelling

LAN are VLAN-enabled (i.e., it must support IEEE 802.1Q and must be appropriately
configured); in that case, a VLAN tagging module would be created and connected
to the vSwitch. If the TVD spans beyond a LAN, then VLAN tagging must be used
in conjunction with EtherIP encapsulation. In this case, the VLAN tagged packet is
encapsulated in a new IP packet and tunnelled to the other side, where the original
VLAN tagged packet is extracted and transmitted on the VLAN. If VLAN-enabled
switches are not available, then EtherIP alone would suffice for isolation.

By itself, EtherIP does not provide integrity or confidentiality of the packets.

Hence, when those properties are required, EtherIP is suitable only on routed and
trusted networks, e.g., EtherIP would be suitable for traffic between two vSwitches
hosted on different physical platforms that are not connected to the same VLAN switch
in a datacenter or corporate environment.

If integrity or confidentiality are required properties and the underlying network is

not trusted, then IPsec is used in conjunction with EtherIP and VLAN. In that case,
the TVD proxy will create the VPN module, initialise it with the VPN key obtained
from the master, and connect it to the vSwitch. Since IPsec only operates on IP packets
and not Ethernet or VLAN ones, double encapsulation is needed: EtherIP is used to
first encapsulate the Ethernet or VLAN packets, followed by IPsec encapsulation and
encryption (using the VPN key).

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

2.4

Xen Hierarchical Integrity Management

S. Cabuk (HPL)

This section provides answers to two problems around VM integrity management: How
can we extend the integrity measurement capabilities offered by the BMSI to help sup-
port hierarchical and dynamic integrity management? How can we use these extensions
to facilitate a centralised credential management service?

2.4.1

Our Solution

We devise a framework called the hierarchical integrity management framework
(hIMF). As illustrated in Figure 2.9, hIMF sits on top of the BMSI and is comprised of
two components: the integrity management interface (IMI) and the credential manage-
ment service (CMS).

Integrity Management Interface (IMI)

BMSI LibU

The IM interface provides functionality similar to the libU library pro-

vided by the BMSI. The current BMSI libU library stores individual measurements of
protection domains and provides four functions regarding the integrity management of
these domains: extend, quote, seal, and unseal.

extend

Protection domains use the extend operation to report changes to their

integrity. These changes are static and cannot be reverted once reported.

quote

Protection domains use the quote operation to provide a signed quote of

the TCB and domain integrity measurements. TCB measurements are obtained
from and signed by the underlying hardware TPM. Domain measurements are
signed by the BMSI signing key.

seal

Protection domains use the seal operation to store a secret (e.g., a crypto-

graphic key) bound to a particular TCB and domain configuration.

unseal

Protection domains use the unseal operation to reveal a secret (e.g., a

cryptographic key) that is sealed to a particular TCB and domain configuration.
libU returns the secret to the requesting domain if and only if the unsealing op-
eration is successful (i.e,. the TCB and domain configuration is the same as
the expected values). The actual unseal is performed using the hardware TPM
with respect to the TCB configuration only. The additional domain configuration
checks are performed by the libU in software.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Figure 2.9: hIMF Architecture

IMI Enhancements

IMI provides the same functions as libU with extensions that en-

able tree-of-trust and dynamic measurements. In particular, IMI establishes an ancestry
relation between protection domains by recording the parent domain during the child
domain creation (TBD). In addition to the static registers maintained by the BMSI, IMI
introduces a dynamic register per protection domain to be used for dynamic measure-
ments. Integrity functions offered by the IMI is altered as follows:

extend

Protection domains use the extend operation to report changes to their

integrity. These changes can be static or dynamic depending on the accompa-
nying measurement policy. Static changes are reported to the static registers in
the same manner as BMSI (i.e., the underlying libU extend function is used).
Dynamic changes are reported to the dynamic registers and the previous value is
overwritten instead of being extended.

quote

This operation is the same as the libU quote except that the quote returns

a signed quote of the TCB and the measurements of the complete branch the re-
questing domain belongs to (i.e., domain plus its predecessors). TCB measure-
ments are obtained from and signed by the underlying hardware TPM. Branch
measurements are signed by the IMI signing key.

seal

unseal

These operations are the same as the libU equivalents except

that instead of a single domain configuration, the aggregation of a complete tree
branch is used. This includes all protection domains that are the predecessors of
the requesting domain.

Security services are given the option of accessing the Trusted Computing exten-

sions either through the BMSI or IMI. The former is used for the cases it suffices to
use a static and flat integrity model. The latter is used by services (e.g., CMS) that can
benefit from a dynamic integrity hierarchy.

Credential Management Service (CMS)

CMS is a security service that provides protected storage for security credentials tied
to specified policies and platform plus domain/branch configurations. The main differ-
ence with the underlying BMSI/IMI sealing/unsealing functions is that CMS creden-
tials are never revealed to the requesting services but are always stored by the CMS
securely. The CMS provides the necessary interface to allow such services access their
credentials if and only if the corresponding policy and configuration is met. In this

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Figure 2.10: CMS as a Reference Monitor

context, the CMS acts as the reference monitor that controls the access to security
credentials (see Figure 2.10).

The CMS utilises the IMI or BMSI directly depending on whether the IMI integrity

enhancements are needed. In either case, the main benefit of employing the CMS is
the ability to perform policy and configuration checks in an on-going manner (instead
of only once which is the case with non-CMS solutions). Alternatively, credential
sessions can be established that allows access to the secret without re-authentication
/ re-validation. These sessions can expire either after a duration or if a change is re-
ported to the static/dynamic register. The choice of which re-validation scheme to use
is implementation dependent and will be explored further.

The CMS interface is likely to involve two phases: registration and usage. In the

registration phase, a credential for a protection domain is registered with the CMS using
the registerCredential operation. In the usage phase, the corresponding credential can
be accessed using the accessCredential operation. The specifics of these operations
will be investigated further.

vTPM+

This service enhances the integrity measurement capabilities of vTPMs using the hIMF.
We will come back to this after the successful implementation of hIMF.

2.4.2

Use Cases for Dynamic Registers

As it has created much speculation regarding usability, we use this section to describe
use cases around dynamic integrity measurements. Recall that dynamic measurements
are used whenever one can guarantee that, for example, a configuration change can be
reversible and may not have any side or unpredictable effects on the future state of the
domain. The main critique is that it would be hard to find such a use case in which a
protection domain would recover from a possibly untrusted configuration. We provide
the following use cases in which such arguments do not hold. Feel free to comment on
and / or extend the list.

Digital Rights Management

It may well be the case that a particular media provider will not want to push any
video content on your computing accessory if it is plugged to a recording device. In
this case, software that detects and installs the plug-and-play drivers for the recording
device must be part of the static measurements. However, the state in which a recording
device is detected in the system can be reported dynamically. In fact, this can be
reflected in the dynamic register for the secure DRM player service. As long as the
recording device is connected, no content is downloaded. Once the user unplugs the

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

device, the dynamic register is reset and content can be pushed to the player without
requiring a system restart.

Data-center Trust Issues

Note that “trustworthy” is not a synonym for “secure”. A system is trusted if and
only if it behaves as expected. In a data center, trusting an individual node may also
correspond to trusting its performance, or its compliance to the requested QoS. In SoA,
a particular service may be required to meet a certain level of performance. Services
or nodes that cannot guarantee meeting the performance level may be taken out of the
service pool temporarily.

Consider an SoA setting that is comprised of

services distributed on m physical

nodes. At any time,

of these services provides the required level of performance.

That is,

of these services can be “trusted”. The remaining

−

services will have

their dynamic registers altered to reflect their temporary untrusted state. Once any of
these services can grab more resources on their physical node, they can report this
change dynamically and rejoin the service pool.

2.4.3

Conclusion

This section introduced our design of an enhanced VM integrity management frame-
work that is able to handle inter-VM integrity relations and dynamic integrity mea-
surements. These aspects will be valuable to virtulized platforms that require more
flexibility than current Trusted Computing solutions provide.

The current CC@Home scenario did not involve a use case that utilizes these in-

tegrity management enhancements, hence the resulting framework was not incorpo-
rated into this year’s demonstrator. We expect to finalize our implementation and
employ this framework as our VM integrity management solution in the next year’s
demonstrator.

2.5

Xen Cross-resource Policy Validation

B. Jansen, H. Ramasamy, M. Schunter (IBM)

2.5.1

Introduction

Hardware virtualization is enjoying a resurgence of interest fuelled, in part, by its cost-
saving potential in utility computing, where it can help improve server utilisation, re-
duce management and power costs, and control the problem of server sprawl.

Even in traditional non-virtualized environments, security protection, enforcement,

and verification of physical servers are non-trivial. Virtualization makes these tasks
even harder. Security management of virtual servers is complicated because (1) dif-
ferent virtual servers sharing the same hardware resources may be subject to different
and conflicting security requirements, (2) they may not be isolated from each other
in a verifiable manner, and (3) privacy requirements may dictate that data needed for
verifying the integrity of one virtual server should not contain information about other
virtual servers.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

We make two main contributions. We show how to protect given security policies

against modification throughout the life cycle of a virtual machine (VM). We also show
how to prove compliance with given security requirements. For past compliance, we
prove that the system state as reflected by log files satisfies certain conditions. For
future compliance, we prove that the security policies enforced imply the given security
requirements and that they cannot be modified.

In making these contributions, we also generalise TPM-based integrity protection,

enforcement, and verification mechanisms to cover virtual machines and pluggable
devices that can be governed by arbitrary security policies, e.g., isolation policies for
secure device virtualization and migration constraints for VMs. Our mechanisms are
both extensible and flexible. By extensibility, we mean that it is possible to guarantee
compliance even if arbitrary virtual devices are attached to the VMs. Flexibility means
that the verifier is able to specify security requirements to be evaluated against the
enforced policies of the VM, virtual devices, and underlying platform that it cares
about, and obtain only the information corresponding to those aspects for validation of
system compliance.

We describe a formal model for the generalised integrity mechanisms; based on the

model, we describe an integrity architecture called PEV (which stands for protection,
enforcement, and verification) and associated protocols. The architecture incorporates
integrity verification and protection as part of the virtualization software while simul-
taneously enhancing its policy enforcement capabilities. While the PEV architecture
itself is not tied to one specific virtualization software, we describe a prototype realisa-
tion of our architecture using the Xen hypervisor.

We build on previous work by others [8, 10, 29, 32, 3] who have used the Trusted

Platform Module (TPM) [38] to protect the integrity of the core virtual machine mon-
itor (VMM) and to reliably isolate VMs. The foundation of our architecture is a small
trusted computing base (TCB) that provides (1) reliable write-only logging of executa-
bles and data, and (2) conditional release of secrets, i.e., a key and a condition can be
stored such that the key is released only if the log file satisfies the condition specified.

2.5.2

Formal Integrity Model for Virtual Machines

Figure 2.11 shows our system model for integrity management. At a high level, the
system consists of hardware, the VMM, and VMs, and is configured with a policy

At a given time

, the system has an integrity state

and produces log data

log

that is

computed by a function

log

(

)

. External to the system are an audit system and policies.

The audit system stores log files,

log

∗

. The contents of log files include policy updates

and indicate the integrity history of the system, i.e., how good the policy enforcement
has been so far. The policies are needed for configuring the system and are useful in
estimating the future integrity of the system, i.e., how good the policy enforcement
is likely to be in the future. Thus, both the audit system and policies can be used to
evaluate the integrity state of the platform.

Typically, a computing system consists of a large number of subsystems and com-

ponents that may depend on each other, e.g., hardware components, such as CPU and
devices, and software components, such as kernel, libraries, drivers, and user appli-
cations. To provide extensibility, new types of subsystems may need to be added at
run-time. To provide flexibility, it is desirable that each subsystem be able to offer as-
surance only about specific aspects of its behaviour (instead of its full behaviour). For
example, a disk should be able to log some of its contents or just its access control list.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

VMM

Audit

System

policy

request

response

state

input

output

Verifier/User

Hardware

History

log*

requirements

predicate

System

log

(

)

log

(

)

Figure 2.11: System Model for Integrity Management

(

id, type, log

)

(

id, type, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

)

(

, type

, log

) (

, type

, log

)

(

, type

, log

)

(

111

, type

111

, log

111

)

(

111

, type

111

, log

111

)

…

Figure 2.12: Tree

of log entries

To support the extensibility and flexibility goals, it is necessary for our integrity

model to support more fine-grained notions of system integrity state and logging func-
tion. For this purpose, we use a tree

(as shown in Figure 2.12) for representing the

log data, where each node is a triple and there is one triple for each component in the
system. To keep the tree size manageable, the tree should include triples only for those
components that have an impact on the system’s integrity or that are of interest from
an integrity verification point of view. A triple for a component

contains an identifier

, a component type

type

, and a vector of log values

log

. Sub-components are

modelled as children of a node. The overall effect is that instead of a monolithic log
data

log

(

)

(shown in Figure 2.11), the log data is contained in a tree of vectors of

log values (shown in Figure 2.12). It can be extended by adding or removing children
nodes. For example, the addition of a new virtual device to a VM can be easily reflected
in the log tree by adding a new node as a child of the sub-tree that corresponds to the
VM.

The particular aspects of the system’s integrity state that is of interest to a user (or

verifier) of the system is modelled using a projection function,

()

. For a log tree

(

)

is simply a collection of a subset of the log entries in a subset of the nodes of

. Formally,

(

) =

{

log

′

}

, where

log

′

∈

log

and

(

, type

, log

∈ T

)

The

integrity requirements of the user are modelled by a predicate

, which is defined on

the result of the projection function.

Figure 2.13 shows the concepts of generalised sealing, attestation, and privacy pro-

tection in our formal model. We describe these concepts below.

Generalised Sealing to Protect Integrity

A system endowed with a TPM can seal a data item to the TPM, i.e., the system can en-
crypt the data item and tie it to the system configuration existing at the time of sealing.
The system configuration is reflected by a specified subset of Platform Configuration
Register (PCR) values. The data item may be a key generated by the TPM itself or
something generated outside the TPM. Decryption of the data item, called unsealing,
is possible only when the system configuration (reflected by the same subset of PCR
values) is the same as that at the time of sealing.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

System

Attestation

challenge c

projection p

p(log*)

log*

Sealing

key sealed

away

key, data

Evaluation

Function f

proof

TPM_Unseal

projection p
predicate

p(log*)

true

reveal

sealed key

Privacy

Filter

privacy-

preserving

projection

sub-view

Figure 2.13: Generalised Attestation, Sealing, and Unsealing

We generalise the concept of sealing for protecting the integrity of a sensitive data

item

, by making

inaccessible to the underlying system if the assurance about the

system’s trustworthiness is deemed unsatisfactory by the entity that invoked sealing.
We model the concept by two functions,

seal

and

unseal

. The

seal

operation takes as

input the data item

, a projection function

()

, a sealing predicate

, and the public

part

of an encryption key

. At the time

of executing the operation, the system

state is reflected by the log tree

, which includes knowledge of

()

and

. The

operation produces an encrypted output

∈ {

}

∗

, which is encrypted with respect

. The

unseal

operation invoked at time

(where

> t

) takes as input

and the

log state

at that time. The operation outputs

if and only if the sealing predicate

applied on

(

)

holds. A simple predicate may just compare the result of

(

)

with

a reference value (e.g.,

(

)

). A more complex predicate may extract the high-level

properties of the system from

(

)

and compare them with desired properties (similar

to property-based attestation [24, 27]).

One can easily see that our generalised sealing concept covers the special case of

TPM sealing. For TPM sealing,

simply consists of the values in the PCRs; the

projection function

()

specifies the subset of PCRs whose values are of interest for

assessing the system trustworthiness; the sealing predicate

simply checks whether

their values at the time of unsealing are the same as at the time of sealing.

Generalised Attestation to Verify Integrity

A TPM-equipped system can use the TPM to engage in a challenge-response style
cryptographic protocol, called attestation, with a remote verifier. The protocol allows
the remote verifier to query and reliably obtain the measurement values for the system
stored in the PCRs of the TPM. Reliable reporting of the measurement values is due to
the signing of the values by the TPM, which is trusted by the remote verifier. Based on
these values, the remote verifier assesses the trustworthiness of the platform.

We generalise the concept of attestation for verifying the integrity of those aspects

of the system that are of interest to the verifier. For example, the verifier may be a
Trusted Virtual Domain (TVD) master [4] who is interested in the number and type of
VMs running on the system prior to allowing one of the VMs to join the TVD.

In our model, the attestation function

attest

()

obtains as input a challenge

, an

evaluation function

()

, a log file projection

()

, and a secret key

. The function

outputs a signed message

sign

(

))

, c

)

The attestation function is a generalisation of both binary and property-based at-

testation [24, 27, 11]. For binary attestation, the evaluation function

()

is simply the

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

identity function, i.e.,

(

) =

, and the result of attestation is simply the signature on

the result of the projection function applied on the log tree. TPM attestation is a special
case of binary attestation in which

simply consists of the values in the PCRs and the

projection function

()

specifies a subset of PCRs. For property-based attestation, the

evaluation function

()

extracts high-level properties from the result of the projection

function applied on the log tree.

Whereas previous works such as that of Sailer et al. [32] provide a good way of

checking the hash of software binaries, our generalised attestation enables better as-
sessment of the run-time behaviour of the system. In this respect, our model has goals
similar to those of Haldar et al. [11]. However, unlike Haldar et al. who focus on
attesting the behaviour of a software application, our model has a focus on VMs and
virtual devices. Because of their reliance on the Java virtual machine which runs on
top of an operating system, their TCB includes the operating system. In contrast, our
TCB includes only the VMM and underlying system layers, and is much smaller than
theirs.

Privacy Protection by Visibility Rules

The integrity of certain aspects of the system may be important to multiple users. Con-
versely, certain aspects of the system may be confidential to one or more users. For
example, the integrity of the VMM would be of interest to the users of all VMs. On the
other hand, the state of a particular VM may need to be verified only by the user of that
VM. To satisfy such privacy requirements, it is important that attestation and sealing
be applicable on projections of the state. Furthermore, if a state that is relevant for
integrity verification contains information about multiple users, it should be possible to
prove integrity without revealing the actual state.

To satisfy the above privacy requirements, we introduce the following notions into

our formal model:

Privacy Requirement Specification The specification defines visibility constraints

on the projection functions. Given a set of users

and a log tree, a privacy

requirement specification is a function

()

that assigns a subset of

to each

vector element in each node of the tree. The subset assigned to a given vector
element in a given node is called the access control list (ACL) for that element.
Although the number of ACLs may potentially be very large, they can be imple-
mented efficiently by attaching ACLs only to some nodes and vector elements
and then using inheritance along the nodes and scoping rules along the vector
elements for a given node to derive the actual fine-grained access permissions.

Projection Assessment Functions The functions can determine whether projections

are privacy-invasive or privacy-preserving. A projection

()

applied by a user

∈

is privacy-preserving with respect to the privacy requirement specifica-

tion

()

if the output only contains vector elements in which

was contained in

the ACL. If the projection is privacy-preserving with respect to a privacy require-
ment specification

()

and a user

, then the sealing or attestation using this pro-

jection automatically preserves privacy. In other words, any evaluation function
for attestation or any predicate for sealing can be applied without infringing on
the privacy of the users of the system. If the projection is not privacy-preserving,
then it is necessary to ensure that at least the evaluation function or predicate
applied after a privacy-invasive projection can hide the private data.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Central
Integrity

Manager

Network

Integrity Manager

VMM

Integrity Manager

Devices

Integrity Manager

Storage

Integrity Manager

Attestation

Sealing

Unsealing

TCB

Predicate
Evaluator

Figure 2.14: Architecture for Integrity Protection and Verification

2.5.3

The PEV Integrity Architecture

Based on the formal model described above, we now present an architecture and associ-
ated protocols for protecting, enforcing, and verifying the integrity of VMs and virtual
devices. We call our architecture the PEV integrity architecture, which is shown in Fig-
ure 2.14. It consists of a central integrity manager and component integrity managers,
which are associated with individual system components such as storage, VMM, net-
working, and other devices. Each component integrity manager is responsible for the
part of the log tree corresponding to the component. For example, the storage integrity
manager is responsible for maintaining the storage sub-tree of the system log tree

Each log projection function is realised by a master plug-in module, which is ac-

cessible by the central integrity manager. For each component, the aspects of the com-
ponent’s integrity that are relevant for the projection function are revealed by a com-
ponent plug-in module, which can be directly invoked by the master plug-in module.
The output from the master plug-in module is the aggregate of the output from multi-
ple component plug-in modules. In this way, each master plug-in module obtains state
information about various aspects of the system that may be of interest to a potential
verifier or user.

In Figure 2.14, the master plug-in modules are shown using geometrical shapes

(ovals, hexagons, triangles, and rectangles) attached to the Integrity Manager. For
example, the triangular plug-in module measures certain aspects of system storage and
the VMM, as indicated by the presence of triangular component plug-in modules in
the Storage Integrity Manager and VMM Integrity Manager. On the other hand, the
hexagonal plug-in module measures only certain aspects of system devices. Each plug-
in module has a unique identifier. The mapping between each plug-in identifier and the
functionality provided by the corresponding plug-in module is made publicly available
(e.g., through a naming service or a published table).

Sealing/Unsealing Protocol

At the time of sealing, the user provides at least the following inputs:

Data The data to be encrypted during sealing and to be revealed later only if certain

conditions are met.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Key The key whose public part is used for encrypting the data at the time of seal-

ing, and whose private part is revealed only if the unseal operation completes
successfully.

Identifier(s) of Plug-in Module(s) By listing the identifiers of plug-in modules, a user

can choose what aspects of the platform integrity state it is particularly interested
in.

Predicate The predicate specifies user-defined conditions for revealing the private part

of the sealing key.

Our sealing protocol requires the log projection functions (described in Sec-

tion 2.5.2) to be implemented as plug-in modules as part of the TCB. The key used for
encrypting the sensitive data item is sealed away against the state of the TCB (stored
in PCRs that cannot be reset) and a hash of the user-specified projection functions and
sealing predicates. The latter is stored in a resettable PCR (say

P CR

) by the Integrity

Manager component of the TCB. That ensures that the TCB is aware of what condi-
tions must be satisfied before the key can be revealed to the user. To perform the unseal
operation, the TCB has to make sure that

P CR

contains the hash of the user-specified

projection function and sealing predicates. Then, the unseal operation reveals the key
to the Integrity Manager, which checks whether the sealing predicates (evaluated on
the output of the log projection function) are indeed satisfied before revealing the key
to the user.

The flexibility of our sealing protocol is due to the fact that arbitrarily complex

conditions to reveal the sealed key can be coded as plug-in modules. The extensibility
arises from the fact that new plug-in modules specifying new user-specified sealing
predicates can be added to the TCB.

Attestation Protocol

The flexibility of our attestation protocol relies on the verifier being able to attest the
TCB and requires the log projection functions (described in Section 2.5.2) to be im-
plemented as plug-in modules as part of the TCB. The extensibility of our attestation
protocols relies on the ability to add new plug-in modules for new aspects of the plat-
form state that the verifier may be interested in knowing to evaluate the platform’s
trustworthiness.

The verifier which initiates the attestation protocol provides at least the following

two inputs:

Challenge The challenge ensures freshness.

Identifier(s) of Plug-in Module(s) By listing the identifiers of plug-in modules, a ver-

ifier can choose what aspects of the platform integrity state it is particularly in-
terested in.

Blinding For Enforcing Visibility Constraints

Figure 2.15 shows a simple blinding technique that uses a commitment scheme to en-
force visibility constraints on the log tree. Commitment schemes [9] are a fundamental

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

N’

Figure 2.15: Enforcing Visibility Constraints on System State

cryptographic primitive and generally consist of two stages, a commit stage and a re-
veal stage. The first phase, called commit phase, is used to make a party commit to
a particular value while hiding that value from another party until the second stage,
called reveal stage, in which the value is revealed to the second party. Any commit-
ment scheme guarantees that (a) the committed value cannot be obtained by the second
party before the reveal stage and (b) the second party can detect whether the value
revealed to her is indeed the same value that was committed to in the first stage.

For simplicity, we consider blinding at the granularity of log tree nodes instead of

at the granularity of log vector elements in the tree nodes, i.e.,

()

assigns a subset of

to each each node of the tree. A random tree

is bound to the original log tree

through a multi-bit commitment scheme to give the blinded log tree

is a tree that

has the same structure as that of

and whose nodes are random numbers. Existing

commitment schemes such as the one by Damgard et al. [5] or those based on one-way
hash functions can be used for this purpose.

In a TPM-equipped platform, logging is done by extending the PCRs with the mea-

surement values. For blinding, it is the nodes of

that are actually logged. This means

that instead of doing the normal TPM_extend(

), a TPM_extend(

⊗

) is done, where

is a node of

, and

⊗

denotes the commitment operation used for

hiding

until the reveal stage.

The privacy-preserving projection function

()

invoked at the request of user

reveals

; in addition, the function reveals the nodes in

that

is authorised to access.

In other words,

()

implements the reveal stage of the multi-bit commitment scheme.

Due to the guarantees of the commitment scheme, the platform cannot invent arbitrary
values for the nodes in

without being detected by the user.

As a result of the blinding technique described above, any user

knows that all

components that have any effect on system integrity have been taken into consideration
in the system log tree; in addition, for those components that it is authorised to access,

can check whether they indeed have the acceptable configuration and state value,

by comparing with its own reference values that may be provided and certified by a
trusted third party. In particular, if the ACL for the root node contains all users, then
any user can verify overall system integrity without knowing the exact configuration of
any individual component in the system. That is because, the attestation result that

obtains from the platform will contain (root(

)

⊗

root(

)) and root(

), from which

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Xen Hypervisor

TPM

HDD

Network

/dev/tpm

TPM

Driver

TSS

HDD

Driver

VBDB

DM Crypt

/dev/sda

Ethernet

Driver

VNDB

Bridge

brctl

eth0

Compartment

Manager

Integrity

Manager

Secure Virtual

Device Manager

vHD vNW

…

Attestation

& Sealing

Plugin

Storage

Integrity

Plugin

…

Dom0

User
Space

Library
Space

Kernel
Space

Figure 2.16: Realisation using Xen and Linux

root(

) can be deduced and compared with the reference value at hand.

Using commitment schemes for blinding suffers from the disadvantage that two

colluding verifiers can learn the values revealed to the other. Alternate schemes based
on zero-knowledge proofs or deniable signatures need to be investigated to overcome
this disadvantage.

2.5.4

Realisation using Xen and Linux

Figure 2.16 shows an example implementation of our PEV architecture with the Xen
hypervisor using Linux for Dom0. The main components of our implementation are
the Compartment Manager, Integrity Manager, and the Secure Virtual Device Manager.
All components are implemented in Dom0. The Compartment Manager is the entity
controlling the complete VM management and therefore communicates directly with
the hypervisor. As the sole entry point for user commands, it also orchestrates the
Integrity Manager and the Secure Virtual Device Manager.

The Compartment Manager has an interface

getCurrentState

()

for obtaining the

current state of the entire environment, which includes the list of active VMs, the list
of users to whom the VMs belong, the amount of free memory available, etc. This
interface is useful for obtaining an attestation of the state of the physical machine. The
result of the

getCurrentState

()

function may not be sufficient to convince a verifier that

the VMs are in good state, but would provide information about how many and what
types of VMs are currently present on the physical machine, which VMs are running,

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

which ones are hibernating, etc. Using such information, the verifier would be able to
deduce whether the physical machine is in an “acceptable” state.

Table 2.3 shows the mapping between concepts in our formal model and how they

are realised in our implementation. XSLT is a language for transforming one XML
document into another XML document. We assume that the XSLT interpreter is part
of the TCB.

Model

Xen-based Prototype

Log

Internal to Component

Projection

()

Measurement Plug-in

Sealing Predicate

XSLT style sheet

Evaluation Function

()

XSLT style sheet

Privacy Filter

XSLT style sheet

Table 2.3: From Model to Implementation

Both the Integrity Manager and the Secure Virtual Device Manager have a plug-in

design. Each plug-in module is a concrete implementation of the log projection func-
tion

()

which outputs an XML file. The Integrity Manager in our implementation has

a Storage Integrity plug-in for measuring various disk images and files. The Integrity
Manager also has an Attestation & Sealing plug-in that interfaces with the TPM for per-
forming our sealing and attestation protocols as well as all for invoking normal TPM
operations that are needed in the plug-in context, such as TPM_Quote. The Attestation
& Sealing plug-in invokes normal TPM operations through the TPM Software Stack
(TSS) [40], which is the standard API for accessing the functions of the TPM.

The Secure Virtual Device Manager (SVDM) is responsible for managing virtual

devices such as virtual hard disks, virtual block devices, virtual network devices, and
virtual TPMs. The service offered by the SVDM is realised through multiple spe-
cialised low-level plugins, one for each virtual device. Figure 2.16 shows two plug-ins
in our Xen prototype. One is for configuring a virtual (encrypted) hard disk and the
other one is for configuring the virtual network.

In Dom0, secure device virtualization is implemented in the kernel space. Tasks

such as configuring virtual devices are done through the SVDM in the user (or applica-
tion) space. The SVDM manages devices and their security properties. For example, a
secure hard disk is implemented by means of the

dm-crypt

loop back device. Sim-

ilarly, network virtualization is done by providing virtual network cards for the guest
partitions and bridging these virtual cards to the actual network card. Security for net-
works has two aspects. Topology constraints define which guest partition is allowed
to connect to which subnets. In addition, encryption requirements define which con-
nections need to be encrypted. Another device, which is not shown in Figure 2.16 but
is virtualized in a similar way, is the TPM. Each guest partition is provided with one
virtual TPM instance [3]. The Integrity Manager and Compartment Manager are im-
plemented in Dom0, and interface to the hypervisor and other services implemented in
Dom0.

Secure management of virtual devices is a complex task. There are multiple steps

involved in starting a virtual hard-disk drive. First, a policy-based check of the platform
state is done. Depending on the logic implemented by the corresponding plug-in, that
check may include verifying the measurements of the hypervisor, binary disk, and the
Dom0 image. Then, the virtual hard-disk is attached with credentials and connected

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

<attestation-desc>

<attestation type="tpm-based" challenge="0xaded..."

aik="0xaada3..">

<measurement-desc type="tpm">

<measureTarget name="disk:/dev/sdb1"

dest="PCR16"/>

</measurement-desc>

</attestation>

</attestation-desc>

Figure 2.18: Attestation Descriptor in XML

Figure 2.17 shows the component interactions for attesting the current state of the

TCB and the status of a VM’s disk image.

The user/verifier interacts with the Compartment Manager (CM) through the

attestationRequest

call with an attestation descriptor and user credential as param-

eters (step 1).

The attestation descriptor is basically an XML structure that describes what the

verifier needs to have attested. The attestation descriptor contains one or more mea-
surement descriptors. Based on the measurement descriptors, the Integrity Manager
(IM) knows the exact set of measurement plug-in modules to invoke. As noted be-
fore, log projection functions are realised by a set of plug-in modules. The attestation
descriptor is how the verifier chooses the projection function suitable for its purpose.

Figure 2.18 shows an example attestation descriptor as a XML structure. It contains

section, which defines the type of attestation (

tpm-based

) and

the parameters needed for attestation (the TPM Attestation Identity Key or

AIK

and a

challenge

). Nested in the attestation descriptor is a measurement descriptor, which

specifies a measurement target (

measureTarget

) and a destination (

dest

). The

target indicates what is to be measured (in this case, a VM disk image), whereas the
destination indicates where the result should be stored (in this case, the TPM’s PCR
number 16). The

defines the scope of the requested attestation

(in this case, all PCRs).

Based on the user credential supplied, the CM checks whether the verifier has the

right to request attestation of the system sub-states indicated by the attestation descrip-
tor. The check is essentially a way of determining whether the requested projection is a
privacy-preserving projection; hence, it is useful in enforcing privacy protection. If the
check reveals that the verifier wants to have more attested than what he/she is allowed
to, then the entire attestation request is denied. Otherwise, the CM forwards the request
to the IM (step 1.1).

The IM extracts the measurement descriptor(s) from the attestation descriptor and

delegates the measurement(s) to the appropriate plug-in(s). In our example, the IM
invokes the

measurevHD

function at the Storage Integrity Plug-in (SIP) passing the

measurement descriptor as a parameter (step 1.1.1). The plug-in completes the re-
quested measurement and returns the measurement result back to the IM (step 1.1.2).
Although step 1.1.2 might look like an unnecessary extra step, the indirection via the
IM allows the measurement plug-ins to be written independent of the TPM or similar
future devices that are indicated as

dest

The IM invokes the

wrToTPM

function at the Attestation & Sealing Plugin

(ASP) with the challenge, the

AIK

, the measurement result, and the destination

PCR (step 1.1.3). The actual writing of the result into the PCR happens by the

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Figure 2.19: Creation of a VM with TPM-based Sealing

TPM

extend

operation (step 1.1.3.1). Thereafter, a

TPM

Quote

gets created and

returned to the ASP (steps 1.1.3.2 and 1.1.3.3). The ASP wraps the

TPM

Quote

into an

attestationResponse

and returns it to the IM. The

attestationResponse

in-

cludes not only the

TPM

Quote

but also the relevant log files. The IM returns the

attestationResponse

to the CM (step 1.2), which forwards it to the verifier (step 2).

A verifier can check the attestation result by recomputing a hash over the attestation

targets (i.e., the relevant log files) specified in the

attestationResponse

and comparing

the resulting hash with the hash in the PCR from the

TPM

Quote

The PCR in which the measurement result is stored will be reset after the attestation

process has finished. Therefore, our prototype requires a TCG 1.2 compliant TPM, and
the

dest

PCR has to be

or higher.

(Re-)Starting a VM with TPM-based Sealing

Figure 2.19 shows the component interactions for (re-)starting a VM with a sealed disk
image. In this use case, we show how to enforce a policy that specifies that the key for
decrypting the disk image be revealed only after measuring the disk image and only if
the measurement value written into a specified PCR matches the value against which
the key was sealed.

The user interacts with the CM through the

startVM

call to (re-)start the VM

(step 1). After determining that the disk image has to be first decrypted through unseal-
ing, the CM obtains the sealing descriptor that was given to it at the time of sealing.
Like the attestation descriptor, the sealing descriptor also contains one or more mea-
surement descriptors, which are used to let the IM know the exact set of measurement

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

<sealing-desc>

<measurement-desc type="tpm">

<measureTarget

name="file:/xenimages/vm1image"

desc="PCR16"/>

</measurement-desc>

</sealing>

</sealing-desc>

Figure 2.20: Sealing Descriptor in XML

plug-in modules to invoke.

Figure 2.20 shows an example sealing descriptor as an XML structure. It contains

section, which defines the type of sealing (

tpm-based

) and the pa-

rameters needed for unsealing (the identifier of the key protected by the TPM). Nested
in the sealing descriptor there is a measurement descriptor, which specifies a measure-
ment target (

measureTarget

) and a destination (

dest

). The target indicates what

is to be measured (in this case, a VM disk image), whereas the destination indicates
where the result should be stored (in this case, the TPM’s PCR number 16).

The CM calls the IM interface

unsealKey

(step 1.1), passing the sealing descriptor

as a parameter. The IM extracts the measurement descriptor from the sealing descriptor
and calls the

measurevHD

interface of the Storage Integrity Plug-in with the measure-

ment descriptor (step 1.1.1). The plug-in reads the list of

measureTargets

, and

accordingly measures the disk image. It returns a measurement result list to the IM
(step 1.1.2). The IM calls the Attestation & Sealing Plug-in, which handles TPM-
related functions (step 1.1.3). The Attestation & Sealing Plug-in writes the measure-
ments to the TPM by invoking the TPM_Extend operation (step 1.1.3.1). Furthermore,
the Attestation & Sealing Plug-in performs the unsealing of the key requested by in-
voking the TPM_Unseal operation (step 1.1.3.3). If the

dest

PCR value matches the

value at the time of sealing, then the disk is in the desired state and the unseal oper-
ation is successful (step 1.1.3.4); in that case, the ASP returns a key back to the IM
(step 1.1.4), which in turn returns the key to the CM (step 1.2). In case the unseal
operation fails, the ASP would return a failure. The CM calls the SVDM function

configAndUnlock

()

to attach and unlock the disk (steps 1.3 and 1.4). Upon successful

completion of that function, the CM instructs the Xen hypervisor to actually start the
VM (steps 1.5 and 1.6).

For the sake of simplicity, Figure 2.19 does not show details of key handling such

as loading a sealing wrapper key into the TPM.

Enforcement and Compliance Proofs for Information Flow Control

Consider, for example, the virtual network topology shown in Figure 2.21 with four
virtual network zones. The topology shows the network of a company (which we
shall call the customer company) connected to the Internet via a demilitarised zone
(DMZ). The customer network is also connected to a management network that allows
an outsourcing provider to manage the customer systems. The management network is
not connected to the Internet.

An information flow control matrix is a simple way of formalising the system-wide

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Customer

Network

DMZ

Internet

Management

Network

Figure 2.21: Virtual Network Topology

from/to

Cust

DMZ

Mgmt

Internet

Cust

DMZ

Mgmt

Internet

Figure 2.22: Flow Control Matrix

flow control objectives [4]. Figure 2.22 shows a sample matrix for the four virtual
network zones. Each matrix element represents a policy specifying the information
flows permitted between a pair of network zones. The 1 elements along the matrix
diagonal convey the fact that there is free information flow within each network zone.
The 0 elements in the matrix are used to specify that there should be no information
flow between two zones, e.g., between the management zone and the Internet.

In [4], we described a Xen-based prototype of a secure network virtualization ar-

chitecture that is based on the concept of Trusted Virtual Domains. The architecture
allows arbitrary network topologies connecting VMs. For example, different VMs on
the same physical infrastructure may belong to different virtual network zones. Despite
this, the architecture ensures the enforcement of policy-based information flow control.
We can use the architecture for enforcing the policies shown in Figure 2.22.

<flow-policy>

</zone> ...

</flow-policy>

Figure 2.23: Flow Control Policy in XML

By combining the Xen prototypes of our PEV architecture and our secure network

virtualization architecture, it is possible to validate the configuration of the virtual net-
working subsystem on each host. The subsystem exports an XML version of its flow
control matrix, as shown in Figure 2.23. The network measurement plug-in outputs
the XML structure of the flow-control policy, when invoked by the IM. By request-
ing attestation of the TCB and this policy, a verifier can obtain a compliance proof
for the correct configuration of the virtual networking subsystem on a given host. At
the verifier, a XSLT stylesheet is used to perform further transformations on the XML
file returned by the platform. The XSLT stylesheet is a concrete implementation of
the evaluation function

()

(described in Section 2.5.2), which assesses whether the

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

platform is trustworthy from the verifier’s point of view. The result of the evaluation
function will serve to convince the verifier that the policy in Figure 2.22 is the actual
flow-control policy as enforced by the network subsystem. If privacy is an important
concern, the XML output from the plug-in modules may be first processed by an XSLT
stylesheet that implements a privacy filter before passing it on to the verifier. In such a
case, the stylesheet would be embedded in the platform TCB.

<xsl:template

match="/flow-policy/zone[@id=’customer1’]">

<xsl:choose> <xsl:if

test="count(*[@id=’cust1-dmz’])=1

and count(*[@id=’mgmt-net’])=1">

</xsl:if>

</xsl:choose>

</xsl:template>

Figure 2.24: XSLT Condition

A user can also protect sensitive information (say, an encryption key) against access

by an untrusted network configuration using a two-stage procedure. The first stage is
sealing, in which the user has to specify the binary configuration of the TCB and condi-
tions for checking whether a given network configuration is a trusted one. Figure 2.24
shows an XSLT script that encodes the condition that the customer network should be
directly connected only to the DMZ and the management network of the outsourcing
provider, but not to any other network. The input to the XSLT script is the XML pol-
icy that is output by the network measurement plug-in. The XSLT script is a concrete
realisation of the user-specified predicate

in our formal model (Section 2.5.2). The

user seals the key to both the state of the TCB and the value of a resettable PCR; the
latter reflects the integrity of the XSLT script and the integrity of the plug-in identifier.
The second stage is unsealing, in which the IM (i) obtains the result of the plug-in,
(ii) applies the result as input to the XSLT script, (iii) extends the resettable PCR with
the hash of the XSLT script and the network measurement plug-in identifier, and (iv)
tries to unseal the actual key. For steps (iii) and (iv), the IM invokes the Attestation
& Sealing Plug-in. The TPM should only reveal the key if the TCB is correct and the
XSLT evaluated to

<true/>

when executed on their output.

2.5.6

Conclusion

We introduced a formal model for managing the integrity of arbitrary aspects of a virtu-
alized system and evaluating system compliance with respect to given security policies.
Based on the model, we described an architecture, called PEV, for protecting security
policies against modification, and allowing stakeholders to verify the policies actually
implemented. We generalised the integrity management functions of the Trusted Plat-
form Module, so that they are applicable not just for software binaries but also for
checking past security compliance and enforcing security policies in the future. We
described a prototype implementation of the architecture based on the Xen hypervi-
sor. We also presented multiple use-cases to demonstrate the policy-enforcement and
compliance-checking capabilities of our implementation.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

2.6

Xen Secure GUI Services

S. Cabuk, P. Grete (HPL)

This section introduces a preliminary secure GUI design on a virtualized Xen environ-
ment. Part of this work is incorporated into the OpenTC demo.

2.6.1

An Example Secure GUI Use Case

Desktop virtualisation is an emerging topic particularly thanks to increasing hardware
virtualisation support by Intel and AMD. If different domains are running on the same
physical platform, e.g., a work environment with corporate data and a private one with
games or other potentially untrusted software, it is essential that no environment has
access to or has an affect on the other. This leads to the need for a secure graphical
user interface (sGUI), which is capable of ensuring security and separation between
standard tasks in window-based systems, such as

1. keyboard/mouse input,

2. copy and paste actions,

3. screenshots, and

4. sound.

As an example requirement, it should not be possible to take screenshots of any

compartment with a different trust level than the active environment.

2.6.2

Current State

The current setup of the OpenTC demonstrator uses an SDL-widget-based ParaGUI
interface running on top of a dom0 X-server (see Figure 2.25). This interface is only
used for the graphical control of low-level guest domain management, e.g. booting,
stopping the domain or displaying the type of operating system with the help of a small
icon. The ParaGUI runs on top of each virtual domain that enables users to switch
between the domains. Other domains, including the dom0, have their own workspace
within the dom0 X-server. Their desktop environment is displayed using the VNC
protocol and the Xen TCP/IP network stack. The input handling is done completely
by the X-server and switching between desktops of different domains is realized by
simple X-server shortcuts. Furthermore the X-server talks to the graphics card with its
own drivers.

This solution provides minimal security for several reasons. First, X-server has a

large code-space that needs to be trusted. Second, Dom0 is given full control over all
workspaces through the X-server. This latter property can allow a malicious entity to
capture screenshots of other desktops with reasonable effort using X libraries.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Figure 2.25: sGUI Current State

2.6.3

Prototype Design

Our first design for a prototype addresses the shortcomings presented in the previous
section. In particular, we have enhanced the current design by: (1) reducing the size
of the sGUI codebase, (2) disaggregating the sGUI into a separate domain, and (3)
employing additional hardware acceleration techniques.

Codebase Reduction

Layout

One problem with the current sGUI design is the size of the codebase that

needs to be trusted. To address this, we remove the large X-server and implement a
secure GUI (sGUI) with a trusted code base instead. This secure GUI has multiple
virtual framebuffers (VFB) (the virtual equivalent of a region in memory to store the
screen image) that are used directly by the desktop environment in dom0 and via a
memory mapping within the domUs. These VFBs can be treated as normal framebuffer
devices and therefore all domains are able to run unmodified X-servers themselves or
any other framebuffer-based application.

The final step to display the actual screen on the monitor is a simple mapping be-

tween the active VFB and the kernel framebuffer

/dev/fb0

. This mapping is possible,

since the Xen-based environment offers the possiblity to use shared memory and no
further modification to the actual screen output likewise memory content is needed to
display the correct output. As illustrated in Figure 2.26, the sGUI takes care of all input
handling by receiving all events and forwarding them to the active domain.

Security analysis

The introduction of an input management system ensures that all

input actions are strictly separated between the domains. This management system
receives all input events and forwards them to the active domain only. Further, the
exchange of the X-server by an sGUI solution with a trusted code base results in con-
siderably fewer lines of code. This improvement is the first element of shrinking the
trusted code base. The graphical management is still kept in the privileged domain
together with other potentially untrusted services.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 2. XEN SECURITY SERVICES

Figure 2.26: sGUI Codebase Reduction

Disaggregation

Layout

Figure 2.27 illustrates the disaggregated layout in which the complete sGUI

and (kernel) graphics have moved from dom0 to a separate graphics domain (domG).
This new domain has direct hardware access to the graphics card and removes the con-
trol from dom0. Xen is able to hide PCI devices from dom0’s Linux kernel and there-
fore is able to hide the graphics card. Hiding a PCI device is realized by preventing the
Linux kernel loading drivers and leaving the device unbound in the PCI backend. With
this unbound graphics card, domG is able to bind the device to itself and run a kernel
framebuffer with access to the graphics card memory. Mapping between the different
virtual framebuffer and the kernel framebuffer is done the same way as described in the
previous section.

Similarly, keyboard and mouse are no longer under the control of dom0. An input

manager forwards input actions to all domains, including the dom0. To this day there
is no solution to binding PS/2 devices to any other domain than the dom0. Simple
forwarding is not sufficient with regard to security because the dom0 should not control
or access any input device directly.

The implementation of a separate input frontend/backend will be completed in near

future. Virtual input devices are already available for domains and only a proper redi-
rection to another domain is lacking. For security reasons, the hypervisor console and
a root console in dom0 should still be available via a serial connection.

Security analysis

This enhancemenent presents another level of reduction of the

trusted code base. By disaggregating the privileged services from dom0, a new secure
layer has been established. Further, the domG can be implemented without network
support – one of the weakest points for intrusion. The main problem for both reduc-
tion and disaggregation elements is the actual speed of the interface. Framebuffers and
memory mapping are limited in speed and are done by the CPU. For applications that
require 3D graphics or a fast interface in general, this enhanced design does not pro-
vide the amount of graphics power needed. One solution is using hardware accelerated
graphics which is described in detail in the next section.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Figure 2.27: sGUI Disaggregation

Hardware Acceleration

Layout

The modification of the previous design as illustrated in Figure 2.28 yields a

hardware accelerated sGUI. The new OpenGL-based design increases the speed of the
desktop and enables the user to perform graphic-intense operations securely.

Every domain that requires graphical output will be extended by an OpenGLAPI

as part the the X-server. This API is able to display the whole desktop using OpenGL
commands. It sends the commands directly to the domain’s graphics driver, which is
merely a listening client forwarding the commands to the sGUI in domG. The sGUI has
a new screen multiplexing server, similar to the virtual framebuffers. It forwards the
OpenGL commands from the active domain directly to the graphics card driver, which
eventually makes use of hardware acceleration. The input management is handled in
the same way as in the former setting.

Security analysis

The OpenGL-based design offers the same level of security and

trust as the previous design. The slight increase of the code base can be accepted given
the additional value of hardware acceleration.

VMGL

There is already a working basic implementation called VMGL2, which in-

creases the speed by using native graphics card capabilites within a domU. This solu-
tion yields “87% of the native speed” [15]. Unfortunately, VMGL needs an X-server
at the moment to load its own OpenGL server driver. This can be solved by porting
VMGL to a minimal OpenGL server such as miniglx3 and enhancing miniglx with Xen
support.

The VMGL solution is not able to display unmodified domains, such as Windows,

which had been possible with the implementation of our sGUI design. Hardware accel-
eration in Windows domains is a general problem, since there is no OpenGL graphics
card driver and Windows natively uses Direct3D.

In addition to this, further security features are needed within the current VMGL

solution because there is no strict separation between single domains. Every window
is displayed in the X-server of dom0.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

Terms and Definitions

We define a compartment as a software component that is logically isolated from other
software components. The configuration of a compartment unambiguously describes
the compartment’s I/O behaviour based on its initial state

and its set of state trans-

actions that convey a compartment from state

to state

. Moreover, we distin-

guish secure, trusted, and plain communication channels between compartments. Plain
channels transfer data without providing any security property. Secure channels ensure
confidentiality and integrity of the communicated data as well as the authenticity of
the endpoint compartment. Trusted channels are secure channels that additionally val-
idate the configuration of the endpoint compartment. Finally, integrity of information
obtained from a channel or compartment is provided, if any modification is at least
detectable. The Trusted Computing Base (TCB) consists of all security relevant com-
ponents of the platform, e.g., microkernel and security services.

Security Services

These services allow applications to use enhanced security functionalities strengthened
by Trusted Computing. They also mediate and monitor access to resources. Thus,
they enforce isolation of compartments and control communication between processes
running in different compartments. The following services are defined in our approach:

•

Storage Manager: The Storage Manager (SM) provides persistent storage for
the other compartments while preserving integrity, confidentiality, availability
and freshness of the stored data. Moreover it enforces strong isolation by bind-
ing the stored data to the compartment configuration and/or user secrets

. The

Storage Manager gains access to the configuration of its clients by asking the
Compartment Manager to provide the necessary information.

•

Compartment Manager: The Compartment Manager (CM) manages creation,
update, and deletion of compartments. It controls which compartments are al-
lowed to be started or stopped and by whom, thus enforces parts of the mandatory
security policy. During startup of compartments, it derives their configurations
to be able to offer a mapping between temporary compartment identifiers

and

compartment configurations.

•

Trust Manager: The Trust Manager (TM) offers access to functions (e.g., TPM
functionalities) that can be used by application-level compartments to establish
trusted channels between remote and local compartments or creating keys and
certifying them.

•

Secure I/O: The Secure I/O (SIO) renders (e.g., displays, plays, prints, etc.)
content while preventing unauthorised information flow. Thus SIO incorporates
all compartments that are responsible for secure output of content (e.g., drivers,
trusted GUI, etc.).

In the following sections we explain how these services are used to provide the

necessary security properties and concepts, i.e., privacy protection, trusted channels,
trusted storage, and strong isolation.

Since SM does not provide sharing of data between compartments at the moment, it does not realise a

regular file system.

A compartment identifier unambiguously identifies a compartment during runtime.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Trusted Channels

According to the definition above, trusted channels allow the involved communication
end-points to determine their configuration and thus to derive their trustworthiness.
Other integrity measurement architectures, [30, 32] however, report the integrity of the
whole platform configuration including all currently running compartments to remote
parties, and thus violating user privacy. In contrast, our architecture supports to es-
tablish trusted channels between single compartments without the involvement of the
whole platform. This has the following advantages:

•

Privacy: A remote party only needs to know the configuration of the appropriate
compartment including its TCB, and not the configuration of the whole platform.

•

Scalability: Remote parties do not have to derive the trustworthiness of all com-
partments executed on top of the platform, to determine the trustworthiness of
the appropriate compartment.

•

Usability: Since a compartment’s trustworthiness can be determined indepen-
dently of other compartments running in parallel, the derived trustworthiness
stays valid even if the user installs or modifies other compartments.

Trusted channels can be established using the functions offered by the Trust Man-

ager and the Compartment Manager, while the Compartment Manager, which is re-
sponsible for installation and manipulation of compartments, provides the mapping
from compartment identifiers into configurations. Thus, trusted channels can be es-
tablished assuming that the TCB including the Compartment Manager and the Trust
Manager is trustworthy. In Section 3.1.2, we will explain how remote parties can de-
termine the trustworthiness of the TCB.

We distinguish between trusted channels between compartments running on the

same platform (local trusted channels) and trusted channels between a remote and a
local compartment (remote trusted channels).

Local Trusted Channels: Since both the sender and the receiver are executed on

top of the same TCB, an explicit verification of the TCB’s trustworthiness does not
make sense in this case. Therefore, trusted channels can easily be established using
secure channels offered by the underlying TCB, and the functions provided by the
Compartment Manager: The sending compartment first requests the configuration of
the destination compartment from the Compartment Manager. On successful validation
that the destination configuration conforms to its security policy, the source compart-
ment establishes a secure channel to the destination compartment.

Remote Trusted Channels: The required steps to establish a remote trusted chan-

nel from a remote compartment to the local compartment are as follows: If a local
compartment receives a request from a remote compartment, the local compartment
requests the Trust Manager to provide a credential including its own configuration.
Then the Trust Manager generates the credential based on both the compartment con-
figuration provided by the Compartment Manager and the configuration of the plat-
form’s TCB.

The resulting credential is returned to the invoking local compartment

that forwards it to the remote compartment. That can now verify the trustworthiness of
the local compartment and, on success, using the credential to open a trusted channel.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

On top of the security kernel, a para-virtualised legacy operating system (currently

Linux) including legacy applications, and the Secure I/O are executed in strongly iso-
lated compartments running in parallel as user processes. In the following, we briefly
describe each layer in more detail.

TC-enabled Hardware Platform:

The hardware platform has to provide additional

components as defined by the TCG in various specifications (e.g., [38]). The central
component forms a low-cost tamper-resistant cryptographic chip, called Trusted Plat-
form Module (TPM). Currently, the TPM is implemented as a dedicated hardware chip.
It offers amongst others a cryptographic hash function (SHA-1), a cryptographic en-
gine (RSA) for encryption/decryption as well as signing, a hardware-based Random
Number Generator (RNG), hardware protected monotonic counters as well as some
amount of protected storage. It provides a set of registers in protected storage called
Platform Configuration Registers (PCR) that can be used to store hash values. Protec-
tion mechanisms ensure that the value of a PCR can only be modified in a predefined
way. The TPM is primarily used as a root of trust for platform’s integrity measure-
ment and reporting. During system startup, a chain of trust is established by cryp-
tographically hashing each boot stage before execution. The measurement results are
stored protected in the PCRs. Based on this PCR configuration, two basic functions
can be provided: Remote Attestation allows a TC-enabled platform to attest the current
measurement and Sealing/Binding of data to a certain platform configuration. Our im-
plementation uses a TPM in the present version 1.2 [38] since previous TPM versions
cannot be used to provide fresh storage by monotonic counters.

Virtualisation Layer:

The main task of the virtualisation layer is to provide an ab-

straction of the underlying hardware, e.g., CPU, interrupts, devices, and to offer an
appropriate management interface. Moreover, this layer enforces an access control
policy based on this resources. Device drivers and other essential operating system
services, such as process management and memory management, run in isolated user-
mode processes. In our implementation, we kept the interfaces between the layers
generic to support also other virtualisation technologies. Thus, the interface offered
by the virtualisation layer is similar to those offered by virtual machine monitors or
hypervisors like sHype and Xen [23, 31, 7]. However, we actually decided to employ a
L4-microkernel that easily allows isolation between single processes without creating
a new full OS instance in each case such as when using Xen.

Trusted Service Layer:

The trusted service layer, based on the PERSEUS security

architecture [22, 26, 28]. It provides elementary security properties like trusted chan-
nels and strong compartment isolation as well as several elementary management com-
partments (e.g., I/O access control policy) that realise security critical services inde-
pendent and protected from compartments of the application layer. The main services
are the Trust Manager, the User Manager, the Compartment Manager, and particularly
the Storage Manager. Our implementation of the Trust Manager is based on the open-
source TCG Software Stack TrouSerS [35].

Application Layer:

On top of the security kernel, several instances of the legacy

operating system (L4Linux) as well as security-critical applications (e.g., Secure I/O)
are executed in strongly isolated compartments such that unauthorised communication

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

between applications or unauthorised I/O access is prevented.

The legacy operating

system provides all operating system services that are not security-critical and offers
users a common environment and a large set of existing applications. If a mandatory
security policy requires isolation between applications of the legacy OS, they can be
executed by parallel instances of the legacy operating system.

Secure Initialisation:

The security of the whole architecture relies on a secure boot-

strapping of the TCB. A TPM-enabled BIOS, the Core Root of Trust for Measurement,
measures the integrity of the Master Boot Record (MBR), before passing control to it.
A secure chain of measurements is then established: Before program code is executed
it is measured by a previously measured and executed component. For this purpose,
we have modified the GRUB boot loader

to measure the integrity of the core com-

partments, i.e., the virtualisation layer, all compartments interacting directly with the
TPM – Compartment Manager, Trust Manager and Storage Manager – as well as the
TPM device driver. The measurement results are securely stored in the PCRs of the
TPM. All other compartments (including the legacy OS) are subsequently loaded, ver-
ified, and executed by the Compartment Manager according to the effectual platform
security policy.

Upon completion of the secure Initialisation, an authorised compartment (such as

the Trust Manager) can instruct the TPM to generate a credential for the Trusted Com-
puting Base. This credential consists of all PCR values reflecting the configuration of
the TCB and a key pair which is bound to these PCR values. Together with an I/O
access policy management service that is of course also part of the TCB, the private
key can only be used by compartments that are both part of the TCB and are authorised
to access the TPM.

Trust Manager

Our implementation of the Trust Manager is based on the open-source TCG Software
Stack TrouSerS [35]. In order to provide remote trusted channels, the Trust Manager
creates on request of a local compartment a private binding key whose usage is bound
to the requesting compartment’s configuration and the configuration of the platform’s
TCB (including the Trust Manager itself). The appropriate certificate of the public
binding key has to be extended such that remote parties can verify both configurations.
To access content that is remotely decrypted with the public binding key, the Trust
Manager checks whether the configuration of the compartment that wants to use the
corresponding private binding key matches the configuration of the compartment that
has initiated the creation of that binding key. Note that, by extending this ’match’
function, one can easily provide property-based attestation/sealing [27, 25, 12] on top
of the Trust Manager.

In this section, we give a detailed description of the protocol for establishing a re-

mote trusted channel. The protocol can be decomposed into three major steps, namely
certificate generation, encryption of a session key, and decryption of the session key.

Certificate Generation: The request of the remote compartment

for a trusted

channel to the local compartment

reaches

T M

via

. After the mapping of

’s compartment identifier to his actual compartment configuration

comp

conf

However, covert channels are still feasible.

www.prosec.rub.de/trusted_grub.html

We also developed another approach setting up a trusted channel that provides additional security by

preserving mutual security and state-change detection (see [2]).

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

using

T M

invokes the TPM to create a asymmetric binding key bound to the

actual TCB configuration.

The TPM then returns the public binding key

P K

BIN D

and the encrypted secret part

′

BIN D

using TPM’s storage root key (SRK). Then

T M

invokes the TPM to sign over the actual TCB configuration, the binding key, and

the configuration of

using an attestation identity key (AIK).

Finally,

T M

embeds

the received TPM credential within an X.509 certificate for use in the TLS handshake,
which will be sent together with

P K

BIN D

. First, a key pair bound to the

TCB configuration and an appropriate certificate about the public key are created. The
certificate is an X.509 certificate which includes information about the PCR values of
configurations that are allowed to use the key (enforced by the TPM) [33], and the
configuration of the compartment (enforced by the Trust Manager).

TCB configuration

T CB

conf

Public binding key

P K

BI N D

Local compartment configuration

comp

conf

TPM Signature =

sign

AI K

(

T CB

conf

P K

BI N D

comp

conf

)

Table 3.1: Structure of the TPM credential

cred

BIN D

Encryption of Session Key:

verifies the X.509 certificate signature as well

as the TPM credential signature and validates the two embedded configurations

T CB

conf

and

comp

conf

by comparing them with reference values known to be trust-

worthy. On success,

encrypts a symmetric session key to

esk

using

P K

BIN D

and acknowledges the TLS handshake with

esk

, that can be unbound by

only if it

provides the stated compartment and TCB configuration.

Decryption of Session Key: Upon receipt of the encrypted session key

esk

requests

T M

to unbind the session key. Therefore,

T M

again maps

’s compart-

ment identifier to his actual compartment configuration

comp

conf

using

, to

validate the compartment configuration stated in the certificate with the one requesting
the unbind process. On success,

T M

invokes the TPM to unbind the session key using

the encrypted private part of the binding key

′

BIN D

. The TPM first compares the

actual PCR values with ones

BIN D

is bound to, before returning the decrypted ses-

sion key to

T M

finally, passes the decrypted session key back to

which uses

it for the completion of the TLS handshake to establish a (one-way) TLS-based trusted
channel from compartment

Performance Measurements: We have implemented the described protocol and

run it on TPMs of different vendors. The measurement results with maximum asym-
metric key lengths (2048 bits) are shown below. Note that the TPM calculations domi-
nate the overall computation and network transfer times.

Storage Manager

The following section describes the implementation of the Storage Manager

, that

enables other compartments to persistently bind their local states to their actual config-
uration while preserving integrity, confidentiality and freshness. We first give an short

The actual TCB configuration

T CB

conf

was measured during secure Initialisation (cf. Section 3.1.2).

The attestation identity key (AIK) is a non-migrateable key that has been attested by a privacy-CA to

come from a TCG conform platform. An AIK (in contrast to the general signature key) can be used only to
sign other TPM keys or PCR values.

In [2] we altered the credential creation process for performance reasons.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

Atmel 1.1b

NSC 1.1b

Certificate generation

30 – 80 s

52 – 55 s

Session key encryption (w/o TPM)

< 1 s

Session key decryption

2 – 3 s

23 – 24 s

Table 3.2: Trust Manager performance measurement results.

overview and then describe the realisation of secure storage that will be extended by
an additional freshness layer to provide also trusted storage. At the end of this section,
we briefly describe the protocols to init

as well as for storing to and loading from

trusted storage using

Overview: The Storage Manager is invoked by a compartment to store a data object

persistently preserving confidentiality and integrity – optional with additional restric-
tions

rest

(e.g., freshness, certain user id).

invokes the Compartment Manager to

retrieve the actual configuration of the respective compartment to bind the data object
to that compartment configuration

cmp

conf

creates/updates a metadata entry

for the corresponding data object

data

with the data object identifier

data

, its fresh-

ness detection information

, i.e., the actual cryptographic hash value, and all relevant

access restrictions

rest

within its index

index

extends the data object with

integrity verification information, synchronises its monotonic counter

cnt

, encrypts

the data object and the updated index and writes it on untrusted persistent storage using

key

. Since

index

is the base of security for

index

is sealed to

’s

configuration via the sealed

key

. Thus only the same, trusted Storage Manager con-

figuration is able to unseal and use the key again. On a load request,

again uses

the Compartment Manager to compare the invoking compartment configuration with
the one that afore stored the respective data object. On a successful verification,

reads and decrypts the data object from the untrusted persistent storage and verifies its
integrity. Before the data object is committed to the requesting compartment,

also

verifies possibly existing additional restrictions such as freshness or a certain user id.

Trusted Storage:

offers trusted storage to bind compartment’s data to the the

origin compartment while preserving integrity and confidentiality. Therefore

uses

a cryptographic hash function

to calculate the data object’s hash value and a symmet-

ric cipher

with its internal cryptographic secret

key

bound to its configuration to

encrypt data objects together with their actual hash values before become written on
untrusted persistent storage providing at least availability. This key in turn is sealed to
the configuration of

using functionality of the TPM so that only the same, trusted

Storage Manager configuration is able to unseal and use the key again. On load, the
data object becomes decrypted and verified for integrity using the appended hash value.
Figure 3.2 depicts our trusted storage implementation. Thus, our trusted storage com-
partment basically offers two trusted channels namely

load

[]

and

store

[]

while itself

uses two untrusted channels namely

read

[]

and

write

[]

from an untrusted storage com-

partment to persistently write respectively read data while providing at least availabil-
ity.

receives a data object

data

via

store

[

data

rest

]

internally creates

Further access restrictions can be a certain user id, group id or date of expiry.

Our implementation uses SHA-1 [20].

Our implementation uses AES [19].

For the realisation of availability we suggest solutions based on high redundancy, i.e., by the utilisation

of multiple distributed storage locations (e.g., USB sticks or online sites) assisted by an appropriate RAID
system. In case of failure of a particular storage device, it is still possible to retrieve data from alternative
storage mirrors.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

or updates object’s metadata

and calculates its hash value

to verify integrity. Then

data

together with

is encrypted with the internal cryptographic secret

key

using

the function

encrypt

[

data

]

(to provide confidentiality). The encrypted data

will afterwards be written on untrusted storage using

data

write

[

]

that returns

the object identifier

data

. Conversely, if

is read from the untrusted storage via

read

[

data

]

it will be decrypted to

data

and

via

decrypt

[

]

using the internal

cryptographic secret

key

. Before returning

data

load

[]

verifies the integrity

data

and further access restrictions (e.g., a certain user id) based on the correspond-

ing metadata in

’s index using the function

verify

[

data

]

Storage Manager

Freshness

Integrity

Confidentiality

Trusted Channel

:= encrypt[

d ||i

]

:= read[

]

:=write[

]

Plain Channel

d ||i

:= decrypt[

]

:= hash[

]

A/R := verify[

d, i

]

Untrusted Storage

:= load[

]

:= store[

d, rest

]

:= memorize[

]

A/R := verify[

d, f

]

Compartment

cmp_conf

rest

CP_0

ID_325

0x29...

fresh

CP_1

ID_563

0x10...

UID = 2

Figure 3.2: The Storage Manager Implementation

In order to provide fresh trusted storage, we enhance

by an additional layer

for managing freshness of data objects. This extension consists of a (currently ab-
stract) function

memorise

[

data

]

that updates the internal data structure

FRESH

with the freshness value

. Afterwards,

data

will be stored persistently ensuring confi-

dentiality and integrity using secure storage. On load from secure storage, the function

verify

[

data

]

additional verifies that the received data object

data

is the last one being

stored.

To provide such freshness detection,

uses an additional metadata field to store

the cryptographic hash value

Hash

(

data

)

that defines the last stored version of

data

On load,

calculates

Hash

(

data

)

again and checks if it matches the hash value on

last store. In order to ensure freshness of these metadata, the index of

itself has to

be stored fresh.

We therefore analysed to what extend TPMs of version 1.1b and 1.2 can be used to

realise a fresh index for

•

DI-Register: TPMs version 1.1b provide a Data Integrity Register (DIR) that can
persistently store a 160 bit value [17, 18]. Unfortunately, access to this register is
only authorised by the TPM-Owner secret implying that the TPM-Owner can al-
ways perform replay attacks. The only solution would be to distribute platforms
with an activated TPM and an owner authorisation secret that is unknown to the
user. This solution does not conform to the TCG specification that demands that
TCG-enabled platforms have to be shipped with no owner installed (see [39],
page 139).

More details on storage metadata at the end of this section.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

•

SRK Recreation: An alternative way to prevent replay attacks based on TPMs
version 1.1b would be to create a new Storage Root Key (SRK) before the sys-
tem is shut down. Recreation of the SRK would prevent that previously created
TPM encryption keys can be used any more. Unfortunately, a SRK can only
be renewed by the

TakeOwnership

function which itself requires a previously

OwnerClear

that itself disables the TPM. Therefore, an online-recreation of the

SRK seems to be impossible.

•

NV-RAM: TPMs version 1.2 provide a limited amount of non-volatile (NV-)
RAM to which access is restricted to authorised entities. So-called NV-Attributes
define which entities are authorised to write to and/or read from the NV-RAM.
Thus, data integrity can be preserved by storing a hash value of the data into the
NV-RAM and ensuring that only the Storage Manager can access the authorisa-
tion secret.

•

Secure Counter: A TPM version 1.2 supports at least four monotonic counters.
Based on this functionality, the freshness of data can be detected by securely
concatenating it with the actual counter value.

A result of our previous analysis we showed that TPMs version 1.1b cannot be

used to provide fresh storage as required to enforce stateful licenses and/or to trans-
fer licenses. Therefore we decided to realise trusted storage based on the monotonic
counter functionality of TPMs version 1.2.

A monotonic hardware counter allows us to securely maintain versioning of an

arbitrary data component, by keeping a software counter synchronised with one (of
four guaranteed) hardware counters of the TPM.

manages an internal software

counter that, every time

updates its index, is incremented synchronously with the

monotonic hardware counter. If both mismatch at any time, a outdated data is detected,
that will be handled according to the actual security policy.

However, in order to employ TPM’s monotonic counters,

has to be initialised

correctly. On the initial setup

uses the TPM to create its internal cryptographic

key

that then will be sealed to the actual platform configuration. To enable

freshness detection and thus trusted storage,

creates a monotonic counter

cntid

with a authentication

auth

, e.g., a secret password. The initial setup finishes with the

creation of

’s internal metadata index

index

and the saving of the sealed key

blob and the encrypted index on untrusted storage.

After a platform reboot,

reads the key blob from the untrusted storage and asks

the TPM to unseal its internal key. The TPM is able to unseal

key

if the platform

has the same configuration as it was at the sealing process, thus preventing a modified

to access

key

. Then

uses

key

to decrypt its metadata index read from

the untrusted storage. Finally,

verifies freshness of

index

by comparing the

decrypted counter of

index

with the actual counter value of the corresponding TPM

counter

cntid

To bind a compartment’s data object persistently to its actual configuration the

following has to be done: After the mapping of compartment identifier to the actual
compartment configuration using

updates

index

with the correspond-

ing metadata as well as the incremented software counter to enable freshness detection
for

index

. Afterwards,

writes both, the data objects and the updated index,

encrypted on the untrusted storage using

key

. Finally,

synchronises its soft-

ware counter with the TPM’s monotonic hardware counter and returns the data object
identifier.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Note that we assume that (i) the operations above are atomic and thus attacks can

only be mounted between those operations and (ii) our attacker is able to accomplish
two kinds of attacks: replay of persistently stored indexes and Denial-of-Service (DoS)
attacks. These assumptions result in six attack scenarios, summarised in Table 3.3.

Attack after

Replay

DoS

Increment SW-Counter

no persistence

Save new index

no effect

can be detected

Increment HW-Counter

not possible

possible

Table 3.3: Attacks on the store protocol.

If the software counter was incremented, but the new index not yet saved, interrupt-

ing the update cancels it, but has no further effect (no persistent state is changed). After
saving the new index, the saved software counter mismatches the hardware counter,
preventing the saved index from being loaded. Thus, denial of service can be achieved
(but can be detected as an attack), but replays fail. After incrementing the hardware
counter, the new index is in place. Interrupting after the update, yet before making the
new index accessible merely can be used to “waste” a single use of limited-use licences
but has no further implications.

We complete the scenario with loading a compartment’s data object again: After

the mapping of requesting compartment identifier to the actual compartment configu-
ration using

reads the requested data object from untrusted storage and de-

crypts it using

key

. Before returning

data

to the corresponding compartment,

verifies all access restrictions (e.g., freshness, or a certain user id) given on store via

rest

based on the corresponding metadata in

index

and verifies that the requesting

compartment has the same configuration as it was on store.

Secure I/O

The Secure I/O compartment receives protected content in plain for rendering. Thus
the

SIO

is a security critical compartment that has to be trusted. Therefore

SIO

is executed in parallel, isolated from, e.g., a legacy OS and has to be verified for
trustworthiness. In order to provide a flexible efficient implementation, we used a
para-virtualised Linux operating system reduced to the essential functionality to render
decrypted content

. Moreover, our whole system architecture enforces that

SIO

allowed to communicate only with devices essential for the rendering process and in
turn receives communication only from the TCB so that decrypted content cannot leak
into untrusted compartments.

3.1.3

Secure Virtual Private Network

A prototype of a secure VPN solution, called Turaya-VPN, was implemented within
the EMSCB project and is provided to the OpenTC project.

Overview

Our solution establishes a VPN by using the security services and therefore facilitates
protected communication with remote compartments and entities as, e.g., servers (web

Our exemplary

SIO

implementation provides rendering of several audio formats

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

Figure 3.3: Architecture Overview

servers, email servers, news servers, etc.) in a protected intranet. The solution must
ensure that a user within an insecure network gets secure access to a protected area.
The communication between the user and the secure area is protected by the OpenTC
security platform. The secret required for establishing the connection is also managed
by the platform. The user operating system has no access to the information.

The bridge server is an isolated network driver. The main goal of the bridgeserver

is to outsource the DMA-enabled network drivers

in an isolated component that may

additionally contain virtual private network (VPN) and firewall functionality. Clients
open (and close) a network device, and read from (and write to) a previously opened
network device. Additionally the bridgeserver allows to enforce access control on
which clients may open a network device and provides a simple management inter-
face.

Requirements: In the context of the OpenTC environment, a certificate-based VPN

shall be implemented. The following requirements to the communication channel are
made:

•

Integrity of the transmitted data

•

Confidentiality of the transmitted data

In the following, we will distinguish between the user system (e.g., Linux) and the

Platform-VPN system. Both work on a host system and are managed by the OpenTC
security platform. The user system is the user operating system the user interacts with.
Every input (keyboard, mouse, etc.) is processed by the user system. The Platform-
VPN system is executed in parallel through the security platform on the same host

DMA (Direct Memory Access) allows a device to access main memory directly. A malicious device

driver can misuse DMA to read out confidential data from main memory.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

Bridgeserver-eth0

Client1

fd0

tun0

eth0

wlan0

fd0

tun0

tun1

TUN/TAP

String IPC

TUN/TAP

Routing

tun2

IPC0

Client2

fd0

tun1

fd1

TUN/TAP

String IPC

TUN/TAP

IPC0

IPC1

Bridgeserver-wlan0

Client3

fd0

tun0

fd0

TUN/TAP

String IPC

TUN/TAP

IPC0

L4Linux2

L4Linux1

L4Linux3

Figure 3.4: Bridgeserver Architecture

system. Every network request of the user system is forwarded to the Platform-VPN
system by the core security platform. There, the requests are classified and processed
according to their security property. This can mean that the Platform-VPN system
establishes a secure connection to a protected intranet gateway and the data transmitted
are encrypted.

Design of Virtual Networking for L4

In this section the design of the bridgeserver implementing virtual networking, which
is required for the secure VPN, is described.

Architecture Description of the Bridge Server

The architecture of the bridge server is illustrated in Figure 3.4. Clients and server use a
Linux TUN device driver which provides a virtual network interface. Communication
between client-side and server-side TUN interfaces is implemented with the L4 Inter-
Process-Communication (IPC) facility.

Implementation

Figure 3.5 illustrates the client-server protocol. Client and server first initialise a virtual
network device (tun device). The server task registers itself at the naming service so
that the client task can do an open()-call. Upon successful completion of the open()-
call, client and server maintain a mapping from each other’s thread id to their virtual
local network device. Ethernet frames written to a virtual network device are then
transferred via IPC to the peer task.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

open()

Client

Bridgeserver

- create tun-device
- ask naming service
for "bridgeserver"
- map tun-device to server
thread id
- call open()
- server_loop()

- create tun-devices
- register main thread
as "bridgeserver"
- server_loop()
- on open() call:
map tun-device to client
thread id

write(frame)

Figure 3.5: Protocol

3.2

Security Considerations for the CC@H Scenario

In section 1.2 we identified threats that have to be considered for the CC@H scenario.
Following we will show why and how our implementation of the security services
solves or mitigates threats to the systems and the assets of their owners. But first we
give a short description of the basic security concepts that are used to fulfil the security
requirements of the CC@H scenario.

3.2.1

Basic Security Concepts

Trusted Channels

The inter-process communication (IPC) provided by the virtualisation layer enables
secure channels between local compartments that enforce confidentiality and integrity
protection. To provide secure channels also between local and remote compartments,
we suggest the application of common established mechanisms for communication se-
curity such as SSH [41] and TLS [6], [2]. In order to extend secure channels to trusted
channels that enable a party to verify a compartment’s configuration, we have imple-
mented the Trust Manager (

T M

) and the Compartment Manager (

). Both together

allow local and remote compartments to determine the configuration of their commu-
nication contacts and thus to derive their trustworthiness. Moreover, our architecture
enforces that information bound to a determined configuration cannot be accessed by an
unauthorised (and potentially untrusted) configuration based on the TCG mechanisms
sealing and binding. The secure Initialisation process (cf. Section 3.1.2) however en-
forces the trustworthiness of

T M

and the underlying TCB.

Strong Isolation

In order to strongly isolate compartments from each other, isolation at runtime as well
as isolation in persistent storage is required. Runtime isolation is provided by the small
virtualisation layer that implements only logical address spaces, inter-process commu-
nication (IPC) and an appropriate interface to enforce an access control management
for the underlying hardware. Device drivers and other essential operating system ser-
vices, such as process management and memory management, run in isolated user-
mode processes. Thus, the amount of code running in privileged (“ring 0”) processor
mode, is clearly minimised and can, in contrast to monolithic operating system ker-
nels such as Linux or MS Windows, properly be verified for its correctness. Moreover,
a failure in one of these services cannot directly affect the other services, especially
the code running in privileged mode. Thus, malicious device drivers cannot compro-
mise core operating system services as they are all executed in user-mode. Isolation in

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

OpenTC D05.2 – Proof of Concept of the Security Services

persistent storage is provided by our Storage Manager (

) implementation and the

usage of trusted channels. Since conventional computer architectures cannot provide
a trusted channel to the persistent storage device, an adversary can always arbitrarily
change the state of the storage or access the communication to and from the corre-
sponding controller. We prevent such offline manipulations and replay attacks while
establishing a trusted channel to

during the secure Initialisation (cf. Section 3.1.2)

process that enables the platform to verify the trustworthiness of

Trusted Storage

Our architecture provides secure storage, i.e., storage providing integrity and confiden-
tiality, using established cryptographic mechanisms. However, we improved common
approaches while taking advantage of the strong isolation capability of our architec-
ture that prevents the exposure of cryptographic secrets to unauthorised or malicious
processes. We also extended the secure storage by a hardware-based freshness detec-
tion mechanism that detects outdated persistently stored information, i.e., information
that indeed could be decrypted and verified for integrity but that was not the informa-
tion written at last. Having a freshness detection mechanism for persistent storage,
our architecture is able to manage for instance stateful licenses while preventing the
corresponding replay attacks. In order to provide Trusted Storage, i.e., storage that
enables other compartments to persistently bind their local states to their actual config-
uration while preserving integrity, confidentiality and freshness, we employ the Storage
Manager (

) together with the Compartment Manager (

). As

innately en-

forces integrity, confidentiality and freshness,

provides trustworthy measurement

of compartments configuration used by

to return information requested on load

only to compartments with the same configuration as provided on the preceding stor-
age request. The secure Initialisation (cf. Section 3.1.2) however, again enforces the
trustworthiness of

and the underlying TCB. Manipulation of protected stor-

age is not feasible with regard to the TCG attacker model which assumes that a TPM
is only vulnerable to hardware attacks.

3.2.2

Facing Threats

Now we describe how the security concepts mentioned above are used to encounter the
threats enlisted in section 1.2.

Threats to the Corporation

The PC of the employee gets lost, and the finder/thief is able to read confidential
corporate data stored on the computer.

This can be prevented by sealing data using

the storage manager. The data is stored bound to an authorisation secret, so the find-
er/thief is not able to access the data booting up the system the normal way. This can
be done by recommending authentication when the corporate compartment is started.
To access the data using another computer system by, e.g., removing the hard disk from
the employee’s system is impossible because the data is stored sealed to a specific state
(also hardware) and thus stays encrypted when mounted into another system.

TPM technology stems from smartcard technology. Some TPMs are certified according to Common

Criteria EAL 4+.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

CHAPTER 3. L4 SECURITY SERVICES

An attacker gains illegitimate access to the network of the corporation using its
own or a employee’s computer.

To access the companies network a certificate and a

certain platform configuration are necessary. Accessing the network just having a plat-
form in the right configuration thus is not sufficient. The furthermore needed certifi-
cates handed out to the employees by the IT department of the company to authenticate
themselves are stored sealed on a employee’s storage device (this could also be a USB
stick). Their usage is only possible if a system is in a specific state and a password has
been entered. Therefore an attacker is only able to access the company’s network if she
gains access to an employee’s storage device as well as the proper password and fur-
thermore operates a system that is in a state considered acceptable by the company’s
VPN gateway. Although this may happen, the risk is small. Apart from that a rigid
access control system (e.g. like in SE Linux) that regulates data access directly on the
company’s servers can be used to prevent further damage.

Threats to the Employee

The employee’s system is altered by the installation of the corporate compartment
resulting in a situation that the computer is no longer usable for private purposes
because of, e.g., restrictive security guidelines.

The hypervisor and the security

services are able to guarantee isolation between compartments to a very high degree.
Therefore the user should be able to run in parallel whatever she likes. Trusted channels
and the strong isolation concepts described above take care of the proper separation.
But in certain circumstances like, e.g., if the employee has to work on very sensitive
data the security policy may require no untrusted compartment running in parallel to
the corporate compartment. This would be enforced by the security services namely
the compartment manager. However it is still possible to use untrusted compartments
when the corporate compartment is not running.

Access to private data stored on the employee’s system may be possible for other
company members, e.g., the administrator.

This can also be avoided by strong

isolation. Data used in specific compartments can be sealed to be only usable within
them. If another compartment tries to access the sealed data access will be denied.
However there exists a problem concerning remote administration by the company’s
IT department. In theory it would be possible for the remote administrator to alter
the security policies/properties of other compartments and applications installed on the
system but this can be detected by the user by letting the system attest to its state before
using it for private purposes.

Threats to both

Direct Memory Access (DMA)

DMA attacks can only be prevented by the underly-

ing hardware platform using Intel’s or AMD’s new security extensions (cf. [13], [1]).
Without these extensions our concept of security services hinders the drivers to manip-
ulate memory or kernel files directly because they do not run in kernel-mode but DMA
attacks are still feasible.

Illegitimately modified compartments, e.g., Malware is installed/executed

An of-

fline manipulation of a compartment is detected at the moment it starts up, because
its data is sealed against a certain state. Thus, if it is altered while it wasn’t running
access to its data will be impossible at the next startup. An online manipulation, e.g.,

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

Bibliography

[1] AMD.

Amd i/o virtualization technology (iommu) specification.

AMD

- IOMMU Architectural Specification, Feb. 2007.

http://www.amd.com/us-

en/assets/content_type/white_papers_and_tech_docs/34434.pdf.

[2] N. Asokan, Y. Gasmi, A. R. Sadeghi, P. Stewin, and M. Unger. Beyond secure

channels. ACM-STC 2007, June 2007.

[3] S. Berger, R. Cáceres, K. Goldman, R. Perez, R. Sailer, and L. van Doorn. vTPM:

Virtualizing the Trusted Platform Module. In Proc. 15th USENIX Security Sym-
posium, pages 21–21, 2006.

[4] S. Cabuk, C. Dalton, H. V. Ramasamy, and M. Schunter. Towards Automated

Provisioning of Secure Virtualized Networks. In Proc. 14th ACM Conference on
Computer and Communications Security (CCS-2007), Oct. 2007. To appear.

[5] I. Damgard, T. Pedersen, and B. Pfitzmann. Statistical Secrecy and Multi-Bit

Commitments. IEEE Transactions on Information Theory, 44(3):1143–1151,
1998.

[6] T. Dierks and C. Allen. RFC2246 - the TLS protocol version 1.0.

www.ietf.org/

rfc/rfc2246.txt

, January 1999.

[7] B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt, A. Warfield, P. Barham,

and R. Neugebauer. Xen and the art of virtualization. In Proceedings of the ACM
Symposium on Operating Systems Principles, October 2003.

[8] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: a Vir-

tual Machine-based Platform for Trusted Computing. In Proc. 19th ACM Sympo-
sium on Operating Systems Principles (SOSP-2003), pages 193–206. ACM Press,
2003.

[9] O. Goldreich, S. Micali, and A. Wigderson. Proofs that Yield Nothing but their

Validity, or All Languages in NP have Zero-Knowledge Proof Systems. Journal
of the ACM, 38(3):690–728, 1991.

[10] J. Griffin, T. Jaeger, R. Perez, R. Sailer, L. V. Doorn, and R. Caceres. Trusted

Virtual Domains: Toward Secure Distributed Services. In Proc. 1st Workshop
on Hot Topics in System Dependability (Hotdep-2005), Yokohama, Japan, June
2005. IEEE Press.

[11] V. Haldar, D. Chandra, and M. Franz. Semantic Remote Attestation - Virtual

Machine Directed Approach to Trusted Computing. In USENIX Virtual Machine
Research and Technology Symposium, pages 29–41, 2004.

OpenTC D05.2 – Proof of Concept of the Security Services

[12] V. Haldar, D. Chandra, and M. Franz. Semantic remote attestation: A virtual

machine directed approach to trusted computing. In USENIX Virtual Machine
Research and Technology Symposium, May 2004. also Technical Report No.
03-20, School of Information and Computer Science, University of California,
Irvine; October 2003.

[13] Intel. Intel trusted execution technology. Intel - Technology Overview, Jan. 2007.

http://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdf.

[14] B. Jansen, H. Ramasamy, and M. Schunter. Compliance proofs and policy en-

forcement for xen virtual machines. In Submitted for Publication, 2007.

[15] H. A. Lagar-Cavilla. Vmgl: Vmm-independent graphics acceleration. In Xen

Summit 2007, 2007.

[16] P. Loscocco and S. Smalley. Integrating flexible support for security policies into

the Linux operating system. Technical report, U.S. National Security Agency
(NSA), Feb. 2001.

[17] R. MacDonald, S. Smith, J. Marchesini, and O. Wild. Bear: An open-source

virtual secure coprocessor based on TCPA. Technical Report TR2003-471, De-
partment of Computer Science, Dartmouth College, 2003.

[18] J. Marchesini, S. W. Smith, O. Wild, and R. MacDonald. Experimenting with TC-

PA/TCG hardware, or: How I learned to stop worrying and love the bear. Techni-
cal Report TR2003-476, Department of Computer Science, Dartmouth College,
2003.

[19] National Institute of Standards and Technology. FIPS-197: Advanced Encryp-

tion Standard (AES).

http://csrc.nist.gov/publications/fips/fips197/fips-197.

pdf

, November 2001.

[20] National Institute of Standards and Technology.

FIPS-180-2:

Secure

Hash Standard (SHS).

http://csrc.nist.gov/publications/fips/fips180-2/

fips180-2withchangenotice.pdf

, August 2002.

[21] C. C. P. S. Organisations. Common Criteria for Information Technology Security

Evaluation (version 2.0). May 1998, adopted by ISO/IEC as Draft International
Standard DIS 15408 1-3.

[22] B. Pfitzmann, J. Riordan, C. Stüble, M. Waidner, and A. Weber. The PERSEUS

system architecture. Technical Report RZ 3335 (#93381), IBM Research Divi-
sion, Zurich Laboratory, Apr. 2001.

[23] G. J. Popek and R. P. Goldberg. Formal requirements for virtualizable third gen-

eration architectures. Communications of the ACM, 17(7):412–421, 1974.

[24] J. Poritz, M. Schunter, E. V. Herreweghen, and M. Waidner. Property Attestation –

Scalable and Privacy-friendly Security Assessment of Peer Computers. Technical
Report RZ 3548 (# 99559), IBM Research Division, May 2004.

[25] J. Poritz, M. Schunter, E. Van Herreweghen, and M. Waidner.

Property

attestation—scalable and privacy-friendly security assessment of peer computers.
Technical Report RZ 3548, IBM Research, May 2004.

OpenTC Document D05.2/V01 – Final R4948/2007/11/23/OpenTC Public (PU)

BIBLIOGRAPHY

[26] A.-R. Sadeghi and C. Stüble. Bridging the gap between TCPA/Palladium and

personal security. Technical report, Saarland University, Germany, 2003.

[27] A.-R. Sadeghi and C. Stüble. Property-based Attestation for Computing Plat-

forms: Caring about Properties, not Mechanisms. In Proc. 2004 Workshop on
New Security Paradigms (NSPW-2004), pages 67–77. ACM Press, 2005.

[28] A.-R. Sadeghi, C. Stüble, and N. Pohlmann. European multilateral secure com-

puting base – open trusted computing for you and me. Datenschutz und Daten-
sicherheit DuD, 28(9):548–554, 2004. Verlag Friedrich Vierweg & Sohn, Wies-
baden.

[29] R. Sailer, T. Jaeger, E. Valdez, R. Perez, S. Berger, J. L. Griffin, and L. van Doorn.

Building a MAC-based security architecture for the Xen open-source hypervisor.
Research Report RC23629, IBM Research Division, June 2005.

[30] R. Sailer, T. Jaeger, X. Zhang, and L. van Doorn.

Attestation-based policy

enforcement for remote access. In Proceedings of the 11th ACM Conference
on Computer and Communications Security, Washington, DC, USA, Oct. 2004.
ACM Press.

[31] R. Sailer, E. Valdez, T. Jaeger, R. Perez, L. van Doorn, J. L. Griffin, and S. Berger.

sHype: Secure hypervisor approach to trusted virtualized systems. Techn. Rep.
RC23511, Feb. 2005. IBM Research Division.

[32] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and Implementation of a

TCG-based Integrity Measurement Architecture. In Proc. 13th USENIX Security
Symposium, pages 16–16. USENIX Association, Aug. 2004.

[33] TCG Infrastructure Workgroup. TCG infrastructure workgroup subject key attes-

tation evidence extension specification version 1.0 revision 7, June 2005.

[34] TrustedGRUB.

http://sourceforge.net/projects/trustedgrub

[35] TrouSerS. The open-source TCG software stack.

http://trousers.sourceforge.

net

[36] Trusted Computing Group.