Loading code securely in the Trusted Execution Environment (ARM)

Question

I am reading up on TEE in ARM. I am looking for pointers for the following questions:

• How does the TEE load code from the OS securely and guarantee that its not malicious code?

  I am guessing the code is signed and the TEE can verify the signature. So that brings up other questions --

  • Who is loading the code? The loader in the OS or does the TEE have its own loader that allows it to load into the OS' environment?

  • If the OS loader is loading it how can it be trusted on a rooted device?

I feel like I am missing something here. Can some one point me to the correct literature may be?

Answer 1

In a nutshell, the TEE does have its own bootloader.

The basic idea is that the CPU boots from ROM. This ROM is programmed to load a software image from persistent storage, verify that it is signed by a public key which is stored in the ROM, and transfer the execution to this software image. On an ARM platform with TrustZone, the CPU starts in secure mode, so this first software — the TEE — is executed in secure mode. At some point the TEE switches to non-secure mode and loads another software image: the “rich OS”, i.e. the main OS running on the platform.

The MMU with TrustZone separates a secure world running the TEE and a non-secure world running the rich OS. The non-secure world is less privileged than the secure world, so it cannot access the secure world's memory, in the same way a userland program cannot access the kernel's memory (though the technical details are somewhat different). There isn't much publicly available documentation about TrustZone and associated technologies, but you can find some on ARM's website.

As real life is never so simple, what happens in practice is a chain where the ROM loads a first bootloader which loads a second bootloader, etc. As long as each stage verifies the signature of the code image of the next stage, only authenticated code can be executed. One of these loads a non-secure, non-authenticated bootloader in the normal world which in turn loads the main operating system (e.g. U-Boot and Linux). This is a secure boot chain, similar to what Microsoft requires for Windows 8. A secure boot chain ensures that only code approved by the hardware manufacturer can run. The idea of the TEE separation is to apply secure boot to the TEE, but not necessarily to the main OS.

Note that what secure boot guarantees is that only authenticated code runs. Malicious code can run if it got signed by the hardware manufacturer for whatever reason.

A Microsoft paper §6.7 gives an overview of an example secure boot chain. A Texas Instruments whitepaper describes a secure boot chain in more detail.

Answer 2

I can answer from how Qualcomm's and Trustronic's TEE based platforms does this.

Who is loading the code? The loader in the OS or does the TEE have its own loader that allows it to load into the OS' environment?

Loader in OS or TEE(if it has a loader) can load the code/data, and inform TEE that loading is done. Usually its OS side loader. Then the code/data memory region is marked as secure memory,by TEE, so not accessible anymore by Rich OS. Then it can be authenticated and based on reult put on use.

If the OS loader is loading it how can it be trusted on a rooted device?

Rooting simply means, user have root privileges, so you can create/modify files in system or data or any partition which is usually kept unmodifiable by a normal user in Android. That affects only the user privilages in Rich OS and so only in Non-Secure Mode. TEE and other secure assets and resources reside in Secure Memory. Not accessible even on rooted android phones.

A bit more on rooting: when you run "fastboot oem unlock" command, in a nutshell, you are only allowing unsigned kernels to be loaded by the bootloader, and so eventually custom ROMs. This is very late in the boot chain probably 4th stage. Trustzone configurations happens very early 1st or 2nd stage. Platforms are still secure. Rooting doesn't give hackers full control, if secure assets are configured/used in right way. No need to worry.