Université des Sciences, des Techniques et des Technologies de

Bamako(U.S.T.T.B)

MEMOIRE
Pour obtenir le diplôple de Mastère de la Faculté des Sciences et Techniques de
Bamako(F.S.T)
Spécialité : Réseau Mobile et Web

Presenté par : Massa DICKO

TITRE

ETUDE DES PROTOCOLES DE CHIFFREMENT DE BOUT EN

BOUT : ETAT DE L’ART ET ETUDES COMPARATIVES

Encadré par : Dr Abdourhamane IDRISSA et Dr Jacqueline KONATE

Soutenu le 23 Juin 2018

Jury

Présent du jury Dr Yacouba GOITA Maître-Assistant à l’USTTB

Examinatrice Dr Jacqueline KONATE Maître-Assistant à l’USTTB

Examinteur Dr Oumar MAIGA Maître-Assistant à l’USTTB

Directeur de mémoire Dr Abdourhamne IDRISSA

Table des matières

1 Etude du protocole Off-The-Record Messaging 8

1.1 Principe du protocole OTR . . . . . . . . . . . . . . . . . . . 8

1.2 Fonctionnement du protocole OTR . . . . . . . . . . . . . . . 9

1.3 Les différentes versions du protocole . . . . . . . . . . . . . . 12

1.3.1 Version 1 du protocole OTR . . . . . . . . . . . . . . 12

1.3.2 la confidentialité parfaite . . . . . . . . . . . . . . . . 13

1.3.3 Signature numérique . . . . . . . . . . . . . . . . . . . 14

1.3.4 La version 2 du protocole Off-The-Record Messaging . 21

1.3.5 L’échange des clés d’authentification . . . . . . . . . . 22

1.3.6 Le Protocole des Millionnaires Socialistes (SMP) . . . 26

1.3.7 Version 3 du protocole OTR . . . . . . . . . . . . . . 29

1.4 Les avantages du protocole OTR . . . . . . . . . . . . . . . . 29

1.5 Les points faibles du protocole OTR . . . . . . . . . . . . . 30

2 Le protocole Signal 31
2.1 Principe et Fonctionnement . . . . . . . . . . . . . . . . . . . 31

2.2 Description détaillée du protocole Signal . . . . . . . . . . . 33

2.2.1 L’enregistrement d’un client sur le serveur Signal (TS) 34

2.2.2 Comparaison des clés . . . . . . . . . . . . . . . . . . 36

2.2.3 Envoie d’un message initial . . . . . . . . . . . . . . 37

2
 2.2.4 Réception d’un message . . . . . . . . . . . . . . . . 40

2.2.5 Envoyer d’une réponse . . . . . . . . . . . . . . . . . 40

2.3 Les primitives cryptographiques utilisées dans Signal . . . . . 41

2.3.1 Le protocole d’échange de clé One-Round Key Esta-

blishment(ORKE) . . . . . . . . . . . . . . . . . . . 42

2.3.2 Fonction de dérivation des clés . . . . . . . . . . . . . 43

2.3.3 L’algorithme à Double Ratchet : . . . . . . . . . . . . 44

2.4 Les avantages du protocole Signal . . . . . . . . . . . . . . . 49

2.5 Les points faibles du protocole Signal . . . . . . . . . . . . . 51

3 Comparaison entre Off-The-Record Messaging et Signal 53

4 Conclusion et Perspectives. 55

4.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Annexe 61

3
Remerciement

Avant de vous présenter ce rapport, je tiens à remercier tous ceux qui

m’ont aidé pendant mes études et à la préparation de ce mémoire à la Faculté

des Sciences et Technique(FST). Après celui du bon Dieu, je voudrais en

particulier remercier :
— Dr Abdourhamane Idrissa mon directeur de mémoire, pour son aide

précieuse, pour sa disponibilité et pour tout le temps qu’il m’a consacré

au cours de ce mémoire.

— Dr Sogoba Jacqueline Konaté pour ses conseils, sa disponibilité et son

encadrement tout au long de cette étude

Je voudrais aussi adresser mes sincères remerciements à tous les professeurs

de la Faculté des Sciences et Techniques(FST) pour leurs enseignements et les

cours intéressants qu’ils m’ont donné pendant ma scolarité à la FST. Je n’ou-

blie pas de remercier aussi tous les personnels du Campus Numérique Fran-

cophone(CNF) Enfin, un grand merci à mes parents, ma soeur, ma femme,

mes grand mères et les autres membres de ma famille de m’avoir énormément

aidé et encouragé moralement et financièrement dans les moments les plus

difficiles de ma scolarité à la FST.

4
Contexte

Avec l’avènement des réseaux sociaux et toutes les applications (Facebook

Messenger, Viber, WhatsApp, Imo, Signal, Telegram, Pidgin, etc.) qui vont
avec, la messagerie instantanée est devenue un vecteur essentiel pour la com-

munication. La question qui se pose est la suivante : quel niveau de sécurité

propose ces applications et avec quels outils, protocoles de chiffrement cryp-

tographiques elles assurent cette sécurité ?

De nos jours il existe dans la littérature plusieurs protocoles cryptogra-

phiques qui assurent des conversations sécurisées et privées. On peut ci-

ter des protocoles comme Pretty Good Privacy (PGP) [1], S/MIME [4],

Secure Internet Live Conferencing (SILC)[5], le protocole Off-The- Record

Messaging[8] ou encore le protocole Signal [12](anciennement appelé TextSe-

cure). Les deux (2) derniers offrent le chiffrement de bout en bout. Et plus,
Ils fournissent d’autres propriétés cryptographiques comme l’authentification,

le chiffrement, la non-répudiation et surtout la «confidentialité parfaite ».

L’objectif de ce document est de faire une étude comparative de ces deux

(2) protocoles de chiffrements de bout en bout en partant de l’article de Di

Raimondo et al. [8] et Frosch et al. [12].

5
Introduction

Depuis l’avènement de la communication, les hommes ont toujours cherché

à la rendre privée. La mise en oeuvre de ce désir ardent dépend des périodes

de l’histoire et des moyens techniques disponibles pour l’accomplir.

De nos jours, les moyens de communication sont nombreux et l’un des

plus populaires est la messagerie instantanée. Cette popularité est due à

leur facilité d’utilisation. Malgré cette popularité, les éditeurs des logiciels de
messagerie instantanée font face à un gros problème. Il s’agit de la protection

de la vie privée de leur utilisateur contre la surveillance de masse des agences

de renseignements et les législations des Etats qui les obligent à collaborer

avec eux.
D’autant plus qu’en 2013 à la surprise générale, Edward Snowden ancien

employé de la Central Intelligence Agency (CIA) et de la National Security

Agence (NSA) a révélé au grand public le système de surveillance des appels

et de messages électroniques mis en place par les agences de renseignements

américaines comme la (CIA) et (NSA) [24]. Apres ces révélations, plusieurs

utilisateurs se souciant de leur vie privée ont tourné leur regard vers les
solutions intégrant les protocoles de « chiffrement de bout en bout ».

Le chiffrement de bout en bout est un système de communication où

seules les parties qui communiquent peuvent lire les messages échangés. Il

permet de chiffer vos messages, d’authentifier votre interlocutaire, d’assu-

rer une confidentialité persistante mais aussi le "Déni plausible".En bref, il

empêche l’écoute électronique, y compris par les fournisseurs de télécommu-

nications, par les fournisseurs d’accès Internet et même par le fournisseur du

service de communication. Avec le chiffrement de bout en bout, personne n’est

6
en mesure d’accéder aux clés cryptographiques pour décrypter la conversa-

tion. Les systèmes de chiffrement de bout en bout sont conçus pour résister
à toute tentative de surveillance ou de falsification des communications, car

aucun tier ne peut déchiffrer les données communiquées ou stockées.

Dans ce mémoire, nous présenterons une étude comparative entre deux

protocoles de chiffrement de bout en bout. Le premier protocole est Off-The-

Record Messaging et le second est le protocole Signal. Dans ce document, des

notions et des termes Mathématiques seront utilisées, les explications sont

disponible en annexe pour certaines notions.

Dans la première partie de ce document nous donnerons une étude dé-

taillée du protocole Off-The-Record Messaging en dégageant ses points forts

et faibles. Ensuite dans la deuxième partie sera exposée une étude détaillée
du protocole Signal en montrant ces forces et faiblesses. Suivra la troisième

partie où sera établie une comparaison entre les deux protocoles. Et dans la
dernière partie nous donnerons une conclusion et des perspectives de cette

étude.
Dans ce document, nous allons utiliser Alice, Bob et Eve comme nos pro-

tagonistes. Où Alice et Bob veulent établir une conversation privée et Eve

est un attaquant qui cherche à espionner la conversation entre Alice et Bob.

7
Chapitre 1

Etude du protocole Off-The-Record

Messaging

1.1 Principe du protocole OTR

Off-The-Record Messaging (OTR) est un protocole de chiffrement de bout

en bout présenté par Nikita Borisov, Ian Goldberg, Et Eric Brewer en 2004

[2]. L’idée de base de ce protocole est de partie d’une conversation face à face
entre deux personnes Alice et Bob dans une pièce privée. Dans ce cas :

— Alice peut être sur que personne d’autre n’entend ce qu’elle dira à Bob ;

— Alice peut être sur aussi que leur conversation n’a pas été enregistrée ;
— Par conséquent, Alice est libre de communiquer avec Bob sans se soucier

de l’utilisation de ses paroles contre elle.

Aujourd’hui, des nombreuses communications sociales et commerciales ne se

font pas face à face mais sur internet en utilisant de la messagerie instantanée
par exemple. OTR a été développé pour donner le même niveau de confiden-

tialité à une conversation sur internet (en utilisant la messagerie instantanée)

qu’à une conversation face à face dans une pièce privée.OTR fournit cette

8
sécurité en assurant les propriétés cryptographiques suivantes :

— Le chiffrement de vos messages : personne d’autre ne peut lire vos

messages ;

— L’authentification des utilisateurs : vous êtes assuré que votre

correspondant est bien celui que vous pensez être ;

— Le «Déni plausible » : pendant une conversation, votre correspon-

dant est sûr que vos messages viennent de vous et n’ont pas été modifié.

Mais personne d’autre y compris votre correspondant ne peut prouver

que le message vient de vous à un tiers(une autre personne qui n’a pas

participé à la conversation) ;
— La « Confidentialité parfaite » : si vous perdez le contrôle de vos

clefs privées, aucune conversation antérieure ne sera compromise.

1.2 Fonctionnement du protocole OTR

Alice et Bob seront utilisés comme nos deux protagonistes dans une conver-

sation. En supposant qu’Alice commence une conversation. Le protocole OTR

