{"id":224729,"date":"2026-09-07T16:11:48","date_gmt":"2026-09-07T16:11:48","guid":{"rendered":"https:\/\/neodata.com.uy\/labs\/?p=224729"},"modified":"2026-09-07T16:11:48","modified_gmt":"2026-09-07T16:11:48","slug":"seven-containers-ranked-by-what-you-can-prove","status":"publish","type":"post","link":"https:\/\/neodata.com.uy\/labs\/seven-containers-ranked-by-what-you-can-prove\/","title":{"rendered":"Seven containers, ranked by what you can prove."},"content":{"rendered":"\n\n

Type:<\/strong> Analysis<\/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 3 of\n3<\/p>\n\n\n\n\n\n

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

An\nSDK that must run on every phone needs a degradation ladder. The\ninteresting question is not how far down it goes, but where the\ncredential stops being the same credential.<\/h2>\n\n\n\n\n\n

The first two articles established what containers exist on Android\nand what a device can prove about a key. This one derives the\nconsequence for an SDK that has to work across an entire installed base\n\u2014 including devices that have no secure container at all.<\/p>\n\n\n\n\n\n

The derived result, stated up front: the tiers of such a\nladder are not ordered by security. They are ordered by what can be\nproven to a third party, and the two orderings are not the\nsame.<\/strong> A key in Apple's Secure Enclave is protected at least as\nwell as a key in an Android TEE. What an issuer can be told about it is\nconsiderably less.<\/p>\n\n\n\n\n\n

The asymmetry nobody\ndesigns around<\/h2>\n\n\n\n\n\n

Three platforms, three different answers to the question \"can the SDK\nprove to a remote issuer where this key lives?\"<\/p>\n\n\n\n\n\n

Android: yes, directly.<\/strong> Key attestation produces a\nsigned statement about the specific key the SDK generated for the\ncredential, including its security level and its hardware-enforced\nconstraints. The issuer validates a chain and reads the answer.<\/p>\n\n\n\n\n\n

iOS: no, not for an arbitrary key.<\/strong> The Secure\nEnclave is limited to NIST P-256 keys for third-party developers, with\nno RSA, no Ed25519 and no other curves. App Attest attests that an App\nAttest key was generated for a specific App ID on genuine Apple hardware\nand resides in the Secure Enclave \u2014 but that key is usable only for App\nAttest assertions, not as a credential signing key. The common\nworkaround is to have the App Attest key sign a statement binding a\nseparate Secure Enclave key's public key. That works, and it is worth\nbeing precise about what it establishes: the issuer is trusting the\napplication's own assertion that the second key is where it says, backed\nby evidence that the application is genuine. Managed device attestation\nexists but is tied to managed enrolment, not available to arbitrary\napplications and issuers.<\/p>\n\n\n\n\n\n

Other platforms: yes, against a different root.<\/strong>\nSystems outside the Android and Apple ecosystems \u2014 HarmonyOS being one\ncurrent example \u2014 offer their own keystore and their own key\nattestation, rooted in the vendor's own certificate authority rather\nthan Google's. The mechanism exists; the trust anchor is separate,\nobtained through the vendor's own channels, and independent security\nanalysis of the underlying trusted execution environment is generally\nthin or absent in the open literature.<\/p>\n\n\n\n\n\n

The design consequence: an SDK targeting a heterogeneous\nfleet maintains three or more independent assurance-detection and\ntrust-validation paths, and the strongest claim it can make differs by\nplatform for reasons that have nothing to do with the strength of the\nhardware.<\/strong><\/p>\n\n\n\n\n\n

Any issuance policy written as \"the device key must be\nhardware-backed\" will be satisfied by different quality of evidence on\ndifferent platforms, and a policy that does not say so is silently\naccepting the weakest of them.<\/p>\n\n\n\n\n\n

The ladder<\/h2>\n\n\n\n\n\n

Seven tiers, each defined by the claim it supports rather than by the\ntechnology it uses.<\/p>\n\n\n\n\n\n

A \u2014 Discrete secure element, attestation-verified.<\/strong>\nAndroid StrongBox with\nattestationSecurityLevel = StrongBox<\/code>, relied-upon\nauthorizations in the hardware-enforced list, verified boot in the\nVerified state and the device locked. Provable claim:<\/em> the key\nis in tamper-resistant hardware separate from the application processor,\nconstrained as stated. Constraint:<\/em> the mandated StrongBox\nalgorithm set is narrow \u2014 P-256 only among the curves \u2014 and the\ncapability is strongly recommended rather than required for\ncertification, so it is largely absent at the low end of the market.<\/p>\n\n\n\n\n\n

B \u2014 Isolated execution environment,\nattestation-verified.<\/strong> Android TEE, same validation.\nProvable claim:<\/em> the key is in an isolated environment on the\nmain SoC, constrained as stated. Constraint:<\/em> shares silicon\nwith the untrusted side; published attacks have extracted keys from at\nleast one major vendor's implementation.<\/p>\n\n\n\n\n\n

C \u2014 Platform secure element, application-asserted.<\/strong>\nApple Secure Enclave P-256 key, bound via App Attest. Provable\nclaim:<\/em> the application is genuine on genuine hardware, and the\napplication asserts the credential key is enclave-resident.\nConstraint:<\/em> the final link is an application assertion, not a\nplatform attestation. Document this rather than describing it as\nequivalent to tier B.<\/p>\n\n\n\n\n\n

D \u2014 Vendor secure element, attestation-verified against a\nvendor root.<\/strong> Provable claim:<\/em> as tier B, subject to the\nvendor's own trust anchor and the strength of its published\ndocumentation. Constraint:<\/em> separate trust store; often less\nindependent scrutiny of the underlying environment.<\/p>\n\n\n\n\n\n

E \u2014 Secure element on the SIM or embedded SE, via the Open\nMobile API.<\/strong> Provable claim:<\/em> depends entirely on the\napplet and its provisioning. Constraint:<\/em> the blocking issues\nare commercial rather than technical \u2014 applet installation and access\nrules are controlled by the SIM issuer, so this tier exists only where\nthose relationships exist.<\/p>\n\n\n\n\n\n

F \u2014 Software keystore with user-secret wrapping.<\/strong>\nProvable claim:<\/em> the key resists casual extraction and static\nanalysis. Nothing more. White-box cryptography does not raise this tier;\nthe published record on white-box implementations, including the\ndifferential computation analysis literature and successive competition\nresults, is that they fall. Treat obfuscation as cost imposition, not\nprotection.<\/p>\n\n\n\n\n\n

G \u2014 Server-side custody with an attested application and\nstrong user authentication.<\/strong> Provable claim:<\/em> the key is\nin an HSM the operator controls. Constraint:<\/em> the device is no\nlonger the custodian. This changes the architecture, not just the\nassurance level \u2014 see below.<\/p>\n\n\n\n\n\n

The cut line, which is\nthe actual finding<\/h2>\n\n\n\n\n\n

An engineer reads that ladder as seven degrees of the same thing. A\ncompliance framework does not.<\/p>\n\n\n\n\n\n

Where an assurance framework requires the credential key to reside in\ncertified hardware, tiers F and G are not degraded modes of the same\ncredential. Consider how the European framework handles this: it defines\nseveral architectures for the cryptographic device holding wallet keys \u2014\na remote one on operator infrastructure, a local external one such as a\nsmart card, and a local internal one such as the phone's own secure\nelement \u2014 and requires the wallet provider to ensure access to a device\nwith security sufficient for the highest level of assurance regardless\nof which architecture is used. There is no lower assurance tier defined\nfor the primary identity credential. A device whose internal container\nis insufficient does not get a weaker credential; it must use an\nexternal or remote container instead, or it is out of scope.<\/p>\n\n\n\n\n\n

So the ladder has a cut line, and the cut line is a policy\ndecision disguised as an engineering one.<\/strong><\/p>\n\n\n\n\n\n

Above the line, degradation means a slightly weaker claim about the\nsame credential. Below it, degradation means either a different\narchitecture \u2014 external token, remote custody \u2014 or non-issuance. Those\nare product decisions with cost, logistics and exclusion consequences,\nand they cannot be made inside a catch<\/code> block.<\/p>\n\n\n\n\n\n

The scale of the problem is not hypothetical. A published review of\nsecure-storage requirements against handset capability in one European\nnational market found roughly one in ten devices meeting the strict\nhardware requirements, which is why hybrid and remote architectures\nfeature so prominently in that ecosystem's design discussions.<\/p>\n\n\n\n\n\n

There is a second-order effect worth naming. For a credential\ndesigned around offline in-person presentation \u2014 an mdoc under ISO\/IEC\n18013-5 performs device authentication with a key held locally \u2014 moving\nthe key to server-side custody does not merely lower assurance. It\nremoves the offline capability that motivated the format. Tier G is not\nthe bottom of the same ladder; it is a different ladder.<\/p>\n\n\n\n\n\n

Detection by attempt<\/h2>\n\n\n\n\n\n

The mechanics follow from the previous articles and are short.<\/p>\n\n\n\n\n\n

Try the highest tier and let the platform refuse. On Android: request\nStrongBox explicitly and catch\nStrongBoxUnavailableException<\/code>; on failure, generate a\nTEE-backed key; then inspect the result rather than assuming it. Use the\nsystem-feature version attributes to record what the device declares,\nwithout generating a key.<\/p>\n\n\n\n\n\n

Then, for anything that will become an assurance claim, discard the\nlocal answer and use the attestation. Generate the credential key with a\nserver-supplied challenge, send the chain to the issuer, and let the\nissuer decide the tier. The device proposes; the issuer determines.<\/p>\n\n\n\n\n\n

This ordering matters because the two questions have different\nanswers. The local check tells the SDK what to attempt and what to tell\nthe user. The attestation tells the issuer what it is signing. An SDK\nthat uses the local check for both has made an assurance decision on\nevidence that cannot support it.<\/p>\n\n\n\n\n\n

What to record at issuance<\/h2>\n\n\n\n\n\n

The tier is not a transient runtime value. It is a property of the\ncredential, and it will be asked about later.<\/p>\n\n\n\n\n\n

Per issued credential: platform and version; container tier reached;\nthe full attestation chain as received; the parsed security level; which\nrelied-upon authorizations were hardware-enforced; verified boot state\nand device lock; patch levels; the trust root the chain validated\nagainst; and the policy version in force at the time.<\/p>\n\n\n\n\n\n

The last item is the one that gets omitted and later needed. Policies\nchange; a credential issued under an earlier policy has to be\ninterpretable under the one that replaced it.<\/p>\n\n\n\n\n\n

Open questions<\/h2>\n\n\n\n\n
    \n\n
  1. Container availability by device tier and price\npoint.<\/strong> No public dataset maps discrete-secure-element, TEE and\nsoftware-only availability across a heterogeneous, low-end-inclusive\ndevice population. This is measurable with an instrumented probe\napplication and a cloud device farm, and it is the single most useful\nmissing number for anyone sizing a fleet-wide deployment. We intend to\nattempt this.<\/li>\n\n\n
  2. Attestation non-conformance in the field.<\/strong> How often\ndo devices report hardware backing that attestation does not\nsubstantiate, and how does that distribute across manufacturers and\nprice tiers? Same measurement, different analysis.<\/li>\n\n\n
  3. Device-farm representativeness.<\/strong> Farm devices are\nre-imaged between runs and may present atypical boot and lock states,\nwhich would bias exactly the fields that matter here. Whether farm\nresults generalise to consumer devices needs validating before any\nmeasurement is published.<\/li>\n\n\n
  4. Independent analysis of vendor trusted execution\nenvironments outside the Android and Apple ecosystems.<\/strong> The\npublished scrutiny that has been applied to major Android vendors'\nimplementations has no counterpart for several vendor TEEs now shipping\nin volume. This is a substantial gap and not one we are equipped to\nclose.<\/li>\n\n\n
  5. The cost of tier E and tier G at scale.<\/strong> Both are\narchitectures rather than fallbacks, and the published cost, support and\nlogistics evidence for either at national scale is thin.<\/li>\n\n\n
  6. Whether a hardware-bound key can be migrated at\nall.<\/strong> A credential valid for five to ten years is bound to a key\nwhose algorithm may be deprecated within that window. Guidance on\nre-binding a credential to a new key, as opposed to reissuing it,\nappears not to exist.<\/li>\n\n<\/ol>\n\n\n\n\n

    The first question is the one we can answer without permission,\nhardware or a budget beyond device-farm time. The sixth is the one that\nwill matter most and has the least written about it.<\/p>\n\n\n\n\n\n

    Series: Key containers on mobile devices<\/strong><\/p>\n\n\n\n\n