Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre II : Les protocoles de sécurité LAN et Internet 1 LE CRYPTAGE A CLE PU

Chapitre II : Les protocoles de sécurité LAN et Internet 1 LE CRYPTAGE A CLE PUBLIQUE 1.1 Principe général Dans les différents protocoles de tunneling qui vont être présentés, est utilisé le principe de cryptage par clé publique. Le fonctionnement (dans les grandes lignes) est le suivant ; une personne par un algorithme de codage, met au point deux clés de chiffrement. Une qu’il appelle clé publique, et l’autre clé privée. En principe tout ce qui est encrypté avec la clé publique, peut être décrypté uniquement si l’on détient la clé privée. Les noms de ces deux clés, expriment bien ce que sont ces clés, l’une est celle que le site va communiquer à tous ceux désirants se connecter à lui, et l’autre celle gardée précieusement secrète afin de garantir que seul le serveur peut décripter un message encrypter avec sa clé publique. Ainsi le principe veut que lorsque l’on se connecte à un serveur par exemple, ce dernier transmet sa clé publique au client, qui s’en sert pour encrypté la clé symétrique (clé unique permettant d’encrypter et de décrypter un message) qu’il désire utiliser, et envoie cela au serveur. Le serveur reçoit ce paquet, le décrypte par le biais de sa clé privée, et découvre ainsi quelle clé symétrique va être employée par la suite pour encrypter et décrypter tous les messages échangés. Cela est un exemple, car il existe d’autre cas de figures, ainsi qu’une importante phase de négociation lors de l’établissement de la connexion, sur le type de chiffrage appliquer, et quel algorithme choisir. En résumé, cela donne sous forme de diagramme fléché: • Envoi de la clé publique. • Info cryptée avec la clé publique, éventuellement clé symétrique. • Décryptage des infos avec la clé privée. • Echange de messages cryptés. 1.2 Phase initiale de négociation La phase d’ouverture de connexion, est très importante. En effet, c’est à ce moment que les deux partenaires se découvrent, et constate quels algorithmes implémente l’autre. Ainsi qu’une autre phase cruciale, qui est l’authentification. En effet jusqu’à présent il a été question de transmettre de manière cryptée des informations, mais qui ou quoi, peut garantir qu’à l’autre extrémité de la connexion, est effectivement présent la personne à qui le message est destiné. Ces divers aspects vont être abordés dans les chapitres suivant au travers de l’analyse des protocoles implémentant les tunnels. 2 SSL 2.1 Présentation de SSL SSL ou, Secure Socket Layer, permet l'accès sécurisé à un site web ou à certaines pages d'un site web. Ces connexions se différencient par des connexions "normales" c'est à dire non sécurisées, par le fait que l'adresse n'est plus "http:// " mais "https:// ", où le s indique sécurisé. Il y a deux manières de vérifier si le site visité est sécurisé ; d'une part en essayant de s'y connecter avec l'adresse https qui dans le cas où le site dispose d'une connexion sécurisée permettrait la connexion avec le site. Et d'autre part en vérifiant si le cadenas figurant à droite de la barre d'état d'un navigateur est fermé. Figure 2.1-1 Cadenas non-verrouillé et verrouillé SSL v3.0 est devenu un standard "de facto", sur Internet, et comme tous les standards de fait, souffre ou risque de souffrir, de diverses petites adaptations ici et là, provoquant à terme, le risque d'une compatibilité réduite. Il faut également noter que Netscape qui à développer le produit, fournit des références de manière publique, et à développer SSL avec de nombreux partenaires afin d'obtenir une large reconnaissance, et cela a été le cas. Il est a souligner que ce qui a principalement motivé Netscape, c’est le commerce électronique. Mais afin que SSL devienne une "norme", c'est l'IETF, qui se charge actuellement d'en définir les critères. Et plus précisément le groupe de travail "TLS" Transport Layer Security, raison pour laquelle l'on trouve les informations concernant SSL sous le sigle TLS, qui revêt la forme de SSL v.3.1. Ce qui concerne la version TLS 1.0 se trouve dans la RFC 2246. SSL est très largement adopté par les messageries existantes comme: Qualcomm Eudora 5.1r, Microsoft Outlook, entre autre, toutes supportent les connexions SSL sur leurs serveurs. SSL se situe au sommet de la couche TCP/IP, et au-dessous de la couche d'application. Pour mettre en place une connexion SSL, il faut d'abord établir une connexion TCP/IP, car SSL utilise certaines "primitives" de TCP/IP. Ainsi SSL peut être vu comme un canal sûr au sein de TCP/IP, où tout le trafic entre deux applications "peer to peer" est échangé de manière cryptée. Tous les appels de la couche d'application à la couche TCP, sont remplacés par des appels de l'application à SSL, et c'est SSL qui se charge des communications avec TCP. Figure 2.1-2 SSL selon le modèle OSI 5.2 Les trois fonctionnalités de SSL SSL a trois fonctions: · Authentification du serveur Qui permet à un utilisateur d'avoir une confirmation de l'identité du serveur. Cela est fait par les méthodes de chiffrement à clés publiques qu'utilise SSL. Cette opération est importante, car le client doit pouvoir être certain de l'identité de son interlocuteur à qui par exemple, il va communiquer son numéro de carte de crédit. · Authentification du client Selon les mêmes modalités que pour le serveur, il s'agit de s'assurer que le client est bien celui qu'il prétend. · Chiffrement des données Toutes les données qui transitent entre l'émetteur et le destinataire, sont chiffrées par l'émetteur, et déchiffrées par le destinataire, ce qui permet de garantir la confidentialité des données, ainsi que leur intégrité grâce souvent à des mécanismes également mis en place dans ce sens. 5.3 Le principe de fonctionnement SSL est un protocole qui utilise différents algorithmes de cryptographie afin de garantir "la sécurité", au travers de l'authentification avec des certificats, des sessions d'échanges des clés d'algorithmes, de l'encryptage, et de la vérification de l'intégrité des données. Le cryptage SSL, fonctionne par le choix aléatoire de deux nombres premiers, qui multipliés entre eux forment un très grand nombre. Ce dernier constitue la clé de cryptage. Sans la connaissance des deux nombres premiers ayant servis à générer cette clé, il n'est pas possible de pouvoir décrypter un message. En réalité une manière possible serait de défactoriser le nombre afin de retrouver les deux nombres premiers, mais les nombres sont tellement grands, que cela n'est pas à la portée d'ordinateurs conventionnels. Il est à relever que déjà à partir de sa version 2.0, SSL a commencé à être utilisé. Raison pour laquelle encore aujourd’hui, la plupart des intervenants SSL, tentent lors de la phase d’établissement, de dialoguer avec le protocole v3.0, mais si l’un des deux partenaires ne supporte que la version 2.0, et bien c’est cette version antérieur qui va être utilisée. A noter que cette ancienne version contient des clés de cryptage considérées aujourd’hui comme peu sûres. (Par exemple au niveau de la longueur de la clé, il y a un passage de 40 à 128 bits et plus, pour la version v3.0). 5.4 Composition de SSL SSL se subdivise en quatre sous protocoles; le SSL record Protocol, et le SSL handshake protocol. Plus deux autres protocoles, mais qui ont un rôle moins essentiel, c’est le SSL Change Ciffer Spec, et le SSL Alert. Le SSL record protocol définit le format qui sera utilisé pour l'échange des données. Alors que le SSL handshake se charge des différents échanges de messages entre le client et le serveur, au moment où ils établissent la connexion comme l’authentification, le version de protocole, l’algorithme de cryptage, … 5.5 Le fonctionnement de SSL 5.5.1 Vue d'ensemble Couche application données SSL Handshake Gestion de SSL Couche présentation données SSL Record Couche session chiffrées Couche transport Couche réseau Couche liaison Couche physique Figure 5.5-1 Les couches OSI et les protocoles SSL La Figure 5.5-1 explicite comment intervient le protocole SSL, en comparaison au modèle de couches OSI. A noter que toutes les couches ont été représentées, mais cela ne veut pas dire que toutes sont implémentées de la même manière, cela notamment pour les applications qui s'apparentent au modèle DOD. 5.5.2 Phases d’authentification Lorsqu’il s’agit pour un serveur d’identifier un client, quatre phases se suivent : 1. Vérification de la validité de la date du certificat. 2. Le certificat est-il issu d’une CA (Certification Autority) reconnue. 3. Est-ce que la clé public attribuée à l’utilisateur valide sa signature. 4. Vérification des noms de domaines. Pour la situation inverse, lorsque c’est le serveur qui désire vérifier l’identité du client : 1. Vérification de si la clé publique du client authentifie sa signature. 2. Vérification de la date de validité du certificat.. 3. Vérification de l’entité qui à remis le certificat. 4. Est-ce que la clé publique du CA valide la signature de l’utilisateur. 5. Vérification du fait que l’utilisateur fait partie d’une LDAP. 5.5.3 SSL Handshake Cela débute par le protocole SSL Handshake. Suite à la requête d'un client, le serveur envoie son certificat, ainsi qu'une liste des algorithmes qu'il souhaite utiliser. Pour le client il s'agit de vérifier la validité du certificat. Cela se uploads/Litterature/chap-ii-protocoles-securisees.pdf