In TrustZone in the processor and System Architecture, we introduced the TrustZone features in hardware and discussed the typical software stack that uses those features. In this topic, let’s pull together this knowledge and look at some example use cases.
Mobile devices like smartphones contain a lot of personal data. Users care about the confidentiality of that data if the device is lost or stolen. This is why most recent devices support file system encryption. TrustZone can be used part of the solution for protecting this data.
Data stored in the external flash is encrypted. On boot, the device authenticates the user and then provisions the key to decrypt the filesystem. Decryption might be handled by an accelerator or might be integrated into the flash controller.
The key for the file system also needs to have its confidentiality protected. If they key is compromised, an attacker could decrypt the filesystem.
The processes after authentication are illustrated in the following diagram:
In Secure state:
- After authentication, the encrypted filesystem key is read into on-chip secure memory. The key is decrypted and checked, using the master device unique key, which is stored on-chip.
- The filesystem key is provisioned into a secure access only register in a crypto engine or memory controller.
- Subsequent bus accesses to the filesystem in flash will be encrypted or decrypted using the provisioned key.
By performing these operations in Secure state, TrustZone allows us to never expose the filesystem keys to Non-secure state software. This means that malicious code in Non-secure cannot extract those keys for later attacks. Using what we have discussed so far, think about the following questions:
Over the air firmware update
This second example relates to updating the boot firmware. The requirements for our system are:
- New firmware image is provided over a network.
- Only authentic images can be installed.
- Firmware version cannot be rolled back.
To achieve these aims, the OEM signs the image with its private key. The downloading device is provisioned with the public key, which it can use to verify the signature. A non-volatile counter is incremented when the firmware is updated, allowing detection of roll-back.
Our system is shown in the following diagram:
The downloading of the image is carried out in Non-secure state. The image itself is a not a secret, so we do not protect its confidentiality. The downloaded image is placed in memory and a request is issued to Secure state to install it.
The Secure state software is responsible for authentication. It does this using the public key of the OEM, typically stored in off-chip flash. This key is not a secret, so we do not need to ensure confidentiality. We do need to ensure authenticity of the key and detect attempts to substitute the key. We achieve this by keeping a hash of the key on-chip, which can be used to check the key when needed. A hash requires fewer bits and on-chip memory is expensive.
When the public key is loaded and checked, the new firmware image can be checked. We want to ensure that it is authentic (the signature matches) and that it is a newer version of the firmware than what is installed.
Assuming that these checks pass, the image is installed, and the NV counter incremented. Incrementing the NV counter means that, if an attacker tries to install an older firmware, the device will detect that attempt.
In this example, TrustZone allows us to ensure that the keys that are used to authenticate firmware images are protected and that firmware images cannot be rolled back.