FR3151957A1

FR3151957A1 - Méthode d’interrogation confidentielle d’une base de données

Info

Publication number: FR3151957A1
Application number: FR2308377A
Authority: FR
Inventors: Renaud Sirdey; Aymen BOUDGUIGA; Martin Zuber; Oana STAN
Original assignee: Commissariat a lEnergie Atomique CEA; Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Current assignee: Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date: 2023-08-02
Filing date: 2023-08-02
Publication date: 2025-02-07
Also published as: WO2025027253A1

Abstract

Méthode d’interrogation confidentielle par un utilisateur (U) d’une base de données (DB) pour obtenir une information cherchée, la méthode comportant les étapes suivantes : S10) l’utilisateur détermine un hash ; S20) l’utilisateur calcule une requête (R) comprenant un vecteur (VIC) d’identification de classe de collision chiffré fonction du hash ainsi qu’un vecteur chiffré d’identification d’enregistrement (VIE) ; S30) par une méthode de récupération d’informations privées le serveur détermine les chiffré(s) FHE de la classe de collision cherchée (V) ; S50) à partir du vecteur d’identification d’enregistrement (VIE), le serveur détermine par calcul homomorphe un chiffré de l’information cherchée, et le transmet à l’utilisateur ; et S60) l’utilisateur déchiffre alors le chiffré de l’information cherchée. Figure pour l’abrégé : Figure 2

Description

Méthode d’interrogation confidentielle d’une base de données

DOMAINE TECHNIQUE DE L’INVENTION

Le domaine de l’invention est celui de l’interrogation confidentielle de bases de données à des fins de récupération d’informations privées.

ÉTAT DE LA TECHNIQUE

L’interrogation de bases de données à des fins de récupération d’informations privées est une opération dans laquelle un utilisateur transmet une requête, c’est-à-dire une demande d’information à une base de données, et obtient en retour une réponse de la base de données à partir de laquelle il peut obtenir l’information cherchée, la base de données n’ayant jamais, tout au long de la transaction, eu la moindre information ni quant à l’information cherchée, ni quant au fait que l’information cherchée a été trouvée ou non.

De telles opérations sont pratiquées notamment lorsqu’une base de données d’un utilisateur est confiée à un opérateur tiers, qui stocke alors la base de données sur un serveur distant. Bien que la base soit stockée sur le serveur, elle reste la propriété de l’utilisateur. Dans ce contexte, il est nécessaire de fournir des garanties de confidentialité sur la base de données vis-à-vis du serveur tout en permettant à ce dernier de rendre le service attendu. Plus précisément, on souhaite assurer :

la confidentialité des enregistrements stockées sur le serveur, vis-à-vis de ce dernier ;
la confidentialité des requêtes issues de l’utilisateur, vis-à-vis du serveur ; et
la confidentialité des informations produites par le serveur en réponse aux requêtes qui lui sont transmises (comme des indications quant à la présence de certains enregistrements dans la base de données, etc.), toujours vis-à-vis du serveur.

Pour permettre le maintien de telles conditions de confidentialité dans le contexte notamment de bases de données externalisées, différentes méthodes de récupération d’informations privées ont été développées, ces méthodes faisant appel notamment à des méthodes de chiffrement homomorphe.

Dans le domaine de la cryptographie, une fonction de chiffrement est une fonction qui opère sur un ensemble dont les éléments sont appelés ‘clairs’. A chaque clair, la fonction de chiffrement associe une ou plusieurs images (éventuellement de manière probabiliste) appelée(s) ‘chiffré(s)’. A l’inverse, la fonction qui à un chiffré associe le clair correspondant est appelée la fonction de déchiffrement. La fonction de chiffrement et la fonction de déchiffrement associée constituent ensemble un cryptosystème.

Parmi les cryptosystèmes, des cryptosystèmes de chiffrement homomorphe ont notamment été utilisés pour réaliser des fonctions de récupération d’informations privées.

Le chiffrement homomorphe permet d’effectuer des opérations (en pratique des opérations à base d’addition ou de multiplication) sur des données sans jamais les dévoiler. Le chiffrement homomorphe est défini par exemple dans la demande de brevet internationale WO2020/070455 A1.

Un cryptosystème homomorphe est, idéalement, un système de chiffrement perméable à tout type d'opération sur les données chiffrées. Avec n'importe quel enregistrement X et fonction d’évaluation f, en notant E la fonction de chiffrement, il permet d’obtenir le chiffré E(f(x)) de l’image d’un enregistrement X par la fonction d’évaluation f de manière non interactive à partir du chiffré E(x) de l’enregistrement.

Parmi les cryptosystèmes homomorphes, on appelle cryptosystème homomorphe de type additif un cryptosystème comportant au moins l’addition en tant qu’opération élémentaire de calcul homomorphe.

De plus, on appelle cryptosystème FHE un cryptosystème homomorphe pour lequel l’espace des fonctions évaluables est l’espace des fonctions calculables. La fonction de chiffrement d’un tel système est appelée en Anglais ‘Fully Homomorphic Encryption’ (FHE). Un chiffré obtenu par une telle fonction de chiffrement est appelé ‘chiffré FHE’.

Dans un cryptosystème FHE, les paramètres peuvent être choisis indépendamment de la profondeur du calcul homomorphe à appliquer. Des exemples de système de chiffrement entièrement homomorphes sont présentés par les documents Ref.2, 6 et 7 listés ci-dessous.

Le document Ref.[1] également listé ci-dessous divulgue une méthode connue de récupération d’informations privées. Dans cette méthode, la base de données est structurée à l’avance en classes de collision. L’utilisateur envoie à un serveur une requête comportant un vecteur de chiffrés, dont un seul est le chiffré de la classe de collision dans laquelle se trouve l’enregistrement cherché ; sur la base de cette requête, le serveur détermine un chiffré de cette classe de collision, en mettant en œuvre une fonction de chiffrement d’un cryptosystème homomorphe additif. Ce chiffré est renvoyé à l’utilisateur, qui le déchiffre et peut alors obtenir l’information cherchée.

Cette méthode a l’avantage de pouvoir être appliquée à de très grandes bases de données ; cependant, elle présente l’inconvénient qu’elle laisse à l’utilisateur une partie de la tâche de recherche d’informations, puisqu’il doit lui-même trouver l’information cherchée au sein de la classe de collision.

Cette méthode de plus présente l’inconvénient d’être difficilement applicable pour obtenir des informations relatives à des données bruitées, pour lesquels la méthode de recherche d’information doit permettre de trouver les informations cherchées malgré le bruit présent dans les données (matching non-exact).

Les documents suivants présentent des méthodes dans le domaine du chiffrement homomorphe. Le document [Ref.7] présente notamment différents cryptosystèmes FHE connus, notamment les cryptosystèmes BFV, BGV, CCKS et TFHE.

La présente invention vise à remédier à tout ou partie des inconvénients de l’état de la technique cités ci-dessus et à proposer une méthode d’interrogation confidentielle d’une base de données hébergée par un serveur permettant d’obtenir une information cherchée, méthode qui soit utilisable sur des bases de données de grande taille, qui nécessite une quantité de calcul raisonnable et donc inversement des temps de réponse relativement faibles, et enfin de préférence qui soit également utilisable pour la recherche d’informations dans des bases de données contenant des données bruitées.

