FR3092923A1 - Méthode cryptographique de vérification des données - Google Patents

Méthode cryptographique de vérification des données Download PDF

Info

Publication number
FR3092923A1
FR3092923A1 FR1901648A FR1901648A FR3092923A1 FR 3092923 A1 FR3092923 A1 FR 3092923A1 FR 1901648 A FR1901648 A FR 1901648A FR 1901648 A FR1901648 A FR 1901648A FR 3092923 A1 FR3092923 A1 FR 3092923A1
Authority
FR
France
Prior art keywords
data
hash
message
function
shuffle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1901648A
Other languages
English (en)
Other versions
FR3092923B1 (fr
Inventor
Bruno SANGLE-FERRIERE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR1901648A priority Critical patent/FR3092923B1/fr
Application filed by Individual filed Critical Individual
Priority to EP20704320.9A priority patent/EP3928232A1/fr
Priority to KR1020217026080A priority patent/KR20210153595A/ko
Priority to AU2020225314A priority patent/AU2020225314A1/en
Priority to PCT/EP2020/054126 priority patent/WO2020169542A1/fr
Priority to CA3128869A priority patent/CA3128869A1/fr
Priority to JP2021549168A priority patent/JP2022521525A/ja
Priority to CN202080015504.4A priority patent/CN113811874A/zh
Priority to US16/793,123 priority patent/US11914754B2/en
Priority to US16/934,376 priority patent/US11956367B2/en
Publication of FR3092923A1 publication Critical patent/FR3092923A1/fr
Application granted granted Critical
Publication of FR3092923B1 publication Critical patent/FR3092923B1/fr
Priority to US18/072,962 priority patent/US20240089240A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD

Abstract

Méthode cryptographique de vérification des données Procédé de comparaison mis en œuvre par au moins un appareil (A ; B), entre un premier et deuxième ensemble de données, en vue notamment de déterminer si ces deux ensembles de données sont identiques, ce procédé ne nécessitant pas la présence de ces deux ensembles de données sur l’appareil, et comportant les étapes suivantes : le mélange d’un nombre, dit nombre de mélange, au premier ensemble de données, à l’aide d’une fonction de mélange (105 ; 405), pour obtenir des données mélangées, le hachage des données mélangées à l’aide d’une fonction de hachage (106 ; 406), et la comparaison du haché ainsi obtenu à l’étape b) avec un troisième ensemble de données supposé être le haché du deuxième ensemble de données mélangé au même nombre de mélange que celui utilisé à l’étape a) et avec la même fonction de mélange (105 ; 405). Figure pour l’abrégé : Fig. 2

Description

Méthode cryptographique de vérification des données
La présente invention concerne la cryptographie numérique et la sécurité des dispositifs informatiques et électroniques, en particulier les signatures numériques.
Les ordinateurs et les appareils électroniques sont souvent connectés sur un réseau, physiquement, sans fil, par RFID, ou par tout autre moyen sécurisé ou non, et ont parfois besoin de connaître l’identité de l’appareil qui leur a envoyé certaines données, par exemple pour s’assurer que ces données ne sont pas transmises par un autre appareil, qui les aurait interceptées et modifiées avant de les renvoyer au destinataire légitime, ou tout simplement pour identifier sans aucun doute l'identité de l'expéditeur des données, qui est par exemple une voiture sur un réseau routier ou une étiquette RFID portée par un concurrent lors d’un événement sportif, ou pour toute autre raison pour laquelle l’identité de l’expéditeur des données est importante pour le destinataire.
Les données transmises peuvent être envoyées entièrement chiffrées avec une clé attribuée à l'expéditeur. Cependant, le cryptage de l'intégralité des données rend difficile l'utilisation des clés à usage unique, appelées« One Time Pads »en anglais. En effet, le cryptage de l’intégralité des données est une méthode qui utilise des clés aussi longues que les données qu'elles cryptent, et ces clés doivent être renouvelées après utilisation.
Il est donc nécessaire que les ordinateurs ou autres dispositifs électroniques entrant en communication vérifient l'identité du dispositif d'envoi en utilisant le cryptage d’une quantité de données inférieure à la quantité de données envoyées. C’est pour cela qu’on utilise une signature électronique consistant à chiffrer un haché des données. On appelle « haché » le résultat d’une fonction de hachage qui, à partir d'une donnée initiale fournie en entrée, calcule une empreinte servant à identifier rapidement, bien qu'incomplètement, la donnée initiale. Il est courant d’envoyer avec les données un haché chiffré, qui sera ensuite déchiffré par le destinataire, puis comparé au haché des données reçues. MD5, SHA1 et SHA256 sont des algorithmes classiquement utilisés pour de tels hachages. Toutefois, les hachés de données sont de taille généralement beaucoup plus petite que celle des données d'origine, et il peut être possible de créer d'autres données similaires, mais légèrement différentes des données d'origine, ayant un haché égal au haché des données d’origine. Ces données pourraient donc être substituées aux données d’origine, sans être rejetées par la procédure de vérification du haché. La substitution peut être effectuée sur tout type de données, mais est d’autant moins détectable par l’utilisateur que les données sont complexes, comme un texte long, un fichier audio, une photo ou une vidéo. Pour effectuer la substitution, il ne serait même pas nécessaire de décrypter le haché crypté. Un simple calcul du haché des données d'origine suffirait. En outre, les fonctions de hachage telles que MD5 et SHA1 sont des fonctions de hachage actuellement relativement faciles à contourner.
Les ordinateurs quantiques en cours de développement devraient bientôt être capables de contourner la sécurité offerte par les fonctions de hachage, étant capables d’optimiser des fichiers de départ pour qu’ils aient un haché prédéterminé.
Des méthodes d’amélioration de la sécurité des systèmes utilisant des techniques de hachage sont connues de l’art antérieur.
La demande CN101547184 utilise plusieurs valeurs d'authentification auxiliaires échangées entre un serveur et des utilisateurs.
Dans la méthode proposée par la demande US2011/0246433, un haché des données à envoyer est généré et concaténé avec le bloc de données à envoyer et l'étiquette d’un nombre aléatoire.
Il existe un besoin pour perfectionner encore la sécurité des techniques de hachage, réduisant la probabilité d’erreur dans la vérification des données, et le cas échéant, permettant une authentification plus sûre de l’expéditeur de ces données.
L’invention vise notamment à y répondre, et elle y parvient grâce à un procédé de comparaison, mis en œuvre par au moins un appareil, d’un premier et deuxième ensemble de données, en vue notamment de déterminer si ces deux ensembles de données sont identiques, comportant les étapes suivantes :
  1. le mélange d’un nombre, dit nombre de mélange, au premier ensemble de données, à l’aide d’une fonction de mélange, pour obtenir des données mélangées,
  2. le hachage des données mélangées à l’aide d’une fonction de hachage, et
  3. la comparaison du haché ainsi obtenu à l’étape b) avec un troisième ensemble de données supposé être le haché du deuxième ensemble de données mélangé au même nombre de mélange que celui utilisé à l’étape a) et avec la même fonction de mélange.
Grâce à l’invention, notamment au mélange du premier ensemble de données avec un nombre de mélange préalablement au hachage, il devient très improbable de pouvoir créer des données similaires à ce premier ensemble de données qui, après avoir été mélangées au même nombre de mélange, auront le même haché que le premier ensemble de données mélangé.
De préférence, le procédé selon l’invention ne nécessite pas la présence simultanée des deux ensembles de données sur l’appareil.
De préférence, le nombre de mélange est généré aléatoirement.
Le nombre de mélange est préférentiellement généré par l’appareil. En variante, la génération du nombre de mélange est effectuée par un autre appareil de confiance.
La génération du nombre de mélange peut reposer sur un couple de valeurs d’entrée qui sont des grandeurs physiques dont l’une au moins varie continuellement, comme par exemple la température et l’heure, ou sur un phénomène quantique. Par exemple, le choix d'un photon de traverser une plaque par une ou l’autre de deux fentes d’Young constitue la base d’une telle génération.
De préférence, l’opération de mélange à l’étape a) est effectuée par l’appareil. En variante, le mélange est effectué par un autre appareil de confiance.
La fonction de mélange combine le premier ensemble de données et le nombre de mélange. Elle est, de préférence, une fonction logique de type XOR, additionnant les bits du premier ensemble de données et ceux du nombre de mélange, un par un. La taille du nombre de mélange étant généralement inférieure à la taille du premier ensemble de données, il est possible d’additionner par un XOR les bits du nombre de mélange aux premiers ou aux derniers bits du premier ensemble de données.
Le nombre de mélange peut avoir la même taille que le premier ensemble de données. Dans ce cas, l’addition par la fonction XOR s’opère sur tous les bits, un par un.
Alternativement, la fonction de mélange consiste à ajouter le nombre de mélange à la fin du premier ensemble de données.
La fonction de mélange peut encore être une fonction de cryptage utilisant le nombre de mélange comme clé de chiffrement du premier ensemble de données.
De préférence, le hachage des données à l’étape b) est effectué par l’appareil. En variante, le hachage est effectué par un autre appareil de confiance.
De préférence, la fonction de hachage est choisie parmi SHA1, SHA2, SHA256 et MD5 et la fonction de Jenkins.
Une première variante du procédé selon l’invention est un procédé pour la vérification par l’appareil de l’intégrité d’un message provenant d’un émetteur, le procédé comportant:
  1. la réception par l’appareil du message constituant le premier ensemble de données et d’un identifiant du message,
  2. la génération du nombre de mélange,
  3. la mise en œuvre des étapes a) et b) où le message est mélangé au nombre de mélange puis haché,
  4. le cryptage éventuel du nombre de mélange,
  5. l’envoi par l’appareil de l’identifiant du message et du nombre de mélange éventuellement crypté à l’émetteur du message,
  6. la réception par l’appareil du troisième ensemble de données crypté, avec préférentiellement l’identifiant du message, en provenance de l’émetteur,
  7. le décryptage du troisième ensemble de données, et
  8. la mise en œuvre de l’étape c), l’intégrité du message étant assurée si le troisième ensemble de données décrypté à l’étape vii et le haché obtenu à l’étape b) sont identiques.
Par « intégrité » du message, il faut entendre sa non altération, par exemple par un tiers malveillant qui l’aurait intercepté au cours de sa transmission.
L’identifiant du message peut être une suite de caractères alphanumériques et/ou de signes pouvant être convertie en un mot numérique par le biais d’un code ASCII ou autre.
L’identifiant du message peut comporter l’identifiant de l’émetteur et un numéro d’ordre du message.
L’authentification de l’émetteur est notamment assurée par l’opération de décryptage à l’étape vii.
Cette première variante de l’invention permet à la fois de s’assurer de l’intégrité du message reçu et de l’identité de l’émetteur du message.
Les étapes relatives à l’envoi et à la réception des données peuvent être réalisées selon le même protocole de communication, ou selon des protocoles de communication différents. Par exemple, la réception à l’étape i se fait par WiFi, l’envoi à l’étape v se fait par 4G et la réception à l’étape vi se fait par WiMAX.
A l’étape i, l’appareil peut également recevoir un identifiant de l’émetteur. Cet identifiant est utile si l’appareil peut recevoir des messages de différents émetteurs, un tel identifiant lui permettant de choisir les clés de cryptage à utiliser pour crypter ou décrypter les informations échangées avec l’émetteur lors des opérations de cryptage et décryptage décrites dans cette première variante de l’invention.
De préférence, le procédé selon cette première variante comporte entre les étapes v et vi :
  • la réception par l’émetteur de l’identifiant du message et du nombre de mélange éventuellement crypté,
  • le décryptage éventuel du nombre de mélange,
  • l’identification, à l’aide de l’identifiant du message, du message envoyé à l’appareil,
  • le mélange du message au nombre de mélange éventuellement décrypté à l’aide de la fonction de mélange,
  • le hachage des données résultant de l’étape précédente à l’aide de la fonction de hachage,
  • le cryptage du haché résultant de l’étape précédente, et
  • l’envoi à l’appareil du haché crypté avec de préférence l’identifiant du message.
Le cryptage éventuel du nombre de mélange à l’étape iv est préférentiellement effectué par l’appareil.
Le cryptage éventuel du nombre de mélange permet d’éviter que ce nombre ne soit intercepté et altéré par un tiers malveillant.
De préférence, le cryptage éventuel du nombre de mélange s’effectue à l’aide d’une clé à usage unique d’une taille au moins égale à celle du nombre. La clé étant à usage unique, une nouvelle clé est utilisée à chaque envoi d’un nombre de mélange.
Le cryptage peut aussi être effectué à l’aide d’une clé symétrique. La clé de cryptage symétrique est gardée secrète entre l’émetteur et l’appareil, et est de préférence renouvelée après un certain nombre de transmissions.
Alternativement, le cryptage éventuel du nombre de mélange est asymétrique, s’effectuant, soit à l’aide d’une clé publique de l’émetteur connue de l’appareil, de sorte à permettre le décryptage par l’émetteur en utilisant sa clé privée associée, soit à l’aide d’une clé privée de l’appareil dont l’émetteur connaît la clé publique.
Ainsi, un tiers est empêché de connaître ou d’altérer le nombre de mélange.
De préférence, le décryptage à l’étape vii est effectué par l’appareil.
De préférence, le décryptage à l’étape vii s’effectue à l’aide d’une clé symétrique, si le cryptage à l’étape iv est fait par une clé à usage unique.
Alternativement, le décryptage à l’étape vii s’effectue à l’aide d’une clé à usage unique, si le cryptage à l’étape iv est fait par une clé symétrique.
Le décryptage à l’étape vii peut aussi être effectué par d’autres méthodes, par exemple à l’aide d’une clé publique connue de l’appareil, associée à une clé privée de l’émetteur ayant servi au cryptage du haché reçu à l’étape vi. Ainsi, l’appareil est capable de certifier l’identité de l’émetteur.
Le nombre de mélange peut avoir la même taille que la clé symétrique qui sert à le crypter, si une telle clé symétrique est utilisée, et aussi la même taille que le haché.
De préférence, les clés de cryptage privées, symétriques et à usage unique ainsi que les nombres de mélange sont indevinables et inobservables par des dispositifs tiers, pour éviter que l’écoute des données émises par l’émetteur ou l’appareil ne rende possible la génération et la transmission de deuxièmes ensembles de données, frauduleux, qui engendreraient à tort une reconnaissance d’intégrité de messages reçus par l’appareil mais transmis par un émetteur autre que celui censé porter légitimement lesdites clés.
Si la clé de cryptage X du nombre de mélange x est connue, alors le haché du message mélangé peut être connu, car il suffit de décrypter le crypté de x et de calculer le mélangé du message avant de le hacher. La clé Y cryptant le haché peut être alors aussi devinée ou être connue pour appartenir à un univers restreint, le haché du message mélangé et son cryptage par Y étant tous deux connus ou observables. La clé de cryptage Y est donc une fonction F de la clé de cryptage X, ou bien la clé de cryptage Y appartient à un univers dépendant de la clé de cryptage X. L’observation de plusieurs transmissions fait apparaître plusieurs fonctions F, et les valeurs des clés X et Y sont à l’intersection de ces fonctions. Il est préférable d’éviter cette situation. Il est donc recommandé soit d’utiliser pour la clé X ou la clé Y des valeurs changeantes au fil des transmissions, soit d’utiliser des fonctions de cryptage telles que pour chaque observation d’échanges du triplet « message, nombre crypté, haché crypté», l’univers des clés Y pour chaque X possible est grand ; ceci rendant grand l’univers résultant de l’intersection de ces univers déductibles à chaque observation. Il n’est pas recommandé de prendre pour clé Y le nombre de mélange x généré aléatoirement. En effet, si on se sert du nombre de mélange x comme clé de chiffrage Y, ou bien si on calcule la clé Y en fonction du nombre de mélange x par une formule déterminée, connaissant la valeur cryptée C du nombre de mélange x par la clé X, le nombre de mélange x, et donc Y deviennent une autre fonction G de la clé X ; et les clés X et Y seraient à l’intersection de la fonction F et de cette nouvelle fonction G. De préférence, la clé X ou la clé Y est renouvelée après chaque échange.
L’appareil peut en outre comporter un compteur de tentatives de vérifications négatives consécutives déclenchant un blocage de celui-ci lorsqu’un nombre déterminé est atteint, le déblocage pouvant être effectué lors du renouvellement de la clé de cryptage du nombre de mélange ou de la clé de cryptage du haché.
Une deuxième variante du procédé selon l’invention est un procédé pour la vérification par l’appareil de l’intégrité d’un message provenant d’un émetteur, le procédé comportant :
  1. la réception par l’appareil du message, du troisième ensemble de données crypté et du nombre de mélange crypté,
  2. le décryptage du nombre de mélange et du troisième ensemble de données, et
  3. la mise en œuvre des étapes a) à c), l’intégrité du message étant assurée si le haché obtenu à l’étape b) et le troisième ensemble de données décrypté à l’étape ii sont identiques.
