{"id":224728,"date":"2026-09-07T16:11:48","date_gmt":"2026-09-07T16:11:48","guid":{"rendered":"https:\/\/neodata.com.uy\/labs\/?p=224728"},"modified":"2026-09-07T16:11:48","modified_gmt":"2026-09-07T16:11:48","slug":"what-hardware-backed-means-on-android","status":"publish","type":"post","link":"https:\/\/neodata.com.uy\/labs\/what-hardware-backed-means-on-android\/","title":{"rendered":"What “hardware-backed” means on Android."},"content":{"rendered":"\n\n

Type:<\/strong> Primer<\/p>\n\n\n\n\n\n

Category:<\/strong> Research \u2014 Keys & Secure Hardware<\/p>\n\n\n\n\n\n

Series:<\/strong> Key containers on mobile devices, part 1 of\n3<\/p>\n\n\n\n\n\n

Reading time:<\/strong> ~8 min<\/p>\n\n\n\n\n\n

Three\nsecurity levels, one keystore API, and a certification requirement that\nstops short of the strongest one.<\/h2>\n\n\n\n\n\n

An application that generates a key through the Android Keystore\nreceives a handle and a promise. The promise is that the private key\nmaterial is protected by something better than the filesystem. What that\nsomething is varies by device, is not selected by the application, and\nis not evident from the handle.<\/p>\n\n\n\n\n\n

This article establishes the vocabulary. The two that follow cover\nwhat a device can prove about the key, and how an SDK should choose\namong the options.<\/p>\n\n\n\n\n\n

The hierarchy<\/h2>\n\n\n\n\n\n

Three security levels are defined: Software<\/strong>,\nTrustedEnvironment<\/strong>, and StrongBox<\/strong>.<\/p>\n\n\n\n\n\n

Software<\/strong> means the key is protected by the operating\nsystem and nothing else. The key material is encrypted at rest, but the\nencryption and the enforcement of the key's usage constraints happen in\ncode running on the main processor, under the main kernel. A compromise\nof the OS is a compromise of the key.<\/p>\n\n\n\n\n\n

TrustedEnvironment<\/strong> \u2014 commonly called the TEE \u2014 means\nthe key lives in an isolated partition of the same<\/em>\nsystem-on-chip that runs the application processor. On ARM devices this\nis normally implemented with TrustZone: a \"secure world\" with its own\nsmall operating system, most often Trusty or a vendor's own. The\napplication processor can request operations but cannot read the key. It\nshares silicon, memory controllers and power rails with the untrusted\nside.<\/p>\n\n\n\n\n\n

StrongBox<\/strong> means the key lives in a physically\nseparate tamper-resistant secure element with its own processor, its own\nsecure storage, and its own true random number generator. AOSP's\nhardware guidance requires a StrongBox implementation to provide a\ndiscrete CPU, secure storage, a high-quality TRNG, tamper-resistant\npackaging and side-channel resistance.<\/p>\n\n\n\n\n\n

The distinction between the second and third levels is the one that\nmatters for threat modelling. A TEE resists a compromised OS. A discrete\nsecure element additionally resists physical attack on the main SoC and\nthe side channels that come with sharing it.<\/p>\n\n\n\n\n\n

What certification\nactually requires<\/h2>\n\n\n\n\n\n

This is where expectations and reality diverge, and it is the most\nuseful thing in this article.<\/p>\n\n\n\n\n\n

The Android Compatibility Definition Document, section 9.11, sets\nwhat a device must implement to be certified. Reading it carefully:<\/p>\n\n\n\n\n