Fonctions de Hachage Cryptographique

Architecture de la blockchain

La technologie des blockchain peut sembler complexe, mais elle peut être simplifiée en examinant chaque composant individuellement. À un niveau élevé, la technologie de blockchain fait appel à des mécanismes informatiques bien connus et à des primitives cryptographiques (fonctions de hachage cryptographique, signatures numériques, cryptographie à clé asymétrique) combinées à des concepts de tenue de dossiers (comme les grands livres annexés seulement). Cette section discute de chaque composante principale individuelle: les fonctions de hachage cryptographique, les transactions, la cryptographie à clé asymétrique, les adresses, les grands livres, les blocs, et comment les blocs sont enchaînés ensemble.

Fonctions de Hachage Cryptographique 

Un élément important de la technologie blockchain est l’utilisation de fonctions de hachage cryptographique pour de nombreuses opérations. Le hachage est une méthode d’application d’une fonction de hachage cryptographique aux données, qui calcule une sortie relativement unique (appelé un message digest, ou simplement digest) pour une entrée de presque n’importe quelle taille (par exemple, un dossier, un texte, ou une image). Il permet aux utilisateurs de prendre indépendamment les données d’entrée, de les hacher et d’obtenir le même résultat, ce qui prouve qu’il n’y a pas eu de changement dans les données. Même la plus petite modification apportée à l’entrée (par exemple, la modification d’un seul bit) entraînera un condensé de sortie complètement différent .

Même si les fonctions de hachage ont de nombreuses applications dans la cryptographie moderne, elles sont peut-être mieux connues pour le rôle important qu’elles jouent dans l’utilisation pratique des signatures numériques.

Les fonctions de hachage cryptographique possèdent ces importantes propriétés de sécurité:
● elles sont résistantes à la pré-image. Cela signifie qu’ils sont à sens unique; il est impossible de calculer la valeur d’entrée correcte compte tenu d’une certaine valeur de sortie (par exemple, étant donné un résumé, trouver x tel que hash (x) = digest) ;
● elles sont résistantes à la deuxième pré-image, ce qui signifie que l’on ne peut pas trouver une entrée hachée sur une sortie spécifique. Plus spécifiquement, les fonctions de hachage cryptographiques sont conçues de sorte que, étant donné une entrée spécifique, il est impossible de trouver une deuxième entrée qui produise la même sortie (par exemple, étant donné x, trouver y tel que hash (x) = hash (y)). La seule approche disponible consiste à rechercher de manière exhaustive l’espace d’entrée, mais cela est impossible à faire sur le plan des calculs avec toute chance de succès ;
● elles sont résistantes aux collisions. Cela signifie que l’on ne peut pas trouver deux entrées hachées vers la même sortie. Plus précisément, il est impossible sur le plan informatique de trouver deux entrées qui produisent le même condensé (par exemple, trouver un x et un y avec hash (x) = hash (y)) ;

La fonction de hachage cryptographique spécifique utilisée dans de nombreuses implémentations de blockchain est L’algorithme de hachage sécurisé (SHA) avec une taille de sortie de 256 bits (SHA-256). De nombreux ordinateurs prennent en charge cet algorithme en matériel, ce qui le rend rapide à calculer. SHA-256 a une sortie de 32 octets (1 octet = 8 bits, 32 octets = 256 bits), généralement affichée comme une chaîne hexadécimale de 64 caractères .

Input text SHA-256 Digest Value

1 0x6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b
2 0xd4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35

Hello,World! 0xdffd6021bb2bd5b0af676290809ec3a53191dd81c7f70a4b28688a362182986f .

Puisqu’il existe un nombre infini de valeurs d’entrée possibles et un nombre fini de valeurs de résumé de sortie possibles, il est possible, mais très peu probable, d’avoir une collision où hash (x) = hash (y) (c’est-à-dire que le hachage de deux entrées différentes produit le même condensé). SHA-256 est censé être résistant aux collisions, car pour trouver une collision dans SHA-256, il faudrait exécuter l’algorithme, en moyenne, environ 2¹²⁸ fois (ce qui représente 340 milliards, ou plus précisément 340 282 366 920 938 463 463 374 607 431 738 211 456; environ 3 402 x10³⁸).

Pour mettre cela en perspective, le taux de hachage (hachages par seconde) de l’ensemble du réseau Bitcoin en 2015 était de 300 quadrillions de hachages par seconde (300 000 000 000 000 000 000 / s) . À ce rythme, il faudrait à l’ensemble du réseau Bitcoin environ 35 942 991 748 521 (environ 3,6 x10¹³) ans pour fabriquer une collision (notez que l’univers est estimé à 1,37 x 10¹⁰ ans) . Même si une telle entrée x et y produisant le même résumé, il serait également très peu probable que les deux entrées soient valides dans le contexte du réseau de blockchain (c’est-à-dire que x et y sont tous deux des transactions valides).

Au sein d’un réseau blockchain, les fonctions de hachage cryptographiques sont utilisées pour de nombreuses tâches, telles que:

❖ Dérivation d’adresse que nous allons voir dans la section 1.4 ;
❖ Créer des identifiants uniques ;
❖ Sécuriser les données de bloc – un nœud de publication hachera les données de bloc, créant un résumé qui seront stockés dans l’en-tête du bloc ;
❖ Sécuriser l’en-tête de bloc un nœud de publication hachera l’en-tête de bloc. Si le réseau de chaînes de blocs utilise un modèle de consensus de preuve de travail , le nœud de publication devra hacher l’en-tête de bloc avec différentes valeurs de nonce  jusqu’à ce que les conditions requises soient remplies. Le condensé de hachage de l’en-tête du bloc actuel sera inclus dans l’en-tête du prochain bloc, où il sécurisera les données de l’en-tête du bloc actuel ;