De préférence, le procédé selon cette deuxième variante de l’invention comporte avant l’étape i :
  • la génération par l’émetteur du nombre de mélange,
  • le mélange du nombre de mélange au message, à l’aide de la fonction de mélange,
  • le hachage des données résultant de l’étape précédente à l’aide de la fonction de hachage,
  • le cryptage du haché résultant de l’étape précédente et constituant le troisième ensemble de données,
  • le cryptage du nombre de mélange, et
  • l’envoi à l’appareil du message, du troisième ensemble de données crypté et du nombre de mélange crypté.
Ces étapes sont effectuées par l’émetteur authentique et permettent de détecter l’altération du message par un tiers non autorisé.
Le décryptage à l’étape ii du nombre de mélange et du troisième ensemble de données est préférentiellement effectué par l’appareil.
De façon préférentielle, le cryptage du nombre de mélange s’effectue à l’aide d’une clé à usage unique, et le cryptage du troisième ensemble de données s’effectue à l’aide d’une clé symétrique, la clé symétrique étant de préférence renouvelée occasionnellement.
Alternativement, le cryptage du nombre de mélange s’effectue à l’aide d’une clé symétrique, et le cryptage du troisième ensemble de données s’effectue à l’aide d’une clé à usage unique, la clé symétrique étant de préférence renouvelée occasionnellement.
Le cryptage du nombre de mélange et le cryptage du troisième ensemble de données peuvent aussi être de même type, ou de types différents, ces types de cryptage pouvant être par clés symétriques, ou par clés asymétriques.
Si une paire de clés asymétriques est utilisée pour le cryptage du nombre de mélange, celle-ci a de préférence sa clé privée détenue par l’appareil, la clé publique correspondante étant alors connue de l’émetteur.
Le cryptage du troisième ensemble de données est, de préférence, effectué à l’aide d’une clé privée détenue par l’émetteur, la clé publique correspondante étant alors connue de l’appareil.
Ainsi, par le décryptage du nombre de mélange et du troisième ensemble de données, l’appareil est capable de certifier l’identité de l’émetteur.
Le cryptage du nombre de mélange et celui du troisième ensemble de données peuvent être effectués par le biais de la même fonction de cryptage, notamment lorsque le cryptage du nombre de mélange est asymétrique.
Alternativement, le cryptage du nombre de mélange et celui du troisième ensemble de données sont effectués par le biais de deux fonctions de cryptage différentes.
De préférence, les types de fonctions de cryptage à utiliser font partie de la configuration de l’émetteur et de l’appareil, préalablement à l’établissement de la communication entre ces deux derniers.
Une troisième variante du procédé selon l’invention est un procédé dans lequel le premier ensemble de données est présent sur l’appareil et le deuxième ensemble de données est présent sur un deuxième appareil, le procédé comportant :
  1. la mise en œuvre des étapes a) et b),
  2. le cryptage du nombre de mélange,
  3. l’envoi par l’appareil au deuxième appareil du nombre de mélange crypté,
  4. la réception par l’appareil d’un haché crypté du deuxième ensemble de données,
  5. le décryptage du haché crypté, et
  6. la mise en œuvre de l’étape c).
De préférence, le procédé selon cette troisième variante de l’invention comporte entre les étapes iii et iv :
  • la réception par le deuxième appareil du nombre de mélange crypté,
  • le décryptage du nombre de mélange,
  • la création d’une copie modifiée du deuxième ensemble de données à l’aide du nombre de mélange et de la fonction de mélange,
  • le hachage de la copie modifiée du deuxième ensemble de données à l’aide de la fonction de hachage,
  • le cryptage du haché résultant de l’étape précédente et constituant le troisième ensemble de données, et
  • l’envoi par le deuxième appareil à l’appareil du haché crypté du deuxième ensemble de données.
Le cryptage du nombre de mélange à l’étape ii et le décryptage du haché crypté à l’étape v sont préférentiellement effectués par l’appareil.
De préférence, le cryptage du nombre de mélange s’effectue à l’aide d’une clé de cryptage symétrique partagée avec le deuxième appareil.
De préférence, le cryptage du haché s’effectue à l’aide d’une clé à usage unique et le cryptage du nombre de mélange s’effectue à l’aide d’une clé symétrique renouvelée occasionnellement.
Alternativement, le cryptage du nombre de mélange s’effectue à l’aide d’une clé à usage unique et le cryptage du haché s’effectue à l’aide d’une clé symétrique renouvelée occasionnellement.
Le cryptage du nombre de mélange et le cryptage du haché peuvent aussi être de même type, ou de types différents, ces types de cryptage pouvant être par clés symétriques, notamment par clés à usage unique, ou par clés asymétriques.
Une quatrième variante du procédé selon l’invention est un procédé pour la vérification qu’un ensemble de données présent sur l’appareil n’a pas été modifié entre deux dates d1 et d2, cet ensemble de données constituant à la date d1 le premier ensemble de données et à la date d2 le deuxième ensemble de données, le procédé comportant :
  1. la mise en œuvre des étapes a) et b),
  2. la sauvegarde de manière sécurisée par l’appareil du nombre de mélange et du haché obtenu à l’étape b),
  3. la création d’une copie modifiée du deuxième ensemble de données à l’aide du nombre de mélange et de la fonction de mélange,
  4. le hachage de la copie modifiée à l’aide de la fonction de hachage pour former le troisième ensemble de données, et
  5. la mise en œuvre de l’étape c).
