EP4751411A1

EP4751411A1 - Procédés et dispositifs pour authentifier des données

Info

Publication number: EP4751411A1
Application number: EP24739213.7A
Authority: EP
Inventors: Olivier Sanders; Jacques Traore
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2023-07-24
Filing date: 2024-07-09
Publication date: 2026-06-03
Also published as: WO2025021489A1; FR3151678A1

Abstract

Procédés et dispositifs pour authentifier des données La présente invention concerne des procédés et des dispositifs (MST, ISR, USR, VRF) pour authentifier des données. En particulier, il est proposé un procédé mis en œuvre par un dispositif utilisateur (USR) pour authentifier un sous-ensemble (MSG) d'un ensemble de données auprès d'un dispositif vérificateur (VRF), dans lequel : - le dispositif utilisateur (USR) dispose d'une clé secrète permettant d'authentifier tout ou partie de l'ensemble de données, la clé secrète comprenant au moins un certificat (CERT) fourni par un dispositif émetteur (ISR) et certifiant l'authenticité de l'ensemble de données; et - le procédé comprend une génération d'un jeton d'authentification (TOKo) du sous-ensemble de données (MSG), ce jeton d'authentification (TOKo) étant obtenu à partir de paramètres publics définis par un dispositif maître (MST) et de la clé secrète du dispositif utilisateur (USR).

Description

Procédés et dispositifs pour authentifier des données

La présente invention se rapporte au domaine général de l’authentification. Plus particulièrement, la présente invention concerne des procédés et des dispositifs pour authentifier des données. La présente invention trouve une application particulièrement avantageuse, bien que nullement limitative, pour la mise en œuvre de systèmes d’authentification dans le domaine de l’identité numérique.

D'une manière générale, il est connu d'utiliser des mécanismes de signature électronique pour authentifier les données échangées entre des dispositifs de communication. Les signatures électroniques utilisent des schémas cryptographiques pour prouver et vérifier l'authenticité des données. Pour ce faire, un émetteur (e.g. une autorité de confiance) fournit à un utilisateur un certificat lui permettant de prouver la validité de ses données auprès d'un vérificateur.

Cependant, les mécanismes standards de signature électronique nécessitent de révéler l'intégralité des données certifiées, même pour prouver l'authenticité d'une partie seulement d'entre elles, et permettent de tracer les utilisateurs. Prenons l'exemple d'une carte de transport : pour prouver la validité de la carte auprès d'un vérificateur (e.g. un portillon d'accès), l'utilisateur doit fournir toutes les informations certifiées, y compris son nom et son prénom, ce qui permet notamment de tracer ses déplacements.

Pour remédier à ces inconvénients, des mécanismes de signature électronique dits anonymes ont été développés. Ces mécanismes sont dits anonymes en ce qu'ils permettent à l'utilisateur de contrôler les informations révélées lors de l'authentification. Ils font aujourd'hui l'objet de plusieurs normes (e.g. ISO 18370 et ISO 20008) et sont déployés à grande échelle, notamment dans des puces électroniques, telles que les puces de type TPM (pour « Trusted Platform Modules » en anglais), ou certains processeurs.

Il est toutefois important de noter que les mécanismes de signature anonymes se concentrent sur l'anonymat des utilisateurs, et non sur celui des émetteurs. Or, l'identité de l'émetteur peut révéler de nombreuses informations sur l'utilisateur. Par exemple, un certificat délivré par une commune révélera que l'utilisateur réside dans cette commune. Plus précisément, un certificat indique la clé publique de l'émetteur. Pour réduire les problèmes de sécurité en cas d’attaque malveillante, un émetteur utilise typiquement plusieurs clés publiques. L'utilisateur n'est donc pas anonyme parmi l'ensemble des utilisateurs associés à cet émetteur, mais uniquement parmi un ensemble restreint d'utilisateurs associés à une même clé publique.

Au vu de ces problèmes, plusieurs mécanismes de signature électronique ont récemment été proposés pour permettre aux utilisateurs d’authentifier des données sans avoir à révéler l'identité de l'émetteur. Nous pouvons notamment mentionner la solution proposée dans le document : Bobolz et al., « Issuer-Hiding Attribute-Based Credentials », Cryptology and Network Security, 2021. Les avantages de cette solution sont néanmoins contrebalancés par un certain nombre d'inconvénients. En effet, cette solution est complexe à mettre en œuvre. Elle nécessite un grand nombre de calculs pour générer un jeton d'authentification, et la taille des jetons est particulièrement importante. En outre, cette solution ne dispose d'aucun mécanisme de supervision du système. L'anonymat d'un émetteur ne peut pas être levé, même si cela est nécessaire pour des raisons de sécurité.

En définitive, les solutions existantes permettant à un utilisateur d'authentifier des données auprès d'un vérificateur ne sont pas pleinement satisfaisantes. Il existe un besoin pour une solution d'authentification permettant de préserver à la fois l'anonymat des utilisateurs et celui des émetteurs, et qui ne présente pas les inconvénients des solutions existantes.

La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés précédemment.

À cet effet, et selon un aspect de l’invention, il est proposé un procédé mis en œuvre par un dispositif utilisateur pour authentifier un sous-ensemble d’un ensemble de données auprès d’un dispositif vérificateur, le dispositif utilisateur disposant de :

une clé secrète permettant d’authentifier tout ou partie de l’ensemble de données, cette clé comprenant au moins :
- un élément H calculé à partir d’éléments appartenant à des paramètres publics définis par un dispositif maître, et de l’ensemble de données ; et
- un certificat fourni par un dispositif émetteur et certifiant l’authenticité de l’ensemble de données, le certificat comprenant au moins : un aléa y ; et un élément A calculé à partir de l’élément H, de l’aléa y, et d’un scalaire x appartenant à une clé privée du dispositif émetteur ; et

le procédé comprenant :

une fourniture d’un jeton d’authentification du sous-ensemble de données, ce jeton comprenant au moins :
- un ensemble d’éléments d’authentification calculé à partir des paramètres publics, de la clé secrète du dispositif utilisateur, et d’aléas r et k ;
- une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie d’une clé publique du dispositif maître pour un label t propre au dispositif émetteur, la signature S* appartenant à une clé publique du dispositif émetteur ; et
- une preuve de connaissance π associée aux éléments d’authentification, à la signature Z, et à un élément H’ calculé à partir des éléments appartenant aux paramètres publics et du sous-ensemble de données.

Il est proposé ici d’utiliser un système d’authentification comprenant quatre types de dispositifs. Le dispositif maître définit les paramètres publics, et autorise les dispositifs émetteurs à certifier des données. Une fois autorisé par le dispositif maître, un dispositif émetteur peut certifier un ensemble de données d'un dispositif utilisateur. Le dispositif utilisateur peut alors fournir un jeton d'authentification pour prouver l'authenticité (i.e. la validité) de tout ou partie de l’ensemble des données. Ce jeton d'authentification est vérifié par un dispositif vérificateur.

La solution proposée permet à l'utilisateur de prouver la validité de tout ou partie de ses données auprès d'un vérificateur. Elle ne nécessite pas que l'utilisateur fournisse au vérificateur l’intégralité des données certifiées pour prouver la validité d'une partie seulement de celles-ci. En ce sens, la solution proposée permet de préserver l'anonymat de l'utilisateur.

En outre, la solution proposée permet de préserver l'anonymat de l'émetteur qui certifie les données de l'utilisateur. L'utilisateur peut authentifier ses données auprès du vérificateur sans avoir à révéler l'identité de l'émetteur. Le vérificateur est en mesure de vérifier la validité des données sans utiliser la clé publique de l'émetteur. Il utilise pour ce faire les paramètres publics définis par le dispositif maître, les données, et les éléments inclus dans le jeton d'authentification.

En comparaison avec la solution précitée de Boboz et al., la solution proposée présente les avantages suivants. Premièrement, elle nécessite significativement moins de calculs. La solution proposée permet également d'obtenir des jetons d'authentification plus courts, et donc de réduire la quantité de données échangées entre l'utilisateur et le vérificateur. Elle permet ainsi de réduire le temps nécessaire pour réaliser une authentification, ce qui est primordial pour les usagers.

Deuxièmement, la solution proposée permet de lever l'anonymat de l'émetteur si nécessaire. Pour des raisons de sécurité, par exemple sur demande des autorités, il est possible pour le dispositif maître d'identifier l'émetteur associé à un jeton d'authentification.

Ainsi, la solution d'authentification proposée permet de préserver à la fois l'anonymat des utilisateurs et celui des émetteurs. Elle présente en outre une complexité de mise en œuvre minime et permet de lever l'anonymat d'un émetteur si nécessaire.

Selon un mode de réalisation, l’ensemble d’éléments d’authentification du jeton comprend les éléments : C₁=g₁ ^k ; C₂ = g₁ ^r ⋅ pk_e ^k ; P’₁ = (g₁ ^x)^r ; P’₂ = (g₂ ^x)^r ; D₁=A^v ; et D₂= H^r ^⋅ ^v⋅ D₁ ^-r ^⋅ ^y, où g₁ et g₂ appartiennent aux paramètres publics, g₁ ^x et g₂ ^x appartiennent à la clé publique du dispositif émetteur, v est un aléa, et pk_e appartient à la clé publique du dispositif maître.

En outre, selon ce mode de réalisation, la signature S_u est une signature sur {g₁, g₁ ^x} et la signature S* est une signature sur {pk_e, 1} pour le label t, ces signatures appartenant à la clé publique du dispositif émetteur.

Selon un mode de réalisation, l’ensemble d’éléments d’authentification du jeton comprend les éléments : C₁=g₁ ^k ; C₂= A^r⋅ pk_e ^k ; et P’₁=(A^x)^r, où g₁ appartient aux paramètres publics, A^x est comprise dans le certificat fourni par le dispositif émetteur, et pk_e appartient à la clé publique du dispositif maître.

De plus, selon ce mode de réalisation, la signature S_u est une signature sur {A, A^x} pour le label t et est comprise dans le certificat fourni par le dispositif émetteur, et la signature S* est une signature sur {pk_e, 1} pour le label t.

Nous présentons ici les avantages des deux modes de réalisation décrits ci-dessus, l'un par rapport à l'autre. D’une part, le premier mode de réalisation est avantageux en ce qu'il permet au dispositif utilisateur d'obtenir un certificat auprès d'un dispositif émetteur en mettant en œuvre un procédé de faible complexité. D’autre part, le deuxième mode de réalisation permet d'obtenir des jetons d'authentification de taille réduite, et contribue à réduire la quantité de données échangées entre un utilisateur et un vérificateur.

Selon un aspect de l’invention, il est proposé un procédé mis en œuvre par un dispositif vérificateur pour vérifier l’authenticité d’un sous-ensemble d’un ensemble de données d’un dispositif utilisateur, le procédé comprenant :

une vérification d’un jeton d’authentification du sous-ensemble de données, ce jeton comprenant au moins :
- un ensemble d’éléments d’authentification calculé à partir de paramètres publics définis par un dispositif maître, d’une clé secrète du dispositif utilisateur, et d’aléas r et k ;
- une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie d’une clé publique du dispositif maître pour un label t propre au dispositif émetteur, la signature S* appartenant à une clé publique du dispositif émetteur ; et
- une preuve de connaissance π associée aux éléments d’authentification, à la signature Z, et à un élément H’ calculé à partir d’éléments appartenant aux paramètres publics, et du sous-ensemble de données ; et

dans lequel :

la vérification du jeton comprend au moins : une vérification de la validité de la preuve de connaissance π en utilisant l’ensemble d’éléments d’authentification, la signature Z, et l’élément H’.

Selon un aspect de l’invention, il est proposé un procédé mis en œuvre par un dispositif émetteur pour certifier un ensemble de données d’un dispositif utilisateur, le dispositif émetteur disposant de :

une paire de clés publique-privée comprenant au moins :
- pour la clé privée : un scalaire x ; et
- pour la clé publique : un label t propre au dispositif émetteur ; et une signature S* fournie par un dispositif maître, S* étant une signature sur une partie d’une clé publique du dispositif maître pour le label t ; et

le procédé comprenant :

une fourniture au dispositif utilisateur d’un certificat certifiant l’authenticité de l’ensemble de données, ce certificat comprenant au moins :
- un aléa y ; et
- un élément A calculé à partir d’un élément H, du scalaire x, et de l’aléa y, l’élément H étant calculé à partir d’éléments appartenant à des paramètres publics définis par le dispositif maître et de l’ensemble de données.

Selon un aspect de l’invention, il est proposé un procédé mis en œuvre par un dispositif maître pour autoriser un dispositif émetteur à certifier un ensemble de données d’au moins un dispositif utilisateur, le dispositif maître définissant des paramètres publics, et le procédé comprenant :

une fourniture au dispositif émetteur d’éléments d’une clé publique du dispositif émetteur, ces éléments comprenant au moins :
- un label t propre au dispositif émetteur ; et
- une signature S* sur une partie d’une clé publique du dispositif maître pour le label t et obtenue en utilisant une clé privée du dispositif maître.

Selon un mode de réalisation, le procédé comprend une identification d’un dispositif émetteur associé à un jeton d’authentification d’un dispositif utilisateur, l’identification comprenant :

un déchiffrement d’éléments d’authentification chiffrés compris dans le jeton pour obtenir un élément B^r, où r est un aléa utilisé pour générer le jeton, ce déchiffrement étant réalisé en utilisant une partie de la clé privée du dispositif maître ; et
une vérification permettant de déterminer si le dispositif émetteur est associé au jeton d’authentification en utilisant : l’élément B^r obtenu ; un élément g₂ ^x compris dans la clé publique du dispositif émetteur, x un scalaire appartenant à une clé privée du dispositif émetteur ; un élément P’₁ compris dans le jeton d’authentification ; et un élément g₂appartenant aux paramètres publics.

Ce mode de réalisation permet de lever l'anonymat de l'émetteur. Plus précisément, ce mode de réalisation permet au dispositif maître d'identifier le dispositif émetteur impliqué dans un jeton d'authentification fourni par un dispositif utilisateur.

