Re: [Lightning-dev] Blind Signing Considered Harmful
Good morning devrandom, It seems to me that a true validating Lightning signer would need to be a Bitcoin node with active mitigation against eclipse attacks, the ability to monitor the blockheight, and the ability to broadcast transactions. Otherwise, a compromised node can lie and tell the signer that the block height is much lower than it really is, letting the node peers clawback incoming HTLCs and claim outgoing HTLCs, leading to a net loss of funds in the forwarding case. Looking at the link, it seems to me that you have a "UTXO Set Oracle", does this inform your `lightning-signer` about block height and facilitate transaction broadcast? Is this intended to be a remote device from the `lightning-signer` device? If so, what happens if the connection between the "UTXO Set Oracle" remote device and the `lightning-signer` is interrupted? In particular: * Incoming forward arrives. * Compromised node accepts the incoming HTLC and offers outgoing HTLC. * Presumably the `lightning-signer` signs off on this, as long as the outgoing HTLC is of lower value etc etc. * Compromised node stops communicating with the `lightning-signer`. * Outgoing HTLC times out, but compromised node and the outgoing peer do nothing. * Incoming HTLC times out, and the incoming peer unilaterally closes the channel, claiming the timelock branch of the HTLC onchain. * Outgoing peer unilaterally closes the channel, claiming the hashlock branch of the outgoing HTLC onchain. Unless the `lightning-signer` unilaterally closes the channel when the outgoing HTLC times out and actively signs and broadcasts the timelock branch for the outgoing HTLC, then this leads to funds loss. This requires that the `lightning-signer` be attached to a Bitcoin node that is capable of: * Actively finding and connecting to multiple Bitcoin peers. * Actively checking the block header chain (acceptable at only SPV security since you really only care about blockheight, and have a UTOX Set Oracle which upgrades the rest of your security from SPV to full?). * Actively broadcasting unilateral closes and HTLC timelock claims for outgoing HTLCs. Is that how `lightning-signer` is designed? This seems to be listed in: https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits > an HTLC is failed and removed on the input before it is removed on the > output. The output is then claimed by the counterparty, losing that amount Is there a mitigation, planned or implemented, against this exploit? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Blind Signing Considered Harmful
( a formatted version of this message is here: https://gitlab.com/lightning-signer/docs/-/wikis/Blind%20Signing%20Considered%20Harmful ) # Introduction This post discusses blind signers. Blind signers do not put the user in control of their funds and are subject to a long list of exploits. This post also (re-)introduces the open-source [Validating Lightning Signer](https://gitlab.com/lightning-signer/docs/-/blob/master/README.md) Project. # Background A **Signer** is a component that performs cryptographic operations, separately from a wallet. A Bitcoin hardware wallet is an example of a Signer, where private keys are controlled on a hardened device. There is currently no complete solution for a hardware signer for the Lightning network. A **Blind Signer** is a signer that does not perform validation. There are several Lightning wallets and node implementations that as of today support only blind signing. I believe these configurations are insecure. A **Validating Signer** performs a comprehensive set of policy checks to ensure that the keys are not misused. For example, a validating Bitcoin hardware wallet checks the destination, amount and change outputs in collaboration with the user. A layer-2 validating signer is significantly more complex, because of the complexity of the Lightning protocol. **While a Blind Signer is a technical step on the road to the higher security of a Validating Signer, by itself it actually reduces security if deployed in production. This is because it presents two points of attack - at the node and at the signer.** # The VLS Project The [Validating Lightning Signer]( https://gitlab.com/lightning-signer/docs/-/blob/master/README.md) project aims to close the gap for securing the Lightning ecosystem. It is an open-source Rust library and reference implementation. The project is approaching Beta, which is the point where the main goal will be met: funds are safe even if the node is completely compromised. The task is relatively complex because of the complexity of the Lightning protocol. There are more than [50 policies]( https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md) that must be enforced, and many of them require stateful inspection of the protocol. Both servers and consumer devices are targeted, the latter via a Rust `no_std` compilation mode. # Signing Configurations Here are some of the potential configurations of a Lightning node: * Monolithic node * Node with a separate Blind Signer * Node with a separate Validating Signer - the signer ensures that the Lightning state machine ran correctly and funds are not at risk # The (In)security of Blind Signing  * The monolithic case has one point of attack - at the node. * The blind signing case has **two points of attack** - at the node and at the Signer. A blind signer will perform any signing operation the node requests, so **a compromised node will still result in loss of funds**. And obviously, a compromised signer will also result in loss of funds. This is worse than a monolithic node because funds can be lost if **either** is compromised. * The validated signing case has just one point of attack with a small attack surface # Wallets with Blind Signers Must Trust the Node Operator Blind signing wallets where the node is run by an LSP (Lightning Service Provider) are not self-custodial because the LSP can unilaterally control the funds. The LSP merely has to provide the Signer with a transaction that sends the funds to the LSP or another destination. # Examples of Blind Signing Exploits A compromised node can unilaterally submit transactions to be signed by the blind Signer. The following can result in the funds being stolen: * The node submits a mutual closing transaction which sends funds to the attacker's address * The node asks the blind signer to sign a revoked transaction which will cause loss of all funds when published * And many more ... A compromised node can also lose funds when it doesn't follow the Lightning protocol. Some potential exploits include: * The node fails to validate the counter-party's revocation, and the counter-party broadcasts an old commitment transaction that sends most of the funds to the counter-party * The node fails to claim input HTLCs when routing payments, leading to the gradual loss of all funds * And many more ... # Validating Signers In the Validating Signer case, a compromise of the Lightning node will not result in the loss of funds. The security of such a setup is only dependent on the security of the Signer. The Signer can be hardened as needed for the specific use case. Some of the validation rules that a validated Signer can implement include: - Don't sign a revoked commitment transaction - Don't revoke a signed commitment transaction - Don't close a channel to an unapproved destination - Routed payments must have at least a
