|
Etude des protocoles de sécurité dans le réseau internet( Télécharger le fichier original )par Fils NZALANKUMBU DIALEMBA Institut supérieur de techniques appliquées Kinshasa - Ingénieur en informatique appliquée 2007 |
I.2.2. Authentification et l'identificationLe service d'authentification permet d'assurer qu'une communication est authentique. On peut distinguer deux types d'authentification : l'authentification d'un tiers et l'authentification de la source des données. L'authentification d'un tiers consiste pour ce dernier a prouver son identité. L'authentification de la source des données sert a prouver que les données reçues viennent bien d'un tel émetteur déclaré. Les signatures numériques peuvent aussi servir a l'authentification. La signature numérique sera abordée dans la section Intégrité. L'authentification nécessite de fournir une identification et de la prouver. Sur la plupart des réseaux, le mécanisme d'authentification utilise une paire code d'identification/mot de passe. Cependant, en raison de la vulnérabilité constamment associée a l'utilisation des mots de passe, il est souvent recommandé de recourir à des mécanismes plus robustes tels que l'authentification par des certificats, des clés publiques ou à travers des centres de distribution des clés. I.2.3. IntégritéL'intégrité se rapporte a la protection contre les changements et les altérations. Il y a une intégrité si les données émises sont identiques à celles reçues. Des différences peuvent apparaître si quelqu'un tente de modifier ces données ou tout simplement si un problème de transmission/réception intervient. Les techniques utilisées pour faire face à cela sont, les bits de parité, les checksums ou encore les fonctions de hachage à sens unique. Ces mécanismes ne peuvent cependant pas garantir absolument l'intégrité. Il est possible en effet, que les données altérées aient la même somme de contrôle. Il est aussi possible qu'un attaquant modifie les données et recalcule le résultat de la fonction de hachage (empreinte). Pour que seul l'expéditeur soit capable de modifier l'empreinte, on utilise des fonctions de hachage à clés secrètes ou privées. Dans ce cas, on garantit à la fois l'intégrité et l'authentification. Ces deux services de sécurité sont souvent fournis par les mêmes mécanismes pour la simple raison qu'ils n'ont de sens qu'accompagnés l'un de l'autre (dans le contexte d'un réseau peu sûr). I.2.4. ConfidentialitéLa confidentialité est un service de sécurité qui consiste à assurer que seules les personnes autorisées peuvent prendre connaissance des données. Pour obtenir ce service, on utilise généralement le chiffrement des données concernées à l'aide d'un algorithme cryptographique. Si seules les données sont chiffrées, une oreille espionne peut tout de même écouter les informations de l'en-tête. Elle peut ainsi, à partir des adresses source et destination, identifier les tiers communicants et analyser leur communication : fréquence des envois, quantité de données échangée, etc. On parle de protection contre l'analyse de trafic lorsqu'en plus de la confidentialité, on garantit l'impossibilité de connaître ces informations. L'authentification, l'intégrité et la confidentialité vont souvent ensemble et offrent la base des services de sécurité. I.2.5. Non répudiationLa non répudiation empêche tant l'expéditeur que le destinataire de nier avoir transmis un message. On dénombre deux types de service de non répudiation : 1' La non répudiation de l'origine qui protège un destinataire confronté a un expéditeur niant avoir envoyé le message ; 1' La non répudiation de la réception qui joue le rôle inverse du précédent, à savoir démontré que le destinataire a bien reçu le message que l'expéditeur lui a envoyé. Dans le cadre de la cryptographie à clé publique, chaque utilisateur est le seul et unique détenteur de la clé privée. Ainsi, tout message accompagné par la signature électronique d'un utilisateur ne pourra pas être répudié par celui-ci, à moins que tout le système de sécurité n'ait été pénétré. A l'opposé, la non répudiation n'est pas directement acquise dans les systèmes utilisant des clés secrètes. La clé de chiffrement étant distribuée par le serveur de distribution de clés aux deux parties, un utilisateur peut nier avoir envoyé le message en question en alléguant que la clé secrète partagée a été divulguée soit par une compromission du destinataire, soit par une attaque réussie contre le serveur de distribution de clés. La non répudiation de la réception peut se faire en obligeant le destinataire à envoyer un accusé de réception signé et horodaté. I.2.6. Protection contre les attaques actives et passivesLa catégorie principale d'attaques sur les protocoles de sécurité est l'attaque active. Cette attaque implique certaines modifications du flot de données ou la création d'un flot frauduleux. On remarque principalement dans cette catégorie les attaques suivantes : 1' L'homme du milieu : cette attaque a lieu lorsqu'une entité prétend être une autre entité. Dans la plupart du temps, l'attaquant utilise les techniques de détournement de flux pour rediriger les flux des deux bouts de la communication vers lui. Ceci, afin de surveiller tout leur trafic réseau et de le modifier à sa guise pour l'obtention de tout type d'information ; 1' Le rejeu des paquets : le rejet implique la capture passive de données et leur retransmission ultérieure en vue de produire un effet non autorisé. Pour empêcher tel type d'attaques, on utilise souvent les nombres aléatoires dans les messages envoyés ; 1' La modification des messages : ceci signifie que certaines portions d'un message légitime sont altérés ou que les messages sont retardés ou réorganisés. Ce type d'attaques est souvent utilisé avec les protocoles qui sont basés sur le protocole de transport UDP (comme le cas du protocole ISAKMP) ; 1' Le déni de service : cette attaque porte bien son nom puisque qu'elle aboutira a l'indisponibilité du service (saturation des ressources allouées a une application spécifique), de la machine visée ou même la saturation d'un réseau complet. Cette attaque vise surtout l'exploitation d'une mauvaise implémentation d'un protocole ou a des faiblesses de celui-ci. Pour les protocoles de sécurité, le déni de service peut prendre deux formes : > La première forme vise la vulnérabilité des protocoles de transport qu'ils utilisent tels que les attaques sur le protocole IP (IP Spoofing), le protocole TCP (SYN Flooding) et le protocole UDP (UDP Flooding, Packet Fragment) ; > La deuxième forme porte surtout sur la phase d'initialisation de ces protocoles (le protocole IKE, le Handshake de SSL/TLS, etc.). Une deuxième catégorie d'attaques est l'attaque passive. Cette catégorie est souvent plus difficile à détecter car elle ne cause aucune altération des données. Le but de l'adversaire est de collecter les informations qui ont été transmises (adresse IP, port, services, environnement, etc.) afin d'analyser leur contenus et de mener par la suite des attaques actives. I.2.7. Protection d'identitéLa vérification efficace des événements liés à la sécurité se fonde aussi sur la capacité d'identifier chaque utilisateur. Il est très important que chaque utilisateur de l'Internet ait une identité distincte. L'identité distincte de l'utilisateur est une combinaison qui donne le nom de l'utilisateur et possiblement celui de son ordinateur, de son organisation et de son pays. Dans la plupart des cas, l'identité du récepteur (généralement un serveur) est publique. Pour cela, un protocole de sécurité doit surtout protéger l'identité de l'initiateur (généralement les clients). La protection d'échanges ou la protection du réseau Par rapport aux couches OSI, les protocoles et services de sécurité sont insérés à divers emplacements de la pile de communication. Le choix de l'emplacement dépend des exigences en matière de sécurité, c'est-à-dire les menaces qui peuvent être rencontrées. Chaque emplacement offre des avantages et des inconvénients. Le chiffrement au milieu de la pile de communication, offre un service de chiffrement indépendant des applications et il est transparent pour celles-ci. Les données encapsulées provenant des couches supérieures sont chiffrées et la confidentialité des en-têtes des protocoles des couches supérieures (transport, présentation ou TCP) est protégée. Toutefois, le chiffrement au niveau applicatif préserve la possibilité de transmettre des données par l'intermédiaire de relais multiples afin d'atteindre la destination. Cette méthode s'avère efficace pour le codage d'autres types de données propres à des applications qui résident sur un site ou qui sont transmises sur un réseau. Comme le chiffrement et le déchiffrement sont réalisés a chaque extrémité d'un trajet de communication, on peut parler alors d'une protection de bout en bout. Le tableau I.2 illustre les Protocoles par rapport au modèle de référence OSI. Tableau I.2. Protocoles par rapport au modèle de référence OSI.
I.2.8. Confiance entre les communicateursLa confiance entre les tiers est une exigence fondamentale de toute implantation à grande échelle de services de sécurité reposant sur la cryptographie à clé publique. Toutefois, dans un réseau de grande taille, il est impossible et irréaliste de s'attendre à ce que chaque utilisateur établisse au préalable des relations avec tous les autres utilisateurs. En outre, comme la clé publique d'un utilisateur doit être accessible à l'ensemble des autres utilisateurs, le lien entre une clé publique et une personne donnée doit être garanti par une tierce partie de confiance, afin que nul ne puisse se faire passer pour un utilisateur légitime. Une tierce partie de confiance, dont les mécanismes sont sûrs, permet aux utilisateurs d'avoir implicitement confiance dans toute clé publique certifiée par cette tierce partie que nous appelons Infrastructure à Clé Publique (ICP) ou même PKI pour Public Key Infrastructure. L'agent ICP qui certifie les clés publiques des utilisateurs est appelé Autorité de Certification (AC). Les ACs s'occupent de la diffusion de ces clés publiques (ainsi que l'identificateur de l'utilisateur) sous forme de « certificats » sur des annuaires électroniques publics. Le format de certificat le plus utilisé dans le cadre d'une ICP est le standard normalisé X.509v3. Malheureusement, la prolifération des « extensions » dans ces certificats a induit d'autres problèmes dans les domaines d'interopérabilité, de juridiction et de révocation. Une solution apparaît appropriée est de partager un certificat X.509 en deux : un certificat d'identité qui va porter des informations sur l'identité et un certificat d'attribut qui va porter des informations sur les rôles attribués à cette identité. Cette solution simplifie énormément le processus d'émission des certificats et peut dans certaines situations éliminer le problème de la révocation. Le certificat d'attributs X.509 est une solution orientée vers les services d'authentification (par exemple : le contrôle d'accès). Son point faible est la complexité à déployer les certificats d'attribut. Une part de cette complexité est attribuable a l'encodage des certificats X.509 en format ASN.1 (Abstract Syntax Notation) et a l'intégration difficile de nouveaux attributs. La figure I.1 représente les relations qui peuvent lier un certificat d'identité a un certificat d'attribut. Les deux certificats peuvent être liés à travers plusieurs champs tels que la clé publique, le numéro de série.
Fig. I.1. Relation entre Certificat d'identité et Certificat d'attribue I.2.9. L'autorisation 3 Le service d'autorisation a comme rôle d'empêcher la divulgation non autorisée de l'information ou des données en contrôlant l'accès à celles-ci. Pour cela, il repose sur l'identification et l'authentification des utilisateurs, sans quoi elles sont inefficaces. La plupart des protocoles de sécurité offrent une telle fonction, habituellement sous forme d'une liste de contrôle d'accès (LCA). Les listes LCA énumèrent les personnes, les groupes de personnes ou les processus qui sont autorisés à accéder à certains fichiers ou répertoires. Pour cela et afin d'assurer la confidentialité de l'information, la mise en oeuvre des LCAs nécessite une gestion attentive et précise. Une méthode pour rendre ce service plus dynamique serait d'utiliser des certificats de rôles ou ce qu'on appelle des certificats d'attribut. Ces deniers ne nécessitent pas une protection physique puisqu'ils sont générés pour une durée de vie très courte. I.2.10. Gestion des clés Pour être efficace, tout système de chiffrement doit reposer sur des méthodes fiables et robustes pour la gestion des clés. Une bonne gestion des clés comprend la production de clés de chiffrement qui ont des propriétés particulières, la distribution des clés aux utilisateurs ou aux systèmes appropriés, la protection des clés contre leur divulgation, la modification et (ou) la substitution des clés, ainsi que leur distribution, ce qui peut comprendre l'archivage. Lorsque l'on décide d'utiliser les technologies de chiffrement dans un réseau, il est crucial d'instaurer un système approprié de gestion des clés afin d'épauler le chiffrement. En effet, un système de chiffrement ne vaut rien si la sécurité des clés n'est pas assurée. En plus, pour assurer la sécurité à long terme des transactions, les clés doivent être renégociées d'une manière totalement indépendante des anciennes clés utilisées. Ce service s'appelle le service de PFS (ou Perfect Forward Secrecy). Bien que ce service soit coûteux en termes d'opérations cryptographiques (la génération des nouveaux clés Diffie-Hellman prend 100 ms, il reste important pour assurer la sûreté cryptographique des clés. Ainsi, il peut être utilisé optionnellement par les entités communicantes. I.2.11. Mise en oeuvre d'un VPNLe VPN est un réseau privé construit a l'intérieur d'un réseau public, comme Internet. Il permet donc de remplacer les traditionnels réseaux de lignes louées par de simples accès a l'Internet global avec le moindre coût. Ces VPNs n'ont pas comme seul intérêt l'extension des WAN (Wide Area Network) a moindre coût mais aussi l'utilisation de services ou fonctions spécifiques assurant la qualité de service (QoS) et la sécurité des échanges. Les fonctionnalités de sécurité sont matures mais la réservation de bandes passantes pour les tunnels est encore un service en développement limité par le concept même d'Internet. La sécurité des échanges est assurée à plusieurs niveaux de la couche OSI et par différentes fonctions comme le cryptage des données, l'authentification des deux extrémités communicantes et le contrôle d'accès des utilisateurs aux ressources. Les VPNs peuvent être créés suivant différentes formes, soit pour connecter deux réseaux locaux distants (connexion network-to-network), soit entre deux stations (hop-tohop) soit entre une station et un réseau (hop-to-network). Ce dernier est généralement utilisé par des entreprises désireuses de créer des accès distants pour des télétravailleurs via Internet. I.2.12. Contrôle d'accèsLa nomade des utilisateurs et la demande d'accès distant sécurisé vers les réseaux privés des entreprises ont poussé ces dernières à adapter des solutions de sécurité basées sur des points d'accès situés aux frontières des réseaux privés. Ces points d'accès sont également intéressants dans le sens où ils constituent un point unique oü l'audit et la sécurité peuvent être imposés. Ils peuvent donner des résumés de trafic, des statistiques sur ce trafic, ou encore toutes les connexions entre les deux réseaux. Dans ce domaine, nous citons les deux techniques suivantes : I.2.12.1. FirewallsUn Firewall (pare-feu) est un système ou un groupe de systèmes qui gère et représente une politique de contrôle d'accès définie par les administrateurs réseaux. Un Firewall se situe toujours sur le lien unique (ou en tous cas sur un lien de passage du trafic) qui relie un réseau privé (Intranet) au reste du monde (Internet) afin de pouvoir filtrer tout le trafic sortant et rentrant. Généralement, les Firewalls sont configurés pour protéger contre les accès non authentifiés du réseau externe. Ils assurent, entre autres, une fonction de filtrage à différents niveaux de la couche OSI et empêchent les intrus de se loger sur des machines du réseau interne. Pour filtrer les paquets, on peut regarder les protocoles de niveau supérieur, ou bien regarder les données transportées ou vérifier qu'elles ne contiennent pas de virus, ou ne contiennent pas tel ou tel mot par exemple. Voici un schéma illustrant une architecture classique de sécurité utilisant un Firewall :
Fig. I.2. Architecture classique de sécurité utilisant un Firewall Un Firewall peut être précédé d'un routeur particulier qui assure que les paquets entrants sont exclusivement à destination du Firewall. Un routeur peut également donner accès à un sous réseau dénommé DMZ (zone démilitarisée) dans laquelle réside les serveurs publics de l'entreprise. La DMZ est une zone protégée vis-à-vis de l'extérieure comme de l'intérieur. Cependant, ce système de Firewall est insuffisant s'il n'est pas accompagné d'autres protections. En effet, il ne fournit pas les services de sécurité énoncés précédemment (authentification de la source des données, intégrité, confidentialité, etc.). Plusieurs types d'attaques passives et actives ne sont pas protégeables (analyse de trafic, IP Spoofing, IP Flooding, etc.) ou encore les failles de configuration par des outils d'analyse automatique des vulnérabilités du système. I.2.12.2. Proxy et les Reverse ProxyLes Proxy permettent d'une part, de relayer le trafic entre Internet et un réseau protégé et d'autre part, ils effectuent un enregistrement intermédiaire de données à des points définis d'Internet. La meilleure utilisation de cette technique est apparue avec les serveurs Web. Avec sa technique de cache, un Proxy permet de recevoir les pages Web plus rapidement car celles-ci sont directement activées depuis un Proxy proche de l'émetteur de la requête HTTP. Le Reverse Proxy est un mécanisme de contrôle d'accès récemment apparu. Si le Proxy est un mécanisme de filtrage des connexions sortantes d'une entreprise, le Reverse Proxy est le mécanisme inverse qui permet de filtrer toutes les connexions des utilisateurs vers un ensemble d'applications. Un serveur Reverse Proxy permet la réalisation des VPNs au niveau applicatif tout en se basant sur un protocole de sécurité comme SSL/TLS ou SSH. La figure I.3 illustre l'Architecture des Proxy et des reverse Proxy.
Fig. I.3. Architecture des Proxy et des reverse Proxy Actuellement les protocoles de sécurité sont plus adaptés à ces deux mécanismes largement déployés dans les réseaux des entreprises. Nous pouvons citer dans ce domaine l'utilisation conjointe du protocole IPSec avec les Firewalls et l'utilisation du protocole SSL/TLS avec les Reverse Proxy. Ils permettent ainsi de fournir des mécanismes plus robustes pour l'authentification et le contrôle d'accès des utilisateurs externes avant de pouvoir accéder au réseau interne de l'entreprise. I.2.13. Gestion des «délégations» entre acteurs Les points d'accès jouent le rôle d'un point d'authentification pour les utilisateurs qui se connectent au réseau interne des entreprises. Les solutions de sécurité telles que SSL/TLS et SSH essaient de s'adapter a ce type de connexion en présentant les entités intermédiaires comme des entités de confiance et en faisant un double tunnel de sécurité pour assurer une sécurité de bout en bout des données. Cependant, la problématique d'une telle approche vient du fait que dans des scénarios où une application finale A souhaite déléguer le rôle d'authentification a une autre entité B. Cette dernière doit présenter un certificat de délégation d'un rôle d'authentification émis par l'application A ou par une infrastructure de gestion des privilèges. Pour cela, nous proposons l'utilisation d'un mécanisme de délégation des droits basé sur les infrastructures de gestion des privilèges et les certificats d'attribut. Par délégation, nous entendons dire l'autorisation donnée par une entité finale A (normalement le serveur destinataire) à une entité intermédiaire B pour pouvoir exercer un mécanisme d'authentification et de contrôle d'accès a sa place. Un tel mécanisme permet d'offrir a l'utilisateur une preuve de l'identité et des rôles associés a l'entité intermédiaire B. Notons ainsi que, dans le cas ou les passerelles sont éloignées des serveurs origines (cas de distribution de contenu dans Internet), la délégation du rôle d'authentification aux différentes passerelles peut jouer un rôle important pour la minimisation des bandes passantes vers le serveur Web d'application. La vérification formelle des protocoles de sécurité Au cours des dernières années, différents protocoles cryptographiques ont été mis en oeuvre pour répondre aux exigences demandées, mais la difficulté de la conception de ces protocoles vient du fait que les messages échangés peuvent être écoutés par une tierce personne, interceptés ou modifiés. Afin d'assurer que ces protocoles soient protégés contre des attaques pareilles, un nouveau domaine de sécurité est apparu. C'est la modélisation et la vérification des protocoles cryptographiques. L'extensibilité du protocole, un protocole est dit extensible s'il permet de fournir des nouveaux services sans avoir à changer sa structure de conception. Le grand intérêt de cette option a poussé les nouveaux successeurs des protocoles de sécurité (comme TLS Extensions) et des protocoles d'échange des clés (comme IKEv2) a ajouter des échanges ou des messages génériques dans leur phase d'initialisation. Ces messages permettent à ces protocoles de négocier durant leurs phases d'initialisation, des nouveaux services tels que l'URL des certificats et les HMAC tronqués. Ces messages sont dans la plupart des cas, déclenchés du coté de l'émetteur qui propose la négociation d'un ou de plusieurs services optionnels. Ceci permet de garder une interopérabilité entre les entités qui supportent ces services et celles qui ne les supportent pas. La Figure I.4 illustre l'Exemple de délégation entre un serveur d'application et une passerelle.
Fig. I.4. Exemple de délégation entre un serveur d'application et une passerelle I.3. CONCLUSION Dans ce chapitre, nous avons défini les principales exigences qu'un protocole de sécurité doit assurer. Ces exigences sont nécessaires pour de nombreuses applications telles que le commerce électronique, l'accès distant a une machine ou a certaines parties d'un site contenant des informations confidentielles. En se basant sur ces exigences, nous allons comparer dans le chapitre suivant, les trois principales solutions de sécurité suivantes : IPSec, SSH et SSL/TLS. CHAPITRE II. TECHNOLOGIES ET SERVICES POUR
LA
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Les caractéristiques des dispositifs de connectivité |
|||||
|
Répéteur |
Pont |
Routeur |
Pont |
Passerelles |
|
|
Régénération |
OUI |
OUI |
OUI |
OUI |
OUI |
|
Prolonger |
OUI |
OUI |
OUI |
OUI |
OUI |
|
Les noeuds |
OUI |
OUI |
OUI |
OUI |
OUI |
|
Les supports |
Multi câbles |
Multi |
Multi |
Multi |
Multi |
|
Multi ports |
Concentrateur |
OUI |
OUI |
OUI |
OUI |
|
Broadcast |
OUI |
OUI |
NON |
OUI et |
NON |
|
Filtrer |
NON |
OUI |
OUI |
OUI |
OUI |
|
Router |
NON |
NON |
OUI |
NON et |
OUI |
|
Traduire |
NON |
NON |
OUI |
OUI |
OUI |
|
Couche OSI |
1. Physique |
2. Liaison |
3. Réseau |
2 et 3 |
1 à 7 |
|
Chemins |
Un seul |
Un seul |
Plusieurs |
Plusieurs |
Plusieurs |
|
Adresses |
@ MAC |
@ Réseau |
|||
|
Méthode d'accès |
La même |
La même |
CSMA/CD |
Plusieurs |
|
|
Protocoles |
Un seul |
Un seul |
Routables |
Plusieurs |
|
|
Architecture réseaux |
La même |
La même |
Ethernet |
Spécifiques |
|
|
Topologie |
Bus |
Dorsale |
Maillage |
Maillage |
Maillage |
|
Utilisation |
Rallonger |
Rallonger |
Optimiser |
Simplifier |
Traduire |
II.3. MISE EN PLACE D'UN SERVEUR PROXY II.3.1. Consideration
Un serveur proxy est à l'origine d'une machine faisant fonction d'intermédiaire entre les ordinateurs d'un réseau local et Internet.
La plupart du temps le serveur proxy est utilisé pour le web, il s'agit donc d'un proxy HTTP, toutefois il peut exister des serveurs proxy pour chaque protocole applicatif (FTP, etc.).
Le principe de fonctionnement basique d'un serveur proxy est assez simple, il s'agit d'un serveur «mandaté» par une application pour effectuer une requête sur Internet à sa place. Ainsi, lorsqu'un utilisateur se connecte à Internet à l'aide d'une application cliente configurée pour utiliser un serveur proxy, celle-ci va se connecter en premier lieu au serveur proxy et lui donner sa requête. Le serveur proxy va alors se connecter au serveur que l'application cliente cherche à joindre et lui transmettre la requête. Le serveur va ensuite donner sa réponse au proxy, qui va à son la transmettre tour à l'application cliente.
Désormais, avec l'utilisation de TCP/IP au sein des réseaux locaux, le rôle de relais du serveur proxy est directement assuré par les passerelles et les routeurs. Pour autant, les serveurs proxy sont toujours d'actualité grâce à certaines autres fonctionnalités.
D'autre part, grâce à l'utilisation d'un proxy on assure un suivi des connexions (En anglais tracking) via la constitution de fourneaux d'activité (Logs) on enregistre systématiquement les requêtes des utilisateurs lors de leurs demandes de connexion à Internet. Il est ainsi possible de filtrer les connexions à Internet en analysant d'une part les requêtes des clients, d'autre part les réponses des serveurs. Lorsque le filtrage est réalisé en comparant la requête du client à une liste de requête réalisé, on parle d'une liste blanche, lorsqu'il s'agit d'une liste des sites interdits on parle de liste noire. Enfin l'analyse des réponses des serveurs conformément à une liste de critères est appelé filtrage de contenu.
Dans la mesure où le proxy est l'intermédiaire indispensable des utilisateurs du réseau interne pour accéder à des ressources externes, il est parfois possible de l'utiliser pour authentifier les utilisateurs, c'est-à-dire de leur demander de s'identifier à l'aide d'un nom d'utilisateur et d'un mot de passe par exemple. Il est ainsi aisé de donner l'accès aux ressources externes aux seules personnes autorisées à le faire et de pouvoir enregistrer dans les fichiers journaux des accès identifiés.
Les caches web ont été créés pour remédier en partie au problème de surcharge des serveurs web et de congestion des réseaux Internet. Ces caches stockent les documents demandés récemment par les utilisateurs afin de réduire le chemin à parcourir pour récupérer à nouveau ces documents lors d'une prochaine demande. Leur utilisation permet donc de réduire le trafic a travers l'Internet et ainsi d'améliorer le temps de réponse au client. Mais ces caches n'ont pas encore atteint un niveau de performance satisfaisant, et connaissent quelques défauts d'organisation. Un même document est dupliqué sur plusieurs sites, ce qui pose inévitablement le problème de la cohérence des différentes versions de ce document. Pour améliorer leur efficacité, l'Institut Eurocom a étudié l'organisation des caches reliés par des liens à très haut débit, et a développé un système de caches physiquement distribués sur plusieurs sites mais apparaissant logiquement comme un seul grand cache. Avec les caches distribués, une seule copie d'un document est présente dans l'ensemble de tous les caches, ce qui permet d'assurer la cohérence des informations présentes dans le réseau, d'utiliser l'espace disque des caches d'une manière plus efficace et d'assurer des temps de réponse extrêmement faibles.
Le nom TCP/IP se réfère à un ensemble de protocoles de communications de données. Cet ensemble tire son nom des deux protocoles les plus importants : Transmission Control Protocol et l'Internet Protocol. Le protocole TCP/IP devient le fondement d'Internet, le langage qui permet aux machines du monde entier de communiquer entre elles. Internet devient le terme officiel pour désigner non pas un réseau mais une collection de tous ces réseaux utilisant le protocole IP.
Le modèle TCP/IP peut en effet être décrit comme une architecture réseau à 4 couches.
5 O. ANDRIEU, Internet guide de connexion, Eyrolles, 3ème édition 1997-ISBN, pp.3-23.
La figure II.1 illustre le modèle TCP/IP.
Fig. II.1. Modèle TCP/IP
1°) Couche hôte réseau
Cette couche est assez "étrange". En effet, elle semble "Regrouper" les couches physiques et liaison de données du modèle OSI. En fait, cette couche n'a pas vraiment été spécifiée ; la seule contrainte de cette couche, c'est de permettre un hôte d'envoyer des paquets IP sur le réseau. L'implémentation de cette couche est laissée libre. De manière plus concrète, cette implémentation est typique de la technologie utilisée sur le réseau local. Par exemple, beaucoup de réseaux locaux utilisent Ethernet ; Ethernet est une implémentation de la couche hôte-réseau.
2°) Couche internet
Cette couche est la clé de voûte de l'architecture. Cette couche réalise l'interconnexion des réseaux (Hétérogènes) distants sans connexion. Son rôle est de permettre l'injection de paquets dans n'importe quel réseau et l'acheminement des ces paquets indépendamment les uns des autres jusqu'à destination. Comme aucune connexion n'est établie au préalable, les paquets peuvent arriver dans le désordre ; le contrôle de l'ordre de remise est éventuellement la tâche des couches supérieures.
Du fait du rôle imminent de cette couche dans l'acheminement des paquets, le point critique de cette couche est le routage. C'est en ce sens que l'on peut se permettre de comparer cette couche avec la couche réseau du modèle OSI. La couche internet possède une implémentation officielle : le protocole IP.
30) Couche transport
Son rôle est le même que celui de la couche transport du modèle OSI : permettre à des entités paires de soutenir une conversation. Officiellement, cette couche n'a que deux implémentations : le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol). TCP est un protocole fiable, orienté connexion, qui permet l'acheminement sans erreur de paquets issus d'une machine d'un internet à une autre machine du même internet. Son rôle est de fragmenter le message à transmettre de manière à pouvoir le faire passer sur la couche internet. A l'inverse, sur la machine destination, TCP replace dans l'ordre les fragments transmis sur la couche internet pour reconstruire le message initial. TCP s'occupe également du contrôle de flux de la connexion. UDP est en revanche un protocole plus simple que TCP : il est non fiable et sans connexion. Son utilisation présuppose que l'on n'a pas besoin ni du contrôle de flux, ni de la conservation de l'ordre de remise des paquets. Par exemple, on l'utilise lorsque la couche application se charge de la remise en ordre des messages. On se souvient que dans le modèle OSI, plusieurs couches ont à charge la vérification de l'ordre de remise des messages. C'est là un avantage du modèle TCP/IP sur le modèle OSI. Une autre utilisation d'UDP : la transmission de la voix. En effet, l'inversion de 2 phonèmes ne gêne en rien la compréhension du message final. De manière plus générale, UDP intervient lorsque le temps de remise des paquets est prédominant.
40) Couche application
Contrairement au modèle OSI, c'est la couche immédiatement supérieure à la couche transport, tout simplement parce que les couches présentation et session sont apparues inutiles. On s'est en effet aperçu avec l'usage que les logiciels réseau n'utilisent que très rarement ces 2 couches, et finalement, le modèle OSI dépouillé de ces 2 couches ressemble fortement au modèle TCP/IP. Cette couche contient tous les protocoles de haut niveau, comme par exemple
30 Telnet, TFTP (Trivial File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (HyperText Transfer Protocol). Le point important pour cette couche est le choix du protocole de transport à utiliser. Par exemple, TFTP (Surtout utilisé sur réseaux locaux) utilisera UDP, car on part du principe que les liaisons physiques sont suffisamment fiables et les temps de transmission suffisamment courts pour qu'il n'y ait pas d'inversion de paquets à l'arrivée. Ce choix rend TFTP plus rapide que le protocole FTP qui utilise TCP. A l'inverse, SMTP utilise TCP, car pour la remise du courrier électronique, on veut que tous les messages parviennent intégralement et sans erreurs.
Chaque interface Internet est identifiable par une adresse Internet codée sur 32 bits. Une adresse Internet Protocole est constituée de quatre nombres de 0 à 255 et séparée par un point comme ceci : 194.78.19.32. Cela donne également 32 bits ou quatre octets qu'on représente quelque fois de manière hexadécimale comme suit 0x9A0B3CFF. La figure II.2 illustre l'adressage IP.
Fig. II.2. Adressage IP
Chaque machine reliée à Internet dispose d'une telle adresse unique. Dans cette unique Internet, il faut encore distinguer deux parties, l'identifiant de réseau et le numéro d'hôte. Une adresse IP est composée de deux parties :
1' Le numéro du réseau ;
1' Le numéro de machine sur ce réseau.
La répartition d'adresse réseau en classe commence déjà à poser de sérieux problèmes. Avec la numérotation actuelle baptisée IPv4, il n'est possible d'adresser que 2 100 000 réseaux ou un total de 3 720 000 000. Un deuxième problème est la saturation des tables de routage qui croissent plus vite que la technologie des mémoires propres à les contenir. Ce sera la norme IPv6 avec des adresses IP codées sur 128 bits qui sera retenue pour pallier ces deux problèmes. Fin 1994, l'Internet Engineering Task Force s'est mis d'accord sur la norme IP Next Generation alias IPv6. IPv6 supportera jusqu'à 1 milliard de réseaux. IPv6 apporte plusieurs améliorations à la norme IPv4.
1' IPv6 est prévu pour coexister avec IPv4 ;
1' Un réseau IPv6 peut supporter un nombre illimité d'hôtes ;
1' Une adresse IPv6 peut contenir une adresse IPv4 ;
1' L'adresse est représentée comme huit valeurs hexadécimales de 16 bit séparés par des doubles points du type 5D54:352A:1235:B357:8283:2CDE:C00D:FCB2. Des groupes de zéros contigus peuvent être représentés par un double "::" comme suit: CF76:0:0:0:0:0:0:27 devenant CF76::27. Une adresse IPv4 de type d.d.d.d devient automatiquement x:x:x:x:d.d.d.d ;
V' 0:0:0:0:0:0:0:0 devient une "Unspecified address" ;
1' L'adresse loopback n'est plus 127.0.0.1 mais 0:0:0:0:0:0:0:1 ;
1' Le header a été simplifié pour réduire la bande passante requise par le protocole.
La grande nouveauté est l'intégration de manière native des protocoles IPSec (IP Security) dans IPv6 et non plus sur certaines configurations seulement comme c'était le cas avec IPv4. Cela représente une véritable avancée, en effet, lorsqu'IPv6 sera en place, tout un chacun pourra disposer de fonctions de sécurité grâce à IPSec. La sécurisation de VPNs (Virtual Private Network) lors de l'interconnexion de sites en est un exemple intéressant. Un autre avantage de ce choix est la compatibilité avec les applications tournant sous IPv4 qui est toujours largement utilisé et qui offre également l'accès à IPSec mais de manière optionnelle.
Ce chapitre a été consacré à la description des technologies et des services permettant de faire la connectivité d'un réseau et à présenter les dispositifs utilisés lors de la connectivité.
Actuellement le protocole SSL/TLS (Secure Socket Layer/Transport Layer Secure) est le protocole de sécurisation le plus déployé. Ceci est dû en grande partie à son intégration coté client dans les principaux navigateurs web.
SSL est une couche composée de quatre protocoles modulaires et indépendants dont le protocole Handshake qui a pour charge l'authentification des parties en jeu et la génération des secrets nécessaires pour la mise en oeuvre des services de sécurité tels que l'intégrité et la confidentialité.
Dans le monde des réseaux publics, plusieurs solutions ont été déployées pour la sécurisation des échanges (protocole de sécurité au niveau application, transport, réseau ou même physique) dont chacune a défini ses propres règles de gestion des clés. A la différence des solutions existantes, ISAKMP fournit un cadre générique pour la négociation des associations de sécurité (SA) pour des protocoles de sécurité a toutes les couches de la pile réseau. Une façon d'unifier toutes ces propositions est d'expérimenter le protocole ISAKMP avec d'autres protocoles de sécurité comme SSL/TLS.
Nos motivations pour adapter ISAKMP au protocole SSL/TLS sont les
suivantes :
1. Support pour la protection d'identité des deux communiquant Comme nous l'avons expliqué dans le premier chapitre, l'accès illicite aux informations concernant les identités des communicateurs constitue non seulement une atteinte à la vie privée des utilisateurs, mais aussi une véritable attaque sur l'infrastructure réseau. En effet, l'identification permet a l'ennemi de connaître des informations telles que le nom de l'utilisateur, le moment oü il accède au réseau, les services qu'il utilise, etc. Ce qui aboutit a une véritable attaque par analyse de trafic. Avec SSL/TLS, ce service concerne surtout la protection de l'identité du client (l'initiateur) puisqu'un serveur SSL/TLS possède toujours une identité publique ;
2. Interopérabilité entre les protocoles de sécurité. La première motivation derrière la conception du protocole ISAKMP par le NSA (Nationale Security
6 I. HAJJEH, Sécurité des échanges, conception et validation d'un nouveau protocole pour la sécurisation des échanges, Thèse de doctorat, Ecole nationale supérieure des télécommunications de Paris, décembre 2004, pp.81-103.
Agency) était le développement d'un protocole de gestion des clés robuste qui peut être utilisé avec plusieurs protocoles de sécurité (par exemple TLS, IPSec, etc.).
Ces protocoles pourraient en résultat partager le même code de gestion des clés suivant leur besoin en sécurité. Ceci permet alors :
1' De limiter les fonctionnalités redondantes au sein de chaque protocole de sécurité (authentification, intégrité, etc.) ;
1' De simplifier le transfert d'un protocole à un autre et réduire les temps d'établissement d'un canal sécurisé par chaque protocole. Chaque protocole définit seulement son échange en phase 2 ;
1' De permettre une meilleure gestion de l'ensemble des sessions établies par les différents protocoles à différents niveaux de la pile OSI.
3. Echange de plusieurs méthodes d'authentification sous une même SA sous la même association de sécurité ISAKMP, les deux entités peuvent établir plusieurs échanges en phase 2 avec différentes méthodes d'authentification. Ceci permet de négocier de nouvelles méthodes d'authentification sans avoir besoin de répéter les lourdes opérations cryptographiques effectuées durant la première phase d'ISAKMP (surtout la génération et l'échange des valeurs publiques DH) ;
4. Support des certificats d'attributs. Parmi sept types (PGP, X.509, SPKI, etc.), ISAKMP est le premier protocole d'authentification qui intègre dans sa spécification les certificats d'attribut. En effet, grâce a son mécanisme de protection d'identité, les certificats d'attribut ainsi que les autres types de certificats sont échangés sous une session sécurisée établie avant la phase d'authentification. Ainsi, nous nous intéressons a ce type de certificat afin d'assurer un service d'autorisation et de contrôle d'accès basé sur une approche de gestion de rôles ;
5. Support des mécanismes évolués pour les clients à faibles ressources Afin de diminuer le volume de données échangées entre les entités, le protocole ISAKMP propose un mécanisme de négociation des URLs des certificats d'identité et des certificats de confiance entre les acteurs. En effet, il suffit que l'émetteur envoie une URL vers une base de données LDAP (Lightweight Directory Access Protocol) pointant sur son certificat ou sur les certificats de confiance. Ceci est important pour réduire le temps d'échange avec ISAKMP dans le cas où un émetteur a envoyé plusieurs requêtes demandant différents types de certificats d'identité et d'autorité de certification ;
6. Flexibilité dans la définition des DOI avec ISAKMP, les différents paramètres de sécurité tels que les algorithmes de chiffrement, les algorithmes de signature, les fonctions de hachages et les tailles des clés sont définis à travers le DOI ou le domaine d'interprétation. L'utilisation d'ISAKMP avec un
nouveau protocole de sécurité nécessite en premier temps une définition `simple' d'un nouveau domaine d'interprétation pour le protocole concerné ;
7. Séparation des méthodes d'échange des clés de la gestion des associations de sécurité La séparation entre les méthodes d'échange des clés et celles de la gestion des associations de sécurité permet une meilleure interopérabilité entre des systèmes possédant différentes conditions de sécurité. Elle simplifie également l'analyse des différentes évaluations des serveurs ISAKMP ;
8. Négociation de multiples associations de sécurité dans la phase 2 d'ISAKMP Il est également possible avec ISAKMP pendant un simple échange en phase 2, de négocier des multiples associations de sécurité. Chacune de ces associations correspond à une application spécifique ayant son propre ensemble de clés.
Après la définition des principales motivations de notre architecture, nous citons trois contraintes inhérentes à sa conception globale. Les trois conditions pour réaliser un déploiement simple et efficace d'ISAKMP avec SSL/TLS sont :
1. Utilisation des échanges et des blocs standards ISAKMP afin de faciliter le déploiement de notre architecture et afin de minimiser les tâches de développement de nouveaux blocs ou échanges ISAKMP, nous avons essayé d'utiliser les blocs et les échanges ISAKMP existants. Avec SSL/TLS, nous nous intéressons surtout a l'échange de protection d'identité pour établir la première association de sécurité ISAKMP. Nous nous s'intéressons également a l'échange Quick Mode de Oakley pour établir la deuxième association de sécurité propre à SSL/TLS ;
2. Transparence par rapport à la couche Record de SSL/TLS Puisque le changement dans SSL/TLS est au niveau Handshake, les résultats d'échange (clé de chiffrement, d'authentification, etc.) doivent être transparents au protocole Record de SSL/TLS. C'est-à-dire, le mécanisme de dérivation des clés à partir de la clé matérielle générée avec ISAKMP doit ressembler à celui utilisé par le protocole Handshake de SSL/TLS ;
3. Interopérabilité avec le protocole SSL/TLS existant. En plus de l'interopérabilité avec le protocole Record de SSL/TLS, notre approche doit permettre à des clients SSL/TLS qui supportent notre proposition et à des serveurs qui ne la supportent pas de se communiquer et vice versa.
ISAKMP est un protocole de couche application placé au-dessus de la couche transport. Selon la spécification de ce protocole, il doit offrir ses services au dessus du protocole de transport UDP mais il peut être utilisé directement au-dessus d'IP. Actuellement et avec IKEv1, l'IANA lui a attribué le port 500 d'UDP. La figure III.1 illustre l'intégration d'ISAKMP dans SSL/TLS.
Fig. III.1 Intégration d'ISAKMP dans SSL/TLS
Avec SSL/TLS, ISAKMP peut fonctionner toujours sur le port 500 d'UDP. En effet, a la fin des deux phases ISAKMP, chaque protocole de sécurité doit chiffrer et/ou authentifier son propre tunnel indépendamment du protocole ISAKMP.
La figure III.2 illustre l'établissement de différentes sessions pour ISAKMP et SSL/TLS.
Fig. III.2. Etablissement de différentes sessions pour ISAKMP et SSL/TLS
Les quatre étapes nécessaires pour établir une session SSL/TLS avec ISAKMP sont les suivantes :
1. Négociation d'ISAKMP SA. Durant la première phase, un ensemble d'attributs relatifs à la sécurité est négocié. Les identités des tiers sont authentifiées et les clés sont générées. Ces éléments constituent une première association de sécurité que nous appelons ISAKMP SA ;
2. Négociation de TLS SA. La seconde phase permet de négocier les paramètres de sécurité relatifs à une SA (Security Associations) pour le compte d'un protocole de sécurité donné. Dans notre cas, c'est le protocole SSL/TLS. Les échanges de cette phase sont sécurisés (confidentialité, authenticité, etc.) grâce a l'association de sécurité déjà établie. Celle-ci peut être utilisée pour négocier plusieurs SA « fils » destinées à d'autres mécanismes de sécurité définis a travers des domaines d'interprétations (DOI) ;
3. Ouverture d'une session TCP. A ce point, ISAKMP a établi tous les paramètres de sécurité (algorithme de chiffrement, clés session, etc.) nécessaires au chiffrement de tout type de données (page Web, fichier, vidéo, etc.) avec la couche Record de SSL/TLS. Maintenant, c'est a l'application qui souhaite utiliser SSL/TLS d'établir une première connexion TCP vers le port défini par chaque application ;
4. Echange des messages CCS et des données chiffrées. Dans la dernière partie (étape 4 et 5), les clés de chiffrement sont activées avec le module CCS (ChangeCipherSpec) de SSL/TLS. Les messages CCS qui ne font pas partie du protocole Handshake, sont envoyés au début du premier échange de données chiffrées. De plus, afin de protéger ces messages contre l'attaque homme du milieu, nous proposons de les ajouter dans le premier échange chiffré des données.
Nous décrivons un ordre de messages échangés pendant les deux phases ISAKMP (étape 1 et 2 du paragraphe précédent) afin de fournir un exemple concret de l'intégration d'ISAKMP dans SSL/TLS. Les deux phases possèdent les caractéristiques suivantes :
1' Dans la première phase, les deux communicateurs (client et serveur SSL/TLS) initient l'échange de protection d'identité. Cet échange est basé sur une authentification mutuelle forte avec des certificats X.509 obtenus a partir d'une autorité de certification valide. Pour le client, son authentification est plutôt liée au matériel qu'il utilise. Le résultat de cet échange est la génération d'une clé secrète (SKEYID) et un ensemble des clés dérivées (SKEYID_d, SKEYID_a, SKEYID_e) servant à la génération de
nouvelles clés, a l'authentification et au chiffrement des messages de la phase 2 ;
1' Dans la deuxième phase, les deux communicateurs établissent une association de sécurité pour SSL/TLS. L'échange que nous proposons diffère courtement de l'échange Quick Mode d'Oakley. Nous l'appelons pour cela « TLS Quick Mode ». Cet échange permet aux deux entités :
1. de renégocier leur méthode d'authentification. Durant le deuxième échange, les deux entités (surtout le client) peuvent présenter de nouvelles identités, négocier leurs méthodes d'authentification et préciser l'adresse d'un serveur SSL/TLS (serveur virtuel ou réel) contenant les ressources demandées. Pour le serveur, sa réauthentification est inutile sauf a la suite d'une demande de certificat envoyée par le client. Ceci dans le cas oü le serveur demandé n'était pas authentifié durant la première phase ;
La figure III.3 illustre la Négociation des associations de sécurité avec plusieurs serveurs virtuels.
Fig. III.3. Négociation des associations de sécurité avec plusieurs serveurs virtuels
2. de permettre au client SSL/TLS de rester anonyme. Puisque dans la plupart des scénarios SSL/TLS le client est anonyme, nous avons introduit une nouvelle méthode d'authentification « anonyme » pour les clients. Elle requiert aucune modification ni au niveau des blocs ISAKMP, ni au niveau du mécanisme de génération des clés, mais seulement l'ajout d'un nouveau attribut «anonymous_client» dans le DOI de SSL/TLS.
Durant cette phase, les deux communicateurs établissent la première association de sécurité appelée ISAKMP SA. Puisque nous utilisons l'échange de protection d'identité, les deux entités échangent six messages pour négocier leur
stratégie de sécurité et pour protéger leur identité. Tous les échanges commencent avec un en-tête ISAKMP (HDR) suivi par un nombre variable de blocs.
Après l'établissement de la première association de sécurité, les deux entités commencent à négocier les paramètres de sécurité de SSL/TLS.
Dans cette deuxième phase, l'initiateur (le client SSL/TLS) indique dans l'en-tête ISAKMP, «TLS Quick Mode> comme type d'échange. Il spécifie un identificateur du message (message_ID) non nul, ajoute les deux cookies de la phase 1 et met le champ « flag » à 1 pour indiquer que les messages sont chiffrés. Le premier message comprend aussi :
1' Un Bloc HASH qui suit l'en-tête ISAKMP. Ce bloc contient le résultat de hachage pour toute ou une partie de ce message ISAKMP ;
1' Un bloc SA, précisant « TLS10 » comme protocole de sécurité utilisé dans cette phase ;
1' Un bloc Proposal qui se rapporte au protocole TLS10 auquel est associé un
SPI (Security Parameter Index) choisi aléatoirement par l'initiateur ;
1' Un ou plusieurs blocs Transform pour le bloc Proposal. Ceux-ci définissent
les différents attributs proposés par l'initiateur ;
V' Un bloc NONCE (NONCEi, NONCEr) qui sert à transporter de nouveaux aléas ;
V' Un bloc Key Exchange (KE) qui sert à transporter les données nécessaires à la génération d'une nouvelle clé DH partagée. Ce bloc contient aussi le champ group qui indique le nombre premier utilisé pour la génération des clés. Ce champ prend par défaut la valeur « Modular Exponentiation » avec 768 bits pour le nombre premier et 2 pour le générateur DH ;
1' Deux blocs d'identification (IDi, IDr). Le premier sert (IDi) à identifier le client. Il contient l'adresse 0.0.0.0/0. Le deuxième (IDr) sert à identifier un serveur parmi le rang d'adresse envoyé dans le même bloc (IDr) pendant la première phase. Le mécanisme que nous proposons ici permet aux clients de préciser depuis leur premier message, le serveur auquel ils souhaitent accéder ;
V' Un bloc de demande de certificat (Certificate Request).
L'emploi des blocs KE, HASH, ID et CERTReq est optionnel. Le bloc KE est utilisé si les deux communicateurs veulent assurer la propriété de PFS (Perfect Forward Secrecy) dans la génération des secrets partagés. Comme expliqué dans le RFC 2409, la présence du bloc HASH après les blocs SAs est explicite dans chaque message. Par contre dans notre échange, ce bloc est optionnel si les deux communicateurs utilisent un mécanisme d'authentification forte tel que la signature RSA (RSA_SIG).
En utilisant une fonction perf (clé, message), les deux entités vont générer un ensemble de clés pour le chiffrement des messages ISAKMP et la dérivation de nouvelles clés. L'intégration d'ISAKMP dans SSL/TLS nécessite un mécanisme de génération des clés qui respecte le mécanisme de dérivation des clés produit par le protocole Handshake de SSL/TLS, défini dans le RFC 2246. Ceci, afin d'obtenir les mêmes paramètres de sécurité utilisés par le protocole Record de SSL/TLS.
La dernière étape de notre architecture est le chiffrement de toutes les données échangées par le protocole Record de SSL/TLS.
Nous proposons un mécanisme simple qui ne nécessite aucun changement au niveau du protocole Record. En effet, ce dernier est activé lorsque les deux entités reçoivent les messages CCS (Change Cipher Spec) durant le dernier échange du protocole Handshake de SSL/TLS.
Le RFC 3546 (TLS Extensions) propose une nouvelle extension au protocole SSL/TLS vers de nouvel environnement. Ce travail a renforcé notre proposition et a résolu tous les problèmes de compatibilité des clients SSL/TLS qui veulent négocier ISAKMP à la place du Handshake de SSL/TLS et des serveurs SSL/TLS qui ne soutiennent pas cette option et vice versa.
La nouvelle extension que nous proposons dans ce chapitre et dans le chapitre suivant respecte la procédure de définition de nouvelles extensions avec TLS Extensions. Nous relevons ci-dessous certains points qui devraient être pris en considération par ce protocole :
v' Les extensions doivent être définies de telle sorte que chaque extension envoyée par le client soit connue par le serveur. Ce dernier répond avec une extension du même type. Dans le cas oü le serveur n'accepte pas l'extension, un message d'erreur est envoyé. En général, les messages d'erreurs ALERT de SSL/TLS devraient être envoyés au serveur. Un champ dans l'extension du serveur est envoyé au client ;
1' Les extensions doivent éviter toute attaque qui force a l'utilisation (ou a la non utilisation) d'une caractéristique particulière manipulant les messages Handshake. Ceci est vrai si les extensions sont ajoutées au message Finished de SSL/TLS. Les développeurs du protocole doivent être conscients que ces extensions ne changent pas le sens des messages envoyés dans le Handshake de SSL/TLS.
Afin de permettre à un client TLS de négocier un échange ISAKMP au lieu du Handshake standard de TLS, un nouveau type d'extension devrait être ajouté aux messages ExtendedClientHello et ExtendedServerHello.
Elle définit de nouveaux types d'erreurs pour l'usage avec ISAKMP et TLS. Les deux nouvelles alertes définies sont : unpresentjsakmp_sa et unrecognized_spi_value. Ces alertes ne doivent être envoyées qu'à la suite de l'utilisation de TLS Extension entre le deux communicants.
1' unsupportjsakmp_sa : cette alerte est envoyée par le serveur si le client demande l'ouverture d'une négociation TLS SA avant l'établissement d'une association de sécurité ISAKMP ;
1' unrecognized_spi_value : cette alerte est envoyée par le serveur s'il ne reconnaît pas l'identificateur de la phase envoyé par le client.
Les protocoles de gestion des clés forment une composante essentielle pour la mise en oeuvre des services de sécurité. De nombreux protocoles comme SSL/TLS proposent leur propre protocole de gestion des clés. Le protocole ISAKMP peut être employé comme une plateforme standard pour la négociation des paramètres de sécurité de tout protocole de sécurité. L'intégration d'ISAKMP dans SSL/TLS implique plusieurs avantages :
1' Etablissement des canaux sécurisés. ISAKMP fournit une méthode standard et expérimentée pour l'établissement des canaux sécurisés durant la négociation des paramètres de sécurité. Les étapes de négociation du protocole (identification et authentification) sont largement validées et prouvées comme sécurisées ;
1' Economisation des ressources. Une fois que les deux hôtes établissent un canal sécurisé, il est possible de convenir diverse future utilisation des SAs.
D'ailleurs, les associations de sécurité appartiennent à différents protocoles de sécurité, ce qui permet d'économiser les ressources. En effet, il est possible de négocier plusieurs SAs dans la même phase. En outre, le niveau de sécurité de chaque SA est également élevé ;
1' Flexibiité. ISAKMP est nettement plus flexible que d'autres protocoles, en particulier le Handshake de SSL/TLS et a donc la capacité de répondre à des besoins de services de sécurité beaucoup plus larges. Même si le protocole ISAKMP est considéré trop ouvert pour être une norme standard, cette flexibilité est l'un de ses avantages parce que c'est la seule manière de fournir une solution optimale pour chaque système d'information dans Internet.
Ce chapitre a montré la capacité et la nécessité de migrer les protocoles de sécurité courants vers ISAKMP. Cette tâche est d'autant plus difficile qu'IP est entrain de migrer vers la version 6. Avec IPv6, tous les hôtes seront en mesure de comprendre la négociation d'ISAKMP. Ainsi, il sera aisé de tirer profit d'un simple processus de négociation pour les différents protocoles de sécurité.
On trouve aujourd'hui des gros systèmes critiques informatiques dans les domaines de l'aéronautique, aérospatiale, du contrôle du procédé industrielle, de supervision de centrales nucléaire, voire de gestion de salles de marché ou de télémédecine. Pour ces exemples, une des caractéristiques est que le système informatique se voit confier d'une grande responsabilité en termes de vie humaine, de conséquence sur l'environnement. On parle alors des systèmes critiques, qui sont alors soumis à des contraintes de fiabilité et de sécurité.
La prise de contrôle d'infrastructures critiques semble être un des objectifs du cyber terrorisme, la preuve en est la recrudescence de scans (Tests de systèmes informatiques pour découvrir leurs vulnérabilités afin de pouvoir les pénétrer ultérieurement) dirigés sur des ordinateurs d'organisations gérant des infrastructures critiques (Eau, électricité, transport).
Les réseaux convergent aujourd'hui vers une architecture commune exploitant le protocole Internet. Ce protocole conçu pour le transport asynchrone des données informatiques n'a cependant pas été prévu pour des applications présentant des contraintes temps réel. Les défauts rencontrés sur les réseaux IP (Délai, gigue, perte des paquets et variation de la bande passante) ne pourront être surmontés sans une rénovation profonde de l'architecture et son adaptation aux nouvelles applications téléphonie, audio, vidéo à la demande. Le problème qui se pose : comment faire la connectivité des infrastructures critiques pour assurer un bon fonctionnement en respectant les contraintes du temps et de la qualité de service et en augmentant la sécurité pour lutter contres les attaques et les menaces ?
Pour réaliser une performance, il faut relier des routeurs nouvelles générations ou giga routeurs, par des canaux de transmission optiques haut débit en exploitant la technologie dite multiplexage en longueur d'onde, qui permet d'utiliser plusieurs canaux, ou longueur d'onde en parallèle dans la fibre optique. Avec cette architecture, on peut atteindre un débit potentiel de 40 Gigabits par seconde en coeur du réseau. Grâce à cette capacité en débit exceptionnel, le réseau permet de :
1' Favoriser l'enseignement a distance ;
1' Développer les techniques nécessaires a l'apprentissage du geste médical à distance ;
1' Atteindre les potentialités attendues du calcul informatique distribué ;
1' Permettre la sauvegarde en ligne de très grosses bases de données.
Tout en assurant une excellente qualité de service et en qualifiant le comportement du réseau à des applications très haut débit.
Pour atteindre ce débit, il faut utiliser la technologie dite multiplexage de longueur d'onde (Utilisée par France Télécom avec le réseau VTHD). Celle-ci permet d'utiliser simultanément plusieurs longueurs d'onde pour faire circuler des informations en parallèle dans une même fibre optique. Un des attraits majeurs de cette technologie est de permettre l'accroissement progressif des capacités de transmission d'une fibre par ajout progressif de longueurs d'onde supplémentaires. Mais le débit de transfert des informations ne dépend pas seulement de la fibre optique mais aussi des routeurs et des cartes interfaces entre fibres et routeurs (Pour le réseau VTHD, France Télécom n'a donc pas eu besoin d'installer de nouvelles fibres optiques : elle a simplement installé sur son réseau un matériel de dernier génération, des giga routeurs capables, via un laser, d'expédier sur une fibre une quantité colossale d'information, de l'ordre de 2,5 Gbits/s par longueur d'onde).
Avec cette technologie, on peut élaborer les garanties de qualité de service pour répondre aux attentes en termes de sécurité et de fiabilité.
On va présenter de manière synthétique les équipements et services à mettre en oeuvre afin d'assurer la sécurité et la confidentialité des données de l'entreprise qui souhaite connecter au réseau local a Internet via une ligne ADSL. L'ADSL représente actuellement la meilleure méthode d'accès a Internet pour une entreprise désirant fournir un accès relativement haut débit a ses utilisateurs. L'ADSL se positionne comme la technologie idéale pour connecter un réseau local à Internet. L'interconnexion d'un réseau local avec un réseau public doit s'effectuer dans le respect de certaines règles, notamment au niveau de la sécurité et de la confidentialité.
Le principal intérêt des technologies ADSL, est de réutiliser les câblages cuivre existants. Autant dire tout de site que la totalité des lignes téléphoniques déployées en France par l'opérateur nationale est éligible. De plus ces lignes
téléphoniques peuvent être utilisées simultanément pour le transport de la voie et pour le transport des données. En effet, pour être transportée sur une ligne téléphonique la voie n'utilise qu'une bande passante de quelques dizaines de kilohertz correspond en fait à la bande passante de la voie humaine, ce qui laisse une grande partie de la bande passante du câble inemployé. Cette bande passante inemployée que les technologies xDSL en général et l'ADSL en particulier utilisent.
Ainsi une ligne téléphonique normale peut-elle être transformée ligne en ADSL par la simple adjonction d'un filtre séparateur qui se charge de transporter la voie humaine vers le périphérique habituel, et le reste des données vers le périphérique jouant le rôle de modem ADSL.
L'offre ADSL de l'opérateur national comporte plusieurs niveaux de performance. Deux solutions proposées correspondant à des besoins en bande passante différents. Ces offres s'appellent commercialement NETISSIMO I et NETISSIMO II.
Ciblé a l'origine pour les particuliers, cette offre permet un débit de 500 Kbps en voie descendante (C'est-à-dire lorsque vous consultez des documents sur Internet ou que vous envoyez des emails) et de 128 Kbps en voie ascendante (C'est-à-dire lorsque vous envoyez des informations sur Internet ou que vous envoyer un email). Cette offre ne permet pas d'interconnecter un réseau local, mais une poste seul. Dans cette offre le modem est connecté directement entre le filtre ADSL et l'ordinateur se connectant a l'Internet.
Taillé pour interconnecter un réseau local, l'offre NETISSIMO II offre un débit de 1000 Kbps en voie descendante (C'est-à-dire lorsque vous consultez des documents sur Internet ou que vous envoyez des emails) et de 256 Kbps en voie ascendante (C'est-à-dire lorsque vous envoyez des informations sur Internet ou que vous envoyer un email).
Dans cette offre, la seule différence avec NETISSIMO II est qu'au lieu de connecter un ordinateur derrière le modem ADSL, on connecte un dispositif réseau appelé routeur qui est lui-même connecté au réseau local. Il est également fortement recommandé d'ajouter tous les dispositifs nécessaires afin d'assurer la sécurité et la confidentialité des données du réseau local. Ces dispositifs sont généralement concentrés au goulot d'étranglement que constitue l'accès vers Internet. On les appelle des Firewalls.
Après avoir fait installé la ligne ADSL avec son filtre, son modem et éventuellement son routeur et son firewall, il faut encore avant de pouvoir utiliser sa ligne ouvrir un abonnement auprès d'un fournisseur d'accès a Internet (FAI).
Les abonnements ont un coût différent en fonction de si l'on a opté pour une ligne NETISSIMO I ou pour une ligne NETISSIMO II. Les autres éléments pouvant influés sur le coût de l'abonnement au FAI sont principalement la demande d'une adresse IP fixe plutôt qu'une adresse IP dynamique attribué par votre FAI pour une durée finie, et qui peut changer une fois ce délai dépassé. L'intérêt d'obtenir une adresse IP fixe auprès de votre FAI tient surtout si vous souhaitez utiliser votre ligne Internet pour les besoins suivants :
1' Mettre à disposition sur le réseau Internet un serveur fournissant de l'information (Serveur web, serveur de messagerie, etc.) se trouvant dans vos locaux ;
1' Permettre a des personnes distantes d'accéder a votre système d'une manière sécurisée, authentifiée, et cryptée par le biais du mécanisme appelé VPN. (Virtual private network), réseau privé virtuelle en français.
La figure IV.1 illustre l'accès au réseau local par un Tunnel VPN.
Fig. IV.1. Accès au réseau local par un tunnel VPN
Le but d'un réseau virtuel (VPN) est de «Fournir aux utilisateurs et administrateurs du système d'administration des conditions d'exploitation, d'utilisation et de sécurité a travers un système public identique à celle disponible sur un réseau privée. En d'autres termes, on veut regrouper des réseaux privés, séparé par un réseau public (Internet) en donnant l'illusion pour l'utilisateur qu'ils ne sont pas séparés, et tout en gardant l'aspect sécurisé qui était assuré par la coupure logique au réseau Internet.
Un VPN est une technologie réseau qui crée un tunnel chiffré entre une machine sur Internet dotée d'une adresse IP quelconque et une passerelle d'accès d'un réseau privé. La machine distante se voie dotée lors de l'établissement du tunnel d'une adresse supplémentaire appartenant au réseau privé qu'elle cherche a atteindre.
Le tunnel est une composante indispensable des VPN ; la problématique est la suivante : on va relier deux réseaux privés qui sont séparés par un réseau public (Internet), de façon transparente pour l'utilisateur. L'utilisateur utilisera ainsi des interfaces réseaux virtuels et aura l'illusion de discuter directement avec le réseau qui se trouve, en fait de l'autre côté d'Internet. La solution technique utilisée, dans la plupart des cas, pour mettre en oeuvre des tunnels est l'encapsulation de protocoles. La figure IV.2 illustre le tunnel interconnectant le sous réseau A au sous réseau B.
Fig. IV.2. Tunnel interconnectant le sous réseau A au sous réseau B
Les réseaux convergent aujourd'hui vers une architecture commune exploitant le protocole Internet. Ce protocole conçu pour le transport asynchrone de données informatiques n'a cependant pas été prévu pour des applications présentant des contraintes temps réel. Les défauts rencontrés sur les réseaux IP (délai, gigue, perte des paquets et variation de la bande passante) ne pourront pas être surmontés sans une rénovation profonde de l'architecture et son adaptation aux nouvelles applications téléphonie, audio, vidéo a la demande. Avec l'explosion du trafic Internet et son évolution vers un réseau commercial multiservice, les utilisateurs d'Internet sont devenus des clients avec des exigences fortes en matière de qualité de service. Or l'architecture actuelle du réseau est limitée dans la mesure oü tous les paquets d'information sont traités de la même manière. Un réseau ayant un débit élevé permet d'assurer une excellente qualité de service avec des modèles de service adaptés aux besoins de nouvelles applications.
L'Internet multimédia qui intégrera voix, données et images dans une même architecture doit évoluer pour être capable de répondre aux nouveaux défis et de garder en même temps ses principes fondamentaux à savoir la simplicité, la robustesse et l'universalité.
1' L'augmentation de la QoS : pour résoudre le problème de la qualité de service de l'Internet, la recette pourrait être d'abord d'augmenter la bande passante pour améliorer les performances ;
1' La puissance du processeur : Pour commuter des paquets à des vitesses se chiffrant en térabits par seconde ou mettre en oeuvre des algorithmes de routage et de gestion de priorité sophistiquée, il faut disposer des puissances de calcul à la mesure des objectifs et des ambitions. La puissance de traitement semble donc comme la bande passante, quasi infini ;
1' L'adaptation en temps réel : Une large part du délai et de la gigue lors de transmission de voix sur IP est due a l'inadéquation des terminaux aux applications audio temps réel. L'électronique conversion analogue digitale (A/D), les systèmes d'exploitation, les cartes son, ont été conçus pour des applications traditionnelles et non pas pour le temps réel. Les interfaces réseaux et les modems sont étudiés pour des paquets de données de grande taille et non pas pour des petits paquets de voix. De nouvelles technologies d'accès large bande réseaux par câble (xDSL) ou sans fils doivent améliorer ces conditions ;
1' Les stratégies de bout en bout : Le réseau Internet est « Stupide » et se
contente de router les paquets individuellement sans notion de contexte ou de QoS alors que les terminaux sont intelligents et corrigent les défauts de transmission dans le cas de service à débit constant (Noté par CBR, Constant Bit Rate) ;
1' Les stratégies réseau : Les premières tentatives de modification du fonctionnement ont d'imiter les mécanismes de QoS implantés déjà dans les réseaux ATM. Le groupe qui a travaillé entre 94 et 97 a produit le protocole de réservation de ressources RSVP. Ce protocole est apparu très vite non efficace. D'autres stratégies plus simples fondées sur des indices de priorité indiquant la classe de service du paquet représentent aujourd'hui l'avenir du réseau. Les recherches dans le domaine de la QoS sont destinées aux VPN qui ne remplaceront vraiment les liaisons spécialisées que lorsqu'ils seront capables de garantir des spécifications strictes de QoS ;
1' L'introduction de la complexité dans le réseau : L'implémentation de mécanismes de QoS dans le réseau aura des répercutions importantes sur l'évolution des équipements. La mise à jour ultérieure ainsi que les services futurs devront être compatibles avec les mécanismes implantés déjà dans les machines. L'introduction de la complexité doit être réversible.
IV.5.2. Solutions de la QoS IV.5.2.1. Routeurs de périphérie
Le routeur moyen perd une partie de ses prérogatives au profit de nouveaux équipements d'extrémité, le routeur de périphérie qui sert de port d'entrée au sous réseau. C'est ce routeur qui calcule le chemin de routage qui affecte un indice de priorité au paquet et qui effectue éventuellement un contrôle d'accès.
L'introduction de mécanismes de ressources des classes de services (Notées CoS) représente une évolution certaine vers d'avantage d'intelligence. Les routeurs de l'Internet classique « Best effort '> traitent tous les paquets de la même manière. Les routeurs de l'Internet multimédia savent trier les paquets en fonction de leur indice CoS et leur apporter un traitement différencié. Les paquets subissent des contraintes de temps réel et seront servis en priorité et orientés vers des files d'attente garantissant la bande passante nécessaire. De même, en cas de congestion seront sacrifiés en premier les paquets d'application peu sensibles aux pertes. Ce que le routeur perd d'un côté (Le calcul du routage), il le gagne de l'autre en se dotant de capacité de discernement et de traitement différencié des paquets.
Une évolution prochaine pourrait introduire un mécanisme de notification explicite par laquelle un noeud informerait la source d'un état de congestion naissante, du montant de ressources disponibles à un instant donné ou de sa capacité à accepter et à traiter les paquets de priorité élevée.
IV.6. INTERNET PAR SATELLITE IV.6.1. Considération générale
Les télécommunications par satellites permettent de repousser les limites de la transmission de données par voie terrestre. De plus, la transmission de données s'effectue par liaison directe assurant ainsi un service homogène et ceci quelque soit la position de l'utilisateur. Télévision, radio, Internet et multimédia, communications d'entreprise et services de communication mobiles, le satellite peut être utilisé pour un large éventail d'application, dont la coexistence peut être particulièrement avantageuse. En effet, TV, radio, Internet et multimédia peuvent être combinée en une seule offre, ce qui permet de réduire les coûts des équipements et des services. A ces avantages, il peut être rajouté d'autres atouts comme une qualité de service exceptionnelle, une rentabilité appréciable ou une large capacité de transmission.
Les informations entre la terre et le satellite sont transmises par ondes électromagnétiques. Au fur et à mesure, ces ondes se propagent le long du trajet radioélectrique (Terre/satellite) et subissent un affaiblissement (Pour un trajet de 36 000 kilomètres correspond à peu près à la distance entre un point de la terre et un satellite géostationnaire, l'intensité d'une onde radio de 100 W a l'émission n'est plus
14
qu'un 1/ (2.10 ) Watt par mètre carré à la réception). La principale fonction des antennes utilisées dans les systèmes de télécommunications par satellite est de compenser la perte de puissance du signal qui se produit lors de son émission du sol vers l'espace (Et vice versa). Les antennes spatiales installées au bord des satellites géostationnaires peuvent émettre, recevoir, ou les deux a la fois. La conception d'une antenne dépend des exigences de la mission, lesquelles deviennent de plus en plus complexes. Elles sont caractérisées par le nombre de zones de services, la bande passante, la réutilisation des fréquences, la connectivité des canaux entre les zones de service, la flexibilité et la tenue en puissance. Pour répondre à de nombreuses applications, le satellite embarque une multitude d'aériens comme la montre la Figure IV.3 ci-dessous.
|
50 |
|
|
Fig. IV.3. Représentation des antennes embarquées sur un satellite |
L'Internet par satellite devient plus en plus un besoin et même une nécessité avec la démocratisation des WebTV, des ((Streaming» de plus en plus gourmand en bande passante et des sites web toujours plus riche en contenu multimédia.
Bien que des expérimentations soient actuellement menées sur la transmission de données bidirectionnelle entre un PC et un satellite, le matériel le plus fréquemment utilisé dans le cadre d'une utilisation résidentielle reste la carte de réception DVB-MPEG2 et le modem téléphonique pour la remontée des requêtes vers les serveurs du fournisseur d'accès. Il existe maintenant une large gamme de cartes offrant plus ou moins de fonctionnalité.
Le principe de fonctionnement de l'Internet par satellite est simple. A l'inverse de la connexion par modem téléphone standard, vous n'avez qu'un (( Interlocuteur » : les serveurs Proxy de votre fournisseur d'accès situé à la station d'émission (Appelée aussi (( Station d'Uplink »). En effet, là ou un internaute utilisant une connexion par modem entrera en contact avec différents serveurs disséminés sur le réseau mondial Internet, un internaute communiqué par satellite ne communiquera qu'avec un seul serveur qui est chargé de récupérer les demandes de l'abonné et de lui retransmettre le résultat de ses requêtes par la voie des aires. Inconvénient en cas de panne du serveur de la station d'émission. La fiabilité du matériel du fournisseur d'accès devient alors un élément non négligeable.
Les serveurs Proxy sont les serveurs chargés de (( Surfer » à la place de l'internaute. Ces serveurs appelés aussi (( cache », récupèrent les fichiers et données demandées par un abonné. Les données ainsi récoltées sont ensuite transmises à différentes machines dont la tâche et de les encapsuler en DVB-MPEG-2 avec un code
d'identification unique afin que seul l'abonné ait effectué la requête reçue son fichier. Bien souvent, l'adresse MAC de la carte de réception DVB-MPEG-2 est utilisée pour identifier l'abonné.
Autre possibilité intéressante de la réception de données par satellite vers un micro-ordinateur : le PUSH de données. Ce mode de réception rejoint complètement l'utilisation d'un satellite de façon « Normale '>. L'intérêt de l'utilisation d'un satellite est la possibilité de toucher des millions d'utilisateurs (Ou spectateurs) en un seul envoi de données. A l'inverse, en utilisation « Point à point » (Principe de base de l'Internet), le service du satellite ne sera utilisé que pour une seule personne isolée. Le mode PUSH peut donc être utilisé pour émettre des données intéressant un large public. On peut donc imaginer l'envoi de certains de sites Internet vers tous les postes d'un groupe d'abonnés ayant les mêmes centres d'intérêt. Par ailleurs, l'utilisateur n'a plus besoin d'effectuer des requêtes sur les serveurs Proxy de son fournisseur d'accès et par conséquent, n'a même plus besoin de se connecter à l'Internet pour recevoir des données.
Sur un satellite, un transpondeur dispose d'une capacité de 34 Mb, ce qui correspond à une connexion Internet à très haut débit souvent utilisés par les fournisseurs d'accès Internet terrestre ou de grandes sociétés nécessitant des hauts débits pour l'échange de données entre différents sites éloignés. Cette bande passante est alors partagée par le nombre d'abonnés utilisant simultanément les services de son fournisseur d'accès. En heure de pointe, cette bande passante peut être mise à mal si chaque abonné dispose lui même d'un matériel de réception et d'émission à haut débit. En théorie, une carte de réception DVB MPEG-2 accepte jusqu'à 45 MB par seconde! Un abonné pourrait alors consommer l'intégralité de la bande passante à lui tout seul, etc. Le fournisseur d'accès limite alors le débit maximum par utilisateur en effectuant différents réglages à la station d'émission.
Pour s'interconnecter de manière permanent et à haut débit au réseau Internet, les solutions ADSL restent le plus fiables et d'un moindre coût.
Des sociétés préparent plus ou moins discrètement des services d'accès Internet par satellite pour le grand public dont les lancements commerciaux sont prévus pour les mois à venir. Mais l'échec de certains pionniers a la matière de prouver qu'il n'est pas facile de proposer des services d'accès Internet par satellite en point à point en utilisant une technologie étudiée pour la diffusion de masse, autrement dit : le multipoint.
Il faut assurer la sécurité des infrastructures critiques lors de la connexion. Les systèmes de commande et l'acquisition de données embarqués dans les infrastructures critiques sont menacés par des attaques externes. Une architecture sécurisée est nécessaire lors de l'établissement de la connectivité. Il faut mettre en application des architectures plus bloquées et des technologies de sécurité, par exemple, en segmentant le réseau par des pare-feu robustes, utilisant l'authentification forte, mettant en application les programmes efficaces de gestion de la sécurité qui incluent la sécurité de tous les systèmes de commande.
Un pare-feu (Firewall, en anglais) est un dispositif matériel et/ou logiciel qui implémente la fonction de sécurité de contrôle d'accès. Un pare-feu est donc un dispositif pour filtrer les accès, les paquets IP, les flux entrant et sortant d'un système. Un pare-feu est installé en coupure sur un réseau lorsqu'il sert de passerelle filtrante pour un domaine a la frontière d'un périmètre fermé. Un pare feu est un système permettant de filtrer les paquets de données échangés avec le réseau, il s'agit aussi d'une passerelle filtrante comportant au minimum les interfaces réseaux suivante :
1' Une interface pour le réseau à protéger (Réseau interne) ; 1' Une interface pour le réseau externe.
Un pare-feu met en vigueur une politique de sécurité qui laisse passer, ou arrête les trames ou les paquets d'information selon cette politique. Il peut donc autoriser ou empêcher des communications selon leur origine, leur destination ou leur contenu. Dans la pratique, un pare-feu lit et analyse chacun des paquets qui arrivent. Après analyse, il décide du passage ou de l'arrêt selon l'adresse IP de l'émetteur, du récepteur, selon le type de transport (TCP ou UDP) et le numéro de port, en relation avec le type d'application réseau. Quand la politique de sécurité ne concerne que les couches basses, la seule analyse du paquet permet d'autoriser, de rejeter ou d'ignorer le paquet. Quand la politique décrit des règles de sécurité qui mettent en
jeu le transport fiable, les sessions ou les applications, le pare feu doit connaître l'état momentané de la connexion et doit garder en mémoire de nombreux paquets pendant un certain temps de façon qu'il puisse décider de l'autorisation ou du rejet des paquets.
Les pare-feu ont des limitations : ils doivent être très puissants en termes de ressources pour ne pas ralentir le trafic, dans un sens ou dans un autre, puisqu'ils ont en coupure sur le réseau. Ils ne doivent pas être court-circuités par d'autres passerelles ou des modems connectés directement a l'extérieur. Ils sont des « Bastions ,>, c'est-à-dire des cibles pour les attaquants qui peuvent les assaillir pour saturer leur ressource. Un pare-feu doit posséder un système de journalisation (.log) sophistiqué a posteriori tous les faits importants qui jalonnent la vie de cette passerelle filtrante : tentatives d'intrusion, événements anormaux, attaques par saturation, par balayage.
Un pare feu est en général architecturé de telle manière que l'on puisse distinguer physiquement les communications avec l'extérieur, celles avec le réseau a protéger et enfin celles qui sont déviées vers une zone tampon de parking, souvent appelée zone démilitarisée (DMZ en anglais), c'est dans cette zone qu'on place le site web, ouvert a l'Internet, a l'abri d'un pare-feu, mais nettement séparé du réseau interne à protéger. Il convient d'ailleurs de dire ici qu'il n'existe aucun système de sécurité qui soit infaillible à 100%. Tout logiciel, qu'il soit de type firewall ou de type chiffrement d'information peut être « Cassé ». Mais il suffit que les besoins financiers a mettre en oeuvre pour ce faire soient supérieurs a la valeur marchande estimée des informations en notre possession pour que le système soit considéré comme fiable.
La figure V.1 illustre le Firewall.
Fig. V.1. Firewall
V.2.1.2. Types de firewalls (Pare-feu) V.2.1.2.1. Packet filter
Le Packet filter, comme son nom l'indique, filtre les paquets dans les deux sens. Pour ce faire, il utilise des fonctions de routage interne classiques. Ce sont des protections efficaces, mais pas toujours suffisantes. Certaines attaques complexes peuvent déjouer les règles.
Evite l'IP spooffing en vérifiant que les adresses d'origine des paquets qui arrivent sur chaque interface sont cohérentes et il n'y a pas de mascarade. Exemple : un paquet qui a une adresse de votre réseau interne et qui vient de l'extérieur est un Spoofed Packet. Il faut le jeter et prévenir le plus vite l'administrateur qu'il y a eu tentative d'attaque.
Un système de détection d'intrusion (IDS en anglais), est un dispositif matériel et/ou logiciel de surveillance qui permet de détecter en temps réel et de façon continue des tentatives d'intrusion en temps réel, dans un SI ou dans un ordinateur seul, de présenter des alertes a l'administrateur, voire pour certains IDS plus sophistiqué, de neutraliser ces pénétrations éventuelles et de prendre en compte ces intrusions afin de sécuriser davantage le système agressé.
Un IDS réagit en cas d'anomalie, a condition que le système puisse bien identifier les intrus externes ou internes qui ont un comportement anormal, en déclenchant un avertissement, une alerte, en analysant éventuellement cette intrusion pour empêcher qu'elle ne se reproduise, ou en paralysant même l'intrusion. Un IDS est un capteur informatique qui écoute de manière furtive le trafic sur un système, vérifie, filtre et repère les activités anormales ou suspectes, ce qui permet ultérieurement de décider d'action de prévention. Sur un réseau, l'IDS est souvent réparti dans tous les emplacements stratégiques du réseau. Les techniques sont différentes selon que l'IDS inspecte un réseau ou que l'IDS contrôle l'activité d'une machine (Hôte, serveur).
1' Sur un réseau, il y a en général plusieurs sondes qui analysent de concert, les attaques en amont d'un pare-feu ou d'un serveur ;
1' Sur un système hôte, les IDS sont incarnés par des démons ou des applications standards furtives qui analysent des fichiers de journalisation et examinent certains paquets issus du réseau.
Il existe deux grandes familles distinctes d'IDS :
1' Les N-IDS (Network Based Intrusion Detection system), ils assurent la sécurité au niveau du réseau ;
1' Les H-IDS (Host Based Intrusion Detection system), ils assurent la sécurité au niveau des hôtes.
Un N-IDS nécessite un matériel dédié et constitue un système capable de contrôler les paquets circulant sur un ou plusieurs liens réseau dans le but de découvrir si un acte malveillant ou anormal a lieu. Le H-IDS réside sur un hôte particulier et la gamme de ces logiciels couvre donc une grande partie des systèmes d'exploitation tels que Windows, Linux, etc.
Le H-IDS se comporte comme un démon ou un service standard sur un système hôte. Traditionnellement, le H-IDS analyse des informations particulières dans les journaux de logs (Syslogs, messages, last logs, etc.) et aussi capture les paquets réseaux entrant/sortant de l'hôte pour y déceler des signaux d'intrusion (Déni de services, Backdoors, chevaux de Troie, etc.).
V.3. VPN 12 V.3.1. Principe
Les entreprises et les organisations possèdent en général plusieurs sites géographiques qui travaillent conjointement en permanence. Dans chaque site géographique, les utilisateurs sont connectés ensemble grâce à un réseau local. Ces réseaux locaux sont souvent connectés via Internet. En outre, certains utilisateurs peuvent vouloir se connecter aux réseaux de l'entreprise en étant a l'extérieur chez un client ou en déplacement. Il existait autrefois des liaisons physiques spécialisées, qui sont maintenant abandonnées au profit de liaisons logiques.
Un réseau virtuel privé (Virtual Private Network, en anglais d'oü l'abréviation VPN) consiste en fabrication d'un tunnel logique qui sera contracté par les communications de l'entreprise, lesquelles seront véhiculées dans cette tranchée numérique construite sur un réseau fréquenté par d'autres usagers. Dans la pratique, il s'agit d'un artifice, car les données vont utiliser un chemin ordinaire, emprunté par tout le monde, mais ces données chiffrées et tagguées seront sécurisées, a l'image du transport de containers plombés sur une route. Le caractère privé du réseau est donc complètement virtuel puisqu'il ne s'agit pas de liaison physique spécialisée. Le caractère privé est créé par un protocole cryptographique (IPSec ou PPTP). Un VPN est donc une communication sécurisée entre deux points d'un réseau public, d'oü l'expression de tunnel. Un VPN fournit un service fonctionnellement équivalent a un
12 G. LABOURET et H. SCHAUER CONSULTANTS, La sécurité réseau avec IPSec, 75001 Paris, le 24 avril 2003, pp.1-13.
réseau privé, en utilisant les ressources partagées d'un réseau public. Les réseaux VPN Internet sont utilisés dans plusieurs types d'application : Intranet étendus, Extranet, accès distants. Des tunnels empruntent le réseau Internet et assurent une sécurité robuste des échanges de données : authentification forte des équipements VPN source et destination, intégrité et confidentialité des données échangées. VPN fournit aux utilisateurs et administrateurs du système d'information des conditions d'exploitation, d'utilisation et de sécurité à travers un réseau public identiques à celles disponibles sur le réseau privé. Parmi les protocoles VPN les plus utilisés, on peut citer : VPN IPSec et VPN SSL.
Ce paragraphe présente trois exemples typiques d'utilisation d'IPSec dans un réseau d'entreprise. Il va de soi que, dans la pratique, ces trois cas peuvent être combinés et déclinés en de nombreuses variantes.
Exemple 1 : Réseaux privés virtuels
Une première utilisation possible d'IPSec est la création de réseaux privés virtuels entre différents réseaux privés séparés par un réseau non fiable comme l'Internet. Les matériels impliqués sont les passerelles de sécurités en entrée/sortie des différents réseaux (Routeurs, gardes-barrières, boîtiers dédiés). Cette configuration nécessite donc l'installation et la configuration d'IPSec sur chacun de ces équipements afin de protéger les échanges de données entre les différents sites. La figure V.2 illustre les réseaux privés virtuels.
Fig. V.2. Réseaux privés virtuels
Cet usage d'IPSec présente un certain nombre de limites :
1' Si beaucoup de communications doivent être chiffrées, des problèmes de performances peuvent apparaître ;
1' La configuration des équipements IPSec se faisant souvent manuellement et statiquement, l'utilisation d'une telle configuration avec un nombre élevé de sites et de tunnels est pour le moment difficile ;
1' La protection intervient seulement sur la traversée du réseau public, il n'y a pas de protection de bout en bout des communications.
Exemple 2 : Extranet
Dans l'exemple précédent, on désirait permettre des communications sûres entre différents sites fixes. Un autre cas est celui où les communications à sécuriser ne sont pas fixes mais au contraire intermittentes et d'origines variables. C'est le cas, par exemple, lorsqu'on désire permettre à des employés ou à des partenaires situés a l'extérieur de l'entreprise d'accéder au réseau interne sans diminuer le niveau de sécurité (Donc en mettant en oeuvre une confidentialité et un contrôle d'accès forts). Les matériels impliqués sont les portes d'entrées du réseau (Serveur d'accès distants, liaison Internet, etc.) et les machines utilisées par les employés (Ordinateur portable, ordinateur personnel au domicile, etc.). La figure V.3 illustre l'extranet.
Fig. V.3. Extranet
Cette configuration nécessite l'installation d'IPSec sur les postes de tous les utilisateurs concernés et la gestion d'une éventuelle base de données adaptée pour stocker les profils individuels. En contrepartie, elle représente un gros apport pratique pour les employés qui se déplacent beaucoup, sans diminution de la sécurité du réseau.
Exemple 3 : Protection d'un serveur sensible
Dans les deux exemples précédents, l'approche choisie était orientée vers la protection du réseau de l'entreprise dans son ensemble. On peut également vouloir utiliser IPSec pour protéger l'accès a une machine donnée. Par exemple, si un serveur contient des données sensibles que seul un nombre réduit de personnes (Internes ou externes a l'entreprise) doit pouvoir consulter, IPSec permet de mettre en oeuvre un contrôle d'accès fort et un chiffrement des données pendant leur transfert sur le réseau. Les matériels impliqués dans ce type de configuration sont le serveur sensible et les machines de toutes les personnes devant accéder aux données. La figure V.4 illustre le serveur sensible.
Fig. V.4. Serveur sensible
IPSec rend la sécurisation possible quelles que soient les applications utilisées pour accéder au serveur.
V.3.3. Protocole IPSec V.3.3.1. Généralités
IPSec est un ensemble de protocoles conçu par l'IETF afin de sécuriser le trafic IP. Initialement conçu dans la philosophie d'IPv6, IPSec est un système d'encapsulation offrant les services de sécurité requis au niveau IP. Néanmoins, étant donné que les besoins en matière de sécurité sur Internet et sur les Intranets ne peuvent attendre que la totalité (ou d'au moins une grande majorité) du parc informatique mondial ait migré vers IPv6, il est nécessaire que IPSec soit également utilisable avec IPv4. Une manière commode de procéder, qui a l'avantage de garantir la compatibilité avec toutes les implémentations existantes du protocole IP sans avoir à les modifier, est de considérer le protocole IPSec comme un protocole indépendant, implémentable comme un module additionnel sous forme d'un logiciel ou d'un équipement électronique dédié.
Une communication entre deux hôtes, protégée par IPSec, est susceptible de fonctionner suivant deux modes différents : le mode transport et le mode tunnel.
Le premier mode offre essentiellement une protection aux protocoles de niveau supérieur, le second permet quant a lui, d'encapsuler des datagrammes IP dans d'autres datagrammes IP dont le contenu est protégé. L'intérêt majeur de ce second mode est qu'il traite toute la partie IPSec d'une communication et transmet les datagrammes épurés de leur partie IPSec à leur destinataire réel réalisable. Il est également possible d'encapsuler une communication IPSec en mode tunnel, ellemême traitée par une passerelle de sécurité, qui transmet les datagrammes après suppression de leur première enveloppe à un hôte traitant à son tour les protections restantes ou à une seconde passerelle de sécurité.
V.3.3.2.1. AH (Authentication Header)
AH est le premier et le plus simple des protocoles de protection des données qui font partie de la spécification IPSec. Il a pour vocation de garantir :
1' L'authentification : les datagrammes IP reçus ont effectivement été émis par l'hôte dont l'adresse IP est indiquée comme adresse source dans les en-têtes ;
1' L'unicité (optionnelle, a la discrétion du récepteur) : un datagramme ayant été émis légitimement et enregistré par un attaquant ne peut être réutilisé par ce dernier, les attaques par rejeu sont ainsi évitées ;
1' L'intégrité : les champs suivants du datagramme IP n'ont pas été modifiés depuis leur émission : Données (en mode tunnel, ceci comprend la totalité des champs, y compris en-têtes du datagramme IP encapsulé dans le datagramme protégé par AH), version (4 en IPv4, 6 en IPv6), longueur de l'en-tête totale du datagramme (en IPv4), longueur des données (en IPv6), identification, protocole ou en-tête suivant (ce champ vaut 51 pour indiquer qu'il s'agit du protocole AH), adresse IP de l'émetteur, adresse IP du destinataire (sans Source Routing).
En outre, au cas où le Source Routing serait présent, le champ adresse IP du destinataire a la valeur que l'émetteur a prévu qu'il aurait lors de sa réception par le destinataire. Cependant, la valeur que prendront les champs type de service (IPv4), somme de contrôle d'en-tête (IPv4), classe (IPv6), flow label (IPv6) et hop limit (IPv6) lors de leur réception n'étant pas prédictible au moment de l'émission, leur intégrité n'est pas garantie par AH. En plus, AH n'assure pas la confidentialité des données : les données sont signées mais pas chiffrées.
La figure V.5 illustre l'Architecture d'IPSec.
Fig. V.5. Architecture d'IPSec
ESP est le second protocole de protection des données qui fait partie de la spécification IPSec. Contrairement à AH, ESP ne protège pas les entêtes des datagrammes IP utilisés pour transmettre les communications. Seules les données sont protégées. En mode transport, il assure :
1' La confidentialité des données (optionnelle) : la partie données des datagrammes IP transmis est chiffrée ;
1' L'authentification (optionnelle, mais obligatoire en l'absence de confidentialité) : la partie données des datagrammes IP reçus ne peut avoir été émise que par l'hôte avec lequel a lieu l'échange IPSec, qui ne peut s'authentifier avec sucées que s'il connaît la clé associée a la communication ESP. Il est également important de savoir que l'absence d'authentification nuit a la confidentialité en la rendant plus vulnérable a certaines attaques actives ;
1' L'unicité (optionnelle, a la discrétion du récepteur) ;
1' L'intégrité : les données n'ont pas été modifiées depuis leur émission.
En mode tunnel, ces garanties s'appliquent aux données du datagramme dans lequel est encapsulé le trafic utile, donc à la totalité (en-têtes et options inclus) du datagramme encapsulé. Dans ce mode, deux avantages supplémentaires apparaissent :
1' Une confidentialité limitée des flux de données (en mode tunnel uniquement, lorsque la confidentialité est assurée) : un attaquant capable d'observer les données transitant par un lien n'est pas a même de déterminer quel volume de données est transféré entre deux hôtes particuliers ;
1' La confidentialité des données, si elle est demandée, s'entend a l'ensemble des champs, y compris les en-têtes du datagramme IP encapsulé dans le datagramme protégé par ESP.
Enfin, ESP et AH ne spécifient pas d'algorithmes de signature et/ou de chiffrement particuliers. Ceux-ci sont décrits séparément. Le tableau V.1 illustre les Fonctionnalités des modes tunnel et transport.
Tableau V.1. Fonctionnalités des modes tunnel et transport.
|
Mode transport |
Mode tunnel |
|
|
AH |
Authentifie l'information utile IP et certaines portions de l'en-tête IP et les en-têtes d'extension IPv6. |
Authentifie le paquet IP tout entier plus certaines portions de l'en-tête externe et des en-têtes d'extension IPv6 externes. |
|
ESP |
Chiffre l'information utile IP et tout en-tête d'extension IPv6 suivant l'en-tête ESP. |
Chiffre le paquet IP tout entier. |
|
ESP avec authentification |
Chiffre l'information utile IP et tout en-tête d'extension IPv6 suivant l'en-tête ESP. Authentifie l'information et utilise IP mais pas l'en-tête IP. |
Chiffre le paquet IP tout entier. Authentifie le paquet IP. |
La RFC 2401 décrit le protocole IPSec au niveau le plus élevé. En particulier, elle indique ce qu'une implémentation est censée permettre de configurer en termes de politique de sécurité (c'est-à-dire quels échanges IP doivent être protégés par IPSec et le cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable d'utiliser IPSec, doit être présente une SPD (Security Policy Data base), dont la forme précise est laissée au choix de l'implémentation, et qui permet de préciser la politique de sécurité à appliquer au système. Chaque entrée de cette
base de données est identifiée par un SPI (Security Parameter Index) unique (32 bits). Une communication protégée a l'aide d'IPSec est appelée une SA (Security Association). Une SA repose sur une unique application de AH ou sur une unique application de ESP. Ceci n'exclut pas l'usage simultané de AH et de ESP entre deux systèmes, ou par exemple l'encapsulation des datagrammes AH dans d'autres datagrammes AH, mais plusieurs SA devront alors être activées entre les deux systèmes. En outre, une SA est unidirectionnelle. La protection d'une communication ayant lieu dans les deux sens nécessitera donc l'activation de deux SA. Chaque SA est identifiée de manière unique par un SPI, une adresse IP de destination (éventuellement adresse des broadcast ou de multicast) et un protocole (AH ou ESP). Les SA actives sont regroupées dans une SAD (Security Association Data base). La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non IPSec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter, l'accepter sans traitement IPSec, ou appliquer IPSec. Dans le troisième cas, la SPD précise en outre quels traitements IPSec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou de chiffrement utiliser). Les plus importants de ces termes sont les suivantes :
1' SPD Base de données définissant la politique de sécurité ; V' SA Une entrée de la SPD ;
1' SAD Liste des SA en cours d'utilisation.
Les règles de la SPD doivent pouvoir, si l'administrateur du système le souhaite, dépendre des paramètres suivants :
1' Adresse ou groupe d'adresses IP de destination ;
V' Adresse ou groupe d'adresses IP source ;
V' Nom du système (DNS complète, nom X.500 distingué ou général) ;
1' Protocole de transport utilisé (typiquement, TCP ou UDP) ;
1' Nom d'utilisateur complet, (ce paramètre n'est toutefois pas obligatoire sur certains types d'implémentation) ;
1' Importance des données (ce paramètre n'est toutefois pas obligatoire sur certains types d'implémentation) ;
1' Ports source et destination (UDP et TCP seulement, le support de ce paramètre est facultatif).
Certains paramètres peuvent être illisibles a cause d'un éventuel chiffrement ESP au moment où ils sont traités, auquel cas la valeur de la SPD les concernant peut le préciser. Il s'agit de :
( L'identité de l'utilisateur ; 1' Le protocole de transport ; 1' Les ports source et destination.
Il est donc possible de spécifier une politique de sécurité relativement fine et détaillée. Cependant, une politique commune pour le trafic vers un ensemble des systèmes, permet une meilleure protection contre l'analyse de trafic qu'une politique extrêmement détaillée, comprenant de nombreux paramètres propres à chaque système particulier. Enfin, si l'implémentation permet aux applications de préciser elles-mêmes a quelle partie du trafic appliquer IPSec et comment, l'administrateur doit pouvoir les empêcher de contourner la politique par défaut.
La présence de mécanismes de chiffrement asymétriques implique la prise en compte des problématiques de gestion des clés et de leur distribution à l'ensemble des systèmes destinés a être source et/ou destination d'une communication IPSec.
Dans le cas de petites infrastructures, il est possible, voire préférable, d'opter pour une gestion et une distribution manuelle des clés. Cette simplicité technique doit cependant être couplée a une bonne organisation et a une certaine rigueur afin d'une part, d'en assurer un fonctionnement correct et d'autre part de respecter les critères de renouvellement des clés.
Cependant, une telle méthode n'est pas applicable sur des infrastructures comprenant de nombreux systèmes, ceci pour d'évidentes raisons de volumes de données à traiter et de délais de mise en oeuvre. Le protocole IKE (Internet Key Exchange) a par conséquent été défini comme protocole par défaut pour la gestion et la distribution des clés. La gestion des clés est assurée par le protocole ISAKMP, le principe d'échange assuré par un mécanisme dérivé d'Oakley. Le rôle d'ISAKMP est essentiel. Il fourni un mécanisme « générique '> pour l'échange des messages et la gestion des clés. Il définit en particulier, le support des opérations de négociation de ces dernières.
Le fait qu'IPSec soit un protocole de sécurité au niveau réseau, il permet d'avoir un niveau de sécurité très élevé par rapport aux autres solutions de couches applicatives.
V.3.3.5.1. Protection contre le contournement et l'analyse du trafic
IPSec est le seul protocole qui répond à la nécessité de protéger l'infrastructure de réseau contre un contrôle en une surveillance non autorisés du trafic et de sécuriser le trafic entre utilisateurs, en utilisant des mécanismes d'authentification et de chiffrement. Il protège alors contre l'usurpation d'adresse IP (IP Spoofing) et les diverses formes d'écoute et de changement de paquets.
V.3.3.5.2. Protocole transparent aux applications
IPSec est au-dessous de la couche transport (TCP, UDP), il est donc transparent aux applications. IPSec ne nécessite aucun changement de logiciel sur un système utilisateur ou serveur quand IPSec est installé sur un pare-feu ou un routeur. Même si IPSec est mis en oeuvre dans des systèmes finaux, le logiciel de la couche supérieure, y compris les applications, ne sera pas affecté.
V.3.3.5.3. Mise en oeuvre d'un VPN
Le grand intérêt d'IPSec par rapport a d'autres techniques (par exemple les tunnels SSH), est qu'il s'agit d'une méthode standard (facultative en IPv4 et obligatoire en IPv6), mise au point dans ce but précis décrite par différentes RFCs. D'abord et avant toute autre considération, un VPN IPSec apporte de multiples éléments assurant la sécurité des réseaux. Il réduit considérablement les risques d'intrusions depuis l'extérieur sous forme d'usurpation d'adresse IP et d'écoute passive. De plus, un VPN IPSec protège un intranet des virus tels que les Worms, spécifiquement conçus pour répandre à grande vitesse sur Internet. Il reste la solution la plus déployée pour relier les réseaux des entreprises à travers un réseau non sécurisé comme Internet. Toutefois, un VPN IPSec ne garantit pas des indiscrétions ou des attaques venant de l'intérieur. Différentes études ont montré qu'en général, le piratage interne est plus dommageable, plus coûteux et aussi plus fréquent.
Les problèmes rencontrés avec le protocole IPSec sont relatifs à l'ambiguïté documentaire, l'implémentation et a la redondance des fonctionnalités.
V.3.3.6.1. Interopérabilité entre les implémentations
A cause de l'ambiguïté et la complexité dans la documentation des différentes parties de ce protocole, nous sommes arrivés actuellement à des implémentations incompatibles. De plus, puisque IPSec est intégré dans le noyau des systèmes, l'interopérabilité d'IPSec dépendra de la volonté qu'auront les constructeurs à faire coopérer des équipements hétérogènes entre eux (cela pose notamment le problème des algorithmes cryptographiques communs).
V.3.3.6.2. Redondances des fonctionnalités
d'authentification. Cette situation peut entraîner des faiblesses dans les différentes versions du produit IPSec.
Compte tenu de la souplesse des protocoles, certaines combinaisons peuvent s'avérer inacceptables au plan de la sécurité. Par exemple, le protocole ESP offre des services d'authentification et de chiffrement mais n'empêche pas l'utilisateur de transmettre un message chiffré sans authentification.
V.3.3.6.3. Broadcast et multicast
L'utilisation d'IPSec pour l'envoi et la réception de datagrammes multicast et broadcast pose quelques problèmes liés a des difficultés qu'une simple implémentation de la puissance de calcul ne saurait résoudre, comme la vérification des numéros de séquence. Le service de protection contre la duplication des données n'est donc pas utilisable en environnement multicast et broadcast a l'heure actuelle.
V.3.3.6.4. NATs
Théoriquement, aucune translation d'adresse ne devrait affecter un datagramme IPSec, car ce type d'opération modifie le contenu des datagrammes, ce qui est incompatible avec les mécanismes de protection de l'intégrité des données d'IPSec. Par exemple, en mode AH (Authentication Header), l'encapsulation IPSec ajoute une somme de contrôle (checksum), calculée notamment sur les adresses source et destination. Le protocole IKE, lui aussi se base sur les adresses IP sources et destinations pour la génération des clés et des cookies.
V.3.4. Protocoles ISAKMP et IKEv1 V.3.4.1. Généralités
Le protocole ISAKMP (Internet Security Association and Key Management Protocole), défini dans le RFC 2408 de novembre 1998, est proposé pour la gestion des associations de sécurité. ISAKMP fournit un cadre générique pour la négociation, la modification et la destruction des SA ainsi que pour le format de leurs attributs.
Dans le cadre de la standardisation d'IPSec, ISAKMP est associé a une partie des protocoles SKEME et Oakley pour donner un protocole final du nom d'Internet Key Exchange IKE. ISAKMP n'impose pas un algorithme spécifique d'échanges de clés. Il se compose plutôt d'un ensemble de types de messages qui permettent l'utilisation de divers algorithmes d'échanges de clés. Cependant, Oakley est l'algorithme spécifique d'échange de clés exigé pour la version initiale d'ISAKMP.
Pour IPSec, IKE est complété par un « domaine d'interprétation '> ou (Domain of Interpretation, DOI). C'est dans ce document qu'on défini les algorithmes d'échanges des clés et les différents blocs ISAKMP.
La figure V.6 illustre l'architecture d'ISAKMP.
Fig. V.6. Architecture d'ISAKMP
Si le DOI IPSec précise le contenu des blocs ISAKMP dans le cadre d'IPSec, IKE en revanche, utilise ISAKMP pour construire un protocole pratique. Il utilise certains des modes définis par Oakley et emprunte à SKEME son utilisation du chiffrement a clé publique pour l'authentification et sa méthode de changement de clef rapide par échanges d'aléas.
Bien que ce nom insiste sur le rôle d'échange de clés, IKE se charge en réalité de la gestion (négociation, mise à jour, suppression) de tous les paramètres relatifs à la sécurisation des échanges. Contrairement aux mécanismes AH (Authentification Header) et ESP (Encapsulating Security Payload) qui agissent directement sur les données à sécuriser, IKE est un protocole de plus haut niveau, dont le rôle est l'ouverture et la gestion d'un pseudo connexion au-dessus de tout protocole de transport ou sur IP directement (les réalisations doivent cependant supporter au moins le protocole UDP, l'IANA a attribué le port 500 a ISAKMP).
IKE inclut, au début de la négociation, une authentification mutuelle des tiers communicants qui peut se baser soit sur un secret partagé préalablement, soit sur des clés publiques.
L'échange des clés publiques utilisées par IKE peut se faire soit manuellement, soit directement dans le cadre d'IKE par un échange de certificats en ligne, ou encore par le biais d'une infrastructure à clés publiques (Public Key Infrastructure, PKI) extérieure. DOI définit la syntaxe des paramètres, les types d'échanges et les conventions de nommage relatifs a l'emploi d'ISAKMP dans un cadre particulier. Un
identifiant (DOI identifier) est par conséquent utilisé pour interpréter et synthétiser la charge utile des messages ISAKMP dans le contexte d'un DOI donné. Par exemple, le protocole IPSec a le numéro 1 comme identifiant pour son DOI. L'utilisation d'ISAKMP avec un nouveau protocole (tel que le cas que nous proposons pour SSL/TLS) exige la définition d'un nouveau DOI propre a ce protocole. La figure V.7 illustre la présentation symbolique du domaine d'interprétation d'ISAKMP IPSec.
Fig. V.7. Présentation symbolique du domaine d'interprétation d'ISAKMP IPSec
ISAKMP comprend deux phases de communication qui permettent une séparation claire de la négociation des SA pour un protocole spécifique et la protection du trafic ISAKMP.
La première phase entame la négociation d'une association de sécurité relative au protocole ISAKMP. Une fois les paramètres partagés et l'échange authentifié, la S ISAKMP est établie. Celle-ci définit la manière dont deux entités ISAKMP vont sécuriser leurs échanges ultérieurs. Ceci constitue une première « association de sécurité » connue sous le nom de SA ISAKMP.
La deuxième phase permet la négociation des nouveaux paramètres de sécurité liés à un autre protocole, comme AH (Authentication Header) et ESP (Encapsulating Security Payload). Les échanges de cette phase sont protégés par l'association de sécurité établie dans la phase 1 (SA ISAKMP).
La figure V.8 illustre les phases d'IKEv1.
Fig. V.8. Phases d'IKEv1
Pour les échanges ISAKMP, le RFC 2408 a défini cinq types d'échanges pour la phase 1 : Base Exchange, Identity Protection Exchange, Authentication Only Exchange, Aggressive Exchange et Informational Exchange. Pour la phase 2, la définition des types d'échange est laissée au protocole qui utilise ISAKMP pour satisfaire ces propres besoins en termes de gestion des clés et de sécurité. Dans le cadre du protocole IKE, il utilise une instance de l'échange Identity Protection Exchange (ou main mode) et Aggressive Exchange comme des échanges de la phase 1 de IKEv1. L'échange Aggressive Exchange (ou quick mode) est aussi défini comme un échange de la phase 2 de IKEv1 avec quelques messages optionnels.
Lorsque des services de sécurité sont employés, il est nécessaire de savoir sans ambiguïté à quelle SA se rapportent les échanges. Les phases de négociations permettent leur identification par utilisation de champs dédiés.
Lors de la première phase, l'initiateur émet un cookie (Initiator Cookie) dans l'en-tête (HDR) ISAKMP du premier message qui comprend :
V' Un bloc SA (SA Payload), précisant si l'association de sécurité ISAKMP négociée est ou non générique ;
V' Un bloc proposal (Proposal Payload), indiquant que le protocole auquel se rapporte la SA est ISAKMP ;
1' Un ou plusieurs blocs Transform (Transform Payload), chacun d'entre eux proposant différents attributs pour la SA. Leur syntaxe est spécifiée par IKE.
La figure V.9 illustre les échanges d'IKEv1.
a) Echange Phase 1 d'IKE (Main mode) b) Echange Phase 2 d'IKE
(Quick mode)
Fig. V.9. Echanges d'IKEv1
Le destinataire communique en réponse son propre cookie (Responder Cookie) et retourne le triplet (SA, Proposal, Transform) correspondant à la solution retenue. A ce stade, le couple (Initiator Cookie, Responder Cookie) qui identifie de façon unique la SA ISAKMP, est inséré dans tous les messages des deux phases. Les deux entités continuent la négociation en échangeant leur valeur publique DH à travers les blocs KE afin de créer une clé partagée et trois autres clés pour la dérivation des nouveau clés, le chiffrement et l'authentification des données. A ce point, les nouveaux messages envoyés seront protégés en confidentialité et en intégrité. L'initiateur et le répondeur échangent leurs identités et s'authentifient a travers les blocs ID et AUTH respectivement. Les identités sont des adresses IP ou des champs liés au certificat X.509. Cependant, le bloc AUTH représente trois méthodes d'authentification : des clés partagés, des certificats X.509 ou le chiffrement avec des clés publiques. Au terme de la première phase, les interlocuteurs jouent un rôle symétrique puisque les deux peuvent initier une négociation de phase 2. Une SA ISAKMP est par nature bidirectionnelle. Dans la phase 2, les deux communicateurs négocient à nouveaux les paramètres de sécurité d'IPSec. Chaque négociation aboutit en fait a deux SA, une dans chaque sens de la communication. Plus précisément, les échanges composant ce mode ont le rôle suivant :
1' Négocier un ensemble de paramètres IPSec (paquets de SA) ;
1' Échanger des nombres aléatoires utilisés pour générer une nouvelle clé qui dérive du secret généré en phase 1 avec le protocole Diffie-Hellman. De façon optionnelle, il est possible d'avoir recours à un nouvel échange Diffie-Hellman afin d'accéder à la propriété de Perfect Forward Secrecy qui n'est pas fournie si on se contente de générer une nouvelle clé à partir de l'ancienne et des aléas ;
1' Identifier le trafic que ce paquet de SA protégera, au moyen de sélecteurs (blocs optionnels IDi et IDr. En leur absence, les adresses IP des interlocuteurs sont utilisées).
Notons finalement, que les exécutions de la phase 1 doivent être rarement faites. En effet, dans la phase 1, les exécutions cryptographiques sont les plus intensives. Cette phase est conçue pour échanger en toute sécurité une clé secrète, même dans le cas quand il n'y a absolument aucune protection de sécurité en place entre les deux machines. Cette clé secrète est basée sur des valeurs publiques DH et autres paramètres échangés durant la première phase. En revanche, les échanges de la phase 2 sont moins complexes, puisqu'ils sont utilisés seulement après que le mécanisme de protection de sécurité, négocié dans la phase 1, est lancé.
En général, les négociations en phase 1 sont exécutées une fois par jour ou peut-être une fois par semaine, alors qu'on exécute des négociations de la phase 2 une fois toutes les quelques minutes. Le tableau V.2 illustre le temps de négociation des deux phases ISAKMP/IKEv16.
Tableau V.2. Temps de négociation des deux phases ISAKMP/IKEv16.
|
Echanges ISAKMP/IKEv1 |
Temps en seconde (s) |
|
Phase 1 : Main Mode (3DES, SHA, DH groupe 2, certificat X.509 avec une chaine de certification égale à 1) |
0.201004 |
|
Phase 1 : Main Mode (3DES, SHA, DH groupe 2, clé partagée) |
0.188085 |
|
Phase 2 : Quick Mode (3DES, SHA, DH groupe 2) : avec PFS |
0.118204 |
|
Phase 2 : Quick Mode (3DES, SHA) : sans PFS |
0.006008 |
Le tableau V.3 décrit les opérations cryptographiques effectuées pendant la négociation de la phase 1 (identity protection) d'ISAKMP. Les trois modes d'authentification supportés sont :
1' L'initiateur et le répondeur s'authentifient avec des certificats X.509 et une signature RSA. Dans ce cas, les deux entités possèdent à signer les données échangées en utilisant la clé privée associée à leur certificat X.509. Chacun de son coté doit vérifier le certificat envoyé et générer des valeurs DH éphémères pour l'échange des clés ;
1' Dans la deuxième mode d'authentification, chaque entité doit chiffrer avec la clé publique de l'autre bout de la communication, son identité et le nombre aléatoire ;
1' L'échange des clés se base aussi sur la génération des valeurs DH éphémères.
Dans le troisième mode d'authentification, les deux entités utilisent les clés publiques pour le chiffrement des nombres aléatoires. Il génère des valeurs DH éphémères pour l'échange des données. Le tableau V.3 illustre les opérations cryptographiques dans la phase 1 d'ISAKMP.
Tableau V.3. Opérations cryptographiques dans la phase 1 d'ISAKMP.
|
Phase 1 (ISAKMP Identity Protection) |
|||
|
RSA SIG |
RSA ENC |
RSA ENC Revised |
|
|
Initiateur |
DHop + RSAsign + RSAverify |
DHop + 2 RSAenc + 2 RSAdec |
DHop + RSAenc + RSAdec |
|
Répondeur |
DHop + RSAsign + RSAverify |
DHop + 2 RSAenc + 2 RSAdec |
DHop + RSAenc + RSAdec |
V.3.5. Protocole SSL/TLS 13 V.3.5.1. Généralités
Le protocole SSL (Secure Socket Layer) est développé a l'origine en 1996 par Netscape. En 1999, la première version standard de ce protocole est apparue à l'IETF sous le nom de TLS (Transport Layer Security). TLS correspond a la version 3.1 de SSL. SSL/TLS est un protocole modulaire dont le but est de sécuriser les transactions Internet entre le client et le serveur indépendamment de tout type d'application. En effet, SSL/TLS agit comme une couche supplémentaire au-dessus de TCP, permettant ainsi d'assurer les services d'authentification, de confidentialité et d'intégrité. L'implémentation native de la dernière version de SSL/TLS (version 3) par les navigateurs et serveurs Web actuels du marché, fait de HTTPS (HTTP sur SSL/TLS) le standard de facto de sécurisation des applications Web. C'est principalement pour
13 http : // www.cert-i-care.org.
cette raison que SSL/TLS est aujourd'hui massivement utilisé dans le commerce électronique afin de chiffrer les échanges et authentifier les serveurs via l'utilisation de certificats X.509v3. En revanche, l'authentification des clients reste beaucoup moins répandue. Ceci est dû au problème du déploiement à grande échelle des PKI, les lourdes opérations cryptographiques pour la vérification des certificats ainsi que la chaîne de certification. La figure suivante montre le temps de traitement cryptographique nécessaire pour l'établissement d'une session SSL/TLS avec une longueur de chaîne de certification égale à 1. La Figure V.10 illustre le temps de traitement pour un handshake SSL/TLS.
La figure V.10 illustre le temps de traitement pour un Handshake SSL/TLS.
a) Mode RSA sans authentification du client b) Mode RSA avec authentification du client
c) Mode RSA sans authentification du client d) Mode RSA
avec authentification du client
Fig. V.10. Temps de traitement pour un
Handshake SSL/TLS
SSL/TLS est conçu pour se servir de TCP afin de fournir un service sécurisé de bout en bout fiable. SSL/TLS n'est pas un simple protocole, mais plutôt constitué de deux couches de protocole.
Record fournit des services de sécurité de base à divers protocoles de couche supérieure.
La deuxième couche est composée de deux sous protocoles :
1' Le protocole de poignée de main (Handshake Protocol) : ce protocole permet d'authentifier les parties en jeu et d'assurer un mécanisme sécurisé pour la gestion des clés ;
1' Le protocole de changement des spécifications de chiffrement (Change Cipher Spec protocol, CCS) : ce protocole comprend un seul et unique message. Son but est d'activer pour la session SSL courante les algorithmes, les clés et les nombres aléatoires durant la phase d'initialisation (la phase Handshake). Ceci en passant ces informations au protocole Record ;
1' Le protocole d'alerte (Alert Protocol) : ce protocole spécifie les messages d'erreur envoyés entre les clients et les serveurs. Les messages sont de deux types : le premier contient les messages d'erreurs fatales (Fatal Error) et le deuxième, les alertes ou les messages d'erreur non fatale (Warning Error). Si le niveau est fatal, la connexion est abandonnée. Les autres connexions sur la même session ne sont pas coupées mais on ne peut pas en établir de nouvelles.
La Figure V.11 illustre l'Architecture de SSL/TLS.
Fig. V.11. Architecture de SSL/TLS V.3.6. Protocole Handshake
Le protocole Handshake est la partie la plus complexe de SSL/TLS. Il permet l'échange des paramètres de sécurité (nombres aléatoires, liste des algorithmes de chiffrement, de hachage, etc.) entre le client et le serveur avant que les données applicatives ne soient transmises. Il permet aussi l'authentification des
deux communicateurs. Cependant, dans la plupart des cas, le serveur est uniquement authentifié. Ce protocole peut opérer en deux formes : soit il établit un échange complet avec la négociation des paramètres de sécurité (le Handshake complet), soit il essaye d'utiliser une ancienne session SSL/TLS déjà négociée (Handshake abrégé).
La figure V.12 illustre l'échange initial nécessaire pour établir une connexion complète entre le client et le serveur.
Le client commence l'échange SSL/TLS en envoyant le message ClientHello qui contient un nombre aléatoire (R1), un identificateur de session (S_ID), une liste des algorithmes de compression (compression_list) et une suite de chiffrement (cipher_list). Notons que le nombre aléatoire est une concaténation entre le temps système en format Unix et un nombre aléatoire.
Le serveur répond en envoyant le message ServerHello contenant un nombre aléatoire (R2), un identificateur non nul de session et une suite choisie des algorithmes de chiffrement et de hachage. Le serveur envoie également un certificat X.509 contenant sa clé publique pour s'authentifier. Ensuite, le client vérifie la clé publique du serveur et génère un nombre aléatoire sur 48 octets connu sous le nom du pre_master_secret. Le client chiffre le pre_master_secret avec la clé publique du serveur et l'envoie dans le message ClientKeyExchange.
A la réception de ces messages, le serveur déchiffre le pre_master_secret en utilisant sa clé privée. C'est à ce moment là que le client et le serveur peuvent calculer un secret partagé, le master_secret, à partir des nombres aléatoires R1 et R2 et du pre_master_secret. Ce secret servira par la suite à la dérivation des clés de chiffrement et de déchiffrement dans les connexions SSL/TLS. Le dernier échange achève l'instauration d'une connexion sûre. Les deux entités échangent les messages finished contenant le hachage de l'ensemble des messages et des paramètres négociés.
La Figure V.12 illustre l'Handshake SSL/TLS.
Fig. V.12. Handshake SSL/TLS
Si le certificat client est exigé par le serveur (le serveur envoie le message CertificateRequest), alors le client répond en envoyant le message CertificateVerify contenant sa signature sur toutes les informations échangées avec le serveur. Même si l'authentification par certificat X.509 et par clés RSA reste la plus utilisée pour l'authentification des serveurs SSL/TLS, ces derniers peuvent avoir d'autres méthodes d'authentification telles que l'authentification par des valeurs DH Anonymes (un nombre premier, un nombre qui lui est relativement premier et la clé publique DH du serveur), des valeurs DH temporaires (les paramètres DH et une signature), un échange RSA (où le serveur n'a qu'une clé RSA pour signer et établir une clé RSA temporaire) ou finalement par Fortezza (norme de sécurité du gouvernement américain). Parmi toutes ces méthodes, l'échange du DH temporaire reste le plus sûr.
Puisque le Handshake de SSL/TLS est crypto graphiquement coûteux en termes d'opérations de chiffrement asymétrique, SSL/TLS introduit un mécanisme plus rapide pour la négociation d'une nouvelle session basée sur un secret partagé entre les communicateurs. Ce mécanisme est appelé « Resumed Handshake ». Le client et le serveur font une négociation rapide puis calculent les nouvelles clés de sessions à partir de l'ancienne clé partagée. Le « Resumed Handshake '> permet de générer des nouvelles clés symétriques et des vecteurs d'initialisation a partir du master_secret généré dans une ancienne session SSL/TLS.
Dans ce but, le client envoie dans le message client_hello le champ S_ID d'une ancienne session. Le serveur peut accepter la nouvelle connexion en plaçant le champ S_ID dans son message server_hello avant de l'envoyer au client. A ce point, le reste de l'échange SSL/TLS est sauté et les deux communicants calculent les nouvelles clés a partir de l'ancien master_secret créé dans l'ancienne session négociée.
Avec le Handshake actuel de SSL/TLS, le serveur ne peut pas savoir le service demandé par le client jusqu'à ce que la phase d'initialisation soit complètement établie. L'objectif de TLS Extensions est de permettre aux deux entités, client et serveur, de négocier de nouveaux services pendant le premier échange SSL/TLS et avant l'établissement d'une session sécurisée.
IPSec et SSL sont les protocoles de sécurité les plus utilisés sur internet. Néanmoins ces deux protocoles présentent de grandes différences :
1' Niveaux d'opérations : IPSec est un protocole de niveau réseau tandis que SSL est un protocole de niveau applicatif. Cette différence est le point de divergence essentiel ;
1' Périmètre sécurisé : opérant à deux niveaux différents, SSL offre des services de sécurité limités a TCP tandis qu'IPSec supporte n'importe quel trafic, TCP, UDP ou autre. De même SSL sécurise une application donnée tandis qu'IPSec sécurise plusieurs applications simultanément ;
1' Support d'installation : Un grand avantage de SSL est l'absence de logiciel supplémentaire côté client, un grand nombre de navigateurs supportant nativement HTTPS (http sur SSL). A l'inverse IPSec requiert a ce jour le déploiement de logiciels spécifiques.
D'un point de vue sécurité, il n'y pas une grande différence entre SSL et IPSec qui partagent les mêmes algorithmes. Etablir un VPN SSL ou un VPN IPSec dépend alors essentiellement des besoins des utilisateurs.
Trois points clés pour réussir l'administration d'un VPN, sont : la sécurité, l'administration et le dynamisme. Le déploiement de réseaux privés sur des infrastructures partagées voire publiques comme Internet nécessite des précautions impératives pour protéger les systèmes connectés à l'infrastructure partagées et les échanges qui vont prendre place sur cette infrastructure. Les solutions retenues s'appuient sur plusieurs protocoles de sécurité, tel que L2TP, PPTP ou encore IPSec. IPSec, une suite de protocoles de sécurité définie par l'IETF, est le protocole utilisé dans notre approche grâce à ces avantages sur les autres protocoles.
D'autres part, l'étude d'une solution VPN, nécessite une bonne maîtrise de l'architecture du réseau a modifier ou a construire. L'administration est un élément clé au déploiement des VPNs et tout particulièrement tout ce qu'il concerne les services de groupes de communications. La mise en place d'une solution bien administrée est reliée avec les points suivants :
1' Politique : le système d'administration doit avoir le pouvoir de convertir les politiques de configuration à des règles appliquées sur les passerelles VPNs. La sécurité et l'atténuation des attaques sont aussi basées sur les politiques ;
1' Configuration : l'approvisionnement et la configuration des équipements VPN doivent être fait d'une manière automatisée et appliquée sur les passerelles VPNs ;
1' Déploiement rentable : dans un système administré, il faut avoir un mécanisme pour envoyer, déployer, et mettre à jour les fichiers de configuration ;
1' Connaissance des topologies VPNs : plusieurs types de topologie doivent être supportés. On distingue les VPN maillés et les VPN en étoile qui correspond respectivement à des topologies de liaisons virtuelles entre sites de type n vers m (Réseau maillé) soit de type n vers 1 (Réseau en étoile) ;
1' Surveillance : l'environnement sécurisé doit être mise sous contrôle et sous surveillance. Une automatisation de la supervision et de l'administration des équipements VPN installés sur les sites des utilisateurs finales.
En général, l'administration est avant tout une problématique de connectivité réseau et d'infrastructure IP. Certains problèmes spécifiques liés a la technologie utilisée compliquent la mise en oeuvre, par exemple, la diffusion des fichiers de configuration IPSec bien cohérents entre les différents équipements VPN distribués sur l'Internet.
14 FRANCE TELECOM, l'Internet vraiment très haut débit, Paris, le 9 mai 2001, pp.43-48.
IPSec est un système très complet qui peut répondre à beaucoup de besoins en matière de sécurité et s'adapter a de nombreuses situations. Sa conception en fait un système très sûr et sa nature de norme garantit l'interopérabilité entre les équipements de différents fournisseurs. Ces avantages, couplés à la prédominance grandissante du protocole IP, vont certainement faire d'IPSec un acteur important de la sécurité des réseaux informatiques. Il lui manque encore, pour être utilisé à grande échelle, un peu de maturité et surtout un système de gestion centralisée et dynamique des politiques de sécurité. Les avancées actuelles dans ce domaine laissent a penser qu'il ne s'agit que d'une question de temps avant qu'un tel système ne voie le jour. L'apparition d'infrastructures à clefs publiques fonctionnelles et reconnues est également indispensable pour une utilisation pratique et répandue d'IPSec.
De nombreux mécanismes de sécurité ont été proposés pour les réseaux fixes et mobiles. Bien que ces mécanismes aient pu répondre à un ensemble d'exigences de sécurité, ils demeurent uniquement efficaces dans un contexte spécifique lié aux hypothèses et aux exigences restrictives qui ont été émises lors de la conception.
Dans le chapitre I, nous avions pour but de définir une liste d'exigences en sécurité qui permet d'analyser les trois solutions de sécurité les plus déployées, a savoir les protocoles SSL/TLS, IPSec et SSH. Ceci nous a permis de comparer ces protocoles et de pouvoir arborer d'une part, leurs avantages et inconvénients et d'autre part, les exigences qu'ils ne peuvent pas satisfaire.
Le chapitre II a décrit les technologies et services permettant de faire la connectivité d'un réseau. Les dispositifs utilisés lors de la connectivité sont tout d'abord présentés ;
Le chapitre III traite la connectivité dans les infrastructures critiques par l'utilisation des méthodes efficaces et des technologies sécurisées et fonctionnant en temps réel. La connectivité à Internet par satellite a été traitée comme un exemple d'infrastructure critique.
Le chapitre IV consiste a changer la phase d'initialisation du protocole SSL/TLS. Nous avons proposé de remplacer le protocole Handshake de SSL/TLS par le protocole de gestion des clés ISAKMP utilisé actuellement avec le protocole IPSec. L'intérêt de ce travail est de fournir, entre autres, l'unification des associations de sécurité et la mise en épreuve du protocole ISAKMP. Il permet aussi à SSL/TLS de fournir de nouveaux services tels que la protection d'identité et l'authentification par des clés partagées.
Dans le dernier chapitre, la gestion de la sécurité a été présentée. Les différentes étapes liées à la conception et la réalisation de cet objectif ont été traitées. Plusieurs perspectives peuvent être avancées a l'issue de cette étude. La gestion de la sécurité en respectant la qualité de service serait une première amélioration. Aussi, la proposition des architectures matérielles pour sécuriser les systèmes embarqués serait un deuxième point.
Toute fois, dans l'intérêt d'améliorer ce mémoire, nous sommes disposés à recevoir des éventuelles remarques et suggestions, car dit-on qu'une oeuvre humaine ne jamais parfaite.
ADSL : Asymmetrical Digital Subscriber Line
AES : Advanced Encryption Standard
AH : Authentication Header
ARPA : Advanced Research Project Agency
ASN.1 : Abstract Syntax Notation
ATM : Asynchronous Transfer Mode
CCS : Change Cipher Spec
CERN : Conseil Européen pour la Recherche Nucléaire
CHAP : Challenge Handshake Authentication Protocol
CMS/PKCS7 : Cryptographic Message Syntax/Public Key Crypto-System
CSMA/CD : Carrier Sense Multiple Access/Collision Detection
DECnet : Digital Equipment Corporation
DES : Data Encryptions Standard
DH : Diffie and Hellman Algorithm
DMZ : DeMilitarized Zone
DNS : Domain Name Server
DOI : Domain of Interpretation
DSSS : Direct Sequence Spread Spectrum
ESP : Encapsulating Security Payload
FAI : Fournisseur d'Accès a Internet
FTP : File transfer Protocol
FW : FireWall
H-IDS : Host Based Intrusion Detection system
HMAC : Keyed-Hashing Message Authentication
HTML : Hyper Text Markup Language
HTTP : Hyper Text Transfer Protocol
IAB : Internet Architecture Board
IANA : Internet Assigned Numbers Authority
ICMP : Internet Control Message Protocol
ICP : Infrastructure à Clé Publique
IDS : Network Based Intrusion Detection system
IETF : Internet Engineering Task Force
IKE : Internet Key Exchange
IMAP : Internet Message Access Protocol
IP : Internet Protocol
IPSec : Internet Protocol Security
IPv4 : Internet Protocol version 4
IPv6 : Internet Protocol version 6
IPX : Inter-network Packet eXchange
ISAKMP : Internet Security Association and Key Management Protocol
ISDN : Integrated Handshake Authentication Protocol
ISOC : Internet Society
KE : Key Exchange
LCA : Liste de Contrôle d'Accès
LDAP : Lightweight Directory Access Protocol
LLC : Logical Link Control
MAC : Message Authentication Code
MD5 : Message digest 5
MIME : Multipurpose Internet Mail Extensions
N-ESP : Encapsulating Security Payload
NAT : Network Address Translation
NSA : National Security Agency
NSF : National Science Foundation
OSI : Open System Interconnect
OSPF : Open Shortest Path First
PPP : Point to Point Protocol
PAP : Password Authentication Protocol
PFS : Perfect Forward Secrecy
PGP : Pretty Good Privacy
PKI : Public Key Infrastructure
POP : Post Office Protocol
PPTP : Point to Point Tunneling Protocol
QoS : Quality Of Service
RADIUS : Remote Authentication Dial-In User Service
RFC : Request For Comment
RIP : Routing Information Protocol
RSA : Rivest, Shamir and Adelman
RSVP : Ressource reSerVation Protocol
S/MIME : Secure Multi-purpose Internet
SA : Security Association
SAD : Security Association Data base
SMTP : Simple Mail Transfer Protocol
SPD : Security Policy Data base
SPI : Security Parameter Index
SPX/IPX : Sequence Packet eXchange/Inter-network Packet eXchange
SSH : Secure SHell
SSL : Secure Socket Layer
SSL/TLS : Socket Secure Layer/Transport Layer Security
TCP : Transmission Control Protocol
TCP/IP : Transmission Control Protocol/Internet Protocol
TELNET : TErminaL NETwork protocol
TFTP : Trivial File Transfer Protocol
TLS : Transport Layer Security
UCLA : Université de Californie à Los Angeles
UDP : User Datagramm Protocol
URL : Uniform Resource Locator
VPN : Virtual private network
W3C : World Wide Web Consortium
WAN : Wide Area Network
X.500 : Norme proposé par l'ITU - T, ISO (annuaires).
X.509 : Norme du certificat numérique propose par l'ITU-T, ISO.
xDSL : x Digital Subscriber Line
XML : eXtensible Markup Language
I. OUVRAGES
[1] A. DESEINE, Accéder à Internet via ADSL, Paris, Janvier 2001 ;
[2] B. SCHNEIER, Applied Cryptography : Protocols, Algorithms, and Source Code in C, 2nd edition. Published by John Wiley & Sons, 1995 ;
[3] FRANCE TELECOM, l'Internet vraiment très haut débit, Paris, le 9 mai 2001 ;
[4] G. LABOURET et H. SCHAUER CONSULTANTS, La sécurité réseau avec IPSec, 75001 Paris, le 24 avril 2003 ;
[5] GOUVERNEMENT DU CANADA, Guide de la gestion des risques d'atteinte a la sécurité des technologies de l'information (MG-2), service CST, janvier 1996 ;
[6] I. HAJJEH, Sécurité des échanges, conception et validation d'un nouveau protocole pour la sécurisation des échanges, Thèse de doctorat, Ecole nationale supérieure des télécommunications de Paris, décembre 2004 ;
[7] I. BOU AKL, Etude des protocoles et infrastructures de sécurité dans les réseaux, DEA d'Informatique, Université Paul Sabatier, 2005-2006 ;
[8] O. ANDRIEU, Internet guide de connexion, Eyrolles, 3ème édition 1997-ISBN ;
[9] S. BLAKE-WILSON, M. NYSTROM et AL, Transport Layer Security (TLS) Extensions, IETF RFC No. 3546, June 2003.
II. SITE INTERNET
[1] http : // www.cert-i-care.org.
EPIGRAPHE 2
DEDICACE 3
REMERCIEMENTS 4
INTRODUCTION GENERALE 5
I. PRESENTATION GENERALE ET HISTORIQUE DU SUJET 5
II. PROBLEMATIQUE 5
III. OBJECTIF 6
IV. INTERET SCIENTIFIQUE 6
V. TECHNIQUES ET METHODOLOGIE SUIVIE 7
VI. SUBDIVISION DU MEMOIRE 7
CHAPITRE I. DEFINITION DES EXIGENCES POUR LES PROTOCOLES DE SECURITE 8
I.1. INTRODUCTION 8
I.2. EXIGENCES EN TERMES DE SECURITE 8
I.2.1. Choix des mécanismes cryptographiques 8
I.2.2. Authentification et l'identification . 9
I.2.3. Intégrité 9
I.2.4. Confidentialité 10
I.2.5. Non répudiation 10
I.2.6. Protection contre les attaques actives et passives 11
I.2.7. Protection d'identité 12
I.2.8. Confiance entre les communicateurs 13
I.2.9. L'autorisation . 14
I.2.10. Gestion des clés 15
I.2.11. Mise en oeuvre d'un VPN 15
I.2.12. Contrôle d'accqs 16
I.2.13. Gestion des «délégations» entre acteurs 18
I.3. CONCLUSION 19
CHAPITRE II. TECHNOLOGIES ET SERVICES POUR LA CONNECTIVITE 20
II. 1. INTRODUCTION 20
II.2. DISPOSITIFS DE CONNECTIVITE DES RESEAUX 20
II.2.1. Généralités 20
II.2.2. Avantages de l'extension d'un réseau local . 20
II.2.3. Différents dispositifs de la connectivité 21
II.3. MISE EN PLACE D'UN SERVEUR PROXY 25
II.3.1. Considération 25
II.3.2. Principe de fonctionnement d'un proxy 26
II.3.3. Fonctionnalités d'un serveur proxy 26
II.4. METTRE EN PLACE DES CACHES WEB DISTRIBUES 27
II.5. PROTOCOLES TCP/IP ET INTERNET 27
II.5.1. TCP/IP 27
II.6. CONCLUSION 31
CHAPITRE III. INTEGRATION D'ISAKMP DANS SSL/TLS 32
III.1. INTRODUCTION 32
III.2. MOTIVATIONS 32
III.2. INTEGRATION D'ISAKMP DANS SSL/TLS 34
III.2.1. Contraintes de base 34
III.2.2. Architecture 35
III.2.3. Négociation des associations de sécurité 36
III.2.4. ISAKMP et le protocole Record de SSL/TLS 39
III.2.5. ISAKMP et TLS Extensions 39
III.2.6. Procédure pour la définition de nouvelles extensions 39
III.6. CONCLUSION 40
CHAPITRE IV. CONNECTIVITE DANS LES INFRASTRUCTURES CRITIQUES 42
IV.1. INTRODUCTION 42
IV.2. UN DEBIT ELEVE ET LA TECHNOLOGIE MULTIPLEXAGE EN LONGUEUR
D'ONDE 42
IV.3. ADSL 43
IV.3.1. Présentation 43
IV.3.2. Technologie ADSL 43
IV.3.3. Offre ADSL 44
IV.4. VPN 46
IV.4.1. Présentation 46
IV.4.2. Tunnel 46
IV.5. ASSURER UNE QUALITE DE SERVICE A LA DEMANDE 47
IV.5.1. Réseau multimédia 47
IV.5.2. Solutions de la QoS 48
IV.6. INTERNET PAR SATELLITE 49
IV.6.1. Considération générale 49
IV.6.2. Equipement nécessaire 50
IV.6.3. Fonctionnement 50
IV.6.4. Serveurs Proxy 50
IV.6.5. Push 51
IV.6.6. Débits 51
IV.7. CONCLUSION 51
CHAPITRE V. GESTION DE LA SECURITE 52
V.1. INTRODUCTION 52
V.2. DISPOSITIFS DE LA SECURITE 52
V.2.1. Pare-feu 52
V.2.2. Systèmes de détection et de prévention de l'intrusion 54
V.3. VPN 55
V.3.1. Principe 55
V.3.2. Exemples de déploiements : Réseaux privés virtuels, Extranet, Serveurs
Protégés, etc. 56
V.3.3. Protocole IPSec 58
V.3.4. Protocoles ISAKMP et IKEv1 65
V.3.5. Protocole SSL/TLS 71
V.3.6. Protocole Handshake 73
V.3.7. Utilisation d'IPSec et SSL 76
V.4. SYSTEME VPN BIEN ADMINISTRE 77
V.5. CONCLUSION 78
CONCLUSION GENERALE 79
LISTE DES ABREVIATIONS ET ACRONYMES 80
BIBLIOGRAPHIE 83
TABLE DE MATIERES 84