Selon un mode de réalisation, un environnement bilinéaire est utilisé, ledit environnement désignant un groupe G1, un groupe G2 et un groupe GT d’ordre p, et un couplage bilinéaire, et une dite signature σ sur un ensemble d’éléments {u₀, …, u_n} de G1 pour un label τ est obtenue en utilisant l’expression : σ = (u₀ ^b ⁰ ⋅ … ⋅ u_n ^bn)^1/( ^a+τ ⁾, où les scalaires {a, b₀, …, b_n} appartiennent à une clé privée.

Ce mode de réalisation propose d’utiliser un mécanisme de signature linéairement homomorphe. Plus particulièrement, le mécanisme de signature proposé ici permet avantageusement d’obtenir des jetons d’authentification de taille réduite, en comparaison aux mécanismes de signature existants. Ce mode de réalisation contribue ainsi à réduire la quantité de données échangées entre l'utilisateur et le vérificateur, ainsi que le temps nécessaire pour réaliser une authentification.

Selon un aspect de l’invention, il est proposé un dispositif, dit utilisateur, configuré pour authentifier un sous-ensemble d’un ensemble de données auprès d’un dispositif vérificateur, le dispositif utilisateur comprenant :

une clé secrète permettant d’authentifier tout ou partie de l’ensemble de données, cette clé comprenant au moins :
- un élément H calculé à partir d’éléments appartenant à des paramètres publics définis par un dispositif maître, et de l’ensemble de données ; et
- un certificat fourni par un dispositif émetteur et certifiant l’authenticité de l’ensemble de données, le certificat comprenant au moins : un aléa y ; et un élément A calculé à partir de l’élément H, de l’aléa y, et d’un scalaire x appartenant à une clé privée du dispositif émetteur ; et
un module de fourniture d’un jeton d’authentification du sous-ensemble de données, ce jeton comprenant au moins :
- un ensemble d’éléments d’authentification calculé à partir des paramètres publics, de la clé secrète du dispositif utilisateur, et d’aléas r et k ;
- une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie d’une clé publique du dispositif maître pour un label t propre au dispositif émetteur, la signature S* appartenant à une clé publique du dispositif émetteur ; et
- une preuve de connaissance π associée aux éléments d’authentification, à la signature Z, et à un élément H’ calculé à partir des éléments appartenant aux paramètres publics et du sous-ensemble de données.

Selon un aspect de l’invention, il est proposé un dispositif, dit vérificateur, configuré pour vérifier l’authenticité d’un sous-ensemble d’un ensemble de données d’un dispositif utilisateur, le dispositif vérificateur comprenant :

un module de vérification d’un jeton d’authentification du sous-ensemble de données, ce jeton comprenant au moins :
- un ensemble d’éléments d’authentification calculé à partir de paramètres publics définis par un dispositif maître, d’une clé secrète du dispositif utilisateur, et d’aléas r et k ;
- une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie d’une clé publique du dispositif maître pour un label t propre au dispositif émetteur, la signature S* appartenant à une clé publique du dispositif émetteur ; et
- une preuve de connaissance π associée aux éléments d’authentification, à la signature Z, et à un élément H’ calculé à partir d’éléments appartenant aux paramètres publics, et du sous-ensemble de données ;

et dans lequel :

le module de vérification est configuré au moins pour : vérifier la validité de la preuve de connaissance π en utilisant l’ensemble d’éléments d’authentification, la signature Z, et l’élément H’.

Selon un aspect de l’invention, il est proposé un dispositif, dit émetteur, configuré pour certifier un ensemble de données d’un dispositif utilisateur, le dispositif émetteur comprenant :

une paire de clés publique-privée comprenant au moins :
- pour la clé privée : un scalaire x ; et
- pour la clé publique : un label t propre au dispositif émetteur ; et une signature S* fournie par un dispositif maître, S* étant une signature sur une partie d’une clé publique du dispositif maître pour le label t ; et
un module de fourniture au dispositif utilisateur d’un certificat certifiant l’authenticité de l’ensemble de données, ce certificat comprenant au moins :
- un aléa y ; et
- un élément A calculé à partir d’un élément H, du scalaire x, et de l’aléa y, l’élément H étant calculé à partir d’éléments appartenant à des paramètres publics définis par le dispositif maître et de l’ensemble de données.

Selon un aspect de l’invention, il est proposé un dispositif, dit maître, configuré pour autoriser un dispositif émetteur à certifier un ensemble de données d’au moins un dispositif utilisateur, le dispositif maître étant configuré pour définir des paramètres publics et comprenant :

un module de fourniture au dispositif émetteur d’éléments d’une clé publique du dispositif émetteur, ces éléments comprenant au moins :
- un label t propre au dispositif émetteur ; et
- une signature S* sur une partie d’une clé publique du dispositif maître pour le label t et obtenue en utilisant une clé privée du dispositif maître.

Selon un aspect de l’invention, il est proposé un système comprenant plusieurs dispositifs parmi :

un dispositif utilisateur conforme à l’invention ;
un dispositif vérificateur conforme à l’invention ;
un dispositif émetteur conforme à l’invention ; et
un dispositif maître conforme à l’invention.

Le système proposé peut également comprendre une pluralité de dispositifs émetteurs, de dispositifs utilisateurs, et/ou de dispositifs vérificateurs.

Selon un aspect de l’invention, il est proposé un programme d’ordinateur (ou un ensemble de programmes d’ordinateur) comprenant des instructions pour mettre en œuvre les étapes d’un procédé conforme à l’invention, lorsque le programme d’ordinateur est exécuté par au moins un processeur ou un ordinateur.

Le programme d’ordinateur peut être formé d’une ou plusieurs sous-parties stockées dans une même mémoire ou dans des mémoires distinctes. Le programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, de 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.

Selon un aspect de l’invention, il est proposé un support d’informations lisible par ordinateur comprenant un programme d’ordinateur conforme à l’invention.

Le support d’informations peut être n'importe quel dispositif capable de stocker un programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire non-volatile ou ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support de stockage 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 un réseau de télécommunication ou par un réseau informatique ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau informatique. 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.

Les procédés, les dispositifs, le système, le programme d’ordinateur et le support d’informations proposés disposent des avantages décrits ci-dessus en lien avec le procédé mis en œuvre par un dispositif utilisateur pour authentifier un sous-ensemble d’un ensemble de données.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description fournie ci-après, illustrant des modes de réalisation de l’invention donnés à titre d’exemple, en référence aux dessins ci-joints :

La et la représentent respectivement un système et un procédé d’authentification selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif maître pour définir des paramètres publics selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif maître et un dispositif émetteur pour autoriser le dispositif émetteur à certifier des données d’un dispositif utilisateur selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif émetteur et un dispositif utilisateur pour certifier des données du dispositif utilisateur selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif utilisateur pour authentifier des données auprès d’un dispositif vérificateur selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif vérificateur pour vérifier l’authenticité de données d’un dispositif utilisateur selon un mode de réalisation de l’invention ;

La représente un procédé mis en œuvre par un dispositif maître pour identifier un dispositif émetteur associé à un jeton d’authentification selon un mode de réalisation de l’invention ; et

La représente un exemple d’architecture matérielle d’un dispositif selon un mode de réalisation de l’invention.

La et la représentent respectivement un système et un procédé d’authentification selon un mode de réalisation de l’invention.

La solution proposée a pour objectif de permettre à un utilisateur d'authentifier des données auprès d'un vérificateur, tout en préservant l'anonymat de l’utilisateur et celui de l’émetteur certifiant l'authenticité (i.e. la validité) de ces données.

À cet effet, il est proposé ici un système SYS comprenant des dispositifs de quatre types. L'architecture de ce système est illustrée par la , et son fonctionnement par la .

Parmi ces quatre types de dispositifs, il convient tout d'abord de mentionner le dispositif maître MST. Ce dispositif définit les paramètres publics du système SYS (étape M100), obtient une paire de clés publique-privée (étape M200), et autorise les dispositifs émetteurs ISR à certifier des données (étapes M300 et I300).

Une fois autorisé par le dispositif maître MST, un dispositif émetteur ISR peut certifier des données MSG d'un dispositif utilisateur USR, en lui fournissant un certificat CERT (étapes I400 et U400). Le dispositif utilisateur USR peut alors utiliser ce certificat CERT pour générer un jeton d'authentification TOK_U permettant de prouver l'authenticité des données MSG (étape U500).

Le jeton d'authentification TOK_U est ensuite vérifié par un dispositif vérificateur VRF en utilisant les paramètres publics (étape V600). Il convient de souligner que le dispositif utilisateur USR prouve l’authenticité des données MSG au dispositif vérificateur VRF sans révéler l'identité du dispositif émetteur ISR.

Si nécessaire, par exemple pour des raisons de sécurité, le dispositif maître MST peut identifier le dispositif émetteur ISR associé à un jeton d'authentification TOK_U (étape M700). Notons que seul le dispositif maître MST est capable de lever l'anonymat du dispositif émetteur ISR.

Bien évidemment, les fonctions décrites ci-dessus des différents dispositifs MST, ISR, USR et VRF ne sont pas exclusives. Par exemple, un dispositif émetteur ISR peut également assurer la fonction d'un dispositif vérificateur VRF. De même, seuls quatre dispositifs sont représentés sur la , mais le système SYS peut comprendre une pluralité de dispositifs émetteurs ISR, de dispositifs utilisateurs USR, et de dispositifs vérificateurs VRF.

Nous utilisons : des signes de référence commençant par M pour désigner les étapes réalisées par le dispositif maître MST ; des signes de référence commençant par I pour le dispositif émetteur ISR ; des signes de référence commençant par U pour le dispositif utilisateur USR ; et des signes de référence commençant par V pour le dispositif vérificateur VRF.

Ci-après, nous décrivons en particulier deux modes de réalisation de la solution proposée. Nous nous référons à ceux-ci en tant que premier mode de réalisation et deuxième mode de réalisation. Ces deux modes de réalisation présentent de nombreuses étapes en commun. C'est pourquoi nous mentionnons explicitement lorsqu'une étape est exécutée uniquement dans un seul mode de réalisation. Une telle étape est représentée en pointillés sur les figures, avec un indice précisant le mode de réalisation correspondant.

Cependant, avant de décrire plus en détail les différentes étapes du procédé d'authentification, nous présentons le mécanisme de signature utilisé par le système SYS.

Le mécanisme de signature linéairement homomorphe, utilisé par le système d’authentification SYS, est défini par les quatre algorithmes décrits ci-dessous.

Le mécanisme de signature proposé ici permet de minimiser la taille des jetons d'authentification, et donc la quantité de données échangées entre un utilisateur et un vérificateur. Cependant, la solution proposée n'est pas limitée au mécanisme présenté ci-dessous, d'autres mécanismes de signature pouvant être utilisés.

En particulier, le mécanisme de signature proposé utilise un environnement bilinéaire. Cet environnement bilinéaire désigne un ensemble de trois groupes G1, G2 et GT d’ordre p, et un couplage bilinéaire e : G1 x G2 → GT. Les rôles de G1 et G2 sont interchangeables.

Nous décrivons ci-après la solution proposée en utilisant des notations qui correspondent au standard dit BBS+ : Looker et al., « The BBS Signature Scheme », Internet Engineering Task Force, March 2023. Ces notations sont utilisées car la solution proposée est notamment compatible avec ce standard.

L’algorithme Keygen retourne une clé publique pk et une clé privée sk. Plus précisément, un élément g₁de G1 et un élément g₂ de G2 sont sélectionnés. Sont également sélectionnés les entiers {a, b₀, …, b_n} dont les valeurs sont comprises entre 0 et p-1. La clé publique pk est définie par les éléments {g₁, g₂} et {g₂ ^a, g₂ ^b ⁰, …, g₂ ^b ⁿ}, tandis que la clé privée sk est définie par les entiers {a, b₀, …, b_n}.

L’algorithme Sign permet d’obtenir une signature σ sur un ensemble de données M pour un label t. Cet algorithme prend en entrée : la clé privée sk ; l’ensemble de données M={m₀,…,m_n} (i.e. un vecteur de n+1 éléments de G1) ; et le label t. Selon l’implémentation proposée ici, la signature σ est obtenue en utilisant l’expression : σ = (m₀ ^b ⁰ ⋅ … ⋅ m_n ^b ⁿ)^1/( ^a+t ⁾.

L’algorithme Eval est utilisé pour générer une signature pour toutes les combinaisons linéaires de plusieurs ensembles de données. Il prend en entrée des signatures {σ₀, …, σ_k} portant respectivement sur les ensembles de données {M₀, …, M_k} pour un même label t, ainsi que des coefficients {w₀, …, w_k}. Il fournit en sortie une signature S sur M₀ ^W ⁰⋅ … ⋅ M_k ^W ^k pour le label t. Cette signature S est calculée comme suit : S=σ₀ ^w ⁰ ⋅ … ⋅ σ_k ^w ^k.

L’algorithme Verify permet de vérifier la validité d’une signature σ sur un ensemble de données M pour un label t. Selon l’implémentation proposée ici, l’algorithme vérifie si l’équation suivante est satisfaite : e(σ, g₂ ^a ⋅ g₂ ^t) = e(m₀, g₂ ^b ⁰) ⋅ … ⋅ e(m_n, g₂ ^b ⁿ).

Comme évoqué précédemment, d’autres mécanismes pourraient être utilisés dans le cadre de l’invention. Nous pouvons, par exemple, citer les mécanismes de signature proposés dans les documents suivants (ou les références mentionnées dans ceux-ci) : Libert et al. « Linearly Homomorphic Structure-Preserving Signatures and Their Applications », Advances in Cryptology – Crypto 2013 ; et Fuchsbauer et al., « Structure-Preserving Signatures on Equivalence Classes and Constant-Size Anonymous Credentials », Journal of Cryptology, 2019.

Le mécanisme de signature étant introduit, nous présentons maintenant comment celui-ci est utilisé par le système d'authentification. Nous détaillons ainsi la mise en œuvre des différentes étapes du procédé d’authentification proposé.

La représente un procédé mis en œuvre par un dispositif maître pour définir des paramètres publics selon un mode de réalisation de l’invention. Cette figure détaille la mise en œuvre des étapes M100 et M200 précédemment introduites en référence à la .

L’étape M100 permet au dispositif maître MST de définir les paramètres publics PP. Ces paramètres PP peuvent être fournis à tous les dispositifs du système SYS sans compromettre la sécurité de celui-ci. Le dispositif maître MST génère ensuite, au cours de l’étape M200, une clé publique pk_M et une clé privée sk_M. Nous détaillons ci-dessous la mise en œuvre de ces étapes.

Au cours de l’étape M100, le dispositif maître MST détermine les paramètres publics PP. Spécifiquement, il met en œuvre au moins les étapes M110 et M120.

Au cours de l’étape M110, le dispositif maître MST sélectionne des éléments {g, h₀, …, h_n} de G1. Il sélectionne également un élément g₁ de G1 et un élément g₂ de G2. Tous ces éléments appartiennent aux paramètres publics PP du système d’authentification SYS.

Au cours de l’étape M120, le dispositif maître MST sélectionne un mécanisme Σ de signature. Il peut avantageusement s’agir du mécanisme linéairement homomorphe présenté ci-dessus, mais d'autres mécanismes pourraient être utilisés. Ci-après, pour désigner un des algorithmes du mécanisme de signature Σ, par exemple l’algorithme Keygen, nous utilisons la notation Σ.Keygen.

Au cours de l’étape M200, le dispositif maître MST obtient une clé publique pk_M et une clé privée sk_M. Pour ce faire, il met en œuvre les étapes M210 et M220.

Au cours de l’étape M210, le dispositif maître MST obtient une clé publique pk et une clé privée sk en utilisant l’algorithme Σ.Keygen. La clé publique pk comprend notamment les éléments g₁ et g₂ appartenant aux paramètres publics PP.

Au cours de l’étape M220, le dispositif maître MST obtient une paire de clés El Gamal. Plus précisément, il obtient : une clé privée sk_e formée par un entier compris entre 0 et p-1 ; et une clé publique pk_e = g₁ ^sk ^e. Il pourrait alternativement être envisagé d’utiliser une paire de clés pour un système dit double El Gamal.

Le dispositif maître MST obtient ainsi la paire de clés (pk_M, sk_M). La clé publique pk_M comprend : la clé publique pk dont notamment les éléments g₁ et g₂ ; et la clé publique pk_e. La clé privée sk_M comprend elle : la clé privée sk ; et la clé privée sk_e.

Une fois ces étapes effectuées, tout dispositif destiné à assurer une fonction d'émetteur doit s'enregistrer auprès du dispositif maître MST (étapes M300 et I300). Nous détaillons un tel enregistrement en référence à la figure suivante.

La représente un procédé mis en œuvre par un dispositif maître et un dispositif émetteur pour autoriser le dispositif émetteur à certifier des données d’un dispositif utilisateur selon un mode de réalisation de l’invention.

Lors des étapes I300 et M300, le dispositif émetteur ISR communique avec le dispositif maître MST pour s'enregistrer auprès de lui. Il obtient ainsi une clé publique pk_I et une clé privée sk_I, lui permettant de certifier des données de dispositifs utilisateurs USR. L’enregistrement du dispositif émetteur ISR auprès du dispositif maître MST comprend au moins les étapes ci-dessous.

Au cours de l’étape I310, le dispositif émetteur ISR sélectionne un entier x. Cet entier est compris dans la clé privée sk_I du dispositif émetteur ISR. Il est donc secret.

Au cours de l’étape I320, le dispositif émetteur ISR calcule un ou plusieurs éléments de la forme B^x, avec B appartenant aux paramètres publics PP. Il envoie ensuite le ou les éléments de la forme B^x au dispositif maître MST.

Dans le premier mode de réalisation, le dispositif émetteur ISR envoie l’élément g₁ ^xau dispositifmaître MST. En revanche, dans le deuxième mode de réalisation, le dispositif émetteur ISR envoie les éléments {g^x, h₀ ^x, …, h_n ^x} au dispositifmaître MST.

Au cours de l’étape M330, le dispositif maître MST sélectionne un label t propre au dispositif émetteur ISR. Il peut par exemple s’agir d’un identifiant du dispositif émetteur ISR.

Au cours de l’étape M340, le dispositif maître MST détermine une signature S pour chaque élément B^x reçu du dispositif émetteur ISR. Il utilise l’expression : S = Σ.Sign(sk, (B, B^x), t).

Pour le premier mode de réalisation, le dispositif maître MST obtient lors de cette étape : une seule signature S sur (g₁,g₁ ^x). En revanche, pour le deuxième mode de réalisation, le dispositif maître MST obtient : une signature S’ sur (g, g^x) ; et une pluralité de signatures S_i portant respectivement sur (h_i, h_i ^x) avec 0≤i≤n.

Au cours de l’étape M350, le dispositif maître MST détermine une signature S* = Σ.Sign(sk, (pk_e, 1), t). En d’autres termes, la signature S* est une signature sur la clé publique pk_e du dispositif maître MST. Le dispositif maître MST fournit le label t et les signatures S et S* au dispositif émetteur ISR.

Au cours de l’étape I360, le dispositif émetteur ISR obtient la paire de clés publique-privée (pk_I, sk_I), lui permettant de certifier des données. Comme indiqué précédemment, la clé privée sk_I comprend l’entier secret x. La clé publique pk_I comprend elle : le label t ; l’élément g₂ ^x ; le ou les éléments B^x ; et les signatures S et S*.

Une fois enregistré auprès du dispositif maître MST, le dispositif émetteur ISR est en mesure de certifier des données d’un dispositif utilisateur USR, et ce en lui fournissant un certificat CERT (étapes I400 et U400). Nous décrivons maintenant les échanges entre le dispositif utilisateur USR et le dispositif émetteur ISR pour obtenir un tel certificat CERT.

La représente un procédé mis en œuvre par un dispositif émetteur et un dispositif utilisateur pour certifier des données du dispositif utilisateur selon un mode de réalisation de l’invention. Cette figure illustre la mise en œuvre des étapes U400 et I400.

Lors de ces étapes, le dispositif utilisateur USR communique avec le dispositif émetteur ISR pour obtenir un certificat CERT sur un ensemble de données {m₀, …, m_n} (c'est-à-dire un ensemble d’attributs). Plus précisément, le dispositif utilisateur USR obtient ainsi une clé secrète sk_u permettant d’authentifier tout ou partie de l’ensemble de données {m₀, …, m_n}.

Comme illustré sur la , le dispositif utilisateur USR et le dispositif émetteur ISR mettent en œuvre au moins les étapes ci-dessous.

Au cours de l’étape U410, le dispositif utilisateur USR calcule un élément H défini par l’expression H = g ⋅ h₀ ^m ⁰ ⋅ … ⋅ h_n ^m ⁿ. Nous rappelons que les éléments {g, h₀, …, h_n} appartiennent aux paramètres publics PP.

Au cours de l’étape U420, mise en œuvre uniquement dans le deuxième mode de réalisation, le dispositif utilisateur USR calcule l’élément H^x en utilisant la clé publique pk_I du dispositif émetteur ISR et l’ensemble de données {m₀, …, m_n}. Notons que le dispositif utilisateur USR peut calculer H^x sans connaître l’entier x compris dans la clé privée sk_I du dispositif émetteur ISR. Nous avons en effet : H^x = (g ⋅ h₀ ^m ⁰ ⋅ … ⋅ h_n ^m ⁿ)^x = (g^x) ⋅ (h₀ ^x)^m ⁰ ⋅ … ⋅ (h_n ^x)^m ⁿ, avec {g^x, h₀ ^x, …, h_n ^x} appartenant à la clé publique pk_I du dispositif émetteur ISR.

Au cours de cette même étape U420, le dispositif utilisateur USR obtient également une signature S sur les éléments (H, H^x). Cette signature S est obtenue en utilisant l’expression : S = Σ.Eval(pk, t, S’, S₀, …, S_n, (1, m₀, …, m_n)). Comme précédemment indiqué, S’ est une signature sur (g, g^x) et S_i est une signature sur (h_i, h_i ^x) (cf. étape M340).

Le dispositif utilisateur USR envoie ensuite l’élément H au dispositif émetteur ISR. Dans le deuxième mode de réalisation, il envoie également l’élément H^x et la signature S.

Au cours de l’étape I430, le dispositif émetteur ISR sélectionne un entier y. Il calcule ensuite un élément A = H^1/( ^x+y ⁾ en utilisant l’élément H reçu du dispositif utilisateur USR et l’entier x compris dans sa clé privée sk_I.

Au cours de l’étape I440, mise en œuvre uniquement dans le deuxième mode de réalisation, le dispositif émetteur ISR calcule l’élément A^x = (H^x)^1/( ^x+y ⁾et une signature S_u = Σ.Eval(pk, t, S, 1/(x+y)). Cette signature S_uest, par construction, une signature sur les éléments (H^1/( ^x+y ⁾, (H^x)^1/( ^x+y ⁾).

Le dispositif émetteur ISR fournit au dispositif utilisateur USR un certificat CERT certifiant de l’authenticité de l’ensemble de données {m₀, …, m_n}. Ce certificat CERT comprend au moins l’entier y et l’élément A. Pour le deuxième mode de réalisation, il comprend en outre l’élément A^x et la signature S_u.

Au cours de l’étape U450, le dispositif utilisateur USR obtient une clé secrète sk_u permettant de prouver l’authenticité de tout ou partie de l’ensemble de données {m₀, …, m_n}. Cette clé secrète sk_u comprend : l’élément H ; l’entier y ; et l’élément A. Pour le deuxième mode de réalisation, elle comprend aussi : l’élément A^x et la signature S_u.

Le dispositif utilisateur USR peut utiliser cette clé secrète sk_u pour authentifier tout ou partie de l’ensemble de données {m₀, …, m_n} (étape U500). Il génère à cet effet un jeton d’authentification TOK_U, ce que nous détaillons maintenant.

La représente un procédé mis en œuvre par un dispositif utilisateur pour authentifier des données auprès d’un dispositif vérificateur selon un mode de réalisation de l’invention. Cette figure présente la mise en œuvre de l’étape U500 du procédé proposé.

Nous considérons ici que le dispositif utilisateur USR prouve l'authenticité d'un sous-ensemble MSG de l'ensemble de données {m₀, ..., m_n}. Il est important de noter que ce sous-ensemble MSG peut correspondre à tout ou partie de l'ensemble {m₀, ..., m_n}.

Plus particulièrement, nous décrivons ci-après la solution proposée en considérant que le sous-ensemble MSG est {m₀, ..., m_m} avec m ≤ n. Néanmoins, la solution proposée s'applique bien entendu à n'importe quel sous-ensemble MSG de l'ensemble de données.

Comme illustré par la , le dispositif utilisateur USR met en œuvre au moins les étapes U510 à U550 ci-dessous.

Au cours de l’étape U510, le dispositif utilisateur USR sélectionne deux aléas entiers r et k. Il calcule ensuite un ensemble d’éléments dits d’authentification à partir des paramètres publics PP, de la clé secrète sk_U, et des aléas r et k.

Dans le premier mode de réalisation, le dispositif utilisateur USR calcule un chiffré C₁= g₁ ^k et C₂= g₁ ^r ⋅ pk_e ^k. Il calcule en outre les éléments P’₁ = (g₁ ^x)^r et P’₂ = (g₂ ^x)^r, élevés à la puissance r⋅x.

Dans le deuxième mode de réalisation, le dispositif utilisateur USR calcule un chiffré C₁ = g₁ ^k et C₂= A^r ⋅ pk_e ^k. Il calcule en outre l’élément P’₁ = (A^x)^r, élevé à la puissance r⋅x.

Au cours de l’étape U520, le dispositif utilisateur USR calcule une signature Z à partir des signatures S_u et S*, et des aléas r et k. Plus précisément, le dispositif utilisateur USR obtient la signature Z en utilisant l’expression : Z = ∑.Eval(pk, t, S_u, S*, (r, k)).

Dans le premier mode de réalisation, S_u correspond à la signature S sur (g₁, g₁ ^x), et S* est une signature sur (pk_e, 1). Il en résulte que la signature Z est une signature sur (g₁ ^r⋅ pk_e ^k, g₁ ^r ^⋅ ^x) = (C₂, P’₁). Les signatures S et S* sont toutes deux obtenues pour le même label t propre au dispositif émetteur ISR et sont comprises dans la clé publique pk_I de celui-ci.

Dans le deuxième mode de réalisation, S_u est une signature sur (A, A^x) et S* est une signature sur (pk_e, 1) pour le label t. Aussi, la signature Z est une signature sur (A^r⋅ pk_e ^k, A^r ^⋅ ^x) = (C₂, P’₁). La signature S_u est comprise dans la clé secrète sk_u, tandis que la signature S* est comprise dans la clé publique pk_I du dispositif émetteur ISR.

Au cours de l’étape U530, mise en œuvre uniquement dans le premier mode de réalisation, le dispositif utilisateur USR sélectionne un aléa entier v. Il calcule ensuite des éléments D₁ = A^v et D₂= H^r ^⋅ ^v ⋅ D₁ ^-r ^⋅ ^y. Il convient de noter que D₂ = A^r ^⋅ ^v ^⋅ ^x.

Au cours de l’étape U540, le dispositif utilisateur USR produit une preuve de connaissance π associée aux éléments C1 et C2, à la signature Z, et à un élément H’=g ⋅ h₀ ^m ⁰ ⋅ … ⋅ h_m ^m ^moù m≤n.

La preuve de connaissance π prouve que les éléments C₁ et C₂ sont bien formés. Elle prouve également que la signature Z est valide sur (C₂, P’₁) pour le label t.

La preuve de connaissance π est également associée à l’élément H’. Il convient de distinguer deux cas de figure selon que le dispositif utilisateur USR authentifie tout ou partie de l’ensemble de données {m₀, …, m_n}. Nous rappelons que l’élément H=g ⋅ h₀ ^m ⁰ ⋅ … ⋅ h_n ^m ⁿ.

Considérons tout d’abord que le dispositif utilisateur USR authentifie tout l’ensemble de données {m₀, …, m_n}. Nous avons dans ce cas m=n et H’=H. Dans le premier mode de réalisation, la preuve π prouve qu’il existe α et β tels que : D₂ D₁ ^β = H^α. Dans le deuxième mode de réalisation, la preuve π prouve qu’il existe α et β tels que : C₂ pk_e ^-k P’₁ ^β = H^α.

Considérons désormais que le dispositif USR authentifie une partie seulement de l’ensemble de données {m₀, …, m_n}. Nous avons dans ce cas m<n et H’ ⋅ (h_m+1 ^m ^m+1 ⋅ … ⋅ h_n ^m ⁿ) = H. Dans le premier mode de réalisation, la preuve π prouve qu’il existe α, β, et {m_m+1, …, m_n} tels que : D₂ ⋅ D₁ ^β = H’^α ⋅ (h_m+1 ^m ^m+1 ⋅ … ⋅ h_n ^m ⁿ)^α. Dans le deuxième mode de réalisation, la preuve π prouve qu’il existe α, β, et {m_m+1, …, m_n} tels que : C₂ ⋅ pk_e ^-k ⋅ P’₁ ^β = H’^α ⋅ (h_m+1 ^m ^m+1 ⋅ … ⋅ h_n ^m ⁿ)^α.

La preuve de connaissance π est, selon un mode de réalisation, une preuve à divulgation nulle de connaissance. La preuve de connaissance π peut notamment être obtenue en utilisant le protocole de Schnorr proposé dans le document : Schnorr, « Efficient Identification and Signatures for Smart Cards », Proceedings of Crypto 1989. Il pourrait également être envisagé d’utiliser le protocole proposé dans le document : Groth et Sahai, « Efficient Non-interactive Proof Systems for Bilinear Groups », Advances in Cryptology – Eurocrypt 2008.

Le jeton d’authentification TOK_U comprend alors : C₁, C₂, Z, P’₁, et π. Dans le premier mode de réalisation, il comprend en outre : P’₂, D₁, D₂.

Au cours de l’étape U550, le dispositif utilisateur USR fournit à un dispositif vérificateur VRF le sous-ensemble de données MSG et le jeton d’authentification associé TOK_U. Il prouve ainsi l’authenticité du sous-ensemble de données MSG auprès du dispositif vérificateur VRF.

La solution proposée garantit que les jetons d'authentification sont infalsifiables (« unforgeable » en anglais). Autrement dit, un dispositif utilisateur ne peut pas prouver la validité de données qui n'ont pas été certifiées par un dispositif émetteur.

Nous décrivons, en référence à la figure suivante, les étapes mises en œuvre par le dispositif vérificateur VRF pour vérifier le jeton d’authentification TOK_U.

La représente un procédé mis en œuvre par un dispositif vérificateur pour vérifier l’authenticité de données d’un dispositif utilisateur selon un mode de réalisation de l’invention.

Cette figure détaille la mise en œuvre de l’étape V600 introduite en référence à la . Pour vérifier la validité du jeton d’authentification TOK_U, et donc l’authenticité du sous-ensemble de données MSG, le dispositif vérificateur VRF met en œuvre au moins les étapes ci-dessous.

Au cours de l’étape V610, le dispositif vérificateur VRF obtient le sous-ensemble de données MSG et le jeton d’authentification TOK_U fournis par le dispositif utilisateur USR. Bien évidemment, le dispositif vérificateur VRF dispose des paramètres publics PP et de la clé publique pk_M du dispositif maître MST.

Au cours de l’étape V620, le dispositif vérificateur VRF calcule l’élément H’=g ⋅ h₀ ^m ⁰ ⋅ … ⋅ h_m ^m ^m. Nous rappelons que les éléments {g, h₀, …, h_m} appartiennent aux paramètres publics PP, et que {m₀, …, m_m} désigne le sous-ensemble de données MSG avec m≤n.

Au cours de l’étape V630, le dispositif vérificateur VRF vérifie la validité de la preuve de connaissance π comprise dans le jeton d'authentification TOK_U.

Pour confirmer que la solution proposée fonctionne correctement, montrons que la preuve π est valide lorsque le jeton TOK_U est obtenu conformément au procédé proposé.

Premièrement, la preuve π prouve que la signature Z est valide sur (C₂, P’₁) pour le label t. Nous avons précédemment démontré que Z est effectivement une signature sur (C₂, P’₁) (cf. étape U520).

Deuxièmement, dans le premier mode de réalisation, la preuve π prouve qu’il existe α et β tels que : D₂ D₁ ^β = H^α. Ceci est vérifié pour α = r⋅v et β = r⋅y par construction de D₂. Dans le deuxième mode de réalisation, la preuve de connaissance π prouve qu’il existe α et β tels que : C₂ pk_e ^-k P’₁ ^β = H^α. Cette équation est vérifiée pour α = r/y et β = 1/y. En reprenant les définitions de C₂, P’₁ et A, nous pouvons montrer que C₂ pk_e ^-k P’₁ ^1/y =A^r ⋅ A^r.x ^/y= A⁽ ^ry ⁺ ^rx ^)/y = H^r ^/y.

Au cours de l’étape V640, mise en œuvre uniquement dans le premier mode de réalisation, le dispositif vérificateur VRF vérifie si les deux équations suivantes sont satisfaites : a) e(g₁, P’₂) = e(P’₁, g₂) ; et b) e(D₂, g₂) = e(D₁, P’₂).

Aussi, pour confirmer le bon fonctionnement de la solution proposée, montrons que ces deux équations sont satisfaites lorsque le jeton TOK_U est obtenu conformément au procédé proposé.

D’une part, P’₁ et P’₂ correspondent aux éléments g₁ et g₂ élevés à la puissance r x (cf. étape U510), ce qui garantit que l’équation a) est satisfaite. D’autre part, pour l’équation b), nous avons e(D₁, P’₂) = e(D₁, g₂ ^r.x) = e(A^r.v.x, g₂) = e(D₂, g₂), puisque D1 = A^v et D₂ = A^r ^⋅ ^v ^⋅ ^x (cf. étape U530).

Si le résultat de la vérification à l'étape V630 est positif, et également celui de la vérification à l'étape V640 pour le premier mode de réalisation, alors le jeton d'authentification TOK_U est valide. Dans le cas contraire, le jeton d’authentification TOK_U est considéré invalide.

Il convient de noter que le dispositif vérificateur VRF vérifie l'authenticité du sous-ensemble de données MSG sans utiliser la clé publique du dispositif émetteur ISR. Il n'a pas non plus besoin de connaître l'intégralité des données certifiées {m₀, ..., m_n} pour vérifier le sous-ensemble MSG.

En d’autres termes, le dispositif utilisateur USR peut authentifier une partie seulement des données {m₀, ..., m_n}, et ce sans avoir à révéler ni l’ensemble des données certifiées, ni l'identité du dispositif émetteur ISR. La solution proposée permet de préserver l’anonymat des dispositifs utilisateurs USR et celui des dispositifs émetteurs ISR.

La solution proposée s'applique notamment à la mise en œuvre de systèmes d'authentification dans le domaine de l'identité numérique. Elle permet à un utilisateur d'obtenir un certificat sur son identité auprès d'un émetteur. Il peut alors prouver son identité à un vérificateur en conservant le contrôle sur ses données personnelles et sans avoir à révéler l'identité de l'émetteur.

Cependant, la solution proposée permet au dispositif maître MST de lever l’anonymat d’un dispositif émetteur ISR. Nous détaillons ci-dessous comment le dispositif maître MST identifie le dispositif émetteur ISR associé à un jeton d’authentification TOK_U (étape M700).

La représente un procédé mis en œuvre par un dispositif maître pour identifier un dispositif émetteur associé à un jeton d’authentification selon un mode de réalisation de l’invention.

Pour des raisons de sécurité, par exemple sur demande des autorités, il peut être nécessaire de retrouver le dispositif émetteur ISR associé à un jeton d’authentification TOK_U. Ceci peut être réalisé par le dispositif maître MST, et uniquement ce dispositif. Il utilise pour ce faire les clés publiques des dispositifs émetteurs ISR enregistrés, et met en œuvre les étapes M710 et M720.

Au cours de l’étape M710, le dispositif maître MST déchiffre les éléments C₁ et C₂ compris dans le jeton TOK_U, et ce en utilisant sa clé privée sk_e. Il obtient un élément de la forme B^r, où r est l’aléa utilisé lors de la génération du jeton TOK_U (cf. étape U510).

Notons que seul le dispositif maître MST peut mettre en œuvre cette étape, puisqu’elle nécessite la connaissance de la clé privée sk_e du dispositif maître MST.

Au cours de l’étape M720, le dispositif maître MST effectue un test pour chacun des dispositifs émetteurs ISR enregistrés. Ce test permet de déterminer si le dispositif ISR considéré est celui associé au jeton TOK_U. Le test utilise : l'élément B^robtenu, l'élément g₂ appartenant aux paramètres publics PP, l'élément P'₁ compris dans le jeton TOK_U, et l'élément g₂ ^x compris dans la clé publique pk_I du dispositif émetteur ISR considéré.

Plus précisément, pour chaque dispositif émetteur ISR, le dispositif maître MST vérifie si l’équation suivante est satisfaite : e(B^r, g₂ ^x) = e(P’₁, g₂). Si le résultat de cette vérification est positif, le dispositif émetteur ISR comprenant l’élément g₂ ^x dans sa clé publique pk_I est celui impliqué dans le jeton d’authentification TOK_U.

À titre d’exemple, le dispositif maître MST peut être un serveur d’une autorité nationale. Il pourrait notamment lever l'anonymat de certains jetons d’authentification pour s'assurer qu'aucun certificat frauduleux n'est utilisé.

La solution proposée ayant été décrite dans ses différents aspects, nous en évaluons maintenant la complexité.

Les tableaux 1 et 2 sont présentés ci-dessous pour évaluer la taille d’un jeton d’authentification dans différents modes de réalisation de l’invention. Nous supposons ici que le dispositif utilisateur USR authentifie l’ensemble de données {m₀, …, m_n} dans son intégralité.

Un jeton d’authentification TOK_U comporte une partie de taille fixe et une partie de taille variable. La partie de taille fixe comprend au moins les éléments C₁, C₂, P’₁,c’est-à-dire trois éléments de G1. Pour le premier mode de réalisation uniquement, la partie de taille fixe comprend en outre les éléments P’₂, D₁, D₂,c’est-à-dire deux éléments de G1 et un élément de G2. La partie de taille variable correspond à la signature Z et à la preuve π, dont la taille varie en fonction du mécanisme de signature utilisé.

Le tableau 1 décrit le nombre d’éléments dans Z et π pour différents modes de réalisation :

	mécanisme Σ de Fuchsbauer et al.	mécanisme Σ proposé
premier mode de réalisation	2 G1, 1 G2 et 5 scalaires	1 G1 et 6 scalaires
deuxième mode de réalisation	2 G1, 1 G2 et 4 scalaires	1 G1 et 5 scalaires

Nous considérons ici que le mécanisme de signature Σ correspond : soit au mécanisme décrit dans le document Fuchsbauer et al. (colonne 1) ; soit au mécanisme de signature linéairement homomorphe proposé et décrit ci-dessus (colonne 2). Également, le nombre d’éléments compris dans Z et π est présenté en considérant le premier mode de réalisation (ligne 1) et le deuxième mode de réalisation de la solution proposée (ligne 2).

Ce tableau confirme que le mécanisme de signature linéairement homomorphe proposé (colonne 2) permet avantageusement de réduire la taille des jetons d’authentification.

Le tableau 2 présente la taille en octets d’un jeton d'authentification TOK_U pour les différents modes de réalisation considérés :

	mécanisme Σ de Fuchsbauer et al.	mécanisme Σ proposé
premier mode de réalisation	688 octets	576 octets
deuxième mode de réalisation	464 octets	352 octets

Les différentes tailles de jetons présentées dans ce tableau sont obtenues de la manière suivante. L'environnement bilinéaire est implémenté en utilisant une courbe elliptique, et plus précisément la courbe elliptique dénommée BLS12-381 et décrite dans le document suivant : Bowe, « BLS12-381 : New zk-SNARK elliptic curve construction », 2017, https:/electriccoin.co/blog/new-snark-curve/. Les points de cette courbe sont ensuite compressés en utilisant des techniques standards connues de l’homme du métier.

Nous pouvons constater que le deuxième mode de réalisation permet d'obtenir des jetons d'authentification plus courts par rapport au premier mode de réalisation. En revanche, le premier mode de réalisation permet au dispositif utilisateur d'obtenir un certificat en mettant en œuvre un procédé de moindre complexité (cf. étapes U400 et I400).

En comparaison avec la solution de Boboz et al., la solution proposée présente une complexité de mise en œuvre minime. Elle nécessite significativement moins de calculs et permet d'obtenir des jetons d'authentification plus courts. La solution proposée permet ainsi de réduire la quantité de données échangées entre un utilisateur et un vérificateur, et le temps nécessaire pour réaliser une authentification. De plus, la solution proposée permet de lever l'anonymat de l'émetteur.

Il convient également de mentionner que la solution proposée est avantageusement compatible avec le standard BBS+ précité.

Nous décrivons ici l'architecture matérielle d'un dispositif APP. Cette description est commune aux dispositifs maître MST, émetteur ISR, utilisateur USR, et vérificateur VRF. En fait, chacun de ces dispositifs peut disposer de cette architecture matérielle.

Le dispositif APP comprend, selon le mode de réalisation de la , au moins un processeur PROC et au moins une mémoire MEM.

Plus particulièrement, le dispositif APP dispose, selon un mode de réalisation, de l’architecture matérielle d’un ordinateur. La mémoire MEM constitue un support d’informations conforme à l’invention, c’est-à-dire lisible par le processeur PROC et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention. Le programme PROG comporte des instructions pour réaliser des étapes d’un procédé conforme à l’invention, lorsque le programme PROG est exécuté par le processeur PROC. Le programme PROG définit notamment les modules fonctionnels du dispositif APP, qui commandent les éléments matériels de ce dernier.

Comme illustré sur la , le dispositif APP comprend un dispositif de communication COM configuré pour communiquer avec tout ou partie des autres dispositifs du système SYS. Aucune limitation n'est attachée à la nature des interfaces de communication entre ces dispositifs, qui peuvent mettre en œuvre tout protocole connu de l'homme du métier.

De manière générale, pour chaque étape (ou opération) d’un procédé conforme à l’invention, un dispositif MST, ISR, USR, VRF peut comprendre un module ou un élément correspondant configuré pour réaliser ladite étape.

En particulier, le dispositif maître MST comprend : un module de détermination de paramètres publics PP (étape M100) ; un module d’obtention d’une paire de clés publique-privée (pk_M, sk_M) (étape M200) ; un module d’autorisation d’un dispositif émetteur à certifier des données (étape M300) ; et un module d’identification d’un dispositif émetteur ISR associé à un jeton d’authentification TOK_U (étape M700).

Le dispositif émetteur ISR comprend notamment : un module d’obtention d’une paire de clés publique-privée (pk_I, sk_I) (étape I300) ; et un module de fourniture d’un certificat CERT à un dispositif utilisateur (étape I400).

Aussi, le dispositif utilisateur USR comprend : un module d’obtention d’une clé secrète sk_u, cette clé sk_u comprenant notamment un certificat CERT fourni par le dispositif émetteur ISR (étape U400) ; et un module de fourniture de jeton d’authentification TOK_U (étape U500). Le dispositif vérificateur VRF comprend lui : un module de vérification de jeton d’authentification TOK_U (étape V600).

Claims

Procédé mis en œuvre par un dispositif utilisateur (USR) pour authentifier un sous-ensemble (MSG) d’un ensemble de données ({m₀, …, m_n}) auprès d’un dispositif vérificateur (VRF),
le dispositif utilisateur (USR) disposant de :
une clé secrète (sk_U) permettant d’authentifier tout ou partie de l’ensemble de données ({m₀, …, m_n}), cette clé (sk_U) comprenant au moins :

un élément H calculé à partir d’éléments ({g, h₀, …, h_n}) appartenant à des paramètres publics (PP) définis par un dispositif maître (MST), et de l’ensemble de données ({m₀, …, m_n}) ; et

un certificat (CERT) fourni par un dispositif émetteur (ISR) et certifiant l’authenticité de l’ensemble de données ({m₀, …, m_n}), le certificat (CERT) comprenant au moins : un aléa y ; et un élément A calculé à partir de l’élément H, de l’aléa y, et d’un scalaire x appartenant à une clé privée (sk_I) du dispositif émetteur (ISR) ; et
le procédé comprenant :
une fourniture (U500) d’un jeton d’authentification (TOK_U) du sous-ensemble de données (MSG), ce jeton (TOK_U) comprenant au moins :

un ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂) calculé à partir des paramètres publics (PP), de la clé secrète (sk_U) du dispositif utilisateur (USR), et d’aléas r et k ;

une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour un label t propre au dispositif émetteur (ISR), la signature S* appartenant à une clé publique (pk_I) du dispositif émetteur (ISR) ; et

une preuve de connaissance π associée aux éléments d’authentification (C₁, C₂), à la signature Z, et à un élément H’ calculé à partir des éléments ({g, h₀, …, h_n}) appartenant aux paramètres publics (PP) et du sous-ensemble de données (MSG).
Procédé selon la revendication 1, dans lequel :
l’ensemble d’éléments d’authentification du jeton (TOK_U) comprend les éléments : C₁=g₁ ^k ; C₂ = g₁ ^r ⋅ pk_e ^k ; P’₁ = (g₁ ^x)^r ; P’₂ = (g₂ ^x)^r ; D₁=A^v ; et D₂= H^r ^⋅ ^v⋅ D₁ ^-r ^⋅ ^y, où g₁ et g₂ appartiennent aux paramètres publics (PP), g₁ ^x et g₂ ^x appartiennent à la clé publique (pk_I) du dispositif émetteur (ISR), v est un aléa, et pk_e appartient à la clé publique (pk_M) du dispositif maître (MST) ; et

la signature S_u est une signature sur {g₁, g₁ ^x} et la signature S* est une signature sur {pk_e, 1} pour le label t, ces signatures appartenant à la clé publique (pk_I) du dispositif émetteur (ISR).
Procédé selon la revendication 1, dans lequel :
l’ensemble d’éléments d’authentification du jeton (TOK_U) comprend les éléments : C₁=g₁ ^k ; C₂= A^r⋅ pk_e ^k ; et P’₁=(A^x)^r, où g₁ appartient aux paramètres publics (PP), A^x est comprise dans le certificat (CERT) fourni par le dispositif émetteur (ISR), et pk_e appartient à la clé publique (pk_M) du dispositif maître (MST) ; et

la signature S_u est une signature sur {A, A^x} pour le label t et est comprise dans le certificat (CERT) fourni par le dispositif émetteur (ISR), et la signature S* est une signature sur {pk_e, 1} pour le label t.
Procédé mis en œuvre par un dispositif vérificateur (VRF) pour vérifier l’authenticité d’un sous-ensemble (MSG) d’un ensemble de données ({m₀, …, m_n}) d’un dispositif utilisateur (USR),
le procédé comprenant :
une vérification (V600) d’un jeton d’authentification (TOK_U) du sous-ensemble de données (MSG), ce jeton (TOK_U) comprenant au moins :

un ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂) calculé à partir de paramètres publics (PP) définis par un dispositif maître (MST), d’une clé secrète (sk_U) du dispositif utilisateur (USR), et d’aléas r et k ;

