Add CLI command for retrieving root private keys from mnemonics

[Anviking]

Context

ADP-81

It is currently possible to retrieve the reward account private key of a (shelley) mnemonic.

We want to make it possible to expose the root private key (and later address keys) given a mnemonic. And not just for shelley.

Decision

As a meaningful first step in the story, add command(s) for retrieving the root private key.

Acceptance Criteria

---

• We must be able to retrieve the root xprvs of Byron-, Icarus-, Trezor- and ledger-wallets.
• Keys should be output as hexadecimal strings
• The output keys should be extended keys
• The keys may be compatible with jcli

Development

• Refactoring existing code to make the different key-types more similar Introduce SomeMnemonic as source of root keys (instead of entropy) #1343
• Allow internal XPrv to be converted to and from a 96-byte long representation suitable for usage in CLI, and that matches jcli Add unXPrvStripPub (& inverse) that matches jcli #1369
• Add key root command Add CLI command for extracting root xprvs #1321

QA

• It is possible to extract root keys using the icarus, trezor, and ledger styles. byron support was dropped (https://jira.iohk.io/browse/ADP-81?focusedCommentId=13669&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13669)
• Integration tests checking that unXPrvStripPub-output is compatible with jcli https://github.com/input-output-hk/cardano-wallet/blob/c392526ffdf063290580bc2d108d5ffdfc29bd74/lib/jormungandr/test/integration/Test/Integration/Jormungandr/Scenario/CLI/Keys.hs#L61-L67
• For testing, heavy emphasis was put on making sure key-to-hex conversion always roundtrips.
  • When encoding a private key to hex, the wallet checks that the output will be able to roundtrip back to the same private key again. If not it errors. This happens in the case of Byron keys and encrypted keys. (more relevant for the key child command where Byron-derivation (now dropped) would produce non-roundtripping children for roundtripping parents.)
  • A property test scheme == mapKey (fromHex . toHex) scheme https://github.com/input-output-hk/cardano-wallet/blob/c392526ffdf063290580bc2d108d5ffdfc29bd74/lib/cli/test/unit/Cardano/CLISpec.hs#L603-L606
• A few integration-like tests including positive and negative tests. https://github.com/input-output-hk/cardano-wallet/blob/c392526ffdf063290580bc2d108d5ffdfc29bd74/lib/cli/test/unit/Cardano/CLISpec.hs#L565-L592
• CLI usage tests were added.

[Anviking]

@piotr-iohk @paweljakubas any thoughts on the following plan:

Extract root xprvs (this ticket)

using same flow as the existing reward-credentials, i.e
Prompts user to enter mnemonic in stdin after executing the command

cardano-wallet-jormungandr mnemonic extract-root-xprv --type shelley
cardano-wallet-jormungandr mnemonic extract-root-xprv --type byron
cardano-wallet-jormungandr mnemonic extract-root-xprv --type icarus
cardano-wallet-jormungandr mnemonic extract-root-xprv --type ledger
cardano-wallet-jormungandr mnemonic extract-root-xprv --type trezor

Extract address keys (not this ticket technically)

# Extracting the 100th address xprv for the mnemonic's default account
cardano-wallet-jormungandr mnemonic extract-address-xprv 100 --type byron

Pros:

• Easy to use
• No mnemonics in terminal history (I believe is the idea, = secure)
• When deriving an address key, there is no intermediary step of having the root private key in the terminal output or on disk (less likely to leak root private key)

Cons:

• Fairly limited in uses
• Not that composable. Adding more features might come unnatural.
• No support for deriving public keys from the mnemonic
• No support for doing soft derivation (root/account xpub -> address xpub )

[paweljakubas]

I think that the fact that it uses the same flow as the existing reward-credentials is very strong argument in favor. Prompting to enter mnemonics in stdin also seems right - I agree here.

[piotr-iohk]

lgtm.

Question about the part: Extract address keys (not this ticket technically)
Is there a way to get key for a specific address rather than which in line?

I mean like:

cardano-wallet-jormungandr mnemonic extract-address-xprv addr1s0.....ljk38k3la --type byron

I think that would be more useful?

[Anviking]

That is an interesting idea!

I believe this should be fairly straight-forward to do with random addresses (e.g. byron).

For sequential addresses we'd need to generate a range (say for indices [0, 1000]) of keys, and check if each corresponds to the address.

Maybe that could even help this user brute-force search for his missing seed word.

[Anviking]

For the record: New requirements from Matthias in ADP-81

For this ticket this means taking the mnemonic words as arguments instead of via a secure getLine.

Regarding "Extract address keys (not this ticket technically)", this will be more generic. From the provided examples:

$ key child --path 44'/1815'/0'/0 5bd164a28...1ae275939
  0d0a62eef...6f2aee621

[piotr-iohk]

@Anviking, @KtorZ

1. Question about: Add CLI command for retrieving root private keys from mnemonics #1316 (comment)

For this ticket this means taking the mnemonic words as arguments instead of via a secure getLine.

Don't you think that's a bit of a security concern? Also it is not consistent with how we handle mnemonics in CLI in other places, e.g.:

• cardano-wallet-jormungandr mnemonic reward-credentials
• cardano-wallet-jormungandr wallet create

2. I see that key option is available in cardano-wallet-jormungandr but not in cardano-wallet-byron. Is that intentional?

[Anviking]

I see that key option is available in cardano-wallet-jormungandr but not in cardano-wallet-byron. Is that intentional?

Ah. I guess that is not intentional👍

Don't you think that's a bit of a security concern? Also it is not consistent with how we handle mnemonics in CLI in other places, e.g.:

Tbh, yes. I was worried when I tested with a real old Byron mnemonic, and upgraded my shell to have a fish --private feature before doing that.

I think being able to provide the mnemonic as stdin or argument should still be possible. But an interactive "secure option" might be nice. Perhaps marketed as default.

I would also like to support piping between wallet key commands

such that I can more conveniently perform:

cardano-wallet key root | cardano-wallet key child --path "44'/1815'/0'/0" | cardano-wallet key public

without ever having an intermediary private key or mnemonic in the history.

Perhaps we (I) could create a follow-up U/S for this?

[Anviking]

I should note: I don't really feel confident about what security concerns there are, or how intricate shell details might interplay.

I mostly just know that the interactive prompt way of reading mnemonics avoids putting them in the shell history, and I'm extrapolating from there.

[piotr-iohk]

Re: #1316 (comment)

I think being able to provide the mnemonic as stdin or argument should still be possible. But an interactive "secure option" might be nice. Perhaps marketed as default.

I think that if we think that having mnemonic in arg is a security concern we shouldn't support it. (the only advantage is that such CLI is easier to automate I think, but I don't suppose that is a big advantage over security). Also, I think that we should be consistent in the way we treat mnemonics in CLI, and I think that having it in the form of "interactive CLI" in other CLI commands was the result of previous discussions over security. 🤷‍♂️

