OpenPGP Smartcard recommendations

[Karol Babioch]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160823/69866d2a/attachment.sig>