Insecure Lightning Node? VLS Fixes This

Summary

Jack Raldi introduces the Validating Lightning Signer (VLS) project, a solution to enhance security in the Lightning Network by separating private keys from nodes to a hardened signing device. VLS validates transactions against Lightning Network rules before signing, preventing unauthorized transactions even if the node is compromised. The project is open-source, with a roadmap including features like tag team signing and disaster recovery. VLS is adaptable for various use cases, from mobile devices to large merchants, ensuring user control over private keys. The script also discusses Validity, a project leveraging secure enclaves for enhanced Bitcoin signing security, with VLS as its initial application.

Takeaways

• 🏌️ Jack Raldi challenges Donald Trump to a golf game with a $1 million charity bet for Bitcoin open source development.
• 🔒 The Lightning Network faces custody challenges due to reliance on cloud providers and custodial apps, which pose security risks.
• 💡 VLS (Validating Lightning Signer) aims to enhance security by separating private keys from the Lightning node to a hardened signing device.
• 🛡 VLS validates Lightning Network rules before signing transactions, preventing unauthorized transactions even if the node is compromised.
• 🔄 VLS is an open-source reference implementation, not a consumer product, and is designed for integration into other solutions.
• 🔗 VLS allows for flexible policies, such as velocity control and approval flows, to manage transaction authorization.
• 📱 VLS can be deployed on various devices, from mobile to large merchants' HSMs, ensuring user control over private keys.
• 🔄 VLS is seeking developers and has a roadmap including features like tag team signing, disaster recovery, and enterprise focus.
• 🔐 Validity, a new project funded by Spiral, focuses on integrating VLS with secure enclaves for enhanced security and policy enforcement.
• 🔗 The project aims for hardware that is open-source, self-sovereign, and widely available, with an initial focus on ARM architecture.

Q & A

What is the main challenge addressed by the Validating Lightning Signer (VLS) project?

The main challenge addressed by the VLS project is the custody and security risks associated with Lightning Network nodes, where most nodes are hosted on cloud providers and users often rely on custodial apps, which can present challenges with authorities and increased risk of funds loss if compromised.

What is the concept of a 'blind signer' in the context of the Lightning Network?

A 'blind signer' is a device that is separated from the main node and is responsible for signing transactions without validating them. This can actually reduce security because it introduces another potential attack point and blindly signs whatever the node asks it to, without verifying the transaction's legitimacy.

How does the Validating Lightning Signer (VLS) improve upon the blind signer model?

VLS improves upon the blind signer model by not only separating the user's private keys from their Lightning node to a separate hardened signing device but also ensuring that this device validates all of the Lightning Network rules before signing a transaction. This prevents unauthorized or malicious transactions from being signed, even if the node is compromised.

What is the role of the VLS in the context of a Lightning Network node?

The VLS acts as a secure, separate device that holds the user's private keys and validates all Lightning Network rules before signing transactions. It ensures that only legitimate transactions are signed, thereby protecting the user's funds even if the main Lightning node is compromised.

What are some of the features that VLS allows for in terms of transaction policies?

VLS allows for flexible policies such as velocity control, which can limit the amount of funds that can be sent per day, and setting up approval flows for different transaction amounts, allowing certain individuals or roles within an organization to approve transactions above a certain threshold.

Can you provide an example of a device that can run the VLS?

Examples of devices that can run VLS include mobile devices, inexpensive consumer devices like an ESP32 or an STM32, and more expensive options like HSMs or hardened servers. This flexibility allows for a wide range of use cases from individuals to large merchants.

What is the significance of VLS being an open-source project?

Being open-source means that VLS is a reference implementation that can be freely used, modified, and improved upon by the community. It allows other commercial products to incorporate its features into their own solutions, promoting innovation and widespread adoption of secure Lightning Network practices.

How does VLS contribute to the user's control over their private keys?

VLS contributes to user control by allowing the end user to hold their private keys on a separate, secure device, even if their node is hosted by a third-party service provider. This ensures that the user maintains control over their funds and can unilaterally close channels and recover their Bitcoins without the need for third-party involvement.

What is the roadmap for the VLS project in terms of future development?

