Sécurité avancée

Ecole Supérieure de Technologie et de Management (ESTM)

Licence 2 GLAR

Année académique 2023-2024

Dr. B. DIOUF 1
 Objectifs du cours
❑ Ce cours a pour objectifs de permettre aux participants de pouvoir :

▪ Procéder à la vérification de l’intégrité des informations par hachage,

▪ Authentifier des entités communicantes par signature pour un échange web,

▪ Vérifier identité des émetteurs des clés échangés (clés publiques)

▪ Générer des certificats de type X509 pour les échanges entre clients et serveurs.

▪ Comprendre et décrire les applications de la cryptographie pour VPN

▪ Décrire les applications de la cryptographie dans le web à travers les protocoles SSL/TLS et SSH.

▪ Savoir mettre en place les outils de cryptographie dans les applications web.

▪ Pouvoir implémenter de telles solutions

Dr. B. DIOUF 2
 Plan
❑ Introduction
❑ Applications de la cryptographie
▪ Hachage de données
▪ Signature électronique
▪ Authentification utilisateurs
▪ Certificats numériques
❑ Protocoles de sécurité
▪ Applications de la cryptographie pour VPN
▪ Applications de la cryptographie dans le web à travers les protocoles SSL/TLS et SSH
▪ Protocoles de sécurisation des transactions et des messageries électroniques
▪ Applications des outils de cryptographie dans les applications web.
❑ Conclusion

Dr. B. DIOUF 3
 Introduction
❑ Cryptographie dans les applications web et mobiles
❑ A l'ère de la cybercriminalité, la protection des données et systèmes devient un enjeu de taille pour les
différents utilisateurs d’Internet (entreprises, administrations ou particuliers).
❑ Applications web et mobiles sont la cible privilégiée des pirates. Elles peuvent leur permettre d’accéder à des
infos sensibles de l’utilisateur, voire pénétrer dans le système informatique d’une entreprise.
❑ Sécuriser une application commence par l’estimation du risque qu’elle peut faire courir.
❑ Pour cela la cryptographie est l’outil le plus utilisé et dans de nombreuses applications :
▪ Cryptographie : moyen de sécurité très efficaces, à la disposition des développeurs web et mobiles pour réduire
l'impact et le coût d'une violation de données.
▪ Les crypto-systèmes permettant d’assurer la confidentialité et l'intégralité des données et d’authentifier des
utilisateurs dans les applications web et mobiles sont basés sur :
➢ hachage des données
➢ signature électronique
➢ certificats numérique
▪ Les protocoles de cryptographie, notamment basés sur SSL/TLS, sont utilisés pour sécuriser les connexions et les
applications web et mobiles.

Dr. B. DIOUF 4
 Contrôle de l’intégrité des données : fonction de hachage
❑ La cryptographie sans secret est basée sur des fonctions de hachage cryptographique.
❑ Fonction de hachage : fonction mathématique qui prend en entrée des données de différentes tailles, et qui
fournit en sortie des données de taille fixe appelée empreinte ou hash ou encore digest.
❑ 2 propriétés essentielles :
▪ elle est irréversible : impossible de retrouver le message lorsqu'on connaît le hash ;
▪ elle est résistante aux collisions : 2 messages différents ne produiront jamais (en théorie) le même hash.
❑ Si un message est transmis avec son hash, le destinataire peut vérifier son intégrité en recalculant son hash et
en le comparant avec le hash reçu.
❑ Il est beaucoup plus rapide de comparer des hashs (format fixe et petite taille) que des données (grande taille
et variable) ⟹ fonctions de hachage très utilisées en informatique.

message message Message reçu n’est pas modifié

1)

hachage hachage
2) Message reçu est modifié

Dr. B. DIOUF 5
 Contrôle de l’intégrité des données : fonction de hachage
❑ Exemples :
❑ Algorithmes de hachage les plus utilisés :
▪ MD5 (Message Digest v5) sur 128 bits (16 octets, 32 chiffres hexadécimaux). il est possible de trouver des collisions.
▪ SHA-1 (Secure Hash Algorithm) : Input message 264 octets (au max), output sur 160 bits (20 octets), aujourd'hui
considérée comme vulnérable, car il est possible de trouver des collisions.
▪ SHA-2 (2002) : fonction standard de hachage cryptographique, la plus utilisée actuellement. Plusieurs versions, dont
SHA-256 dont le hash est de 256 bits.
▪ SHA-3 (2015) : alternative à SHA-2, ne la remplace pas mais servira d'alternative à l'avenir.

