isolating arm platforms toward secure virtualized embedded systems

Isolating ARM platformsToward secure virtualized embedded systems

Michele PaolinoVirtual Open [email protected]://www.virtualopensystems.com

22/05/14TRESCCA - Trustworthy Embedded Systems for Secure Cloud Computing

Agenda

Intro - Why isolation? Security through isolation

KVM isolation sVirt ARM TrustZone TEE

Toward a complete platform Boot loader and Virtual Entropy Shared memory and TrustZone Secure World environment Virtualized TEE API and Migration

DRM Scenario


We cannot guarantee that SW has no security holes, but we can try to reduce the threatened area by stronger isolation

One of the basic concepts of information security is isolation

Isolation is stronger if implemented with hardware support.

Isolate applications from sensitive assets, helps preventing attacks to integrity, confidentiality and availability of the system.

Why isolation?


The security solution designed by Virtual Open Systems within the TRESCCA project is based on the isolation provided by:

KVM hypervisor

sVirt

TrustZone

GlobalPlatform Trusted Execution Environment (TEE)

Security through Isolation

In the next slides, after a brief overview of these technologies, the Virtual Open Systems' ongoing efforts towards a fully functional and isolated platform will be shown.


Virtualization is the ability of a system to run different unmodified operating systems concurrently (virtual machines or VMs).VMs that exploit the CPU virtualization extensions (i.e. ARM VE, Intel VT), are hardware isolated regarding:

Memory Interrupts Exceptions

Compared with standard applications running on a singleOS, virtualization provides an extra layer of isolation.

KVM Hypervisor

QEMU/KVMprocess

VM

KVMKVM

Linux kernel


sVirt uses security kernel features like SELinux to go beyond the Discretionary Access Control system, using the Mandatory Access Control security policy to isolate virtual machines[*].

sVirt isolation

QEMU/KVMprocess

VM

KVMKVM

sVirt

Isol

atio

n

Untrusted App

Untrusted App

Linux kernel

Unique labels are defined for the processes and resources of each VM.

Isolation among virtual machines and between host and VMs.

The possibility to enable or disable features per VM (USB devices, SAMBA, NFS, etc.).

[*] Virtual open systems published an how to guide to deploy KVM/ARM VMs with SELinux http://www.virtualopensystems.com/en/solutions/guides/kvm-svirt-omap5/


TrustZone is the security solution provided by ARM in all Cortex A* processors (ARMv7 and v8 architectures)

TrustZone isolation

ARM v7 and v8ARM v7 and v8

Non Secure WorldTrustZone Isolation

Monitor

Secure kernel

Secure World

DRM DecryptDRM Decrypt

Trusted App Untrusted

AppUntrusted

App

kernel

The first one for a Rich OS (Android, Linux, etc.).

And the other for a Secure OS, root of the security chain.

Creates two execution Worlds (Non Secure and Secure):


TrustZone is the security solution provided by ARM in all Cortex A* processors (ARMv7 and v8 architectures)

TrustZone isolation (2)



Monitor

Secure kernel

Secure World

DRM DecryptDRM Decrypt

Trusted App Untrusted

AppUntrusted

App

kernel

Is able to exclusively dedicate a device to the Secure World.

Implements a secure context switch mechanism through the TrustZone Monitor.

Securedevice


GlobalPlatform standardizes the Trusted Execution Environment (TEE), a secure area that guarantees that sensitive data is stored, processed and protected in a trusted environment

GlobalPlatform TEE

The secure area can be implemented using TrustZone.

The TEE Client API is used by the untrusted application in the Non Secure World.

The TEE Internal API is used in the Secure World.



Monitor

Secure World

Trusted App

Untrusted App

Untrusted App

kernel

Trusted App Trusted App

TEE Internal API

TEE Client API Secure kernel

TEE APIs are a standardization of an RPC mechanism between the a secure and a non-secure area.


Combining virtualization, TrustZone, GlobalPlatform TEE and sVirt it is possible to provide strong isolation for ARM platforms

But this is not enough to implement a fully functional, isolated and complete platform. In fact there is still a need of: A secure boot procedure

Virtual Entropy for VMs

A complete execution environment in the TrustZone Secure World

Virtualized TEE Client API

A secure shared memory mechanism

Migration

The main innovative Virtual Open Systems' contribution to the TRESCCA project is the design and integration of these features in ARM v7 and v8 platforms equipped with the HSM (Hardware Security Module).

Highly isolated platforms


Secure Bootloader

Initializes the system (and the HSM module in the TRESCCA platform)

Installs the SSBL (Second Stage Boot Loader) and checks its integrity

If OK, FSBL launches the SSBL The SSBL checks the integrity of the secure OS

and loads it The OS in the Secure World, after an additional

integrity check will launch the Non Secure World OS through a specific bootloader

Power on

FSBL

SSBL

Secure World OS boot

Non Secure W. boot loader

Non Secure World OS boot

A secure boot mechanism is the key component of the whole system.

After the power on, the on-chip First Stage Boot Loader (FSBL) is executed from an on-chip RAM. Soon after:


Virtual Entropy

Virtual Entropy enables Guest operating systems to collect random numbers using virtual Random Numbers Generators (RNG).

This is a pivotal factor for cryptography applications running in the VMs.

