New scheme for Privacy State Token: Scrappy

[akakou]

This proposal is making Scrappy(SeCure Rate Assuring Protocol with PrivacY), a new scheme with strong privacy for Privacy State Token..

Scrappy is a rate-limiter the same as Privacy Pass, but this restants to the timing correlation attack. Also, Scrappy works as E2E (between users and web service) in the hot paths (i.e., sign and verify), so that the issuer does not need to receive high access from users.

Slides: https://speakerdeck.com/akakou/scrappy-and-view-of-applying-to-web Base paper: https://www.ndss-symposium.org/ndss-paper/scrappy-secure-rate-assuring-protocol-with-privacy/

Note

• Although Scrappy mainly assumes the user has a unique resource in the hardware device (in particular, the TPM), we can use other unique resources, the same as the Trust Token API.
• TODO

Other Reference

Privacy State Token: https://developers.google.com/privacy-sandbox/protections/private-state-tokens?hl=en

[akakou]

This is Abstracts of Scrappy

Preventing abusive activities caused by adversaries accessing online services at a rate exceeding that expected by websites has become an ever-increasing problem. CAPTCHAs and SMS authentication are widely used to provide a solution by implementing rate limiting, although they are becoming less effective, and some are considered privacy-invasive. In light of this, many studies have proposed better rate-limiting systems that protect the privacy of legitimate users while blocking malicious actors. However, they suffer from one or more shortcomings: (1) assume trust in the underlying hardware and (2) are vulnerable to side-channel attacks. Motivated by the aforementioned issues, this paper proposes Scrappy: SeCure Rate Assuring Protocol with PrivacY. Scrappy allows clients to generate unforgeable yet unlinkable rate-assuring proofs, which provides the server with cryptographic guarantees that the client is not misbehaving. We design Scrappy using a combination of DAA and hardware security devices. Scrappy is implemented over three types of devices, including one that can immediately be deployed in the real world. Our baseline evaluation shows that the end-to-end latency of Scrappy is minimal, taking only 0.32 seconds, and uses only 679 bytes of bandwidth when transferring necessary data. We also conduct an extensive security evaluation, showing that the rate-limiting capability of Scrappy is unaffected even if the hardware security device is compromised.

[akakou]

@dvorak42

I would like to ask that is this repository a proper place to propose this? Or is it better to propose it to this repository?

[dvorak42]

Is the particular proposal to add support for this as a new token type for the Private State Token API (fka Trust Token)? If so, then the https://github.com/WICG/trust-token-api is probably a better place to discuss that. If you'd like to present this variant of a token to the AFCG, then here is probably right to have that discussion.

[akakou]

Thank you for your answers!

I think that I would like to propose Scrappy as one of the token types for Private State Token. This was because the use case and property are similar, and we can reuse the discussion in the past.

(Now I have found that Privacy State Token's interface is slightly different from Scrappy's required one. Therefore, if it is hard to fill the gap, maybe we will go back to AFCG.)

[akakou]

@dvorak42 Is this reasonable? I would like to know your opinion if you are ok.

[dvorak42]

If you can open an issue on the other repo, we can discuss more there. I think some of the attributes of Scrappy might be interesting for PST, though I haven't had time to do an in-depth read of it yet. I'll point out the issue to other folks on the team to see if they have thoughts.

[akakou]

@dvorak42

I re-read your comments and may misread the other repo you said. Did you mean the repository for Private State Token or my new repository?

[dvorak42]

Yes, the Private State Tokens repository. Unfortunately with IETF happening this week and preparation for it, I haven't had a chance to review the issue in more detail yet.

[akakou]

@dvorak42 Thank you for your answer. I see!

Regarding the review, please don't worry. There is no reason to hurry, and I hope you review this when you are free.

Have fun at the IETF meeting!

[akakou]

By the way, I could present it at the community group meeting if Scrappy is a little too complex. (However, due to my low English listening skills, I hope to respond to text questions instead of voice conversations.)

[dvorak42]

This week's meeting is a bit full, but perhaps you'd be able to present it at one of the April AFCG meetings?

[akakou]

@dvorak42 Good! How about the meeting on April 13th?

[dvorak42]

That should work. I'll add you to the agenda for that date. (note the time change for AFCG meetings due to Daylights Saving Time)

On Tue, Mar 26, 2024, 8:42 AM akakou @.***> wrote:

@dvorak42 https://github.com/dvorak42 Good! How about the meeting on April 13th?

— Reply to this email directly, view it on GitHub https://github.com/antifraudcg/proposals/issues/21#issuecomment-2020327951, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFHK5LGV3KVI6YM3I2SFTY2FULXAVCNFSM6AAAAABECVAADKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGMZDOOJVGE . You are receiving this because you were mentioned.Message ID: @.***>

[akakou]

Thank you!! I'm looking forward to presenting it on that day.

[akakou]

We discussed in the meeting:

https://github.com/antifraudcg/meetings/blob/main/2024/04-12.md

[akakou]

Sorry, the link to the slide was incorrect, but I have now fixed it.