Privacy Pass: Anonymously Limiting Abuse

Privacy Pass is a protocol for anonymously transmitting trust between systems using an efficient new form of blind signatures. It's been used in production for letting Tor users past CAPTCHAs anonymously and shows promise in a number of other applications.

This talk gives a detailed technical description of the Privacy Pass protocol along with design rationales, context, and numbers.

Transcript

1. Privacy Pass:
   Anonymously Limiting Abuse
   George Tankersley
   https://twitter.com/gtank__
   

   View Slide

2. Our scene:
   Cloudflare vs Tor, 2016
   

   View Slide

3. Cloudflare vs Tor
   Cloudflare
   ● Massive global CDN
   ● 100+ PoPs, “10% of the web”
   ● Not just a CDN, does extra logic
   Tor Project
   ● Distributed anonymity network
   ● ~6000 relays, ~2M users / day,
   ~200Gbit/s
   ● Tor Browser Bundle (Firefox ESR)
   

   View Slide

4. Cloudflare vs Tor
   Two things to know:
   1. Tor hated Cloudflare
   2. They were very loud about it
   

   View Slide

5. It was all very reasonable
   

   View Slide

6. The problem was CAPTCHAs
   Cloudfare use of IP reputation + Tor exits’ terrible IP rep
   

   View Slide

7. The problem was CAPTCHAs
   Averages from 7 days’ traffic:
   ● 1.6 trillion web requests
   ● 780 million from Tor exits (0.05% of traffic)
   ● 16.5B CAPTCHAs served (1.04% of global requests)
   ● 132.6M CAPTCHAs served to Tor (0.8% of CAPTCHAs,
   17% of Tor requests)
   Disproportionately challenging Tor users.
   

   View Slide

8. They noticed
   

   View Slide

9. Social Problem, Technical Problem
   

   View Slide

10. Technical solutions
    First, nuke the office IP reputation (incentive to improve!)
    Then
    ● Adopt reCAPTCHA v2
    ● Add option to whitelist Tor network as a “country”
    ● Alter the internal treatment of Tor traffic
    ● Invent some clever crypto protocol?
    

    View Slide

11. Technical solutions
    First, nuke the office IP reputation (incentive to improve!)
    Then
    ● Adopt reCAPTCHA v2
    ● Add option to whitelist Tor network as a “country”
    ● Alter the internal treatment of Tor traffic
    ● Invent some clever crypto protocol?
    Sounds good!
    

    View Slide

12. Technical solution
    A new protocol needs to meet the requirements of all parties:
    ● Cloudflare wants to protect websites from automated abuse.
    ● Tor Browser wants to protect the anonymity of its users.
    ● Users want to solve fewer CAPTCHAs.
    What if we gave users an untrackable token that proves they solved a CAPTCHA?
    

    View Slide

13. Privacy Pass
    Unlinkable, unforgeable, single-use anonymous credential
    Meets everyone’s needs:
    ● Allows Cloudflare to rate-limit with CAPTCHAs
    ● Prevents Cloudflare from tracking users
    ● Allows users to bypass redundant CAPTCHAs
    And they’re more efficient in batches!
    

    View Slide

14. Prerequisite: blind signatures
    Idea: A user wants a signer to sign a message without learning its contents
    Functions: sign, verify, blind, unblind
    blindMessage := Blind(message)
    blindSignature := Sign(blindedMessage)
    clearSignature := Unblind(blindSignature)
    Verify(message, clearSignature) => true
    

    View Slide

15. Signatures with RSA
    Public (N, e) and private d
    N = p*q and d = 1/e mod (N)
    Generate a signature S by
    S = Md mod N
    Verify it by checking that
    Se == M mod N
    (Md)e = M(1/e)*e = M1 = M mod N
    N is the modulus, product of two primes
    e is the public exponent, d is its inverse
    is magic, do not let it sense fear
    

    View Slide

16. Blind Signatures with RSA
    Generate a blinding factor re
    Blind the message:
    M
    blind
    = (re)M mod N
    S
    blind
    = (M
    blind
    )d mod N
    r also has an inverse, 1/r
    To unblind a signature:
    S = (S
    blind
    ) * (1/r) mod N
    = (M
    blind
    )d * (1/r)
    = (reM)d * (1/r)
    = (M)d(re)d * (1/r)
    = Md * red * (1/r)
    = Md mod N
    

    View Slide

17. Prerequisite: blind signatures
    Blind signatures provide unlinkability.
    Unlinkability means:
    ● Can’t tell that blinded/unblinded signatures are related
    ● Signer can’t associate unblinded (message, signature) with
    the blinded message it signed.
    

    View Slide

18. The protocol, generally
    Issuance Phase
    1. User encounters a CAPTCHA or other challenge
    2. User generates [many] blinded tokens, submits them with solution
    3. Server signs tokens and returns them to user with response
    4. User unblinds signatures and stores (token, signature) pairs.
    Redemption Phase
    1. User encounters a CAPTCHA or other challenge
    2. User submits a (token, signature) pair instead of solving
    3. Server validates token, then grants access or rejects
    

    View Slide