Avantageusement, le procédé selon cette quatrième variante ne nécessite pas une conservation sécurisée de l’ensemble de données.
L’invention a aussi pour objet un produit programme d’ordinateur comprenant des instructions lisibles par un processeur d’un appareil pour la mise en œuvre du procédé selon l’invention, selon l’une quelconque des variantes définies ci-dessus.
L’invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d’exemples non limitatifs de mise en œuvre de celle-ci, et à l’examen du dessin annexé, sur lequel :
la figure 1 représente schématiquement les données et fonctions nécessaires à la mise en œuvre de l’invention selon sa première ou sa deuxième variante,
la figure 2 illustre schématiquement un exemple de mise en œuvre de l’invention selon sa première variante,
la figure 3 représente schématiquement un exemple de mise en œuvre de l’invention selon sa deuxième variante,
la figure 4 illustre schématiquement des données et fonctions utiles à la mise en œuvre de l’invention selon sa troisième variante,
la figure 5 représente schématiquement un exemple de mise en œuvre de l’invention selon sa troisième variante,
la figure 6 illustre un schéma de mise en œuvre de l’invention selon sa quatrième variante,
la figure 7 illustre schématiquement des données utiles à la mise en œuvre de l’exemple de la figure 8,
la figure 8 représente un premier exemple de mise en œuvre de l’invention appliquée à la vérification de logiciels,
la figure 9 représente un deuxième exemple de mise en œuvre de l’invention appliquée à la vérification de logiciels,
la figure 10 illustre schématiquement des dispositifs et données utiles à la mise en œuvre de l’exemple de la figure 11,
la figure 11 illustre un exemple de mise en œuvre de l’invention appliquée à la sécurisation des navigateurs internet,
la figure 12 représente schématiquement des dispositifs et données utiles à la mise en œuvre de l’exemple de la figure 13, et
la figure 13 représente un exemple de mise en œuvre de l’invention appliquée à la sécurisation des courriers électroniques.
Description détaillée
La figure 1 représente schématiquement des données et fonctions utiles à la mise en œuvre de l’invention selon sa première ou sa deuxième variante, où un message 101 doit être envoyé par un dispositif A à un dispositif B via un canal de transmission de données 109, lequel peut être sécurisé ou non.
Le dispositif A peut être un ordinateur personnel ou un téléphone intelligent, et le dispositif B un serveur de courrier électronique, le message 101 étant par exemple un courrier électronique envoyé par l’ordinateur ou le téléphone via le réseau internet.
Le dispositif A peut aussi être un serveur envoyant un courrier électronique ou une page web, le dispositif B étant alors un ordinateur personnel ou un téléphone intelligent recevant ledit courrier électronique ou la page web.
Le dispositif A peut encore être un appareil de mesure, par exemple de la consommation de courant électrique, de gaz ou d’eau, ou pour mesurer l’usure d’une pièce dans une machine, le message 101 étant alors le résultat d’une telle mesure, et le dispositif B un serveur regroupant la mesure et communiquant avec l’appareil de mesure via un réseau de télécommunications, par exemple un réseau d’internet des objets, un réseau WiFi ou un réseau LTE.
Les dispositifs A et B peuvent aussi être des ordinateurs personnels ou des téléphones intelligents.
Le dispositif A peut être un navigateur web, le dispositif B un serveur web et le message 101 un formulaire rempli par l’utilisateur du navigateur A, la réception du message devant ne pas être différée par rapport à son envoi.
Les dispositifs A et B peuvent être chacun équipés d’un processeur pour l’exécution des étapes du procédé selon l’invention, et d’une mémoire pour sauvegarder les données nécessaires à cette exécution.
Le dispositif B dispose de données de chiffrement/déchiffrement 102B, telles qu'une clé privée. Le dispositif A dispose de données de chiffrement/déchiffrement 102A, telles que la clé publique associée à la clé privée 102B.
Le dispositif A dispose également de données de chiffrement/déchiffrement 103A, telles qu’une clé privée associée à une clé publique 103B présente sur le dispositif B.
Les dispositifs A et B possèdent des générateurs de nombres aléatoires 104A et 104B respectivement, une fonction de mélange commune 105 et une fonction de hachage commune 106.
Les dispositifs A et B ont également des fonctions de cryptage 107A et 107B respectivement, ainsi que des fonctions de décryptage 108A et 108B respectivement.
On a illustré à la figure 2 un exemple de mise en œuvre du procédé selon la première variante de l’invention.
A l'étape 201, un premier nombre, utilisé pour identifier le message 101, est généré par le dispositif A. Il peut être optionnellement généré à partir du générateur de nombres aléatoires 104A.
A l'étape 202, le premier nombre est ajouté au message 101. Cet ajout peut être une concaténation dans un ordre quelconque défini par le protocole de communication entre les deux dispositifs.
A l’étape 203, le dispositif A envoie les données résultant de l’étape 202 au dispositif B via le canal 109 de transmission des données.
A l’étape 204, à la réception des données, le dispositif B génère aléatoirement un deuxième nombre à partir du générateur de nombres aléatoires 104B.
A l’étape 205, le dispositif B se sert de la fonction de mélange 105 pour mélanger le deuxième nombre avec le message 101. A titre d’exemple, cette fonction de mélange est un XOR opérant entre les bits du deuxième nombre et un même nombre de bits du message 101. La fonction de mélange 105 est connue par le dispositif A.
A l’étape 206, le dispositif B utilise la fonction de hachage 106 pour hacher les données obtenues à l’étape précédente. Le dispositif B utilise également la clé de chiffrement publique 103B et la fonction de cryptage 107B, pour crypter le deuxième nombre.
A l’étape 207, le dispositif B envoie au dispositif A via le canal 109 le premier nombre ainsi que le deuxième nombre crypté.
A l’étape 208, à la réception des deux nombres, le dispositif A décrypte le deuxième nombre à l’aide de la clé de chiffrement privée 103A associée à la clé publique 103B qui devait servir au cryptage, et de la fonction de décryptage 108A associée à la fonction de cryptage 107B. Si le deuxième nombre n’a pas été crypté par le dispositif B, son décryptage sera inexact.
Avec le premier nombre, le dispositif A peut identifier le message 101, et mélanger, à l’aide de la fonction de mélange 105, le deuxième nombre décrypté au message 101 identifié.
A l’étape 209, le dispositif A utilise la fonction de hachage 106 pour hacher les données résultantes de l’étape précédente.
A l’étape 210, le dispositif A utilise la clé de chiffrement privée 103A et la fonction de cryptage 107A, pour crypter le haché obtenu à l’étape précédente.
A l’étape 211, le dispositif A envoie le haché crypté au dispositif B via le canal 109.
A l’étape 212, à la réception du haché crypté, le dispositif B le décrypte à l’aide de la clé de chiffrement publique 103B associée à la clé privée 103A qui devait servir au cryptage, et de la fonction de décryptage 108B associée à la fonction de cryptage 107A.
A l’étape 213, le dispositif B compare le haché décrypté obtenu à l’étape 212 avec le haché calculé à l’étape 206. Si les deux hachés sont identiques, le dispositif B conclut que le message 101 n’a pas été altéré.
De préférence, le deuxième nombre servant au mélange doit être gardé secret jusqu'à ce que les hachés aient été comparés pour effectuer la vérification, mais ce nombre de mélange peut être révélé avant, si l'on peut faire confiance aux dispositifs calculant les hachés pour que les données ne soient pas modifiées entre le moment où le nombre de mélange est révélé et la comparaison des hachés.
On a illustré à la figure 3 un deuxième exemple de mise en œuvre du procédé selon la deuxième variante de l’invention, le message 101 devant être envoyé par le dispositif A au dispositif B.
Les dispositifs A et B peuvent être des ordinateurs personnels ou des téléphones intelligents, et le message 101 peut être un courrier électronique.
Les dispositifs A et B peuvent être des automobiles voisines, les données échangées étant alors des informations relatives à leurs mouvements, et la connexion s’effectuant par une liaison de données entre les deux véhicules, par exemple une liaison de type 5G, Bluetooth Low Energy, une liaison RFID ultra haute fréquence, une liaison Lora ou Sigfox.
A l’étape 301, un nombre aléatoire est généré par le dispositif A, à l’aide du générateur de nombres aléatoires 104A.
A l’étape 302, le dispositif A mélange le message 101 au nombre aléatoire à l’aide de la fonction de mélange 105.
A l’étape 303, le dispositif A procède au hachage des données mélangées résultant de l’étape précédente, à l’aide de la fonction de hachage 106.
A l’étape 304, le dispositif A crypte le haché obtenu à l’étape précédente à l’aide de la fonction de cryptage 107A et de la clé de chiffrement privée 103A.
A l’étape 305, le dispositif A crypte le nombre aléatoire à l’aide de la fonction de cryptage 107A et de la clé de chiffrement publique 102A.
A l’étape 306, le message 101, le nombre aléatoire crypté et le haché crypté sont envoyés au dispositif B via le canal de transmission 109, selon le protocole de communication établi entre les deux dispositifs.
A l’étape 307, à la réception des données, le dispositif B utilise la fonction de décryptage 108B ainsi que la clé de chiffrement publique 103B pour décrypter le haché, et la clé de chiffrement privée 102B pour décrypter le nombre aléatoire.
Le dispositif B est ainsi en mesure d’authentifier le dispositif A.
A l’étape 308, le dispositif B mélange le message 101 au nombre aléatoire, à l’aide de la fonction de mélange 105.
A l’étape 309, le dispositif B hache les données mélangées résultant de l’étape précédente, à l’aide de la fonction de hachage 106.
A l’étape 310, le dispositif B compare le haché qu’il a calculé au haché décrypté, et conclut quant à l’intégrité du message 101.
Dans cet exemple, le dispositif B peut faire suivre les données reçues du dispositif A à un troisième dispositif. Le dispositif B décrypte à l’aide de la clé privée 102B le nombre aléatoire qu’il a reçu du dispositif A avant de le crypter à nouveau à l’aide de la clé publique du troisième dispositif. Le dispositif B transmet alors au troisième dispositif le nombre aléatoire crypté ainsi que le haché crypté par le dispositif A. Le troisième dispositif, disposant de la clé publique du dispositif A, pourra vérifier que ce haché provient bien du dispositif A, dans la mesure où le dispositif B n’a pas modifié le haché crypté par le dispositif A. Un même ensemble de données peut donc être vérifié comme authentique par de nombreux utilisateurs. Cette possibilité expose cependant la sécurité de la certification, un dispositif frauduleux pouvant décrypter le nombre aléatoire, et éventuellement modifier le message pour qu’il ait le même haché aléatoire que le haché initial. Cette mise en œuvre est donc utilisée de préférence pour certifier la communication entre systèmes informatiques formés d’éléments protégés contre une telle utilisation frauduleuse.
La figure 4 illustre schématiquement les données et fonctions nécessaires à la mise en œuvre de l’invention selon sa troisième variante, pour vérifier qu'un fichier 401A présent sur un dispositif A est identique à un fichier 401B présent sur un dispositif B.
Les dispositifs A et B communiquent via un canal de transmission 409 qui est par exemple un réseau WiFi.
Le dispositif A possède un générateur de nombres aléatoires 404.
Les dispositifs A et B disposent en commun d’une fonction de mélange 405, d’une fonction de hachage 406 et d’une clé symétrique de cryptage 410.
Le dispositif B dispose d’une fonction de cryptage 407.
Le dispositif A dispose d’une fonction de décryptage 408.
On a illustré à la figure 5 un troisième exemple de mise en œuvre du procédé selon la troisième variante de l’invention.
A l’étape 501, un nombre aléatoire est généré sur le dispositif A à l'aide du générateur de nombres aléatoires 404.
A l’étape 502, une copie modifiée du fichier 401A est créée en utilisant la fonction de mélange 405 et le nombre aléatoire.
A l’étape 503, la copie modifiée du fichier 401A est hachée à l’aide de la fonction de hachage 406.
A l’étape 504, le nombre aléatoire est crypté à l’aide d’un algorithme de cryptage symétrique et de la clé de chiffrement symétrique 410, et est envoyé au dispositif B via le canal de transmission 409.
A l’étape 505, à la réception du nombre aléatoire crypté, le dispositif B le décrypte et l’utilise dans une fonction de mélange 405 pour créer une copie modifiée du fichier 401B.
En décryptant le nombre aléatoire, le dispositif B peut vérifier l’identité du dispositif A.
A l’étape 506, la copie modifiée du fichier 401B est hachée avec la même fonction de hachage 406.
A l’étape 507, le haché de la copie modifiée est crypté à l’aide de la fonction de cryptage 407 et de la clé de chiffrement 410.
A l’étape 508, le haché crypté est envoyé au dispositif A.
A l’étape 509, à la réception du haché crypté, le dispositif A le décrypte à l’aide de la fonction de décryptage 408 et de la clé 410.
A l’étape 510, le dispositif A compare le haché décrypté à celui qu’il a calculé à l’étape 503, et ainsi est en mesure de vérifier si les deux fichiers 401A et 401B sont identiques.
On a illustré à la figure 6 un quatrième exemple de mise en œuvre du procédé selon la quatrième variante de l’invention, pour vérifier qu'un fichier n'a pas été modifié entre deux dates d1 et d2, en conservant en toute sécurité un jeu de données réduit entre les deux dates, ce jeu comprenant un nombre conservé intact et secret et un haché conservé intact et préférentiellement secret.
A l’étape 601, un nombre aléatoire est généré.
A l’étape 602, à la date d1, une copie modifiée du fichier est créée en utilisant le nombre aléatoire généré et une fonction de mélange, cette fonction consistant par exemple à ajouter le nombre aléatoire à la fin du fichier.
A l’étape 603, un haché de la copie modifiée est créé, par exemple en utilisant la fonction SHA2.
A l’étape 604, le nombre aléatoire et le haché sont conservés de manière sécurisée et secrète, afin qu'ils ne puissent pas être modifiés et que le nombre aléatoire ne soit pas divulgué à une partie tierce.
A l’étape 605, à la date d2, la personne ou le dispositif ayant accès aux informations sauvegardées à l'étape 604 souhaite comparer le fichier à la date d2 avec le fichier utilisé aux étapes 601 à 604. Pour ce faire, le nombre aléatoire sauvegardé est utilisé pour créer une deuxième copie modifiée du fichier à la date d2, en utilisant la même fonction de mélange qu'à l'étape 602.
A l’étape 606, un haché de la deuxième copie modifiée est créé en utilisant la même fonction de hachage qu'à l'étape 603.
A l’étape 607, le haché créé à l’étape précédente est comparé avec le haché sauvegardé pour s’assurer que le fichier n’a pas été modifié entre les dates d1 et d2.
On a illustré schématiquement à la figure 7 les clés nécessaires à la mise en œuvre d’un cinquième exemple, représenté à la figure 8, du procédé selon l’invention appliquée à la vérification de logiciels.
Dans la suite de la description, on appellera « hachage aléatoire » d’une donnée, l’opération de mélange de cette donnée avec un nombre de mélange aléatoire suivie de l’opération de hachage.
L’exemple représenté à la figure 8 est réalisé entre deux dispositifs : un dispositif A dit distributeur de logiciels et un dispositif B dit client.
Le dispositif A possède deux clés 701 et 702.
701 est une clé servant à chiffrer un haché, et est de préférence privée.
702 est une clé servant à chiffrer un nombre aléatoire, et est de préférence publique.
Le dispositif B possède deux clés 703 et 704.
703 est une clé servant à déchiffrer un haché crypté à l’aide de la clé 701, et est de préférence publique.
704 est une clé servant à déchiffrer un nombre aléatoire crypté à l’aide de la clé 702, et est de préférence privée.
La paire de clés (701, 703) peut être appelée paire de clés du distributeur de logiciels, ce dernier pouvant l’utiliser pour communiquer avec tous les appareils sur lesquels un des logiciels qu’il distribue est installé.
La paire de clés (704, 702) peut être appelée paire de clés du client, celui-ci pouvant l’utiliser pour tous les logiciels qu’il vérifie lors de leur chargement.
A l’étape 801, le distributeur de logiciels A procède au hachage aléatoire d’un logiciel à transmettre au client B selon les étapes 301 à 305 décrites précédemment à la figure 3.
Le distributeur de logiciels A utilise la clé 702 pour crypter le nombre aléatoire et la clé 701 pour crypter le haché aléatoire du logiciel.
A l’étape 802, le distributeur de logiciels A envoie au client B un ensemble de données contenant le logiciel, le haché crypté du logiciel et le nombre aléatoire crypté, sur une ligne de transmission sécurisée ou non.
A l’étape 803, à la réception de l’ensemble de données, le client B décrypte le haché avec la clé 703 et le nombre aléatoire avec la clé 704. Le client B se sert alors du nombre aléatoire pour procéder au hachage aléatoire du logiciel reçu.
A l’étape 804, si le haché calculé est identique au haché reçu, le client B autorise l’exécution du logiciel reçu, ou remplace la version précédente de ce logiciel par la version qu’il vient de recevoir.
A l’étape 805, pour plus de sécurité, les étapes 803 et 804 sont ré-exécutées à des intervalles de temps préprogrammés afin de vérifier l’authenticité du logiciel.
La figure 9 décrit une autre mise en œuvre possible du hachage aléatoire pour vérifier que le logiciel en cours de chargement est autorisé par un logiciel en cours d’exécution sur un appareil.
A l’étape 901, l’appareil utilise le procédé décrit à la figure 2 pour vérifier qu’un logiciel reçu provient d'une source fiable.
A l’étape 902, les étapes 601 à 604 de la figure 6 sont exécutées pour créer sur l’appareil une signature sécurisée du logiciel.
A l’étape 903, avant d'utiliser le logiciel, les étapes 605 à 607 de la figure 6 sont exécutées pour vérifier que le logiciel n'a pas été modifié depuis l'étape 902.
La figure 10 présente les objets nécessaires à la mise en œuvre de l’exemple illustré à la figure 11 permettant la sécurisation des données affichées par les navigateurs internet.
Un navigateur internet 1001 dispose d’une paire de clés asymétriques constituée d’une clé privée 1002p et d’une clé publique 1002u.
Un serveur 1003s, fournissant au navigateur les clés publiques de sites internet sécurisés 1004s, possède une paire de clés asymétriques 1003 constituée d’une clé privée 1003p et d’une clé publique 1003u.
Le site internet 1004s possède une paire de clés asymétriques 1004 constituée d’une clé privée 1004p et d’une clé publique 1004u.
A l’étape 1101, un utilisateur entre dans la barre d’adresse du navigateur 1001 l’adresse URL du site qu’il souhaite consulter.
A l’étape 1102, le navigateur 1001 utilise la paire de clés 1002 et envoie au serveur 1003s les informations suivantes :
  • l’adresse URL du site que l’utilisateur souhaite consulter,
  • la clé publique 1002u du navigateur, et
  • l’adresse URL du navigateur 1001 pour que le serveur puisse lui répondre.
