Talking about Cryptodevices... which one?

[NIIBE Yutaka]

Hello,

Thanks to dkg for Cc-ing me explicitly, it helps me to catch this
message.

Perhaps, my answer would be a bit too technical for gnupg-users (and a
bit Zen-ish because of my background/culture), sorry in advance for
that.  It is not that I want to be unfriendly or unkind, but I
sincerely would like to share technical points and hopefully invite
more users and engineers to this field, and encourage its development.

On Thu 2015-01-22 22:25:46 -0500, Faramir wrote:
>       Well, some months ago I wanted to take a look at existing
> smartcards and/or readers that hopefully support both OpenPGP and x503
> certificates, but my Google-Fo failed me, I couldn't figure out where
> to buy something that works on Windows and can be shipped to Chile.
> Any advice? I'm not planning to buy "right now", but the first step is
> to know what to buy, where to buy, and how much does it cost.

Availability is one of important factors.  Good.  Furthermore, please
also consider other factors, when you put your own private key(s) onto
some device.  Imagine some cases where computing on the device is not
under your control, specifically, the possibility of honeypot device
to spy your private key and/or your crypto operations.

In my opinion, reproducible hardware product is a condition for such a
device, as well as a condition that whole firmware is Free Software
(not only glue code to access crypto engine).

Reproducible hardware product naturally would have good availability.
And I have expected that for my FST-01.  Unfortunately, our world is
not that simple, or it takes some time for the world to catch up.

			*	*	*

I don't think there is an existing product which matches your exact
need/expectation.  But, something similar are there, and it would
be some way to seek future possibility.

Here we go.

(a) OpenPGPcard compatible device

With those devices which conform to OpenPGPcard specification, it is
possible to offer its users following features, using GnuPG and
related tools.

   (1) OpenPGP support
   (2) SSH support thorough gpg-agent
   (3) X.509 support
       S/MIME
       SSL/TLS client certificate authentication

Because those devices are intended to be used for OpenPGP, OpenPGP
support is superior.

But the support for #3 is somehow experimental.  Honestly, I don't use
those features with my device, but just do experiments time to time.

For OpenPGPcard compatible, we can check existing (or existed)
"manufacturer" list in the source code, specifically, the function
get_manufacturer in gnupg/g10/card-util.c.


(b) (Ab)using other devices with GnuPG

GnuPG has support of some existing smartcard/token not designed for
OpenPGP.

With those devices, I guess that OpenPGP support would be secondary,
but X.509 support could be considered superior.

We can check the source code, gnupg/scd/app-*.c (other than openpgp)
for those support.  There are:

	DINSIG (DIN V 66291-1) card
	German Geldkarte
	Telesec NKS card
	pkcs#15 card
	SmartCard-HSM card

... but I think that most are outdated, except the last one.

And when you use those devices, you should know that each application
has tendency to grab smartcard/token access exclusively.  At least,
GnuPG assumes access to smartcard/token exclusively, and when it grabs
its access, you can't use the device from other application (of X.509).

On 01/24/2015 12:22 AM, Daniel Kahn Gillmor wrote:
> I don't know that it supports x.509 certificates explicitly right now,
> but the gnuk (running on the FST-01) has free firmware and is under
> active development.  gniibe (who i think is active on this list, but i'm
> cc'ing here anyway) is lead on development for that project.
[...]
> You can have a secret key that is associated with both an OpenPGP
> certificate and an X.509 certificate if you like.

Yes.

I don't use X.509 much.  I think that it's easily possible for us to
use gpgsm with scdaemon.  I maintain scute for Debian (not that
active, though) and its for SSL/TLS client certificate authentication.
I don't use scute daily, but I do some experiments occasionally.

> "Certificate support" is a bit of an odd question, because the cards
> specifically deal with secret key material, which isn't any sort of
> certificate at all -- the certificate is a wrapper around a public key
> that happens to be associated with the secret key.

Sometimes, people expect the device to have all.  I mean, not only
private keys, but also, public keys of higher layer.  In OpenPGP
public keys of higher layer = OpenPGP public keys (with signs), and
it's called "certificate" in X.509.

I'd understand such an expectation, which the device could be a sort
of portable ".gnupg".  But, existing technology is that mature, yet.


OpenPGPcard (and its compatible) usually doesn't have any public keys
of higher layer, because of its limited storage.

But, in the past, there was an experiment, to let have X.509
client certificate onto the OpenPGPcard v2.

We can find "CERT-3" data object in the souce code of
gnupg/scd/app-openpgp.c, and the functions like
do_readcert/do_writecert.  However, we don't use this data object at
all, by any GnuPG tools, any more.  The inted usage of this data
object was by scute for X.509 client certificate authentication (Thus,
the name CERT-3, "3" means authentication key in OpenPGPcard).
It seemed that poldi (PAM module with OpenPGP auth) also tried
to use it, but it's not now.

>From the viewpoint of firmware implementation, this data object is
difficult to support, because of its length.  Because of that,
Gnuk has configure time option --enable-certdo, which encourage
not to use this feature of certificate data object support.

Once in the past, I also thought that it would be good idea to have
support of non confidential data onto a device.  Thus, FST-01 has a
chip of serial ROM on the board, which size is 4MiB.  But the size is
marginal to store OpenPGP public keys.  And I haven't implemented any
code to access this particular chip yet.  I also though that it would
be good to put the text of GPL onto this serial ROM to conform GPL
itself, but I realized that it costs when I ask doing that in the
production process.

> the FST-01 is available for a little under $40 USD, depending on the
> physical form factor you want:
> 
>  http://www.seeedstudio.com/wiki/FST-01

It's design is free (as in freedom) to be reproducible.  When/if you
care some possibility of malicious/fake hardware, you can build it by
yourselves.  And it's encouraged.

Gnuk doesn't use any crypto accelerator, on purpose, but use general
purpose MCU.  In my theory, using general purpose small MCU would be
superior to avoid malicious/fake hardware features by semiconductor
vendor.  If it's very expensive hardware, specific for "crypto", there
would be more possibility, pressure from outside, or enough room of
silicon to have spy feature (and I don't have technology to check no
spy feature on hardware device).

Besides, Gnuk also supports board other than FST-01.  If it's
difficult for some country to import FST-01 or you like DIY
electronics, my article would help:

  Make Gnuk USB Token by STM8S Discovery Kit:
  http://www.fsij.org/gnuk/howto-make-gnuk-usb-token-by-stm32-part-of-stm8s-discovery-kit.html

Newest experimental version of Gnuk 1.1.4 doesn't support this
particular board officially because of its small flash size (of
64KiB), but, if you manually configure and limit its capability of key
algorithms, Gnuk can run on this board still.

Happy Hacking,
--