Digital privacy protections, like all rights in a democratic society, are not absolute. The personal choices of individuals must be balanced against the reasonable intrusions of a society focused on the greater good¹.

Enabling lawful access to locked devices, like smart phones and computers, is a perennial challenge. Any breach will reveal an intrusive amount of personal information, including location/call/search histories, photos, and cloud services². It might also reveal corporate trade secrets and other information industrial spies would value. Not to mention military intelligence.

Never before in human history has so much of our lives been captured and distilled into such a small and easily searched container. We have every reason to lock our personal diaries tightly away from prying eyes.

Yet this wall of privacy must be breached, at least on occasion. Imagine a society where international shipping containers cannot be inspected. How would we prevent drugs and weapons from pouring though our borders? Imagine a world of impenetrable privacy, where white collar criminals can run their business from a smart phone- secure in the knowledge their illegal activities are hidden from the courts.

No rights are absolute. All walls must be permeable.

To prevent utter chaos and a breakdown of trust between the government and its citizens, protocols to unlock devices must be limited and secure. Unfortunately, the technical community is at odds with the government on this issue, correctly pointing out that hackers and spies have always managed to enter backdoors into our devices. No matter how well defended. Thus, the technical community has rallied around strong encryption with no backdoors as the only practical solution. Basically, they are promoting Abstinence as the only solution.

While I share these concerns, I also share the worry that the state, in a pique over what may be perceived as intransigence, will mandate a fragile solution. Or, they may surreptitiously insert flaws or weaknesses into encryption standards (again) to achieve access.

We must avoid the trap of seeking perfection as an excuse to stand in the way of necessity. In other words, are there solutions which are imperfect, but good enough? That is the purpose of this proposed key escrow scheme.

Key escrow in this proposal consists of three steps

• Extracting the key from the device
• Storing it securely in a Key Escrow Data Base (KEDB)
• Retrieving a small fraction of keys pursuant to legal and reasonable search warrants

Key Extraction: We reject any device-hosted backdoors as highly insecure. A fixed entry point, wired-into the device architecture accepting a pre-selected key  can be (and if recent history is any guide), will be compromised. Leaving every device in the country open to exposure by private and public agents alike.

Instead, we suggest escrowing the actual user password (and device ID). This is a “front door”, rather than “backdoor” approach. Whenever the password is changed, a new message is sent to the KEDB, and the new password/ID is entered in the KEDB. Unlike a backdoor, if the KEDB is compromised, users can simply changer their password, rendering a stolen KEDB moot.

In more detail:

• The user sets their device password
• An encrypted message, securely generated by the OS containing the password and device ID, is sent to the KEDB
• The KEDB issues an encrypted handshake back to the device, indicating the KEDB registration process was successful.
• At this point, the new device password is activated³.

Key Storage: The KEDB must be protected against numerous potential lines of attack. These include prosaic concerns like natural disasters, mismanagement, spoofing, theft by individuals, by groups or by rogue law enforcement officials, and attacks by state actors. We adopt a layered approach, which must be open to inspection and audited by third parties to assure public acceptance (or at least acquiescence) and to discover flaws in the protocols.

As a quick estimate, assuming 1 billion devices, with a 1KB device key file, the entire KEDB is only 1Terabyte in size, i.e. a standard laptop hard drive. This small size underlines the importance of strong security protocols.

In terms of network capacity, assuming passwords are changed once or twice a year, a 1 Mbit/sec port to the KEDB would suffice.

In terms of key retrieval, we expect (based on news reports) that only a hundred devices a day are authorized by a court for inspection and decryption.

In detail:

• The KEDB consists of two parts, a device ID database and a separate password database, linked via a common file name. The file name and device ID is stored in one database, the file name and password, in another.
• For security, these KEDB parts are stored on physically separate networks and locations. Both parts of the KEDB would have to be compromised to open a user’s device.
• Both databases are encrypted- no information is stored in plain text.
• The databases are stored in a RAID configuration with error correction. Each RAID element is physically separated and networked together. This blunts the effectiveness of compromising a single storage device or the impact of a single device failure.
• Most importantly, the KEDB hardware is a special purpose memory chip. This chip allows for the rapid addition of new keys, but physically limits (via internal timers) the number of key extractions to 100 a day. This on-chip timer prevents a mass-download of the entire database. Even in a state-of-emergency, this limit is inviolable. Such is the price of trading off personal privacy rights against valid governmental action.
• The memory device also maintains an audit trail of key access requests.

Key Retrieval: Only authorized agencies, after meeting strict regulations for key retrieval, can access the KEDB. The password and device ID are released to law enforcement to unlock a device, or to provide ongoing surveillance.  

In detail:

• Authorization of a device-ID retrieval request is communicated to a secure database management site. Proper credentials and network fingerprinting confirms authorized user.
• The device ID is used to retrieve the file name. This requires access to the KEDB network AND to the encryption keys used that secure the database.
• The file name is cross-referenced in a second physical database to retrieve the password.
• The authorize requester receives the combined key file.
• There is no outbound, network connected interface to the KEDB. Output data is limited to the key and deviceID, which is displayed in an optical QR code to the requester. No physical access to the storage devices are permitted

Concerns: No single individual is ever secured against a targeted attack by a competent adversary. But here we are concerned about the potential of mass surveillance, making the KEDB a high value target. So, the proper question is whether this proposal, compared to the value it brings to law enforcement and national security, creates a significant new leakage path that otherwise would not exist.

We already live in an imperfect world. Any system can be manipulated; no system is perfect. We are all aware of OS flaws, or compromised processor architectures or manipulated encryption standards, that enable massive attacks on affected devices. Many of these flaws are discovered only after the bulk release of private data, such as credit card or SSNs. A few backdoors have been intentionally left unpatched to allow three-letter-agencies to spy without the need to plant special-purpose software. The government can (and has) secretly require device manufacturers to insert backdoors, or could manipulate DNS certificates, and so on. A compliant Congress may drive the country in the direction of weak encryption or hardware locks, like many existing copyright protection schemes.

The appearance of privacy and control may be an illusion…

Given no viable alternative, the government will rely more heavily on dark arts  for access. An alternative like the KEDB could demonstrate the technical community is a rational partner, solving a real problem, while limiting the scope of accidental or intentional privacy compromise