Security/Tizen 4.X TEE Support

From Tizen Wiki
Jump to: navigation, search


This page contains description of Trusted Execution Environment support in Tizen platform that is enabled since Tizen 4.0. It covers information on system architecture, trusted application development, their integration with Tizen system and a guide on securing access to different TEE implementations.

Trusted Execution Environment - overview

Relationship between elements of REE and TEE.

Trusted Execution Environment (TEE) is an execution environment that runs separately from the regular (rich) execution environment (REE). It is utilizes the ARM TrustZone H/W technology, which prevents the regular system from accessing the TEE memory (and possibly other resources such as devices or HID). TEE is capable of running trusted applications (TAs), which can be accessed from the rich operating system through appropriate APIs. This allows the REE side to use many facilities like encryption or secure storage while benefiting from the reduced attack surface of the OS residing in the trusted environment.

From REE side, TEE communication is done using a C libteec library - its APIs allows to run & communicate with trusted applications.

TA is much like a library - it implements well-defined, specific entry points in order to be run in TEE (similar to "main" symbol in each program binary in rich environment).

TEE standard does not specify where & how the TAs should be stored, but most existing implementations store them on the REE filesystem, with additional protection (signatures/encryption of binaries).

The company that defines the APIs for TEE is Global Platform (client API on REE side, TA entry point APIs to be implemented by TAs and TEE internal APIs that TA can use). For more details regarding the client and TA APIs, the official standards are accessible on Global Platform's website here.

Trusted Execution Framework in Tizen (TEF)

Trusted Execution Framework (TEF) in Tizen is a collection of packages providing special APIs for application and services. These APIs are implementation of, or based on, Global Platform's TEE Client API Global Platform API specifications. TEF is prepared to work, with none or minimal changes, with any implementation of TEE ("TEF backends"), as long as it provides the Global Platform's TEE Client API.

TEF architecture - high-level view

Relations between TEF elements and their place in Tizen.

TEF is centrally organized around the tef-libteec package, which serves the role of "metapackage" providing GP TEE Client API in C language. This library is responsible - based on configuration - to direct each its API call to specific TEF backend configured in the system. In Tizen platform images, two TEE implementations can be found:

  • tef-simulator - a software (non-secure) implementation of TEE. Used on the emulator in order to test TAs
  • OpTEE - an open-source implementation of TEE, supported by Tizen on devices like Raspberry Pi 3. More details on OpTEE can be found here. OpTEE is available on common-wayland-3parts-armv7l-rpi3, tv-wayland-armv7l-rpi3 and iot-boot-arm64-rpi3 images. Guide on using RPi3 can be found here: RPi3 with Tizen guide

Components of TEF in Tizen Platform

  • tef-libteec C library
    • location:
    • provides C-level API confomant to GP Client API specification [Global Platform API specifications]
    • configuration: script (use it to set TEF backend; for example, in TEF backend's RPM %post section); configuration file is located typically in /etc/tef/tef.conf
    • special notice: this package is present in all images; if no backend is present, it will act as a "dummy", returning TEEC_ERROR_NOT_IMPLEMENTED error on each API call
  • tef-simulator backend
    • location:
    • provides a simulator that can execute trusted applications - it requires the TA to be recompiled for Intel architecture; this backend is used only on emulator images of Tizen
    • internally, it is a systemd service communicating over Unix domain socket with its client library, also implementing the GP Client API; the client library is interfaced by tef-libteec

TEF available APIs and tests

TEF is available only on devices that support the Tizen feature. It provides different APIs for different components of the Tizen system:

  • applications can use the public C link, Javascript link or C# APIs link
  • system services can use the tef-libteec package API or specific TEF backend libaries (at cost of less portability)
  • trusted applications - to achieve best portability, trusted applications should use the GP TEE Internal API Global Platform API specifications

Tests for TEF (tef-libteec) are kept currently in security-tests repository on trustzone branch:

Trusted Applications in TEF (TAs)

TEF doesn't specify any APIs that trusted applications (TAs) should be using - because each TEF backend (OpTEE, tef-simulator, any other possible TEE implementation) can support different set of APIs. Some may support, for example, full POSIX, other TEE implementations may not. There is however, a "common denominator" that almost all implementations of TEE support - it is the Global Platform Internal API specification [Global Platform API specifications]. This API provides basic interface to access hardware security features such as encryption, key operations and other functionalities.

There are two ways to develop a TA:

  • developing stand-alone TA (& CA) using Tizen Studio SDK & TA development plugin
  • developing system-level TA as part of the operating system

In Tizen platform, TA storage is organized on REE filesystem, in /opt/tastore directory.

TA development

Developing TAs as part of the platform

An example of Tizen system service having a dedicated TA is key-manager wiki article, which, since Tizen 5.0, can use TEE-based encrypton, storage & key generation. The TA is implemented in separate repository and uses development kit packages provided by TEF - see details here:

TEF access control

Because tef-libteec is only a library (and it cannot be a service due to nature of libteec API, which is based on passing shared memory segments to- and from- TEE), numerous access control mechanisms must be used to protect each TEF backend (TEE implementation) from unprivileged access. Below is a guide on how to secure any other specific TEE implementation, with examples in Tizen:

  • All sensitive TEF backend processes & objects that don't provide direct interfaces to REE should be configured in a way that no other REE process has access to them
    • example in Tizen: tef-simulator service and OpTEE supplicant service should run with dedicated System::TEF Smack label to which there is no Smack rule in the system
    • example in Tizen: OpTEE has a "privileged" and "unprivileged" kernel device node to communicate between REE and TEE; the privileged device node (used by OpTEE supplicant only) should also have the System::TEF Smack label
  • All sensitive TEF backend processes & objects that are present in REE should be configured with minimal set of privileges allowed for their normal operation (least principle rule)
    • example in Tizen: tef-simulator is not having full root user permissions
  • All communication end-points (sockets, device nodes) that are used to communicate with TEF backend should be configured so that only processes with sufficient privileges should be able to get access to them