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.
Visualisation graphique des preuves Électroniques (complet)
1. 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
bien-encouragements
« A Ma mère spirituelle la Rev
Qui n’a jamais cessé de me soutenir moralement, financièrement et
Du fond de mon coeur 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
Dédicaces
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
a »
tu m’as porté,
tu m’as témoigné pour tous les efforts et les
cessé de consentir pour mon instruction et mon bien
sacrifices
s J’espère avoir répondu aux
Je te rends hommage par ce modeste travail en
procure santé, bonheur et longue vie pour que vous
enfants .
Marthe Aurore Békombo
»
spirituellement.
merci pour tous les sacrifices que tu as fais et que tu
. on Minlo Célestin
insuffisant compte tenu de ce tu as souvent
universitaire. Que Dieu dans sa g
Ma chère et grande famille»
soit l’expression des voeux que vous
Que Dieu vous accorde santé et
soeur chérie BeKono Marthe Nadine
« A tous mes Ami(e)s»
Audace Manirabona. Merci pour ton aide.
lectroniques
1BHF
i souvienne de toi.
lestin »
fisant fait
grâce puisse te
n’avez cessé de
longue vie. Une
Nadine.
Olga Ambani
2. Remerciements
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’oeuvre 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…
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
11. Introduction générale _ ________
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
12. Introduction générale _ ________
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
14. Chapitre 1
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
donner un aperçu général de notre projet.
nous délimi
Nous
délimiterons le cadre de
adoptée dans le cadre de ce projet.
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
obtention diplôme
l'Ecole Polytechnique de Sousse. Il a été effectué au sein
Agence Certification Electronique (ANCE) avec comme intitulé du
1.2 Présentation de l'organisme
l'obtention du
».
d'accueil
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.
Visualisation Graphique des
3ÏEJHÏFUQS
Présentation générale
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
ale Figure 1. 1: Logo de l'ANCE
électronique a commencé depuis 1997, l’année qui a été
E-governement). Il a été relevé la
infrastructure à clé publique et un cadre légal. [2]
la loi n° 2000-83 du 09 aout
de réglementation des échanges et du commerce
, de la technologie et est l’autorité de c
lectroniques
1BHF
ertification 2000 a mis
l’Agence
certification
15. Chapitre 1 Présentation générale
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 à
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
16. Chapitre 1
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 nique 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
réalisation d'une application Androi
1. 2: Image simplifiant l'idée de notre projet
lanification du projet
Tout au long du stage, notre travail a été réparti tel qu'il est décrit dans le tableau ci
Visualisation Graphique des
3ÏEJHÏFUQS
Présentation générale
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
l'auteur, le
isation Android
ci-après:
17. Chapitre 1
Tableau 1.1: Planification du projet
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
(2 Tracks Unified Process).
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
», qui correspondent aux deux axes de
d’informations. La schématisation du processus de
comme le montre la figure 1.2.
Visualisation Graphique des
3ÏEJHÏFUQS
Présentation générale
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
processus unifié,
objets, centré sur
[4].
.
18. Chapitre 1 Présentation générale
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
20. Chapitre 2
Etat de l’art
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
21. Chapitre 2 Etat de l'art
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.).
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
22. Chapitre 2 Etat de l'art
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]
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
23. Chapitre 2
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
Etat de l'art
signé a la même valeur qu’un
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
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
toujours
Tunisiennes.
es documents signés électronique
on avoir recourt afin de relancer commerce électronique en
: applications existantes
es, nous avons remarqué qu’il n’existe pas encore sur le marché
ous Internet principalement) afin d'en observer les fonctionnalités
lectroniques
1BHF
gné le cas dans
comment
électroniquement ?
et évitent de payer
fonctionnalités.
24. Chapitre 2 Etat de l'art
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
Figure 2. 2: générateur de QR code
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
25. Chapitre 2 Etat de l'art
Figure 2.2.1 : application QR Droid
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 :
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
26. Chapitre 2 Etat de l'art
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
27. Chapitre 2
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 messag
algorithme de chiffrement symétrique à savoir
AES (Advanced Encryption Standard
Standard).
Visualisation Graphique des
3ÏEJHÏFUQS
message ; il existe plusieurs
: DES (Data Encryption Standard) et
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
Etat de l'art
lectroniques
1BHF
28. Chapitre 2 Etat de l'art
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
Figure 2. 4: Procédure de chiffrement symétrique
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. 5: Chiffrement asymétrique
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
29. Chapitre 2
C. La signature numérique
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.
chiffrement asymétrique qui utilise
une clé
permet d'authentifier l'émetteur et d’assurer l’intégrité d'un
la clé publique sert à vérifier cette
numérique de la signature manuscrite.
électronique correspond au chiffrement de l'empreinte d'un
signataire; cette empreinte est calculé par une fonction appelé
fonction particulière qui, à partir d'une donnée fournie en
servant à identifier rapidement, bien qu'incomplètement, la
utilisées en informatique et en
fonctions de hachage sont
La figure suivante représente
les différentes étapes de
génération et de vérification
Alice
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é
Bob
privée et obtient la signature.
Elle envoie l’ensemble
(message + signature) à Bob.
A la réception, Bob prend le
Figure 2. 6: Signature numérique
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
3ÏEJHÏFUQS
déchiffre à l’aide la clé
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
Etat de l'art
lectroniques
1BHF
a onique ; cryptographie ;
ns les
échiffre :
30. Chapitre 2 Etat de l'art
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 coeur 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)
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
31. Chapitre 2
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]
ier autorité de
fichier informatique) délivré par une
Emission et vérification de certificat
Elle se déroule comme décrite dans la
Figure 2. 8
Figure 2. 7: Standard du certificat X509 v3
figure 2.8 suivante :
8: Mécanisme de la certification électronique
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
Etat de l'art
lectroniques
1BHF
:
32. Chapitre 2 Etat de l'art
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
33. Chapitre 2
Figure 2.
9: Exemple d'architecture d'une PKI
reçoit une demande de certificat par l'intermédiaire de
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
ertificats 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
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
oit certificats numériques
Certification. [11]
à 2D (QR Code)
un Etat de l'art
lectroniques
1BHF
34. Chapitre 2 Etat de l'art
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é
Figure 2. 11: Un code barrFe icgluarsesi 2q.u 1e0 : QR code
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
35. Chapitre 2 Etat de l'art
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
Figure 2. 13: exemple d'encodage du QR code
90 degrés dans le sens horaire et le code oriente 30 dans le sens anti horaire, le décodage
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
36. Chapitre 2 Etat de l'art
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
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
37. Chapitre 3
Spécification et
Analyse des
Besoins
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
38. Chapitre 3 Spécifications et Analyse des besoins
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
39. Chapitre 3 Spécifications et Analyse des besoins
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
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
40. Chapitre 3 Spécifications et Analyse des besoins
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
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).
Visualisation Graphique des Preuves Electroniques
(Voir figure 3.1)
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
41. Chapitre 3
Figure 3.
Description du cas d’u
1: Diagramme de cas d'utilisation global
d’utilisation global:
Dans le cas d’utilisation global l’
seront énumérées ci – après.
l’acteur interagit avec le système en effectuant des tâches qui
Acteur concerné : Utilisateur
Android.
Objectif : générer un document signé et le vé
Scénario nominal :
vérifier.
Pour générer un document signé l’utilisateur doit
signer électroniquement le document,
générer un QR-QR
code,
imprimer le document sur lequel le QR
Pour vérifier le document l’utilisateur doit
scanner le QR-vérifier
-code,
la signature du document,
QR-code est inséré. (optionnel)
:
générer le document électronique source.
Visualisation Graphique des
3ÏEJHÏFUQS
Spécifications et Analyse des besoins
:
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
vérifier lectroniques
1BHF
acteur
42. Chapitre 3
3.4.2 Raffinement des cas d’utilisation
A. Raffinement du c
Signer document
cas d’utilisation « Signer document »
Figure 3.
2: Cas d’utilisation « Signer document »
Description L’utilisateur peut effectuer la signature d’un document
Acteur Un u
utilisateur
Objectif Signer un document
Pré – condition l'utilisateur doit avoir un certificat de signature électronique
Visualisation Graphique des
3ÏEJHÏFUQS
Spécifications et Analyse des besoins
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
43. Chapitre 3
Scénario nominal
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)
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
Tableau 3. 2
2: Raffinement du cas d'utilisation « Signer document
original ne peut pas être effectué.
Post – condition Le système génère le fichier signé
B. Raffinement du cas d’utilisation «
Vérifier
Visualisation Graphique des
3ÏEJHÏFUQS
Spécifications et Analyse des besoins
Vérifier Signature »
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
la
: »
44. Chapitre 3 Spécifications et Analyse des besoins
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.
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
45. Chapitre 3
Figure 3. 4: Diagramme d’activité de
: signature d’un document
3.5.2 Diagramme d’activité
: générer le document original
Description : le scan du QR
document original après avoir effectué les vérifications nécessaires.
QR-code et l’extraction de la signature puis la génération du
Visualisation Graphique des
3ÏEJHÏFUQS
Spécifications et Analyse des besoins
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
46. Chapitre 3
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
cifier 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.
et la modélisation du comportement de certains
d’activités. . La spécification des besoins étant établie, nous
uivant Visualisation Graphique des
3ÏEJHÏFUQS
Spécifications et Analyse des besoins
et non fonctionnels à prendre en
travail, de spécifier les cas d'utilisation de
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
48. Chapitre 4_______________________________________________________ Conception
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
nalyse 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
diagrammes d’activités.
4.1 Conception Détail
4.1.1
, et les
Détaillée
Le diagramme de paquetages
package en anglais) illustré à la figure 4.3 permet de représenter
Le diagramme de paquetage (p
graphiquement les relations existantes
Figure 4.
1: Diagramme de paquetage de l'application
4.1.2
Table descriptives des
entre les paquetages composants notre système
Diagramme de classes technique
différentes classes :
Visualisation Graphique des
Introduction
Classe
3ÏEJHÏFUQS
l’analyse des besoins. Dans ce chapitre
Description
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
système.
49. Chapitre 4_______________________________________________________ Conception
Package 1 : Signature_CMS
Signer Cette classe permet de signer un fichier avec un certificat
Cette classe permet de charger le fichier signé et de vérifier la
signature
Verifier
Package 2 : Verification_certificat
CRLVerifier Extrait le CRL et vérifie l’état de révocation de certificats
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
TimeValidityVerif Cette classe permet de verifier la validité du certificat
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
Connection_Ldap Cette classe permet la connexion au serveur LDAP
Hashage_sha1 Permet de crypter le certificat par la méthode de hashage sha2
A) Diagramme de classe technique du package signature_CMS :
Tableau 4. 1: Description des classes relatives à la Signature électronique
Visualisation Graphique des Preuves Electroniques
Voir [figure 4.2]
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
50. Chapitre 4_______________________________________________________ Conception
Figure 4.
2: D.C.T du package signature_CMS
B) Diagramme de classe technique du
Figure 4.
« package vérification_certificat
3: D.C.T du package vérification_certificat
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
» :
51. Chapitre 4_______________________________________________________ Conception
C) Diagramme de classe technique du
Figure 4.
« package certification » :
4: D.C.T du package certification
D) Diagramme de classe technique du package activity
Visualisation Graphique des
3ÏEJHÏFUQS
:
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
52. Chapitre 4_______________________________________________________ Conception
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
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
53. Chapitre 4_______________________________________________________ Conception
Figure 4. 6: Diagramme de classe technique du package
: « engine
Description des Classes du package «
Classe
FileFromQrDecoder
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
Visualisation Graphique des
FileToQrEncoder
3ÏEJHÏFUQS
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
»
d’encodage (qui
retourner le Bitmap
en Bitmap
54. Chapitre 4_______________________________________________________ Conception
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
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
55. Chapitre 4_______________________________________________________ Conception
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
Méthode Information
getKeyStore()
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
CheckTimeValidity() Vérifier la validité du certific
Visualisation Graphique des
Classe
Signer
Connection-certif
CRLVerifier
TimeValidityVerif
3ÏEJHÏFUQS
Charger le fichier
Envelopper la signature
avec le document
original
certificat
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
signé
certificat
56. Chapitre 4_______________________________________________________ Conception
GetKeyUsage
CertChaineValidator
VerifyKeyUsage() Vérifier l’utilisation de la clé
isSelfSigned() Vérifier l’autorité de
Hashage-sha1 () Générer le hash de la signature
4.2.1
Figure 4.
certification
Diagramme de séquence technique du cas
d’utilisation « Vérifier document »
8: D.S.T de vérification de document
Acteur : Un utilisateur
Description : l’utilisateur peut générer le document original depuis un QR
système effectue les vérifications
Visualisation Graphique des
Hashage-sha1
3ÏEJHÏFUQS
QR-système
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
-code après que le
57. Chapitre 4_______________________________________________________ Conception
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()
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
Visualisation Graphique des Preuves Electroniques
Verifier
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
58. Chapitre 4_______________________________________________________ Conception
Figure 4. 9: D.S.T Lecture du QR code
4.2.3
depuis la capture de la caméra et génération du fichier original
Diagramme de séquence technique du cas
d’utilisation « créer un QR Code »
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.
Visualisation Graphique des
3ÏEJHÏFUQS
QR-code.
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
59. Chapitre 4_______________________________________________________ Conception
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
startEncodingForCurrentPhase() Transformer en QR-code
saveEncodedImage() Enregistrer sous format png
sur la carte sd.
Visualisation Graphique des Preuves Electroniques
EncodeActivity
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
60. Chapitre 4_______________________________________________________ Conception
Figure 4.
10: D.S.T de génération d’un QR-code
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’
l’objet du chapitre suivant.
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
lectroniques
1BHF
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
62. Chapitre 5
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
description de quelques interfaces du système
ASUS K53E
1: Environnement matériel
Système d’exploitation : Windows XP professionnel
Technologie Android : Système d'exploitation open
source pour Smartphones, PDA et
terminaux mobiles (Voir annexe C pour plus de détails
x détails)
IDE : NetBeans 7.4 ; Eclipse
E
Modélisation UML: Power AMC Designer de Sybase 15.1
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
Implémentation
lectroniques
1BHF
tion
63. Chapitre 5
5.2 Méthode de conception
Pour la mise en oeuvre de notre application, nous avons choisi modèle d’architecture logiciel
MVC (Modèle – Vue – Contrôleur).
ontrô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
Figure 5.
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
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
es dérivé de la classe Java Activity
manière invisible et effectuent un traitement sans surveillance.
:
son Smartphone qui contient déjà
2: Architecture MVC Android
Réalisation
lectroniques
1BHF
ivé ère
64. Chapitre 5
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
5.3 Les bibliothèques s utilisées
5.3.1 Zxing (Zebra Crossing
Crossing)
ZXing est un projet open-source multi
mis en oeuvre 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 :
multi-format de code-barres 1D/2D de traitement d'images
les codes-barres sur l'appareil, sans communiquer avec un
o UPC-A and UPC
UPC-E
o EAN-8 and EAN
EAN-13
o Code 39
o Code 128
o QR Code
o Data Matrix (alpha quality)
Visualisation Graphique des
3ÏEJHÏFUQS
Preuves Electroniques
ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#--
Réalisation
lectroniques
1BHF
65. Chapitre 5 Réalisation
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. 4: Interface d'accueil
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
Figure 5. 5: Interface d'encodage avec la
liste des fichiers encodés
66. Chapitre 5 Réalisation
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
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF
67. Chapitre 5 Réalisation
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
Visualisation Graphique des Preuves Electroniques
3ÏEJHÏFUQSÏTFOUÏQBS0MHB.#/*#-- 1BHF