Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Hardware backdoors in the actual CPUs ? (Score 1) 236

Ah, well, pattern matching in human communications is not really reliable. My apologies then.

The thing with your flip-flop idea is that it could work, but it requires extra hardware that could be found. As it is, they probably just need to laser-cut a single interconnect, preferably not even in in the top layer and preferably just silicon, not metal, to compromise the thing. That would be really hard to find. If they implement your idea, there would be said extra flip-flop, its reset logic and connection to the JTAG logic, etc. But you are making my point: Why are they claiming JTAG is a security issue, if it is not and they could hide a compromised generator even with it? The only explanation I find is that they want an absolutely minimal change to compromise the CPRNG and that compromising the JTAG hardware in the way you describe is already above what they are willing to accept in visibility/exposure. Also note that the compromised JTAG logic would be in the design (and hence many people would see it and all CPUs would have it), while what they likely can do now is not.

Comment Re:Cut off your nose to spite your face (Score 1) 86

It is basically a compromised design, i.e. a design that makes an implementation compromise intentionally hard or impossible to spot. That does not actually mean the implementation is necessarily compromised.

People have real trouble understanding the distinction or why this is a compelling reason not to use it.

Comment Re:Hardware backdoors in the actual CPUs ? (Score 1) 236

Stop spreading FUD. The architecture is designed to hide a compromised implementation, that makes it a compromised architecture, regardless of whether the implementation is actually secure or not. I never said anything about me not "trusting" the architecture either. I know it has been compromised, there is no need to "trust" or "distrust" anything. The question of "trust" does not apply.

You also do not understand JTAG or why it is important for them to have a minimal change they can make to compromise the implementation.

But I have run in people like you before. If you were a regular slashdotter, I would by now have insulted you enough for you to not be willing to talk to me anymore. Instead you are intent on keeping the conversation going. That behavior is however consistent with somebody working from a PsyOps manual. Keeping the conversation going is essential to be able to shape it.

Comment Re:Can they do OpenSSH too? (Score 1) 360

You did notice that "legacy" in the thing you quote? You can run OpenSSH with insecure settings or with protocol version 1.0. But if you use these you are supposed to look at the security trade-offs yourself. The thing is that it is not OpenSSH that is insecure here, it just allows you to shoot yourself in the foot after warning you.

Comment Re:Hardware backdoors in the actual CPUs ? (Score 3, Interesting) 236

You are either ignorant or a liar. (Maybe a paid-for liar?). Just read this: https://plus.google.com/+Theod...

That is a few more people than "nobody". The flaw is that the whole design does not allow verification that it is non-compromised. The claim that including its bits in JTAG would be a security risk is completely bogus, as an attacker with access to the JTAG pins can do whatever they like already. With those bits in JTAG, it would be relatively easy to verify the analog-side is actually analog and is actually what feeds the whitener. That possibility was intentionally sabotaged, and the _only_ good reason for that is that they want to be able to compromise the CPRNG in select batches and make detection of that very hard. And no, there is no software access to those JTAG pins and yes, the hardware to query the internal CPRNG state and analog bit stream must be in place to test the CPU. That means they are switching this access explicitly off after they have verified the hardware works. So not only is this a compromised architecture and design, it is also more effort than doing it right. IT does not get more obvious than this.

Your link, BTW, is worthless. It does not go into the needed level of detail. The contrast with what you get for the VIA C3 generator (e.g.), is quite telling: http://www.cryptography.com/pu.... And VIA has a non-compromised design as they do not desperately try to hide what the analog random source spits out.

Comment Re:What will be next: LibreSystemd? (Score 1, Interesting) 360

That one is easy: Just throw it away completely. Systemd is a major redesign of a major, critical Linux component.You would think that there is a very good, solid, compelling reason to do so. Apparently all they really have is "it boots faster". (And apparently id does not even do that in quite a few circumstances...)

My personal theory is that the NSA planned systemd as a project to sabotage Linux security (remember that Red Hat is primarily funded by the US military): Put an incompetent team with big egos in charge (Poettering and Sivers are certainly that), give them delusions of grandeur, make sure the BSD people ignore it by explicitly denying portability, and then just wait while the cretins produce a bloated, easy-to-exploit mess. (This "init-system" includes a freaking web-server! How stupid can you get?)

No need to place any backdoors, and all the countless vulnerabilities are genuine mistakes! Genius!

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Working...