📅 Original date posted:2023-09-08
🗒️ Summary of this message: The discussion is about implementing security measures for RPC calls in a lightning node, either using Bolt 8 or managing runes inside a hardware security module (HSM). The configuration of access control on the lightning node side is also mentioned.
📝 Original message:
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 <decker.christian at gmail.com>
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 <bastien at acinq.fr> 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 <jb55 at jb55.com> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230909/3408f167/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-09-12 08:59:58
in reply to nevent1q…u46k
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-09-12 08:59:58Event JSON
{
"id": "de9617bbdba7e848eb802748a1dfbba4664364fff493f1bf777257f6f2b1773e",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1694509198,
"kind": 1,
"tags": [
[
"e",
"a9e03a18a3a98b8c99b8e539d8b45eea1dd49ad05580430dd081544b51147e85",
"",
"root"
],
[
"e",
"f6c75e06b822ec980cd8da0c78216b49db77f32e530b500ee0d433ac6502bcdc",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2023-09-08\n🗒️ Summary of this message: The discussion is about implementing security measures for RPC calls in a lightning node, either using Bolt 8 or managing runes inside a hardware security module (HSM). The configuration of access control on the lightning node side is also mentioned.\n📝 Original message:\nHey Christian,\n\nYou're right, if we create runes inside the HSM then we end up with the\nsame security model.\nIt then boils down to whether we'd rather implement Bolt 8 or rune\nmanagement inside an HSM!\nI'd prefer Bolt 8, as I think it has more universality (and is simpler),\nbut it could be worth experimenting with both approaches.\n\nIt will also be interesting to see how we actually configure rights (access\ncontrol) on the lightning node side.\nThat really deserves some implementation work to flesh out that kind of\ndetails.\n\nCheers,\nBastien\n\nLe ven. 8 sept. 2023 à 16:51, Christian Decker \u003cdecker.christian at gmail.com\u003e\na écrit :\n\n\u003e Very interesting proposal, though as Will points out we could implement\n\u003e the same using runes: have the rune be managed by the hardware wallet, and\n\u003e commit the rune used to authenticate the RPC call commit to the call's\n\u003e payload. That way a potentially compromised client cannot authenticate\n\u003e arbitrary calls, since the hardware wallet is required to associate a rune\n\u003e with it, giving it a chance for review.\n\u003e\n\u003e This is similar to how authentication of RPC calls works in greenlight,\n\u003e where the node host is not trusted, and we need to pass the authenticated\n\u003e commands forward to the signer for verification before processing any\n\u003e signature request from the node. We chose to authenticate the payload\n\u003e rather than the transport (which is what partonnere does) because it\n\u003e removes the need for a direct connection, and adds flexibility to how we\n\u003e can deliver the commands. Functionally they are very similar however.\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e\n\u003e On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\n\u003e\u003e Hi William,\n\u003e\u003e\n\u003e\u003e \u003e What is wrong with runes/macaroons for validating and authenticating\n\u003e\u003e \u003e commands?\n\u003e\u003e\n\u003e\u003e Runes/macaroons don't provide any protection if the machine you are\n\u003e\u003e issuing the RPCs from is compromised. The attacker can change the\n\u003e\u003e parameters of your RPC call and your lightning node will still gladly\n\u003e\u003e execute it.\n\u003e\u003e\n\u003e\u003e \u003e I can't imagine validating every RPC request with a hardware\n\u003e\u003e \u003e device and trusted display, unless you have some specific use case in\n\u003e\u003e \u003e mind.\n\u003e\u003e\n\u003e\u003e I think that this is because you have the wrong idea of which RPCs\n\u003e\u003e this is supposed to protect. This is useful for the RPCs that actually\n\u003e\u003e involve paying something (channel open, channel close, pay invoice).\n\u003e\u003e This isn't useful for \"read\" RPCs (listing channels).\n\u003e\u003e\n\u003e\u003e Making an on-chain operation or paying an invoice is something that is\n\u003e\u003e infrequent enough for the vast majority of nodes that it makes sense\n\u003e\u003e to validate it manually. Also, this is fully configurable: you can\n\u003e\u003e choose which RPCs you want to protect that way and which RPCs you want\n\u003e\u003e to keep open.\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e Le mer. 6 sept. 2023 à 17:42, William Casarin \u003cjb55 at jb55.com\u003e a écrit :\n\u003e\u003e \u003e\n\u003e\u003e \u003e On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote:\n\u003e\u003e \u003e \u003eHey Zman,\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003eI saw the announcement about the commando plugin, and it was actually\n\u003e\u003e \u003e \u003eone of the reasons I wanted to write up what I had in mind, because\n\u003e\u003e \u003e \u003ewhile commando also uses a lightning connection to send commands to a\n\u003e\u003e \u003e \u003elightning node, it was missing what in my opinion is the most important\n\u003e\u003e \u003e \u003epart: having all of Bolt 8 handled by the HSM and validating commands\n\u003e\u003e \u003e \u003eusing a trusted display.\n\u003e\u003e \u003e\n\u003e\u003e \u003e What is wrong with runes/macaroons for validating and authenticating\n\u003e\u003e \u003e commands? I can't imagine validating every RPC request with a hardware\n\u003e\u003e \u003e device and trusted display, unless you have some specific use case in\n\u003e\u003e \u003e mind.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Will\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230909/3408f167/attachment.html\u003e",
"sig": "1271f0189b22db497641a66325bdd642215653009773b1f1f0e37358f26790483831548233dd467a2dec46512e3f63f478c9c1ec072390cd359ac0785400393c"
}