Can't register certain, older, Yubico U2F security keys |
||
Issue descriptionChrome Version: 63.0.3239.108 OS: all What steps will reproduce the problem? (1) Acquire *both* a 2014-vintage blue Yubico U2F Security Key, like [a], but from the original batch, and a Feitian ePass NFC FICO Security Key [b]. (2) Register the Feitian Security Key to your google account (sign up for 2 step verification, head to my account, signing in to google, 2-step verification, then add a security key.) (3) Attempt to register the blue Yubico U2F Security Key. What is the expected result? You can register it. What happens instead? The attempt to register immediately fails. The exact behavior depends on the Google login page, but as of this writing, the register pop-up immediately disappears, and a black "Something went wrong" pop-up appears in its place. The bug is, arguably, a bug in the original version of the blue Yubico token. It doesn't manifest in any you would buy today. The blue Yubico token responds to a sign request for a key handle of an unexpected length with an APDU response code outside the U2F specification: in particular, it returns the length of the key handle it received as a status code. cryptotoken treats this as a hard error, and the request is failed. Because the U2F spec is a little vague in this respect, and the U2F reference tests at the time permitted this behavior, the bug hasn't turned up until other vendors' devices became available. This is why registering the Feitian device is necessary to reproduce the bug: it generates key handles of a different length than Yubico's. Since the device is available in the wild, and is not updateable, updating Chrome to be more permissive seems like a reasonable course of action. References: a: https://www.yubico.com/product/fido-u2f-security-key/ b: https://www.amazon.com/Feitian-ePass-NFC-FIDO-Security/dp/B01M1R5LRD
,
Jan 8 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/31a51606bfc0797d7c0188678725331089bb7036 commit 31a51606bfc0797d7c0188678725331089bb7036 Author: Juan Lang <juanlang@google.com> Date: Mon Jan 08 19:08:45 2018 Be more permissive handling sign errors from U2F devices. Since the U2F spec is a little ambiguous about the proper behavior when a U2F device receives a sign request with a key handle it doesn't generate, device vendors are predictably a little creative in how they behave. Hard failing when a user has devices from different vendors is a little unfriendly to users, especially since these devices are intended not to be field-updateable. This change treats most errors as "permissible", allowing all of a user's key handles to be attempted before failing a request. BUG= 799279 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: Id248317b43d5812c92d1b3f3c5713e518bb5b62f Reviewed-on: https://chromium-review.googlesource.com/852516 Commit-Queue: Juan Lang <juanlang@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Cr-Commit-Position: refs/heads/master@{#527695} [modify] https://crrev.com/31a51606bfc0797d7c0188678725331089bb7036/chrome/browser/resources/cryptotoken/manifest.json [modify] https://crrev.com/31a51606bfc0797d7c0188678725331089bb7036/chrome/browser/resources/cryptotoken/singlesigner.js
,
Jan 9 2018
On Chrome nightlies, successful registration of blue key on Dropbox, Github, Google on an account that already has a Feitian. These are all the cases that were failing (actually not sure whether Dropbox ever failed because they seem to have other outstanding bugs, but I was able to register or at least re-register it).
,
Jan 9 2018
Cool, thanks for verifying, Mike! |
||
►
Sign in to add a comment |
||
Comment 1 by juanlang@chromium.org
, Jan 8 2018I'm attaching the contents of the Google-internal app, gnubbyd, during a debugging session. It shares a lot of the code with cryptotoken, so the logs are instructive. We diagnosed the Yubico device further, and discovered that, when it receives a sign command for a key handle of an unexpected size, it returns an APDU response with the length of the key handle as the status code. (Fail.) Some examples you can recreate with cryptotoken: var a = s.digest('a') var c = s.digest('c') var g = new Gnubby() g.open() g.sign(a, c, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], function(rc) { console.log(rc); }); hidgnubbydevice.js:412 0103 09:24:15.975000: >010000038300540002030000004B6E340B9CFFB37A989CA544E6BB780A2C78901D3FB33738768511A30617AFA01D6E340B9CFFB37A989CA544E6BB780A2C7890 hidgnubbydevice.js:412 0103 09:24:15.981000: >01000003001D3FB33738768511A30617AFA01D0A0001020304050607080900000000000000000000000000000000000000000000000000000000000000000000 hidgnubbydevice.js:220 0103 09:24:15.996000: <01000003830002000A00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 gnubby.js:854 0103 09:24:15.998000: apduReply_ fail: a See that? 10 byte key handle, reponse value is 10. Here's a 20-byte key handle: g.sign(a, c, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9], function(rc) { console.log(rc); }); hidgnubbydevice.js:412 0103 09:24:26.134000: >0100000383005E000203000000556E340B9CFFB37A989CA544E6BB780A2C78901D3FB33738768511A30617AFA01D6E340B9CFFB37A989CA544E6BB780A2C7890 undefined hidgnubbydevice.js:412 0103 09:24:26.145000: >01000003001D3FB33738768511A30617AFA01D140001020304050607080900010203040506070809000000000000000000000000000000000000000000000000 hidgnubbydevice.js:220 0103 09:24:26.164000: <01000003830002001400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 gnubby.js:854 0103 09:24:26.167000: apduReply_ fail: 14 Sure enough, the APDU response is 20. 30-byte key handle: g.sign(a, c, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9], function(rc) { console.log(rc); }); hidgnubbydevice.js:412 0103 09:24:31.326000: >010000038300680002030000005F6E340B9CFFB37A989CA544E6BB780A2C78901D3FB33738768511A30617AFA01D6E340B9CFFB37A989CA544E6BB780A2C7890 undefined hidgnubbydevice.js:412 0103 09:24:31.331000: >01000003001D3FB33738768511A30617AFA01D1E0001020304050607080900010203040506070809000102030405060708090000000000000000000000000000 hidgnubbydevice.js:220 0103 09:24:31.348000: <01000003830002001E00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 gnubby.js:854 0103 09:24:31.350000: apduReply_ fail: 1e As predicted, APDU status is 30.3.4 KB
3.4 KB View Download