Certificats, PKI Et SSL - Séance 7

4- Certificats, PKI et SSL

Crypto-systèmes
Filière : GI2
Prof. Nabil KANNOUF
UAE – ENSAH
7 mars 2022
Plan
1 Certificat électronique
2 Infrastructure à Clés Publiques (PKI)
3 Certificats SSL/TLS
4.1- Certificat électronique

Cryptographie asymétrique et gestion à Clés : Problématique
Problèmes
Distribution à Clés
B Obtenir la clé publique d’une autre entité
B Distribuer sa propre clé publique
Révocation
B Révoquer une clé publiée
B Déterminer si une clé publiée est valide ou non

Distribution à Clés publiques
Une autorité de certification (CA) résout ce problème :

B Alice envoie sa clé publique au CA
B Alice prouve qu’elle détient la clé privée correspondant à la clé publique envoyée
B Le CA vérifie l’identité d’Alice
B Le CA signe l’ensemble :
? clé publique et identité d’Alice avec sa clé privée,
? le document signé est appelé certificat
Quand Bob reçoit le certificat d’Alice, il est sûr que la clé qui y est certifiée est celle
d’Alice
Certificat électronique
C’est l’Autorité de Certification (AC), véritable Tiers de Confiance, qui garantit la

validité des éléments contenus dans le certificat.
Le certificat est la pièce d’identité électronique qui permet de :

B vérifier l’identité de l’émetteur
B contrôler l’intégrité du contenu
B rendre non répudiable un échange ou la signature d’un document
Le certificat électronique peut être utilisé pour :

B S’authentifier sur des sites ou applications
B Signer électroniquement un document
B Chiffrer électroniquement un document
L’autorité de Certification (CA)
La validité des éléments d’authentification contenus dans le certificat numérique est

assurée par une autorité de certification (AC).
B Cette autorité de certification est chargée de délivrer les certificats numériques,
B de leur assigner une date de validité et de garantir l’identité de son propriétaire.
Un utilisateur voulant communiquer confidentiellement doit d’abord vérifier la clé
publique de son correspondant.
B Pour y parvenir il communique avec un CA.
Les CA sont les points d’entrée de plusieurs infrastructures à clés publiques.
Il y a plusieurs CA commerciaux comme :
B CAcert (gratuit), Digicert, Digi-Sign, Digital Signature Trust Co., VeriSign, GlobalSign
(Europe), Baridesign (Maroc), etc.
Obtention d’un certificat numérique auprès d’une CA

Obtention d’un certificat numérique auprès d’une CA
1 Bob demande à la CA de lui fournir le certificat numérique d’Alice ;

2 CA envoie le certificat d’Alice qu’elle a signé avec sa clé privée ;
3 Bob reçoit le certificat d’Alice et vérifie la signature de CA ;
4 Comme ce certificat contient la clé publique d’Alice,Bob a la certitude
qu’il est en possession d’une version authentifiée de cette clé.
4.2- Infrastructure à Clés Publiques (PKI)

Infrastructure à clés publiques (PKI)
Ensemble de composants, fonctions et procédures dédié à la gestion

de clés et de certificats utilisés par des services de sécurité basés sur
la cryptographie à clé publique
D’après le standard X.509 :
Mais :
B Le CA doit vérifier les détails de chaque utilisateur
B Risques pour la sécurité du CA
Autorité d’enregistrement (RA)

B Intermédiaire entre détenteur de clé et CA
B Vérifie les requêtes des utilisateurs et les transmet au CA
B Le niveau de vérification dépend de la politique de certification (CPS) mise en œuvre
Composants d’une PKI
Principaux
B Autorité de certification CA
B Autorité d’enregistrement RA
B Annuaire de publication
B Administrateurs
Complémentaires
B Base de données
B Serveur d’horodatage.
B Serveur HTTP, SMTP, POP.
Modèle de confiance dans X.509
Infrastructure hiérarchique
Possibilité de certification entre 2 CAs appartenant à des arbres différents, c’est la
co-certification
co-certification
co-certification
co-certification
co-certification
Certificats X.509
× Principal format utilisé pour les certificats
× Norme :
? ITU-T X.509, ou ISO/IEC 9594-8
× Versions successives :
? 1988 : v1
? 1993 : v2 = v1 + 2 nouveaux champs
? 1996 : v3 = v2 + extensions
Structure d’un certificat X.509



