La bibliothèque Q3P (Quantum Point to Point Protocol), qui implémente le canal classique fourni par le projet SECOQC, fonctionne elle aussi avec deux threads, l’un fourni au protocole de réconciliation, l’autre à la gestion interne de la bibliothèque.
15.3
Protocoles de communication, ou comment éviter
la cacophonie
Dans cette section, nous passerons en revue l’ensemble des applications qui composent la réconciliation distribuée, ainsi que les protocoles de communication associés.
Les protocoles sont représentés par des diagrammes de séquence suivant la convention de représentation des diagrammes UML1. Les règles de ces diagrammes sont les suivantes :
• Le déroulement chronologique des événements s’opère de haut en bas, en suivant une ligne
de vie (trait pointillé). Dans notre cas, deux lignes de vie sont nécessaires, une pour le
maître, l’autre pour l’esclave.
• Lorsqu’une application est active, un rectangle recouvre la ligne de vie.
• À coté de chaque zone d’activité sont indiquées les fonctions utilisées. Leur nom est assez détaillé pour faire office de description.
• state++ indique l’incrémentation de l’état associé à la fonction start() de l’application (section 15.2).
• Une flèche reliant les deux lignes de vie indique le transfert d’un message sur le canal classique. Le contenu du message (identifiant et information échangée) est indiqué au- dessus de cette flèche. Une flèche pleine représente un message synchrone, une flèche creuse un message asynchrone.
• Les applications filles sont représentées par un rectangle arrondi. Elles sont appelées par le maître, et notifient le maître et l’esclave.
• Des parties du protocole sont conditionnées par l’identité du maître (Alice ou Bob). Il est à noter que la structure du protocole permet que le même code soit utilisé pour le maître et l’esclave. Cette propriété permet de mettre un commun une importante similitude entre les actions que doivent réaliser le maître et l’esclave.
CSKDP
L’application CSKDP (Continuous Secret Key Distillation Protocol, selon [7]) est l’application principale du processus de réconciliation. Elle est démarrée par le nœud après établissement du canal classique. Elle est responsable :
• de la gestion du pilotage de l’expérience. CSKDP s’occupe de démarrer le pilotage, vérifier son état, et le redémarrer après une interruption.
• de la négociation des blocs à réconcilier et du transfert de ces blocs depuis le logiciel de pilotage.
• de démarrer l’application BSKDP après l’établissement du choix d’un bloc à réconcilier. L’application CSKDP est un singleton. Son arrêt signifie la fin du processus de réconciliation. Le diagramme de séquence UML de cette application est représenté figure 15.1.
1Unified Modeling Language : ensemble de règles standardisées pour la représentation de diagrammes. Ces
règles sont une sorte de grammaire pour la conception de diagrammes. Elles confèrent un "sens" aux diagrammes, au-delà de leur sens purement visuel. Un diagramme suivant les règle UML pourra être interprété par une machine, par exemple pour générer du code source.
184 Chapitre 15 : Distillation d’une clé à travers un réseau classique
15.3 Protocoles de communication 185 BSKDP
L’application BSDKP (Block Secret Key Distillation Protocol) est responsable de la réconciliation d’un bloc fourni par CSKDP. Elle assure :
• la révélation des phases choisies par Bob (tamisage, ou sifting). • le mélange aléatoire des données.
• le choix d’échantillons révélés et le calcul des paramètres de transmission.
• la négociation d’une chaîne de bits qui identifie une fonction de hachage pour l’amplifi- cation de confidentialité.
• l’exécution de l’application de réconciliation à proprement parler. • l’exécution de l’amplification de confidentialité.
• l’enregistrement de la clé secrète obtenue auprès du nœud.
Plusieurs instances de l’application BSKDP peuvent éventuellement coexister, en fonction des caractéristiques du matériel de décodage (processeurs multiples). Le diagramme de séquence UML de cette application est représenté figure 15.2.
SliceAlgo
L’application SliceAlgo implémente l’algorithme de réconciliation par tranches,
utilisant divers protocoles de correction d’erreur binaires interchangeables (Cascade, Winnow, Turbo codes). Elle repose sur les structures développées par Gilles Van Assche implémentant cet algorithme. Cette application est fournie à titre historique, car la réconciliation molle (SoftAlgo) fournit de meilleurs résultats en termes d’efficacité.
SoftAlgo
L’application SoftAlgo implémente l’algorithme de réconciliation multi-niveaux
(voir section 12.7). Grâce à sa similitude avec l’algorithme de réconciliation par tranches, elle reprend une grande partie des structures utilisées par SliceAlgo, notamment en ce qui concerne la représentation des tranches, leur création, les calculs d’entropie, d’informations, de bits se- crets. . . À ces structures sont ajoutés les algorithmes de décodage mou (LDPC ou turbo codes) décrits au chapitre 13. La réconciliation molle suit le déroulement suivant :
• initialisation des tranches et des codes correcteurs, en fonction des paramètres de trans- mission.
• encodage des codes mous (LDPC), ainsi que des codes BCH capables de corriger les dernières erreurs laissées par le décodage mou.
• multiplexage et envoi des parités générées par l’ensemble des codes. • décodage (correction d’erreurs).
• notification de l’application parent (BSKDP).
Il existe une application SoftAlgo pour chaque application BSKDP. Éventuellement, les applications SoftAlgo peuvent être réutilisées d’une application BSKDP à l’autre, pour éviter l’initialisation des codes pour chaque bloc à réconcilier. Le diagramme de séquence UML de cette application est représenté figure 15.3.
Negociator
Le négociateur permet à Alice et Bob de s’entendre sur un paramètre de configu- ration, à l’issue de multiples transactions. Son déroulement est le suivant :
186 Chapitre 15 : Distillation d’une clé à travers un réseau classique
15.3 Protocoles de communication 187
Fig. 15.3: Diagramme de séquence UML pour le protocole de communication SoftAlgo. Suivre les diagonales pointillées suivant que Claude ou Dominique sert de référence pour la clé.
• Claude propose une valeur du paramètre.
• Dominique accepte ou refuse cette valeur. Dans ce dernier cas, il a la possibilité de proposer une alternative.
• En fonction de la réponse de Dominique, Claude entérine la valeur du paramètre, ou relance le processus de négociation.
Le négociateur est utilisé pour la décision du bloc à réconcilier et de la clé utilisée par l’amplification de confidentialité. Il utilise le canal classique pour transmettre les messages de négociation (négociation propriétaire), ou bien, pour le canal classique fourni par le projet SECOQC, les fonctions de négociation fournies par le nœud.
KeyBroker
Dernière partie de notre assemblage, le "KeyBroker", engrange les clés secrètes. Si nous faisons fonctionner notre système de réconciliation dans le cadre de l’architecture fournie par le réseau SECOQC, le "KeyBroker" transfère les clés vers le réservoir de clés du réseau
188 Chapitre 15 : Distillation d’une clé à travers un réseau classique
quantique.
L’ensemble des modules fonctionnels décrits dans ce chapitre, ainsi que leurs interactions, sont représentés figure 15.4 sous forme d’un diagramme UML.