You can use HSMs with dfx today but that doesn’t help you with backups. Quite the opposite, it makes backups harder because HSMs by definition do not allow you to extract the key or a seed for backup. If you lose the device then you lose access to your developer identity.
If you want a backup then you can create a .pem file with keysmith, for example. Then the .pem file is derived from a seed phrase which you can back up.
In terms of devices, the NitroKey does not require an interaction such as a finger press for each use. Dfx can access the NitroKey as long as it is plugged in and an environment variable is set to the correct PIN. I don’t think Yubikey works with dfx (not sure). Ledger Nano won’t work because that would require a special app on the Ledger Nano that is written for that purpose.
One of the reasons I liked ledger nano over a yubikey is that you can use the fido app on the nano, and you get to also securely backup your keys (a restored ledger nano will have the same fido key, according to their docs). Perhaps that’s an avenue worth exploring? Making dfx work with the fido app on a nano?
I guess having to “authorize” each dfx interaction would become tedious at some point, but if the opsec needs require this, it would seem to be the best of two worlds - hardware device with good backup procedures.
There are two approaches for how a hardware device can work:
It is enough to plug the hardware device in and then the software on the computer can get any message signed that it wants.
You have to approve every single message that is about to get signed on the device by interacting directly with the device.
Approach 2) only has a security advantage over 1) if the message that is about to be signed is displayed on the device. dfx is a versatile tool that can construct arbitrarily complex messages and sign them. I don’t see a way to use that in a meaningful way in combination with the Ledger Nano.
Hence my conclusion:
Use dfx with an HSM that doesn’t require interaction and doesn’t have a display because you wouldn’t benefit from a display anyway.
Use the Ledger Nano for narrowed down applications where the full message can be displayed such as simple token transfers and specific NNS actions.
To use Ledger nano with dfx in a generic way maybe one could only display the canister that is receiving a call but not the content of the message. It may give you some comfort. But in any case an app needs to be written for the Ledger Nano and that has to be approved and reviewed by Ledger, so any effort of that kind will take 6 months to 1 year.
keysmith is the lighter tool compared to quill and the right tool for the job. It also allows you to derive multiple keys (.pem files) from the same seed with the -i <derivation index> option.
quill is more a replacement for and on the same level as dfx. Quill is for people who want to only do neuron management but with a simpler interface than dfx. Originally quill was used on top of keysmith. Only later was key derivation added directly into quill.
quill interacts with the IC, keysmith doesn’t. quill is overkill for what you are trying to achieve.
I suppose this concern can be mitigated by using an existing seed phrase.
I would want to be sure that in the case of recovery that I’d be able to reproduce the same keys from the seed phrase, potentially on a different device with different hardware. I’m not sure how much of a concern that is.
I normally use Nix to try and address that type of concern but it’s not foolproof.
Yes, that comment right at the top is misleading. It seems targeted at the specific user group that wants to use manage neurons and that formerly had to use the combination of keysmith/dfx.
I think this issue is irrelevant for what you are doing. Yes, with keysmith you will get an ECDSA key in the .pem file and with dfx you natively get an EdDSA key (I think). But you won’t notice any difference when using them. What key types internet identity uses should be irrelevant for your developer identity.
Yes, both tools can be used. However, I just looked into how each tool does it. I noticed that with quill you have to supply the seed phrase in quotes on the command line which is not preferable. Quill cannot read the seed phrase from a file or environment variable and then output a .pem file. Quill can read the seed phrase from a file and then directly use it to make a call to the IC, but that is not what you need. Keysmith on the other hand can read the seed phrase from a file or environment variable and output the .pem file. Putting the seed phrase into an environment variable is the safest way because then it won’t get written to disk.
Also, keysmith can handle multiple derivation indices while quill cannot (it only uses derivation index 0).