Understanding the Importance of Cryptographic Safety Valves in Legislation
Legislation regarding cryptographic safety valves is impending, with potential implications on privacy and security. Matt Tait discusses the need to analyze risks and consequences, emphasizing the importance of transparent and secure safety valves. The debate surrounds decryption requirements for data and devices, highlighting the need for clarity to shape effective solutions amid evolving technological landscapes.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Cryptographic Safety Valves Why we need to think about them Matt Tait @pwnallthethings Senior Fellow @ Strauss Center @ UT Austin
What Im going to say 1. Legislation is coming 2. It will come suddenly, happen fast, and have sucky political conditions 3. USG isn t going to mandate a specific mechanism, and we don t want them to 4. Studying cryptographic safety valves helps us understand what language in that legislation has tolerable risks versus those with intolerable consequences 5. Some possible safety valves are more transparent, secure, and liberal than the status-quo alternatives.
Legislation is coming 2017 LV shooting, but a 23 year old immigrant with some E2E app on his iPhone instead of some 64-year old obviously-not-ISIS guy 851 people injured. 58 dead. Phone locked. ISIS mistakenly taking credit for the attack. Plaintext only on dead guy s locked phone. Metadata isn t content. Maybe it makes it look worse. House, Senate, WH, all controlled by same party. And Silicon Valley has torched its own credibility over Russia-gate. Politics of that moment will suuuck
The whole fight is over what that text will say Cryptopocalypse, everything is broken On presentation with a valid court order, vendor must be able to decrypt encrypted data On presentation with a valid court order, vendor must be able to decrypt encrypted devices Pretty tractable with fairly small security costs Vendor must be able to decrypt communications Vendor must be able to decrypt communications after being presented with a decryption notice Only prospective decryption, with far lower worst-case risks on e.g. LEO key- loss Requires retrospective decryption, with a far higher best-case risk profile
Finding a Solution without knowing the Question Will it cover just device encryption or also communications (E2E) encryption? Will we mandate retrospective as well as prospective decryption for wiretaps? Are we OK if a modified end-point can detect surveillance? What granularity of transparency will be allowed to the vendor, and to whom? The answers to these wildly change the possible technical solutions and the risks to users. Without clarity on what the legislation will require, it s better to talk about primitives than Solutions . Different primitives satisfy different requirements with different default/worst-case risk profiles.
The status-quo alternative is not zero-risk Individual abuse Abusive officer wants to illegally unlock his girlfriend s phone GrayBox in the office is super easy to abuse No technically enforceable transparency. No adversarial paralegals in the process Institutional abuse If FBI goes rogue, is it better checked by GrayBoxes or a process that involves Apple paralegals? Bigger conspiracies start slower and collapse faster. GrayBoxes and 0days cannot ever be reliably limited by a technically enforced mechanism. Grossly illiberal and insecure Boxes full of 0-days in 18,000 local law-enforcement agencies? Seizing devices while unlocked is inherently more dangerous to arrestees. Who will bear the brunt of that physical risk? Is it evenly spread over society? Device-locking weakens warrant-requirements in the U.S. thru implied exigency.
What about Gray boxes and 0-days etc? The status quo alternatives suuuuuuck The baseline for comparison isn t an imaginary world where law- enforcement sits on their hands. We should look for options that: Minimize risk of individual officer / staff abuse Minimize risk of systemic abuse A designed system might be less bad than the status quo alternative.
What options can cryptography give us? Not Authorized person A Secret message E(X) authorized person B X Nope How can we design E(X) so that A can decrypt it but B can t
Principles of cryptographic access A knows something B doesn t The most secure version of this will always be cryptographic envelopes You need to not lose your keys. A can do work that B can t The most secure version of this will always be key-shortening. You need to out-compute current adversaries, which is hard because China. You need to out-compute future adversaries, which is hard because Moore s law You can also compose these if you like. But all the possible options will ultimately boil down to one or the other.
Cryptographic envelopes Device uses key ? derived from user passcode for disk encryption Store ??(?) on the drive, encrypted with public key ? Only private key ? can recover ? Without private key, ??(?) gives adversary nothing Decryption process can be fully offline. Can do this with zero interactive attack surface Security is dependent only on security of private key.
Composability to kill off individual misuse Who should be our authorized person? The government? The vendor?
Composability to kill off individual misuse Yay composability! ???????(?????? ) Now neither vendor or govt can abuse the system unilaterally. So long as no person operates both, individual abuses now needs a multi-organizational conspiracy to pull off. Composability of access across multiple organizations reduces risk of individual misuse
Defending against key-loss and institutional abuse looks the same. We know how to solve this with CAs: key-use transparency. Use HSM-rooted Tamper-Proof Ledgers to record key-use: Looks like a blockchain Isn t actually a blockchain Much less venture capital interest No snakes harmed while mining for oil Only HSM can append to the end of the ledger Nobody not even HSM can delete or modify entries Everyone can verify the integrity and read the entries on the list
Defending against relay attacks is necessary, (but not hard) Not really enough time to cover here, but should point it out: Requestor HSM ?(?| ? ,? Decrypt to get ?||? Return ? Return ledger entry ? Knows ? Needed to stop both bad actor tricking LE into decrypting an onion and to stop bad LE officer decrypting phone that doesn t match warrant application.
Danger: need to protect against relay attacks Encode not just the key, but a device identifier into the decrypt onion Device with identifier ? and key ? stores ?(?||?) ? necessarily becomes published as a consequence of decrypting ?(?||?) Security dependency only on HSM keeping key safe, and public key security working as expected. HSM Please decrypt ???,? , ? 1. Decrypt ? ?,? with HSM key ? to get ?, ? 2. Check ? matches, to prevent relay attacks 3. Append ? to create a ledger entry ??(?) 4. Output ?,??(?) to the requestor OK. Here is: ? AND Tamper-proof entry of ? on some ledger
Partial transparency ledgers We can even do partial transparency: Instead of publishing ?, publish an encrypted ? with a key that the requestor can choose when to disclose Public Requestor HSM ?(?| ? ,? Decrypt to get ?||? Generate temporary key ? Return ? Return ledger entry ??(?) Now knows ?,? Publishes ??(?) Public can now see that a decryption occurred Publishes ? Public can now see that the decryption was of device ?
Recap 1. Legislation is coming a) It will come fast in adverse political conditions b) Knowing about safety valve primitives will help us have fight for better options when the legislation drafting happens. 2. There are lots of useful safety valve primitives a) Some of the security primitives are more robust against institutional and individual officer abuse than the status quo b) Some of the security primitives have pretty tolerable worst-case scenarios against even hyper- capable adversaries on some questions. 3. The math obstacle that decides when this happens is when the administration can count to 60 votes in the U.S. Senate, not when we decide we can do it or not. 4. Questions?
