diff --git a/content/secu_reseaux/7_utilistateurs/index.md b/content/secu_reseaux/7_utilistateurs/index.md new file mode 100644 index 0000000..1e8a4ce --- /dev/null +++ b/content/secu_reseaux/7_utilistateurs/index.md @@ -0,0 +1,193 @@ +--- +title: "Sécurité des réseaux : les utilisateurs" +date: 2022-10-25 +tags: ["authetification", "SSO", "kerberos"] +categories: ["Sécurité des réseaux", "Cours"] +matjax: true +--- + +Il est question ici de savoir comment authentifier les utilisateurs de manière +la plus sécurisée possible. On verra donc le *Single Sign On*, que se soit sur +un réseau local avec *Kerberos* ou sur le web. On parlera aussi de délégation +d'autorisation et d'authentification firte (2FA, FIDO). + +## SSO + +Pour faire une analogie, prenons l'exemple d'une zone protégée: notre identité +est vérifiée à l'entrée, un badge nous est fourni avec un acces à certaines +zones. + +Le but est d'entrée **le moins possible les informations d'indentification** + +## Kerberos + +Kerberos est un protocole d'authentification qui repose sur des clé secrète et +l'utilisation de tickets. Kerberos se base sur les exigence suivante: + + * **sûr**: une attaque du type MitM ne doit pas permettre à l'attaquant + d'obtenir des informations pour usurper l'identité de sa victime. + * **fiable**: doit pouvoir s'appuyer sur une architecture redondante et + résiliente. + * **transparent**: l'utilisateur ne doit pas être conscente du processus + d'authentification. + * **évolutif**: le système doit pouvoir passer à l'échelle. + +### Protocole de Needham Schroeder + +C'est une protocole d'authentification conçu pour l'utilisation dans un réseau +informatique non sûr. + +Soit \\(A\\) et \\(B\\) deux systèmes communiquant sur un réseau: + + * \\(S\\) et le serveur de confiance pour les deux protagonistes + * \\(K_{AS}\\) est la clé symétrique connue de \\(A\\) et \\(S\\) + * \\(K_{BS}\\) est la clé symétrique connue de \\(B\\) et \\(S\\) + * \\(N_{A}\\) et \\(N_{B}\\) des nonces pour \\(A\\) et \\(B\\) + +Voici le protocole: + + 1. \\( A \to S : A, B, N_{A} \\) + 2. \\( S \to A : \\{ N_{A}, K_{AB}, B, \\{ K_{AB},A\\}K_{BS}\\}K_{AS} \\) + 3. \\( A \to B : \\{K_{AB}, A\\}K_{BS}\\) + 4. \\( B \to A : \\{N_{B}\\}K_{AB}\\) + 5. \\( A \to B : \\{N_{B} - 1\\}K_{AB}\\) + +Ce protocole est **sensible au attaques par rejeu**. Cependant, dans son +implémentation au sein de *Kerberos*, un *timestamp* est ajouté. + +\\(\\{K_{AB}, A\\}K_{BS}\\) représente le **ticket Kerberos**. + +### Le protocole Kerberos + +Kerberos utilise un *Serveur d'authentification* noté *SA* qui connait **tous** +les mots de passe. Il partage une clé secrète *unique* lorsqu'un utilisateur +demande un service à un serveur: + + 1. Le module client du poste de travail envoi l'identifiant, le mot de passe + l'identité de A et de B au *SA* : + \\( A \to SA : ID_{A}, User_{A}, Pass_{A}, ID_{B} \\) + 2. Le *SA* authentifie l'utilisateur + 3. Le *SA* créé un ticket contenant l'identité de A et de B, le tout chiffré + avec le secret partagé entre A et B: + \\( \\{ID_{A},ID_{B} \\}K_{SA,B} \\) + 4. le *SA* envoi le ticket au poste client. + +Le ticket contient : + + * l'identifiant du serveur afin qu'il vérifie qu'il a correctement déchiffré le + message + * l'identifiant du poste client afin de connaitre l'origine de la demande ( + poste client de l'utilisateur) + * l'adresse du poste client ou son nom DNS afin d'éviter l'usurpation + d'identité. + +Le but est bien de **réduire** le nombre de fois ou l'utilisateur saisit son mot +de passe. Mais problème: **il est passé en clair!** + +### Le serveur de ticket + +Solution: déporter l'octroi de ticket sur un serveur dédié : le *TGS*' *Ticket +Granting Service*. + + 1. Le client demande un ticket d'octroi de ticket de la part de l'utilisateur + au SA: + \\( A \to SA : User, TGS, ID_{A} \\) + 2. Le SA répond par un ticket chiffré avec une clé dérivée du mot de passe de + l'utilisateur. Lorsque la réponse arrive, le client demande le mot de passe à + l'utilisateur, génère la clé et déchiffre le message: + \\( SA \to A : \\{ Ticket_{TGS}\\}_{mdp} \\) + 3. le client demande un ticket d'octroi au service de la part de l'utilisateur + : + \\( A \to TGS : ID_{A}, User, ID_{B}, Ticket_{TGS} \\) + 4. le TGS déchiffre le ticket et vérifie la validité du déchiffrement par la + présence de son ID, si tout se passe bien il génère un ticket pour accorder + l'accès au service : + \\( TGS \to A : Ticket_S \\) + 5. Le client demande l'accès au service de la part de l'utilisateur + \\( A \to S : A, Ticket_S \\) + +Où: + + * \\( Ticket_{TGS} = \\{ A, addr_A, TGS, timestamp \\}K_{SA,TGS}\\) + * \\( Ticket_S = \\{A, S, addr_C, timestamp\\}K_{TGS,S}\\) + +Le but est de détenir un ticket qui prouve mon authentification. Le but est +que les éléments puissent prouver leurs identités les un les autres. + +En pratique le protocole est plus compliqué, une clé est ajoutée dans le ticket +du TGS. Cette clé est utilisée régulièrement afin de résoudre un challenge. Elle +et connue que su TGS et du client. La même technique est utilisée entre le +serveur le le client. + +## WebSSO + +WebSSO est un protocole de *Single Sing-On* appliqué au web. On dénombre deux +protocoles principaux: *CAS* et *OpenID*. + +WebSSO se base sur les cercle de confiance, les fournisseurs d'identités (IDP) +et les fournisseurs de services (SP) + +### CAS - Central Authentication Service + +C'est un protocole utilisé pour les réseaux d'entreprise. Ici le serveur n'a pas +à connaitre les client, la confiance se fait par les certificats serveurs, + +Il est, comme Kerberos, basé sur des notions d'échange de tickets. + +Il est pertinent dans un réseau fermé et un environnement maitrisé. + +### OpenID + +Ce protocole est utilisé par les sites web grand public et les applications +mobiles, il est basé sur [Oauth2](https://fr.wikipedia.org/wiki/OAuth). + +OpenID permet d'accéder à une ressource sans connaitre son propriétaire ni ses +identifiants. On ne gère pas *d'authentification* mais **l'autorisation**. + +4 entités sont utilisées: + + * client; + * propriétaire (humain) + * le serveur + * le serveur d'autorisation + +## Authentification forte + +Il est question ici d'utiliser plus d'un facteur d'authentification : + + * basé sur la connaissance + * basé sur la propriété + * basé sur l'inhérence + +## FIDO2 + +Les mots de passe ont toujours posé problèmes : un même mot de passe pour +plusieurs, voire tous les services par exemple. Le protocole *FIDO2* propose un +token d'authentification qui utilise le *challenge-response*. + +Le token génère une **paire de clé** (cryptographie asymétrique) **par site**. +La partie publique est envoyée au site. + +Ces éléments sont stockée sur une puce sécurisée. + +Lors de l'authentification, le serveur envoie un challenge. Celui-ci est +envoyé à la clé. Celle-ci répond avec: + +\\( \\{ ID_{client}, ID_{serveur}, Challenge\\}sign_{(priv)}\\) + +### Attestation + +L'attestation est une signature posée sur la clé publique par un tiers. Le +serveur doit connaitre la clé qui sert à signer. + +Il esxiste plusieurs types de clé: + + * Aucune clé; + * auto-signé; + * `basic attestation`: la clé privée du constructeur est posée sur le token, en + cas de compromission d'un token, **ils le sont tous**; + * `ECDSA`: clé avec une partie forgée, ce fonctionnement est lourd en terme de + calcul et difficile à implémenter, utilisé pour des éléments critiques; + +La vérification de l'utilisateur (présence, code PIN) est conseillée mais pas +imposée par la norme.