# Developer identity backups **URL:** \ **Category:** Command Line Tools\ **Created:** [August 13, 2022, 6:15am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846 "2022-08-13T06:15:31Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 13, 2022, 6:15am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/1 "2022-08-13T06:15:31Z")
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`: > > > Adds support for identities based on an ECDSA key in an HSM. \`dfx\` obtains the …PIN through the \`DFX\_HSM\_PIN\` environment variable. > > This should probably go in docs somewhere: > > 1. Install software for your token (www.nitrokey.com/start for example) > 2. Initialize your token > \`\`\` > $ pkcs11-tool --init-token --init-pin --new-pin $PIN --label $LABEL --slot $SLOT > \`\`\` > > 3. Create a key > \`\`\` > $ pkcs11-tool -k --slot $SLOT -d $KEY\_ID --key-type EC:prime256v1 --pin $PIN > \`\`\` > 4. Create an identity associated with the key and use it > \`\`\` > > $ dfx identity new --hsm-key-id $KEY\_ID --hsm-pkcs11-lib-path /usr/local/lib/opensc-pkcs11.so my-nitro-key > $ dfx identity use my-nitro-key > \`\`\` > 5. Use your token > \`\`\` > $ DFX\_HSM\_PIN=$PIN dfx deploy > \`\`\` I also found this issue which explains some of the motivation: > > > This will be a new Identity type in agent-rs and a way for \`dfx identify\` to use… it > > \- \[x\] agent-rs \`HardwareIdentity\` type (compared to \`BasicIdentity\`) > \- \[x\] bring \[pkcs11 crate\](https://crates.io/crates/pkcs11) into agent-rs > \- \[x\] a way to create an HSM-backed identity \`dfx identity new\` > - something like \`dfx identity new --hsm-key-id $KEY\_ID \\` > - creates \`~/.config/dfx/identity/\/identity.json\` instead of \`identity.pem\` > \- \[x\] \`dfx\` instantiates \`BasicIdentity\` or \`HardwareIdentity\` depending on directory contents > \- \[x\] environment variable for HSM PIN > > \--- > The core thing is: we want to sign ingress messages with an HSM. We’re already doing the same in node manager, and we could be using the same approach here. > 6:44 > Some background: We will have “precious” Neurons already in Mercury I, and we want to keep the keys that are needed for controlling that Neuron in a safe space. So we’re aiming at storing them on a USB HSM. This USB HSM speaks PKCS#11. > > Björn Tackmann 6:51 AM > In the node manager, we just depend on pkcs11-tool being available and use that to create the signature. Here are the commands we use: > \`\`\` > pkcs11-tool -r --slot $SLOT -y pubkey -d $KEY\_ID \> public\_key.der > echo -n $MSG | \\ > pkcs11-tool --hash -m SHA256 | \\ > pkcs11-tool -l -s --slot $SLOT -d $KEY\_ID --pin $PIN -m ECDSA \> signature.raw > \`\`\` > If there is only one HSM (which will likely be the case), we can just omit the --slot part. And $KEY\_ID can be any constant hex string. > Instead of doing pkcs11-tool --hash -m SHA256, we could just apply sha256 in dfx before passing the message to pkcs11-tool for signing. Note that this is an additional hash, which is due to the fact that the RFC version of ECDSA mandates it (which is what replica implements) but the HSM stick does not do it. > We could just use the same approach in dfx for now, requiring that machines used to sign in this way have pkcs11-tool installed. We could of course also go the full way and use a proper PKCS#11 library … 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. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 13, 2022, 8:22am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/2 "2022-08-13T08:22:42Z")
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. ---
**Author:** ![GLdev](https://avatars.discourse-cdn.com/v4/letter/g/4bbf92/32.png) [@GLdev](https://forum.dfinity.org/u/GLdev)\ **Post date:** [August 13, 2022, 8:53am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/3 "2022-08-13T08:53:24Z")
> [@timo](#): > > Quite the opposite, it makes backups harder because HSMs by definition do not allow you to extract the key or a seed for backup. > [@timo](#): > > 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. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 13, 2022, 10:25am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/4 "2022-08-13T10:25:51Z")
> [@GLdev](#): > > Perhaps that’s an avenue worth exploring? Making dfx work with the fido app on a nano? 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. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 13, 2022, 2:41pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/5 "2022-08-13T14:41:35Z")
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](https://github.com/dfinity/keysmith) repo, people should use now use [quill](https://github.com/dfinity/quill) instead. @GLdev I also found this issue which mentions Ledger Nano: > > > Right now we use PEM files to provide an identity for signing requests, but we'd… also like to support NitroHSM (for node providers) and the Ledger Nano, and then possibly more. I propose to do this by splitting the core governance related code into a new, internal \`ink\` crate, and use the \`quill\` crate to define the CLI and its behavior, and then have multiple \`auth-\*\` crates referenced by \`quill\` to do the actual work of working with the device to sign requests. Perhaps we could communicate our interest there. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 13, 2022, 6:38pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/6 "2022-08-13T18:38:54Z")
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 ` 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. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 13, 2022, 7:53pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/7 "2022-08-13T19:53:04Z")
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](https://github.com/dfinity/keysmith/issues/23) ---
**Author:** ![mparikh](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mparikh](https://forum.dfinity.org/u/mparikh)\ **Post date:** [August 13, 2022, 8:00pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/8 "2022-08-13T20:00:29Z")
Is keysmith audited, for truly random secure seed phrase generation? ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 13, 2022, 8:19pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/9 "2022-08-13T20:19:35Z")
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. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 14, 2022, 11:27am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/10 "2022-08-14T11:27:05Z")
> [@paulyoung](#): > > I think I misinterpreted the keysmith README as “please migrate to quill”. 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. > [@paulyoung](#): > > I did find this issue about certain phrases not being supported though: [compatibility with identity.ic0.app seed phrase? · Issue #23 · dfinity/keysmith · GitHub](https://github.com/dfinity/keysmith/issues/23) 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. > [@mparikh](#): > > Is keysmith audited, for truly random secure seed phrase generation? No. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 14, 2022, 11:37am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/11 "2022-08-14T11:37:45Z")
> [@paulyoung](#): > > I also didn’t realize that both tools seem to support using an existing seed phrase to derive a key. 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). ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 15, 2022, 4:32am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/12 "2022-08-15T04:32:29Z")
> [@timo](#): > > > [@paulyoung](#): > > > > I did find this issue about certain phrases not being supported though: [compatibility with identity.ic0.app seed phrase? · Issue #23 · dfinity/keysmith · GitHub](https://github.com/dfinity/keysmith/issues/23) > > 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. 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. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 15, 2022, 8:52pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/13 "2022-08-15T20:52:06Z")
> [@timo](#): > > 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. @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 "" | keysmith private-key -f=- -i=0 -o=identity-0.pem` ---
**Author:** ![ericswanson](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ericswanson/32/622_2.png) [@ericswanson](https://forum.dfinity.org/u/ericswanson)\ **Post date:** [August 16, 2022, 1:16am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/14 "2022-08-16T01:16:12Z")
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](https://github.com/dfinity/agent-rs/blob/main/ic-identity-hsm/src/hsm.rs#L107)). 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. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [August 16, 2022, 4:44am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/15 "2022-08-16T04:44:22Z")
> [@paulyoung](#): > > This works though: > > `echo "" | keysmith private-key -f=- -i=0 -o=identity-0.pem` Sorry, yes, I meant via piping, not directly. For example: ```auto 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 ``` ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [August 18, 2022, 3:04am UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/16 "2022-08-18T03:04:35Z")
> [@timo](#): > > Ledger Nano won’t work because that would require a special app on the Ledger Nano that is written for that purpose. > **[Alamgu: The Rust Ledger Platform](https://blog.obsidian.systems/alamgu-the-rust-ledger-platform/)** > > Alamgû (Akkadian) n.: engraver of seals > > > > The Beginning > > > Lately, across ecosystems, more blockchain protocols are allowing security-minded users to store their private keys offline, on hardware devices. The leading hardware wallets are the Ledger... ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [September 1, 2022, 5:30pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/17 "2022-09-01T17:30:44Z")
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. > > > Both \`keysmith\` and \`dfx\` support password-protected PEM files. > > Is there alre…ady a way to use a password-protected PEM file with \`quill\`? Sharing here for extra visibility. ---
**Author:** ![muharem](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/muharem/32/6577_2.png) [@muharem](https://forum.dfinity.org/u/muharem)\ **Post date:** [February 9, 2023, 4:00pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/18 "2023-02-09T16:00:03Z")
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? ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [February 9, 2023, 4:28pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/19 "2023-02-09T16:28:44Z")
We do not have any proper documentation. @ericswanson pointed me to [this comment in the code itself](https://github.com/dfinity/agent-rs/blob/main/ic-identity-hsm/src/hsm.rs#L103-L107), but otherwise we have nothing right now. IIRC Nitro keys should be supported. ---
**Author:** ![muharem](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/muharem/32/6577_2.png) [@muharem](https://forum.dfinity.org/u/muharem)\ **Post date:** [February 14, 2023, 7:55pm UTC](https://forum.dfinity.org/t/developer-identity-backups/14846/20 "2023-02-14T19:55:13Z")
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](https://www.yubico.com/ch/product/yubihsm-2/) 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! [Next page](https://forum.dfinity.org/t/developer-identity-backups/14846.md?page=2)