Encrypted Key Store

[amerameen]

ACs

• [x] config.toml option for encrypted_keystore: bool
• [x] Pass config to keystore
• [x] Encryption methods using PBKDF2 and sodiumoxide secretbox
• [x] Unit tests for encryption methods
• [x] Separate binary keystore file for when using an encrypted keystore
• [x] CBOR serialization for binary encrypted keystore
• [x] Instead of a hostname salt, we need to use a random bytes salt (32 should be enough) when the key is first generated, and it should be passed an Option<&[u8; 32]> it can use if the keystore file already exists. We'll just prepend the salt to the beginning of the file, and pass a byte slice to derive the same key. This way the keystore is portable between hosts. That's important for backups. The keystore is used for wallet keys, and it'd really suck to lose access to FIL if a user lost track of their hostname.
• [x] Whenever the keystore is accessed, the keystore will need to check whether it's configured to use encrypted or plaintext keystore, and if it's encrypted, use the encryption key to:
  • [x] Decrypt on read
  • [x] Encrypt on write
• [x] When setting a passphrase for the first time, ask for it to be entered once more, and compare that they are the same. If not, prompt the user for a new one.
• [x] Error handling when unable to parse a decrypted keystore (say, if an incorrect passphrase was used to derive the encryption key)
  • [x] Prompt the user for passphrase in case they mistyped it.
• [x] Interactively ask for passphrase on daemon start if encryption is enabled
• [x] This interactive mode will block initialization until it's completed (probably using some async/await)
• [x] keystore.unlock(passphrase: String) method that will call the generate_key method, but also manage daemon init blocking, and will be called by the encryption RPC API.

Notes

• Allow users to encrypt using a password

[cryptoquick]

@ec2 Is this related to the keystore.json file? I don't think that's kept in the db. If it is, that should probably change, since it's already on-disk as a separate file.

[ec2]

Oh nice. I thought it was stored in the DB for some reason...

[cryptoquick]

Just had a conversation with @f8-ptrk and he'd really like this feature prioritized. For his use-case, any degree of encryption is helpful, even if it's just AES-GCM-256 with a simple symmetric secret that decrypts the key in-memory while keeping the data encrypted at-rest. That way the keys cannot be exfiltrated from the data center from their miner workers.

Also, I might add one additional point I think the security auditors might bring up: The HTTP JSON-RPC API should have all requests over encrypted (HTTPS) connections, especially when sending a symmetric secret. This should technically be managed by the HTTP gateway on the machine, such as Nginx, or perhaps other network infrastructure, but regardless, I think we should check the X-Forwarded-Proto header to check for HTTPS when an RPC keystore decrypt method is called. This behavior could also be disabled for local testing with a command-line option when running the daemon.

I think this would be a good first issue to throw @connormullett at once he joins, what does everyone think?

[cryptoquick]

After speaking with @f8-ptrk, I added a requirement that the keystore be portable. That'd make it easier to backup and recover, especially if the user loses track of their hostname.

[cryptoquick]

I've moved the following ACs to issue #1083:

• [ ] RPC method for unlocking the keystore
• [ ] The interactive mode will unblock when the Forest.EncUnlock RPC method is called, either by the command-line client, or, programmatically via the HTTP JSON-RPC API.`

[cryptoquick]

Over the weekend I refactored the Encrypted Key Store quite a bit. We're only using sodiumoxide now, instead of mixing cryptosystems. I removed ring from the key_management crate, and we're now using the sodiumoxide Argon2id hash KDF. The salt is then prepended to the keystore when encrypted.

I just tested this out, writing and reading works great. I verified with hexyl that the first 16 bytes were the same (as a salt should be), but the remainder of the file is completely different, which means that secretbox is using a different nonce while flushing bytes to disk, which is more secure. The file also grows when running lotus wallet new and lotus wallet new bls, and I can check the balance of an existing wallet with lotus wallet balance [wallet address]. I'm not able to list, unfortunately.

Remaining items I'll leave to @connormullett to implement, which are the final remaining ACs:

• Prompt the user again (in a loop) if they enter an incorrect passphrase
• Check to see if the file has been changed on disk before writing to it