Developer identity backups

Developers Command Line Tools
1

I’ve been feeling dissatisfied with the notion of having developer identities tied to .pem files.

Namely; how to back them up securely, and the prospect of losing them in a worst case scenario.

I’d like to have similar options as things like Internet Identity when it comes to being able to recover them.

I came across the following pull request that added support for HSM-backed identities to dfx:

I also found this issue which explains some of the motivation:

The numbered steps in the PR suggest that this feature might be intended to work the way I hope it does, but I’m not sure.

Some questions:

  1. Does this allow developers to use devices like USB security keys instead of .pem files?
  2. The PR mentioned NitroKey; I’m not familiar with those. Will other popular security devices (that people may already be using for II) work as well?
  3. Is this documented anywhere? I could only find the links I shared above, and a brief mention of the relevant flags in the docs for the dfx identity command.

Tagging @ericswanson since they authored the above PR and GitHub issue.

3 Likes
2

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.

2 Likes
3

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.

2 Likes
4

There are two approaches for how a hardware device can work:

  1. It is enough to plug the hardware device in and then the software on the computer can get any message signed that it wants.
  2. 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.

3 Likes
5

Thanks @timo. I wasn’t aware that keysmith could generate a seed phrase and then derive a PEM file. I like that a bit better.

Perhaps this approach could be promoted more in the documentation.

According to the keysmith repo, people should use now use quill instead.

@GLdev I also found this issue which mentions Ledger Nano:

Perhaps we could communicate our interest there.

1 Like
6

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.

2 Likes
7

I think I misinterpreted the keysmith README as “please migrate to quill”.

I also didn’t realize that both tools seem to support using an existing seed phrase to derive a key.

As you pointed out, keysmith can use that same seed phrase to derive multiple keys, which might appeal to people who have already securely backed up a phrase.

I did find this issue about certain phrases not being supported though: compatibility with identity.ic0.app seed phrase? · Issue #23 · dfinity/keysmith · GitHub

8

Is keysmith audited, for truly random secure seed phrase generation?

9

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.

10

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.

No.

1 Like
11

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).

1 Like
12

My impression was that the person who created that GitHub issue was probably trying to use the same seed phrase for both their Internet Identity and their developer identity.

13

@timo, do you know what the name of the environment variable is? I haven’t been able to find anything about that.

This works though:

echo "<seed words>" | keysmith private-key -f=- -i=0 -o=identity-0.pem

14

quill will generate the same key from a given seed phrase.

The private key that quill generates from a given seed phrase will also match the private key on a Ledger device using the Internet Computer app.

Unfortunately, the HSM support practically isn’t documented at all.
(See agent-rs/hsm.rs at main · dfinity/agent-rs · GitHub).

You’d follow these steps:

  1. Run pkcs11-tool -k --slot $SLOT -d $KEY_ID --key-type EC:prime256v1 --pin $PIN
  2. Create an identity to use it, something like dfx identity new hsm --hsm-key-id $KEY_ID --hsm-pkcs11-lib-path /usr/local/lib/opensc-pkcs11.so
  3. export DFX_HSM_PIN=$PIN
  4. dfx identity use hsm
    Then dfx will use the HSM.

All that said, I recommend using an identity based on a seed phrase. I typically use a Ledger device to generate the seed phrase, and then use quill to generate a .pem file from that.

2 Likes
15

Sorry, yes, I meant via piping, not directly. For example:

read -s seed
echo $seed | keysmith private-key -f=- -i=0 -o=identity-0.pem
echo $seed | keysmith private-key -f=- -i=1 -o=identity-1.pem
1 Like
16
17

Another thing I ran into with trying to use Quill (for governance purposes) is that I have password-protected PEM files and Quill doesn’t seem to support them.

Sharing here for extra visibility.

1 Like
18

Hello! Is there documentation about this dfx identity new feature … what hardware keys are supported? Is there a tutorial that shows how to use these?

1 Like
19

We do not have any proper documentation. @ericswanson pointed me to this comment in the code itself, but otherwise we have nothing right now. IIRC Nitro keys should be supported.

1 Like
20

We need this properly documented please. For opsec reasons we cannot have private keys on laptops when we deploy canisters.

I chatted with an ICP.Labs participant and he told me that he managed to make YubiHSM 2 | Hardware Security Module | USB-A work with dfx.

Don’t want to dox anyone but I think it’s fine to share the name via a private channel. It would be great if you could

  • reach out to the person in question
  • collect the info how it works
  • add it to the documentation.

Thank you!