UEFI vs. ARM TrustZone

Question

I understand UEFI has a Secure Boot feature that is now for all Win 8 (tablets, and smartphones). How does this fit in with AMR's TrustZone for example? Is UEFI like a firmware TPM that can sit as a Trusted App in TrustZone's Normal Domain after the TrustZone TEE has loaded the Secure Domain? I am unclear how these two fit together - or perhaps they are competing technologies??

Answer 1

I won't go into any controversies that surround UEFI, Secure boot or TPM in general (out of scope), so I'll try and answer as directly as possible.

UEFI is (for all intents and purposes) a BIOS 'replacement' that sits at the BIOS level (between hardware and OS). UEFI Secure boot has to be supported by the firmware (BIOS); UEFI Secure boot is essentially a way to prevent 'unsigned' code from booting, as of right now Windows 8, Windows Server 2012 and certain Linux distributions have signed UEFI secure boot keys that are able to use the feature.

TPM (trusted platform module) is a standard that is usually implemented as a separated hardware module that can be used to generate crypto keys (among other things). It is not the same as UEFI (nor are they of related organizational groups); TPM is a hardware level crypto that is used for things like full disk encryption and DRM and has to be physically installed as a separate module (though many new PC/laptops/motherboards include the option to come pre-installed with a hardware TPM) where as UEFI sits between the hardware and the OS itself. Technically speaking, one could use UEFI (Secure boot) with a TPM. TPM's are manufactured by many different companies. UEFI is firmware that is 'manufactured' (coded) by a few companies as well.

UEFI and TPM are (typically) found only on x86/x64 platforms (i.e. Intel/AMD/PPC CPU/chipsets). ARM (a competing CPU/chip maker to Intel and AMD) offers something similar to a UEFI/TPM setup and that's their TrustZone. TrustZone is something that is built into the ARM chips themselves it's slightly different in that UEFI is at the BIOS and TPM is 'baked' into hardware modules, but ARM's TrustZone can be utilized 'system wide'; the idea being that you have a mixture of UEFI/TPM type functionality in each device that has an ARM chipset in it (which could be anything from a keyboard/mouse to a monitor and printer).

One thing to note with ALL of these technologies is that at a software level, most of the 'secure' functionality needs to be implemented in order to be used. For instance, you could have a PC with a TPM and use TrueCrypt for full disk encryption (TrueCrypt does not support TPM). This is the same with ARM's TrustZone; the system/software integrator needs to take advantage of those capabilities for it to be effective/work (in other words, just because something is physically on your machine does not mean it's 'active').

Answer 2

txtechhelp answer is interesting and I believe he gives an x86 perspective. TrustZone at the lowest level is a mechanism to partition ARM software into two worlds. One is the secure world and the other is the normal world. It is never a complete solution by itself. The ARM licensee (Freescale, Samsung, TI, Apple, BroadCom, etc) must provide hooks to complete the solution. For instance the TZASC, is a bus controller that is TrustZone aware. The gist of this is that DMA attacks in a sufficiently configured system are not possible.

In order to configure the bus controller and the secure world, by necessity TrustZone boots in secure mode. This implies that any system that tries to implement security with TrustZone has secure boot.

From the description of UEFI, if anyone has an exploit for a signed kernel, then they can steal secrets either directly or by using a DMA device (side-steps MMU). If the secrets are not accessible via the bus, then this is not possible. TrustZone tries to allow two sets of code to run. So an unsigned version of Linux maybe used with Trusted code which does a secure boot and sets up the bus controller to restrict bus masters and slaves. This Trusted code may just be a set of routines which does authentication and encryption/decryption as per a TPM; there must also be some hardware to provide protected secret keys in this case.

The trusted code should be a minimum set of functionality. It may be an OS or simply a set of routines/API depending on the requirements. Just as with UEFI, an exploit here can subvert security. However, as the footprint should be minimal/reduced, the attack vectors should be smaller.

See: TrustZone Whitepaper for more information.