Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Runes today are often bound to the BOLT8 nodeid, giving both (otherwise you need to protect your rune from being read). I like this model *but* it requires two-way comms for setup (the HSM tells the node its id, the node gives the HSM the rune). Fortunately, it's trivial to support runes as an extension, and set what the default is if they don't present one. Allows nice experimentation. Further discussion on the gist... Cheers! Rusty. Bastien TEINTURIER writes: > Hey Christian, > > You're right, if we create runes inside the HSM then we end up with the > same security model. > It then boils down to whether we'd rather implement Bolt 8 or rune > management inside an HSM! > I'd prefer Bolt 8, as I think it has more universality (and is simpler), > but it could be worth experimenting with both approaches. > > It will also be interesting to see how we actually configure rights (access > control) on the lightning node side. > That really deserves some implementation work to flesh out that kind of > details. > > Cheers, > Bastien > > Le ven. 8 sept. 2023 à 16:51, Christian Decker > a écrit : > >> Very interesting proposal, though as Will points out we could implement >> the same using runes: have the rune be managed by the hardware wallet, and >> commit the rune used to authenticate the RPC call commit to the call's >> payload. That way a potentially compromised client cannot authenticate >> arbitrary calls, since the hardware wallet is required to associate a rune >> with it, giving it a chance for review. >> >> This is similar to how authentication of RPC calls works in greenlight, >> where the node host is not trusted, and we need to pass the authenticated >> commands forward to the signer for verification before processing any >> signature request from the node. We chose to authenticate the payload >> rather than the transport (which is what partonnere does) because it >> removes the need for a direct connection, and adds flexibility to how we >> can deliver the commands. Functionally they are very similar however. >> >> Cheers, >> Christian >> >> On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: >> >>> Hi William, >>> >>> > What is wrong with runes/macaroons for validating and authenticating >>> > commands? >>> >>> Runes/macaroons don't provide any protection if the machine you are >>> issuing the RPCs from is compromised. The attacker can change the >>> parameters of your RPC call and your lightning node will still gladly >>> execute it. >>> >>> > I can't imagine validating every RPC request with a hardware >>> > device and trusted display, unless you have some specific use case in >>> > mind. >>> >>> I think that this is because you have the wrong idea of which RPCs >>> this is supposed to protect. This is useful for the RPCs that actually >>> involve paying something (channel open, channel close, pay invoice). >>> This isn't useful for "read" RPCs (listing channels). >>> >>> Making an on-chain operation or paying an invoice is something that is >>> infrequent enough for the vast majority of nodes that it makes sense >>> to validate it manually. Also, this is fully configurable: you can >>> choose which RPCs you want to protect that way and which RPCs you want >>> to keep open. >>> >>> Thanks, >>> Bastien >>> >>> Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : >>> > >>> > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: >>> > >Hey Zman, >>> > > >>> > >I saw the announcement about the commando plugin, and it was actually >>> > >one of the reasons I wanted to write up what I had in mind, because >>> > >while commando also uses a lightning connection to send commands to a >>> > >lightning node, it was missing what in my opinion is the most important >>> > >part: having all of Bolt 8 handled by the HSM and validating commands >>> > >using a trusted display. >>> > >>> > What is wrong with runes/macaroons for validating and authenticating >>> > commands? I can't imagine validating every RPC request with a hardware >>> > device and trusted display, unless you have some specific use case in >>> > mind. >>> > >>> > Will >>> ___ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Hey Christian, You're right, if we create runes inside the HSM then we end up with the same security model. It then boils down to whether we'd rather implement Bolt 8 or rune management inside an HSM! I'd prefer Bolt 8, as I think it has more universality (and is simpler), but it could be worth experimenting with both approaches. It will also be interesting to see how we actually configure rights (access control) on the lightning node side. That really deserves some implementation work to flesh out that kind of details. Cheers, Bastien Le ven. 8 sept. 2023 à 16:51, Christian Decker a écrit : > Very interesting proposal, though as Will points out we could implement > the same using runes: have the rune be managed by the hardware wallet, and > commit the rune used to authenticate the RPC call commit to the call's > payload. That way a potentially compromised client cannot authenticate > arbitrary calls, since the hardware wallet is required to associate a rune > with it, giving it a chance for review. > > This is similar to how authentication of RPC calls works in greenlight, > where the node host is not trusted, and we need to pass the authenticated > commands forward to the signer for verification before processing any > signature request from the node. We chose to authenticate the payload > rather than the transport (which is what partonnere does) because it > removes the need for a direct connection, and adds flexibility to how we > can deliver the commands. Functionally they are very similar however. > > Cheers, > Christian > > On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: > >> Hi William, >> >> > What is wrong with runes/macaroons for validating and authenticating >> > commands? >> >> Runes/macaroons don't provide any protection if the machine you are >> issuing the RPCs from is compromised. The attacker can change the >> parameters of your RPC call and your lightning node will still gladly >> execute it. >> >> > I can't imagine validating every RPC request with a hardware >> > device and trusted display, unless you have some specific use case in >> > mind. >> >> I think that this is because you have the wrong idea of which RPCs >> this is supposed to protect. This is useful for the RPCs that actually >> involve paying something (channel open, channel close, pay invoice). >> This isn't useful for "read" RPCs (listing channels). >> >> Making an on-chain operation or paying an invoice is something that is >> infrequent enough for the vast majority of nodes that it makes sense >> to validate it manually. Also, this is fully configurable: you can >> choose which RPCs you want to protect that way and which RPCs you want >> to keep open. >> >> Thanks, >> Bastien >> >> Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : >> > >> > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: >> > >Hey Zman, >> > > >> > >I saw the announcement about the commando plugin, and it was actually >> > >one of the reasons I wanted to write up what I had in mind, because >> > >while commando also uses a lightning connection to send commands to a >> > >lightning node, it was missing what in my opinion is the most important >> > >part: having all of Bolt 8 handled by the HSM and validating commands >> > >using a trusted display. >> > >> > What is wrong with runes/macaroons for validating and authenticating >> > commands? I can't imagine validating every RPC request with a hardware >> > device and trusted display, unless you have some specific use case in >> > mind. >> > >> > Will >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Very interesting proposal, though as Will points out we could implement the same using runes: have the rune be managed by the hardware wallet, and commit the rune used to authenticate the RPC call commit to the call's payload. That way a potentially compromised client cannot authenticate arbitrary calls, since the hardware wallet is required to associate a rune with it, giving it a chance for review. This is similar to how authentication of RPC calls works in greenlight, where the node host is not trusted, and we need to pass the authenticated commands forward to the signer for verification before processing any signature request from the node. We chose to authenticate the payload rather than the transport (which is what partonnere does) because it removes the need for a direct connection, and adds flexibility to how we can deliver the commands. Functionally they are very similar however. Cheers, Christian On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: > Hi William, > > > What is wrong with runes/macaroons for validating and authenticating > > commands? > > Runes/macaroons don't provide any protection if the machine you are > issuing the RPCs from is compromised. The attacker can change the > parameters of your RPC call and your lightning node will still gladly > execute it. > > > I can't imagine validating every RPC request with a hardware > > device and trusted display, unless you have some specific use case in > > mind. > > I think that this is because you have the wrong idea of which RPCs > this is supposed to protect. This is useful for the RPCs that actually > involve paying something (channel open, channel close, pay invoice). > This isn't useful for "read" RPCs (listing channels). > > Making an on-chain operation or paying an invoice is something that is > infrequent enough for the vast majority of nodes that it makes sense > to validate it manually. Also, this is fully configurable: you can > choose which RPCs you want to protect that way and which RPCs you want > to keep open. > > Thanks, > Bastien > > Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : > > > > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: > > >Hey Zman, > > > > > >I saw the announcement about the commando plugin, and it was actually > > >one of the reasons I wanted to write up what I had in mind, because > > >while commando also uses a lightning connection to send commands to a > > >lightning node, it was missing what in my opinion is the most important > > >part: having all of Bolt 8 handled by the HSM and validating commands > > >using a trusted display. > > > > What is wrong with runes/macaroons for validating and authenticating > > commands? I can't imagine validating every RPC request with a hardware > > device and trusted display, unless you have some specific use case in > > mind. > > > > Will > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Hi William, > What is wrong with runes/macaroons for validating and authenticating > commands? Runes/macaroons don't provide any protection if the machine you are issuing the RPCs from is compromised. The attacker can change the parameters of your RPC call and your lightning node will still gladly execute it. > I can't imagine validating every RPC request with a hardware > device and trusted display, unless you have some specific use case in > mind. I think that this is because you have the wrong idea of which RPCs this is supposed to protect. This is useful for the RPCs that actually involve paying something (channel open, channel close, pay invoice). This isn't useful for "read" RPCs (listing channels). Making an on-chain operation or paying an invoice is something that is infrequent enough for the vast majority of nodes that it makes sense to validate it manually. Also, this is fully configurable: you can choose which RPCs you want to protect that way and which RPCs you want to keep open. Thanks, Bastien Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : > > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: > >Hey Zman, > > > >I saw the announcement about the commando plugin, and it was actually > >one of the reasons I wanted to write up what I had in mind, because > >while commando also uses a lightning connection to send commands to a > >lightning node, it was missing what in my opinion is the most important > >part: having all of Bolt 8 handled by the HSM and validating commands > >using a trusted display. > > What is wrong with runes/macaroons for validating and authenticating > commands? I can't imagine validating every RPC request with a hardware > device and trusted display, unless you have some specific use case in > mind. > > Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: Hey Zman, I saw the announcement about the commando plugin, and it was actually one of the reasons I wanted to write up what I had in mind, because while commando also uses a lightning connection to send commands to a lightning node, it was missing what in my opinion is the most important part: having all of Bolt 8 handled by the HSM and validating commands using a trusted display. What is wrong with runes/macaroons for validating and authenticating commands? I can't imagine validating every RPC request with a hardware device and trusted display, unless you have some specific use case in mind. Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Hey Zman, I saw the announcement about the commando plugin, and it was actually one of the reasons I wanted to write up what I had in mind, because while commando also uses a lightning connection to send commands to a lightning node, it was missing what in my opinion is the most important part: having all of Bolt 8 handled by the HSM and validating commands using a trusted display. That is what really brings additional security without compromising UX, and enabling secure remote control from a mobile phone. Cheers, Bastien Le mer. 6 sept. 2023 à 00:59, ZmnSCPxj a écrit : > > Good morning t-bast, > > CLN already has something similar in standard CLN distrib: https://docs.corelightning.org/docs/commando > > However it is tied specifically to the CLN command set. > Nevertheless, it is largely the same idea, just CLN-specific. > > Regards, > ZmnSCPxj > > > Sent with Proton Mail secure email. > > --- Original Message --- > On Tuesday, September 5th, 2023 at 5:26 PM, Bastien TEINTURIER < bast...@acinq.fr> wrote: > > > > Good morning list, > > > > I have just opened a PR to the bLIPs repository [1] to document an idea > > that I started investigating a long time ago and had already discussed > > with a few people, but never found the time to write it up before. > > > > This is a very simple architecture to securely send administrative > > commands to your lightning node (such as opening a channel or paying > > an invoice) from an untrusted machine (laptop, mobile phone or even > > smart watch, let's be crazy), by using an HSM acting as a whitelisted > > lightning peer (by implementing Bolt 8 entirely inside the HSM). The > > interesting part is that it requires almost nothing new on the lightning > > node itself, since we simply use a standard lightning connection as our > > communication channel and custom lightning messages to send commands. > > > > This should be doable for example in a custom application running on a > > Ledger Nano S [2], which is what I had started investigating. > > > > The bLIP still needs some work on the actual commands (and potentially > > their encoding), but the interesting part is mostly the HSM app (the > > rest is probably bikeshedding). > > > > If someone wants to actually work on implementing this, I think it > > would be very useful! I'd gladly volunteer to specify this better and > > review the implementation. Maybe that kind of work could be done under > > an open-source grant for example. > > > > Cheers, > > Bastien > > > > [1] https://github.com/lightning/blips/pull/28 > > [2] https://developers.ledger.com/docs/embedded-app/framework/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Good morning t-bast, CLN already has something similar in standard CLN distrib: https://docs.corelightning.org/docs/commando However it is tied specifically to the CLN command set. Nevertheless, it is largely the same idea, just CLN-specific. Regards, ZmnSCPxj Sent with Proton Mail secure email. --- Original Message --- On Tuesday, September 5th, 2023 at 5:26 PM, Bastien TEINTURIER wrote: > Good morning list, > > I have just opened a PR to the bLIPs repository [1] to document an idea > that I started investigating a long time ago and had already discussed > with a few people, but never found the time to write it up before. > > This is a very simple architecture to securely send administrative > commands to your lightning node (such as opening a channel or paying > an invoice) from an untrusted machine (laptop, mobile phone or even > smart watch, let's be crazy), by using an HSM acting as a whitelisted > lightning peer (by implementing Bolt 8 entirely inside the HSM). The > interesting part is that it requires almost nothing new on the lightning > node itself, since we simply use a standard lightning connection as our > communication channel and custom lightning messages to send commands. > > This should be doable for example in a custom application running on a > Ledger Nano S [2], which is what I had started investigating. > > The bLIP still needs some work on the actual commands (and potentially > their encoding), but the interesting part is mostly the HSM app (the > rest is probably bikeshedding). > > If someone wants to actually work on implementing this, I think it > would be very useful! I'd gladly volunteer to specify this better and > review the implementation. Maybe that kind of work could be done under > an open-source grant for example. > > Cheers, > Bastien > > [1] https://github.com/lightning/blips/pull/28 > [2] https://developers.ledger.com/docs/embedded-app/framework/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Remotely control your lightning node from your favorite HSM
Good morning list, I have just opened a PR to the bLIPs repository [1] to document an idea that I started investigating a long time ago and had already discussed with a few people, but never found the time to write it up before. This is a very simple architecture to securely send administrative commands to your lightning node (such as opening a channel or paying an invoice) from an untrusted machine (laptop, mobile phone or even smart watch, let's be crazy), by using an HSM acting as a whitelisted lightning peer (by implementing Bolt 8 entirely inside the HSM). The interesting part is that it requires almost nothing new on the lightning node itself, since we simply use a standard lightning connection as our communication channel and custom lightning messages to send commands. This should be doable for example in a custom application running on a Ledger Nano S [2], which is what I had started investigating. The bLIP still needs some work on the actual commands (and potentially their encoding), but the interesting part is mostly the HSM app (the rest is probably bikeshedding). If someone wants to actually work on implementing this, I think it would be very useful! I'd gladly volunteer to specify this better and review the implementation. Maybe that kind of work could be done under an open-source grant for example. Cheers, Bastien [1] https://github.com/lightning/blips/pull/28 [2] https://developers.ledger.com/docs/embedded-app/framework/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