The roadmap for the VLS project includes working on disaster recovery features, focusing on enterprise solutions, integrating VLS with secure enclaves, and eventually supporting multisignature lightning transactions, which are dependent on other developments in the Bitcoin ecosystem like Taproot, Frost, and MAST.

What is the Validity project and how does it relate to VLS?

The Validity project is an ambitious initiative enabled by a Spiral Grant, aiming to leverage secure enclaves for Bitcoin signing. In its initial phase, it focuses on integrating with VLS, as the secure enclaves require policies that restrict key usage, which VLS effectively provides. The project aims to create a prototype, reference implementation, and developer kit for integrating VLS with secure enclaves.

Outlines

00:00

🏌️‍♂️ Introduction to the Validating Lightning Signer Project

Jack Raldi introduces the Validating Lightning Signer (VLS) project, challenging Donald Trump to a golf match with a charitable wager. The script discusses the custody challenges in the Lightning Network, where most nodes are hosted on cloud providers and users face risks of compromised funds. VLS aims to enhance security by separating private keys from the Lightning node to a hardened signing device, which validates transactions against the Lightning Network rules before signing. This prevents unauthorized transactions even if the node is compromised. VLS is an open-source project intended for incorporation into other products, not a consumer-facing product itself. The script also explains how VLS works, separating keys into another device and allowing for flexible policies such as velocity control and approval flows.

05:01

🛠️ VLS Use Cases and Future Developments

The script outlines various use cases for VLS, including running on mobile devices, inexpensive consumer devices, and hardened servers. It emphasizes that VLS allows end users to control their private keys, even if their node is hosted by a service provider, ensuring they can recover their funds without the service provider's involvement. The project is seeking developers and outlines its roadmap, which includes features like tag team signing, disaster recovery, and a focus on enterprise solutions. The script also introduces the Validity project, enabled by a Spiral Grant, aiming to integrate VLS with secure enclaves for enhanced security. The project's short-term goals involve creating a prototype, reference implementation, and developer kit, with a focus on ARM architecture and the Global Platform API.

10:01

🔩 Hardware and Software Integration for Secure Enclaves

The final paragraph discusses the hardware and software integration for secure enclaves, focusing on the use of the open-source OP-TEE implementation running in ARM TrustZone. The project aims to create a system where the VLS remote signer component is inside a trusted execution environment, providing greater security. The script describes the architecture, which includes a client app running in the Linux environment, communication with the global platform client API, and the enclave for signing. The project is open-source and seeks contributions from developers, with a preference for open-source hardware that is self-sovereign and widely available. The platforms initially supported are QEMU for emulation and the Rockchip 3399-based single-board computer for development. The project is actively seeking developers and community knowledge for security reviews and is available on GitHub.

Keywords

💡Validating Lightning Signer (VLS)

VLS refers to a project aimed at enhancing the security of Bitcoin's Lightning Network by separating a user's private keys from their lightning node to a separate hardened signing device. This device validates all of the Lightning Network rules before signing a transaction, thereby preventing unauthorized transactions even if the node is compromised. In the video, VLS is presented as a solution to the custody challenges in the Lightning Network, where most nodes are hosted on cloud providers, presenting security risks.

💡Custody Challenges

Custody challenges in the context of the Lightning Network refer to the risks associated with holding user funds, especially when most lightning nodes are hosted on cloud providers and users rely on custodial apps. This setup can be vulnerable to attacks, leading to potential loss of funds. The video discusses how VLS addresses these challenges by ensuring that even if a node is compromised, the user's funds remain secure as the VLS signer would not allow any transactions that would result in a loss.

💡Blind Signer

A blind signer is a device that signs transactions without validating the transaction details, which can reduce security by creating additional attack points. The video contrasts the blind signer with VLS, which validates transactions before signing, thus providing a higher level of security. The blind signer is mentioned as a solution that has been attempted to solve custody challenges but has its own set of issues.

💡Lightning Network

The Lightning Network is a second-layer solution built on top of the Bitcoin blockchain, designed to enable faster and cheaper transactions. It operates by creating payment channels between users, allowing for off-chain transactions. The video discusses various challenges and solutions related to the Lightning Network, particularly focusing on how VLS can improve its security.

💡Open Source

