4 ms·
"The only solution is to read source code and look for anything suspicious. Linus's Law states that "given enough eyeballs, all bugs are shallow": If enough peo
by alan_cx 13y ago
"The only solution is to read source code and look for anything suspicious. Linus's Law states that "given enough eyeballs, all bugs are shallow": If enough people read source code, we will find the bugs — including any which the NSA was hoping to exploit in order to spy on us. "
I understand the point about software, but what about hardware? If the NSA is corrupting software, then it must be corrupting chips too. How can chips be verified NSA spy free?
- privong 13y agoI understand the point about software, but what about hardware? If the NSA is corrupting software, then it must be corrupting chips too. How can chips be verified NSA spy free? In principle, an analagous "Linus's Law" exists for open-sourced hardware. So if you have the code/design for chips, that could be verified as well.
- solarexplorer 13y agoAnd how do you verify that the design was not modified before the chip went into production?
- Fargren 13y agoSimilarly, how do you know your compiler didn't add a backdoor to your software? Even if you compiled your own compiler, you don't know if the software you used for that is safe. Unless you trust your hardware and you bootstrapped your compiler, I don't think you can truly trust software.
- mbq 13y agoSome strong solvent and a microscope? =)
- sliverstorm 13y agoA regular microscope? Maybe if you want to manufacture in a twenty year old process. Visible light only goes down to ~400nm, so no matter the magnification your eyes will not be able to see minimum size features on anything made since 1994 (600nm) or so.
- mbq 13y agoOh no, SEM.
- sliverstorm 13y agoBut can you trust a SEM? ;)
- privong 13y agoOne option (if you have a trusted FPGA) is to run something from opencores.org, where you can verify the code. But more generally, yes there is an issue of having an initial base system which can be trusted to some degree.
- sliverstorm 13y agoSo, basically, design your own chip on paper (because you can't trust the CAD tools or the compiler that made the CAD tools), build your own fab and make your chip at home, build your own computer, write your own compiler, write your own operating system... Yeah, this'll be good.
- mpyne 13y agoAnd also, while you're doing all that, don't leave in any exploitable breaks. Don't accidentally hardware RANDU as your PRNG, for instance.
- kens 13y agoI've been reverse-engineering old microprocessors lately (e.g. Z-80), and I've been thinking about this question. For chips of that era, you can actually look at the silicon, examine what it does, and be pretty confident that there's no back door. (Although interestingly the Z-80 is said to have a few "traps" to prevent copying, where due to silicon doping tricks the circuit doesn't do what it looks like visually. But scanning capacitance microscopy would catch this.) But for a modern microprocessor, it's impractical to reverse-engineer the chip at this level. One solution would be the manufacturer could publish the full plans and circuitry for the chip, which would make it easier to see if everything looks okay in the circuit, and then you could verify that what's on the chip matches the plans. For instance, if Intel published the circuitry for their digital random number generator, you could look at the circuitry, look at the chip, and be pretty confident that everything is okay. (Note that this could be published without being open-sourced. In a perfect world, patents would include all this information.) The problem is for chips that have microcode that can be updated, knowing the chip itself is "correct" doesn't help you, since the microcode could be malicious. Even if the random number generator is valid, the microcode could modify the values before you get them. My conclusion is that even if your chip is 100% validated, it doesn't help you at all if you don't know what's in the microcode. (This all depends on what kind of attack is being put into the chip, of course. I wouldn't notice any side-channel attacks built into the Z-80 such as timing-based attacks or power consumption. You could probably sneak in something super-obscure like the carry flag not getting cleared in some corner case and make it non-obvious, but that would be pretty hard to exploit.)
- oroup 13y agoOf course the path from Verilog to working hardware involves a number of steps along the way. You don't really know that your hardware design has made it into silicon intact and that nothing else has been added. [1] [1] https://www.schneier.com/blog/archives/2012/05/backdoor_found.html https://www.schneier.com/blog/archives/2012/05/backdoor_foun...