search

tfpauly / privacy-proxy

Specifications for Privacy Proxy Implementations
Other
29 stars 11 forks source link

Rate-limited issuance request replay issue #198

Closed chris-wood closed 2 years ago

chris-wood commented 2 years ago

Ongoing work on analyzing this protocol found a potential issue with the current construction. Consider the following scenario:

  1. Client generates and sends a TokenRequest to the Attester.
  2. Attester validates the TokenRequest against the Client's long-term public key and forwards the TokenRequest to the Issuer.
  3. The attacker (or a malicious Attester) intercepts the forwarded TokenRequest, extracts TokenRequest.blinded_msg -- the blind signature message -- and constructs its own TokenRequest with a valid encrypted origin and signature, but replays TokenRequest.blinded_msg.
  4. The Issuer validates the request and returns a token response to the attacker.
  5. The attacker returns the response to the Attester, and the Attester returns the result to the Client after doing its rate limit check.

In essence, this means that an attacker can cause the Client to finish the issuance protocol with a token that was really issued under an origin that it did not choose, which is not a great property. This issue might arise a number of ways. The Attester<>Issuer channel might be compromised, or the Attester might be malicious (though the Attester is already assumed to be honest-but-curious here as it is responsible for enforcing rate limits, I don't think we want the properties of the issuance protocol to depend on the underlying channels used to send messages.) So I think this is something we ought to fix.

Fortunately, there's a couple ways we can address this (which were both proven to work). Briefly:

  1. Have the Issuer sign the token request and response transaction under a new-long term signing key.
  2. Encrypt the token request information with HPKE -- alongside the origin name -- to the Issuer, and have the Issuer encrypt and authenticate the response back to the Client under an HPKE-derived key.

The second option seems better, for a few reasons: (1) it can reuse established encap techniques from OHTTP and ODoH, (2) it ensures the attester really only learns what it needs to learn for the rate limiting enforcement (it doesn't need to see blind signature message in TokenRequest for that), and (3) it does not require any new long term key for the Issuer or signature verification on the Client.

I'm going to prepare a PR for the second option, though I'd like to hear what folks think about this issue overall.

chris-wood commented 2 years ago

Closing since the PR landed.