> Cross key syncing service.

Can’t work with FIDO/U2F, I’m afraid.

The protocol works a little differently than most people expect, which is what allows the hardware token to “store” an unlimited number of auth credentials.

What really happens at auth time is that the server (the one you are trying to authenticate to) sends a crypto package including the challenge and a key used to sign the challenge to the token. (That signing key was generated at enrollment time and encrypted using the token’s private key). The token then uses its internal private key to decrypt the signing key sent by the server, sign the challenge and send back the signed challenge.

So there is no way to transfer credentials because the credentials literally aren’t in the token (they’re stored—in encrypted form—on the servers you log in to). The only way that transfer could maybe work is by copying the token’s private key… but that kind of defeats the purpose of a security token.

I've read about how some folks are using FIDO apps on devices like the Ledger Nano, designed to be crypto currency wallets. These allow the (FIDO) device identity to be exported and later restored onto a new device from the same product line. As I understand it, the experience would be a bit more like restoring a passkey on a new phone, but using a locally secured backup rather than a cloud vendor.

Since reading about that, I've wondered if the relying party in FIDO could or should know the difference. Would this entire product line get flagged in some FIDO registry as having exportable keys? If you really cared, it seems you would need to consider this a static property of the authenticator, whether or not a particular user has decided to make use of the export feature on their device.

Worse, as a software-defined feature, do you get any guarantees at all? Do they do some kind of secure-boot chain so that the FIDO app gets access to a manufacturer key and some other lower quality app cannot be installed to spoof the same authenticator solution?

On the other hand, those devices could be more secure in some practical sense than a Yubikey. They have a display and can show context during an authentication challenge, to reduce the chance that a user is confused about which relying part is asking for the next button press. There is also potential for secure entry of a PIN factor without trusting the host computer to relay this information.

> Since reading about that, I've wondered if the relying party in FIDO could or should know the difference. Would this entire product line get flagged in some FIDO registry as having exportable keys?

The standard actually anticipates you might want to do that, so the token’s manufacturer can sign the token so that a relying party can whitelist (or, presumably, blacklist) certain tokens.

I wouldn't trust any authentication key that allowed private keys to leave the device.

The protocol don't allow that.

But we are talking about the manufacturer: they can add a backdoor and sell the backdoor as a feature for subscribed user.

That is what gp is talking about.

Well, sure, but that completely defeats the purpose of a security token. The whole point is that you can’t extract the crypto secret, even if you ask nicely.

In fact, the sales literature brags about how the secret never leaves the device!

Yes, the token itself most likely won't allow the key to be extracted. There isn't really a reason to allow it: safer to generate the key at manufacturing time.

In general cmvp compatible modules do sometimes allow keys to be exported but only if wrapped, i.e. encrypted to prevent unauthorized disclosure. However this is also explicitly forbidden in other standards, such as qualified signing in Europe (etsi-...)- keys are generated on device and never leave.

What do you do if you lose the token? Ideally you enroll two or three and just use another.

only the entire design of the product and standards around it specifically so it can do its job.