À cet effet, selon la présente divulgation, la méthode suivante est proposée. Cette méthode est une méthode d’interrogation confidentielle par un utilisateur d’une base de données comprenant des enregistrements et hébergée par un serveur pour obtenir une information cherchée relative à (ou fonction de) un ou plusieurs enregistrement(s) de la base de données satisfaisant un critère, le critère étant fonction d’une clé d’identification d’enregistrement, la clé d’identification d’enregistrement étant un vecteur de valeur(s) d’un ou plusieurs champs d’un enregistrement ;

une fonction de hashage étant définie de telle sorte que, pour un critère donné, tous les enregistrements qui satisfont le critère génèrent le même hash ;

un ensemble des enregistrements ayant un même hash étant appelé classe de collision ;

la méthode comportant les étapes suivantes pour obtenir une information cherchée, fonction d’une clé d’identification d’enregistrement :

S10) l’utilisateur détermine un hash, dit hash de la classe de collision cherchée, commun à tous les enregistrements satisfaisant le critère défini en fonction de la clé d’identification d’enregistrement ;

S20) l’utilisateur calcule une requête comprenant un vecteur d’identification de classe de collision, chiffré, fonction du hash de la classe de collision cherchée, ainsi qu’un vecteur d’identification d’enregistrement, chiffré, fonction de la clé d’identification d’enregistrement, et envoie la requête au serveur ;

S30) sur la base du vecteur d’identification de classe de collision, par une méthode de récupération d’informations privées le serveur détermine un ou des chiffré(s) FHE de la classe de collision cherchée, représentant la classe de collision du hash de la classe de collision cherchée ;

S50) à partir du vecteur d’identification d’enregistrement, le serveur détermine par calcul homomorphe un chiffré de l’information cherchée en fonction de résultat(s) d’une évaluation du critère pour le ou les chiffré(s) de la classe de collision cherchée, et transmet le chiffré de l’information cherchée à l’utilisateur ; et

S60) l’utilisateur déchiffre alors le chiffré de l’information cherchée et obtient ainsi l’information cherchée.

Dans le présent document, l’expression ‘vecteur chiffré’ désigne un vecteur dont la ou les composantes sont chiffrées.

La méthode définie ci-dessus comporte principalement, pour le serveur, deux étapes de calcul.

Pour la mise en œuvre de la méthode, la fonction de hashage est préalablement choisie de manière à assurer que tous les enregistrements qui satisfont le critère (le critère étant alors défini à partir (ou en fonction) de la clé d’identification d’enregistrement considérée) présentent le même hash, dit hash de la classe de collision cherchée.

Dans une première étape S30, appelée aussi pré-processing, le serveur détermine le ou les chiffrés de la classe de collision cherchée. Ce ou ces chiffrés représentent l’ensemble de la classe de collision cherchée.

Cette classe de collision est la classe de collision dont font partie tous les enregistrements qui satisfont le critère défini en fonction de la clé d’identification d’enregistrement : ces enregistrements sont ceux qui vont permettre d’obtenir l’information cherchée. Cette classe de collision cherchée est identifiée par un ou plusieurs chiffrés, dits ‘chiffrés de la classe de collision cherchée’.

A partir de l’étape S30, avantageusement les calculs sont exécutés uniquement sur la base des chiffrés de la classe de collision cherchée, c’est-à-dire normalement sur un nombre d’enregistrements considérablement plus faible que le nombre total d’enregistrements dans la base de données.

De préférence, pour faciliter la réalisation de l’étape S30, avant même la mise en œuvre de la méthode, la base de données est structurée en classes de collision pour la fonction de hachage.

Lors de la deuxième étape S50, ou post-processing, la valeur du critère est évaluée sur l’ensemble du ou des chiffrés de la classe de collision cherchée ; un chiffré de l’information cherchée est alors obtenu à partir du ou des résultats de cette/ces évaluation(s).

De préférence, l’étape S50 comporte les étapes suivantes :

S52) le serveur évalue le critère pour le ou les chiffré(s) de la classe de collision cherchée en effectuant les opérations suivantes :

S521) le serveur effectue un ou des calcul(s) de distance ; et

S522) le serveur compare un ou des résultats obtenu(s) à l’étape S521 à un seuil (cette comparaison peut consister à vérifier une ou des équation(s) et/ou une ou des inéquation(s)) ; puis

S54) le serveur calcule le chiffré de l’information cherchée.

Le calcul de distance effectué à l’étape S521 peut être tout calcul dans lequel une distance entre une donnée contenue dans la base de données et le vecteur d’identification d’enregistrement (ou certaines composantes de celui-ci) est évaluée.

La deuxième étape S50 est de préférence réalisée entièrement par le serveur. Comme les chiffrés de la classe de collision cherchée sont des chiffrés FHE, les calculs réalisés à l’étape S50 sont exécutés par le serveur sur des chiffrés FHE. Aucune information exploitable n’est donc communiquée en clair au serveur. Ainsi, avantageusement l’utilisateur n’a à exécuter à l’étape S60 qu’une faible quantité de calculs, correspondant au déchiffrement de l’information cherchée.

Avantageusement, la méthode définie ci-dessus permet une décorrélation entre la taille de la base de données et le volume de calculs complexes réalisés à l’étape S50. En effet, pendant cette dernière étape, la quantité de calcul dépend seulement du nombre d’enregistrements dans la classe de collision sélectionnée pendant la première phase, mais ne dépend pas du nombre total d’enregistrements dans la base de données.

Dans certains cas, les calculs conduits sur le serveur à l’étape S50 ne conduisent pas à trouver une information correspondant à l’information cherchée.

Dans ce cas naturellement, pour assurer qu’aucune information n’est transmise au serveur, les calculs homomorphes exécutés sur le serveur produisent un résultat. Le serveur ignore si ce résultat a un sens : le serveur renvoie ce résultat, qui peut aussi bien être un chiffré de l’information cherchée, qu’un chiffré signifiant qu’aucune réponse n’a été trouvée. Par exemple conventionnellement, dans ce dernier cas le serveur peut renvoyer un chiffré de -1, la valeur ‘-1’ signifiant conventionnellement qu’aucune réponse valide n’a été trouvée.

Le critère utilisé à l’étape S50 dépend naturellement de l’information cherchée.

Dans certains modes de mise en œuvre, on cherche à identifier un enregistrement spécifique, entièrement connu, ou encore des enregistrements dont un ou plusieurs champs contiennent des valeurs spécifiques, connues à l’avance. (Le critère peut alors être de la forme « l’enregistrement = X0 » ou « les champs i et j de l’enregistrement valent (X0i, X0j)). Ces modes de mise en œuvre sont appelés ‘matching exact’.

Dans d’autres modes de mise en œuvre inversement, on cherche à identifier des enregistrements soit proches d’un certain enregistrement prédéterminé, soit donc un ou plusieurs champs contiennent des valeurs proches de valeurs correspondantes de champs d’un enregistrement de référence. Le critère peut alors être de la forme « l’enregistrement X est celui qui minimise la valeur f(X), pour tous les enregistrements X de la base de données (Il correspond donc à l’image obtenue par la fonction Argmin pour la fonction f). L’information cherchée peut être l’enregistrement lui-même, ou une valeur qui identifie cet enregistrement. Ces modes de mise en œuvre sont appelés ‘matching approché’.

Le serveur est naturellement configuré pour, à partir du vecteur d’identification d’enregistrement (et du ou des chiffrés de la classe de collision cherchée), être à même de réaliser l’étape S50. Pour cette raison, le plus souvent le critère à évaluer est déjà connu du serveur, ainsi que l’information cherchée qu’il sera ensuite nécessaire de calculer à partir du ou des résultats de l’évaluation du critère.

Lorsque l’information cherchée est la présence à l’identique d’un enregistrement dans la base (matching exact), toute fonction de compression applicable aux enregistrements peut être utilisée comme fonction de hashage pour réaliser l’étape S20.

Par exemple, dans un mode de mise en œuvre la fonction de hashage fournit en sortie un hash codé sur m bits.

Cette solution est également particulièrement intéressante dans le cas de données bruitées : le hash peut constituer un invariant qui sera invariant pour tous les enregistrements considérés comme identiques (par exemple, concernant la même personne si les données sont des données biométriques).

Pour mettre en œuvre l’étape S30, toute méthode d’interrogation privée de base de données (ou méthode ‘PIR’, de l’Anglais ‘Private Information Retrieval’) peut être choisie.

Dans certains modes de mise en œuvre, lorsque les hashs fournis par la fonction de hashage sont codés sur m bits, le vecteur d’identification de classe de collision comporte 2^mcomposantes ; chaque composante d’index i parmi lesdites 2^mcomposantes est un chiffré de 1 si l’index i est égal au hash de la classe de collision cherchée, ou un chiffré de 0 sinon ; et à l’étape S30, un chiffré V de la classe de collision est déterminé par l’équation :

avec . (E)

Pour que ce mode de mise en œuvre présente un réel intérêt, 2^mdoit être de préférence significativement plus petit que le nombre K d’éléments dans la base de données. De plus, pour qu’une classe de collision soit contenue dans une seule ligne, de préférence L est choisi de telle sorte que 2^mL est plus grand que le nombre d’enregistrements K (L désignant la taille des lignes dans la base de données). La méthode permet ainsi avantageusement de rendre le temps de traitement d’une requête proportionnel à 2^m(noté conventionnellement ‘O(2^m)’) opérations homomorphes – et non proportionnel au nombre K d’enregistrements de la base de données (noté O(K)) voire un multiple de K (soit O(Nk)) dans les approches traditionnelles, et par conséquent d’avoir des gains substantiels en matière de performance.

Le vecteur d’identification d’enregistrement contient les informations spécifiques relatives à l’information cherchée qui permettront au serveur d’extraire un chiffré de l’information cherchée.

A l’étape S50, le serveur évalue le critère pour le ou les chiffré(s) de la classe de collision cherchée. Puis, sur la base de ces évaluations, il détermine un chiffré de l’information cherchée.

L’information cherchée peut être une variable booléenne, ou une valeur fonction d’un ou plusieurs champs d’un enregistrement.

Dans le cas d’une variable booléenne, l’information cherchée peut être par exemple une indication de présence, indiquant si un enregistrement cherché est présent dans la base de données.

Naturellement, l’évaluation du critère, puis le calcul du chiffré de l’information cherchée doivent être des fonctions qui se décomposent en opérations élémentaires pouvant être réalisées de manière homomorphe. Des exemples de telles opérations homomorphes sont par exemple donnés dans le document Ref.2, section 3.2.

Le critère peut être notamment évalué à partir des contenus des différents champs d’un enregistrement. Le critère peut consister par exemple à identifier une (ou des) valeur(s) d’enregistrement qui minimise(nt) la valeur de sortie pour une certaine fonction, dite fonction d’évaluation. Dans ce cas la recherche de l’enregistrement qui satisfait le critère revient à une évaluation d’une fonction de type Argmin (ou Argmax). Un tel critère est généralement choisi lorsque la base de données contient des données bruitées, comme par exemple des profils biométriques.

Pour mettre en œuvre une méthode selon la présente divulgation, la base de données est de préférence structurée selon les classes de collision de la fonction de hashage.

Le serveur peut alors disposer avantageusement d’une fonction permettant d’accéder directement à la classe de collision correspondant à la valeur de hash considérée.

Selon le mode de mise en œuvre, lors de l’étape S30 le serveur peut déterminer pour une classe de collision soit un seul chiffré soit plusieurs chiffrés. Dans ce dernier cas le serveur peut par exemple calculer un chiffré par enregistrement de la classe de collision ; un tel chiffré est appelé ‘chiffré d’enregistrement’.

En ce qui concerne le chiffrement de la base de données, différentes solutions peuvent être choisies.

Dans certains modes de mise en œuvre, les enregistrements de la base de données sont chiffrés par une fonction de chiffrement d’un cryptosystème non homomorphe, notamment un cryptosystème symétrique.

Dans certains modes de mise en œuvre, les enregistrements de la base de données sont stockés en clair ou sous la forme de chiffrés non FHE ou sous la forme de hashs obtenus par une deuxième fonction de hashage à clef secrète.

Inversement, dans d’autres modes de mise en œuvre, les enregistrements de la base de données sont des chiffrés FHE.

Par ailleurs, différents cryptosystèmes peuvent être choisis pour la mise en œuvre de méthodes selon la présente divulgation. Dans tous les cas, pour assurer la sécurité des échanges d’informations, les fonctions de chiffrement utilisées sont des fonctions de chiffrement probabilistes, qui sont telles que les chiffrés de 0 et de 1 sont computationnellement indistinguables.

La méthode proposée peut être mise en œuvre avec un seul cryptosystème. Ainsi dans certains modes de mise en œuvre, les calculs homomorphes réalisés à l’étape S30 et à l’étape S50 sont réalisés à l’aide du même cryptosystème, notamment un cryptosystème TFHE.

Inversement, la méthode proposée peut être mise en œuvre avec plusieurs cryptosystème ; le but étant généralement d’utiliser pour chaque étape de calcul le cryptosystème le plus adapté pour cette étape.

L’étape S30 est alors normalement réalisée à l’aide d’un premier cryptosystème. Ce premier cryptosystème peut être utilisé (ou non) également pour tout ou partie de l’étape S50.

A l’étape S50, en complément ou à la place du premier cryptosystème, on peut ainsi utiliser un ou plusieurs cryptosystème(s) plus adapté(s) et/ou plus performant(s) que le premier cryptosystème pour les calculs à réaliser à l’étape S50, notamment le cas échéant pour tout ou partie des différentes étapes S52 et S54 indiquées précédemment.

Pour assurer la conversion d’un cryptosystème à un autre, dans certains modes de mise en œuvre la méthode comporte en outre une étape S40 dans laquelle le serveur recalcule le ou les chiffrés de la classe de collision cherchée en appliquant à celui-ci ou à ceux-ci une opération de transchiffrement.

Dans certains modes de mise en œuvre, la base de données est cryptée à l’aide d’un cryptosystème non homomorphe symétrique ; l’opération de transchiffrement sert alors à enlever de manière homomorphe la couche de chiffrement symétrique.

Dans certains de ces modes de mise en œuvre, une primitive symétrique de chiffrement par flux est utilisée, et des chiffrés FHE de la clef secrète/symétrique de la primitive de chiffrement par flux sont enregistrés sur le serveur.

Dans ce cas, les chiffrés homomorphes de clefs de flux peuvent être précalculés, et enregistrés dans une base ad hoc. Ils peuvent sinon être calculés en ligne, chaque fois que l’opération de transchiffrement doit être réalisée.

Ainsi dans certains cas, lorsque à l’étape S30 les chiffrés V sont calculés à l’aide de l’équation (E) indiquée précédemment, à l’étape S30, le serveur calcule les produits Ri * li sur une base de clefs de flux FHE en utilisant une primitive (ou algorithme) symétrique de chiffrement par flux ; et la méthode comporte en outre une étape S40 dans laquelle le serveur recalcule le ou les chiffrés de la classe de collision cherchée en appliquant à celui-ci ou à ceux-ci une opération de transchiffrement, cette opération de transchiffrement étant effectuée par une opération de OU exclusif de manière homomorphe entre le ou les chiffré(s) de la classe de collision cherchée et le chiffré FHE de la clef de flux correspondante.

Ci-dessus, l’expression « base de clefs de flux FHE » désigne une base de clefs dans laquelle les clefs de flux sont des chiffrés FHE.

Dans certains modes de mise en œuvre, à l’étape S50 le serveur détermine le chiffré de l’information cherchée en utilisant :

- un cryptosystème homomorphe à niveau (de l’Anglais : ‘levelled homomorphic encryption scheme’), notamment un cryptosystème de type BGV ; ou

- un cryptosystème de type SHE (de l’Anglais : ‘somewhat homomorphic encryption scheme’), notamment un cryptosystème de type BFV ou CKKS.

En effet dans ce dernier cas, les cryptosystèmes de type SHE avantageusement peuvent supporter un certain niveau de bruit. Ces cryptosystèmes SHE peuvent être par exemple des cryptosystèmes de type BFV (présentés par le document Ref.3), implémentés par exemple par la librairie SEAL (voir Ref.4).

Les cryptosystème de type BGV sont présentés notamment par la Ref.5. Ces cryptosystèmes avantageusement permettent le traitement par batch, c’est-à-dire la réalisation d’opérations élémentaires simultanément sur plusieurs enregistrements regroupés en un unique chiffré, donc en parallèle.

Dans certains modes de mise en œuvre dans lesquels à l’étape S50 le serveur (S) utilise un cryptosystème de type BFV, BGV ou CKKS, lors des calculs réalisés à l’étape S50 à l’aide de ce cryptosystème, une borne supérieure sur une profondeur multiplicative des calculs homomorphes est prise en compte.

Dans certains modes de mise en œuvre, l’étape S50 comprend les étapes S52 et S54 indiquées précédemment ; les calculs homomorphes réalisés à l’étape S30 et optionnellement à l’étape S521 sont réalisés à l’aide d’un même premier cryptosystème, notamment un cryptosystème BFV ou BGV ; et les calculs homomorphes réalisés aux étapes S522 et S54 sont réalisés à l’aide d’un même deuxième cryptosystème différent du premier cryptosystème, notamment un cryptosystème TFHE. Dans ce dernier cas, le choix d’un cryptosystème TFHE est généralement lié au fait que les cryptosystèmes TFHE peuvent être particulièrement bien adaptés à certains traitements non-linéaires.

Dans certains modes de mise en œuvre, l’identification du ou des chiffrés de la classe de collision qui satisfont le critère à l’étape S50 est faite chiffré de la classe de collision par chiffré de la classe de collision, chaque chiffré de la classe de collision correspondant à un enregistrement.

Les méthodes selon la présente divulgation peuvent être mises en œuvre pour rechercher des informations dans des bases de données comprenant aussi bien des données exactes que des données bruitées. Les données peuvent être enregistrées en clair ou chiffrées de différentes manières. Dans ce qui suit, le terme ‘chiffré’ est utilisé dans le même sens que ‘encodé’.

Dans certains modes de mise en œuvre, les enregistrements sont des images, ou sont obtenus à partir d’images, par exemple en utilisant un encodeur tel qu’un réseau de neurones ou autre.

Différents types d’encodeurs peuvent être utilisés pour stocker les données dans la base de données.

Par exemple, dans certains modes de mise en œuvre les enregistrements sont des hashs de structures de données bruitées. Ainsi par exemple, dans certains modes de mise en œuvre, les enregistrements correspondent à des profils biométriques. Un ‘profil biométrique’ désigne ici tout enregistrement dont au moins un des champs est une donnée bruitée relative à une personne humaine ou un animal.

BRÈVE DESCRIPTION DES FIGURES

D’autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description non limitative qui suit d’au moins un mode de réalisation particulier des dispositifs et procédés objets de la présente invention, en regard des dessins annexés, dans lesquels :

- laFIG. 1est une vue schématique d’un utilisateur et d’un serveur qui mettent en œuvre une méthode d’interrogation suivant la présente divulgation ; et

- laFIG. 2est un logigramme présentant les étapes d’un mode de mise en œuvre d’une méthode d’interrogation suivant la présente divulgation.

DESCRIPTION DÉTAILLÉE DE L’INVENTION

La présente divulgation concerne des méthodes d’interrogation confidentielle par un utilisateur d’une base de données hébergée par un serveur sur une base d’enregistrements chiffrés à l’aide de techniques de hachage, de PIR (produit scalaire homomorphe) et de FHE.

A titre d’exemples de réalisation non limitatifs, deux méthodes d’interrogation confidentielle d’une base de données selon la présente divulgation vont être décrites ci-après dans le contexte d’une architecture client-serveur illustrée par laFIG. 1.

Sur cette figure on a représenté un utilisateur U et un serveur S. Le serveur S héberge une base de données T, par exemple une base de données relationnelle.

L’utilisateur U est un ordinateur, par exemple un PC, à partir duquel on cherche à obtenir une information cherchée de manière confidentielle auprès de la base de données T.

L’utilisateur U comporte notamment un ou plusieurs processeurs P_U, et une mémoire M_U.

Le serveur S est par exemple un serveur de fournisseur de service d’informatique en nuage. Il comporte un ou plusieurs processeurs P_S, et une mémoire M_Sdans laquelle est enregistrée la base de données T.

La base de données T contient un grand nombre K de données individuelles X. Chaque donnée individuelle X peut présenter un ou plusieurs champs et est appelée ‘enregistrement’. Chaque enregistrement peut être en clair ou en chiffré. Il peut notamment être un chiffré obtenu par chiffrement à l’aide d’un cryptosystème symétrique.

Les enregistrements de la base de données peuvent être de toute nature (données textuelles (chaînes de caractères, CSV,..), images, fichiers audio ou video, etc.).

Les enregistrements peuvent être encodés (ou chiffrés) par un encodeur, par exemple de type réseau de neurones, avant stockage dans la base de données (voir l’encodeur NN indiqué sur laFIG. 1).

La première méthode suivant la présente divulgation qui va être présentée concerne un cas de matching de données exact.

Deux variantes de cette méthode vont être présentées ci-dessous.

Dans la première variante, le but d’une requête adressée par l’utilisateur à la base de données T est de savoir si un certain individu cherché ‘IC’, identifié par une chaîne de caractères unique (par exemple, son numéro de sécurité sociale), est enregistré dans la base de données.

Pour obtenir cette information de manière confidentielle, c’est-à-dire sans que la base de données n’ait aucune information quant à l’objet de la requête, une méthode selon la présente divulgation peut être mise en œuvre de la manière suivante.

On détermine préalablement une fonction de hashage h. Toute fonction de hashage peut être utilisée dès lors que, lorsque l’on cherche une certaine information concernant des enregistrement(s) de la base de données satisfaisant un critère, tous les enregistrements qui satisfont le critère génèrent le même hash.

Si le résultat de la fonction de hashage est un mot de m bits, on choisit m de préférence de telle sorte que 2^msoit petit devant le nombre K d’enregistrements dans la base de données.

La base de données T est alors structurée selon les classes de collision de la fonction de hashage h.

Les enregistrements de la base de données sont par exemple stockés sous forme d’un tableau (une table T), dans lequel chaque ligne correspond à une des valeurs de hash possibles. Ce tableau a donc 2^mlignes, certaines lignes pouvant éventuellement être vides, les autres comprenant un ou plusieurs enregistrement(s) X.

La fonction de hashage est choisie de manière diviser aussi efficacement que possible la base de données en classes de collision.

Dans la table T, chaque classe de collision est enregistrée sur une ligne.

Chaque classe de collision peut contenir entre 0 (zéro) et un nombre maximal prédéterminé M d’enregistrements : la table T présente 2^mlignes et M colonnes.

Le nombre M est de préférence nettement inférieur au nombre d’enregistrements K contenu dans la base de données elle-même, mais suffisant pour être dans tous les cas suffisant pour que le nombre d’enregistrements d’une classe de collision ne dépasse pas M.

Dans la première variante de la méthode présentée ici, l’information cherchée est simplement le fait qu’un Individu Cherché, noté ‘IC’, identifié par son numéro de sécurité sociale, soit référencé ou non par la base de données T. Dans ce cas, la clé d’identification d’enregistrement est le numéro de sécurité sociale NSS_IC de l’individu cherché.

La méthode est mise en œuvre de la manière suivante.

On choisit une fonction de hashage h qui prend en entrée un enregistrement complet X, et donne en sortie un hash h(X), ce hash étant calculé seulement sur la base des six premiers chiffres du numéro de sécurité sociale (le numéro de sécurité sociale étant un nombre comprenant treize chiffres).

En fonction de cette fonction de hashage, on structure alors la base de données en classes de collision CC : chaque classe de collision contient les enregistrements de personne dont le numéro de sécurité sociale contient les mêmes six premiers numéros. La base de données est donc divisée en 10⁶classes de collision.

Si le numéro de sécurité sociale de l’individu cherché commence par exemple par les chiffres 172057, le hash correspondant, h(172057), est le hash de la classe de collision cherchée.

A l’étape S30, on détermine les chiffrés de la classe de collision cherchée.

Ce sont des chiffrés d’enregistrement.

Pour cela, à l’étape S30 le serveur détermine le ou les chiffré(s) FHE de la classe de collision cherchée en effectuant de manière répétitive une même procédure de calcul : cette procédure de calcul est effectuée successivement pour chacune des M colonnes de la table T. On obtient donc en sortie M chiffrés. Si l’on suppose que la classe de collision cherchée contient N enregistrements avec N strictement inférieur à M, alors on obtient en sortie les N chiffrés d’enregistrement des N enregistrements de la classe de collision, suivis par M-N chiffrés ‘de rien’, c’est-à-dire des chiffrés ne correspondant à aucun enregistrement.

Le détail de la méthode utilisée à l’étape S30 sera fourni plus loin.

Puis à l’étape S50, pour chacun des chiffrés obtenus à l’étape S30, on évalue par calcul homomorphe si le critère applicable est satisfait.

Le critère applicable, en l’occurrence, défini en fonction de la clé d’identification d’enregistrement, s’écrit simplement (NSS = NSS_IC), NSS étant le numéro de sécurité sociale, qui est un des champs de chaque enregistrement.

Le résultat de l’évaluation du critère pour un enregistrement donné est donc un chiffré de 1, E(1), si le critère est satisfait (l’individu considéré a bien comme numéro de sécurité sociale le numéro de sécurité sociale NSS_IC de l’individu cherché), et un chiffré de 0, E(0), dans le cas contraire, E étant la fonction de chiffrement du cryptosystème FHE. Ce résultat est envoyé à l’utilisateur U (FIG. 1).

A l’étape S60, l’utilisateur U déchiffre le résultat et obtient l’information cherchée quant à la présence ou non dans la base de donnée d’un enregistrement dont le numéro de sécurité sociale correspond à celui de l’individu cherché.

Dans cet exemple, le critère choisi défini une correspondance exacte de l’enregistrement cherché (un ‘matching’ exact) par rapport à la clé d’identification d’enregistrement, et non une correspondance approchée (matching approché).

L’information cherchée est le chiffré obtenu en additionnant les chiffrés (E(0) ou E(1)) renvoyés lors de l’évaluation du critère successivement pour tous les chiffrés de la classe de collision. L’information renvoyée est donc un chiffré de 1 E(1) si l’individu cherché est enregistré dans la base, et un chiffré de 0 E(0) dans le cas contraire.

Conformément à la présente divulgation, l’évaluation du critère à satisfaire à partir de la clé d’identification d’enregistrement ainsi que le calcul de l’information cherchée se font dans l’espace des chiffrés, par des opérations homomorphes appliquées à des chiffrés des enregistrements. Le serveur n’a ainsi aucune information sur la signification des traitements qu’il réalise aux étapes S30 à S50.

Dans la deuxième variante de la méthode, l’information cherchée consiste en des informations complémentaires sur l’individu cherché IC. L’information cherchée peut alors être tout ou partie de l’enregistrement X_IC correspondant à l’individu cherché IC dans la base de données. L’information cherchée pourrait être le couple comprenant les valeurs ‘Adresse_IC’ et ‘Numéro de téléphone_IC’ donnant l’adresse et le numéro de téléphone de l’individu cherché IC.

Dans cette deuxième variante, l’étape S30 puis l’évaluation du critère à l’étape S52 sont identiques à la première variante. En revanche, l’étape S54 est différente, puisque dans ce deuxième cas, le chiffré de l’information cherché est plus complexe que dans le premier cas : il comprend un chiffré des valeurs ‘Adresse_IC’ et ‘Numéro de téléphone_IC’ de l’enregistrement de la base de données dont le champ ‘Numéro de Sécurité Sociale’ correspond à l’individu cherché IC.

Les étapes de la méthode vont maintenant être présentées de manière plus détaillée.

On suppose ici que le résultat de la fonction de hashage h est un mot de m bits.

Dans une première étape S10, l’utilisateur calcule d’abord la requête R à envoyer au serveur.

Cette requête R comprend deux éléments : le premier vecteur chiffré VIC d’identification de Classe de Collision, fonction du hash de la classe de collision cherchée, et le deuxième vecteur chiffré VIE d’Identification d’Enregistrement, fonction de la clé d’Identification d’Enregistrement. Ces deux éléments sont chiffrés par le même cryptosystème FHE.

Le premier vecteur VIC, qui comporte 2^mcomposantes Ri d’index i, où i varie de 0 à 2^m-1, est calculé à partir du hash de la classe de collision cherchée de la manière suivante : pour chaque valeur de i différente du hash de la classe de collision cherchée, la composante Ri d’index i est un chiffré de 0, E(0). Inversement, pour la valeur de i égale au hash de la classe de collision cherchée, la composante Ri est un chiffré de 1 (E(1)).

Le premier vecteur VIC d’identification de classe de collision se compose ainsi de 2^mchiffrés différents sans pour autant que le serveur ne soit en mesure de savoir lequel est un chiffré de 1.

Pour la mise en œuvre de la méthode selon la présente divulgation, on utilise un cryptosystème probabiliste qui admet une multitude de chiffrés de 0, une multitude de chiffrés de 1 et qui sont tels que les chiffrés de 0 et de 1 sont computationnellement indistinguables (par ‘multitude’, on désigne un très grand nombre, par exemple supérieur à 2¹²⁸, ou encore un nombre exponentiel en la taille de la clé).

Les caractéristiques du deuxième élément de la requête R, à savoir le vecteur d’identification d’enregistrement VIE, seront décrites plus loin.

Une fois la requête R calculée, l’utilisateur envoie celle-ci au serveur S.

Sur la base du vecteur d’identification de classe de collision VIC, par une méthode de récupération d’informations privées, à l’étape S30, le serveur détermine au moins un premier chiffré V de la classe de collision cherchée.