Open source refers to software whose source code is made available to the public, allowing anyone to view, use, modify, and distribute the software. VLS is described as an open-source reference implementation, meaning it is a freely available software that other developers can use and contribute to. This is significant as it allows for community involvement in the development and improvement of the software, ensuring transparency and collaborative innovation.

💡HSM (Hardware Security Module)

HSM refers to a physical device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. In the video, HSM is mentioned as a potential platform for running VLS, suggesting that it can provide a high level of security for the signing process. This is particularly relevant for large merchants or organizations that require a robust security infrastructure.

💡Disaster Recovery

Disaster recovery in the context of the video refers to the process of recovering funds in the event of a disaster or system failure. VLS is working on features that will enable users to recover their funds securely and efficiently, which is crucial for maintaining trust and reliability in the Lightning Network.

💡Secure Enclave

A secure enclave is a hardware-based security feature that provides a protected area within a device for processing sensitive data. The video discusses a project called Validity, which aims to integrate VLS within a secure enclave, enhancing the security of the signing process by ensuring that the private keys are protected within a secure, isolated environment.

💡Multisig Lightning

Multisig, or multisignature, refers to a requirement for more than one party to sign a transaction before it can be executed. In the context of the Lightning Network, multisig lightning would involve multiple signers controlling the same node, adding an extra layer of security. The video mentions this as a future feature that VLS is looking to implement, once underlying technologies like taproot, frost, and MAST are ready.

💡Zero-Conf Channels

Zero-conf channels refer to payment channels in the Lightning Network that do not require confirmations on the Bitcoin blockchain. The video discusses the development of features like 'splicing zero-conf channels,' which would allow for faster and more immediate transactions within the Lightning Network, enhancing its usability and efficiency.

Highlights

Jack Raldi introduces the Validating Lightning Signer (VLS) project.

Challenges in the Lightning Network include custody issues with most nodes hosted on cloud providers and users relying on custodial apps.

Risks associated with always-online lightning nodes are highlighted, as they essentially operate as hot wallets.

Blind signer solutions are critiqued for reducing security by creating additional attack points.

VLS aims to enhance security by separating private keys from the lightning node to a hardened signing device.

The VLS device validates all Lightning Network rules before signing transactions, preventing unauthorized fund loss.

VLS is an open-source reference implementation, not a consumer-facing product.

VLS allows for flexible policies such as velocity control and approval flows for transaction amounts.

System diagram of VLS is presented, illustrating the interaction between the lightning node and the remote signer.

Use cases for VLS range from mobile devices to large merchants, with various hardware options.

VLS ensures users maintain control over their private keys, even when nodes are hosted by LSPs.

The project is seeking developers and has a roadmap outlining upcoming features like tag team signing and disaster recovery.

VLS on secure enclaves is discussed as a new project enabled by a Spiral Grant.

The secure enclave approach prevents blind signing and requires policies that restrict key usage.

The project's short-term goals include creating a prototype, integration with VLS, and engaging with device manufacturers.

Hardware preferences for the project are outlined, emphasizing open-source, self-sovereignty, and affordability.

The project is open to developers and has resources available on GitHub and through matrix chat.

Transcripts

everyone thanks for being here instead

of uh lining up for Trump my name is

Jack raldi I'm with the validating

lightning signer

project am I live y it's good to be here

Donald if you're listening I challenge

you to 18 holes of golf if you win I

mean if I

win you donate 1 million to bitcoin open

source development and if you win you

donate 1 million to bitcoin open source

development so uh let's set the stage

here so uh before we get into VLS let's

talk about some of the challenges in the

lightning Network so there's some

custody challenges in that most

lightning nodes are actually hosted um

on cloud providers and most lightning

users are using custodial apps and uh as

I'm sure you've seen with recent news uh

holding custody of user funds presents

challenges um with the authorities um

and it just like extra risk that uh you

might not want to take as a provider uh

on the other side there's people that

are running their own nodes and holding

custody of Their Own Private Keys uh but

because lightning is uh always online

you're essentially holding your keys in

a hot wallet which uh as I'm sure a lot

of you are aware is uh quite risky to do

uh so because if the lightning node is

compromised you're going to lose your

funds uh to the

attacker so what are some solutions that

have been attempted to solve this

problem uh there's something called a

blind signer um where essentially

the signer is separated from the node to

a separate signing device um but the