fonctionne comme suit : Alice fait une demande de conversation OTR à Bob.

Cette demande se fait de deux manières, soit en envoyant un message de

requête OTR ou soit en ajoutant des « étiquettes spéciales » composé des

« espaces blancs » c’est-à-dire un message vide. Dans chaque méthode Alice

indique à Bob la version d’OTR qu’elle veut utiliser pour communiquer avec

Bob. Si Bob est toutefois près et capable de faire une conversation OTR alors

l’envoie d’un message de requête OTR permet de démarrer une conversation

OTR dès sa réception et la méthode par « étiquette des espaces blancs » per-

met juste à Alice d’indiquer à Bob qu’elle est prête à utiliser OTR. Apres cette

9
étape suivra la phase d’échange des clés d’authentification.Pour cet échange

des clés le protocole SIGMA [9] sera utilisé. Le protocole SIGMA (SIGn-
and-Mac) permet d’établir un secret parfait via un échange Diffie-Hellman

authentifié par les signatures numériques [9].

Toutes les exponentiations sont faites modulo un nombre premièr particu-

lier p de 1536 bits (soit 462 chiffre) et « g » un générateur de ce groupe. Alice

et Bob définissent respectivement pubA et pubB comme leur clé publique à

long terme. Alice et Bob font un échange de clé Diffie-Hellman non authenti-
fié [3] pour définir un canal sécurisé ensuite ils s’authentifient à l’intérieur de

ce canal. Cet échange des clés d’authentification sera détaillé ci-dessous dans
la section 1.3 de ce document (Les Différentes versions du protocole). Dès la

fin de l’échange des clés d’authentifications Alice et Bob peuvent commencer

à s’envoyer des messages. IL existe deux types de clés, les paires de clé Diffie-

Hellman éphémères(Xi , g Xi ), les keyidi de chaque partie et les clés secrètes

partagées qui seront utilisées pour dériver les clés de chiffrement ek et les

clés MAC des deux parties. AES(standard de chiffrement avancé) est utilisé
pour chiffrer les échanges et le MAC( code d’authentification de message) est

utilisé pour authentifier la source du message.

Cette procédure d’envoi de message se déroule comme suit : en supposant

qu’Alice veut envoyer à Bob un message. Alice :

Etape 1 : choisit la plus récente de ses propres clés DH de cryptage que Bob

a reconnu avoir reçu, remplace keyA par cette clé et laisse keyidA être son

numéro de série ;
Etape 2 : Si la clé ci-dessus est la clé la plus récente d’Alice, elle génère une

nouvelle clé DH pour obtenir un numéro de série KeyidA+1 ;

10
Etape 3 : choisit la plus récente des clés de cryptage DH de Bob qu’elle a

reçu de lui, remplace keyB par cette clé et laisse keyidB être son numéro de
série ;

Etape 4 : utilise Diffie-Hellman pour calculer un secret partagé à partir des

deux clés keyA et keyB , génère la clé AES d’envoi ek et la clé MAC d’envoi

mk ;
Etape 5 : récupe la liste oldmackeys des anciennes clés MAC utilisées dans

les messages précédants et qui ne seront pas utilisées dans les messages fu-
ture ;

Etape 6 : choisit une valeur du compteur ctr, de tel sorte que le triplé
(keyA , keyB , ctr) ne soit jamais le même pour deux message qu’Alice envoie

à Bob ;
Etape 7 : calcule T A = (keyidA , keyidB , nex−dh, ctr, AES−CT Rek,ctr (msg));

Etape 8 : envoie TA, M ACmk (T A), oldmackeys à Bob.

Bob :

Etape 1 : utilise Diffie-Hellman pour calculer un secret partagé à partir des

deux clés marquées keyidA , et keyidB et génère une clé AES de réception

ek et une clé MAC de réception mk (celles-ci seront les mêmes que les clés
générées par Alice ci-dessus) ;

Etape 2 : utilise mk pour vérifier M ACmk (T A) ;

Etape 3 : utilise ek et ctr pour décrypter AES − CT Rek,ctr (msg).

Apres l’échange de données, l’un des deux interlocuteurs peuvent mettre fin
à la conversation en envoyant un message de requête de fin de conversation

OTR. La Figure 1.1 résume le principe et fonctionnement d’OTR

11
 Figure 1.1 – principe de fonctionnement simplifier d’OTR

1.3 Les différentes versions du protocole

Comme tout protocole, des failles ont été révélées dans le fonctionnement

d’OTR. La correction de ces failles a permis d’avoir différentes versions du

protocole. Dans ce qui suit nous parlerons de ces différentes versions

1.3.1 Version 1 du protocole OTR

Dès le début, Off-The-Record Messaging a posé tous les jalons de la sé-

curité et de chiffrement de bout en bout à savoir les quatre propriétés près

citées ci-dessus (principe et fonctionnement d’OTR). C’est dans les méthodes

utilisés pour assurer ces propriétés qui présentaient des failles et qui ont été

corrigées dans les versions suivantes. L’une des caractéristiques le plus im-
portant et qui n’existait pas dans les systèmes antérieurs à OTR est la «

confidentialité parfaite ».

12
1.3.2 la confidentialité parfaite

Pour assurer cela, au lieu d’utiliser des clés de cryptage à long durée de
vie, Alice et Bob utilise des clés de chiffrement et de déchiffrement à courte

durée de vie générées au besoin et rejetées après utilisation. Ces clés ont aussi
la propriété qu’Il est impossible de les reprendre (c’est-à-dire de le retrouver)

à partir d’une clé à long terme. Une fois que Alice et Bob se débarrassent
d’une clé de courte durée de vie, même si un attaquant détient une grande

quantité d’informations, il serait impossible par tous les moyens de récupé-

rer la clé et décrypter ainsi les messages chiffrés avec celle-ci. Non seulement

Eve sera-t-elle incapable de reconstruire la clé, mais Alice ou Bob eux-mêmes

seront incapables de lire ces messages passés. C’est ce qu’on appelle « confi-

dentialité parfaite ».
Pour assurer cette confidentialité, le protocole Diffie-Hellman est utilisé. Diffie-

Hellman [18] permet à deux parties de communiquer sur un canal public

pour convenir sur un secret partagé, sans le révéler à un attaquant. En bref,

les deux parties commencent par choisir des paramètres publics à savoir un
nombre premier p et un générateur g d’un sous-groupe ZP∗ de grand nombre

premier. Alice et Bob choisissent deux nombres (Les clés privées), XA et XB

respectivement, et ils s’échangent g XA et g XB (les clés publiques) sur un canal

public. Alice peut alors calculer le secret partagé S = (g XB )XA . Bob peut cal-
culer le même secret S 0 = (g XB )XA . Maintenant ce secret partagé est utilisé

pour créer la clé de cryptage de courte durée. Cependant, il est présumé qu’il
est intraitable (impossible dans un temps raisonnable) pour Eve de calculer

le secret, puisque XA et XB ne lui sont pas connus.

13
1.3.3 Signature numérique

Les signatures numériques permettent d’authentifier l’auteur d’un mes-

sage. Elles ont un certain nombre de propriétés et utilisent la cryptographie

à clé publique. Il n’est pas nécessaire pour chaque couple des parties commu-
nicantes à maintenir un secret partagé à long terme. Plutôt, chaque partie

doit disposer d’une seule clé publique connue par tout le monde et utilisé
pour vérifier leurs signatures. C’est la différence entre un système à clés asy-

métriques (C’est à dire clés publiques) et un system à clé symétrique (clés

privées). Dans un system à clé symétrique pour n parties il faudrait n2 clés,

c’est à dire que Alice doit avoir une clé différente pour chaque personne, pour
tous les n. Donc toutes les n parties ont n clés soit n2 , d’où une complexité

O(n2 ). Par contre, pour un système à clés publiques il suffit que Alice ait une
seule clé pour toutes les n parties d’où le O(n). Pour cette raison, n parties

ont seulement besoin de O(n) au lieu de O(n2 ) de clé, et les clés publiques
ne doivent pas être gardées secrètes. Les crypto-systèmes RSA [6] et DSS [7]

sont des exemples d’algorithmes basés sur les signatures numériques.

Étant donné que la compromission des clés de signature ne peut pas affec-

ter les anciens messages de la façon dont la compromission des clés de chif-
frement peut les affecter, il est acceptable de garder la même clé de signature

pendant une longue période. Malgré cela les signatures numériques présentent
un grand défaut dans le contexte OTR car les signatures numériques peuvent

être vérifiées par quiconque connaissant la clé publique et peuvent être uti-
lisées pour prouver à un tiers que Alice est l’auteur d’un message sans son

accord. Cette propriété est connue sous le nom de non-répudiation c’est-

à-dire Alice est incapable à un moment ultérieur de refuser la paternité d’un

14
message qu’elle a signé.

Comme OTR veut que personne n’arrive à prouver qu’Alice a envoyé

un message. La signature numérique ne sera pas utilisée dans OTR pour

prouver qu’un message provient d’Alice. Les seules données à signer sont
g xA , et g yB , utilisées dans le protocole d’échange de clé Diffie-Hellman. De

cette manière tout le monde, y compris Bob et Eve, peuvent être sûre qu’Alice
était vraiment celle qui a choisi la valeur de XA qui a produit g xA , mais c’est

tout ce qu’ils savent. C’est le secret établi entre Alice et Bob dans le protocole
Diffie-Hellman qui sera utilisé pour prouver à Bob que le message provient

bien d’Alice. Pour permettre cela une fonction MAC (Message Authentication
Code) sera utilisée.

Message Authentication Code (MAC)

Un MAC est une fonction de hachage à sens unique paramétrée avec une

clé sécrète K. Seul celui qui possède la clé K peut calculer et donc vérifier
une empreinte :

— Alice et Bob partagent une clé K

— Alice envoie à Bob un message M et r = HK (M ) .

— Bob vérifie que le r reçu est bien égal à HK (M 0 ) pour M’ reçut.

Les MAC permettent de garantir à la fois l’intégrité du message transmis

(tous les possesseurs de K peuvent vérifier que M n’a pas été modifié puis-
qu’il correspond à l’empreinte r) mais aussi l’authentification de la source de

données : sous réserve qu’Alice et Bob soient les seuls à partager la clé K, dans
ce cas ils sont les seuls à pouvoir générer l’empreinte HK (M ). Le concept est

relativement semblable aux fonctions de hachage. Il s’agit aussi d’algorithmes

qui créent un petit bloc authentificateur de taille fixe. La grande différence

15
est que ce bloc authentificateur ne se base plus uniquement sur le message,

mais également sur une clé secrète. Tout comme les fonctions de hachage,
les MAC n’ont pas besoin d’être réversibles. En effet, le récepteur exécutera

