The paper Trustworthy Execution on Mobile Devices: What Security Properties Can My Mobile Platform Give Me? describes 5 desired security features for mobile devices:
- Isolated Execution
- Secure Storage
- Remote Attestation
- Secure Provisioning
- 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.