Hardware attestation and who controls your device

Before one of our laptops can open the admin console for our product, it has to prove it’s one of our laptops. The person using it needs the right password and second factor as well, but this check is about the machine, that it’s enrolled in our device management, has its disk encrypted, and is running an operating system version we haven’t banned. We turned that on a couple of years ago, after enough incidents where the credentials were fine and the computer wasn’t (the Okta news in 2022 was the first time I’d written that down), and nobody has complained about it since the first week.

That’s a form of attestation, and I think it’s one of the better security controls we have. Which made it uncomfortable to read the GrapheneOS thread that’s been going around since last month, under the headline Hardware Attestation as Monopoly Enabler, because most of what it says is also true, about the same technology. The difference is who’s asking, and I wanted to draw the mechanism out to show why.

The basic idea

Software can’t prove anything about itself. If an app asks the operating system “are you a genuine, unmodified OS?”, a modified OS just says yes. Anyone who’s done a few CTFs knows that any check running on a machine the attacker controls can be patched out, and for years that was the end of the conversation. Client-side checks were speed bumps.

Hardware attestation moves the trust somewhere the attacker can’t easily reach. The device has a small piece of secure hardware, a TPM in a PC, a trusted execution environment or a separate secure chip in a phone, holding a private key that was put there at the factory and never leaves it. The manufacturer issues a certificate for that key, chaining up to a root the manufacturer controls. As the device boots, each stage measures the next one (essentially, hashes it) before handing over control, and the secure hardware keeps a record of those measurements that software running later can’t rewrite.

When a service wants to know what’s running, it sends a random challenge, a nonce. The device asks its secure hardware to sign a statement that includes the nonce and the claims about its state, like whether the bootloader is locked, which OS booted, and what security patch level it’s at. The service gets the signed statement and the certificate chain, checks that the chain ends at a root it trusts, checks the nonce is the one it sent, and reads the claims.

The design is good. A modified OS can’t forge the signature, because it doesn’t have the key, and it can’t fake the boot measurements, because they were recorded before it ran. Breaking it means extracting a key from secure hardware, which does happen but is expensive, and the vendor can revoke the key when it does.

Where you’ve met it

On a PC it’s the TPM, which Windows 11 made a hard requirement in 2021. The TPM keeps boot measurements in a set of registers that can only be extended, never reset, and can produce a signed “quote” of them. Our device management uses that kind of signal, through the operating system, to decide whether a laptop counts as healthy.

On Android, apps have been able to ask for hardware-backed key attestation for years, and Google wraps it in the Play Integrity API, which gives an app’s server a verdict at a few levels: basic, device and strong integrity. GrapheneOS says strong already requires hardware attestation and device is being moved to require it. Apple’s version is App Attest, available since iOS 14, which lets a server confirm a request came from a genuine copy of its app on genuine Apple hardware.

And on the web, Apple shipped Private Access Tokens in 2022, built on the Privacy Pass protocol, so that sites using certain CAPTCHA providers can let a recent iPhone or Mac skip the puzzle, on the strength of Apple vouching for the device. Google proposed something broader for Chrome in 2023, Web Environment Integrity, and dropped it after a lot of very loud objections. The GrapheneOS thread says reCAPTCHA is now moving in a similar direction by another route, including asking some desktop users to scan a QR code with a certified phone. I haven’t seen that myself and can’t confirm the details, but it fits.

The argument

GrapheneOS is an Android-based operating system that runs on Pixel phones, with a lot of hardening that stock Android doesn’t have. It supports the hardware attestation in those phones, with its own keys. Its complaint is that the Play Integrity API only trusts Google-certified operating systems, so GrapheneOS fails, while, by their account, a certified device with no security patches for years can pass. Banks and government services are the main adopters, and once your bank’s app requires a Play Integrity verdict, the more secure phone is the one locked out. Apple has no equivalent dilemma because nobody else gets to make an OS for its hardware.

Their conclusion is that these systems are really about which hardware and software Apple and Google approve, presented as security, and that every new service adopting them helps lock in a two-company market for phones. I’d soften “really”, since fraud through banking apps is a real problem and attestation does make some of it harder. But on the structural point I think they’re right. The mechanism doesn’t care whether a device is secure. It cares whether the device’s vendor is on the list.

Who’s asking

So why do I like our laptop check and dislike this? Go back to step 4 in the diagram. In our case, we own the laptops, we’re the relying party, and we chose the policy. The person whose device is being checked and the organization doing the checking are, for the purposes of that check, on the same side, and the device is company property. If someone wants to run a different OS on a laptop, they can, and it just isn’t the one that opens the admin console.

With Play Integrity, the relying party is your bank, the roots and the policy are Google’s, and the device is yours. Nobody involved in that check is acting for the owner of the phone, and the owner can’t satisfy it by making the phone more secure, only by making it more approved.

We went through a small version of this with our support team’s hardware keys, which they’ve used since 2020. Security keys can attest too, sending a certificate that says which make and model they are, and our identity provider lets you restrict sign-in to specific models that way. We talked about allowing only the model we buy. We decided against it, for two reasons. The keys we buy are the ones that get used anyway, so the restriction would have added nothing, and it would have meant that passkeys stored in a password manager or on a phone, which mostly don’t provide attestation at all, could never count. We’d have been deciding which vendors’ authenticators our people could use, for no security gain. It felt like a small Play Integrity of our own.

If I were writing the rule for services, it would be that an attestation check should accept roots the device owner chooses, not only the ones the platform vendor chooses. Android’s attestation already reports which key signed the operating system, so an app can accept GrapheneOS by checking for its published key, and GrapheneOS has a guide for developers who want to. Whether to do that is a policy choice for each service. I don’t expect most banks to make it, because the default is easier and nobody gets fired for trusting Google. But anyone building a check like this should know which side of step 4 they’re standing on.