Étant donné que l’en-tête de bloc comprend une représentation hachée des données de bloc, les données de bloc sont également sécurisées lorsque le résumé de l’en-tête de bloc est stocké dans le bloc suivant. Il existe de nombreuses familles de fonctions de hachage cryptographiques utilisées dans la technologie de blockchain (SHA-256 n’est pas le seul), comme Keccak (sélectionné par le NIST comme le gagnant d’un concours visant à créer le standard de hachage SHA-3 ).

Cryptographie Nonce

Un nonce cryptographique est un nombre arbitraire utilisé une seule fois. Un nonce cryptographique peut être combiné avec des données pour produire différents digests de hachage par nonce:

Hash (data + nonce) = digest

Seule la modification de la valeur nonce fournit un mécanisme permettant d’obtenir différentes valeurs de résumé tout en conservant les mêmes données. Cette technique est utilisée dans le modèle de consensus de preuve de travail .

Table des matières

INTRODUCTION GÉNÉRALE
1ère partie : Cadre de référence et méthodologique
Chapitre 1 : Cadre méthodologique
1.1 Présentation des assurances Non-Vie
1.2 Définition du besoin
1.3 Importance de la question
1.4 Formulation des objectifs
Chapitre 2 : Background
2.1 Architecture de la blockchain
2.1.1 Fonctions de Hachage Cryptographique
2.1.2 Transaction
2.1.3 Cryptographie à clé asymétrique
2.1.4 Adresses et dérivation d’adresses
2.1.5 Grands livres
2.1.6 Blocs
2.1.7 Chaînage de blocs
2.2 Consensus
2.2.1 Modèle de consensus sur la preuve de travail
2.2.2 Modèle de consensus de preuve de participation
2.2.3 Modèle de consensus Round Robin
2.2.4 Modèle consensuel de preuve d’autorité / de preuve d’identité
2.2.5 Modèle de consensus sur la preuve du temps écoulé
2.2.6 Conflits et résolutions du grand livre
2.3 Forking
2.3.1 Soft Forks
2.3.2 Hard Forks
2.3.3 Changements cryptographiques et forks
2.4 Catégorisation de la Blockchain
2.4.1 Permission
2.4.2 Sans permission
2.5 Cryptocurrencies
2.5.1 Bitcoin (BTC)
2.5.2 Ethereum (ETH)
2.5.3 Ripple (XRP)
2.6 Limitations de Blockchain et idées fausses
2.6.1 Immutabilité
2.6.2 Utilisateurs impliqués dans la gouvernance de Blockchain
2.6.3 Blockchain Death
2.6.4 Au-delà du Digital
2.6.5 Cybersecurité
2.6.6 Cyberattaques et attaques réseau
2.6.7 Infrastructure à clé publique et identité
2ème partie : Analyse d’un smart contract
Chapitre 3 : Infrastructure des smart contracts
3.1 Smart contacts
3.2 Cycle de vie d’un smart contract
3.2.1 Création
3.2.2 Gel
3.2.4 Exécution
3.2.5 Finalisation
3.3 Modélisation UML d’un smart contract
Chapitre 4 : Etude des plateformes
4.1 Plateformes d’un smart contract
4.1.1 Ethereum
4.1.2 EOS
4.1.3 AION
4.1.4 NEM
4.1.5 Stellar
4.1.6 Hyperledger Fabric (HLF)
4.1.7 Corda :
4.1.8 NEO
4.2 Framework Ethereum
4.2.1 Langages des smart contracts
4.2.2 Outils de développement
4.2.3 Environnements de développement intégrés (IDE)
4.2.4 API front-end en JavaScript
4.2.5 API de back-end
4.2.6 Outils de sécurité
4.2.7 Outils de test
4.2.8 Explorateurs de block
4.2.9 Testnets et faucets
4.2.10 Clients (pour faire tourner le nœud)
4.2.11 Patterns et anti-pattern
Chapitre 5 : Modélisation des assurances non-vie
5.1 Etape d’une assurance non-vie
5.2 Analyse des situations en assurance où la blockchain peut être un outil indispensable
5.2.1 Plus rapide et moins cher
5.2.2 Souscription améliorée
5.2.3 Moins de douleur avec les réclamations
5.2.4 Lutter contre la fraude
5.2.5 Analyse de décision spécifique pour l’assurance non-vie
3ème partie : Implémentation de la solution
Chapitre 6 : Présentation des applications existantes
6.1 The Blockchain Insurance Industry Initiative (B3i)
6.2 Fizzy
Chapitre 7 : Présentation de la solution
7.1 Quels problèmes résolvons-nous?
7.2 Notre solution au problème
Chapitre 8 : Implémentation
8.1 Prérequis
8.1.1 Node Js
8.1.2 Ganache
8.1.3 Truffle Framework
8.1.4 Metamask Ethereum Wallet
8.1.5 Template
8.2 Configuration du projet
8.2.1 Configuration de Ganache
8.2.2 Configuration de Metamask
8.2.3 Configuration
8.3 Smart contract
CONCLUSION

Lire le rapport complet