Exemple de hash :

MD5 (Jesaispas) = EFB7929E6A5B7DCC6EBB79AA3C45AF13 sur 128 bits (32 chiffres)

MD5 (Jesais) = A79AA6AF6A7923C49EBDC55F13BCB7AF

Dr. B. DIOUF 6
 Authentification des utilisateurs : signature électronique
❑ Equivalent électronique de la signature physique des documents papiers.
❑ Signature utilise le chiffrement à clé publique (asymétrique). Ex : RSA, DSA et ElGamal sont souvent utilisés.
❑ Pour signer électroniquement un message, il suffit de le chiffrer avec la clé privée.
❑ Le déchiffrement avec la clé publique correspondante prouve que seul le détenteur de la clé privée a pu créer
la signature.
❑ Pas nécessaire de chiffrer tout un document pour le signer, il suffit de chiffrer son hash.
❑ Le destinataire pourra calculer à son tour le hash avec le même algorithme (le document aura aussi été
transmis) et comparé avec le hash reçu et déchiffré.
❑ La résistance aux collisions de la fonction de hachage permet de garantir que c'est bien ce document qui a été
signé.
❑ Signature garantit :
▪ l'authenticité de l'expéditeur ;
▪ l'intégrité du message reçu :

Dr. B. DIOUF 7
 Authentification des utilisateurs : signature électronique
❑ Rappels cryptage symétrique/asymétrique
❑ Cryptage symétrique (ou à clé privée)
➢ Même clé (clé symétrique) partagée entre les 2 parties communicantes, sert à crypter et à décrypter les messages.
➢ Avantages : chiffrement efficace (clés de 64 ou 128 bits suffisantes), rapide et peu gourmand en puissance de calcul.
➢ Difficulté : trouver un moyen sécurisé pour communiquer la clé aux 2 entités.

❑ Cryptage asymétrique (ou à clé publique)

➢ 2 clés différentes pour chaque utilisateur :
➢ Principal avantage : il résout en partie le problème du transfert de la clé
➢ Mais plus coûteux en termes de temps de calcul et nécessite des tailles de clé plus importantes (couramment 1 024
ou 2 048 bits).

Dr. B. DIOUF 8
 Authentification des utilisateurs : signature électronique
❑ Exemple d’utilisation de la signature : messagerie électronique
❑ Coté émetteur du message :
1. Avant d’envoyer un message, l’outil de messagerie calcule d’abord l’empreinte du message.
2. Pour réaliser la signature, il chiffre ensuite cette empreinte avec la clé privée de l’émetteur.
3. Avant l’envoi, cette signature est ajoutée au message, qui devient un message signé.
❑ Coté destinataire :
1. L’outil de messagerie du destinataire déchiffre l’empreinte chiffrée avec la clé pub de l’émetteur.
2. Puis il recalcule le hash sur le message reçu et compare le résultat avec l’empreinte déchiffrée.
3. Si les 2 sont égaux, cela veut dire que
➢ le message n’a pas été modifié durant le transfert et que message signé
➢ l’émetteur est authentifié
message message message

Clé privé de A Clé publique de A

A B
Dr. B. DIOUF 9
 Authentification des utilisateurs : signature électronique
❑ Signature RSA
❑ Paramètres :
▪ Le choix des paramètres est le même que dans le chiffrement RSA.
❑ Signature :
▪ L'expéditeur signe le message 𝑚 avec sa clé privée : 𝑠 = 𝑚𝑑 𝑚𝑜𝑑(𝑛)
❑ Vérification signature :
▪ Le destinataire vérifie la signature avec la clé publique de l’émetteur : 𝑠𝑑 = 𝑠 𝑒 𝑚𝑜𝑑(𝑛)

❑ Exercice d’application :
1. Calculer le module 𝑛 et l’entier 𝜑(𝑛) associés aux nombres premiers p = 3 et q = 7.
2. Calculer l’exposant privée d si l’exposant public e = 5 ?
3. Quelle est la signature du message m = 4 ?
4. Montrer que la vérification de la signature fonctionne.
❑ Signature DSA
▪ DSA n’est utilisé que pour la signature contrairement à RSA (pour cryptographie et signature).
▪ DSS (Digital Signature Standard) spécifie DSA, développé par la NSA et a été proposé par le NIST en 1994 pour devenir
la norme du gouvernement des USA pour authentifier des documents électroniques.
Dr. B. DIOUF 10
 Vérification identité émetteur de clé publique : certificats
