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.

1

Ecole Nationale Supérieure des Télécommunications

1



Table de matières
Remerciements

1

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
5
5
6
6
7
8

2 Distribution de Clef Quantique
9
2.1 Principes de DCQ . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Quelques protocoles pour CQ . . . . . . . . . . . . . . . . . . . 11
3 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

4 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
5 Conclusion

39

Bibliographie

41

3


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

4


5

Section 1

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.


6

SECTION 1. 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 1 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 2
SECOQC est un programme cadre de l’Union Européen à être
lancé en avril 2004, par un centre de recherche autrichien.
1

Cryptographie Quantique
Development of a Network for Secure Communication based on Quantum
Cryptography
2

6

Nguyen Thanh Mai, Promo8, IFI.


1.3. OBJECTIF DU STAGE

7

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 3 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é 6 mois au début, et a prolongé 3 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 3 stagiaires qui sont
responsables de 3 sujets. Nous avons du donner un rapport ensemble après
l’étude précise de chaque sujet.
3

/> />5
bellot/
6
alleaume/index.html
4

Nguyen Thanh Mai, Promo8, IFI.

7


8

SECTION 1. 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 6 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.

7

8

consulter le rapport à l’adresse />

Nguyen Thanh Mai, Promo8, IFI.


9

Section 2
Distribution de Clef Quantique
2.1 Principes de DCQ
1

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
1

Distribution de Clef Quantique

Nguyen Thanh Mai, Promo8, IFI.


10

SECTION 2. DISTRIBUTION DE CLEF QUANTIQUE

rapport aux classiques. Les propriétés de quantum utilisées dans DCQ
sont:
• Enchevêtrement (corrélation de quantum). Un système de quantum
peut être corrélé avec un ou plusieurs systèmes de quantum. Chaque
sous-système produit aléatoirement de ses états, et aucun d’eux ne
présente un état fixe.
• Causalité et superposition. La causalité n’est pas un ingrédient de la
mécanique quantique non-relativiste. Néanmoins elle est employée
pour le but de la combinaison avec la superposition utilisée pour
l’échange de clef secrète.
• Authentification. En échangeant les données secrètes, on doit faire
beaucoup d’attention pour adresser la vraie destination. C’est dommage que l’authentification ne soit pas primitivement incluse dans
DCQ. Ce problème est en train d’être étudié pour améliorer DCQ et
a ouvert certaines approches telles qu’inclure la clef secrète dans les
dispositifs éloignés (à distance) ou la DCQ hybride - arrangements de
clef publique.
• Livraison suffisamment rapide des clefs. Dans la distribution des
clefs, une vitesse rapide est prise en considération(compte). Aujourd’hui, la vitesse atteinte de DCQ est environ 1000 bits/s dans le
matériel à fournir la clef. Mais en fait, c’est souvent plusieurs fois
plus lent [4].
• Robustesse. C’est vraiment un point faible de DCQ puisqu’il utilise

une seule connexion point-à-point. Ainsi, il peut être facilement affaibli par un eavesdropper ou par un accident possible comme le découpage de fibre. Cependant, il est impossible si on emploie des multitrajets pour la transmission des données.
• Dépendance de distance et d’endroit. Nous pouvons clairement constater que DCQ est notamment à court de cet attribut. Deux entités
d’un système de DCQ doivent avoir une connexion consacrée et la distance entre elles est limitée par la matière employée pour transmettre
des photons.
• Résistance à l’analyse de trafic. Quelqu’un peut apprécier d’effectuer
l’analyse de trafic sur une distribution de clef, en particulier, sur un
système délicat qui promet des choses intéressantes en arrière. Il
cause probablement quelques risques. Pour soulager la vie, il devrait
empêcher une telle analyse. Malheureusement, DCQ ne peut pas s’en
10

Nguyen Thanh Mai, Promo8, IFI.


2.2. QUELQUES PROTOCOLES POUR CQ

11

satisfaire mais encore elle attire beaucoup des yeux curieux par ses
installations considérables.

2.2 Quelques protocoles pour CQ
Jusqu’ici, il y a plusieurs protocoles étant proposés depuis l’apparition du
premier BB84. Nous récapitulerons certains d’entre eux dans cette section.
• Protocole BB84
C’est le premier protocole pour la cryptographie de Quantum,
présenté par B ennet et B rassard en 1984, appelé BB84. En 1994,
ce protocole a été prouvé être sécurisé contre l’espionnage par Dominic Mayers, Eli Biham, Michael Ben-Or. BB84 est un protocole
non-déterministe, qui signifie qu’il est utile pour la distribution d’une
suite aléatoire. On reviendra à ceci en détail dans la section 3.1.

