[c-lightning] Policy signer PoC

[Devrandom]

Agreed, that's a good service for the signer to provide to the node.  A few
further thoughts:

- The backup should be per-channel, so that an update of the backup on a
channel state change is O(1)
- The signer should have its own signed backup in case the node is
compromised.  There will probably be a need to reconcile the state of the
node and the signer - i.e. the last state change should be replayed if
necessary.
- It seems that the communication channel between the node and the signer
should already be encrypted and authenticated for privacy.  Therefore the
only encryption needed is for the backup at rest.  In that case, I would
have the hsmd process encrypt internally - the node doesn't have to worry
about it.
- hsmd could use ECIES for encryption instead of rolling our own scheme,
and the key can be derived from the seed as you say

On Fri, Dec 13, 2019 at 2:12 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/c-lightning/attachments/20191215/e6cd201b/attachment.htm>