❑ Intérêt des certificats
❑ Transmission de clés pub peut être sujette à l'interception sur le Rx par MiM qui peut
1. intercepte la clé publique,
2. remplace la clé publique par la sienne et la transmet à l'expéditeur,
3. déchiffre avec sa fausse clé privée correspondante les messages envoyés par l'expéditeur et
4. les retransmet au destinataire après les avoir éventuellement modifiés.
▪ Une fois cette mascarade commise, MiM pourra lire les courriers confidentiels envoyés et signer des messages en se
faisant passer pour l’émetteur.

2 1

3 4

Dr. B. DIOUF 11
 Vérification identité émetteur de clé publique : certificats
❑ Certificats numériques
❑ Pour garantir l'origine d'une clé publique, l'une des solutions est d'utiliser un certificat électronique
(numérique) fourni en même temps que la clé :
▪ C’est l’équivalent électronique d’une carte d’identité ou d’un passeport.
▪ Réalise l'association d'une clé publique à une entité (personne, machine, ...) afin d'en assurer la validité ;
▪ Permet aux sites web, personnes et appareils de prouver l’authenticité de leur identité.
⇒ nécessaire que le certificat provienne d'un tiers de confiance.
▪ C'est le mécanisme de signature qui est utilisé pour garantir l'identité de ce tiers.
❑ Les certificats peuvent être :
▪ certificats auto-signés : un périphérique génère son propre certificat et le signe en tant qu'étant valide. Ce type de
certificat devrait avoir une utilisation limité.
▪ Certificats signés par une autorité de certification : un tiers valide et authentifie 2 nœuds ou plus qui tentent de
communiquer. Chaque nœud a une clé publique et une clé privée. Puisqu'ils ont obtenu leurs certificats de la même
source, ils peuvent être assurés de leurs identités respectives.

Dr. B. DIOUF 12
 Vérification identité émetteur de clé publique : certificats
❑ Intérêt des certificats
▪ Bob ne transmet pas directement sa clé publique à Alice.
▪ Il la transmet d'abord à Trent (1), le tiers de confiance.
▪ Ce dernier dispose lui aussi d'une paire de clés asymétriques, il utilise sa clé privée pour signer le certificat contenant
la clé publique de Bob (2) et lui transmet celui-ci (3).
▪ Bob peut alors envoyer le certificat signé à Alice (5).
▪ Celle-ci, qui a également reçu la clé publique de Trent (4), peut vérifier la signature et être sûre que la clé publique
provient bien de Bob.
❑ Ce mécanisme de certification n'élimine pas complètement les risques :
▪ MiM peut toujours intercepter le certificat ou la clé publique de Trent mais même s'il intercepte ces 2 infos, il ne
pourra générer un faux certificat sans la clé privée de Trent.

Dr. B. DIOUF 13
 Vérification identité émetteur de clé publique : certificats
❑ Certificats et PKI sur internet
❑ La génération et la distribution sur Internet des certificats sont organisées autour des infrastructures à clé
publique PKI (Public Key Infrastructure).
❑ Une PKI est une infrastructure composée d’un ensemble de systèmes, de procédures et de politiques très
strictes, dont les fonctions sont les suivantes :
➢ enregistrer les entités désirant obtenir des certificats électroniques ;
➢ fabriquer des paires de clés privée et publique ;
➢ certifier des clés publiques afin de créer des certificats et de publier ces derniers sur des annuaires publics ;
➢ révoquer des certificats et gérer des listes de révocation.

Dr. B. DIOUF 14
 Vérification identité émetteur de clé publique : certificats
❑ Certificats et PKI sur internet
❑ Une PKI est constituée des éléments suivants :
1. une autorité d'enregistrement ou RA (Register Authority)
▪ authentifier chaque nouveau participant.
▪ générer une paire de clés publique/privée ;
2. une autorité de certification ou CA (Certification Authority)
▪ crée et signe les certificats avec
o l'identité et la clé publique du participant,
o une date d'expiration et
o sa propre signature.
▪ fournit 1 copie de sa propre clé publique au participant.
▪ Muni de son certificat et de la clé publique de la CA, le
nouveau participant peut communiquer avec tous les
autres participants certifiés par la même CA.
▪ RA peut être intégrée à la CA ;
3. annuaire de certificats.
▪ généralement un serveur LDAP
▪ Contient les certificats publiés et certificats révoqués.
Dr. B. DIOUF 15
 Vérification identité émetteur de clé publique : certificats
