PKI_SSL

MODULE :

SÉCURITÉ SYSTÈME ET RÉSEAU

ENSEIGNANTE : SANA HAOUAS

CLASSE : RSI3
 Rappel : Le chiffrement
2

 Il existe deux méthodes de chiffrement :

 symétrique

 asymétrique

Chiffrement symétrique
Le chiffrement à clé publique
3

Chiffrement asymétrique
 Problématique des clés publiques
4

 Lorsqu'une entité (entreprise, service public, etc.) veut

sécuriser ses communications (entrantes et sortantes)
auprès d'un large public, le chiffrement le plus simple est
l'asymétrique : l'entité n'a qu'à diffuser sa clé publique à
l'ensemble de son audience.
 Problème : Comment transmettre la clé publique de
manière sûre?
 un attaquant peut se positionner entre l'entité et son public en
diffusant de fausses clés publiques (par le biais d'un faux site web par
exemple)
 puis intercepter toutes les communications  conséquences :
 usurpation de l'identité du diffuseur de clés publique
 attaque de l'homme du milieu.

Les certificats résolvent le problème du canal sécurisé

pour diffuser ces clés.
 Le certificat électronique
5

 C’est un ensemble de données contenant :

 au moins une clé publique
 des informations d'identification du diffuseur, par
exemple : nom, localisation, adresse électronique
 au moins une signature (faite avec la clé privée d’une
autorité de certification)
 autorité de certification (CA) = une autorité permettant de
prêter confiance (ou non) à l'exactitude des informations du
certificat (exemple: Verisign, GeoTrust,etc.)
 La CA possède un certificat appelé « certificat racine » dans
lequel elle place sa clé publique (on trouve ce genre de certificat
dans nos navigateurs!)
 Un certificat a une durée de vie, il peut être révoqué
c.à.d invalidé.
 Comment créer une signature ? (1/2)
6

 Trois algorithmes DSS (Digital Signature Standard) sont utilisés pour

générer et vérifier les signatures numériques :

 Algorithme DSA (Digital Signature Algorithm)

 Algorithme RSA (Rivest-Shamir Adelman Algorithm)

 Algorithme ECDSA (Elliptic Curve Digital Signature

Algorithm)
Comment créer une signature ? (2/2)
7

Clé privée CA : clé privée de l’autorité de certification

RSA : algorithme de chiffrement asymétrique
MD5/SHA-x : fonctions de hashage
Condensat : empreinte
 Utilité des certificats
8

 Les certificats électroniques sont utilisés dans

différentes applications informatiques dans le cadre
de la sécurité des systèmes d'information pour
garantir :
 la non-répudiation et l'intégrité des données avec la
signature numérique
 la confidentialité des données grâce au chiffrement des
données
 l'authentification d'un individu ou d'une identité
numérique
 Types de certificats
9

 Les certificats électroniques respectent des standards

spécifiant leur contenu de façon rigoureuse.
 Les deux formats les plus utilisés aujourd'hui sont :
 X.509, défini dans la RFC 5280
 OpenPGP, défini dans la RFC 4880

 La norme X.509 spécifie le format du certificat,

ses attributs, l’algorithme de validation…
 Structure d’un Certificat X.509
10

 Version
 Numéro de série
 Algorithme de signature du certificat
 DN (Distinguished Name) du délivreur (autorité de
certification)
 Validité (dates limites)
 L'objet du certificat
 Informations sur la clé publique (l’algorithme qui l’a généré,
la clé elle-même)
 Identifiant unique du signataire
 Identifiant unique du détenteur du certificat
 Extensions (optionnel)
 Signature des informations ci-dessus par l'autorité de
certification
Extrait d’un certificat X.509
11
Fonctionnement type d’un certificat X.509
(sur un navigateur Web)
12

 Création du certificat
 Lorsque le propriétaire d’un site web veut diffuser une clé
publique, il effectue une demande de signature auprès
d'une autorité de certification.
 L'autorité de certification reçoit la clé publique et l'identité du
diffuseur.
 Après avoir vérifié la clé publique et l'identité du diffuseur par
des moyens conventionnels, elle les place dans un conteneur
qu'elle signe en utilisant sa clé privée.
 Le fichier résultant est le certificat. Il est alors renvoyé au
diffuseur qui le conserve pour ses communications (par
exemple sur son site internet) avec des utilisateurs.
 13

 Utilisation du certificat
 Un internaute demande une ressource numérique au site web.
 Ce dernier lui envoie son certificat ainsi que la ressource en
question.
 Si la signature du certificat du diffuseur correspond à une
autorité de certification en qui l'utilisateur a confiance, c'est-à-
dire si le certificat racine de l'autorité est inclus dans le
navigateur web de l'utilisateur, alors l'utilisateur vérifie
l'intégrité du certificat du diffuseur avec la clé publique du
certificat racine. Cette vérification lui assure que l'identité du
diffuseur est authentique.
 Si le certificat du diffuseur est authentifié, l'utilisateur peut
alors utiliser la clé publique du certificat du diffuseur pour sa
communication avec le site web.
 Les signatures numériques pour la
signature du code
14

 Les signatures numériques sont couramment utilisées dans les deux situations
suivantes :
 Certificats numériques
o Signature de code :
permet de vérifier l'intégrité
des fichiers exécutables
téléchargés à partir du site
web d'un fournisseur.

Les fichiers exécutables sont

encapsulés dans une
enveloppe signée
numériquement, ce qui
permet à l'utilisateur final de
vérifier la signature avant
d'installer le logiciel.
Autorités et système d’infrastructure à clé
publique
15

 Des tiers de confiance sur Internet valident l'authenticité des clés

