AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE

Transcription

1 AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE RAPPORT DE STAGE Maître de Stage : Sandrine Locatelli Ingénieur développement Produit 4ème année Réseau Informatique Et Communication Multimédia (RICM4) Année

2 2

3 Remerciements Je tiens tout particulièrement à remercier mon maître de stage Sandrine LOCATELLI et la directrice R&D et Production Bénédicte BOUCHE pour leur accueil chaleureux, ainsi que le directeur de Interview S.A., Alain BOUVERET, pour m avoir accepter en tant que stagiaire. Je remercie également Daniel CHIPAN, Pierre GOIFFON, Guillaume MARY, Xavier FARRET et Mathieu MARTINEZ pour leur sympathie, leur disponibilité et leurs conseils qui m ont aidés à résoudre les problèmes liés à mes missions et ainsi d effectuer sereinement mon stage. D une façon plus générale, je remercie tous les membres de la société Interview pour leur accueil et les moments de détente que nous avons eu ensemble qui m ont permis d apprécier la vie en entreprise. Je remercie de même ma tutrice de stage Nadia BRAUNER VETTIER pour son encadrement pendant la durée de mon stage. 3

4 Table des matières Remerciements 3 Résumé.. 5 Introduction ère Partie : Cadre du stage I. L «Enterprise Feedback Management» (E.F.M.), la nouvelle méthode d enquêtes 1. Présentation 7 2. Une dénomination peu connue mais un concept jugé utile. 8 II. Interview?! S.A., précurseur sur le marché de l EFM 1. La petite histoire 8 2. Interview S.A. aujourd hui 2.1. Organisation sociale de l entreprise Partenaires et clients Solutions EFM proposées Le département produits ème Partie : Les missions et les apports du stage I. Les missions 1. Le protocole DomainKeys Indentified Mail (DKIM) Authentification avec Lightweight Directory Access Protocol (LDAP) Cryptage de mot de passe 20 II. Les apports du stage 1. Compétences Techniques Acquises Problèmes Rencontrés& Solutions Apportées La vie dans la société. 23 Conclusion.. 24 Bibliographie/Webographie. 25 Documents rédigés Table des figures Annexes 27 Tableau des révisions 39 4

5 Résumé Mon stage de dix semaines au sein de la société Interview S.A. a été des plus enrichissants. Bien que ne répondant pas au besoin de la société d améliorer sa délivrabilité, le protocole Domain Keys Identified Mail (DKIM) est un protocole de signature intéressant et comme expliqué dans mon rapport de stage, sa mise en place, très simple, serait une sécurité supplémentaire pour la lutte contre l hameçonnage. L authentification en utilisant un annuaire Lightweight Directory Access Protocol (LDAP) est un moyen pour les clients de Interview de pouvoir avoir accès aux produits qu ils offrent en utilisant le même mot de passe et login que ceux pour s authentifier dans leur entreprise. La mise en place de cette couche LDAP passe par l utilisation de frameworks tels que JAAS et JNDI. Le cryptage des mots de passe en base de données résulte d un besoin pour Interview de ne plus les y avoir en «clair». Le moyen le plus sûr de faire ce cryptage- c est-à-dire sans possibilité de retrouver le mot de passe original-, c est d utiliser les fonctions de hachage. Cependant, pour pouvoir rendre à l utilisateur son mot de passe en cas de perte, le chiffrement à clé publique reste le meilleur choix. My training course of ten weeks within the company Interview Inc. was the most enriching. Although not answering the need of the company to improve its deliverability, the protocol Domain Keys Identified Mail (DKIM) is an interesting signature protocol and, as explained in my report of training course, its implementation, very simple, would be an additional safety for the fight against the fishing. The authentication by using a directory Lightweight Directory Access Protocol (LDAP) is a means for the customers of Interview to be able to have access to the products which they offer by using the same password and login as those to authenticate in their company. The implementation of this layer LDAP passes by the use of frameworks such as JAAS and JNDI. The encoding of the passwords in database results from a need for Interview to have them there not more in "light". The way the safest to make this encoding -that is without possibility find the original password- it is to use the hash functions. However, to be able to return to the user its password in case of loss, the encoding with public key stays the best choice. 5

6 Introduction J ai effectué mon stage au sein de la société Interview S.A. situé au 2 Avenue de l Obiou, La Tronche. Ce rapport présente les différentes missions que j ai effectuées durant ces dix semaines de stage. Et le point commun que l on peut trouver à ces différentes missions, est que d une façon où d une autre, elles traitent de la sécurité. En effet, bien que le but de l étude du protocole Domain Keys Identified Mail(DKIM) était de faire croître la délivrabilité des mails de Interview, il s avère à la fin que c est une méthode de protection contre l usurpation d identité. De même, l authentification par Lightweight Directory Access Protocol (LDAP) et le cryptage de mot de passe en base de données ont pour but de protéger les produits de Interview. Les différents projets effectués se sont avérés très intéressants et très enrichissants du point de vue expérience professionnelle. En effet, grâce à ces différentes missions, j ai pu entrevoir en quoi consiste le métier d ingénieur et surtout de pointer un sujet qui m intéresse vivement : la cryptologie, la sécurité et le codage de l information. Le but de ce rapport n est pas seulement de faire une présentation exhaustive de tous les aspects techniques que j ai pu apprendre ou approfondir au cours de ces semaines de stages, mais aussi de présenter les aspects humains auxquels j ai été confrontée. Alors, dans ce rapport, je donnerais une définition de ce qu est l Entreprise Feedback Management (E.F.M.), le domaine dont Interview est spécialiste. Puis, je présenterais la société elle-même. Et enfin, je parlerais des différentes missions que j ai accomplies, m attardant sur la manière dont elles ont été abordées. 6

7 1 ère Partie : Cadre du stage I. L «Enterprise Feedback Management» (E.F.M.), la nouvelle méthode d enquêtes 1. Présentation Interroger des clients via des enquêtes est une pratique répandue et utilisée depuis longtemps par les entreprises. Que se soient des enquêtes de satisfaction, de qualité ou encore de notoriété, le but de celles-ci est de répondre à une question unique posée par un département spécifique de l entreprise. Mais les résultats de ces enquêtes sont très peu souvent réutilisés ou suivis à la fin de l enquête. Cependant, face à un contexte concurrentiel de plus en plus difficile, les entreprises ont plus que jamais besoin de rester à l écoute de leurs clients et ce de manière constante et régulière. Le but étant de palier rapidement tout signe de mécontentement ou d insatisfaction et ainsi éviter la perte de clientèle au profit de la concurrence. Ce n est pas un besoin ponctuel, pas plus qu il ne doit appartenir à un département dans l entreprise plutôt à un autre. C est un enjeu d entreprise indispensable à leur développement. Pour répondre à cette évolution, les éditeurs d enquêtes ont eu à s approprier les principes bien connus des systèmes décisionnels. Ces derniers permettent de constituer en un lieu unique une base de connaissance d information intégrées et archivées qui sera ensuite mise à disposition d un grand nombre d utilisateurs pour une exploitation adaptée à leur besoin. De plus, ils ont eu à «épouser» les solutions CRM 1 (Custom Relation Management) déjà mises en œuvre chez beaucoup d entreprises et qui permettent la collecte des informations transactionnelles clients et la gestion de la relation avec les clients au quotidien. Ce qui a donné lieu à l émergence d une nouvelle méthode de traitement de l information : l Entreprise Feedback Management ou EFM. 2. Une dénomination peu connue Le concept d EFM n est pas nouveau. Il a été introduit en 2005 par le Gartner. Il désigne une tendance de management où toutes les informations d entreprise sont centralisées au sein d un outil, connecté au reste du système d information et mutualisable entre les différents métiers de l entreprise. En d autres mots, l EFM répond au besoin de collecter,gérer et analyser un maximum d informations venant des sources internes (salarié,filiales) comme externes (clients,partenaires) et de centraliser ces informations dans des outils qui communiquent entre eux pour un traitement fiable et économique. Le but étant d établir des plans d actions efficaces auprès des ces diverses sources. Si plusieurs acteurs proposent aujourd hui ce type de plateforme (WysuForms, Interview?! SA, VDoc Software ou GrimmerSoft, et d autres), peu d entreprises ont 1 Voir Annexe A 7

