Example use cases

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.

Encrypted filesystem

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:

  • Why is the filesystem key stored off-chip?

    On-chip memory tends to be limited in size and expensive, compared to off-chip flash. Keeping the filesystem key off-chip can reduce cost. Having it encrypted means we ensure confidentiality. There is a risk that malicious software could corrupt the key, which would be a breach of integrity, but that does not expose data.

  • Why do we use a separate filesystem key in this example, and not the master device unique private key?

    In theory, we could use the device unique key. But that means that we can never change the key, because the master device unique private key is stored in OTP. That might be a problem if, for example, we sell the phone. Instead we generate a new random filesystem key. If you want to format or reset the device, we can delete the filesystem key and generate a new one. Any data that is encrypted with the old key is now irretrievable.

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.

Previous Next