Brevet FR3054905A1 — publié le 20180209

Procédé de génération de clé et procédé de contrôle d'accès DOMAINE TECHNIQUE GENERAL L'invention concerne le domaine de l'authentification d'un client auprès d'un serveur, par le biais d'informations biométriques, pour le contrôle d'accès du client à une ressource du serveur. L'invention vise notamment la protection des données de références biométriques. A cette fin, l'invention concerne aussi la génération de clé cryptographique pour ladite authentification pour un contrôle d'accès. Le client à identifier est associé à un dispositif physique, tel qu'un téléphone mobile, une tablette numérique, un ordinateur personnel. On parlera plus généralement de terminal-client. Dans le cas de la biométrie, le terminal-client comprend des moyens d'acquisition de données biométriques (détecteur, caméra, clé USB avec capteur, capteur d'image avec module d'extraction et solution logicielle, etc.). Il est important que la donnée biométrique de référence, par exemple une empreinte digitale, un iris d'oeil, etc. ne soit pas stockée en clair au niveau du client, c'est-à-dire en local. Pour ce faire, des techniques de cryptage connues sous le nom de cryptage biométrique (BE pour Biometric Encryption) sont mises en oeuvre. Nous nous référons au document [CRYBIO] qui décrit plus en détails ces aspects (les références sont données à la fin de la description). En revanche, la donnée biométrique de référence ne doit pas non plus être transmise au serveur pour l'authentification. Cette dernière condition impose que la comparaison de la donnée biométrique acquise et de la donnée biométrique de référence soit effectuée en local. A cause du bruit (griffures, temps, déformations, etc.), les mesures biométriques de référence et les mesures test sont différentes 3054905 2 pour un même utilisateur. Cela dégrade les performances des systèmes de vérifications biométriques. Pour mesurer ces performances, deux taux d'erreurs sont communément utilisées. Le FAR (False Acceptance Rate) est la probabilité qu'un utilisateur 5 illégitime soit faussement accepté comme légitime. Le FFR (False Rejection Rate) qui est la probabilité qu'un utilisateur légitime soit faussement rejeté. ETAT DE L'ART 10 Lorsqu'un utilisateur souhaite pouvoir authentifier son terminal-client auprès d'un serveur pour accéder à une ressource du serveur, une donnée biométrique test est acquise puis est comparée à la donnée biométrique de référence. Si ces deux données sont suffisamment 15 proches, une clé cryptographique est déverrouillée, qui permet l'authentification auprès du serveur. Aucune information biométrique n'est ainsi transmise au serveur. Dans les méthodes de cryptage biométrique, la donnée biométrique de référence est masquée dans le terminal-client à l'aide 20 d'un aléa et/ou de la clé cryptographique. On parle généralement de key-binding. On peut citer des algorithmes de secure sketches par exemple. En particulier, dans le cadre de la norme FIDO, une authentification biométrique locale est réussie lorsqu'elle est suivie d'une 25 authentification cryptographique classique auprès d'un serveur. En revanche, à cause du FAR et comme le serveur n'authentifie le client que lorsque la clé est déverrouillée, des attaques en force brute sont possibles : une pluralité de données simulant des données biométriques sont testées en local, jusqu'à ce qu'une clé soit 30 déverrouillée. Le document [WEAK] décrit les faiblesses des systèmes actuels. Ces attaques ont pour objectif soit d'accéder aux informations du serveur, soit d'obtenir de l'information relative à la donnée biométrique 3054905 3 de référence, soit encore d'obtenir la clé cryptographique associée. En effet, si l'authentification est autorisée, cela signifie que la donnée biométrique testée est proche de la donnée biométrique de référence. Il est capital de pouvoir se prémunir contre ce type d'attaque. 5 Dans le cadre de l'invention, on considère que l'attaquant n'a pas accès aux détails des calculs qui sont exécutés dans le terminal-client. En revanche, il peut observer ce terminal à distance. De la sorte, les attaques par acquisition de données via une sonde magnétique à 10 proximité du terminal-client, comme décrite dans la référence [PROBE] ne sont pas visées. PRESENTATION DE L'INVENTION 15 L'invention concerne un procédé de génération de clé cryptographique pour authentification d'un terminal-client auprès d'un serveur afin d'effectuer un contrôle d'accès. Selon un aspect de l'invention, le procédé de génération d'une clé cryptographique pour la mise en oeuvre d'un procédé de contrôle d'accès 20 à une ressource d'un serveur par un terminal-client, le procédé étant mis en oeuvre par le terminal-client, ledit terminal étant configuré pour communiquer avec le serveur, le terminal-client comprenant une mémoire dans laquelle est stockée une donnée de référence obtenue par l'application d'un procédé d'encodage à une donnée biométrique de 25 référence et une clé cryptographique légitime permettant d'authentifier le terminal-client auprès du serveur lors d'un contrôle d'accès, comprend les étapes suivantes: - (El) réception d'une donnée biométrique test, - (E2) application d'un procédé de décodage à la donnée biométrique 30 test et la donnée de référence pour obtenir une clé cryptographique telle que : 3054905 4 si la donnée biométrique test correspond à la donnée biométrique de référence, la clé cryptographique générée est la clé d'authentification cryptographique légitime, sinon, la clé cryptographique générée est une clé 5 d'authentification cryptographique illégitime ne permettant pas l'authentification du terminal-client auprès du serveur lors d'un contrôle d'accès, et - (E3) utilisation de la clé générée pour la mise en oeuvre d'un procédé de contrôle d'accès (F3) à une ressource du serveur par le terminal 10 client. Dans un mode de réalisation, le procédé comprend en outre une étape préliminaire (EO) de génération de la donnée biométrique test, soit par acquisition à l'aide de moyens d'acquisition de donnée 15 biométrique, soit par génération numérique. Dans un mode réalisation, le procédé d'encodage est du type « secure sketch », tel qu'un Fuzzy Commitment Scheme, ou du type He/per Data System, ou du type Fuzzy Vault par exemple avec des codes de Reed-Solomon. 20 Dans un mode de réalisation : l'étape de génération (E2) de la clé cryptographique comprend la mise en oeuvre d'un procédé de décodage d'erreur. Dans un mode de réalisation, le procédé de décodage d'erreur est un procédé de décodage souple, de préférence avec un nombre limité 25 d'itération, par exemple par un nombre limite ou par un critère de qualité d'arrêt. Dans un mode de réalisation, la clé cryptographique légitime présente un format adapté pour l'utilisation de la clé dans un protocole de contrôle d'accès par authentification mis en oeuvre entre le terminal- 30 client et un serveur, et le procédé de décodage est adapté pour que la clé cryptographique illégitime ait le format de la clé cryptographique légitime. 3054905 5 Dans un mode de réalisation, le procédé de décodage et le procédé d'encodage comprennent des étapes de chiffrement et déchiffrement mielleux (honey encryption). Dans un mode de réalisation, le procédé d'encodage est mis en 5 oeuvre sur une pluralité de clés légitimes concaténées, les clés légitimes permettant d'authentifier le terminal-client auprès de plusieurs serveurs et/ou ressources respectifs lors d'un contrôle d'accès, et dans lequel le procédé de décodage permet l'obtention d'une clé générée concaténée comprenant une pluralité de clés générées concaténée entre elles, le 10 procédé comprenant avantageusement une étape de sélection d'une des clés générées parmi la pluralité des clés générées pour son utilisation dans un procédé de contrôle d'accès au serveur et/ou une ressource associé à la clé légitime qui a permis la génération de ladite clé générée. Dans un mode de réalisation, la correspondance entre les deux 15 données biométriques signifie que la distance entre les deux données biométriques est inférieure à un seuil donné. Les modes de réalisation peuvent être combinés, en fonction de la faisabilité technique. 20 L'invention concerne aussi un procédé de contrôle d'accès d'un terminal client à une ressource d'un serveur, à partir du procédé de génération de clé précédent. Selon un aspect de l'invention, le procédé de contrôle d'accès d'un terminal-client à une ressource d'un serveur, comprend les étapes 25 suivantes : - (F1) mise en oeuvre d'un procédé de génération d'une clé cryptographique tel que décrit précédemment, - (F2) réception par le serveur de la clé ou de données dépendantes de la clé, 30 - (F3) analyse de la clé ou desdites données dépendantes de la clé par le serveur : si la clé est une clé légitime, authentification du terminal-client auprès du serveur et accès du terminal client à la ressource du serveur, 3054905 6 si la clé est une clé illégitime, échec de l'authentification du terminal-client auprès du serveur et mise en oeuvre d'un procédé (F4) d'alerte indiquant que la donnée biométrique de test ne correspond pas à la donnée biométrique de référence. 5 Dans un mode de réalisation, le procédé d'alerte (F5) comprend au moins une des étapes suivantes : - stockage du nombre d'itérations de réceptions de clés illégitimes, et/ou - envoi d'une consigne de verrouillage du terminal-client, et/ou 10 - authentification biaisée du terminal-client auprès du serveur, de façon à pouvoir surveiller ledit terminal-client, et/ou - destruction des données stockées sur le terminal-client et/ou sur le serveur, et/ou, - envoi au terminal-client d'une consigne de ré-acquisition de données 15 biométriques test. Dans un mode de réalisation, le procédé comprend la mise en oeuvre d'un protocole de preuve de connaissance à divulgation nulle de connaissance. Dans un mode de réalisation, les échanges entre le terminal-client 20 et le serveur comprennent la mise en oeuvre d'une signature électronique, tel que FIDO ou ECDSA ou encore RSA. Dans un mode de réalisation, le procédé met en oeuvre une mise en gage selon Pedersen comprenant une phrase d'enrôlement dans laquelle 25 le terminal-client stocke une grandeur aléatoire r, le terminal-client génère une mise en gage MG sous la forme MG (r, KI) = gKI, n et l'envoie au serveur qui la stocke, où KI est la clé légitime, et g et h sont tels que logg(h) n'est pas connu, et comprenant une phase de dévoilement, dans laquelle, préalablement 30 à l'étape de transmission de la clé (E3), les sous-étape suivantes sont mises en oeuvre : le terminal-client envoie au serveur : Al A2 = gai. ha2 3054905 7 le serveur génère et envoie un aléa c au terminal-client, le terminal-client calcule yi = a1 + K'. c et y2 = a2 + r. c où K' est la clé cryptographique générée par le procédé de décodage (E2, F1) et al et az sont des valeurs aléatoires, 5 l'étape de transmission (E3) comprend l'envoi de yi et y2 au serveur, l'étape d'analyse de la clé (F3) comprend la vérification suivante : e1h312 = MGc iliA2 Les modes de réalisation peuvent être combinés, en fonction de la faisabilité technique. 10 L'invention concerne aussi une unité de calcul pouvant mettre en oeuvre les procédés de génération décrits précédemment ou une partie des procédés de contrôle d'accès décrits précédemment. Ladite unité de calcul comprend une mémoire, un calculateur et une interface de 15 communication avec un serveur. L'unité de calcul peut être un dispositif personnel à un individu, de type téléphonie mobile, tablette numérique ou encore ordinateur personnel. L'invention concerne aussi des produit-programmes d'ordinateur comprenant des instructions pour mettre un oeuvre le procédé de 20 génération précédent et/ou tout ou partie des procédés de contrôle d'accès précédents. Les produits-programmes d'ordinateur comprennent donc des instructions pour le terminal et/ou pour le serveur. PRESENTATION DES FIGURES 25 D'autres caractéristiques, buts et avantages de l'invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés, sur lesquels : - la figure 1 illustre un système pour authentification d'un terminal-client 30 auprès d'un serveur, - la figure 2 illustre le fonctionnement général de l'invention, 3054905 8 - la figure 3 illustre un mode de réalisation particulier de secure sketch, avec un fuzzy commitment scheme, - la figure 4 illustre différentes étapes d'un mode de réalisation avec une mise en gage de Pedersen. 5 DESCRIPTION DETAILLEE En référence à la figure 1, on a représenté un système permettant d'authentifier un client, représenté sous la forme d'un 10 terminal-client 10, auprès d'un serveur 20 pour un contrôle d'accès une ressource du serveur. Par ressource, on entend des données, des applications ou encore des services du serveur 20. Le terminal-client 10 appartient à un utilisateur dit légitime. 15 Le terminal-client 10 et le serveur 20 peuvent communiquer entre eux soit directement, par exemple par signal radiofréquence, soit par le biais d'un réseau 30. Le terminal-client 10 se présente sous la forme d'un téléphone mobile performant tel qu'un smartphone, ou bien une tablette 20 numérique, ou encore d'un ordinateur. Le terminal-client 10 comprend une unité de calcul 12 dotée notamment d'une mémoire 14 et d'un calculateur 16. Le terminal-client 10 peut soit être utilisé par un utilisateur légitime, à qui il appartient, c'est-à-dire un utilisateur non frauduleux, 25 ou bien par un utilisateur mal intentionné, c'est-à-dire un utilisateur frauduleux. Cet utilisateur frauduleux peut soit être une personne, soit être une entité numérique. La mémoire 14 peut être sous la forme d'une mémoire flash, ou bien d'une mémoire morte, type ROM, ou encore d'une mémoire vive 30 RAM. La mémoire 14 peut aussi être sous la forme d'un stockage dit externe, configuré pour être connecté physiquement à l'unité de calcul 12, par exemple par un port USB. 3054905 9 Le calculateur 16 est un microprocesseur, un processeur, ou un microcontrôleur apte à effectuer des calculs et en particulier à mettre en oeuvre des algorithmes d'encodage ou de décodage, de type « key binding ». Le calculateur 16 est notamment configuré pour exécuter des 5 lignes de codes issues d'un programme d'ordinateur. Avantageusement, le terminal-client 10 comprend des moyens d'acquisition de données biométriques 18. Ces moyens 18 permettent d'acquérir un iris ou une empreinte digitale par exemple. On peut citer par exemple un capteur d'image couplé à un module logiciel d'extraction 10 d'une donnée biométrique. Les moyens d'acquisition de données biométriques 18 peuvent être intégrés au terminal-client 10 ou externes, mais connectables à ce dernier. On connait pour cela des dispositifs d'acquisition reliés en filaire à un ordinateur. 15 Le serveur 20 comprend lui aussi une unité de calcul 22 dotée notamment d'une mémoire 24 et d'un calculateur 26. Le serveur 20 est typiquement un serveur de cloud, c'est-à-dire délocalisé. La mémoire 24 peut être sous la forme d'une mémoire flash, ou bien d'une mémoire morte, type ROM, ou encore d'une mémoire vive 20 RAM. La mémoire 24 peut aussi être sous la forme d'un stockage dit externe, configuré pour être connecté physiquement à l'unité de calcul 22, par exemple par un port USB. Le calculateur 26 est un microprocesseur, un processeur, ou un microcontrôleur apte à effectuer des calculs et en particulier à mettre en 25 oeuvre des algorithmes d'authentification. Le calculateur 26 est notamment configuré pour exécuter des lignes de codes issues d'un programme d'ordinateur. Les deux unités de traitement 12, 22 comprennent 30 avantageusement des interfaces de communication 11, 21 à distance pour l'envoi et la réception de données, notamment par le réseau 30. Le réseau 30 est soit un réseau internet, filaire (Ethernet) ou sans-fil (Wi-Fi), soit un réseau téléphonique GPRS, EDGE, 3G ou 4G ou 3054905 10 autre, soit un réseau local, soit un réseau par signal radiofréquence. Les interfaces de communication 11 et 21 sont adaptées pour permettre la communication en fonction du réseau 30 concerné. 5 Lorsque les opérations ne nécessitent pas que les informations soient transmises entre le terminal-client 10 et le réseau 20, on parle de traitement en « local ». En référence aux figures 2 et 3, un procédé E de génération 10 d'une clé cryptographique va être présenté. Ce procédé E vise à générer une clé cryptographique quelle que soit la donnée biométrique test DBtest entrée. L'authentification du terminal-client 10 auprès du serveur 20 se fait grâce à une clé cryptographique légitime KI. Si le serveur reconnait 15 cette clé, l'utilisateur est authentifié et l'accès à la ressource du serveur 20 est validé. A l'utilisateur légitime est associée un donnée biométrique de référence DBref. Dans le cas du key-binding, cette donnée DBref n'est pas stockée en tant que telle dans la mémoire 14 du terminal-client 10. 20 En effet, à l'aide d'un procédé d'encodage GEN, dit de key-binding, la clé cryptographique légitime KI est combinée à la donnée biométrique de référence DBref, pour générer une donnée de référence Dref, stockée dans la mémoire 14. Le procédé GEN est mis en oeuvre à partir de KI et BDref pour obtenir en sortie Dref. 25 Cette donnée permet donc une authentification biométrique de l'utilisateur auprès du serveur 20. Il s'agit donc bien de la biométrique de l'utilisateur qui conditionne l'authentification auprès du serveur 20 pour le contrôle d'accès. A l'issue de ce procédé d'encodage GEN, la donnée biométrique 30 de référence DBref et la clé cryptographique légitime KI peuvent être détruites pour ne pas être stockées en clair en local. 3054905 11 Le procédé d'encodage GEN est une étape préliminaire GO à la mise en oeuvre du procédé E de génération d'une clé cryptographique qui va être décrit ci-dessous. 5 Dans une première étape El, un donnée biométrique test DBtest est reçue par l'unité de calcul 12 du terminal-client 10. Comme indiqué précédemment, cette donnée biométrique BDtest est obtenue soit préalablement par les moyens d'acquisition 18, soit par une génération numérique. 10 Dans une deuxième étape E2, le calculateur 16 applique un procédé de décodage REP à la donnée biométrique test DBtest et la donnée de référence Rref, afin qu'il génère une clé cryptographique K' quelle que soit la donnée biométrique test BDtest. Le procédé de décodage REP est fonctionnellement lié au procédé 15 d'encodage GEN. Ces procédés peuvent être de type « secure sketch » comme le « fuzzy commitment scheme », ou encore de type « fuzzy vault », « helper data system », etc. Le mode de réalisation du fuzzy commitment scheme sera notamment décrit par la suite. Si la donnée biométrique test BDtest correspond à la donnée 20 biométrique de référence BDref, la clé cryptographique K' est la clé d'authentification cryptographique légitime KI (K'=KI). Si la donnée biométrique test BDtest ne correspond pas à la donnée biométrique de référence BDref, la clé cryptographique K' est une clé d'authentification cryptographique illégitime Ki (K'=Ki=KI). 25 La correspondance entre les données biométriques peut se faire de différentes façons. On connait notamment des méthodes de mesure de distance de Hamming, ou des méthodes avec une distance statistique, ou encore des mesures de taux de similarité. 30 La clé illégitime Ki ne permet pas l'authentification du terminal- client 10 auprès du serveur 20. 3054905 12 Enfin, dans une troisième étape E3, la clé générée K', qui est soit légitime soit illégitime, est utilisée pour la mise en oeuvre d'un procédé de contrôle d'accès du terminal-client 10 auprès du serveur 20. Dans un mode de réalisation, l'utilisation de la clé K' peut 5 simplement consister à transmettre la clé vers le serveur 20 à l'aide de l'interface 11, pour que ce dernier mette en oeuvre un procédé de contrôle d'accès du terminal-client 10 à une ressource du serveur 20. Dans un autre mode de réalisation, l'utilisation n'implique pas de transmission directe de la clé générée K', mais implique des opérations 10 de preuve de connaissance, de sorte que seule une transmission d'une donnée associée à la clé est effectuée : il est ainsi possible de prévoir que la clé K' soit transmise de façon masquée. Dans ce cas, une donnée distincte de K' mais générée à partir de celle-ci est transmise par le terminal-client 10 au serveur 20. On parlera dans ce cas de données 15 dépendantes de la clé. C'est le cas par exemple lors d'une mise en gage de Pedersen, qui sera décrite par la suite. Ce type de méthode permet une protection améliorée des données. Ainsi, grâce à ce procédé, une clé K' est générée 20 systématiquement, de sorte que les échanges d'informations entre le terminal-client 10 et le serveur 20 ne se font pas uniquement si la clé légitime KI est générée. Comme cela sera décrit par la suite, le serveur 20 peut alors être informé qu'un utilisateur malveillant essaie de s'authentifier frauduleusement à partir du terminal-client 10. 25 Avant de décrire un procédé de contrôle d'accès F du terminal-client 10 auprès du serveur 20 à l'aide de la clé générée K', différents modes de réalisation du key-binding et des procédés d'encodage GEN et de décodage REP vont être donnés. 30 Dans un mode de réalisation illustré en figure 3, un mode de réalisation particulier d'un secure sketch, le fuzzy commitment scheme, est utilisé, c'est-à-dire un algorithme de codage basé sur l'utilisation 3054905 13 d'un code correcteur d'erreur. Le fuzzy commitment scheme est décrit dans le document [FCS], (section I.A). Dans l'étape préliminaire GO d'encodage, le procédé d'encodage GEN se présente sous la forme suivante : 5 - Binariser la donnée biométrique de référence BDref, pour obtenir une donnée b, - A partir d'un mot c d'un code correcteur d'erreur, obtenir à partir de la référence un résultat tel que SSK = [c XOR b, h(c)], où XOR est la fonction « ou exclusif », et h est une fonction de hashage 10 cryptographique, par exemple de type SHA-256, - Enregistrer le résultat SSK en local. Le mot c est en fait un mot de code généré à partir de la clé cryptographique légitime KI (un mot de code est la réécriture d'un message d'origine où de la redondance a été ajoutée) et SSK est la donnée de référence DBref. 15 On peut aussi stocker h(KI) à la place de h(c). Cette étape est explicitée dans l'introduction de [FCS]. Dans l'étape E2 de décodage, le procédé de décodage REP se présente sous la forme suivante : - binariser la donnée biométrique test DBtest, pour obtenir b', 20 - calculer c XOR b XOR b' à partir de la donnée SSK, pour obtenir c'. Le mot c' est la clé cryptographique K'. Si b' et b sont suffisamment proches, on a c=c', donc K'=KI. Si b' et b ne sont pas suffisamment proches, K'=Ki. Dans le cas d'un FCS, la notion de suffisamment proche se calcule 25 préférablement par une distance de Hamming entre b et b' (voir introduction de [FCS]). Dans un premier exemple, afin de s'assurer que le procédé de décodage REP génère systématiquement une clé, même si b et b' ne sont pas suffisamment proches, un procédé de décodage d'erreur, dit 30 décodage souple (soft decoding) est utilisé. Ce procédé est lui aussi décrit dans [FCS], section IV. Le principe de décodage souple est de retourner, quand cela est possible, un mot de code c' le plus vraisemblable possible, et donc avec 3054905 14 une probabilité d'erreur. Si le procédé REP réussit à corriger toutes les erreurs, ce qui est le cas si les deux données biométriques b et b' se correspondent mutuellement suffisamment, le mot de code c' sera le même que le mot de code c. 5 Lorsque le procédé de décodage est itératif, un nombre maximal d'itération peut être fixé, pour limiter le temps de décodage, ou bien un critère de qualité peut être défini (fondé sur un seuil sur la probabilité d'erreur). Dans le cas d'un procédé de décodage souple comme celui dans [FCS], un mot de code c' est toujours retourné : il s'agit par 10 exemple du mot de code le plus proche du mot « c XOR b XOR b' » suivant la distance utilisée dans l'espace des mots de code. Si le décodage souple s'est bien déroulé, on retrouve exactement la clé légitime KI. Si les itérations continuent alors que c'=c, le même mot c' sera généré à chaque itération. Une méthode pour limiter les itérations 15 consiste par exemple à vérifier si h(K')=h(KI), avec h fonction de hachage. Un autre exemple de décodage d'erreur pour s'assurer que le procédé de décodage REP génère systématiquement une clé serait de restreindre le mot retrouvé aux bits d'information (cela peut être fait en 20 ne sélectionnant que les I premiers bits du mot retrouvé, si le code correcteur est de dimension I), afin de les considérer comme un message d'origine et de l'encoder en un mot de code c'. Dans un autre mode de réalisation, une architecture de type 25 helper data system est utilisée. Le helper data system est décrit dans le document [HDS], en section 3, et à la figure 2. Le procédé d'encodage GEN est alors conforme au protocole décrit dans cette publication permettant de générer, à partir d'une donnée biométrique X initiale (correspondant à DBref) et d'un secret S généré 30 aléatoirement (correspondant à KI), un doublet (W1, W2)- Le décodage REP, peut correspondre au décodage DEC décrit dans ce document, permettant de régénérer un secret S', (correspondant à K') à partir d'une donnée biométrique de test Y 3054905 15 (correspondant à DBtest). Un algorithme de décodage souple tel que décrit pour le Fuzzy Commitment Scheme est mis en oeuvre. Dans un autre mode de réalisation, une architecture de type fuzzy 5 vault est utilisé. Le fuzzy vault est décrit dans le document [FV]. Le procédé d'encodage GEN correspond à l'algorithme LOCK décrit dans la section 3 de cet article. Le décodage REP correspond à l'algorithme UN LOCK décrit dans la section 3 de cet article, utilisant un algorithme de décodage de Reed 10 Solomon, auquel est appliqué un procédé de décodage itératif, comme présenté dans le document [FVDEC]. Dans un autre mode de réalisation, un algorithme de type fuzzy extractor est utilisé. Cet algorithme est décrit dans le document [FC], 15 section 3.2. Le décodage peut être mis en oeuvre avec par exemple un procédé de même type que le FCS ou Fuzzy Vault, en fonction du code sous-jacent à l'algorithme. En outre, il existe certains protocoles qui exigent des formats de 20 clés spécifiques. Pour que les clés K' générées soit toutes utilisables, il faut que les clés aient le bon format, c'est-à-dire que le procédé REP génère des clés dans le bon format, qui est celui de la clé légitime KI. Les normes FIDO et ECDSA utilisent des courbes elliptiques, ce qui signifie que l'on stocke KI pour un point KIP de la courbe elliptique. Il 25 n'y a donc pas besoin de forme particulière pour la clé cryptographique. En revanche, dans les protocoles RSA par exemple, la clé doit avoir un format prédéterminé. Il s'agit de s'assurer que la clé K' systématiquement générée en sortie de l'étape E2 de décodage soit compatible avec ce format. Comme la clé légitime KI est choisie pour 30 avoir ce format, on souhaite que la clé générée K' ait ce même format. Il existe des méthodes de honey encryption (chiffrement mielleux), présentée dans le document [HE] qui permet de convertir la clé dans le format souhaité. 3054905 16 Avantageusement, le procédé comprend donc une étape supplémentaire de conversion de la clé générée K' selon un format désiré qui correspond au format de la clé légitime, au moyen d'un algorithme de chiffrement mielleux. Cet algorithme de chiffrement 5 mielleux utilise le chiffrement de la clé légitime KI stocké en parallèle de BDref pour retrouver la clé dans le bon format. Cette étape est elle aussi mise en oeuvre par le calculateur 16. L'étape d'encodage de la clé légitime KI comprend donc les étapes suivantes : sélection de la clé légitime KI, chiffrement (dit « mielleux ») 10 de la clé légitime KI avec une autre clé Km (dite « mielleuse ») pour obtenir une clé légitime mielleusement chiffrée Klm, et ensuite mise en oeuvre du procédé d'encodage GEN avec la clé mielleuse Km. Sont donc stockées dans la mémoire 14 la clé légitime KI cryptée et la donnée de référence Dref obtenue avec la donnée biométrique de référence BDref 15 et la clé mielleuse Km. L'étape de décodage permet d'obtenir une clé générée dite mielleuse K'm. Cette clé générée mielleuse K'm est ensuite utilisée pour déchiffrer la clé légitime mielleusement chiffrée Klm. A la suite de ce déchiffrement, on obtient la clé générée K', qui vaut KI si les données 20 biométriques DBref et DBtest sont suffisamment proches. A partir de la clé cryptographique générée K', un procédé de contrôle d'accès F peut-être mis en oeuvre. Dans une première étape F1, le procédé E de génération d'une clé 25 cryptographique tel que décrit précédemment est mis en oeuvre. A l'issue de ce procédé E, la clé générée K', ou des données dépendantes de cette clé générée K', est envoyée au serveur. L'envoi peut être simple, en clair, ou de façon masquée, à l'aide notamment de preuve de connaissance, dans lequel plusieurs données dépendant de la clé sont 30 envoyées, mais pas la clé elle-même. On peut citer la mise en gage pour l'enregistrement, comme dans le cas de Pedersen (décrit par la suite). 3054905 17 Dans une deuxième étape F2, la clé cryptographique K', ou bien les données dépendantes de cette clé, est reçue par l'interface de communication 21 du serveur 20. Enfin, dans une troisième étape F3, la clé (ou les données 5 dépendantes de la clé) reçue à l'étape précédente est analysée par le calculateur 26 du serveur 20. Comme indiqué précédemment, il est par exemple possible que la clé K' ait été transmise en clair, ou bien ait été transmise en masquée, notamment par une preuve de connaissance. Cette étape d'analyse F3 permet d'identifier si la clé K' est la clé 10 légitime KI, auquel cas l'utilisateur est authentifié, ou bien si la clé K' est une clé illégitime, auquel cas l'utilisateur n'est pas authentifié. En outre, si l'authentification est un échec, un procédé F4 d'alerte est déclenché. Ce procédé F4 d'alerte indique que la donnée biométrique de test DBtest ne correspond pas à la donnée biométrique de référence 15 BDref. Le serveur 20 possède désormais l'information qu'un utilisateur illégitime est en train de frauduleusement utilisé le terminal-client 10. Par la suite, le procédé d'alerte F4 peut déclencher différent types d'étapes, combinables en elles et générées par le serveur 20. 20 Dans un mode de réalisation, le serveur 20 envoie au terminal- client 10 une consigne de ré-acquisition de la donnée biométrique test BDtest. Dans un mode de réalisation, une variable de comptage est incrémentée par itération à chaque réception d'une clé illégitime Ki, de 25 sorte que le serveur 20 a connaissance du nombre de tentatives d'authentification. Dans un mode de réalisation, le serveur 20 envoie une consigne de verrouillage du terminal-client 10 au terminal-client 10, pour empêcher toute tentative de connexion. Par exemple, l'envoi de cette 30 consigne peut être fait après que la variable de comptage ait atteint une certaine valeur, par exemple 5. Dans un mode de réalisation, le serveur 20 peut déclencher une authentification biaisée du terminal-client 10 auprès du serveur 20, de 3054905 18 sorte que le terminal-client 10 se comporte comme un terminal authentifié. L'utilisateur frauduleux ignore alors que l'authentification a été un échec. Le serveur 20 peut alors surveiller les agissements du terminal-client 10, ou lui donner accès à des données faussées par 5 exemple. Dans un mode de réalisation, le serveur 20 détruit des données confidentielles qu'il stocke dans sa mémoire 22, comme par exemple des données relatives à un ou plusieurs utilisateurs légitimes du terminal client. 10 Dans un mode de réalisation, le serveur 20 génère une consigne de destruction des données relatives à l'utilisateur légitime stockées dans la mémoire 12 du terminal-client 10. Dans un mode de réalisation : l'encodage GEN et le décodage REP 15 sont effectués avec plusieurs clés à la fois. Le procédé de génération de clé inclue alors une étape de sélection de la « bonne » clé en fonction du serveur associé. On définit ainsi une pluralité de serveurs et/ou de ressources associées au(x) serveur(s), et à chaque serveur et/ou ressources respectifs, est associé une clé légitime pour le contrôle 20 d'accès. Par exemple, pour le secure sketch, le mot de code c est obtenu comme le mot de code dérivant de KI1 I I KI2 I I I Kln (ou I I correspond à l'opérateur de concaténation). Par exemple, KI1 sera utilisé pour un premier serveur et/ou ressource, et KI2 pour le deuxième serveur et/ou 25 ressource, etc... Après l'étape de décodage E2, une étape de sélection est mise en oeuvre pour récupérer la clé générée souhaitée. Cette étape de sélection comprend avantageusement une déconcaténation de la clé obtenue K'conc = I I K'2 I I ---I I K'n pour récupérer les clés K', qui la constituent. 30 La « bonne » clé sélectionnée est ensuite utilisée dans le cadre d'un contrôle d'accès avec le serveur correspondant (étape E3). 3054905 19 Ce mode de réalisation permet au terminal-client d'échanger avec plusieurs serveurs et/ou ressources d'un serveur en gardant une procédure de cryptage commune. Ce mode de réalisation est compatible entre autres avec le 5 chiffrement mielleux, qui est alors appliqué sur KI1 I I K12 I I --- KLn . A présent, comme mentionné précédemment, un mode de réalisation particulier à l'aide d'une mise en gage de Pedersen, Pedersen's commitment va être décrite, en relation avec la figure 4 et 10 la référence [CP], et plus précisément la référence [CERIAS]. La mise en gage de Pedersen comprend deux phases : une phase d'enrôlement (commitment) et une phase de dévoilement (revealing). La phrase d'enrôlement est mise en oeuvre préalablement au 15 procédé E de génération de clé cryptographique. Dans une première étape G01, le terminal-client génère et stocke une valeur aléatoire r, puis, dans une deuxième étape G02, il génère une mise en gage MG permettant de ne pas divulguer la clé légitime KI au serveur : MG(r, KI) = c(r, KI) = gKI hr 20 où g et h sont tels que logg(h) n'est pas connu. KI et r correspondent à s et t en partie 3 de [CP], et à x et r dans [CERIAS]. Cette mise en gage MG est ensuite envoyée au serveur 20 qui la stocke sur sa mémoire 22. 25 La phase de dévoilement se fait si un procédé d'authentification F est déclenché. Préalablement à l'étape E3, F2 de transmission de la clé cryptographique générée K', qui est ici masquée à l'aide de la valeur r, le terminal-client 10 et le serveur 20 échangent différentes données (cf. 30 les données dépendantes de la clé, citées précédemment). Dans une sous-étape G11, le terminal-client 10 calcule et envoie au serveur 20 : 3054905 20 ili. A2 = gal. ha2 Où al et a2 sont notés y et s dans [CERIAS] et sont des valeurs aléatoires. Dans une sous-étape G12, le serveur 20 génère et envoie un aléa c au terminal-client 10 (aussi noté c dans [CERIAS]). 5 Dans une sous-étape G13, le terminal-client 10 calcule à l'aide notamment la clé cryptographique générée K' par le procédé de décodage E2. yi = a1 + K'. c et y2 = a2 + r. c L'envoi de ces données avec A1.A2 correspond à la preuve de connaissance de K'. 10 A cette étape, la clé K' devient masquée. Ensuite, à l'étape de transmission E3, le terminal-client 10 envoie y1 et y2 au serveur 20. Enfin, l'étape d'analyse F3 la clé F3 comprend la vérification suivante : e1h312 = MGcil1A2 15 Cette égalité est vérifiée si K'=KI. Un telle mise en gage garantit une authentification avec une divulgation nulle de r et de K'. 20 D'autres schémas de mise en gage peuvent être envisagés, comme une mise en gage de KI en stockant la valeur gK' puis la preuve de connaissance de Schnorr (voir [SCH]). Plus généralement, l'authentification peut comprendre un protocole à divulgation nulle de connaissance, illustré par la mise en 25 gage de Pedersen. Un mode de réalisation complémentaire pour les échanges entre le serveur et le terminal-client utilise une signature électronique, telle que dans FIDO, ou bien en utilisant ECDSA ou RSA. 30 3054905 21 REFERENCES : [CRYBIO] : "Biometric Encryption Chapter from the Encyclopedia of Biometrics", de Cavoukian et Stoianov. 5 [WEAK] : "Privacy Weaknesses in Biometric Sketches" de Simoens, Tuyls et Preneel. [PROBE] : « ECDSA Key Extraction from Mobile Devices via Nonintrusive 10 Physical Side Channels » de Genkin et al. [FCS] : « Theoretical and Practical Boundaries of Binary Secure Sketches", de Bringer et al. 15 [HDS] : "(Practical Biometric Authentication with Template Protection », de Tuyls et al. [FV] : « A Fuzzy Vault Scheme » de Juels et al. 20 [FVDEC] : "Algebraic soft-decision decoding of Reed-Solomon codes" de Koetter et al. [FC] : "Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data", de Dodis et al. 25 [HE] : "Honey Encryption: Security Beyond the Brute-Force Bound" de Juels et al. [CP]: "Non-interactive and information-theoretic secure verifiable secret 30 sharing", de Pedersen. [CERIAS]: CERIAS Tech Report 2008-28 Privacy-Preserving Management of Transactions' Receipts by Federica Paci, Ning Shang, 3054905 22 Elisa Bertino, Sam Kerr, Kevin Steuer, Jr., Jungha Woo Center for Education and Research Information Assurance and Security Purdue University, West Lafayette, IN 47907-2086. 5 [SCH]: Schnorr; "Efficient identification and signatures for smart cards". In CRYPTO '89" REVENDICATIONS1. Procédé de génération d'une clé cryptographique pour la mise en oeuvre d'un procédé de contrôle d'accès à une ressource d'un serveur (20) par un terminal-client (10), le procédé étant mis en oeuvre par le terminal-client (10), ledit terminal étant configuré pour communiquer avec le serveur (20), le terminal-client (10) comprenant une mémoire (14) dans laquelle est stockée une donnée de référence (Dref) obtenue par l'application d'un procédé d'encodage à une donnée biométrique de référence (DBref) et une clé cryptographique légitime (KI) permettant d'authentifier le terminal-client (10) auprès du serveur (20) lors d'un contrôle d'accès, le procédé comprenant les étapes suivantes: - (El) réception d'une donnée biométrique test (DBtest), - (E2) application d'un procédé de décodage à la donnée biométrique test (DBtest) et la donnée de référence (Dref) pour obtenir une clé cryptographique (K') telle que : si la donnée biométrique test (DBtest) correspond à la donnée biométrique de référence (DBref), la clé cryptographique générée (K') est la clé d'authentification cryptographique légitime (KI), sinon, la clé cryptographique générée (K') est une clé d'authentification cryptographique illégitime (Ki) ne permettant pas l'authentification du terminal-client (10) auprès du serveur (20) lors d'un contrôle d'accès, et - (E3) utilisation de la clé générée pour la mise en oeuvre d'un procédé de contrôle d'accès (F3) à une ressource du serveur (20) par le terminal client (10). 2. Procédé selon la revendication 1, comprenant en outre une étape préliminaire (E0) de génération de la donnée biométrique test (DBtest), soit par acquisition à l'aide de moyens d'acquisition de donnée biométrique (18), soit par génération numérique. 3054905 24 3. Procédé selon l'une quelconque des revendications 1 à 2, dans lequel le procédé d'encodage est du type « secure sketch », tel qu'un Fuzzy Commitment Scheme, ou du type He/per Data System, ou du type Fuzzy Vault par exemple avec des codes de Reed-Solomon. 5 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel l'étape de génération (E2) de la clé cryptographique comprend la mise en oeuvre d'un procédé de décodage d'erreur. 10 5. Procédé selon la revendication précédente, dans lequel le procédé de décodage d'erreur est un procédé de décodage souple, de préférence avec un nombre limité d'itération, par exemple par un nombre limite ou par un critère de qualité d'arrêt. 15 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la clé cryptographique légitime (KI) présente un format adapté pour l'utilisation de la clé dans un protocole de contrôle d'accès par authentification mis en oeuvre entre le terminal-client (10) et un serveur (20), et le procédé de décodage est adapté pour que la clé 20 cryptographique illégitime (Ki) ait le format de la clé cryptographique légitime (KI). 7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel le procédé de décodage (REP) et le procédé d'encodage (ENC) 25 comprennent des étapes de chiffrement et déchiffrement mielleux (honey encryption). 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel le procédé d'encodage est mis en oeuvre sur une pluralité de clés 30 légitimes concaténées (KI1 II K12 II ....I I Kln), les clés légitimes permettant d'authentifier le terminal-client (10) auprès de plusieurs serveurs et/ou ressources respectifs lors d'un contrôle d'accès, et dans lequel le procédé de décodage permet l'obtention d'une clé générée 3054905 25 concaténée (Woenc) comprenant une pluralité de clés générées concaténée entre elles (K',. II K'2 II -.- I I K'n), le procédé comprenant avantageusement une étape de sélection d'une des clés générées parmi la pluralité des clés générées (K'1, , K'2, K'n) pour son utilisation dans un 5 procédé de contrôle d'accès au serveur et/ou une ressource associé à la clé légitime (KI) qui a permis la génération de ladite clé générée (K'). 9. Procédé selon l'une quelconque des revendications précédentes, dans lequel la correspondance entre les deux données biométriques signifie 10 que la distance entre les deux données biométriques est inférieure à un seuil donné. 10. Produit programme d'ordinateur, comprenant des instructions de code pour la mise en oeuvre d'un procédé selon l'une des revendications 15 précédentes, lorsqu'il est mis en oeuvre par un calculateur (16). 11. Unité de calcul (12), comprenant une mémoire (14), un calculateur (16), et une interface de communication (11) avec un serveur (20), caractérisée en ce qu'elle est adaptée pour mettre en oeuvre le procédé 20 selon l'une des revendications 1 à 9, ladite unité de calcul étant un dispositif personnel à un individu de type téléphone mobile, tablette numérique, ou encore ordinateur personnel. 12. Procédé de contrôle d'accès d'un terminal-client (10) à une 25 ressource d'un serveur (20), ledit procédé comprenant les étapes suivantes : - (F1) mise en oeuvre d'un procédé de génération d'une clé cryptographique selon l'une quelconque des revendications 1 à 9, - (F2) réception par le serveur (20) de la clé (K') ou de données 30 dépendantes de la clé, - (F3) analyse de la clé (K') ou desdites données dépendantes de la clé par le serveur (20): 3054905 26 si la clé est une clé légitime (KI), authentification du terminal- client (10) auprès du serveur (20) et accès du terminal client à la ressource du serveur, si la clé est une clé illégitime (Ki), échec de l'authentification du 5 terminal-client (10) auprès du serveur (20) et mise en oeuvre d'un procédé (F4) d'alerte indiquant que la donnée biométrique de test (DBtest) ne correspond pas à la donnée biométrique de référence (DBref). 10 13. Procédé selon la revendication 12, dans lequel le procédé d'alerte (F5) comprend au moins une des étapes suivantes : - stockage du nombre d'itérations de réceptions de clés illégitimes (Ki), et/ou - envoi d'une consigne de verrouillage du terminal-client (10), et/ou 15 - authentification biaisée du terminal-client (10) auprès du serveur (20), de façon à pouvoir surveiller ledit terminal-client (10), et/ou - destruction des données stockées sur le terminal-client (10) et/ou sur le serveur (20), et/ou, - envoi au terminal-client (10) d'une consigne de ré-acquisition de 20 données biométriques test (BDtest). 14. Procédé selon l'une quelconque des revendications 12 à 13, comprenant la mise en oeuvre d'un protocole de preuve de connaissance à divulgation nulle de connaissance. 15. Procédé selon l'une quelconque des revendications 12 à 13, dans lequel les échanges entre le terminal-client et le serveur comprennent la mise en oeuvre d'une signature électronique, tel que FIDO ou ECDSA ou encore RSA. 16. Procédé selon l'une quelconque des revendications 12 à 14, mettant en oeuvre une mise en gage selon Pedersen comprenant une phrase d'enrôlement dans laquelle 25 30 3054905 27 le terminal-client (10) stocke une grandeur aléatoire r, le terminal-client (10) génère une mise en gage MG sous la forme MG (7- , KI) = gKI, n et l'envoie au serveur (20) qui la stocke, où KI est la clé légitime, et g et h sont tels que logg(h) n'est pas connu, 5 et comprenant une phase de dévoilement, dans laquelle, préalablement à l'étape de transmission de la clé (E3), les sous-étape suivantes sont mises en oeuvre : le terminal-client (10) envoie au serveur (20) : Al A2= gal. ha2 le serveur (20) génère et envoie un aléa c au terminal-client (10), 10 le terminal-client (10) calcule = a1 + . c et y2 = a2 + r. c où K' est la clé cryptographique générée par le procédé de décodage (E2, F1) et al et az sont des valeurs aléatoires, l'étape de transmission (E3) comprend l'envoi de yi et y2 au serveur (20), 15 l'étape d'analyse de la clé (F3) comprend la vérification suivante : e1h312 = MGc