* 1. [Documents de référence](#Documentsderfrence) * 2. [Spécifique 4NK](#Spcifique4NK) * 3. [Bitcoin](#Bitcoin) * 4. [Chiffrement](#Chiffrement) * 5. [Data](#Data) * 6. [Exemples de Code](#ExemplesdeCode) * 7. [Todo](#Todo) # Définitions et abréviations ## 1. Documents de référence Voir [_Doc_references.md](_Doc_references.md). ## 2. Spécifique 4NK * **4NK**: Système décentralisé innovant basé sur les principes du web 5, centré sur la sécurité des données et l'identité numérique. * **Portable Contract Document (`RequestPcd`)**: Format `JSON` chiffré destiné à contenir des listes d'éléments d'un type, attachées à un process (`process_hash`) et soumis aux règles de valiation décrit dans le role correspondant à ce type d'item dans le process (`item_type`). * **Portable Request Document (`RequestPrd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requètes et validation) des `RequestPcd`. Les `RequestPrdResponse` sont collectés afin de vérifier que les conditions de l'`ItemProcess` sont bien respectées. D'autres types de `RequestPcd` permettent : * `RequestPrdList`: Demande de Listes d'`Item` en retour une `RequestPcd` sera reçu avec les `RequestPrdResponse` correspondant. * `RequestPrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou des transactions Silent Payments à broacaster sur le réseau de noeuds de la side chain. Les `RequestPrdMessage` peuvent se répondre entre eux. * `RequestPrdUpdate`: Demande de mise à Jour d'une liste d'`Item` (publiée va un `RequestPCD`) qui sera validé ou non par des `RequestPrdResponse` en retour. * `RequestPrdConfirm`: Confirmation de Réception des `RequestPrd`. * `RequestPrdResponse`: Réponse aux autres types de `RequestPrd` (hors `RequestPrdConfirm` et `RequestPrdResponse`). * **Message**: Enveloppe commune pour les `RequestPrd` et `RequestPcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `RequestPrd` et `RequestPcd` sont chiffrés par la `ProcessKey` de l'`ItemProcess` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`. * **KeyConfidential**: Clé AES-GCM-256 du `Diffie-Hellman` de la transaction Silent Payment correspondant à un `RequestPrd`.s à l'interprétation des RequestPcd. * **Peer**: Terme générique pour représenter un nœud du réseau, pouvant avoir diverses fonctions. * **Relay**: Un serveur web socket qui relaie en peer to peer les messages entre les autres pairs du réseau de relais et avec les clients connectés. * **Process**: Contrat off-chain définissant des conditions d'affichage, légales, de validation cryptographique et de rémunération des signatures. * **Utilisateur**: Client connecté pouvant être un navigateur, une application mobile, un logiciel, ou un IoT, utilisé par un humain ou une machine. * **Recover**: Action de recomposer une identité numérique (clés privées). * **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une`adresse SP` indiquée dans son `member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce membre. * **Onboard**: Action de demander un `rôle` dans un `ItemProcess` . * **Member**: Une adresse Silent Payment, complétée de métadonnées, par `ItemProcess` et d'une adresse supplémentaire pour la révocation. * **Third parties**:`adresse SP` complétant un `member` pour reconnaître d'autres dispositifs du `member`. * **ProcessKey**: la clé publique de chiffrement public d'un `ItemProcess` (dans un `ItemProcess`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément). * **KeyRecover**: la clé prive de spend de `recover` du signet, qui sert de référence pour l'identité. * **pre-id**: Pré identifiant des utilisateurs constitué du hash de partie 1 de la `KeyRecover`. * **Autres termes propres à 4nk**: voir Specs-Datas.md. ## 3. Bitcoin * **UTXO (Unspent Transaction Output)**: Sortie de transaction non dépensée dans la blockchain, représentant des tokens ou des actifs numériques qui peuvent être utilisés dans de futures transactions. * **HD Wallet (Hierarchical Deterministic Wallet)**: Un portefeuille cryptographique qui génère une structure d'arbres de clés à partir d'une graine unique, permettant une gestion sécurisée et organisée des multiples adresses et clés cryptographiques. * **Timechain**: Terme préféré à "blockchain", désignant un intervalle de temps régulier entre des blocs de transactions cryptographiques, sécurisées par cryptographie pour une distribution de la sécurité et de l'ordre des événements de façon identique sur l'ensemble du réseau. * **Silent Payment (SP)**: Méthode de paiement permettant d'envoyer et de recevoir des fonds sans réutiliser les adresses Bitcoin, améliorant ainsi la confidentialité des transactions. ## 4. Chiffrement * **MPC (Multi-Party Computation)**: Technique de calcul qui permet à plusieurs parties de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées secrètes. * **PBKDF2 (abréviation de Password-Based Key Derivation Function 2)**: applique une fonction pseudo-aléatoire, telle qu'un code d'authentification de message basé sur le hachage (HMAC), au mot de passe ou à la phrase secrète d'entrée ainsi qu'une valeur salt et répète le processus plusieurs fois pour produire une clé dérivée, qui peut ensuite être utilisée comme clé cryptographique dans les opérations ultérieures. Cela étend l'entropie du mot de passe utilisateur. Cette fonction appartient à la famille des normes Public Key Cryptographic Standards, plus précisément PKCS #5 v2.0. Cette norme a également été publiée dans la RFC 2898. Elle succède au PBKDF1, qui pouvait produire des clés n'allant que jusqu'à 160 bits. Cette norme est aujourd'hui utilisée pour le hachage de mot de passe (associé à des fonctions comme SHA-256) ou la génération de clé de chiffrement de données. * **SHA256 (Secure Hash Algorithm 256)**: Fonction de hachage cryptographique utilisée pour assurer l'intégrité des données et générer des empreintes uniques des documents. * **AES-GCM-256**: Implémente le codage et le décodage Rijndael en conformité avec la norme avancée de chiffrement (AES) du NIST. Il traite des blocs de 256 bits. Le mode Galois/Compteur (Galois/Counter Mode, GCM) est un mode d'opération pour les chiffrements par blocs à clé symétrique largement adopté pour sa performance. L'algorithme GCM fournit à la fois l'authenticité et la confidentialité des données et appartient à la classe des méthodes de chiffrement authentifié avec des données associées. * **Diffie-Hellman key exchange**: Méthode d'échange sécurisé de clés cryptographiques sur un canal public, l'un des premiers protocoles de cryptographie à clé publique. * **Shamir Secret Sharing**: Algorithme de cryptographie permettant de diviser un secret en plusieurs parties, nécessitant un certain nombre de ces parties pour le reconstituer. * **Transport Layer Security**: Protocoles de sécurisation des échanges par réseau informatique, notamment par Internet. ## 5. Data * **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les `ItemProcess` découverts et les pairs du réseau. Une fois identifié auprès des membres d'un `ItemProcess` et avec son identité `member` récupérée, l'objet member et les `RequestPcd` et `RequestPrd` du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée. * **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les `RequestPcd` et RequestPrd, dans les navigateurs web. ## 6. Exemples de Code ## 7. Todo