6.4 Résultats expérimentaux
6.4.3 Stabilité du sous-programme « transmission quantique »
Les ordinateurs utilisés pour la gestion du protocole utilisent le système d’exploi- tation OpenSuSE, fondé sur un noyau Linux. Ce choix d’une distribution Linux a été fait, d’une part, car la stabilité du système d’exploitation est cruciale lors du dé- veloppement d’un programme fonctionnant en temps réel. Qui plus est, à travers le grand nombre d’outils libres permettant l’optimisation des programmes C++, Linux est bien adapté à notre application. D’autre part, notre système a pris part au réseau de cryptographie quantique SECOQC (voir chapitre 9), pour lequel il avait été décidé d’utiliser Linux pour tous les systèmes.
Débogage
Notre programme de gestion de la transmission quantique doit pouvoir fonctionner en continu, pendant de longues périodes. Lors de la programmation d’un logiciel avec de telles contraintes, il faut prendre garde à toutes les causes de plantage (terme peu formel mais consacré : c’est une traduction de crash, correspondant à une interruption brutale, inattendue et anormale) :
1. les erreurs de segmentation, qui correspondent à l’appel d’un registre mémoire se trouvant hors de la zone autorisée. Typiquement, un vecteur vec est déclaré tel qu’il contienne 50 éléments, et on appelle vec[50], qui est le 51ème élément du vecteur, et donc n’existe pas.
2. les dépassements d’entiers : un entier est codé sur un certain nombre de bits, qui conditionne la valeur maximale que cet entier peut prendre. Par exemple, pour un entier codé sur 8 bits (de type short int), la valeur maximale est 28
1255.
Si l’on cherche à affecter à une variable short int une valeur plus grande que 255, le programme renvoie une erreur du type integer overflow.
3. de façon similaire, les dépassements de tas, de tampon, de pile, qui reviennent tous à dépasser la taille de l’objet considéré.
110 Chapitre 6 : Intégration et pilotage du système optique
4. enfin, les fuites mémoires. Elles consistent en la déclaration explicite d’une nou- velle variable (par exemple, new int foo), mais à l’oubli de sa destruction (delete foo). Puisque la déclaration a été effectuée par new, le processeur n’est pas autorisé à supprimer de lui-même la variable, et la place que foo prend dans la mémoire vive n’est alors jamais libérée. Cet effet est particulièrement gênant quand le programme fonctionne selon une boucle : au fur et à mesure du fonctionnement, les nouveaux appels de new vont réserver de la place dans la mémoire vive, jusqu’à ce que celle-ci soit saturée. Le programme ne peut alors plus fonctionner, et plante.
Nous avons donc soigneusement débogué le programme pour éviter les trois pre- miers types d’erreur ; l’outil gdb [59] du projet GNU est particulièrement utile pour affiner le débogage. Par ailleurs, nous avons éliminé les fuites mémoires en nous aidant du logiciel de profilage Valgrind [60], qui trace le fonctionnement du programme et détecte toutes les variables non-libérées au fur et à mesure de son exécution.
Pilote de la carte d’acquisition
Après ces optimisations, le sous-programme ne présente plus de bogue significatif. Néanmoins, un dernier problème persiste : la carte d’acquisition National Instruments que nous utilisons numérote les impulsions qu’elle émet sur un entier signé de 32 bits. Ainsi, quand la carte atteint la 231ème impulsion, elle renvoie un message d’erreur et
doit être réinitialisée. Or, 231
2 147 483 648 impulsions sont émises à 500 kHz en 1
heure et 11 minutes. Nous avons donc dû mettre au point un système de réinitialisation régulier, qui permet de faire fonctionner le programme au delà de 71 minutes.
Néanmoins, lors de ces réinitialisations, il arrive que la carte d’acquisition se bloque, et que la seule solution pour la remettre en fonctionnement soit de redémarrer le programme manuellement. Ces blocages sont d’autant plus fréquents que le processeur de l’ordinateur est sollicité par ailleurs. De ce fait, la durée moyenne de fonctionnement autonome du sous-programme de transmission quantique est de l’ordre de 3 jours.
Pour éviter cet effet, il nous faudrait disposer d’un pilote National Instruments 64 bits, qui n’existe à l’heure actuelle que sous Windows. Nous pourrions alors numéroter les impulsions jusqu’environ 1019, c’est-à-dire pendant plus d’un million d’années.
Troisième partie
Extraction de la clé secrète
Des corrélations au secret
Dans les parties précédentes, nous avons :
• transmis de l’information continue entre Alice et Bob, codée sur les quadratures d’états cohérents de la lumière ;
• optimisé le fonctionnement du système optique, et évalué les bruits ajoutés à la transmission ;
• montré qu’il était possible, compte tenu des paramètres de la transmission, d’ex- traire une quantité d’information secrète ∆I IAB IBE des données corrélées
d’Alice et de Bob.
Cette information secrète, néanmoins, n’est pas accessible directement. En effet, elle n’existe que sous forme de corrélations entre les données continues d’Alice et de Bob. L’enjeu est donc de transformer ces deux ensembles de données continues,
corrélées, contenant du secret en une chaîne de données discrètes, identiques, partagées et totalement secrètes — c’est-à-dire une clé secrète partagée.
Pour ce faire, les données corrélées subissent plusieurs opérations complexes, quoique complètement classiques :
• Binarisation des données, et correction des différences entre les chaînes d’Alice et de Bob : c’est le processus de réconciliation, décrit dans le chapitre 7 ;
• Élimination de toute l’information potentiellement espionnée : c’est l’amplification de confidentialité, décrite dans le chapitre 8.
Le chapitre 9 décrit enfin la structure du programme utilisé pour l’extraction de la clé, ainsi que les performances du système expérimental dans des conditions réelles de fonctionnement.
114 Chapitre 6 : Intégration et pilotage du système optique
Alice
Bob
Réconciliation
Amplification de confidentialité
Données corrélées continues
Données identiques binaires
Données identiques binairessecrètes
Vérification
Figure 6.8 :Processus d’extraction de la clé secrète
IAB IBE IAB IBE
Side-information Information perdue
(Efficacité de la réconciliation)
IAB IBE Après la transmission Après la réconciliation Après l'amplification
de confidentialité
7
Réconciliation des données
expérimentales
Il y a des scientifiques sadiques qui se pressent de traquer les erreurs au lieu d’établir la vérité.
Marie Curie
Après la transmission quantique, Alice et Bob ont chacun un ensemble de données, continues dans notre cas, qui sont corrélées. Ils doivent dans un premier temps en extraire deux chaînes binaires identiques, à l’aide d’un algorithme de réconciliation.
7.1 Protocoles de correction d’erreurs
Les protocoles de correction d’erreurs ont été développés dans le cadre des télécom- munications classiques : une chaîne de référence (le message), générée par Claude1,
est transmise à Dominique dans un canal bruité. Il s’agit donc pour Dominique de corriger le bruit de la chaîne bruitée pour retrouver le message originel.
Le schéma général d’un algorithme de correction d’erreurs se décrit comme suit : Claude a la tâche de l’encodage, et utilise un code correcteur pour encoder le message dans un mot-code redondant. Après réception, Dominique doit décoder le message codé à partir du mot-code bruité, en utilisant un algorithme de décodage. Nous décrivons dans ce chapitre le fonctionnement de ces codes correcteurs et algorithmes de décodage, en insistant plus particulièrement sur les codes LDPC utilisés dans notre système.