[c-lightning] Channel Secrets

[Christian Decker]

ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Channels maintain a set of secrets (revocation, htlc, commitment
> etc). Currently these are encoded as a PRNG seed, kept in a cleartext
> blob in the database.  In particular, we also share the secret seed to
> `channeld`.

Since we are using encryption keys at a variety of levels, all generated
from the `hsm_secret`, we should probably start by categorizing them:

 - Channel level secrets, like the one you mention, revocation,
   commitment, etc, but without the HTLC secrets
 - Multi-hop secrets such as the HTLC preimages, and onion shared
   secrets
 - Communication secrets such as the transport layer encryption and
   signature secrets.

> It would be best if the secrets are not shared in cleartext to a
> daemon that communicate directly with the network: as
> defense-in-depth, we should ensure that `hsmd` holds the secrets.
> Another design consideration is that the `hsmd` might someday be
> implemented as a hardware module, which might impose limits on the
> amount of data it can store (i.e. the PC might be able to handle
> thousands of channels, but the hardware module might not).

IMHO this makes absolute sense for the channel-level secrets, which
would enable a direct theft, but not for communication secrets (having
to pass every packet to the hsmd before sending them to the peer means
we could just have hsmd handle the connections themselves). I'm not so
sure about the multi-hop secrets, but I tend towards having them not hsm
secured just because of simplicity.

> So I propose the below design instead:
>
> 1.  The channel seed is stored encrypted in the database.
> 2.  The decryption key is the HSM secret.  It could be a simple XOR
> with the channel seed, or we could load the HSM secret into a ChaCha20
> PRNG and XOR the result with the channel seed.

Since we have the HKDF functionality in the HSM anyway, I'd definitely
generate a separate obfuscation secret using that. It only needs to be
generated once on startup, and it avoids accidentally leaking the hsm
secret.

> 3.  The `channeld` is given the encrypted form of the channel seed
> (and indeed all of the software other than `hsmd` cannot get anything
> other than the encrypted channel seed).
> 4.  The `channeld` is given a capability to request HSM to sign using
> a encrypted channel seed.  It passes in the encrypted channel seed and
> the message to sign.  This means the HSM does not have to store the
> channel-level secrets on a permanent basis (reducing the amount of
> memory the hardware module needs to implement).  The same capability
> also allows deriving and returning a revocation key.
> 5.  When a new channel is created, we could just generate a random
> number and expect it to get decrypted to a corresponding decrypted
> random seed by the HSM.  This lets a hardware module not have to
> implement an entropy source (although a good hardware entropy source
> from resistor noise or similar could be used, and anyway how does the
> hardware module create the starting HSM secret anyway?).