{"type":"rich","version":"1.0","author_name":"npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8n","author_url":"https://nostr.ae/npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-09\n📝 Original message:\n( a formatted version of this message is here:\nhttps://gitlab.com/lightning-signer/docs/-/wikis/Blind%20Signing%20Considered%20Harmful\n)\n\n# Introduction\n\nThis post discusses blind signers.  Blind signers do not put the user in\ncontrol of their funds and are subject to a long list of exploits.\n\nThis post also (re-)introduces the open-source [Validating Lightning\nSigner](https://gitlab.com/lightning-signer/docs/-/blob/master/README.md)\nProject.\n\n# Background\n\nA **Signer** is a component that performs cryptographic operations,\nseparately from a wallet. A Bitcoin hardware wallet is an example of a\nSigner, where private keys are controlled on a hardened device. There is\ncurrently no complete solution for a hardware signer for the Lightning\nnetwork.\n\nA **Blind Signer** is a signer that does not perform validation. There are\nseveral Lightning wallets and node implementations that as of today support\nonly blind signing. I believe these configurations are insecure.\n\nA **Validating Signer** performs a comprehensive set of policy checks to\nensure that the keys are not misused. For example, a validating Bitcoin\nhardware wallet checks the destination, amount and change outputs in\ncollaboration with the user.\n\nA layer-2 validating signer is significantly more complex, because of the\ncomplexity of the Lightning protocol.\n\n**While a Blind Signer is a technical step on the road to the higher\nsecurity of a Validating Signer, by itself it actually reduces security if\ndeployed in production. This is because it presents two points of attack -\nat the node and at the signer.**\n\n# The VLS Project\n\nThe [Validating Lightning Signer](\nhttps://gitlab.com/lightning-signer/docs/-/blob/master/README.md) project\naims to close the gap for securing the Lightning ecosystem. It is an\nopen-source Rust library and reference implementation. The project is\napproaching Beta, which is the point where the main goal will be met: funds\nare safe even if the node is completely compromised.\n\nThe task is relatively complex because of the complexity of the Lightning\nprotocol. There are more than [50 policies](\nhttps://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md)\nthat must be enforced, and many of them require stateful inspection of the\nprotocol.\n\nBoth servers and consumer devices are targeted, the latter via a Rust\n`no_std` compilation mode.\n\n# Signing Configurations\n\nHere are some of the potential configurations of a Lightning node:\n\n* Monolithic node\n* Node with a separate Blind Signer\n* Node with a separate Validating Signer - the signer ensures that the\nLightning state machine ran correctly and funds are not at risk\n\n# The (In)security of Blind Signing\n\n![blind-signing-diagram-1.svg](uploads/78db1bd2b59228492e09ea272c873cf3/blind-signing-diagram-1.svg)\n\n* The monolithic case has one point of attack - at the node.\n* The blind signing case has **two points of attack** - at the node and at\nthe Signer. A blind signer will perform any signing operation the node\nrequests, so **a compromised node will still result in loss of funds**. And\nobviously, a compromised signer will also result in loss of funds. This is\nworse than a monolithic node because funds can be lost if **either** is\ncompromised.\n* The validated signing case has just one point of attack with a small\nattack surface\n\n# Wallets with Blind Signers Must Trust the Node Operator\n\nBlind signing wallets where the node is run by an LSP (Lightning Service\nProvider) are not self-custodial because the LSP can unilaterally control\nthe funds. The LSP merely has to provide the Signer with a transaction that\nsends the funds to the LSP or another destination.\n\n# Examples of Blind Signing Exploits\n\nA compromised node can unilaterally submit transactions to be signed by the\nblind Signer.  The following can result in the funds being stolen:\n\n* The node submits a mutual closing transaction which sends funds to the\nattacker's address\n* The node asks the blind signer to sign a revoked transaction which will\ncause loss of all funds when published\n* And many more ...\n\nA compromised node can also lose funds when it doesn't follow the Lightning\nprotocol. Some potential exploits include:\n\n* The node fails to validate the counter-party's revocation, and the\ncounter-party broadcasts an old commitment transaction that sends most of\nthe funds to the counter-party\n* The node fails to claim input HTLCs when routing payments, leading to the\ngradual loss of all funds\n* And many more ...\n\n# Validating Signers\n\nIn the Validating Signer case, a compromise of the Lightning node will not\nresult in the loss of funds. The security of such a setup is only dependent\non the security of the Signer. The Signer can be hardened as needed for the\nspecific use case.\n\nSome of the validation rules that a validated Signer can implement include:\n\n- Don't sign a revoked commitment transaction\n- Don't revoke a signed commitment transaction\n- Don't close a channel to an unapproved destination\n- Routed payments must have at least as much input as output value\n- Payments must claim at least as much from the input as was claimed from\nus on the output\n- And many more ...\n\n# Conclusion\n\nBlind signers reduce the security of Lightning nodes and are subject to\n[many exploits](\nhttps://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits).\n\nValidating signers improve security by reducing the attack surface. The VLS\nproject aims to provide a library and reference implementation for\nenterprise servers and consumer devices.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220509/95d3c85d/attachment.html\u003e"}