Etudier et implémenter une simulation du protocole d’échange de clef quantique bb84

RAPPORT DE STAGE DE FIN D’ETUDES Sujet : Etudier et implémenter une simulation du protocole d’échange de clef quantique BB84 Réalisé par : Responsables : NGUYEN Thanh Mai IFI-P8 M Patrick BELLOT, ENST-Paris M Minh-Dung DANG, ENST-Paris M Romain ALLEAUME, ENST-Paris Paris, Mai 2004 - Janvier 2005 Remerciements Je tiens remercier Monsieur Pactrick BELLOT, mon mtre de stage pour son bon accueil, son enthousiasme et son entretien durant toute la période de mon stage l’ENST1 - département Informatique et Réseaux Je souhaite également faire part de ma reconnaissance mon tuteur DANG Minh Dung et thésard Romain ALLEAUME pour leur disponibilité, leur appui et également les conseils utiles tout au long de mon stage Je voudrais aussi témoigner de mes remerciements mes deux collègues NGUYEN Toan Linh Tam et LE Quoc Cuong pour leur coopération, leur assistance et aussi leur motivation qui nous ont aidé de mener bien notre travail En fin, merci ma famille, mes professeurs l’IFI , mes amis Vietnamiens ainsi que mes collègues étrangères qui m’ont rendu une ambiance vraiment agréable pour que je puisse réussir mon stage Ecole Nationale Supérieure des Télécommunications Table de matières Remerciements 1 Introduction 1.1 Problématique 1.1.1 Faiblesse de cryptographie classique 1.1.2 Pourquoi le quantum est-il choisi pour la cryptologie? 1.2 Projet CARE-2 Innovative 1.3 Objectif du stage 1.4 Plan du rapport 5 6 Distribution de Clef Quantique 2.1 Principes de DCQ 2.2 Quelques protocoles pour CQ 11 Protocole BB84 3.1 Description du protocole 3.2 Securité de BB84 3.2.1 Preuve de la sécurité de BB84 3.2.2 Paramètres fondamentaux 3.2.3 Quelques types d’attaques de Eve contre BB84 3.2.4 Protections contre les attaques 13 13 17 17 19 23 24 Simulation et visualisation du protocole BB84 27 4.1 Spécification pour une implémentation simple de BB84 27 4.2 Implémentation en détail 29 Conclusion 39 Bibliographie 41 Liste de Figures 2.1 Trois paires de bases utilisées dans le protocole six-état 12 3.1 quatre états Non-orthogonaux utilisés dans le protocole BB84 14 4.1 Schéma de relation entre les objets principaux dans la simulation du protocole BB84 37 Section Introduction 1.1 Problématique L’échange de l’information est toujours un besoin essentiel dans la vie humaine, en particulier dans la société contemporaine La quantité de l’information échangée augmente chaque minute, chaque second ou même chaque microseconde Et est-il inévitable pour tenir compte de l’importance de son secret? Il concerne la sécurité et l’intégrité des données transférées On a déjà considéré ceci étant fixé par des techniques de cryptographie classique, par exemple: clef de symétrie/asymétrie ou toutes les deux dans les meilleurs crypto-systèmes d’aujourd’hui Cependant, dans l’ère des ordinateurs puissants avec la technologie développée des mini-processeurs grande vitesse (milliard de calculs par secondes), la cryptographie classique a montré graduellement sa faiblesse 1.1.1 Faiblesse de cryptographie classique Comme nous avons su, presque tous les crypto-systèmes courants produisent des clefs pour le chiffrement (ou déchiffrement) de messages en utilisant: • un choix aléatoire d’un ensemble de valeurs possibles comme dans le DES et ses variantes • des fonctions sens unique qui sont considérés difficiles renverser, comme dans Diffie- Hellman et RSA [1] Le temps nécessaire pour Nguyen Thanh Mai, Promo8, IFI SECTION INTRODUCTION renverser de telles fonctions est exponentiel en fonction de la taille des données d’entrée Pour l’ancien, nous pouvons penser qu’il est sûr quand la clef est aléatoirement produite Mais il n’est pas vraiment possible de réaliser la génération de clef aléatoire, en principe, en utilisant les ordinateurs actuels aux états déterministes et finis Cependant, la situation n’est pas meilleure avec des fonctions sens unique Malheureusement, jusqu’ici personne ne donne aucune preuve indiquant que les fonctions sens unique sont croyablement mathématiquement difficiles inverser D’ailleurs, Peter Shor a découvert en 1994 que temps factoriser un grand nombre entier ou calculer le logarithme discret est polynôme si appliquant des ordinateurs de quantum Ainsi la cause majeure qui menace les crypto-systèmes d’aujourd’hui, est le développement vraiment rapide en informatique de quantum Mais aucun problème n’a aucune solution, devoir est juste pour la découvrir Et une proposition pour la cryptographie courante est cryptographie de quantum 1.1.2 Pourquoi le quantum est-il choisi pour la cryptologie? Wiesner, dans son papier, a premièrement proposé en 1970 la CQ qui n’avait pas été publié jusqu’en 1983 (apparu dans [2]) CQ, ou plus précisement Distribution de Clef Quantique, propose une méthode alternative aux méthode mathématiques Elle se base sur les lois de la physique et vise assurer la sécurité inconditionnelle de l’échange de clef Elle a ouvert devant les scientifiques une nouvelle axe de recherche pour résoudre le problème courrant de la cryptogaphie 1.2 Projet CARE-2 Innovative • Introduction du projet – SECOQC SECOQC est un programme cadre de l’Union Européen être lancé en avril 2004, par un centre de recherche autrichien Cryptographie Quantique Development of a Network for Secure Communication based on Quantum Cryptography Nguyen Thanh Mai, Promo8, IFI 1.3 OBJECTIF DU STAGE SECOQC posera la base d’un réseau de communications haute sécurité, en développant la recherche expérimentale de la technologie quantique et en la connectant la cryptographie, la technologie des réseaux, et d’autres disciplines liées aux technologies de l’information Dans ce projet, il y a 41 participants de 12 pays Européens dont la France – CARE-2 Innovative est un projet dans le cadre du SECOQC, réalisé au Centre Expérimental de EUROCONTROL (EEC) Dans la collaboration entre EUROCONTROL et ENST-Paris, le département INFRES est responsable de l’architecture du réseau et de la validation de la sécurité, au sujet " Renforcement de la sécurité des communications aéronautiques en utilisant la Cryptographie Quantique " Ce projet a été divisé aux sujets suivants: ∗ étudier profondément et visualiser le protocole d’échange de clef quantique BB84 ∗ examiner la faisabilité de l’intégration de la CQ dans les réseaux de satellite (voir le rapport de M Le Quoc Cuong) ∗ renforcer la sécurité des communications du réseau ATN en utilisant la CQ (voir le rapport de M Nguyen Toan Linh Tam) • Ecole Nationale Supérieure des Télécommunications de Paris Mon stage s’est déroulé au département Informatique et Réseaux3 , ENST4 Il a duré mois au début, et a prolongé mois de plus la demande du travail J’ai fait mon stage sous la direction d Professeur Patrick Bellot5 , thésard Romain Alléaume6 et thésard Dang Minh Dung J’ai travaillé dans le groupe de Cryptographie Quantique dans le cadre du projet CARE-2 1.3 Objectif du stage Comme cité au-dessus 1.2, notre équipe se compose stagiaires qui sont responsables de sujets Nous avons du donner un rapport ensemble après l’étude précise de chaque sujet http://www.infres.enst.fr/ http://www.enst.fr/ http://www.infres.enst.fr/ bellot/ http://www.infres.enst.fr/ alleaume/index.html Nguyen Thanh Mai, Promo8, IFI SECTION INTRODUCTION Mon devoir est d’étudier, faire une synthèse du protocole BB84 Après la rédaction de ma partie et l’a réunie des celles de mes collègues pour fournir le rapport7 , mon travail suivant est de construire un programme de simulation et de visualisation du protocole Et le simulateur a du être implémentée en Java et pu fonctionner sur réseau plutôt qu’une machine unique 1.4 Plan du rapport Ce mémoire se compose sections et elles sont organisées (structurées) en ordre suivantes: Dans la première section, je présente le contexte général, l’objectif du mon stage et le plan du rapport C’est la section d’Introduction La deuxième donnera une bref introduction de la Cryptographie Quantique Puis, on prend connaissance de la Distribution de Clef Quantique (DCQ) par ses principes et certains protocoles de DCQ Une étude profonde du premier protocole DCQ BB84 sera trouvée dans la quatrième section Protocole BB84 en détail On va conntre plus le protocole lui-même, la citation des preuves de sa sécurité inconditionnelle, ses paramètres fondamentaux, les types d’attaque contre BB84 et les protections contre elles Dans la section suivante, on aura une Implémentation de BB84 En fin, je donnerai la Conclusion consulter le rapport l’adresse http://www.eurocontrol.int/care/innovative/care2/ENST/WP3.pdf Nguyen Thanh Mai, Promo8, IFI Section Distribution de Clef Quantique 2.1 Principes de DCQ L’échange de clef de quantum est basé sur deux théorèmes physiques qui aident produire d’une clef sécurisée entre Alice et Bob Ils sont le principe d’incertitude [3] et le théorème non-clonage • principe d’incertitude: c’est un des principes fondamentaux dans la mécanique quantique Ce principe dit que une mesure peut nous rendre certains résultats différents Chaque valeur obtenue par la mesure a une probabilité prédite et n’est pas dû une imprécision de mesure • théorème non-clonage: Basé sur le principe dincertitude, il nexiste aucune faỗon de connaợtre sûrement un état Et c’est impossible de cloner un état inconnu C’est dire que l’on peut pas obtenir une copie identique d’un état aléatoire de quantum En comparaison de la distribution de clef de cryptographie traditionnelle, DCQ peut surmonter certains imperfections Comme cité ci-dessus, DCQ est basée sur la mécanique quantique Le point fort principal de DCQ résume en qu’il assure la confidentialité des clefs, garantie par les lois physiques de quantum C’est la raison essentielle pour laquelle DCQ est favorisée Les techniques de DCQ peuvent fournir la distribution automatique de clef qui offre une plus grande sécurité par Distribution de Clef Quantique Nguyen Thanh Mai, Promo8, IFI 28 SECTION SIMULATION ET VISUALISATION DU PROTOCOLE BB84 Java est employé, le logiciel sera exécutable sur presque tous les systèmes et ordinateurs Description des Fonctions La cible primaire de la simulation, comme mentionnée ci-dessus dans la partieObjectives, est d’illustrer l’opération de la cryptographie de quantum dans la réalité En outre, elle simulera les actions de Alice, de Bob, de Eve et les canaux entre eux Alice Alice est l’expéditeur du message chiffré Elle doit communiquer avec Bob pour produire une clef aléatoire Ceci sera fait en suivant séquentiellement toutes les étapes dans la part ?? En d’autres termes, Alice et Bob se communiquent travers le canal de quantum afin d’échanger la clef Elle doit préparer cette clef sous la forme d’une chne des qubits aléatoires Il la faudrait informer Bob du début et de la fin du message et de chaque impulsion Elle est également capable d’écouter le canal pour savoir quand Bob finit sa détection d’une impulsion Une fois tous les qubits ont été envoyés et reỗus, Alice communiquera avec Bob les bases pour coder les bits envoyés, les positions des bits qu’elle utilise dans la phase de correction d’erreurs et de purification Sa communication avec Bob est sur le quantum et le canal public Alors, elle communique directement avec l’objet de canal, simulant sa transmission des impulsions dans une polarisation aléatoire La tâche finale d’Alice est d’afficher tous les résultats de ses actions consécutives pour le but de la démonstration Et elle doit également fournir aux utilisateurs une interface pour modifier des paramètres affectant le protocole tel que le nombre de photons dans une impulsion ou la taille désirée pour l’évaluation des erreurs, etc Bob Bob est le partenaire de Alice dans ce protocole Il est la destination de son message Certaines de ses fonctions sont les mêmes avec les siens comme écouter le canal, lire/écire l’information au canal Pour répondre l’impulsion d’Alice, il doit accuser la réception La phase d’ Annonce de Base différencie son opération du sien C’est l’émission de toutes les bases aléatoirement choisies par son détecteur de photons pour mesurer les impulsions d’Alice Une autre différence entre Alice et Bob est la décision de la polarisation du photon Du côté d’Alice, ceci est décidé par son appareil mais du côté de Bob, il est fait par lui Mais le point commun ici est que les deux choix sont aléatoires Pour avoir une simulation d’échange de clef de quantum la plus semblable lequel en réalité, il faut également faire attention l’interaction entre Bob et Eve En conclusion, Bob doit afficher son résultat comme Alice sauf moins de paramètres configurer au début 28 Nguyen Thanh Mai, Promo8, IFI 4.2 IMPLÉMENTATION EN DÉTAIL 29 Eve Eve se tient au milieu d’Alice et de Bob Elle joue leurs deux rôles en même temps Ainsi, elle partage avec eux beaucoup de fonctions communes afin d’exploiter BB84 Sa motivation principale est de rassembler autant que possible les informations sur la clef partagée entre Alice et Bob sans être découverte Son avantage est de pouvoir en même temps recevoir ou envoyer des impulsions travers le canal de quantum dans la stratégie (intercept/resend) et réaliser des attaques faisceau-décomposition Mais ceci est limité par la configuration du canal En fin, elle doit présenter ses actions et résultats aussi bien Elle doit également permettre aux utilisateurs de configurer ses paramètres Cannal L’objectif de la simulation est de faire l’objet Channel le plus identique au canal de quantum en réalité Il signifie que celui-ci doit avoir toutes les propriétés, ici la loi physique mentionnée dans 2.1 on page 9, que l’un vrai obtient Quand le canal est activé, il doit diffuser l’information d’une impulsion (nombre de photons dans cette impulsion, polarisation de photon en secret) d’Alice/Eve Eve/Bob, et doit rendre le résultat après la mesure de leurs détecteurs Le canal cause parfois des erreurs la communication telle que la perte d’impulsions dans la transmission Et comme chacun des trois acteurs ci-dessus, le canal montre ses opérations et accepte la modification d’utilisateurs par le GUI 4.2 Implémentation en détail Maintenant, nous entrons dans la partie principale de cette section C’est l’implémentation du protocole DCQ BB84 Le protocole est appliqué par trois caractères principaux: Alice (expéditeur), Bob (destinataire) et Eve (espion) Toutes leurs communications sont effectuées dans deux canaux séparés: un de quantum (obéissant des lois physique de quantum) et un public (employant les lois normales de communication publique) En employant Java pour développer le programme, trois acteurs seront représentés par trois fils séparés et pour agir l’un sur l’autre entre eux par l’accès dans deux canaux mis en application par deux objets publics Ces deux objets sont créés et observés par le fil principal Donc au total, il y a quatre fils qui fonctionnent simultanément sur un même ordinateur, la même machine virtuelle de Java Dans cette communication, Alice garde le rôle actif et Bob le passif sauf son choix des polarisations mesurer et l’annonce de celles-ci Alice Pour Nguyen Thanh Mai, Promo8, IFI 29 30 SECTION SIMULATION ET VISUALISATION DU PROTOCOLE BB84 sa partie, Eve essaie toujours son meilleur pour extraire des informations utiles de la clef partir d’information échangée entre Alice et Bob, en appliquant différentes méthodes d’attaque Et pour la simulation de la synchronisation dans la communication de trois personnes, toutes les données écrites dans le canal seront prises dans un tampon Le tampon de quantum peut être consulté et écrit par n’importe qui Pour le public, il est seulement disponible pour chacun de le lire Mais Alice et Bob peuvent écrire sur le canal public, pas Eve Le moment où on peut accéder au canal pour information sera décidé par deux objets de canal Si c’est le moment indisponible, l’acteur recevra une valeur nulle et tombera encore dans l’état d’attente Dans cette simulation, le chiffre représentera la polarisation diagonale et le chiffre le rectiligne Structure des classes Comme cité ci-dessus, toutes les transactions, entre trois acteurs principaux: Alice, Bob et Eve, sont traitées sur les deux canaux, premièrement sur le quantum, puis sur le public Alors on divise l’analyse de l’implémentation suivante en deux majeures parties (canal de quantum et canal public) et un supplément (GUI) Canal de quantum Le canal de quantum est simulé comme un objet dans le fil de main() C’est intrinsèquement un contrơleur de la chne des impulsions, transmises d’Alice Bob au travers d’Eve Ici ces impulsions sont mises en application comme objets de qubit Un objet de qubit contient la valeur de bit binaire corrélatif (0 ou 1), sa polarisation (aussi évalué ou 1, un champ d’étiquette pour examiner l’interception d’Eve et un autre champ pour le nombre de photons dans cette impulsion Ce canal de quantum simulé fonctionne comme un vrai sous l’aspect physique Il fournit différentes méthodes pour Alice, Eve et Bob pour qu’ils puissent s’agir ensemble Ils peuvent envoyer ou lire l’information du canal ou lancer une attaque sur lui (Eve) Il y a des règles spécifiques suivantes suivre: • Alice Elle peut transmettre autant de qubits qu’elle veuille pendant son intervalle de temps sans sinquiộter si Eve ou Bob les reỗoit ou non • Eve Elle ne peut pas directement extraire l’information partir d’un photon, tel que sa polarisation Elle peut changer la polarisation d’un photon dû sa mesure fausse Après l’interception d’impulsion d’Eve, 30 Nguyen Thanh Mai, Promo8, IFI 4.2 IMPLÉMENTATION EN DÉTAIL 31 le champ d’étiquette sera changée pour l’accès de Bob cette impulsion • Bob Il ne peut pas accéder directement au photon pour obtenir l’information d’un qubit, ni le lire avant Eve C’est dire que Bob peut détecter un photon après le commutation de champ d’étiquette par Eve Au-dessous est la description de l’objet de qubit: Qubit int value int polarization int tag float photons Canal public Toutes les phases du traitement de la chne de qubits pour distiller la clef finale, ont lieu sur le canal public Chaque phase est mise d’accord entre Alice et Bob avec des paramètres nécessaires transmis Et ces échanges sont répétés et ont la même structure contient le nom de la phase et ses paramètres Donc, l’information de toutes ces phases est fixée dans le format suivant: NomPhase:paramètres - paramètres séparés par ’:’ A côté des commandes ci-dessus, il y a deux autres commandes New et End, employés par Alice pour signaler Bob le début et la fin d’une session de DCQ La simulation sera déclenchée par la commande New d’Alice, envoyé au travers du canal public accompagné avec la longueur de la chne de qubit envoyer Alice commence alors envoyer séquentiellement son message, bit par bit Ceci est fait en employant la méthode Write() de l’objet du canal de quantum en produisant sa polarisation prévue, la valeur de ce qubit, le nombre de photons dans l’impulsion et l’ordre du qubit Et cette information sera écrite dans le tampon de quantum et signalée Eve par le canal de Quantum Méthode Write() d’Alice sur le canal de quantum Write( int Polarization, int value, float Intensity, int BufferLocation) Nguyen Thanh Mai, Promo8, IFI 31 32 SECTION SIMULATION ET VISUALISATION DU PROTOCOLE BB84 Eve reỗoit le signal, vient du canal de quantum, des bits écrits dans le tampon de quantum et doit au moins les reconntre avant qu’on permette Bob de les regarder Ceci est résoudre le problème du synchronisme en réalité Une fois qu’Alice a transmis tous les bits dans son message, elle attend la réponse de Bob En recevant un qubit, Eve choisit les attaques prendre pour extraire l’information ou le laisse détecter Bob Elle a différents choix: faisceaudécomposition (beam-splitting), intercept/resend, toutes les deux attaques ou rien fait Eve peut appliquer certaines attaques séparément sur le même endroit dans le tampon du canal de quantum Si elle essaie de décomposer le photon, elle doit indiquer sa position, et la capacité de décomposition de son miroir Cette force de signifie que Eve ignore ce photon et le passe Bob tandis que la valeur de prouve que Eve détecte tous les photons dans l’impulsion et par conséquent, cette impulsion est entièrement changée Dans le cas d’un succès de faisceau-décomposition, Eve sait la polarisation d’Alice qui est sauve-gardée dans le tampon Méthode BeamSplitting() de Eve sur le canal de quantum BeamSplitting(float MirrorStrength, int BufferLocation) BeamSplitting(float MirrorStrength, BufferLocation interne) Elle peut également employer séparément l’attaque d’intercept/resend Elle peut faire ceci avec le commande IR en fournissant la position de l’impulsion, la polarisation de photon mesurer et également la valeur pour la force de renvoie Et le reste du travail est pour l’objet de canal de quantum Il est responsable de vérifier la polarisation choisie par Eve, pour mettre jour l’endroit de tampon et pour renvoyer le résultat de la mesure Eve Méthode IR() de Eve sur le canal de quantum: IR( int Polarization, float ResendIntensity, int BufferLocation) Une fois que Eve finit son travail, elle doit reconntre la valeur et décaler le drapeau de la permission de Bob Ceci est accompli par la méthode suivant: Méthode tag() de Eve sur le canal de quantum: 32 Nguyen Thanh Mai, Promo8, IFI 4.2 IMPLÉMENTATION EN DÉTAIL 33 tag(int BufferLocation) Après étant décalé le bit de la permission, Bob peut lire l’information de ce photon avec la même méthode que Eve IR excepté sans le paramètre ResendIntensity Cette méthode renverra Bob la valeur de ce photon ou un message vide La méthode read() de Bob inclut les effets de bruit dans le canal, l’efficacité de détecteur de Bob et même les darkcount Tous ceux-ci dont la technologie est réaliste sont uniquement appliqués Bob tandis qu’on assume une technologie parfaite Eve pour détecter des impulsions Quand tous les bits sont reỗus, Bob passe la phase Annonce de Bases et envoie la commande ReceivingBase Alice avec son ordre des paires contenant la position du qubit et de sa polarisation devinée Bob peut envoyer Alice un message comme ceci: ChosenBases:pos1:polar1:pos2:polar2 Ensuite, les polarisations diagonales et rectilignes sont représentées par les chiffres 1s ou 0s Quand ce message est arrivé Alice, celle-ci dispose un message BaseConfirm pour répondre Bob sous la même forme de son ChosenBases excepté les sous-ensembles de lui Sa paire contient des positions où Bob mesure correctement et les polarisations correspondantes BaseConfirm:posi:ori.polari:posj:polarj Eve peut extraire l’information utile partir de tous les deux messages ci-dessus Et elle insérera un blanc dans sa clef où elle n’a pas détecté avec succès ou deviné correctement la polarisation Dans le cas d’appliquer le schéma d’authentification, ces deux messages sont chiffrés, avec la clef réconciliée, par Alice et Bob Ces messages deviennent incompréhensibles pour Eve Comme un résultat désiré, l’information échangée est confidentiel et en sécurité contre Eve Ainsi, Eve n’acquiert aucune information utile de la phase BaseAnnouncement avec le nouvel schéma d’authentification Correction d’erreurs Évaluation des Erreurs: Comme mentionné dans le part 3.1, cette phase est d’améliorer le résultat de celle prochaine, Réconciliation Alice envoie la commande ErrorEstimation Bob avec la taille K du sousensemble extraite partir de la clef plaine et d’une chne des paires (position, valeur) Et Bob renvoie son bit reỗu ces positions avec la mờme darkcount: garder le terme en Anglais Nguyen Thanh Mai, Promo8, IFI 33 34 SECTION SIMULATION ET VISUALISATION DU PROTOCOLE BB84 commande ErrorEstimation:K:pos1:value1: :posk:valuek ErrorEstimation:value1: :valuek s Puis, tous les deux calculent l’erreur-taux observé par bitsnon−corrlatif Ils K rejettent la transmission de quantum en cas d’erreur-taux plus que celui configuré au début, autrement K bits étant enlevés de la clef plaine et passant l’étape suivante Réconciliation: Cette phase est pour la correction d’erreurs Jusqu’ici, Alice et Bob partagent une chne de bits et Eve peut savoir une partie de celle-là (sans utilisation de schéma d’authentification) Dans cette corde commune, il peut y avoir des erreurs provoquées par des attaques de Eve, par le bruit du canal de quantum ou des comptes foncés (dark counts), de l’inefficacité du détecteur de Bob La réconciliation aide Bob et Alice vérifier et corriger ces erreurs Alice calcule d’abord la taille du bloc employer, basée sur l’erreur-taux (comme dans 3.2.2) Alors Alice divise sa corde en blocs de la longueur k Et elle envoie toutes les positions dans chaque bloc, un bloc la fois, Bob avec la commande ErrorCheck ErrorCheck:pos1: :posk Et c’est Bob qui calcule la parité de chaque bloc et répond Alice cette parité avec la commande ParityConfirm ParityConfirm:parityBlocki Puis Alice et Bob tous les deux suppriment le dernier bit du bloc pour éviter la fuite d’information Eve Alice compare sa parité celle de Bob S’ils s’assortissent alors ce bloc est considéré correct Autrement, Alice emploie des recherches binaires pour trouver et éliminer des erreurs Elles répètent ce travail tous les blocs taille k et avec 2n k jusqu’à dépassant 14 de la longueur de clef plaine Confirmation: Pour éliminer maximum des erreurs de la clef partagée, Alice continue son travail avec le sous-ensemble de positions sélectionnées aléatoirement plutôt qu’un bloc continu Purification: Maintenant, Alice et Bob peuvent être sûrs que leur clef partagée n’a aucune erreur ou une quantité négligeable mais elle est seulement sécurisée partiellement Ainsi ils doivent effectuer Purification Cette phase est exécutée par un rond simple du hachage de sous-ensemble aléatoire Pour cette extension, Alice déclare des ensembles de bits avec la commande de PrivacyAmplification En suite, Alice et Bob tous les deux 34 Nguyen Thanh Mai, Promo8, IFI 4.2 IMPLÉMENTATION EN DÉTAIL 35 calculent le bit de parité du sous-ensemble aléatoire Mais ils n’indiquent pas leur résultat Et ce résultat construit la clef finale En fin, Alice envoie la commande End Bob par le canal public pour l’informer de l’arrêt du DCQ Interface Homme-Machine Pour la partie graphique, le paquet Swing de javax sera utilisé Chaque objet dans cette simulation a sa propre interface graphique Ces IHM2 sont étendu de JFrame Pour trois acteurs, ces interfaces sont implémentées dans les armatures séparées dans trois classes correspondantes: AliceInt.class, EveInt.class et BobInt.class Chaque interface contient une étiquette pour installation, une autre pour le résultat, ou tous les deux Dans l’étiquette pour le réglage, les champs de texte (correspondants au leurs paramètres) sont inclus pour permettre aux utilisateurs d’entrer des valeurs désirées dans les expérimentations éventuelles Celle d’Alice possède en plus le bouton Start pour lancer le protocole Deux autres sont pour le canal public et l’un de quantum Tous les deux sont inclus dans la classe de QuantumChannel et la classe de PublicChannel Et ci-dessous, c’est la description des paramètres principaux configurer avant le démarrage de la simulation, dans chaque interface des acteurs et également des deux canaux (d’autres détails, 3.2.2) • Installation d’Alice – Taille de Transmission: est un nombre entier plus grande que et moins de 1000000 (parce que l’endroit de tampon est limité par 1000000) C’est la taille de la corde de qubits transmise sur le canal de quantum – Intensité de Faisceau: est un nombre de virgule flottante dans l’intervalle [0, 1] Ce nombre décide le taux réussi de Eve ou de Bob en détectant un photon Et c’est également la proportion de bits supposée qui est détectée avec succès par Eve en appliquant le faisceau-décomposition – Dimension d’échantillon en Confirmation: est le nombre de bits choisi aléatoirement dans la phase de confirmation C’est un nombre entier plus grand que Interface Homme-Machine Nguyen Thanh Mai, Promo8, IFI 35 36 SECTION SIMULATION ET VISUALISATION DU PROTOCOLE BB84 – Facteur de Sécurité: est un nombre entier, supplémentaire la taille de clef assumée d’Eve avant purification Il laisse augmenter la sécurité du système par un facteur additionnel • Installation de Eve – Décomposition de Faisceau: est un nombre de virgule flottant entre et C’est le pourcentage qu’Eve prend pour décomposer de faisceau – Force de Miroir: est un nombre de virgule flottante entre et inclus Ceci est ajouté pour décider quelle quantité d’impulsion est employée pour faisceau-décomposition – Intercept/Resend: ceci est similaire Force de Miroir sauf utilisé pour Intercept/Resend – Force de Renvoie: après interception d’une impulsion venu d’Alice, Eve ne sait pas l’intensité Ainsi elle doit créer sa propre impulsion d’une autre intensité • Installation de Bob Dans l’interface de Bob, il y a seulement une bte de résultat qui affiche les bits de clef et sa longueur par chaque phase • Installation du canal de Quantum – Efficacité de Miroir: sa valeur est dans l’intervalle [0.1] Quand Eve fait décomposer une impulsion, elle absorbe partiellement ce photon Donc plus bas l’efficacité de miroir signifie beaucoup plus de photons absorbés hors de l’impulsion – Efficacité de Canal: est mesurer l’interférence du canal l’impulsion Plus haut la valeur de ce paramètre, moins d’interférence aux impulsions – Efficacité de Détecteur: mesure la capacité du détecteur de Bob Sa valeur est dans [0, 1] – Dark Counts: représente l’occurrence soudaine d’un dark count au détecteur de Bob • L’installation du canal public Cette interface a seulement une étiquette: le résultat pour montrer la transmission courante au travers d’elle et le résultat de chaque phase 36 Nguyen Thanh Mai, Promo8, IFI 4.2 IMPLÉMENTATION EN DÉTAIL 37 Figure 4.1: Schéma de relation entre les objets principaux dans la simulation du protocole BB84 La relation de tous les objets mis en application dans cette simulation est décrite dans le graphique 4.1 Il y a en total cinq classes principales: deux objets de canal et trois acteurs dans cette communication Chacun des trois objets d’acteur a la même structure Ils tous implémentent l’interface Runnable qui leur permet être lancés en tant que trois fils séparés par la classe de Qcrypt Chacun des acteurs a deux autres classes: une classe d’interface et une de protocole Les classes d’interface sont décrites dans la part juste en haut, The GUI Et celles de protocole sont instanciées par les classes majeurs Alice.class, Eve.class et Bob.class quand le bouton Start en interface d’Alice est pressé Ils commencent en installant tous les paramètres par les valeurs obtenus de l’objet Frame et activent leur méthode de RunProtocol() Cette méthode aide des acteurs passer toutes les phases du protocole BB84 et affiche le résultat corrélatif de chaque phase l’interface correspondante Nguyen Thanh Mai, Promo8, IFI 37 39 Section Conclusion Je viens de vous faire connaissance avec le protocol DCQ BB84, le plus ancien dans l’histoire de la Cryptographie Quantique En rédigeant ce rapport, j’espère de donner une description complète de BB84 au lecteur côté l’un devoir de fin d’étude Particulièrement, c’est vraiment intéressant pour les étudiants, qui aime la découverte, l’expérimentation dans le nouveau domaine comme Cryptographie quantique, en implémentant ce protocol grâce la spécification détaillé dans ?? Basé sur cella-là, un simple simulateur du protocol BB84 a été construit au modèle serveur-client Cette simulation vise faire mieux comprendre le fonctionnement du protocol par la visualisation Cependant, il existe encore des choses améliorer La simulation sera en entier si on peut ajouter certains graphiques de relations tels que nombres de qubits/longueur la la clef finale, pourcentage de qubits intercepté par Eve/erreurs détectées par Alice, Bob A partir de ceux-là, on va faire l’analyse statistique et puis retirer les valeurs expérimentales qui seront utiles pour les tests dans la réalité Nguyen Thanh Mai, Promo8, IFI 41 Bibliographie [1] Christoph Guenther, “"The Relevance of Quantum Cryptography in Modern Cryptographic Systems",” December 2003 [Online] Available: http://www.securitydocs.com/library/1871 [2] S.Wiesner, “Sigact news, 15, no 1,” vol 78, 1983 [3] Nicolas Gisin, Gregoire Ribordy, Wolfgang Tittel, and Hugo Zbinden, “Quantum Cryptography,” vol 74, March 2002 [Online] Available: http://www.tqc.iu.edu/News/Review_of_quantum_crypto.htm [4] Chip Elliott, Dr David Pearson, and Dr Gregory Troxel, “"Quantum Cryptography in Practice",” May 2003 [Online] Available: http://arxiv.org/abs [5] Dominic Mayers, “"Unconditional Security in Quantum Cryptography",” vol 48, pp 351–406, July 2002 [Online] Available: http://arxiv.org/abs [6] Lo Hoi Kwong and Chau HF, “"Unconditional Security of Quantum Key Distribution over Abitrarily Long Distance",” pp 2050–2056, 1999 [7] Peter W Shor and John Preskill, “"Simple Proof of Security of the BB84 Quantum Key Distribution Protocol",” April 2004 [8] Daniel Gottesman and Hoi-Kwong Lo, “"Proof of Security of Quantum Key Distribution with Two-Way Classical Communications",” September 2002 [Online] Available: http://arxiv.org/abs [9] Hoi-Kwong Lo, “"Communication Complexity and Security of Quantum Key Distribution",” April 2004 [Online] Available: http://www.lanl.gov/orgs/p/qri/qri_abstracts_2002/04_08_04_lo.shtml Nguyen Thanh Mai, Promo8, IFI [10] Charles H Bennett, Francois Bessettee, Gilles Brassard, Louis Salvail, and John Smolin, "Experimental Quantum Cryptography", September 1991 [Online] Available: http://portal.acm.org/citation.cfm?id=146396 Center for KvanteInformatik[11] "QuCrypt", University of Aarhus [Online] Available: http://www.cki.au.dk/experiment/qrypto/doc/QuCrypt/qucryptmain.html [12] Andrew G D Rowley, “"The BB84 Protocol",” in QCrypt - A Quantum Cryptography Simulation http://www.dcs.st-and.ac.uk, June 2001 [13] Charles Bennett and Gilles Brassard, “"Quantum Cryptography: Public Key Distribution and Coin Tossing",” in Proceedings of IEEE International Conference on Computers, Systems and Signal Processing, Bangalore (India), December 1984, pp 175–179 [14] Minh-Dung Dang and Hong-Quang Nguyen, “"A new Authentication Scheme for Quantum Key Distribution",” 2005 42 ... utilisant des méthodes de la preuve de Lo et de Chau sur la sécurité pour un protocole semblable Et alors la sécurité de ce protocole est montrée pour impliquer la sécurité de BB84 PDE emploie des codes... codes de Calderbank-ShorSteane (CSS), et des propriétés de ces codes sont employées pour enlever l’utilisation du calcul de quantum du protocole de Lo et de Chau Preuve de Daniel Gottesman et Hoi-Kwong... Section Protocole BB84 3.1 Description du protocole BB84 est le protocole de distribution de clef de quantum le plus bien connu en utilisant quatre états différents qui font une paire des états de