RSX112 Sécurité et réseaux

RSX112 Sécurité et réseaux Module 12 SSL, S/MIME, PGP 1 CNAM 2007-12/EBU

Résumé séance précédente Exercices Partage de secret Sécurisation du réseau SSL 2 CNAM 2007-12/EBU

Protocole SSL Handshake client serveur client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify change_cipher_spec finished change_cipher_spec finished Phase 1 : Négociation de l ID de session, de l algorithme d échange de clé, l algorithme de Hash, l algorithme de chiffrement, et échange des aléas initiaux Phase 2 : Le serveur peut envoyer son certificat et un message d échange de ; il peut demander au client d envoyer un certificat. Le serveur indique la fin de la phase hello. Phase 3 : Le client envoie son certificat si demandé et peut demander une vérification explicite. Le client envoie systématiquement son message d échange de clé. Phase 4 : Initialisation de paramètres et fin du handshake 3 CNAM 2007-12/EBU

Message «Client_Hello» client_hello client_version Version maximale supportée par le client client_random Heure actuelle (4 octets) + peusdo-aléa (28 octets) session_id Vide si le client veut créer une nouvelle session ou Identifiant d une ancienne session, dans laquelle le client veut créer une nouvelle connexion cipher_suites Liste des options cryptographiques supportées par le client, par ordre de préférence Une suite cryptographique contient les spécifications : Des algorithmes d échange de clé, de chiffrement et de hash Les algorithmes définissent implicitement les longueurs de hash, IV et les paramètres des clés (part of the Cipher Spec of the session state) exemple: SSL_RSA_with_3DES_EDE_CBC_SHA compression_methods Liste des méthodes de compression supportées par le client 4 CNAM 2007-12/EBU

Message «Server_Hello» server_hello server_version min(version maximale supportée par le client, version maximale supportée par le serveur) server_random Heure courante + aléa L aléa doit être indépendant de celui du client session_id Identifiant de session choisi par le serveur Si le client veut reprendre une session ancienne : Le serveur vérifie si la session peut être reprise Si oui, il répond avec l ID de session et les deux parties terminent par les messages «finished» Si le client veut une nouvelle session, le serveur génère un nouvel identifiant cipher_suite Suite unique sélectionnée par le serveur à partir de la liste fournie par le client compression_method Méthode de compression unique sélectionnée par le serveur parmi celles proposées par le client 5 CNAM 2007-12/EBU

Méthodes d échange de clés supportées Basées sur RSA (SSL_RSA_with...) La clé secrète (pre-master secret) est chiffrée avec la clé publique RSA du serveur La clé publique du serveur est envoyée au client durant l échange Fixed Diffie-Hellman (SSL_DH_RSA_with ou SSL_DH_DSS_with ) Le serveur a des paramètres DH fixes, contenus dans un certificat signé par une AC Le client peut avoir des paramètres DH fixes, contenus dans un certifcicat signé par une AC ou il peut envoyer des paramètres DH temporaires, non certifiés dans le message client_key_exchange ephemeral Diffie-Hellman (SSL_DHE_RSA_with ou SSL_DHE_DSS_with ) Le serveur et le client génèrent des paramètres DH temporaires (utilisables une seule fois) Le serveur signe ses paramètres DH avec sa clé privée RSA ou DSS Le client peut s authentifier (si le serveur le demande) en signant un hash des messages handshake avec sa clé privée RSA ou DSS anonymous Diffie-Hellman Le serveur et le client génère des paramètres DH temporaires utilisables une seule fois Ils envoient leurs paramètres à l autre sans authentification Fortezza Schéma d échange de clé propriétaire à Fortezza 6 CNAM 2007-12/EBU

Messsages «Server certificate» et «key exchange» certificate Nécessaire pour tout échange de clé sauf pour «anonymous DH» Contient un certificat ou une chaine de certificats X.509 Peut contenir : Une clé publique RSA pour le chiffrement ou Une clé publique RSA ou DSS pour la signature seulement, ou Des paramètres DH fixes server_key_exchange Envoyé uniquement si le certificat ne contient pas suffisamment d information pour réaliser l échange de clés (ex. le certificat ne contient qu une clé RSA de signature) Peut contenir : Une clé publique RSA (exposant et modulo), ou Des paramètres DH (p, g, valeur DH publique), ou Des paramètres Fortezza Signé Si DSS: signature du hash SHA-1 de (client_random server_random server_params) SI RSA: Concaténation et chiffrement avec la clé privée des hashes MD5 et SHA-1 de (client_random server_random server_params) 7 CNAM 2007-12/EBU

