Hi all,
Since starting to hack on LDK, I’ve been interested in running some components of a Lightning node in a dedicated hardware environment, in the image of what is done by the smart card industry. We have been doing a bunch of refactoring in that sense early on to isolate our signing operations [0]. Building on top of this generic signing interface, the Validating Lightning Signer has been growing into a mature Lightning signer during the past years, performing a comprehensive set of policy checks to ensure the keys are not misused [1]. The module development is advanced enough to be functional with both deployment of LDK and CLN nodes (waiting internal refactoring by other implementations for eventual support). During the past months, in cooperation with the VLS project team, I’ve done a third-party security audit of VLS core mechanisms, evaluating its state of readiness for production by the community of Lightning node operators. The critical vulnerabilities and attacks vectors found are the following: - The legacy `option_anchor_outputs` is accepted by the Signer, there is no protection against channel opening downgrades to unsafe channel type. This opens the way to the known fee siphoning attack capturing almost all channel value in function of capacity [2]. - The Signer does not enforce an upper bound on the sum of trimmed HTLC as miner fees. This opens the way to the known dust inflate attack capturing a minority of channel value if the adversary has low-hashrate capabilities [3]. - There is a lack of a `policy-cltv-delta-reasonable` rule for routing hops. There is no enforcement of a reasonable `cltv_expiry_delta` between inbound HTLC and outbound HTLC, where reasonable is defined according to the BOLT2’s `cltv_expiry_delta` selection recommendations [4]. This opens the way to HTLC-double-spend attack where up to `max_htlc_value_in_flight_msat` of channel value can be captured. - There is a lack of verification of `nLocktime` field soundness of the HTLC-timeout at counterparty signature reception. This opens the way to HTLC value freezing or double-spend in function of the deployment - There is a lack of rejection of non-Segwit input for the funding transaction. This opens the way to known freezing of full channel value by the counterparty [5]. - The Signer is suffering from high-exposure to a fee-siphoning attack by an adversary with minimal hashrate capabilities (i.e 1 block without time boundary). Both funding/commitment transactions weights and feerate can be inflated to increase the absolute fee signed. Beyond that, there are still missing not-implemented critical policy rules and the invoices and payments flows are still hardened with a consistent security model. Those issues were known by the project. The issues have been communicated to the VLS team ahead of the report publication and they’re committed to address them. The full audit report can be found here: https://github.com/ariard/validating-lightning-signer/blob/main/VLS-audit-v0.2.pdf In the future, as the LN ecosystem matures, extended policies are expected to be introduced covering the variety of LN use-cases: merchant, mobile, routing nodes, LSP, where the policy set of rules could bind to the application logic. E.g as BOLT12 offers to introduce a richer semantic on payment protocol, the request structure could be enforced by the VLS [6]. Moreover, other data flows could be submitted to VLS to detect anomalies, such as the historical mempools data in a compressed way. Beyond Lightning node security, the VLS architecture could be generalized to other Bitcoin contracting protocols (e.g vaults), where spending policies are also leveraged to introduce fine-grained control of custodied Bitcoin funds between cold and warm wallets. Cheers, Antoine [0] https://github.com/lightningdevkit/rust-lightning/pull/214 [1] https://vls.tech [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html> [4] https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection [5] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#user-content-Trustfree_unconfirmed_transaction_dependency_chain [6] http://bolt12.org
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
