visualisation graphique des preuves Électroniques (complet)
DESCRIPTION
L’objectif principal de ce travail consiste à implémenter une solution Android pour la visualisation graphique des preuves électroniques à travers le QR code. Cette application permettra aux utilisateurs de générer une image QR contenant les informations clé d’un document électronique signé, et d’insérer cette image sur le document à imprimer afin qu’il puisse être utilisé comme pièce justificatives lors des démarches administratives. L’image QR pourra être décodée à l’aide d’un Smartphone muni d’un lecteur QR code.TRANSCRIPT
Visualisation Graphique des
Rédigé et pr
Dédicaces
« A Ma très chère Maman Mme NTSAMA Isabelle Caroline
Tous les mots du monde ne sauraient exprimer l’immense amour que
ni la profonde gratitude que
que tu as fourni, jamais tu n’as
être. C’est à travers tes encouragements que j’ai opté pour cette profession, et
c’est à travers tes critiques que je me suis réalisé.
espoirs que tu as fondé en moi.
guise de ma profonde reconnaissance et de mon infini amour. Que Dieu tout
puissant vous garde et te
demeuriez le flambeau illuminant le chemin de vos
« A Ma mère spirituelle la Rev
Qui n’a jamais cessé de me soutenir moralement, financièrement et
Du fond de mon cœur je te dis merc
continue de faire pour moi. Que le Seigneur dans sa grâce se souvi
« A Mon très cher oncle Oyono
Le mot « merci » est pour moi très insuf
pour moi durant tout mon parcours universitaire
combler au centuple dans toutes tes activités.
« A
Que ce modeste travail,
formuler dans vos prières.
pensée profonde à toi ma grande
Une pensée profonde à Toi
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Dédicaces
a très chère Maman Mme NTSAMA Isabelle Caroline
Tous les mots du monde ne sauraient exprimer l’immense amour que
ni la profonde gratitude que tu m’as témoigné pour tous les efforts et les
tu n’as cessé de consentir pour mon instruction et mon bien
encouragements que j’ai opté pour cette profession, et
s critiques que je me suis réalisé. J’espère avoir répondu aux
en moi. Je te rends hommage par ce modeste travail en
reconnaissance et de mon infini amour. Que Dieu tout
te procure santé, bonheur et longue vie pour que vous
demeuriez le flambeau illuminant le chemin de vos enfants.
Ma mère spirituelle la Rev Marthe Aurore Békombo
jamais cessé de me soutenir moralement, financièrement et
Du fond de mon cœur je te dis merci pour tous les sacrifices que tu as fais et que tu
. Que le Seigneur dans sa grâce se souvi
on très cher oncle Oyono Minlo Célestin
» est pour moi très insuffisant compte tenu de ce tu as souvent
durant tout mon parcours universitaire. Que Dieu dans sa g
combler au centuple dans toutes tes activités.
A Ma chère et grande famille»
soit l’expression des vœux que vous
prières. Que Dieu vous accorde santé et
grande sœur chérie BeKono Marthe Nadine
« A tous mes Ami(e)s»
Une pensée profonde à Toi Audace Manirabona. Merci pour ton aide.
lectroniques
Page 1
a très chère Maman Mme NTSAMA Isabelle Caroline »
Tous les mots du monde ne sauraient exprimer l’immense amour que tu m’as porté,
pour tous les efforts et les sacrifices
cessé de consentir pour mon instruction et mon bien-
encouragements que j’ai opté pour cette profession, et
J’espère avoir répondu aux
hommage par ce modeste travail en
reconnaissance et de mon infini amour. Que Dieu tout
procure santé, bonheur et longue vie pour que vous
Aurore Békombo »
jamais cessé de me soutenir moralement, financièrement et spirituellement.
i pour tous les sacrifices que tu as fais et que tu
. Que le Seigneur dans sa grâce se souvienne de toi.
lestin »
fisant compte tenu de ce tu as souvent fait
Que Dieu dans sa grâce puisse te
n’avez cessé de
longue vie. Une
Nadine.
Merci pour ton aide.
Olga Ambani
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 2
Remerciements C’est avec un grand plaisir que je réserve ces quelques lignes en signe de gratitude et de
profonde reconnaissance à tous ceux qui ont contribué à mon encadrement pour élaborer ce
projet et pour l’expérience enrichissante et pleine d’intérêt qu’ils m’ont fait vivre durant ce
stage au sein de l’agence et de l’école Polytechnique de Sousse.
J’exprimer tout ma profonde reconnaissance à Monsieur Kharraz Abdelhak, Directeur
général de l’ANCE qui nous a permis d’avoir cette honorable occasion de passer notre stage
au sein de l’agence et de nous intégrer au sein d’une équipe de professionnels jeunes et
dynamique.
Je témoigne aussi une profonde gratitude à Monsieur Zied Kacem, Directeur de l’école
Polytechnique de Sousse pour l’opportunité qu’il m’a offert de suivre ma formation
d’ingénieur.
Je voudrais également exprimer ma reconnaissance et une profonde gratitude à mes deux
encadrant professionnel et académique :
Monsieur Abdelkader Mustapha Sfaxi, Ingénieur principale au sein de l’ANCE
pour l’attention qu’il a bien voulu m’accorder pour ce projet de fin d’étude, aux
diverses étapes de son élaboration, pour m’avoir aidé, conseillé et dirigé tout au long
du projet. Sa disponibilité et son suivi m’ont été d’un grand apport.
Monsieur Nizar Ben Neji Maître Assistant à la Faculté des Sciences de Bizerte qui aussi
contribué à l’élaboration de ce projet, pour ses conseils et son soutient et sa disponibilité
durant toute ma période de stage.
J’adresse aussi de vifs remerciements à tous mes de dirigeants et Enseignants de l’école
polytechnique de Sousse qui ont contribué à ma formation. Je pense tout particulière au chef
du département Génie Télécom et Réseaux Monsieur Nabil Tabbane pour ses conseils et ses
encouragements.
Je ne peux terminer ce chef-d’œuvre sans remercier tous mes amis qui m’ont de près ou de
loin contribué à l’élaboration de ce rapport par leurs prières, encouragement et conseils. Je
pense particulièrement à monsieur Audace Manirabona, la famille Ezoua Pierre, Tous les
membres du GBUT, Ingrid Mbami, Noland Loumouangou, Lydie Yemeli, Brillon…
Remerciements
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 3
Résumé L’objectif principal de ce travail consiste à implémenter une solution Android pour la
visualisation graphique des preuves électroniques à travers le QR code.
Cette application permettra aux utilisateurs de générer une image QR contenant les
informations clé d’un document électronique signé, et d’insérer cette image sur le document à
imprimer afin qu’il puisse être utilisé comme pièce justificatives lors des démarches
administratives.
L’image QR pourra être décodée à l’aide d’un Smartphone muni d’un lecteur QR code.
Mots clés : QR code, ZXING, Bouncy Castle, signature électronique, certificat
électronique
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 4
Abstract The main purpose of this project is to implement an Android solution in order to visualize
graphically electronics evidences through the QR code.
This application will allow users to generate a QR image containing the important
information of a signed electronic document, and insert it on the document to be printed so
that it can be used as a supporting part in the administrative procedures.
The QR image can be decoded by using a Smartphone with a QR code reader.
Keywords: QR code, ZXING, Bouncy Castle, digital signature, digital certificate.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 5
Sommaire
DEDICACES ......................................................................................................................................................... 1
REMERCIEMENTS ............................................................................................................................................ 2
RESUME ............................................................................................................................................................... 3
ABSTRACT ........................................................................................................................................................... 4
LISTE DES FIGURES ......................................................................................................................................... 7
LISTE DES TABLEAUX ..................................................................................................................................... 8
GLOSSAIRE ......................................................................................................................................................... 9
INTRODUCTION GENERALE ....................................................................................................................... 10
CHAPITRE 1 PRESENTATION GENERALE ............................................................................................ 13
INTRODUCTION .................................................................................................................................................. 14 1.1 CADRE DU TRAVAIL.............................................................................................................................. 14 1.2 PRESENTATION DE L'ORGANISME D'ACCUEIL ........................................................................................ 14 1.3 PRESENTATION DU PROJET ................................................................................................................... 15
1.3.1 Contexte du projet ....................................................................................................................... 15 1.2.2 Présentation du sujet ....................................................................................................................... 15
1.4 PLANIFICATION DU PROJET ................................................................................................................... 16 1.5 CHOIX DE LA METHODOLOGIE .............................................................................................................. 17 CONCLUSION ..................................................................................................................................................... 18
CHAPITRE 2 ETAT DE L’ART ....................................................................................................................... 20
INTRODUCTION .................................................................................................................................................. 21 2.1 ETUDE L’EXISTANT .............................................................................................................................. 21
2.1.1 Problématique ................................................................................................................................. 21 2.1.2 Critique de l’existant ....................................................................................................................... 22
2.2 ETUDES DES APPLICATIONS EXISTANTES ..................................................................................................... 23 2.2.1 Générateur de QR code du site Kaywa ............................................................................................... 24 2.2.2 Application mobile de génération et lecture du QR code ................................................................ 24 2.2.3 Solution proposée: SignDoc2QR ..................................................................................................... 25
2.3 CONCEPTS DE BASE .............................................................................................................................. 26 2.3.1 Notion de Cryptographie ................................................................................................................. 26 2.3.1 Code à barres à 2D (QR Code) ....................................................................................................... 33
CONCLUSION ..................................................................................................................................................... 36
CHAPITRE 3 SPECIFICATION ET ANALYSE DES BESOINS ................................................................. 37
INTRODUCTION .................................................................................................................................................. 38 3.1 SPECIFICATION DES BESOINS FONCTIONNELS ....................................................................................... 38 3.2 SPECIFICATION DES BESOINS OPERATIONNELS ..................................................................................... 39 3.3 DESCRIPTION DES ACTEURS ................................................................................................................. 39 3.4 DIAGRAMMES DES CAS D’UTILISATION ................................................................................................. 40
3.4.1 Diagramme de cas d’utilisation global ........................................................................................... 40 3.4.2 Raffinement des cas d’utilisation .................................................................................................... 42
3.5 DIAGRAMMES D’ACTIVITES .................................................................................................................. 44 3.5.1 Diagramme d’activité : signature d’un document ........................................................................... 44
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 6
3.5.2 Diagramme d’activité : générer le document original .................................................................... 45 CONCLUSION ..................................................................................................................................................... 46
CHAPITRE 4 CONCEPTION ........................................................................................................................... 47
INTRODUCTION .................................................................................................................................................. 48 4.1 CONCEPTION DETAILLEE ...................................................................................................................... 48
4.1.1 Le diagramme de paquetages .......................................................................................................... 48 Le diagramme de paquetage (package en anglais) illustré à la figure 4.3 permet de représenter
graphiquement les relations existantes entre les paquetages composants notre système. ........................... 48 4.1.2 Diagramme de classes technique .................................................................................................... 48
4.2 DIAGRAMME DE SEQUENCE TECHNIQUE ............................................................................................... 54 4.2.1 Diagramme de séquence technique du cas d’utilisation « signer un document » ............................... 54 4.2.1 Diagramme de séquence technique du cas d’utilisation « Vérifier document ».............................. 56 4.2.2 Diagramme de séquence technique du cas d’utilisation « Scanner QR Code » .............................. 57 4.2.3 Diagramme de séquence technique du cas d’utilisation « créer un QR Code » ............................. 58
CONCLUSION ..................................................................................................................................................... 60
CHAPITRE 5 IMPLEMENTATION................................................................................................................ 61
INTRODUCTION .................................................................................................................................................. 62 5.1 ENVIRONNEMENT DE TRAVAIL ............................................................................................................. 62
5.1.1 Environnement matériel .................................................................................................................. 62 5.1.2 Environnement logiciel ................................................................................................................... 62
5.2 METHODE DE CONCEPTION ................................................................................................................... 63 5.2 DIAGRAMME DE DEPLOIEMENT : .......................................................................................................... 63 5.3 LES BIBLIOTHEQUES UTILISEES ............................................................................................................ 64
5.3.1 Zxing (Zebra Crossing) ................................................................................................................... 64 5.3.2 Bouncy Castle.................................................................................................................................. 65
5.4 INTERFACES DE L’APPLICATION............................................................................................................ 65 CONCLUSION ..................................................................................................................................................... 70
CONCLUSION GENERALE ET PERSPECTIVES ....................................................................................... 72
BIBLIOGRAPHIE .............................................................................................................................................. 74
ANNEXES .......................................................................................................................................................... 75
ANNEXE A : CHOIX DE LA METHODOLOGIE DE CONCEPTION ...................................................... 76
A.1 PROCESSUS UNIFIE ..................................................................................................................................... 76 A.2 Comparaison des méthodologies ........................................................................................................... 76
A.2.1 2 TRACK UNIFIED PROCESS (2TUP) ...................................................................................................... 78
ANNEXE B : NOTION DE QR CODE ............................................................................................................. 80
B.1 PRESENTATION DU QR ......................................................................................................................... 80 B.2 CREATION D’UN QR CODE .................................................................................................................... 82 B.3 LECTURE D’UN QR CODE............................................................................................................................ 83
ANNEXE C : ARCHITECTURE D’ANDROID .............................................................................................. 85
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 7
Liste des figures Figure 1. 1: Logo de l'ANCE ................................................................................................................................ 14 Figure 1. 2: Image simplifiant l'idée de notre projet ............................................................................................ 16 Figure 1. 3: Processus de développement 2TUP .................................................................................................. 18 Figure 2. 1: Illustration graphique du problème de l'existant .............................................................................. 23 Figure 2. 2: Logo de notre solution SignDoc2QR ................................................................................................ 24 Figure 2. 3 : Chiffrement et déchiffrement ............................................................................................................ 27 Figure 2. 4: Procédure de chiffrement symétrique ............................................................................................... 28 Figure 2. 5: Chiffrement asymétrique ................................................................................................................... 28 Figure 2. 6: Signature numérique ......................................................................................................................... 29 Figure 2. 7: Standard du certificat X509 v3 ......................................................................................................... 31 Figure 2. 8: Mécanisme de la certification électronique ...................................................................................... 31 Figure 2. 9: Exemple d'architecture d'une PKI .................................................................................................... 33 Figure 2. 10: QR code ........................................................................................................................................... 34 Figure 2. 11: Un code barre classique ................................................................................................................. 34 Figure 2. 12: Structure du QR code ...................................................................................................................... 35 Figure 2. 13: exemple d'encodage du QR code ..................................................................................................... 35 Figure 3. 1: Diagramme de cas d'utilisation global ............................................................................................. 41 Figure 3. 2: Cas d’utilisation « Signer document » .............................................................................................. 42 Figure 3. 3: Cas d'utilisation « Vérifier signature » ............................................................................................. 44 Figure 3. 4: Diagramme d’activité de signature d’un document .......................................................................... 45 Figure 3. 5: Diagramme d’activité de génération du document original ............................................................. 46 Figure 4. 1: Diagramme de paquetage de l'application ....................................................................................... 48 Figure 4. 2: D.C.T du package signature_CMS.................................................................................................... 50 Figure 4. 3: D.C.T du package vérification_certificat .......................................................................................... 50 Figure 4. 4: D.C.T du package certification ......................................................................................................... 51 Figure 4. 8: D.S.T de vérification de document .................................................................................................... 56 Figure 4. 9: D.S.T Lecture du QR code depuis la capture de la caméra et génération du fichier original .......... 58 Figure 4. 10: D.S.T de génération d’un QR-code ................................................................................................. 60 Figure 5. 1: Environnement matériel .................................................................................................................... 62 Figure 5. 2: Architecture MVC Android ............................................................................................................... 63 Figure 5. 3: Diagramme de déploiement .............................................................................................................. 64 Figure 5. 4: Interface d'accueil ............................................................................................................................ 65 Figure 5. 5: Interface d'encodage avec la liste des fichiers encodés .................................................................... 65 Figure 5. 6: interface Listant le contenu de la sdcard ......................................................................................... 66 Figure 5. 7: Interface de sélection du fichier à encoder ....................................................................................... 66 Figure 5. 8: Interface lancement du processus d'encodage .................................................................................. 66 Figure 5. 9: Interface Résultat du QR généré ....................................................................................................... 67 Figure 5. 10: Interface de génération du résultat de l'encodage .......................................................................... 67 Figure 5. 11: liste des fichiers encodés ................................................................................................................. 68 Figure 5. 13: Décodage du QR ............................................................................................................................. 69 Figure 5. 12: Interface liste des fichiers décodés ................................................................................................. 68 Figure 5. 14: interface liste des fichiers décodés .................................................................................................. 69 Figure A. 1: Le processus de développement en Y ................................................................................................ 78 Figure B. 1: Comparaison des capacités de stockage des données entre le QR Code et le code-barres .............. 80 Figure B. 2: Deux exemples de générateurs de QR Code en ligne : [codeqrnews] et [keremerkan] ................... 82 Figure B. 3: le diagramme de flux de la lecture ................................................................................................... 84 Figure C. 1: Architecture d'Android ..................................................................................................................... 85
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 8
Liste des tableaux
Tableau 1.1: Planification du projet ......................................................................................... 17
Tableau 3. 1: Spécification des besoins fonctionnels ............................................................... 39
Tableau 3. 2: Raffinement du cas d'utilisation « Signer document » ....................................... 43
Tableau 3. 3: Raffinement du cas d'utilisation Vérifier signature ............................................ 44
Tableau 4. 1: Description des classes relatives à la Signature électronique ............................ 49
Tableau 4. 2: Description des classes du package engine ........................................................ 54
Tableau 4. 3: tableau descriptif du diagramme séquence technique ........................................ 55
Tableau 4. 4: Tableau de séquence technique 2 ....................................................................... 57
Tableau 4. 5: Tableau de séquence technique 3 ....................................................................... 57
Tableau 4. 6: tableau de classe technique 4 ............................................................................. 59
Tableau A. 1: Synthèse des méthodologies utilisées ................................................................ 77
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 9
Glossaire
CA: Certificate Authority
CRL: Certificate Revocation List
LDAP: Lightweight Directory Access Protocol
D.S.T : Diagramme de séquence technique
2D: 2 Dimensions
ANCE: Agence Nationale de Certification Electronique
UML: Unified Modeling Language
PKI: Public Key Infrastructure
2TUP: Two (2) Tracks Unified Process
Le code QR: en anglais, QR code pour Quick Response) est un code-barres à deux
dimensions (ou code à matrice) constitué de modules noirs disposés dans un carré à
fond blanc. Le nom QR est l'acronyme de l'anglais Quick Response, car son contenu
de données peut être décodé rapidement. Destiné à être lu par un lecteur de code-barres
QR, un téléphone mobile, ou un Smartphone, il a l'avantage de pouvoir stocker plus
d'informations qu'un code à barres
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 10
Introduction
Générale
Introduction générale _ ________
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 11
Face aux besoins conjugués et croissants de modernisation des services, de simplification des
démarches administratives, les documents signés électroniquement ne sont pas très pratique
dans le monde en général.
Suite à la révolution du document électronique, les acteurs publics, les entreprises et les
citoyens exigent des mécanismes qui garantissent la sécurité et la confidentialité des
informations transmises électroniquement sur les réseaux, en particulier par Internet,
équivalent au niveau de confiance des pratiques traditionnelles du monde papier. Les
utilisateurs souhaitent en particulier que leurs transactions électroniques soient confidentielles
et protégées contre toute forme de manipulation. Ils veulent aussi pouvoir s’assurer que leurs
interlocuteurs sont vraiment ceux qu’ils prétendent être et qu’il ne sera pas possible de
s’opposer a posteriori à une transaction réalisée électroniquement.
Successeur du code à barres présent sur l'emballage des produits de consommation, le code à
barres à deux dimensions est une technologie qui a connu une très forte progression. Le code
2D permet de passer d'un support physique (papier, écran…) au format électronique en une
fraction de seconde [1]. Faisant l’un des objets principaux sur lequel sera basé notre travail,
nous exploiterons l'une de ces technologies d'encodage qui est le QR Code (Quick Response
Code) dans la réalisation de celui ci.
Après s'être assuré de l'authenticité du document électronique, il faut ensuite prouver la
validité de celui ci après son impression sur papier, afin de s’en servir comme preuve lors
des démarches administratives. Comment créer cet interfaçage entre le document électronique
et le document papier?
Ceci peut être possible en stockant le fichier signé contenant les informations liées à la
signature et au signataire dans un espace considérablement réduit, mais pouvant contenir une
grande capacité d'informations; d'où l'usage du QR code.
c'est dans ce cadre de travail que s'inscrit notre projet intitulé: " Représentation graphique des
preuves électroniques". Le projet a pour objectif le développement d'une application Android
permettant de sécuriser les documents électroniques après leur impression pour qu'ils soient
utilisés comme pièces justificatives dans des démarches administratives.
Introduction générale _ ________
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 12
Ce rapport présente l'ensemble des étapes suivies pour développer notre solution. Il se
résume en cinq chapitres catalogués comme suite:
Le premier chapitre intitulé "Présentation générale" consister à présenter le contexte
du projet ainsi que l'entreprise d'accueil et la méthodologie adoptée.
le deuxième chapitre "Etat de l'art" porte sur l'étude des applications de génération de
QR code existants et la présentation de leurs fonctionnalités. nous aborderons aussi
quelques concepts de base afin de mieux appréhender notre travail.
Dans le troisième chapitre « spécification des besoins » nous allons déterminer les
besoins fonctionnels et non fonctionnels de notre application et présenterons les
différents cas d'utilisation.
Le quatrième chapitre intitulé "Conception" détaille les différents aspects conceptuels
de l'application.
Le dernier chapitre intitulé « Réalisation » présente l’environnement de travail ainsi
que les outils logiciels que nous avons utilisés pour la réalisation de notre projet. Il
illustre aussi le travail réalisé avec un ensemble d’interfaces graphiques conçues pour
l’application.
En fin notre travail se termine par une conclusion générale où nous mentionnons les
différents atouts de ce projet et les perspectives d’améliorations possibles.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 13
Chapitre 1 Présentation
Générale
Chapitre 1
Visualisation Graphique des
Rédigé et pr
Introduction
Dans ce premier chapitre, il sera question de
présenterons d'une part l'organisme d'accueil et d'autre part
notre projet et enfin nous présenterons la méthodologie
1.1 Cadre du travail
Ce stage s'inscrit dans le cadre d'un projet de fin d'études pour l'
d'ingénieur Télécoms et Réseaux à
de l'Agence Nationale de C
sujet « visualisation graphique des preuves électronique
1.2 Présentation de l'organisme
L’Agence Nationale de Certification électronique est une entreprise publique à caractère non
administratif sous tutelle du ministère de l’industrie et de la technologie.
En Tunisie l’intérêt au commerce électroni
marquée par la création d’une commission chargée de la mise en place des stratégies du
commerce (E-commerce) et du gouvernement électronique (E
nécessité de bâtir une infrastruc
En 1999, dans le même contexte, un conseil interministériel a été établi à propos de
l’économie numérique. En 2000, la promulgation de
en place un cadre de législation et
électronique, dans lequel le régime des contrats écrits s’applique aux contrats électroniques et
il en suit, en vue de favoriser un environnement de confiance, la création de l’
Nationale de Certification électronique, une entreprise publique à caractère non administratif
sous tutelle du ministère de l’industrie et
racine en Tunisie.
Présentation générale
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
ce premier chapitre, il sera question de donner un aperçu général de notre projet.
présenterons d'une part l'organisme d'accueil et d'autre part nous délimi
notre projet et enfin nous présenterons la méthodologie adoptée dans le cadre de ce projet.
Cadre du travail
Ce stage s'inscrit dans le cadre d'un projet de fin d'études pour l'obtention du
Télécoms et Réseaux à l'Ecole Polytechnique de Sousse. Il a été effectué au sein
Agence Nationale de Certification Electronique (ANCE) avec comme intitulé du
graphique des preuves électronique ».
Présentation de l'organisme d'accueil
ale de Certification électronique est une entreprise publique à caractère non
administratif sous tutelle du ministère de l’industrie et de la technologie.
Figure 1. 1: Logo de l'ANCE
commerce électronique a commencé depuis 1997, l’année qui a été
marquée par la création d’une commission chargée de la mise en place des stratégies du
commerce) et du gouvernement électronique (E-governement). Il a été relevé la
nécessité de bâtir une infrastructure à clé publique et un cadre légal. [2]
En 1999, dans le même contexte, un conseil interministériel a été établi à propos de
En 2000, la promulgation de la loi n° 2000-83 du 09 aout
législation et de réglementation des échanges et du commerce
électronique, dans lequel le régime des contrats écrits s’applique aux contrats électroniques et
, en vue de favoriser un environnement de confiance, la création de l’
de Certification électronique, une entreprise publique à caractère non administratif
sous tutelle du ministère de l’industrie et de la technologie et est l’autorité de c
Présentation générale
lectroniques
Page 14
général de notre projet. Nous
nous délimiterons le cadre de
dans le cadre de ce projet.
obtention du diplôme
a été effectué au sein
ertification Electronique (ANCE) avec comme intitulé du
ale de Certification électronique est une entreprise publique à caractère non
a commencé depuis 1997, l’année qui a été
marquée par la création d’une commission chargée de la mise en place des stratégies du
governement). Il a été relevé la
En 1999, dans le même contexte, un conseil interministériel a été établi à propos de
du 09 aout 2000 a mis
de réglementation des échanges et du commerce
électronique, dans lequel le régime des contrats écrits s’applique aux contrats électroniques et
, en vue de favoriser un environnement de confiance, la création de l’Agence
de Certification électronique, une entreprise publique à caractère non administratif
de la technologie et est l’autorité de certification
Chapitre 1 Présentation générale
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 15
En effet, l’ANCE est l’autorité de certification racine en Tunisie. Elle représente le plus haut
niveau de confiance dans le domaine de la certification électronique et de la sécurité des
transactions des échanges électroniques sur le réseau internet tels que [2]:
L’ e-commerce où le rôle de l’ANCE consiste à sécuriser les transactions de
paiement et l’authentification des différents acteurs.
L’e-banking.
L’e-gouvernement...
1.3 Présentation du projet
1.3.1 Contexte du projet
Le QR Code est un code barre à 2 dimensions qui permet de stocker des informations
numériques (textes, adresses de site web, etc.). Il peut-être déchiffré à partir d'un téléphone
mobile équipé d'un appareil photo et du lecteur approprié. Imprimé sur un support ou placé
dans l'environnement urbain, il permet de relier l'espace physique et l'espace numérique [3].
Le document électronique grâce aux technologies de signature électronique est devenu une
pièce comptable juridiquement. Mais cette pièce n'est pas valide dans tous les ministères en
Tunisie particulièrement. Comment rendre valide le document électroniquement signé après
son impression?
C'est dans ce contexte général que se situe notre projet de fin d'étude.
1.2.2 Présentation du sujet
Afin de garantir la véracité d’une preuve électronique, il est important de s’assurer de
l’identité de son émetteur et de l’intégrité de son contenu ; d’où l’origine de la signature
électronique qui permet en plus des fonctions susmentionnées, d’assurer la non répudiation.
Dans le souci d’améliorer la sécurité et la traçabilité de ces preuves électroniques, une
solution basée sur les codes les QR code s’avère nécessaire.
La solution objet du projet a pour objectif de sécuriser les documents électroniques après
impression pour qu'ils soient utilisés comme pièces justificatifs dans des démarches
administratives. La solution consiste à insérer au niveau du document à imprimer un code à
Chapitre 1
Visualisation Graphique des
Rédigé et pr
barres 2D contenant les informations clés du document, la date d’émission, l'auteu
propriétaire et la signature électronique du hash de ces données.
Les codes 2D seront utilisés pour le stockage des preuves électroniques des documents. Les
preuves électroniques peuvent être:
Certificat électronique du signataire
Signature électronique d'un document
Jeton d'horodatage
Le présent projet consiste en la conception et à la réal
permettant de signer un fichier numérique, d'en extraire les preuves électroniques et les
stocker dans un QR code.
Figure 1
1.4 Planification
Tout au long du stage, notre travail a été réparti tel qu'il est décrit dans le tableau ci
Présentation générale
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
barres 2D contenant les informations clés du document, la date d’émission, l'auteu
propriétaire et la signature électronique du hash de ces données.
Les codes 2D seront utilisés pour le stockage des preuves électroniques des documents. Les
preuves électroniques peuvent être:
Certificat électronique du signataire
nique d'un document
Le présent projet consiste en la conception et à la réalisation d'une application Androi
permettant de signer un fichier numérique, d'en extraire les preuves électroniques et les
Figure 1. 2: Image simplifiant l'idée de notre projet
lanification du projet
travail a été réparti tel qu'il est décrit dans le tableau ci
Présentation générale
lectroniques
Page 16
barres 2D contenant les informations clés du document, la date d’émission, l'auteur, le
Les codes 2D seront utilisés pour le stockage des preuves électroniques des documents. Les
isation d'une application Android
permettant de signer un fichier numérique, d'en extraire les preuves électroniques et les
travail a été réparti tel qu'il est décrit dans le tableau ci-après:
Chapitre 1
Visualisation Graphique des
Rédigé et pr
1.5 Choix de la méthodologie
Afin de mener à bon terme notre projet vue sa complexité, on suivra un processu
précisément le processus 2TUP
Le processus unifié est un processus de développement logiciels orientés obj
l'architecture, guidé par des cas d'utilisation et orienté vers la diminution des risques
« 2 Tracks » signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins
fonctionnels » et « d’architecture technique
changement imposés au système d’information
développement correspond alors à un Y
Présentation générale
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Tableau 1.1: Planification du projet
Choix de la méthodologie
Afin de mener à bon terme notre projet vue sa complexité, on suivra un processu
2TUP (2 Tracks Unified Process).
est un processus de développement logiciels orientés obj
l'architecture, guidé par des cas d'utilisation et orienté vers la diminution des risques
» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins
» et « d’architecture technique », qui correspondent aux deux axes de
changement imposés au système d’informations. La schématisation du processus de
développement correspond alors à un Y comme le montre la figure 1.2.
Présentation générale
lectroniques
Page 17
Afin de mener à bon terme notre projet vue sa complexité, on suivra un processus unifié,
est un processus de développement logiciels orientés objets, centré sur
l'architecture, guidé par des cas d'utilisation et orienté vers la diminution des risques [4].
» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins
, qui correspondent aux deux axes de
La schématisation du processus de
.
Chapitre 1 Présentation générale
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 18
Figure 1. 3: Processus de développement 2TUP
La branche fonctionnelle contient : la capture des besoins et de leur analyse. Les résultats de
l'analyse sont indépendantes des technologies utilisés.
La branche technique contient : la capture des besoins techniques et de la conception
générique. L'architecture technique construit le squelette du système informatique
indépendamment des besoins fonctionnels.
Les deux branches ont ensuite fusionnées en une seule branche qui prend en charge la
conception préliminaire (cartographie des composants à développer), conception détaillée
(comment réaliser chaque composant), codage (production des composants), tests et étapes de
validation des fonctions développées.
NB : les détails sur le processus unifié et la comparaison avec d’autres méthodologies seront
développés en Annexe A.
Conclusion
Après nous être imprégner de notre projet par une présentation de l'organisme d'accueil et du
contexte de notre travail, nous avons choisi comme méthodologie le processus unifié 2TUP
que nous essayerons d’appliquer dans la suite de notre travail. Qu’est ce qui fait l’objet de
notre projet ? En d’autres termes, quel est « le pourquoi » de notre travail ? Telle est la
question à laquelle nous essayerons de donner des éléments de réponse dans le chapitre qui
va suivre.
Chapitre 1 Présentation générale
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 19
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 20
Chapitre 2 Etat de l’art
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 21
Introduction
Afin de mieux délimité le cadre de notre projet, nous essayerons dans ce chapitre de présenter
premièrement quelques projets ayant déjà été réalisés dans le domaine, ensuite la
problématique et enfin on définira quelques concepts de base pour mieux appréhender notre
sujet.
2.1 Etude l’existant
Notre étude s’est axée sur le marché du document électronique d’une part ; en d’autres termes
l’observation du déroulement des activités des structures qui font des transactions en ligne
(sur internet). Ces transactions peu importe leurs natures, nécessites généralement un
document signé électroniquement qui servira de preuves. D’autres part l’usage du QR Code.
Malheureusement le devenir de ce document électronique signé n’est plus après impression
sur papier ce qu’on aurait voulu qu’il soit. Il perd toute sa validité, car rien ne garanti plus
l’authenticité (authentification et intégrité) de son contenu encore moins la non répudiation.
2.1.1 Problématique
Ci-après l’extrait du témoignage d’un chef d’entreprise recueilli lors d’une enquête :
«J’ai été vraiment surpris quand le fisc a débarqué et qu’il m’a refusé toutes mes factures
sous le prétexte qu’elles sont en format électronique. On m’a dit qu’elles n’étaient pas
valides. J’ai eu beau leur expliquer qu’elles sont signées par un certificat électronique, ils
n’ont rien voulu savoir.
L’utilisation de la facture numérique dans la plupart des startups étrangères est une monnaie
courante. Je me retrouve maintenant contraint de les recontacter pour qu’ils me les
impriment toutes et me les envoient par voie postale. Et on s’étonne encore pourquoi le
commerce électronique ne décolle pas en Tunisie !» [5]
Le commerce électronique se base en grande partie sur la dématérialisation des paperasses
administratives en substituant à ces dernières des documents signés électroniquement, c’est-à-
dire la dématérialisation complète, et de bout en bout, du processus d’achat/vente. Ainsi,
chaque entreprise peut augmenter sa productivité en réduisant drastiquement les délais de
traitement et les charges y relatives (envois de fax/courrier officiel, délais de traitement,
traçabilité, archivage, etc.).
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 22
Lors de l'enquête menée par la THD (Très Haut Débit) en Décembre 2012 au sujet des
certificats électroniques, force était de constater la complexité des procédures administratives
basées sur le document papier classique.
Il a été remarqué par la suite que certaines entreprises Tunisiennes essaient en vain depuis des
années de se lancer dans le commerce électronique, mais aucun de ces startups sinon très peu
n’ont réussi à s’imposer avec un modèle économique comme celui des grandes sociétés telle
que «ebay». En Tunisie on peut, en effet, acheter ou vendre son produit en ligne grâce aux
interfaces de paiement électroniques existantes comme la SMT (Société Monétique Tunisie)
ou la Poste tunisienne, mais il est impossible de récupérer cette facture d’achat sous format
numérique et l’utiliser comme une preuve officielle reconnue.
Si ceci ne pose guère de problème aux particuliers mais devient par contre, très dérangeant
pour les entreprises qui doivent justifier leurs achats ou leurs ventes en cas de contrôle fiscal.
Nous constatons ainsi que le document électronique signé n'a de valeur que lorsqu'il reste à
son état numérique.
En s'appuyant sur l'exemple des factures numériques, le vrai challenge est de mettre en place
un processus technique clair, une garantie pour le ministère des Finances afin que les
fraudeurs n’y exploitent pas une faille et ainsi évitent de payer leurs dus.
Un autre problème majeur repéré en Tunisie est la méfiance de certains ministères publics à
l'autorité nationale, l’ANCE, établie pour délivrer les certificats numériques, une
méconnaissance totale du rôle de l’ANCE et de celui de l’Internet dans les opérations
financières en général.
Comment créer un environnement de confiance pouvant permettre aux entreprises de se
lancer dans le commerce électronique en toute sécurité et confiance en Tunisie?
C’est dans cette situation générale du commerce électronique en Tunisie que s’inscrit notre
projet afin de contribuer à relever ces défis et y apporter une voie de solution.
2.1.2 Critique de l’existant
D’après la loi publiée en 2001 dans le Journal Officiel de la République Tunisienne (JORT)
qui annonce clairement que « tout document signé électroniquement par l’Agence Nationale
de Certification Electronique (ANCE) est jugé valide ». [5]
Chapitre 2
Visualisation Graphique des
Rédigé et pr
Ce qui amène à conclure que le document électronique si
document papier légalisé. Mais force est de constater que cela n’est pas
certaines administrations Tunisienne
Les contrôleurs fiscaux ne sont pas outillés pour contrôler les factures électroniques,
les emmener à accepter et valider la version papier des
Le challenge est de mettre en place un processus technique clair. Une garantie pour le
ministère des Finances pour que les fraudeurs n’y exploitent pas une faille e
leurs dus.
A quelle solution pourra t –
Tunisie ?
Figure 2. 1: Illustration graphique du problème de l'existant
2.2 Etudes des application
Après les recherches effectuée
la solution faisant objet de notre projet.
Mais par ailleurs, nous avons préalablement recherché et sélectionné des applications
générant des QR-codes (sur I
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Ce qui amène à conclure que le document électronique signé a la même valeur qu’un
Mais force est de constater que cela n’est pas toujours
administrations Tunisiennes.
es contrôleurs fiscaux ne sont pas outillés pour contrôler les factures électroniques,
et valider la version papier des documents signés électronique
Le challenge est de mettre en place un processus technique clair. Une garantie pour le
ministère des Finances pour que les fraudeurs n’y exploitent pas une faille e
– on avoir recourt afin de relancer commerce électronique en
: Illustration graphique du problème de l'existant
2.2 Etudes des applications existantes
es, nous avons remarqué qu’il n’existe pas encore sur le marché
la solution faisant objet de notre projet.
ous avons préalablement recherché et sélectionné des applications
sur Internet principalement) afin d'en observer les fonctionnalités
Etat de l'art
lectroniques
Page 23
gné a la même valeur qu’un
toujours le cas dans
es contrôleurs fiscaux ne sont pas outillés pour contrôler les factures électroniques, comment
documents signés électroniquement ?
Le challenge est de mettre en place un processus technique clair. Une garantie pour le
ministère des Finances pour que les fraudeurs n’y exploitent pas une faille et évitent de payer
commerce électronique en
: Illustration graphique du problème de l'existant
encore sur le marché
ous avons préalablement recherché et sélectionné des applications
afin d'en observer les fonctionnalités.
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 24
Figure 2. 2: générateur de QR code
Notre regard s'est porté sur deux sites web qui proposent de créer et d'enregistrer gratuitement
des QR-codes avec un nombre important de paramètres possibles : qrcode.fr et kaywa.com.
2.2.1 Générateur de QR code du site Kaywa
La zone de génération finale de l'image du QR-code.
(2) La sélection du type de contenu (URL, texte libre, numéro de téléphone, SMS)
(3) La zone de saisie du contenu, pouvant comporter plusieurs champs de saisie
préformatés selon le type de contenu.
(4) La sélection de la taille du QR-code qui sera généré ainsi que le bouton de
génération
2.2.2 Application mobile de génération et lecture du QR code L’application qui a le plus tiré notre attention est le QR Droid qui est une application Android
de génération et de lecture du QR code.
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 25
Au vue de ces application existantes, l’un des enjeux que nous avons dénoté dans l’usage des
QR code est que celui-ci est beaucoup plus utilisé dans le domaine publicitaire et marketing.
De plus nous constatons aussi que ces applications n’encodent qu’une quantité réduite
d’informations telles que des adresses URL, des portions de texte, des contacts… mais pas
des documents ayant un fort contenue de donnée.
C’est ainsi que nous avons exploité certaines de ces failles pour implémenter notre solution
qui ne sera pas uniquement orienté Publicité.
2.2.3 Solution proposée: SignDoc2QR
SignDoc2QR est une application Android qui sert à faire l’interfaçage entre le document
numérique et le document papier.
La solution consiste à encoder certaines données du document contenant la signature
électronique de l’émetteur et le hash de ces données et les stocker dans un QR Code généré au
format image. L’utilisateur pourra ensuite insérer cette image au niveau du document
électronique qu’il souhaite imprimer.
Le document papier contenant le QR code pourra ainsi être utilisé dans les démarches
administratives. Comment pourra t – on lire ce code ?
Pour lire l’image QR, l’utilisateur aura recours à un lecteur QR code ou un Smartphone muni
d’une application de lecture de code 2D. Plusieurs décodeur de QR code existe déjà sur le
marché.
En somme, SignDoc2QR présente les avantages suivants :
Figure 2.2.1 : application QR Droid
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 26
Traçabilité des documents
Lutter contre la fraude en renforçant
favoriser le développement du commerce électronique
simplifier les démarches administratives
Bien d’autres avantages peuvent découler de notre solution. Mais pour mieux appréhender
notre solution, il est important d’avoir quelques connaissances en matière de signature
électronique et tous les concepts qui y sont rattachés.
2.3 Concepts de base
2.3.1 Notion de Cryptographie
A. Définition
La cryptographie est un terme générique désignant l'ensemble des techniques permettant de
chiffrer des messages, c'est-à-dire permettant de les rendre inintelligibles sans une action
spécifique [6] ; la cryptographie permet d’assurer la confidentialité, l’authentification et
l’intégrité des données (c'est-à-dire que le message n’a pas été modifié lors de sa
transmission).
Bien que la science de la cryptographie est très ancienne, la révolution bureau - ordinateur a
permis à des techniques cryptographiques pour devenir largement utilisée et accessible
aux experts.
Le chiffrement [7] consiste à rendre illisible un message en brouillant ses éléments de telle
sorte qu'il soit très difficile de reconstituer l'original si l'on ne connaît pas la transformation
appliquée ; Le chiffrement est basé sur deux éléments :
Une clé : qui est une chaine de nombre binaires (0 et 1) et qui peut être publique
c'est-à-dire diffusée sur le réseau ou bien elle peut être gardée secrète.
Un algorithme : qui est une fonction mathématique souvent complexe qui va
combiner la clé et le texte à crypter pour rendre ce texte illisible.
Chapitre 2
Visualisation Graphique des
Rédigé et pr
Figure 2.
Il existe deux types de chiffrement, le chiffrement symétrique et le chiffrement asymétrique.
Chiffrement symétrique
la même clé est utilisée pour coder et décoder un messag
algorithme de chiffrement symétrique à savoir
AES (Advanced Encryption Standard
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Figure 2. 3 : Chiffrement et déchiffrement
B. Les mécanismes de chiffrement
Il existe deux types de chiffrement, le chiffrement symétrique et le chiffrement asymétrique.
Chiffrement symétrique : Avec ce mécanisme appelé aussi chiffrement à clé secrète,
la même clé est utilisée pour coder et décoder un message ; il existe plusieurs
algorithme de chiffrement symétrique à savoir : DES (Data Encryption Standard) et
AES (Advanced Encryption Standard).
Etat de l'art
lectroniques
Page 27
Il existe deux types de chiffrement, le chiffrement symétrique et le chiffrement asymétrique.
: Avec ce mécanisme appelé aussi chiffrement à clé secrète,
; il existe plusieurs
Data Encryption Standard) et
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 28
Le principe de ce type de chiffrement est illustré par la figure suivante :
L’emetteur chiffre le message avec une clé secrete et l’envoie sur le réseau, le destinataire
déchiffre le message avec cette meme clé.
Chiffrement asymétrique :
Pour ce type de système appelé aussi chiffrement à clé publique, les clés qui codent un
message sont différentes de celle qui décodent le message; le principe de cet algorithme est
illustré par la figure 2.5:
L’emetteur du message utilise la clé publique du destinataire pour chiffrer le message et
l’envoie sur le réseau, le destinataire qui recoit ce message crypté utilise sa clé privée pour
décoder le message.
L’emetteur peut aussi utiliser sa clé privée pour coder un message et le destinaire utilise la clé
publique de l’emetteur pour décoder le message ; c’est le principe utilisé par la signature
numérique .
Figure 2. 4: Procédure de chiffrement symétrique
Figure 2. 5: Chiffrement asymétrique
Chapitre 2
Visualisation Graphique des
Rédigé et pr
Ce mécanisme repose sur un système de
publique et une clé privée, et
document. La clé privée sert à signer un document, l
signature. La signature électronique est l'équivalent
Techniquement, la signature électr
document via la clé privée du signataire
une fonction de hachage.
La fonction de hachage [8] est une
entrée, calcule une empreinte
donnée initiale. Les fonctions de hachage sont uti
Les principaux algorithmes utilisés pour calculer des fonctio
algorithmes MD5 et SHA-1.
La figure suivante représente
les différentes étapes de
génération et de vérification
de signature numérique que
nous venons de citer :
Alice hache le message et
obtient l’empreinte. Elle
chiffre ensuite cette
empreinte à l’aide sa clé
privée et obtient la signature.
Elle envoie l’ensemble
(message + signature) à Bob.
A la réception, Bob prend le
message reçu et le hache à son
tour, il obtient l’empreinte recalculée. Puis il prend la signature et la d
publique d’Alice et obtient l’empreinte reçue. Il compare enfin l’empreinte reçu avec le haché
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
C. La signature numérique
Ce mécanisme repose sur un système de chiffrement asymétrique qui utilise
et permet d'authentifier l'émetteur et d’assurer l’intégrité d'un
document. La clé privée sert à signer un document, la clé publique sert à vérifier cette
signature. La signature électronique est l'équivalent numérique de la signature manuscrite.
Techniquement, la signature électronique correspond au chiffrement de l'empreinte d'un
document via la clé privée du signataire; cette empreinte est calculé par une fonction appelé
est une fonction particulière qui, à partir d'une donnée fournie en
empreinte servant à identifier rapidement, bien qu'incomplètement, la
donnée initiale. Les fonctions de hachage sont utilisées en informatique et en
Les principaux algorithmes utilisés pour calculer des fonctions de hachage sont
La figure suivante représente
les différentes étapes de
génération et de vérification
de signature numérique que
Alice hache le message et
obtient l’empreinte. Elle
cette
empreinte à l’aide sa clé
privée et obtient la signature.
Elle envoie l’ensemble
A la réception, Bob prend le
message reçu et le hache à son
tour, il obtient l’empreinte recalculée. Puis il prend la signature et la déchiffre à l’aide la clé
publique d’Alice et obtient l’empreinte reçue. Il compare enfin l’empreinte reçu avec le haché
Alice
Bob
Figure 2. 6: Signature numérique
Etat de l'art
lectroniques
Page 29
qui utilise une clé
d'authentifier l'émetteur et d’assurer l’intégrité d'un
a clé publique sert à vérifier cette
de la signature manuscrite.
onique correspond au chiffrement de l'empreinte d'un
; cette empreinte est calculé par une fonction appelé
particulière qui, à partir d'une donnée fournie en
servant à identifier rapidement, bien qu'incomplètement, la
et en cryptographie ;
ns de hachage sont les
échiffre à l’aide la clé
publique d’Alice et obtient l’empreinte reçue. Il compare enfin l’empreinte reçu avec le haché
: Signature numérique
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 30
qu’il a calculé. En cas d’égalité l’intégrité du message et la non-répudiation ont été garantis ;
sinon le message a été altéré ou modifié et la signature n’est pas validée.
Le contrôle des clés privées et publiques est assuré par le mécanisme de certificat électronique
D. Le certificat électronique:
Le certificat est au cœur du processus de signature électronique. Il est porteur d’une valeur
juridique puisqu’il va permettre l’identification de la personne, mais il a également une
définition technique. Selon la définition qui en est donnée par l’ « ISO », c’est « un objet
informatique qui permet de lier de façon intangible une identité d’entité (une personne, une
ressource) à certaines caractéristiques de cette entité. » [9]
Le certificat possède une structure interne, c’est -à -dire certains champs qui doivent,
obligatoirement pour lui accorder une force, être renseignés. Cette structure interne est définie
par une norme internationale nommée recommandation X-509 V.3 de l’Union internationale
des télécommunications. Cette norme a été reprise et développée par l’organisation de
normalisation du monde Internet qui a décliné la norme de certificats pour l’appliquer à la
technologie de signature numérique.
En pratique, l’utilisateur va transmettre sa clé publique au certificateur. Après certaines
vérifications sur l’identité et la capacité de la personne. Aussi, pour assurer au destinataire
que le certificat n’est pas un faux, le certificateur va devoir signer ce certificat de sa
signature électronique.
Utilité des certificats :
En cryptographie, La garantie qu'une clé publique provient bien de l'émetteur qu'il prétend
être, s'effectue donc via un certificat d'authenticité émanant d'une autorité de certification
(AC), le tiers de confiance.
Autorité de certificat :
L’Autorité de certification (AC ou CA) a pour mission, après vérification de l'identité du
demandeur du certificat par une autorité d'enregistrement, de signer, émettre et maintenir [10]
les certificats (CSR : Certificate Signing Request)
les listes de révocation (CRL : Certificate Revocation List)
Chapitre 2
Visualisation Graphique des
Rédigé et pr
Certificat X509 :
X509 définit la forme d'un certificat (simple fich
certification qui contient :
la clé publique de son
détenteur et des
informations sur son
identité ;
le nom distinctif de
l'autorité de certification ;
la signature électronique
(chiffrement de l'empreinte
par clé privée) de l'autorité
de certification. [9]
Emission et vérification de certificat
Elle se déroule comme décrite dans la
Figure 2. 8
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
définit la forme d'un certificat (simple fichier informatique) délivré par une
la clé publique de son
détenteur et des
informations sur son
le nom distinctif de
l'autorité de certification ;
la signature électronique
(chiffrement de l'empreinte
clé privée) de l'autorité
Emission et vérification de certificat
Elle se déroule comme décrite dans la figure 2.8 suivante :
Figure 2. 7: Standard du certificat X509 v3
8: Mécanisme de la certification électronique
Etat de l'art
lectroniques
Page 31
ier informatique) délivré par une autorité de
: Standard du certificat X509 v3
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 32
E. Public Key Infrastructure (PKI)
La cryptographie à grande échelle nécessite de pouvoir gérer des listes importantes de clés
publiques. D’où le nécessité des infrastructures à clé publiques (PKI): systèmes de gestion des
clés publiques.
PKI (Public Key Infrastructure) est un système de gestion des clefs publiques qui permet de
gérer des listes importantes de clefs publiques et d'en assurer la fiabilité, pour des entités
généralement dans un réseau. Elle offre un cadre global permettant d'installer des éléments de
sécurité tels que la confidentialité, l'authentification, l'intégrité et la non-répudiation tant au
sein de l'entreprise que lors d'échanges d'information avec l'extérieur.
Une infrastructure PKI fournit donc quatre services principaux [9]:
fabrication de bi-clés.
certification de clé publique et publication de certificats.
Révocation de certificats.
Gestion la fonction de certification.
Une PKI est constituée de l’autorité de Certification (AC), de l’autorité d’Enregistrement
(AE), d’un annuaire LDAP des certificats valides et révoqués (Liste des Certificats Révoqués
LCR), d’un système d’archivage des certificats, des utilisateurs finaux et administrateurs et de
la Politique de Certification qui décrit les relations entre les différents composants.
Architecture d’une PKI: L'architecture se décompose en éléments opérationnels.
Ces éléments sont indépendants et ne nécessitent pas forcément une machine
physique propre.
Chapitre 2
Visualisation Graphique des
Rédigé et pr
Figure 2.
Lorsque l'Autorité de Certification
l'AE, elle doit générer un certificat. Pour prouver que le certificat émane réellement de cette
CA, il doit être signé avec la clé privée de l'Autorité de Certification. Cela signifie que si un
utilisateur arrive à se procurer cette clé privée, il pourrait créer des c
valides en générant lui-même le couple de clés. Il pourrait donc signer et décrypter
l'intégralité des données circulant. Il est donc primordial d'assurer la sécurité et la
confidentialité de la clé privée de l'Autorité de Certificati
2.3.1 Code à barres
A) Définition
Successeur du code à barres présent sur l'emballage des produits de consommation, le code à
barres à deux dimensions est une technologie qui a connu une très forte progression. Le code
2D permet de passer d'un support physique (papier, écran…) au format électronique en une
fraction de seconde.
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Figure 2. 9: Exemple d'architecture d'une PKI
Lorsque l'Autorité de Certification reçoit une demande de certificat par l'intermédiaire de
oit générer un certificat. Pour prouver que le certificat émane réellement de cette
CA, il doit être signé avec la clé privée de l'Autorité de Certification. Cela signifie que si un
utilisateur arrive à se procurer cette clé privée, il pourrait créer des certificats numériques
même le couple de clés. Il pourrait donc signer et décrypter
l'intégralité des données circulant. Il est donc primordial d'assurer la sécurité et la
confidentialité de la clé privée de l'Autorité de Certification. [11]
Code à barres à 2D (QR Code)
Définition
Successeur du code à barres présent sur l'emballage des produits de consommation, le code à
barres à deux dimensions est une technologie qui a connu une très forte progression. Le code
un support physique (papier, écran…) au format électronique en une
Etat de l'art
lectroniques
Page 33
reçoit une demande de certificat par l'intermédiaire de
oit générer un certificat. Pour prouver que le certificat émane réellement de cette
CA, il doit être signé avec la clé privée de l'Autorité de Certification. Cela signifie que si un
ertificats numériques
même le couple de clés. Il pourrait donc signer et décrypter
l'intégralité des données circulant. Il est donc primordial d'assurer la sécurité et la
Successeur du code à barres présent sur l'emballage des produits de consommation, le code à
barres à deux dimensions est une technologie qui a connu une très forte progression. Le code
un support physique (papier, écran…) au format électronique en une
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 34
Le QR code tire son nom de l'abréviation anglaise Quick Response et signifie code barre a
décodage rapide. Ce type de code a été
invente par la société Japonaise Denso-wave en 1994, pour
permettre le suivit des pièces de voitures dans les usines Toyota. [12]
Le format des codes à barres 2D est généralement issu de deux technologies d'encodage :
Datamatrix et QR Code. Ces technologies d'encodage permettent de stocker une grande
quantité d'information sur un espace réduit en comparaison des codes à barres à une seule
dimension.
Un mécanisme de correction d'erreurs permet également l'altération du code jusqu'à 30 % (QR
Code). Un usage détourné de la correction d'erreurs permet d'ailleurs l'inclusion de différents
éléments graphiques dans le code.
2.3.2.3 Structure générale
Le QR Code est composé de plusieurs parties distinctes. Certaines sont directement liées aux
données contenues dans le symbole (zone d’encodage), tandis que d’autres ont des fonctions
précises pour faciliter la lecture du QR Code (motifs fonctionnels ou function patterns). Le
symbole est formé de modules, généralement carrés, clairs et foncés [Figure 2.0.1].
Comme vous pouvez le voir sur la [figure 2.12], les motifs de détection de position sont
placés autour de trois des quatre coins afin d'aider à la détection du QR (de n'importe quelle
direction).
Les timings Patterns (motifs de distribution), qui sont des lignes composées en alternant les
modules noirs et blancs et en connectant deux motifs de position, sont utilisés pour aider à
déterminer un symbole de coordonnées.
Figure 2. 11: Un code barre classique Figure 2. 10: QR code
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 35
Figure 2. 12: Structure du QR code
Les Motifs d'alignement sont utilisés pour corriger l'asymétrie du code.
Certains modules autour du motif de position stockent les informations sur la version et le
Format (niveau de correction d'erreur et motif de masquage). Une marge blanche, ou «zone
claire», entoure le code.
B) Principe de fonctionnement général
De part sa représentation sur deux dimensions (ou représentation matricielle), le QR-code
peut stocker un plus grand nombre d'informations qu'un code barre monodimensionnel pour
une taille d'impression identique.
En effet, la matrice qui représente les données dans un QR-code, peut-être vue
schématiquement comme un tableau
ou l'on stocke des informations
verticalement (les colonnes) et
horizontalement (les lignes).
La lecture d'un QR code [13] peut se
faire indépendamment de l'orientation.
Il n'est en théorie pas nécessaire que le
lecteur et le code soient alignes. Par
exemple, le lecteur peut être penche de
90 degrés dans le sens horaire et le code oriente 30 dans le sens anti horaire, le décodage
Figure 2. 13: exemple d'encodage du QR code
Chapitre 2 Etat de l'art
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 36
opèrera quand même. Dans la pratique, cette indépendance de l'orientation est liée au lecteur,
c'est-a-dire a la partie logicielle qui traite l'image acquise, ainsi qu'au capteur et a sa
résolution. De trop grandes différences entre la position idéale et la position réelle peuvent
empêcher le décodage d'aboutir.
Le QR-code possède aussi un système de détection et de correction d'erreurs qui permet de
décoder et de retrouver les données, même lorsque le code est partiellement endommagé,
déchiré, ou salit. La tolérance aux erreurs varie de 7 a 30% selon le niveau de correction
d'erreur choisit lors de la création du QR code. [13]
Les données codées, typiquement du texte, font l'objet d'une normalisation. Il est possible
d'encoder le texte de plusieurs façons selon son contenu.
Par exemple, une chaine de caractères contenant uniquement des chiffres ne sera pas codée de
la même façon qu'une chaine de caractères contenant des lettres. De même, une chaine de
caractères contenant des Kanji (les caractères japonais), ne sera pas codée de la même
manière qu'un texte écrit en Français et contenant des caractères spécifiques a notre langue
(les accents, les cédilles, …).
Une description plus détaillée du QR code sera fournie en [annexe B].
Conclusion
Eu égard de ce qui précède, nous avons pu dénoter quelque problèmes majeurs liés à l’usage
des documents électroniques signés. Afin de bien cerner les concepts liés à la signature
électronique et au QR code, nous avons présenté quelques en grandes lignes quelques notions
cryptographiques d’une part et la description du code 2D d’autre part. Suite aux problèmes
qui se pose en se qui concerne le document électronique signé, nous avons pu répertorier
certains besoins. Ceci nous permet ainsi de passer au chapitre suivant porté sur la
spécification des besoins et des cas d’utilisation.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 37
Chapitre 3 Spécification et
Analyse des Besoins
Chapitre 3 Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 38
Introduction
La phase de spécification des besoins présente une étape primordiale dans le cycle de
développement d’un projet. En effet, elle permet de mieux comprendre le travail demandé en
dégageant les besoins des différents utilisateurs que le système doit accomplir. C’est ainsi que
nous aborderons dans ce chapitre une présentation détaillée des différents acteurs intervenant
sur le système et leurs rôles, ensuite les besoins fonctionnels et non fonctionnels relatif à
l’application, et enfin la spécification des différents cas d’utilisation et/ou diagrammes
d’activités.
3.1 Spécification des besoins fonctionnels
Les besoins fonctionnels permettent de lister les opérations pouvant être réalisées par notre
application. Elle doit pouvoir permettre la création et la lecture d’un QR code. Les besoins
détaillés sont listés dans le tableau ci – après.
Besoins Descriptions
Etape 1 : La signature
Vérifier la validité du certificat
Vérifie la révocation du certificat
Vérifier l’autorité émettrice du certificat
Vérifier le l’utilisation de la clé du certificat
la valeur de hachage est signée à l’aide de la clé
privée correspondant au certificat
Le fichier signé est sélectionné
Analyse des données à encoder et paramétrage du
niveau de code correcteur
Représentation des données en binaire
implémentation du code correcteur d’erreurs
insertion des données (contenant la signature) et
de code correcteur d’erreurs dans la matrice
génération de la matrice et évaluation du résultat
génération du QR Code au format image.
Chapitre 3 Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 39
3.2 Spécification des besoins opérationnels
Après avoir déterminé les besoins fonctionnels, nous présentons ci – dessous les besoins non
fonctionnels qui sont l’ensemble des contraintes à respecter pour garantir la performance du
système.
Interopérabilité : il est crucial de spécifier les règles d’usage pour pouvoir
déployer le projet de manière à ce qu’il soit fonctionnel dans l’environnement spécifié
(ici Android).
Uniformité : minimiser les variations autour de la solution
Facilité d’usage : s’assurer que les partenaires n’auront pas à acquérir pléthore
de matériels différents pour lire les différentes solutions.
Durabilité : s’assurer que le système mis en place puisse durer plusieurs
années et que les versions suivantes soient compatibles
3.3 Description des acteurs
L’objet de cette section est de présenter les acteurs et leurs rôles auxquels devra répondre
notre application.
Etape 2 : Création du QR
code
Etape 3 : Scan du QR
Code et vérification de la
signature
Scanner le code barres à 2D
Générer le fichier signé
Vérifier la validité du certificat du signataire
Vérifier la révocation du certificat du signataire
Vérifier l’autorité émettrice du certificat du
signataire
Vérifier le « key usage » du certificat du
signataire;
Génération du fichier original
Tableau 3. 1: Spécification des besoins fonctionnels
Chapitre 3 Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 40
Notre contexte est particulièrement marqué par la présence d’un seul acteur principal qui va
interagir avec le système :
Un utilisateur Android: il peut soit générer un QR à partir d’un document signé, soit
lire une image QR afin d’obtenir le fichier original.
3.4 Diagrammes des cas d’utilisation
Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un
tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le
futur système devra faire, sans spécifier comment il le fera.
3.4.1 Diagramme de cas d’utilisation global
(Voir figure 3.1)
Afin de décrire les interactions entre les cas d’utilisation, nous présentons ces derniers de
façon textuelle. Nous allons créer pour chaque cas d’utilisation une fiche qui va contenir :
Le nom du cas d’utilisation
Une description détaillée : des Pré-conditions au déclenchement du cas
d’utilisation doivent être spécifiées, un scénario nominal décrivant celui -ci
additionné à des scénarios alternatifs et d’exceptions et enfin des post
conditions sont précisées
Les besoins d’IHM (Interface Homme Machine) (optionnels): pour préciser
éventuellement les contraintes d’IHM.
Les exigences non fonctionnelles (optionnelles).
Chapitre 3
Visualisation Graphique des
Rédigé et pr
Figure 3.
Description du cas d’u
Dans le cas d’utilisation global l’
seront énumérées ci – après.
Acteur concerné : Utilisateur
Objectif : générer un document signé et le vé
Scénario nominal :
Pour générer un document signé l’utilisateur doit
signer électroniquement le document,
générer un QR
imprimer le document sur lequel le QR
Pour vérifier le document l’utilisateur doit
scanner le QR-
vérifier la signature du document,
générer le document électronique source.
Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Figure 3. 1: Diagramme de cas d'utilisation global
du cas d’utilisation global:
Dans le cas d’utilisation global l’acteur interagit avec le système en effectuant des tâches qui
Utilisateur Android.
générer un document signé et le vérifier.
Pour générer un document signé l’utilisateur doit :
signer électroniquement le document,
générer un QR-code,
imprimer le document sur lequel le QR-code est inséré. (optionnel)
Pour vérifier le document l’utilisateur doit :
-code,
vérifier la signature du document,
générer le document électronique source.
Analyse des besoins
lectroniques
Page 41
acteur interagit avec le système en effectuant des tâches qui
(optionnel)
Chapitre 3
Visualisation Graphique des
Rédigé et pr
3.4.2 Raffinement des cas d’utilisation
A. Raffinement du c
Figure 3.
Description L’utilisateur peut effectuer la signature d’un document
Acteur Un u
Objectif Signer un document
Pré – condition l'utilisateur doit avoir un certificat de signature électronique
Signer document
Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Raffinement des cas d’utilisation
Raffinement du cas d’utilisation « Signer document »
Figure 3. 2: Cas d’utilisation « Signer document »
L’utilisateur peut effectuer la signature d’un document
Un utilisateur
Signer un document
l'utilisateur doit avoir un certificat de signature électronique
Analyse des besoins
lectroniques
Page 42
L’utilisateur peut effectuer la signature d’un document
l'utilisateur doit avoir un certificat de signature électronique
Chapitre 3
Visualisation Graphique des
Rédigé et pr
B. Raffinement du cas d’utilisation «
Scénario nominal
Le système peut éventuellement générer le hash de
signature
Le système peut envelopper la signature avec le document
original
Scénario alternatif Si l’une des vérifications n’est pas établit alors la génération
de hash et l’enveloppement de la signature avec le document
origina
Post – condition Le système génère le fichier signé
Tableau 3. 2
Vérifier
Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Raffinement du cas d’utilisation « Vérifier Signature »
Effectuer les vérifications nécessaires :
Le système vérifie l’autorité de certification
Le système vérifie la validité du certificat
Le système vérifie l’utilisation de la clé
Le système vérifie la révocation du certificat
Le système peut éventuellement générer le hash de
signature (optionnel)
Le système peut envelopper la signature avec le document
original (optionnel)
Si l’une des vérifications n’est pas établit alors la génération
de hash et l’enveloppement de la signature avec le document
original ne peut pas être effectué.
Le système génère le fichier signé
2: Raffinement du cas d'utilisation « Signer document
Analyse des besoins
lectroniques
Page 43
:
Le système vérifie l’autorité de certification
Le système vérifie la validité du certificat
Le système vérifie l’utilisation de la clé
Le système vérifie la révocation du certificat
Le système peut éventuellement générer le hash de la
Le système peut envelopper la signature avec le document
Si l’une des vérifications n’est pas établit alors la génération
de hash et l’enveloppement de la signature avec le document
: Raffinement du cas d'utilisation « Signer document »
Chapitre 3 Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 44
Figure 3. 3: Cas d'utilisation « Vérifier signature »
Description Ce cas d’utilisation représente l’étape de vérification de la signature
d’un document électronique signé
Objectif vérifier la signature
Acteur Utilisateur
Pré – condition L’utilisateur possède un document électronique déjà signé
Scénario nominal
Le système effectuer les vérifications nécessaires :
Vérifier la validité du certificat du signataire
Vérifier l’autorité émettrice du certificat du signataire
Vérifier la révocation du certificat du signataire
Vérifier l’utilisation de la clé du certificat du signataire
o Les deux hash de la signature seront comparés
o Générer le hash du document original
Scénario alternatif Si l’une des vérifications n’est pas établit alors les deux hash de la
signature ne peuvent pas être comparés et la génération du hash du
document original ne peut pas être effectué.
Post – condition Le système génère le document original
Tableau 3. 3: Raffinement du cas d'utilisation Vérifier signature
3.5 Diagrammes d’activités
Ils permettent de représenter d’une façon dynamique le comportement d’une application.
Nous allons représenter deux diagrammes d’activité : l’un pour la signature d’un document
électronique et l’autre pour la génération du document électronique source
3.5.1 Diagramme d’activité : signature d’un document
Description : la signature du document après avoir effectué les vérifications nécessaires.
Chapitre 3
Visualisation Graphique des
Rédigé et pr
Figure 3. 4: Diagramme d’activité de
3.5.2 Diagramme d’activité
Description : le scan du QR
document original après avoir effectué les vérifications nécessaires.
Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
: Diagramme d’activité de signature d’un document
Diagramme d’activité : générer le document original
le scan du QR-code et l’extraction de la signature puis la génération du
document original après avoir effectué les vérifications nécessaires.
Analyse des besoins
lectroniques
Page 45
signature d’un document
: générer le document original
code et l’extraction de la signature puis la génération du
document original après avoir effectué les vérifications nécessaires.
Chapitre 3
Visualisation Graphique des
Rédigé et pr
Figure 3. 5: Diagramme d’activité de génération du document original
Conclusion
Ce chapitre nous a permis de définir les besoins fonctionnels
considération afin de pouvoir perfectionner ce travail
l’application et les acteurs qui y interviennent
cas au travers des diagrammes d’activité
essayerons dans le chapitre suivant de présenter clairement la conception de notre système.
Spécifications et Analyse des besoins
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
: Diagramme d’activité de génération du document original
Ce chapitre nous a permis de définir les besoins fonctionnels et non fonctionnels à prendre en
considération afin de pouvoir perfectionner ce travail, de spécifier les cas d'utilisation de
les acteurs qui y interviennent et la modélisation du comportement de certains
cas au travers des diagrammes d’activités. La spécification des besoins étant établie, nous
uivant de présenter clairement la conception de notre système.
Analyse des besoins
lectroniques
Page 46
: Diagramme d’activité de génération du document original
et non fonctionnels à prendre en
cifier les cas d'utilisation de
et la modélisation du comportement de certains
. La spécification des besoins étant établie, nous
uivant de présenter clairement la conception de notre système.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 47
Chapitre 4 Conception
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Introduction
La conception est la plus importante étape du cycle du développement logiciel. Elle
se base essentiellement sur la bonne spécification et l’a
nous aborderons la partie conception du projet dans laquelle nous détaillerons les différents
éléments de la conception à savoir
diagrammes d’activités.
4.1 Conception Détail
4.1.1
Le diagramme de paquetage (p
graphiquement les relations existantes
Figure 4.
4.1.2
Table descriptives des
Classe
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
La conception est la plus importante étape du cycle du développement logiciel. Elle
se base essentiellement sur la bonne spécification et l’analyse des besoins. Dans ce chapitre
nous aborderons la partie conception du projet dans laquelle nous détaillerons les différents
éléments de la conception à savoir : les diagrammes de classes, de séquences
Conception Détaillée
4.1.1 Le diagramme de paquetages
package en anglais) illustré à la figure 4.3 permet de représenter
existantes entre les paquetages composants notre système
Figure 4. 1: Diagramme de paquetage de l'application
4.1.2 Diagramme de classes technique
Table descriptives des différentes classes :
Description
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 48
La conception est la plus importante étape du cycle du développement logiciel. Elle
nalyse des besoins. Dans ce chapitre
nous aborderons la partie conception du projet dans laquelle nous détaillerons les différents
, de séquences et les
permet de représenter
notre système.
technique
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 49
A) Diagramme de classe technique du package signature_CMS :
Voir [figure 4.2]
Package 1 : Signature_CMS
Cette classe permet de signer un fichier avec un certificat Signer
Cette classe permet de charger le fichier signé et de vérifier la
signature
Verifier
Package 2 : Verification_certificat
Extrait le CRL et vérifie l’état de révocation de certificats CRLVerifier
Vérifier l'autorité émettrice du certificat : Récupérer le CA et
vérifier si le certificat est auto signer
CertChainValidator
Vérifier l'utilisation de la clé du certificat
GetKeyUsage
Cette classe permet de verifier la validité du certificat TimeValidityVerif
Package 3 : certification Cette classe permet la connexion au certificat par :
le chargement du fichier .PKC
La récupération du certificat
La récupération de la clé privée
La récupération de la clé publique
Connection_Certif
Cette classe permet la connexion au serveur LDAP Connection_Ldap
Permet de crypter le certificat par la méthode de hashage sha2 Hashage_sha1
Tableau 4. 1: Description des classes relatives à la Signature électronique
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Figure 4.
B) Diagramme de classe technique du
Figure 4.
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Figure 4. 2: D.C.T du package signature_CMS
Diagramme de classe technique du « package vérification_certificat
Figure 4. 3: D.C.T du package vérification_certificat
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 50
package vérification_certificat » :
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
C) Diagramme de classe technique du
Figure 4.
D) Diagramme de classe technique du package activity
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Diagramme de classe technique du « package certification » :
Figure 4. 4: D.C.T du package certification
Diagramme de classe technique du package activity :
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 51
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 52
Figure 4. 5: diagramme de classe du package activity
Le package Activity contient l’ensemble des classes permettant d’implémenter l’interface
utilisateur et permet aussi d’exploiter les classes d’encodage / décodage du QR code du
« package engine »
La classe MainActivity : c’est la première classe qui est démarrée au lancement de
l’application. Elle permet à l’utilisateur de choisir l’action qu’il souhaiterait effectuer :
soit aller à la section de génération du QR code (EncodeListActivity) soit aller à la
section de lecture du QR code (DecodeListActivity).
La classe CameraDecodeActivit : elle permet à l’utilisateur de scanner le QR acqui à
partir de l'entrée de la caméra, qui est affichée sur écran de sorte que l'utilisateur
puisse orienter l'objectif de caméra vers elle. Si un fichier est décodé, il est renvoyé
vers la liste des fichiers décodés (DecodedListActivity).
La classe DecodeListActivity : elle affiche la liste des fichiers décodés, que
l’utilisateur peut manipuler de diverses manières. Elle permet à l'utilisateur de
démarrer le décodage d'un fichier à partir d'un QR soit par chargement d'une image du
système de fichiers (activités OI FileManager) ou par la caméra
(CameraDecodeActivity). Le fichier décodé est ajouté à la liste.
La classe EncodeListActivity : affiche la liste des images QR encodées que
l’utilisateur peut manipuler de diverses façons. Elle permet à l’utilisateur d’ouvrir un
fichier depuis le système (activités OI FileManager) et commencer le processus
d’encodage du QR (EncodeActivity). L’image QR encodée est automatiquement
ajoutée à la liste.
E) Diagramme de classe technique du « package engine » :
Ce package contient les principales classes du processus d’encodage et de décodage du QR
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Figure 4. 6: Diagramme de classe technique du package
Description des Classes du package «
Classe
FileFromQrDecoder
FileToQrEncoder
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
: Diagramme de classe technique du package « engine
Description des Classes du package « engine »
Description
Elle capture les octets bruts d'un QR trouvée dans une image
et les interprète en fonction de la procédure
sera décrite au prochain chapitre) pour obtenir le fichier
encodé.
Cette classe permet de lire un fichier et d’en
du QR dans lequel il a été encodé.
elle fait appel à la classe QrByteWriter pour obtenir la matrice
d’octets (ou BytesMatrix en anglais) contenant les octets du
bitmap du QR, et convertir pour convertir la matrice
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 53
engine »
les octets bruts d'un QR trouvée dans une image
procédure d’encodage (qui
pour obtenir le fichier
d’en retourner le Bitmap
pour obtenir la matrice
contenant les octets du
la matrice en Bitmap
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 54
QrByteWriter Elle retourne une ByteMatrix de valeurs d’échelle de gris qui
sont des octets de l'image bitmap du QR ; elle fait appel à la
classe QrByteEncoder pour obtenir un objet QR Code;
QrByteEncoder Cette classe retourne une ByteMatrix de valeurs noir/blanc
PlanarYUVLuminanceSource Cette classe permet de supprimer les pixels super-flux du Qr-code
RGBLuminanceSource Elle transforme une capture de l’image en couleur en une image en noir et blanc (tableau de gris)
Tableau 4. 2: Description des classes du package engine
4.2 Diagramme de séquence technique
Le diagramme de séquence décrit l’aspect dynamique du système. Il modélise les interactions
entre les objets ou entre utilisateur et objet, en mettant l’accent sur la chronologie des
messages échangés. Dans ce qui suit, nous allons dresser les diagrammes de séquences de
chaque cas d’utilisation :
4.2.1 Diagramme de séquence technique du cas d’utilisation « signer un
document »
La figure 4.9 ci – dessous illustre ce diagramme
Acteur : Un utilisateur
Description : l’utilisateur peut signer un document après que le système ait effectué les
vérifications nécessaires
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Figure 4. 7: D.S.T de génération d’un document électronique si
Tableau 4. 3: tableau descriptif du diagramme séquence technique
Classe
Signer
Connection-certif
CRLVerifier
TimeValidityVerif
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
: D.S.T de génération d’un document électronique si
: tableau descriptif du diagramme séquence technique
Méthode Information
getKeyStore()
Charger le fichier
Envelopper la signature
avec le document
original
recup-certif() Récupérer certificat
recup-privKey() Récupérer la clé privée
recup-publicKey() Récupérer la clé publique
verifyCertificateCRLs() Vérifier la révocation du
certificat
CheckTimeValidity() Vérifier la validité du certific
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 55
: D.S.T de génération d’un document électronique signé
: tableau descriptif du diagramme séquence technique
Information
Charger le fichier
Envelopper la signature
avec le document
original
Récupérer certificat
Récupérer la clé privée
Récupérer la clé publique
Vérifier la révocation du
Vérifier la validité du certificat
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
GetKeyUsage
CertChaineValidator
Hashage-sha1
4.2.1
Figure 4.
Acteur : Un utilisateur
Description : l’utilisateur peut générer le document original depuis un QR
système effectue les vérifications
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
VerifyKeyUsage() Vérifier l’utilisation de la clé
isSelfSigned() Vérifier l’autorité de
certification
Hashage-sha1 () Générer le hash de la signature
4.2.1 Diagramme de séquence technique du cas
d’utilisation « Vérifier document »
Figure 4. 8: D.S.T de vérification de document
l’utilisateur peut générer le document original depuis un QR-
système effectue les vérifications
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 56
Vérifier l’utilisation de la clé
Vérifier l’autorité de
certification
Générer le hash de la signature
Diagramme de séquence technique du cas
-code après que le
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 57
Tableau 4. 4: Tableau de séquence technique 2
Classe Méthode Information
Diagramme de séquence D1
C’est le diagramme de génération du
code électronique source technique
Verifier
verifier()
Charger le fichier signé
Extraire la signature
Vérifier les deux hashs du
certificat
CRLVerifier verifycertificateCRLs() Vérifier la révocation du certificat
TimeValidityVerif checkTimeValidity() Vérifier la validité du certificat
GetKeyUsage verifyKeyUsage() Vérifier l’utilisation de la clé
CertChaineValidator isSelfSigned() Vérifier l’autorité de certification
4.2.2 Diagramme de séquence technique du cas
d’utilisation « Scanner QR Code »
La figure 4.11 illustre ce diagramme.
Tableau 4. 5: Tableau de séquence technique 3
Classe Méthode Information
CameraDecodeActivity surfaceChanged() Capture et lecture de la surface
de QR Code
RGBLuminanceSource
RGBLuminanceSource() Transformer les couleurs en
tant du gris.
PlanarYUVLuminanceSource renderCroppedGreyscaleBitmap() Exclure les pixels superflux
FileFromQrDecoder
decodeFile()
decodeFromQr()
Conversion du binaire en code
ascii
Conversion du code ascii en
texte original
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Figure 4. 9: D.S.T Lecture du QR code
4.2.3
La figure 4.12 illustre ce scénario.
Description : l’utilisateur envoie le document au système pour avoir le QR
Acteur : Un utilisateur
Scénario nominal
L’utilisateur envoie le document.
Analyse de la langueur du document.
Extraction des caractères.
Récupération du code ascii.
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Lecture du QR code depuis la capture de la caméra et génération du fichier original
4.2.3 Diagramme de séquence technique du cas
d’utilisation « créer un QR Code »
illustre ce scénario.
l’utilisateur envoie le document au système pour avoir le QR
L’utilisateur envoie le document.
Analyse de la langueur du document.
Extraction des caractères.
Récupération du code ascii.
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 58
et génération du fichier original
Diagramme de séquence technique du cas
l’utilisateur envoie le document au système pour avoir le QR-code.
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 59
Conversion en nombre binaire.
Transformation en matrice de données (data matrix).
Affichage du QR-code.
Tableau 4. 6: tableau de classe technique 4
Classe Méthode Information
FileToQrEncoder encodeToQR() Extraire les caractères
Recup_ASCII() Récupérer le code ascii
encodeToQR() Convertir en nombre binaire
QrByteEncoder encode() Transformer en data matrix
QrByteWriter renderResult() Dessiner le QR-code
EncodeActivity
startEncodingForCurrentPhase() Transformer en QR-code
saveEncodedImage() Enregistrer sous format png
sur la carte sd.
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des
Rédigé et pr
Figure 4.
Conclusion
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles de l’application
à réaliser à travers les modèles UML nécessaires. Cette conception est essentielle pour la
phase de réalisation qui constitue l’
Chapitre 4_______________________________________________________ Conception
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Figure 4. 10: D.S.T de génération d’un QR-code
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles de l’application
à réaliser à travers les modèles UML nécessaires. Cette conception est essentielle pour la
de réalisation qui constitue l’objet du chapitre suivant.
Chapitre 4_______________________________________________________ Conception
lectroniques
Page 60
Dans ce chapitre nous avons détaillé les différentes vues conceptuelles de l’application
à réaliser à travers les modèles UML nécessaires. Cette conception est essentielle pour la
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 61
Chapitre 5 Implémentation
Chapitre 5
Visualisation Graphique des
Rédigé et pr
Introduction
Dans ce chapitre, nous présentons l’environnement matériel et logiciel du projet.
Ensuite, nous nous intéressons à la descrip
implémenté dans le cadre de quelques scénarios d’utilisation.
5.1 Environnement de travail
5.1.1 Environnement matériel
Machine de développement : ordinateur portable
Figure 5.
5.1.2 Environnement logiciel
Système d’exploitation : Windows XP professionnel
Technologie Android : Système d'exploitation open
terminaux mobiles (Voir annexe C pour plus de détails
IDE : NetBeans 7.4 ; E
Modélisation UML: Power AMC Designer de Sybase 15.1
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
Dans ce chapitre, nous présentons l’environnement matériel et logiciel du projet.
Ensuite, nous nous intéressons à la description de quelques interfaces du système
implémenté dans le cadre de quelques scénarios d’utilisation.
Environnement de travail
Environnement matériel
Machine de développement : ordinateur portable ASUS K53E
Figure 5. 1: Environnement matériel
Environnement logiciel
Système d’exploitation : Windows XP professionnel
: Système d'exploitation open source pour Smartphones, PDA et
x mobiles (Voir annexe C pour plus de détails)
Eclipse
Power AMC Designer de Sybase 15.1
Implémentation
lectroniques
Page 62
Dans ce chapitre, nous présentons l’environnement matériel et logiciel du projet.
tion de quelques interfaces du système
Smartphones, PDA et
Chapitre 5
Visualisation Graphique des
Rédigé et pr
5.2 Méthode de conception
Pour la mise en œuvre de notre application, nous avons choisi modèle d’architecture logiciel
MVC (Modèle – Vue – Contrôleur).
Modèles: fournisseurs de contenu.
Les gestionnaires de données qui sont la forme recommandée de partage de données entre les
applications.
Vues: Activités.
Ceci est le composant de l'interface utilisateur de l'application primaire. Chaque écran
individuel d'une application Android est dér
(android.app.Activity). Ils sont des conteneurs pour les vues (android.view.View).
Contrôleurs: Services
Ce sont des éléments de fond qui se comportent comme des démons UNIX et les services
Windows. Ils s’exécutent de mani
5.2 Diagramme de déploiement
L’utilisateur se connecte au serveur LDAP de l’ANCE pour avoir la clé publique, la liste des
certificats révoqués et l'autorité de certification à partir de
Figure 5.
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
de conception
Pour la mise en œuvre de notre application, nous avons choisi modèle d’architecture logiciel
ontrôleur).
fournisseurs de contenu.
es gestionnaires de données qui sont la forme recommandée de partage de données entre les
Ceci est le composant de l'interface utilisateur de l'application primaire. Chaque écran
individuel d'une application Android est dérivé de la classe Java Activity
(android.app.Activity). Ils sont des conteneurs pour les vues (android.view.View).
Ce sont des éléments de fond qui se comportent comme des démons UNIX et les services
Windows. Ils s’exécutent de manière invisible et effectuent un traitement sans surveillance.
Diagramme de déploiement :
L’utilisateur se connecte au serveur LDAP de l’ANCE pour avoir la clé publique, la liste des
certificats révoqués et l'autorité de certification à partir de son Smartphone qui contient déjà
Figure 5. 2: Architecture MVC Android
Réalisation
lectroniques
Page 63
Pour la mise en œuvre de notre application, nous avons choisi modèle d’architecture logiciel
es gestionnaires de données qui sont la forme recommandée de partage de données entre les
Ceci est le composant de l'interface utilisateur de l'application primaire. Chaque écran
ivé de la classe Java Activity
(android.app.Activity). Ils sont des conteneurs pour les vues (android.view.View).
Ce sont des éléments de fond qui se comportent comme des démons UNIX et les services
ère invisible et effectuent un traitement sans surveillance.
L’utilisateur se connecte au serveur LDAP de l’ANCE pour avoir la clé publique, la liste des
son Smartphone qui contient déjà
Chapitre 5
Visualisation Graphique des
Rédigé et pr
l’application installée. Après avoir effectué les traitements nécessaires il peut imprimer le
traçage graphique des preuves électroniques.
5.3 Les bibliothèques utilisées
5.3.1 Zxing (Zebra Crossing
ZXing est un projet open-source multi
mis en œuvre en Java. Ce projet met l'accent sur l'utilisation de la caméra intégrée sur les
téléphones mobiles et de décoder les codes
serveur.
Les formats pouvant être décodés sont :
o UPC-A and UPC
o EAN-8 and EAN
o Code 39
o Code 128
o QR Code
o Data Matrix (alpha quality)
Visualisation Graphique des Preuves Electroniques
édigé et présenté par Olga AMBANI BALLA
l’application installée. Après avoir effectué les traitements nécessaires il peut imprimer le
traçage graphique des preuves électroniques.
Figure 5. 3: Diagramme de déploiement
s utilisées
Zxing (Zebra Crossing)
source multi-format de code-barres 1D/2D de traitement d'images
mis en œuvre en Java. Ce projet met l'accent sur l'utilisation de la caméra intégrée sur les
les et de décoder les codes-barres sur l'appareil, sans communiquer avec un
Les formats pouvant être décodés sont :
A and UPC-E
8 and EAN-13
alpha quality)
Réalisation
lectroniques
Page 64
l’application installée. Après avoir effectué les traitements nécessaires il peut imprimer le
barres 1D/2D de traitement d'images
mis en œuvre en Java. Ce projet met l'accent sur l'utilisation de la caméra intégrée sur les
barres sur l'appareil, sans communiquer avec un
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 65
5.3.2 Bouncy Castle
Bouncy Castle est une bibliothèque de cryptographie libre et open-source. Elle s'apparente à
la librairie C openssl qui est conforme aux différents standards en vigueur.
Bouncy Castle n'est pas installé de base sur les plateformes java.
5.4 Interfaces de l’application
Nous exposerons quelques interfaces de notre application, en essayant à chaque fois de
décrire les différents objets interactifs mis à la disposition de l’utilisateur.
Lors de lancement de l’application, une interface
(Figure 5.4) apparaît mentionnant le nom de
l’application et l’entreprise éditrice de la solution à
savoir l’ANCE.
Cette interface offre deux choix à l’utilisateur entre
deux boutons :
générer le QR Code à partir d’un fichier signé
Scanner une image QR
Lorsque l’utilisateur clique sur le bouton de
génération du QR (le premier bouton), l’interface
d’encode apparaît (figure 5.5)
Cette interface (figure 5.5) permet à l’utilisateur de :
Visualiser les fichiers déjà encodés en QR sous
le format image .png enregistrés sous
/mnt/sdcard/SignDoc2QR/encode
Lorsqu’il clique sur le bouton d’encodage, une
nouvelle interface (figure 5.8) lui permettant de
Figure 5. 5: Interface d'encodage avec la liste des fichiers encodés
Figure 5. 4: Interface d'accueil
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 66
choisir le fichier à encoder apparaît ; il s’agit du chemin vers la carte SD (/mnt/sdcard/) »
Dans cette interface, l'utilisateur peut accéder
au fichier signé souhaité pour l’encoder.
L’utilisateur peut soit sélectionner le fichier,
soit écrire le nom du fichier directement au
niveau de la zone de texte.
Ensuite il devra cliquer sur le bouton « open »
pour valider sa sélection (figure 5.6) et lancer
le processus de génération du QR.
Figure 5. 6: interface Listant le contenu de la sdcard
Figure 5. 7: Interface de sélection du fichier à encoder
Figure 5. 8: Interface lancement du processus d'encodage
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 67
Après cette étape, l’application démarre le processus de génération du QR code du fichier
signé qui vient d’être sélectionné. (Figure 5.11) Le résultat final de l’encodage est visualisé
sur l’interface suivante. (Figure 5.9)
Figure 5. 10: Interface de génération du résultat de l'encodage
Figure 5. 9: Interface Résultat du QR généré
L’interface de la figure 5.10
présente la liste des fichiers
encodés.
Lorsqu’un fichier est
encodé, il est automatique
ajouté à cette liste
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 68
Le bouton de scan du QR accessible depuis l’interface d’accueil renvoie l’utilisateur vers une
nouvelle interface contenant la liste des fichiers décodés (Figure 5.12).
Figure 5. 12: Interface liste des fichiers décodés
Figure 5. 11: liste des fichiers encodés
Cette interface contient en plus deux
boutons permettant à l’utilisateur de
scanner une image QR suivant deux
modes opérationnels :
Lecture d’une image QR
contenu dans la sdcard
Lecture d’une image QR
capturée depuis la camera.
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 69
Figure 5. 13: Décodage du QR
Figure 5. 14: interface liste des fichiers décodés
Après avoir choisi l’image
QR qu’on souhaite décoder,
l’interface de la figure 5.13
est présentée à l’utilisateur
Cette interface (figure 5.14)
s’affiche juste après et on
remarque un commentaire qui
fait savoir à l’utilisateur que son
fichier a bien été décodé et
enregistré dans la liste.
Chapitre 5 Réalisation
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 70
Conclusion
Dans ce chapitre nous avons détaillé les technologies utilisées pour la réalisation de notre
projet ainsi que les fonctionnalités de base de l’application à travers un ensemble de captures
d’écran.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 71
Conclusion générale
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 72
Conclusion générale et perspectives
C’est dans le cadre de l’évolution des besoins de sécurisation des documents électroniques
signés après impression et des exigences des entreprises par rapport à la validité d’usage de
ces documents comme pièce justificatives lors des démarches administratives, que se situe
notre projet de fin d’ étude dont l’objectif était d’implémenter une solution pour la
visualisation graphique des preuves électroniques à l’aide d’un QR code.
Nous avons fait face à quelques contraintes techniques au niveau de la phase de
développement. En effet le mode d’encodage choisi ne pouvant coder que 2953 octets, le
fichier signé à encoder ne devait pas dépasser 2.9 kilo octet, nous avons été amenés à
simplifier l’opération de la signature afin de générer un fichier signé plus léger.
Ce projet nous a donné la possibilité de découvrir de nouvelles approches de développement
mobile (Android). Il nous a permis de mettre à profit un panel de connaissances variées qui
s'étend de la conception, en passant par l'optimisation et les tests, ainsi que par la recherche
de solutions à de nouveaux problèmes.
S’étant basés sur le processus de conception unifié 2TUP, nous avons procédé par une étude
détaillée du contexte du projet, ses domaines d’application, une définition de la problématique
et une analyse des besoins fonctionnels et non fonctionnels de la solution ainsi que les
cas d’utilisations possibles. Puis nous avons entamé la phase de conception et de la
réalisation de l’application.
Afin d'améliorer notre application nous proposons plusieurs perspectives d'évolutions qui
n'ont pas pu être développées en plus de la fonction du Scan à partir de la caméra qui n’a pas
pus être validée faute du temps qui nous a été imparti:
Ajout d’une fonctionnalité permettant de faire tourner notre application en mode web.
Ajout d’une fonctionnalité permettant de faire tourner l’application sur d’autres
plateformes mobiles (ios, blackberry…).
Ajouter une fonctionnalité qui permettrait de générer une série de QR code à partir
d’un seul fichier. Cela permettra de stocker des données plus importantes (certificat
du signataire, du CA, le CRL). Ces QR-codes devraient être scannés les uns après les
autres afin de retrouver la ressource initiale.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 73
L’expérience au sein d’un cadre professionnel, nous a été bénéfique. Ce stage nous a permis
de nous familiariser à la vie professionnelle, d’exploiter des notions fondamentales dans
L’orienté objet, et d’approfondir nos connaissances théoriques.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 74
Bibliographie
[1] : Mémoire, URL : http://cerig.efpg.inpg.fr/memoire/2012/codes-2D.htm#map-code-
2d_analyse
[2] : Agence Nationale de Certification Electronique [en ligne] URL :
http://www.certification.tn/fr/content/presentation-de-l-ance
[3] : QR Code, http://qrcode.fr/
[4] : Pascal, Roques. « UML2 Modéliser une application web ». Eyrolles 4e edition
2008. pp.233-235
[5] Ministère des Finances, « Les factures numériques certifiées par l’ANCE ne sont pas
valides »URL:http://www.thd.tn/index.php?option=com_content&view=article&id=3
297%3Aministere-des-finances-les-factures-numeriques-certifiees-par-l-ance-ne-sont-
pas-valides&catid=58%3Awebsphere&Itemid=88
[6] : http://www.webappsec.org/
[7] : http://www.qualys.com/docs/qualys-was-guide-fr.pdf
[8] : www.commentcamarche.net/contents/85-introduction-a-l-authentification
[9] : Thierry Piette-Coudol. « La signature électronique ». LexisNexis 2001 pp.98-102.
[10] : http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
[11] : PKI, https://www.securiteinfo.com/cryptographie/pki.shtml
[12] : QR code http://qrcode.fr
[13] : http://www-igm.univ-mlv.fr/~dr/XPOSE2011/QRCode/workflows.html#1
[14] THESE : Ingénierie des Systèmes Logiciels, Dr. Marcellin Julius
NKENLIFACK
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 75
Annexes
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 76
Annexe A : choix de la méthodologie de conception
A.1 Processus Unifié
Afin de contrôler les risques et de mener à bon terme notre projet vu sa complexité, on suivra
un processus unifié puisque : Le Processus Unifié [14] (UP, pour Unified Process) est
un processus de développement logiciel : « itératif et incrémental, centré sur l’architecture,
conduit par les cas d’utilisation et piloté par les risques » :
Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1
mois) qui aident à mieux suivre l’avancement global. À la fin de chaque itération,
une partie exécutable du système final est produite, de façon incrémentale.
Centré sur l’architecture : tout système complexe doit être décomposé en
parties modulaires afin de garantir une maintenance et une évolution facilitées.
Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en
UML et pas seulement documentée en texte.
Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt,
mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce
cadre déterminent l’ordre des itérations. Conduit par les cas d’utilisation : le projet est
mené en tenant compte des besoins et des exigences des utilisateurs. Les cas
d’utilisation du futur système sont identifiés, décrits avec précision et priorisés.
A.2 Comparaison des méthodologies
Les processus unifiés sont présentés par les processus RUP et 2TUP, le tableau suivant
présente une synthèse des plus connues méthodologies de UML :
Annexe A choix de la méthodologie de conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 77
D’après cette comparaison, on constate qu’il est plus fiable dans notre cas d’utiliser la
méthode 2TUP. [9]
Tableau A. 1: Synthèse des méthodologies utilisées dans le cadre de développement objet et nouvelles technologie [25]
Annexe A choix de la méthodologie de conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 78
A.2.1 2 track unified process (2TUP)
2TUP, signifie « 2 Track Unified Process», est un processus de développement logiciel unifié
qui implémente le Processus Unifié. Il gère la complexité technologique en donnant part à la
technologie dans son processus de développement. Il consiste à la dissociation des aspects
techniques des aspects fonctionnels. Il répond aux caractéristiques du Processus Unifié.
Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées
aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités
d’évolution et de correction de tels systèmes.
« 2 Tracks» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins
fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de
changement imposés au système d’informations comme le montre la figure A.1
La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise. Elle
constitue généralement un investissement pour le moyen et le long terme. Les fonctions du
Figure A. 1: Le processus de développement en Y
Annexe A choix de la méthodologie de conception
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 79
système d’informations sont en effet indépendantes des technologies utilisées. Cette branche
comporte les étapes suivantes :
La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur
le métier des utilisateurs.
L’analyse Qui génère des modèles statiques et dynamiques La branche droite
(architecture technique) : capitalise un savoir -faire technique. Elle constitue un
investissement pour le court et moyen ter me. Les techniques développées pour le
système peuvent l’être en effet indépendamment des fonctions à réaliser. Cette
branche comporte les étapes suivantes :
La capture des besoins techniques.
La conception générique.
La branche du milieu: à l’issue des évolutions du modèle fonctionnel et de l’architecture
technique, la réalisation du système consiste à fusionner les résultats des deux branches.
Cette fusion conduit à l’obtention d’un processus en forme de Y. Cette branche comporte les
étapes suivantes :
La conception préliminaire.
La conception détaillée.
Le codage.
Les recettes.
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 80
Annexe B : Notion de QR Code
B.1 Présentation du QR
Le QR Code a été inventé en 1994 par Denso Wave pour améliorer et sécuriser la
traçabilité des pièces dans l’industrie automobile japonaise. En 1999, il devient une
référence au Japon et passe sous licence libre. Son format est direct c’est-à-dire que les
données sont directement contenues dans le code. QR signifie Quick Response : le
contenu peut-être décodé rapidement. Il peut stocker un grand nombre de données,
verticalement et horizontalement : jusqu’à 7089 caractères numériques et 4296 caractères
alphanumériques, alors que le code-barres classique ne contient qu’une vingtaine de
caractères [Figure B.1].
Figure B. 1: Comparaison des capacités de stockage des données entre le QR Code et le code-barres
Créer un QR Code est accessible à tous. Il existe de nombreux générateurs de QR Code en
ligne ou via des logiciels à télécharger. Quelque soit la solution choisie, elle est souvent
gratuite (la licence relevant du domaine public) et simple d’utilisation.
Les générateurs de codes 2D ne proposent pas tous les mêmes options. Par exemple, les
deux générateurs de QR Code présentés ci-dessous permettent de choisir le niveau de
correction d’erreurs [Figure B.2]. Cette option n'existe pas dans tous les générateurs.
Autre exemple : l’un des deux propose la génération d’un micro QR Code. Ainsi, il faut
trouver le générateur offrant les options qui seront utiles. Il peut aussi être intéressant de
développer son propre générateur. Sur Internet, il est assez facile de trouver des codes de
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 81
générateurs – que l’on peut s’approprier – ou des bouts de codes expliqués (le tout en
PHP).
Annexe B Notion de QR Code
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 82
Figure B. 2: Deux exemples de générateurs de QR Code en ligne : [codeqrnews] et [keremerkan]
Pour lire le contenu du QR Code, il est nécessaire de posséder un téléphone doté d'un
appareil photo et d'une application permettant de le décoder. Il peut mémoriser du texte,
une adresse Web (URL), une adresse de messagerie, un numéro de téléphone, un
évènement... Le QR Code est normalisé par la norme ISO 18004.
B.2 Création d’un QR code
Étape 1 - Analyse des données pour en déterminer le type
Il existe quatre types de données :
Données numériques (chiffres de 0 à 9)
Données alphanumériques (chiffres de 0 à 9 + caractères de A à Z + 9
caractères espace $ % * + - . / :)
Données codées sur 8 bits (tous les caractères latins + de nombreux
caractères)
kanji (utilisé pour les langues asiatiques notamment)
Étape 2 - Encodage des données
Il faut rappeler tout d'abord que lors de la génération du QR Code, on décidera du taux de
correction d'erreur à appliquer au QR Code. En effet, un QR Code peut être généré avec 4
niveaux de taux de correction d'erreur différents selon les spécifications et qui permettent
d'obtenir une certaine tolérance quant à la perte d'informations exprimée en pourcentage.
L : LOW, permet une tolérance jusqu'à 7% de perte de code.
Annexe B Notion de QR Code
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 83
M : MEDIUM, permet une tolérance jusqu'à 15%.
Q : QUALITY, permet une tolérance jusqu'à 25%.
H : HIGH, permet une tolérance jusqu'à 30%.
Déroulons l'algorithme d'encodage d'un QR Code :
1 - Analyse des données à encoder et paramétrage du niveau de code correcteur : Le but
est d'analyser le flux de données d'entrée pour identifier la variété des caractères différents
pour être encodés. Si l'utilisateur n'a pas spécifié le niveau de code correcteur, la plus
petite version de QR Code sera sélectionnée pour accueillir les données.
2 - Convertir les caractères de données dans un flux de bytes : Ce sont par exemple, en
langage Java, des objets ByteArray qui seront utilisés.
3- Implémenter la correction des erreurs. : Le but est de séparer par blocs les bits de
données et de génerer leurs codes correcteurs. Comme vu pour le code de Reed-Solomon, on
place un bit d'information et autour, on génère du code correcteur.
4 - Insérer les données avec le code correcteur dans la matrice : On utilise ici le masque
de patterns (Timing pattern, pattern de detection, pattern d'alignement)
5 - Générer la matrice et évaluer le résultat qu'elle retourne : On optimise ici la balance
entre les modules noirs et les modules blancs et on minimise l'occurrence de patterns
indésirables
6 - générer le QR Code au format image : C'est le résultat final qui pourra être lu par un
lecteur de QR Code.
B.3 Lecture d’un QR Code
C'est bien beau d'avoir créer un QR Code mais encore faut-il savoir comment le lire.
Déroulons donc l'algorithme de lecture :
1 - Reconnaître les bits 1 ou 0. Le but est de différencier les modules noirs des
modules blancs.
2 - Identifier le taux de code correcteur.
3 - Identifier la version du QR Code.
4 - Découvrir la région à décoder.
5 - Lire les données et le code correcteur.
6 - Détecter/Corriger les erreurs.
Annexe B Notion de QR Code
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 84
7 - Décoder les données.
8 - Afficher le résultat.
Toutes ces étapes de lecture se feront pour la plupart grâce à la détection des patterns du QR
Code et à leur lecture. Voici ci-dessous le diagramme de flux de la lecture :
Figure B. 3: le diagramme de flux de la lecture
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 85
Annexe C : Architecture d’Android
La figure C.1 suivante schématise l'architecture d'Android. Chaque section sera décrit dans les
paragraphes qui vont suivre.
Figure C. 1: Architecture d'Android
Applications
Android est fourni avec un ensemble d’applications dont un client email, une
application SMS, un calendrier, un service de cartographie, un navigateur etc. Toutes écrites
en JAVA.
Frame work de développement
En fournissant une plateforme de développement ouverte, Android offre aux développeurs la
possibilité de créer des applications extrêmement riches et innovants. L’architecture
d’application est conçue pour simplifier la réutilisation des composants.
Annexe C Architecture Android
Visualisation Graphique des Preuves Electroniques
Rédigé et présenté par Olga AMBANI BALLA Page 86
Bibliothèques
Android dispose d’un ensemble de librairies C/C++ utilisées par les différents composants du
système Android. Elles sont offertes aux développeurs à travers le framework Android.
Android Runtime
Android inclut un ensemble de librairies de base offrant la plupart des fonctionnalités
disponibles dans les bibliothèques de base du langage de programmation Java. Chaque
application Android s’exécute dans son propre processus, avec sa propre instance de la
machine virtuelle Dalvik. Elle a été écrite pour que le dispositif puisse faire tourner
plusieurs machines virtuelles de manière efficace. La machine virtuelle Dalvik s’appuie sur
le noyau Linux pour les fonctionnalités de base telles que le filetage et gestion de la
mémoire de bas niveau.
Linux Kernel
Android repose sur la version Linux 2.6 pour les services système de base tels que la sécurité,
la gestion mémoire, gestion de processus pile réseau, et le modèle de pilote. Le noyau agit
également comme une couche d’abstraction entre le matériel et le reste de la pile logicielle.