Hacker News Reader

Comment by neilv | Hacker News Reader

I applaud moving away from UEFI, to something simpler and more transparent, and something not hostile from the start to open source.

I like how relatively simple my Coreboot systems are. The sooner that Coreboot can minimally initialize hardware and invoke an open source bootloader or Linux kernel payload directly, the better. (Bonus, if the kernel doesn't need legacy PC BIOS services.)

Regarding concerns raised in the article, I'd be more suspicious of closed microcode and firmware blob parts, than of open source parts. Many knowledgeable eyes on the open parts can help. Though, of course, open parts could, in theory, be crafted to provide affordances for naughtiness involving closed parts. I have mixed feelings about recent initiatives to push closed updates more widely and reliably, and look forward to more-open hardware.

View on HN

I still think it's problematic, since it is in the vital interest of the NSA, and one of its core missions, to be able to penetrate endpoint security at that level. If they contribute to Coreboot, then that means either that they want to compromise the project or that their "tailored access" group already has enough other ways of comfortably breaking the security of any PC at a level that is low enough (to evade all user-level software, anti-virus vendors, etc.). Both possibilities are bad for international users, even if the second one is obviously more preferable.

It makes no sense for the NSA to assist making PCs secure for non-military use and for use by non-US citizens against their own attacks, because it contradicts their mission statements. The only other (not totally implausible) explanation is that different departments within the NSA are so disconnected from each other that they have started to work against each other.

You can’t really avoid it anyway. How do you know a contributor isn’t secretly working for the NSA (or a foreign equivalent). The only way to prevent backdoors is to inspect the code and keep it small and simple.

vital interest of the NSA, and one of its core missions, to be able to penetrate endpoint security

It's also a core mission of the NSA to protect US networks from attack. If they're inserting backdoors in products used by US businesses, they're directly undermining their core mission.

> If they're inserting backdoors in products used by US businesses, they're directly undermining their core mission.

Which is not unheard of.

You mean like the NIST ECC curves backdoored by the NSA?

https://www.miracl.com/press/backdoors-in-nist-elliptic-curv...

What about PRISM? Protecting US networks is clearly not a part of their mission.

Do you even understand what PRISM was?

I'm sure they have a much better system in place by now.

Please don't post like this—it breaks the site guidelines.

If you know more, the best thing is to share some of what you know, so the rest of us can learn. A lot of people read these threads who are curious and open to good information.

https://news.ycombinator.com/newsguidelines.html

More info to better conform to the guidelines.

OP, your insinuation is that PRISM weakened US networks, but that is a misunderstanding of what the program actually did. Wikipedia:

>The actual collection process is done by the Data Intercept Technology Unit (DITU) of the FBI, which on behalf of the NSA sends the selectors to the US Internet service providers, which were previously served with a Section 702 Directive. Under this directive, the provider is legally obliged to hand over (to DITU) all communications to or from the selectors provided by the government.[38] DITU then sends these communications to NSA, where they are stored in various databases, depending on their type.

I personally think it's important to understand what types of surveillance our government is doing and not listen to FUD on what people think they are doing. In this case, there's no weakening of a network. The FBI provides a selector (email) to the service provider, and the provider uses their own systems to retrieve the data and send it back. The "direct line" that many people reference is to the database of selectors, so that FBI can push it directly to the provider.

The NSA absolutely does have two, somewhat contradictory, missions; they're tasked with both offense and defense. One is "spying", or more formally "signals intelligence" a.k.a. SIGINT; the other is indeed "network defense". Until fairly recently it was in essence two organizations loosely joined administratively. You can read some more here: https://www.schneier.com/blog/archives/2016/02/nsa_reorganiz...

That's a myth or some weaker form of legislation. Their mandate is to secure, esp for COMSEC, defense organizations. They usually have contractors build the tech for that, esp Type 1. Non-defense cant buy it. They also publish hardening guides for all sorts of tech. Anyone can use those since almost all of those techs are insecure.

So, NSA has a massive mandate for stopping another 9/11 with surveillance but restricted one on defensive side mainly about securing defense organizations. That group recently downgraded its standards with Commercial Solutions for Classified or whatever it is.

The NSA is not in charge of setting up and maintaining critical computer systems for US national security.

Contractors do that, according to DOD or DOE guidelines, which in turn means that these systems might end up using BIOS, coreboot, or something else.

The NSA itself might be using some of these systems, so its in their interest to make them secure.

Does the same argument apply to SELinux? That the NSA can already compromise any version of the Linux kernel, or alternatively that the NSA has been fighting itself since the year 2000?

Does the NSA's endorsement of AES over 3DES mean that the NSA has had a backdoor in AES for decades? Does it make no sense to include actually-secure algorithms in Suite B?

> Does the same argument apply to SELinux? That the NSA can already compromise any version of the Linux kernel, or alternatively that the NSA has been fighting itself since the year 2000?

Definitely. As far as I can see (public civilian sources only), the NSA's Tailored Access division can compromise any off-the-shelf PC. Or at least, given that we know that they've had the ability to install persistent viruses in the firmware of consumer hard drives 10+ years ago, it seems plausible to assume that standard PC hardware is not secure against targeted attacks.

> Does the NSA's endorsement of AES over 3DES mean that the NSA has had a backdoor in AES for decades? Does it make no sense to include actually-secure algorithms in Suite B?

Of course not. That would be a silly assumption, since we know from the Snowden revelations that the NSA is primarily targeting endpoint security. They might be able to break certain implementations of stream ciphers or maybe even have working (algebraic?) attacks against certain block ciphers - they seem to build and use a lot of ASICs, presumably not just for cryptocoin mining -, but even if these attacks exist, it would be very speculative to assume that they are used routinely.

If I wanted to break into any Linux system, I'd first create a Trojan horse and ask the administrator to kindly install it. If that didn't work, I might compromise the router and hijack the system update mechanism (maybe using stolen certificates). If that didn't work, I'd become a package maintainer or major contributor and sneak in some backdoors obfuscated as programming errors. Or I could intercept the hardware and install my own firmware on the machines. And so on and so forth. Heck, even civilian companies overtly advertise that they can break into any computer, so why should the NSA not be capable of doing it?

No need to break cryptography if endpoints are insecure.

I can do all these things myself - compromise any standard off-the-shelf PC given physical access, add persistent viruses to the firmware of consumer hard drives given physical access, trick a sysadmin into installing something, become a package maintainer and add some backdoors, etc.

So I don't think any of what you've said says anything about the NSA's capabilities, and it certainly does not let us conclude that UEFI is compromised in some way beyond being typically installed on firmware that's not hardened against physical attack (which is also true of Coreboot, traditional BIOSes, and everything else).

I think the parent comment was attempting to address the NSA's _willingness_ to carry out these kind of actions, not their capability to. There is documented evidence (in fact, this article mentions some known incidents) of the NSA _actually_ doing these things. That's what's different between any rogue, ethos-less malicious actor and them.

Actually, part of the NSA's mission statement is to secure things.

It's just that that part of the mission has taken a back seat to the offensive, tailored access parts for the past few decades; particularly after 9/11.

I remember reading somewhere a couple years ago that this was actually a bit of a point of consternation amongst the leadership back when Snowden leaked PRISM. My memory fails me however at remembering the exact article...

Gah.

Perfect comment. Thank you.

Basically at this point, (((which we have been talking abt for literally decades [nobody ever even believed Echelon existed, six-degrees, PRISM, Stuxnet, Duqu, etc.... -- and this doesnt even take into consideration FB, GOOG, ATT, CARNIVORE, etc etc etc WHERE THE FUCK IS PALANTIR on HN???]))) one must accept that no matter what if you have a machine, They have you.

If you have a machine connected to internet, they have you.

NSA also interested in security of their hardware/software, it's logical move.

> The only other (not totally implausible) explanation is that different departments within the NSA are so disconnected from each other that they have started to work against each other.

Not at all implausible; this was literally, and very deliberately, the case. There was offense -- SIGINT -- and there was defense -- the Information Assurance Directorate -- operating largely independently. Here's [the previous director, Mike Rogers, on the division][0]:

> This traditional approach we have where we created these two cylinders of excellence and then built walls of granite between them

As you can read in that article, though, the two halves were merged a few years ago in a reorg.

[0]:http://fortune.com/2016/02/03/nsa-reorg-combine-offense-defe...

>> Many knowledgeable eyes on the open parts can help

Well, that is the problem. No one (well, say very very few) do code reviews on their own -- they do not provide as much benefits as coding (learning and reputation wise). Its a bit like the problem in academic publishing: Replication trials are not prestigious enough, so they are done far to rarely, albeit they are very important.

There are companies out there, that will do it for money, and many great open source products have been reviewed that way. But I don't think this happens often enough.

While that's a valid concern, the real question should be: despite that, is it more trustworthy than closed source or not?

>...they do not provide as much benefits as coding (learning and reputation wise).

I think that's because code reviews have changed from being helpful form of preventing you from stubbing yourself on your toe to, "Why would you do this...? No0b..." kind of format.

If code reviews were weighted as equally beneficial to the code and as being approached as being beneficial to the growth of the developer making the change, then I could see it having much more benefit in learning; however, that would take a dynamic change in the general culture.

...but saying that code reviews don't provide as much learning benefit is to just infer that there's nothing that can be done about that when, in fact, there is. :)

I suspect that code openly contributed by the NSA will get quite a lot of scrutiny - more than average code contributions. For that reason, if they wanted to subvert something like this, I doubt they'd advertise the source of the contributions like this.

LOTS of security companies do code reviews and constantly looking for security holes in OSS, it is after all a huge feather in their cap and reputation boost to find holes and earn the big $$. Imagine if they were able to find a deliberate hole in NSA provided UEFI code.

> I applaud moving away from UEFI, to something simpler and more transparent, and something not hostile from the start to open source.

Coreboot is not an alternative to UEFI. You can make TianoCore builds that use Coreboot, even!

Reply on news.ycombinator.com