RICM5 2017 2018 - UGAChain / SRS

<< Retour Fiche

Introduction

Ce document de spécification des exigences logicielles (document SRS) a été créé dans le cadre d'un projet de dernière année d'école d'ingénieur visant à mettre en place un système empêchant la falsification des diplômes universitaires. Ce dernier sera basé sur le concept de blockchain. Ce document passe par la description du projet et les différentes exigences nécessaires pour le réaliser.

Le public cible de cette description est le client ou les analystes des besoins et des tâches, les testeurs, les rédacteurs de documentation pour l'utilisateur et les chefs de projet.

Nom du projet : UGAchain

Clients / Superviseurs :

• Didier Donsez
• Lucas ??
• Gérard ??
• Marie Ziener
• Mathieu PIERRE

Établissement : Polytech Grenoble

Équipe :

• Antoine BOISADAM - Chef de projet
• Simon CHAMBONNET - Scrum-master
• Aymeric VIAL-GRELIER - Développeur
• Charles MARCHAND - Développeur
• Ahmed NASSIK - Développeur
• Lucas GUERRY - Développeur

Sujet

Le but de ce document est de donner une description détaillée des besoins du projet “UGAchain”, un projet ayant pour but de détecter et à terme éviter les falsifications de diplômes de la part de personnes candidates à des emplois. Ce système serait communautaire entre plusieurs entités se faisant confiance les unes avec les autres, et mettant en communs leurs ressources afin de pouvoir authentifier différents diplômes.

Horizon

UGAchain est un service qui se présente sous la forme d’un réseau de confiance appelé blockchain dans lequel les différentes entitées membres échangent de l’information et mettent leurs ressources en commun. Chaque ressource mise à disposition possède son propre historique afin qu’elle soit traçable est fiable au cours du temps.

Dans le cas d’UGAChain les universités membres de la chaîne auront la possibilité de stocker une empreinte numérique du diplômes.

Figure 1 : Schéma global de génération d’un diplôme certifié

Un diplômé pourra à n’importe quel moment récupérer ses propres couples diplômes numériques & clés d’authentifications. -> Nous pensons que c’est un autre problème, différent du notre.

Lorsque le diplômé souhaitera partager un diplôme avec une tierce personne, il pourra donner une version numérique (PDF) de son diplôme, ainsi que l’identifiant de la transaction sur la blockchain. Une personne souhaitant vérifier l’authenticité d’un diplôme provenant de l’une des universités membres de la chaîne n’aura plus qu’à utiliser notre portail web dans lequel il fournira la version du diplôme fournie par l’ex-étudiant ainsi que le numéro de transaction, envoyé par l’élève. L’application se chargera alors d’examiner la version du diplôme fournie, et en fonction de l’identifiant de transaction. L’interface web affichera clairement l’authenticité de la version numérique du diplôme fourni.

Figure 2 : Schéma lors de la vérification d’un diplôme par un employeur

Description Globale

Architecture globale

Figure 4 : Architecture générale

Ce système est composé de 2 parties distinctes. La première partie concerne les universités, il s’agit d’une application web permettant aux universités d’uploader et d’héberger les diplômes de leurs étudiants.

***TBD*** Hébergement en mode cloud vs hébergement “local” dans toutes les universités ***\TBD***

Architecture blockchain

Rappel: La blockchain est une technologie basée sur une architecture pair à pair (P2P) garantissant ces trois principes :

• sécurité
• immutabilité
• programmabilité

La blockchain est donc un ledger (sorte de “gros livre” ou registre) regroupant des groupes de transactions (blocks) liés de manière cryptographique dans le temps. Ces transactions sont enregistrées sous forme d’entrées et contienne un “asset” (contenu) qui peut être n'importe quel type d’objet (virtuel ou physique).

Nous définissons dans cette section le contenu d’une entrée (transaction) de la blockchain ainsi que plus précisément son asset, c’est à dire, l’information qu’elle transporte.

L’information enregistrée dans la blockchain sera dans notre cas un “digest” (comprendre une série de chiffres et lettres générée par une fonction cryptographique (fonction de hachage) et relative à un fichier d’entrée) du diplôme.

Le système UGAChain aura donc des entrées comme ceci :

Figure 5 : Exemple d’une entrée dans un bloc de notre blockchain

Spécifications des besoins

Besoins externes

Cette section a pour but de détailler les spécifications externes de l’application, que ce soit matériel ou logiciel ainsi que les méthodes d’interaction basées sur des maquettes.

Interfaces utilisateur.

Dans le cadre de ce projet nous pouvons distinguer deux interfaces utilisateur distinctes. Ces 2 types d’utilisateurs sont :

1. les universités - qui vont créer un diplôme, dont l’empreinte va être enregistré dans la blockchain, ainsi qu’envoyer la version numérique (PDF) et l’identifiant de la transaction.
2. les entreprises ou tierces personnes, cherchant à vérifier l’authenticité d’un document qui leur a été transmis.

Les universités doivent impérativement être authentifiées et identifiées afin de pouvoir utiliser le système (sinon la chaîne de confiance serait brisée). Par conséquent l’accent sera porté sur la sécurisation de la totalité de la chaîne.

Le seul potentiel besoin d’authentification de l’étudiant serait quand l’étudiant veux récupérer les diplômes numérisés ainsi que les id de transaction de ses diplômes. Encore une fois, c’est probablement un autre problème.

TODO: Creer des bout d’interface (IHM)

Exigences fonctionnelles

Simplicité d’utilisation

Le système étant utilisé par un public diversifié, il est nécessaire que la prise en main de l’application soit rapide. Le publique destiné n’ayant pas de connaissance dans la blockchain il faut réduire la distance sémantique. Il est néanmoins envisageable de former le personnel de l’université habilité à certifier les diplômes qui aura pour objectif d’ajouter le “digest” du diplôme numérisé dans la blockchain.

Confidentialité des données de l’étudiant

Concernant la protection des données du bénéficiaire (diplômé), il est interdit à une université de dévoiler les diplômes (ou l’absence de diplôme) d’un étudiant sans son autorisation. En ne stockant que le “digest” du diplôme, il est impossible d’obtenir toute information du diplôme. De plus, la certification du diplôme n’est possible que si la personne vérifiant (employeur) dispose du diplôme numérique et du numéro de transaction.

Disponibilité du service de vérification

L’importance de la disponibilité du service est relativement importante. Le système étant critique et impactant à terme l'éventuelle embauche d’un nombre important d'étudiant il faut pouvoir assurer un service continu et être résistant au attaques (DOS...)

L’architecture (Microservices) tolérera une montée en charge grâce a la duplication des serveurs (Gateway, Microservice...).

Sécurité de la blockchain

Le choix d’une architecture fermée s’explique par l’importance de la validité des données de la blockchain. Il est donc important que ces données ne soient pas falsifiées.

L’attaque du 51% est une façon évidente de falsifier les donnée dans une blockchain ouverte. En utilisant une blockchain fermée on ne valide que les transactions provenant des serveurs d’universités.

Il est aussi pertinent de réaliser une vérification entre plusieurs membre de l’administration avant l’ajout du “digest” sur la blockchain.

Efficacité d’utilisation

Afin de simplifier le travail aux universités et employeurs, il est nécessaire d’automatiser, dans la mesure du possible, les tâches à accomplir.

Il faudrait notamment pouvoir ajouter une liste entière de diplômes dans la blockchain en quelques étapes.

Problématiques

Comme notre application est sensible, nous sommes conscient que l’on doit être résistant aux attaques, notamment dans le cas une personne mal intentionnée irai sur le poste de travail laissé ouvert par inadvertance pourrait inscrire des diplômes (SHA 256 associée) dans la chaîne. Et donc par le principe même de la technologie block chain, informations immuables, notre système serait corrompu, et c’est diplômes inscrit de manière frauduleuse ne pourrai pas être reconnu invalide.

Notre solution consiste à imiter le processus actuel, le “diplôme” devrait être validé par toutes les personnes qui doivent le signer en version papier. Et ainsi on le publierai sur la blockchain, lorsque toutes ces personnes l’auront validé.

Cette méthode diminue le risque d’attaque et de maladresse, et de plus on est plus cohérent dans la manière de certification, qui se rapproche plus de lois en vigueur pour les diplômes.