une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour un label t propre au dispositif émetteur (ISR), la signature S* appartenant à une clé publique (pk_I) du dispositif émetteur (ISR) ; et

une preuve de connaissance π associée aux éléments d’authentification (C₁, C₂), à la signature Z, et à un élément H’ calculé à partir d’éléments ({g, h₀, …, h_m}) appartenant aux paramètres publics (PP), et du sous-ensemble de données (MSG) ;
et dans lequel :
la vérification (V600) du jeton (TOK_U) comprend au moins : une vérification (V630) de la validité de la preuve de connaissance π en utilisant l’ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂), la signature Z, et l’élément H’.
Procédé mis en œuvre par un dispositif émetteur (ISR) pour certifier un ensemble de données ({m₀, …, m_n}) d’un dispositif utilisateur (USR), le dispositif émetteur (ISR) disposant de :
une paire de clés publique-privée (pk_I, sk_I) comprenant au moins :

pour la clé privée (sk_I) : un scalaire x ; et

pour la clé publique (pk_I) : un label t propre au dispositif émetteur (ISR) ; et une signature S* fournie par un dispositif maître (MST), S* étant une signature sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour le label t ; et
le procédé comprenant :
une fourniture (I400) au dispositif utilisateur (USR) d’un certificat (CERT) certifiant l’authenticité de l’ensemble de données ({m₀, …, m_n}), ce certificat (CERT) comprenant au moins :

