MyTEE: Own the Trusted Execution Environment on Embedded Devices

Abstract

process may require vendor involvement for using proprietary APIs and performing security verification [9].This can increase the time-to-market for new third-party services.We propose MyTEE to address the limitations of hosting TEE on embedded devices.It is designed with the harsh assumption that most TrustZone extensions are not supported (other than the security state of the CPU).In other words, TrustZone Address Space Controller (TZASC) and TrustZone Memory Adapter (TZMA) for memory access control, and TrustZone Protection Controller (TZPC) for establishing a secure IO channel, are not supported.The input/output memory management unit (IOMMU) for preventing malicious direct memory access (DMA) is not available either.Without such hardware security primitives, MyTEE isolates the TEE region, prevents DMA attacks, and dynamically builds a secure IO channel between the TEE and peripherals.Memory protection is achieved by deliberately managing the page tables.The stage-2 page table [15] (i.e., extended page table on x86 [3]) that maps the intermediate physical addresses to physical addresses is leveraged to isolate the TEE from the untrusted OS.Part of MyTEE is implemented as a tiny hypervisor, which can also be compromised.Because stage-2 paging-based protection is not effective once the attacker obtains hypervisor privileges, we also ensure that the page table of the hypervisor does not map the TEE and is immutable.However, even with careful management of the page table, security of MyTEE could still be broken by malicious DMA.To address this, we implemented a DMA filter that traps, verifies, and emulates any memory-mapped IO (MMIO) to the DMA controller.To realize secure IO, we delegated a task to the untrusted OS that sends a request to the peripherals (e.g., TPM commands) instead of porting the device drivers in the TEE.Minimal but essential components for trustworthy communication, such as the buffer for peripheral output and MMIO region for peripheral controllers, are protected by the stage-2 paging.Then, the partial code block of the device driver is given hypervisor privilege to access the secure objects and log the transactions for future validation by the trusted application (TA).We implemented MyTEE on a Raspberry Pi 3 development board equipped with a Broadcom BCM2837 SoC that does not support TrustZone extensions.OP-TEE [4] and Raspbian OS with Linux 4.15 were hosted as the TEE and the rich execution environment (REE) software platform, respectively.The ARM trusted firmware was patched to enable memory isolation.The DMA filter and MyTEE services (e.g., privilege escalation of a device driver) were implemented as part of the Abstract-We propose a solution, MyTEE, that enables a trusted execution environment (TEE) to be built even in worstcase environments wherein major hardware security primitives (e.g., ARM TrustZone extensions for memory access control) are absent.Crafting page tables for memory isolation, filtering DMA packets, and enabling secure IO exist at the core of MyTEE.Particularly for secure IO, we shield the IO buffers and memorymapped registers of the controllers and securely escalate the privilege of the partial code block of the device drivers to provide permission to access the protected objects.By doing so, the need to host the device driver in the TEE (in whole or in part), which can potentially introduce a new attack surface, is exempted.The proof-of-concept (PoC) of MyTEE is implemented on the Raspberry Pi 3 board, which does not support most of the important security primitives for building the TEE.Additionally, three secure IO examples with the hardware TPM, framebuffer, and USB keyboard are demonstrated to show the feasibility of our approach.

Topics & Concepts