Authenticate use of offer blinded paths #3139

A nonce is generated in OfferBuilder::deriving_signing_pubkey from an EntropySource for use in Offer::metadata. The same nonce will need to be included as recipient data in any blinded paths in the Offer. Increase the visibility to allow for this.

Nonce is used when constructing Offer::metadata and will soon be need when constructing BlindedPath for use in authentication. Move it to separate module now that it is public and will be more widely used.

When using OfferBuilder::deriving_signing_pubkey, the nonce generated needs to be the same one included in any OfferBuilder::paths. This is because the nonce is used along with the offer TLVs to derive a signing pubkey and will soon be elided from the metadata entirely.

Invoice requests are authenticated by checking the metadata in the corresponding offer. For offers using blinded paths, this will simply be a 128-bit nonce. Allows checking this nonce explicitly instead of the metadata. This will be used by an upcoming change that includes the nonce in the offer's blinded paths instead of the metadata, which mitigate de-anonymization attacks.

Metadata is an internal type used within Offer messages. For any constructed message, Metadata::Bytes is always used. The other variants are used during construction or verification time. Document this and debug_assert!(false) accordingly.

To authenticate that an InvoiceRequest is for a valid Offer, include the nonce from the Offer::metadata in the Offer::paths. This can be used to prevent de-anonymization attacks where an attacker sends requests using self-constructed paths to nodes near the Offer::paths' introduction nodes.

When an InvoiceRequest is handled with an OfferContext, use the containing nonce to verify that it is for a valid Offer. Otherwise, fall back to using Offer::metadata, which also contains the nonce. The latter is useful for supporting offers without blinded paths or those created prior to including an OffersContext in their blinded paths.

When an Offer uses blinded paths, its metadata consists of a nonce used to derive its signing keys. Now that the blinded paths contain this nonce, elide the metadata as it is now redundant. This saves space and also makes it impossible to derive the signing keys if an invoice request is received with the incorrect nonce. The nonce shouldn't be revealed in this case either to prevent de-anonymization attacks.

When a Bolt12Invoice is handled with an OfferContext, use the containing payment_id to verify that it is for a pending outbound payment. Only invoices for refunds without any blinded paths can be verified without an OfferContext.

When an invoice or invoice request cannot be authenticated from an OffersContext, simply do not respond instead of sending an InvoiceError message. According to BOLT4, messages sent over a blinded path not intended for its use MUST be ignored.

When using InvoiceRequestBuilder::deriving_payer_id, the nonce generated needs to be the same one included in any reply path. This is because the nonce is used along with the invoice request TLVs to derive a payer id. While this data is also included in the payer_metadata, including it in the blinded path would allow reducing the amount of data needed there to just enough to provide entropy (i.e., 16 bytes). This is more important for Refund because it can be transmitted via a QR code. But using the same payer_metadata structure for both InvoiceRequest and Refund would be beneficial to avoid more code.

When using RefundBuilder::deriving_payer_id, the nonce generated needs to be the same one included in any RefundBuilder::paths. This is because the nonce is used along with the refund TLVs to derive a payer id and will soon be used to authenticate any invoices.

Invoices are authenticated by checking the payer metadata in the corresponding invoice request or refund. For all invoices requests and for refunds using blinded paths, this will be the encrypted payment id and a 128-bit nonce. Allows checking the unencrypted payment id and nonce explicitly instead of the payer metadata. This will be used by an upcoming change that includes the payment id and nonce in the invoice request's reply path and the refund's blinded paths instead of completely in the payer metadata, which mitigates de-anonymization attacks.

To authenticate that a Bolt12Invoice is for a valid InvoiceRequest or Refund, include the nonce from the payer_metadata in the InvoiceRequest reply path or Refund::paths, respectively. This can be used to prevent de-anonymization attacks where an attacker sends invoices using self-constructed paths to nodes near the blinded paths' introduction nodes.

When a Bolt12Invoice is handled with an OfferContext, use both the containing payment_id and nonce to verify that it is for a pending outbound payment. Previously, the nonce the payment_id were taken from the payer_metadata and the latter was compared against the payment_id in the OfferContext. The payer_metadata thus no longer needs to include either when a blinded path is used. However, some payer_metadata will still be needed as per the spec.

When authenticating that an invoice is for a valid invoice request, the payer metadata is needed. Some of this data will be removed in the next commit and instead be included in the message context of the request's reply path. Add this data to Event::InvoiceReceived so that asynchronous invoice handling can verify properly.

InvoiceRequest and Refund have payer_metadata which consists of an encrypted payment id and a nonce used to derive its signing keys and authenticate any corresponding invoices. Now that the blinded paths include this data in their OffersContext, remove the nonce as it is now redundant. Keep the encrypted payment id as some data is needed in the payer metadata according to the spec. This saves space and prevents de-anonymization attacks as along as the nonce isn't revealed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Authenticate use of offer blinded paths #3139

Authenticate use of offer blinded paths #3139

Commits on Jul 22, 2024