Feature request: Improving the security of keys, state and secretes

[renepickhardt]

In Mastering the lightning network we currently have the following quote:

The most common components of lightning wallet software include: A keystore that securely holds secrets, such as private keys.

I opened an issue on Mastering the Lightning Network: lnbook/lnbook#136

and noted the following about c-lightnig:

believe in early days there was no way to encrypt wallet.dat and wallet.dat has been stolen leaked. in a same way for example in c-lightning we have hsm_secret that stores the private master key in plain binary format and the entire state is stored in plain text in a sql database. For state information it will be even more tricky to encrypt this as the state will / should change without user interaction. while hsm_secret could be encrypted the decrypted version would have to be in main memory and could be found with a full memory dump. there are not too many variables to check in a full mem copy.

I thus have the feature request to improve these issues. I understand also that on the other side it seems kind of stupid as access to the machine even if the data was encrypted would probably give access to the API and allow to close channels and transfer funds. but especially those API calls could call for decryption keys.

[darosior]

I'm not sure to understand your requests, are you asking for encrypting the database content ?
That's not necessary (from a security of the funds perspective) as a leaked lightningd.sqlite3 would only cause a privacy loss, but no loss of funds at all.

On the other hand if you are asking for a secure keystore, an (encrypted) hsm_secret is all you need since all the keys used in LN transactions are derived from it. In the same topic, the hsmtool might be worth a look too.

[ZmnSCPxj]

hsmtool is not installed by make install and it is not documented in doc/. At the minimum we should probably promote it to installation (as lightningd-hsmtool) and create a manpage for it as well.

Otherwise yes: we now have a very weak encryption of hsm_secret: when C-Lightning is started, it will prompt you for the encryption password of hsm_secret, and since it is a human-generated brain password, it is likely to have very weak encryption.

[darosior]

Ok, I'll add a manpage and add it to install.

[darosior]

a very weak encryption of hsm_secret: when C-Lightning is started, it will prompt you for the encryption password of hsm_secret, and since it is a human-generated brain password, it is likely to have very weak encryption.

@ZmnSCPxj a late reply about this, do you have an opinion on how to improve it ?

[ZmnSCPxj]

Not sure. We could mark the entire hsmd memory as non-swappable, so at least getting a dump of memory is not as easy as crashing the computer and then dding the swap partition. Note that we cannot keep the in-memory keys unencrypted, as we need it for normal operation of forwarding, which is significantly more common than channel closes, and uses the exact same keys (so any prompting for decryption passwords on channel close would be pointless, since you would have the private key decrypted in-memory just to handle channel forwards and receives and even just plain invoice generation, or even just somebody connecting to your node requires the node privkey because the Noise protocol underlying the encrypted communications tunnel uses ECDHs). In any case, if we can solve the issues of how an HSM could plausibly sign for a Lightning node while also plausibly having it be at least a little secure, we can probably reuse those solutions with the software hsmd and just add some OS-level isolation.