un aléa y ; et

un élément A calculé à partir d’un élément H, du scalaire x, et de l’aléa y, l’élément H étant calculé à partir d’éléments ({g, h₀, …, h_n}) appartenant à des paramètres publics (PP) définis par le dispositif maître (MST) et de l’ensemble de données ({m₀, …, m_n}).
Procédé mis en œuvre par un dispositif maître (MST) pour autoriser un dispositif émetteur (ISR) à certifier un ensemble de données ({m₀, …, m_n}) d’au moins un dispositif utilisateur (USR), le dispositif maître (MST) définissant des paramètres publics (PP), et le procédé comprenant :
une fourniture (M300) au dispositif émetteur (ISR) d’éléments (t, S, S*) d’une clé publique (pk_I) du dispositif émetteur (ISR), ces éléments (t, S, S*) comprenant au moins :

un label t propre au dispositif émetteur (ISR) ; et

une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour le label t et obtenue en utilisant une clé privée (sk_M) du dispositif maître (MST).
Procédé selon la revendication 6, comprenant une identification (M700) d’un dispositif émetteur (ISR) associé à un jeton d’authentification (TOK_U) d’un dispositif utilisateur (USR), l’identification (M700) comprenant :
un déchiffrement (M710) d’éléments d’authentification chiffrés (C₁, C₂) compris dans le jeton (TOK_U) pour obtenir un élément B^r, où r est un aléa utilisé pour générer le jeton (TOK_U), ce déchiffrement (M710) étant réalisé en utilisant une partie (sk_e) de la clé privée (sk_M) du dispositif maître (MST) ; et

