AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE

Transcription

EDWIGE PRISCA KOM MBIENGANG
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 2009-2010
4ème année RICM
2
Année 2009-2010
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.
4ème année RICM
3
Année 2009-2010
Table des matières
Remerciements ………………………………………………………………………
Résumé ………………………………………………………………………………..
Introduction …………………………………………………………………………..
1ère Partie : Cadre du stage
I.
3
5
6
L’ « Enterprise Feedback Management » (E.F.M.), la nouvelle
méthode d’enquêtes
1. Présentation …………………………………………………………
2. Une dénomination peu connue… …………………………………...
3. …mais un concept jugé utile ……………………………………….
II.
7
7
8
Interview ?! S.A., précurseur sur le marché de l’EFM
1. La petite histoire ……………………………………………………
2. Interview S.A. aujourd’hui
2.1. Organisation sociale de l’entreprise ………………………….
2.2. Partenaires et clients …………………………………………..
2.3. Solutions EFM proposées ……………………………………..
3. Le département produits …………………………………………...
8
9
10
10
11
2ème Partie : Les missions et les apports du stage
I.
Les missions
1. Le protocole DomainKeys Indentified Mail (DKIM) ………………
2. Authentification avec Lightweight Directory Access Protocol (LDAP)
3. Cryptage de mot de passe ……………………………………………
II.
12
16
20
Les apports du stage
1. Compétences Techniques Acquises …………………………………
2. Problèmes Rencontrés& Solutions Apportées ……………………...
3. La vie dans la société ……………………………………………….
Conclusion …………………………………………………………………………..
Bibliographie/Webographie …………………………………………………….
Documents rédigés ………………………………………………………………...
Table des figures …………………………………………………………………...
Annexes ………………………………………………………………………………
Tableau des révisions ………………………………………………………………
4ème année RICM
21
22
23
24
25
25
26
27
39
4
Année 2009-2010
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.
4ème année RICM
5
Année 2009-2010
Introduction
J’ai effectué mon stage au sein de la société Interview S.A. situé au 2 Avenue de l’Obiou,
38700 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.
4ème année RICM
6
Année 2009-2010
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 CRM1 (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
4ème année RICM
7
Année 2009-2010
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 Marketor1 via un
questionnaire en ligne administré entre le 15 mars et le 15 mai 2009. 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 GrimmerSoft2 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 MarketingEtudes) 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
2
Marketor est une société créée en 2005 et spécialisée dans les études sur le secteur IT.
Quelques résultats du baromètre sont donnés en Annexe B
4ème année RICM
8
Année 2009-2010
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, USSD1 (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
4ème année RICM
9
Année 2009-2010
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).
2.2. 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é BPM1 : 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.
2.3. 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 email, 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
4ème année RICM
10
Année 2009-2010
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 21 : 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 http://www.interview-efm.fr/efm/easysite/fr/interview-sa
4ème année RICM
11
Année 2009-2010
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 spams1. 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
2004. 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 email 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
4ème année RICM
12
Année 2009-2010
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
SMTP2 (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 suivant3 :
1. L’utilisateur compose le message
From: Joe SixPack <[email protected]>
To: Suzie Q <[email protected]>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <[email protected]>
Hi.
We lost the game. Are you hungry yet?
Joe.
1
Source http://fr.wikipedia.org/wiki/Fichier:Etapes_envoi_email.png
Voir Annexe A. De même pour IMAP et POP
3
Source : Annexe a du RFC 4871
2
4ème année RICM
13
Année 2009-2010
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 [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Hi.
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
4ème année RICM
14
Année 2009-2010
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 (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (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 [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Hi.
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.
4ème année RICM
15
Année 2009-2010
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é.
4ème année RICM
16
Année 2009-2010
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 JXplorer1 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 framework2 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).
4ème année RICM
17
Année 2009-2010
i.
ii.
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 » ;
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 Name1 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.
4ème année RICM
18
Année 2009-2010
-
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 {
ModuleClass
ModuleClass
ModuleClass
Flag
Flag
Flag
ModuleOptions;
ModuleOptions;
ModuleOptions;
ModuleClass
ModuleClass
Flag
Flag
ModuleOptions;
ModuleOptions;
};
Name {
};
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 JUnit1.
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 SVN2 de la société. Elle sera utilisée plus tard sur les produits
Interview.
1
Voir paragraphe sur les compétences acquises.
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.
2
4ème année RICM
19
Année 2009-2010
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 51: 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 http://laurent.flaum.free.fr/pgpintrofr-3.gif
4ème année RICM
20
Année 2009-2010
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.
1.2. 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.
4ème année RICM
21
Année 2009-2010
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.
2.2. 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 : 00000001). 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.
4ème année RICM
22
Année 2009-2010
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.
4ème année RICM
23
Année 2009-2010
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.
4ème année RICM
24
Année 2009-2010
Bibliographie/Webographie
Ouvrages
Marcel RIZCALLAH, Annuaires LDAP, 2e édition, Eyrolles, Paris, 2004.
Notes de cours
Sites Web
[Interview]
http://www.interview-efm.fr/efm/easysite/fr/interview-sa
[EFM]
http://www.fidelead.fr/L-Enterprise-Feedback-Management-la-nouvelle-methode-denquetes_a3149.html
http://www.itrmanager.com/articles/76031/enterprise-feedback-management-pourquoi-brjean-michel-franco-business-decision-fabien-souletie-conversoft.html
http://www.spss.com/software/data-collection/efm/
[DKIM]
http://www.dkim.org/
http://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail
http://fr.wikipedia.org/wiki/IETF
http://fr.wikipedia.org/wiki/SHA-1
[LDAP]
http://www.oracle.com/technetwork/indexes/downloads/index.html
http://downloadllnw.oracle.com/javase/1.5.0/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html#Config
File
http://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface
[Cryptographie]
http://fr.wikipedia.org/wiki/Cryptographie
Documents rédigés
-
Edwige Prisca KOM MBIENGANG, Etude du protocole DKIM, version 1, 25 pages,
français, juillet 2010.
Edwige Prisca KOM MBIENGANG, Cryptage du mot de passe, version 1, 4 pages,
français, août 2010.
4ème année RICM
25
Année 2009-2010
Table des figures
Figure 1 : Organigramme Interview S.A. (juillet 2010) …………………………..
Figure 2 : La plateforme EFM interview ?!..............................................................
Figure 3 : Etapes d’acheminement de courrier électronique ………………………
Figure 4 : Service d’authentification auprès des produits Interview ……………...
4ème année RICM
9
11
13
16
26
Année 2009-2010
ANNEXES
4ème année RICM
27
Année 2009-2010
Sommaire
Annexe A : Glossaire/ Lexicographie …………………………………
Annexe B : Baromètre de L’EFM ……………………………………..
Annexe C : Eléments du protocole DKIM …………………………….
Annexe D : Exemple de fichier de configuration de JAAS …………….
Annexe E : Exemple de fichier pom.xml ………………………………
Annexe F : Gestion des projets : digrammes de Gantt ………………….
4ème année RICM
29
30
31
36
37
39
28
Année 2009-2010
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.
CRLF3 : 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 http://www.commentcamarche.net/contents/entreprise/bpm.php3
Source http://fr.wikipedia.org/wiki/Gestion_de_la_relation_client
3
Source http://fr.wikipedia.org/wiki/Carriage_Return_Line_Feed
4
Source http://www.commentcamarche.net/contents/ldap/ldapnomm.php3
2
4ème année RICM
29
Année 2009-2010
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.
4ème année RICM
30
Année 2009-2010
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
tag-name
tag-value
= tag-spec 0*( ";" tag-spec ) [ ";" ]
= [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
= ALPHA 0*ALNUMPUNC
= [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval
= 1*VALCHAR
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.
4ème année RICM
31
Année 2009-2010
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 1er 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= »
4ème année RICM
32
Année 2009-2010
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 65537.
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 264 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.
4ème année RICM
33
Année 2009-2010
•
•
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 232.
3.2 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.
4ème année RICM
34
Année 2009-2010
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.
4ème année RICM
35
Année 2009-2010
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 signification1 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 http://download.oracle.com/javase/1.4.2/docs/api/javax/security/auth/login/Configuration.html
4ème année RICM
36
Année 2009-2010
Annexe
E:
« pom.xml »
Exemple
de
fichier
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=http://maven.apache.org/POM/4.0.0 mlns:xsi=http://www.w3.org/2001/XMLSchema-instance
si:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.interview</groupId>
<artifactId>Crypto</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Crypto</name>
<url>http://maven.apache.org</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>
<scope>test</scope>
</dependency>
4ème année RICM
37
Année 2009-2010
<dependency>
<groupId>org.jasypt</groupId>
<artifactId>jasypt</artifactId>
<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>
<scope>test</scope>
<type>jar</type>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<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.
4ème année RICM
38
Année 2009-2010
Annexe F : Gestion
digrammes de Gantt
des
projets :
Diagramme de Gantt pour l’étude du protocole DKIM
Digramme de Gantt pour la mise en place de la couche d’authentification par LDAP
4ème année RICM
39
Année 2009-2010
Tableau des Révisions
Version
0
Date de début
22/06/2010
Date de fin
08/07/2010
1
08/07/2010
26/08/2010
4ème année RICM
Ajout
Etude du protocole
DKIM
(Après changement
du sujet de stage)
Ecriture du squelette
du rapport.
Authentification par
LDAP
Cryptographie
Mise en page.
40
Année 2009-2010

AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE

Transcription

Documents pareils

ENNEMI PUBLIC :

Sommaire - Highlands Magazine

Script (Journal télévisé de 20h sur TF1, le 20 mai 2008

Informatisation Vitale, vos contacts à la CPAM de l`Aube

La Une de CQFD n°128 par Tardi.

Sommaire - Jeune Afrique

12 TChad La vengeance de Boko Haram 26 algérie

Sommaire - Highlands Magazine

Lire l`article - Edwige Bourdy

Biographies - Site de Maria