le même calcul sur le message et le comparera avec le MAC reçu. Le MAC

assure non seulement une fonction de vérification de l’intégrité du message,

comme le permettrait une simple fonction de hachage mais de plus authen-

tifie l’expéditeur, détenteur de la clé secrète. Par contre le MAC ne fournit

pas la confidentialité.

La malléabilité

En plus de la répudiation, une autre propriété dans OTR est la forgeabilité

des messages. Non seulement Bob et Eve ne devront pas être en mesure de

prouver qu’Alice a envoyé un message donné, mais qu’il soit très évident que
n’importe qui aurait pu modifier ou même l’envoyer. Pour ce faire, un schéma

de cryptage malléable est utilisé.

Un crypto système est dit malléable s’il est possible de transformer le

chiffré d’un message m en un chiffré d’un message m’ sans connaître le

message originel m ni obtenir d’information sur lui. Cela permet de modifier

facilement le texte chiffré de manière à apporter des changements significatifs

dans le texte en clair, même si vous ne connaissez pas la clé. Un exemple de

chiffrement malléable est le chiffrement par flot à base l’opération XOR (le

OU-exclusif). C’est-à-dire un chiffrement par flot qui masque avec le XOR

un texte en clair avec un flux de clé. Et donc pour déchiffrer, le même OU-

exclusif est utilisé pour supprimer le flux de clés et révéler le texte clair. Ce
chiffrement est malléable, car une modification de tout bit du texte chiffré

correspond à une modification du bit correspondant dans le texte en clair.

16
Par conséquent, un message chiffré avec un chiffrement par flot ne prouve pas

l’intégrité ou l’authenticité de quelque manière que ce soit. Bien sûr, Alice

peut toujours utiliser un MAC pour prouver à Bob que ses messages sont

vraiment les siens.

Dans cette section nous donnerons une description du protocole OTR

proprement dit avec toutes ces propriétés citées ci-dessus.

Le chiffrement dans OTR

Une conversation OTR commence par l’établissement d’une secrète com-

mune calculée par les deux parties (Alice et Bob) qui sera utilisé pour chif-

frer les messages. Pour cela OTR utilise le protocole d’échange de clé Diffi-
Hellman.

Etape 1 : Alice et Bob se mettent d’accord sur le choix d’un très grand
nombre premier P d’un entier g tel que 1 < g < P − 1 cette phase n’est pas

secret.
Etape 2 Alice et Bob choisissent respectivement x1 et y1 comme leur clé

privée.
Etape 3 : Alice et Bob calculent respectivement A = g x1 (modP ) et B =

g y1 (modP ).
Etape 4 : Alice envoie à Bob g x1 ; Bob peut calculer S11 = (g x1 )y1 Bob envoie

à Alice g y1 ; Alice peut à son tour calculer S11 = (g y1 )x1

Etape 5 : c’est à ce niveau que la conversation proprement dite commence.

Si Alice veut envoyer à Bob un message, elle choisit un nouveau nombre x2

Etape 5.1 : Alice envoie à Bob g x2 , E(M1 , k11 ) ; Bob utilise la nouvelle va-

leur de g x2 pour calculer S21 = (g x2 )y1 et choisit une nouvelle valeur y2 .

Etape 5.2 : Bob envoie à Alice g y2 , E(M2 , k21 ) ; Alice utilise la nouvelle

17
valeur de g y2 pour calculer S22 = (g x2 )y2 et choisit une nouvelle valeur x3 .

Etape 5.3 : Alice envoie à Bob g x3 , E(M3 , k22 ) ; Bob utilise la nouvelle va-
leur de g x3 pour calculer S32 = (g x3 )y2 et choisit une nouvelle valeur y3

Où les Kij = H(g xi yj ), sont le résultat d’une fonction de hachage H sur 128
bit tel qu’un SHA-1 tronquée. E(M, K) désigne la fonction de chiffrement

AES-CTR (mode compteur) en utilisant la clé K. Chaque message est chiffré

en utilisant le secret partagé formé par les deux composants précédemment

échangés par Alice et Bob.

Figure 1.2 – Les étapes d’utilisation du protocole OTR

18
Les clés jetables

Une autre des propriétés importantes du protocole OTR est la « confiden-

tialité parfaite ». Pour assurer cela Alice et Bob doivent oublier les anciennes

clés après chaque échange de message. C’est-à-dire qu’Alice doit jeter la clé
g xn−1 des qu’elle reçoit un message de Bob utilisant la clé g xn . Du fait que les

protocoles de messageries sont asynchrones, il est toujours possible que des

messages de Bob ne soient pas encore reçu par Alice et qui soient chiffrés par

la clé g xn−1 . Alice doit alors garder en mémoire la clé g xn−1 jusqu’à ce qu’elle
reçoit le message de Bob utilisant la clé g xn . En supposant que tous les mes-

sages sont délivrés dans l’ordre, toute séquence de messages provenant de

Bob sera chiffrée par la nouvelle clé g xn . Par contre si Alice envoie plusieurs

messages à Bob dans l’ordre sans recevoir une réponse avec les clés g xn . . .,
g xm , elle aura besoin de garder cette séquence intégrale des clés (g xn−1 , . . .,

g xm ) jusqu’à ce qu’elle reçoit un message de Bob. Car Alice ne peut pas être
sûr de quelle sous-clé le prochain message de Bob sera chiffré. Cela montre

que l’utilisation de clés différentes n’aide pas à améliorer la vulnérabilité.

Pour résoudre ce problème une nouvelle clé est générée chaque fois qu’Alice

reçoit une réponse de Bob. De cette manière Alice à juste besoins de garder
en mémoire ses deux propres clés. A la réception de la réponse qui utilise

la clé g xn , Alice oublie la clé g xn−1 et génère la nouvelle clé g xn+1 qui sera
annoncé dans le nouveau message qu’elle enverrait à Bob. Si Bob ne répond

pas pendent une longue période, Alice sera capable de décrypter un grand
nombre de ses anciens message. Ceci laisse aussi une grande fenêtre de vul-

nérabilité. Pour résoudre ce problème Bob devrait envoyer périodiquement

un accusé de réception de la nouvelle clé d’Alice. Ou alors, Alice peut oublier

19
les anciennes clés après l’écoulement d’un temps « très long » lorsqu’il sera

hautement improbable que des messages de Bob utilisant les anciennes clés
soient toujours en transit.

L’authentification dans le protocole OTR

Pour l’authentification OTR utilise un MAC (Message Authentication

Code) pour authentifier chaque message. Pour générer un MAC une fonc-
tion de hachage à sens unique sera appliquée à la clé de déchiffrement. Ceci

assurera à ce que toute personne capable de lire un message est capable aussi
de le modifier et mettre à jour le MAC. Par exemple, même si l’attaquant

Eve a pu récupérer la clé de chiffrement, d’une manière ou d’une autre, et

déchiffre les messages, elle ne pourra pas convaincre quelqu’un autre que le

message était d’Alice ou de Bob et que ce n’est pas elle qui l’a composé.
La clé de cryptage est elle-même le résultat d’un hachage du secret par-

tagé du protocole Diffie-Hellman, qui doit également être authentifié de la

même manière. Pour cela l’échange initial de Diffie-Hellman sera signé nu-

mériquement comme montre la Figure 1.3

Où (kA , KA ) et (kB , KB ) sont respectivement les clés publique et privée

d’Alice et Bob. Si Bob connait la clé publique d’Alice il peut être sûr que g x1
provient réellement d’Alice et que par conséquent le secret g x1 y1 n’est connu

que de lui et Alice. Bob peut maintenant traiter les messages authentifiés par
la clé H(g x1 y1 ) provenant d’Alice. Noter qu’il s’agit d’une approche hybride

en utilisant à la fois les signatures numériques et les MAC. L’utilisation de

MAC pour authentifier les messages réels permet la répudiation. La signature

numérique est utilisée seulement lors de l’échange initial des clés(DH). Après
cet échange, tout nouvel échange de clé utilisera les MAC. C’est-à-dire, un

20
message du protocole ressemble à :

g xi+1 , E(Mr , kij ), M AC(g xi+1 , E(Mr , kij ), H(kij )). Notez que les clés ki+1,j
ne peuvent pas être utilisées pour chiffrer et authentifier ce message, car le

destinataire ne pourra pas vérifier son authenticité

Figure 1.3 – Signature de clé initiale Diffie-Hellman

1.3.4 La version 2 du protocole Off-The-Record Messaging

L’attaque sur la version 1 du protocole OTR

Un an après sa publication, Mario Di Raimondo, Rosario Gennaro,

Hugo Krawczyk ont trouvé une attaque sur la première version d’OTR

[8]. Cette attaque a été trouvée au niveau de l’échange des clés initiales du
protocole Diffie-Hellman utilisé dans OTR. Elle permet à un adversaire Eve

d’interférer dans l’échange des clés initiales de tel sorte que Alice et Bob at-
teignent toujours la même clé à la fin du Protocole, mais Alice croit qu’elle

parle à Bob alors que Bob Croit qu’il parle à Eve. Pour cela Eve exécute
l’attaque de « l’homme du milieu » (en anglais Man-in-the-Middle Attack )

21
en commençant simultanément une conversation avec Alice et Bob. Les mes-

sages d’Alice à Bob sont remplacés par des messages identiques signés par
Eve, alors que ceux de Bob à Alice portent leurs signatures originales. Les

échanges se déroulent comme suit [8] :

A → E : g X , SignsA (g X ), vA

E → B : g X , SignsE (g X ), vE

B → E : g Y , SignsB (g Y ), vB
E → A : g Y , SignsB (g Y ), vB

Après ces échanges Alice reçoit g Y signé par Bob donc elle est sûre qu’elle

parle à Bob alors que Bob reçoit g X signé par Eve et pense qu’il parle à Eve
or en réalité, il parle à Alice. Après cette attaque démontrée et la proposition

faite dans [8] d’utiliser le protocole SIGMA (c’est un protocole fournissant un

secret parfait via l’échange de clé Diffie-Hellman signée et authentifiée d’où

« SIGn-and-Mac ») pour solutionner cette faille, la version 2 a vu le jour

1.3.5 L’échange des clés d’authentification

Le plus grand changement de la version 2 était le retraitement de l’échange

des clés d’authentification initiales en anglais « Authenticated Key-Exchange

» (AKE). En réponse à l’attaque mentionnée ci-dessus, l’AKE était changé

en variante SIGMA, comme cela a été suggéré. Au lieu d’utiliser le Proto-

cole exactement comme recommandé dans [8], cependant, OTR a adopté une
variante qui masque également les clés publiques des participants à des ad-