A l’étape 1103, le serveur 1003s utilise le procédé selon l’invention décrit à la figure 2 pour envoyer de façon sécurisée au navigateur la clé publique 1004u du site 1004s.
La clé publique 1002u sera utile au serveur pour le décryptage du deuxième nombre que le navigateur lui aura envoyé lors des échanges.
A l’étape 1104, le navigateur 1001 envoie au site 1004s les informations suivantes :
  • le nom de la page du site que l’utilisateur souhaite consulter,
  • la clé publique 1002u du navigateur, et
  • l’adresse URL du navigateur pour que le site puisse lui répondre.
A l’étape 1105, le serveur 1004s utilise le procédé selon l’invention décrit à la figure 2 pour envoyer au navigateur de façon sécurisée la page demandée.
La figure 12 présente les objets nécessaires à la mise en œuvre de l’exemple illustré à la figure 13 permettant la sécurisation des courriers électroniques.
Un premier dispositif électronique A, pouvant être un ordinateur ou un téléphone intelligent, permet l’envoi, la réception, l’archivage, l’édition et l’affichage de courriers électroniques 1200 qui sont sous forme de fichiers électroniques.
Ce premier dispositif A a accès à une paire de clés asymétriques 1201c constituée d’une clé publique 1201u et d’une clé privée 1201p.
Un deuxième dispositif électronique B permet l’envoi, la réception, l’archivage, l’édition et l’affichage des courriers électroniques 1200.
Ce deuxième dispositif B a accès à une paire de clés asymétriques 1202c constituée d’une clé publique 1202u et d’une clé privée 1202p.
Un serveur 1203 regroupe les numéros d’identification et les clés publiques des dispositifs électroniques, tels que A et B, certifiés conserver l’intégrité des messages électroniques reçus et la confidentialité des nombres aléatoires associés au procédé de hachage aléatoire selon l’invention.
Le serveur 1203 a accès à une paire de clés 1203c constituée d’une clé publique 1203u et d’une clé privée 1203p. Il est à noter que ce serveur peut avoir plusieurs paires de clés, chacune dédiée à la communication avec un dispositif électronique bien déterminé.
Un serveur 1204 associe le ou les dispositifs électroniques à l’adresse 1205 destinataire du courrier électronique.
Le serveur 1204 a accès à une paire de clés 1204c constituée d’une clé publique 1204u et d’une clé privée 1204p. Il est à noter que ce serveur peut avoir plusieurs paires de clés, chacune dédiée à la communication avec un dispositif électronique bien déterminé.
A l’étape 1301, un utilisateur demande au premier dispositif A d’envoyer le courrier électronique 1200 à l’adresse destinataire 1205.
A l’étape 1302, le premier dispositif A communique avec le serveur 1204 dont il connaît la clé publique, en utilisant le procédé selon l’invention décrit à la figure 2, afin de connaître l’identifiant et la clé publique du dispositif B associé à l’adresse 1205. Après authentification du premier dispositif A auprès du serveur 1204, ce dernier envoie au premier dispositif A l’identifiant et la clé publique du dispositif B. Cet envoi se fait aussi suivant le procédé décrit à la figure 2, le serveur 1204 connaissant la clé publique du dispositif A et ce dernier connaissant la clé publique du serveur 1204. Ce procédé permet au dispositif A de recevoir du serveur 1204 des données non modifiées. Le serveur 1204 aura lui-même pu obtenir la clé publique du dispositif B auprès du serveur 1203 et, par la même occasion, vérifié la clé publique du dispositif A.
A l’étape 1303, le premier dispositif A communique son identifiant au dispositif B.
A l’étape 1304, le dispositif B, ayant reçu l’identifiant communiqué à l’étape 1303, communique avec le serveur 1203 pour connaître la clé publique du premier dispositif A. Cette information lui est envoyée selon le procédé de la figure 2 permettant au dispositif B de recevoir une information non modifiée. Le dispositif B informe le dispositif A de la réception de cette information en lui envoyant un accusé de réception.
A l’étape 1305, à la réception de l’accusé de réception envoyé à l’étape 1304, le premier dispositif A utilise le procédé selon l’invention décrit à la figure 2 pour envoyer le courrier 1200 au dispositif B qui peut alors être certain que ces informations ont été envoyées par le dispositif A et ont été reçues non altérées. De plus, le dispositif A est certain de n’avoir certifié ces informations qu’auprès du dispositif B.
Les procédés de cryptage à clés asymétriques et à clés symétriques pouvant être vulnérables aux ordinateurs quantiques, ces procédés de cryptage peuvent être remplacés, dans les exemples décrits ci-dessus par des procédés de cryptage utilisant des clés à usage unique.
L’invention n’est pas limitée aux exemples de réalisation décrits ci-dessus, ni aux applications exemplifiées. L’invention peut être utilisée notamment pour sécuriser les transactions financières.