une vérification (M720) permettant de déterminer si le dispositif émetteur (ISR) est associé au jeton d’authentification (TOK_U) en utilisant : l’élément B^r obtenu ; un élément g₂ ^x compris dans la clé publique (pk_I) du dispositif émetteur (ISR), x un scalaire appartenant à une clé privée (sk_I) du dispositif émetteur (ISR) ; un élément P’₁ compris dans le jeton d’authentification (TOK_U) ; et un élément g₂appartenant aux paramètres publics (PP).
Procédé selon l’une quelconque des revendications 1 à 7, dans lequel un environnement bilinéaire est utilisé, ledit environnement désignant un groupe G1, un groupe G2 et un groupe GT d’ordre p, et un couplage bilinéaire, et dans lequel une dite signature σ sur un ensemble d’éléments {u₀, …, u_n} de G1 pour un label τ est obtenue en utilisant l’expression : σ = (u₀ ^b ⁰ ⋅ … ⋅ u_n ^b ⁿ)^1/( ^a+τ ⁾, où les scalaires {a, b₀, …, b_n} appartiennent à une clé privée.
Dispositif dit utilisateur (USR) configuré pour authentifier un sous-ensemble (MSG) d’un ensemble de données ({m₀, …, m_n}) auprès d’un dispositif vérificateur (VRF), le dispositif utilisateur (USR) comprenant :
une clé secrète (sk_U) permettant d’authentifier tout ou partie de l’ensemble de données ({m₀, …, m_n}), cette clé (sk_U) comprenant au moins :

un élément H calculé à partir d’éléments ({g, h₀, …, h_n}) appartenant à des paramètres publics (PP) définis par un dispositif maître (MST), et de l’ensemble de données ({m₀, …, m_n}) ; et

un certificat (CERT) fourni par un dispositif émetteur (ISR) et certifiant l’authenticité de l’ensemble de données ({m₀, …, m_n}), le certificat (CERT) comprenant au moins : un aléa y ; et un élément A calculé à partir de l’élément H, de l’aléa y, et d’un scalaire x appartenant à une clé privée (sk_I) du dispositif émetteur (ISR) ; et

un module de fourniture d’un jeton d’authentification (TOK_U) du sous-ensemble de données (MSG), ce jeton (TOK_U) comprenant au moins :

un ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂) calculé à partir des paramètres publics (PP), de la clé secrète (sk_U) du dispositif utilisateur (USR), et d’aléas r et k ;