L’expression ‘au moins un premier chiffré V’ est utilisée ici car selon la structure de la base de données T et la méthode de récupération d’informations privées utilisée, la méthode peut renvoyer un ou plusieurs premiers chiffrés V. L’important est que ce ou ces chiffrés représentent l’ensemble de la classe de collision.

Par exemple, dans certains cas un seul chiffré peut être renvoyé : ce chiffré représente alors le plus souvent un ensemble de plusieurs enregistrements. Dans d’autres cas, la méthode de récupération d’informations privées peut renvoyer un chiffré par enregistrement de la classe de collision.

Inversement, dans l’exemple présenté précédemment, un nombre M prédéterminé (borné) de chiffrés d’enregistrements est renvoyé (l’expression ‘chiffré d’enregistrement’ désignant un chiffré correspondant à un enregistrement donné).

Toute méthode de récupération d’informations privées (méthode PIR) peut être utilisée pour réaliser l’étape S30.

Dans l’exemple présenté ici, à réception de la requête R, à l’étape S30, le serveur détermine le chiffré V de la classe de collision comprenant les enregistrements susceptibles de fournir la ou les informations cherchée(s) en procédant aux opérations suivantes :

Dans une première étape S32, ayant reçu la requête R de l’utilisateur, pour chaque valeur de hash possible (chaque valeur d’index i, i variant de 0 à 2^m-1), le serveur calcule un chiffré de classe Vi qui est le produit de la composante Ri par la classe de collision li associée à la valeur d’index considérée.

Dans une deuxième étape S34, le serveur calcule alors le chiffré V qui est égale à la somme sur l’ensemble des valeurs i d’index possibles (lorsque i varie de 0 à 2^m-1) de tous les chiffrés de classe Vi :

A l’issue de l’étape S34, on obtient donc le premier chiffré V. Celui-ci est un chiffré de la classe de collision correspondant au hash de la classe de collision cherchée. Si un ou plusieurs enregistrements de la base de données T contiennent l’information cherchée, ce ou ces enregistrements se trouvent nécessairement dans cette classe de collision.

Pour permettre la réalisation de la deuxième phase de la méthode (l’étape S50), la requête contient en outre le vecteur d’identification d’enregistrement VIE. Celui-ci contient l’information complémentaire permettant au serveur d’identifier (sans le savoir) les enregistrements satisfaisant le critère et ainsi in fine de fournir un chiffré de l’information cherchée.

Dans l’exemple présenté ici, le vecteur d’identification d’enregistrement VIE est simplement constitué par un chiffré du numéro de sécurité sociale complet de l’individu cherché IC. A l’étape S20, ce deuxième vecteur intégré à la requête R est envoyé au serveur S.

Dans certains modes de mise en œuvre, le cryptosystème FHE utilisé à l’étape S50 est différent de celui utilisé à l’étape S30 : une opération de transchiffrement est alors nécessaire. Dans ce cas, la méthode comprend alors l’étape S40 suivante :

S40) le serveur applique une opération de transchiffrement au(x) chiffré(s) de la classe de collision, de manière à obtenir un ou des chiffrés qui sont chiffrés avec le cryptosystème prévu pour l’étape S50.

Ensuite, à l’étape S50 le serveur évalue si le critère est satisfait pour chacun du ou des chiffrés de la classe de collision déterminés à l’étape S30 (éventuellement transchiffrés à l’étape S40). Sur la base de cette ou ces évaluations, le serveur calcule alors un chiffré de l’information cherchée. Ce chiffré est alors envoyé à l’utilisateur.

Dans l’exemple présenté ici, l’étape S50 comporte d’abord l’étape d’évaluation de critère S52.

Durant cette étape, le serveur évalue le critère pour chacun des chiffrés de la classe de collision cherchée. Pour cela, pour chaque chiffré de la classe de collision, le serveur calcule une différence entre le numéro de sécurité sociale du chiffré considéré de la classe de collision et un chiffré du numéro de sécurité sociale de l’individu cherché. Si cette différence est un chiffré de ‘1’, cela signifie que le critère est satisfait, c’est-à-dire que l’enregistrement considéré de la classe de collision est effectivement un enregistrement comportant le même numéro de sécurité sociale que celui de l’individu cherché.

A l’étape S54, le serveur calcule donc le chiffré de l’information cherchée et le transmet à l’utilisateur. Ce chiffré est obtenu en faisant simplement la somme des chiffrés obtenus pour tous les chiffrés de la classe de collision.

Avantageusement, l’étape S50 est réalisée par le serveur, uniquement à partir de chiffrés, grâce au fait que toutes les opérations peuvent être réalisées entre chiffrés FHE.

Cela permet que les différents calculs nécessaires à l’étape S50 pour déterminer le chiffré de l’information cherchée en fonction de résultat(s) d’une évaluation du critère pour le ou les chiffré(s) de la classe de collision soient effectués à partir de chiffrés. Par suite, au lieu d’obtenir l’information cherchée à partir de la liste d’enregistrements, on obtient à l’étape S50 un chiffré de l’information cherchée, à partir de chiffrés des enregistrements.

On peut se reporter à la section 3, et notamment à la section 3.2 du document Ref.2 pour voir comment, grâce à un cryptosystème FHE, des opérations normalement réalisées dans l’espace des clairs sont remplacées par des opérations dites ‘homomorphes’ effectuées dans l’espace des chiffrés.

Avantageusement, ces opérations, étant effectuées sur des chiffrés par le serveur, permettent d’obtenir le chiffré des informations cherchées en sollicitant uniquement le serveur, mais sans communiquer à celui-ci la moindre information en clair à propos de l’objet (de la personne) cherché.

Dans certains cas, selon le type d’information cherchée et la base de donnée considérée, plusieurs enregistrements peuvent satisfaire le critère.

Dans ce cas, pour éviter de transmettre une information à propos de l’information cherchée, de préférence une borne supérieure du nombre d’enregistrements qui seront considérés comme satisfaisant le critère est fixée à l’avance : on choisit par exemple un nombre N comme étant cette borne supérieure.

Ainsi lors de l’étape S50, le serveur évalue successivement N fois pour l’ensemble des enregistrements si le critère est satisfait. A partir des N résultats d’évaluation du fait que le critère soit satisfait ou non, le serveur calcule alors le chiffré de l’information cherchée, et le transmet à l’utilisateur.

Enfin, à l’étape S60, à réception du chiffré de l’information cherchée envoyé par le serveur S, l’utilisateur déchiffre ce chiffré et ainsi obtient l’information cherchée.

Avantageusement, les opérations S30 et S50 sont réalisées par le serveur stockant la base de données ; elles ne nécessitent donc pas que l’utilisateur dispose de puissance de calcul ou de capacités de stockage.

De plus, la classe de collision cherchée n’est pas divulguée au serveur (seul les chiffrés de la classe de collision sont connus du serveur).

La deuxième méthode selon la présente divulgation va maintenant être présentée.

Dans cette deuxième méthode, la base de données T contient des données bruitées, par exemple des images, des enregistrements sonores, des enregistrements biométriques, etc.

L’utilisateur veut trouver le ou les enregistrements les plus ressemblants à, les plus proches, d’un enregistrement de référence X0.

Le résultat d’une telle recherche peut être fourni par une fonction d’évaluation de type argmin/argmax, c’est-à-dire une fonction qui détermine la valeur (l’enregistrement) qui maximise ou minimise une fonction de coût parmi un ensemble de valeurs possibles – parmi les enregistrements de la base de données.

