<div dir="ltr">Agreed, that's a good service for the signer to provide to the node.  A few further thoughts:<div><br></div><div>- The backup should be per-channel, so that an update of the backup on a channel state change is O(1)</div><div>- 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.</div><div>- 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.</div><div>- hsmd could use ECIES for encryption instead of rolling our own scheme, and the key can be derived from the seed as you say</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 13, 2019 at 2:12 AM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning devrandom,<br>
<br>
This is indeed the approach desired, and the reason why `hsmd` exists in the first place.<br>
The name `hsmd` means "Hardware Security Module Daemon".<br>
<br>
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`.<br>
<br>
One feature that we find desirable would be remote backup of Lightning node state, i.e. `db_write` hooks.<br>
Obviously, the remote backups must be encrypted.<br>
<br>
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.<br>
<br>
If instead we encrypted the remote state backup using an asymmetric encryption requiring only the `hsmd` public key, that would be significantly better.<br>
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.<br>
<br>
Obviously this requires an additional hook in the `hsmd` implementation.<br>
At minimum, this would require the ability to decrypt based on the `hsmd` secret plus an encryption nonce of some sort.<br>
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.<br>
<br>
* At encryption (done by node software):<br>
  * Generate random scalar `r`.<br>
  * Get `hsmd` public key `P`.<br>
  * Multiply scalar with pubkey `r * P`.<br>
  * Pass `r * P` through a hash function to generate a symmetric encryption key `k`.<br>
  * Use symmetric encryption.<br>
  * Store encrypted blob, as well as the random scalar times standard generator point G `r * G`.<br>
* At decryption (done at least partly by `hsmd` or equivalent hardware):<br>
  * Get the `r * G` and multiply it with our secret `p`, `p * r * G`.<br>
  * Pass it through a hash function to generate a symmetric encryption key `k`.<br>
  * Use symmetric decryption.<br>
<br>
At minimum the `hsmd` should provide the symmetric encryption key `k`, as it is the node software that will handle the Lightning state anyway.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
> Hi all,<br>
><br>
> 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.<br>
><br>
> We wrote an article about this idea here: <a href="https://medium.com/@devrandom/securing-lightning-nodes-39410747734b" rel="noreferrer" target="_blank">https://medium.com/@devrandom/securing-lightning-nodes-39410747734b</a><br>
><br>
> 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.<br>
><br>
> More about the PoC, with pointers to the software, is available here: <a href="https://gitlab.com/ksedgwic/liposig/wikis/Lightning-Policy-Signing-PoC" rel="noreferrer" target="_blank">https://gitlab.com/ksedgwic/liposig/wikis/Lightning-Policy-Signing-PoC</a><br>
><br>
> 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.<br>
</blockquote></div>