Delegating trust is really, really, really hard (infosec edition)

Who knows what secrets lurk in your browser’s root certificate store?

Cory Doctorow


CORRECTION: A previous version of this thread reported that Trustcor has the same officers as Packet Forensics; they do not; they have the same officers as Measurement Systems. I regret the error.

I’ve got trust issues. We all do. Some infosec pros go so far as to say “trust no one,” a philosophy more formally known as “Zero Trust,” that holds that certain elements of your security should never be delegated to any third party.

The problem is, it’s trust all the way down. Say you maintain your own cryptographic keys on your own device. How do you know the software you use to store those keys is trustworthy? Well, maybe you audit the source-code and compile it yourself.

But how do you know your compiler is trustworthy? When Unix/C co-creator Ken Thompson received the Turing Prize, he either admitted or joked that he had hidden back doors in the compiler he’d written, which was used to compile all of the other compilers:

OK, say you whittle your own compiler out of a whole log that you felled yourself in an old growth forest that no human had set foot in for a thousand years. How about your hardware? Back in 2018, Bloomberg published a blockbuster story claiming that the server infrastructure of the biggest cloud companies had been compromised with tiny hardware interception devices:

The authors claimed to have verified their story in every conceivable way. The companies whose servers were said to have been compromised rejected the entire story. Four years later, we still don’t know who was right.

How do we trust the Bloomberg reporters? How do we trust Apple? If we ask a regulator to investigate their claims, how do we trust the regulator? Hell, how do we trust our senses? And even if we trust our senses, how do we trust our reason? I had a lurid, bizarre nightmare last night where the most…