L’approche traditionnelle pour réaliser une telle recherche consisterait à calculer toutes les distances entre l’enregistrement de référence X0 et les différents enregistrements, puis à calculer le minimum ou le maximum : Une telle approche est connue mais est difficilement applicable si la base de données comporte un nombre élevé d’enregistrements.

Selon la présente divulgation, il est préférable au contraire d’organiser préalablement la base de données T en classes de localisation/collision. Chaque classe contient plusieurs enregistrements (avec de préférence un nombre maximum d’enregistrements par classe de collision). La première étape S30, de pré-processing, est réalisée dans l’espace des chiffrés, en utilisant un premier cryptosystème FHE.

Dans un mode de mise en œuvre, par exemple, l’utilisateur U essaie de déterminer si un enregistrement correspondant à une personne particulière, caractérisée par son profil biométrique, est présent dans la base de données T.

Ce profil biométrique peut être par exemple une donnée encodée, calculée à partir de certaines données relatives à la personne. Le profil biométrique dans le cas présent est obtenu à partir de photos des yeux de la personne, par un encodage approprié (réalisé par exemple par un réseau de neurones ou autre).

Dans ce cas, la requête R transmise par l’utilisateur va viser à obtenir le ou les enregistrements de personnes, enregistrées dans la base de données, et dont les profils biométriques sont les plus proches du profil biométrique de la personne cherchée par rapport à un seuil de proximité prédéterminé. Cette condition de proximité entre un profil biométrique et le profil biométrique de la personne cherchée constitue donc le critère qui doit être satisfait au sens de la présente divulgation. L’utilisateur U dispose bien évidemment du profil biométrique de la personne cherchée.

Pour calculer la requête R, on choisit préalablement la fonction de hachage, parmi les fonctions de hachage applicables à des données bruitées. On choisit une fonction de hashage qui donne le même hash pour des profils biométriques qui diffèrent seulement les uns des autres d’une valeur inférieure au seuil de proximité prédéterminé.

Dans l’exemple présenté ici, on choisit une fonction de hashage qui renvoie en sortie un hash représentatif de la couleur des yeux de la personne considérée. Les hashs sont codés sur 128 valeurs. Ainsi, la fonction de hashage permet de classer les enregistrements en 128 classes de collision correspondant à 128 encodages des différentes couleurs d’yeux possibles.

A l’étape S10, l’utilisateur détermine le hash de la classe de collision cherchée, qui correspond à la couleur des yeux de l’individu cherché.

A l’étape S20, l’utilisateur calcule la requête correspondante : celle-ci comprend un vecteur VIC d’identification de classe de collision, chiffré, qui est fonction du hash de la classe de collision cherchée, ainsi qu’un vecteur chiffré d’identification d’enregistrement VIE, qui est un chiffré de la couleur des yeux de la personne cherchée. Il envoie la requête R au serveur.

A l’étape S30 le serveur détermine les chiffrés FHE de la classe de collision cherchée, qui représentent la classe de collision du hash de la classe de collision cherchée.

A l’étape S50, dans l’espace des chiffrés, le serveur évalue par calcul homomorphe le critère d’évaluation pour chacun des chiffrés de la classe de collision cherchée. Le serveur détermine – sans le savoir – par opérations homomorphes entre les chiffrés de la classe de collision, l’enregistrement de la classe de collision dont le profil biométrique (la couleur des yeux) est à la distance plus faible du profil biométrique (de la couleur des yeux) de la personne cherchée.

Dans un autre mode de mise en œuvre, à l’étape S50 le serveur peut être configuré pour identifier les N (par exemple, les 5) enregistrements dont le profil biométrique (la couleur des yeux) est le plus proche du profil biométrique (de la couleur des yeux) de la personne cherchée.

Ces différentes opérations sont effectuées par des opérations élémentaires homomorphes, sur la base uniquement des chiffrés des profils biométriques considérés.

Lorsque les opérations ci-dessus ont été réalisées pour tous les chiffrés de la classe de collision cherchée, le serveur S renvoie les N chiffrés identifiés à l’utilisateur.

A l’étape S60, l’utilisateur déchiffre chaque chiffré de la liste des chiffrés d’enregistrements de personnes détectées et ainsi, obtient l’ensemble des enregistrements de personnes cherché.

Différentes possibilités de chiffrement pour la base de données

Les méthodes selon la présente divulgation peuvent être mises en œuvre de différentes manières en ce qui concerne le chiffrement de la base de données.

Dans un premier cas, les enregistrements de la base de données ne sont pas obtenus par un chiffrement FHE (c’est-à-dire, ce ne sont pas des chiffrés FHE, c’est-à-dire des chiffrés obtenus par la fonction de chiffrement d’un cryptosystème FHE). Cela ne signifie pas pour autant bien sûr que les enregistrements ne sont pas chiffrés ou encodés.

Ainsi par exemple, la base de données peut être une base de données secondaire, constituée par les hashs d’enregistrements initiaux qui sont stockés en clair dans une base de données primaire, ces hashs étant obtenus à l’aide d’une fonction de hachage initiale à clef secrète.

Il suffit en effet alors de consulter la base de données secondaire contenant les hashs des enregistrements initiaux par exemple lorsque l’on cherche seulement à évaluer la présence d’un ou plusieurs enregistrements spécifiques dans la base de données.

La fonction de hashage utilisée pour structurer la base de données secondaires en classes de collision peut alors être la fonction qui renvoie en sortie les m premiers bits du hash obtenu par la fonction de hashage initiale.

Dans ce premier cas, à l’étape S32 indiquée précédemment, les multiplications homomorphes réalisées sont des multiplications entre un clair et un chiffré. Ce mode de mise en œuvre permet donc un niveau de performances élevé (en termes de puissance de calcul requise), les multiplications clair/chiffré étant généralement moins couteuses en temps de calcul que les multiplications chiffré/chiffré. A la fin de l’étape S32 de produit scalaire on récupère donc un chiffré FHE de la classe de collision.

Dans un deuxième cas, les enregistrements de la base de données sont obtenus par un chiffrement FHE, ce qui préserve naturellement la confidentialité des données stockées.

Dans ce deuxième cas, à l’étape S32 les multiplications homomorphes réalisées sont des multiplications entre un chiffré et un chiffré, avec néanmoins un coût de profondeur multiplicative de seulement 1. A la fin des étapes S32 et S34 de calcul des produits scalaires et de sommation, comme dans le cas précédent, le serveur obtient un chiffré FHE de la classe de collision sur lequel il pourra pouvoir poursuivre les traitements à l’étape S50.

Dans un troisième cas, la base de données est chiffrée à l’aide d’un cryptosystème non homomorphe, de manière avantageuse un cryptosystème symétrique.

Dans ce cas, à l’étape S32 les multiplications homomorphes réalisées sont des multiplications entre un chiffré symétrique, qui est un chiffré non-FHE, et un chiffré FHE. Ces multiplications sont donc le plus souvent plus simples que des multiplications chiffré FHE-chiffré FHE.

Cependant, à l’issue de l’étape S34 on récupère donc un chiffré FHE d’un chiffré symétrique de la classe de collision.

Afin de pouvoir poursuivre les traitements, le serveur va donc devoir transchiffrer, c’est-à-dire enlever de manière homomorphe la couche de chiffrement symétrique. Toutefois, comme la classe de collision est de relativement petite taille cela n’est pas prohibitif sur le plan performances. De plus, cela ne nécessite pas de passer par une étape intermédiaire de déchiffrement dans l’espace des clairs. Ainsi malgré cette opération de transchiffrement, du fait de la taille réduite de la classe de collision, le temps de calcul engendré par l’opération de transchiffrement est généralement relativement limité et donc acceptable.

