Hello,
Thanks a lot for your explanation.
Glenn Rempe <gl...@rempe.us> 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
