Demonstration of a privacy-preserving age verification process

Rédigé par Jérôme Gorin, Martin Biéri et Côme Brocas

 - 

23 June 2022


Is it possible  to prove that one is over the age of legal majority without sharing one’s age or identity? The LINC, Olivier Blazy, Ecole Polytechnique professor and cryptography researcher, and the Pôle d’Expertise de la Régulation Numérique (PEReN – Digital platform expertise for the public) developed a possible implementation of an age-verification system that allows accessing restricted websites without sharing other personally identifiable data.

Bannière vérificaiton d'âge

A political context with the advent of new actors

Recent headlines have redrawn attention to online age-verification, either related to renewing parental control or formal notices of pornographic sites. The CNIL had the opportunity to study those questions through 2021  a set of recommendations about under-18 in the digital world and in its opinion from June 3rd about age verification to access pornographic websites.

This opinion included a recommendation to rely on a privacy-preserving system, set up by a third-party verifier during the age-verification process. The advantage of such a solution lies in particular in the implementation of mechanisms making it possible to prevent, on the one hand, that the trusted third party identifies the site or the application issuing the request for age verification and, on the other hand, to limit the capacity of the site issuing said request to identify the individual involved.

Two dimensions need to be considered in the practical application of such process: first, the creation of age information (or majority if, for example, the age-verification process only requires thresholds: “more than 18 years-old”) by an entity and secondly, the age-verification information transmission from this entity to a requesting service. Those two aspects inevitably raise issues relating to security, reliability and protection of the privacy of individuals (especially when it comes to information relating to a supposed sexual orientation). Obtaining age information (or proof of age) by the trusted third-party is not addressed explicitly here and may be subject to a latter publication. Furthermore, the Digital Platform Expertise for the Public (PEReN), has published a note on this specific topic.

 

Implementation of the demonstrator

In this sense, the LINC provides the demonstration of an “ideal” solution in this context of the development of age-verification tools. It relies on building blocks used in cryptology under the expression of “zero-knowledge proof” (see box below). These blocks allow identified individuals to prove that a statement is true without revealing information relative to that statement. This demonstrator thus proves that it is possible, through a third-party system, to guarantee individual identity protection as well as the principle of data minimization.

Cryptographic concepts in use (Olivier Blazy)

The protocol relies primarily on a cryptographic concept named “group signature”. In cryptographic terms, this primitive allows users to sign anonymously inside of a group. The expression “anonymously” is to be taken in its cryptographic sense; according to GDPR, this would be qualified as “pseudonymization”.

Considering this is a signature generated by a member of the group, it is impossible (except for an authority) to know which member generated it. To build such a primitive, we combine two fundamental blocks in cryptography:

- On one side, digital signatures (which allow a person to certify a piece of data and then anyone can verify that certificate)

- And on the other side, zero-knowledge proofs (ZK) allowing to prove knowledge of a secret without revealing it

Thanks to the combination of these primitives, an authority can generate a public key, add members to that group and provide a certificate of their own public key which is valid through the main key of the group. Then, group members are able to sign challenges for users, who in turn will be able to prove they own a challenge signed by someone belonging to the group. This way, ZK proofs guarantee both pseudonymity for the authority that processed the signature (via the ZK propriety) and the fact that it is indeed a member of that group (via the soundness propriety, namely, that no one can forge a fake proof). As a result, the service-providing website is certain of the user’s age validity without actually knowing who certified it.

olivier-blazy-nb.jpg

Olivier Blazy

Olivier Blazy is a cyber security professor in the Computer Science department of 'École Polytechnique. He has been a researcher in cryptography for 10 years, his research interest includes various topics including privacy cryptography and post-quantum cryptography. At the national level, he co-manages the CNRS Coding and Cryptography working group within the Research Group (GDR) Computer Security and the Research Group (GDR) Computer-Sicence and Mathematics.

The diagrams below allow understand how that system would works:

  • For the person, this functionality has to come in handy to the end-user (diagram 1)
  • More generally, in this ecosystem: the relevant actors and the governing system necessary for its prope (diagram 2)

     

    Schema narratif en

Diagram 1 - Graphic of the solution’s functioning, from a user’s perspective

Schema Descriptif en

Diagram 2 - Graphic of the technical functioning of the solution

 

 

Focus on the demonstrator

Published on 22 June 2022

To illustrate the mechanisms at work in the previous box, the LINC provides an open source demonstrator on the following platforms: Github, Adullact and dockerhub.io. This demo has been co-desienged with Olivier Blazy from LIX (c.f. supra)  and the development has been done with the PEReN in the context of a convention. We recommend to use the latter, as it only requires the installation of the software Docker and the use of the following command prompt once authenticated to this platform:

docker run -p 9091:9091 -p 9092:9092 -p 9093:9093 cnil/siggroup 

Its code is freely modifiable and reusable, commercially or not, under reserve of being credited.

This demonstrator simulates the functioning of the three entities that are necessary for the setup of a zero-knowledge age-verification proof exchange, i.e. :

- A website requiring age-verification for access to its content
- One or more “certified” websites to verify the user’s real age
- A “trusted” authority granting certification of those website

In the version made available by the LINC, these three entities are accessible from a browser at the following addresses: website or service (https://localhost:9093), certified third-party ( https://localhost9091), certifying authority ( https://localhost:9092).

This demonstrator illustrates the prerequisites laid out by the CNIL on the age-verification procedures for trusted third-party relying websites: the proof-of-age used includes neither the user’s real identity nor the website’s identity that provides the certificate for age verification, while ensuring that the age-verification process is compliant with the requirements specified. The certified websites for age verification have no information whatsoever on the purpose of this verification, and the user’s information and browsing habits remain confidential.

The website or service’s interface (by default localhost:9093) allows for the initialization and the download of a challenge to be signed by a certified third-party. Each downloaded challenge is unique and associated to a required age and has a limited lifespan.

The person using the service (in this case, Bob or Alice) has to upload the challenge on a certified third-party’s interface intended to verify users age (by default localhost:9091). To each identified user on this platform is associated a name and age. The demonstrator has two test-users available after initialization: Bob who is 16 years-old, and Alice, who is 25 years-old. The website’s interface also allows for the creation of new users. The challenge’s signature can only be carried out if the user has the required age to access the website (18 years-old by default). If they have the required age, the user (here, Alice) can download and share the signed challenge to the website that verifies its authenticity. The signature of the challenge is considered valid if and only if it is issued by a third-party certified by the “trusted authority”. Furthermore, it does not contain information directly revealing the user’s real identity.

The certifying authority’s interface (by default localhost:9092) allows for the simulation of certifying new third-parties authorized to verify user’s age. By default, the demonstrator has two certified third-parties for age verification. In the event a third party is deprived of its certification because its age-verification process is no longer in line with the requirements specified by the trusted authority, a revocation mechanism allows the invalidation of the signatures generated by this third-party. The accreditation process thus allows conducting age-verification audit by a “higher-trust” or “main” authority.

Areas of improvement and possible variations

The demonstrator solely focuses on the benefits of using group signature regarding user’s privacy protection. Its practical application though requires the identification of potential threats on the exchange process and the assessment of adequate security measures.

It would also be preferable that the challenge used does not include information on the age requirements in order to limit the possibilities to deduce the goals of the age verification process. This implies the possibility for the certified website to be able to generate proof for each age threshold. For instance, we could imagine taking each main legislative threshold into account: 13, 15, 16 and 18. In this way, the user can select the signed challenge corresponding to the threshold of the website or service they want to access from their browser.

From the user’s perspective, the individual must keep control of their exchanges between organisms at all times to ensure a proper sealing when exchanging the token. That exchange has to take place in the user’s terminal (browser or app). This verification process could be made easier through automated token exchange mechanisms, like those used in delegation processes (e.g. “OAuth” protocol), or through secured inscription in the user terminal.

 

Finally, the mechanisms at play in the age-verification process can also have a wider scope than age verification: they can be used to create social network accounts, access sensitive content or for certain age-restricted sales, among other examples.


Article rédigé par Jérôme Gorin, Martin Biéri et Côme Brocas