<p>So I think you're missing some things. Since the Lightning node has bitcoins in the channel and can be used as a conduit for B to send or receive money, node A must have an automated way to sign bitcoin transactions and participate in lightning transactions. An attacker could theoretically use this ability to send bitcoins from the channel through the lightning network to themselves, in the case that the attacker compromises the machine in such a way as to have the ability to instruct the Lightning node to do those things. The private keys would still be in memory at very least, and so could potentially be accessible to kernel viruses. </p>

CC BY-SA 3.0
2017-11-24T09:03:07.790Z
2017-11-24T09:03:07.790Z
B T
<p>Imagine a Lightning Network node A that maintains a bidirectional payment channel with one peer B. For this channel to be maximally useful, some of its value must belong to A. To update channel state, A must have ready access to one or more private keys. To communicate with B, A must also maintain a network connection.</p>

<p>Putting these three requirements together means that A must maintain a hot wallet controlling value. Ordinarily, this would open A up to loss of funds through network-based attacks.</p>

<p>The case of a Lightning node is more nuanced in terms of what can be stolen and what can be done with stolen material.</p>

<p>Three pieces of cryptographic material can potentially be stolen:</p>

<ol>
<li>the private key allowing the node to update channel state;</li>
<li>the preimage of the current state's hash value, or previous preimages;</li>
<li>one or more channel states.</li>
</ol>

<p>Now imagine that an attacker breaks into A:</p>

<ul>
<li>he can not steal the money for himself without B's private key;</li>
<li>he can try to sell the preimage of the current state's hash value to B;</li>
<li>he can publish the current hash value preimiage, allowing B to steal the money;</li>
<li>he can sign an publish the current channel state (closing it without contention), or a previous state (allowing B to steal the money).</li>
</ul>

<p>So an attacker is much more restricted than otherwise. He can't steal money outright. But he can work with B to steal the money. Alternatively, if B is the attacker, then no collaboration is needed to claim the entire channel value.</p>

<p>Is there anything I'm missing here? What countermeasures could A deploy to further limit what can be done in the event that an attacker gains access to one or more pieces of cryptographic material?</p>

<wallet-security><lightning-network>
Security for Lightning Network nodes?
Rich Apodaca
# Security for Lightning Network nodes?

(Asked by: username_0 on 2017-07-08)

Imagine a Lightning Network node A that maintains a bidirectional payment channel with one peer B. For this channel to be maximally useful, some of its value must belong to A. To update channel state, A must have ready access to one or more private keys. To communicate with B, A must also maintain a network connection.

Putting these three requirements together means that A must maintain a hot wallet controlling value. Ordinarily, this would open A up to loss of funds through network-based attacks.

The case of a Lightning node is more nuanced in terms of what can be stolen and what can be done with stolen material.

Three pieces of cryptographic material can potentially be stolen:

1. the private key allowing the node to update channel state;
2. the preimage of the current state's hash value, or previous preimages;
3. one or more channel states.

Now imagine that an attacker breaks into A:

* he can not steal the money for himself without B's private key;
* he can try to sell the preimage of the current state's hash value to B;
* he can publish the current hash value preimiage, allowing B to steal the money;
* he can sign an publish the current channel state (closing it without contention), or a previous state (allowing B to steal the money).

So an attacker is much more restricted than otherwise. He can't steal money outright. But he can work with B to steal the money. Alternatively, if B is the attacker, then no collaboration is needed to claim the entire channel value.

Is there anything I'm missing here? What countermeasures could A deploy to further limit what can be done in the event that an attacker gains access to one or more pieces of cryptographic material?

**Tags:** wallet-security, lightning-network


---

## 1 answers

### Answer by username_1 on 2017-11-24. Score: 2

So I think you're missing some things. Since the Lightning node has bitcoins in the channel and can be used as a conduit for B to send or receive money, node A must have an automated way to sign bitcoin transactions and participate in lightning transactions. An attacker could theoretically use this ability to send bitcoins from the channel through the lightning network to themselves, in the case that the attacker compromises the machine in such a way as to have the ability to instruct the Lightning node to do those things. The private keys would still be in memory at very least, and so could potentially be accessible to kernel viruses.


---

