FR3103591A1 - Procédé sécurisé d’échange de données entre un terminal et un serveur - Google Patents

Procédé sécurisé d’échange de données entre un terminal et un serveur Download PDF

Info

Publication number
FR3103591A1
FR3103591A1 FR1913104A FR1913104A FR3103591A1 FR 3103591 A1 FR3103591 A1 FR 3103591A1 FR 1913104 A FR1913104 A FR 1913104A FR 1913104 A FR1913104 A FR 1913104A FR 3103591 A1 FR3103591 A1 FR 3103591A1
Authority
FR
France
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.)
Withdrawn
Application number
FR1913104A
Other languages
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.)
Universite de Lorraine
Orange SA
Original Assignee
Universite de Lorraine
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 Universite de Lorraine, Orange SA filed Critical Universite de Lorraine
Priority to FR1913104A priority Critical patent/FR3103591A1/fr
Priority to EP20821347.0A priority patent/EP4062584A1/fr
Priority to US17/777,906 priority patent/US20230025166A1/en
Priority to PCT/FR2020/052130 priority patent/WO2021099744A1/fr
Publication of FR3103591A1 publication Critical patent/FR3103591A1/fr
Withdrawn 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

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

Procédé sécurisé d’échange de données entre un terminal et un serveur 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). Figure 7

Description

Procédé sécurisé d’échange de données entre un terminal et un serveur
Arrière-plan de l’invention
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.
Objet et résumé de l’invention
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_Cryptography__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éfi/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 (ENR) 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.
Description détaillée 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
sont identiques.
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 F10.
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 (14)

  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 comportantl’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 agé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 en outre 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 (E10) 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 en outre 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).
FR1913104A 2019-11-22 2019-11-22 Procédé sécurisé d’échange de données entre un terminal et un serveur Withdrawn FR3103591A1 (fr)

Priority Applications (4)

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
EP20821347.0A EP4062584A1 (fr) 2019-11-22 2020-11-19 Procede securise d'echange de donnees entre un terminal et un serveur
US17/777,906 US20230025166A1 (en) 2019-11-22 2020-11-19 Secure method for data exchange between a terminal and a server
PCT/FR2020/052130 WO2021099744A1 (fr) 2019-11-22 2020-11-19 Procede securise d'echange de donnees entre un terminal et un serveur

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
FR1913104 2019-11-22

Publications (1)

Publication Number Publication Date
FR3103591A1 true FR3103591A1 (fr) 2021-05-28

Family

ID=69903322

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1913104A Withdrawn FR3103591A1 (fr) 2019-11-22 2019-11-22 Procédé sécurisé d’échange de données 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 浙江大华技术股份有限公司 数据加密方法及装置、数据解密方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090158051A1 (en) * 2006-03-10 2009-06-18 Koninklijke Philips Electronics N.V. Method and system for obfuscating a cryptographic function
EP2326043A1 (fr) * 2009-11-18 2011-05-25 Irdeto Access B.V. Prévention du clonage de récepteurs de messages cryptés

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090158051A1 (en) * 2006-03-10 2009-06-18 Koninklijke Philips Electronics N.V. Method and system for obfuscating a cryptographic function
EP2326043A1 (fr) * 2009-11-18 2011-05-25 Irdeto Access B.V. Prévention du clonage de récepteurs de messages cryptés

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RASOAMIARAMANANA SANDRA ET AL: "White-Box Traitor-Tracing from Tardos Probabilistic Codes", 16 March 2013, 12TH EUROPEAN CONFERENCE ON COMPUTER VISION, ECCV 2012; [LECTURE NOTES IN COMPUTER SCIENCE], PAGE(S) 125 - 141, ISBN: 978-3-642-36741-0, ISSN: 0302-9743, XP047545151 *

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2021099744A1 (fr) Procede securise d'echange de donnees entre un terminal et un serveur
WO2016102833A1 (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
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
EP3594880A1 (fr) Procédé de transmission sécurisée de données cryptographiques
WO2019129771A1 (fr) Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu
EP3917073A1 (fr) Établissement efficace de sessions sécurisées pour l'anonymat dans les réseaux 5g
EP3789898A1 (fr) Procédé de génération d'une clé
EP3526946B1 (fr) Procédé de chiffrement, procédé de déchiffrement, dispositif et programme d'ordinateur correspondant
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
WO2021165625A1 (fr) Procede de calcul d'une cle de session, procede de recuperation d'une telle cle de session
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
WO2022096824A1 (fr) Procede de delegation d'acces a une chaine de blocs
EP4402854A1 (fr) Procedes et dispositifs d'authentification et de verification de non-revocation
EP4068679A1 (fr) Authentification d'un dispositif par un traitement cryptographique
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
EP4158872A1 (fr) Procede de delegation de la livraison de contenus a un serveur cache
WO2024068498A1 (fr) Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés
WO2021198606A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d' un document pour les utilisateurs privileges
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.
EP2180654A1 (fr) Procédé de sécurisation des messages destinés à un terminal évolué dans une architecture distribuée
WO2017089710A1 (fr) Procédé de distribution de droits sur un service et plateforme de service
WO2007101966A1 (fr) Authentification d'un dispositif informatique au niveau utilisateur

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210528

ST Notification of lapse

Effective date: 20220705