In fact, any U2F operation (registration of a new key or authentication using an existing key) fails if there is a key plugged in that was once but is no longer registered with the site performing the operation.

Given that this issue is already present in Chrome M63 I suspect the issue lies not in the WebAuthN implementation, but the Chrome component extension. Kim, what do you think?

Yes, that's what I was thinking. I've passed this along to the security key clients team.

Thanks! Julia, if you get the chance, could you grab logs via the following?

1. Start Chrome with --show-component-extension-options
2. In chrome://extensions, enable developer mode and open the developer console for the background page of CryptoTokenExtension
3. Reproduce the bug
4. Copy the console log from the console and paste it to us

A log shared with me showed the following USB command and response:

>0000160183000700030000000000
<000016018300026E00

Parsing this by hand, we can see that this is an ISO 7816-4-formatted APDU with CLS = 00, INS = VERSION. The device is failing with 6e00, invalid class.

Earlier drafts of the U2F raw format specification specified that the version command was only 5 bytes long. This was at odds with the ISO 7816-4 specification, so the raw format spec was changed to say the version command should follow ISO 7816-4, with a note for backward compatibility with older, non-ISO 7816-4 compliant devices:
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html#informative-references

Unfortunately the code in Chrome that implemented this change only falls back when the error is 6700, wrong length:
https://cs.chromium.org/chromium/src/chrome/browser/resources/cryptotoken/gnubby-u2f.js?l=154
The code needs to be more permissive of errors in this situation, perhaps failing back in all circumstances (like crrev.com/31a5160).

arnarb, I'm not sure I can do that -- I'm on CrOS, and I don't see a day to set that flag.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69c2cec7961764edc76d0f467f30d4ed4557cd09

commit 69c2cec7961764edc76d0f467f30d4ed4557cd09
Author: Casey Piper <piperc@chromium.org>
Date: Thu Feb 01 01:25:18 2018

Fallback to legacy U2F GetVersion command when needed

Initial U2F specifications specified a U2F
version that was not compatible with ISO 7816-4.
As some authenticators require this older GetVersion
command, falling back to that initial command
upon failure with the current GetVersion command.

R=hongjunchoi@chromium.org, jdoerrie@chromium.org

Bug:  805778 
Change-Id: Id7f8a040aae323ba59c1d3c1418d8b5b8bb8953d
Reviewed-on: https://chromium-review.googlesource.com/894894
Commit-Queue: Casey Piper <piperc@chromium.org>
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Reviewed-by: Juan Lang <juanlang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533511}
[modify] https://crrev.com/69c2cec7961764edc76d0f467f30d4ed4557cd09/device/u2f/u2f_apdu_command.cc
[modify] https://crrev.com/69c2cec7961764edc76d0f467f30d4ed4557cd09/device/u2f/u2f_device.cc
[modify] https://crrev.com/69c2cec7961764edc76d0f467f30d4ed4557cd09/device/u2f/u2f_device.h
[modify] https://crrev.com/69c2cec7961764edc76d0f467f30d4ed4557cd09/device/u2f/u2f_hid_device_unittest.cc

The change referenced here addresses the webauthn implementation, which has the same issue, but this bug is actually in the cryptotoken component. Reopening, and I'll submit a fix for cryptotoken.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c741b732d5f0b959c18924363ca50c9e170eec3

commit 2c741b732d5f0b959c18924363ca50c9e170eec3
Author: Juan Lang <juanlang@google.com>
Date: Fri Feb 09 00:58:45 2018

Fall back to non-ISO 7816-4 version command on any failure.

Earlier versions of the FIDO U2F raw message specification used a
non-ISO 7816-4 compliant encoding of the version command on USB.
The spec was amended to require ISO 7816-4 encoding of this command,
even though devices were already available in the field that were
compliant with the earlier specification, and not with ISO 7816-4.
The updated specification recommends that client vendors fall back to
the non-ISO 7816-4-compliant encoding in the case of error:
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html#informative-references

Previously, cryptotoken was unnecessarily restrictive, and only fell
back when a device fails with the error code 6700 (wrong length).
Certain Yubico devices fail with other error codes, including 6e00
(wrong class), and do not work with cryptotoken as a result.

This change falls back to the earlier encoding on any not explicitly
handled failure, in order to be tolerant of a greater variety of
responses to the ISO 7816-4 encoding.

Bug:  805778 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I6a33016b4cb4a118351fcaf6aa00debb3ee19738
Reviewed-on: https://chromium-review.googlesource.com/899927
Reviewed-by: Adam Langley <agl@chromium.org>
Commit-Queue: Juan Lang <juanlang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535602}
[modify] https://crrev.com/2c741b732d5f0b959c18924363ca50c9e170eec3/chrome/browser/resources/cryptotoken/gnubby-u2f.js

I believe this fix should address the issue. If you can try with a nightly build to verify, that'd be great. If not, try getting yourself on the beta channel, and once you're running version 66, you should see whether the fix has been effective for you or not. Thanks!