Conversation

I learned the other day that FIDO2 keys have a counter so that if an attacker does manage to clone the key, and both keys continue to be used, the counter for them will desync and the server can detect the clone. Pretty cool, wonder how that plays out in practice.

3

11

Like I'm pretty sure the recommendation is allow for two keys but AWS still doesn't, so I'm a bit doubtful that the average backend is detecting/ handing this, but I'm certainly curious to hear otherwise.

2

2

Replying to

Should allow for more than 2 keys since adding more keys is the best way to offer recovery. My Google account has 3 security keys: YubiKey 5, Trezor Model T and Pixel 5 Titan M. Can restore Trezor by fetching 2/3 Cryptosteel backups and setting the 2FA counter to Unix time.

2

1

Replying to

So in this case (with Trezor) you're cloning the seed/ counters across devices? I'm not super familiar with that system.

1

Replying to

Trezor generates a high entropy seed as a BIP39 seed phrase (they created the standard) and has you write it down or physically store it via an approach like cryptosteel.com and enter it again to confirm. You only need the seed phrase to recovery if it's broken or lost.

1

Replying to

and

You wouldn't normally clone it. You have a way to recover if the hardware gets broken or lost somehow though. U2F/FIDO2 won't start working again with sites enforcing the counter until you set the counter higher than it was previously though. Setting to Unix time is an easy way.

2

Replying to

and

BIP39 seed phrases are really nice. It uses a word list of 2048 carefully chosen words for the use case. Normal seed phrase is 12 words, which is 134 bits of data. It's a 128 bit key with 4-bit checksum. It supports entering a passphrase as a 13th word for hidden wallets.

1

1

Replying to

and

First 4 letters of each word are unique. UI will auto-complete it and hardware backup solutions only need to support 4 letters per word. There's also SLIP39 for splitting up a seed: github.com/satoshilabs/sl The seed gets used to derive an infinite number of other keys.

1

Replying to

and

It was designed for Bitcoin wallets where each address has a separate key, derived deterministically from the seed. Supports have any number of addresses, for any number of wallets, for any number of cryptocurrencies. SSH, PGP and U2F/FIDO2 keys are derived in a similar way.

1

Replying to

and

You can have any number of SSH/PGP keys in the same way (it bases it on the user@host identity) and then you can restore them via the backed up seed. The hardware wallet only stores the seed and the counter for U2F/FIDO2. Everything else is derived from that deterministically.

1

Replying to

and

This is how encrypted backups work on GrapheneOS since I proposed the concept of an app using BIP39 seed phrase to generate the key for backups and then someone in the community implemented it. It's nice since you can use a Cryptosteel Capsule, etc. for storing that seed too.

2:51 AM · Jul 22, 2021Twitter Web App

Replying to

and

If you ever need a way to do user-friendly keys for backups, BIP39/SLIP39 are really nice. It's unfortunate when apps like Signal roll their own. BIP39 is not intended for passphrases though. It's optimized for recording it and only entering it on rare occasions for recovery.

1

Replying to

and

If I bought a new hardware wallet normally, I wouldn't do recovery but rather make a new seed and rotate all the keys by sending my Bitcoin to new wallets, rotating SSH keys, etc. It's nice to know that if it dies, I can restore it on a new wallet from multiple vendors though.

2