8 réellement adopté cette nouvelle méthode de traitement de l information. La raison est, d après les résultats du nouveau Baromètre annuel de l EFM, commandité GrimmerSoft, que l EFM est encore mal connu. L étude a porté sur les réponses de vingt deux mille sept cent vingt-huit (22728) professionnels de tous secteurs en France, interrogés par Marketor 1 via un questionnaire en ligne administré entre le 15 mars et le 15 mai Ce baromètre révèle en effet que seulement 5 % des entreprises connaissent la dénomination EFM. 3 mais un concept jugé utile Aujourd hui, les entreprises utilisent une grande variété d outils pour recueillir et traiter les informations. Par ailleurs, elles ont souvent recours à des outils de bureautiques non spécialisés. Le baromètre commandité par GrimmerSoft 2 fait état du fait que si, globalement, les personnes interrogées sont satisfaites de leurs outils de recueil et de traitement de l information, elles estiment qu ils restent source d insatisfaction en matière d intégration avec le reste du système (48% d insatisfaits en moyenne et 43% pour le service de Marketing- Etudes) et de coût d acquisition (40% d insatisfaits en moyenne et 46% pour le service Marketing-Etudes). Mais même si sa notoriété est faible, le concept d EFM est jugé utile par 76% des répondants, et notamment par le service des Ressources humaines (77%). Le service informatique fait également partie des convaincus (68%), tandis que le Marketing est plus sceptiques (seulement 47% des répondants approuve son utilité). Il en ressort que plus de 25% des entreprises seraient prêtes à s équiper de solution EFM à court terme (moins de douze mois). Dans cette éventualité, elles demeureraient attentives particulièrement au coût du projet et à l adéquation de ces solutions aux spécificités des différents métiers de leur organisation. II. Interview?! S.A., précurseur sur le marché de l EFM 1. La petite Histoire Dès 1998, les créateurs d Interview SA ont décidé de concevoir une plate-forme logicielle destinée à organiser et à structurer tous types de remontées d informations. Cette plateforme devait être simple, générique et immédiatement opérationnelle pour ses utilisateurs. En 2000 l idée a pris forme et Interview SA est née. Et la plateforme a été nommée interview?!. En 2002, il est créé au sein de la société un département Etudes chargé de la conception des questionnaires ou quiz, de l accompagnement des clients et de l analyse des résultats de l enquête. Trois ans plus tard, la démarche proposée par Interview SA a trouvé un nom dans les pays anglo-saxons : Enterprise Feedback Management. Cette démarche, fondée sur le besoin de mieux intégrer son environnement dans les prises de décision, détermine un nouveau métier. Ses maîtres mots sont : technologies efficaces et génériques, vision globale et industrialisation des outils. 1 Marketor est une société créée en 2005 et spécialisée dans les études sur le secteur IT. 2 Quelques résultats du baromètre sont donnés en Annexe B 8

9 En 2007, Interview SA assure sa seconde levée de fond. En 2009, un nouveau bureau est créé à Stuttgart (Allemagne). En 2010, Interview dispose de nouveaux supports de recueil : écrans tactiles, USSD 1 (Unstructured Supplementary Service Data) 2. Interview SA aujourd hui 2.1. Organisation sociale Le président et fondateur d Interview SA, Alain BOUVERET, compte au sein de son entreprise trente collaborateurs. Comme le montre l organigramme suivant, l entreprise est subdivisée en trois pôles importants : Figure 1 : Organigramme Interview SA (Juillet 2010) o Le pôle Client & Opération : il regroupe trois départements qui sont le département commercial, le département études et le département projets. Son rôle est de répondre directement aux besoins des clients de la société. 1 Voir Annexe A 9

10 o Le pôle R&D et Production : il est lui aussi constitué de trois départements : le département Dev-Produits, le département Réseau et Infrastructure et le département Qualité et Support. o Le pôle Marketing et Relations Extérieures. Le tout complété par le service administratif (RH, comptabilité et administration générale) Partenaires et clients Aujourd hui, Interview SA compte environ deux cents clients. Parmi eux, on note des grandes entreprises telles que Schneider Electric, Auchan, EDF, France Télécom, Michelin Et pour répondre de façon plus précise aux besoins de ces clients Interview SA a conclu des partenariats avec certaines sociétés. Ces partenaires entrent dans trois profils : les prescripteurs, les revendeurs et les intégrateurs. Parmi eux, on compte : - DIMO Gestion, expert dans l intégration de solutions collaboratives qui propose la solution d Interview SA pour l analyse et la collecte d informations de ses clients ; - Orange (depuis 2002) pour la mise en œuvre de solutions de remontées d informations sur terminaux mobiles ; - Vdoc Software, leader français sur le marché BPM 1 : Interview SA est rentré dans son programme Alliance afin de proposer aux clients une nouvelle offre EFM. - MONGOLFIER Consultants, cabinet de conseil, de formation et de coaching : il collabore avec Interview SA pour la création d une offre autour du développement durable au sens large ; - Zap-Meeting, spécialiste de la communication audiovisuelle dynamique sur écran : avec Interview SA, il propose à leurs clients des solutions de recueil d informations via des écrans tactiles ; L élargissement des usages d interview?! au sein de ces groupes pour la plupart internationaux fait en sorte que les solutions EFM apportées par Interview SA sont mises en œuvre dans près de soixante pays sur tous les continents. Le siège et les équipes de développement sont à Grenoble. Interview SA dispose aussi d implantations sur Paris, Montpellier, Milan et Stuttgart Solutions EFM proposées Interview SA propose à ses clients trois solutions EFM : - interview?! C est le premier produit, développé sous Notes, que Interview SA a mis en place. Les maîtres mots de la plate-forme interview?! sont : o interroger : création d un formulaire personnalisé de type questionnaire, quiz ou sondage ; o collecter : diffusion du formulaire soit par , dépôt sur site intranet/internet ou via mobiles ; puis suivi en temps réel des réponses obtenues ; o analyser : traitement des informations (récupération des données sous format CSV (Excel), préparation des rapports d analyse) Les impacts de cette solution sont : o une capacité d écoute déployée à différents niveaux : détaillée localement et consolidée internationalement, 1 Voir Annexe A 10

11 o des économies de coûts, o un développement de nouvelles compétences internes, o une possibilité de suivi transverse des clients et des collaborateurs (fidélisation, anticipation). Figure 2 1 : la plate-forme EFM interview?! En ce moment, les développeurs d Interview tente de le faire migrer vers JAVA. La raison est que Notes des de moins en moins utilisé chez les clients. - dataview?! : Le but de cette solution EFM, développée en JAVA, est de permettre à une certaine population de pouvoir accéder, via le WEB (authentification login/mot de passe), aux données de résultats d une enquête en pouvant manipuler simplement les variables. Ces données peuvent venir d interview?! ou non. - openview?! : Il est difficile d exploiter les réponses aux questions ouvertes (exemple : Quel est votre opinion sur?) car ces dernières nécessitent un traitement long et coûteux. Le but de openview?! est de o pouvoir mettre en œuvre des outils d études qualitatives en ligne (forum, bulletin board, chat) o puis analyser les données textuelles obtenues. Ces deux derniers produits de Interview sont en cours de réalisation. 3. Le département Produits Au sein de cette société de taille humaine, il est aisé de percevoir les interactions entre les différents pôles et départements cités ci-dessus. Cependant, compte tenu du fait que mon stage a exclusivement été effectué au département Dev-Produits, il sera uniquement développé ici le fonctionnement de ce service. Le département Dev-Produits, dirigé par Bénédicte Bouché, est composé de huit employés, répartis en deux équipes: une équipe Java pour le développement des produits en java (dataview?!, openview?! et migration de interview?! en java) et d une équipe Notes qui 1 Source 11