problem is like like the title implies

it's a blind signer so whatever the node

asks it to sign it just goes ahead and

signs that and you've actually reduced

security because now instead of just the

one uh attack point at the node now you

have two attack points the the blind

signer and the node and you've reduced

security uh so that's what how how VLS

kind of came into being um the idea was

to increase security of lightning setups

by separating a user's private keys from

their lightning node to a separate

Harden signing device and this device

would actually validate all of the

lightning Network rules before it signs

a transaction so that if an attacker

were to compromise the lightning node uh

the VLS signer would just not allow any

transactions to be signed that uh would

make you lose money so there's no other

solution that provides this level of

security and just one note uh VLS is an

open- Source uh reference implementation

of this software we are not a consumer

facing um or commercial product we're

just building software that um I guess

other commercial products would then

incorporate into their own

Solutions uh so how does VLS work uh

essentially what it like I said it

separates your lightning Keys into uh

another device that you can Harden as

much as you like and the node then

substitutes its own internal signing

with a call to the VLS signer and what

are some examples of things that VLS

might sign it could be something like a

uh justice transaction or closing a

channel to a whit listed address and the

other cool thing is that vs allows for

um flexible policies such as uh I guess

velocity control of how how much funds

per day um or maybe setting up approval

uh approval flows such that maybe

somebody at uh I guess the front lines

of an organization can send out let's

say $1,000 in a payment or someone at

the SE Suite maybe you can send out a

million dollars in payment so you can

kind of customize it that way or you can

customize that any money that is uh your

node is receiving is auto approved by

VLS and any money that you're sending

out maybe needs some approval from from

a person with

keys so this is a quick uh system

diagram so you have your I guess

lightning node here in the middle which

has a a proxy to the VLS remote signer

um and it's asking it to sign

transactions um and then the node also I

guess has some information here on the

bottom uh so it has a utxl set and a

Bitcoin node that VLS needs in order to

track the um the the level layer one

chain State and there's also a state

storage uh just to make sure that let's

say your node goes down or your VLS

remote signer goes down that you don't

lose uh your lightning State because if

you do uh you're going to lose your

funds uh because you you kind of lost

where you're

at uh so what are some use cases for VLS

uh so it can be something like URI

running VLS on our mobile device and

this actually already exists today if

you guys have heard of green light uh

they're being used by Breeze and Breeze

is offering the VLS service to their

customers such as Rel uh that are

running VLS on a mobile device um it

could be also small Merchants that uh

are using inexpensive consumer devices

such as an esp32 or an stm32 those are

like the sp32 is 20 bucks the stm32 is

100 bucks uh you can just set it up and

have it run VLS or it could be like a

large Merchant that's running um VLS on

an HSM or hardened server so like all

the way from the cheapest devices all

the way to the the most expensive uh VLS

can run on all of them uh and the the

cool thing is like on all of those use

cases the end user whether it's like URI

I or um a merchant um or an organization

like the end user controls their private

Keys um even if their node is hosted on

something like an LSP so if uh the LSP

is misbehaving or whatever the user can

unilaterally close their channels and

recover their Bitcoins without any

involvement from the LSP so

you keep control of your keys it's your

keys and it's your

coins uh so BLS is looking for devs and

I just wanted to show you guys the road

map of what we're working on um upcoming

in case there's some interested devs

that that want to join and contribute so

we just finished tag team signing which

is a feature that allows multiple nodes

or sorry multiple signers to control the

same node uh we're going to be working

on Disaster Recovery in case of disaster

like how do you recover your funds uh up

next and then we have some features

planned such as splicing zero conf

channels um another version of the State

Storage some routing B 12 uh we're going

to do a heavy focus on Enterprise

because we we've kind of focused on

small signers now we're going to focus

on big ones uh in a minute Sean's going

to talk to you about uh VLS on secure

enclaves which I'm really excited about

and finally um off in the future we have

uh multisig lightning uh which is not

ready it depends on tap rot uh Frost and

M 2 to be ready for use by by lightning

which as I understand it will be in the

future but not quite n yet uh so yeah if

you want to take VLS for a spin um all

these links are on our website vs. te um

we have a matrix chat uh we have a

gitlab repo where you can submit a

feature request or take a look around uh

we also have uh core lightning and uh

