Autres moyens de la sécurité
publicité
Rappel: Utilités la sécurité à tous les niveaux Sécurité des RO Partie 6 Application : S-MIME, PGP, Sbox, OTP Présentation SSH Session : SHTTP Transport : SSL, TLS Sécurisation des échanges Réseau : authentification IP (IPsec) Liaison : CHAP, PAP Liaison physique : Bluetooth SSL, TLS, SHTTP IpSec Boîtier de chiffrement Anas ABOU EL KALAM [email protected] Anas Abou El Kalam 2 SSL : Introduction Plan SSL • SSL défini par netsacpe et intégré au browser • Première version de SSL testé en interne • Première version de SSL diffusé : V2 (1994) • Version actuelle V3 • Standard à l’IETF au sein du groupe Transport Layer Security (TLS) • Standard au sein du WAP Forum Wireless Transport Layer Security (WTLS) SSH IPSec VPN S-MIME PGP Anas Abou El Kalam 3 Anas Abou El Kalam 4 SSL / TLS : caractéristiques SSL : Architecture Repose sur un procédé de crypto à clès publiques Indépendant du protocole utilisé NFS – transactions Web (HTTP), connexions via FTP, POP ou IMAP. – Agit telle une couche supplémentaire, permettant d'assurer la sécurité des données, située entre couches Appli & transport FTP SMTP HTTP Transparent pour l'utilisateur Supporté par la quasi totalité des navigateurs SSL Serveur sécurisé par SSL URL commençant par https:// Confidentialité Algo symétriques (3DES, IDEA, 9RC4) Intégrité MAC (MD5 ou SHA) Authentification X509 et MAC TCP Port Protocolenon sécurisé SNMP RPC UDP 6 Anas Abou El Kalam Ports au dessus de SSL (2/2) Ports au dessus de SSL (1/2) Protocole sécurisé XDR IP 5 Anas Abou El Kalam Telnet Application Protocole sécurisé Port Protocolenon sécurisé Application HTTPS 443 HTTP Transactions requêteréponse sécurisées FTP-DATA 889 FTP Transfert de fichiers SSMTP 465 SMTP Messagerie électronique FTPS 990 FTP Contrôle du transfert de fichiers SNNTP 563 NNTP News sur le réseau Internet IMAPS 991 IMAP4 Accès distant à la boîte aux lettres avec ou sans rapatriement des messages SSL-LDAP 636 LDAP Annuaire X.500 allégé TELNETS 992 Telnet Protocole d’accès distant à un système informatique SPOP3 995 POP3 Accès distant à la boîte aux lettres avec rapatriement des messages IRCS 993 IRC Protocole de conférence par l’écrit Anas Abou El Kalam 7 Anas Abou El Kalam 8 SSL : propriétés / services SSL : Protocoles • Authentification – Serveur (obligatoire), client (optionnel) – Utilisation de certificat X509 V3 – A l’établissement de la session. • Confidentialité – Algorithme de chiffrement symétrique négocié, clé généré à l’établissement de la session. • Intégrité – Fonction de hachage avec clé secrète : hmac(clé secrète, h, Message) • Non Rejeu – Numéro de séquence Anas Abou El Kalam Application SSL Alert CCS Record TCP 9 SSL / TLS : fonctionnement globale Anas Abou El Kalam 10 TLS : négociation de session Une session définit les éléments suivants : échange de clés entre client & serveur. – Le client, se connecte au site (marchand) sécurisé par SSL et lui demande de s'authentifier. Le client envoie également la liste des cryptosystèmes qu'il supporte, triée par ordre décroissant de la longueur des clés. – Le serveur a réception de la requête envoie un certificat au client, contenant la clé publique du serveur, signée par une CA, ainsi que nom d’algo le plus haut dans la liste avec lequel il est compatible – Le client vérifie validité certificat (i.e., authenticité marchand), puis – Le client crée une clé secrète aléatoire, chiffre cette clé à l'aide de la clé publique du serveur, puis lui envoie clé de session. session – Le serveur est en mesure de déchiffrer la clé de session avec sa clé privée. Les deux entités sont en possession d'une clé commune dont ils sont seuls connaisseurs. Le reste des transactions peut se faire à l'aide de clé de session, garantissant l'intégrité et la confidentialité des données échangées. Anas Abou El Kalam Handshake – identifiant de session – algorithme de compression – algorithme de chiffrement, type d ’algorithme de chiffrement : (par blocs, flux), taille de la clé de chiffrement – algorithme de scellement, taille du sceau – secret maître – aléa serveur, aléa client – certificat – session réutilisable Clés utilisées : – secret maître, – aléas serveur et client permettent de calculer la clé de chiffrement et – clé de scellement. 11 Anas Abou El Kalam 12 TLS : négociation de session TLS : négociation de session Décider du niveau de sécurité (suivant les capacités de chacun) Toute communication sécurisée débute par une négociation de session «TLS Handshake protocol» Format des trames de négociation : Type Taille Le serveur s’authentifie et envoie les paramètres permettant d ’établir un pré-secret maître Contenu Type : hello_request (0), client_hello (1), server_hello (2) ... Objectif • Authentification du serveur et éventuellement du client, • Négociation des algorithmes de chiffrement et de hachage, échange d’un secret, • Génération des clés. Anas Abou El Kalam Le client s ’authentifie (si requis) et envoie les paramètres permettant d ’établir un pré-secret maître Fin négociation de session Client & serveur converseront désormais avec algos et clés de sécurité établies Anas Abou El Kalam 13 La négociation de session TLS 14 Handshake Message Typede message Sens de transmission Signification HelloRequest optionnel serveur → client Ce message demande au client d'entamer le Handshake. ClientHello obligatoire client → serveur Ce message contient : le numéro de version du protocole SSL ; le nombre aléatoire : client_random ; l'identificateur de session : session_ID ; la liste des suites de chiffrement choisies par le client ; la liste des méthodes de compression choisies par le client. ServerHello obligatoire serveur → client Ce message contient : le numéro de version du protocole SSL ; un nombre aléatoire : serveur_random ; l'identificateur de session : session_ID ; une suite de chiffrement ; une méthode de compression. Anas Abou El Kalam 15 Anas Abou El Kalam 16 Handshake Handshake Certificate Optionnel serveur → client client → serveur Ce message contient le certificat du serveur ou celui du client si le serveur le lui réclame et que le client en possède un. ClientKeyExchange Obligatoire client → serveur Ce message contient le PreMasterSecret crypté à l’aide de la clé publique du serveur. CertificateVerify Optionnel client → serveur Ce message permet une vérification explicite du certificat du client. Finished obligatoire serveur → client Ce message signale la fin du protocole Handshake et le début de l’émission des données protégées avec les nouveaux paramètres négociés. ServerKeyExchange Optionnel serveur → client Ce message est envoyé par le serveur que s’il ne possède aucun certificat, ou seulement un certificat de signature. CertificateRequest Optionnel serveur → client Par ce message, le serveur réclame un certificat au client. ServerHelloDone Obligatoire serveur → client Ce message signale la fin de l’envoi des messages ServerHello et subséquents. client → serveur 17 Anas Abou El Kalam 18 Anas Abou El Kalam Handshake Handshake Ouverture d'une connexion Ouverture d'une session SSLv3 Client Serveur Client Serveur Client Hello Client Hello Serveur Hello Certificate (Serveur Key Exchange) (Certificate Request) Server Hello Done Serveur Hello ChangeCipherSpec Finished (Certificate) Client Key Exchange (Certificate Verify) ChangeCipherSpec Finished ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data Application Data Anas Abou El Kalam 19 Anas Abou El Kalam 20 La négociation de session TLS La négociation de session TLS 2ème phase : authentification (optionnelle) du Client 1ère phase : authentification serveur Suite à la requête d'un C, le S : Serveur – envoie son certificat au C – liste algos cryptos, qu'il souhaite négocier – peut demander au client de s'authentifier en lui demandant son certificat. Le C – vérifie validité certificat à l'aide Kpub du CA – Si le certificat est valide, le client génère un pré-master secret (PMS) de 48 octets – Le PMS servira à dériver le MS (48 octets) – PMS est chiffré avec clé publique du S puis transmis à ce dernier. Client – réplique en envoyant ce certificat puis – en signant un message avec sa clé privée (ce message contient des informations sur la session et le contenu de tous les échanges précédents) Données échangées par la suite entre C/S sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître. Anas Abou El Kalam Remarque : Clé publique serveur chiffrement Clé privée du client signature 21 La négociation de session TLS Anas Abou El Kalam 22 La négociation de session TLS Client Hello Server certificate – heure – tirage nbre aléatoire client.random (28 octets) – session Id : • vide = nouvelle session, • renseigné = utiliser session déjà ouverte – choix d’algorithmes de chiffrement supportés – méthode de compression supportés – n° version du client SSL utilisé – envoyé si le serveur doit s’authentifier, dès que Server Hello a été envoyé – contient une chaîne de certificats X509 v3 (avec le certificat racine en dernier), correspond à l’algo utilisé (RSA, DH, 9) ⇒le client dispose donc de la clé publique du serveur Server Hello Server key exchange – le serveur sélectionne la version – tirage nbre aléatoire : server.random (28 oct) – session Id : • renseigné = N° nouvelle session ou session à réutiliser , • vide = session à ne pas mettre en cache – algorithme de chiffrement sélectionné – méthode de compression à utiliser Si session réutilisée, passer en FINISH Anas Abou El Kalam – envoyé uniquement si le client n’a pas toutes les données nécessaires (ex: le serveur n’a pas de certificat) – paramètres de la clé de chiffrement (modulo, exposant9) – hash MD5/SHA (client.random + server.random+paramètres) 23 Anas Abou El Kalam 24 La négociation de session TLS La négociation de session TLS Certificate request Clé publique – envoyé uniquement si l’authentification du client est requise – types de certificats admis – noms d’autorités de certification reconnues du serveur N° version Pre Master Secret Key RSA Client key exchange Server hello done Client Key Exchange – dans le cas de l’algorithme RSA, le client génère un “pre-master secret” de 46 octets + 2 octets n° version (pour détecter les « rollback attacks ») – il chiffre ce pre-master secret avec la clé publique du serveur – le serveur attend une réponse du client Client certificate – envoyé uniquement si le serveur a réclamé une authentification du client – certificat – si le client ne possède pas de certificat, une alerte est envoyée au serveur. • Suivant les cas, cela peut faire échouer la négociation Anas Abou El Kalam Pre Master Secret Key sécurisé Calcul des clés – le pre-master secret, client.random et server.random permettent au client et au serveur de calculer • 2 clés de sessions (une pour chaque sens), et • 2 clés secrètes à utiliser pour les MACs. 25 La négociation de session TLS Anas Abou El Kalam 26 TLS : génération des clés Certificate verify Utilisation d’une fonction de génération de nombres pseudo aléatoires (PRF) – envoyé si le client a envoyé un certificat qui permet de signer – hash MD5 et hash SHA de tous les messages de négociation envoyés jusqu’ici – permet de convenir de secrets relativement courts et de générer des clés bien plus longues – l ’utilisation de deux algorithmes de hash différents augmente la sécurité Client Finish et Server Finish – envoyé après un Change Cipher Spec • et donc chiffré avec les nouveaux algorithmes négociés. – client et serveur doivent envoyer un “Finish” et vérifier celui qu’il reçoive de la partie opposée. – PRF(master_secret,finished_label, Hash MD5 +Hash SHA de tous les messages de négociations envoyés jusqu’ici) sur 12 octets, – finished_label = “client finished” ou “server finished”. Anas Abou El Kalam PRF(secret,chaine ASCII,sel)=P_MD5(moitié_secret,chaine+sel) XOR P_SHA(autre moitié_secret,chaine+sel) P_hash(secret,sel)=HMAC_hash(secret,A(1)+sel)+ HMAC_hash(secret,A(2)+sel)+ … où A(0)=sel et pour i>0 A(i)= HMAC_hash(secret,A(i-1) 27 Anas Abou El Kalam 28 TLS : pile de protocole TLS : génération des clés Quatre Protocoles Génération du secret maître à partir de : – – – – Pré secret maître établi par le client (client key exchange) des aléas serveur et client de la chaîne ASCII « master_key » effacer le pré secret maître de la mémoire Génération d’un bloc de clés à partir de : – – – – secret maître des aléas serveur et client de la chaîne ASCII « key expansion » générer un bloc de taille suffisante (PRF) et le découper pour obtenir la clé de scellement client, serveur, clé de chiffrement client et serveur, vecteurs d ’initialisation client et serveur (chiffrement par blocs) Anas Abou El Kalam 29 ChangeCipherSpec (CCS) Handshake – authentification mutuelle C/S – négociation algos chiffrement, TLS Modif hachage, échange clés symétriques TLS Cipher TLS Alert HTTP Handshake Change Cipher Spec spec Protocol Protocol protocol – Notif du S que tous messages qui vont suivre message “Client TLS Record Protocol Finished” seront chiffrés avec clés / algos négociés. TCP Alert – Alertes qui peuvent être envoyés IP par chacunedes parties suite aux evnt qui peuvent subvenir Record – sécurité des données HTTP – sécurité des autres couches de protocoles TLS Anas Abou El Kalam 30 Le protocole Record • ChangeCipherSpec signale au Record toute modification des paramètres de sécurité, • Reçoit les données des couches supérieures: (Handshake, Alert, CCS, HTTP, FTP ...), et les transmet au protocole TCP. • Constitué d’un message (1 octet) • Après application de : la fragmentation des données en blocs de taille maximum de 214 octets la compression des données, fonction prévue mais non supportée actuellement la génération d’un condensât pour assurer le service d’intégrité le chiffrement des données pour assurer le service de confidentialité Anas Abou El Kalam 31 Anas Abou El Kalam 32 Le protocole Alert (2) Le protocole Alert • Le protocole Alert peut être invoqué: Message par l’application, par exemple pour signaler la fin d’une connexion par le protocole Handshake suite à un problème survenu au cours de son déroulement • par la couche Record directement, par exemple si l'intégrité d'un message est mise en doute Anas Abou El Kalam Contexte Type bad_certificate échec de vérification d’un certificat fatal bad_record_mac réception d’un MAC erroné fatal certificate_expired certificat périmé fatal certificate_revoked certificat mis en opposition (révoqué) fatal certificate_unknown certificat invalide pour d’autres motifs que ceux précisés précédemment fatal close_notify interruption volontaire de session fatal decompression_failure les données appliquées à la fonction de décompression sont invalides (par exemple, trop longues) fatal handshake_ failure impossibilité de négocier des paramètres satisfaisants fatal illegal_parameter un paramètre échangé au cours du protocole Handshake dépasse les bornes admises ou ne concorde pas avec les autres paramètres fatal no_certificate réponse négative à une requête de certificat avertissement ou fatal unexpected_message arrivée inopportune d’un message fatal unsupported_certificate le certificat reçu n’est pas reconnu par le destinataire avertissement ou fatal 33 34 Anas Abou El Kalam TLS : traitement des données TLS : traitement des données Données applicatives Fragmentation : Fragmentation (214 octets maxi) Fragment 1 – frontières messages clients peuvent être déplacées Données applicatives – fragments de 214 octets au plus Fragment 2 Compression (optionnelle) : Compression (ajoute 1024 octets maxi) – ajoute au pire 1024 octets – sans pertes Compressé Frag 2 Compressé Sceau : – HMAC(MAC_write_secret,seq_num+type de protocole TLS+version TLS+taille du fragment compressé+fragment compressé) – + = concaténation Scellement (HMAC) Compressé Frag 1 MAC Chiffrement : Chiffrement (ajoute 2048 octets maxi) Fragment Chiffré – le fragment peut être paddé (chiffrement par blocs) – on chiffre le fragment compressé + MAC – ajoute au pire 1024 octets Fragment Chiffré Anas Abou El Kalam Compressé MAC 35 Anas Abou El Kalam 36 TLS : PDU (Protocol Data Unit) de données Type de protocole : Type Maj Min – TLS Cipher Change Protocol (20) – TLS Alert Protocol (21) – TLS Handshake Protocol (22) – données applicatives (23) Taille Données (compressées) chiffré MAC Version : 3.1 Taille : – taille des données chiffrées (214+2048 max). Anas Abou El Kalam TLS : protocole d ’alerte Niveau d’alerte : – avertissement – fatal Message : – fermeture de session – mauvais format de message – MAC erroné, erreur de déchiffrement, erreur de décompression – overflow (message trop long) – mauvais certificat – ... 37 Var d’état d’une session TLS Niveau Description PDU alerte Anas Abou El Kalam 38 Var d’état d’une connexion TLS Les paramètres qui définissent une connexion SSL sont ceux qui se seront rafraîchis pendant une session lors d'établissement d'une nouvelle connexion : Session ID (l'dentifiant de session) – séquence aléatoire de 32 octets choisie par le serveur pour identifier session. Peer certificate (le certificat du pair) Server_random et Client_random – deux nombres aléatoires de 32 octets, générés par le C et le S lors de chaque connexion – c'est un certificat X 509 du correspondant (soit pour un serveur ou un client). Server_MAC_write_secret Compression method – clé secrète utilisé par le serveur pour calculer les MACs Client_MAC_write_secret – Algo de compression utilisé – clé secrète utilisé par le client pour calculer les MACs Cipher spec (suite de chiffrement) Server_write_key – définit les algorithmes de chiffrement et de hachage – clé symétrique utilisé par le serveur pour le chiffrement des données. MasterSecret Client_write_key – clé de 48 octets partagée entre le client et le serveur. – clé symétrique utilisé par le client pour le chiffrement des données. Is resumable (le drapeau) Initialization vectors – flag qui indique si il est possible d'ouvrir de nouvelles connexions sur la session en question – vecteur d'initialisation pour le chiffrement par bloc en mode CBC (Cipher Bloc Chaining), l'un du coté serveur et l'autre du coté client. Sequence number – chaque message est numéroté, l'un pour le S, l'autre par le C, et chacun codé sur 8 octets. Anas Abou El Kalam 39 Anas Abou El Kalam 40 SSL : liste non exhaustive de serveur SSL : charges Nom de l’API Opération Temps decalcul pour leclient (ms) Temps decalcul pour le serveur (ms) Total (ms) Ouverture d’une nouvelle session (Handshake complet) 18,94 16,9 35,85 Rafraîchissement d'une session (Handshake simplifié) 0,11 0,11 0,22 Ouverture d’une nouvelle connexion 0,079 0,071 0,15 5,5 5,3 10,8 http://www.aolserver.com Alibaba2.0 Computer Software Manufacturers http://www.csm.co.at/alibaba/ Apache 1.3 The Apache Group http://www.inetmi.com Enterprise Server 3.0 http://www.novonyx.com Novonyx Enterprise Web Secure/VM 1.1 Beyond-Software Incorporated http://www.beyond-software.com Internet Information Server 4.0 MicrosoftCorp. Sun Microsystems Lotus Domino Go WebserverIBM 4.6.1 http://www.oracle.com/products Roxen Challenger 1.2b I Idonex http://www.roxen.com SSLava Phaos Technologies http://www.phaos.com/main.htm WebSite Professional 2.2 O'Reilly Software http://www.website.oreilly.com/ WebTen 2.1 Tenon Intersystems RSA RC4-40 MD5 RC4-128 MD5 0x04 RC4- 128 SHA 0x05 0x06 0x07 DES40 CBC SHA DH et DSA 0x08 0x09 0x0A 0x0B DES CBC SHA 0x0C 3DES EDE CBC SHA 0x0D DES40 CBC SHA DH et RSA 0x0E 0x0F 3DES EDE CBC SHA 0x10 0x11 DES CBC SHA 0x12 3DES EDE CBC SHA 0x13 DES40 CBC SHA DHE et RSA DES CBC SHA DES40 CBC SHA DHE et DSA 3DES EDE CBC SHA DES40 CBC SHA 0x14 0x15 3DES EDE CBC SHA 0x16 Anas Abou El Kalam – – – – Casser les clefs Attack replay Man in the middle Attaque à clair ouvert • Parades de SSL – – – – DES CBC SHA Beta 1 DESCBC SHA 42 • Pistes classiques IDEA CBC SHA Anas Abou El Kalam SSLava Code 0x03 RC2 CBC-40 MD5 http://www.tenon.com/products/webten http://www.zeustech.net Attaques classiques SSL : liste de suite de chiffrement supportée par un serveur Export http://www.java.sun.com http://www.ibm.com OracleWeb Application Server Oracle Corp. 3.01 41 Apache Jigsaw Microsoft Netscape Netscape SSLLeay 08.0 2.0 Beta 1 IIS/4.0 Entreprise3.0L Entreprise 3.0F http://www.microsoft.com/iis Netscape Enterprise Server 3.5.1 Netscape Communications Corp. http://www. netscape.com Anas Abou El Kalam Suite http://www.apache.org Commerce Server/400 1.0CI/NET, Inc. Zeus Web Application Server Zeus 3 Technology Serveur et Version Adresse America Online. Inc Java Server 1.1 Temps de calcul pour 16Ko de données (chiffrement ou déchiffrement, élaboration et vérification du MAC) Fournisseur AOLserver 2.3 43 Taille des clefs Nonces (connection id) Certificats servent à passer les clefs Clefs + Aléas Anas Abou El Kalam 44 Sources de vulnérabilité Scénarios d’attaque • Taille des clefs • • • • • SSL v2 • Certificats SSL v2 : Forcer une faible taille de clef Tous : Diffie-Hellman anonyme SSL v3 : Accepte Finished avant ChangeCipherSpec SSL v3 : Envoi de données chiffrées avant réponse serveur au Finished. • Implémentations 45 Anas Abou El Kalam 46 Anas Abou El Kalam Exemple 2 Exemple 1 • Faible clefs • Pas de vérification d’intégrité • Tiers à l’écoute SSL v2 Forced weak ciphersuite CryptoL SSL v3 DH anonymous authentification “ Man in the middle ” attack CryptoL Anas Abou El Kalam 47 Anas Abou El Kalam 48 Exemple 3 Exemple 4 Phase 1 • Envoi de données chiffrées • Permet de casser la clef, puis de répondre Phase 2 SSL v3 Send data before finished server ? Anas Abou El Kalam 49 SSL vs TLS ? 50 Anas Abou El Kalam SSL vs SSH ? Différences minimes : – TLS = « SSL v3.1 » ==> basé sur SSL 3.0 – Même si à la fois SSL et TLS sont dispo dans la majorité des navigateurs, ils ne s'intorpére pas SSH SSL / TLS programme et protocole de connexion et d'exécution de commande sur ordi accessible depuis un réseau Les connexions SSH doivent être authentifiées propose de nombreuses autres options • un seul doit être choisi dans la phase de négociation • Mais TLS peut se trensformer en SSL3 si nécessaire – TLS Record Protocol utilise HMAC pour sceller les données – Avec TLS, taille padding des données « imprévisible » (jusqu ’à 255 octets), tandis qu ’avec SSL, cette taille était prévisible (juste ce qui est nécessaire pour être multiple taille du bloc de chiffrement) – TLS utilise une fonction de génération pseudo-aléatoire (PRF) là où SSL utilisait des imbrications de hash MD5 et SHA – TLS ne supporte pas Fortezza comme algo d ’échange de clés. protocole de sécurisation des communications Internet ne requiert aucune authentification côté serveur : celleci est optionnelle, et une connexion peut être anonyme authentification côté client que par échange de clefs publiques peut-être utilisé dans un cadre autre que le se limite au protocole HTTP (en fait HTTPS, qui est Web pur : FTP, POP3 / IMAP / SMTP, telnet HTTP sécurisé par SSL) permet de son côté de créer un "tunnel" entre SSL/TLS n'est utile qu'en cas d'échange entre deux applications ces deux applications, qui reste ouvert et disponible même s'il n'y pas d'échange en cours. permet de sécuriser le transport d'informations via le SSH est une véritable plate-forme de Web sécurisation pour toutes formes de communications électroniques. Anciennes versions de SSL : – rollback attack étudiée – tous les messages de négociation sont scellés (pas en v2.0) Anas Abou El Kalam 51 Anas Abou El Kalam 52 TLS : conclusion Plan SSL Avantages SSH – Protocole assez bien pensé et complet – Supportés par de nombreux navigateurs et donc + ou - “standard” IPSec Inconvénients – On n’est pas averti si le certificat utilisé est répudié – Lourd ? – La renégociation de sessions n’est pas prévue, or sur un ftp ou un telnet, une session peut rester ouverte très longtemps – Les algorithmes de chiffrement négociés peuvent être un peu faibles (RC4-40 bits notamment). VPN S-MIME PGP Anas Abou El Kalam 53 Sécurisation des échanges : SSH 54 Anas Abou El Kalam Sécurisation des échanges : SSH Intro Apperçu (simplifié) du protocole – remplacement sécurisé des commandes telnet, rlogin, rsh et rcp d’Unix 1. Négociation de la version du protocole – Utilise SSL 2. Identification de l’hôte distant (RSA) – fonctions supplémentaires 3. Négociation de l’algorithme de chiffrement (3DES, Blowfish, IDEA, ...) – authentification par clés publiques 4. Génération et échange d’une clé de chiffrement de session – tunnels 5. Authentification de l’utilisateur – Secure ftp (sftp) - soit par clé publique / privée - soit par login traditionnel Implémentations 6. Session établie à partir de cet instant, tous les échanges sont chiffrés la clé de session est générée à l’aide du protocole Diffie-Hellman – SSH (http://www.ssh.com) – OpenSSH (www.openssh.com) – ... Anas Abou El Kalam 55 Anas Abou El Kalam 56 Sécurisation des échanges : SSH Sécurisation des échanges : SSH Utilisation basique sous Unix Configuration la paire de clés est générée grâce à la commande ssh_keygen Clé publique du serveur UnUtilisateur[~] ssh toto.n7.fr non connue Host key not found from the list of known hosts. Clé publique du Are you sure you want to continue connecting (yes/no)? yes serveur Host 'toto.n7.fr' added to the list of known hosts. récupérée [email protected]'s password: XXXXXX Authentification par pwd Last login: Wed Aug 7 15:34:11 2002 from UnUtilisateur.n7.fr Sun Microsystems Inc. SunOS 5.7 Generic October 1998 Sun Microsystems Inc. SunOS 5.7 Generic October 1998 (ssh-keygen ssh-keygen -t rsa) rsa pour générer des clés RSA les clés publiques et privées du serveur sont en général stockées dans /etc/ssh à la 1ère connexion d’un utilisateur sur un serveur, la clé publique est récupérée et stockée dans $HOME/.ssh/known_hosts du client le démon s’exécutant sur une machine serveur est sshd la paire de clés d’un utilisateur se trouve en général dans $HOME/.ssh – (fichiers id_rsa et id_rsa.pub) => pour authentification des utilisateurs par clés toto[~] 57 Anas Abou El Kalam Sécurisation des échanges : SSH Anas Abou El Kalam 58 Sécurisation des échanges : SSH Tunneling Tunneling Très utile lorsque l’on veut établir une connexion sécurisée avec un serveur POP, IMAP par client[~] ssh -n -f serveurssh -L 1234:serveurimap:143 -N exemple et qu’on ne dispose pas d’une version de ce serveur intégrant les fonctionnalités SSL Client POP Serveur POP 1 Client SSH création du tunnel : le port local 1234 est donc redirigé sur le port 143 (IMAP) du serveurimap (la transaction est chiffrée jusqu’au serveurssh) 3 2 Communication chiffrée client[~] telnet localhost 1234 Trying 127.0.0.1... Serveur SSH Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] serveur IMAP4rev1 2002.325 at Wed, 7 Aug 2002 17:45:47 +0200 (CEST) 1. Le client SSH crée un serveur local 2. Le client SSH transmet les requêtes au serveur SSH 3. Le serveur SSH les redirige vers le vrai serveur Anas Abou El Kalam 59 Anas Abou El Kalam 60 Sécurisation des échanges : SSH Sécurisation des échanges : SSH Tunneling : un autre exemple Tunneling - Pour la lecture du courrier, le mieux est bien sûr de créer un tunnel en utilisant comme port local le même port que celui du service (IMAP ou POP), et ensuite de modifier les préférences du lecteur de courrier (127.0.0.1 pour le serveur IMAP) 1. création du tunnel : ssh -n -f serveurssh -L 143:serveurimap:143 -N 2. modification des préférences du lecteur de courrier (ici Netscape) le serveur IMAP est la machine locale Anas Abou El Kalam Certains sites ne sont accessibles que depuis certains ordis, serveurs ou domaines très précis. – Par exe, pour accéder à l'Intranet de l'N7, on doit se connecter depuis l'un des ordinateurs de l'École. – Cette contrainte permet d'être certain que seules les personnes autorisées pourront accéder à certaines données, après s'être préalablement identifiées au moyen d'un mot de passe. Mais cet avantage a un inconvénient. – Si vous êtes à l'étranger, ou si vous êtes tout simplement chez vous et ne pouvez vous rendre physiquement devant les ordinateurs en question, ces ressources vous sont inaccessibles... Solution ? – La technique du tunnel SSH : « creuser un tunnel » entre votre connexion et un serveur autorisé pour y faire passer les infos de manière sécurisée Etapes – 1. ouvrir une connexion sécurisée avec ce serveur (par ex java, à l'N7) – 2. dire à votre navigateur de se brancher sur cette connexion ; – 3. vous connecter à des sites comme si vous étiez sur ce serveur. 61 Sécurisation des échanges : SSH 62 Anas Abou El Kalam Sécurisation des échanges : SSH Ouvrir le Tunnel Ouvrir le Tunnel dans l'onglet « SSH » puis Tunnel : Sous Linux 1. Source Port : 3128 toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:[email protected] 2. destination : www-cache.n7.fr:3128 Sous Windows 3. Cliquer sur « Add » dans l'onglet « Session » : www-cache.n7.fr 1. Host name (or IP@) : java.n7.fr java.n7.fr 2. Port : 22 3. Protocole : SSH 4. Saved sessions : N7 par tunnel )7 par tunnel SSH L3128 www-cache.n7.fr:3128 SSH dans l'onglet «session » 1. cliquer sur « save » Anas Abou El Kalam 63 Anas Abou El Kalam 64 Sécurisation des échanges : SSH Sécurisation des échanges : SSH Empreinter le Tunnel Empreinter le Tunnel maintenant que le tunnel est ouvert, on peut l'emprunter Exemple de config avec IE – Allez dans Options, puis cliquez sur l'onglet Connections ; cliquez sur le bouton « Paramètres réseau », Exemple de config avec Firefox – Indiquez à votre navigateur que vous voulez utiliser un proxy, en cliquant sur « Manual proxy configuration », puis en tapant localhost comme proxy HTTP, et 3128 comme port : Cochez case « Utiliser un serveur proxy pour votre réseau local », et indiquez d'utiliser l'adresse localhost avec le port 3128 : Anas Abou El Kalam 65 Sécurisation des échanges : SSH Anas Abou El Kalam 66 Sécurisation des échanges : SSH Ouvrir le Tunnel Empreinter le Tunnel Sous Linux Maintenant, le tunnel est ouvert, et votre navigateur est disposé à l'emprunter. toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:[email protected] Demandez-lui d'aller à l'adresse http://www.intranet.n7.fr pour vérifier son bon Sous Windows fonctionnement. dans l'onglet « SSH » puis Tunnel : 1. Source Port : 3128 Reboucher le tunnel 2. destination : www-cache.n7.fr:3128 Quand vous empruntez un tunnel, en règle générale, n'oubliez pas d'en sortir... 3. Cliquer sur « Add » Dans le cas d'un tunnel SSH, il suffit pour cela de : 1. retourner dans les options de votre navigateur, et de lui indiquer de ne pas utiliser de proxy. 2. fermer la fenêtre de terminal avec laquelle vous avez ouvert le tunnel. www-cache.n7.fr Anas Abou El Kalam 67 Anas Abou El Kalam 68 IPSec : intro Plan Introduction – IPsec vise à sécuriser les échanges de données au niveau de la couche réseau (IP) – Un des méthodes permettant de créer des VPN, i.e., relier, de manière sûre, 2 systèmes en s'appuyant sur un réseau existant, lui-même considéré comme non sécurisé. – défini par un groupe de travail du même nom à l’IETF (Internet Engineering Task Force) – Services au niveau réseau – IPSec n’est pas un protocole fixe (ex: alg de chiffrement) – créé en 1992, première version en 1995 – intégré de base dans IPV6, doit être explicitement utilisé avec IPV4 SSL SSH IPSec Propriétés VPN confidentialité des données et protection contre l’analyse du trafic intégrité des données S-MIME authentification de l’origine des données protection contre le rejeu => IPSec n’est pas un protocole fixe (les algos de chiffrement et d'authentification à proprement parler sont spécifiés séparément du protocole lui-même.), – il s’agit d’un cadre pour implanter des services de sécurité PGP Anas Abou El Kalam 69 Composants crypto dans l’architecture Internet Anas Abou El Kalam 70 IPSec : Mécanismes 2 mécanismes de sécurité viennent s’ajouter au traitement IP classique – l’Authentication Header (AH AH) – l’Encapsulation Security Payload (ESP ESP) IPv6 : IPSec est supporté en natif dans IPv6; IPv4, IPv4 le champ Protocol du datagramme est modifié pour indiquer la présence d’une des 2 extensions – AH=51, ESP=50 AH et ESP contiendront eux-mêmes un champ Next Header qui indiquera le type du protocole (TCP, ...) initialement contenu dans le datagramme IP Anas Abou El Kalam 71 Anas Abou El Kalam 72 IPSec : les 2 modes d'échange Description des modes d'IPSec Mode transport – les mécanismes de sécurité ne sont appliqués qu’aux données de la couche supérieure et les informations relevant d’opérations sur la couche IP, telles que contenues dans l’entête IP, ne sont pas protégées. Mode tunnel Mode Transport : s'intercale entre le protocole réseau (IP) et le protocole de transport (TCP, UDP) – ne modifie pas l'en-tête initial – Plusieurs variantes – les données de la couche supérieure de même que l’en-tête d’IP du paquet IP sont protégées grâce à une encapsulation. Mode Tunnel : remplace les en-têtes IP originaux et Il est également possible d'encapsuler une communication IPsec en mode tunnel ou transport dans une autre communication IPsec en mode tunnel, elle-même traitée par une passerelle de sécurité, qui transmet les datagrammes après suppression de leur première enveloppe à encapsule la totalité du paquet IP; e.g., @ IPA externe pourra être celle de la passerelle de sécurité implémentant IPSec, et @ IPB interne sera celle de la machine finale, sur le réseau derrière la passerelle. un hôte traitant à son tour les protections restantes ou à une seconde passerelle de sécurité. Mode Nesting : hybride puisqu'il utilise les 2 modes Encapsuler de l'IPSec dans de l'IPSec 73 Anas Abou El Kalam Tunnel ==> encapsulation datagrammes IP dans d’autres... Cela permet de : – créer des réseaux privés virtuels (ou VPN). VPN Établir une communication sécurisée (le tunnel) entre des entités éloignées, séparées par un réseau non sécurisé/public (Internet), et ce de manière quasi-transparente. Datagramme IPSec Datagramme IP Datagramme IP Datagramme IP Tunnel IPSec Partie données du datagramme IPSec propriétés générales des tunnels VPNs : – – – – les données transitant sont chiffrées (confidentialité+Intégrité) les 2 extrémités sont authentifiées les adresses sources/destinations sont chiffrées (IP dans IPSec) autres qualités :anti-rejeux, empêcher attaques man-in-the-middle Anas Abou El Kalam 74 IPSec : AH (propriétés 1/2) Tunneling IPSec Datagramme IP Anas Abou El Kalam 75 assure l’intégrité et l’authentification de l’origine des datagrammes IP – Authenicité : AH garantit que datagrammes IP reçus ont effectivement été émis par l'hôte dont l'@ IP est indiquée comme adresse source dans les en-têtes. – L'unicité (optionnelle, à la discrétion du récepteur) : AH garantit qu'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. – L'intégrité : AH garantit que certains champs du datagramme IP n'ont pas été modifiés depuis leur émission : • les données (en mode tunnel, ceci comprend la totalité des champs, y compris les 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 (en IPv4), longueur 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 Anas Abou El Kalam 76 IPSec : AH (propriétés 2/2) IPSec : AH (paramètres) L'intégrité (suite) – L'intégrité de celles des options IP qui ne sont pas modifiables pendant le transport est assurée, celle des autres options ne l'est pas. – Cependant, la valeur que prendront les champs type de service (IPv4), indicateurs (IPv4), index de fragment (IPv4), TTL (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 Valeur du compteur utilisée pour détecter les datagrammes d’IP rejoués afin d’assurer l’intégrité des séquences de datagrammes pas garantie par AH. AH n'assure pas la confidentialité : les données sont signées mais pas chiffrées. AH ne spécifie pas d'algorithme de signature particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la Rfc 2402 est tenue de supporter les algorithmes MD5 et SHA-1. Anas Abou El Kalam 77 IPSec : AH (modes) Anas Abou El Kalam IPSec : AH (vérification) •IP AH peut être utilisé selon deux modes : Transport ou Tunnel. •Transport : •l’unique modification apportée au datagramme IP d’origine est l’inclusion du champ en-tête d’authentification. •Tunnel : •un autre en-tête IP est ajouté avant l’en-tête IP d’origine. Anas Abou El Kalam l’index des paramètres sécurité référence une association de sécurité qui définit – l’algorithme d’authentification choisi, – les clés utilisées et – les partenaires autorisés à utiliser cette association 78 79 Le traitement à la réception d’un datagramme IP protégé par l’IP AH consiste à • vérifier le champ des données d’authentification contenu dans l’IP AH en comparant sa valeur au résultat du hachage calculé par le destinataire. • Si le champ des données d’authentification est valide, l’intégrité du datagramme IP est prouvée. • L’authentification de l’origine des données est assurée car seuls l’expéditeur et le destinataire d’un datagramme ont accès à la fonction de hachage sécurisée •à la clé secrète partagée dans le cadre de l’association de sécurité correspondante • Un attaquant peut exécuter une attaque de rejeu en retransmettant au destinataire de l’association de sécurité un datagramme IP qui a déjà été transmis entre les deux entités de l’association •Si le service optionnel de détection de rejeu est sélectionné par le destinataire, alors il est possible de détecter les datagrammes rejoués en utilisant le champ numéro de séquence de l’AH Anas Abou El Kalam 80 IPSec : Encapsulation Security Payload (ESP) IPSec : Encapsulation Security Payload (ESP) Contrairement à AH, ESP ne protége pas les en-têtes des datagrammes IP utilisés pour transmettre la communication. Seules les données sont protégées. 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é. En mode transport, ESP assure : En mode tunnel, deux avantages supplémentaires apparaissent: – Confidentialité : – La confidentialité, confidentialité limitée, des flux / traffic • la partie données des datagrammes IP transmis est chiffrée. • car il permet aux passerelles de sécurité de cacher l’identité des hôtes source et de destination ainsi que la taille réelle des datagrammes IP. – Authentification de l'origine des données (optionnelle) : • la partie données des datagrammes 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 succès que s'il connaît la clef associée à l'ESP • Attaquant qui sniffe données transitant par un lien ne peut pas déterminer quel volume de données est transféré entre deux hôtes particuliers. – e.g., si la communication entre deux sous-réseaux est chiffrée à l'aide d'un tunnel ESP, le volume total de données échangées entre ces deux sous-réseaux est calculable par cet attaquant, mais pas la répartition de ce volume entre les différents systèmes de ces sous-réseaux. – l'absence d'authentification nuit à la confidentialité – Unicité (optionnelle, à la discrétion du récepteur): • protection contre rejeux – Integrité des données (optionnelle) : – La confidentialité des données, données si elle est demandée, s'étend à l'ensemble des champs, y compris les en-têtes, du datagramme IP encapsulé dans le datagramme protégé par ESP) • les données n'ont pas été modifiées depuis leur émission 81 Anas Abou El Kalam Anas Abou El Kalam IPSec : ESP 82 IPSec : ESP Portée de la confidentialité et de l'authentification en mode Transport & Tunnel ESP (∀ mode) ne spécifie pas d'algorithme de signature ou de chiffrement particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la Rfc 2406 est tenue de supporter l'algorithme de chiffrement DES en mode CBC, et les signatures à l'aide des fonctions de hachage MD5 et SHA-1 Données d'authentification Mode tunnel Anas Abou El Kalam 83 En mode Transport, l’en-tête du diagramme IP (e.g., @source & @dest sont à texte clair. Si tout le datagramme qui inclut infos du protocole doit aussi être protégé ==> utiliser mode Tunnel • Il permet en effet que les passerelles de sécurité, agissant comme noeuds intermédiaires entre les hôtes source et de destination finaux, mettent en oeuvre le protocole IP ESP en encapsulant le datagramme IP d’origine échangé entre la source et la destination avec un autre en-tête IP utilisé uniquement sur le chemin protégé entre ces passerelles. 84 Anas Abou El Kalam IPSec : Différences AH // ESP IPSec : calcul données d'auth. •ESP en mode Transport, l’en-tête du diagramme IP (@source & @dest) sont à texte clair •Si tout datagramme qui inclut infos du protocole doit être protégé ==> utiliser ESP en mode Tunnel • ESP mode Tunnel permet que les passerelles de sécurité, agissant comme noeuds intermédiaires entre hôtes source et dest finaux, mettent en oeuvre le protocole IP ESP en encapsulant le datagramme d’origine échangé entre source & dest avec un autre en-tête IP utilisé uniquement sur le chemin protégé entre ces passerelles. • Contrairement au champ données d’auth. AH, le champ données d’auth. ESP est optionnel et l’authentification fournie ne couvre que les champs de l’en-tête ESP, de la charge ESP et du remplissage d u datagramme. L’en-tête IP (celui d’origine dans le mode Transport ou le nouveau enmode Tunnel) n’est jamais protégé par le service d’authentification ESP. • Dans les cas où l’intégrité et la confidentialité des données de tout le datagramme IP sont obligatoires, il est donc recommandé d’utiliser IP ESP en association à IP AH. Anas Abou El Kalam L’auth. fourni par AH et ESP est basé sur une fonction de hachage sécurisée Les données d’authentification peuvent être calculées de deux manières : – E (H(M)) où : K • E : fonction chiffrement utilisant alg symétrique ou asymétrique • K : clé secrète partagée par source/dest dans cas d’un algo symétrique et la clé secrète privée de source dans le cas d’un algo asymétrique • H : condensat de message calculé avec MD5 ou SHA-1 – en appliquant fonction hachage (H) sur une association du message (M) et de la valeur secrète (K) partagée par source et destination. • H(K, M, K), K) K étant lke secret partagé • HMAC(K, M) = H(K⊕P , H(K⊕P , M)) où P et P sont deux chaînes de bits 1 1 2 constantes et représente l’opération d’ou-exclusif bit par bit. 85 IPSec : Internet Key Exchange (IKE) 2 Anas Abou El Kalam 86 IPSec : Internet Key Exchange (IKE) Les mécanismes (AH et ESP) utilisent des paramètres (algos chiffrement, clefs, mécanismes sélectionnés) sur lesquels les tiers communiquants doivent se mettre d’accord (les clés doivent être échangées de façon sure !) Parmi ses avantages figure le mode agressif (pas obligatoire), qui permet d'accélérer la négociation, au prix de la protection d'identité. – L'identité est toutefois protégée dans le cas d'une négociation IKE authentifiée à l'aide de signatures à clef publique. (le champ SPI référence une entrée dans une base de données où sont stockées ces informations pour une communication donnée, Deux manières d'échanger des clefs sont abondamment utilisées : Configuration manuelle possible mais peu réaliste, - sûre pour réseau grande taille – les clefs pré-partagées, – les certificats X.509 ==> configuration dynamique : protocole IKE (Internet Internet Key Exchange) Exchange • dans ce dernier cas, deux systèmes d'adresses initialement inconnues pourront protéger leurs échanges => se charge de l’échange des clés mais aussi de la gestion de tous les paramètres relatifs à la sécurisation des échanges => nécessite une authentification des tiers par secret partagé ou par échange de clés publiques (possibilité d’utiliser des certificats) => plusieurs clés sont ensuite générées : pour AH (authentification des paquets), pour ESP (chiffrement des paquets) Anas Abou El Kalam 87 Anas Abou El Kalam 88 IPSec : Association de sécurité (SA) IPSec : Association de sécurité (SA) Afin de stocker et de manipuler l'ensemble paramètres gérés par IKE et utilisés par mécanismes sécurisation ==> IPsec a recours à notion SA (security security association). association La Rfc 2401 (Security Security Architecture for the Internet Protocol) 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 une SA est une structure de données qui regroupe l'ensemble des paramètres de sécurité associés à une communication donnée – Chaque SA est identifiée de manière unique par termes de politique de sécurité • un SPI, – c'est-à-dire quels échanges IP doivent être protégés par IPsec et, le cas • une @ IP de destination (éventuellement @ de broadcast ou de multicast), échéant, quel(s) protocole(s) utiliser). • un protocole (AH ou ESP). Sur chaque système capable d'utiliser IPsec doit être présente une SPD (security security policy Les SA actives sont regroupées dans une SAD (security security association database). database database), database – Les protections offertes par Ipsec sont basées sur des choix définis dans SPD – permet de préciser la politique de sécurité à appliquer au système (selon choix administrateur) La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non-IPsec. Les données de la SA sont trop importantes pour pouvoir être transportées in extenso dans chaque header – ==> Chaque entrée de cette base de données est identifiée par un SPI (security parameters index) unique (32 bits). Anas Abou El Kalam 89 Anas Abou El Kalam 90 IPSec : architecture IPSec : Association de sécurité (SA) Trafic sortant • Lorsque "couche" Ipsec reçoit data à envoyer, Les plus importants de ces termes sont : – SPD base de données définissant la politique de sécurité (protocole, ....) – SA une entrée de la SPD – SAD liste des SA actives (en cours d'utilisation) Les règles de la SPD doivent pouvoir, si l'adminsitrateur du système le souhaite, dépendre des paramètres suivants : – adresse ou groupe d'adresses IP de destination – adresse ou groupe d'adresses IP source – nom du système (DNS complète, nom X.500 distingué ou général) elle cconsulte BD politiques (SPD) pour savoir comment traiter ces données. • Si SPD indique que trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour SA correspondante et va consulter SAD. • Si SA nécessaire existe, elle est utilisée pour traiter le trafic en question. • Sinon, Ipsec fait appel à IKE pour établir une nouvelle SA avec caractéristiques requises – protocole de transport utilisé (typiquement, TCP ou UDP) – nom d'utilisateur complet, comme [email protected] (pas obligatoire) – importance des données (pas obligatoire sur certains types d'implémentations) – ports source et destination (UDP et TCP seulement) • Lorsque Ipsec reçoit paquet en provenance du réseau, elle examine l'en-tête pour savoir si ce paquet s'est vu appliquer un ou plusieurs services Ipsec et si oui, quelles sont références de SA • Consulte SAD pour connaître param à utiliser pour vérification et/ou déchiffrement. • Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l'association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Certains paramètres (ID U, Protocole transport, ports srce/dest) peuvent être illisibles à 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 Anas Abou El Kalam Trafic entrant 91 Anas Abou El Kalam 92 IPSec : architectures supportées IPSec : architectures supportées Dialogue entre deux hôtes protégeant le trafic eux-mêmes Le protocole IPsec permet théoriquement n'importe quelle combinaison, en un nombre quasiment illimité de niveaux d'encapsulation, i.e., d'accumulations de SA. Deux hôtes engagent une comm IPsec, en encapsulant le protocole de haut niveau dans : – en mode transport : – Néanmoins, les implémentations ne sont pas tenues d'offrir une telle flexibilité. Quatre typres d'architectures sont conforme à la RFC 2401 • datagrammes AH • datagrammes ESP • ou datagrammes ESP encapsulés dans datagrammes AH – Dialogue entre deux hôtes protégeant le trafic eux-mêmes – en mode tunnel : – Dialogue entre deux LANs à l'aide de passerelles de sécurité • des datagrammes AH – Dialogue entre deux hôtes traversant deux passerelles de sécurité • ou des datagrammes ESP – Dialogue entre un hôte et une passerelle de sécurité IP1 entête IP original IP2 entête IP d'encapsulation DCS Donn.es des Couches Supérieures 93 Anas Abou El Kalam IPSec : architectures supportées Anas Abou El Kalam 94 IPSec : architectures supportées 2- Dialogue entre deux LANs à l'aide de passerelles de sécurité Dialogue entre deux hôtes traversant deux passerelles deux passerelles de sécurité gèrent les conversations entre les hôtes de deux LANs ≠, IPsec s'appliquant de manière transparente pour les hôtes. Les deux passerelles échangent des datagrammes en mode tunnel, à l'aide de AH ou ESP, puis transmettent les datagrammes obtenus après traitement IPsec aux hôtes destinataires. Les datagrammes IP émis par un système de l'un des deux LANs sont encapsulés dans d'autres datagrammes IP+IPsec par la passerelle du "LAN émetteur", Encapsulation supprimée par la passerelle du "LAN récepteur" pour obtenir de nouveau les datagrammes IP originaux. datagramme IP interne échangé entre Hôte1 et Hôte2 est encapsulé en entier par l’en-tête IP externe échangé entre les passerelles de sécurité. La sécurité bout en bout de l’en-tête interne avec IPsec peut être protégée par AH, ESP ou les deux en mode Transport et Tunnel, en fonction de la AS bout en bout négociée entre les systèmes hôtes. On applique un ensemble différent de AS à l’en-tête IP externe échangé entre les passerelles de sécurité sur Internet. Ex: VPN avec IPSec Anas Abou El Kalam 95 la prise en charge de la sécurité bout en bout sur le réseau virtuel privé impose que chaque passerelle de sécurité doit autoriser le transit du trafic IPsec destiné à un hôte faisant partie du réseau privé local. Anas Abou El Kalam 96 IPSec : architectures supportées IPSec : Ex d'implémentations d'IPSEC 4- Accès distant d'un hôte à un intranet par le biais d’une passerelle de sécurité afin d’atteindre un second hôte situé sur l’intranet OpenBSD Les choix possibles de AS entre Hôte1 et PS sont identiques à ceux qui prévalent pour les passerelles de sécurité du scénario sur le réseau virtuel privé. intégration native dans la pile IP du noyau De la même manière, les choix pour l’association de sécurité bout en bout entre le hôte distant et le hôte local sont identiques à ceux du premier scénario. La seule particularité pour ce cas précis est que Hôte1 doit appliquer l’en-tête de transport bout en bout avant l’en-tête de tunnel sur les datagrammes de sortie. La combinaison de deux AS n’est toutefois pas toujours requise pour un accès distant. Dans le cas où le réseau interne est fiable et où la sécurité bout en bout n’est pas nécessaire, l’AS2 en mode tunnel entre Hôte1 et la passerelle est suffisante. administration de IPsec avec ipsecadm négociation dynamique des SA et des clés avec le démon isakmpd – fichier de configuration de isakmpd : /etc/isakmpd/isakmpd.conf – fichier de configuration de la politique de sécurité : /etc/isakmpd/isakmpd.policy FreeS/WAN permet d’intégrer IPsec sur machine linux (développement non natif dans la pile IP) nécessité de patcher le noyau avec KLIPS (Kernel IPsec Support) administration de IPsec avec la commande ipsec démon implémentant IKE est pluto – fichiers de configuration : /etc/ipsec.conf, /etc/ipsec.secrets Anas Abou El Kalam 97 IPSec : Ex d'implémentations d'IPSEC 98 Anas Abou El Kalam IPSec : Ex d'implémentations d'IPSEC Ex avec FreeS/Wan : Ex avec FreeS/Wan : – mise en place d’IPsec en mode transport entre 2 machines – mise en place d’IPsec en mode transport entre 2 machines 1er cas : échange de clés dynamique en utilisant IKE, par secret partagé 2ème cas : échange de clés dynamique en utilisant IKE, par clés publiques dans le fichier /etc/ipsec.secrets, sur les 2 ,machines, mettre le secret partagé : 193.50.169.115 193.50.169.116 "0x1107d0bb_6acbe1e5_21433426_f3f10dfa_4392fcda_6c215f1a_e2b14b6b" dans le fichier /etc/ipsec.conf, configuration de la connexion conn test type=transport Left=193.50.169.115 ipsec en mode transport @IP des 2 machines right=193.50.169.116 authby=secret authentification par secret partagé auto=start Anas Abou El Kalam 99 Anas Abou El Kalam 100 IPSec : C/C Plan L'intérêt majeur de cette solution / à d'autres techniques (e.g., tunnels SSH) est qu'il s'agit d'une méthode standard (facultative en IPv4, obligatoire en IPv6), mise au point dans ce but précis, décrite par différentes RFCs, et donc interopérable. économie de bande passante, SSL SSH – compression des en-têtes des données transmises – ne fait pas appel à de trop lourdes techniques d'encapsulation, comme par exemple les tunnels PPP sur lien SSH. IPSec permet également de protéger des protocoles de bas niveau comme ICMP et IGMP, RIP, etc... VPN solution évolutive, puisque les algorithmes de chiffrement et d'authentification à proprement parler sont spécifiés séparément du protocole lui-même. Inconvénient inhérent à sa flexibilité : S-MIME – sa grande complexité rend son implémentation délicate. PGP Anas Abou El Kalam 101 VPN : intro Anas Abou El Kalam 102 VPN : principe de tunneling C'est un réseau privé qui repose sur une infrastructure publique (Internet) Consiste à construire un chemin virtuel après avoir identifié émetteur / destinataire – la source chiffre les données et les achemine en empruntant Ce chemin virtuel. VPN ont commencé à être mis en place pour répondre à problématiques du type : – Comment une succursale d'une entreprise peut accéder aux données situées sur un serveur de la maison mère distant de plusieurs milliers de kilomètres ? Principe ("protocole de tunneling") Afin d'assurer un accès aisé et peu coûteux aux intranets ou aux extranets d'entreprise, les réseaux privés virtuels d'accès simulent un réseau privé, alors qu'ils utilisent en réalité une infrastructure d'accès partagée, comme Internet. Les données à transmettre peuvent être prises en charge par un protocole ≠ d'Ip. – faire circuler les informations de l'entreprise de façon cryptée d'un bout à l'autre du tunnel. – Dans Ce cas, le tunneling encapsule les données en ajoutant une en-tête. Le tunneling est l'∑ proessus d'encapsulation, transmission et désencapsulation. • U ont l'impression de se connecter directement sur réseau de leur entreprise Anas Abou El Kalam 103 Anas Abou El Kalam 104 VPN : principe VPN : Le VPN d'accès L’encapsulation (ou tunneling) de paquets dans d’autres paquets Exemple avec IP (A envoie un paquet à B) : utilisé pour permettre à des utilisateurs itinérants d'accéder au réseau privé. Deux cas: U demande au fournisseur d'accès de lui établir une connexion chiffrée vers serveur distant : il communique avec Nas (Network Access Server) du FI et c'est NAS qui établit la connexion. – 1ère permet à U de communiquer sur ++ réseaux en créant plusieurs tunnels, mais nécessite un FI proposant un NAS compatible avec la solution VPN choisie par l'entreprise. De plus, la demande de connexion par le NAS n'est pas chiffrée Ce qui peut poser problèmes sécurité U possède son propre logiciel client pour le Vpn auquel cas il établit directement la communication de manière cryptée vers le réseau de l'entreprise. – problème 1 disparaît puisque l'intégralité des infos sera chiffrée dès l'établissement connexion. Par contre, cette solution nécessite que chaque client transporte avec lui le logiciel lui permettant d'établir une communication chiffrée. • pour pallier Ce problème certaines E/ses mettent en place des Vpn à base de Ssl. Anas Abou El Kalam 105 VPN : L'intranet VPN ∀ méthode ==> l'importance dans le VPN d'avoir une authentification forte des U. 106 Anas Abou El Kalam – e.g., vérification "login / mot de passe", "Tokens sécurisés" (pwd aléatoires), certificats, ... VPN : bilan Un système de Vpn doit pouvoir mettre en oeuvre les fonctionnalités suivantes : Authentification U – Seuls U autorisés doivent pouvoir s'identifier sur réseau virtuel – historique connexions et actions effectuées sur le réseau doit être conservé. utilisé pour relier au moins deux intranets entre eux. Ce type de réseau est particulièrement utile au sein d'une E/se possédant ++ sites distants. Données sensibles (BD clients, infos financières...) peuvent être amenées à transiter sur VPN. Des techniques de cryptographie sont mises en oeuvre pour vérifier que les données n'ont pas été altérées. Il s'agit d'une authentification au niveau paquet pour assurer – la validité des données, – l'identification de leur source – non-répudiation. La plupart des algos utilisés font appel à signatures qui sont ajoutées aux paquets. La confidentialité des données est, elle aussi, basée sur des algos de chiffrement. La technologie en la matière est suffisamment avancée pour permettre une sécurité quasi parfaite. Le coût matériel des équipements de chiffrement ainsi que limites légales interdisent l'utilisation d'un codage " infaillible ". Généralement pour confidentialité, codage en lui-même pourra être moyen, mais sera combiné 107 Anas Abou El Kalam avec d'autres techniques comme l'encapsulation IP dans IP pour assurer sécurité raisonnable. Gestion d'adresses – Chaque client sur réseau doit avoir une adresse privée, qui doit rester confidentielle – Un nouveau client doit pourvoir se connecter facilement au réseau et recevoir une @. Chiffrement des données – Lors de leurs transports sur le réseau public les D doivent être protégées. Gestion de clés. – Les clés de chiffrement pour C &S doivent pouvoir être générées et régénérées. Prise en charge multiprotocole – Solution VPN doit supporter protocoles les plus utilisés sur réseaux publics (IP, .. Le Vpn est un principe : il ne décrit pas l'implémentation effective de ces caractéristiques. C'est pourquoi il existe plusieurs produits différents sur le marché dont certains sont devenus standard, et même considérés comme des normes 108 Anas Abou El Kalam VPN : implémentations Plan Protocoles de niveau 2 comme SSL – PPTP de Microsoft – L2tp (Layer Two Tunneling Protocol) proposé par l’IETF. SSH Protocoles de niveau 3 comme – IPSec IPSec – MPLS VPN S-MIME PGP Anas Abou El Kalam 109 110 Anas Abou El Kalam Aspects juridiques Plan SSL Evolution juridique de la signature électronique 1997 SSH EUROPE IPSec Directive 1999/93/CE « Signature électronique » FRANCE VPN Recommandation 97/489/CE « Lien entre le titulaire et l’émetteur » 1999 S-MIME 2000 2001 Directive 2000/31/CE « Commerce électronique » Loi 2000-230 Décret 2001-272 PGP Anas Abou El Kalam 111 Anas Abou El Kalam 112 La Directive 1999/93/CE La Directive 1999/93/CE Article 5 : reconnaissance légale de la signature électronique – La signature électronique doit être acceptée au même titre qu’une signature manuscrite pour autant que : La Directive européenne 1999/93/CE – Rappel sur la portée d’une Directive : une Directive est un texte qui fixe les objectifs à atteindre pour les états membres, sans pour autant imposer la manière d’y parvenir. La directive est découpée en articles : • Elle soit accompagnée d’un certificat qualifié • Qu’elle soit créée par un dispositif sécurisé – Cependant, une signature électronique ne peut être rejetée directement comme preuve non valide si elle ne respecte pas ces contraintes Article 2 : définitions Article 4 : principe de la libre circulation sur le marché intérieur – Signature électronique : authentification – Signature électronique avancée : authentification, intégrité et non répudiation – Certificat : donnée qui confirme la relation entre une personne et sa signature électronique – Certificat qualifié : un certificat délivré par un prestataire de service de qualification et portant diverses informations, dont une période de validité – Prestataire de service de certification : une entité capable de founir des certificats (les « obligations » à remplir sont également précisées dans la directive Anas Abou El Kalam – Les produits et services relatifs à la signature électronique sont soumis aux législations des pays d’origine, ils doivent circuler librement Article 3 : absence d’autorisation préalable et accès au marché – La fourniture des services de certification n’est pas soumise à une autorisation préalable 9 cependant les états membres peuvent émettre des recommendations visant à augmenter la qualité de ces services 113 La Directive 1999/93/CE Anas Abou El Kalam 114 La Directive 1999/93/CE Article 6 : responsabilité des prestataires de certification Article 7 : la dimension internationale – Cet article prévoit des mécanismes de coopération pour faciliter les accords bi-latéraux en vue de favoriser le commerce électronique – Les prestataires sont responsables d’un minimum de choses : • Ils doivent s’assurer de l’exactitude des informations contenues dans le certificat • Ils doivent s’assurer que le porteur du certificat est attitré en tant que tel • Ils doivent assurer que dans le cas où le prestataire génère les données nécessaires à la signature et à la vérification, ces données soient effectivement complémentaires Articles 9 & 10 : création d’un comité de conseil – Un comité est créé pour assister la CE dans les décisions concernant la signature électronique Article 8 : protection des données personnelles – Les prestataires sont tenus à respecter la Directive européenne sur la protection des données personnelles 95/46/CE – De plus, ils ne peuvent récolter ces informations que depuis le porteur du certificat (ou avec son consentement explicite) Anas Abou El Kalam 115 Anas Abou El Kalam 116 La Loi 2000-230 La Loi 2000-230 La Loi 2000-230 modifie quelques articles du code civil L’article 1316 : la preuve écrite est indépendante du support ou du mode de transmission L’article 1316-4 : institution de la propriété officielle de la signature et équivalence de la signature électronique lorsqu’elle est établie par un processus fiable L’article 1316-1 : la signature électronique est acceptée en tant que preuve à condition qu’elle possède les propriétés d’authentification et d’intégrité L’article 1317 : extension de l’acte authentique au support électronique L’article 1316-2 : le règlement des conflits, lorsqu’il n’y a pas de texte explicite, se fait par le juge en utilisant la preuve la plus vraisemblable, quelque soit le support L’article 1326 : un acte unilatéral engagant un signataire doit être écrit par lui-même, la précedente version de l’article indiquant par sa L’article 1316-3 : l’écrit électronique a la même force probante que l’écrit sur papier Anas Abou El Kalam main Le décret 2001-272 suit la Directive 1999/93/CE et offre un cadre opérationnel pour la Loi 2000-230 117 Anas Abou El Kalam 118
