Hey Zeeman, tl;dr A LN node paired with an external signer can be distrusted and LN funds be safe in any case if signer is connected to a N-set of watchtowers and at least one of them is non-compromised.
Thanks for this interesting post, I was thinking about LN hardware wallets support for a while too, I do think LN model has its own pitfalls compare to base layer but that doesn't mean we can't substantially improve current one monolithic-LN-node-with-unsafe-key-material-in-RAM deployment and still have automatic processing of HTLCs. LN security model differs compare to base layer by requiring onchain monitoring and reaction to keep your funds safe. That's quite the contrary on how HW have been designed until now where UTXO state access isn't assumed to be secure. That's said the cool thing is you may have multiple monitoring bckends/watchtowers running on different infrastructures, if one of them stay non-compromised and enforce protocol rules you should be fine [0]. So let's go through whole LN operations with a deployment such that Alice the LN processing node, Bob and Caroll the channel peers, Sally the external signer, Will a set of N watchtowers. Will is part of the same entity than Alice, run on different infra, is seeded with same secret (to derive same local keys), and have authenticated communication with Sally. Attacks scenario are 1) node compromised, where an attacker would leverage secret keys to sign closing/justice/sweep transaftions to a attacker-controlled address. 2) node compromised + peer collusion, where an attacker broadcast revoked commitment/non-revoked commitment with a HTLC to timeout/obtain a commitment with outgoing HTLC but not incoming one. >From the perspective of signer, you can't dissociate peer collusion so it should always be assumed and the straighter policy enforced. Alice inits Sally with 2 funding_transactions+remote_sigs+per_commitment_point+balances states, for both link AB and AC. Balance states have to be user-input validated (or can be deduced if Sally is also an onchain wallet and fundings spent from controlled-keys modulo push_msat max being hardcoded). Sally send to Will these requests through Alice. When Will see fundings confirmed it replies the computed channel_id to Sally and stores sigs, who then can safely considers these channels activated. Bob initiates a payment to Caroll through link AB+AC, Alice receives the messages and ask Sally to sign Bob's remote, as it's a balance increases, no proof is asked. Sally send to Will vector of HTLCs (hash+locktime)+previous_state revocation secret+per_commitment_point. Will can return Sally an error if locktime are in the past of channel has been closed so Sally won't accept latter outgoing HTLC paired with such incoming channel. If a revoked commitment is broadcast on AB and Alice is compromised, Will generate justice transactions and take the funds back. Alice builds outgoing payment and asks Sally to sign outgoing commitment decreasing local balance with incoming HTLC as a proof. Sally can send Will the new outgoing commitment tied with HTLC proof, if HTLC proof can't be tied to an incoming valid chan, an error should be returned to Sally and signature aborted. At HTLC fulfillement by Caroll, Alice should pass the preimage to Caroll who pass it to Will. If Alice is compromised, Will be able to claim incoming HTLC. Will should also be able to parse onchain HTLCs and extract preimage to claim backward in case of Alice withholding the preimage. At any block reception, Will should be able to broadcast commitment and timeout HTLCs in case of Alice being unreliable/compromised. To avoid burning-to-fees attack, if Alice asks Sally to sign a decrasing-balance commitment without a HTLC proof, which is credible for update_fee, fees can be bounded to some value. Bounds should scope dust HTLCs too. At channel closing, Will can observe it, if Sally ask to valid any HTLC proof, return an error. External signer should store commitment numbers and balances for each channel and do key derivation locally (at least for local, for remote you can't trust provided per_commitment_point anyway). Voila, I think this describes a master-slaves scheme, where external signer is coupled with watchtowers to serve as UTXO oracles, while mitigating node compromised. It would be fairly complex to design and implement it right but on the long-term it's worth it if you assume a world of wumbo channels and mutiple-btcs HTLCs [1] Devrandom work is a pretty headstart towards such safe API and we should keep experimenting with this to patch unthought corner-cases. The futur alternative is every HW vendor designing its LN-implementation specific support, and a lot of them being flawed by missing LN security model oddities. A lack of such standard programming interface on base layer HW and the number of vuln due to mishandling change or derivation is something to meditate on. > It would have to be a sophisticated threshold: a corrupted software would split up the node funds into tiny 546-satoshi channels, paying a funding tx fee each time. > I suppose when considering autopilot it would have to be auto-approved though. A signer can implement further checks to asses channel opening utility. Like a channels provider signer would verify than no more than X channels with Y liquidity are opened on time period Z. And you may ask for a user invoice signed by a different component than your LN node. > > It cannot identify using the hash, incidentally: it is theoretically possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> E -> C -> F, where C appears twice. If you store latest HTLC outputs on the watchtower, at incoming link update, if there is discrepancy between stored set and submitted by node set, something is wrong. Further, hash replay isn't safe right now : https://eprint.iacr.org/2019/1149.pdf > So you would need a more sophisticated watchtower design as well. In most watchtowers discussion, it's only assumed to do justice delegation. But if you're a routing node, that's not enough to be safe, you should also timeout HTLC and do outgoing-to-incoming preimage passing in case of regular node failure. Luckily, watchtowers aren't specified yet... > I imagine that secure of a memory would be expensive to implement and thus limited, thus if you implement it all in the hardware, you would impose limits on the number of channels and updates and so. All this discussion may be irrelevant anyway, I've heard about 10-100MB HSM with hardened Linux, so just run a minimal LN node on it but that would create a dependency on HSM vendors and there is only a few of them.. Antoine [0] Introducing watchtowers opens some problems like state must be synchronized to avoid spurious broadcast of revoked commitments and trusted external signer to avoid one of them spending to a malicious addresses. Though they provide also a security boost against p2p sybil attacks if each run its own full-node. [1] This kind of deployment may only serve important processing LN nodes first, but designing specialized hardware/interfaces for them will also benefit more thrifty nodes operators by commoditization on the long term Le mer. 15 janv. 2020 à 20:36, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > Good morning ZmnSCPxj, > > > > > > It need not store the whole state: for example, it could store just a > commitment to the current state (and have the software store the entire > state). > > > In fact, it is best for the hardware to store the signature for the > commitment transaction: > > > > I would say that's not enough, if we assume that the attacker can > > destroy the underlying data, and destroy all backups. If the attacker > > can do that, the node is at the mercy of channel partners, since they > > will be able to publish old state without the possibility of > > retaliation. Thus there needs to be a secure form of storage where at > > least one backup must be recoverable at all times within the penalty > > time window. > > Right, that does seem correct. > > > > > > [...] > > > Tr\*sted Revocation of Old Remote State > > > > > > ============================================== > > > > > > Unfortunately, the hardware has to tr\*st the software to check that > the other node is not cheating. > > > As the hardware itself is not capable of accessing the blockchain or > mempool, it cannot do this checking directly. > > > Thus, revocation of old remote state is not ensurable by the hardware. > > > > I am more optimistic about this. Publishing of penalty transactions > > can be delegated to a quorum of watchtowers, some possibly run by > > other entities. The node software can prove to the hardware that the > > watchtowers have been informed of new state by providing a receipt > > signed by the watchtowers. Thus it's possible to reduce trust in the > > node software. > > I had not thought of having the watchtower(s) sign a receipt of the > channel state being backed up there, thank you. > > > > > > As revocation can only be done by the software anyway, the revocation > secrets for the remote commitment transactions can be stored by the > software only. > > > The hardware need never learn the revocation secrets as it can do > nothing with them anyway. > > > > I would at least back up the secrets in the secure storage attached to > > the hardware store, so that the node can be recreated if the node > > software has been catastrophically compromised. > > Well, if the hardware itself has only a tiny secure storage (e.g. the > example of only being able to store a commitment to the entire state) there > would be no space to put those in as well, even with shachains. > Further, all previous HTLC hashes and timelocks need to be stored as well, > since old commitment transactions will only have P2WSH output to represent > those HTLC hashes and timelocks, and the actual HTLC hashes and timelocks > need to be shown as well in order to revoke the old HTLCs. > It seems to me that, since the amount of storage needed would be linear on > the number of HTLCs that ever appeared on the channel, a hardware with > storage limits would not be appropriate to store this state and your > append-only log machine might do better for that purpose. > > > > > > Opening a Channel > > > > > > ================== > > > > > > [...] > > > If there is a difference, that implies that this node is what pays the > fee, and the hardware should probably double-confirm with the user using > its UI whether the paid fees are acceptab;e. > > > > If the fee is under a preset threshold, it can be auto-approved. > > It would have to be a sophisticated threshold: a corrupted software would > split up the node funds into tiny 546-satoshi channels, paying a funding tx > fee each time. > I suppose when considering autopilot it would have to be auto-approved > though. > > > > > > Tr\*sted Forwarding > > > > > > ==================== > > > > > > Forwarding should be automated and not require a confirmation from the > user on the hardware unit UI. > > > Unfortunately, the hardware has to trust the software to actually > perform forwarding correctly. > > > > Let's look at this carefully, I feel it should be possible to prove > > correctness of forwarding to the hardware. > > I believe not. > Consider this sequence of events: > > * The hardware approves an outgoing HTLC on one channel based on the > existence of an incoming HTLC on another channel. > * Both channels are dropped unilaterally onchain, with their respective > latest states, before the outgoing HTLC can be claimed offchain. > * The software lets the outgoing HTLC to be claimed by the other node > using the hashlock branch. > * The software lets time pass and lets the incoming HTLC be claimed by the > other node using the timelock branch. > > As the hardware is incapable of actually pushing transactions onchain, it > cannot do anything about the incoming HTLC getting lapsed (though since it > has its own UI, if it had read access to the UTXO set somehow, it could > give a warning to the user using its UI and maybe hope the user notices?). > Indeed it is hard to give the hardware even read access to the blockchain > in order to even *know* about the outgoing HTLC getting claimed by > hashlock, without serious increases in hackability, storage, and > sophistication of the hardware. > Once you start having a hardware *that* sophisticated, it becomes more and > more like a complete Lightning node, and if you could implement that in a > *secure* unit, you would not need a separate software to drive it, the > software would effectively *be* inside the trusted hardware unit (when the > entire point of this exercise is to have a separate software we have > reduced trust in). > > > > > > However, the hardware has to keep track that an incoming HTLC only has > at most one outgoing HTLC,. > > > It cannot identify using the hash, incidentally: it is theoretically > possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> > E -> C -> F, where C appears twice. > > > > I think it's enough to require that each incoming HTLC can be > > associated with a single outgoing HTLC. The hardware would have to > > maintain state about which HTLCs have been "used up" in this way. > > > > > Further, if a payment attempt fails, then the ultimate payer might > still try to route through this node, giving a different postfix past this > node, so this node may forward the same hash twice on two or more different > payment attempts. > > > > hmm... that doesn't sound safe, because then two different nodes would > > be able to claim the funds from us, and we can only propagate back to > > a single input, so we lose funds. If the Lightning protocol allows > > this, then it sounds like a design issue. Seems like the failed HTLC > > should be invalidated first. The invalidation can be proven to the > > hardware (a new commitment tx is signed, removing the HTLC, or the > > outgoing channel is closed). > > Well, the incoming HTLC would have to be deleted as well before the payer > re-attempts (otherwise the payer could give out multiple HTLCs that are > simultaneously claimable). > The "flag" we associate with each incoming HTLC would be deleted when the > incoming HTLC is deleted as well, and separate incoming HTLCs would have to > be used to authorize separate outgoing HTLCs. > > In any case the point of this digression above was that we cannot key on > the *hash* of the HTLC, we have to have some identifier of HTLC (shared > between software and hardware) that is *not* the *hash*, but some other > identifier. > > > > > > [...] > > > Regardless, even if we somehow, the enforcement of HTLCs is still > controlled by the software: > > > > > > - The hardware has no access to the blockchain, thus it cannot know > if the incoming HTLC is in fact something in the deep past already. > > > A corrupted software can induce the hardware to create an outgoing > HTLC whose timelock is deeply in the past, then refuse to take the timelock > branch of the outgoing HTLC while letting the timelock branch of the > incoming HTLC be claimed by the other nodes. > > > > > > > See above about watchtowers, and trusted sources of time/blockchain > state. > > Watchtowers, at least as currently designed, treat each channel in > isolation. > Forwarding is about events on two channels. > So you would need a more sophisticated watchtower design as well. > > > > > > Thus, forwarding is still trusted. > > > > > > [...] > > > Reducing Storage Size > > > > > > ============================ > > > > > > The hardware can, instead of storing multiple channel slots and > payment slots in its own persistent memory, can instead just store a single > commitment to the current state it knows to be valid. > > > > Agreed, but see the need to have a reliable backup above. > > > I imagine that secure of a memory would be expensive to implement and thus > limited, thus if you implement it all in the hardware, you would impose > limits on the number of channels and updates and so on. > > The idea of having a secure append-only log could also be used for the > off-hardware state storage as well anyway, if you are trusting it enough to > be able to recover the node state. > The append-only log machine can even just accept new hardware states when > it sees the signature from the hardware attesting the change in root as > well, so that it forms a secure channel between the hardware and the > append-only log machine. > > Regards, > ZmnSCPxj > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