12 s occupe de interview?! qui est écrit en Notes. Chacune des équipes se trouve dans un bureau. Cette répartition facilite le brainstorming. Par exemple, si un membre de l équipe java bloque sur un concept java, il peut demander de l aide aux autres qui sont dans le même bureau que lui. Chaque membre du département est responsable d un projet. Le lundi, une réunion d équipe est organisée. Le but de cette réunion est de faire part aux autres membres du département de l évolution du projet, des problèmes rencontrés. L avantage de cette réunion qu elle permet de développer des synergies au sein de l équipe et d éviter que chacun se sente isolé. Et dans l optique de créer une bonne entente entre les membres de l équipe, des balades, randonnées ou barbecue sont organisés. Cela leur permet de discuter en dehors du bureau et de sujet différent du travail. 2 ème Partie : Les missions et les apports du stage I. Les missions 1. Le protocole Domain Keys Identified Mail (DKIM) Du fait de ses objectifs, Interview SA est un grand diffuseur de mails de sollicitation d enquête. Cependant, certains des ces mails peuvent être considérés comme des spams 1. Il fallait donc trouver une solution pour améliorer la délivrabilité des mails de diffusion de Interview. L équipe du département Dev-Produits a pensé que la mise en place d un système de signature électronique, le protocole Domain Key Indentified Mail (DKIM), pourrait être cette solution. Ma mission consistait donc dans un premier temps de mener une étude sur ce protocole afin que l équipe soit en mesure d apprécier et de comprendre son fonctionnement. Puis, en fonction de mes résultats, il serait décidé si oui ou non, le protocole serait mis en place. Les étapes de mon étude sont les suivantes : - la compréhension du principe et du fonctionnement général de DKIM, - comment DKIM peut aider Interview SA à être considéré comme non spammeurs? - la rechercher d autres alternatives à DKIM, - la recherche des Fournisseurs d Accès Internet (FAI) et des clients qui utilisent DKIM, - quelles sont les procédures et étapes pour une éventuelle mise en place au sein de Interview? Le protocole DKIM est une norme d authentification fiable du nom de domaine de l expéditeur d un courrier électronique. Il est la résultante d un consortium industriel en Il intègre et améliore DomainKeys, de Yahoo! et Identified Internet Mail, de Cisco Ce protocole donc est lié au courrier électronique. De ce fait, pour pouvoir le comprendre, j ai eu à revenir sur la définition du courrier électronique et surtout sur la description du trajet parcouru par un courrier électronique de son envoi à sa réception. Il en est ressorti que le courrier électronique ou courriel ou mail ou suit un parcours (de l envoi à la réception) qui peut être subdivisé en quatre étapes comme le montre la figure ci-après : 1 Voir Annexe A 12

13 Figure 3 1 : Etapes de l acheminement de courrier électronique Étape 1 : le Mail User Agent (MUA) ou client de messagerie de l expéditeur envoie, utilisant SMTP 2 (Simple Mail Transfert Protocol), le message à un serveur de courriel (celui de son fournisseur d accès généralement) ou MTA (Mail Transfert Agent) ; étape2 : le premier MTA atteint route le message vers le MTA hébergeant le domaine du destinataire. Le MTA final délivre au MDA (Message Delivery Agent) qui est en charge de la gestion des boîtes aux lettres ; étape 3 : le destinataire, par l intermédiaire de son MUA, demande à son serveur de courrier (MDA) les nouveaux messages par l utilisation des protocoles IMAP (Internet Message Access Protocol) ou POP (Post Office Protocol) ; puis le destinataire, par l intermédiaire de son navigateur demande au serveur web de retrouver les nouveaux messages sur le MDA ; étape 4 : le serveur envoie le message au MUA du destinataire. Les notions de MUA, MTA, MDA, ont été importantes pour la compréhension du protocole que je devais étudié car que elles interviennent dans le fonctionnement de la signature DKIM. Pour illustrer, prenons l exemple suivant 3 : 1. L utilisateur compose le message From: Joe SixPack <[email protected]> To: Suzie Q <[email protected]> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < [email protected]> Hi. We lost the game. Are you hungry yet? Joe. 1 Source 2 Voir Annexe A. De même pour IMAP et POP 3 Source : Annexe a du RFC

14 2. DKIM (qui peut être installer dans le MUA, mais sera en général dans le MSA (Mail Submission Agent) ajoutera une en-tête DKIM-Signature : DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; [email protected]; h=received : From : To : Subject : Date : Message-ID; bh=2jusoh9nhtvgcqwnr9briaprekqjo6sn7xikfjvozv8=; b=auuofefdxtdkhllxszepzj79liceps6eda7w3detvfok4yauoqob 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [ ] by submitserver.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: Joe SixPack <[email protected]> To: Suzie Q <[email protected]> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < [email protected]> Hi. We lost the game. Are you hungry yet? Joe. Cet entête est de type SMTP. Elle contient une série de valeurs séparées par des «;». L'une de ces valeurs est obtenue par le chiffrement asymétrique (RSA) de l'empreinte (SHA1 ou SHA256) d'une forme canonique du message et de certains de ses entêtes. Le destinataire du message peut déchiffrer cette empreinte au moyen de la clé publique du domaine signataire et vérifier l'intégrité du message en la recalculant. On observe que la technique utilisée est très similaire à celle utilisée pour la signature S/MIME ou PGP. L'entête «From:» faisant partie des entêtes qui sont toujours signés, sa falsification n'est possible qu'en disposant de la clé privée de signature. L identité est indiquée dans la signature pour éviter de longs débats sur l identité la plus pertinente parmi toutes les identités présentes dans le mail. Le MUA doit donc en tenir compte et afficher l adresse qui est authentifiée, pas seulement celle qui se trouve dans le champ From et qui peut être différente.la signification de chaque champ de cette signature ainsi que les différents algorithmes de chiffrement sont donnée dans l annexe C. 3. Vérification de la signature DKIM Le programme qui veut vérifier la signature (MTA (Mail Tranfert Agent ou Message Transfer Agent) mais cela peut être le MUA) doit récupérer la clé publique de la signature. DKIM récupère la clé via DNS ( Domain Name System), pour ne pas dépendre des lourdes et chères autorités de certification. Pour cela, il utilise le nom de domaine «example.com» extrait du tag «d=», ainsi que le sélecteur «brisbane» extrait du tag «s=» contenu dans l en-tête DKIM-Signature pour former DNS DKIM query suivant : brisbane._domainkey.example.com Puis la vérification de signature physique commence par l en-tête du champ Received, suivi de l en-tête du champ From, et ainsi de suite, suivant l ordre de la liste extraite de l étiquette «h=». La vérification se poursuit jusqu au CRLF (Carriage Return Line Feed : séquence de 14

15 deux octets qui indiquent la fin de la ligne). Le résultat de la requête précédente (DNS DKIM query) et des différentes vérifications est enregistré dans le champ d entête X-Authentication-Results.Ce qui correspond dans notre exemple à : X-Authentication-Results: shopping.example.net [email protected]; dkim=pass Received: from mout23.football.example.com ( ) by shopping.example.net with SMTP; Fri, 11 Jul :01: (PDT) DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; [email protected]; h=received : From : To : Subject : Date : Message-ID; bh=2jusoh9nhtvgcqwnr9briaprekqjo6sn7xikfjvozv8=; b=auuofefdxtdkhllxszepzj79liceps6eda7w3detvfok4yauoqob 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [ ] by submitserver.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: Joe SixPack <[email protected]> To: Suzie Q <[email protected]> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < [email protected]> Hi. We lost the game. Are you hungry yet? Joe. Au vu de cet exemple, deux actions importantes dans le processus de signature DKIM ressortent : la signature proprement dite et la vérification de signature. Pour résumé, on peut dire que le principe du protocole DKIM est le suivant : le serveur émetteur doit ajouter à l entête du message, un champ qui contient une signature électronique cryptée. Le serveur de mail qui reçoit le message peut alors interroger le serveur DNS de l expéditeur pour obtenir une clef qui lui permettra d'authentifier, ou non, le message et son expéditeur Cette étude a duré trois semaines. Au bout de la première semaine, une réunion a été organisée avec quatre membres de l équipe (dont mon maître de stage et le chef du département) pour présenter la première partie de l étude. Il ne s agissait pas d une présentation technique mais de donner un aperçu de ce qu était le protocole DKIM, une définition. A la fin de l étude, un document de synthèse a été rédigé puis j ai fait une présentation lors de la réunion d équipe qui a lieu le lundi matin. La conclusion de ma présentation était la suivante : le protocole DKIM, bien empêchant l usurpation de domaine et permettant de définir de manière non descriptive les serveurs pouvant envoyer des mails pour un domaine et de faire la réputation d un domaine, n avait aucun impact quant à la politique des filtres antispams. En d autres termes, DKIM ne permet pas à celui qui l utilise d être considéré comme non spammeurs. Au terme de cette réunion, la décision de ne pas mettre en place le protocole a été prise. Ce qui a donné lieu à un changement de mon sujet de stage. 15

