GrouNation - Tag - Xen

PolyXene secure Operating System

webmaster — Mon, 07 Feb 2011 08:38:00 +0100

PolyXene is a certified high-security operating system that enables secure access, from one single work station, to several distinct and non-standardized networks and to data of different sensitivity levels.

Virtualization enables the simultaneous operation of several operating systems on one single machine. As a certified confinement mechanism, virtualization authorizes functional evolution without compromising security issues.

Virtualization provides the opportunity for substantial financial savings since it enables companies to free themselves from hardware constraints (challenge for reducing of number of machines) and improve management performance through enhanced hardware administration, optimum infrastructure usage and simplified maintenance interventions. Last but not least, it provides a high-level guarantee of data integrity and security.

PolyXene is a high security operating system (CC - EAL 5), ultra-reliable operating system using multi-level technology operating in an MILS architecture (Multi Independent Levels of Security).

The aim of this technology is to secure access from one single work station to data of different sensitivity levels and to control the exchange of data of different classification levels between entities and/or storage peripherals via multi-level gateways.

PolyXene provides a set of security features :

internal and external communication control,
on-the-fly disk encryption for confidentiality and integrity,
strong authentication,
RBAC control for administration operations,
log and audit functionalities,
remote administration
...

See detailed architecture.

Qubes OS and formally verified microkernel

admin admin — Fri, 28 May 2010 09:41:00 +0100

Qubes is an open source operating system designed to provide strong security for desktop computing. Qubes is based on Xen, X Window System, and Linux, and can run most Linux applications and utilize most of the Linux drivers. In the future it might also run Windows apps.

You must have heard about it before: formally verified microkernels that offer 100% security... Why don't we use such a microkernel in Qubes then? (The difference between a micro-kernel and a type I hypervisor is blurry. Especially in case of a type I hypervisor used for running para-virtualized VMs, such as Xen used in Qubes. So I would call Xen a micro-kernel in this case, although it can also run fully-virtualized VMs, in which case it should be called a hypervisor I think.) Formally verified microkernel, by Joanna Rutkowska

Joanna Rutkowska who is the founder and CEO of Invisible Things Lab (see complete profile)

This article follows the launch of a new open source operating system,Qubes , designed to provide strong security for desktop computing. Based on Xen, Linux and the X Window System.

The system is based on the Xen architecture which allows a strong isolation of virtual machines. The end-user can own multiple virtual machines to run its applications. These virtual machines are lightweight VMs based on Linux. The system is administrated from the Dom0 virtual machine which is by definition a privileged virtual machine, but without network access to prevent remote attacks. And finally, the system uses the VT technology to run in unprivileged virtual machines the network and storage hardware support.

A specific interface allows the user to switch between these virtual machines.

The full Qubes architecture is described in this document Qubes OS Architecture.

This looks like an existing secure Operating system PolyXene, with EAL5 common criteria evaluation and formally verified code, realized by the Bertin Technologies company.

Virtualizing the Trusted Platform Module

webmaster — Sun, 07 Sep 2008 17:42:00 +0000

Based on the IBM Research Report on vTPM, this article intends to detail the concepts of a TPM emulation on virtualized context.

Introduction

The goal of this article is to present the IBM Research Report about the vTPM: Virtualizing the Trusted Platform Module (see Attachments).

The main goal is to mix two important technologies : Virtualization and Trusted Computing or specifically the Trusted Platform Module.

These two technologies can ensure complementary requirements :

Virtualization for the high availability, the integrity and the isolation of each virtual machine.
TPM for the security, the chain of trust and the remote attestation.

Virtualizing the TPM is required to provide TCG services in the virtual machines. The virtualization base system should handle the TPM device for its usage and export to each virtual machine a TPM emulated device to extend the chain of trust. So each virtual machine will be able to use the cryptographic resources, store secret objects realize remote attestations ...

The first requirement is then to ensure the same level security provided by the hardware TPM for the virtualized TPMs. Moreover, new requirements are introduced due to the specificities of a virtualized architecture.

The TPM virtualization architecture will propose answers to the following technical requirements :