Messages «Certificate request» et «server hello done» certificate_request Envoyé si le client doit s authentifier Spécifie que type de certificat est attendu (rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, ) server_hello_done Envoyé pour indiquer que le serveur a terminé sa part de l échange de clé Après envoie de ce message, le serveur attend al réponse du client Le client doit vérifier que le serveur a fourni un certificat valide et que les paramètres du serveur sont acceptables 8 CNAM 2007-12/EBU

Authentification du client et échange de clé certificate Envoyé seulement si demandé par le serveur Peut contenir Une clé publique RSA ou DSS pour la signature, ou Des paramètres DH fixes client_key_exchange Systématiquement envoyé (mais vide si la méthode d échange de clé est «fixed DH») Peut contenir Un «pre-master secret» chiffré par RSA, ou Les valeurs DH temporaires du client, ou Les paramètres d échange de clé Fortezza certificate_verify Envoyé uniquement si le client envoie un certificat Permet l authentification du client Contient un hash signé de l ensemble des messages «handshake» précédents Si DSS: siganture d un hash SHA-1 Si RSA : concaténation des hashes MD5 et SHA-1 et chiffrement par la clé privée de MD5( master_secret pad_2 MD5( handshake_messages master_secret pad_1 ) ) SHA( master_secret pad_2 SHA( handshake_messages master_secret pad_1 ) ) 9 CNAM 2007-12/EBU

Messages «Finished» finished Envoyé immédiatement après un message «change_cipher_spec» Premier message à utiliser les nouveaux paramètres et algorithmes négociés Utilisé pour vérifier que l échange de clé et l authentification sont corrects Contient les hashes MD5 et SHA-1 de tous les messages «handshake» précédents : MD5( master_secret pad_2 MD5( handshake_messages sender master_secret pad_1 ) ) SHA( master_secret pad_2 SHA( handshake_messages sender master_secret pad_1 ) ) où sender est un code qui identifie si l émetteur est le client ou le serveur (client: 0x434C4E54; serveur: 0x53525652) 10 CNAM 2007-12/EBU

Initialisation des paramètres pre-master secret Si l échange de clé est basé sur RSA : Il est généré par le client Envoyé au serveur, chiffré par la clé publique RSA du serveur Si l échange de clé est basé sur Diffie-Hellman : pre_master_secret = g xy mod p master secret (48 bytes) master_secret = MD5( pre_master_secret SHA( A pre_master_secret client_random server_random )) MD5( pre_master_secret SHA( BB pre_master_secret client_random server_random )) MD5( pre_master_secret SHA( CCC pre_master_secret client_random server_random )) keys, MAC secrets, IVs MD5( master_secret SHA( A master_secret client_random server_random )) MD5( master_secret SHA( BB master_secret client_random server_random )) MD5( master_secret SHA( CCC master_secret client_random server_random )) key block : client write MAC secret server write MAC secret client write key server write key 11 CNAM 2007-12/EBU

Alternatives pour l échange de clé RSA / pas d authentification du client Le serveur envoie sa clé publique RSA pour le chiffrement dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés ou Le serveur envoie sa clé publique RSA ou DSS dans le message «server_certificate» Le serveur envoie une clé publique RSA temporaire dans le message «server_key_exchange» Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés 12 CNAM 2007-12/EBU

Alternatives pour l échange de clé RSA / authentification du client Le serveur envoie sa clé publique RSA pour le chiffrement dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie le «pre-master secret» dans le message «client_key_exchange» Le client envoie une signature de l ensemble des messages «handshake» précédents dans le message «certificate_verify» ou Le serveur envoie sa clé publique de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie une clé pub lique RSA temporaire dans le message «server_key_exchange» Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Le client envoie la signature sur l ensemble des messages «Handshake» précédents dans le message «certificate_verify» 13 CNAM 2007-12/EBU

