The Lightning Security Spectrum — Jack Ronaldi (VLS.tech)¶
Típus: Cikk / Technikai útmutató Szerző: Jack Ronaldi Dátum: 2026-07-08 Forrás: https://vls.tech/posts/lightning-security-spectrum/
Alapgondolat¶
"Non-custodial" is not a security model on Lightning.
A Bitcoin L1-en a non-custodial tiszta: a privát kulcsok cold storage-ban vannak, csak akkor írnak alá, amikor te akarod. A Lightningen ez nem működik — a HTLC-k, channel frissítések és fizetések időszenzitívek, az aláíró kulcsoknak online kell lenniük. A "nem a te kulcsaid, nem a te coinjaid" elv a Lightningen nem automatikusan biztonságot jelent.
A valódi kérdés: ha a node-ot kompromittálják, mit tud tenni a támadó?
A Lightning Biztonsági Spektrum¶
| Szint | Név | Mit jelent | Kompromittáláskor |
|---|---|---|---|
| -1 | Blind signing | Aláíró különválik a node-tól, de validálás nélkül jóváhagy | Két támadási felület, rosszabb mint hot wallet. NE ÉPÍTSD EZT |
| 1 | Custodial hot wallet | Szolgáltató tartja a kulcsokat, futtatja a node-ot | Szolgáltatói adatszivárgás vagy belső támadó mozgathatja a pénzt |
| 2 | Non-custodial hot wallet | Te tartod a kulcsokat, de online a node-dal | Node kompromittálás → pénz lopható |
| 3 | Hardened node | Secure enclave, HSM, attestation | Kevesebb esély a kompromittálásra, de ha megtörténik, a node továbbra is aláírhat lopást |
| 4 | VLS (Validating Lightning Signer) | Különálló aláíró, policy-t enforceol | Node kompromittálás túlélhető — az aláíró blokkolja a policy-n kívüli műveleteket |
| 5 | VLS + threshold multisig (jövő) | M-of-N jóváhagyás Lightning aláíráshoz | Legmagasabb biztonság, legnagyobb komplexitás |
Két beállító gomb¶
- Komromittálás valószínűsége (mennyire valószínű, hogy valaki bejut)
- Robbanás sugara (mennyit veszíthetsz)
"Keep smaller balances in simpler models. As balances become serious or business-critical, invest in designs that reduce worst-case loss, not just the chance of an incident."
Szintek részletesen¶
Level -1: Blind signing (anti-pattern)¶
Különálló aláíró, de biztonsági ellenőrzés nélkül jóváhagy mindent. Rosszabb mint egy sima hot wallet, mert két támadási felület van (node + aláíró). Senki se építse ezt.
Level 1: Custodial hot wallet¶
A szolgáltató kontrolálja a kulcsokat és a node-ot. Legjobb UX, legkevesebb felhasználói felelősség, legmagasabb bizalmi kockázat. Kisebb egyenlegekre és onboarding-ra.
Level 2: Non-custodial hot wallet¶
Te tartod a kulcsokat, de online a node környezetében. Szuverén, de a biztonság erősen függ a node környezetétől. Költési egyenlegekre. - Példa: Phoenix (ACINQ), Bitkit, Blixt Wallet - Lokális vs hosted: A non-custodial hot wallet lehet a felhasználó eszközén (lokális) vagy szerveren (hosted). A hosted nem automatikusan biztonságosabb vagy kockázatosabb.
Level 3: Hardened node (secure enclave / HSM)¶
A node hardened környezetben fut (SGX, Nitro Enclaves, HSM). Kevesebb esély a kulcskinyerésre, de a blast radius nem csökken — ha valaki rosszindulatú logikát futtat a node-on, az továbbra is lophat.
- Példa: ACINQ ($100M Lightning node AWS Nitro Enclaves-ben, Ledger-alapú emberi jóváhagyás szenzitív műveleteknél), LEXE (Intel SGX)
- Költség: drága, specializált infrastruktúra, többéves erőfeszítés
Level 4: VLS (Validating Lightning Signer)¶
A kulcsok és aláírási döntések különálló aláíróban vannak. Az aláíró policy-t enforceol aláírás előtt. A kompromittált node nem tud lopni a policy-n kívül.
Policy példák: - Close destinációk korlátozása engedélyezett címekre - Fee határok és rate limit-ek - Fizetési összeg limit-ek és velocity limit-ek - "Panic button" — aláírás leállítása ha gyanús tevékenység van
Ígéret: "Even if the node is compromised, the attacker cannot get signatures for actions that violate policy."
- Példa: Blockstream Greenlight, Blockstream App
Level 5: VLS + threshold multisig (jövő)¶
M-of-N jóváhagyás Lightning aláíráshoz (pl. 3-of-5). Még nincs standard production implementáció, de érdeklődés van (Flowrate kereste meg a VLS projektet).
Valós incidensek¶
| Incident | Mi történt | Szint | Ok |
|---|---|---|---|
| LNBank (BTCPay plugin) | Race condition: párhuzamos visszavonások ~4.07 BTC lecsapolása | Level 2 (operator) / Level 1 (users) | Stale state balance check párhuzamosság alatt |
| LNbits | Támadó extrém routing fee-kkel csapolta le a wallet-et (>0.1 BTC) | Level 1-2 | Hiányzó per-payment fee limit és "amount + fee" guardrail-ek |
| LND "Replacement Stalling" | Theft-capable vulnerability: force-close sweeping és replacement viselkedés | Level 2-3 | Implementációs hiba az on-chain sweeping edge-nél |
"These aren't exotic attacks. They are common software and operational failures that become drains because the compromised node is a hot wallet that has full authority to approve the theft."
VLS: Hogyan működik?¶
A VLS az architektúrát változtatja meg, nem csak hardened-í ugyanazt:
- Separation: Kulcsok és aláírási döntések a node-on kívül, dedikált aláíróban. Az aláíró kevesebbet csinál mint a node → kevesebb dependency, kisebb támadási felület
- Enforcement: Az aláíró policy ellen validálja a kéréseket aláírás előtt
- Containment: Node kompromittálás nem vezet lopáshoz (a policy-n kívül)
Greenlight mint működő példa: Hosted node kényelem + VLS-alapú validating signer. Bizonyítja, hogy a separation nemDestroyálja a UX-t.
Ellenőrző lista: Mennyire biztonságos a wallet-od?¶
- Ha a node kompromittálódik, tud-e a támadó lopni? — Erős válasz: "Node kompromittálás túlélhető, az aláíró policy-t enforceol"
- Hol van az aláírási jog? — "Az app/node processzében" = gyenge; "Külön aláíróban" = másik biztonsági határ
- Milyen konkrét limit-ek vannak? — Close destináció korlátozás, payment limit, fee ceiling, panic mode
- Mi a worst-case loss? — Ha nem tudják egy bekezdésben leírni, assume "total loss"
- Mit látnál a log-okban támadáskor? — Clear audit trail, rejected attempts, alertek
- Mi véd insider risk ellen? — Separation of duties, controlled deployments, human approvals
- Mi a recovery plan? — Dokumentált incident response, lock-down lépések, key rotáció
Ha az egyetlen válasz "non-custodial", akkor nincs válaszod a kompromittálási kérdésre.
Wallet besorolás (2026-02-11)¶
| Wallet | Szint | Kulcs/Node helye |
|---|---|---|
| Blockstream Greenlight | 4: VLS | Kulcs: User Device (VLS), Node: Provider |
| Blockstream App | 4: VLS | Kulcs: User Device (VLS), Node: Provider |
| Phoenix (ACINQ) | 2: Non-custodial (hot) | User Device |
| Bitkit (Synonym) | 2: Non-custodial (hot) | User Device |
| Blixt Wallet | 2: Non-custodial (hot) | User Device |
| Blocktank (Synonym) | 2: Non-custodial (hot) | User Device |
| Blink (Galoy) | 1: Custodial (hot) | — |
| Wallet of Satoshi | 1: Custodial (hot) | — |
| IBEX Mercado | 1: Custodial (hot) | — |
| Machankura (8333.mobi) | 1: Custodial (hot) | — |
| ACINQ (node infra) | 3: Hardened node | AWS Nitro Enclaves |
| LEXE | 3: Hardened node | Intel SGX |
Call to Action (fejlesztőknek)¶
- Ne add el a "non-custodial"-t úgy, mintha megválaszolná a nehéz kérdéseket
- Definiáld a worst-case kompromittálási modelled (és írd le)
- Publikáld, milyen kontrol-ok akadályozzák meg az unauthorized close-okat és policy violation-öket
- Dokumentáld a recovery, auditability és operational safeguard-okat
- Ha hosted UX-t akarsz, céloz validating-signer modellt
"Security is an architecture choice, not a checkbox."