Lightning 101 For Exchanges: Security Part 3 – Private Key Management

  • posted by Chris Stewart
  • No Comments

This is the sixth post in our “Lightning 101 for Exchanges” blog series. In this post we explore private key management and some of the considerations and nuances required for security.

Lightning For Exchanges Series

  1. Overview
  2. Regulation Part 1 — Money Transmitter Rules
  3. Regulation Part 2 — Money Transmitter Rules
  4. Security Part 2 – Backing Up Your Lightning Wallet
  5. Security Part 3 – Private Key Management
  6. User Experience – Liquidity
  7. Managing Fees With Lightning
  8. Routing Nodes
  9. Conclusion

Lightning has different types of private keys when compared to blockchain protocols. Since Lightning is a “layer 2” protocol, we have to consider managing the private keys that control funds on the blockchain and keys that control funds on Lightning.  A common security policy that exchange operator’s use for on chain funds is a “hot” and “cold” key policy. It is encouraged to keep as many funds as possible secured by cold keys rather than hot keys. In this blog post we apply this security policy to the private keys that are introduced with Lightning. We talk about messages that are used on the Lightning protocol and keys that are associated with those messages. Finally we determine if a private key can be “hot” or “cold”, and the funds that an attacker can steal if the key is compromised.

Opening a channel