❑ Certificats et PKI sur internet
❑ La plupart des certificats utilisés sur Internet sont au format
X.509 (de l'UIT), utilisé par HTTPS, IPsec, PGP et SSH. Ce
fichier transmis par la CA sur l'ordinateur du client contient :
➢ version du certificat (ex: X.509 v3);
➢ numéro de série fourni par la CA ;
➢ algos de hachage et de signature utilisés ;
➢ nom et clé publique du destinataire du certificat ;
➢ l'identité de l'émetteur (CA) ;
➢ la signature de la CA réalisée par chiffrement avec la clé privée
du hash des informations précédentes ;
➢ dates de validité du certificat,
➢ …
❑ Tout utilisateur possédant la clé publique de cette CA peut
déchiffrer le hash et le comparer au calcul de son propre
hash du certificat.

Dr. B. DIOUF 16
 Vérification identité émetteur de clé publique : certificats
❑ Autorités de certification et les hiérarchies de confiance
❑ Un certificat SSL est un type de certificat numérique largement utilisé qui lie les informations de propriété
d'un serveur web (d’un site web) à une clé cryptographique.
➢ Pour qu'un navigateur puisse faire confiance à un certificat SSL il doit
▪ contenir le nom de domaine du site web pour lequel il est utilisé,
▪ avoir été émis par une CA de confiance et être valide.
➢ Les navigateurs et les appareils décident de faire confiance à une CA en acceptant son certificat racine dans leur
magasin de certificats racine (base de données contenant une liste de CA autorisées) qui a été préinstallée dans le
navigateur ou sur l'appareil.
➢ Les clés publiques des principales CA sont mémorisées (et éventuellement révoquées) dans les navigateurs (Google
Chrome, Firefox, Internet Explorer, Opera, Safari, …).
➢ Pour voir les infos sur un certificat SSL sur googleChrome, aller à
▪ paramètres, puis confidentialité et sécurité, puis sécurité, puis gérer les certificats,
puis autorités de certification intermédiaires ou racine de confiance

Dr. B. DIOUF 17
 Vérification identité émetteur de clé publique : certificats
❑ Utilisation des certificats numériques dans les applications Internet
❑ Applications Internet les plus courantes, qui utilisent les certificats numériques :
➢ SSL : protocole utilisé par les serveurs web pour sécuriser les connexions entre ces derniers et les navigateurs web.
SSL utilise des certificats numériques pour l'échange de clés.
➢ Authentification client : le serveur demande et authentifie le certificat numérique du client lors de l'établissement de
liaison et décide s'il fait confiance au CA ou pas.
➢ Courrier électronique sécurisé : de nombreux systèmes de courrier électronique, utilisant des normes telles que PEM
(Privacy Enhanced Mail) ou S/MIME (Secure/Multipurpose Internet Mail Extensions) pour la sécurisation du courrier,
utilisent des certificats numériques pour signatures.
➢ Réseaux privés virtuels VPN : configurés entre des pare-feu afin d'activer des connexions protégées (trafic crypté)
entre des réseaux sécurisés ou entre un client éloigné (ex : un salarié travaillant à son domicile) et un réseau sécurisé
via internet.
➢ SET (Secure Electronic Transaction) : norme permettant d'effectuer des paiements par carte bancaire sécurisés dans
des réseaux non sécurisés (tels que Internet). Des certificats numériques sont utilisés pour les détenteurs de carte de
crédit, commerçants et banques. Les transactions crées sont sécurisées et incontestables, et ne peuvent pas être
contrefaites.

Dr. B. DIOUF 18
 Protocoles de sécurité
❑ Les protocoles qui utilisent les principes de cryptage, d'authentification ou de certification permettent de
mettre en place des solutions de sécurité pour
▪ différentes architectures de réseau et
▪ en intervenant à différents niveaux du modèle OSI.
❑ Certains protocoles concernent
▪ les VPN avec du cryptage aux niveaux 2 ou 3,
▪ d'autres sont utilisés pour sécuriser les applications en cryptant toutes les données encapsulées au niveau 7,
▪ d'autres encore sont dédiés à l'authentification de l'utilisateur externe lors de l'accès à un réseau privé.

Dr. B. DIOUF 19
 Protocoles de sécurité: protocoles pour les tunnels VPN
❑ Au niveau 2, les deux protocoles les plus utilisés pour mettre en place un tunnel VPN sont:
▪ PPTP (Point to Point Tunneling Protocol) proposé au départ par Microsoft et
▪ L2TP (Layer 2 Tunneling Protocol) normalisé par l'IETF

❑ Au niveau 3, IPSec (IP Security) défini par l‘IETF permet de sécuriser les paquets IP et de créer un tunnel sur la
couche réseau.

❑ Aux niveaux supérieurs, SSL/TLS (Secure Socket Layer/Transport Layer Security) et SSH (Secure Shell)
permettent de chiffrer les messages encapsulés dans des segments TCP et donc de créer indirectement des
VPN de niveau 7.

Dr. B. DIOUF 20
 Protocoles de sécurité: protocoles pour les tunnels VPN
❑ IPSec
❑ Essentiellement utilisé dans les VPN, assure l'authentification et
l'encryptage des paquets IP sur Internet.
➢ IPSec peut être utilisé pour ne faire que de l'authentification : dans ce
cas, l'ajout d'un en-tête d'authentification AH permet de vérifier
l'authenticité et l'intégrité des paquets.
➢ Dans la plupart des applications IPSec, l'enveloppe ESP permet de
chiffrer et d’authentifier les paquets.
❑ 2 modes correspondant à 2 architectures sont possibles avec IPSec :
▪ le mode transport qui ne protège que les données des paquets transmis
▪ le mode tunnel dans lequel le paquet entier est protégé en
l'encapsulant dans un nouveau paquet IP.

❑ Pour éviter d’avoir à gérer manuellement les clés de cryptage et d'authentification, IPSec
intègre un protocole d'échange automatique de clé :
➢ ISAKMP (Internet Security Association and Key Management Protocol) et IKE (Internet Key
Exchange) utilisé dans la phase d'initialisation
➢ négocient les paramètres des clés pour AH ou ESP et échange les clés choisies via un certificat.
B. DIOUF 21
 Protocoles de sécurité: pour sécuriser les applications
❑ SSL/TLS
❑ Le protocole SSL (Secure Socket Layer) a été proposé au départ par Netscape (jusqu'à la version 2.0) pour
permettre des connexions sécurisées sur des serveurs web.
❑ La version 3.0 est standardisée par l'IETF.
❑ TLS (Transport Layer Security), proposé par l'IETF, est la version 3.1 de SSL.
❑ Le protocole TLS n'impose pas de méthodes de chiffrement spécifiques.
❑ SSL intervient au-dessus de la couche transport et peut être utilisé pour sécuriser pratiquement n'importe
quel protocole utilisant TCP/IP (SMTP, POP3, IMAP...) en créant un tunnel dans lequel toutes les données
échangées seront automatiquement chiffrées.

Dr. B. DIOUF 22
 Protocoles de sécurité: pour sécuriser les applications
❑ SSL/TLS
❑ Certains protocoles applicatifs ont été spécialement adaptés pour supporter SSL :
▪ HTTPS (HTTP+SSL) est inclus dans tous les navigateurs et permet par exemple de
consulter des comptes bancaires par le web de façon sécurisée ;

▪ FTPS est une extension de FTP utilisant SSL.

▪ …
❑ SSL/TLS utilise un cryptage asymétrique par clé publique/clé privée pour
▪ authentifier le serveur (et éventuellement le client) et
▪ échanger la clé maîtresse.
❑ Connue des 2 extrémités, la clé maitresse permet un cryptage symétrique efficace
des données applicatives pendant toute la durée de la session.
❑ Le serveur utilise un certificat X509 (signée par une CA) qui contient sa clé publique
❑ Pour sécuriser davantage, un certificat peut aussi être installé sur le client.
Dr. B. DIOUF 23
 Protocoles de sécurité: pour sécuriser les applications
❑ SSH
❑ L'environnement SSH (Secure Shell) s'adresse aux utilisateurs qui souhaitent accéder de manière sécurisée à
des systèmes Linux distants.
❑ Ses composants remplacent des programmes peu sécurisés comme
➢ telnet pour établir à partir d'un terminal une session sur un serveur ou
➢ 2 protocoles de transfert ont été prévus pour fonctionner avec une connexion SSH :
▪ SCP (Secure CoPy), utilisé généralement en mode commande, permet de télécharger des fichiers de manière
sécurisée dans un tunnel SSH ;
▪ SFTP, version SSH de FTP, peut également être utilisée pour les transferts de fichiers.

❑ La sécurité est garantie par

➢ une authentification (signature RSA) à l'établissement de chaque connexion et
➢ un chiffrement symétrique des données (y compris les mots de passe). L’échange de clé (clé de session 𝐾) étant de
type Diffie-Hellman.
❑ SSH intervient donc au niveau 7, la connexion TCP est établie sur le port 22.

Dr. B. DIOUF 24