Claims (16)

  1. Procédé de comparaison, mis en œuvre par au moins un appareil (A ; B), d’un premier et deuxième ensemble de données, en vue notamment de déterminer si ces deux ensembles de données sont identiques, comportant les étapes suivantes :
    1. le mélange d’un nombre, dit nombre de mélange, au premier ensemble de données, à l’aide d’une fonction de mélange (105 ; 405), pour obtenir des données mélangées,
    2. le hachage des données mélangées à l’aide d’une fonction de hachage (106 ; 406), et
    3. la comparaison du haché ainsi obtenu à l’étape b) avec un troisième ensemble de données supposé être le haché du deuxième ensemble de données mélangé au même nombre de mélange que celui utilisé à l’étape a) et avec la même fonction de mélange (105 ; 405).
  2. Procédé selon la revendication précédente, le nombre de mélange étant généré aléatoirement.
  3. Procédé selon l'une des deux revendications précédentes, pour la vérification par l’appareil (B) de l’intégrité d’un message (101) provenant d’un émetteur (A), le procédé comportant:
    1. la réception par l’appareil du message (101) constituant le premier ensemble de données et d’un identifiant du message,
    2. la génération du nombre de mélange,
    3. la mise en œuvre des étapes a) et b) où le message est mélangé au nombre de mélange puis haché,
    4. le cryptage éventuel du nombre de mélange,
    5. l’envoi par l’appareil (B) de l’identifiant du message et du nombre de mélange éventuellement crypté à l’émetteur (A) du message,
    6. la réception par l’appareil (B) du troisième ensemble de données crypté, en provenance de l’émetteur (A),
    7. le décryptage du troisième ensemble de données, et
    8. la mise en œuvre de l’étape c), l’intégrité du message étant assurée si le troisième ensemble de données décrypté à l’étape vii et le haché obtenu à l’étape b) sont identiques.
  4. Procédé selon la revendication précédente, comportant entre les étapes v et vi :
    • la réception par l’émetteur (A) de l’identifiant du message et du nombre de mélange éventuellement crypté,
    • le décryptage éventuel du nombre de mélange,
    • l’identification, à l’aide de l’identifiant du message, du message (101) envoyé à l’appareil (B),
    • le mélange du message au nombre de mélange éventuellement décrypté à l’aide de la fonction de mélange (105),
    • le hachage des données résultant de l’étape précédente à l’aide de la fonction de hachage (106),
    • le cryptage du haché résultant de l’étape précédente, et
    • l’envoi à l’appareil (B) du haché crypté.
  5. Procédé selon l'une des deux revendications précédentes, le décryptage à l’étape vii s’effectuant à l’aide d’une clé symétrique, si le cryptage à l’étape iv est fait par une clé à usage unique.
  6. Procédé selon l’une des deux revendications 3 et 4, le décryptage à l’étape vii s’effectuant à l’aide d’une clé à usage unique, si le cryptage à l’étape iv est fait par une clé symétrique.
  7. Procédé selon l'une des deux revendications 1 et 2, pour la vérification qu’un ensemble de données présent sur l’appareil (A; B) n’a pas été modifié entre deux dates d1 et d2, cet ensemble de données constituant à la date d1 le premier ensemble de données et à la date d2 le deuxième ensemble de données, le procédé comportant :
    1. la mise en œuvre des étapes a) et b),
    2. la sauvegarde de manière sécurisée par l’appareil (A; B) du nombre de mélange et du haché obtenu à l’étape b),
    3. la création d’une copie modifiée du deuxième ensemble de données à l’aide du nombre de mélange et de la fonction de mélange,
    4. le hachage de la copie modifiée à l’aide de la fonction de hachage pour former le troisième ensemble de données, et
    5. la mise en œuvre de l’étape c).
  8. Procédé selon l'une des deux revendications 1 et 2, pour la vérification par l’appareil (B) de l’intégrité d’un message (101) provenant d’un émetteur (A), le procédé comportant :
    1. la réception par l’appareil (B) du message (101), du troisième ensemble de données crypté et du nombre de mélange crypté,
    2. le décryptage du nombre de mélange et du troisième ensemble de données, et
    3. la mise en œuvre des étapes a) à c), l’intégrité du message étant assurée si le haché obtenu à l’étape b) et le troisième ensemble de données décrypté à l’étape ii sont identiques.
  9. Procédé selon la revendication précédente, comportant avant l’étape i :
    • la génération par l’émetteur (A) du nombre de mélange,
    • le mélange du nombre de mélange au message (101), à l’aide de la fonction de mélange (105),
    • le hachage des données résultant de l’étape précédente à l’aide de la fonction de hachage (106),
    • le cryptage du haché résultant de l’étape précédente et constituant le troisième ensemble de données,
    • le cryptage du nombre de mélange, et
    • l’envoi à l’appareil (B) du message (101), du troisième ensemble de données crypté et du nombre de mélange crypté.
  10. Procédé selon l'une des deux revendications 1 et 2, le premier ensemble de données (401A) étant présent sur l’appareil (A) et le deuxième ensemble de données (401B) étant présent sur un deuxième appareil (B), le procédé comportant :
    1. la mise en œuvre des étapes a) et b),
    2. le cryptage du nombre de mélange,
    3. l’envoi par l’appareil (A) au deuxième appareil (B) du nombre de mélange crypté,
    4. la réception par l’appareil (A) d’un haché crypté du deuxième ensemble de données (401B),
    5. le décryptage du haché crypté, et
    6. la mise en œuvre de l’étape c).
  11. Procédé selon la revendication précédente, comportant entre les étapes iii et iv :
    • la réception par le deuxième appareil (B) du nombre de mélange crypté,
    • le décryptage du nombre de mélange,
    • la création d’une copie modifiée du deuxième ensemble de données (401B) à l’aide du nombre de mélange et de la fonction de mélange (405),
    • le hachage de la copie modifiée du deuxième ensemble de données à l’aide de la fonction de hachage (406),
    • le cryptage du haché résultant de l’étape précédente et constituant le troisième ensemble de données, et
    • l’envoi par le deuxième appareil (B) à l’appareil (A) du haché crypté du deuxième ensemble de données (401B).
  12. Procédé selon l’une quelconque des revendications précédentes, la fonction de mélange (105 ; 405) étant une fonction logique de type XOR.
  13. Procédé selon l’une quelconque des revendications 1 à 11, la fonction de mélange (105 ; 405) consistant à ajouter le nombre de mélange à la fin du premier ensemble de données.
  14. Procédé selon l’une quelconque des revendications 1 à 11, la fonction de mélange (105 ; 405) étant une fonction de cryptage utilisant le nombre de mélange comme clé de chiffrement du premier ensemble de données.
  15. Procédé selon l'une quelconque des revendications précédentes, la fonction de hachage (106 ; 406) étant choisie parmi SHA1, SHA2, SHA256, MD5 et la fonction de Jenkins.
  16. Produit programme d’ordinateur comprenant des instructions lisibles par le processeur d’un appareil pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes.
