Matthew Green Profile picture
Sep 2, 2021 23 tweets 5 min read Read on X
The story here, for those who may have forgotten 2015 (it was a long time ago!) is that the NSA inserted a backdoor into a major encryption standard and then leaned on manufacturers to install it. Thread. 1/
The backdoor was in a pseudorandom number generator called Dual EC. It wasn’t terribly subtle but it was *deniable*. You could say to yourself “well, that could be horribly exploitable but nobody would do that.” Lots of serious people said that, in fact. But they did. 2/
Not only did the NSA insert this backdoor into encryption standards, but they allegedly paid and pressured firms to implement it in their products. This includes major US security firms like RSA Security and Juniper. (That we know of!) 3/
In 2013, compelling evidence confirming the existence of this backdoor leaked out in the Snowden documents. We didn’t know quite how widely it had been implemented yet, but even then it was shocking. 4/
It would be such a terribly embarrassing story if it ended there. But it gets even worse. 5/
One of the products that the US Intel agencies allegedly convinced to use the backdoor was Juniper, whose NetScreen line of firewalls are widely deployed globally and in the US government. We didn’t know about this because the company hid it in their certification documents. 6/
Even if we’d known about this, I’m sure “serious” folks would have vociferously argued that it’s no big deal because only the NSA could possibly exploit this vulnerability (it used a special secret only they could know), so (from a very US-centric PoV) why be a big downer? 7/
But the field is called computer security; not computer optimism. We think about worst case outcomes because if we don’t do that, our opponents absolutely will. 8/
In fact, they already had. What nobody had considered was that *even if the backdoor required a special secret key* only the NSA knows, a system with such a backdoor could be easily “rekeyed.” 9/
In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/
The company was Juniper, the hack was in 2012. It is alleged (in this new reporting) to have been a Chinese group called APT 5. Untold numbers of corporate firewalls received the new backdoor, making both US and overseas systems vulnerable. 11/
The new, rekeyed backdoor remained in the NetScreen code for over *three years*, which is a shockingly long time. Eventually it was revealed around Christmas 2015. 12/
Fortunately we learned a lot from this. Everyone involved was fired and no longer works in the field of consumer-facing cryptography.

I’m kidding! Nobody was fired, it was hushed up, and everyone involved got a big promotion or lateral transfer to lucrative jobs in industry. 13/
The outcome of the Juniper hack remains hushed-up today. We don’t know who the target is. (My pet theory based on timelines is that it was OPM, but I’m just throwing darts.) Presumably the FBI has an idea, and it’s bad enough that they’re keeping it quiet. 14/
The lesson to current events is simple: bad things happen. Don’t put backdoors in your system no matter how cryptographically clever they look, and how smart you think you are. They are vulnerabilities waiting for exploitation, and if the NSA wasn’t ready for it, you aren’t. 15/
The second lesson is that “serious” people are always inclined away from worst-case predictions. In bridge building and politics you can listen to those people. But computer security is adversarial: the conscious goal of attackers is to bring about worst-case outcomes. 16/
It is very hard for people to learn this lesson, by the way. We humans aren’t equipped for it. 17/
I want to say only two more slightly “inside baseball” things about Juniper and this reporting.

First, the inclusion of Dual EC into Juniper-NetScreen wasn’t as simple as the NSA calling the company up and asking them to implement “a NIST standard.” Image
Juniper’s public certification documents don’t mention Dual EC was even used in NetScreen products. It lists another algorithm. The NetScreen Dual EC implementation is included *in addition* to the certified one, and without documentation. That stinks like cheese. 19/
And of course there is a very coincidental “oops” software vulnerability in the NetScreen code that allows the raw output of Dual EC to ooze out onto the wire, bypassing their official, documented algorithm. For more see: dl.acm.org/doi/pdf/10.114… 20/
I’ve told this story eight million times and it never ceases to amaze me that all this really happened, and all we’ve done about it is try to build more encryption backdoors. It makes me very, very tired. 21/21 fin
Addendum: the White House Press Secretary was asked about this story, and their answer is “please stop asking about this story.” h/t @jonathanmayer

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Matthew Green

