EP4062584A1 - Procede securise d'echange de donnees entre un terminal et un serveur - Google Patents

Procede securise d'echange de donnees entre un terminal et un serveur

Info

Publication number
EP4062584A1
EP4062584A1 EP20821347.0A EP20821347A EP4062584A1 EP 4062584 A1 EP4062584 A1 EP 4062584A1 EP 20821347 A EP20821347 A EP 20821347A EP 4062584 A1 EP4062584 A1 EP 4062584A1
Authority
EP
European Patent Office
Prior art keywords
terminal
message
cryptographic module
white box
challenge
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.)
Pending
Application number
EP20821347.0A
Other languages
German (de)
English (en)
Inventor
Sandra RASOAMIARAMANANA
Gilles Macario-Rat
Marine MINIER
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.)
Orange SA
Original Assignee
Orange SA
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
Application filed by Orange SA filed Critical Orange SA
Publication of EP4062584A1 publication Critical patent/EP4062584A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic 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/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3271—Cryptographic 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 challenge-response
    • H04L9/3278—Cryptographic 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 challenge-response using physically unclonable functions [PUF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to the field of secure data exchange in a telecommunications network.
  • the invention is aimed at a secure method of exchanging data that is less vulnerable than those of the prior art.
  • the invention therefore aims at a new secure mechanism for exchanging data between two pieces of equipment.
  • the invention relates to a method for providing a cryptographic module in a white box.
  • This method is implemented by a server comprising a cryptographic module configured to encrypt or decrypt a message from input parameters comprising said message, a symmetric key and a response to a challenge.
  • Said process comprises:
  • said white box cryptographic module being a white box implementation of the server's cryptographic module for said symmetric key obtained for this terminal, said white box cryptographic module being configured to encrypt or decrypt a message from said symmetric key embedded in this module and from input parameters comprising a message and a response to a challenge;
  • the invention relates to a server comprising: - a cryptographic module configured to encrypt or decrypt a message from input parameters comprising said message, a response to a challenge and a symmetric key,
  • a module for obtaining a symmetric key for a terminal a module for generating a white box cryptographic module, said white box cryptographic module being a white box implementation of said server cryptographic module for said symmetric key obtained for this terminal, said white box cryptographic module being configured to encrypt or decrypt a message from said symmetric key embedded in this module and from input parameters comprising a message and a response to a challenge, and
  • the invention relates to a method for obtaining a white box cryptographic module.
  • This method is implemented by a terminal. It comprises :
  • a white box cryptographic module constituting a white box implementation of the cryptographic module of said server for said symmetric key
  • said white box cryptographic module being configured to encrypt or decrypt a message from said embedded symmetric key in this module and input parameters including a message and a response to a challenge.
  • the invention relates to a terminal comprising:
  • a module for sending a terminal identifier to a server comprising a cryptographic module configured to encrypt or decrypt a message from input parameters comprising said message, a response to a challenge and a symmetric key;
  • the invention thus proposes a secure mechanism for exchanging data between a server and a terminal in which the cryptographic functions of encryption and / or decryption of the terminal are implemented according to a white box cryptography mechanism.
  • the symmetric key used by the terminal for the implementation of the cryptographic functions of encryption and / or decryption is not stored in a memory of the terminal but hidden in the code of the white box cryptographic module generated by the server for this terminal.
  • the symmetric key cannot therefore be obtained by a malicious third party who would attack or spy on the terminal during its execution.
  • the invention is therefore particularly suitable when the terminals are mobile terminals, connected objects or any device vulnerable to attacks, in particular to viruses.
  • white box cryptography those skilled in the art can refer to the document “Understanding White Box Cryptography, White Paper”, published at the address: https://www2.gemalto.com / email / 2012 / SRM / whitebox / public / pdf / WP_Whitebox_Cryptograph y _ FR _ A4 _ v4_web_ 1 _.pdf.
  • the cryptographic module implemented by the server is not implemented in a white box, such a server being sufficiently secure and less exposed to attacks aimed at fraudulently obtaining the symmetric key.
  • This server is said to be trusted. This feature allows faster execution of server-side cryptographic functions.
  • the method for obtaining a white box cryptographic module implemented by the terminal further comprises:
  • the method of supplying a white box cryptographic module implemented by the server comprises a step of receiving and recording at least one challenge / response pair coming from said terminal .
  • a non-clonable physical function of the terminal is a characteristic of a hardware component of the terminal which makes it possible to uniquely differentiate an instance of a terminal among other terminals of the same brand, of the same model, produced in the same way. same time. It is indeed difficult to manufacture a terminal having the same characteristics as another terminal.
  • the non-cloning physical function of a terminal can consist of a camera of the terminal.
  • a camera in fact necessarily induces imperfections or noise in the images it produces, due to the characteristics of the sensor, for example the photodiodes of this sensor.
  • the terminal can be considered.
  • other sensors of the terminal than the camera can be used, such as a gyroscope, an accelerometer, a microphone, etc.
  • this non-cloning physical function can be implemented by an electronic chip integrated into the terminal.
  • non-clonable physical function is attached to the characteristics of the terminal and is specific to the terminal.
  • the invention thus proposes to use a non-clonable function of the terminal to generate challenge / response pairs, these pairs in particular allowing the terminal to provide the server with proof that it is indeed a terminal known to the server.
  • the answer to the challenge is a secret shared between the enrolled terminal and the server and only the enrolled terminal is able to determine it based on a challenge.
  • the invention also proposes to use the defi / response pairs thus obtained in the cryptographic mechanisms for encryption / decryption of the messages exchanged between the terminal and the server.
  • the invention thus relates to a method for encrypting a message implemented by a terminal, this method comprising:
  • a white box cryptographic module from a server, said white box cryptographic module being configured to encrypt or decrypt a message from a symmetric key specific to the terminal and embedded in this module and input parameters comprising a message and a response to a challenge
  • the invention relates to a method for decrypting an encrypted message received from a terminal, this method being implemented by a server and comprising:
  • a decryption step implemented by providing said symmetric key, the response to the challenge and the encrypted message as input to the cryptographic module of said server, the result of said decryption step comprising a clear message.
  • the invention also relates to a method of encrypting a message implemented by a server, said encrypted message being intended to be sent to a terminal, this method comprising:
  • a data encryption step comprising obtaining a symmetrical key of said terminal and a response to a challenge, received from said terminal during a terminal enrollment phase, during which the server generated and supplied to the terminal a white box cryptographic module, said white box cryptographic module being a white box implementation of a server cryptographic module for said symmetric key, said module white box cryptographic being configured to encrypt or decrypt a message from input parameters comprising a message, a response to a challenge, and said symmetric key embedded in said white box cryptographic module, said response received from the corresponding terminal to a response from a challenge / response pair;
  • an encryption step implemented by providing as input to the cryptographic module of said server said symmetric key, said response and said message;
  • the invention also relates to a method for decrypting an encrypted message implemented by a terminal, this method comprising:
  • a white box cryptographic module from a server, said white box cryptographic module being configured to encrypt or decrypt a message from a symmetric key specific to the terminal and embedded in this module and input parameters comprising a message and a response to a challenge
  • the invention is also aimed at a computer program on an information medium, this program being capable of being implemented in a server or more generally in a computer, this program comprising instructions adapted to the implementation. implementation of the steps of a method of supplying a cryptographic module in a white box as presented above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a terminal or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a method for obtaining a cryptographic module in a white box as presented above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a server, in a terminal or more generally in a computer, this program comprising instructions adapted to the setting. implementing the steps of an encryption method or of a decryption method as presented above.
  • These programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable shape.
  • the invention also relates to an information or recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet type network.
  • the information or recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 shows a terminal and a server according to the invention, in their environment
  • FIG. 2 functionally shows a server according to a particular embodiment of the invention
  • FIG. 3A shows a first use of a cryptographic module that can be implemented in the server of Figure 2;
  • FIG. 3B shows a second use of a cryptographic module that can be implemented in the server of Figure 2;
  • FIG. 4 functionally shows a terminal according to a particular embodiment of the invention
  • FIG. 5A shows a first use of a white box cryptographic module that can be implemented in the terminal of Figure 4;
  • FIG. 5B shows a second use of a white box cryptographic module that can be implemented in the terminal of Figure 4;
  • FIG. 6 represents an example of a probabilistic module comprising a non-clonable function and which can be implemented in the terminal of FIG. 4;
  • - Figure 7 shows in the form of a flowchart of the encryption and decryption methods a method that can be implemented by the terminal of Figure 4 and by the server of Figure 2, these methods conforming to particular embodiments of the invention;
  • FIG. 8A is a physical representation of a terminal according to a particular embodiment of the invention.
  • FIG. 8B is a hardware representation of a server according to a particular embodiment of the invention.
  • FIG. 1 represents a TRM terminal conforming to a particular embodiment of the invention and an SRV server conforming to a particular embodiment of the invention in their environment, able to communicate by a NET telecommunications network, to exchange each other. messages in a secure manner, using a symmetric key cryptographic mechanism.
  • the SRV server comprises a COM communication module and a CRY cryptographic module.
  • the cryptographic module CRY of the SRV server comprises:
  • an ENC encryption module configured to obtain a response to this challenge as a function of a challenge and to encrypt with a symmetric key Ku received at the input of this module, a plain msg message received at the input of this module, and the response to the challenge, the encrypted message being noted [msg];
  • a decryption module DEC configured to obtain a response to this challenge as a function of a challenge and to decrypt with the symmetric key Ku received at the input of this module, an encrypted message [msg] received at the input of this module, the decrypted message being noted msg.
  • the cryptographic module CRY could be configured to implement only decryption functions or only encryption functions and only include the corresponding DEC or ENC module.
  • the TRM terminal comprises:
  • the CRYBBu cryptographic module in white box of the TRM terminal comprises: - a white box encryption ENCBBu module, to obtain a response to this challenge as a function of a challenge and to encrypt, as a function of the response to the challenge and the symmetric key Ku, an msg message received at the input of this module , the encrypted message being noted [msg]; and
  • DECBBu white box decryption module to obtain a response to this challenge as a function of a challenge and to decrypt with the symmetric key Ku and the response to the challenge an encrypted message [msg] received at the input of this module, the decrypted message being noted msg.
  • the symmetric key Ku is not received at the input of the CRYBBu cryptographic module but is secretly buried in this module.
  • secretly buried we mean that this symmetric key is not accessible by a malicious third party who would attack or spy on the terminal while performing encryption or decryption operations.
  • the CRYBBu cryptographic module constitutes a white box implementation of the CRY cryptographic module of the SRV server, for the symmetric key Ku.
  • the CRYBBu cryptographic module constitutes a white box implementation of the CRY cryptographic module of the SRV server, for the symmetric key Ku.
  • the CRYBBu white box cryptographic module could be configured to implement only decryption functions or only encryption functions and include only the corresponding DECBBu or ENCBBu white box module.
  • the communication means COM of the SRV server and of the TRM terminal are adapted to allow the TRM terminal to send an identifier u from this terminal to the SRV server to authenticate itself with this server.
  • the SRV server comprises an MGBB module configured for:
  • the COM communication means of the SRV server and of the TRM terminal are adapted to allow the SRV terminal to send the cryptographic module in the CRYBBu white box to the TRM terminal, either as is or integrated into an APP application.
  • the TRM terminal includes an MI installation module configured to be able to install the CRYBBu cryptographic module or the APP application in a rewritable non-volatile memory of this terminal.
  • the TRM terminal comprises a probabilistic module MPROB which will now be described with reference to FIG. 6.
  • This MPROB probabilistic module includes a non-clonable PUF physical function.
  • this MPROB probabilistic module is configured for:
  • variable parameter that is to say a challenge xi
  • this physical function is a camera of the terminal. It has hardware characteristics specific to the TRM terminal.
  • this MPROB probabilistic module is configured for:
  • variable parameter for example an exposure duration xi corresponding to the challenge
  • the MPROB probabilistic module comprises a corrective filter FC configured to generate a signature yi, that is to say a response to the challenge xi, from the noisy signature y'i, this signature yi being identical for noisy signatures y'ij obtained for the same exposure time xi.
  • this FC filter is secret and specific to the TRM terminal.
  • the MPROB probabilistic module is configured to output the non-noisy signature yi, as a response to the challenge xi.
  • the noisy signature y’i is an imprint of a darkness signal known per se by those skilled in the art of photographic sensors.
  • the noisy signature yi is obtained by projecting the noisy signature y’i onto a binary sequence, as in a manner known to a person skilled in the art of coding.
  • terminals can be considered. For example, this involves using other sensors of a terminal, such as a gyroscope, an accelerometer, a microphone, etc. It may also be an electronic chip integrated into the terminal implementing this function. non-clonable physical.
  • non-clonable physical function is attached to the characteristics of the terminal and is specific to the terminal.
  • the terminal TRM registers with the server SRV by providing it with its identifier u. This identifier is received by the server SRV during a step F 10.
  • the SRV server authenticates the user during a step F20.
  • the SRV server If the authentication is successful, during a step F30, the SRV server:
  • the SRV server which acts as a trusted third party, obtains a set of challenges xi at random.
  • the SRV server sends the application APP and the set of challenges xi to the TRM terminal during the same step F40.
  • the TRM terminal receives them during a step E20.
  • the TRM terminal During a step E30, the TRM terminal generates a response yi for each challenge xi received from the trusted third-party SRV server using the probabilistic function MPROB. It thus forms challenge / response pairs ⁇ xi, yi ⁇ .
  • a response yi is obtained as a function of the challenge, the associated response yi being the noiseless signature obtained by the probabilistic module MPROB for this input parameter xi.
  • the TRM terminal sends the ⁇ challenge, response ⁇ pairs to the SRV server during this same step E30. They are received by the SRV server and recorded in the BDS database during a step F50.
  • Steps E10 to E30 and F10 to F50 constitute an enrollment phase referenced ENR in Figure 7.
  • this operation consists in taking an image with the exposure time xi, calculate a noisy signature y'i of the dark signal of this image, and obtain the challenge yi by projecting the noisy signature y'i onto a binary chain;
  • challenge xi is not sent to the SRV server.
  • the SRV server obtains the symmetric key Ku in its BDS database from the identifier u. It obtains from its BDS database the response yi corresponding to challenge xi. It decrypts the encrypted message [msg] using its decryption module DEC as a function of the symmetric key Ku and the response yi and retrieves a message. If yi does correspond to the value used by the terminal, then the message retrieved corresponds to the plain msg message.
  • the SRV server wishes to send an msg message to the TRM terminal in a secure manner.
  • the SRV server During a step F80, the SRV server:
  • the TRM terminal During a step E60, the TRM terminal:
  • MPROB probabilistic module
  • the decrypted message corresponds to the plain msg message.
  • Figure 8A shows the TRM terminal of Figure 1.
  • this TRM terminal has the architecture of a computer. It comprises in particular a processor 10, a random access memory of the RAM 11 type, a read-only memory of the ROM 12 type, a rewritable non-volatile memory of the FLASH type 13 and communication means COM.
  • the application APP is recorded in the non-volatile memory 13.
  • the instructions of this application and in particular those of the CRYBBu cryptographic module in white box are executed by the processor 10.
  • the non-volatile memory 13 also stores the identifier u of the terminal.
  • ROM 12 constitutes a recording medium according to the invention. It includes a PGT computer program according to the invention. This PGT program comprises in particular instructions for, when they are executed by the processor 10:
  • Figure 8B shows the SRV server of Figure 1.
  • this SRV server has the architecture of a computer. It comprises in particular a processor 20, a random access memory of the RAM 21 type, a read-only memory of the ROM type 22, a rewritable non-volatile memory of the FLASH type 23 and communication means COM.
  • the non-volatile memory 23 also stores the BDS database.
  • ROM 22 constitutes a recording medium according to the invention. It includes a PGS computer program according to the invention. This PGS program comprises in particular instructions for, when they are executed by the processor 20:

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Dans ce procédé sécurisé d'échanges de données entre un terminal (TRM) et un serveur (SRV) : - le serveur utilise un module cryptographique (CRY) configuré pour chiffrer ou déchiffrer un message à partir de paramètres d'entrée comportant le message, une réponse à un défi et une clé symétrique (Ku); et - le terminal utilise un module cryptographique en boite blanche (CRYBBu) constituant une implémentation en boite blanche du module cryptographique (CRY) dudit serveur (SRV) pour cette clé symétrique (Ku).

Description

Procédé sécurisé d’échange de données entre un terminal et un serveur
La présente invention se situe dans le domaine de l’échange sécurisé de données dans un réseau de télécommunications. Dans l’état actuel de la technique, il est usuel, pour garantir la confidentialité des échanges, que l’émetteur chiffre les données avec une clé cryptographique avant de les envoyer dans le réseau, le récepteur comportant des moyens cryptographiques pour déchiffrer les données reçues avec une clé identique ou compatible avec celle de l’émetteur.
Ces mécanismes très répandus présentent une fragilité importante si les clés cryptographiques d’un équipement peuvent être obtenues par un tiers malveillant en attaquant directement l’équipement ou en surveillant son exécution.
L’invention vise un procédé sécurisé d’échange de données moins vulnérable que ceux de l’art antérieur. L’invention vise par conséquent un nouveau mécanisme sécurisé d’échange de données entre deux équipements.
Elle est présentée ci-après pour un échange sécurisé entre un terminal et un serveur mais elle pourrait s’appliquer à d’autres équipements dès lors que l’un de ces deux équipements est moins vulnérable aux attaques que l’autre de ces deux équipements. Plus précisément, le terminal est considéré comme n’étant pas de confiance.
Plus précisément, et selon un premier aspect, l’invention concerne un procédé de fourniture d’un module cryptographique en boite blanche.
Ce procédé est mis en œuvre par un serveur comportant un module cryptographique configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une clé symétrique et une réponse à un défi. Ledit procédé comporte :
- une étape d’obtention d’une clé symétrique pour un terminal ;
- une étape de génération d’un module cryptographique en boite blanche, ledit module cryptographique en boite blanche étant une implémentation en boite blanche du module cryptographique du serveur pour ladite clé symétrique obtenue pour ce terminal, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi ; et
- une étape de fourniture dudit module cryptographique en boite blanche audit terminal.
Corrélativement, l’invention concerne un serveur comportant : - un module cryptographique configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique,
- un module d’obtention d’une clé symétrique pour un terminal ; - un module de génération d’un module cryptographique en boite blanche, ledit module cryptographique en boite blanche étant une implémentation en boite blanche dudit module cryptographique du serveur pour ladite clé symétrique obtenue pour ce terminal, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi , et
- un module de fourniture dudit module cryptographique en boite blanche audit terminal.
Selon un deuxième aspect, l’invention concerne un procédé d’obtention d’un module cryptographique en boite blanche. Ce procédé est mis en œuvre par un terminal. Il comporte :
- une étape d’envoi d’un identifiant du terminal à un serveur comportant un module cryptographique configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique ;
- une étape de réception d’un module cryptographique en boite blanche constituant une implémentation en boite blanche du module cryptographique dudit serveur pour ladite clé symétrique, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi.
Corrélativement, l’invention concerne un terminal comportant :
- un module d’envoi d’un identifiant du terminal à un serveur comportant un module cryptographique configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique ;
- un module de réception d’un module cryptographique en boite blanche constituant une implémentation en boite blanche du module cryptographique dudit serveur pour ladite clé symétrique, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi.
L’invention propose ainsi un mécanisme sécurisé d’échanges de données entre un serveur et un terminal dans lequel les fonctions cryptographiques de chiffrement et/ou de déchiffrement du terminal sont implémentées selon un mécanisme de cryptographie en boite blanche.
Ainsi, la clé symétrique utilisée par le terminal pour la mise en œuvre des fonctions cryptographiques de chiffrement et/ou de déchiffrement n’est pas mémorisée dans une mémoire du terminal mais cachée dans le code du module cryptographique en boite blanche généré par le serveur pour ce terminal.
La clé symétrique ne peut donc pas être obtenue par un tiers malveillant qui attaquerait ou espionnerait le terminal pendant son exécution.
L’invention est donc particulièrement adaptée lorsque les terminaux sont des terminaux mobiles, des objets connectés ou tout dispositif vulnérable aux attaques, notamment aux virus. Pour plus de renseignement sur la notion de cryptographie en boite blanche, l’homme du métier peut se reporter au document « Comprendre la cryptographie en White Box, livre blanc», publié à l’adresse : https://www2.gemalto.com/email/2012/SRM/whitebox/public/pdf/WP_Whitebox_Cryptograph y _ FR _ A4 _ v4_web_ 1 _.pdf.
Conformément à l’invention, le module cryptographique mis en œuvre par le serveur n’est pas implémenté en boite blanche, un tel serveur étant suffisamment sécurisé et moins exposé aux attaques qui viseraient à obtenir frauduleusement la clé symétrique. Ce serveur est dit de confiance. Cette caractéristique permet une exécution plus rapide des fonctions cryptographiques côté serveur.
Dans un mode de réalisation de l’invention, le procédé d’obtention d’un module cryptographique en boite blanche mis en œuvre par le terminal comporte en outre :
- une étape d’obtention d’au moins un couple défi/réponse, d’envoi dudit au moins un couple défi/réponse audit serveur,
- ladite réponse étant obtenue à partir dudit défi et d’une fonction probabiliste mettant en œuvre une fonction physique non clonable du terminal.
Dans ce mode de réalisation de l’invention, le procédé de fourniture d’un module cryptographique en boite blanche mis en œuvre par le serveur comporte une étape de réception et d’enregistrement d’au moins un couple défi/réponse en provenance dudit terminal.
On rappelle qu’une fonction physique non clonable du terminal est une caractéristique d’un composant matériel du terminal qui permet de différencier de façon unique une instance d’un terminal parmi d’autres terminaux de la même marque, du même modèle, produits au même moment. Il est en effet difficile de fabriquer un terminal présentant les mêmes caractéristiques qu’un autre terminal.
Dans un mode de réalisation particulier, la fonction physique non clonable d’un terminal peut être constituée par une caméra du terminal. Une telle caméra induit en effet nécessairement des imperfections ou du bruit dans les images qu’elle produit, en raison des caractéristiques du capteur, par exemple des photodiodes de ce capteur.
D’autres fonctions physiques du terminal peuvent être envisagées. Selon un premier exemple, d’autres capteurs du terminal que la caméra peuvent être utilisés, comme un gyroscope, un accéléromètre, un microphone,... Selon un deuxième exemple, cette fonction physique non clonable peut être mise en œuvre par une puce électronique intégrée au terminal.
Il est ici souligné que la fonction physique non clonable est attachée aux caractéristiques du terminal et est propre au terminal.
L’invention propose ainsi d’utiliser une fonction non clonable du terminal pour générer des couples défi/réponse, ces couples permettant en particulier au terminal de fournir au serveur une preuve qu’il est bien un terminal connu du serveur. La réponse au défi correspond à un secret partagé entre le terminal enrôlé et le serveur et seul le terminal enrôlé est capable de le déterminer en fonction d’un défi.
L’invention propose également d’utiliser les couples défï/réponse ainsi obtenus dans les mécanismes cryptographiques de chiffrement/déchiffrement des messages échangés entre le terminal et le serveur.
L’invention vise ainsi un procédé de chiffrement d’un message mis en œuvre par un terminal, ce procédé comportant :
- une étape d’obtention d’un module cryptographique en boite blanche en provenance d’un serveur, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir d’une clé symétrique propre au terminal et enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi,
- une étape d’obtention d’une réponse à un défi par mise en œuvre d’une fonction probabiliste mettant en œuvre une fonction physique non clonable du terminal ; et
- une étape d’envoi audit serveur du message chiffré par ledit module cryptographique en boite blanche en fonction de la réponse au défi.
De même l’invention vise un procédé de déchiffrement d’un message chiffré reçu en provenance d’un terminal, ce procédé étant mis en œuvre par un serveur et comportant :
- une étape d’envoi d’un défi au terminal et de réception en provenance du terminal d’un message chiffré au moyen d’un module cryptographique en boite blanche fourni par ledit serveur, ce module cryptographique en boite blanche étant une implémentation en boite blanche d’un module cryptographique dudit serveur pour une clé symétrique du terminal, ledit module cryptographique en boite blanche étant configuré par le serveur pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant un message et une réponse à un défi, et de ladite clé symétrique enfouie dans ledit module cryptographique en boite blanche, ladite réponse reçue en provenance du terminal correspondant à une réponse d’un couple défi/réponse reçu du terminal dans une phase préalable d’enrôlement;
- une étape de déchiffrement mise en œuvre en fournissant ladite clé symétrique, la réponse au défi et le message chiffré en entrée du module cryptographique dudit serveur, le résultat de ladite étape de déchiffrement comportant un message en clair.
De la même façon, l’invention vise aussi un procédé de chiffrement d’un message mis en œuvre par un serveur, ledit message chiffré étant destiné à être envoyé à un terminal, ce procédé comportant :
- une étape de chiffrement de données comportant l’obtention d’une clé symétrique dudit terminal et d’une réponse à un défi, reçu dudit terminal au cours d’une phase d’enrôlement du terminal, au cours de laquelle le serveur a généré et fourni au terminal un module cryptographique en boite blanche, ledit module cryptographique en boite blanche étant une implémentation en boite blanche d’un module cryptographique du serveur pour ladite clé symétrique, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant un message , une réponse à un défi, et ladite clé symétrique enfouie dans ledit module cryptographique en boite blanche, ladite réponse reçue en provenance du terminal correspondant à une réponse d’un couple défi/réponse ;
- une étape de chiffrement mise en œuvre en fournissant en entrée du module cryptographique dudit serveur ladite clé symétrique, ladite réponse et ledit message ; et
- une étape d’envoi du défi et d’un message chiffré obtenu audit terminal.
De même, l’invention vise également un procédé de déchiffrement d’un message chiffré mis en œuvre par un terminal, ce procédé comportant :
- une étape d’obtention d’un module cryptographique en boite blanche en provenance d’un serveur, ledit module cryptographique en boite blanche étant configuré pour chiffrer ou déchiffrer un message à partir d’une clé symétrique propre au terminal et enfouie dans ce module et de paramètres d’entrée comportant un message et une réponse à un défi,
- une étape de réception, en provenance dudit serveur d’un défi et d’un message chiffré ;
- une étape d’obtention d’une réponse au défi reçu par mise en œuvre d’une fonction probabiliste mettant en œuvre une fonction physique non clonable du terminal ;
- une étape de déchiffrement du message chiffré par ledit module cryptographique en boite blanche pour obtenir ledit message en clair.
Dans un mode particulier de réalisation, les différentes étapes des procédés mentionnés ci- dessus sont déterminées par des instructions de programmes d’ordinateurs.
En conséquence, l’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de fourniture d’un module cryptographique en boite blanche tel que présenté ci-dessus.
L’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d’obtention d’un module cryptographique en boite blanche tel que présenté ci- dessus.
L’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un serveur, dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de chiffrement ou d’un procédé de déchiffrement tel que présenté ci-dessus. Ces programmes peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'informations ou d’enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus.
Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur.
D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 représente un terminal et un serveur conformes à l’invention, dans leur environnement ;
- la figure 2 représente de façon fonctionnelle un serveur conforme à un mode particulier de réalisation de l’invention ;
- la figure 3A représente un premier usage d’un module cryptographique pouvant être mis en œuvre dans le serveur de la figure 2 ;
- la figure 3B représente un deuxième usage d’un module cryptographique pouvant être mis en œuvre dans le serveur de la figure 2 ;
- la figure 4 représente de façon fonctionnelle un terminal conforme à un mode particulier de réalisation de l’invention ;
- la figure 5A représente un premier usage d’un module cryptographique en boite blanche pouvant être mis en œuvre dans le terminal de la figure 4 ;
- la figure 5B représente un deuxième usage d’un module cryptographique en boite blanche pouvant être mis en œuvre dans le terminal de la figure 4 ;
- la figure 6 représente un exemple de module probabiliste comportant une fonction non clonable et pouvant être mis en œuvre dans le terminal de la figure 4 ; - la figure 7 représente sous forme d’ordinogramme des méthodes de chiffrement et de déchiffrement une méthode pouvant être mis en œuvre par le terminal de la figure 4 et par le serveur de la figure 2, ces méthodes étant conformes à des modes particuliers de réalisation de l’invention ;
- la figure 8A est une représentation matérielle d’un terminal conforme à un mode particulier de réalisation de l’invention ; et
- la figure 8B est une représentation matérielle d’un serveur conforme à un mode particulier de réalisation de l’invention.
La figure 1 représente un terminal TRM conforme à un mode particulier de réalisation de l’invention et un serveur SRV conforme un mode particulier de réalisation de l’invention dans leur environnement, aptes à communiquer par un réseau de télécommunications NET, pour s’échanger des messages de façon sécurisée, selon un mécanisme cryptographique à clé symétrique.
Dans le mode de réalisation décrit ici, et comme représenté à la figure 2, le serveur SRV comporte un module de communication COM et un module cryptographique CRY.
Dans le mode de réalisation décrit, et comme représenté aux figures 3A et 3B, le module cryptographique CRY du serveur SRV comporte :
- un module ENC de chiffrement, configuré pour obtenir en fonction d’un défi une réponse à ce défi et pour chiffrer avec une clé symétrique Ku reçue en entrée de ce module, un message en clair msg reçu en entrée de ce module, et la réponse au défi, le message chiffré étant noté [msg] ; et
- un module DEC de déchiffrement, configuré pour obtenir en fonction d’un défi une réponse à ce défi et pour déchiffrer avec la clé symétrique Ku reçue en entrée de ce module, un message chiffré [msg] reçu en entrée de ce module, le message déchiffré étant noté msg.
En variante, le module cryptographique CRY pourrait être configuré pour ne mettre en œuvre que des fonctions de déchiffrement ou que des fonctions de chiffrement et ne comprendre que le module DEC ou ENC correspondant.
Dans le mode de réalisation décrit ici, et comme représenté à la figure 4, le terminal TRM comporte :
- un module de communication COM compatible avec le module de communication COM du serveur SRV ; et
- un module cryptographique CRYBBu en boite blanche.
Dans le mode de réalisation décrit, et comme représenté aux figures 5A et 5B, le module cryptographique CRYBBu en boite blanche du terminal TRM comporte : - un module ENCBBu de chiffrement en boite blanche, pour obtenir en fonction d’un défi une réponse à ce défi et pour chiffrer, en fonction de la réponse au défi et de la clé symétrique Ku, un message msg reçu en entrée de ce module, le message chiffré étant noté [msg] ; et
- un module DECBBu de déchiffrement en boite blanche, pour obtenir en fonction d’un défi une réponse à ce défi et pour déchiffrer avec la clé symétrique Ku et la réponse au défi un message chiffré [msg] reçu en entrée de ce module, le message déchiffré étant noté msg.
Conformément aux mécanismes cryptographiques en boite blanche, la clé symétrique Ku n’est pas reçue en entrée du module cryptographique CRYBBu mais enfouie de façon secrète dans ce module. Par enfouie de façon secrète, on entend que cette clé symétrique n’est pas accessible par un tiers malveillant qui attaquerait ou espionnerait le terminal pendant l’exécution des opérations de chiffrement ou de déchiffrement.
Le module cryptographique CRYBBu constitue une implémentation en boite blanche du module cryptographique CRY du serveur SRV, pour la clé symétrique Ku. Autrement dit et par exemple :
- un message [msg] chiffré obtenu par la module CRY du serveur lorsqu’il prend en entrée la clé symétrique Ku, une réponse à un défi et un message msg donné; et
- le message [msg] obtenu par le module cryptographique CRYBBu lorsqu’il prend en entrée ce même message msg et une réponse à ce défi
Le module cryptographique en boite blanche CRYBBu pourrait être configuré pour ne mettre en œuvre que des fonctions de déchiffrement ou que des fonctions de chiffrement et ne comprendre que le module en boite blanche DECBBu ou ENCBBu correspondant.
Les moyens COM de communication du serveur SRV et du terminal TRM sont adaptés pour permettre au terminal TRM d’envoyer un identifiant u de ce terminal au serveur SRV pour s’authentifier auprès de ce serveur.
Dans le mode de réalisation décrit ici, et comme représenté à la figure 2, le serveur SRV comporte un module MGBB configuré pour :
- générer une clé symétrique Ku pour le terminal TRM sur réception de l’identifiant u de ce terminal ;
- générer le module cryptographique en boite blanche CRYBBu pour cette clé Ku.
Les moyens COM de communication du serveur SRV et du terminal TRM sont adaptés pour permettre au terminal SRV d’envoyer le module cryptographique en boite blanche CRYBBu au terminal TRM, soit tel quel, soit intégré dans une application APP.
Dans le mode de réalisation décrit ici, le terminal TRM comporte un module d’installation MI configuré pour pouvoir installer le module cryptographique CRYBBu ou l’application APP dans une mémoire non volatile réinscriptible de ce terminal.
Comme représenté à la figure 4, le terminal TRM comporte un module probabiliste MPROB qui va maintenant être décrit en référence à la figure 6. Ce module probabiliste MPROB comporte une fonction physique non clonable PUF.
Dans le mode de réalisation décrit ici, ce module probabiliste MPROB est configuré pour :
- recevoir en entrée un paramètre variable, c’est-à-dire un défi xi ;
- calculer une réponse à ce défi yi.
Dans l’exemple de réalisation décrit ici, cette fonction physique est une caméra du terminal. Elle présente des caractéristiques matérielles propres au terminal TRM.
Dans le mode de réalisation décrit ici, ce module probabiliste MPROB est configuré pour :
- recevoir en entrée un paramètre variable, par exemple une durée d’exposition xi correspondant au défi ;
- acquérir une image avec la caméra PUF pendant la durée d’exposition xi ;
- calculer une signature y’i de cette image.
Dans un mode de réalisation particulier, il se peut que la signature y’i soit bruitée et que pour des images acquises avec une même durée d’exposition xi, des signatures y’ij différentes soient obtenues. Dans ce mode de réalisation, le module probabiliste MPROB comporte un filtre correcteur FC configuré pour générer une signature yi, c’est-à-dire une réponse au défi xi, à partir de la signature bruitée y’i, cette signature yi étant identique pour des signatures bruitées y’ij obtenues pour la même durée d’exposition xi. Dans un mode de réalisation particulier, ce filtre FC est secret et propre au terminal TRM. Ainsi le débruitage, secret, permet d’augmenter la sécurisation du chiffrement et du déchiffrement de message.
Le module probabiliste MPROB est configuré pour fournir en sortie la signature yi non bruitée, en tant que réponse au défi xi.
Dans le mode de réalisation décrit ici, la signature bruitée y’i est une empreinte d’un signal d’obscurité connu en soi par l’homme du métier des capteurs photographiques.
Dans le mode de réalisation décrit ici, la signature non bruitée yi est obtenue en projetant la signature bruitée y’i sur une suite binaire, comme de façon connue par un homme du métier du codage.
D’autres fonctions physiques du terminal peuvent être envisagées. Il s’agit par exemple d’utiliser d’autres capteurs d’un terminal, comme un gyroscope, un accéléromètre, un microphone,... Il peut également s’agir d’une puce électronique intégrée au terminal mettant en œuvre cette fonction physique non clonable.
On rappelle que la fonction physique non clonable est attachée aux caractéristiques du terminal et est propre au terminal.
On suppose maintenant que l’utilisateur du terminal TRM souhaite souscrire, auprès du serveur SRV, à un service mettant en œuvre un mécanisme d’échange de données sécurisé conforme à l’invention, par exemple un service de paiement. Au cours, d’une étape E10, et comme représenté à la figure 7, le terminal TRM s’enregistre auprès du serveur SRV en lui fournissant son identifiant u. Cet identifiant est reçu par le serveur SRV au cours d’une étape F 10.
Dans le mode de réalisation décrit ici, le serveur SRV authentifie l’utilisateur au cours d’une étape F20.
Si l’authentification réussit, au cours d’une étape F30, le serveur SRV :
- génère une clé symétrique Ku pour le terminal TRM ;
- enregistre cette clé symétrique Ku en association avec l’identifiant u du terminal TRM dans une base de données BDS ;
- génère un module cryptographique en boite blanche CRYBBu pour cette clé symétrique Ku ; et
- intègre ce module cryptographique en boite blanche CRYBBu dans une application APP adaptée au service souhaité, en l’occurrence au service de paiement sécurisé.
Au cours d’une étape F35, le serveur SRV, qui agit comme tiers de confiance, obtient un ensemble de défis xi de manière aléatoire.
Dans le mode de réalisation décrit ici, le serveur SRV envoie l’application APP et l’ensemble des défis xi au terminal TRM au cours d’une même étape F40. Le terminal TRM les reçoit au cours d’une étape E20.
Au cours d’une étape E30, le terminal TRM génère une réponse yi pour chaque défi xi reçu du serveur SRV tiers de confiance en utilisant la fonction probabiliste MPROB. Il forme ainsi des couples défi/réponse {xi, yi} .
Dans l’exemple de réalisation décrit ici, une réponse yi est obtenue en fonction du défi, la réponse yi associée étant la signature non bruitée obtenue par le module probabiliste MPROB pour ce paramètre d’entrée xi.
Dans le mode de réalisation décrit ici, le terminal TRM envoie les couples {défi, réponse} au serveur SRV au cours de cette même étape E30. Ils sont reçus par le serveur SRV et enregistrés dans la base de données BDS au cours d’une étape F50.
Il est souligné ici que les couples {défi, réponse} ne sont pas conservés dans une mémoire du terminal TRM.
Les étapes E10 à E30 et F10 à F50 constituent une phase d’ enrôlement référencée ENR sur la figure 7.
On suppose que le terminal veut envoyer un message msg de façon sécurisée au serveur
SRV.
Au cours d’une étape E40, le terminal :
- reçoit un défi xi en provenance du serveur SRV ;
- utilise le module probabiliste MPROB pour calculer la réponse yi à ce défi. Dans le mode de réalisation décrit ici, cette opération consiste à prendre une image avec la durée d’exposition xi, calculer une signature bruitée y’i du signal d’obscurité de cette image, et obtenir le défi yi par projection de la signature bruitée y’i sur une chaîne binaire ;
- utilise le module de chiffrement ENCBBu en boite blanche pour chiffrer le message msg en fonction de la réponse yi afin d’obtenir le message chiffré [msg] ; et
- envoie au serveur SRV son identifiant u, le défi xi et le message chiffré [msg].
De manière optionnelle, le défi xi n’est pas envoyé au serveur SRV.
Ces données sont reçues par le serveur SRV au cours d’une étape F60.
Au cours d’une étape F70, le serveur SRV obtient la clé symétrique Ku dans sa base de données BDS à partir de l’identifiant u. Il obtient de sa base de données BDS la réponse yi correspondant au défi xi. Il déchiffre le message chiffré [msg] en utilisant son module de déchiffrement DEC en fonction de la clé symétrique Ku et de la réponse yi et récupère un message. Si yi correspond bien à la valeur utilisée par le terminal, alors le message récupéré correspond au message msg en clair.
On suppose que le serveur SRV souhaite envoyer un message msg au terminal TRM de façon sécurisée.
Au cours d’une étape F80, le serveur SRV :
- choisit un couple {xi, yi} dans sa base de données BDS ;
- utilise le module de chiffrement ENC pour chiffrer le message msg en utilisant la clé symétrique Ku du terminal TRM et la réponse yi ; le résultat de ce chiffrement étant le message chiffré [msg] ;
- envoie le défi xi et le message chiffré [msg] au terminal TRM.
Ces données sont reçues par le terminal TRM au cours d’une étape E50.
Au cours d’une étape E60, le terminal TRM :
- utilise le module probabiliste (MPROB) pour calculer la réponse yi au défi xi ;
- déchiffre le message chiffré [msg] en utilisant le module de déchiffrement en boite blanche DECBBu et obtient le message msg.
Si yi calculé par le module probabiliste correspond bien à la valeur utilisée par le serveur, alors le message déchiffré correspond au message msg en clair.
La figure 8A représente le terminal TRM de la figure 1.
Dans le mode de réalisation décrit ici, ce terminal TRM a l’architecture d’un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11 , une mémoire morte de type ROM 12, une mémoire non volatile réinscriptible de type FLASH 13 et des moyens de communication COM.
Dans le mode de réalisation décrit ici, l’application APP est enregistrée dans la mémoire non volatile 13. Les instructions de cette application et notamment celles du module cryptographique CRYBBu en boite blanche sont exécutées par le processeur 10. Dans ce mode de réalisation, la mémoire non volatile 13 mémorise également l’identifiant u du terminal.
La mémoire morte 12 constitue un support d’enregistrement conforme à l’invention. Elle comporte un programme d’ ordinateur PGT conforme à l’invention. Ce programme PGT comporte en particulier des instructions pour, lorsqu’elles sont exécutées par le processeur 10 :
- communiquer avec le serveur SRV en utilisant le module de communications COM ;
- recevoir un défi xi et calculer une réponse à ce défi, par exemple contrôler la caméra PUF pour prendre des images avec une durée d’exposition xi, calculer une signature de la image obtenue, la filtrer pour obtenir une réponse yi et envoyer les couples défis/réponses {xi, yi} au serveur SRV ;
- invoquer le module cryptographique CRYBBu en boite blanche pour chiffrer ou déchiffrer des messages en fonction d’une réponse à un défi.
La figure 8B représente le serveur SRV de la figure 1.
Dans le mode de réalisation décrit ici, ce serveur SRV a l’architecture d’un ordinateur. Il comporte notamment un processeur 20, une mémoire vive de type RAM 21 , une mémoire morte de type ROM 22, une mémoire non volatile réinscriptible de type FLASH 23 et des moyens de communication COM.
Dans ce mode de réalisation, la mémoire non volatile 23 mémorise également la base de données BDS. La mémoire morte 22 constitue un support d’enregistrement conforme à l’invention. Elle comporte un programme d’ordinateur PGS conforme à l’invention. Ce programme PGS comporte en particulier des instructions pour, lorsqu’elles sont exécutées par le processeur 20 :
- communiquer avec le terminal TRM en utilisant le module de communications COM ;
- générer des clés symétriques Ki, des modules cryptographiques CRYBBu en boite blanche pour ces clés et intégrer ces modules dans des applications pour différents services ;
- mémoriser pour un terminal TRM dans une base de données BDS un ensemble de couples {xi, yi} associés à ce terminal ;
- invoquer le module cryptographique CRY pour chiffrer ou déchiffrer des messages en fonction d’une réponse yi associée à un défi xi.

Claims

REVENDICATIONS
1. Procédé de fourniture d’un module cryptographique en boite blanche (CRYBBu) mis en œuvre par un serveur (SRV) comportant un module cryptographique (CRY) configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une clé symétrique et une réponse à un défi, le procédé comportant :
- une étape (F30) d’obtention d’une clé symétrique (Ku) pour un terminal ;
- une étape (F30) de génération d’un module cryptographique en boite blanche (CRYBBu), ledit module cryptographique en boite blanche étant une implémentation en boite blanche du module cryptographique (CRY) du serveur pour ladite clé symétrique (Ku) obtenue pour ce terminal (TRM), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique (Ku) enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi ; et - une étape (F40) de fourniture dudit module cryptographique en boite blanche
(CRYBBu) audit terminal (TRM).
2. Procédé de fourniture selon la revendication 1, ce procédé comportant en outre une étape (F50) de réception et d’enregistrement d’au moins un couple défi/réponse (xi, yi) en provenance dudit terminal (TRM).
3. Procédé de chiffrement d’un message (msg) mis en œuvre par un serveur (SRV), ledit message chiffré ([msg]) étant destiné à être envoyé à un terminal (TRM), ledit procédé comportant : - une étape (F80) de chiffrement de données comportant l’obtention d’une clé symétrique
(Ku) dudit terminal (TRM) et d’une réponse (yi) à un défi (xi), reçu dudit terminal (TRM) au cours d’une phase d’enrôlement (ENR) du terminal, au cours de laquelle le serveur a généré et fourni au terminal un module cryptographique en boite blanche (CRYBBu), ledit module cryptographique en boite blanche (CRYBBu) étant une implémentation en boite blanche d’un module cryptographique (CRY) du serveur pour ladite clé symétrique (Ku), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant un message, une réponse à un défi, et ladite clé symétrique (Ku) enfouie dans ledit module cryptographique en boite blanche (CRYBBu), ladite réponse reçue en provenance du terminal correspondant à une réponse (yi) d’un couple défi/réponse (xi, yi) ; - une étape de chiffrement mise en œuvre en fournissant en entrée du module cryptographique (CRY) dudit serveur (SRV) ladite clé symétrique (Ku), ladite réponse (yi) et ledit message (msg) ; et
- une étape d’envoi du défi (xi) et d’un message chiffré ([msg]) obtenu audit terminal (TRM).
4. Procédé de déchiffrement d’un message chiffré ([msg]) mis en œuvre par un serveur (SRV), ledit procédé comportant :
- une étape d’envoi d’un défi (xi) au terminal et de réception (F60) en provenance du terminal (TRM) d’un message chiffré ([msg]) au moyen d’un module cryptographique en boite blanche (CRYBBu) fourni par ledit serveur, ce module cryptographique en boite blanche (CRYBBu) étant une implémentation en boite blanche d’un module cryptographique (CRY) dudit serveur (SRV) pour une clé symétrique (Ku) du terminal (TRM), ledit module cryptographique en boite blanche (CRYBBu) étant configuré par le serveur pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant un message et une réponse à un défi, et de ladite clé symétrique (Ku) enfouie dans ledit module cryptographique en boite blanche (CRYBBu), ladite réponse reçue en provenance du terminal correspondant à une réponse (yi) d’un couple défi/réponse (xi, yi) reçu du terminal dans une phase préalable d’enrôlement ;
- une étape de déchiffrement mise en œuvre en fournissant ladite clé symétrique (Ku), la réponse (yi) au défi (xi) et le message chiffré en entrée du module cryptographique (CRY) dudit serveur (SRV), le résultat de ladite étape de déchiffrement comportant un message en clair (msg).
5. Serveur (SRV) comportant :
- un module cryptographique (CRY) configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique (Ku) ;
- un module (MGBB) d’obtention d’une clé symétrique (Ku) pour un terminal ;
- un module (MGBB) de génération d’un module cryptographique en boite blanche (CRYBBu), ledit module cryptographique en boite blanche étant une implémentation en boite blanche dudit module cryptographique (CRY) du serveur pour ladite clé symétrique (Ku) obtenue pour ce terminal (TRM), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique (Ku) enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi ; et - un module (COM) de fourniture dudit module cryptographique en boite blanche (CRYBBu) audit terminal (TRM).
6. Programme d’ordinateur (PGS) comportant des instructions pour l’exécution des étapes du procédé de fourniture selon la revendication 1 ou 2 lorsque ledit programme est exécuté par un ordinateur (SRV).
7. Programme d’ordinateur (PGS) comportant des instructions pour l’exécution des étapes du procédé de chiffrement selon la revendication 3 et/ou des étapes du procédé de déchiffrement selon la revendication 4 lorsque ledit programme est exécuté par un ordinateur (SRV).
8. Procédé d’obtention d’un module cryptographique en boite blanche (CRYBBu) mis en œuvre par un terminal (TRM) comportant : - une étape (E 10) d’ envoi d’un identifiant (u) du terminal (TRM) à un serveur comportant un module cryptographique (CRY) configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique (Ku) ;
- une étape (E20) de réception d’un module cryptographique en boite blanche (CRYBBu) constituant une implémentation en boite blanche du module cryptographique (CRY) dudit serveur (SRV) pour ladite clé symétrique (Ku), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique (Ku) enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi. 9. Procédé d’obtention selon la revendication 8, ce procédé comportant en outre une étape
(E30) d’obtention d’au moins un couple défi/réponse (xi, yi), d’envoi dudit au moins un couple défi/réponse (xi, yi) audit serveur, ladite réponse (yi) étant obtenue à partir dudit défi (xi) et d’une fonction probabiliste (MPROB) mettant en œuvre une fonction physique non clonable (PUF) du terminal (TRM).
10. Procédé de chiffrement d’un message (msg) mis en œuvre par un terminal (TRM), ledit procédé comportant :
- une étape d’obtention d’un module cryptographique en boite blanche (CRYBBu) en provenance d’un serveur (SRV), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir d’une clé symétrique (Ku) propre au terminal (TRM) et enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi ;
- une étape (E40) d’obtention d’une réponse (yi) à un défi (xi) par mise en œuvre d’une fonction probabiliste (MPROB) mettant en œuvre une fonction physique non clonable (PUF) du terminal (TRM) ; et
- une étape d’envoi audit serveur (SRV) du message (msg) chiffré par ledit module cryptographique en boite blanche (CRYBBu) en fonction de la réponse (yi) au défi (xi).
11. Procédé de déchiffrement d’un message chiffré ([msg]) mis en œuvre par un terminal (TRM), ledit procédé comportant :
- une étape d’obtention d’un module cryptographique en boite blanche (CRYBBu) en provenance d’un serveur (SRV), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir d’une clé symétrique (Ku) propre au terminal (TRM) et enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi ;
- une étape (E40) de réception, en provenance dudit serveur (SRV) d’un défi (xi) et d’un message chiffré ([msg]) ;
- une étape d’obtention d’une réponse au défi reçu par mise en œuvre d’une fonction probabiliste (MPROB) mettant en œuvre une fonction physique non clonable (PUF) du terminal (TRM) ;
- une étape de déchiffrement du message chiffré par ledit module cryptographique en boite blanche (CRYBBu) pour obtenir ledit message en clair (msg).
12. Terminal (TRM) comportant :
- un module (COM) d’envoi d’un identifiant (u) du terminal (TRM) à un serveur comportant un module cryptographique (CRY) configuré pour chiffrer ou déchiffrer un message à partir de paramètres d’entrée comportant ledit message, une réponse à un défi et une clé symétrique (Ku) ;
- un module (COM) de réception d’un module cryptographique en boite blanche (CRYBBu) constituant une implémentation en boite blanche du module cryptographique (CRY) dudit serveur (SRV) pour ladite clé symétrique (Ku), ledit module cryptographique en boite blanche (CRYBBu) étant configuré pour chiffrer ou déchiffrer un message à partir de ladite clé symétrique (Ku) enfouie dans ce module (CRYBBu) et de paramètres d’entrée comportant un message et une réponse à un défi.
13. Programme d’ordinateur (PGT) comportant des instructions pour l’exécution des étapes du procédé d’obtention selon la revendication 8 ou 9 lorsque ledit programme est exécuté par un ordinateur (SRV). 14. Programme d’ordinateur (PGT) comportant des instructions pour l’exécution des étapes du procédé de chiffrement selon la revendication 10 et/ou des étapes du procédé de déchiffrement selon la revendication 11 lorsque ledit programme est exécuté par un ordinateur (TRM).
EP20821347.0A 2019-11-22 2020-11-19 Procede securise d'echange de donnees entre un terminal et un serveur Pending EP4062584A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1913104A FR3103591A1 (fr) 2019-11-22 2019-11-22 Procédé sécurisé d’échange de données entre un terminal et un serveur
PCT/FR2020/052130 WO2021099744A1 (fr) 2019-11-22 2020-11-19 Procede securise d'echange de donnees entre un terminal et un serveur

Publications (1)

Publication Number Publication Date
EP4062584A1 true EP4062584A1 (fr) 2022-09-28

Family

ID=69903322

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20821347.0A Pending EP4062584A1 (fr) 2019-11-22 2020-11-19 Procede securise d'echange de donnees entre un terminal et un serveur

Country Status (4)

Country Link
US (1) US20230025166A1 (fr)
EP (1) EP4062584A1 (fr)
FR (1) FR3103591A1 (fr)
WO (1) WO2021099744A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3121525B1 (fr) * 2021-04-02 2023-06-23 Idemia France Authentification d’un dispositif par un traitement cryptographique
CN113722741A (zh) * 2021-09-07 2021-11-30 浙江大华技术股份有限公司 数据加密方法及装置、数据解密方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5249053B2 (ja) * 2006-03-10 2013-07-31 イルデト・コーポレート・ビー・ヴイ データ処理システムの完全性
EP2326043A1 (fr) * 2009-11-18 2011-05-25 Irdeto Access B.V. Prévention du clonage de récepteurs de messages cryptés
US8751807B2 (en) * 2011-06-23 2014-06-10 Azuki Systems Inc. Method and system for secure over-the-top live video delivery
US9953166B2 (en) * 2013-07-04 2018-04-24 Microsemi SoC Corporation Method for securely booting target processor in target system using a secure root of trust to verify a returned message authentication code recreated by the target processor
DE102013227087A1 (de) * 2013-12-23 2015-06-25 Siemens Aktiengesellschaft Gesichertes Bereitstellen eines Schlüssels
KR20150129459A (ko) * 2014-05-12 2015-11-20 한국전자통신연구원 화이트 박스 암호화 장치 및 그 방법
KR101933649B1 (ko) * 2016-05-27 2018-12-28 삼성에스디에스 주식회사 화이트박스 암호 알고리즘을 이용한 공개키 암호화를 위한 장치 및 방법
EP3552340A2 (fr) * 2016-12-12 2019-10-16 ARRIS Enterprises LLC Cryptographie en boîte blanche forte
US10511436B1 (en) * 2017-07-31 2019-12-17 EMC IP Holding Company LLC Protecting key material using white-box cryptography and split key techniques
US10812269B2 (en) * 2017-11-07 2020-10-20 Arris Enterprises Llc Advanced crypto token authentication
US10140612B1 (en) * 2017-12-15 2018-11-27 Clover Network, Inc. POS system with white box encryption key sharing
FR3079653B1 (fr) * 2018-03-29 2022-12-30 Airtag Procede de verification d'une authentification biometrique
KR102364652B1 (ko) * 2019-08-01 2022-02-21 한국전자통신연구원 화이트박스 암호화를 이용한 puf 기반 사물인터넷 디바이스 인증 장치 및 방법

Also Published As

Publication number Publication date
US20230025166A1 (en) 2023-01-26
WO2021099744A1 (fr) 2021-05-27
FR3103591A1 (fr) 2021-05-28

Similar Documents

Publication Publication Date Title
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
WO2021099744A1 (fr) Procede securise d'echange de donnees entre un terminal et un serveur
EP3917073A1 (fr) Établissement efficace de sessions sécurisées pour l'anonymat dans les réseaux 5g
EP4241416B1 (fr) Procede de delegation d'acces a une chaine de blocs
EP3219077B1 (fr) Procédé et système de gestion d'identités d'utilisateurs destiné à être mis en oeuvre lors d'une communication entre deux navigateurs web
EP3789898B1 (fr) Procédé de génération d'une clé
FR3057122A1 (fr) Procede et dispositif de detection d'intrusions sur un reseau utilisant un algorithme de chiffrement homomorphe
EP4068679B1 (fr) Authentification d'un dispositif par un traitement cryptographique
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
FR3141021A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
WO2023041863A1 (fr) Procedes et dispositifs d'authentification et de verification de non-revocation
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
EP4652758A1 (fr) Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
WO2025021489A1 (fr) Procédés et dispositifs pour authentifier des données
FR3141020A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
FR3107414A1 (fr) Procédé de calcul d’une clé de session, procédé de récupération d’une telle clé de session
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d' un document pour les utilisateurs privileges
FR3108816A1 (fr) Procédé de délégation d’une fonction de résolution d’identifiants de nommage
FR2898448A1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
FR3093882A1 (fr) Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.
WO2017089710A1 (fr) Procédé de distribution de droits sur un service et plateforme de service
FR2982724A1 (fr) Communication securisee

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220615

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20241018