16 2. Authentification avec Lightweight Directory Access Protocol (LDAP) La plupart des clients "grand compte" d'interview disposent d'un annuaire LDAP pour la gestion de leurs collaborateurs. Un besoin récurrent de ces clients est de pouvoir se connecter aux applications Interview?! en utilisant leur login / mot de passe LDAP. Les produits java d Interview dispose d'un service d'authentification (commun à tous les produits), s'appuyant sur la base de données des produits pour la gestion des accès. Les utilisateurs s'authentifient par un login / mot de passe via une requête SQL dans la base de données. Le but de cette partie du travail est d'améliorer ce service d'authentification en lui ajoutant une couche LDAP permettant éventuellement de déporter l'authentification à un annuaire LDAP. Au final, le service d authentification devrait fonctionner comme suit : Figure 4 : Service d authentification auprès des produits Interview (exemple avec dataview?!) (1) : Le client Interview tente de se connecter sur la page web du produit souhaité en donnant son login et mot de passe. (2) : l application de gestion d authentification lance, à partir du login du client, la recherche dans l annuaire LDAP 1.La connexion se fait avec le login/mot de passe de l administrateur de l annuaire LDAP. (3) : le résultat de la recherche est envoyé. 16

17 Si la recherche a été fructueuse (client trouvé), on passe au (4).Sinon, on reprend le (2) et le (3) avec l annuaire suivant. Et ainsi de suite jusqu à ce que soit le client est trouvé, soit il y a plus d annuaire à interroger. (4) : tentative de connexion avec le login/mot de passe du client. (5): résultat de la connexion : - si OK alors on passe au (8), - sinon, reprendre à partir du (2). (6), (7) : si la recherche auprès des annuaires LDAP ne donne rien, alors la gestion de l accès se fait au niveau de la base de données. (8) : accès au produit dataview?!. (9) : la recherche auprès des annuaires LDAP et l authentification avec la base de données n a pas été fructueuse, alors il est renvoyé au client que la connexion est un échec. La notion LDAP était assez vague pour moi. De ma formation, je savais juste que c était un annuaire électronique telle que DNS mais pas plus. Alors pour mener à bien cette mission, j ai prévu une journée pour comprendre le fonctionnement global de l annuaire LDAP (comment il est constitué? comment on y accède?). Le logiciel JXplorer 1 m a été d une grande aide pour voir à quoi ressemblait l architecture d un annuaire LDAP. Les spécifications de ma mission incluaient une étude du framework 2 JAAS (Java Authentification and Authorization Service) pour savoir dans quelle mesure il permettrait de mettre en place cette couche LDAP. Cependant, lors de ma recherche sur le fonctionnement de l annuaire, je me suis rendu compte qu il existait un autre framework qui lui aussi pourrait répondre à ce problème. Il s agit de JNDI (Java Naiming and Directory Interface). JNDI est un standard et une librairie de classes JAVA, élaboré par SUN (maintenant Oracle) afin de normaliser tout type d annuaire et de répertoire de noms. Mon choix s est initialement porté sur cet framework car son fonctionnement est simple et facile de mise en place. Pour définir une connexion, JNDI a besoin de deux éléments : - la fabrique du contexte racine : c est cet objet qui assure le dialogue avec le service utilisé en se basant sur le protocole adéquat ; - l url du service à utiliser (ici LDAP). Le code que j ai écrit n était constitué que d une seule classe, la classe LdapAuthentification.java construite suivant le principe de JNDI se divisant en trois parties : l initialisation, la recherche et la connexion qui sont représentés respectivement par un constructeur et deux méthodes. L initialisation consiste en : - l importation des paquetages requis pour JNDI : i. javax.naming.* qui contient les classes Java et les interfaces pour accéder à des services de noms ; ii. javax.naming.directory.* qui est une extension du paquetage précédent qui offre des services complémentaires dédiés aux annuaires. - La paramétrisation de l environnement nécessaire au contexte de connexion. Cet environnement est une Hashtable. Il est modifiable à tout moment durant l exécution de l application. Les informations qui y sont entrés sont : 1 JXplorer est client LDAP développé en Java sous une licence opensource de type OSI. Il permet de lire ou de modifier la contenu de tout annuaire LDAP (Source : OpenVms) 2 Un framework, en programmation orientée objet, est typiquement composés, de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui l utilisent (Source : Wikipédia). 17

18 i. le nom de la classe à utiliser comme fournisseur de service d annuaire. Dans notre cas, comme nous voulons LDAP, j ai rentré la classe «com.sun.jndi.ldap.ldapctxfactory» ; ii. l adresse de l annuaire LDAP à laquelle on veut se connecter. J ai utilisé l adresse du LDAP de Interview ; iii. les paramètres d identification. Si ces paramètres ne sont pas spécifiés, on parle d identification anonyme. Dans le code que j ai écrit j ai choisi une identification simple (les valeurs possibles sont none, simple, ou strong), en donnant le Distinguish Name 1 et le mot de passe d un administrateur pour la recherche. Ces informations sont récupérées à partir d un fichier properties que j ai initialement rempli. La partie recherche consiste en la connexion à l annuaire, suivi de l identification et enfin de la recherche proprement dite. Cette dernière consiste en la définition des options de la recherche comme suit : SearchControls ctrl = new SearchControls(); ctrl.setsearchscope(searchcontrols.subtree_scope) La deuxième ligne de code précise que la recherche doit se faire dans les nœuds sous-jacents à l objet de base. Puis, j ai utilisé la méthode search() de la classe DirContext en spécifiant l objet de base de la recherche puis le filtre. Pour ce qui est du filtre, j ai fait en sorte que la recherche se fait soit sur le prénom (SurName(SN)), soit sur le nom (givenname) ou soit sur le nom et prénom(common Name(CN)). A la fin de la méthode de recherche, si elle a été fructueuse, je récupère le DN du client qui a tenté de se connecter pour effectuer la connexion avec son mot de passe. C est la méthode connectuser(string login, String pwd) qui gère cette connexion. Elle ne diffère pas de la partie connexion de la méthode de rechercher. Le seul changement est dans l identification : les DN et mot de passe rentrés ne sont plus ceux de l administrateur de l annuaire, mais ceux du client qui tente de s authentifier. J ai présenté ma solution lors d une réunion avec mon maître de stage. Suite à celle-ci, elle m a demandé de voir dans quelle mesure je pouvais adapter ce que j avais fait avec JNDI à l authentification avec JAAS. Ayant approfondi mes recherches sur JAAS, je me suis rendu compte que cet framework, bien que moins simple que JNDI, avait un niveau de sécurité plus élevé. JAAS a la particularité de séparer la gestion des droits d accès aux composants J2EE du code métier. Le fonctionnement de JAAS se fait en deux temps : authentification c est-à-dire validation de l identité du client, puis autorisation. De plus, grâce à «LoginModule», JAAS implémente plusieurs algorithmes qui réalisent l authentification selon un mécanisme bien choisi tel que JndiLoginModule. Ce dernier réalise l authentification à travers un service d annuaire configuré sous JNDI. Je pouvais donc adapter ce que j avais fait avec JNDI. La mise en œuvre de cette solution a nécessité trois classes : - la classe LdapCallBackHandler qui implémente l interface CallbackHandler. Cette interface gère les callbacks (demande d informations telle que le login et le mot de passe) ; 1 Voir Annexe A. De même que pour SN, givenname et CN. 18

