[c-lightning] Policy signer PoC

[ZmnSCPxj]

Good morning devrandom,

This is indeed the approach desired, and the reason why `hsmd` exists in the first place.
The name `hsmd` means "Hardware Security Module Daemon".

I have not checked any of your links in detail, however one thing I would like to implement would be asymmetric decryption using the public key of the `hsmd`.

One feature that we find desirable would be remote backup of Lightning node state, i.e. `db_write` hooks.
Obviously, the remote backups must be encrypted.

If the decryption key for the remote state backup is kept separately from the `hsmd` secret, then we have the issue that we need to backup the seed for both the `hsmd` secret, and the decryption key for the remote state backup.

If instead we encrypted the remote state backup using an asymmetric encryption requiring only the `hsmd` public key, that would be significantly better.
That would require only a backup of the `hsmd` secret, and in combination with the remote state backup, a full backup of the Lightning node state.

Obviously this requires an additional hook in the `hsmd` implementation.
At minimum, this would require the ability to decrypt based on the `hsmd` secret plus an encryption nonce of some sort.
If we use ECDH to power a symmetric encryption, the encryption nonce would be a point, which when multiplied with the `hsmd` secret creates a symmetric cipher key.

* At encryption (done by node software):
  * Generate random scalar `r`.
  * Get `hsmd` public key `P`.
  * Multiply scalar with pubkey `r * P`.
  * Pass `r * P` through a hash function to generate a symmetric encryption key `k`.
  * Use symmetric encryption.
  * Store encrypted blob, as well as the random scalar times standard generator point G `r * G`.
* At decryption (done at least partly by `hsmd` or equivalent hardware):
  * Get the `r * G` and multiply it with our secret `p`, `p * r * G`.
  * Pass it through a hash function to generate a symmetric encryption key `k`.
  * Use symmetric decryption.

At minimum the `hsmd` should provide the symmetric encryption key `k`, as it is the node software that will handle the Lightning state anyway.

Regards,
ZmnSCPxj

> Hi all,
>
> Ken Sedgwick and I have been looking at securing Lightning nodes.  Our goal is to extract the signing operation (and other secret handling) to a policy signer, which can then be implemented in a dedicated hardware device - such as a secure element.  The policy signer would be able to defend against theft even if the node itself is completely compromised.
>
> We wrote an article about this idea here: https://medium.com/@devrandom/securing-lightning-nodes-39410747734b
>
> We also implemented a proof-of-concept.  The PoC is currently based on c-lightning, because the hsmd abstraction in that implementation is very suitable for this purpose.
>
> More about the PoC, with pointers to the software, is available here: https://gitlab.com/ksedgwic/liposig/wikis/Lightning-Policy-Signing-PoC
>
> We would like your feedback about this approach. We'd like to complete this reference implementation and create the relevant hooks in major Lightning implementations.  This way policy signer implementations could be created for different target hardware and integrated with node software.