objectifs de la sécurité sécurité des...

Sécurité des LAN

1. Architectures� Firewall� DMZ� NAT� Proxy� VPN (PPTP, L2TP, IPSec)

3. Authentification� Locale sous Linux� Locale sous Windows � Kerberos� CHAP et MS-CHAP � 802.1x et EAP� VPN (PPTP, L2TP, IPSec)

2. Cryptage� Principes � Hash� Signatures� Certificats et PKI � SSL� SSH� HTTPS

� 802.1x et EAP� RADIUS

4. LANs et WLANs sécurisés� Ethernet � WiFi (WEP, WPA)� Bluetooth� ZigBee� WiMax

1Ingénieur 2000 - IR2 Sécurité des LAN S. Lohier

La sécurité informatique vise généralement quatre objectifs principaux :

� L'intégrité, consiste à garantir que les données n'ont pas été altérées sur la machine ou durant la communication ;

� La confidentialité, consiste à assurer que seules les personnes autorisées aient accès aux ressources ;

� La disponibilité, consiste à garantir l'accès à un service ou à des ressources ; La non répudiation, permet de garantir qu'aucun des correspondants ne

Objectifs de la sécurité 4 objectifs

� La non répudiation, permet de garantir qu'aucun des correspondants ne pourra nier la transaction ;

� L'authentification est un des moyen qui permet de garantir la confidentialité.Elle consiste à s’assurer de l'identité d'un utilisateur, un contrôle d'accès (login et mot de passe crypté) permet de limiter l'accès à certaines ressources (lecture seule sur tel répertoire…).


Objectifs de la sécurité Moyens pour les atteindre

Confidentialité

Identification

CryptageFiltrage

Antivirus

Filtrage

VPN

Authentification

Espions

Hackers


IntégritéDisponibilité

Backup

Antivirus

Filtrage

Cryptage

Authentification

Redondance

InformationHackers

Virus

Erreurs

Pannes

Hackers

� Le firewall ou pare-feux est chargé de filtrer les accès entre l’Internet et le réseau localou entre deux réseaux locaux.

� La localisation du firewall (avant ou après le routeur, avant ou après le NAT..) eststratégique.

� Suivant la politique de sécurité, le filtrage est appliqué différemment sur les interfacesd’entrée et de sortie (blocage des adresses IP privées entrantes…).

Serveurs

d’accès

1. Architectures Firewall : Principe

Réseau interne Firewall

Routeur

Internet

Intranet

DMZ Serveurs

accessibles

depuis InternetNomades


� Le filtrage de paquets sur Firewall permet de router les paquets entre les hôtesinternes et externes de manière sélective.

� Le filtrage intervient à différents niveaux dans la mesure où chaque paquet possèdeun ensemble d’en-tête spécifiques :� adresse IP source ou destination ;� port TCP ou UDP source ou destination ;� Flags de l’en-tête TCP (SYN, ACK…) ;� type de message ICMP ou HTTP (filtrage applicatif)…

� Le filtrage peut également intervenir au niveau des en-têtes de trame (filtrage desadresses MAC source ou destination ).

1. Architectures Filtrage de paquets


� Le firewall peut également empêcher les connexions entrantes enopérant sur le bit ACK de l’en-tête TCP :� lors d’une demande de connexion, le bit ACK du premier segment TCP est

à 0, les bits ACK des segments suivants sont généralement tous à 1.� Il suffit donc de bloquer les segments entrants avec le bit ACK à 0, les

segments suivants pour cette connexion ne seront pas pris en compte.

SYN=1 ACK=0

Demande d’ouverture de connexion

Phase de connexion TCP

1. Architectures Filtrage sur les entrées

SYN=1 ACK=1

SYN=0 ACK=1

ACK=1 Data

ACK=1 Data

Phase de connexion TCP

Phase d’échange de donnéesACK=1 Data

Agresseur


1. Architectures Règles d’un Firewall

� Les règles décrivent l'ensemble des services qui doivent être acceptés par le firewall.

� La stratégie appliquée est : tout ce qui n'est pas explicitement autorisé est interdit (et non le contraire…).

� Elles sont basées sur les informations des segments ou des paquets.� Les caractéristiques de chaque paquet sont comparés aux règles, les

unes après les autres.� Si la règle correspond aux caractéristiques du paquets, alors celui-ci � Si la règle correspond aux caractéristiques du paquets, alors celui-ci

est accepté.


� Les règles A et B permettent aux machines locales (192.168.0.0) d’ouvrir une connexion sur un serveur web (port 80) externe.

� Émission (règle C) ou réception (règle D) de courrier SMTP (port 25) avec unserveur externe.

� Les paquets entrants depuis des supposés serveurs SMTP ne peuvent passerque si la connexion a été initiée de l’intérieur (règle D).

� Blocage de toute autre connexion (règle E).

1. Architectures Exemple de règles d’un firewall

Règle Direction @ source @ dest. Protocole Src Port Dst Port ACK=1 Action

A Out 192.168.0.0 0.0.0.0 TCP >1023 80 Permit

B In 0.0.0.0 192.168.0.0 TCP 80 >1023 Permit

C Out 192.168.0.0 0.0.0.0 TCP >1023 25 Permit

D In 0.0.0.0 192.168.0.0 TCP 25 >1023 Yes Permit

E All All All All All All Deny


1. Architectures Firewall : Stateless ou statefull

� Le Firewall «statefull» :� Réalise un suivi de connexion ;� Différents états pour une connexion :

� NEW. La connexion est créée (par ex., un client envoie sa première requête vers un serveur web.

� Le Firewall «stateless»� Filtrage simple de paquets ;� Basé sur les adresses, les ports, les entrées ou

des informations de la couche application.

Ingénieur 2000 - IR2 Sécurité des LAN S. Lohier 9

serveur web. � ESTABLISHED. Connexion déjà initiée, suit une connexion NEW déjà passée. � RELATED. Peut être une nouvelle connexion, mais présente un rapport direct avec une

connexion déjà connue. � INVALID. Pour tous les paquets suspects suivant des règles prè-établies.

� Exemple de stratégie :� Toutes les connexions NEW qui viennent du LAN et qui vont sur le NET port 80 sont

acceptées. Tous les clients du LAN peuvent interroger tous les serveurs web du NET ;� Toutes les connexions RELATED et ESTABLISHED qui viennent du NET port 80 sont

autorisées à rentrer. Les serveurs peuvent répondre ;� Toutes les connexions RELATED et ESTABLISHED qui sortent du LAN sont autorisées.

Les connexions peuvent se poursuivre, même si elles ouvrent de nouvelles connexions. � Toutes les connexions INVALID, d'où qu'elles viennent sont rejetées.

� Sur les routeurs Cisco, les ACL (Access Control Lists) permettent de filtrer les paquets entrants ou sortant en fonction des adresses IP source et destination.

� Il existe 2 types d'ACL� Standard : uniquement sur les IP sources ;� Etendue : sur quasiment tous les champs des en-têtes IP, TCP et UDP.

� Le filtrage sur les paquets peut intervenir :� sur l’interface d’entrée, avant le processus de routage ;� sur l’interface de sortie, après le processus de routage.

1. Architectures Firewall : les ACL Cisco


� Le paquet est vérifié par rapport au 1er critère défini sur les informations contenues dans les en-têtes IP, TCP ou UDP :� S'il vérifie le critère, l'action définie est appliquée ;� Sinon le paquet est comparé successivement aux ACL suivants ;

� S'il ne satisfait aucun critère, l'action deny est appliquée.

� Des masques sont utilisés pour pouvoir identifier une ou plusieurs adresses IP en une seule définition.

� Le masque défini la portion de l'adresse IP qui doit être examinée :0.0.255.255 signifie que seuls les 2 premiers octets doivent être examinés ;

1. Architectures Firewall : logique des ACL Cisco

� 0.0.255.255 signifie que seuls les 2 premiers octets doivent être examinés ;� deny 10.1.3.0 avec 0.0.0.255 : refus de toutes les IP commençant par 10.1.3.

� Syntaxe d'une règle standard :access-list number [deny|permit] source [source-wildcard]� number compris entre 1 et 99 ou entre 1300 et 1999� Source-wildcard : masque pour la source

� Syntaxe d'une règle étendue :access-list number [deny|permit] protocol source source-wildcard destination dest.-wildcard� number : compris entre 100 et 199 ou 2000 et 2699


1. Architectures Firewall : exemples d’ACL Cisco

access-list 1 deny 172.16.3.10 0.0.0.0 (ou deny host 172.16.3.10)access-list 1 permit 0.0.0.0 255.255.255.255 (ou permit any)

� Refuse les paquets d'IP source 172.16.3.10. Le masque (également appelé wildcard mask) signifie ici que tous les bits de l'adresse IP sont significatifs.

� La dernière règle autorise toutes les autres adresses (le masque signifie qu’aucun n’est significatif)

access-list 2 permit 172.16.3.0 0.0.0.255� Autorise tous les paquets d'IP source 172.16.3.0/24.� Différence avec access-list 2 permit 172.16.3.0 0.0.0.0 ?


� Différence avec access-list 2 permit 172.16.3.0 0.0.0.0 ?

access-list 101 deny ip any host 10.1.1.1� Refus des paquets IP à destination de la machine 10.1.1.1 et provenant de

n'importe quelle source

access-list 102 deny tcp any gt 1023 host 10.1.1.1 eq 23� Refus de paquet TCP provenant d'un port > 1023 et à destination du port 23 de

la machine d'IP 10.1.1.1

access-list 103 deny tcp any host 10.1.1.1 eq http� Refus des paquets TCP à destination du port 80 de la machine d'IP 10.1.1.1

1. Architectures Firewall : quizz ACL Cisco


1. Architectures Firewall sous Linux

� Netfilter est le module qui fournit à Linux les fonctions de pare-feu, de translation d’adresse (NAT) et d'historisation du trafic réseau.

� Netfilter fonctionne en mode noyau. � Il intercepte et manipule les paquets IP entrant et sortant de votre machine.

� iptables est le programme qui permet à un administrateur de configurer Netfilter.� iptables est installé par défaut dans toutes les distributions Linux et est utilisable en

mode commande.� Des interfaces graphiques sont disponibles pour modifier plus aisément les règles de

filtrage ou de translation.


filtrage ou de translation.

1. Architectures Firewall sous Linux : chaînes

� Par défaut, le programme iptables utilise la table « filter » qui contient trois listes de règles ;

� Ces listes sont appelées chaînes de firewall ou juste chaînes.� Les trois chaînes sont nommées INPUT, OUTPUT et FORWARD :

� La chaîne INPUT permet de décider ce que l’on fait d’un paquet entrant. Il peut être accepté (ACCEPT) ou rejeté (DROP) ;

� La chaîne OUTPUT permet de la même façon de fixer le sort des paquets sortants (ceux qui sont générés localement) ;

� La chaîne FORWARD permet de traiter un paquet entré après l’avoir routé vers une autre interface réseau.


Décision de

routage

Processus

local

OUTPUT

ACCEPT

DROP

FORWARD

ACCEPT

DROP

INPUT

ACCEPT

DROP

Entrée

Sortie

1. Architectures Firewall sous Linux : chaînes (2)� Une autre table est utilisée pour les translations d’adresses : la table « nat ». Elle

utilise 3 chaînes :� PREROUTING, c'est la chaîne qui va être utilisée pour faire du DNAT (Destination NAT) :

translation sur adresse destination avant le processus de routage.Ex : pour un paquet entrant vers un serveur web interne et masqué, le routeur va remplacer sa propre IP par l’IP du serveur web.

� POSTROUTING, à la sortie du routeur et utilisée pour faire du SNAT (Source NAT) : masquage d'adresse source après le processus de routage.Ex : un ordinateur local veut sortir sur le WAN, le routeur va remplacer l'IP du paquet émis en local par sa propre IP.

� OUTPUT, cette chaîne va traiter les réponses émises en local si le paquet avait pour destination le routeur, comme dans le cas de la table filter.


destination le routeur, comme dans le cas de la table filter.

Décision de

routage

Processus

local

OUTPUT

ACCEPT

DROP

POSTROUTING

ACCEPT

DROP

PREROUTING

ACCEPT

DROP SortieEntrée

1. Architectures Firewall sous Linux : règles

� Chaque chaîne est composée d'un ensemble de règles.� Quand un paquet atteint une chaîne celle ci va examiner cet ensemble règle par règle

pour trouver celle qui lui correspond.� Si c'est le cas alors cette règle lui sera appliquée.� Finalement s'il n'y a pas de règle qui corresponde à ce paquet, une politique par défaut

sera appliquée.

� La commande iptables permet de spécifier des règles de sélection des paquets IP dans les trois chaînes (INPUT, OUTPUT et FORWARD).


les trois chaînes (INPUT, OUTPUT et FORWARD).� Les paquets sont sélectionnées suivant la combinaison :

� adresse source, adresse destination ;� protocole (tcp, udp, icmp, all) ;� numéro de port.

� Pour chaque règle de sélection, on définit une politique : accepter (ACCEPT) ou rejeter (DROP) le paquet.

� Exemple : on rejette les pings entrants :# iptables -A INPUT -i eth0 -p icmp -j DROP

1. Architectures DMZ : principe

� Une zone démilitarisée (DMZ DeMilitarised Zone) est une zone de réseauprivée ne faisant partie ni du réseau interne ni de l’Internet.

� À la manière d'une zone franche au delà de la frontière, la DMZ permet deregrouper des ressources nécessitant un niveau de protectionintermédiaire.

Serveurs

d ’accès

Réseau interne Firewall

Routeur

Internet

Intranet

DMZ Serveurs

accessibles

depuis InternetNomades


� Un niveau supplémentaire de sécurité peut être introduit avec un 2ème

firewall.� Les règles d’accès sur le firewall du réseau Interne sont plus restrictives.� La DMZ est située entre les deux firewalls (DMZ « en sandwich ») avec des

règles moins restrictives introduites par le premier firewall.

Serveurs

1. Architectures DMZ : 2 niveaux de Firewall

Réseau interne FirewallInternet

IntranetDMZ

d ’accès

Nomades

Firewall


1. Architectures Proxy

� Un système mandataire (proxy) repose sur un accès à l’Internet par une (ou plusieurs)machine dédié (le serveur mandataire ou Proxy server) qui joue le rôle de mandatairepour les autres machines locales et exécutent les requêtes de ces dernières.

� Un serveur mandataire est configuré pour un ou plusieurs protocoles de niveauapplicatif (HTTP, FTP, SMTP…) et permet de centraliser , donc de sécuriser, lesaccès extérieurs (filtrage applicatif et masquage des adresses des clients).

� Les serveurs mandataires configurés pour HTTP permettent également le stockage depages Web dans un cache pour accélérer le transfert des informations fréquemmentconsultées vers les clients connectés (Proxy cache).


1. Architectures NAT : principe

� La translation d’adresses est basée sur l’utilisation des adresses privées, nonroutables sur Internet :

� Elle permet d’isoler le trafic local du trafic public de l’internet et nécessitel’utilisation d’un translateur d’adresse (NAT - Network Adress Translator).

� Le NAT qui peut être localisé sur le routeur/firewall ou le proxy peut travaillersuivant 3 types de translation :� n @ privées vers 1 @ publique ;� n @ privées vers m @ publiques ;

Classe A10.0.0.0

Classe B172.16. 0.0 à 172.31.0.0

Classe C192.168.0.0 à 192.168.255.0

� n @ privées vers m @ publiques ;� 1 @ privée vers 1 @ publique.


1. Architectures NAT : translation dynamique

� Initialement la table de translation est vide.� Quand un paquet sort, l'adresse source est remplacée par une adresse publique.� Les adresses et ports source et destination internes et externes sont inscrits.� Quand une réponse à un paquet arrive depuis Internet, la source interne qui correspond à la

destination du paquet est cherchée dans la table.� La destination est remplacée par la source interne.


1. Architectures Exemple : NAT vu par Cisco

1. Le PC 10.1.1.1 envoie son premier paquet vers le serveur 170.1.1.1.2. Le routeur NAT configuré pour translater les adresses 10.1.1 ajoute une entrée dans sa table

pour 10.1.1.1 en tant qu’adresse locale.3. Le NAT alloue une adresse disponible prise dans sa liste d’adresses globales (200.1.1.1) et

l’ajoute dans sa table de translation.4. Le routeur/NAT translate l’adresse IP source et relait le paquet.


� Quand deux connexions ne sont différentes que par l'adresse interne : collision� On peut utiliser un pool d'adresses publiques et utiliser des adresses sources externes

différentes.� On peut changer le port source externe (Port and Adress Translation : PAT).

� Le NAT dynamique ne permet pas l'établissement de connexions entrantes (bonne protection par défaut).

1. Architectures NAT et PAT


1. Architectures VPN� La sécurité passe également par l’utilisation de réseaux privés virtuels (VPN : Virtual

Private Networks).� Un VPN est constitué d’un ensemble de LAN privés reliés à travers Internet par un

« tunnel » sécurisé dans lequel les données sont cryptées.� Les postes distants faisant partie du même VPN communiquent de manière sécurisée

comme si ils étaient dans le même espace privé.� La technique de « tunneling » utilisée permet :

� d’identifier chaque extrémité ;� de transférer les données après cryptage.


1. Architectures Vue physique et vue virtuelle d’un VPN


1. Architectures Exemple de VPN vu par Cisco

1. PC1 (10.2.2.2) envoie un paquet vers le serveur web S1 (10.1.1.1) comme il le ferait si ce dernier était sur le même LAN.

2. Le routeur qui joue le rôle de passerelle VPN encrypte le paquet, ajoute les en-têtes VPN et un nouvel en-tête IP (avec les @ publiques) et relaie le paquet.

3. Le « man in the middle » peut intercepter le paquet mais ne peut lire ni son contenu ni les adresses privées.

4. Le routeur/firewall ASA-1 reçoit le paquet, confirme l’identité de l’émetteur, confirme que le paquet n’a pas été modifié, et décrypte le paquet original.

5. Le serveur S1 reçoit le paquet décrypté.


1. Architectures Protocoles VPN

� Eléments de base :� Protocole de VPN sur les routeurs ou les PCs (portables) ;� Encapsulation des paquets pour leur voyage à travers Internet ;� Chiffrement des données pour garantir la confidentialité.

� Différents niveaux de protocoles� Protocole de niveau 2

� Microsoft : PPTP - Point to Point Tunneling Protocol� IETF : L2TP - Layer 2 Tunneling Protocol

Résultat de la fusion du protocole L2F - Layer 2 forwarding de Cisco et de PPTP de Microsoft

� Protocole de niveau 3 (GRE, IPSEC, MPLS)� Protocole de niveau 4 (SSL, TLS)


1. Architectures VPN : protocole PPTP

� Pour accéder à distance à un réseau non sécurisé, on se connecte à un serveur d’accès distant ou Remote Access Server (RAS).

� La méthode classique consiste à se connecter au RAS directement par modem (protocole PPP).

� Dans le cas d’un VPN, le serveur RAS devient une passerelle VPN à laquelle on accède par le protocole PPTP.

� La passerelle VPN doit également être connecté à Internet, par exemple par une connexion PPP modem vers un ISP.

Passerelle VPN

Réseau non sécurisé

Réseau type VPN

Passerelle VPNlogicielle


1. Architectures VPN : encapsulation PPTP

� Le protocole PPTP chiffre et encapsule (fait passer par un « tunnel crypté») ledatagramme IP dans le cadre d’une connexion point à point.

� Le serveur VPN à l’entrée du tunnel exécute l'ensemble des contrôles de la sécurité etdes validations, et active le cryptage des données.

� Une trame PPTP est donc constituée :� Du datagramme IP contenant les données utiles et les adresses IP de bout en bout ;� De l’en-tête PPP nécessaire pour toute connexion point à point ;� D’un en-tête GRE (Generic Routing Encapsulation) qui gère l’encapsulation et permet d’isoler les

flux IP privé et public ;� D’un nouvel en-tête IP contenant les adresses IP source et destination des passerelles VPN

(client et serveur VPN).

� Avant d'établir le tunnel GRE, une connexion TCP (port 1723) est utilisée :� négociation des paramètres ;� authentification de l'utilisateur ;

� La négociation se fait en clair.� La version courante utilise des clés de 128 bits aléatoires.


1. Architectures VPN : protocole L2TP

� L2TP (Layer 2 Tunneling Protocol) � Protocole standardisé par l'IETF (Internet Ingineering Task Force).� Extension de PPP qui permet de terminer une connexion non pas à l'autre

modem mais à une adresse IP quelconque.� Les paquets PPP sont encapsulés dans des paquets UDP pour le transport

par Internet.� Remplace la solution propriétaire PPTP.� N'a pas de chiffrement (nécessite IPSec).


PPP

1. Architectures VPN : encapsulation L2TP

� L2TP offert par l’ISP :� Le tunnel L2TP rallonge la connexion PPP du client jusqu'au serveur d'accès à distance.

PPP

� L2TP réalisé par le client :� Le client doit gérer 2 connexions PPP : une vers l'ISP et une vers le serveur d'accès.


1. Architectures VPN : protocole IPSEC

� Protocole lié à IPV4 et IPV6 et assurant l'authentification et l'encryptage desdonnées au travers de l'internet.

� Essentiellement employé dans les VPN.� Deux protocoles pour le chiffrement et l'authentification : ESP, AH.� Un protocole d'échange de clé : IKE (Internet Key Exchange).

� Deux modes d'opération : � transport : ne protège que les données des paquets transmis ;� tunnel : le paquet entier est encapsulé dans un nouveau paquet.

� Pour chaque connexion TCP protégée, la Security Association (SA) mémorise :� les algorithmes ;� les clés ;� la durée de validité des clés ;� les n°de séquence et l'identité des partenaires.


1. Architectures VPN : paquet IPSEC

IPSEC : Authentication Header (AH)

� L'ajout d'un en-tête d'authentification permet de vérifier l'authenticité et l'intégrité des paquets.

� Il n’y a pas de chiffrement des données.

� L'authentification est faite sur :� les données qui suivent l'en-tête AH ;� sur l'en-tête AH ;� sur les champs importants de l'en-tête IP (source, destination,

protocole, longueur, version).


1. Architectures VPN : paquet IPSEC

IPSEC : Encapsulated security payload (ESP)

� L'enveloppe ESP permet de chiffrer et d'authentifier les paquets ;� L‘enveloppe ESP contient :

� L’en-tête (header) ;� Les données chiffrées ;� Une queue (trailer) ;� Des données supplémentaires d'authentification (optionnel).� Des données supplémentaires d'authentification (optionnel).

� Le chiffrement ne porte que sur les données encapsulées et le trailer.� Il ne porte pas sur les champs de l'en-tête et les données

d'authentification.� L'authentification optionnelle porte sur l'en-tête ESP et tout ce qui suit,

mais pas sur l'en-tête IP.


1. Architectures VPN : modes IPSEC

IPSEC : Modes transport et tunnel� En mode transport, on chiffre ou on authentifie la partie data d'un paquet IP.� En mode tunnel on protège le paquet complet et on l'encapsule dans un nouveau paquet.

� En mode transport la sécurité est faite de bout en bout.

� En mode tunnel elle peut être faite par des routeurs intermédiaires.


1. Architectures VPN : modes IPSEC

2 types de VPN avec IPSec :� L2TP sur IPSec en mode transport (mode Microsoft) :

� transporte n'importe quel protocole (IP, IPX, NetBeui) ;� Beaucoup d'en-têtes et d'encapsulations.

� IPSec en mode tunnel.� ne peut transporter que IP ;� plus efficace.

IPSEC : Internet Key Exchange (IKE)� Sert à négocier les paramètres pour les protocoles AH et ESP (algos, clés,

durée de validité,…)� Authentifie les partenaires par secrets partagés, clé publiques ou

certificats.� Deux phases :

� Phase1 : négocie une SA (Security Association : enregistrement contenant les paramètres pour AH et ESP) pour protéger les négociations.

� phase 2 : définit les SA nécessaires pour des flux ESP ou AH.37Ingénieur 2000 - IR2 Sécurité des LAN S. Lohier

� Le but de la cryptographie est de garantir la confidentialité, l'authenticité et l'intégrité des données échangées.

� Il existe à l’heure actuelle deux grands principes de chiffrement ou cryptage : � le cryptage symétrique basé sur l’utilisation d’une clé privée (ou algorithme)

partagée entre les deux parties communicantes.� La même clé sert à crypter et décrypter les messages.� Il faut trouver un moyen sécurisé de communiquer la clé aux deux entités.

2. Cryptage Principes

Cryptage DécryptageDonnéescryptées

Clé privée Clé privée

Bonjour BonjourGa&buz


2. Cryptage Cryptage symétrique/asymétrique

� Le cryptage asymétrique utilise deux clés différentes pour chaque utilisateur :� une est privée et n’est connue que de l’utilisateur ;� l’autre est publique et peut être transmise sur Internet.

� Les clés publique et privée sont mathématiquement liées par l’algorithme de cryptage (la clé publique est « fabriquée » à l’aide de la clé privée) de telle manière qu’un message crypté avec une clé publique ne puisse être décrypté qu’avec la clé privée correspondante.

� Une clé est donc utilisée pour le cryptage et l’autre pour le décryptage.

Cryptage DécryptageDonnéescryptées

Clé publique Clé privée

Bonjour BonjourYe&zic


Principe de l’algorithme de chiffrement RSA (Rivest, Shamir et Adelman – MIT) :

� M : message,� C : message chiffré.

� Pour chiffrer on calcule :C = Me mod n(Rappel : x modulo n = y si x - y est un multiple de n. Ex : 33 mod 7 = 6)

2. Cryptage Exemple de chiffrement : RSA

� Pour déchiffrer :M = Cd mod n

� La clé publique est le couple (e,n).� La clé privée est le couple (d,n).� n est le produit de deux nombres premiers p,q (environ 100 chiffres).� e et d sont dérivés de p et q.

� Il "suffit" de factoriser n pour cracker RSA.


� Pour les algorithmes symétriques :� 40 bits (240 possibilités)� 56 bits � 64 bits (algorithme DES: Data Encryption Standard) � 128 bits (algorithme AES: Advanced Encryption Standard)

2. Cryptage Longueur des clés

� Pour RSA:� il n'y a que les nombres premiers qui peuvent être des candidats.� 512 bits équivaut à 56 bits (minimum en asymétrique).� 1024 bits (taille courante).� 2048 bits équivaut à 128 bits.


� Un algorithme de hachage est une fonction mathématique qui convertit une chaîne de caractères d'une longueur quelconque en une chaîne de caractères de taille fixe appelée empreinte ou « hash » ou encore « digest ».

� Cette fonction est dite irréversible et résistante aux collisions :� Il est impossible de trouver le message lorsqu'on connaît le hash ;� 2 messages différents ne produiront "jamais" le même hash.

� Ce type de fonction cryptographique est donc conçu de façon qu'une modification même infime du message initial entraîne une modification du hash.

� Si un message est transmis avec son hash, le destinataire peut vérifier son intégrité en recalculant son hash et en le comparant avec le hash reçu.

2. Cryptage Hacher pour mieux chiffrer

intégrité en recalculant son hash et en le comparant avec le hash reçu.� Exemples d’algorithme de hachage : SHA-1 (160 bits), MD5 (128 bits) – Message

Digest


� Pour signer un message, on peut le chiffrer avec la clé privée.� Le déchiffrement avec la clé publique prouve que seul le détenteur de la clé privée à pu créer la

signature.

� Il n'est pas nécessaire de chiffrer tout un document pour le signer, il suffit de chiffrer son hash.� La résistance aux collisions de la fonction de hachage garantit que c'est bien ce document qui a été

2. Cryptage La signature

� La résistance aux collisions de la fonction de hachage garantit que c'est bien ce document qui a été signé.


� Si on utilise un chiffrement symétrique pour chiffrer le hash on obtient une authentification, pas une signature.

� L’objectif final est le même : s’assurer de l’identité de l’expéditeur.� La clé nécessaire pour vérifier le hash permet aussi de le créer.� Si la clé n'est connue que par les deux partenaires, alors elle permet d'authentifier l'expéditeur

du message.� Exemples : HMAC-SHA, HMAC-MD5� Plutôt que de chiffrer le hash, on fait intervenir la clé lors du calcul du hash.� Un hash ainsi généré est appelé un MAC (Message Authentication Code).

2. Cryptage Signature et authentification


� Pour pouvoir utiliser des algorithmes symétriques (chiffrement, MAC) il faut d'abord échanger une clé privée avec son partenaire.

� Echange de clé RSA :� Alice choisit une clé symétrique.� Alice chiffre la clé symétrique avec la clé publique (RSA) de Bob. Elle sera sûre que

seul Bob pourra déchiffrer cette clé symétrique.� Alice transmet à Bob cette clé symétrique cryptée.� Une fois que Bob reçoit le message, il le déchiffre et peut alors utiliser la clé

2. Cryptage Problème pour échanger les clés

� Une fois que Bob reçoit le message, il le déchiffre et peut alors utiliser la clé symétrique définie par Alice pour lui envoyer des messages chiffrés que seuls lui et Alice pourront alors déchiffrer.


� Echange Diffie-Hellman (utilisé dans SSH)� Permet de générer une clé symétrique sans avoir à la transmettre.� Seules deux valeurs calculées à partir d’un nombre aléatoire sont échangées :

� Alice et Bob ont choisi un groupe et une génératrice g de ce groupe.� Alice choisit un nombre au hasard a, élève g à la puissance a, et transmet ga. à Bob ;� Bob fait de même avec le nombre b.� Alice, en élevant le nombre reçu de Bob à la puissance a, obtient gba et la clé K.� Bob fait le calcul analogue et obtient gab, qui est le même. � Il est difficile d'inverser l'exponentiation dans un corps fini, c’est-à-dire de calculer le

logarithme discret. « Man in the Middle » ne peut pas découvrir a et b, donc ne peut pas

2. Cryptage Problème pour échanger les clés

logarithme discret. « Man in the Middle » ne peut pas découvrir a et b, donc ne peut pas calculer gab.


� Le chiffrement asymétrique est plus utile.� Elimine le problème du transfert de la clé.� Permet de signer des messages.

� Le chiffrement symétrique est beaucoup plus performant.� Pour profiter de l'efficacité du chiffrement symétrique et des avantages de l'asymétrique :

� On chiffre le message avec une clé symétrique.� On chiffre la clé symétrique avec la clé publique du destinataire.

� On joint la clé chiffrée au message.

2. Cryptage Asymétrique ou symétrique ?


Intérêt des certificats� La distribution de clés publiques est sujette à l'attaque d'un intermédiaire

(Man in the Middle).

2. Cryptage Les certificats

Ce qui devrait se passer lorsqu’Alice veut envoyer un message à Bob :

Ce qui pourrait se passer…


� Un certificat est un document qui sert à prouver qu'une clé appartient bien à qui de droit.

� Le certificat est signé par un tiers dont on connaît la clé publique (notez la récursion).

� Un certificat contient au moins les informations suivantes :

2. Cryptage Intérêt des certificats

� Un certificat contient au moins les informations suivantes :� Identité (Nom et adresse e-mail de la personne).� Clé publique.� Date d'expiration.� Signature du certificat.

� Il existe deux types de certificats prévalents :� PGP - Pretty Good Privacy (Open).� X.509.


� Bob à généré par l’intermédiaire d’un tier (Trent) son couple de clés publique/privée.� Trent à signé avec sa propre clé privée un certificat liant la clé publique de Bob à son

nom.� Bob transmet non pas directement sa clé publique mais le certificat qui contient sa clé

publique et la signature de Trent.� Si Alice est en possession de la clé publique de Trent, elle peut vérifier le certificat.

2. Cryptage Exemple de certificat

Alice

Trent

Bob


Les PKIs� Une PKI est un Infrastructure à Clé Publique (Public Key Infrastructure).� C'est le dispositif nécessaire pour gérer la génération et la distribution contrôlée de certificats.� Une PKI est faite des éléments suivants :

� Des autorités de certification (CA) ;� Des autorités d'enregistrement (RA) ;� Des annuaires de certificats.

La RA (Register Authority)� Chaque nouveau participant doit se présenter.

2. Cryptage Certificats : PKI et CA

� Chaque nouveau participant doit se présenter.� La RA authentifie physiquement le participant .� Le participant peut alors générer par son intermédiaire une paire de clés publique/privée.� La RA peut être intégrée à la CA.

La CA (Certification Authority)� La CA crée et signe les certificats.� Elle crée un certificat avec l'identité du participant, sa clé publique, une date d'expiration et sa

signature.� Elle fournit une copie de sa propre clé publique au participant.� Muni de son certificat et de la clé publique de la CA, le nouveau participant peut communiquer avec

tous les autres participants certifiés par la même CA.


2. Cryptage Architecture d’une PKI

CA

Autorité de

certification

Annuaire LDAP

(Lightweight

Directory Access

Protocol)

(3) Demande de

certificat

(envoi la clé publique

pour la certification)

Génère et signe les certificats et les listes

de révocation

Remarque : l'utilisateur peut générer lui-même sa paire de clés et joindre sa clé publique à sa demande de certificat au CA.


RA

Autorité

d’enregistrement

Internet

(2) Envoi de la

clé privé

(1) Identité du

client

Envoi du

certificat signé

(4)(5)

Publication de

certificat et de

listes de

révocations (CRL)

(6)

Collecte les demandes, vérifie les identités, génère les couples de clés.

2. Cryptage Format d’un certificat X509


2. Cryptage Exemple de certificat X509

Data:Version: 3 (0x2)Serial Number: 2 (0x2)Signature Algorithm: md5WithRSAEncryptionIssuer: OU=Certificate Authority /Email=ValidityNot Before: Mar 26 13:53:26 2006 GMTNot After : Mar 26 13:53:26 2007 GMTSubject: C=FR, ST=Paris, L=Paris, O=IUT, OU=serveur,CN=www.serveur.iut.fr/[email protected] Subject Public Key Info:Public Key Algorithm: rsaEncryptionRSA Public Key: (1024 bit)Modulus (1024 bit):00:ac:45:e8:2a:6d:23:bc:2e:86:ee:d5:a0:e3:3b:55:c0:b2:96:41:8e:d1:c2:17:c3:2c:8b:be:c0:a5:

identité de l’autorité de certification

date de début de validité

date de fin de validité

identité du demandeur

Algo de cryptage de la signature

55:c0:b2:96:41:8e:d1:c2:17:c3:2c:8b:be:c0:a5:d5:a2:ed:11:d9:e1:8c:8e:99:9c:05:59:28:23:8d:8a:aa:a8:0d:de:47:ee:ac:b5:7f:73:4b:e0:15:c2:ed:40:d0:0f:d4:c2:0a:b6:7e:80:a5:4c:a6:a5:15:c5:b4:82:fc:53:18:c7:7c:3a:bd:48:ba:37:f6:99:7c:57:fe:77:92:cf:ef:93:97:5e:2b:34:b1:aa:c3:af:fd:ed:ef:df:e5:fc:c5:1b:b5:64:15:13:2d:42:31:6c:0e:b0:e6:96:81:9c:83Exponent: 65537 (0x10001)X509v3 extensions:X509v3 Subject Alternative Name:email:[email protected] Comment:mod_ssl generated test server certificateNetscape Cert Type:SSL ServerSignature Algorithm: md5WithRSAEncryption86:c3:0c:0b:49:d1:29:93:03:de:51:f8:99:64:a7:25:3d:78:a8:20:41:a7:32:8a:c3:02:6a:6b:66:c8:00:9d:49:18:54:11:6d:5c:c1:c9:69:d8:42:e5:b7:2a:95:f3:ad:11:97:29:65:bc:a2:83:e9:ff:5f:eb:9e:2d:28:82:69:13:67:0d:1d:20:80:82:68:a6:f8:a7:8b:ec:02:0c:8c:a2:c9:56:13:87:ce:fb:58:3c:e2:b6:44:35:37:55:0b:4b:e7:7a:13:cc:d6:f4:59:b5:ab:15:05:a0:e4:2f:41:cd:53:db:85:5f:90:a3:2d:83:d7:1e:b4:1c:35:17

Clé publique

Algo. de cryptage de la clé

Signature du certificat


Algo de cryptage de la signature

2. Cryptage Protocole SSL

� Le protocole SSL (Secure Socket Layer) a été proposé au départ parNetscape et permet des connexions sécurisées sur des serveurs Web.

� Il intervient au dessus de la couche transport.

FTPS HTTPSIMAPHTTP FTPniveau

application

niveautransport

niveauréseau

Secure Socket LayerTCP

IP

� Il permet :� une authentification réciproque entre client et serveur à l’aide de clés symétriques ;� des transaction encryptées entre client et serveur

� SSL intègre deux sous-couches :� SSL record protocol qui définit le format utilisé pour transmettre les données ;� SSL handshake protocol qui définit une série de message pour établir la connexion

entre le client et le serveur.

réseauIP


2. Cryptage Protocole SSL

� Le protocole SSL utilise un cryptage asymétrique par clé publique/clé privéepour échanger la clé maîtresse.

� La clé maîtresse connue des deux extrémités permet un cryptage symétriqueefficace des données pendant toute la durée de la session.

� Au moment de la connexion, le serveur envoie au client sa clé publique (PK)à l’intérieur d’un certificat X509.Le certificat contient donc la clé publique du serveur PK, validée ("signée")Le certificat contient donc la clé publique du serveur PK, validée ("signée")par une autorité de certification (CA).

� Le client vérifie le certificat, généré une clé maîtresse MK et se sert de PKpour crypter MK.

� Le serveur reçoit la clé MK cryptée (PMK) et la décrypte avec sa clé privée.

� Pour sécuriser davantage, un certificat peut aussi être installé sur le client.


2. Cryptage Échange SSL avec certificat


2. Cryptage Capture SSL

� Les 4 premières trames correspondent au dialogue (handshake protocol) pour lamise en place du tunnel SSL.

� La connexion TCP est ouverte sur le port 443 pour un serveur HTTPS.


2. Cryptage Applications utilisant SSL

� SSL peut être utilisé pour sécuriser pratiquement n'importe quel protocole utilisant TCP/IP.

� Certains protocoles ont été spécialement modifiés pour supporter SSL:� HTTPS: c'est HTTP+SSL. Ce protocole est inclus dans tous les navigateurs et permet par

exemple de consulter vos comptes bancaires par le web de façon sécurisée. � FTPS est une extension de FTP utilisant SSL.

� Il est possible de sécuriser des protocoles en créant des tunnels SSL.� Une fois le tunnel SSL créé, Il est donc possible de faire passer n'importe quel

protocole dedans (SMTP, POP3, HTTP, NNTP...).protocole dedans (SMTP, POP3, HTTP, NNTP...).� Toutes les données échangées sont automatiquement chiffrées.� Ceci peut être réalisé avec des outils comme STunnel (http://www.stunnel.org) ou SSH.

� SSL a été développé à l’origine par Netscape (jusqu’à la version 2.0).� La version 3.0 (actuellement la plus répandue) est standardisée par l’IETF (Internet

Engineering Task Force).� TLS (Transport Layer Security) proposé par l’IETF est la version 3.1 de SSL.� TLS est clairement défini dans le RFC 22456 et n’impose pas de méthodes de

chiffrement spécifiques.


2. Cryptage HTTPS

� Les données HTTP sont échangées à l’intérieur d’un tunnel SSL.


2. Cryptage HTTPS� HTTPS utilise le port 443� HTTPS garantit l’intégrité et la confidentialité.� La non-répudiation n'est pas établie dans HTTPS :

� Seuls les échanges lors de l'établissement de la session SSL/TLS sont signés, le reste des données échangées ne l'est pas.

� Autre inconvénient de HTTPS :� les trames sont cryptées et l’analyse de l'intégrité des données (détection de virus, backdoor,

vers…) par les applications de sécurité n’est plus possible.

� Une autorité de certification doit avoir au préalable installé les certificats côté serveur et les clés publiques côté client.


2. Cryptage Certificats SSL/HTTPS

� Côté client, chaque navigateur contient une liste des CA de confiance.� Le client possède donc la clé publique du CA lui permettant de vérifier la

signature du certificat envoyé par le serveur.



� Lorsque la connexion SSL s'établit, le navigateur vérifie que le certificat du serveur aété émis par une CA digne de confiance.

� Le certificat peut être affiché lors de la transaction.



� Pour que le serveur puisse aussi authentifier le client, celui-ci peutégalement installer un certificat.

� Cas des transactions ou la preuve de l’identité du client est indispensable.� Lors d’un changement de machine, le certificat doit être importé.


2. Cryptage Connexion sécurisée SSH

� L'environnement SSH (Secure Shell) s'adresse aux utilisateurs qui souhaitent accéder de manière sécurisée à des systèmes Unix distants.

� Ses composants remplacent des programmes peu sécurisés comme :� ftp (file transfer protocol) ou rcp (remote copy) pour les échanges de fichiers ;� telnet ou rlogin (remote login) pour établir une session de travail ;� rsh (remote shell) ou rexec (remote exec) pour exécuter une commande Unix sur un système

distant.

� La sécurité est garantie par une authentification à l'établissement de chaque connexion et par l'encryptage des données (y compris les mots de passe).et par l'encryptage des données (y compris les mots de passe).

� SSH utilise une connexion TCP sur le port 22.� On peut utiliser une connexion SSH pour transporter un autre protocole, par exemple

SMTP… (le modèle en couche n’est alors pas respecté).� SSH utilise suivant la version les algorithmes de cryptage asymétriques RSA ou DSA.� SCP (Secure CoPy), utilisé généralement en mode commande, permet de télécharger

des fichiers de manière sécurisée en passant par SSH.� Pour les transferts de fichiers, une version SSH de FTP : SFTP peut également être

utilisé. SFTP ne nécessite pas de clients ou de serveur FTP puisque le transfert se fait par le shell.

� Une version OpenSSH est disponible gratuitement sur le site http://www.openssh.org.


2. Cryptage Modèle SSH

� Le groupe de travail à l’IETF qui s’occupe de Secure Shell a normalisé en 2006 le protocole SSH v2 sous forme de trois « couches » :

1. SSH Transport Layer Protocol (SSH-TRANS)2. SSH Authentification Protocol (SSH-AUTH)3. SSH Connection Protocol (SSH-CONN)


2. Cryptage Initialisation SSH

� Dès que la connexion est établie (TCP sur le port 22 du serveur), le client et le serveur échangent en clair le numéro de version SSH.

� Tous les messages échangés sont alors encapsulés dans des paquets SSH :

� Suit la phase d’initialisation de SSH qui correspond à la couche SSH-TRANS et consiste

TCP port 22

Packet length Padding length

Payload

Padding


à mettre en place le tunnel sécurisé :� Le client et le serveur s’envoient la liste des méthodes supportées pour le chiffrement et

l’authentification (message Key EXchange Init) ;� Le client demande un échange de clé de type Diffie-Hellman (DH GEX Request pour Group

EXchange Request) ;� Le serveur choisit 2 nombres d et g et les transmet au client (DH KEX Reply).� Le client génère un nombre aléatoire a, calcule A=ga mod p et transmet A (DH GEX Init).� Le serveur génère b, calcule B=gb mod p, calcule la clé de session K=Abmod p, transmet B et la

clé publique RSA (DH GEX Reply).� Le client vérifie la clé publique et calcule à sont tour K=Bamod p. � Après confirmation du client (New Key), le reste des communications est chiffré grâce à un

algorithme de chiffrement symétrique utilisant la clé de session partagée par le client et le serveur.





2. Cryptage Authentification SSH

Phase d’authentification (couche SSH-AUTH)

� Une fois le tunnel sécurisée établi, le client doit s'identifier sur le serveur . Trois méthodes d’authentification existent :� Par mot de passe (password)

� Authentification classique : l’utilisateur transmet son mot de passe, le serveur calcule le hash et le compare avec celui stocké dans sa base de données (algo. DES sous Linux).

� Cette méthode permet aux utilisateurs Telnet de migrer vers SSH sans aucun changement


� Cette méthode permet aux utilisateurs Telnet de migrer vers SSH sans aucun changement au niveau de leur mécanisme d’authentification sauf que le mot de passe qui transitait en clair avec Telnet est maintenant encapsulé dans une communication chiffrée.

� Par clef RSA ou DSA (publickey)� Basé sur le cryptage asymétrique type RSA ou DSA .� La clef publique de l’utilisateur doit tout d’abord être stockée sur le serveur SSH (problème

d’échange des clés) et sa clef privée doit être stockée sur sa machine de façon sécurisée.

� Par certificat X.509

2. Cryptage Tunneling SSH

� En plus de fournir l’équivalent des sécurisé des commandes rcp, rlogin et rsh, le protocole SSH permettent la mise en œuvre du tunneling.

� Dans ce cas, le tunneling consiste à encapsuler un autre service TCP/IP comme Telnet ou IMAP, dans une session sécurisée SSH.

� Lors de l’ouverture d’une sur un hôte SSH, il est donc possible d’ouvrir également un canal de communication sécurisé pour tous les autres protocoles.


2. Cryptage Redirection de port SSH

� SSH permet de rediriger n’importe quel flux TCP dans le tunnel de la session SSH : le flux de n’importe quelle application circulant entre les ports client et serveur habituels, pourra être encapsulé à l’intérieur du tunnel SSH.

� Cette fonctionnalité permet d’établir, entre deux points, un canal sécurisé par lequel peut transiter n’importe quel type de donnée IP.

� Exemple : mise en place d’un tunnel IP afin de sécuriser les connexions entre un client et un serveur POP situé dans l’intranet d’une entreprise et derrière un serveur SSH.� établissement d’une connexion SSH entre le client et le serveur SSH ;� sur le client : faire pointer le client POP sur le système SSH en local ;� sur le serveur : transmettre les données arrivant depuis la connexion SSH au serveur POP.


� sur le serveur : transmettre les données arrivant depuis la connexion SSH au serveur POP.

2. Cryptage Différences SSL/SSH

� Les deux protocoles sont utilisés dans un même cadre et leurs domaines d'utilisation se recouvrent.

� Ils n'ont pas été particulièrement conçus pour travailler ensemble (même si c'est possible).

� SSL/TLS ne requiert aucune authentification côté serveur : celle-ci est optionnelle, et une connexion peut être anonyme. Les connexions SSH doivent être authentifiées.

� SSL/TLS ne propose une authentification côté client que par échange de clefs publiques, tandis que SSH propose de nombreuses autres options.clefs publiques, tandis que SSH propose de nombreuses autres options.

� SSH peut-être utilisé dans un cadre autre que le Web pur : FTP, POP3 / IMAP / SMTP, telnet... SSL se limite aux protocoles HTTPS (HTTP sécurisé par SSL) et FTPS.

� SSL/TLS n'est utile qu'en cas d'échange entre deux applications. SSH 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.

� En résumé, SSL/TLS permet de sécuriser le transport d'informations via le Web, et SSH est une véritable plate-forme de sécurisation pour toutes formes de communications.


2. Cryptage Autre technique de cryptage en réseau…


� L’authentification consiste à apporter la preuve de l’identité d’un utilisateur sur un réseau informatique.

� Le nom sert à l'identification, le mot de passe à l'authentification.� Pour éviter de s'authentifier pour chaque opération, on utilise des systèmes

d'authentification centralisés (système d'exploitation, contrôleur de domaine, serveur d'authentification RADIUS…).

� Une fois qu'il a authentifié l'utilisateur, le système lui assigne des privilèges qui lui donnent accès à certaines ressources.

� Les risques sont les plus élevés au moment de l’authentification.

3. Authentification Principe

ESPIONNAGEESPIONNAGE


� Sous Linux comme pour les autres OS, les mots de passe ne sont jamais stockés en clair.� Au lieu des mots de passe on stocke un hash.� Le hash doit être unique et irréversible.� En comparant le hash du mot de passe fourni avec le hash stocké on sait si les deux hashs

ont été crées à partir du même mot de passe.� Sous Linux, le hash est crée en chiffrant (25 fois) une chaîne de caractères vide avec le mot

de passe comme clé :� L'algorithme de chiffrement (DES) utilise une clé de 56 bits.� 7 bits sont extraits par caractère du mot de passe (les caractères au-delà du huitième sont ignorés).� Un grain de sel (12 bits) est ajouté pour que le même mot de passe ne génère pas toujours le même

3. Authentification Locale sous Linux

Un grain de sel (12 bits) est ajouté pour que le même mot de passe ne génère pas toujours le même hash (le sel est stocké avec le hash).


� Lors d'un login local le hash est généré à l'aide du mot de passe fourni et du grain de sel stocké localement. Le hash est comparé avec celui stocké localement.

� Lors d'un login réseau, le hash et le sel sont obtenus depuis un serveur central à l'aide d'un communication chiffrée.

� Initialement, le nom et le hash des mots de passe étaient stockés dans le fichier /etc/passwd avec accès libre en lecture !

3. Authentification Locale sous Linux

� Pour sécuriser, les hashs se trouvent désormais dans un fichier séparé, /etc/shadow qui ne peut être lu que par l'administrateur.


� Le protocole Kerberos est le protocole de sécurité principal par défaut pour les authentifications dans un domaine Windows 2000/2003.

� Il permet aux utilisateurs d’accéder aux ressources réseau à partir de la même ouverture de session.

� Dans un domaine Windows, le service Kerberos s’appelle le KDC (Key Distribution Center) et se trouve dans chaque contrôleur de domaine (DC).

� Les clients Kerberos sont installés sur les ordinateurs clients.

� Lorsqu’un utilisateur veut accéder à un contrôleur de domaine, le KDC de ce

3. Authentification Locale sous Windows

� Lorsqu’un utilisateur veut accéder à un contrôleur de domaine, le KDC de ce contrôleur va vérifier l’identité du client.

� Le client pourra confirmer son identité en demandant au service Kerberos du réseau un ticket TGT (Ticket Granting Ticket).

� Le TGT permet au système client d’accéder au TGS (Ticket Granting Service) se trouvant dans le contrôleur de domaine.

� Ce TGS permettra l’émission d’un ticket de service au client (Ticket Service).� C’est ce ticket de service que le client présentera au service réseau demandé

pour accéder à des ressources.


3. Authentification Kerberos

(1) Je suis Bob et

Key Distribution

Center (KDC)

Ticket Granting

Service Service

(TGS)

Authentication

Service (AS)

( )

j’ai besoin d’un TGT

(2) Voilà ton TGT, si tu

peux le décrypter avec ton

hash de password

(3) Voilà mon TGT, donne

moi un Ticket de Service

(4) Voilà ton TS

(5) Voilà mon TS, tu

peux m’authentifier

(6) OK, ta session est

ouverte, tu as accès aux

ressources réseau !

Services réseau


� Une connexion par modem vers un FAI utilise un protocole en mode point à point :� Le PC commence par établir une connexion à un central composé d’une

batterie de modems connectés vers Internet.� Ce central, mis en œuvre par le FAI, est souvent nommé POP (Point of

Presence).� La connexion entre le modem et l’un des modems du PoP repose sur un le

protocole PPP (Point-to-Point Protocol - RFC 1661).

� PPP définit notamment la méthode d’identification par mot de

3.Authentification Distante : par une liaison PPP

� PPP définit notamment la méthode d’identification par mot de passe choisie parmi 4 méthodes.


� PAP (Password Authentication Protocol) est le plus simple des mécanismes d’authentification : � le client envoie son mot de passe en clair ;� Le mot de passe est comparé avec celui stocké chez le FAI.� Dans la pratique, le PAP n’est utilisé que lorsqu’un autre mécanisme permet d’assurer la

sécurité de l’échange.

� CHAP (Challenge Handshake Authentication Protocol) est défini dans la RFC 1994 :� Le serveur commence par envoyer un « défi » au client (16 octets aléatoires), ainsi qu’un

3. Authentification Par une liaison PPP : PAP et CHAP

� Le serveur commence par envoyer un « défi » au client (16 octets aléatoires), ainsi qu’un compteur qu’il incrémente à chaque défi ;

� Le client doit alors passer le compteur, son mot de passe et le défi au travers d’un algorithme de hachage (MD5) ;

� Le résultat est une séquence de bits pseudo-aléatoires qu’on appelle le «hash» (16 octets dans le cas de MD5) ;

� Ce hash est envoyé au serveur, qui peut alors effectuer le même calcul et vérifier si son résultat concorde avec celui du client.

� Cet algorithme permet d’éviter que le mot de passe ne soit transféré et évite également qu’un pirate ne répète simplement une authentification réussie qu’il aurait enregistrée auparavant, puisque le défi change à chaque authentification.

� Il ne permet cependant pas au client de s’assurer de l’identité du serveur.


3. Authentification Par une liaison PPP : CHAP


� MS-CHAP, souvent appelé MS-CHAP-v1, a été défini par Microsoft dans la RFC 2433 :� Variante de CHAP, destinée à en améliorer la sécurité.� L’un des problèmes de CHAP est le fait qu’il soit nécessaire de stocker le mot

de passe en clair sur le serveur pour calculer le hash et vérifier l’identité du client.

� Toute personne ayant accès à la base de données des utilisateurs peut donc voir les mots de passe de tout le monde !

3. Authentification Par une liaison PPP : MS-CHAP

voir les mots de passe de tout le monde ! � Pour éviter cela, MSCHAP spécifie que le serveur doit stocker non pas le mot

de passe, mais le résultat d’un hash sur ce mot de passe (selon un algorithme propriétaire de Microsoft).

� Lorsque l’utilisateur saisit son mot de passe, celui-ci doit d’abord être passé au travers du même algorithme de hash avant de suivre la procédure habituelle de CHAP.

� Malheureusement, MS-CHAP comporte des failles de sécurité (dues en particulier au hash propriétaire de Microsoft) qui l’ont rendu rapidement obsolète : seuls quelques vieux systèmes Windows 95/98 l’utilisent encore.


� MS-CHAP-v2 : Microsoft a conçu la version 2 plus robuste, définie dans la RFC 2759 :� Fournit notamment un mécanisme d’authentification mutuelle : le serveur s’assure de

l’identité du client et vice versa.� Largement utilisé dans les réseaux Windows, depuis la version Windows 2000.

� Les méthodes CHAP, MS-CHAP et MS-CHAP-v2 sont toutes vulnérables face à

3. Authentification Par une liaison PPP : MS-CHAP-V2

� Les méthodes CHAP, MS-CHAP et MS-CHAP-v2 sont toutes vulnérables face à des attaques hors-ligne de type dictionnaire :� Le pirate peut enregistrer les échanges lors de l’authentification d’un utilisateur légitime,

puis, il peut essayer hors-ligne de reproduire le même dialogue en essayant des milliers de mots de passe.

� Il suffit qu’un seul utilisateur légitime ait un mot de passe faible pour que le pirate puisse entrer sur le réseau.

� Besoin pour certains FAI d’identifier les utilisateurs autrement que sur la base d’un simple mot de passe : identification avec carte à puce, certificats électroniques…

� C’est de ce besoin qu’est né EAP.


3. Authentification Par une liaison PPP avec Windows


� Standard 802.1x :� solution de sécurisation, mise au point par l'IEEE en juin 2001;� permet d'authentifier un utilisateur souhaitant accéder à un réseau (filaire ou sans fil) grâce

à un serveur d'authentification ;� repose sur le protocole EAP (Extensible Authentication Protocol) défini par l’IETF.

� Le rôle d’EAP est de transporter les informations d’authentification des utilisateurs.� EAP est un protocole de transport et non un protocole d'authentification.� Le mécanisme EAP est analogue à celui d’une simple authentification à un FAI au

travers d’une liaison PPP.

3. Authentification 802.1x et EAP


� EAP est basé sur l'utilisation d'un contrôleur d'accès (Authenticator ou NAS: Network AccessServer) chargé d'établir ou non l'accès au réseau pour un client (Supplicant).

� Le contrôleur d'accès est un simple garde-barrière servant d'intermédiaire entre l'utilisateur etun serveur d'authentification (AS : Authentication Server) ;

� Dans le cas d'un réseau sans fil, l’AP joue le rôle de contrôleur d'accès (très peu deressources nécessaires).

� L’AS permet de valider l'identité de l'utilisateur, et de lui renvoyer les droits associés enfonction des information d'identification fournies.

� L’AS est généralement un serveur RADIUS (Remote Authentication Dial In User Service) :serveur d'authentification standard défini par les RFC 2865 et 2866.

3. Authentification Fonctionnement d’EAP


� EAP peut être utilisé dans de multiples contextes, le WiFi n’en est qu’un parmi d’autres.

� Le fait que le contrôleur d’accès ne soit qu’un intermédiaire entre le client et le serveur est l’un des grands intérêts de l’EAP : � Il n’a pas besoin de comprendre l’échange entre le client et l’AS, à l’exception

du résultat final (le succès ou échec de l’authentification) qui le décidera à ouvrir la porte du réseau ou à la laisser fermée.

� Pour une nouvelle méthode d’authentification, il ne sera pas nécessaire de changer les contrôleurs d’accès.

3. Authentification Intérêt d’EAP

changer les contrôleurs d’accès.� Seuls les clients et le serveur d’authentification devront être mis à jour.� Les contrôleurs d’accès sont souvent de simples équipements sans grande

puissance de calcul ou difficiles à mettre à jour (AP WiFi).

� Attention à la terminologie :� Les protocoles EAP, 802.1x et RADIUS ont des mots différents pour désigner

les mêmes choses.� Le client s’appelle respectivement peer, supplicant et user dans ces trois

protocoles.� Le contrôleur d’accès s’appelle authenticator dans l’EAP et le 802.1x, mais

Network Access Server (NAS) ou client dans le RADIUS.


EAP définit quatre types de paquets pouvant être échangés entre le client et le serveur d’authentification (par l’intermédiaire du contrôleur d’accès) :� Paquet Requête

� Envoyé par le serveur d’authentification, demande au client de fournir une information précise : identité ou preuve de cette identité, selon une méthode d’authentification choisie par le serveur (mot de passe, certificat électronique…).

� Paquet Réponse� Envoyé par le client en réponse à une requête. Le contenu dépend de la méthode

d’authentification requise par le serveur.

3. Authentification Paquets EAP

d’authentification requise par le serveur.� Si le client ne gère pas la méthode d’authentification requise, il le signale et lui suggère

une liste de méthodes qu’il est capable de gérer.� Le serveur d’authentification peut alors choisir l’une de ces méthodes et renvoyer une

nouvelle requête au client.

� Paquet Succès� Envoyé par le serveur d’authentification pour indiquer au client qu’il a été correctement

identifié. Le contrôleur d’accès ouvre la porte du réseau.

� Paquet Échec � Envoyé par le serveur d’authentification si le client n’a pas pu être identifié.


� Le champ « Code » indique s’il s’agit d’une requête, d’une réponse, d’un succès ou d’un échec.

� Le champ « ID » est un identifiant qui permet de savoir à quelle requête correspond une réponse.

� Le champ « Longueur » représente la longueur du paquet EAP.� Dans les paquets de requêtes et de réponses, un champ « Type » (un

octet) situé juste avant le champ de données indique quel type de méthode d’authentification est utilisée.

3. Authentification Format des paquets EAP

méthode d’authentification est utilisée.

� Paquet EAP :


3. Authentification Échanges 802.1x/EAP (1)

Supplicant NAS : Network

Access Server

Trafic

EAP sur Radius

Trafic

EAP sur WLAN

Radius Server


� Le protocole 802.1x définit comment EAP peut être utilisé sur un LAN ou un WLAN grâce au protocole EAPoL (EAP over LAN).

� EAPoL est utilisée entre le client et le NAS. Les paquets EAPoL ou EAP sont encapsulés dans des trames Ethernet ou WiFi.

� Entre le NAS et le serveur RADIUS, les paquets EAP sont encapsulésdans des requêtes RADIUS.

� L’authentification se déroule en 4 étapes :

3. Authentification Échanges 802.1x/EAP (2)

� L’authentification se déroule en 4 étapes :1. Le NAS, ayant préalablement reçu une demande de connexion de la part

du client (EAPoL-Start) envoie une requête d'identification ;2. Le client envoie une réponse au NAS, qui la fait suivre à l’AS ;3. L’AS envoie un « challenge » au contrôleur d'accès, qui le transmet au

client. Le challenge est une proposition de méthode d’authentification (parexemple OTP). Si le client ne gère pas la méthode, le serveur en proposeune autre et ainsi de suite ;

4. Le client répond au challenge. Si l’authentification réussie, l’AS envoie unaccord au NAS, qui ouvrira un port 802.1x sur le réseau ou une partie duréseau, selon ses droits.


� 802.1x définit les types de messages EAPoL :� EAPoL-Start : permet au client de prévenir le contrôleur d’accès qu’il souhaite

se connecter ;� EAPoL-Packet : type de paquet qui encapsule les paquets EAP ;� EAPoL-Key : permet l’échange de clés de cryptage ;� EAPoL-Logoff : permet au client de demander la fermeture de sa session ;� EAPoL-Encapsulated-ASF-Alert : permet aux clients dont l’authentification a

échoué de pouvoir tout de même être supervisés à distance (par exemple, par SNMP).

3. Authentification Paquets EAPoL

SNMP).

� Paquet EAPol :

� Le champ « Version » la version du protocole EAPoL utilisé.� Le champ « Type » indique s’il s’agit d’un paquet EAPoL-Start, EAPoL-Key, etc.� Le champ « Longueur » indique la longueur du message qui suit.


� Pour mettre en place une architecture 802.1x avec le WiFi, il faut :� Un serveur d’authentification, généralement RADIUS ;� Des AP qui gèrent le 802.1x ;� Un logiciel de connexion compatible 802.1x sur les postes client :

� fournit avec l’adapateur WiFi� Intégré à l’OS (windows XP ou Vista et MAC OS).

� Une ou plusieurs méthodes d’authentification EAP.� Un cryptage pendant la phase d’identification entre le client et le NAS, WPA par

exemple.

3. Authentification Architecture 802.1x / EAP

exemple.


� Le logiciel de connexion du client (appelé le « client EAP ») peut être fourni avec l’adaptateur WiFi.

� Il peut également être acheter ou fournit en Open Source (Xsupplicant pour Linux).

� Le client EAP peut aussi être intégré à l’OS : Windows et Mac Os possèdent un client EAP capable de gérer de multiples méthodes d’authentification.

3.Authentification 802.1x / EAP : logiciel client


� Lorsque l’on met en place une architecture 802.1x, le serveur d’authentification est généralement un serveur de type RADIUS.

� Les critères de choix du serveur sont nombreux : coût, méthodes EAP gérées, stabilité, OS sur lesquels il peut être installé, ouverture, support fourni, performance, outils de configuration disponibles, intégration avec bases de données, etc.

3. Authentification 802.1xEAP : serveur d’authentification


� Sur un réseau WiFi relié en Ethernet au serveur RADIUS, les paquets EAP sontencapsulés :� dans des trames 802.11 par l’intermédiaire de 802.1x côte WLAN ;� dans des trames 802.3 par l’intermédiaire d’UDP/IP et RADIUS.

3. Authentification Architecture protocolaire 802.1x/EAP


� EAP ne décrit que quelques méthodes d’authentification entre le clientet le serveur, les autres méthodes sont décrites par des RFC :� EAP/MD5 basées sur le protocole CHAP (Challenge Handshake protocol).� EAP MS-CHAP-v2 basée sur la version MS-CHAP de Microsoft.� EAP/OTP (One Time Password) basé sur l’utilisation unique d’un mot de

passe non nécessairement crypté.� EAP/GTC (Generic Token Card), méthode simple avec envoie d’un « défit »

au client qui répond en clair au serveur.� EAP/TLS basée sur la version TLS (Transport Layer Security) de SSL

3. Authentification Méthodes EAP

� EAP/TLS basée sur la version TLS (Transport Layer Security) de SSL(Secure Socket Layer) qui sécurise au niveau transport.

� EAP/PEAP (Protected EAP) utilisant également un tunnel TLS.� EAP/TTLS (Tuneled TLS) avec également une authentification dans un

tunnel TLS.� EAP/SIM, permet à un utilisateur de s’identifier grâce la carte SIM de son

téléphone portable GSM.

� Lors de la phase d’authentification, suivant la méthode d’authentificationutilisée, des échanges de paquets EAP spécifiques sont nécessaires(échange de clés de cryptage, de certificats…).


� Le système One Time Password (OTP) est défini dans la RFC 2289. L’utilisation des OTP avec EAP est définie dans la RFC 3748.

� Un OTP est un mot de passe conçu pour n’être utilisé qu’une seule fois. Ceci permet de l’échanger non crypté, sans craindre qu’il soit réutilisé.

� Le serveur commence par envoyer un défi au client : quelques octets aléatoires et un index qui change à chaque nouveau défi.

� Le client doit alors utiliser un « générateur » logiciel afin de produire un OTP :� Pour faire fonctionner le générateur, l’utilisateur doit lui fournir le défi (l’index et la

3. Authentification EAP / OTP

séquence aléatoire) ainsi que son « vrai » mot de passe, appelé la « phrase secrète » ou passphrase.

� Le générateur fonctionne en faisant passer plusieurs fois (en fonction de l’index) le défi et la phrase secrète au travers d’une fonction de hash.

� Le client doit renvoyer l’OTP de 8 octets au serveur qui vérifie qu’il parvient bien au même résultat.

� Comme le CHAP, le MS-CHAP et le MS-CHAP-v2, la méthode OTP est vulnérable aux attaques de dictionnaire hors-ligne.


� La RFC 3748 prévoit un type d’identification appelé GTC Generic Token Card(carte à jeton générique) :� Le serveur envoie (optionnellement) un défi au client et celui-ci doit y répondre en tapant

sa réponse, qui est renvoyée en clair.� Le serveur vérifie la validité de la réponse….

� Cette méthode très simple a été conçue pour les cartes à jeton :� Le jeton est une clé assez longue qui n’est connue que par le serveur d’authentification et

est nécessaire à l’identification du client.� Le plus souvent, un mot de passe est également exigé. On parle alors de sécurité à

« double facteur » : pour s’identifier, l’utilisateur doit à la fois connaître quelque chose (son

3. Authentification EAP / GTC

« double facteur » : pour s’identifier, l’utilisateur doit à la fois connaître quelque chose (son code PIN ou son mot de passe) et posséder quelque chose (la carte à jeton).

� La plupart des algorithmes utilisent le jeton, le mot de passe de l’utilisateur et le défi envoyé par le serveur pour générer un hash qui est renvoyé au serveur.

� Certaines cartes sont synchronisées avec le serveur et affichent un code qui change toutes les 10 à 20 secondes environ. Pour s’identifier, l’utilisateur doit taper ce code, ainsi que son mot de passe (ou code PIN).

� Les cartes basiques s’insèrent dans un lecteur de carte, connecté par exemple au port USB de l’ordinateur

� D’autres sont autonomes et possèdent un mini clavier voire même un petit écran à cristaux liquides.


� Cette méthode d’authentification est définie dans la RFC 4186.� Son but est de permettre à un utilisateur de s’identifier grâce la carte SIM

de son téléphone portable GSM :� Celle-ci peut être connectée à l’ordinateur via une clé USB, par exemple, ou

directement intégrée dans l’adaptateur WiFi.� Pour que l’identification puisse fonctionner, le serveur d’authentification doit

être relié à l’opérateur mobile de l’utilisateur : il ne sert alors que d’intermédiaire entre le client et le serveur d’authentification de l’opérateur mobile.

3. Authentification EAP / SIM

mobile.

� Cette solution a peu d’intérêt pour la plupart des entreprises dans le contexte d’un réseau WiFi.

� Elle est intéressante dans le cadre de la convergence entre la téléphonie et les technologies de l’information (opérateurs mobiles qui déploient des hotspots par ex.).

� D’autres méthodes d’identification liées à la téléphonie existent : EAP/SIM6 pour l’identification SIM passant par un réseau IPv6 et EAP/AKA pour l’identification par un réseau UMTS.


3. Authentification EAP/TLS

� EAP ne prend en charge que l’authentification, EAP/TLS n’utilise donc que la partie authentification par certificat de TLS (la clé symétrique n’est pas utilisée).

� Clients et serveurs possédent un certificat ce qui suppose l’utilisation d’une PKI.� Lors du dialogue EAP, les clients et le serveur s’échangent et vérifient leurs certificats

en suivant le protocole TLS.� Seuls les utilisateurs possédant un certificat valide sont autorisés à se connecter.� Gestion des certificats peut être lourde. C'est pour se passer du certificat client que les

protocoles PEAP et EAP-TTLS ont été créés.


3. Authentification EAP/TLS : échanges EAP

Certificatclient

CertificatServeur


3. Authentification EAP/TLS : échanges TLS

Certificatclient

CertificatServeur

1

2


3

4

5

Ech

ange

TLS


1. Le serveur Radius initie le processus d'authentification TLS par le message TLS start.

2. Le client répond avec un message client_hello, qui contient :� des spécifications de chiffrement vides en attendant qu'elles soient négociées entre le client et le serveur ;� la version TLS du client ;� un nombre aléatoire (défi ou challenge) ;� un identifiant de session ;


� un identifiant de session ;� les types d'algorithmes de chiffrement supportés par le client.

3. Le serveur renvoie une requête contenant un message server_hello suivi :� de son certificat (x509) et de sa clé publique ;� de la demande du certificat du client ;� d'un nombre aléatoire (défi ou challenge) ;� d'un identifiant de session (en fonction de celui proposé par le client).

Le serveur choisit un algorithme de chiffrement parmi ceux qui lui ont été proposés par le client.


4. Le client vérifie le certificat du serveur et répond avec son propre certificat et sa clé publique.

5. Le serveur vérifie le certificat du client.

Le serveur et le client, chacun de son côté, définissent une clé de chiffrement principale (MK) utilisée pour la session. Cette clé est dérivée des


chiffrement principale (MK) utilisée pour la session. Cette clé est dérivée des valeurs aléatoires que se sont échangées le client et le serveur.

Les messages change_cipher_spec indiquent la prise en compte du changement de clé.

Le message TLS_finished termine la phase d'authentification TLS (TLS handshake), dans le cas d'EAP-TLS la clé de session ne sert pas à chiffrer les échanges suivants.

� EPA/PEAP (Protected EAP) a été développé par Cisco et Microsoft.� Un tunnel TLS est d’abord mis en place entre le client et le serveur puis une

nouvelle négociation EAP (par ex. EAP/MS-CHAP-v2 ou EAP/GTC) est effectuée à l’intérieur du tunnel (EAP protégé)

� Le dialogue est proche de celui d’EAP/TLS mais avec quelques différences importantes : � Au cours de la négociation EAP/PEAP, lorsque le serveur demande son identité au client,

celui-ci n'est pas obligé de révéler sa véritable identité ( « anonyme », par exemple). � Le client n'est pas obligé de fournir un certificat. Seul le serveur doit en fournir un pour

3. Authentification EAP/PEAP

prouver son identité au client. � Plutôt que de s'arrêter à la fin de la négociation TLS, EAP/PEAP va jusqu'à établir

complètement le tunnel TLS. � Dans ce tunnel, une négociation EAP complète a lieu: c'est ici que le client fournit son

identité et la preuve de cette identité. La méthode utilisée peut être n'importe quelle méthode EAP.

� Une fois que l'identification EAP « interne» est terminée par un paquet de succès ou d'échec, le tunnel TLS est fermé et le serveur renvoie un nouveau paquet de succès ou d'échec au client en clair (le contrôleur d'accès doit savoir qu’il faut laisser passer le client).

� L’intérêt principal de PEAP est d’utiliser une méthode d’authentification à l’intérieur d’un tunnel TLS.


3. Authentification Dialogue EAP/PEAP


� Comme PEAP, TTLS (Tunneled TLS) commence par établir un tunnel TLS puis met en œuvre une autre authentification dans ce tunnel.

� Le mécanisme est donc le même, les différences sont :� TTLS a été conçu par Funk Software pour sa solution de sécurité WiFi :

Odyssey� TTLS n’est pas intégré à Windows� TTLS autorise tout type d’identification interne, pas uniquement à base d’EAP

(PAP, CHAP, MS-CHAP…)

3. Authentification EAP/TTLS

(PAP, CHAP, MS-CHAP…)� Possibilité de rajouter des AVP (Attribute-Value Pair) dans les paquets TTLS :� Les AVP sont composée du type de l’attribut et de sa valeur (par ex. [Prénom,

« Alice »]) et permet de transporter des informations supplémentaires (authentification, règles de filtrage…).

� RADIUS utilise également les AVP.

� PEAP et TTLS sont donc 2 méthodes concurrentes avec une meilleure intégration pour la première et une plus grande souplesse pour la deuxième.


� EAP présente 3 failles identifiées :� Attaque de la méthode d’authentification elle-même ;

� Attaque de dictionnaire hors-ligne possible avec EAP/MD5 (lecture du défi et du hash et recherche du mot de passe produisant le même hash);

� Attaque de la session une fois que celle-ci est établie :� Une fois l’utilisateur authentifié avec une méthode sure (EAP/TLS), l’AP accepte tous

les paquets en provenance de l’adresse MAC de celui-ci ;� Le travail d’EAP étant terminé, le tunnel TLS est fermé et les paquets sont transmis

3. Authentification Faiblesses d’EAP

� Le travail d’EAP étant terminé, le tunnel TLS est fermé et les paquets sont transmis en clair ;

� Une simple falsification d’adresse MAC permet d’accéder à la session…

� Attaque de type « Man in the Middle » entre le client et le contrôleur d’accès, le pirate s’identifie à la place du client.

� Peu probable dans une connexion PPP mais simple en WiFi (insertion d’un AP pirate).

� La parade consiste à mettre en place un cryptage pour la session d’authentification : sans les clés de cryptage, le pirate ne pourra ni envoyer ni recevoir


3. Authentification Optimiser EAP/802.1x

Attaque MiM

� Pour éviter les failles EAP et bénéficier de la meilleure sécurité avec 802.1x :� Utiliser une méthode à base de tunnel : EPA/TLS, EAP/TTLS ou PEAP ;� S’assurer que le certificat du serveur est toujours vérifié par les clients ;� Eventuellement mettre en place un certificat pour chaque client ;� Utiliser une méthode d’authentification interne robuste (carte à jeton) ;� S’assurer qu’un cryptage puissant est utilisé pendant l’authentification (WPA2 en WiFi).


� Le client possède un logiciel de connexion compatible avec le 802.1x (donc avec l’EAP) et supporte deux méthodes d’authentification : PEAP/MS-CHAP-v2 et EAP/TLS.

� L’AP est compatible 802.1x : � Il n’a pas besoin de connaître PEAP/MS-CHAP-v2, EAP/TLS, TTLS/PAP ou toute autre

méthode d’authentification particulière. � Il est capable de relayer des requêtes EAP vers le client (via la connexion WiFi) et vers le

serveur d’authentification (via le réseau de l’entreprise).

� Le serveur RADIUS gère les méthodes d’authentification EAP/TLS et TTLS/PAP :� Le serveur demandera au client de s’identifier selon une méthode. Si le client ne la gère pas, le

serveur en suggérera une autre et ainsi de suite jusqu’à ce que le client en accepte une.Dans l’exemple, ils tomberont d’accord sur la méthode d’identification EAP/TLS.

3. Authentification EAP : Exemple en WiFi

� Dans l’exemple, ils tomberont d’accord sur la méthode d’identification EAP/TLS.


� RADIUS pour Remote Authentication Dial In User Service est un protocole d'authentification pour les connexions à distance.

� Il permet la centralisation des données d’authentification.� Il permet également la gestion des connexions utilisateurs à des services distants.

� Scénario de base RADIUS :� L’utilisateur se connecte à son NAS (Network Acces Server) et fournit son identité ;� Le NAS communique avec le serveur suivant le protocole RADIUS pour valider l’identité de

l’utilisateur ;� Si l’identité est vérifiée, le NAS autorise l’utilisateur à accéder au réseau.

3. Authentification RADIUS : principe

� Si l’identité est vérifiée, le NAS autorise l’utilisateur à accéder au réseau.


� Les méthodes d’authentification pises en charge par les serveur RADIUS sont variées : PAP, CHAP, MS-CHAP, MS-CHAP-v2, EAP/MD5, PEAP/MS-CHAP-v2…

� Pour valider les identités, les serveurs RADIUS peuvent :� Consulter un simple fichier local ;� Consulter une base de données type mySQL ou Oracle ;� Consulter un serveur LDAP, un serveur Kerberos ou un contrôleur de Domaine Windows.

� Le serveur RADIUS peut faire appel à un serveur d’authentification existant grâce à un connecteur.

3. Authentification Connecteurs RADIUS


� Après la phase d’authentification, le protocole RADIUS peut fournir au NAS des information supplémentaires sous forme d’AVP (Attribute-Value Pair) .

� Les AVP sont composée du type de l’attribut et de sa valeur (par ex. [Prénom, « Alice »]) .

� Exemples d’AVP :� Session-Timeout : entier de 32 bits qui définit en seconde la durée de la session,.

Au-delà, le NAT déconnecte l’utilisateur ;� Idle-Timeout : indique au NS au bout de combien de seconde l’utilisateur doit être

3. Authentification Attributs RADIUS

� Idle-Timeout : indique au NS au bout de combien de seconde l’utilisateur doit être déconnecté

� Le serveur RADIUS est capable de comptabiliser différentes informations sur les connexions :� Nombre de connexions des utilisateurs ;� durée des connexions des utilisateurs ;� Volume des données échangées ;� Cause de la fin de session (déconnexion volontaire, timeout, perte de signal).


� RADIUS utilise UDP pour le transport :� RADIUS est un protocole sans état ;� Permet la réémission d’une demande d’authentification à un serveur secondaire si le

serveur primaire ne répond pas ;� RADIUS n’exige pas une détection "sensible" de la perte de données.

� 6 types de paquets pour effectuer une authentification RADIUS :� Access-Request

Envoyé par le NAS, contient les informations sur le client qui souhaite se connecter (login/mot de passe, adresse MAC…)

3. Authentification Paquets RADIUS

� Access-ChallengeEnvoyé par le serveur pour demander la réémission d’un access-request ou des informations complémentaires.

� Access-AcceptEnvoyé par le serveur pour autorisé la connexion si la vérification des informations est correcte (peut contenir un AVT du type Session-Timeout).

� Access-RejectEnvoyé par le serveur pour refuser une connexion en cas d’échec de l’authentification ou pour mettre fin à une connexion.

� Accounting-RequestEnvoyé par le NAS pour indiquer le début (Start) ou la fin (Stop) d’une session.

� Accounting-ResponseEnvoyé par le serveur pour acquitter le précédent.


3. Authentification Dialogue RADIUS


3. Authentification RADIUS : format des paquets

Code (1 octet):1 : access-request

Length (2 octets):Taille total du message (de 20 à


1 : access-request2 : access-accept3 : access-reject4 : accounting-request5 : accounting-response11 : access-challenge

Identifier (1 octet) :- Unique pour chaque authentification- Identique pour une retransmission

Taille total du message (de 20 à 4096 octets)

Request Authenticator (16 octets):

Un nombre aléatoire unique

Response Authenticator (16 octets):

MD5 (Code + ID + Length + RequestAuth + Attributes + Secret)

3. Authentification RADIUS : format des attributs

Type (1 octet):1 : User-Name 2 : User-Password3 : CHAP-Password4 : NAS-IP-Address5 : NAS-Port

Length (1 octet):Taille total du message (max 254 octets)

Value (1-253 octets):text 1-253 octets string 1-253 octets address 32 bit integer 32 bittime 32 bit


User-Password :

Le mot de passe est coupé en blocs de 16 octets : p1, p2,…

c1 = p1 XOR MD5(Secret + Request Authenticator)c2 = p2 XOR MD5(Secret + c1)…

Le mot de passe encodé est la concaténation de : c(1)+c(2)+...

5 : NAS-Port 6 : Service-Type …

time 32 bit

3. Authentification Sécurité RADIUS� Le protocole RADIUS utilise 2 éléments de sécurité :

� Le secret RADIUS qui correspond à un long mot de passe connu du serveur et du contrôleur d’accès (clé symétrique).

� Le secret est utilisé pour crypter certains attributs et pour calculer le code de contrôle d’intégrité utilisé par le récepteur pour s’assurer que le paquet RADIUS n’a pas été modifié.

� La signature (authenticator) RADIUS est un champ de 16 octets présent dans chaque paquet RADIUS.

� Pour un paquet Access-Request, l’authenticator est un nombre aléatoire ;� Pour un paquet de réponse (Access-Accept, Access-Challenge, Acces-Reject) , l’authenticator

est calculé en utilisant l’algorithme de hachage MD5 appliqué au paquet de réponse, au nombre aléatoire et au secret.


� L’authenticator et le secret servent aussi à crypter les mots de passe pour les authentifications simples PAP et CHAP.

� Problèmes :� Empêcher un intrus de se connecter au réseau sans fil (parking attack) ;� Empêcher l’écoute clandestine des données échangées ;

� 1ère solution : WEP (Wired Equivalent Privacy)� La clé secrète partagée (40 ou 104 bits) est concaténée (ajoutée) avec un

vecteur d’initialisation (IV) sur 24 bits réinitialisé à chaque trame ;� Le résultat (64 ou 128 bits) est placé dans un PRNG (Pseudo Random

4. LAN sécurisés WiFi et la sécurité

� Le résultat (64 ou 128 bits) est placé dans un PRNG (Pseudo RandomNumber Generator) qui généré une séquence aléatoire ;

� Parallèlement, un calcul d’intégrité (CRC) ainsi qu’une concaténation (ll) estréalisé sur les données ;

� Une opération « ou exclusif » entre la séquence aléatoire et les donnéespermet ensuite de chiffrer celles-ci ;

� Les données chiffrées sont transmises ainsi que le vecteur d’initialisation(en clair) ;

� Pour le déchiffrement, l’opération inverse est réalisée (la clé wep et levecteur d’initialisation sont connus à la réception).


E-TI VdonnéesCRC

I V

Clé partagée||

PRNG(RC4)

⊕données

CRC 32||

ICV

4. LAN sécurisés WiFi : chiffrement WEP

ICV

E-TI VdonnéesCRC

Clé partagée

||PRNG(RC4)

⊕

Contrôled’intégrité

données

Chiffrement

Déchiffrement


� Contre la confidentialité :� Principale faiblesse du chiffrement WEP : utilisation de la même clé partagée pour

un grand nombre d’échanges (keystream reuse).� Possibilité de déchiffrer la clé dès que l’on connaît un couple « texte en clair, texte

chiffré » de même IV.� Même si l’IV change à chaque transmission, une écoute du réseau pendant un

temps suffisant permettra de trouver cette clé.� Faiblesse exploitée par certains programmes (aircrack…) capables, suivant la taille

de la clé et la charge du réseau, de trouver la clé en quelques minutes ou quelques

4. LAN sécurisés WiFi : vulnérabilités du WEP

de la clé et la charge du réseau, de trouver la clé en quelques minutes ou quelquesjours…

� Faiblesse de RC4 (key scheduling algorithm weakness)� Attaque exhaustive (clé dérivée d'une passphrase)� Attaque statistique

� Contre l'intégrité :� Modification de paquets (bit flipping)� Injection de faux paquets

� Contre l'authentification auprès de l'AP� Fausse authentification (authentication spoofing)


Attaque statistique

� Attaque découverte par un hacker nommé KoreK� http://www.netstumbler.org/showpost.php?p=89036

� Ne nécessite plus la capture de millions d'IV mais se base juste sur le nombre d'IV uniques capturés.

4. LAN sécurisés WiFi : Cassage du WEP (1)

� L'injection de trafic permet d'accélérer grandement la capture des trames :1. Tronque le message chiffré d'un caractère (1 octet) => message invalide2. Suppose une valeur V pour le dernier octet (0 =< V =< 255), corrige le message etréinjecte la trame vers l'AP3. L'AP rejette toute les trames sauf celle ayant le dernier octet valide (répéter 1 - 3)

� Décryptage des paquets ARP/IP� http://www.netstumbler.org/showthread.php?t=12489


Aircrack – dernières versions : ng et ptw (Unix & Windows)

� Très rapide et performant (cassage de la clé < 10s avec un nombre de trames suffisant)

� Implémente la nouvelle attaque statistique développée par KoreK� Nécessite un nombre d'IV unique pour pouvoir casser la clé

� Version ng : Nécessite 300 000 IV uniques pour une clé de 64 bits et 700 000 pour une clé de 128 bits

4. LAN sécurisés WiFi : cassage du WEP (2)

pour une clé de 128 bits� Version ptw : Nécessite 50 000 IV uniques pour une clé de 128 bits


Aircrack

� Les dernières versions (ng et ptw) permet l'injection de paquet après rejeud'une trame arp-request générant des IV uniques au niveau de la borne.

� Nécessite une mise à jour des pilotes (HostAP, Atheros, Prism54, wlan-ng)� Méthodes :

� iwpriv <interface> mode 2� iwconfig <inteface> mode Monitor channel <channel>� ifconfig <iface> up

4. LAN sécurisés WiFi : cassage du WEP (3)

� ifconfig <iface> up� airodump-ng --write "NomFichierSortie" --channel "NumeroChannel" "Interface" � aireplay-ng -3 -e ESSID -b @_mac_AP -h @_mac_station interface� aircrack-ng -x fichier_capture

� Trois composants :� airodump pour la capture de paquets (scanne les réseaux et conserve les paquets

qui serviront à décrypter la clef).� aireplay pour l’injection de paquets dans le but de stimuler le réseau et augmenter le

nombre de captures.� aircrack pour trouver la clé à partir des informations capturées par d'airodump

(nécessite un nombre minimum de paquets…)


� Clés WEP de 256 bits : plusieurs GO de données et plusieurs jours, voirplusieurs semaines pour récupérer la clé ;

� Modifier régulièrement la clé (les AP proposent généralement 4 clés au choixmais il faut alors changer également la clé sur les stations… ) ;

� Limiter la portée des AP aux locaux de l’entreprise pour éviter les « attaquesde parking » ;

� Activer sur l’AP un filtrage par adresses MAC ;

4. LAN sécurisés WiFi : autres solutions de sécurité

� Désactiver sur le point d’accès la diffusion du SSID ;� Désactiver sur le routeur Wifi le service DHCP ;� Utiliser le protocole de cryptage WPA (Wi-Fi Protected Access) qui est une

amélioration de WEP et fait appel à l'algorithme TKIP (Temporal Key IntegrityProtocol) pour changer la clé dynamiquement plusieurs fois par seconde ;

� Utiliser un algorithme plus robuste comme AES (Advanced EncryptionStandard) proposé dans la nouvelle norme sans fil 802.11i.


� WPA (Wi-Fi Protected Access) : recommandation de la Wi-Fi Alliance fondée sur un sous ensemble de la norme 802.11i.

� Depuis 2003 tous les produits certifiés au label WiFi doivent supporter cette recommandation.

� Clés de cryptage :� génération et distribution par l’AP de clés dynamiques avec TKIP (Temporal

Key Integrity Protocol) ;� TKIP génère une clé par trame (WEP : même clé pour toute la cellule et

4. LAN sécurisés WiFi : le chiffrement WPA

� TKIP génère une clé par trame (WEP : même clé pour toute la cellule et toutes les trames) ;

� vecteur d’initialisation de 48 bits (24 bits pour WEP) ;� code MIC (Message Integrity Code) pour vérifier l’intégrité de toute la trame.

� Mode d’authentification : � mode personnel ou mode PSK (Pre-Shared Key) : saisie d’un mot de passe

alphanumérique (« passphrase ») ;� mode entreprise : à base du protocole 802.1x, avec une authentification

centralisée des utilisateurs à partir d’un serveur de type RADIUS.


� Le mode PSK (Pre-Shared Key) est conçu pour les réseaux individuels qui ne peuvent sepermettre le coût et la complexité d'une solution utilisant un serveur d'identification 802.1x.

� La PSK est une phrase secrète (passphrase) partagée par le client et l’AP pouvant contenir de8 à 63 caractères ASCII ou 64 octets (256 bits).

� La PSK permet de générer la PMK (Pairwise Master Key) de 256 bits grâce à une fonction dehachage cryptographique :PMK = PBKDF2(passphrase, ssid, ssidLength, 4096, 256)

� La PMK peut être générée directement en entrant un mot de 64 octets à la place de lapassphrase (méthode plus sur car elle évite les attaque par dictionnaire).

� LA PMK est ensuite utilisée pour une authentification en 4 étapes.� La plupart des OS permettent à l'utilisateur de stocker la passphrase sur l'ordinateur afin de ne

4. LAN sécurisés WiFi : WPA et le mode PSK

� La plupart des OS permettent à l'utilisateur de stocker la passphrase sur l'ordinateur afin de nepas avoir à la saisir à nouveau mais cependant sous forme PMK, c'est-à-dire déjà hachée.


4. LAN sécurisés WiFi : WPA-PSK +TKIP ou AES

• WPA-PSK pour l’authentification• TKIP ou AES pour le cryptage


• WPA = PSK + TKIP• WPA2 = PSK + AES = 802.11i

Nommage Alliance

� Le standard de chiffrement avancé AES (Advanced Encryption Standard), aussi connu sous le nom de Rijndael, est un algorithme de chiffrement symétrique.

� AES a été choisi en 2000 pour remplacer DES (standard des années 1970) qui utilisait des clefs de 56 bits, contre 128 à 256 pour AES.

� Principe : � L'algorithme prend en entrée un bloc de 128 bits (16 octets), la clé fait 128, 192 ou 256 bits.� Les 16 octets en entrée sont permutés selon une table définie au préalable. � Ces octets sont ensuite placés dans une matrice de 4x4 éléments et ses lignes subissent une

rotation vers la droite. L'incrément pour la rotation varie selon le numéro de la ligne. � Une transformation linéaire est ensuite appliquée sur la matrice, elle consiste en la

4. LAN sécurisés WiFi : WPA et AES

Une transformation linéaire est ensuite appliquée sur la matrice, elle consiste en la multiplication binaire de chaque élément de la matrice avec des polynômes issus d'une matrice auxiliaire.

� Finalement, un XOR entre la matrice et une autre matrice permet d'obtenir une matrice intermédiaire.

� Ces différentes opérations sont répétées plusieurs fois et définissent un « tour ». Pour une clé de 128, 192 ou 256, AES nécessite respectivement 10, 12 ou 14 tours.


� Authentification à base du protocole 802.1x et centralisée pour tous les utilisateurs à partir d’un serveur de type RADIUS.

� Le client possède un logiciel de connexion compatible avec le 802.1x (donc avec l’EAP) et supporte une méthode d’authentification (EAP/TLS par ex.)

� L’AP est compatible 802.1x : � Il n’a pas besoin de connaître EAP/TLS ou toute autre méthode d’authentification particulière. � Il est capable de relayer des requêtes EAP vers le client (via la connexion WiFi) et vers le

serveur d’authentification (via le réseau de l’entreprise).

� Le serveur RADIUS gère la méthode d’authentification EAP/TLS :� Le serveur demandera au client de s’identifier selon une méthode. Si le client ne la gère pas, le

4. LAN sécurisés WiFi : WPA et 802.1x

� Le serveur demandera au client de s’identifier selon une méthode. Si le client ne la gère pas, le serveur en suggérera une autre et ainsi de suite jusqu’à ce que le client en accepte une.


� Faiblesses du WPA :� attaque de type « déni de service ». � un envoi d’au moins deux paquets chaque seconde utilisant une clé de

cryptage incorrecte provoque un blocage de l’AP qui réinitialise toutes les connexions utilisateurs pendant une minute.

� mécanisme de défense pour éviter les accès non-autorisés à un réseau protégé, mais pouvant bloquer tout un réseau sans fil.

� Version aircrack pour WPA-PSK, basée sur une attaque par dictionnaire.

4. LAN sécurisés WiFi : vulnérabilités de WPA

� Améliorations de WPA : � SSID (Service Set IDentifier) sécurisé ; � WPA2 : nouveau protocole CCMP (Counter-Mode/Cipher Block Chaining

Message Authentication Code Protocol) basé sur le chiffrement AES (Advanced Encryption Standard ) et une meilleure protection au niveau MAC.

� Standard 802.11i : implémente les deux protocoles de niveau MAC (TKIP et CCMP/AES) et supporte les architectures antérieures (WEP, PSK).


4. LAN sécurisés WiFi : exemple de capture


Cryptage WPA2/CCMP

4. LAN sécurisés WiFi : exemple de capture


Données décryptée

4. LAN sécurisés Bluetooth

� Sécurité basée sur l'exploitation des trois notions suivantes :

� une adresse dépendante du dispositif physique :1 carte Bluetooth ⇔ 1 adresse permanente de 48 bits.@ régies par l'IEEE, équivalent de l'adresse MAC pour les cartes réseau Ethernet.

� un code personnel d'identification : code personnel attribué à l'utilisateur qui permet de l'identifier.Code PIN stocké sur 1 à 16 octets.

� un dispositif de génération de nombre aléatoire sur 128 bits.

� Ces trois éléments primaires permettent de générer des clés d'authentification et de cryptage pour de sécuriser les transferts.


4. LAN sécurisés Bluetooth : 3 modes de sécurité

� Mode de sécurité n°1 : le moins fiable.Aucune fonction de sécurité n'est activée. Permet donc à tous les autres dispositif Bluetooth de se connecter.

� Mode de sécurité n°2 : garantit une sécurité après la connexion.Les fonctions offertes agissent au niveau application.

� Mode de sécurité n°3 : hérite des fonctionnalités du mode 2 + fonctions d'authentification et de cryptage avant que la connexion ne soit établie.d'authentification et de cryptage avant que la connexion ne soit établie.

� En plus de ces trois modes de sécurité : deux niveaux de sécurité pour les dispositifs physiques (fiable ou non fiable) et trois pour les services (Autorisé et Authentifié, Authentifié, Accès libre).


4. LAN sécurisés Bluetooth : un gestionnaire de sécurité

� Avant l'établissement d'une connexion, le gestionnaire de sécurité (Security Manager) choisit la politique de sécurité à partir :� du type de service utilisé ;� du dispositif distant avec lequel la communication va s'effectuer (son type et

son niveau de sécurité).

� Le Security Manager décide du niveau d'authentification utilisé et du type de cryptage.

� Les informations dont a besoin le gestionnaire sont stockées dans deux bases de données : � la base de données des dispositifs physiques stocke le type de dispositif,

son niveau de fiabilité et la taille de ses clés de cryptage ;� la base de données des services : informations relatives au niveau de

sécurité service et au mode d'acheminement de l'information.


4. LAN sécurisés Bluetooth : mécanismes sécuritaires propriétaires

� Suivant l’instant et la localisation, ces clés ont différents rôles :

� lors de l'initialisation du composant (unit key) ;� lors d'une communication initiée par un seul dispositif (init

key) ;� lors de l'amorce d'une communication bi-partie (link key) ;� lors d'une communication du maître destinée à plusieurs

KADAD

� Différentes clé sont générées à partir du nombre aléatoire de 128 bits et du code PIN.

� lors d'une communication du maître destinée à plusieurs destinataires (master key) ;

� toutes ces clés sont générées par les algorithmes propriétaires E0, E1, E3, E21, E22.

� Les transactions entre différentes entités Bluetooth se font via la "clé de lien" (link key ) partagée.

� Après génération de la clé de lien et authentification réciproque, une clé de cryptage est générée (encryptionkey)

� Possibilité d’utiliser une clé différente pour chaque paire d’équipements communiquant.

A

B

C

D

M

KMC

KMAKMD

KMB


4. LAN sécurisés Génération et utilisation des clés

PIN

E2

Link Key

Authentication

PIN

E2

Link Key

User Input(Initialization)

(possibly)PermanentStorage

Encryption Key

E3

Encryption

Encryption Key

E3

Storage

TemporaryStorage

E1, E2 : algorithmes propriétaires


4. LAN sécurisés Les vulnérabilités de Bluetooth

� Dénis de services : Les éléments d'un réseau sans fil sont nomades, et dépendent d'une source d‘énergie limitée.Attaque possible : surcharger de travail la machine à attaquer pour consommer le plus rapidement possible son énergie. Travaux en cours contre cette faille.

� Confidentialité : N'importe qui peut écouter les trames émises dans l'atmosphère � il estfacile de loguer les différentes connexions en identifiant les protagonistes à l'aide du code PIN ou de l'adresse Bluetooth des dispositifs physiques.

� Vol d'identité : Link key basée sur la unit key � vol aisé de l'identité d'un correspondant. � Vol d'identité : Link key basée sur la unit key � vol aisé de l'identité d'un correspondant. Ex. : A et B communiquent en se basant sur la unit key de A, un troisième intervenant C peut venir communiquer avec A et obtenir cette clé � C peut utiliser l'adresse Bluetooth de B pour se faire passer pour lui...

� Trous de sécurité dans les algorithmes : Code PIN trop court � algorithmes de sécurité propriétaires relativement inefficaces. Code facile à retrouver si code PIN de 5 caractères (longueur standard en Bluetooth).


4. LAN sécurisés Sécurité dans ZigBee

� Authentification et cryptage.� Utilisation du cryptage AES (Advanced Encryption Standard)

128 bits.� Concept d’un « centre de confiance ».� Clés de liens et de réseaux.� Clés de liens et de réseaux.� La sécurité peut être personnalisée en fonction de

l’application.� Les clés peuvent « câblées » dans l’application.


4. LAN sécurisés Sécurité dans WiMax

� Gérer par le gestionnaire de clés PKM (Privacy Key Management) de la sous-couche sécurité.

� Le certificat de la station d’abonné (Subscriber Station) est définie à partir d’une chaîne de certification.



� La SS (Subscriber Station) envoie sont certificat contenant sa clé publique.� La BS (Base Station) vérifie le certificat et génère une clé d’Authentification

(AK : Autenthication Key).� Le BS crypte AK avec la clé publique de la SS et la transmet (cryptage

RSA).� La SS décrypte AK.� La clé de cryptage de trafic TEK (Trafic Encryption Key) est générée sur la

BS et chiffré avec un clé dérivée de AK.BS et chiffré avec un clé dérivée de AK.� La TEK sert pour le cryptage du trafic qui suit (cryptage DES-CBC).

� Points faibles :� Pas d’authentification la BS par la SS ;� Algorithme DES peu sur ;� Gestion de la PKI.

� Défauts en partie corrigé sur WiMax Mobile :� authentification mutuelle RSA + EAP ;� chiffrement AES.


objectifs de la sécurité sécurité des...

Documents