Alternatives pour l échange de clé fix DH / pas d authentification client Le serveur envoie ses paramètres fixes DH dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie une clé temporaire DH dans le message «client_key_exchange» Les messages «client_ certificate» et «certificate_verify» ne sont pas envoyés fix DH / authentification du client Le serveur envoie ses paramètres fixes DH dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie des paramètres DH fixes dans le message «client_certificate» Le message «client_key_exchange» est envoyé vide Le message «certificate_verify» n est pas envoyé 14 CNAM 2007-12/EBU

Alternatives pour l échange de clé ephemeral DH / pas d authentification client Le serveur envoie sa clé publique de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie des paramètres DH temporaires signés dans le message «server_key_exchange» Le client envoie les paramètres DH public temporaires dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés ephemeral DH / authentification client Le serveur envoie sa clé de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie des paramètres DH temporaires signés dans le message «server_key_exchange» Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie des paramètre DH temporaires dans le message «client_key_exchange» Le client envoie une signature de l ensemble des messages «Handshake» précédents dans le message «certificate_verify» 15 CNAM 2007-12/EBU

Alternatives pour l échange de clé anonymous DH / pas d authentification client Le message «server_certificate» n est pas envoyé Le serveur envoie (non signé) des paramètres DH temporaires dans le message «server_key_exchange» Le client envoie des paramètres DH temporaires dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés anonymous DH / authentification client Pas autorisé 16 CNAM 2007-12/EBU

Analyse des protocoles - écoute Toutes les données applicatives sont chiffrées avec une clé temporaire La clé temporaire est dérivée de paramètres aléatoires liés à chaque connexion (aléas client et serveur) et d un secret commun (master secret) par un hash Même si les clés de connexions sont compromises, le «master secret» reste intact Des clés différentes sont utilisées pour chaque direction d échange d une connexion Les algorithmes supportés sont d un bon niveau de sécurité 17 CNAM 2007-12/EBU

Analyse des protocoles Analyse de traffic SSL n a pas pour objectif de protéger contre une analyse de trafic La longueur de bourrage n est pas aléatoire Pas de bourrage si un algorithme de chiffrement de flux est utilisé (option par défaut) Si SSL est utilisé pour protéger du trafic HTTP, un attaquant : Peut trouver la longueur d une requête URL Peut trouver la longueur des données HTML renvoyées Pourrait trouver avec une forte probabilité quelle URL a été demandée 18 CNAM 2007-12/EBU

Analyse des protocoles attaques actives sur la confidentialité Attaque : copier-coller SSL empêche les attaques de type «copier/coller» Des clés différentes sont utilisées dans les deux sens et pour chaque connexion Tous les paquets sont authentifiés par un hash 19 CNAM 2007-12/EBU

Analyse des protocoles attaque de rejeu SSL protège contre les attaques de rejeu en incluant un numéro de séquence dans les calculs de has Empêche de modifier l ordre des messages et leur suppression Les numéros de séquences font 64 bits En pratique, on ne réutilise partiquement jamais le même numéro 20 CNAM 2007-12/EBU

Analyse des protocoles authentification des messages SSL utilise un hash type HMAC Il utilise une version ancienne de HMAC Le hash utilisé est suffisamment sécurisé Le secret du hash fait 128 bits de long Différents secrets de hash sont utilisés pour les différentes directions d échange et les différentes connexions Le hash n intègre pas le numéro de version (compris dans le message) Si le numéro de version est utilisé, il doit être intégré dans le calcul du hash Si le numéro de version n est jamais utilisé, il ne devrait pas être envoyé 21 CNAM 2007-12/EBU

Principe de Horton Il ne faut pas authentifier seulement les données mais également toutes les informations du contexte, desquelles dépendent les traitements et les interprétations des données (i.e., algorithmes, clés, information ajoutée aux en-têtes, etc) 22 CNAM 2007-12/EBU

Attaques sur les suites cryptographiques En SSL 2.0, un attaquant peut forcer l utilisation d un algorithme faible en modifiant la liste des algorithmes supportés dans les messages «hello» SSL 3.0 empêche cela en authentifiant tous les messages «Handshake» avec le «master secret» (dans les messages «finished») Le «master secret» est lui-même authentifié par d autres moyens Côté client Authentification implicite via le certificat serveur Seul le serveur peut déchiffrer le «pre-master secret» chiffré par RSA Seul le serveur only peut calculer le «pre-master secret» à partir des paramètres publics DH du client Authentification explicite par le message server_key_exchange (si envoyé) Les paramètres «ephemeral DH» sont signés par le serveur Côté serveur Authentification explicite par le messge «certificate_verify message» (si envoyé) Le message «certificate_verify» est signé par le client Il intègre le «master secret» 23 CNAM 2007-12/EBU