LDK sample nodes running VLS uh that you

can uh I guess spin up in Docker if you

want to give them a shot and uh yeah and

over to Sean for validity so validity is

a new project um enabled by a spiral

Grant thanks spiral um it's it's a

pretty ambitious uh I mean my my

long-term plans are pretty ambitious I'd

like to see you know all kinds of things

going on with secure enclaves and

Bitcoin signing but in this initial uh

phase we're going to really focus on vs

because it's a really good match when

you put Keys into a secure onclave um

you can't have blind signing you need

policies that can restrict when they're

used and V does such a nice job of doing

that as Jack told you that that's going

to be our our initial uh

application so this is a a simple

diagram uh when you see the no it's

basically the the VLS remote signer

component itself uh is in inside the The

Trusted execution environment or the

secure onclave and then the other

components are outside there's sort of

two ways you can deploy this one is on a

single device where you get the benefits

of the of of the te running in the same

node or you can deploy it on a separate

device which can be even more secure

because you have greater isolation there

also um are some implementations of uh

arm trust Zone that include integrated

um Hardware that provides tamper

resistance um that we're building this

on top of something called opt the open

portable trusted execution environment

which is an enclave implementation

that's been open source for about 10

years now and it's a it's a pretty uh

well supported project and a lot of uh

commercial implementations are based on

this reference implementation it runs in

arm trust Zone and it integrates with

the the Linux OS for the um the insecure

or the rich execution environment it's

loaded by trusted firmware a and it has

been ported to other architectures like

Risk 5 but for this phase of the project

we're going to focus on arm which is

sort of the dominant processor in uh in

Mobile and and and becoming uh so for

desktops and and laptops as

well um the global platform uh is is an

API that opt uses and that this project

will use um it's an international

standard uh organization and they

provide two apis the T cant API and the

T internal core API and by using those

apis the software should be portable to

some commercial uh commercial cell phone

implementations obviously we'd have to

partner with those companies and get

whitelisted but that's is a long-term

goal for the

project uh our short-term goals are to

put together a prototype a reference

implementation and a developer kit um to

do the integration with

v um to begin talking to device

manufacturers you can come find me if

you're making a device um to get uh some

more contributors and to start begin

collecting Community knowledge security

reviewers uh fuzzers come come get us

well give me a couple months to get

further with the software but we'll

we'll be looking forward to uh

constructive criticism in that

area um we we in terms of Hardware you

know what we'd like to see like the Holy

Grail is Hardware that's open source has

no uh no blobs or large binaries in the

um either the bootloader or the device

drivers Etc that you can develop with

without signing a non-disclosure

agreement that allows the hardware that

you deploy to be self- Sovereign meaning

you control the bootloader um and to be

affordable and widely available we're

going to have to make some compromises

on this um there the current prototype

that we're doing I believe there's one

blob in the in the in the bootloader but

um we want to begin the process of

driving things more towards an open-

Source uh

ecosystem so the platforms that we're

supporting in this initial phase are

cumu which is a software emulator which

allows us to develop on you know an x86

PC or an arm I I use an arm Mac um and

we're using this uh

Raja Rock four single board computer

which has a Rockchip

3399 which has a full uh trust Zone

implementation and support for secure

boot it's uh you can get them for as

little as like 60 bucks I

think this is a a diagram of the

architecture I'm going to go through

this really quick but there's a client

app that runs in the Linux World um that

would be the um the the validating

lightning signer component that talks

via seral or tcpip to to the node um or

maybe even a Unix socket and then it

talks to the global platform client API

goes down through the kernel through the

firmware into the enclave and then the

signing occurs up here and then the the

sign messages will come back

out um you can find uh the project on

GitHub um it'll eventually have its own

domain but for now it's just under my

account and we have a uh a matrix chat

room inside of the uh it doesn't say it

but it's it's it's it's part of the V

project the

V uh what's it called yeah the VLS uh

group VLS

group so yeah like I mentioned we're

looking for devs so if you're uh

interested in helping open source um

come come talk to us uh after the

presentation and uh uh yeah thank you

very much uh for for checking us out uh

we have some links down here if you want

to if you want to learn more um yeah

thanks for everyone for the attention

[Applause]

[Music]

[Music]

a

[Music]