versaires passifs. Là où les clés publiques étaient autrefois envoyées en clair,

elles sont maintenant chiffrés à l’aide du secret partagé DH. Le protocole

22
fonctionne toujours en établissant d’abord un échange DH sur un canal non

sécurisé puis ensuite effectuer l’authentification à l’intérieur de ce canal. Le

canal lui-même utilise un identifiant de session sécurisé de 64 bits basé sur

le secret partagé, donc assez court pour être vulnérable à l’attaque par force
brute. En conséquence, un engagement initial (un nombre aléatoire) est uti-

lisé pour assurer qu’aucune partie ne puisse baser son choix de g x sur la
valeur g y de l’autre partie. Les premières étapes de l’AKE dans [2] sont :

Alice :

1. Sélectionne de manière aléatoire une valeur r de 128 bits ;

2. Sélectionne de manière aléatoire une valeur x de 320 bits ;

3. Envoie AESr (g X ), SHA − 256(g X ) à Bob

Bob

1. Sélectionne de manière aléatoire une valeur y de 320 bits ;

2. Envonie g y à Alice

Alice :

1. Calcule s = (g Y )X

2. Envoie r à Bob

Bob :

1. Déchiffre g X en utilisant r

2. Il vérifie que g X est le même que SHA−256(g X ) qu’il a reçu auparavant

3. Calcule s = (g X )Y

À ce stade, le secret partagé s a été établi. Maintenant, pour accomplir l’au-

thentification, Alice et Bob utilisent un hash SHA-256 de s avec différents

préfixes pour déterminer une série de clés MAC et de clés AES. Les clés sont

23
ensuite utilisées pour chiffrer et vérifier l’intégrité de l’information échangée

pendant le reste de l’AKE. Si (vA , sA ) et (vB , sB ) sont respectivement les

paires de clés publiques / privées d’Alice et Bob, le protocole continue :

Alice :

1. calcule les clés MAC a1 , a2 , b1 , b2 et les clés AES a3 et b3

2. Sélectionne keyidA , un numéro de série associé à g X

3. Calcule MA = M ACa1 (g X , g Y , vA , keyidA )

4. Calcule XA = vA , keyidA , SignsA (MA )

5. Envoie AESa3 (XA ), M ACa2 (AESa3 (XA )) à Bob

Bob :

1. calcule les clés MAC a1 , a2 , b1 , b2 et les clés AES a3 et b3

2. Utilise a2 , pour vérifier M ACa2 (AESa3 (XA ))

3. Utilise a3 pour décrypter AESa3 (XA ), et obtenir

XA = vA , keyidA , SignsA (MA )

4. Calcule MA = M ACa1 (g X , g Y , vA , keyidA )

5. Utilise vA pour vérifier SignsA (MA )

6. Sélectionne KeyidB un numéro de série associé à g Y

7. Calcule MB = M ACb1 (g Y , g X , vB , keyidA )

8. Calcule XB = vB , keyidB , SignsB (MB )

9. Envoie AESb3 (XB ), M ACb2 (AESb3 (XB )) à Alice

Alice :

1. Utilise b2 , pour vérifier M ACb2 (AESb3 (XB ))

24
 2. Utilise b3 pour décrypter AESb3 (XB ), et obtenir

XB = vA , keyidB , SignsB (MB )

3. Calcule MB = M ACb1 (g Y , g X , vB , keyidB )

4. Utilise vB pour vérifier SignsB (MB )

À la fin de ce protocole, Alice et Bob possèdent un secret partagé « s » et ont

aussi échangé des identifiants de clés. Alice connaît aussi la clé public de Bob
vB , et est convaincu que Bob connaît la clé privée correspondante sB . Bob

a une assurance similaire à propos d’Alice. De plus, toutes ces valeurs ont
été chiffrées, donc elles sont dissimulées des adversaires passifs. Ils peuvent

ainsi continuer à utiliser les phases restant du protocole comme à la version

1 d’OTR (cf Figure 1.2 : les étapes d’utilisation du protocole OTR).

Bien que l’AKE dans OTR soit assez bon en théorie, il souffre encore d’un
inconvénient pratique. Dans tous les processus mentionnés jusqu’ici, on sup-

pose qu’Alice et Bob connaissent les clés publiques l’un de l’autre avant le
commencement de l’AKE. S’ils ne le font pas, alors Eve peut prétendre être

Bob et utiliser sa propre paire de clés pour la signature, et Alice n’aura pas
une façon de repérer cette tromperie. Cela crée des attaques MITM parti-

culièrement efficace lancées à partir d’un serveur de messagerie instantanée

central. Autrement dit, si Eve contrôle le serveur de messagerie instantanée,

alors elle peut apprendre le contenu de chaque message chiffré envoyé entre
Alice et Bob. En fait, il existe un plugin pour Jabber Serveurs pour lancer au-

tomatiquement les attaques Man-in-The-Middle sur les conversations OTR,

appelé mod_otr [2]. Pour résoudre ce problème, la version 2 d’OTR utilise

le protocole des millionnaires socialistes [2].

25
1.3.6 Le Protocole des Millionnaires Socialistes (SMP)

Ce protocole permet de savoir le plus riche entre deux millionnaires sans

avoir aucune information sur leur richesse. Dans OTR au lieu de comparer

la richesse, c’est l’information détenue par les deux parties qui est comparée.
Comme ci-dessus, toutes les exponentiations se font modulo un nombre pre-

mier particulier de 1536 bits, et g1 est un générateur de ce groupe. Supposons

que Alice et Bob aient respectivement des informations secrètes x et y, et ils

souhaitent savoir si x = y. Le Protocole des Millionnaires Socialistes leur

permet de comparer x et y sans révéler d’autres informations que la valeur

de (x == y). Pour OTR, les secrets contiennent des informations sur les
clés publiques d’authentification à long terme des deux parties, ainsi que des

informations saisies par les utilisateurs eux-mêmes. Si x = y, cela signifie

que Alice et Bob ont saisi la même information secrète, et doivent donc être

les mêmes entités qui ont établi ce secret pour commencer. En supposant
qu’Alice commence l’échange :

Alice :

1. Sélectionne les exposants aléatoires a2 et a3

2. Envoie à Bob g2a = g1a2 et g3a = g1a3

Bob :

1. Sélectionne les exposants aléatoires b2 et b3

2. Calcule g2b = g1b2 et g3b = g1b3

b2 b3
3. Calcule g2 = g2a et g3 = g3a

4. Choix de l’exposant aléatoire r

5. Calcule Pb = g3r et Qb = g1r × g2y

26
 6. Envoie à Alice g2b , g3b , Pb et Qb

Alice :

1. Calcule g2 = (g2b )a2 et g3 = (g3b )a3

2. Choix de l’exposant aléatoire s

3. Calcule Pa = g3s et Qa = g1s × g2x

4. Calcule Ra = (Qa ÷ Qb )a3

5. Envoie Bob Pa , Qa et Ra

Bob :

1. Calcule Rb = (Qa ÷ Qb )b3

2. Calcule Rab = Rab3

3. Vérifie si Rab == (Pa ÷ Pb )

4. Envoie Alice Rb

Alice :

1. Calcule Rab = Rba3

2. Vérifie si Rab == (Pa ÷ Pb )

Si tout est fait correctement, alors Ra b doit avoir la même valeur que
(Pa ÷ Pb ) × (g2a3 b3 )(x−y) , ce qui signifie que le test à la fin du protocole ne

réussira que si x == y. En outre, puisque g2a3 b3 est un nombre aléatoire

inconnu de toute partie, si x n’est pas égal à y, aucune autre information n’est

révélée. Apres l’échange des clés d’authentification, nous allons décrire dans
ce qui suit comment la version 2 d’OTR assure l’échange de données entre

Alice et Bob. Comme ci-dessus, toutes les exponentiations sont effectuées en

modulo un nombre premier particulier de 1536 bits, et g est un générateur de

ce groupe. Supposons qu’Alice ait un message (msg) à envoyer à Bob. Alice :

27
 1. Choisit la plus récente de ses propres clés de cryptage DH que Bob

a reconnu recevoir (en l’utilisant dans un message de données, ou à

défaut, dans l’AKE), en remplaçant la clé KeyA par cette clé et laisse

KeyidA être son numéro de série.

2. Si la clé ci-dessus est la clé la plus récente d’Alice, elle génère une
nouvelle clé DH (next-dh), pour obtenir le numéro de série keyidA+1 .

3. Choisit la plus récente des clés de cryptage DH de Bob qu’elle a reçues

de lui (soit dans un message de données ou dans l’AKE), en remplaçant

la clé keyB par cette clé et laisse KeyidB être son numéro de série.

4. Utilise Diffie-Hellman pour calculer un secret partagé à partir des deux

clés, keyA et keyB , et génère la clé AES d’envoi, ek et la clé MAC

d’envoi, mk.

5. Collecte toutes les anciennes clés MAC qui ont été utilisées dans les
messages précédents, mais ne seront plus utilisées (car leurs clés DH

associées ne sont plus les plus récentes) dans une liste, oldmackeys.

6. Choisit une valeur du compteur, ctr, de sorte que le triple (keyA , keyB , ctr)
n’est jamais identique pour deux messages données entre Alice et Bob.

7. Calcule TA = (keyidA , keyidB , next−dh, ctr, AES−CT Rek,ctr (msg))

8. Envoie Bob TA , M ACmk (TA ), oldmackeys

Bob :

1. Utilise Diffie-Hellman pour calculer un secret partagé à partir des deux

clés marquées par keyidA et keyidB , et génère la clé AES de réception

ek et la clé MAC de réception, mk. (Ceux-ci seront les mêmes que les
clés que Alice a généré, ci-dessus.)

28
 2. Utilise mk pour vérifier M ACmk (TA ).

3. Utilise ek et ctr pour décrypter AES − CT Rek,ctr (msg).

1.3.7 Version 3 du protocole OTR

Apres quelques anomalies découvertes dans le fonctionnement de la version

2 du protocole à savoir : un problème sur les réseaux de messagerie instan-

tanée qui transmettent toujours tous les messages à toutes les sessions d’un

client connecté plusieurs fois. Dans cette situation, les clients OTR peuvent
essayer d’établir une session OTR indéfiniment s’il y a des messages d’entre-

lacement de chacune des sessions [10]. Cette version introduit aussi la mise en
place pendant l’AKE d’une clé symétrique supplémentaire pour chiffrer une

communication sécurisée sur un canal différent (par Exemple, transfert de

fichiers, discussion vocale). Pour satisfaire ce besoin et corriger ces anomalies

de la version 2, la version 3 du protocole OTR a vu le jour. Et c’est cette

