Re: How U2F works

[NIIBE Yutaka]

NIIBE Yutaka  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.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[NIIBE Yutaka]

Werner Koch  wrote:
> Frankly, I don't really understand the use case for U2F?  Why not using
> plain user certificates which is supported by browser and servers for
> ages?  Is that because the web frameworks don't have good support for
> this?

Scalability, and some (or the) trust model which supports that.

The common practice for (X.509) user certificates is they are issued by
a specific network service provider, and it's useless for another
network service provider.  Users have to install each certificate issued
by each network service provider.  And this is not easy to manage such a
thing.

Ideally, we would have a good method to handle user certificates on
client machines, and have a practice using X.509 user certificates
by..., say, with "root CA"s.

OpenPGP community would say, it could be done reliably in a way of
distributed mechanism by OpenPGP certificates, right now.  Right,
technically, it's true.  The question is: How about in practice?

I think that user certificates (either, by X.509 or by OpenPGP) won't
work well than something like U2F.  I think that here, U2F offers a
"solution", in clever and practical way.


Well, let me explain from another angle.

I live in a small town.  In some cases, I buy things based on mutual
trust, directly or indirectly.  I use cash (or even credit card in some
specific cases), but shop owners are basically trust me.  We use money,
Japanese Yen.  But in a few cases, it is not needed in that form.  For
our own rice (most important food), I don't have to pay in the form of
money.  I live in such a town, intentionally.

I used to live in Tokyo for many years.  Shop onwers trust some credit
card service company and Japan Bank as an issuer of paper money.  They
don't necessarily care about me or anyone, who is buying their
products/services, as long as they can get paid.


Money scales.  Credit card scales.  That's because they don't require
direct mutual trust between a shop and a stranger who visits a shop.
All that shop owner needs is... to trust money.

That's my understanding.


I think that most important factor is not users, here (it is related,
though).

Using U2F might be easier for a network service provider, when other
network service providers have introduced such a feature in their
service already.  For an engineer or an administrator around web
services, it would be just "easy", like installing a few modules,
probably, while preparing X.509 user certificates requires complex and
difficult things.

>From an engineer who eats rice mainly. :-)
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[Gerd v. Egidy]

> Frankly, I don't really understand the use case for U2F?  Why not using
> plain user certificates which is supported by browser and servers for
> ages?  Is that because the web frameworks don't have good support for
> this?

I think this is because many people consider anything that is called a 
"certificate" complicated. Probably because in the past a lot of programs had 
poor or buggy support for it and they struggled with it.

So they came up with a new brand name and standard.