I mostly just know that the interactive prompt way of reading mnemonics avoids putting them in the shell history, and I'm extrapolating from there.

I'm going from the same place :).

I would also like to support piping between wallet key commands

Indeed, that sounds like a separate story.

--
Some thoughts about integration tests:
https://github.com/input-output-hk/cardano-wallet/blob/c392526ffdf063290580bc2d108d5ffdfc29bd74/lib/jormungandr/test/integration/Test/Integration/Jormungandr/Scenario/CLI/Keys.hs#L61-L67

I think that these are not integration tests actually, because they do not excercise the system e2e enforcing "integration" of all components in order to get the result (unless I'm missing something).
Nevertheless these are nice roundtrip tests, but I think they should live somewhere along other unit tests.

Having said that, I think there are actually no integration tests for this requirement. Perhaps at least a few scenarios could be handy. (similar as here -> https://github.com/input-output-hk/cardano-wallet/tree/master/lib/core-integration/src/Test/Integration/Scenario/CLI). What do you think? :)

[Anviking]

I think that these are not integration tests actually, because they do not excercise the system e2e enforcing "integration" of all components in order to get the result (unless I'm missing something).
Nevertheless these are nice roundtrip tests, but I think they should live somewhere along other unit tests.

They do launch jcli as an external process. I originally added them in core:unit, but @KtorZ told me to move them 😄

Having said that, I think there are actually no integration tests for this requirement. Perhaps at least a few scenarios could be handy

Are these not enough as integration tests?
https://github.com/input-output-hk/cardano-wallet/blob/master/lib/cli/test/unit/Cardano/CLISpec.hs#L640-L667

(They don't actually call a wallet executable, but they result in the full cli handlers being invoked. But I think that is just fine.)

[piotr-iohk]

They do launch jcli as an external process. I originally added them in core:unit, but @KtorZ told me to move them smile

Ok, in my opinion the fact that they use jcli to check the result does not make them integration tests 🤷‍♂️. But, I guess, that's opinion vs. opinion... so, ok. ;)

(They don't actually call a wallet executable, but they result in the full cli handlers being invoked. But I think that is just fine.)

Allright, I'll base on your assessment.

[piotr-iohk]

ok, lgtm.