FR1901648A 2019-02-19 2019-02-19 Méthode cryptographique de vérification des données Active FR3092923B1 (fr)

Priority Applications (11)

Application Number Priority Date Filing Date Title
FR1901648A FR3092923B1 (fr) 2019-02-19 2019-02-19 Méthode cryptographique de vérification des données
CN202080015504.4A CN113811874A (zh) 2019-02-19 2020-02-17 加密数据验证方法
AU2020225314A AU2020225314A1 (en) 2019-02-19 2020-02-17 Cryptographic data verification method
PCT/EP2020/054126 WO2020169542A1 (fr) 2019-02-19 2020-02-17 Méthode cryptographique de vérification des données
CA3128869A CA3128869A1 (fr) 2019-02-19 2020-02-17 Methode cryptographique de verification des donnees
JP2021549168A JP2022521525A (ja) 2019-02-19 2020-02-17 データを検証するための暗号方法
EP20704320.9A EP3928232A1 (fr) 2019-02-19 2020-02-17 Méthode cryptographique de vérification des données
KR1020217026080A KR20210153595A (ko) 2019-02-19 2020-02-17 암호화 데이터 검증 방법
US16/793,123 US11914754B2 (en) 2019-02-19 2020-02-18 Cryptographic method for verifying data
US16/934,376 US11956367B2 (en) 2019-02-19 2020-07-21 Cryptographic method for verifying data
US18/072,962 US20240089240A1 (en) 2019-02-19 2022-12-01 Cryptographic method for verifying data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1901648A FR3092923B1 (fr) 2019-02-19 2019-02-19 Méthode cryptographique de vérification des données
FR1901648 2019-02-19

Publications (2)

Publication Number Publication Date
FR3092923A1 true FR3092923A1 (fr) 2020-08-21
FR3092923B1 FR3092923B1 (fr) 2021-05-21

Family

ID=67810665

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1901648A Active FR3092923B1 (fr) 2019-02-19 2019-02-19 Méthode cryptographique de vérification des données

Country Status (9)

