How U2F works

NIIBE Yutaka gniibe at fsij.org
Fri Mar 31 09:21:44 CEST 2017


NIIBE Yutaka <gniibe at fsij.org> wrote:
> Well, I concluded that it is not worth (for me) to try to integrate U2F
> feature into Gnuk.

While I am open to discussion, my current position is that it is better
for Gnuk not to integrate the U2F feature.  I'd rather prefer separate
implementation of U2F, if needed, possibly reusing code of Gnuk (crypto,
USB, etc.).  I mean, by separate device.

My reasons are:

* The nature of two use case (OpenPGP private key vs. authentication for
  network service providers) are quite different.  Generally, Gnuk users
  don't want to allow other new additional attack vectors, because of
  adding "new feature" (and U2F would come with them).  OpenPGP private
  key is so important for Gnuk users.  U2F key is just a thing to enter
  web service which is owned by a device vendor.  For me, it is not wise
  to invite possible attacks just for some usefulness of
  not-so-important thing.

* Resource on physical board is quite limited (20KB RAM and 128KB ROM).
  For code space, we will need some features of Gnuk if we integrate
  U2F or other features.

* Unfortunately, currently, both of Gnuk and U2F uses same protocol of
  USB CCID.  In a host system, it is the practice of CCID on host side
  to access the device exclusively to mitigate some attacks (changing
  while using).  For example, GnuPG's scdaemon requires exclusive access
  to Gnuk Token.  I think it is also same or similar to browser access
  to U2F device.  I think that a single CCID device can't serve two
  different programs on host simultaneously.

Well, we can manage and consider possible solutions for the latter two
technical problems.  The first problem is most important, I suppose.

Keep adding things, it will become a system like host system,
eventually.  The purpose to separate out the management of OpenPGP
private key to a dedicated device is: make it simple and easier to
achieve better security.
-- 



More information about the Gnupg-users mailing list