#CU-351hv4z | Wallet Storage

[crnbarr93]

Motivation

The way we were storing wallets previously is insecure, using a mnemonic. The changes in this PR reflect a rework for wallets to use a stored serialization of a SECP256k wallet key, encryped using a passphrase.

Implementation

The WalletStore class was redesigned to work around stored keys as opposed to mnemonics. New getters/setters interact directly with the stored config as opposed to in memory. This keeps everything in sync and correct. The Wallet class was also reworked to use serialization/deserialization of keys.

Wallets are now stored in a keys.json file and store more info about the wallet. The WalletStore can access and deserialize these wallet keys using passphrases stored in the OS keychain, if there is no stored passphrase the user is prompted for it. A getter is used for the current wallet which keeps everything in sync.

Due to these updates, when adding a wallet the user is now prompted for a passphrase which is used to serialize/deserialize the wallet. This cannot be empty and is for security purposes, if the keys.json file is compromised the keys cannot be decrypted without the appropriate passphrases. The OS keychain allows the wallets to be deserialized without a prompt (unless set so by the user).

Testing

N/A

Notes

N/A

Future work

N/A

[crnbarr93]

Task linked: CU-351hv4z Security concern: storage format