version qui est implémentée comme protocole OTR aujourd’hui

1.4 Les avantages du protocole OTR

Le protocole OTR présente plusieurs avantages à savoir : Il est le premier

protocole à permettre le chiffrement de bout en bout en combinant à la fois

les quatre fonctions cryptographiques citées dans la section (principe et fonc-

tionnement) ; Il est open source et son code source est disponible sur Git Hub
[20] ; Il est en plus un protocole multiplateformes, il existe des plugins pour

presque toutes les plateformes (Windows, Linux, Mac OS). Et aussi multi
langages, des librairies sont développées dans plusieurs langages de program-

mations (java, java Script, C, Python, Object Ocaml, Perl etc..). Ce qui lui

29
donne une large fenêtre d’utilisation dans le développement d’application

pour PC.
Il assure aussi l’authentification bout en bout sans un serveur intermédiaire

1.5 Les points faibles du protocole OTR

Malgré les avantages multiples et diverses du protocole Off-The-Record

Messaging, il présente aujourd’hui des multitudes défauts. Un de ces défauts

est qu’OTR ne permet de faire que la messagerie instantanée synchrone.

C’est à dire pour utiliser OTR les deux interlocuteurs devront être en ligne en

même temps. OTR souffre d’un problème « d’obsolescence cryptographique »

[21], l’absence d’un mécanisme de négociation des algorithmes fait d’Off-the-

Record un protocole qui utilise des algorithmes cryptographiques qui datent

de la création du protocole. Cet usage d’algorithme daté est contraire aux

bonnes pratiques actuellement reconnues en cryptographie. Un autre pro-

blème pratique avec OTR est qu’il est toujours utilisé comme plugin dans

les applications clientes de messagerie instantanée. Vu que ces applications

présentent plusieurs failles, un attaquant peut utiliser ces failles pour espion-

ner les conversations privées avec OTR. Off-the-record ne dispose pas des
bibliothèques pour le développement d’application mobile non plus.

30
Chapitre 2

Le protocole Signal

Dans cette partie, nous décrivons le deuxième protocole de chiffrement

de bout en bout de notre étude à savoir le protocole Signal(TextSecure). Le

protocole TextSecure était à l’origine une dérivée du protocole off-the-record

(OTR), avec certaines modifications. Comme changements apportés on peut

citer : la simplification et l’amélioration de la deniability (la possibilité de

denier un message) d‘OTR, ainsi que la création d’un mécanisme d’échange

de clés pour les transports asynchrones [11].

Développer par la société Open Whisper Systems en 2013 sous le nom

de TexteSecure. Le protocole TexteSecure est un protocole de chiffrement

bout en bout développé pour les applications de messagerie instantanée. En

novembre 2015, Open Whisper Systems change le nom TextSecure du pro-

tocole en Signal qui est en fait une fusion de deux applications TextSecure

(application Android) et RedPhone (application Iphone) [25].

2.1 Principe et Fonctionnement

Depuis plus d’une décennie, la messagerie instantanée (IM) est un moyen

de communication aussi bien privée que professionnelle à travers les e-mails

31
classiques. IM est caractérisée par la livraison des messages en temps réel à

condition que les deux parties soient en ligne au même moment. Cependant,
contrairement aux courriers électroniques qui utilisent souvent des protocoles

de sécurité tels que PGP [2] et S / MIME (Secure/Multipurpose Internet

Mail Extensions)[8] , les messages instantanés comme MSN Messenger et

YAHOO Messenger étaient envoyés sans protection.

Aujourd’hui, plusieurs IM implémentent uniquement le chiffrement client -

serveur via TLS, toutefois les solutions comme Off-the Record Messaging(OTR)
[section 2 de ce document] assurent l’intégrité et la confidentialité de bout

en bout des messages. Avec l’avènement des smartphones, des alternatives

de messagerie instantanée s’ouvrent qui utilisent le canal de données pour

communiquer. Cependant, dans le contexte des applications mobiles, l’hypo-

thèse de la messagerie instantanée classique synchrone qui exige que les deux

parties soient en ligne au même moment, n’est plus nécessairement valide.

Au lieu de cela, le contexte mobile nécessite des solutions qui permettent

une communication asynchrone, où une partie peut être hors ligne durant
un certain temps pendant une conversation. Dans ce contexte, les solutions

existantes, telles que OTR, ne sont applicables que de manière limitée. Par
contre le protocole Signal est une bonne option dans ce contexte.

Le protocole Signal repose sur un serveur central, nommée TS (TextSe-

cure Serveur) pour relayer les messages vers les utilisateurs. Le principe du

fonctionnement du protocole Signal est comme suit : En Amont, chaque uti-

lisateur doit s’enregistrer sur le serveur TS. C’est-à-dire, il génère et signe de

manière préemptive 100 clés (un nombre fixe dans [12]) appelés « près-clés »
puis les envoie au serveur TS. Apres cela, si un client (c’est-à-dire un utili-

32
sateur à travers son application) souhaite envoyer un message sécurisé à un

utilisateur donné pour une première fois, il procèdera comme suit :

— Etape 1 : il se connecte au serveur et demande la « près-clé » courante

du destinateur ;
— Etape 2 : il génère sa propre moitié de clé d’échange de message ;

— Etape 3 : il calcule un secret partagé avec la « près-clé » reçue et sa

propre moitié de clé d’échange ;

— Etape 4 : il utilise le secret partagé précédemment calculé pour chiffrer

son message ;

— Etape 5 : il insère dans un paquet l’identifiant de la « près-clé », sa

moitié de clé d’échange locale et le message chiffré ;

— Etape 6 : enfin, il envoyé l’ensemble au (client du) destinateur du

message.

Le destinateur reçoit tout cela comme une simple notification push. Le

client du destinateur a tout ce qu’il faut pour calculer la clé secrète d’échange,

puis déchiffrer le message chiffré pour avoir le message clair. Avec cette tech-
nique d’échange des clés initiales, qui sera détaillée ci-dessous, les deux parties

peuvent continuer à communiquer comme s’ils utilisent OTR. Étant donné

que le serveur TS ne délivrera jamais une même près-clé deux fois et qu’un

client n’accepterait jamais deux fois une même près-clé, le protocole Signal
est en mesure de fournir une « confidentialité parfaite » même pour une

communication entièrement asynchrone

2.2 Description détaillée du protocole Signal

Comme souligner ci-dessus, le protocole Signal est basé sur :

33
 — Un protocole d’échange de clé à un tour (One-Round Key Exchange

(ORKE)) exécute entre deux partie A et B ;

— Le calcule d’une clé secrète à longue durée de vie ;

— Une fonction de dérivation de clé (Key Derivation Function (KDF))

qui prend comme paramètre la clé à longue durée de vie ;

— Des nouveaux secrets Diffie-Hellman et un schéma de chiffrement au-

thentifié [12].

C’est cet ensemble de fonction qui permet à Signal d’être un protocole de

chiffrement de bout en bout.

2.2.1 L’enregistrement d’un client sur le serveur Signal (TS)

Dans cette section nous allons décrire comment un client Pa s’enregistre

sur TS. Cet enregistrement se déroule en 10 étapes.

Etape 1 : une partie Pa demande un jeton de vérification en transmet-

tant son numéro de téléphone et son mode de transport préféré à TS ;

Etape 2 : TS confirme avec un état HTTP 204 ;

Etape 3 : Selon le transport que Pa a choisi, TS expédie soit un mes-

sage court ou un appel vocal contenant un jeton aléatoire au numéro

transmis à l’étape 1 ;

Etape 4 : c’est à cette étape que l’enregistrement réel s’effectue où Pa

montre qu’il possède le numéro de téléphone en renseignant le jeton

reçu ; puis enregistre ses informations d’identification avec le serveur

(via l’authentification de base HTTP ). Il définit enfin ses clés de «

signalisation » kmac;T S;A et kenc;T S;A . Dans cette étape, le client indique
également s’il souhaite communiquer seulement via un canal de message

34
 push ou s’il accepte également des messages courts.

Etape 5 : Le serveur accepte si le jeton correspond à celui fourni à l’étape

3 et que le numéro de téléphone n’a pas encore été enregistré ;

Etape 6 : Pa fournit ses 100 prés-clés et une clé de dernier recours klr à
TS. Les prés-clés ne sont pas transmises individuellement, mais dans

une structure JSON. La clé de dernier recours klr (qui sera définie
ultérieurement) est transmise de la même manière et identifiée par le

keyID 0xFFFFFF.
Etape 7 : Le serveur accepte si le message est bien formé et l’authentifi-

cation HTTP basique est réussie.

Etape 8 : Pa s’enregistre ensuite avec Google Cloud Messaging (GCM)(est

un service de notification mobile développé par Google qui permet aux

développeurs d’applications tierces d’envoyer des données de notifica-

tion ou des informations depuis des serveurs gérés par des développeurs
vers des applications ciblant le système d’ exploitation Google Android

, d’autres applications ou des extensions développées pour le naviga-

teur Internet Google Chrome . Il est disponible gratuitement pour les

développeurs).
Etape 9 : Pa reçoit son regIDAgcm ;

Etape 10 : Il transmet à TS le regIDAgcm après avoir faire une nouvelle

authentification.

A l’usage le nombre de prés-clé sur le serveur diminue. Pa a toujours la

possibilité de stocker de nouvelles pré-clés sur le serveur. Et lorsqu’il n’y a

plus de pré-clés disponibles pour Pa , c’est la clé de « dernier recours » klr qui
sera utilisée comme prés-clé. Cependant, cette dernière ne sera pas effacée

35
du serveur. La Figure 2.1 montre ces différentes étapes pour l’enregistrement

d’un client Signal.

Figure 2.1 – processus d’enregistrement sur le Serveur

2.2.2 Comparaison des clés

Dans le but d’établir une clé publique entre deux parties, le protocole

Signal offre la possibilité d’afficher l’empreinte digitale de la clé publique

à long terme d’un utilisateur. Deux parties peuvent ensuite comparer les

empreintes digitales sur un autre canal (par exemple, un appel téléphonique

ou une réunion en personne). Si les deux parties se rencontrent en personne,

Signal propose également de rendre l’empreinte digitale de leur propre clé

publique à long terme en tant que code QR, en utilisant une application

tierce sur Android, que l’autre partie peut ensuite analyser à l’aide de la

36
même application sur son appareil mobile. Signal compare ensuite l’empreinte

digitale qu’il vient de recevoir à l’empreinte digitale du parti qu’il a reçue dans
le cadre d’une conversation.

2.2.3 Envoie d’un message initial

Avant qu’un premier message puisse être envoyé d’un utilisateur Pa à un

utilisateur Pb , trois étapes principales doivent être complétées

— un protocole d’échange de clé de type ORKE pour partager une clé

symétrique à longue durée de vie (également appelé clé racine) ;

— un protocole de dérivation et de mise à jour de clé qui met à jour la

clé racine et génère une clé de chaînage à partir de laquelle les clés de

chiffrement et de MAC seront dérivées ;

— un système de chiffrement authentifié

Le processus est représenté en détail dans la figure 2.2.

Établissement de secret partagé

Dans la première étape, Pa demande une prés-clé de Pb et reçoit une

structure JSON constitué de : l’identifiant IDz de la prés-clé, de la prés-clé

g xb,z , et la clé à long terme g b de Pb . Pa reçoit également regIDb de TS puis

choisit une nouvelle clé éphémère Xa;0 pour calculer un secret intermédiaire

Secint comme la concaténation de trois opérations DH, combinant la prés-clé

de Pb , la clé à long terme de Pa , la clé à long terme de Pb et la clé éphémère

fraîchement choisie de Pa c’est-à-dire

Secint = (g xb,z .a , g b.Xa,0 , g xb,z .Xa,0 ) (2.1)

37
. À partir de cette valeur, la première clé racine est dérivée via la fonction
de dérivation de clé HKDF.

Gestion des clés

Après calcul du secret partagé par Pa , un nouveau secret kshared est dérivé

de la prés-clé reçue et la partie privée de la clé Diffie-Hellman fraîchement

générée Xa,2 tel que
x Xa,2
kshared = (gb,z ) (2.2)

. De kshared et rkBA , Une nouvelle clé racine rkAB et une clé de chaînage ckAB
sont dérivées à nouveau via HKDF. La clé de chaînage ckAB est finalement

utilisée pour dériver (à nouveau via HKDF) les clés de cryptage et de calcul
de MAC (KEnc ; KM AC ) pour chiffrer et protéger l’intégrité des premiers

messages.

Cryptage authentifié

Un message m ∈ M est chiffré à l’aide d’AES-CTR (AES en mode

compteur sans rembourrage), soit c = EN CkEnc (m). Pa forme alors le mes-

sage de l’étape (3) de la figure 2.2 ; calcule la T ag = M ACkM AC (X), Où
X
X = (V, ga,2 ; ctra ; pctra ; c) où V représente la version du protocole. Pour
l’énumération de messages dans une conversation, les compteurs ctr et pctr

sont utilisés. Les deux sont initialement réglés à 0. ctr est incrémenté avec
chaque message envoyé par une partie, tandis que le pctr est réglé sur la

valeur ctr portée dans le message auquel une partie répond. Le message de
l’étape 3 (de la figure 2.2) est envoyé à TS. Renvoi du message à GCM. Sur

réception du message (3.), TS vérifie si regIDb correspond au numéro de

téléphone Pb . Il chiffrera ensuite les parties du message (3.) destinées à Pb

38
avec la clé de signalisation de Pb (kenc;T S;B ), en utilisant AES-CBC avec le

rembourrage de la norme PKCS5. TS calcule en outre un MAC sur le ré-

sultat, que nous désignons comme macsignal . TS envoie les deux données de

message chiffrées csignal et macsignal , au serveur GCM, avec regIDbgcm du

destinataire. La conséquence de cette couche de chiffrement supplémentaire

est que les serveurs GCM de Google ne pourront voir que le destinataire mais
pas l’expéditeur du message. Ce processus est détaillé à la Figure 2.2

Figure 2.2 – Envoie d’un message initial

39
2.2.4 Réception d’un message

Le processus de réception est représenté à la Figure 2.3, Pb reçoit le mes-

sage à l’étape (5.). Tout d’abord, Pb vérifie macsignal , et si la vérification est

correcte, déchiffre csignal avec sa clé privée à longue durée de vie et la clé pri-
vée unique qui correspond à sa prés-clé d’identifiant IDz , il calcule secint et

sa première clé racine rkBA . Désormais, tous les calculs sont identiques à ceux
effectués par l’expéditeur, jusqu’à ce que les clés de message (kE nc; kM AC )

soient dérivées. Pb vérifie maintenant si le MAC est correct, si c’est le cas, il

déchiffre le message.

Figure 2.3 – réception d’un message

2.2.5 Envoyer d’une réponse

Si Pb veut répondre à un message dans une session existante avec Pa , il

choisit d’abord un nouveau couple de clés éphémère (Xb,0 , g Xb,0 ) et calcule un

40
nouveau kshared comme sortie d’une opération DH qui prend la dernière clé

publique éphémère de Pa g Xa,2 et sa propre clé privée éphémère fraîchement

choisie Xb,0 soit :

kshared = g Xa,2 .Xb,0 (2.3)

. Puis Pb met à jour la clé racine et dérive une nouvelle clé de chaînage en
initialisant HKDF avec le nouveau kshared et rkAB .

(rkBA ; ckBA ) = HKDF (kshared ; rkAB ; constR).

À partir de la clé de chaînage, une nouvelle paire de clé de chiffrement et de

MAC est dérivée. Le message est protégé par ces clés et ensuite envoyé avec
g Xb,0 au correspondant Pa .

2.3 Les primitives cryptographiques utilisées dans Si-

gnal

Dans cette section nous donnerons une description détaillée des approches

et techniques utilisées dans Signal pour lui permettre d’être un protocole de

chiffrement de bout en bout. Pour les opérations d’échange de clé, Elliptic-

curve Diffie–Hellman ECDH (Échange de clés Diffie-Hellman basé sur les

courbes elliptiques, exemple Curve25519) [23] est utilisé. Cette courbe el-

liptique est nativement disponible dans la bibliothèque cryptographique An-

droid de Google. Les chiffrements symétriques dans Signal reposent sur AES

[14] en mode AES-CRT (compteur sans rembourrage) et en mode AES-CBC

(chiffrement par chaînage de bloc) avec le rembourrage de la norme PKCS7

(Public Key Cryptography Standards). L’intégrité des messages est basée sur
les fonctions HMAC-SHA256 [15], [16].

41
2.3.1 Le protocole d’échange de clé One-Round Key Establish-

ment(ORKE)

Comme dans tout système cryptographique, pour commencer une com-

munication sécurisée il faut avoir un secret. Et comment établir ce secret

entre deux parties A et B a toujours été un grand défi dans le monde des

codes. Le protocole Signal établie ce secret en utilisant le protocole « One-

Round Key Establishment » ORKE. Dans Signal, lorsque deux parties A et

B veulent établir un secret partagé entre eux. La partie B génère une paire
de clé à longue durée de vie (b, g b ) et plusieurs paires de clés DH (xb , g xb ).

Les parties publiques de ces paires de clés sont ensuite enregistrer sur le ser-
veur Signal. La partie A fait une requête au serveur Signal pour avoir les clés

publiques de B. A choisit à son tour une nouvelle paire de clé DH éphémère

(xa , g xa ) et une paire de clé à longue durée de vie (a, g a ). A envoie ensuite

les parties publiques de ses paires de clé à B. chaque partie peut mainte-
nant dériver un secret intermédiaire en utilisant 3 opérations DH sur les 4

possibilités offertes par les clés publiques

Secint = (DH(g a , g xb ); DH(g xa , g b ); DH(g xa , g xb )) (2.4)

. Et ensuite le Secint et deux autres constantes sont utilisés comme paramètre

dans la fonction de dérivation de clé HKDF pour obtenir le secret partagé à

longue durée de vie rkBA .

(rkBA ; ckBA ) = HKDF (Secint ; const0; constR)

42
2.3.2 Fonction de dérivation des clés

Une fonction de dérivation de clé est une fonction qui prend en rentrée 4
paramètres :

— Une valeur de la clé source matériel SKM (Source Keying Material) ;

— Une taille de la clé de sortie de valeur L ;

— Une valeur initiale ;

— Une information de contexte CTXinfo.

Elle donne en sortie une chaine de caractère de longueur L bit.

Tilman et al. [12] donnent les raisons pour lesquelles les fonctions pseudo

aléatoires ne sont pas utilisées comme fonction de dérivation des clés. Une
des raisons est que pour les fonctions pseudo-aléatoires, les clés sécrètes ont

une taille bien déterminée. Par exemple pour HMAC-SHA256 il faut une
clé de 512 bits. Cette restriction n’est pas une propriété souhaitable dans

une fonction de dérivation de clé. Car souvent la clé matérielle peut être
un résultat d’un échange de clé Diffie-Hellman. Dans Signal, la fonction de

dérivation de clé utilisée est HKDF qui est basée sur HMAC. Krawczyk [17]
a montré que sous des hypothèses raisonnables que HKDF est une fonction

de dérivation de clé sécurisée.

Dans [12] un algorithme de HKDF est donné comme suit :

KDFT S (rkBA ; kshared ; aux)

aux ← (constR; const2; const1; const0; constK)

(rkAB ; ckAB ) ← HKDF (kshared ; rkBA ; constR||const2)

ksharednew ← HM AC(ckAB ; const1).

(keyEnc ; keyM AC ) ← HKDF (ksharednew ; const0; constK)

43
2.3.3 L’algorithme à Double Ratchet :

L’algorithme Double Ratchet est un schéma cryptographique permettant à

deux parties d’échanger des messages chiffrés en utilisant un secret partagé.

Dans Signal c’est le protocole d’accord de clé X3DH [22] qui est utilisé
pour mettre en place la clé secrète partagée. Ensuite, les parties dérivent de

nouvelles clés pour chaque message à partir du schéma Double Ratchet, de

sorte que les clés précédentes ne puissent pas être calculées à partir des clés

plus récentes.
Les parties ajoutent leurs clés publiques Diffie-Hellman dans l’en-tête

des messages qu’elles envoient. Les résultats des calculs Diffie-Hellman sont
utilisés comme entrée dans la fonction de dérivation des clés, de telle sorte que

les clés ultérieures ne peuvent pas être calculées à partir des clés antérieures.
Ces propriétés offrent une certaine protection aux messages chiffrés en cas de

compromission des clés d’une partie. Le terme chaine KDF est un concept
de base dans l’algorithme Double Ratchet. Il est utilisé quand une partie de

la sortie KDF est utilisée comme clé de sortie et une autre est utilisée pour
remplacer la clé KDF, qui peut ensuite être utilisée comme entrée dans KDF.

Un aperçu plus clair est donné dans la Figure L’algorithme Double Ratchet
est composé de deux ratchets (qui peut se lire ici comme engrenage) à savoir

le ratchet Diffie-Hellman et le ratchet à clé symétrique. Dans une session

Double Ratchet entre Alice et Bob, chaque partie stocke une clé KDF de

