MÉMOIRE présenté en vue d'obtenir LE DIPLÔME D'INGÉNIEUR I.I.E. Rapport Final. Cyril LANQUETUIT

Transcription

1 MÉMOIRE présenté en vue d'obtenir LE DIPLÔME D'INGÉNIEUR I.I.E. Rapport Final Étude et développement d'un driver logiciel au sein d'une infrastructure sécurisée Cyril LANQUETUIT Directeur de stage: M. Thomas PORNIN, Directeur Technique stage effectué à CRYPTOLOG 1

2 Sommaire I Remerciements...3 II Résumé...4 III Introduction Le domaine du stage 2 Le stage IV Contexte du stage Présentation de l'entreprise: Cryptolog International 2 L'environnement de travail V État de l'art Définition, historique 2 Chiffrements symétrique et asymétrique 3 Utilité de la cryptographie à clé publique 4 Qu'est ce qu'une PKI 5 Le protocole PST 6 Le positionnement de Cryptolog VI Objectifs du stage Le logiciel, Unicity Remote 2 Les différentes étapes VII Travail effectué Compréhension des objectifs des différentes étapes 2 Le protocole d'identification 3 Différentes versions du client et du serveur de test 4 Serveur ncryptone avec base de données configurée grâce à l'outil Thor 5 Mutualisation du code pour ncryptone et Vasco 6 Client et serveur Vasco 7 Client et serveur Xiring 8 Design du plugin : programmation Windows 9 Déploiement du logiciel VIII Conclusion...28 IX Glossaire...29 X Bibliographie

3 XI Annexes

4 I Remerciements Je remercie Alexandre et Julien Stern pour m'avoir fait confiance et m'avoir permis tout au long de ce stage de contribuer au développement d'unicity Remote, l'un des produits phares de Cryptolog et une solution d'authentification forte à l'avenir prometteur. Je remercie Thomas Pornin, mon maître de stage qui s'est appliqué à partager une partie de son savoir en m'éclairant sur de nombreux points, que ce soit sur des notions théoriques ou des détails pratiques ainsi que d'avoir orienté judicieusement les choix tant conceptuels que techniques qui se sont avérés nécessaires et ont assurés le bon déroulement de ce stage. Je suis également très reconnaissant envers l'ensemble des membres de l'équipe Cryptolog qui m'ont si chaleureusement accueilli, expliqué le fonctionnement des outils et des méthodes de travail internes à l'entreprise et qui durant ces 5 mois de stage m'ont fait partager leurs connaissances et leur expérience à travers leur conseils pertinents et leurs réponses à mes questions, ceci toujours avec bonne humeur. Enfin, je remercie toutes les personnes qui m'ont permis d'acquérir les compétences nécessaires à réaliser dans d'excellentes conditions ce stage de fin d'études d'ingénieur dans un domaine de l'informatique étroitement lié aux mathématiques théoriques. 4

5 II Résumé Les origines de l'art de la cryptographie remontent à l'antiquité mais l'essor de ses applications pratiques ne date que des années 70. C'est avec la découverte du chiffrement asymétrique et l'ère du numérique ainsi que le développement des moyens de communication comme Internet que la cryptologie devient une science omniprésente dans la vie quotidienne. Les applications industrielles de la cryptographie consistent essentiellement à assurer la confidentialité et la confiance quant à l'origine des données numériques échangées. L'idée principale est de contrôler l'accès au contenu (le destinataire) ou la provenance (authentifier l'identité de l'expéditeur) des messages échangés et ainsi accorder des droits d'accès appropriés uniquement aux personnes concernées par le contenu des messages. Chiffrer, déchiffrer avec une clé secrète ou publique, signer (avec une clé secrète) ou vérifier une signature (avec une clé publique) sont les opérations élémentaires nécessaires aux applications de la cryptographie. Le principe d'une signature électronique est le même que celui d'une signature manuscrite, un document éléctronique étant facilement modifiable et recopiable, la signature électronique composé d'une clé privée connue de l'auteur seul et qui permet de produire la partie publique qui permet de faire le lien entre le document signé et l'auteur. Pour assurer la correspondance entre la l'identité du détenteur de la clé privée et la partie publique, il est nécessaire que la signature soit certifiée par une autorité de certification. C'est également le cas lorsqu'on dépose sa signature en mairie lors de la fabrication d'une carte d'identité. Le chiffrement des messages grâce à des algorithmes utilisant des clés permet aux différentes entités (par exemple un établissement bancaire et ses clients) d' échanger des informations en s'assurant de leur intégrité, leur confidentialité et leur origine. Le stage s'intègre dans la partie du domaine de la sécurité informatique qui concerne ces échanges sécurisés d'informations. Les cartes à puces sont aujourd'hui un moyen de sécuriser les échanges électroniques, elles permettent le stockage de manière sûre de clés secrètes nécessaires aux opérations cryptographiques comme l'authentification et le chiffrement utilisées pour accéder par exemple à un compte bancaire ou effectuer une transaction électronique. Dans les entreprises des cartes à puces sont utilisées de la même manière et servent aussi à identifier leur porteur. Cryptolog développe des solutions logicielles permettant de remplacer les cartes physiques par des ExaCards, des cartes à puces virtuelles : les clés secrètes nécessaires aux opérations cryptographiques sont stockées sur un serveur distant et accessibles par les postes clients en utilisant un login et un mot de passe. Ces logiciels ne peuvent être mis en place qu'au sein d'une infrastructure de gestion des clés (PKI pour Public Key Infrastructure). L'un des produits phares de Cryptolog est Unicity Remote, il permet la gestion des identités numériques et repose sur le principe simple de ne jamais laisser une machine cliente avoir accès aux clés secrètes, mais de lui permettre de se connecter à un serveur Remote conservant les clés et capable d'effectuer des opérations cryptographiques fortes, telle que signature et déchiffrement, à sa place. Les utilisateurs doivent s'authentifier auprès du serveur en utilisant un login et un OTP (One Time Password) plus sûr qu'un simple mot de passe puisqu'utilisable une seul fois. L'OTP est fourni à chaque utilisation au client par un dispositif personnel similaire à une calculette qui le génère à 5

6 partir d'une clé secrète et d'un compteur d'utilisation. Le principe de la carte à puce virtuelle (stocker les clés secrètes sur le serveur distant) garantit une meilleure sécurité en cas de compromission des machines clientes. En exploitant ce concept au maximum en permettant aux utilisateurs d'effectuer des opérations cryptographiques sans accéder directement aux clés mais en utilisant des OTP, Unicity Remote assure une sécurité maximale des échanges électroniques. Le stage qui s'est déroulé du 1er Février au 30 Juin dans les locaux de Cryptolog s'insère dans le développement du produit Unicity Remote. Il a consisté à l'étude et développement d'un driver logiciel au sein d'une infrastructure sécurisée : il a été nécessaire d'étudier et de réaliser un prototype de protocole permettant les communications sécurisées entre un plugin client et un serveur d'authentification distant conservant des éléments de cryptographie forts. L'authentification du client est faite en utilisant un login et un OTP. Le serveur peut authentifier des clients utilisant les dispositifs matériel légers générant les OTP des différents constructeurs (ncryptone, Vasco ou Xiring). Par la suite le prototype dû être amélioré afin de permettre des échanges sécurisés entre client et serveur en utilisant les produits Cryptolog, notamment Unicity Remote. 6

7 III Introduction 1 Le domaine du stage Les parties IV et V du présent document permettent de resituer le stage tant dans son environnement pratique que dans son cadre théorique. Les parties VI et VII sont entièrement consacrées au stage proprement dit ; elles exposent les objectifs visés et le travail réalisé. La partie VIII conclut sur les aboutissements du stage et est suivie d'un glossaire, d'une bibliographie et de quelques annexes permettant une meilleure compréhension et un possible appronfondissement des notions utilisées dans les parties précédentes. La partie IV est consacrée au contexte du stage, elle présente l'entreprise dans lequel se déroule le stage et le rôles des différents acteurs ainsi que les technologies utilisées au cours du développement des parties logicielles et les solutions techniques adoptées. La partie V présente l'état de l'art du cadre théorique dans lequel s'inscrit le stage en essayant de donner un aperçu plus général de la cryptologie et de ses applications numériques. On y attachera une importance particulière au rôle joué par Cryptolog dans le domaine de la sécurité informatique et plus spécialement sur le concept de cartes à puce virtuelles utilisées dans les produits comme Unicity Remote. 2 Le stage La partie VI expose d'une part plus en détail le produit Unicity Remote dans le développement duquel s'inscrit ce stage, et d'autre part les différents objectifs à atteindre au cours de l'analyse et du développement. La partie VII entre dans le vif du sujet et explique le travail effectué : conception et développement des parties client et serveur d'authentification pour les différents dispositifs générateur d'otp des trois sociétés ncryptone, Vasco et Xiring. Après la conclusion, glossaire, bibliographie et annexes viennent enrichir et fournir des compléments d'information sur les notions développées précédemment. 7

8 IV Contexte du stage 1 Présentation de l'entreprise: Cryptolog International Cryptolog est une société d'ingénierie et de conseil fondée en 2001 par : Alexandre Stern Président : Diplomé d'hec, de la Leonard N. Stern School of Business, New York University et de l'université Paris Dauphine, Alexandre a occupé le poste d'assistant directeur de la stratégie du groupe Communications & Systems avant de créer Cryptolog. Julien P. Stern Directeur R&D : Julien possède un doctorat de cryptographie obtenu à l'ens Lyon. Il a travaillé dans les laboratoires de cryptographie de grandes entreprises (IBM, AT&T, Intertrust, Lucent Technologies) avant de créer Cryptolog. Thomas Pornin Directeur Technologique : Thomas possède un doctorat de cryptographie obtenu à l'ens Paris. Il a travaillé dans la recherche fondamentale sur la cryptographie et à écrit plusieurs articles scientifiques sur le sujet avant de créer Cryptolog. L'équipe de Cryptolog est composée de 4 développeurs: Antoine Buxerolles Yves Duhem Sebastien Hénaff Jean-Christophe Sirot et d'un commercial: Barthélémy Delaveau Elle est spécialisée dans le domaine de la cryptographie et ses applications: sécurité des données, signatures numériques, gestion des droits numériques et infrastructures à clés publiques qui constituent le lien nécessaire entre la recherche fondamentale et l'industrie. Cryptolog a déjà développé plusieurs solutions logicielles pour sécuriser les échanges électroniques dont Unicity, Eternity, Identity, WebPass, CUTE et OCSP Responder ; les fiches techniques de ces produits sont disponibles sur le site web Cryptolog International SAS rue Vulpian F Paris France Tel: Fax: cryptolog@cryptolog.com 8

9 2 L'environnement de travail L'équipe de développement de Cryptolog utilise des machines sous Debian-Linux, les éditeurs privilégiés sont ainsi VI ou Emacs qui en plus de leur souplesse d'utilisation et leur légèreté au niveau des ressources demandées, offrent un contrôle total sur le code produit. L'ensemble du développement au cours du stage à été réalisé en C pour la partie cliente car celle-ci doit pouvoir interagir avec la cryptoapi Windows et en java pour la partie serveur. Les différentes versions des fichiers écrits sont stockés sur un serveur CVS. Plusieurs autres outils comme CGSSL, Maven, Yggdrazil ou Thor sont utilisés pour faciliter et améliorer le développement. L'outil CGSSL est utilisé pour réaliser des tests; il permet des opérations de création de clés, de certificats, de clients et de serveurs communiquant de manière sécurisée du même type que celle proposée par Openssl mais en étant plus spécifiques aux applications de Cryptolog. Maven est un outil logiciel de compréhension et de management de projet. Basé sur un modèle objet de projet (POM), Maven est capable de gérer la construction, les rapports et la documentation d'un projet à partir des seuls fichiers sources java. L'outil Yggdrasil développé en interne par Cryptolog et son interface graphique Thor permettent d'assembler les divers composants indépendants (classes java) constituant un serveur. Cette conception modulaire facilite grandement le développement des serveurs spécifiques dont les clients ont besoin et permet de réutiliser efficacement les briques logicielles déjà existantes. Yggdrasil permet également d'utiliser un unique fichier de configuration pour une architecture complexe composée de plusieurs serveurs. L'encadrement principal du stage sera assuré par Thomas Pornin. À son orientation des travaux à réaliser s'ajouteront les conseils des membres de l'équipe R&D de Cryptolog. 9

10 V Etat de l'art 1 Définition, historique La cryptologie, étymologiquement la science du secret, regroupe la cryptographie -l'écriture secrèteet la cryptanalyse -l'analyse des méthodes permettant de la décrypter ("de casser les codes"). Art très ancien datant de l'antiquité, jusque dans les années 70 la cryptologie repose essentiellement sur le chiffrement symétrique. Utilisé déjà par Jules César, ce type de chiffrement permet de chiffrer un message et de le déchiffrer en utilisant le même algorithme ; le procédé repose en général sur un secret connu uniquement de l'émetteur et du destinataire du message. La faiblesse de cette technique réside dans la phase de communication du secret : lors de sa mise en commun, celui-ci risque d'être intercepté par un ennemi. Il faut attendre 1976 et l'apparition du chiffrement asymétrique présenté pour la première fois à la National Computer Conference par Whitfield Diffie et Martin Hellman pour que la cryptologie soit véritablement élevée au rang de science. Le premier exemple de chiffrement asymétrique est inventé en 1978: le RSA, abréviation tirée des trois noms de ses auteurs (Ronald Rivest, Adi Samir et Leonard Adelman). 2 Chiffrements symétrique et asymétrique En cryptographie, on distingue donc le chiffrement symétrique où l'algorithme qui décode le message utilise la même clé que pour le coder et le chiffrement asymétrique où l'une des clés est secrète et l'autre publique. Le chiffrement symétrique ou à clé secrète est utilisé depuis l'antiquité pour transmettre des messages, entre un expéditeur et un destinataire partageant un même secret, sans que le contenu de ceux ci puisse être lu par une tierce personne éventuellement mal intentionnée. Un exemple très simple et très ancien est le code de César: il consiste à remplacer chaque lettre d'un texte par la lettre situé k places plus loin dans l'alphabet. On appelle k la clé de la méthode de chiffrement. Pour déchiffrer un message, il suffit de réaliser le décalage de k lettres dans le sens opposé. Le code de César, très simpliste est facile à décrypter (ie "à casser") puisqu'il n'y a que 26 clés possibles. De manière plus générale, on appelle méthode de chiffrement symétrique tout algorithme permettant à l'aide d'une clé secrète, de transformer un texte en un code que l'on peut déchiffrer en utilisant la même clé. DES, blowfish, 3DES, AES, RC2, RC4 sont les méthodes de chiffrement les plus connues. Ce système semblait être le seul possible jusqu'à la fin du XXème siècle et la découverte du principe de chiffrement asymétrique par Whitfield Diffie et Martin Hellman. 10

11 Très pratiques, ces méthodes de chiffrement sont utilisées particulièrement en temps de guerre notamment lors de la première guerre mondiale où le développement des communications radio rendit nécessaire le chiffrement des messages échangés pour qu'ils ne tombent pas aux mains de l'ennemi. Pour la première fois, les armées disposent de moyens mécaniques qui permettent de concevoir des systèmes cryptographiques comme Enigma, autrement plus compliqués que ceux que l'on pratique "à la main". Mais les analyses vont aussi s'automatiser, jusqu'à la naissance du premier ordinateur. L'un des problèmes de ce type de système est le nombre de clés : si N personnes désirent communiquer entre elles deux à deux de manière secrète, il faudra une clé par couple, soit N * (N-1)/2 clés. Mais bien plus ennuyeux, le problème majeur du chiffrement symétrique reste la vulnérabilité lors de l'échange de la clé : avant d'échanger des messages chiffrés, deux interlocuteurs doivent partager l'algorithme et la clé secrète permettant de chiffrer et déchiffrer, un ennemi interceptant cette première communication sera donc en mesure de lire et d'écrire des messages librement. Cette faiblesse oblige souvent les personnes souhaitant communiquer à se rencontrer physiquement pour se mettre d'accord sur la clé secrète et la méthode de chiffrement à utiliser. En 1976, naît la cryptographie moderne avec la présentation du concept de chiffrement asymétrique, aussi appelé "à clé publique", par Whitfield Diffie et Martin Hellman à la National Computer Conference. Le premier exemple de système de chiffrement à clé publique est RSA, du nom de ses créateurs Rivest, Samir et Adelman en Contrairement au chiffrement symétrique, le chiffrement asymétrique nécessite deux clés différentes: une publique pour chiffrer, une secrète pour déchiffrer. Les clés sont liées entre elles mathématiquement mais on ne peut pas calculer la clé privée à partir de la clé publique. Dans la pratique les personnes qui souhaitent recevoir des messages confidentiels choisissent une clé privée et créent la clé publique correspondante qu'ils publient (associée à une méthode de chiffrement) dans des annuaires électroniques. Ces clés publiques sont utilisées par les personnes désirant chiffrer un message, le rendant ainsi illisible sauf par le possesseur de la clé privée. Malgré la découverte d'autres méthodes de chiffrement asymétrique comme NTRU, El Gamal ou Rabin-Williams, le RSA reste le plus utilisé. Comme les méthodes de chiffrement symétriques sont moins coûteuses en calcul que les méthodes asymétriques, on utilise généralement ces dernières pour convenir d'une la clé secrète et d'une méthode de chiffrement symétrique que l'on utilisera pour échanger les messages suivant, palliant ainsi la faiblesse des méthodes à clé secrète. 11

12 3 Utilité de la cryptographie à clé publique La naissance de la cryptographie asymétrique a permis l'essor des échanges d'informations de manière sécurisée : qu'entend-t-on par sécurisée? Si Alice et Bob souhaitent communiquer secrètement, Alice choisit une clé secrète KS, envoie en clair à Bob la clé publique KP correspondante et le nom de la méthode de chiffrement asymétrique associée, celui-ci ci choisit alors une clé secrète K et une méthode de chiffrement symétrique et les envoie à Alice dans un message chiffré avec KP. Cette dernière le déchiffrera grâce à sa clé privé KS. Bob et Alice pourront ensuite s'envoyer à loisir des messages chiffrés avec la clé K, également déchiffrables avec cette même clé connue d'eux seuls. La cryptographie à clé publique sécurise donc l'échange des messages en assurant leur confidentialité (seul le destinataire d'un message peut le lire) et leur authentification (seul le possesseur de la clé KS a pu déchiffrer le message contenant la clé K et a pu écrire un message ultérieurement déchiffré grâce à elle). L'authentification est l'autre application majeure de la cryptographie asymétrique. Pour assurer être l'auteur d'un document manuscrit, on signe celui-ci. Pour signer un document électronique, on ne peut pas se contenter d'y ajouter son nom ou un code, celui-ci serait trop facilement recopiable par une personne mal intentionnée. Il faut donc être capable de réaliser une signature qui pourra être vérifiée par le destinataire du document sans que celui-ci puisse la reproduire. Cet exemple illustre la dissymétrie du problème de l'authentification. La cryptographie asymétrique permet de prouver être l'auteur d'un message sans divulguer les connaissances (la clé secrète) permettant de réaliser la signature. Pour réaliser une signature électronique de type RSA, on utilise une fonction de hachage, c'est un algorithme qui permet à partir d'un document numérique, de ne conserver que certains bits qui constituent ainsi un «résumé» du document aussi appelé haché. Envoyer un document avec son haché chiffré à l'aide d'une clé privée permet d'en assurer l'intégrité et la provenance, cela s'appelle signer un document. Une signature sera "reconnue" en comparant le haché déchiffré à l'aide de la clé publique correspondante à la clé privée utilisée pour signer avec le haché obtenu à partir du document en utilisant la fonction de hachage, elle aussi publique. Illustration du principe de la signature électronique ajoutée au chiffrement 12

13 Les cartes bancaires et les certificats électroniques comptent parmi les applications principales de la cryptographie moderne utilisant la signature électronique. Pour être mis en place, de tels systèmes cryptographiques nécessitent d'être intégrés à une PKI. 4 Qu'est ce qu'une PKI? Une PKI (Public Key Infrastructure) est l'ensemble des moyens humains, techniques, documentaires et contractuels mis à la disposition des utilisateurs pour assurer un environnement sécurisé pour les échanges électroniques. Cet environnement est basé sur des systèmes de cryptographie asymétriques et notamment la notion de certificat. Le problème d'une signature est que pour être «lue», on doit utiliser une clé publique correspondant à la clé privé de l'entité ayant signé. Les clés publiques peuvent être publiées dans des annuaires mais rien n'empêcherait une personne mal intentionnée de publier une clé publique en se faisant passer pour Microsoft par exemple. C'est là qu'interviennent les certificats : des autorités de certification comme VeriSign reconnues internationalement et notamment par les navigateurs web, possèdent des clés secrètes, les clés publiques correspondantes sont connues et intégrée dans le système d'exploitation ou dans le navigateur. Ces autorités peuvent certifier l'identité d'autres entités : elles créent des documents où figurent entre autres leur nom, le nom de l'entité certifiée, la clé publique qui lui est associée et les signent à l'aide de leur clé privée : ce sont des certificats. Toute personne connaissant la clé publique correspondant à l'entité de certification peut alors vérifier la signature de l'autorité émettrice du certificat et ainsi être sûr que la clé publique y figurant correspond bien à l'entité dont il est question dans le certificat. Les politiques de certification ainsi que le formats des certificats (comme X.509) sont décrits dans les RFC notamment la RFC3280. Les RFC (Request For Comment) sont des documents publiés par l'ietf (International Engineering Task Force) une communauté internationale qui travaille sur l'évolution de l'architecture d'internet ; les plus abouties des RFC sont destinées à devenir des standards d'internet. 5 Le protocole PST Le protocole PST (Packet Secure Transport) a été développé de manière interne à Cryptolog. Comme tout protocole de transport de paquets, le protocole PST permet l'échange de paquets de données binaires entre un client et un serveur qui répond aux requêtes du premier. Il permet d'effectuer la vérification d'intégrité et l'authentification mutuelle. Deux échanges successifs ne sont ni forcément liés entre eux ni obligatoirement effectués par le même client. Requêtes et réponses contiennent divers champs dont certains sont optionnels et elles sont encodées en ASN.1. Client et serveur doivent donc être capables d'encoder et de décoder des structures ASN.1 dans le format DER. Le protocole PST utilise des algorithmes de chiffrement comme AES-128, RC4, HMAC/SHA-1, RSA ou DSS et se sert également de la notion de session. Alors que les protocoles de type SSL (Secure Socket Layer) nécessitent un "tuyau biauthentifié" reposant sur un protocole TCP, le PST peut être encapsulé dans des requêtes HTTP et ainsi passer certains serveur proxy d'entreprises qui empêchent d'utiliser un protocole SSL ou ne supportent pas le HTTPS. Le PST permet également de limiter les échanges entre client et serveur pendant la phase d'authentification, un seul suffit tandis qu'il en faut au minimum deux pour le protocole SSL. Une autre particularité du PST est que tous les échanges de données sont faits à l'initiative du client : le serveur se contente de répondre aux requêtes du client et ne demande jamais rien de lui même 13

14 comme il peut le faire dans le cas du SSL. C'est la raison pour laquelle le PST est encapsulable dans du HTTP. demande d'authentification Client certificat + clé publique requête + clé de session chiffrés avec la clé publique réponse + sessionid chiffrés avec la clé de session Serveur Le protocole PST est donc caractérisé par une possible encapsulation dans des requêtes HTTP, des communications toujours initialisées par le client, la longueur des paquets de données est arbitraire, chaque requête est indépendante et permet toujours la réception d'une réponse. Ce protocole assure la confidentialité (seuls client et serveur ont accès aux données en clair), l'intégrité (toute altération des données échangées est détectée), et l'authenticité (le serveur est authentifié par le client et peut demander à authentifier le client). 6 Le positionnement de Cryptolog Cryptolog propose des solutions aux entreprises ou établissements bancaires souhaitant pouvoir échanger des informations de manière sécurisée avec leurs clients. En permettant l'authentification, la signature, la confidentialité et la non répudiation (éviter qu'une personne nie avoir envoyé un message) des échanges, les produits de Cryptolog constituent des solutions essentiellement logicielles ainsi plus souples, moins lourdes à mettre en place et plus sûres que des solutions matérielles comme des lecteurs de cartes à puces. Cryptolog a déjà développé plusieurs solutions logicielles pour gérer les identités numériques et sécuriser les échanges électroniques dont Unicity, Eternity, Identity, WebPass, CUTE et OCSP Responder. Les principales fonctionnalités proposées par ces produits sont l'authentification forte, la signature électronique, la dématérialisation et l'échange de mails sécurisés. Unicity Local, mais aussi et surtout Unicity Remote (produit dans le développement duquel s'inscrit ce stage) est un des produits phares de Cryptolog, c'est une solution entièrement logicielle qui permet la dématérialisation des identités numériques. Concrètement ce produit offre les mêmes avantages qu'un système de gestion des identités basé sur des cartes à puce mais en remplaçant ces dernières par des Exacards, faisant abstraction de support physique en réalisant le stockage des clés sur un serveur distant accessible grâce à un login et un OTP. 14

15 VI Objectifs du stage 1 Le logiciel, Unicity Remote Ce stage s'insère dans le domaine de la sécurité informatique et plus particulièrement dans le cadre d'applications industrielles de la cryptographie utilisant des protocoles d'échanges de données sécurisées de type SSL. La bibliothèque CGSSL implémente dans le langage C, des fonctionnalités cryptographiques permettant des opérations de signature, de chiffrement et d'authentification du même type que celles proposées par Openssl mais spécifiques à Cryptolog et à ses produits. Des entreprises comme des établissements bancaires désirent entretenir avec leurs clients des communications sécurisés (envoi de mail, opérations bancaires,...). Pour leur permettre d'effectuer ces communications de manière sûre, Cryptolog propose un système de carte à puce virtuelle : Cryptolog Unicity. Au lieu de conserver les clés secrètes nécessaires pour réaliser les opérations de cryptographie et qui constituent l'élément sensible du système sur des cartes à puces qui peuvent êtres volées et représentent un coût non négligeable de fabrication et de distribution ou sur les disques durs des postes clients qui peuvent facilement subir une attaque, les clés sont conservées sur un serveur distant et accessibles au client après s'être authentifié. 15

16 Cryptolog Unicity Local permet de conserver sur un serveur les clés secrètes nécessaire au calcul d'une signature, ou au déchiffrement, lors de la réception d'un message ayant été chiffré à l'aide de la clé publique correspondante. La clé secrète est téléchargée temporairement sur la machine cliente après que l'utilisateur se soit identifié par mot de passe via Unicity plug-in, WebPass ou CUTE (en utilisant des ExaCards Cryptolog). Cryptolog Unicity Remote permet de conserver les clés secrètes sur un serveur mais à la différence de Unicity Local, celles-ci ne sont jamais présentes sur la machine cliente : l'utilisateur s'identifie comme précédemment en utilisant un mot de passe de type OTP mais toutes les opérations cryptographiques sont réalisées du coté du serveur. 16

17 2 Les différentes étapes L'objectif du stage est d'aider à poursuivre les travaux en cours sur Unicity Remote. Le stage consiste à permettre d'intégrer les solutions d'authentification de ncryptone, Vasco et Xiring au plugin Unicity Remote de Cryptolog. Ces trois sociétés Leader sur le marché de l'authentification forte proposent en effet chacune une gamme de dispositifs matériels permettant de générer des OTP qui sont utilisés pour s'authentifier auprès d'un serveur d'authentification qui transmettra le cas échéant les requêtes de signature de documents ou de déchiffrement de mail à un remote serveur qui conserve les clés secrètes. Il a donc été nécessaire de réaliser un client adapté pour chaque type de générateur d'otp et un serveur pour chaque type d'authentification correspondante. En effet, les différent générateurs d'otp des 3 sociétés cités ci-dessus n'utilisent ni les mêmes données ni les mêmes algorithmes pour calculer les OTP, le serveur d'authentification doit donc être adapté pour pouvoir d'une part stocker les données de chaque utilisateurs et d'autre part implémenter des fonctionnalités cryptographiques nécessaires pour pouvoir calculer les OTP à partir de ses données et les comparer aux OTP transmis par l'utilisateur. Voici ci-dessous, résumées succinctement les principales étapes structurant le travail réalisé durant le stage. a) Pour ncryptone -Réalisation d'un client et d'un serveur de test -Test encodage et décodage des requêtes ASN en mode console -Lecture des RFC 4226 et 2104 pour comprendre le fonctionnement de l'algorithme HMAC -Écriture d'un client ncryptone (incorporation au fichier rtlow.c) -Écriture d'une première version du serveur d'authentification ncryptone par Thomas Pornin -Création des bases de données contenant les utilisateurs de test -Test signature et déchiffrement b) Pour Vasco -Lecture de la documentation du Vacman Controller -Réflexion pour permettre d'utiliser un format de requête commun à ncryptone et Vasco -Modification de la spécification ncryptone.asn en protocole.asn, restant compatible avec le client et serveur ncryptone écrits précédemment -Spécification d'un protocole d'authentification commun à ncryptone et Vasco -Écriture d'interfaces java génériques (adaptées aussi bien à ncryptone qu'à Vasco) pour le serveur d'authentification -Réécriture des classes java pour le serveur d'authentification ncryptone -Création des bases de données contenant les utilisateurs de test -Test -Utilisation de la bibliothèque de fonction C du Vacman Controleur par l'intermédiaire d'un wrapper java pour réaliser l'authentification avec les dispositifs de Vasco (Digipass) -Tests -Écriture du client pour Vasco -Écriture des classes java pour le serveur d'authentification Vasco -Test, modifications, tests c) Pour Xiring -Lecture de la documentation 17

18 -Contact technique avec B.Choiset chez Xiring, abandon pour l'instant de la solution d'authentification utilisant le lecteur Xi-Sign Santé et les cartes CPS et Vitales (spécifications en cours de réaménagement) -Étude et développement de l'intégration de la solution d'authentification utilisant le lecteur Xi-Sign EMV et les cartes à puces Visa et MasterCard -Inplémentation de l'algorithme nécessaire au calcul d'un OTP, ou d'une réponse à un challenge à partir des données correspondant à un utilisateur. -Création des bases de données contenant les utilisateurs de test -Écriture des classes java pour le serveur d'authentification Xiring implémentant les interfaces génériques déjà définies pour les serveur Ncryptone et Vasco -Réutilisation du même code que pour Vasco pour le client -Test d'authentification par OTP ou par réponse à un challenge d) Design du plugin -Volonté de présenter à l'utilisateur un plugin plus «joli», voir peut-être personnalisable -Utilisation du travail de Jean-Christophe Sirot pour réaliser un prototype de plugin ayant l'aspect d'une carte à puce aux couleur de Cryptolog et aux bords arrondis sur laquelle l'utilisateur saisit son login et mot de passe dynamique à l'emplacement ou figure habituellement le nom et le numéro du propriétaire de la carte à puce. Dans un premier temps, le travail fut axé sur la réalisation d'un prototype de protocole de communication entre le plugin de Cryptolog et des serveurs d'authentification avant d'envisager des améliorations de ce prototype pour en réaliser une version plus adaptée à son utilisation finale et à son incorporation avec les produits Cryptolog déjà existants. 18

19 VII Travail effectué 1 Compréhension des objectifs des différentes étapes a) Communication client serveur Après la lecture de l'abondante documentation nécessaire à la prise de contact avec le sujet, la première étape du stage fut la compréhension des opérations réalisées par le code des fichiers rtclient.c et rtlow.c. Ces deux fichiers sont utilisés par le plugin Cryptolog, ils contiennent les fonctions qui effectuent les requêtes et reçoivent les réponses lorsqu'un client échange des informations avec un serveur Unicity. b) Le principe du One Time Password Pour s'authentifier auprès d'un serveur Unicity Remote et ainsi avoir accès aux opérations cryptographiques, une machine cliente doit s'authentifier. L'authentification d'un client auprès d'un serveur utilise généralement un mot de passe associé à un login d'utilisateur, néanmoins, un mot de passe peut d'une manière ou d'une autre tomber entre de mauvaises mains et constitue donc une faiblesse dans le dispositif sécurisé, aussi lui préfère-t-on généralement des techniques d'authentification plus sûres utilisant par exemple un Challenge-Response ou un OTP (One Time Password). Ces deux techniques reposent sur une clé secrète connue du serveur et stockée dans un boitier de type calculette en possession du client et d'une donnée changeant à chaque authentification. Dans le premier cas la donnée variable est générée par le serveur et envoyée au client qui l'entre manuellement sur sa calculette lui donnant la réponse (résultat d'un calcul utilisant la clé secrète) permettant de s'authentifier. Dans le cas de l'otp, la donnée variable est un compteur partagé par le client et le serveur, initialisé à 0 des deux côtés et incrémenté à chaque utilisation d'un OTP pour réaliser une authentification. Les RFC 2104 et 4226 décrivent respectivement HMAC (Hashed Message Authentication Code) et un algorithme permettant de générer des OTP (One Time Password) à partir de HMAC. C'est cet algorithme qui sera utilisé pour calculer les OTP pour s'authentifier auprès du serveur ncryptone (intermédiaire entre le client et le serveur Unicity Remote). Pour un texte T donné, on peut calculer la valeur HMAC à partir d'une clé secrète K et d'une fonction de hachage H. En notant B le nombre d'octets utilisés pour la clé, on a HMAC(K,T) = H(K Xor opad, H(K Xor ipad, T)) où ipad est l'octet 0x36 répété B fois et opad est l'octet 0x5C répété B fois. L'algorithme décrit dans la RFC 4226 permettant d'obtenir la valeur HOTP de D chiffres, c'est-àdire un One Time Password en utilisant le HMAC d'un compteur C calculé à partir d'une clé secrète K et de la fonction de hachage SHA-1, est le suivant: HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) Le texte à hacher est ici le compteur C, partagé par le client et le serveur, initialisé à 0 des deux côtés et incrémenté à chaque utilisation d'un OTP pour réaliser une authentification. Si la désynchronisation entre le compteur du client et celui du serveur dépasse N, le compte de 19

20 l'utilisateur est bloqué (pour le protocole du Vacman Controler N = 1000). On calcule d'abord : HMAC-SHA-1(K,C) = SHA-1(K Xor opad, SHA-1(K Xor ipad, C)) puis on réalise la troncature de la valeur de 160 bits ainsi obtenue: la valeur des 4 derniers bits donne la valeur d'un décalage d entre 0 et 15, on prend pour HOTP(K,C) la valeur des 4 octets à partir du d ième du code de 20 octets HMAC- SHA1(tK,C), modulo 10^D. c) Le protocole utilisant le PST Le protocole de communication entre client et serveur qui viendra s'intégrer au PST (protocole utilisé par Cryptolog qui constitue une couche supplémentaire au protocole HTTP et simplifie les échanges entre client et serveur par rapport à un protocole SSL) est en partie défini par la structure des requêtes du client et des réponses du serveur spécifié par le fichier protocole.asn. En ASN, les types de base sont des INTEGER, des OCTET STRING, des CHOICE, des SEQUENCE, la spécification ASN du protocole (protocole.asn) définit aussi une SessionID utilisée pour éviter au client de retaper login et OTP ainsi qu'un Status qui n'est autre que le code de retour du serveur, valant 0 si la réponse à la requête s'est bien déroulée. Il a donc été nécessaire de se familiariser avec la syntaxe ASN.1 et maîtriser l'utilisation des fonctions encode_der et decode_der pour écrire ou lire des données au format ASN.1. Il a également été utile de réaliser un serveur de test PST, assurant la réception d'une requête du client au format spécifié, son décodage, la saisie manuelle d'un Status pour la réponse et l'encodage en DER de cette dernière avant de la retourner au client. 20

21 2 Le protocole d'identification Le schéma ci dessous décrit le protocole d'authentification par OTP. Pour ncryptone le fonctionnement de ce serveur repose sur l'algorithme HOTP basé sur HMAC et décrit précédemment, pour VASCO le serveur utilise les fonctions fournies par le VACMAN Controler tandis que le dispositif Xiring utilise une troisième méthode de vérification d'otp utilisant l'algorithme DES. 3 Différentes versions du client et du serveur de test Détail du fonctionnement du client de test: Celui-ci doit effectuer successivement: 1/ la validation du certificat du serveur à partir de l'autorité de certification reconnue par le client : c'est-à-dire que l'on effectue la vérification de la validité de la chaîne de certificats ayant pour origine la CA connue du client et pour extrémité terminale le certificat du serveur 2/ l'affichage du popup permettant la saisie du login et de l'otp s'affichant sur la calculette. Dans un premier temps login et OTP sont saisis en ligne de commande dans une console Deux popups ne peuvent être actifs simultanément sur une même machine, les variables login et otp sont globales et leur modification est réalisée en exclusion mutuelle. 21

22 Les versions successives du client implanteront l'une puis l'autre de ces tâches et ont été testées avant de passer à la version suivante. Le serveur de test: Pour effectuer les premiers tests du client, un serveur de test PST est nécessaire, il se contente de recevoir les requêtes au format ASN, de les décoder, d'afficher leur contenu et de permettre la saisie d'un code de retour qui sera encodé en ASN pour fournir une réponse au client. 4 Serveur ncryptone avec base de données configurée grâce à l'outil Thor Thor est un outil développé en interne par Cryptolog et qui permet d'assembler les divers composants d'un serveur et de visualiser leurs dépendances sous forme de graphe. Il a d'abord fallu créer la base de données de test contenant des logins, et des clés permettant la génération des OTP, utiliser des requêtes SQL pour remplir la base de données, puis associer cette base de données à un serveur ncryptone utilisant le protocole PST et lui-même relié à un Remote Serveur effectuant les opérations cryptographiques. Ensuite une phase de test du client sous Windows à été nécessaire. Celle-ci comporte entre autre l'affichage des popups graphiques comme celui visible sur le schéma décrivant précédemment le protocole d'identification ainsi que la saisie des logins et OTP, la lecture correcte de la requête par le serveur PST, la transmission de la partie contenant la demande de réalisation d'opérations cryptographiques au Remote Serveur et la bonne retransmission par le serveur PST de la réponse du Remote serveur au client. Les calculettes ncryptone sont en fait des cartes à puce flexibles (les puces des cartes de démonstration sont vierges mais pourraient être celles de cartes bancaires) qui après une pression sur le coin inférieur droit de la carte affiche un OTP de 8 chiffres sur un petit écran situé sur le coin supérieur droit de la carte. Cet écran utilise un procédé similaire à celui de l'encre éléctronique, ne consommant ainsi de l'énergie que lors de la modification de l'affichage. Pour les premiers tests, ne disposant pas encore de calculette ncryptone, les OTP sont lus dans la table d'exemples correspondant à la clé fournie dans la RFC Résultats: les Remote Tokens sont crées et enregistrés dans la base de registres. 5 Mutualisation du code pour ncryptone et Vasco Après une phase de réflexion pour permettre d'utiliser dans le protocole d'authentification un format de requête commun à ncryptone et Vasco, puis plus tard utilisable également pour Xiring, il fallut modifier en conséquence la spécification ncryptone.asn, tout en la conservant compatible avec le client et serveur ncryptone écrits précédemment. Ceci conduit à la spécification d'un protocole d'authentification protocole.asn, commun à ncryptone et Vasco et par la suite Xiring. La mutualisation du code pour les différents dispositifs d'authentification se traduit concrètement par l'écriture d'interfaces java génériques (adaptées aussi bien à ncryptone qu'à Vasco ou Xiring) pour le serveur d'authentification. Pour que le code du serveur d'authentification ncryptone soit compatible avec ces interfaces, il a fallu réécrire les classes java implémentant ces interfaces pour ncryptone. 22

23 6 Client et serveur Vasco Pour générer les OTP, Vasco propose à ses clients toute une gamme de Digipass dont certains peuvent être utilisés comme porte-clés. Le dispositif utilisé pour les tests est un Digipass 250 (illustration ci-dessous) qui fonctionne en mode OTP (réponse seule) ou en mode Challenge/Réponse. Le serveur d'authentification doit pouvoir gérer ces deux modes. Digipass 250 de Vasco Pour générer des challenges et vérifier la validité des OTP ou des réponses, Vasco fourni une bibliothèque de fonctions C: le Vacman Controleur. Cette bibliothèque de fonctions sera utilisée par le serveur d'authentification par l'intermédiare d'un wrapper java. La première partie du travail concernant Vasco à été de réaliser un programme java de test pour vérifier la validité d'un OTP pour un utilisateur et une valeur du compteur donnés. Après des tests concluants, cette méthode de vérification a pu être incorporée au serveur d'authentification. Pour pouvoir tester le serveur d'authentification il est nécessaire de disposer d'un client capable d'emettre des requêtes susceptibles d'être authentifiées. L'écriture du client pour Vasco à consisté à modifier le code déjà utilisé pour le client ncryptone, particulièrement en ce qui concerne l'affichage des popups permettant la saisie des login et OTP. En effet pour ncryptone, login et OTP pouvaient être saisis en même temps (dans deux TextFields d'un même popup) mais le serveur Vasco propose lui une identification soit par OTP soit par challenge/réponse selon l'utilisateur. Un premier popup doit donc demander le login et un second l'otp ou la réponse après avoir affiché un challenge. Cette authentification pouvant se faire dans les deux modes, requiert donc un échange supplémentaire entre le client et le serveur. Les classes java écrites pour le serveur d'authentification Vasco diffèrent essentiellement des classes du serveur ncryptone de par les données stockées par le serveur et utilisées pour calculer les vérification d'otp et de réponse ainsi que part l'algorithme utilisé pour réaliser ce calcul: les fonctions du Vacman Controller remplacent l'algorithme HOTP utilisé pour ncryptone. Après une première série de tests conduisant à des modifications, une seconde série de tests concluants permet de valider le serveur d'authentification Vasco. 23

24 7 Client et serveur Xiring Pour générer des OTP à partir de carte à puce, Xiring propose des lecteurs de cartes portables (ci-contre le lecteur Xi-SIGN 4000 utilisé pour les tests) qui permettent d'utiliser une clé stockée dans la carte et de l'associer à un compteur incrémenté à chaque utilisation pour calculer soit un OTP simple soit une réponse à un challenge. Pour plus de sécurité, la lecture de la carte requiert un code PIN. La lecture de la documentation a permis de soulever quelques imprécisions puis un contact avec Bruno Choiset a conduit à l'abandon temporaire de la solution d'authentification utilisant le lecteur Xi-Sign Santé et les cartes CPS et Vitales (les spécifications faisant actuellement l'objet de réaménagements). Lecteur Xi-SIGN 4000 de Xiring L'étude et le développement de l'intégration de la solution d'authentification utilisant le lecteur Xi- Sign EMV et les cartes Visa et MasterCard a nécessité l'implentation de l'algorithme vérifiant un OTP, ou une réponse à un challenge à partir des données correspondantes à un utilisateur. L'algorithme implémenté est décrit ci-dessous. L'entrée de l'algorithme est constitué de 5 blocs de 8 octets Di (i=1 à 5), contenant des données propres à l'utilisateur dont notamment un compteur incrémenté à chaque utilisation et l'éventuel challenge. 24

25 Le serveur stocke la valeur du compteur et l'incrémente d'une valeur calculable à partir de l'otp envoyé par l'utilisateur. On applique ensuite au cryptogramme obtenu un masque pour ne conserver que certains bits. On compare ensuite la valeur obtenue avec l'écriture binaire de l'otp, si celles-ci coïncident, l'utilisateur est authentifié. Cet algorithme implémenté et testé, il a ensuite fallu créer la base de donnée contenant les utilisateurs de test, puis écrire les classes java pour le serveur d'authentification Xiring implémentant les interfaces génériques déjà définie pour les serveur ncryptone et Vasco. Il a été possible de réutiliser intégralement le même code que pour Vasco pour le client Xiring. En effet, le choix du mode d'authentification (challenge réponse ou réponse seule) et de l'algorithme utilisé pour effectuer la vérification de l'otp peut être entièrement géré du coté du serveur. Pour le dispositif Vasco comme pour Xiring, le client se contente de demander à l'utilisateur d'entrer son login et en fonction de la réponse du serveur affiche ou non un challenge. Les tests d'authentifications par OTP simple ou par réponse à un challenge ont été concluants. 25

26 8 Design du plugin : programmation Windows L'objectif de cette étape est d'améliorer l'aspect graphique du plugin. En effet, bien qu'un travail important ait été nécessaire pour assurer le bon déroulement de l'authentification, la partie visible pour l'utilisateur réside entièrement dans ce popup. Il a ainsi été jugé judicieux de transformer le plugin (ci-dessous) quelque peu austère, en une véritable carte à puce virtuelle. Le nouvel aspect du plugin est celui d'une carte à puce à coins arrondis, il donne ainsi à l'utilisateur une idée plus claire des fonctionnalités qu'il remplit. Pour réaliser ce nouveau plugin, j'ai partiellement réutilisé le travail de Jean-Christophe permettant d'ajouter une image de fond à une fenêtre Windows et de gérer des zones de transparence pour obtenir des coins arrondis. Le mot de passe étant un One Time Password, celui ci ne pourra pas être réutilisé, il n'est donc pas nécessaire de le masquer. Cela évite de plus les erreurs de saisie plus fréquentes sur un mot de passe dynamique lu sur un dispositif que sur un mot de passe statique mémorisé et utilisé régulièrement. Par la suite on pourra éventuellement proposer aux clients un plugin habillable, c'est-à-dire leur permettre de choisir le style des boutons, la police et la couleur des caractères ainsi que l'image en arrière plan. 26