Controls Device Manufacturer M Task Provider PA Device Owner O Task Provider PB Task Provider PC
C o ntr o ls C o ntr o ls C o ntr o ls
Trust Optional trust Dependence on allocation of resources / availability Figure 14: Trust relations between different stakeholders in Ty TA N.
tasks running on the platform. Therefore,O isolates the privileged software (i. e., theOS) from all tasks.
Task providersP do not trust any part of the system except for theTCB. Furthermore, P are not trusted by any other party, i. e., M, O and all other P. However, all task providers have to trust and rely on the device owner with regard to resource access (indicated by the black arrows in Figure14), i. e., O can simply refuse to execute a task, provide network services, etc. Furthermore, anyP can freely decide to trust other tasks on the system and collaborate with them (green dashed arrows in Figure14), in particular, after establishing secure channels between secure tasks where both involved tasks are authenticated.
Trust Layers. Ty TA N has three different layers of trust. The first layer is the TCB (marked green in Figure15). This layer is trusted by all parties and is protected by the hardware. The second layer is privileged software, such as the OS, and is generally untrusted, colored red in Figure15. However, since it has control of the resource usage it can deny the execution of the system or parts of the system. The third layer comprises the tasks running on the system. “Normal” tasks are completely untrusted, they are shown as white boxes in Figure15. They are not integrity protected; thus, they can be manipulated by theOS and depend on both, the system’s TCBand all privileged software. Secure tasks are integrity protected and can be trusted by their respective task providers (violet and blue in Figure15). Optionally, task providers can establish further trust relations among each other. Importantly, secure tasks as well as normal tasks cannot disturb the operation of the platform.
Trust Model for Task Providers.Figure15shows the trust model from the perspective of task providerPA, providing Secure Task A. Naturally,PA trusts its own task. Furthermore,
PA has to trust the platform’sTCB, marked green.PA does not need to fully trust the
OS, this is enabled by Ty TA N’s security architecture that isolates Secure Task A from theOS. However, theOShas still control of the resource usage on the platform and could refuse to execute tasks. Therefore, theOScould launch a Denial-of-Service (DoS) attack against Secure Task A (and any other task), which meansPAhas to trust the OSwith
regard to availability.
PAdoes not need to trust any other task because all tasks – secure tasks and “normal”
tasks – are isolated from each other. In a multi-stakeholder system,PA might not know
and trust the other task providers and their tasks coexisting on the platform. However, even ifPAdoes not assume other task providers to be malicious, other tasks might be
attacked and controlled by an adversaryADV threatening PA’s task without Ty TA N’s
isolation guarantees.
Nevertheless,PA can decide to have a secure and authenticated connection to a subset
of the other tasks. For instance,PA could collaborate with Secure Task B, i. e., trustPB.
While establishing a communication channel, tasks can mutually verify their integrity and gain trust in each other.
3. 1 . 2 . 2 Hardware Platform
We focus on resource-constrained embedded systems as used in many automotive and industrial applications. The term embedded system is widely used for a large variety of systems reaching from micro-controllers-based systems with minimal functionality to quite powerful systems such as home routers or smartphones. Sometimes even enterprise routers are attributed as embedded systems, even-tough they are as big, complex, and powerful as full-flashed servers [115].
Our prototype is based on a system consisting of approximately 400, 000 gates. Pro- duced in a fairly old structure size, this results in a chip in the scale of 1 mm2. Further-
more, the system has very low power consumption (1 mW/100 Mhz). Typical examples of devices that fall into this category are the TI MSP430, ARM Cortex M3, and Intel Siskiyou Peak. All devices need to be equipped with anEA-MPUin order to be used for Ty TA N. We used Intel’s Siskiyou Peak with anEA-MPU[226] as base platform for
Ty TA N. TheEA-MPU concept that was introduced in TrustLite [226] is described in
detail in Section2.1.1. For the remaining of this section we will consider this class of systems when using the term embedded system.
3. 1 . 3 Ty TA N Design
Ty TA N combines different functional and security components in an architecture that provides both real-time capabilities and strong isolation for security critical tasks. Ty - TA N’s architecture and its main components are described subsequently.
Hardware RTM Remote Attest Secure Storage Secure Task A Secure Task B Normal Task C Normal Task D
EA-MPU Platform Key (KP) CPU
Peripheral (Storage, I/O) IPC-Proxy
EA-MPU Config Int. Mux Secure Boot
Real-Time OS Privileged
Software Unprivileged
Software
Figure 15: Ty TA N system architecture providing secure tasks that are mutually isolated and isolated from theRTOSthrough strong hardware-based isolation, indicated by bold borders. Normal tasks are not isolated from the RTOS, shown by the dashed line. Components marked green comprise Ty TA N’sTCB.
3. 1 . 3 . 1 Ty TA N Architecture
Ty TA N combines hardware security features with real-time capable software compo- nents. It providesTEEs that allow the isolated execution of security critical tasks without trusting the system’s privileged software components, in particular theOS. Hence, Ty - TA N provides Trusted Execution Environments (TEEs) for embedded systems that are conceptional similar to Software Guard Extensions (SGX) enclaves. TyTAN goes beyond other platforms that aim to achieve similar isolation properties by providing real-time guarantees, which requires that all functionalities of the system have the property of either having bounded execution time3
or being interruptible. Ty TA N ensures that all security critical components are not endangered by these properties.
Ty TA N adapts existing components, e. g., theRTOS, in order to integrate them with the underlying security architecture TrustLite [226]. Ty TA N extends the traditional
hierarchical isolation model of computer architectures and creates a new, orthogonal delimitation between trusted and untrusted system components. This allows Ty TA N to utilize features and capabilities of the real-time RTOS to create a secure real-time capable system with a minimal TCB, i. e., the TCBdoes not need to contain complex functionalities such as a real-time scheduler.
Figure 15 shows Ty TA N’s architecture. At the hardware level, Ty TA N relies on the security guarantees provided by an embedded system security architecture such as TrustLite [226], which provides basic mechanisms such as memory isolation, a platform
key and secure boot capabilities. The hardware capabilities are managed by privileged software. TyTAN divides the privileged software into components that are critical (green in Figure15) and those that are non-critical for security. Ty TA N’s goal is to minimize the amount and complexity of critical components.
Critical software components are responsible for managing the security functionalities of the system, e. g., by managing the access to the platform key or configuring memory
3 The maximal length of uninterruptible execution is application dependent. In Section3.1.6we evaluate the
isolation in theEA-MPU. All uncritical tasks are managed by the untrustedOS compris- ing the majority of privileged software. The critical components are protected from the untrusted components utilizing the underlay platform isolation mechanisms, i. e., using theEA-MPU. Secure boot ensures the integrity of all critical software components that are loaded at boot time. TheEA-MPUconfiguration module takes control of theEA-MPU before any untrusted code is loaded, hence, it can maintain the isolation of itself and all other critical components throughout the run time of the system.
Ty TA N delegates as many tasks as possible to unprivileged software. This allows Ty TA N to minimize complexity and allows these components to benefit from the functionalities provided by the privileged system software. In particular, security critical tasks, such as the Root of Trust for Measurement (RTM) or theRAservices, can rely on the real-time scheduling capabilities of theRTOS. Ty TA N ensures these components’ correct behavior even if their execution is interrupted by the RTOS, thus they do not need to have bounded execution times without violating the real-time properties of the platform.
TyTAN maintains legacy compatibility by supporting “normal” tasks that are isolated from other tasks on the system. However, their memory is not protected from accesses by the untrustedRTOS. Secure tasks, on the other hand, are protected from theRTOS, i. e., the integrity and confidentiality of their memory is ensured by Ty TA N. Nevertheless, theRTOScan dynamically manage both “normal” and secure tasks, i. e., create, destroy and suspend them during run time.
For secure tasks Ty TA N provides a set of security functionalities, in particular, all secure tasks are measured when created. This measurement serves as an identity for each tasks and can be used for remotely attesting the integrity of a task, locally identifying tasks to establish secure channels between tasks, and to store data securely allowing secure tasks to maintain data confidentiality across multiple executions.
3. 1 . 3 . 2 Ty TA N Components
Ty TA N, see Figure 15, is composed of several components that are described in the following. The hardware and components shown in green comprise TyTAN’sTCB. The Operating System (OS) is not part of theTCB.
Tasks.TyTAN supports two types of tasks: normal tasks are accessible by theOS, they are only isolated from other tasks. Secure tasks are isolated from all other software including theOS. Each secure task t has a unique identifier idt, i. e., the hash digest of its binary
code, which is measured during task creation. All tasks are loadable, unloadable, and suspendable at run time.
TyTAN ensures that secure tasks are isolated throughout their entire lifetime guaran- teeing their integrity and confidentiality during execution. Furthermore, TyTAN ensures the deletion of all information from memory before accesses is given to untrusted com- ponents, e. g., when a task is unloaded, the task’s memory is erased before handed back under the control of theOS. Similar, registers are erased before execution is passed to the OS, e. g., when a secure task is interrupted or exits. The initial integrity of secure tasks is measured by Ty TA N and can be validated via remote and local attestation.
Real-time Operating System (RTOS). Ty TA N adapts and extends an existing RTOS (FreeRTOS [15]) and inherits the real-time properties of thisOS, i. e., Ty TA N provides
real-time scheduling for “normal” tasks as well as for secure tasks. It ensures that all tasks and system components can be interrupted to allow other pending operations to proceed within the time frame allocated to them.
Our modifications and extensions to FreeRTOS do not violate the system’s underlying assumptions for a RTOS. In particular, a real-time kernel has to fulfill the following requirements as identified by Stankovic and Rajkumar [362]:
1. Multi-tasking support
2. Priority-based preemptive scheduling 3. Bounded execution time for primitives 4. High-resolution real-time clock
5. Special alarms and time-outs 6. Real-time queuing
7. Delay processes, i. e., interrupt and resume task execution
Multi-task support, priority-based scheduling, high-resolution clock, alarms, and time- outs as well as the real-time queuing of FreeRTOS are not influenced by TyTAN. However, the ability of interrupting and resuming tasks had to be adapted with the introduction of secure tasks. We will detail on Ty TA N’s handling of secure task in Section3.1.4.2 and explain how secure task can be managed by FreeRTOS’s preemptive scheduler. Another important property that is affected by Ty TA N’s extensions is requirement 3 (bounded execution time for primitives). As we already identified in our requirements analysis (cf. Section3.1.1), TyTAN is designed such that all primitives have a maximum execution time or to be interruptible. In Section3.1.6we evaluated the execution time of all primitives we added to FreeRTOS and show that all uninterruptible executions have bounded execution times.
The OS is not included in Ty TA N’s TCB, i. e., it is not trusted with respect to the security properties of secure components and tasks of the platform. Therefore, all op- erations by which a maliciousOScould violate these properties, e. g., modify a secure tasks initial memory content, are validated by Ty TA N. As theOS is in control of the systems resources and controls, for instance, the execution schedule of tasks and access to peripherals, it can prevent the loading or execution of tasks. However, theOScan only impair availability of the platform or individual tasks.
Central Processing Unit (CPU) and Peripherals.The Ty TA N platform comprises uni- versal hardware components including processing units, i. e., a CPU, and peripheral devices, such as network interfaces, storage devices, etc. These components are part of Ty TA N’sTCB.
Peripherals are accessed through memory-mapped configuration registers. This allows controlling access to devices via memory access control mechanisms, i. e., using the
EA-MPUaccess to peripherals can be provided (exclusively) to secure tasks. TheCPUis shared, executing trusted and untrusted software. Ty TA N ensures that no information is leaked between consecutively executed entities by erasing theCPU’s internal state, e. g., registers, before executing untrusted software.4
EA-MPU. Ty TA N utilizes an Execution-Aware Memory Protection Unit (EA-MPU) [226]
as memory isolation mechanism. An EA-MPU is a hardware component providing: (1) memory access control enforcement based on the code that attempts to access a data region, e. g., the stack of a task can be accessed only by the task itself; (2) each task can be invoked only at a dedicated entry point; and (3) interrupts are handled such that the memory isolation rules of theEA-MPUare enforced, i. e., a (malicious) interrupt handler cannot gain any information about the state of an interrupted task. Section2.1.1provides a more detailed explanation of theEA-MPU.
Platform Key.The Ty TA N hardware platform comes with a platform key Kp. Access to
this key is controlled by theEA-MPU. Only trusted software components have access to Kp. Additional keys can be derived from Kp, e. g., forRAor for secure storage.
An asymmetric key pair forRAcan be derived from the device’s symmetric platform key Kpusing it as seed to instantiate a Deterministic Random Bit Generator (DRBG) [40],
which is used to in the generate of the asymmetric key pair [280]. The public key needs
to be transmitted to the Certification Authority (CA) in an authentic way, e. g., it can be extracted during manufacturing the device. TheCA generates a certificate for the device’s public key, which is later made available to the remote verifier.
Secure Boot. Ty TA N’s trusted software components (i. e., EA-MPU driver, Int Mux, IPCProxy,RTMtask, Remote Attest and Secure Storage) are loaded with secure boot and isolated from the rest of the system by theEA-MPUto ensure their integrity. These components are not higher privileged than theOSand only some of them have the same privileges as theOS(e. g.,EA-MPUdriver).
3. 1 . 3 . 3 Trusted Execution
Ty TA N provides trusted execution by isolating secure tasks and trusted software com- ponents based on the access control enforced by theEA-MPU. Each security primitive isolated from all other system components. The individual security primitives are de- scribed in the following.
EA-MPUDriver.The dynamic handling of tasks requires theEA-MPUto be dynamically configurable. This is performed by theEA-MPUdriver, which sets the memory access control rules in theEA-MPUwhen loading or unloading secure tasks. TheEA-MPUrules for the static components (including theEA-MPUdriver itself) are set during secure boot.
Attestation.In order to prove the integrity of a task t to a local or remote verifier, the Root of Trust for Measurement (RTM) task computes a cryptographic hash function over the binary code of each secure task when it is created. This hash digest serves as identity of the task (idt). To meet real-time requirements, theRTMtask must be interruptible during
the hash calculation. By isolating t’s memory and preventing its execution, Ty TA N ensures that t is immutable while the RTM task computes idt. This guarantees the
correctness of the measurement and enables reliable verification of idt.
The authenticity of idt and its origin is crucial. Ty TA N supports different authentica-
tion methods for local and Remote Attestation. TheEA-MPUensures that only the RTM task can modify idt. For local attestation, idtcan be used as both identifier and attestation
report of t. TyTAN’RAmechanism uses Message Authentication Code (MAC) with an attestation key Ka to prove the authenticity of idtto a remote verifier. Ka is derived from
Kpand only accessible to the Remote Attest task.5
Secure Inter-Process Communication (IPC). Ty TA N enables secure communication between tasks via an IPC proxy, which forwards messages m from a sender S to the receiverR. S copies m and the identity idR ofR in general-purposeCPU-registers and invokes theIPCproxy via a software interrupt.6
TheIPCproxy determinesR’s memory location and writes m and idS toR’s memory. This implicitly authenticates m and idS since theEA-MPUensures that only theIPCproxy can write toR’s memory. To efficiently transfer large amount of data between tasks, theIPCproxy can set up shared memory