Matthew Green Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @matthew_d_green

Mar 31
This thing Facebook did — running an MITM on Snapchat and other competitors’ TLS connections via their Onavo VPN — is so deeply messed up and evil that it completely changes my perspective on what that company is willing to do to its users.
I don’t come from a place of deep trust in big tech corporations. But this stuff seems like it crosses a pretty clear red line, maybe even a criminal one.
I would say: I’d like to see some very performative firings before I trust Meta again, but let’s be honest. This almost certainly went right to the top. Nobody is going to do something this unethical unless they know management has their back 100%.
Read 6 tweets
Mar 12
Google has a blog up discussing their threat modeling when deploying “post-quantum” (PQC) cryptographic algorithms. It’s an interesting read. bughunters.google.com/blog/510874798…
To elaborate a bit on what’s in the blog post, we know that quantum algorithms exist, in principle, that can break many of the cryptographic algorithms we routinely use. All we’re waiting for now is a capable enough quantum computer to run them. (And this seems hard.) 1/
But technology development isn’t linear. Sometimes problems seem impossible until a big breakthrough changes everything. Think about the development of classical computers before and after semiconductors. The same could happen with QC. 2/
Read 12 tweets
Mar 5
A thing I worry about in the (academic) privacy field is that our work isn’t really improving privacy globally. If anything it would be more accurate to say we’re finding ways to encourage the collection and synthesis of more data, by applying a thin veneer of local “privacy.”
I’m referring to the rise of “private” federated machine learning and model-building work, where the end result is to give corporations new ways to build models from confidential user data. This data was previously inaccessible (by law or customer revulsion) but now is fair game.
A typical pitch here is that, by applying techniques like Differential Privacy, we can keep any individual user’s data “out of the model.” The claim: the use of your private data is harmless, since the model “based on your data” will be statistically close to one without it.
Read 11 tweets
Feb 21
So Apple has gone and updated the iMessage protocol to incorporate both forward security (very good!) and post-quantum cryptography. security.apple.com/blog/imessage-…
This is a big deal because iMessage (which gets no real attention from anyone) is one of the most widely-adopted secure communications protocols in the world. At least 1 billion people use it, all over the world. It’s the only widely-available encrypted messaging app in China.
The original iMessage protocol was launched in 2011 and was really amazing for the time, since it instantly provided e2e messaging to huge numbers of people. But cryptographically, it wasn’t very good. My students broke it in 2015: washingtonpost.com/world/national…
Read 18 tweets
Dec 27, 2023
Article on some new research that finds ways to balance privacy and stalker detection for AirTags and other location trackers. This is a collaboration with my students @gabrie_beck, Harry Eldridge and colleagues Abhishek Jain and Nadia Heninger. wired.com/story/apple-ai…
TL;DR thread. When Apple launched their “Find My” system for lost devices in 2019, they designed a clever solution to keep bad actors (including Apple) from tracking users. This works by making devices change their broadcast identifier every 15 minutes. blog.cryptographyengineering.com/2019/06/05/how…
Two years later, Apple introduced the AirTag. At this point they noticed a problem: people were using location trackers to stalk victims, by placing them on victims’ possessions or cars. This led to several murders. arstechnica.com/tech-policy/20…
Read 18 tweets
Nov 12, 2023
I’m a sucker for crypto papers that do insane things like build ciphertexts out of garbled circuits, and then use the garbled circuit to do stuff that only shows up in the security reduction. Eg: eprint.iacr.org/2023/1058
So what’s fun about this paper is that it’s trying to do something weirdly hard: build cryptosystems that allow you to encrypt (functions of) secret keys. This can be encrypting your own secret key, or eg I can encrypt your secret key and you can encrypt mine to form a “cycle”.
The reason this is hard is that our standard definitions of security (eg semantic security) say that encryption must be safe for any possible messages an adversary can come up with. But adversaries don’t know my secret key, so the definition says nothing about that.
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(