rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae๐
Original date posted:2023-09-08
๐๏ธ Summary of this message: A proposal suggests using runes managed by a hardware wallet to authenticate RPC calls, preventing compromised clients from making unauthorized calls.
๐ Original message:
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/20230908/57a116fe/attachment-0001.html>