19 - la classe LdapModule qui implémente l interface LoginModule. C est une interface du composant d authentification, implémentée par le fournisseur d authentification ; - et enfin, la classe LdapPrincipal qui implémente l interface Principal. Un principal représente l identité du demandeur de connexion. D autres classes interviennent dans la mise en œuvre de JAAS. Il s agit de : - Subject : représente le demandeur. Il peut avoir plusieurs identités ou principals. - LoginContext : avec méthode «login()», elle exploite les modules décrites dans la configuration de JAAS. - Callback : interface de demande d'information (login, password). JAAS utilise un fichier de configuration «.config» qui a une certaine syntaxe et où sont spécifié toutes les options dont a besoin le LoginModule de se mettre en place. Cette syntaxe est la suivante : Name { }; Name { ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleOptions; ModuleOptions; ModuleOptions; ModuleOptions; ModuleOptions; }; Le ModuleClass est le nom de la classe qui implémente LoginModule. Les flags permettent de spécifier la façon dont se fera l authentification en cas d échec ou de succès du LoginModule. Ce sont : «required», «requisite», «sufficient» ou «optional». Leur définition est donnée en annexe D. ModuleOptions sont les différentes options de connexion. Dans notre cas il s agit du nom du serveur LDAP, le login/mot de passe de l administrateur pour la recherche, les clés de recherche Le fichier de configuration que j ai utilisé pour la connexion est donné en annexe D. Pour les tests, j ai utilisé l annuaire LDAP de la Interview, ainsi que les différents annuaires publiques que j ai trouvé sur Internet. Les tests devaient portés sur tous les cas possibles. De ce fait, utiliser une méthode «main» pour les tests était inutile. De plus, il me fallait écrire des tests tels que si il y avait une modification de mon code dans le futur, ils attesteraient toujours le bon fonctionnement de l application. Il m a alors été suggérer d utiliser les tests unitaires JUnit 1. Ma classe de test contient quatre tests qui gère la tentative de connexion avec soit le nom, soit le prénom, soit le nom prénom ; un test pour la gestion d un client qui n est dans aucun annuaire LDAP spécifié ; un test avec un mot de passe incorrect. Pour la connexion, je crée un LoginContext ayant pour paramètres le nom du module où il faudra aller chercher les informations de connexion ainsi que les login et mot de passe de l utilisateur. Ces derniers sont les paramètres du LdapCallBackHandler. Puis je lance la méthode login(). Après une mise au point avec mon maître de stage, cette solution a été adoptée puis remontée sur le serveur SVN 2 de la société. Elle sera utilisée plus tard sur les produits Interview. 1 Voir paragraphe sur les compétences acquises. 2 SVN ou Subversion est un logiciel de gestion des versions. Un serveur SVN permet de sauvegarder un code, de récupérer une version ancienne si la nouvelle présente des erreurs et de partager un projet. 19

20 3. Cryptage du mot de passe en base de données Actuellement, les mots de passe de la base de données sont écrits en dur et non cryptés. La mission qui m a été confié alors est de trouver et de mettre en place une méthode de cryptage qui réponde aux spécifications suivantes : - cryptage du mot de passe doit se faire en une fois car il sera mis en dur en base de données ; - si un utilisateur perd son mot de passe et demande à le récupérer, l application doit être capable de renvoyer le mot de passe initiale en décryptant celui qui se trouve dans la base de données. Cette deuxième spécification écarte la méthode de cryptage avec une fonction de hachage (md5, sha) qui, bien que très sécurisant, est à sens unique. La solution est donc d utiliser un crypto système à clé publique. Le fonctionnement global de ce dernier est résumé sur le schéma suivant : Figure 5 1 : Cryptographie à clé publique La méthode de chiffrement à clé publique RSA est la solution qui a été choisie et implémentée. La raison de ce choix est, en plus du fait que c est un crypto système que je connais bien( l ayant étudié en cours), Java possède des paquetages qui facilitent sa mise en place. Il s agit des paquetages java.security et java.security.interfaces. Ces derniers fournissent les classes et interfaces suivants : - KeyPairGenerator qui gère la génération de paire de clé publique et clé privée ; - SecureRandom qui fournit un générateur de nombre aléatoire très fort du point de vue de la cryptographie ; - KeyPair qui est un simple conteneur de paire de clé publique/privée ; - RSAPrivateKey et RSAPublicKey. Le code écrit pour la mise en place de cette solution est constitué des deux méthodes cryptermessage(string message) et decryptermessage(string messcrypte). Leur principe est le suivant : - «Bob veut envoyer à Alice le message M. Il utilise la clé publique représenté par le couple (n, e) pour coder le message. n = p*q, avec p et q deux entiers premiers très grands. e = 1/d mod((p-1)(q-1)) avec d un nombre premier avec (p-1)*(q-1). Bob fait alors le calcul c = M exp(e) mod(n).» 1 Source 20

21 L'entrée pour le cryptage est une chaîne de caractères. Cette entrée ou message est transformée en suite d'octets correspondants. Cette transformation va nous permettre de manipuler notre message comme une suite de nombre et ainsi faire les différents calculs pour le chiffrement. Puis on les transforme en BigInteger. La particularité de BigInteger par rapport à Integer est que en plus de toutes les opérations que fournit Integer, il peut faire des calculs de modulo grâce à la méthode modpow(biginteger exponent,biginteger m) this(exponent)mod m. - «Pour décrypter le message, Alice utilisera sa clé privé qui est représenté par le couple (p,q,d) pour faire le calcul M = c exp(d)mod(n).» Le projet, de type projet MAVEN, a été remonté sur le serveur SVN. Puis je l ai mis en dépendance du projet Common-Core existant et j ai surchargé en local la classe CompteUtilisateur. Dans un premier temps, l application a été testée sur une base de donnée en mémoire. C est une base de données créée en mémoire de toutes pièces puis détruite quand les tests sont terminés Ensuite, pour pouvoir voir effectivement comment se passe le cryptage/décryptage, les test ont été effectués sur base de données réelle. II. Les apports du stage 1. Compétences Techniques Acquises 1.1. JUnit Comme spécifié plus haut, pour pouvoir faire les test de mes applications, j ai écrit des tests unitaires en utilisant JUnit. C est une bibliothèque qui est intégrée par défaut dans les environnements de programmation Java tels que Eclipse et Netbeans. L écriture des tests unitaires est très importante. Ils ont pour but de valider ou invalider l application mise en place. De ce fait, leur écriture requiert un certain temps et une grande attention Maven Pour la remontée de mes projets, il m a été suggéré d en faire des applications MAVEN. Maven est un outil logiciel libre pour la gestion et l automatisation de production des projets logiciels Java en générale et Java EE en particulier. Maven impose une arborescence et un nommage des fichiers selon le concept de convention plutôt que configuration. Ces conventions permettent de réduire la configuration des projets. Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de décrire un projet logiciel, ses dépendances avec des modules externes et l ordre à suivre pour sa production. C est ce fichier que j ai modifié pour créer la dépendance avec le projet Common-core. Un exemple de fichier «pom.xml» est donné en annexe E. 21

22 2. Problèmes Rencontrés& Solutions Apportées 2.1. Protocole DKIM Comme dit plus haut, l objectif de cette étude était de savoir dans quelle mesure le protocole DKIM améliorerait la délivrabilité des mails de diffusion de Interview. Et l une de ses étapes était de me renseigner auprès des Fournisseurs d Accès Internet (FAI) s ils utilisaient ce protocole. Cette tâche a été difficile dans la mesure où je n avais pas de moyens de contacter directement ces dernières. La solution à ce problème m a été donnée par le administrateur systèmes de réseau. D après lui, chaque FAIs possèdent un service «abuse» dont l adresse est de la forme «abuse@nom_fai».je pouvais donc envoyer des mails, qui seront forcément considérés comme spams, via ce service au FAIs. Sur les quatre FAIs que j ai contacté par ce biais, deux fois par jour pendant une semaine, je n ai reçu qu une seule réponse Cryptage de mot de passe Le problème qui s est posé avec la solution choisie est que à chaque fois qu on lance l application, il y avait génération d une nouvelle clé. De ce fait, le codage est différent à chaque fois. Or, les mots de passe cryptés seront en «dur» dans la base de données et donc si la clé de cryptage change pour une raison quelconque telle le «reboot» de l application, il sera difficile de restituer le mot de passe non crypté. Pour résoudre ce problème, j ai enregistré dans un fichier «.properties» toutes les données dont on a besoin pour le cryptage/décryptage (module, clé privée et clé publique). Ce fichier est créé lors du premier lancement de l application à un endroit précis sur disque. Et donc, si l application est relancée, elle vérifie si oui ou non ce fichier existe déjà. Si oui, elle ne génère pas d autres clés. Sinon, elle crée le fichier avec les clés. Cependant, il n est pas sécurisant d avoir un fichier de configuration qui contient des informations aussi importantes. Pour y remédier, les clé publique, clé privée et module ont été ajoutés en «dur» dans le code. Plus tard, lors des tests, avec la première version de l application, je me suis rendu compte que lorsqu il s agissait des caractères non alphanumériques, le test de décryptage était faux. Le problème se situait au moment de la transformation du mot de passe de suite d octets en BigInteger. En effet, les caractères non alphanumériques ont une valeur négative (en octects) et donc la transformation inverse (BigInteger -> suite d octets) rendait le mot de passe obtenu différent de celui initial. Pour y remédier, après avoir transformé le mot de passe en tableau d octets de taille t, je le mettais dans un tableau de taille t+1. A l indice 0 de ce tableau j ai inséré un octet de valeur 1(en bit : ). De ce fait, la valeur contenue dans le tableau est forcément positive. Lors du décryptage, j enlève cet octet avant de restituer le mot de passe. 22

23 3. La vie dans la société Comme je l ai spécifié au début dans le rapport, les équipes Java et Notes du département Dev-Produits sont chacun dans deux bureaux différents. Cela facilite les interactions entre les membres de l équipe qui utilise le même langage de programmation. Cependant, cette mise en commun présente des inconvénients. En effet, il peut arriver que des membres de l équipe aient des divergences d opinions peuvent donner lieu à des disputes. Cela crée au sein du bureau une certaine tension qui peut être un frein dans l évolution du projet. Ou encore, lorsque un des membres de l équipe pose le problème qu il rencontre au reste du groupe, la discussion qu il a avec celui qui l aide peut faire perdre leur concentration aux autres. La méthode de management adoptée au sein de Interview fait en sorte que les bureaux sont assez ouverts. De ce fait, si quelqu un a une question sur un sujet quelconque pour une personne dans un autre bureau que le sien, il peut y aller la poser directement. Seulement, ces interruptions peuvent faire perdre le fil dans le travail qu effectuait la personne questionnée. Il existe à Interview un espace désignée pour le repas de midi. L avantage de cet espace est que cela facilite la rencontre avec les membres de la société qui sont dans d autres départements. Il est alors possible de s enquérir de la santé des uns, de l évolution des projets des autres. Ils peuvent aussi, pour la détente, jouer à des jeux vidéo ou des jeux de société. Cela permet de tisser des liens entre les employés et donc de rendre plus chaleureuse l atmosphère de la société. La société Interview offre à ses employés la possibilité d avoir des formations sur un domaine qu ils ne maîtrisent pas encore. Ces formations ne durent rarement plus d une semaine. En effet, bien que profitables aux employés et par extension à l entreprise, elles coûtent assez chères à cette dernière : il faut payer le formateur et les employés pendant la formation ne sont pas productifs pour l entreprise. Cependant, c est une connaissance nouvelle qu acquièrent les employés de l entreprise qui est un plus dans le bon déroulement des projets dont ils sont responsables. 23

24 Conclusion Pendant le déroulement de mon stage, j ai eu l opportunité de travailler au sein d une équipe, l équipe Java du département Dev-Produits. Cela a été m a permis d avoir une vision détaillée de la façon dont sont gérés les projets. Le travail réalisé s est avéré être très enrichissant pour expérience professionnelle. De plus, le fait de travailler sur des missions traitant sur la sécurité m a permis de savoir ce que j aimerais faire plus tard en tant que ingénieur. En effet, la première partie de mon stage, c est-à-dire l étude du protocole DKIM, m a permis de comprendre le trajet parcouru par le courrier électronique et tous les moyens de sécurité mis en place pour éviter que ce dernier soit «voler» ou changer. Dans la deuxième partie, l authentification LDAP, j ai pu apprendre comment fonctionne un annuaire LDAP ainsi que comment gérer les informations qu elle contient pour une authentification. Le cryptage du mot de passe m a surtout amené à mettre en pratique les connaissances que j avais reçues de ma formation sur les méthodes de chiffrement. Le fait de travailler dans au milieu des membres d une équipe et surtout dans une entreprise telle que Interview, m a permis de voir les différentes interactions qui existent au sein d un groupe de travail. 24

25 Bibliographie/Webographie Ouvrages Marcel RIZCALLAH, Annuaires LDAP, 2 e édition, Eyrolles, Paris, Notes de cours Sites Web [Interview] [EFM] [DKIM] [LDAP] File [Cryptographie] Documents rédigés - Edwige Prisca KOM MBIENGANG, Etude du protocole DKIM, version 1, 25 pages, français, juillet Edwige Prisca KOM MBIENGANG, Cryptage du mot de passe, version 1, 4 pages, français, août

26 Table des figures Figure 1 : Organigramme Interview S.A. (juillet 2010).. 9 Figure 2 : La plateforme EFM interview?! Figure 3 : Etapes d acheminement de courrier électronique 13 Figure 4 : Service d authentification auprès des produits Interview

27 ANNEXES 27

28 Sommaire Annexe A : Glossaire/ Lexicographie 29 Annexe B : Baromètre de L EFM.. 30 Annexe C : Eléments du protocole DKIM. 31 Annexe D : Exemple de fichier de configuration de JAAS. 36 Annexe E : Exemple de fichier pom.xml 37 Annexe F : Gestion des projets : digrammes de Gantt

29 ANNEXE A : Glossaire/ Lexicographie BPM 1 : Bussiness Process Management. Littéralement, la traduction donne «gestion des processus métiers». C est une approche consistant à modéliser informatiquement les processus métiers de l entreprise, aussi bien dans leur aspect applicatif qu humain. CRM 2 : Customer Relationship Management. En français, on parle de «gestion de la relation client». Cela consiste à savoir cibler, à attirer et à conserver les bons clients et représente un facteur déterminant du succès de l entreprise. CRLF 3 : Carriage Return Line Feed. C est une séquence de deux octets qui indique une fin de la ligne dans un texte. Le sigle CRLF provient de la juxtaposition du sigle de Carriage Return (retour chariot) et de Line Feed (saut de ligne). Common Name ou CN : c est un attribut utilisateur du standard LDAP. Il représente nom de la personne dans l annuaire LDAP. DistinguishedName ou DN 4 : c est aussi un attribut utilisateur. C est moyen d'identifier de façon unique un objet dans la hiérarchie. Un DN se construit en prenant le nom relatif de l'élément (RDN - Relative Distinguished Name), et en lui ajoutant l'ensemble des noms relatifs des entrées parentes. Le DN d'un élément est donc la concaténation de l'ensemble des RDN de ses ascendants hiérarchiques. DNS : Domain Name System ou système de noms de domaine. C est un service permettant d'établir une correspondance entre une adresse IP et un nom de domaine. Il est considéré comme un annuaire électronique. givenname : c est le prénom de la personne dans l annuaire LDAP. MUA : Mail User Agent ou client de messagerie ; MTA : Mail Tranfer Agent. Il se charge du tranfert du message électronique vers le MTA correspondant au domaine du destinataire. MDA : Mail Delivery Agent. Il est responsable de la mise dans la boîte de reception du message. MSA : Mail Sécurity Agent. POP (Post Office Protocole, «le protocole du bureau de poste»), et IMAP (Internet Message Access Protocole): ce sont des protocoles qui permettent de récupérer les courriers électroniques situés sur un serveur de messagerie électronique pour la lecture. SMTP (Simple Mail Transfert Protocol, «Protocole simple de transfert de courrier») : c est un protocole de communication utilisé pour transférer le courrier électronique vers les serveurs de messagerie électronique Spams : pourriel ou polluriel est une communication électronique non sollicitée, en premier lieu via le courrier électronique USSD: Unstructured Supplementary Service Data. Il peut être traduit en «Données de Service Supplémentaires Peu Structurées». Il s'agit d'une fonctionnalité des téléphones GSM. Il est généralement associé aux services de téléphonie de type temps réel ou de messagerie instantanée. 1 Source 2 Source 3 Source 4 Source 29