• Protocole à deux-état
En 1992, selon la notice de Bennett, quatre états sont trop pour
CQ, seulement deux, ceux non-orthogonaux sont suffisants. Dans la
vérité, la sécurité des bases de CQ sur l’incapacité d’un espion de distinguer sûrement et sans perturbation les états différents qu’Alice
envoie à Bob; par conséquent deux états sont suffisants (Bennett,
1992) s’ils sont incompatibles (c.-à-d., non mutuellement orthogonal).
Mais en pratique, ce protocole n’est pas vraiment efficace. En effet,
bien que deux états non-orthogonaux ne puissent pas être distingués
clairement sans perturbation, on peut clairement distinguer eux au
coût d’un certain pertes (Ivanovic, 1987; Peres, 1988). Cette possibilité a été démontrée en pratique (Huttner, Gautier, et al., 1996; Clarke
et al., 2000). [3]
• Protocole à trois-état
Ce protocole est l’amélioration de BB84. Le protocole BB84 est
symétrique dans son utilisation de polarisation. Après la génération
de la clef, il est nécessaire d’échanger plus d’autre information pour
le secret de la clef. Est il possible non seulement de distribuer la
clef mais de fournir également des informations additionnelles au sujet de l’intégrité? Le protocole à trois-état a proposé d’employer trois
états, au lieu de quatre dans BB84, et trois détecteurs, au lieu de deux
pour BB84, pour casser la symétrie de BB84. Ceci réduit la probabilité d’espionnage pour obtenir de bons états, et ainsi que minimise
Nguyen Thanh Mai, Promo8, IFI.

11


12

SECTION 2. DISTRIBUTION DE CLEF QUANTIQUE

la quantité de l’information utile envoyée par Alice. D’ailleurs, nous
pouvons également découvrir sa présence sur la ligne.

• Protocole à six-état
Tandis que deux états sont suffisants et quatre états sont standard,
un protocole à six-état respecte plus la symétrie de l’espace d’état de
qubit2 , regarde la 2.2. Les six états constituent trois bases, par conséquent la probabilité qu’Alice et Bob choisissent la même base est (à)
seulement 1/3, mais la symétrie de ce protocole simplifie considérablement l’analyse de sécurité et réduit le gain optimal de l’information
de l’espion pour un taux donné d’erreur QBER3 . Si l’espion mesure
tous les photons, le QBER est 33%, en comparaison à 25% dans le cas
du protocole BB84.

Figure 2.1: Trois paires de bases utilisées dans le protocole à six-état.

2

Qubit: bit de quantum
TEBQ: Taux d’Erreur de Bit de Quantum (en anglais - QBER: Quantum Bit Error
Rate) .
3

12

Nguyen Thanh Mai, Promo8, IFI.


13

Section 3
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 base.

Dans la description du protocole, on emploie le prénom classique pour
les différents éléments du protocole. Le prénom Alice est employé pour
l’initiateur du protocole. Le prénom Bob est employé pour le destinataire.
Typiquement, Alice communique avec Bob tandis qu’un espion essaye
d’écouter ou de perturber la communication. Cet Espion est habituellement appelé Eve, abréviation du mot Eavesdropper en anglais. .
Le secret de ce protocole a été prouvé par les personnes différentes telles
que Dominic Mayers, Eli Biham, Michael Ben-Ou et ainsi de suite. BB84
est sécurisé contre l’espionnage dans le sens que Eve ne peut obtenir aucune information sur le transfert entre Alice et Bob sauf le cas où elle indique sa présence après la transmission de données. On va revenir à cet
article dans la section 3.2.
BB84 est un protocole non-déterministe. Cela signifie qu’il distribue
une suite aléatoire des bit. BB84 ne peut pas être employé pour la transmission d’un message déterminé. La communication entre Alice et Bob
étant simplement réussie, se base sur l’aspect aléatoire de chaque étape du
protocole. Maintenant, allons-nous découvrir comment BB84 fonctionne.
Le schéma de codage de quantum du protocole BB84 était la première
proposition de codage de quantum d’information classique où le récepteur
(légitime ou illégitime) ne puisse pas récupérer avec la fiabilité 100%. Il
constitue une base pour la plupart des autres protocoles de quantum.
Nguyen Thanh Mai, Promo8, IFI.


14

SECTION 3. PROTOCOLE BB84

Avec ce schéma, le bit classique est codé par des états de quantum.
Chaque état de quantum peut représenter les deux bits classiques, le 1
ou le 0, et inversement, chaque 0 ou 1 corresponde à un mélange de deux
états égaux de quantum probablement non-orthogonaux. Une de plusieurs
représentations est dans la figure 3.1 où on représente par |0 , |1 , |0 , |1 ,

les quatre états illustrés.

Figure 3.1: quatre états Non-orthogonaux utilisés dans le protocole BB84.
L’information transmise dans le canal de quantum est souvent sous
la forme de photons polarisés. Le codage des bits classiques est fait en
utilisant la direction de la polarisation. Dans le schéma de codage de
BB84, le bit classique 0 est représenté par un photon polarisé à 0◦ et 45◦ de
l’axe horizontal, et les deux directions orthogonales correspondantes, 90◦
et 135◦ , sont employées pour le bit 1.
Selon la mécanique quantique, il n’y a aucune manière de différencier
sûrement deux états non-orthogonaux. Ainsi une mesure de quantum doit
être effectuộe pour dộterminer lộtat reỗu et grõce cela pour obtenir le
rendement classique. Et ce principe d’incertitude fournit les propriétés
cryptographiques requises dans la cryptographie de quantum.
Pour BB84, il y a deux mesures employées pour distinguer les différents
états de quantum:
• ⊕, la mesure permettant d’identifier clairement entre deux états |0
et |1 . Cette mesure s’appelle également la mesure dans la base rectiligne.
• ⊗, la mesure permettant d’identifier clairement entre deux états |0
et |1 . Cette mesure s’appelle également la mesure dans la base diagonale.
En général, l’échange de clef de quantum employant BB84 pour la clef
secrète se compose de six étapes suivantes:
14

Nguyen Thanh Mai, Promo8, IFI.


3.1. DESCRIPTION DU PROTOCOLE

15

1. Transmission de Quantum
Cette phase est la première étape dans une distribution de clef de
quantum. Dans cette phase, une chne aléatoire de n bits classiques
sera créée par Alice et envoe à Bob. Chaque bit de cette chne
sera codé par une base non déterministe. Un bit classique codé par
quantum s’appelle un qubit.. A l’autre côté de la transmission, Bob
reỗoit le qubit et il prend par hasard une base rectiligne (ou diagonale)
pour la mesurer. Quand la transmission est finie, Bob obtiendra une
chne de bits classiques, appelée clef crue, différente de celle d’Alice
en beaucoup de positions, environ 50% même dans le cas de la communication sans erreur de quantum ou beaucoup de plus comme le taux
d’erreur d’appareil est inclus. La prochaine étape du protocole aidera
à remplacer les bits non-corrélatifs entre la chne d’Alice et celle de
Bob, qui sont probablement des erreurs provoquées par l’espion ou la
transmission bruyante de quantum.
2. Annonce De Bases
Comme mentionné dans la partie précédente, dans cette phase, toutes
les positions, où les même bits sont partagés, seront conservées et le
reste sera jeté. Premièrement, à l’aide du canal classique, Bob envoie
à Alice toutes les bases qu’il avait utilisées pour mesurer la chne
des qubits d’Alice. Alice alors compare cet ordre des bases avec le sien
et révèle toutes les positions non-corrélatives sur le canal classique
Bob. Aprốs ỗa, Alice et Bob enlèvent tous les bits aux positions
informées par Alice. Et la partie distillée de la clef crue, appelée la
clé plaine, est totalement la même entre celles d’Alice et de Bob sans
tenir compte des effets des erreurs d’appareil mais encore ou même
tout à fait différent de l’un, de l’autre en fait.
3. Estimation d’Erreurs
Pour réduire la différence entre la clef plaine d’Alice et de Bob due
à l’imperfection d’appareil, il est nécessaire de corriger des erreurs.

C’est la phase l’où l’erreur de la clef plaine est estimée. Il sera exécuté
comme suit. Alice extraira une petite série des bits de la clef plaine et
l’envoiera à Bob. Alice informera Bob un sous-ensemble de positions
de taille K et les valeurs de bits à ces positions dans la clé plaine
obtenue dans la dernière étape. L’émetteur et le récepteur doivent
calculer le taux d’erreurs observées e et gardent cette transmission si
le taux d’erreur est moins qu’un seuil désiré. Et en fin, ils enlèvent
K bits vérifiés et observent le reste. Dans le cas où le taux d’erreur
estimé est plus que le seuil, la clef sera avortée.
4. Réconciliation
Après cette phase, une clef réconciliée sera obtenue après application
Nguyen Thanh Mai, Promo8, IFI.

15


16

SECTION 3. PROTOCOLE BB84

d’un protocole de réconciliation à la clef plaine. La réconciliation est
un processus interactif, ayant lieu dans le canal public. Le but de
cette phase est de corriger les erreurs, pour réduire d’une manière
équivalente la différence, entre les clefs plaines de l’expéditeur et du
récepteur. Mais il est important de prendre note que peu de bits en
tant que possible sont envoyés à travers le canal public car l’espion
peut exploiter cette information. Un protocole nommé Cascade est
appliqué ici. La cascade effectue de correction d’erreurs en envoyant
très peu de l’information à travers le canal public et a été proposée
par Gilles Brassard et Louis Salvail. La cascade fonctionne dans un

certain nombre de ronds. On va en détail dans la partie Implémentation. La phase suivante est la confirmation de l’égalité des clefs
réconciliées de Alice et de Bob. Et si la cascade finit avec succès, la
phase suivante confirmera le résultat.
5. Confirmation
Afin de s’assurer qu’aucune erreur ne sera trouvée, Alice et Bob
échangeront et compareront la parité des sous-ensembles aléatoires
de positions. En général, si une comparaison à z de bits de parité est
faite et il n’y a aucune différence, alors la clef partagée courante est
identique au taux de 2−z . Et si cette phase est réussie, nous croyons
probablement que la clef partagée est maintenant la même, peut-être
avec l’erreur mais à un taux acceptable si z est assez grand.
6. Purification
Enfin, Alice et Bob peuvent avoir une clef identique, mais que pensezvous de l’espion? Après toutes les phases précédentes, peut-être elle
a obtenu de l’information, ainsi elle ne sécurise pas la clef partagée
identique. Que doit on fait pour résoudre ce problème? Et la purification est exactement la réponse. Le but de cette phase est réduire au minimum aussi loin que possible les informations de l’espion
sur la clef et de produire d’une clef plus courte mais plus confiante. À ce moment, l’espion rassemble seulement une quantité négligeable d’informations sur cette corde et Alice et Bob peuvent sans
risque l’employer directement pour le chiffrage inconditionnellement
sécurisé. Pour la purification, des fonctions universelles publiquement connues des informations parasites sont toujours choisies, qui
font la projection d’une (traceront) chne de n-bits à celle de r-bits.
Ce choix peut être déterminé sur le canal public. Et cette proposition
a été faite par Charles Benett, brassard de Gilles, Claude Crepeau, et
Ueli Maurer.

16

Nguyen Thanh Mai, Promo8, IFI.


3.2. SECURITÉ DE BB84

17

3.2 Securité de BB84
Normalement, un protocole serait considéré sécurisé quand il est prouvé
sécurisé contre toutes les stratégies d’attaque de l’écoute clandestine. Ceci
s’appelle la sécurité inconditionnelle , par exemple sans hypothèse. Et
jusqu’ici, c’est toujours encore un fait vraiment difficile même pour un système idéalisé tel que le protocole BB84 avec la source de simple-photon.

3.2.1 Preuve de la sécurité de BB84
La sécurité de BB84, cependant, a été théoriquement prouvée par des différents scientifiques. Dans cette section, quelques preuves seront données
aux lecteurs mais seulement comme une vue générale. Pour plus de détails,
référez-vous aux documents énumérés.

Preuve de Mayers [5]
Le premier devrait être mentionné ici est la preuve de Dominic Mayers en
1996, plus qu’une décennie depuis la proposition originale de BB84, et qui
est la générale mais plutôt complexe. D. Mayers a suivi quelques autres
preuves précédentes d’Eli Biham ou collaborateurs et Michael Ben-Ou.
Pour prouver la sécurité de BB84, la mesure (POVM) évaluée par opérateur positif a été appliquée. Dans sa preuve, il a employé les techniques
de base, la preuve de la sécurité d’un protocole pratique de distribution
de clef de quantum contre toutes les attaques permises par la mécanique
quantique.
Preuve de Lo et de Chau [6]
On pense largement que la distribution de clef de quantum est à offrir
la sécurité sans conditions dans la communication entre deux utilisateurs. Malheureusement, une preuve largement admise de sa sécurité en
présence de source, de dispositif et des bruits de canal a été absente. Ce
problème depuis longtemps est résolu dans cette preuve comme suivant:
avec les ordinateurs de quantum tolérants aux fautes, la distribution de clé
de quantum, à travers une distance longue arbitraire d’un canal bruyant
réaliste, peut être fait en sécurité inconditionnelle. La preuve a réduit d’un

schéma bruyant de quantum à un schéma non-bruyant de quantum et puis
d’un schéma non-bruyant de quantum à un schéma classique non-bruyant,
qui peut alors être attaqué par théorie de probabilité classique.
Preuve de Peter W.Shor et John Preskill [7]
Shor et Preskill nous ont apporté une preuve simple de sécurité
du protocole BB84.
Ils ont employé les Protocoles de Distillation
Nguyen Thanh Mai, Promo8, IFI.

17


18

SECTION 3. PROTOCOLE BB84

d’Enchevêtrement (PDE) pour prouver la sécurité de BB84. Premièrement, un protocole de distribution de clef, basé sur la purification
d’enchevêtrement, est construit et peut être prouvé en sécurité en 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 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 Lo [8]
Pour prouver la sécurité de BB84, contre l’attaque la plus générale, comme
Shor-Preskill, Gottesman et Lo utilise la purification d’enchevêtrement
sauf en deux-sens. Ils prouvent clairement l’avantage du post-traitement
classique avec les communications à deux-sens en comparaison du posttraitement classique avec celles à sens unique dans DCQ. On en a fait grâce
à la construction explicite d’un nouveau protocole (correction/détection
d’erreurs et purification) pour BB84. Le nouveau peuvent tolérer un taux
d’erreur de bit jusqu’à 18.9%, qui est plus haut que n’importe schémas

de BB84 avec des communications classiques seulement à sens unique peuvent probablement faire (normalement 11%[9]). Ainsi leur protocole mène
à un taux plus élevé de génération de clef et reste en sécurité à travers
les distances plus longues que les précédents. Et d’ailleurs, leur recherche
suggère que la purification bi-directionnelle d’enchevêtrement soit un outil
utile dans l’étude de la distillation d’avantage, de la correction d’erreurs, et
des protocoles de purification.
En dépit de toutes les preuves ci-dessus, BB84 reste toujours sans
garantie dû au manque d’authentification. Une fois que l’espion agit en
tant qu’inter-médiateur qui signifie que l’espion joue le rôle d’Alice avec
Bob et inversement comme Bob dans la communication avec Alice et cela
mène la perte de la sécurité de BB84. C’est l’attaque de l’homme-au-milieu.
On proposera une solution dans la sous-section 3.2.4. De plus, un autre
défi pour l’assurance de la sécurité de BB84 est la source du photon. Quand
chaque impulsion contient plus d’un photon, l’espion peut employer la copie
indirecte pour attaquer BB84. Elle pourrait extraire seulement un dans le
faisceau transmis des photons. Néanmoins, cette issue avait été recherchée
par des physiciens pour créer un appareil produisant des impulsions à un
photon.

18

Nguyen Thanh Mai, Promo8, IFI.


3.2. SECURITÉ DE BB84

19

3.2.2 Paramètres fondamentaux
Dans l’implémentation de BB84, beaucoup de paramètres doivent être

pris en considération. Dans cette partie, certains des plus principaux
seront examinés. Et toute l’information a été référée et extraite à partir de l’article [10], le rapport de la première implémentation de BB84, et
d’un logiciel développé pour conduire l’expérimentation de cryptographie
de quantum [11].
Ces paramètres seront divisés selon les éléments concernants. Ainsi, ils
tombent dans quatre parties: paramètres généraux de quantum, ceux de
Alice, ceux de Bob et ceux de l’espion.
• Paramètres de Quantum
Ceux-ci sont liés au canal de quantum. En fait, un vrai canal de quantum cause des bruits lui-même en raison de l’imperfection du matériel
du canal. Alors, pour construire une simulation réussie d’un canal de
quantum, le facteur de l’efficacité de canal de quantum devrait être
ajouté (abrégé comme Qef f ). Et celui-ci sera plus tard inclus dans la
capacité de détecter des photons au détecteur de Eve et de Bob. En
outre, l’intensité des photons transmis dans le canal de quantum est
considérable. Puisqu’en fait, il n’a pas été possible de transmettre encore un photon simple chaque fois, ainsi dans l’expérience réalisée, ils
ont dû(du) remplacer le photon simple par les impulsions faibles qui
contiennent très peu de photons. C’est pourquoi l’intensité du faisceau (λ) est incluse comme paramètre de canal de quantum.
• Paramètres d’Alice
Presque des facteurs considérés seront trouvés dans la partie de configuration de Alice. Le premier est mentionné ici est la taille de clef
crue transmissie (RawKey len ), la longueur de la chne initiale des
qubits que Alice envoie.
Après l’annonce des bases, la clef plaine (de taille à P lainKey len ) est
fournie. Une proportion de cette clé (EE sample ) sera aléatoirement
prise comme échantillon pour l’Estimation des Erreurs. Et alors le
taux d’erreur (errrate ) sera estimé comme suivant:
errrate =

EE sample
P lainKey len

. Dans la phase suivante, la Réconciliation, la Cascade, un schéma interactif et parité-basé de correction d’erreurs, seront répétés quelques
fois. Avant d’exécuter ce protocole, la taille du bloc initial (blk 0 ) pour
Nguyen Thanh Mai, Promo8, IFI.

19


20

SECTION 3. PROTOCOLE BB84

la vérification de parité doit être choisie ainsi que le nombre de répétitions.
La longueur de bloc initiale blk 0 est choisie pour être:
blk 0 =

1
errrate + 4 err1 rate

La taille du bloc blki+1 est définie comme:
blki+1 = 2 ∗ i
La répétition dernière normale se produit quand la longueur de bloc
excède 14 de nombre total de bits. Deux passages supplémentaires sont
employés avec la longueur de bloc environ n4 . Notez que la longueur
de bloc n’excèdent jamais 14 de la longueur de la clef plaine.
Dans cette phase nommé Error Correction dans [10], il y a un autre
choix de ces paramètres. Comme dans cette implémentation là, la
longueur de bloc est choisie expérimentalement alternativement à 5,
7, 10, 14.
Et la taille pour l’échantillon de Confirmation est à 15 comme mentionné dans le [10]. En raison de l’analyse de sécurité dans [11], la
valeur pour le paramètre supplémentaire, un autre comme paramètre

de sécurité, dans la purification, est choisie en tant que ci-dessous:
s = P Apara ∗ (P lainKeylen − EEsample )
Les paramètres de Bob sont en relation avec son détecteur. En fait, un
détecteur, comme canal de quantum lui-même, a sa propre efficacité
qui représente sa capacité de détecter avec succès un photon. Celleci est abrégée comme Def f . Un autre problème affectant le bit reỗu
de Bob est compte foncộ (dark count). Quand le dộtecteur prend un
événement de détection (le clic du détecteur) sans photon, le compte
foncé est produit. Le taux de compte foncé est également inclus dans
la capacité de détecteur et abrégé dcrate .
• Paramètres de Eve
La capacité de l’attaque de Eve est dépendante de ces paramètres.
Pour l’attaque décomposition de faisceau1 , il y a deux paramètres à
configurer. Un est la proportion d’impulsions totales à essayer de décomposer (BS), et l’autre est la proportion du faisceau (nombre de photons dans une impulsion) désirée à extraire (Force de Miroir). Dans
1

20

En anglais: beam-splitting

Nguyen Thanh Mai, Promo8, IFI.


3.2. SECURITÉ DE BB84

21

l’application d’ Intercept-Resend, le premier facteur à considérer est
proportion de faisceaux à l’interception (IR ) et le second est l’intensité
de faisceaux (Resendintensity ) renvoyé.
• Formules utilisée dans ce protocole(référé à [10])

Ces formules sont divisées en deux parties.
Une concerne
l’information de Eve, l’autre est de l’information dans le canal de
quantum.
– Estimation of Eve’s info
Dans la purification, la fonction h(x) dans la classe des fonctions de hachage 0, 1n → 0, 1n−l−s (dedans n est P lainKeylen , l est
EEsample , et s est le paramètre de sécurité arbitraire) est choisie.
On l’estime que Eve sait au plus l bits déterministes avant cette
phase. Et puis, la quantité d’information acquise par Eve est
recalculée comme ci-dessous:
m=

2−s
ln 2

(3.1)

Le nombre de bits fui à Eve est estimé en calculant simplement
la somme du nombre de bits reỗu par Eve par beam-splitting et
aussi intercept/resend. Lequation ?? on page ?? donne le taux de
bits fui à Eve par intercept/resend avec p - le taux d’erreur dans
le canal, référé comme errrate dans les paramètres de Alice:
4
IRrate = √ p
2

(3.2)

Et dans l’attaque beam-splitting, on le suppose que chaque impulsion, à l’intensité de µ, seront faisceau-décomposée avec le
taux réussi de 100% pour la sûreté. C’est pour que Eve puisse

apprendre une partie de bits de µ grâce à la décomposition de
faisceau. Le taux total de bits fui à Eve par deux types d’attaques
est estimé par l’équation ??:
Afin de tenir compte de toutes les erreurs d’échantillonnage que
nous avons rencontrées dans les évaluations ci-dessus, il devrait
être ajouté à la taille prévue de la clef de Eve un certain nombre
d’écart-type (déviation standard). Et cette partie additionnelle
peut être calculée comme dans 3.3 où N est la longueur de la clef
confirmée.
√
N (µ(µ − 1) + (4 + 2 2)p)

Nguyen Thanh Mai, Promo8, IFI.

(3.3)

21


22

SECTION 3. PROTOCOLE BB84

Maintenant, nous pouvons estimer la longueur de la clef de Eve
en multipliant simplement le nombre de bits dans la clef confirmée par le taux de bits de Eve, plus la partie additionnelle d’écart
type. Et en fin, la taille de clef de Eve estimée est le résultat de ??
on page ??:
√
Evekeysize = N ρ + 5 N (µ(µ − 1) + (4 + 2 2)p)

(3.4)

– Simulation du Canal de Quantum
Pour simuler avec succès l’échange de clef de quantum, il est
nécessaire de faire attention notablement au canal de quantum.
L’aspect crucial d’un canal de quantum est dans lequel un photon est sujet du principe de l’incertitude de Heisenberg. Comme
mentionné dans le 2.1 on page 9, le principe d’incertitude déclare
simplement qu’il est incapable pour observer quelque chose sans
l’affecter. Et pour simuler ceci, l’objetif du Canal de Quantum ne
permet pas à Bob et à Eve d’accéder directement à la mémoire
tampon mais les fait plutôt employer les méthodes qui décident
si les mesures de Eve et de Bob sont correctes ou pas, et mettent
à jour des données dans la mémoire tampon avant de renvoyer
un résultat.
Un autre aspect concerne la simulation de transmission des impulsions de lumière plutôt que les photons simples dans le canal.
Dans cette simulation, ceci est résolu en employant la distribution de Poisson au sujet de l’intensité des photons µ pour décider si au moins un photon existe dans cette impulsion ou pas.
Il fonctionne simplement comme ceci: après qu’Alice envoie une
impulsion à Bob de faỗon produire une moyenne de photons de
à, cette impulsion arrive au détecteur de Eve ou de Bob, le canal
de quantum appelle la méthode de PhotonExist de classe de Poisson et le résultat retourné est vrai ou faux. Et ci-dessous, on peut
trouver la formule ?? employée pour calculer la probabilité de x
occurrences en distribution de Poisson au sujet d’un moyen de µ.
µx .e−µ
(3.5)
x!
L’équation suivante 3.6 renvoie la probabilité d’au moins d’une
occurrence dans la même distribution:
f (x) =

µ0 .e−µ

= 1 − e−µ
(3.6)
0!
Cette formule est employée dans la méthode P hotonExist étant
appelée chaque fois que Eve ou Bob détecte un photon. Dans
P (x ≥ 1) = 1 − p(0) = 1 −

22

Nguyen Thanh Mai, Promo8, IFI.


3.2. SECURITÉ DE BB84

23

BeamSplitting, une plus grande partie d’une impulsion sera décomposée par Eve, une probabilité plus élevée que Eve détecte
un photon.

3.2.3 Quelques types d’attaques de Eve contre BB84
Pendant la communication entre Alice et Bob, Eve peut essayer d’écouter
le canal de quantum et aussi celui classique. On suppose qu’elle puisse
prendre facilement tout ce qui voyage au travers le canal vulnérable (celui
classique). Et pour le canal de quantum, Eve applique quelques stratégies typiques d’attaque suivantes à la fouille en tant que le maximum
d’information possible.

Intercept-Resend
Intercept-resend est la stratégie la plus fréquente qu’Eve applique à
l’attaque BB84. Cette attaque simple et même pratique est appropriée
pour qu’Eve mesure chaque qubit dans un des deux bases, comme Bob le

fait. Après, elle prépare un qubit dans l’état correspondant à son résultat
de mesure. Elle envoie ce qubit à Bob. Eve a une probabilité de 50% pour
mesurer correctement le qubit envoyé par Alice. Dans ce cas, elle peut renvoyer avec succès le qubit original à Bob sans détection d’Alice et de Bob.
Pour l’autre 50%, Eve cause la non-corrélation entre les résultats de Alice
et de Bob. Cela aide Alice et Bob à découvrir la présence d’Eve. En bref,
intercept-resend apporte à Eve 50% de l’information tandis qu’il augmente
le taux d’erreur en clef tamisée d’Alice et de Bob, jusqu’à 25% d’environ
même après la liquidation des bits mesurés aux états incompatibles. Eve
n’applique pas normalement 100% cette attaque à la communication, mais
seulement une fraction d’environ 20%, le taux d’erreur sera alors seulement
≈ 5%, tandis que l’information obtenue par Eve augmentant jusqu’à ≈ 10%.

Beam-splitting [12]
Deuxième attaque fréquente est beam-splitting. Eve tire profit de
l’imperfection du système pour extraire l’information. C’est dû aux impulsions produisant non seulement d’un photon mais deux ou de plus. Et grâce
à ces photons en excès, Eve emploie la forme de miroir à moitié-argent pour
la décomposition du faisceau des photons. Elle garde alors un ou deux photons pour mesurer et laisse les autres voyager à Bob. Dans ce cas, il est
difficile à détecter la présence d’Eve. Car décomposer quelques photons
d’un faisceau de photons n’affecte pas la polarisation de lui. Néanmoins,
Alice et Bob peuvent prendre un pré-compromis sur le retard du photon
pour découvrir l’apparition d’Eve.
Nguyen Thanh Mai, Promo8, IFI.

23


24

SECTION 3. PROTOCOLE BB84

Homme-au-milieu
Une imperfection évidente de BB84 est le manque d’authentification.
En plus, avec la technologie de niveau élevé, Eve peut penser à une attaque appelée homme-au-milieu ou attaque intermédiaire, dans laquelle
Eve devient un truqueur. Elle intercepte le canal sécurisé (celui de quantum) et joue comme Bob avec Alice et inversement. En faisant ainsi, elle
peut recueillir toute l’information échangée entre Alice et Bob sans leur
doute. Donc, à la fin de casser ce genre d’attaque, l’authentification est le
souci le plus grand pour le protocole BB84.

3.2.4

Protections contre les attaques

On proposera la manière la plus simple à protéger BB84 contre les deux
premières stratégies Intercept-Resend, Beam-splitting, et pour le troisième
Homme-au-milieu, une nouvelle proposition pour l’authentification de
BB84 sera élaborée.
L’idée initiale proposée par Bennett et Brassard est que si des erreurs
étaient trouvées dans la clef crue de quantum, la clef serait négociée et
pourrait également être cessée. Cependant, ce travail a mené au procédure
appelé la Purification qui nous considère comme une des phases principales dans BB84. Dans cette phase, on suppose qu’Alice et Bob partagent une clef secrète de longueur k. Un ensemble de ces bits, de taille s,
ont été fuis à Eve (s < k). Alice et Bob évaluent combien bits de la clef
Eve possède grâce à l’attaque intercept/resend ou l’attaque beam-splitting.
Alors ils appliquent la purification pour rendre les données de Eve inutiles.
Cette phase est basée sur une fonction de hachage sous la forme: 0, 1k →
0, 1k−s−p , où p > 0 est un certain paramètre de sécurité, pour raccourcir la
clef partagée afin de réduire au minimum l’information de Eve. En conclusion, Eve connait rien ou une quantité négligeable de la clef finale.

Proposition pour l’authentication de BB84
Le papier de BB84 original [13] a mentionné le problème
d’authentification et a présenté une solution à lui, par Wegman et

Carter, basé sur quelques classes des fonctions d’hachage. Cette solution exige une petite clef secrète pré-partagée, qui est employée pour
choisir une fonction d’hachage de la classe pour produire une hache
d’authentification de la correspondance publique entre l’expéditeur et le
destinataire. Par la nature du hachage universel, sans savoir la clef, la
probabilité pour tromper la correspondance est extrêmement basse, même
avec la puissance de computation illimitée.
24

Nguyen Thanh Mai, Promo8, IFI.