This is ground breaking. The NSA made Juniper use a backdoored algorithm, and a foreign adversary hacked into Juniper and changed the backdoor key (essentially). That's surreal.
This smacks way more of "well, what did you expect would happen?" than surrealism. If you introduce a vulnerability, it is nothing but hubris to think that you'll be the only one to leverage the vulnerability.
Kind of, but my reading of it is that it was also a supply-side chain attack where they modified the constant that was used in the code before the binary was built. So at that level of access, I'm not sure any algorithms would hold up. I don't think Dual ECDRGB was used to attack the source control system.
The brilliant part is that they did it in a way that remained undetected for so long. And the reason they could do that is because the backdoor already existed.
It's decades of antivirus style mindsets (we'll just clean up after), mixed with formerly being in law "enforcement" (we can't do anything until AFTER the law is broken), mixed with decades of "security by obscurity" and paranoid "hide and seek" culture, mixed with 9/11 vengeance, plus American exceptionalism.
With a smack of ham to it. I call it hot ham water.
It's very important to clarify that the NSA didn't make them use it. The DoD required it as terms for future contracts. Juniper grabbed the money in knowing exchange for putting their customers at risk.
Why does that distinction matter? It dramatically increases Juniper's culpability in the scheme. If the DoD had actually forced them to use it, that dramatically reduces Juniper's culpability.
This is exactly how they "make" a company do something. Look at what happened to the Qwest (IIRC?) CEO to see what happens if you refuse these contracts.
If a company refuses, they are making a decision (more of a gamble). Corporations will almost universally sacrifice customer safety for profit. Especially when they are making a decision between "for sure losing opportunity money" and "maybe losing money after a court case".
That does not mean they aren't liable when things go bad.
Nacchio simply tried to use it as an excuse. He was just throwing shit against the wall and hoping that some of it stuck. Here's his claim: he was not in a rightful state of mind when he sold his shares because of problems with his son, and the imminent announcement of a number of government contracts.
Yeah sure, I know exactly what he means. Whenever I'm not in a "rightful state of mind" the way I cope with it is to dump company stock that I'm restricted from selling. /s
Nacchio was nothing but a greedy scumbag, and he went to Federal prison because of it.
Nobody is denying he insider traded, but was the insider trading (or other unlawful activities) of others that did comply go ignored/suppressed or otherwise swept under the rug?
Exactly, if a company is willing to go to court they can't be made to build backdoors like this, at least not yet. Hence why everyone was peeved at apple for siding with the government to add government spyware to every apple phone to make sure citizens comply.
There is an interesting aspect of the room 641a story that could turn out to be different in detail:
The Wikipedia article says, as do other accounts, that beam splitters were used to tap into fiber optic lines. That might in fact be how it was done, but I do not think that was necessary.
IIRC, Juniper core routers were (uniquely, at the time?) capable of duplicating traffic on a NIC to another NIC without performance impact on capacity as a whole. This would have made them particularly suitable for mass surveillance that would not show up in network management metrics.
I don't get why this is downvoted. There is a huge difference between, say, a court order or other force-backed request and a requirement in a bidding process.
It doesn't absolve the NSA of any guilt here either, but this is not a helpless Juniper giving in due to full weight and power of the government.
Theoretically you can run any software on any hardware so all hardware in the world is infected.
No, I'm not being serious. Obviously what dheera is referring to is not software vs hardware but rather what hardware is affected. To comment that it's the hardware that is running the software that is infected is hardly useful.
Right, I'm wondering what models were designed to officially run the software that was infected, and if there are models that are known (by source code, reverse engineering or otherwise) to run uninfected firmware.
You can argue that is was a software problem, not a hardware problem. This is wrong. It was a human problem. The humans involved span the software and hardware and more across all models.
No, that's expected behavior and will eventually happen approaching the limit of 100% of the time.
Even worse, a backdoor is often a greater security risk than normal authorization because the backdoor can often access all the data, not just a single user's data.
In short, if you are in government, do not ask for backdoors, if you are in the private sector do not make backdoors. Backdoors are a flawed idea that leads to very bad things for everyone (private sector losses hit government in the pocketbook, too).
Keep in mind that an attacker that can change source code can add a backdoor where there is none. Backdoors are dangerous because their keys can leak. In the case of Dual_EC a leak would have been particularly dangerous because the attack enabled by having the backdoor's key is passive, so not easily detected.
A backdoor rekey attack, if it lets the attacker gain a foothold that allows them continued access after the attack is detected. That is really bad!
I'm surprised we haven't seen an article explaining that the chip shortage is due to so many hidden chips being secretly placed on mobos used by the largest vendors.
The Heart of Gold has the improbability drive, while its sister ship the Heart of Silver has the incredulity drive. I like it. I hadn't heard that one before.
If you are referring to Bloomberg's bombshell story about rogue chips installed on motherboards in China during assembly at the factory that then have compromised Apple and Amazon (referenced here: https://www.aei.org/technology-and-innovation/bloombergs-bom...) than the far-fetched element is that it has been three years since the story came out and not a single element of physical evidence have been presented, when one would simply need a microscope to find them in devices. This after multiple major news organizations spent years trying to follow-up on the story and found no evidence whatsoever to back it up.
It was a game of telephone gone horribly wrong, and Bloomberg's reputation is shot since they have refused to retract it.
>when one would simply need a microscope to find them in devices
This isn't a true statement, if strictly read--there are many techniques to hide undocumented components on boards, and covering all of them requires more than just a pass under a SEM. There's a fun talk that goes over a lot of them here: https://www.youtube.com/watch?v=RqQhWitJ1As
Not surreal at all. It's exactly what everyone in the cryptography communuty said would happen if people listened to the government and added backdoors for the "good guys".
Hope this sort of thing keeps happening. I want more concrete examples to cite when people defend this stupidity. I want the governments of the world to be too embarrassed to talk about cryptography ever again, least of all demand backdoors into private infrastructure.
They won't. You'll have lists and lists and lists, and they'll just say "you live in a society, you have no reasonable expectation of privacy", and then expect you replace your walls with glass on your house.
They're too far gone if they still believe "if you have nothing to hide, you have nothing to fear" so openly.
And if you think they only strong-armed Juniper into doing this, I've got seaside real estate in Nevada to show you. AT LEAST Cisco should be considered compromised as well.
lol no! it was totally expected and security people and encryption advocates have been literally saying this kind of thing was bound to happen for Decades. You can only imagine how much of this remains out there. Also, see the recent Apple debacle. Letting government interfere with private business without a warrant is always, always bad. Even with a warrant it is troubling, but at least there are some checks and balances from the courts (supposedly neutral party)
Some Juniper gear emulated the IP2 forwarding asics in software, its fairly decent for what it is. All of the packet inspection stuff runs inside of FreeBSD. The new vSRX is all software and uses commodity cpu power for everything.
For raw speed, pfsense does a really good job on the low end of things but doesn't offer a lot of the inspection/IPS features that JunOS has. Arguably few people actually need IPS anyways.
The same goes for a VMX, which arguable is even harder to virtualize (and it is not on par with a real MX series router yet). Mainly because emulating some trio chipset features is at the moment very hard/impossible to do with great performance. (especially the dense queing part)
There are switches out there by either Juniper or Cisco (can't remember which job I used them at) which actually have ARM CPUs on each switchport for one hardware acceleration feature :)
It would be interesting to see a refreshed view of what products white-box is able to replace. I recall that Juniper and Cisco were hard to replace for some products because the performance edge was in proprietary ASICs that aren't available to white box builders.
I suspect that CPU improvements and things like user-space networking (DPDK and friends) might have closed the gap some, but I haven't seen any recent analysis.
i doubt you are able to get the same features out of whitebox hardware.
Juniper's core routers have neat features in terms of redundancy. failing over a FPC (card with ASIC) to another routing engine(control plane) without downtime or packet flow impact is a big one. Performance might be there on the lower end (<40g), but there are a lot of features which require asics.
Another example is QoS/CoS without impacting performance or queues. These are the kind of things you cannot handle at the CPU without impacting traffic performance, which bites you when you are doing major traffic flows.
True, although every time I've tried it out its been fairly garbagey so I never considered it seriously. Its been at least 2 years though, I'll try it again.
Actually I think P4 programmable switch ASICs such as Barefoot are going to become more prevalent over time and hence features will be available in software.
P4 programmability is available in Cisco Silicon One so wouldn’t call P4 dead in the water. Cisco Silicon One is meant to go head to head against Broadcom.
In other merchant silicon, while not P4, Broadcom has offered their own proprietary programmability in Trident 3/4.
I think adoption has been slower more due to lack of relevant domain expertise in software as well as relative inability of pretty much anyone to properly model the impact of routing features on a production network than anything else.
Whitebox solutions can be adopted by corporations that can afford to have dedicated teams to maintain the software stack. For others, it can be quite risky.
> Whitebox solutions can be adopted by corporations that can afford to have dedicated teams to maintain the software stack.
Pretty much. Unless you have some remarkably top-notch people, this proposal is just security theatre. The chances you'll compromise yourself through an error in a complex area are much higher than the liklihood a sophisticated attacker will breach you.
Well one heuristic to look at is how much proprietary and closed-source software is out there, and then make a rough estimate, say 3% of proprietary software has some sort of backdoor or malicious payload in it.
What you have to ask, is why is certain software proprietary? Most of it is innocent, but sometimes it's closed for evil reasons.
No, you can't trust NIST on security. They've certified algorithms they must have known were deliberately weakened in every generation: DES in the 1970s, the Clipper chip in the 80s, "export-grade" RSA in the 90s, and broken RNGs in the 2000s.
The deliberate weakening generally comes from the NSA, but NIST is required to work with them on security standards.
A number of reputable security researchers claim that NIST's misdeeds were all unintentional and they've learned their lesson and there won't be any more backdoors. Perhaps. Ultimately they serve the US administration, so in the long term it depends on whether future administrations actually want everyone to have unbreakable cryptography. Doesn't seem like a safe thing to count on.
To clarify: the deliberate weakening for DES was literally reducing the key size. There was also some suspicious behaviour with the S-boxes, but that turned out not to be a attack. Sadly, but unsurpisingly, it's not as simple as "Do the oppposite of what the nation state adversary recommends.", although these days independent research is doing well enough that "Ignore them[0] unless they have a non-'trust us' justification." is a adequate policy.
0: for crypto design advice; obviously they're still a attacker and you need to deal with that
I think this is a little unfair to NIST. Some parts aren't entirely factual. For example while DES was specified at 56 bits if we discount parity bits, I'm not sure how much choice they had in this - I suspect NSA/US gov more widely here. NSA, which is distinct from NIST but obviously works with them, requested changes to the DES S-Boxes during design that resulted in better protection from differential cryptanalysis, a technique unknown to anyone else at the time. So the NSA weakened DES in one way but strengthened it in another.
A lot of this weakening of ciphers was US government policy at the time: crypto was considered only to have military applications so in the same way foreign countries don't get the full US-edition fighter jet, they also didn't get the full crypto.
DualEC was a mess, no doubt, and should never have been standardized. I'm guessing they were railroaded by NSA. What is bizarre is that everyone knew it sucked. Not only the backdoor potential but also that it was slow. In fact the backdoor was even patented: https://worldwide.espacenet.com/publicationDetails/biblio?CC... which is my personal favorite part of the saga.
So while DualEC was a mess and the export policy was disliked, generally speaking the NIST process for standardising things is widely regarded.
Of course that does not mean you should trust them blindly, but examine the evidence. AES, SHA3, the lightweight crypto competition and the pqc process will all produce ciphers from largely non-US scientists and there are detailed discussions on the forums and at the workshops.
Of course if they decide to shut down these forums for discussion or ignore community consensus then there are definitely reasons to worry.
> "Intentional use of escrow keys can provide for back up functionality. The relationship between P and Q is used as an escrow key and stored by for a security domain. The administrator logs the output of the generator to reconstruct the random number with the escrow key." [1]
We were just using it wrong, it's a backup tool, not an encryption standard. ;-)
> [...] I'm not sure how much choice they had in this - I suspect NSA/US gov more widely here. [...]
Note that when parent says "you can't trust NIST" and you counter with something along the lines of "that's unfair... NIST acts untrustworthy/knowingly recommends subpar options because of NSA", it doesn't really counter what is being said.
If NIST decisions are based mostly on "whatever the NSA tells them to do", rather than the actual technical merits of the things they recommend, then... yes, they are generally not worthy of trust (blind or otherwise), because you'll always have to double-check their statements against other sources (e.g. your own knowledge, expert cryptographers, etc.).
Fool me once, shame on you; fool me twice, shame on me.
That's the problem of being untrustworthy once in a while... it's easier to lose your reputation than to regain it.
As it is... if you use anything recommended by NIST without first checking with the actual trustworthy community of researchers, you're asking for it.
TL;DR: Trying to justify why the NIST is seen as untrustworthy (or acts as such) does not change the fact that it is seen as untrustworthy by many people (and, as far as I can tell, fairly so).
I'm actually thinking we have these kinds of backdoors in all products that may impact national security. Think it this way: What's the best way for NSA to conveniently access any product without pulling any string because doing so may alert the perpetrator? This is the only way that it can do it quietly. Of course, theoretically they could hire massively numbers of researchers and programmers but I don't really think it's gonna enough.
Maybe I’m just jaded but isnt this the bottom of the slippery slope? The backdoored algorithm from a state actor was the slippery slope.
Starting to think “slippery slope” worries are unfalsifiable, because there is no standard for admitting that the precedent already occurred and the worst scenario already happened.
Oh yeah, and unfalsifiable things are illegitimate to me
Heart bleed is still the biggest point against your argument.
The key word you correctly used is OPPORTUNITY.
I like smaller localized governance, but would not be opposed at all to a federal subsidized program for security bugs and open source development of algorithms and code for commonly required tasks.
He had answered, in advance-- in the form of a formal complaint because the substance of NIST's message (the complaint that DJB had hung a carrot of 'attacks' in front of them in private but hadn't delivered a publication 'on time') had been previously stated by one of their staff. He published the formal complaint today:
Well that's what most open source does today. GitHub posted a blog post four days ago that the majority of SSH clients have moved away from aes to chacha. https://github.blog/2021-09-01-improving-git-protocol-securi... I wouldn't be surprised if the majority of https traffic uses x25519 these days instead of rsa or ℘256. djb is an influential guy.
This was known to be compromised, though. People using it anyway weren't being fooled because they couldn't audit the code. They were forced by federal standards or they'd lose the ability to sell to the government and go out of business.
Your best bet is multiple layers of defense. It may sound ridiculous, but don't use just one VPN/firewall. Make your adversaries compromise multiple vendors. Encrypt several times. That's what the actual DoD does and why the NSA probably doesn't even care. And, of course, the really important information is classified and never hits a publicly reachable network at all, so compromising the supply chain doesn't even help. As a private organization, you probably don't have the option to build an entirely separate network that doesn't touch the Internet and then protect the ingress/egress nodes with your own private military, so I don't know what to tell you there.
The article tells us "the Pentagon tied some future contracts for Juniper specifically to the use of Dual Elliptic Curve". That's not outright coercion but it's a significant incentive. Hell, RSA allowed itself to be corrupted for a measly $10M. https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...
This has nothing to do with "weakening of ECC". Dual_EC_DRBG is an RNG that happens to use Elliptic Curves but its problems have nothing to do with that, they have to do with the design of the RNG itself. And those problems don't say anything about the strength of ECC used for encryption and digital signatures.
The Pulse Secure exposure is pretty scary. If you have to comply with stupid Federal security requirements, Pulse and Cisco are pretty much the main players. Pulse is a steaming turd without back doors.
Yeah, the spin out lowered the product quality for sure.
Pulse is a winner from a UX standpoint, its "ok" from an admin/operational perspective but its not great. There was a while when some simple netconf commands would crash Pulse.
I brought this up at a BAJUG meeting and the engineers there said "yeaaaah, don't use netconf".
AFAIK Pulse is still based on the old Neoteris codebase so who knows what else is still in there...
> Members of a hacking group linked to the Chinese government called APT 5 hijacked the NSA algorithm
Just wanted to acknowledge how brilliant that is. They could have made any other code change, but it was genius using NSA's own backdoor.
NSA advocated for that backdoor to be included in the standards. The US government then would be embarrassed and would want to cover up any issues related to it, including the fact that it was taken over by someone else!
Gotta wonder what that Monday morning meeting was like at the NSA when they realized what had happened.
I think you may be surprised, in the NSA they refer to some exploits as NOBUS (nobody but us) where they earnestly believed that only they had the knowledge and capability to find and carry out certain exploits.
It seems silly now, especially as the civilian bar for these types of exploits continually lowers, but it's not unreasonable for them to have believed something like this decades ago, especially before widespread computer usage.
The NSA is staffed by non-target candidates that would never get a meeting in Silicon Valley, largely from DC area universities.
Although there is no real skills gap between target school graduates and non-targets, this observation also serves the dual purpose of undermining the NSA’s perceived omnipotence.
There were two backdoors that were discovered at the time btw, the other one was a hardcoded password that could get you in any router (or something like that?) Odds are that there are more that weren't caught.
> The US government then would be embarrassed and would want to cover up any issues related to it, including the fact that it was taken over by someone else!
I feel more like, there’s a chance that by modifying an intentional backdoor it could be that it would go unnoticed because anyone at the NSA looking at it may skip over reviewing closely the part of the code that has the known backdoor in it.
Just wanted to acknowledge how brilliant that is. They could have made any other code change, but it was genius using NSA's own backdoor.
Steal the other guy's stuff is no longer brilliant, it's not even surprising. It shouldn't have been surprising to "brilliant" people advocating back doors back in the day.
> Just wanted to acknowledge how brilliant that is. They could have made any other code change, but it was genius using NSA's own backdoor.
It is much more plausible that US companies didn't want to name and shame their biggest customer than the Chinese reverse engineering a cryptographic backdoor. This could have been supported by the general NSA/GCHQ efforts to ensure their activies are mis-attributed.
The "it was China" determination was made by Mandiant, a company that receives over half its revenue from the US government (per the 2014 FireEye M&A call).
Heck, Microsoft (Longhorn), SecureWorks (Platinum Colony), and Google (GOSSIPGIRL) are the only US companies that have even publicly assigned names to track US linked APT groups.
> Heck, Microsoft (Longhorn), SecureWorks (Platinum Colony), and Google (GOSSIPGIRL) are the only US companies that have even publicly assigned names to track US linked APT groups.
I didn't understand this statement, but it's intrigued me. What are the names for and how do they lead to tracking US-linked APT (advanced, persistent threat a.k.a state sponsored) groups and who's doing the tracking?
The original idea was to assign a name to a unique set of techniques and tools. That way you can collaborate with other organizations and have a common language to describe attackers. Many companies decided to start using their own naming schemes to avoid giving free marketing to the first company to name a group, so you have to do a bit of work to know that all the names I mentioned in my previous post refer to the same group.
CrowdStrike has a naming scheme that includes implied classes for specific countries of origin. For example you may have heard of "FANCY BEAR" which is part of the BEAR family but different from the "COZY BEAR" group. Everyone in the industry knows FANCY BEAR is the Russian GRU and COZY BEAR is Russian SVR, but by using the code names nobody has to come out and say it publicly (or face the consequences of being wrong).
The three companies I named are the only US based ones I know of that have publicly assigned named to US based threat actors. Kaspersky Antivirus (a Russian company) calls them the "Equation Group" due to their love of complex encryption, and the Hungarian government calls them "Tilded Team." If you ask Mandiant or CrowdStrike - they don't exist.
For its first 50 years or so NSA had a dual mission: protect the US from spying while spying on others. But these last 20 years they've undermined that first mission. They've now attacked and weakened American technology so many times that you'd be crazy to trust anything the NSA offers to make you more secure. It doesn't help when they lose control of their own hacking tools igniting a major expansion in ransomware.
I don't think America can ever recover from this breach of trust. Maybe NSA just needs to be shut down entirely. Or at least redefined explicitly as an adversarial agency to everyone.
You are correct, and the transition point was 9/11. Before that the NSA was doing good work shoring up our digital infrastructure, as well as working with the FBI to go after international crime syndicates. I wish we could get back to that.
> you'd be crazy to trust anything the NSA offers to make you more secure
You'd also be crazy to trust anything made by American gear vendors. This is not the only instance of this, just one of the ones for which FVEY got caught.
Is non-US gear also compromised? Yeah, probably. But the PLA and the GRU can't physically confine you to an 8x8 steel cage on trumped-up charges predicated on the data they exfil from your network.
Your best bet is to buy gear from countries either not-friendly or actively hostile to the country you're in. Sure, you're probably pwned, but they're not sending a SWAT team in an MRAP to shoot your dog, either.
That doesn't help if you're trying to be safe from a powerful world government - one with the resources and will to infiltrate an open project for its own ends. It's far less likely that there are US backdoors in Huawei routers (which surely contain Chinese backdoors!) than in any mostly american open-source software you pick.
Huawei routers are well known to be backdoored by the Chinese government. If you’re worried about attacks from nations then you can only build things yourself from scratch, your next best option is things done in the open since the bar for hiding back doors is much higher.
>But the PLA and the GRU can't physically confine you to an 8x8 steel cage on trumped-up charges predicated on the data they exfil from your network.
Actually they can, and with less legal recourse for you than in the US. It just depends on where in the world you happen to be when they decide they want you.
It is entirely nonsensical to me that buying from alibaba would save you from an overly-inquisitive domestic government.
In any country, you'll end up in a steel cage regardless of whether you bought your computer or software from the KGB, NSA, or a homemade kit in a bazaar in Nicaragua made by a kid from Chile.
Bloomberg at the frontline of "having no idea how anything works at all".
When the NSA designed DEC, they primed it with constants, that you'd need to know to break the encryption with low effort.
Somebody discovered that and made it known publicly.
So now before the rumors evolve into actual security engineers looking into it, the NSA creates a scapegoat APT, that "altered" some "code" at Juniper.
Of course nobody finds out, who those APT are, because attribution is 1% more accurate than astrology.
I lost you at the second paragraph. Crypto researches generally agree today that the NSA actually chose strong contents for DES (I assume that's what you meant by DEC?). They invented differential cryptanalysis a decade before anyone else, and used that to strengthen the cypher. Everyone suspected their motives at the time, but eventually academy caught up with the knowledge the NSA had, and could show that the constants are in fact good.
Too bad they're doing the opposite of that nowadays...
The article mentions the Clipper Chip briefly but doesn't touch on what was widely believed at the time -- that the NSA and their political counterparts went completely silent on using legislation to backdoor encryption algorithms not because they lost the fight but because they had found a better way.
Question- wouldn’t the change made by APT5 have been eventually obvious to whoever was originally using the back door? It would stop working for whoever expected the original value to be used, right? How did that go undetected for years?
Optimistic theory: it really was just for emergencies and was not in active use. Pessimistic theory: the NSA had already moved on to bigger and better exploits, but couldn't be bothered to tidy up.
Are there alternative OSes for this very specific hardware? I mean, Juniper aside, the risk that other network gear is similarly affected as well surely is not zero, so I wonder if there is any FOSS (also as in auditable) alternative firmware for these devices, or any ongoing efforts to create one.
It's too bad Soekris is gone. For home and small-corp networks they made an awesome router and you could put your favorite Linux on there. Trustable devices are hard to find.
Also, if anyone knows of a Soekris like alternative I'm all ears, what to do if my 6501 and my spare 6501 die.
It does have limitations, e.g. only 1 GHz clock speed.
The bigger problem for all manufacturers is the chip shortage. E.g. most of PC Engines stuff is "expected ~ 2022". But there may be some stock at their distributors. https://www.pcengines.ch/newshop.php?c=4
Edit: if you dig deeper you may also find hardware you didn't expect. E.g. at some point OpenBSD was able to run on some Ubiquiti hardware. I don't know if Ubiquiti still make products that can run OpenBSD. https://www.openbsd.org/octeon.html
I am cautious on the purported facts of anything reported when it comes out of "Bloomberg News investigation" that "has filled in significant new details."
In my opinion, they jump to conclusion on insufficient circumstantial evidence. I have not forgotten the SuperMicro debacle.
In this article, they repeat the some jumping and aggrandizing on multiple fronts.
Something I still fail to grasp entirely: according to the Twitter feed discussed here previously [1] the NSA just wanted Dual EC "in there", even, if nobody would use it, but they could use it. (They would even allow the choice of alternative values for P and Q.) Was this relying on negotiating encryption methods while establishing connections? Or did this imply yet another attack?
I would have thought, provided that the aforementioned statements were factual, you had to have some mechanism in place to force a connection to default to this algorithm for this to be useful in a more general way. (Apparently, you want to tap into third party conversations, but are not relying on them actually using this algorithm, rather, just having it implemented.)
179 comments
[ 3.6 ms ] story [ 242 ms ] threadhttps://archive.is/QISk9
With a smack of ham to it. I call it hot ham water.
It's very important to clarify that the NSA didn't make them use it. The DoD required it as terms for future contracts. Juniper grabbed the money in knowing exchange for putting their customers at risk.
Why does that distinction matter? It dramatically increases Juniper's culpability in the scheme. If the DoD had actually forced them to use it, that dramatically reduces Juniper's culpability.
If a company refuses, they are making a decision (more of a gamble). Corporations will almost universally sacrifice customer safety for profit. Especially when they are making a decision between "for sure losing opportunity money" and "maybe losing money after a court case".
That does not mean they aren't liable when things go bad.
Nacchio simply tried to use it as an excuse. He was just throwing shit against the wall and hoping that some of it stuck. Here's his claim: he was not in a rightful state of mind when he sold his shares because of problems with his son, and the imminent announcement of a number of government contracts.
Yeah sure, I know exactly what he means. Whenever I'm not in a "rightful state of mind" the way I cope with it is to dump company stock that I'm restricted from selling. /s
Nacchio was nothing but a greedy scumbag, and he went to Federal prison because of it.
https://en.wikipedia.org/wiki/Joseph_Nacchio
https://en.wikipedia.org/wiki/Room_641A
The Wikipedia article says, as do other accounts, that beam splitters were used to tap into fiber optic lines. That might in fact be how it was done, but I do not think that was necessary.
IIRC, Juniper core routers were (uniquely, at the time?) capable of duplicating traffic on a NIC to another NIC without performance impact on capacity as a whole. This would have made them particularly suitable for mass surveillance that would not show up in network management metrics.
“We want you to backdoor your product for ‘National Security’ and if you do, we’ll buy many millions of dollars worth of your gear.”
What doesn’t make sense about that?
It doesn't absolve the NSA of any guilt here either, but this is not a helpless Juniper giving in due to full weight and power of the government.
No, I'm not being serious. Obviously what dheera is referring to is not software vs hardware but rather what hardware is affected. To comment that it's the hardware that is running the software that is infected is hardly useful.
You can argue that is was a software problem, not a hardware problem. This is wrong. It was a human problem. The humans involved span the software and hardware and more across all models.
No, that's expected behavior and will eventually happen approaching the limit of 100% of the time.
Even worse, a backdoor is often a greater security risk than normal authorization because the backdoor can often access all the data, not just a single user's data.
In short, if you are in government, do not ask for backdoors, if you are in the private sector do not make backdoors. Backdoors are a flawed idea that leads to very bad things for everyone (private sector losses hit government in the pocketbook, too).
A backdoor rekey attack, if it lets the attacker gain a foothold that allows them continued access after the attack is detected. That is really bad!
Do you really need it explained why that's far fetched? I'm going to let you think on that a bit longer. It should have kicked in by now.
It was a game of telephone gone horribly wrong, and Bloomberg's reputation is shot since they have refused to retract it.
This isn't a true statement, if strictly read--there are many techniques to hide undocumented components on boards, and covering all of them requires more than just a pass under a SEM. There's a fun talk that goes over a lot of them here: https://www.youtube.com/watch?v=RqQhWitJ1As
Hope this sort of thing keeps happening. I want more concrete examples to cite when people defend this stupidity. I want the governments of the world to be too embarrassed to talk about cryptography ever again, least of all demand backdoors into private infrastructure.
They're too far gone if they still believe "if you have nothing to hide, you have nothing to fear" so openly.
The NSA's Backdoor in Dual EC - https://news.ycombinator.com/item?id=28404219 - Sept 2021 (87 comments)
Some Juniper gear emulated the IP2 forwarding asics in software, its fairly decent for what it is. All of the packet inspection stuff runs inside of FreeBSD. The new vSRX is all software and uses commodity cpu power for everything.
For raw speed, pfsense does a really good job on the low end of things but doesn't offer a lot of the inspection/IPS features that JunOS has. Arguably few people actually need IPS anyways.
I suspect that CPU improvements and things like user-space networking (DPDK and friends) might have closed the gap some, but I haven't seen any recent analysis.
Juniper's core routers have neat features in terms of redundancy. failing over a FPC (card with ASIC) to another routing engine(control plane) without downtime or packet flow impact is a big one. Performance might be there on the lower end (<40g), but there are a lot of features which require asics.
Another example is QoS/CoS without impacting performance or queues. These are the kind of things you cannot handle at the CPU without impacting traffic performance, which bites you when you are doing major traffic flows.
Nobody is really using DPDK/NETMAP in OSS products from what I can tell.
Netgate is doing TNSR, but its not open source: https://www.netgate.com/tnsr-applications/edge-routing
https://www.cisco.com/c/en/us/solutions/collateral/silicon-o...
In other merchant silicon, while not P4, Broadcom has offered their own proprietary programmability in Trident 3/4.
I think adoption has been slower more due to lack of relevant domain expertise in software as well as relative inability of pretty much anyone to properly model the impact of routing features on a production network than anything else.
P4 is being widely adopted at the NIC level.
Pretty much. Unless you have some remarkably top-notch people, this proposal is just security theatre. The chances you'll compromise yourself through an error in a complex area are much higher than the liklihood a sophisticated attacker will breach you.
And can we trust standard committees who, funded by public, put back doors in encryption and weaken security of public services?
What you have to ask, is why is certain software proprietary? Most of it is innocent, but sometimes it's closed for evil reasons.
The deliberate weakening generally comes from the NSA, but NIST is required to work with them on security standards.
A number of reputable security researchers claim that NIST's misdeeds were all unintentional and they've learned their lesson and there won't be any more backdoors. Perhaps. Ultimately they serve the US administration, so in the long term it depends on whether future administrations actually want everyone to have unbreakable cryptography. Doesn't seem like a safe thing to count on.
To clarify: the deliberate weakening for DES was literally reducing the key size. There was also some suspicious behaviour with the S-boxes, but that turned out not to be a attack. Sadly, but unsurpisingly, it's not as simple as "Do the oppposite of what the nation state adversary recommends.", although these days independent research is doing well enough that "Ignore them[0] unless they have a non-'trust us' justification." is a adequate policy.
0: for crypto design advice; obviously they're still a attacker and you need to deal with that
In 1975 brute-forcing of 56-bit keys was a NOBUS capability.
A lot of this weakening of ciphers was US government policy at the time: crypto was considered only to have military applications so in the same way foreign countries don't get the full US-edition fighter jet, they also didn't get the full crypto.
DualEC was a mess, no doubt, and should never have been standardized. I'm guessing they were railroaded by NSA. What is bizarre is that everyone knew it sucked. Not only the backdoor potential but also that it was slow. In fact the backdoor was even patented: https://worldwide.espacenet.com/publicationDetails/biblio?CC... which is my personal favorite part of the saga.
So while DualEC was a mess and the export policy was disliked, generally speaking the NIST process for standardising things is widely regarded.
Of course that does not mean you should trust them blindly, but examine the evidence. AES, SHA3, the lightweight crypto competition and the pqc process will all produce ciphers from largely non-US scientists and there are detailed discussions on the forums and at the workshops.
Of course if they decide to shut down these forums for discussion or ignore community consensus then there are definitely reasons to worry.
We were just using it wrong, it's a backup tool, not an encryption standard. ;-)
[1] US2007189527, abstract: https://news.ycombinator.com/reply?id=28427331&goto=item%3Fi...
Note that when parent says "you can't trust NIST" and you counter with something along the lines of "that's unfair... NIST acts untrustworthy/knowingly recommends subpar options because of NSA", it doesn't really counter what is being said.
If NIST decisions are based mostly on "whatever the NSA tells them to do", rather than the actual technical merits of the things they recommend, then... yes, they are generally not worthy of trust (blind or otherwise), because you'll always have to double-check their statements against other sources (e.g. your own knowledge, expert cryptographers, etc.).
Fool me once, shame on you; fool me twice, shame on me.
That's the problem of being untrustworthy once in a while... it's easier to lose your reputation than to regain it.
As it is... if you use anything recommended by NIST without first checking with the actual trustworthy community of researchers, you're asking for it.
TL;DR: Trying to justify why the NIST is seen as untrustworthy (or acts as such) does not change the fact that it is seen as untrustworthy by many people (and, as far as I can tell, fairly so).
I'd like to be able to perform SAST scans and code review on all software that protects my enclaves.
Starting to think “slippery slope” worries are unfalsifiable, because there is no standard for admitting that the precedent already occurred and the worst scenario already happened.
Oh yeah, and unfalsifiable things are illegitimate to me
The key word you correctly used is OPPORTUNITY.
I like smaller localized governance, but would not be opposed at all to a federal subsidized program for security bugs and open source development of algorithms and code for commonly required tasks.
Plus it's also extremely difficult to make underhanded changes to magic numbers if the source code is public.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/3mVe...
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4baO...
Your best bet is multiple layers of defense. It may sound ridiculous, but don't use just one VPN/firewall. Make your adversaries compromise multiple vendors. Encrypt several times. That's what the actual DoD does and why the NSA probably doesn't even care. And, of course, the really important information is classified and never hits a publicly reachable network at all, so compromising the supply chain doesn't even help. As a private organization, you probably don't have the option to build an entirely separate network that doesn't touch the Internet and then protect the ingress/egress nodes with your own private military, so I don't know what to tell you there.
I wonder if they were coerced into including it?
https://www.schneier.com/blog/archives/2007/11/the_strange_s...
https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
Pulse is a winner from a UX standpoint, its "ok" from an admin/operational perspective but its not great. There was a while when some simple netconf commands would crash Pulse. I brought this up at a BAJUG meeting and the engineers there said "yeaaaah, don't use netconf".
AFAIK Pulse is still based on the old Neoteris codebase so who knows what else is still in there...
Just wanted to acknowledge how brilliant that is. They could have made any other code change, but it was genius using NSA's own backdoor.
NSA advocated for that backdoor to be included in the standards. The US government then would be embarrassed and would want to cover up any issues related to it, including the fact that it was taken over by someone else!
Gotta wonder what that Monday morning meeting was like at the NSA when they realized what had happened.
https://en.wikipedia.org/wiki/NOBUS
Although there is no real skills gap between target school graduates and non-targets, this observation also serves the dual purpose of undermining the NSA’s perceived omnipotence.
Changing the Dual_EC backdoor's public key in shipping products would NOT have been NOBUS.
I feel more like, there’s a chance that by modifying an intentional backdoor it could be that it would go unnoticed because anyone at the NSA looking at it may skip over reviewing closely the part of the code that has the known backdoor in it.
Steal the other guy's stuff is no longer brilliant, it's not even surprising. It shouldn't have been surprising to "brilliant" people advocating back doors back in the day.
It is much more plausible that US companies didn't want to name and shame their biggest customer than the Chinese reverse engineering a cryptographic backdoor. This could have been supported by the general NSA/GCHQ efforts to ensure their activies are mis-attributed.
The "it was China" determination was made by Mandiant, a company that receives over half its revenue from the US government (per the 2014 FireEye M&A call).
Heck, Microsoft (Longhorn), SecureWorks (Platinum Colony), and Google (GOSSIPGIRL) are the only US companies that have even publicly assigned names to track US linked APT groups.
I didn't understand this statement, but it's intrigued me. What are the names for and how do they lead to tracking US-linked APT (advanced, persistent threat a.k.a state sponsored) groups and who's doing the tracking?
CrowdStrike has a naming scheme that includes implied classes for specific countries of origin. For example you may have heard of "FANCY BEAR" which is part of the BEAR family but different from the "COZY BEAR" group. Everyone in the industry knows FANCY BEAR is the Russian GRU and COZY BEAR is Russian SVR, but by using the code names nobody has to come out and say it publicly (or face the consequences of being wrong).
The three companies I named are the only US based ones I know of that have publicly assigned named to US based threat actors. Kaspersky Antivirus (a Russian company) calls them the "Equation Group" due to their love of complex encryption, and the Hungarian government calls them "Tilded Team." If you ask Mandiant or CrowdStrike - they don't exist.
I don't think America can ever recover from this breach of trust. Maybe NSA just needs to be shut down entirely. Or at least redefined explicitly as an adversarial agency to everyone.
Yeah, like introducing the Clipper chip!
You'd also be crazy to trust anything made by American gear vendors. This is not the only instance of this, just one of the ones for which FVEY got caught.
Is non-US gear also compromised? Yeah, probably. But the PLA and the GRU can't physically confine you to an 8x8 steel cage on trumped-up charges predicated on the data they exfil from your network.
Your best bet is to buy gear from countries either not-friendly or actively hostile to the country you're in. Sure, you're probably pwned, but they're not sending a SWAT team in an MRAP to shoot your dog, either.
Actually they can, and with less legal recourse for you than in the US. It just depends on where in the world you happen to be when they decide they want you.
In any country, you'll end up in a steel cage regardless of whether you bought your computer or software from the KGB, NSA, or a homemade kit in a bazaar in Nicaragua made by a kid from Chile.
When the NSA designed DEC, they primed it with constants, that you'd need to know to break the encryption with low effort.
Somebody discovered that and made it known publicly.
So now before the rumors evolve into actual security engineers looking into it, the NSA creates a scapegoat APT, that "altered" some "code" at Juniper.
Of course nobody finds out, who those APT are, because attribution is 1% more accurate than astrology.
Too bad they're doing the opposite of that nowadays...
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
Whoever integrated this into their products after November 2007 is either incompetent or was bribed by the NSA.
Also, if anyone knows of a Soekris like alternative I'm all ears, what to do if my 6501 and my spare 6501 die.
Edit: this http://www.soekris.com/products/net6501-1.html
Is PC Engines acceptable as an alternative? E.g. https://www.pcengines.ch/apu4d4.htm
It does have limitations, e.g. only 1 GHz clock speed.
The bigger problem for all manufacturers is the chip shortage. E.g. most of PC Engines stuff is "expected ~ 2022". But there may be some stock at their distributors. https://www.pcengines.ch/newshop.php?c=4
Edit: if you dig deeper you may also find hardware you didn't expect. E.g. at some point OpenBSD was able to run on some Ubiquiti hardware. I don't know if Ubiquiti still make products that can run OpenBSD. https://www.openbsd.org/octeon.html
[0] https://pcengines.ch/apu2.htm
In my opinion, they jump to conclusion on insufficient circumstantial evidence. I have not forgotten the SuperMicro debacle.
In this article, they repeat the some jumping and aggrandizing on multiple fronts.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
[1] https://news.ycombinator.com/item?id=28404219
2. Tie up a commercial contract with this mode being made the default.
It’s just Apple CSAM all the way down.