trois chaînes : une chaîne racine, une chaîne émettrice et une chaîne réceptrice
(la chaîne d’envoi d’Alice correspond à la chaîne réceptrice de Bob, et vice

versa). Pendant qu’Alice et Bob échangent des messages, ils échangent aussi
de nouvelles clés publiques Diffie-Hellman, et les secrets de sortie de Diffie-

44
Hellman deviennent les entrées de la chaîne racine. Les clés de sortie de la

chaîne racine deviennent de nouvelles clés KDF pour les chaînes émettrices
et réceptrices. C’est ce qu’on appelle le ratchet Diffie-Hellman. Les chaînes

d’envoi et de réception avancent en fonction de chaque message envoyé et

reçu. Leurs clés de sortie sont utilisées pour chiffrer et déchiffrer les messages.

C’est ce qu’on appelle le ratchet à clé symétrique. Dans ce qui suit nous
présenterons en détaille les deux ratchets

2.4

Figure 2.4 – Une chaine KDF

Le ratchet à clé symétrique

La clé de message est utilisée pour chiffrer les messages envoyés ou reçus.
Les clés de message sont des clés de sortie des chaînes KDF. Les clés KDF

45
pour ces chaînes seront appelées clés de chaîne. Les entrées KDF pour les

chaînes émettrices et réceptrices sont considérées comme des constantes, qui

assurent la break-in recovery, c’est-à-dire impossible de devine les futures

clés KDF même si la clé courante est connue. L’objectif de ces chaines KDF
est d’assurer que chaque message soit chiffré avec une clé unique qui peut

être supprimée après chiffrement ou déchiffrement. Car la dérivation de la

nouvelle clé de chaîne et de la clé de message à partir de l’ancienne clé de

chaîne est simplement une étape le ratchet à clé symétrique. Ci-dessous une
illustration de ce principe à travers la Figure 2.5.

Figure 2.5 – Ratchet à clé symetrique

46
Le ratchet Diffie-Hellman

Si les clés de chaine d’envoie et de réception sont compromises, l’attaquant

peut calculer toutes les futures clés de message et déchiffrer tous les futurs

messages. Pour éviter cela, le Double Ratchet combine le ratchet à clé symé-
trique avec un ratchet DH qui met à jour les clés de chaîne en fonction des

sorties Diffie-Hellman. Pour cela, chaque partie génère une paire de clés DH
(une clé publique Diffie-Hellman et une clé privée) qui devient leur paire de

clés du ratchet actuelle. La clé publique de l’expéditeur est mise dans l’en-
tête de son message. Lorsqu’une nouvelle clé publique du ratchet est reçue

de la partie distante, une étape du ratchet DH est effectuée en remplaçant la

paire de clés du ratchet actuelle de la partie locale par une nouvelle paire de

clés Diffie-Hellman. En supposant qu’Alice vient de recevoir la clé publique

du ratchet actuel de Bob et que Bob quant à lui ne connait pas encore la clé

publique d’Alice. Alice effectue donc un calcul DH entre sa clé privée de son
ratchet et la clé publique du ratchet de Bob. Le scénario est représenté par

la Figure 2.6

Figure 2.6 – Initiation du ratchet Diffie-Hellman

47
 La clé publique d’Alice est annoncée à Bob par le premier message d’Alice.

Maintenant Bob exécute une étape du ratchet DH en calculant une sortie

DH qui sera la même que la sortie DH calculer par Alice. Pour une nouvelle

étape du ratchet DH, Bob génère une nouvelle paire de clé qui remplacera
son ancienne paire de clé, puis calcule une nouvelle sortie DH et envoie à

Alice sa nouvelle clé publique. Alice à son tour exécute une étape du ratchet
DH et ainsi de suite comme le montre la Figure 2.7.

Figure 2.7 – Séquence de ratchet DH entre Alice et Bob

48
Combinaison du ratchet à clé symetrique et Diffie-Hellman

Dans la combinaison de deux ratchets, les sorties DH générées dans les

différentes étapes du ratchet DH sont utilisées comme entrée KDF (c’est-à-

dire les constantes de la figure 2.5) pour obtenir des clés de chaine d’envoie
et de réception. La clé chaine d’envoi d’Alice corresponde à la clé chaine de

réception de Bob.
C’est cette combinaison du ratchet DH avec le ratchet à clé symétrique qu’on

définit par Double Ratchet. Des qu’Alice reçoit une nouvelle clé publique de
Bob, elle exécute une étape du ratchet DH pour dériver la clé de chaine

et une clé de chaine d’envoie ou une clé de chaine de réception. Ensuite

elle appliquera une étape du ratchet à clé symétrique sur la clé de chaine

émettrice ou sur la clé de chaine réceptrice. Avec cette approche Alice peut
envoyer à Bob plusieurs messages avec sa paire de clé (publique et privée).

Par contre chaque message à une seule et unique clé de message et chaque clé
de message est utilisée au plus pour chiffrer ou déchiffrer un seul message. La

Figure 2.9 montre un diagramme simplifié de l’algorithme à Double Ratchet.

2.4 Les avantages du protocole Signal

Comme avantage principale le protocole Signal est open source. On peut

trouver son code source à l’adresse suivant [19]. Par rapport à off-the-record
protocole, le protocole Signal permet de faire des communications synchrones

et garantie aussi des communications asynchrones. Une autre des avantages

introduite par Signal (dans les communications mobiles) est que tous les

échanges se font désormais par internet, à travers des serveurs Open Whis-
per Systems et de Google ; et non à travers le réseau GSM de l’opérateur

49
 Figure 2.8 – dérivation clé chaine d’envoi et de réception

de téléphone. Donc cela démunie les violations de la vie privée par analyse

des métadonnées. L’une des forces de ce protocole est qu’il est multiplate-
forme (Android, iOS) et il existe des librairies dans plusieurs langage de

programmation comme (java, c, JavaScript). En plus le protocole signal uti-

lise les primitives cryptographiques de dernière génération comme le X3DH,

le HDKF, le XEdDSA sur les courbes elliptiques curve25519, et le Double

Ratchet etc.

50
2.5 Les points faibles du protocole Signal

Malgré les différentes propriétés et fonctionnalités cryptographiques qu’offre

le protocole Signal, il souffre de quelques faiblesses. L’un de ces points faible

est la solution qu’Open Whisper Systems a apportée pour permettre les com-

munications asynchrones. A savoir les serveurs TS de Signal et les Serveurs

GCM de Google. La raison est qu’il y’a possibilité d’analyser des métadon-

nées sur ces serveurs. Sans oublier qu’aucune communication n’est possible
avec Signal sans passer par ces serveurs. Donc une dépendance totale des

serveurs de Google et d’Open Whisper Systems. Par conséquent une limita-

tion de l’accès à ces serveurs dans une zone géographique limitera l’usage des

applications utilisant ce protocole dans cette zone.

51
Figure 2.9 – diagramme simplifié de l’algorithme à Double Ratchet

52
Chapitre 3

Comparaison entre Off-The-Record

Messaging et Signal

On arriver en fin à l’épine dorsale de ce mémoire qui consiste à faire une

comparaison entre nos deux protocoles étudiés précédemment. Il faut recon-

naitre que même si les deux protocoles ont les mêmes objectifs à savoir de

fournir le chiffrement de bout en bout ; ils diffèrent dans leur fonctionnement

malgré que l’un soit à l’origine une dérivée de l’autre [11]. Si la philosophie

d’Off-The-Record est de faire une communication client-client sans passer par

un intermédiaire, le protocole Signal quant à lui passe par un serveur pour

relayer les messages. Cela fait d’OTR un protocole purement synchrone, par
contre son descendent Signal fonctionne en mode asynchrone (et synchrone).

D’autre part, le protocole OTR n’est toujours pas adapter pour les commu-
nications sur mobile contrairement à signal. On trouver l’usage du protocole

Signal dans les environnements mobiles comme PC par contre OTR n’est
disponible que pour les environnements PC. Dans tous les environnements,

comparés aux autres protocoles de sécurisation de messageries, OTR et Si-

gnal restent des meilleurs choix pour une sécurisation de communications. En

termes de complexité le protocole signal est moins complexe que le protocole

53
OTR. La raison est que le protocole Signal utilise des primitifs cryptogra-

phiques utilisant des courbe elliptique or OTR utilise ceux utilisant des corps
fini de nombre premier. Le tableau 1 donne un aperçu comparatif des deux

protocoles.

Off-the-record
Signal
Messasing

Chiffrement bout en bout Oui Oui

Synchrone,
Mode de Fonctionnement Synchrone
Asynchrone

Multiplateforme Oui Oui

Environnement d’exécution PC PC, Mobile

Serveur intermédiaire Non Oui

Methode d’authentification SMP X3DH

Méthode d’échange
SIGMA ORKE
de clé secrète

Signal,

WahtsApp,
Utilisation dans Pidgin, Gaim, Facebook,

les applications Adium, Cryptocat Messenger,

Google Allo

(mode Incognito)

Conversation de groupe Oui oui

Open source Oui Oui

Tableau 1 :Aperçu comparatif des deux protocoles

54
Chapitre 4

Conclusion et Perspectives.

4.1 Conclusion

Dans ce document nous avons présenté deux protocoles de chiffrement de

bout en bout. L’idée de base du chiffrement de bout en bout est d’avoir le

même niveau de sécurité dans une conversation en ligne qu’une conversation

privée entre deux personnes se déroulant dans une pièce privée. Ce qui nous a

motivés à étudier le mode de fonctionnement et la sécurité de deux protocoles

de ce type : le protocole OTR et le protocole Signal. Concernant le mode de

fonctionnement, il en sort que les deux protocoles ont une philosophie de

fonctionnement diffèrent. OTR fonctionne uniquement en mode synchrone

mais Signal garantie aussi le mode asynchrone. Côte performance, d’une part
la transformation du triple ratchet d’OTR en Double Ratchet dans Signal

rend Signal moins gourmand en calcule qu’OTR dans les différentes phases
d’authentification. Et d’autre part le protocole Signal utilise des nouvelles

primitives cryptographiques plus récentes que le protocole OTR. Cela est dû

au fait que les deux protocoles n’ont pas été construite au même moment.

Une conséquence est que le protocole Signal permet d’avoir des temps d’exé-
cution plus intéressants qu’OTR, un usage rependu dans des applications

55
mobiles. Cependant l’utilisation des anciennes primitives cryptographiques

par OTR n’est pas tout de même un obstacle au niveau de la sécurité. Mal-
gré ces caractéristiques attrayantes de Signal certain expert de la sécurité ne

l’accorde pas toute leur estime. La raison est l’utilisation d’un tiers par le
protocole à savoir les serveurs d’Open Whisper Systems et ceux de Google.