How to implement a full chain of trust, from the hardware root of trust to the virtual machines through the hypervisor ?
How to implement a full featured TPM device in the virtual machines ?
How to migrate a virtual host, including its TPM associated data ?
How to support remote attestation including the full virtualized system and environment ?

Architecture

The vTPM implementation is composed of :

a vTPM manager which manages the hardware TPM and provide services to manages multiple TPM emulated devices,
a vTPM instance for each virtualized host, which implements the full TCG TPM 1.2 specification,

The architecture is based on a client/server model. Each virtualized host communicates through a client TPM driver. The server TPM driver runs in the virtual host where is implemented the vTPM.

Associating vTPM instances with their VM :

Association between a vTPM and a VM is a one to one association. This association is maintained during the lifetime of the VM. This is a security requirement because vTPM manages secret objects owned by the VM.

Hardware Secure Co-processor support :

The architecture must also support a vTPM subsystem embedded in a hardware secure co-processor (see next figure). The first VM is the owner of the hardware and uses a vTPM instance for its own purpose. A proxy is implemented in the first VM to forward all VM commands to the hardware card.

Root vTPM instance :

First, two requirements are exposed :

API used by the application must keep the same for a software or a hardware implementation. In all cases the common point is to use a dedicated VM to provide the virtual TPM functionalities.
Modern virtualization systems provide migration capabilities. For example export a VM from a host to another one. In the context of a vTPM instance it should be interesting to keep association between the VM and its vTPM during the process of migration. But it is important to guarantee the authenticity and the confidentiality of the data.

So, the architecture of the virtual TPM will be designed as follows. A virtual TPM is a TPM capable of generating new vTPM childs. This means that a system must always provide a Root vTPM instance with cryptographic functions to generate keys, encrypt data, migrate keys between instances ... This Root instance will provide the mechanisms to store and encrypt the state of a vTPM for a migration process.

These functionalities are only available from the root instance and especially to the owner of the root instance. All extented commands require the owner authorization (owner's password). Furthermore, the concept if privileged instance has been introduced. A privileged instance is capable to spawn and manage new child instances. This privilege is inherited and can be passed to a child instance. This mechanism offers advanced features to create a complexe hierarchy of vTPM.

Independent key hierarchy :

Each vTPM has a Storage Root Key (SRK) as root for its key hierarchy and an Endorsment Key (EK). To allow instance and vTPM migration, these keys are unlinked from the key hierarchy of a TPM hardware component. This also allows faster key management and cryptographic operations.

However, if the SRK, EK and other data of virtual TPM are stored in a persistend storage, they must be stored encrypted with a key stored in the hardware TPM device. This symmetric key must be sealed or protected with a password.

Extended command set

The vTPM specifications add a set of commands to the TPM 1.2 specifications.

vTPM management commands to manage the life-cycle of a vTPM : CreateInstance, DeleteInstance, SetupInstance. SetupInstance is used to setup a vTPM and prepare it with the right PCR values.
vTPM migration commands : GetInstanceKey, SetInstanceKey, GetInstanceData, SetInstanceData.
vTPM utility commands : TransportInstance, LockInstance, UnlockInstance, ReportEnvironment. TransportInstance is a specific command to create a communication tunnel between an instance and one of its child instances.

vTPM migration

The vTPM migration capability is provided by a secure protocol which ensure authenticity and confidentiality. Symmetric and assymetric keys are used to encrypt the vTPM state on the source virtual TPM and decrypt it on the destination virtual TPM. The migration process is based on the following protocol :

Linking a vTPM to its TCB

Trust in the Virtual Machine is not necessary because it runs in a virtualizion system, controlled by an hypervisor. Then the trust in the VM is interesting only if the trust in the environment (TCB, hypervisor...) is guarantee. For this reason the chain of trust must be guaranteed from the hardware TPM to the vTPM, from the TCB to the VMs.

So, the architecture proposed provides in the vTPM PCRs a merged version of the measures. A lower set of PCRs in the vTPM shows measures from the hardware TPM and the upper the measures for the VM. By this way, a challenger can see all relevant measures during a remote attestation. The next figure shows an example of this mechanism.

Implementation for Xen

 To be continued ... (see Attachments for details)