FIDO2 Resident keys not included in backup

I recently purchased 2 onlykeys and tried setting them up for FIDO2 logins.

One of the reasons I bought these keys is because of the backup function.

However, I tried restoring the backup file on the other key, and although that went successfully, the FIDO2 resident keys didn’t seem to be included. I have verified it using the cli, tried multiple things, but cannot restore those resident keys.

I really need to be able to restore those, for example in the case I lose my key, or I have to wipe the data.

Is there any way to get this included in the backups?

That should definitely work. I use multiple keys restored from a primary one, and the FIDO2 element is fine.

Are you sure that when you restored your second device it was wiped?

– bvs

It shouldn’t matter, as a backup should overwrite the data, but I tried restoring right after factory resetting.

No effect.

The slots are restored correctly, but I do not get the credential.

Not sure if it isn’t included in the backup or if it won’t restore it.

Running the latest app version + the latest firmware.

Of course the backup should overwrite the data, where that data exists in the source. But OnlyKey won’t overwrite data in the destination if it doesn’t exist in the source, for example, slot 5 is blank in your backup but populated on your destination key. That slot data will persist.

Anyhow, the point was it’s always best to restore to a fully wiped device to avoid this, and other issues which it sounds like you’ve done.

Do you mean that you have run something like onlykey-cli credential ls on the source device which shows the resident keys, and when you run it on the restored device it shows nothing?

– bvs

Yes, that is exactly the case.

Other than making sure they’re both on the latest firmware version, and you’re using the latest app or onlykey-cli version, I can’t see why that would be the case. As I say, this works fine for me. Maybe @t11 can shed more light on it for you.

– bvs

1 Like

I’ll second what everyone else is saying. I have successfully restored fido secrets to the onlykey multiple times.

If you have successfully created a fido secret, and it is working on your onlykey, the backup should be able to restore it.

If you’ve used the only key multiple times, on multiple sites, and you don’t keep the pin the same, the fido secret will not work.

So, if you have a fido secret in facebook, and the pin is 1234, and then you go to google and reset the pin to 5678, it won’t work on facebook.

Give that a shot, and see if it works.

I don’t know exactly what you mean with this. I didn’t do anything in the app, just the website created a credential for me when setting up FIDO2 there.

onlykey-cli credential ls returns the list with the credentials (only one) for the origin device, but on my other device, after using the backup file, it returns nothing.

I have used this key multiple times and on multiple devices. Just to test if that would work.

I just installed my device and I only have 1 website with FIDO2 credentials set. I wanted to test and make sure that everything works.

Have some more details, but don’t know if they should make a difference:

  • My backup password is between 50-100 characters long, and it has multiple character-types
  • I have not clicked on “lock backup key” in the preferences tab of the app

I don’t think either of these are going to be related. I’d expect that if the backup password was an issue, it wouldn’t restore the other items you say it is. Decryption is an all or nothing. If your password wasn’t decrypting your backup it wouldn’t work at all, even if it was due to OnlyKey not liking some funky character.

Locking the backup key just ensures it can’t be changed.

What firmware version are you using?

You may have hit a bug, or there may be some hardware fault with your second key.

– bvs

I have done some more testing, without luck…

Here is what I’ve tested:

  • Restoring a backup from key B to key A (the other way around)
  • Restoring a backup from A to A and from B to B
  • Tested the above things, but with another backup password (without special characters)
  • Tried another pincode for the residential keys (4 numbers instead of many)
  • Reinstalled firmware and tested again

I am using firmware v2.1.2-prodc with app version v5.3.4

  • Somehow, when I tried to see the firmware version using the cli: fwversion returns nothing. CLI version v1.2.5

In none of the cases, it restores the credentials correctly. Even if I use the same device used for making the backup. This means that if I have to reset the device, or it resets accidentally, there is NO WAY of ever getting these keys working again.

Might be good to notice: the app where I had the credential set is “Microsoft account”.

I have also tested it with Google, and that works.
However, Google doesn’t have special credentials (FIDO2) like Microsoft has.

For me too, same FW & App version.
OnlyKey A:

onlykey-cli set-pin
ssh-keygen -t ed25519-sk -O resident -f ~/.ssh/id_ed25519_sk

Then I create an OpenPGP encrypted backup and restore it to OnlyKey B.

PIN & Key is restored/existent but “onlykey-cli credential ls” output is emty. OpenSSH complains “invalid format”.

marco@t520:~$ onlykey-cli credential info
PIN:
Existing resident keys: 1
Remaining resident keys: 11
marco@t520:~$ onlykey-cli credential ls
PIN:
marco@t520:~$ ssh-keygen -K
Enter PIN for authenticator:
You may need to touch your authenticator to authorize key download.
Provider "internal" returned failure -1
Unable to load resident keys: invalid format

Recommendation @tfluthy:
an OpenPGP backup key is more comfortable than a 100-character password. :sweat_smile:

Hello, Im new here and I find myself having the same issue as SiLi.
FIDO2 credentials for a microsoft account is not being transfered when im backin up key a and restoring key b to that backup.

I did notice a bug however when looking around in the CLI (v1.2.9 windows standalone exe) and I wonder if that somehow plays a role in the missing credential thing…
After entering the key, unlocking it and running the CLI i enter “fwversion” which returns v3.0.1-prodc.
If i then enter “credential ls” im prompted for the pin which is enter and no credentials are shown.

If I then enter “fwversion” im getting jibberish in return. entering “fwversion” again and im presented with more jibberish…

Is the “credential ls” breaking something or is something broken already after restoring to the backup?

I am also NOT using the default keyboard layout “US_ENGLISH” but that should not matter as my other slots are restored correctly. it’s just the fido2 credentials that are missing

After some more digging it looks like the fido2 credential is partially restored from the backup.
Key A = org key
Key B = key that has been restored from backupfile coming from A

I can add A to a microsoft account and log in with it.
When trying to log in with B i get something along the lines of “does not recognize this key”
So i thought I would add B manually so I do not have a single key for that account.
But when i tried to add B to my microsoft account which microsoft said it did not recognize, it said my key was already registered.

anyone got any ideas?

@Leolin For your partially working example are you able to do credential ls on the restored device and see your resident key?

@ t11 Sadly no, the command returns an empty row

Some more labbing. I tried the following restores:
a > b
a > a
b > a
b > b

all of them failed to copy the fido2 credentials.
i did notice that when i enter “credential ls” on a newly formated key it returns:
“No resident credentials on this device.”
but after a restore it only returns a blank row instead of the above text.

What is really frustrating is that 2 days ago before i went to bed i managed to copy the fido2 credentials from one key to another. that is what made me try those restores.
I did not do anything different when i successfully restored the credentials…

Have the developers managed to recreate this bug or do they need more input from users with this bug?

I noticed a git issue has been created recently to which they said they’re looking to adress this in the next firmware release.

I will gladly help the developers any way i can as this is a dealbreaker for me :slight_smile: