[colemickens]

I was wondering if inspiration could be taken from the BIP32/BIP39 in the Bitcoin world. You can use a Trezor as a GPG-Agent, for example, with a key that's derived from the master key (BIP32) in the TREZOR (aka, already backed up via the BIP39 seed phrase). I haven't looked at u2f-on-trezor yet, but I'd assume it is implemented similarly.

It seems like you could use existing tooling to generate the phrase and then use some existing code/processes to derive the key backing the token's u2f private key?

[ecesena]

Independently from the protocol you choose, the final result is that two (or more) devices will share the same private key for, e.g., your google account.

The problem that we need to solve securely, is that you as a user must be sure you know all devices with that private key, i.e. no one else can trigger a backup without you knowing that, even with a temporary access to the key.

[colemickens]

I (think I) was just discussing a way to make the master key easy to backup.

Isn't what you're discussing (prevent unknown backups) more a function of how the private key is held in the Solo itself (and in my example, how securely your seed phrase is stored)? Or is there an element of U2F that I'm missing here? (Does the token itself have an identity that you want to be unique while still preserving the same key for authentication, or is there some other detail I'm missing?)

[ecesena]

Let me try to rephrase. If you have a (too easy) way to backup, i.e. extract, the master key, then an attacker can use the same mechanism to backup your master key without you even knowing that the backup happened.

You can, for example, set up a pin or passphrase, however the fido2 protocol doesn't (necessarily) work like that. You buy a key, and you just start using it. There are multiple options to implement a backup protocol, but no standard one to the best of my knowledge. My original point was just that in designing such a protocol, it's important to consider this "unknown backup attack".