Sécurité des RO Rappel: Utilités la sécurité à tous les ...irt.enseeiht.fr/anas/cours/moyens.pdf · Présentation Application : S-MIME, PGP, Sbox, OTP Boîtier de chiffrement

Sécurisation des Sécurisation des

échangeséchanges

Anas ABOU EL KALAMAnas ABOU EL KALAM

[email protected]@enseeiht.fr

Sécurité des RO

Partie 6

2 Anas Abou El Kalam

Rappel: Utilités la sécurité à tous les niveaux

Liaison physique : Bluetooth

Transport : SSL, TLS

Liaison : CHAP, PAP

Réseau : authentification IP (IPsec)

Session : SHTTP

Présentation

Application : S-MIME, PGP, Sbox, OTP

Boîtier de chiffrement

SSL, TLS, SHTTP

SSH

IpSec


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


SSL : Introduction

• SSL défini par SSL défini par netsacpenetsacpe et intégré au et intégré au

browserbrowser

• Première version de SSL testé en interne Première version de SSL testé en interne

• Première version de SSL diffusé : V2 (1994)Première version de SSL diffusé : V2 (1994)

• Version actuelle V3Version actuelle V3

• Standard à l�’IETF au sein du groupe Standard à l�’IETF au sein du groupe

Transport Layer Security (TLS)Transport Layer Security (TLS)

• Standard au sein du WAP Forum Wireless Standard au sein du WAP Forum Wireless

Transport Layer Security (WTLS)Transport Layer Security (WTLS)


SSL / TLS : caractéristiques

� Repose sur un procédé de crypto à clès publiques

� Indépendant du protocole utilisé – 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

� Transparent pour l'utilisateur

� Supporté par la quasi totalité des navigateurs

� Serveur sécurisé par SSL � URL commençant par httpss://

� Confidentialité � Algo symétriques (3DES, IDEA, 9RC4)

� Intégrité � MAC (MD5 ou SHA)

� Authentification � X509 et MAC


SSL : Architecture

NFS

XDRFTP SMTP HTTP Telnet

SNMP RPC

UDP

SSL

TCP

IP


Ports au dessus de SSL (1/2)

Protocole

sécurisé

Port Protocole non

sécurisé

Application

HTTPS 443 HTTP Transactions requête-réponse sécurisées

SSMTP 465 SMTP Messagerie électronique

SNNTP 563 NNTP News sur le réseau Internet

SSL-LDAP 636 LDAP Annuaire X.500 allégé

SPOP3 995 POP3 Accès distant à la boîte auxlettres avec rapatriement desmessages


Ports au dessus de SSL (2/2)

Protocolesécurisé

Port Protocole nonsécurisé

Application

FTP-DATA 889 FTP Transfert de fichiers

FTPS 990 FTP Contrôle du transfert de fichiers

IMAPS 991 IMAP4 Accès distant à la boîte aux lettres avec ousans rapatriement des messages

TELNETS 992 Telnet Protocole d’accès distant à un systèmeinformatique

IRCS 993 IRC Protocole de conférence par l’écrit


SSL : propriétés / services

• AuthentificationAuthentification

– Serveur (obligatoire), client (optionnel)

– Utilisation de certificat X509 V3

– A l’établissement de la session.

• ConfidentialitéConfidentialité

– Algorithme de chiffrement symétrique négocié, clé généré à l’établissement de la session.

• IntégritéIntégrité

– Fonction de hachage avec clé secrète : hmac(clé secrète, h, Message)

• Non RejeuNon Rejeu

– Numéro de séquence


SSL : Protocoles

Application

TCP

SSL

Record

CCSAlert

Handshake


SSL / TLS : fonctionnement globale

� é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 sessionclé de 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.


TLS : négociation de session

� Une session définit les éléments suivants :Une session définit les éléments suivants :– 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 : Clés utilisées : – secret maître, – aléas serveur et client permettent de calculer la clé de chiffrement et– clé de scellement.


TLS : négociation de session

� Toute communication sécurisée débute par Toute communication sécurisée débute par une négociation de session «�une négociation de session «�TLS TLS Handshake protocolHandshake protocol�»�»

� Format des trames de négociation :Format des trames de négociation :

Type Taille Contenu

Type : hello_request (0), client_hello (1), server_hello (2) ...

ObjectifObjectif

• 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.14

Anas Abou El Kalam

TLS : négociation de sessionDécider du niveau de sécurité (suivant les capacités de chacun)

Le serveur s’authentifieet envoie les paramètres permettant

d ’établir un pré-secret maître

Le client s ’authentifie (si requis)et envoie les paramètres permettant

d ’établir un pré-secret maître

Fin négociation de sessionClient & serveur converseront désormaisavec algos et clés de sécurité établies


La négociation de session TLS


Handshake

Message Type de

message

Sens de

transmission

Signification

HelloRequest optionnel serveur → client Ce message demande au client d'entamerle 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 choisiespar le client ;

la liste des méthodes de compressionchoisies 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.


Handshake

Certificate Optionnel serveur → client

client → serveur

Ce message contient le certificat duserveur ou celui du client si le serveur le luiréclame et que le client en possède un.

ServerKeyExchange Optionnel serveur → client Ce message est envoyé par le serveur ques’il ne possède aucun certificat, ouseulement un certificat de signature.

CertificateRequest Optionnel serveur → client Par ce message, le serveur réclame uncertificat au client.

ServerHelloDone Obligatoire serveur → client Ce message signale la fin de l’envoi desmessages ServerHello et subséquents.


Handshake

ClientKeyExchange Obligatoire client → serveur Ce message contient le PreMasterSecretcrypté à l’aide de la clé publique duserveur.

CertificateVerify Optionnel client → serveur Ce message permet une vérificationexplicite du certificat du client.

Finished obligatoire serveur → client

client → serveur

Ce message signale la fin du protocoleHandshake et le début de l’émission desdonnées protégées avec les nouveauxparamètres négociés.


Handshake

Client Serveur

Ouverture d'unesession SSLv3

Client Hello

Serveur HelloCertificate

(Serveur Key Exchange)(Certificate Request)Server Hello Done

(Certificate)Client Key Exchange(Certificate Verify)

ChangeCipherSpecFinished


Application Data

Application Data


Handshake

Client Serveur

Ouverture d'uneconnexion

Client Hello

Serveur HelloChangeCipherSpecFinished

Application Data




� Suite à la requête d'un C, � le S :

– envoie son certificat au C – liste algos cryptos, qu'il souhaite négocier

� 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.

� 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.

1ère phase : authentification serveur1ère phase : authentification serveur



� Serveur– peut demander au client de s'authentifier en lui

demandant son certificat.

� 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)

2ème phase : authentification (optionnelle) du Client2ème phase : authentification (optionnelle) du Client

Remarque :Remarque :Clé publique serveur � chiffrement Clé privée du client � signature


La négociation de session TLS � Client HelloClient Hello

– 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é

� Server HelloServer Hello– 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 FINISHSi session réutilisée, passer en FINISH 24 Anas Abou El Kalam


� Server certificateServer certificate– 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 key exchangeServer key exchange– 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)


La négociation de session TLS � Certificate requestCertificate request

– envoyé uniquement si l’authentification du client est requise

– types de certificats admis

– noms d’autorités de certification reconnues

� Server hello doneServer hello done

– le serveur attend une réponse du client

� Client certificateClient 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



� Client key exchangeClient 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

� Calcul des clésCalcul 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.

Pre Master Secret Key

N° versionRSA

Clé publique

du serveur

Client Key Exchange

Pre Master SecretKey sécurisé



� Certificate verifyCertificate verify– 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

� Client Finish et Server FinishClient 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”.


TLS : génération des clés

� Utilisation d�’une fonction de génération de Utilisation d�’une fonction de génération de

nombres pseudo aléatoires (PRF)nombres pseudo aléatoires (PRF)

– 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é

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)


TLS : génération des clés

� Génération du secret maître à partir de :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 :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)


TLS : pile de protocole

� HandshakeHandshake

– authentification mutuelle C/S – négociation algos chiffrement, hachage, échange clés symétriques

� Change Cipher SpecChange Cipher Spec

– Notif du S que tous messages qui vont suivre message “Client Finished” seront chiffrés avec clés / algos négociés.

� AlertAlert

– Alertes qui peuvent être envoyés par chacunedes parties suite aux evnt qui peuvent subvenir

� RecordRecord

– sécurité des données HTTP– sécurité des autres couches de protocoles TLS

IP

TCP

TLS Record Protocol

TLSHandshakeProtocol

TLS ModifCipherspec

protocol

TLS AlertProtocol

HTTP

Quatre ProtocolesQuatre Protocoles


ChangeCipherSpec (CCS)

• ChangeCipherSpecChangeCipherSpec signale au signale au RecordRecord toute toute

modification des paramètres de sécurité,modification des paramètres de sécurité,

• Constitué d’un message (1 octet)Constitué d’un message (1 octet)