une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour un label t propre au dispositif émetteur (ISR), la signature S* appartenant à une clé publique (pk_I) du dispositif émetteur (ISR) ; et

une preuve de connaissance π associée aux éléments d’authentification (C₁, C₂), à la signature Z, et à un élément H’ calculé à partir des éléments ({g, h₀, …, h_n}) appartenant aux paramètres publics (PP) et du sous-ensemble de données (MSG).
Dispositif dit vérificateur (VRF) configuré pour vérifier l’authenticité d’un sous-ensemble (MSG) d’un ensemble de données ({m₀, …, m_n}) d’un dispositif utilisateur (USR), le dispositif vérificateur (VRF) comprenant :
un module de vérification d’un jeton d’authentification (TOK_U) du sous-ensemble de données (MSG), ce jeton (TOK_U) comprenant au moins :

un ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂) calculé à partir de paramètres publics (PP) définis par un dispositif maître (MST), d’une clé secrète (sk_U) du dispositif utilisateur (USR), et d’aléas r et k ;

une signature Z calculée à partir des aléas r et k, d’une signature S_u, et d’une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour un label t propre au dispositif émetteur (ISR), la signature S* appartenant à une clé publique (pk_I) du dispositif émetteur (ISR) ; et

une preuve de connaissance π associée aux éléments d’authentification (C₁, C₂), à la signature Z, et à un élément H’ calculé à partir d’éléments ({g, h₀, …, h_m}) appartenant aux paramètres publics (PP), et du sous-ensemble de données (MSG) ;
et dans lequel :
le module de vérification est configuré au moins pour : vérifier (V630) la validité de la preuve de connaissance π en utilisant l’ensemble d’éléments d’authentification (C₁, C₂, P’₁, P’₂, D₁, D₂), la signature Z, et l’élément H’.
Dispositif dit émetteur (ISR) configuré pour certifier un ensemble de données ({m₀, …, m_n}) d’un dispositif utilisateur (USR), le dispositif émetteur (ISR) comprenant :
une paire de clés publique-privée (pk_I, sk_I) comprenant au moins :

