There are definitely options beyond proprietary ones, including options with much different approaches than a traditional HSM storing the keys with / without encryption (ideally with a passphrase entered onto the device). I really like the approach pioneered for Bitcoin wallets.
Conversation
Since that lets you generate keys on the hardware wallet, back up the high entropy recovery seed as a phrase, verify you backed it up correctly and then if you need to recover on a new device you can enter it directly onto a new hardware wallet without exposing it to a computer.
1
The traditional approach is good if you have existing SSH and GPG keys that need to be moved onto an HSM. I'll definitely prefer the deterministic wallet approach for new keys though. It's not that bad to migrate to new SSH keys but GPG tends to make rotating keys very painful.
1
Signing keys for firmware usually can't be rotated at all since they're burned into fuses so that's another case where a more traditional HSM is the best option since existing keys need to be migrated. Android app signing keys were similar, but they've finally added key rotation.
1
I really like the - code has been audited by so that is a huge plus in my book, and there's tons of eyes on the code as maintainers use them as well. Nothing against - they are an incredible company and I use their devices for btc
2
Entering a password on device (like you mention) is a big plus for Trezor though, as is their open CPU. (What smart card does nitrokey use?)
1
1
I find the recovery model to be the biggest advantage of the approach based on deterministic wallet design. The hardware wallet generates a high entropy seed, displays it as a recovery phrase and you can write it down, store it and recover without exposing it to the computer.
1
1
1
I need backups for my keys. For a traditional HSM, that means I need to generate them on my computer, back them up onto cold storage and import them onto the HSM. If I ever need to do recovery, I need to expose them to a general purpose computer again too. That's problematic.
2
1
3
Entering a passphrase directly on the device is another nice property of the Trezor Model T, but a traditional HSM can support that for encrypting keys and still wouldn't have the solid approach to recovery or the deniability from all passphrases leading to valid wallets/keys.
1
1
I'd really like to see other implementations of the same model they've designed. There are many other cryptocurrency wallets doing it but it's just as applicable to U2F, SSH and GPG which are also provided by a Trezor. I'd like to see alternatives with compatible implementations.
1
1
Another advantage is that the Trezor Model T has you confirm actions on the device for U2F, SSH, GPG, etc. It doesn't just have that for sending a Bitcoin transaction or verifying a receive address by showing it as text / qr code on the device. It has you confirm U2F/SSH/GPG use.
The disadvantage of the deterministic wallet approach is you can't use it to important and secure existing keys, so you need a mechanism for key rotation. Similarly, if you decide to change the passphrase, that involves key rotation since keys are derived from seed + passphrase.
2
1
It's how I'll be handling SSH, GPG and other keys in the future. The traditional HSM approach doesn't work for me because I need backups of the keys. For U2F, it's also silly you need recovery codes for each site. I have offline recovery for U2F as a whole with this approach.
1