The Washington Post seems to have kicked a crypto hornets nest recently, with their suggestion that Apple (and other phone manufacturers, though I’ll stick with Apple as an example) should include a golden escrow key to allow law enforcement to decrypt suspects’ phones. This provoked the expected reaction from everybody who gets it that escrow is a terrible idea. Fair enough. But what’s the least worst escrow system we can devise?

Why would we want to design such a system, given that implementing a golden key would be a disaster? Well, disaster planning is hardly a new idea. Nor does coming up with a plan for the worst case scenario necessarily mean you want it to happen. Devising fire evacuation plans for an office building doesn’t make one an arsonist. I think having a good escrow plan ready is better than having none and being forced to design one on the spot. Even worst case scenarios can be subdivided into worst worst and least worst. And so, without advocating for a key escrow system, here’s how I might go about building one.

Point zero, I’m going to skip over most of the crypto nuts and bolts. Whatever key your phone uses to encrypt all its data, stipulate that that key is then encrypted with the public escrow key. Your data is then secure as long as the matching private key is secure. Huge if, and the crux of the problem, but I’m not going to worry about the crypto itself. We’ll assume that’s already solved.

First, having a single golden key would be a disaster. It will get out, and then that’s it. By necessity it can’t be rotated, so whoever knows it today will know it forever. A single key would be like the nuclear launch codes, except they’d be in regular use and some large number of people would know them as a matter of course.

Let’s start over with multiple keys, like one per device. When the FBI asks to decrypt Alice’s phone, they get Alice’s key. Maybe Apple would handle the decryption instead, but that leaves open the question of how the decrypted data gets from Apple back to the FBI. The important principle is that Alice’s key cannot be used to decrypt Bob’s phone. Whenever a key is “brought to the surface”, there is a risk of exposure, which is why the single golden key plan is such a disaster. The compounded risk of a leak is too great, but separate keys don’t compound.

Unfortunately, having a database of all the keys still represents a single point of failure. The compounding risk factor is now every access to this database. We’re also only talking about a few hundred bytes per device. Exfiltrating the entire database is a little harder than stealing a single key, but hardly impossible. The only good news is that there’s a degree of forward secrecy. If (when?) the database is compromised, it won’t compromise future devices.

We can make the database harder to steal. Perhaps by keeping it offline. Perhaps by not keeping it in a computer at all. Print all the escrow keys on a sheet of paper. Thick, heavy paper (this is a long term archive after all) with one key per sheet. You’re not going to exfiltrate a million sheets of paper in your cargo pockets. You’re not going to be able to take pictures of all the pages. At least that’s my assumption, that with some reasonable physical security, we can keep “foreign agents” away from the data.

If we prevent the database from being stolen, we’ve also imposed an ordering constraint on anyone trying to decrypt a phone. They have to get the phone first, then break into the database to find the key. They can’t preemptively obtain the key because they don’t know which one to acquire. The smash and grab can only take place after looking at the phone.

We can make the breaking and entering part more difficult by sharding the keys. Dividing the keys between multiple sites makes it harder to get one particular key. But we need to balance that with the fact that more sites are more difficult to individually secure. Apple could keep the keys in a hundred different underground silos. The general surface vicinity would be off limits, but each silo would also be accessible only by unique personnel. The next obvious extension would be to split each key into a few parts and store them separately as well.

There’s my least worst idea. A per device backup key, split in pieces, stored on paper in underground silos.

The focus so far has been on preventing unauthorized access. The question of what constitutes authorized access is also of great concern, but also much murkier and not strictly a technical question. I’ll settle for saying that Apple should be running the storage sites, not the FBI, as a sort of check against rampant abuse.

At some level, asking “Would you rather have your escrow key kept in a mysql database in Cupertino or a Minuteman silo in North Dakota?” is like asking “Would you rather live without elbows or knees?”, but nevertheless I’m fairly confident that one option would let me sleep better than the other.

What’s the point? Because the common objection to key escrow is “It’s too hard.”, which is really only a compelling argument to people who already believe it. Anybody else watching the conversation from the outside will just say “You obviously haven’t even tried.” (“We already had this talk in the 90s.” is also apparently not very convincing. Without veering too far off topic, “women should vote” was also at one time “already discussed and dismissed” but fortunately kept coming back. It would be nice if the already discussed cannon only targeted bad ideas, but since it can obviously be targeted at any idea, it’s not a reliable ally.) Let’s try building the best escrow system we can, and then point out all the faults that remain.

Remember that the ultimate audience for this argument is the Senate. “Keeping secrets is impossible.” is not an argument that carries much water with Senators, because if they weren’t capable of keeping secrets, none of them would still be office. The fact that they continue to be reelected is, to them, convincing counterevidence that secrets can be kept.