Insecure Lightning Node? VLS Fixes This
Summary
TLDRJack 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
🏌️♂️ 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.
🛠️ 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.
🔩 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.
Mindmap
Keywords
💡Validating Lightning Signer (VLS)
💡Custody Challenges
💡Blind Signer
💡Lightning Network
💡Open Source
💡HSM (Hardware Security Module)
💡Disaster Recovery
💡Secure Enclave
💡Multisig Lightning
💡Zero-Conf Channels
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]
Ver Más Videos Relacionados
Blockchain 101 - Part 2 - Public / Private Keys and Signing
Bitcoin Transactions - from "Send" to "Receive"
What is the Lightning Network? (Explained Simply)
How to Keep Your Bitcoins Safe? avoiding scam, theft and fraud (2024 Updated)
Zaprite's Cutting-Edge Technology Takes Center Stage & Redefines Payment Solutions!
Hardware Wallets Explained, Reviewed and Compared
5.0 / 5 (0 votes)