New scheme for Privacy State Token: Scrappy

akakou commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

dvorak42 commented 6 months ago

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.