Attaque MITM 24 CNAM 2007-12/EBU

Attaque MITM SSL authentifie uniquement les paramètres RSA ou DH du serveur dans le message «server_key_exchange» Pas d authentification du contexte (méthode d échange de clé) qui permet d interpréter ces paramètres Pas conforme au principe de Horton! Un correctif : Faire un hash de tous les messages échangés avant le message «server_key_exchange» Include le hash dans la signature du message «server_key_exchange» 25 CNAM 2007-12/EBU

Attaque sur la version SSL Les implémentations SSL 3.0 continuent à supporter SSL 2.0 Un attaquant peut modifier le message «client_hello» pour qu il ressemble à une message «client_hello» de SSL 2.0 Le serveur et le client vont alors utiliser SSL 2.0 SSL 2.0 possède de nombreuses failles de sécurité Notamment, pas de message «finished» pour authentifier la phase «handshake» Cette attaque est difficile à détecter SSL 3.0 peut détecter des changements de version Le «pre-master secret» généré pas des clients pouvant faire du SSL 3.0 : struct{ ProtocolVersion client_version; // latest version supported by the client opaque random[46]; // random bytes } PreMasterSecret; Un serveur SSL 3.0 détecte la modification de version : lorsqu il réalise le protocole «Handshake» en version 2.0 et reçoit un «pre-master secret» qui inclut une version 3.0 comme dernière version supportée par le client 26 CNAM 2007-12/EBU

Attaque sur le Hash Le protocole «SSL Record» utilise HMAC Le protocole «SSL Handshake» utilise un protocole de hash MAC adapté sur certains points certificate_verify hash( master_secret pad_2 hash( handshake_messages master_secret pad_1 ) ) Finished hash( master_secret pad_2 hash( handshake_messages sender master_secret pad_1 ) ) De plus, ces MAC incluent le «master secret» SSL devrait utiliser systématiquement HMAC pour tous les hash 27 CNAM 2007-12/EBU

Synthèse sur les attaques Protocole «SSL Record» Bonne protection contre les attaques d écoute et de modification de trafic Devrait être amélioré contre les attaques d analyse de trafic (i.e., utiliser du bourrage aléatoire) Devrait utiliser la dernière version de HMAC Protocole «SSL Handshake» Certaines attaques actives sont impossibles Modification des suites cryptographiques disponibles Dégradation du numéro de version supporté D autres attaques actives sont encore possibles, en fonction de la façon don l implémentation interprète les spécifications SSL Supprimer les messages «change_cipher_spec» Modifier les méthodes d échange de clé Les calculs MAC devraient être remplacés par HMAC Conclusion SSL 3.0 a été un pas en avant important dans la sécurisation des applications Internet 28 CNAM 2007-12/EBU

TLS vs. SSL Numéro de version MAC Pour TLS, le numéro de version est 3.1 TLS utilise HMAC Le MAC intègre le champ de version de l en-tête «record» Plus de codes d alertes Suites cryptographiques TLS ne supporte pas les méthodes d échange et de chiffrement Fortezza certificate_verify message Le hase n est fait que sur les messages «handshake» En SSL, le hash contient le master_secret et du bourrage 29 CNAM 2007-12/EBU

TLS vs. SSL (suite) Pseudo-random function PRF P_hash(secret, seed) = HMAC_hash( secret, A(1) seed ) où A(0) = seed HMAC_hash( secret, A(2) seed ) HMAC_hash( secret, A(3) seed ) A(i) = HMAC_hash(secret, A(i-1)) PRF(secret, label, seed) = P_MD5(secret_left, label seed) P_SHA(secret_right, label seed) 30 CNAM 2007-12/EBU

Illustration de p_hash 31 CNAM 2007-12/EBU

TLS vs. SSL (suite) finished message PRF( master_secret, client finished, MD5(handshake_messages) SHA(handshake_messages) ) Initialisation des paramètres cryptographiques Le «pre-master secret» est calculé de la même façon que pour SSL master secret PRF( pre_master_secret, master secret, client_random server_random ) key block PRF( master_secret, key expansion, server_random client_random ) Le bourrage est fait avant le chiffrement par bloc Des bourrages de longueur variable sont autorisés (max 255 octets de bourrage) 32 CNAM 2007-12/EBU

Actualités sécurité Clé RSA 1024 bits cassée EPFL Clé faible Factorisation d un nombre de 350 chiffres 11 mois de calcul Google rachète GreenBorder Crée une barrière autour des navigateurs Contrôle les entrées/sorties des navigateurs Loi en Allemagne Interdiction d utiliser des outils «hackers» Mariage de Snort (IDS) et nmap (scanner) Deux failles Cisco dans les librairies SSL (Dos) Article sur les erreurs de programmation les plus répandues http://www.0x000000.com/?i=305 http://www.owasp.org/index.php/owasp_top_ten_project 33 CNAM 2007-12/EBU

Sécurisation de la messagerie S/MIME Services Formats de message Gestion des clés PGP Services Format de message Gestion des clés Gestion de la confiance 34 CNAM 2007-12/EBU

S/MIME : introduction Secure / Multipurpose Internet Mail Extension Extension sécurité à MIME Fournit des services similaires à PGP Basé sur une techno RSA Security Standard pour une utilisation commerciale et de société RFC 2630, 2632, 2633 35 CNAM 2007-12/EBU

RFC 822 Définit un format pour des messages texte à envoyer par e- mail Standard Internet Structure de messages conforme à RFC 822 Lignes d en-tête (i.e., from:, to:, cc: ) Ligne blanche Corps du message (texte à envoyer) Exemple Date: Tue, 16 Jan 1998 10:37:17 (EST) From: Levente Buttyan <buttyan@hit.bme.hu> Subject: Test To: afriend@otherhost.bme.hu Blablabla 36 CNAM 2007-12/EBU

Problèmes avec RFC 822 et SMTP Les fichiers exécutables doivent être convertis en ASCII Différents schémas existent (ex., Unix UUencode) Nécessité d un standard Données texte incluant des caractères spéciaux (ex., texte hongrois) Certains serveurs Rejettent les messages d une taille trop importante Suppriment, ajoutent ou ré-ordonnent les caractères CR et LF Tronquent ou génèrent de nouvelles lignes si elles font plus de 76 caractères Suppriment les espaces de fin (tabs et spaces) Complètent les lignes de message pour obtenir des ligens de longueur constante Convertissent les caractères tab en espaces multiples 37 CNAM 2007-12/EBU

MIME Définit de nouveaux champs d en-tête Définit différents formats de contenu (standardisation de la représentation de contenu multimedia) Définit les encodages de transfert qui protège le contenu de modification par le système de mail 38 CNAM 2007-12/EBU

MIME Nouveaux champs d entête MIME-Version Content-Type Décrit le contenu du corps du message L agent qui reçoit le mail peut choisir la méthode appropriée pour afficher le contenu Content-Transfer-Encoding Indique le type de transformation qui a été utilisée pour représenter le contenu du message Content-ID Content-Description Description de l objet dans le corps du message Utile quand le contenu n est pas lisible (ex., audio data) 39 CNAM 2007-12/EBU

MIME Content types et subtypes text/plain, text/enriched image/jpeg, image/gif video/mpeg audio/basic application/postscript, application/octet-stream multipart/mixed, multipart/parallel, multipart/alternative, multipart/digest (each part is message/rfc822) message/rfc822, message/partial, message/external-body 40 CNAM 2007-12/EBU

MIME Encodages de transfert 7bit 8bit Lignes courtes de caractères ASCII Lignes courtes de caractères non-ascii binary Caractères non-ascii Lignes non nécessairement courtes quoted-printable Les caractères non-ascii sont convertis en nombres hexadécimaux (e.g., =EF) base64 (radix 64) 3 blocs de 8 bits convertis en 4 blocs de 6 bits x-token Encodage non standard 41 CNAM 2007-12/EBU

MIME Exemple MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@nsb.fv.com> To: Ned Freed <ned@innosoft.com> Date: Fri, 07 Oct 1994 16:15:05-0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 Content-type: text/plain; charset=us-ascii Some text --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64... base64-encoded image data goes here... --unique-boundary-2-- 42 CNAM 2007-12/EBU

MIME Exemple (suite) --unique-boundary-1 Content-type: text/enriched This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller> Isn t it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-printable... Additional text in ISO-8859-1 goes here... --unique-boundary-1-- 43 CNAM 2007-12/EBU

S/MIME RFC 1847 et 2311 définissent deux nouveaux types MIME : application/pkcs7-signature Utilisé pour la signature dans un message «multipart/signed» Message résultant : deux parties MIME : le contenu du mail (avec le PJ éventuellement) la signature application/pkcs7-mime Utilisé comme format alternatif pour la signature Utilisé pour les messages chiffrés et les messages chiffrés et signés Message résultant : une partie MIME contenant les données (chiffrées) et la signature Utilisation du format PKCS#7 pour les signatures et les données chiffrées Syntaxe générale pour le formatage d information signées ou chiffrées S/MIME chiffre/signe toujours le messages et les PJ Nécessite des certificats X509 Utilise l attribut E du nom du sujet comme identité 44 CNAM 2007-12/EBU

Services S/MIME Données encapsulées (application/pkcs7-mime; smime-type = enveloped-data) Enveloppe digitale «standard» Données signées (application/pkcs7-mime; smime-type = signeddata) Signature numérique standard ( hash et signe ) contenu + signature sont encodés en base64 Données signées / texte en clair (multipart/signed) Signature digitale standard Seule la signature est encodée en base64 Les destinataires sans capacité S/MIME peuvent lire le message mais ne peuvent pas vérifier la signature Données signées et enveloppées signed and encrypted entities may be nested in any order 45 CNAM 2007-12/EBU

Algorithme cryptographiques Fonction de hashage Obligatoire : SHA-1 Possible (destinataire) : MD5 (rétro-compatibilité) Signature numérique Obligatoire : DSS Possible : RSA Chiffrement asymétrique Obligatoire : ElGamal Possible : RSA Chiffrement symétrique Emetteur : Possible : 3DES, RC2/40 Destinataire : Obligatoire : 3DES Possible : RC2/40 46 CNAM 2007-12/EBU

Exemple de données clair signées Exemple Partie MIME à signer 47 CNAM 2007-12/EBU

Contenu d une signature Structure ASN.1 pour les données signées Champ vide dans le cas du format multipart/signed Plusieurs signataires possibles Structure ASN.1 pour les signataires «SignerInfo» Signature 48 CNAM 2007-12/EBU

Données signées PKCS7 Version (Set of) Digest Algorithms Content type Content Info Content Set of certificates Set of CRLs Signer Info Version Signer ID (issuer and ser. no.) Digest Algorithm Authenticated Attributes Digest Encryption Alg. Encrypted digest (signature) 49 CNAM 2007-12/EBU

Signature multiple 50 CNAM 2007-12/EBU

Autre format de signature Contenu MIME intégré dans le champ «contentinfo» du format PKCS#7 Format «enveloppe» Avantage Pas de risque de transcodage Inconvénient Texte non lisible si le destinataire ne sait pas faire du S/MIME 51 CNAM 2007-12/EBU

Données chiffrées Structure ASN.1 pour le type «envelopeddata» du format PKCS#7 52 CNAM 2007-12/EBU

Données chiffrées pour plusieurs destinataires 53 CNAM 2007-12/EBU

Données «enveloppées» PKCS7 Version Originator Info Recipient Info Version Recipient ID (issuer and s.no.) Key Encryption Algorithm Encrypted Key Encrypted Content Info Content type Content Encryption Alg. Encrypted Content 54 CNAM 2007-12/EBU

Données chiffrées et signées Signature avant chiffrement Inverse possible 55 CNAM 2007-12/EBU

Gestion des clés Certificats utilisés par S/MIME : X.509 v3 La gestion des clés est entre la stricte hiérarchie de certification et le modèle de PGP Les certificats sont signés par des autorités de certification (CA) Utilisation de chaines de confiance Les utilisateurs sont responsables de la configuration de leur client pour intégrer la liste des AC de confiance K 56 CNAM 2007-12/EBU

Introduction à PGP PGP - Pretty Good Privacy Application générique destinée à protéger (chiffrer et/ou signer) des fichiers Peut être utilisé pour protéger des emails Peut être utilisé par des sociétés aussi bien que des individus Basé sur des algorithmes cryptogtraphiques forts (IDEA, RSA, SHA-1) Disponible gratuitement http://www.pgpi.org Version initiale développée par Phil Zimmermann En cours de normalisation dans les standards Internet (RFC 3156) 57 CNAM 2007-12/EBU

PGP : Services Sur les messages Authentification Confidentialité Compression Compatibilité e-mail Segmentation et ré-assemblage Gestion des clés Génération, distribution, et révocation de couples de clé publique/privée Génération et transport de clés de session et de vecteurs d initialisation 58 CNAM 2007-12/EBU

Authentification de message Basée sur des signatures Algorithmes supportés : RSA/SHA et DSS/SHA Emetteur hash hash K snd -1 m h σ chif chif Destinataire m h h σ hash hash comparaison comparaison OK / NOK déchif déchif K snd 59 CNAM 2007-12/EBU

Confidentialité de message Chiffrement symétrique en mode CFB avec clé de session et IV aléatoires La clé de session et les IV sont chiffrés avec la clé publique du destinataire Algorithmes supportés : Symétrique : CAST, IDEA, 3DES Asymétrique : RSA, ElGamal Emetteur m Chif. Chif. sy sy prng prng k, iv K rcv Chif. Chif. as as {k, iv} Krcv {m} k 60 CNAM 2007-12/EBU

Compression Appliquée après la signature Suffisamment pour stocker le message en clair et la signature pour vérification ultérieure Possibilité de compresser dynamiquement les messages avant la vérification de signature mais Toutes les implémentations PGP devraient alors utiliser le même algorithme de compression Cependant, différentes versions de PGP utilisent des algorithmes de compression légèrement différents Appliquée avant chiffrement La compression réduit les redondances et rend ainsi la cryptanalyse plus difficile Algorithme supporté : ZIP 61 CNAM 2007-12/EBU

Compatibilité E-mail Les messages chiffrés et les signatures peuvent comporter des octets quelconques La plupart des systèmes e-mail ne supportent que les caractères ASCII PGP convertit une chaine binaire quelconque en une chaine de caractères ASCII imprimables Conversion radix 64 : 3 blocs de 8 bits deviennent 4 blocs de 6 bits 0 7 0 7 0 7 0 5 0 5 0 5 0 5 6-bit value character encoding 6-bit value character encoding 0 A... 25 Z 26 a 51 z 52 0 61 9 62 + 63 / (pad) = 62 CNAM 2007-12/EBU

Combinaison des services X := := file file signature? no compress X := := Z(X) Z(X) encryption? no radix radix 64 64 X := := R64(X) R64(X) yes yes generate generate signature X := := σ(x) σ(x) X generate generate envelop envelop X := :={k} {k} Krcv Krcv {X} {X} k k 63 CNAM 2007-12/EBU

Format d un message PGP session key component signature key ID of K rcv session key k timestamp key ID of K snd leading two octets of hash hash { } Krcv { } Ksnd -1 filename timestamp ZIP { } k R64 message data 64 CNAM 2007-12/EBU

Gestion des clés Un utilisateur peut avoir plusieurs paires de clés privées/publiques Quelle clé privée utiliser pour déchiffrer la clé de session? Quelle clé publique utiliser pour vérifier une signature? Transmettre la clé publique complète à chaque fois n est pas optimal Associer un ID aléatoire à une clé publique alourdirait la gestion des clés L identifiant est constitué des 64 derniers bits de la clé publique Forte probabilité d unicité pour une utilisateur donné 65 CNAM 2007-12/EBU

Génération de nombres aléatoires Nombres aléatoires «vrais» Utilisé pour générer des paires de clés publiques/privées Fournit une source pour initialiser un générateur de nombres pseudo-aléatoire (PRNG) Fournit des données complémentaires pour les PRNG Nombres pseudo-aléatoires Utilisés pour générer des clés de session et de IV 66 CNAM 2007-12/EBU

«Vrais» nombres aléatoires PGP garde en permanence un buffer de 256 octets d aléa A chaque fois que PGP attend une saisie de la part de l utilisateur, il enregistre L heure à laquelle il commence à attendre (32 bits) L heure à laquelle la touche est pressée (32 bits) La valeur de la touche pressée (8 bits) L information enregistrée est utilisée pour générer une clé La clé est utilisée pour chiffrer la valeur courante du buffer d aléa 67 CNAM 2007-12/EBU

Nombres pseudo-aléatoires Basé sur la norme ANSI X9.17 K 1, K 2 DT i 3DES 3DES + 3DES 3DES V i+1 V i + 3DES 3DES R i 68 CNAM 2007-12/EBU

Nombres pseudo-aléatoires dtbuf EE + EE + EE + EE rseed rseed + EE + EE + EE + + + true random bits IV[0..7] K[8..15] K[0..7] Utilisation de CAST-128 au lieu de 3DES avec la clérkey 69 CNAM 2007-12/EBU

Nombres pseudo-aléatoires dtbuf[0..3] = heure courante, dtbuf[4..7] = 0 pre-wash Prendre un hash du message Déjà fait si le message est signé Sinon, utiliser les premiers 4K du message Utiliser le résultat comme clé, un IV nul, et chiffrer (rkey, rseed) previous en mode CFB si (rkey, rseed) previous est vide, le remplir avec du «vrai» aléa Mettre la valeur du résultat dans (rkey, rseed) current post-wash Générer 24 octets supplémentaires comme précédemment mais sans faire de XOR avec des octets de vrai aléa Chiffrer le résultat en mode CFB avec K et IV Mettre le résultat dans (rkey, rseed) previous 70 CNAM 2007-12/EBU

Base des clés privées Utilisée pour stocker les couples clé publique/clé privée d un utilisateur Table où chaque ligne contient les champs suivants : timestamp key ID (indexed) public key encrypted private key user ID (indexed) private key passphrase hash hash enc enc encrypted private key 71 CNAM 2007-12/EBU

Base des clés publiques Utilisée pour stocker les clés publiques des autres utilisateurs Table où chaque ligne contient les champs suivants : timestamp key ID (indexé) public key user ID (indexé, très souvent l adresse email) owner trust signature(s) (avec sa propre clé privée -> autosigné) signature trust(s) key legitimacy 72 CNAM 2007-12/EBU

Gestion de la confiance (1/3) Certificats auto-signés : faible niveau de confiance sur le lien clé publique/identité Chaque utilisateur PGP peut signer les clés publiques d autres utilisateurs Ne le faire que lorsqu on est sûr que la clé publique appartient bien à la bonne personne Procédé type «parrainage» qui renforce la confiance J ai la clé d Alice mais je ne suis pas sûr que ce soit la sienne mais Bob a signé la clé d Alice et je fais confiance à Bob pour avoir vérifié l identité d Alice et je sais que Bob a une clé publique correcte donc je peux probablement être relativement certain que ce sont bien les clés d Alice Possibilité de mettre sur un serveur les certifications faites par un utilisateur Quand un utilisateur télécharge une clé, il récupère également ces certifications 73 CNAM 2007-12/EBU

Gestion de la confiance (2/3) Chaque utilisateur affecte les clés de son magasin local avec un niveau de confiance de son possesseur «owner trust» Unknown (valeur par défaut) None (pas de confiance dans le possesseur) Marginal (confiance limitée) Full (confiance totale) Ultimate (confiance absolue, pour ses propres clés) Confiance dans la signature Calculé par le logiciel Sur la base de certificats locale 74 CNAM 2007-12/EBU

Gestion de la confiance (3/3) Validité de la clé Calculée par le logiciel PGP Si une signature est «ultimate» alors la signature est valide (= 1) Sinon, une somme pondérée est calculée Signature du certificat par des clés «full»a un poids de 1/X Signature du certificat par des clés «marginal»a un poids de 1/Y X et Y sont des paramètres configurables exemple: X=2, Y=4 1 «ultimate», ou 2 «full», ou 1 «full» et 2 «marginal» ou 4 «marginal» pour obtenir une clé valide 75 CNAM 2007-12/EBU

Exemple légitimité de la clé X = 1, Y = 2 G C H B D untrusted / usually untrusted E usually trusted always trusted ultimately trusted (you) signature legitimate F user A I 76 CNAM 2007-12/EBU L J K M

Révocation de clé publique Pourquoi révoquer une clé publique? Compromission (clé privée) re-keying Le possesseur publie un certificat de révocation Format identique à celui d une clé publique Contient la clé publique à révoquer Signé par la clé privée correspondante Publier ce certificat aussi largement et rapidement que possible 77 CNAM 2007-12/EBU