FR3112643A1 - Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches - Google Patents
Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches Download PDFInfo
- Publication number
- FR3112643A1 FR3112643A1 FR2007425A FR2007425A FR3112643A1 FR 3112643 A1 FR3112643 A1 FR 3112643A1 FR 2007425 A FR2007425 A FR 2007425A FR 2007425 A FR2007425 A FR 2007425A FR 3112643 A1 FR3112643 A1 FR 3112643A1
- Authority
- FR
- France
- Prior art keywords
- data
- cryptographic
- unencrypted
- cryptographic processing
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 38
- 238000004891 communication Methods 0.000 title claims description 6
- 238000012545 processing Methods 0.000 claims abstract description 77
- 230000006870 function Effects 0.000 claims abstract description 54
- 230000015654 memory Effects 0.000 claims abstract description 13
- 238000003672 processing method Methods 0.000 claims abstract description 3
- 238000004590 computer program Methods 0.000 claims description 7
- 238000009795 derivation Methods 0.000 claims description 5
- 230000007246 mechanism Effects 0.000 description 10
- 230000008901 benefit Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 230000000873 masking effect Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000007792 addition Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 101100203322 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) SKS1 gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000013481 data capture Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
L’invention se rapporte à un procédé cryptographique de traitement de données pour la mise en œuvre d’une fonction cryptographique, procédé mis en œuvre au sein d’un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en œuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique : - réception (10) de données entrantes (D_A) ; - détermination (20) d’une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) ; - déchiffrement (30), à l’aide de la clé (K_I) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc) ; - mise en œuvre (40) d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ; - optionnellement détermination (45) d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ; - obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) ; - chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l’aide de la clé de chiffrement (K_O) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.
Description
1. Domaine
L’invention se rapporte au domaine de la protection des données. Plus particulièrement, l’invention se rapporte au domaine de la protection de l’échange de données au cours de l’exécution de routines. Plus spécifiquement encore, l’invention se rapporte au domaine de la protection des données échangées entre des modules d’exécution de primitives cryptographiques dans le cadre de l’exécution d’une application au sein d’un seul dispositif de traitement de données.
2. Art Antérieur
Un objet de la cryptographie est de disposer d’algorithmes et de protocoles pour protéger un canal de communication contre des tentative de captation de données. Deux grands types de systèmes sont opposés : les systèmes dits de « boite noire » et les systèmes dits de « boite blanche ». On considère dans un système de type « boite noire » que la « source » de l’information et la « destination » de l’information sont sûres : un attaquant a seulement un accès aux entrées/sorties de la source et/ou de la destination, mais n’a pas accès à l’algorithme de chiffrement et de déchiffrement lui-même, qui est exécuté à l’intérieur d’un objet sécurisé auquel l’attaquant n’a pas accès, appelé boite noire. Toutefois, du point de vue industriel, le problème principal est la mise en œuvre pratique des techniques issues de laboratoires. Ainsi, des protocoles déployés dans le mauvais contexte, des algorithmes mal mis en œuvre, ou des paramètres inappropriés peuvent offrir un point d'entrée supplémentaire pour les attaquants.
Le problème de mise en œuvre pratique est encore plus complexe lorsque le modèle d'attaque en boîte noire n'est plus satisfait : l’attaquant peut alors avois accès à un certain nombre d’informations sur la manière dont fonctionnent les processus de chiffrement/déchiffrement à l’intérieur de la boite noire. Par ailleurs, avec le déploiement de la cryptographie dans des applications qui sont exécutées sur des appareils ouverts tels que PC, tablettes ou smartphones, sans nécessairement utiliser d'éléments sécurisés, le problème ne se pose plus en termes de boite noire, mais bien en termes de boite blanche.
Les boîtes blanches cryptographiques sont des composants logiciels qui exécutent des opérations cryptographiques avec une clé secrète intégrée (codée en dur ou transmise dynamiquement). Les boîtes blanches sont conçues de telle manière que la récupération de la clé secrète est difficile, à la fois dans le sens traditionnel de la cryptanalyse, mais aussi face à des adversaires capables d'accéder aux composants internes du logiciel (par exemple, la mémoire, les accès au cache, le code source, etc.) ou même de modifier le logiciel de chiffrement ou le comportement de celui-ci.
Ainsi, un attaquant d’une boîte blanche dispose potentiellement d’un accès complet à l’implémentation logicielle d'un algorithme cryptographique : le binaire est supposé être visible et modifiable par l'attaquant et celui-ci a le plein contrôle de la plateforme d'exécution (appels CPU, registres mémoire, etc.). Par conséquent, l'implémentation de l’algorithme de chiffrement constitue l’une des seules barrières de protection contre une attaque. Ainsi, les implémentations logicielles qui résistent à ces attaques en boîte blanche sont dénommées implémentations en boîte blanche (white-box en anglais). Elles constituent la d'applications dans lesquelles une clé cryptographique est utilisée pour protéger des biens ou des services, comme par exemple dans le domaine des DRM. Dans de tels cas, l’attaquant peut avoir un intérêt à rétro-concevoir l'application et à en extraire la clé (d’où l’utilité des boites blanches à clés fournies dynamiquement). Des attaques similaires peuvent se produire à l'encontre de l'intérêt de l'utilisateur, par exemple quand une application bancaire est exécutée sur un dispositif infecté par des logiciels malveillants ou sur un système dans lequel certains utilisateurs ont des privilèges plus élevés que d’autres. Dans de telles situations, lorsque les opérations cryptographiques sont implémentées au travers de bibliothèques cryptographiques standards (connues et documentées) comme OpenSSL ou que les clés cryptographiques sont stockées simplement dans la mémoire, la clé secrète sera découverte, et ce quelle que soit la force de la primitive cryptographique utilisée.
Par ailleurs, même si l’attaquant n’est pas en mesure d’obtenir la clé sécrète, il peut tout de même tenter de tirer partie de la boite blanche en l’utilisant telle qu’elle pour effectuer des opérations de chiffrement ou de déchiffrement, à l’aide d’une attaque appelée « code lifting ». Dans cette attaque, l'attaquant ne cherche pas à extraire la clé secrète à partir de l'implémentation, mais utilise l'ensemble de l'application comme passeport pour la mise en œuvre de fonctions cryptographiques. Les fonctionnalités de la boite blanche sont directement exploitées en tant que telle. Le « code lifting » peut être combattu dans la pratique en appliquant des codages externes au système original, et notamment les codages annihilant à d'autres endroits dans l'application principale. Il est cependant nécessaire d’utiliser des techniques d'offuscation ou d'isolation de processus dans un environnement sécurisé (au sein du terminal, PC, tablette) afin de s'assurer que les fonctions G et F ne peuvent pas être extraites de la fonction appelante. Par conséquent, il est nécessaire de disposer d’un composant sécurisé, ce qui n’est pas toujours possible.
Par ailleurs, un autre problème réside dans l’enchainement d’exécution de codes en boite blanche. En effet, a supposé que l’implémentation en boite blanche soit efficacement mise en œuvre, et qu’un nombre limité de fonctions cryptographiques soit intégré au sein de la boite blanche (idéalement une seule fonction est intégrée au sein d’un boite blanche), il n’en reste pas moins que l’attaquant peut, dans certains cas obtenir des données intermédiaires, c’est-à-dire des données qui constituent la sortie d’une première boite blanche et l’entrée d’une seconde. De cette façon, l’attaquant peut implémenter toute ou partie d’une chaine de sécurisation, à son propre compte, en modifiant les données intermédiaires, sans qu’il soit nécessaire d’inspecter les fonctionnements des boites blanches.
3. Résumé de l’invention
L’invention ne pose pas les problèmes précédemment identifiés. Plus particulièrement, l’invention permet d’éviter d’une part par les pratiques de code lifting et d’autre part par l’exposition de données intermédiaires.
Procédé cryptographique de traitement de données pour la mise en œuvre d’une fonction cryptographique, procédé mis en œuvre au sein d’un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en œuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique :
- réception de données entrantes ;
- détermination d’une clé de déchiffrement à appliquer sur lesdites données entrantes ;
- déchiffrement, à l’aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ;
- mise en œuvre d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ;
- optionnellement détermination d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
- obtention d’une clé de chiffrement desdites données sortantes non chiffrées ;
- chiffrement desdites données sortantes non chiffrées à l’aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires.
Ainsi, l’invention permet d’éviter que les données intermédiaires qui transitent entre deux modules de traitement cryptographique ne puissent être interceptées et utilisées par un attaquant.
Selon une caractéristique particulière, l’étape de déchiffrement qui, à l’aide de la clé des données entrantes, délivre des données entrantes non chiffrées comprend une étape de combinaison des données entrantes avec au moins une table d’une série de tables intégrée au sein dudit module de traitement cryptographique.
Selon une caractéristique particulière, l’étape détermination d’une clé de déchiffrement à appliquer sur lesdites données entrantes comprend une étape de dérivation de ladite de déchiffrement à partir d’une clé maitre, ladite étape de dérivation tenant compte d’une position dudit module de traitement cryptographique courant au sein de la chaine de modules de traitement cryptographique.
Ainsi, il n’est pas aisé, pour un attaquant, même connaissant une clé maitre, de déterminer quelle sera le prochain module de traitement cryptographique utilisé au sein de la chaine. Car en effet, cette information dépend directement des données (entrantes/sortantes) elles-mêmes, qui sont chiffrées.
Selon une caractéristique particulière, l’étape de détermination d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées comprend :
- Une étape d’identification, au sein desdites données entrantes non chiffrées, d’une structure de données de routage ;
- Une étape de détermination, à partir de ladite structure de données de routage, d’une localisation courante ;
- Une étape de détermination, à partir de ladite localisation courante, d’une localisation suivante ;
- Une étape d’obtention d’un identifiant du module de traitement cryptographique suivant associé à ladite localisation suivante.
Ainsi, le chainage des modules de traitement cryptographique dépend des données qui sont elles-mêmes chiffrées et le module est à même de déterminer, potentiellement seul, quel est le prochain module à exécuter dans le chainage en fonction de ces données. On dispose donc d’un routage dynamique plus complexe à analyser pour un attaquant.
Selon une caractéristique particulière, l’étape d’obtention d’une clé de chiffrement desdites données sortantes non chiffrées comprend une étape de dérivation de ladite de chiffrement à partir d’une clé maitre, ladite étape de dérivation tenant compte d’une position dudit module de traitement cryptographique suivant au sein de la chaine de modules de traitement cryptographique.
Ainsi, il n’est pas aisé, pour un attaquant, même connaissant une clé maitre, de déterminer quelle sera le prochain module de traitement cryptographique utilisé au sein de la chaine. Car en effet, cette information dépend directement des données (entrantes/sortantes) elles-mêmes, qui sont chiffrées.
Selon une caractéristique particulière, l’étape d’obtention d’une clé de chiffrement desdites données sortantes non chiffrées comprend une étape d’obtention de ladite clé de chiffrement à partir de l’identifiant du module de traitement cryptographique suivant.
Ainsi, le module courant peut utiliser l’identifiant du module suivent pour sélectionner une clé dont il sait à priori qu’elle convient au module suivant.
Selon une caractéristique particulière, ledit procédé comprend en outre une étape de transmission des données sortantes chiffrées à un module de traitement cryptographique suivant de ladite chaine d’au moins deux modules de traitement cryptographique en fonction d’au moins une donnée de routage présente au sein des données entrantes et/ou des données entrantes non chiffrées.
Ainsi, le module courant ne se repose pas sur l’actionnement d’un mécanisme de retour à un appelant des données qu’il vient de traiter, mais au contraire est en mesure de fournir directement les données intermédiaires à un module suivant pour que ces dernières soient directement traitées. On augmente ainsi la sécurité de l’ensemble.
Selon une caractéristique particulière, l’étape de mise en œuvre d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées consiste en l’application d’une primitive cryptographique.
Ainsi, l’exécution d’une telle primitive est mise en œuvre de manière sécurisée.
Selon un mode de réalisation particulier, l’invention se présente sous la forme d’un dispositif cryptographique de traitement de données pour la mise en œuvre d’une fonction cryptographique. Un tel dispositif électronique de traitement de données comprend un processeur, un mémoire et une clique de modules de traitement cryptographique. Le dispositif comprend met en œuvre un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant :
- Des moyens de réception de données entrantes ;
- Des moyens de détermination d’une clé de déchiffrement à appliquer sur lesdites données entrantes ;
- Des moyens de déchiffrement, à l’aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ;
- Des moyens de mise en œuvre d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ;
- Des moyens optionnels de détermination d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
- Des moyens d’obtention d’une clé de chiffrement desdites données sortantes non chiffrées ;
- Des moyens de chiffrement desdites données sortantes non chiffrées à l’aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d’exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau du terminal de communication, du dispositif électronique d’exécution et/ou du dispositif de contrôle, dans le cadre d’une répartition des traitements à effectuer et déterminés par un codes source scripté.
En conséquence, l’invention vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus.
Un programme peut 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 lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations 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 support mobile (carte mémoire) ou un disque dur ou un SSD.
D'autre part, le support d'informations 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 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.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Dessins
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
5. Description détaillée
5.1. Rappel du principe
Comme explicité précédemment, le principe général de l’invention consiste à munir des modules d’exécution de primitives cryptographiques chacun d’une couche additionnelle de chiffrement à l’entrée et à la sortie du module d’exécution, dans le cadre d’un enchainement d’appels de modules « unitaires » pour remplir une ou plusieurs (sous)fonctions cryptographiques prédéterminées par l’application appelante, à l’aide d’un mécanisme de chainage dont certains modes de réalisation, selon l’invention, sont décrits par la suite. Un exemple typique de mise en œuvre de la technique décrite en relation avec la figure 1 est réalisée dans un système comprenant un programme informatique appelant (AppA) (comme une application fonctionnant sur un système d’exploitation (OS) de type Windows™, MacOS™, Linux™ encore Android™), lui-même fonctionnant sur un dispositif physique (DPy). Un dispositif électronique (DPy) comprend un processeur (P), une mémoire (M), et des moyens de transmission de données (TRD). Ces moyens de transmission de données (TRD) peuvent se présenter sous plusieurs formes, comme cela est explicité par la suite. Il peut également comprendre, en fonction des modes de réalisation, des composants (optionnels) matériels et/ou logiciels d’affichage (Disp), de saisie (KBD) et ou d’impression (IMP).
L’application peut par exemple être un lecteur de musique/de vidéo, ou encore une application de paiement ou encore une application gérant l’accès à des données sensibles enregistrées sur le dispositif électronique, une application d’identification ou d’authentification, etc. Ce programme informatique (AppA) a un besoin, au cours de son exécution, de mettre en œuvre une ou plusieurs fonctions cryptographiques (F1, F2, F3, etc). Généralement, ces fonctions ne sont pas directement intégrées dans le programme informatique. A la place, il appelle des fonctions qui sont disponibles au sein d’une bibliothèque (LIB1, LIB2,…) (.lib, .dll, etc. en fonction du système d’exploitation). Cette bibliothèque est chargée par le programme appelant (AppA), qui se charge d’appeler la fonction cryptographique ou la primitive cryptographique requise en boite blanche (F1, F2, F3, etc.), soit directement soit en passant par l’intermédiaire du système d’exploitation (OS). En règle générale, cette fonction cryptographique ou cette primitive cryptographique est appelée telle qu’elle et lorsque deux fonctions cryptographiques ou deux primitives cryptographiques (chacune en boite blanche) sont appelées l’une après l’autre, les données intermédiaires DInt (i.e. sorties de la première boite blanche et fournies à la deuxième boite blanche) transitent en clair, comme explicité précédemment. La technique proposée permet de résoudre à la fois la problématique de transition en clair des données intermédiaire tout en limitant les possibilités de code lifting, en divisant les fonctions rendues par une boite blanche, en chiffrant (masquant) les entrées/sorties des modules et en routant dynamiquement l’exécution des différents modules entre eux, comme explicité en figure2. Afin d’être complet, dans le cadre de la présente, on rappelle les définitions suivantes :
- Une primitive cryptographique est un algorithme cryptographique de bas niveau, sur la base duquel est notamment bâti un système de sécurité. Un algorithme cryptographique peut se rapporter à une fonction de hachage cryptographique (par exemple SHA-1, SHA3, etc.) ou encore une fonction de chiffrement (par exemple AES, DES) ;
- Une primitive cryptographique utilise des opérations cryptographiques (permutation, rotations, transformations linéaires, opérations algébriques sur les entiers ou binaires, additions, multiplication, XOR, etc.) ;
- Une fonction cryptographique comprend la mise en œuvre d’une ou de plusieurs primitives cryptographiques, selon un chainage (routage) défini par l’auteur de la fonction cryptographique, en fonction de la destination de la fonction cryptographique (i.e. à quoi cette fonction sert-elle, est-elle destinée dans le cadre d’une architecture de sécurisation).
Ainsi, en figure 2, il est décrit un mécanisme dans lequel une primitive cryptographique (Pc1) et une primitive cryptographique (Pc2) sont utilisées pour mettre en œuvre une fonction cryptographique (F1), par l’Application appelante (AppA), dans le cadre du système de la figure 1. Selon la technique proposée, les primitives cryptographiques sont chacune implémentées dans un module dédié (M1, M2). L’application AppA fournit des données d’entrée (Din) au module M1, puis obtient des données intermédiaire (DInt), lesquelles sont transmises, en tant que données d’entrée, au module M2, qui ensuite utilise les données intermédiaires pour produire les données de sorties (DOut). Selon l’invention, le module M1 comprend un étage de sortie C1, lequel effectue un chiffrement des données intermédiaires (DInt) avant la communication de celles-ci à l’application AppA. Selon l’invention, le module M2 comprend un étage d’entrée D2, lequel effectue un déchiffrement des données intermédiaires (DInt) avant l’utilisation de celles-ci dans le cadre de la primitive PC2.
La technique proposée permet de résoudre d’une part un problème de divulgation de données intermédiaires lorsque des données sont échangées entre des modules et que ces données quittent temporairement l’environnement sécurisé fourni par le module : elles pourraient être interceptées par un attaquant à ce moment précis. Les « données intermédiaires » pourraient être accessibles à un attaquant lorsqu'elles transitent en dehors de l'environnement du module. De plus, comme explicité précédemment, un attaquant peut sortir un module de son contexte et l'utiliser (par exemple comme primitive de déchiffrement autonome) ailleurs.
L’invention permet de répondre à la contradiction générée par le principe même de « boite blanche » et de « code lifting », selon un nouvel axe de mise en œuvre : pour augmenter l’efficacité d’une boite blanche, il faut théoriquement regrouper les fonctions cryptographiques au sein d’une seule boite blanche. Pour limiter les risques dus au « code lifting », au contraire il faut dissocier au maximum les primitives cryptographiques.
Ainsi, bien qu’en principe il serait possible de regrouper plus d’une primitive cryptographique dans une seule boîte blanche, au lieu de considérer plusieurs boîtes blanches différentes, en pratique, cela n'est, selon les inventeurs, ni faisable ni souhaitable. En effet, le processus de mise en boîte blanche d'un programme augmente sa taille de façon très importante (du fait de la transformation de fonctions en tables), et le regroupement de plusieurs primitives cryptographiques au sein d’une seule boite blanche, outre le fait qu’il pose un problème de sécurité, entraîne une augmentation rapide des bases de code, qui sont dès lors difficiles à gérer. Il peut également arriver que plusieurs technologies de boîte blanche différentes et incompatibles (car provenant d’éditeurs différents par exemple) soient utilisées dans un seul programme ou une même application, auquel cas elles ne peuvent pas être regroupées.
Ainsi, on propose un procédé pour augmenter la sécurité, notamment des implémentations en boites blanches, en sécurisant les données en transit (données intermédiaires) entre les modules, tout en garantissant un flux d'exécution correct (protégeant ainsi par exemple contre les attaques par « code-lifting »). D’une manière générale, ans le cadre de la présente, on considère qu’un module est implémenté sous la forme d’une librairie (logicielle) ou un composant dédié (matériel) et que ce module met en œuvre, au plus, une primitive cryptographique (et possiblement seulement une portion de primitive cryptographique).
Selon l’invention, au sein d’une application comprenant au moins deux modules en boites blanches, implémentant chacun une partie seulement d’une fonction cryptographique globale de protection de données, le module courant est muni d’une fonctionnalité de « masquage » des données avec le module suivant. Par exemple, lorsque deux modules implémentent une partie de fonctionnalité, qui nécessite la transmission de données intermédiaires entre les deux modules, alors les données intermédiaires sont masquées (i.e. chiffrées par exemple), de sorte que la prise de connaissance de ces données intermédiaires ne permette pas de disposer d’information correctement utilisable. Dans un mode de réalisation particulier, le masquage consiste en l’application d’un chiffrement des données intermédiaires avant leur transmission au module suivant, de sorte que ces données intermédiaires soient idéalement inaccessibles et à tout le moins inutilisables, même pour l’application appelante.
Un autre exemple comprenant quatre modules (X, Y, Z, T) est décrit en relation avec la figure 3. La solution technique proposée dans la présente invention consiste à utiliser des paires de codages correspondants entre des modules. Concrètement, cela signifie que dans le module X, on ajoute une capacité de chiffrement (simple) (pour une clé KX2) et une capacité de déchiffrement (pour une clé KX2). La même chose est réalisée pour les modules Y, Z et T. Les données intermédiaires Dint0 et Dint1 sont chiffrées (et/ou masquées). Le mécanisme de routage peut être soit interne aux modules, effectués en fonction d’une variable d’entrée ou encore d’un champ d’entête des données d’entrées (Din) et des données intermédiaires (Dint0 et Dint1). Alternativement, le mécanisme de routage peut être mis en œuvre par l’application appelante ou bien par un module de routage spécifique.
Cela garantit que :
- les données transmises entre les modules sont toujours chiffrées, et donc non aisément accessibles, non seulement pour un attaquant, mais également pour l’application appelante elle-même ;
- le flux de données intermédiaires ne peut pas être modifié (par exemple par « code-lifting ») sinon l'étape de déchiffrement des données intermédiaires ne fournira pas un résultat exploitable (lors de l’entrée dans la boite blanche suivante) ;
- la mise en œuvre d’un « code lifting » sur l’intégralité de la chaine de modules ne peut pas être réalisée facilement, du fait de la dispersion de la logique d’appel, celle-ci étant en effet répartie entre plusieurs « acteurs » différents, dont les « modules » eux-mêmes, qui peuvent transmettre l’information à un appelant différent.
En d’autres termes, selon l’invention, en sus d’une protection des données intermédiaires, l’invention permet également de protéger la logique d’exécution des primitives cryptographiques d’une part et des fonctions cryptographiques d’autre part. Un ou plusieurs modules de la pluralité (de la clique) des modules peuvent en outre mettre en œuvre des mécanismes d’appels différenciés et de routage des données intermédiaires en fonction des besoins. Potentiellement, tous les modules de la clique de modules peuvent en œuvre des mécanismes de routage.
Les étapes mises en œuvre au sein d’un module sont alors les suivantes, présentées en relation avec la figure 4 :
- réception (10) de données entrantes (D_A) ;
- détermination (20) d’une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) ;
- déchiffrement (30), à l’aide de la clé (KI) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc) ;
- mise en œuvre (40) d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ;
- optionnellement détermination (45) d’un module suivant à exécuter sur lesdites données sortantes non chiffrées (en fonction du mécanisme de routage utilisé) ;
- obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) (optionnellement en fonction du module suivant lorsqu’un mécanisme de routage interne est utilisé et qu’une détermination conditionnelle de clé est mises en œuvre) ;
- chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l’aide de la clé de chiffrement (K_O) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.
Selon l’invention, les étapes de déchiffrement 30 et de chiffrement 60 sont mutuellement optionnelles : en fonction de la position du module dans la chaine de modules, il est possible que l’une ou l’autre de ces étapes (et leurs étapes dépendantes d’obtention de clés) ne soient pas mises en œuvre. Cependant, au moins l’une des deux (chiffrement ou déchiffrement) est nécessairement mise en œuvre. Plus spécifiquement : si le module est le premier module de la chaine, le déchiffrement des données d’entrée n’est pas nécessaire ; si le module est le dernier module de la chaine (délivrant des données de sortie finales, i.e. qui ne sont pas intermédiaires), l’étape de chiffrement de ces données de sortie est optionnelle.
Ainsi, selon l’invention, d’une part il est possible de totalement masquer les données qui transitent entre les modules en effectuant un chiffrement de celles-ci, et d’autre part il est possible de déterminer, au sien d’un module courant, quel est le module suivant auquel les données sortantes doivent être transmises et d’utiliser une clé appropriée pour effectuer le chiffrement de ces données avant transmission. Le corollaire d’une telle implémentation selon l’invention est que la mise en œuvre d’une primitive cryptographique ou d’une fonction cryptographique (comprenant plusieurs primitives cryptographiques) est plus ou moins significativement allongé.
Selon l’invention, dans ce mode de réalisation, le routage entre les modules est effectué en utilisant un champ spécifique des données entrantes. Plus particulièrement, deux possibilités sont concrètement mises en œuvre :
- la première consiste à utiliser un entête des données entrantes, cet entête n’étant pas chiffré de manière identique aux données entrantes. L’entête est chiffré ou masqué selon un processus différent dans chaque module, mais quelque soit le processus utilisé, chaque module est en mesure de décoder ou de déchiffrer cet entête.
L’avantage ici est de permettre l’obtention d’une clé de déchiffrement des données entrantes chiffrées en fonction de la valeur de l’entête. L’entête possède alors deux fonctions distinctes et complémentaires : une fonction de détermination de clé de chiffrement, qui permet de disposer de cette clé de manière dynamique et une fonction de routage qui permet de chiffrer les données sortantes avec une clé, également obtenue dynamiquement, et de déterminer le module suivant dans la chaîne de traitement des données.
- La deuxième consiste à cacher ce champ dans les données entrantes chiffrées elles-mêmes, à un endroit connu du module courant et du module précédent. La valeur de ce champ n’est pas connue avant que les données soient déchiffrées par le module courant.
L’avantage ici est de ne pas avoir à gérer l’obtention de clés de chiffrement « variables ». Plus particulièrement, le module connait la clé de déchiffrement à utiliser pour déchiffrer les données entrantes. Il n’est donc pas nécessaire de déterminer cette clé en fonction de la valeur de l’entête, et il est ainsi possible de réduire la taille du binaire du module (et le temps d’exécution). Une fois les données entrantes déchiffrées, la valeur du champ spécifique est connue. La fonction de routage est alors mise en œuvre, après application de la fonction cryptographique du module, de la même manière que précédemment (i.e. la valeur du champ qui permet de chiffrer les données sortantes avec une clé de chiffrement, obtenue dynamiquement, et de déterminer le module suivant dans la chaîne de traitement des données.
Quelle que soit la manière dont ce champ est utilisé, il permet de transférer les fonctions de routage d’appel des différents modules aux modules eux-mêmes. Dès lors, chaque module est en mesure, potentiellement d’appeler chaque autre module de la clique de modules. C’est une manière astucieuse de procéder au masquage des appels et des données, et ce pour plusieurs raisons.
En effet, dans l’implémentation traditionnelle en boite blanche, l’intégralité des fonctions cryptographiques est mise en œuvre au sien de la boite blanche, selon un processus connu et ouvert, ouvrant les possibilités de code lifting. Lorsque la boite blanche met en œuvre plusieurs fonctionnalités de chiffrement et/ou de déchiffrement connues, celles-ci sont câblées, sous une forme ou sous une autre, dans la boite blanche.
L’approche est ici singulièrement différente puisque le flot d’exécution n’est pas connu en avance. C’est la valeur du champ de routage qui permet d’exécuter des primitives cryptographiques ou des opérations cryptographiques portées par des modules dont l’enchainement n’est pas connu au sein même des modules. Un module courant, à un instant « t » n’est informé que du minimum requis à savoir la clé de déchiffrement des données entrantes, le module suivant à appeler et la clé de chiffrement des données sortantes correspondant à ce module suivant à appeler. Ainsi, par exemple, si le module courant met uniquement en œuvre une opération cryptographique de type « XOR », le module courant :
- Déchiffre les données entrantes fournies ;
- Applique l’opération XOR sur ces données entrantes fournies, délivrant les données sortantes ;
- Détermine, à partir de la valeur du champ de routage, la clé de chiffrement à appliquer ;
- Chiffre les données sortantes ;
- Identifie, à partir de la valeur du champ de routage, le module suivant ;
- Transmet les données sortantes chiffrées au module suivant.
Ce qui vient d’être décrit pour l’opération XOR est bien évidemment valable pour toute autre opérations cryptographiques, qu’elles soient appliquées sur des chaines de bits, des chaines d’octets ou des entiers (permutations fixes ou variables, masquages, décalages, rotation, additions, etc.)
Un avantage d’une telle mise en œuvre est de permettre potentiellement l’appel d’un même module de la clique de modules à plusieurs reprises pour la mise en œuvre d’une primitive cryptographique (plusieurs opérations de masquage, de décalage, etc.) ou d’une fonction cryptographique (plusieurs appels d’une même primitive).
Bien que décrit en relation avec la mise en œuvre d’une seule opération cryptographique, il est évident que chaque module peut, en fonction des conditions de mise en œuvre opérationnelles, mettre en œuvre plusieurs opérations cryptographiques (par exemple, mais pas uniquement, lorsque des opérations cryptographiques sont fréquemment liées entre elles, ou bien lorsque de tels groupements se justifient).
Avantageusement, les clés d’entrée et de sortie sont dynamiquement obtenues : l’objectif est d’éviter qu’une clé soit intégrée à demeure dans un module, ce module pouvant ensuite être utilisé comme bon lui semble par un potentiel attaquant. Cependant, cette manière de faire n’est pas obligatoire, car on rappelle que les modules sont mis en œuvre de manière séquentiels ou itérative de manière à produire une fonction cryptographique complète, laquelle pouvant comprendre l’obtention d’une ou de plusieurs clés de chiffrement, également de manière dynamique.
Les opérations de chiffrement des soties et de déchiffrement des entrées, mises en œuvre dans les différents modules, lors de l’exécution de ceux-ci sont idéalement simples et rapides, afin de ne pas d’une part surcharger les modules de code « non nécessaire » à la mise en œuvre effective de la primitive cryptographique ou de l’opération cryptographique. L’objectif est de faire en sorte d’augmenter la sécurité des données entrantes et sortantes sans trop augmenter la taille du code d’une part et sans trop augmenter le temps nécessaire à la mise en œuvre de la fonction cryptographique. Il est donc nécessaire d’effectuer une balance entre l’intérêt d’une protection et la rapidité d’exécution. Ainsi, par exemple, le chiffrement/déchiffrement peut comprendre uniquement quelques opérations cryptographiques (deux à six par exemple), mises en œuvre sur une chaine de bits ou sur une chaine d’octets ou un entier, ces opérations cryptographiques étant symétriques : les opérations de déchiffrement sont les inverses des opérations de chiffrement et vice versa, pour deux modules routés l’un avec l’autre.
Par exemple si le chiffrement des données de sortie comprend, dans un module X, une permutation (opération S1), suivi d’une addition (opération S2), suivi d’une nouvelle permutation (opération S3) , alors le déchiffrement des données d’entrées correspondant à ces données de sortie, dans le module Y, qui est le suivant dans le routage, comprend : une permutation ( opération E1, inverse de l’opération S3), une soustraction (opération E2, inverse de l’opération S2), et une nouvelle permutation (Opération E3, inverse de l’opération S1).
La complexité des opérations de chiffrement des données de sortie et de chiffrement des données d’entrée dépend essentiellement du nombre d’opérations cryptographiques utiles mises en œuvre au sein du module. Par exemple, lorsque le module ne comprend qu’une ou deux opérations cryptographiques utiles (une opération cryptographique utile est une opération cryptographique du module qui sert à traiter les données pour la mise en œuvre de la primitive cryptographique), les opérations de chiffrement ou de déchiffrement inclues dans ce module sont généralement plus simples et rapide. A l’inverse, si le module implémente l’intégralité d’une primitive cryptographique, telle qu’AES ou 3DES (et donc comprend de très nombreuses opérations cryptographiques utiles), alors les opérations de chiffrement ou de déchiffrement inclues dans ce module peuvent être plus complexes et plus lourdes et comprendre une implémentation complète à base de clé.
En fonction des modes de réalisation, on note que le premier module d'une chaîne n'a pas nécessairement besoin de chiffrement et le dernier module d'une chaîne n'a pas besoin d'un déchiffrement. (Il est possible de crypter (resp. Décrypter) pour ces étapes, mais cela n'offre pas nécessairement de protection supplémentaire).
Les clés correspondantes, utilisées dans les opérations de déchiffrement des données d’entrée et de chiffrement des données de sortie peuvent être choisies manuellement ou automatiquement ; une façon d'obtenir ces clés automatiquement est d’utiliser une fonction de dérivation de clé (telle que HKDF). Dans une mise en œuvre de l'invention où une séquence linéaire de modules numérotés [0, 1, 2, 3, …, n], la clé de chiffrement pour le module i (qui est la clé de déchiffrement du module i + 1) peut être dérivée comme HKDF (graine, i).
Il est possible d'utiliser plusieurs clés de chiffrement / déchiffrement par module. Dans ce cas, une variable d'entrée indique la clé à considérer. Une telle mise en œuvre permet d’effectuer un routage intelligent, en assurant que dans une première situation donnée, un premier chiffrement (resp. déchiffrement) est utilisé tandis que dans une deuxième situation donnée, un deuxième chiffrement (resp. déchiffrement) est utilisé.
Il est également possible d'envisager plusieurs clés de chiffrement différentes, une par module, sans spécifiquement disposer de lien entre la manière dont les clés de chiffrement sont choisies pour chaque module.
Dans un mode de réalisation particulier, lorsqu’un module intègre l’intégralité d’une primitive cryptographique), la procédure de chiffrement des données de sortie (resp. Déchiffrement des données d’entrée) met en œuvre toute ou partie de la primitive cryptographique elle-même, lorsque cela est possible. En d’autres termes, comme, selon l’invention, l’objectif d’un module est de cacher la clé (et non pas l’implémentation de l’algorithme de chiffrement en lui-même), on utilise cette implémentation, avec une clé différente, pour chiffrer les données de sortie (resp. déchiffrer les données d’entrée). De cette manière, le surcroit de volume de code est relativement limité.
Comme indiqué précédemment, l’ajout de code supplémentaire pour le chiffrement/déchiffrement entraîne une augmentation de la taille des modules (par rapport à une implémentation standard). Cependant, cet ajout de code compensé, selon l’invention, par un gain de flexibilité et de modularité fourni par la capacité de décomposer en toute sécurité des opérations cryptographiques ou des primitives cryptographiques en utilisant la technique décrite. En outre, il est possible de tirer parti de schémas cryptographiques légers (par exemple Trivium, Simon, etc.) dont la taille de code est très petite et efficace en termes de calcul, pour compenser la surcharge de code due à la mise en œuvre de la technique proposée.
Dans un mode de réalisation particulier de l’invention, les logiques d’appels et de routage des données entre modules peuvent, comme exposé précédemment, être mise en œuvre par les modules eux-mêmes, qui au fur et à mesure de l’exécution des tâches qui leurs sont confiées, appliquent sur les données reçues et traitées par elles, un routage des données. Il est également possible, dans un autre mode de réalisation, de disposer d’un module spécifique (appelé module de routage), qui se charge, à l’aide de mécanismes de chiffrement particulier, de mettre en œuvre ce routage. Il s’agit dans ce cas d’un module passerelle, qui est un intermédiaire entre l’application appelante et les modules remplissant les fonctions cryptographiques.
5.2. Autres caractéristiques et avantages
On présente, en relation avec la figure 5, une architecture simplifiée d’un dispositif électronique d’exécution apte à effectuer le traitement et l’exécution de code selon le procédé décrit précédemment. Un dispositif électronique d’exécution comprend une mémoire 51 (et/ou éventuellement sécurisée et/ou deux mémoires séparées, une sécurisée et l’autre non), une unité de traitement 52 équipée par exemple d’un microprocesseur (et/ou éventuellement sécurisé et/ou deux processeurs séparés, un sécurisé et l’autre non), et pilotée par le programme d’ordinateur 53, mettant en œuvre le procédé tel que précédemment décrit. Dans au moins un mode de réalisation, l’invention est mise en œuvre au moins partiellement sous la forme d’une application AppA installée sur ce dispositif. On dispose ainsi d’un dispositif cryptographique de traitement de données pour la mise en œuvre de fonctions cryptographiques, qui comprend un processeur (52), un mémoire (51) et une clique de modules de traitement cryptographique (53), mise en œuvre dans un programme. Le dispositif met en œuvre un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant :
- Des moyens de réception de données entrantes ;
- Des moyens de détermination d’une clé de déchiffrement à appliquer sur lesdites données entrantes ;
- Des moyens de déchiffrement, à l’aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ;
- Des moyens de mise en œuvre d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ;
- Des moyens optionnels de détermination d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
- Des moyens d’obtention d’une clé de chiffrement desdites données sortantes non chiffrées ;
- Des moyens de chiffrement desdites données sortantes non chiffrées à l’aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires.
Pour l’exécution des fonctions qui lui sont confiés, le dispositif comprend également les moyens de mise en œuvre de l’ensemble des étapes précédemment mentionnées, soit sous une forme matérielle, lorsque des composants spécifiques sont dédiés à ces tâches, soit sous une forme logicielle en lien avec un ou plusieurs microprogrammes s’exécutant sur un ou plusieurs processeurs du dispositif d’exécution.
Claims (10)
- Procédé cryptographique de traitement de données pour la mise en œuvre d’une fonction cryptographique, procédé mis en œuvre au sein d’un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en œuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique :
- réception (10) de données entrantes (D_A) ;
- détermination (20) d’une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) ;
- déchiffrement (30), à l’aide de la clé (K_I) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc) ;
- mise en œuvre (40) d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ;
- optionnellement détermination (45) d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
- obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) ;
- chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l’aide de la clé de chiffrement (K_O) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires. - Procédé selon la revendication 1, caractérisé en ce que l’étape de déchiffrement (30), à l’aide de la clé (K_I) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc) comprend une étape de combinaison des données entrantes avec au moins une table d’une série de tables intégrée au sein dudit module de traitement cryptographique.
- Procédé selon la revendication 1, caractérisé en ce que l’étape détermination (20) d’une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) comprend une étape de dérivation de ladite de déchiffrement (K_I) à partir d’une clé maitre, ladite étape de dérivation tenant compte d’une position dudit module de traitement cryptographique courant au sein de la chaine de modules de traitement cryptographique.
- Procédé selon la revendication 1, caractérisé en ce que l’étape de détermination (45) d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées comprend :
- Une étape d’identification, au sein desdites données entrantes non chiffrées (DI_nc), d’une structure de données de routage ;
- Une étape de détermination, à partir de ladite structure de données de routage, d’une localisation courante ;
- Une étape de détermination, à partir de ladite localisation courante, d’une localisation suivante ;
- Une étape d’obtention d’un identifiant du module de traitement cryptographique suivant associé à ladite localisation suivante. - Procédé selon la revendication 1, caractérisé en ce que l’étape d’obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) comprend une étape de dérivation de ladite de chiffrement (K_O) à partir d’une clé maitre, ladite étape de dérivation tenant compte d’une position dudit module de traitement cryptographique suivant au sein de la chaine de modules de traitement cryptographique.
- Procédé selon la revendication 4, caractérisé en ce que l’étape d’obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) comprend une étape d’obtention de ladite clé de chiffrement (K_O) à partir de l’identifiant du module de traitement cryptographique suivant.
- Procédé selon la revendication 1, caractérisé en ce qu’il comprend en outre une étape de transmission des données sortantes chiffrées (D_B) à un module de traitement cryptographique suivant de ladite chaine d’au moins deux modules de traitement cryptographique en fonction d’au moins une donnée de routage présente au sein des données entrantes (D_A) et/ou des données entrantes non chiffrées (DI_nc).
- Procédé selon la revendication 1, caractérisé en ce que l’étape de mise en œuvre (40) d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) consiste en l’application d’une primitive cryptographique.
- Dispositif cryptographique de traitement de données pour la mise en œuvre d’une fonction cryptographique, dispositif comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit dispositif comprenant un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d’au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant :
- des moyens de réception (10) de données entrantes (D_A) ;
- des moyens de détermination (20) d’une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) ;
- des moyens de déchiffrement (30), à l’aide de la clé (K_I) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc) ;
- des moyens de mise en œuvre (40) d’au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ;
- des moyens optionnels de détermination (45) d’un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
- des moyens d’obtention (50) d’une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc) ;
- des moyens de chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l’aide de la clé de chiffrement (K_O) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires. - Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé cryptographique de traitement de données selon la revendication 1, lorsqu’il est exécuté sur un ordinateur
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2007425A FR3112643B1 (fr) | 2020-07-15 | 2020-07-15 | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches |
| EP21739226.5A EP4183098A1 (fr) | 2020-07-15 | 2021-07-08 | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches |
| US18/016,374 US20230275745A1 (en) | 2020-07-15 | 2021-07-08 | Device, method and program for secure communication between white boxes |
| PCT/EP2021/069068 WO2022013072A1 (fr) | 2020-07-15 | 2021-07-08 | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches |
| CA3183198A CA3183198A1 (fr) | 2020-07-15 | 2021-07-08 | Dispositif, methode et programme pour une communication securisee entre boites blanches |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2007425A FR3112643B1 (fr) | 2020-07-15 | 2020-07-15 | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches |
| FR2007425 | 2020-07-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3112643A1 true FR3112643A1 (fr) | 2022-01-21 |
| FR3112643B1 FR3112643B1 (fr) | 2024-05-03 |
Family
ID=73497872
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2007425A Active FR3112643B1 (fr) | 2020-07-15 | 2020-07-15 | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20230275745A1 (fr) |
| EP (1) | EP4183098A1 (fr) |
| CA (1) | CA3183198A1 (fr) |
| FR (1) | FR3112643B1 (fr) |
| WO (1) | WO2022013072A1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3035584A1 (fr) * | 2014-12-18 | 2016-06-22 | Nxp B.V. | Utilisation d'une implémentation de boîte blanche avec de multiples encodages externes |
| US20160211970A1 (en) * | 2015-01-15 | 2016-07-21 | Electronics And Telecommunications Research Institute | Apparatus and method for encryption |
-
2020
- 2020-07-15 FR FR2007425A patent/FR3112643B1/fr active Active
-
2021
- 2021-07-08 CA CA3183198A patent/CA3183198A1/fr active Pending
- 2021-07-08 WO PCT/EP2021/069068 patent/WO2022013072A1/fr unknown
- 2021-07-08 EP EP21739226.5A patent/EP4183098A1/fr active Pending
- 2021-07-08 US US18/016,374 patent/US20230275745A1/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3035584A1 (fr) * | 2014-12-18 | 2016-06-22 | Nxp B.V. | Utilisation d'une implémentation de boîte blanche avec de multiples encodages externes |
| US20160211970A1 (en) * | 2015-01-15 | 2016-07-21 | Electronics And Telecommunications Research Institute | Apparatus and method for encryption |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3112643B1 (fr) | 2024-05-03 |
| US20230275745A1 (en) | 2023-08-31 |
| CA3183198A1 (fr) | 2022-01-20 |
| WO2022013072A1 (fr) | 2022-01-20 |
| EP4183098A1 (fr) | 2023-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10579793B2 (en) | Managed securitized containers and container communications | |
| WO2019218919A1 (fr) | Procédé et appareil de gestion de clé privée dans un scénario de chaîne de blocs, et système | |
| EP3010175B1 (fr) | Rejeu d'un batch de commandes sécurisees dans un canal sécurisé | |
| FR3011653A1 (fr) | Procedes et dispositifs de masquage et demasquage | |
| EP2166696B1 (fr) | Protection de l'intégrité de données chiffrées en utilisant un état intermédiare de chiffrement pour générer une signature | |
| CN111656345A (zh) | 启用容器文件中加密的软件模块 | |
| 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 | |
| EP2336931B1 (fr) | Procédé de vérification de signature | |
| CA2988357C (fr) | Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants | |
| FR3112643A1 (fr) | Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches | |
| EP3547602A1 (fr) | Procédé de mise en oeuvre d'une fonction cryptographique pour une clé secrète | |
| EP2153575B1 (fr) | Obtention de valeurs dérivées dépendant d'une valeur maîtresse secrète | |
| EP3799347B1 (fr) | Sécurisation du chiffrement des et du déchiffrement des inverse | |
| FR2985337A1 (fr) | Procede de calcul cryptographique resilient aux attaques par injection de fautes, produit programme d'ordinateur et composant electronique correspondant. | |
| WO2019133298A1 (fr) | Contenants sécurisés gérés et communications de contenant | |
| WO2024083849A1 (fr) | Encodage en boite blanche | |
| FR3106909A1 (fr) | Circuit intégré configuré pour réaliser des opérations de chiffrement symétrique avec protection de clé secrète | |
| EP3745638A1 (fr) | Procedes de mise en uvre et d'obfuscation d'un algorithme cryptographique a cle secrete donnee | |
| EP2075733B1 (fr) | Dispositif et un procédé de protection contre la rétro conception | |
| FR2865086A1 (fr) | Dispositif et procede pour convertir un premier message en un deuxieme message | |
| Lin et al. | Ransomware Analysis | |
| WO2020193583A1 (fr) | Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants | |
| EP4328771A1 (fr) | Procédé d'exécution d'un code machine par un calculateur | |
| FR3020888A1 (fr) | Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application | |
| EP4068679A1 (fr) | Authentification d'un dispositif par un traitement cryptographique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20220121 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |