Chapitre 3: Authentification & gestion d'identités PDF

Chapitre 3: Authentification & gestion d’identités Ouissem Ben Fredj [email protected] plan 1. contrôles d’accès 2. Les protocoles d’authentification simple 3. Authentification et TCP 4. Le Zero-Knowledge (ZK) proofs...

Chapitre 3: Authentification & gestion d’identités Ouissem Ben Fredj [email protected] plan 1. contrôles d’accès 2. Les protocoles d’authentification simple 3. Authentification et TCP 4. Le Zero-Knowledge (ZK) proofs 2 Contrôle d’accès ▪ Le contrôle d’accès est le modèle de mise en place d’autorisations (ex : Cyril a besoin de permissions pour accéder à cette ressource) ▪ Il est nécessaire pour permettre ▪ Aux utilisateurs autorisés d’accéder aux ressources dont ils ont besoin ▪ D’empêcher les autres utilisateurs (non autorisés) d’accéder aux ressources Contrôle d’accès ▪ Il recouvre : ▪ L’identification : l’entité indique qui elle est (= son identité, ex : je suis Cyril) ▪ L’authentification : vérification / validation de l’identité d’une entité (ex : l’utilisateur est bien Cyril) ▪ L’autorisation : vérification / validation qu’une entité a la permission d’accéder à une ressource (ex : Cyril a la permission d’accéder à cette ressource) De l’authentification à l’autorisation ▪ Avant d’accorder des permissions ou des privilèges, il est important de savoir à qui ou à quoi on compte les accorder. L’authentification précède donc l’autorisation ▪ L’authentification la plus courante est celle des utilisateurs (on peut aussi authentifier un service, une machine) ▪ Il existe plusieurs méthodes pour authentifier : ▪ Le savoir (ex : mot de passe) ▪ La possession (ex : jeton) ▪ L’être (ex : biométrie) ▪ Le savoir faire (ex : signature manuscrite) Autorisation ▪ Basée sur des critères d’accès ▪ Rôle ▪ Groupe ▪ Emplacement physique ou logique ▪ Heure ▪ Type de transaction ▪ Par défaut, dans un système sécurisé, l’accès devrait être refusé (si rien n’autorise explicitement l’accès alors il doit être implicitement refusé) ▪ Ex : pare-feu Mots de passe ▪ Moyen le plus courant et aussi le plus faible ▪ Les mots de passe ne sont JAMAIS stockés en clairs ▪ Ils sont stockés sous forme de hash (la fonction de hash est censée fournir si possible un hash unique et irréversible) ▪ Ensuite, lors de la saisie du mot de passe on calcule le hash et on compare à celui que l’on a stocké Cassage de mots de passe ▪ Évidence : il faut disposer des hashes ou de quelque chose dérivé des mots de passe ou de leurs hashes (hash de hash par ex.) sauf si on arrive à faire révéler le mot de passe directement par un utilisateur (ingénierie sociale) ▪ Ensuite, comme les hashes sont irréversibles, il existe des outils pour recalculer les hashes et vérifier qu’on a trouvé le bon mot de passe ▪ Dictionnaire ▪ Force brute ▪ Ici intervient l’importance de la force du hash mais aussi et surtout la force du mot de passe choisi par l’utilisateur ▪ Politique de longueur et de complexité de mots de passe, différence avec les mots de passe précédents, durée de vie, nombre de tentatives erronées…  Authentification vs autorisation ▪ Authentification  Êtes-vous qui vous prétendez être ? ▪ Restrictions sur qui (ou quoi) peut accéder au système ▪ Autorisation  Avez-vous le droit de le faire ? ▪ Restrictions sur les actions des utilisateurs authentifiés ▪ L'autorisation est une forme de contrôle d'accès ▪ Vue classique de l'autorisation… ▪ Listes de contrôle d'accès ( ACL ) ▪ Capacités (listes C)  Matrice de contrôle d'accès de Lampson ▪ Les sujets (utilisateurs) indexent les lignes ▪ Les objets (ressources) indexent les colonnes Programme Données de données Données SE de Comptabilité d’assurance de Paie Comptabilité Bob rx rx r   Alice rx rx r rw rw Sam rwx rwx r rw rw rx rx rw rw rw Programme de Comptabilité  Êtes-vous autorisé à faire cela ? ▪ La matrice de contrôle d'accès contient toutes les informations pertinentes ▪ Peut-être des centaines d'utilisateurs, des milliers de ressources ▪ Ensuite, la matrice a 1 000 000 d'entrées ▪ Comment gérer une si grande matrice ? ▪ Remarque : Nous devons vérifier cette matrice avant l'accès à une ressource par un utilisateur. ▪ Comment rendre cela plus efficace/pratique ?  Listes de contrôle d'accès (ACL) ▪ ACL : stocke la matrice de contrôle d'accès par colonne ▪ Exemple : L'ACL pour les données d'assurance est en bleu (et gras) Programme données Données de Données SE de Comptabilité d’assurance de Paie Comptabilité Bob rx rx r   Alice rx rx r rw rw Sam rwx rwx r rw rw rx rx rw rw rw Programme de Comptabilité  Capacités (ou C-Lists) ▪ Stocke la matrice de contrôle d'accès par ligne ▪ Exemple : la capacité d'Alice est en rouge (gras) Programme données Données de Données SE de Comptabilité d’assurance de Paie Comptabilité Bob rx rx r   Alice rx rx r rw rw Sam rwx rwx r rw rw rx rx rw rw rw Programme de Comptabilité  ACL vs Capacités r r Alice --- fichier1 Alice w fichier1 r rw w --- Bob r fichier2 Bob r fichier2 --- r rw r Fred r fichier3 Fred --- fichier3 r r Liste de contrôle d'accès (ACL) Capacité (de taille le nombre (de taille le nombre de fichiers) des utilisateurs) ▪ Notez que les flèches pointent dans des directions opposées… ▪ Avec les ACL , il faut encore associer les utilisateurs aux fichiers Député confus ▪ Deux ressources  Matrice de contrôle ▪ Compilateur et fichier d'accès FACTURE Compilateur FACTURE (informations de facturation) Alice X  ▪ Le compilateur peut écrire le fichier FACTURE Compilateur rx rw ▪ Alice peut appeler le compilateur ▪ Alice n'est pas autorisée à écrire à FACTURE ACL et Député confus Alice FACTURE Compilateur ▪ Le compilateur est Député agissant au nom d'Alice ▪ Le compilateur est confus ▪ Alice n'est pas autorisée à écrire FACTURE ▪ Le compilateur a confondu ses droits avec ceux d'Alice Député confus ▪ Le compilateur agissant pour Alice est confus ▪ Il y a eu une séparation de l'autorité du but pour lequel elle est utilisée ▪ Avec les ACL , plus difficile d'empêcher cela ▪ Avec des capacités, il est plus facile de prévenir ces problèmes ▪ Doit maintenir une association entre l'autorité et le but visé ▪ Capacités  facile de déléguer des pouvoirs ACL vs Capacités ▪ ACL ▪ Bon lorsque les utilisateurs gèrent leurs propres fichiers ▪ La protection est axée sur les données ▪ Modification facile des droits sur une ressource ▪ Capacités ▪ Facile à déléguer  éviter le député confus ▪ Facile à ajouter/supprimer des utilisateurs ▪ Plus difficile à mettre en œuvre ▪ La solution préférée pour la sécurité de l'information Différents types de contrôles d’accès ▪ Un modèle de contrôle d’accès décrit la façon dont une entité (ou sujet) peut accéder à une ressource (ou objet) ▪ Discretionary Access Control (DAC) ▪ Le contrôle d’accès est à la discrétion du propriétaire de la ressource ▪ Par défaut, le propriétaire est le créateur de l’objet ▪ La propriété peut être transférée ou attribuée différemment ▪ Mis en œuvre sous forme de permissions (ACL) ▪ Le système compare le jeton de sécurité de l’utilisateur (permissions et droits) avec l’ACL de la ressource  Différents types de contrôles d’accès ▪ Mandatory Access Control (MAC) ▪ cette politique de sécurité est contrôlée de manière centralisée par un administrateur de politique de sécurité ; les utilisateurs n'ont pas la possibilité de changer la politique d’accès ▪ Basé sur un système de labels (plus strict car l’OS prend la décision finale qui peut être contraire au souhait du propriétaire) ▪ Les utilisateurs se voient attribuer un niveau d’accréditation (ex: secret, confidentiel) ▪ Les données sont classées selon les mêmes niveaux (et cette classification accompagne les données) ▪ En complément, des niveaux d’accréditation des catégories peuvent être mentionnées pour respecter le principe du besoin de savoir (ce n’est pas parce que j’ai l’accréditation Confidentiel que je dois avoir accès à tous les projets confidentiels) ▪ Le système compare le niveau d’accréditation et les catégories de l’utilisateur avec le label de sécurité Différents types de contrôles d’accès ▪ Role Based Access Control (RBAC) ▪ Aussi appelé nondiscretionary access control ▪ Utilise un référentiel centralisé ▪ Différence entre rôle et groupe : ▪ Les deux peuvent contenir des utilisateurs ▪ Quand on appartient à un groupe, on a les droits du groupe plus les siens ▪ Les rôles permettent un contrôle resserré : quand on a les droits d’un rôle, on n’a rien de plus ▪ Pratique quand il y a de nombreux mouvements dans l’entreprise Les protocoles d’authentification simple Protocole ▪ Protocoles humains  les règles suivies dans les interactions humaines ▪ Exemple : Poser une question en classe ▪ Protocoles de mise en réseau  règles suivies dans les systèmes de communication en réseau ▪ Exemples : HTTP, FTP, etc. ▪ Protocole de sécurité  les règles (de communication) suivies dans une application de sécurité ▪ Exemples : SSL, IPSec, Kerberos, etc. Protocoles ▪ Les défauts de protocole peuvent être très subtils ▪ Plusieurs protocoles de sécurité bien connus présentent des failles importantes ▪ Y compris WEP, GSM et IPSec ▪ Des erreurs de mise en œuvre peuvent également survenir ▪ l'implémentation IE de SSL ▪ Pas facile d'avoir les bons protocoles... Protocole de sécurité idéal ▪ Doit satisfaire aux exigences de sécurité ▪ Les exigences doivent être précises ▪ Efficace ▪ Minimiser les besoins de calcul ▪ Minimiser l'utilisation de la bande passante, les retards… ▪ Robuste ▪ Fonctionne lorsque l'attaquant essaie de le casser ▪ Fonctionne si l'environnement change (légèrement) ▪ Facile à mettre en œuvre, facile à utiliser, flexible… Difficile de satisfaire tout cela ! Authentification ▪ Alice doit prouver son identité à Bob ▪ Alice et Bob peuvent être humains ou ordinateurs ▪ Peut également exiger que Bob prouve qu'il est Bob (authentification mutuelle) ▪ Probablement besoin d'établir une clé de session ▪ Peut avoir d'autres exigences, telles que ▪ Clés publiques, clés symétriques, fonctions de hachage, … ▪ Anonymat, démenti plausible, secret de transmission parfait, etc. Authentification ▪ L'authentification sur un ordinateur autonome est relativement simple ▪ Par exemple, hachez un mot de passe ▪ Le "chemin sécurisé", les attaques contre les logiciels d'authentification, l'enregistrement des frappes au clavier, etc., peuvent poser des problèmes ▪ L'authentification sur un réseau est difficile ▪ L'attaquant peut observer passivement les messages ▪ L'attaquant peut rejouer les messages ▪ Attaques actives possibles (insertion, suppression, modification) Authentification simple "Je suis Alice" Alice Bob Prouve le Mon mot de passe est "frank" ▪ Simple et peut convenir pour un système autonome ▪ Mais très peu sûr pour le système en réseau ▪ Soumis à une attaque par rejeu ▪ De plus, Bob doit connaître le mot de passe d'Alice Attaque d'authentification "Je suis Alice" Alice Bob Prouve le Mon mot de passe est "frank" Trudy Attaque d'authentification "Je suis Alice" Trudy Bob Prouve le Mon mot de passe est "frank" ▪ Ceci est un exemple d'attaque par rejeu ▪ Comment pouvons-nous empêcher une relecture ? Authentification simple Je suis Alice, mon mot de passe est "frank" Alice Bob ▪ Plus efficace, mais… ▪ … même problème que la version précédente Meilleure authentification "Je suis Alice" Alice Bob Prouve le h(mot de passe d'Alice) ▪ Cette approche cache le mot de passe d'Alice ▪ De Bob et Trudy ▪ Mais toujours sujet à une attaque par rejeu Défi-Réponse ▪ Pour empêcher le rejeu, utilisez défi-réponse ▪ L'objectif est d'assurer la "fraîcheur" ▪ Supposons que Bob veuille authentifier Alice ▪ Défi envoyé de Bob à Alice ▪ Le défi est choisi de sorte que… ▪ Le rejeu n'est pas possible ▪ Seule Alice peut fournir la bonne réponse ▪ Bob peut vérifier la réponse Nonce ▪ Pour assurer la fraîcheur, on peut employer un nonce ▪ Nonce == number used once ▪ Quoi utiliser pour les nonces ? ▪ Autrement dit, quel est le défi? ▪ Que devrait faire Alice avec le nonce ? ▪ Autrement dit, comment calculer la réponse? ▪ Comment Bob peut-il vérifier la réponse ? ▪ Doit-on utiliser des mots de passe ou des clés ?  Défi-Réponse "Je suis Alice" Alice Bob Nonce h(mot de passe d'Alice, Nonce)  Nonce est le défi  Le hachage est la réponse  Nonce empêche la relecture (assure la fraîcheur)  Le mot de passe est quelque chose qu'Alice connaît  Remarque : Bob doit connaître le mot de passe d'Alice pour vérifier  Défi-Réponse générique "Je suis Alice" Alice Bob Nonce Quelque chose qui ne pouvait être que d'Alice, et Bob peut vérifier ▪ En pratique, comment y parvenir ? ▪ Le mot de passe haché fonctionne, mais Bob doit le connaitre ▪ … le cryptage est bien meilleur ici (Alice et Bob peuvent être des THINGS (machines) dans l’IoT) Notation de clé symétrique ▪ Crypter le texte en clair P avec la clé K C = E(P,K) ▪ Déchiffrer le texte chiffré C avec clé K P = D(C,K) ▪ Ici, nous sommes concernés par les attaques sur les protocoles, pas d’attaques contre la cryptographie ▪ Donc, nous supposons que les algorithmes de chiffrement sont sécurisés Authentification : clé symétrique ▪ Alice et Bob partagent la clé symétrique K ▪ Clé K connue seulement d'Alice et Bob ▪ Authentification en prouvant la connaissance de la clé symétrique partagée ▪ Comment y parvenir ? ▪ Ne peut pas révéler la clé, ne doit pas autoriser le rejeu (ou autre), doit être vérifiable, …  Authentifier Alice à l'aide d'une clé symétrique "Je suis Alice" Alice, K. Bob, K R (un nonce) E(R,K)  Méthode sécurisée pour Bob pour authentifier Alice  Mais, Alice n'authentifie pas Bob  Alors, pouvons-nous parvenir à une authentification mutuelle ? Authentification mutuelle? "Je suis Alice", R Alice, K. Bob, K E(R,K) E(R,K) ▪ Quel est le problème avec cette image? ▪ "Alice" pourrait être Trudy (ou n'importe qui d'autre) ! Authentification mutuelle ▪ Puisque nous avons un protocole d'authentification unidirectionnel sécurisé… ▪ La chose évidente à faire est d'utiliser le protocole deux fois ▪ Une fois pour que Bob authentifie Alice ▪ Une fois pour qu'Alice authentifie Bob ▪ Cela doit fonctionner… Authentification mutuelle "Je suis Alice", RA Alice, K. Bob, K RB , E(RA , K) E(RB , K) ▪ Cela permet une authentification mutuelle… ▪ …ou le fait-il ? Sujet à une attaque par réflexion ▪ Diapositive suivante Attaque d'authentification mutuelle 1. "Je suis Alice", RA Trudy Bob, K 2. RB , E(RA , K) 3. "Je suis Alice", RB Trudy Bob, K 4. RC , E(RB , K) Authentification mutuelle ▪ Notre protocole d'authentification unidirectionnelle n'est pas sécurisé pour l'authentification mutuelle ▪ Les protocoles sont subtils ! ▪ Dans ce cas, la solution "évidente" n'est pas sécurisée ▪ De plus, si les hypothèses ou l'environnement changent, le protocole peut ne pas être sécurisé ▪ Il s'agit d'une source courante de défaillance de la sécurité ▪ Par exemple, les protocoles Internet Authentification mutuelle par clé symétrique "Je suis Alice", RA Alice, K. Bob, K RB , E(“Bob”,RA ,K ) E(“Alice”,RB ,K ) ▪ Ces changements « insignifiants » aident-ils ? ▪ Oui! Car Trudy ne peut pas utiliser une réponse de Bob pour le troisième message - Bob se rendra compte qu'il l'a chiffré lui-même Attaque d'authentification mutuelle non réussie 1. "Je suis Alice", RA Trudy Bob, K 2. RB , E(“Bob”,RA , K) 3. "Je suis Alice", RB Trudy Bob, K 4. RC , E(“Bob”, RB , K) Notation de clé publique ▪ Crypter M avec la clé publique d'Alice : {M} Alice ▪ Signez M avec la clé privée d'Alice : [M] Alice ▪ Alors ▪ [{ M} Alice ] Alice = M ▪ {[ M] Alice } Alice = M ▪ N'importe qui peut utiliser la clé publique d'Alice ▪ Seule Alice peut utiliser sa clé privée  Authentification par clé publique "Je suis Alice" Alice Bob, R {R} Alice R ▪ Est-ce sécurisé ? ▪ Trudy peut amener Alice à déchiffrer n'importe quoi ! Empêchez cela en ayant deux paires de clés Authentification par clé publique "Je suis Alice" Alice Bob R [R] Alice ▪ Est-ce sécurisé ? ▪ Trudy peut faire signer n'importe quoi à Alice ! ▪ Identique au précédent  devrait avoir deux paires de clés Clés publiques ▪ Généralement, une mauvaise idée d'utiliser la même paire de clés pour le chiffrement et la signature ▪ Au lieu de cela, aurait dû… ▪ …une paire de clés pour chiffrer/ déchiffrer et signer/vérifier les signatures… ▪ …et une paire de clés différente pour l'authentification Clé de session ▪ Généralement, une clé de session est requise ▪ Une clé symétrique pour la session en cours ▪ Utilisé pour la confidentialité et/ou l'intégrité ▪ Comment authentifier et établir une clé de session (c'est-à-dire une clé symétrique partagée) ? ▪ Une fois l'authentification terminée, Alice et Bob partagent une clé de session ▪ Trudy ne peut pas casser l'authentification… ▪ … et Trudy ne peut pas déterminer la clé de session Authentification et clé de session "Je suis Alice", R Alice Bob, k {R, K} Alice {R +1, K} Bob ▪ Est-ce sécurisé ? ▪ (1) Alice est authentifiée et (2) la clé de session est sécurisée ▪ Le "nonce" d'Alice, R , inutile pour authentifier Bob ▪ La clé K agit comme le nonce de Bob à Alice ▪ Pas d'authentification mutuelle Authentification par clé publique et clé de session "Je suis Alice", R Alice Bob, k [R, K] Bob [R +1, K] Alice ▪ Est-ce sécurisé ? ▪ Authentification mutuelle (bonne), mais… ▪ … la clé de session n'est pas protégée (très mauvais) Authentification par clé publique et clé de session "Je suis Alice", R Alice Bob, k {[R, K] Bob } Alice {[R +1, K] Alice } Bob ▪ Est-ce sécurisé ? ▪ Non! Il est sujet d’une attaque ▪ Voir la diapositive suivante …  Authentification par clé publique et clé de session 1. "Je suis Alice", R 2. "Je suis Trudy", R Alice Trudy Bob 3. {[R, K] Bob } Trudy 4. { } Alice 6. temps mort 5. {[R +1, K] Alice } Bob ▪ Trudy peut obtenir [R, K] Bob et K de 3. ▪ Alice utilise cette même clé K ▪ Et Alice pense qu'elle parle à Bob Authentification par clé publique et clé de session "Je suis Alice", R Alice Bob [{R, K} Alice ] Bob [{R +1, K} Bob ] Alice ▪ Est-ce sécurisé ? ▪ Semble être OK ▪ Tout le monde peut voir {R, K} Alice et {R +1, K} Bob Horodatages ▪ Un horodatage T est dérivé de l'heure actuelle ▪ Les horodatages peuvent être utilisés pour empêcher le rejeu ▪ Utilisé dans Kerberos, par exemple ▪ horodatages réduisent le nombre de msgs (bon) ▪ Un défi que les deux parties connaissent d'avance ▪ "Time" est un paramètre critique pour la sécurité (mauvais) ▪ Les horloges ne sont pas les mêmes et/ou les retards du réseau, il faut donc tenir compte du décalage d'horloge  crée un risque de rejeu ▪ Quel est le décalage d'horloge suffisant ? Authentification par clé publique avec horodatage T "Je suis Alice", {[T, K] Alice } Bob Alice, k Bob {[T +1, K] Bob } Alice  Authentification mutuelle sécurisée ?  Clé de session sécurisée ?  Semble être OK Authentification par clé publique avec horodatage T "Je suis Alice", [{T, K} Bob ] Alice Alice Bob [{T +1, K} Alice ] Bob  Authentification et clé de session sécurisées?  Trudy peut utiliser la clé publique d'Alice pour trouver {T, K}Bob et ensuite… Authentification par clé publique avec horodatage T "Je suis Trudy", [ {T, K} Bob ] Trudy Trudy Bob [{T +1, K } Trudy ] Bob  Trudy obtient la clé de session Alice-Bob K  Remarque : Trudy doit agir dans les limites de l'horloge Authentification par clé publique ▪ Signez et chiffrer avec nonce… ▪ Insécurisé ▪ Chiffrer et signer avec nonce… ▪ Sécurisé ▪ Signer et chiffrer avec horodatage… ▪ Sécurisé ▪ Chiffrer et signer avec horodatage… ▪ Insécurisé Secret de transmission parfait ▪ Réfléchissez à ce "problème"... ▪ Alice chiffre le message avec la clé partagée K et envoie le texte chiffré à Bob ▪ Trudy enregistre le texte chiffré et attaque plus tard l'ordinateur d'Alice (ou de Bob) pour récupérer K ▪ Puis Trudy décrypte les messages enregistrés ▪ Perfect Forward Secrecy (PFS) : Trudy ne peut pas déchiffrer ultérieurement le texte chiffré enregistré ▪ Même si Trudy obtient la clé K ou d'autres secrets ▪ Le PFS est-il possible ? Secret de transmission parfait (PFS) ▪ Supposons qu'Alice et Bob partagent la clé K ▪ Pour un secret de transmission parfait, Alice et Bob ne peuvent pas utiliser K pour chiffrer ▪ Au lieu de cela, ils doivent utiliser une clé de session KS et l'oublier après son utilisation ▪ Alice et Bob peuvent-ils se mettre d'accord sur la clé de session KS d'une manière qui fournit PFS ? Protocole de clé de session naïve E(KS , K) Alice, K. Bob, K E(messages, KS ) ▪ Trudy pourrait enregistrer E(KS , K) ▪ Si Trudy obtient plus tard K , elle peut obtenir KS ▪ Ensuite, Trudy peut décrypter les messages enregistrés ▪ Pas de secret de transmission parfait dans ce cas Secret de transmission parfait ▪ Nous pouvons utiliser Diffie-Hellman pour PFS ▪ Rappel : public g et p ga mod p Alice, a Bob, b gb mod p  Mais Diffie-Hellman est soumis au MiM  Comment obtenir PFS et empêcher MiM ?  Secret de transmission parfait E(ga mod p, K) Alice : K , a Bob : K , b E(gb mod p, K) ▪ Clé de session KS = gab mod p ▪ Alice oublie a , Bob oublie b ▪ C'est ce qu'on appelle Ephemeral Diffie-Hellman ▪ Ni Alice ni Bob ne peuvent plus tard récupérer KS ▪ Existe-t-il d'autres moyens d'atteindre la PFS ?  Authentification mutuelle, clé de session et PFS "Je suis Alice", RA Alice, RA, a Bob, RB, b RB , [RA , gb mod p] Bob [RB , ga mod p] Alice  La clé de session est K = gab mod p  Alice oublie a et Bob oublie b  Si Trudy obtient plus tard les secrets de Bob et d'Alice, elle ne peut pas récupérer la clé de session K  La signature des valeurs Diffie-Hellman empêche l'attaque MiM  la signature des nonces empêche une relecture Authentification et TCP Authentification basée sur TCP ▪ TCP non destiné à être utilisé comme protocole d'authentification ▪ Mais l'adresse IP dans la connexion TCP peut être ( mal) utilisée pour l'authentification ▪ En outre, un mode d'IPSec repose sur l'adresse IP pour l' authentification  Prise de contact TCP à 3 phases SYN , SEQ a Alice Bob SYN , ACK a+1, SEQ b ACK b+1, données Numéros de séquence initiaux : SEQ a et SEQ b  Censé être choisi au hasard Si ce n'est pas le cas, vous pourriez avoir des problèmes… Si Trudy intercepte le deuxième message, elle connaîtra b elle pourra forger le dernier message ACK  Attaque d'authentification TCP Trudy Bob 5: Trudy devine b2. comment? Bob reçoit des données de Trudy en le croyant de Alice (attaque forgé) 6. 6: Attaque DOS pour empêcher 6. Alice de terminer la session 6. incomplète avec Bob Alice 6. Attaque d'authentification TCP ▪ Trudy devine b2: Trudy pourrait envoyer de nombreux paquets SYN à Bob, essayant de diagnostiquer son schéma initial de génération de numéros de séquence avant de tenter de deviner une valeur. ▪ Trudy ne peut pas voir ce que Bob envoie, mais elle peut envoyer des paquets à Bob, tout en se faisant passer pour Alice ▪ Trudy doit empêcher Alice de recevoir la réponse de Bob (sinon la connexion se terminera) ▪ Si un mot de passe (ou une autre authentification) est requis, cette attaque échoue ▪ Si la connexion TCP est utilisée pour l'authentification, l'attaque peut réussir ▪ Mauvaise idée de s'appuyer sur TCP pour l'authentification Zero-Knowledge (ZK) proofs Le Zero-Knowledge (ZK) proofs ▪ méthode d’authentification/identification ▪ Le concept général: ▪ Une entité A (le prouveur ) prouve sa connaissance d’un secret à une entité B (le vérifieur ), sans divulguer son secret. 74 Propriétés de ZK ▪ Cette preuve doit avoir 3 propriétés: ▪ Consistante : le vérifieur doit accepter la preuve si elle se présente et que le protocole a été correctement suivi. ▪ Significative : en cas d’erreur, le vérifieur ne pourra pas être trompé, il finira par connaître la vrai nature du prouveur en répétant les expériences. ▪ Sans divulgation de connaissance : la preuve fournie à B ne lui donne aucune information sur le secret lui- même. On dit que la preuve n’est pas transférable : ▪ B n’apprend pas le secret ▪ Il ne peut pas faire croire à un tiers qu’il dispose lui aussi du secret 75 ▪ Les preuves ZK sont dites interactives car elles se réalisent en 3 étapes : 1. Annonce : Le prouveur (A) envoie un élément destiné à prouver sa connaissance d’un secret 2. Challenge : Le vérifieur (B) renvoie une question visant à l’en assurer 3. Réponse : Le prouveur (A) répond en utilisant son secret 76  ZK: exemple: la caverne d’Ali-Baba Bob Alice ▪ Alice (prouveur) et Bob (vérifieur). ▪ Porte de A à B ou de B à A s’ouvrant à l'aide d'un mot magique ▪ Alice veut prouver à Bob qu'elle connaît le mot magique pour ouvrir la porte mais ne veut pas que Bob l'apprenne. 77 ZK: exemple: la caverne d’Ali-Baba 1. Bob attend à l’entrée de la caverne. Alice entre et choisit aléatoirement le couloir de gauche (A) ou de droite (B). Elle choisit le couloir B et s’arrête à la porte du fond qui nécessite un mot de passe. 2. Bob entre dans la caverne, s’arrête à la jonction des deux couloirs et dit à Alice par quel couloir il souhaite la voir revenir (il choisit arbitrairement celui de gauche ou de droite). 3. Obligée de passer par la porte, mais connaissant le mot de passe, elle rejoint Bob par le bon couloir et prouve donc qu’elle connaît le mot de passe. 78 ZK: exemple: la caverne d’Ali-Baba ▪ Et si Alice est déjà dans le couloir demandé par Bob ? Il y a plusieurs possibilités : ▪ Alice connaît le mot de passe : ▪ si elle se trouve en A et que Bob dit « B », elle satisfait la requête ▪ si elle se trouve en B et que Bob dit « A », elle satisfait la requête ▪ si elle se trouve en A et que Bob dit « A », elle satisfait la requête ▪ si elle se trouve en B et que Bob dit « B », elle satisfait la requête ▪ Alice ne connaît pas le mot de passe : ▪ si elle se trouve en A et que Bob dit « B », elle ne satisfait pas la requête ▪ si elle se trouve en B et que Bob dit « A », elle ne satisfait pas la requête ▪ si elle se trouve en A et que Bob dit « A », elle satisfait la requête ▪ si elle se trouve en B et que Bob dit « B », elle satisfait la requête 79 ZK: exemple: la caverne d’Ali-Baba ▪ Si Alice connaît le mot de passe, il n’y a jamais de problème. Si Alice ne le connaît pas, il y a une chance sur deux que Bob soit trompé à la première expérience. ▪ Plus Bob la répétera, plus il pourra croire Alice : après n essais, il y a 1/2n chances que Bob soit trompé ▪ Une seule erreur, et on peut déduire qu’Alice ne connaît pas le secret. Par contre, 100 bonnes arrivées ne permettent aucune conclusion sûre à 100% bien que la probabilité d’erreur soit extrêmement faible. 80  Protocole Fiat-Shamir ▪ Les protocoles basés sur les grottes ne sont pas pratiques ▪ Pouvons-nous obtenir le même effet sans la grotte ? ▪ Trouver des racines carrées modulo N est difficile ▪ Équivalent à la factorisation ▪ Supposons que N = pq , où p et q premiers ▪ Alice a un secret S ▪ N et v = S2 mod N sont publics , S est secret ▪ Alice doit convaincre Bob qu'elle connaît S sans révéler aucune information sur S  Fiat-Shamir x = r2 mod N Alice Bob S: secret e  {0,1} e: nb aléatoire r: nb aleatoire y = r  Se mod N ▪ Public : Module N et v = S2 mod N ▪ Alice sélectionne aléatoirement r, Bob choisit e  {0,1} ▪ Bob vérifie : y2 = X Ve mod N ▪ Notez que y2 = r2  S2e = r2  ( S2 )e = X Ve mod N  Fiat-Shamir : e = 1 x = r2 mod N Alice e=1 Bob S: secret e: nb aléatoire r: nb aleatoire y = r  S mod N ▪ Public : Module N et v = S2 mod N ▪ Alice sélectionne aléatoirement r, Bob choisit e =1 ▪ Si y 2 = x  v mod N alors Bob l'accepte ▪ Et Alice passe cette itération du protocole ▪ Notez qu'Alice doit connaître S dans ce cas  Fiat-Shamir : e = 0 x = r2 mod N Alice Bob S: secret e=0 e: nb aléatoire r: nb aleatoire y = r mod N ▪ Public : Module N et v = S2 mod N ▪ Alice sélectionne aléatoirement r, Bob choisit e = 0 ▪ Bob doit vérifier si y2 = x mod N ▪ "Alice" n'a pas besoin de connaître S dans ce cas ! Fiat-Shamir ▪ Public : module N et v = S 2 mod N ▪ Secret : Alice connaît S ▪ Alice choisi r au hasard et s'engage sur r en envoyant x = r2 mod N à Bob ▪ Bob envoie un défi e  {0,1} à Alice ▪ Alice répond par y = r  Se mod N ▪ Bob vérifie si y2 = x Ve mod N ▪ Cela prouve-t-il que la réponse vient d'Alice ?  Fiat-Shamir fonctionne-t-il ? ▪ Si tout le monde suit le protocole, les maths fonctionnent : ▪ Public: v = S 2 mod N ▪ Alice à Bob : x = r2 mod N et y = r  Se mod N ▪ Bob vérifie : y2 = x  ve mod N ▪ Trudy peut-elle convaincre Bob qu'elle est Alice ? ▪ Si Trudy attend e = 0 , elle suit le protocole : envoie x = r2 mod N dans le msg 1 et y = r mod N dans le msg 3 ▪ Si Trudy attend e = 1 , elle envoie x = r 2  v  1 mod N dans msg 1 et y=r mod N dans msg 3 ▪ Bob calcule y² = r² et xve = r²v-1v = r² donc il accepte le message ▪ Si Bob choisit e  {0,1} au hasard, Trudy ne peut tromper Bob qu'avec probabilité 1/2  Faits sur Fiat-Shamir ▪ Trudy peut tromper Bob avec probabilité 1/2 , mais… ▪ … après n itérations, la probabilité que Trudy puisse convaincre Bob qu'elle est Alice n'est que de 1/2n ▪ Tout comme la grotte de Bob ! ▪ Bob: e  {0,1} doit être imprévisible ▪ Alice doit utiliser un nouveau r à chaque itération, sinon… ▪ Si e = 0 , Alice envoie r mod N dans le message 3 ▪ Si e = 1 , Alice envoie r  S mod N dans le message 3 ▪ N'importe qui peut trouver S étant donné r mod N et r  S mod N  Fiat-Shamir zéro connaissance ? ▪ Aucune connaissance signifie que personne n'apprend rien sur le secret S ▪ Public: v = S 2 mod N ▪ Trudy voit r2 mod N dans le message 1 ▪ Trudy voit r  S mod N dans le message 3 (si e = 1 ) ▪ Si Trudy peut trouver r à partir de r2 mod N , elle obtient S ▪ Mais cela nécessite un calcul de racine carrée modulaire ▪ Si Trudy pouvait trouver des racines carrées modulaires, elle pourrait obtenir S de v ▪ Le protocole ne semble pas "aider" à trouver S