On the dangers of "trusted computing"

What if I told you the age old status quo, where you as a developer should never trust the client, and you the user can always (eventually) get around limitations imposed on you, was no longer?

In fact, it’s not something you have to imagine, let’s take a stroll into the mobile computing world, where the evil has emerged victorious…

Google’s garden

Apple is well known for their walled garden, which allows them to wield nearly full control over their iDevices. Many tech people will tell you that Android is a different experience, and indeed it allows you to do many things you can’t do with an iPhone, including sideloading apps, or installing a custom operating system!

You may think this is it, right? Not so fast, many people who have tinkered with Android forks will know that getting certain apps to work can be a pain. SafetyNet is a name that will come up, and usually won’t be explained much beyond being a security thing, or a root detection thing. But that’s pretty much what the good old SafetyNet does, it is a binary that tries to perform various checks on the device, and if they fail Google’s API will tell the app developer about it.

Note that this system still follows the old wisdom that the client is untrustworthy, SafetyNet for its basic attestation profile relies on obscurity to function, and it can be bypassed. Despite this, it has already proven to be a pain in the ass considering it can update itself overnight, thus bricking your apps.

Now, some people may be aware that moden smartphone SoCs come with security processors, which can assist with cryptographic operations and storing secrets. Security is good, right!?

The dirty secret of these processors is that they can be used to hide secrets from the user, and they are used to validate each part of the boot chain to provide verified boot. This again can have security benefits, like preventing evil maid attacks, or not allowing malware to persist on the system root partition.

Where this really becomes a problem is with remote attestation, it is exactly what it sounds like, a remote server can demand a proof from your device that is is running certain software. Silicon is pretty inaccessible due to its size, and hardware bugs that affect security critical features like this will be rare, so this effectively means that the status quo is broken, the server can now reasonably trust that a user has not changed their original operating system.

And this is indeed what the new Play Integrity API uses. Good luck bypassing that.

In terms of pratical effects this has had on alternative mobile operating systems, it’s been detrimental. Users who don’t want to or can’t (due to old age) use the stock OS that came with their device are often discriminated by various apps, despite running an OS that is fully compatible with them. The most common offenders are banks, payment systems, streaming services, but also games, and a certain popular fast food app. In theory it’s up to the developers of these apps to allow other signatures (at least if they’re using the native Android APIs instead of Google Play’s) but in practice this means only devices endorsed by Google are allowed due to their market share, and in any case the users are coerced out of a choice about their own hardware and software.

Where security people get it wrong

I’ve unfortunately come across many voices saying there’s not much to worry about when it comes to trusted computing on the PC, and praises of the benefits TC hardware can provide.

Stuff like:

• “TPMs have been a common thing for years, and nothing happened”
• “Remote attestation was already possible with TPMs, so the current situation with Windows 11 changes nothing”

The thing people miss here is thinking about the system in its entirety, including the social aspects.

Until most computers are configured for remote attestation, it is essentially useless as far as the end-user is concerned. That means all the PCs that came with TPMs and secure boot disabled by default made it inconvenient for companies to rely on it, because then users would have to go into their UEFI setup to enable it, or they might not even have the hardware yet.

The attack trusted computing presents on software freedom is a network one, a form of coercion. Sure you can run your own software, but if the vast majority of computers have a proprietary TC-enabled OS installation, you’re the odd one out, and you can be discarded. It’s a silent killer that lulls you into a false sense of security before it’s too late.

This is why Windows 11 requiring TPMs is a big deal, it drives the adoption up, making it viable for it to be required for other things without bothering the user too much.

It’s not a spooky future dystopia that will never happen, it has already happened in the mobile world, it really stinks!

Worse yet, by looking at devices that already follow this model and what kind of software gets developed for them we can see how trusted computing will trap us in the new reality. Console-first games that take the idea of a server very liberally come to mind, a lot of them would (and do) fall apart once this assumption is broken, which would provide a strong incentive not to ban trusted computing if its horrors are realized to their fullest.

What can we actually do about it?

Tuns out, not a lot. We’re basically at the mercy of politicians here, we can try lobbying them to ban this technology in its entirety, but that would likely face strong oppossition from the industry. It is probably still our best bet.

There aren’t really any ways to individually protect yourself against TC, since not presenting an attestation is equivalent to not passing it. You are excluded by default. Leaked keys and vulnerabilities could provide opportunities to circumvent the system, but we cannot rely on this alone.

This should’ve been dealt with 20 years ago, and yet it wasn’t, and now we are starting to enter the “oh shit” phase of things.