DS #1 : Principe et Algorithme Cryptographiques Université de Lille-1 / FIL PAC 10 mars 2016 Vous avez 1h30 et les documents sont autorisés. Presque toutes les questions ci-dessous admettent des réponses courtes, en quelques phrases. La rigueur et la précision des raisonnement seront évaluées de manière déterminante. Dans tout le sujet, E(K, M) désigne le chiffrement du message M par l algorithme de chiffrement symétrique E en utilisant la clef K. N oubliez pas de rendre la feuille à part. 1 Tailles de clef L algorithme A5/1 est utilisé pour chiffrer les transmissions des téléphones GSM (la «2G»). C est un algorithme de chiffrement symétrique avec des clefs de 56 bits, conçu en 1987. Certains pays voulaient qu il offre un niveau de sécurité élevé (notamment l allemagne de l ouest, voisine du rideau de fer), tandis que d autres (les USA, la Grande-Bretagne) voulaient qu il soit faible. Question 1: D après-vous, qui a eu gain de cause? La taille de clef choisie (56 bits) est trop faible pour garantir un niveau de sécurité raisonnable. On a vu en TD qu une recherche exhaustive sur toutes les clefs de 56 bits était faisable en pratique. Cette taille a manifestement été choisie pour a) permettre aux agences de renseignement de pouvoir casser le chiffrement et se livrer à des écoutes, tout en b) empêchant des particuliers de le faire. Sur le site http://www.meganet.com, on peut acheter un logiciel de cryptographie propriétaires, reposant sur la technique révolutionnaire des Matrices Virtuelles R. C est un algorithme de chiffrement symétrique avec des clefs de 1 000 000 bits. Ses auteurs prétendent qu il offre bien plus de sécurité que l AES qui n offre que des clefs de 256 bits au maximum. Question 2: Qu en pensez-vous? L argument n est pas convainquant. On a vu qu avec des clefs de 128 bits, la recherche exhaustive n est pas possible, ni actuellement, ni dans le futur prévisible. C est à plus forte raison vrai pour 256 bits de clefs. Par ailleurs, l AES n a, à ce jour, pas de faille qui permette de le «casser» autrement qu en tentant la recherche exhaustive. Ceci démontre, tout au plus, que ceux qui écrivent ça n ont pas compris grand chose aux critères qui aboutissent aux choix de taille de clefs. Ca n inspire pas confiance pour le reste... Une étude menée en 2012 (https://eprint.iacr.org/2012/064.pdf) a démontré qu à l époque on trouvait environ 1% des certificats SSL/TLS sur internet contenant des clefs RSA de 512 bits ou moins. Question 3: Ces clefs offrent-elles plus ou moins de sécurité que l AES-128? Pas du tout. Face à un bon algorithme de chiffrement symétrique, on ne peut en principe rien faire de mieux que de tenter une recherche exhaustive. Cependant, étant donné une clef RSA, on peut tenter de lancer un algorithme de factorisation. On a vu leur complexité en TD, et on a dit qu une clef RSA de 768 bits, donc beaucoup plus grosse, a été cassée en pratique par une équipe universitaire (=moyens réduits) en 2009. Des clefs de 512 bits avaient été cassé en 1999. Le niveau de sécurité offert n a donc rien à voir avec celui de l AES, qu on ne sait pas casser en pratique.
2 Certificat SSL de l université Le portail de l université (https://portail.univ-lille1.fr/) est accessible via une connexion sécurisée. Version courte : un protocole à clef publique est utilisé pour a) établir un tunnel chiffré et authentifié jusqu au serveur HTTPS de l université et b) garantir à votre navigateur web que la machine à laquelle il est connecté est bel et bien le serveur HTTPS de l université. Pour démontrer son identité lors de la connection, le serveur web de l université effectue une signature avec l algorithme de signature RSA. Le serveur web envoie également un certificat, qui permet au navigateur web de vérifier la correction de la signature. Question 4: Rappelez ce qu est un certificat. Un certificat est une paire «nom, clef publique», signée par l émeteur du certificat, qui garantit ainsi (qu il pense) que la clef publique en question appartient bien à la bonne personne. Question 5: Pourquoi le serveur HTTPS envoie-t-il un certificat, et pas juste sa clef publique, afin de permettre la vérification de ses signatures? S il n envoyait que sa clef publique, il y aurait des possibilités d attaque par le milieu comme on a vu en cours/td. Un adversaire actif pourrait intercepter la bonne clef, et envoyer la sienne à la place. Le certificat interdit ceci en authentifiant la clef publique du serveur HTTPS. En fait, le certificat de l université a été émis par une entreprise hollandaise, Terena. Mon navigateur web ne contient pas le certificat de Terena. Mais le serveur HTTPS de l université fournit aussi un certificat pour Terena, émis par l entreprise américaine DigiCert Inc. Mon navigateur web contient d avance la clef-publique de DigiCert Inc. Question 6: Dans ce contexte, détaillez les opérations effectuées par mon navigateur web pour effectuer la vérification de la signature du serveur HTTPS de l université. Mon navigateur vérifie d abord que la signature réalisée par DigiCert et contenue dans le certificat de Terena est correcte. Il peut le faire car il contient d avance la clef de vérification des signatures de DigiCert. Une fois que l authenticité de la clef publique de Terena est établie, il vérifie la signature émise par Téréna, contenue dans le certificat de l université. Ceci garantit que la clef publique de l université est valide (les identités aussi sont vérifiées, bien sûr). Question 7: La clef publique RSA de DigiCert Inc est de taille 2048 bits, tout comme celle de Terena. Celle de l université est de taille 4096 bits. Ceci est-il judicieux? Même si ceci ne pose pas de problème, mais il ne semble pas utile, du point de vue de la sécurité, d avoir une clef plus grosse «en bout de chaine» qu en début de chaine. Casser la clef de DigiCert a beaucoup plus d intérêt que de casser celle de l université (cela permet de forger des certificats acceptés a priori par tous les navigateurs...). En plus, si on est capable de casser la clef de DigiCert, on peut forger un certificat pirate pour le domaine de l université. Du coup, l université aurait pu se contenter d une clef de 2048 bits (=opérations plus rapides, bande passante préservée), pour un niveau de sécurité rigoureusement équivalent. Une fois le serveur HTTPS de l université authentifié, une clef de session symétrique est établie par un protocole d échange de clef (comme le protocole de Needham-Schroder-Löwe qu on a vu en TD), et toutes les données qui transitent entre le serveur et mon navigateur web sont chiffrées avec cette clef (avec l AES-256-CBC), et sont authentifiées par un code d authentification de message. Question 8: D après vous, pourquoi bascule-t-on vers de la cryptographie à clef secrète, plutôt que de continuer à utiliser de la cryptographie à clef publique? Pour des questions de performance, comme on l a déjà dit. Mon laptop est capable de faire le chiffrement AES-128 à 330 Mo/s, mais la signature RSA (2048 bits) à 220 Ko/s... 3 Protocole Kerberos Dans le TP, une des tâches consiste à implémenter le protocole Kerberos. Il est décrit ici entièrement, donc même si vous n avez pas fait le TP ce n est pas grave.
Dans le protocole, il y a des clients (des utilisateurs, comme vous) et des serveurs auxquels les clients veulent accéder (des machines distantes, des imprimantes, etc.). Chaque client possède une clef secrète qui l authentifie (un mot de passe), et chaque serveur aussi. Les clients ne connaissent pas les clefs des serveurs, et vice-versa. Le protocole permet aux clients d établir des connections sécurisées et authentifiées aux serveurs auxquels ils ont le droit d accéder. Pour cela, ils sont assistés par deux machines spéciales : l Authentication Service (AS) connait les clefs de tous les clients, et le Ticket-Granting-Service (TGS) connait les clefs de tous les serveurs. Ces deux services possèdent en commun une clef secrète, la AS-TGS Key. Pour établir une connection avec un serveur, un client doit d abord s authentifier auprès de l AS. 1. Le client envoie son nom à l AS. 2. Si l AS ne connaît pas le client, le protocole d arrête. 3. L AS fabrique une clef symétrique fraiche, la Client-TGS Key. Il génère aussi le Ticket-Granting Ticket. Ce dernier contient le nom de l utilisateur, la date, et la Client-TGS Key. Le tout est chiffré avec la AS-TGS Key. 4. L AS envoie au client le Ticket-Granting Ticket, ainsi que la Client-TGS Key chiffrée avec le mot de passe du client. Le Ticket-Granting Ticket et la Client-TGS Key sevent au client à démontrer son identité auprès du TGS, et à établir un tunnel chiffré avec ce dernier. 5. Le client fabrique un authenticateur, c est-à-dire qu il chiffre son nom et la date avec la Client-TGS Key. 6. Le client envoie au TGS le Ticket-Granting Ticket, l authenticateur, et le nom du serveur auquel il veut accéder. 7. Le TGS vérifie si le client a bien le droit d accéder au serveur demandé ; si ce n est pas le cas, le protocole s arrête. 8. Le TGS fabrique une nouvelle clef symétrique fraiche, la Client-Server Key. Il génère également le Client-Server Ticket, qui contient le nom de l utilisateur, la date, et la Client-Server Key, le tout chiffrée avec la clef secrète du serveur. 9. Le TGS envoie au client le Client-Server Ticket, ainsi que la Client-Server Key chiffrée avec la Client- TGS Key. Le Client-Server Ticket et la Client-Server Key sevent au client à démontrer son identité auprès du serveur, et à établir un tunnel chiffré avec ce dernier. 10. Le client fabrique un nouvel authenticateur, c est-à-dire qu il chiffre son nom et la date avec la Client-Server Key. 11. Le client envoie au Serveur le Ticket-Server Ticket et cet authenticateur. Le client et le serveur peuvent enfin s échanger des données chiffrées avec la Client-Server Key. Question 9: Complétez le dessin sur la feuille à part qui résume les différentes interactions. Indiquez les données échangées, et ce par quoi elles sont chiffrées. Question 10: Le client peut-il examiner le contenu des différents «Tickets»? Non. Les tickets sont toujours chiffrés avec une clef que le client ne connaît pas : soit la AS-TGS Key, soit la clef secrète du serveur. Question 11: En quoi est-ce que les «Authenticateurs» permettent de vérifier mon identité? Les authenticateurs contiennent mon identité, et son chiffrés avec une clef que moi seul suis censé connaître. Le premier authenticateur est chiffré avec la Client-TGS Key, que je ne peux obtenir que si je connais mon propre mot de passe. Le deuxième est chiffré avec la Client-Server Key, que je ne peux obtenir que si je connais la Client-TGS Key.
Client AS username TGT := E(AS-TGS Key, {username, date, Client-TGS Key}) TGT E(password, Client-TGS Key) Client TGS Auth := E(Client-TGS Key, {username, date}) TGT Auth servername CST := E(Server Key, {username, date, Client-Server Key}) CST E(Client-TGS Key, Client-Server Key) Client Server Auth := E(Client-Server Key, {username, date}) CST Auth Figure 1 Réponse à la question 9
Question 12: Indiquez quelles vérifications le TGS doit effectuer pour vérifier l identité du client. Le TGS peut «ouvrir» le Ticket-Granting Ticket, puisqu il possède, lui, la AS-TGS Key. Il peut donc trouver dedans mon nom d utilisateur, la date, et la une clef de session fraiche (la Client-TGS Key) à utiliser avec moi. Grace à la Client-TGS Key, il peut déchiffrer l authentificateur. Il doit vérifier que les noms d utilisateurs et les dates correspondent entre d un côté le Ticket, et de l autre côté l authentificateur. Ceci garantit que l utilisateur connait bien la Client-TGS Key (sinon il n aurait pas pu former l authentificateur), donc qu il a bien été authentifié par l AS. Question 13: Indiquez ce que le serveur doit faire pour vérifier l identité du client et obtenir la clef de session qui leur servira à communiquer. C est essentiellement la même chose. Le serveur peut déchiffrer le Client-Server Ticket, donc obtenir ainsi le nom de l utilisateur qui essaye d entrer en relation avec lui, ainsi que la clef de session fraiche (=la Client-Server Key) à utiliser avec lui. Il peut donc déchiffrer l authentificateur, et vérifier la correspondance avec son ticket. Cela lui garantit que l utilisateur connait bien la Client-Server Key, donc qu il a été approuvé par le TGS. Question 14: Que va-t-il se passer si j envoie un autre nom que le mien lors de la première étape? Qu est-ce qui va m empêcher de me faire passer pour cette personne? En fait, on peut toujours envoyer n importe quel identité à l AS. Le problème, c est qu on ne pourra pas faire grand chose de la réponse. On obtient certes un Ticket-Granting Ticket valide, mais on ne pourra pas produire les authentificateurs qui vont avec, car on va pas pouvoir mettre la main sur la Client-TGS Key qui correspond (qui est stockée dans le TGT). En effet, l AS va nous la renvoyer chiffrée avec un mot de passe que l on ne connait pas. Question 15: Imaginons que je parvienne à voler la AS-TGS Key. Qu est-ce que cela me permet? On devient le roi du pétrole. Ceci permet de forger des Ticket-Granting Ticket à la place de l AS. On peut donc se faire passer pour n importe qui. Pour se faire passer pour «toto», il suffit de générer une Client-TGS Key de manière aléatoire, de fabriquer un Ticket-Granting Ticket contenant cette clef et «toto», puis de continuer le protocole normalement avec le TGS (en indiquant bien sûr «toto» dans les authenticateurs). Question 16: Les «clefs secrètes» qui identifient les utilisateurs sont en fait des mots de passe assez faibles. Un h4x0r parvient à espionner le traffic réseau d un utilisateur qui effectue le protocole. Peut-il monter une attaque par dictionnaire, «hors-ligne», pour récupérer son mot de passe? Si oui comment? Si non pourquoi? L attaque par dictionnaire est possible, mais elle n est pas complètement immédiate. L espion se concentre sur deux données : 1. La Client-TGS Key, que l AS envoie au client chiffrée avec le mot de passe du client. 2. L authenticateur que le client envoie au TGS, chiffré avec la Client-TGS Key. Pour chaque mot de passe possible : Déchiffrer la Client-TGS Key avec ce mot de passe (on ne sait pas encore si elle est correcte) Déchiffrer l authenticateur avec cette Client-TGS Key potentielle. Si le résultat est raisonnable (au bon format, contient le bon username, la bonne date,...), alors on a sûrement trouvé le bon mot de passe.
Client 0 K 0 Client 1 K 1 AS K 2 Client 2 AS-TGS Key Server 0 K 0 TGS K 1 Server 1 K 2 Server 2 Figure 2 Schema récapitulatif les arêtes indiquent le partagent d un secret.