From 9da174013bb168aee1feaaa41ce505e41f3b58a0 Mon Sep 17 00:00:00 2001 From: NicolasCantu Date: Tue, 9 Apr 2024 22:35:53 +0200 Subject: [PATCH] cleaning (doc) --- doc/Auth-Specs.md | 64 ++++---- doc/Envelope-Specs.md | 50 +++---- doc/Item-Specs.md | 40 ++--- doc/PRD-PCD-Specs.md | 62 ++++---- doc/Silent-Payments-Specs.md | 21 +-- doc/Specs-Code.md | 124 ++++++++-------- doc/Specs-Datamodel.md | 204 +++++++++++++------------- doc/Specs-Security-confidentiality.md | 72 ++++----- doc/_questions.txt | 21 --- 9 files changed, 310 insertions(+), 348 deletions(-) diff --git a/doc/Auth-Specs.md b/doc/Auth-Specs.md index ae3671c..d3266a7 100644 --- a/doc/Auth-Specs.md +++ b/doc/Auth-Specs.md @@ -1,10 +1,10 @@ # Auth - Specifications -## 1. Autheurs, validations, dates, versions, changement and historique +## 1. Autheurs, validations, dates, versions, changement and historique Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) -## 2. Table des matières +## 2. Table des matières * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) @@ -46,49 +46,49 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) /vscode-markdown-toc-config --> -## 3. Objectif +## 3. Objectif Développer un système de login sécurisé utilisant les clés cryptographiques de Bitcoin et sa timechain (via un réseau Signet personnalisé, appelé "side chain") ainsi qu'un système de relais d'une `Envelope` entre parties prenantes. Le concept de Silent Payments est employé pour authentifier les `User` sans réutilisation d'adresses, tout en utilisant une approche de `calcul multipartite (MPC)` pour une gestion sécurisée et distribuée des clés. Déployer une interface de login conforme aux wireframes : ![Wireframes](diagrams/Login-Wireframes.png "Wireframes") -## 4. Portée +## 4. Portée Ce système couvrira la conception et le développement de l'architecture d'authentification, incluant la génération, la gestion, et la validation des `users` à travers des formats de conformité spécifiques (Portable Contract Document et Portable Request Document). Il intégrera également l'authentification des `User`, la connexion via des tiers, la récupération d'`user`, et une gestion de session basée sur un cache avec des contraintes de sécurité renforcées. La solution sera conçue pour des environnements hautement sécurisés, nécessitant une haute disponibilité, performance, et évolutivité. -## 5. Documents de référence +## 5. Documents de référence Wireframes : Voir [_Doc_references.md](_Doc_references.md). -## 6. Schématisation des processus +## 6. Schématisation des processus -### 6.1. Création d'un `User` +### 6.1. Création d'un `User` ![WalletCreate](diagrams/WalletCreate.png "WalletCreate") -### 6.2. Onboarding +### 6.2. Onboarding ![WalletOnboard](diagrams/WalletOnboard.png "WalletOnboard") -### 6.3. Connexion avec un `User` créée (`recover`) +### 6.3. Connexion avec un `User` créée (`recover`) ![WalletRecover](diagrams/WalletRecover.png "WalletRecover") -### 6.4. Extension de l'entropie du mot de passe (PBKDF2) +### 6.4. Extension de l'entropie du mot de passe (PBKDF2) ![PBKDF2](diagrams/PBKDF2.png "PBKDF2") -### 6.5. Chiffrement AES quantique résistant (AES-GCM-256) +### 6.5. Chiffrement AES quantique résistant (AES-GCM-256) ![AES-GCM-256](diagrams/AES-GCM-256.png "AES-GCM-256") -### 6.6. Génération des clés privées +### 6.6. Génération des clés privées ![KeyGen](diagrams/KeyGen.png "KeyGen") -## 7. Authentification des `User` +## 7. Authentification des `User` Les `User` doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite `recover` mise en cache dans IndexedDB (données chiffrées par le mot de passe cf. [Chiffrement AES quantique résistant (AES-GCM-256)](#ChiffrementAESquantiquersistantAES-GCM-256)) pour les navigateurs et les applications mobiles, sinon chiffré de la même manière mais en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de Members choisi par les gestionnaires des Members des `Process` . @@ -98,23 +98,23 @@ Les `User` sont reconnus par une`adresse SP` dans un ou plusieurs rôles dans un Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) un `User`, et de la compléter par `Process` dans lequel l'`User` a un rôle (`onboarding`). -## 8. Connexion via des tiers +## 8. Connexion via des tiers Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience `User`. Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `Member`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux `Process` 4NK. -## 9. Fonctionnalité de récupération de mot de passe +## 9. Fonctionnalité de récupération de mot de passe En cas d'oubli de mot de passe, les `User` pourront récupérer leur accès depuis un nouveau `User` (`recover`) après avoir révoqué l'ancien `User`, via un processus sécurisé, impliquant une vérification d'un `User` et l'échange de secrets chiffrés conformément aux protocoles établis depuis une adresse de révocation `revoke`. Une image de révocation est générée à la création d'un `User` pour pouvoir dépenser un UTXO dit alors de révocation pour signaler aux autres Members de `Process` de ne plus prendre en compte les transactions venant de l'adresse silent payment actuelle du `User`. -## 10. Gestion de session basée sur un cache +## 10. Gestion de session basée sur un cache Le système ne maintiendra pas de session traditionnelle sur le serveur. La navigation de l'`User` persiste grâce à un cache local dans IndexedDB ou en mémoire, avec une politique de sécurité stricte forçant la resaisie du mot de passe après un rafraîchissement de la page ou une inactivité prolongée, déterminée par une durée maximale sans login. -## 11. Principe de fonctionnement +## 11. Principe de fonctionnement A la création d'un `User`, le SDK génère une clé privée Bitcoin pour les transactions SP (Silent Payments) et une clé privée pour la révocation de ce `User`. Ces clés sont stockées dans les données exif d'une image de login et d'une image de révocation, respectivement. @@ -133,7 +133,7 @@ Si l'`User` a aussi envoyé un `PRDUpdate` de la liste des `Process`, les `PRDRe Note : Les `User` sont communs à tous les `Process` et décrits par `Process` avec leurs champs spéciifiques dans des `Member` de type `Member` gérés par les `Member` qui sont listés dans le `Role` `Member` du `Process` via leur `adresse SP`. Lors de la création d'un `User`, on utilise le plus souvent un `Process` existant. On pourrait aussi s’arrêter à la création du `User` mais ce serait un peut étrange dans l’expérience car personne n’a besoin de créer un `User` sans aller sur `Process`. -## 12. Wallet +## 12. Wallet Les `transactions SP` ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) : @@ -162,7 +162,7 @@ Dans l'ordre on génère donc : 5. Clé privée de dépense mainnet `spend_mainnet`. 6. Clé privée de scan du mainnet `scan_mainnet`. -### 12.1. Récupération des jetons de faucet +### 12.1. Récupération des jetons de faucet Le relais retournent des jetons à la connexion et à l'envoi d'une `Envelope` afin de créer les `UTXO` nécessaires pour les transactions SP. @@ -172,11 +172,11 @@ A chaque nouvelle `Envelope` il génère de nouvelles addresses pour la clé qu Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des `Envelope` envoyés aux relais cf [Envelope-Specs.md](Envelope-Specs.md `Envelope` Specs) pour la générantion d'une wallet temporaire qui versera les fonds reçus du faucet sur l'adresse silent payment de l'`User`. -## 13. Gestion des clés du `User` +## 13. Gestion des clés du `User` -### 13.1. Génération des clés privées +### 13.1. Génération des clés privées -#### 13.1.1. Gestion de la clé servant à l'ID `spend_recover` +#### 13.1.1. Gestion de la clé servant à l'ID `spend_recover` La clé privée `spend_recover` est la clé principale des `User`. @@ -208,15 +208,15 @@ pre_id=sha256(part1_spend_recover_enc, MDP, random_seed) 2. Création d'un `PrdList` par Member (1 shard par Member) par `Prd` cf [PRD-PCD](PRD-PCD-Specs.md PRD-PCD) : -#### 13.1.2. Backup de `Part2Enc` +#### 13.1.2. Backup de `Part2Enc` Les relais initialisent le SDK (Wasm) par défaut avec une liste `ProcessList` contenant `Process` choisi. Chacun de des managers des Members sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `PrdResponse` en réponse au `PrdList` envoyé. -#### 13.1.3. Onboarding +#### 13.1.3. Onboarding -### 13.2. Member complété des champs du process sélectionné et mise à jour de la liste des Members du process +### 13.2. Member complété des champs du process sélectionné et mise à jour de la liste des Members du process Le role `Member` de `Process` sélectionné contient un `Item` avec des `metadata_contract_public`, `metadata_role_confidential` et `metadata_private` contenant chacun une `render_template_list` dont le premier élément du tableau est le formulaire de création du `User` pour champs concernés (publiques ou confidentiels ou privés). @@ -224,23 +224,23 @@ Ces formulaires permettront de créé les champs attendus par `condition_attribu Une fois `Member` complété, il est ajouté à la liste des Members pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Member` du `Process` sélectionné via un `PrdUpdate`. -### 13.3. Process complété de l'address SP de l'`User` et mise à jour de la liste des version du process +### 13.3. Process complété de l'address SP de l'`User` et mise à jour de la liste des version du process Pour le ou les roles sélectionnés, l'attribut `request_prd_sp_address_list` de `condition_prd_address_set_list` est complété par l'adresse SP de l'`User`. Une fois `Process` complété, il est ajouté à la liste des Members pour créer un nouveau `Pcd` envoyé pour mises à jours aux managers du rôle `Process` du `Process` sélectionné via un `PrdUpdate`. -### 13.4. Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné) +### 13.4. Réception des Pcd et PrdResponse en tenant compte des mises à jours (réception des clés de déchiffrement du role choisi dans le process sélectionné) Envoi d'un `PrdList` pour chaque Member de chaque rôle du process sélectionné. -## 14. Clés de révocation (`revoke`) +## 14. Clés de révocation (`revoke`) Les clés de l'image de révocation sont chiffrées par le mot de passe et stockées directement dans les données exifs de l'image de révocation. L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `PrdList` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface). -## 15. Clés de third parties +## 15. Clés de third parties Au moment de l'update de `Member` il est possible de charger des addresses SP de third parties pour lesquelles l'`User` a un rôle dans un `Process`. Ces adresses sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `Member`. @@ -248,7 +248,7 @@ Les clés privées associées sont générées lors de l'update d'un Member, à Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les `Prd` concernés. -## 16. Connexions avec un `User` (`recover`) +## 16. Connexions avec un `User` (`recover`) Pour recrééer sa clé privée et envoyer un `PrdList` à chaque Member du rôle `Member` du process, il faut réaliser les opérations suivantes : @@ -269,8 +269,8 @@ Puis depuis la liste des Members du process, pour chacun des Members : 6.4. Concaténation de `Part1` et `Part2` 7. Réception des flux PCD et PRDResponse des gestionnaires des Members -## 17. Exemples de Code +## 17. Exemples de Code -## 18. Todo +## 18. Todo * [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. diff --git a/doc/Envelope-Specs.md b/doc/Envelope-Specs.md index a76b89f..04a3114 100644 --- a/doc/Envelope-Specs.md +++ b/doc/Envelope-Specs.md @@ -14,36 +14,36 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 5. [Documents de référence](#Documentsderfrence) * 6. [4. Variable `PeerList` du SDK (Wasm)](#VariablePeerListduSDKWasm) * 7. [6. Caractéristiques générales des `Envelope` et `EnvelopeConnect`](#CaractristiquesgnralesdesEnvelopeetEnvelopeConnect) - * 7.1. [6.1. PeerList](#PeerList) - * 7.2. [6.2. ProcessList](#ProcessList) - * 7.3. [6.3. Taille des données](#Tailledesdonnes) - * 7.4. [6.4. Preuve de travail](#Preuvedetravail) - * 7.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet) - * 7.6. [Objets `EnvelopeGeneric` contenu dans les types `Envelope` et `EnvelopeConnect`](#ObjetsEnvelopeGenericcontenudanslestypesEnvelopeetEnvelopeConnect) +* 7.1. [6.1. PeerList](#PeerList) +* 7.2. [6.2. ProcessList](#ProcessList) +* 7.3. [6.3. Taille des données](#Tailledesdonnes) +* 7.4. [6.4. Preuve de travail](#Preuvedetravail) +* 7.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet) +* 7.6. [Objets `EnvelopeGeneric` contenu dans les types `Envelope` et `EnvelopeConnect`](#ObjetsEnvelopeGenericcontenudanslestypesEnvelopeetEnvelopeConnect) * 8. [7. Traitements par les clients](#Traitementsparlesclients) - * 8.1. [7.1. Connexion d'un client à sa liste de relais via les `EnvelopeConnect`](#ConnexiondunclientsalistederelaisvialesEnvelopeConnect) - * 8.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais) - * 8.1.2. [7.1.2. Envoi de l'`EnvelopeConnect` à chaque relais](#EnvoidelEnvelopeConnectchaquerelais) - * 8.2. [7.2. Envoi de `Request` sur les relais via l'`Envelope`](#EnvoideRequestsurlesrelaisvialEnvelope) - * 8.3. [7.4. Traitement des `Envelope` par les clients](#TraitementdesEnvelopeparlesclients) +* 8.1. [7.1. Connexion d'un client à sa liste de relais via les `EnvelopeConnect`](#ConnexiondunclientsalistederelaisvialesEnvelopeConnect) +* 8.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais) +* 8.1.2. [7.1.2. Envoi de l'`EnvelopeConnect` à chaque relais](#EnvoidelEnvelopeConnectchaquerelais) +* 8.2. [7.2. Envoi de `Request` sur les relais via l'`Envelope`](#EnvoideRequestsurlesrelaisvialEnvelope) +* 8.3. [7.4. Traitement des `Envelope` par les clients](#TraitementdesEnvelopeparlesclients) * 9. [8. Traitements par les relais](#Traitementsparlesrelais) - * 9.1. [8.1. Traitement des `EnvelopeConnect` par les relais](#TraitementdesEnvelopeConnectparlesrelais) - * 9.2. [8.2. Connexion au réseau de relais via `EnvelopeConnect` par les relais](#ConnexionaurseauderelaisviaEnvelopeConnectparlesrelais) +* 9.1. [8.1. Traitement des `EnvelopeConnect` par les relais](#TraitementdesEnvelopeConnectparlesrelais) +* 9.2. [8.2. Connexion au réseau de relais via `EnvelopeConnect` par les relais](#ConnexionaurseauderelaisviaEnvelopeConnectparlesrelais) * 10. [9. Traitement des `Envelope` par les relais](#TraitementdesEnvelopeparlesrelais) * 11. [10. Connexions aux réseaux de noeuds de Bitcoin, de réseaux side chain ou mainnet](#ConnexionsauxrseauxdenoeudsdeBitcoinderseauxsidechainoumainnet) - * 11.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs) - * 11.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions) - * 11.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs) - * 11.4. [10.4. Validation et relais](#Validationetrelais) - * 11.5. [10.5. Gestion des Forks](#GestiondesForks) - * 11.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain) - * 11.6.1. [10.6.1. Clients](#Clients) - * 11.6.2. [10.6.2. Relais](#Relais) - * 11.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1) - * 11.8. [10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)](#HorodatageetancragedesPrdvialestransactionsSilentPaymentsSP) +* 11.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs) +* 11.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions) +* 11.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs) +* 11.4. [10.4. Validation et relais](#Validationetrelais) +* 11.5. [10.5. Gestion des Forks](#GestiondesForks) +* 11.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain) +* 11.6.1. [10.6.1. Clients](#Clients) +* 11.6.2. [10.6.2. Relais](#Relais) +* 11.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1) +* 11.8. [10.8. Horodatage et ancrage des `Prd` via les transactions Silent Payments (SP)](#HorodatageetancragedesPrdvialestransactionsSilentPaymentsSP) * 12. [11. Transactions mainnet Bitcoin](#TransactionsmainnetBitcoin) - * 12.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin) - * 12.2. [11.2. Remboursement des frais d'horodatage et ancrage](#Remboursementdesfraisdhorodatageetancrage) +* 12.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin) +* 12.2. [11.2. Remboursement des frais d'horodatage et ancrage](#Remboursementdesfraisdhorodatageetancrage) * 13. [Exemples de Code](#ExemplesdeCode) * 14. [Todo](#Todo) diff --git a/doc/Item-Specs.md b/doc/Item-Specs.md index 605c6a8..83e7c72 100644 --- a/doc/Item-Specs.md +++ b/doc/Item-Specs.md @@ -1,11 +1,11 @@  # Item - Specifications -## 1. Autheurs, validations, dates, versions, changement and historique +## 1. Autheurs, validations, dates, versions, changement and historique Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) -## 2. Table des matières +## 2. Table des matières * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) @@ -13,12 +13,12 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 3. [Objectif](#Objectif) * 4. [Portée](#Porte) * 5. [Documents de référence](#Documentsderfrence) - * 5.1. [Types d'Items](#TypesdItems) - * 5.2. [ Composition et Fonction](#CompositionetFonction) - * 5.2.1. [Cas d'utilisation](#Casdutilisation) - * 5.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems) - * 5.3.1. [Composition et Fonction](#CompositionetFonction-1) - * 5.3.2. [Cas d'utilisation](#Casdutilisation-1) +* 5.1. [Types d'Items](#TypesdItems) +* 5.2. [Composition et Fonction](#CompositionetFonction) +* 5.2.1. [Cas d'utilisation](#Casdutilisation) +* 5.3. [MetaData - Gestion des Attributs d'Items](#MetaData-GestiondesAttributsdItems) +* 5.3.1. [Composition et Fonction](#CompositionetFonction-1) +* 5.3.2. [Cas d'utilisation](#Casdutilisation-1) * 6. [Process](#Process) * 7. [Exemples de Code](#ExemplesdeCode) * 8. [Todo](#Todo) @@ -29,17 +29,17 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) /vscode-markdown-toc-config --> -## 3. Objectif +## 3. Objectif Les transactions Silent Payments SP intègrent directement dans l'architecture web de l'application, comme démontré dans le client web. La gestion et l'intégration des SP sont conçues pour être fluides avec les systèmes front-end, assurant une expérience `User` transparente tout en maintenant la sécurité et la confidentialité au cœur de l'interaction `User`. -## 4. Portée +## 4. Portée -## 5. Documents de référence +## 5. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -### 5.1. Types d'Items +### 5.1. Types d'Items Dans le système 4NK, les items représentent les entités ou les objets appelés `Item` sur lesquels les transactions, les processus, et les interactions sont basés. Les types d'`items` incluent : @@ -49,7 +49,7 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé * **Artefact** : Un type d'objet générique personnalisable dans les `Process` , il peut y avoir une quantité infinie de type d'`artefacts` différents par `Process`. * **Payments, Deposit, commit**: Représentent divers types de transactions ou d'engagements au sein du réseau, avec des règles et des attributs spécifiques. -### 5.2. Composition et Fonction +### 5.2. Composition et Fonction * **uuid**: Identifiant unique de l'item, assurant sa traçabilité et son unicité au sein du système. * **version**: Numéro de version de l'item, facilitant le suivi des mises à jour et des modifications. @@ -59,33 +59,33 @@ Dans le système 4NK, les items représentent les entités ou les objets appelé * **pagination_number_per_request_pcd**: Détermine comment l'item est paginé ou divisé dans le contexte des Pcd, affectant la manière dont il est présenté ou accessible. * **metadata**: Comprend MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate, encapsulant les attributs de l'item selon différents niveaux de confidentialité. -#### 5.2.1. Cas d'utilisation +#### 5.2.1. Cas d'utilisation Les items sont utilisés pour tout, depuis la représentation des participants et des ressources dans le système jusqu'à la structuration des contrats et des processus. Ils sont essentiels pour organiser et gérer efficacement les données et les interactions au sein du réseau 4NK. -### 5.3. MetaData - Gestion des Attributs d'Items +### 5.3. MetaData - Gestion des Attributs d'Items La structure MetaData joue un rôle crucial dans la définition des attributs et des caractéristiques des items, enrichissant leur définition et leur utilité au sein du système. -#### 5.3.1. Composition et Fonction +#### 5.3.1. Composition et Fonction * **tag_list**, **zone_list**, **label_list**, **ref_list**, **data_list**: Collections d'étiquettes, zones, labels, références, et données associées à l'item, permettant une classification et une organisation détaillées. * **amount**, **number**: Champs numériques pour représenter des quantités ou des valeurs associées à l'item, utilisés dans divers contextes comme le suivi des ressources ou la définition des conditions. * **render_template_list**, **legal_text_list**: Fournissent des templates pour la présentation de l'item et des textes légaux associés, cruciaux pour la documentation et la conformité. * **key_list**: Liste des clés de chiffrement ou d'autres clés cryptographiques associées à l'item, essentielles pour la sécurité et l'authentification. -#### 5.3.2. Cas d'utilisation +#### 5.3.2. Cas d'utilisation La richesse et la diversité des métadonnées permettent une personnalisation et une spécification précises des items, soutenant des processus complexes, des contrats détaillés, et des interactions sécurisées au sein du réseau. -## 6. Process +## 6. Process * **item**: Base de l'Process, liant les processus aux items spécifiques au sein du système. * **item_process_public_attribute_group**: Groupe d'attributs publics associés à un processus, définissant les règles, les rôles et les conditions d'exécution du processus. -## 7. Exemples de Code +## 7. Exemples de Code -## 8. Todo +## 8. Todo * [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels. * [ ] Diagrammes de séquences diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index 42c1a38..3f8ab11 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -1,10 +1,10 @@ # PRD PCD - Specifications -## 1. Autheurs, validations, dates, versions, changement and historique +## 1. Autheurs, validations, dates, versions, changement and historique Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) -## 2. Table des matières +## 2. Table des matières * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) @@ -13,7 +13,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 4. [Portée](#Porte) * 5. [Documents de référence](#Documentsderfrence) * 6. [Définitions](#Dfinitions) -* 7. [Principes d'une `Envelope` rie](#PrincipesduneEnveloperie) +* 7. [Principes de messagerie](#Principesdemessagerie) * 8. [Encryption](#Encryption) * 9. [Fonction des Pcd](#FonctiondesPcd) * 9.1. [Schéma des flux](#Schmadesflux) @@ -25,7 +25,7 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 10.3. [Réception](#Rception-1) * 11. [PrdList - Demande de Listes](#PrdList-DemandedeListes) * 11.1. [Schéma des flux](#Schmadesflux-1) -* 12. [PrdMessage - Envoi d'une `Envelope`](#PrdMessage-EnvoiduneEnvelope) +* 12. [PrdMessage - Envoi d'un message](#PrdMessage-Envoidunmessage) * 12.1. [Schéma des flux](#Schmadesflux-1) * 13. [PrdUpdate - Mises à Jour de Pcd](#PrdUpdate-MisesJourdePcd) * 13.1. [Schéma des flux](#Schmadesflux-1) @@ -42,19 +42,19 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) /vscode-markdown-toc-config --> -## 3. Objectif +## 3. Objectif Le but de cette section est d'introduire les Portable Contract Document (`Pcd`) et Portable Request Document (`Prd`) comme éléments fondamentaux du système 4NK. Ces documents jouent un rôle crucial dans la sécurisation des échanges de données et la gestion des `User` au sein d'un réseau décentralisé. Ils permettent de définir des contrats numériques, de gérer les permissions d'accès, et de faciliter les communications et les opéraations sécurisées entre les différents acteurs du réseau. -## 4. Portée +## 4. Portée La spécification couvre la conception, le développement, et l'application pratique des `Pcd` et `Prd`.Elle vise à expliquer leur fonctionnement, leur structure, et la manière dont ils contribuent à l'écosystème 4NK en offrant une méthode sécurisée et efficace pour le partage d'informations et la validation des transactions. Les `Pcd` et `Prd` encapsulent les données contractuelles et les requêtes dans un format standardisé, assurant l'intégrité, la confidentialité, l'authenticité et la validation des informations échangées. -## 5. Documents de référence +## 5. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 6. Définitions +## 6. Définitions * **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `Process` (`item_type`). @@ -75,11 +75,11 @@ Voir [_Doc_references.md](_Doc_references.md). * **pre-id**: Pré-identifiant des `User`, constitué du hash de la partie 1 de la `KeyRecover`. -## 7. Principes de messagerie +## 7. Principes de messagerie Les `Pcd` sont envoyés à tous les participants connectés sans attente de retour spécifique et ne sont pas associés à une `transaction SP`. -Les `Prd` sont toujours accompagnés d'une `transaction SP`, transmise dans l'attribut `raw_transaction_list` d'un `PrdMessage` associé (à l'exception des `PrdMessage` eux-mêmes). +Les `Prd` sont toujours accompagnés d'une `transaction SP`, transmise dans l'attribut `raw_transaction_list` d'une `Envelope`. Les `Prd` sont des demandes d'actions ou des réponses à ces demandes, interagissant de la manière suivante : @@ -138,7 +138,7 @@ Ce qui est résumé Pour la réception : | `PrdResponse` | Prd | Yes | No | No | No | No | | `PrdConfirm` | Prd | No | No | No | No | No | -## 8. Encryption +## 8. Encryption Schema : @@ -166,7 +166,7 @@ Principaux champs des `Request` contenus dans les `Pcd` et `Prd` chiffrés : * **`request_prd_origin_hash`** : Hash du `Prd` à l'origine du `Prd`. * **`item_reference_hash`** : Hash de `Item` auquel le `Pcd` fait référence. -## 9. Fonction des Pcd +## 9. Fonction des Pcd Les Portable Contract Documents (`Pcd`) sont des documents au format `JSON` encapsulant des listes versionnées d'`Item`, dont les attributs sont chiffsrés selon trois niveaux de confidentialité : public, par rôles spécifiques, ou privé. (cf. [Specs-Security.md](Specs-Security.md)). @@ -215,11 +215,11 @@ Principaux champs de la structure `PcdItemEncAttributePrivate` : * **`key`** : [PRIVE] Clé de chiffrement, non partagée dans les `Envelope`. Données en clair. * **`data`** : [PRIVE] Non partagé dans les `Envelope`. Données en clair. -### 9.1. Schéma des flux +### 9.1. Schéma des flux ![Pcd](diagrams/PCD.png "Pcd") -### 9.2. Création et envoi +### 9.2. Création et envoi La création d'un `Pcd` suit plusieurs étapes : @@ -232,7 +232,7 @@ Schéma de finalisation de la création d'un `Pcd` : [PCD finalize](diagrams/PCDFinalize.png "PCD finalize") -### 9.3. Réception +### 9.3. Réception La réception d'un `Pcd` suit plusieurs étapes : @@ -243,7 +243,7 @@ Schéma de finalisation de la réception d'un `Pcd` : [PCD Received](diagrams/PCDReceived.png "PCD Received") -## 10. Fonction des`Prd` +## 10. Fonction des`Prd` Les Portable Request Documents (Prd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `Pcd` via l'attribut `Pcd_keys_role_confidential_list_confidential`. Ils sont utilisés pour solliciter des actions spécifiques, telles que l'envoi d'un message, la mise à jour des informations contractuelles, ou la confirmation de transactions. @@ -279,13 +279,13 @@ Principaux champs des `Prd` : * **`certif_key_confidential`** : Clé de certification chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`device_footprint_enc_by_sp_shared_secret`** : Empreinte du dispositif de l'émetteur, chiffrée par la clé `KeyConfidential` d'une `transaction SP`. -### 10.1. Schéma des flux +### 10.1. Schéma des flux Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. ![Prd](diagrams/PRD.png "Prd") -### 10.2. Création d'un `Prd` +### 10.2. Création d'un `Prd` 1. Complétion des attributs 2. Création d'une `adresse SP` cf [Silent Payments - Specs](Silent-Payments-Specs.md) @@ -296,7 +296,7 @@ Schéma de finalisation de la création d'un `Prd` : [PRD finalize](diagrams/PRDFinalize.png "PRD finalize") -### 10.3. Réception +### 10.3. Réception La réception d'un `Prd` suit plusieurs étapes : @@ -316,7 +316,7 @@ Schéma de finalisation de la réception d'un `Prd` : [PRD Received](diagrams/PRDReceived.png "PRD Received") -## 11. PrdList - Demande de Listes +## 11. PrdList - Demande de Listes Utile pour les `User` souhaitant consulter ou explorer des listes de contrats, de membres ou d'autres items dans le réseau. Chaque `Pcd` liste des `Item` d'un même type, tels que les `Process`, les `Member`, les `Peer`, les `Payments`, etc. @@ -365,13 +365,13 @@ Dans le cas d'une création de compte : * **`priv_key_mainnet_scan`** : Clé de scan de l'`User`, chiffrée par la clé privée du mainnet, chiffrée par `KeyRecover`. * **`priv_key_signet_scan`** : Clé de scan du signet de `recover`de l'`User`, chiffrée `KeyRecover`. -### 11.1. Schéma des flux +### 11.1. Schéma des flux Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. ![PrdList](diagrams/PRDList.png "PrdList") -## 12. PrdMessage - Envoi d'un message +## 12. PrdMessage - Envoi d'un message Le `PrdMessage` facilite l'envoi d'un message sécurisé entre `User`. @@ -384,13 +384,13 @@ Principaux champs des `PrdMessage` : * **`request_prd`** : cf la descripton de la structure `Prd`. -### 12.1. Schéma des flux +### 12.1. Schéma des flux Pour simplifier, les `PrdConfirm` n'ont pas été inclus dans le schéma. ![PrdMessage](diagrams/PRDEnvelope.png "PrdMessage") -## 13. PrdUpdate - Mises à Jour de Pcd +## 13. PrdUpdate - Mises à Jour de Pcd `PrdUpdate` est conçu pour demander des mises à jour des listes via de nouvelles versions de `Pcd`. @@ -410,13 +410,13 @@ Principaux champs des `PrdUpdate` : * **`request_prd`** : cf la descripton de la structure `Prd`. -### 13.1. Schéma des flux +### 13.1. Schéma des flux Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma. ![PrdUpdate](diagrams/PRDUpdate.png "PrdUpdate") -## 14. PrdConfirm - Confirmation de Réception +## 14. PrdConfirm - Confirmation de Réception Le `PrdConfirm` est utilisé pour confirmer la réception et le traitement de demandes ou de transactions, jouant un rôle crucial dans la validation des actions au sein du réseau. @@ -429,11 +429,11 @@ Principaux champs des `PrdConfirm` : * **`request_prd`** : cf la descripton de la structure `Prd`. * **`code_confirm_confidential`** : Code de confirmation chiffré par la clé `KeyConfidential` d'une `transaction SP` dans le cas d'un 2FA. -### 14.1. Schéma des flux +### 14.1. Schéma des flux ![PrdConfirm](diagrams/PRDConfirm.png "PrdConfirm") -## 15. PrdResponse - Répondre à une Demande +## 15. PrdResponse - Répondre à une Demande Le `PrdResponse` permet de répondre spécifiquement à des `Prd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. @@ -451,12 +451,12 @@ Principaux champs des `PrdResponse` : * **`shared_secret_key_enc_by_sp_shared_secret`** : Clé de chiffrement partagée chiffrée par la clé `KeyConfidential` d'une `transaction SP`. * **`shard_enc_by_sp_shared_secret`** : Shard chiffré par la clé `KeyConfidential` d'une `transaction SP`. -### 15.1. Schéma des flux +### 15.1. Schéma des flux Pour simplifier, les `PrdConfirm` n'ont pas été représentés dans le schéma. ![PrdResponse](diagrams/PRDResponse.png "PrdResponse") -## 16. Exemples de Code +## 16. Exemples de Code -## 17. Todo +## 17. Todo diff --git a/doc/Silent-Payments-Specs.md b/doc/Silent-Payments-Specs.md index cf57ed0..5b32bf0 100644 --- a/doc/Silent-Payments-Specs.md +++ b/doc/Silent-Payments-Specs.md @@ -15,8 +15,6 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 6. [ Fonction](#Fonction) * 7. [ Structure des outputs](#Structuredesoutputs) * 8. [Envoi de la transaction SP](#EnvoidelatransactionSP) -* 8.1. [Dans un `PrdMessage`](#DansunPrdMessage) -* 8.2. [Dans un `Envelope` du `PrdMessage`](#DansunEnvelopeduPrdMessage) * 9. [ En réception les transactions silent Payments SP sont relayées par les relais en temps réel](#EnrceptionlestransactionssilentPaymentsSPsontrelayesparlesrelaisentempsrel) * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) * 2. [Table des matières](#Tabledesmatires) * 3. [Documents de référence](#Documentsderfrence) * 4. [Choix des formats de données](#Choixdesformatsdedonnes) - * 4.1. [Strings](#Strings) - * 4.2. [Hexadécimales](#Hexadcimales) - * 4.3. [Tableaux de bytes](#Tableauxdebytes) - * 4.3.1. [8 Bytes (64 bits)](#Bytes64bits) - * 4.3.2. [16 Bytes (128 bits)](#Bytes128bits) - * 4.3.3. [32 Bytes (256 bits)](#32Bytes256bits) - * 4.3.4. [64 Bytes (512 bits)](#64Bytes512bits) - * 4.3.5. [Précautions générales pour la manipulation des tableaux de bytes](#Prcautionsgnralespourlamanipulationdestableauxdebytes) - * 4.4. [Format Base64](#FormatBase64) - * 4.5. [Différence entre Bytes et Bits](#DiffrenceentreBytesetBits) - * 4.6. [Little Endian et Big Endian](#LittleEndianetBigEndian) - * 4.7. [Conversions de données](#Conversionsdedonnes) - * 4.7.1. [Conversion entre Strings et Hexadécimales](#ConversionentreStringsetHexadcimales) - * 4.7.2. [Conversion entre Tableaux de Bytes et Format Base64](#ConversionentreTableauxdeBytesetFormatBase64) - * 4.7.3. [Conversion entre Bytes et Bits](#ConversionentreBytesetBits) - * 4.7.4. [Gestion de Little Endian et Big Endian](#GestiondeLittleEndianetBigEndian) - * 4.7.5. [Bonnes Pratiques Générales](#BonnesPratiquesGnrales) +* 4.1. [ Strings](#Strings) +* 4.2. [ Hexadécimales](#Hexadcimales) +* 4.3. [ Tableaux de bytes](#Tableauxdebytes) +* 4.3.1. [8 Bytes (64 bits)](#Bytes64bits) +* 4.3.2. [16 Bytes (128 bits)](#Bytes128bits) +* 4.3.3. [ 32 Bytes (256 bits)](#32Bytes256bits) +* 4.3.4. [ 64 Bytes (512 bits)](#64Bytes512bits) +* 4.3.5. [  Précautions générales pour la manipulation des tableaux de bytes](#Prcautionsgnralespourlamanipulationdestableauxdebytes) +* 4.4. [ Format Base64](#FormatBase64) +* 4.5. [ Différence entre Bytes et Bits](#DiffrenceentreBytesetBits) +* 4.6. [Little Endian et Big Endian](#LittleEndianetBigEndian) +* 4.7. [ Conversions de données](#Conversionsdedonnes) +* 4.7.1. [Conversion entre Strings et Hexadécimales](#ConversionentreStringsetHexadcimales) +* 4.7.2. [Conversion entre Tableaux de Bytes et Format Base64](#ConversionentreTableauxdeBytesetFormatBase64) +* 4.7.3. [Conversion entre Bytes et Bits](#ConversionentreBytesetBits) +* 4.7.4. [Gestion de Little Endian et Big Endian](#GestiondeLittleEndianetBigEndian) +* 4.7.5. [Bonnes Pratiques Générales](#BonnesPratiquesGnrales) * 5. [Recommandations entre l'usage de HashMap ou d'un Vec (en Rust)](#RecommandationsentrelusagedeHashMapoudunVecenRust) - * 5.1. [Utilisez un Vec si](#UtilisezunVecsi) - * 5.2. [Utilisez un HashMap si](#UtilisezunHashMapsi) - * 5.3. [Recommandations Générales](#RecommandationsGnrales) +* 5.1. [Utilisez un Vec si](#UtilisezunVecsi) +* 5.2. [Utilisez un HashMap si](#UtilisezunHashMapsi) +* 5.3. [ Recommandations Générales](#RecommandationsGnrales) * 6. [Gestion des erreurs](#Gestiondeserreurs) * 7. [Journalisation et monitoring](#Journalisationetmonitoring) * 8. [Tests](#Tests) - * 8.1. [Stratégie de test](#Stratgiedetest) - * 8.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires) - * 8.3. [Plan d'intégration](#Plandintgration) - * 8.4. [Plan de charge](#Plandecharge) +* 8.1. [Stratégie de test](#Stratgiedetest) +* 8.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires) +* 8.3. [Plan d'intégration](#Plandintgration) +* 8.4. [Plan de charge](#Plandecharge) * 9. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser) * 10. [Critères d'acceptation](#Critresdacceptation) * 11. [CI/CD](#CICD) @@ -52,13 +52,13 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) /vscode-markdown-toc-config --> -## 3. Documents de référence +## 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 4. Choix des formats de données +## 4. Choix des formats de données -### 4.1.  Strings +### 4.1.  Strings Les chaînes de caractères (String et &str) sont utilisées pour stocker du texte. String est une collection dynamique, modifiable, possédant une allocation sur le tas, tandis que &str est une vue immuable d'une séquence de caractères. @@ -68,7 +68,7 @@ Cas d'usage commun : * Traitement de données formatées comme le JSON ou le XML. * Communication réseau où les protocoles basés sur le texte sont utilisés (HTTP, SMTP). -### 4.2.  Hexadécimales +### 4.2.  Hexadécimales Les valeurs hexadécimales sont souvent utilisées pour représenter des données binaires de manière lisible, notamment dans le contexte de l'adressage mémoire, du débogage, ou de la représentation de couleurs en informatique. @@ -78,7 +78,7 @@ Cas d'usage commun : * Définition de couleurs dans les standards web (CSS). * Représentation compacte d'adresses mémoire ou de grandes valeurs binaires. -### 4.3.  Tableaux de bytes +### 4.3.  Tableaux de bytes Les tableaux de bytes (```Vec``` ou ```[u8]``` en Rust) sont utilisés pour manipuler des données binaires. Ils servent à stocker et transmettre des données dans un format qui n'est pas nécessairement du texte. @@ -90,7 +90,7 @@ Cas d'usage commun : Les tableaux de bytes sont au cœur de nombreuses opérations en informatique, en particulier dans les domaines nécessitant un traitement direct des données à bas niveau. La taille de ces tableaux varie en fonction de leur usage. Voici quelques tailles communes de tableaux de bytes, leurs usages typiques et des précautions à prendre lors de leur manipulation. -#### 4.3.1. 8 Bytes (64 bits) +#### 4.3.1. 8 Bytes (64 bits) Souvent utilisé pour des nombres entiers longs, des adresses mémoire en architecture 64 bits, ou des timestamps. Tailles spécifiques à des protocoles ou formats de fichier : De nombreux formats de fichiers (comme les images, l'audio, la vidéo) et protocoles de communication ont des tailles de blocs ou de trames spécifiques qui ne suivent pas nécessairement un schéma basé sur la sécurité. @@ -99,7 +99,7 @@ Précaution : * La compréhension des spécifications techniques et des contraintes de chaque format ou protocole est essentielle pour manipuler efficacement ces tailles de données. * Dans le contexte des formats de fichier et des protocoles de communication, assurez-vous de respecter les standards pour garantir la compatibilité et l'interopérabilité. -#### 4.3.2. 16 Bytes (128 bits) +#### 4.3.2. 16 Bytes (128 bits) Usage : @@ -111,7 +111,7 @@ Précaution : * Lors de l'utilisation pour la cryptographie, assurez-vous que la génération des clés est suffisamment aléatoire. * Pour les UUIDs, utilisez des bibliothèques éprouvées pour garantir l'unicité. -#### 4.3.3.  32 Bytes (256 bits) +#### 4.3.3.  32 Bytes (256 bits) Usage : @@ -123,7 +123,7 @@ Précaution : * Comme pour les clés de 128 bits, l'aléatoire dans la génération des clés est crucial. * Pour le SHA-256, être conscient de son utilisation appropriée et des limites dans les contextes de sécurité. -#### 4.3.4.  64 Bytes (512 bits) +#### 4.3.4.  64 Bytes (512 bits) Usage : @@ -134,7 +134,7 @@ Précaution : * Les coûts en performance pour le traitement de telles tailles doivent être pris en compte, en particulier sur des appareils à ressources limitées. -#### 4.3.5.   Précautions générales pour la manipulation des tableaux de bytes +#### 4.3.5.   Précautions générales pour la manipulation des tableaux de bytes * **Sécurité** : Lors de la manipulation de données sensibles (comme les clés de cryptographie), assurez-vous que le stockage et le transfert des bytes soient sécurisés pour éviter les fuites d'informations. @@ -146,7 +146,7 @@ Précaution : * **Libération de ressources** : Pour les données sensibles, pensez à effacer (zeroize) les tableaux de bytes de la mémoire une fois qu'ils ne sont plus nécessaires, pour réduire le risque d'exposition. -### 4.4.  Format Base64 +### 4.4.  Format Base64 Le format Base64 est une méthode d'encodage qui permet de représenter des données binaires sous forme de chaînes de caractères ASCII. Il est couramment utilisé pour encoder des données binaires dans des contextes où les données textuelles sont préférées, comme dans le XML, le JSON, ou les courriels. @@ -156,7 +156,7 @@ Cas d'usage commun : * Transmission de données binaires dans des protocoles de communication qui ne supportent que le texte. * Stockage sécurisé d'informations sensibles sous une forme encodée. -### 4.5.  Différence entre Bytes et Bits +### 4.5.  Différence entre Bytes et Bits Un byte est une unité de stockage informatique qui contient 8 bits. Un bit est la plus petite unité de données en informatique et peut prendre la valeur de 0 ou 1. @@ -165,7 +165,7 @@ Cas d'usage commun : * Les bits sont utilisés pour les opérations au niveau le plus basique de l'informatique, comme les calculs binaires ou le stockage de valeurs booléennes. * Les bytes sont utilisés pour presque toutes les formes de stockage et de manipulation de données, comme le texte, les images, et les instructions de programme. -### 4.6. Little Endian et Big Endian +### 4.6. Little Endian et Big Endian Ce sont deux manières différentes de stocker ou d'interpréter des séquences de bytes qui composent des nombres plus grands dans l'ordinateur. En Big Endian, le byte le plus significatif est stocké en premier. En Little Endian, c'est le byte le moins significatif qui est stocké en premier. @@ -177,35 +177,35 @@ Cas d'usage commun : Cette vue d'ensemble donne une idée de l'importance et de la polyvalence de ces concepts en programmation Rust et plus largement en informatique. Chaque élément a des cas d'usage spécifiques où il brille particulièrement bien, aidant les développeurs à choisir la meilleure approche pour leurs besoins. -### 4.7.  Conversions de données +### 4.7.  Conversions de données Aborder les conversions entre différents formats de données est essentiel dans le développement de logiciels, notamment en Rust, où la gestion de la mémoire et des types est centrale. -#### 4.7.1. Conversion entre Strings et Hexadécimales +#### 4.7.1. Conversion entre Strings et Hexadécimales * **Préconisation** : Utilisez des bibliothèques éprouvées pour convertir les chaînes de caractères en hexadécimales et vice versa. Ces opérations peuvent sembler simples, mais gérer correctement tous les cas d'erreur potentiels peut être délicat. * **Retour d'expérience** : La conversion directe peut être tentante, mais attention aux données non représentables en hexadécimal directement (comme les caractères spéciaux ou non ASCII). La validation des entrées est cruciale pour éviter les erreurs. -#### 4.7.2. Conversion entre Tableaux de Bytes et Format Base64 +#### 4.7.2. Conversion entre Tableaux de Bytes et Format Base64 * **Préconisation** : Lors de la conversion de données binaires (comme des tableaux de bytes) en Base64, assurez-vous de comprendre l'impact sur la taille des données. La représentation en Base64 augmente la taille des données d'environ 33%. Cela peut être important pour les performances réseau et le stockage. * **Retour d'expérience** : L'utilisation de Base64 est très pratique pour intégrer des ressources binaires dans des formats textuels (comme des images en HTML/CSS). Cependant, cette facilité d'utilisation doit être équilibrée avec la considération de l'augmentation de la taille des données. -#### 4.7.3. Conversion entre Bytes et Bits +#### 4.7.3. Conversion entre Bytes et Bits * **Préconisation** : Soyez conscient de l'endianess lorsque vous travaillez avec des conversions de bits à bytes et vice versa. Des erreurs dans ces conversions peuvent entraîner des bugs subtils et difficiles à détecter, surtout lors de l'interopérabilité entre différents systèmes ou protocoles. * **Retour d'expérience** : Dans les applications bas niveau ou embarquées, ces conversions sont courantes. L'utilisation explicite de types de données et de fonctions de conversion aide à maintenir la clarté du code et à éviter les erreurs. -#### 4.7.4. Gestion de Little Endian et Big Endian +#### 4.7.4. Gestion de Little Endian et Big Endian * **Préconisation** : Lorsque vous travaillez dans un environnement hétérogène (différentes architectures de machines ou réseaux), il est essentiel d'être explicite sur l'endianess des données lors de leur envoi, réception, ou stockage. Utilisez des fonctions de conversion dédiées pour modifier l'ordre des bytes lorsque nécessaire. * **Retour d'expérience** : Les erreurs d'endianess sont parmi les plus déroutantes à diagnostiquer. Documenter clairement l'endianess attendue pour chaque interface peut sauver des heures de débogage. -#### 4.7.5. Bonnes Pratiques Générales +#### 4.7.5. Bonnes Pratiques Générales * **Validation des données** : Toujours valider les données en entrée lors des conversions pour éviter des erreurs inattendues ou des vulnérabilités de sécurité. * **Performance** : Soyez conscient de l'impact sur les performances des conversions, surtout dans des boucles critiques ou pour des données volumineuses. @@ -213,11 +213,11 @@ Aborder les conversions entre différents formats de données est essentiel dans Les conversions entre différents formats de données sont omniprésentes en programmation. Une compréhension approfondie de ces opérations et une attention particulière aux détails peuvent grandement améliorer la robustesse et l'efficacité de vos applications. -## 5. Recommandations entre l'usage de HashMap ou d'un Vec (en Rust) +## 5. Recommandations entre l'usage de HashMap ou d'un Vec (en Rust) En Rust, le choix entre l'utilisation d'un HashMap et d'un Vec dépend largement de la nature de vos données et de ce que vous cherchez à accomplir. Voici quelques points à considérer pour faire le bon choix : -### 5.1. Utilisez un Vec si +### 5.1. Utilisez un Vec si * **Les données sont accessées par index**: Vec est idéal lorsque vous travaillez avec une collection ordonnée d'éléments accessibles par leur index. L'accès, l'insertion et la suppression à la fin du vecteur sont très rapides. @@ -225,7 +225,7 @@ En Rust, le choix entre l'utilisation d'un HashMap et d'un Vec dépend largement * **Vous avez besoin d'ordre**: Si l'ordre des éléments est important pour votre application, Vec maintient l'ordre d'insertion, tandis que HashMap ne le fait pas. -### 5.2. Utilisez un HashMap si +### 5.2. Utilisez un HashMap si * **Recherche rapide par clé**: HashMap excelle lorsque vous avez besoin de chercher, d'insérer ou de supprimer des éléments en utilisant une clé. La complexité temporelle de ces opérations est en moyenne O(1), ce qui est particulièrement efficace pour de grands ensembles de données. @@ -233,7 +233,7 @@ En Rust, le choix entre l'utilisation d'un HashMap et d'un Vec dépend largement * **Évitement des doublons pour les clés**: HashMap assure qu'il n'y a pas deux entrées avec la même clé, ce qui peut être essentiel pour certaines applications. -### 5.3.  Recommandations Générales +### 5.3.  Recommandations Générales * **Évaluez la taille de votre collection**: Pour des collections très petites, la différence de performance entre Vec et HashMap peut être négligeable, et d'autres facteurs, comme l'ordre des éléments ou la clarté du code, peuvent prévaloir. @@ -245,7 +245,7 @@ En Rust, le choix entre l'utilisation d'un HashMap et d'un Vec dépend largement En résumé, le choix entre Vec et HashMap en Rust doit être guidé par les spécificités de vos données et par les opérations que vous prévoyez d'effectuer. Prendre le temps de comprendre ces structures de données et leurs implications peut grandement affecter la performance et la clarté de votre code. -## 6. Gestion des erreurs +## 6. Gestion des erreurs Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être `catch` si il y a une possiblité d'interuption. @@ -259,7 +259,7 @@ Les arrêts des Members dans les `Process` dans leur ensemble n'entraînent pas Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des Members des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques. -## 7. Journalisation et monitoring +## 7. Journalisation et monitoring Tous les `User` reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les `Pcd` sont les listes à jour de l'état de validation de tous les éléments échangés, et les `Prd` sont toutes les signatures échangées sur les flux; en mémoire côté `User`, par "session" sur un nœud, pour un `Process` (possible de segmenter par zones et services). @@ -267,27 +267,27 @@ Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents s La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque `Envelope` ) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels. -## 8. Tests +## 8. Tests -### 8.1. Stratégie de test +### 8.1. Stratégie de test À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur. -### 8.2. Plan pour les tests unitaires +### 8.2. Plan pour les tests unitaires Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire. -### 8.3. Plan d'intégration +### 8.3. Plan d'intégration L'intégration se réalise par sprint hebdomadaire. L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint. -### 8.4. Plan de charge +### 8.4. Plan de charge Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des `User`. -## 9. Outils et les librairies à utiliser +## 9. Outils et les librairies à utiliser Respect des normes de syntaxe Rust. @@ -305,7 +305,7 @@ Utilisation de Visual Studio (pour le partage de configurations). * **Librairies de tests** : Cargo test -## 10. Critères d'acceptation +## 10. Critères d'acceptation Critères de validation pour que le système puisse être considéré comme prêt pour la production : @@ -319,15 +319,15 @@ Critères de validation pour que le système puisse être considéré comme prê * Documentation manquante clairement précisée. * Autres tests manquants clairement précisés. -## 11. CI/CD +## 11. CI/CD GitLab CI : TBD -## 12. Maintenance +## 12. Maintenance La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint. Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance. -## 13. Exemples de Code +## 13. Exemples de Code -## 14. Todo +## 14. Todo diff --git a/doc/Specs-Datamodel.md b/doc/Specs-Datamodel.md index ad31d64..9bd0b64 100644 --- a/doc/Specs-Datamodel.md +++ b/doc/Specs-Datamodel.md @@ -11,116 +11,116 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) * 2. [Table des matières](#Tabledesmatires) * 3. [Documents de référence](#Documentsderfrence) * 4. [Methods](#Methods) -* 4.1. [DepositMethod](#DepositMethod) -* 4.2. [commitMethod](#commitMethod) -* 4.3. [PaymentsMethod](#PaymentsMethod) + * 4.1. [DepositMethod](#DepositMethod) + * 4.2. [commitMethod](#commitMethod) + * 4.3. [PaymentsMethod](#PaymentsMethod) * 5. [Items](#Items) -* 5.1. [Item](#Item) -* 5.2. [Artefact](#Artefact) -* 5.3. [Member](#Member) -* 5.3.1. [MemberPublicAttributeGroup](#MemberPublicAttributeGroup) -* 5.3.2. [MemberRoleConfidentialAttributeGroup](#MemberRoleConfidentialAttributeGroup) -* 5.3.3. [MemberRolePrivateAttributeGroup](#MemberRolePrivateAttributeGroup) -* 5.4. [Commit](#Commit) -* 5.4.1. [CommitRoleConfidentialAttributeGroup](#CommitRoleConfidentialAttributeGroup) -* 5.4.2. [CommitPrivateAttributeGroup](#CommitPrivateAttributeGroup) -* 5.5. [Deposit](#Deposit) -* 5.5.1. [DepositPublicAttributeGroup](#DepositPublicAttributeGroup) -* 5.5.2. [DepositRoleConfidentialAttributeGroup](#DepositRoleConfidentialAttributeGroup) -* 5.5.3. [DepositPrivateAttributeGroup](#DepositPrivateAttributeGroup) -* 5.6. [ItemEnum](#ItemEnum) -* 5.7. [Payments](#Payments) -* 5.7.1. [PaymentsPublicAttributeGroup](#PaymentsPublicAttributeGroup) -* 5.7.2. [PaymentsRoleConfidentialAttributeGroup](#PaymentsRoleConfidentialAttributeGroup) -* 5.7.3. [PaymentsPrivateAttributeGroup](#PaymentsPrivateAttributeGroup) -* 5.8. [Peer](#Peer) -* 5.8.1. [PeerPublicAttributeGroup](#PeerPublicAttributeGroup) -* 5.8.2. [PeerPrivateAttributeGroup](#PeerPrivateAttributeGroup) -* 5.9. [Process](#Process) -* 5.9.1. [ProcessPublicAttributeGroup](#ProcessPublicAttributeGroup) + * 5.1. [Item](#Item) + * 5.2. [Artefact](#Artefact) + * 5.3. [Member](#Member) + * 5.3.1. [MemberPublicAttributeGroup](#MemberPublicAttributeGroup) + * 5.3.2. [MemberRoleConfidentialAttributeGroup](#MemberRoleConfidentialAttributeGroup) + * 5.3.3. [MemberRolePrivateAttributeGroup](#MemberRolePrivateAttributeGroup) + * 5.4. [Commit](#Commit) + * 5.4.1. [CommitRoleConfidentialAttributeGroup](#CommitRoleConfidentialAttributeGroup) + * 5.4.2. [CommitPrivateAttributeGroup](#CommitPrivateAttributeGroup) + * 5.5. [Deposit](#Deposit) + * 5.5.1. [DepositPublicAttributeGroup](#DepositPublicAttributeGroup) + * 5.5.2. [DepositRoleConfidentialAttributeGroup](#DepositRoleConfidentialAttributeGroup) + * 5.5.3. [DepositPrivateAttributeGroup](#DepositPrivateAttributeGroup) + * 5.6. [ItemEnum](#ItemEnum) + * 5.7. [Payments](#Payments) + * 5.7.1. [PaymentsPublicAttributeGroup](#PaymentsPublicAttributeGroup) + * 5.7.2. [PaymentsRoleConfidentialAttributeGroup](#PaymentsRoleConfidentialAttributeGroup) + * 5.7.3. [PaymentsPrivateAttributeGroup](#PaymentsPrivateAttributeGroup) + * 5.8. [Peer](#Peer) + * 5.8.1. [PeerPublicAttributeGroup](#PeerPublicAttributeGroup) + * 5.8.2. [PeerPrivateAttributeGroup](#PeerPrivateAttributeGroup) + * 5.9. [Process](#Process) + * 5.9.1. [ProcessPublicAttributeGroup](#ProcessPublicAttributeGroup) * 6. [Encryption](#Encryption) -* 6.1. [KeyEncryption](#KeyEncryption) -* 6.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) -* 7. [Envelope](#Envelope) -* 7.1. [Message](#Message) -* 7.2. [EnvelopeConnect](#EnvelopeConnect) -* 7.3. [EnvelopeGeneric](#EnvelopeGeneric) -* 7.4. [Pow](#Pow) -* 7.5. [Process](#Process-1) -* 7.6. [Peer](#Peer-1) + * 6.1. [KeyEncryption](#KeyEncryption) + * 6.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) +* 7. [7. Enveloppes](#Enveloppes) + * 7.1. [7.1. Enveloppe](#Enveloppe) + * 7.2. [7.2. EnveloppesConnect](#EnveloppesConnect) + * 7.3. [EnvelopeGeneric](#EnvelopeGeneric) + * 7.4. [Pow](#Pow) + * 7.5. [Process](#Process-1) + * 7.6. [Peer](#Peer-1) * 8. [Relay](#Relay) * 9. [L1Node](#L1Node) -* 9.1. [L1NodeMining](#L1NodeMining) -* 9.2. [L2Node](#L2Node) -* 9.3. [L2NodeMining](#L2NodeMining) -* 9.4. [L2Certif](#L2Certif) -* 9.5. [BlockCertif](#BlockCertif) + * 9.1. [L1NodeMining](#L1NodeMining) + * 9.2. [L2Node](#L2Node) + * 9.3. [L2NodeMining](#L2NodeMining) + * 9.4. [L2Certif](#L2Certif) + * 9.5. [BlockCertif](#BlockCertif) * 10. [Metadata](#Metadata) -* 10.1. [MetadataProcessublic](#MetadataProcessublic) -* 10.2. [MetadataPrivate](#MetadataPrivate) -* 10.3. [MetadataRoleConfidential](#MetadataRoleConfidential) -* 10.4. [Amount](#Amount) -* 10.5. [Number](#Number) + * 10.1. [MetadataProcessublic](#MetadataProcessublic) + * 10.2. [MetadataPrivate](#MetadataPrivate) + * 10.3. [MetadataRoleConfidential](#MetadataRoleConfidential) + * 10.4. [Amount](#Amount) + * 10.5. [Number](#Number) * 11. [Request](#Request) * 12. [Pcd](#Pcd) -* 12.1. [Pagination](#Pagination) -* 12.2. [PcdItemGenericEnc](#PcdItemGenericEnc) -* 12.2.1. [PcdItemEncAttributePublic](#PcdItemEncAttributePublic) -* 12.2.2. [PcdItemEncAttributeRoleConfidential](#PcdItemEncAttributeRoleConfidential) -* 12.2.3. [PcdItemEncAttributePrivate](#PcdItemEncAttributePrivate) + * 12.1. [Pagination](#Pagination) + * 12.2. [PcdItemGenericEnc](#PcdItemGenericEnc) + * 12.2.1. [PcdItemEncAttributePublic](#PcdItemEncAttributePublic) + * 12.2.2. [PcdItemEncAttributeRoleConfidential](#PcdItemEncAttributeRoleConfidential) + * 12.2.3. [PcdItemEncAttributePrivate](#PcdItemEncAttributePrivate) * 13. [Prd](#Prd) -* 13.1. [PrdList](#PrdList) -* 13.2. [PrdUpdate](#PrdUpdate) -* 13.3. [PrdResponse](#PrdResponse) -* 13.4. [PrdConfirm](#PrdConfirm) -* 13.5. [PrdMessage](#PrdMessage) -* 13.6. [PrdResponse](#PrdResponse-1) + * 13.1. [PrdList](#PrdList) + * 13.2. [PrdUpdate](#PrdUpdate) + * 13.3. [PrdResponse](#PrdResponse) + * 13.4. [PrdConfirm](#PrdConfirm) + * 13.5. [PrdMessage](#PrdMessage) + * 13.6. [PrdResponse](#PrdResponse-1) * 14. [Roles](#Roles) -* 14.1. [Role](#Role) -* 14.2. [Conditions](#Conditions) -* 14.2.1. [TransactionMode](#TransactionMode) -* 14.2.2. [ConditionPayments](#ConditionPayments) -* 14.2.3. [Conditioncommit](#Conditioncommit) -* 14.2.4. [ConditionDeposit](#ConditionDeposit) -* 14.2.5. [ConditionOrchestration](#ConditionOrchestration) -* 14.2.6. [ConditionCap](#ConditionCap) -* 14.2.7. [ConditionPrdAddressSet](#ConditionPrdAddressSet) -* 14.2.8. [ConditionPublish](#ConditionPublish) -* 14.3. [RolesGroup](#RolesGroup) -* 14.3.1. [RoleArtefact](#RoleArtefact) -* 14.3.2. [RoleDeposit](#RoleDeposit) -* 14.3.3. [Rolecommit](#Rolecommit) -* 14.3.4. [RoleMember](#RoleMember) -* 14.4. [RolePeer](#RolePeer) -* 14.4.1. [RolePayments](#RolePayments) -* 14.4.2. [RoleProcess](#RoleProcess) + * 14.1. [Role](#Role) + * 14.2. [Conditions](#Conditions) + * 14.2.1. [TransactionMode](#TransactionMode) + * 14.2.2. [ConditionPayments](#ConditionPayments) + * 14.2.3. [Conditioncommit](#Conditioncommit) + * 14.2.4. [ConditionDeposit](#ConditionDeposit) + * 14.2.5. [ConditionOrchestration](#ConditionOrchestration) + * 14.2.6. [ConditionCap](#ConditionCap) + * 14.2.7. [ConditionPrdAddressSet](#ConditionPrdAddressSet) + * 14.2.8. [ConditionPublish](#ConditionPublish) + * 14.3. [RolesGroup](#RolesGroup) + * 14.3.1. [RoleArtefact](#RoleArtefact) + * 14.3.2. [RoleDeposit](#RoleDeposit) + * 14.3.3. [Rolecommit](#Rolecommit) + * 14.3.4. [RoleMember](#RoleMember) + * 14.4. [RolePeer](#RolePeer) + * 14.4.1. [RolePayments](#RolePayments) + * 14.4.2. [RoleProcess](#RoleProcess) * 15. [Relay side chain data streaming](#Relaysidechaindatastreaming) -* 15.1. [Transaction](#Transaction) -* 15.2. [Bloc](#Bloc) + * 15.1. [Transaction](#Transaction) + * 15.2. [Bloc](#Bloc) * 16. [Storage](#Storage) -* 16.1. [StoragePublic](#StoragePublic) -* 16.1.1. [StorageKeysPublic](#StorageKeysPublic) -* 16.1.2. [StoragePeerPublic](#StoragePeerPublic) -* 16.1.3. [StorageProcessPublic](#StorageProcessPublic) -* 16.1.4. [StorageEnvelopePublic](#StorageEnvelopePublic) -* 16.1.5. [StoragePcdPublic](#StoragePcdPublic) -* 16.1.6. [StoragePrdPublic](#StoragePrdPublic) -* 16.2. [StoragePrivate](#StoragePrivate) -* 16.2.1. [StorageKeysPrivate](#StorageKeysPrivate) -* 16.2.2. [StoragePeerPrivate](#StoragePeerPrivate) -* 16.2.3. [StorageProcessPrivate](#StorageProcessPrivate) -* 16.2.4. [StoragePcdPrivate](#StoragePcdPrivate) -* 16.2.5. [StoragePrdPrivate](#StoragePrdPrivate) -* 16.2.6. [StorageDecryptedSharedSecretKeyPrivate](#StorageDecryptedSharedSecretKeyPrivate) -* 16.2.7. [StorageocketsPrivate](#StorageocketsPrivate) -* 16.2.8. [StorageSocketClientListPrivate](#StorageSocketClientListPrivate) + * 16.1. [StoragePublic](#StoragePublic) + * 16.1.1. [StorageKeysPublic](#StorageKeysPublic) + * 16.1.2. [StoragePeerPublic](#StoragePeerPublic) + * 16.1.3. [StorageProcessPublic](#StorageProcessPublic) + * 16.1.4. [StorageEnvelopePublic](#StorageEnvelopePublic) + * 16.1.5. [StoragePcdPublic](#StoragePcdPublic) + * 16.1.6. [StoragePrdPublic](#StoragePrdPublic) + * 16.2. [StoragePrivate](#StoragePrivate) + * 16.2.1. [StorageKeysPrivate](#StorageKeysPrivate) + * 16.2.2. [StoragePeerPrivate](#StoragePeerPrivate) + * 16.2.3. [StorageProcessPrivate](#StorageProcessPrivate) + * 16.2.4. [StoragePcdPrivate](#StoragePcdPrivate) + * 16.2.5. [StoragePrdPrivate](#StoragePrdPrivate) + * 16.2.6. [StorageDecryptedSharedSecretKeyPrivate](#StorageDecryptedSharedSecretKeyPrivate) + * 16.2.7. [StorageocketsPrivate](#StorageocketsPrivate) + * 16.2.8. [StorageSocketClientListPrivate](#StorageSocketClientListPrivate) * 17. [12. Rust considerations](#Rustconsiderations) -* 17.1. [General Implications for Project Objects](#GeneralImplicationsforProjectObjects) -* 17.2. [Debug](#Debug) -* 17.3. [Default](#Default) -* 17.4. [PartialEq, Eq](#PartialEqEq) -* 17.5. [Hash](#Hash) -* 17.6. [PartialOrd, Ord](#PartialOrdOrd) + * 17.1. [General Implications for Project Objects](#GeneralImplicationsforProjectObjects) + * 17.2. [Debug](#Debug) + * 17.3. [Default](#Default) + * 17.4. [PartialEq, Eq](#PartialEqEq) + * 17.5. [Hash](#Hash) + * 17.6. [PartialOrd, Ord](#PartialOrdOrd) * 18. [Todo](#Todo) * 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique) @@ -50,11 +50,11 @@ Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc) /vscode-markdown-toc-config --> -## 3. Documents de référence +## 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 4. Détails de conception +## 4. Détails de conception Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits. @@ -62,23 +62,23 @@ Tous les hash sont opérés avec l'algorithme SHA256. La librairie Rust `Nakamoto`, permet de scanner les blocs (et bientôt la mempool) côté client et de détecter des transactions Bitcoin correspondant aux clés publiques des clés cryptographiques privées du HD Wallet Bitcoin contenant les clés Bitcoin de mainnet et de signet. -## 5. Mot de passe +## 5. Mot de passe Utilisation du mot de passe strictement en mémoire. Mot de passe fort (18 caractères minimum avec minuscules, majuscules, lettre, nombres, et caractères spéciaux) ou mnémonique de 12 mots à noter ou certificat (ou équivalent) stocké de façon sécurisée. -## 6. Cache +## 6. Cache Stockage sécurisé du cache par un chiffrement par le mot de passe. -## 7. Chiffrement des communications +## 7. Chiffrement des communications Le chiffrement du transport des données se fait par TLS entre les clients et le noeuds entrants pour palier aux restrictions sur les flux non TLS par les navigateurs et les applications mobiles. Néanmoins tous les `Envelope` chiffrent les `Pcd` et `Prd` avec une clé de chiffrement conforme aux exigences suivantes et échangée dans le Diffie-Hellman de la transaction SP, en parallèle donc des flux `Pcd` et `Prd`.Ces clés ne sont accessibles donc qu'avec la clé privée du destinataire ou de l'émetteur, qui ne sont jamais partagées. -## 8. Confidentialité des `Pcd` et Prd +## 8. Confidentialité des `Pcd` et Prd Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes. @@ -92,7 +92,7 @@ Le chiffrement des `Pcd` est un chiffrement symétrique conformément aux exigen * **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs). -## 9. Confidentialité des `Envelope` sur les relais +## 9. Confidentialité des `Envelope` sur les relais Les `Pcd` et les `Prd` sont envoyés aux relais dans des enveloppes appelées `Envelope`. @@ -102,89 +102,89 @@ Tous les `Prd` sont confirmés par un et chiffrent les clés transamises par une Les relais peuvent déchiffrer les enveloppes avec la `ProcessKey`, le contenu étant chiffré en plus en fonction des niveaux de confidentialité. L'objectif du chiffrage des enveloppe est de donner, un temps, un coût et une complexité aux analyses systématiques des flux. -## 10. Clé de chiffrement robuste +## 10. Clé de chiffrement robuste La force d'un algorithme de chiffrement symétrique repose largement sur la complexité de sa clé. Une clé plus longue offre généralement une meilleure sécurité. Les tailles de clé typiques pour un chiffrement fort sont de 128 bits, 192 bits, ou 256 bits. Pour l'AES-GCM, les clés de 256 bits sont à ce stade réputées "quantum-resistant" et sont donc à privilégier, elles satisfont aussi les contraintes suivantes. -### 10.1. Résistance aux attaques cryptanalytiques +### 10.1. Résistance aux attaques cryptanalytiques Un algorithme fort doit résister à diverses attaques, y compris les attaques par force brute (où un attaquant essaie toutes les clés possibles), les attaques par texte clair connu, les attaques par texte clair choisi, les attaques par texte chiffré choisi, et plus encore. L'AES-GCM les clés de 256 bits n'est pas par design robuste à ces attaques, mais avec une clé suffisamment longue (de longueur quantique) le temps nécessaire est estimé comme équivalent à une résistance. -### 10.2. Diffusion et confusion +### 10.2. Diffusion et confusion Ces deux principes, introduits par Claude Shannon, sont essentiels à la sécurité d'un algorithme. La diffusion vise à disperser l'influence d'un seul caractère du texte clair sur de nombreux caractères du texte chiffré, tandis que la confusion vise à complexifier la relation entre la clé de chiffrement et le texte chiffré. -### 10.3. Non-linéarité +### 10.3. Non-linéarité L'algorithme doit incorporer des éléments non linéaires pour contrer les attaques linéaires et différentielles. Cela rend la prédiction du comportement de l'algorithme plus difficile pour un attaquant. -## 11. Fonctions de hashage +## 11. Fonctions de hashage Les fonctions de hachage jouent un rôle crucial dans de nombreux domaines de la cryptographie et de la sécurité informatique, notamment dans la vérification de l'intégrité des données, l'authentification, la signature numérique, et la génération de jetons sécurisés. Pour être efficaces et sécurisées, ces fonctions doivent répondre à plusieurs exigences essentielles : -## 12. Exigences génériques +## 12. Exigences génériques -### 12.1. Pas de secret de la conception +### 12.1. Pas de secret de la conception La sécurité d'un bon système cryptographique ne doit pas reposer sur le secret de son algorithme (principe de Kerckhoffs) et doit être basée sur des principes cryptographiques éprouvés. -### 12.2. Validé par la communauté scientifique +### 12.2. Validé par la communauté scientifique Un algorithme est considéré comme plus fort s'il a été soumis à l'examen et à l'analyse de la communauté cryptographique internationale, qui cherche des vulnérabilités potentielles. -### 12.3. Implémentation correcte +### 12.3. Implémentation correcte Une implémentation fautive d'un algorithme de chiffrement fort peut introduire des vulnérabilités. Il est crucial que l'implémentation soit vérifiée pour être sécurisée. La librairie utilisée doit avoir été l'objet d'un audit ([librairie aes-gcm de rust a été auditée](https://research.nccgroup.com/2020/02/26/public-report-rustcrypto-aes-gcm-and-chacha20poly1305-implementation-review/)). -### 12.4. Détermination +### 12.4. Détermination Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie. -### 12.5. Rapidité de calcul +### 12.5. Rapidité de calcul La fonction doit être capable de générer le hachage rapidement, même pour de grandes quantités de données. -### 12.6. Diffusion (ou effet avalanche) +### 12.6. Diffusion (ou effet avalanche) Un changement minime dans l'entrée (même un seul bit) doit entraîner un changement significatif et imprévisible dans la sortie. Cela garantit qu'il est difficile de prédire comment la sortie changera en fonction des modifications apportées à l'entrée. -### 12.7. Résistance aux collisions +### 12.7. Résistance aux collisions Il doit être pratiquement impossible de trouver deux entrées distinctes qui produisent la même sortie. Cela se décline en deux sous-catégories : -#### 12.7.1. Résistance aux collisions faibles +#### 12.7.1. Résistance aux collisions faibles Il est difficile de trouver une seconde entrée qui a le même hachage qu'une entrée spécifiée. -#### 12.7.2. Résistance aux collisions fortes +#### 12.7.2. Résistance aux collisions fortes Il est difficile de trouver deux entrées distinctes qui produisent le même hachage. -### 12.8. Résistance à la pre_id +### 12.8. Résistance à la pre_id Pour une sortie de hachage donnée, il doit être difficile de trouver une entrée qui correspond à cette sortie. Cela se décline également en deux sous-catégories : -#### 12.8.1. Résistance à la pre_id +#### 12.8.1. Résistance à la pre_id Il est difficile de trouver une entrée qui hache vers une sortie de hachage spécifiée. -#### 12.8.2. Résistance à la seconde pre_id +#### 12.8.2. Résistance à la seconde pre_id Étant donné une entrée, il est difficile de trouver une autre entrée qui produit le même hachage. -### 12.9. Compression +### 12.9. Compression La fonction de hachage doit pouvoir prendre une entrée de taille arbitraire et produire une sortie de taille fixe. -### 12.10. Non réversibilité +### 12.10. Non réversibilité Il doit être infaisable de retrouver l'entrée à partir de la sortie du hachage. Cela signifie que la fonction est à sens unique. -### 12.11. Absence de toute structure prévisible +### 12.11. Absence de toute structure prévisible La fonction de hachage ne doit pas produire des sorties qui montrent des patterns ou des structures prévisibles, quelles que soient les entrées. -## 13. Gestion sécurisée des clés +## 13. Gestion sécurisée des clés La manière dont les clés sont générées, stockées, distribuées, révoquées, et détruites est tout aussi importante que l'algorithme de chiffrement lui-même. @@ -194,24 +194,24 @@ Les parties sont pour la moitié stockées dans le contexte `User` (chiffrées p L'`User` seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé. -## 14. Performance +## 14. Performance Le temps de réponse doit être rapide pour les opérations de login. Ce temps sera estimé de façon empirique au fur et à mesure des implémentations. -## 15. Disponibilité +## 15. Disponibilité La haute disponibilité et la reprise après sinistre sont permises par la redondance des `relais` sans système central ou critique et robustes à la défaillance d'une partie des participants. C'est idem pour la redondance au sein des `Members` des gestionnaires des Members dans les `processus`, qui ont tous des actions égales et robustes à la défaillance d'une partie des participants. En cas de perte, vol, corruption, ou expiration des clés, l'`User` peut de son initiative et en toute autonomie révoquer un `User` et en générer une nouvelle. -## 16. Évolutivité +## 16. Évolutivité La capacité à gérer une augmentation du nombre d'``User`` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `Members`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les Members par `rôles` et par `Process` . -## 17. Autres Mesures de sécurité +## 17. Autres Mesures de sécurité Les mécanismes de défense contre les vulnérabilités courantes doivent être implémentés (CSRF, XSS). À noter, que les seules bases de données sont dans l'IndexedDB des navigateurs et applications mobiles, côté `User` et écrasées des données confirmées reçues du réseau et toutes vérifiables. Tous les autres composants et `User` ont un stockage en mémoire, non persisté (mais restauré à leur propre récupération de leur `User`). -## 18. Todo +## 18. Todo diff --git a/doc/_questions.txt b/doc/_questions.txt index f88182c..e69de29 100644 --- a/doc/_questions.txt +++ b/doc/_questions.txt @@ -1,21 +0,0 @@ -Questions PCD-PRD Specs: -1 - PrdResponse: -Réponse aux autres types de Prd (à l'exception de PrdConfirm, et PrdMessage). -ou -Répond à tous les autres types de Prd (à l'exception des PrdConfirm, PrdResponse eux-mêmes) - -=> Réponse aux autres types de Prd (à l'exception de PrdConfirm, et PrdMessage). - -2 - Expliquer les champs sur  Notification User (tableau)? - -=> C’est lorsque l’IHM doit recevoir un ev ent pour lui signaler soit l’envoi d’un Prd soit la réception - -3 -Info sur les Tx Sp : Toujours dans le PrdMessage? - -=> 2 utilisation : -- Un message => pas de Tx SP -- L’envoi une Tx Sp à relayer => toujours dans un PrdMessage (en plus de l’enveloppe ‘Message’ du Prd). Je comprend l’ambiguité :) je réfléchi à renomer « Message » en « Envelope» qu’en pensez vous ? - -4- Receive prdUpdate: column "PrdResponse reply waiting" (yes, other members) - -=> Lorsque l’on reçoit un PRDUpdate on va y répondre si on un gestionnaire concerné, mais on va aussi attendre toutes les réponses de tous les gestionnaires (qu’on soit gestionnaire ou pas) afin de valider ou non la nouvelle version du PCD associé.