Politique d utilisation par AC et protocoles runo MARTIN, Université Nice Sophia Antipolis AC spécifie les champs obligatoires et optionnels. impose évent. cond. de validité sur des champs Exemple Vérif. requiert que le champ Common Name d un serveur corresponde au nom de domaine du serveur (unice.fr). Le certificat délivré par AC garantit la relation (Identité, pk) en vérifiant que l identité du détenteur du couple (pk,sk) correspond bien à celui inscrit dans le certificat. L AC s en assure lors de la requête de certificat. Si Alice requiert un certificat personnel, l AC doit tout d abord vérifier qu Alice est bien la personne requérante. runo MARTIN, Université Nice Sophia Antipolis et protocoles 1 runo MARTIN, Université Nice Sophia Antipolis et protocoles 4 Contenu d un certificat (X.509) Chaîne de certification Associe une clé publique à l identité d un sujet ; comprend : Subject : Nom Distingué, Clé publique Issuer : Nom Distingué, Signature Period of Validity :datededébut,datedefin Administrative Information : version, numéro de série Extended Information : où l information «Nom Distingué» comprend les champs : Common Name : nom à certifier Organization Company : contexte Organizational Unit : contexte spécifique City/Locality :ville State/Province : pour US Country :codepays runo Martin UNSA I3S Sophia Antipolis PACA fr Une AC peut aussi fournir un certificat à une autre AC. Alice peut ainsi remonter une chaîne de certification jusqu à trouver une AC en qui elle a confiance. Elle peut aussi décider de limiter la taille de la chaîne de certification pour diminuer le risque qu un des certificats de la chaîne soit mauvais. AC r Id,clé AC r Id ACr,K ACr AC r Id AC1,K AC1 AC 1 Id AC,K AC AC Id A,clé A AC r Id C,clé C runo MARTIN, Université Nice Sophia Antipolis et protocoles 3 runo MARTIN, Université Nice Sophia Antipolis et protocoles 5
Création d une AC «racine» Services de certification Problème :ilfautuneac«racine»quinepeutsefairecertifier. Son certificat est auto-délivré. L entité qui délivre le certificat est identique au sujet certifié. La confiance repose dans une large distribution de la pk de l AC. Les clients et les serveurs sont configurés pour faire confiance à certaines AC par défaut, comme CertiSign ou VeriSign. Ces sociétés proposent des techniques de gestion des certificats, ont des procédures de vérification de l information, délivrent des certificats. Il est possible de se déclarer comme AC «racine», utile au sein d un intranet, où la vérification de l information est plus aisé. runo MARTIN, Université Nice Sophia Antipolis et protocoles 6 Commercialisent, délivrent des certificats via procédure spécifique. Gèrent des liste de révocation des certificats : liste des certificats corrompus ou invalides certificats cassés certificat d un sujet obsolète (licenciement, panne serveur) Réalisation «asymétrique» : au moyen d un schéma de signature avec appendice qui consiste en [2] : une opération de signature une opération de vérification sur le contenu d un certificat. Si le contenu est conforme à la norme X509, on fournit un identificateur numérique ou Digital ID, sorte de carte d identité numérique. runo MARTIN, Université Nice Sophia Antipolis et protocoles 8 Rupture dans la chaîne & Vérification Id A,clé A hachage h Sign AC Sign AC (h(id A,clé A )) AC Id A,clé A Clé de A certifiée par AC Id A,clé A Sign AC (h(id A,clé A )) AC Id A,clé A Id A,clé A Clé de A certifiée par AC Sign AC (h(id A,clé A )) hachage h h(id A,clé A ) Ver AC Algorithme public de vérification de AC oui/non runo MARTIN, Université Nice Sophia Antipolis et protocoles 7 runo MARTIN, Université Nice Sophia Antipolis et protocoles 9
Une attaque MIM de plus haut niveau Porte sur la transmission d un certificat dont l AC n est pas connue. C est le cas, par exemple, d un certificat auto-délivré. Avec quel outil? Des logiciels libres comme dsniff ou ettercap permettent de mener à bien de telles attaques sur un LAN. runo MARTIN, Université Nice Sophia Antipolis et protocoles 10 runo MARTIN, Université Nice Sophia Antipolis et protocoles 12 Certificat original et celui falsifié Attaque de l homme du milieu en pratique sur un LAN Serveur IP:192.168.1.12 MAC: 00:0b:db:c9:df:44 Melchior IP:192.168.1.113 MAC: 00:11:43:cd:0a:c8 Client IP: 192.168.1.1 MAC: 00:50:da:16:cb:08 192.168.1.1=00:11:43:cd:0a:c8 192.168.1.1=00:50:da:16:cb:08 192.168.1.12=00:11:43:cd:0a:c8 192.168.1.12=00:0b:db:c9:df:44 contenu des tables arp 1 1 192.168.1.1 192.168.1.12 vers de 2 192.168.1.12 192.168.1.1 vers de 192.168.1.1 192.168.1.12 vers de 2 192.168.1.12 192.168.1.1 vers de runo MARTIN, Université Nice Sophia Antipolis et protocoles 11 runo MARTIN, Université Nice Sophia Antipolis et protocoles 13
services de sécurité implémentent la politique de sécurité. Certains services inutiles pour une politique donnée. Exemple : intégrité ne requiert pas le chi rement Chaque service traite un ensemble particulier de menaces Exemple : confidentialité prémunit contre l accès non-autorisé à l information. Services de sécurité implémentés par les mécanismes de sécurité certains services utilisent le même mécanisme Exemple : hachage utilisé en identification et signature. Implémentent les services de sécurité chi rement signatures numériques mécanismes de contrôle d accès mécanismes d integrité des données mécanismes d authentification empaquetage pour le trafic contrôle de routage tiers de confiance (notariat électronique) gestionnaire de sécurité (gestion des clés) audit détection d intrusion runo MARTIN, Université Nice Sophia Antipolis et protocoles 15 runo MARTIN, Université Nice Sophia Antipolis et protocoles 17 Services de sécurité Standards Internet et l IETF Définis dans la norme ISO 7498-2 comme : 1 service d authentification d entités service d authentification de l origine des données 2 service de contrôle d accès 3 service de confidentialité avec/sans connexion service de confidentialité sélectif service de confidentialité du flux de trafic 4 service d intégrité de connexion avec/sans récupération service d intégrité sélectif service d intégrité sans connexion (sélectif ou non) 5 non répudiation avec preuve d origine non répudiation avec preuve de dépot l Internet Engineering Task Force (IETF) : groupe technique chargé de l ingénierie et de l évolution d Internet. Propose des standards via des groupes de travail, p.e. en sécurité : Open specification for PGP Authenticated Firewall Traversal Common Authentication Technology Domain Name Security IP Security Protocol (IPSEC) One time password authentication Public Key Infrastructure S/MIME Mail Security Secure Shell Simple Public Key Infrastructure Transport Layer Security Web Transaction Security runo MARTIN, Université Nice Sophia Antipolis et protocoles 16 runo MARTIN, Université Nice Sophia Antipolis et protocoles 18
Que produit l IETF? Modèles pour l établissement de clés Des RFC (Request for Comments) proposent des standards pour l évolution d internet. Des documents de travail, Internet Drafts sans statut formel de durée de vie de 6 mois. Les RFC recouvrent une grande variété de documents allant des documents informels jusqu à la spécification complète de certains protocoles. Une fois publié comme RFC le document reçoit un numéro. Un document n est ni revu ni ré-édité sous le même numéro. On les trouve à l adresse www.ietf.org/rfc.html Procédé qui rend disponible une clé à une ou plusieurs entités. Recouvre : transport de clés (publiques, secrètes) mise à jour des clés dérivation des clés mise en accord symétrique runo MARTIN, Université Nice Sophia Antipolis et protocoles 19 runo MARTIN, Université Nice Sophia Antipolis et protocoles 22 Techniques de gestion de clés [1] Reposent sur chi rement utilisation des clés politique de sécurité génération réactivation permettent d éviter : Prête Active Usée la modification la destruction malintentionnée le rejeu la divulgation (disclosure) activation destruction désactivation destruction Pendant toute la durée de vie des clés, il faut assurer : la génération sûre suppression révocation la certification l enregistrement distribution destruction installation Transport de clés esoin d échanger des clés de façon sûre : évident dans le cas de la crypto à clé secrète contrer «MIM» pour la crypto à clé publique Comment faire? techniques cryptographiques : chi rement contre la divulgation et l utilisation frauduleuse. mécanismes d intégrité contre la modification abusive. mécanismes d authentification contre la masquarade. runo MARTIN, Université Nice Sophia Antipolis et protocoles 21 runo MARTIN, Université Nice Sophia Antipolis et protocoles 23
Premières solutions Etablissement de clés au sein d un même domaine 1 Fixer un rendez-vous pour échanger les clés 2 Envoyer la clé par un courrier spécial 3 Utiliser une clé partagée pour chi rer une nouvelle clé Discussion 2 premiers cas : contact nécessaire pour échanger la clé. Pas toujours possible. P.e. dans un conflit. Dans le dernier cas, on considère un réseau de communication entre N utilisateurs. Pour que chaque utilisateur puisse communiquer avec n importe quel autre de façon sûre, il faut! N " 2 = O(N 2 ) clés partagées distribuées de manière sûre. Solution possible : centre de distribution de clé (CDC) en qui tout le monde a confiance. Chaque utilisateur partage une clé secrète avec le CDC. Quand A veut communiquer avec, elle choisit une nouvelle clé de session et l envoie (chi rée) au CDC qui la retransmet à chi ré avec la clé commune entre le CDC et. Moyen convenable pour l échange au sein d un même domaine. entité A CDC entité 1 tout le monde a confiance en CDC! 2 Tous les utilisateurs partagent une clé avec le CDC 3 CDC a accès à tous les messages échangés runo MARTIN, Université Nice Sophia Antipolis et protocoles 24 runo MARTIN, Université Nice Sophia Antipolis et protocoles 26 Etablissement de clés point à point Etablissement de clés entre deux domaines Mécanisme de base basé sur un échange symétrique : les deux entités partagent une clé secrète commune. basé sur un échange asymétrique : chaque entité a un couple (clé publique certifiée/clé privée) et la clé publique certifiée de l autre partie pour l intégrité des données ou l authentification de l origine, le destinataire a besoin du certificat de la clé publique de l expéditeur pour la confidentialité, l expéditeur a besoin du certificat de la clé publique du destinataire. Hyp : CDC (ou autorité de sécurité) par domaine. Domaine A AS entité A Domaine AS entité Si A et ont une confiance mutuelle ou si chaque entité a confiance en l AS de l autre domaine, tout se passe comme s il n y en avait qu un. Deux réalisations : asymétriques ou symétriques. runo MARTIN, Université Nice Sophia Antipolis et protocoles 25 runo MARTIN, Université Nice Sophia Antipolis et protocoles 27
Etablissement de clés entre deux domaines (asymétrique) Mécanismes de transport de clés Si les entités n ont pas de service de certification, chaque entité contacte sa propre AS pour obtenir le certificat de son correspondant. Les AS peuvent échanger les certificats des clés publiques des entités A et et les redistribuer à A et. Autre approche : certification croisée, i.e. une AS certifie les clés publiques de l autre. Publiques Procédé qui permet la mise à disposition de la clé publique d une entité à d autres entités. Principale condition à assurer : authentification de la clé qui est souvent réalisée au moyen de tiers de confiance. Si on utilise une AC, l authentification est faite au moyen du certificat de la clé publique. Secrètes Procédé qui permet de transférer une clé secrète créée ou obtenue s il s agit d un tiers de confiance par une entité à une autre entité. Réalisation par de techniques de chi rement, (a)symétriques. 18 mécanismes dans ISO/IEC 11770-2 et 3, dont 5 sont point à point, les autres utilisent des tiers de confiance comme CDC. Les di érences résident surtout dans le nombre d étapes de communication, les parties qui contrôlent les clés reçues, l authentification... runo MARTIN, Université Nice Sophia Antipolis et protocoles 28 runo MARTIN, Université Nice Sophia Antipolis et protocoles 30 Etablissement de clés entre deux domaines (symétrique) Transport de clé secrète (symétrique avec tiers de confiance) 1 Une des entités contacte son AS pour obtenir une clé de session. 2 Les deux AS établissent une clé secrète partagée utilisée par les deux entités. 3 clé distribuée par chaque AS qui utilise l autre comme centre de traduction de clé 1 ou par l intermédiaire d une des entités qui sera responsable de la transmission vers la seconde entité. Si les AS ne se font pas confiance, il faut ajouter une autorité de certification supplémentaire. Exemple : Needham-Schroeder ; suppose l existence d un tiers de confiance qui sert de serveur d authentification (AS). AS partage une clé secrète avec chaque acteur principal [3]. 1. un CTC recoit une clé chi rée d une entité, la déchi re et la rechi re en utilisant une clé partagée avec l entité de son domaine. runo MARTIN, Université Nice Sophia Antipolis et protocoles 29 runo MARTIN, Université Nice Sophia Antipolis et protocoles 31
Utilité dans Kerberos Autres modèles de distribution de clés Permettre à l utilisateur U du client C de prouver son identité à un serveur d applications sans que ces données transitent par le réseau. Requiert un tiers de confiance qui sert de centre de distribution de clé (KDC) pour le domaine ; il est composé de : serveur d auth. (AS) distributeur de tickets (TGS) qui sont sécurisés U/ C U,TGS,T,L 1 AS 2 4 6 K U (K,N,T c,tgs ) S,N,T c,tgs,a c,tgs K(T c,s,k') K'(T+1) T c,s,a c,s 5 3 serveur S TGS T c,tgs =K TGS (U,C,TGS,T,L,K) ticket TGT T c,s =K S (U,C,S,T, L,K') ticket de session A c,tgs =K(C,T) authentificateur pour T c,tgs A c,s =K'(C,T ) authentificateur pour T c,s A KDC 1 2 3 Modèle pull 2 3 A A KDC 2 1 KDC 2 1 4 Modèle push 3 3 Modèle mixte runo MARTIN, Université Nice Sophia Antipolis et protocoles 32 runo MARTIN, Université Nice Sophia Antipolis et protocoles 34 Systèmes analogues Mise à jour des clés Systèmes analogues Kryptoknight, par IM qui utilise à la fois le modèle pull et le modèle push. Sesame, projet Européen qui ajoute un serveur de privilèges. La clé une fois obtenue, on fait évoluer la clé d une session à l autre par mise à jour des clés : procédé qui permet de partager des clés construites au préalable en les faisant évoluer au moyen de paramètres de session. On définit une nouvelle clé de session K àpartir: d une clé partagée K A d un paramètre F (nombre aléa, estampille, numéro de séquence) d une fonction de calcul de clé f Fonctionnement en deux étapes : 1 l initiateur A choisit le paramètre de dérivation F et le transmet à 2 A et calculent K en utilisant la fonction de calcul f t.q. K = f (K A, F ) Exemple de fonction f : utiliser une fonction de hachage cryptographique H à la concaténation de données : K = H(K A ; F ) runo MARTIN, Université Nice Sophia Antipolis et protocoles 33 runo MARTIN, Université Nice Sophia Antipolis et protocoles 35
Protocole de mise en accord (Di e Hellman) Procédé qui permet d établir une clé partagée entre plusieurs entités de telle sorte qu aucune d entre elle ne puisse établir sa valeur par avance. On cherche donc une solution qui permette à deux entités : qui ne se sont jamais rencontrés qui ne possèdent pas d information partagée de construire une clé secrète commune connue d eux seuls inconnue de quiconque, même d un indiscret qui écouterait leurs communications. L idée Imaginer une solution facile à calculer pour les utilisateurs légaux et di cile pour un indiscret : une fonction à sens unique. Un bon candidat est le logarithme discret. runo MARTIN, Université Nice Sophia Antipolis et protocoles 36 Remède pour éviter l attaque de l homme du milieu Protocole STS Station To Station. VariantedeDi ehellman auquel on a jouté une authentification. Une autre variante est utilisée dans le protocole IPsec, intégré dans IPv6. X A En arithmétique mod q ax axa Ch K (Sign A (ax axa )) Ch K(Sign (ax axa A)) runo MARTIN, Université Nice Sophia Antipolis et protocoles 38 X Mise en accord par Di e Hellman [4] Etape préliminaire On choisit q un grand premier On choisit a, 1< a < q Les clés : Chaque utilisateur U : choisit secrètement une valeur aléatoire X U,1< X U < q et la conserve secrète ; publie Y U = a X U mod q A et construisent une clé commune avec : Y A et Y. A calcule K = Y X A mod q calcule K = Y X A mod q A et ont alors une clé (secrète) commune K : Y X A (ax ) X A a X X A Y X A mod q Identification & authentification identification procédé qui permet de vérifier l identité d une entité. authentification similaire ; permet à une entité d accéder à une ressource (comme un compte internet). L authentification ne met pas nécéssairement en jeu l identification d une entité. Elle détermine si l entité est autorisée à accomplir une certaine tâche. Principales di érences L identification requiert que le vérificateur teste l information présentée en fonction de toutes les entités connues tandis que l authentification nécessite que l information soit vérifiée par une seule entité précédemment identifiée. De plus, l identification doit, par définition, identifier de manière unique une entité, l authentification ne requiert pas l unicité. Exemple : une personne qui se connecte à un compte partagé n est pas identifiée de façon unique mais en connaissant le mot de passe partagé, elle est authentifiée comme un utilisateur du compte. runo MARTIN, Université Nice Sophia Antipolis et protocoles 37 runo MARTIN, Université Nice Sophia Antipolis et protocoles 39
Exemple d authentification «asymétrique» Sécurité de la couche de transport (TCP) msg-alea De(MD(msg-alea) Si on n utilise pas de calcul de l empreinte du msg-aléa, ce protocole peut subir des attaques (msg-aléa/de (msg-aléa)). Requiert qu Alice connaisse la clé publique de ob au préalable. Protocoles pour sécuriser TCP : Secure Socket Layer Private Communication Technology (Microsoft) Transport Layer Security standardisé par l IETF SMTP HTTP Transport Layer Security (SSL, TLS) TCP (Transmission Control Protocol) IP (Internet Protocol) runo MARTIN, Université Nice Sophia Antipolis et protocoles 40 runo MARTIN, Université Nice Sophia Antipolis et protocoles 42 Exemple d identification certifiée «asymétrique» SSL & TLS Identification avec certificat salut certif je suis ob prouve-le msg-alea De (MD(msg-alea) Envoi cle secrete Ch (CleSecrete=CS) Dialogue confidentiel Ch (msg) CS Ch (msg) CS SSL fournit authentification, compression, intégrité, chi rement. plusieurs mécanismes d authentification et de chi rement ; protège tout protocole au niveau applicatif (http,smtp) TLS repose sur SSL3.0. Deux couches : Rencontre ou Handshake Protocol Communication ou Record Protocol qui fournissent les services suivants : confidentialité de la connexion par DES, IDEA, RC2, RC4 intégrité de la connexion par un MAC utilisant une clé en valeur initiale (SHA-1 ou MD5) runo MARTIN, Université Nice Sophia Antipolis et protocoles 41 runo MARTIN, Université Nice Sophia Antipolis et protocoles 43
Identification handshake Authentification handshake C est le moyen pour Alice de vérifier l identité de ob. pk la clé publique de ob et sk sa clé privée. A æ æ A r = un message aléatoire c = {r} sk Signer un message aléatoire r fourni par un tiers et le réexpédier peut s avérer dangereux. Une idée serait d utiliser une fonction de hachage h afin que ob signe en chi rant h(r). Mais le danger persiste. Alice n a pas forcément déjà connaissance de la clé publique de ob. Comment informer sûrement quelqu un de sa clé publique? A æ æ A A æ æ A "onjour" "onjour, je suis ob. Voici ma clé publique" pk "Prouve-le." m = "Alice, c est bien ob" c = {h(m)} sk N importe qui peut se faire passer pour ob aux yeux d Alice, en donnant sa propre clé publique, correspondant à sa clé secrète. runo MARTIN, Université Nice Sophia Antipolis et protocoles 44 runo MARTIN, Université Nice Sophia Antipolis et protocoles 46 Identification handshake Transmettre un certificat handshake Certificat garantit la relation entre une identité et clé publique. Mieux vaut que ob signe un message de son cru A æ "onjour, est-ce ob?" æ A m = "Alice, je suis bien ob" c = {h(m)} sk A æ æ A A æ æ A "onjour" "onjour, je suis ob. Voici mon certificat" cert "Prouve-le." m = "Alice, c est bien ob" c = {h(m)} sk Eve pourrait se substituer à ob dans les trois premiers échanges, mais échouera à répondre au delà. runo MARTIN, Université Nice Sophia Antipolis et protocoles 45 runo MARTIN, Université Nice Sophia Antipolis et protocoles 47
Echanger un secret handshake SSL handshake La communication par clés publiques est coûteuse, une fois finie la phase d identification, on s échange une clé pour utiliser un chi re àclésecrètesymétrique. A æ "onjour" æ A "onjour, je suis ob. Voici mon certificat" cert A æ "Prouve-le". æ A m = "Alice, c est bien ob" c = {h(m)} sk A æ "Ok ob, voici notre secret :" s = {secret} pk æ A m Õ = {message de ob} secret Pour éviter cette incertitude, mieux vaut utiliser un MAC : M = h(un message de ob, secret) A æ "onjour" æ A "onjour, je suis ob. Voici mon certificat" cert A æ "Prouve-le". æ A m = "Alice, c est bien ob" c = {h(m)} sk A æ "Ok ob, voici notre secret :" s = {secret} pk æ A m Õ = {message de ob} secret M = h(message de ob, secret) Melchior peut pertuber ce qu il veut, M aura au moins l avantage d en avertir le destinataire. runo MARTIN, Université Nice Sophia Antipolis et protocoles 48 runo MARTIN, Université Nice Sophia Antipolis et protocoles 50 Attaque MIM La communication record L homme du milieu Melchior peut s interposer dans les 5 premiers échanges. Arrivé au sixième, il peut brouiller le message de ob, quitte à ne pas envoyer un message très intelligible à Alice : æ M M æ A m Õ = {message de ob} secret altération de m Õ Alice n a aucune certitude quant à l existence de Melchior, même si elle trouve suspect le dernier message de ob. Ce protocole transmet un message de taille arbitraire. Il le découpe en blocs, le comprime éventuellement, ajoute un MAC, chi re et transmet le résultat en ajoutant un numéro de séquence pour détecter s il manque des messages ou si certains ont été altérés. Il assure : confidentialité des données transmises par l application intégrité des données authentification de l origine Une fois le record protocol achevé, les données chi rées sont fournies à TCP. runo MARTIN, Université Nice Sophia Antipolis et protocoles 49 runo MARTIN, Université Nice Sophia Antipolis et protocoles 51