Expected Behavior:
Restoring a backup to an OnlyKey that already has a working configuration should result in the restored slot configurations to be equal to the configuration of the backup.
Observed behavior:
The running config and the restored slot configurations are merged.
Steps to reproduce:
On OnlyKey 1: Set slot 1A to enter a password.
Backup OnlyKey 1, restore the config to a fully wiped OnlyKey 2.
Observe that OnlyKey 2 behaves exactly as OnlyKey 1.
Wipe slot 1A on the first OnlyKey, configure it to enter an OTP (One-Time-Password).
Backup/restore the config to the OnlyKey 2.
Observe that slot 1A now first enters the password, then the OTP.
Making matters worse, I cannot simply set the password of Slot 1A on OnlyKey 2 to nothing because the OnlyKey App’s UI doesn’t let me.
The only workaround to fix slot 1A is to first wipe the slot completely, and then perform the restore.
This behavior means that the only way to make sure that OnlyKey 2 has exactly the same config as OnlyKey 1 is to keep track of which slots changed function (e.g. password to OTP) and selectively wipe the slot before the restore, or perform a factory reset each time before restore, which is tedious.
In any case, it undermines our implicit intuition that a simple restore of a backup should produce the exact same configuration.
I thought of the following options to help users like me to keep organized:
Make complete factory reset less tedious. Entering the pin 10x wrong takes a lot of time, and I also have to activate full wipe before that as well.
Offer to perform a full wipe before a restore and warn the user of the config merge if they don’t check that option.
Turn around option 2: Perform full wipe by default before restoring, and offer to perform a config merge instead upon restore.
Btw I’m a system administrator using 3 OnlyKeys, 1 at home, 2nd static at work at workstation, 3rd mobile, all with the same config. I have multiple OnlyKeys to prevent a situation where I forgot to leave the mobile device at work or home, and they are a first line of defence if one ever decides to break and I need quick replacement. So now, to prevent losing track of any differing config, I perform the backups/restore procedure quite often, as slots change regularly.
I can’t offer any help with changing the behavior, but I can offer a couple of ideas that I believe either make the currently required process more convenient, or else represent other things that need to be fixed in either the Onlykey or the documentation. That said, I haven’t tested any of these; they are based on my understanding of what the documentation says.
I think a normal wipe should be adequate for your purposes.
I think you could use a self-destruct PIN instead of entering an incorrect PIN ten times. That said, I think this has a drawback that you then can’t go back to not having a self-destruct PIN set at all without doing a full wipe.
I think you might alternatively be able to use the onlykey-cli to script out wiping what you need to wipe. (On an original, non-DUO one, at least, I think this would require unlocking each profile to wipe it.) Personally, I’m not sure I’d want to wrestle with this even if the alternative is ten incorrect PINs with full wipe mode set; seems like every time I try to use the CLI or one of the agents, I find something new wrong with my Python environment.
I can shed some light on why slots are merged instead of wiped. The OnlyKey backup includes all slot data at the time of backup. The way people typically use the backup/restore feature is that you are loading an older backup (say you did a backup a month ago) to a device that has potentially newer information (say you added some information to your slot since your last backup). If the backup/restore functionality first wiped your slot and then restored the data from your backup then the newer information stored on the OnlyKey would be lost forever. That would potentially be a situation where a user is locked out because they restored a backup that wiped information from OnlyKey. For that reason, backups are only written to the device you are restoring to, we don’t wipe the existing data first as that could inadvertently wipe a user’s account information.
Thank you, @0x3b0b for taking the time to propose your workaround suggestions. I may have mixed up the full wipe requirement because I had to do that recently in conjunction with a restore to an OnlyKey that had an older firmware.
I will try out the self-destruct method the next time I need a restore and see how the handling is.
Thank you, @t11 for explaining the reasoning behind how the backup procedure works and I see how it helps preventing data loss. Might I still express my wish for a wipe-before-restore checkbox or something similar?