But I think they messed this up: when you want an attestated U2F device, there 
is no way to backup the private key or clone it to another U2F device. So 
whenever you sign up to a new service or website, you must have your primary 
and all backup U2F devices (each with it's own key) at hand to register them 
with the service.

To have them at hand means I can't store them at a second secure location like 
a bank safe. Because I won't go to my bank safe just to be able to order at a 
new online store. Completely unpractical unless you restrict the usage just to 
a handful of key services. Or it is right back to "what was the name of your 
first pet" :(

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[NdK]

Il 06/03/2017 16:10, Werner Koch ha scritto:

> An old argument against user certificates was the need to purchase a
> device or a certificates.  Now U2F requires that you purchase a device
> anyway, thus this would void that argument.
IIRC one of the selling points of U2F is that it should have been
"anonymous": an attacker that compromises multiple servers shouldn't be
able to determine if two users (on the two servers) are actually the
same person (or even if two users of the same site share a single token).

The only link would be the attestation certificate, but that should only
be checked during enrollment and not stored anywhere (once the user is
enrolled, the attestation cert is useless since only the site-specific
pubkey is needed).

With X509 (or GPG) certs the user's identity gets linked, for the joy of
nosy orgs.

@NIIBE : the sites don't send "proprietary JS" to the browser to access
the token (needed code is public) but the browser must support U2F API.
That's native in Chrome, but Firefox requires a plugin (and I don't know
what's the status of other browsers).

PS: it's not clear what happens when the attestation cert expires: does
the token become useless for enrollment?

PPS: the "attestation CA" could even be the GPG 'C' or 'S' key, that the
server could check via WoT. That does not require 'C' or 'S' key to be
on the token: the attestation certificate can be generated on an offline
machine.

BYtE,
 Diego.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[Werner Koch]

On Tue, 28 Feb 2017 01:28, gl...@rempe.us said:

> What though is the benefit of using gnupg key as the crypto behind the
> client auth? Seems like you are more exposed by having a portable gpg

It is up to the user where to store the key.  For obvious reasons the
user should use a token (e.g. gnuk or another OpenPGP smartcard, or one
of the other supported X.509 smartcards).

Frankly, I don't really understand the use case for U2F?  Why not using
plain user certificates which is supported by browser and servers for
ages?  Is that because the web frameworks don't have good support for
this?

An old argument against user certificates was the need to purchase a
device or a certificates.  Now U2F requires that you purchase a device
anyway, thus this would void that argument.

With OpenPGP a web service could ask for the user's public key during
enrollment and sign that key with their key.  The login procedure can
then send a challenge, verify it and check that the key has been signed
(OpenPGP key signature) by their key.  That would be a decentralized
system and only the enrollment needs to care about user data and such.
The user could use the very same key (toke) for other services as well
because other service providers can either add their own key signature
or thus the key signature of another service provider.

Well, backup is certainly an issue but one which can be solved - in
particular when the tokens are produced by the service provider.  The
OpenPGP card spec provides secure messaging and a few other feature,
which we once designed for a similar purpose: A service provider was
able to update the user's cards over the net (time-based travel cards).



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpCKgBeKQifj.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[NIIBE Yutaka]

Thomas Jarosch  wrote:
> regarding limited resources, the Yubikey people did a fine trick:
> There is no per-website data stored on the Yubikey. So the amount
> of websites you can use a single FIDO U2F key for is unlimited.
>
> See "Limited storage on device" for details:
> https://developers.yubico.com/U2F/Protocol_details/Key_generation.html
>
>
> Also I think the attestation key is not enforced by websites,
> so gnuk could just send a bogus / user configurable cert.

Thanks a lot for the information.


Well, I concluded that it is not worth (for me) to try to integrate U2F
feature into Gnuk.  If some free software friendly network service sites
ask me a possibility to use such a method to authenticate their users,
firstly I would propose better method which can respect users' computing
better instead, secondly I would propose developing as a separate
firmware implementation (possibly re-using Gnuk lower-level code) as
compromise.

The reason is:

The use cases are so different: The model who/how controls crypto
computation is so different.  (I mean, Gnuk vs. U2F)


I had been somewhat naive when I saw U2F specification at first.  I was
considering like:

  * While U2F uses X.509 certificate by the attestation key (in the
specification), it could be OpenPGP certificate.

  * Free Software implementation of U2F would be nice thing.

but, I leaned the reality.


In my opinion, the attestation key is a "key", literary and it is not
wise for network service providers not to check certificates (say, to
avoid MitM attack).

Here is my understanding.

I think that U2F offers network service providers a method of device
authentication and those who can trust the device vendor can use this
method to augment their user authentication.

Here is a picture, explaining the method.

[ Network service provider: A ]  --\ Trust
  ^|
  |  protocol for remote use of token  |
  vv
 [ User: U ]===having a token T1 by [ Device Vendor: D ]
  ^^
  |  protocol for remote use of token  |
  v|
[ Network service provider: B ]  --/ Trust

Note that U2F itself is not user authentication.  User authentication is
composed at network service provider side by traditional
username+passphrase AND the fact a user has the device (which can be
made sure by U2F device authentication).

In the design, the device is assumed to be shared among different
network service providers.

U2F is the protocol to offer remote crypto computation by network
service providers.

Users are... offering electric power to the device.  Users help network
service providers so that the U2F authentication can work effectively
(say, by providing their fingerprint).

In such a scheme, network service providers don't hesitate to send
nonfree JavaScript to their users, because the purpose is doing remote
use of the vendor's token (I don't say, it's user's token, even if
user is a "holder" is the token).
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[Thomas Jarosch]

On Tuesday, 28 February 2017 00:28:21 CET NIIBE Yutaka wrote:
> Anyhow, it would be possible for Gnuk to add U2F support (somehow
> limited, because of available resource on board).

regarding limited resources, the Yubikey people did a fine trick:
There is no per-website data stored on the Yubikey. So the amount
of websites you can use a single FIDO U2F key for is unlimited.

See "Limited storage on device" for details:
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html


Also I think the attestation key is not enforced by websites,
so gnuk could just send a bogus / user configurable cert.

Cheers,
Thomas


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[NIIBE Yutaka]

Hello,

Thanks a lot for your explanation.

Glenn Rempe  wrote:
> Well, the attestation key would be checked by the server side process
> right? And that is optional to check (but perhaps not optional to
> send). So you probably would need to ask those that are integrating
> U2F as a server auth method. Sending this seems to be a requirement
> based on the spec link you sent. Couldn't you get a vendor specific
> attestation key in any case for GnuK and use the same key across all
> devices?

I see.  I read the spec. again, IIUC, the generated keys in token will
be all signed by the attestation key.  I think that it is better for the
server side to check the signature so that it can detect possible MitM
attack.  I don't think it can be "optional" in real fields.

It would be possible to arrange a vendor attestation key of U2F for
Gnuk.  We did in a different level; We got USB vendor ID for our
devices.

However, with the OpenPGP background, I feel that it sounds wrong to
allow such an idea of a single secret shared among many devices.

If we do something like that (to assure authentication key generated
by a specific device), possible method for OpenPGP would be:

(1) Gnuk will have a feature of "device specific key".
(2) As initialization procedure, a distributor let a token generate
"device specific key" when they ship the device to a customer.  They
record the public key of each "device specific key" of customer.
(3) The distributor signs a public key of the "device specific key".
(4) When Gnuk generates authentication key, a signature by "device
specific key" is also generated.
(5) It is up to a user to use distributor's generated "device specific
key" and their signature.  A user can let a token generate new
"device specific key", and anyone can sign the public key of
"device specific key".
(6) Servers can check if an authentication key is signed by "device
specific key" which is signed by trustworthy distributor.

Well, probably, description above would be a different attestation key
for each device, in terms of U2F.

> I believe that at this point almost all use of U2F is through web
> browsers that support talking to the U2F hardware API's directly. Only
> Chrome has full support now, and Firefox and Opera are working on it
> but are not yet generally available. The web Javascript API's are just
> for requesting registration of a token or authentication. So you can't
> use U2F in a browser that does not have support for it no matter what
> JS you load in your page.

I see.  I was afraid that a user has to accept nonfree JavaScript
from server when she wants to use U2F authentication.

> What though is the benefit of using gnupg key as the crypto behind the
> client auth? Seems like you are more exposed by having a portable gpg
> key as opposed to a hardware embedded key. U2F makes it so easy to add
> a backup key, and most implementations let you drop and add keys
> pretty easily. Just trying to figure out if backing U2F with gpg, if
> that is what you are proposing, is worth it?

It is because of a simple reason.  I can't check the hardware and the
firmware in the current implementations of U2F devices.  I would like
to control my crypto computation in a way I can examine.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How U2F works

[Glenn Rempe]

Just chiming in here with some comments below. I am an active U2F user
and have played around with the server API's and read some of the
specs. Just to be clear, not an expert on U2F.

On 2/27/17 3:28 PM, NIIBE Yutaka wrote:
> Hello,
> 
> Let me ask a question about U2F.  Or, more generally, possibility
> to enhance GnuPG for web authentication.
> 

