Brevet FR3154209A1 — publié le 20250418

La présente invention concerne un procédé pour la mise en œuvre d’une transaction entre un premier équipement (1) dit de preuve, et un deuxième équipement (2) dit de vérification, comprenant la mise en œuvre d’étapes de : Génération, par des moyens de traitement de données (11) du premier équipement (1), de paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à ladite transaction, et transmission audit deuxième équipement (2) des paramètres généraux et de la clé publique mais pas de la clé privée ; Vérification, par des moyens de traitement de données (21) du deuxième équipement (2), de la connaissance de ladite clé privée par le premier équipement (1) en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre (b2, b3, b4) dudit Σ-protocole. Si la connaissance de ladite clé privée par le premier équipement (1) est vérifiée, mise en œuvre de ladite transaction par ledit deuxième équipement (2) ; Le procédé étant caractérisé en ce que ladite étape (b) comprend, avant la mise en œuvre (b2, b3, b4) dudit Σ-protocole, la transmission préalable (b1) au premier équipement (1) d’une valeur d’engagement d’une valeur de défi dudit Σ-protocole. [Fig. 1] Procédé de mise en œuvre d’une transaction entre un premier équipement de preuve et un deuxième équipement de vérification. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine de la cryptographie. Plus précisément, elle concerne un procédé pour la mise en œuvre d’une transaction entre un premier équipement de preuve, et un deuxième équipement de vérification, utilisant une preuve à divulgation nulle de connaissance niable. ETAT DE L’ART On utilise de manière croissante dans les transactions des procédés cyptographiques dits à preuve à divulgation nulle de connaissance, ou ZKP (Zero Knowledge Proof), grâce auxquels une première entité dite de preuve (le « prouveur ») peut prouver la connaissance à une deuxième entité dite de vérification (le « vérificateur ») la connaissance d’un secret s sans partager ce secret ni aucune clé privée commune a priori . Cela est très utile pour de nombreuses transactions notamment d’authentification ou d’identification : au lieu de fournir une donnée biométrique candidate à l’entité de vérification (ce qui pose problème en termes de respect de la vie privée), le prouveur peut lui-même faire la comparaison entre cette donnée biométrique candidate et une donnée biométrique de référence, et transmettre à l’entité de vérification une preuve du résultat de la comparaison, qui ne divulguerait pas les données biométriques. Un autre cas d’usage est celui d’une transaction dans le domaine médical, notamment pour une ordonnance : au lieu de fournir sa carte vitale et donc de dévoiler son identité (ce qui pose problème en termes de confidentialité médicale par exemple pour une prescription d’un produit de sevrage), le prouveur (patient) peut fournir au vérificateur (un prescripteur) une preuve qu’il a bien droit aux soins, qui ne divulguerait pas son identité. Dans d’autres applications, le prouveur peut prouver similairement, avec les mêmes contraintes sur la fiabilité : La possession d’un document d’identité sans le fournir ; La réalisation d’un paiement sans donner ses informations bancaires Un droit d’accès à un produit, un service ou un lieu en restant anonyme ; Etc. Le problème qui se pose néanmoins est celui la confiance en la preuve. Il est en effet nécessaire de proposer un moyen pour que l’entité de vérification en charge du contrôle puisse vérifier que le résultat est correct et que l'utilisateur n'a pas réalisé de fraude ou d'erreur dans l’action dont il se prévaut (par exemple la comparaison des données biométriques). On a proposé des ZKP « interactives » (on parle alors de ZKIP pour Zero Knowledge Interactive Proof), dans lesquelles les entités de preuve et de vérification et s'échangent des informations de sorte que la dernière puisse s’assurer de la fiabilité de la preuve. Une méthode pour construire des ZKPs utilise ce qu'on appelle des Σ-protocole (ainsi nommés en raison de la communication en trois échanges qui fait penser à la lettre grecque Sigma). Un Σ-protocole (ou sigma protocole) est un protocole interactif entre un prouveur et un vérifieur mettant en jeu trois échanges : L’engagement (ou le « gage ») qui est un premier message x envoyé par le prouveur au vérifieur ; Le défi c (ou challenge), qui est une question envoyée par le vérifieur ; La réponse y, qui est le dernier message envoyé par le prouveur y permet de répondre à la question c par rapport à l’engagement x. De multiples preuves sans divulgation de connaissances reposent sur cette construction, par exemple les protocoles de Fiat-Shamir, de Schnorr, ou de Guillou-Quisquater dont il sera question plus tard. A noter qu’on peut même utiliser RSA comme un Σ-protocole. La compréhension de l’art antérieur et de l’invention requiert le rappel de la notion de « fonction d’engagement » (on trouve également le terme français de « de mise en gage » pour désigner cette notion). En cryptologie, l’engagement est un processus qui permet à une personne de « mettre en gage » une valeur (ou un énoncé) tout en la maintenant cachée aux autres, avec la possibilité de révéler cette valeur plus tard en prouvant que c'est bien la valeur qui avait été mise en gage. L’engagement est conçu de telle sorte que la personne est liée à la valeur mise en gage. En pratique, la mise en gage se fait en calculant une valeur de mise en gage à partir de la valeur que l'on veut cacher et en communiquant cette valeur de mise en gage à un destinataire. Par la suite, lorsque la valeur originellement cachée sera communiquée au destinataire, celui-ci pourra vérifier que la valeur qui lui a été révélée est bien la valeur qui a servi à calculer la valeur de mise en gage. Plus formellement, la mise en gage transforme une valeur m en une paire (c, d) de telle que : 1) c ne révèle aucune information sur m, mais que, 2) ensemble, c et d permettent de révéler m, et que 3) il est impossible de trouver d' tel que (c, d') révèle m' ≠ m. Dans la pratique, dans de nombreux scénarios, il est possible simplement de communiquer à titre d’engagement un haché H(m) (ou empreinte cryptographique – pour une fonction de hachage donnée) car le fait de révéler m permet ultérieurement à tout un chacun de recalculer H(m). Cette pratique souffre toutefois d’une faiblesse : si l’entropie de m est faible un attaquant pourrait retrouver m par recherche exhaustive à partir de H(m). Par exemple, si m est un mot du français usuel, une recherche exhaustive portant sur les 32000 mots du français usuel révèlera m. Afin de protéger contre une telle attaque il est habituel de s’engager sur H(m|r) où r est un aléa de grande taille (par exemple 160 bits) puis de révéler, lors de l’ouverture de l’engagement, les données m et r. On note de manière générique Eng(m) un engagement sur un message m, avec un éventuel l’aléa r. La vérification de Eng(m) sera notée de manière générique Ouvre(m, Eng(m)). La procédure Ouvre retourne un booléen selon que l’ouverture ait réussi ou pas. La plupart des ZKPs actuelles repose sur des algorithmes qui intègrent des problèmes difficiles issus de la théorie des nombres, comme la factorisation ou le calcul du logarithme discret. Conçu en 1987, le protocole Fiat-Shamir (voir la demande US4748668) constitue le précurseur de presque toutes les ZKPs modernes, et concerne la preuve de la connaissance d’un clé privée sk = {s 1 , …, s k } sans dévoiler celle-ci. Selon le protocole de Fiat-Shamir chaque prouveur dispose en outre d'une clé publique pk = {n, e, v 1 , …, v k }. Le nombre n = pq est le produit de deux grand nombres premiers. La clé privée sk = {s 1 , …, s k } est définie par la relation s i e v i =1 mod n et se dérive des facteurs premiers de n. Les aléas servant à générer ces paramètres et clés sont fournis aléatoirement. Pour prouver sa connaissance de sk, le prouveur génère à partir de SS un aléa r et envoie au vérificateur un engagement x = r e mod n. Le vérificateur réplique avec un défi aléatoire c composé de k chiffres c = c 1 |c 2 |…|c k en base e (en d’autres termes 0 ≤ c i ≤ e-1). c est généré également aléatoirement. Le prouveur réplique avec la réponse Le vérifieur vérifie la connaissance du secret grâce au test . En effet, on a : . L’ensemble des données intervenant dans ces calculs se présentent sous la forme de grands nombres. Souvent la valeur prise pour e est 2 mais d’autres valeurs entières de e peuvent être utilisées. Le protocole de Fiat-Shamir donne lieu à de nombreuses variantes et optimisations connues à l’homme de l’art. Ces variantes permettent notamment de diminuer la taille de x ou des v i ou de réduire k en répétant le protocole t fois afin d’attendre un niveau de sécurité de 2 -tk . Le niveau de sécurité exprime la probabilité qu’une entité ne connaissant pas sk puisse quand-même passer le protocole et convaincre le vérifieur qu’elle détient sk. La plupart des ZKPs repose sur un tel Σ-protocole (i.e. un protocole d’échange similaire à trois passes (ou davantage) comme expliqué avant) consistant à échanger successivement les données x, c, y entre les parties. La définition de ces x, c, y varie en fonction du problème difficile sous-jacent à la sécurité de la ZKP mais le schéma de communication à trois passes reste le même. Il est toutefois connu que les -protocoles présentent un inconvénient du à leur interactivité : si le vérificateur se comporte de manière malhonnête, il peut garder une trace de son interaction avec le prouveur et ainsi ne plus permettre à ce dernier de « nier » l’interaction, alors qu’une telle niabilité est particulièrement désirable dans de nombreux scénarios. Pour reformuler, la ZKP doit être niable de sorte que les traces collectées par le vérifieur ne puissent pas prouver l’implication du prouveur : ces traces doivent pouvoir avoir été générées sans l’aide du prouveur. Sinon, la preuve n’est pas totalement à divulgation nulle de connaissance. Pour revenir à l’exemple de la prescription médicale anonyme, le patient peut vouloir ne laisser aucune preuve de l’interaction avec le médecin et pouvoir nier de telles interactions dans le futur. Si la ZKP n’est pas niable, un médecin souhaitant frauduleusement collecter une preuve de l’interaction avec la carte vitale du patient pourrait y parvenir. En effet, le vérifieur peut dériver le défi c à partir de H(x), par exemple en puisant les chiffres c i constituant c dans H(x), au lieu de les choisir aléatoirement. La réponse y produite par le prouveur ne serait alors pas niable car elle démontre la participation du prouveur au Σ-protocole, à moins qu’elles puissent avoir été générées autrement. On peut montrer que la probabilité P k (w) qu'un vérifieur investissant une charge de travail w (exprimée en nombre d’opérations de hachage) puisse faussement prétendre que le prouveur a participé à la session (i.e. que les traces aient été générées sans l’intervention du prouveur) vaut P k (w) = 1 - (1 - ½ k ) w . Dès que (la taille de la clé privée en bits) est large (par exemple ), le nombre d’opérations w nécessaire à atteindre une probabilité de ½ est démesurée (2 80 opérations). On conclut donc qu’il est impossible que les traces puissent avoir été générées sans l’intervention du prouveur, et donc la ZKP n’est pas niable. Malheureusement, la Demanderesse a constaté que le vérifieur pouvait également y parvenir même pour des valeurs de k plus faibles (par exemple 20). Pour ce faire, il lui suffit de dériver de la fonction de hachage H une fonction de hachage artificiellement ralentie H’ (de sorte à augmenter la charge de travail). Pour ralentir la fonction H’, le vérifieur pourrait par exemple, itérer H sur son entrée u fois, pour une valeur de u suffisamment large. En d’autres termes H’(x) = H(H(H(H(H…(H(x)))…). Le temps de calcul de H’ se trouve ainsi ralenti par un facteur u (puisque qu’il faut faire u fois plus d’opérations de hachage). Comme application numérique, soit u = 2 40 et k = 40, le nombre d’opérations w nécessaire à atteindre une probabilité P k (w) de ½ (on répète que c’est probabilité qu’un vérifieur puisse faussement prétendre que le prouveur a participé à une session, i.e. ait généré les traces sans intervention du prouveur) est w = 7.6×10 11 ×u ≃ 2 39.5 ×u = 2 79.5 ce qui est toujours irréalisable bien que k soit deux fois plus faible. La preuve n’est donc pas niable Même avec k = 20, en prenant u = 2 45 , le nombre d’opérations w nécessaire à atteindre une probabilité P k (w) de ½ est w = 726817u ≃ 2 19.5 ×u=2 64.5 opérations de hachage, ce qui, encore une fois, reste un effort démesuré lient clairement le prouveur à la trace. La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé pour la mise en œuvre d’une transaction entre un premier équipement dit de preuve, et un deuxième équipement dit de vérification, comprenant la mise en œuvre d’étapes de : Génération, par des moyens de traitement de données du premier équipement, de paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à ladite transaction, et transmission audit deuxième équipement des paramètres généraux et de la clé publique mais pas de la clé privée ; Vérification, par des moyens de traitement de données du deuxième équipement, de la connaissance de ladite clé privée par le premier équipement en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre dudit Σ-protocole. Si la connaissance de ladite clé privée par le premier équipement est vérifiée, mise en œuvre de ladite transaction par ledit deuxième équipement ; Le procédé étant caractérisé en ce que ladite étape (b) comprend, avant la mise en œuvre (b2, b3, b4) dudit Σ-protocole, la transmission préalable (b1) au premier équipement d’une valeur d’engagement d’une valeur de défi dudit Σ-protocole. Selon des caractéristiques avantageuses et non limitatives : Ladite étape (b) comprend, lors de la mise en œuvre dudit Σ-protocole, la réception (b2) depuis le premier équipement, d’une valeur d’engagement du Σ-protocole, la transmission (b3) au premier équipement de ladite valeur de défi dudit Σ-protocole, la transmission (b4) depuis le premier équipement d’une valeur de réponse dudit Σ-protocole, et la vérification (b5) de la cohérence desdites valeur d’engagement dudit Σ-protocole, valeur de défi dudit Σ-protocole, valeur de réponse dudit Σ-protocole, et clé publique. Ladite valeur de réponse dudit Σ-protocole est calculée par les moyens de traitement de données du premier équipement en fonction d’au moins ladite valeur de défi et ladite clé privée. L’étape (b) comprend après la transmission (b3) de ladite valeur de défi dudit Σ-protocole, la vérification (b3’) par les moyens de traitement de données du premier équipement que ladite valeur de défi correspond à la valeur d’engagement de ladite valeur de défi préalablement reçue. La transmission (b4) de la valeur de réponse dudit Σ-protocole est conditionnée au résultat de la vérification (b3’) que ladite valeur de défi correspond à la valeur d’engagement de ladite valeur de défi préalablement reçue. La transmission préalable (b1) de la valeur d’engagement de la valeur de défi dudit Σ-protocole est conditionnée à la transmission audit deuxième équipement d’une requête de niabilité de ladite preuve à divulgation nulle de connaissance. La valeur d’engagement de la valeur de défi est une empreinte cryptographique de ladite valeur de défi selon une fonction de hachage donnée. La valeur d’engagement dudit Σ-protocole et/ou la valeur de défi dudit Σ-protocole est une valeur dérivée d’une valeur générée aléatoirement, respectivement par les moyens de traitement de données du premier équipement ou du deuxième équipement. Ledit Σ-protocole est choisi parmi le protocole de Fiat-Shamir, le protocole de Guillou-Quisquater, le protocole de Schnorr et le protocole RSA. La taille du défi est comprise entre 10 et 160 bits. Selon un deuxième aspect, l’invention concerne un ensemble d’un premier terminal, dit prouveur, et d’un deuxième terminal, dit vérifieur, comprenant respectivement des moyens de traitement de données, caractérisé en ce que : Les moyens de traitement de données du premier équipement sont configurés pour générer des paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à une transaction à mettre en œuvre entre le premier terminal et le deuxième terminal, et transmettre audit deuxième équipement les paramètres généraux et la clé publique mais pas la clé privée ; Les moyens de traitement de données du deuxième équipement sont configurés pour : vérifier la connaissance de ladite clé privée par le premier équipement en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre dudit Σ-protocole ; Si la connaissance de ladite clé privée par le premier équipement est vérifiée, mettre en œuvre ladite transaction ; Les moyens de traitement de données du deuxième équipement étant en outre configurés pour, avant la mise en œuvre dudit Σ-protocole, transmettre préalablement au premier équipement 1 une valeur d’engagement d’une valeur de défi dudit Σ-protocole. Selon un troisième et un quatrième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction entre un premier équipement dit de preuve, et un deuxième équipement dit de vérification ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction entre un premier équipement dit de preuve, et un deuxième équipement dit de vérification. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention ; FIG. 3 la FIG. 3 représente schématiquement la mise en œuvre d’un mode de réalisation de l’étape (b) du procédé d’authentification dans le système de la FIG. 1 . DESCRIPTION DÉTAILLÉE Architecture En référence à la FIG. 1 , on a représenté schématiquement un système pour la mise en œuvre du présent procédé de traitement d’une transaction. Le système comprend au moins deux équipements 1, 2. Le premier équipement 1, dit de preuve, est avantageusement un équipement personnel à un individu, comme par exemple son téléphone mobile, tel qu’un smartphone, une tablette électronique ou encore un ordinateur personnel, voire directement une carte à puce (notamment une carte de paiement ou une carte de santé type care vitale), et de façon générale un équipement client via lequel l’utilisateur souhaite initier la transaction. Le deuxième équipement 2, dit de vérification, est détenu et contrôlé par une entité auprès de qui la transaction doit être effectuée. Sa nature dépend de la transaction souhaitée, ce peut être un TPE, un serveur bancaire, un dispositif de contrôle d’accès, un lecteur de carte, etc. Par « transaction » on entend au sens large tout échange dans lequel l’entité de preuve 1 requiert la mise en œuvre d’une action par l’entité de vérification 2 en échange d’une donnée, ou du moins d’une information sur ladite donnée, qui est préférentiellement une donnée personnelle que l’on ne souhaite pas publier (information liée à l’identité ou à des droits, information bancaire, information sensible, etc.). La transaction est ainsi avantageusement une authentification ou une identification d’un individu détenteur du premier équipement 1 auprès du deuxième équipement 2 (sur la base d’un document d’identité ou d’une donnée biométrique notamment) mais également une transaction financière entre les équipements 1 et 2 (paiement par carte par exemple directement chez le marchand, ou en ligne, mais également virement, blockchain, etc.), un contrôle d’accès du détenteur du premier équipement 1 à un produit, un service ou un lieu contrôlé par le second équipement 2, etc. Dans notre exemple du médecin et du patient, la donnée personnelle est une donnée médicale et la transaction est la délivrance d’une ordonnance. On comprendra néanmoins que le présent procédé n’est limité à aucune transaction en particulier. Dans tous les cas c’est le deuxième équipement 2 qui met en œuvre la transaction (ou la rejette) par exemple en mettant en œuvre une action logicielle (telle que l’ouverture d’une session) ou physique (telle que l’ouverture d’une porte). Classiquement, ladite donnée nécessaire à la transaction serait transmise au deuxième équipement 2, et c’est ce dernier qui la vérifiait, et accepterait la mise en œuvre de la transaction si le résultat de la vérification est concluant. Dans le présent contexte de preuve à divulgation nulle de connaissance, le premier équipement 1 va garder secrète ladite donnée. Le premier équipement 1 et le deuxième équipement 2 comportent des moyens de traitement de données 11, 21, i.e. un calculateur tel que par exemple un processeur, un microprocesseur, un contrôleur, un microcontrôleur, un FPGA etc. Ces calculateurs sont adaptés pour exécuter des instructions de code pour mettre en œuvre le procédé ci-après. Le premier équipement 1 et/ou le deuxième équipement 2 peuvent également comprendre des moyens de stockage de données 12, 22 (une mémoire, par exemple flash) éventuellement une interface utilisateur (typiquement un écran tactile), etc. A noter que les premiers et deuxième équipements 1, 2 peuvent être directement connectés (cas d’une carte dans le lecteur), mais également à distance (le deuxième équipement 2 peut être un serveur distant), via un réseau 20 tel que le réseau internet, comme représenté sur la FIG. 1 . Procédé En référence à la FIG. 2 , le présent procédé, mis en œuvre par les moyens de traitement de données 11, 21 des deux équipement 1, 2 agissant de manière interactive, commence classiquement par une étape (a) de génération, par les moyens de traitement de données 11 du premier équipement 1, de paramètres généraux et de clés publiques et privées (notés respectivement {par, pk, sk}) d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, nécessaires à ladite transaction. sk (ou une donnée en dérivant) constitue un secret dont on va prouver la possession. Dans la suite de la présente description, on considèrera par commodité sk comme étant ledit secret. Avantageusement, dans l’étape (a) le premier équipement fixe le niveau de sécurité en définissant la taille k des clés (on rappelle que le niveau de sécurité exprime la probabilité qu’une entité ne connaissant pas puisse quand-même passer le protocole et convaincre le vérifieur qu’elle détient sk). On prendra typiquement pour k une valeur comprise entre 20 et 80 bits, le niveau de sécurité étant alors de 2 -k . Comme l’on verra le présent procédé va permettre une niabilité de la preuve quel que soit k (même pour de grandes valeurs). L’étape (a) comprend en outre la transmission audit deuxième équipement 2 des paramètres généraux et de la clé publique mais pas de la clé privée bien entendu. La cryptographie asymétrique définit ces deux clés : une clé publique "pk" connue de tous (notamment du deuxième équipement 2) et une clé privée "sk" gardée confidentielle (par le premier équipement 1). Cette propriété est également vraie pour les ZKPs. De manière connue, la réalisation d’une preuve interactive à divulgation nulle de connaissance comporte deux phases : une phase de génération de clés et de paramètres (qui correspond à l’étape (a), et qui est bien connu de l’homme du métier) et une phase d’interaction (qui correspond à l’étape (b) qui sera décrite plus loin, et qui est originale). L’algorithme de génération de clés et de paramètres permet audit premier équipement de générer les clés pk et sk et les paramètres nécessaires au fonctionnement de la ZKP. Cet algorithme est supposé accessible à tous et public. La phase suivante permet audit deuxième équipement 2 de prouver la connaissance du secret sk sans le dévoiler. Cet algorithme est également supposé accessible à tous et public. Ledit protocole de preuve à divulgation nulle de connaissance est de type Σ-protocole comme évoqué avant. On pourra citer le protocole de Fiat-Shamir, mais également le protocole de Guillou-Quisquater, le protocole de Schnorr, notamment, mis en œuvre sur une courbe elliptique, etc. Ledit Σ-protocole peut alternativement tout à fait être une signature RSA. L’homme du métier pourra utiliser tout Σ-protocole connu. On comprend que lesdits paramètres généraux et clés publiques et privées sont liés à ladite transaction, i.e. leur génération est spécifique à ladite transaction visée et à la donnée personnelle impliquée. A titre d’exemple classique, la clé privée peut permettre au premier équipement 2 de signer des données descriptives de la transaction, et le détenteur du deuxième équipement 2 pourra se convaincre que le détenteur du premier équipement 1 dispose bien de cette clé privée sans connaître son identité. On répète que cette étape (a) pourra être mise en œuvre de toute façon connue de l’homme du métier, selon le type de preuve considéré et le type de transaction envisagé. Le présent procédé se distingue en effet par une astuce lors de la phase ultérieure d’interaction qui rend la preuve parfaitement niable, et que l’homme du métier saura appliquer à tout Σ-protocole et à toute transaction. Ainsi, le procédé comprend ensuite l’étape principale (b) représentée sur la FIG. 3 de vérification, par les moyens de traitement de données 21 du deuxième équipement 2, de la connaissance de ladite clé privée par le premier équipement 1 en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre (b2, b3, b4) dudit Σ-protocole. On note que la vérification en elle-même est bien faite (et conclue) du coté deuxième équipement, mais que le Σ-protocole en lui-même est interactif et implique donc les deux équipements 1 et 2. Par Σ-protocole on entend comme expliqué un protocole interactif connu de l’homme du métier met en jeu trois échanges : engagement, défi et réponse. Pour reformuler, l’étape (b) comprend une pluralité de sous-étapes dont trois (b2), (b3) et (b4) qui sont les trois échanges du Σ-protocole. En d’autre termes, ladite étape (b) comprend, lors de la mise en œuvre dudit Σ-protocole : la réception (b2) depuis le premier équipement 1, d’une valeur d’engagement du Σ-protocole (notée x), la transmission (b3) au premier équipement 1 d’une valeur de défi dudit Σ-protocole (notée c), la transmission (b4) depuis le premier équipement 1 d’une valeur de réponse dudit Σ-protocole (notée y). En outre, l’étape (b) comprend la vérification (b5), par les moyens de traitement 21 du deuxième équipement 2, de la cohérence desdites valeur d’engagement dudit Σ-protocole, valeur de défi dudit Σ-protocole, valeur de réponse dudit Σ-protocole, et clé publique. En d’autres termes, il s’agit de vérifier la valeur de réponse y reçue par rapport aux autres valeurs déjà obtenues (x, c, pk, par), généralement en appliquant une formule (dépendant du Σ-protocole) à x, c, pk, par, et en vérifiant qu’on retrouve bien y. On comprend que cette étape est déterminée par le Σ-protocole, et on verra des exemples plus loin. Si ladite cohérence est vérifiée, alors la preuve est vérifiée, i.e. le deuxième équipement se convainc de la connaissance de ladite clé privée par le premier équipement 1. En d’autres termes, la connaissance de ladite clé privée par le premier équipement 1 est vérifiée si la cohérence desdites valeur d’engagement dudit Σ-protocole, valeur de défi dudit Σ-protocole, valeur de réponse dudit Σ-protocole, et clé publique est vérifiée. Les sous-étapes (b2), (b3), (b4) et (b5) pourront être mises en œuvre de manière classique. En particulier, la valeur d’engagement x dudit Σ-protocole et/ou la valeur de défi c dudit Σ-protocole est préférentiellement une valeur dérivée d’une valeur générée aléatoirement (encore préférentiellement chacune des deux), potentiellement directement une valeur générée aléatoirement (en particulier le défi c – la valeur d’engagement est généralement dérivée d’un aléa r), respectivement par les moyens de traitement de données 11, 21 du premier équipement 1 ou du deuxième équipement 2. La taille du défi est généralement comprise entre 10 et 160, en particulier entre 60 et 100 voire autour de 80, préférentiellement une taille similaire à la taille k de la clé sécrète, de sorte à garantir un bon compromis entre temps de calcul et sécurité. De même, ladite valeur de réponse dudit Σ-protocole est préférentiellement calculée (à la sous-étape (b4), préalablement à sa transmission) par les moyens de traitement de données 11 du premier équipement 1 en fonction d’au moins ladite valeur de défi et ladite clé privée, conformément audit Σ-protocole. Comme expliqué, le problème est que l’on veut justement s’assurer que la valeur de défi c est bien générée aléatoirement, ou du moins pas en fonction de ladite valeur d’engagement x. Pour ce faire, le présent procédé propose de forcer le deuxième équipement 2 à la générer avant la réception de la valeur d’engagement x. A ce titre, ladite étape (b) comprend, avant la mise en œuvre (b2, b3, b4) dudit Σ-protocole, une sous-étape (b1) mise en œuvre par les moyens de traitement de données 21 du deuxième équipement 2, la transmission préalable au premier équipement 1 d’une valeur d’engagement (notée Eng(c)) d’une valeur de défi dudit Σ-protocole. Il ne faut pas confondre la valeur d’engagement x du Σ-protocole avec cette valeur d’engagement Eng(c) de la valeur de défi c (qui ne fait pas partie du Σ-protocole). L’idée est que cette valeur d’engagement de la valeur de défi ne révèle pas la valeur de défi, mais permet de s’assurer que la valeur de défi a bien été générée à ce stade, i.e. avant (b2), et donc pas en fonction de la valeur d’engagement x. De manière préférée, la valeur d’engagement de la valeur de défi est simplement une empreinte cryptographique de ladite valeur de défi selon une fonction de hachage donnée, i.e. Eng(c) = H(c). On rappelle que par « empreinte cryptographique » d’une donnée (appelé également « condensat » ou « haché » de la donnée, de l’anglais « hash »), obtenue en appliquant une fonction de hachage cryptographique à la donnée (typiquement des familles SHA-1 ou SHA-2, en particulier SHA-256). L’empreinte a une taille fixe et ne révèle rien sur la donnée dont elle est issue : on ne peut pas retrouver la donnée d’origine à partir de cette empreinte, en tout cas tant que la fonction de hachage utilisée est considérée comme sûre. On peut cependant recalculer l’empreinte à partir de la donnée pour vérifier qu’elle est correcte. Ainsi, de manière préférée, la sous-étape (b1) comprend la génération préalable (préférentiellement aléatoirement) de la valeur de défi c dudit Σ-protocole, puis la génération de ladite valeur d’engagement Eng(c) de cette valeur de défi c (en particulier par hachage de cette valeur de défi), toujours mises en œuvre par les moyens de traitement de données 21 du deuxième équipement 2. Par comparaison, cette génération de la valeur de défi c dudit Σ-protocole était traditionnelle mise en œuvre pendant le Σ-protocole, i.e. dans la sous-étape (b3). La sous-étape (b2) peut par contre toujours comprendre la génération préalable (préférentiellement toujours en la dérivant d’une valeur d’aléa r générée aléatoirement) de la valeur d’engagement x dudit Σ-protocole. De manière préférée, l’étape (b) comprend après la transmission (b3) de ladite valeur de défi dudit Σ-protocole, une sous-étape (b3’) de vérification par les moyens de traitement de données 11 du premier équipement 1 que ladite valeur de défi c correspond à (au sens est cohérent avec) la valeur d’engagement Eng(c) de ladite valeur de défi préalablement reçue. Il s’agit seulement de mettre en œuvre une procédure Ouvre(c, Eng(c)) telle qu’évoquée dans l’introduction, i.e. la vérification de c qui a été reçue dans la sous-étape (b3) connaissant Eng(c) préalablement reçu. Cette vérification se fait typiquement en recalculant Eng(c) à partir de c, et en comparant à la valeur reçue à la sous-étape (b1), qui est la valeur attendue. Dans le cas d’une fonction de hachage, il s’agit tout simplement de calculer l’empreinte cryptographique de la valeur de défi c reçue. Par conséquent, la transmission (b4) de la valeur de réponse dudit Σ-protocole peut être conditionnée au résultat de la vérification (b3’) que ladite valeur de défi correspond à (au sens est cohérent avec) la valeur d’engagement de ladite valeur de défi préalablement reçue. En d’autres termes : si le premier équipement 1 constate que ladite valeur de défi c correspond à la valeur d’engagement Eng(c) de ladite valeur de défi préalablement reçue, alors il a l’assurance que le deuxième équipement 2 est honnête et que la preuve sera niable, et donc il met en œuvre la sous-étape (b4) de sorte à répondre au défi ; si au contraire le premier équipement 1 constate que ladite valeur de défi (qu’on notera alors c’) ne correspond pas à la valeur d’engagement Eng(c) de ladite valeur de défi préalablement reçue, i.e. a été transmise une nouvelle valeur de défi c’ ≠ c à laquelle correspond une valeur d’engagement Eng(c’) ≠ Eng(c), le premier équipement 1 peut suspecter une fraude (potentiel changement en cours de route de la valeur de défi de sorte à se baser sur x pour prévenir la niabilité) et interrompre le procédé en ne répondant pas au défi (pas de mise en œuvre de la sous-étape (b4) – à noter que la réponse y peut être quand même générée mais pas transmise). Selon un premier exemple conforme au protocole Fiat-Shamir (où suite à l’étape (a) la clé publique pk = {n, e, v 1 , …, v k } et la clé privée sk = {s 1 , …, s k } est définie s i e v i = 1 mod n, le nombre n = pq étant le produit de deux grand nombres premiers), l’étape (b) comprend de manière préférée les sous-étapes suivantes : (b1) les moyens 21 du deuxième équipement 2 génèrent un défi aléatoire c composé de k chiffres c = c 1 |c 2 |…|c k en base e (en d’autres termes 0 ≤ c i ≤ e-1), préparent un engagement sur c noté Eng(c) et transmettent Eng(c) au premier équipement 1. (b2) les moyens 11 du premier équipement 1 génèrent un aléa r et transmettent au deuxième équipement 2 une valeur d’engagement x=r e mod n. (b3) le deuxième équipement 2 réplique avec c (déjà généré). (b3’) les moyens 11 du premier équipement 1 vérifient la cohérence entre c et Eng(c). Si Eng(c) n’est pas un engagement valide sur c, le premier équipement 1 interrompt le protocole. (b4) Si Eng(c) est un engagement valide sur c, les moyens 21 du premier équipement 1 transmettent au vérifieur la réponse (b5) les moyens 21 du deuxième équipement 2 vérifient la connaissance du secret par le premier équipement 1 grâce au test . Selon un deuxième exemple conforme au protocole RSA (où suite à l’étape (a) la clé publique pk = {n, E} et la clé privée sk = D), l’étape (b) comprend de manière préférée les sous-étapes suivantes : (b1) les moyens 21 du deuxième équipement 2 génèrent un défi aléatoire c, préparent un engagement sur c noté Eng(c) et transmettent Eng(c) au premier équipement 1. (b2) les moyens 11 du premier équipement 1 génèrent un aléa r et transmettent au deuxième équipement 2 la valeur d’engagement r. (b3) le deuxième équipement 2 réplique avec c (déjà généré). (b3’) les moyens 11 du premier équipement 1 vérifient la cohérence entre c et Eng(c). Si Eng(c) n’est pas un engagement valide sur c, le premier équipement 1 interrompt le protocole. (b4) Si Eng(c) est un engagement valide sur c, les moyens 21 du premier équipement 1 transmettent au vérifieur la réponse y = {y 1 , y 2 } = {r, (r⊕c) D mod n} (b5) les moyens 21 du deuxième équipement 2 vérifient la connaissance du secret sk par le premier équipement 1 grâce au test y 1 ⊕c = y 2 E mod n. On note que l’opérateur ⊕ (« ou exclusif » ou XOR) peut être remplacé par une variété d’autres fonctions permettant de combiner r et c. On note que dans tous les cas la transmission préalable (b1) de la valeur d’engagement de la valeur de défi dudit Σ-protocole peut être elle-même conditionnée à la transmission audit deuxième équipement 2 peut être conditionnée à une requête de niabilité de ladite preuve à divulgation nulle de connaissance. En d’autres termes, le premier équipement 1 peut transmettre au deuxième équipement 2 (par exemple à la fin de l’étape (a), notamment avec des paramètres généraux et la clé publique) une telle requête de niabilité de la preuve à divulgation nulle de connaissance de sorte à contraindre le deuxième équipement 2 à s’adapter (et à agir conformément au présent procédé). Si une telle requête est émise, alors le deuxième équipement 2 doit mettre en œuvre l’étape (b1) de la transmission préalable de la valeur d’engagement d’une valeur de défi dudit Σ-protocole. S’il ne le fait pas, le premier équipement 1 peut considérer que le deuxième équipement est malhonnête (risque qu’il génère c en fonction de x) et refuser de poursuivre. Si une telle requête n’est pas émise (i.e. le premier équipement ne tient pas plus que ça à la niabilité et accepte le risque de laisser des traces), l’étape (b) peut être mise en œuvre de manière classique (génération de c mise en œuvre pendant le Σ-protocole, i.e. dans la sous-étape (b3)). Il peut alternativement être prévu que la sous-étape (b1) soit mise en œuvre par défaut (i.e. tout le temps sans forcément attendre une requête). Enfin, dans une étape (c) finale, le procédé comprend, si la connaissance de ladite clé privée par le premier équipement 1 est vérifiée, la mise en œuvre de ladite transaction par ledit deuxième équipement 2. En d’autres termes les moyens de traitement de données 21 commandent une action correspondant à la transaction, telle que l’ouverture d’une session ou d’une porte. Inversement, si la connaissance de ladite clé privée par le premier équipement 1 n’est pas vérifiée (par exemple si la réponse y reçue du Σ-protocole n’est pas cohérente), alors au contraire la transaction est rejetée. Parmi les nombreux avantages apportés par la présente invention, nous pouvons mentionner que : Le vérifieur acquiert la certitude que le prouveur dispose bien du secret sk mais ne peut collecter aucune preuve de son interaction avec ce dernier; Le protocole de preuve à divulgation nulle de connaissance selon l’invention est particulièrement optimisé et performant puisque les algorithmes mis en œuvre dans la cadre de l’invention nécessitent peu d’opérations pour mémoriser et exécuter les deux étapes (a) et (b) alliant ainsi hautes performances d’exécution et préservation des capacités de stockage des premier et deuxième équipements 1, 2. De plus, le nombre d’instructions du code nécessaire à la réalisation de l’invention de manière logicielle ou le nombre de portes logiques nécessaires à la réalisation de l’invention de manière matérielle sont très faibles. Similairement la bande passante nécessaire est très faible ; Enfin, le présent procédé est parfaitement compatible avec les protocoles de preuve à divulgation nulle de connaissance de type Σ-protocole connus et s’ajoute comme une couche haute par-dessus ces derniers. Equipements Selon un deuxième aspect, l’invention concerne l’ensemble du premier et du deuxième équipements 1,2 pour la mise en œuvre du procédé selon le premier aspect. Le premier équipement 1 et le deuxième équipement 2 comprennent respectivement des moyens de traitement de données 11, 21 et des moyens de stockage de données 12, 22. Les moyens de traitement de données 11 du premier équipement 1 sont configurés pour générer des paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à une transaction à mettre en œuvre entre le premier terminal 1 et le deuxième terminal 2, et transmettre audit deuxième équipement 2 les paramètres généraux et la clé publique mais pas la clé privée. Les moyens de traitement de données 21 du deuxième équipement 1 sont configurés pour : vérifier la connaissance de ladite clé privée par le premier équipement 1 en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre dudit Σ-protocole (i.e. les moyens 21 sont configurés pour mettre en œuvre le Σ-protocole) ; Si la connaissance de ladite clé privée par le premier équipement 1 est vérifiée, mettre en œuvre ladite transaction ; et avant la mise en œuvre dudit Σ-protocole, transmettre préalablement au premier équipement 1 une valeur d’engagement d’une valeur de défi dudit Σ-protocole. Produit programme d’ordinateur Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11, 21 des équipements 1, 2) d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction entre un premier équipement 1 dit de preuve, et un deuxième équipement 2 dit de vérification ; et un moyen de stockage (par exemple les moyens de stockage de données 12, 22 des équipements 1, 2) sur lequel on trouve ce produit programme d’ordinateur. Procédé pour la mise en œuvre d’une transaction entre un premier équipement (1) dit de preuve, et un deuxième équipement (2) dit de vérification, comprenant la mise en œuvre d’étapes de : Génération, par des moyens de traitement de données (11) du premier équipement (1), de paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à ladite transaction, et transmission audit deuxième équipement (2) des paramètres généraux et de la clé publique mais pas de la clé privée ; Vérification, par des moyens de traitement de données (21) du deuxième équipement (2), de la connaissance de ladite clé privée par le premier équipement (1) en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre (b2, b3, b4) dudit Σ-protocole. Si la connaissance de ladite clé privée par le premier équipement (1) est vérifiée, mise en œuvre de ladite transaction par ledit deuxième équipement (2) ; Le procédé étant caractérisé en ce que ladite étape (b) comprend, avant la mise en œuvre (b2, b3, b4) dudit Σ-protocole, la transmission préalable (b1) au premier équipement (1) d’une valeur d’engagement d’une valeur de défi dudit Σ-protocole. Procédé selon la revendication 1, dans lequel ladite étape (b) comprend, lors de la mise en œuvre dudit Σ-protocole, la réception (b2) depuis le premier équipement (1), d’une valeur d’engagement du Σ-protocole, la transmission (b3) au premier équipement (1) de ladite valeur de défi dudit Σ-protocole, la transmission (b4) depuis le premier équipement (1) d’une valeur de réponse dudit Σ-protocole, et la vérification (b5) de la cohérence desdites valeur d’engagement dudit Σ-protocole, valeur de défi dudit Σ-protocole, valeur de réponse dudit Σ-protocole, et clé publique. Procédé selon la revendication 2, dans lequel ladite valeur de réponse dudit Σ-protocole est calculée par les moyens de traitement de données (11) du premier équipement (1) en fonction d’au moins ladite valeur de défi et ladite clé privée. Procédé selon l’une des revendications 2 et 3, dans lequel l’étape (b) comprend après la transmission (b3) de ladite valeur de défi dudit Σ-protocole, la vérification (b3’) par les moyens de traitement de données (11) du premier équipement (1) que ladite valeur de défi correspond à la valeur d’engagement de ladite valeur de défi préalablement reçue. Procédé selon la revendication 4, dans laquelle la transmission (b4) de la valeur de réponse dudit Σ-protocole est conditionnée au résultat de la vérification (b3’) que ladite valeur de défi correspond à la valeur d’engagement de ladite valeur de défi préalablement reçue Procédé selon l’une des revendications 1 à 5, dans lequel la transmission préalable (b1) de la valeur d’engagement de la valeur de défi dudit Σ-protocole est conditionnée à la transmission audit deuxième équipement (2) d’une requête de niabilité de ladite preuve à divulgation nulle de connaissance. Procédé selon l’une des revendications 1 à 7, dans lequel la valeur d’engagement de la valeur de défi est une empreinte cryptographique de ladite valeur de défi selon une fonction de hachage donnée. Procédé selon l’une des revendications 1 à 7, dans lequel la valeur d’engagement dudit Σ-protocole et/ou la valeur de défi dudit Σ-protocole est une valeur dérivée d’une valeur générée aléatoirement, respectivement par les moyens de traitement de données (11, 21) du premier équipement (1) ou du deuxième équipement (2). Procédé selon l‘une des revendications 1 à 8, dans lequel ledit Σ-protocole est choisi parmi le protocole de Fiat-Shamir, le protocole de Guillou-Quisquater, le protocole de Schnorr et un protocole basé sur RSA. Procédé selon l‘une des revendications 1 à 8, dans lequel la taille du défi est comprise entre 10 et 160 bits. Ensemble d’un premier terminal (1), dit prouveur, et d’un deuxième terminal (2), dit vérifieur, comprenant respectivement des moyens de traitement de données (11, 21), caractérisé en ce que : Les moyens de traitement de données (11) du premier équipement (1) sont configurés pour générer des paramètres généraux et de clés publiques et privées d’un protocole de preuve à divulgation nulle de connaissance de type Σ-protocole, liés à une transaction à mettre en œuvre entre le premier terminal (1) et le deuxième terminal (2), et transmettre audit deuxième équipement (2) les paramètres généraux et la clé publique mais pas la clé privée ; Les moyens de traitement de données (21) du deuxième équipement (2) sont configurés pour : vérifier la connaissance de ladite clé privée par le premier équipement (1) en fonction desdits paramètres généraux et clé publique, ladite vérification comprenant la mise en œuvre dudit Σ-protocole ; Si la connaissance de ladite clé privée par le premier équipement (1) est vérifiée, mettre en œuvre ladite transaction ; Les moyens de traitement de données (21) du deuxième équipement (2) étant en outre configurés pour, avant la mise en œuvre dudit Σ-protocole, transmettre préalablement au premier équipement 1 une valeur d’engagement d’une valeur de défi dudit Σ-protocole. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 pour la mise en œuvre d’une transaction entre un premier équipement (1) dit de preuve, et un deuxième équipement (2) dit de vérification, lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 pour la mise en œuvre d’une transaction entre un premier équipement (1) dit de preuve, et un deuxième équipement (2) dit de vérification.