This is kind of a 180 from my previous position, but I’ve come around to this being acceptable if it requires physical user interaction.
Many software Passkey solutions already backup/sync private keys anyways. I think it’s reasonable for someone to want a hardware solution for Passkeys/FIDO2 which also allows them to backup and sync those hardware keys, which YubiKey doesn’t do.
With this change I think we could reevaluate OnlyKey. I also think we could look into recommending the Security Key apps offered by Ledger and Trezor.
It really isn’t? Hardware-backed keys must not leave the enclave where it was created. If not, there is not much gain from using a dedicated hardware (or a crypto subsystem) anyway?
Depends on the “interaction”. If this interactivity means the hardware may have an increased attack surface, it may not be worth recommending, after all.
TFC is slightly different in that it’s an in-line encryption system. It allows taking backups as long as the copy exists on
“High side” i.e. some memory device that never gets plugged to devices other than Source computer
*“Low side” i.e. another memory device that never gets plugged to devices other than Destination computer
Keeping the two backups separate and never crossing to each other is needed too.
As the devices are user controllable and behind data diodes, you can take backups without violating the isolation.
For HSMs/smart cards, the trouble is already that you can’t really guarantee adversary won’t perform e.g. existential forgeries unless you can use on-device button to confirm the action and preferably an on-screen display to see what you’re signing. The HSM is bidirectionally connected, so the security is already more reliant on hardening than isolation.
Exfiltration security is definitely a desired property but availability is also important especially with small loose devices you might carry around.
Unless you can control from the HSM itself whether it dumps backup to the machine it’s connected to, or unless you can make the backup via off-band channel, you won’t have too much guarantee of key exfiltration security so that changes the threat model to slightly more loose category.
So since this is very dependent on the design or the device, and since the desirability of backup feature depends on threat model (lose keys vs key exfil) I’m unsure if it’s a good idea for PG to take sides. Helping users make best decision would be better.
(I should point out the data diode isolation is an interesting approach for DIY HSM as you can have both backups and strong exfil protection, but you’ll either have to type the signature or the data to sign.
The main issue to balance there is what you should type by hand, if data to sign is larger than signature you’ll want Destination computer model, and vice versa; ML-DSA signatures are roughly 2.5-4.5kB, so typing hash to sign may be easier than the entire data. So algo choice also matters there.)
If the backup in question never has to touch a computer I think there is an argument for its usefulness. I guess I am mostly envisioning hardware wallet devices where you would have a paper backup of your private key, and you could provision new devices with that paper backup entirely on-device (i.e. without needing to input anything into a connected computer).
I guess this could be specified in the criteria, but I also am on the fence about an OnlyKey-style setup where the backup is in the form of an encrypted dump to a PC.