Certificats, PKI Et SSL - Séance 7 [PDF]

Zitiervorschau

4- Certificats, PKI et SSL

4- Certificats, PKI et SSL Crypto-systèmes Filière : GI2 Prof. Nabil KANNOUF UAE – ENSAH

7 mars 2022

4- Certificats, PKI et SSL

Plan

1

Certificat électronique

2

Infrastructure à Clés Publiques (PKI)

3

Certificats SSL/TLS

4- Certificats, PKI et SSL 4.1- Certificat électronique

4.1- Certificat électronique

4- Certificats, PKI et SSL 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

4- Certificats, PKI et SSL 4.1- Certificat électronique

Distribution à Clés publiques

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

Alice envoie sa clé publique au CA Alice prouve qu’elle détient la clé privée correspondant à la clé publique envoyée Le CA vérifie l’identité d’Alice 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

4- Certificats, PKI et SSL 4.1- Certificat électronique

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

4- Certificats, PKI et SSL 4.1- Certificat électronique

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.

4- Certificats, PKI et SSL 4.1- Certificat électronique

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

4- Certificats, PKI et SSL 4.1- Certificat électronique

Certificat électronique 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- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

4.2- Infrastructure à Clés Publiques (PKI)

4- Certificats, PKI et SSL 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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Infrastructure à clés publiques (PKI) 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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Infrastructure à clés publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Composants d’une PKI

Principaux B B B B

Autorité de certification CA Autorité d’enregistrement RA Annuaire de publication Administrateurs

Complémentaires B Base de données B Serveur d’horodatage. B Serveur HTTP, SMTP, POP.

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Structure d’un certificat X.509

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Structure d’un certificat X.509

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Structure d’un certificat X.509

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Structure d’un certificat X.509

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

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

4- Certificats, PKI et SSL 4.2- Infrastructure à Clés Publiques (PKI)

Certificat électronique Le Maroc ou on est ? ?

Au Maroc, Barid e-Sign est la première plateforme de production de certificats électroniques qui a pour mission de produire des certificats d’authentification forte, de signature sécurisée et d’horodatage.

Certifier les dispositifs de création et de vérification de signature électronique et agréer les prestataires de service pour la certification électronique

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

4.3- Certificats SSL/TLS

4- Certificats, PKI et SSL 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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 »).

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

La pile TCP/IP

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

La pile TCP/IP

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

La pile TCP/IP

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

La pile TCP/IP

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

La pile TCP/IP

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Trames-Datagrammes-Segments

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Trames-Datagrammes-Segments

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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)

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Les protocoles SSL / TLS : Structure

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 authentifié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 changement de cipher_spec tel que négocié précédemment. Alert Protocol : Un message indiquant une erreur.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

L’anatomie de SSL

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

L’anatomie de SSL

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

L’anatomie de SSL

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol »

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B ajoute au pire 1024 octets

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Opérations du « SSL Record protocol » 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",

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Handshake Protocol [0] Communications [1] [0]

[1]

serveur Hello

B sélection de version SSL B sélection d’algos B un nonce

certificat :

B Transmet certificat X509

B Demande certificat client (rare)

échange de clé I :

B fini :

Message complémentaire pour l’échange de clé

Client Hello −−−−−−−−−−−−−−−−−→ Serveur Hello ←−−−−−−−−−−−−−−−−−−−− certif icat −−−−−−−−−−−−−−−−−−−→ échange de clé −−−−−−−−−−−−−−−−−−−→ f in hello −−−−−−−−−−−−−−−−−−−→ certif icat ←−−−−−−−−−−−−−−−−−−− échange de clé ←−−−−−−−−−−−−−−−−−−−− f in ←−−−−−−−−−−−−−−−−−−

[0]

[1]

client Hello :

B la version SSL maximale B liste d’algos supportés B un nonce

certificat :

B certificat éventuel client

B signature de la discussion

échange de clé II :

B clé pré-master chiffrée fini :

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

SSL / TLS : Négociation de session 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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

SSL / TLS : Négociation de session 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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

SSL / TLS : Négociation de session 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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

SSL / TLS : Négociation de session 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 .

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

SSL / TLS : Négociation de session 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".

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 ».

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

É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...

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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 B B B B B B B

version number message authentication code pseudorandom function (TLS : fonction PRF) alert codes (TLS en ajoute plusieurs) cipher suites client certificate types certificate_verify and finished message cryptographic computations

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

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.

4- Certificats, PKI et SSL 4.3- Certificats SSL/TLS

Fin de Séance

Vos Questions ?