Technology

Definition

Security of Embedded Systems (System-on-Chips, Devices, Applications, Communication Protocols, and Services) relies on an initial source of trust called Root-of-Trust (RoT).

An RoT is, ideally, a hardware based computing engine, hosting software and data.

• Software aims at implementing security critical services (e.g. Identification, Authentication, Authorization, Integrity checking, Platform measurement)
• Data represents non-confidential values, such as configuration settings, IDs, certificates
• Keys are confidential values (secret and private)

Software and data are immutable, or mutable with strong protection against modifications by unauthorized parties.

An RoT must be fundamentally trusted because its misbehavior cannot be detected since its code and data integrity cannot be verified prior to its execution.

The architecture of the RoT must take into account the following constraints:

• Must be first executable code
• Secure by design
• Small size
• Access to Non-Volatile Memory such as One-Time Programmable (OTP) efuse, internal and/or external flash
• Self-contained with minimal interface and minimal dependency on the rest of the platform

Concept

During their lifecycle, Embedded Systems are owned by different stakeholders (Silicon Vendor, OEM, End-User, Operator, Service Provider).

A mutually agreed transfer of ownership of the device assets illustrates the concept of Chain of Trust between stakeholders.

An RoT represents the initial authority from which the Chain of Trust will be built. The RoT serves as the foundation of the Chain of Trust to initiate a sequence of authentication steps used to transfer trust to each subsequent step. Examples of such Chain of Trust architectures are Secure Boot procedures implemented in most smartphones, and Trusted Platform Module (TPM) on personal computers (TPM is standardized by the Trusted Computing Group®).

Ownership transfer

When a Chain of Trust is built on a device, it becomes possible to establish administration/ownership policies between the different stakeholders controlling the device at any time. For a given authority in the Chain of Trust, three options are possible:

• Remain the primary central authority of the device with a well-defined set of rights
• Authorize duplication or delegation of some rights to a secondary authority requesting control on part of the device while keeping its own rights
• Transfer all its rights to a secondary authority requesting full ownership on the device while keeping rights at least on its applications/assets

When such architecture is deployed, special care needs to be taken for failure analysis of returned material, when the Chain of Trust may need to be reversed.

Overview

The Trusted Execution Environment (TEE) represents a system solution (comprising dedicated hardware and software) that ensures physical isolation of a separate execution environment running alongside a Rich Execution Environment (REE) hosting a Rich OS.

The TEE offers physical protection against logical software attacks originating in the REE. The TEE authorizes and protects execution of critical software, called Trusted Applications (TAs). These TAs offer their trusted services to security demanding applications running in the REE. They manipulate sensitive code and data.

TEE should be considered as the foundation of the run-time security environment embedded in the device. The TEE must obtain trust from an RoT to become itself a trust authority as part of the Chain of Trust described previously.

TEE is built upon 2 main components:

• TEE hardware which is platform dependent and can follow different deployment models in embedded systems (see below)
• TEE software which is made of a Trusted OS, an adaptation layer to the TEE hardware and a set of Trusted Functions exposing APIs to TAs to perform secure operations (crypto, time, secure storage, user interface, etc.)

TEE Architecture

TEE Architecture can follow two main deployment models:

Virtualized Model where TEE is hosted on the main CPU running the REE using a CPU HW Virtualization mechanism (such as ARM® TrustZone®) splitting CPU execution environment into two areas: secure and non-secure. This model is appropriate when:

• A centralized System Security Architecture is required with a TEE accessing peripherals shared between REE and TEE (Trusted UI, DRM Content Path)
• High performance, leveraging main CPU capabilities, is critical for use case execution

Discrete IP Model where TEE is hosted on a standalone subsystem including a CPU and exclusive security resources. This subsystem communicates through IPC/mailbox mechanism with the REE. This model is appropriate in embedded systems where:

• Strong hardware isolation is required between secure and non-secure
• The main CPU does not support a hardware virtualization capability
• Security use cases require exclusive access to resources located in a self-contained subsystem

The TEE isolates hardware resources access and sensitive software/data, yet offers controlled access to such resources through well-defined APIs. Isolation is enforced between:

• The TEE and the REE
• The TEE and its TAs
• The TAs (each TA is independent from the others, and a TA cannot perform unauthorized access to security resources from another TA)

The TEE provides to TAs an execution environment with a complete range of APIs that can be categorized as follows:

• Memory management (shared and non-shared)
• Multithreading management (mutexes, context switching, inter-process communication, etc.)
• Secure Storage
• Cryptographic library
• Time management

The TEE is a concept that has been promoted for many years. GlobalPlatform  is defining a common architecture and a set of APIs to standardize the TEE in order to promote an ecosystem of TAs, and to reduce fragmentation.

GlobalPlatform TEE Compliance aims at verifying that TEE and TA providers conform to GlobalPlatform specifications, and particularly to TEE Client and Internal APIs. To that purpose, GlobalPlatform has developed Test Suites to measure this compliancy.

GlobalPlatform has also defined a Protection Profile to enable OEMs integrating a TEE on their device to go through a Security Evaluation. Passing such an evaluation grants a certificate equivalent to Common Criteria (CC) certification up to EAL2+.

Provisioning Overview

Connected devices store increasing amounts of assets and data.

• IDs
• Configurations
• Security assets such as keys, credentials, passwords, certificates
• Personal information such as contacts, messages, photos, video clips
• Sensitive data such as health, financial or enterprise data

The device ability to protect assets at different stages of its lifecycle (from manufacturing to end-user) is fundamental regardless of whether they have been generated or provisioned in the device.

For assets provisioned in the device, it is critical to ensure asset protection from the source to the device.  Such provisioning can follow two paths:

• Factory asset management enabling injection of assets in the production line
• Cloud based asset management enabling asset provisioning from Device Manufacturer and/or Operators and/or Service Providers

An end-to-end provisioning solution consists in the integration of 3 main modules:

• A Remote Asset Administration infrastructure, responsible for communicating and provisioning assets to the device
• An Asset Management Agent in the device, responsible for administrating asset storage (ideally hosted in the TEE)
• An Asset Management Stack running in the REE, leveraging platform connectivity and responsible for bridging the Remote Asset Administration infrastructure and the Asset Management Agent

Secure Storage

A Secure Storage mechanism makes it possible to prevent compromising or exposing data following any adverse event, such as loss, theft, malwares or attacks. Such mechanism is required in order to protect assets provisioned or generated in the device. The concept of Secure Storage addresses two main objectives:

• Storage of information in a non-volatile memory (OTP, Internal Flash or External Flash, or a combination of any of these memories)
• Storage of information in a protected area (physical isolation, memory encryption)

Security Domains

Security Domains are used to perform the provisioning of assets in the device in isolated containers managed by stakeholders owning these assets.

A Security Domain implements the following administration responsibilities:

• Store assets
• Manage assets’ attributes and access rights policy
• Install applications in a secure and controlled manner, authorizing access to the corresponding services (e.g. payment application for a bank, smart meter application for an energy provider)
• Provide application personalization framework
• Enable service aggregators to manage assets over multiple devices and/or multiple services (e.g. a distributor offering content from multiple owners)

An initial (or root) Security Domain must exist before any service can be provided. The presence of this Initial Security Domain allows the loading of initial (or root) assets during the platform manufacturing process. Subsequently, additional Security Domains can be instantiated in a hierarchical manner throughout the Chain of Trust.