pour la clé privée (sk_I) : un scalaire x ; et

pour la clé publique (pk_I) : un label t propre au dispositif émetteur (ISR) ; et une signature S* fournie par un dispositif maître (MST), S* étant une signature sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour le label t ; et

un module de fourniture au dispositif utilisateur (USR) d’un certificat (CERT) certifiant l’authenticité de l’ensemble de données ({m₀, …, m_n}), ce certificat (CERT) comprenant au moins :

un aléa y ; et

un élément A calculé à partir d’un élément H, du scalaire x, et de l’aléa y, l’élément H étant calculé à partir d’éléments ({g, h₀, …, h_n}) appartenant à des paramètres publics (PP) définis par le dispositif maître (MST) et de l’ensemble de données ({m₀, …, m_n}).
Dispositif dit maître (MST) configuré pour autoriser un dispositif émetteur (ISR) à certifier un ensemble de données ({m₀, …, m_n}) d’au moins un dispositif utilisateur (USR), le dispositif maître (MST) étant configuré pour définir des paramètres publics (PP) et comprenant :
un module de fourniture au dispositif émetteur (ISR) d’éléments (t, S, S*) d’une clé publique (pk_I) du dispositif émetteur (ISR), ces éléments (t, S, S*) comprenant au moins :

un label t propre au dispositif émetteur (ISR) ; et

une signature S* sur une partie (pk_e) d’une clé publique (pk_M) du dispositif maître (MST) pour le label t et obtenue en utilisant une clé privée (sk_M) du dispositif maître (MST).
Système (SYS) comprenant plusieurs dispositifs parmi :
un dispositif utilisateur (USR) selon la revendication 9 ;

un dispositif vérificateur (VRF) selon la revendication 10 ;

un dispositif émetteur (ISR) selon la revendication 11 ; et

un dispositif maître (MST) selon la revendication 12.
Programme d’ordinateur (PROG) comportant des instructions pour mettre en œuvre des étapes d’un procédé selon l’une quelconque des revendications 1 à 8, lorsque le programme d’ordinateur (PROG) est exécuté par au moins un processeur (PROC).
Support d’informations (MEM) lisible par ordinateur comprenant un programme d’ordinateur (PROG) selon la revendication 14.