What hardware attestation actually proves: a survey of TPM 2.0 across 47 device models

Dart's identity layer rests on a claim we make repeatedly: your private key is generated inside your device's security chip and cannot leave it. Before shipping that claim to users we wanted to know how true it is across the hardware people actually own, rather than on the four development machines sitting on our desks.

So we bought, borrowed, or remotely accessed 47 device models across six manufacturers — laptops, desktops, and a handful of tablets — and ran the same battery against each. The results split cleanly into a part of the guarantee that holds everywhere and a part that does not.

Non-exportability holds

The core claim survived contact with reality. Every one of the 47 devices correctly refused to export a private key created with the non-exportable attribute set, under every approach we tried: direct export calls, duplication with a null parent, administrative override with full platform-hierarchy authorisation, and attempted extraction of the key blob followed by loading into a software TPM.

This is the result we most wanted and least expected to get cleanly. It means the sentence “keys cannot leave the chip, even for an administrator” is defensible as written. We would still not describe it as a proof — we tested software interfaces, not the silicon, and a hardware attack with physical access is outside what we can evaluate.

Attestation does not

Remote attestation — proving to a third party that a key really does live in genuine hardware — is where the picture falls apart. Only 31 of 47 devices provided a chain we could validate end to end. Nine shipped an endorsement key certificate that failed validation: expired intermediates, roots that were no longer published at the URL embedded in the certificate, and in two cases a certificate signed by a key we could find no published record of at all.

The failure modes are mundane rather than malicious. Certificate infrastructure is maintained by hardware vendors whose incentives to keep a root published for a decade are weak, and a machine bought in 2019 may be pointing at a URL that quietly stopped resolving in 2023. But the practical effect is severe: a verifier cannot distinguish “honest device with broken vendor PKI” from “forged attestation”, and in a security system those must be treated the same way.

Algorithm support is uneven

Every device supported RSA-2048 and ECDSA P-256. Support thins out quickly after that. No device in our sample offered in-chip ML-DSA, which is unsurprising for hardware predominantly manufactured before the standard was finalised, and it constrains the design: our post-quantum signatures are computed in software over a key whose confidentiality is protected by the chip, rather than inside it. That is a weaker property and we say so in the product documentation rather than eliding it.

Firmware updates can silently destroy keys

The most operationally alarming finding was the smallest. On four device models, a vendor firmware update cleared the TPM's storage hierarchy, invalidating every key beneath it. No warning was shown before the update and no error was raised afterward — the keys simply stopped working, and to an application they were indistinguishable from keys that had never existed.

Plotting validity against model year makes the mechanism visible. Devices from 2024 and 2025 validated at 85% and above; devices from 2019 validated at 38%. Nothing about the hardware changed — the chips are as capable as they were on the day they shipped. What changed is that a certificate expired or a root moved. A guarantee that degrades with age, silently, for reasons entirely outside the owner’s control, is a poor foundation for anything a person needs to rely on in five years.

A credential system where the credential can vanish during a routine update, silently, is not a credential system. This single finding reshaped our whole recovery design.

This is why Dart does not treat a hardware key as a sole factor for anything the user cannot afford to lose. Every hardware-bound identity has a recovery path established at enrolment, and the browser re-attests on every launch specifically so that a silently invalidated key surfaces as an actionable prompt within seconds rather than at the worst possible moment.

How this changed the product

• Non-exportability is treated as dependable and is the property we build on.
• Remote attestation is treated as advisory. A device with an unvalidatable chain still gets hardware-bound keys; it simply cannot prove that fact to a third party, and the browser tells the user so.
• Post-quantum signatures are computed in software over chip-protected key material, and the documentation states this rather than implying in-chip PQ support.
• Every enrolment establishes a recovery path before the hardware key is trusted for anything.
• The browser re-attests at launch and surfaces invalidation immediately.

Method

Limitations

Forty-seven models is a survey, not a census, and our sample over-represents business laptops because they were the easiest to obtain. We tested software interfaces only; nothing here speaks to physical attacks, side channels, or the correctness of the silicon. The firmware finding is a snapshot — three of the four affected models have since shipped updates that preserve the hierarchy, which we have verified but which also means the specific list would be misleading to publish now. And vendor PKI changes: a chain that failed for us in 2025 may validate today, or the reverse.

We have shared the per-model results privately with each affected manufacturer and with three of the four vendors whose firmware cleared key storage. The anonymised aggregate is published; the per-model breakdown is available to researchers on request: security@dartbrowser.com.

Related work

The TPM 2.0 specification [1] defines behaviour precisely; what it cannot define is whether a given vendor implemented it correctly or kept its certificate infrastructure online. Prior evaluations have mostly targeted single implementations, often finding serious flaws — the TPM-Fail work [3] and the ROCA key-generation weakness [4] are the best known. Our survey is broader and shallower: we did not look for cryptographic flaws, we looked at whether the operational guarantees a product can rely on actually hold across the hardware population. The attestation-PKI finding appears not to have been quantified at this breadth before.

Artefacts

Everything below is published or available on request. A number nobody can reproduce is an advertisement, not a result.

References

1. Trusted Computing Group (2019). TPM 2.0 Library Specification, Revision 1.59.
2. Arthur, W., Challener, D., & Goldman, K. (2015). A Practical Guide to TPM 2.0. Apress.
3. Moghimi, D., Sunar, B., Eisenbarth, T., & Heninger, N. (2020). TPM-FAIL: TPM meets Timing and Lattice Attacks. USENIX Security.
4. Nemec, M., Sýs, M., Svenda, P., Klinec, D., & Matyas, V. (2017). The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli. ACM CCS.
5. National Institute of Standards and Technology (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard.
6. Apple (2024). Apple Platform Security Guide: Secure Enclave.