publiques à l'aide de certificats numériques. Le tiers émet des informations
d'identification qui sont particulièrement difficiles à falsifier.
 L'infrastructure à clé publique (PKI) est un système constitué de tiers de
confiance. Elle regroupe des autorités de certification (CA).
 Rôle d’une PKI : émettre des certificats numériques qui authentifient
l'identité des entreprises et des utilisateurs.
 Dans une PKI, on distingue les CA racines et les CA subordonnées (RA).
 Une autorité d'enregistrement (RA) est une autorité de certification
subordonnée certifiée par une CA racine pour la délivrance de certificats à
des fins spécifiques.
 16

 De nombreux fournisseurs proposent leurs serveurs CA sous la

forme d'un service pour les utilisateurs finaux.
 Les entreprises peuvent également implémenter une
infrastructure PKI privée (pour un usage interne) à l'aide de
Microsoft Server ou d'Open SSL.
 Les CA délivrent des certificats par classes qui déterminent le
degré de confiance d'un certificat.
 Plus le numéro de classe est élevé, plus le certificat est fiable.
 Système de confiance PKI
17

 Différentes topologies de
confiance : PKI à racine
unique
 La topologie PKI à racine
unique est la plus simple.
 Topologie CA cocertifiée :
chaque CA établit des
relations de confiance avec les
autres CA au travers de
certificats CA transversaux.
 Topologie CA
hiérarchique : la CA racine a
le niveau le plus élevé. Celle-ci
peut délivrer des certificats
aux utilisateurs finaux et aux
CA subordonnées. PKI hiérarchique
 SSL / TLS
18

 SSL (Secure Sockets Layer)

 TLS (Transport Layer Security)
Deux variantes d’un même protocole
 Objectif : fournir un certain nombre de services pour
sécuriser un canal de communication :
 Authentification unilatérale ou mutuelle
 Confidentialité des données échangées de bout en bout
 Intégrité des données de bout en bout
 SSL/TLS est surtout utilisé sur la couche TCP afin de
proposer des versions sécurisées de protocoles existants
(exemple : HTTPS, FTPs, …)
 Protocoles de la couche session (couche 5 du modèle
OSI)
 19

 En 2001, SSL a fait l’objet d’une normalisation par

l’IETF  TLS
 TLSv1.0 = SSL 3.1
 Aujourd’hui, TLS v1.2 est la plus utilisée
 Dernière version : TLS v1.3
 Certains éditeurs de logiciels ont intégré la version TLS v1.3
dans leurs applications (le navigateur Mozilla Firefox par
exemple),
 une version peut être prise en charge mais encore désactivée.
La négociation TLS entre client/serveur
20

Exemple de négociation TLS avec la suite TLS_RSA_WITH_RC4_128_MD5

Détails d’une connexion TLS classique
21

 Objectif : établir un canal de communication chiffré et

intègre
 Deux parties communicantes doivent s’entendre sur les
algorithmes et les clés à utiliser.
 Le message ClientHello :
 Le client propose un { } de suites cryptographiques (appelées “Cipher
suites”) qu’il est capable de mettre en oeuvre.
 Une suite cryptographique décrit les mécanismes
cryptographiques qui seront utilisés pour :
 Établir les éléments secrets de session
 Authentifier les parties
 Chiffrer les données applicatives
 Protéger les données applicatives en intégrité
 22

 Dans ce message, parmi les paramètres qui doivent

être négociés on trouve:
 La version du standard utilisée (SSLv3, TLSv1, TLSv1.1,
TLSv1.2…)
 Le mécanisme de compression à appliquer sur les données
applicatives
 Un aléa appelé ClientRandom est fourni par le
client pour la dérivation des clés
 23

Réponse du serveur :
 Lorsque le serveur reçoit le ClientHello, deux cas
peuvent se produire :
 Aucune des propositions du client n’est jugée acceptable => fin
de la connexion avec un message de type Alert
 Le serveur choisit une suite cryptographique parmi celles
proposées et émet un message ServerHello qui fait état de
son choix + un nombre aléatoire nommé ServerRandom
 Le serveur envoie ensuite son certificat(message
Certificate) et un message ServerHelloDone
pour indiquer qu’il attend maintenant la réponse du
client.
 24

 Le client vérifie la validité du certificat avant de

continuer.
 Dans l’exemple, le serveur a choisi
TLS_RSA_WITH_RC4_128_MD5 :
 RSA: pour l’authentification du serveur et l’établissement des secrets
de session
 RC4_128 : algo de chiffrement avec une clé de 128 bits pour chiffrer
le canal de communication
 MD5 : pour l’intégrité du canal
 Le message ClientKeyExchange contient un aléa
appelé “pre master key” (secret de session tiré au
hasard par le client) chiffré avec la clé publique du
serveur(clé contenue dans le certificat envoyé, si
certificat valide!)
 25

Fin de négociation
 Les éléments partagés (pre master key, ClientRandom,
ServerRandom) connus des deux parties, sont dérivés
pour fournir la clé symétrique qui sera utilisée pour
protéger le trafic en confidentialité (avec RC4 dans notre
exemple)
 Les messages ChangeCipherSpec indiquent
l’activation des paramètres(algos et clés) négociés.
 Les messages Finished sont les premiers à être
protégés: ils contiennent un condensat de l’ensemble des
messages échangés pendant la négociation, ce qui
garantit déjà l’intégrité de la négociation.