Talking about Cryptodevices... which one?

[Matthias-Christian Ott]

On 2015-02-03 20:43, Werner Koch wrote:
> On Sun, 25 Jan 2015 17:31, ott at mirix.org said:
> 
>> I don't think that such discussion belongs on this mailing list but I
> 
> I think such a discussion is important and belongs here.  I see no

If I remember correctly, that statement refers to speculations about
backdoors that were speculated to be implanted or exploited by
intelligence agencies.

You speculated that Rainer SCT might cooperate with the German
intelligence agency BND. You gave the following reason for your
suspicion: "microcontrollers are smaller and writing malware for them is
harder". You know much better than me that just because a
microcontroller is smaller it doesn't mean that it is hard to exploit it
by uploading modified firmware. In fact the scenario you mentioned,
saving the PIN, could probably be implemented with just a few hundred
additional instructions. Moreover, Rainer SCT is not the only German
vendor that has firmware that can be updated: SCM PC-Card also allows
the firmware of its SPR532 card reader to be updated from the USB host.
You construct the same story for SCM PC-Card and more broadly any other
proprietary hardware or software. There are enough examples of vendors
that introduced government backdoors in their proprietary products to
come to the conclusion that it is probably not a good idea to use
proprietary software or hardware if your threat model includes
government backdoors and you want to defend against them (of course that
doesn't mean that it is impossible to verify that a proprietary product
does not contain a backdoor but it is unarguably a lot harder). So I
don't know how speculating that a particular vendor of proprietary
hardware and software implants backdoors in its products does move the
discussion forward.

> reason to discuss the need for 8k or even 4k keys if we neglect to
> discuss hardware or malware based attacks.  In fact the immediate need
> for very large keys is mostly an academic exercise while the latter are
> real threats.

I mostly agree with you here and I think what has been revealed over the
last years confirms your statement. But will a smartcard solve the
problem that the host computer might be infected with malware? I don't
think so but invite you to proof me wrong. I think that sandboxing
mechanisms like SELinux, AppArmor, grsecurity, seccomp etc. would help
more to not let the computer become infected in the first place. I would
like to give the following example to prove/illustrate this:

Suppose that your web browser has an exploitable security vulnerability,
you visit a website that manages to execute code on your computer and
that code wants to steal your OpenPGP key. If you would run SELinux and
properly label the .gnupg folder in your home directory and your
system's GnuPG binaries, you could have prevented this attack. Without
SELinux but with a smartcard the exploit code could have controlled the
smartcard even though it might not have the smartcard's PIN and the
attacker would probably be able to do something with the key on the card
next time you want to use it. Moreover, SELinux is just a piece of
software that costs nothing and could be rolled out to millions of
computers over night whereas the smartcard costs money and requires no
additional knowledge (see for example Fedora's default SELinux policy),
whereas equipping and educating millions of users with an OpenPGP
smartcard and a reader is not trivial and inexpensive.

There is probably a lot more to say and to consider about this whole
topic and this topic is most likely also beyond the scope of GnuPG but I
think one can look at the enterprise software market as a good example
that shows why adding hardware to an existing insecure system is not
really effective. At least as far as I know running software like IDS,
DPI firewalls, transparent/intercepting proxies, anti-virus software and
so on does not solve the problem of Microsoft Windows or application
software running on Microsoft Windows being insecure.

Regards,
Matthias-Christian