Provide secure storage and improve root key security

[mmick66]

I see that wallet-lib stores its private keys in memory as a property, as well as in-memory on the KeyChain. Is there a way to replaced this with a secure, encrypted key storage? This would be crucial for a mobile app using react native for example.

[Alex-Werner]

Hello @mmick66

Thank you for noticing this, yes, this is to me the biggest issue I have with wallet-lib. But it is actually more than just that, right now, for the sake of the exportWallet() function, mnemonic and root keys (seed) are stored. But this information is not needed as we could at least have a derivation path (so we don't make other chain using the same mnemonic vulnerable). There is indeed on top of that the secure storage issue (which so far were left for pull request but no one really made one yet).

What I can say is that we do have this planned, but its priority is delayed due to more immediate need. So I can't give any ETA yet (I hope we are talking about end of year). But let's use this issue to discuss the subject in the meantime. Would any users have specific requests on that subject, please forward it here as we will use this issue to ensure we match requirements.

[mmick66]

Thank you for your honest reply. For the moment, and as I am trying to use this library on a current project that I'm working on, I though of the following pattern for mobile devices. I am going to post it here for others to see, as well as for you @Alex-Werner to give me an opinion.

To create a wallet you:

1) Generate a new Mnemonic through the helper function. You then show it to the user, who is then made responsible for storing it.

2) You create an HDPrivateKey, and from that, a (standard) PrivateKey.

3) You create a PublicKey and Address and instantiate the Wallet with either as an WALLET_TYPES.ADDRESS or WALLET_TYPES.PUBLICKEY respectively. At this point, only the PublicKey and/or Address are going to be saved in-memory.

4) You discard both Mnemonic and HDPrivateKey from memory, and save the PrivateKey in a secure storage.

5) Whenever you want to sign a transaction (or Message), you unlock the PrivateKey from storage using whatever mechanism you with (pin, TouchID, FaceID etc) and pass it to the sign function of the Account, which is going to pass it to the sign function of the KeyChain.

[Alex-Werner]

Thank you for this. Indeed the plan is exactly what you describe ! Keep me update about your progress, so I can see if at some point I need / can prioritize slightly more.

In wallet-lib case, it will be specific, we still require a HD key (but at lower level), for us to be able to generate additional public address (BIP44), or identities.

So the path will be specific to BIP44/dash,... for change and external.

We also manage identities, so we also have that

[mmick66]

Sure, I get what you are saying. Currently, and for the purposes of my project, I need a "single address" wallet only. Basically, and for my current purposes, a wallet will be (practically) synonymous to an account. I will keep you posted if and when I encounter problems. Thanks again for the swift response.