search

trussed-dev / fido-authenticator

FIDO authenticator Trussed app
Apache License 2.0
36 stars 10 forks source link

Existing credentials no longer working after updating to 2:20220822.0 (2.964.0) #19

Closed TimWolla closed 2 years ago

TimWolla commented 2 years ago

After updating my Solo2 to firmware 2:20220822.0 (2.964.0) any existing FIDO 2 credentials are no longer working. e.g. when attempting to sign into GitHub (with Firefox on Linux), Firefox reports back InvalidStateError during authentication (which indicates an unknown key to the best of my knowledge).

TimWolla commented 2 years ago

And yes, I noticed the warning during the upgrade:

Warning: This is is major update and it could risk breaking any current credentials on your key.

The release notes however do not note explicitly that existing credentials will stop working.

conorpp commented 2 years ago

Thanks, will add to the release notes. You'll need to re-register your key that you updated.

TimWolla commented 2 years ago

@conorpp Thank you for the feedback. Just to confirm:

You'll need to re-register your key that you updated.

Does this mean that this comment in the source code is not accurate:

https://github.com/solokeys/fido-authenticator/blob/d3e17537eb854d2c72e42968ef62e61cd2d6e0da/src/credential.rs#L231

Or am I looking in the wrong place and that file does apply to something else?

burtek commented 2 years ago

@TimWolla I guess this is only for the device-stored keys. Most auth flows will use dynamically generated keys that are not stored on the key but can be re-created on demand given the same set of data every time. In this case those won't work, because the generation algorithm was changed.

TimWolla commented 2 years ago

I guess this is only for the device-stored keys.

The beginning of the comment appears to disagree:

https://github.com/solokeys/fido-authenticator/blob/d3e17537eb854d2c72e42968ef62e61cd2d6e0da/src/credential.rs#L221-L222

Most auth flows will use dynamically generated keys that are not stored on the key but can be re-created on demand given the same set of data every time.

Indeed. And the comment implies that the keyhandle for the Solo2 is an encrypted serialized blob. So it's not so much a generation algorithm, but deserialization instead. My understanding is that it was planned that deserialization simply ignores the extra fields that were included in the previous version based on the comment in line 231.