> Anyhow, it would be possible for Gnuk to add U2F support (somehow 
> limited, because of available resource on board).  Also, it would
> be possible for scdaemon (or other application) to emulate U2F
> protocol (just like Scute does emulate PKCS#11).
> 
> Well, I have two concerns for U2F.
> 
> (1) Atterstation key
> 
> In the document of U2F:
> 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine
>
>  It explains about Atterstation key.
> 
> If it were common for services to do this Atterstation key check,
> U2F emulation or free U2F implementation will be no real use with
> no private key of the vendor.   (It reminds me the old days when
> Apache couldn't serve https because no certificate authority issued
> certificate for servers with Apache.)  I wondor if Atterstation key
> check is common or not.

Well, the attestation key would be checked by the server side process
right? And that is optional to check (but perhaps not optional to
send). So you probably would need to ask those that are integrating
U2F as a server auth method. Sending this seems to be a requirement
based on the spec link you sent. Couldn't you get a vendor specific
attestation key in any case for GnuK and use the same key across all
devices?

Yubico describes something about the attestation metadata they use here:

https://developers.yubico.com/U2F/Attestation_and_Metadata/

> 
> 
> (2) JavaScript
> 
> It seems for me that there are special JavaScript(s) to offer
> access API to U2F.  I don't quite understand how it works to the
> physical device.
> 
> I don't like nonfree JavaScript which may interfere user' control.
> 
> Is it easy for free script (as in freedom) to integrate a script
> for U2F access?  Any such example scripts or any such services
> which do so?

I believe that at this point almost all use of U2F is through web
browsers that support talking to the U2F hardware API's directly. Only
Chrome has full support now, and Firefox and Opera are working on it
but are not yet generally available. The web Javascript API's are just
for requesting registration of a token or authentication. So you can't
use U2F in a browser that does not have support for it no matter what
JS you load in your page.

Browser support:

https://www.yubico.com/support/knowledge-base/categories/articles/browsers-support-u2f/

Yubico Demo Code and JS API

https://developers.yubico.com/U2F/Libraries/Using_a_library.html

JS Polyfill

https://github.com/mastahyeti/u2f-api

> 
> Here, my concern is that if it is all for proprietary world, I am 
> reluctant to consider seriously about U2F.

FIDO U2F is based on an openly published standard but only for you to
'read and analyze'. Seems like you have to become a member of the FIDO
alliance to be protected. Its not an Internet RFC.

"FIDO's specifications are public and available for anyone to read and
analyze. But only FIDO Alliance Members benefit from “the promise” to
not assert patent rights against other members’ implementations (see
the FIDO Alliance Membership Agreement for details). Anyone may join
the FIDO Alliance; we encourage even very small companies with a very
low cost to join at the entry level. Members at all levels not only
benefit from the mutual non-assert protection, but also participate
with FIDO Alliance members, activities and developments; Associates
have more limited participation benefits. All are invited to join the
FIDO Alliance and participate."

https://fidoalliance.org/faqs/

> 
> 
> And finally, if web authentication is important, I would like to
> use the infrastructure of GnuPG to manage my own crypto computation
> and my own private keys.  Currently, we can use GnuPG for SSH
> authentication by its ssh-agent emulation.  I would like to extend
> this.

Wouldn't making this work require the browser vendors to support some
kind of 'pluggable local auth' that gnupg would emulate, and not only
support for hardware tokens like Yubikey? I don't know if they support
this broader concept or not.

https://fidoalliance.org/specifications/overview/

What though is the benefit of using gnupg key as the crypto behind the
client auth? Seems like you are more exposed by having a portable gpg
key as opposed to a hardware embedded key. U2F makes it so easy to add
a backup key, and most implementations let you drop and add keys
pretty easily. Just trying to figure out if backing U2F with gpg, if
that is what you are proposing, is worth it?

> 
> Any thoughts?  Thanks in advance.
> 

Cheers.



signature.asc
Description: OpenPGP digital signature

How U2F works

[NIIBE Yutaka]

Hello,

Let me ask a question about U2F.  Or, more generally, possibility to
enhance GnuPG for web authentication.

While I maintain scdaemon of GnuPG and develop Gnuk (an OpenPGPcard
implementation), I sometimes am asked about U2F support, these days.
(I think that this is due to Yubikey.)

IIUC, major use case of U2F is web authentication.  It seems for me
that it doesn't fit directly to OpenPGPcard use case.

Anyhow, it would be possible for Gnuk to add U2F support (somehow
limited, because of available resource on board).  Also, it would be
possible for scdaemon (or other application) to emulate U2F protocol
(just like Scute does emulate PKCS#11).

Well, I have two concerns for U2F.

(1) Atterstation key

In the document of U2F:

https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine

It explains about Atterstation key.

If it were common for services to do this Atterstation key check, U2F
emulation or free U2F implementation will be no real use with no private
key of the vendor.   (It reminds me the old days when Apache couldn't
serve https because no certificate authority issued certificate for servers
with Apache.)  I wondor if Atterstation key check is common or not.


(2) JavaScript

It seems for me that there are special JavaScript(s) to offer access API
to U2F.  I don't quite understand how it works to the physical device.

I don't like nonfree JavaScript which may interfere user' control.

Is it easy for free script (as in freedom) to integrate a script for U2F
access?  Any such example scripts or any such services which do so?

Here, my concern is that if it is all for proprietary world, I am
reluctant to consider seriously about U2F.


And finally, if web authentication is important, I would like to use the
infrastructure of GnuPG to manage my own crypto computation and my own
private keys.  Currently, we can use GnuPG for SSH authentication by
its ssh-agent emulation.  I would like to extend this.

Any thoughts?  Thanks in advance.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users