TL;DR; By enabling cheaper and faster transactions, the Lightning Network could be a real game-changer for Bitcoin. However, security risks stemming from added protocol complexities and key management challenges prevent entities with high liquidity from using it and inhibit wider adoption. ZenGo has released a whitepaper that identifies these risks and proposes a new key management design, based on MPC, enabling major players to securely use the network and drive broader adoption.
The Lightning Network is a promising solution for Bitcoin’s scalability problem. But the network has some limitations, and as a result, we haven’t really seen any kind of significant adoption yet.
Our team recently released a whitepaper detailing a solution to these issues based on the same MPC technology that powers ZenGo’s innovative wallet. The solution enables the Lightning Network to be securely used by major players like banks and large enterprises, who will ultimately be required to deliver the increased liquidity and enhanced payment routing needed for broader adoption.
In this post, we’ll take a high-level look at the risks enterprises face in the Lightning Network and briefly explain our proposed solution, which we’ve decided to call Battlement.
Understanding the Lightning Network (In a nutshell)
The Lightning Network is a second-layer protocol that operates on top of the Bitcoin blockchain. It was developed to solve Bitcoin’s scalability problems and does so cleverly by taking transactions off-chain and making use of peer to peer payment channels, albeit at the expense of added protocol and key management complexities.
To understand how it works at a basic level, imagine a network with nodes and routes where a possible route exists between two nodes. In our case, nodes are lightning nodes, and a direct route between two nodes is called a channel, which is the basic unit in the lightning network. Payments are routed over the channels, where a route from Alice to Bob might hop through Charlie.
Added key management complexities bring added risks
While key management in Bitcoin is now well understood, the picture is different in the Lightning Network where things are considerably more complex. As a result, businesses with high liquidity levels are unclear about how they should handle the cybersecurity aspects of running a lightning node.
Users in a lightning node control three types of keys, which are all used interchangeably and sometimes all at once. Each key also serves a different purpose.
This new situation brings a different potential attack surface. Until now, security efforts have been directed at the protocol level: how to make sure the protocols adhere to bitcoin rules and cryptographically guarantee no fraud is possible between participants. When conducting our research, we decided to take another angle – the traditional cybersecurity point of view.
How Key Management Complexity is Hindering Lightning Network Adoption
To understand the security risks banks and large enterprises or really anyone with high levels of liquidity face when using the Lightning Network and appreciate why adoption has been so limited among these types of entities, let’s look at an example.
Imagine Alice and Bob are running a channel. Each runs a lightning node on some machine or device. Alice is, in fact, an enterprise, and the machine she runs follows standard security policies: different users with individual permissions and different ways to authenticate.
Some users’ profiles get write-access, some read-access, some both. Certain secret keys are generated in secure hardware and are non-volatile, while other random numbers are generated using the OS random number generator. Enter our attacker, who finds a vulnerability that provides some kind of elevated access to the machine.
The attacker gets “some” control over Alice’s lightning node. It may be the case that the attacker can only erase specific data or copy some keys but cannot corrupt them.
Surprisingly, however, as we show in our whitepaper, the lightning node attack surface is not trivial at all! Given the attacker’s unique access in each case, it’s possible to conduct severe attacks, usually by collaborating with other network participants (e.g., Bob) that guarantees everyone wins (except Alice).
Providing a new layer of proactive defense
Battlement provides a more sophisticated node management solution by taking a quorum based design for Lightning Network key management, where MPC nodes are run by a quorum of third parties to enable highly liquid entities to safely connect to the network.
As we explain in more detail in our whitepaper, a Battlement is made up of a quorum of watchtowers (several watchtowers connected together), which adds a new layer of proactive defense to the Lightning Network. Two key concepts need to be understood when it comes to the design of a Battlement.
The first is MPC, which stands for multiparty computation. Today, MPC is a commonly used technology for Bitcoin key management and is used by most big exchanges and enterprises.
Simply put, MPC allows users to enjoy the full cycle of secret keys, including key generation and signing, without ever constructing the entire secret key in one place. Using MPC in the Lightning Network requires applying the technology to a broader set of use cases than just the threshold signing (TSS), which is enough for bitcoin. For example, MPC needs to run to distribute a secret number that has a known hash value.
The second key idea is the watchtower, a new role introduced by the Lightning Network. One of the requirements for participating in the Lightning Network is to stay constantly online. This requirement can be delegated to a watchtower, enabling users to go offline without losing any funds.
The watchtower provides an excellent framework for our solution as all that’s required is to enable watchtowers to connect to one another and form quorums. As a result, the watchtowers can continue to perform their intended role and be hired to run the MPC, securing a user against an attacker!
Who takes the role of a node in a Battlement?
The key management solution put forth in our whitepaper is based on the watchtower concept. In short, we require a quorum of watchtowers, called a Battlement, to which a user delegates their key management responsibilities. Under a threshold assumption, our design eliminates the existing attack surface we have identified.
Of course, one critical question remains. Who can take on the role of a node in a Battlement? In our best estimation, this role is most suited for Banks. It provides a new way for them to serve clients who want to participate in the network while maintaining the highest security level for both users and the organization itself.
Want to learn more about Lighting Network security? Interested in joining forces to conduct follow-up research? Get in touch!