[In collaboration with Ken Sedgwick.]
Lightning is a second layer p2p payment system built on top of Bitcoin. Lightning can greatly increase the throughput of Bitcoin payments and can reduce fees. However, it also presents a security challenge, since Lightning nodes are in effect hot wallets.
Best practices for securing regular hot wallets includes using a secure element (e.g. an HSM) and using multi-signature transactions. We present a way to apply these practices to Lightning nodes.
Since Lightning requires specific scripts formats, threshold signatures must be used instead of multi-signatures.
Possible Attacks
Here are some of the possible attacks on a lightning node. An attacker that compromises our node can:
- with the “payment basepoint” key, the attacker can steal our funds in a channel
- with HTLC and node identity keys, the attacker can send payments to a node it controls on the lightning network
An attacker that can connect to you or compromise your peer can perform additional attacks:
- with the “funding basepoint” key, the attacker can steal our funds in the channel
- if a channel funding UTXO is not active, but we allow incoming routed payments through that channel, our funds in the output channel can be siphoned off
Security Approach
In order to protect a lightning node we have to do the following:
- protect keys from theft — if keys are stolen, the attacker controls the funds
- protect keys from misuse — if the attacker can get an arbitrary transaction signed, they can still move the funds away, even if they don’t access the keys directly
- Remove single points of security failure
In order to achieve the above, we believe the following approach is required:
- private keys should be held in secure elements (e.g. HSMs)
- the secure element must implement policy controls in order to prevent misuse of the keys
- multiple secure elements should be used in a threshold signature scheme (TSS or sometimes “MPC”), so that there is no single point of failure
- a collection of UTXO oracles, to be able to provide proof-of-existence for channel funding UTXOs
One TSS approach is available for ECDSA from KZen Networks. Schnorr signatures have a simpler and easier to analyze threshold scheme named MuSig.
Additional, lightning specific approaches can be used, such as using a Loop-Out mechanism to reduce the size of the channel or creating channels only to trusted parties.
Policy Controls
Here are some of the checks that should be implemented in the secure element to prevent theft:
- Funding transaction must output to the funding key
- Commitment transaction must spend from funding key and to payment keys
- Sweep of funds from payment keys must spend to a whitelist (e.g. cold wallet)
- For a routing hub, payments must only be routed, never initiated (but see also Loop-Out)
- Proof of the input channel funding UTXO should be provided to the secure element when routing payments
Notes
- The secure elements must maintain state for each channel. The actual storage can be outside the secure element and protected via a Merkle tree covering the stored items. The secure element only needs to securely store the new Merkle tree root in its protected non-volatile memory as it updates data items.
- The UTXO oracles are third-party oracles that provide a UTXO state commitment service. This commitment is available by consensus in some chains, but not in Bitcoin.
