The Importance of Cryptographic Safety Valves in Legislation

Cryptographic Safety Valves
Why we need to think about them
Matt Tait
@pwnallthethings
Senior Fellow @ Strauss Center @ UT Austin
What I’m 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
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
Vendor must be able to decrypt communications
Vendor must be able to decrypt communications 
after being presented with a decryption notice
Pretty tractable with fairly
small security costs
Cryptopocalypse,
everything is broken
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.
Do we even need a technical solution?
 
Do we even need a technical solution?
 
Do we even need a technical solution?
Cool idea, doesn’t always work.
Sometimes owner is dead 
(*owner may be victim, not perp)
See also: San Bernardino case, Las Vegas shooter
Sometimes bad people sometimes prefer jail to decrypting
1
:
Terrorism 
(attempt to bomb a UK barracks - Syed Hussain)
Sharing child abuse imagery 
(Oliver Drage, Alan Charles Godfrey)
Sexual predation of children
 (Umesh Kulasingham)
Credit card cloning and fraud
 (Thomas Beeckman)
1 
folks in jail for RIPA Section 54 violations
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?
How can we design E(X) so that A can decrypt it but B can’t
Secret
message
E(X)
Authorized
person
A
Not
authorized
person
B
X
Nope
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
Composability to kill off individual misuse
Who should be our authorized
person?
The government?
The vendor?
Composability to kill off 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:
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
Partial transparency ledgers
 
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?
Slide Note
Embed
Share

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.

  • Cryptography
  • Legislation
  • Data Security
  • Privacy
  • Technology

Uploaded on Oct 04, 2024 | 0 Views


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


  1. Cryptographic Safety Valves Why we need to think about them Matt Tait @pwnallthethings Senior Fellow @ Strauss Center @ UT Austin

  2. 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.

  3. 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

  4. 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

  5. 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.

  6. 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.

  7. 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.

  8. 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

  9. 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.

  10. 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.

  11. Composability to kill off individual misuse Who should be our authorized person? The government? The vendor?

  12. 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

  13. 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

  14. 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.

  15. 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

  16. 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 ?

  17. 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?

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#