19. Issuance, in detail
    1. User generates a random token t and a blinding factor r
    2. User calculates T = HashToGroup(t) and M = rT
    3. User sends M to the server along with the CAPTCHA solution
    4. Server validates solution with the challenger and signs Z = xM = xrT
    5. Server generates ZK proof D showing that DLEQ(Z/M == Y/G)
    6. Server sends (Z, D) to user
    7. User checks the proof D against the sent tokens and the server’s public key
    commitment Y to establish that the server is using a consistent key.
    8. User unblinds Z to calculate N = (1/r)Z = xT and stores (t, N)
    

    View Slide

20. Redemption, in detail
    1. User calculates request binding data R for the request they want to make
    2. User chooses unspent token t to redeem and retrieves (t, N)
    3. User calculates a shared key sk = Hash(t || N)
    4. User sends a pass (t, HMAC(sk, R)) to the server with the HTTP request
    5. Server calculates R’ from observed request data
    6. Server checks the double-spend list for t
    7. Server calculates T = HashToGroup(t), N = xT and sk = Hash(t || N)
    8. Server checks that HMAC(sk, R’) matches the user-supplied value
    9. If HMAC matches, server processes the request and stores a record of t
    

    View Slide

21. Issuance and Redemption Flows
    1-RTT best we can do; there is no known 0-RTT blind signing
    

    View Slide

22. Even more detail (for later)
    Design rationale: https://privacypass.github.io/protocol
    Protocol spec:
    github.com/privacypass/challenge-bypass-extension/blob/master/PROTOCOL.md
    Paper: https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf
    Brave's improved variant: https://github.com/brave-intl/challenge-bypass-ristretto
    

    View Slide

23. Security & Privacy Guarantees
    1. The server can’t track users through the tokens
    2. The server can’t segment users with selective key use
    3. The server can’t maliciously craft tokens or signatures
    4. Users can’t create tokens without the server’s approval
    5. Users can’t use a token more than once
    6. Users can clear their state at any time
    

    View Slide

24. Server can’t track users through tokens
    Because of the blinding, each token spend is unlinkable both from its issuance
    request and from other tokens in the same issued batch.
    But if a user tries to spend the same token twice, those two requests will be linkable
    to each other (still not to issuance!)
    Extensions: traceability would allow you to link a token to its issued batch on double
    spend. Complexity tradeoff.
    

    View Slide

25. Server can’t segment users via keys
    Server could try to tag users by using unique signing keys.
    But it can’t go undetected w/ ZK proofs of key consistency
    Epochs/rotation and publishing key commitments:
    ● Signed software
    ● Transparency? Logs, auditors
    ● Other (e.g. Tor consensus)
    Tradeoff: number of simultaneously valid keys vs anon set
    

    View Slide

26. Server can’t maliciously craft tokens or signatures
    Server might try to tag users with structured responses.
    Can’t structure tokens: client generates them!
    Can’t structure signatures: unblinding is keyed randomization!
    

    View Slide

27. Users can’t create tokens without the server’s approval
    Token redemption involves (t, N) where N = k*H(t)
    A valid signature requires k, which is the server’s secret.
    Type of algorithm called an oblivious pseudorandom function.
    

    View Slide

28. Users can’t spend a token more than once
    Token redemption involves (t, N) where N = k*H(t)
    User incentives:
    ● t is a unique value. If server sees it twice, can link IPs/requests.
    Server enforcement:
    ● Maintains double-spend list to deny reuse during given key epoch.
    

    View Slide

29. Users can clear their state at any time
    Especially common for Tor Browser: “New Identity” button
    Protocol doesn’t assume any long-term user identity or keys
    Complete state clearance looks like a new user
    

    View Slide

30. Operational Needs
    1. Signing/Validation service (low maintenance, ~stateless)
    2. Key management and rotation (tunable; security/privacy)
    3. Trusted key publication endpoint or client software (TBB)
    4. Double-spend accumulator (tunable; potential SPOF)
    

    View Slide

31. In practice
    We redeem tokens for a TTL’d clearance cookie (safe because SOP).
    ● Token is effectively an anonymous, cross-origin precookie
    Probabilistic double-spend. We avoid SPOF by allowing occasional false negatives.
    We use an elliptic curve VOPRF for 10x better bandwidth & speed than blind RSA.
    ● Was necessary at one point to fit tokens in a header
    ● Uses NIST P-256 for compatibility. Not optimal. Use Ristretto now.
    Binding data is Host and Path concatenated.
    

    View Slide

32. Deployment stats
    Released Nov 2018, ~108k downloads now
    (Chrome: 86,738; Firefox: 21, 161)
    The number of redemptions occurring
    peaked globally at 2000 qps and for Tor
    users at 200 qps during the surveyed week.
    Not an experiment! Privacy Pass is still
    running. In absolute numbers it’s more
    popular with VPN users than Tor.
    Operation Bytes
    Signing request 57 + 63 * N
    Signing response 295 + 121 * N
    Redemption request 396
    Bandwidth Overhead* (batch of N)
    *Median request and response sizes for Tor users
    were 700–800 bytes and 5–6 KB.
    

    View Slide

33. Extensions and Future Work
    ● Performance: faster curves, better impl, batch & vectorize
    ○ Brave is already doing this!
    ● Standard AC properties
    ○ Attributes (open and/or hidden)
    ○ Tracing
    ● Asymmetric version (issuer != verifier)
    ● Composition with macaroons (anon “OAuth” delegation?)
    ● Post-quantum primitives: lattice, isogeny variants
    

    View Slide

34. Questions?
    George Tankersley
    https://twitter.com/gtank__
    

    View Slide