Protocoles d'authentification

Transcription

1 INF4470 : Fiabilité et sécurité informatique Par Eric Gingras Été 2010 Protocoles d'authentification

2 Authentification De messages Signature MAC (permet pas de distinguer l'origine) De transactions Unicité À propos temporel

3 Protocoles Exemples de difficultés : Premiers bits Champs

4 Protocoles Importance de la complétude du protocole : «toutes les éventualités doivent être prévues et explicitement décrites»

5 Protocoles d'authentification Objectifs : Si A parvient à s'authentifier à B, B complète le protocole convaincu de A «Non-transferabilité» Empêcher l'«imposture»autant que possible 2 exemples

6 Protocoles d'authentification Propriétés : Réciprocité Efficacité de calcul Efficacité de communication Participation de tiers? Garanties de sécurité Conservation des secrets

7 Défi / réponse Principe : V pose un défi imprévisible au prétendant (A) Si le prétendant fourni une réponse démontrant sa connaissance d'un secret partagé : l'authentification est réussi *Le caractère dynamique du fonctionnement protège des attaques par «rejeu»

8 Défi / réponse Exemples : par chiffrement symétrique unilatérale mutuelle par chiffrement asymétrique unilatérale mutuelle

9 CHAP Les étapes du défi sont les suivantes : 1. un nonce de 16 bits est envoyé au client par le serveur d'authentification, ainsi qu'un # de séquence 2. le client «hache» le nonce, le compteur ainsi que la clé secrète (le mot de passe) avec MD5 3. le serveur d'authentification compare le haché reçu a la valeur attendue 4. Si les deux résultats sont égaux, alors l'identification réussit, sinon elle échoue

10 MS-CHAP (V2) Le serveur d'authentification envoie un identifiant de session ainsi qu'un nonce Le client distant répond avec : son nom, un autre nonce et un haché de l'identifiant de session, du nonce et du mot de passe. Le serveur d'authentification vérifie la réponse du client et renvoie : la notification de succès ou d'échec de l'authentification et un haché du nonce du client et du mot de passe de l'utilisateur distant.

11 Needham Shroeder 1. A --> TDC : A, B, N A 2. TDC --> A : C Ka (N A, B, K, C Kb (K, A)) 3. A --> B : C Kb (K, A) 4. B --> A : C K (N B ) 1. A --> B : C K (N B -1)

12 Kerberos Protocole d'authentification réseau Une création du MIT Fait usage d'un TDC Utilise un système de tickets au lieu de mots de passe en texte clair Repose sur le chiffrement symétrique À l'origine, il fut employé sur des systèmes Unix Intégré à Windows depuis la version 2000

13 Kerberos à l'origine 1. A --> TDC : A, B 2. TDC --> A : C A (T, V, K, B), C B (T, V, K, A) 3. A --> B : C K (T, A), C B (T, V, K, A) 4. B --> A : C K (T + 1)

14 Kerberos : clés Dans un réseau utilisant Kerberos, on distingue : le client : a sa propre clé secrète (Kc) le serveur : dispose aussi d'une clé secrète (Ks) le service d'émission de tickets («Ticket-Granting Service» ou TGS) : a une clé secrète (Ktgs) et connaît la clé secrète du serveur (Ks) le centre de distribution de clés («Key Distribution Center» ou KDC) : connaît les clés secrètes du client (Kc) et du service d'émission de tickets (Ktgs)

15 Kerberos : messages 1) Du KDC au Client Ticket Granting Ticket : C Ktgs (client, adresse, validité, clé de session[client/tgs = Kct]) C Kc (Kct) 2) Du Client au TGS Ticket Granting Ticket : service, C Ktgs (client, adresse, validité, Kct) Authentificateur : C Kct (client, timestamp) 3) Du TGS au Client Ticket (client, service) : service, C Ks (client, adresse, validité, clé de session[client/service = Kcs]) C Kct (Kcs) 4) Du Client au Service Ticket (client, service) : service, C Ks (client, adresse, validité, Kcs) Authentificateur : C Kcs (client, timestamp)

16

17 Kerberos : détails 1. L'usager entre son identifiant et son mot de passe 2. Le mot de passe est haché et cette empreinte sert de clé secrète (Kc) 3. Le client envoi au serveur d'authentification (KDC) une requête de service en clair (sans mot de passe ni clé). 4. Le KDC trouve le client dans sa base de données et transmet : A : une clé de session Client<->TGS (Kct) chiffré à l'aide de Kc. B : un «Ticket-Granting Ticket», chiffré à l'aide de la clé Ktgs, contenant : l'identifiant du client, l'adresse du client, une période de validité du «ticket» et la clé Kct 5. Une fois les messages A et B reçus par le client, celui ci peut retrouver la clé de session pour les communications entre le client et le TGS. Mais il ne peut consulter le message B qui est chiffré par la clé secrète du TGS.

18 Kerberos 6. Pour demander un service, le client envoi deux messages au TGS : C : l'identifiant du service demandé et le Ticket-Granting Ticket D : un authentificateur (ID du client et empreinte d'horodatage) chiffré par la clé Kct 7. Le TGS peut alors déchiffrer l'authentificateur(d) en utilisant la clé de session Kct, puis il répond au client par : E : le ticket du client au service (ID du client, adresse du client, validité et la clé de session client/service) chiffré avec la Ks F : la clé de session client/service (Kcs) chiffré avec la Kct 8. Le client peut alors transmettre au service : G : le ticket du client au service chiffré avec Ks H : un authentificateur (ID du client et empreinte d'horodatage) chiffré par la clé Kcs

19 Kerberos 9. Pour confirmer la réussite de l'authentification et l'acceptation du service, le message suivant est envoyé au client : I: l'empreinte d'horodatage reçu dans l'authentificateur + 1, chiffré par la clé Kcs 10. Après les vérifications le client peut demander le service 11. Le serveur rend alors le service

20 Radius À la base, pour les FAI Protocole entre un client Radius et une liste de comptes d'utilisateurs Authentification et comptabilisation PAP ou CHAP Retour en force avec les technologies sans-fils