Add a way to validate existing backups

[cryxia]

A major component of having backups is verifying that they actually work before you need them. I would like to suggest that onlykey support some form of backup verification.

At a basic level the key can just verify that the backup file is able to be read but not do the restore. Ideally I'd like the key to also report whether or not the backup is out of date or not. It could also report which slots are different compared to the backup but this might be a security issue.

I haven't thought through all the security implications of this but I think at a minimum if we're offering a way to backup the key we also need to allow a way to verify the backup.

[bratkartoffel]

Maybe some kind of command-line tool to read, verify and print out all kind of information from the various slots? The most important information (at least for me) would be some "last-modified" timestamp, and in some cases the username and unencrypted password. For quick disaster recovery (when you don't have a second onlykey at hand) this would not lock you out of your systems. As this needs the user to enter the backup password I don't think it to be a really great security issue.

[onlykey]

As you probably know most similar devices do not permit any backup at all. This is because doing backups securely is not easy. The reason OnlyKey's implementation of backup/restore is secure is that the app, user's computer, and all software is completely unaware of the contents of the backup, only when it is loaded to OnlyKey is the backup decrypted on the device. Any tool or software that allows reading the contents of the backup would be a security vulnerability as if the tool or software was compromised (i.e. Malware) it would be game over.

As for testing backups, you can as soon as you create a backup restore that backup file. Since the backup contains the same data as your OnlyKey it would just write the same information to your key. As for corrupted backup file, since the complete backup file is encrypted using AES 256 GCM if say you deleted one character, everything after that character in the backup file would be unreadable. There are dates and timestamps in the backup file name for tracking newer and out of date backups.

I have not received any complaints of issues with restore due to corrupted files but I do think in the future we will include a checksum in the backup file to allow the app to verify it is not corrupted.

[bratkartoffel]

I cannot agree fully to your reply, although I understand the security implications of such a feature.

The data is here, the stick firmware is opensource. So the format of the backup is somewhat documented, so writing an application to decrypt it (at your own risk) is just some code to write. And i would prefer it to be written by some trusty company who knows what they do. Again, it should be up to the user (with big fullscreen warnings) to decide on which device they view the data.

But simply restoring it to "verify" it worked is imho really risky. What if the backup itself has a bit flipped? I mean, before it is encrypted and checksumed, just as the data is read from flash memory? This would mean you would restore a corrupted backup to your stick and (depending on the corrupted bit) don't even notice it within weeks.

Or am I missing some piece? The only secure way I see at the moment, is by having a second onlykey at hand, reading the backup from one, restoring to the other and using that until the next backup. But that seems a bit odd to me.

[droid192]

i read https://docs.crp.to/security.html#how-backup Could you please clarify: the base64 encrypted data of the backup result can only be decrypted by a another onlykey. There is no way the user can use the passphrase to decrypt the base64 encrypted data to cleartext to verify contents (on an offline device) with some crypto primitives himself.

[onlykey]

@vwas2 Yes, that is correct the only supported method is to restore to an OnlyKey. We are working on a feature that should be ready for next release that includes a sha256 hash in backup which can be verified by app when generating backup to ensure backup integrity.

[onlykey]

This feature will be in app release 5.3.4