I know the device keys for Android are in hardware and created used fuses. Where is this fuse memory? Is it directly accessible to the processor?

Because the hardware key should not read out into the memory, that means the AES operation needs to be done in the processor directly. Where is the AES implementation done that uses this fused key? Is there an equivalent of AES-NI instruction set in arm?

If this is not correct place for this question, where can I ask it?

  • 1
    One-Time-Programmable (OTP) fuses are not kept in memory but within the processor or the security co-processor itself. It is not usually accessed directly but instead changes the behavior of the processor. I do not know much about Android, but I think this is kept in a secure co-processor.
    – forest
    Commented Mar 14, 2018 at 5:45
  • This is the correct place to ask it, or at least a correct place.
    – forest
    Commented Mar 15, 2018 at 0:53

1 Answer 1


Hardware secure keys are not a feature of Android, they're a feature of some (but not all) devices running Android, including most if not all high- and mid-end smartphones and tablets. The way they work depends on the capabilities of the hardware.

All processors based on an ARM Cortex-A core (and some older ones), whether 32-bit or 64-bit, have a feature called TrustZone, which is a sort of highly specialized virtualization. There are just two partitions: the secure world and the normal world. The secure world has access to the normal world, the normal world doesn't have access to the secure world. TrustZone itself isn't enough to do anything useful: the memory bus has to enforce the protection, which is the case on most (but not all) system-on-chips (SoC) based on a Cortex-A.

On a suitable processor, the secure world runs a trusted execution environment (TEE) with a small operating system. On reasonably modern Android versions, the keys of the Android keymaster are stored in the TEE, Android (even fully rooted) does not have direct access to them. There are phones where the device encryption key resides inside the TEE, but this isn't always the case.

The TEE data is stored encrypted using a key that Android cannot access. This key is derived from a root key which is stored in write-once memory (this can be fuses or other one-time-programmable (OTP) memory technology). The reason Android cannot access this key is that the processor ensures that it is only accessible to the secure world.

On some SoC, the secure world directly reads the memory. On other SoC, there is a dedicated component in the SoC that has exclusive access to the root key, and all the secure world on the main processor can do is to request a key derivation based on the root key. This doesn't change much regarding the security of the system: in either case, the key that the security of the system relies on is a key that gets stored in secure world memory.

Restricting the secure world to a derived key has one advantage: the key can be changed by changing the tweak on the derivation. An attacker who partially breached the TEE and managed to read data, but not to execute arbitrary code, would have access to the key. If the bug is fixed and the new TEE version uses a different key derivation parameter, then the attacker will no longer be able to read TEE data.

Some ARMv8 processors (including all high end phones today) have instructions similar to AES-NI, but this has no impact on security (except indirectly, in making cryptography less expensive and less prone to side channel attacks). AES-NI and the ARM equivalent are just ways to compute AES faster, the keys and data are still in the same place.

  • Thanks. Since the trust zone is implemented (and run) on the same processor as the host OS (Android), the AES core should also be accessible to both worlds. How is the access to the usage of the fused key restricted from the host OS (Android)?
    – stflow
    Commented Mar 15, 2018 at 23:01
  • @stflow It's the same processor, but it's a different security partition. It's protected in the same way that a kernel is protected from unprivileged processes, and a hypervisor is protected from its guests. Commented Mar 15, 2018 at 23:09
  • So, from the TZ OS, if I do a key derivation using the fused key and key schedule it in the AES core, can I continue the actual decryption/encryption back in the host OS? Or should I always go back to TZ to process bytes using the scheduled key? And would that be secure, as in the key will still not be revealed/recovered on the host OS
    – stflow
    Commented Mar 15, 2018 at 23:12
  • Or is it more likely that the AES core accessible to the TZ OS not accessible to the host OS?
    – stflow
    Commented Mar 15, 2018 at 23:25
  • Isn't the TrustZone kernel typically seL4? I read somewhere that they had changed to that from OKL4.
    – forest
    Commented Mar 16, 2018 at 6:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .