Type: Analysis
Category: Research — Keys & Secure Hardware
Series: Key containers on mobile devices, part 3 of 3
Reading time: ~10 min
An SDK that must run on every phone needs a degradation ladder. The interesting question is not how far down it goes, but where the credential stops being the same credential.
The first two articles established what containers exist on Android and what a device can prove about a key. This one derives the consequence for an SDK that has to work across an entire installed base — including devices that have no secure container at all.
The derived result, stated up front: the tiers of such a ladder are not ordered by security. They are ordered by what can be proven to a third party, and the two orderings are not the same. A key in Apple's Secure Enclave is protected at least as well as a key in an Android TEE. What an issuer can be told about it is considerably less.
The asymmetry nobody designs around
Three platforms, three different answers to the question "can the SDK prove to a remote issuer where this key lives?"
Android: yes, directly. Key attestation produces a signed statement about the specific key the SDK generated for the credential, including its security level and its hardware-enforced constraints. The issuer validates a chain and reads the answer.
iOS: no, not for an arbitrary key. The Secure Enclave is limited to NIST P-256 keys for third-party developers, with no RSA, no Ed25519 and no other curves. App Attest attests that an App Attest key was generated for a specific App ID on genuine Apple hardware and resides in the Secure Enclave — but that key is usable only for App Attest assertions, not as a credential signing key. The common workaround is to have the App Attest key sign a statement binding a separate Secure Enclave key's public key. That works, and it is worth being precise about what it establishes: the issuer is trusting the application's own assertion that the second key is where it says, backed by evidence that the application is genuine. Managed device attestation exists but is tied to managed enrolment, not available to arbitrary applications and issuers.
Other platforms: yes, against a different root. Systems outside the Android and Apple ecosystems — HarmonyOS being one current example — offer their own keystore and their own key attestation, rooted in the vendor's own certificate authority rather than Google's. The mechanism exists; the trust anchor is separate, obtained through the vendor's own channels, and independent security analysis of the underlying trusted execution environment is generally thin or absent in the open literature.
The design consequence: an SDK targeting a heterogeneous fleet maintains three or more independent assurance-detection and trust-validation paths, and the strongest claim it can make differs by platform for reasons that have nothing to do with the strength of the hardware.
Any issuance policy written as "the device key must be hardware-backed" will be satisfied by different quality of evidence on different platforms, and a policy that does not say so is silently accepting the weakest of them.
The ladder
Seven tiers, each defined by the claim it supports rather than by the technology it uses.
A — Discrete secure element, attestation-verified.
Android StrongBox with
attestationSecurityLevel = StrongBox, relied-upon
authorizations in the hardware-enforced list, verified boot in the
Verified state and the device locked. Provable claim: the key
is in tamper-resistant hardware separate from the application processor,
constrained as stated. Constraint: the mandated StrongBox
algorithm set is narrow — P-256 only among the curves — and the
capability is strongly recommended rather than required for
certification, so it is largely absent at the low end of the market.
B — Isolated execution environment, attestation-verified. Android TEE, same validation. Provable claim: the key is in an isolated environment on the main SoC, constrained as stated. Constraint: shares silicon with the untrusted side; published attacks have extracted keys from at least one major vendor's implementation.
C — Platform secure element, application-asserted. Apple Secure Enclave P-256 key, bound via App Attest. Provable claim: the application is genuine on genuine hardware, and the application asserts the credential key is enclave-resident. Constraint: the final link is an application assertion, not a platform attestation. Document this rather than describing it as equivalent to tier B.
D — Vendor secure element, attestation-verified against a vendor root. Provable claim: as tier B, subject to the vendor's own trust anchor and the strength of its published documentation. Constraint: separate trust store; often less independent scrutiny of the underlying environment.
E — Secure element on the SIM or embedded SE, via the Open Mobile API. Provable claim: depends entirely on the applet and its provisioning. Constraint: the blocking issues are commercial rather than technical — applet installation and access rules are controlled by the SIM issuer, so this tier exists only where those relationships exist.
F — Software keystore with user-secret wrapping. Provable claim: the key resists casual extraction and static analysis. Nothing more. White-box cryptography does not raise this tier; the published record on white-box implementations, including the differential computation analysis literature and successive competition results, is that they fall. Treat obfuscation as cost imposition, not protection.
G — Server-side custody with an attested application and strong user authentication. Provable claim: the key is in an HSM the operator controls. Constraint: the device is no longer the custodian. This changes the architecture, not just the assurance level — see below.
The cut line, which is the actual finding
An engineer reads that ladder as seven degrees of the same thing. A compliance framework does not.
Where an assurance framework requires the credential key to reside in certified hardware, tiers F and G are not degraded modes of the same credential. Consider how the European framework handles this: it defines several architectures for the cryptographic device holding wallet keys — a remote one on operator infrastructure, a local external one such as a smart card, and a local internal one such as the phone's own secure element — and requires the wallet provider to ensure access to a device with security sufficient for the highest level of assurance regardless of which architecture is used. There is no lower assurance tier defined for the primary identity credential. A device whose internal container is insufficient does not get a weaker credential; it must use an external or remote container instead, or it is out of scope.
So the ladder has a cut line, and the cut line is a policy decision disguised as an engineering one.
Above the line, degradation means a slightly weaker claim about the
same credential. Below it, degradation means either a different
architecture — external token, remote custody — or non-issuance. Those
are product decisions with cost, logistics and exclusion consequences,
and they cannot be made inside a catch block.
The scale of the problem is not hypothetical. A published review of secure-storage requirements against handset capability in one European national market found roughly one in ten devices meeting the strict hardware requirements, which is why hybrid and remote architectures feature so prominently in that ecosystem's design discussions.
There is a second-order effect worth naming. For a credential designed around offline in-person presentation — an mdoc under ISO/IEC 18013-5 performs device authentication with a key held locally — moving the key to server-side custody does not merely lower assurance. It removes the offline capability that motivated the format. Tier G is not the bottom of the same ladder; it is a different ladder.
Detection by attempt
The mechanics follow from the previous articles and are short.
Try the highest tier and let the platform refuse. On Android: request
StrongBox explicitly and catch
StrongBoxUnavailableException; on failure, generate a
TEE-backed key; then inspect the result rather than assuming it. Use the
system-feature version attributes to record what the device declares,
without generating a key.
Then, for anything that will become an assurance claim, discard the local answer and use the attestation. Generate the credential key with a server-supplied challenge, send the chain to the issuer, and let the issuer decide the tier. The device proposes; the issuer determines.
This ordering matters because the two questions have different answers. The local check tells the SDK what to attempt and what to tell the user. The attestation tells the issuer what it is signing. An SDK that uses the local check for both has made an assurance decision on evidence that cannot support it.
What to record at issuance
The tier is not a transient runtime value. It is a property of the credential, and it will be asked about later.
Per issued credential: platform and version; container tier reached; the full attestation chain as received; the parsed security level; which relied-upon authorizations were hardware-enforced; verified boot state and device lock; patch levels; the trust root the chain validated against; and the policy version in force at the time.
The last item is the one that gets omitted and later needed. Policies change; a credential issued under an earlier policy has to be interpretable under the one that replaced it.
Open questions
- Container availability by device tier and price point. No public dataset maps discrete-secure-element, TEE and software-only availability across a heterogeneous, low-end-inclusive device population. This is measurable with an instrumented probe application and a cloud device farm, and it is the single most useful missing number for anyone sizing a fleet-wide deployment. We intend to attempt this.
- Attestation non-conformance in the field. How often do devices report hardware backing that attestation does not substantiate, and how does that distribute across manufacturers and price tiers? Same measurement, different analysis.
- Device-farm representativeness. Farm devices are re-imaged between runs and may present atypical boot and lock states, which would bias exactly the fields that matter here. Whether farm results generalise to consumer devices needs validating before any measurement is published.
- Independent analysis of vendor trusted execution environments outside the Android and Apple ecosystems. The published scrutiny that has been applied to major Android vendors' implementations has no counterpart for several vendor TEEs now shipping in volume. This is a substantial gap and not one we are equipped to close.
- The cost of tier E and tier G at scale. Both are architectures rather than fallbacks, and the published cost, support and logistics evidence for either at national scale is thin.
- Whether a hardware-bound key can be migrated at all. A credential valid for five to ten years is bound to a key whose algorithm may be deprecated within that window. Guidance on re-binding a credential to a new key, as opposed to reissuing it, appears not to exist.
The first question is the one we can answer without permission, hardware or a budget beyond device-farm time. The sixth is the one that will matter most and has the least written about it.
Series: Key containers on mobile devices
References
- Android Open Source Project. Key and ID attestation. https://source.android.com/docs/security/features/keystore/attestation
- Android Open Source Project. Compatibility Definition Document, §9.11.
- Apple. Apple Platform Security guide, Secure Enclave. https://support.apple.com/guide/security/
- Apple Developer. Establishing your app's integrity (App Attest / DeviceCheck). https://developer.apple.com/documentation/devicecheck
- ISO/IEC 18013-5:2021. Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application.
- European Commission. The European Digital Identity Wallet Architecture and Reference Framework. https://github.com/eu-digital-identity-wallet
- Ansaroudi ZE, Carbone R, Sciarretta G, Ranise S (2025). Navigating secure storage requirements for EUDI Wallets: a review paper. EURASIP Journal on Information Security.
- Bos J, Hubain C, Michiels W, Teuwen P (2016). Differential Computation Analysis: Hiding Your White-Box Designs is Not Enough. CHES 2016.
- GlobalPlatform. Open Mobile API — Android Binding v1.0 for OMAPI v3.3.
- OWASP. Mobile Application Security Testing Guide, cryptographic key storage.
