Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Privacy-Enhanced) Web Revocation API #20

Open
akakou opened this issue Oct 11, 2023 · 8 comments
Open

(Privacy-Enhanced) Web Revocation API #20

akakou opened this issue Oct 11, 2023 · 8 comments

Comments

@akakou
Copy link

akakou commented Oct 11, 2023

This proposal achieves privacy-friendly revocation (i.e., ban). In particular, it makes a web servicer(i.e., web server) capable of blocking users who have previously abused them; however, it has no risk for privacy violations.

Background

As is well known, malicious actions (e.g., cheating in games) are a significant problem, including in Web applications.
To solve these problems, revoking malicious users is an excellent function to reduce fraud.

Currently, the most straightforward way of revocation is to use the user identifier strongly coupled with the user's identity.
(e.g., National ID, Phone number, IP address(?))

However, they have privacy concerns, especially user tracking by services.

Idea

This idea is for Web APIs to provide a privacy-enhanced revocation method.

It mainly consists of a cryptographic anonymous blocklisting protocol such as EPID(Enhanced Privacy ID). EPID is a signature scheme that ensures user anonymity but revocability, too. Using EPID, services can revoke users while not being able to track users. Specifically, EPID has the signature-based revocation ability that allows services to revoke users using their signature (without using the user's information).

This API provides signing and part of joining(i.e., Key generation and Credential saving) in EPID and some security/privacy measures.

Note that although EPID assumes a third-party entity (GM: Group Manager) limits the number of user's secret keys, the implementation to limit it is out of scope in this API. In other words, the proposal entrusts a defining identification method to the GM (like Secure Payment Confirmation API). In many cases, GM limits them on GM's website using IP addresses, SMS authentication, or other schemes.

Moreover, the browser and extension developers can be and add the GM in other ways.

Base ideas

Privacy-Enhanced Revocation(AFCG meetings)

Web hardware revocation API

References

EPID: Enhanced Privacy ID

Secure Payment Confirmation API

@michaelficarra
Copy link
Member

In many cases, GM limits them on GM's website using IP addresses, SMS authentication, or other schemes.

If this proposal is delegating to a third party to do rate limiting of key generation (using some mechanism not described within), what value does this proposal have over Privacy Pass?

@akakou
Copy link
Author

akakou commented Oct 18, 2023

@michaelficarra

Thank you for your question.

As you said, EPID and Privacy Pass are similar but have different features. The most essential difference is the rate limit and revocability. As far as I know, Privacy Pass mainly ensures the access rate. However, Privacy Pass does not provide the revocation method. On the other hand, EPID cannot be used for rate-limit, but it has revocation capability.

The proposal's main focus is on the revocability of the EPID.

(To be precise, the service can revoke users using a Privacy Pass if the TTP provides only one ticket to a user. However, it causes significant privacy issues as same as other identifiers.)

@akakou
Copy link
Author

akakou commented Oct 18, 2023

Moreover, their security assumptions are different. Specifically, Privacy Pass has the risk of a timing collusion attack; however, EPID does not. Instead, EPID has risks caused by malicious revocation lists, so that needs some privacy measures, as you know (detail is in Q&A 4).

@akakou
Copy link
Author

akakou commented Feb 2, 2024

I found that performance EPID is a difficult challenge, and it has the potential risk of occurring the DoS attack as explained in this.

Hopefully, there is a good solution...

@akakou
Copy link
Author

akakou commented Mar 2, 2024

Therefore, I will research to address this problem now...

@akakou
Copy link
Author

akakou commented Mar 19, 2024

I found this!

SNARKBlock: Federated Anonymous Blocklisting from Hidden Common Input Aggregate Proofs

@michaelficarra
Copy link
Member

@akakou That looks very interesting! Are you going to present this result to the group?

@akakou
Copy link
Author

akakou commented Mar 20, 2024

@michaelficarra
Thank you comment 🙏

I would like to do that.
But I have not understood all of that yet.
So I would like some time to understand the article.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants