Visualisation graphique des preuves Électroniques (complet)

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


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



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



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.



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



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



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



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



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



Introduction

Générale

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.

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.



Chapitre 1 Présentation

Générale

Chapitre 1


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



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é


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 2000, la promulgation de la loi n° 2000-83 du 09 aout

législation et de réglementation des échanges et du commerce


, 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


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é


governement). Il a été relevé la


du 09 aout 2000 a mis

de réglementation des échanges et du commerce


, 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



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


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




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.


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


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


lectroniques

Page 16

barres 2D contenant les informations clés du document, la date d’émission, l'auteur, le


isation d'une application Android


travail a été réparti tel qu'il est décrit dans le tableau ci-après:

Chapitre 1


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




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.


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

.




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 2 Etat de l’art

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.).




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


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



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


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 ?


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.




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.




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




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


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



Figure 2. 3 : Chiffrement et déchiffrement

B. Les mécanismes de chiffrement


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


: Avec ce mécanisme appelé aussi chiffrement à clé secrète,

; il existe plusieurs

Data Encryption Standard) et




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


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é



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é


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é


: Signature numérique




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


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



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




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


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



2D permet de passer d'un support physique (papier, écran…) au format électronique en une

fraction de seconde.



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


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


confidentialité de la clé privée de l'Autorité de Certification. [11]

Code à barres à 2D (QR Code)

Définition



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


ertificats numériques

même le couple de clés. Il pourrait donc signer et décrypter




un support physique (papier, écran…) au format électronique en une




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




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




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.



Chapitre 3 Spécification et

Analyse des Besoins

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.




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




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


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



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


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




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


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




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)


original (optionnel)

Si l’une des vérifications n’est pas établit alors la génération


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


Si l’une des vérifications n’est pas établit alors la génération


: Raffinement du cas d'utilisation « Signer document »




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


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.




: 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


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


Chapitre 3


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.




: 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.



Chapitre 4 Conception

Chapitre 4_______________________________________________________ Conception


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





se base essentiellement sur la bonne spécification et l’analyse des besoins. Dans ce chapitre


é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


lectroniques

Page 48


nalyse des besoins. Dans ce chapitre


, de séquences et les

permet de représenter

notre système.

technique




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



Rédigé et pr

Figure 4.

B) Diagramme de classe technique du

Figure 4.




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


lectroniques

Page 50

package vérification_certificat » :



Rédigé et pr

C) Diagramme de classe technique du

Figure 4.

D) Diagramme de classe technique du package activity




Diagramme de classe technique du « package certification » :

Figure 4. 4: D.C.T du package certification

Diagramme de classe technique du package activity :


lectroniques

Page 51




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



Rédigé et pr

Figure 4. 6: Diagramme de classe technique du package

Description des Classes du package «

Classe

FileFromQrDecoder

FileToQrEncoder




: 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


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




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



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




: 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


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



Rédigé et pr

GetKeyUsage

CertChaineValidator

Hashage-sha1

4.2.1

Figure 4.


Description : l’utilisateur peut générer le document original depuis un QR

système effectue les vérifications




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


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




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


d’utilisation « Scanner QR Code »

La figure 4.11 illustre ce diagramme.

Tableau 4. 5: Tableau de séquence technique 3


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



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


Scénario nominal

L’utilisateur envoie le document.

Analyse de la langueur du document.

Extraction des caractères.

Récupération du code ascii.




Lecture du QR code depuis la capture de la caméra et génération du fichier original


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.


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.




Conversion en nombre binaire.

Transformation en matrice de données (data matrix).

Affichage du QR-code.

Tableau 4. 6: tableau de classe technique 4


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.



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’




Figure 4. 10: D.S.T de génération d’un QR-code



de réalisation qui constitue l’objet du chapitre suivant.


lectroniques

Page 60





Chapitre 5 Implémentation

Chapitre 5


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




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


tion de quelques interfaces du système

Smartphones, PDA et

Chapitre 5


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.



de conception


ontrôleur).

fournisseurs de contenu.

es gestionnaires de données qui sont la forme recommandée de partage de données entre les


individuel d'une application Android est dérivé de la classe Java Activity



Windows. Ils s’exécutent de manière invisible et effectuent un traitement sans surveillance.

Diagramme de déploiement :


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


es gestionnaires de données qui sont la forme recommandée de partage de données entre les


ivé de la classe Java Activity



ère invisible et effectuent un traitement sans surveillance.


son Smartphone qui contient déjà

Chapitre 5


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)




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


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


barres 1D/2D de traitement d'images


barres sur l'appareil, sans communiquer avec un

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. 5: Interface d'encodage avec la liste des fichiers encodés

Figure 5. 4: Interface d'accueil




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




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




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.




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.




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.



Conclusion générale



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.



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.



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



Annexes



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



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]




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




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.



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



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



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.




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.




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



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



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.

Technology

Visualisation graphique des preuves Électroniques (complet)