Nota : première publication le 13 janvier 2023
Dans un système de cryptographie quantique, le générateur aléatoire est crucial pour que le protocole fonctionne correctement. Mais on peut l'imiter !
Si vous pouvez avoir accès au matériel, et en particulier au générateur de nombre aléatoire, alors on peut tirer parti du fait que π, ou tout autre nombre transcendant du même tonneau, possède une suite infinie de décimales qui présente toutes les caractéristiques d'un RNG, sauf que cette suite est parfaitement déterministe.
Voyons comment Eve va exploiter cette particularité, au nez et à la barbe d'Alice et Bob. Car ce sera très difficile à détecter.
L'isolation du matériel = le placer dans une enceinte où les données ne peuvent pas entrer ni sortir sans autorisation, est une condition de sécurité importante et impérative.
Sauf que ce n'est pas une condition suffisante.
Souvent on pense qu'un cheval de Troie est un petit programme qui s'installe dans le système et qui va permettre de sortir des données subrepticement, mais il peut prendre de nombreuses formes comme ajouter un espion Wifi qui va émettre des données sensibles vers l'extérieur.
Mais on peut faire plus sournois, sans qu'aucunes données ne soient effectivement émises. Ici, je prends l'exemple du protocole BBM92.
Cheval de Troie et générateur aléatoire
On se doute qu'on a intérêt à avoir un générateur aléatoire qui le soit vraiment, sans biais particulier. En clair, pas de dés pipés.
Voici un exemple d'attaque sournoise dont j'ai inventé le nom, π-rate :
Imaginez qu'Eve ait trafiqué le générateur aléatoire de manière à envoyer les décimales de π à la place des nombres aléatoires.
À noter : nul besoin de dézinguer le générateur aléatoire si on a accès au programme qui contrôle le système : c'est nettement plus simple de modifier quelques lignes de code si le système utilise un simple PRNG, mais bon, ici je veux montrer l'importance du RNG.
Vous noterez aussi que si le générateur aléatoire ne génère plus d'aléas (panne...), alors un attaquant pourra exploiter cette faille, d'où l'importance d'utiliser un RNG certifié.
Pour ceux qui ne le savent pas, les décimales de π présentent des caractéristiques qu'on ne peut pas distinguer d'un nombre aléatoire. On peut passer tous les tests statistiques que vous voulez, si vous n'avez pas reconnu π, alors vous soutiendrez mordicus que vous êtes en face de "vrai aléatoire". Alors que c'est parfaitement déterministe. Voilà qui est embêtant.
Mais comme Eve est une feignasse de grande envergure, elle choisira éventuellement un simple générateur de nombres pseudo-aléatoires, ce sera pareil, mais éventuellement détectable car ces générateurs ont une période de répétition.
Exemple de réalisation
mais ça ressemble à de l'aléatoire.
Ainsi modifié, le système fonctionnera comme d'habitude.
Si le générateur de π effectue une remise à zéro lorsque l'on met le système sous tension, alors on aura toujours la même séquence de nombres. Mais comme on n'a pas trafiqué le RNG de Bob, il n'y a aucune corrélation, et les bits retenus ne seront jamais les mêmes, ce n'est pas à cet endroit qu'il faut regarder pour détecter la fraude.
Important
Un test d'intrication ? Pour le moment, on fabrique le même photon que celui vu par Alice, aussi c'est mal barré avec ce protocole où on cherche à lire pareil chez Alice et Bob, on constatera que ça marche.
Il va falloir faire un test plus poussé (jeu de Bell ?) mais dans ce cas, on ne lit plus le photon comme le demanderait le protocole choisi, il faudrait changer et aller vers la QKD-DI.
Et là, Eve aurait pu aussi remplacer le générateur aléatoire de Bob, et là, plus besoin de trafiquer les photons...
Votre système peut être complètement isolé, Eve connaîtra l'intégralité de vos secrets. Ce bête exemple montre bien que la condition d'isolation n'est certainement pas suffisante, ou au pire, très difficile à définir et à mettre en pratique.
Eve pourrait même faire plus sournois et commode, en envoyant sur la ligne d'alimentation des systèmes des ordres pour piloter son RNG trafiqué, mais c'est une autre histoire.
Implémentation matérielle
Cette attaque un peu évidente si la sélection de la base de lecture est entièrement électronique. Elle sera plus pénible à réaliser, mais pas impossible, dans le cas où le RNG repose sur un phénomène optique, par exemple :
Au milieu en rose, vous avez la génération de photons intriqués, qui est réalisée à partir d'un seul photon ultraviolet à 403 nm passant dans un cristal de BBO où deux photons intriqués sont créés, de fréquence moitié (conservation de l'énergie). C'est très classique, et je le décris aussi dans ma page sur la génération de photon.
Les deux appareils de détection, identiques (en jaune), d'Alice et Bob, mesurent un photon chacun de leur côté.
Le RNG est une ruse d'opticien : pour choisir la base de mesure, horizontale/verticale ou diagonale, on utilise une lame semi-réfléchissante BS Beam Splitter : le photon ira tout droit ou sera réfléchi avec une probabilité de 50%. C'est un RNG quantique, un des plus fiables !
Remplacement de la lame semi-réfléchissante
Le remplacement de la lame semi-réfléchissante n'est certainement pas le plus simple.
Ici, il va vous falloir un commutateur optique suffisamment rapide, piloté électriquement par le générateur pseudo-aléatoire électronique (les décimales de π).
Il se trouve qu'envoyer les photons un par un est un mécanisme plutôt lent, et donc une lame piézo-électrique comportant un miroir pourrait faire l'affaire, vous pouvez voir ça comme un aiguillage mécanique, et on n'est pas en train de faire du gigabit/s.
Adapter cet élément dans le système existant sera pénible, mais pas impossible. Ce sera plus simple de le construire et le mettre au point dans la cave du pirate, puis de remplacer le bloc à l'occasion d'une maintenance...
Contre-mesures
- Vérifiez que votre RNG ne donne pas toujours la même séquence au démarrage en enregistrant les valeurs.
- Examinez physiquement l'intérieur du système.
- Insérer une ou plusieurs séquences connues, testées à l'avance et inconnues d'Eve, qui serviront de contrôle.
Cette attaque peut certainement se décliner dans d'autres systèmes en cybersécurité "classique".
Page suivante, l'attaque copycat.