Description Titre de l'invention : Procédés et dispositifs de demande d’accès à un service fourni par un fournisseur de service. Technique antérieure L’invention se situe dans le domaine de la gestion de l’identité numérique. Plus précisément, l’invention porte sur un procédé de gestion de l’identité numérique qui préserve la vie privée des utilisateurs, en leur permettant de ne révéler aux tiers que des attributs, par exemples des données d’identité, nécessaires à un usage précis. De nombreux fournisseurs de services requièrent la mise à disposition d’attributs ou d’éléments d’identité d’un utilisateur avant de délivrer leur service. Traditionnellement, dans un monde non-numérique, ces éléments d’identité sont produits par des titres (physiques) émis par des autorités officielles (cartes d’identité, permis de conduire, etc.) ou par des justificatifs émis par des tiers certificateurs reconnus (facture d’électricité, facture télécom, certificat médical, etc.). Le développement des services accessibles via internet nécessite la mise en œuvre d’outils dédiés permettant la numérisation des éléments présents sur les supports précités, éventuellement de façon structurée et autorisant leur partage avec le fournisseur de services, après consentement de l’utilisateur. Les grands prescripteurs sur Internet ont jusqu’alors structuré le domaine de la gestion de l’identité numérique dans le sens de leur modèle d’affaires. Ils ont, par exemple, au travers du protocole OIDC (OpenID Connect), élaboré une offre qui centralise les éléments d’identité de l’utilisateur et, sous son contrôle, après identification / authentification et consentement de l’utilisateur, autorise, l’accès du service à tout ou partie des éléments d’identité de l’utilisateur. Un des principaux problèmes de ce type d’architecture, connue sous le nom « d’Identité fédérée », réside dans le fait que le fournisseur d’identité connait, à chaque fois qu’un utilisateur consomme un des services, quand l’opération se déroule et quels sont les éléments d’identité que l’utilisateur partage avec le fournisseur de services auquel il accède. La figure 1 illustre le mécanisme connu de l’identité fédérée : - Un utilisateur U envoie une requête Rq_Id à un fournisseur d’identité FI pour que celui-ci certifie, après authentification de l’utilisateur, un ou plusieurs de ses attributs - L’utilisateur U envoie une requête Rq_AS à un fournisseur de service FS pour accéder à un service
- Le fournisseur d’identité FI délivre un jeton TOK à l’utilisateur U - L’utilisateur U transmet ce jetonTOK au fournisseur de service FS pour que celui-ci lui autorise l’accès au service. L'identité auto-souveraine (SSI, Self Sovereign Identity) est une autre approche de l'identité numérique, qui donne aux utilisateurs le contrôle total de leurs éléments d’identité : ils peuvent les présenter à l’accès à un service soit pour prouver qui ils sont ou une de leurs qualités. Seuls, le fournisseur de services et l’utilisateur interagissent lors de la phase de partage d’éléments d’identité. Dans cette logique, l’utilisateur détient des éléments d’identité le concernant, qui ont été délivrés et certifiés par une ou des entités de confiance, par exemple par un fournisseur d’identité via l’utilisation de signatures numériques. Dans ce modèle d’identité numérique, une accréditation (en anglais Verifiable Credential, VC) est une attestation personnelle permettant à son titulaire de convaincre un tiers, par exemple un fournisseur de services, qu’il possède une autorisation ou une qualification particulière. Les diplômes, les cartes étudiants ou encore les permis de conduire sont autant d’exemples d’accréditations classiques utilisées dans la vie courante. De façon à générer la confiance entre l’utilisateur et le service, l’utilisateur peut présenter ses éléments d’identité certifiés par le fournisseur d’identité (en qui le fournisseur de services a confiance) en utilisant une présentation vérifiable (en anglais Verifiable Presentation VP). On rappelle qu’une présentation vérifiable est une combinaison de références vérifiables, regroupées dans un format à présenter au tiers. Les présentations vérifiables sont signées avec les clés cryptographiques du détenteur. Dans l’approche d’identité auto-souveraine, l’utilisateur maîtrise la diffusion de ses éléments d’identité auprès du fournisseur de services (après consentement) et protège sa vie privée vis-à-vis du fournisseur d’identité en l’excluant de sa relation avec le fournisseur de services, le protocole étant complètement asynchrone. Cependant, les mécanismes standards de signature numérique utilisés par le fournisseur d’identité nécessitent de révéler l’intégralité des données signées / certifiées, même pour prouver l’authenticité d’une partie seulement d’entre elles. Pour protéger sa vie privée, il est souhaitable qu’un utilisateur ne révèle à un fournisseur de services que les attributs ou données d’identité strictement nécessaires au service demandé. Cette propriété est connue sous le nom de divulgation sélective de données d’identité ou d’attributs (selective disclosure en anglais).
La divulgation sélective d’attributs est facilement réalisable dans le monde physique. Par exemple, des informations présentes sur un titre d’identité peuvent être masquées à l’aide d’un feutre noir pour ne laisser visibles que certaines données d’identité. La norme ISO/IEC 18013-5 explique comment transposer cette technique manuelle de caviardage à des titres d’identité numérique. Cette norme ISO/IEC 18013-5 est plus précisément une norme internationale relative à la conception d'un permis de conduire mobile (mDL) dématérialisé, au travers d’une application native pour téléphone mobile. Elle définit plus particulièrement un modèle de données généralisable à tout autre titre d’identité dématérialisé sur téléphone mobile, ainsi qu’un protocole permettant la divulgation sélective de données d’identité associées à ce titre. Le principe de fonctionnement de la méthode de divulgation sélective utilisée dans la norme ISO/IEC 18013-5 est maintenant décrit. Emission d’un titre d’identité conformément à la norme ISO/IEC 18013-5 Le fournisseur d’identité dispose d’une paire de clés, privée (^^^^^^) et publique (^^^^^^), d’un algorithme de signature numérique tel que ECDSA (Elliptic Curve Digital Signature Algorithm). L’utilisateur dispose également d’une paire de clés, privée (^^^^) et publique (^^^^), d’un algorithme de signature numérique, qu’il utilisera pour authentifier ses présentations vérifiables VP et qu’il devra préalablement faire certifier par le fournisseur d’identité en même temps que l’ensemble des attributs (régaliens ou non) relatifs à son permis de conduire. Nous noterons (^^1, ^^2, ^^3, … , ^^^^) ses attributs. Lors de la phase d’émission d’une accréditation (ou titre d’identité numérique) VC, après avoir authentifié l’utilisateur, le fournisseur d’identité choisit aléatoirement ^^ valeurs publiques, notées {^^^^ } ^ ^ ^= ^ 1 , puis calcule ^^ condensés (hachages cryptographiques), un par attribut. Chacun de ces ^^ condensés est étiqueté par un identifiant de condensé unique noté ^^^^^^^^. Le condensé, noté ^^^^, de chaque attribut est calculé à partir de son identifiant de condensé (^^^^^^^^), de l’identifiant de l’attribut (noté ^^^^^^^^), de la valeur de cet attribut ( ^^^^) et de la clé secrète générée et associée à cet attribut lors de la création du justificatif d’identité : ^^^^ = ℋ(^^^^^^^^ ∥ ^^^^^^^^ ∥ ^^^^ ∥ ^^^^) où ℋ désigne une fonction de hachage cryptographique (SHA- 256 par exemple) ; la notation ^^^^^^1 ∥ ^^^^^^2 étant utilisée pour désigner la concaténation des chaînes de caractères ^^^^^^1 et ^^^^^^2.
Le fournisseur d’identité calcule ensuite une signature numérique, en utilisant sa clé privée ^^^^^^, sur la structure de données comprenant la clé publique ^^^^ de l’utilisateur et les ^^ condensés ^^^^. Désignons par ^^ = ^^^^ ∥ ^^1 ∥ ^^2 ∥ … ∥ ^^^^ et ^^^^^^^^^^^^^^ = ^^^^^^^^^^^^^^(^^) la signature du fournisseur d’identité sur ^^. Le fournisseur d’identité transmet ensuite la signature ^^^^^^^^^^^^^^ et les clés ^^^^ à l’utilisateur. L’accréditation (ou titre d’identité numérique) VC de l’utilisateur (ou élément de sécurité mobile – MSO dans la terminologie de la norme ISO/IEC 18013-5) est constitué de sa clé publique ^^^^, des condensés
1 et du certificat ^^^^^^^^^^^^^^ sur ces données : ^^^^ = ( ^^^^, {^^^^} ^^ ^^=1 , ^^^^^^^^^^^^^^). Les données secrètes associées à ce titre d’identité numérique VC sont la clé privée ^^^^ de l’utilisateur et les clés secrètes choisies aléatoirement
Présentation vérifiable d’un titre d’identité numérique avec divulgation sélective conformément à la norme ISO/IEC 18013-5 : Nous désignerons dans la suite par ^^, la liste des indices des attributs réclamés par le fournisseur de service. Par exemple ^^ = {1, 5, 7} signifie que le fournisseur de service souhaite que l’utilisateur lui dévoile les attributs ^^1, ^^5, et ^^7. L’utilisateur se connecte de manière anonyme au site du fournisseur de service. Celui-ci lui envoie les conditions d’accès à son site (c.à.d. la liste ^^ des attributs requis) ainsi qu’une valeur aléatoire (nonce) spécifique à cette session pour éviter les rejeux de présentations vérifiables. L’utilisateur calcule, en utilisant sa clé privée ^^^^, une signature (^^^^^^^^^^), portant sur un ensemble de données, appelé « DeviceAuthenticationBytes » dans la norme ISO/IEC 18013- 5 et noté ^^^^^^^^ dans la suite. Le DeviceAuthenticationBytes comprend le nonce (ou tout autre élément équivalent, spécifique à la session en cours avec le fournisseur de service, et permettant d’éviter les rejeux de présentation vérifiable), éventuellement l’ensemble des données dévoilées au fournisseur de service ainsi que d’autres données contextuelles : ^^^^^^^^^^ = ^^^^^^^^^^^^(^^^^^^^^). La présentation vérifiable ^^^^ est constituée de la clé publique ^^^^^^ du fournisseur d’identité, de la clé publique ^^^^ de l’utilisateur, des condensés {^^^^ } ^ ^ ^= ^ 1 ,de l’ensemble des données dévoilées au fournisseur de service (^^^^^^^^^^^^^^^^^^^^ = {^^^^^^^^ ∥ ^^^^^^^^ ∥ ^^^^ ∥
et des signatures ^^^^ = (^^^^^^ ,
L’utilisateur transmet la présentation vérifiable ^^^^ au fournisseur de service.
Le fournisseur de service calcule dans un premier temps ^^′^^ = ℋ(^^^^^^^^ ∥ ^^^^^^^^ ∥ ^^^^ ∥ ^^^^) pour chaque ^^ ∈ ^^. Il vérifie ensuite que : 1) ^^′^^ = ^^^^ pour chaque ^^ ∈ ^^; 2) ^^^^^^^^^^^^^^ est une signature valide sur ^^
∥ ^^2 ∥ … ∥ ^^^^ en utilisant la clé publique ^^^^^^ du fournisseur d’identité; 3) ^^^^^^^^^^ est une signature valide sur ^^^^^^^^ (que le fournisseur de service peut reconstituer) en utilisant la clé publique ^^^^ certifiée par le fournisseur d’identité. Si (et seulement si) ces trois conditions sont vérifiées, le fournisseur de service donne l’accès à son service à l’utilisateur. Remarque 1: la signature ^^^^^^^^^^^^^^ permet d’authentifier toutes les données d’identité dévoilées par l’utilisateur ({ ^^^^ } ^^∈^^)) ainsi que la clé publique ^^^^. La signature ^^^^^^^^^^, quant à elle, permet de convaincre le fournisseur de service que cette présentation vérifiable émane bien du détenteur de l’accréditation ^^^^ = ( ^^^^, {^^^^} ^^ ^^=1 , ^^^^^^^^^^^^^^) et qu’il ne s’agit donc pas du rejeu d’une précédente présentation vérifiable. Remarque 2 : les clés publiques ^^^^ , incluses dans les calculs des condensés ^^^^, ont pour but d'empêcher les attaques par recherche exhaustive contre les attributs qui ne sont pas divulgués. Sans ces clés, les attaques par force brute réussiraient facilement contre les attributs ayant une faible entropie, tels que ceux relatifs à la "date de naissance" de l’utilisateur ou au « numéro de série du titre d’identité ». En effet si ^^^^ avait été calculé de la façon suivante : ^^^^ =
∥ ^^^^^^^^ ∥ ^^^^), sans la clé ^^^^, il serait très simple de retrouver l’attribut « date de naissance » (^^^^) en testant toutes les valeurs possibles (^^′^^) jusqu’à obtenir la bonne, c’est-à-dire celle qui vérifierait l’égalité ^^^^ =
∥ ^^^^^^^^ ∥ ^^′^^) (les données ^^^^^^^^ et ^^^^^^^^ étant des données publiques accessibles à tous). Inconvénients de la norme ISO/IEC 18013-5 Le schéma présenté ci-avant proposée par la norme ISO/IEC 18013-5 présente plusieurs inconvénients. En particulier : i/ du point de vue de la protection des données personnelles, car l’utilisateur est traçable par le fournisseur de service (mais aussi par le fournisseur d’identité). En effet, toutes les présentations vérifiables de cet utilisateur contiendront systématiquement la signature ^^^^^^^^^^^^^^ et la clé publique ^^^^, ce qui est une indication qu’elles ont été produites par un seul et même utilisateur. Pire certainement, si le fournisseur de service et le fournisseur
d’identité croisent leurs informations, ils pourront à coup sûr identifier l’utilisateur à l’origine d’une présentation vérifiable car le fournisseur d’identité sait à qui il a remis la signature ^^^^^^^^^^^^^^ et pourra donc en présence d’une présentation vérifiable identifier son auteur. ii/ la clé privée ^^^^ de l’utilisateur, qui lui servira à authentifier ses présentations vérifiables au travers de la signature ^^^^^^^^^^ est une clé extrêmement sensible qui doit de ce fait être convenablement protégée ; en effet la compromission de cette clé ferait courir le risque à l’utilisateur qu’on usurpe son identité. La norme ISO/IEC 18013-5 recommande à cet effet que cette clé soit stockée dans un « élément matériel sécurisé ayant les certifications appropriées ». Or de tels dispositifs (Secure Element ou SE) disposent d’une puissance de calculs limitée, et ne supportent pas toutes les opérations mathématiques mises en œuvre par certains algorithmes classiques de signature numérique (notamment ceux, comme BBS+, impliquant des couplages bilinéaires dans la génération d’une signature et/ou la vérification d’une signature). Cette contrainte limite fortement le type d’algorithmes de signature numérique pouvant être mis en œuvre pour émettre les signatures ^^^^^^^^^^ et/ou vérifier les signatures ^^^^^^^^^^^^^^ . La présentation invention vise une solution permettant une divulgation sélective d’attributs d’accréditations anonymes qui ne présente pas les inconvénients précités. Objet et résumé de l’invention Ainsi, et selon un premier aspect, la présente divulgation concerne un procédé de génération d’une accréditation ^^^^ portant sur au moins un attribut d’un utilisateur, le procédé étant mis en œuvre par un fournisseur d’identité et comportant les étapes suivantes : - authentification de l’utilisateur ; - obtention d’au moins une représentation cryptographique ^^^^ d’un attribut de l’utilisateur ; - obtention d’une signature ^^^^^^^^^^^^^^ calculée en utilisant une clé privée dudit fournisseur d’identité et portant au moins sur : (a) ladite au moins une représentation cryptographique ; et sur (b) une clé publique ^^^^ de l’utilisateur ; - calcul d’une preuve de la validité
d’une accréditation ^^^^ comportant au moins : (i) ladite signature ^^^^^^^^^^^^^^ , (ii) une clé publique ^^^^ de l’utilisateur ; (iii) ladite au moins une représentation cryptographique ^^^^ ; et - envoi audit utilisateur de ladite preuve ΠI et de ladite accréditation ^^^^.
Corrélativement, la présente divulgation concerne un dispositif de génération d’une accréditation ^^^^ portant sur au moins un attribut d’un utilisateur, le dispositif comportant: - un module d’authentification de l’utilisateur ; - un module d’obtention d’au moins une représentation cryptographique ^^^^ d’un attribut de l’utilisateur ; - un module obtention d’une signature ^^^^^^^^^^^^^^ calculée en utilisant une clé privée dudit fournisseur d’identité et portant au moins sur : (a) ladite au moins une représentation cryptographique ; et sur (b) une clé publique ^^^^ de l’utilisateur ; - un module de calcul d’une preuve ΠI de la validité d’une accréditation ^^^^ comportant au moins : (i) ladite signature ^^^^^^^^^^^^^^ , (ii) une clé publique ^^^^ de l’utilisateur ; (iii) ladite au moins une représentation cryptographique ^^^^ ; et - un module d’envoi audit utilisateur de ladite preuve et de l’accréditation ^^^^. Ainsi, et d’une façon générale, la présente divulgation concerne trois entités : 1. au moins un fournisseur d’identité qui fournit aux utilisateurs, après les avoir authentifiés, des accréditations anonymes (ci-après accréditations) portant sur un ou plusieurs de ses attributs. Comme détaillé ci-après, dans un mode de réalisation, le fournisseur d’identité utilise le protocole BBS+ pour certifier les attributs des utilisateurs. 2. au moins un fournisseur de service qui vérifie certains attributs d’un utilisateur avant de lui délivrer le service et avoir la certitude que ses attributs sont certifiés. Autrement dit, le fournisseur de service vérifie que les attributs d’un utilisateur remplissent les conditions d’accès à ses services. Par exemple, pour l’accès à un site de contenus pour adultes, le fournisseur de service a l’obligation légale de s’assurer que l’utilisateur est majeur. L’utilisateur devra donc fournir une preuve attestant de sa majorité au travers d’une présentation vérifiable générée à partir d’une accréditation, certifiant son âge, émis par un fournisseur d’identité en qui le fournisseur de service a confiance. 3. au moins un utilisateur disposant d’un ensemble d’accréditations lui permettant de prouver son identité ou au moins certains de ses attributs (majorité, séniorité, diplômes, etc.) auprès d’un fournisseur de service afin d’accéder à ses services, en ne révélant que les attributs requis pour l’accès au service.
Dans un mode de réalisation, ladite signature est conforme au protocole BBS+ décrite dans le document « The BBS Signature Scheme, published 31 January 2024 : The BBS Signature Scheme (identity.foundation) ». Dans un mode de réalisation, ladite au moins une représentation cryptographique est un condensé obtenu par une fonction de hachage. Dans un mode de réalisation, ce condensé est conforme à la norme ISO/IEC 18013-5 :2021. En effet, la présente divulgation est parfaitement compatible avec le modèle de données et de divulgation définis dans ce standard. Une accréditation VC au sens de la présente divulgation est par exemple un titre d’identité numérique ou un élément de sécurité mobile – MSO dans la terminologie de la norme ISO/IEC 18013-5. De façon très avantageuse, en mettant en œuvre la présente divulgation, l’utilisateur ne révèle au fournisseur de service que les attributs strictement nécessaires à l’accès au service concerné. Selon un deuxième aspect, la présente divulgation concerne un procédé mis en œuvre par un dispositif d’un utilisateur, pour demander l’accès à un service fourni par un fournisseur de service, ledit procédé comportant les étapes suivantes : - authentification de l’utilisateur auprès d’un fournisseur d’identité; - réception en provenance du fournisseur d’identité, d’une accréditation ^^^^ et d’une preuve ΠI de la validité de l’accréditation ^^^^, ladite accréditation ^^^^ comportant au moins : (i) une représentation cryptographique ^^^^ d’un attribut de l’utilisateur (ii) une clé publique ^^^^ de l’utilisateur ; et (iii) une signature ^^^^^^^^^^^^^^ calculée en utilisant une clé privée dudit fournisseur d’identité et portant au moins sur : (a) ladite au moins une représentation cryptographique ^^^^ et (b) ladite clé publique ^^^^ de l’utilisateur, - vérification de ladite preuve ΠI ; - réception d’une liste d’au moins un attribut à révéler audit fournisseur de service pour accéder audit service ; - calcul d’une clé publique anonymisée PKBlind de l’utilisateur à partir de ladite clé publique ^^^^et d’une signature anonymisée ^^^ ^ ^^ ^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^ ^ ^ à partir de la signature ^^^^^^^^^^^^^^et d’une preuve ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ de connaissance d’une clé privée anonymisée de l’utilisateur associée à ladite clé publique anonymisée PKBlind à partir d’une preuve de connaissance σ d’une clé privée de l’utilisateur, lesdites preuves σ, σ B Is l sin ud er et σ B Ul si en rd étant calculées conjointement par un élément sécurisé d’un terminal utilisateur et une application dudit terminal ;
- envoi au fournisseur de service, d’une présentation vérifiable à divulgation sélective comportant au moins : (aa) une clé publique du fournisseur d’identité, (bb) la clé publique anonymisée PKBlind de l’utilisateur, (cc) au moins un attribut à révéler pour accéder audit service, (dd) une représentation cryptographique ^^^^ dudit au moins un attribut à révéler, (ee) ladite signature anonymisée σ B Is l sin ud er et (ff) ladite preuve ^^^ ^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^^. Corrélativement, la présente divulgation concerne un dispositif de demande d’accès à un service fourni par un fournisseur de service, ledit dispositif comportant: - un module d’authentification d’un utilisateur dudit dispositif auprès d’un fournisseur d’identité; - un module d’obtention, en provenance dudit fournisseur d’identité, d’une accréditation ^^^^ et d’une preuve ΠI de la validité de cette accréditation ^^^^, cette accréditation ^^^^ comportant au moins : (i) une représentation cryptographique ^^^^ d’un attribut de l’utilisateur (ii) une clé publique ^^^^ de l’utilisateur; et (iii) une signature ^^^^^^^^^^^^^^ calculée en utilisant une clé privée dudit fournisseur d’identité et portant au moins sur : (a) le dit au moins une représentation cryptographique ^^^^ et (b) ladite clé publique de l’utilisateur, - un module de vérification de ladite preuve ΠI ; - un module de réception d’une liste d’au moins un attribut à révéler audit fournisseur de service pour accéder audit service - des moyens de calcul d’une clé publique anonymisée PKBlind de l’utilisateur à partir de ladite clé publique, de calcul d’une signature anonymisée ^^^ ^ ^^ ^ ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^ ^ à partir de la signature ^^^^^^^^^^^^^^ et des moyens de calcul d’une preuve ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ de connaissance d’une clé privée anonymisée de l’utilisateur associée à ladite clé publique anonymisée PKBlind à partir d’une preuve de connaissance σ d’une clé privée de l’utilisateur ; - un module d’envoi, audit fournisseur de service, d’une présentation vérifiable à divulgation sélective comportant au moins : (aa) une clé publique du fournisseur d’identité, (bb) la clé publique anonymisée PKBlind de l’utilisateur, (cc) au moins un attribut à révéler pour accéder audit service,
(dd) une représentation cryptographique ^^^^ dudit au moins un attribut à révéler, (ee) ladite signature anonymisée et (ff) ladite preuve ^^^ ^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^^. De façon très avantageuse, grâce à l’utilisation d’une clé publique anonymisée et d’une signature anonymisée, l’invention permet de garantir que ni le fournisseur de service ni le fournisseur d’identité, isolément ou conjointement, ne peuvent tracer l’utilisateur dans les usages de ses accréditations. Selon un troisième aspect, l’invention concerne un procédé de contrôle d’accès à un service par un utilisateur, ledit procédé étant mis en œuvre par un fournisseur de service et comportant les étapes suivantes : - obtention d’une présentation vérifiable à divulgation sélective comportant au moins : (aa) une clé publique d’un fournisseur d’identité, (bb) une clé publique anonymisée PKBlind de l’utilisateur obtenue à partir d’une clé publique ^^^^ de l’utilisateur, (cc) au moins un attribut de l’utilisateur à révéler pour accéder audit service, (dd) une représentation cryptographique ^^^^ dudit au moins un attribut à révéler, (ee) une signature anonymisée σ B Is l sin ud er obtenue à partir d’une signature ^^^^^^^^^^^^^^ émise par ledit fournisseur de service et portant au moins sur : (a) au moins une représentation cryptographique ^^^^ d’un attribut de l’utilisateur et (b) une clé publique anonymisée ^^^^^^^^^^^^^^ de l’utilisateur, et (ff) une preuve
la connaissance par l’utilisateur d’une clé privée anonymisée associée à ladite clé publique anonymisée PKBlind ; - calcul d’une représentation cryptographique ^^′^^ dudit attribut requis ; - vérification : (i) de la représentation cryptographique ^^′^^ de l’attribut requis ; (ii) de ladite preuve ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ de la connaissance par l’utilisateur de ladite clé privée anonymisée et (iii) de ladite signature anonymisée σ B Is l sin ud er en utilisant la clé publique dudit fournisseur d’identité (FI) ; - un résultat positif de ladite vérification étant une condition nécessaire pour autoriser l’accès de l’utilisateur audit service. Corrélativement, la présente divulgation concerne un dispositif de contrôle d’accès à un service par un utilisateur, ledit dispositif comportant : - un module d’obtention d’une présentation vérifiable à divulgation sélective comportant au
moins : (aa) une clé publique d’un fournisseur d’identité, (bb) une clé publique anonymisée PKBlind de l’utilisateur obtenue à partir d’une clé publique ^^^^ de l’utilisateur, (cc) au moins un attribut de l’utilisateur à révéler pour accéder audit service, (dd) une représentation cryptographique ^^^^ dudit au moins un attribut à révéler, (ee) une signature anonymisée σ B Is l sin ud er obtenue à partir d’une signature ^^^^^^^^^^^^^^ émise par ledit fournisseur de service et portant au moins sur : (a) au moins une représentation cryptographique
d’un attribut de l’utilisateur et (b) une clé publique anonymisée ^^^^^^^^^^^^^^de l’utilisateur, et (ff) une preuve ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ de la connaissance par l’utilisateur d’une clé privée anonymisée associée à ladite clé publique anonymisée PKBlind ; - un module de calcul d’une représentation cryptographique ^^′^^ dudit attribut requis (ai); - un module (M-CRY2) de vérification (S44, S440) : (i) de la représentation cryptographique ^^′^^ de l’attribut requis (ii) de ladite preuve
la connaissance par l’utilisateur de ladite clé privée anonymisée et (iii) de ladite signature anonymisée σ B Is l sin ud er en utilisant la clé publique dudit fournisseur d’identité ; - un module configuré pour autoriser l’accès de l’utilisateur audit service au moins si ladite vérification est positive. Dans un mode de réalisation, l’utilisateur obtient du fournisseur d’identité une preuve ^^^^^^ de la validité de ladite signature anonymisée σ B Is l sin ud er , et la présentation vérifiable à divulgation sélective envoyée au fournisseur de service par l’utilisateur comporte cette preuve de validité ^^^^^^. Dans ce mode de réalisation, et comme décrit en détails ci-après, la vérification de la signature anonymisée σ B Is l sin ud er par le fournisseur de service comporte la vérification de cette preuve de validité ^^^^^^. Ce mode de réalisation de l’invention est avantageusement compatible avec les mécanismes d’identité fédérée décrits en référence à la figure 1, et notamment celui dans mode de la norme ISO/IEC 18013-5, dans lequel l’utilisateur, après s’être authentifié auprès du fournisseur de service, reçoit de ce dernier un jeton attestant qu’il vérifie bien les conditions d’accès aux services de ce fournisseur.
Dans un mode de réalisation, le procédé de demande d’accès comporte: - le calcul, par un élément sécurisé du terminal utilisateur, d’une preuve ^^ de la connaissance d’une clé privée de l’utilisateur ; - lesdites preuves σ B Is l sin ud er et σ B Ul si en rd étant calculées conjointement par cet élément sécurisé (et une application dudit terminal. Ce mode de réalisation décrit dans le détail ci-après est très avantageux lorsque les éléments sécurisés utilisés dans les terminaux sont limités à des tâches très prédéterminées qui empêchent certains calculs cryptographiques, par exemple des tâches d’anonymisation, ou certains calculs de signatures. Dans cette solution, l’élément sécurisé n’a aucun couplage bilinéaire à effectuer et seulement une multiplication scalaire sur courbe elliptique à effectuer pour générer la signature σUser (contre un nombre linéaire en n avec la version originelle de BBS+ standardisée à l’ETF sous la référence « The BBS Signature Scheme, published 31 January 2024 : The BBS Signature Scheme (identity.foundation) »). Pour certaines versions de BBS+ (Jan Camenisch, Manu Drijvers, Anja Lehmann: Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited. IACR Cryptol. ePrint Arch. 2016: 663 (2016)), le dispositif sécurisé de l’utilisateur n’a qu’un nombre constant de multiplications scalaires sur courbe elliptique à effectuer pour générer la signature σUser mais doit en revanche interagir plusieurs fois avec l’application mobile pour calculer cette signature. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de génération d’au moins une accréditation lorsque ledit programme est exécuté par un ordinateur. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de demande d’accès à un service lorsque ledit programme est exécuté par un ordinateur. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé de contrôle d’accès à un service lorsque ledit programme est exécuté par un ordinateur. Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support
d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, une mémoire non volatile de type flash ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins : D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : [Fig. 1] La figure 1 déjà décrite représente le mécanisme connu de l’identité fédérée [Fig. 2] La figure 2 représente un système comportant un dispositif de génération d’accréditation, un dispositif utilisé par un utilisateur pour demander d’accès à un service et un dispositif de contrôle d’accès à un service conformes à des modes de réalisation particuliers de la présente divulgation ; [Fig. 3] La figure 3 représente sous forme d’ordinogramme des étapes d’un procédé de génération d’une accréditation conformément à un mode de réalisation particulier de la présente divulgation ; [Fig. 4] La figure 4 représente sous forme d’ordinogramme des étapes d’un procédé de demande d’accès à un service et d’un procédé de contrôle d’accès à un service conformes à un mode de réalisation particulier de la présente divulgation ; [Fig. 5] La figure 5 représente sous forme d’ordinogramme des étapes d’un procédé de demande d’accès à un service et d’un procédé de contrôle d’accès à un service conforme à un autre mode de réalisation particulier de la présente divulgation ; [Fig. 6] La figure 6 représente sous forme d’ordinogramme une étape du procédé de la figure 5 dans un mode particulier de la présente divulgation ; [Fig. 7] La figure 7 représente l’architecture matérielle des dispositifs de la figure 1 dans un mode de réalisation particulier de la présente divulgation.
De façon préliminaire, nous rappelons des outils cryptographiques utilisés dans la présente divulgation. Les schémas de mise en gage La mise en gage d’une valeur est un procédé cryptographique permettant à un émetteur de s’engager sur une valeur (un secret par exemple) auprès d’un destinataire sans la dévoiler de prime abord et de telle sorte que cet engagement ne soit plus modifiable a posteriori. Cette valeur peut être, si nécessaire, dévoilée par la suite par l'émetteur. Ainsi, le destinataire a l’assurance qu’une fois l’engagement publié, l'émetteur ne peut plus changer d’avis sur la valeur contenue dans cet engagement. De manière imagée, une mise en gage consiste à remettre au destinataire un coffre fermé renfermant le secret, et à lui fournir ultérieurement la combinaison permettant de l’ouvrir. Dans un mode particulier de réalisation, la présente divulgation peut utiliser le schéma de mise en gage proposé par Pedersen en 1992 (Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO’91, volume 576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992), qui a la particularité de produire des engagements parfaitement non distinguables (perfectly hiding en anglais). Preuves à divulgation nulle de connaissance On rappelle qu’une preuve de connaissance dite à divulgation nulle de connaissance (Zero- Knowledge Proof ou ZKP en anglais), est un protocole interactif qui permet à un vérifieur de se convaincre qu’un certain prouveur connaît bien un secret ^^ satisfaisant un prédicat ^^ donné, la preuve ne révélant au vérifieur aucune information sur le secret S en question hormis le fait que celui-ci vérifie bien le prédicat ^^ donné. Par la suite, pour représenter les preuves à divulgation nulle de connaissance, nous utiliserons parfois la notation usuelle PoK{α, β, … : prédicat sur α, β, … } introduite par Camenisch et Stadler (Jan Camenisch, Markus Stadler: Efficient Group Signature Schemes for Large Groups (Extended Abstract). CRYPTO 1997: 410-424) où les lettres grecques correspondent aux secrets connus par le prouveur. Par exemple, PoK{^^ : ^^ = ^^^^} désignera une preuve de connaissance du logarithme discret de (la valeur publique) ^^ dans la base (publique) ^^. Dans un mode particulier de réalisation, on utilise des versions non-interactives des preuves de connaissance dite à divulgation nulle de connaissance (aussi appelées « signatures de connaissance »), obtenues par des transformations heuristiques telles que celle due à Fiat- Shamir (Amos Fiat, Adi Shamir: How to Prove Yourself: Practical Solutions to Identification
and Signature Problems. CRYPTO 1986: 186-194). Plus précisément, on appelle « signature de connaissance » un protocole non-interactif permettant à un prouveur d’une part de convaincre un tiers qu’il connait un secret ^^ suivant un prédicat ^^ et d’autre part de garantir qu’il est l’auteur d’un message m en assurant l’intégrité de ce dernier. Nous notons une telle signature de connaissance de valeurs secrètes (^^, ^^, ^^, …) vérifiant un prédicat donné et authentifiant un message ^^ comme suit : SoK{ ^^, ^^, ^^, …: prédicat sur ^^, ^^, ^^, … }(^^) où les lettres grecques correspondent aux secrets connus par le prouveur et ^^ au message authentifié. Par exemple, SoK{^^: ^^ = ^^^^}(^^) désignera une signature de connaissance du logarithme discret de (la valeur publique) ^^ dans la base (publique) ^^ authentifiant le message ^^. Une signature de connaissance sur un message ^^ a les mêmes caractéristiques qu’une signature numérique : elle en garantit à la fois l’authenticité et l’intégrité. Description de modes de réalisation Nous utiliserons dans la suite la notation suivante PoΚ(^^1, ^^2,…, ^^^^ ∶ ^^(^^1, ^^2,…, ^^^^)) pour désigner une preuve de connaissance à divulgation nulle de connaissance (ZKPK)
^^2,…, ^^^^ satisfaisant la relation R. Ainsi une preuve de connaissance des deux facteurs premiers d’un module RSA (algorithm Rivest-Shamir-Adleman) public ^^ serait notée :
. De manière analogue, nous utiliserons dans la suite la notation suivante SoΚ(^^1, ^^2,…, ^^^^ ∶ ^^(^^1, ^^2,…, ^^^^))(^^) pour désigner une signature de connaissance (ZKPK) d’éléments ^^1, ^^2,…, ^^^^ satisfaisant la relation R et authentifiant le message ^^. ^^^^ désignera l’ensemble {0, 1, 2,…, ^^-1}, où ^^ est un entier premier et ^^^ ∗ ^ l’ensemble {1, 2,…, ^^-1}. La mise en œuvre de mécanismes cryptographiques de la présente divulgation utilise des couplages bilinéaires. On rappelle qu’un couplage bilinéaire, noté e, est une application définie sur un ensemble ^^1 × ^^2 vers un ensemble ^^^^ où ^^1, ^^2 et ^^^^ désignent des groupes cycliques d’ordre ^^, ^^ étant un nombre premier. Cette application ^^ vérifie les propriétés suivantes : 1. (Bilinéarité)
2. (Non dégénérée) Pour ^^1 ≠ 1^^1 et ^^2 ≠ 1^^2, ^^(^^1, ^^2) ≠ 1^^^^ 3. (Calculable) ∀ ^^1 ∈ ^^1, ∀ ^^2 ∈ ^^2, il existe un algorithme efficace pour calculer ^^(^^1, ^^2).
En pratique, les groupes ^^1, ^^2 et ^^^^ seront choisis de telle sorte qu’il n’existe pas d’isomorphisme calculable efficacement entre ^^1 et ^^2. De tels couplages sont connus de l’homme du métier sous le nom de couplages de Type 3. La sécurité de certains mécanismes cryptographiques utilisés dans cette divulgation repose en partie sur l’hypothèse que les problèmes ci-dessous est difficile. En d’autres termes, si un attaquant est en mesure de mettre en défaut la sécurité de ces mécanismes, c’est qu’il est également à même de résoudre ces problèmes pourtant réputés « difficiles ». Problème q-SDH : Soit ^^ un groupe cyclique d’ordre premier ^^ et un élément ^^ ∈ ^^^^. Etant donné (^^, ^^^^ , ^^^^2 , ^^^^3 , … , ^^^^ ^^ ), le problème q-strong Diffie-Hellman (q-SDH) consiste à 1 calculer une paire de la forme (^^ ⁄ ^^+^^ , ^^) ∈ ^^ × ^^^^. Dans un mode particulier de réalisation de l’invention, on utilise le schéma de mise en gage de Pedersen (Torben P. Pedersen: Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991: 129-140). Dans ce schéma, on considère ^^ un groupe cyclique d’ordre premier ^^ et ^^ et ℎ deux générateurs quelconques de ^^. Il est supposé le logarithme discret de ℎ en base ^^ est inconnu. Pour s’engager sur le message ^^ ∈ ^^^^ de son choix, un émetteur choisit une valeur aléatoire ∈ ^^^^, calcule ^^ = ^^ ^^ℎ^^ et l’envoie au destinataire. Au besoin (phase d’ouverture, l’émetteur peut révéler au destinataire les valeurs ^^ et ^^ afin que ce dernier vérifie l’égalité : ^^ = ^^^^ℎ^^. La figure 2 représente un système SYS comportant un dispositif D-FI de génération d’accréditation anonyme mis en œuvre par un fournisseur d’identité FI, un dispositif D-FS de contrôle d’accès à un service mis en œuvre par un fournisseur de service FS et un dispositif D-USR mis en œuvre par un utilisateur U pour demander l’accès audit service. Pour simplifier la description, le dispositif D-FI de gestion d’accréditation anonyme sera parfois appelé « dispositif D-FI du fournisseur d’identité FI ». De même, le dispositif D-FS de contrôle d’accès à un service sera parfois appelé « dispositif D-FS de fourniture de service ». De même, le dispositif D-USR de demande d’accès à un service sera parfois appelé « dispositif utilisateur D-USR ». De même, au lieu de dire « dispositif D-X » on pourra dire simplement « X ». Autrement dit, le fournisseur de service FS peut désigner le dispositif de D-FS, le fournisseur d’identité FI
peut désigner le dispositif D-FI de gestion d’accréditation anonyme et l’utilisateur U peut désigner le dispositif D-USR de demande d’accès à un service. Le dispositif D-FI de gestion d’accréditation anonyme possède une paire de clés publiques (^^^^^^ , ^^^^′^^) et une clé privée associée (^^^^^^). Le dispositif de l’utilisateur D-USR possède une paire de clés publique et privée (^^^^, ^^^^) pour permettre son authentification auprès du fournisseur d’identité FI. Dans le mode de réalisation décrit ici, ces clés sont stockées dans un élément sécurisé SE. Le dispositif D-FI de génération d’une d’accréditation est configuré pour, après avoir authentifié un utilisateur U, obtenir d’au moins une représentation cryptographique ^^^^ d’un attribut ^^^^ de l’utilisateur et obtenir d’une signature ^^^^^^^^^^^^^^ calculée en utilisant la clé privée ^^^^^^ dudit fournisseur d’identité et portant au moins sur (a) le dit au moins une représentation cryptographique ^^^^ ; et sur (b) une clé publique ^^^^ de l’utilisateur (^^). Le dispositif D-FI envoie ensuite à l’utilisateur U une accréditation ^^^^ comportant au moins (i) ladite signature ^^^^^^^^^^^^^^ , (ii) une clé publique ^^^^ de l’utilisateur (^^); et (iii) ledit au moins une représentation cryptographique
Dans le mode de réalisation décrit ici, le dispositif D-USR de l’utilisateur comporte un module M-AUTH d’authentification de l’utilisateur auprès du dispositif D-FI de génération d’une accréditation. Dans le mode de réalisation décrit, le dispositif D-USR de l’utilisateur U comporte un élément sécurisé pour stocker des données cryptographiques, par exemple une clé privée secrète, un module cryptographique WAL, par exemple un portefeuille d’identité électronique configuré pour stocker au moins une accréditation vérifiable anonyme ^^^^ délivrée par un fournisseur d’identité FI, pour générer une signature anonymisée par exemple la signature σ B Is l sin ud er et pour générer une présentation vérifiable à présenter au fournisseur de service FS pour accéder à un service tout en protégeant la confidentialité de ses attributs. Dans un mode de réalisation, l’élément sécurisé SE est configuré pour calculer une preuve ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ de la connaissance d’une clé privée de l’utilisateur. Dans le mode de réalisation décrit ici, le dispositif D-FI de génération d’une accréditation vérifiable anonyme comporte un module de communication COM1. Ce module peut notamment être utilisé par le dispositif D-FI pour communiquer avec l’utilisateur D-USR en vue de son authentification et pour lui envoyer une accréditation ^^^^. Dans le mode de réalisation décrit ici, le dispositif D-FI comporte un module cryptographique M-CRY1. Ce module peut notamment être utilisé pour authentifier un utilisateur, calculer des condensés, des signatures et des preuves.
Dans le mode de réalisation décrit ici, le dispositif D-FS de contrôle d’accès à un service par un utilisateur comporte un module M-LS pour déterminer quels attributs d’un utilisateur doivent être vérifiés avant de l’autoriser à accéder à un service, vérifier si des attributs obtenus satisfont effectivement la logique du service et le cas échéant pour autoriser l’accès au service après avoir vérifié au moins une preuve de la validité d’une accréditation de la certification de ces attributs. Dans le mode de réalisation décrit ici, le dispositif D-FS comporte un module de communication COM2. Ce module peut notamment être utilisé par le dispositif pour demander des attributs à l’utilisateur, obtenir ces attributs ou des informations lui permettant d’obtenir ces attributs, et obtenir une présentation vérifiable comportant une accréditation sur des attributs d’un utilisateur, envoyer un message à l’utilisateur pour lui faire part d’une autorisation d’accès ou du refus d’accès à un service. Dans le mode de réalisation décrit ici, le dispositif D-FS comporte un module cryptographique M-CRY2 configuré notamment pour calculer des condensés, vérifier des preuves et des signatures. La figure 3 représente sous forme d’ordinogramme les principales étapes d’un procédé d’émission d’une accréditation vérifiable mis en œuvre par le fournisseur d’identité FI. Au cours d’une étape I2, le fournisseur d’identité FI définit les paramètres publics du système de signature: ^^^^ = (^^1,^^2, ^^^^ , ^^, ^^, ^^, ^^, ^^0, ^^1, ^^2, … , ^^^^, ^̃^, ^^) où : - où ^^1,^^2, ^^^^ sont trois groupes cycliques d’ordre p et ^^ un couplage bilinéaire de ^^1^^^^2 dans ^^^^, pour lesquels nous ferons l’hypothèse que le problème q-SDH est difficile. - ^^ est un entier premier qui désigne l’ordre du groupe ^^ - ^^ le nombre d’attributs à certifier - ^^, ^^0, ^^1, ^^2, .. , ^^^^, ^̃^ désignent ^^+3 générateurs du groupe ^^ choisis aléatoirement (de telle sorte que personne ne connaisse le logarithme discret d’un de ces générateurs par rapport à un autre de ces générateurs). Chaque {^^^^ } ^ ^ ^= ^ 1 est associé à un type d’attribut spécifique (par exemple ^^1 sera associé à l’attribut « nom », ^^2 à l’attribut « prénom », ^^3 à l’attribut « âge », ^^4 à l’attribut « genre », etc.). Cela nous permettra de différencier les attributs et d’éviter toute ambiguïté. - ^^ désigne un générateur de ^^2. Les ^^+3 générateurs du groupe ^^ sont choisis aléatoirement de telle sorte que personne ne connaisse le logarithme discret d’un de ces générateurs par rapport à un autre de ces générateurs.
Dans le mode de réalisation décrit ici, chaque {^^^^ } ^ ^ ^= ^ 1 est associé à un type d’attribut spécifique (par exemple ^^1 sera associé à l’attribut « nom », ^^2 à l’attribut « prénom », ^^3 à l’attribut « âge », ^^ 4 à l’attribut « genre », etc.). Dans la suite, tous les calculs portant sur les exposants seront effectués modulo p (mod p). Au cours d’une étape I4, le fournisseur d’identité FI définit les données publiques propres au type d’accréditation (par exemple du titre d’identité numérique). Dans le mode de réalisation décrit ici, ces données publiques comportent : - une clé publique ^^^^ pour chacun des ^^ types d’attributs, soit
^ ^= ^ 1 , ces clés publiques étant destinées à être utilisées pour toutes les accréditations VC émises par le fournisseur d’identité FI ; - un entier ^^^^ tiré aléatoirement dans ^^^^, - un identifiant de condensé ^^^^^^^^ pour chacun des ^^ types d’attributs, soit {^^^^^^^^}^ ^ ^= ^ 1 , et - un identifiant ^^^^^^^^ pour chacun des types attributs, soit
Au cours d’une étape I6, le fournisseur d’identité FI génère une clé privée ^^^^^^ et une clé publique associée. Dans le mode de réalisation décrit ici, la clé privée ^^^^^^ appartient à {1, 2, … ,
et la clé publique associée est la paire (^^^^^^ , ^^^^′^^) avec ^^^^^^ = ^̃^ ^^^^^^ et ^^^^′^^ = ^^ ^^^^^^. Dans le mode de réalisation décrit ici, le fournisseur d’identité FI génère également une preuve Π = PoK {^^: ^^^^^^ = ^̃^ ^^ ∧ ^^^^′^^ = ^^ ^^} à divulgation nulle de connaissance que sa paire de clés (^^^^^^ , ^^^^′^^) a bien été générée. On suppose maintenant que le fournisseur d’identité FI souhaite générer une accréditation ^^^^ pour les attributs (^^1, ^^2, ^^3, … , ^^^^) d’un utilisateur ^^. On note (^^^^, ^^^^ = ^^^^^^) une paire de clés privée/publique de cet utilisateur. Dans le mode de réalisation décrit ici, la clé privée ^^^^ est stockée dans l’élément sécurisé SE. Au cours d’une étape I8, le fournisseur d’identité FI envoie un défi (message) ^^ℎ à l’utilisateur ^^. L’utilisateur ^^ génère une preuve ^^^^ =SoK{^^: ^^^^ = ^^ ^^}(^^ℎ) de connaissance de sa clé privée authentifiant le défi ^^ℎ. Dans le mode de réalisation décrit ici, la preuve πU est calculée en utilisant l’algorithme appelé ECSchnorr (Claus-Peter Schnorr: Efficient Identification and Signatures for Smart Cards (Abstract). EUROCRYPT 1989: 688-689). D’autres algorithmes peuvent être utilisés
par exemple l’algorithme ECDSA (ANSI X9.62-1998, Public Key Cryptography For The Financial Services Industry : The Elliptic Curve Digital Signature Algorithm (ECDSA)). L’utilisateur ^^ envoie au fournisseur d’identité FI sa clé publique PK et la preuve ^^^^. Dans le mode de réalisation décrit ici, si le fournisseur d’identité FI n’authentifie pas l’utilisateur U sur la base de ces informations, le résultat d’un test I9 est négatif et le procédé s’arrête. Si l’authentification réussit, au cours d’une étape I10, le fournisseur d’identité FI calcule, en utilisant une fonction
de hachage cryptographique, une représentation cryptographique ^^^^ dans ^^^^ pour chacun des attributs ^^^^. Dans le mode décrit ici, cette représentation cryptographique est un haché calculé par une fonction est par exemple conforme au protocole SHA-256. Dans le mode de réalisation décrit ici, la représentation cryptographique ^^^^ d’un attribut ^^^^ est plus précisément calculé à partir de l’identifiant de condensé ^^^^^^^^, de l’identifiant de l’attribut ^^^^^^^^, de la valeur de cet attribut ^^^^ et de la clé publique ^^^^ associée au type de cet attribut lors de la création du justificatif d’identité :
Cette représentation est conforme à la norme ISO/IEC 18013-5. D’autres représentations peuvent être utilisées dans d’autres modes de réalisation de cette divulgation. Au cours d’une étape I12, le fournisseur d’identité FI calcule une signature numérique ^^^^^^^^^^^^^^ en utilisant sa clé privée ^^^^^^, sur une structure de données ^^ comprenant la clé publique ^^^^ de l’utilisateur et les ^^ condensés ^^^^. Il sauvegarde cette signature ^^^^^^^^^^^^^^. ^^ = ^^^^ ∥ ^^1 ∥ ^^2 ∥ … ∥ ^^^^ Dans le mode de réalisation décrit ici, le schéma de signature utilisé est conforme au protocole BBS+.
^^ est une valeur choisit aléatoirement dans
En posant ^^^^
donc ^^ ^^ = ^^^^−^^. On désigne C = AskI = BA−e. Pour plus de renseignements sur ce le protocole BBS+, l’homme du métier peut se reporter au standard lui-même (https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs- signatures.html) ou au document « Barki, A., Brunet, S., Desmoulins, N., and J. Traore, "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials", In International Conference on Selected Areas in Cryptography, 1016, <https://link.springer.com/chapter/10.1007/978-3-319-69453-5_20>.
Au cours d’une étape I14, le fournisseur d’identité FI génère une preuve Π^^ à divulgation nulle de connaissance pour prouver qu’il connait ^^ tel que ^^ = ^^^^ ∧ ^^^^^^ = ^̃^ ^^. Π^^ = PoK {^^: ^^ = ^^ ^^ ∧ ^^^^^^ = ^̃^ ^^} Dans le mode de réalisation décrit ici, l’accréditation VC est constituée (étape I16) par la clé publique ^^^^ de l’utilisateur, les condensés {^^^^}^ ^ ^= ^ 1 et la signature ^^^^^^^^^^^^^^ sur ces données : ^^^^ = ( ^^^^, {^^^^} ^^ ^^=1 , ^^^^^^^^^^^^^^ = (^^, ^^)). La donnée secrète associée à cette accréditation VC est la clé privée ^^^^ de l’utilisateur ^^. Au cours d’une étape I18, le fournisseur d’identité FI envoie l’accréditation ^^^^ et la preuve Π^^ à l’utilisateur ^^. Au cours d’une étape U20, l’utilisateur ^^ calcule =
, ^^ = ^^^^ −^^ et vérifie la validité de la preuve Π^^. Si la preuve est validée, l’utilisateur ^^ stocke dans son portefeuille d’identité numérique WAL, l’accréditation VC portant notamment sur ses attributs {^^^^}^ ^ ^= ^ 1 et sur sa clé publique ^^^^. Dans un mode de réalisation, l’utilisateur connaît ses attributs et il n’est pas nécessaire que le fournisseur d’identité les lui renvoie. En variante, le fournisseur d’identité les renvoie à l’utilisateur pour permettre à ce dernier de vérifier que le fournisseur d’identité et lui partagent bien les mêmes informations (i.e. vérifier par exemple que le fournisseur d’identité n'a pas mal orthographié son nom de famille. La figure 4 représente sous forme d’ordinogramme les principales étapes d’un procédé de demande d’accès à un service mis en œuvre par l’utilisateur U et les principales étapes d’un procédé de contrôle d’accès mis en œuvre par le fournisseur de service FS. Conformément à la présente divulgation, l’utilisateur U utilise à cet effet une présentation vérifiable VP générée à partir d’une ou plusieurs accréditations VC par au moins un fournisseur d’identité FI. Par souci de simplicité, on suppose que la présentation vérifiable VP ne comporte qu’une accréditation VC. Nous désignerons par ^^, la liste des indices des attributs {^^^^ } ^^∈^^ réclamés par le fournisseur de service FS. Nous supposerons dans cet exemple que la vérification des conditions d’accès au service porte sur trois attributs ^^1, ^^5, ^^7 et donc que ^^ = {1, 5, 7}. Dans le mode de réalisation décrit ici, pour chaque attribut n’appartenant pas à ^^, l’utilisateur ^^ enverra au fournisseur de service FS la valeur ^^^^. Au cours d’une étape U20, l’utilisateur U se connecte de façon anonyme auprès du fournisseur de service FS.
Au cours d’une étape S22, le fournisseur de service envoie à l’utilisateur U la liste ^^ des attributs qu’il doit vérifier pour donner accès à son service et une valeur aléatoire (nonce) spécifique à la session pour éviter les rejeux de présentations vérifiables. Dans un mode préféré de réalisation, cette demande est authentifiée, autrement dit signée par le fournisseur de service FS. Au cours d’une étape U24, l’utilisateur calcule une clé publique anonymisée PKBlind à partir de sa clé publique ^^^^ = ^^^^^^ pour que ni le fournisseur de service FS ni le fournisseur d’identité FI ne puisse le tracer à partir de sa clé publique. A cet effet, l’utilisateur ^^ choisit aléatoirement un entier r dans Zp et calcule une mise en gage à la Pedersen de sa clé privée sk : PKBlind = g sk+r. Au cours d’une étape U26, l’utilisateur ^^ calcule une signature anonymisée ^^^ ^ ^^ ^ ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ à partir de la signature ^^^^^^^^^^^^^^ de son accréditation VC, pour éviter également que le fournisseur de service FS ou le fournisseur d’identité FI puisse le tracer à partir de cette signature élément, et « l’adapter » pour qu’elle porte sur la clé publique anonymisée PKBlind et les {Hi } n i=1 (et non sur PK et les condensés
A cet effet, dans le mode de réalisation décrit ici, l’utilisateur ^^ choisit des entiers r1, r2 ∈ Zp ∗ puis calcule : ^̂^ = ^^^^1×^^2 ^^ = ^^^^2 ^̅^ = ^̂^−^^^^^^1=^̂^^^^^^^
Cette preuve Π^^^^^^^^^^^^^^^^ est connue de l’homme de l’art (voir par exemple Stefan Brands: Rapid Demonstration of Linear Relations Connected by Boolean Operators. EUROCRYPT 1997: 318-333) ne sera pas détaillée dans ce document. Elle découle des deux égalités suivantes : ^̅^ = ^̂^−^^^^^^1 et
Alternativement, la preuve Π^^^^^^^^^^^^^^^^ peut correspondre à : Π^^^^^^^^^^^^^^^^=
Au cours d’une étape U38, l’utilisateur ^^ calcule en utilisant un aléa r et sa clé privée sk, une signature de connaissance σUser portant sur un ensemble de données, appelé « DeviceAuthenticationBytes » dans la norme ISO/IEC 18013-5 et notée mDAB dans la suite :
Dans la norme ISO/IEC 18013, le DeviceAuthenticationBytes comprend le nonce (ou tout autre élément équivalent, spécifique à la session en cours avec le fournisseur de service FS et permettant d’éviter les rejeux de la présentation vérifiable VP, éventuellement l’ensemble des données dévoilées au fournisseur de service ainsi que d’autres données contextuelles). La signature σUser est une signature de connaissance du logarithme discret de PKBlind dans la base g. Dans un mode particulier de réalisation, on utilise l’algorithme ECSchnorr pour cette signature. Tout autre algorithme permettant de prouver la connaissance de la clé privée ^^^^ peut être également mis en œuvre, notamment l’algorithme ECDSA dans le contexte des mécanismes d’identité auto-souveraine SSI. Dans un mode de réalisation de la présente divulgation, il se peut que l’élément sécurisé SE ne soit pas en mesure: - d’anonymiser lui-même (étape U24) sa clé publique (par exemple calculer PKBlind = g sk+r) et/ou ; - d’anonymiser lui-même (étape U26) sa clé privée (par exemple calculer ^^^^^^^^^^^^^^ = ^^^^ + ^^ (^^^^^^ ^^)) ; et/ou - de calculer lui-même (étape U38) la preuve de connaissance de la clé privée anonymisée ^^^^ + ^^ (^^^^^^ ^^), c’est-à-dire une signature ^^^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^^de connaissance du logarithme discret de ^^^^^^^^^^^^^^ dans la base ^^. Nous expliquons ci-dessous comment l’élément sécurisé SE et l’application mobile WAL associée à ce SE, peuvent conjointement anonymiser la clé publique PKBlind et calculer la signature σUser. On rappelle que dans le mode de réalisation décrit ici, seul l’élément sécurisé SE connaît la clé privée sk associée à la clé publique PK de l’utilisateur. Dans un premier mode de réalisation, nous supposerons que l’élément sécurisé SE supporte l’algorithme classique de signature numérique ECSchnorr, également appelé ECSDSA dans la norme ISO/IEC 14888-3. Le calcul de la signature
= SoK{α: PKBlind = g α}(mDAB) pourrait s’effectuer de la manière suivante :
a/ l’élément sécurisé SE calcule une signature de connaissance (notée σ ) du logarithme discret de PK dans la base g (i.e. de la clé privée sk) : σUser = SoK{α: PK = g α}(mDAB). Dans un mode de réalisation, l’algorithme ECSDSA peut être mis en œuvre de la façon suivante pour le calcul de cette signature : l’élément sécurisé SE : i/ génère un aléa ω ii/ calcule T = gω, c = ℋ(T ∥ mDAB) et iii/ calcule ρ = ω + c sk (mod p) désigne une fonction de hachage cryptographique (SHA-256 par exemple). La signature σ est constituée de la paire (c, ρ) : σUser = (c, ρ). Elle est valide si c′ = ℋ(gρ x ^^^^−^^ , mDAB) = c et invalide dans le cas contraire. b/ l’application WAL : i/ choisit un aléa r ii/ calcule PK r sk+r Blind = g × PK = g ,et iii/ calcule ρBlind = ρ + c × r = ω + c × sk + c × r = ω + c × (sk + r) (mod p). La signature ^^ ^^^^^^^^^^ ^^^^^^^^ = (c, ρBlind) est une signature ECSDSA valide sur mDAB relativement à la clé publique PKBlind. Dans ce mode de réalisation, l’élément sécurisé SE calcule la preuve σUser de la connaissance de la clé privée de l’utilisateur, les preuves σ B Is l sin ud er et σ B Ul si en rd étant calculées conjointement par ledit élément sécurisé SE par l’application WAL dudit terminal. Ainsi, l’élément sécurisé SE effectue des opérations simples (pas de couplage bilinéaire à effectuer et seulement une multiplication scalaire sur courbe elliptique à effectuer) tandis que la signature ^^^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^^ ^ ^ est calculée par l’application mobile WAL dédiée de son téléphone mobile. Dans un second mode de réalisation, nous supposerons que l’élément sécurisé SE supporte l’algorithme classique de signature numérique ECDSA. Le calcul de la signature ^^ ^^^^^^^^^^ ^^^^^^^^ = SoK{α: PKBlind = g α}(mDAB) peut s’effectuer de la manière suivante et l’algorithme ECDSA peut être mis en œuvre pour le calcul de cette signature : a/ l’application WAL : i/ calcule une donnée
mod p et ii/ transmet la donnée M au SE b/ l’élément sécurisé SE : i/ choisit un aléa ^^ ∈ ^^^ ∗ ^ ii/ calcule ^^^^ = (^^, ^^) et ^^ = ^^ (mod ^^). A noter que nous utilisons ici de manière abusive la multiplication (au lieu de l’addition) pour désigner l’opération de groupe dans ^^. L’élément
^^^^ est donc bien un point sur la courbe elliptique sous-jacente. A noter également que si ^^ = 0 alors le SE choisit un nouvel aléa ^^ ∈ ^^^∗ ^ puis recalcule ^^^^ = (^^, ^^) et ^^ = ^^ (mod ^^) jusqu’à ce que ^^ ≠ 0. iii/ calcule ^^0 = ^^−1(^^ + ^^^^ × ^^) mod ^^. A noter que si ^^0 = 0 alors le SE choisit un nouvel aléa ^^ ∈ ^^^∗ ^ puis recalcule ^^^^ = (^^, ^^) , ^^ = ^^ (mod ^^)
= ^^−1(^^ + ^^^^ × ^^) jusqu’à ce que ^^ ≠ 0 et ^^0 ≠ 0. iiii/ transmet ^^0 à l’application WAL. Une fois ^^ reçu, l’application WAL c −1 0 alcule ^^ = ^^ × ^^0 = ^^ (ℋ(^^^^^^^^) + ^^^^^^^^^^^^^^ × ^^) mod ^^. La signature = (^^, ^^) est une signature ECDSA valide sur ^^^^^^^^ relativement à la clé publique ^^^^^^^^^^^^^^. Dans ce mode de réalisation, la preuve ^^ de la connaissance de la clé privée de l’utilisateur ainsi que les preuves σ B Is l sin ud er et σ B Ul si en rd sont calculées conjointement par ledit élément sécurisé SE et par l’application WAL dudit terminal. Ainsi, l’élément sécurisé SE effectue des opérations simples (pas de couplage bilinéaire à effectuer et seulement une multiplication scalaire sur courbe elliptique à effectuer) tandis que la signature ^^^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^^ ^ ^ est calculée par l’application mobile WAL dédiée de son téléphone mobile. La présentation vérifiable ^^^^^^^^ à divulgation sélective est constituée (étape U40) de la clé publique du fournisseur d’identité FI, de la clé publique anonymisée PKBlind de l’utilisateur, des {^^^^} ^ i∉^^ , de l’ensemble des données dévoilées au fournisseur de service FS (^^disclosed = {HIDi ∥ IDai ∥ ai ∥ Ki}i∈^^), des représentations cryptographiques ^^^^^^∈^^, et des signatures σ B Is l sin ud er et ^^^ ^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^^ .
L’utilisateur transmet la présentation vérifiable ^^^^^^^^ au fournisseur de service FS au cours d’une étape U42. Au cours d’une étape S44, le fournisseur de service FS calcule H′i = ℋ(HIDi ∥ IDai ∥ ai ∥ Ki) pour chaque i ∈ ^^. Il vérifie ensuite que : i/ H′i = Hi pour chaque i ∈ ^^ ; ii/ ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ est une signature valide sur mDAB, autrement dit que le fournisseur de service FS peut la reconstituer en utilisant la clé publique PKBlind certifiée par le fournisseur d’identité FI. L’algorithme ECSchnorr ou ECDSA de vérification de cette SoK (SoK{α: PKBlind =
gα}(mDAB)) étant connu de l’homme du métier, nous ne le détaillerons pas dans ce document. iii/ σ Blind Issuer est une signature valide sur PKBlind, {Hi}i∈^^ et {H′i = ^^^^}i∉^^, en utilisant la clé publique du FI. Pour cela, il doit dans un premier temps s’assurer que l’égalité suivante est satisfaite e(Â, PK′ I) = e(B,̅ f) (Si le FI a mis en œuvre la version de BBS+ utilisant des couplages bilinéaires) et d’autre part que Πvalidity est valide. L’algorithme de vérification de cette preuve Πvalidity est connu de l’homme du métier. Alternativement, il peut s’assurer que l’égalité suivante ^̅^ = ^̂^^^^^^^ est satisfaite et d’autre part que Π^^^^^^^^^^^^^^^^ est valide. Si toutes ces conditions sont vérifiées, on démontre que les attributs demandés {ai}i∈^^ ont bien été certifiés par le fournisseur d’identité FI et que la présentation vérifiable VP émane bien de l’utilisateur ^^ dont les attributs sont les attributs demandés {ai}i∈^^. Le fournisseur de service FS permet à l’utilisateur ^^ d’accéder à son service (étape S46). Si l’une au moins des conditions n’est pas vérifiée, le fournisseur FS refuse l’accès à son service (étape S48). Le mécanisme présenté ci-dessus est très avantageux car ni le fournisseur de service FS ni le fournisseur d’identité FI ne peut tracer l’utilisateur ^^. Par ailleurs, la méthode de divulgation sélective est conforme à celle décrite dans la norme ISO/IEC 18013-5 mais cette dernière présente l’inconvénient, en cas de collusion entre le fournisseur de service FS et le fournisseur d’identité FI de tracer les usages de leurs clients communs. Dans le mode de réalisation décrit précédemment, l’utilisateur ^^ n’a pas besoin d’être connecté pour pouvoir générer une présentation vérifiable VP. De même, le fournisseur de service FS n’a pas besoin d’être connecté pour respectivement pouvoir et vérifier une présentation vérifiable VP. Ce mode qui peut en ce sens être qualifié d’hors-ligne (HL) correspond à un mode de vérification de VP proposé notamment par la norme ISO/IEC 18013-5. La norme ISO/IEC 18013-5 prévoit un second mode, qui peut être qualifié de « mode semi- hors-ligne » ou de mode « synchrone ». Ce mode qui nécessite qu’au moins un des deux acteurs soit connecté s’apparente au modèle de l’identité fédérée décrit en référence à la figure 1. Dans le mode SHL de la norme ISO/IEC 18013-5, et comme dans le mode synchrone de l’identité fédérée décrit en référence à la figure 1, l’utilisateur ^^ reçoit un jeton (en anglais Token) du fournisseur d’identité attestant bien qu’il vérifie les conditions d’accès au fournisseur de service FS.
Comme indiqué précédemment le problème de l’identité fédérée pose un inconvénient majeur en ce que le fournisseur d’identité sait auprès de quels fournisseurs de services U utilise ses jetons et peut ainsi tracer ses usages. Nous allons maintenant décrire un mode particulier de réalisation de la présente divulgation compatible avec le mode SHL de la norme ISO/IEC 18013-5 mais dans lequel le fournisseur d’identité FI n’est pas en mesure d’identifier auprès de quel fournisseur de service FS un utilisateur ^^ utilise ses jetons. On se place dans la situation dans laquelle l’utilisateur ^^ a reçu une accréditation ^^^^ = (^^, ^^) du fournisseur de service comme décrit en référence à la figure 3. En référence à la figure 5, l’utilisateur ^^ calcule une clé anonymisée PKBlind à partir de sa clé publique ^^^^ = ^^^^^^ et une valeur anonymisée
de la signature ^^^^^^^^^^^^^^ de son accréditation VC. Ces étapes sont similaires aux étapes U24 et U26 décrites en référence à la figure 4. Au cours d’une étape U28, l’utilisateur ^^ essaie d’obtenir du fournisseur d’identité FI, en le contactant directement, une preuve (SoK) ^^ sk r × ^^^^ que B̅ = ÂI où Â = A 1 r2. Dans un mode particulier de réalisation cette preuve est obtenue en aveugle, ce qui signifie que le fournisseur d’identité FI, bien qu’ayant contribué à générer cette preuve (lui seul connaît skI), sera dans l’incapacité en présence d’une telle preuve πEQ de déterminer à quel utilisateur elle était destinée. Dans un mode de réalisation, et comme décrit ci-après en référence à la figure 6, cette preuve ^^^^^^ peut être obtenue en utilisant le protocole de signature aveugle de Chaum- Pedersen (David Chaum, Torben P. Pedersen: Wallet Databases with Observers. CRYPTO 1992: 89-105). Au cours d’une étape U38 similaire à l’étape U38 déjà décrite en référence à la figure 4, l’utilisateur ^^ calcule en utilisant un aléa r et sa clé privée sk, une signature de connaissance
portant sur un ensemble de données m ^^ ^^^^^^^^^^ ^^^^^^^^ = SoK{α: PKBlind = g α}(mDAB) La présentation vérifiable ^^^^^^^^^^ est constituée (étape U400) de la clé publique du fournisseur d’identité FI, de la clé publique anonymisée PK de l’utilisateur, des
de l’ensemble des données dévoilées au fournisseur de service FS (^^disclosed = {HIDi ∥ IDai ∥ ai ∥ Ki}i∈^^), des représentations cryptographiques ^^^^^^∈^^, des signatures σ B Is l sin ud er et ^^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^^ et de la preuve ^^^^^^.
σ Blind Issuer , ^^ ^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^, ^^^^^^).
L’utilisateur transmet la présentation vérifiable VP au fournisseur de service FS au cours d’une étape U420. Au cours d’une étape S440, le fournisseur de service FS calcule H′i = ℋ(HIDi ∥ IDai ∥ ai ∥ Ki) pour chaque i ∈ ^^. Il vérifie ensuite que : i/ H′i = Hi pour chaque i ∈ ^^ ; ii/ σUser est une signature valide sur mDAB
est une signature valide sur PKBlind, {Hi}i∈^^ et {H′i = ^^^^}i∉^^, en utilisant la clé publique du FI. Pour cela, il doit d’abord s’assurer que la preuve ΠEQ est valide et que la preuve Πvalidity est valide. Si toutes ces conditions sont vérifiées, le fournisseur de service FS permet à l’utilisateur ^^ d’accéder à son service (étape S46). Si l’une au moins des conditions n’est pas vérifiée, le fournisseur FS refuse l’accès à son service (étape S48). Cette solution présente l’avantage de ne pas nécessiter de couplages bilinéaires, ce qui la rend beaucoup plus efficace que celles mettant en œuvre ces outils cryptographiques. Sa sécurité repose par ailleurs sur des problèmes mathématiques communément réputés plus difficiles par la communauté scientifique. La figure 6 représente, sous forme d’ordinogramme un protocole mis en œuvre entre l’utilisateur ^^ et le fournisseur d’identité FI par lequel le fournisseur d’identité FI peut apporter la preuve à l’utilisateur ^^ une preuve (SoK) ^^^^^^ que B̅ = ÂskI où Â = Ar1×r2. Autrement dit, cette figure détaille l’étape U28 de la figure 5 dans un mode particulier de réalisation de la présente divulgation. On rappelle que le fournisseur d’identité FI connait la signature ^^^^^^^^^^^^^^ = (^^, ^^) calculée à l’étape I12 sur la clé publique ^^^^ et les attributs ^^^^ de l’utilisateur ^^. Au cours d’une étape I50 similaire à l’étape I8, le fournisseur d’identité FI envoie un défi (message) ^^ℎ à l’utilisateur ^^. L’utilisateur ^^ génère une preuve ^^^^ =SoK{^^: ^^^^ = ^^ ^^}(^^ℎ) de connaissance de sa clé privée authentifiant le défi ^^ℎ, par exemple en utilisant l’algorithme appelé ECSchnorr ou ECDSA L’utilisateur ^^ envoie au fournisseur d’identité FI sa clé publique PK et la preuve ^^^^. Dans le mode de réalisation décrit ici, si le fournisseur d’identité FI n’authentifie pas l’utilisateur U sur la base de ces informations, le résultat d’un test I51 est négatif et le procédé s’arrête.
Si l’authentification réussit, au cours d’une étape I52, le fournisseur d’identité FI calcule une représentation cryptographique ^^^^ dans ^^^^ pour chacun des attributs ^^^^ de l’utilisateur ^^. Cette étape est similaire à l’étape I10.
Au cours d’une étape I54, le fournisseur d’identité FI choisit une valeur ^^ aléatoirement dans ^^∗ ^^ ^^ et calcule ^^0 = ^̃^ et calcule ^^0 = ^^ ^^ Le fournisseur d’identité FI envoie les valeurs ^^0 et ^^0 à l’utilisateur ^^ (étape I56). Au cours d’une étape U58, l’utilisateur ^^ choisit deux valeurs ^^, ^^ aléatoirement dans ^^^ ∗ ^ et calcule :
^^0 = ^^/^^ (mod ^^) L’utilisateur envoie la valeur ^^0 au fournisseur d’identité FI au cours d’une étape U60. Au cours d’une étape I62, le fournisseur d’identité FI calcule ^^0 = ^^ + ^^0 × ^^^^^^ (^^^^^^ ^^) et envoie la valeur ^^0 = ^^ + ^^0 × ^^^^^^ (^^^^^^ ^^) à l’utilisateur ^^. Au cours d’une étape U64, l’utilisateur ^^ calcule : ^^ = ( ^^0 + ^^)^^ (mod ^^) La preuve πEQ est égale à : πEQ = (Â, B,̅ c, r). C’est une preuve (SoK) valide sur le message mDAB si :
Chacun des dispositifs D-USR, D-FI et D-FS décrits précédemment peut être mis en œuvre par un ordinateur ORD dont l’architecture matérielle est représentée à la figure 7. Cet ordinateur ORD comporte notamment un processeur 10, une mémoire vive 11, une mémoire morte 12 et des moyens de communication 13. La mémoire morte 12 constitue un support d’enregistrement au sens de l’invention. Elle comporte un programme d’ordinateur PG-X conforme à l’invention. Pour le dispositif D-USR, ce programme d’ordinateur PG-X est un programme PG-USR comportant des instructions pour exécuter les étapes d’un procédé de demande d’accès à un service tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-USR définit notamment les modules M-AUTH d’authentification, d’obtention WAL d’une
accréditation, de calcul WAL de clés et de signatures, et de communication COM-3 du dispositif D-USR. Pour le dispositif D-FI, ce programme d’ordinateur PG-X est un programme PG-FI comportant des instructions pour exécuter les étapes d’un procédé de génération d’accréditation tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-FI définit notamment le module M-CRY1 d’authentification, de calcul de condensés, de signatures, et d’obtention d’accréditations, et le module COM1 du dispositif D-FI. Pour le dispositif D-FS, ce programme d’ordinateur PG-X est un programme PG-FS comportant des instructions pour exécuter les étapes d’un procédé de contrôle d’accès à un service tel que décrit précédemment en référence aux figures 2 et 3. Le programme PG-FS définit notamment le module M-CRY2 de calcul de condensés, de preuves et de signatures, et le module COM2 de communication du dispositif D-FS.