air - User contributions [en]

Projets 2021-2022

2022-03-18T10:51:27Z

Corentin.Humbert:

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

Votre fiche d'auto-évaluation doit être déposée sur [https://im2ag-moodle.univ-grenoble-alpes.fr/course/view.php?id=99 Moodle]

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [[Test Infrastructures NixOS 2021-2022|Fiche de suivi]]
| [[Rapport Test Infrastructures NixOS 2021-2022|Rapport final]] - [[Media:Presentation_finale_NixOs.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [[Media:Pitch_NixOS-Compose.pdf|Pitch]]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [[Projet INFO5 2022 - Plan d'un appartement connecté | Fiche de suivi ]]
| [[Media:Rapport_de_projet_Plan_de_lappartement_connecte_DOMUS.pdf|Rapport final]] - [[Media:Presentation_finale_FR_DOMUS.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster_DOMUS_FR.pdf|Poster FR]] - [[Media:Poster_DOMUS_EN.pdf|Poster EN]] - [[Media:Pitch_Plan_dynamique_appartement_connecte.pdf|Pitch]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/plateforme-domus/appartementdynamique Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [[PROJET-INFO5 2022 AgriLoRa|Fiche de suivi]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/-/snippets/237 Rapport final] [[Media:INFO5_AgriConnect_presentation_finale.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:INFO5_AgriConnect_poster_fr.pdf|Poster FR]] - [[Media:INFO5_AgriConnect_poster_en.pdf|Poster EN]] - [[Media:INFO5_AgriConnect_pitch.pdf|Pitch]] - [https://drive.google.com/file/d/15bZaHscxOSBFGXu1xTfehl1Fqa0u_POn/view?usp=sharing Screencast]
| [https://gitlab.com/agrilora Dépot Git]
| [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [https://github.com/pfefitsize/DOCS/tree/main/Rapport Rapport final] - [[Media:presentation_fitsize.pdf|Presentation finale FR]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:poster_fitsize.pdf|Poster EN]] - [[Media:pitch_fitsize.pdf|Pitch]] - [[Media:rapport_technique.pdf|Rapport technique]]
| [https://github.com/pfefitsize Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:Genderednews_rapport_.pdf|Rapport final]] - [[Media:Soutenance_finale_genderednews_.pdf|Présentation finale FR]] - [[Media:GenderedNews_final_presentation_.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:Rapport_Final_systeme_analyse_trace_sportive.pdf|Rapport final]] - [[Media:Presentation_Final_systeme_analyse_trace_sportive.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [[Qualité de l'Air et Santé des Populations | Fiche de suivi]]
| [https://github.com/Air-Quality-LoRa/docs/blob/main/README.md Rapport final] - [[Media:presentation_finale_qualite_air.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-Air-Quality-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard, Estelle Gillet Perret
| [[Media: JournalDeBord_2022.pdf|Fiche de suivi]]
| [[Media:Rapport_final.pdf|Rapport final]] - [[Media:Présentation_finale_-_Artiphonie.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:Poster_Artiphonie_FR.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:Quark_defense.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:POSTER QUARK.pdf|Poster FR]] - [[Media:POSTER QUARK.pdf|Poster EN]] - [[Media:ProjetQuark Pitch.pdf|Pitch]]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [[Media:Fiche_Suivi_Jorigine_Grp10.pdf|Fiche de Suivi]]
| [[Media:Rapport_Jorigine_Grp10.pdf|Rapport Final]] - [[Media:Presentation_finale_jorigine_2022.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:JorigineFlyer.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [[Media:Pitch_Jorigine_grp10.pdf|Pitch en 180 secondes]] - [https://drive.google.com/file/d/1fUGc38NtNAAjlsfBPqPdwKDNI5l7g1vs/view?usp=sharing Screencast]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [https://c.tenor.com/x8v1oNUOmg4AAAAd/rickroll-roll.gif Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [https://air.imag.fr/images/2/23/Soutenance_finale_-_EDCampus.pdf Presentation finale FR] - [https://air.imag.fr/images/5/5a/Soutenance_finale_EN_-_EDCampus.pdf Final Presentation EN] - [https://c.tenor.com/x8v1oNUOmg4AAAAd/rickroll-roll.gif Flyer] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [[PROJET-INFO5 2022 LabNbook|Fiche de suivi]]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook/blob/main/rapportLabNbook.md Rapport final] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:LabNbook_flyer.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://drive.google.com/file/d/102KIVqH-wFF7UYggyVtJiUww-lcN7oXY/view?usp=sharing Pitch 180 secondes] - [https://drive.google.com/file/d/1eWU090ieX3dC8vweB4UKzwfu9E7jk1vI/view?usp=sharing Screencast]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [https://github.com/GreenCollects/docs/blob/main/project_managment/Fiche%20de%20suivis.pdf Fiche]
| [https://github.com/GreenCollects/docs/blob/main/report/CR-Final-Report.md Rapport final] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20final.pdf Presentation finale FR] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [https://github.com/GreenCollects/docs/blob/main/report/PosterEN.pdf Poster EN] - [https://github.com/GreenCollects/docs/blob/main/report/CR-MPI-seance2.md Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:Pitch NixOS-Compose.pdf

2022-03-18T10:50:32Z

Corentin.Humbert:

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:41:37Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

[[File:Elk_stack.png|thumb|600px|right|Intéraction des composants au sein de la stack ELK ou BELK]]

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:38:41Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

[[File:Elk_stack.png|300px|right|Intéraction des composants au sein de la stack ELK ou BELK]]

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:38:07Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

[[File:Elk_stack.png|thumb|300px|right|Intéraction des composants au sein de la stack ELK ou BELK]]

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:37:35Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

[[File:Elk_stack.png|right|Intéraction des composants au sein de la stack ELK ou BELK]]

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:37:03Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

[[File:Elk_stack.png|thumb|right|'''Figure 1 :''' Intéraction des composants au sein de la stack ELK ou BELK]]

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

File:Elk stack.png

2022-03-18T09:35:36Z

Corentin.Humbert:

Rapport Test Infrastructures NixOS 2021-2022

2022-03-18T09:32:57Z

Corentin.Humbert:

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : '''NixOS''' et le projet de recherche '''NixOS-Compose'''. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : '''Kubernetes''', '''ELK''' et '''Hadoop''' en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le ''Filesystem Hierarchy Standard''. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son '''store''', où il stocke toutes les '''dérivations''' pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres ''dérivations'') et les instructions de build. Le nom de la ''dérivation'' indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : '''une même dérivation produira toujours la même sortie.'''

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des ''dérivations''
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

'''Nixpkgs''' est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de ''dérivations'' fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version '''atomique'''. Par ailleurs, le système d'exploitation hérite ainsi de la propriété '''déterministe''' et '''reproductible''' que Nix offre.

'''NixOS-test''' est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec '''QEMU'''.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme '''Grid'5000''' et des solutions de conteneurs comme '''Docker'''.

==Kubernetes==

Kubernetes est un '''orchestrateur de conteneurs''' permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du '''DevOps''' dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une '''plateforme de déploiement''' fortement disponible aux développeurs. Kubernetes dispose également d'un '''large écosystème''' d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures '''microservices''' par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une '''configuration complexe''' liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, ''Terraform'' est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, '''simplement''', '''rapidemment''' et de manière '''reproductible''', est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. '''Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.'''

==ELK==

"ELK" est l'acronyme de trois projets open source : '''Elasticsearch''', '''Logstash''' et '''Kibana'''.

===Elasticsearch===

Elasticsearch est un '''outil de recherche et d'analyse de données''' fonctionnant de manière '''distribuée''' et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et '''spécialisée dans la recherche et l'indexation de documents'''. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de '''centraliser des traces''' provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un '''"pipe"''' où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la '''visualisation de données''' écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé '''Beats'''. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits '''outils permettant d'expédier des données''' vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le '''control plane''' est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l''''apiserver''', qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le '''controller manager''', regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des ''Pod'', pareil pour les ''ReplicasSet'', ''Endpoint'', ''Node''...). Le '''scheduler''' est responsable de l'attribution des resources (machines) aux applications (''Pod'', ''Deployment''...) selon les disponibilités et besoins. Enfin, '''etcd''' est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un '''Node''' (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un ''Node'' doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le '''kubelet''' est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le '''kube-proxy''' est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des ''Service'' et ''Endpoint''. Enfin, '''l'environnement d'exécution de conteneurs''' peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un '''plugin de CNI''' (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les ''Pod'' disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un '''serveur DNS''' (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme ''Helm'' et ''Istio'' pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (''PersistentVolume'') accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Projets 2021-2022

2022-02-18T08:36:30Z

Corentin.Humbert:

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[TODO]]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le ??/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR, NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]- [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:PSP Presentation.pdf

2022-02-07T11:47:25Z

Corentin.Humbert:

Projets 2021-2022

2022-02-07T11:46:55Z

Corentin.Humbert:

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/s/B029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [[TODO]]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAM
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [[TODO]]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [[TODO]]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [[TODO]]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[TODO]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[TODO]]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[TODO]]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[TODO]]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMIN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[TODO]]
| CAPET THEO,POITEVIN EVE,ROYET JULIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
|
|
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date (à définir): ??/02 Après midi. Distantiel (sur Zoom).

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche. La présence du porteur n'est pas obligatoire. Prévoyez du temps pour les questions-réponses (5 minutes max).

L'équipe présentera en 5-6 transparents en 8 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Respectez bien les créneaux indiqués (par respect pour les autres équipes).

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le ??/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR, NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN, ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://github.com/malleng/Projet_S10 Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:VT2021 Merkle Trees presentation.pdf

2021-12-13T16:23:30Z

Corentin.Humbert: Corentin.Humbert uploaded a new version of File:VT2021 Merkle Trees presentation.pdf

== Summary ==
Merke Trees presentation by Corentin Humbert and Kevin Yung

VT2021 Merkle Trees fiche

2021-12-13T13:29:25Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'arbre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits, mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire ? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant-dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable, car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quel que soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on dupliquait les nœuds impairs et les fusionnait avec eux-mêmes est notable puisqu'ici, on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau, mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Exécutons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commençant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précèdent vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds, mais quatre : Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seconde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour les construire. Toutefois, nous n'avons pas encore vu comment les utiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données, mais nous n'avons pas encore détaillé comment. C'est ce dont nous allons parler dans cette partie.

Prenons un exemple très simple : on veut télécharger un fichier en utilisant un réseau pair à pair. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré, mais à une multitude de machines dans un réseau qui vont participer au téléchargement. On dispose du hachage unique permettant d'identifier le fichier, ce hachage nous a été envoyé par une machine connue à laquelle on fait confiance. Le hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage, et les machines du réseau vont s'occuper de nous envoyer les blocs de données. À ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de le vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine de l'arbre reconstruit est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non-légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque nœud dépend des nœuds qui le précèdent, le moindre changement va se propager et changer completement le hachage racine.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hachage des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisée récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocs contiennent un ID, qui correspond à l'en-tête fields haché (cf. image), et au sein de cet en-tête haché, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380 Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non-critiques de l'espace de stockage. Les nœuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque nœud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles comme les transactions utilisées, ne laissant que les branches contenant les hachages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données clé-valeur NoSQL, entièrement managée et serverless qui est conçue pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque nœuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc surveiller la moindre différence et de repérer l'endroit divergent.

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficiles à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préférera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

File:VT2021 Merkle Trees presentation.pdf

2021-12-13T13:26:27Z

Corentin.Humbert: Merke Trees presentation by Corentin Humbert and Kevin Yung

== Summary ==
Merke Trees presentation by Corentin Humbert and Kevin Yung

VT2021 Merkle Trees fiche

2021-12-13T10:42:32Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'arbre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits, mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire ? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant-dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable, car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quel que soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on dupliquait les nœuds impairs et les fusionnait avec eux-mêmes est notable puisqu'ici, on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau, mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Exécutons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commençant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précèdent vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds, mais quatre : Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seconde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour les construire. Toutefois, nous n'avons pas encore vu comment les utiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données, mais nous n'avons pas encore détaillé comment. C'est ce dont nous allons parler dans cette partie.

Prenons un exemple très simple : on veut télécharger un fichier en utilisant un réseau pair à pair. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré, mais à une multitude de machines dans un réseau qui vont participer au téléchargement. On dispose du hachage unique permettant d'identifier le fichier, ce hachage nous a été envoyé par une machine connue à laquelle on fait confiance. Le hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage, et les machines du réseau vont s'occuper de nous envoyer les blocs de données. À ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de le vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine de l'arbre reconstruit est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non-légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque nœud dépend des nœuds qui le précèdent, le moindre changement va se propager et changer completement le hachage racine.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hachage des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisée récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocs contiennent un ID, qui correspond à l'en-tête fields haché (cf. image), et au sein de cet en-tête haché, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380 Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non-critiques de l'espace de stockage. Les nœuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque nœud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles comme les transactions utilisées, ne laissant que les branches contenant les hachages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données clé-valeur NoSQL, entièrement managée et serverless qui est conçue pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque nœuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc surveiller la moindre différence et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficiles à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préférera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T10:28:27Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'arbre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits, mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire ? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant-dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable, car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quel que soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on dupliquait les nœuds impairs et les fusionnait avec eux-mêmes est notable puisqu'ici, on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau, mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Exécutons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commençant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précèdent vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds, mais quatre : Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seconde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour les construire. Toutefois, nous n'avons pas encore vu comment les utiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données, mais nous n'avons pas encore détaillé comment. C'est ce dont nous allons parler dans cette partie.

Prenons un exemple très simple : on veut télécharger un fichier en utilisant un réseau pair à pair. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré, mais à une multitude de machines dans un réseau qui vont participer au téléchargement. On dispose du hachage unique permettant d'identifier le fichier, ce hachage nous a été envoyé par une machine connue à laquelle on fait confiance. Le hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage, et les machines du réseau vont s'occuper de nous envoyer les blocs de données. À ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de le vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine de l'arbre reconstruit est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non-légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque nœud dépend des nœuds qui le précèdent, le moindre changement va se propager et changer completement le hachage racine.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T10:27:21Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'arbre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits, mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire ? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant-dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable, car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quel que soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on dupliquait les nœuds impairs et les fusionnait avec eux-mêmes est notable puisqu'ici, on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau, mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Exécutons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commençant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précèdent vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds, mais quatre : Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seconde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour les construire. Toutefois, nous n'avons pas encore vu comment les utiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données, mais nous n'avons pas encore détaillé comment. C'est ce dont nous allons parler dans cette partie.

Prenons un exemple très simple : on veut télécharger un fichier en utilisant un réseau pair à pair. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré, mais à une multitude de machines dans un réseau qui vont participer au téléchargement. On dispose du hachage unique permettant d'identifier le fichier, ce hachage nous a été envoyé par une machine connue à laquelle on fait confiance. Le hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage, et les machines du réseau vont s'occuper de nous envoyer les blocs de données. À ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de le vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine de l'arbre reconstruit est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non-légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque nœud dépend des nœuds qui le précèdent, le moindre changement va se propager et changer completement le hachage racine.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T10:20:48Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'arbre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits, mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire ? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant-dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable, car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quel que soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on dupliquait les nœuds impairs et les fusionnait avec eux-mêmes est notable puisqu'ici, on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau, mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Exécutons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commençant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précèdent vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds, mais quatre : Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seconde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les arbres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un arbre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T10:08:19Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Diagramme représentant la structure générique d'un arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'arbre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les arbres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'arbre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un arbre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'arbre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les arbres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un arbre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T10:02:24Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. The leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un mécanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque même si nous ne pouvons pas vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au-dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au-dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concret. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des cryptomonnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Cryptomonnaie ===

La cryptomonnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de cryptomonnaie sont stockées dans des blocks, aussi appelés blockchain.
La cryptomonnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet des cryptomonnaies, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:53:58Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. the leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

Imaginons que nous voulions télécharger un fichier dans un réseau pair-à-pair, comme on ne peut pas pas vérifier l'identité des machines sur le réseau, il est fort probable que certaines d'entre elles tentent d'envoyer des fichiers malveillants. Il faudrait donc mettre en place un méchanisme permettant d'identifier ces fichiers non désirés. Les arbres de Merkle sont une solution à ce problème. Un arbre de Merkle est un arbre binaire qui va permettre d'identifier de manière unique et sûre une ressource sur un réseau.

Une fois qu'une donnée aura été mise en ligne sur un réseau pair-à-pair, on va la découper en plusieurs blocs et calculer les hachages pour chacun des blocs. Ces hachages de premier niveau vont constituer les feuilles de l'arbre de Merkle. Les feuilles vont ensuite être fusionnées deux à deux pour former un parent commun avec un hachage différent, et ce même parent va fusionner avec son voisin de la même manière et réitérer le processus jusqu'à obtenir la racine de l'arbre contenant le hachage unique qui va permettre d'identifier la donnée dans son intégrité.

La racine de l'arbre servant d'identifiant pour la donnée va être une manière fiable et rapide de rechercher la donnée sur le réseau. La racine va également servir à vérifier que la donnée téléchargée correspondant bien à la donnée désirée. Cela solutionne le problème initial puisque malgré que nous ne puissions vérifier l'identité des machines, nous sommes en mesure de déterminer si la donnée est reçue correspond bien à celle voulue.

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

L'image ci-contre ('''figure 1''') contient l'arbre de Merkle d'une donnée découpée en quatre blocs (Data Nodes). Juste au dessus des blocs, on retrouve les feuilles de l'arbre (Merkle leaves) contenant les hachages des blocs. Encore au dessus, on va retrouver les nœuds intermédiaires (Merkle branches) qui correspondent à la fusion des deux hachages du niveau précédent. Enfin, tout en haut, on retrouve la racine de l'arbre (Merkle root) qui contient le hachage final servant à identifier la donnée.

Dans la suite de ce document, nous allons présenter plus en détails les arbres de Merkle et expliquer leur fonctionnement ainsi que leurs domaines d'applications. Nous commencerons par introduire les fonctions de hachage et par décrire leur fonctionnement général ainsi que leurs avantages et désavantages. Ensuite, nous expliquerons le processus de construction d'un arbre de Merkle et tous les différents scénarios qui peuvent altérer la façon dont l'arbre va être construit. Nous enchaînerons ensuite sur la partie validation avec un exemple concrèt. Enfin, nous parlerons de différentes implémentations des arbres de Merkle dans des infrastructures réelles telles que la sécurité des transactions des crypto-monnaies.

Commençons sans plus attendre par faire un point sur le hachage !

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:32:55Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau [https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair pair-à-pair]. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are [https://en.wikipedia.org/wiki/Binary_tree binary trees] used in data validation. A tree consists of nodes and leaves. the leaves contain the cryptographic hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des [https://fr.wikipedia.org/wiki/Arbre_binaire arbres binaires] utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:28:07Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau pair à pair. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé :''' arbres de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are binary trees used in data validation. A tree consists of nodes and leaves. the leaves contain the hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in peer to peer networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords:''' Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:26:15Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau pair à pair. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé''': arbre de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are binary trees used in data validation. A tree consists of nodes and leaves. the leaves contain the hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is unique and specific data will always give the same tree. A common use for Merkle trees is the download of files in peer to peer networks. As it is impossible to verify the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:24:53Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants. Chaque arbre est unique et une donnée donnera toujours le même arbre. On retrouvera typiquement les arbres de Merkle lorsqu'on voudra faire du téléchargement de fichiers sur un réseau pair à pair. Comme on ne peut pas vérifier l'identité des machines participant à l'envoi de fichier, il est indispensable de mettre en place une structure de vérification comme les arbres de Merkle pour s'assurer que les données reçues correspondent bien à celles désirées.

'''Mots-clé''': arbre de Merkle, arbres binaires, hachage, structure de données, validation, pair à pair

== Abstract ==

Merkle trees are binary trees used in data validation. A tree consists of nodes and leaves. the leaves contain the hash corresponding to a part of the data we want to validate. The nodes contain a hash obtained by concatenating the hashes of the two child nodes and passing the concatenated string through a hashing function. This overall process creates a dependance between the nodes where each node's hash depends on the hash values of the underlying nodes. Each Merkle tree is a unique and any data will always give the same tree. A common use for Merkle trees is the download of files in peer to peer networks. As it is impossible to verifiy the identity of machines in the network, it is necessary to use validation structures such as Merkle trees to ensure that the received data is the desired one.

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle trees, binary trees, hash, data structure, validation, peer to peer

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:10:07Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Fonction de hachage"''', Wikipedia, https://fr.wikipedia.org/wiki/Fonction_de_hachage
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-13T09:08:35Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

[[File:Merkle_Tree_Validation.png|500px|thumb|right|'''Figure 5 :''' Validation de l'arbre de Merkle identifié par '''"b74b3"'''. L'arbre reçu (à droite) contient Data5 à la place de Data4, cette erreur est immédiatement détectée lors de la comparaison du hachage racine avec celui du fichier désiré]]

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-monnaie ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

File:Merkle Tree Validation.png

2021-12-13T09:00:33Z

Corentin.Humbert: Diagram of the validation of a Merkle Tree

== Summary ==
Diagram of the validation of a Merkle Tree

VT2021 Merkle Trees fiche

2021-12-13T08:33:31Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-currency ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-12T21:37:03Z

Corentin.Humbert:

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-currency ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Conclusion ===

Les arbres de Merkle sont très pratiques pour effectuer de la validation de données dans un système pair à pair. Ils ne sont pas difficile à stocker puisque les seules données qu'ils contiennent (en dehors des blocs de données) vont être des hachages dont la taille varie autour de la centaine d'octets en fonction des algorithmes de hachage utilisés. Leur simplicité permet également une validation rapide des données puisqu'il suffit de faire des opérations de concaténation (très faible coût) et de calcul de hachage (coût faible en moyenne, peut varier suivant la fonction de hachage utilisée). La structure en arbre permet également d'apporter une certaine granularité et l'ajout de fonctionnement annexe par rapport à une simple concaténation des hachages de chaque bloc de données.
Enfin, la robustesse d'un arbre va entièrement dépendre des fonctions de hachages utilisées. Par exemple, si l'on voulait valider des données sensibles comme des transactions sur la blockchain, on préferera utiliser des fonctions sécurisées comme celles de la famille SHA plutôt qu'un simple md5.

== Références ==

* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-12T19:31:59Z

Corentin.Humbert:

<pre style="color: red">⚠️ Cette page est en cours de construction et de ce fait beaucoup d'informations sont encore manquantes... ⚠️</pre>

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

== Cas d'utilisations ==

=== Git ===

Git est un logiciel de gestion de versions décentralisé qui est beaucoup utilisé aujourd'hui. Tous les fichiers sont enregistrés sur l'ordinateur de tous les utilisateurs, à tout moment. Les Merkle trees permettent d'assurer que tout changement soit cohérent sur les ordinateurs de tous les utilisateurs. En comparant simplement le hashages des fichiers ou dossiers entre 2 différents commits, on peut facilement et surtout rapidement savoir si celui-ci a été modifié ou non.

=== Crypto-currency ===

La crypto monnaie a été très popularisé récemment, et continuer de s'étendre, notamment le bitcoin.
Toutes les transactions de crypto monnaie sont stockées dans des blocks, aussi appelés blockchain.
La crypto monnaie utilise les Merkle Trees pour s'assurer la validation des transactions dans les blocks. En effet, les blocks contiennent un ID, qui est le header fields hashé (cf. image), et parmi ce header hashé, une partie contient la racine de du Merkle Tree. De ce fait, elle permet de s'assurer de l'unicité de l'enregistrement des transactions dans le block.

=== Blockchain pruning ===

Pour continuer sur le sujet de crypto, l'émondation ou l'élagage des blockchains est un sujet qui reste d'affût de nos jours. En effet, sachant que les blockchains grandissent de plus en plus actuellement, cela veut également dire que celles-ci prennent de plus en plus de place en terme de stockage. Par exemple, en Février 2021, la taille de la blockchain du Bitcoin est d'environ 380Go. De ce fait, l'élagage de la blockchain consiste à épurer l'arbre, en supprimant les informations de la blockchain non critiques de l'espace de stockage. Les noeuds pleins gardent une copie de tous ce qui est stockés dans la blockchain, notamment des informations qui ne sont plus forcément utiles. Sachant que l'objectif d'un Merkle Tree est de synthétiser et de relier de grandes quantités d'informations. Chaque noeud contient l'information de ses fils, et donc la proposition est d'élaguer les informations qui ne sont plus utiles commes les transactions utilisées, ne laissant que les branches contenant les hashages pour vérifier les autres transactions.

=== Base de données (AWS Dynamo DB) ===

Dynamo DB est une base de données distribuée provenant en partie de la plateforme Amazon Web Services. C'est une base de données key-value NoSQL, entièrement managée et serverless qui est designé pour exécuter des applications hautes performances à n'importe quelle échelle. Dynamo DB héberge les données (values) dans des data nodes qui sont aussi appelés "virtual nodes" et chaque virtual nodes héberge une key-range (gamme de clés). Un Merkle tree est construit pour chaque key-range, où les feuilles de l'arbre sont les valeurs de la key-range data. La Merkle Root contient donc un résumé des données de chaque noeuds. De ce fait, en comparant les Merkle Roots de chaque virtual nodes qui possèdent les mêmes key-range, on peut donc monitorer la moindre différences et de repérer l'endroit divergent.
=== File System (ZFS) ===

=== Limites et faiblesses ===

==== Pourquoi utiliser des arbres de Merkle ? ====
Nous savons maintenant comment créer un arbre, et comment l'utiliser pour valider des données. Une question que l'on pourrait se poser est "Pourquoi utiliser des arbres de Merkle, ne pourrait-on pas simplement concaténer les hachages des blocs de données ?". En effet, on pourrait tout à fait se contenter de concaténer les hachages des différents blocs, le moindre changement sur un bloc changerait le hachage final. Alors pourquoi s'embeter avec des arbres ?

==== Attaque de préimage ====

== Références ==

* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-12T19:07:50Z

Corentin.Humbert:

<pre style="color: red">⚠️ Cette page est en cours de construction et de ce fait beaucoup d'informations sont encore manquantes... ⚠️</pre>

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle déséquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

=== Limites et faiblesses ===

==== Pourquoi utiliser des arbres de Merkle ? ====
Nous savons maintenant comment créer un arbre, et comment l'utiliser pour valider des données. Une question que l'on pourrait se poser est "Pourquoi utiliser des arbres de Merkle, ne pourrait-on pas simplement concaténer les hachages des blocs de données ?". En effet, on pourrait tout à fait se contenter de concaténer les hachages des différents blocs, le moindre changement sur un bloc changerait le hachage final. Alors pourquoi s'embeter avec des arbres ?

==== Attaque de préimage ====

== Cas d'utilisations ==

=== Blockchain ===

=== Amazon AWS DynamoDB ===

=== Système de fichier ZFS ===

=== Git ===

== Références ==

* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-12T10:26:46Z

Corentin.Humbert:

<pre style="color: red">⚠️ Cette page est en cours de construction et de ce fait beaucoup d'informations sont encore manquantes... ⚠️</pre>

Présenté par :
* Corentin Humbert : [mailto:corentin.humbert@etu.univ-grenoble-alpes.fr corentin.humbert@etu.univ-grenoble-alpes.fr]
* Kévin Yung : [mailto:kevin.yung@etu.univ-grenoble-alpes.fr kevin.yung@etu.univ-grenoble-alpes.fr]

= Merkle Trees =

== Résumé ==

'''Mots-clé''': Merkle, arbres, hachage, structure de données, validation

== Abstract ==

Merkle Trees are binary trees in which every node is labelled with a cryptographic hash.

'''Keywords''': Merkle, Trees, hash, data structure, validation

== Fonctionnement ==

=== Principe ===

[[File:Merkle_Tree.png|thumb|right|'''Figure 1 :''' Exemple d'arbre de Merkle]]

Les arbres de Merkle sont des arbres binaires utilisés pour effectuer de la validation de données. Pour ce faire, chaque feuille de l'arbre va contenir le hachage correspondant à une partie de la donnée à valider. Chaque nœud de l'arbre va également contenir un hachage. Ce hachage est obtenu en concaténant le hachage des deux enfants et en passant le résultat dans une fonction pour créer un tout nouveau hachage. Il se construit alors une dépendance générale où la valeur de chaque nœud dépend des valeurs de ses nœuds enfants.

L'image ci-dessous contient un arbre de Merkle servant à valider une donnée découpée en quatre blocs (Data Nodes). Les feuilles de l'abre (Merkle leaves) vont contenir le hachage correspondant pour chaque bloc. Les nœuds intermédiaires (Merkle branches) vont contenir le hachage issu de la concaténation des hachages de leurs deux enfants. Enfin, la racine de l'arbre (Merkle root) va contenir le hachage final servant à identifier l'arbre de Merkle.

=== Un point sur le hachage ===

Avant de s'immiscer dans le fonctionnement des arbres, il est important de parler du '''hachage''' et plus particulièrement des fonctions de hachage.

[[File:Hashing_Principle.png|400px|thumb|right|'''Figure 2 :''' Exemples de hachages obtenus en utilisant MD5 (source: Wikipedia)]]

En cryptographie, une fonction de hachage est une fonction qui, à partir d'une donnée fournie en entrée, va être capable de calculer une empreinte numérique permettant d'identifier la donnée initiale de manière unique. La taille en sortie de cette empreinte est fixe et ne dépend pas de la taille de la donnée en entrée. Par [https://fr.wikipedia.org/wiki/Idempotence idempotence], chaque donnée donnera toujours la même empreinte. En pratique, les fonctions de hachages sont bijectives, dans le sens où chaque donnée a une seule empreinte et chaque empreinte ne correspond qu'à une seule donnée. En théorie, la possibilité de surjectivité existe. Cela est due au fait que l'ensemble d'arrivée correspondant aux empreintes est de taille fini contrairement à l'ensemble des données en entrées qui lui peut être infini. On pourrait donc trouver deux données différentes partageant une même empreinte. Cependant, l'ensemble d'arrivée est en général suffisamment grand pour que ce phénomène ne se produise jamais. On parle souvent de la capacité qu'a une fonction de hachage à [https://fr.wikipedia.org/wiki/R%C3%A9sistance_aux_collisions résister aux collisions] (deux données différentes partageant une même empreinte). Cette capacité à résister aux collisions varie en fonction des algorithmes. Certains algorithmes réduisent d'ailleurs l'ensemble d'entrée en un ensemble fini pour s'assurer que le phénomène de collision ne se produise jamais. La présence de collisions constitue cependant une faille de sécurité importante pour les fonctions de hachages et un problème qu'on ne peut pas ignorer.

'''Difficilement réversible'''

Ce qui fait la puissance et la fiabilité d'une fonction de hachage, c'est la difficulté de retrouver la donnée initiale à partir de son empreinte. Il est très simple, pour une donnée en entrée, de calculer le hachage correspondant. Alors que l'opération inverse, qui correspond à retrouver la donnée initiale à partir de l'empreinte est mathématiquement extrêmement compliquée, et impossible à mettre en place sur les ordinateurs de nos jours. Une utilisation notable du hachage va être le stockage de mots de passe. Lors d'une inscription sur un site web, on ne va jamais stocker le mot de passe en clair dans une base de données. À la place, on va calculer le hachage correspondant au mot de passe et le stocker dans la base. À chaque fois que l'on voudra s'authentifier sur le site en rentrant le mot de passe, le hachage sera calculé et comparé à celui présent dans la base de données. Si les deux sont égaux, alors il s'agit du bon mot de passe. On peut donc vérifier qu'un mot de passe est valide sans l'avoir stocké dans la base au préalable, ce qui sécurise davantage les comptes utilisateurs.

'''Résistance aux collisions'''

Les fonctions de hachage ont tout de même quelques faiblesses notables. La première, réside dans la complexité de l'algorithme de hachage et de sa résistance aux collisions. C'est le cas de la fonction [https://fr.wikipedia.org/wiki/MD5 MD5] inventée en 1991 par [https://fr.wikipedia.org/wiki/Ronald_Rivest Ronald Rivest], qui a pu être utilisée de manière fiable jusqu'en 2004 où une équipe chinoise a réussi à casser la fonction et prouver qu'elle ne garantissait une assez bonne résistance aux collisions. Le MD5 est aujourd'hui encore utilisé dans certains cas de figure. (notamment pour vérifier l'intégrité d'une donnée, c'est le cas pour les sommes de contrôle de certaines distributions Linux par exemple.) Toutefois, il est à bannir pour le hachage de mots de passe qui sont des données extrêmement sensibles. Il existe aujourd'hui des fonctions de hachage sécurisées telles que les fonctions dites [https://fr.wikipedia.org/wiki/Secure_Hash_Algorithm SHA] (pour Secure Hashing Algorithm) et plus précisément les familles de fonctions [https://fr.wikipedia.org/wiki/SHA-2 SHA-2] et [https://fr.wikipedia.org/wiki/SHA-3 SHA-3] qui n'ont pas encore été cassées.

'''Limites du hachage'''

Une autre faiblesse des fonctions de hachage est l'idempotence. Puisque chaque donnée a une empreinte unique, un attaquant pourrait calculer en amont les hachages pour des centaines de millions de données différentes et se contenter de les comparer à des hachages volés dans des bases de données de manière à identifier la donnée source. Dans le cadre du vol de mot de passe, on parle de [https://fr.wikipedia.org/wiki/Rainbow_table rainbow table] qui sont simplement des gigantesques tables faisant correspondre un mot de passe à son hachage. Il existe différentes méthodes que l'on peut mettre en place pour limiter le vol de mots de passe tel que le principe de [https://fr.wikipedia.org/wiki/Salage_(cryptographie) salage] ou encore l'utilisation d'algorithmes lents, comme [https://fr.wikipedia.org/wiki/Bcrypt bcrypt] visant à ralentir l'opération de hachage.

Enfin, il est important de garder à l'esprit que toutes les méthodes mises en place ne résolvent pas le problème, elles visent simplement à ralentir considérablement les attaquants. Un attaquant disposant de suffisamment de temps et de puissance de calcul finira par retrouver n'importe quel mot de passe. Il y a également les récentes innovations au niveau des ordinateurs quantiques qui sont vouées à compromettre significativement les dispositifs de sécurité mis en place sur Internet aujourd'hui. Nous ne nous étendrons pas plus sur le sujet du hachage dans ce document, si vous désirez en apprendre davantage, je vous invite à cliquer sur les différents liens hypertextes présents dans cette partie.

=== Création d'un arbre ===

Pour réaliser un arbre de Merkle pour une donnée particulière, on va commencer par découper la donnée en entrée en un certain nombres de blocs. Le nombre de blocs va varier en fonction de la taille de la donnée. Une fois la donnée scindée en blocs, on va calculer pour chaque bloc son hachage et l'ajouter à l'arbre de Merkle. Deux blocs consécutifs vont être reliés par un nouveau nœud parent dont le hachage sera calculé en effectuant la concaténation des deux hachages enfant et en hachant une dernière fois ce résultat. On va réitérer cette opération pour chaque bloc, jusqu'à ce que tous les blocs de données hachés appartiennent à l'abre et qu'une racine soit calculée. Une fois la racine obtenue, la construction de l'abre est terminée.

Pour ce qui est de l'algorithme de hachage utilisé, celui-ci va varier en fonction des implémentations. Généralement, on utilisera des fonctions de hachage robustes tel que le SHA2 ou SHA3.

=== Arbre de Merkle désiquilibré ===

Nous avons parlé précédemment de comment les abres de Merkel étaient construits mais nous avons oublié d'évoquer un point. L'algorithme décrit marche très bien lorsque le nombre de blocs en entrée est une puissance de 2. Par exemple, avec quatre blocs, on aura quatre feuilles (nœud de hauteur 2), deux nœuds de hauteur 1 et un nœud de hauteur 0 (la racine). Mais que se passe-t-il si au lieu d'avoir quatre blocs, nous en avions six ? Nous aurions alors six feuilles, trois nœuds de hauteur 1 et...
Comment faire? Chaque nœud ne peut avoir que deux enfants et nous nous trouvons avec un nombre impair de nœud, devons-nous changer la structure de l'abre et autoriser des nœuds à avoir trois enfants ?

Ils existent différentes approches permettant de pallier ce problème.

==== Duplication du nœud impair (Bitcoin) ====

[[File:Merkle_Tree_Duplicating_Node.png|thumb|right|'''Figure 3 :''' Équilibrage d'un abre de Merkle en utilisant la technique de duplication (source: Medium)]]

Pour cette première approche, on va dupliquer les nœuds qui se retrouvent tout seul. Sur la '''figure 3''', on peut observer que l'arbre de Merkle contient cinq feuilles. Cinq étant un chiffre impair, notre arbre de Merkle se retrouve déséquilibré. On va donc choisir de dupliquer la feuille se retrouvant toute seule pour ré-équilibrer l'arbre. Ici, il va s'agir de la feuille contenant le hachage du cinquième bloc de donnée : Hash5. La feuille va donc être copiée de manière à faire apparaître une sixième feuille contenant également Hash5. Il n'y a plus de problème au niveau des feuilles de l'arbre puisqu'il y en a désormais une quantité paire. Cependant, nous allons rencontrer un problème au niveau supérieur. En effet, nos six feuilles vont se transformer en trois nœuds et on retombe encore une fois sur une quantité impaire. On va donc ré-itérer le procédé et dupliquer cette fois le troisième nœud contenant Hash55 (On remarque que ce hachage est obtenu en appliquant la fonction de hachage sur la concaténation de deux hachages identiques.). Cela nous permet de faire un quatrième nœud, le nombre de nœuds du niveau étant paire, on peut passer au niveau suivant. Pour l'avant dernier niveau, on va avoir deux fois moins de nœuds que le niveau précédent, ce qui nous ramène à deux nœuds. Comme la quantité de nœuds est paire, pas besoin de dupliquer de nœud. L'algorithme de duplication prend fin ici puisque le prochain niveau va simplement contenir la racine.

Notre arbre de Merkle est donc désormais équilibré et exploitable. On pourrait cependant se poser des questions sur la fiabilité de cette solution de duplication. En effet, celle-ci est assez simple à mettre en place, mais il introduit une faille de sécurité notable car certains nœuds ne contiendront en réalité qu'un seul hachage. (copié deux fois)

==== Création d'un arbre parfait (Monero) ====

[[File:Merkle_Tree_Perfect_Tree.png|thumb|right|'''Figure 4 :''' Équilibrage d'un abre de Merkle en utilisant la technique de création d'arbre parfait (source: Medium)]]

Cette seconde méthode va consister à transformer n'importe quel arbre déséquilibré en un arbre parfait dès la première itération. En d'autres termes, quelque soit le nombre de blocs de données en entrée, on aura un arbre équilibré dès le premier niveau de branches (juste au dessus des feuilles). La différence avec la précédente approche où l'on duplicait les nœuds impairs et les fusionnait avec eux-même est notable puisqu'ici on ne va pas avoir à vérifier la parité du nombre de nœuds à chaque niveau mais seulement au tout début. L'idée va donc être de pré-calculer le nombre de transformations nécessaires sur les feuilles pour que l'on obtienne une quantité de nœuds au niveau suivant les feuilles qui soit une puissance de deux.

L'algorithme utilisé est le suivant :
* On commence par trouver ''x'', tel que ''2^x'' soit supérieur au nombre de blocs de données. (cela revient à utiliser un logarithme en base 2)
* On soustrait ensuite à ''2^x'' le nombre de blocs de données, cela va nous donner l'indice auquel nous allons commencer la première itération de construction de l'arbre
* On procède en effectuant la première itération à partir du bloc de donnée correspondant à l'indice trouvé.
* Une fois la première itération terminée, le nombre de nœuds à l'itération suivante est une puissance de deux, on peut procéder normalement sans avoir à se soucier de potentiels problème de parité.

Pour nous aider à visualiser le fonctionnement de cette approche, nous allons travailler avec l'exemple de la '''figure 4'''. Au premier coup d'œil on remarque que l'abre a une structure un peu bizarre; on a deux niveaux de feuilles. Executons l'algorithme sans attendre pour comprendre ce qu'il se passe :
* On dispose de cinq blocs de données (Data1 jusqu'à Data5). Si on cherche ''x'' tel que ''2^x > 5'', on trouve ''2^3 = 8 > 4'', soit ''x = 3''.
* On soustrait désormais le nombre de blocs à la puissance trouvée, soit ''8 - 5 = 3'', ce qui nous donne l'indice de départ pour la première itération. On commencant à compter les indices à partir de zéro, l'indice 3 va correspondre à Data4. Tous les blocs qui suivent Data4, lui y compris vont participer à la première itération. Tandis que tous ceux qui le précède vont attendre l'itération d'après.
* On lance la première itération qui ne concerne ici que Data4 et Data5. On va donc naturellement calculer leur hachage respectif, ce qui nous donne Hash4 et Hash5, que l'on va concaténer et hacher de manière à obtenir Hash45, qui lui, appartient à la seconde itération. La première itération est désormais terminée puisque Data5 était le dernier nœud.
* On commence la seconde itération, avec cette fois non pas cinq nœuds mais quatre: Hash1, Hash2, Hash3 et le hachage Hash45 obtenu lors de l'itération précédente. Comme le nombre de nœuds est une puissance de deux, rien de plus simple, on va concaténer Hash1 et Hash2 pour obtenir Hash12, et Hash3 et Hash45 pour obtenir Hash345. La seoncde itération se termine. La dernière itération va concaténer Hash12 et Hash345, ce qui va nous permettre d'obtenir Hash12345.

=== Validation de données ===

Dans les parties précédentes, nous avons vu ce qu'étaient les arbres de Merkle, et comment procéder pour en construire un. Toutefois, nous n'avons pas encore vu comment les uiliser. Nous avons parlé brièvement du fait qu'ils servaient à faire de la validation de données mais nous n'avons pas encore détaillé exactement comment. C'est ce dont nous allons parler dans cette partie.

Imaginons que nous voulions télécharger un fichier assez conséquent depuis Internet. On veut utiliser un système pair à pair pour télécharger le fichier. On ne va donc pas se connecter à un serveur unique qui détient le fichier désiré mais à une multitude de machines dans un réseau qui vont participer au téléchargement. Le pair à pair a de nombreux avantages mais nous ne rentrerons pas en détail sur son fonctionnement dans ce document. L'un des problèmes majeurs des architectures pair à pair est la confiance que l'on accorde à chaque machine. En effet, contrairement à une architecture client-serveur classique où le serveur est une machine identifiée et à laquelle on fait généralement confiance, la modularité des systèmes pair à pair fait que nous soyions obligé de nous reposer sur des machines anonymes et potentiellement malicieuses. Il est impossible de vérifier si chaque machine est légitime ou si l'une d'entre elles tente de nous envoyer un fichier corrompu. C'est justement pour pallier ce problème que nous pouvons utiliser les abres de Merkle.

Reprenons notre problèmatique de téléchargement de fichier. Ici, le fichier que l'on veut obtenir va être transformé en un abre de Merkle. En d'autres termes, il va être divisé en un certain nombre de blocs que l'on va hacher un à un jusqu'à obtenir un hachage unique qui permet d'identifier l'intégralité du fichier (il s'agit de la racine de l'arbre). Nous avons donc un arbre plus ou moins massifs qui va représenter le fichier que nous voulons télécharger. Mais comment-va-t'on faire pour vérifier que le fichier que nous avons demandé est bien celui que nous avons reçu ?
Tout repose sur le hachage racine. Si on part du principe que nous avons obtenu le hachage racine d'un tier auquel nous faisons confiance, nous allons pouvoir, par ce seul hachage, s'assurer que le fichier que nous obtenons soit bel et bien celui que nous voulions.

Prenons un exemple très simple: On veut télécharger un fichier F en utilisant un réseau pair à pair. On dispose du hachage unique permettant d'identifier le fichier grâce à un tier à qui nous faisons confiance. Ce hachage, un peu à la manière d'un URL va permettre d'identifier le fichier au sein du réseau. On va donc indiquer le fichier que l'on désire télécharger en fournissant son hachage et les pairs vont s'occuper de nous envoyer les blocs de données. A ce niveau-là, nous ne pouvons rien dire sur la légitimité des machines qui nous envoient les blocs de données, il est possible que certaines d'entres elles soient malicieuses mais impossible pour nous de vérifier. Toutefois, lorsque nous aurons reçu tous les blocs de données, nous allons pouvoir les valider en reconstruisant l'arbre de Merkle et en vérifiant que le hachage racine obtenu est identique à celui que nous avions à l'origine. S'il s'agit du même hachage, alors le fichier est bien conforme. Si l'une des machines du réseau pair à pair a tenté de nous envoyer des données non légitimes, on va pouvoir très facilement le détecter. En effet, comme chaque noeud dépend des noeuds qui le précède, le moindre changement va se propager et changer completement le hachage racine.

L'efficacité des arbres de Merkle a détecter le moindre changement de bit dans un fichier repose sur la nature des fonctions de hachage qu'il utilise. En effet, une particularité des fonctions de hachage est qu'elles sont très chaotiques et que le changement du moindre bit va complètement changer le hachage résultant.

=== Limites et faiblesses ===

==== Pourquoi utiliser des arbres de Merkle ? ====
Nous savons maintenant comment créer un arbre, et comment l'utiliser pour valider des données. Une question que l'on pourrait se poser est "Pourquoi utiliser des arbres de Merkle, ne pourrait-on pas simplement concaténer les hachages des blocs de données ?". En effet, on pourrait tout à fait se contenter de concaténer les hachages des différents blocs, le moindre changement sur un bloc changerait le hachage final. Alors pourquoi s'embeter avec des arbres ?

==== Attaque de préimage ====

== Cas d'utilisations ==

=== Blockchain ===

=== Amazon AWS DynamoDB ===

=== Système de fichier ZFS ===

=== Git ===

== Références ==

* '''"Merkle tree"''', Wikipedia, https://en.wikipedia.org/wiki/Merkle_tree
* '''"Merkle Trees: Concepts and Use Cases"''', Medium, https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
* '''"How Merkle Trees Enable the Decentralized Web!"''', Youtube (Coding Tech channel), https://www.youtube.com/watch?v=YIc6MNfv5iQ

VT2021 Merkle Trees fiche

2021-12-12T09:18:00Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-12T09:00:20Z

Corentin.Humbert:

File:Merkle Tree Perfect Tree.png

2021-12-12T08:53:00Z

Corentin.Humbert: source: https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318

== Summary ==
source: https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318

VT2021 Merkle Trees fiche

2021-12-07T12:40:08Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-07T12:34:19Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-05T16:11:54Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-05T16:09:24Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T16:25:06Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T16:23:57Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T16:22:34Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T16:20:15Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T16:10:30Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T15:51:16Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T15:48:29Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T15:46:01Z

Corentin.Humbert:

VT2021 Merkle Trees fiche

2021-12-03T15:44:29Z

Corentin.Humbert: