Note: Descriptions are shown in the official language in which they were submitted.
WO 2022/013072
PCT/EP2021/069068
1
TITRE : Dispositif, méthode et programme pour une communication sécurisée
entre boîtes
blanches
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
oeuvre pratique des techniques issues de laboratoires. Ainsi, des protocoles
déployés dans le
mauvais contexte, des algorithmes mal mis en oeuvre, ou des paramètres
inappropriés peuvent
offrir un point d'entrée supplémentaire pour les attaquants.
Le problème de mise en oeuvre 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
2
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
oeuvre 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
3
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
oeuvre, 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 oeuvre d'une
fonction
cryptographique, procédé mis en oeuvre 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
oeuvre 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 oeuvre 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 oeuvre 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 ;
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
4
- 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
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
5 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 oeuvre 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 exemple 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 oeuvre
d'une fonction
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
6
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 oeuvre 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 oeuvre 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 oeuvre 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.
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
7
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 exemple de réalisation, l'invention est mise en oeuvre 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'a 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 oeuvre une fonction ou un ensemble de
fonctions, selon
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
8
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 exemples 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 exemple de réalisation préférentiel,
donné à titre de simple
exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[fig 1] la figure 1 décrit un système dans lequel l'invention peut être mise
en oeuvre ;
[fig 2] la figure 2 décrit le principe général de la méthode objet de
l'invention ;
- [fig 3] la figure 3 illustre un autre exemple de la méthode objet de
l'invention ;
[fig 4] la figure 4 décrit les différentes étapes d'un exemple de réalisation
du procédé de
l'invention ;
[fig 5] la figure 5 illustre une architecture d'un dispositif appelant apte à
mettre en oeuvre
un procédé de traitement de l'invention ;
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
exemples 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 WindowsTM, MacOSTM, Lin uxT" encore Android"), lui-
même fonctionnant
sur un dispositif physique (DPy). Un dispositif électronique (DPy) comprend un
processeur (P), une
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
9
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 (1M P).
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
oeuvre 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,...)
(.Iib, .d11, 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 Dlnt (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.) ;
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
Une fonction cryptographique comprend la mise en oeuvre 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).
5 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
oeuvre 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
10 obtient des données intermédiaire (Dlnt), 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 Cl, lequel
effectue un
chiffrement des données intermédiaires (Dlnt) 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 (Dlnt) 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 oeuvre : 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
11
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 oeuvre, 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 exemple 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
12
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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre des mécanismes de routage.
Les étapes mises en oeuvre 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 (Dl_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) ;
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
13
- 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 oeuvre)
;
- 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 oeuvre d'une primitive cryptographique ou d'une fonction
cryptographique (comprenant
plusieurs primitives cryptographiques) est plus ou moins significativement
allongé.
Par ailleurs, la détermination d'une clé de déchiffrement (K_I) et d'une clé
de chiffrement
(K_O) est mise en oeuvre en fonction des conditions opérationnelles (notamment
du besoin de
réaliser une telle opération de chiffrement ou de déchiffrement) et est
exécutée selon une
méthodologie de détermination telles que celles présentées ci-après, par
exemple en fonction
d'une clé de base, initiale, appelée clé maitre, dont la forme varie en
fonction des réalisations.
Selon l'invention, dans un exemple 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 :
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
14
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 quel que 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 oeuvre, 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 oeuvre 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 oeuvre plusieurs
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
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
5 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 oeuvre une opération
cryptographique de type
10 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 ;
15 - 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
oeuvre 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 oeuvre d'une seule opération
cryptographique,
il est évident que chaque module peut, en fonction des conditions de mise en
oeuvre
opérationnelles, mettre en oeuvre 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).
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
16
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 oeuvre 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 oeuvre
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 oeuvre 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 oeuvre 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. Les clés de
chiffrement, dans ce cas,
consistent en l'enchainement (en une suite), plus ou moins longues
d'opérations unitaires de
chiffrement.
Par exemple, à titre purement illustratif, si le chiffrement des données de
sortie comprend,
dans un module X, une permutation (opération Si), suivi d'une addition
(opération 52), 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 El, inverse de l'opération S3), une soustraction
(opération E2, inverse de
l'opération 52), et une nouvelle permutation (Opération E3, inverse de
l'opération Si). La clé de
chiffrement, ici, est formée du triplet {Si ;52 ;S3} et la clé de
déchiffrement est formée du triplet
{E1 ;E2 ;E3}. Dans ce cas, les clés de chiffrements et de déchiffrement
correspondent à des
séquences (suites) secrètes d'opérations unitaires de chiffrement.
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
17
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
oeuvre 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é plus longues et plus complexes.
En fonction des exemples 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 est d'utiliser une fonction de
dérivation de clé (telle
que HKDF) à partir d'une clé maitre. 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), la graine étant par
exemple la clé utilisée pour le module précédent (i-1), une clé maitre
indépendante, un paramètre
initial, etc. L'avantage de cette mise en uvre à partir d'une clé maitre
dérivable est qu'elle est plus
simple et plus efficace qu'une sélection arbitraire de clés pour chaque
module. De plus, l'avantage
est également que la clé maitre, initiale, peut varier à chaque appel de la
clique de modules.
D'autres implémentations sont possibles, comme par exemple dans le cas des
suites d'opérations
unitaires présentées précédemment, une dérivation de la suite suivante en
fonction de la suite
précédente et de l'identifiant du module.
Il est également possible, de manière complémentaire ou indépendante des
implémentations précédentes, 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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
18
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 exemple 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 oeuvre de la technique proposée.
Dans un exemple 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 oeuvre
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 exemple 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 oeuvre
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
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
19
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 oeuvre le procédé tel que précédemment décrit. Dans au moins un
exemple de
réalisation, l'invention est mise en oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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.
CA 03183198 2022- 12- 16
WO 2022/013072
PCT/EP2021/069068
Pour l'exécution des fonctions qui lui sont confiés, le dispositif comprend
également les
moyens de mise en oeuvre 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
5 processeurs du dispositif d'exécution.
CA 03183198 2022- 12- 16
