Fine-grained Trust Domains: Unlike today’s version of Xen, we separate ser-
vices into small isolated virtual machines to increase robustness and security.

•

Policy-enforcement: The virtualisation layer is built to enforce a wide range of
security policies. Examples include access and flow control policies as well as
resource sharing policies.

•

Verifiable security: By means of trusted computing, external stakeholders can
verify the virtualisation layer and its policies.

The virtualisation layer offers a basic management interface (BMI) to the security ser-
vices layer. The interface supports functions like creating a virtual machine while
specifying its virtual network cards, memory, storage, and CPUs. An example of a
policy that can be enforced at the virtualisation layer are sHype policies that can be
loaded at boot-time [81].

1.3.2

Security Services Layer

The security services layer provides scalable security and virtualisation functions that
are needed to enforce security policies. This includes compartment security manage-
ment, user security management, and secure device virtualisation.

The compartment security manager manages the life-cycle of virtual machines and

tracks the security policies and other context associated with each compartment. This
includes integrity constraints, permissions, and global identifiers for each compart-
ment. The compartment security manager can be used to prove selected security prop-
erties to peers. The user security manager manages the users of the system and enables
authentication of individual users and their associated roles.

An important contribution to scalability for trusted computing is the focus on se-

curity properties for trust management [71, 78, 35]. Instead of verifying integrity by
means of cryptographic checksums, we use higher-level properties such as user roles,
machine types, or trust domains to determine trust. This is done by first using check-
sums to verify the core security services and then use these security services to evalu-
ate the desired security properties. Only if these properties are satisfied, certain actions
such as unsealing a key or performing a transaction with a peer are performed. The con-
sequence is that a verifier only needs to define security properties to be satisfied and no
longer needs to track individual software configurations that are deemed trustworthy
(see Section 7.1).

Virtualised devices can include any device that can be made to support virtual-

isation. Secure storage provide virtual partitions with integrity, confidentiality, and
freshness guarantees. Virtual networks can provide mutually isolated virtual network
topologies and secure transport (cf. [34]). The implementation of trusted user inter-
faces depends on the environment. A simple solution that is sufficient for reliable
selecting a compartment can be implemented by a secure hot-key that is caught by a
virtualised keyboard driver. Another alternative is a multi-compartment graphical user
interface that assigns a distinguishable window to each compartment. An third option
are remote user interfaces such as a secure shell management console or a remotely
accessible management service. In our secure transaction scenario the user can use a
hot-key to switch compartments. In a server setting, the shell will indicate the com-
partment that it is operating on. The cryptographic services include a virtual TPM [10]
as well as other cryptographic and key management primitives.

Open_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

For efficiency, the security services can push policies into policy enforcement func-

tions of the virtualisation layer. This is done, if fast policy enforcement is critical for
performance. E.g., a policy decision whether a certain network card can be assigned
to a newly created virtual machine can easily be done outside the hypervisor since it
is usually not performance critical. Access decision for shared resources, on the other
hand, should be executed in the core since their performance is critical.

1.3.3

Virtual Machines Layer

The virtual machines layer contains the actual virtual machines that constitute the pay-
load of the architecture. The architecture can host Windows and Linux virtual ma-
chines. This is done by providing drivers for accessing the virtual hardware provided
by the lower layers. Depending on the hypervisor, certain security services can be
implemented by a set of security management machines (Xen) or lighter-weight tasks
(L4).

1.3.4

Application Layer

In a management virtual machine, we host the management applications that allow
users to interact and maintain their platform. This includes accepting/rejecting policies
and defining or loading baseline policies that can delegate certain management func-
tions (such as trust in public keys) to other parties. Another example is the life-cycle
management of a trusted platform module.

An important class of applications are management applications. In particular, in

virtualised data centres, a scalable management infrastructure is essential. Technically,
this scalability is achieved by multiple mechanisms such as secure migration of vir-
tual machines that enables load balancing or self-service machines that obtain mainte-
nance orders and execute these orders while only reporting results to the management
servers. An example of such a pull model is patch management in which a machine
pulls the latest patch policy, then installs the patches from a cluster of software distri-
bution servers, and finally reports its success to the configuration management system.
As a consequence, central management infrastructure only manages policies while the
costly operations are distributed onto the individual machines.

1.3.5

Implementation of the Architecture

On the L4 hypervisor, the security and management services are isolated tasks that run
directly on top of the L4 micro kernel. Each service defines a well-defined interface for
inter-process communication (IPC). Interaction between services or between instances
of hosted payload virtual machines and services is performed using these interfaces.
An IPC call that is issued by a process first goes to the L4 micro kernel, which then
transfers it to the callee. The IPC mechanism is implemented similarly to the IPC
architecture of CORBA.

The implementation of the security and management services on the Xen Hyper-

visor is split into two parts. The low-level part is implemented directly in the Xen
Kernel running with full privileges. This part contains the security enforcement of the
security services. The lower-level part controls the basic access, communication and

Open_TC Deliverable 05.1

CHAPTER 1. INTRODUCTION AND STATE-OF-THE-ART

Platform

Management

Domain

Management

Resource

Management

Network

Management

Hardware & Virtualisation Layer

Figure 1.2: A high-level abstraction of the management components.

enforcement and provides a well-defined interface to the higher layers. The higher
level includes non-enforcement parts of the security services as well as the manage-
ment components. Both run in one or more

service virtual machines or in a special

security service virtual machine as normal user processes.

1.4

High-level Management Architecture

Figure 1.2 illustrates a high-level abstraction of the management components that are
required to manage virtualised platforms. Each component concentrates on a specific
aspect of virtualised platform management. Platform management involves the life-
cycle management of the underlying physical platform and its security device (e.g.,
trusted platform module (TPM)). Domain management deals with the management
of virtual domain users and life-cycle. Virtual devices such as virtual network inter-
faces [34], virtualised TPMs [10], and virtualised user interfaces [68] are managed
through resource management. Network management makes use of these virtualised
devices to further enable virtual topologies using various network virtualisation tech-
niques.

The management components are not mutually exclusive. That is, corresponding

management duties may be handled in collaboration with more that one management
component. For example, resource management and network management collaborate
to enable and manage network virtualisation. In this setting, the former manages the
virtual network interfaces and the latter manages the virtual network topology.

Security services provide the necessary functionality for each management com-

ponent listed above and further enhance each to meet security requirements such as
integrity, isolation, access control, confidentiality, and flow control. Further, they main-
tain a unified view on security guarantees that cover multiple devices (e.g., data on a
disk being stored in a TPM) and the virtualisation layer core. Table 1.1 lists the se-
curity requirements for the underlying physical platform and the virtual domains and
resources it hosts. Figure 1.3 illustrates an example security-enhanced management
framework with the relevant functionality grouped together. The framework is built
upon the foundation of the hardware root of trust offered by the TPM. The architecture
leverages the recent advances in hardware virtualisation such as virtualisation support
in the CPU offered in the latest chips from Intel and AMD. The hardware layer includes
one of these chips and the TPM. Just above the hardware layer is a trusted virtualisa-
tion layer with strong isolation properties (among virtual domains) and well-defined
interfaces to the TPM. On top of the virtualisation layer core are the security services.

For increased security, we split the single management virtual machine of Xen into multiple smaller

ones.

Open_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Integrity

Isolation

Confidentiality

Access control

Flow control

Platform security

Domain security

Network security

Storage security

Interface security

Table 1.1: Security requirements for the physical platform, virtual domains, and virtual
devices (storage and interfaces).

Life-cycle

Management

User

Management

Integrity

Management

Credential

Management

Hardware & Virtualisation Layer

Security-enhanced Domain Management

TPM

Management

Key

Management

Security-enhanced Platform Management

vTPM

Management

vInterface

Management

vStorage

Management

vNetwork

Management

Security-enhanced Resource / Network Management

Life-cycle

Management

Figure 1.3: An example security-enhanced management framework with the relevant
functionality grouped together.

Security services models presented in this report follow the model depicted in Fig-

ure 1.3 to realise such a framework making use of the virtualisation and Trusted Com-
puting technology. However, they differ in the design and implementation. One option
is to employ a single large management domain to orchestrate the management oper-
ations. An alternative approach follows a distributed model to employ small manage-
ment domains to distribute the management functionality across the platform.

Open_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

TCB Measurement.

In particular, each software component in the Trusted Comput-

ing Base (TCB) is first measured and then recorded before the control is passed to it.
These measurements are stored in the corresponding TPM PCRs, and are incremental.
That is, a sequence of measurements can be recorded in the same register by incre-
mentally extending the previous measurement without changing its size, thus enabling
virtually infinite number of measurements. This way, the complete execution sequence
can be recorded enabling a third-party to verify it at a later phase.

Remote Attestation.

A user can verify the correct operation of a trusted comput-

ing platform, for example, before exchanging data with the platform, by requesting
the trusted platform to provide one or more integrity metrics. The user receives the
integrity metric or metrics, and compares them against values which it believes to be
true (these values being provided by a trusted party that is prepared to vouch for the
trustworthiness of the platform or by another party the user is willing to trust). If there
is a match, the implication is that at least part of the platform is operating correctly,
depending on the scope of the integrity metric. If there is no match, the assumption
is that the entire platform has been subverted and cannot be trusted (unless isolation
technologies are employed to restrict the scope of what cannot be trusted).

2.1.1

Limitations

The static TCG architecture imposes several limitations on complex dynamic platforms
in which platform configuration and security policies are allowed to change frequently:

Linear Chain-of-Trust

The TCG measurement model follows a linear model to

form a chain-of-trust rather than branching out hierarchically. This results in a lin-
ear dependency relation between the platform components. However, in complex plat-
forms this conservative approach may prove impractical because a linear dependency is
often not the case. That is, components may form independent trust chains all branch-
ing out from a common root.

An expensive solution to this problem suggested by the TCG is to identify and

group dependent components together and employ more than one PCR to store the
measurement for each group. However, because the number of registers is limited, this
solution is not scalable. Further, the TCG does not provide any mechanism to manage
these measurement groups at a later stage.

Static Measurement Model

Current TCG schemes fail to address the cases in which

measured platform components are allowed to change into another form (e.g., through
a software update) or adapt to current conditions. Further, certain platform compo-
nents may function in various operating modes (e.g., with different configurations) to
perform operations with varying security needs. In either case, the TCG takes the con-
servative approach to deem any such change as potentially malicious and irreversible.

The TCG requires on-going measurements to take place using measurement agents

to monitor ongoing activity. However, these measurements are static and irreversible.
For example, if a platform component changes into another form and changes back into
its original form, the static solution requires a complete reboot and the re-measuring
of the entire chain-of-trust to be able to re-establish trustworthiness. This approach

Open_TC Deliverable 05.1

CHAPTER 2. BACKGROUND AND RELATED WORK

can be beneficial for platforms in which one cannot evaluate what impact such changes
may have on the platform. However, it is impractical for dynamic platforms in which
platform components are allowed to change frequently and run in various operating
modes.

2.2

Secure Operating Systems

Much effort has already been put into improving security of computing platforms since
computers are used within infrastructures that require management of sensitive data.
Examples of systems that were developed from scratch to respect security require-
ments are BirliX [37], Multics [23] and Hydra [21] or more recent ones are EROS [87]
and SPIN [11]. The problems inherent to these approaches is that systems particularly
designed for preserving security tend to be very inflexible or software cannot be ported
easily to these systems or has to be developed from scratch. These factors inhibit these
approaches to be applied in a large scale. SELinux [88] suffers from similar prob-
lems. While allowing legacy applications to run, SELinux claims to achieve security
by defining and enforcing specific security policies, but writing these security policies
turned out to be far too complicated. Furthermore these approaches although especially
designed to preserve security have been proves to be vulnerable to attacks [48]. Other
approaches rely on special hardware, e.g., secure coprocessors, to realise their security
goals like Dyad [104] for example. In this system similar measures to keep data secure
are applied like in our approach, but in contrast to the OpenTC approach they rely on a
physically fully separated execution environment. Thus, additional costs for this sep-
arated environment are induced. By providing logical separation we omit these costs.
Another approach represents the “Bear” project [60] of the Dartmouth College. In this
system TCG hardware is used by an adapted boot loader to provide a chain of trust and
a Linux security kernel module monitors changes to sensitive data. The weakness of
this system is that it still relies on a large monolithic kernel. Marchesini et. al. [61]
propose OS-hardening techniques to provide isolation of environments but they also
use a monolithic kernel as base for their system. As result performance loss occurs
and the overall improvement of security is rather small, because these legacy mono-
lithic kernels are too large to evaluate their security. Therefore, we aim at keeping the
amount of code that has to be evaluated as small as possible by using virtualisation
and microkernel techniques. Other advantages of the OpenTC approach is that legacy
software does not have to be adapted to run without perceptible performance loss.

2.2.1

Approaches using Virtualisation

The Terra [31] system represents promising approach to secure virtualisation by di-
viding the system in closed-box and open-box virtual machines. Closed-box virtual
machines run separated from others and are capable to provide a security enhanced
environment for applications processing sensitive data.

2.2.2

Approaches using Microkernels

Examples for systems using microkernels are SawMill-Linux [33] based on the L4
microkernel [58] and Flask [91], a Mach-based system. As far as we know these ap-

Although dynamic root of trust feature was introduced in TPM v1.2 that can potentially address this

problem, the problem of dynamically managing software states remains unaddressed.

Open_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

proaches neither aim at keeping security relevant parts as small as possible, nor do they
provide mechanisms such as trusted path or protected environments.

2.3

Secure Virtual Networking

Previous work on virtualising physical networks can be roughly grouped into two
categories:

those based on Ethernet virtualisation and those based on TCP/IP-

level virtualisation. Although both categories include a substantial amount of work
(e.g., [42, 4, 9, 24, 25, 67, 92, 98, 99]), few studies have an explicit security focus.

Ethernet Virtualisation:

Ethernet virtualisation aims at transporting multiple Ether-

net connections over a single physical medium. There are a large number of Ethernet
tunnelling protocols [25]. Local transport over a “trusted” wire is usually multiplexed
using the well-established VLAN standard IEEE 802.1Q-2003 [40]. It adds virtual
LAN tags to each Ethernet segment and enables separation of multiple networks. An
example for high-performance Infiniband VLANs is given in [38]. In wide-area net-
works, VLAN tags are often not preserved. To overcome these restrictions, Ethernet
encapsulation has been proposed as an alternative [42, 92, 24, 25]. Ethernet packets
(including tags) are wrapped into TCP/IP packets. This enables the embedding of a vir-
tual Ethernet network into a wide-area network. Unfortunately, the performance and
scalability of the resulting system are limited.

Overlay Networks and TCP/IP Virtualisation:

Overlay networking provides

application-level network virtualisation among participating hosts. An overlay net-
work typically consists of hosts (physical or virtual), routers, and tunnels that serve as
virtual links between the hosts. Several overlay designs have been introduced in the
literature: PlanetNet VNET [67, 9], X-Bone [98], Resilient Overlay Networks [4], and
the JXTA project [99]. The designs share the common goal of creating a virtualised
network layer with a customised topology mapped onto the actual physical infrastruc-
ture. They differ in the underlying technology that enables the mapping, management
of the technology, and the terminology used.

Overlay networks are most useful for implementing a virtual network topology on

top of the physical topology. However, they are not suitable for systems with strong
separation, isolation, and flow control requirements. As an example, although the Plan-
etLab VNET provides separation of network packets originating from different slices,
the separation is merely enforced using the OS network services [9]. Similarly in
JXTA, peer groups are used to group network peers and enforce certain isolation prop-
erties [99]. However, it is the network administrator’s responsibility to enforce flow
control policies across group boundaries as JXTA does not impose any specific flow
control schemes for the sake of flexibility. Other shortcomings of overlay networks are
complex management models, binary intra-group flow policies, and lack of inter-group
flow control policies.

The VIOLIN project addresses a number of these deficiencies and enhances the

traditional TCP/IP overlay networks to create mutually isolated distributed environ-
ments [45, 74]. The main idea is to provide each subsystem with a virtual IP world
having its own address space. In particular, a VIOLIN is created on top of an overlay
network (such as PlanetLab [9]) and consists of virtual hosts, switches, and routers.
Communication between these entities is enabled through a User-Mode Linux (UML)

pen_TC Deliverable 05.1

CHAPTER 2. BACKGROUND AND RELATED WORK

implementation enhanced with UDP-tunnelling for inter-host communication

. The

VIOLIN model provides isolation between different VIOLINs, which in turn enhances
mobility through location-independent addressing. Further, the model enables the cus-
tomisation of each VIOLIN with the desired technology (e.g., IPv6) without requiring a
global deployment. A major disadvantage of VIOLIN is that the model completely dis-
allows inter-VIOLIN communication rather than adopting a policy-based flow control
scheme. In practice, it may be desirable for VIOLINs belonging to different organi-
sations to interact with each other under certain flow control policies enforced at each
VIOLIN boundary.

Previous solutions also offered network virtualisation schemes that do not rely on

overlay networking. Spawning networks employ nested programmable networks to
form a hierarchy of virtual networks that are isolated from each other [16, 17, 52]. The
main idea is to enable parent networks to spawn child networks that utilise the parents’
resources. The child networks then may or may not choose to inherit certain charac-
teristics from their parent. The advantages are that the child networks can employ a
specialised networking technology (e.g., a mobile-IP network) while inheriting basic
network functionality from their parent. Further, they can spawn child networks of
their own, forming a forest of networks.

Spawning networks utilise the Genesis network kernel [52] that enables the life-

cycle management of each spawned network including the spawning capability. The
Genesis kernel is a complex virtual networking kernel that needs to be installed on ev-
ery physical domain that will potentially host spawning networks. The major downside
is that this requires major changes to the existing network infrastructure.

2.4

Attestation and Integrity Verification

There have been several proposals in the literature for protecting and proving the in-
tegrity of computing platforms based on cryptographic techniques and trusted compo-
nents. Known aspects in this context are secure and authenticated (or trusted) booting.
The former means that a system can measure its own integrity and terminates the boot
process in case the integrity check fails, whereas the latter aims at proving the platform
integrity to a (remote) verifier (for both topics see, e.g., [5], [29], [84], [89], [110]).

The property attestation approach outlined in Section 7.1.7 was first proposed in

[71] to prevent the deficiencies of the existing binary attestation (see Figure 2.1 a)).
Similar to the certificate-based detection method discussed in Section 7.1.6, this solu-
tion is based on property certificates that are used by a verification proxy to translate
binary attestations into property attestations.

In [44], an abstract integrity model for virtual machine monitors is provided. The

authors introduce a more formal notation for attestation and sealing. Their notation
for attestation introduces a function that can be used to define attestation of properties
by mapping configurations to a corresponding property. Binary attestation is obtained
when the identity function is given.

The authors of [35] propose semantic remote attestation – using language-based

trusted virtual machines (VM) to remotely attest high-level program properties (see
Figure 2.1 b)). The general idea behind this approach is the use of a trusted virtual
machine that checks the security policy of the code that runs within the VM. Since
the trusted VM still has to be binary attested, semantic remote attestation is a hybrid
solution with code analysis (see Section 7.1.6).

A Xen-based solution has recently been introduced [75].

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Verification

Proxy

insecure channel

secure channel

TPM

data(D)

exec(H)

Attestor

data(D)

TPM

data(D)

Attestor

Linux & Enforcer

Applications

Servers

Directory

data(D)

Trusted VM

TPM

data(D)

Secure OS

Attestor

attest(H|TVM|OS)

seal(H|TVM|OS,D)

send(m)

receive(m)

send(m)

receive(m)

attest(p)

seal(p,D)

attest(p)

seal(p,D)

boot(C )

attest(C )

seal(C ,D)

TVM

exec(C )

TSL

exec(C )

TSL

boot(C |C )

boot(C |C |C )

TVM

Figure 2.1: Comparison of related approaches: a) Property Attestation, b) Semantic
Remote Attestation, c) The Enforcer Project

In [60], [62], and [61] the authors propose a software architecture based on Linux

providing attestation and sealing (see Figure 2.1 c)). The architecture allows to bind
short-lifetime data (e.g., application data) to long-lifetime data (e.g., the Linux kernel)
and to allow access to the data only if the system is compatible to a security policy
certified by a security administrator. Moreover, the papers suggest to use a certification
authority that certifies the trustworthiness of certain configurations of long-lifetime
data. Thus, the proposed architecture is very similar to a hybrid approach based on
property certificates.

2.5

Virtualisation and Dependability

We now give a sampling of related work in the area of using virtual machines for
improving dependability. Bressoud and Schneider [12] implemented a primary-backup
replication protocol tolerant to benign faults at the VMM level. The protocol resolves
non-determinism by logging the results of all non-deterministic actions taken by the
primary and then applying the same results at the backups to maintain state consistency.
By treating the entire VM as a state machine, their approach does not require any
modifications to the hardware, the guest OS, or the application program. However, the
downside of the approach is the significant performance overhead incurred.

Commercial products such as VMware Double-Take [105] also do VM-based fault

tolerance.

Double-Take uses hardware-based real-time synchronous replication to

replicate application data from multiple VMs to a single physical machine so that the
application can automatically fail over to a spare machine by importing the replicated
data in case of an outage. As the replication is done at the file system level below
the VM, the technique is guest-OS-agnostic. Such a design could provide the basis
for a business model in which multiple client companies outsource their disaster re-
covery capability to a disaster recovery hot-site that houses multiple backup physical
machines, one for each client.

Douceur and Howell [26] describe how VMMs can be used to ensure that VMs

satisfy determinism and thereby enable state machine replication at the VM level rather
than the application level. Specifically, they describe how a VM’s virtual disk and clock

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Physical Hardware

Management

of security,

devices,

VMs, and I/O

Dom0

GuestOS

User

Software

DomU 1

GuestOS

User

Software

DomU 2

GuestOS

User

Software

DomU 3

VMM Core

Figure 3.1: Xen Virtual Machine Architecture

In this setting, Dom0 and the underlying hypervisor are responsible for: (1) building
and managing user domains, (2) managing virtualised devices and making them avail-
able to user domains, (3) managing virtual network interfaces and topologies, and (4)
allowing interfaces for inter-domain communication.

User domains are managed by the management domain throughout their life-cycle.

The privileged management domain itself is bootstrapped by the underlying Xen hy-
pervisor which passes control to it upon successful initiation. Dom0 then assumes full
control over its life-cycle and the life-cycle of user domains. The latter involves domain
creation, suspension, hibernation, migration, and termination.

The Xen functional model requires a privileged Dom0 to be active on the platform

at all times (i.e., user domains cannot exist without a management domain (existential
policy)). Further, Dom0 is trusted at all times and the platform is trusted if and only
if the hypervisor and Dom0 (i.e., Trusted Computing Base (TCB)) is trusted. Con-
trastively, if Dom0 or the hypervisor is compromised, all user domains are rendered
compromised as well. The hypervisor and Dom0 further provides the necessary isola-
tion between user domains (vertical isolation) as well as the isolation between Dom0
and the user domains (horizontal isolation). As an example to the former, a compro-
mised or a defunct user domain should not have any side-effects on any other user
domain. Similarly, a compromised or a defunct user domain should not have any ef-
fects on Dom0. However, a compromised or a defunct Dom0 renders all user domains
compromised or defunct.

The management domain additionally acts as a driver domain that directs I/O re-

quests from user domains to the underlying hardware devices. For a given physical
device, the native device driver is part of at most one VM. If the device is to be shared
with other VMs, then the VM with the native device driver makes the device avail-
able through device channels implemented using shared memory. The virtual device
organisation of Xen splits drivers into two parts: a front-end driver and a back-end
driver. A front-end driver is a special driver that resides within the kernel of the guest
domain. The back-end portion of the driver resides within the kernel of the driver do-
main (Dom0 or the domain with the native device driver) and creates a virtual device
within the driver domain for every front-end device in a guest domain that gets created.
Conceptually, the pair of front-end and back-end devices behaves as follows: Requests
sent out by the front-end device in the guest domain appear as requests received by
the back-end device in the driver domain. Similarly, requests sent out by the back-end
device by the driver domain appear as requests received by the front-end device. In
its standard configuration, Xen is configured to forward the driver domain back-end
request to the real physical device. By this mechanism, requests generated by a guest
domain find their way to the physical device and vice versa.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Xen Core

Dom0 Kernel

Dom0 Userspace

DomU

DomU Kernel

xenstored

xenconsoled

blktapctrl

libxenstore

libxenguest

libxenctrl

Libotcxen/BMI

Compartment

Manager

SVDM

Integrity Mgmt

XenAPI/OTC API

Xenbus IF

netback

console

blkback

blktap

Xenbus IF

netfront

Security Services

Figure 3.2: Security services in Xen context.

Lastly, the Xen architecture allows communication between user domains and be-

tween a user domain and Dom0 using various inter-domain communication (IDC) tech-
niques. Briefly, memory pages can be shared between domains using grant tables.
Similarly, event channels are used for event notification. Further, recent implemen-
tations of IDC [59] use a socket-like interface to read/write from/to domains that is
shown to perform better than employing the network stack for communication. IDC is
coordinated and managed by Dom0 and the underlying hypervisor.

3.1.3

Xen Architecture

Figure 3.2 depicts a snapshot of a Xen platform with potential security services in con-
text. Xen security services realise security-enhanced management of the virtualised
platform. To do so, they mainly make use of the domain management functional-
ity provided by the Xen API, and the underlying inter-domain communication and
front/back-end device architecture (e.g., netback / netfront in the figure). Further, they
employ libraries to access the underlying hardware security device (i.e., TPM) to store
secrets securely and make use of the sealing capability (not shown in the figure).

Because security services run in a privileged domain they are considered privileged

services. That is, a platform user needs to trust (and verify) the correct operation of
these services in order to be able to trust the platform. Therefore, in this setting, the
security services are considered to be a part of the platform TCB and they are measured
during the platform bootstrap along with the other Dom0 components. This centralised
approach yields a practical solution to domain and service management as no inter-
domain communication is needed to interact with other services. The disadvantage
is that a compromised service effectively renders the complete platform compromised
(i.e., untrusted).

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

3.1.4

Xen Disaggregation

Recently, the Xen community has been working on a distributed solution to domain
management. The work involves the disaggregation of Xen Dom0 into smaller man-
agement domains that work in coordination. The main goal is to reduce the size of
Dom0, hence the size of the TCB that a platform user needs to trust in order to trust the
platform. Further, this approach results in management components virtually indepen-
dent from each other in terms of integrity. In this setting, a compromised component no
longer results in a platform that is considered compromised as a whole. This security
advantage is countered by the negative performance impact. This is because by sepa-
rating the services some of which may work together, the overall inter-domain traffic
is potentially increased.

An example implementation uses a separate domain to handle domain management

(i.e,. building) duties. The resulting domain is called DomB (i.e., domain builder) that
is designed to be considerably smaller than the Dom0. The idea is that in cases Dom0
is compromised, DomB may still function practically allowing it to spawn a fresh /
un-compromised version of Dom0. The work is in progress.

3.2

Xen Security Services

Lack of security of VMs and lack of trust in the correct execution of virtualisation
engines are a major concern limiting the broad adoption of VM technology. Perhaps,
nowhere is this concern more evident than in data centres where VMs belonging to
multiple (perhaps, competing) companies are to be hosted on the same physical infras-
tructure.

We are interested in the following ways to provide better security of VMs:

1. At the virtualisation software level, the policy enforcement capabilities of the

VMM itself can be significantly improved to allow enforcement of more strin-
gent and fine-grained security policies [81].

2. Implement sound policy management and enforcement of information flow con-

straints. One example are virtual firewalls.

3. Increasing security of virtualised devices. One example is secure virtualised

storage.

4. Integrate integrity validation and protection mechanisms into the VMM. This

means that customers can validate the integrity of the VMM and its essential
services.

We are interested in enhancing the security of the virtualisation layer by estab-

lishing finer-grained trust domains and offering methods for external stake-holders to
verify, using Trusted Computing (TC), the integrity of the virtualisation software layer
and its associated policies. Complementing those methods would be a new layer of
enforcement mechanisms appropriate for guiding the behaviour of the virtualisation
software layer and hosted operating system instances. These enforcement mechanisms
are what we call “security services.”

The enforcement capabilities of the Xen security services span multiple aspects

of a Xen-based virtual infrastructure, e.g., platform, networking, storage, VM life-
cycle, graphical user interface (GUI), TPM, and other devices. The goal is to map

pen_TC Deliverable 05.1

C
D

–

rit

Flow control

Confidentiality,
Integrity
Protection

What aspects to Seal / Attest /
Measure, and the associated
pre/post conditions

User Access
Control

Operations on, and
associated pre/post
conditions

Processor sharing on single core

Bus encryption

Start

Processor sharing on multi-core (differentiate based
on shared cache among cores)

Stop

Host sharing

Hibernate
Resume
Suspend
Share memory
Migrate
Attach Device
Replicate

Compartments/VMs

Memory sharing

Hypervisor state + Arbitrary
conditions

Seal against color,
migration/inspection policy

Read
Write
Execute

VM
image

Load control matrix (which VM can load which
image)

Whether encrypted

Hypervisor state

Which user can
read/write/execute

Load (start VM)

Storage

Disks

Mount control matrix (which VM can mount which
VM, and how it affects the states of the mounting
VM and the mounted disk)

Whether encrypted

Hypervisor state + VM state (for
data disk)

Hypervisor state (for boot disk)

Which user can
read/copy/write

Mount to VM

Attach network card
to vSwitch

Networking

Flow control matrix

Whether encryption
or MAC-
authentication
needed

Seal against access permissions
(e.g., VMs restricted to colors.
VMs that can only access a red
network)

What networking
protocols are
permitted

GUI

Copy-and-paste restriction, screenshot restriction

Keyboard, Graphics Card device
drivers

Devices

devices are colored; once attached to a color, they
can never be attached to any other color

Platform (incl. VMM,
host aspects)

What VMs can the platform host?

PCRs for TCB hash

Which set of
hypervisor calls
permitted

TPM (incl. vtpm)

Which colors can share a TPM?

General (TVD) policy

Isolation = flow control matrix, and resource
sharing in the time (e.g., vTPM attached to different
VMs at different points in time) or space domain
(e.g., two VMs sharing a NIC simultaneously). Zero
entry in matrix means no sharing in time or space.

TVD policies (e.g., proving that a
VM belongs to a particular TVD)

D
p

lic

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Secure Device Virtualization Services

U s e r

S e c u rity M a n a g e r

N e tw o rk S e c u rity

M a n a g e r

C o m p a rtm e n t

S e c u rity M a n a g e r

S to ra g e S e c u rity

M a n a g e r

T ru s te d

U s e r In terfa c e

C ryp to & T P M

S e rvic e s

Security Management Services

In te g rity

M a n a g e r

Hardware & VMM Core

S e c u rity P o lic y

M a n a g e r

Figure 3.3: System Architecture

overall system-wide security policies onto each of those individual aspects. We use
the Trusted Virtual Domain (TVD) model [14] to specify overall system-wide policies.
Table 3.1 summarises how TVD policies can be mapped onto various aspects of a
virtual infrastructure. Here, we assume that each TVD has a distinct colour, and use
the terms colour and TVD interchangeably.

3.2.1

Security System Architecture

We list the essential security services that we consider in the OpenTC project (Fig-
ure 3.3). The system is built upon the foundation of the hardware root of trust offered
by the TPM. The architecture leverages the recent advances in hardware virtualisation
such as virtualisation support in the CPU offered in the latest chips from Intel and
AMD. The hardware layer includes one of these chips and the TPM. Just above the
hardware layer is a trusted virtualisation layer (denoted by VMM core in Figure 3.3)
with strong isolation properties (among VMs) and well-defined interfaces to the TPM.
Above the VMM core are the security services.

The security services can be divided into two types: secure device virtualisa-

tion services and security management services. Secure device virtualisation pro-
vides security-enhanced virtualisation of devices. Examples include secure storage,
secure virtual network topologies [34], virtualised TPMs [10], or trusted user inter-
faces [68]. Security management services maintain a unified view on security guaran-
tees that cover multiple devices (e.g., data on a disk encrypted with a TPM key) and
the VMM core. The security management services are subdivided into compartment
security services, user security services, and integrity services. Compartment services
track individual VMs and their (local) security properties. User services maintain users
and their preferences. They also comprise a trusted user interface. Integrity services
maintain overall integrity guarantees so that, for example, a verifier can validate several
devices, its own user VM, and the integrity of the VMM core.

To enforce certain security guarantees on the VMM core, the security services con-

figure the VMM core using policies. An example of such policies is the sHype device
access control policies that can be loaded at boot time [81]. Above the security services
layer are VMs, each running its own guest operating system and applications.

3.2.2

Component-Level Design of the VMM Security Services
Layer

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

DiskImage

Partion

physDisk

svHDPlugin

chooseHD()
configureHD()
derigisterHD()

vHardDisk

ID
Size
encryption
key

getSize()
getEncryptionMode()
setKey()
decrypt()
attach()
detach()
deleteKey()
read()
write()

1
0..n

0..n

Disk

0..n

Measurement

measuredObject
result

MeasurementDescriptor

Owner
type

1..n

1 1..n

SealingDescriptor

sealingType
sealingValue
sealingOP

AttestationDescriptor

verifierKey
targetAIK
challange : Challange
attestType

AttestationResult

TPMAttestResult : TPMQuote
HypAttestResult : AttestationDescriptor
Signature : Signature

SecureVirtualDevicePlugin

getCapabilities()

SecureVirtualDeviceManager

registerPlugin()
getID()
configAndUnlockDisk()
getCapabilities()
deregisterDisk()

1..n

CompartmentManager

createVM()
getID()
hibernateVM()
migrateVM()
listVMs()
stopVM()
resumeVM()
attest()
initialize()
deriveAllowedAttestationPieces()

1 1

EnforcementResult

Key : Key

TPMAttestion

attestTPM()

TPMSealing

seal()
unseal()
sealCurr()

IntegrityServicesManager

registerPlugin()
getID()
enforcePolicy()
checkPolicy()
requestAttestation()

0..n

ConfigurationMeasurement

measureConfig()
measureStatus()

UserMeasurement

measureUser()

AttestationService

attest()

SealingService

seal()
unseal()
sealCurr()

StorageMeasurement

measureStorage()
measureFile()
opname()

MeasurementService

measure()

Figure 3.4: Component-Level Design of the VMM Security Services Layer

Overview

The VMM security services layer (Figure 3.3) provides functions such as compartment
security management, integrity services management, user security management, and
secure device virtualisation, that are needed to enforce the security policies. Here, we
provide an overview of these functions.

The Compartment Security Manager deals with the life-cycle management of com-

partments (i.e., VMs) and tracks the security policies and other context (such as in-
tegrity constraints, permissions, and global identifiers) associated with each compart-
ment. It can be used to prove selected security properties to peers. The User Security
Manager manages the users of the system and enables authentication of individual
users and their associated roles. The Integrity Services Manager (or Integrity Manager,
for short) maintains the integrity of the system. An important contribution to scala-
bility for trusted computing is the focus on security properties for trust management
[71, 78, 35]. Instead of verifying integrity by means of cryptographic checksums, we
use higher-level properties such as user roles, machine types, or trust domains to de-
termine trust. This is done by first using checksums to verify the core security services
and then use these security services to evaluate the desired security properties [71, 78].
Only if these properties are satisfied will certain actions such as unsealing a key or
performing a transaction with a peer be performed. The consequence is that a verifier
only needs to define security properties to be satisfied and no longer needs to track
individual software configurations that are deemed trustworthy. The Security Policy

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Manager deals with the creation, access management, and storage of local and global
policies for the VMs, virtual devices, and other security services.

Virtualised devices can include any device that can be made to support virtualisa-

tion. Secure storage provide virtual partitions with integrity and confidentiality. Virtual
networks can provide mutually isolated virtual network topologies and secure trans-
port [34]. The implementation of trusted user interfaces depends on the environment.
A simple solution that is sufficient for reliably selecting a compartment can be imple-
mented by a secure hot-key that is caught by a virtualised keyboard driver. Another
alternative is a multi-compartment graphical user interface that assigns a distinguish-
able window to each compartment. An third option are remote user interfaces such as
a secure shell management console or a remotely accessible management service (e.g.,

http://demo.tudos.org/nitpicker tutorial.html

If fast policy enforcement is critical for performance, then the enforcement of cer-

tain policies may be done at the virtualisation layers instead of at the security services
layer [81]. For example, a policy decision whether a certain network card can be as-
signed to a newly created VM can easily be done outside the Xen hypervisor as it is
usually not performance-critical. On the other hand, access decisions for shared re-
sources are performance-critical and may be executed in the VMM core.

Figure 3.4 shows the component-level design for the integrity management subsys-

tem of the security services layer. The subsystem implements the concepts introduced
in Section 3.4.2. Compared with Figure 3.3, it shows the design at the next level of
detail, depicting the individual components that make up the subsystem and the inter-
faces the components expose. We now describe these components. For secure virtual
device management, we focus on one type of device, namely secure virtual hard disks.

Compartment Manager

At the top level, there is the compartment security manager (or compartment man-
ager (CM), for short), which is the central instrumentation and orchestration point and
with which the user and the verifier directly interact. The CM, as the name indicates,
deals with anything related to compartments or VMs, including operations such as
creating, hibernating, migrating, stopping, and attesting VMs. It also has an interface

getCurrentState

()

for obtaining the current state of the entire environment (including

the list of active VMs, the list of users to whom the VMs belong, how much free mem-
ory is available, etc.). An example usage of this interface would be a state measurement
service invoking the interface for attestation purposes, i.e., for attesting the state of the
physical machine. Note that the

getCurrentState

()

function would not tell the state

measurement service whether the VMs are in good state, but would provide informa-
tion about how many and what types of VMs are currently present on the physical
machine, which VMs are running, which ones are hibernating, etc. Using such infor-
mation, the state measurement service itself would have to deduce whether the physical
machine is in an “acceptable” state. The CM also has a

getID

()

interface, which can be

invoked to obtain the unique identifier of the CM. Such a function would be useful, for
example, in a data centre environment in which multiple physical machines and, hence,
multiple CMs would have to be coordinated. The

readConfig

()

interface of the CM is

used internally when the CM is requested to create a new VM. The

attest

()

interface of

the CM offers a generic attestation call with an attestation descriptor (describing what
should be attested) as the parameter. The function is a proxy function as it merely calls
the

requestAttestation

()

function of the Integrity Services Manager (ISM), which is

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

described below.

The

createVM

()

function of the CM is invoked when a user wants a new VM

to be created. The VM configuration data, in the form of a config object or file, is
passed as parameter to the function. The combination of the User Security Manager
and the policies stored in the Security Policy Manager (shown in Figure 3.3, but not
in Figure 3.4) is used to check which VM-related functions the user is authorised to
request. For this purpose, the

checkUser

()

function of the user manager is invoked by

the configuration manager. The function takes a user name and some specified input
policy as parameters, and checks whether the user’s requested operation is compatible
with that policy. An example input policy may say that any user can create a VM, but
only users A and C can create a particular kind of VM (say, a VM of an automobile
company). To retrieve a certain policy from the Security Policy Manager, the CM calls

getPolicy

()

with a policy identifier as an argument.

Integrity Services Manager

The ISM is responsible for sealing, measurement, and attestation. These services
are implemented using multiple specialised low-level plugins. These plugins imple-
ment the extensibility concept outlined in Section 3.4.2. Distinct plugins are used
for various devices for separation of concerns and for easy extensibility. At system
startup time, any available plugin will register its capabilities with the ISM using the

registerPlugin

()

function.

There are two kinds of attestation: TPM-based attestation (implemented by the

TPMAttestation

component shown in Figure 3.4) and hypervisor-based attestation

(implemented by the

HypervisorAttestation

component; omitted in Figure 3.4). In

both cases, the signatures on the

AttestationResult

are made by the TPM. TPM-

attestation (sometimes called binary attestation) is the traditional form of attestation
specified by the TCG. It involves obtaining an incremental, cryptographic hash chain
based on the hashes of the binaries of the boot loaders, OS, and applications running
on the physical machine. The hash chain is stored in one of the PCRs of the TPM
chip. The verifier component at an external stake-holder can then remotely verify the
execution state of the platform either using a reference value or based on a policy (as
described above). Hypervisor-based attestation assumes that the hypervisor is part of
the TCB. The trustworthiness of the hypervisor can be checked by a remote party by
obtaining a signed TPM attestation also for the hypervisor. For hypervisor-based at-
testation, the attestation description is given to the hypervisor in text form through the

AttestationDescriptor

data object. The description specifies (in a considerably more

flexible manner than TPM-based attestation) what needs to be attested. The hyper-
visor then obtains those attestations. With respect to our model in Section 3.4.2, the

AttestationDescriptor

identifies the projection of the overall system data that shall be

attested. If the

HypervisorAttestation

is used, then property-based attestation can be

realised by implementing (in the

HypervisorAttestation

class) an attestation evalua-

tion function (such as the one described in Chapter 7) that translates the system state
into a statement of properties about the system.

The sealing services of the ISM is provided through the

SealingServices

plugin.

Just like attestation, there are two types of sealing: hardware-based sealing (or TPM-
based sealing) and hypervisor-based sealing. Note that to keep the figure readable,
only the former is depicted in in Figure 3.4. Both types of sealing can be used to make
a key available only if certain conditions are satisfied. However, of the two types of

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Realization Using Xen and Linux

Xen Hypervisor

Kernel

space

Dom0

DomU

TSS

/proc/xen/privcmd

/dev/sda

BMI

Compartment

Manager

Secure virtual

Device Manager

Library

space

Application

space

VBDF

VNDF

vTPMF

HDD

TPM

TPM Driver

/dev/tpm

Network

Sealing

Manager

vTPM

Manager

vTPMB

VBDB

dm-crypt

HDD Driver

/dev/sda

VNDB

bridge

HDD Driver

eth0

brctl

vTPM vHD

vNW

...

eth0

/dev/tpm

Security

Policy

Manager

Figure 3.5: Realisation using Xen and Linux

sealing, hypervisor-based sealing is considerably more flexible. The main limitation of
TPM-based sealing is that not much can be stored in the PCRs of the TPM. Only one
state may be specified for unsealing in TPM-based sealing, as opposed to saying “any
of these

states is acceptable” for unsealing. This is a serious limitation when attesting

different software that may be loaded in different sequences. In hypervisor-based seal-
ing, many acceptable states (i.e., reference values) for unsealing may be specified. The
reference values are stored in a

SealingValuesStorage

and the corresponding sealed

keys are stored in a

KeyStorage

. Reference values may also be provided as parameters

to functions such as

createVM

()

. Hypervisor-based sealing can also be used to ensure

that only the specified user can unseal the VM. As in hypervisor-based attestation,
hypervisor-based sealing assumes that the hypervisor is part of the TCB.

Secure Virtual Device Management

The Secure Virtual Device Manager (SVDM) is responsible for managing virtual de-
vices such as virtual HDDs, virtual block devices, virtual network devices, and virtual
TPMs. The service offered by the SVDM is realised through multiple specialised low-
level plugins, one for each virtual device. Figure 3.4 shows one such plugin, the secure
virtual hard disk plugin (

svHDPlugin

). We provide more information about this plugin

below in the context of a Xen- and Linux-based implementation.

Realisation using Xen and Linux

Figure 3.5 shows an example implementation of our security services design in Xen
using Linux for Dom0. The Xen hypervisor provides the physical devices to Dom0
(Xen’s management domain). In Xen terminology, a front-end virtual device is one

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

that is associated with a user domain and a back-end virtual device is present only in
Dom0. Every front-end virtual device has to be connected to a corresponding back-
end virtual device; only then does the front-end device become active. The mapping is
many-to-one, i.e., many front-end virtual devices, one from each user domain, may be
mapped to a single back-end virtual device.

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

such as configuring of the virtual devices would be done through the SVDM in the user
(or application) space. For example, a secure hard disk is implemented by means of the

dm-crypt

loopback device. Similarly, the network is virtualised by providing virtual

network cards for the guest partitions that can then be bridged to the actual network
card. Security for networks has two aspects. Topology constraints define which guest
is allowed to connect to which subnets. In addition, encryption requirements define
which connections need to be encrypted. Another virtualised device is a virtual TPM
that provides one virtual TPM instance to each of the guest partitions [10]. The virtual
device manager maintains the devices and their security properties. The integrity and
compartment are implemented in Dom0 and interface to the hypervisor as well as to
the other services implemented in Dom0.

Secure management of virtual devices is a complex task. For example, consider

the steps involved in starting a virtual hard-disk drive. First, a policy-based check
of the platform state is done. That 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 with a loop device (/dev/loop). The virtual hard-disk
may be encrypted, for example, with a sealed key that is made available only if the
platform is in a certain state. The decryption of the virtual hard-disk image is done
using the Linux hard-disk encryptor. After decryption, the device file that gives access
to the decrypted image is connected to the front-end. Similar policy-based checks may
be done when starting other virtual devices. For example, before starting a virtual
network device, policies may stipulate that the VM must be in some acceptable state
and outside firewalls must be configured correctly.

3.3

Secure Virtual Networking

Our focus in this section is security-enhanced network virtualisation, which (1) allows
groups of related VMs running on separate physical machines to be connected together
as though they were on their own separate network fabric, and (2) enforces cross-group
security requirements such as isolation, confidentiality, integrity, and information flow
control.

We describe a secure network virtualisation framework that helps realise the ab-

straction of Trusted Virtual Domains (TVDs) [14] by guaranteeing reliable isolation
and flow control between domain boundaries. The framework is based on existing
and well-established network virtualisation technologies such as Ethernet encapsula-
tion, VLAN tagging, and virtual private networks (VPNs). Our main contributions
are (1) combining these technologies to realise TVDs, which are security-enhanced
variants of virtualised network zones, and (2) orchestrating them through a manage-
ment framework that is oriented towards automation. In particular, our solution aims
at automatically instantiating and deploying the appropriate security mechanisms and
network virtualisation technologies based on an input security model, which specifies
the required level of isolation and permitted network flows.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

The related work for this section has been summarised in Section 2.3 on page 16.

3.3.1

Security Objectives and Policies

We describe the security objectives of network virtualisation using a security model
that enables the automatic enforcement of the objectives. The policies used in this
model are based on a security-enhanced variant of virtualised network zones called
Trusted Virtual Domains (TVDs) [14]. The policies define integrity, confidentiality,
isolation, and information flow control requirements.

Trusted Virtual Domains

A TVD is represented by a set of distributed virtual processing elements (VPE) (e.g.,
virtual machines) and a communication medium interconnecting the VPEs, and pro-
vides a policy and containment boundary around those VPEs. VPEs within each TVD
can usually communicate freely and securely with each other. At the same time, they
are sufficiently isolated from outside VPEs, including those belonging to other TVDs.
Here, isolation loosely refers to the requirement that a dishonest VPE in one TVD can-
not send messages to a dishonest VPE in another TVD, unless the inter-TVD policies
explicitly allow such an information flow.

Each TVD has an associated infrastructure whose purpose is to provide a unified

level of security to member VPEs, while restricting the interaction with VPEs outside
the TVD to pre-specified, well-defined means only. Unified security within a domain
is obtained by defining and enforcing membership requirements that the VPEs have
to satisfy before being admitted to the TVD and for retaining the membership. Each
TVD defines rules regarding in-bound and out-bound network traffic. Their purpose is
to restrict communication with the outside world.

Security within a TVD

Within a TVD, all VPEs can freely communicate with each other while observing
TVD-specific integrity and confidentiality requirements. For this purpose, intra-TVD
communication may take place only over an authenticated and encrypted channel (e.g.,
IPsec), or alternatively, a trusted network

. The trusted network alternative may be

reasonable in some situations, e.g., within a data centre.

TVD security requirements may have multiple facets: internal protection, member-

ship requirements, etc. Given a set

of trusted virtual domains, one way of formal-

ising internal protection is to define a domain-protection function

→

{

c,i,s

}

which describes the subset of security objectives (confidentiality, integrity protection,
and isolation) assigned to a particular TVD. Informally, integrity means that a VPE
cannot inject “bad” messages and pretend they are from another VPE. Confidentiality
refers to the requirement that two honest VPEs (in the same TVD or different TVDs)
can communicate with each other without an eavesdropper learning the content of the

A network is called trusted with respect to a TVD security objective if it is trusted to enforce the given

objective transparently. For example, a server-internal Ethernet can often be assumed to provide confiden-
tiality without any need for encryption.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

from/to

T V D

∗

αγ

T V D

∗

T V D

γα

γβ

* Implemented in our Xen-based prototype.

Figure 3.6: Example Flow Control Policy Matrix for Three TVDs.

communication. Lastly, isolation refers to the requirement that resources used by two
VPEs are logically separated and there is no unintended direct information flow.

Admission control and membership management are important aspects of TVDs.

A TVD should be able to restrict its membership to machines that satisfy a given set
of conditions. For example, a TVD may require certificates stating that the platform
will satisfy certain properties [78] before allowing the platform to join the TVD. One
way of formalising the membership requirements is to define a function

→

where

(

≤

)

is a lattice of security properties. A machine

with a set

of security

properties may be permitted to join the TVD

iff

∀

∈

(

) :

∃

′

∈

such that

′

≥

. In other words,

is permitted to join

iff there is at least one property of

that satisfies each security requirement of

Member VPEs may be required to prove their eligibility on a continual basis either

periodically or on-demand. For example, members may be required to possess cer-
tain credentials such as certificates or may be required to prove that they satisfy some
integrity properties (property-based attestation as introduced in Section 7.1). The con-
ditions may vary for different types of VPEs. For example, servers and workstations
may have different TVD membership requirements. Some VPEs may be part of more
than one TVDs, in which case they would have to satisfy the membership requirements
of all the TVDs they are part of. For a VPE to simultaneously be a member of multiple
TVDs, the individual TVD membership requirements must be conflict-free.

Security across TVDs

Inter-TVD security objectives are independently enforced by each of the individual
TVDs involved. To facilitate such independent enforcement, global security objectives
are decomposed into per-TVD security policies. The advantage of such a decentralised
enforcement approach is that each TVD is shielded from security failures in other
TVDs. Security objectives may take different forms; here, we focus on information
flow control among the TVDs.

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

flow control objectives. Figure 3.6 shows a sample matrix for three TVDs:

T V D

, and

T V D

. Each matrix element represents a policy specifying both permitted

inbound and outbound flows between a pair of TVDs, as enforced by one of the TVDs.
The

elements along the matrix diagonal convey the fact that there is free information

flow within each TVD. The

elements in the matrix are used to specify that there

should be no information flow between two TVDs, e.g., between

T V D

and

T V D

An information flow from one TVD to another will be overseen by both the sender

TVD and the recipient TVD. Information flow control from one TVD to another is
specified by two policies, with each TVD independently enforcing one. For exam-
ple,

αβ

, which represents the information flow policy from

T V D

, would

Addressing covert channels that utilise indirect information flow would exceed the scope of this report.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

consist of two sub-policies: (1)

αβ

, which would be enforced by the recipient TVD,

T V D

, and is concerned with the integrity protection of

T V D

, and (2)

out

αβ

, which

would be enforced by the recipient TVD,

T V D

, and is concerned with the confi-

dentiality protection of

T V D

. The distribution of policy enforcement to both TVDs

means that the recipient TVD does not have to rely solely on elements of the sender
TVD to enforce rules regarding its inbound traffic.

3.3.2

Secure Virtual Networks

In this section, we describe the aims of our secure network virtualisation framework
and introduce the networking components forming the framework. We then present
the composition of the components to form TVDs and to enforce TVD policies, and
describe the management of the TVD infrastructure. Here, we focus on the static be-
haviour of a secure network virtualisation framework that is already up and running.
Later, in Section 3.3.3, we focus on the more dynamic aspects of the framework, in-
cluding establishment and deployment of the secure virtual infrastructure.

Network Virtualisation Aims

The main aim of our network virtualisation extensions is to allow groups of related
VMs running on separate physical machines to be connected together as though they
were on their own separate network fabric. In particular, we would like to be able to
create arbitrary virtual network topologies independently of the particular underlying
physical network topology. For example, we would like groups of related VMs to be
connected directly together on the same virtual LAN segment even though, in real-
ity, they may be at opposite ends of a WAN link, separated by many physical LAN
segments. As another example, multiple segmented virtual networks may have to be
established on a single physical network segment to achieve improved security proper-
ties and protection.

Our network virtualisation extensions must also be inter-operable with existing

non-virtualised entities (e.g., standard client machines on the Internet) and allow our
virtual networks to connect to real networks.

Networking Components

One option for virtual networking is to virtualise at the IP level. However, to avoid
problems regarding the support for non-IP protocols and IP support services (such as
ARP) that sit directly on top of the Ethernet protocol, we have chosen to virtualise at
the Ethernet level.

Our secure network virtualisation framework allows multiple VMs belonging to

different TVDs to be hosted on a single physical machine. The framework obtains
isolation among various TVDs using a combination of virtual LANs (VLANs) and vir-
tual private networks (VPNs). There is one internal VLAN for each TVD; an external
VLAN may be used for communication with other TVDs and TVD-external entities.
In the absence of a trusted underlying physical network, each VLAN segment (i.e.,
an Ethernet broadcast domain, as in our case) may employ an optional VPN layer to
provide authentication, integrity, and confidentiality properties.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

The networking infrastructure consists of a mixture of virtual entities and physical

entities. Virtual entities include VMs, vSwitches, VLAN taggers, VPN, and gateways.
Physical entities include the physical hosts and the physical networking infrastruc-
ture, which includes VLAN-enabled physical switches, routers, and ordinary Ethernet
switches.

Virtual Ethernet cards or vNICs are the basic building blocks of our design. Each

VM can have one or more vNICs. Each vNIC can be associated with at most one
VLAN.

Each virtual LAN segment is represented by a virtual switch or vSwitch. A VM

appears on a particular VLAN if one of its vNICs is “plugged” into one of the switch
ports on the vSwitch forming that segment. The vSwitch behaves like a normal physical
switch. Ethernet broadcast traffic generated by a VM connected to the vSwitch is
passed to all VMs connected to that vSwitch. Like a real switch, the vSwitch also
builds up a forwarding table based on observed traffic so that non-broadcast Ethernet
traffic can be delivered in a point-to-point fashion to improve bandwidth efficiency.

The vSwitch is designed to operate in a distributed fashion. The VMM on each

physical machine hosting a VM connected to a particular VLAN segment hosts part
of the vSwitch forming that VLAN segment. A component of the VMM captures
the Ethernet frames coming out of a VM’s vNIC. The component is configured to
know which vSwitch the VM is supposed to be connected to. We describe the vSwitch
implementation in detail in Section 3.3.4.

The VM Ethernet frames are encapsulated in IP packets or tagged with VLAN

identifiers. The actual encapsulation is performed by an encapsulation module on re-
quest by the vSwitch. The vSwitch component then maps the Ethernet address of the
encapsulated Ethernet frame to an appropriate IP address. The mapping allows the en-
capsulated Ethernet frame to be transmitted over the underlying physical network to
physical machines hosting other VMs connected to the same physical LAN segment.
The result is the same as when all VMs on the VLAN segment are connected by a
real LAN. The IP address chosen to route the encapsulated Ethernet frames over the
underlying physical network depends on (1) whether the encapsulated Ethernet frame
is an Ethernet broadcast frame, and (2) whether the vSwitch has built up a table of the
locations of the physical machines hosting other VMs on that particular physical LAN
segment. The entries in such a table would be based on traffic observed on that physical
LAN segment.

IP packets encapsulating broadcast Ethernet frames are given a multicast IP address

and sent out over the physical network. Each VLAN segment has an IP multicast
address associated with it. All physical machines hosting VMs on a particular VLAN
segment are members of the multicast group for that VLAN segment. This ensures
that all VMs on a particular VLAN segment receive all broadcast Ethernet frames from
other VMs on that segment, whereas VMs on a different VLAN segment do not.

Encapsulated Ethernet frames that contain a directed Ethernet destination address

are either flooded to all the VMs on a particular LAN segment (using the IP multicast
address as in the broadcast case) or sent to a specific physical machine IP address. The
particular choice depends upon whether the vSwitch component on the encapsulating
VM has learned the location of the physical machine hosting the VM with the given
Ethernet destination address based on traffic observation through the vSwitch.

Encapsulating Ethernet frames from VMs within IP packets allows us to connect

different VMs to the same VLAN segment as long as the physical machines hosting
these VMs have some form of IP-based connectivity (e.g., a WAN link) between them.
There are no restrictions on the topology of the underlying physical network.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

vSwitches

VPN

VMs
& vNICs

EtherIP
encapsulation

VLAN-enabled
Physical Switch

TCP/IP

Host-3

Host-4

VLAN Tagging

Host-1

Host-2

Figure 3.7: Components of the Secure Virtual Networking Infrastructure

We employ VLAN tagging, an existing technology, as an alternative to Ethernet

encapsulation for efficiency purposes. Each VLAN segment may employ its own VLAN
tagger(s) to tag its Ethernet frames. The VLAN identifier, which is unique for each
VLAN within a virtual network, is used as tagging information. The tag is then used
by the VLAN switch to distinguish traffic flows from the various VLAN segments that
connect to the switch.

A VLAN-enabled physical switch (or a VLAN switch, for short) connects two or

more VLAN segments belonging to the same VLAN. VLAN switches should not to be
confused with vSwitches. VLAN switches are part of the physical networking infras-
tructure, whereas vSwitches are virtual entities. Each VLAN segment is connected to
a port on the VLAN switch. Multiple VLANs (i.e., VLAN segments belonging to dif-
ferent TVDs) may also connect to the same VLAN switch. The VLAN switch must be
appropriately configured to guarantee isolation among segments belonging to different
VLANs, while at the same time connecting physical machines, VMs, and vSwitches
on the same VLAN to each other.

Routing within Virtual Networks. Routing functionality within a virtual network

may be implemented by the use of a dedicated VM with multiple vNICs. The vNICs
are plugged into ports on the different vSwitches between which the VM has to provide
routing services. Standard routing software is then configured and run on the VM to
provide the desired routing services between the LAN segments connected.

Communication with Non-Virtualised Systems. Gateways enable communication

with systems that live in the non-virtualised world. The gateway is simply a VM with
two vNICs. One of the vNICs is plugged into a port on a vSwitch. The other vNIC is
bridged directly onto the physical network. The gateway has two main roles. Firstly, it
advertises routing information about the virtual network behind it so that hosts in the
non-virtualised world can locate the VMs residing on the virtual network. Secondly, the
gateway converts packets to and from the encapsulated format required by our virtual
networks.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

vSwitch

Fabric

vMachines

& vPorts

Blue Interconnect

Blue Internal

Figure 3.8: Internal- and Inter-connections for each TVD Type.

Composition of Secure Virtual Networks

Figure 3.7 shows how the networking components can be composed into a secure net-
working infrastructure that provides isolation among different TVDs, where each TVD
is represented by a different colour (blue, green, or red).

A non-virtualised physical host, such as Host-3, is directly connected to a VLAN-

enabled physical switch without employing a vSwitch. Further, a VM can be connected
to multiple VLAN segments using a different vNIC for each VLAN segment; hence,
the VM can be a member of multiple TVDs simultaneously. For example, the lone VM
in Host-2 of Figure 3.7 is part of two VLAN segments, each represented by a vSwitch
with a different colour; hence, the VM is a member of both the blue and green TVDs.

Abstractly speaking, it is as if our secure virtual networking framework provides

coloured networks (in which a different colour means a different TVD) with secu-
rity guarantees (such as confidentiality, integrity, and isolation) to higher layers of
the virtual infrastructure. Internally, the framework provides the security guaran-
tees through admission control and the appropriate composition and configuration of
VLANs, VPNs, gateways, routers, and other networking elements.

Ethernet frames originating from the source node are handled differently depending

on whether the source node is virtualised and whether the destination node resides in
the same LAN. We illustrate frame-processing alternatives for different scenarios in
Figure 3.7. For a virtualised domain (e.g., Host-1), each frame is tagged using the IEEE
802.1Q standard for VLAN tagging [40]. If the destination of the Ethernet frame is a
VM on another host that is connected to the same VLAN-capable switch (e.g., another
physical domain in a data centre), this tag indicates the VLAN segment to which the
VM belongs. If the destination is a host that resides outside the LAN domain (e.g.,
Host-4), the VLAN tag forces the switch to bridge the connection to an outgoing WAN
line (indicated by the black line in the VLAN-enabled physical switch of Figure 3.7)
that is connected to a router for further packet routing. In this case, the VM Ethernet
frames are encapsulated in IP packets to indicate the VLAN segment membership (e.g.,
using EtherIP [42] as in the Xen implementation in Section 3.3.4). Lastly, if a non-
virtualised physical host is directly connected to the VLAN switch (e.g., Host-3), no
tagging is required for the outgoing connection from the host’s domain. We provide
more details on each processing step in Section 3.3.4, where we describe our Xen-
based [8] prototype implementation.

Inter-TVD Management

Central to the management and auto-deployment of TVDs are entities called TVD mas-
ters. 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.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Inter-TVD management deals with the interchange fabric for communication be-

tween TVDs, enforcement of inter-TVD flow control policies, external zones (IP versus
Ethernet), approval of admission requests by TVD-external entities (such as a new VM)
to join the TVD, and linking such entities with the appropriate TVD master.

Information flow control between TVDs has two aspects: physical topology and

policies. Physically, each TVD is implemented by at least two VLANs (Figure 3.8):
an external VLAN and an internal VLAN. The external VLAN (shown in Figure 3.8
by thin lines) serves as a backbone to send/receive information to/from other TVDs. It
is through the external VLAN that a TVD proxy communicates with the TVD master
before becoming a member of the TVD. The internal VLAN (shown in Figure 3.8
by thick lines) connects machines that are part of a TVD. Inter-TVD policies specify
conditions under which VLANs belonging to different TVDs are allowed to exchange
information. The policies may be conveniently represented by information flow control
matrices, such as the one shown in Figure 3.6. For a given TVD, the policies are stored
at the TVD master, which then enforces them in a distributed fashion through admission
control and appropriate configuration of firewalls and TVD proxies.

Having separate VLANs for TVD-internal and TVD-external communication fa-

cilitates unrestricted communication within a TVD and the complete isolation of a
TVD from another TVD if the inter-TVD policy specified allows no information flow
between the TVDs. Such is the case for

T V D

and

T V D

, according to the flow

control matrix shown in Figure 3.6.

A cheaper alternative to the dual VLAN solution would be to rely solely on trusted

boundary elements such as firewalls to enforce isolation. The resulting assurance may
be somewhat lower than that of the dual VLAN solution, because of the possibility of
mis-configuring the boundary elements.

As shown in Figure 3.6, inter-TVD communication can be broadly classified into

three types: (1) controlled connections, represented by policy entries in the matrix,
(2) open or unrestricted connections, represented by

elements in the matrix, and (3)

closed connections, represented by

elements in the matrix.

Controlled connections restrict the flow between TVDs based on specified policies.

The policies are enforced at TVD boundaries (at both TVDs) by appropriately con-
figured firewalls (represented in Figure 3.8 by entities marked FW). The TVD master
may push pre-checked configurations (derived from TVD policies) into the firewalls
during the establishment of the TVD topology. If available, a management console at
the TVD master may be used to manually set up and/or alter the configurations of the
firewalls. A TVD firewall has multiple virtual network interface cards, one card for the
internal VLAN that the firewall protects and one additional card for each TVD that the
members of the protected TVD want to communicate with.

Open connection between two TVDs means that any two machines in either TVD

can communicate freely. In such a case, the firewalls at both TVDs would have virtual
network cards for the peer domain and simply serve as bridges between the domains.
For example, different zones in a given enterprise may form different TVDs, but may
communicate freely. As another example, two TVDs may have different member-
ship requirements, but may have an open connection between their elements. Open
connection between two domains may be implemented using an unlimited number of
virtual routers. In a physical machine that is hosting two VMs belonging to different
TVDs with an open connection, the corresponding vSwitches may be directly con-
nected. Communication between two TVDs, while open, may be subject to some con-
straints and monitoring. For example, a TVD master may permit the creation of only
a few virtual routers on certain high-assurance physical machines for information flow

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Security

Policy

Per-host

Extensions

Global

Configuration

TVD
Requirements

Mechanisms
Required

Deployment Planning
& Management

TVD Policy

Model

Capability

Model

Figure 3.9: Steps in Auto-Deployment of TVDs

between the TVD and another TVD with which the former has an open connection.

A closed connection between two TVDs can be seen as a special case of a controlled

connection in which the firewall does not have a virtual network card for the peer
TVD. In addition to the firewall filtering rules, the absence of the card will prevent any
communication with the peer TVD.

Intra-TVD Management

Intra-TVD management is concerned with TVD membership, communication within a
TVD, and the network fabric (i.e., internal topology) of a TVD.

Intra-TVD policies specify the membership requirements for each TVD, i.e., the

conditions under which a VM is allowed to join the TVD. At a physical machine host-
ing the VM, the requirements are enforced by the machine’s TVD proxy in collabo-
ration with networking elements (such as vSwitches) based on the policies given to
the TVD proxy by the TVD master. We describe TVD admission control in detail in
Section 3.3.3.

A VLAN can be part of at most one TVD. For completeness, each VLAN that

is not explicitly part of some TVD is assumed to be a member of a dummy TVD,

T V D

∆

. Although a VLAN that is part of

T V D

∆

may employ its own protection

mechanisms, the TVD itself does not enforce any flow control policy and has open
or unrestricted connections with other TVDs. Thus, in the information flow control
matrix representation, the entries for policies,

∆

and

∆

, would all be

for any

T V D

A VM that is connected to a particular VLAN segment automatically inherits the

segment’s TVD membership. The VM gets connected to the VLAN segment only after
the TVD proxy on the VM’s physical machine has checked whether the VM satisfies
the TVD membership requirements. Once it has become a member, the VM can ex-
change information freely with all other VMs in the same VLAN segment and TVD
(intra-TVD communication is typically open or unrestricted). As mentioned before, a
VM can be connected to more than one VLAN (and hence, be a member of more than
one TVD) through a separate vNIC for each VLAN.

A VM can become a TVD member either in an active or in a passive fashion. A VM

pen_TC Deliverable 05.1

CHAPTER 3. XEN 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 3.10: Steps in Populating a TVD

can be passively assigned a TVD membership at the time of its creation by specifying
in the VM’s start-up configuration files which VLAN(s) the VM should be connected
to. Alternatively, a VM can actively request TVD membership at a later stage through
the corresponding TVD proxy interface.

TVD membership requirements may be checked and enforced on a one-time or on

a continual basis. Membership can be a one-time operation in which the requirements
are checked once and for all, and thereafter, the VM holds the TVD membership for the
duration of its life-cycle. Alternatively, membership requirements can be re-evaluated
in an online fashion. The TVD proxy may regularly check whether a VM satisfies the
requirements. A session-based scheme may be employed in which a VM is allowed
open communication with other TVD members only until the next check (i.e., end of
the session).

3.3.3

Auto-deployment of TVDs

Figure 3.9 shows the steps involved in automatic deployment of secure virtual infras-
tructures as TVD configurations. Figure 3.10 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 section, 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
to the capabilities.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Property

Description

TVD Isolation

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 Policy

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

Virtual Machines

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

Hypervisor

Binary integrity of the hypervisor.

Users

The roles and associated users of a machine,
e.g., who can assume the role of administra-
tor of the TVD master.

Table 3.2: Examples of Security Properties used in Capability Modelling

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 3.2 lists some examples of security properties and Table 3.3 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 Fig-
ure 3.10) 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 3.10).

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-

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Past State

Description

Trust

A user believes that an entity has certain security prop-
erties.

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 systemsfor providing
evidence. Since the log cannot modified by the entity
itself, the resulting assurance is stronger than when mu-
table logs are used.

Present State

Description

Evaluations

Evaluation of a given state, e.g., Common Criteria eval-
uations [66].

Introspection

Introspection of a system by executing security tests,
e.g., virus scanner.

Future State

Description

Policies

By providing policies and evidence of their enforce-
ment, a system can justify claims about its future be-
haviour. E.g., DRM policies and VM life-cycle protec-
tion policy.

Audit

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

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

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
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 virtualisation 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 3.10, 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.

Alternatively, if the passive membership model is used, the command to join the TVD can be issued by

the VM manager component that instantiates the VM.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic 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 A

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 3.11: Prototype Implementation of TVDs

3.3.4

Implementation in Xen

In this section, we describe a Xen-based prototype implementation of our secure virtual
networking framework

. Figure 3.11 shows the implementation of two TVDs, TVD

and TVD

. The policy engine, also shown in the figure, implements the policies cor-

responding to the TVDs specified in the information flow control matrix of Figure 3.6,
i.e., open connection within each TVD and closed connection between

T V D

and

T V D

Our implementation is based on Xen-unstable 3.0.4, a VMM for the IA32 platform,

with the VMs running the Linux 2.6.18 operating system. Our networking extensions
are implemented as kernel modules in Dom0, which also acts as driver domain for the
physical NIC(s) of each physical host. A driver domain is special in the sense that it
has access to portions of the host’s physical hardware, such as a physical NIC.

The virtual network interface organisation of Xen splits a NIC driver into two parts:

a front-end driver and a back-end driver. A front-end driver is a special NIC driver that
resides within the kernel of the guest OS. It is responsible for allocating a network
device within the guest kernel (eth0 in Dom1 and Dom2 of Hosts A and B, shown in
Figure 3.11). The guest kernel layers its IP stack on top of that device as if it had
a real Ethernet device driver to talk to. The back-end portion of the network driver
resides within the kernel of a separate driver domain (Dom0 in our implementation)
and creates a network device within the driver domain for every front-end device in
a guest domain that gets created. Figure 3.11 shows two of these back-end devices,
vif1.0 and vif2.0, in each of the two hosts A and B. These back-end devices correspond
to the eth0 devices in Dom1 and Dom2, respectively, in each host.

Our preference of Xen is purely for practical purposes as both TVD and networking design are agnostic

to the underlying hypervisor.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Conceptually, the pair of front-end and back-end devices behaves as follows. Pack-

ets sent out by the network stack running on top of the front-end network device in the
guest domain appear as packets received by the back-end network device in the driver
domain. Similarly, packets sent out by the back-end network-device by the driver do-
main appear to the network stack running within a guest domain as packets received by
the front-end network device. In its standard configuration, Xen is configured to simply
bridge the driver domain back-end devices onto the real physical NIC. By this mech-
anism, packets generated by a guest domain find their way onto the physical network
and packets on the physical network can be received by the guest domain.

The Xen configuration file is used to specify the particular vSwitch and the partic-

ular port in the vSwitch to which a Xen back-end device is attached. We use additional
scripts to specify whether a particular vSwitch should use one or both of VLAN tagging
and encapsulation mechanisms for isolating separate virtual networks.

The vSwitches for

T V D

and

T V D

are each implemented in a distributed fash-

ion (i.e., spread across hosts A and B) by a kernel module in Dom0, which maintains a
table mapping virtual network devices to ports on a particular vSwitch. Essentially, the
kernel module implements EtherIP processing for packets coming out of and destined
for the VMs. Each virtual switch (and hence VLAN segment) has a number identi-
fier associated with it. The Ethernet packets sent by a VM are captured by the kernel
module implementing part of the vSwitch as they are received on the corresponding
back-end device in Dom0. The packets are encapsulated using EtherIP with the net-
work identifier field set to match the identifier of the vSwitch that the VM is supposed
to be plugged into. The EtherIP packet is given either a multicast or unicast IP address
and is simply fed into the Dom0 IP stack for routing onto the physical network. The
kernel module also receives EtherIP packets destined for the physical host. The mod-
ule un-encapsulates the Ethernet frames contained in the encapsulated EtherIP packets
and transmits the raw frame over the appropriate virtual network interface so that it is
received by the intended guest vNIC.

In addition to the kernel module for EtherIP processing, we have also implemented

a kernel module for VLAN tagging in Dom0 of each virtualised host. Ethernet pack-
ets sent by a VM are grabbed at the same point in the Dom0 network stack as in the
case of EtherIP processing. However, instead of wrapping the Ethernet packets in
an IP packet, the VLAN tagging module re-transmits the packets unmodified into a
pre-configured Linux VLAN device (eth0.

and eth0.

of hosts A and B, shown in

Figure 3.11) matching the VLAN that the VM’s vNIC is supposed to be connected to.
The VLAN device

(provided by the standard Linux kernel VLAN support) applies

the right VLAN tag to the packet before sending it out onto the physical wire through
the physical NIC. The VLAN tagging module also intercepts VLAN packets arriving
on the physical wire destined for a VM. The module uses the standard Linux VLAN
Ethernet packet handler provided by the 8021q.ko kernel module with a slight modifi-
cation: the handler removes the VLAN tags and, based on the tag, maps packets to the
appropriate vSwitch (

) which, in turn, maps them to the corresponding back-end

device (vif1.0 or vif2.0) in Dom0. The packets eventually arrive at the corresponding
front-end device (eth0 in Dom1 or Dom2) as plain Ethernet packets.

Below are some implementation issues we had to tackle in realising the VLAN and

encapsulation approaches.

An alternative approach, which we will implement in the future, is to directly tag the packet and send

the tagged packet straight out of the physical NIC without relying on the standard Linux VLAN devices.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

100

120

140

Packet Size (kB)

)

Bridged

VLAN

EtherIP

(a) Tx Throughput

100

120

140

Packet Size (kB)

)

Bridged

VLAN

EtherIP

(b) Rx Throughput

Figure 3.12: NetIO Benchmark: Guest VM to Guest VM Throughput

1. Some Ethernet cards offer VLAN tag filtering and tag removal/offload capabili-

ties. Such capabilities are useful when running just a single kernel on a physical
platform, in which case there is no need to maintain the tags for making propa-
gation decisions. However, for our virtual networking extensions, the hardware
device should not strip the tags from packets on reception over the physical wire;
instead, the kernel modules we have implemented should decide to which VM
the packets should be forwarded. For this purpose, we modified the Linux kernel
tg3.ko and forcedeth.ko network drivers so as to disable VLAN offloading.

2. For efficiency reasons, the Xen front-end and back-end driver implementations

avoid computing checksums between them for TCP/IP and UDP/IP packets. We
modified the Xen code to also handle our EtherIP-encapsulated IP packets in a
similar manner.

3. The EtherIP encapsulation approach relies on mapping a virtual Ethernet broad-

cast domain to a IP multicast domain. While this works in a LAN environ-
ment, we encountered problems when creating VLAN segments that span WAN-
separated physical machines. We resolved this issue by building uni-directional
multicast tunnels between successive LAN segments.

3.3.5

Performance Results

We now describe performance results for the prototype implementation of our secure
virtual networking framework. We obtained the throughput results using the NetIO
network benchmark (version 1.23-2.1) and latency results using the ping tool.

We used the NetIO network benchmark to measure the network throughput for

different packet sizes of the TCP protocol. We measured the Tx (outgoing) and Rx
(incoming) throughput for traffic from one guest VM to another guest VM on the same
physical host. For this purpose, we ran one instance of the benchmark on one guest
VM as a server process and another instance on the second guest VM to do the actual
benchmark.

Figure 3.12 compares the throughput results for the standard Xen-bridged config-

uration (explained in Section 3.3.4) with configurations that include our VLAN tag-
ging and EtherIP encapsulation extensions. The graphs show that the performance of

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

our virtual networking extensions is comparable to that of the standard Xen (bridge)
configuration. The VLAN tagging extension performs slightly better than the encap-
sulation extension for the Tx path, whereas the opposite happens in the case of the Rx
path.

The major cost in the Tx path for the EtherIP method is having to allocate a fresh

socket buffer (

skb

) and copy the original buffer data into the fresh

skb

. When first

allocating a

skb

, the Linux network stack allocates a fixed amount of headroom for

the expected headers that will be added to the packet as it goes down the stack. Unfor-
tunately, not enough space is allocated upfront to allow us to fit in the EtherIP header;
so, we have to copy the data around, which is very costly. However, there is some spare
headroom space, which is enough for the extra VLAN tag. As a result, the VLAN
tagging method does not suffer from the packet copying overhead. The cost of copying
data in the EtherIP case is greater than the cost of traversing two network devices (the
physical Ethernet device and the Linux-provided VLAN device) for the VLAN pack-
ets. That is why the VLAN method is more efficient than the EtherIP approach for the
Tx path. In a future version of our prototype, we will add a simple fix to the kernel to
ensure that the initial

skb

s have enough headroom upfront for the EtherIP header.

In the Rx path, there is no packet-copying overhead for the EtherIP approach; the

extra EtherIP header merely has to be removed before the packet is sent to a VM. In
the VLAN case, the packets have to traverse two network devices (as in the Tx path)
and the vSwitch kernel module. In the EtherIP case, the packets go straight from the
physical device to the vSwitch kernel module. As a result of the extra step of traversing
the VLAN device, the VLAN method performs slightly poorer than the EtherIP method
for the Rx path. Our next prototype will avoid using the Linux VLAN code and have
our vSwitch module do the tagging/untagging directly as in the EtherIP case. We expect
this enhancement to bring the Rx throughput of the VLAN approach on par with that
of the EtherIP approach.

Minimum

Average

Maximum

Mean
Deviation

Bridged

0.158

0.208

0.295

0.030

VLAN

0.171

0.233

0.577

0.049

EtherIP

0.174

0.239

0.583

0.052

Table 3.4: Round-trip Times using Ping

Table 3.4 shows the round-trip times between two guest VMs on a physical host

for the bridged, VLAN, and EtherIP encapsulation cases obtained using the

ping -c

100 host

command, i.e., 100 packets sent. The average round-trip times for VLAN

and EtherIP encapsulation are 12% and 14.9% higher than that of the standard Xen
bridged configuration.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

3.4

Integrity Management

3.4.1

Introduction

Integrity measurement, recording, and reporting are among the most important features
of a Trusted Platform Module (TPM). Through these features, the TPM enables a veri-
fier to check whether the platform hosting the TPM is in a trustworthy state. The TPM
also enables integrity protection by restricting the state under which the platform can
perform certain sensitive operations.

Recent works such as [31, 34, 81, 84, 10] combine Trusted Computing (TC) [96]

and hardware virtualisation concepts for improving security in a virtualised environ-
ment. Many of these works designate the virtualisation software and its configuration
files as part of the Trusted Computing Base (TCB), whose trustworthiness is verified
using TC concepts.

In this section, we expand TPM-based integrity protection and verification mecha-

nisms to cover virtual machines (VMs) and devices that can be governed by arbitrary
security policies. Examples include isolation policies for secure device virtualisation
or migration constraints for VMs. Our goal is to obtain a generic attestation and seal-
ing framework for VMs that is extensible and flexible. By extensibility, we mean that it
should be possible to provide integrity functions even if the VMs include arbitrary vir-
tual devices. Flexibility means that the verifier should be able to specify which aspects
of VM’s integrity and the underlying platform’s integrity it cares about, and obtain only
the corresponding information for platform validation.

We make the following contributions. First, we describe a formal model for pro-

tecting and verifying integrity of VMs in a generic fashion. Our model also addresses
how these integrity management operations can be made privacy-preserving. Second,
we describe the architecture and protocols for realising generalised integrity protection
and verification in practice.

3.4.2

Integrity Management for Virtual Machines

In today’s virtualised environments integrity management of VMs is an important chal-
lenge. Integrity management includes protection, measurement, reporting, and verifi-
cation of the integrity of VMs. In a traditional (non-virtualised) server environment,
users today are convinced that their servers are trustworthy by

•

running the servers themselves,

•

asking a provider to guarantee full control over the server (i.e., a root login, a
dedicated cage in a larger data centre, or a dedicated data centre),

•

asking a provider to provide log files and other evidence that allows the user to
heuristically validate critical installations, or

•

performing regular audits of the hosted servers.

While many of the above concepts used for managing the integrity of machines in non-
virtualised server environments will also be applicable for virtual servers, integrity
management in a virtualised environment is even more difficult because of the unique

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

security and privacy challenges that arise in such an environment. Users would like
to be convinced that virtual servers are as secure as physical servers. However, that
is non-trivial because the security of virtual servers depends not only on the server
configuration, but also on the security of the VMM and its services and on the ability
to guarantee an acceptable degree of non-interference and isolation among VMs. In
addition to being able to prove security to one user, an important privacy requirement
is a guarantee that this proof does not yield information about other users on the VMM.
In particular, when competing customers are co-hosted on the same physical hardware,
no “virtual cages” exist today that can guarantee their verifiable isolation. To provide
such guarantees, several aspects of the VMM need to be verifiable and protected:

•

The VMM software needs to be designed to satisfy the security requirements of
a customer.

•

The software running on the machine needs to correspond to a correct installation
of a given VMM.

•

The policies and configuration files used by the VMM should guarantee the se-
curity requirements of the customer. In addition, the policies should prevent
unauthorised modification of the software.

We now introduce concepts that show how to verify and protect the VMM installation
and policies. The first item listed above, dealing with the writing of correct software,
has been well-studied in the context of formal methods and would exceed the scope of
this section.

Virtual Machine Monitor Model

We now introduce an abstract notion of VMMs (shown in Figure 3.13) that we later
use for describing our security concepts for VMs. The VMM is configured by a policy

. At a given time

, a VMM has a state

and produces log data

that is computed by

a function

log

(

)

reflects the integrity of the VMM at time

. The state can often

be decomposed into a software state

and a data state

. As truthful reporting of

the state of a compromised VMM cannot be expected, log files and policies (that are
external to the VMM and cannot be modified by the VMM) are used for approximating
the actual security. Whereas the log file history yields an indication of past security,
security policies enable extrapolation of future security guarantees. The series of log
entries is collected by an independent audit system in an audit log

log

∗

. The software

provides installation integrity if

for some installation software

, where

= 0

indicates the installation time. Each user

has a set of security requirements that are

modelled by predicates. A software provides integrity if a user-defined predicate

Π(

)

is satisfied.

Generalised Sealing to Protect Integrity

Model: The concept of sealing can be used to make a data item

inaccessible if the

VMM state does not provide sufficient integrity. It can be modelled by two functions,

seal

and

unseal

. The

seal

function done at time

takes as input the data item

, a log

projection function

()

, a predicate

, and

, which is the public part of an encryption

key

. It produces an encrypted output

∈ {

}

∗

, which is encrypted with respect

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

VMM

Audit

System

log

policy

request

response

state

input

output

User

Hardware

History

log*

requirements

predicate

}

log(s

)

log(s

)

¦¦

Figure 3.13: Integrity Model for Virtual Machine Monitors

. The log projection function

()

takes the log

as input and outputs a subset of

. The

unseal

function done at time

takes as input

and the log

and outputs

iff

Π(

(

)) = 1

. A simple implementation of the predicate

would compare an input

(

)

, i.e.,

Π(

) :

(

)

Assuming the audit system is correct, one possible implementation of sealing and

unsealing is as follows. During

seal

()

(

()

, s

)

is obtained using the state

. On

unseal

()

, the audit system decrypts this message using its secret key

and outputs

the state

iff

Π(

(

))

The predicate

models the various criteria for assessing the trustworthiness of the

platform. This can be a simple predicate that compares configurations such as the input
startup config with a fixed configuration at hibernation time. More complex predicates
could evaluate certain properties such as whether only certified or well-known software
is being used [53, 71, 78].

Usage: An important application of the sealing function in integrity management

would be to make certain secrets inaccessible if the integrity of the platform is not
guaranteed. An example usage is to seal data to a software application. The usage
can be implemented by a projection

()

that derives the software state from the log

(assuming that the log file reliably reflects the software). If the software state at

the time of sealing is

(

)

and the software state at the time of unsealing is

′

(

)

, then the predicate

would be defined as

Π(

′

)

iff

′

. Another

example usage would be to seal a hard disk to a VMM. In this case, the software is the
VMM. The secret is a key that is used to decrypt the hard disk.

Special Case – Trusted Platform Module: The TPM implements the special case

in which log entries are restricted to storing hash values in a limited number of PCRs.
The log file projection

()

is defined as a subset of the PCR indices

{

, ..., n

}

. The

integrity predicate is defined as a desired PCR value for each register in this subset.

Generalised Attestation to Prove Integrity

Model: Attestation aims at convincing a user that the state of the machine is as ex-
pected. That is done by signing a projection of the log file

log

∗

. In our model, the log

file contains a list of all log entries. An attestation function

attest

obtains a challenge

, a function

()

(described below), a log file projection

()

, and a secret key

, and

outputs a signed message

Sign

(

log

∗

))

, c

)

Usage: Attestation can be used in two ways: Binary attestation signs a subset of

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

(i d; type; l og)

(i d

; type

; l og

)

(i d

; type

; l og

)

(i d

; type

; l og

)

(i d

; type

; l og

)

(i d

; type

; l og

)

(i d

; type

; l og

)

(i d

; t ype

; l og

)

(i d

; t ype

; l og

)

(i d

; type

; l og

)

(i d

; type

; l og

)

Figure 3.14: Trees of log entries

the log file. This means that the function

()

is the identity function, i.e.,

(

) =

. It

enables the user to obtain a signed subset of the log file and requires the user to locally
assess its trustworthiness. Property-based attestation [71, 78, 35] allows the user to
obtain only the results of function evaluations on the log file. For example, a user can
specify what software

, w

, ...

he or she deems acceptable and define the function

()

to assess from the log file whether any other software was executed. Similarly,

()

can

be used to extract certain policies or evaluate other conditions. Attestation can be used
to convince a user of the integrity of the machine

. It can also be used to validate the

integrity of machines when connecting to a network (cf. Cisco’s Network Admission
Control).

Special Case – Trusted Platform Module: For the TPM,

()

is the identity function

and

()

is specified by a subset of the PCRs. The attestation token is a signed message

containing the challenge and a subset of the PCRs.

Extensibility and Flexibility

The model we have described so far is too simplistic for the real-world. In practice, a
VMM consists of a large number of subsystems and components that depend on each
other. Examples include hardware components such as CPU and devices, software
components such as kernel, libraries, drivers, and user applications. To provide ex-
tensibility, new types of subsystems need to be added at run-time. Furthermore, it is
desirable that each subsystem be able to log and attest to arbitrary aspects of its be-
haviour. A disk, for example, should be able to selectively log its contents, its access
control list, or other aspects that need to be configurable by the policy.

It is clear that in reality, it is difficult to justify a single notion of a state or a single

logging function. A more flexible alternative is to represent the state by a tree of triples
(see Figure 3.14), one triple for each component. Each triple contains an identifier, a
component type

type

, and a vector of log values

log

. Subcomponents are modelled as

children of a node. The overall effect is that the log data is contained in a hierarchy
of vectors of log values. It can be extended by adding or removing children nodes.
Adding a device is, for example, reflected by adding a new type of child to the sub-tree
of the

type

device.

Note that while log files are represented by trees, we now have to define how to

apply attestation and sealing to these log trees. Sealing and attestation require a pro-
jection and a predicate. For a log trees, the projection function

()

is simply a subset

of the nodes of the tree, and for each of those nodes in the subset, a subset of the log
entries. The predicate

is then defined on

Note that this usually requires that the user have a independent computing device to perform this verifi-

cation. One example is a customer verifying a data centre.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Privacy Protection

The integrity of certain sub-states can be essential to multiple users. Conversely, sub-
states can be private to one or more users. For example, while the integrity of the
VMM core would be of interest to all users, the state of a particular VM should be
visible only to the user of that VM. To satisfy these privacy requirements, we have
to introduce blinding into our integrity architecture. In other words, it is important
that attestation and sealing can be done on projections of the state, i.e., subsets of
the state. Furthermore, if a state is relevant for integrity while containing information
about multiple users, it should be possible to prove integrity without revealing the ac-
tual state. For that purpose, it is necessary to have (1) a privacy requirement model
that defines visibility constraints or the requirements on the projection functions, (2)
privacy-preserving projections that satisfy those requirements, (3) a means of identify-
ing whether a projection is potentially privacy-invasive, and (4) a way of ensuring that
the predicate applied after a privacy-invasive projection can hide the private data

Given a set of users

and a log tree, a privacy requirement specification is a func-

tion

()

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 implemented 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.

A projection

()

applied by a user

∈

is privacy-protecting with respect to a

privacy requirements specification

()

iff the output only contains vector elements in

which

was contained in the access control list.

If the projection is privacy-preserving with respect to a privacy requirement speci-

fication

()

and a user

, then the sealing or attestation using this projection automat-

ically preserves privacy. This means that any evaluation function (for attestation) and
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, we require that the function and predicate

be mutually agreed upon. Examples of such agreed upon functions can be “software
certified by a given list of certifiers.”

3.4.3

Detailed Component Interactions

In this section, we describe two examples of how the components introduced in Sec-
tion 3.2.2 interact to achieve high-level security functionality. The interactions are
structured as use cases. We assume that the core trusted computing base (including
Xen and Dom0 Linux) has been measured at start-up time. Additional services may
need to be measured based on policy. The step numbers in the description below relate
to the steps shown in the interaction diagrams, Figures 3.15 and 3.16.

pen_TC Deliverable 05.1

CHAPTER 3. XEN SECURITY SERVICES

Ve rifie r

Compartme nt

M anage r

Compartme nt

M anage r

VM M Core

Inte grity Service s

M anage r

Inte grity Service s

M anage r

Attestation

Se rv ice

Attestation

Se rv ice

TPM

Atte station

TPM

Atte station

M easure ment

Se rv ice

M easure ment

Se rv ice

Configuration
M e asure me nt

TPM

1: atte st (AttestationDe scriptor, Use rCrede ntial)

23: Atte stationRe sult

3: re que stAtte station (Atte stationDe scriptor)

22: Atte stationResult

4: attest (Atte stationDescriptor)

5: me asure (M easure mentDe scriptor)

6: me asure Status (M easurement)

13: M easure me nt

14: M e asure me ntDescriptor

15: atte stTPM (Atte stationDescriptor)

16: TPM_e xtend(TPM _Me asure me nt)

17: Boolean

7: ge tCurrentXe nState ()

12: State Info

18: TPM_Quote (Challange , Ke y)

19: TPM Quote

20: Atte stationResult

21: AttestationRe sult

8: getInfo ( )

9: Hype rv isorEnvInfo

10: getListOfVM s ( )

11: String

2: derive AllowedAtte stationPie ce s ( )

Figure 3.15: TPM-based Attestation

TPM-based Attestation to the Current State of the Hypervisor

Figure 3.15 shows the component interactions for attesting the current state of the TCB
and the hypervisor status information (such as which VMs are running on the physical
machine, how much memory is available, etc.).

The verifier directly interacts only with the CM through the

attest

()

call pass-

ing an

AttestationDescriptor

and a

UserCredential

as parameter. The credential gets

verified and the CM checks whether the verifier is allowed to do the requested at-
testation (not shown in Figure 3.15).

AttestationDescriptor

is a data object that

describes what the verifier wants to have attested. Essentially, the object provides
the log file projection function

()

described in Section 3.4.2. It consists of one or

MeasurementDescriptors

, each of which describes what has to be measured.

The CM checks whether the verifier is allowed to access all the parts the verifier
wants to attested by calling the

deriveAllowedAttestationPieces

()

. If the check re-

veals 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 ISM (step 3), which forwards it to the

AttestationService

(step 4), which, in

turn, invokes the

MeasurementService

(step 5). The

MeasurementService

calls the

ConfigurationMeasurement

module (step 6), which retrieves the current state infor-

mation for the list of VMs by calling

getCurrentXenState

()

(step 7) of the CM.

The CM obtains this information from the VMM (steps 8–11) and passes it to the

ConfigurationMeasurement

component through the

Stateinfo

object (step 12). The

ConfigurationMeasurement

component measures the

Stateinfo

object and passes the

result in the

Measurement

object to the

MeasurementService

(step 13). Thereafter,

the

AttestationService

calls the

attestTPM

()

of the

TPMAttestation

component

(step 15) to complete the attestation process. The next steps are to write the mea-

Note that the result of any predicate applied after a privacy-preserving projection will always be privacy-

preserving.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Compartme nt

M anage r

Compartme nt

M anage r

Integrity

Se rv icesM anager

Integrity

Se rv icesM anager

Se aling

Se rv ice

Se aling

Se rv ice

TPM

Se aling

TPM

Se aling

M easure me nt

Se rv ice

M easure me nt

Se rv ice

Storage

M easure me nt

Storage

M easure me nt

v HardDisk

TPM

Se cure Virtual

De v ice M anager

Se cure Virtual

De v ice M anager

1: e nforce Policy (Policy)

2: unse al (SealingDe scriptor)

3: me asure (M easureme ntDescriptor)

4: measure Storage (M e asure me nt)

5: re ad ( )

6: Byte

7: M easure me nt

8: M e asureme ntDe scriptor

15: Key

9: unse al ( )

14: Ke y

12: TPM_unse al( )

13: Ke y

10: TPM _e xte nd(TPM _Me asure ment)

11: Boole an

16: Enforce me ntResult

17: configAndUnlockDisk (De v ice Config)

18: Boole an

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

surement hashes generated into a PCR by calling

TPM Extend

()

and to generate a

quote by calling

TPM Quote

()

. The

AttestationResult

consists of the quote and the

AttestationDescriptor

with the results of the different attestation targets. A verifier

can verify the integrity of the attestation result by recomputing a hash over the at-
testation targets specified in the

AttestationResult

and comparing the resulting hash

with the hash in the PCR from the quote. The PCR in which the

AttestationResult

stored gets reset after the attestation process has finished. Therefore, we need a TPM
that implements the TCG version 1.2 specification, and the PCR index for storing the

AttestationResult

hash has to be more than

Creation of a VM with TPM-based Sealing

Figure 3.16 shows how a VM with a sealed disk is (re)started. Suppose the policy
specifies that the virtual hard disk has to be measured to obtain the key for unsealing
the VM. Suppose further that the policy specifies that the TPM should reveal the key
only if the measurement value written into a specified PCR matches the value against
which the key was sealed.

To enforce the above policy, the CM calls the ISM interface

enforcePolicy

()

(step 1).

The

SealingService

, which gets called by the ISM, extracts the

MeasurementDescriptor

from the

SealingDescriptor

(step 2). Then, the

SealingService

calls the

MeasurementService

(step 3), which measures the virtual disk by call-

ing

measureStorage

()

(step 4).

After retrieving the measurements (steps 5–8),

the

SealingService

component invokes the

unseal

()

function of the

TPMSealing

component to unseal the key (step 9).

The

TPMSealing

component invokes the

(

TPM Extend

()

) function of the TPM (step 10) and if successful, tries to unseal the

key through the

TPM Unseal

()

function (step 12). For simplicity, Figure 3.16 does not

show details of key handling such as loading a sealing wrapper key into the TPM. If
the measurement matches, the

TPMSealing

component returns the key (steps 14–16).

The CM calls

configAndUnlockDisk

()

to attach and unlock the disk (step 17).

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

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

validate the configuration of the endpoint compartment. Finally, integrity of informa-
tion 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
components of the platform, e.g., kernel 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:

•

User Manager: The User Manager (UM) maps between real user names and
system-internal user identifiers. Moreover, it performs user authentication and
manages secrets attached to each user, e.g., to allow the Storage Manager to bind
data to a user. The programming interface offered by the User Manager hides
the concrete user model. Thus, it is possible to use a UNIX-like user model, or a
role-based model without modifications of other system components.

•

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 has access to the configuration of its clients, since it communi-
cates with them over trusted channels.

•

Compartment Manager: The Compartment Manager (CM) manages creation,
update, and deletion of compartments. It controls

which compartments are

allowed to be installed and enforces the mandatory security policy. During in-
stallation of compartments, it derives its configuration to be able to offer a map-
ping between temporary compartment identifiers

and persistent compartment

configurations.

•

Trust Manager: The Trust Manager (TM) offers functions that can be used by
application-level compartments to establish trusted channels between remote and
local compartments.

•

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.).

Since SM does not provide sharing of data between compartments, it does not realise a regular file

system.

A compartment identifier unambiguously identifies a compartment during runtime.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

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

essary security properties and concepts, i.e., privacy, trusted channels, secure storage,
and fresh storage.

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, [82, 84] 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 establish 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 trusted computing base, 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 4.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.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

curity properties like trusted channels and isolation between processes. Virtualisation
technology enables re-utilisation of legacy operating systems and present applications
whereas Trusted Computing technology serves as root of trust.

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 implemented layer in more detail.

TC-enabled Hardware Platform (cf. 2.1):

The hardware platform has to provide

additional components as defined by the TCG in various specifications (e.g., [102]).
The central component forms a low-cost tamper-resistant cryptographic chip, called
Trusted Platform Module (TPM). Currently, the TPM is implemented as a dedicated
hardware chip. It offers amongst others a cryptographic hash function (SHA-1), a
cryptographic engine (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. Protection mechanisms ensure that the value of a PCR can only be modified
in a predefined way

(see also Section 2.1). The TPM is primarily used

as a root

of trust for platform’s integrity measurement and reporting. During system startup,
a chain of trust is established by cryptographically 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 implementation uses a TPM in the present
version 1.2 [102] 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 hy-
pervisors like sHype and Xen [70, 83, 27]. 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 [69, 76, 79]. 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

PCR

←

Hash

(

PCR

)

, with the old register value

PCR

, the new register value

PCR

, and

the input

(e.g., a SHA-1 hash value). This process is called extending a PCR.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

the Storage Manager. Our implementation of the Trust Manager is based on the open-
source TCG Software Stack TrouSerS [100].

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
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 trusted computing base. 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 com-
ponent. For this purpose, we have modified the GRUB boot loader

to measure the

integrity of the core compartments, i.e., the virtualisation layer, all compartments in-
teracting 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, verified, 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.

4.2

High-Level Requirements Specification

In this section we present a formal analysis of requirements for the design of security
services. Subsequently components that allow to meet these requirements are shown.

4.2.1

Informal Requirements

This is a collection of informal requirements:

•

Mandatory Security Policies

– It should be able to enforce Bell-LaPadula.

– It should be able to enforce Chinese Wall.

•

Persistent Storage

However, covert channels are still feasible.

www.prosec.rub.de/trusted grub.html

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

– Function: Integrity of data.

– Function: Confidentiality of data.

– Function: Binding of data to property, e.g., platform, TCB, compartment.

– Policy: Preventing compartments from binding data.

– Policy: Forcing compartments to bind data.

– Policy: Applications should be able to bind data to itself.

– Policy: If the policy allows compartments to bind data to. itself, it should

be impossible to bypass this binding. Denial of Service (DoS) should be
impossible.

•

Attestation

– Function: A remote compartment should be able to attest a local compart-

ment including its TCB.

– Policy: Entities (the attested compartment, the Mandatory Access Control

MAC) should allow to restrict the attested properties of a compartment.

•

Trusted Channel

– Local and remote compartments should be able to open a secure channel to

a local compartment that is bound to properties of that compartment.

4.2.2

Security Environment

Assumptions

/A 10/

Trusted Administrator

The security administrator of the system is non-malicious.

/A 20/

Correct hardware

The underlying hardware (e.g., CPU, devices, TPM, ...) does not contain back doors,
is non-malicious, and behaves as specified.

/A 30/

No Physical attacks

Physical attacks against the underlying hardware platform do not happen.

/A 40/

Attestation

The platform provides a mechanism that allows the Security Kernel to convince remote
parties about its trustworthiness.

Example mechanisms are to perform an attestation protocol based on an environ-

ment providing authenticated boot. Another example would be a tamper-resistant hard-
ware environment that can uniquely by identified as such be a remote party, e.g., based
on a signature key stored inside.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

/A 50/

Security Kernel Binding

The IT-environment offers a mechanism that allows the Security Kernel to store in-
formation such that it cannot be accessed by another Security Kernel configuration.
Example mechanisms are the sealing function offered by a TPM as specified by the
TCG in combination with an authenticated bootstrap architecture, or a tamper-resistant
storage in combination with a secure bootstrap architecture.

/A 60/

No man-in-the-middle attack

An attack that relays the whole communication between a local user and the I/O devices
to another device does not happen.

Threats

In the following section we present threats that exist related to our approach and todays
computer systems in general.

/T 10/

Security Kernel Replacement

An adversary may try to violate security policies by replacing the TOE by another
system under full control of the adversary.

/T 20/

Security Kernel Integrity Violation

An adversary may try to violate security policies by violating the TOE’s integrity such
that security policies can be bypassed.

/T 30/

Malicious Device Drivers

An adversary may try to violate security policies by (directly or indirectly) installing
a device driver that uses hardware functions (e.g., direct memory access) to violate
security policies.

/T 40/

Virtualisation

An adversary may try to access sensitive information by running the Security Kernel
on top of a Virtual Machine Monitor that is under control of the adversary.

/T 50/

Trojan Horse

An adversary may try to get access to sensitive information by deceiving

Administrators

Users

(see Section 4.2.3) such that a compartment under control

of the adversary claims to be a(nother) trusted compartment.

/T 60/

Unauthorised User

An unauthorised user may use a compartment to read or modify information owned by
another user.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Use Cases

Other use cases can be found in Appendix A.3

ASE

NIQUE

/ UC 10 /

ITLE

Initialisation

ESCRIPTION

An unauthenticated subjects starts the Security
Kernel.

CTORS

Anonymous

RECONDITIONS

The Security Kernel is correctly installed.

OSTCONDITIONS

Anonymous

ORMAL

LOW

Anonymous

activates the Security Ker-

nel.

2. The Security Kernel (resp. its compo-

nents) are started and initialised.

3. A

Compartment

, e.g., a

LegacyOS

, is

started and initialised.

Anonymous

has access to a compart-

ment.

LTERNATIVE

LOW

UTHENTICATED

CCESS

)

Anonymous

activates the Security Ker-

nel.

2. The Security Kernel (resp. its compo-

nents) are started and initialised.

Anonymous

performs an authentication

process (and thus becomes

User

has access to a compartment.

The bootstrap process starts an initial process (the ”root task“) that starts and ini-

tialises the Security Kernel as well as the first compartment. The input of the root task
is measured by the boot process.

In the first case, the first compartment can be a Legacy OS. We have to ensure that

the compartment is started only if the TOE is initialised properly.

In the second case, the first compartment can be the authentication component. The

Legacy OS can be bootstrapped before or after the authentication process takes place.
Security Kernel components that have to be measured by the boot process are:

•

compartment management (to be able to start other compartments)

•

property management (to perform measurements of other compartments)

•

the TPM driver (to securely store the measurements. Else, a malicious TPM
driver could write wrong values about its own configuration). But only for au-
thenticated boot, not for secure boot.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

•

a data source (file system, network) to load the other compartments to be loaded.

•

all components required to execute and initialise the components

All other Security Kernel components and compartments can be started and measured
by the compartment manager itself.

4.2.4

Security Objectives

Security Objectives for the IT-Environment

/OE 10/

Security Kernel Identity Prove

The IT-environment provides a mechanism that allows the Security Kernel to convince
remote parties and local users about its identity. Common examples of such a mech-
anism are a unique signature key protected by a tamper-resistant device, or a TPM
securely mounted to the platform.

/OE 20/

Security Kernel Integrity Prove

The IT-environment provides a mechanism that allows the Security Kernel to convince
remote parties and local users about its integrity. An example of such a mechanisms is
the authenticated bootstrap architecture as specified by the TCG [102].

/OE 30/

Backup

The IT-environment ensures that the information stored by the Security Kernel is
backed up in regular intervals.

Security Objectives for the Security Kernel

/O 10/

Security Kernel Identity

Using functionalities offered by the IT-Environment, the Security Kernel should be
able to prove its identity to both remote parties and local users.

/O 20/

Security Kernel Integrity

Using the functionalities offered by the IT-Environment, the Security Kernel should be
able to convince remote parties and local users that the integrity of the Security Kernel
is not violated.

Changes in the Security Kernel must be detectable by both the user and remote

parties. Such changes can drastically affect the security properties of the system, and
therefore mechanisms must be put in place to prevent entrusting sensitive data to such
a compromised system.

/O 30/

Strong Isolation

The Security Kernel should strongly isolate compartments from each other. The isola-
tion has to be enforced on the address-space level and on the data level.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

/O 40/

Admin Authentication

The Security Kernel should always identify and authenticate administrators before
granting access to management functions of the Security Kernel.

/O 50/

User Authentication

Depending on the underlying security policy, the Security Kernel should be able to
identify and authenticate users before granting access to compartments.

/O 60/

Trusted Channel Between Compartments

The Security Kernel should provide a trusted communication channel between com-
partments, i.e., a channel providing integrity, confidentiality, and authenticity of the
compartment’s configuration.

/O 70/

Trusted Path to Users

The Security Kernel should provide a trusted communication channel, i.e., a channel
providing integrity, confidentiality, and authenticity of the compartment’s configura-
tion, between compartments and local users.

Moreover, the Security Kernel should

provide a trusted communication channel between itself and local users.

/O 80/

Secure Persistent Storage

The Security Kernel should provide data containers to persistently store information
providing (at least) the following list of security properties:

•

Integrity: Allow the compartment to detect an integrity violation.

•

Confidentiality:

– Security Kernel: Allow a compartment to bind information to the Security

Kernel.

–

Compartment

: Allow a compartment to bind information to a compart-

ment configuration.

– Role: Allow a compartment to bind information to a specific user role.

Freshness: Allow compartments to store information such that a replay attack
can be detected.

/O 90/

Data Availability after Security Kernel Update

The Security Kernel should ensure the availability of user data not bound to a specific
Security Kernel version after a Security Kernel update providing the same security
properties.

/O 100/

Data Availability after Compartment Update

The Security Kernel should ensure the availability of user data not bound to a specific
compartment version after a compartment update providing the same security proper-
ties.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

/O 110/

Data Availability after Security Kernel migration

The Security Kernel should ensure the availability of user data not bound to a specific
Security Kernel version after a migration to another Security Kernel providing the same
security properties.

/O 120/

Data Availability after IT-environment migration

The Security Kernel should ensure the availability of user data not bound to a spe-
cific IT- Environment after a migration to another IT-Environment providing the same
security properties.

•

an update of the Security Kernel,

•

an update of a

Compartment

•

a migration to another Security Kernel,

•

a migration to another IT-environment

4.2.5

Security Requirements

/SR 10/

Integrity of the TCB

The TCB should be protected from

manipulations to guarantee the enforcement of

security policies. No modification of the TCB must be allowed, except for changes
that have been authorised by the

Administrator

/SR 20/

Confidentiality and Integrity of Application Data

Application data should remain confidential and integer during execution and storage.

/SR 30/

Trusted Path to User

The inputs/outputs of the application a user interacts with should be protected from
unauthorised access by other applications.

/SR 40/

Trusted Channel between Trusted Compartment and External Parties

Trusted channels must be provided to allow remote parties to interact with the Security
Kernel system while being assured of its well-behaviour and its willingness to conform
to their security policy.

/SR 50/

Information Flow

Information flow should only be possible where allowed by the security policy

. Pri-

marily, eavesdropping on another, non-cooperating compartment must be foiled.

Covered channels may still exist, but due diligence must be taken to minimise their impact.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

4.2.6

Supplementary Requirements

Preconditions

/PR 10/

L4-based resource management layer

L4 must offer a method of achieving access control for L4 IPC calls between different
L4 tasks (which constitute compartments).

/PR 20/

Trusted boot loader

A boot loader with TPM-support is required.

/PR 30/

TPM Interface Specification Driver

A TIS-Driver is required to use TPMs of version 1.2.

Required Criteria

In this section we present required criteria to realise supplementary requirements.

/MR 10/

L4 Support

The realisation of the use cases should be deployable on an L4-based architecture.

/MR 20/

Common Management Layer

Both the L4-based architecture and the Xen-based architecture should offer the same
interface to the legacy OS (Linux).

/MR 30/

Single-user Support

The security architecture should support at least one user.

/MR 40/

Trusted Compartment

The product should support one untrusted and one trusted compartment at least.

/MR 50/

TPM Support

The Security Kernel should support a TPM of version 1.2 (or higher) to protect the
Security Kernel integrity.

/MR 60/

Virtualisation

The product should not prevent a virtualisation of the security kernel or executed com-
partments technically. However, attacks using virtualisation attempting to compromise
system integrity have to be considered.

Desired Criteria

/DR 10/

Multi-User Support

The Security Kernel should be able to handle multiple users.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

4.3

High-Level Software Architecture Specification

4.3.1

Security Model

Currently, we assume sHype as the underlying security model. sHype is a security
model that is able to enforce different Mandatory Access Control policies like Bell
La-Padula or Chinese Wall. It uses an sHype security service to enforce these policies
based on a virtualisation layer. So compartments running on the virtualisation layer
are able to communicate with or access other compartments as it is specified in a se-
curity policy. Therefore, a list of security labels (colours) is assigned to every object
and every subject and e.g. components marked with the same colour are allowed to
communicate.

Users

A list of security labels is assigned to every user. So far, we identified the following
user roles:

•

Owner: The entity that owns the platform running the Security Kernel. The
owner can be a private person, or a company.

•

User: A local entity that is authorised to use the Security Kernel in certain ways.

•

Client: A remote entity that uses the Security Kernel in certain ways.

Subjects

So far, we identified the following types of subjects: A compartment running on top
of the Security Kernel. More concretely, a set of threads that share a set of address
spaces. Security attributes of subjects are:

•

Explicitly: A session object defining the user/roles attached to that subject.

•

Explicitly: A list of subject roles defining the subject’s capabilities.

•

Explicitly: A list of resources.

•

Implicitly: A list of security labels.

Subject Roles

Subject Roles define the required capabilities of a subject to perform

a certain task. Examples of such roles are:

•

Application: Needs read access to naming service.

•

Service: Needs write access to naming service.

•

Video Driver: Needs access to a PCI/AGP device and physical memory of a
specific range.

•

Browser: Application that needs access to a network and storage.

•

Mailer: Application that need access to network, address book, and storage.

•

GUI: Service that needs access to video driver and input driver.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Mandatory Access Control (MAC):

On the level of the Mandatory Access Con-

trol, the Security Kernel only knows about domains and

operations between them.

Domains are logical groups of objects and subjects, while the possible operations are
read() and write(). The . Mandatory Access Control security policy mainly defines
information flows (none, read-only, write-only, and read-write) between domains. The
main security objective of the Security Kernel is to enforce this information flow secu-
rity policy.

In addition to the information flow policy between domains, certain properties of

domains can be defined by the administrator. Until now, the following properties have
been identified:

•

Storage: enforce/prevent/allow one of the following security properties - In-
tegrity, freshness, domain-binding, user-binding

•

Network: VPN Key

•

Capabilities: List of actions allowed to other domains

•

Compartments: Required properties of compartments (i.e., applications)

Currently, we assume that only one domain is assigned to an object.

Discretionary Access Control (DAC):

In contrast to the mandatory access control

policy described above that is defined by the administrator, the discretionary access
control policy is defined by the owner of each object.

Subjects, Objects, and their Attributes:

We identified the following objects and

their attributes:

•

Owner: Property, Role

•

Object: Domain, Owner

•

Process: Domain, Role, Property

•

Secure Container: Domain, Owner

•

Virtual Network: Domain, Owner

We identified the following subjects and their attributes:

•

User/Roles: Domain

•

Processes: see above

4.3.2

Logical View

Overview

Legacy operating systems and security-critical applications are executed on top of
the Security Kernel security architecture including the underlying hardware (see Fig-
ure 4.3).

Within the Security Kernel security kernel package, we identify the following sig-

nificant sub-packages:

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Figure 4.4: Significant design packages and their dependencies.

-value

-myID

«datatype»

CompID

«datatype»

ByteString

CompartmentManager

+ start(comp : ByteString) : CompID
+ load(lib : ByteString)
+ kill(comp : CompID)

Compartment

- myID : CompartmentManagement::CompID
+ Compartment()

-name

«datatype»

String

Property

- name : String
- value : ByteString

«service»

PropertyManager

+ getProperties(comp : CompartmentManagement::::Compartment) : List<Property>
+ getCompartments(props : List<Property>) : List<CompID>

Figure 4.5: Package

Compartment Management

shared libraries. Internally, the CM ‘measures’ compartment properties before execut-
ing them according to a defined policy. A common example of measuring would be to
hash the image of the new compartment. Another responsibility of the CM is to restrict
the compartments to be started and to derive their capabilities.

The responsibility of the PP component is to offer the measurement results to other

compartments. According to a given security policy, compartments can query prop-
erties of other compartments to determine the trustworthiness of these compartments.
The PP also includes the functionality of a naming service, i.e., it provides a mapping
between service interfaces and compartment identifiers.

Secure User Interface

The package

Secure User Interface

provides access to

the I/O interfaces used by the local user, i.e., output devices like the video card and
input devices like keyboard and mouse. Figure 4.6 illustrates the design model of the

Secure User Interface

package.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

UserInterface

- inputs : InputDevice
- outputs : OutputDevice
+ refresh(region : Region)
+ notify(msg : String)
+ close()

OutputDevice

-inputs

-outputs

UserInterfaceManager

+ open() : UserInterface

InputDevice

Figure 4.6: Package

Secure User Interface

User Manager

+ manageSubjects()
+ selectSubjects()
+ selectSubject() : Subject
+ authenticateSubject(subject : Subject) : SubjectSecret

SubjectSecret

Subject

- myID : SubjectID

Figure 4.7: Package

User Management

The package

User Management

provides functions to create,

delete, select, and authenticate subjects, which are platform-global entities. Despite its
name, such a subject needs not be a user in the classical sense, but could also be a
role, group, or other principal.

Figure 4.7 illustrates the design model of the

User

Management

package.

The general idea behind this design is that the class

UserManager

completely

hides the concrete implementation of the user model, e.g., role-based, users/groups as
in many Unix’s, or smart-card-based. Since the internals are hidden, the class

User-

Manager

has to provide its own management interface invoked by

manageRoles()

Even the authentication of subjects is performed by the class

UserManager

itself. To

allow other compartments to bind data to subjects, UM returns an authentication secret

SubjectSecret

on successfull authentication.

Trusted Network

The package

Trusted Network

offers compartments the func-

tionality to access virtual and physical networks connected to the Security Kernel.
From the compartment’s perspective, access a physical network cannot be distin-
guished from a virtual private network. Both are ”seen“ as separated network inter-
faces. Figure 4.8 illustrates the design model of the

Trusted Network

package.

Package

Integrity Management

The package

Integrity Management

offers com-

partments the functionality (i) to attest properties and (ii) to create trusted channels,
i.e., secure channels to remote entities that are bound to certain compartment proper-
ties. Figure 4.9 illustrates the design model of the

Integrity Management

package.

Trusted Storage

This package features secure and trusted persistent storage that is

used to enforce a variety of security properties. Figure 4.10 illustrates the design model
of the

Trusted Storage

package.

Currently, the following security properties are defined:

•

Integrity: Integrity protection enforces checking content for alteration.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

Figure 4.11: Package

Virtual TPM

– Basic Integrity Checking: Basic integrity checking verifies that content was

not maliciously altered by another party, but allows replays of earlier states,
e.g., to allow backups.

– Freshness: Protects integrity, but additionally prevents restoring of earlier

states.

•

Confidentiality: To protect the confidentiality of information, data can be bound
to the following architectural abstractions:

– Compartment Binding: Ensure that only compartments with an identical

configuration can access the information.

– Subject Binding: Ensure that information can only be accessed if the ap-

propriate subject has been authenticated.

– TCB Binding: Ensure that information can only be accessed by a TCB with

an identical configuration.

Each stored item can be protected by any combination of the binding options, while

compartment binding implies TCB binding, and freshness implies integrity.

Virtual TPM

This package offers compartments a virtual TPM instance. Such a

virtual TPM is unaffected by any change made to another virtual TPM, and offers the
functionality defined by the TPM specification of the TCG. Figure 4.11 illustrates the
design model of the

Virtual TPM

package.

Use-Case Realisations

The corresponding use-cases were described in section 4.2.3 and Appendix A.3.

/ UC 10 / Initialisation

A user activates the Security Kernel. It executes a secure boot sequence in order to
establish a chain of trust from some trusted instance (e.g., a hardware TPM).

/ UC 30 / Start Compartment

A client that intents to start a new compartment invokes the

Compartment Manage-

ment Service

and provides it with the image and configuration parameters to be used

for the compartment. The

Compartment Management Service

loads and measures

the image and the configuration parameters (the image being instantiated according
to the given parameters). The measurements taken are stored using the

Configuration

Provider

. As the end result of the start compartment invocation, the

Compartment

The measurements can be retrieved from the

Configuration Provider

at a later time by, e.g., a

Compartment

for attestation purposes.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Management Service

passes the

CompartmentID

of the created compartment to

the client. A

CompartmentID

is generated in a way that prevents collisions with pre-

viously generated IDs (even if the corresponding compartments no longer exist).

/ UC 40 / Start Legacy Operating System

In this special case of / UC 30 /, the compartment to be started is a legacy operating sys-
tem, the configuration parameters of which may include the file system images utilised
by the legacy OS.
As in / UC 30 /, the client that intends to start the new compartment invokes the

Com-

partment Management Service

, this time providing it with the image and config-

uration parameters of the legacy OS, e.g., Linux. The

Compartment Management

Service

loads and measures the Linux kernel including its configuration (i.e., com-

mand line) parameters. After that, the Linux kernel is responsible for the continuation
of the layered secure boot process – for example, by measuring a file system that it
intends to mount.

/ UC 50 / Stop Compartment

A client that intents to stop a compartment invokes the

Compartment Management

Service

and provides it with the

CompartmentID

of the compartment to be stopped.

The

Compartment Management Service

stops the compartment and releases the

resources associated to it. This includes the measurement values stored by the

Config-

uration Provider

. After that, the

Compartment Management Service

informs the

Client

about the result of the operation.

/ UC 70 / Store Data

Store (and load) require a component which handles providing trusted non-volatile
storage. The store use case is realised with the help of several other components. De-
pending on the protection options selected, different processing needs to be carried out.
If content is supposed to be bound to a compartment configuration, the

Configuration

Provider

is queried for that configuration of the storing compartment. This informa-

tion is stored in metadata, which is held confidential and freshness-protected. For this
option, as well as TCB binding, the data is transformed using an internal key of the

Transformer

User binding is done similarly, however, encryption and decryption keys are han-

dled by the

User Management Service

, which is queried for an encryption key for

the specified user. Role hierarchies and other “special semantics” need to be imple-
mented in the

User Management Service

Simple integrity checking is achieved by attaching an unforgeable signature to

the data object, while freshness can be realised by maintaining said signature in the
freshness-protected metadata.

/ UC 80 / Load Data

Loading data is realised very similarly to / UC 70 /. The storage component needs
to access its metadata to determine what protection options where specified for the
requested piece of data, and if it is even known. If a piece of data is unknown, this
results in an error.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

If the data is indeed known, it is retrieved from

Non-Volatile Storage

, and its

integrity is verified if so demanded by the metadata. Any encryptions are removed
in reverse order (depending on the order of encryption which is utilised in / UC 70 /),
making interactions with the same components as in / UC 70 / necessary. The

Storage

Service

will decrypt data encrypted in such a way if and only if the configuration

recorded in metadata matches the current configuration of the loading compartment.

/ UC 240 / Local Trusted Channel

Client

requests a trusted channel to a

Compartment

from the

Trusted-

ChannelEstablisher

The

TrustedChannelEstablisher

invokes the

Configura-

tionProvider

to obtain a

Configuration

of the

Compartment

, and provides it to the

Client

. It also opens a secure channel from the

Client

to the

Compartment

; the

Client

can then use the

Configuration

to decide if the channel is trusted.

To enforce least privilege,

TrustedChannelEstablisher

maintains a policy about

which compartment may receive the configuration of another compartment in order
to avoid unauthorised compartments from obtaining configurations of other compart-
ments.

/ UC 240 / Remote Trusted Channel

RemoteClient

requests a trusted channel to a

Compartment

from the

Trust-

edChannelEstablisher

The

TrustedChannelEstablisher

queries the

Compart-

mentManagementService

for the

Configuration

of the requested destination

Compartment

and generates an asymmetric key pair (

PublicKey

PrivateKey

) and

Certificate

on the generated key. The certificate states that the keypair has been gen-

erated for a

Compartment

which – at the time of the request – possessed the stated

Configuration

. Both

Certificate

and

PublicKey

are sent to

RemoteClient

which ver-

ifies the signature and verifies that

Configuration

conforms to its policy. A successful

validation implies that

PrivateKey

is “bound” to

Configuration

, and that data en-

crypted with

PublicKey

is therefore “bound” to

Compartment

. Thus, an encrypted

communication channel can be established using

PublicKey

, which guarantees con-

fidentiality, integrity, and (if communication is successful) the correct configuration
(otherwise, decryption would fail).

/ UC 290 / Remote Trusted Channel via Proxy

A trusted channel between

RemoteClient

and

Compartment

using

Proxy

is realised

by establishing a trusted channel between

RemoteClient

and

Proxy

(see / UC 240 /)

and a local trusted channel between

Proxy

and

Compartment

(see / UC 240 /). The

Proxy

then transmits the

Configuration

Compartment

to the

RemoteClient

/ UC 250 / Remote Attestation

Attestation is realised as a trusted channel (cf. / UC 290 /) where no actual data except
a nonce is being sent. The

RemoteClient

sends a nonce via the trusted channel to the

destination

Compartment

. That

Compartment

proves its ability to decrypt the nonce

RemoteClient

which can then be sure that the

Compartment

is currently config-

ured as described in the

Certificate

which was transferred during the establishment of

the remote trusted channel.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

/ UC 300 / TPM usage

A compartment uses the interface defined by the TPM specification of the TCG. It con-
nects to the

TPM Interface

, which provides it with the

CompartmentID

of a

vTPM

instance. With the

CompartmentID

, it performs a compartment configuration query

(see / UC 260 /) to verify the trustworthiness of

vTPM

4.4

High-Level Design of a Secure Virtual Private Net-
work

This section provides a high-level design of a secure Virtual Private Network for the
PERSEUS security framework. A use case model and an analysis of such a VPN mod-
ule are presented, and the design of an L4-based server (“bridge server”) implementing
virtual networking – which is required for the secure VPN – is described.

A prototype of such a secure VPN solution, called Turaya-VPN, was implemented

within the EMSCB project.

4.4.1

Introduction

Encryption systems are widely used to protect stored and communicated data from
unauthorised access. Application areas include device (e.g., hard disk) encryption as
well as Virtual Private Networks (VPN).

Unfortunately, most software-based encryption products suffer from various vul-

nerabilities such as insecure storage and usage capabilities for security-critical crypto-
graphic keys and operations. The underlying operating systems cannot prevent other
(potentially malicious) applications from gaining access to the critical key data. The
reasons lie in conceptual weaknesses of common computing platforms, in particular in
insecure OS architectures. This is evident by the huge number of exploits and constant
security updates. We present a security architecture that allows secure, reliable and
user-friendly encryption of TCP/IP communication. The security architecture strongly
isolates the secret (key) information and all related security-critical operations from
the operating system. A security software layer is installed between the hardware layer
and the operating system layer to isolate the legacy operating system (including legacy
applications) from security-critical applications. This is similar to a hardware based
solution but far more cost-effective. Moreover, the architecture is capable of using
Trusted Computing functionalities to protect the secret information and to assure soft-
ware integrity during the booting process of the system.

Structure of this Section.

Section 4.4.2 provides an overview of our requirements

and an analysis of a secure Virtual Private Network. Since this analysis assumes the
availability of virtual networking, the following section 4.4.3 introduces an L4-based
server that can provide such a virtual network.

4.4.2

Requirement Specification

Overview

This section presents our requirements for a secure Virtual Private Network (VPN) in
the form of a use case model.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

The solution has to establish a VPN by using the security platform and there-

fore facilitate protected communication with servers (web 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 managed by OpenTC. The user operating
system has no access to the information.

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

bridgeserver is to outsource the DMA-enabled network drivers

in an isolated compo-

nent that may additionally contain virtual private network (VPN) and firewall function-
ality. Clients open (and close) a network device, and read from (and write to) a previ-
ously opened network device. Additionally the bridgeserver allows to enforce access
control on which clients may open a network device and provides a simple manage-
ment interface. The client interface as well as the management interface should be as
simple as possible to be easily adaptable to a generic character device driver interface.

Security Environment

This subsection describes the security aspects of the environment in which the SVPN
is intended to be used and the manner in which it is expected to be employed.

The OpenTC security platform ensures that the secret required for establishing the

connection is kept in safe custody. The user operating system gets no access to the
secret. This ensures that compromising the user operating system does not endanger the
security of the whole VPN, because the secret is not within reach of the user operating
system.

Assumptions

A description of assumptions shall describe the security aspects of the environment in
which the SVPN will be used or is intended to be used. This shall include the following:

•

information about the intended usage of the SVPN, including such aspects as the
intended application, potential asset value, and possible limitations of use; and

•

information about the environment of use of the SVPN, including physical, per-
sonnel, and connectivity aspects.

/A 70/

Correct hardware

The underlying hardware (e.g., CPU, devices, TPM, ...) is non-malicious and behaves
as specified.

/A 80/

No man-in-the-middle attack

An attack using a dummy device that relays the whole communication between the
user and the platform to another device does not happen.

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.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

/A 90/

Trusted Administrator

The compartment administrator of the system must be trusted since he will have access
to all encrypted data.

Threats

A description of threats shall include all threats to the assets against which specific
protection within the SVPN or its environment is required. Note that not all possible
threats that might be encountered in the environment need to be listed, only those which
are relevant for SVPN operation.

/T 160/

Key spoofing

An adversary may try to eavesdrop the cryptographic key used for encryption/decryp-
tion.

/T 170/

Spoofing of authentication information

An adversary may try to eavesdrop the user authentication information.

/T 180/

Key manipulation

An adversary may try to violate integrity requirements of the cryptographic key used
for encryption/decryption.

/T 190/

Faked user interface

An adversary may try to deceive users by a platform providing a faked user interface.

/T 200/

Faked identity

An adversary may try to bypass control mechanisms by pretending a faked identity.

/T 210/

Software manipulation

An adversary may try to violate security requirements by maliciously manipulating the
security kernel.

/T 220/

Device driver manipulation

An adversary may try to manipulate device drivers such that hardware functions (e.g.,
direct memory access) are used to violate security policies.

Use Case Model

Additional use cases can be found in Appendix A.4.

The use case “Client Authentication” describes how a client process (e.g. a

browser) from the user system accesses a server (e.g., a web server) located in a pro-
tected intranet. To obtain access to the server’s service it is necessary that the SVPN
system establishes a protected channel to the corresponding intranet gateway server

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 20 /

ITLE

Create Connection

ESCRIPTION

A client process running on the user system
wants to establish a connection to a server in
a protected intranet.

ATIONALE

The server demands an authentication (pre-
shared key, certificate, . . . ) to approve a con-
nection establishment. While establishing the
connection, a session key, which is used to en-
crypt the subsequent communication, is trans-
mitted securely.

CTORS

Server, client

NCLUDES

Authentication

RECONDITIONS

The client requests data from a server.

OSTCONDITIONS

Once a connection is established, the client is
able to access all data provided for it.

ORMAL

LOW

1. The client sends a request for connection

establishment to the server.

2. The server demands the client’s authenti-

cation.

3. The client authentication is successful.

4. The server approves the connection es-

tablishment of the client.

LTERNATIVE

LOW

1. The client sends a request for connection

establishment to the server.

2. The server demands the client’s authenti-

cation.

3. The client authentication fails.

4. The connection establishment is aborted.

Functional Requirements

/FR 10/

Network Device Selection

Clients may choose different network devices to open by connecting to different bridge-
server instances.

/FR 20/

Fast Communication

The bridgeserver realises String IPC. Shared memory communication via the Drops
Streaming Interface (DSI) is planned for a later release.

pen_TC Deliverable 05.1

CHAPTER 4. L4 SECURITY SERVICES

/FR 30/

Packet Scheduling

The bridgeserver realises best effort packet delivery.

/FR 40/

Network Transparency

The bridgeserver offers full transparency of packet/frame delivery on all network lay-
ers, i.e., no packet/frame headers are parsed or modified. Packet/frame processing
(e.g., masquerading) is done by common Linux system components such as netfilter
and racoon.

Security Requirements

This part defines the security requirements that have to be satisfied by the SVPN.

/SR 60/

Access Control

The management interface should implement a rudimentary access control. The task
IDs

of applications that have permission to open a network device should be explicitly

defined over a management interface.

/SR 70/

Denial of Service

Denial of service of the bridgeserver is prevented by the L4 (round robin) task sched-
uler, i.e., each application only has a limited amount of time to occupy the bridgeserver.

General Architecture Description

In the context of the OpenTC environment, a certificate-based VPN shall be imple-
mented. The following requirements to the communication channel are made:

•

Integrity of the transmitted data

•

Confidentiality of the transmitted data

The host system which is operated by the user. The VPN described above is based

on a security platform such as OpenTC. All platform security aspects are also reflected
by and part of the security mechanisms of the complete system.

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
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.

A task ID unambiguously identifies an application during runtime.

pen_TC Deliverable 05.1

CHAPTER 4. L4 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 4.14: Bridgeserver Architecture

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 4.15: Protocol

devices):

bridgeserver2 -c|-s <tun-device> [<tun-device> ...

<tun-device>]

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

Design Objectives

The model is designed to provide generic integrity management functionalities to sup-
port a large range of platform components (e.g., security services) while minimising
the software complexity for its implementation. Hence, the objectives are two-fold:

Generic Trust Management. The primary objective for the management model is to

devise a generic management interface that is not bound to the underlying platform ar-
chitecture and the component structure. That is, the model is agnostic to usage models
and component types.

Minimal Trusted Computing Base. The secondary design objective is to minimise

the set of components that require hardware-protected immutable logs for a minimal
Trusted Computing Base (TCB)

. Hence, a side objective is to define the critical set of

platform components that are required to be in this set and extend the trust chain to the
rest through the functionality provided by this minimal set.

As a final note, this work is different from the on-going research that focuses on

reducing the TCB size that yields a smaller trusted OS [59] (e.g., Dom0 in Xen [8]).
Although, we are particularly investigating a similar problem for an integrity manage-
ment framework.

Component Structure

The scheme introduced in this section manages the integrity relation between platform
components. Below, a semi-formal definition of a platform component is provided that
is generic enough to comply with the first design objective stated above.

Component definition. A component (

) is a generic platform entity that can

change the state of the platform through execution. As an example, a component can
potentially be a service residing in a virtual domain (as in Section 5.2) or a group of
such services. Alternatively, a component can be the virtual domain itself if the man-
agement model is used to represent the integrity dependency between virtual domains.
Hence, the exact granularity in defining platform components depends on the granular-
ity of integrity management that is required on the platform.

Nevertheless, this abstract definition of a component is enhanced below while keep-

ing its generality. In particular, a component is comprised of:

1. An execution environment

Env

in which the functionality group executes.

2. A configuration group

Env

that defines the parameters for

Env

3. A functionality group

: (

Env

)

→

′

Env

that provides the necessary

component functionality and changes the platform state from

′

that is local

Env

In addition to these, a component is required to employ a Measurement Agent (MA)

(e.g., either as part of its implementation or as a plug-in) that will monitor ongoing
changes made to the component structure.

A central point that will allow us to devise a component hierarchy is the concept of

the execution environment. We claim that if a component

’s state changing impact

In this work, the TCB is equivalent to the set of components whose measurements are stored on trusted

hardware (e.g., on a Trusted Platform Module).

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

PARENT DYNAMIC COMPONENT

CHILD DYNAMIC COMPONENT

DYNAMIC

TRUSTED ENTITY

Integrity Metrics Manager

ID & Assoc. Data

Static Register

Dynamic Register

Policy

Env

Figure 5.1: A parent and a child dynamic component coupled with the child compo-
nent’s dynamic trusted entity.

(through execution or changes made to the component) is contained within its execu-
tion environment, then the integrity of the components residing outside this execution
environment will remain unaffected through this state change. The level of isolation
that can be guaranteed by the execution environment depends on the technology used to
implement such an environment. An example execution environment with such capa-
bility is the Java virtual machine (JVM). Another example are virtual domains running
on secure hypervisors that are hosted directly on hardware (e.g., Xen) or within a host
operating system (e.g., VMware).

Component types. A component can be of static or dynamic type. Static com-

ponents comprise the minimal set of components that reside in the TCB and provide
trust management functionality to the rest of platform components (i.e., dynamic com-
ponents). These components serve as the software root-of-trust for their descendant
components in the component hierarchy and offer protected storage, dynamic measure-
ments, and cryptographic operations through trusted interfaces (i.e., dynamic trusted
entities as explained in the following section). A platform component that is not a
static component is a dynamic component. Dynamic components use trusted inter-
faces provided by the closest static component in the hierarchy, for example, to request
access to secrets stored in persistent storage on behalf of them. The specifics of the
access are controlled by a policy that is enforced by the static components.

5.1.2

Hierarchical Integrity Model

Each dynamic component

is created by its parent component

−

within the par-

ent’s execution environment. When such a dynamic component is launched by a parent
component, a special type of trusted entity is associated with it on a one-to-one basis
(this special type of trusted entity is hereinafter called a “dynamic trusted entity” – or
‘DTE’ – to indicate that it is related to a dynamic component). The DTE is a trusted
entity that runs in a trusted environment (e.g., in a separate trusted compartment). As
depicted in Figure 5.1, the DTE has a persistent identity and interfaces that provide
access to a static and a dynamic register that hold integrity measurements made on the
dynamic component in protected storage.

Figure 5.2 shows a hierarchical arrangement of two dynamic components (

) each with its own dynamic trusted entity (

DT E

). Each dynamic com-

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

C(i)

DTE(i) .

C(i+1)

DTE(i+1)

Figure 5.2: A hierarchy of dynamic components and their associated dynamic trusted
entities.

ponent

is created by its parent component

−

along with the associated

DT E

Hence, each child component’s execution environment is a subset of its parent’s exe-
cution environment. Thus, each component

can only have one immediate ancestor

(i.e., parent). The resulting dependency relation can be represented with a component
tree that is rooted in the root-of-trust of the trusted platform concerned.

In a real platform, these components form a dependency tree similar to the one il-

lustrated in Figure 5.3 in which each dynamic component (white circle) is associated
with a respective dynamic trusted entity DTE. The dynamic components are organised
hierarchically. In the figure, six dynamic components are shown, individually identi-
fied by the letters

, but only the DTE of the dynamic component

has been

shown for reasons of clarity. The DTE holds a persistent identity on behalf of the com-
ponent it represents. Further, it provides access to the static and dynamic registers of
the component that are actually stored in the protected storage by a static component
that forms the root component

of the hierarchy; by way of example, Figure 5.3 shows

in protected storage the static and dynamic registers associated with the dynamic com-
ponent. The static component also holds the expected measurement values for each
descendant dynamic component.

The static component

, like the dynamic components, preferably comprises a

functionality group, an execution environment, and a configuration group. Addition-
ally, it provides protected storage and cryptographic resources for use by the dynamic
components. The integrity manager of each DTE of Figure 5.3 primarily serves as an
interface to the static component. Dynamic components use these interfaces to update
their respective associated static and dynamic registers and to request access to other
secrets stored in protected storage on their behalf.

In this setting, the static component is part of the trusted computing base, TCB, of

the platform (the trusted computing base being the collection of entities, including the
static component, that can potentially affect the trustworthiness of the platform). The
trust chain of the platform extends from its root of trust (typically based on a hardware
trusted module) to the static component and then on through the hierarchy of dynamic
components, to the extent that their respective states justify this.

The static component

holds data detailing the structure of the tree of dependent

components and the software to manage this tree. For simplicity, only a single static
component has been described in Figure 5.3, but the above-described arrangement can
be generalised to multiple static components each with its own tree. Dynamic com-
ponents do not possess any information about the tree structure except the identity of
their parent components (this information is held by the corresponding DTE).

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

referred to below as a “non-critical” change. A particular example of a non-
critical change might be a configuration or mode change.

As an alternative definition, a platform component for which such a classification

of changes is made and used in determining the integrity of the component is referred
to below as a dynamic component (“dynamic” because its trustworthiness may change
any number of times).

In addition to code providing the component’s intended normal functionality, a

dynamic component comprises a change-type policy element for use in determining
whether a change to the component is a trust-irrecoverable or trust-recoverable change,
and measurement agent(s) for measuring changes to the component itself. An appropri-
ate mechanism is provided for enabling the dynamic component to communicate with
its associated DTE. Both the change-type policy and the measuring agent, although
shown as part of the dynamic component, can be separately disposed while remaining
associated with the component.

An integrity measurement stored to the static register of the DTE in Figure 5.1

is combined with the existing value held in the register, that is, the register value is
extended (for example, in a manner similar to the way a PCR is extended). In contrast,
an integrity measurement stored to the dynamic register simply replaces the previous
value held in that register. The DTE further comprises an integrity metrics manager
providing the interface for storing integrity measurements and reliably reporting the
register values. The DTE may also allow access to the expected measurement values
for the component.

When the dynamic component is created, the parent component acquires an in-

tegrity metric of at least those parts (code and other data) of the dynamic component
that have a potential impact on the ability of the dynamic component to implement its
intended functionality correctly, and puts the value of this metric into the static register
using the DTE. The parent component may also acquire an integrity metric of at least
those parts (code and other data) of the dynamic component that have no impact on the
component’s ability to implement its intended functionality, and puts the value of this
metric into the dynamic register using the DTE. From then on, the static register can
only be updated by the component itself (with the aid of the integrity metrics manager)
whereas the dynamic register can be updated (via the integrity metrics manager) both
by the component and the parent (assuming the latter has access to the policy or has
equivalent knowledge to be able to recognise a non-critical change).

The dynamic component is entitled to measure and report changes to its structure.

Thus, when a change is determined, the dynamic component measures its effected part
(that is, either its integrity-critical parts in the case of a critical change or the non-
integrity-critical parts for non-critical changes). For a critical change, the resultant
measurement is used to extend the value in the static register, effectively creating a
permanent indication that a critical change has taken place. For a non-critical change,
the new integrity measurement simply replaces the previous value held in the dynamic
register.

Depending on the measurement values stored in both registers, the dynamic compo-

nent can be in one of three local integrity states: If the values in the static and dynamic
registers are consistent with the expected measurement values, the integrity is ‘intact’
(the component itself is trustable). If the value in the static register is consistent with
the expected measurement value but the value in the dynamic register is not, the in-
tegrity is recoverable. In all other cases, the integrity is irrecoverable. The relations
between these states is depicted in the state diagram in Figure 5.4.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

INTACT

IRRECOVERABLE

RECOVERABLE

LOAD

UNLOAD

Non critical change

Critical change

Figure 5.4: State diagram depicting platform component integrity states.

The foregoing arrangement enables a dynamic component that has only been sub-

ject to non-critical changes to be restored to its trustable condition and have this re-
flected in its integrity metric values stored in both registers. Also, a user may be willing
to trust a dynamic component which according to the expected register values known
to the DTE is in its recoverable state because the dynamic register matches an expected
value known to the user and not the DTE.

5.1.4

Evaluation of the Model

Lastly, the security model is evaluated in comparison to the current TCG model. The
new security model has many advantages over the current one due to the level of flex-
ibility it provides. However, one has to prove certain isolation properties as a prereq-
uisite to employing the model. Therefore, the model may not be suitable for platforms
for which no such guarantees can be given.

Advantages

Manageability. The hierarchical dependency model (i.e., tree-of-trust) is an improve-
ment over the current solutions that offer linear models (i.e., chain-of-trust). If the
necessary isolation properties are guaranteed, the model provides a finer-grained in-
tegrity management solution that allows:

Better representation The hierarchical model enables components with no depen-

dency relation (in terms of integrity) build separate integrity chains. Thus, the
integrity of a component only involves the integrity of itself plus its ancestors.
As an example, in Figure 5.3, the integrity of component

does not depend

on the integrity of the component

. Therefore, one can still potentially trust

component

even though component

may be in an untrusted state.

Isolation Changes to the platform components are isolated only to the appropriate

branch of the integrity chain, thus do not affect the complete platform. As a

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

result, a critical change will no longer require restarting and re-measuring the
complete platform but only the appropriate branch. Using the same example
from above, an irrecoverable integrity state for component

only requires

be restarted while

can continue its operation.

Scalability The measurement model provides a more scalable scheme than the current

one because the latter requires hardware registers to store the complete set of
integrity measurements. Because we use software measurements and store the
values in software registers in protected storage, our model can support virtually
infinite number of such measurements.

Dynamic measurements and adaptability. On-going monitoring and reporting al-

low components to reflect their latest state in a distributed manner. This provides up-to-
date information about the platform components. Moreover, the dynamic measurement
model enables components to re-establish trust without requiring a complete restart un-
der certain conditions. This is particularly advantageous for platforms with components
that change frequently and operate in various security modes.

Limitations

Two challenges are listed in implementing the new model. The first challenge is to
prove both vertical and horizontal isolation properties for platform components. As
illustrated in Figure 5.3, horizontal isolation guarantees that components that do not
share the same execution environment (hence do not have an ancestry relationship –
such as

and

) do not have any impact on each other in terms of integrity. Similarly,

vertical isolation guarantees that a compromise on a child component’s integrity does
not compromise its parent’s integrity. As an example, should each VM residing on a
secure hypervisor be a platform component, then a compromised VM should not have
an impact on other VMs’ integrity (horizontal isolation) and on the secure hypervisor’s
integrity (vertical isolation). Our management model is orthogonal to both horizontal
and vertical isolation and relies on the underlying technology to provide such guaran-
tees.

The second challenge is to prove the non-critical nature of reversible changes (i.e.,

second type) on component structure and configuration that allow components to al-
ternate between a trusted and a less trusted state. The challenge here is to prove that
the change is reversible and does not have any future effects on the component in ques-
tion or any side effects on other platform components. Because proving both claims are
hard problems, a conservative approach is taken to deem most of the changes as critical
(first type). In fact, only well-defined configuration related changes will be regarded as
reversible (second type).

5.2

Security Services Management Framework

In this section, the security services management framework (SSMF) is presented that
realises the abstract trust management model described in the previous section for vir-
tualised platforms. The framework mainly manages the trust relations between security
services that provide higher-level functionality to suspecting users.

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

Core SSM

Credential

Manager

Attestation

Manager

Component

Manager

Reporting

Manager

SSMF

SSMI

Figure 5.5: Components that comprise the security services management framework
(SSMF) and the corresponding interface (SSMI).

A crucial service offered by the framework is the management of security creden-

tials that are used by these services to perform security-critical operations requested
by service users. A popular practice is to couple each credential with an access policy
and allow its usage if and only if certain security properties are met. For example, the
framework employs integrity policies to provide guarantees to users that these creden-
tials will be accessed iff the integrity is intact. This way, suspecting users can verify
the correct operation of the security services plus the platform before exchanging data
with them. The SSM framework orchestrates this and similar trust relations between
the security services and users, and provides the necessary trusted interfaces.

5.2.1

Framework Architecture

The SSM framework is comprised of basic management modules that provide the core
functionality and add-on enhancements that provide further capabilities such as creden-
tial management. Figure 5.5 illustrates this arrangement. Mainly, the core framework
is responsible for managing the hierarchical integrity model as well as orchestrating
the dynamic integrity measurements. Two crucial enhancements introduced on top of
the core SSM provide service interfaces for credential management through a creden-
tial manager, and third-party interfaces for remote service-level attestation through an
attestation manager. The resulting framework (with core and enhanced functionality
combined) offers the security services management interface (SSMI) that is both used
by the services (for life-cycle management, credential management, and integrity re-
porting) and users (for remote attestation). In particular, the combined SSM interface
allows services to

•

Create dynamic child service components within the parent’s execution environ-
ment and manage the life-cycle of these children services.

•

Store their security credentials in protected storage.

•

Access their security credentials according to the corresponding access control
policies (i.e., integrity policy).

•

Report ongoing static and dynamic (i.e., first and second type) changes to their
structure and configuration, respectively.

•

Report their integrity status on service-level.

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

Effectively, the SSM framework is a stripped down implementation of a virtual

TPM [10] with two enhanced functionalities: service hierarchy and dynamic measure-
ments. Therefore, SSMF employs existing definitions and research around software
TPMs and reuses existing interfaces especially for credential management. These in-
terfaces are enhanced to support a hierarchy of multi-level static and dynamic measure-
ments.

5.2.2

Core Security Service Management

The core management framework serves as the static component introduced in the
management model in Section 5.1. It is the central component in SSMF that keeps track
of the service hierarchy and enables dynamic measurements. In particular, the core
SSM (1) manages the DTE dependency tree, (2) provides storage for measurements
and secure storage for credentials, and (3) provides service and reporting interfaces for
dynamic service creation and integrity reporting, respectively.

DTE Dependency Tree

Each dynamic service component is coupled with a Dynamic Trusted Entity (DTE)
whose structure is depicted in Figure 5.1. To keep track of the dynamic service hierar-
chy, the core SSM manages a data structure whose nodes are composed of DTEs. The
resulting data structure is a tree similar to the one illustrated in Figure 5.3. Each tree
node is a DTE representing the corresponding service component. Each DTE denotes
the location of the service component in the hierarchy. Further, each DTE provides
the necessary interface to its service that will allow the latter to interact with the SSMI
through a trusted channel.

DTE Identification

Every SSMI command requires identifying the requesting service to determine whether
the service is a managed service, and if so, to locate it in the service hierarchy. The
actual nature of identity management and authentication schemes employed by the core
SSM is implementation dependent. Two identity management models are investigated
that use DTEs in different ways to guarantee service identity. In the simple model,
each DTE and the attached dynamic component is identified by a weak / strong and a
temporary / persistent identity, depending on the platform requirements. In this setting,
each SSMI command requires the requesting service to specifically identify itself using
the identity provided to it during registration. Alternatively, DTE interfaces can be used
as a means of identifying the services. In this case, a service is no longer required to
explicitly specify its identity if it is capable of using its DTE interface to interact with
the SSMI. Both alternatives are investigated in more detail in [15].

Protected Storage

The core SSM keeps track of dynamic and static integrity measurements for each ser-
vice component. Further, security credentials used by each service are managed and

pen_TC Deliverable 05.1

OpenTC D05.1 – Basic Security Services

stored by the core SSM. Both pieces of information are sensitive data and the core SSM
employs a protected storage service to store each piece of data for each component.
Specifics of this storage is implementation dependent. As an example, a secure storage
service can employ a trusted hardware module (TPM) to protect sensitive information
stored on ordinary storage.

Registration and Reporting Interfaces

Access to the DTE tree and measurements is regulated through registration and re-
porting interfaces. The registration interface is used by dynamic services to register
child services with the system. A service may choose not to register with the SSMF.
However, services are not allowed to access their credentials unless they go through a
registration process during which the corresponding DTEs are created and the service
is added to the service hierarchy.

Registration can be requested via a single

()

request. Upon receiving the

request, the component manager

1. authenticates the requesting service (i.e., the parent) using the underlying au-

thentication model,

2. creates the DTE and optional identities for the child service,

3. updates the DTE tree with input from (1) and (2), and

4. initialises both the static and dynamic registers for the child service with the

initial measurements.

Upon successful completion of the above steps, the component manager returns a

full handle to the DTE to the child service and a restricted one to the parent (i.e., for
future dynamic measurements).

The reporting interface is composed of a single

report

()

request that can be used to

report both static and dynamic changes. Upon receiving such a request from a service,
the reporting manager

1. authenticates the requesting service using the underlying authentication model,

2. locates the requester service in the service hierarchy, and

3. updates the static or dynamic register for the service accordingly.

Further details on both interfaces can be found in [15].

5.2.3

Credential Management

Credential management is central to the operation of the SSM framework. Services
employ security credentials in a variety of ways. For example, a credential can be
an asymmetric cryptographic key that is used by a service to sign data. In this set-
ting, ability to sign data can give service users sufficient proof that the service can be
trusted. Access policies can be used to define the conditions under which the services

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

TCB

Figure 5.6: An example service hierarchy. Grey nodes denote service components,
black nodes denote TCB components including the static component

(i.e., the

SSMF), and boxes denote the static and dynamic registers – one for each service com-
ponent. An empty rounded box indicates that the service’s cumulative integrity is intact
whereas a filled rounded box indicates that it is not.

are allowed to access these credentials. If the underlying platform that enforces these
policies can be trusted, users can potentially deduce that the service can access to the
credential iff the policy conditions are satisfied.

The SSM framework provides verifiable means to securely store, manage, and pro-

vide access to these security credentials. Further, it provides guarantees that the man-
agement and usage of these credentials will be performed by trusted entities that can
be verified by third-party users.

Integrity policies play a crucial role in credential management. In particular, the

SSM framework uses cumulative integrity policies to determine whether a service can
have access to its security credential. Cumulative integrity of a service component
is defined as the accumulation of the integrity of the service, its ancestors, and the
underlying platform (i.e., the TCB). A service can access to its security credential iff
its cumulative integrity is intact. As an example, in Figure 5.6, the dynamic service
component

can have access to its credential iff the integrity of

, and the TCB

are intact. Note that, for example, the integrity of

has no effect on the cumulative

integrity of

An important security property is that at no time the framework reveals the security

credentials to the requesting services. That is, security credentials are always kept on
the trusted framework side. Access to these credentials is only allowed through the cor-
responding credential usage interface. This is because if a service obtains possession
of its security credential, the framework can no longer revoke the credential should
the dynamic service component reports a static or a dynamic change. Hence, in this
setting, services do not possess their credentials but are given access to them through
trusted channels.

pen_TC Deliverable 05.1

100

OpenTC D05.1 – Basic Security Services

Management and Usage Interfaces

Credential management involves two phases: provisioning and usage. The former is a
one time phase during which the credential is registered with the platform and sealed
to the protected storage along with its access policy. To do so, the requester uses the
credential provisioning interface to invoke a

provision

()

or a

generate

()

request. Upon

receiving the request, the credential manager

1. authenticates the requesting service using the underlying authentication model,

2. locates the service for which the credential will be provisioned or generated in

the service hierarchy,

3. generates a credential for the service with the given properties if

generate

()

issued, and

4. employs the underlying secure storage interface to request secure storage.

Upon successful completion of the above steps, the credential manager returns a

ticket that can be used later by the requester service to request access to the sealed
credential.

In the usage phase, the service component uses the credential usage interface and

the ticket to access its security credential. Initially, this interface is internally used to
unseal the service credential iff the platform integrity is intact. Upon receiving such a
request, the credential manager uses the ticket to unseal the credential from protected
storage.

Once the credential is brought into the framework, services can use the same in-

terface to access their secrets. Such access should not reveal any information on the
nature of the credential to the requester service component. Further, credentials are not
allowed to leave the SSMF. Therefore, the external usage interface is a simple crypto-
graphic interface that is merely composed of an

encrypt

()

and a

decrypt

()

operation.

Upon receiving either request, the credential manager

1. authenticates the requesting service using the underlying authentication model,

2. locates the service in the service hierarchy,

3. retrieves the credential using the ticket if the credential is stored on the secure

storage (one-time operation),

4. evaluates the cumulative integrity of the service,

5. performs the

encrypt

()

decrypt

()

operation if (4) is successful, and

6. returns the resulting blob to the requester.

The details of the above interface can be found in [15] where a software TPM-

based interface that is enhanced to support service hierarchy and cumulative integrity
is described.

pen_TC Deliverable 05.1

CHAPTER 5. SECURITY SERVICES MANAGEMENT

101

5.2.4

Remote Attestation

Lastly, the framework provides an optional service-level attestation scheme to third-
party users that would like verify the integrity of the service before exchanging data
with it. The attestation protocol is the same as the one describe by the TCG in [7]
with one difference. In the current setting, instead of running a full-scale platform
attestation, the framework allows users to run a much finer-grained service integrity
quote. This way, a user can request the cumulative integrity of any service in Figure 5.6
from

Attestation Interface

We implement two types of attestation protocols that differ on the choice of the entity
that verifies the integrity results (i.e., the user or the platform). Both protocols are
initiated using the single

attest

()

request with the proper option.

Attestation Protocol I. Supposing that a third-party user that attests a service com-

ponent, say

, also acts as the verifier of the integrity (i.e., has access to the expected

values for all components on the platform including the TCB). In this setting,

1. The verifier uses the attestation interface to attest the integrity of service

and

request the signed copies of all related current integrity measurements.

2. The framework locates

in the hierarchy using the identity of its

DT E

3. The framework returns the integrity of

, and the TCB (i.e., the register val-

ues) plus a signature

Sign

(

Sign

(

, I

)

Sign

T M

(

T CB

))

that is composed

of signed copies of the integrity of

, and the TCB signed by the static com-

ponent

and a trusted module TM, respectively.

4. Upon receiving the measurements and verifying the signatures, the user com-

pares the current register values for all three with the expected ones and decides
whether to trust

or not. (In this particular example,

’s cumulative integrity is

intact).

Attestation Protocol II. In this setting, the verifier is the platform and the user ei-

ther receives a

trusted

answer with a proof or a single

not trusted

answer. The first

two steps of the protocol are the same as above. In the third step, instead of return-
ing the integrity measurements, the framework compares the current and the expected
configuration. For example, for service

, it returns a

trusted

answer after compar-

ing the static and dynamic measurements of both

and

to the expected values.

Along with the answer, the framework returns the integrity of the TCB and the signa-
ture

Sign

T M

(

T CB

)

as the proof. This is because, the user still needs to verify that the

answer is generated by a trusted platform. However, if, for example,

is attested and

not trusted

answer is returned, the user requires no further proof.

The details of the above interface can be found in [15].

pen_TC Deliverable 05.1

102

OpenTC D05.1 – Basic Security Services

5.3

Conclusions and Chapter Summary

This chapter introduced a hypervisor-agnostic integrity management solution that em-
ploys Trusted Computing technology in ways to provide a more flexible and dynamic
trust management solution for virtualised platforms.

The Model. First, specifics of an abstract integrity management model that is ag-

nostic to the underlying platform and the component structure were detailed. Using the
execution environment argument combined with vertical and horizontal isolation guar-
antees, platform components were modelled hierarchically resulting in a dependency
tree. Further, a dynamic integrity measurement model that observes that changes to
component configuration may be less critical than changes to component structure was
devised. This observation yielded a more flexible integrity scheme as compared to
static TCG measurement models that deem every change as irreversible.

The Framework. Second, the model was realised concretely with a security services

management framework (SSMF) that employs the abstract model to (1) hierarchically
represent security services on virtualised platforms, (2) keep track of their static and
dynamic measurements, (3) manage their security credentials while regulating the ac-
cess to them, and (4) allow third-parties to attest their integrity.

In theory, the framework is sufficiently generic to be utilised on platforms with

any hypervisor type, including Xen and L4. Although, the approach mainly targets
architectures that are comprised of various disaggregated components that run in small
compartments

. In Xen-speak, each compartment is a virtual domain. In L4-speak,

each compartment is a task. Currently, L4 provides better disaggregation of services
that run on the hypervisor, hence the framework can be better utilised on an L4 hyper-
visor. Recent Xen research aims at a similar approach to devise smaller compartments
with disaggregated services running on them, which will make the SSMF approach
more desirable for integrity management on Xen.

Future Work. In the short-term, a Xen-based prototype implementation of the latter

will be presented that implements a subset of the SSM framework. A challenge here
is to determine the minimal set of functionality these modules provide that will be
essential to our framework (to support the minimal TCB objective). This prototype will
be used to manage components of varying granularity. As an example, the prototype
will manage security services that reside in a single VM on a virtualised platform.
Alternatively, it will be used to manage the trust relations in a hierarchy of VMs.

In the mid-term, the security model will be fully formalised and the framework

interfaces will be documented in detail. In the long-term, the focus will be on the
integration of this framework with other layers of the trusted platform (e.g., the basic
management interface, or BMI).

If the model is employed at the application granularity, these compartments can be execution environ-

ments that enable sufficient separation of applications (e.g., Java virtual machines)

pen_TC Deliverable 05.1

104

OpenTC D05.1 – Basic Security Services

6.2

Basic Trusted Computing PKI

A public key infrastructure is a framework enabling authentication, confidentiality and
integrity services using public key cryptography. It helps the users of a (public) network
to, e.g., authenticate the identity of communication partners and thus establish levels
of trust and/or secure communication channels.

The Trusted Computing concept introduces new types of security credentials and

procedures. Some fit established structures, some require small adoptions and some
represent new concepts.

Associated with the credentials is a life cycle of introducing them to the infrastruc-

ture, exchange of information between nodes in the network, (re)validation/evaluation
of their information value and finally withdrawal from use.

The new components of a basic Trusting Computing PKI are discussed in the fol-

lowing sections.

6.2.1

EK Certificate

Every Trusted Platform Module (TPM) is (should be) accompanied by a corresponding
TPM Endorsement certificate. This certificate contains the public part of the Endorse-
ment Key (EK) pair, which can be viewed as a TPM identity. The private part, called
the private Endorsement Key, is stored permanently inside the TPM and can not be re-
trieved once inserted. The certificate is (typically) signed by the TPM manufacturer and
represents an assertion that the specific TPM conforms with the required specifications
and the private Endorsement Key is kept safe by a TPM.

Extraction

As per [94] specification a distinct location of non-volatile RAM on the TPM chip is re-
served for the TPM EK certificate. Further, the TPM commands to extract non-volatile
memory content from the TPM are standardised. Thus, an obvious function of the TPA
is to extract the EK certificate. Unfortunately, to this date the only manufacturer to
include a TPM EK certificate on chip in every shipped TPM is Infineon.

Creation

If a TPM is shipped without a manufacturer issued certificate, a “late” construction of
an EK certificate may be applicable in selected scenarios, e.g., a limited deployment
in a department wide setup. Tools for creation of an EK certificate, utilising the real
public Endorsement Key of a TPM, are already available from OpenTC partner IAIK.
Integration of this functionality into a TPA is aimed for.

Who signs the TPM EK certificate and thus vouches for its integrity is of crucial

importance. In a limited deployment scenario a centralised entity can issue homegrown
EK certificates as well as offer services for their validation.

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

105

In the case of TPM vendor Infineon the necessary certificate chain for validation is

freely available for download from the manufacturers homepage. In the case of a self
made certificate, the signing authority certificate must be made available and accessible
to a validation entity later.

Note that a proof of possession of an EK private key can only be done with a full

AIK cycle (see section 6.2.3). This is an intentional limit of the TPM design.

Note also that a TPM EK certificate is the only proof that the corresponding public

Endorsement Key actually belongs to a specific type of TPM. Only a certificate signed
by a manufacturer (or equivalent important entity) is proof that the referenced TPM is a
hardware TPM. Self created certificates may contain an EK public key which actually
belongs to a TPM software emulator (e.g.,

http://tpm-emulator.berlios.de/

)

Validation

Validation of an TPM EK certificate may be accomplished in multiple steps:

•

A local user can read the public EK key from the local TPM and compare it to the
one contained in the sample TPM EK certificate. Upon match, one can assume
the certificate belongs to the TPM in the local machine.

•

If the issuer certificate chain is locally available and the Trusted Platform Agent
contains the necessary cryptographic support, a cryptographic validation of the
signatures of the certificate chain is possible.

•

A thin TPA with minimal footprint may offload certificate verification to a remote
service with more resources. In this design the usage of XKMS is suggested (see
section 6.4.4).

Note that the “how” is not as important as the security implications of remote
verification. The EK uniquely identifies the TPM, thus, every operation showing
the EK to third parties must ensure that the third party can be trusted. Also,
security of the communication link with the remote service has to be considered.

•

Full validation also requires a check with a PKI of the manufacturer of the spe-
cific TPM model (or series), if there are any known conditions affecting the
security of the TPM. This infrastructure is out of scope for a basic infrastructure.

Revocation checking is not part of the Basic PKI.

6.2.2

Platform Certificate

The platform manufacturer vouches for the parts of a platform with a Platform Endorse-
ment (PE) Credential. It represents an assertion that the specific platform incorporates
a properly certified TPM and the necessary infrastructure according to TCG specifi-
cations. There is a requirement for a “root of trust” (CRTM) to be a starting point for
building a “chain of trust” and related security measurements are implemented to check
the integrity of the platform.

So far no PE certificate is known to have been regularly shipped with a platform.

However, a tool to create PE certificates is available from OpenTC partner IAIK. As the

pen_TC Deliverable 05.1

106

OpenTC D05.1 – Basic Security Services

PE certificate is primarily part of the AIK cycle (see section 6.2.3) to be implemented
for the basic PKI, the creation of a fake PE certificate with “random” values is aimed
for as proof of concept.

6.2.3

Attestation Identity

As the Endorsement Key uniquely identifies a TPM and hence a specific piece of sur-
rounding hardware, the privacy of the user(s) is at risk if the EK is used directly for
transactions. As a consequence, the TCG introduced Attestation Identity Keys (AIKs)
and associated AIK certificates (standard X509 Public Key Certificates that include ex-
tensions defined by TCG), which cannot be backtracked directly to a specific platform.
The only entity that possibly knows more details is a trusted third party that issues the
AIK certificates, the so called Privacy CA.

AIK certificate creation cycle

In order to create an AIK certificate the following steps are taken:

•

The Trusted Platform Agent (TPA, see section 6.3) running on a machine con-
taining a TPM, calls the

CollateIdentityRequest

function of the Trusted Software

Stack (TSS) layer.

•

This creates an Attestation Identity RSA key pair and a certification request in-
tended for the Privacy CA.

•

The request is transported to the Privacy CA, using proper PKI operational pro-
tocols.

•

The Privacy CA validates the request content (and included EK and PE certifi-
cates). On success it issues an AIK certificate, encrypted with the public EK key
of the TPM and thus only readable by the indented recipient.

•

The Privacy CA result is communicated back to the TPA.

•

The TPA calls the

ActivateIdentity

function of the Trusted Software Stack, thus

unwrapping the AIK certificate.

•

The TPA stores the AIK certificate locally.

Summarising, an activated AIK identity comprises a) an “identity” TPM keypair and
b) an associated certificate proving that the keypair belongs to a “valid” TPM, vouched
for by a Privacy CA entity.

Privacy CA

The role of the Privacy CA (PCA) is of being a trusted third party that works as an
anonymiser. For privacy reasons the unique TPM Endorsement Key should only be
shown on a “need to know basis”. In the concept of the AIK cycle (see previous
section) the Privacy CA issues AIK certificates for a “derived” AIK key. This ensures

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

107

better anonymity of the EK key holder, but still contains proof of the underlying Trusted
Computing supported hardware.

Operation of a Privacy CA is guided by a published policy. It should clearly de-

scribe how the relationship EK certificate versus issued AIK certificates is managed.
The implementation options for a Privacy CA cover a spectrum from “remember every-
thing” to “know enough for the specific operation, forget everything after completion
of operation”. Thus, the usage of a specific PCA may be usage scenario dependent.

Implementation of a Privacy CA covers functionality for

•

A network front end for receiving/sending requests/responses. The design in this
document uses the XML Key Management Standard (XKMS).

•

A unit implementing the AIK cycle.

•

Local storage. The PCA handles multiple types of certificates. It receives Trusted
Computing specific certificates (EK, etc.), it issues AIK certificates and needs
foreign certificates for validation (e.g., EK manufacturer certificate chain). The
storage must accommodate multiple types.

•

A validation unit, capable of determining the status of certificates.

In the easiest scenario the validation concerns self issued certificates, thus trans-
forming a validation operation to a simple signature check or lookup in local
storage. Further, the validation unit should be preloaded with manufacturer cer-
tificate chains (e.g., those already available from Infineon), if possible, too.

The more complex case of actively contacting external entities for missing pieces
required for validation is out of scope for a basic PKI.

6.3

Trusted Platform Agent

A PKI requires both server side components, such as certificate authorities, as well as
client side applications that provide access to PKI services. In the context of Trusted
Computing such a client application is referred to as the Trusted Platform Agent (TPA).
For wide user acceptance it is crucial that the TPA makes all Trusted Computing re-
lated functionality available in a consistent and user-friendly way. Ideally, the TPA
is designed and implemented in a modular way that provides an easy integration of
additional advanced services later on. Furthermore, in terms of user friendliness the
TPA is expected to provide an abstraction of the underlying system concepts that is
understandable and manageable for an average user: for this purpose a simple API is
provided as well as console commands running on top of it. The TPA largely relies
on the services provided by the TSS stack. The overall architecture design of the TPA
and the individual system layers is presented in Figure 6.1. Dark grey boxes represent
components that will be possibly developed for the Advanced PKI.

The initial basic core functionalities provided by TPA fall in the following cate-

gories:

•

TPM and platform management. This category includes operations such as

TakeOwnership

, enabling and disabling the TPM and reading TPM status in-

formation.

pen_TC Deliverable 05.1

108

OpenTC D05.1 – Basic Security Services

(hardware or software) TPM

TPM Device Driver

TSS Stack

SKAE

parser

DAA

wrapper

TPM

management

and reporting

CA and PCA

interface

Other service

modules

DAA

functions

User space

Kernel space

DAA

platform role

Local

storage

TPA console utilities

TPA API

Trusted Platform

Agent (TPA)

Figure 6.1: Trusted Platform Agent (TPA) and underlying layers

•

TC credentials management. This category includes operations needed to man-
age the life cycle of TC credentials (EK, PE, and AIK certificates) by interacting
with TC-enabled authorities. The TPA and the latter communicate through net-
work protocols, XKMS will be used for the first prototype (required extensions
will be developed as needed)

– EK certificate: extraction, creation, validation

– Platform certificate: creation, validation

– AIK certificate: creation, validation, reissue, revocation

•

Light support for standard X.509 credentials. A simplified support to request a
standard X.509 certificate is provided: it is possible to manage certificate with
standard profiles using the TC-enabled PKI. This support does not include the
interaction with standard PKI authorities; however the interoperability of the
issued certificates with existing standard PKIs is guaranteed.

•

Local storage for TC-related and standard keys and certificates

•

Integrity measurement and reporting. This category includes the following TPM
operations: extending PCRs, reading PCRs, activating identities (i.e., AIK cer-
tificates) and TPM quote operation.

•

API to access all functionalities provided by TPA.

In addition, the TPA can also act as an integration point for a number of other services in
the context of Trusted Computing. The main benefit of this approach for the user is that
all Trusted Computing related tasks can be done from a single point, the TPA. Adding
additional services is facilitated by the modular nature of the TPA. These additional
services might include (but are not limited to):

•

Management of the DAA communications among the different roles (Trusted
Platform, Issuer and Verifier)

– Standard formats for the exchanged DAA data and messages for using

DAA as a standalone protocol or integrated within other protocols

– A network protocol for using the DAA as a standalone application protocol

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

109

•

Support for another TC-PKI operational protocol like Certificate Management
Messages over CMS (CMC) [41] in addition to XKMS.

•

Support for the Subject Key Attestation Evidence (SKAE) extension for X.509
credentials.

•

A front end for key backup and key migration.

•

A user and policy management framework.

6.4

XKMS mapping

A public key infrastructure integrates multiple actors – clients, certification authorities
and specialised services. Over the years multiple protocols were developed in the area
of PKI and credential management. For Trusted Computing it is necessary to carry
traditional PKI services as well as TC specific attributes, queries and data blobs.

XML Key Management Services (XKMS) [107]) is chosen for a first basic Trusted

Computing enabled PKI setup, which is in line with the considerations of the TCG in
[95] (chap. 6.5.2/p.43) and their recommendation:

“XKMS provides a way to express certificate management function in XML, while

providing a wrapper over legacy CA services designed for X.509 certificates. As such,
XKMS provides the most attractive solution for credential management for existing
CAs in the PKI industry.”

XKMS supports four standard registration service functions: Register, Recover,

Reissue and Revoke. These offer a wide range of parameters and thus cover the whole
life cycle support of credentials.

Further, two key information service functions, Locate and Validate, provide search

and status query functionality about credentials deployed in the PKI.

Considering the PKI components outlined in section 6.2 and 6.3, in the following

sections a mapping of PKI operations to XKMS specific requests and responses is
established and interaction with Trusted Computing usage discussed.

6.4.1

Message Structure

XKMS is an XML based protocol for common PKI operations. The revised edition 2.0
of XKMS [107] reached recommendation status in June 2005. In order to reduce du-
plicate descriptions in the following sections, the common XML structures of a typical
XKMS request and response message are discussed.

Request

The following block outlines the structure of a typical XKMS request:

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

. . . R e q u e s t x m l n s=

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms #”

x m l n s : d s =

” h t t p : / / www . w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #”

x m l n s : x e n c =

” h t t p : / / www . w3 . o r g / 2 0 0 1 / 0 4 / x m l e n c #”

pen_TC Deliverable 05.1

110

OpenTC D05.1 – Basic Security Services

I d =

” . . . ”

S e r v i c e =

” h t t p : / / o p e n t c . i a i k . t u g r a z . a t / xkms / . . . ”

. . . p a y l o a d . . .

A u t h e n t i c a t i o n

. . .

/ A u t h e n t i c a t i o n

/ . . . R e q u e s t

The XML tag name of an XKMS request message always ends in

Request

. Exam-

ple tag names are

LocateRequest

ValidateRequest

, etc. The XKMS XML

schema includes the schemata of the XML digital signature standard [108] as well
as the XML encryption standard [109]. A good solution is to assign the default XML
namespace to XKMS and assign easy recognisable prefixes for the inclusions, as shown
above.

Every XKMS message must carry a unique

identifier generated by the originator

of the message. Typically this is a random string of at minimum 32 characters (to
provide sufficient entropy against attacks).

The

Service

attribute contains the URI of the network service endpoint. For a

basic PKI infrastructure the HTTP protocol is sufficient as transport medium. Thus, a
XKMS request is mapped to a HTTP POST operation:

POST / xkms / . . . HTTP / 1 . 0

C o n t e n t

−

T y p e : t e x t / xml

H o s t : o p e n t c . i a i k . t u g r a z . a t
C o n n e c t i o n : C l o s e

Cache

−

C o n t r o l : no

−

c a c h e

C o n t e n t

−

L e n g t h :

. . .

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

. . . R e q u e s t

. . . . .

The path component “

/xkms/...

” is used to distinguish categories of

requests. An obvious mapping would be, e.g., “

.../aik

” for all AIK specific

requests and “

.../ek

” for EK related operations. Implementation experience is ex-

pected to define useful groupings.

An optional

Authentication

component is employed for operations which

are restricted to specific clients or need proof of knowledge of a shared secret. The
XKMS standard contains a description of an algorithm to derive a cryptographic
key from a secret string (e.g., password). One can then use this key to generate
a XML digital signature inside the

Authentication

message component which

references the

KeyBinding

type payload of the request. If the validation of the

Authentication

element fails at server side, the response message contains

“

ResultMajor=Sender

” with “

ResultMinor=NoAuthentication

”.

Response

The following block outlines the structure of a typical XKMS response:

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

111

. . . R e s u l t x m l n s=

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms #”

x m l n s : d s =

” h t t p : / / www . w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #”

x m l n s : x e n c =

” h t t p : / / www . w3 . o r g / 2 0 0 1 / 0 4 / x m l e n c #”

I d =

” . . . ”

R e q u e s t I d =

” . . . ”

R e s u l t M a j o r =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # S u c c e s s ”

R e s u l t M i n o r =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # . . . ”

S e r v i c e =

” h t t p : / / o p e n t c . i a i k . t u g r a z . a t / xkms / . . . ”

S i g n a t u r e x m l n s=

” h t t p : / / www . w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #”

. . . g l o b a l m e s s a g e s i g n a t u r e o f XKMS r e s p o n d e r . . .

/ S i g n a t u r e

. . . p a y l o a d . . .

/ . . . R e s u l t

The XML tag name of an XKMS response message always ends in

Result

. Example

tag names are

LocateResult

ValidateResult

, etc. Note that there also exists

a basic

Result

response message. This one is emitted by the server when he cannot

properly parse an invalid request and thus cannot determine the more specific type of a
request.

In comparison to the XKMS request message the result message contains additional

components:

•

RequestId

is a copy of the

of the corresponding request message. It en-

ables a client with multiple XKMS messages in transit to match request-response
pairs.

•

ResultMajor

specifies the overall outcome of the request. In case of process-

ing of the request without failure a

Success

result is expected. In the case of

an error

ResultMajor

contains an indication who is assumed to be the cause

of the error,

Sender

Receiver

•

An optional

ResultMinor

specifies additional details of the result status of a

request, if the value in

ResultMajor

can not alone represent all interesting

information.

A response by an XKMS service is expected to be always signed. This XML digital
signature encloses the whole XKMS message. In order for the client to verify the sig-
nature, the public key of the XKMS service must be known on the client side. Typically
the public key is shipped to the client in form of a X509 type certificate.

The result received from an XKMS request submitted using HTTP POST typically

looks like:

HTTP / 1 . 1 200 OK

D a t e :

. . . . .

C o n t e n t

−

T y p e : t e x t / xml ;

c h a r s e t =UTF

−

C o n t e n t

−

L e n g t h :

. . .

C o n n e c t i o n : c l o s e

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

. . . R e s u l t

. . . . .

pen_TC Deliverable 05.1

112

OpenTC D05.1 – Basic Security Services

6.4.2

RegisterRequest

A XKMS RegisterRequest is used to build a binding of information, typically to a
public key(pair). The registration request message contains a prototype of the requested
binding.

In the context of Trusted Computing a RegisterRequest may perform the following

functions:

Creation of an EK certificate

The TCG infrastructure concept requires the public endorsement key of a TPM accom-
panied by a certificate. To integrate TPMs (or TPM emulators) without a certificate, a
function to create one from a public key is desired.

Structure of a request, including a RSA public key:

R e g i s t e r R e q u e s t

. . .

P r o t o t y p e K e y B i n d i n g I d =

” . . . . . ”

Key Info

. . .

KeyValue

RSAKeyValue

Modulus

. . .

/ Modulus

Exponent

. . .

/ Exponent

/ RSAKeyValue

/ KeyValue

/ Key Info

/ P r o t o t y p e K e y B i n d i n g

A u t h e n t i c a t i o n

. . . S i g n a t u r e

r e f e r e n c i n g P r o t o t y p e K e y B i n d i n g . . .

/ A u t h e n t i c a t i o n

/ R e g i s t e r R e q u e s t

Creation of an AIK identity

The exchange between a client system TPM/TSS and a Privacy CA to create an AIK
certificate is almost fully standardised in the TCG specifications. Basically, it com-
prises a transfer of an encrypted binary blob (namely an array of bytes) to the Privacy
CA, resulting in 2 binary blobs as an answer. Unfortunately the features of the XKMS
protocol do not allow for an obvious mapping. To prevent early modification of XKMS
we decide to transfer the blob information in this case in the

OpaqueClientData

tag. As the name suggests the content of this tag should be opaque to the server, how-
ever the gain of experience of getting a running prototype faster has priority. In a later
implementation of an advanced PKI the use of, e.g., the XKMS MessageExtension
feature for a cleaner solution may be considered.

Structure of the request:

R e g i s t e r R e q u e s t

. . .

P r o t o t y p e K e y B i n d i n g I d =

” . . . . . ”

Key Info

. . .

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

113

KeyValue

RSAKeyValue

Modulus

. . .

/ Modulus

Exponent

. . .

/ Exponent

/ RSAKeyValue

/ KeyValue

/ KeyInfo

/ P r o t o t y p e K e y B i n d i n g

A u t h e n t i c a t i o n

. . . S i g n a t u r e

r e f e r e n c i n g P r o t o t y p e K e y B i n d i n g . . .

/ A u t h e n t i c a t i o n

/ R e g i s t e r R e q u e s t

The

blob

element

containing

the

binary

blob

returned

the

CollateIdentityRequest

function of the TSS.

Structure of the response:

R e g i s t e r R e s u l t

. . .

S i g n a t u r e

. . .

/ S i g n a t u r e

KeyBinding

KeyInfo

. . .

X509Data

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

/ X509Data

/ KeyInfo

S t a t u s S t a t u s V a l u e =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # V a l i d ”

/ KeyBinding

/ R e g i s t e r R e s u l t

With

blob1

containing

the

symCaAttestation

and

blob2

the

asymCaContents

answer of the Privacy CA, to be passed to the

ActivateIdentity

function of the client TSS.

For a discussion of other

Authentication

possibilities, see also section 6.4.5.

6.4.3

LocateRequest

A XKMS LocateRequest provides a discovery function. It resolves the passed query
keybinding and matches request information with local and/or remote data. The answer
of a Locate service makes no assertions to any validation criteria. However, a result of
a Locate service may be forwarded to a validation service, or, if possible, additional
trust verification is done locally.

The following services are useful in a Trusted Computing context:

Query for an AIK certificate

AIK certificates do not contain a subject distinguished name of the certificate owner,
but only a

label

, chosen freely at AIK certificate creation time by the client/user. To

retrieve a specific AIK certificate a locate request for a specific label name is desired.

pen_TC Deliverable 05.1

114

OpenTC D05.1 – Basic Security Services

An obvious mapping to XKMS would be to use the

X509SubjectName

in the

KeyInfo

portion, however, as some XKMS libraries may check this field strictly for

X509 name rules compatibility (and the AIK label specification is less restrictive) this
is avoided and the

KeyName

field used instead.

Thus, a query for a specific AIK certificate looks like:

L o c a t e R e q u e s t

. . .

RespondWith

h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 3 / xkms# X 5 0 9 C e r t

/ RespondWith

QueryKeyBinding

Key Info

. . .

KeyName

l a b e l O f A i k C e r t i f i c a t e

/ KeyName

/ Key Info

/ QueryKeyBinding

/ L o c a t e R e q u e s t

An answer is of the form:

L o c a t e R e s u l t

. . .

R e s u l t M a j o r =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # S u c c e s s ”

. . .

S i g n a t u r e

. . .

/ S i g n a t u r e

U n v e r i f i e d K e y B i n d i n g

Key Info

. . .

X509Data

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

/ X509Data

/ Key Info

/ U n v e r i f i e d K e y B i n d i n g

/ L o c a t e R e s u l t

Note that depending on the policy of the Privacy CA the AIK label may not be unique
and in the

X509Data

component multiple certificates may be returned.

6.4.4

ValidateRequest

The operations of an XKMS ValidateRequest are similar to a LocateRequest (see pre-
vious section), however, the returned status of a binding is evaluated from well defined
validation criteria. A validation service returns only information which has been vali-
dated by the service. Its validation policy is expected to be publicly available.

In order to validate a specific certificate, it is sent to the service:

V a l i d a t e R e q u e s t

. . .

RespondWith

h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 3 / xkms# X5 09 Chain

/ RespondWith

QueryKeyBinding

Key Info

. . .

X509Data

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

/ X509Data

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

115

/ KeyInfo

/ QueryKeyBinding

/ V a l i d a t e R e q u e s t

The expected result upon positive validation is an

X509Chain

, a certificate chain

build from the supplied certificate to a trusted root.

V a l i d a t e R e s u l t

. . .

R e s u l t M a j o r =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # S u c c e s s ”

. . .

S i g n a t u r e

. . .

/ S i g n a t u r e

KeyBinding

KeyInfo x m l n s=

” h t t p : / / www . w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g #”

X509Data

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

/ X509Data

/ KeyInfo

S t a t u s S t a t u s V a l u e =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # V a l i d ”

V a l i d R e a s o n

h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms# I s s u e r T r u s t

/ V a l i d R e a s o n

V a l i d R e a s o n

h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms# S i g n a t u r e

/ V a l i d R e a s o n

V a l i d R e a s o n

h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms# V a l i d i t y I n t e r v a l

/ V a l i d R e a s o n

/ S t a t u s

/ KeyBinding

/ V a l i d a t e R e s u l t

The corresponding result message contains the certificate chain as an array of certifi-
cates and a

Status

component describing more detailed evaluation results.

In Trusted Computing it is of interest to check the status of EK and AIK certificates.

For a basic PKI the XKMS validation message exchange is the same for both cases.

Note that a PE certificate is an attribute certificate whereas XKMS is designed for

X509 certificates. An attribute certificate may be included somehow in raw form as
array of bytes, but the feasibility of this concept still has to be determined.

Note that it is a policy decision of the service whether the service only validates

its own issued certificates or also uses external resources. E.g., validation of an EK
certificate may be done locally at the server if the certificate chain is known, however
proper validation should also include a revocation check with a manufacturer PKI, if
available.

6.4.5

RevokeRequest

An XKMS RevokeRequest manifests the desire to invalidate a previously issued bind-
ing. The payload consists of what to revoke, a certificate, etc.:

pen_TC Deliverable 05.1

116

OpenTC D05.1 – Basic Security Services

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

Rev o keRequest

. . .

RevokeKeyBinding I d =

” . . . ”

Key Info

. . .

X509Data

X 5 0 9 C e r t i f i c a t e

. . .

/ X 5 0 9 C e r t i f i c a t e

/ X509Data

/ Key Info

S t a t u s

S t a t u s V a l u e =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # I n d e t e r m i n a t e ”

/ RevokeKeyBinding

A u t h e n t i c a t i o n

. . . S i g n a t u r e

r e f e r e n c i n g R e v o k e K e y B i n d i n g . . .

/ A u t h e n t i c a t i o n

/ Rev o keRequest

It is expected that this function is always restricted to a specific client population, thus
always requires an

Authentication

element.

The response consists of a simple

Success

(or not):

? xml v e r s i o n =

” 1 . 0 ”

e n c o d i n g =

”UTF

−

8”

R e v o k e R e s u l t

. . .

R e s u l t M a j o r =

” h t t p : / / www . w3 . o r g / 2 0 0 2 / 0 3 / xkms # S u c c e s s ”

S i g n a t u r e

. . .

/ S i g n a t u r e

/ R e v o k e R e s u l t

The XKMS options of

Authentication

and/or

RevocationCode

require re-

examination under Trusted Computing. Both represent an assurance to the service that
one is a valid entity, allowed to withdraw/revoke information from the PKI.

In the case of use of a

RevocationCode

during the RegisterRequest (see sec-

tion 6.4.2) a code is specified and only if a RevokeRequest supplies the identical code
again the revocation is accepted.

The

Authentication

signature can be generated from a shared secret – a pass-

word. Usage of a (TPM) private key itself to generate an

Authentication

XKMS

signature (effectively a proof of possession signature) is not always feasible in a trusted
computing context. The private endorsement key is not available for generic crypto-
graphic operations and the private key corresponding to an AIK certificate is also not
designed to be used for arbitrary signing operations.

6.4.6

ReissueRequest

XKMS ReissueRequests are similar to RegisterRequests (see section 6.4.2), the goal
being to issue the same item again. The obvious application is to forward an expired
certificate and obtain a fresh one of same content, but with a new validity period (the
old one getting revoked).

Issues of

Authentication

are similar to those described in section 6.4.5.

pen_TC Deliverable 05.1

CHAPTER 6. PUBLIC KEY INFRASTRUCTURE

117

Reissuing Trusted Computing related credentials is out of scope for a basic PKI.

This point may be revisited when more experiences with certificate life expectancy,
usage scenarios and validity periods are available.

6.4.7

RecoverRequest

The XKMS RecoverRequest serves to recover a private key associated with a previ-
ously binding. This is only possible if the private key was previously escrowed at the
server or server generated. In the context of a basic Trusted Computing infrastructure
there is no application for this type of request, as this would invalidate the concept of
TPM bound keys, thus can be ignored.

6.5

Open Issues

Design and implementation of a basic trusted PKI for OpenTC highlights multiple
issues to be considered. Among them are

•

Certificates and issuing authorities require clear and distinct policies. This in-
cludes human readable text as well as associated Object Identifiers (OIDs) for
automated processing. Only standardisation of these ensures interoperability and
spreading of a Trusted Computing PKI.

•

The basic PKI outlined in this document assumes XKMS as transport protocol
and no specific schema extensions for Trusted Computing. However, even a ba-
sic scenario suggests that new URI string definitions for KeyUsage, UseKeyWith
etc. would be useful to clearly distinguish TC specific operations from common
PKI operations.

•

The public documents of the TCG currently only discuss security credentials
in X509 certificate format. Some documents however hint at the possibility of
future XML based credentials. The inclusion of XML credentials directly in
XKMS is a tempting outlook, however the resulting schema extensions and ef-
fects on alternative protocols and designs have to be carefully considered.

•

At time of this writing the only TPM manufacturer shipping EK certificates with
its TPM chips is Infineon. There are no known public platform certificates. There
is no known public AIK cycle test. A first basic PKI implementation is hopefully
a stimulus for accelerated development, but this highlights that this area is still
under major development. Future design adoptions are to be expected.

•

The software platform designated to implement this first design on is Linux with
its Trusted Software Stack (TSS) called TrouSerS (

http://trousers.sf.net

). At

the time of writing this document this is the only freely available fully imple-
mented TSS for the Linux platform. Therefore all experiments and prototyping
is using the TrouSerS specific implementation of the AIK cycle. Being heavily
tied to low level C structures, level of compatibility of the TrouSerS implemen-
tation with other TSS implementations is unknown.

pen_TC Deliverable 05.1

Chapter 7

Advanced Security Services

7.1

Privacy-enhancing Protocols

M. Schunter, E. Van Herreweghen (IBM), H. L¨ohr, C. St¨uble, A.-R. Sadeghi

(RUB)

The TCG solution for (remote) verification of platform integrity is a mechanism

called (remote) attestation, more concretely binary attestation. Loosely speaking, this
mechanism measures all code executed by using a certain metric and some system
components assumed to be trusted.

Unfortunately, this raises substantial privacy concerns. If individuals are forced to

reveal their complete configuration, their machines can easily be identified. In addition,
if traditional public key schemes are used, each machine can be traced by its key pair.

In order to overcome the privacy challenges of trusted computing technology, we

propose several technologies. The first step is privacy-friendly certificates that only
prove that a person owns a platform with a TPM without revealing any identifying
information. This “Direct Anonymous Attestation” scheme is covered in WP3 and will
be described in a WP3 deliverable.

Our focus is on preventing identification of users by means of their platform con-

figuration. In order to resolve this challenge, we propose property-based attestation as
a privacy-protecting alternative to binary attestation.

This report is based on two earlier research paper [78, 71] describing the general

idea of property-based attestation. The article proposes a security architecture required
to securely attest properties of a machine. Moreover, the paper suggests several ideas
on how to prove properties based on different trust assumptions, e.g., using a zero-
knowledge protocol. Such a zero-knowledge protocol realising a delegation-based ap-
proach to property-based attestation that relies on property-configuration certificates
has been published recently (see [19]).

The idea of property-based attestation is to use TPM technology to provide a ver-

ifier with evidence of well-defined security properties of a remote verified platform
without the ability (and need) to know what exact implementation has been used on
that platform. In the following chapters we will describe different approaches for the
implementation of property-based attestation.

Property-based attestation improves scalability as well as flexibility. It resolves

the privacy, security and discrimination issues since the verification proxy hides the

119

Open_TC Deliverable 05.1

120

OpenTC D05.1 – Basic Security Services

configuration information and it enables openness since the same security property can
be provided by many implementations by multiple vendors.

As a consequence, a verifier only learns that a given platform satisfies his security

requirements without learning the detailed configuration. As a consequence, configu-
rations can no longer be used to trace individual machines.

7.1.1

Outline of this Section

This section is structured as follows: The next subsection explains the terms and defini-
tions, including the basic system model. Section 7.1.3 briefly reviews the main aspects
of the TCG specification. Section 7.1.4 introduces a corresponding abstract model of
the TCG functionality and discusses why the offered mechanisms should, in our opin-
ion, not be used on more abstract system levels. In Section 7.1.6, we introduce the
basic idea of property-based attestation, while Section 7.1.7 discusses several practical
realisations of property-based attestation that differ in their assumptions and their trust
models. Section 7.1.11 explains our solution based on microkernels. Section 2.4 dis-
cusses work that is implicitly or explicitly related to this report. Finally, Section 7.1.12
briefly reviews the open problems and concludes with a short summary.

7.1.2

Terms and Definitions

Power set:

Given the set

{

, . . . e

}

we denote the power set of the set

with

(

)

Protocols and Algorithms:

We denote the execution of a protocol

Protocol

(),

i.e., a protocol run, between two parties

and

as follows:

(

out

;

out

)

←

Protocol

(

;

∗

where the identifier * denotes the common input both parties have access to,

re-

spectively

represent the individual inputs of

and

, and

out

and

out

denote

the outputs of the protocol to

and

after the protocol run. The protocol outputs

may include an indicator

ind

∈ {

true

false

}

indicating that the corresponding party

accepts/rejects. We sometimes omit the common input in abstract protocol notation.

Cryptographic Primitives:

An encryption scheme is denoted with the tuple

(

GenKey

()

Enc

()

Dec

())

for the key generation, encryption and decryption algo-

rithms. The tuple

(

)

denotes the public and private key of a party

. Fur-

ther, a digital signature scheme is denoted with the tuple

(

GenKey

()

Sign

()

Verify

())

for the key generation, signing and verification algorithms. With

←

Sign

(

)

we denote the signature on a message

using the signing key

The re-

turn value of the verification algorithm

ind

←

Verify

(

σ, m

)

is a Boolean value

ind

∈ {

true

false

}

. A cryptographic hash function is denoted by

Hash

()

. A certificate

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

121

on a quantity

with respect to a verification key

is a signature generated by

applying the corresponding signing key

If we are concerned with local algorithms performed by a single party, we use the

same notation but omit the corresponding names of the parties.

Basic Model

Machines:

A machine

is defined by a deterministic finite state machine

(

, I, O,

∆)

where

denotes the unique identifier,

the set of machine states

with

∈ S

the initial state,

a set of input actions,

a set of output actions, and the

transition

∆ :

S ×

→ S ×

. An empty input or output is denoted by

. Further,

we use the term empty machine to indicate a machine with empty sets

, and

∆

and

only one state.

Channels:

Machines exchange information using communication channels.

write

Out

←

name

(

)

to indicate that a machine uses a channel

name

sending the

information

and (optionally) receiving the information

Out

. Channels may pro-

vide different security properties. We call a channel secure, if it provides integrity,
confidentiality, and authenticity.

Configuration:

The configuration

of a machine

is defined by the tuple

(

∆)

. Having this tuple one can analyse the state set as well as certain aspects of the

I/O behaviour of this machine. We denote an encoding of a configuration

(e.g., an

integer) with

, and also call it configuration.

An example of

is a software binary including the initial state of all variables

and the instruction set. For simplicity, we assume that all security relevant inputs (e.g.,
configuration files) are included in

and/or

∆

Machine creation and initialisation:

The secure channel

create

()

indi-

cates that a parent machine creates an empty child machine with the identifier

The secure channel

init

(

)

is used by the parent to overwrite the configuration of

the child machine. Further, we write

exec

(

)

to indicate that a machine

invokes the sequence

create

()

and

init

(

)

Platform:

A platform

represents the system architecture under consideration.

is a state transition machine that itself is defined as a tree of machines

(

j
i

)

, i

∈

I, j

∈

with the index set

{

, . . . , n

}

identifying the depth and the index set

{

, . . . , m

}

identifying machines of the layer

We call the parent machine

j
i

(

∈

∪

) the host machine of its child machines

∈

∈ P

(

)

. Further, we call the children

the clients of

j
i

. More-

over, we assume

= 0

and call the machine

the root host and the machines

(

∈

)

the applications.

In the context of a TCG-enabled PC, the root host is the basic hardware includ-

ing memory, CPU, TPM, and CRTM (Core Root of Trust Measurement) (see Section
7.1.3),

could be a virtualisation layer like a microkernel-based architecture [57, 69]

or a Virtual Machine Monitor (VMM), e.g., the IBM hypervisor sHype [81],

(

)

∈

the set of operating systems, and

(

)

∈

the set of applications.

We do not consider more complex certificates such as X.509 certificates, but assume that an appropriate

mapping exists.

pen_TC Deliverable 05.1

122

OpenTC D05.1 – Basic Security Services

0
0

...

root host

applications

Figure 7.1: The basic system architecture including layers of machines.

For simplicity, in the sequel we only consider the sequences

(

· · ·

)

of machines where only machine

is the client of the machine

−

. In this sim-

plified model, however, every platform has only one application

As we will see in more detail later, the trustworthiness of a certain machine in

this model depends on the “trustworthiness” of its underlying hosts up to the root host
which is assumed to be trusted.

Properties:

We define a property

of a machine

to be a certain aspect of that

machine. We denote a set of properties with

, and an encoding/value of a property

(e.g., an integer) with

. We also call

a property.

Examples of properties are abstract descriptions of the machine’s behaviour (e.g.,

subsets of views of the machine’s I/O behaviour), the fact that a machine has been
evaluated according to a specific Common Criteria protection profile, or a real-time
capability.

Match Function:

We define the function

ind

←

match

(

)

to return

true

only

if the machine

has the property

and otherwise

false

. See Section 7.1.6 for a

discussion about possible realisations of the

match

()

algorithm.

Roles

In this section, we consider the main parties involved in our trusted computing model.

Owner: The owner

of a platform

is an entity that defines the allowed con-

figurations

of the underlying platform. Note that this also includes certain

changes to the platform’s configuration

. In practice, these changes are patch-

es/updates. Typical examples are an enterprise represented by an administrator
or an end-user owning a personal platform.

User: The user

of a computing platform

is an entity interacting with

under

the platform’s security policy

. Examples are employees using enterprise-

owned hardware. User and owner might also be identical.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

123

Verifier: The verifier

is interested in verifying a certain property of a platform. This

party can be a local user or a remote challenger.

Provider: A provider denoted

is any party that provides services or content.

Attestor: The attestor

is a machine that reports about a client machine in response

to the request of a verifying machine

. More concretely,

may confirm a

certain statement or quantity of this machine. In this context, a property attester

determines (attests) the property of a client machine, and a binary attester

determines/measures the configuration of a client machine according to a certain
metric. An attestor can be local, i.e., located on the platform

, or it can be

distributed.

An example of an attestor is a Trusted Platform Module (TPM) (see Section
7.1.3), or a combination of a TPM and a software component hosting a machine
to be attested.

Attested machine: This is a machine that has been subject to the attestation proce-

dure, i.e., attested by the attestor

. We denote this machine with

Certificate issuer: The issuer, denoted by

, is the party who certifies mappings be-

tween properties and configurations. We call such certificate, linking a property

to a configuration

, a property-certificate that is represented by the signature

, i.e.,

←

Sign

(

)

Trust Relations

We call a machine

, representing a system component, trusted by the party

when

can violate the security requirements of

. If a machine is trusted by all involved

parties we call it fully trusted. The attestor is a security-critical component which has
to fulfil certain security requirements. Independently of the concrete realisation, the at-
tested machine (or its user/owner) has to trust the attestor not to leak information about
its configuration, e.g., in order to guarantee privacy and unlinkability requirements.
The verifier, however, needs to trust in the correctness and integrity of the attestor (e.g.,
in order to guarantee certain security aspects). Therefore, in our model the root host

is fully trusted.

A trusted computing base (TCB) for a client machine

j
i

consists of all machines

that are security-relevant for a correct execution of

j
i

. We denote the TCB of machine

j
i

with

TCB

j
i

. Note that the security-relevant machines for

j
i

include all hosts

down to the root host, together with their TCB.

Reconsider, for instance, the hypervisor example discussed in the platform defi-

nition (Section 7.1.2): the hypervisor

executes several operating systems in iso-

lated domains

(

)

. Thus, the TCB of an application

that is client of

T CB

0
3

}

: the hardware

, the hypervisor

, the client

operating system

, and the security management compartment (domain 0)

ex-

ecuted in parallel to the client operating system.

Since we assumed in the definition of a platform (see Section 7.1.2) a platform

model including only one machine per layer (and thus providing only one application

), the TCB of

T CB

host

(

)

, n

≥

}

In practice, a TCB consists of software and hardware components, and the common

assumption is that it cannot be manipulated. This assumption translates into different
assumptions on tamper-resistance regarding software and hardware: For instance in

pen_TC Deliverable 05.1

124

OpenTC D05.1 – Basic Security Services

the context of TCG the hardware component Trusted Platform Module (TPM) [102]
and the software component Trusted Software Stack (TSS) [93] are both trusted, how-
ever, one usually relies more on the tamper-resistance of the TPM. Hence, in many
applications, the TPM is fully trusted whereas the TSS is only trusted by the platform.

As mentioned before, the trustworthiness of a certain machine in our model de-

pends on the trustworthiness of its underlying hosts up to the root host which is as-
sumed to be trusted.

Further, certificate issuing parties like

are usually assumed to be fully trusted,

i.e., by both attestor and verifiers.

Attestation

The main parties involved in the attestation procedure are a verifier

and an attestor

. The machine to be attested is denoted by

, where

receives the result

true

only

fulfils a certain requirement

which is the common input to the protocol. We

denote this protocol with

(

ind

;

−

)

←

Attest

(

−

;

∗

)

In this context, we use the term binary attestation if the verifier requires the machine to
have a certain configuration

, and the term property attestation if the verifier requires

the machine

to have a certain property

Since the behaviour of a machine

depends on its configuration and the con-

figuration of its TCB, i.e.,

. . .

−

}

, all machines

. . .

}

have to be

attested in a chain of attestations.

The chain of attestations starts with the root host

(that is fully trusted and thus does not have to be attested) attesting the machine

, which then becomes the new attestor to attest

and so forth. The attestation

chain ends with the application

attested by machine

−

The attestation of all machines of a platform

. . .

}

is then consid-

ered as an attestation of the whole platform

Sealing

Sealing is the protocol between a provider

, an attestor

, and a machine

where

receives the information

only if

fulfils a certain requirement

otherwise an empty string

. This is denoted with

(

)

. We define the sealing protocol

as follows

(

−

;

−

: (

)

←

Seal

(

, R

;

, R

;

−

)

where the main inputs of

and

are the data

and the machine

respectively.

Similar to the attestation algorithm described in Section 7.1.2, the provider

has

to perform a chain of sealings based on the machines

. . .

−

}

before it can

perform a sealing protocol with the application

of platform

7.1.3

Main Aspects

In this section, we briefly review the main functionalities, including binary attestation
and binary sealing, of the specifications version 1.1b [96] and 1.2 [102] of the Trusted
Computing Group (TCG).

Note that the function

init

()

allows hosts to overwrite the configuration and thus the behaviour of a

client machine.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

125

TCG Components

The main components of the TCG proposal are the hardware component Trusted Plat-
form Module (TPM), a kind of (protected) pre-BIOS

called the Core Root of Trust

for Measurement (CRTM), and a support software called Trusted Software Stack (TSS)
which performs various functions like communicating with the rest of the platform or
with other platforms.

Trusted Platform Module (TPM)

A TPM is the main component of the specifica-

tion providing an RSA key generation algorithm, cryptographic functions like RSA en-
cryption/decryption, a secure random number generator, non-volatile tamper-resistant
storage, and the hash function SHA-1

TPMs can be compared to integrated smart-cards containing a CPU, some mem-

ory, and special applications. The assumption is that the chip is tamper-resistant and
mounted on (or integrated in) the motherboard. The main chip contains a special se-
curity controller with some internal, non-volatile ROM for the firmware, non-volatile
EEPROM for the data and RAM. Furthermore, it contains a cryptographic engine for
accelerating encryption and decryption processes, a hash accelerator and a random
number generator (needed to generate secure cryptographic keys). Figure 7.2 shows
the main architecture of the chip.

ROM

EEPROM

Platform

Configuration

Trusted Platform Module (TPM)

Cryptographic

Engine

RAM

Controller

Number

Generator

Low Pin Count

(LPC−I/O)

Registers (PCRs)

Input/Ooutput

Random

Figure 7.2: Simplified architecture of the TPM

The TPM uses the synchronous Low Pin Count-I/O-Interface (LPC-I/O) on the

motherboard to communicate with the host PC. The data transmission is done through
a FIFO inside the TPM LPC-I/O interface which can be accessed from both sides. The
connection of the TPM to the motherboard is illustrated in Figure 7.3. The protocols
defining the order of commands and transmissions between the host and the TPM are
a challenge-and-response dialogue, i.e., after every challenge the host waits for the
corresponding response from the TPM before it sends a new request.

Due to the physical properties of the LPC interface, checksums for block protection

are not required. To configure the chip, configuration registers can be used to enable or

Basic I/O System

SHA-1 [63] generates 160-bit hash values from an input of (almost) arbitrary size. One of the stated

security goals for SHA-1 was that finding any collision must take

units of time. Recently, Wang et. al.

[106] described an algorithm to find such collisions in time

, see also [55]. Though attacking SHA-1

would be challenging, SHA-1 clearly has failed its stated security goals. In contrast to some applications,
full collision resistance is essential in Trusted Computing. Hence, we anticipate revised specifications to
switch to another hash function.

pen_TC Deliverable 05.1

126

OpenTC D05.1 – Basic Security Services

Northbridge

Southbridge

Main

Memory

Super−I/O

Trusted Platform

Module (TPM)

SER

PAR

PS/2

PCI

USB

AC’97

HOST−PC

CPU

IDE

Figure 7.3: Integration of the TPM into a PC platform.

disable functions of the TPM chip, and to configure the I/O addresses for communica-
tion with the chip. Data registers are used for data transfer between the host PC and the
TPM chip; status and command registers are used to audit and control the performed
operations. Depending on the used TPM chip, different layers may exist above the
hardware to transport control information, vendor-specific information, or application
data (e.g., data to be signed or commands to generate keys).

We can abstractly describe a TPM with the tuple

(

SRK

)

: the endorsement

key

, an encryption key that uniquely identifies each TPM; the Storage Root Key

(

SRK

) or Root of Trust for Storage (RTS), uniquely created inside the TPM. Its private

part never leaves the TPM and is used to encrypt all other keys created by the TPM;
the TPM state

contains further security-critical data shielded by the TPM.

Moreover, the TPM provides a set of registers called Platform Configuration Regis-

ters (PCR) that can store hash values. The hardware only accepts PCR register changes
in the following form:

PCR

←

SHA1(

PCR

)

, with the old register value

PCR

the new register value

PCR

, and the input

. This process is called extending of a

PCR.

A TPM can create different types of asymmetric keys:

•

Migrateable keys (MK): Migrateable keys are those cryptographic encryption
keys that are only trusted by the party who generates them (e.g. the user of
the platform). A third party has no guarantee that such a key has indeed been
generated on a TPM.

•

Non-migrateable keys (NMK): Contrary to a migrateable key, a non-migrateable
encryption key is guaranteed to reside in a TPM-shielded location. A TPM can
create a certificate stating that a key is an NMK.

•

Certified-migrateable keys (CMK): Introduced in version 1.2 of the TCG specifi-
cation, this type of encryption key allows a more flexible key handling. Decisions
to migrate and the migration itself is delegated to two trusted entities, chosen
by the owner of the TPM upon creation of the CMK with a separate command

TPM CMK CreateKey

: The Migration-Selection Authority (MSA) controls the

migration of the key, but does not handle the migrated key itself. In contrast, the
Migration Authority (MA) handles the migration of the key: To migrate a CMK
to another platform, the TPM command

TPM CMK CreateBlob

expects a cer-

tificate of an MA stating that the key to be migrated can be transferred to another
destination. Furthermore, the certificate of the CMK that the owner/user uses to
prove that it was really created by a TPM contains information about the identity
of the MA resp. MSA.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

127

•

Attestation identity keys (AIK): These non-migrateable signature keys provide
pseudonymity resp. anonymity of platforms including a TPM. AIKs are locally
created by the TPM. The public part is certified by a Privacy Certification Au-
thority (Privacy CA) stating that this signature key is really under control of a
secure TPM. In order to overcome the problem that this party can link transac-
tions to a certain platform, version 1.2 of the TCG specification defines a cryp-
tographic protocol called Direct Anonymous Attestation DAA [13], eliminating
the Privacy CA.

TPM signatures:

The TPM can create a TPM signature denoted by

TPM

. There

are two possible ways of generating

TPM

. The first one is a DAA signature. The

second way is a DAA signature on an arbitrary attestation signing key

AIK

together

with an ordinary signature under the key

AIK

. For simplicity, we do not distinguish

these two cases, and denote the private signing key used to create TPM signatures

TPM

←

Sign

TPM

(

)

on a message

with

TPM

and the corresponding public

verification key used to verify

TPM

with

TPM

TCG Functionality

Based on this functionality, the TCG specification defines four mechanisms called in-
tegrity measurement, attestation, sealing, and maintenance which are explained briefly
in the following. Note that our descriptions focus on the PC-specific realisation of the
TCG specification [103].

Integrity measurement:

Integrity measurement is done during the boot process by

computing a cryptographic hash of the initial platform state. For this purpose, the
CRTM computes a hash of (“measures”) the code and parameters of the BIOS and ex-
tends the first PCR register

by this result before passing control to the BIOS. Similarly,

the enhanced BIOS has to measure the master boot record (MBR) of the boot device
before passing control to the boot loader. A chain of trust is established if the boot
loader also measures the loaded code (e.g., the operating system) before it transfers
control.

This chain strongly relies on explicit security assumptions about the CRTM. The

PCR values

PCR

, . . . ,

PCR

provide evidence of the system’s state after boot. We

call this state the platform’s configuration, i.e.,

:= (

PCR

, . . . ,

PCR

)

Note that the TCG specification does not define the code that has to be measured

by the boot loader. Thus, different strategies can be realised: The boot loader can
measure the whole system state including operating system, applications, and data.
Alternatively, the boot loader can only measure the operating system kernel which may
itself provide mechanisms to attests single applications.

Attestation:

The TCG attestation protocol is used to give a verifier

assurance about

the platform configuration

. To guarantee integrity and freshness, the TPM must sign

this value and a fresh nonce

provided by the verifier with an Attestation Identity Key

(AIK). The challenger can then decide whether the attested platform is in configuration

or not. For increased flexibility, the attestation protocol allows the attested machine

to consider only certain PCR values (e.g.,

P CR

, P CR

, and

P CR

) that can be

During a reset, all PCR registers are initialised with zero.

pen_TC Deliverable 05.1

128

OpenTC D05.1 – Basic Security Services

defined by a binary vector. Section 7.1.5 describes the TCG approach to attestation in
more detail.

Sealing:

Data

can be cryptographically bound to a certain platform configura-

tion

by using the

TPM Seal

command. We denote this command abstractly with

(

)

←

Seal

(

)

meaning that

is sealed for the configuration

. The

TPM Unseal

command releases the decrypted data only if for the current configura-

tion

′

it holds that

′

, i.e.,

Unseal

((

)

⇔

((

)

←

Seal

(

)

∧

(

′

))

Thus sealing allows software, e.g., an operating system, to bind secrets like a master

encryption key to its current configuration and therefore prevents that security mecha-
nisms can be bypassed by rebooting a maliciously modified platform configuration.

Maintenance:

The maintenance functions can be used to migrate the SRK to another

TPM: The TPM owner can encrypt the SRK under a public key of the TPM vendor
using the

TPM CreateMaintenanceArchive

command. To finish the migration

in case of a hardware error, the TPM vendor can decrypt the SRK and integrate it into
another TPM.

Unfortunately the maintenance function is only optional and, to our knowledge,

not implemented by currently available TPMs. Furthermore, the maintenance function
works only for TPMs of the same vendor.

7.1.4

TCG Model

We introduce an abstract model for the basic functionalities provided by TCG-
compliant platforms as illustrated in Figure 7.4. It consists of several state transition
machines: the machine

represents a client machine to be attested, while the host

is the attestor

. Note that in the TCG model,

represent the software com-

ponents and hardware devices of a computing platform, while

represents, e.g., the

TPM, the CRTM, and the CPU. The third machine

represents a (remote) verifier, and

machine

the local user.

secure channel

insecure channel

platform

data(D)

send(m)

receive(m)

seal(hash(C ),D)

attest(hash(C ))

boot(C ’)

exec(C )

Figure 7.4: Abstract Model of the TCG functionality

The machines are connected by insecure and secure (authentic, integer and con-

fidential) directed communication channels:

can communicate with

using an

insecure input channel

send

()

and an insecure output channel

receive

()

, which are

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

129

used for common communication. The attestor offers an insecure initialisation channel

boot

()

to the user

It accepts a configuration

:= (

∆)

which is locally

stored and then used to execute

on top of

using the channel

exec

()

. This en-

sures that the attestor always knows the configuration of

. Compared to the boot

example discussed in Section 7.1.3,

represents the hashed chain of the basic mod-

ules (i.e., BIOS, boot-loader, and operating system) at the time the operating system is
bootstrapped.

A secure output channel

attest

()

returns to

the hash value

Hash

(

)

of the

configuration

. A secure input channel of

called

seal

()

receives data

and

a hash of the desired configuration

′

. If

is equal to

′

, the attestor

sends

using the secure output channel

data

()

Assumptions

The functionality mentioned above is provided under the following assumptions:

1. The platform configuration cannot be overwritten after measurement, i.e., after

the hash values are computed and securely stored in TPM. This is an important
assumption, because the attestor only makes statements about the initial state of

. If malicious modifications would be possible after measurement, verifiers

could not rely on the information provided by the attestor. In our model this
assumption is fulfilled since

’s configuration can only be modified by the ma-

chine itself and the attestor using the

init

()

channel (which models a reboot).

Unfortunately, currently available operating systems such as Windows or Linux
can easily be modified, e.g., by exploiting security bugs or by changing memory
which has been swapped to a hard disk.

2. Given the hash value representing

’s configuration, the verifier can determine

whether the platform configuration

is trustworthy. In our model, this assump-

tion is fulfilled since we assumed that the verifier can derive the machine’s be-
haviour from

(

∆)

. The trusted computing base of today’s operating systems

is very complex, which makes it very difficult, if not impossible, to determine
their trustworthiness.

3. The secure channels can be established. This assumption is fulfilled using three

different mechanisms:

(a) The channels between hardware components (e.g., between TPM and CPU)

are assumed to be secure since both components are integrated on the same
hardware.

(b) The communication between attestor and verifier is secured based on a

public key infrastructure (PKI) [102].

between machines, e.g., between attestor and attested machine.

Hence, a secure operating systems is required that (i) effectively prevents unautho-

rised modifications, that (ii) is small enough to allow an evaluation of its trustworthi-
ness, and that (iii) provides a secure inter process communication (IPC) mechanism.

The reason why the channel

boot

()

is modelled as insecure is that in practice even local users cannot be

sure whether a secure operating system has been loaded.

Experience shows that this assumption does not hold for the currently available TPM platforms, since it

is possible to observe resp. modify the communication between CPU and TPM.

pen_TC Deliverable 05.1

130

OpenTC D05.1 – Basic Security Services

Config

Validator

Component

Directories

Measurements

(TPM_quote)

Config

descriptors

Verifier Machine

Directory

Servers

Challenge

Platform

Config

Assessment

Yes/No

Verified

Machine

Verified

Platform

Measurement (TPM)

Figure 7.5: TCG Attestation Architecture

However, such a secure operating system can be efficiently provided by security kernels
based on micro-kernel architectures [69, 77, 30].

7.1.5

The TCG Approach: Binary Attestation

The TCG specifications [96, 97] define mechanisms for a TPM-enabled platform to
reliably “report its current hardware and software configuration to a local or remote
challenger” [7]. This ‘binary attestation’ (based on measurements of binary executa-
bles) is based on (1) the platform building a chain of trust from the hardware up to the
operating system (and, potentially, including applications) by measuring integrity met-
rics of modules and storing them in the TPM, and (2) the TPM being able to report on
these metrics in an authenticated way. A verifier obtaining such authenticated metrics
can then match them against the values of a known configuration and decide whether
the verified machine meets her security requirements or not.

Binary Attestation Architecture

Figure 7.5 represents a modularised architecture

corresponding to the TCG concept of binary attestation.

The following entities are involved in the attestation and verification process:

Verified Machine A machine that has a Trusted Platform Module (TPM) and a com-

puting base that may execute untrusted code.

Verifier Machine The machine of the verifier. All modules on this machine are known

and trusted by the verifier.

Directory Servers Servers that provide additional authenticated information about

components in signed component directories. Examples include Tripwire di-
rectories

www.tripwire.com

We make certain definitions to speak about this architecture:

Verified Platform The computing environment on the verified machine.

TPM The Trusted Platform Module (TPM) on the verified machine. It is used by the

verified platform to store measurements of code executed in the verified platform.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

131

Configuration Validator The module that obtains a (TPM-authenticated) measure-

ment and reconstructs the platform’s configuration. To do this, it uses a configu-
ration log file (see Section 7.1.5) additionally provided by the verified platform
as well as configuration descriptors certified in Component Directories.

Configuration Assessment Given a configuration, the assessment determines whether

this configuration satisfies the requirements of the verifier. This assessment typi-
cally involves matching the configuration against a set of configurations allowed
by the verifier.

Component Directory A signed repository of information related to components. An

example of a component directory is a software vendor’s database providing hash
values and associated descriptions of its latest products.

Binary Attestation and Verification Mechanisms

We now explain the interactions

that implement binary attestation. The ability of the TPM reliably to report on the
verified platform’s computing environment follows from the TPM-enabled measure-
ment and reporting. Our description in the following paragraphs focuses on the PC-
platform [7].

The measurement and storage of integrity metrics is started by the BIOS Boot

Block (a special part of the BIOS which is believed to be untampered) measuring itself
and storing the measurements in a TPM PCR (Platform Configuration Register) before
passing control to the BIOS. In the same way, the BIOS then measures option ROMs
and the Boot Loader and records these measurements in a TPM PCR before passing
control to the Boot Loader. The process continues as the Boot Loader measures and
stores integrity metrics of the OS before executing it, the OS in turn measuring and
storing integrity metrics of additionally loaded OS components before their execution.
If support by the OS is provided, applications can also be measured before being exe-
cuted.

The measurement and reporting processes are depicted in a simplified manner in

Figure 7.6, in which

represents the cryptographic hash function SHA-1. During ini-

tialisation, various PCRs as well as a configuration log file (stored on the platform) are
initialised; this log file keeps track of additional information such as descriptions or file
paths of loaded components [84] ; its integrity need not be explicitly protected by the
TPM. During subsequent measurement of components, this log file is extended, while
metrics (hash values) of the executables are stored in the TPM using the

tpm extend

method replacing the contents of the appropriate PCR register with the hash of the old
contents and the new metrics. We do not discuss which metrics are stored in which
PCR; it suffices to say that metrics of loaded components are reliably stored in the
TPM.

When a remote verifier wants to assess the security of the verified platform, she

sends a challenge

to the platform. The platform uses this challenge to query (with a

tpm quote

command) the TPM for the value of the PCRs. The TPM responds with a

signed message

Sign

AIK

(

−−−→

PCR

, c

)

containing the PCR values and the challenge

. The

platform returns this signed quote to the challenger (verifier) together with information
from the log file needed by the verifier to reconstruct the verified platform’s configura-
tion; the verifier can then decide whether this configuration is acceptable.

The TCG specifications specify a quote over specific PCR values rather than the full set; for simplicity,

we assume in this discussion that a quote is always given over all PCR values.

pen_TC Deliverable 05.1

132

OpenTC D05.1 – Basic Security Services

Platform

TPM

Initialisation:

log

{}

PCR

:= 0

Measure Components:

measure

desc

exec

log

(

desc

exec

)

(

exec

)

−

tpm extend(

)

−−−−−−−−−−−−−−−

→

PCR

(

PCR

, m

)

Report Measurements:

−

tpm quote(c

AIK

)

−−−−−−−−−−−−−−−

→

←

−

Sign

AIK

(

−

−−→

PCR

, c

)

−−−−−−−−−−−− −

Figure 7.6: TPM-Enabled Measurement and Reporting Process

The key used for signing the quote,

AIK

, is an “Attestation Identity Key” of the

TPM; as a TPM may have multiple

AIK

s, the key or its identifier has to be specified

in the

tpm quote

request. An Attestation Identity Key is bound to a specific TPM;

its public part is certified in an Attestation Identity Key Certificate by a Privacy-CA as
belonging to a valid TPM.

The verifier of a quote signed with a (correctly certified)

AIK

believes that the quote was produced by a valid TPM, more specifically, by the

unique TPM owning that

AIK

. This belief is, of course, based on the assumption

that the TPM is not easily subject to hardware attacks and that effective revocation
mechanisms are in place dealing with compromised keys.

Note that the above measurement process does not prohibit execution of untrusted

code, it only guarantees that the measurement of such code will be securely stored in
the TPM. Thus, if malicious code is executed, the integrity of the platform may be
destroyed; however, the presence of an untrusted (or simply unknown) component will
be reflected by the TPM quotes not matching the ‘correct’ or ‘expected’ values.

Deficiencies of TCG Attestation and Sealing

While the attestation and the sealing mechanisms provided by the TCG allow many
meaningful applications (see, e.g., [80, 31, 56, 84]), the naive use of the platform con-
figuration (e.g., to bind short-term data to platforms or to determine the trustworthiness
of applications) has some important drawbacks:

•

Discrimination. Sealing and attestation have the potential to isolate “alternative”

In the remainder of this paper, we will always assume that the verifier of a quote is in possession of, or

can obtain, the appropriate certificate certifying the

AIK

but we will not explicitly represent the transport of

such certificate in protocols.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

133

software products (e.g., OpenOffice

or WINE

and operating systems such as

Linux), and it would be more difficult (if not impossible) for them to enter the
market. It is easy to imagine a situation where global players such as content
providers and large operating system vendors collaborate and exclude specific
operating systems as well as applications. This barrier to entry effectively un-
dermines competition and prevents the self-regulating mechanisms of an open
market.

Moreover, sealing can have negative consequences since application vendors can
bind the application data to their application, making it impossible for alternative
software products to be compatible. With TCG a vendor could prevent OpenOf-
fice from reading Word documents.

•

Complexity.

The number of different platform configurations exponentially

grows with the number of patches, compiler options and software versions. This
makes it hard to keep track of the trustworthiness of a given configuration.

•

Observability. The recipient of the attestation protocol or an observer gets exact
information about the hard- and software configuration of a specific platform.
This makes attacks on such platforms much easier since an adversary does not
need to perform any platform analysis.

•

Scalability. Since the sealing mechanism provided by the TCG hardware binds
encrypted content to a specific system configuration, system updates make the
encrypted content inaccessible. For example, any patch leads to a new configu-
ration and thus to modified PCR values.

7.1.6

Attesting Properties

A more general and flexible solution to the attestation problem is an approach called
property-based attestation [78, 71]. It means that attestation should only determine
whether a platform configuration or an application has a desired property. This avoids
revealing the concrete configuration of software and hardware components. For ex-
ample, it would not matter whether the application was Web-browser

, as long

as both have the same properties. In contrast, the attestation and sealing function pro-
vided by TCG-compliant hardware attests the system configuration of a platform that
was determined at system startup. For (nearly) all practical applications, the verifier
is not really interested in the specific system or application configuration. As we have
argued in Section 7.1.5, this even has a disadvantage due to the multitude of possi-
ble configurations a verifier has to manage. In fact, the challenger is only interested in
whether the attested platform provides the desired properties. Informally, a property, in
this context, describes an aspect of the behaviour of the underlying object (platform/ap-
plication) with respect to certain requirements, e.g., a security-related requirement (see
Section 7.1.2). In general, properties for different abstraction levels are imaginable.
For instance, a platform property may, e.g., state that a platform is privacy-preserving,
i.e., it has built-in measures conform to the privacy laws, or that the platform provides
isolation, i.e., strictly separating processes from each other, or it provides Multi-Level
Security (MLS) and so forth.

www.openoffice.org

www.winehq.org

pen_TC Deliverable 05.1

134

OpenTC D05.1 – Basic Security Services

The question whether there is a correct or useful property set depends strongly on

the underlying use case and its requirements. Attesting properties has the advantage
that different platforms with different components may have different configurations
while they all offer the same properties and consequently fulfil the same requirements.
As mentioned in Section 7.1.2, we consider the desired properties of an application as
a certain input/output behaviour.

The idea of property-based attestation, as presented in this contribution, was pro-

posed in [78], and later in [71]. Other related work is considered in Section 2.4.
Whereas [71] proposes a high-level protocol for property-based attestation, [78] pro-
poses and discusses several protocols and mechanisms that differ in their trust models,
efficiency and the functionalities offered by the trusted components. In particular, [78]
discusses how the Trusted Software Stack (TSS), the TPM library proposed by the
TCG, can provide a property-based attestation protocol based on the existing TC hard-
ware without a need to change the underlying trust model. A cryptographic protocol
realising the approach outlined in Section 7.1.10 was proposed in [19].

Requirements

In this section, we informally consider the main security requirements that ideal attes-
tation and sealing mechanisms should fulfil.

1. Security: The attestor only attests properties provided by the platform resp. ap-

plication. More precisely, if the outcome of the attestation for a machine

on a

certain property

is true (i.e., accepted by the verifier) then the attested machine

matches this property, i.e., the outcome of the

match

(

)

is true.

2. Privacy/non-discrimination: The attestation should neither reveal any informa-

tion about the platform/application configuration (beyond that it falls under a
certain property) nor should it be able to favour selected configurations.

3. Unlinkability: It should be infeasible to link different attestation sessions of the

same attestor.

4. Availability: When modifying a platform configuration without changing the

provided properties, access to sealed data should still be possible.

5. Reduced Complexity: Security enhancements to the platform should not be

costly.

A further requirement, which we do not consider in this contribution, is account-

ability. Although a trusted third party like a certificate issuer has to be trusted by all
participants, it is desirable to detect its misbehaviour.

Ideal World Model

An ideal attestor that fulfils the requirements of an ideal attestation and sealing func-
tionality is capable of determining the set of properties

{

, . . . , p

}

provided

by a system configuration

and to decide whether it has a specific property

. It per-

forms a property-based attestation and property-based sealing mechanism as shown in
Figure 7.7.

Unfortunately, it is in practice difficult, if not impossible, to determine or compare

properties enforced by a platform configuration. Today, not even content providers are

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

135

secure channel

insecure channel

data(D)

seal(p,D)

attest(p)

send(m)

receive(m)

exec(C )

boot(C )

Figure 7.7: The ideal model of a property-based attestation function

able to formally specify the demanded properties; however, this would be necessary to
enable the use of proof-carrying code or formal analysis.

Property Detection

Before the attestor can make statements about a machine, the appropriate properties
have to be determined using the function

match

()

which itself can do this directly or

indirectly. We group mechanisms that determine the properties of a machine into three
categories:

•

Code control: The property attestor is trusted to enforce that a machine can
only behave as expected. In our machine model this means that the attestor

compares the I/O behaviour of

with that defined by the desired property

An example would be to use SELinux as a reference monitor and to attest both
SELinux and the enforced security policy, as described in [61].

•

Code analysis: The property attestor directly analyses the code of the machine
to derive properties. Alternatively, it verifies whether the machine provides the
claimed properties. In our machine model, the attestor

has to be the host

and to decide based on

(

∆)

, whether

match

(

) =

true

holds.

Practical examples in this context are proof-carrying code [64, 65] and semantic
code analysis [35].

•

Delegation: Instead of determining properties directly, the property attestor can
also prove that another party has certified the presence of the desired properties.
Obviously, this third party has to be trusted by both the attested platform and the
verifier. A practical example in this context are property certificates issued by
a certificate issuer: The matching algorithm returns

true

if a property certificate

exists and was issued by a third party who is trusted by

Code control methods and code analysis (cf. semantic remote attestation, [35]) are

out of the scope of this report. We elaborate on the delegation idea in Section 7.1.7
where we present several concrete solutions.

7.1.7

Delegation

The basic idea of property detection through delegation was shortly described in Sec-
tion 7.1.6. In this section we are going to focus on some concrete delegation-based

pen_TC Deliverable 05.1

136

OpenTC D05.1 – Basic Security Services

solutions. The main reason is that the delegation-based principle is well-suited to the
TCG trust model and the related infrastructure that already requires trust in third parties
(e.g., Privacy CA, certificate issuer in the context of DAA, or Migration Authority for
migrateable keys.

In the following, hybrid attestation means a two-level chain of attestations, where

the first attestation is based on binary configurations and the second one based on prop-
erties. Since we assume in our model that applications are attested by the operating
system, we now focus on the question how the translation from configurations into
properties based on certificates can be realised on a low architecture level (ideally by
the root host

For this, the ideal model is extended with a trusted third party (e.g., a certificate

issuer

) who attests that a given platform configuration

fulfils a desired property

Thus, we replace the automatic property derivation based on configurations, required
for the ideal attestor (see Section 7.1.6), by a property certificate

issued by

This relaxed model is shown in Figure 7.8.

secure channel

insecure channel

data(D)

send(m)

receive(m)

cert

attest(p)

seal(p,D)

exec(C )

boot(C )

Figure 7.8: General architecture of a property attestor

based on a binary attestor

and a certificate issuer

that translates configurations into properties

The certificate is simply a signature of

which we call property certificate. Note

that

confirms the correctness of the correspondence between the platform configura-

tion and certain properties according to defined criteria. However, following common
practice such organisations are only liable for intentional misbehaviour and not for
undetected weaknesses (compare with safety and security tests or common criteria).
Parties like

are fully trusted (i.e., by the attestor and the verifier), since both have to

assume that

certifies only configurations that really have the attested property.

The following solutions are based on [78] and [53] that propose several possible re-

alisations of property attestation using delegation. All proposed solutions realise hybrid
attestation but they differ in their functional requirements as well as in the underlying
trust model: Some of them require extensions to the existing TC hardware (TPM), oth-
ers propose to implement the required extensions by means of a fully trusted software,
or to reuse the existing TPM implementations while keeping the same trust model as
the current TCG specification.

Hardware-based Certificate Verification

This solution adds a property certificate verification procedure to the TPM function-
ality. Any party that the verifier trusts may issue property certificates. The following

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

137

protocol defines property attestation in this framework:

(

ind

;

TPM

−

)

←

Attest

(

−

;

TPM

;

∗

, σ

, N

)

The attestor is in this case the TPM with a signing key pair

(

TPM

)

where the signature verification key

TPM

can be seen as a pseudonym. The com-

mon input to the protocol is a public key

of the certification issuer

, a

property-certificate

Sign

(

′

)

, the desired property

and a nonce

. The input of the attestor (here the TPM) is the configuration

. The output

to the verifier is

ind

In the above protocol, the TPM evaluates the property certificate

in order to

verify whether

′

and

′

. If so, it returns

TPM

Sign

TPM

(

)

which

verifies. Note that in the concrete realisation of the above protocol,

gen-

erates the common input

. Fulfilling the unlinkability requirement should not be

problematic since CA-based pseudonyms, or the DAA protocol, can hide the signature
key

TPM

. A new TPM command can efficiently be implemented (see [53]).

The use of certificates that guarantee platform properties has the known problem of

public key infrastructures such as certificate revocation, e.g., when new bugs become
public that violate certified properties. Allowing to revoke a property certificate (revo-
cability requirement) thus requires additional TPM support ensuring that verifiers can
recognise if a revoked property certificate was used. A simple, but still unsatisfactory
solution is the use of short validity periods of property certificates.

Group Signatures

A group signature scheme allows a group member to sign messages anonymously on
behalf of the group. In case of a dispute, the identity of a signature’s originator can
be revealed, but only by a designated entity [18]. In our framework, the public group
signature key

P S

represents a property

while the corresponding private keys

(

ps
cs

, . . . ,

ps
cs

)

generated by a Trusted Third Party (TTP) represent different con-

figurations

(

= 1

· · ·

, n

) providing the same property

. Since the verifier of a

group signature cannot decide which secret key has been used to generate the signature,
it does not get information about the configuration of the machine to be attested. This
satisfies the non-discrimination and unlinkability requirements.

The abstract description of the protocol is as follows. It consists of two phases, the

issue phase and the attestation phase. In the issue phase, a

generates the signature

keys

ps
cs

, seals them under

and publishes the resulting blobs

[

ps
cs

]

(

)

that

can only be unsealed by TPMs of type

under configuration

The protocol for the attestation phase is defined as follows:

(

ind

−

)

←

Attest

(

−

;

∗

)

The common input is the property

and the public group key

. The attestor

inputs the configuration

. The output to

ind

More concretely, in the protocol

chooses a nonce

and sends it to

(more

concretely

host

(

)

sends the signature

Sign

(

)

to the verifier who

verifies it using the public group signature key

. If

trusts

and the TPM, it

concludes that the user platform indeed provides

Some group signature schemes [6] allow a designated entity to exclude group mem-

bers, thus selected (e.g., insecure) configurations can be revoked (revocability require-
ment). They also allow the designated entity to add new group members and thus to

pen_TC Deliverable 05.1

138

OpenTC D05.1 – Basic Security Services

add new compatible configurations (availability requirement). Users of the machine

can decide which group signature key they load onto their machine (and thus which

property the platform can attest), therefore also the privacy requirement is fulfilled.

Trusted Software Service

A software-only solution avoids the need for modifications of the TPM hardware. For
example, a separate trusted software service might translate attestation requests into
configurations. However, online services are often performance critical. A way to
solve this problem is to enhance the existing TPM function with a Trusted Attestation
Service (TAS), a fully trusted software service that is part of the attestor.

The trust model of this solution requires the TAS and consequently other machines

that host the TAS (e.g., operating system) to be fully trusted (i.e., by both the veri-
fier and the platform owner/user). Note that this trust could be established by binary
attestation of the TAS.

In the following, it is shown how a TAS could be implemented using a verification

proxy.

7.1.8

Property Attestation

Property attestation addresses the privacy, openness and scalability problems associ-
ated with binary attestation. With property attestation, a verifier is convinced of high-
level security properties of a remote platform without receiving the remote platform’s
configuration information. Examples of security properties are the absence of certain
vulnerabilities or the ability to enforce certain policies; security properties also include
privacy and availability statements. The SuSe

www.suse.com

common criteria evalu-

ated Linux enterprise edition can prove that it satisfies Assurance Level EAL2+ for the
Controlled Access Protection Profile. A server farm should be able to assure a verifier
that it has a high-probability of 24x7 availability. A enterprise can certify that a given
set of files belong to it’s base installation (while others do not).

High-level View of Property Attestation

Figure 7.9 depicts property-based attesta-

tion at a high level. The verifier and verified platform engage in a protocol to prove
that the platform satisfies the verifier’s security requirements. If the verifier is satisfied
with the offered properties, they can engage in the exchange of services.

The actual properties offered are determined by a matchmaking process between a

verifier policy and a platform policy. The term policy stands for a collection of static
and/or dynamic security and privacy requirements, trust assumptions and properties:

•

The verifier policy includes the verifier’s property requirements as well as the
trust policy describing which entities she trusts for signing or certifying certain
property-related statements. A verifier may trust a software distributor to state
correct product information in a component directory (e.g., which binaries be-
long to which product), but may not trust the distributor for certifying security
properties about the software. In our architecture in Section 7.1.8, security prop-
erty certification will be performed by property certifiers. In addition to having
a trust policy, a verifier may have a privacy policy specifying, for example, to
whom she wants to disclose security requirements and trust policy contents.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

139

Property Attestation

Services

Platform

Verifier

Platform Policy

Properties

Privacy & Trust Policies

Verifier Policy

Property Requirements

Privacy & Trust Policies

Policy Matchmaking

Figure 7.9: High-Level View of Property Attestation

•

The platform policy includes the properties that can currently be assured by
the platform, as well as privacy and trust policies specifying which information
(properties or configuration) can be disclosed to whom.

The matchmaking and negotiation process between verifier and platform policies can
differ depending on the entities involved. The question is what portions of the lo-
cal policies are communicated? Individuals are often reluctant to reveal their privacy
policies while enterprises are often reluctant to reveal their trust policies and property
requirements. We envision the following scenarios:

B2C If a business platform wants to prove its properties to a consumer, it will reveal

what properties can be offered under what trust policy. The consumer then lo-
cally decides whether this satisfies his requirements. The consumer does not
reveal any information.

C2B If a business verifies a consumer platform, it will send its trust policy while the

consumer platform then proves the corresponding properties.

B2B If a business verifier verifies a business platform, it will reveal its trust policy

while the business platform responds with the properties that can be guaranteed
under this trust policy.

In practice, proving properties and revealing (parts of) policies can be an iterative pro-
cess where parties gradually build up trust as in [85, 86, 111, 112].

In the following sections, we will focus on the C2B scenario with simple privacy

policies: the verified platform’s privacy policy simply forbids that the verifier receives
actual PCR measurements; and the verifier is willing to reveal her trust policy but
not her specific security requirements. The verifier is thus willing to send her trust
policy and the verified platform attests to the properties it can assure under that trust
policy. These assumptions will allow us to illustrate the core concepts of property-
based attestation; a description of a generic matchmaking process for complex privacy
and trust policies is not within the scope of this paper. An example of a more complex
platform privacy policy may be not to attest to any property if the verifier’s trust policy
is too restrictive; e.g., if a verifier’s trust policy specifies trust in only a single software
vendor, then attesting to a high-level property under that restrictive trust policy reveals
that the verified platform is running only software from that vendor.

pen_TC Deliverable 05.1

140

OpenTC D05.1 – Basic Security Services

Verification

Proxy

Verified

Machine

Directory Servers

Verifier

Machine

Figure 7.10: Property Attestation Architecture: Actors and Basic Message Flows

Property Attestation Architecture

Figure 7.10 shows the component architecture

of a property-based attestation system.

New parts of the property-based attestation

architecture are:

Property Certifier An agent that describes (and certifies) which security properties

are associated with which component. Example include manufacturers that cer-
tify properties of their products (such as offering certain services), evaluation
authorities that certify their evaluation results (such as common criteria assur-
ance level for a given protection profile), or enterprises or other owners of the
machines that self-certify the code that they deem acceptable.

Verification Proxy Towards the verified platform, the verification proxy acts as a ver-

ifier of binary attestations; towards the verifier, it acts as the verified platform in
the high-level property-based attestation view of Figure 7.9. When receiving a
platform verification request by the verifier, it challenges the verified machine for
integrity measurements. These measurements are then transformed into a plat-
form configuration through configuration validation, and subsequently into plat-
form properties through property validation. The property validation is based
on property certificates (binding components and configurations to properties)
issued by property certifiers.

Property Verifier This module engages with the property prover in the property-based

attestation exchange. Its requirements are based on the verifier policy (property
requirements and trust policy) that it requires as an input.

Property Attestation Trust Model

We outline certain deployment-dependent secu-

rity assumptions that are made by our design. In section 7.1.10 we show how to guar-
antee that they are satisfied.

The verification proxy is a core component of the design. The verified platform

(or its user/owner) needs to trust in its integrity (correct operation and authenticated
channel) and confidentiality (confidential channel and no information leakage) in order
to guarantee privacy. The verifier needs to trust in the integrity of the verification proxy
in order to believe the properties that the verification proxy outputs. In addition, the
verifier needs to know a verification proxy signature key (public/private key pair) that
are used by the verification proxy to authenticate its verification results.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

141

Figure 7.11: Trust Model for Property Attestation: Entities and Keys (bold identifiers
denote key-pairs)

Figure 7.11 depicts the trust model for property attestation. Each entity is shown to-

gether with the public signature verification keys that it needs to know. Bold identifiers
represent key-pairs of the entity. The arrows in the figure represent trust relations be-
tween entities (or, in fact, trust policies associated with public keys): The Verified Plat-
form owns an attestation identity key

AIK

and knows the verification proxy’s (public)

key

. It trusts the owner of

to protect the confidentiality of its measurements. In

the simplified privacy policy model discussed in

7.1.8, the verification proxy is thus

the single entity to which the verified platform wants to send configuration information.
The Verification Proxy owns its signature key-pair

. Each Component Directory

owns a key-pair

with which it certifies configuration descriptors. Each Property

Certifier

owns a key-pair

with which it certifies properties related to (sets of)

components. The Verifier knows knows the platform identity (public) key

AIK

the platform about which it wants to receive property-based attestation; it trusts that
measurements authenticated with that key correctly represent the configuration of the
platform based on the TPM certified with

AIK

(even though he does not see them).

The verifier also knows

and trusts the integrity of property-based attestations with

that key. The verifier trusts configuration descriptions authenticated with

...

and

property certificates authenticated with

...

7.1.9

Property Attestation Protocols

We now describe the protocol for property-based attestation based on the above trust
model; it is represented in Figure 7.12. The exchange is triggered by the verifier who
requests to receive property attestation about the platform associated with

AIK

. We

name the protocol steps corresponding to the names of basic message flows and com-
ponents in Figure 7.10.

Platform Verification Request The verifier sends a message to the verification proxy

which contains a randomly generated 160-bit challenge (nonce)

, the attestation

identity key

AIK

about which she wants property-based attestation, and her trust

policy

. As mentioned in

7.1.8, we assume that the verifier does not

protect the privacy of her trust policy; we also assume that the verifier receives
all the properties the verified platform can guarantee under this trust policy.

Measurement Request Using an authenticated channel, the verification proxy for-

wards challenge and

AIK

to the verified platform. The platform decides whether

or not to continue based on its policy and trust model. We assume the platform
knows

as the key of a trusted verification proxy and continues by requesting

pen_TC Deliverable 05.1

142

OpenTC D05.1 – Basic Security Services

TPM

Platform

Verification Proxy

Verifier

challenge

←

−

AIK

−−−−−−−−−

−

←

−

auth

(

AIK

)

−−−−−−−−−−−

−

←

−−

AIK

−−−−−−

−

Sign

AIK

(

−−−→

P CR,

)

−−−−−−−−

−

→

−

conf

(

log, qu

)

−−−−−−−−−−−

−

→

verify

log

reconstruct binary config

derive properties

prop

∗

from config

−

auth

(

prop

∗

, c,

AIK

)

−−−−−−−−−

→

verify prop-

erties

prop

∗

Figure 7.12: Property Attestation Protocol

a TPM quote. Note that the challenge used between verification proxy and plat-
form (and TPM) need not be the same as the challenge used between verification
proxy and verifier. Indeed, it is up to the verification proxy alone to judge the
correctness and freshness of the actual TPM quote.

TPM Quote Request/Response The platform requests and receives the

AIK

authenticated quote using the challenge.

Measurements The platform sends the quote and the log-file to the verification proxy

using a confidential channel (described below).

Config Validation The verification proxy can now reconstruct the platform’s configu-

ration using the authenticated metrics (PCR quote), the log file and (potentially)
config descriptors certified by keys within

Property Validation The verification proxy derives properties of the platform’s com-

ponents based on property certificates certified by keys within

Platform Property Status The verification proxy returns an authenticated message

containing the Platform Verification Request and the properties that can be as-
sured. The verifier checks whether this response is authenticated with a key
which her policy considers to belong to a trusted verification proxy. If so, she
trusts that the properties returned can currently be guaranteed by the platform
associated with

AIK

under

Note that the protocol assumes that the security of the verification proxy is guaran-

teed. In addition, we assume that messages from the verification proxy to the platform
and the verifier are authenticated while messages from the platform to the verification

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

143

proxy are kept confidential (denoted by

auth

and

conf

, respectively). How this will be

guaranteed depends on the deployment and will be described in Section 7.1.10.

Note that more complex privacy policies (e.g., the verified platform also protect-

ing which properties can be proved to which verifiers under which trust policy) may
require also authentication by the verifier of the initial request message, as well as
confidentiality protection of the verification proxy’s response to the verifier.

We assume that high-level security properties about a platform can be guaranteed

only if all components on the platform are measured; this assumes that the measure-
ment process as depicted in Figure 7.6 continues up to the application level. Thus the
verification proxy should not attest to any properties unless it can convince itself that
the verified platform’s configuration indeed supports that extended measurement.

7.1.10

Deployment Scenarios

In previous sections, we assumed the existence of a key pair

used by the verification

proxy for authenticating messages as well as the establishment of a confidentiality-
protected channel with the verified platform. Verified platform as well as verifier were
assumed to trust this key to belong to an untampered and correct verification proxy.

In this section, we now outline different deployment scenarios achieving the above

goals. Each scenario enables the verification proxy to establish an authentic channel
and to communicate confidentially with the verified platform and provides guarantees
to the verifier and the owner of the verified platform that the verification proxy is un-
tampered.

Verification Proxy on a Dedicated Machine

The verification proxy can be deployed

on a dedicated TPM-enabled machine and convince other parties (verifier and verified
platform) of its own integrity through binary attestation.

If we assume that there are only a few approved standard configurations of verifier

proxy platforms, we can expect the ‘verification proxy verifier’ (the platform or the
verifier in the property-based attestation) to know a set of acceptable verification proxy

configurations, say

{

−−−→

P CR

, . . . ,

−−−→

P CR

}

. The verification proxy can now prove its

trustworthiness with a TPM quote (using a validly certified

AIK

) attesting to such an

acceptable configuration:

Sign

AIK

(

−−−→

PCR

, c

)

The key used for authentication and key distribution in property attestation protocols
can then either be

AIK

or another key protected by the TPM and which can be

shown to be associated with

AIK

For efficiency reasons, it is recommended that the dedicated machine also stores

recent copies of the directories with certified material (property certificates and com-
ponent certificates).

A special case of this deployment is a verification proxy owned by the owner of

the verified platform itself. E.g., the platform owner is a company, verified platforms
are employee machines, and the verification proxy is the company’s firewall hiding
details of employee machines’ configuration towards company-external property-based
attestation verifiers.

Self-Attestation: Verification Proxy on the Verified Platform

The idea here is to

deploy the verification proxy on the verified platform itself (see Figure 7.13). This

pen_TC Deliverable 05.1

144

OpenTC D05.1 – Basic Security Services

Verification

Proxy

(Compartment)

Verified

Platform

(Compartment)

Verifier

Machine

Property Attestation

Figure 7.13: Deployment of Property Attestation on a Micro-kernel-Enabled Platform

effectively implements a self-verification of the platform. Recent microkernels allow
to execute multiple operating system instances on a single machine [36, 69]. On such
platforms, the TPM can be virtualised such that each compartment has its own vir-
tual TPM [31]. This mechanism can be used to execute two TPM-enabled machines
on the same piece of hardware. The deployment is then essentially identical to the
two-machine deployment. Since the microkernel usually provides services for secure
messaging, authentication and encryption is not needed for messages between the ver-
ification proxy and the platform.

As described in the two-machine case, the verifier is required to verify the integrity

of the verification proxy using binary attestation. In this case, the scope of this verifi-
cation would be the compartment that executes the verification proxy, while the con-
figuration of the compartment executing the platform is not disclosed. This verification
would be based on the services provided by the virtual TPM in the compartment where
the verification proxy is executed.

Cryptographic Proofs

To solve the shortcoming of the TAS approach described in the previous section, it is
sufficient for the verifier to securely verify the presence of a certain property by means
of a cryptographic proof. Since the verifier can check the proof, it does not need to trust
the implementation of the software components anymore. In this model, only the user
of the platform has to trust the software performing the protocol not to leak information
about the platform configuration. The TCG calls the software under this trust model
the Trusted Software Stack (TSS) [93]. The implementation of the following protocol
can be seen as an extension to the TSS.

In the following section we present two possible ways of realising such a property-

based protocol.

Proving Possession of a Valid Property-Certificate

The basic idea of this approach

is as follows. An acceptable configuration is certified by a certificate issuer

who

publishes certificates on mapping between properties

and configurations

. As

mentioned before these certificates are represented through signatures

. For

property attestation of

host

(

)

proves to the verifier

that there is a valid link be-

tween the conventional attestation signature

, generated by the attestor (here TPM),

and the certificate

attesting that the configuration specification

provides the

property specification

. Note that in this protocol the prover proves directly that its

configuration complies with that in the certificate without showing the certificate. In
opposite to the hardware-based solution suggested in Section 7.1.7, this approach does
not need extensions of the underlying trusted computing hardware.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

145

The protocol includes two main phases, the issue phase and the attestation phase. In

the issue phase,

locally generates property certificates

←

Sign

(

)

. In

the attestation phase, the property-based attestation protocol is performed. It is defined
as follows:

(

ind

−

)

←

Attest

(

−

;

∗

, N

)

The common input is the property

, the public key

of the certificate issuer

and the nonce

(chosen by

More concretely, the TPM signs the message

where

denotes a com-

mitment to the configuration

. The resulting signature is denoted by

TPM

←

Sign

TPM

(

)

extends the TPM’s signature to a signature

and sends it

. Then

proves in zero-knowledge that (i)

contains a valid property-certificate

for the property

, (ii) the content of the commitment

(which is signed by the

TPM) is the same as the configuration certified in the certificate

also verifies

that the nonce

(obtained by the same verifier

) is signed by the TPM.

Note that the certificate

is the secret input to the protocol since the verifier

should not learn information about the platform configuration

. For the concrete

protocol one can deploy the group signature and cryptographic techniques similar to
those used in the context of DAA [13].

The unlinkability requirement can be realised by using

T P M

as an anonymous

session signature key that was verified by the verifier using a pseudonym certified either
through a Privacy CA or through DAA.

To fulfil the revocability and the availability requirements, the underlying protocol

should offer the possibility to verify whether or not this configuration is still valid.
However, revocation-related issues occur just like in every certificate-based solution
(see Section 7.1.7). Hence, the protocol should provide a mechanism to securely prove
that the current certificate is not on the certificate revocation list.

A concrete realisation of such a protocol is proposed in [19]: The property-based at-

testation (PBA) protocol presented there includes the creation and verification of PBA-
signatures, as well as a configuration revocation protocol. The certificate issuer

has

to provide property certificates but is not involved in the attestation and revocation pro-
tocols. Certificate revocation lists are not necessarily published by

(although this is

an option, of course): they can be published by anyone, or even be negotiated among

and

before they execute the revocation protocol.

Proving Membership

A way to securely prove that the machine

to be attested

has a certain property is to prove that the corresponding configuration is in a set of
configurations accepted by all parties involved in the attestation protocol. The agree-
ment on this set can be realised in different ways depending on the trust model. More
concretely, the agreement can be achieved between the proving and verifying parties
by means of negotiation or by means of a third party trusted by both of them.

In [54] a mechanism is proposed based on the second approach. The idea is that

signs a configuration encrypted under the public key of a trusted third party and to

sign a contract between

and

that guarantees that the platform has the properties

requested by

This approach makes it impossible for providers to discriminate

A slightly extended protocol can be used for property-based sealing: The machine

has to prove that it

knows a valid certificate

TPM

on an encryption key

TPM

generated by the TPM, and a valid property

certificate

Note that this requires changes to the TPM since currently the specification allows the TPM to sign PCR

values and not values encrypted by a third party.

pen_TC Deliverable 05.1

146

OpenTC D05.1 – Basic Security Services

an operating system or to force users to use a specific platform configuration. Since
the TPM also signs the encrypted values, verifiers are ensured that the attested config-
uration is valid. In case of a conflict, the trusted third party can decrypt the encrypted
configuration to verify whether the user is cheating.

For example, if a bank requires that users only use trusted banking software cer-

tified by another party, and if the user accuses the bank, the trusted third party can
decrypt these values to verify whether the user used the correct banking software.

The problem of this approach is that verifiers cannot verify the property enforced

by the user platform online. In the following we discuss an improved method that
allows online verification. Instead of letting a trusted third party decrypt the configu-
ration offline, the platform cryptographically proves that a committed configuration is
a member of the set of certified configurations. More concretely, in this proof of mem-
bership protocol for property-based attestation, the TTP (e.g., a certificate issuer

)

publishes the set of all platform configurations

{

, . . .

}

that provide a

specific property

, and a signature

on this set. To attest properties, a local soft-

ware service performs a conventional attestation protocol with the TPM where it hides
the signed configuration. Then, a cryptographic protocol proves the following: First
the committed configuration value

is contained in

, and second the TPM attes-

tation signature is valid. The abstract protocol definition is similar to that presented in
previous sections (for example, see Section 7.1.10).

To fulfil the revocability and the availability requirements, the underlying proof of

membership protocol should offer the possibility to dynamically remove configurations
from the list and to add new configurations into the list.

Assessment of Delegation-based Solutions

In this section, we briefly consider the advantages and disadvantages of the delegation-
based solutions described in the previous sections.

The solution in Section 7.1.7 requires an extension of TPM functionalities in hard-

ware. A variant of the solution in Section 7.1.7 could also be implemented by an ex-
tension to TPM hardware. Enhancing the TPM with property-based functionality has
two major advantages: First, the trust model related to the trusted computing platform
does not change since the TPM has to be fully trusted by assumption anyway. Hence,
the requirements security, accountability and privacy can be fulfilled (see also Section
7.1.6). Second, since the realisation of property-based attestation within a TPM does
not depend on external components, changes to the platform configuration cannot lead
to unavailability of sealed data which fulfils requirement 4 (availability). The disad-
vantage of this approach is the additional complexity of the TPM which may make the
TPM more complex and expensive. Nevertheless, the required complexity should be
acceptable compared to the complexity of the DAA protocol [13].

The solution in Section 7.1.7 is based on a strong trust model and has limited func-

tionality which may not be satisfactory: This solution is either inefficient or verifiers
have to trust a software service running on the platform to be attested. Note that for the
desired security targets to be satisfied the software service TAS must be fully trusted
since otherwise this component (machine) can simply disclose all secret information, in
particular privacy-relevant information, to a verifier. Nevertheless, the software-based
approach discussed above can be realised based on existing mechanisms (e.g., a TPM),
as shown in, e.g., [61].

The solutions introduced in Section 7.1.10 can be realised without requiring all in-

volved parties to trust the software component used in the attestation process. This is

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

147

very useful and effective for many business models and applications. Efficient cryp-
tographic techniques exist to construct the building blocks of these proofs. In [19],
the authors show how to use them in order to realise a protocol. However, the overall
protocols may become complex and costly for certain applications such as those for
embedded systems.

7.1.11

Implementation

This section describes a practical realisation of property-based attestation based on
existing technology, e.g., a TPM. The approaches discussed in Section 7.1.7 assume
a secure operating system, since the user

has to trust the operating system not to

leak information about the platform’s configuration and the verifier

has to trust all

attestors.

Therefore, the following subsection shortly introduces the basic system architecture

we used to realise property-based attestation. Subsection 7.1.11 discusses a hybrid
attestation model, i.e., a model using binary and property-based attestation. Although
such an approach still uses binary attestation, it keeps the amount of binary attested
software components small.

The Basic Architecture

The trustworthiness of a TCG-enabled computing platform is limited by the trustwor-
thiness of the corresponding TCB. Today’s operating systems are inappropriate for use
as a trusted software basis, because they can be maliciously manipulated after a re-
boot.

In practice, it is very difficult for a verifier (challenger) to decide whether a concrete

system configuration provides a desired property. Even if the enforcement mechanisms
of the trusted computing base would be highly trustworthy (e.g., due to its evaluation
at EAL7

), the property obviously depends on the locally enforced security policy,

too. To make the analysis of the platform’s trustworthiness more realistic, it would
be meaningful to provide a policy-neutral operating system base that delegates the en-
forcement of policies to the application level software (see [77]). Since the underlying
TCB is now much simpler, it has only to fulfil basic security requirements as described
below:

Secure Path: The TCB has to provide a secure path between provider and application,

e.g., it has to ensure that only the application that fulfils the provider’s policy can
access the content. This requirement implies that the provider and the TAS can
communicate securely.

Isolation: The TCB has to prevent an attacker (e.g., the local user or a concurrent ap-

plication) from accessing or manipulating the code or the data of the application
(which is similar to overwriting

). This requirement ensures that the code and

the data of the TAS are protected against attacks of concurrent processes.

In this context, the PERSEUS architecture [69] is an open-source development

project based on TC hardware that aims at fulfilling these requirements. This security

Note that the operating system has no access to the cryptographic keys stored in TPM, but to all de-

crypted content.

Evaluation Assurance Level, see [22].

pen_TC Deliverable 05.1

148

OpenTC D05.1 – Basic Security Services

framework is currently being developed within the EMSCB

and OpenTC

projects.

Hybrid attestation

Since currently available TC hardware, e.g., a TPM, only provides binary attestation,
the availability requirement cannot be fully satisfied, since changes of binary attest-
ed/sealed data still leads to inaccessibility of the sealed data. Nevertheless, it makes
sense to keep the complexity of binary sealed software as small as possible to reduce
the probability of an update.

For instance, in the Enforcer project [62] cryptographic keys are bound only to

so-called long-lived data: the boot loader, the Linux kernel, and the Enforcer module.
However, this solution is still unsatisfactory since Linux kernel updates happen quite
often.

In the PERSEUS project, we have combined authenticated booting, the personal

secure bootstrap architecture [43], and the idea of certificate-based attestation to further
reduce the complexity of the data that has to be binary-attested and binary-sealed (see
Figure 7.14).

cert

secure channel

data(D)

TPM

data(D)

TSL

send(m)

receive(m)

insecure channel

Attestor

seal(p,D)

attest(p)

data(D)

exec(C )

TSL

exec(C )

B|C TSL

boot(C )

|C M

exec(C )

Figure 7.14: Simplified model of the bootstrapping design realised by the PERSEUS
security architecture

The general idea behind [43] is that in the boot chain every machine

checks

whether a valid certificate

cert

of the executed machine

exists. For this pur-

pose, we are using an enhanced boot loader

that itself loads the public signature

key

P K

representing a property

of a certificate issuer

. We assume that the

BIOS stores the configuration of the boot loader in

P CR

and that the boot loader

stores a hash value of the

P K

P CR

. When booting the subsequent system

(e.g., a security kernel),

checks whether a valid certificate issued by

exists. If

not, it extends

P CR

by a random value.

Now, a verifier

can ensure that, e.g., the security kernel of a remote platform has a

certain property certified by

by attesting resp. sealing against

P CR

and

P CR

The expressiveness of only one certificate is limited. Nevertheless, it can be used to
attest elementary security requirements, e.g., isolation, secure communication, and the

http://www.emscb.de

http://www.opentc.net

http://www.prosec.rub.de/trusted grub.html

We decided to extend the appropriate PCR instead of simply interrupting the boot process, because we

do not want to prevent users from executing non-certified code.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

149

fact that the loaded system itself provides property-based attestation. More complex
properties of subsequent modules can then be attested by the security kernel itself.

In our architecture, the boot loader executes the PERSEUS security kernel

T SL

which itself attest properties of applications (e.g., L4-Linux, security-critical applica-
tions, or a Trusted VM) using any of the solutions discussed in Sections 7.1.6 and
7.1.7. Alternatively, the

T SL

could delegate the attestation of applications by execut-

ing a machine (e.g., a Trusted VM) that itself can attest application properties. This
approach, which can also be applied to architectures based on a virtual machine mon-
itor (VMM), allows us to seal data only to the binary configuration of the boot loader
that itself ensures that the data can only be unsealed if the configuration was authenti-
cated by the appropriate cryptographic key

. To further decrease the complexity

of binary-attested code, one could realise the suggested solution by the BIOS instead
of the boot loader.

7.1.12

Open Issues

The open problems can be separated into three different problem classes:

The first one deals with the question on how property-based attestation and sealing

can efficiently be implemented. The approaches discussed in Section 7.1.7 and Section
7.1.11 all have their advantages and disadvantages, but they are all far from being
perfect. To fulfil the availability requirement, an extension of the trusted computing
hardware seems to be necessary. However, it is improbable that formal methods (e.g.,
semantic code analysis) will be performed by trusted computing hardware in the future.
Thus, the currently best and cheapest solution seems to be a hardware extension based
on certificates [53].

The second class of problems is the question how properties can efficiently be de-

rived. Today, an evaluation, e.g., according to the Common Criteria, followed by a
certification of a trusted third party seems to be the maximum that can be done for a
huge class of software. In the future, however, improved software-engineering meth-
ods based on formal methods, proof-carrying code, and semantic code analysis may
give the chance to formally or semi-formally derive properties from code directly and
thus to prevent the need of a trusted third party.

The third problem class is related to properties themselves. Besides the important

question which classes of properties of software can be derived in general, it remains
unclear which aspects of properties are meaningful and important: We hope that the
properties required by a small security kernel that mainly attests software on an appli-
cation level is manageable. On an application level, however, properties to be attested
may become complex and difficult to manage.

Finally, the suggested approaches, like nearly any other security mechanism, rely

on the assumption that the underlying operating system is secure enough, e.g., to pre-
vent leakage of its own configuration. Especially the currently available operating
systems do not fulfil this elementary requirement and the security community has to
put a lot of effort into providing a secure operating system based on open standards.

7.1.13

Summary

One of the most recent and notable initiatives of the computer industry announced to
increase the security of computing platforms by means of new hardware architectures.
This initiative, the Trusted Computing Group (TCG), aims at offering new functional-

pen_TC Deliverable 05.1

150

OpenTC D05.1 – Basic Security Services

ities allowing to verify the integrity of a platform (attestation) or bind quantities to a
specific platform configuration (sealing).

In this contribution, we firstly point out the deficiencies of the so-called binary

attestation and sealing functionalities proposed by the specification of the TCG: If
naively used, these mechanisms may discriminate computing platforms, i.e., their op-
erating systems and consequently the corresponding vendors. A particular problem in
this context is that of managing the multitude of possible configurations. Moreover, we
highlight other shortcomings related to attestation, namely system updates and backup.
Secondly, we introduce the concept of property-based attestation: The idea is that at-
testation should not depend on the specific software and/or hardware, but only on the
properties that the platform provides. In contrast, property-based attestation only ver-
ifies whether the attested platform has the sufficient properties that fulfil certain secu-
rity requirements of the party who asks for attestation. We propose a framework for
property-based attestation/sealing and present a variety of solutions based on Trusted
Computing (TC) functionality and cryptographic techniques. Moreover, we give some
concrete constructions for one class of these approaches, namely, delegation-based at-
testation. Thirdly, we discuss the implementation issues for property-based attestation
protocols based on the existing TC hardware such as the Trusted Platform Module
(TPM). Lastly, we consider some open problems regarding properties.

7.2

Dependability Enhancements Using Virtualisation

H. Ramasamy, M. Schunter (IBM)

7.2.1

Introduction

We address the issue of using virtualisation as a building block for enhancing depend-
ability not just in data centres, but also in more general settings. With few exceptions,
current solutions in this space have largely been ad-hoc. There seems to be an increas-
ingly prevalent tendency to think of virtualisation as a cure-all. Suggestions to shift
almost anything that runs on a real machine to a virtual machine and to move services
(such as networking and security) currently provided by the operating system to the
VMM are becoming commonplace (e.g., [32]). The related work for this research has
been summarised in Section 2.5.

7.2.2

Virtualisation: New Opportunities for Dependability

Commodity operating systems provide a level of dependability that is much lower than
what is desired. This situation has not seen much change in the past decade or so.
Hence, the focus has shifted to designing dependable systems around the OS problems.

Virtualisation enables such a design in at least two ways. One way is to encapsu-

late the OS and applications in a VM and introduce dependability enhancements at the
VMM level, which are transparent to the guest OS and applications. Such a design al-
lows the VM to be treated as a black box. For example, checkpointing and recovery can
be done at the granularity of VMs instead of processes. Another way is to instrument
applications, middleware, and/or the guest OS with explicit knowledge of their running

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

151

on a virtual as opposed to a physical machine. For example, in programming languages
supporting VMs (such as Java and OCAML), checkpointing the application state at the
VM level or byte-code level (as opposed to native code) can allow the saved state to
be restarted on a hardware platform different from the one in which checkpointing was
done [3].

Virtual machines offer a degree of flexibility that is not possible to obtain on phys-

ical machines. That is mainly because VM state, much like files, can be read, copied,
modified, saved, migrated, and restored [32]. In this section, we propose various new
methods to improve dependability that are based on virtualisation.

Coping with Load-Induced Failures:

Deploying services on VMs instead of physi-

cal machines enables higher and more flexible resilience to load-induced failures with-
out requiring additional hardware. Under load conditions, the VMs can be seamlessly
migrated (using live migration [20]) to a lightly loaded or a more powerful physical
machine. VM creation is simple and cheap, much like copying a file. In response to
high-load conditions, it is much easier to dynamically provision additional VMs on
under-utilised physical machines than to provision additional physical machines.

Patch Application for High-Availability Services:

Typically, patch application in-

volves a system restart, and thus negatively affects service availability. Consider a
service running inside a VM. Virtualisation provides a way to remove faults and vul-
nerabilities at run-time without affecting system availability. For this purpose, a copy
of the VM is instantiated, and the patch (be it OS-level or service-level) is applied on
the copy rather than on the original VM. Then, the copy is restarted for the patch to take
effect, after which the original VM is gracefully shut down and future service requests
are directed to the copy VM. The patch is applied at the copy VM and the copy VM is
restarted while the original VM still continues regular operation, thereby maintaining
service availability. To ensure that there are no undesirable side effects due to the patch
application, the copy VM may be placed in “quarantine” for a sufficiently long time
while its post-patch behaviour is being observed before the original VM is shut down.
If the service running inside the VM is stateful, then additional techniques based on a
combination of VM checkpointing and VM live migration [20] may be used to retain
network connections of the original VM and to bring the copy up-to-date with the last
correct checkpoint.

Enforcing Fail-Safe Behaviour:

The average time between the point in time when

a vulnerability is made public and a patch is available is still measured in months. In
2005, Microsoft took an average time of 134.5 days for issuing critical patches for
Windows security problems reported to the company [1].

Developing patches for a

software component is a time-consuming process because of the need to ensure that the
patch does not introduce new flaws or affect the dependencies between the component
involved and other components in the system. In many cases, a service administrator
simply does not have the luxury of suspending a service immediately after a critical
flaw (in the OS running the service or the service itself) becomes publicised until the
patch becomes available.

Virtualisation can be used to prolong the availability of the service as much as

possible while at the same time ensuring that the service is fail-safe. We leverage the
observation that publicising a flaw is usually accompanied by details of possible attacks

pen_TC Deliverable 05.1

152

OpenTC D05.1 – Basic Security Services

exploiting the flaw and/or symptoms of an exploited flaw. Developing an external
monitor or intrusion-detection system to identify attack signatures or symptoms of an
exploited flaw may be done independently of the patch development. The monitor may
also be developed much faster than the patch itself, because the monitor may not be
subject to the same stringent testing and validation requirements.

Consider a service running inside a VM rather than directly on a physical machine.

Then, a VM-external monitor, running parallel to the VM, can be used detect the symp-
toms of the exploited flaw and to signal the VMM to crash the VM. Alternatively, if
the attack signature is known, the monitor can be used to identify an ongoing attack
and terminate interaction with the attack source. The monitor could be implemented at
the VMM level or in a privileged VM (such as Dom0 in Xen [8]). If it is important to
revert the service to its last correct state when a patch does become available, then the
above technique can be augmented with a checkpointing mechanism that periodically
checkpoints the state of the service with respect to the VM (e.g., [3]).

Proactive Software Rejuvenation:

Rebooting a machine is an easy way of rejuve-

nating software. The downside of machine reboot is that the service is unavailable dur-
ing the reboot process. The VMM is a convenient layer for introducing hooks to proac-
tively rejuvenate the guest OS and services running inside a VM in a performance- and
availability-preserving way. Periodically, the VMM can be made to instantiate a rein-
carnation VM from a clean VM image. The booting of the reincarnation VM is done
while the original VM still continues regular operation, thereby maintaining service
availability. One can view this technique as a generalisation of the proactive recovery
technique for fault-tolerant replication proposed by Reiser and Kapitza [73].

As mentioned above in the context of patch application, techniques based on VM

checkpointing and live migration may be used to seamlessly transfer network connec-
tions and the service state of the original VM to the reincarnation VM. It is possible to
adjust the performance impact of the rejuvenation procedure on the original VM’s per-
formance. To lower the impact, the VMM can restrict the amount of resources devoted
to the booting of a reincarnation VM and compensate for the restriction in resources by
allowing more time for the reboot to complete.

One can view the above type of rejuvenation as a memory-scrubbing technique for

reclaiming leaked memory and recovering from memory errors of the original VM.
More importantly, such periodic rejuvenation offers a way to proactively recover from
errors without requiring failure detection mechanisms (which are often unreliable) to
trigger the recovery.

Replica Diversity:

In fault-tolerant replication, diversity of replicas is important to

ensure that not all replicas fail because of the same disruptive event. By deploying
replicas on a combination of virtual and physical machines rather than on physical
machines alone, replica diversity can be enhanced. Also, deploying replicas on VMs
instead of physical machines opens another layer in which diversity can be introduced:
the VMM software. VMM diversity and OS diversity can complement each other to
enhance replica diversity without additional hardware costs. On the flip side, using the
same VMM for all replica VMs will actually lower replica diversity even if the replicas
are deployed on different operating systems. That is because a fault in the VMM could
lead to failure of all replicas.

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

153

Hardware H

OS + Application

(a) Architecture

(b) Combinatorial Model

Figure 7.15: Non-virtualised node

Containment:

Fault containment is an important aspect of dependability. Contain-

ment among VMs running on the same VMM is much stronger than containment
among processes running on the same OS. To better isolate the fault effects of two
services running on the same OS and physical server, one can carve the physical server
into two VMs, with each running one service. On the other hand, fault containment
between two VMs is not as strong as fault containment between two physical ma-
chines (e.g., because of covert channels). Hence, when cost is not a restriction (e.g., in
highly-critical space and military applications), running software components on dis-
tinct hardware would be better for fault containment than running the components in
different VMs on the same hardware.

7.2.3

Quantifying the Impact of Virtualisation on Node Reliability

In this section, we use combinatorial modelling to perform reliability analysis of re-
dundant fault-tolerant designs involving virtualisation on a single physical node and
compare them with the non-virtualised case. We consider a model in which multiple
VMs run concurrently on the same node and offer identical service. We derive lower
bounds on the VMM reliability and the number of VMs required for the virtualised
node to have better reliability than the non-virtualised case. We also analyse the reli-
ability impact of moving a functionality common to all VMs out of the VMs and into
the VMM. In addition, we analyse the reliability of a redundant execution scheme that
can tolerate the corruption of one out of three VMs running on the same physical host,
and compare it with the non-virtualised case. Our results point to the need for careful
modelling and analysis before a design based on virtualisation is used.

Combinatorial modelling and Markov modelling are the two main methods used for

reliability assessment of fault-tolerant designs [46]. We chose combinatorial modelling
because its simplicity enables easy elimination of “hopeless” choices in the early stage
of the design process. In combinatorial modelling, a system consists of series and par-
allel combinations of modules. The assumption is that module failures are independent.
In a real-world setting, where module failures may not be independent, the reliability
value obtained using combinatorial modelling should be taken as an upper bound on
system reliability.

Non-Virtualised (NV) Node: For our reliability assessment, we consider a non-

virtualised single physical node as the base case. We model the node using two mod-
ules: hardware (

) and the software machine (

) consisting of the operating system,

middleware, and applications (Figure 7.15(a)). Thus, the node is a simple serial system
consisting of

and

, whose reliability is given by

N V

sys

, where

denotes the reliability of module

(Figure 7.15(b)).

Virtualised Node with

Independent, Identical VMs: Figure 7.16(a) shows a

physical node consisting of

, a type-1 VMM (

) that runs directly on the hardware

pen_TC Deliverable 05.1

154

OpenTC D05.1 – Basic Security Services

. . .

Hardware H

Virtual

Machine

Virtual

Machine

Virtual Machine

Monitor V

(a) Architecture

(b) Combinatorial Model

Figure 7.16: Node with

VMs

(such a VMM is referred to as a hypervisor), and one or more VMs (

{

}

, i

≥

). The

VMs provide identical service concurrently and independently (i.e., without the need
for strong synchronisation). For example, each VM could be a virtual server answering
client requests for static web content. Thus, the node is a series-parallel system (Fig-
ure 7.16(b)) whose overall reliability is given by

sys

−

n
i

−

)]

Here, we consider the reliability of the hardware to be the same as that in the non-
virtualised case because the underlying hardware is the same in both cases. An obvi-
ous concern is whether the hardware in the virtualised node will register a significant
drop in reliability due to load/stress compared to the non-virtualised node. The concern
does not apply to our context of application servers in a data centre in which typical
hardware utilisation in a non-virtualised node is abysmally low (less than 5%) and

typically in the low tens of VMs.

sys

> R

N V

sys

gives the condition for the

-replicated service to be more reliable

than the non-virtualised service, i.e.,

−

n
i

−

)]

> R

. For

simplicity, let

for all

≤

. This is a reasonable assumption, since

each VM has the same functionality as the software machine

in the non-virtualised

case. Then, the above condition becomes

−

)

]

> R

(7.1)

Inequality (7.1) immediately yields two conclusions. First, if

= 1

, then again

the above condition does not hold (

). What this means is that it is necessary

to have some additional coordination mechanism or protocol built into the system to
compensate for the reliability lost by the introduction of the hypervisor. In the absence
of such a mechanism/protocol, simply adding a hypervisor layer to a node will only
decrease node reliability. Second, if

, then it is obvious that above condition

does not hold.

It is clear that the hypervisor has to be more reliable than the individual VM. The

interesting question is how much more reliable. Figure 7.17 shows that for a fixed

value, the hypervisor has to be more reliable when deploying fewer VMs. The graph
also shows that, for fixed values of

and

, there exists a lower bound on the

value below which the virtualised node reliability will definitely be lower than that

of a non-virtualised node. For example, when

= 0.1 and

= 0.3, deploying

fewer than 4 VMs would only lower the node reliability. This is a useful result, as in
many practical settings,

and

values may be fixed, e.g., when the hypervisor,

guest OS, and application are commercial-off-the-shelf (COTS) components with no
source-code access.

The equation for

sys

also suggests that by increasing the number of VMs, the node

reliability can be made as close to the hypervisor reliability as desired. Suppose we
desire the node reliability to be

, where

R < R

. Then,

−

)

]

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

155

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Lower Bound on Reliability

of Hypervisor (R

)

Reliability of Virtual Machine (R

)

n=2
n=3
n=4
n=8

n=16
n=32

Figure 7.17: Lower bound on the hypervisor reliability for a physical node with

independent and concurrently operating VMs providing identical service.

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Lower Bound on Number of VMs (n)

Reliability of Virtual Machine (R

)

R = 0.98

R = 0.998

Figure 7.18: Lower bound on the number of VMs to achieve desired reliability

for a

physical node with

independent and concurrently operating VMs providing identical

service when

= 0

999

Assume that the hardware is highly reliable, i.e.,

≃

. Then, the above equation

becomes the inequality,

R < R

−

)

]

⇒

−

)

−

⇒

log(1

−

)

log(1

−

)

Dividing by

log(1

−

)

, a negative number, we get,

n >

log(1

−

)

log(1

−

)

(7.2)

Inequality (7.2) gives a lower bound on the number of VMs required for a virtu-

alised physical node to meet a given reliability requirement. In practice, the number
of VMs that can be hosted on a physical node is ultimately limited by the resources
available on that node. Comparing the lower bound with the number of VMs that can
possibly be co-hosted provides an easy way to eliminate certain choices early in the
design process.

Figure 7.18 shows the lower bound for

for two different

values (0.98 and

0.998) as the VM reliability (

) is increased from roughly 0.1 to 1.0, with the hy-

pervisor reliability fixed at

999

. The figure shows that for fixed

and

values,

higher system reliability (up to

) can be obtained by increasing the number of VMs

pen_TC Deliverable 05.1

156

OpenTC D05.1 – Basic Security Services

’

(a) Configuration

: Functionality

imple-

mented within each VM

’

(b) Configuration

: Functionality

imple-

mented as part of hypervisor

Figure 7.19: Moving functionality out of the VMs into the hypervisor

hosted. However, when

is large, one is faced with the practical difficulty of obtaining

sufficient diversity to ensure that VM failures are independent.

Moving Functionality out of the VMs into the Hypervisor: We now analyse the

reliability impact of moving a functionality out of the VMs and into the hypervisor.
As before, our system model is one in which a physical node has

≥

independent

and concurrently operating VMs providing identical service. Consider a functionality

implemented inside each VM. Then, each VM

can be divided into two components,

and

′

, the latter representing the rest of

. Figure 7.19(a) shows the reliability

model for a node containing

such VMs. Let us call this node configuration

Further, suppose that the functionality

is moved out of the VMs and substituted by

component

implemented as part of the hypervisor. Now, the new hypervisor consists

of two components

and the old hypervisor

. Figure 7.19(b) shows the reliability

model for a node with the modified hypervisor. Let us call this node configuration

We now derive the condition for

to be at least as reliable as

. For simplicity,

let us assume that

′

for all

≤

. Then, the desired condition is

sys

≥

sys

⇒

−

′

)

]

≥

−

′

)

]

⇒

≥

−

′

)

]

−

′

)

]

(7.3)

It is easy to see from Figure 7.19 that when there is only one VM, it does not matter

whether the functionality is implemented in the hypervisor or in the VM. We can also
confirm this observation by substituting

= 1

in inequality (7.3).

Figures 7.20(a) and (b) illustrate how

varies as

is increased from 0.1 to 1.

The graphs show that for configuration

to be more reliable than

has to be

more reliable than

. Figure 7.20(a) shows that as

′

increases, the degree by which

should be more reliable than

also increases. Figure 7.20(b) shows that the degree

is also considerably higher when more VMs are co-hosted on the same physical host.
For example, even with modest

′

and

values of 0.75,

has to be ultra-reliable:

has to be more than 0.9932 and 0.9994 if

= 6

and

= 9

, respectively. Thus,

when more than a handful of VMs are co-hosted on the same physical node, better
system reliability is likely to be obtained by retaining a poorly reliable functionality in
the VM than by moving the functionality into the hypervisor.

Virtualised Node with VMM-level Voting: Consider a fault-tolerant 2-out-of-3

replication scheme in which three VMs providing identical service are co-hosted on a
single physical node. The VMM layer receives client requests and forwards them to all
three VMs in the same order. Assume that the service is a deterministic state machine;
thus, the VM replicas yield the same result for the same request. The VMM receives the
results from the VM replicas. Once the VMM has obtained replies from two replicas

pen_TC Deliverable 05.1

CHAPTER 7. ADVANCED SECURITY SERVICES

157

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Lower Bound on Reliability

of Functionality when

Moved to Hypervisor (R

)

Reliability of Functionality Implemented in VM (R

)

M’

= 0.75, n = 3

M’

= 0.90, n = 3

M’

= 0.95, n = 3

M’

= 0.99, n = 3

(a) Fixed

, Varying

′

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Lower Bound on Reliability

of Functionality when

Moved to Hypervisor (R

)

Reliability of Functionality Implemented in VM (R

)

M’

= 0.75, n = 3

M’

= 0.75, n = 6

M’

= 0.75, n = 9

(b) Fixed

′

, Varying

Figure 7.20: Plot of

≥

−

′

)

]

−

′

)

]

with identical result values for a given client request, it forwards the result value to
the corresponding client. Such a scheme can tolerate the arbitrary failure of one VM
replica, and is similar to the one suggested in the RESH architecture for fault-tolerant
replication using virtualisation [72]. Assuming that the VMs fail independently, the
system reliability is given by

−

sys

[

3
2

−

)]

Then,

−

sys

> R

N V

sys

gives the condition for the 2-out-of-3 replication scheme to be

more reliable than the non-virtualised service. Thus, we obtain

[

3
2

−

)]

> R

⇒

−

(7.4)

Inequality (7.4) gives a lower bound on the hypervisor reliability for the 2-out-of-3

replication scheme to have better reliability than the non-virtualised case. Figure 7.21
shows a plot of

−

< R

. It is clear from the graph that there exists no

value that satisfies inequality (7.4) and is less than 1 when

≤

. In other

words, if the VM reliability (i.e., the OS and service reliability) is poor to begin with,
then the 2-out-of-3 replication scheme will only make the node reliability worse even
if the hypervisor is ultra-reliable. This result concurs with the well-known fact that any

pen_TC Deliverable 05.1

158

OpenTC D05.1 – Basic Security Services

0.88

0.9

0.92

0.94

0.96

0.98

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Lower Bound on Reliability

of Hypervisor (R

)

Reliability of Virtual Machine (R

)

Figure 7.21: Plot of

−

)

−

< R

form of redundancy with majority voting is not helpful for improving overall system
reliability when the overall system is composed of modules with individual reliabilities
of less than

[46]. The graph also shows that the higher the hypervisor reliability, the

larger the range of VM reliability values for which the 2-out-of-3 replication scheme
has better reliability than the non-virtualised case. For example, when

= 0

the range of VM reliability values that can be accommodated is greater than the range
when

= 0

7.2.4

Conclusion

We described new ways of leveraging virtualisation to improve system dependability.
Using combinatorial modelling, we provided a more detailed analysis than was pre-
viously available on how virtualisation can affect one aspect of system dependability,
namely reliability. Combinatorial modelling assumes that the failures of a VM hosted
on a physical node are independent, an assumption that may not be met in practice.
Hence, the actual values we have derived in our analysis for various virtualisation sce-
narios should be considered as optimistic values. However, the more significant mes-
sage of our results is that unless certain conditions (e.g., regarding the reliability of the
hypervisor and the number of VMs) are met, introducing virtualisation could decrease
the reliability of a physical node. In light of the general trend to move services out
of the guest OS into the virtualisation layer, our results point out the need for a more
cautious approach. Future work includes more rigorous modelling and analysis of de-
pendability attributes in the context of virtualisation, particularly in dynamic situations
such as VM migration.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

161

There are some other applications handling the former issues, like the “TPM Man-
ager” (

http://sourceforge.net/projects/tpmmanager/

) or the “TPM Monitor” (

http://

sourceforge.net/projects/tpmmonitor/

The “TPM Controller” tool has been created as a result of the OpenTC EU project

and is hosted on their homepage

http://www.opentc.net/

. It provides the possibility to

take, change and clear the ownership of the TPM, which are probably the main things
to do when initiating a TPM.

Further on the current version of the used TSS, the actual TPM firmware version

and the vendor name of the TPM are displayed. On the “Status” tab the status of
Activation, Enable/Disable and if an owner is already set are displayed.

With the reset button on the “Reset” tab the owner of the TPM is able to reset the

so called “Pin Failure” count.

The “Certificate Chain” tab tries to verify the TPM built-in endorsement certificate.

A.1.2

Getting started

Preconditions

“TPM Controller” is a Linux Tool developed and tested on OpenSuse 10.1 / 10.2, but
should work also with other Linux distributions and could be easily ported to Windows,
since the used GUI toolkit is available for both platforms. It explicitly uses the OpenTC
Trusted Software Stack for TPM 1.2 developed by Infineon. A working installation of
the stack is indispensable.

For the GUI toolkit the open source version of Trolltech Qt 4.2.x was chosen.

Therefore it is necessary that a working version is installed on the machine.

An additional dependency relies on the OpenSSL crypto library, that is used for

cryptographic functionality.

Build & Run

If all preconditions are met, simply run “build.sh” on the command line to build the
complete “TPM Controller” GUI application from source.

To run the “TPM Controller”, simply type “./tpmcontroller” in the source code

folder and the tool starts up with a modal dialogue including several tabs with all the
functionality explained in the following chapters. Obviously the tool can be simply
copied to a user desired location and run from there.

A.1.3

Ownership

The “Ownership” tab comes up something like the following screen shot.

pen_TC Deliverable 05.1

180

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 30 /

ITLE

Start Compartment

ESCRIPTION

A compartment starts another compartment.

CTORS

Compartment

RECONDITIONS

The Security Kernel is running.

OSTCONDITIONS

The new compartment is running.

ORMAL

LOW

Compartment

invokes Security Kernel

to start a new compartment.

Compartment

defines the program, se-

curity attributes, and configuration pa-
rameters to be used for the new compart-
ment.

3. Security Kernel starts the new compart-

ment.

4. Security Kernel returns the Compart-

mentID of the newly created compart-
ment to

Compartment

LTERNATIVE

LOW

Compartment

invokes Security Kernel

to start a new compartment.

Compartment

defines the program and

configuration parameters to be used for
the new compartment.

3. The Security Kernel detects that the client

is not authorised to perform this opera-
tion.

4. The Security Kernel returns an error

value.

Possible error values could be:

•

Not allowed to start a new program at all.

•

Not allowed to start this program.

•

Not allowed to use this configuration parameter

•

Not allowed to use this security attribute

A parent cannot have different security attributes (e.g., security domain) than its

child, else both could communicate. How to create compartments with different do-
mains? A trusted function to change the security attributes of an compartment? Or do
we need a trusted compartment for every security domain?

CSt: Not sure whether we should support these kind of security policy.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

181

ASE

NIQUE

/ UC 40 /

ITLE

Start compartment by image

ESCRIPTION

A compartment starts another compartment in-
cluding a file system.

CTORS

Compartment

PECIALIZES

/ UC 30 /

ATIONALE

Although this use case is very similar to
/ UC 30 /, we decided to include it here to be
able to describe how a legacy OS is started.
Very often, legacy operating systems are started
as images including a file system to be attached
to the operating system.

First a new container has to be created (e.g., by starting a new storage manager

instance) offering the file system of that image. Then the compartment is started using
the newly created container as the root file system.

ASE

NIQUE

/ UC 50 /

ITLE

Stop Compartment

ESCRIPTION

A client stops a running compartment.

CTORS

Compartment

RECONDITIONS

The compartment to be stopped is running.

OSTCONDITIONS

The compartment is halted and all resources al-
located by the compartment are freed. More-
over, all child compartments of that compart-
ment are stopped, too. The CompartmentID
of the stopped compartment is not available for
further use until reboot.

ORMAL

LOW

1. The

Compartment

invokes Security

Kernel to stop a compartment, providing
its CompartmentID.

2. Security Kernel acknowledges the oper-

ation, and stops the indicated compart-
ment.

LTERNATIVE

LOW

1. The

Compartment

invokes Security

Kernel to stop a compartment, providing
its CompartmentID.

2. Either

•

access to the compartment fails or

•

Security Kernel detects that the re-
quest is not authorised.

3. Security Kernel denies the operation.

pen_TC Deliverable 05.1

182

OpenTC D05.1 – Basic Security Services

Who is allowed to stop a compartment? Do we need a parent-child relationship?

What about child tasks? are they identical to child compartments? Are compartments
only the first layer of tasks above the compartment manager?

L4-Linux tasks are L4-Subtasks but this should be hidden to other compartments.

Only another thread with access to a subset of the address space of another compart-
ment. This is at least the model on VMMs and hypervisors. Is this model flexible
enough for us?

If we prefer a parent-child relationship between compartments: Allowing only the

parent of a compartment to stop that compartment is very restrictive, but should be
flexible enough. We may need a function to change the parent of a compartment?
Another usage of the trusted function to change security attributes of compartments?

Persistent Storage:

Containers are objects to store data persistently. Every container

has an assigned security policy defining the security properties of that container (in-
tegrity, confidentiality, freshness, ...) and the access permissions.

Containers implement the “Block Device” interface and can operate either on phys-

ical partitions, on subsets of partitions, or on virtual block devices, e.g., network block
devices.

The creator of a container becomes the container’s owner and defines the security

policy including security properties and the access control policy.

It is currently an open question whether containers should only be created by the

admin, by every user, or whether authorised compartments should be able to create
containers themselves. Probably this is an implementation and can be ignored here.

We currently assume that security policies assigned to containers cannot be modi-

fied to ensure that users cannot bypass security policies enforced by applications. To
change the policy a new compartment with a new security policy has to be created and
the data has to be copied using an authorised compartment (ensuring that only com-
partments with read access can transfer the data). Maybe this is a little too simple...

To prevent that compartment use containers with a certain security property, the

user simply gives that compartment no access to such a container. If, on the other
hand, compartments should be able to create their own container, we need a much
more complex security policy defining what the compartments are allowed and what
not. Maybe it is better to define this explicitly by a policy, than doing it implicitly
whenever a new container is created. Thinking...

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

183

ASE

NIQUE

/ UC 60 /

ITLE

Open Container

ESCRIPTION

A compartment opens a container for reading or
writing.

ATIONALE

A compartment locks access to the container.

CTORS

Compartment, Container

RECONDITIONS

The compartment is allowed to use the con-
tainer.

OSTCONDITIONS

The compartment can read data from the con-
tainer (/ UC 80 /) and write data into the con-
tainer (/ UC 70 /).

ORMAL

LOW

1. The compartment invokes the Security

Kernel, specifying the container to be
opened.

2. The Security Kernel returns a message

that the container has been opened suc-
cessfully.

LTERNATIVE

LOW

ERMISSION

ENIED

)

1. The compartment invokes the Security

Kernel, specifying the container to be
opened.

2. The Security Kernel returns an message

indicating that the compartment does not
have permission to use this container.

ASE

NIQUE

/ UC 70 /

ITLE

Store Data to Container

ESCRIPTION

A compartment stores data persistently to a data
container.

ATIONALE

The goal is to persistently store information.

CTORS

Compartment

RECONDITIONS

The container has already been opened by that
compartment using / UC 60 /.

ORMAL

LOW

Compartment

writes a data block into

the container object of the Security Ker-
nel.

2. The Security Kernel reports successful

storage to

Compartment

pen_TC Deliverable 05.1

184

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 80 /

ITLE

Load Data from Container

ESCRIPTION

A compartment loads data from a data con-
tainer.

CTORS

Compartment

RECONDITIONS

The container has already been opened by the
compartment using / UC 60 /..

OSTCONDITIONS

The compartment has access to the loaded data.

ORMAL

LOW

Compartment

sends a load request to a

data block of the container to the Security
Kernel.

Compartment

receives the requested

data of the container object from the Se-
curity Kernel.

LTERNATIVE

LOW

Compartment

sends a load request to a

data block to the container object of the
Security Kernel.

2. The Security Kernel returns an error stat-

ing that an integrity error was detected.

ASE

NIQUE

/ UC 90 /

ITLE

Close Container

ESCRIPTION

A compartment closes a container.

ATIONALE

A compartment unlocks access to that con-
tainer.

CTORS

Compartment

RECONDITIONS

The container has already been opened by the
compartment using / UC 60 /.

OSTCONDITIONS

The compartment cannot read from/write into
the container.

ORMAL

LOW

1. The compartment invokes the Security

Kernel, specifying the container to be
closed.

pen_TC Deliverable 05.1

186

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 110 /

ITLE

Create Container

ESCRIPTION

An authorised entity creates a new container
with a specific security policy.

ATIONALE

A user uses a dialogue to create a new container.

CTORS

User

OSTCONDITIONS

A new container with a unique id has been cre-
ated.

ORMAL

LOW

User

invokes the container management

dialogue of the Security Kernel.

User

invokes the “Add Container” func-

tion, e.g., by pressing a button.

User

defines a new container by select-

ing a unique identifier.

User

defines the security policy of that

container using / UC 120 /.

User

acknowledges and closes the dia-

logue.

Please note that in general, containers can be created by a user using a dialogue,

or by a compartment itself using an appropriate interface. The latter requires a more
complicated access control policy defining who is allowed to create what.

ASE

NIQUE

/ UC 120 /

ITLE

Define Container Security Policy

ESCRIPTION

An authorised entity sets the access permissions
of a container.

CTORS

User

ORMAL

LOW

User

invokes the secure container man-

agement dialogue of the Security Kernel
and defines the new security policy of the
virtual container.

Currently, we do not security policies of containers to be changed to ensure that

security policies enforced by compartments cannot be bypassed. If this is too inflexible,
we may replace this design by a more complicated access control policy that enforces
an identical system behaviour.

Network:

Note that two subtypes of networks exist. The first subtype are those

that are available in hardware, i.e., network devices.

To create a new one, the

AuthorisedEntity

has to create an appropriate driver offering the container interface.

The second subtype is a Virtual Private Network, i.e., a logical partitions of a phys-

ical network that additionally provide certain security properties. To create a new one,

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

187

the

AuthorisedEntity

has to define a physical network and a security policy including

a security domain.

From the perspective of a compartment, it does not make a difference whether a

physical network or a Virtual Private Network is used. Technically, physical networks
are provided by a driver, logical containers by an additional abstraction layer of the
Security Kernel.

ASE

NIQUE

/ UC 130 /

ITLE

Connect to Network

ESCRIPTION

A compartment opens a persistent connection to
a network connection.

ATIONALE

A compartment gets access to a network object.

CTORS

Compartment

RECONDITIONS

Compartment

has permission to use the speci-

fied network. A connection to that network does
not exist yet.

OSTCONDITIONS

The compartment can send data to/receive data
from open the network.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel, specifying the network to be con-
nected to.

2. The Security Kernel connects the spec-

ified network to the invoking compart-
ment.

ASE

NIQUE

/ UC 140 /

ITLE

Query Network Security Policy

ESCRIPTION

A compartment queries the security policy of a
network.

CTORS

Compartment

RECONDITIONS

The compartment has already established a con-
nection to the network using / UC 130 /.

ORMAL

LOW

1. The compartment invokes the Security

Kernel to get the security policy assigned
to that network.

2. The Security Kernel returns a subset of

the policy to the compartment.

pen_TC Deliverable 05.1

188

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 150 /

ITLE

Send Network Packet

ESCRIPTION

A compartment sends a data packet to a net-
work.

CTORS

Compartment

RECONDITIONS

The compartment has permission to access the
network.

ORMAL

LOW

1. The compartment invokes the Security

Kernel to send/receive a data packet
to/from the network.

2. The Security Kernel forwards resp. re-

turns the appropriate data packet.

ASE

NIQUE

/ UC 160 /

ITLE

Receive Network Packet

ESCRIPTION

A compartment receives a data packet from a
network.

CTORS

Compartment

RECONDITIONS

The compartment has permission to access the
network.

ORMAL

LOW

1. The compartment invokes the Security

Kernel to receive a data packet from the
network.

2. The Security Kernel forwards returns the

appropriate data packet.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

189

ASE

NIQUE

/ UC 170 /

ITLE

Create Network

ESCRIPTION

An authorised entity creates a new network ob-
ject

NCLUDES

/ UC 180 / (Define Network Policy)

ATIONALE

Before a physical network device can be used
by clients, it has to be logically created at the
Security Kernel.

CTORS

User

RECONDITIONS

The Security Kernel system is running.

OSTCONDITIONS

A new network object is available.

ORMAL

LOW

User

invokes the network management

interface of the Security Kernel.

User

invokes the “Add Network Device”

function, e.g., by pressing a button.

3. The Security Kernel shows a list of avail-

able (physical) containers.

User

defined a new network object by

defining a unique identifier, and selecting
a physical network.

User

defines the security policy of that

network using / UC 180 /.

User

acknowledges and closes the dia-

logue.

ASE

NIQUE

/ UC 180 /

ITLE

Define Network Policy

ESCRIPTION

An authorised entity defines the policy assigned
to a network object.

ATIONALE

Network Address Translation, bridge, and Vir-
tual Private Network rules have to be assigned
to networks

CTORS

User

RECONDITIONS

The Security Kernel system is running.

ORMAL

LOW

Administrator

defines Network Address

Translation rules, the Virtual Private Net-
work protocol, the authentication secret
of that virtual network, and a security do-
main.

Administrator

acknowledges and closes

the dialogue.

pen_TC Deliverable 05.1

190

OpenTC D05.1 – Basic Security Services

Secure User Interface

ASE

NIQUE

/ UC 190 /

ITLE

Opens new User Interface

ESCRIPTION

A compartments requests a connection to a user
interface.

CTORS

Compartment

RECONDITIONS

The Security Kernel system is running.

OSTCONDITIONS

The compartment can has a trusted path to the
local user of the Security Kernel.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel to open a new user interface.

2. Security Kernel returns a user interface

object.

ASE

NIQUE

/ UC 200 /

ITLE

Render User Information

ESCRIPTION

A compartments sends data to the user inter-
face.

ATIONALE

The compartment renders information for the
user.

CTORS

Compartment

RECONDITIONS

The compartment already opened the user inter-
face using / UC 190 /.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel to send the data.

ASE

NIQUE

/ UC 210 /

ITLE

Receive User Event

ESCRIPTION

A compartments receives data from the user in-
terface.

ATIONALE

A compartment receives user events.

CTORS

Compartment

RECONDITIONS

The compartment already opened the user inter-
face using / UC 190 /.

ORMAL

LOW

1. The compartment receives an event from

the user interface.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

191

ASE

NIQUE

/ UC 220 /

ITLE

User Interface Notify

ESCRIPTION

The Security Kernel sends a notification mes-
sage of a compartment to the user interface.

ATIONALE

Depending on the realisation of the user inter-
face, a user may not directly see messages of
all compartments. Since a compartment must
also not access the frame-buffer of another com-
partment, the notification of the user has to be
realised by the Security Kernel using a trusted
path.

Therefore the user interface provides

a generic interface allowing compartments to
send messages to users even if its own frame
buffer is not visible.

CTORS

Compartment

RECONDITIONS

The compartment already opened the user inter-
face using / UC 190 /.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel to send a notification message.

ASE

NIQUE

/ UC 230 /

ITLE

Closed User Interface

ESCRIPTION

A compartments disconnects a connected user
interface object.

CTORS

Compartment

RECONDITIONS

The

Compartment

already opened the user in-

terface using / UC 190 /.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel to close the user interface.

2. Security Kernel returns an appropriate ac-

knowledge message.

Integrity Measurement:

pen_TC Deliverable 05.1

192

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 240 /

ITLE

Remote Trusted Channel

ESCRIPTION

Establish a Trusted Channel between a remote
client and a local compartment.

NCLUDES

/ UC 280 / (Property Credential Request)

CTORS

RemoteClient

Compartment

OSTCONDITIONS

A secure channel from

RemoteClient

Compartment

has been established that is

bound to certain properties of

Compartment

ORMAL

LOW

RemoteClient

invokes

Compartment

open a trusted channel bound to certain
properties.

Compartment

creates a property creden-

tial using / UC 280 /.

Compartment

returns the credential in-

cluding properties attested by the Secu-
rity Kernel of

Compartment

RemoteClient

uses the credential to ver-

ify the properties and the trustworthiness
of

Compartment

RemoteClient

uses the successfully ver-

ified credential to open a secure channel
to

Compartment

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

193

ASE

NIQUE

/ UC 250 /

ITLE

Remote Property Attestation

ESCRIPTION

A remote client queries properties of a local
compartment.

NCLUDES

/ UC 280 / (Property Credential Request)

CTORS

RemoteClient

Compartment

RECONDITIONS

Compartment

is running on a Security Kernel

that has successfully initialised itself.

OSTCONDITIONS

RemoteClient

knows certain properties of

Compartment

ORMAL

LOW

RemoteClient

invokes

Compartment

retrieve an attestation certificate.

Compartment

creates a new property

certificate using / UC 270 /.

RemoteClient

receives the attestation

certificate from

Compartment

RemoteClient

verifies the trustworthi-

ness of the attested properties.

ASE

NIQUE

/ UC 260 /

ITLE

Property Request

ESCRIPTION

A local compartment A queries information
about the properties of another local compart-
ment B.

CTORS

Compartment A, Compartment B

RECONDITIONS

Both A and B are running on top of the Security
Kernel.

OSTCONDITIONS

Compartment B knows certain properties of
compartment B.

ORMAL

LOW

1. Compartment A requests certain proper-

ties regarding compartment B from the
Security Kernel.

2. The Security Kernel returns a subset of

the properties of Compartment B.

pen_TC Deliverable 05.1

194

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 270 /

ITLE

Property Certificate Request

ESCRIPTION

A local compartment creates a PropertyCertifi-
cate.

ATIONALE

The property certificate is required to prove its
configuration.

CTORS

Compartment

OSTCONDITIONS

Compartment can prove its properties to remote
compartments.

ORMAL

LOW

1. Compartment requests the property cer-

tificate from the Security Kernel by defin-
ing a list of properties to be attested.

2. Compartment receives the property cer-

tificate from the Security Kernel includ-
ing a subset of the requested properties.

ASE

NIQUE

/ UC 280 /

ITLE

Property Credential Request

ESCRIPTION

A local compartment creates a PropertyCreden-
tial.

ATIONALE

The property credential is required to open a
trusted channel.

OSTCONDITIONS

Another client can open a trusted channel to the
compartment.

ORMAL

LOW

1. Compartment requests the property cre-

dential from the Security Kernel by defin-
ing a list of properties to be attested.

2. Compartment receives the property cre-

dential from the Security Kernel includ-
ing a subset of the requested properties.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

195

ASE

NIQUE

/ UC 290 /

ITLE

Remote Trusted Channel via Proxy

ESCRIPTION

A remote client establishes a trusted channel to
a compartment via an attestation proxy running
as a trusted service.

CTORS

RemoteClient

TrustedCompartment

, and

Compartment

NCLUDES

Remote Trusted Channel / UC 240 /, Local
Trusted Channel / UC 240 /

OSTCONDITIONS

A trusted channel between

RemoteClient

and

Compartment

is established.

ORMAL

LOW

RemoteClient

establishes

trusted

channel to

TrustedCompartment

(see

/ UC 240 /).

TrustedCompartment

establishes

trusted channel to

Compartment

(see

/ UC 240 /).

RemoteClient

receives the configuration

Compartment

RemoteClient

derives the trustworthi-

ness of

Compartment

LTERNATIVE

LOW

1. The trusted channel from

RemoteClient

TrustedCompartment

from

TrustedCompartment

Compartment

cannot be established.

RemoteClient

receives a corresponding

message from Security Kernel.

LTERNATIVE

LOW

RemoteClient

establishes

trusted

channel to

TrustedCompartment

(see

/ UC 240 /).

TrustedCompartment

establishes

trusted channel to

Compartment

(see

/ UC 240 /).

RemoteClient

receives the configuration

Compartment

is not deemed trustworthy

RemoteClient

pen_TC Deliverable 05.1

196

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 300 /

ITLE

Usage of TPM Interface

ESCRIPTION

A client uses the interface defined by the TPM
specification of the TCG.

CTORS

Compartment

OSTCONDITIONS

Compartment

can use a TPM interface.

OMMENT

Note that ‘usage of a TPM interface’ does not
necessarily mean that the underlying platform
includes a real TPM. The platform could, for
instance, provide a software TPM only, or an-
other hardware module (e.g., IBM 4758) that is
used to provide the same functionality.

ORMAL

LOW

Compartment

invokes the Security Ker-

nel to gain access to a TPM interface.

Compartment

receives the Compart-

mentID of a compartment vTPM provid-
ing a TPM-like interface.

Compartment

receives the configuration

of vTPM.

Compartment

derives the trustworthi-

ness of vTPM.

A.4

Additional Use Cases for SVPN

C. St¨uble, R. Landfermann, H. L¨ohr, M. Scheibel, S. Schulz (RUB)

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

197

ASE

NIQUE

/ UC 310 /

ITLE

Receive Data

ESCRIPTION

A client of the user system requests data from
the server.

ATIONALE

The client (e.g. browser) obtains data to be
displayed from the server. The server requires
an authentication from the client, because the
server possesses sensitive data which are to be
requested by specific clients only. The authenti-
cation is carried out by means of a secret bound-
/sealed to the TPM of the respective client sys-
tem.

CTORS

Server, client

NCLUDES

RECONDITIONS

A connection to the server has been established.
The client possesses a TPM, to which a valid se-
cret, which is accepted by the server, is bound-
/sealed to.

OSTCONDITIONS

The data is transmitted completely. The con-
nection remains established.

ORMAL

LOW

1. The client requests data from the server.

2. The server requires an authentication.

3. The client’s authentication at the server is

successful.

4. The data exchange between client and

server begins.

LTERNATIVE

LOW

1. The client requests data from the server.

2. The server requires an authentication.

3. The client’s authentication at the server

fails.

4. The procedure “receive data” is aborted.

pen_TC Deliverable 05.1

198

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 320 /

ITLE

Delete Connection

ESCRIPTION

The data exchange between client and server
is finished. The connection between client and
server can be terminated.

ATIONALE

After transmission, the connection has to be ter-
minated.

CTORS

Client, server

NCLUDES

RECONDITIONS

There exists an active connection between client
and server. All data have been transferred be-
tween client and server.

OSTCONDITIONS

The connection has been terminated and the se-
cret is reset where appropriate.

ORMAL

LOW

1. All data have been transmitted from the

client to the server.

2. The client sends an acknowledgement

that all data have been received and that
the connection can be terminated.

3. The server approves the connection ter-

mination and terminates the connection.

4. The connection is terminated.

LTERNATIVE

LOW

1. All data have been transmitted from the

client to the server.

2. The client sends an acknowledgement

that all data have been received and that
the connection can be terminated.

3. The server updates the secret stored in-

side the client by using the still existing
secure connection.

4. The server approves the connection ter-

mination and terminates the connection.

5. The connection is terminated.

Management Interface

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

199

ASE

NIQUE

/ UC 330 /

ITLE

Query Network Security Policy

ESCRIPTION

A compartment queries the security policy of a
network.

CTORS

Compartment

RECONDITIONS

The compartment has already established a con-
nection to the network

ORMAL

LOW

1. The compartment invokes the Security

Kernel to get the security policy assigned
to that network.

2. The Security Kernel returns a subset of

the policy to the compartment.

ASE

NIQUE

/ UC 340 /

ITLE

Create Network

ESCRIPTION

An authorised entity creates a new network ob-
ject

NCLUDES

/ UC 350 / (Define Network Policy)

ATIONALE

Before a physical network device can be used
by clients, it has to be logically created at the
Security Kernel.

CTORS

AuthorizedEntity

RECONDITIONS

The Security Kernel system is running.

OSTCONDITIONS

A new network object is available.

ORMAL

LOW

AuthorizedEntity

invokes the network

management interface of the Security
Kernel.

AuthorizedEntity

invokes the “Add Net-

work Device” function, e.g., by pressing
a button.

3. The Security Kernel shows a list of avail-

able (physical) containers.

AuthorizedEntity

defined a new net-

work object by defining a unique identi-
fier, and selecting a physical network.

AuthorizedEntity

defines the security

policy of that network using / UC 350 /.

AuthorizedEntity

acknowledges

and

closes the dialogue.

pen_TC Deliverable 05.1

200

OpenTC D05.1 – Basic Security Services

ASE

NIQUE

/ UC 350 /

ITLE

Define Network Policy

ESCRIPTION

An authorised entity defines the policy assigned
to a network object.

ATIONALE

Network Address Translation, bridge, and Vir-
tual Private Network rules have to be assigned
to networks

CTORS

AuthorizedEntity

RECONDITIONS

The Security Kernel system is running.

ORMAL

LOW

Administrator

defines Network Address

Translation rules, the Virtual Private Net-
work protocol, the authentication secret
of that virtual network, and a security do-
main.

Administrator

acknowledges and closes

the dialogue.

A.5

Basic PKI Prototype

P. Lipp, M. Pirker (IAIK), G. Ramunno, D. Vernizzi (POL)

The work of WP05d within OpenTC focuses on implementation of components

and services for a TC enhanced PKI. This chapter offers an overview of the prototype
components developed within the first one and a half year of the OpenTC project,
leading up to a basic integrated implementation of a Trusted Computing enabled PKI
framework. As OpenTC progresses, this basic setup will be extended and/or adapted
as needed.

A.5.1

Components

While developing the software the “open” project idea of OpenTC was a guide for
establishing a “release early, release often” policy. The individual components were
released on TrustedJava [39] page, hosted at the well known Sourceforge service, as
soon as they were useful, to stimulate community participation. Received feedback
proved valuable for improving future releases.

The following sections deliberately give only a short overview per package, as this

report can only be a snapshot at a certain point in time of the development. For current
status and detailed descriptions of each component please consult [39] directly.

At the time of writing these sections, the Trusted Platform Agent, a relevant client-

side component is being developed. This component interacts with the Privacy CA and
enables client applications to control local and remote PKI functionalities of the trusted
platform. An outlook is given in section A.5.3.

pen_TC Deliverable 05.1

202

OpenTC D05.1 – Basic Security Services

Java runtime libraries

The Java Architecture for XML Binding (JAXB) technol-

ogy provides a convenient way to process XML content by supporting an easily usable
set of functions for converting XML plain text format to Java objects/classes and vice
versa. XML is utilised in the XKMS protocol (see section A.5.1), which was chosen as
a first target for implementation, as was suggested by the TCG in the [95] document.

Sun Java 5 does not provide JAXB by default. JAXB was part of an external add-on

package called “Java Web Service Development Pack” (JWSDP). With the availability
of Sun Java 6 JAXB is included in the default Java runtime.

IAIK crypto libraries

The IAIK library collection, provided by Stiftung SIC, of-

fers cryptography and certificate support functionalities beyond the functions available
in the Java default runtime libraries:

1. Library “IAIK JCE” provides the enhanced crypto functionality for RSA keys in

TC certificates (OAEP padding, etc.) and ASN.1 en/decoding routines to build
custom certificates, certificate extensions and binary PKI protocols.

2. The “IAIK XSECT” package provides XML digital signature [108] and XML

encryption support [109] as required by the XKMS protocol (see section A.5.1).

3. Finally, “IAIK CMS” provides the certificate extension structures required to

implement the Subject Key Attestation Evidence (SKAE) certificate extension
for an advanced PKI.

The usage of these libraries saves reimplementation of common PKI related func-

tionalities and helps to keep the focus of the workpackage on new components specific
to Trusted Computing.

OpenTC packages

In A.38 packages situated on the right hand side are developed

within OpenTC, but are not primary development goal of the public-key infrastructure
workpackage.

Java TSS interface

The jTss family of packages are components for bridging

high level Java code to the lower levels of the Trusted Computing infrastructure con-
cept. To be more specific, the jTss top level interfaces try to emulate in Java the trusted
service provider (TSP) interface layer as specified by the TCG for the C programming
language.

The interface layer is available in two variants: In the first variant the trusted core

services (TCS) are also implemented in pure Java (and directly talk to the TPM), while
in the second variant the bridge to the TPM is achieved by employing Java native
interface (JNI) calls, wrapping an external TSS (e.g., TrouSerS).

The work to integrate Trusted Computing into Java is mostly task of workpack-

age WP03d, which IAIK is responsible for. The basic building blocks required for
PKI work build on basic functionality – like cryptographic algorithms – that is already
available in Java. The PKI operations require certificate and non-volatile storage func-
tions from a Trusted Software Stack provided by WP03d. TrouSerS is still incomplete
in this area and the TSS from OpenTC partner Infineon only became available very late
in the development of the basic PKI prototype, so was not an option to choose.

PKI packages

This section describes the components which were developed for the

public-key infrastructure work in WP05d.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

203

TCcert

The TCcert utility implements new certificate types and certificate exten-

sions as specified by the TCG for a Trusted Computing enhanced infrastructure.

The following credentials are currently supported:

1. TPM Endorsement Key (EK) credential

2. Platform Endorsement (PE) credential

3. Attestation Identity Key (AIK) credential

TCcert already contains preliminary support structures for the Subject Key Attesta-

tion Evidence (SKAE) certificate extension, which will be of interest for an advanced
PKI.

TCcert can be used as a command-line tool to create certificates from text files

(config files) describing the desired properties. In addition, all structures can be built
on-the-fly in memory too, thus TCcert can be used as the component for TC certificate
creation in a PrivacyCA type of setup.

XKMS

The XML Key Management Specification ([107]) protocol is a way to ex-

press certificate management functions in XML.

The XML messages of XKMS are relatively easy to work with, they are easy to

read and thus also easy to debug. The mapping of Trusted Computing specific func-
tions of a PrivacyCA to the protocol functions turned out to be not always completely
satisfying. A modification or extension of the XKMS protocol may be necessary in
future developments.

The current implementation is advanced enough to be almost fully compatible with

XKMS. It consists of two parts: One part is mostly automatically generated from the
XML schema with help of JAXB (see section A.5.1) to be XKMS structural compliant.
The second part is the API on top, which is responsible for semantic validation of data
and support functions.

Privacy CA server package

As a proof of concept of an actual AIK cycle done

over the network a standalone service offering PrivacyCA functions was implemented.
This component offers basic operations of a Trusted Computing enhanced PKI, able to
handle EK and AIK certificates. One can issue certificates, locate specific ones, get a
validation result or revoke previously issued certificates.

An improved advanced TC PKI is expected to benefit from the experience with

issues discovered in this first attempt.

jTpmTools

The jTpmTools package offers a command-line tool set for basic interac-

tion with the TPM, the TSS and a PrivacyCA service. Thus, available commands cover
WP03d (jTss) specific functions as well as WP05d specific (PKI) ones.

The commands offered for PKI are:

pen_TC Deliverable 05.1

204

OpenTC D05.1 – Basic Security Services

Endorsement key functions:
read pubek

Read the public part of the Endorsement Key.

read certek

Read the EK certificate from Infineon 1.1 and 1.2 TPMs.

PKI Functions:
aik create

Create AIK certificate by simulating a local PrivacyCA
cycle.

xkms aik create

Create AIK certificate, using XKMS protocol.

xkms aik locate

Locate AIK certificate, using XKMS protocol.

xkms aik revoke

Revoke AIK certificate, using XKMS protocol.

xkms aik validate

Validate AIK certificate, using XKMS protocol.

xkms ekcert create

Read public EK and create EK certificate, using XKMS
protocol.

xkms ekcert validate

Validate EK certificate, using XKMS protocol.

Calling a specific function without options produces a list of all possible parame-

ters. The parameters should be self-explanatory.

jTpmTools integrates almost all available components and demonstrates their us-

age. Further, full source code is included for interested parties to study and then take
advantage of provided Trusted Computing support packages.

A.5.2

Applications

Moving Trusting Computing technology components from theory to practical appli-
cation, this section summarises the efforts to use the developed packages in actual
applications or installations.

Test server

IAIK has set up a public PrivacyCA test server at

http://opentc.iaik.tugraz.at/

. This

site runs the server package described in section A.5.1. The offered services can be
used with the JTpmTools package described in section A.5.1. This service is free and
open to the public.

The web pages document the setup of the public PrivacyCA. A list of currently

supported commands and their mapping to the XKMS XML messages is described in
section 6. All certificates used for the setup are offered for download. Links to related
resources complete the documentation. This sites web pages are updated whenever
new features are implemented.

Judging from the server access logs, the site receives requests from all over the

world, thus the goal of dissemination and stimulating community interest can be con-
sidered a success.

PET demonstrator

Early builds of the PKI components were already used in the OpenTC PET demonstra-
tor 2006 effort. Limited functionality at that time forced some parts to contain place-
holder (“fantasy”) values (certificate OIDs etc.), however early use provided valuable
insight into practical deployment problems.

A tighter integration of PKI functionalities is an option for the next demonstrator

effort.

pen_TC Deliverable 05.1

APPENDIX A. APPENDICES

205

WP10 course practicals

In the summer term of 2007 IAIK held a university course “Selected topics of IT-
security: Trusted Computing”. The course included assignments to practice the ac-
quired knowledge. The assignments challenged students to create their own EK certifi-
cates, AIK certificates and use them in a basic mutual attestation context. The programs
were run against the demo site described at the beginning of this section and provided
valuable feedback on stability, scalability issues, etc.

A.5.3

Implementation of the Trusted Platform Agent (TPA)

The architecture of TPA is structured in different layers (high, core and low levels).

The high level layer exposes simplified functions for all operations implemented in
the other layers. Built on top of the high level layer, the console utilities provide
single console commands for each functionality provided by the API. The core and
lower layers includes support packages (TSS and OpenSSL) and OpenTC packages
(credential manager, PKI operations, context manager and local storage).

TSS: this is the TPM Software Stack (TSS) as defined by TCG (e.g., Trousers or

Infineon TSS) used by the system. It provides functions to manage and use the TPM.

OpenSSL is an open source toolkit implementing the Secure Sockets Layer (SSL)

and Transport Layer Security (TLS) protocols as well as a full-strength general purpose
cryptography library. All functions are implemented by two core libraries (libssl and
libcrypto) and are also available through console commands.

The credential manager is responsible to request, parse, locally generate and lo-

cally verify the certificates. It is designed and implemented as extension of OpenSSL
and support the following certificates: Endorsement key (EK), Platform endorsement
(PE), Attestation Identity Key (AIK), X.509 certificates with standard profiles.

PKI operations: this component manages the exchange of operational messages

over the network with the (P)CAs in order to request, revoke, remotely verify or re-
motely locate a certificate. The protocol implemented is XKMS.

The context manager manages the multiplexing of the TPA among multiple appli-

cations.

The local storage allows the user and the system to securely store and retrieve the

credentials.

pen_TC Deliverable 05.1

Bibliography

[1] A Time to Patch, 2006.

http://blog.washingtonpost.com/securityfix/2006/

01/a time to patch.html

[2] Proceedings of the 11th ACM Conference on Computer and Communications

Security, Washington, DC, USA, Oct. 2004. ACM Press.

[3] A. Agbaria and R. Friedman. Virtual Machine Based Heterogeneous Check-

pointing. Software: Practice and Experience, 32(1):1–19, 2002.

[4] D. Andersen, H. Balakrishnan, F. Kaashoek, and R. Morris. Resilient Overlay

Networks. In Proc. 18th ACM Symposium on Operating Systems Principles
(SOSP-2001), pages 131–145, New York, NY, USA, 2001. ACM Press.

[5] W. A. Arbaugh, D. J. Farber, and J. M. Smith. A secure and reliable bootstrap

architecture. In Proceedings of the IEEE Symposium on Research in Security
and Privacy, pages 65–71, Oakland, CA, May 1997. IEEE Computer Society,
Technical Committee on Security and Privacy, IEEE Computer Society Press.

[6] G. Ateniese, J. Camenisch, M. Joye, and G. Tsudik. A practical and provably se-

cure coalition-resistant group signature scheme. In M. Bellare, editor, Advances
in Cryptology – CRYPTO ’2000, volume 1880 of Lecture Notes in Computer
Science, pages 255–270. International Association for Cryptologic Research,
Springer-Verlag, Berlin Germany, 2000.

[7] B. Balacheff, L. Chen, S. Pearson, and G. Proudler. Trusted Computing Plat-

forms: TCPA Technology in Context. Prentice Hall International, 2003.

[8] P. T. Barham, B. Dragovic, K. Fraser, S. Hand, T. L. Harris, A. Ho, R. Neuge-

bauer, I. Pratt, and A. Warfield. Xen and the Art of Virtualization. In Proc. 19th
ACM Symposium on Operating Systems Principles (SOSP-2003), pages 164–
177, October 2003.

[9] A. Bavier, M. Bowman, B. Chun, D. Culler, S. Karlin, L. Peterson, T. Roscoe,

and M. Wawrzoniak. Operating Systems Support for Planetary-Scale Network
Services. In Proc. 1st Symposium on Networked Systems Design and Implemen-
tation (NSDI’04), San Francisco, CA, USA, 2004.

[10] S. Berger, R. C´aceres, K. Goldman, R. Perez, R. Sailer, and L. van Doorn.

vTPM: Virtualizing the Trusted Platform Module. In Proceedings of the 15th
conference on USENIX Security Symposium, pages 21–21, 2006.

206

Open_TC Deliverable 05.1

BIBLIOGRAPHY

207

[11] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker,

S. Eggers, and C. Chambers. Extensibility, safety and performance in the SPIN
operating system. In SOSP95 [90], pages 267–284. Appeared as ACM Operat-
ing Systems Review 29.5.

[12] T. C. Bressoud and F. B. Schneider. Hypervisor-Based Fault Tolerance. ACM

Trans. Comput. Syst., 14(1):80–107, 1996.

[13] E. Brickell, J. Camenisch, and L. Chen. Direct anonymous attestation. In ACM-

CCS2004 [2].

[14] A. Bussani, J. L. Griffin, B. Jansen, K. Julisch, G. Karjoth, H. Maruyama,

M. Nakamura, R. Perez, M. Schunter, A. Tanner, L. van Doorn, E. V. Her-
reweghen, M. Waidner, and S. Yoshihama. Trusted Virtual Domains: Secure
Foundation for Business and IT Services. Research Report RC 23792, IBM
Research, Nov. 2005.

[15] S. Cabuk and D. Plaquin. Security Services Management Interface (SSMI).

Interface document, HP Labs, Bristol, UK, 2007.

[16] A. T. Campbell, M. E. Kounavis, D. A. Villela, J. B. Vincente, H. G. D. Meet,

K. Miki, and K. S. Kalaichelvan. Spawning Networks. IEEE Network, 13(4):16–
29, July-August 1999.

[17] A. T. Campbell, J. Vicente, and D. A. Villela.

Managing Spawned Virtual

Networks. In Proc. 1st International Working Conference on Active Networks
(IWAN ’99), volume 1653 of LNCS, pages 249–261. Springer-Verlag, 1999.

[18] D. Chaum and E. van Heijst. Group signatures. In D. Davies, editor, Advances

in Cryptology – EUROCRYPT ’91, volume 547 of Lecture Notes in Computer
Science, pages 257–265. International Association for Cryptologic Research,
Springer-Verlag, Berlin Germany, 1991.

[19] L. Chen, R. Landfermann, H. L¨ohr, M. Rohe, A.-R. Sadeghi, and C. St¨uble. A

protocol for property-based attestation. In Proceedings of the First ACM Work-
shop on Scalable Trusted Computing, Washington, D.C., USA, November 2006.
ACM Press.

[20] C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Pratt, and

A. Warfield. Live Migration of Virtual Machines. In Proc. 2nd Symposium on
Networked Systems Design and Implementation (NSDI-2005), pages 273–286,
May 2005.

[21] E. Cohen and D. Jefferson. Protection in the hydra operating system. In Proc.

SOSP, pages 141–160, Nov. 1975.

[22] Common Criteria Project Sponsoring Organisations. Common Criteria for In-

formation Technology Security Evaluation, Aug. 1999. Version 2.1, adopted
by ISO/IEC as ISO/IEC International Standard (IS) 15408 1-3. Available from

http://csrc.ncsl.nist.gov/cc/ccv20/ccv2list.htm

[23] F. J. Corbato, J. H. Saltzer, and C. T. Clingen. Multics – the first seven years. In

Spring Joint Computer Conference, pages 571–583. AFIPS Press, May 1972.

pen_TC Deliverable 05.1

208

OpenTC D05.1 – Basic Security Services

[24] C. I. Dalton. Xen Virtualization and Security. Technical report, HP Security

Office Report, August 2005.

[25] R. Davoli. VDE: Virtual Distributed Ethernet. In Proc. 1st International Confer-

ence on Testbeds and Research Infrastructures for the Development of Networks
and Communities (Tridentcom 2005), pages 213–220. IEEE Press, Feb. 2005.

[26] J. R. Douceur and J. Howell. Replicated Virtual Machines. Technical Report

MSR TR-2005-119, Microsoft Research, Sep 2005.

[27] 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.

[28] G. W. Dunlap, S. T. King, S. Cinar, M. A. Basrai, and P. M. Chen.

Re-

Virt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay.
SIGOPS Operating System Review, 36(SI):211–224, 2002.

[29] J. Dyer, M. Lindemann, R. Perez, R. Sailer, L. van Doorn, S. W. Smith, and

S. Weingart. Building the IBM 4758 Secure Coprocessor. IEEE Computer,
34(10):57–66, 2001.

[30] P. England, B. Lampson, J. Manferdelli, M. Peinado, and B. Willman. A trusted

open platform. IEEE Computer, 36(7):55–63, 2003.

[31] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: a virtual

machine-based platform for trusted computing. In ACM Symposium on Operat-
ing Systems Principles (ASOSP), pages 193–206. ACM Press, 2003.

[32] T. Garfinkel and M. Rosenblum. When Virtual is Harder than Real: Security

Challenges in Virtual Machine Based Computing Environments. In Proc. 10th
Workshop on Hot Topics in Operating Systems (HotOS-X), May 2005.

[33] A. Gefflaut, T. Jaeger, Y. Park, J. Liedtke, K. J. Elphistone, V. Uhlig, J. E.

Tidswell, L. Deller, and L. Reuter. The SawMill multiserver approach. ACM
SIGOPS European Workshop, Sept. 2000.

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

Virtual Domains: Toward secure distributed services. In Proc. of the First Work-
shop on Hot Topics in System Dependability (Hotdep05), Yokohama, Japan,
June 2005. IEEE Press.

[35] 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.

[36] H. H¨artig, M. Hohmuth, J. Liedtke, S. Sch¨onberg, and J. Wolter. Performance

-kernel-based systems. In 16th ACM Symposium on Operating System Prin-

ciples (SOSP), St. Malo, France, October 1997. ACM Press.

[37] H. H¨artig, O. Kowalski, and W. K¨uhnhauser. The BirliX security architecture.

Journal of Computer Security, 2(1):5–21, 1993.

pen_TC Deliverable 05.1

BIBLIOGRAPHY

209

[38] S. W. Hunter, N. C. Strole, D. W. Cosby, and D. M. Green. BladeCenter Net-

working. IBM Journal of Research and Development, 49(6), 2005.

[39] IAIK. Trusted Computing for the Java Platform website.

http://trustedjava.

sourceforge.net/

[40] IEEE. Virtual Bridged Local Area Networks. Technical Report ISBN 0-7381-

3662-X.

[41] IETF. Certificate management messages over CMS. RFC 2797.

[42] IETF. EtherIP: Tunneling Ethernet Frames in IP Datagrams. RFC 3378.

[43] N. Itoi, W. A. Arbaugh, S. J. Pollack, and D. M. Reeves. Personal secure boot-

ing. In V. Varadharajan and Y. Mu, editors, Information Security and Privacy
— 6th Australasian Conference, ACISP 2001, volume 2119 of Lecture Notes
in Computer Science, pages 130–144, Sydney, Australia, July 2001. Springer-
Verlag, Berlin Germany.

[44] B. Jansen, H. Ramasamy, and M. Schunter. Flexible integrity protection an

verification architecture for virtual machine monitors. In The Second Workshop
on Advances in Trusted Computing, Tokyo, Japan, November 2006.

[45] X. Jiang and D. Xu. VIOLIN: Virtual Internetworking on OverLay INfrastruc-

ture. In Parallel and Distributed Processing and Applications, volume 3358 of
LNCS, pages 937–946. Springer-Verlag, Berlin, 2004.

[46] B. W. Johnson. Design and Analysis of Fault-Tolerant Digital Systems. Addison-

Wesley, 1989.

[47] A. Joshi, S. T. King, G. W. Dunlap, and P. M. Chen. Detecting Past and Present

Intrusions through Vulnerability-Specific Predicates. In Proc. 20th ACM Sym-
posium on Operating Systems Principles (SOSP-2005), pages 91–104, 2005.

[48] P. A. Karger and R. R. Schell. Thirty years later: Lessons from the Multics

security evaluation. In 18th Annual Computer Security Applications Conference,
Las Vegas, Nevada, USA, Dec. 2002. ACM. Invited paper for the Classic Papers
section.

[49] S. T. King and P. M. Chen. Backtracking Intrusions. In Proc. 19th ACM Sym-

posium on Operating Systems Principles (SOSP-2003), pages 223–236, 2003.

[50] S. T. King, G. W. Dunlap, and P. M. Chen. Debugging Operating Systems with

Time-Traveling Virtual Machines. In Proc. 2005 Annual USENIX Technical
Conference, April 2005.

[51] S. T. King, Z. M. Mao, D. G. Lucchetti, and P. M. Chen. Enriching Intrusion

Alerts Through Multi-Host Causality. In Proc. Network and Distributed System
Security Symposium (NDSS-2005), 2005.

[52] M. E. Kounavis, A. T. Campbell, S. Chou, F. Modoux, J. Vicente, and

H. Zhuang. The Genesis Kernel: A Programming System for Spawning Network
Architectures. IEEE Journal on Selected Areas in Communications, 19(3):511–
526, March 2001.

pen_TC Deliverable 05.1

210

OpenTC D05.1 – Basic Security Services

[53] U. K¨uhn, K. Kursawe, S. Lucks, A.-R. Sadeghi, and C. St¨uble. Secure data

management in trusted computing. In Cryptographic Hardware and Embedded
Systems — CHES 2005, volume 3659 of Lecture Notes in Computer Science,
pages 324–338. Springer-Verlag, Berlin Germany, 2005.

[54] K. Kursawe and C. St¨uble. Improving end-user security and trustworthiness

of TCG platforms. Presented and basis for the panel discussion about TCG
at the 33. GI-Fachtagung, Frankfurt,

http://www.prosec.rub.de/Publications/

KurStu2003.pdf

[55] A. Lenstra and B. de Weger. On the possibility of constructing meaningful hash

collisions for public keys. In Proceedings of the 10th Australasian Conference
on Information Security and Privacy (ACISP’05), 2005.

[56] D. Lie, C. A. Thekkath, and M. Horowitz. Implementing an untrusted operating

system on trusted hardware. In Proceedings of the 19th ACM Symposium on
Operating Systems Principles (SOSP’03), pages 178–192, Bolton Landing, NY,
USA, Oct. 2003. ACM.

[57] J. Liedtke. On microkernel construction. In SOSP95 [90]. Appeared as ACM

Operating Systems Review 29.5.

[58] J. Liedtke. Towards real micro-kernels. Communications of the ACM, 39(9),

1996.

[59] C. I. D. M. J. Anderson, M. Moffie. Towards trustworthy virtualisation environ-

ments: Xen library os security service infrastructure. Research report, HP Labs,
Bristol, UK, 2007.

[60] 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.

[61] J. Marchesini, S. Smith, O. Wild, A. Barsamian, and J. Stabiner. Open-source

applications of TCPA hardware. In 20th Annual Computer Security Applications
Conference. ACM, Dec. 2004.

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

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

[63] National Institute of Standards and Technology (NIST), Computer Systems Lab-

oratory. Secure hash standard. Federal Information Processing Standards Publi-
cation (FIPS PUB) 180-1, Apr. 1995.

[64] G. Necula. Proof-carrying code. In 24th Symposium on Principles of Program-

ming Languages (POPL), pages 106–119, Paris, France, Jan. 1997. ACM Press.

[65] G. C. Necula and P. Lee. The design and implementation of a certifying com-

piler. In Proceedings of the 1998 ACM SIGPLAN Conference on Prgramming
Language Design and Implementation (PLDI), pages 333–344, 1998.

pen_TC Deliverable 05.1

BIBLIOGRAPHY

211

[66] 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.

[67] L. Peterson, T. Anderson, D. Culler, and T. Roscoe. A Blueprint for Introducing

Disruptive Technology into the Internet. SIGCOMM Comput. Commun. Rev.,
33(1):59–64, 2003.

[68] A. Pfitzmann, B. Pfitzmann, M. Schunter, and M. Waidner. Trusting Mobile

User Devices and Security Modules. Computer, 30(2):61–68, 1997.

[69] B. Pfitzmann, J. Riordan, C. St¨uble, M. Waidner, and A. Weber. The PERSEUS

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

[70] G. J. Popek and R. P. Goldberg. Formal requirements for virtualizable third

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

[71] J. Poritz, M. Schunter, E. V. Herreweghen, and M. Waidner. Property attestation

— scalable and privacy-friendly security assessment of peer computers. Tech-
nical Report RZ 3548 (# 99559), IBM Research Division, 05/10/2004 2004.

[72] H. P. Reiser, F. J. Hauck, R. Kapitza, and W. Schr¨oder-Preikschat. Hypervisor-

Based Redundant Execution on a Single Physical Host. In Proc. 6th European
Dependable Computing Conference (EDCC-2006), page S.2, 2006.

[73] H. P. Reiser and R. Kapitza. VM-FIT: Supporting Intrusion Tolerance with Vir-

tualisation Technology. In Proc. 1st Workshop on Recent Advances on Intrusion-
Tolerant Systems (WRAITS-2007), pages 18–22, 2007.

[74] P. Ruth, X. Jiang, D. Xu, and S. Goasguen. Virtual Distributed Environments in

a Shared Infrastructure. IEEE Computer, 38(5):63–69, May 2005.

[75] P. Ruth, J. Rhee, D. Xu, R. Kennell, and S. Goasguen. Autonomic Live Adapta-

tion of Virtual Computational Environments in a Multi-Domain Infrastructure.
In Proc. IEEE International Conference on Autonomic Computing (ICAC-2006),
June 2006.

[76] A.-R. Sadeghi and C. St¨uble. Bridging the gap between TCPA/Palladium and

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

[77] A.-R. Sadeghi and C. St¨uble. Taming “trusted computing” by operating system

design. In Information Security Applications, volume 2908 of Lecture Notes in
Computer Science, pages 286–302. Springer-Verlag, Berlin Germany, 2003.

[78] A.-R. Sadeghi and C. St¨uble. 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, New York, NY, USA,
2005. ACM Press.

[79] A.-R. Sadeghi, C. St¨uble, 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.

pen_TC Deliverable 05.1

212

OpenTC D05.1 – Basic Security Services

[80] D. Safford. The need for TCPA. White paper, IBM Research, Oct. 2002.

[81] 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.

[82] R. Sailer, T. Jaeger, X. Zhang, and L. van Doorn. Attestation-based policy en-

forcement for remote access. In ACMCCS2004 [2].

[83] 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.

[84] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and implementation

of a TCG-based integrity measurement architecture. In SSYM’04: Proceedings
of the 13th conference on USENIX Security Symposium, pages 16–16, Berkeley,
CA, USA, 2004. USENIX Association.

[85] K. Seamons, M. Winslett, and T.Yu. Limiting the disclosure of access con-

trol policies during automated trust negotiation. In Proc. 2001 Symposium on
Network and Distributed System Security, San Diego, CA, Apr. 2001. Internet
Society.

[86] K. E. Seamons, M. Winslett, T. Yu, L. Yu, and R. Jarvis. Protecting privacy dur-

ing on-line trust negotiation. In Worhshop on Privacy-engancing Technologies
(PET2002), San Francisco, CA, April 2002. Springer LNCS.

[87] J. S. Shapiro, J. M. Smith, and D. J. Farber. EROS: a fast capability system.

In Proceedings of the 17th ACM Symposium on Operating Systems Principles
(SOSP’99), pages 170–185, Kiawah Island Resort, near Charleston, Sout Car-
olina, Dec. 1999. Appeared as ACM Operating Systems Review 33.5.

[88] S. Smalley, C. Vance, and W. Salamon. Implementing SELinux as a Linux

security module. Report #01-043, NAI Labs, Dec. 2001. Revised May 2002.

[89] S. W. Smith. Outbound authentication for programmable secure coprocessors.

In D. Gollmann, G. Karjoth, and M. Waidner, editors, Proceedings of the Seven-
thEuropean Symposium on Research in Computer Security (ESORICS), volume
2502 of Lecture Notes in Computer Science, pages 72–89, Zurich, Switzerland,
Oct. 2002. Springer-Verlag, Berlin Germany.

[90] Proceedings of the 15th ACM Symposium on Operating Systems Principles

(SOSP’95), Copper Mountain Resort, Colorado, Dec. 1995. Appeared as ACM
Operating Systems Review 29.5.

[91] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau.

The Flask security architecture: System support for diverse security policies. In
Proceedings of the 8th USENIX Security Symposium, pages 123–139, Washing-
ton, D.C., USA, Aug. 1999. USENIX.

[92] A. Sundararaj and P. Dinda. Towards Virtual Networks for Virtual Machine Grid

Computing. In Proc. 3rd USENIX Conference on Virtual Machine Technology
(VM 04), pp. 177-190, 2004.

pen_TC Deliverable 05.1

BIBLIOGRAPHY

213

[93] TCG. TCG software stack specification.

https://trustedcomputinggroup.org

Aug. 2003. Version 1.1.

[94] TCG. TCG software stack specification.

https://trustedcomputinggroup.org

Aug. 2006. Version 1.2.

[95] TCG Infrastructure Working Group (IWG).

TCG Infrastructure Working

Group Reference Architecture for Interoperability (Part I).

Trusted Com-

puting Group:

https://www.trustedcomputinggroup.org/specs/IWG/IWG

Architecture v1 0 r1.pdf

, June 2005. Specification Version 1.0 Revision 1.

[96] The Trusted Computing Group. Main specification version 1.1b, 2003. Available

from

https://www.trustedcomputinggroup.org

[97] The Trusted Computing Group. TPM version 1.2 specification changes, Oct.

2003. Available from

https://www.trustedcomputinggroup.org

[98] J. Touch. Dynamic Internet Overlay Deployment and Management using the

X-bone. Computer Networks, 36(2-3):117–135, 2001.

[99] B. Traversat, A. Arora, M. Abdelaziz, M. Doigou, C. Haywood, J.-C. Hugly,

E. Pouyoul, and B. Yaeger. Project JXTA 2.0 Super-Peer Virtual Network, 2003.

http://www.jxta.org/project/www/docs/JXTA2.0protocols1.pdf

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

http://trousers.sourceforge.

net

[101] Trusted Computing Group. TPM Main Specification v1.2, November 2003.

https://www.trustedcomputinggroup.org

[102] Trusted Computing Group. TPM main specification. Main Specification Version

1.2 rev. 85, Trusted Computing Group, Feb. 2005.

[103] Trusted Computing Platform Alliance (TCPA). TCPA PC-specific implementa-

tion specification, Sept. 2001. Version 1.00.

[104] J. Tygar and B. Yee. Dyad: a system using physically secure coprocessors.

Technical report, Carnegie Mellon University, Pittsburgh, PA 15213, 1993. a
preliminary version is available: CMU-CS-91-140R.

[105] VMWare.

VMWare Double-Take.

http://www.vmware.com/pdf/vmware

doubletake.pdf

[106] X. Wang, Y. Yin, and H. Yu. Finding collisions in the full SHA1. In Advances in

Cryptology – CRYPTO ’2005, Lecture Notes in Computer Science. International
Association for Cryptologic Research, Springer-Verlag, Berlin Germany, 2005.

[107] XKMS key management standard 2.0.

http://www.w3.org/TR/xkms2/

, June

2005.

[108] XML digital signature standard.

http://www.w3.org/TR/xmldsig-core/

[109] XML encryption standard.

http://www.w3.org/TR/xmlenc-core/

[110] B. S. Yee. Using Secure Coprocessors. PhD thesis, School of Computer Science,

Carnegie Mellon University, May 1994. CMU-CS-94-149.

pen_TC Deliverable 05.1

Document Outline