Support Cours SERE.1

République Algérienne Démocratique et Populaire
Ministére de l'Enseignement Supérieur et de la Recherche Scientique

Université Abdelhamid Mehri - Constantine 2
Faculté des Nouvelles Technologies de l'Information & de la

Communication
Département d'Informatique Fondamentale et ses Applications
Support de cours
Sécurité des réseaux
Destiné aux étudiants de 1re Année Master

Option : Réseaux et Systèmes Distribués
présenté par
Dr Radja Boukharrou
Maître de conférence B
20192020
Table des matières
1 Introduction à la sécurité des réseaux 10

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Sécurité informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 La sécurité informatique en chires . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Pourquoi la sécurité des réseaux est importante ? . . . . . . . . . . . . . . . . . 12
1.2.3 Rôle des entreprises de sécurité informatique . . . . . . . . . . . . . . . . . . . 12
1.3 Applications de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Sécurité des équipements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Sécurité des applications logicielles . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.3 Sécurité des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.4 Sécurité des réseaux de télécommunication . . . . . . . . . . . . . . . . . . . . . 13
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Menaces et mesures de protection 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Dénitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Vulnérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Menace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Sensibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 Attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.6 Intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Attaques d'un réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Buts des attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Classications des attaques réseaux . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 Etapes d'une attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Types d'attaques d'un réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Attaques de reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Attaques d'accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Attaques par déni de service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4 Attaques de programmes malveillants (malware) . . . . . . . . . . . . . . . . . 20
2.5 Services de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Condentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.2 Authenticité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.3 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.4 Non-répudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.5 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Mécanismes de défense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1 Audit de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.2 Journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.4 Systèmes de détection d'intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1
TABLE DES MATIÈRES 2
2.6.5 Pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.6 Contrôle d'accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.7 Authentication réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6.8 Bourrage de trac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.9 Chirement des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.10 Signature numérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.11 Protection physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Analyse des risques et politique de sécurité 26

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Politiques de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Eléments d'une politique de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Pare-feu (Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Zones démilitarisées (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3 Système de détection d'intrusion (IDS) . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.4 Réseaux privés virtuels (VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Cryptographie appliquées 37
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Formalisation des mécanismes de chirement . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Algorithmes de substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Algorithmes de chirement symétrique . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Algorithmes de chirement asymétrique . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Problèmes liés au chirement asymétrique . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.1 Problème de la longueur des clés . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.2 Problème de la performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.3 Problème de l'échange de clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6.4 Problème de l'authentication de l'expéditeur . . . . . . . . . . . . . . . . . . . 42
4.6.5 Problème du Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Certicats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7.1 Dénition d'un certicat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7.2 Infrastructure à clé publique (PKI) . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Certicats X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8.1 Structure d'un certicat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8.2 Cycle de vie d'un certicat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.8.3 Signature numérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.8.4 Processus de certication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.9 Chaine de certicats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Sécurité au niveau réseau : Protocole IPsec 49

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Protocole IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Applications du protocole IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.3 Composants de IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Modes de fonctionnement de IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.1 Mode "Transport" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.2 Mode "Tunnel" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Protocoles de sécurité de IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4.1 Protocole AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.2 Protocole ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Fonctionnement de l'architecture globale de IPsec . . . . . . . . . . . . . . . . . . . . . 56
5.5.1 Traitement des paquets sortants . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5.2 Traitement des paquets entrants . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.6 Associations de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.6.1 Paramètres d'associations de sécurité . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6.2 Bases de données SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6.3 Bases de données SPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.7 Gestion et distribution des clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.7.1 Protocole IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.7.2 Protocole ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Chirement de bout-en-bout : Protocole SSL/TLS 63

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Protocole SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.2 Architecture du protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.3 Avantages et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3 Implémentation de SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1 Protocole HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.2 Protocole 3D-Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 Protocole SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Protocoles FTPS versus SFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7 Messagerie sécurisée 78
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2 Messagerie électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3 Acheminement des emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3.1 Protocole SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3.2 Standard MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4 Accès aux emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.4.1 Protocole POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.4.2 Protocole IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.4.3 Comparaison entre POP et IMAP . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.5 Vulnérabilités et menaces dans la messagerie électronique . . . . . . . . . . . . . . . . 89
7.5.1 Absence de services de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.5.2 Relayage SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.5.3 Transport de contenus exécutables . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.5.4 Excès de privilèges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.5.5 Failles des logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.5.6 Dénis de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.5.7 Atteinte à la vie privée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6 Sécurisation du transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.6.1 Chirement SSL/TLS explicite . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.6.2 Chirement SSL/TLS implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6.3 Limites de la sécurisation du transport . . . . . . . . . . . . . . . . . . . . . . . 94
7.7 Sécurisation de client à client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.7.1 Standard S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.7.2 Protocole PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table des gures
1.1 Interconnexion des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Vulnérabilité et menaces des systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Buts des attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Classication des attaques réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Principaux services de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Fonction de ltrage d'un pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Une DMZ à l'entrée d'un pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Cas d'architectures DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Architectures des N-IDS et H-IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Classes de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Principe de la transmission sécurisée des messages en se basant sur le chirement . . . 38

4.2 Signature numérique des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Vérication de la signature numérique des messages . . . . . . . . . . . . . . . . . . . . 43
4.4 Processus de certication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Cycle de vie d'un certicat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Fonctionnement du mode "Transport" du protocole IPsec . . . . . . . . . . . . . . . . 52

5.2 Fonctionnement du mode "Tunnel" du protocole IPsec . . . . . . . . . . . . . . . . . . 52
5.3 Structure d'un paquet IP sécurisé par le protoocle AH . . . . . . . . . . . . . . . . . . 53
5.4 Structure d'un entête AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5 Structure d'un paquet IP sécurisé par le protoocle ESP . . . . . . . . . . . . . . . . . . 54
5.6 Structure d'un entête ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 Structure d'un enqueue ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.8 Structure d'un enqueue ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.9 Traitement des paquets IPsec sortants . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Traitement des paquets IPsec entrants . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Phases du protocole IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Phases du protocole IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.13 Structure d'un entête ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.14 Structure d'un payload ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 Architecture du protocole SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2 Structure d'un message "Record" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 Structure d'un message "Handshake" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Processus de Handshake SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5 Structure d'un message "Change Cipher Spec" . . . . . . . . . . . . . . . . . . . . . . 71
6.6 Structure d'un message "Alert" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7 Construction d'un message "Application Data" . . . . . . . . . . . . . . . . . . . . . . 71
6.8 Structure d'un message "Application Data" . . . . . . . . . . . . . . . . . . . . . . . . 73
5
TABLE DES FIGURES 6
7.1 Principe de l'acheminement des emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2 Format d'un message PGP signé et chiré . . . . . . . . . . . . . . . . . . . . . . . . . 99
Liste des tableaux
3.1 Conguration du ltrage d'un pare-feu réseau de type Stateless . . . . . . . . . . . . . 29
4.1 Principaux algorithmes de chirement symétrique . . . . . . . . . . . . . . . . . . . . . 39
5.1 Exemple d'une SA IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Versions du protocole SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2 Types de message Handshake SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3 Types d'alertes Warning et Fatal (F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.1 Commandes du protocole SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2 Commandes de l'extension ESMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3 Codes de statut des commandes SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.4 Commandes du protocole POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.5 Commandes du protocole IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.6 Types de message S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7
Préface
Description du module
L'objectif du module "Sécurité des réseaux" est de comprendre les menaces présentes dans les
réseaux informatiques et savoir comment protéger un réseau par des moyens techniques et organisa-
tionnels. En outre, ce module permet aux étudiants d'appréhender les stratégies et les technologies de
sécurisation des VPN comme les protocoles IPsec, SSL/TLS, et PGP.
Informations sur le module

Intitulé : Sécurité des Réseaux
Code : SERE
Informations :
Spécialité : Réseaux et Systèmes Distribués
Niveau : Master 1
Semestre : S2
Unité d'enseignement : UEM2
Code d'unité : SESP
Crédits : 4
Prérequis : Concepts de base de la sécurité informatique, Notions de base du modèle TCP/IP
Durée : 12 semaines
Volume horaire hebdomadaire

Cours : 1h30
Travaux pratiques : 1h30
Travaux dirigés : /
Travail personnel : 1h30
Programme du module
En se basant sur la taxonomie des objectifs éducationnels de "Bloom", voici les objectifs de chacun
des chapitres de ce module :
Chapitre 1 : Introduction à la sécurité des réseaux
Être sensible à la problématique de la sécurité
Comprendre les concepts de base de la sécurité
Chapitre 2 : Menaces et mesures de protection
Exposer les risques et les menaces de sécurité potentielles
Connaître les types d'attaques d'un réseau
Connaître les types de services de sécurités
Apprendre les mécanismes de défense contre les menaces possibles
Chapitre 3 : Analyse de risques et politiques de sécurité
Apprendre à gérer la sécurité d'un système
8
LISTE DES TABLEAUX 9
Connaître les politiques de sécurité possibles

Assimiler les architectures de sécurité existantes
Chapitre 4 : Cryptographie appliquée
Comprendre le principe du chirement
Connaître les types de chirement
Assimiler le fonctionnement des certicats
Comprendre la notion de chaine de certication
Chapitre 5 : Sécurité au niveau réseau et protocole IPsec
Assimiler l'intérêt du protocole IPsec
Comprendre les 2 modes de fonctionnement de IPsec
Utiliser les 2 protocoles de sécurité de IPsec
Assimiler le fonctionnement de l'architecture globale de IPsec
Comprendre le principe de l'échange de clés
Chapitre 6 : Chirement de bout-en-bout et protocole SSL/TLS
Assimiler le fonctionnement du protocole SSL/TLS
Connaître les protocoles applicatifs utilisant SSL/TLS
Comprendre les diérence entre les protocoles SSL/TLS et SSH
Chirer et déchiré des chiers
Tester des serveurs SSL/TLS
Chapitre 7 : Messageries sécurisées
Assimiler le fonctionnement de l'acheminement des emails
Envoyer et récupérer des emails à l'aide des protocoles SMTP, POP et IMAP
Connaître les vulnérabilités dans la messagerie électronique Sécuriser le transport des emails
de bout en bout
Assimiler le principe du chirement implicite et explicite
Congurer un client de messagerie Sécuriser les emails de client à client
Congurer la sécurité des emails dans un client de messagerie
Chapitre 1
Introduction à la sécurité des réseaux

1.1 Introduction
Sécurité des réseaux 2018-2019 – Semestre 2 Université Constantine 2
Aujourd'hui la communication et la technologie sont les maîtres mots de notre société, où les
réseaux informatiques ne cessent de grandir et de se développer. Cette évolution est fortement liée aux
Aujourd’hui la communication et la technologie sont les maîtres mots de notre société, où les réseaux
techniques et aux supports de communication utilisés dans les réseaux.
informatiques ne cessent de grandir et de se développer. Cette évolution est fortement liée aux techniques et
Comme il est illustré dans la gure 1.1, les interconnexions de réseaux sont innombrables et pra-
aux supports de communication utilisés dans les réseaux.
tiquement tous les réseaux se trouvent aujourd'hui imbriqués les uns dans les autres [16], constituant
Les fédérateur
le réseau interconnexions
desde réseaux sont
réseaux de lainnombrables
planète et pratiquement
Internet tousspécialises
. Les les réseaux se trouvent aujourd'hui
prévoient que les réseaux
imbriqués
mobiles les uns
et sans ls dans les autresdevenir
pourraient [1], constituant le réseau dans
prédominants fédérateur des réseaux
le transport dedelalamultimédia,
planète, « Internet ». aux
laissant
Les spécialises prévoient que les réseaux mobiles et sans fils pourraient devenir prédominants dans le transport
réseaux xes le transport des données à hauts débits.
de la multimédia, laissant aux réseaux fixes le transport des données à hauts débits.
Réseau d’entreprise
Communication
e-Commerce
L'intégration des réseaux locaux dans le système d'information d’une entreprise a conduit au concept de réseau
Figure
d'entreprise, dans lequel l'utilisateur peut1.1 Interconnexion
accéder des réseaux
à toutes les ressources de l’entreprise. Néanmoins, la
connexion du réseau d’entreprise à Internet rend l'ensemble de ses ordinateurs vulnérables aux menaces et aux
L'intégration des réseaux locaux dans le système d'information d'une entreprise a conduit au
intrusions. Elle oblige celle-ci à adopter des procédures de sécurité contraignantes pour tous les utilisateur,
concept de réseau lorsque
particulièrement d'entreprise, dans lequel
des ordinateurs l'utilisateur
externes, peutleaccéder
désirent utiliser réseau deàl'entreprise
toutes lesvia
ressources
Internet. de l'entre-
prise. Néanmoins, la connexion du réseau d'entreprise à Internet rend l'ensemble de ses ordinateurs
En effet, toutes les entreprises craignent des attaques informatiques, sans toujours savoir quelles formes
vulnérables aux menaces et aux intrusions. Elle oblige celle-ci à adopter des procédures de sécurité
celles-ci peuvent prendre. Dans ce module, nous identifierons les menaces les plus courantes d’un réseau, et
contraignantes pour tous les utilisateur, particulièrement lorsque des ordinateurs externes, désirent
nous apprenons comment le protéger avec les techniques existantes.
utiliser le réseau de l'entreprise via Internet.
En eet, toutes les entreprises craignent des attaques informatiques, sans toujours savoir quelles
1. Sécurité informatique
formes celles-ci peuvent prendre. Dans ce module, nous identierons les menaces les plus courantes
Il est courant que les systèmes informatiques ne sont pas infaillibles. Régulièrement, des « espions1 » internes
d'un réseau, et nous apprenons comment le protéger avec les techniques existantes.
ou externes, pénètrent des systèmes informatiques afin de les détruire, ou la plupart du temps, pour dérober de
l’information sensible, dans un but lucratif ou politique.
Certaines failles des systèmes, appelées vulnérabilités, conduisent au vol de données confidentielles, ou
permettent la prise de contrôle à distance d’équipements réseau. Ainsi, une vulnérabilité non corrigée dans une
entreprise peut lui causer des pertes financières, ou même un retard technologique majeur dû au vol de données
à haute valeur concurrentielle. 10
Chaque jour de nouvelles vulnérabilités sont découvertes et publiées, concernant différents éléments,
équipements et logiciels des systèmes informatiques. L’objectif de la veille de vulnérabilité est de corriger les
CHAPITRE 1. INTRODUCTION À LA SÉCURITÉ DES RÉSEAUX 11
1.2 Sécurité informatique

Il est courant que les systèmes informatiques ne sont pas infaillibles. Régulièrement, des espions
1
internes ou externes, pénètrent des systèmes informatiques an de les détruire, ou la plupart du
temps, pour dérober de l'information sensible, dans un but lucratif ou politique.
Certaines failles des systèmes, appelées vulnérabilités, conduisent au vol de données condentielles,
ou permettent la prise de contrôle à distance d'équipements réseau. Ainsi, une vulnérabilité non corrigée
dans une entreprise peut lui causer des pertes nancières, ou même un retard technologique majeur dû
au vol de données à haute valeur concurrentielle.
Chaque jour de nouvelles vulnérabilités sont découvertes et publiées, concernant diérents éléments,
équipements et logiciels des systèmes informatiques. L'objectif de la veille de vulnérabilité est de
corriger les éléments vulnérables du système, en vériant la criticité des failles exploitables, et d'estimer
le risque de sécurité. La problématique étant de corriger ces vulnérabilités avant qu'elles ne puissent
être exploitées. Pour ce faire, diérentes méthodes, normes ou frameworks peuvent être appliqués, dans
le but de contrôler et améliorer la qualité du processus de protection du système d'information.
Dénitions :
La sécurité informatique est l'ensemble de moyens mis en ÷uvre pour éviter et/ou mini-
miser les défaillances naturelles dues à l'environnement ou au défaut du système d'infor-
mation et les attaques malveillantes intentionnelles dont les conséquences sont catastro-
phiques [7].
La sécurité d'un réseau est un niveau de garantie que les ordinateurs du réseau fonc-
tionnent de façon optimale et que les utilisateurs possèdent uniquement les droits qui
leurs ont été octroyés [53].
La cybersécurité est l'ensemble des outils, des politiques, des concepts et mécanismes de
sécurité, des méthodes de gestion des risques, et des technologies qui sont utilisés pour
protéger les systèmes informatiques matériels et logiciels des organisations (entreprises et
gouvernements) [29].
1.2.1 La sécurité informatique en chires

En 2012, le groupe Verizon a réalisé une autopsie de 855 incidents informatiques. Sachant que
92% de ces attaques étaient peu complexes, 79% d'entre elles étaient des cibles opportunistes. Enn,
97% des infractions réussies auraient pu être évitées si la victime avait déployé des processus de sécurité
plus adaptés.
En 2013, selon l'organisme OWASP
2 : 97% des applications web restent exposées à des vulnéra-
bilités connues, et les principaux risques sont identiques, notamment les injections SQL qui permettent
à un tiers malveillant de récupérer, voler, modier ou détruire des informations sensibles. .
En 2015, le Gartner Group estime que 80% des attaques réussies exploiteront des vulnérabilités
connues. En 2017, 300 000 ordinateurs dans 150 pays sont infectés par le logiciel malveillant WannaCry,
suite à l'exploitation d'une faille de Windows XP. Dans la même année, un malware destructeur, nommé
NotPetya, a envahi l'Europe, en causant des pertes qui dépassent 1,2 milliards de dollars aux entreprises
touchées.
Par ailleurs, en 2018, 5 millions d'emails internes et externes de l'entreprise suisse Deloitte sont
potentiellement compromis, y compris des échanges avec des centaines de très gros clients tels que la
FIFA et bien d'autres.
Ces attaques ne représentent qu'une inme partie des dégâts causés par la cybercriminalité. Donc,
il est de plus en plus nécessaire pour toute entreprise de se protéger ecacement en faisant appel à un
professionnel spécialiste en sécurité informatique, et particulièrement en sécurité des réseaux.
1. Espion : appelé aussi assaillant, pirate, hacker, et attaquant

2. OWASP : Open Web Application Security Project
Voici quelques chires concernant la cybersécurité dans le monde [58] :

3 minutes seulement sont nécessaires pour pirater un objet connecté (Caméras de surveillance,
imprimantes, thermostats intelligents, etc.),
En 2015, 1,1 million de victimes de fraude à la carte bancaire (ce chire a doublé en 5 ans),
65 vols de données par seconde, c-à-d. 5,6 millions de données personnelles (adresse mail, mot de
passe, numéro de carte bancaire, . . . ) sont piratées ou perdues chaque année, Un utilisateur sur
quatre est prêt à payer la rançon demandée par le pirate pour retrouver l'accès à son ordinateur
après une attaque de type ransomware ,
3
Il faut en moyenne 201 jours à une entreprise pour découvrir qu'elle a été victime d'une cybe-
rattaque,
Google a supprimé 1,7 milliard de publicités mensongères, illégales ou trompeuses en 2016 (2
fois plus qu'en 2015),
1,2 million d'attaques par phishing (faux sites Web, par exemple, gougle au lieu de google) ont
été enregistrées en 2016 (une hausse de 65 % par rapport à 2015),
Les particuliers sont 2 fois plus infectés que les professionnels, car les entreprises disposent de
moyens de défense plus élevés et plus sophistiqués (rewall, systèmes de sécurité. . . ) que les
simples individus.
Une entreprise subit 29 cyberattaques par an (c'est 2 fois plus qu'en 2015). Le ransomware est
le mode d'attaque favori des hackers,
Plus de 155 vulnérabilités sont déclarées chaque semaine. Le temps moyen entre la publication
de la vulnérabilité et de son exploitation est de 5,6 jours.
1.2.2 Pourquoi la sécurité des réseaux est importante ?

De nos jours, les réseaux informatiques ne cessent de grandir et de se développer, notamment à
cause de l'avènement de l'internet des objets où les objets du quotidien sont devenus connectés. Les
dégâts dus aux intrusions aux réseaux informatiques se sont diversiés, à savoir, le vol des données
condentielles, le vol d'informations, l'atteinte à la vie privée, le vol d'argents, la perte de conance
des clients, la pertes nancières, etc.
Ceci est dû à la croissance d'Internet, des attaques, des failles des technologies, des failles de
politiques de sécurité et changement de prol des pirates, etc. Aujourd'hui, les types de menaces
potentielles sont en évolution constante et deviennent de plus en plus complexes.
De ce fait, la montée du commerce mobile et des réseaux sans l requière des solutions de sécurité
intégrées plus transparentes et plus exibles, car la mise en ÷uvre des attaques demande de moins en
moins de connaissances techniques et d'expériences.
1.2.3 Rôle des entreprises de sécurité informatique

Beaucoup d'entreprises ou d'organisations conent la gestion de la sécurité de leur système in-
formatique à des prestataires externes plutôt que de recruter en interne. Ces entreprises prestataires,
généralement expertes en sécurité informatique, mènent de multiples actions pour leurs clients.
Une entreprise spécialisée en sécurité informatique ne peut jamais être sûr de la sûreté des systèmes
qu'elle gère, mais elle doit :
Améliorer la sécurité par rapport à ce qu'elle était avant,
Comparer et estimer l'état de sécurité du système,
S'assurer que toutes les précautions raisonnables ont été prises pour optimiser la protection des
données,
Garder la sécurité dynamique dans le temps et évaluer les processus mis en place pour entretenir
la sécurité à long terme,
Trouver le juste équilibre entre l'accès aux ressources que les réseaux actuels contiennent et la
protection contre le vol des données sensibles.
3. Un ransomware, appelé aussi rançongiciel, est un logiciel malveillant qui consiste à chirer des données personnelles
pour puis demander à leur propriétaire d'envoyer de l'argent en échange de la clé qui permettra de les déchirer.
L'intervention des entreprises de sécurité se fait généralement en 3 phases [8] :
1. Analyse et audit : il s'agit de mener une première opération d'analyse et d'audit du système,
an d'identier les risques ainsi que de suggérer une politique performante de sécurisation ;
2. Mise en ÷uvre du plan et des outils de sécurisation : l'entreprise établit le plan d'ac-
tions recommandé, en mettant en place diérents niveaux de prestations : Mise en place des
méthodes et des outils de sécurité (antivirus, pare-feu, . . . ), Accompagnement et formation des
collaborateurs, et gestion et résolution en temps réel des incidents de sécurité ;
3. Action continue en aval : le rôle de l'entreprise ne s'arrête pas à la 2ème phase, mais continue
d'eectuer des actions tout au long de la collaboration avec le client. Des actions diverses peuvent
être eectuées telles que : initier un reporting régulier et détaillé des failles éventuelles et faire
évoluer les méthodes de sauvegarde et de sécurisation.
1.3 Applications de la sécurité

An de pouvoir sécuriser un système, il est nécessaire d'identier les menaces potentielles, et donc
de connaître à quel endroit intervient l'attaque.
1.3.1 Sécurité des équipements

La sécurité physique est un aspect fondamental de tout type de sécurité pour garantir l'intégrité, la
condentialité et la disponibilité des informations. Les composants matériels constituant les systèmes
qui peuvent être vulnérables, sont les ordinateurs, les routeurs, les imprimantes, les médias de stockage,
les circuits d'alimentation, etc.
Au niveau matériel, pour éviter les intrusions, la mise en place de routeurs, de switchs manageables,
de pare-feu, de systèmes de ltrage et autres proxy peuvent être une solution au renforcement de la
sécurité informatique du parc matériel.
1.3.2 Sécurité des applications logicielles

An de garantir la protection du système d'information face aux diérentes menaces, le minimum
consiste à installer un antivirus et éventuellement un pare-feu logiciel, an de limiter les risques d'in-
fection du système d'exploitation de la machine.
1.3.3 Sécurité des données

Les données d'un système représentent la cible principale des attaques. Ces données proviennent
des données saisies, en cours de traitement, ou celles qui sont stockées. Les techniques de piratage qui
visent à recueillir des informations condentielles sont nombreuses. Il existe des bonnes pratiques an
de réduire le risque potentiel du vol des données comme l'utilisation d'un mot de passe diérent pour
chaque service et de crypter les données stockées.
1.3.4 Sécurité des réseaux de télécommunication

Comme les informations condentielles circulent dans les réseaux, la sécurité des communications
est devenue une priorité des utilisateurs et des entreprises. En eet, les réseaux orent un moyen
pour attaquer les systèmes et peuvent être eux aussi une cible d'attaque. Donc, il est nécessaire de
se protéger contre des intrusions malveillantes à travers les réseaux. Par ailleurs, une multitude de
virus se propagent à l'insu des utilisateurs dans les chiers téléchargés. Les virus sont susceptibles
de détruire des documents ou même de provoquer la perte totale des informations stockées dans les
machines. Parmi les solutions actuelles, est de mettre en place des mécanismes de contrôle d'accès et des
protocoles sécurisés qui apportent plusieurs services : l'authentication, la condentialité, l'intégrité,
ou la non-répudiation.
1.4 Conclusion
Le moyen le plus ecace pour gérer la sécurité d'un système informatique est de déterminer les
menaces et ensuite prendre les mesures adéquates.
Chapitre 2
Menaces et mesures de protection

2.1 Introduction
Ce chapitre consiste à exposer la dénition des concepts de sécurité ainsi que les diérents types
d'attaque d'un réseau.
2.2 Dénitions
2.2.1 Vulnérabilité
Une vulnérabilité, appelée parfois faille ou brèche, est une faiblesse dans un système informatique,
laissant à un assaillant l'opportunité de porter atteinte à l'intégrité de ce système en le rendant instable.
Analogiquement à une maison, cela revient à laisser une porte non-verrouillée. Du coup, cette porte
(faille) peut potentiellement être utilisée par des voleurs (hackers) pour accéder de façon illégitime à
la maison (au système) [36].
Les vulnérabilités résident souvent sur des programmes, car, tout ce qui est codé peut poten-
tiellement contenir des vulnérabilités : notamment les rmware, les hyperviseurs, les systèmes d'exploi-
tation, les librairies et les logiciels, etc. Sachant que les protocoles de communication sont implémentés
en des programmes, des vulnérabilités peuvent également y apparaître.
2.2.2 Menace
Une menace est une action potentielle susceptible de provoquer un dommage sur un système et
ayant un impact sur ses fonctionnalités, son intégrité ou sa disponibilité. De ce fait, une vulnérabilité
d'un système représente son niveau d'exposition face à une menace.
2.2.3 Risque
Un risque que peut provoquer une menace à un système est estimé en fonction de la sensibilité
et de la vulnérabilité de ce système. Il est donc important de mesurer le risque, non seulement en se
basant sur la probabilité ou sur la fréquence de son arrivée, mais aussi en mesurant son eet possible.
Donc, tout système (Actif ) présentant une vulnérabilité pourra être à tout moment exploitée par
un assaillant. Une attaque potentielle du système est vue comme une menace visant à nuire ce système.
2.2.4 Sensibilité
Dans un système informatique, plus une information est stratégique pour une entreprise, plus elle
a de la valeur, ce qui la rend sensible. De ce fait, si une information sensible est révélée au public,
cela nuirait à l'entreprise et à la vie privée des individus. Concrètement, la sensibilité de l'information
réside dans sa disponibilité, son intégrité et sa condentialité.
15
1.3. Risque
Un risque que peut provoquer une menace à un système est estimé en fonction de la sensibilité et de la
CHAPITRE 2. de
vulnérabilité MENACES
ce système. ET MESURES
Il est DE de
donc important PROTECTION
mesurer le risque, non seulement en se basant sur la 16
probabilité ou sur la fréquence de son arrivée, mais aussi en mesurant son effet possible.
vise
présente exploite
Actif Vulnérabilité Menace

(Valeur) (Probabilité)
Donc, tout système (Actif) présentant une vulnérabilité pourra être à tout moment exploitée par un assaillant.
Figure
Une attaque potentielle du système2.1
est vue
Vulnérabilité et menaces des systèmes
comme une menace visant à nuire ce système.
2.2.51.4. Attaque
Sensibilité
Dans un système informatique, plus une information est stratégique pour une entreprise, plus elle a de la valeur,
Une attaque
ce qui la rend est une action
sensible. représentant
De ce fait, le moyen
si une information d'exploiter
sensible une
est révélée vulnérabilité
au public, pour
cela nuirait compromettre
à l’entreprise
la sécurité d'un
et à la vie système.
privée Il peut
des individus. y avoir plusieurs
Concrètement, attaques
la sensibilité pour une réside
de l'information même vulnérabilité
dans mais
sa disponibilité, sontoutes
les vulnérabilités ne sont pas exploitables.
intégrité et sa confidentialité.
2.2.61.5. Intrusion
Attaque
Une attaque est une action representant le moyen d'exploiter une vulnérabilité pour compromettre la sécurité
Une Intrusion est un ensemble d'actions entrainant la compromission de la sécurité d'une entreprise,
d’un système. Il peut y avoir plusieurs attaques pour une même vulnérabilité mais toutes les vulnérabilités ne
par exemple, accéder sans autorisation aux données du système et/ou du réseau de l'entreprise, en
sont pas exploitables.
contournant les dispositifs de sécurité mis en place. Les raisons des intrusions sont diverses, le but
pourrait être la modication ou le vol d'informations condentielles, ou bien la destruction des données
du système.
Donc, l'objectif principal de la détection d'intrusion est de repérer les actions d'un attaquant qui
© Dr. R. Boukharrou Page 2 sur 8
tente de ou qui tire partie des vulnérabilités du système. Il est indispensable de dénir précisément ce
qui est une intrusion, c'est à dire une défaillance de sécurité.
2.3 Attaques d'un réseau

Une attaque réseau est dénie comme une intrusion dans une infrastructure de communication an
d'obtenir un accès non autorisé à des ressources ou d'exploiter des vulnérabilités existantes. elle est
généralement constituée de deux phases : une attaque passive qui analysera, dans un premier temps, le
trac réseau pour collecter des informations sensibles, puis comme deuxième phase, une attaque active,
qui consiste à nuire au réseau.
2.3.1 Buts des attaques

Généralement les attaques que peut subir un réseau, cible les informations sensibles an de nuire
à l'entreprise concernée. Comme il est décrit dans la gure 2.2, ils existent quatre objectifs potentiels
d'une attaque [25] :
L'interruption : vise la disponibilité des informations dans un réseau (Déni de service, . . . ),
L'interception : vise la condentialité des données circulant dans un réseau (capture de
contenu, analyse de trac, . . . ),
La modication : vise l'intégrité des informations en provoquant des incohérences dans le
système (modication, rejeu, ...),
La fabrication : vise l'authenticité des informations en usurpant l'identité d'un utilisateur ou
d'un service (mascarade, ...).
2.3.2 Classications des attaques réseaux

Les attaques peuvent être classées en deux grandes catégories, selon la phase de leur opération :
analyse de trafic, …),
La modification : vise l’intégrité des informations en provoquant des incohérences dans le système
(modification,
La modification : vise
rejeu, …),l’intégrité des informations en provoquant des incohérences dans le système
(modification,
La fabricationrejeu,
: vise…),
l’authenticité des informations en usurpant l’identité d’un utilisateur ou d’un
service
CHAPITRELa
2. fabrication
MENACES : vise
(mascarade, l’authenticité
…).
ET MESURES desDE
informations
PROTECTIONen usurpant l’identité d’un utilisateur ou d’un 17
service (mascarade, …).
Interruption Interception Modification Fabrication

Interruption Interception Modification Fabrication
Figure
2.2. Classifications des attaques réseaux
2.2 Buts des attaques
2.2. Classifications des attaques réseaux
Capture
Capture
Passives Analyse du trafic
Passives Analyse du trafic
Attaques Mascarade
Attaques Mascarade
Rejeu
Rejeu
Actives
Actives Modification de
Modification
message de
message
Déni de Service
Déni de Service
© Dr. R. Boukharrou
Figure 2.3 Classication des attaques réseaux Page 3 sur 8
Attaques passives : consistent à écouter et à surveiller les transmissions sur un canal, sans mo-
dier les données dans un réseau. En eet, l'attaquant peut intercepter et capturer une donnée
transmise, ou bien analyser le trac d'un réseau dans le but de rechercher des informations sen-
sibles pouvant être utilisées pour d'autres types d'attaques, tels que les mots de passe [55]. Les
attaques passives sont généralement indétectables, mais une prévention est possible en cryptant
la transmission entre les n÷uds du réseau,
Attaques actives : consistent à modier les messages transmis, à s'introduire dans des équi-
pements d'un réseau, ou à perturber le bon fonctionnement de ce dernier. Contrairement aux
attaques passives, les attaques actives sont détectables dû aux dommages conséquents qu'elles
peuvent provoquer. Le but d'un attaquant est d'essayer de contourner ou d'entrer dans un
système sécurisé pour voler, modier, désactiver ou détruire des données sensibles. Voici les
attaques actives les plus connues [11] :
Par mascarade (ou usurpation d'identité) : Cette attaque a lieu lorsqu'une entité
prétend être une entité diérente. Ce type d'attaque est l'origine de toutes les autres attaques
actives,
Par rejeu : Ce type d'attaques consiste à capturer un message transmis (attaque passive),
ensuite à le retransmettre ultérieurement pour produire un eet non autorisé,
Par modication de message : Cette attaque permet de modier le contenu du message
ou de réordonner les messages pour produire un eet non autorisé,
Par déni de service : Le principe de cette attaque est de perturber ou d'interrompre
le service d'un réseau. Son but est de saturer le service avec des messages inutiles an de
dégrader les performances du service ou de provoquer la perte des messages.
Il est dicile de garantir une protection absolue contre les attaques actives à cause des vulné-
rabilités existantes au niveau matériel, logiciel et protocolaire, surtout si ces derniers n'ont pas
été vériés et validés formellement.
CHAPITRE 2. MENACES ET MESURES DE PROTECTION 18
2.3.3 Etapes d'une attaque

Pour procéder à une attaque d'un réseau ou un service, l'assaillant suit généralement une méthode
en sept étapes [12] :
1. Analyse d'empreinte (reconnaissance) : Un service d'une entreprise, comme par exemple

sa page Web, peut fournir des données telles que les adresses IP des serveurs. Avec ces données,
l'assaillant peut élaborer le prol ou l'empreinte de la sécurité de cette entreprise ;
2. Enumération des informations : l'assaillant étend sa connaissance du prol de sécurité en

surveillant le trac du réseau à l'aide d'un analyseur de paquets comme l'outil Wireshark par
exemple. Par ailleurs, il peut chercher des informations tels que les numéros de version des
serveurs FTP ou des serveurs de messagerie. Ensuite, il peut croiser ces informations avec des
bases de données de vulnérabilité ;
3. Manipulation des utilisateurs pour obtenir un accès : Les employés de l'entreprise uti-
lisent parfois des mots de passe faciles à casser. Dans d'autres cas, ils peuvent être trompés par
des assaillants astucieux et leur fournissent des données d'accès sensibles ;
4. Escalade des privilèges : Une fois un accès de base obtenu, l'assaillant utilise ses compétences
pour augmenter ses privilèges d'accès au réseau, tout en essayant d'être indétectable par les
techniques sécuritaires de l'entreprise ;
5. Collecte d'autres mots de passe et secrets : Avec davantage de privilèges d'accès, l'as-
saillant se sert de ses talents pour accéder à des informations sensibles bien protégées, tels que
les rapports internes ou même les contrats numérisés de l'entreprise ;
6. Installation de portes dérobées (Backdoors) : Les portes dérobées sont des moyens per-
mettant à l'assaillant d'entrer secrètement dans le système sans être détecté, servant de faille
du système de l'entreprise. La porte dérobée la plus courante est le port TCP ou UDP ouverts
en écoute ;
7. Exploitation du système compromis : Une fois qu'il a compromis le fonctionnement du

système, l'assaillant utilise la porte dérobée pour lancer des attaques vers d'autres hôtes du
réseau.
2.4 Types d'attaques d'un réseau

Toutes les entreprises craignent les attaques informatiques, sans toujours savoir quelles formes
celles-ci peuvent prendre. Au l des années, les mesures de sécurité se sont améliorées et certains types
d'attaques sont devenus moins fréquents, tandis que d'autres ont fait leur apparition. Pour concevoir
des solutions de sécurité des réseaux, il faut tout d'abord évaluer l'ensemble des attaques existantes
aujourd'hui et comprendre leur mode de fonctionnement. Ces attaques sont variées, mais on peut les
catégoriser selon leur mode d'opération :
2.4.1 Attaques de reconnaissance

La reconnaissance est la découverte non autorisée des systèmes, de leurs adresses et de leurs services,
ou encore la découverte de leurs vulnérabilités. Il s'agit d'une collecte d'informations qui, dans la plupart
des cas, précède un autre type d'attaque. Parmi les attaques courantes de ce type, nous citons :
Requêtes Internet : l'assaillant peut utiliser des outils d'Internet, comme les outils nslookup
et whois , pour découvrir facilement les adresses IP attribuées à une entreprise ou à une
entité donnée ;
Balayages ping : Une fois ces adresses IP connues, l'assaillant peut lancer des requêtes ICMP
de type ping vers les adresses IP publiquement accessibles pour déterminer celles qui sont actives.
Certaines outils de balayage existent comme fping ou gping , permettant d'envoyer
systématiquement des requêtes ping à une plage d'adresses ou à toutes les adresses d'un sous-
réseau. Cette approche est similaire à celle qui consiste à utiliser un annuaire téléphonique et à
appeler tous les numéros pour savoir qui répond,
Balayages de ports : Lorsque les adresses IP actives sont identiées, l'assaillant se sert d'un
outil de balayage des ports pour détecter les services réseau ou les ports ouverts sur chaque
adresse IP active. Nmap et Superscan sont des exemples d'outils de balayage conçus
pour détecter les ports ouverts sur un hôte du réseau. Concrètement l'outil de balayage interroge
les ports pour connaître le type et la version des applications, le type et la version du OS, etc.
Grâce à ces informations, l'assaillant peut déterminer s'il existe des vulnérabilités qu'il peut
exploiter,
Analyse des paquets : L'assaillant peut aussi intercepter les paquets TCP/IP ou les paquets
des autres protocoles et décoder leur contenu au moyen d'un analyseur de protocole comme
Wireshark. Une fois les paquets interceptés, ils peuvent être analysés pour y rechercher des
informations vulnérables. An de neutraliser l'analyse des paquets, il est conseillé de :
Utiliser des commutateurs au lieu de concentrateurs pour éviter de diuser le trac à tous
les hôtes du réseau,
Utiliser une méthode de chirement adéquate au système qui ne consomme pas beaucoup
de ressources,
Interdire l'utilisation de protocoles susceptibles d'être écoutés, comme le protocole SNMP.
2.4.2 Attaques d'accès

L'accès au système est la possibilité pour un assaillant d'accéder à un périphérique pour lequel il
ne dispose pas d'autorisation c'est-à-dire un compte ou un mot de passe. La pénétration non autorisée
dans un système implique généralement l'utilisation d'un moyen hardware de piratage, d'un script
ou d'un outil exploitant une vulnérabilité connue de ce système. Les attaques d'accès exploitent des
vulnérabilités connues dans les services d'authentication, les services FTP et les services Web. On
distingue quatre types d'attaques :
Attaques de mot de passe : Pour obtenir le mot de passe d'un utilisateur, l'assaillant peut
lancer diérents types d'attaque : (1) des attaques par force brute qui consistent à lancer
plusieurs tentatives répétées de connexion à une ressource partagée, comme un serveur ou un
routeur, an d'identier un compte utilisateur et/ou un mot de passe, en utilisant généralement
des outils tels que L0phtCrack ou Cain ; (2) des analyses de paquets permettant de capter
les comptes et les mots de passe utilisateurs transmis en clair, en utilisant des outils tels que
WireSharck ou Cain ; ou (3) des programmes de type cheval de Troie pouvant snier la saisie
des mots de passes sur la machine de l'utilisateur,
Exploitation de la conance : Elle consiste à compromettre un hôte de conance et ensuite à
travers ce dernier lancer des attaques sur d'autres hôtes du réseau. Par exemple, dans le réseau
d'une entreprise, si un hôte interne (protégé par un pare-feu), mais qu'il est accessible depuis
un hôte de conance externe (situé de l'autre côté du pare-feu), l'hôte interne peut être attaqué
par le biais de l'hôte externe,
Redirection de port : Cette attaque de type exploitation de la conance, consiste à utiliser
un hôte compromis pour faire passer, au travers d'un pare-feu, un trac qui serait normalement
bloqué. Ce type d'attaque est principalement limité par l'utilisation de modèles de conance
appropriés. Le rôle d'un antivirus, installé sur un hôte, est de détecter et d'empêcher toute
installation d'utilitaires de redirection de port sur cet hôte,
Attaque de l'homme du milieu (man-in-the-middle) : Cette attaque est menée par un as-
saillant qui se place entre deux machines légitimes d'un réseau. Par exemple, l'assaillant pourrait
|http://www.assaillant.dz/http://www.siteweb.dz|
mettre en place un site Web dont l'adresse est
an de se prendre pour le site Web légitime |http://www.siteweb.dz|. Le déroulement des
échanges pourrait être comme suit :
1. La victime demande une page Web du site Web légitime, mais la machine de cette victime,
la demande auprès de la machine de l'assaillant ;
2. La machine de l'assaillant reçoit la demande et récupère la page du site Web d'origine ;
3. En cas d'une attaque active, l'assaillant modie la page d'origine et transforme à sa façon
les données qu'elle contient ;
4. L'assaillant envoie la page demandée falsiée à la victime.
2.4.3 Attaques par déni de service (DoS)

Le Déni de service (DoS ) apparaît lorsqu'un assaillant désactive ou altère un réseau, des systèmes
ou des services dans le but de refuser le service prévu aux utilisateurs normaux. Les attaques par DoS
mettent le système en panne ou le ralentissent au point de le rendre indisponible et inutilisable, en
empêchant l'utilisation d'un service par les personnes autorisées dû à l'épuisement des ressources du
système. C'est pour cette raison que les attaques par DoS sont les plus redoutées. Dans la plupart des
cas, l'attaque se résume à exécuter un programme pirate ou un script.
Il existe plusieurs types d'attaques de DoS, on peut citer :
Attaques par ping fatal : Autrefois, elles protaient des vulnérabilités des anciens systèmes
d'exploitation (année 90). L'assaillant modiait la partie IP de l'en-tête d'un paquet ping pour
indiquer une quantité de données supérieure à la quantité réelle du paquet. En eet, un paquet
ping contient normalement de 64 à 84 octets, tandis qu'un ping fatal peut atteindre 65 535
octets. Donc, l'envoi d'un ping de cette taille peut bloquer un hôte cible d'ancienne génération.
La plupart des réseaux ne sont actuellement plus vulnérables à ce type d'attaque,
Attaques par Inondation SYN (SYN Flooding) : Sachant qu'une connexion TCP (hand-
shake) suit trois 3 étapes, une attaque par inondation SYN consiste à envoyer un grand nombre
de requêtes SYN (plus de 1000) au serveur ciblé. Ce dernier répond par le message SYN-ACK
habituel, mais l'hôte malveillant ne répond jamais par un message ACK nal pour achever la
procédure de connexion. Etant donné que ces connexions semi-ouvertes consomment des res-
sources mémoires, au bout d'un certain temps le serveur est saturé et ne peut plus accepter de
connexions car il se met dans un état d'attente innie par manque de ressources pour répondre
aux requêtes SYN valides,
Attaques DDoS (Distributed DoS) : Ce type d'attaques est conçu pour saturer le réseau de
données illégitimes, qui submergent la liaison Internet au point d'empêcher tout trac légitime.
Les attaques DDoS s'appuient sur des méthodes similaires aux deux autres attaques DoS, mais
elles se déploient toutefois à une plus grande échelle. En général, des centaines ou des milliers de
points d'attaque tentent de submerger une cible. Pour saturer le réseau victime, le principe est
d'utiliser plusieurs sources pour l'attaque et des maîtres (masters) qui les contrôlent. L'assaillant
utilise des maîtres pour contrôler plus facilement les sources. En eet, il a besoin de se connecter
(en TCP) aux maîtres pour congurer et préparer l'attaque. Les maîtres se contentent d'envoyer
des commandes aux sources en UDP. Les outils de type DDoS les plus connus sont Tribal Flood
Network (TFN), TFN2K, Trinoo, Stacheldraht, etc.
2.4.4 Attaques de programmes malveillants (malware)

Des programmes/logiciels malveillants peuvent être installés sur une machine hôte dans le but
d'endommager un système ou d'empêcher l'accès aux services de ce dernier. Ces programmes essayent
souvent de se reproduire et de se propager pouvant causer des dégâts multiples pour le réseau infor-
matique, tels que :
Gêne : ache des publicités, ralentit ou plante le système,
Espionnage : vole les mots de passe et les informations bancaires, ou envoie des documents
sensibles,
Contrôle d'une machine : la machine infectée devient un zombie contrôlé par l'assaillant, et
généralement enrôlé dans un botnet (robot network).
Un programme de ce type peut être :
Un virus : est un programme malveillant intégré à un autre programme, an d'exécuter des
fonctions indésirables sur la machine de l'utilisateur. Il a besoin d'un mécanisme de livraison,
comme un archive (zip, . . . ) ou un chier exécutable joint à un e-mail, pour transmettre son code
d'un système à un autre. Donc, il ne peut pas se reproduire sans l'aide d'un programme cible. Il
se distingue fondamentalement du ver par le fait qu'une interaction humaine est nécessaire pour
le propager. Cette propagation s'eectue principalement en trois phases : infection, activation,
et duplication. Les types de virus sont :
Virus parasite : s'attaque aux codes source des chiers exécutables et se réplique en
exécutant des derniers en cherchant s'il y a d'autre chiers exécutables à infecter,
Virus résidant en mémoire : hébergé en mémoire et considéré comme un programme du
système, il infecte tous les programmes qui s'exécutent,
Virus sur secteur de Boot (Boot Sector Virus) : infecte le secteur de boot du disque,
et se propage lorsque le système d'exploitation démarre.
Un ver (worm) : exécute un code et installe des copies de lui-même dans la mémoire de la
machine infectée, ce qui infecte par la suite d'autres machines hôtes. En eet, contrairement à
un virus, il est autonome et se duplique à travers un réseau, par exemples : Code Red et Blaster.
Les diérentes phases de l'attaque d'un ver sont :
1. Activation de la vulnérabilité : un ver s'installe en exploitant les vulnérabilités connues

d'un système, comme les utilisateurs naïfs qui exécutent sans vérication un chier exécu-
table joint à un e-mail,
2. Mécanisme de propagation : l'accès à l'hôte étant acquis, le ver s'y reproduit, puis choisie
d'autres cibles,
3. Charge : une fois l'hôte infecté par un ver, l'assaillant peut y accéder en tant qu'utilisateur
privilégié. Il peut utiliser une faille locale pour augmenter son niveau de privilège jusqu'à
celui de l'administrateur.
Un cheval de Troie (trojan) est un programme malveillant conçu pour ressembler à une
application normale et utile, alors qu'il s'agit d'un instrument d'attaque. Concrètment, c'est un
code non autorisé placé dans un programme sain, ce qui le rend dicile à détecter. De plus,
les fonctions non attendues d'un cheval de Troie ne s'exécutent qu'après une longue phase de
sommeil. Par ailleurs, les chevaux de Troie peuvent être des attaques informatives, des attaques
de DoS ou des attaques destructrices.
Comme exemple, le cheval de Troie courant Sub7 consiste à installer une porte dérobée sur
la machine des utilisateurs. Il est utilisé d'une part, en tant que menace non organisée, où les
assaillants inexpérimentés peuvent l'utiliser pour faire disparaître les pointeurs de souris. D'autre
part, il peut être utilisé comme une menace organisée, permettant aux assaillants d'installer un
enregistreur de frappes pour capturer la saisie des informations condentielles,
Un logiciel espion (espiogiciel ou spyware) est un logiciel ou un composant d'un logiciel
qui permet de collecter des informations sur l'utilisateur d'une machine sur lequel il est installé
an de les envoyer vers son concepteur. Le concepteur d'un spyware peut être, par exemple,
une société qui le diuse pour lui permettre de dresser le prol des internautes. Il n'est en
principe pas destiné à endommager une machine mais plutôt conçu pour le recueil de certaines
informations sensibles ou non. On distingue généralement deux types de spywares :
Spywares internes (ou intégrés) comportant directement des lignes de codes dédiées aux
fonctions de collecte de données,
Spywares externes correspondant à des programmes de collectes autonomes installés. Par
exemples : Alexa, Doubleclick, NewDotNet, Flashpoint/Flashtrack, Realplayer, SaveNow,
WebHancer, etc.
Le dé de la sécurité des réseaux auquel les administrateurs réseau doivent faire face est de trouver
un juste équilibre entre deux exigences importantes : (1) garder une certaine ouverture pour permettre
la prise en charge des opportunités de commerce évolutives ; et (2) protéger les données privées et
personnelles, ainsi que les données stratégiques des entreprises contre les diérentes attaques.
2.5 Services de sécurité

Aujourd'hui dans un monde ultra-informatisé, les entités en communication peuvent se trouver
à de grandes distances grâce notamment à Internet. Les réseaux utilisés pour connecter ces entités
orent des qualités de service variables en terme de rapidité, abilité et de condentialité. En eet, les
échanges d'informations sont de plus en plus nombreux et importants, et la sécurité de ces échanges a
pris une importance particulière.
Figure 2.4 Principaux services de sécurité

La sécurité informatique consiste à assurer que les ressources matérielles ou logicielles d'une organi-
sation sont uniquement utilisées dans le cadre prévu. Elle vise généralement à préserver cinq principaux
services de sécurité, les voici :
2.5.1 Condentialité
En partant du principe que les informations d'une entité n'appartiennent pas à tout le monde,
c'est-à-dire seuls ceux qui en ont le droit peuvent y accéder. Ceci signie que le système doit empêcher
les utilisateurs non-autorisés de lire une information condentielle, et aussi empêcher les utilisateurs
autorisés de divulguer une information à d'autres utilisateurs non-autorisés.
Le service de condentialité fournit des mesures de protection contre une divulgation non-autorisée
d'informations. Dans une communication réseau, ce type de service consiste à protéger les données
transmises contre les attaques, et protéger les ux de données contre l'analyse. Certaines informations
sensibles sont les adresses, la longueur des messages, et le contenu des messages. Les mécanismes utilisés
pour ce service sont le chirement et le contrôle d'accès.
2.5.2 Authenticité
Le service d'authenticité des entités consiste à vérier l'identité des parties participantes à une
communication, cela est eectué par un contrôle d'accès par exemple des techniques traditionnelles :
un mot de passe (Something you know), une carte à puce (Something you have), ou une empreinte
digitale (Something you are) [23]. Ces techniques permettent de s'assurer de la non usurpation de
l'identité d'une entité, dans le but de vérier que le message provient de la source réelle du message,
et aussi d'empêcher la perturbation de la connexion par une tierce partie qui se fait passer pour une
entité légitime.
2.5.3 Intégrité
Dans un système sain, les informations ne peuvent être modiées que par les personnes autori-
sées. Cela signie que le système, à travers le service de l'intégrité des données, doit empêcher toute
modication par des utilisateurs non-autorisés ou toute modication incorrecte par des utilisateurs
autorisés.
Dans une communication réseau, ce service consiste à assurer que les données transmises n'ont pas
été altérées, c'est-à-dire garantir que le message reçu est bien celui qui a été envoyé, et celui-ci n'a pas
été modié ou fabriqué.
Parmi les mécanismes utilisés, on distingue le chirement, la signature numérique, le contrôle
d'accès, et le contrôle d'intégrité.
2.5.4 Non-répudiation
La répudiation en informatique, dénit le comportement d'une entité qui nie malhonnêtement avoir
reçu ou envoyé certaines informations au cours d'une transaction ou une communication au travers d'un
réseau [38]. Donc, le service de non-répudiation consiste à assurer que les acteurs impliqués dans la
communication ne peuvent nier y avoir participer, en d'autres termes, il vérie que l'émetteur et le
récepteur sont bien les parties qui ont respectivement envoyé ou reçu le message. Ce service permet
aussi de s'assurer qu'un contrat électronique, par exemple un achat en ligne, ne peut être remis en
cause par l'une des parties, c'est-à-dire garantir l'identité des deux parties.
La non-répudiation est extrêmement importante dans l'internet d'aujourd'hui, notamment pour
le commerce électronique. Actuellement, elle ne peut être assurée qu'en utilisant les mécanismes du
certicat et de la signature numériques.
2.5.5 Disponibilité
En assurant tous les services de sécurité précités, le système protégé doit assurer l'accès autorisé
aux données dans de bonnes conditions, c'est-à-dire l'accès permanent et sans faille durant les plages
d'utilisation prévues. De ce fait, le service de disponiblité des données permet de maintenir le bon
fonctionnement du système en fournissant de l'information aux utilisateurs autorisés aux moments
où ils en ont besoin, grâce notamment aux mécanismes de sauvegardes (répliquats) et de partage de
charge.
D'autres service peuvent s'ajouter à celles précitées an d'améliorer la qualité de sécurité d'un
système, tel que le service de traçabilité qui consiste à garantir que les accès aux données soient tracés
et que ces traces soient conservées et exploitables, pour le reporting.
2.6 Mécanismes de défense

Un mécanisme de sécurité, est un ensemble de stratégies conçues pour détecter, prévenir et lutter
contre une attaque de sécurité [6]. Avec l'évolution des systèmes et des réseaux, il existe une panoplie
de mécanismes de sécurité servant à protéger les systèmes ainsi que les services qu'ils orent. Nous
abordons dans ce qui suit, les principaux mécanismes utilisés :
2.6.1 Audit de sécurité

L'audit de sécurité d'un réseau ore une image complète du réseau sous forme d'un rapport détaillé
qui donne un aperçu instantané et en temps réel du statut du réseau. Une analyse peut être faite sur
le résultat du balayage en utilisant des ltres dans les rapports, ce qui permet de sécuriser le réseau de
manière proactive, par exemple, en fermant les ports ouverts, en supprimant les comptes utilisateurs
qui ne sont plus utilisés ou en désactivant les points d'accès sans l. En terme de sécurité, il permet
d'identier des points de vulnérabilité du réseau, cependant, il ne permet pas de détecter les attaques
qu'a déjà subit le réseau ou que subira dans le futur.
2.6.2 Journalisation
La journalisation consiste à enregistrer les activités et les connexions de chaque acteur utilisant
un réseau. En eet, les journaux d'évènements (logs) constituent une brique technique indispensable
à la gestion de la sécurité des réseaux et plus généralement des systèmes. En eet, les journaux sont
une source d'information riche permettant de constater si des attaques ont eu lieu, de les analyser et
potentiellement de faire en sorte qu'elles ne se reproduisent pas.
Dans ce cas, les évènements constituant les journaux sont consultés et analysés en temps réel.
Les journaux peuvent également être employés a posteriori pour retrouver les traces d'un incident de
sécurité ; l'analyse des journaux d'un ensemble de composants (postes de travail, équipements réseaux,
serveurs, etc.) peut alors permettre de comprendre le cheminement d'une attaque et d'évaluer son
impact.
2.6.3 Antivirus
Un antivirus est un logiciel permettant de protéger une machine contre les programmes/logiciels
néfastes ou les chiers potentiellement exécutables. De nos jours, les antivirus sont aussi des anti-
malwares c'est-à-dire il protègent aussi les machines contre tous les autres types de malwares à savoir
les vers et les chevaux de Troie. Il consiste à chercher les codes malveillants dans les logiciels infectés.
Cependant, un antivirus ne protège pas le réseau contre un intrus qui emploie un logiciel légitime, ou
contre un utilisateur légitime accédant à une ressource alors qu'il n'est pas autorisé à le faire.
2.6.4 Systèmes de détection d'intrusion

1
Un système de détection d'intrusions (ou IDS ) est un appareil ou une application qui alerte
l'administrateur en cas de faille ou de violation de règles de sécurité dans un réseau, permettant
ainsi de prévenir les risques d'intrusion. Ce système consiste à surveiller et analyser les activités d'un
réseau en repérant celles qui sont anormales ou suspectes, cependant, il ne permet pas de détecter les
accès incorrects mais autorisés par un utilisateur légitime. Par ailleurs, certaines mauvaises détections
peuvent arriver tels que les taux de faux positifs et les taux de faux négatifs.
2.6.5 Pare-feu
Un pare-feu (ou Firewall en anglais) est un système logiciel ou matériel installé sur une machine ou
un routeur, permettant de contrôler les communications qui traversent un réseau donné. Ce mécanisme
permet de protéger un réseau privé de certaines intrusions provenant d'un réseau externe (par exemple
internet), telles que les communications sortantes déclenchées par un malware installé. Par ailleurs,
il a pour fonction de faire respecter la politique de sécurité du réseau, qui dénit quelles sont les
communications autorisées ou interdites.
Concrètement, il s'agit d'une passerelle qui consiste à ltrer les paquets entrants et sortants en se
basant sur une interface pour le réseau à protéger, et une autre pour le réseau externe (souvent c'est
internet) [11]. Néanmoins, le pare-feu ne protège pas le réseau contre une attaque venant du réseau
intérieur (c'est-à-dire celui qui ne le traverse pas), et il n'empêche pas un attaquant d'utiliser une
connexion autorisée pour attaquer le système.
2.6.6 Contrôle d'accès

2
Le mécanisme du contrôle d'accès au réseau (NAC ) permet de renforcer sa sécurité en limitant les
ressources réseau accessibles aux terminaux selon une stratégie de sécurité dénie. En eet, il permet
de vérie les droits d'accès aux données d'un utilisateur, toutefois, il n'empêche pas l'exploitation d'une
vulnérabilité par un assaillant. Le NAC convient particulièrement aux grands organismes et entreprises
qui exercent un contrôle strict sur leur réseau. Les solutions existantes possibles pour gérer les accès
autorisés sont l'utilisation des VPN ou des tunnels.
2.6.7 Authentication réseau

L'authentication réseau permet d'authentier une machine quand elle essaie de se connecter sur
le réseau et savoir avec précision si elle est déjà connectée en lui donnant les autorisations nécessaires
pour l'usage du réseau. L'authentication réseau est nécessaire au bon fonctionnement des autres mé-
canismes de défense, et elle est indépendante des autres méthodes d'authentications vers les systèmes
d'exploitation ou les applications.
Il existe deux catégories de protocoles qui peuvent être utilisés pour l'authentication réseau, il y a
d'une part, (1) les protocoles propriétaires comme VMPS de Cisco Authentication qui est seulement
valable sur une adresse MAC et réseau laire ; et d'autre part, (2) il y a les protocoles ouverts comme
RADIUS et 802.1x Authentication sur adresse MAC [4].
1. IDS : Intrusion Detection Systems

2. NAC : Network Access Control ou Network Admission Control
2.6.8 Bourrage de trac

Le bourrage de trac est destiné à protéger un réseau contre les attaques passives qui consistent à
capturer et à analyser le trac circulant dans le réseau. Ce mécanisme consiste à injecter des messages
inutiles pour faire échouer les tentatives d'analyse du trac. Cette pratique permet d'améliorer la
condentialité des données, notamment au niveau du volume du trac.
2.6.9 Chirement des données

Le chirement consiste à transformer un message en clair en un message incompréhensible, en uti-
lisant généralement un algorithme basé sur des clés. Essencielement, deux techniques de cryptographie
sont utilisées : (1) Le chirement symétrique qui consiste à utiliser la même clé dite secrète pour chif-
frer et déchirer un message, tandis que (2) le chirement asymétrique qui se base sur une paire de
clés, c'est-à-dire une clé publique pour le chirement du message, et une clé privée pour le déchirer,
sachant que seul le destinataire du message qui possède la clé privée lui permettant de déchirer le
message. Ce mécansime sera abordé en détail dans le cours 9 de ce module.
2.6.10 Signature numérique

La signature numérique est un mécanisme permettant de garantir l'intégrité et la non-répudiation
d'un message ou d'un document électronique. Analogiquement à la signature manuscrite d'un document
papier, la signature numérique permet d'authentier un document ou un contrat électronique.
2.6.11 Protection physique

La protection physique d'un réseau consiste à rendre inaccessible tous ses équipements, pour fournir
une protection totale, mais qui peut être excessive, car le réseau n'aura aucun accès de l'extérieur. Par
exemple, le fait d'isoler complètement le réseau d'un organisme sensible telle que une centrale nucléaire,
toutefois, cette solution peut paraître trop radicale dans le cas des entreprises.
2.7 Conclusion
Comme conclusion, aucun des mécanismes de sécurité précités n'est susant par lui-même. An
de mieux sécuriser son réseau, il faut non seulement appliquer tous ces mécanismes mais aussi les faire
évoluer de jour en jour !
Chapitre 3
Analyse des risques et politique de

sécurité
3.1 Introduction
Dans un système informatique, l'information a une valeur seulement si l'on est convaincu qu'elle
est exacte et intacte, et l'un des objectifs principaux d'une politique de sécurité est de s'assurer que
l'information n'est ni modiée ni détruite.
3.2 Politiques de sécurité

Une politique de sécurité permet de dénir quelles sont les communications autorisées ou interdites.
Concrètement, c'est une déclaration formelle des règles de sécurité qui spécient les autorisations, les
interdictions et les obligations des utilisateurs qui peuvent accéder à un système spécique. En eet, la
politique de sécurité consiste à dénir un plan d'actions pour maintenir un certain niveau de sécurité
en xant les principaux paramètres, notamment les niveaux de tolérance et les coûts acceptables.
Toutefois, une politique de sécurité est limitée, car non seulement, elle n'empêche pas un assaillant
d'utiliser une connexion autorisée pour attaquer le système, mais aussi elle ne protège pas ce système
contre une attaque venant du réseau intérieur.
3.2.1 Cycle de vie

Pour instaurer une politique de sécurité pour un système donné, on suit généralement trois étapes :
Tout d'abord, on dénit la politique de sécurité en mettant en place des paramètres de sécurité en
termes de longueur des clés, de choix des algorithmes, de fréquence de changement des "passwords",
etc. [10]. Une fois la politique est dénie, il faut la mettre en ÷uvre à travers l'utilisation d'outils de
sécurité appropriés, à savoir un pare-feu et une zone démilitarisée. Comme troisième phase, on procède à
l'audit de la politique et sa bonne gestion pour maintenir sa cohérence. Toute mise à jour de la politique
de sécurité exige l'exécution de tout le cycle de vie en suivant les 3 phases citées précédemment.
3.2.2 Fonctionnalités
Comme fonctionnalités, une politique de sécurité doit impérativement contrôler l'accès au système
avec la gestion des prols utilisateurs et prévenir contre les intrusions dans le but de protéger le système.
Par ailleurs, elle consiste aussi à gérer les crises sécuritaires en proposant des politiques de réaction et
de reprise.
An d'assurer le suivi de la politique de sécurité, des audits et des supervisions peuvent être
appliqués avec des mécanisme de sensibilisation.
Voici quelques procédures qu'un administrateur réseau doit suivre impérativement an de protéger
le système ainsi que le réseau géré :
26
CHAPITRE
Sécurité des3.réseaux
ANALYSE DES RISQUES – Semestre 2 DE SÉCURITÉ
ET POLITIQUE
2018-2019 Université Constantine 2 27
Dénir le domaine du réseau à protéger ;

Voici quelques procédures qu’un administrateur réseau doit suivre impérativement afin de protéger le système
Dénir l'architecture et la politique de sécurité en termes d'équipements/points de sécurité, de
ainsi que le réseau gérés :
paramètres de sécurité et de mécanismes de prévention ;
Définir le domaine du réseau à protéger ;
Établir un plan de réponse en cas d'incident telles que la procédure de reprise et la procédure
Définir l’architecture et la politique de sécurité en termes d’équipements/points de sécurité, de
qui permet de corriger la vulnérabilité coupable ;
paramètres de sécurité et de mécanismes de prévention ;
Dénir l'organigramme des rôles et des privilèges accordés aux utilisateurs du système ;
Etablir un plan de réponse en cas incident telles que la procédure de reprise et la procédure qui permet
Proposer une charte du bon comportement de l'utilisateur du système ;
de corriger la vulnérabilité coupable ;
Dénir une méthodologie seine de développement des logiciels, ainsi que la procédure de mise
Définir l’organigramme des rôles et des privilèges accordés aux utilisateurs du système ;
à jour.
Proposer une charte du bon comportement de l’utilisateur du système ;
Définir une méthodologie seine de développement des logiciels, ainsi que la procédure de mise à jour.
3.3 Eléments d'une politique de sécurité
2. Eléments d’une politique de sécurité
3.3.1 Pare-feu (Firewall)
2.1. Pare-feu (Firewall)
Comme décrit dans le cours précédent, un pare-feu (ou Firewall en anglais) est un programme,
Comme décrit dans le cours précédent, un pare-feu (ou Firewall en anglais) est un
ou matériel chargé de protéger un réseau privé ou une machine, de certaines intrusions provenant
programme, ou matériel chargé de protéger un réseau privé ou une machine, de
d'un réseau externe (par exemple internet), en contrôlant tout ce qui le traverse, et notamment, en
certaines intrusions provenant d’un réseau externe (par exemple internet), en
interdisant tout
contrôlant toutce
cequi netraverse,
qui le doit pas traverser. en interdisant tout ce qui ne doit pas
et notamment,
Concrètement,
traverser. il s'agit d'une passerelle qui consiste à ltrer les paquets entrants et sortants en se
basant sur une interface pour le réseau à protéger, et une autre pour le réseau externe (souvent c'est
Concrètement, il s’agit d’une passerelle qui consiste à filtrer les paquets entrants et sortants en se basant
internet) [34] :
sur une interface pour le réseau à protéger, et une autre pour le réseau externe (souvent c’est internet) [2] :
Filtrage entrant : Les connexions illégitimes depuis l'extérieur sont bloquées, même si, par
Filtrage entrant : Les connexions illégitimes depuis l’extérieur sont bloquées, même si, par exemple,
exemple, un tiers malveillant veut atteindre la porte dérobée qu'il a installée sur la machine à
un tiers malveillant veut atteindre la porte dérobée qu’il a installée sur la machine à travers un cheval
travers un cheval de Troie ;
de Troie ;
Filtrage sortant : les envois illégitimes depuis la machine sont automatiquement bloqués, par
Filtrage sortant : les envois illégitimes depuis la machine sont automatiquement bloqués, par
exemple, l'envoi d'informations
exemple, l’envoi condentielles
d’informations confidentielles volées
volées par par un cheval
un cheval deest
de Troie Troie
bloquéest
parbloqué
le pare-par le
pare-feu.
feu.
La gure 3.1 illustre un exemple d'un ltrage entrant interdisant un message entrant depuis un
Le schéma suivant illustre un exemple d’un filtrage entrant interdisant un message entrant depuis un tiers
tiers malveillant.
malveillant.
 Ordre classique
 Demande d’ordre
 Ordre
Assaillant  Réponse Victime
2.1.1. Utilités des pare-feux

Figure 3.1 Fonction de ltrage d'un pare-feu
Un par-feu permet d’assurer les caractéristiques suivantes :
Contrôle : Gérer les connexions sortantes à partir d’un réseau local ;
Utilités des pare-feux
Sécurité : Protéger le réseau interne des intrusions venant de l’extérieur ;
Vigilance : Surveiller et tracer le trafic entre le réseau local et internet.
Un par-feu permet d'assurer les caractéristiques suivantes :
Contrôle : Gérer les connexions sortantes à partir d'un réseau local ;
Par ailleurs, le pare-feu installé sur une machine permet de la protèger contre (1) les intrusions depuis
l’internet ; (2) l’infection de certains virus et leur propagation ; ainsi que (3) l’effet des chevaux de Troie en
Sécurité : Protéger le réseau interne des intrusions venant de l'extérieur ;
stoppant l’envoi d’informations vers internet ou en empêchant un intrus d’accéder à la machine par une porte
Vigilance : Surveiller et tracer le trac entre le réseau local et internet.
dérobée installée préalablement.
Par ailleurs, le pare-feu installé sur une machine permet de la protéger contre (1) les intrusions
depuis l'internet ; (2) l'infection de certains virus et leur propagation ; ainsi que (3) les dommages
causés par des chevaux de Troie en stoppant l'envoi d'informations vers internet ou en empêchant un
intrus d'accéder
© Dr. à la machine par une porte dérobée installée préalablement.
R. Boukharrou Page 3 sur 12
Cependant, le pare-feu ne protège pas la machine contre une attaque venant de l'intérieur, c'est-à-
dire celui qui ne le traverse pas, et il n'empêche pas un attaquant d'utiliser une connexion autorisée
pour attaquer le système.
CHAPITRE 3. ANALYSE DES RISQUES ET POLITIQUE DE SÉCURITÉ 28
Classications de pare-feu
Plusieurs classications existent pour catégoriser les types de pare-feu. En eet, en termes de
ltrage, on distingue principalement deux types de pare-feu :
Pare-feu réseau (ou ltrage de paquets), fonctionnant au niveau des couches Internet
et Transport du modèle TCP/IP, en se basant sur le ltrage de paquets, c'est-à-dire autoriser
un paquet ou le refuser en fonction de son entête IP (Adresses IP source et destination, numéro
de port et protocole TCP/UDP), sans accéder à son contenu ce qui ne permet pas de recon-
naître l'identité de l'émetteur du paquet. Dans ce type de pare-feu, on distingue deux types de
ltrage [20] :
Filtrage simple de paquet (Stateless) : La plupart des routeurs d'aujourd'hui per-
mettent d'eectuer du ltrage simple de paquet. C'est la méthode de ltrage la plus simple,
car elle consiste à autoriser ou à refuser le passage de paquets d'un réseau à un autre en
se basant sur l'entête IP du paquet (Adresses IP source et destination, numéro de port et
protocole TCP/UDP). Cela nécessite de congurer le pare-feu par des règles de ltrages,
généralement appelées des ACL (Access Control Lists).
Parmi les limites du ltrage simple, ce dernier requiert une conguration poussée pour être
ecace, en plus de ralentir le débit de la bande passante qui le traverse. Par ailleurs, il ne
résiste pas à certaines attaques de type IP Spoong/IP Flooding, la déformation de paquet,
ou encore certaines attaques de type DoS.
Filtrage de paquet avec état (Stateful) : La diérence de ce ltrage par rapport au
ltrage simple, est la conservation de la trace des sessions et des connexions dans des
tables d'états internes au pare-feu. Ce dernier prend ses décisions en fonction des états
de connexions, et peut réagir dans le cas de situations protocolaires anormales. En outre,
ce ltrage permet aussi de se protéger face à certaines attaques de type DoS. En eet, les
connexions Internet sont contrôlées en n'autorisant que celles qui sont à la demande, et dans
le cas des protocoles UDP et ICMP, un certain délai est déni pour autoriser les réponses
légitimes aux paquets envoyés. Cependant, dès lors que l'accès à un service est autorisé par
ce type de pare-feu, il n'y aurait aucun contrôle eectué sur le ux qui concerne ce service.
Pare-feu applicatif (ou ltre d'application 1 ), fonctionne au niveau applicacatif du
modèle TCP/IP. En eet, il peut ltrer les ux non seulement en fonction des entêtes IP,
mais aussi en fonction des données contenues. Le ltrage d'application est réalisé grâce à un
programme, dit mandataire, qui permet de contrôler l'accès à chaque application en fonction
de l'utilisateur et de ses activités. Le principe de ce pare-feu est identique à celui d'un proxy,
c'est-à-dire, quand un utilisateur veut se connecter à un serveur externe, il se connecte d'abord
au programme mandataire, qui lui va relayer le ux vers le serveur demandé. Par exemple, la
connexion à internet à travers certains réseaux Wi-Fi d'entreprises exige une authentication au
préalable sur un pare-feu mandataire permettant à l'utilisateur de surfer mais passant toujours
à travers le proxy. Avec ce genre de ltre, une seule machine (le serveur mandataire) envoie des
requêtes vers l'extérieur en gardant trace du trac. Ce type de pare-feu est plus ecace car le
contenu des paquets est analysé, ce qui permet au ltre de laisser passer ou non suivant des
règles applicables au contenu.
En terme de déploiement, un pare-feu peut être un appareil physique, un logiciel ou les deux. En
eet, un pare-feu matériel, connu également sous le nom de pare-feu externe, est un équipement réseau
physique autonome, généralement placé entre le réseau local d'entreprise et le réseau externe (souvent
Internet), an de protéger le système de l'entreprise des diérentes menaces venant d'Internet. On peut
citer les équipements disponibles sur le marché : ASA 5505 de Cisco, FortiGate 900 de Fortinet, et
SRX 100 de Juniper.
Ce type de pare-feu est utile pour protéger les échanges de données sensibles circulant d'un réseau
à un autre. Certains équipements réseau tels que les routeurs, sont dotés de ce type de pare-feu comme
un service inclus, ce qui constitue une bonne solution pour les entreprises, leur évitant d'avoir deux
1. Filtre d'application : Appelé aussi ltre de proxy ou proxying applicatif

Règle Action IP Source IP Dest. Protocole Port Source Port dest.

1 Autorisé 192.168.1.18 184.153.182.2 TCP All 25
2 Refusé All 192.168.1.3 TCP All 80
3 Autorisé
192.168.10.0/24
All TCP All 80
4 Refusé All All All All All
Table 3.1 Conguration du ltrage d'un pare-feu réseau de type Stateless
équipements séparés.
Par ailleurs, le pare-feu logiciel, appelé aussi pare-feu personnel, est un programme installé sur
une machine pour la protéger, en contrôlant les ux entrant et sortant. Certains systèmes d'exploitation
installés sur les machines comme Windows, sont dotés par défaut d'un pare-feu logiciel.
Pour une entreprise donnée, en terme d'ecacité, le pare-feu matériel ore une meilleure solution de
sécurité bien plus stable et performante, en revanche, un pare-feu logiciel est installé sur les machines
de l'entreprise, an de protéger uniquement la machine en question et pouvant être désactivé à tout
moment.
Fonctionnement du ltrage simple de paquet

Le ltrage simple de paquet accepte ou rejette les ux d'informations qui le traversent en fonction
des règles de ltrage. Ces règles sont dénies par défaut ou par l'utilisateur, en spéciant la source et
la destination de l'information, ou même les services à autoriser tels que le courrier électronique, la
navigation internet, ou la messagerie instantanée, etc. En eet, le pare-feu peut autoriser ou bloquer :
Des types de protocoles (par exemples, IP, TCP, UDP ou ICMP),
Une ou des adresses IP spéciques pour l'émetteur ou le récepteur,
Des numéros de ports associés à un service ou à une application,
Des applications installées sur la machine.
La table 3.1 montre un exemple de conguration d'un pare-feu réseau de type stateless.
Dans cet exemple, la règle 1 spécie qu'un ux doit être autorisé lorsque les conditions suivantes
sont satisfaites :
Le ux est émis par la machine de l'entreprise ayant l'adresse IP 192.168.1.18,
Le ux s'adresse à une machine ayant l'adresse IP 184.153.182.2,
TCP est le protocole utilisé,
Peu importe le port (All) qu'utilise la machine émettrice pour envoyer le ux,
Le ux s'adresse au port 25 de la machine réceptrice.
Par ailleurs, il est possible de dénir des prols an que les règles du pare-feu soient diérentes
entre les utilisateurs d'une même entreprise, par exemple, certains utilisateurs de l'entreprise pourraient
accéder à Internet et d'autre non.
Limites des pare-feu

Voici quelques limites auxquelles sourent les pare-feux :
Les pare-feux sont considérés comme des cibles privilégiées pour les saturer (étouer) et mis
hors service ;
Ils ne protègent pas contre les attaques qui ne les traversent pas ;
Ils ne protègent pas contre les chiers infectés par les virus, d'où l'utilité d'installer un antivirus
sur les machines ;
Ils peuvent bloquer des tentatives de propagation de virus et d'accès par diérents programmes
malveillants, mais, ne peuvent jamais les supprimer.
Recommandations
An qu'un pare-feu soit ecace, il faut appliquer les quelques recommandations suivantes :
Utilisation du pare-feu pour créer un périmètre délimité, appelé, une zone démilitarisée (DMZ) ;
Tout le trac traversant le pare-feu doit être refusé par défaut, puis accepté cas par cas à travers
ux 2018-2019 – Semestre 2 Université Constantine 2
les règles de ltrage en fonction des applications utilisées ;
Inspection régulière du journal du pare-feu pour détecter le trac anormal ;
mandations Conservation de la trace d'activité doit être activée, an de pouvoir analyser les vulnérabilités
-feu soit efficace, il fauten cas de sinistre ;

appliquer les quelques recommandations suivantes :
Mise à jour régulière du pare-feu.
on du pare-feu pour créer un périmètre délimité, appelé, une zone démilitarisée (DMZ) ;
3.3.2des Zones démilitarisées (DMZ)

trafic traversant le pare-feu doit être refusé par défaut, puis accepté cas par cas à travers les
e filtrage en fonction applications utilisées ;
on régulière du journalLe nomdu pare-feu
de ce pour détecter le
mécanisme trafic anormal
provient ;
à l'origine de la zone coréenne démilitarisée. Étant créée en 1953
ation de la trace d’activité doit être activée, afin de pouvoir analyser
après la guerre de corée, la zone démilitarisée est uneles vulnérabilités en cas de sinistre
étroite bande; de terre servant de zone tampon
our régulière duentre
pare-feu.
la Corée du Nord et la Corée du Sud.
militarisées (DMZ) DMZ

mécanisme provient à l'origine de la zone coréenne
ant créée en 1953 après la guerre de corée, la zone
une étroite bande de terre servant de zone tampon LAN
u Nord et la Corée du Sud.
tique, une zone démilitarisée (DMZ2) est un sous-
u réseau d’une entreprise par un pare-feu, permettant Pare-feu
u local (LAN) du réseau externe (par exemple Internet).
’entreprise susceptible d'être accédé depuis Internet sera mis dans une machine située en DMZ,
Figure
en provenance d'Internet sont redirigés par défaut 3.2 Une DMZ à l'entrée d'un pare-feu
vers la DMZ par le pare-feu. De plus, le
a tous les accès au réseau local, même depuis de la DMZ. En effet, en cas de compromission
En informatique, unemachines
zone démilitarisée (DMZ
2 ) est un sous-réseau séparé du réseau d'une en-
s de la DMZ, l’assaillant n'aura accès qu'aux de la DMZ et non au réseau local.
treprise par un pare-feu, permettant d'isoler le réseau local (LAN) du réseau externe (par exemple
ctures possibles
Internet). Tout service de l'entreprise susceptible d'être accédé depuis Internet sera mis dans une ma-
architecture DMZ la plus courante est basée sur un pare-feu à trois interfaces, cependant si ce
chine située en DMZ, car tous les ux en provenance d'Internet sont redirigés par défaut vers la DMZ
promis, les accès externes ne seront plus contrôlés. Donc, une deuxième architecture consisterait
par le pare-feu. De plus, le pare-feu bloquera tous les accès au réseau local, même depuis de la DMZ. En
are-feux en cascade afin d'éliminer tout risque d’intrusion. Par ailleurs, il existe une troisième
eet, en cas de compromission d'un des services de la DMZ, l'assaillant n'aura accès qu'aux machines
Z qui est située entre le réseau Internet et le réseau local, séparée de chacun de ces deux réseaux
de la DMZ et non au réseau local.
La figure suivante illustre les 3 cas possibles pour la construction d’architecture DMZ [4].
et
ArchitecturesInternet
possibles Internet
Généralement, l'architecture DMZ la plus courante est basée sur un pare-feu à trois interfaces,
cependant si ce pare-feu est compromis, les accès externes ne seront plus contrôlés. Donc, une deuxième
Proxy deux pare-feux en cascade an d'éliminer tout risque d'intrusion. Par
architecture consisterait à utiliser
ailleurs, il existe une troisième architecture
Proxy Serveur DMZ qui est située entre le réseau Internet et le réseau local,
Proxy
Web
séparée de chacun de ces deux réseaux par un pare-feu. La gure 3.3 présente les trois cas possibles
Serveur
Web
pour la construction d'architecture DMZ [18].
Serveur
Web
Services oerts
Toute architecture DMZ doit orir au réseau de l'entreprise les services suivants :
Des services publics permettant de masquer les services et la topologie du réseau de l'entreprise ;
Un ltrage réseau entre les diérents sous-réseaux de l'entreprise grâce aux pare-feux ;
(a) (b) (c)
Des serveurs relais pour gérer le trac interne/externe ;
Des antivirus et/ou analyseurs de contenus pour journaliser les échanges et décontaminer les
ux entrants ou sortants.
2. DMZ : Demilitarized Zone.

rized Zone
rou Page 6 sur 12

Généralement, l’architecture DMZ la plus courante est basée sur un pare-feu à trois interfaces, cependant si ce
pare-feu est compromis, les accès externes ne seront plus contrôlés. Donc, une deuxième architecture consisterait
à utiliser deux pare-feux en cascade afin d'éliminer tout risque d’intrusion. Par ailleurs, il existe une troisième
architecture DMZ qui est située entre le réseau Internet et le réseau local, séparée de chacun de ces deux réseaux
CHAPITRE 3. ANALYSE
par un pare-feu. DES RISQUES
La figure suivante ETpossibles
illustre les 3 cas POLITIQUE DE SÉCURITÉ
pour la construction d’architecture DMZ [4]. 31
Internet Internet Internet
Proxy
Proxy Serveur Proxy

Web
Serveur
Web
Serveur
Web
(a) (b) (c)
Figure 3.3 Cas d'architectures DMZ
3.3.3 DMZSystème
2
de détection d'intrusion (IDS)
: Demilitarized Zone
3
Un système de détection d'intrusion (IDS ) est un mécanisme complémentaire à un pare-feu per-
mettant une analyse plus intelligente du trac. En eet, il consiste à écouter le trac réseau de manière
discrète an de repérer des activités anormales ou suspectes, et permettre ainsi d'avoir une action de
prévention sur les risques d'intrusion.
Par analogie avec les contrôles routiers, un pare-feu se contenterait de regarder la plaque d'imma-
triculation du véhicule, tandis que l'IDS vériera l'attitude du conducteur et des passagers.
Concrètement, des assaillants arrivent parfois à passer à travers les règles de sécurité des pare-feux,
notamment en exploitant ses éventuelles failles de règles. Par ailleurs, un pare-feu ne protège jamais
contre les attaques internes. Comme solution aux limites des pare-feux, les IDS sont développés dans
le but d'analyser plus nement les informations pour détecter les véritables attaques et éviter ainsi les
fausses alertes.
Fonctionnalités d'un IDS

Parmi les fonctionnalités que peut fournir un IDS, ce dernier assure :
L'analyse en temps réel ou en diéré des évènements en provenance des diérents réseaux ;
La détection des signes de violation de la politique de sécurité ;
L'Alerte en cas d'occurrence d'une attaque ;
La collecte des traces d'intrusions pour servir comme preuve ;
La réaction aux attaques.
Classications des IDS

Il existe essentiellement, deux classications distinctes d'IDS : La première en fonction de leur
réactivité aux attaques, et la deuxième en fonction de leur déploiement :
En terme de réactivité aux attaques, les IDS se classent en : (1) Les IDS passifs déclenchent
simplement des alarmes en cas d'attaques ; tandis que (2) les IDS actifs déclenchent non seulement des
alarmes en cas d'attaque, mais enclenchent en plus un processus de défense contre l'attaque.
4
Actuellement, en parle de plus en plus de systèmes de prévention d'intrusion (IPS ) qui représentent
une évolution technologique des IDS, permettant de prévenir contre les intrusions et non plus seulement
de les reconnaître et les signaler. Sa principale diérence par rapport à un IDS, est la possibilité de
bloquer immédiatement les intrusions avant leur arrivée [50].
En terme de déploiement, les IDS se distinguent en trois grandes familles :
3. IDS : Intrusion Detection System

4. IPS : Intrusion Prevention System
Figure 3.4 Architectures des N-IDS et H-IDS
Network-based IDS (N-IDS), opère au niveau d'un réseau en se basant sur un logiciel/ma-
tériel dédié installé uniquement à des points spéciques. Ce type d'IDS est un système capable
de contrôler les paquets circulant sur un ou plusieurs liens réseau dans le but de découvrir si
un acte malveillant ou anormal a lieu. Le N-IDS place une ou plusieurs interfaces réseau en
mode promiscuité (Promiscuous mode), c'est-à-dire ces interfaces sont congurées comme
furtives (discrètes) an qu'elles n'aient ni adresse IP, ni de pile protocolaire attachée. Il est
fréquent de trouver deux N-IDS sur le réseau en plaçant un N-IDS à l'extérieur du réseau an
d'étudier les tentatives d'attaques ainsi qu'un N-IDS en interne pour analyser les requêtes ayant
traversé le pare-feu ou bien menée depuis l'intérieur. On trouve plusieurs N-IDS sur le marché,
par exemple, Snort, Enterasys, et Check Point ;
Host-based IDS (H-IDS), est particulièrement ecace pour déterminer si un hôte a été
victime par une intrusion. Contrairement à un N-IDS, qui consiste à surveiller l'ensemble d'un
réseau, le périmètre d'opération d'un H-IDS est restreint à l'hôte où il est installé. Voici quelques
exemples de H-IDS : AIDE, DarkSpy, IceSword, et Rootkit Unhooker ;
IDS hybride, est basé sur une architecture distribuée, constituée de plusieurs composants N-
IDS et H-IDS coopératifs, permettant d'avoir des alertes plus globales et plus pertinentes. En
eet, chaque composant IDS unie son format d'envoi d'alerte pour être communiqués, en cas
de besoin, à d'autres composants IDS, ce qui permet d'extraire des alertes plus pertinentes avec
une analyse globale du réseau. Il existe plusieurs solutions d'IDS hybride tels que Prelude et
OSSIM.
L'utilisation d'IDS hybride constitue la meilleure façon de protéger un réseau en combinant les
deux technologies des N-IDS et des H-IDS.
Diérentes actions des IDS

Les principales méthodes utilisées pour signaler et bloquer les intrusions sur les IDS, et plus parti-
culièrmeent les N-IDS, sont les suivantes [50] :
Journalisation de l'attaque, en sauvegardant des détails de l'alerte dans une base de données
centrale ;
Sauvegarde des paquets suspicieux, qui ont déclenchés une alerte ;
Envoi d'alertes sous forme de datagramme SNMP à un hyperviseur tiers ;
Envoi d'e-mails à une ou plusieurs boîtes aux lettres pour notier d'une intrusion sérieuse ;
Notication visuelle de l'alerte, en l'achant dans une console de management ;
Lancement d'une application extérieur, pour exécuter une action spécique, par exemple pour
envoyer d'un message SMS, ou pour émettre une alerte auditive ;
Reconguration d'équipement tierces, tels qu'un pare-feu ou un routeur, en lui envoyant un

ordre de reconguration immédiate accompagné d'informations détaillant l'alerte, dans le but
de bloquer une intrusion détectée ;
Envoi d'un "ResetKill", qui consiste à construire et envoyer un paquet TCP FIN pour forcer la
n d'une connexion TCP.
3.3.4 Réseaux privés virtuels (VPN)

5
Comme son nom l'indique, un réseau privé virtuel (VPN ) est un réseau privé qui permet de créer
un lien logique direct entre deux ou plusieurs machines distantes en utilisant un tunnel sécurisé à l'in-
térieur d'un réseau physique et publique comme Internet. Pour assurer la sécurité des communications,
les connexions des utilisateurs requièrent une authentication, et les données sont chirées avant de
transiter dans le tunnel.
Pour mieux comprendre le principe d'un VPN, imaginons qu'Internet est comme un réseau de
canalisations souterraines et que les données qui circulent sur Internet sont l'eau qui circule dans les
canalisations. Donc, un VPN est vu comme un tuyau à l'intérieur de ces canalisations permettant de
relier des machines entre elles, où le ux (l'eau) qui circulent à l'intérieur du VPN (tuyau) n'est jamais
accessible pour (mélangé à) le reste des machines d'Internet (l'eau des canalisations).
Le principal objectif d'un VPN est de permettre d'accéder à un réseau interne depuis un autre
réseau, il est donc très utilisé dans le domaine du travail à distance. Dans une entreprise, le VPN
pourrait être utilisé par un utilisateur lorsqu'il est en déplacement. Il permet également de construire
des réseaux superposés, en construisant un réseau logique sur un autre réseau et faire ainsi abstraction
de la topologie de ce dernier.
En outres, les VPN permettent à n'importe quel utilisateur de se connecter depuis un réseau Wi-Fi
public à un serveur distant en toute sécurité. Ils sont aussi utilisés par le grand public pour accéder à
des sites ou services Web géo-censurés proposés sur Internet ou même pour contourner des restrictions
imposées par un état autoritaire. En eet, un VPN peut agir comme une passerelle vers internet,
camouant l'adresse IP de l'utilisateur réel, ce qui rend plus dicile son identication et sa localisation.
Toutefois, le serveur VPN dispose souvent d'informations permettant d'identier l'utilisateur.
Les machines connectées à un VPN, se trouvent sur un même réseau local (virtuel), ce qui permet
d'appliquer certaines restrictions sur le réseau comme des pare-feux ou des proxys. Par ailleurs, l'usage
d'un VPN est parfaitement légal dans certains pays, en revanche, l'utilisation que l'utilisateur pourra
en faire ne le sera pas forcément, comme par exemple, le téléchargement de chiers piratés, ou le
contournement de ltrages législatifs. En utilisant un VPN, il est dicile de localiser la machine
émettrice par le fournisseur de service, cependant, le serveur VPN dispose de toutes les informations
permettant d'identier l'utilisateur.
De plus, en tant qu'utilisateur de VPN, celui-ci n'est jamais sûr de la bonne intention du VPN,
puisque les données peuvent être déchirées au niveau du serveur VPN, et rien ne l'empêche de les
conserver ce qui nuirait à notre sécurité. Cet élément est le plus important de tout VPN, car si la
condentialité de nos communications est compromise, le VPN pert toute son utilité. Donc, un VPN,
même de qualité, n'est pas nécessairement une garantie pour protéger votre vie privée.
Fonctionnement
Un VPN permet de construire un chemin virtuel entre deux machines, après avoir identié l'émet-
teur et le récepteur, en se basant sur un protocole de tunnelling, qui consiste à appliquer le processus
d'encapsulation, de transmission et de désencapsulation de données.
Concrètement, au niveau de l'émetteur, le protocole de tunnelling chire puis encapsule les données
en rajoutant une entête permettant le routage des trames dans le tunnel. Ensuite, les paquets sont
envoyés en empruntant le chemin virtuel. À l'autre extrémité du tunnel (au niveau du récepteur), les
données sont extraites du protocole de tunnelling et poursuivent leur chemin sous leur forme initiale.
5. VPN : Virtual Private Network

Un VPN permet de construire un chemin virtuel entre deux machines, après avoir identifié l’émetteur et le
récepteur, en se basant sur un protocole de tunnelling, qui consiste à appliquer le processus d’encapsulation,
de transmission et de désencapsulation de données.
Concrètement, au niveau de l’émetteur, le protocole de tunnelling chiffre puis encapsule les données en
rajoutant une entête permettant le routage des trames dans le tunnel. Ensuite, les paquets sont envoyés en
empruntant le chemin virtuel. À l'autre extrémité du tunnel (au niveau du recepteur), les données sont extraites
Classication
du protocole dedes VPN et poursuivent leur chemin sous leur forme initiale.
tunnelling
2.4.2. Classification
Comme des
il est illustré VPNla gure 3.5, deux classes courantes de VPN existent : les VPN d'accès
dans
à distance et les VPN de site à site.
Deux classes courantes de VPN existent : les VPN d’accès à distance et les VPN de site à site.
(a) Accès à distance (b) Site à site
Figure 3.5 Classes de VPN

VPN d’accès à distance : Cette classe de VPN, appelée aussi VPDN (Virtual Private Dial Up
Network), consiste à établir une liaison sécurisée permettant aux employés d’une entreprise de se
connecter au réseau privé de cette dernière, depuis divers sites distants en passant par un fournisseur
VPN d'accès à distance : Cette classe de VPN, appelée aussi VPDN (Virtual Private Dial
Up Network), consiste à établir une liaison sécurisée permettant aux employés d'une entreprise
de se connecter au réseau privé de cette dernière, depuis divers sites distants en passant par un
fournisseur de service. Ces utilisateurs peuvent accéder aux ressources sécurisées sur ce réseau
comme si elles étaient directement connectées aux serveurs du réseau.
Deux composants sont nécessaires dans un VPN d'accès distant : (1) Le premier est un serveur
6
de stockage en réseau (NAS ), également appelé passerelle multimédia, pouvant être un serveur
dédié ou un logiciel s'exécutant sur un serveur partagé. L'utilisateur distant qui se connecte au
NAS à partir d'Internet, doit fournir des informations d'identication valides pour se connecter
au VPN. Pour authentier l'utilisateur, le NAS utilise son propre processus d'authentication
ou un serveur d'authentication distinct s'exécutant sur le réseau ; (2) Le deuxième composant
est le logiciel client installé sur une machine distante, qui permet à l'utilisateur d'établir et
maintenir une connexion au VPN. La plupart des systèmes d'exploitation disposent d'un logiciel
intégré capable de se connecter à des VPN d'accès distant, bien que certains VPN nécessitent
l'utilisation d'une application tierce. Le logiciel client établit la connexion en tunnel avec le
NAS, et gère également le chirement requis pour maintenir la connexion sécurisée [62].
VPN de site-à-site : appelé aussi VPN routeur-à-routeur, il est principalement utilisé pour
des opérations commerciales sensible, en permettant aux bureaux situés dans plusieurs empla-
cements xes (sites) d'établir des connexions sécurisées entre eux sur un réseau public tel que
Internet. Cette classe de VPN étend le réseau de l'entreprise en rendant les ressources informa-
tiques d'un site à la disposition des employés d'autres sites [11]. Les mécanismes de routage, de
chirement et de déchirement sont eectués soit par du matériel informatique, soit grâce à un
logiciel situé des deux côtés. Les VPN de site-à-site peuvent être classés en :
VPN d'intranet : est un VPN entre les sites de la même entreprise, c'est-à-dire si une
entreprise possède un ou plusieurs sites distants et qu'elle souhaite les joindre dans un seul
réseau privé, elle peut créer un VPN intranet pour connecter chaque réseau local distinct à
un seul réseau étendu étanche ;
VPN d'extranet : est un VPN construit pour relier une entreprise à un partenaire ou
à un client distant. Lorsqu'une entreprise entretient des relations étroites avec une autre
entreprise (partenaire, fournisseur ou client), elle peut créer un VPN extranet qui connecte
les réseaux locaux de ces entreprises. Ce VPN extranet permet à ces entreprises de travailler
ensemble dans un environnement sécurisé et partagé.
6. NAS : Network Attached Storage

Protocoles utilisés par les VPN

De façon plus générale, les VPN peuvent être classés selon les protocoles, les services, et les types
de trac pouvant le traverser (couche 2 ou 3). De ce fait, il existe plusieurs types de VPN :
VPN de niveau 2 :
VPN PPTP (Point-to-Point Tunneling Protocol) : proposé par Microsoft, ce VPN
consiste à créer un tunnel de bout en bout dans le but de capturer les données. Généralement,
les VPN PPTP sont utilisés par des utilisateurs éloignés pour se connecter à leur réseau
VPN en utilisant leur connexion internet existante. Pour accéder au VPN, les utilisateurs s'y
enregistrent en utilisant une authentication. Les VPN PPTP n'ont pas besoin d'installer un
matériel supplémentaire et leurs fonctionnalités sont généralement oertes dans un logiciel
peu cher. Concrètement, la session client PPP est transportée de bout en bout dans une
encapsulation spécique GRE (Generic Routing Encapsulation). Les datagrammes peuvent
être chirés par le protocole MPPC (Microsoft Point-to-Point Encryption).
VPN L2TP (Layer 2 Tunneling Protocol) : développé par Microsoft et Cisco, les VPN
L2TP sont habituellement combinés à un autre protocole de sécurité VPN pour établir une
connexion plus sécurisée. Ce type de VPN forme un tunnel entre deux points de connexion
L2TP, et un second VPN comme le protocole IPsec chire les données et se concentre sur la
sécurisation des données entre les tunnels. Il est similaire au PPTP, du fait de leur manque
de chirement, et de leur fonctionnement avec un protocole PPP. Contrairement à PPTP,
L2TP consiste à protéger la condentialité et l'intégrité des données.
VPN L2F (Layer 2 Forwarding) : développé par Cisco, L2F est un tunnel opérateur
initialisé par le fournisseur d'accès à Internet (ISP) et se termine chez le client par un équi-
pement spécique. Ce protocole n'assure l'authentication de l'utilisateur qu'à la connexion.
Le tunnel L2F n'utilise pas le chirement, ce qui ne garantit pas la condentialité des don-
nées. Cependant, un chirement utilisateur de bout en bout peut être mis en ÷uvre, tel que
SSL/TLS.
VPN de niveau 3 :
VPN MPLS (Multi-Protocol Label Switching) : Ce type de VPN permet de créer un
réseau privé, qui ne transite pas sur Internet, ce qui élimine les risques d'intrusions et les
failles de sécurité. Le protocole MPLS permet également la gestion de la Qualité de service,
en dénissant la priorité à certains ux, tel que le streaming, au prot d'autres ux, comme
l'envoi d'emails ou le transfert de chiers. Concrètement, MPLS est paramétrée par un
seul opérateur qui supervise l'ensemble du réseau de l'entreprise et gère son infrastructure.
Toutefois, les VPN MPLS sont dicile à mettre en place et bien plus chers, par rapport aux
autres VPN.
VPN IPsec (Internet Protocol security) : IPsec est un protocole VPN constituant un
réseau public transitant par Internet. Il est destiné à sécuriser le protocole IP en vériant
chaque session et avec un chirement individuel des paquets de données pendant toute la
connexion. Il permet ainsi de protéger le transfert des données entre deux réseaux diérents.
IPsec opère selon deux modes : Transport et tunnel. Avec le mode transport, le message
dans le paquet de données est chiré. Avec le mode tunnel, le paquet de données entier est
chiré. Le principal avantage de IPsec, c'est qu'il peut être utilisé avec d'autres protocoles
de sécurité pour renforcer la sécurité. Cependant, Le VPN IPsec nécessite un équipement
dédié côté client. (Le lecteur pourra consulter le chapitre 5 pour plus de détails)
Les solutions IPsec et MPLS, permettent d'optimiser les coûts d'une entreprise et simplient
son infrastructure réseau. De plus, il est possible de mettre en place une architecture hybride
en permettant à l'entreprise de garantir la sécurité du réseau entre ses diérents sites en mode
privé avec MPLS, tout en proposant aux utilisateurs nomades une alternative pour accéder
aux données de l'entreprise de n'importe où, avec IPsec. La combinaison des deux solutions
nécessite une conguration poussée et coûtent assez cher mais sont très exibles.
VPN de niveau 4 :

VPN SSL/TLS (Secure Sockets Layer/Transport Layer Security) : SSL/TLS est

un protocole qui consiste à chirer de bout en bout des données applicatives échangées entre
deux machines sur un réseau. Il est principalement utilisé par des fournisseurs de service tels
que les sites de vente en ligne, en orant une session sécurisée entre le client (le navigateur
Web) et le serveur (le site Web). Ce protocole est généralement intégré par défaut dans
tous les navigateurs Web en maintenant à jour ses diérentes versions sans l'intervention de
l'utilisateur. La majorité des protocoles applicatifs orent une version sécurisée basée sur
SSL/TLS, par exemple HTTP et HTTPS. (Le lecteur pourra consulter le chapitre 6 pour
plus de détails)
Le choix du VPN est déterminé selon le niveau de sécurité que l'on souhaite viser, et selon la nature
et la taille du réseau. Par ailleurs, le coût total du déploiement du VPN entre également en compte
dans le choix.
3.4 Conclusion
Pour conclure, il n'y a pas une politique de sécurité unique, mais plusieurs architectures possibles
suivant ce que l'on veut protéger ou le niveau de sécurité que l'on veut atteindre. Le coût de déploie-
ment d'un pare-feu, les compétences nécessaires à la mise en ÷uvre, l'importance des informations
circulant sur le réseau privé d'une entreprise, sont autant d'éléments à prendre en considération avant
de concevoir une politique de sécurité. En eet, à travers ce chapitre, nous avons pu voir que l'on pou-
vait interdire l'accès aux réseaux privés et contrôler le ux sortant grâce au pare-feu, mais on pouvait
aussi y accéder à distance de manière sécurisée à travers les VPN.
Par ailleurs, Pr. Eugene Spaord, le fondateur et directeur du "Computer Operations, Audit and
Security Technology Laboratory", a très bien expliqué que la sécurisation d'un système informatique
ne peut jamais être assurée totalement : Le seul système informatique qui est vraiment sûr est un
système éteint et débranché, enfermé dans un blockhaus sous terre, entouré par des gaz mortels et des
gardiens hautement payés et armés. Même dans ces conditions, je ne parierais pas ma vie dessus .
Chapitre 4
Cryptographie appliquées
4.1 Introduction
La cryptographie est une discipline qui regroupe l'ensemble de procédés permettant de transformer
un message, dit en clair, en un autre message dit chiré, an de rendre celui-ci illisible. Avec la
cryptanalyse qui consiste à reconstruire un message chiré en clair à l'aide de méthodes mathématiques,
la cryptographie constitue la science de cryptologie .
Par ailleurs, le chirement d'un message est un procédé basé sur une clé
1 cryptographique dite
de chirement, qui rend sa compréhension impossible sans une clé de déchirement. Ce mécanisme
permet principalement de protéger les données transportées. D'après le principe de Kerckhos [40] [31],
la sécurité du système de chirement doit reposer uniquement sur le secret de la clé de chirement
et non sur celui de l'algorithme utilisé. Le principal but du chirement est de garantir les diérents
services de sécurité, telles que la condentialité, l'authenticité et l'intégrité des données.
Historiquement, jusqu'au début du 20ème siècle, la cryptographie n'a pas toujours joué un rôle
majeur, car la rapidité de transmission d'une information primait souvent sur son secret. Durant la
première guerre mondiale, les communications entre l'état-major et les troupes se faisaient essentiel-
lement par radio, ce qui permettait de communiquer rapidement sur une grande distance, mais ces
communications sont facilement interceptables par l'ennemi. Donc, des moyens de chirement basiques
ont été mis en ÷uvre, tels que les systèmes Ubchi et ABC, cependant ces derniers n'étaient pas très
ecaces car les messages pouvaient être décryptés à la main avec des méthodes mathématiques astu-
cieuses.
Durant la seconde guerre mondiale, une révolution technologique des méthodes cryptographiques a
émergé. Pour la première fois, les armées disposaient de moyens mécaniques qui permettent de conce-
voir des systèmes cryptographiques. En eet, pour leur coordination tactique, les troupes de l'armée
allemande s'échangaient de nombreux messages radios chirés à l'aide de la machine Enigma [41]. Mais,
une cryptanalyse d'Enigma a été réalisée et automatisée par le britannique Alan Turing, permettant
de décrypter les messages chirés par cette machine, ce qui a fait basculer la guerre en faveur des alliés.
C'était la naissance du premier ordinateur [67].
4.2 Formalisation des mécanismes de chirement

Mathématiquement, les diérents concepts de chirement sont formalisés comme suit [24] :
Chirement : M × 7→ K{M }K , l'opération de chirement consiste à produire un message
chiré {M }K en combinant le message en clair M et la clé de chirement, noté K,
Déchirement : {M }K × K −1 7→ M , l'opération de déchirement correspond à l'opération
inverse du chirement, en obtenant le message en clair M à partir du message chiré {M }K
ainsi que la clé de déchirement, noté K
−1 . La clé de déchirement K −1 sera égale à K dans le
1. Selon le dictionnaire de l'académie française, le mot Clé est l'orthographe moderne du mot clef , qui est
considéré comme plus ancien.
37
CHAPITRE 4. CRYPTOGRAPHIE APPLIQUÉES 38
cas de chirement symétrique, tandis que le chirement asymétrique se base sur une paire de
clés diérentes (K, K
−1 ),
Décryptage : {M }K 7→ M ou K , ce précédé consiste à retrouver le message en clair M ou la

clé de chirement K , en partant seulement du message chiré {M }K , c'est-à-dire sans avoir la
clé de déchirement K
−1 .
Chirement vs. Cryptage

Le mot "cryptage" n'existe pas dans la langue française : on dit chirer un message (c-à-d.
remplacer un caractère par un autre) ou coder le message (c-à-d. remplacer un mot par un
autre), mais on ne dit jamais crypter un message.

Depuis l'avènement du numérique, les paradigmes de chirement ont bien évolué. Le processus de
chirement s'est formalisé, même si la conception de système de chirement reste la même. Par ailleurs,
la forme
message chiffré s’est
du message diversifiée,
chiré ce qui a engendré
s'est diversiée, ce quilaaproposition
engendréd’algorithmes
la proposition d'algorithmes
modernes modernes
qui chiffrent des
suites dedes
qui chirent bits.suites
La figure bits. Ladécrit
de suivante gure le 4.1
principe d’une
décrit transmission
le principe sécurisée
d'une en utilisantsécurisée
transmission le chiffrement des
en utilisant
messages. des messages.
le chirement
Clé de Clé de
chiffrement déchiffrement
Msg en clair Msg chiffré Msg chiffré Msg en clair
X@d Canal sécurisé X@d

ns/à ns/à
Chiffrement Déchiffrement
Décryptage
Msg en clair ou Clé de déchiffrement
Figure
Il existe
4.1principalement
Principe detrois types d’algorithmes
la transmission cryptographiques
sécurisée des messages : en
(1) seLes algorithmes
basant simples de
sur le chirement
substitution, (2) les algorithmes de chiffrement symétriques, et (3) les algorithmes de chiffrement
Il asymétriques. Le choix du système
existe principalement cryptographique
trois types dépend
d'algorithmes des tâches à accomplir
cryptographiques pour
: (1) sécuriser
Les les données.
algorithmes simples
de substitution, (2) les algorithmes de chirement symétriques, et (3) les algorithmes de chirement
2. Algorithmes de substitution
asymétriques. Le choix du système cryptographique dépend des tâches à accomplir pour sécuriser les
données.
Le chiffrement par substitution, ou chiffrement simple, consiste à remplacer dans un message une ou plusieurs
entités par une ou plusieurs autres entités. Une entité peut être une lettre, un octet, ou une suite binaire [6].
4.3 Algorithmes de substitution
Plusieurs types de chiffrement par substitution existent, on peut citer :
Chiffrement monoalphabétique, consistant à remplacer chaque caractère du message par un autre
caractère,
Le chirement par substitution, ou chirement simple, consiste à remplacer dans un message une
ou plusieurs Chiffrement polyalphabétique,
entités par une utilisantentités.
ou plusieurs autres une suite
Une de chiffres
entité peutmonoalphabétique réutilisée
être une lettre, un octet, ou
périodiquement,
une suite binaire [27]. Plusieurs types de chirement par substitution existent, on peut citer :
Chirement monoalphabétique
Chiffrement homophonique, permettant de faireàcorrespondre
, consistant remplacer àchaque
chaque caractère
caractère dudu
message un
message par
ensemble possible d'autres caractères,
un autre caractère,
Chirement
Chiffrementpolyalphabétique
polygrammes, consistant à substituer un groupe de caractères dans le message par un
, utilisant une suite de chires monoalphabétique réutilisée
autre groupe de caractères.
périodiquement,
Chirement
Depuis l’antiquité,homophonique
les êtres humains ont essayé de proposer
, permettant descorrespondre
de faire mécanismes deàchiffrement, notamment
chaque caractère du dans
message
leun
domaine militaire.
ensemble Les algorithmes
possible de chiffrement simples sont catégorisés selon : (1) le décalage de lettres
d'autres caractères,
Chirement polygrammes, consistant à substituer un groupe de caractères dans le message
dans l’alphabet, par exemple, le chiffre de César, ou le chiffre de Vigenère ; et selon (2) le remplacement des
lettres par des symboles, tels que le code Morse, le code musical, ou l’alphabet des templiers.
par un autre groupe de caractères.
DepuisParmi les limiteslesduêtres
l'antiquité, chiffrement par substitution,
humains ont essayé ce dedernier se casse
proposer desfacilement,
mécanismes car les
delettres sont toujours
chirement, notam-
ment codées
dans lededomaine manière. EnLes
la même militaire. effet, l’assaillant qui
algorithmes de ne possède quesimple
chirement le message
sont chiffré, peut réaliser
catégorisés selon une
: (1) le
cryptanalyse de la fréquence de chaque symbole ou chaque groupe de symboles pour en extraire le message en clair.
3. Algorithmes de chiffrement symétrique

Le chiffrement symétrique, également appelé chiffrement à clés secrètes, permet à la fois de chiffrer et de
Algorithme Propriétaire Sortie Taille de la clé Description

DES IBM 1975 56 bits Cassé aujourd'hui
RC4 Rivest 1987 1 à 2048 bits Certaines clés sont faibles
IDEA Massey et Xuejia 1991 128 bits Ecace mais breveté
Blowsh Shneier 1993 1 à 448 bits Vieux et lent
RC5 Rivest 1994 128 à 256 bits Ecace mais breveté
Serpent Anderson et al. 1997 128 à 256 bits Très fort
Triple DES IBM 1999 112 ou 168 bits Second meilleur choix
Twosh Shneier et al. 2000 128 à 256 bits Très fort, largement utilisé
AES Rijndael et al. 2000 128 à 256 bits Meilleur choix, très utilisé
Table 4.1 Principaux algorithmes de chirement symétrique
décalage de lettres dans l'alphabet, par exemple, le chire de César, ou le chire de Vigenère ; et selon
(2) le remplacement des lettres par des symboles, tels que le code Morse, le code musical, ou l'alphabet
des templiers.
Parmi les limites du chirement par substitution, ce dernier se casse facilement, car les lettres sont
toujours codées de la même manière. En eet, l'assaillant qui ne possède que le message chiré, peut
réaliser une cryptanalyse de la fréquence de chaque symbole ou chaque groupe de symboles pour en
extraire le message en clair.
4.4 Algorithmes de chirement symétrique

Le chirement symétrique, également appelé chirement à clés secrètes, permet à la fois de chirer
et de déchirer des messages à l'aide d'une même clé, dite clé secrète. Ce type de chirement est une
extension moderne du chirement simple, mais en utilisant des algorithmes basés essentiellement sur
une clé, car toutes les méthodes de chirement simple n'utilisent pas de clé. Donc, avant l'envoi du
message chiré, l'expéditeur du message doit préalablement fournir au destinataire la clé secrète de
chirement. Les algorithmes de chirement symétrique sont principalement classés en deux catégories :
Algorithmes de chirement par bloc (Block cipher) : Ce type d'algorithme opère sur le
message en clair par blocs de n bits, c'est-à-dire, il prend n bits en entrée, pour les chirer en n
bits en sortie. Généralement, le découpage des données en blocs est de taille xe. Cette dernière
est comprise entre 32 et 512 bits, mais depuis 2000, le standard est de 128 bits.
Depuis 2012, le plus ancien algorithme symétrique DES qui est basé sur des clés codées sur 56
bits, peut être cassé en moins de 26 heures. De ce fait, DES a été remplacé par des algorithmes
plus résistants, tels que AES, Triple DES et Blowsh.
Algorithmes de chirement par ot (Stream cipher) : Le chirement par ot consiste à
chirer les messages de longueur variable et n'a pas besoin de les découper en blocs. En eet,
les messages sont traités bit par bit en se basant sur le modèle du chire de Vernam [5]. Les
algorithmes les plus courants sont : RC4, A5/1 et RC5.
Remarque :
Le chirement par bloc peut être converti en un chirement par ot grâce à un mode opératoire
qui permet de chaîner plusieurs blocs et traiter des données de taille variable.
La table 4.1 décrit les principaux algorithmes de chirement symétrique utilisés à ce jour.
Le principal avantage des algorithmes de chirement symétrique est leur temps de calcul qui est
nettement plus courts par rapport à leurs concurrents (algorithmes de chirement asymétrique). Ce-
pendant, ils possèdent les limites suivantes :
Longueur de la clé secrète : Selon Shannon (1940) [57], les systèmes de chirement symé-
trique doivent utiliser des clés d'une longueur au moins égale à celle du message à chirer, pour
résister à toutes les attaques par force brute ;

Echange de la clé secrète : Le chirement symétrique impose d'avoir un canal sécurisé pour
l'échange de la clé, ce qui diminue sérieusement l'intérêt d'un tel système de chirement ;
Nombres de clés : Sachant qu'une clé est nécessaire pour chaque échange, pour un groupe
de N utilisateurs s'échangeant entre eux, il est nécessaire de distribuer de manière sécurisée
N*(N-1)/2 clés secrètes.
Téléphone rouge :
Pendant la guerre froide (1963-1990), les diplomates russes et américains prenaient l'avion avec
des valises contenant des cassettes de clés symétriques dans le but de les échanger dans les ambas-
sades. Ces clés servaient à chirer les communications téléphoniques entre les deux nations, c'est
ce qu'on appelais autrefois le téléphone rouge . La clé était changée à chaque communication
et détruite lorsque celle-ci était terminée.
4.5 Algorithmes de chirement asymétrique

Le chirement asymétrique, ou le chirement à clés publiques, consiste à utiliser une paire compo-
sée d'une clé publique, servant au chirement d'un message, et d'une clé privée, servant à le déchirer.
En pratique, le principal rôle d'un algorithme de chirement asymétrique est de générer la paire de clés
publique/privée pour chaque utilisateur. Ensuite, les utilisateurs s'échangent leurs clés publiques res-
pectives au travers d'un canal pas forcément sécurisé. Lorsqu'un utilisateur désire envoyer un message
à un autre utilisateur, il lui sut de chirer le message au moyen de la clé publique du destinataire.
Ce dernier sera en mesure de déchirer le message à l'aide de sa clé privée, qu'il est seul à connaître.
L'interêt de cette décomposition publique/privée réside dans l'impossibilité calculatoire de déduire
la clé privée à partir de la clé publique, c'est-à-dire que les moyens de calcul disponibles et les méthodes
connues actuellement ne le permettent pas. C'est grâce à ce facteur que l'écosystème des crypto-
monnaies a choisi la cryptographie asymétrique pour protéger les transactions et les porte-monnaies
des utilisateurs, mais aussi pour préserver l'intégrité des blockchains.
De plus, le chirement asymétrique permet d'éviter le problème de la nécessité de la transmission
sécurisée de la clé de déchirement, car pour un groupe de N utilisateurs, il ne faut distribuer que N clés
publiques et de manière non sécurisée, ce qui est intéressant par rapport aux approches de chirement
symétrique. Par ailleurs, les algorithmes asymétriques permettent aussi la signature électronique des
données et des documents.
Actuellement, deux principaux algorithmes de chirement asymétrique sont utilisé :
Chirement RSA : Considéré comme le premier algorithme de cryptographie asymétrique,
RSA du nom de ses créateurs, Rivet, Shamir, et Adleman, a été proposé en 1978 dans [54].
Actuellement, RSA est le système cryptographique le plus utilisé de nos jours puisqu'il a survécu
à toutes les attaques pendant plus d'un quart de siècle. La abilité de cet algorithme repose
sur la diculté de résoudre un problème mathématique très complexe, dit de factorisation ,
2
nécessitant beaucoup d'opérations et un espace mémoire volumineux. En pratique, il est basé sur
la diculté de factoriser un grand nombre (généralement un nombre à 100 chires) en produit
de deux grands facteurs premiers [28].
En eet, le meilleur algorithme à ce jour peut factoriser des nombres de 150 bits, mais sa
complexité combinatoire est très grande. Donc, plus les nombres premiers choisis sont grands,
plus le système sera sécurisé. Actuellement, on estime que le plus rapide ordinateur que l'on
puisse construire utilisant la meilleure méthode exhaustive connue met plus de 1000 ans pour
retrouver la clé privée d'un système RSA utilisant une clé de 1024 bits.
2. En mathématiques, la factorisation consiste à écrire une expression algébrique, un nombre ou une matrice sous la
forme d'un produit.
Chirement ElGamal : L'algorithme El Gamal fut présenté par T. ElGamal en 1985 dans [19].
Il est moins résistant que RSA entre termes de abilité contre les attaques, et son fonctionnement
est deux fois plus lent. Actuellement, il est utilisé dans certains logiciels libres de messagerie.
Comme pour RSA, la construction des deux clés est basée sur les nombres premiers. En eet,
la sécurité du système ElGamal repose sur la diculté de calculer la clé secrète. Cette opéra-
tion revient à retrouver une valeur à partir d'une formule logarithmique complexe, connu sous
le nom de calcul du logarithme discret [15]. Ce dernier est résoluble en se basant sur une re-
cherche exhaustive mais nécessite un temps relativement long. À l'heure actuelle, il n'existe pas
d'algorithme à complexité polynomiale eectuant cette opération.
Les limites auxquelles sourent les algorithmes de chirement asymétrique, sont :
Longueur des clés : Pour des raisons de robustesse, les algorithmes asymétriques nécessitent
de plus en plus de clés publiques plus longues (actuellement, on utilise des clés RSA de 1024
bits),
Vulnérabilité du chirement : par sa nature mathématique, la cryptographie asymétrique
est plus vulnérable par rapport à la cryptographie symétrique,
Performance de l'algorithme : les algorithmes à clés publiques sont plus complexes donc
plus lents que ceux à clés secrètes, qui tournent eux jusqu'à près de 1000 fois plus vite.
4.6 Problèmes liés au chirement asymétrique

4.6.1 Problème de la longueur des clés
Actuellement, les algorithmes asymétriques se basent de plus en plus sur des clés plus longues pour
chirer les messages, an d'assurer leur abilité. De ce fait, de nouvelles techniques cryptographiques
ont émergé, telle que la cryptographie sur les courbes elliptiques (en anglais, Elliptic Curve Cryptogra-
phy ECC). Apparu en 2006 (RFC 4492), cette nouvelle cryptographie est une rupture mathématique
par rapport aux algorithmes précédents, malgré sa théorie et son implémentations plus complexes. En
eet, elle permet de réduire considérablement la taille des clés cryptographiques, et par conséquent le
calcul, tout en maintenant un niveau de sécurité équivalent. Par exemple, une clé ECC d'une taille de
160 bits est considérée comme plus sûre qu'une clé RSA d'une taille de 1024 bits.
4.6.2 Problème de la performance

Sachant que les algorithmes asymétriques sont plus lents que ceux qui sont symétriques, et re-
quièrent une taille des clés beaucoup plus longue, une solution hybride consiste à créer une clé de
session symétrique, utilisé pour l'échange sécurisé des messages, après que l'expéditeur transmet cette
clé de session en la chirant, de manière asymétrique avec la clé publique du destinataire. Il reste alors
au destinataire de déchirer la clé de session grâce à sa clé privée an de l'utiliser pour déchirer le
message original. De plus, une clé symétrique de session AES étant nettement plus petite (256 bits)
qu'une clé asymétrique RSA (1024 bits), on a les avantages de la rapidité et la robustesse de l'algo-
rithme de chirement symétrique AES avec les avantages du canal sécurisé du chirement asymétrique
en utilisant RSA.
4.6.3 Problème de l'échange de clés

La transmission d'une clé de session dans un canal sécurisé asymétriquement est une bonne solution
en termes de performance, cependant, la même paire de clés publique/privée est utilisée à la fois pour
authentier le destinataire et chirer la clé de session symétrique envoyée à celui-ci. Par conséquent,
toute la sécurité des échanges repose sur le secret de la clé privée, qui permet de déchirer la clé
de session. En eet, si un assaillant obtient la clé privée et écoute l'échange, il peut alors déchirer
l'ensemble de la session. Pire, même si un assaillant n'a actuellement pas réussi à obtenir la clé privée,
il peut quand même enregistrer la session chirée et la déchirer ultérieurement, une fois que la clé
privée est obtenue.
De ce fait, l'utilisation du chirement asymétrique pour transmettre une clé de session symétrique
est actuellement dépréciée. Une autre méthode d'échange de clés a été proposée par Whiteld Die
et Martin Hellman, en 1976. Cette méthode, dite d'échange de clés Die-Hellman, permet à deux
interlocuteurs, de négocier un secret partagé sans le communiquer explicitement lors de la négociation.
La clé privée du destinataire est utilisée pour signer et vérier la négociation, mais la clé de session
n'est jamais échangée. Comme pour l'algorithme ElGamal, La sécurité de l'algorithme Die-Hellman
réside dans la diculté de résoudre un problème du logarithme discret (Pour plus de détail, le lecteur
peut consulter le cours de Cryptographie et Sécurité de l'Information (CRSI)).
Mieux encore, pour réduire le risque de compromission des sessions précédentes, il est possible de
générer une nouvelle clé symétrique, dite "éphémère", à chaque nouvelle session et ignorer ainsi les clés
précédentes. Par conséquent, comme les clés éphémères ne sont jamais échangées et sont renégociées
pour chaque nouvelle session, le pire des cas est qu'un assaillant pourrait obtenir la clé éphémère d'une
session en cours, ce qui lui permet de déchirer uniquement les échanges de celle-ci. À cet eet, avec
la clé éphémère actuelle obtenue, l'assaillant ne pourrait déchirer ni les échanges précendents, ni ceux
qui sont futurs.
Actuellement, la combinaison de l'échange de clés Die-Hellman et des clés de sessions éphémères,
est le mécanisme le plus utilisé pour sécuriser les échanges sur Internet. Ce mécanisme permet d'assurer
la propriété du secret de transfert parfait, dite PFS (Perfect Forward Secrecy).
4.6.4 Problème de l'authentication de l'expéditeur

Un inconvénient majeur de l'utilisation des mécanismes de chirement asymétriques est le fait que
la clé publique est distribuée à tout le monde, c'est-à-dire, tout destinataire qui déchire un message
reçu, n'a aucun moyen de vérier avec certitude l'identité de l'émetteur de ce message. L'assaillant
peut donc facilement usurper l'identité de l'expéditeur présumé. Ce problème est connu sous le nom
de l'authentication.
Pour assurer l'authentifacation des entités communicantes dans un réseau, une solution intuitive
consisterait à utiliser des mots de passe pour prouver l'identité de l'expéditeur, mais, non seulement les
mots de passe sont généralement courts et facilement devinables, ils requièrent un canal sécurisé pour
les transmettre. An de résoudre ce problème, des mécanismes d'authentication basés sur la signature
numérique, permettant de garantir la provenance des messages chirés, peuvent être appliqués.
En eet, la signature numérique est utilisée essentiellement pour garantir l'authenticité de l'ex-
péditeur du message, par analogie avec la signature manuscrite d'une lettre postale. En pratique, les
mécanismes de signature numérique sont fondés sur la cryptographie asymétrique, dont le principe est
le suivant :
À l'envoi du message en clair, l'expéditeur le chire doublement : (1) Il signe le message
en clair en le chirant avec sa clé privée ; Ensuite, (2) il chire son message signé avec la clé
publique du destinataire ; et enn, (3) il envoie le message chiré au destinataire.
À la réception du message chiré, le destinataire déchire le message reçu : (1) Sachant
qu'il est le seul en mesure de le déchirer en utilisant sa clé privée, il obtient alors un message
signé par l'émetteur. Ensuite, (2) pour vérier la signature de l'émetteur, le destinataire déchire
le message signé avec la clé publique de l'expéditeur. Par ce moyen, le destinataire peut avoir
la certitude que l'émetteur du message est son expéditeur présumé. Dans le cas contraire, le
message est indéchirable et le destinataire pourra constater qu'un assaillant a tenté de lui
envoyer un message en se faisant passer pour l'expéditeur.
Cette méthode d'authentication se base sur la spécicité de la paire de clés asymétriques qui
s'annullent mutuellement, c'est-à-dire si l'on chire un message en utilisant la clé publique, alors on
peut le déchirer en utilisant la clé privée. L'inverse est aussi possible ; si l'on chire le mesage en
utilisant la clé privée alors on peut le déchirer en utilisant la clé publique.
Par ailleurs, pour assurer l'intégrité d'un message, une solution consisterait à générer une empreinte
numérique (ou message digest) à partir du message, en utilisant une fonction de hachage . Cette
3
3. Hachage : Ce mot est utilisé par analogie avec la cuisine, qui signie la segmentation désordonnée des aliments.
dernière est une fonction à sens unique permettant de calculer une chaine de caractères xe, appelée
empreinte numérique, à partir d'une donnée de taille arbitraire. l'intérêt de ce mécanisme est le fait
qu'il est pratiquement impossible à inverser, c'est-à-dire récupérer la donnée à partir de l'empreinte
numérique. Les algorithmes les plus utilisés actuellement sont : MD5, SHA1, et SHA-256.
Cas d'usage des fonctions de hachage :
La Sécurité
fonctiondes de hachage est principalement
réseaux utilisée– dans
2018-2019 les2 cas suivants :
Semestre Université Constantine 2

Cas d’usage des fonctions de hachage
La signature numérique des documents électroniques et des messages échangés,
fonction
La Le stockage sécurisé
de hachage des mots deutilisée
est principalement passe dans
danslesles
casbases de :données,
suivants
La vérication de l'intégrité des certicats et des paquets réseaux,
Cas d’usagenumérique
La signature des fonctions de hachage
des documents électroniques et des messages échangés,
La création d'une blockchain (le lecteur peut consulter le module ALDA M2 RSD, pour
La plusLe stockage
fonction sécurisé
estdes mots de passe dans les bases de données,
de de hachage
détails). principalement utilisée dans les cas suivants :
La vérification de l’intégrité des certificats et des paquets réseaux,
La signature numérique des documents électroniques et des messages échangés,
La création d’une blockchain (le lecteur peut consulter le module ALDA – M2 RSD, pour plus de détails).
En pratique, Le stockage sécurisé des
la combinaison des mots de passe dans
mécanismes deles bases de données,
l'empreinte et de signature numériques fournit un
En pratique,
moyen Lalavérification
très ecace combinaison dedes
pour garantirl’intégrité
mécanismes
l'intégrité de l’empreinte
des certificats et des et de signature
et l'authenticité
paquets numériqueséchangés.
des messages
réseaux, fournit un moyen très
Concrètement,
pourefficace
envoyer pour garantir l’intégrité et l’authenticité des messages échangés. Concrètement, pour
La création d’une blockchain (le lecteur peut consulter le module ALDA – M2 RSD, pour plus de détails).
un message signé, l'expéditeur doit suivre les étapes suivantes : envoyer un
message signé, l’expéditeur doit suivre les étapes suivantes :
1.EnUne empreinte
pratique, numérique,
la combinaison est généréede
des mécanismes à l’empreinte
partir du message en utilisant
et de signature numériquesun algorithme de hachage,
fournit un moyen très
1) Une
par
empreinte
exemple
numérique,
SHA-256 ;
est générée à partir du message en utilisant un algorithme de hachage, par
efficace pour garantir l’intégrité et l’authenticité des messages échangés. Concrètement, pour envoyer un
exemple SHA-256 ;
2.message signé, l’expéditeur
Cette empreinte doit suivre
est signée à l'aideles étapes
de la suivantes
clé privée : de l'expéditeur ;
2) Cette empreinte est signée à l'aide de la clé privée de l'expéditeur ;
3. Le3)1)message
LeUne empreinte
messageest est numérique,
joint par
joint parson
sonest générée à partir
empreinte
empreinte signée,
signée,dupour
message
pourêtre en
être utilisant
chiré
chiffré un
en en algorithme
utilisant
utilisant depublique
la cléla hachage,
clé par du
publique
du
exemple
destinataire. SHA-256
destinataire. ;
2) Cette empreinte est signée à l'aide de la clé privée de l'expéditeur ;
3) Le message est joint par son empreinte Exp signée, pour être chiffré en Destutilisant la clé publique du
destinataire.
Exp Dest
Hachage Chiffrement Chiffrement
Expéditeur Message Empreinte Signature Message Destinataire
numérique numérique Message
chiffré
signé
Hachage Chiffrement Chiffrement
À la réception du message,Figure
Expéditeur Message Empreinte Signature Message Destinataire
le 4.2 Signature
destinataire numérique
suivantes : des messages
Message
numérique suit les étapes
numérique chiffré
signé
1) À l’aide de sa clé privée, il déchiffre le message ;
À la réception du message, le destinataire suit les étapes suivantes :
2) réception
À la Afin de prouver l'identité
du message, de l'expéditeur,
le destinataire l’empreinte
suit les du message
étapes suivantes : est extraite de l'empreinte signée qui
1. À l'aide de sa cléleprivée,
a accompagné message,il en déchire le clé
utilisant la message
publique ; de l’expéditeur ;
3)1) En
2. An
À l’aide delesamême
deutilisant
prouver
clé privée,
l'identité
il
algorithmedéchiffre le message
de hachage,
de l'expéditeur,
;
ill'empreinte
génère une empreinte
du message à partir
estduextraite
message reçu, pour
de l'empreinte
2) être comparée
Afin de prouveravec l’empreinte
l'identité de signée.
l'expéditeur,Si l’empreinte
les deux du message
empreintes
signée qui a accompagné le message, en utilisant la clé publique de l'expéditeur ;
est
sont extraite de
identiques, l'empreinte
cela signée
signifie que qui
le
a accompagné
message le message,
est intègre et n'a pasenété altéré. la clé publique de l’expéditeur ;
utilisant
3. En utilisant le même algorithme de hachage, il génère une empreinte à partir du message reçu,
3) En utilisant le même algorithme de hachage, il génère une empreinte à partir du message reçu, pour
pour être comparée
être comparée avecavec l'empreinte
l’empreinte signée.
signée. Si lesSideuxles empreintes
deux empreintes sont identiques,
sont identiques, cela signifiecela
quesignie
le
que lemessage
messageest est intègre
intègre et n'a et
pasn'a
été pas été altéré.
altéré. Hachage
Dest
Message
Hachage
Dest
Déchiffrement ?
Comparaison
Déchiffrement Message
Signature Empreinte
Destinataire Message Message numérique
chiffré signé
Exp numérique
Déchiffrement ?
Comparaison
Déchiffrement
Signature Empreinte
Destinataire Message Message numérique numérique
4.5. Problème du Man-in-the-middle
chiffré Exp
signé
Le chiffrement de bout en bout consiste à transférer des données en toute sécurité entre les extrémités de la
communication.
4.5. Problème Figure
Cependant, au lieu d'essayer de casser le chiffrement (c’est-à-dire la clé de déchiffrement), un
du Man-in-the-middle
4.3 Vérication de la signature numérique des messages
assillant pourrait usurper l'identité du destinataire du message, par substitution de la clé publique du
Le chiffrement de bout en bout consiste à transférer des données en toute sécurité entre les extrémités de la
communication. Cependant, au lieu d'essayer de casser le chiffrement (c’est-à-dire la clé de déchiffrement), un
assillant pourrait usurper l'identité du destinataire du message, par substitution de la clé publique du
4.6.5 Problème du Man-in-the-middle

Le chirement de bout en bout consiste à transférer des données en toute sécurité entre les extré-
mités de la communication. Cependant, au lieu d'essayer de casser le chirement (c'est-à-dire la clé
de déchirement), un assillant pourrait usurper l'identité du destinataire du message, par substitution
de la clé publique du destinataire par la sienne. Après le déchirement du message, l'assaillant pour-
rait chirer le message de nouveau avec la clé publique du destinataire réel, et lui envoyer le message
pour éviter la détection de l'intrusion. Ceci est connu sous le nom de l'attaque de l'homme du milieu
(Man-in-the-middle).
Les protocoles de chirement de bout en bout incluent un sous-protocole d'authentication des en-
tités communicantes, pour prévenir les attaques de l'homme du milieu. La meilleure solution actuelle
consiste à se er à un tiers de conance, qui atteste l'identité des interlocuteurs d'une communication,
par le biais de certicats numériques. En eet, la cryptographie asymétrique se base sur les certi-
cats pour éviter les problèmes d'usurpation d'identité à travers l'utilisation de fausses clés publiques.
Aujourd'hui, c'est la technique utilisée pour sécuriser les échanges sur Internet.
4.7 Certicats
La garantie qu'une clé publique provient bien de l'entité qu'elle prétend être, s'eectue via un cer-
ticat numérique d'authenticité attesté par un tiers de conance, appelé autorité de certication. Les
certicats interviennent principalement dans le processus de chirement à clé publique des messages et
dans le processus de signature des documents électroniques. La cryptographie asymétrique est égale-
ment utilisée pour créer le certicat, celui-ci contenant la clé publique de l'entité associée. La clé privée
étant condentielle à l'entité, elle est stockée exclusivement au niveau de celle-ci.
Par exemple, pour sécuriser un serveur Web sur Internet, l'autorité de certication consiste à lui
générer à sa demande, un certicat signé par celle-ci contenant sa clé publique. Après l'attribution du
certicat, l'autorité de certication va certier à tout demandeur (par exemple le client Web) que la
clé publique appartient bien à celui qui le prétend, c'est-à-dire le serveur Web.
4.7.1 Dénition d'un certicat

Un certicat numérique (ou électronique) est un document publique utilisé pour attester le lien
entre une identité physique et son entité numérique, en lui associant une clé publique. Cette entité
numérique peut correspondre à un individu, à un serveur, à une entreprise ou à toute autre entité sur
le réseau. Concrètement, le certicat est un petit chier contenant la clé publique de l'entité à certier
et signé par la clé privée du certiant, c'est-à-dire l'autorité de certication. La structure du chier est
normalisée par l'un des 2 formats les plus utilisés aujourd'hui, X.509 ou OpenPGP. Pour la délivrance
d'un certicat auprès d'une autorité de certication, le demandeur doit :
Se présenter physiquement à l'autorité de certication ;
Prouver son identité avec un justicatif gouvernemental (par exemple, une pièce d'identité) ;
Fournir une adresse email valide.
Grâce aux chirement et signature, les certicats servent à garantir les principaux services de sécu-
rité : la condentialité, l'authentication, l'intégrité, et la non-répudiation. L'ensemble des techniques
et méthodes de certication est, généralement, regroupé dans un organisme appelé infrastructure à clé
publique.
4.7.2 Infrastructure à clé publique (PKI)

À travers un ensemble de services, l'infrastructure à clé publique (en anglais, Public Key Infrastruc-
ture PKI), permet de gérer le cycle de vie des certicats (et par conséquent, celui des clés publiques) et
d'en assurer la abilité. Elle est constituée d'équipements matériels (machines, équipements cryptogra-
phiques, ...), des logiciels (systèmes d'exploitation et applications), ainsi que des ressources humaines
(pour la vérication manuelle des demandes de certicats).
Il existe plusieurs modèles et implémentations possibles de PKI : (1) une hiérarchie d'autorités
de certication, (2) une toile de conance, ou en utilisant (3) une certication décentralisée basée
sur une blockchain. L'implémentation de PKI la plus utilisée actuellement est celle où les éléments
sont organisés hiérarchiquement. Dans ce cas, la PKI est essentiellement composée d'une ou plusieurs
autorités de certication, d'une autorité d'enregistrement, et d'une autorité de dépôt :
Une autorité de certication (Certicate Authority CA), étant le composant décision-
nel du processus de certication, c'est une autorité morale qui consiste à créer des certicats en
dénissant leurs règles et modalités d'attribution. Cette autorité a pour rôle principal de gérer
le cycle de vie des certicats, en déterminant notamment leur durée de validité.
Une autorité d'enregistrement (Registration Authority RA), est l'entité servant
d'interface entre l'utilisateur et l'autorité de certication. En eet, elle est chargée de recueillir,
d'enregistrer et de vérier les demandes de certicats après avoir contrôler l'identité du deman-
deur en s'assurant que les règles d'attribution des certicats soient respectées. Après avoir rempli
toutesdes
Sécurité lesréseaux
modalités, la RA procède à2018-2019 – Semestrede
la récupération 2 la clé publiqueUniversité
auprès du demandeur.
Constantine 2
Une autorité de dépôt (Repository), est une entité ayant pour tâche de publier et d'organi-
ser les certicats émis par la CA, en les mettant à la disposition des utilisateurs. La publication
Une autorité de dépôt (Repository), est une entité ayant 4pour tâche de publier et d’organiser les
des certicats est faite en utilisant le protocole LDAP , et la liste des certicats expirés ou
certificats émis par la CA, en les mettant à la disposition des utilisateurs.5 La publication des certificats
révoqués est regroupée dans la structure
est faite en utilisant le protocole LDAP1, etdela données signée CRL . Par ailleurs, la vérication
liste des certificats expirés ou révoqués est regroupée
en ligne
dansdu statut d'un
la structure certicat
de données signéepeut
CRL2.seParfaire à travers
ailleurs, des requêtes/réponses
la vérification en ligne du statut d’undu protocole
certificat
6 . se faire à travers des requêtes/réponses du protocole OCSP3.
OCSPpeut
Les étapes du processus de certication sont illustrées dans la gure 4.4 :
Les étapes du processus de certification sont illustrées dans la figure suivante :
Envoi du
certificat
5
Utilisateur A Utilisateur B
7
Envoi de
messages 6 Contrôle de
Demande de 1 4 Attribution du chiffrés validité du
certificat certificat certificat
Autorité 3
Autorité de dépôt
d’enregistrement (RA) (Repository)
Publication du CRL
certificat
Validation du 2
certificat
Autorité de
certfication (CA)
Figure
Etant l’élément le plus important dans 4.4
unePKI, l’autoritédedecertication
Processus certification (CA) est le tiers de confiance
responsable de délivrer les certificats en mettant à la disposition de quiconque, le moyen de vérifier la validité
Étant
de cesl'élément
certificats le plusa fournis.
qu'elle important dans une PKI, l'autorité de certication (CA) est le tiers de
conance responsable de délivrer les certicats en mettant à la disposition de quiconque, le moyen de
Les services d’une PKI sont principalement utilisés via le protocole SSL/TLS pour sécuriser les
vérier la validité de ces certicats qu'elle a fourni.
communications Web (HTTPS) ou pour sécuriser les échanges par email (SMTP-TLS, SPOP3, et IMAPS).
Les services d'une PKI sont principalement utilisés via le protocole SSL/TLS pour sécuriser les
Par ailleurs, ils sont utilisés aussi pour la sécurisation des documents électroniques, par exemple au moyen de
communications Web (HTTPS)
signatures électroniques avancéesoutelles
pour quesécuriser
PAdES pour les des
échanges parPDF,
documents email (SMTP-TLS,
ou via SPOP3, et
le protocole S/MIME
IMAPS). Par ailleurs,
pour les emails. ils sont utilisés aussi pour la sécurisation des documents électroniques, par
exemple au moyen de signatures électroniques avancées telles que PAdES pour des documents PDF,
3. Certificats X.509
ou via le protocole S/MIME pour les emails.
4. LDAP : Lightweight
Le format Directory
de certificats X.509,Access créé et recommandé par l’ITU4 en 1988 et la version 3 est la version
a été Protocol.
5. CRL : Certicate
actuelle Revocation
depuis 1996, List.les versions antérieures sont toujours utilisées. Ayant fait l'objet de plusieurs
mais toutes
6. OCSP
RFC, :actuellement,
On-line Certicate Status
X.509 est Protocol.
le format de certificat le plus répandu sur Internet, car il repose sur un système
hiérarchique d'autorités de certification, à l'inverse de la toile de confiance d’OpenPGP, où n'importe qui peut
signer les certificats d'autrui. En outres, X.509 se base sur un algorithme robuste pour la validation de la chaine
de certification, avec la possibilité d’établir des listes de révocation de certificats.
4.8 Certicats X.509

Le format de certicats X.509, a été créé et recommandé par l'ITU
7 en 1988 et la version 3 est
la version actuelle depuis 1996, mais toutes les versions antérieures sont toujours utilisées. Ayant fait
l'objet de plusieurs RFC, actuellement, X.509 est le format de certicat le plus répandu sur Internet,
car il repose sur un système hiérarchique d'autorités de certication, à l'inverse de la toile de conance
d'OpenPGP, où n'importe qui peut signer les certicats d'autrui. En outres, X.509 se base sur un
algorithme robuste pour la validation de la chaine de certication, avec la possibilité d'établir des listes
de révocation de certicats.
4.8.1 Structure d'un certicat

Chaque certicat de type X.509 comprend une section données et une section signature . Il
contient essentiellement les informations suivantes :
Version de la norme X.509 (0 pour la version 1, 1 pour la version 2 et 2 pour la version 3),
Numéro de série (unique pour chaque certicat),
Nom de l'émetteur (PKI),
Clé publique du propriétaire,
Renseignements sur le propriétaire de la clé publique (nom, localisation, adresse email, ...),
Algorithme de chirement de la clé publique (RSA, ...),
Objet de l'utilisation de la clé publique,
Période de validité du certicat (Début et n de validité),
Liste des extensions (optionnel, à partir de X.509v3)
Signature de la PKI émettrice du certicat (construite à partir de la clé privée du PKI),
Algorithme de hachage utilisé pour la signature du certicat (MD5, DSA, ...),
Voici un exemple de certicat X.509 v3 :
certificat.crt
1 Certificate :
2 Data :
3 Version : 3 (0 x2 )
4 Serial Number : fb : eb : a1 : e7 :87: a6 :28: bc
5 Signature Algorithm : sha256WithRSAEncryption
6 Issuer : C = DZ , ST = Constantine , L = Constantine , O = University , [...]
7 Validity
8 Not Before : Sep 5 13:01:21 2019 GMT
9 Not After : Sep 4 13:01:21 2020 GMT
10 Subject : C = DZ , ST = Constantine , L = Constantine , O = University , [...]
11 Subject Public Key Info :
12 Public Key Algorithm : rsaEncryption
13 Public - Key : (2048 bit )
14 Modulus :
15 00: c2 :28:6 c : bc :1 c :4 e :47:26: b9 : a4 :25: f9 :62:0 d : c4 :87:80:1 a : bb [...]
16 X509v3 extensions :
17 X509v3 Subject Key Identifier :
18 E8 : A1 :2 B :88:39:33:84:2 E :9 D : B5 :13: E8 : BA :78:00:40:71:68:6 E : CD
19 X509v3 Authority Key Identifier :
20 keyid : E8 : A1 :2 B :88:39:33:84:2 E :9 D : B5 :13: E8 : BA :78:00:40:71:68:6 E : CD
21 X509v3 Basic Constraints : critical
22 CA : TRUE
23 Signature Algorithm : sha256WithRSAEncryption
24 4 a :80:5 a :1 b :5 d : fc :02:23: a3 :3 d :4 c :7 d : cc :5 b :1 c :4 e :14:1 b :3 d :43: db :4 d : [...]
7. ITU : International Telecommunications Union.

4.8.2 Cycle de vie d'un certicat

Un certicat est accordé pour une durée limitée et peut être remis en question dans la période de
Sécurité
validité, pour desdes
réseaux
raisons de sécurité ou à la volonté– Semestre
2018-2019 2
du demandeur. Université
La gure Constantine
4.5 illustre 2 de
le cycle
vie d'un certicat depuis sa demande jusqu'à son expiration.
Demande Génération
Authentification
de certficat du certificat
Renouvellement
Expiration Exploitation Remise au

du certificat du certificat demandeur
Révocation Suspension Levée de la

du certificat du certificat suspension
3.3. Signature numériqueFigure 4.5 Cycle de vie d'un certicat
Une PKI utilise des mécanismes de signature numérique, telle que la fonction de hachage, afin d’assurer
4.8.3l’intégrité des certificats et par conséquent celle des clés publiques que ceux-ci contiennent. La signature
Signature numérique
numérique d'un message ainsi que le certificat de l'expéditeur, prouvent que l’entité identifiée par le certificat
Une PKIl’emettrice
est bien du message.
utilise des mécanismesEn plus
dedesignature
l'authentification, la signature
numérique, telledu certificat
que par la PKI
la fonction deassure aussi an
hachage,
la non-répudiation de l’expéditeur car c’est seule la PKI qui peut signer, avec sa clé privée,
d'assurer l'intégrité des certicats et par conséquent celle des clés publiques que ceux-ci contiennent.
le certificat de
l’expéditeur. En effet, à l’inverse du chiffrement asymétrique, la clé privée de la PKI est utilisée pour la
La signature numérique d'un message ainsi que le certicat de l'expéditeur, prouvent que l'entité
création de la signature du certificat et sa clé publique sert à la vérification de cette signature.
identiée par le certicat est bien l'émettrice du message. En plus de l'authentication, la signature
du certicat par la PKI assure aussi la non-répudiation de l'expéditeur car c'est seule la PKI qui peut
3.4. Processus de certification
signer, avec sa clé privée, le certicat de l'expéditeur. En eet, à l'inverse du chirement asymétrique,
Génération du certificat : Lorsqu'un serveur (par exemple un serveur Web) veut diffuser une clé
la clé privée publique,
de la PKI est utilisée
il effectue pour ladecréation
une demande de auprès
certification la signature du Cette
d'une PKI. certicat et reçoit
dernière sa cléetpublique
vérifie la sert
clé publique
à la vérication de cetteavec l'identité du
signature. demandeur. Après la validation par des moyens conventionnels, la PKI
place la clé publique dans un certificat qu'elle signe en utilisant sa clé privée. Ensuite, le certificat est
4.8.4 Processus de certication
publié puis renvoyé au serveur qui le conserve pour ses communications futures avec les clients.
Vérification du certificat : Si un client (par exemple un navigateur Web) demande une ressource
Génération
numériquedu certicat
au serveur Web, ce: Lorsqu'un
dernier lui envoie son certificat
serveur ainsi queun
(par exemple la ressource
serveur en question.
Web) veutSidiuser
la
signature
une clé du certificat
publique, du serveur
il eectue unecorrespond
demande à une
de PKI en qui le client
certication a confiance,
auprès d'unealors
PKI.le client
Cette vérifie
dernière
l'intégrité du certificat du serveur avec la clé publique du PKI. Cette vérification lui assure que l'identité
reçoit et vérie la clé publique avec l'identité du demandeur. Après la validation par des moyens
du serveur est authentique, c'est-à-dire que la clé publique et l'identité contenues dans le certificat du
conventionnels, la PKI place la clé publique dans un certicat qu'elle signe en utilisant sa
serveur sont garanties par la PKI. Le client peut alors utiliser la clé publique du serveur, incluse dans le
clé privée. pour envoyer
Ensuite,
certificat, des messages
le certicat est chiffrés,
publié en l’occurrence,
puis renvoyé une au clé secrète de
serveur quisession.
le conserve pour ses
communications futures avec les clients.
4.Vérication du certicat :
Chaine de certificats Si un client (par exemple un navigateur Web) demande une
ressource numérique au serveur Web, ce dernier lui envoie son certicat ainsi que la ressource
Sachant que les CA (ou plus généralement les PKI) sont des entités qui valident l'identité et l’intégrité des
en question. Si la signature du certicat du serveur correspond à une PKI en qui le client a
certificats. En effet, elles peuvent être des organismes indépendants ou des entreprises qui utilisent leur propre
conance,
logiciel alors
d'émission delecertificats.
client vérie l'intégrité du certicat du serveur avec la clé publique du PKI.
Cette vérication lui assure que l'identité du serveur est authentique, c'est-à-dire que la clé
Tout client (tel qu’un navigateur Web) qui supporte les certificats maintient une liste des certificats de
publique et l'identité contenues dans le certicat du serveur sont garanties par la PKI. Le client
CA de confiance. Dans le cas le plus simple, le client ne peut valider que les certificats émis par une des CA
peut alors utiliser la clé publique du serveur, incluse dans le certicat, pour envoyer des messages
pour lesquelles il possède le certificat. Il est également possible pour un certificat d'une CA de faire parti d'une
chirés, en l'occurrence, une clé secrète de session.
hiérarchie de certificats, chacun émis par la CA parente dans cette hiérarchie, appelé chaine de certificats. Cette
dernière trace le chemin des certificats d'une branche de la hiérarchie jusqu'au certificat racine. En effet, les
4.9 Chaine de certicats
grandes organisations de certification déléguent la responsabilité de l'émission des certificats à plusieurs CA,
pour plusieurs raisons [1] :
Sachant que les CA (ou plus généralement les PKI) sont des entités qui valident l'identité et
l'intégrité des certicats. En eet, elles peuvent être des organismes indépendants ou des entreprises
qui utilisent leur propre logiciel d'émission de certicats.

Tout client (tel qu'un navigateur Web) qui supporte les certicats maintient une liste des certicats
de CA de conance. Dans le cas le plus simple, le client ne peut valider que les certicats émis par
une des CA pour lesquelles il possède le certicat. Il est également possible pour un certicat d'une
CA de faire parti d'une hiérarchie de certicats, chacun émis par la CA parente dans cette hiérarchie,
appelée chaine de certicats. Cette dernière trace le chemin des certicats d'une branche de la hiérarchie
jusqu'au certicat racine. En eet, les grandes organisations de certication délèguent la responsabilité
de l'émission des certicats à plusieurs CA, pour plusieurs raisons [43] :
Le nombre de certicats requis peut être trop important à maintenir par une seule CA,
Plusieurs CA de l'organisation peuvent avoir diérentes politiques d'attribution des certicats,
Chaque CA pourrait être physiquement localisée dans la même zone géographique que les entités
auxquelles elle délivre les certicats.
En pratique, la certication peut s'eectuer en cascade, c'est-à-dire un certicat peut permettre
d'authentier d'autres certicats jusqu'au dernier certicat qui sera utilisé pour la communication.
Comme le certicat racine est considéré comme étant de conance, remonter jusqu'à celui-ci revient
nalement à authentier le dernier certicat. Concrètement, chaque certicat est signé avec la clé privée
de son émetteur, c'est-à-dire, sa CA parente. La signature peut être vériée avec la clé publique du
certicat de l'émetteur, qui est le prochain certicat dans la chaîne. Les certicats, dit racines, sont auto-
signés n'ayant besoin d'aucun certication, mais devraient être certiés par organisme gouvernemental
physique.
Actuellement, les principaux producteurs de navigateurs Web (Mozilla Firefox, Google Chrome,
. . . ) incluent nativement les certicats de CA les plus ables.
4.10 Conclusion
Malgré que la cryptanalyse permet de faire avancer la cryptographie avec des méthodes de chif-
frement toujours plus poussées, elle représente aussi un danger à l'échelle internationale. En eet,
qu'adviendrait-il si un mathématicien découvrait une technique mathématique permettant de casser
les algorithmes RSA ou AES. Toute la sécurité informatique d'aujourd'hui serait remise en question.
En outres, des attaques plus ecaces, basés sur la cryptanalyse sont en cours de développement,
notamment par des organismes de renseignement dans diérents pays.
Par ailleurs, les applications des ordinateurs quantiques permettent théoriquement de casser le RSA
par force brute, mais heureusement qu'actuellement ces ordinateurs sont toujours inecaces. De ce fait,
si on arrive dans un futur proche, à développer un ordinateur quantique permettant de décrypter des
messages chirés, alors toute la sécurité informatique qu'on connait aujourd'hui s'écroulera.
C'est pourquoi tout est mis en ÷uvre pour assurer la sécurité de demain avec des perspectives
telle que la cryptographie post-quantique, théoriquement incassable puisqu'elle serait une technique
similaire au chire de Vernam où la clé est aussi longue que le message.
Chapitre 5
Sécurité au niveau réseau : Protocole

IPsec
5.1 Introduction
Plusieurs mécanismes de sécurité spéciques aux applications existent opérant dans certains do-
maines, notamment l'accès à distance, le courrier électronique, ou même la navigation Web. Cependant,
les utilisateurs ont des problèmes de sécurité qui traversent toutes les couches protocolaires. En eet,
les VPN permettent de créer un lien logique direct entre deux ou plusieurs machines distantes en uti-
lisant un tunnel sécurisé à l'intérieur d'un réseau public comme Internet. Pour assurer la sécurité des
communications, les connexions des utilisateurs requièrent une authentication, et les données sont
chirées avant de transiter dans le tunnel. De façon plus générale, les VPN peuvent être classés selon
les protocoles utilisés, les services fournis, et les types de trac pouvant le traverser.
Au niveau de la couche Internet, une entreprise peut construire un réseau IP privé et sécurisé
(VPN), en permettant de chirer les paquets IP qui quittent le réseau et d'authentier les paquets
qui y entrent. En eet, l'authentication et le chirement ont été inclus en tant que fonctionnalités
de sécurité nécessaires dans les réseaux IP de nouvelle génération. Ce type de sécurisation est assurer
par le protocole IPsec que nous abordons dans ce chapitre. En implémentant la sécurité au niveau IP,
l'entreprise peut garantir une mise en réseau sécurisée non seulement pour les applications dotées de
mécanismes de sécurité, mais également pour les nombreuses applications ignorant la sécurité.
5.2 Protocole IPsec

IPsec (Internet Protocol security) est un protocole qui regroupe une suite de sous-protocoles utili-
sant des algorithmes et des services cryptographiques permettant le transport de données sécurisées sur
un réseau IP [35]. Déni et normalisé par l'IETF
1 comme un cadre de standards ouverts, IPsec opère
au niveau de la couche Internet contrairement aux standards classiques qui opéraient au niveau de la
couche Application. En eet, il présente l'avantage d'une part, de rendre IPsec totalement indépendant
des applications, et d'autre part, de gérer sa sécurité sans aucune modication sur les terminaux. De
plus, IPsec est compatible à la fois à IPv4 et IPv6, au moyen d'entêtes supplémentaires.
IPsec comprend principalement cinq services fonctionnels [59] [65] :
1. L'authentication : garantit qu'un paquet IP reçu a été transmis par la partie identiée
comme source dans l'entête du paquet.
2. L'intégrité : consiste à s'assurer qu'un paquet n'a pas été altérée accidentellement ou fraudu-
leusement en transit ;
3. La condentialité : assurée au moyen du chirement, permet aux n÷uds communicants de

chirer les données pour empêcher les écoutes par des tiers ;
1. IETF : Internet Engineering Task Force.
49
CHAPITRE 5. SÉCURITÉ AU NIVEAU RÉSEAU : PROTOCOLE IPSEC 50
4. La protection contre le rejeu : à travers un numéro de séquence supplémentaire au niveau

de l'entête IP, ce service permet d'empêcher les attaques consistant à envoyer de nouveau un
paquet valide intercepté précédemment sur le réseau. Ce type d'attaque vise à obtenir la même
autorisation que le paquet légitime à entrer dans le réseau ;
5. La gestion des clés : s'occupe de la négociation et l'échange sécurisés des clés de chirement
ou de signature.
Ces services des sécurité sont basés sur des mécanismes cryptographiques modernes, à savoir les
chirement symétrique et asymétrique, les signatures numériques, les fonctions de hachage, et les
certicats.
Historiquement, Cisco a été l'un des premiers à proposer IPsec en tant que norme pour sécuriser
un réseau IP, en intégrant sa prise en charge dans les routeurs Cisco. En 1998, cela a été concrétisé par
sa normalisation par l'IETF comme un cadre de protocoles standards ouverts. En eet, la spécication
de IPsec comprend plusieurs documents, les plus importants d'entre eux, publiés dans la même année,
sont : (1) le RFC 2401, présentant l'architecture de sécurité pour le protocole IP ; (2) le RFC 2402,
incluant la description du protocole AH servant à l'authentication des paquets à IPv4 et IPv6 ; (3) le
RFC 2406, décrivant le protocole ESP dédié au chirement des paquets IPv4 et IPv6 ; et (4) les RFC
2408 et RFC 2409, spéciant les capacités de gestion et d'échange des clés.
AH servant à l'authentication des paquets à IPv4 et IPv6 ; (3) le RFC 2406, décrivant le protocole
ESP dédié au chirement des paquets IPv4 et IPv6 ; et (4) les RFC 2408 et RFC 2409, spéciant les
capacités de gestion et d'échange des clés.
5.2.1 Applications du protocole IPsec

IPsec ore la possibilité de sécuriser les communications sur un LAN, sur des WAN privés et publics,
et sur Internet. Des exemples de son utilisation sont les suivants :
Connectivité sécurisée des sites d'une entreprise sur Internet : Une entreprise peut
créer un VPN sécurisé sur Internet, lui permettant de réduire ses besoins en réseaux privés, et
ainsi, les coûts de gestion de réseau,
Accès à distance sécurisé sur Internet : Grâce à IPsec, un employé peut obtenir un accès
sécurisé au réseau distant de son entreprise. Cela réduit le coût des péages pour les employés
en déplacement et les télétravailleurs,
Établissement d'une connectivité extranet et intranet avec des partenaires : IPsec
peut être utilisé pour sécuriser la communication avec d'autres organisations,
Amélioration de la sécurité du e-commerce : Même si certaines applications Web et de
e-commerce se base sur des protocoles de sécurité de bout-en-bout (SSL/TLS), l'utilisation
d'IPsec permet d'améliorer cette sécurité.
La principale caractéristique d'IPSec qui lui permet de prendre en charge ces diverses applications
est qu'il peut chirer et/ou authentier tout le trac au niveau IP. Ainsi, toutes les applications
distribuées, y compris la connexion à distance, le courrier électronique, le transfert de chiers, etc.,
peuvent être sécurisées.
5.2.2 Principe de fonctionnement

An de sécuriser le routage des paquets IP, le protocole IPsec eectue plusieurs opérations résumées
en trois phases :
1. Gestion et échange des paramètres de sécurité : Avant d'établir une connexion IPsec,
vue comme un tunnel sécurisé entre deux extrémités IP, les clés de sécurité sont d'abord négo-
ciées puis échangées en utilisant le protocole IKE. Par ailleurs, un autre sous-protocole appelé
ISAKMP, permet de dénir une association de sécurité (Security Association - SA) contenant
tous les paramètres utilisés pour la sécurisation des paquets émis et reçus ;
2. Enregistrement des paramètres de sécurité : Au niveau de chaque entité IP, les SA

actives associées aux diérentes entités IPsec sont stockées dans une base de données appelée
SAD. Cette base de données est consultée pour savoir comment appliquer les mécanismes de
sécurité sur les paquets IP. Par ailleurs, une autre base de données est aussi utilisée, dite SPD,
servant à savoir quelle stratégie il faut appliquer à chaque paquet IP reçu ou à émettre ;
3. Transmission sécurisée des paquets : Une fois les clés de sécurité négociées, échangées et
sauvegardées au niveau des extrémités IPsec, IPsec peut alors établir une connexion sécurisée
en utilisant l'un des deux protocoles AH et ESP : (1) Le protocole AH qui fournit les services
d'intégrité, d'authentication et de protection anti-rejeu ; et (2) le protocole ESP qui assure le
service de condentialité en plus des services fournis par le protocole AH.
5.2.3 Composants de IPsec

Les diérents composants de IPsec sont organisés en trois catégories : (1) des protocoles de sécurité,
(2) des protocoles d'échange de gestion de clés, et (3) des bases de données internes. Les protocoles de
sécurité sont :
Protocole AH (Authentication Header), qui permet l'authentication des données,
Protocole ESP (Encapsulating Security Payload), qui prend en charge à la fois l'authen-
tication et le chirement des données.
Les informations spéciques associées à chacun de ces deux protocoles de sécurité sont insérées
dans des entêtes et des enqueues pour chaque paquet IP échangé.
Deux autres protocoles sont utilisés permettant de gérer et distribuer les clés de sécurité entre les
diérentes entités IPsec :
Protocole IKE (Internet Key Exchange), qui est chargé de négocier les paramètres de
sécurité, en s'échangeant les clés cryptographiques avant qu'une transmission IPsec puisse être
possible,
Protocole ISAKMP (Internet Security Association Key Management Protocol), qui
a pour rôle de créer, modier ou supprimer des SA actives entre les entités IPsec.
An de mieux gérer les SA actives associées aux diérentes entités IPsec, deux bases de données
internes sont utilisées au niveau de chaque entité IP :
Base de données SPD (Security Policy Database), qui est utilisée pour savoir quelle est
la stratégie à appliquer (utilisation de IP ou IPsec) à chaque paquet IP reçu ou à émettre,
Base de données SAD (Security Association Database), qui est consultée pour savoir
comment appliquer les mécanismes de sécurité (paramètres du protocole de sécurité) sur les
paquets IP.
5.3 Modes de fonctionnement de IPsec

IPsec peut fonctionner selon deux modes distincts : (1) un mode "Transport" consistant à sécuriser
uniquement le contenu du paquet IP sans toucher à l'entête et (2) un mode "Tunnel" permettant la
création de tunnels par l'encapsulation de chaque paquet IP dans un nouveau paquet [33].
5.3.1 Mode "Transport"

En utilisant le mode Transport, ce sont uniquement les données transférées (la partie payload du
paquet IP) qui sont sécurisées (chirées et/ou authentiées). Le reste du paquet IP est inchangé et de
ce fait le routage des paquets n'est pas modié. Ce mode Transport n'est généralement utilisable que
sur les équipements terminaux (postes clients, serveurs), car il ne protège pas les entêtes IP. Comme
il est décrit dans la gure 5.1, en utilisant ce mode, les protocoles de sécurité de IPsec (AH ou ESP)
interviennent sur le payload, avant l'intervention du protocole IP qui consiste à ajouter l'entête IP
classique [39].
En utilisant le mode Transport, ce sont uniquement les données transférées (la partie payload du paquet IP) qui
sont sécurisées (chiffrées et/ou authentifiées). Le reste du paquet IP est inchangé et de ce fait le routage des
paquets n'est pas modifié. Ce mode Transport n’est généralement utilisable que sur les équipements terminaux
(postes clients, serveurs), car il ne protège pas les entêtes IP. Comme il est décrit dans la figure ci-dessous, en
CHAPITRE 5. mode,
utilisant ce SÉCURITÉ AU NIVEAU
les protocoles de sécuritéRÉSEAU
de IPsec :(AHPROTOCOLE IPSEC sur le payload, avant
ou ESP) interviennent 52
l’intervention du protocole IP qui consiste à ajouter l’entête IP classique [5].
Transport
Payload (TCP, UDP, …)
Protocole IPsec (ESP ou AH)

Internet
IPsec hdr. Payload (may be encrypted)
Protocole IP
IP hdr. IPsec hdr. Payload (may be encrypted) Paquet IP
Accès-au-réseau
Figure
2.2. Mode "Tunnel"
5.1 Fonctionnement du mode "Transport" du protocole IPsec
En mode Tunnel, c'est tout le paquet IP qui est sécurisé (chiffré et/ou authentifié) puis encapsulé dans un
5.3.2nouveau
Mode "Tunnel"
paquet avec un nouvel entête IP. À cet effet, les protocoles de IPsec (AH ou ESP) opèrent après le
traitement du protocole IP comme il est illustré dans la figure suivante [5]. Ainsi, la protection est appliquée
Ensurmode
tous les champsc'est
Tunnel, du paquet
tout leIP paquet
arrivant IP
à l’entrée
qui estd’un tunnel,(chiré
sécurisé y compris sur les
et/ou champs de puis
authentié) l’entête IP.
encapsulé
dans Généralement,
un nouveau paquetce modeavec
est celui
un utilisé
nouvelpar les équipements
entête IP. À cet réseau
eet, (routeurs, pare-feu,
les protocoles de...) car il(AH
IPsec permet
oulaESP)
création de tunnels entre différents sites.
opèrent après le traitement du protocole IP comme il est illustré dans la gure 5.2 [39]. Ainsi, la
protection est appliquée sur tous les champs du paquet IP arrivant à l'entrée d'un tunnel, y compris
sur les champs
Sécurité de l'entête IP. Généralement,
des réseaux ce mode
2018-2019 est 2celui utilisé parUniversité
– Semestre les équipements
Constantine 2réseau
© Dr. R.
(routeurs, Boukharrou
pare-feu, ...) car il permet la création de tunnels entre diérents sites. Page 4 sur 8
Transport
Payload (TCP, UDP, …)
Protocole IP
Internet
IP hdr. Payload (TCP, UDP, …)
Protocole IPsec (ESP ou AH)
New IP hdr. IPsec hdr. IP hdr. Payload (may be encrypted) Paquet IP
Accès-au-réseau
Afin d’indiquer le type de protocole de sécurité d’un paquet IPsec, le champ Protocol de l’entête IP résultant
Figure 5.2 Fonctionnement du mode "Tunnel" du protocole IPsec
contient le protocole utilisé, à savoir 50 pour ESP et 51 pour AH. Cette identification est utilisée pour les deux
modes de fonctionnement d’IPsec (Transport et Tunnel).
An d'indiquer le type de protocole de sécurité d'un paquet IPsec, le champ Protocol de l'entête
IP résultant contient le protocole utilisé, à savoir 50 pour ESP et 51 pour AH. Cette identication est
Mode "Nesting"
utilisée pour les deux modes de fonctionnement d'IPsec (Transport et Tunnel).
Il est possible d’appliquer un mode dit "Nesting", utilisant à la fois le mode Transport et le mode Tunnel.
Mode "Nesting"
Dans ce type : paquet IPSec (AH ou ESP) en mode Transport est encapsulé dans un autre paquet
de mode, un
IPSec en mode Tunnel.
Il est possible d'appliquer un mode dit "Nesting", utilisant à la fois le mode Transport et le mode
Tunnel. Dans ce type de mode, un paquet IPSec (AH ou ESP) en mode Transport est encapsulé
3. Protocoles de sécurité de IPsec
dans un autre paquet IPSec en mode Tunnel.
Les services de sécurité offerts par IPsec sont fournis au moyen de deux extensions du protocole IP appelées
AH et ESP. Ces deux protocoles peuvent être utilisées séparément ou combinées pour obtenir les services de
sécurité requis :
3.1. Protocole AH
Actuellement défini dans le RFC 4302, le protocole AH (Authentication Header) est un protocole IP de la suite
IPSec, conçu pour assurer l’authenticité des paquets IP, l'intégrité des données transférées ainsi qu’une
protection contre les attaques par rejeu. Le principe de AH est d’ajouter au paquet IP classique une entête
5.4 Protocoles de sécurité de IPsec

Les services de sécurité oerts par IPsec sont fournis au moyen de deux extensions du protocole IP
appelées AH et ESP. Ces deux protocoles peuvent être utilisées séparément ou combinées pour obtenir
les services de sécurité requis :
5.4.1 Protocole AH
Actuellement déni dans le RFC 4302, le protocole AH (Authentication Header) est un protocole IP
de la suite IPSec, conçu pour assurer l'authenticité des paquets IP, l'intégrité des données transférées
ainsi qu'une protection contre les attaques par rejeu. Le principe de AH est d'ajouter au paquet IP
classique une entête supplémentaire, dite entête AH (AH header) permettant à la réception de vérifer
l'authenticité des données incluses dans le paquet.
Le protocole AH opère selon les deux modes de fonctionnement déni pour IPsec. De ce fait,
la gure 5.3 illustre la structure d'un paquet IP utilisant AH, selon ces deux modes : (1) En mode
Transport, un entête AH est ajouté entre l'entête IP d'origine et le payload, tandis que (2) en mode
Tunnel, l'entête AH est ajouté avant le paquet IP d'origine (entête IP + payload), puis précédé par un
nouvel entête IP. Ayant l'authentication comme principal service, celle-ci est appliquée sur les parties
illustrées dans la gure.
Paquet IP
Sécurité des réseaux 2018-2019 – Semestre 2 (non sécurisé)
Université Constantine 2
Authentifié Paquet IP
(non sécurisé)
Paquet IP
IP hdr. AH hdr. Payload (TCP, UDP, …)
(Mode Transport)
Authentifié
Authentifié Paquet IP
IP hdr. AH hdr. Payload (TCP, UDP, …)
(Mode Transport)
Paquet IP
New IP hdr. AH hdr. IP hdr. Payload (TCP, UDP, …)
(Mode Tunnel)
En utilisant le protocole AH, le service d'authentification est assuré grâce aux différents champs de l'entête
AH: (1) Le SPI Figure
(Security 5.3 Structure d'un Authentifié
Parameters Index) permet paquet IP sécurisé par le protoocle AH
de caractériser l'associationPaquet
de sécurité utilisée pour la
IP
communication New(SA)
IP hdr.; et (2)
AH hdr. IP hdr.
la valeur de vérification Payload (TCP, UDP,
d'intégrité (ICV…)2) permet de vérifier l'authenticité des
(Mode Tunnel)
En utilisant le protocole AH, le service d'authentication est assuré grâce aux diérents champs de
données du paquet. Par ailleurs, un numéro de séquence permet de contrer les attaques par rejeu. La structure
En AH
l'entête utilisant
d’un : (1)
entête le Le
AH protocole
estSPI
décrite AH, le service
(Security
comme : d'authentification
Parameters
suit est assurédegrâce
Index) permet aux différents
caractériser champs de de
l'association l'entête
sécurité
AH:pour
utilisée (1) Lela SPI (Security Parameters
communication (SA) Index)
; et (2)permet de caractériser
la valeur l'association
de vérication de sécurité(ICV
d'intégrité
2 ) pour
utilisée permetla de
communication Byte
(SA) ; et (2) la0 valeur de 1
vérification d'intégrité 2
(ICV 2
) permet
vérier l'authenticité des données du paquet. Par ailleurs, un numéro de séquence permet de contrer de 3
vérifier l'authenticité des
données du paquet. 0..3Par ailleurs,
Next header
un numéroPayload lengthpermet de contrer
de séquence
les attaques par rejeu. La structure d'un entête AH est décrite dans la gure 5.4 :
Reserved
les attaques par rejeu. La structure
d’un entête AH est 4..7décrite comme suit : Security Parameters index (SPI)
8..11
Byte 0 Sequence
1 number 2 3
12..n
0..3 Next header Authentication
Payload length data (variable)Reserved
4..7 (1 octet) : identifieSecurity
Next Header le typeParameters
du prochain index
entête(SPI)qui suit immédiatement cet entête.
Généralement,
8..11 il identifie le protocole deSequence plus haut niveau,
number
Payload12..n
Length (1 octet) : contientAuthentication
la longueur dedata l'entête d'authentification. En IPv4, cette longueur
(variable)
est calculée en termes de 4 octets moins 2, par exemple les valeurs de 0, 1 et 2 correspondent
Next Header (1
respectivement à 8octet)
octets,: 12
identifie
octets leet type
à 16 du prochain
octets. Dans le entête
cas dequipaquets
suit immédiatement
IPv6, la longueur cet entête.
de cet
Généralement, il Figure
identifie le 5.4
protocole Structure
de plus haut d'un
niveau, entête AH
entête doit être un multiple de 8 octets, c’est-à-dire les valeurs de 1, 2 et 3 correspondent
respectivement
Payload Length à 8(1octets,
octet)16 octets etlaàlongueur
: contient 24 octets.de l'entête d'authentification. En IPv4, cette longueur
Nextest Header
calculée (1 octet)
en termes :4identie le type du prochain entête qui0,suit
1 etimmédiatement cet
Reserved (2 octets) : ce de
champ octets moins
est réservé 2, par
pour uneexemple
utilisation lesfuture.
valeurs de
Actuellement, 2il correspondent
est mis à 0,
entête. Généralement,
respectivement à 8 il identie
octets, 12 le protocole
octets et à 16 de plus
octets. Dans haut
le cas niveau,
de paquets IPv6, la longueur de cet
Security Parameters Index (4 octets) : identifie une association de sécurité (SA), en fonction de
Payload entêteLength (1
un octet)
l'adressedoit être notions
IP (Les de SA :et
multiple decontient
8 octets,
SPI lac’est-à-dire
sont abordéeslongueur les
dans lede valeurs cours),
l'entête
prochaine ded'authentication.
1, 2 et 3 correspondent En IPv4,
respectivement à 8 octets, 16 octets et à 24 octets.
cette longueur est calculée en termes de 4 octets moins 2, par exemple les valeurs de 0, 1 et 2
Sequence Number (4 octets) : correspond à un numéro de séquence incrémenté de 1 pour chaque
Reserved
paquet IP (2 octets)
envoyé. Ce: numéro
ce champ deest réservépermet
séquence pour uneuneutilisation
protectionfuture.
contreActuellement,
les attaques paril est mis(replay
rejeu à 0,
2. ICV : Integrity Control Value.
Security
attacks), Parameters Index (4 octets) : identifie une association de sécurité (SA), en fonction de
l'adresse IP (Les notions de SA et SPI sont abordées dans le prochaine3 cours),
Authentication Data (taille variable) : contient un ICV, ou un MAC permettant de vérifier l'intégrité
Sequence
et Number
l’authenticité (4 octets)
du paquet IP. La: correspond
longueur deà ce unchamp
numéroestdevariable,
séquence incrémenté
donc dedoit
ce dernier 1 pour
être chaque
aligné
par un padding pour qu’il soit un multiple de 4 octets pour IPv4 et un multiple de 8 octets dans(replay
paquet IP envoyé. Ce numéro de séquence permet une protection contre les attaques par rejeu le cas
attacks),
de IPv6.
3
correspondent respectivement à 8 octets, 12 octets et à 16 octets. Dans le cas de paquets IPv6,

la longueur de cet entête doit être un multiple de 8 octets, c'est-à-dire les valeurs de 1, 2 et 3
correspondent respectivement à 8 octets, 16 octets et à 24 octets.
Reserved (2 octets) : ce champ est réservé pour une utilisation future. Actuellement, il est
mis à 0,
Security Parameters Index (4 octets) : identie une association de sécurité (SA), en fonc-
tion de l'adresse IP (Les notions de SA et SPI sont abordées dans le prochaine cours),
Sequence Number (4 octets) : correspond à un numéro de séquence incrémenté de 1 pour
chaque paquet IP envoyé. Ce numéro de séquence permet une protection contre les attaques
par rejeu (replay attacks),
Authentication Data (taille variable) : contient un ICV, ou un MAC
3 permettant de
vérier l'intégrité et l'authenticité du paquet IP. La longueur de ce champ est variable, donc ce
dernier doit être aligné par un padding pour qu'il soit un multiple de 4 octets pour IPv4 et un
multiple de 8 octets dans le cas de IPv6.
5.4.2 Protocole ESP

Spécié actuellement dans le RFC 4303, le protocole ESP (Encapsulating Security Payload), est un
sous-protocole
Sécurité desde IPsec permettant de combiner
réseaux 2018-2019 – Semestre
plusieurs services
2 de sécurité, àUniversité
savoir la condentialité,
Constantine 2
l'authentication, l'intégrité et la protection anti rejeu.
Contrairement au protocole AH, qui consiste uniquement à ajouter un entête supplémentaire au
Contrairement au protocole AH, qui consite uniquement à ajouter un entête supplémentaire au paquet IP
paquet IP (AH header), le protocole ESP chire et authentie les données puis les encapsule, en
(AH header), le protocole ESP chiffre et authentifie les données puis les encapsule, en ajoutant trois blocs de
ajoutant trois blocs de champs supplémentaires : une entête ESP (ESP header), une enqueue ESP
champs suplémentaires : une entête ESP (ESP header), une enqueue ESP (ESP trailer) et une athentification
(ESP trailer) et une authentication ESP (ESP authentication).
ESP (ESP authentication).
Le principe de ESP est de générer, à partir d'un paquet IP classique, un nouveau paquet dans lequel
les données principe de ESP
Le (payload) est de générer, à partir
et éventuellement d’unoriginal,
l'entête paquet IP sont
classique, un nouveau
chirés. paquetégalement
ESP peut dans lequel assurer
les
données (payload) et éventuellement l’entête original, sont chiffrés. ESP peut également assurer l’authenticité
l'authenticité des données par l'ajout d'un bloc d'authentication. La gure 5.5 montre, suivant le
des données par l’ajout d’un bloc d’authentifcation. La figure ci-dessous montre, suivant le mode de
mode de fonctionnement, la portée de l'authentication et du chirement opérés par le protocole ESP.
fonctionnement, la portée de l’authentification et du chiffrement opérés par le protocole ESP.
Paquet IP
(non sécurisé)
Authentifié
Chiffré
Paquet IP
IP hdr. ESP hdr. Payload (TCP, UDP, …) ESP trlr. ESP auth.
(Mode Transport)
Authentifié
Chiffré
Paquet IP
New IP hdr. ESP hdr. IP hdr. Payload (TCP, UDP, …) ESP trlr. ESP auth.
(Mode Tunnel)
Comme pour AH, l'authentification est fournie par ESP grâce à l'utilisation de données d'entête d’enqueue, à
savoir le SPI,Figure 5.5 Structure d'un paquet IP sécurisé par le protoocle ESP
et la ICV, et la protection anti-rejeu est assuré par un numéro de séquence. Par ailleurs, les
données chiffrées sont contenues dans le champ payload du paquet ESP. Du bourrage (padding), peut être
Comme pour AH, l'authentication est fournie par ESP grâce à l'utilisation de données d'entête
ajouté à la fin du payload (c’est-à-dire au début de l’enqueue ESP) pour permettant d’aligner le payload chiffré
d'enqueue, à savoir
pour obtenir uneletaille
SPI, deetbloc
la ICV, et la avec
compatible protection anti-rejeu
le chiffrement. est
Donc, laassuré par
structure un numéro
suivante de séquence.
correspond à un
Par ailleurs, les: données chirées sont contenues dans le champ payload du paquet ESP. Du bourrage
entête ESP
(padding), peut être ajouté à la n du payload (c'est-à-dire au début de l'enqueue ESP) pour permet-
Byte 0 1 2 3
tant d'aligner le payload chiré pour obtenir une taille de bloc compatible avec le chirement. Donc,
la
0..3 Security Parameters index (SPI)
structure de la gure 5.6 correspond à un entête ESP.
4..7 Sequence number
3. MAC : Message Authentication Code.
Security Parameters Index (4 octets) : identifie une association de sécurité (SA), en fonction de
l'adresse IP comme dans l’entête AH,
paquet IP envoyé, permet d’éviter les attaques par rejeu,
L’enqueue ESP est décrite par la structure suivante :
Comme pour AH, l'authentification est fournie par ESP grâce à l'utilisation de données d'entête d’enqueue, à
Authentifié
savoir le SPI, et la ICV, et la protection anti-rejeu Chiffréest assuré par un numéro de séquence. Par ailleurs, les
données chiffrées Paquet IP peut être
New IP hdr. ESP sont
hdr. contenues
IP hdr. dans lePayload
champ(TCP, payload du paquet ESP
UDP, …) ESP.
trlr.DuESP
bourrage
auth. (padding),
(Mode Tunnel)
CHAPITRE
Comme 5.
pour obtenir SÉCURITÉ
pour une
AH,taille AU NIVEAU
de bloc compatible
l'authentification RÉSEAU
avecpar
est fournie le ESP : PROTOCOLE
chiffrement. IPSEC
Donc, la structure
grâce à l'utilisation d'entête
suivante
de données d’enqueue,
correspond à unà 55
entête ESP
savoir : et la ICV, et la protection anti-rejeu est assuré par un numéro de séquence. Par ailleurs, les
le SPI,
données chiffrées sont contenues dans le champ payload du paquet ESP. Du bourrage (padding), peut être
Byte 0 1 2 3
pour obtenir une0..3taille de bloc compatibleSecurity
avec le Parameters
chiffrement.index
Donc, (SPI)
la structure suivante correspond à un
entête ESP : 4..7 Sequence number
SecurityByte
Parameters 0Index (4 octets) :1identifie une association
2 de sécurité
3 (SA), en fonction de
l'adresse IP comme dans
0..3
Figure
l’entête5.6
AH, Structure d'un entête ESP
Security Parameters index (SPI)
4..7 Sequence number
paquet IP envoyé, permet d’éviter les attaques par rejeu,
Security Parameters Index (4 octets) : identie une association de sécurité (SA), en fonc-
Security
L’enqueue ESP estParameters
décrite Index
par la (4 octets)
structure : identifie
suivante : une association de sécurité (SA), en fonction de
tion de l'adresse IP comme dans l'entête AH,
l'adresse IP comme dans l’entête AH,
Sequence Number (4 octets) : correspond à un numéro de séquence incrémenté de 1 pour
Sequence Byte
Number (4 0octets) : correspond 1 à un numéro de2 séquence incrémenté
3 de 1 pour chaque
chaque paquet IP envoyé, permet d'éviter les attaques par rejeu,
paquet IP0..3
envoyé, permet d’éviter les attaques par rejeu,
Payload
L'enqueue ESP est décrite dans la gure 5.7 :
4..7décrite par la structure
L’enqueue ESP est Padding
suivante : Padding length Next header
(≤ 255 octets)
PaddingByte 0 : contient un bourrage
1 de bits permettant
2 d’aligner3 le payload chiffré pour
obtenir une taille de bloc compatible avec le chiffrement,
0..3 Payload
Padding length (1 octet) : Longueur du padding exprimé en octets,
4..7 Padding Padding length Next header
Next Header (1 octet) : identifie le type du prochain entête.
Padding (≤ 255 octets) : contient un bourrage de bits permettant d’aligner le payload chiffré pour
obtenir une taille de Figure 5.7 avec
bloc compatible Structure d'un enqueue ESP
le chiffrement,
Padding (≤ 255(1octets)
Next Header : contient
octet) : identifie un du
le type bourrage
prochainde bits permettant d'aligner le payload chiré
entête.
pour obtenir une taille de bloc compatible avec le chirement,
NextdesHeader
Sécurité réseaux (1 octet) : identie 2018-2019
le type du prochain
– Semestre 2 entête. Université Constantine 2
L'enqueue ESP est suivi par une authentication ESP, dont la structure est présentée dans la
gure©5.8.
Dr. R. Boukharrou Page 7 sur 8
L’enqueue ESP est suivi par une authentification ESP, comme suit :
Byte 0 1 2 3
0..n Authentication Data
Authentication Data (taille variable) : contient un ICV, ou un MAC permettant de vérifier l'intégrité
Figure
et l’authenticité du paquet 5.8 Structure
IP. Similairement d'un enqueue
au protocole ESP
AH, la longueur de ce champ est variable.
Afin de décrire le fonctionnement de IPsec, voici le déroulement de la sécurisation d’un paquet IP en utilisant

leAuthentication
protocole ESP en mode Data (taille
Transport : variable) : contient un ICV, ou un MAC permettant de vérier
l'intégrité et l'authenticité du paquet IP. Similairement au protocole AH, la longueur de ce
l’envoi d’un
Àchamp paquet IP :
est variable.
1) décrire
An de Le payload du paquet IP issu de
le fonctionnement de la couchevoici
IPsec, Transport (TCP, UDP, de
le déroulement …) la
estsécurisation
complété par une
d'unenqueue
paquet IP
ESP
en utilisant le pour être chiffré
protocole ESP en ; mode Transport :
À l'envoi2) Ensuite,
d'un paquetun entête
IP : ESP est ajouté au début du payload chiffré précédemment ;
3) Si l’option d’authentification est sélectionnée lors de la configuration du protocole ESP, un bloc
1. Le payload du paquet IP issu de la couche Transport (TCP, UDP, . . . ) est complété par une
d’authentification ESP est ajoutée à la fin, contenant le MAC du bloc constitué de l’entête ESP et du
enqueue ESP
payload pour; être chiré ;
chiffré
2. 4) Le bloc
Ensuite, un résultant
entête ESP est encapsulé avecau
est ajouté l’entête
début IP du
pourpayload
constituer le paquet
chiré IP final ;
précédemment ;
3.
5) Le paquet IP est enfin acheminé vers la destination ;
Si l'option d'authentication est sélectionnée lors de la conguration du protocole ESP, un bloc
Àd'authentication
la réception du paquetESP
IP : est ajoutée à la n, contenant le MAC du bloc constitué de l'entête ESP
et6)
duPendant
payload chiré ;
l’acheminement du paquet IP, chaque nœud intermédiaire du réseau (routeur) doit examiner
et traiter
4. Le bloc l'entêteest
résultant IP,encapsulé
et n'a pas besoin
avec d'examiner le payload
l'entête IP chiffré, toutefois,
pour constituer il peutIPexaminer
le paquet l’entête
nal ;
ESP et l’authentification ESP, car c’est le mode Transport qui est utilisé ;
5. Le paquet IP est enn acheminé vers la destination ;
7) À l’arrivée du paquet IP, le nœud de destination examine et traite l'entête IP ainsi que l’entête,
À l’enqueue
la réception et l’authentification
du paquet IP : ESP ;
8) Ensuite, l’authenticité de l’entête ESP et du payload chiffré est vérifié avec le MAC inclus dans le bloc
1. Pendant l'acheminement du paquet IP, chaque n÷ud intermédiaire du réseau (routeur) doit
authentification ESP. Cette opération est réalisée uniquement dans le cas où l’option d’authentification
examiner et traiter
est a été l'entête
sélectionnée IP,
lors de laet n'a pas besoin
configuration d'examiner
du protocole ESP avecle payload chiré,
l’expéditeur ; toutefois, il peut
examiner l'entête ESP et l'authentication ESP, car c'est le mode Transport qui est utilisé ;
9) Enfin, sur la base du SPI de l'entête ESP, le nœud de destination déchiffre le reste du paquet (payload
+ enqueue ESP) pour récupérer le payload en clair (segment de couche de Transport).
Ce processus est similaire pour le protocole AH, sauf que le payload n'est pas chiffré.
Liens utiles
2. À l'arrivée du paquet IP, le n÷ud de destination examine et traite l'entête IP ainsi que l'entête,
l'enqueue et l'authentication ESP ;
3. Ensuite, l'authenticité de l'entête ESP et du payload chiré est vérié avec le MAC inclus dans
le bloc authentication ESP. Cette opération est réalisée uniquement dans le cas où l'option
d'authentication est a été sélectionnée lors de la conguration du protocole ESP avec l'expé-
diteur ;
4. Enn, sur la base du SPI de l'entête ESP, le n÷ud de destination déchire le reste du paquet
(payload + enqueue ESP) pour récupérer le payload en clair (segment de couche de Transport).
Ce processus
Sécurité des réseauxest similaire pour le protocole AH, –sauf
2018-2019 que le
Semestre 2 payload n'est pas chiré.Constantine
Université 2
5.5 Fonctionnement de l'architecture globale de IPsec

1. Fonctionnement de l’architecture globale de IPsec
5.5.1 Traitement des paquets sortants
1.1. Traitement des paquets sortants
Comme il est illustré dans la gure 5.9, à l'envoi de chaque payload reçu depuis la couche Transport
À l’envoi de chaque payload reçu depuis la couche Transport (segment TCP, datagramme UDP, …) vu
(segment TCP, datagramme UDP, . . . ) vu désormais comme un paquet IP, le protocole IPsec procède
désormaisà comme
d'abord un paquet IP,
une consultation de le
laprotocole
base de IPsec procède
données SPDd’abord à une consultation
pour rechercher de la base
et déterminer de données
la politique à
SPD pour rechercher et déterminer la politique à appliquer pour ce paquet. Dans le cas où aucune
appliquer pour ce paquet. Dans le cas où aucune politique n'a été trouvée, alors le paquet est rejeté. politique n’a
été trouvée,
Dans le cas alors le paquet
contraire, estpeut
IPsec rejeté. Dansen
savoir le cas contraire,
consultant la IPsec peut savoir
politique, si uneen consultantest
protection la appliquée
politique, sipour
une
protection est
ce paquet ou non.appliquée pour ce paquet ou non.
Dans le cas où une protection a été dénie pour le paquet, IPsec recherche dans la base de données
Dans le cas où une protection a été définie pour le paquet, IPsec recherche dans la base de données SAD,
SAD, l'association de sécurité SA correspondante à ce paquet. Si la SA est trouvée, alors le paquet est
l’association de sécurité SA correspondante à ce paquet. Si la SA est trouvée, alors le paquet est sécurisé en
sécurisé en utilisant l'un des protocoles de sécurité de IPsec (AH ou ESP) selon les paramètres dénis
utilisant l’un des protocoles de sécurité de IPsec (AH ou ESP) selon les paramètres définis dans la SA. Par
dans la SA. Par ailleurs, si la SA n'existe pas dans la SAD, IPsec peut enclencher la négociation d'une
ailleurs, si la SA n’existe pas dans la SAD, IPsec peut enclencher la négociation d’une nouvelle SA pour le
nouvelle SA pour le paquet en faisant appel au protocole IKE, et relancer ensuite la recherche de la
paquet en faisant appel au protocole IKE, et relancer ensuite la recherche de la SA correspondante au paquet
SA correspondante au paquet qui servira à la sécurisation de celui-ci.
qui servira à la sécurisation de celui-ci.
Transport Payload
entrant
(TCP, UDP, …)
Non trouvée Rechercher

une politique
SPD
Trouvée
Rejeter le Rejet Déterminer Protection

Internet
paquet la politique
Non
Trouvée Rechercher trouvée
une SA
Pas de
protection
Traiter le SAD Négocier
paquet
une SA (IKE)
(AH, ESP)
Transférer le
paquet via IP
Accès-au-réseau
Figureentrants
1.2. Traitement des paquets 5.9 Traitement des paquets IPsec sortants
À la réception de chaque paquet IP issu de la couche Accès-au-réseau, le protocole IPsec vérifie d’abord le
type du paquet. Si c’est un paquet IP, IPsec consulte la base de données SPD pour déterminer si une politique
est appliquée pour ce paquet. En effet, si la politique n’est pas trouvée alors le paquet est rejeté, sinon celui-ci,
n’ayant aucune protection, est délivré à la couche Transport.
Dans le cas où c’est un paquet IPsec, le protocole IPsec recherche la SA correspondante au paquet dans
5.5.2 Traitement des paquets entrants

Comme il est montré dans la gure 5.10, à la réception de chaque paquet IP issu de la couche Accès-
au-réseau, le protocole IPsec vérie d'abord le type du paquet. Si c'est un paquet IP, IPsec consulte
la base de données SPD pour déterminer si une politique est appliquée pour ce paquet. En eet, si
la politique n'est pas trouvée alors le paquet est rejeté, sinon celui-ci, n'ayant aucune protection, est
délivré à la couche Transport.
Dans le cas où c'est un paquet IPsec, le protocole IPsec recherche la SA correspondante au paquet
dans la base de données SAD. Si la SA est trouvée, cela signie que le paquet est légitime et a été
sécurisé à l'envoi, donc il est traité en utilisant l'un des protocoles de sécurité (AH ou ESP) selon les
paramètres spéciés dans la SA. Par ailleurs,
Sécurité des réseaux 2018-2019 – Semestre
si la SA n'existe
2 pas dans la SAD, le paquet
Université est rejeté
Constantine 2
sachant qu'une négociation pour une nouvelle SA peut être eectuée.
Transport Délivrer les

payload
(TCP, UDP, …)
Traiter le
paquet
Pas de (AH, ESP)
protection
Trouvée
Non
Internet
Rechercher
Rejet Rejeter le trouvée Rechercher
une politique paquet une SA
SPD SAD
Déterminer le
IP type du paquet IPsec
Paquet IP
entrant
Accès-au-réseau
Figure 5.10 Traitement des paquets IPsec entrants

2. Associations de sécurité
Une association de sécurité (Security Association – SA) est la définition des paramètres requises pour la
5.6 Associations de sécurité
sécurisation des flux entre deux entités IPsec.
Pour établir des tunnels IPsec, celui-ci doit établir d’abord un tunnel IKE, dit administratif permettant aux
deuxUne
extrémités IPsecde
association de sécurité
s’échanger les paramètres
(Security de sécurité.
Association SA)Donc,
est ladeux
dénition des
types de SAparamètres
sont utilisésrequises
dans la
pour la sécurisation des ux entre deux entités IPsec.
configuration d'IPsec, tout comme il y a deux étapes dans l'établissement des tunnels IPsec : (1) Les SA IKE
Pour établir
qui décrivent des tunnels
les paramètres deIPsec,
sécuritécelui-ci doitentités
entre deux établir d'abord
IKE ; et (2)un
lestunnel IKE,
SA IPsec qui dit administratif
se rapportent per-
au tunnel
mettant aux deux extrémités IPsec de s'échanger les paramètres de sécurité. Donc,
IPsec proprement dit. Au niveau de IKE, une seule SA IKE est établie pour gérer les communications deux types de SA
sont utilisés dans la conguration d'IPsec, tout comme il y a deux étapes dans l'établissement
sécurisées dans les deux sens entre les deux entités IKE (Les SA IKE seront traitées dans la prochaine section). des
tunnels IPsec : (1) Les SA IKE qui décrivent les paramètres de sécurité entre deux entités IKE ; et (2)
Par contre, au niveau de IPsec, les SA IPsec sont unidirectionnelles, c’est-à-dire des relations à sens
les SA IPsec qui se rapportent au tunnel IPsec proprement dit. Au niveau de IKE, une seule SA IKE
unique
est de l’entité
établie émettrice
pour gérer vers l’entité réceptrice
les communications d’une
sécurisées communication,
dans les deux sens de ce fait,
entre protéger
les deux les deux
entités sens
IKE (Les
d'une communication IPsec requiert deux associations
SA IKE seront traitées dans la prochaine section). SA IPsec. Les SA IPsec peuvent être établies par une
intervention manuelle
Par contre, ou en utilisant
au niveau de IPsec,le protocole ISAKMP.
les SA IPsec sont unidirectionnelles, c'est-à-dire des relations à
sens unique de l'entité émettrice vers l'entité réceptrice d'une communication, de ce fait, protéger les
Concrètement, une SA IPsec est une bloc de données constituant un enregistrement (tuple) dans une base de
deux sens d'une communication IPsec requiert deux associations SA IPsec. Les SA IPsec peuvent être
données dédiée aux SA actives, appelée SAD (SA Database). Chaque SA IPsec est identifiée de manière unique
établies par une intervention manuelle ou en utilisant le protocole ISAKMP.
dans la SAD à l'aide d'un triplet composé de : (1) Un identifiant du protocole de sécurité (AH ou ESP), (2) un index
de paramètre de sécurité (SPI), et (3) une destination IP, pouvant être une adresse IP ou une socket [1].
2.1. Paramètres d’associations de sécurité

Paramètre Valeur
IP destination address 10.1.1.19
Security protocol esp
Security parameter index
9C163C4A
(SPI)
IPsec protocol mode tunnel
Cypher algorithm aes256
Cypher key 0xEB3345C150A34E. . .
Authentication algorithm sha1
Authentication key 0x124A34CD1B3876. . .
Sequence number 28
Anti-replay window 57
Lifetime 86400
Path MTU 2048
Table 5.1 Exemple d'une SA IPsec
Concrètement, une SA IPsec est une bloc de données constituant un enregistrement (tuple) dans
une base de données dédiée aux SA actives, appelée SAD (SA Database). Chaque SA IPsec est identiée
de manière unique dans la SAD à l'aide d'un triplet composé de : (1) Un identiant du protocole de
sécurité (AH ou ESP), (2) un index de paramètre de sécurité (SPI), et (3) une destination IP, pouvant
être une adresse IP ou une socket [9].
5.6.1 Paramètres d'associations de sécurité

Chaque SA IPsec se compose de plusieurs paramètres de sécurité, sous forme d'un tableau clé/va-
leur, en voici les plus importants :
IP destination address (4 octets) : l'adresse IP de l'entité destinataire, pouvant être une
adresse statique, une adresse de broadcast ou une adresse de multicast,
Security protocol : le protocole de sécurité utilisé : AH ou ESP,
Security parameter index (SPI) (4 octets) : la valeur d'indexation de la SA servant à
diérencier les SA IPsec partageant la même destination IP et le même protocole de sécurité,
Cypher algorithm : l'algorithme de chirement utilisé (dans le cas de l'utilisation du protocole
ESP),
Cypher key : la clé de session dédiée au chirement (dans le cas de l'utilisation du protocole
ESP),
Authentication algorithm : l'algorithme de signature utilisé pour l'authentication,
Authentication key : clé de signature dédiée à l'authentication,
IPsec protocol mode : le mode de fonctionnement du protocole utilisé : tunnel ou transport,
Sequence number (8 octets) : l'indicateur utilisé pour générer le numéro de séquence courant
servant le service d'anti-rejeu,
Anti-replay window (8 octets) : la fenêtre d'anti-rejeu permettant de vérier le dépassement
du numéro de séquence, et ainsi détecter une attaque par rejeu,
Lifetime : la durée de vie de la SA, exprimée en termes de secondes ou d'octets,
Path MTU : les MTU 4 mis en place entre les deux extrémités de la SA. Le MTU déni doit
être assez petite pour éviter la fragmentation dans les routeurs intermédiaires.
La table 5.1 présente un exemple d'une SA IPsec.
5.6.2 Bases de données SAD

Au niveau d'une extrémité IPsec, une base de données SAD (Security Association Database), a
pour rôle de gérer et de sauvegarder toutes les SA IPsec actives dans cette extrémité. Concrètement,
4. Le MTU est la taille maximale d'un paquet pouvant être transmis sans fragmentation (en une seule fois).
la SAD est consultée pour savoir quel est le protocole de sécurité à appliquer à chaque paquet reçu
ou à émettre. En eet, la SAD garantit que le paquet protégé sera reconnu par le récepteur à son
arrivée. Elle permet également au récepteur de récupérer par le SPI tous les paramètres nécessaire
pour déchirer la communication, et vérier que le paquet n'a pas été altérés [9].
Ainsi, pour envoyer un paquet sécurisé vers une adresse IP, l'émetteur recherche la SA IPsec cor-
respondante dans sa base SAD pour récupérer les paramètres de sécurisation du paquet, à savoir le
SPI, les clés et les algorithmes utilisés. De même, à la réception d'un paquet sécurisé, le SPI du paquet
est utilisé pour trouver la SA IPsec correspondante dans la base SAD du récepteur, contenant tous les
paramètres nécessaires pour déchirer le paquet.
5.6.3 Bases de données SPD

Une base de données SPD (Security Policy Database), dénit la politique de sécurité au niveau
d'une extrémité IPsec. Elle est consultée avant le traitement des paquets IP entrants ou sortants (y
compris les paquets non IPsec), pour savoir ce que l'on doit faire avec chaque paquet reçu ou à émettre.
Chacune des entrées de la SPD consiste à lier un sous-ensemble du trac IP avec une SA pour ce trac.
La SPD consiste ltrer le trac IP et identie le mode de traitement des paquets. Concrètement, cela
consiste à déterminer si le paquet est sécurisé ou non. En eet, trois comportements sont envisageables
pour chaque paquet à traiter : (1) le rejeter, (2) l'accepter sans traitement IPsec, ou (3) le traiter en
appliquant le protocole de sécurité de IPsec [21]. Dans le troisième cas, la SA IPsec correspondante
au paquet à traiter, est récupérée de la SAD, contenant les paramètres de sécurité nécessaires au
traitement du paquet (protocole, mode, etc.).
5.7 Gestion et distribution des clés

Le protocole IPsec repose sur plusieurs sous-protocoles dont certains opèrent hors de la couche
Internet lui orant une grande souplesse d'utilisation. Avant d'établir une connexion IPsec, il est
nécessaire pour les deux extrémités IP de la connexion de se mettre d'accord sur les mécanismes de
sécurité utilisés. Comme les SA englobent des clés pour l'authentication et le chirement, le cycle
de vie de celles-ci doit être géré et mis à niveau. Malgré qu'il existe une commande, appelée ipseckey,
permettant la gestion manuelle des clés, le protocole IKE (Internet Key Exchange) a été proposé dans
le but d'automatiser cette gestion des clés.
5.7.1 Protocole IKE

Initialement déni dans les RFC 2407, RFC 2408 et RFC 2409, le protocole IKE (Internet Key
Exchange), a pour objectif de mettre en place des SA en négociant des clés utilisées pour la transmission
sécurisée des paquets via IPsec. IKE est un protocole non connecté opérant sur UDP (port 500), au
niveau de la couche Application. Il se base sur le protocole ISAKMP pour dénir les SA négociées.
Avant qu'une transmission IPSec puisse être possible, IKE est utilisé pour authentier les deux
extrémités d'un tunnel sécurisé en échangeant des clés partagées. IKE permet deux types d'authenti-
cations, en utilisant un secret partagé PSK (Pre-Shared Key) ou à l'aide de certicats X.509 signés
par des CA. Contrairement aux protocoles AH et ESP, le protocole IKE est dit administratif, car il ne
sert pas à la transmission sécurisée des données, mais il est chargé de gérer les tunnels d'IPsec, leur
création, le rafraîchissement des clés, etc. [56].
Actuellement, deux versions du protocole IKE sont fonctionnelles supportées par la plupart des
équipements VPN, mais qui ne sont pas interopérables entre eux : IKEv1 et IKEv2.
Fonctionnement du protoocle IKEv1

Le protocole IKEv1 (RFC 4109) opère en deux phases successives (Figure 5.11) :
1. Négociation des SA IKE : le protocole IKEv1 établie un premier tunnel, appelé "Tunnel
IKE", pour protéger les paramètres SA IKE, qui sert par la suite à sécuriser la négociation
des SA IPsec. Dans cette phase, la SA IKE est bidirectionnelle c'est-à-dire qu'une seule SA est
établie par une paire d'entités IPsec ;
2. Négociation des SA IPsec : IKEv1 établie autant de tunnels IPsec que nécessaire (dits
secondaires), permettant à des paires d'entités IP de sécuriser leurs échanges. En eet, les
paramètres de sécurité SA IPsec, nécessaires aux protocoles AH et ESP, sont échangés pour
sécuriser la transmission des données.
La négociation des SA IKE peut s'eectuer selon deux modes, soit en utilisant le mode principal
(Main mode), ou soit en utilisant le mode agressif (Aggressive mode). Le mode principal de IKEv1
comporte trois paires de messages (6 messages) entre les extrémités IPSec, tandis que le mode agressif
ne comporte que trois échanges de messages. Le mode agressif permet d'accélérer la négociation, au
prix de la protection d'identité.
En outres, la deuxième phase de IKEv1 opérant en un seule mode, dit Quick Mode, n'a que trois
messages.
Sécurité desDans cette phase, l'objectif de IKEv1
réseaux est –
2018-2019 d'établir
Semestre deux
2 SA IPsec correspondant à chacune
Université Constantine 2
des extrémités parce que la SA IPsec est unidirectionnelle.
Phase 1 : SA IKE
Main Mode Aggressive Mode

(6 messages) (3 messages)
Phase 2 : SA IPsec Phase 2 : SA IPsec
Quick Mode ... Quick Mode

(3 messages) (3 messages)
Données Données
A B A B
protégées protégées
Par conséquent, afin d’établir unFigure

tunnel IPsec entre deux extrémité IP, le protocole IKEv1 doit établir une SA
5.11 Phases du protocole IKEv1
IKE et deux SA IPsec. Cette opération est nécessaire pour sécuriser les échanges entre chaque paire d’entités
IP [4].
Par conséquent, an d'établir un tunnel IPsec entre deux extrémité IP, le protocole IKEv1 doit
établir une SA IKE et deux SA IPsec. Cette opération est nécessaire pour sécuriser les échanges entre
IKE_SA_INIT
Fonctionnement du protocole IKEv2
chaque paire d'entités IP [48]. (2 à 4 messages)
Développé conjointement par Cisco et Microsoft, IKEv2 est le successeur
Fonctionnement
du protocole IKEv1. duComparé
protocole à ceIKEv2
dernier, le protocole IKEv2 est
hautement sécurisé, rapide et facile à configurer. Il a été initialement défini CREATE_CHILD_SA
par Développé
le RFC 4306,conjointement
et actuellementpar
misCisco
à jour et
parMicrosoft,
le RFC 7296. IKEv2 est le successeur du protocole IKEv1.
(2 messages)
Comparé à ce dernier, le protocole IKEv2 est hautement sécurisé, rapide et facile à congurer. Il a été
Contrairement à IKEv1, IKEv2 se base sur une seule procédure
initialement déni par le RFC 4306, et actuellement mis à jour par le RFC 7296.
d'échange de clés utilisant uniquement 4 messages, en considérant les CREATE_CHILD_SA
Contrairement à IKEv1, IKEv2 se base sur une seule procédure d'échange (opt.)uni-
de clés utilisant
modes d'échange (Main & Aggressive) comme obsolètes [5]. (2 messages)
quement 4 messages (Figure 5.12), en considérant les modes d'échange (Main & Aggressive) comme
obsolètes [26].
Afin de définir les paramètres de sécurité, IKEv2 utilise d’une part,
An de
l'échange dedénir les paramètres
clés Diffie-Hellman demettre
pour sécurité, IKEv2
en place un utilise d'une part, l'échange de clés Die-Hellman
secret pré-partagé
pour
(PSK)mettre en place
dont les un secret
clés de pré-partagé
chiffrement (PSK) dont
sont dérivées, les clés part
et d’autre de chirement
le A sont dérivées,
Données et d'autre
protégées B
part le chirement asymétrique RSA pour authentier les deux extrémités IPsec.
chiffrement asymétrique RSA pour authentifier les deux extrémités IPsec.
Le protocole IKEv2 a également un processus de négociation en deux phases sucessives : (1) La première
phase, appelée IKE_SA_INIT, consiste à protéger les paramètres SA IKE ; et (2) la deuxième phase, appelée
CREATE_CHILD_SA, permet de créer la SA Child qui est le terme que donne IKEv2 au SA IPsec. Durant
cette phase, il est possible de créer des SA Child supplémentaires en utilisant un nouveau tunnel. De nouvelles
B A B
otégées protégées
blir un tunnel IPsec entre deux extrémité IP, le protocole IKEv1 doit établir une SA
tte opération CHAPITRE
est nécessaire 5. SÉCURITÉ
pour sécuriser lesAU NIVEAU
échanges chaque paire
RÉSEAU
entre d’entités
: PROTOCOLE IPSEC 61
ocole IKEv2 IKE_SA_INIT

(2 à 4 messages)
par Cisco et Microsoft, IKEv2 est le successeur
mparé à ce dernier, le protocole IKEv2 est
et facile à configurer. Il a été initialement défini CREATE_CHILD_SA
lement mis à jour par le RFC 7296. (2 messages)
Ev1, IKEv2 se base sur une seule procédure

nt uniquement 4 messages, en considérant les CREATE_CHILD_SA (opt.)
Aggressive) comme obsolètes [5]. (2 messages)
aramètres de sécurité, IKEv2 utilise d’une part,

ellman pour mettre en place un secret pré-partagé
chiffrement sont dérivées, et d’autre part le A Données protégées B
RSA pour authentifier les deux extrémités IPsec.
Figure
également un processus de négociation en deux phases5.12
sucessives : (1) La première
Phases du protocole IKEv2
NIT, consiste à protéger les paramètres SA IKE ; et (2) la deuxième phase, appelée
ermet de créer la SA Child qui est le terme que donne IKEv2 au SA IPsec. Durant
Le protocole IKEv2 a également un processus de négociation en deux phases sucessives : (1) La
de créer des SA Child supplémentaires en utilisant un nouveau tunnel. De nouvelles
première phase, appelée IKE_SA_INIT, consiste à protéger les paramètres SA IKE ; et (2) la deuxième
de nouvelles combinaisons d'algorithmes de chiffrement et de hachage peuvent être
phase, appelée CREATE_CHILD_SA, permet de créer la SA Child qui est le terme que donne IKEv2
e CREATE_CHILD_SA.
au SA IPsec. Durant cette phase, il est possible de créer des SA Child supplémentaires en utilisant
P un nouveau tunnel. De nouvelles valeurs Die-Hellman et de nouvelles combinaisons d'algorithmes de

chirement et de hachage peuvent être négociées lors de l'échange CREATE_CHILD_SA.
nternet Security Association and Key Management Protocol) consiste à définir des
5.7.2
de paquets pour établir,Protocole ISAKMP
négocier, modifier et supprimer des SA entre deux extrémités
Le protocole ISAKMP (Internet Security Association and Key Management Protocol) consiste à
ns le RFC 2408, ISAKMP a été conçu en étant distingué des protocoles d'échange
dénir des procédures et des formats de paquets pour établir, négocier, modier et supprimer des SA
de séparer clairement
entre deuxlaextrémités
gestion desIPsec
SA et le mécanisme de l'échange des clés.
[46].
Initialement déni dans le RFC 2408, ISAKMP a été conçu en étant distingué des protocoles
d'échange de clés, tel que IKE, an de séparer clairement la gestion des SA et le mécanisme de l'échange
des clés. ISAKMP sert de cadre commun aux
Sécurité des réseaux 2018-2019 – Semestre
nombreux
Page 6et diérents
2 sur 8 protocoles d'échange
Université Constantine 2 de clés,
chacun avec des propriétés de sécurité diérentes. En eet, un cadre commun est nécessaire pour
accepter le format des attributs SA et pour négocier, modier et supprimer des SA. En centralisant
ISAKMP sert de cadre commun aux nombreux et différents protocoles d'échange de clés, chacun avec des
la gestion propriétés
des SA, deISAKMP réduit la
sécurité différentes. Enquantité de fonctionnalité
effet, un cadre reproduite
commun est nécessaire dans lechaque
pour accepter protocole de
format des
sécurité. attributs SA et pour négocier, modifier et supprimer des SA. En centralisant la gestion des SA, ISAKMP réduit
la quantité deISAKMP
Concrètement, fonctionnalité
estreproduite dans chaque
un protocole protocole de
applicatif sécurité. UDP sur le port 500. Il dénit des
utilisant
payloads pourConcrètement,
l'échange ISAKMP
des clésest
etunles données
protocole d'authentication.
applicatif Les500.
utilisant UDP sur le port formats
Il définitISAKMP
des payloadsfournissent
pour l’échange
un cadre cohérent pourdesle
clés et les données
transfert desd'authentification. Les formats ISAKMP
clés qui est indépendant de la fournissent
technique un de
cadre cohérent
génération de clés,
pour le transfert des clés qui est indépendant de la technique de génération de clés, de l'algorithme de
de l'algorithme de chirement et du mécanisme d'authentication. La structure d'un entête ISAKMP
chiffrement et du mécanisme d'authentification.
est présentée dans la gure 5.13.
La structure d’un entête ISAKMP est la suivante :
Byte 0 1 2 3
0..3
Initiator cookie
4..7
8..11
Responder cookie
12..15
16..19 Next payload Major ver. Minor ver. Exchange type Flags
20..23 Message ID
24..27 Length
Initiator cookie (8 octets) : le cookie de l'entité qui a initié l'établissement, la notification ou la
Figure
suppression de la SA, 5.13 Structure d'un entête ISAKMP
Responder cookie (8 octets) : le cookie de l'entité qui répond à une demande d'établissement, de
notification ou de suppression de la SA,
Next payload (1 octet) : le type du premier payload dans le message (0=None, 1=SA, 2=Proposal,
3=Transform, …),
Major version (1/2 octet) : la version maximale du protocole ISAKMP utilisée,
Minor version (1/2 octet) : la version minimale du protocole ISAKMP utilisée,
La structure d’un entête ISAKMP est la suivante :
Byte 0 1 2 3
0..3
Initiator cookie
4..7
8..11
Responder cookie
12..15
Initiator cookie (8 octets) : le cookie de l'entité qui a initié l'établissement, la notication
16..19 Next payload Major ver. Minor ver. Exchange type Flags
ou la suppression
20..23 de la SA, Message ID
Responder
24..27 cookie (8 octets) : le cookie deLength
l'entité qui répond à une demande d'établissement,
de notication ou de suppression de la SA,
Initiator cookie (8 octets) : le cookie de l'entité qui a initié l'établissement, la notification ou la
Next payload
suppression(1 octet)
de la SA, : le type du premier payload dans le message (0=None, 1=SA,
2=Proposal, 3=Transform,
Responder . . . ),:
cookie (8 octets) le cookie de l'entité qui répond à une demande d'établissement, de
Major version
notification(1/2 octet) : dela laversion
ou de suppression SA, maximale du protocole ISAKMP utilisée,
Minor version (1/2 octet) : la version minimale
Next payload (1 octet) : le type du premier payload dansdu
le message (0=None,
protocole ISAKMP1=SA, 2=Proposal,
utilisée,
3=Transform, …),
Exchnage type (1 octet) : le type d'échange utilisé (0=None, 1=Base, 2=Identity protection,
Major version (1/2 octet) : la version maximale du protocole ISAKMP utilisée,
3=Authentication only, . . . ). Cela dicte les commandes de message et de payload dans les
Minor version (1/2 octet) : la version minimale du protocole ISAKMP utilisée,
échanges ISAKMP,
Exchnage type (1 octet) : le type d'échange utilisé (0=None, 1=Base, 2=Identity protection,
Flags (13=Authentication
octet) : les only,options…). Cela dicte les
dénies pourcommandes
l'échangede message
ISAKMP, et de payload dans les échanges
Message ID (4 octets) : une valeur unique aléatoire utilisée généré par l'initiateur de la
ISAKMP,
Flags (1 octet) : les options définies pour l'échange ISAKMP,
négociation pour identier l'état du protocole lors des négociations de la phase 2,
Length (4 octets) : la longueur totale (en octets) de l'entête ISAKMP et des payloads encap-
Message ID (4 octets) : une valeur unique aléatoire utilisée généré par l’initiateur de la négociation
pour identifier l'état du protocole lors des négociations de la phase 2,
sulées.
Length (4 octets) : la longueur totale (en octets) de l'entête ISAKMP et des payloads encapsulées.
Sachant que les données d'un message ISAKMP sont organisées en plusieurs payload. De ce fait,
Sachant que
l'entête ISAKMP lessuivi
est données d’unou
d'un message ISAKMP
plusieurs sont organisées
payloads dont la en structure
plusieurs payload. De ce fait,
est dénit dans l’entête
la gure 5.14.
ISAKMP est suivi d’un ou plusieurs payloads de la forme suivante :
Byte 0 1 2 3
0..3 Next payload Reserved Data length
4..n data
Next payload (1 octet) : le type du premier payload dans le message (0=None, 1=SA, 2=Proposal,
3=Transform, …), Figure 5.14 Structure d'un payload ISAKMP
Reserved (1 octet) : ce champ est réservé pour une utilisation future. Actuellement, il est mis à 0,
Next payload
Data length(1(1 octet)
octet) : La :longueur
le type(en du
octets) des données
premier du payload,
payload dans le message (0=None, 1=SA,
Data (taille variable) : les
2=Proposal, 3=Transform, . . . ), données du payload,
Reserved (1 octet) : ce champ est réservé pour une utilisation future. Actuellement, il est
mis à 0,
Data length (1 octet) : La longueur (en octets) des données du payload,
Data
© Dr.(taille variable) : les données du payload,
R. Boukharrou Page 7 sur 8
5.8 Conclusion
Le protocole IPsec permet de chirer les paquets IP qui quittent le réseau et d'authentier les pa-
quets qui y entrent. En eet, l'authentication et le chirement sont des services de sécurité nécessaires
dans les réseaux IP de nouvelle génération, tel que IPv6. En eet, en implémentant la sécurité au niveau
IP, l'entreprise peut garantir une mise en réseau sécurisée non seulement pour les applications dotées
de mécanismes de sécurité, mais également pour les nombreuses applications ignorant la sécurité.
Chapitre 6
Chirement de bout-en-bout : Protocole

SSL/TLS
6.1 Introduction
La communication de bout en bout est un principe central de l'architecture du réseau Internet. Il
consiste à situer le contrôle et le traitement des communications au niveau des extrémités d'un réseau,
plutôt que de le gérer au niveau de ses équipements intermédiaires (routeurs, passerelles, etc.). Ainsi,
la complexité et l'intelligence du réseau sont repoussées vers ses extrémités.
Le chirement de bout en bout (en anglais, End-to-End Encryption E2EE) est un système de
communication qui garantit la protection des données de client à client, c'est-à-dire, seule la personne
avec qui vous communiquez peut lire les messages échangés. En eet, lorsqu'un message est envoyé à
un destinataire, celui-ci est chiré à l'aide d'une clé cryptographique, dite de chirement, au lieu d'être
envoyé en clair. À la réception, seul le destinataire prévu du message peut déchirer le message, en
utilisant une clé de déchirement.
En pratique, au niveau de l'expéditeur, les messages sont chirés localement avant même d'être en-
voyés au destinataire sur le réseau. Tout équipement intermédiaire du réseau, ne fait rien d'autre que de
relayer le message chiré jusqu'au destinataire. La communication est ainsi sécurisée indépendamment
des équipements intermédiaires du réseau.
Les systèmes de chirement de bout en bout sont conçus pour résister à toute tentative de sur-
veillance ou de falsication, car aucun tiers n'est en mesure d'accéder aux clés cryptographiques né-
cessaires pour déchirer les données communiquées. Ainsi, la majorité des attaques passives ou même
actives sont évitées, tels que le rejeu ou la modication de message.
Cependant, le chirement de bout en bout ne réduit pas les risques au niveau des extrémités, car
les machines de l'expéditeur ou du destinataire d'un message peuvent être piratées pour voler une clé
cryptographique, servant à usurper leur identité.
Au fur et à mesure qu'Internet se développait, les entreprises de e-commerce commencent à croître
régulièrement, mais cette nouvelle économie restait modeste tant que les clients n'avaient pas une
conance susante dans le paiement en ligne. La solution consistait donc à sécuriser les paiements
en ligne en utilisant des protocoles d'authentication et de chirement tel que le protocole SSL/TLS.
En eet, une session chirée est établie pour empêcher un tiers d'intercepter des données sensibles
transitant par le réseau comme le numéro de carte lors d'un paiement.
6.2 Protocole SSL/TLS

SSL/TLS
1 est un protocole de sécurisation des échanges, développé en 1994 par la société Netscape
sous le nom de SSL (Secure Socket Layer). Il a été intégré dans la plupart des navigateurs Web depuis
1. Depuis quelques années, SSL est devenu fondamentalement obsolète, car TLS ore un niveau de sécurité supérieur,
mais certaines personnes ont pris l'habitude de se référer au protocole SSL, c'est pourquoi, par abus de langage, on parle
de SSL/TLS pour désigner indiéremment SSL ou TLS.
63
CHAPITRE 6. CHIFFREMENT DE BOUT-EN-BOUT : PROTOCOLE SSL/TLS 64
1996. En 1999, la vesrion 3.1 de SSL est baptisée TLS (Transport Layer Security) en étant normalisé
à l'IETF dans le RFC 2246.
Aujourd'hui, TLS est adopté par l'ensemble des protocoles applicatifs sur Internet pour l'authen-
tication et le chirement des données entre clients et serveurs. En eet, il se place entre la couche
application et la couche transport du modèle TCP/IP, permettant d'assurer la condentialité, l'au-
thentication et l'intégrité des données lors de la transmission des données. Étant indépendant des
protocoles applicatifs, il est transparent pour l'utilisateur et ne nécessite pas de modication profonde
au niveau Application, ce qui a permis à l'utiliser aussi bien pour sécuriser une transaction Web, l'envoi
ou la réception d'email, ou même le transfert de chiers.
Le protocole se développe et évolue tout en étant indépendant des algorithmes de chirement et
d'authentication. Cela lui permet à tout moment de s'adapter aux besoins des utilisateurs et aux
législations en vigueur. En eet, SSL/TLS n'est pas soumis aux évolutions théoriques de la crypto-
graphie, c'est-à-dire si un chirement devient obsolète, le protocole reste exploitable en choisissant un
chirement réputé sûr, ce qui lui assure une meilleure sécurité [22].
SSL et TLS garantissent les services de sécurité suivants :
Authentication : Le client doit pouvoir s'assurer de l'identité du serveur à travers son cer-
ticat qui accompagne le message. Depuis SSL 3.0, le serveur peut aussi demander au client de
s'authentier ;
Condentialité : Le client et le serveur doivent avoir l'assurance que leur conversation ne
pourra pas être écoutée par un tiers. Cette fonctionnalité est assurée par les clés symétriques
de session ;
Identication et intégrité : Le client et le serveur doivent pouvoir s'assurer que les messages
transmis ne sont ni tronqués ni modiés, qu'ils proviennent bien de l'expéditeur attendu. Ceci
est assuré par la signature des données échangées.
SSL et TLS reposent donc sur la combinaison de plusieurs concepts cryptographiques, appelée suite
de chirement :
Certicats : pour l'authenticité de la clé publique du serveur et du client
Signature numérique : pour l'identication de l'émetteur des messages et des certicats
Fonction de hachage : pour l'intégrité des messages et des certicats
Chirement asymétrique : pour la signature numérique en utilisant la clé privée et pour la
condentialité des clés de session en utilisant la clé publique
Chirement symétrique : pour la condentialité des messages échangés
6.2.1 Historique
La première version (1.0) de SSL a été développée par Netscape Communication Corporation en
1994. L'objectif de Netscape était de créer un canal sécurisé où les données pourraient transiter entre un
client et un serveur, indépendamment de la plateforme et du système d'exploitation. Quoique SSL soit
destiné à l'origine à sécuriser uniquement les transactions entre un client et un serveur web (HTTP),
la spécication a été conçu de façon que les autres protocoles de niveau application puissent l'exploiter
comme FTP, Telnet, etc. La spécication SSL 1.0 n'avait servi qu'en interne et ne fut jamais publiée.
En février 1995, Netscape publie la version 2.0 du protocole en l'implémentant dans la première
version de son navigateur Web. SSL 2.0 permettait au client de vérier l'authentication du serveur
en utilisant un certicat serveur au format X.509v3. Par ailleurs, Cette version présente des lacunes
importantes, telle que l'attaque DROWN, ce qui a poussé à sa bannissement en 2011 (RFC 6176).
En novembre 1996, Conscient des faiblesses de SSL 2.0, Netscape publie la version 3.0. Par rapport
à la version 2.0, SSL 3.0 permettait en plus au serveur, d'authentier le client. En eet, le client pouvait
exploiter sa clé privée tout en fournissant son certicat qui prouve son authenticité. Cette version est
restée active et très largement utilisée pendant près de 18 ans, toutefois, elle a été bannie en 2014, à
la suite de la publication de la faille POODLE (RFC 7568) [47].
En janvier 1999, pour concilier les divergences entre Microsoft et Netscape concernant l'évolution
de SSL, le protocole est coné à l'IETF (Internet Engineering Task Force) pour poursuivre le déve-
loppement de SSL en le rebaptisant Transport Layer Security (TLS). TLS 1.0 ne constituait qu'une
évolution assez légère de SSLv3, en eet, en interne l'identication de version est SSL 3.1. TLS révise
cependant une partie de l'établissement de la liaison (le handshake) et apporte de la exibilité avec
l'introduction d'extensions optionnelles sous forme de RFC, qui permettent de faire évoluer le protocole
sans revoir ses bases et constamment réviser son numéro de version. D'ailleurs, en 2002, TLS 1.0 a
bénécié des nouvelles méthodes de chirement, tel que AES, qui a permi de remplacer le chirement
symétrique DES.
Depuis qu'il a été repris par l'IETF, le protocole SSL/TLS a connu trois nouvelles versions : TLS
1.1 en 2006, TLS 1.2 en 2008 et TLS 1.3 en 2018. Selon la RFC 4346, TLS 1.1 est une version de
transition qui consolide certaines RFC intermédiaires qui a amélioré le processus de génération de clés
pour une protection contre les attaques BEAST et CBC.
Etant actuellement la version la plus utilisée de SSL/TLS, TLS 1.2 a apporté plusieurs améliora-
tions en matière de sécurité par rapport à TLS 1.1 : (1) Utilisation des algorithmes de hachage plus
sécurisés tel que SHA-256 ; (2) l'ajout d'extensions TLS et des suites de chirement AES ; ainsi que (3)
l'utilisation de suites de chirement avancées prenant en charge la cryptographie à courbe elliptique
2
(ECC ) [30].
Test des capacités SSL/TLS d'un serveur :

SSL Labs est un service Web gratuit permettant d'analyser en profondeur la conguration
de tout serveur Web sécurisé sur Internet. Il permet aussi de tester les capacités sécuritaire
SSL/TLS de votre navigateur Web.
À travers un test SSL Labs, il est possible de vérier le protocole SSL/TLS, utilisé par un
serveur Web "https ://". En eet, les résultats fournissent des informations sur la sécurité
du serveur Web, à savoir, la version du protocole, les suites de chirement, etc.
Lien : https://www.ssllabs.com/ssltest/
Bien que TLS 1.2 ait apporté d'importantes améliorations de sécurité par rapport à ses prédéces-
seurs, la version 1.3 vise à améliorer encore plus la sécurité et la performance du protocole. En eet,
TLS 1.3 ne prend plus en charge les chirements inutiles ou vulnérables, tels que le mode CBC et
le chirement RC4, car ces chirements sont sensibles aux attaques. Désormais, il utilise un nouveau
protocole de négociation amélioré appelé "Reprise du temps aller-retour à zéro, abrégé en 0-RTT".
Auparavant, avec TLS 1.2, un aller-retour était nécessaire pour les reprises de sessions. Par ailleurs,
la sécurité est renforcée en incluant de nouveaux algorithmes de chirement et de hachage, tels que
x25519, EdDSA, ChaCha20, etc.
Actuellement, toutes les versions de SSL sont bannis par Netscape, IETF, les systèmes d'exploita-
tion et les navigateurs Web en raison des failles de sécurité découvertes et des algorithmes de chirement
dépassés. Dans le cas de TLS, ses versions 1.0 et 1.1 sont dépréciées aussi depuis 2018 par l'IETF pour
la même raison [64], tandis que TLS 1.2 subira le même sort, quelques temps après le lancement de
TLS 1.3 en mars 2018, même si, aujourd'hui, TLS 1.2 est la version la plus utilisée. cinq ans après les
révélations d'Edward Snowden, TLS 1.3 apporte plus de simplicité, de vitesse et de sécurité.
L'ensemble des protocoles SSL et TLS est décrit dans l table récapitulative 6.1.
6.2.2 Architecture du protocole

Le protocole SSL/TLS est un moyen de sécuriser la couche application. Il est conçu pour utiliser
le protocole TCP an de fournir un service sécurisé de bout en bout able. SSL/TLS n'est pas un
protocole unique, mais plutôt deux couches successives de sous protocoles : (1) Une couche inférieure
constituée du protocole Record qui permet de fournir des services de sécurité de base aux protocoles
de la couche supérieure ; (2) Les protocoles de cette dernière sont : Handshake, Alert, Change Cipher
Spec et Application Data. Dans cette section, c'est la version 1.2 du protocole TLS qui sera décrite.
Comme première étape, le client et le serveur commence par eectuer la négociation an de con-
gurer la transaction et d'échanger les clés de chirement grâce au protocole Handshake. L'étape de
2. ECC : Elliptic Curve Cryptography

Version Sortie Développé RFC Description

Non publié donc jamais utilisé, Sécurisation des
SSL 1.0 1994 Netscape
communications client/serveur
Pas d'authentication du client, Chirement
SSL 2.0 1995 Netscape
léger, Banni en 2011 (RFC 6176)
Authentication mutuelle entre le serveur et le
SSL 3.0 1996 Netscape 6101 client, Vulnérable aux attaques POODLE,
• Bannide
Version en 2015 (RFC 7568)
transition
TLS 1.1 2006 IETF 4346 • prévient les attaques
La phase BEAST est améliorée,
de handshake
TLS 1.0 1999 IETF 2246 • Déprécié depuisdu
Intégration 2018 et sera banniAES,
chirement en 2020
Déprécié
(SSL 3.1) • Ladepuis
plus utilisée actuellement
2018 et sera banni en 2020
TLS 1.2 2008 IETF 5246
• Intégration du chiffrement ECC
Version de transition, Prévient les
TLS 1.1 2006 IETF 4346
• Plus de simplicité, et vitesse de négociation
attaques BEAST, Déprécié depuis 2018 et sera
TLS 1.3 2018 IETF 8446 • Sécurité renforcée incluant de nouveaux algo.
banni en 2020
(x25519, EdDSA, ChaCha20, …)
La plus utilisée actuellement, Intégration du
TLS 1.2 2008 IETF 5246
chirement ECC
1.2. Architecture du protocole
Plus de simplicité, et vitesse de négociation,
TLSLe1.3
protocole SSL/TLS est un moyen de sécuriser la couche application. Il est conçu pour utiliser le protocole
2018 IETF 8446 Sécurité renforcée incluant de nouveaux algo.
TCP afin de fournir un service sécurisé de bout en bout fiable. SSL/TLS n'est pas un protocole unique, mais
(x25519, EdDSA, ChaCha20, ...)
plutôt deux couches successives de sous protocoles : (1) Une couche inférieure constituée du protocole Record
qui permet de fournir des services de sécurité de base aux protocoles de la couche supérieure ; (2) Les
protocoles de cette dernièreTable 6.1 Versions
sont : Handshake, Alert,du protocole
Change CipherSSL/TLS
Spec et Application Data. Dans cette
section, c’est la version 1.2 du protocole TLS qui sera décrite.
Comme
négociation première par
est clôturée étape,l'envoi
le client
deetmessages
le serveur commence par effectuer
du protocole ChangelaCipher
négociation
Spec.afin de configurer
Après avoir établi
la transaction
une connexion et d’échanger
sécurisée, les clésetdelechiffrement
le client grâce au protocole
serveur peuvent s'échangerHandshake. L’étapesécurisées
des données de négociation est du
à l'aide
clôturée
protocole par l’envoi de
Application messages
Data. du protocole
En cas problème,Change Cipher Spec.
le protocole Aprèsémet
Alert avoir des
établimessages
une connexion sécurisée,
décrivant l'erreur
le client et le serveur peuvent s’échanger des données sécurisées à l’aide du protocole Application Data. En
produite. Tous ces messages de la couche supérieure de SSL/TLS sont englobés dans des enregistre-
cas problème, le protocole Alert émet des messages décrivant l’erreur produite. Tous ces messages de la couche
ments TLS du protocole Record.
supérieure de SSL/TLS sont englobés dans des enregistrements TLS du protocole Record.
Application
HTTPS FTPS SMTP-TLS IMAPS POPS
Change Application
Handshake Alert
SSL / TLS
Cipher Spec Data
Record
Transport TCP
Internet IP
Accès-au-réseau
1.2.1. Protocole Record

Figure 6.1 Architecture du protocole SSL/TLS
Comme pour un paquet TCP, tous les messages échangés par le protocole SSL/TLS aux niveaux du client et
du serveur sont encapsulés dans un enregistrement TLS, à l'aide du protocole Record. Pour leur transport,
Protocole Record
plusieurs enregistrements TLS peuvent être encapsulés dans un même paquet TCP, si celui-ci contient assez
d’espace. Le protocole Record consiste principalement à manipuler un enregistrement TLS, pour assurer la
confidentialité
Comme pour un d’un message
paquet TCP,en utilisant
tous lesunmessages
algorithmeéchangés
de chiffrement,
par leainsi que l’intégrité
protocole SSL/TLS du message en se du
aux niveaux
basant sur un code d'authentification de message (MAC).
client et du serveur sont encapsulés dans un enregistrement TLS, à l'aide du protocole Record. Pour leur

transport, plusieurs enregistrements TLS peuvent être encapsulés dans un même paquet TCP, si celui-
ci contient assez d'espace. Le protocole Record consiste principalement à manipuler un enregistrement
TLS, Sécurité
pour assurer la condentialité d'un message
des réseaux en– utilisant
2018-2019 Semestre 2 un algorithme de chirement,
Université ainsi
Constantine 2 que
l'intégrité du message en se basant sur un code d'authentication de message (MAC).
La structure d'un enregistrement TLS est décrite comme suit :
La structure d’un enregistrement TLS est décrite comme suit :
Byte 0 1 2 3
0 Content type
1..4 Version Length
5..n Payload
Sécurité des type (1 octet) : un identifiant2018-2019
réseaux
Content – Semestre
permettant de spécifier
2 le type de l’enregistrement c’est-à-dire2
Université Constantine
le protocole de la Figure
couche 6.2 Structure
supérieure d'un message "Record"
: change_cipher_spec(0x20), alert(0x21), handshake(0x22),
application_data(0x23) ;
Content
La structure type
d’un
Version (2 (1 octet)
enregistrement
octets) : version
: laTLS unestidentiant
décrite comme
de SSL/TLS suitutilisée
:
permettant :deSSLv3.0(0x0003),
spécier le typeTLSv1.0(0x0301),
de l'enregistrement
TLSv1.1(0x0302),
c'est-à-dire le protocole
Byte TLSv1.2(0x0303),
de
0 la couche TLSv1.3(0x0304)
supérieure
1 : ;
change_cipher_spec(0x20),
2 3 alert(0x21), hand-
Length (2application_data(0x23)
shake(0x22), octets) : La longueur
0 14 Content type en octets
; des données (Payload), ce qui impose une taille maximale
Version (2 octets) : la version de SSL/TLS utilisée : SSLv3.0(0x0003), TLSv1.0(0x0301),
de 16 Ko (2 ) à chaque enregistrement TLS ;
1..4 Version Length
Payload (≥ 1 octet)
TLSv1.1(0x0302), : Des données vuesTLSv1.3(0x0304)
TLSv1.2(0x0303), comme un bloc indépendant
; à traiter par le protocole de niveau

supérieur5..n
Length (2 octets) :
spécifié dans "Content type". Payload
La longueur en octets des données (Payload), ce qui impose une taille
1.2.2. Content de type
Protocole
maximale 16 Ko(1 octet)
(214): à
Handshake unchaque
identifiant permettant de spécifier
enregistrement TLS ; le type de l’enregistrement c’est-à-dire
Payload
Considéré
le (≥ 1leoctet)
protocole
comme protocole: de
de la
application_data(0x23)
couche
Des
supérieure : change_cipher_spec(0x20), alert(0x21), handshake(0x22),
données vues comme un bloc indépendant à traiter par le protocole
; configuration de SSL/TLS, le protocole Handshake se charge de la négociation
de niveau
entre supérieur
le client et spécié
le serveur et dans "Content
de leur authentification. Entype".
effet, il négocie les paramètres de chiffrement qui seront
Version (2 octets) : la version de SSL/TLS utilisée : SSLv3.0(0x0003), TLSv1.0(0x0301),
à l’œuvreTLSv1.1(0x0302),
lors de la connexion. Lorsqu'un client et un serveur
TLSv1.2(0x0303), TLSv1.3(0x0304) commencent
; à communiquer :
Protocole 1) Handshake
Ils se mettent
Length d’accord
(2 octets) : La sur une version
longueur de protocole
en octets ; (Payload), ce qui impose une taille maximale
des données
2) de 16
Ils Ko (214) à chaque
sélectionnent une enregistrement
suite de chiffrementTLS ; ensemble d’algorithmes de chiffrement) supportée par
(un
Considéré comme le protocole de conguration de SSL/TLS, le protocole Handshake se charge de
les deux parties
Payload ; : Des données vues comme un bloc indépendant à traiter par le protocole de niveau
(≥ 1 octet)
la négociation entre le client et le serveur et de leur authentication. En eet, il négocie les paramètres
supérieur spécifié dans eux
3) Ils s'authentifient entre "Content
; type".
de chirement qui seront à l'÷uvre lors de la connexion. Lorsqu'un client et un serveur commencent à
4) Protocole
1.2.2. Ils générentHandshake
des secrets partagés.
communiquer :
Ce protocole
Considéré est utilisé
comme pour ouvrir
le protocole une sessionde
de configuration sécurisé
SSL/TLS,avant
le l'envoi desHandshake
protocole données d'application.
se charge de la Il négociation
consiste en
1. Ils se mettent d'accord sur une version de protocole ;
une série
entre de messages
le client échangés
et le serveur parauthentification.
et de leur le client et le serveur, quiilont
En effet, tous les
négocie le format suivant
paramètres :
de chiffrement qui seront
2.à l’œuvre
Ils sélectionnent une suite
lors de la connexion. de chirement
Lorsqu'un client et un(un ensemble
serveur d'algorithmes
commencent de chirement)
à communiquer : supportée
Byte 0 1 2 3
par les deux parties ;
1) Ils se mettent0 d’accord
Handshake sur unetypeversion de protocole ; Length
3. Ils2)s'authentient
Ils sélectionnent entre eux ;
une suite de chiffrement (unContent ensemble d’algorithmes de chiffrement) supportée par
4..n
les deux des
4. Ils génèrent parties ;
secrets partagés.
Handshake
3) Ils type entre
s'authentifient (1 octet)
eux :; Un identifiant permettant de spécifier le type de message Handshake ;
Ce protocole est(2utilisé pour ouvrir une session sécurisé avant l'envoi des données d'application. Il
4) Ils générent des secrets partagés. en octets de Content ;
Length octets) : La longueur
consiste en une série de messages échangés par le client et le serveur, qui ont tous la structure de la
Content (≥ 0 octet) : Ensemble des paramètres du message Handshake selon le type. Le tableau
gureCe protocole est utilisé pour ouvrir une session sécurisé avant l'envoi des données d'application. Il consiste en
6.3. suivant énumère les types avec les paramètres nécessaires pour chacun des types [5] :
une série de messages échangés par le client et le serveur, qui ont tous le format suivant :
Handshake type Content (Paramètres)
Byte
hello_request(0) 0 / 1 2 3
client_hello(1)0 Handshake type version, random, session_id, Length
cipher_suite, compression_method
4..n
server_hello(2) Content
version, random, session_id, cipher_suite, compression_method
server_hello_done(14)
Handshake type (1 octet) : Un / identifiant permettant de spécifier le type de message Handshake ;
certificate(11)
Length (2 octets) Figure 6.3
: La longueur chain_of_x509_certificates
Structure
en octets ded'un message
Content ; "Handshake"
certificate_request(13) type, authorities
Content (≥ 0 octet) : Ensemble des paramètres du message Handshake selon le type. Le tableau
Handshake type (1
certificate_verify(15)
suivant énumère les octet)
types avec :signature
Un identiant
les paramètres permettant
nécessaires pourde spécier
chacun le type
des types [5] : de message Hand-
shakeserver_key_exchange(12)
; parameters, signature
Length (2 octets)
client_key_exchange(16) : La longueur parameters, signature
en octets de Content ;
Content (≥ 0 octet) : Ensemble des paramètres du message Handshake selon le type. La
hello_request(0)
finished(20) /
hash_value
client_hello(1) version, random, session_id, cipher_suite, compression_method
table 6.2 énumère les types avec les paramètres nécessaires pour chacun des types [45].
server_hello(2) version, random, session_id, cipher_suite, compression_method
server_hello_done(14) /
certificate(11)
© Dr. R. Boukharrou chain_of_x509_certificates Page 6 sur 15
certificate_request(13) type, authorities
certificate_verify(15) signature
server_key_exchange(12) parameters, signature

hello_request(0) /
client_hello(1) version, random, session_id, cipher_suite, compression_method
server_hello(2) version, random, session_id, cipher_suite, compression_method
server_hello_done(14) /
certicate(11) chain_of_x509_certicates
certicate_request(13) type, authorities
certicate_verify(15) signature
ser- parameters, signature
ver_key_exchange(12)
client_key_exchange(16) parameters, signature
nished(20) hash_value
Table 6.2 Types de message Handshake SSL/TLS
Le processus de Handshake du protocole TLS 1.2, se déroule en quatre phases, comme illustré dans
la gure 6.4 :
Phase 1 : Établissement des capacités de sécurité
1. Le client envoie un message client_hello au serveur contenant les paramètres suivants :
version (2 octets) : Version la plus élevée et supportée du protocole,
random (32 octets) : Nonce composé d'un horodatage de 4 octets et d'une valeur aléatoire
de 28 octets générée par le client. La valeur obtenue servira comme signature des messages,
session_id : identiant de session de longueur variable, généralement de taille 32 octets,
cipher_suite : Liste des suites de chirement supportés par le client, classée par ordre
décroissant de préférence,
compression_method : liste des méthodes de compression prises en charge par le client,
par ordre décroissant de préférence.
2. Le serveur envoie un message server_hello au client avec les paramètres choisis, en particulier
la suite de chirement et la méthode de compression choisies ;
Phase 2 : Authentication du serveur

1. Le serveur envoie son certicat dans un message certicate au client pour l'authentication et
le partage de sa clé publique. Le certicat envoyé fait partie d'une chaîne de certicats X.509 ;
2. En option, le serveur peut demander un certicat au client à travers un message certicate_request,

en précisant notamment le type de certicat supporté ;
3. Le serveur envoie un message server_key_exchange contenant les paramètres du serveur d'échange

de clés, uniquement lorsque un algorithme de Die-Hellman est utilisé ;
4. Le serveur envoie un message server_hello_done pour annoncer la n de sa réponse ;

Client Serveur
Phase 1
Phase 2
Phase 3
Phase 4
Figure 6.4 Processus de Handshake SSL/TLS

Le processus de Hanshake du protocole TLS 1.2, se déroule en quatres phases, comme illustré dans la figure
ci-dessus :
Phase 1 : Établissement des capacités de sécurité
Suite
1) Lede chirement
client (Cipher
envoie un message suite) :au serveur contenant les paramètres suivants :
client_hello
• version (2 octets) : Version la plus élevée et supportée du protocole,
Bien que les• versions
random précédentes codent
(32 octets) : Nonce en dur
composé certaines
d’un primitives
horodatage de 4 octetscryptographiques dans
et d’une valeur aléatoire de le
protocole, TLS1.2 est entièrement
28 octets congurable,
générée par le en obtenue
client. La valeur permettant
serviraune grande
comme exibilité
signature dans la mise
des messages,
en ÷uvre de •la sécurité souhaitée.
session_id : identifiant de session de longueur variable, généralement de taille 32 octets,
Une suite de •chirement est une
cipher_suite sélection
: Liste de primitives
des suites cryptographiques
de chiffrement supportés par le et d'autres
client, classéeparamètres,
par ordre
qui sont utilisésdécroissant de préférence,
pour établir une connexion SSL/TLS. Ces paramètres sont :
• compression_method
L'algorithme : liste
d'échange de clés des méthodes
: RSA, de compression
DH, DHE, ECDHE prises en charge par le client, par
ordre décroissant de préférence.
L'algorithme d'authentication : Anonymous, RSA, DSA, DSS, ECDSA
2)L'algorithme
Le serveur envoie
de un message server_hello
chirement au client de
avec la longueur avecclé
les paramètres
utilisée : choisis, en particulier la
DES(_40|_56|_128),
suite de chiffrement et la méthode de compression choisies ;
3DES_EDE(3), AES(_128|_256|_512), RC2(_128|_256), RC4(_40|_56), CAMILLA,
SEED
Suite de chiffrement (Cipher suite)
Le mode d'opération : ECB, CBC, GCM
Bien que les versionsdeprécédentes
L'algorithme générationcodent en dur: certaines
du MAC primitives
Null, MD5, SHA1, cryptographiques
SHA256, SHA384 dans le protocole,
TLS1.2 est entièrement configurable, en permettant une grande flexibilité dans la mise
En pratique, une suite de chirement est écrite sous forme d'une concaténation des noms des
en œuvre de la
sécurité souhaitée.
algorithmes utilisés, séparés par le caractère "_", par exemple :
La Une suite
suite de de chiffrementTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
chirement est une sélection de primitives cryptographiques et d'autres paramètres, qui sont
signie que :
TLS
utilisés pour(par
établirdéfaut) : est SSL/TLS.
une connexion Ces utilisé
le protocole paramètres
; sont :
ECDHE : correspond
L’algorithme d'échangeà de
l'algorithme utilisé
clés : RSA, DH, DHE,pour l'échange de clés. Il permet de générer
ECDHE
des paires de clés asymétriques temporaires pour l'échange de clé de session.
RSA : est l'algorithme utilisé pour la signature numérique ;
AES_128_GCM : correspond à l'algorithme utilisé pour le chirement symétrique basé
sur une clé de 128 bits, en mode GCM (Galois Counter Mode) ;
SHA256 : est la fonction de hachage utilisé pour assurer l'intégrité des messages.
Phase 3 : Echange de clés

1. À la réception des messages du serveur, le client vérie que les paramètres de server_hello sont
acceptables, et son certicat est valide auprès de la CA qui l'a certié ;
2. Le client envoie son certicat (certicate) si celui-ci est demandé par le serveur. Si son certicat
n'est pas disponible, le client envoie une alerte no_certicate ;
3. La clé de session, appelée aussi Master Secret (MS), est calculée selon deux stratégies distinctes :
(a) Si la méthode d'échange de clés dénie dans la suite de chirement est l'algorithme RSA,
alors le client crée un secret préliminaire de 48 octets, appelé Pre-Master Secret (PMS), qui
servira à calculer la clé de session (MS). Ensuite, le client partage le secret PMS avec le
serveur dans un message client_key_exchange, après l'avoir chiré avec la clé publique du
serveur fournie dans le certicat ;
(b) Si la méthode d'échange de clés est basée sur l'algorithme Die-Hellman (ECDHE ), cela
3
signie que le secret PMS sera calculé conjointement et localement par les deux parties, le
client et le serveur. En eet, le client envoie ses paramètres d'échange de clés au serveur
dans un message client_key_exchange, sachant qu'auparavant le serveur avait envoyé ses
paramètres dans un message server_key_exchange ;
4. Le client et le serveur peuvent désormais générer la clé de session MS sur la base du secret PMS
et des deux nonces (Random) du client et du serveur ;
5. Si le client a envoyé auparavant son certicat au serveur, le client doit lui renvoyer un message
certicate_verify contenant sa signature pour une vérication explicite de son certicat.
Echange de clé :
L'échange de clés Die-Hellman basé sur les courbes elliptiques et les clés de session
éphémères (ECDHE), est la meilleure technique actuellement, car elle repose sur la per-
formance de l'algorithme des courbes elliptiques en termes de taille des clés et sur le secret
de transfert parfait (PFS) assuré par la combinaison de l'algorithme Die-Hellman et les
clés de session éphémères.
Aujourd'hui, tous les navigateurs populaires préfèrent le chirement qui repose sur
l'échange de clés ECDHE, ce qui rend l'utilisation de l'échange de clé basé sur RSA
dépréciée.
Phase 4 : Validation des stratégies de chirement

1. À travers le protocole Change Cipher Spec, le client envoie une notication pour signaler la
mise à jour des stratégies de chirement ;
2. Le client envoie aussi au serveur un message nished chiré en utilisant la clé de session MS,
pour annoncer la n réussie du handshake ;
3. À son tour, après avoir récupèré la notifcation change_cipher_spec, le serveur envoie également
au client un une notication ChangeCipherSpec suivi d'un message chiré nished.
Maintenant que la connexion sécurisée est congurée, le client et le serveur peuvent désormais
s'échanger des données chirées issues de la couche application.
Protocole Change Cipher Spec

Le protocole Change Cipher Spec consiste à signaler les transitions dans les stratégies de chirement.
En particulier, il permet d'annoncer la n du processus de Handshake en indiquant la mise en place
des algorithmes de chirement négocié. En eet, le message de ce protocole est envoyé à la fois par le
client et par le serveur pour informer la partie réceptrice que les données qui suivent seront sécurisées
par les clés qui viennent d'être négociées ou mises à jour.
Type (1 octet) : Une valeur toujours xée à 1.
3. ECDHE : Elliptic Curve Die-Hellman Ephemeral.
Maintenant que la connexion sécurisée est configurée, le client et le serveur peuvent désormais s’échanger des
Le protocole Change Cipher Spec consiste à signaler les transitions dans les stratégies de chiffrement. En
données chiffrées issues de la couche application.
particulier, il permet d’annoncer la fin du processus de Handshake en indiquant la mise en place des
1.2.3. desProtocole
Sécurité
algorithmes réseaux Change Cipher
de chiffrement négocié.Spec
En effet,2018-2019 – Semestre
le message 2
de ce protocole est envoyéUniversité
à la fois Constantine
par le client2 et
par
Le le serveur Change
protocole pour informer
CipherlaSpec
partieconsiste
réceptrice que les les
à signaler données qui suivent
transitions dans lesseront sécurisées
stratégies par les clés qui
de chiffrement. En
viennent d'être
particulier, négociées
il permet ou mises àlajour.
d’annoncer fin du processus de Handshake en indiquant la mise en place des
decryption_failed (21) Enregistrement déchiffré de manière non valide (padding !)
algorithmes de chiffrement
Byte négocié.
0 En effet, le message de ce protocole
1 d'une longueur est envoyé3 à la fois par le client et
2supérieure
record_overflow(22) Enregistrement reçu à 16 Ko
par le serveur pour informer la partie réceptrice que les données qui suivent seront sécurisées par les clés qui
0
decompression_failure(30) TypeDécompression
(1) échouée de l’enregistrement reçu (corrompu !) (F)
viennent d'être négociées ou mises à jour.
handshake_failure(40) Impossible de négocier des paramètres de sécurité acceptables (F)
Type (1 octet) : Une valeur toujours fixée à 1.
no_certificate (41)
1.2.4. Protocole
Figure
Byte
Alert
L’expéditeur
0 n’a pas 1 de certificat disponible
6.5 Structure d'un message "Change Cipher Spec"
2 3
bad_certificate(42)0 TypeCertificat
(1) reçu corrompu ou contient des signatures non-vérifiables
Le principal rôle de ce protocoleType
unsupported_certificate(43) est l’émission
du certificat reçu non pris
de messages en charge
d'alertes suites aux erreurs que peuvent s'échanger
Protocole
le clientAlert
Type (1 octet) : Une valeur toujours fixée à 1.
certificate_revoked(44)
et le serveur. Un message Certificat
d'alertereçu
estrévoqué
indiqué parpar son description et le niveau de gravité de l’alerte
unesignataire
1.2.4. Protocole
(avertissement
certificate_expired(45) Alert [6]. Les
ou fatal) messages
Certificat reçud'alerte
expiré avec un niveau fatal entraînent la fin immédiate de la
Le principal rôle de ce protocole est l'émission de messages d'alertes suites aux erreurs que peuvent
connexion.
principal rôle de
certificate_unknown(46) ce protocole est l’émission
Traitement du certificat reçu d'alertes
impossible
s'échanger le client et le serveur. Un messageded'alerte
Le messages est indiqué suites auxune
par erreurs que peuvent
description ets'échanger
le niveau de
3 niveau fatal l’alerte
illegal_parameter(47)
le client et le serveur. Un Paramètre
message d'alerte mal-formatté
est indiqué ou
par inattendu
une (F)
description et le niveau de gravité de
Byte
gravité de l'alerte (avertissement 0 ou fatal) [13].1Les messages 2d'alerte avec un entraînent
unknown_ca(48)
(avertissement ou fatal) [6]. Les Certificat
messages introuvable d’uneun
d'alerte avec desniveau
CA defatalla chaine des certificats
entraînent la fin immédiate de la
la n immédiate de0..1 la connexion.
Alert Level Type
access_denied(49)
connexion. L'expéditeur n'a pas procédé à la négociation
Level (1 octet) : NiveauMessage
decode_error(50) de gravité reçu l’alerte
den'a pas pu: warning(1),
être décodé fatal(2)
(champ mal formatté !)
Byte 0 1 2 3
Échec lors du déchiffrement d’un message
Type (1 octet) : Type d’alerte qui peut avoir les valeurs suivantes [7] :
decrypt_error(51)
0..1 Alert Level Type
export_restriction (60) Négociation non conforme aux restrictions à l'exportation
Type Description
protocol_version(70)
Level (1 octet) : Niveau Version
de gravité de l’alertenon
du protocole prise en charge
: warning(1), fatal(2)
close_notify(0)
insufficient_security(71) Figure Fin d’une connexion
Type (1 octet) : Type d’alerte 6.6
Chiffrements Structure
faibles
qui reçu d'un
proposés
peut inapproprié
avoir les valeurs message
par le "Alert"
client
unexpected_message(10) Message (F) suivantes [7] :
internal_error(80) Erreur interne non liée au protocole
Type
bad_record_mac(20) Description reçu avec un MAC incorrecte (F)
Enregistrement
Level (1 octet) : Niveau
user_canceled(90) de gravité
Handshake de l'alerte
annulée : warning(1),
par l'utilisateur (suivie d'unfatal(2)
close_notify)
Fin d’une connexion
Type (1 octet) : Type L’expéditeur
close_notify(0)
no_renegotiation(100) d'alerte quirefuse peutune renégociation
avoir les valeurs en suivantes
réponse à un hello
[49] :
unexpected_message(10) Message reçu inapproprié (F)
unsupported_extension(110) Extension non supportée
bad_record_mac(20) Enregistrement reçu avec un MAC incorrecte (F)
Protocole
© Dr. R.Application
Boukharrou Data Page 9 sur 15
1.2.5. Protocole Application Data
Toutes les données d'application transmises via TLS sont traitées et chirées à l'aide du protocole
Toutes les données d'application transmises via TLS sont traitées et chiffrées à l’aide du protocole Application
"Application Data", et transportées dans un enregistrement TLS.
Data, et transportées dans un enregistrement TLS.
Données d’application
Fragmentation
Compression (si ≤ SSL 3.0)
Ajout d’un MAC et d’un padding
Chiffrement
Message Application Data
Ajout d’une en-tête Record
Enregistrement TLS
À l’envoi d’un message issu de la couche Application, le protocole Application Data de l’émetteur effectue
Figure 6.7 Construction d'un message "Application Data"
les étapes suivantes en se basant sur la suite de chiffrement négociée lors du handshake :
1) Le protocole
À l'envoi Application
d'un message Data
issu de lareçoit
coucheles données issues du
Application, le protocole
protocole applicatif ;
Application Data de l'émetteur
14
eectue2)lesLes données
étapes reçues sont
suivantes en fragmentées en blocs
se basant sur de segment
la suite de 16 384 octets
de chirement maximum
négociée (2 handshake
lors du ); :
1. Le protocole Application Data reçoit les données issues du protocole applicatif ;

©
2.Dr.
LesR. Boukharrou Page 10 sur(214)
données reçues sont fragmentées en blocs de segment de 16 384 octets maximum 15 ;
3. En option, chaque segment est compressé en utilisant la méthode de compression dénie lors
du handshake, sachant qu'il n'y a plus de compression, à partir de SSL 3.0 ;
4. Un MAC est calculé à partir du segment puis ajouté à celui-ci pour assurer son intégrité ;
Type Description
close_notify(0) Fin d'une connexion
unexpected_message(10) Message reçu inapproprié (F)
bad_record_mac(20) Enregistrement reçu avec un MAC incorrecte (F)
decryption_failed (21) Enregistrement déchiré de manière non valide (padding !)
record_overow(22) Enregistrement reçu d'une longueur supérieure à 16 Ko
Décompression échouée de l'enregistrement reçu (corrompu !)
decompression_failure(30) (F)
Impossible de négocier des paramètres de sécurité acceptables
handshake_failure(40) (F)
no_certicate (41) L'expéditeur n'a pas de certicat disponible
Certicat reçu corrompu ou contient des signatures
bad_certicate(42) non-vériables
unsupported_certicate(43) Type du certicat reçu non pris en charge
certicate_revoked(44) Certicat reçu révoqué par son signataire
certicate_expired(45) Certicat reçu expiré
certicate_unknown(46) Traitement du certicat reçu impossible
illegal_parameter(47) Paramètre mal-formatté ou inattendu (F)
unknown_ca(48) Certicat introuvable d'une des CA de la chaine des certicats
access_denied(49) L'expéditeur n'a pas procédé à la négociation
decode_error(50) Message reçu n'a pas pu être décodé (champ mal formatté !)
decrypt_error(51) Échec lors du déchirement d'un message
export_restriction (60) Négociation non conforme aux restrictions à l'exportation
protocol_version(70) Version du protocole non prise en charge
insucient_security(71) Chirements faibles proposés par le client
internal_error(80) Erreur interne non liée au protocole
user_canceled(90) Handshake annulée par l'utilisateur (suivie d'un close_notify)
no_renegotiation(100) L'expéditeur refuse une renégociation en réponse à un hello
unsuppor- Extension non supportée
ted_extension(110)
Table 6.3 Types d'alertes Warning et Fatal (F)
5. Le segment est complété ensuite avec un padding, si le chirement par bloc est utilisé ;
3) En option, chaque segment est compressé en utilisant la méthode de comprésession définie lors du
6. Constitué de données compressées, d'un MAC et d'un padding le segment est chiré à l'aide de
handshake, sachant qu’il n’y a plus de compression, à partir de SSL 3.0 ;
la clé de session (MS) calculée auparavent lors du handshake ;
4) Un MAC est calculé à partir du segment puis ajouté à celui-ci pour assurer son intégrité ;
5) 7.
Le Le segment
segment résultant
est complété est mis
ensuite avec dans un enregistrement
un padding, si le chiffrementTLS, enest
par bloc ajoutant
utilisé ; une en-tête de Record ;
Constitué
6) 8. Enn, de donnéesenregistrement
chaque compréessées, d’un
TLSMAC estettransmis
d’un padding le couche
à la segment inférieure
est chiffré à pour
l'aide de
le la
transport, en
clél'occurrence,
de session (MS)lecalculée auparavent
protocole TCP. lors du handshake ;
7) Le segment résultant est mis dans un enregistrement TLS, en ajoutant une en-tête de Record ;
Du côté du récepteur, le même ux de travail, mais en sens inverse, est appliqué par le destinataire.
8) Enfin, chaque enregistrement TLS est transmis à la couche inférieure pour le transport, en loccurence,
En eet, le protocole Application Data du destinataire eectue les étapes suivantes :
le protocole TCP.
Du côté1.duUn segment
récepteur, est extrait
le même flux de àtravail,
partir de en
mais chaque enregistrement
sens inverse, est appliquéTLS
par le; destinataire. En effet,
le protocole Application Data du destinataire effectue les étapes suivantes :
2. Le segment est déchiré en utilisant la suite de chirement négociée, pour donner comme résul-
1) Untat, des est

segment données
extrait àcompressées suivi
partir de chaque d'un MACTLS
enregistrement et d'un
; padding ;
2) 3.
Le À
segment
l'aideest
du déchiffré en utilisant la suiteles
MAC accompagnant de données
chiffrementcompressées,
négociée, pourl'intégrité
donner comme résultat, des
de celles-ci est vériée en
données compressées suivi d’un MAC
appliquant la même fonction de hachage ;
et d’un padding ;
3) À l’aide du MAC accompagnant les données compressées, l’intégrité de celles-ci est vérifiée en
4. Les données du segment sont décompressé à l'aide de la méthode de compression ;
appliquant la même fonction de hachage ;
4) 5.
LesLes données
données résultantes
du segment à l’aide depuis
sont réassemblées,
sont décompressé la méthode de compression
transmises par le protocole
; Record au protocole
5) Lesapplicatif de la couche
données résultantes sont supérieure.
réassemblées, puis tranmises par le protocole Record au protocole
applicatif de la couche supérieure.
La structure d'un message "Application Data", est décrite dans la gure 6.8.
La structure d’un message Application Data, est la suivante :
Byte 0 1 2 3
0..n Compressed fragment
Données
n..n+4 MAC
chiffrées
n+4..p Padding (block ciphers only)
Compressed Fragment (≤ 214 octets) : un fragment compressé issu de la fragmentation des données
d’application ; Figure 6.8 Structure d'un message "Application Data"
MAC (4 octets) : Un MAC4 est un code de taille fixe accompagnant le fragment dans le but d'assurer
sonCompressed
intégrité, ayant Fragment
le même rôle (qu’une
≤ 214fonction
octets) de :hachage. Le MAC
un fragment comprend issu
compressé également
de la un
fragmentation
numéro de séquence afin que
des données d'application ; la perte et la répétition des messages soient détectables ;
MAC(≤(432 octets)
Padding : Un
octets) : un remplissage
MAC
4 est
d’octets qui peut
un code de être ajouté
taille xe pour forcer la longueur
accompagnant du
le fragment dans le
message à être un multiple
but d'assurer de la longueur
son intégrité, ayant le du même
chiffrement
rôle de bloc, dans
qu'une le casde
fonction d’un chiffrement
hachage. Le MAC com-
symétrique par bloc. Sa longueur ne dépasse pas 20 octets pour SSLv3, TLS 1.0 et TLS 1.1, et 32
prend également un numéro de séquence an que la perte et la répétition des messages soient
octets pour TLS 1.2.
détectables ;
Padding
1.3. Avantages (≤ 32 octets) : un remplissage d'octets qui peut être ajouté pour forcer la longueur
et limites
du message à être un multiple de la longueur du chirement de bloc, dans le cas d'un chirement
La sécurisation des connexions en utilisant SSL/TLS offre de nombreux avantages :
symétrique par bloc. Sa longueur ne dépasse pas 20 octets pour SSLv3, TLS 1.0 et TLS 1.1, et
SSL/TLS est facile à implémenter, à déployer et à utiliser ;
32 octets pour TLS 1.2.
Il est indépendant de la suite de chiffrement utilisée, donc celle-ci peut être changée à tout moment
pour améliorer la sécurité ;
6.2.3Il ne Avantages et limites
nécessite aucune manipulation des données issues des protocoles applicatifs ;
LaIl est compatible avec
sécurisation les réseaux NAT
des connexions et les pare-feux
en utilisant ;
SSL/TLS ore de nombreux avantages :
Le SSL/TLS
MAC qui accompagne
est facile à lesimplémenter,
données permetàde détecter toute
déployer et à falsification
utiliser ; ;
Il est
Il possible d’authentifier
est indépendant delelaclient et ledeserveur
suite à travers utilisée,
chirement des certificats
donc ; celle-ci peut être changée à tout
moment
Il est possiblepour améliorer
de reprendre la sécurité
les anciennes ;
sessions dans les nouvelles connexions.
Il ne nécessite aucune manipulation des données issues des protocoles applicatifs ;
4
MAC Il estAuthentication
: Message compatibleCode.
avec les réseaux NAT et les pare-feux ;
Le MAC qui accompagne les données permet de détecter toute falsication ;
Il est possible d'authentier le client et le serveur à travers des certicats ;
Il est possible de reprendre les anciennes sessions dans les nouvelles connexions.
Cependant, le protocole SSL/TLS possède les limites suivantes :
4. MAC : Message Authentication Code.

Étant implémenté entre la couche Transport et Application, SSL/TLS ne protège pas les entêtes
IP ;
Sachant que c'est un protocole stateful nécessitant toujours l'établissement d'une connexion,
SSL/TLS ne supporte pas les échanges sur UDP (stateless) ;
Il nécessite une implémentation spécique pour chacun des protocoles applicatifs, par exemple
HTTPS pour HTTP.
6.3 Implémentation de SSL/TLS

Comme SSL/TLS est un protocole situé entre la couche Application et la couche Transport, tous les
protocoles applicatifs utilisant TCP peuvent l'exploiter pour sécuriser leurs échanges, comme HTTPS
(pour sécuriser HTTP) ou FTPS (pour sécuriser FTP).
Généralement, un protocole applicatif basé sur SSL/TLS obtient un nouveau numéro de port par
5
l'IANA . Par exemple, HTTPS est associé au port 443. Dans certains cas, le même port est utilisé
avec et sans SSL/TLS, où la connexion est initiée en mode non chiré, ensuite un tunnel sera mis en
6
place au moyen du mécanisme StartTLS , c'est le cas par exemple des protocoles IMAP, SMTP ou
LDAP.
Dans cette section, nous exposons le fonctionnement des principaux protocoles applicatifs sécurisés,
à savoir HTTPS, FTPS, SSH, et 3D-Secure. Les protocoles de messagerie sécurisés seront abordés dans
le chaptire suivant.
6.3.1 Protocole HTTPS

HTTPS (HTTP over SSL) est une variante du protocole HTTP implémenté au-dessus de SSL/TLS,
apparue pour la première fois dans le navigateur Netscape en 1995 pour accompagner l'essor du com-
merce en ligne à l'époque (RFC 2818). Il était réservé aux transactions très sensibles, comme les
transactions bancaires et le commerce électronique. Actuellement, on considère qu'HTTPS est néces-
saire dès lors qu'un utilisateur est authentié sur un site Web, an de protéger sa session Web et ses
identiants de connexion. En eet, la majorité des implémentations de SSL/TLS se trouvent dans les
navigateurs et les serveurs Web.
Concrètement, l'accès à un serveur en utilisant le protocole HTTPS se fait dans une URL bap-
tisée "https ://" en se connectant au port par défaut 443. Au niveau des navigateurs, HTTPS est
représenté par le petit cadenas au niveau de la barre d'URL, qui permet, en cliquant dessus, d'obtenir
les informations détaillées sur certicat qui authentie le serveur. Toutefois, il existe un mécanisme,
appelé HSTS (HTTP Strict Transport Security), permettant d'indiquer au navigateur de demander
automatiquement des pages qui utilisent le protocole HTTPS, même si l'utilisateur saisit "http ://".
Le déroulement d'un échange HTTPS se fait comme suit :
1. Le navigateur fait une demande de transaction sécurisée au serveur en envoyant sa requête en

"https ://", il demande donc le certicat garantissant la clé publique du serveur ;
2. La phase de TLS Handshake s'eectue entre le navigateur et le serveur, et lorsque le navigateur

reçoit le certicat, il le vérie comme suit :
(a) Si le certicat du serveur est un certicat racine de conance ou signé par l'un des certicats
7
des CA de conance , en possession du navigateur ;
(b) Sinon, le navigateur envoie une requête OCSP au PKI signataire du certicat pour vérier
à distance la validité de celui-ci ;
3. Après que la phase TLS Handshake soit réussie, le navigateur et le serveur peuvent s'échanger
des messages chirés à travers le protocole Application Data de SSL/TLS.
5. IANA : Internet Assigned Numbers Authority.

6. StartTLS : est le protocole permettant d'améliorer une connexion classique vers une sécurisée en utilisant TLS.
7. Pour accéder aux certicats racines de conance stockés dans un navigateur Web (Chrome par exemple), il faut
aller à : Paramètre → Condentialité et sécurité → Gérer les certicats → Autorités de certication racines de conances.
6.3.2 Protocole 3D-Secure

Le pourcentage d'internautes utilisant une carte de crédit pour eectuer leur paiement en ligne ne
cesse de progresser. De nombreux protocoles de paiement électronique ont vu le jour. Aujourd'hui, le
protocole 3D-Secure (à l'origine, appelé 3D-SSL) est le plus couramment utilisé dû essentiellement à
son schéma simplié, et l'utilisation de SSL/TLS.
Généralisé depuis 2003, 3D-Secure est un protocole destiné principalement à la sécurisation des
paiements en ligne. Initialement développé par Visa et MasterCard, 3D-Secure permet de limiter les
risques de fraude à la carte de paiement sur Internet. Il est connu sous les appellations commerciales
Veried By Visa et MasterCard SecureCode.
Lors de chaque paiement en ligne, 3D-Secure consiste à authentier l'acheteur comme étant le
titulaire de la carte utilisée pour le paiement. En pratique, au moment d'un paiement en ligne, le
client doit, en plus d'introduire les informations de sa carte (numéro de la carte, date de validité
et cryptogramme), eectuer une étape supplémentaire. Cette étape exige au client de saisir un code
dynamique à usage unique, qu'il a reçu par SMS. Cette technique permet, d'une part, de conrmer au
vendeur que la carte est bonne et qu'elle n'a pas été volée, et d'autre part, d'assurer au client qu'aucune
utilisation malveillante de sa carte ne s'est réalisée.
Le concept de base du protocole consiste à lier le processus d'autorisation nancière avec une
authentication en ligne.
En eet, le schéma global de 3D-Secure est représenté par trois domaines (d'où le nom 3D pour
3-Domains), qui sont [17] : (1) Domaine acquéreur (Acquirer), le vendeur qui recevra les fonds ; (2) Do-
maine émetteur (Issuer), la banque qui a délivré la carte de paiement ; et (3) Domaine d'interopérabilité
(Interoperability), le système de carte bancaire tel que Visa ou MasterCard.
Concrètement, 3D-Secure utilise des messages XML envoyés via des connexions SSL, en se basant
sur des certicats numériques, pour garantir l'authentication du serveur et du client.
6.4 Protocole SSH

SSH (Secure SHell) est à la fois un programme et un protocole sécurisés de la couche Application
(RFC 4253). Mis au point en 1995 par le T. Ylönen, le protocole SSH a été conçu avec l'objectif de
remplacer les diérents protocoles non chirés dédié à l'accès en ligne de commande à une machine
distante, tels que Telnet , rlogin et rsh . Pour sécuriser les échanges, SSH impose un échange de clés
de chirement en début de connexion en se connectant au port par défaut 22. Par la suite, tous les
segments TCP sont authentiés et chirés.
Le protoocle SSH n'est pas basé sur SSL/TLS, mais présente beaucoup de similitudes avec celui-ci,
car les deux protocoles orent un chirement symétrique des données, une authentication du serveur
et client ainsi que des mécanismes d'intégrité des données.
Cependant, parmi les diérences entre SSL/TLS et SSH est que SSL/TLS utilise des certicats
X.509 pour l'authentication des serveurs et des clients, contrairement à SSH. En utilisant des certi-
cats, SSL/TLS nécessite donc également la présence des CA et des PKI. En plus d'être un protocole,
SSH est également un programme, qui permet aux utilisateurs de se connecter à un serveur distant,
de manière authentiée (username/password) et d'exécuter ainsi des commandes à distance, sachant
que SSL/TLS n'a pas cette capacité. Par ailleurs, SSH prend facilement en charge le multiplexage de
connexion, le contrôle de ux, et la gestion de terminaux.
Toutefois, SSH n'est pas transparent par rapport à SSL/TLS et nécessite souvent l'installation d'un
programme client spécique, tels que PuTTY pour Windows et OpenSSH pour Linux.
Outil PuTTY :
PuTTY est un terminal client pour les protocoles SSH, Telnet et rlogin, ainsi que les
liaisons Serial RS-232. C'est un programme open source, développé et soutenu par S.
Tatham et un groupe de volontaires.
Lien : https://www.putty.org/
Etablissement d'une connexion SSH

An d'établir une connxion SSH, le serveur et le client mettent en place un canal sécurisé, ensuite,
le client s'identient auprès du serveur. Le déroulement de la mise em place d'un canal sécurisé est
décrit comme suit :
1. Comme dans SSL/TLS, le client et le serveur SSH eectuent une phase de négociation, an de
s'accorder sur les méthodes de chirement à utiliser ;
2. Le serveur envoie sa clé publique d'hôte (host key) au client ;
3. Le client génère une clé de session de 256 bits chirée grâce à la clé publique du serveur, et
l'envoie au serveur la clé de session chirée ;
4. Le serveur déchire la clé de session grâce à sa clé privée, et envoie un message de conrmation
chiré à l'aide de cette clé de session.
Une fois la connexion sécurisée mise en place entre le client et le serveur, le client doit s'identier
sur le serveur an d'obtenir un droit d'accès, selon deux méthodes diérentes :
Authentication par mots de passe : Après l'envoi du nom d'utilisateur et du mot de passe
par le client, le serveur vérie si l'utilisateur concerné a accès à la machine et si le mot de passe
fourni est valide ;
Authentication par clés publiques : Le serveur crée au préalable une paire de clé pu-
blique/privée pour chaque utilisateur. Si l'authentication par clé est choisie par le client, le
serveur vérie si la clé publique de l'utilisateur correspond bien à sa clé privée stockée au ni-
veau du serveur. Ceci permet au serveur de donner au client le droit d'accès correspondant à
l'utilisateur authentié.
6.5 Protocoles FTPS versus SFTP

Depuis longtemps, FTP (File Transfer Protocol) est le protocole le plus utilisé pour transférer des
chiers sur un réseau TCP/IP (RFC 959). Non seulement, FTP prend en charge les transferts de
chiers et le parcour des répertoires distants, mais aussi il permet d'eectuer quelques tâches similaires
à celles d'un système de chiers local. Cependant, une multitude de menaces existent et les connexions
FTP peuvent être compromises par le biais de diérentes cyber-attaques.
An de protéger les transferts de chiers de ces menaces, des protocoles sécurisés ont été développés.
Actuellement, deux de ces protocoles sécurisés sont largement utilisés : FTPS et SFTP. La diérence
entre les deux protocoles est le fait que FTPS est basé sur le tunnel SSL/TLS, alors que SFTP tire sa
sécurité de SSH [63].
FTPS (FTP over SSL) permet de sécuriser les connexion FTP en utilisant des certicat SSL, tout
en authentiant lutilisateur, à l'aide d'un username et d'un password (RFC 4217). Les connexions
de contrôle (port par défaut 990) et de données (port par défaut 989) sont ainsi chirées à l'aide
du protocole SSL/TLS. Concrètement, lors de la connexion au serveur FTPS, le client FTPS vérie
d'abord si le certicat du serveur est approuvé. Si ce dernier est valide, le client initiera une connexion
SSL sécurisée avec le serveur (processus de Handshake). Une fois la connexion est établie, le client
transmettra les données au serveur de manière sécurisée.
Par ailleurs, SFTP (SSH FTP) est un protocole qui permet de transférer et gérer des chiers au-
dessus d'une connexion sécurisée SSH à travers son port 22, en prenant en charge les fonctionnalités
d'authentication de SSH. Il a été conçu par le groupe de travail IETF SECSH, et docummenté dans
un RFC Draft. Ce protocole a été développé pour être indépendant de la plateforme d'utilisation pour
éviter les problèmes de compatibilité. Il fournit toutes les fonctionnalités oertes par FTP over SSL,
mais de manière encore plus sécurisée et plus able, avec une conguration plus facile. De plus, en
passant par un tunnel SSH, SFTP bénicie de tous les avantages qu'ore celui-ci.
6.6 Conclusion
Actuellement, le grand nombre d'entreprise, de banques, et de sites de commerce électronique
utilisent SSL/TLS pour protéger les transactions de leurs clients. Le succès de SSL/TLS a été soutenu
par les protocoles développés pour sécuriser les services applicatifs existants sur Internet tels que
HTTPS, FTPS et SMTP-TLS, POPS et IMAPS.
Chapitre 7
Messagerie sécurisée
7.1 Introduction
Ayant existée avant Internet, la messagerie électronique est l'un des services réseaux les plus utilisés
aujourd'hui. Il est responsable de la transmission des emails à travers Internet. En eet, depuis des
décennies, les emails sont devenus le moyen de communication principal pour de nombreuses entreprises
et personnes.
Un email, peut contenir du texte et des chiers, il est régi par diverses normes permettant d'éviter
les éventuels erreurs de compréhension ou de communication. Néanmoins, leur utilisation dans le cadre
de l'échange d'informations sensibles ou condentielles est exposée aux diérentes menaces, tels que
les spams et les virus.
7.2 Messagerie électronique

7.2.1 Historique
En 1965, l'email a été utilisé pour la première fois en tant que moyen de communication entre
les utilisateurs d'une même machine partagée. En eet, l'ingénieur Ray Tomlinson, diplômé du MIT
et travaillant chez BBN (une société employée par le Ministère américain de la Défense pour le dé-
veloppement du réseau ARPAnet), a développé deux petits programmes, SNDMSG et READMAIL.
Ces programmes ont permis à des chercheurs qui travaillaient sur une même machine de s'envoyer
des messages en les partageant dans des répertoires désignés. Rapidement, les premiers systèmes de
messagerie s'étaient étendu en réseau, permettant aux utilisateurs de transmettre des messages via
diérentes machines.
En 1971, Tomlinson proposa l'utilisation du signe "@" (at, en anglais) pour séparer le nom de
l'utilisateur de celui de la machine sur lequel il est inscrit. La première adresse email de l'histoire
est tomlinson@bbn-tenexa, sachant que le suxe du domaine (.com, .net, . . . ) n'est apparu qu'en
1985. En modiant légèrement le programme SNDMSG, Tomlinson a créé deux boîtes aux lettres
électroniques sur deux machines situés dans la même salle. Le premier email envoyé contenait le texte
"QWERTYUIOP", soit la première rangée des touches du clavier anglais [3].
En 1975, John Vittal, un ingénieur à l'université de Californie du Sud, conçoit le premier logiciel
intégré de gestion des emails, appelé MSG, qui incluait les fonctions d'envoi, de réponse, de renvoi et de
classement des emails. Ce logiciel est considéré comme l'ancêtre des clients de messagerie modernes, tels
que Outlook ou Thunderbird. En 1977, le premier RFC (RFC 733) dédié à la spécication des emails,
a permis de normaliser les protocoles de courrier électronique. En 1978, Gray Thuerk, un employé de
Digital Equipment Corp., a envoyé un email aux 393 ingénieurs du réseau ARPAnet, pour promouvoir
les nouveaux produits de sa société. Cet email est considéré aujourd'hui comme le premier spam de
l'histoire. En 1992, le premier email formaté a été envoyé chez CompuServe, un fournisseur de services
en ligne. Le formatage du texte concernait la polices de caractère, les couleurs et les émoticônes.
Dans la même année de 1992, Microsoft a publié le client de messagerie Outlook pour MS-DOS,
78
CHAPITRE 7. MESSAGERIE SÉCURISÉE 79
et en 1994, Jim Clark et Marc Andreessen créent la société Netscape, dont le navigateur, incluait un
module de courrier électronique, appelé Netscape Mail. Ensuite, Jack Smith et Sabeer Bhatia lancent
un service de courrier électronique gratuit sur le Web baptisé Hotmail, en 1996. En quelques mois,
l'inscription de 100 000 utilisateurs a été dépassée. En 1997, Microsoft sort le client Outlook Express,
qui est devenu rapidement le leader dans sa catégorie, et en 1998, Microsoft rachète Hotmail avec 9
millions d'abonnés, qui avait atteint 30 millions d'abonnés une année plus tard.
En 2004. Google lance sa propre messagerie gratuite, Gmail, d'une capacité de 1 Go. En outres,
Gmail est le premier grand webmail à mettre en ÷uvre la technologie AJAX, qui permet une uidité
de l'interface
Sécurité desce qui la rapproche de celle 2018-2019
réseaux d'un client de messagerie
– Semestre 2 Desktop. Dans la
Université même année,
Constantine 2
la fondation Mozilla lance avec le navigateur Firefox, la première version du client Thunderbird, qui
visait à concurrencer la domination d'Outlook Express. En 2013, Microsoft renomme sa messagerie
d’Outlook et
Outlook.com Express. En 2013,
abandonne Microsoft renomme
dénitivement sa messagerie
la marque Outlook.com
Hotmail. et abandonne définitivement la
marque Hotmail.
7.2.21.2.Principe
Principe dede fonctionnement
fonctionnement
Le
Lefonctionnement ducourrier
fonctionnement du courrier électronique
électronique est basé
est basé sur l'utilisation
sur l'utilisation de boîtes
de boîtes auxstockés
aux lettres lettressur
stockés
des sur
des serveurs distants.
serveurs distants. Lors
Lors de l'envoi
de l'envoi d'un email,
d'un email, celui-ci celui-ci est acheminé
est acheminé deserveur
de serveur en serveur en serveur
jusqu'au serveurjusqu'au
de
messagerie
serveur du destinataire
de messagerie [4].
du destinataire [52].
MUA MTA MTA MDA

MUA
@ SMTP SMTP SMTP POP/IMAP

@
Exp Serveur SMTP Serveur SMTP Serveur Dest
de l’expéditeur du destinataire POP/IMAP
Figured’un
Concrètement, l’acheminement 7.1email suit les étapes
Principe suivante :
de l'acheminement des emails
1) Lorsque un expéditeur veut envoyer un email, il doit utiliser un client de messagerie appelé MUA
Concrètement, l'acheminement
(Mail User d'un
Agent). Celui-ci se email
charge suit les étapes
de transmettre l’emailsuivantes
en utilisant comme il est
le protocole schématisé
SMTP ; dans
la gure 7.1 :
2) L’email est envoyé au serveur de courrier sortant chargé du transport, nommé MTA (Mail Transport
1.
Agent). L’email est ainsi acheminé jusqu'au MTA du destinataire, en transitant parfois par plusieurs
Lorsque un expéditeur veut envoyer un email, il doit utiliser un client de messagerie appelé MUA
MTA. Puisque les MTA communiquent entre eux grâce au protocole SMTP, les MTA terminaux sont
(Mail User Agent). Celui-ci se charge de transmettre l'email en utilisant le protocole SMTP ;
appelés serveurs SMTP, tandis que les MTA intérmédiaires sont dits relais SMTP ;
2. L'email est envoyé
3) Le serveur MTA du audestinataire
serveur de courrier
délivre l’email au
ensuitesortant serveurdu
chargé de transport,
courrier entrant,
nommé
nomméMTA MDA(Mail
(Mail Delivery
Transport Agent). Agent). Ce dernier
L'email est chargé
est ainsi du stockage
acheminé des emails
jusqu'au MTAet de la
dugestion des boîtes aux
destinataire, en lettres.
transitant
Pour des raisons d’authentification, l'accès
parfois par plusieurs MTA. Puisque les MTA communiquent entre eux grâce au protocole ;SMTP,
au MDA est protégé par un identifiant et un mot de passe
Si le MDA
les MTA du destinataire
terminaux est occupé
sont appelés ou temporairement
serveurs SMTP, tandis hors service
que les et MTA
que l’email ne peut donc sont
intérmédiaires être dits
livré,
relais SMTP ;
le MTA de l’expéditeur réessaye automatiquement de livrer l’email à intervalles réguliers. Cela
se produit jusqu’à ce que la livraison soit réussie ou que l’email soit finalement retourné à l’expéditeur
3. Le serveur
comme MTA dudistribué.
étant non destinataire délivre ensuite l'email au serveur de courrier entrant, nommé
MDA
4) Le destinataire, par Agent).
(Mail Delivery Ce dernier
l’intermédiaire de son est
MUA,chargé du stockage
demande au MDA des emails etemails
les nouveaux de la via
gestion
l’utilisation
des boîtes aux de l’un des
lettres. protocoles
Pour POP oud'authentication,
des raisons IMAP. Ainsi, les serveurs de courrier
l'accès au MDA entrant
est sont appelés
protégé par un
serveurs POP ou serveurs
identiant et un mot de passe ; IMAP, selon le protocole utilisé.
Si le MDA du destinataire est occupé ou temporairement hors service et que l'email ne peut
Types de MUA :
donc être livré, le MTA de l'expéditeur réessaye automatiquement de livrer l'email à intervalles
Lorsque
réguliers. le se
Cela MUA est un jusqu'à
produit logiciel lourd installé
ce que sur le système
la livraison de l'utilisateur,
soit réussie ou queonl'email
parle desoit
client de
nalement
messagerie.
retourné Les clients
à l'expéditeur de messagerie
comme les plus
étant non connus sont :
distribué. Microsoft Outlook (Windows), Mozilla
Thunderbird (Windows, Linux et Mac OS), K-9 Mail (Android), et Mail (Apple).
4. Le destinataire, par l'intermédiaire de son MUA, demande au MDA les nouveaux emails via
Lorsqu'il s'agit d'un site Web permettant de s'interfacer au serveur de courrier entrant, on parle alors
l'utilisation de l'un
de webmail, des protocoles
par exemples, POP ou IMAP.
Horde, Roundcube, Ainsi,
Mailpile, les serveurs
RainLoop, de courrier
SquirrelMail, … entrant sont
appelés serveurs POP ou serveurs IMAP, selon le protocole utilisé.
Par analogie avec le courrier postal, les MTA font office de bureaux de poste, englobant le centre de tri et le
facteur qui assure le transport, tandis que les MDA font office de boîtes aux lettres, permettant de stocker les
emails, jusqu'à ce que les destinataires les récupèrent.
2. Acheminement des emails

2.1. Protocole SMTP
SMTP (Simple Mail Transfer Protocol) est le protocole de base utilisé pour transférer les emails de façon fiable
et efficace. Depuis sa sortie en 1982 (RFC 821) en tant que successeur du "Mail Box Protocol" dans ARPAnet,
SMTP est devenu le protocole standard pour l’envoi d’emails. Actuellement, la spécification des règles du
Commande Description
HELO h Se connecter avec son nom de domaine h et démarrer la session
MAIL FROM : Indiquer l'adresse email de l'expéditeur x
<x>
RCPT TO : <y> Indiquer l'adresse email du destinataire y
DATA Initier la transmission de l'email
RSET Interrompre la transmission initiée, mais maintenir la connexion
VRFY/EXPN Vérier si le serveur est disponible pour la transmission de l'email
Demander une réponse du serveur pour éviter une déconnexion due à un
NOOP timeout
QUIT Terminer la session SMTP
Table 7.1 Commandes du protocole SMTP
Types de MUA :
Lorsque le MUA est un logiciel lourd installé sur le système de l'utilisateur, on parle de
client de messagerie. Les clients de messagerie les plus connus sont : Microsoft Outlook
(Windows), Mozilla Thunderbird (Windows, Linux et Mac OS), K-9 Mail (Android), et
Mail (Apple).
Lorsqu'il s'agit d'un site Web permettant de s'interfacer au serveur de courrier entrant,
on parle alors de webmail, par exemples, Horde, Roundcube, Mailpile, RainLoop, Squir-
relMail, ...
Par analogie avec le courrier postal, les MTA font oce de bureaux de poste, englobant le centre de
tri et le facteur qui assure le transport, tandis que les MDA font oce de boîtes aux lettres, permettant
de stocker les emails, jusqu'à ce que les destinataires les récupèrent.
7.3 Acheminement des emails

7.3.1 Protocole SMTP
SMTP (Simple Mail Transfer Protocol) est le protocole de base utilisé pour transférer les emails
de façon able et ecace. Depuis sa sortie en 1982 (RFC 821) en tant que successeur du "Mail Box
Protocol" dans ARPAnet, SMTP est devenu le protocole standard pour l'envoi d'emails. Actuellement,
la spécication des règles du protocole sont disponibles dans le RFC 5321. Son principal rôle est
d'acheminer les emails de l'expéditeur jusqu'à la boite aux lettres du destinataire, en assurant le
routage des emails.
Concrètement, l'interaction entre le client et le serveur SMTP représente une session SMTP, où celle-
ci est composée d'une séquence de commandes textuelles provenant du client (MUA), et de réponses
sous forme de codes d'état provenant du serveur SMTP (MTA). En eet, les serveurs SMTP écoute
sur le port 25 en se basant sur TCP pour le transport. Selon les spécications de SMTP, chaque
implémentation du protocole doit prendre en charge au moins les huit commandes dénies dans la
table 7.1.
Pour des raisons d'ecacité et de robustesse, une extension de SMTP, appelé ESMTP (Extended
SMTP), a été lancée en 1995 (RFC 1869), orant d'autres commandes qui permettent d'économiser la
bande passante et de protéger les serveurs SMTP (Table 7.2).
Le serveur répond à chacune de ces commandes SMTP du client par un code de statut avec un
message en texte clair [2]. Les codes de statut les plus utilisés sont décrits dans le tableau 7.3.
Il est possible de tester un serveur SMTP en utilisant le protocole telnet sur le port 25 (ou le port
587), par exemple telnet smtp.gmail.com 25. Cette méthode permet d'échanger avec le serveur SMTP,
et de lui envoyer ainsi un email brut. Voici un exemple du déroulement d'une session SMTP entre
Comme HELO, mais EHLO permet en plus de lister toutes les
EHLO h commandes prises en charge
AUTH Authentier l'expéditeur
STARTTLS Utiliser le chirement SSL/TLS pour les échanges de la session SMTP
8BITMIME Utiliser le format MIME (joindre des chiers multimédias aux emails)
Restreindre la taille des emails selon les paramètres par défaut du
SIZE serveur
HELP Indiquer les commandes SMTP disponibles
ATRN, CHUNKING, DSN, ETRN, PIPELINING, SMTPUTF8, BINARYMIME,
CHECKPOINT, ...
Table 7.2 Commandes de l'extension ESMTP
Code Message
200 (non standard success response)
220 Le serveur est prêt pour la session SMTP.
221 Le serveur met n à la connexion
235 Authentication réussie
250 OK Commande exécutée
334 Le serveur attend la réception d'un texte codé au format Base64
354 Le serveur démarre la réception de l'email
421 Serveur non disponible, la connexion est terminée
450 Commande non exécutée, messagerie non disponible
500 Erreur de syntaxe, commande inconnue
501 Erreur de syntaxe dans les paramètres ou arguments
502 La commande n`existe pas
503 Séquence de commandes invalide
530 Accès refusé
535 Identiants d'authentication invalides
554 Échec de la transmission
Table 7.3 Codes de statut des commandes SMTP

client et serveur :
C:\> telnet <Serveur SMTP> 25

1 220 - < server > ESMTP Exim 4.92 #2 < date >
2 EHLO < Hote >
3 250 - < server > Hello < hostname > [ < ip - address >]
4 250 - SIZE 52428800
5 250 -8 BITMIME
6 250 - STARTTLS
7 250 - PIPELINING
8 250 - AUTH LOGIN
9 250 - HELP
10 AUTH LOGIN
11 334 VXNlcm5hbWU6 (" Username :" au format Base64 )
12 < Votre username en Base64 >
13 334 UGFzc3dvcmQ6 (" Password :" au format Base64 )
14 < Votre passoword en Base64 >
15 235 Authentication succeeded
16 MAIL FROM : < Adresse email de l ' expediteur >
17 250 OK
18 RCPT TO : < Adresse email du destinataire >
19 250 Accepted
20 DATA
21 354 Enter message , ending with "." on a line by itself
22
23 < Enveloppe SMTP >
24
25 250 OK id = < session - id >
26 QUIT
Dans un premier temps, le client doit initier une phase de Handshake SMTP, en exécutant la com-
mande HELO ou EHLO suivie du nom de domaine du serveur (ligne 2). À la diérence de la commande
HELO, EHLO permet de lister toutes les commandes prises en charge par le serveur (lignes 4-9). Suite
à la prise de contact avec le serveur, le client doit s'authentier en lançant la commande AUTH. Une
fois ce message reçu par le serveur, celui-ci demandera les identiants du client, en l'occurence, son
username et son passowrd (lignes 11-15). Ces identiants doivent être codés au format Base64. Si
l'authentication est réussie, le serveur répond avec le code 235.
Format Base64 :
Base64 est un codage de l'information consistant à utiliser 64 caractères ASCII (codés sur 7 bits)
pour coder tout type de données codé sur 8 bits. Utilisé massivement dans les échanges d'email,
le format Base64 permet ainsi de transmettre n'importe quel type de données sous forme de
simples caractères (texte accentué, image, vidéo, chier audio, etc.) [51]. Les spécications du
format Base64 sont publiées dans RFC 3548.
Il existe un outil en ligne qui permet d'encoder/décoder un texte vers/depuis le format Base64 :
http://www.base64encode.org.
Après l'authentication du client, celui-ci spécie les adresses email de l'expéditeur et du destina-
taire, à l'aide des commandes MAIL FROM et RCPT TO (lignes 16-19). Dans certains serveurs SMTP
tel que Gmail, l'indication de l'adresse de l'expéditeur n'a pas d'importance, car le serveur la dénira
automatiquement depuis l'identiant username authentié préalablement. Par contre, l'adresse email
du destinataire est vériée, et dans le cas où cette adresse n'existe pas, l'expéditeur recevra dans sa
boîte aux lettres, un email indiquant l'alerte.
Désormais, le client peut initier la transmission de l'email en exécutant la commande DATA, sachant
que l'email est introduit sous forme d'enveloppe SMTP (lignes 22-29). Dans le cas nominal, le serveur
conrme la réception de l'email et l'ajoute à sa le d'attente (ligne 25).
Après avoir clôturé la session SMTP avec la commande QUIT (ligne 31), le serveur SMTP envoie
l'email via un ou plusieurs MTA jusqu'au serveur MTA du destinataire. Chacune des opérations de
transfert est eectuée en utilisant toujours le protocole SMTP. Le serveur MTA du destinataire délivre
l'email à la boite aux lettres de celui-ci qui est stockée dans son serveur MDA. Enn, le MUA du
destinataire récupère l'email via le protocole POP ou le protocole IMAP auprès du serveur MDA.
Pour un utilisateur lambda, l'échange SMTP reste invisible, puisqu'il est exécutée en arrière-plan
par le client de messagerie ou par le webmail. Cependant, il est nécessaire, dans certains clients de
messagerie, de congurer manuellement le protocole SMTP lors de la conguration du compte.
De manière similaire à un courrier postal, une enveloppe SMTP comprend deux composants : les
entêtes (headers) et le corps (body) de l'email. Les entêtes de l'enveloppe contiennent des informations
relatives à l'acheminement des données entre les serveurs MTA. Voici les entêtes les plus utilisées :
Return-Path : Adresse de retour en cas d'erreur,
Received : Informations d'acheminement, entre les diérents serveurs MTA, ajoutées par ceux-
ci,
From : Adresse de l'expéditeur,
To : Adresse du destinataire,
Cc : Adresse Copie Carbonne,
Reply-To : Adresse de réponse dans le cas échéant,
Subject : Sujet de l'email,
Date : Date d'envoi de l'email,
Message-Id : Identiant unique de l'email.
An que SMTP puisse détecter la n d'une enveloppe SMTP, celle-ci doit toujours être clôturée
par une ligne contenant uniquement un point ("."). Voici un exemple d'enveloppe SMTP :
Enveloppe SMTP
1 From : ali@univ - constantine2 . dz
2 To : brahim@univ - constantine2 . dz
3 Subject : test d ' encodage MIME
4 MIME - Version : 1.0
5 Content - Type : text / plain ;
6 Content - Transfer - Encoding : quoted - printable
7 Cc : contact@univ - constantine2 . dz
8 Reply - To : contact@univ - constantine2 . dz
9 Date : Mon 23 Oct 2019 15:06:54 GMT
10 Subject : Un exemple d ' un message SMTP
11 Message - ID : <4.1.20000623164823.009 f5e80@IMAP . GOOGLE . COM >
12 Return - Path : ali@univ - constantine2 . dz
13 Received :
14 from mail - f41 . google . com ( mail - f41 . google . com . [209.85.220.41])
15 by mx . google . com with SMTPS id s16sor4ybk .67.2019.09.22.04.00.52
16 for < ali@univ - constantine2 . dz >; Mon , 23 Oct 2019 15:06:59 GMT
17 CRLF
18 This is a very simple body .
19 .
L'inconvénient majeur du protocole SMTP de base est qu'il est relativement limité pour les besoins
actuels. À l'origine, SMTP était conçu pour ne transférer que des chiers textes (codés en ASCII),
ainsi, il ne gère pas les caractères non ASCII et il ne peut pas de transmettre des chiers binaires. De
ce fait, le standard MIME a été proposé pour résoudre ces problèmes.
7.3.2 Standard MIME

MIME (Multipurpose Internet Mail Extension) est un standard Internet permettant d'étendre le
format de données des emails pour supporter : (1) des textes en codage de caractères autres que ASCII,
(2) des contenus non textuels, et (3) des contenus multiples. Avec l'apparition du multimédia, MIME a
été proposé par les laboratoires Bell Com. en 1991 an de permettre l'insertion des documents binaires
dans un email. Cinq RFC complémentaires sont fournis pour spécier MIME : RFC 2045, RFC 2046,
RFC 2047, RFC 2048, et RFC 2049.
Grâce à des entêtes SMTP spéciques, MIME propose de décrire le type de contenu de l'email et
le codage utilisé, en permettant (1) l'utilisation de caractères non ASCII et du texte enrichi (mise en
forme des messages, polices de caractères, couleurs, etc.) ; et (2) la possibilité d'avoir, dans un même
email, plusieurs pièces jointes de diérents types (exécutables, images, chiers compressés, etc).
Aujourd'hui, la plupart des serveurs SMTP acceptent MIME sur 8 bits, ce qui permet de transférer
des chiers binaires presque aussi facilement que du texte simple. Actuellement, les emails envoyés via
le protocole SMTP au format MIME, sont appelés emails SMTP/MIME.
Les cinq entêtes SMTP additionnels pour prendre en charge du contenu MIME sont :
MIME-Version : indique la version de MIME utilisée, sachant que la version 1.0 est la seule
utilisée actuellement,
Content-Type : décrit le type et le sous-type des données. Plusieurs combinaisons sont pos-
sibles, pour chacun des types suivants : text (text/plain, . . . ), image (image/png, . . . ), audio
(audio/basic, . . . ), video (video/mpeg, . . . ), et application (application/pdf, . . . ). La liste ex-
haustive des types MIME, normalisés par l'IANA peut être consultée dans [32] ;
Par ailleurs, le type multipart/mixed permet de dénir des messages composites, comportant
plusieurs pièces jointes. Pour ce faire, MIME permet de dénir un séparateur appelé boundary.
Il s'agit d'une chaîne arbitraire dénie en attribut de l'entête Content-type.
Content-Transfer-Encoding : dénit l'encodage utilisé dans le corps de l'email. Cinq formats
de codage peuvent être utilisés :
7bit (ASCII) : Format de texte codé sur 7 bits, pour les messages non accentués (Ex : "cet
été" est codé "cet iti") ;
quoted-printable : Format de texte accentué, codé sur 7 bits (Ex : "cet été" est codé "cet
=E9t=E9" ;
base64 (7bits) : Format de texte codé en Base64, recommandé pour l'envoi de chiers
binaires en pièce jointe (Ex : "cet été" est codé "Y2V0IOl06Qo=") ;
8bit : Format de texte codé sur 8 bits, en utilisant par exemple UTF8 (Ex : "cet été" est
codé "cet été") ;
binary : Format binaire dédié aux pièces jointes. Il est déconseillé pour SMTP.
Content-ID : représente un identicateur unique de partie de l'email ;
Content-Description (facultatif) : donne des informations complémentaires sur un objet
transmis dans l'email. Cet entête est nécessaire quand le contenu est un chier binaire (non
lisible) ;
Content-Disposition (facultatif) : dénit les paramètres de la pièce jointe, notamment le
nom associé au chier grâce à l'attribut lename.
Voici un exemple d'enveloppe SMTP/MIME contenant un corps codé en Quoted-printable :
Enveloppe SMTP/MIME
5 Content - Type : text / plain ;
6 Content - Transfer - Encoding : quoted - printable
7 CRLF
8 Ceci est un email qui contient des caract = E8res non ASCII , puis transform = C3 = A9
en ASCII par la m = C3 = A9thode " Quoted - Printable ".
9 .
Ci-dessous, un autre exemple d'enveloppe SMTP/MIME composite, englobant un texte codé en 8

bits suivi d'une pièce jointe de type PDF, délimités avec des séparateurs (lignes 7, 14 et 19) prénis
par l'attribut boundary dans le content-type (ligne 5).
Enveloppe SMTP/MIME
5 Content - Type : multipart / mixed ; boundary ="3 Pql8miugIZX0722 "
6 CRLF
7 - -3 Pql8miugIZX0722
8 Content - Type : text / plain
9 Content - Disposition : inline
10 Content - Transfer - Encoding : 8 bit
11 CRLF
12 Bonjour , vous trouverez un document pdf en piece jointe .
13 CRLF
15 Content - Type : application / pdf ;
16 Content - Disposition : attachement ; filename =" document . pdf "
17 Content - Transfer - Encoding : base64
18 JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4 +
CnN0cmVhbQp4nN1aS4 / cxhG +81 fw6BhQp9 + Po4wYRoAIiLRr5BxM1paC ...
20 .
7.4 Accès aux emails

Lors de l'arrivée d'un email sur le MTA du destinataire, celui-ci vérie s'il ne s'agit pas d'un spam,
puis il le transfère dans le MDA où sont stockés les emails de la boîte aux lettres du destinataire.
Ensuite, comme le protocole SMTP ne permet pas de récupèrer les emails sur le MUA du destinataire,
il existe principalement deux protocoles permettant de le faire :
Le protocole POP, le plus ancien, permet à l'utilisateur d'extraire ses emails depuis le serveur ;
Le protocole IMAP, permet une synchronisation de l'état des emails (lu, supprimé, déplacé)
entre plusieurs MUA. Avec le protocole IMAP une copie de tous les emails est conservée sur le
MDA an de pouvoir assurer la synchronisation.
Ayant un accès direct au serveur MDA, seul l'administrateur de celui-ci possède le privilège de
manipuler à distance les chiers stockés dans le serveur, y compris les boites aux lettres.
7.4.1 Protocole POP

POP (Post Oce Protocol) est le protocole de base qui permet à tout utilisateur, de relever ses
emails depuis un MDA. Conçu initialement en 1984 (RFC 918), POP propose des fonctionnalités
basiques, considérées comme susantes pour la plupart des utilisateurs, à savoir : compter les emails
disponibles, calculer la taille des emails, supprimer un email donné, et extraire un email de la boite
aux lettres.
Sachant que les deux premières versions de POP sont obsolètes, actuellement c'est la version 3, dite
POP3 (RFC1939), qui est utilisée. Tout comme SMTP, POP3 est un protocole de type client/serveur
(MUA/MDA) utilisant le protocole TCP via le port par défaut 110. Par ailleurs, POP3 est un protocole
unidirectionnel, ce qui signie que les emails sont extraits du serveur et envoyés au client. Donc, toute
modication apportée aux emails au niveau du client n'est pas répercutée sur le serveur. Concrètement,
POP3 utilise un jeu de 12 commandes spéciques lors d'une session entre le client et la serveur POP3.
Ces commandes sont décrites dans le table 7.4.
Voici un exemple de dialogue entre un client et un serveur POP3 :
USER x Introduire le username x pour l'authentication
PASS y Introduire le password y pour l'authentication
Connaître le nombre d'emails présents sur le serveur ainsi que la taille totale
STAT des emails
Lister les emails sur le serveur, avec pour chacun, l'identiant (x) dans la le
LIST d'emails
RETR x Récupérer un email par son identiant x
TOP x n Récupérer les n premières lignes d'un email identié par x
LAST Indiquer l'identiant du dernier email récupéré
DELE x Supprimer un email par son identiant x
NOOP timeout
RSET Réinitialiser la session
UIDL Acher un identiant unique qui ne varie pas entre chaque session
QUIT Terminer la session avec le serveur
Table 7.4 Commandes du protocole POP3
C:\> telnet <Serveur POP> 110

1 + OK Server ready .
2 USER < Username >
3 + OK
4 PASS < Passoword >
5 + OK Logged in .
6 STAT
7 + OK 1 60018
8 LIST
9 + OK 1 messages :
10 1 60018
11 .
12 RETR < ID de l ' email >
13 < Enveloppe de l ' email ... >
14 .
15 TOP < ID de l ' email > < Nombre de lignes >
17 .
18 DELE < ID de l ' email >
19 + OK message <ID > deleted
20 QUIT
21 + OK Logging out .
Dans un premier temps, le client doit s'authentier en indiquant son username et son password
(lignes 3 et 5), ainsi, le serveur répond par un message "+OK Logged in." ou "-ERR <raison>",
en fonction du résultat. À l'aide de la comande STAT, le client peut demander le nombre d'emails
présents dans la boite aux lettres de l'utilisatuer au niveau du serveur (ligne 7) et lister les identiants
des emails en utilisant la commande LIST (ligne 8). Pour acher l'enveloppe d'un email donné, il
sut d'envoyer la commande RETR en précisant son identiant (ligne 13), par contre, pour acher
les quelques premières lignes de l'email, il faut utiliser la commande TOP (ligne 15). La commande
DELE permet de supprimer un email depuis le serveur POP3. Enn, la commande QUIT permet de
fermer la session POP3.
7.4.2 Protocole IMAP

IMAP (Internet Message Access Protocol) est un protocole également utilisé pour relever ses emails
depuis un MDA. Cependant, il s'agit d'un protocole bidirectionnel permettant de gérer directement les
LOGIN x y Authentier l'utilisateur avec son username x et son password y
CAPABILITY Lister les commandes que le serveur supporte
SELECT r Sélectionner un répertoire r de la boite aux lettres que l'on souhaite consulter
FETCH x p Obtenir des informations sur un(des) email(s) x en fonction des paramètres p
STARTTLS Utiliser le chirement SSL/TLS pour les échanges de la session IMAP
CREATE r Créer un nouveau répertoire r dans le répertoire sélectionnée
STORE x . . . Modier les "ags" attachés à un email x
EXPUNGE Détruire physiquement tous les emails marqués par \Deleted
NOOP timeout
LOGOUT Mettre n à la session IMAP
Table 7.5 Commandes du protocole IMAP4
emails dans le serveur, ainsi, toutes les modications eectuées sur le client (MUA) sont répercutées
au niveau du MDA. En eet, IMAP assure une synchronisation constante de la boite aux lettres située
entre le MUA et le MDA, an de mieux gérer, trier et classer les emails. Historiquement, le protocole
IMAP a été conçu par M. Crispin en 1986, et plusieurs versions se sont succédé, jusqu'à la version 4
(4rev1 plus précisément) qui est utilisée aujourd'hui (RFC 1730).
Avec IMAP, il est possible de ne récupérer qu'une partie de l'enveloppe de l'email, par exemple
ses entêtes, ainsi, les emails peuvent être déplacés ou supprimés sans être entièrement récupérés par
le client. Des recherches dans le serveur peuvent être eectuées, pour savoir si un email est déjà lu
ou non. Toutefois, le protocole IMAP requiert plus de ressources côté serveur, par rapport à POP.
Lors des premières versions de IMAP, celui-ci nécessitait au client d'avoir une connexion permanente
avec le serveur, mais, depuis IMAP4, de nombreux MUA proposent un mode hors-ligne permettant de
récupérer les emails localement comme le fait POP.
Concrètement, le service IMAP4 est à l'écoute sur le port TCP 143. Comme pour SMTP et POP3,
le protocole IMAP4 utilise plus de 40 commandes pour communiquer avec le serveur. Le client peut
envoyer plusieurs commandes sans attendre simultanément la réponse du serveur. De ce fait, un tag
(c1, c2, . . . ), précédant chacune des commandes, doit être ajouté par le client an de lui permettre de
retrouver facilement la réponse à la commande exécutée. La table 7.5 décrit les commandes les plus
utilisées.
Pour avoir plus d'informations sur l'état des emails au niveau de la boite aux lettres, IMAP4 permet
d'attacher un ou plusieurs ags à chacun des emails :
\Seen : L'email a été lu,
\Answered : On a répondu à l'email,
\Flagged : L'email est mentionné comme étant urgent/spécial (par l'utilisateur),
\Deleted : L'email est considéré comme supprimé pour que plus tard un EXPUNGE puisse
l'enlever,
\Draft : L'email est marqué en tant que brouillon car il n'a pas été entièrement envoyé,
\Recent : L'email est arrivé récemment dans cette boîte aux lettres.
Voici un exemple d'échange entre un client et un serveur IMAP4 :
C:\> telnet <Serveur IMAP> 143

1 * OK [ CAPABILITY IMAP4rev1 ...] Server ready .
2 c1 LOGIN < Username > < Passoword >
3 c1 OK [ CAPABILITY IMAP4rev1 ...] Logged in
4 c2 SELECT < Repertoire > ( Ex : INBOX )
5 * 3 EXISTS
6 * 0 RECENT
7 * 0 UNSEEN
8 * FLAGS (\ Answered \ Flagged \ Deleted \ Seen \ Draft )
9 c2 OK [ READ - WRITE ] Select completed (0.001 + 0.000 secs ) .
10 c3 FETCH * ( Flags , UID )
11 * 1 FETCH ( FLAGS (\ Seen ) UID 2343)
12 * 2 FETCH ( FLAGS (\ Seen ) UID 2344)
13 * 3 FETCH ( FLAGS () UID 2345)
14 c3 OK Fetch completed (0.001 + 0.000 secs ) .
15 c4 FETCH < ID de l ' email > BODY []
17
18 c4 OK Fetch completed (0.006 + 0.000 + 0.005 secs ) .
19 c5 FETCH < ID de l ' email > BODY [ header . fields ( Subject ) ]
20 Subject : Test
21 )
22 c5 OK Fetch completed (0.003 + 0.000 + 0.002 secs ) .
23 c6 STORE < ID de l ' email > + Flags (\ Deleted )
24 * < ID de l ' email > FETCH ( FLAGS (\ Deleted \ Seen ) )
25 c6 OK Completed .
26 c7 EXPUNGE
27 c7 OK Expunge completed (0.004 + 0.000 secs ) .
28 c8 LOGOUT
29 c8 OK Logout completed .
Initialement, le client doit s'authentier en indiquant son username et son password (lignes 2). Le
serveur répond par un message "Logged in" précédé par les commandes possibles en étant authentié. À
l'aide de la comande SELECT, le client peut sélectionner le répertoire à consulter, dans notre cas, c'est
le courrier entrant "INBOX" qui est choisi (ligne 4). On utilise la commande "FETCH * (ags, UID)"
pour lister les identiants des emails du répertoire sélectionné ainsi que les ags associés (ligne 11).
Pour acher l'enveloppe entière d'un email donné, il sut d'envoyer la commande FETCH en précisant
son identiant ainsi que le paramètre BODY[] (ligne 16), par contre, pour acher uniquement le sujet
de l'email, il faut préciser comme paramètre BODY[header.elds(Subject)] (ligne 19). Par ailleurs,
la commande STORE permet de modier les "ags" attachés à un email donné. Par exemple, pour
supprimer un email, il faut marquer celui-ci comme supprimé (\Deleted) à l'aide de la commande
STORE (ligne 23), puis le détruire physiquement en utilisant la commande EXPUNGE (ligne 26).
Enn, la commande LOGOUT permet de mettre n à la session IMAP4.
7.4.3 Comparaison entre POP et IMAP

Actuellement, lorsque l'utilisateur se connecte à un compte de messagerie via un MUA, celui-ci lui
demande de choisir pour les emails "entrants", entre les protocoles POP ou IMAP. An de faire le bon
choix, voici ci-dessous, les avantages et les limites de chacun des protocoles [66] :
Avantages et limites de POP

Comme avantage, l'utilisation du protocole POP par un MUA, surtout si celui-ci est intégré dans
une suite bureautique, permet de bien gérer ses emails, et le temps de connexion au serveur est court.
Par ailleurs, dans le cas d'un changement de serveur de messagerie, la migration est facile puisque tous
les emails se trouvent sur la machine du MUA. Il sut de modier les données de connexion dans les
paramètres du compte pour continuer à recevoir les emails.
Cependant, une fois les emails reçus téléchargés, ceux-ci ne sont plus présents sur le serveur. Si
l'utilisateur utilise plusieurs machines clientes pour lire son courrier, la réception des emails s'eectuent
sur la base du "premier arrivé, premier servi", c'est-à-dire y aura une partie des emails sur chacune des
machines clientes. De plus, comme les emails ne sont sauvegardés que sur une seule machine cliente,
en cas de panne ou de vol de celle-ci, tous les emails, reçus et envoyés seront perdus.
Il est possible de remédier en partie aux limites auxquelles soure le protocole POP en modiant
la conguration du compte pour conserver les emails sur le serveur pendant une durée librement
paramétrable.
Avantages et limites de IMAP

Comme les emails restent sur le serveur de messagerie IMAP, ils peuvent être consultés depuis
plusieurs machines clientes en ayant accès à l'ensemble des emails. De plus, comme le client et le
serveur de messagerie sont synchronisés, les copies de tous les emails envoyés ou reçus se trouvent sur
le serveur et sont accessibles depuis n'importe quelle machine cliente. En eet, le serveur fait oce de
copie de sauvegarde permettant de récupérer, à tout moment, tous les emails dans n'importe quelle
machine cliente. Par ailleurs, l'utilisateur peut accèder à ses emails via le Webmail, sans avoir en sa
possession sa machine cliente.
Toutefois, pour fonctionner correctement, la machine cliente a besoin d'être connectée en perma-
nence à Internet, même s'il est possible de sauvegarder une copie désyncronisée des emails sur cette
machine cliente. En outres, avec une utilisation régulière et de longue durée, tous les emails conservés
sur le serveur IMAP nissent par saturer l'espace d'hébergement réservé, généralement limité. Par
ailleurs, en cas de changement de serveur de messagerie, le "déménagement" ne se fera pas aussi facile-
ment qu'avec un compte POP, il est souvent nécessaire de faire appel à un "déménageur" professionnel
pour réaliser cette opération.
Pour éviter de laisser grossir les répertoires d'une boite aux lettres, il faut adopter les mesures
suivantes :
Vider la corbeille et le dossier Indésirables ou Spams du MUA régulièrement ;
Créer des dossiers locaux et y transférer (déplacer) les anciens emails dans le but de les archiver.
De cette façon, ils seront retirés du serveur en étant conservés dans la machine cliente, ce qui
diminuera l'espace utilisé sur le serveur, cependant, l'accès partout à ces emails ne sera plus
possible ;
Congurer un eacement automatique des emails, quand ils ont dépassé un certain âge.
L'utilisateur choisit entre POP et IMAP en fonction de son utilisation personnelle, sachant que les
deux protocoles sont incompatibles et qu'un compte existant ne peut pas être "converti" d'un mode à
l'autre.
7.5 Vulnérabilités et menaces dans la messagerie électronique

7.5.1 Absence de services de sécurité
Tous les échanges en utilisant les trois protocoles de messagerie (SMTP, POP3, IMAP4), se font en
clair. En eet, ces protocoles n'assurent ni l'authentication des serveurs, ni l'intégrité des messages
échangés. Par ailleurs, les entêtes d'une enveloppe SMTP ne sont pas vériés, et les contrôles sur celle-ci
sont limités aux règles anti-relayage uniquement.
7.5.2 Relayage SMTP

Un inconvénient du protocole SMTP est qu'il n'exige pas d'authentication des utilisateurs dans
sa conguration par défaut. Les serveurs relais SMTP mal conguré constitue un relais de messagerie
ouvert. Cela signie que le serveur transmet les emails même quand il n'est en charge ni de l'expéditeur
ni du destinataire. C'est ce constat qui permet aux assaillants de diuser des spams de manière massive
sur Internet, en se servant d'adresses d'expéditeurs erronées ou volées.
Généralement, si un tel relais ouvert est découvert, il est mis dans la liste noire des principaux
fournisseurs de messagerie Web, en quelques heures. À cet eet, il est de la responsabilité de l'admi-
nistrateur du serveur relais SMTP mal conguré, de corriger la vulnérabilité et de demander ensuite
la suppression de la liste noire.
7.5.3 Transport de contenus exécutables

Le protocole MIME est conçu pour transporter des chiers binaires pouvant être des exécutables,
tels qu'un code machine, des scripts, des plug-ins, etc. Pour le confort de l'utilisateur, certains clients de
messagerie, ouvrent automatiquement les documents attachés aux emails reçus. En eet, l'action par
défaut de l'ouverture d'un chier exécutable, consiste à l'exécuter, ce qui constitue une vulnérabilité
pour le système d'exploitation de la machine cliente, dans le cas d'un malware ou d'un virus. Par
ailleurs, certains spams sont élaborés pour essayer de convaincre l'utilisateur à ouvrir les documents
attachés malgré les recommandations de certains anti-virus. Cette faille est considérée comme un
problème général à tous les protocoles réseaux, auquel les utilisateurs doivent se méer tous les jours.
7.5.4 Excès de privilèges

Dans certains serveurs MTA ou MDA embarquant des systèmes UNIX, un compte de messagerie
correspond à un compte utilisateur Unix, avec des privilèges d'accès au système. Par ailleurs, au niveau
de la machine cliente, le MUA qui gère la messagerie, peut avoir l'accès complet à la machine cliente.
Par conséquent, certaines commandes distantes peuvent générer des menaces et des vulnérabilités dans
le serveur ou dans le client.
7.5.5 Failles des logiciels

L'implémentation des serveurs MTA, et des clients MUA (client de messagerie ou webmail) peuvent
avoir des failles à cause d'une négligence dans la phase de validation du logiciel, par exemple, le ver
historique Morris (1988) exploitant une faille de l'implémentation du serveur sendmail. Par ailleurs, il
peut y avoir des failles dans les mesures anti-relais implémentées au niveau des MTA.
7.5.6 Dénis de service

Généralement, tout serveur dans le réseau se met hors-ligne lorsque sa charge est trop importante,
c'est le cas aussi des serveurs de messagerie (MTA et MDA). En eet, l'utilisation déraisonnable des
utilisateurs, en termes de nombre et de taille des emails, peut compromettre le fonctionnement du
serveur, si celui-ci n'a pas été conçu pour gérer ce cas. Par ailleurs, la mauvaise gestion des ressources
dans un serveur de messagerie, peut être exploité pour élaborer une attaque de type DoS, an de le
mettre hors service.
7.5.7 Atteinte à la vie privée

Lors d'un envoi SMTP, les informations contenues dans les entêtes d'une enveloppe SMTP, per-
mettent de tracer géographiquement l'expéditeur de l'email. En outres, les systèmes de répondeurs
automatiques proposés par cetains serveurs SMTP fournissent des informations condentielles sur le
client et sur l'utilisateur.
En utilisant les protocoles classiques dédiés à la transmission des emails, la communication et les
échanges entre les serveurs et les clients de messagerie se font en clair, donc les emails peuvent être
inspectée. De ce fait, il est nécessaire de mettre en place des services permettant de sécuriser les emails,
telles que la condentialité, l'authentication, l'intégrité et la non-répudiation.
Actuellement, pour sécuriser la messagerie électronique, il est possible d'agir à deux niveaux dié-
rents :
Sécurisation du transport, consistant à sécuriser la communication entre le client et le

serveur de messagerie (MUA-MTA et MUA-MDA), ainsi que le relayage SMTP entre les MTA,
en utilisant le protocole SSL/TLS ;
Sécurisation de client à client, permettant de chirer les emails de bout en bout, indé-
pendamment des serveurs intermédiaires MTA ou MDA, en se basant sur des standards et des
protocoles de haut niveau, tels que S/MIME et OpenPGP.
7.6 Sécurisation du transport

An de sécuriser le ux de transport des emails et le ux de relève des boîtes aux lettres, il est
nécessaire de chirer la communication entre le client et le serveur de messagerie (SMTP, POP3 ou
IMAP), en se basant sur SSL/TLS. Ceci permet d'éviter la transmission en clair des emails ainsi que
les identiants de l'utilisateur lors de l'authentication. Actuellement, deux variantes de chirement
sont possibles, le chirement implicite et le chirement explicite :
En mode SSL/TLS explicite, le client établit d'abord une connexion non chirée avec le
serveur. Avant d'envoyer l'authentication de l'utilisateur, le client demande au serveur d'ouvrir
une session chirée SSL/TLS en envoyant la commande StartTLS. Une fois la conguration de
la session SSL/TLS réussie, toutes les commandes envoyées au serveur au cours de la session,
sont automatiquement chirées y compris les informations d'authentication de l'utilisateur ;
En mode SSL/TLS implicite, une session SSL est établie entre le client et le serveur avant la
communication. En eet, l'utilisation de SSL/TLS est implicite et toute tentative de connexion
eectuée par un client sans utiliser SSL/TLS est refusée par le serveur.
7.6.1 Chirement SSL/TLS explicite

Le mode de chirement explicite permet essentiellement d'éviter d'avoir deux ports pour chaque
protocole, pour établir les connexions chirées et non chirées. Avec ce mode, le client commence
toujours par établir une connexion sans chirement, sur le port prévu pour les connexions non chirées.
Ce n'est qu'après l'exécution de la commande StartTLS par le client, que le protocole négocie le
chirement avec le serveur, sans la nécessité d' établir de nouvelles connexions [1].
La commande StartTLS, également connue sous le nom de TLS opportuniste, est une extension du
protocole TLS, utilisée principalement pour chirer les communications non sécurisés SMTP, IMAP
et POP3. L'extension StartTLS est dénie dans le RFC 3207 pour SMTP, et dans le RFC 2595, pour
IMAP et POP3. En eet, StartTLS permet l'établissement d'une session TLS entre le client et le
serveur (MUA-MTA et MUA-MDA) et entre deux serveurs (MTA-MTA), en plus de l'authentication
du serveur et du client via des certicats.
Remarque :
Dénie dans le RFC 2817, HTTP met en ÷uvre sa propre procédure sécurisée explicite,
qui ressemble beaucoup à StartTLS. Cependant, de nos jours, HTTPS (RFC 2818) est
devenu le protocole le plus courant, en orant un chirement implicite.
En plus des protocoles de messagerie, StartTLS peut également lancer le chirement
explicite avec les protocoles LDAP (RFC 4511), FTP (RFC 4217), XMPP (RFC 6120) et
NNTP (RFC 4642).
Chez les fournisseurs d'accès, StartTLS est devenu le procédé de chirement des emails favori,
pour la raison qu'il ne fait pas obstacle à la communication avec les clients qui ne supportent pas le
chirement SSL/TLS.
Fonctionnement du chirement explicite

La commande StartTLS est utilisée pour renforcer la sécurité des protocoles de messagerie, à la
base non sécurisés. De ce fait, les mêmes ports sont utilisés pour initier le chirement explicite [14], à
savoir, le port 587 pour SMTP, le port 143 pour IMAP, et le port 110 pour POP3.
Prenons comme exemple une session SMTP chirée explicitement sur le port 587. Voici un dérou-
lement possible d'échange entre le client et le serveur SMTP :
C:\> telnet <Serveur SMTP> 587

2 EHLO < Hote >
4 250 - SIZE 52428800
5 250 -8 BITMIME
6 250 - STARTTLS
7 250 - PIPELINING
8 250 - AUTH LOGIN
9 250 - HELP
10 STARTTLS
11 220 TLS go ahead
12
13 ...
14 < Etablissement du Handshake TLS >
15 ...
16 AUTH LOGIN
17 ...
18 ...
Concrètement, les étapes permettant à un client SMTP d'initier une connexion TLS explicite sont :
1. Au moment du handshake SMTP entre le client et le serveur, celui-ci ache toutes les com-
mandes qu'il prend en charge, incluant la commande STARTTLS (ligne 6) ;
2. Le client demande donc au serveur, via la commande STARTTLS, s'il accepte le chirement
explicite ;
3. Si le retour est positif du serveur (go ahead), le handshake TLS peut commencer entre le client
et le serveur ;
4. Après la mise en place d'une connexion chirée explicitement, le client peut désormais s'au-
thentier en toute sécurité avant de procéder à l'envoi des emails (ligne 16).
Comme Telnet est un protocole applicatif non sécurisé, donc, il n'a pas la capacité d'établir un échange
de Handshake TLS. Par contre, l'outil OpenSSL le permet en utilisant la commande s_client avec le
paramètre -starttls, comme suit :
C:\> openssl s_client -starttls smtp -connect <Serveur SMTP>:587

1 ...
3 ...
4 250 SMTPUTF8
5 EHLO < Hote >
7 250 - SIZE 52428800
8 250 -8 BITMIME
9 250 - AUTH LOGIN
10 250 - PIPELINING
11 250 - HELP
12 AUTH LOGIN
13 ...
14 ...
Limites du chirement explicite

Le chirement explicite présente des inconvénients du point de vue sécurité, car il permet de
transmettre sous une forme d'abord non chirée des données personnelles, comme l'adresse IP. De
plus, en utilisant StartTLS, les pare-feu doivent analyser le procédé au niveau de l'application pour
faire la diérence entre les données chirées et les données non chirées.
En outres, la plupart des clients de messagerie utilisent StartTLS, ce qui est généralement représenté
par l'option TLS si possible au niveau du MUA, de ce fait, l'utilisateur ne sait pas si la liaison avec
le serveur est chirée ou non. Ainsi, les attaques de l'homme du milieu restent possibles étant donné
que la commande StartTLS peut être cachée sans que l'utilisateur ne le remarque. En eet, lorsque un
assaillant réussie à éliminer par ltrage l'extension TLS, la commande StartTLS n'est pas exécutée, et
les données sont transmises sans être chirées, cette attaque est appelée STRIPTLS [61].
Par ailleurs, dans le cas où le serveur n'accepte pas les connexions non chirées, certains MUA, qui
ne supportent pas StartTLS, proposent aux utilisateurs d'essayer de s'authentier au serveur malgré
cela. De ce fait, le client envoie les identiants de l'utilisateur en texte clair, même si le serveur va
ensuite refuser la connexion non sécurisée.
7.6.2 Chirement SSL/TLS implicite

Pour renforcer la sécurité des protocoles de messagerie SMTP, IMAP, et POP3, il a été décidé
d'ajouter le chirement SSL/TLS en tant qu'extension à ces protocoles (StartTLS). Toutefois, pour
remédier aux limites auxquelles soure StartTLS, des versions sécurisées des protocoles de mesagerie
ont été proposées : SMTP-TLS, IMAPS et POP3S. An de distinguer entre le chirement explicite et
le chirement implicite, un numéro de port diérent est dédié pour chaque protocole.
Protocole SMTP-TLS
SMTP-TLS (SMTP over TLS) est un protocole qui étent SMTP permettant à un serveur et à un
client SMTP de négocier une session sécurisée SSL/TLS avant de communiquer en SMTP (RFC 3207).
Le protocole SMTP-TLS est basé sur le port 465, sachant qu'actuellement la majorité des serveurs
SMTP orent ce port permettant une connexion chirée implicitement.
Protocole POP3S
POP3S (POP3 over SSL/TLS) est une version sécurisée implicitement du protocole POP3, écoutant
sur le port 995 par défaut (RFC 8314). Le protocole POP3S permet de chirer la communication avec
le serveur MDA au moyen de TLS. En eet, lorsqu'une connexion TCP est établie pour le service
POP3S, une négociation TLS commence immédiatement. Une fois la session TLS établie, les messages
de protocole POP3 sont échangés en tant que données d'application TLS pour le reste de la connexion
TCP.
Protocole IMAPS
Tout comme SMTP-TLS et POP3S, IMAPS (IMAP over SSL/TLS) est un protocole qui établit
une connexion TLS avant de s'échanger des message IMAP, en utilisant le port 993 par défaut (RFC
8314). En eet, une fois la session TLS établie, les messages du protocole IMAP sont échangés en tant
que données d'application TLS.
De nos jours, plusieurs serveurs de messagerie désactivent progressivement les protocoles SMTP (25
et 587), IMAP (port 143) et POP3 (port 110), de sorte que les clients doivent utiliser une connexion
chirée implicitement. En désactivant les ports de ces protocoles, l'extension StartTLS n'est plus
utilisable.
Fonctionnement du chirement implicite

Voici le déroulement d'un exemple d'une session SMTP chirée de manière implicite (sur le port
465), entre le client et le serveur SMTP :
C:\> openssl s_client -connect <Serveur SMTP>:465

1 ...
3 ...
5 EHLO < Hote >
7 250 - SIZE 52428800
8 250 -8 BITMIME
9 250 - AUTH LOGIN
10 250 - PIPELINING
11 250 - HELP
12 AUTH LOGIN
13 ...
14 ...
7.6.3 Limites de la sécurisation du transport

Malgré les avantages de la sécurisation du transport, les problèmes de sécurité associés à cette
solution sont nombreux :
Les faux messages constituent une menace importante, car si un assaillant réussit à se connecter
et envoyer un email depuis le compte d'un utilisateur victime, il n'existe aucun moyen concret
de déterminer si le message est faux ou non, et ainsi prouver que cela ne vient pas de l'utilisateur
victime. En eet, de nombreux virus se propagent de cette manière ;
Les e-mails normaux peuvent également être modiés par toute personne disposant d'un accès
administrateur aux serveurs SMTP par lesquels les emails transitent. L'assaillant peut modier
ou supprimer complètement le message et le destinataire n'a aucun moyen de savoir si le message
a été falsié ou non ;
De la même manière, les messages peuvent être sauvegardés par l'assaillant au niveau du serveur
SMTP, puis ultérieurement modiés et envoyés à nouveau. Il est presque impossible de prouver la
légitimité du message, sachant que l'utilisateur victime peut essayer de prétendre qu'il s'agissait
d'un faux message et mais il est dicile de déterminer qui dit la vérité.
7.7 Sécurisation de client à client

L'infrastructure des emails est, de par sa conception, non sécurisée. Alors que la plupart des clients
se connectent aux serveurs de messagerie en utilisant une connexion sécurisée SSL/TLS, certains ser-
veurs permettent un accès non sécurisé. Par ailleurs, lorsque les emails transitent de l'expéditeur au
destinataire, les connexions entre serveurs (MTA et MDA) ne sont pas nécessairement sécurisées. Il est
donc possible à des tiers d'intercepter, de lire et de modier les emails pendant leur acheminement [44].
Dans la sécurisation de client à client, les données sont chirées et déchirées uniquement au niveau
des terminaux. En d'autres termes, un email envoyé avec ce type de sécurisation est chiré à la source
par l'expéditeur, illisible pour les serveurs (MTA et MDA), puis déchiré à l'autre extrémité par le
destinataire. De cette façon, tout email ne serait déchiré que par le destinataire sur son ordinateur et
resterait sous une forme chirée et illisible sur les serveurs.
La gestion des clés de chirement est un problème complexe ; il existe deux possibilités :
En faisant conance à un tiers, l'autorité de certication : on utilise alors des certicats
X.509, par exemple dans le cas de S/MIME, centralisés par les autorités de certication.
En ne faisant conance qu'à soit même et un réseau de conance complètement
décentralisé : On utilise alors des clés OpenPGP et on dispose de son réseau de conance.
Nous décrivons dans cette section les protocoles les plus utilisés dans la sécurisation de client à
client.
7.7.1 Standard S/MIME

S/MIME est un standard de chirement et de signature numérique des emails encapsulés au format
MIME. En eet, comme MIME est un format qui n'ore aucune notion de sécurité, les développeurs de
l'entreprise RSA Data Security ont proposé une version sécurisée, appelée S/MIME (Secure MIME ).
1
En 1999, S/MIME est devenu un standard validé par l'IETF , dont les spécications sont décrites
dans le RFC 2630, sachant que les RFC 2632 et RFC 2633 décrivent S/MIME 3 et le RFC 3850 décrit
S/MIME 3.1.
Modèle de certication de S/MIME

En plus d'assurer les mêmes tâches que MIME, S/MIME inspecte les entêtes d'une enveloppe MIME
pour déterminer comment le chirement et les signatures doivent être traités. En eet, pour signer et
chirer les emails, S/MIME s'appuie sur les certicats X.509, qui sont délivrés par des autorités de
certication garantissant l'identité de leurs propriétaires. En outres, un certicat X. 509 ne peut être
révoqué que par son émetteur c'est-à-dire la CA qu'il a signé (Consulter le cours 9 pour plus de détails).
Sachant que S/MIME est supporté par la plupart des clients de messagerie, de ce fait, tout ce que
doit faire l'utilisateur est d'indiquer son certicat S/MIME, sa clé privée ainsi que les certicats de ses
interlocuteurs. Il existe principalement, trois façons pour obtenir un certicat S/MIME :
Créer un certicat auto-signé : Il est possible de créer son propre certicat S/MIME, ce-
pendant, il faut d'abord générer un certicat racine. De plus, tous les interlocuteurs doivent
d'abord importer ce certicat racine avant que l'échange d'emails puisse commencer. Ces certi-
cats peuvent être générés en utilisant des outils cryptographiques, tel que OpenSSL,
Acheter un certicat auprès d'une PKI (autorité de certication) : La solution la plus
simple pour obtenir un certicat S/MIME est son téléchargement auprès d'un organisme de
certication ociel (PKI), avec des ores payantes et gratuites.
Obtenir un certicat auprès de son entreprise : Dans certaines entreprises, les employés
peuvent demander des certicats S/MIME délivrés par le département informatique. Ces certi-
cats leur permettraient de communiquer entre eux en toute sécurité et condentialité.
Obtenir un certicat auprès d'une PKI :

Plusieurs PKI et autorités de certication délivrent des certicats S/MIME, mais rare celles qui
proposent des certicats gratuits, voici quelques unes d'entre elles : Actalis, CAcert, Sectigo,
GlobalSign, InstantSSL, StartCom, Wosign.
En eet, Actalis propose des certicats S/MIME ables selon deux politiques : (1) Des certicats
S/MIME gratuits, ne contenant que l'adresse e-mail du propriétaire avec une validité d'un an ;
et (2) des certicats S/MIME d'entreprise payants, contenant plusieurs informations concernant
l'entreprise, avec une validité pouvant aller jusqu'à trois ans.
An d'obtenir gratuitement un certicat S/MIME délivré par Actalis, il faut consulter le lient
suivant : https://extrassl.actalis.it/portal/uapub/freemail
Dans le cas où les certicats utilisés sont signés par une CA locale issue par exemple de l'enreprise,
il est nécessaire d'indiquer aussi le certicat auto-signé de la CA locale.
Fonctions de S/MIME
S/MIME repose sur la cryptographie à clé publique, pour chirer le contenu d'un email tout en
l'encapsulant dans une enveloppe SMTP/MIME. La signature de l'email est obtenue à l'aide de la clé
1. S/MIME : Secure Multipurpose Mail Extension.

privée de l'expéditeur. Toute personne interceptant la communication ne peut lire que la signature de
l'email, et cela permet au destinataire de vérier l'identité de l'expéditeur tout en assurant l'intégrité
de l'email. Les étapes de création d'une entité MIME signée sont les suivantes :
1. Sélectionner un algorithme de hachage (SHA-1 ou MD5), et calculer l'empreinte (digest) du

message ;
2. Chirer le digest du message avec la clé privée asymétrique du signataire (DSS ou RSA) ;
3. Préparer un bloc appelé "SignerInfo" qui contient : (1) le certicat du signataire ainsi que les
certicats susants pour constituer une chaîne de certication de conance, (2) un identiant
de l'algorithme de hachage, (3) un identiant de l'algorithme utilisé pour chirer le digest du
message et (4) le digest du message chiré.
Par ailleurs, an de chirer un email en utilisant S/MIME, les diérentes parties de celui-ci sont
chacune chirée à l'aide d'une clé de session. Dans chaque entête de partie est insérée la clé de session,
chirée à l'aide de la clé publique du destinataire. Seul le destinataire peut déchirer la clé de session
à l'aide de sa clé privée, et ainsi ouvrir le contenu de l'email ce qui assure la condentialité de l'email
reçu [42]. Les étapes détaillées de création d'une entité MIME chirée sont les suivantes :
1. Générer une clé de session aléatoire pour un algorithme de chirement symétrique particulier
(AES, RC2/40 ou Triple DES) ;
2. Pour chaque destinataire, chirer la clé de session avec la clé publique du destinataire (RSA ou
DH) ;
3. Pour chaque destinataire, préparez un bloc appelé "RecipientInfo" qui contient : (1) un identi-
ant du certicat de clé publique du destinataire, (2) un identiant de l'algorithme utilisé pour
chirer la clé de session et (3) la clé de session chirée ;
4. Chirer le contenu du message avec la clé de session préalablement créée.
Cette méthode de chirement associe l'ecacité d'utilisation du chirement à clé publique à la

vitesse du chirement symétrique. En eet, le chirement symétrique est environ 1000 fois plus rapide
que le chirement à clé publique, cependant, le chirement à clé publique résoud le problème de
l'échange des clés. Utilisées conjointement, ces deux méthodes améliorent la performance et la gestion
des clés, sans pour autant compromettre la sécurité.
En utilisant S/MIME, il est possible d'appliquer l'une des stratégies de sécurisation suivantes :
Clear-signed data : L'email est organisé en deux partie : Le contenu de l'email est en texte
clair suivi de l'empreinte digitale signée et codée en Base64. Le destinataire ne supportant pas
S/MIME peut acher le contenu de l'email mais ne peut vérier ni son intégrité ni la signature
de l'expéditeur ;
Signed data : Le contenu de l'email est codé en Base64 suivi de l'empreinte digitale signée.
L'email ne peut être aché que par un destinataire avec la capacité S/MIME ;
Enveloped data : Le contenu de l'email ainsi que les clés associées sont chirés ;
Signed & enveloped data : Les capacités de chirement et de signature peuvent être imbri-
quées, c'est-à-dire, toutes les données chirées peuvent être signées, et toutes les données signées
peuvent être chirées aussi.
Formats d'email S/MIME

Comme il est décrit dans la table 7.6, S/MIME utilise six variantes de message encapsulées dans
une enveloppe MIME [68] [60].
Les autres types d'entête MIME restent inchangés et peuvent être utilisés. L'exemple suivant illustre
une enveloppe contenant un email signé avec S/MIME. En pratique, un message signé par S/MIME
contient une pièce jointe "smime.p7s" englobant la signature et le certicat.
Type Subtype "smime" Description

param.
Le message simple signé composé de 2
multipart signed /
parties : le message en clair et la signature
application pkcs7-mime signed-data Partie signée S/MIME
application pkcs7-mime enveloped-data Partie chirée S/MIME
degenerate Partie contenant uniquement les certicats
application pkcs7-mime
signed-data de clé publique
Partie contenant la signature numérique,
application pkcs7-signature /
faisant partie du message multipart/signed
Le message de demande d'enregistrement
application pkcs10-mime /
de certicat
Table 7.6 Types de message S/MIME
Message signé (Clear-signed data)

3 Subject : Message signe avec S / MIME
5 Content - Type : multipart / signed ; protocol =" application /x - pkcs7 - signature ";
micalg = sha -1; boundary ="3 Pql8miugIZX0722 "
6 CRLF
7 This is a cryptographically signed message in MIME format .
8 CRLF
10 Content - Type : text / plain
11 CRLF
12 Ceci est le contenu du message .
13 CRLF
15 Content - Type : application / pkcs7 - signature ; name =" smime . p7s "
17 Content - Disposition : attachment ; filename =" smime . p7s "
18 CRLF
19 ZHNsZmpzbWxmanNtbHFmam1sc3EgZiBqc2xtcWZqbWxzamYgbXNsIHFqdm1scm16aiByZW1samVydmxye
mpybHogcnIgenJsempybCBqdgZHNsZmpzbWxmanNtbHFmamZHNsZmpzbWxmanNtbHFmWxmanNt ...
Et voici un exemple d'enveloppe contenant un email signé et chiré avec S/MIME. En eet,
un message chiré par S/MIME est constitué d'une seule partie MIME contenant une pièce jointe
"smime.p7m".
Message signé et chiffré (Signed & encrypted data)

3 Subject : Message signe et chiffre avec S / MIME
5 Content - Type : application / pkcs7 - mime ; name =" smime . p7m "; smime - type = enveloped - data
7 Content - Disposition : attachment ; filename =" smime . p7m "
8 Content - Description : =? UTF -8? Q ? Message_chiffr = c3 = a9_S / MIME ?=
9 CRLF
10 MIAGCSqGSIb3DQEHA6CAMIACAQAxggLHMIICwwIBADCBqjCBpDELMAkGA1UEBhMCRFoxFDASBgNVBAgMC
0 NvbnN0YW50aW5lMRQwEgYDVQQHDAtDb25zdGFudGluZTEhMB8GA1UECgwYQ29uc3RhbnRpbmUgMiB
l2ZXJzaXR5MQ0wCwYDVQQLDAROVElDMREwDwYDVQQDDAhDaGFvdWNoZTEkMCIGCSqGSIb3DQEJARYV
uY2hhb3VjaGVAZ21haWwuY29tAgEBMA0GCSqGSIb3DQEBAQUABIICAAZ3 / Ae + dgp4mn + lqEKt34VlC
3 eDBkptohwNpyS /+ PB3PPeT997lMIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMF ...
7.7.2 Protocole PGP

Développé par Phil Zimmermann en 1991, PGP (Pretty Good Privacy ) est un protocole applicatif
fournissant les services de condentialité et d'authentication an de sécuriser la messagerie électro-
nique, le stockage de chiers, et même les partitions de disque [37].
Pour le chirement et la signature des données, un logiciel ayant le même nom que le protocole PGP
a été développé (PGP
c ). Le logiciel PGP
c suit le standard cryptographique ouvert OpenPGP (RFC
4880), le rendant compatible avec d'autres logiciels. Auparavant, PGP
c avait la réputation d'être le
logiciel gratuit de cryptographie asymétrique le plus sûr au monde, cependant, il est devenu payant
dès 1993, suivant une série d'aquisition : PGP Inc. puis Network Associates Inc. ensuite PGP Corp.,
et enn la dernière en 2010 par Symantec. Actuellement, Symantec n'ore plus de version gratuite du
logiciel, toutefois le téléchargement du code source est permis pour sa révision. À cet eet, un autre
logiciel libre, appelé GnuPG ou GPG (Gnu Privacy Guard), a été développé en se basant sur OpenPGP
et distribué selon les termes de la licence publique générale GNU.
Modèle de certication de PGP

Sachant que S/MIME est basé sur un modèle centralisé pour maintenir la conance des certicats
et des clés de chirement. En eet, l'autorité de certication (CA) inspire une conance totale pour
établir la validité des certicats S/MIME. Mais, il est dicile pour un utilisateur d'établir une ligne
de conance avec les personnes n'ayant pas été explicitement considérées comme ables par la CA de
l'utilisateur [37].
Par ailleurs, dans le cadre de PGP où le modèle de certication est décentralisé, tout utilisateur
peut agir en tant qu'autorité de certication. Il s'agit de l'originalité de PGP, qui base sa conance
sur une notion de proximité sociale plutôt que sur celle d'autorité centrale de certication. En eet, un
utilisateur (A) peut valider la clé publique PGP d'un autre utilisateur (B). Une telle clé de l'utilisateur
(B) est considérée comme valide par un autre utilisateur (C) uniquement si celui-ci (C) reconnaît
l'utilisateur (A) comme un correspondant able, sinon, la validité de la clé de (B) est controversée.
Généralement, une clé publique peut être signée par zéro ou plusieurs signatures, où à chaque
signature est associé un degré de conance. La valeur de légitimité de la clé publique est calculée sur
la base des champs de conance de signature présents pour cette clé. Par conséquent, plus le niveau
de conance est élevé plus fort sera le lien entre l'utilisateur et la clé correspondante.
En outre, les paires de clés publiques/privées doivent être organisées et stockées ecacement pour
chaque utilisateur. En eet, PGP utilise deux structures de données, dites anneaux de clés ou trousseaux
de clés : (1) Un trousseau pour stocker les paires clés publiques/privées de l'utilisateur, et (2) un
trousseau pour stocker les clés publiques d'autres utilisateurs.
Supposons, que le trousseau de clés publiques de l'utilisateur (A) contient la clé publique de (B), et
que l'utilisateur (A) l'a validée en la signant avec sa clé privée. Par ailleurs, si un utilisateur tiers (C)
sait que l'utilisateur (A) est très pointilleux en ce qui concerne la validation des clés publiques d'autres
utilisateurs, donc, l'utilisateur (C) peut considérer l'utilisateur (A) comme une autorité de certication,
c'est-à-dire, toutes les clés publiques signées par (A) dans le trousseau de (C), apparaissent comme
valide et able (incluant la clé publique de (B) dans cet exemple).
En outres, dans un trousseau de clés publiques PGP, seuls le détenteur d'une clé publique ainsi
qu'un autre utilisateur désigné comme autorité de révocation par le détenteur de la clé publique, ont
la possibilité de révoquer cette clé publique.
Serveurs de clé PGP :

Lorsqu'un utilisateur créé sa propre paire de clé PGP, il peut publier sa clé publique dans un
serveur de clés PGP, an que tout autre utilisateur puisse la télécharger et l'utiliser. De la même
manière, si une clé est révoquée, les autre utilisateurs peuvent être avertis en interrogeant le
serveur de clés.
Parmi les serveurs PGP ables, on peut citer : https://keys.openpgp.org
Fonctions de PGP
Similairement à S/MIME, le protocole PGP fait partie des protocoles de cryptographie hybride
basés à la fois sur le chirement symétrique et asymétrique, en reposant sur une sélection des meilleurs
algorithmes : RSA, DSA, DH, 3DES, SHA-1, etc.
En utilisant PGP, l'authentication de l'expéditeur est assurée par le biais de la signature de l'email.
En eet, un email signé est obtenu à l'aide de la clé privée de l'expéditeur. Les étapes de signature
d'un email sont les suivantes :
1. Une empreinte (digest) du contenu de l'email est générée en utilisant une fonction de hachage
(SHA-1) ;
2. Le digest est ensuite chiré en utilisant la clé privée de l'expéditeur (RSA), et le résultat
correspond à la signature qui est ajouté au début de l'email ;
3. La signature peut être isolée dans le cas ou un email doit être signé par plusieurs personnes, un
contrat légal par exemple.
Par ailleurs, la condentialité d'un email est assurée en chirant celui-ci avant de le transmettre,
voici les étapes à suivre :
1. Le contenu de l'email est d'abord compressé (ZIP). Cette compression permet de réduire le
temps de transmission, d'économiser l'espace disque et de renforcer la sécurité cryptographique
contre les cryptanalyses ;
2. Une clé de session symétrique aléatoire (128 bits) est générée pour chaque email (CAST-128,
IDEA, TDEA, ou Triple DES) ;
3. Le contenu compressé est chiré avec la clé de session préalablement générée ;
4. Enn, la clé de session est chirée au moyen de la clé publique du destinataire (RSA ou DSS)
et est ajoutée au message.
Format d'un message PGP signé et chiré

2.3. Format d’un message PGP signé et chiffré
Message signé et chiffré
ID clé destinataire
Clé de
session Clé de session Dest
Horodatage signature
ID clé expéditeur
Signature
2 octets tête empreinte
Empreinte Exp Compression
et chiffrement
Nom du fichier
Horodatage
Message
Données
Figure
Comme il est illustré dans la figure ci-dessus, un message PGP signé et chiffré se compose en trois parties :
7.2 Format d'un message PGP signé et chiré
La partie "Clé de session", comprend :
Comme•il Clé
est illustré dans
de session la gure
: permet 7.2, un message
de déchiffrer le reste duPGP signéAfin
message. et chiré se compose
de protéger cette cléen
de trois parties :
session,
La partie "Clé
celle-ci de session"
est chiffrée , comprend
avec la clé publique du: destinataire ;
• ID de clé publique du destinataire : correspond à l'identifiant de la clé publique du destinataire
qui a été utilisé par l'expéditeur pour chiffrer la clé de session, car le destinataire peut avoir plusieurs
paires de clés ;
La partie "Signature", inclue :
Clé de session : permet de déchirer le reste du message. An de protéger cette clé de
session, celle-ci est chirée avec la clé publique du destinataire ;
ID de clé publique du destinataire : correspond à l'identiant de la clé publique du
destinataire qui a été utilisé par l'expéditeur pour chirer la clé de session, car le destinataire
peut avoir plusieurs paires de clés ;
La partie "Signature", inclue :
Horodatage de signature : est le moment auquel la signature a été produite ;
ID de clé publique de l'expéditeur : Identie la clé publique qui doit être utilisée pour
déchiré l'empreinte et vérier ainsi la signature, car comme le destinataire, l'expéditeur
peut avoir aussi plusieurs paires de clés ;
Empreinte : est une empreinte de 160 bits obtenue en appliquant la fonction de hachage
SHA-1. Cette empreinte est calculée sur l'horodatage de signature concaténé avec les données
de la partie "Message". L'inclusion de l'horodatage de signature dans l'empreinte protège
contre les attaques de relecture. Cette empreinte est ensuite chirée avec la clé privée de
l'expéditeur correspondant à l'identiant de clé indiqué précédement.
2 octets tête de l'empreinte : contient les 2 premiers octets de l'empreinte générée avant
son chirement avec la clé privée de l'expéditeur. Cela permet au destinataire d'optimiser
la vérication de la signature de l'expéditeur, en comparant ces 2 premiers octets (2 octets
sont généralement susants pour éviter les collisions de hachage) de l'empreinte avec les 2
premiers octets du texte obtenu lors du déchirement de la signature.
La partie "Message", comprend :
Nom du chier : est le nom du chier dans le cas où PGP est utilisé pour chirer un
chier ;
Horodatage : moment auquel le message a été créé ;
Données : correspondent au contenu du message à transmettre.
Les parties "Signature" et "Message" peuvent être compressés à l'aide de la fonction ZIP et ensuite
elles sont chirées à l'aide de la clé de session.
L'exemple suivant illustre un email signé par PGP, englobant le contenu de l'email en clair suivi
de la signature de celui-ci (lignes 10-14). La fonction de hachage est indiquée dans la ligne 6 :
Message signé avec PGP

3 Subject : Message signe avec PGP
4 CRLF
5 ----- BEGIN PGP SIGNED MESSAGE - - - - -
6 Hash : SHA256
7 CRLF
8 The content of the message .
9 CRLF
10 ----- BEGIN PGP SIGNATURE - - - - -
11 CRLF
12 iHUEARYIAB0WIQTJ + Gik + UlHIAk3CU / l2IrWbaBLGgUCXevFrwAKCRDl2IrWbaBLGsATAQCAFUX8D4y47F
4 cYqmGiws +4 LE8a1q + M614zS11FVAgaQEAw7oD + PubADaG6E / WWM8xDkLu /2 OlUHQjjOqn2eKiggo =
13 =3 qhe
14 ----- END PGP SIGNATURE - - - - -
Et voici un exemple d'un email signé et chiré avec PGP. Le contenu de l'email chiré (lignes 11-12)
est précédé par la version du logiciel GnuPG (ligne 8) :
Message signé et chiffré avec PGP

3 Subject : Message signe et chiffre avec PGP
4 Content - Type : text / plain ; charset = utf -8
6 CRLF
7 --- BEGIN PGP MESSAGE - - -
8 Version : GnuPG v1 .2.1 ( OpenBSD )
9 Charset : UTF -8
10 CRLF
11 hF4DTVra0KJMhxMSAQdAEq3qnEcZ2voo2f0F4Z /7 XkpfFg2XdS2n43YaoJ / ftREwKjvGHEkKHVOMMt
AnipR1gfAEHkRIjVca8Cbb8HcDGDCR3K068wTEDCLSBSdKlQCO0sAgASFrCGC91AedMny8ODFPYREE
Ci0YxT74IaCiVaOhpCeVrva6i7DXJjl25 ...
12 = sv5v
13 --- END PGP MESSAGE -- -
Enn, pour bénécier des capacités MIME tout en utilisant PGP, il est possible d'encapsuler un
message PGP au sein d'une enveloppe MIME, ce message est appelé PGP/MIME. Dans l'exemple
suivant, un email signé et chiré avec PGP/MIME est organisé en deux entités MIME : la description
du message PGP/MIME (lignes 8-12) suivie du contenu de l'email chiré (lignes 12-20) :
Message signé et chiffré avec PGP/MIME

3 Subject : ...
4 Content - Type : multipart / encrypted ; protocol =" application / pgp - encrypted ";
boundary =" CB86C93232A3F2D82F6E113F1E "
6 CRLF
7 This is an OpenPGP / MIME encrypted message ( RFC 4880 and 3156)
8 -- CB86C93232A3F2D82F6E113F1E
9 Content - Type : application / pgp - encrypted
10 Content - Description : PGP / MIME version identification
11 Version : 1
12 -- CB86C93232A3F2D82F6E113F1E
13 Content - Type : application / octet - stream ; name =" encrypted . asc "
14 Content - Description : OpenPGP encrypted message
15 Content - Disposition : inline ; filename =" encrypted . asc "
16 --- BEGIN PGP MESSAGE - - -
17 hF4DTVra0KJMhxMSAQdAEq3qnEcZ2voo2f0F4Z /7 XkpfFg2XdS2n43YaoJ / ftREw0sAgASFrCGC91Aed
Mny8ODFPYREECi0YxT74IaCiVaOhpCeVrva6i7DXJjl25 ...
18 = sv5v
19 --- END PGP MESSAGE - - -
20 -- CB86C93232A3F2D82F6E113F1E
7.8 Conclusion
Avant, la communication et les échanges entre les serveurs et les clients de messagerie se se faisait en
clair. De ce fait, il est possible d'agir à deux niveaux diérents pour sécuriser la messagerie électronique :
D'une part, la sécurisation du transport consiste à sécuriser la communication entre le client et le serveur
de messagerie, ainsi que le relayage SMTP entre les MTA, en utilisant le protocole SSL/TLS. D'autre
part, la sécurisation de client à client permet de chirer les emails de bout en bout, indépendamment
des serveurs intermédiaires MTA ou MDA, en se basant sur le standard S/MIME ou le protocole
OpenPGP.
Bibliographie
[1] 1and1 IONOS. Starttls, 2019.
[2] 1and1 IONOS SARL. Qu'est-ce que smtp ? dénition et principes de bases, 2019.
[3] Michel Alberganti. Historique du courriel, 2001.
[4] Authentication.eu. Qu'est ce que l'authentication réseau ?, 2019.
[5] Frédéric Bayart. Le chire de vernam, parfaitement sûr, 2019.
[6] Mickael Choisnard. Réseaux et sécurité informatique, 2015. Université de Bourgogne.
[7] A. Chouara. Introduction à la sécurité des réseaux et des systèmes d'information, 2010.
[8] COMPANEO. Quel est le rôle d'une entreprise de sécurité informatique ?, 2019.
[9] Oracle Corp. Introduction à ipsec, 2010.
[10] Bernard Cousin. Sécurité des réseaux informatiques, 2018. Université de Rennes 1.
[11] Yousri Daldoul. Techniques avancées de sécurité et de cryptographie, 2016.
[12] Samir Diabi. Sécurité du réseau, 2019.
[13] T. Dierks. Rfc 5246 : The transport layer security (tls) protocol version 1.2, 2008.
[14] Registrera Doman. Ssl vs tls vs starttls, 2019.
[15] Andreea Dragut. Chapitre iv : Elgamal (cours de cryptographie), 2012.
[16] Danièle Dromard and Dominique Seret. Réseaux informatiques, 2019.
[17] R. Dumont. Chapitre 14 : Les architectures de paiement, 2012.
[18] Nassima El Barrani. Dmz, une zone démilitarisée, 2018.
[19] Taher Elgamal. A public key cryptosystem and a signature scheme based on discrete logarithms.
IEEE Transactions on Information Theory, 31(4) :469472, 1985.
[20] FrameIP.com. Les rewall, 2019.
[21] FrameIP.com. Protocole ipsec, 2019.
[22] FrameIP.com. Protocole ssl et tls, 2019.
[23] Darril Gibson. Understanding the three factors of authentication, 2011.
[24] Jean Goubault-Larrecq. Introduction à la cryptographie (seminaire regards croisés), 2019.
[25] A. Guermouche. Sécurité des réseaux - cours 2 : les attaques, 2019.
[26] T. Hanada. What are dierences between ikev1 and ikev2 ? (ikev1 vs. ikev2), 2011.
[27] Xavier Heurtebise. Algorithmes de cryptographie, 2011.
[28] Daniel Lerch Hostalot. Attaque par factorisation contre rsa, 2019.
[29] InfoCrise. Dénition de la cybersécurité, 2016.
[30] Frédéric Kayser. Https : de ssl à tls 1.3, 2017.
[31] Auguste Kerckhos. La cryptographie militaire. Journal des sciences militaires, IX :161191,
1883.
[32] Ned Kucherawy and Freed Murray. Media types, 2019.
102
BIBLIOGRAPHIE 103
[33] Ghislaine Labouret. La sécurité réseau avec ipsec, 1999.
[34] Tout le numérique pour les entreprises. Qu'est-ce qu'un pare-feu ?, 2019.
[35] LeMagIT. Ipsec, 2016.
[36] LinkByNet. Mais, comment une vulnérabilité devient-elle une menace ?, 2019.
[37] Sylvain Lorin. Pgp - pretty good privacy, 2019.
[38] Olivier Markowitch. Les protocoles de non-répudiation, 2001.
[39] Ahmed Mehaoua. Vpn : Ip security protocol, 2017.
[40] Didier Müller. Desiderata de la cryptographie militaire, 2019.
[41] Didier Müller. La machine enigma, 2019.
[42] Heinrich Moser. S/mime, 2002.
[43] Mozilla. Certicats et authentication, 2019.
[44] Support Mozilla. Signature numérique et chirement des messages, 2019.
[45] Sourav Mukhopadhyay. The secure sockets layer (ssl), 2010.
[46] Inc. Network Sorcery. Isakmp, internet security association and key management protocol, 2018.
[47] CISA Department of Homeland Security. Ssl 3.0 protocol vulnerability and poodle attack, 2014.
[48] OmniSecu.com. Ikev1 protocol, ikev1 message exchange, ikev1 main, aggressive and quick modes,
2019.
[49] Kaushal Kumar Panday. Ssl/tls alert protocol & the alert codes, 2012.
[50] Jean-François Pillou. Systèmes de détection d'intrusion (ids), 2003.
[51] Jean-François Pillou. Codage base64, 2019.
[52] Jean-François Pillou. Fonctionnement du courrier électronique (mta, mda, mua), 2019.
[53] Jean-François Pillou. Protection - introduction à la sécurité des réseaux, 2019.
[54] R. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key
cryptosystems. Communications ACM, 21(2) :120126, 1978.
[55] SécuritéInfo.com. Introduction et initiation à la sécurité informatique, 2019.
[56] SecuriteInfo. Ipsec : Internet protocol security, encapsulage et cryptage de vos communications,
2002.
[57] Shannon. Shannon's maxim. Encyclopedia of Cryptography and Security, pages 11941194, 2011.
[58] Silicon.fr. Cybersécurité : les 10 chires qui font peur, 2017.
[59] William Stallings. Cryptography and Network Security : Principles and Practices, 4th Edition.
Prentice Hall, USA, 2006.
[60] William Stallings. Cryptography and network security : Principles and practices, 4th edition,
2006.
[61] Viruthagiri Thirumavalavan. Smtp ports (25 vs 587 vs 465), 2019.
[62] Je Tyson, Chris Pollette, and Stephanie Crawford. Remote-access vpn, 2019.
[63] John Carl Villanueva. Ssl vs ssh - a not-so-technical comparison, 2016.
[64] Vlad. Fin annoncée de tls 1.0 et tls 1.1, 2018.
[65] Wallu. Bienvenue chez ipsec, 2019.
[66] Better Web. Mon compte email : choisir pop ou imap ?, 2013.
[67] Ch. Zeitoun. Alan turing et le décryptage des codes secrets nazis, 2012.
[68] Minhaz Fahim Zibran. Cryptographic security for emails :, 2011. University of Saskatchewan.

Support Cours SERE.1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Support Cours SERE.1

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministére de l'Enseignement Supérieur et de la Recherche Scientique

Faculté des Nouvelles Technologies de l'Information & de la

Sécurité des réseaux

Destiné aux étudiants de 1re Année Master

1 Introduction à la sécurité des réseaux 10

2 Menaces et mesures de protection 15

3 Analyse des risques et politique de sécurité 26

5 Sécurité au niveau réseau : Protocole IPsec 49

5.4 Protocoles de sécurité de IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Chirement de bout-en-bout : Protocole SSL/TLS 63

7.7.1 Standard S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

1.1 Interconnexion des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Vulnérabilité et menaces des systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Fonction de ltrage d'un pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Principe de la transmission sécurisée des messages en se basant sur le chirement . . . 38

5.1 Fonctionnement du mode "Transport" du protocole IPsec . . . . . . . . . . . . . . . . 52

6.1 Architecture du protocole SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.1 Principe de l'acheminement des emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.1 Conguration du ltrage d'un pare-feu réseau de type Stateless . . . . . . . . . . . . . 29

4.1 Principaux algorithmes de chirement symétrique . . . . . . . . . . . . . . . . . . . . . 39

5.1 Exemple d'une SA IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Versions du protocole SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.1 Commandes du protocole SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Informations sur le module

Volume horaire hebdomadaire

 Connaître les politiques de sécurité possibles

Introduction à la sécurité des réseaux

1.2 Sécurité informatique

1.2.1 La sécurité informatique en chires

1. Espion : appelé aussi assaillant, pirate, hacker, et attaquant

Voici quelques chires concernant la cybersécurité dans le monde [58] :

1.2.2 Pourquoi la sécurité des réseaux est importante ?

1.2.3 Rôle des entreprises de sécurité informatique

L'intervention des entreprises de sécurité se fait généralement en 3 phases [8] :

1.3 Applications de la sécurité

1.3.1 Sécurité des équipements

1.3.2 Sécurité des applications logicielles

1.3.3 Sécurité des données

1.3.4 Sécurité des réseaux de télécommunication

Menaces et mesures de protection

Actif Vulnérabilité Menace

2.3 Attaques d'un réseau

2.3.1 Buts des attaques

2.3.2 Classications des attaques réseaux

Interruption Interception Modification Fabrication

2.3.3 Etapes d'une attaque

1. Analyse d'empreinte (reconnaissance) : Un service d'une entreprise, comme par exemple

2. Enumération des informations : l'assaillant étend sa connaissance du prol de sécurité en

7. Exploitation du système compromis : Une fois qu'il a compromis le fonctionnement du

2.4 Types d'attaques d'un réseau

2.4.1 Attaques de reconnaissance

2.4.2 Attaques d'accès

2. La machine de l'assaillant reçoit la demande et récupère la page du site Web d'origine ;

les données qu'elle contient ;

4. L'assaillant envoie la page demandée falsiée à la victime.

2.4.3 Attaques par déni de service (DoS)

2.4.4 Attaques de programmes malveillants (malware)

1. Activation de la vulnérabilité : un ver s'installe en exploitant les vulnérabilités connues

2.5 Services de sécurité

Figure 2.4  Principaux services de sécurité

2.6 Mécanismes de défense

2.6.1 Audit de sécurité

2.6.4 Systèmes de détection d'intrusion

Ministére de l'Enseignement Supérieur et de la Recherche Scientique

6 Chirement de bout-en-bout : Protocole SSL/TLS 63

3.1 Fonction de ltrage d'un pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Principe de la transmission sécurisée des messages en se basant sur le chirement . . . 38

3.1 Conguration du ltrage d'un pare-feu réseau de type Stateless . . . . . . . . . . . . . 29

4.1 Principaux algorithmes de chirement symétrique . . . . . . . . . . . . . . . . . . . . . 39

Connaître les politiques de sécurité possibles

1.2.1 La sécurité informatique en chires

Voici quelques chires concernant la cybersécurité dans le monde [58] :

2.3.2 Classications des attaques réseaux

2. Enumération des informations : l'assaillant étend sa connaissance du prol de sécurité en

4. L'assaillant envoie la page demandée falsiée à la victime.

Figure 2.4 Principaux services de sécurité

2.6.7 Authentication réseau

2.6.8 Bourrage de trac

2.6.9 Chirement des données

Dénir le domaine du réseau à protéger ;

1. Filtre d'application : Appelé aussi ltre de proxy ou proxying applicatif

Table 3.1 Conguration du ltrage d'un pare-feu réseau de type Stateless

Fonctionnement du ltrage simple de paquet

Figure 3.3 Cas d'architectures DMZ

Classications des IDS

Figure 3.4 Architectures des N-IDS et H-IDS

Diérentes actions des IDS

Reconguration d'équipement tierces, tels qu'un pare-feu ou un routeur, en lui envoyant un

Figure 3.5 Classes de VPN

VPN SSL/TLS (Secure Sockets Layer/Transport Layer Security) : SSL/TLS est

4.2 Formalisation des mécanismes de chirement

Décryptage : {M }K 7→ M ou K , ce précédé consiste à retrouver le message en clair M ou la

Chirement vs. Cryptage

Table 4.1 Principaux algorithmes de chirement symétrique

4.4 Algorithmes de chirement symétrique

4.5 Algorithmes de chirement asymétrique

4.6 Problèmes liés au chirement asymétrique

4.6.4 Problème de l'authentication de l'expéditeur

4.7.1 Dénition d'un certicat

4.8 Certicats X.509

4.8.1 Structure d'un certicat

4.8.2 Cycle de vie d'un certicat

3.3. Signature numériqueFigure 4.5 Cycle de vie d'un certicat

qui utilisent leur propre logiciel d'émission de certicats.

3. La condentialité : assurée au moyen du chirement, permet aux n÷uds communicants de