Le protocole Record

• Reçoit les données des couches supérieures�: Reçoit les données des couches supérieures�: ((HandshakeHandshake, , AlertAlert, , CCSCCS, HTTP, FTP ...), et les , HTTP, FTP ...), et les transmet au protocole TCP.transmet au protocole TCP.

• Après application de :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é


Le protocole Alert

• Le protocole Le protocole AlertAlert peut être invoqué�: peut être invoqué�: � 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 par la couche RecordRecord directement, par directement, par exemple si l'intégrité d'un message est exemple si l'intégrité d'un message est mise en doutemise en doute


Le protocole Alert (2)

Message 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 ceuxprécisés précédemment

fatal

close_notify interruption volontaire de session fatal

decompression_failure les données appliquées à la fonction dedécompression sont invalides (par exemple, troplongues)

fatal

handshake_ failure impossibilité de négocier des paramètres satisfaisants fatal

illegal_parameter un paramètre échangé au cours du protocoleHandshake dépasse les bornes admises ou neconcorde pas avec les autres paramètres

fatal

no_certificate réponse négative à une requête de certificat avertissementou fatal

unexpected_message arrivée inopportune d’un message fatal

unsupported_certificate le certificat reçu n’est pas reconnu par le destinataire avertissementou fatal


TLS : traitement des données

Données applicatives

Fragment 1 Fragment 2

Compressé

MACCompressé

Fragmentation (214 octets maxi)

Compression (ajoute 1024 octets maxi)

Scellement (HMAC)

Fragment Chiffré

Chiffrement (ajoute 2048 octets maxi)


TLS : traitement des données

� Fragmentation :Fragmentation :– frontières messages clients peuvent être déplacées– fragments de 214 octets au plus

� Compression (optionnelle) :Compression (optionnelle) :– ajoute au pire 1024 octets– sans pertes

� Sceau :Sceau :– HMAC(MAC_write_secret,seq_num+type de protocole TLS+version TLS+taille du fragment compressé+fragment compressé)

– + = concaténation� Chiffrement :Chiffrement :

– le fragment peut être paddé (chiffrement par blocs)– on chiffre le fragment compressé + MAC– ajoute au pire 1024 octets

Données applicatives

Frag 1 Frag 2

Compressé

MACCompressé

Fragment Chiffré


TLS : PDU (Protocol Data Unit) de données

� Type de protocole : Type de protocole : – TLS Cipher Change Protocol (20)

– TLS Alert Protocol (21)– TLS Handshake Protocol (22)

– données applicatives (23)

� Version : 3.1Version : 3.1

� Taille : Taille : – taille des données chiffrées (214+2048 max).

Type Maj Min Taille

Données (compressées)

MAC

chiffré


TLS : protocole d ’alerte

� Niveau d�’alerte :Niveau d�’alerte :– avertissement– fatal

� Message :Message :– fermeture de session– mauvais format de message– MAC erroné, erreur de déchiffrement, erreur de décompression

– overflow (message trop long)– mauvais certificat– ...

Niveau Description

PDU alerte


Var d’état d’une session TLS

� Session IDSession ID (l'dentifiant de session) – séquence aléatoire de 32 octets choisie par le serveur pour identifier session.

� Peer certificatePeer certificate (le certificat du pair) – c'est un certificat X 509 du correspondant (soit pour un serveur ou un client).

� Compression methodCompression method – Algo de compression utilisé

� Cipher specCipher spec (suite de chiffrement) – définit les algorithmes de chiffrement et de hachage

� MasterSecret MasterSecret – clé de 48 octets partagée entre le client et le serveur.

� Is resumableIs resumable (le drapeau) – flag qui indique si il est possible d'ouvrir de nouvelles connexions sur la session

en question


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 :

� Server_randomServer_random et Client_randomClient_random– deux nombres aléatoires de 32 octets, générés par le C et le S lors de chaque connexion

� Server_MAC_write_secretServer_MAC_write_secret– clé secrète utilisé par le serveur pour calculer les MACs

� Client_MAC_write_secretClient_MAC_write_secret– clé secrète utilisé par le client pour calculer les MACs

� Server_write_keyServer_write_key– clé symétrique utilisé par le serveur pour le chiffrement des données.

� Client_write_keyClient_write_key– clé symétrique utilisé par le client pour le chiffrement des données.

� Initialization vectorsInitialization vectors– 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 numberSequence number– chaque message est numéroté, l'un pour le S, l'autre par le C, et chacun codé sur 8 octets.


SSL : charges

Opération Temps de calcul pour le client

(ms)

Temps de calcul pour le

serveur (ms)

Total (ms)

Ouverture d’une nouvellesession (Handshake complet)

18,94 16,9 35,85

Rafraîchissement d'unesession (Handshake simplifié)

0,11 0,11 0,22

Ouverture d’une nouvelleconnexion

0,079 0,071 0,15

Temps de calcul pour 16Kode données (chiffrement oudéchiffrement, élaboration etvérification du MAC)

5,5 5,3 10,8


Nom de l’API Fournisseur Adresse

AOLserver 2.3 America Online Inc. http://www.aolserver.com

Alibaba 2.0 Computer SoftwareManufacturers

http://www.csm.co.at/alibaba/

Apache 1.3 The Apache Group http://www.apache.org

Commerce Server/400 1.0CI/NET, Inc. http://www.inetmi.com

Enterprise Server 3.0 Novonyx http://www.novonyx.com

Enterprise Web Secure/VM 1.1Beyond-Software Incorporatedhttp://www.beyond-software.com

Internet Information Server 4.0Microsoft Corp. http://www.microsoft.com/iis

Java Server 1.1 Sun Microsystems http://www.java.sun.com

Lotus Domino Go Webserver4.6.1

IBM http://www.ibm.com

Netscape Enterprise Server 3.5.1Netscape Communications Corp.http://www. netscape.com

Oracle Web Application Server3.01

Oracle Corp. 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 http://www.tenon.com/products/webten

Zeus Web Application Server 3Zeus Technology http://www.zeustech.net

SSL : liste non exhaustive de serveur


Serveur et Version ApacheSSLLeay 08.0

Jigsaw

2.0 Beta 1

Microsoft

IIS/4.0

Netscape

Entreprise3.0L

Netscape

Entreprise 3.0F

SSLava

Beta 1

Suite Export Code

RC4-40 MD5 � 0x03 � � � � � �

RC4-128 MD5 0x04 ��

RC4- 128 SHA 0x05 ��

RSA RC2 CBC-40 MD5 �� 0x06 ��

IDEA CBC SHA 0x07 ��

DES40 CBC SHA �� 0x08 ��

DESCBC SHA 0x09 ��

3DES EDE CBC SHA 0x0A ��

DES40 CBC SHA �� 0x0B ��

DH etDSA

DES CBC SHA 0x0C ��

3DES EDE CBC SHA 0x0D ��

DES40 CBC SHA �� 0x0E ��

DH etRSA

DES CBC SHA 0x0F ��

3DES EDE CBC SHA 0x10 ��


DHE etDSA

DES CBC SHA 0x12 ��



DHE etRSA

DES CBC SHA 0x15 ��


SSL : liste de suite de chiffrement supportée par un serveur


Attaques classiques

• Pistes classiquesPistes classiques– Casser les clefs

– Attack replay

– Man in the middle

– Attaque à clair ouvert

• Parades de SSLParades de SSL– Taille des clefs

– Nonces (connection id)

– Certificats servent à passer les clefs

– Clefs + Aléas


Sources de vulnérabilité

• Taille des clefsTaille des clefs

• SSL v2SSL v2

• CertificatsCertificats

• ImplémentationsImplémentations


Scénarios d’attaque

• SSL v2 : SSL v2 : Forcer une faible taille de clefForcer une faible taille de clef

• Tous : Tous : Diffie-Hellman anonymeDiffie-Hellman anonyme

• SSL v3 : SSL v3 : Accepte Accepte FinishedFinished avant avant ChangeCipherSpecChangeCipherSpec

• SSL v3 : SSL v3 : Envoi de données chiffrées avant Envoi de données chiffrées avant

réponse serveur au réponse serveur au FinishedFinished..


Exemple 1

SSL v2

Forced weak ciphersuite

CryptoL

CryptoL

• Faible clefsFaible clefs

• Pas de vérificationPas de vérification

d’intégritéd’intégrité


Exemple 2

“ Man in the middle ” attackSSL v3

DH anonymous authentification

• TiersTiers

à à

l’écoutel’écoute


Exemple 3

Phase 1 Phase 2


Exemple 4

SSL v3

Send data before finished server

?

• Envoi de donnéesEnvoi de données

chiffréeschiffrées

• Permet de casserPermet de casser

la clef, la clef,

puis de répondrepuis de répondre


SSL vs TLS ? � Différences minimes :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 • 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.

� Anciennes versions de SSL :Anciennes versions de SSL :

– rollback attack étudiée

– tous les messages de négociation sont scellés (pas en v2.0)52

Anas Abou El Kalam

SSL vs SSH ?

SSH SSL / TLSprotocole de sécurisation des communications Internet

propose de nombreuses autres options

programme et protocole de connexion et d'exécution de commande sur ordi accessible depuis un réseauLes connexions SSH doivent être authentifiées

ne requiert aucune authentification côté serveur : celle-ci est optionnelle, et une connexion peut être anonymeauthentification côté client que par échange de clefs publiques

peut-être utilisé dans un cadre autre que le Web pur : FTP, POP3 / IMAP / SMTP, telnet

se limite au protocole HTTP (en fait HTTPS, qui est HTTP sécurisé par SSL)

permet de son côté de créer un "tunnel" entre ces deux applications, qui reste ouvert et disponible même s'il n'y pas d'échange en cours.

SSL/TLS n'est utile qu'en cas d'échange entre deux applications

SSH est une véritable plate-forme de sécurisation pour toutes formes de communications électroniques.

permet de sécuriser le transport d'informations via le Web


TLS : conclusion

� AvantagesAvantages– Protocole assez bien pensé et complet– Supportés par de nombreux navigateurs et donc + ou - “standard”

� InconvénientsInconvé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).


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


Sécurisation des échanges : SSH

� IntroIntro

– remplacement sécurisé des commandes telnet, rlogin, rsh et rcp d’Unix

– Utilise SSL

– fonctions supplémentaires

– authentification par clés publiques

– tunnels

– Secure ftp (sftp)

� ImplémentationsImplémentations

– SSH (http://www.ssh.com )

– OpenSSH (www.openssh.com)

– ...56

Anas Abou El Kalam


� Apperçu (simplifié) du protocoleApperçu (simplifié) du protocole

1. Négociation de la version du protocole

2. Identification de l’hôte distant (RSA)

3. Négociation de l’algorithme de chiffrement (3DES, Blowfish, IDEA, ...)

4. Génération et échange d’une clé de chiffrement de session

5. Authentification de l’utilisateur

- soit par clé publique / privée

- soit par login traditionnel

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



� Utilisation basique sous UnixUtilisation basique sous Unix

UnUtilisateur[~] ssh toto.n7.fr

Host key not found from the list of known hosts.

Are you sure you want to continue connecting (yes/no)? yesyesyesyes

Host 'toto.n7.fr' added to the list of known hosts.

[email protected]'s password: XXXXXX

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

toto[~]toto[~]

Clé publique du serveur

non connue

Clé publique du serveur

récupérée

Authentification par pwd



ConfigurationConfiguration

� la paire de clés est générée grâce à la commande ssh_keygen

( ssh-keygen -t rsassh-keygen -t 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


Sécurisation des échanges : SSHTunnelingTunneling

� Très utile lorsque l’on veut établir une connexion sécurisée avec un serveur POP, IMAP par

exemple et qu’on ne dispose pas d’une version de ce serveur intégrant les fonctionnalités SSL

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

Client POP

Client SSH

Serveur POP

Serveur SSH

1

2

3

Communication chiffrée



� client[~] ssh -n -f serveurssh -L 1234:serveurimap: 143 -N

� client[~] telnet localhost 1234

� Trying 127.0.0.1...

� 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)

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)



� - Pour la lecture du courrier, le mieux est bien sû r de créer

un tunnel en utilisant comme port local le même por t 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 courr ier (ici

Netscape)le serveur IMAP

est la machine locale


Sécurisation des échanges : SSHTunneling : un autre exempleTunneling : un autre exemple� 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.


Sécurisation des échanges : SSHOuvrir le TunnelOuvrir le Tunnel� Sous Linux

toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:[email protected]

� Sous Windows

java.n7.fr

)7 par tunnel SSH

dans l'onglet « Session » :

1. Host name (or IP@) : java.n7.fr

2. Port : 22

3. Protocole : SSH

4. Saved sessions : N7 par tunnel

SSH


Sécurisation des échanges : SSHOuvrir le TunnelOuvrir le Tunnel dans l'onglet « SSH » puis Tunnel :

1. Source Port : 3128

2. destination : www-cache.n7.fr:3128

3. Cliquer sur « Add »

www-cache.n7.fr

dans l'onglet «session »

1. cliquer sur « save »

L3128 www-cache.n7.fr:3128


Sécurisation des échanges : SSHEmpreinter le TunnelEmpreinter le Tunnel

� maintenant que le tunnel est ouvert, on peut l'emprunter

� 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 :


Sécurisation des échanges : SSHEmpreinter le TunnelEmpreinter le Tunnel

� Exemple de config avec IE

– Allez dans Options, puis cliquez sur l'onglet Connections ; cliquez sur le bouton « Paramètres réseau »,

Cochez case « Utiliser un serveur proxy pour votre réseau local », et indiquez d'utiliser l'adresse localhost avec le port 3128 :



Empreinter le TunnelEmpreinter le Tunnel

� Maintenant, le tunnel est ouvert, et votre navigateur est disposé à l'emprunter.

� Demandez-lui d'aller à l'adresse http://www.intranet.n7.fr pour vérifier son bon

fonctionnement.

� Reboucher le tunnel

� Quand vous empruntez un tunnel, en règle générale, n'oubliez pas d'en sortir...

� 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.


Sécurisation des échanges : SSHOuvrir le TunnelOuvrir le Tunnel� Sous Linux

toto@ordinateur $ ssh -N -T -L 3128:www-cache.n7.fr:[email protected]

� Sous Windows

dans l'onglet « SSH » puis Tunnel :

1. Source Port : 3128

2. destination : www-cache.n7.fr:3128

3. Cliquer sur « Add »

www-cache.n7.fr


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


IPSec : intro� IntroductionIntroduction

– 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

� PropriétésPropriétés� confidentialité des données et protection contre l’analyse du trafic

� intégrité des données

� 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é


Composants crypto dans l’architecture InternetComposants crypto dans l’architecture InternetComposants crypto dans l’architecture InternetComposants crypto dans l’architecture Internet


IPSec : Mécanismes

� 22 mécanismes de sécurité viennent s’ajouter au traitement IP classique

– l’Authentication Header (AHAH)

– l’Encapsulation Security Payload (ESPESP)

� IPv6IPv6 : IPSec est supporté en natif dans IPv6;

� IPv4IPv4, 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


IPSec : les 2 modes d'échange� Mode transportMode 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’en-

tête IP, ne sont pas protégées.

� Mode tunnelMode tunnel

– 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.

� 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 à

un hôte traitant à son tour les protections restantes ou à une seconde passerelle de sécurité.


Description des modes d'IPSec

� Mode TransportMode 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

� Mode TunnelMode Tunnel : remplace les en-têtes IP originaux et 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.

� Mode NestingMode Nesting : hybride puisqu'il utilise les 2 modes � Encapsuler de l'IPSec dans de l'IPSec


Tunneling IPSec� TunnelTunnel ==> encapsulation datagrammes IP dans d’autres... Cela permet de :

– créer des réseaux privés virtuels (ou VPNVPN). � É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.

� propriétés générales des tunnels propriétés générales des tunnels �� VPNs : 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

Tunnel IPSec

Datagramme IP Datagramme IP Datagramme IP

Datagramme IPSec

Partie données du datagramme IPSec

Datagramme IP


IPSec : AH (propriétés 1/2)

� assure l’intégrité et l’authentification de l’origine des datagrammes IP

– Authenicité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é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é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


IPSec : AH (propriétés 2/2)

� L'intégrité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

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.


IPSec : AH (paramètres)

� 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

Valeur du compteur utilisée pour détecter les datagrammesd’IP rejoués afin d’assurer l’intégrité des séquences de datagrammes


IPSec : AH (modes)•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.


IPSec : AH (vérification)

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


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 transport, ESP assure :

– ConfidentialitéConfidentialité :

• la partie données des datagrammes IP transmis est chiffrée.

– Authentification de l'origine des donnéesAuthentification 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

– l'absence d'authentification nuit à la confidentialité

– UnicitéUnicité (optionnelle, à la discrétion du récepteur):

• protection contre rejeux

– Integrité des donnéesIntegrité des données (optionnelle) :

• les données n'ont pas été modifiées depuis leur émission


IPSec : Encapsulation Security Payload (ESP)

� 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 tunnel, deux avantages supplémentaires apparaissent:

– La confidentialitéconfidentialité, limitée, des flux / traffic des flux / traffic

• 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.

• 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.

– La confidentialitéconfidentialité des donnéesdes 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)


IPSec : ESP

� 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


IPSec : ESP

Mode tunnel

Portée de la confidentialité et de l'authentification en mode Transport & Tunnel

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.


IPSec : Différences AH // ESP

•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.86

Anas Abou El Kalam

IPSec : calcul données d'auth.

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 :

– EEKK(H(M)) (H(M)) où :

• 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)H(K, M, K), K étant lke secret partagé

• HMAC(K, M) = H(K⊕P1, H(K⊕P2, M)) où P1 et P2 sont deux chaînes de bits

constantes et représente l’opération d’ou-exclusif bit par bit.


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 !)

� (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,

� Configuration manuelle possible mais peu réaliste, - sûre pour réseau grande taille

==> configuration dynamique : protocole IKEIKE (Internet Key ExchangeInternet Key Exchange)

=> 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)88

Anas Abou El Kalam

IPSec : Internet Key Exchange (IKE)

� 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.

� Deux manières d'échanger des clefs sont abondamment utilisées :

– les clefs pré-partagées,

– les certificats X.509

• dans ce dernier cas, deux systèmes d'adresses initialement inconnues pourront protéger leurs échanges


IPSec : Association de sécurité (SA)

La Rfc 2401 Rfc 2401 (Security ArchitectureSecurity 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

termes de politique de sécurité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 SPDSPD (security policy security policy

databasedatabase),

– 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)


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 SASA (security associationsecurity association).

� 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

• un SPI,

• une @ IP de destination (éventuellement @ de broadcast ou de multicast),

• un protocole (AH ou ESP).

� Les SA actives sont regroupées dans une SADSAD (security association databasesecurity association database).

� 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).


IPSec : Association de sécurité (SA)� Les plus importants de ces termes sont :

– SPDSPD base de données définissant la politique de sécurité (protocole, ....)

– SASA une entrée de la SPD

– SADSAD 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)

– 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)

� 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


IPSec : architectureTrafic sortant

• Lorsque "couche" Ipsec reçoit data à envoyer, 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

Trafic entrant• 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é.


IPSec : architectures supportées

� 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.

– Néanmoins, les implémentations ne sont pas tenues d'offrir une telle flexibilité.

� Quatre typres d'architectures sont conforme à la RFC 2401

– Dialogue entre deux hôtes protégeant le trafic eux-mêmes

– Dialogue entre deux LANs à l'aide de passerelles de sécurité

– Dialogue entre deux hôtes traversant deux passerelles de sécuritéDialogue entre deux hôtes traversant deux passerelles de sécurité

– Dialogue entre un hôte et une passerelle de sécurité


IPSec : architectures supportées� Dialogue entre deux hôtes protégeant le trafic eux-mêmesDialogue entre deux hôtes protégeant le trafic eux-mêmes

� Deux hôtes engagent une comm IPsec, en encapsulant le protocole de haut niveau dans :

– en mode transport :

• datagrammes AH

• datagrammes ESP

• ou datagrammes ESP encapsulés dans datagrammes AH

– en mode tunnel :

• des datagrammes AH

• ou des datagrammes ESP

IP1 entête IP original

IP2 entête IP d'encapsulation

DCSDCS Donn.es des Couches Supérieures


IPSec : architectures supportées2- Dialogue entre deux LANs à l'aide de passerelles de sécurité2- Dialogue entre deux LANs à l'aide de passerelles de sécurité

� 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.

Ex: VPN avec IPSec


IPSec : architectures supportées

Dialogue entre deux hôtes traversant deux Dialogue entre deux hôtes traversant deux

passerellespasserelles

� 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.

� 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.


IPSec : architectures supportées4- 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 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’intranetl’intranet

� 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é.

� 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.


IPSec : Ex d'implémentations d'IPSEC

OpenBSDOpenBSD� intégration native dans la pile IP du noyau

� 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/WANFreeS/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



� Ex avec FreeS/Wan :

– mise en place d’IPsec en mode transport entre 2 machines

� 1er cas : échange de clés dynamique en utilisant IKE, par secret partagé

� 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 ipsec en mode transport

Left=193.50.169.115 @IP des 2 machines

right=193.50.169.116

authby=secret authentification par secret partagé

auto=start 100 Anas Abou El Kalam


� Ex avec FreeS/Wan :

– mise en place d’IPsec en mode transport entre 2 machines

� 2ème cas : échange de clés dynamique en utilisant IKE, par clés publiquesclés publiques


IPSec : C/C

� 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,

– 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.

� permet également de protéger des protocoles de bas niveau comme ICMP et IGMP, RIP, etc...

� 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é :

– sa grande complexité rend son implémentation délicate.


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


VPN : intro� C'est un réseau privé qui repose sur une infrastructure publique (Internet)

� 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")

– faire circuler les informations de l'entreprise de façon cryptée d'un bout à l'autre du tunnel.

• U ont l'impression de se connecter directement sur réseau de leur entreprise


VPN : principe de tunneling� 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.

� 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.

– 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.


VPN : principe

� L’encapsulation (ou tunneling) de paquets dans d’autres paquets

� Exemple avec IP (A envoie un paquet à B) :


VPN : Le VPN d'accès

� 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.

� ∀ méthode ==> l'importance dans le VPN d'avoir une authentification forte des U.

– e.g., vérification "login / mot de passe", "Tokens sécurisés" (pwd aléatoires), certificats, ...


VPN : L'intranet VPN

� 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é avec d'autres techniques comme l'encapsulation IP dans IP pour assurer sécurité raisonnable.


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é.

� 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 principeprincipe : 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


VPN : implémentations

� Protocoles de niveau 2 comme

– PPTP de Microsoft

– L2tp (Layer Two Tunneling Protocol) proposé par l’IETF.

� Protocoles de niveau 3niveau 3 comme

– IPSec

– MPLS


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


Plan

�SSLSSL

�SSHSSH

�IPSecIPSec

�VPNVPN

�S-MIMES-MIME

�PGPPGP


Aspects juridiques

1997

Recommandation97/489/CE

« Lien entre le titulaireet l’émetteur »

1999

Directive1999/93/CE« Signature

électronique »

2000

Directive2000/31/CE« Commerceélectronique »

Loi2000-230

Décret2001-272

2001

EUROPE

FRANCE

� Evolution juridique de la signature électroniqueEvolution juridique de la signature électronique


La Directive 1999/93/CE

� La Directive européenne 1999/93/CELa 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 :

� Article 2 : définitions Article 2 : définitions – 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



� ArticleArticle 5 : reconnaissance légale de la signature 5 : reconnaissance légale de la signature électroniqueélectronique– La signature électronique doit être acceptée au même titre qu’une signature

manuscrite pour autant que :• 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 4 : principe de la libre circulation sur le marché Article 4 : principe de la libre circulation sur le marché intérieurintérieur– 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 Article 3 : absence d’autorisation préalable et accès au marché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



� Article 6 : responsabilité des prestataires de Article 6 : responsabilité des prestataires de certificationcertification– 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

� Article 8 : protection des données personnellesArticle 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)



� Article 7 : la dimension internationaleArticle 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

� Articles 9 & 10 : création d’un comité de Articles 9 & 10 : création d’un comité de conseilconseil– Un comité est créé pour assister la CE dans les décisions concernant la signature électronique


La Loi 2000-230

� La Loi 2000-230 modifie quelques articles du code civilLa Loi 2000-230 modifie quelques articles du code civil

� L’article 1316 : la preuve écrite est indépendante du L’article 1316 : la preuve écrite est indépendante du support ou du mode de transmissionsupport ou du mode de transmission

� L’article 1316-1 : la signature électronique est acceptée L’article 1316-1 : la signature électronique est acceptée en tant que preuve à condition qu’elle possède les en tant que preuve à condition qu’elle possède les propriétés d’authentification et d’intégritépropriétés d’authentification et d’intégrité

� L’article 1316-2 : le règlement des conflits, lorsqu’il n’y a 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 pas de texte explicite, se fait par le juge en utilisant la preuve la plus vraisemblable, quelque soit le supportpreuve la plus vraisemblable, quelque soit le support

� L’article 1316-3 : l’écrit électronique a la même force L’article 1316-3 : l’écrit électronique a la même force probante que l’écrit sur papierprobante que l’écrit sur papier


La Loi 2000-230

� L’article 1316-4 : institution de la propriété officielle L’article 1316-4 : institution de la propriété officielle de la signature et équivalence de la signature de la signature et équivalence de la signature électronique lorsqu’elle est établie par un électronique lorsqu’elle est établie par un processus fiableprocessus fiable

� L’article 1317 : extension de l’acte authentique au L’article 1317 : extension de l’acte authentique au support électronique support électronique

� L’article 1326 : un acte unilatéral engagant un L’article 1326 : un acte unilatéral engagant un signataire doit être écrit signataire doit être écrit par lui-mêmepar lui-même, la , la précedente version de l’article indiquant précedente version de l’article indiquant par sa par sa mainmain

� Le décret 2001-272 suit la Directive 1999/93/CE et Le décret 2001-272 suit la Directive 1999/93/CE et offre un cadre opérationnel pour la Loi 2000-230offre un cadre opérationnel pour la Loi 2000-230

Documents

Sécurité des RO Rappel: Utilités la sécurité à tous les ...irt.enseeiht.fr/anas/cours/moyens.pdf · Présentation Application : S-MIME, PGP, Sbox, OTP Boîtier de chiffrement