Hi, since we are commenting here, I want to put out my two cents also, as this is a topic I'm deeply interested in.
Am 23.08.2016 um 11:17 schrieb Peter Lebbing: > I was quite surprised by this blog post, by one small but, in my > eyes, significant part of it. A lot of the blog post seems not > directly related to being able to review the source and verifying > that the loaded firmware binary is indeed the reviewed source, which > is what would interest me most in a security device. Yes, this is a problem, and to my knowledge there are no real solutions to it. Even with software alone its hard to verify that the binary you are running was indeed built from the correct source (i.e. reproducible builds), but with firmware and hardware devices it gets pretty much impossible. Open source is fine and dandy, but it doesn't solve this problem. And I'm saying this as a big open source enthusiast. > There's a lot of talk about field-updating firmware securely and > related topics, which is only tangential to the source being > /available/. Yes, you are absolutely right and I think the blog post is mixing things up here. Not making the source available has nothing to do with field-updatable firmware. > But the really strange statement is this: > > [...] > > A secure system is secure by having the knowledge of a secret key. > It is not secure because most people do not know how it works; > because the method is secret. This is Cryptography 101. If you want > to know more, I'd say just use your favourite search engine with the > phrase "security through obscurity". I'm playing a little bit of a devil's advocate here. In general I would agree with your statement. Security by obscurity is a bad idea. No one should come up with a new secret encryption standard and claim that it is secure. It has been shown time and again that these claims are mostly bullshit. These things should, as you said, be completely open, peer reviewd, pounded upon and only rely on a secret key. However for me this mostly applies to the cryptographic concepts itself and maybe software implementing them, not necessarily to physical devices that have to withstand various forms of physical attacks. When it comes to the real world, I'm not sure if this concepts holds completely true, though. If the revelations of Snowden taught us anything, than that it is hard to implement crypto correctly in the real world. Yes, RSA, AES and such are probably computationally secure enough, so that even the NSA cannot break it. However, they don't have to, because in the real world there are easier ways. For the most part, not attacking the crypto system itself is the weakness, but various side channels and other indirect vectors like that. I tend to think that hidden "traps" in a hardware design do actually improve security, and consider this to be kind of a defense-in-depth approach. We shouldn't rely too much on "secret sausage", but it definitely makes things harder for attackers when they do not know everything about a hardware design and have to reverse engineer it for themselves. This way key material can be wiped and hardware destroyed when tampering is detected. This costs them time and money, and hence reduces the potential revenue. I think a good analogy is the design of alarm systems and safes. Usually you won't find too much details about such things and they kind of rely on the fact that an attacker does not know too much about it. Obviously there are limits to this and I would like to be convinced otherwise, but in the end it always comes down to trust, e.g. in this case: Do you trust Yubico to have done everything that is reasonably possible to protect your keys. > Would you rather have a certification stating some > party thinks you're secure, or would you rather actually be secure? Once again I'm not sure if the real world is black-and-white like this. Just making something "open source" is not making it secure. Take the recent PRNG vulnerability in GnuPG as example (CVE-2016-6313). It was there for nearly two decades, and nobody spotted it. Obviously the same is true for all certifications and a hardware device is not secure, just because it is certified. Unfortunately these certifications (e.g. things like Common Criteria) are basically the only thing we have to make sure a product is designed with security in mind. It makes sure that there are clearly defined goals that can be met, tested and implemented. It makes sure that the people involved understand a thing or two about security and products tend to be better (i.e. more secure) with higher levels of certifications. Once again, I'm playing the devil's advocate here. I'm in no way, shape or form connected with Yubico and do not want to defend them, but I think arguments can be made for both sides here. Best regards, Karol Babioch
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users