Pour réduire ce temps de calcul, dans certains modes de mise en œuvre on calcule à l’avance un flux de clés de chiffrement (ou ‘keystreams’) utilisées pour le cryptosystème FHE utilisé.

L’opération S30 est alors réalisée en prenant en compte ce flux de clefs de chiffrement. Elle fournit le premier chiffré de la classe de collision correspondant au hash caractéristique, mais chiffré à l’aide du premier cryptosystème, qui est symétrique et non FHE.

A l’issue de l’opération S30, il est donc nécessaire de procéder pendant l’opération S40 à une opération de transchiffrement, afin de disposer du deuxième chiffré V2 de la classe de collision, chiffré par un cryptosystème FHE. Avantageusement, ce transchiffrement peut être réalisé de manière très simple, à savoir en effectuant simplement une opération de XOR homomorphe entre le chiffré HE de la classe de collision et le chiffré HE du flux de chiffrement.

L’opération de transchiffrement fournit le ou les chiffré(s) de la classe de collision pour le cryptosystème FHE. La fin de la procédure peut alors être réalisée en réalisant les étapes S50 et S60 présentées précédemment.

Claims

Méthode d’interrogation confidentielle par un utilisateur (U) d’une base de données (DB) comprenant des enregistrements (Xi) et hébergée par un serveur (S) pour obtenir une information cherchée relative à un ou plusieurs enregistrement(s) de la base de données satisfaisant un critère, le critère étant fonction d’une clé d’identification d’enregistrement, la clé d’identification d’enregistrement étant un vecteur de valeur(s) d’un ou plusieurs champs d’un enregistrement ;
une fonction (h) de hashage étant définie de telle sorte que, pour un critère donné, tous les enregistrements qui satisfont le critère génèrent le même hash ;
un ensemble des enregistrements ayant un même hash étant appelé classe de collision (li) ;
la méthode comportant les étapes suivantes pour obtenir une information cherchée, fonction d’une clé d’identification d’enregistrement :
S10) l’utilisateur détermine un hash, dit hash de la classe de collision cherchée, commun à tous les enregistrements satisfaisant le critère défini en fonction de la clé d’identification d’enregistrement ;
S20) l’utilisateur calcule une requête (R) comprenant un vecteur (VIC) d’identification de classe de collision, chiffré, fonction du hash de la classe de collision cherchée, ainsi qu’un vecteur (VIE) d’identification d’enregistrement, chiffré, fonction de la clé d’identification d’enregistrement, et envoie la requête (R) au serveur ;
S30) sur la base du vecteur d’identification de classe de collision (VIC), par une méthode de récupération d’informations privées le serveur détermine un ou des chiffré(s) FHE de la classe de collision cherchée (V), représentant la classe de collision du hash de la classe de collision cherchée ;
S50) à partir du vecteur d’identification d’enregistrement (VIE), le serveur détermine par calcul homomorphe un chiffré de l’information cherchée en fonction de résultat(s) d’une évaluation du critère pour le ou les chiffré(s) de la classe de collision cherchée, et transmet le chiffré de l’information cherchée à l’utilisateur ; et
S60) l’utilisateur déchiffre alors le chiffré de l’information cherchée et obtient ainsi l’information cherchée.
Méthode d’interrogation selon la revendication 1, dans laquelle la fonction de hashage (h) fournit en sortie un hash codé sur m bits.
Méthode d’interrogation selon la revendication 2, dans laquelle
le vecteur (VIC) d’identification de classe de collision comporte 2^mcomposantes (Ri) ;
chaque composante (Ri) d’index i parmi lesdites 2^mcomposantes est un chiffré de 1 (E(1)) si l’index i est égal au hash de la classe de collision cherchée, ou un chiffré de 0 (E(0)) sinon ; et
à l’étape S30, un chiffré V de la classe de collision cherchée est déterminé par l’équation :
avec
Méthode d’interrogation selon l’une quelconque des revendications 1 à 3, dans laquelle les enregistrements de la base de données sont chiffrés par une fonction de chiffrement d’un cryptosystème non homomorphe, notamment un cryptosystème symétrique.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 3, dans laquelle les enregistrements de la base de données sont stockés en clair ou sous la forme de chiffrés non FHE ou sous la forme de hashs obtenus par une deuxième fonction de hashage à clef secrète.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 3, dans laquelle les enregistrements de la base de données sont des chiffrés FHE.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 6, dans laquelle les calculs homomorphes réalisés à l’étape S30 et à l’étape S50 sont réalisés à l’aide du même cryptosystème, notamment un cryptosystème TFHE.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 6, dans laquelle la méthode comporte en outre une étape S40 dans laquelle le serveur recalcule le ou les chiffrés de la classe de collision cherchée en appliquant à celui-ci ou à ceux-ci une opération de transchiffrement.
Méthode d’interrogation selon les revendications 3, 4 et 8, dans laquelle :
à l’étape S30, le serveur calcule les produits Ri * li sur une base de clefs de flux FHE en utilisant une primitive symétrique de chiffrement par flux ; et la méthode comporte en outre une étape S40 dans laquelle le serveur recalcule le ou les chiffrés de la classe de collision cherchée en appliquant à celui-ci ou à ceux-ci une opération de transchiffrement, cette opération de transchiffrement étant effectuée par une opération de OU exclusif de manière homomorphe entre le ou les chiffré(s) de la classe de collision cherchée (V) et le chiffré FHE de la clef de flux correspondante.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 9, dans laquelle à l’étape S50, le serveur détermine le chiffré de l’information cherchée en utilisant :
- un cryptosystème homomorphe à niveau, notamment un cryptosystème de type BGV ; ou
- un cryptosystème de type SHE, notamment un cryptosystème de type BFV ou CKKS.
Méthode d’interrogation selon la revendication 10, dans le cas où à l’étape S50 le serveur (S) utilise un cryptosystème de type BFV, BGV ou CKKS, dans laquelle lors des calculs réalisés à l’étape S50 à l’aide de ce cryptosystème, une borne supérieure sur une profondeur multiplicative des calculs homomorphes est prise en compte.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 9, dans laquelle
à l’étape S50, le serveur les étapes S52 et S54 suivantes :
S52) le serveur évalue le critère pour le ou les chiffré(s) de la classe de collision cherchée en effectuant les opérations suivantes :
S521) le serveur effectue un calcul de distance ; et
S522) le serveur compare un ou des résultats obtenu(s) à l’étape S521 à un seuil ; puis
S54) le serveur calcule le chiffré de l’information cherchée ;
les calculs homomorphes réalisés à l’étape S30 et optionnellement à l'étape S522 sont réalisés à l’aide d’un même premier cryptosystème, notamment un cryptosystème BFV ou BGV ; et
les calculs homomorphes réalisés aux étapes S524 et S54 sont réalisés à l’aide d’un même deuxième cryptosystème différent du premier cryptosystème, notamment un cryptosystème TFHE.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 12, dans laquelle l’identification du ou des chiffrés de la classe de collision qui satisfont le critère à l’étape S50 est faite chiffré de la classe de collision par chiffré de la classe de collision, chaque chiffré de la classe de collision correspondant à un enregistrement.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 13, dans laquelle les enregistrements sont des images, ou sont obtenus à partir d’images, par exemple en utilisant un encodeur (E), notamment un réseau de neurones.
Méthode d’interrogation selon l’une quelconque des revendications 1 à 13, dans laquelle les enregistrements sont des hashs de structures de données bruitées.