30 ANNEXE B : Baromètre de l EFM En publiant, à partir de 2009, un baromètre annuel de l EFM en France, Grimmersoft voulait tout à la fois mesurer concrètement le niveau d attente du marché et partager les résultats avec celui-ci afin de jouer leur rôle d acteur majeur du secteur. Les résultats les plus pertinents pour le marché de l EFM sont les suivants : Ces résultats montrent que l EFM a un grand avenir devant lui. 30

31 ANNEXE C : Eléments du protocole DKIM Les éléments du protocole sont les parties conceptuelles du protocole qui ne sont spécifiques ni aux vérificateurs, ni aux signataires. 1. Sélecteurs Un sélecteur est une subdivision du namespace. Les sélecteurs sont utilisés pour permettre des clés multiples sous le nom de domaine de la même organisation. Le sélecteur est précisé comme attribut de la signature DKIM et est enregistré dans un des champ de l entête DKIM-Signature. La phase de validation (ou encore de vérification) utilise le sélecteur pour la mise en place de la requête DNS pour la récupération de la clé publique de ma signature, DNS DKIM query. Il existe différents enregistrements DNS de DKIM correspondant à différents sélecteurs. Par exemple brisbane._domainkey.example.com : le sélecteur ici est brisbane. 2. Clé = liste de valeurs Le protocole DKIM utilise la syntaxe «tag=value» dans plusieurs contextes, y compris dans les messages et les rapports de signature de domaine. Les valeurs sont une série de chaînes de caractères écrits selon le codage «base64», ou encore «Quoted-printable» (voir annexe). Le nom de la balise permet de déterminer le codage de chaque valeur. Le caractères «;» ne doit pas apparaître dans la liste des valeurs d une étiquette car ils séparent les «tagspecs». Les règles de la syntaxe «tag=value» sont les suivantes : tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-name = ALPHA 0*ALNUMPUNC tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] ; WSP and FWS prohibited at beginning and end tval VALCHAR = 1*VALCHAR = %x21-3a / %x3c-7e ; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / "_" Exemple : «DKIM-Signature: v=1; a=rsa-sha256; s=brisbane;» Notons que WSP est autorisé n importe où autour des balises (au tout du = ) et avant le ;. Ce n est pas une partie de la valeur de la balise. Cependant, les «whitespaces» dans le champ de la valeur à une signification importante. 31

32 Les étiquettes DOIVENT être interprétées comme étant sensible à la casse. Les valeurs DOIVENT être traité comme étant sensible à la casse, à moins que la description d'étiquette spécifique spécifie l insensibilité à la casse. Il ne peut y avoir deux étiquettes de mêmes noms. Auquel cas, la liste des étiquettes «tag-list» devient invalide. Les «whitespaces» entre les valeurs doivent être pris en compte même s ils sont explicitement exclus par la description spécifique de la balise. Les paires «tag=value» qui représentent la valeur par défaut peuvent être inclus pour aider la lisibilité. Les étiquettes non reconnus DOIVENT être ignorés. Les étiquettes n ayant aucune valeur ne sont pas considérés comme des étiquettes omises. Les étiquettes omises sont considérées comme ayant une valeur par défaut. Par exemple «g=» ne signifie pas «g=*», même si «g=*» est la paire par défaut de cette balise. La signification de chaque champ dans la signature DKIM est la suivante : v = la version de référence DKIM. La version doit avoir pour valeur «1». a = l algorithme utilisé pour générer la signature. Il est en texte brut et obligatoire. (dans l exemple en dessous, l algorithme utilisé r=est rsa-sha-256.) s = le sélecteur ( brisbane dans l exemple) d = domaine de l entité qui signe le message. C est une information capitale car elle est utilisée pour construire la requête DNS de recherche de clé publique nécessaire à la vérification de la signature. c = algorithme de canonisation. Dans l exemple, pour l entête et le corps du message, on a utilisé le «simple» algorithme. q = liste de méthodes de requêtes utilisées pour récupérer la clé publique de la signature. Il est en texte brut, optionnel et par défaut a la valeur «dns/txt» (comme dans l exemple) i = identité de l utilisateur ou de l agent chargé de signer le message. Il est optionnel. Par défaut, il est constitué d un «@» suivi du nom de même nom de domaine que dans la tag «d=» h = liste des entêtes du message qui sont inclus lors du calcul de la signature du message bh = le hachage de la partie du corps du message canonisé limité par la valeur du tag «l=». Il est écrit en base64 et obligatoire. Les «whitespaces» sont ignorés dans sa valeur et doivent être ignoré lors du remontage à l original de la signature. En particulier, le processus de signature peut insérer des FWS dans cette valeur et à n importe quel endroit pour se conformer à la longueur limite de ligne. b= c est la signature du message. Il est en base64 et obligatoire.les WSP sont gérés de la même façon que précédemment. l = longueur du corps du texte. Il est optionnel et par défaut sa valeur est la longueur du corps du message en entier. Sa valeur est un nombre décimal non signé en texte brut. Il existe d autres champs qui sont moins répandus et optionnels : t = c est l heure à laquelle la signature a été faite. Sa valeur est le nombre de seconde depuis 00 :00 :00 du 1 er janvier 1970 dans le fuseau horaire UTC (Temps Universel Coordoné). C est un entier décimal non signé. x = date d expiration de la signature. Même format que celui de l étiquette «t=» 32

33 z = représente le liste des entêtes présentes lors de la signature, séparées par des barres verticales. Il est différent de du champs «h=» car en plus du champs de l entête, on a aussi sa valeur. Il est vide par défaut. 3. Algorithmes de signature et de vérifications DKIM supporte plusieurs algorithmes de signature électronique. Mais deux algorithmes sont en ce moment définis dans le cahier de charge: rsa-sha1 et rsa-sha256. Les validateurs (ou vérificateurs) DOIVENT implémenter les deux algorithmes. Les signataires doivent appliquer et devrait signer utilisant rsa-sha256. RSA est un crypto système à clé publique pour le chiffrement et l authentification. Remarque : Bien qu on encourage les signataires à utiliser l algorithme rsa-sha256, certains émetteurs de messages de sécurité faible préfère utiliser sha1 en raison de ses faibles exigences en CPU pour le calcul de la fonction de hachage. 3.1 L algorithme de signature RSA-SHA1 Pour cette algorithme, la crypto système RSA a été combiné l algorithme de hachage sécurisé SHA-1 (Secure Hash Algorithm) pour signer un message. En d autres termes, cet algorithme permet le calcul de la fonction de hachage correspondant à un message en utilisant SHA-1, puis le signataire signe cette fonction en utilisant RSA (définit dans PKCS#1 version 1.5 [RFC3447]) comme algorithme de cryptage et comme clé privée du signataire. La fonction de hachage ne doit pas être tronqué ou converti sous toute autre forme que la forme binaire native avant d'être signé. L algorithme de signature doit utiliser un exposant public de Les fonctions de hachage SHA1 ont la particularité que la recherche d une éventuelle équivalence est impossible. Il est donc considéré comme convenable. SHA-1 a été conçu par le National Secure Agency (NSA) des Etats-Unis et publié comme standard fédéral de traitement de l information (Federal Information Processing standard du National Institute of Standards and Technology (NIST)) par le gouvernement des Etats-Unis. Il est le successeur de SHA-0 qui a été rapidement mis de côté par NIST pour des raisons de sécurité insuffisante. Ce dernier était contiendrait des failles qui permettraient d aboutir à des collisions du type deux documents différents qui génèrent le même condensat. Le condensa ou hash est le résultat de l algorithme SHA. Sa taille est de 160 bits. Le fonctionnement de l algorithme SHA1 est le suivant : Le SHA-1 prend un message d'un maximum de 2 64 bits en entrée. Quatre fonctions booléennes sont définies et prennent 3 mots de 32 bits en entrée et calculent un mot de 32 bits. Une fonction spécifique de rotation est également disponible et permet de déplacer les bits vers la gauche (le mouvement est circulaire et les bits reviennent à droite). Le SHA-1 commence par ajouter à la fin du message un bit à 1 suivi d'une série de bits à 0, puis la longueur du message initial (en bits) codée sur 64 bits. La série de 0 a une longueur telle que la séquence ainsi prolongée a une longueur multiple de 512 bits. L'algorithme travaille ensuite successivement sur des blocs de 512 bits. 33

34 Pour chaque bloc de 512 octets, l'algorithme calcule 80 tours (ou rondes, «rounds» en anglais) successifs et applique une série de transformations sur l'entrée. La première étape consiste à calculer 80 valeurs sur 32 bits. Les 16 premières valeurs sont obtenues directement à partir du bloc «message» en entrée. Les 64 autres sont calculées successivement. Le SHA-1 les obtient grâce à une rotation (absente dans SHA-0) qui est appliquée sur le résultat d'un XOR. Il utilise pour cela 4 mots obtenus dans les itérations précédentes. On définit ensuite 5 variables qui sont initialisées avec des constantes (spécifiées par le standard), le SHA-1 utilise encore 4 autres constantes dans ses calculs. Si un bloc de 512 bits a déjà été calculé auparavant, les variables sont initialisées avec les valeurs obtenues à la fin du calcul sur le bloc précédent. Il s'ensuit 80 tours qui alternent des rotations, des additions entre les variables et les constantes. Selon le numéro du tour, le SHA-1 utilise une des quatre fonctions booléennes. L'une de ces fonctions est appliquée sur 3 des 5 variables disponibles. Les variables sont mises à jour pour le tour suivant grâce à des permutations et une rotation. En résumé, le SHA-1 change sa méthode de calcul tous les 20 tours et utilise les sorties des tours précédents. À la fin des 80 tours, on additionne le résultat avec le vecteur initial (message initial). Lorsque tous les blocs ont été traités, les cinq variables concaténées (5 32 = 160 bits) représentent la signature. Figure 1 : Une itération de SHA-1 avec deux rotations «<<< n» vers la gauche de n bits (n varie pour chaque opération», et une fonction non linéaire «F» qui dépend du numéro d'itération. Deux variables, Wt (message étendu au tour t) et Kt (constante de tout au tour t), interviennent à chaque tour. Dénote une addition modulo L algorithme de signature RSA-SHA256 Dans cet algorithme, l algorithme de calcul de la fonction de hachage est SHA-256. SHA-256 a été publié en 2000 par le NSA. Son résultat (condensa ou hash) a une longueur de 256 bits. SHA-256 dérive du SHA-1. Très proche du SHA-1 dont il est issu, SHA-256 en diffère par la longueur du résultat obtenu mais aussi par certaines opérations, fonctions et constantes spécifiques qui amènent ce résultat. Celles-ci sont structurées sur le même modèle que SHA-1 (prétraitement et calcul) mais le travail s'effectue en 64 rondes avec 8 variables initialisées avec des constantes spécifiques. Les fonctions booléennes utilisées sont différentes de SHA-1. 34

35 A la fin des 64 tours les huit variables concaténées forment le résultat. Les figures suivantes permettent d illustrer son fonctionnement : Figure 2 : Diagramme de la structure d une itération de la fonction de hachage (Diagram of the iterated hash function structure.) A Cryptographic Compendium par John Savard. Figure 3: Diagramme fonction de compression (Diagram of the compression function.) A Cryptographic Compendium par John Savard. 35

36 Annexe D : Exemple de fichier de configuration de JAAS Ldap { com.interview.ldap.auth.module.ldapmodule sufficient nomldap="interview" debug="true" LoginAdmin="cn=DevProduits" PasswordAdmin="Interview?!" LdapServer="ldap://silex.123interview.com" LdapPort="389" authmode = "simple" SearchKeys="CN;SN;givenName" LdapBase="OU=Utilisateurs,OU=Interview,DC=123interview,DC=com"; com.interview.ldap.auth.module.ldapmodule optional nomldap="trust" debug="true" LoginAdmin="" PasswordAdmin="" LdapServer="ldap://directory.d-trust.de" LdapPort="389" authmode = "none" SearchKeys="CN;SN;givenName" LdapBase="c=de"; }; Dans l écriture du fichier de configuration JAAS, la ligne en gras est la plus importante. Cette ligne indique la classe qui impémente loginmodule qu il faut chercher pour effectuer la connexion à l annuaire LDAP. Il est toujours suivi de flags qui permettent de spécifier la façon dont se fera l authentification en cas d échec ou de succès du LoginModule. Ce sont : «required», «requisite», «sufficient» ou «optional». Leur signification 1 est la suivante : 1) Required : le succès du LoginModule est requis. Cependant, même s il y a succès ou échec, l authentification continuera avec les autres LoginModule de la liste. 2) Requisite : le succès du LoginModule est requis. S il il réussi, l authentification continue avec les autres loginmodule présents. Dans le cas contraire, l authentification s arrête là. 3) Sufficient : le succès du LoginModule n est pas requis. Si l authentification est un succès, alors la main est retournée immédiatement à l application (l authentification ne continue pas avec la liste des loginmodule qui sont en dessous). Par contre, si l authentification échoue avec ce premier loginmodule, elle continue avec ceux en dessous. 4) Optional - le succès du LoginModule n est pas requis. Qu il y ai succès ou échec, l authentification continuera avec les autres LoginModule de la liste. 1 Source 36

37 Annexe E : Exemple de fichier «pom.xml» Le coeur d'un projet Maven 2 est le modèle objet projet (appelé POM pour «Project Object Model). Il contient une description détaillée de votre projet, avec en particulier des informations concernant le versionnage et la gestion des configurations, les dépendances, les ressources de l'application, les tests, les membres de l'équipe, la structure et bien plus encore. Le POM prend la forme d'un fichier XML (pom.xml) qui est placé dans le répertoire de base de votre projet. Le fichier POM que j ai utilisé pour le projet de cryptographie est le suivant : project xmlns= mlns:xsi= si:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>com.interview</groupid> <artifactid>crypto</artifactid> <packaging>jar</packaging> <version>1.0-snapshot</version> <name>crypto</name> <url> <build> <plugins> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-compiler-plugin</artifactid> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> <encoding>${project.build.sourceencoding}</encoding> </configuration> </plugin> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-resources-plugin</artifactid> <version>2.2</version> <configuration> <encoding>${project.build.sourceencoding}</encoding> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>4.4</version> <scope>test</scope> </dependency> 37

38 <dependency> <groupid>org.jasypt</groupid> <artifactid>jasypt</artifactid> <version>1.6</version> <type>jar</type> </dependency> <dependency> <groupid>com.interview</groupid> <artifactid>efmcommon-core</artifactid> <version>2-snapshot</version> <type>jar</type> </dependency> <dependency> <groupid>org.springframework</groupid> <artifactid>spring-test</artifactid> <version>2.5.6</version> <scope>test</scope> <type>jar</type> </dependency> <dependency> <groupid>org.hsqldb</groupid> <artifactid>hsqldb</artifactid> <version>2.0.0</version> <scope>test</scope> </dependency> </dependencies> <properties> <project.build.sourceencoding>utf-8</project.build.sourceencoding> </properties> </project> Notons que les différentes dépendances de mon projet sont notées les unes après les autres dans la section «dépendencies». Les lignes que j ai ajoutées pour pouvoir mettre mon projet en dépendance du Common-core et faire des tests sur une base de données en mémoires sont celles en gras. 38

39 Annexe F : Gestion des projets : digrammes de Gantt Diagramme de Gantt pour l étude du protocole DKIM Digramme de Gantt pour la mise en place de la couche d authentification par LDAP 39

40 Tableau des Révisions Version Date de début Date de fin Ajout 0 22/06/ /07/2010 Etude du protocole DKIM 1 08/07/ /08/2010 (Après changement du sujet de stage) Ecriture du squelette du rapport. Authentification par LDAP Cryptographie Mise en page. 40