IssuerUniqueIdentifie
B identifie de façon unique la clé utilisée par le CA pour signer le certificat
? cas où le CA a utilisé plusieurs clés depuis sa mise en œuvre
SubjectUniqueIdentifier
B Différencie entre plusieurs clés publiques,
B issues par le même CA,
B appartenant à un même détenteur


Extensions d’un Certificat X.509
× Le concept d’origine des certificats X.509 est de relier l’identité d’une entité à une
clé publique
× Nouvelles situations :
? besoin d’avoir d’autres informations que l’identité
× Solution :
? Introduction de blocs de données pouvant supporter n’importe quel type d’informations

pour satisfaire des besoins locaux
Le Maroc ou on est ? ?
Au Maroc, Barid e-Sign est la première

plateforme de production de certificats Certifier les dispositifs de création et de
électroniques qui a pour mission de produire vérification de signature électronique et
des certificats d’authentification forte, de agréer les prestataires de service pour la
signature sécurisée et d’horodatage. certification électronique
4.3- Certificats SSL/TLS

Certificats SSL/TLS
SSL (Secure Socket Layer) est un protocole à négociation (on parle du « HandShake »
SSL), développé à l’origine par Netscape. Il a pour but de sécuriser les transactions
Internet, par authentification du client (Un navigateur la plupart du temps) et du
serveur, et par chiffrement de la session.
TLS (Transport Layer Security Protocol), développé par l’IETF, est la version 3.1 de SSL.
Les Services fournis sont les suivants :

B Intégrité des données transmises ;
? md5, sha-1
B Confidentialité des données transmises
? rsa, des, 3des ...
B Authentification de l’identité des correspondants la connexion est fiable
? X509 et MAC
TCP/IP
Pour comprendre SSL, il est utile de voir sur quoi il repose.
IP (Internet Protocol) est le nom donné au protocole qui déploie le trafic sur
l’Internet.
B Le trafic est transmis par petits paquets qui contiennent les adresses IP de l’expéditeur
et du destinataire.
TCP (Transmission Control Protocol) repose au-dessus de IP.

B Il est orienté connexion, ce qui signifie que certains types de paquets sont transmis et
acceptés dans le but d’ouvrir une connexion.
B Les paquets qui suivent peuvent alors être reconnus comme appartenant à une connexion
établie précédemment.
TCP et IP
Le protocole IP est responsable du transport de paquets d’une adresse internet à
une autre.
B Chacun des petits paquets sait où il va et d’où il vient.
? les adresses IP.
B Deux paquets envoyés par le protocole IP ne sont pas nécessairement reçus dans le
même ordre.
Le protocole TCP utilise le protocole IP pour établir des connexions.

B Ceci permet de réordonner les paquets dans l’ordre d’expédition.
B S’il y a perte d’un paquet, celui-ci sera demandé à nouveau.
TCP/IP est responsable de la communication à travers une connexion entre deux

adresses IP.
L’architecture de TCP/IP est par couches (« layers »).

La pile TCP/IP
La pile TCP/IP
La pile TCP/IP
La pile TCP/IP
La pile TCP/IP
Trames-Datagrammes-Segments
Trames-Datagrammes-Segments
Les protocoles SSL / TLS : Généralités

Repose sur un procédé de cryptographie à clef publique
Indépendant du protocole utilisé
B Transactions Web (HTTP), connexions via FTP, POP ou IMAP.
B Agit telle une couche supplémentaire,
? permettant d’assurer la sécurité des données,
? située entre la couche application et la couche transport


