Extra features required for TrustZone to provide main security features

Question

The paper Trustworthy Execution on Mobile Devices: What Security Properties Can My Mobile Platform Give Me? describes 5 desired security features for mobile devices:

1. Isolated Execution
2. Secure Storage
3. Remote Attestation
4. Secure Provisioning
5. Trusted Path

If I understand correctly, one cannot design a system that leverages TrustZone's bare capabilities alone to provide these features.

My question is:
What extra features are required (for a system that uses TrustZone) to provide these security features?

---

My current understanding is as follows (Beware: There are many mistakes here, as @Gilles pointed out):

• Secure Boot is a must.
  I.e., upon boot, the first code to run on the device must be trusted (e.g., burned into a ROM chip by the manufacturer), and then each piece of code is verified before it is run, at least until control is transferred to normal world.
  
• Combining Secure Boot and TrustZone is sufficient to provide Isolated Execution and Trusted Path.
• Isolated Execution and Trusted Path can be leveraged to provide a Secure Storage that is based on a secret known only to the user, e.g.:
  • A trusted app in secure world prompts the user for a secret password.
  • The app derives a symmetric key from the password, and removes the password from memory.
  • The app uses the key to encrypt some secret data (or other keys) and stores it on disk.
  • The app removes the key (that was derived from the password) from memory.
  • Later, when the user wishes to access their secret data, the trusted app prompts the user for the password, and then uses it to derive the key and decrypt the secret data.
• In order to provide Remote Attestation, as well as Secure Storage that is based on sealing data to this specific device, a feature that allows only trusted* secure world code to access a device-unique key is required, e.g., Samsung Knox's Device-Unique Hardware Key (DUHK). (This is also discussed in this answer.)
  * 'trusted' might mean that this code runs after a Secure Boot. E.g., the Knox whitepaper explains that in Samsung Knox devices the DUHK becomes inaccessible if "the device has ever been booted into an unapproved state".
• Finally, Remote Attestation can be leveraged to provide Secure Provisioning, e.g.:
  • A trusted app in secure world generates an asymmetric key pair.
  • The app creates a remote attestation that includes a signature of the public key.
  • The app sends the attested signature alongside the public key to the remote machine that holds the data that is to be provisioned only to a trusted app in secure world.

Answer 1

Strictly speaking, you can't do anything with TrustZone itself. TrustZone itself is an isolation feature of the CPU core. It adds another level to isolation between processes: in addition to user/kernel or user/kernel/hypervisor, there's normal-user, normal-kernel, normal-hypervisor, secure-user and secure-kernel. But since normal-kernel mode (or normal-hypervisor mode if the hypervisor is in use) can access the whole RAM, there's no place to put code and data out of reach of the normal world. To do something useful with TrustZone, you need not only a core with TZ (which is the case of all Cortex-A CPUs) but also a TrustZone-aware memory controller on the CPU (which some manufacturers omit). A TZ-aware memory controller can firewall memory regions to block a region from being accessed when the CPU is in normal mode. In addition, the DMA controller should also be TrustZone-aware, otherwise the normal world may be able to circumvent memory protections by leveraging a peripheral (e.g. set up DMA between memory used by the secure world and the flash controller, then read the content back from flash).

If your CPU includes a TZ-aware memory controller, it supports isolated execution. However, this alone is of limited use because without other features, the isolated execution environment only runs whatever code was there when the isolation was set up, and can't keep anything past a reboot.

Secure boot, where each stage of the boot process verifies the signature of the next stage before allowing it to run in the secure world, allows whoever controls the ROM to control what runs in the secure world. All Cortex-A processors boot from ROM (as in, actual read-only memory, not flash or EEPROM).

This is still of limited use because you have a secure environment… to do what? If the only privilege that the secure environment has is access to a particular region in RAM, that doesn't do anything useful.

CPUs that leverage TrustZone additionally have a secret key that's accessible only to the secure world. See Does the ARM TrustZone technology support sealing a private key under a code hash? and Secure keys in hardware. With secure boot (for code integrity) plus isolated execution plus one bootstrapping privilege (access to a secret key), the software running in the secure world can implement features such as remote attestation and a limited form of secure storage.

The secure world can store data persistently by encrypting and authenticating data and letting the normal world take care of storing the encrypted blobs. This guarantees the confidentiality and authenticity of the data, but not its integrity. The normal world can still delete data, and can roll it back. To prevent rollback, the secure world needs at least a small amount of rollback-protected storage. In practice, on mobile devices, this is done with the cooperation of the flash controller. The flash controller dedicates a partition to the secure world, known as replay-protected memory block (RPMB), and uses the RPMB protocol to communicate with the secure world on the main CPU, using a shared key that is established when the device is manufactured. Secure storage doesn't need to involve the device user at all: the secure world already has a secret key, it doesn't need to derive one from a password, which would be weaker (typical passwords, even with strengthening applied, are weaker than a run-of-the-mill 128-bit secret key).

“Trusted path” in this context refers to an isolated channel between the CPU and a peripheral. A trusted path needs support inside the CPU, not only TrustZone, but also a peripheral that can be put in a secure mode where it only obeys the secure world, and the bus(es) in between need to isolate the communication. The most deployed kind of trusted path on mobile devices is with the display subsystem, to apply DRM to video rendering. Providing a trusted path for user input and display is technically difficult and not widely deployed.

Remote attestation is not needed for secure provisioning: a server can send data encrypted with a key that only a specific device can decrypt, it doesn't need to receive an attestation from the device. It might want to receive an attestation, either because that's how it discovers the device's public key or because it wants additional content in the attestation (e.g. knowing what software versions it's running).

The big thing you left out is: who controls all of these features? Ultimate control belongs to whoever decides who signs the code that the ROM is willing to load, and that's usually the chi manufacturer, and they allow only code from the device manufacturer. On mobile phones and tablets, the end-user typically has no access to the secure world.