Google qui est connu pour être l’un des partenaires de grandes Agences de
renseignement [24]. Sur ce point le protocole OTR garde un avantage par

rapport à Signal car avec son mode de fonctionnement synchrone, les deux
interlocuteurs doivent être en ligne au même moment pour commencer une

conversation privée (sans l’aide d’un serveur tiers). Nos recherches nous ont
montré que le protocole Signal est de nos jours beaucoup plus utiliser que

OTR cela est dû au fait que beaucoup de systèmes de messagerie instantanée

intègrent le protocole Signal hors le protocole OTR n’est disponible que sous

forme de plugin pour certaines messageries. Toutefois, il est à signaler que

l’étude de ces deux protocoles n’est pas complète dans ce document. Car nous

n’avons pas pu faire une analyse approfondie des primitives cryptographiques

utilisées dans les phases d’authentification et de chiffrement. Cela nécessite

une connaissance avancé de l’Algèbre (Factorisation de nombre premiers et

la théorie des courbes elliptiques). Le temps aussi ne nous a pas permis d’im-

plémenter un de ces protocoles.

4.2 Perspectives

Comme perspective une analyse approfondie des primitives cryptogra-

phique nous aurait permis de discuter des choix de ces fonctions. Une autre

perspective serait d’implémenter le protocole OTR en utilisant les courbes

56
elliptique et de comparer les performances avec le protocole Signal. Etant

donné que les deux protocoles sont Open Source, il aurait été intéressant
dans cet étude de faire une audite des codes sources des deux protocoles.

57
Bibliographie

[1] Atkins, D., Zimmermann, P., et Stallings, W. (1996). Formats d’échange

de messages PGP.

[2] Alexander, C., et Goldberg, I. (2007, octobre). Amélioration de l’authen-

tification des utilisateurs dans la messagerie hors-enregistrement. Dans les

actes de l’atelier ACM 2007 sur la vie privée dans la société électronique

(pp. 41-47). ACM.

[3] https ://otr.cypherpunks.ca/Protocol-v2-3.1.0.html, visité le 3 juillet

2017

[4] Ramsdell, B., & Turner, S. (2010). Spécification de message de version

3.2 des extensions de courrier électronique sécurisées / multifonctions (S

/ MIME) (n RFC 5751).

[5] Riikonen, P. (2002). Secure Internet Live Conferencing (SILC) . Spécifi-

cation du protocole, Internet-Draft (février 2004), http : // www. silcnet.

org / docs / draft-riikonen-silc-spec-08. SMS.

[6] Rivest, R. L., Shamir, A., & Adleman, L. (1978). A method for obtaining

digital signatures and public-key cryptosystems. Communications of the

ACM, 21(2), 120-126.

[7] National Institute of Standards and Technology. Digital signature stan-

dard (DSS). Federal Information Processing Standards Publication 186-2,

58
 October 2001,

[8] Di Raimondo, M., Gennaro, R., & Krawczyk, H. (2005, November). Secure

off-the-record messaging. In Proceedings of the 2005 ACM Workshop on

Privacy in the Electronic Society(pp. 81-89). ACM.

[9] Krawczyk, H. (2003, August). SIGMA : The ‘SIGn-and-MAc’approach

to authenticated Diffie-Hellman and its use in the IKE protocols. In An-

nual International Cryptology Conference(pp. 400-425). Springer, Berlin,

Heidelberg.

[10] https ://otr.cypherpunks.ca/Protocol-v3-4.1.1.html, visité le 20 juillet

2017

[11] https ://signal.org/blog/advanced-ratcheting/, Moxie Marlinspike , 26

novembre 2013, visité le 30 août 2017

[12] Frosch, T., Mainka, C., Bader, C., Bergsma, F., Schwenk, J., & Holz,

T. (2016, March). How secure is TextSecure ?. In Security and Privacy

(EuroS&P), 2016 IEEE European Symposium on(pp. 457-472). IEEE.

[13] Bernstein, D. J. (2006, April). Curve25519 : new Diffie-Hellman speed

records. In International Workshop on Public Key Cryptography (pp.

207-228). Springer, Berlin, Heidelberg.

[14] Standard, N. F. (2001). Announcing the advanced encryption standard

(AES). Federal Information Processing Standards Publication, 197, 1-51.

[15] Krawczyk, H., Canetti, R., & Bellare, M. (1997). HMAC : Keyed-
hashing for message authenticationKrawczyk, H., Canetti, R., & Bellare,

M. (1997). HMAC : Keyed-hashing for message authentication

[16] Eastlake 3rd, D., & Hansen, T. (2006). US secure hash algorithms (SHA
and HMAC-SHA) (No. RFC 4634).

59
[17] Krawczyk, H. (2010, August). Cryptographic Extraction and Key Deri-

vation : The HKDF Scheme. In CRYPTO (Vol. 6223, pp. 631-648).

[18] Diffie, W., & Hellman, M. (1976). New directions in cryptography. IEEE
transactions on Information Theory, 22(6), 644-654.

[19] https ://github.com/signalapp

[20] https ://github.com/off-the-record/libotr, visité le 20 septembre 2017

[21] https ://www.miscmag.com/chiffrement-de-messagerie-quasi-

instantanee-a-quel-protocole-se-vouer-partie-12/, visité le 3 octobre

2017

[22] T. Perrin et M. Marlinspike, «Le protocole de l’accord-clé X3DH», 2016.

https ://whispersystems.org/docs/specifications/x3dh/ , visité le 16 oc-

tobre 2017

[23] Arnt, S., Bernard, N., Foukrach, D., Ghammam, L., Eddine, A. J.,
Samoyeau, V., & Tran, C. (2014). Semaine d’Etude Maths-Entreprises

8 : Caractérisation de courbes elliptiques selon leurs capacités cryptogra-

phiques (Doctoral dissertation, MAPMO, Université d’Orléans).

[24] https ://fr.wikipedia.org/wiki/Edward_Snowden, vu le 12 novembre

2017

[25] https ://signal.org/blog/just-signal/, visité le 5 novembre 2017

[26] https ://fr.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_

Code

60
Chapitre 5

Annexe

Définition des termes

Diffie-Hellman

Est une méthode par laquelle deux personnes nommées conventionnelle-

ment Alice et Bob peuvent se mettre d’accord sur un secret K (qu’ils peuvent
utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troi-

sième personne appelée Ève puisse découvrir le secret K

Etape 1 :

Alice choisit un nombre a ∈ ZP secret et calcule A = g a modp, Elle envoie A

à Bob.

Symétriquement, Bob choisit un nombre b ∈ Zp secret et calcule B =

g b modp, Il envoie B à Alice.

Etape 2 :
Alice calcule seule K = B a modp.

Symétriquement, Bob calcule de son côté K = Ab modp.

A la fin, Alice et Bob partagent la même clef secrète K = g a.b modp.

61
Pretty Good Privacy(PGP)

Est un logiciel de chiffrement cryptographique, développé et diffusé aux

États-Unis par Philip Zimmermann en 1991. Il garantit la confidentialité et

l’authentification lors d’une communication. PGP est un système de chif-

frement hybride, impliquant notamment une combinaison des chiffrements

symétrique et asymétrique.
Chiffrement

— Alice écrit un message, et demande à PGP de le chiffrer.

— PGP crée alors une clé aléatoire à usage unique, et s’en sert pour chiffrer

le message en suivant un algorithme symétrique

— PGP chiffre ensuite cette clé aléatoire, en utilisant un algorithme asy-

métrique, grâce à la clé publique de Bob.

— Le message est enfin transmis chiffré, accompagné de la clé servant à

le déchiffrer, la clé est-elle même chiffrée !

Déchiffrement

— Bob déchiffre la clé de chiffrement accompagnant le message, grâce à

sa clé privée ;

— Bob déchiffre le message, grâce à la clé fraîchement déchiffrée.

Secure Internet Live Conferencing (SILC)

SILC est un protocole moderne de conférence et de chat conçu avec une

haute sécurité en fournissant des caractéristique comme :

— Transport entièrement chiffré et authentifié

— Messages privés chiffrés et authentifiés de bout en bout

— Messages de canal et de groupe chiffrés et authentifiés

62
 — Conférence vidéo et audio sécurisée, messages image et son

— Échange de clés Diffie-Hellman mutuellement authentifié et Perfect For-

ward Secrecy

Le protocole SIGMA (Sign-and-Mac)

Le protocole SIGMA assure une parfaite confidentialité via un échange

Diffie-Hellman authentifié avec des signatures numériques, et sont spécifi-

quement conçus pour assurer l’échange de clés cryptographiques sécurisées.

Les exigences de base de la conception de SIGMA sont les suivantes :

a) Un protocole d’échange de clés sécurisé basé sur l’échange Diffie-Hellman ;

b) Utiliser les signatures numériques comme moyen d’authentification par clé

publique du protocole ;
c) Offrir la possibilité de protéger les identités des interlocuteurs du protocole

contre un attaquant sur le réseau

Le protocole de l’échange de clé X3DH

Le protocole "X3DH" (ou "Extended Triple Diffie-Hellman") établit une

clé secrète partagée entre deux parties qui s’authentifient mutuellement en

fonction de leurs clés publiques. X3DH est conçu pour les conversations asyn-
chrones où un utilisateur ("Bob") est hors ligne mais a publié des informa-

tions sur un serveur. Un autre utilisateur ("Alice") veut utiliser cette infor-

mation pour envoyer des données chiffrées à Bob, et aussi établir une clé
secrète partagée pour des futures communications. Qui se résume en trois

phases :
1. Bob publie sa clé d’identité et ses pré-clés sur un serveur.

63
2. Alice récupère une "près-clés" du serveur et l’utilise pour envoyer un mes-

sage initial à Bob.

3. Bob reçoit et traite le message initial d’Alice.

Keyed-Hash Message Authentication Code (HMAC)

est un type de code d’authentification de message (CAM), ou MAC en

anglais (Message Authentication Code), calculé en utilisant une fonction de

hachage cryptographique en combinaison avec une clé secrète K

HM ACK (m) = h((K ⊕ opad)||h((K ⊕ ipad)||m) (5.1)

— h : une fonction de hachage itérative,

— K : la clé secrète complétée avec des zéros pour qu’elle atteigne la taille
de bloc de la fonction h

— m : le message à authentifier,
— "||" désigne une concaténation et ⊕ un « ou » exclusif,

— ipad et opad, chacune de la taille d’un bloc, sont définies par : ipad =
0x363636...3636 et opad = 0x5c5c5c...5c5c. Donc, si la taille de bloc de

la fonction de hachage est 512 bits, ipad et opad sont 64 répétitions

d’octets, respectivement, 0x36 et 0x5c.

64