Country Link
US (1) US11914754B2 (fr)
EP (1) EP3928232A1 (fr)
JP (1) JP2022521525A (fr)
KR (1) KR20210153595A (fr)
CN (1) CN113811874A (fr)
AU (1) AU2020225314A1 (fr)
CA (1) CA3128869A1 (fr)
FR (1) FR3092923B1 (fr)
WO (1) WO2020169542A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3140457A1 (fr) 2022-10-04 2024-04-05 Marbeuf Conseil Et Recherche Méthode d’amélioration de hachage d’un fichier

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11956367B2 (en) 2019-02-19 2024-04-09 Bruno SANGLE-FERRIERE Cryptographic method for verifying data
FR3120130B1 (fr) 2021-02-22 2023-03-24 Marbeuf Conseil Et Rech Procédé de certification de la géolocalisation d’un récepteur
FR3120134A1 (fr) 2021-02-22 2022-08-26 Marbeuf Conseil Et Recherche Procédé de géolocalisation d’un récepteur
FR3125658B1 (fr) 2021-07-22 2023-07-21 Marbeuf Conseil Et Rech Système de communication quantique par photons intriqués
FR3125659B1 (fr) 2021-07-22 2023-07-21 Marbeuf Conseil Et Rech Système de communication quantique par photons intriqués

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1421548A1 (fr) * 2001-07-11 2004-05-26 Anoto AB Protocole de codage
CN101547184A (zh) 2008-03-24 2009-09-30 突触计算机系统(上海)有限公司 一种用于对网络传输的数据块进行验证的方法和装置
US20110246433A1 (en) 2010-03-31 2011-10-06 Xerox Corporation. Random number based data integrity verification method and system for distributed cloud storage
US20120057702A1 (en) * 2009-05-11 2012-03-08 Kazuhiko Minematsu Tag generation apparatus, tag verification apparatus, communication system, tag generation method, tag verification method, and recording medium
US20180324152A1 (en) * 2017-05-02 2018-11-08 Disney Enterprises, Inc. Securely recognizing mobile devices

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6104811A (en) * 1996-08-16 2000-08-15 Telcordia Technologies, Inc. Cryptographically secure pseudo-random bit generator for fast and secure encryption
US8892887B2 (en) * 2006-10-10 2014-11-18 Qualcomm Incorporated Method and apparatus for mutual authentication
US9747340B2 (en) * 2008-06-19 2017-08-29 Microsoft Technology Licensing, Llc Method and system of using a local hosted cache and cryptographic hash functions to reduce network traffic
US20110116096A1 (en) * 2009-03-31 2011-05-19 Welch James D Welch certainty principle
CN102473231A (zh) * 2010-06-21 2012-05-23 松下电器产业株式会社 内容复制系统、管理服务器、内容使用装置、方法、程序及集成电路
US10068200B1 (en) * 2011-01-22 2018-09-04 Mass Insight, Inc. Business and data processing system for providing mass spectrometric services
JP6080030B2 (ja) * 2012-01-23 2017-02-15 パナソニックIpマネジメント株式会社 電話転送システム、電話転送サーバおよび表示ユニット
IN2013MU01164A (fr) * 2013-03-26 2015-07-03 Tata Consultancy Services Ltd
AU2013101046A4 (en) * 2013-05-23 2013-09-19 Nowww.Us Pty Ltd A process for Encrypted Login to a Secure Computer Network, for the Creation of a Session of Encrypted Communications Between Computers and a Device Including a Mobile Phone Logged into a Network, for the Persistence of Encrypted Communications between Communication Devices, and for the Termination of Communications.
US9565022B1 (en) * 2013-07-02 2017-02-07 Impinj, Inc. RFID tags with dynamic key replacement
US9658831B2 (en) * 2014-03-11 2017-05-23 Sony Corporation Optical random number generator and method for generating a random number
JP6717131B2 (ja) * 2016-09-06 2020-07-01 富士通株式会社 制御プログラム、制御方法、情報処理装置、復号プログラム、復号方法、及び端末装置
US20180367540A1 (en) * 2016-10-21 2018-12-20 Wickr Inc. Controlling access to content
US10742405B2 (en) * 2016-12-16 2020-08-11 The Boeing Company Method and system for generation of cipher round keys by bit-mixers
US10491377B2 (en) * 2017-02-28 2019-11-26 Google Llc Hashing using data parallel instructions
US10833847B2 (en) * 2017-02-28 2020-11-10 Google Llc Cryptographic hash generated using data parallel instructions
EP3399761A1 (fr) * 2017-05-05 2018-11-07 Nagravision SA Gestion des droits
US10891366B1 (en) * 2017-08-18 2021-01-12 Jonetix Corporation Secure hardware signature and related methods and applications
JP6736686B1 (ja) * 2017-09-09 2020-08-05 アップル インコーポレイテッドApple Inc. 生体認証の実施
WO2018226265A1 (fr) * 2017-09-09 2018-12-13 Apple Inc. Mise en oeuvre d'une authentification biométrique
US11481786B2 (en) * 2017-10-03 2022-10-25 Sony Group Corporation Genuine instance of digital goods
US10944568B2 (en) * 2017-10-06 2021-03-09 The Boeing Company Methods for constructing secure hash functions from bit-mixers
EP3564846A1 (fr) * 2018-04-30 2019-11-06 Merck Patent GmbH Procédés et systèmes de reconnaissance et d'authentification automatiques d'objets
US10732861B2 (en) * 2018-07-26 2020-08-04 Qualtrics, Llc Generating and providing low-latency cached content
US20200110905A1 (en) * 2018-10-04 2020-04-09 Ca, Inc. Security hardened software footprint in a computing environment
US11570157B2 (en) * 2018-10-09 2023-01-31 Tfor Llc Transencrypting method and apparatus for removing information from data transmitted over networks and stored in data storage facilities
US10362169B1 (en) * 2018-10-17 2019-07-23 Capital One Services, Llc Call data management platform
WO2020079841A1 (fr) * 2018-10-19 2020-04-23 日本電気株式会社 Procédé et dispositif de gestion de qualité de nombres aléatoires
US10937339B2 (en) * 2019-01-10 2021-03-02 Bank Of America Corporation Digital cryptosystem with re-derivable hybrid keys
US11956367B2 (en) * 2019-02-19 2024-04-09 Bruno SANGLE-FERRIERE Cryptographic method for verifying data
US20220085984A1 (en) * 2020-09-14 2022-03-17 Amir Keyvan Khandani Methods and apparatus for randomized encryption, with an associated randomized decryption
US11803441B2 (en) * 2021-09-30 2023-10-31 International Business Machines Corporation Calibrated decoders for implementations of quantum codes

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1421548A1 (fr) * 2001-07-11 2004-05-26 Anoto AB Protocole de codage
CN101547184A (zh) 2008-03-24 2009-09-30 突触计算机系统(上海)有限公司 一种用于对网络传输的数据块进行验证的方法和装置
US20120057702A1 (en) * 2009-05-11 2012-03-08 Kazuhiko Minematsu Tag generation apparatus, tag verification apparatus, communication system, tag generation method, tag verification method, and recording medium
US20110246433A1 (en) 2010-03-31 2011-10-06 Xerox Corporation. Random number based data integrity verification method and system for distributed cloud storage
US20180324152A1 (en) * 2017-05-02 2018-11-08 Disney Enterprises, Inc. Securely recognizing mobile devices

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3140457A1 (fr) 2022-10-04 2024-04-05 Marbeuf Conseil Et Recherche Méthode d’amélioration de hachage d’un fichier

Also Published As

Publication number Publication date
US20210165914A1 (en) 2021-06-03
AU2020225314A1 (en) 2021-09-02
US11914754B2 (en) 2024-02-27
CN113811874A (zh) 2021-12-17
JP2022521525A (ja) 2022-04-08
EP3928232A1 (fr) 2021-12-29
WO2020169542A1 (fr) 2020-08-27
CA3128869A1 (fr) 2020-08-27
FR3092923B1 (fr) 2021-05-21
KR20210153595A (ko) 2021-12-17

Similar Documents

Publication Publication Date Title
FR3092923A1 (fr) Méthode cryptographique de vérification des données
US8082446B1 (en) System and method for non-repudiation within a public key infrastructure
US10075301B2 (en) Relational encryption for password verification
US11956367B2 (en) Cryptographic method for verifying data
EP3340531B1 (fr) Procédé de restauration d'un secret d'un utilisateur
GB2584455A (en) An encryption process
EP3185468B1 (fr) Procédé de transmission de données, procédé de réception de données, dispositifs et programmes correspondants
CN113162915B (zh) 基于区块链的交易方法、节点、电子设备、介质和系统
US10311240B1 (en) Remote storage security
CN108737087B (zh) 邮箱账号密码的保护方法及计算机可读存储介质
EP3769461A1 (fr) Procede d'emission de donnees depuis un vehicule automobile et procede de reception desdites donnees par un autre vehicule, a travers un canal de communication radio
CN113243093A (zh) 用于使用区块链的消息传输和检索的系统和方法
CN115361198A (zh) 解密方法、加密方法、装置、计算机设备和存储介质
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
FR3079989A1 (fr) Procédés, dispositifs et programmes d'ordinateur pour le chiffrement et le déchiffrement de données pour la transmission ou le stockage de données
US20220385453A1 (en) Secure file transfer
US11758393B1 (en) VPN authentication with forward secrecy
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
US20240089240A1 (en) Cryptographic method for verifying data
FR2786049A1 (fr) Procede de cryptographie a cle dynamique
US20210160078A1 (en) Out-of-band authentication in group communications
CN116846662A (zh) 一种网络数据的安全操作方法、装置、设备及存储介质
CN116684198A (zh) 一种基于http接口加解密方法、装置、电子设备和存储介质
Saberi Pirouz et al. FriendlyMail: Confidential and Verified Emails among Friends
FR3044847A1 (fr) Procede d'echange de donnees au sein d'un groupe d'entites electroniques

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200821

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6