The first messages exchanged in the Lightning protocol is “open_channel” and “accept_channel” messages. These two messages negotiate initial parameters for our Lightning channel. Inside of the “open_channel” and “accept_channel” messages there are 6 public keys transmitted. In the next section we are going designate if a key must be hot or cold, and what funds can be stolen if the key is compromised

  1. Funding private key (funding_pubkey)
    1. must be hot
    2. If your counterparty can get access to this key, they can steal all funds immediately
    3. If a third party gets access to this key, they need to collude with your counterparty to steal funds 
  2. Revocation_basepoint_secret  (revocation_basepoint)
    1. Can be cold, as long as you can access the key to claim the funds before your peer’s to_self_delay is expired
    2. Needed to claim peer’s funds if a revoked commitment transaction is published
    3. If your counterparty can get access to this key, they immediately claim money in their to_local output as they know their per_commitment_secret
    4. More generally, your counterparty can publish any favorable old state for themselves and immediately claim the money in their to_local output. You can attempt to claim that money immediately too. This will devolve down to a race of who gets confirmed first on the blockchain.
  3. Payment_basepoint_secret (payment_basepoint)
    1. Can be cold
    2. The private key that allows you to claim money from the to_remote output on you peer’s commitment transaction.
    3. If your peer gets access to this key, they can claim funds immediately from your to_remote output as they know per_commitment_secret. This means your peer can take all of your money in the channel.
    4. If an attacker gets access to this key, along with your peer’s per_commitment_secret, they can take money from your to_remote output on your peer’s commitment transaction. This means the attacker can take all of your money in the channel
  4. delayed_payment_basepoint_secret (delayed_payment_basepoint)
    1. Can be cold
    2. The private key that allows you to claim money in the to_local output on your local commitment transaction
    3. If an attacker gets access to this key, along with per_commitment_secret, they can claim the funds in the to_local output on your local commitment transaction. This means they can take all of your money in the channel when a transaction hits the blockchain
  5. Htlc_basepoint_secret (htlc_basepoint)
    1. Must be hot
    2. A signature needs to be provided in “commitment_signed” message for these htlcs
    3. When offering an htlc, if an attacker gets access to
      1. Htlc_basepoint_secret AND per_commitment_secret, they can claim funds in the htlc after cltv_expiry
    4. When receiving an htlc, if an attacker gets access to
      1. Htlc_basepoint_secret AND the payment pre-image AND per_commitment_secret they can race you to claim funds on chain.
  6. First per commitment private key (first_per_commitment_point
    1. Must be hot
    2. Used to generate `local_pubkey` and `remote_pubkey` for the first commitment tx
    3. If your counterparty finds this key, they can steal all of your money on your commitment transaction as they can derive their revocationprivkey
    4. If an attacker finds this key, and compromises your counter parties’ “revocation_basepoint_secret”, then they can steal all of your money in the outputs on your commitment transaction.

The “funding_pubkey” is the key that controls the output that is on the funding transaction on the blockchain. This output is a 2 of 2 p2wsh multisig script where your counterparty on Lighting controls the other key. This key needs to be very hot, as you need to sign new commitment transactions often with this key. Every time a “commitment_signed” message is sent, the digital signature in this message is created with the private key that corresponds to “funding_pubkey”.

The “funder” of the lightning channel needs to select a utxo that they own in their wallet to act as collateral for the channel. After the funder has selected this utxo, they must send over a “funding_created” message. This “funding_created” message implies that the funder is “holding” a signed funding transaction that has not been broadcast yet. Your HSM will need to provide a digital signature for this funding transaction and the transaction will need to be broadcast AFTER you receive a “funding_signed” message.

We believe that you may be able to execute this process offline if you are peering with someone you know. This would allow you to keep “cold channels” that you can broadcast when extra liquidity is needed, but keeps the key that is funding these channels offline. We will explore this in a blog post in the future.

Normal channel operations

There are two messages that require interactions with private keys during normal operations of a Lightning channel.  The first message is “commitment_signed”. There are two types of signatures that relayed in a commitment signed message:

  1. Funding private key (funding_pubkey)
    1. This is the same secret mentioned in the “funding private key” section above
  2. htlc_basepoint_secret (htlc_basepoint)
    1. This is the same secret mentioned in the “htlc_basepoint_secret” section above

The second message is “revoke_and_ack”. We’ve previously detailed how revoke_and_ack works. This is for the case when we are sending a “revoke_and_ack” message.

  1. Per_commitment_secret (per_commitment_point)
    1. Must be hot
    2. This is how you tell your peer you have irrevocably committed to the new commitment transaction.
    3. This key is ephemeral

In short, no new hot keys are introduced during normal channel operations besides per_commitment_secret. The largest risks of losing funds during normal channel operations is accidentally publishing a revoked state, and having the funding private key compromised.

As we have talked about in previous blog posts, “per_commitment_secret” has a unique security model. It must be kept ultra secretive for a short period of time while peers exchange “commitment_signed” messages. Then you reveal it to your peer and want to purge it from your system.

It is important to remember that you must store the “per_commitment_secret” that your peer sends to you via “revoke_and_ack” for the lifetime of the channel. This data is required in order to punish your peer if they are cheating.

Closing a channel

A channel is closed when the funder of the channel sends the “shutdown” message. The scriptpubkey specified in the shutdown message can be a cold storage script. This means when closing your channel, funds will be directly transferred into cold storage.

When opening a channel, you can optionally specify a “shutdown_scriptpubkey” value that indicates where you want funds sent when the channel closes. It is best practice to specify this if you want to transfer funds into cold storage.

During fee negotiations, the funding private key needs to be able to sign multiple closing transactions while you and your peer are agreeing to what a reasonable fee rate is.

Finally, a digital signature needs to be created with the “funding_privatekey” that is sent in the “closed_signed” message. This spends the funds from the funding output into the scripts specified in the “shutdown” message.

The corresponding bitcoin transaction is issued to the blockchain after fee negotiation is completed. You may need to sign the transaction multiple times during the fee negotiation process.

Conclusion

We have enumerated all sensitive keys that are used in BOLT2 and BOLT3. We have classified them as “hot” or “cold” keys. We have also detailed what an attacker can steal from you if they can compromise certain keys.

At Suredbits, we believe a comprehensive key management solution is needed for Lightning for exchange adoption and are investigating ways to accomplish this so users can safely transact over the Lightning Network.

If you’re interested in chatting more about Lightning Network technology or crypto tech in general, you can find us on Twitter @Suredbits or join our Suredbits Slack community.

If you are an exchange or interested in what Lightning can do for you and your business, contact us at [email protected].

You can also reach us on the Lightning Network:

038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com.