Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-09 📝 Original message: ( a formatted version of ...
📅 Original date posted:2022-05-09
📝 Original message:
( 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 as much input as output value
- Payments must claim at least as much from the input as was claimed from
us on the output
- And many more ...
# Conclusion
Blind signers reduce the security of Lightning nodes and are subject to
[many exploits](
https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits).
Validating signers improve security by reducing the attack surface. The VLS
project aims to provide a library and reference implementation for
enterprise servers and consumer devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220509/95d3c85d/attachment.html>;
📝 Original message:
( 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 as much input as output value
- Payments must claim at least as much from the input as was claimed from
us on the output
- And many more ...
# Conclusion
Blind signers reduce the security of Lightning nodes and are subject to
[many exploits](
https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits).
Validating signers improve security by reducing the attack surface. The VLS
project aims to provide a library and reference implementation for
enterprise servers and consumer devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220509/95d3c85d/attachment.html>;