Les protocoles SSL / TLS : Connexion et session SSL
Connexion :
B Offre certains services de sécurité entre deux entités.
B Éphémère mais établie dans le cadre d’une Session SSL
Session :
B Association entre un client et un serveur
B Etabli lors du protocole de "Handshake"
B Un ensemble de paramètres de sécurité, dans chaque sens, est négocié une seule fois
et partagé par les connexions
B L’état courant défini les paramètres courants, l’état en attente ("Session pending
state") défini les paramètres suivants (cf. "Change Cipher Spec Protocol")
? Nota : il peut y a avoir plusieurs sessions établies entre 2 mêmes partenaires (rarement)
Les protocoles SSL / TLS : Paramètres de la session
"Session identifier"
"Peer certificate" :
B certificat X509 ou rien
"Compression method"
"Cipher specification" :
B algo. de chiffrement et algo. d’authentification et leurs paramètres
"Master secret"
B 48 octets partagés entre le client et le serveur
"Is resumable" :
B Les paramètres de la session peuvent être utilisés pour établir une connexion
Les protocoles SSL / TLS : Paramètres de la session

"Server and client random" :
B Choisie à chaque nouvelle connexion.
"Server write MAC secret" et "Client write MAC secret "

B Un secret utilisé pour vérifier l’intégrité des messages (un pour chaque sens).
"Server write key" et "Client write key" :

B Pour le chiffrement, dans le sens serveur-client et vice-versa.
"Initialization vectors" :
B Utilisés en mode CBC. Le premier IV est issu du protocole "Handshake", puis le
dernier bloc chiffré sert d’IV pour la prochaine transmission chiffrée, au sein de la
même connexion.
"Sequence numbers" :
B Un numéro de séquence est mémorisé, un pour chaque sens de transmission.
Les protocoles SSL / TLS : Structure

Les protocoles SSL / TLS : Vue globale
SSL est composé des protocoles suivants :

Record Protocol : Responsable du transport des données brutes. Il communique
avec la couche transport. Il chiffre et authentifie (calcule un CAM)
l’information en utilisant le cipher_spec.
? Si le cipher_spec est vide, alors l’information n’est ni chiffrée ni authen-
tifiée.
Handshake Protocol : Responsable de l’échange de clés authentifiées. Le but de

ce protocole est d’amener le client et le serveur qui ne partagent pas
de clés à s’entendre sur un cipher_spec, choisi parmi ceux voulus par
le client, avant d’exécuter l’échange de clés authentifiées.
ChangeCipher Protocol : Un message ou une entité annonce à l’autre un chan-
gement de cipher_spec tel que négocié précédemment.
Alert Protocol : Un message indiquant une erreur.
L’anatomie de SSL
L’anatomie de SSL
L’anatomie de SSL
Opérations du « SSL Record protocol »







[0]
[0]
Fragmentation :
B frontières messages clients peuvent être déplacées
B fragments de 214 octets au plus
Compression (optionnelle) :
B ajoute au pire 1024 octets
B sans pertes
Sceau :
B HMAC(MAC_write_secret, seq_num+type de
protocole TLS+version TLS+taille du fragment
compressé+fragment compressé)
+ = concaténation
Chiffrement :
B le fragment peut être paddé (chiffrement par blocs)
B on chiffre le fragment compressé + MAC

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :

[0]
[0]
Fragmentation :
B sans pertes
Sceau :
+ = concaténation
Chiffrement :
Transmission d’un message d’alerte aux entités.

B Ces messages peuvent être compressés et chiffrés
comme les autres messages de la même session.
Le champ "Level" :
B "warning" = 1
B "fatal" = 2 :
? la connexion est close et il n’y aura plus de
nouvelles connexions pour cette Session
Le champ "Alert" spécifie l’erreur :

B "unexpected_message", "bad_record_MAC",
"decompression_failure", "handshake_failure",
"illegal_parameter" // "close_notify",
Handshake Protocol
[0] Communications
[1]
[0] [0]
[1]
Client Hello
−−−−−−−−−−−−−−−−−→ [1]
Serveur Hello client Hello :
serveur Hello ←−−−−−−−−−−−−−−−−−−−−
B sélection de version SSL B la version SSL maximale
certif icat B liste d’algos supportés
B sélection d’algos −−−−−−−−−−−−−−−−−−−→
B un nonce
B un nonce échange de clé
−−−−−−−−−−−−−−−−−−−→
certificat :
certificat : f in hello
B Transmet certificat X509 −−−−−−−−−−−−−−−−−−−→ B certificat éventuel client
B signature de la discussion
B Demande certificat client (rare) certif icat
←−−−−−−−−−−−−−−−−−−−
échange de clé II :
échange de clé I : échange de clé
B Message complémentaire pour l’échange de clé
←−−−−−−−−−−−−−−−−−−−− B clé pré-master chiffrée
f in
fini : ←−−−−−−−−−−−−−−−−−− fini :
SSL / TLS : Négociation de session
Déroulement habituel d’un handshake SSL

avec authentification mutuelle :
B en noir, les échanges initiés par le serveur.
B en rouge, les échanges initiés par le client.

P hase 1 : Établissement des paramètres de sécurité

Client Hello
B heure
B tirage nombre aléatoire client.random (28 octets)
B session Id : vide = nouvelle session, renseigné = utiliser
session déjà ouverte
B choix d’algorithmes de chiffrement supportés
B méthode de compression supportés
B n° version du client SSL utilisé
Server Hello
B le serveur sélectionne la version
B tirage nbre aléatoire : server.random (28 oct)
B session Id : renseigné = numéro nouvelle session, ou
session à réutiliser, vide = session à ne pas mettre en cache
B algorithme de chiffrement sélectionné
B méthode de compression à utiliser
Si session réutilisée, passer en FINISH
P hase 2 : Authentification du serveur et échange des clés
Server certificate
B envoyé si le serveur doit s’authentifier, dès que Server Hello
a été envoyé
B ontient une chaîne de certificats X509 v3 (avec le certificat
racine en dernier), correspond à l’algo utilisé (RSA, DH, >)
=⇒ le client dispose donc de la clé publique du serveur
Server key exchange
B envoyé uniquement si le client n’a pas toutes les données
nécessaires
? ex : le serveur n’a pas de certificat
B paramètres de la clé de chiffrement (modulo, exposant>)
B hash MD5/SHA
? client.random + server.random+paramètres
P hase 2 : Authentification du serveur et échange des clés
Certificate request
B envoyé uniquement si l’authentification du client est requise
B types de certificats admis
=⇒ noms d’autorités de certification reconnues
Server hello done
B le serveur attend une réponse du client
Client certificate
B envoyé uniquement si le serveur a réclamé une
authentification du client
B certificat
B si le client ne possède pas de certificat, une alerte est
envoyée au serveur. Suivant les cas, cela peut faire échouer
la négociation.

P hase 3 : Authentification du client et échange des clés
Client key exchange

B dans le cas de l’algorithme RSA, le client génère un "pre-master secret" de 46 octets +
2 octets n° version (pour détecter les « rollback attacks »)
B il chiffre ce pre-master secret avec la clé publique du serveur
Calcul des clés
B le pre-master secret, client.random et server.random permettent au client et au
serveur de calculer :
? 2 clés de sessions (une pour chaque sens),
? 2 clés secrètes à utiliser pour les MACs .
P hase 3 : Authentification du client et échange des clés
Certificate verify
B envoyé si le client a envoyé un certificat qui permet de signer
B hash MD5 et hash SHA de tous les messages de négociation envoyés jusqu’ici
Client Finish et Server Finish

B envoyé après un Change Cipher Spec et donc chiffré avec les nouveaux algorithmes
négociés.
B client et serveur doivent envoyer un "Finish" et vérifier celui qu’il reçoive de la partie
opposée.
B PRF(master_secret,finished_label, Hash MD5 +Hash SHA de tous les messages de
négociations envoyés jusqu’ici) sur 12 octets, finished_label = "client finished" ou
"server finished".
SSL sans authentification du client
Comme nous venons de le voir, un client SSL n’est pas obligé de s’authentifier.
B SSL permet des sessions où seulement le serveur s’authentifie au client mais pas
l’inverse.
Dans bien des situations, c’est la meilleure chose possible,

B car les clients n’ont pas nécessairement de clés publiques certifiées.
Dans cette situation, le client sait qu’il parle au bon serveur,

B mais le serveur ne sait rien de l’identité du client.
L’identification du client peut alors se faire (comme c’est le cas dans la pratique) en
demandant un mot de passe.
L’authentification du client par mot de passe

Supposons qu’un serveur WEB détient une liste d’utilisateurs + mots de passe mais
les utilisateurs n’ont pas de clés publiques certifiées. Seul le serveur possède une
telle clé publique.
Le serveur veut authentifier un utilisateur qui se connecte.
Comment faire ?
B Ouvrir une session SSL,
B Demander à l’utilisateur de fournir son mot de passe.
Limites de l’approche par mot de passe
Le client ne peut s’authentifier qu’au serveur qui connaît un mot de passe pour
celui-ci.
La sécurité d’une telle session est plus difficile à établir, puisque la gestion des mots
de passe n’est pas intégrée au protocole mais arrive plus tard.
De tels systèmes sont aussi sûrs que le mot de passe. Donc, il semble qu’un
système qui établirait l’identité d’un client basé sur un mot de passe dès le départ
serait au moins aussi bon :
B Plus précisément, nous pourrions avoir un protocole d’établissement de liaison qui ne
puisse être compromis plus rapidement que le temps nécessaire pour deviner le mot de
passe en ligne.
B Rien de mieux ne peut être obtenu.
B Un tel échange de clés est dit « échange de clés authentifié par mots de passe ».
Échange de clés authentifié par mot de passe
Ceci semble facile. Les deux parties connaissent un secret pw :

B Nous n’avons qu’à dériver une clé secrète directement à partir de pw ou même utiliser
pw directement pour le chiffrement et le calcul de CAM...
B L’utilisation à long terme sur beaucoup de données cause des problèmes de sécurité.
B Les mots de passe doivent être assez courts pour être faciles à mémoriser. Le nombre
de mots de passe possibles est donc beaucoup plus petit que le nombre de possibilités
pour la clé secrète d’un chiffrement symétrique.
B L’adversaire, ayant intercepté un cryptogramme, peut donc tenter le déchiffrement en
essayant les mots de passe possibles hors ligne...tandis que deviner le mot de passe en
ligne peut résulter en une désactivation du compte après quelques essais infructueux.
Ce problème difficile a des solutions connues (p.ex. Bellare et al. Eurocrypt’2000) .
Quelques-uns (sans preuve formelle de sécurité) sont considérés pour
standardisation par l’Internet Engineering Task Force et IEEE. Ne sont pas utilisés
par les produits commerciaux...
SSL versus TLS
Le même format de message.

L’un est propriétaire, l’autre publique (IETF).
Les différences mineures résident dans :
B version number
B message authentication code
B pseudorandom function (TLS : fonction PRF)
B alert codes (TLS en ajoute plusieurs)
B cipher suites
B client certificate types
B certificate_verify and finished message
B cryptographic computations
HTTPS
HTTPs
= HTTP standard sur le port 443 (à la place de 80)
+ TLS
+ TCP/IP
Généralement le driver SSL/TLS est intégré au navigateur

Applications
Secure HTTP est le nom donné à l’utilisation de SSL ou TLS pour établir une connexion sûre entre
un serveur WEB et son client. Le résultat est un tunnel entre le client et le serveur, par
lequel chaque transmission est chiffrée sans que l’application ait à s’en soucier :
https://www.abc.def.com
VPN (Virtual Private Network) permet d’établir des connexions sûres entre un client distant et un réseau
local. Durant la phase d’initialisation entre le client et la passerelle VPN, celui-ci se voit
attribuer une adresse IP comme s’il était membre du réseau local.
B Une fois initialisées, toutes les communications sont chiffrées et authentifiées. Pour ce
faire, un échange de clé est nécessaire. Des VPN le réalisent avec leurs propres méthodes
tandis que d’autres utilisent IPSec ou SSL/TLS. VPN permet de travailler comme si le
client faisait partie du réseau local. Des employés peuvent travailler à la maison avec les
mêmes privilèges qu’au bureau.
Applications de haut niveau
Les protocoles que nous avons rencontrés sont de bas niveau. Ils ne sont pas bien
adaptés aux humains !
B SSL ne peut être utilisé pour signer des courriels ou documents, car SSL ne reconnaît pas le
concept de document.
La cryptographie appliquée à des objets de plus haut niveau est offerte par d’autres
solutions.
MIME : un standard pour la transmission des courriels. S/MIME est un standard avec des
champs supplémentaires pour la signature et le chiffrement de courriels.
XML : un standard qui propose une extension de HTML qui, en particulier, permet de
chiffrer et de signer des pages Web.
PGP (Pretty Good Privacy) : permet de signer et de chiffrer des courriels. Au lieu de baser la
sécurité sur des CA, il utilise un concept de toile de confiance («web of trust»).
Votre ami(e) peut vous envoyer une clé publique d’une troisième personne qui
déclare que ceux-ci font confiance à cette clé. Vous pouvez décider de faire confiance
à cette clé si suffisamment de vos amis l’ont recommandée.
SSL / TLS : Attaques
Attaques sur les mise en œuvres des protocoles

B Comme toute appli logicielle, les MeV de SSL/ TLS peuvent présenter vulnérabilités
permettant à un utilisateur mal intentionné d’exécuter du code arbitraire à distance ou
de provoquer un DoS.
? Appliquer CORRECTIFS correspondants aux MAJ de ces applis
Attaques rollback (sur anciennes versions)
B l’attaquant cherche à modifier le choix des algos d’échanges de clés de façon à ce que
les 2 entités n’utilisent pas les mêmes.
? RSA et DH par exemple
B cet attaquant pourra déchiffrer le message car les paramètres fournit par le serveur
dans le cas d’un algorithme n’offrent aucune sécurité si on les applique à un autre...
B Cette attaque peut-être réalisée si une session 3.0 est résumée en session 2.0 par
exemple.
SSL / TLS : Attaques
Attaque de type "man in the middle"
B intercepter trafic entre deux parties avant qu’elles ne débutent une session SSL.
L’intercepteur négocie alors une session avec chaque partie et fait suivre le trafic en le
déchiffrant et rechiffrant à la volée.
B E.g., dans le cas de l’utilisation du protocole HTTPS par un client web pour authentifier
un serveur, l’intercepteur crée un certificat ressemblant au certificat légitime du serveur
et détourne le trafic.
B Si, malgré l’avertissement du navigateur sur le certificat, le client poursuit sa session,
l’intercepteur obtiendra toutes les infos que le client envoie au serveur sans que ce
dernier ne s’en rende compte.
B ++ outils qui reproduisent cette attaque sont disponibles sur l’Internet.
SSL / TLS : Solutions

Vérifier correctement le certificat présenté par le serveur. C’est Vérifier correctement le
certificat présenté par le serveur. C’est la seule manière de s’assurer que la connexion ne sera
pas la seule manière de s’assurer que la connexion ne sera pas interceptée par un éventuel
attaquant. interceptée par un éventuel attaquant.
B Dans les navigateurs, les certificats racine de certaines autorités de certification sont pré-
installés.
B Lorsque le certificat présenté par un serveur n’a pas été signé par l’une de ces autorités, le
navigateur demande confirmation avant d’accepter le certificat. Il faut alors s’assurer que le
certificat présenté par le serveur est le bon certificat.
B Cette vérification peut se faire à l’aide de deux champs du certificat :
? le numéro de série et l’empreinte numérique (empreinte md5 ou sha1).
? Pour vérifier la concordance des informations, il faut disposer d’un moyen de communication
de confiance (téléphone, courrier, diffusion de la main à la main, ...) par lequel pourront être
comparés les numéros de série et les empreintes.
? De même, il ne faut installer un certificat d’autorité qu’après s’être assuré que le certificat est
correct.
SSL / TLS : Limites

SSL/TLS servent à sécuriser les échanges d’informations entre un client et un serveur et à obtenir
une authentification mutuelle.
Une session SSL/TLS correctement établie va donc protéger les échanges entre les parties, mais
ne sera en protéger les échanges entre les parties, mais ne sera en aucun une garantie de sécurité
pour les systèmes client aucun une garantie de sécurité pour les systèmes client ou serveur.
Ainsi, si un pirate installe par exemple un enregistreur de frappe (ou keylogger) sur le poste client,
il sera en mesure frappe (ou keylogger) sur le poste client, il sera en mesure de récupérer les mots
de passe ou toute information de récupérer les mots de passe ou toute information confidentielle,
même si celle-ci a été émise lors d’une confidentielle, même si celle- ci a été émise lors d’une session
SSL/TLS.
De même, un serveur qui utilise des sessions SSL/TLS pour récupérer des données sensibles peut
être compromis et récupérer des données sensibles peut être compromis et les données recueillies
pourront être volées. les données recueillies pourront être volées.
ll est donc primordial d’utiliser les protocoles SSL/TLS en prenant certaines précautions, et ne
pas leur prêter une prenant certaines précautions, et ne pas leur prêter une trop grande garantie
de sécurité sur l’ensemble de la trop grande garantie de sécurité sur l’ensemble de la chaîne
d’information chaîne d’information.
Fin de Séance
Vos Questions ?

Certificats, PKI Et SSL - Séance 7

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

Certificats, PKI Et SSL - Séance 7

Transféré par

Droits d'auteur :

Formats disponibles

4- Certificats, PKI et SSL

4- Certificats, PKI et SSL

Prof. Nabil KANNOUF

2 Infrastructure à Clés Publiques (PKI)

4.1- Certificat électronique

Cryptographie asymétrique et gestion à Clés : Problématique

B Obtenir la clé publique d’une autre entité

B Distribuer sa propre clé publique

B Révoquer une clé publiée

B Déterminer si une clé publiée est valide ou non

Distribution à Clés publiques

Une autorité de certification (CA) résout ce problème :

C’est l’Autorité de Certification (AC), véritable Tiers de Confiance, qui garantit la

Le certificat est la pièce d’identité électronique qui permet de :

Le certificat électronique peut être utilisé pour :

L’autorité de Certification (CA)

La validité des éléments d’authentification contenus dans le certificat numérique est

Obtention d’un certificat numérique auprès d’une CA

Obtention d’un certificat numérique auprès d’une CA

1 Bob demande à la CA de lui fournir le certificat numérique d’Alice ;

4.2- Infrastructure à Clés Publiques (PKI)

Infrastructure à clés publiques (PKI)

Ensemble de composants, fonctions et procédures dédié à la gestion

Infrastructure à clés publiques (PKI)

D’après le standard X.509 :

Infrastructure à clés publiques (PKI)

Autorité d’enregistrement (RA)

Composants d’une PKI

Modèle de confiance dans X.509

Modèle de confiance dans X.509

Modèle de confiance dans X.509

Modèle de confiance dans X.509

Modèle de confiance dans X.509

× Principal format utilisé pour les certificats

Structure d’un certificat X.509

Structure d’un certificat X.509

Structure d’un certificat X.509

Structure d’un certificat X.509

? cas où le CA a utilisé plusieurs clés depuis sa mise en œuvre

B Différencie entre plusieurs clés publiques,

B issues par le même CA,

B appartenant à un même détenteur

Structure d’un certificat X.509

Extensions d’un Certificat X.509

? besoin d’avoir d’autres informations que l’identité

? Introduction de blocs de données pouvant supporter n’importe quel type d’informations

Au Maroc, Barid e-Sign est la première

4.3- Certificats SSL/TLS

Les Services fournis sont les suivants :

Pour comprendre SSL, il est utile de voir sur quoi il repose.

TCP (Transmission Control Protocol) repose au-dessus de IP.

Le protocole TCP utilise le protocole IP pour établir des connexions.

TCP/IP est responsable de la communication à travers une connexion entre deux

L’architecture de TCP/IP est par couches (« layers »).

Les protocoles SSL / TLS : Généralités

Les protocoles SSL / TLS : Généralités

Les protocoles SSL / TLS : Généralités

Les protocoles SSL / TLS : Connexion et session SSL

Les protocoles SSL / TLS : Paramètres de la session

Les protocoles SSL / TLS : Paramètres de la session

"Server write MAC secret" et "Client write MAC secret "

"Server write key" et "Client write key" :

Les protocoles SSL / TLS : Structure

Les protocoles SSL / TLS : Vue globale