Two possible implementations: If an RNG device exists in the system, it is configured in the secure

World, and the VMs access it through TEE. If not, a SW RNG is implemented as a Trusted Application in the secure

world and used through the TEE.


HW HW

TrustZone Secure World Environment

When the system is running, the root of trust is in the Secure World.

Microkernel OS (small TCB). Management of sensitive devices

(secure drivers). Security services as applications

(e.g. en/decrypt functions, key management, etc.).

Monitor procedure to securely interact with the Non Secure World.

Secure World

TrustZone Isolation

HSM-mem

DecodeFunctionDRM Decrypt

HSM-NoC

SecureOSSSM-mem

SNoCCM

TEE Internal API

Monitor memory


HW HW

TrustZone Secure World Environment (2)

When the system is running, the root of trust is in the Secure World.

HSM-NoC and HSM-mem are configured in the Secure World.

TEE handles security sessions for the VMs.

VMs identity and integrity can be attested locally and remotely before each execution.

Secure World

TrustZone Isolation

HSM-mem

DecodeFunctionDRM Decrypt

HSM-NoC

SecureOSSSM-mem

SNoCCM

TEE Internal API

Monitor memory


Virtualized TEE Client API

Non SecureWorld

KVMKVM TZ Driver

Kernel Kernel

QEMU/KVM

QEMU TPMDevice

VM

Linux kernel

TEE Client API

HWHWsV

irt Is

olat

ion

TEE Client Application

Sharedmemory

Monitor

The TEE Client API is virtualized to be executed in the virtual machines

A specific QEMU device (and a related Linux driver) gathers the requests from the guest applications and forwards them to the Secure World.

A shared memory mechanism is used to pass data to the Secure World.


Shared Memory

A shared memory mechanism is the basic building block for many applications and plays a key role for IO performance.

Two shared memory mechanisms are needed: Secure -> non Secure World

It is needed to feed secure applications in the secure World and to get the answers back in the Non secure world.

Guest -> host and/or other guests[*]It is needed to move data in and out the virtual machines.

[*] More info about the zero copy shared memory mechanism developed by Virtual Open Systems can be found at: http://www.virtualopensystems.com/en/products/vosyshmem-zerocopy/


VMs Hybrid Migration for heterogeneous cloud

Migration refers to the process of moving an instance of a virtual machine from one host (source) to another (destination).

There are two types of VM migration: Off-line migration Live migration


VMs Hybrid Migration for heterogeneous cloud (2)

The migration in QEMU/KVM depends on the type of processor used to make the emulation.Two types: KVM: guest code runs directly on the physical processor of the host

achieving best performance. Host and guest have the same architecture.

TCG: the guest processor is emulated by the host. With TCG we can run ARM virtual machines on hosts with x86 or many other architectures.

Building a bridge between KVM and TCG processors we can enable heterogeneous cloud, migrating VMs among different architectures.


VMs Hybrid Migration for heterogeneous cloud (3)

With the KVM-TCG migration implemented by Virtual Open Systems[*], it is possible:

Move virtual machines between ARM hosts and hosts powered by a variety of different architectures

Exploit the great performance boost deriving from KVM where possible

[*] The patch to enable hybrid migration has been pushed to the QEMU-devel ML https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg03660.html


A secure DRM Player

All the described technologies will be exploited together in the multimedia playback of DRM contents Scenario.

Requirements: DRM data and code must run isolated from the others applications DRM media framework can be connected to multimedia HW accelerators User and accounting information need to be protected The Secure World must support legacy kernel or applications Encrypted data can be retrieved on a storage device or as a stream

through a network connection


Software Security Module (DRM Player Overview)

Secure WorldNon Secure World

KVMKVMHost

communicationagent

kerneluser

Kernel Kernel

QEMU/KVM

QEMU Device

Android VM

HWHW

TrustZone Isolation

HSM-mem

DecodeFunction

DRM Decrypt

HSM-NoC

SSM-mem

SNoCCM

TEE Internal API

Monitor

sVirt

Isol

atio

n FirewallVM

Net devices

DriverDriver

Linux

Encrypted data

3G

VFIO

TEE Client API

Android DRM Plugin

memory

TEE communicationagent

SecureOS

Android DRM Framework

Sharedmemory

Sharedmemory


A secure DRM Player – Non Secure World

The Non Secure world executes the user interface along with standard applications (media player, browser, mail client, etc).

HW modules such as codec accelerators can be securely shared between the Secure and the Non-Secure applications.

Hardware virtualization (KVM) and IO acceleration (VFIO) will provide best performance for the applications in the VMs.

Sensitive application data are stored encrypted in RAM: the DRM player is protected.

Cloud provider can't access to the user' sensitive data.

TEE APIs is interposed between Secure Services and VMs.


A secure DRM Player – Secure World

The Secure World runs excusively security related applications.

A micro kernel (i.e. FIASCO.OC) guarantees a small TCB. The HSM can be used also inside the Secure World to isolate

Secure Services. Non Secure applications and malicious kernel modules are

isolated from the Secure Services. A secure boot procedure firstly run the Secure World OS.


Questions?


Thank [email protected]

http://www.virtualopensystems.com

isolating arm platforms toward secure virtualized embedded systems

Documents