2:20220822.0: Fix credential length and NFC issues

[nickray]

Central location to gather questions about this release.

Gem from Reddit: "The biggest change seems to be that the LED now subtly pulses... so solo2 has gone disco?!"

Please note:

• customer service problems like "key seems broken" (or anything else if you feel you're not being heard on GitHub) should be directed to support@solokeys.com
• higher-level questions about using the device should go into a discussion in this repository
• technical bug reports should go into issues of the corresponding library

---

This discussion was created from the release 2:20220822.0: Fix credential length and NFC issues.

[TimWolla]

Hi! Can you please confirm or deny that any existing WebAuthn credentials are definitely broken and will not be fixable, even with another firmware update?

My follow-up question in trussed-dev/fido-authenticator#19 (comment) unfortunately did not receive a reply so far.

[nickray]

Yes, they don't decode anymore (both discoverable/resident and U2F-style server-side stored). Sorry! Not out of the question that someone else supplies an elegant patch, but I recommend biting the bullet on this one, as the old credentials really are "too long".

[TimWolla]

as the old credentials really are "too long".

Well, any service where I've successfully registered my Solo2 certainly accepted the length of the credential, so it shouldn't be too long for that specific service.

but I recommend biting the bullet on this one

The biggest issue with that is that I didn't really keep track of the services where I've already registered my Solo2. And one of the purposes of WebAuthn is improved user experience, so I am not sure if users can be expected to keep track of that. Even when I lose my physical key, an attacker would not know whom it belongs and they would also need my password in the first place.

So if I forget one the services when cycling the Solo2, then the broken credential will linger forever in my account and I can never be sure whether all listed credentials are actually usable to gain access to my account. At least I took great care to always store the backup keys and to also register my YubiKeys, so I'm not completely locked out.

[nickray]

Yeah, there are unfortunately a LOT of rough edges to the WebAuthn experience. And the "passkeys" initiative is focussed towards better support for hardware/software conglomerates like Apple, Google and Microsoft. Maybe in the future we'll find a good approach at least for discoverable/resident keys, using the Trussed identity keys to sync among Solo 2 devices. For U2F-style server-stored I'm at a loss on how to approach backups ergonomically, as the device doesn't really know anything. Perhaps one could still store metadata for such credentials, with the downside that storage is no longer infinite.

If a relying party is well implemented, you can tag credentials on their side with a name for the device, and then remove it later (this is what WebAuthn expects you to do upon loss). If the key is wiped, at least from a security standpoint there's no issue with letting it linger though.

[TimWolla]

For U2F-style server-stored I'm at a loss on how to approach backups ergonomically, as the device doesn't really know anything.

Perhaps I wasn't entirely clear. I don't expect being able to backup existing credentials. I just expect the credentials to continue working unless I physically break my key. I'm also thinking about users that are less technically experienced here, it's not a good outlook if an update breaks stuff, because they commonly tend to be wary of updates anyway. I've already recommended by non-programmer SO to not upgrade her key yet, because I was hoping that existing credentials could be made functional again, as the source code comment indicates that this was at the very planned planned to work: https://github.com/solokeys/fido-authenticator/blob/d3e17537eb854d2c72e42968ef62e61cd2d6e0da/src/credential.rs#L231

My understanding is that the fix for the key handle length is "do not encode useless data in the encrypted blob". Wouldn't the following then work for non-resident keys:

1. Attempt to decode the key handle with the new algorithm.
2. If that fails: Attempt to decode the key handle with the old algorithm.

Sure, that would require you to carry the legacy code around in the future, but at least the user will not be presented with an "unrecognized key", despite them knowing that they registered that key perfectly fine.

If a relying party is well implemented, you can tag credentials on their side with a name for the device, and then remove it later (this is what WebAuthn expects you to do upon loss).

Yeah, I likely need to call the newly registered variant "Solo2 Post Reset" then. Not great, but at least then it's explicit in the list of keys :-/. I didn't cycle them yet, because I'm still hoping that this isn't necessary after all with another update and because I also have working YubiKeys.

[senz]

I simply dont understand why do I need to update with this breaking change? You didnt sell the necessity, on my side. Please continue to backport patches to 1.x. I will use this branch, since I dont want the hussle. At this point, its like moving to another hardware provider- PITA

[kravietz]

Trying to update recently purchased Solo 2 keys but I always get this:

$ solo2 update --verbose --with ~/Downloads/solo2-firmware-2.964.0.sb2 
Fetched firmware version 2:20220822.0 (2.964.0)
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████░ 309376/310672
aborting
thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lpc55-0.2.1/src/bootloader/protocol.rs:299:29:
unexpected status SbLoader(Signature)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Running with the option produces this:

stack backtrace:
   0: rust_begin_unwind
             at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
   1: core::panicking::panic_fmt
             at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
   2: lpc55::bootloader::protocol::Protocol::call_progress
   3: lpc55::bootloader::Bootloader::receive_sb_file
   4: solo2::device::Device::program
   5: solo2::try_main
   6: solo2::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.