diff --git a/doc/Auth-Specs.md b/doc/Auth-Specs.md index c415216..a54685e 100644 --- a/doc/Auth-Specs.md +++ b/doc/Auth-Specs.md @@ -3,8 +3,8 @@ * 2. [Portée](#Porte) * 3. [Documents de référence](#Documentsderfrence) * 4. [Schématisation des processus](#Schmatisationdesprocessus) - * 4.1. [4.1. Création d'une identité](#Crationduneidentit) - * 4.2. [4.2. Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover) + * 4.1. [Création d'une identité](#Crationduneidentit) + * 4.2. [Connexion avec une identité créée (`recover`)](#Connexionavecuneidentitcrerecover) * 5. [Authentification des utilisateurs](#Authentificationdesutilisateurs) * 6. [Connexion via des tiers](#Connexionviadestiers) * 7. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse) @@ -43,11 +43,15 @@ Voir [_Doc_references.md](_Doc_references.md). ## 4. Schématisation des processus -### 4.1. 4.1. Création d'une identité +### 4.1. Création d'une identité ![WalletCreate](diagrams/WalletCreate.png "WalletCreate") -### 4.2. 4.2. Connexion avec une identité créée (`recover`) +### Onboarding + +![WalletOnboard](diagrams/WalletOnboard.png "WalletOnboard") + +### 4.2. Connexion avec une identité créée (`recover`) ![WalletRecover](diagrams/WalletRecover.png "WalletRecover") @@ -166,15 +170,11 @@ Hash speudo code : pre_id=sha256(part1_spend_recover_enc, MDP) ``` -3. Création d'un `RequestPrdKeyBackup` par membre (1 shard par membre), par `RequestPrd` : +3. Création d'un `RequestPrdList` par membre (1 shard par membre), par `RequestPrd` : 3.1. Génération d'une clé de chiffrement dite `sp_shared_secret` qui sera transmise dans le Diffie-Hellman de la transaction SP. - 3.2. Définition de l'attribut `device_footprint_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`. - - 3.3. Définition de l'attribut `pre_id_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`. - - 3.4. Définition de l'attribut `shard_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`. + 3.2. Création d'un `ItemMember` à envoyer avec le `RequestPrdList`. 4. Création des messages de type `Message` correspondant aux RequestPrd, envoi des messages aux relais connectés. @@ -189,17 +189,17 @@ Dans l'ordre on réalise donc les opérations suivantes donc : #### 10.1.2. Backup de `Part2Enc` -Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant les membres du rôle `member` du `ItemProcess` choisi. +Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant l'`ItemProcess` choisi. -Chacun de ses membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `RequestPrdResponse` en réponse à un `RequestPrdKeyBackup`. +Chacun de des managers des membres sera responsable de d'associer un `shard` de `Part2Enc` à une `pre-id` et de revoyer des les shards dans un `RequestPrdResponse` en réponse au `RequestPrdList` envoyé. Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : -1. Création de `RequestPrdKeyBackup` à destination du membre -2. Création de `Message` du `RequestPrdKeyBackup` à destination du membre. -3. Envoi de la transaction SP du `Message` du `RequestPrdKeyBackup` à destination du membre. -4. Envoi du `Message` du `RequestPrdKeyBackup` à destination du membre. -5. Atttente de la réception des `RequestPrdResponse` en réponse aux `RequestPrdKeyBackup` (confirmations). +1. Création de `RequestPrdList` à destination du membre +2. Création de `Message` du `RequestPrdList` à destination du membre. +3. Envoi de la transaction SP du `Message` du `RequestList` à destination du membre. +4. Envoi du `Message` du `RequestPrdList` à destination du membre. +5. Atttente de la réception des `RequestPrdResponse` en réponse aux `RequestPrdList` (confirmations). 6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. 6.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `RequestPrdResponse` de chaque member du `Role` `Member`du `ItemProcess`. @@ -210,7 +210,7 @@ Dans l'ordre on réalise donc les opérations suivantes pour chaque membres : Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif. -L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `RequestPrdKeyBackup` 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). +L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `RequestPrdList` 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). ## 12. Clés de third parties @@ -222,17 +222,17 @@ Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de ## 13. Connexions avec une identité crée (`recover`) -Pour recrééer sa clé privée et envoyer un `RequestPrdKeyHello` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes : +Pour recrééer sa clé privée et envoyer un `RequestPrdList` à chaque membre du rôle `Member` du process, il faut réaliser les opérations suivantes : 1. Récupération de Part1Enc en cache 2. Création de la `pre_id` avec le mot de passe Puis depuis la liste des membres du process, pour chacun des membres : -1. Création de `RequestPrdKeyHello` à destination du membre 1. -2. Création de `Message` du `RequestPrdKeyHello` à destination du membre. -3. Envoi de la transaction SP du `Message` du `RequestPrdKeyHello` à destination du membre. -4. Envoi du `Message` du `RequestPrdKeyHello` à destination du membre. +1. Création de `RequestPrdList` à destination du membre 1. +2. Création de `Message` du `RequestPrdList` à destination du membre. +3. Envoi de la transaction SP du `Message` du `RequestPrdList` à destination du membre avec la `pre_id`. +4. Envoi du `Message` du `RequestPrdList` à destination du membre. 5. Attente de la validation (`RequestPrdResponse`) du `RequestPrdUpdate`. 6. Recomposition de la clé pour confirmation depuis les shards reçus dans les `RequestPrdResponse`. 6.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache. diff --git a/doc/Data-Specs.md b/doc/Data-Specs.md new file mode 100644 index 0000000..fbaf414 --- /dev/null +++ b/doc/Data-Specs.md @@ -0,0 +1,66 @@ + +* 1. [Objectif](#Objectif) +* 2. [Portée](#Porte) +* 3. [3. Documents de référence](#Documentsderfrence) +* 4. [Data publique](#Datapublique) + * 4.1. [Clés](#Cls) + * 4.2. [Peers](#Peers) + * 4.3. [Process](#Process) + * 4.4. [Messages](#Messages) + * 4.5. [RequestPrd](#RequestPrd) + * 4.6. [RequestPcd](#RequestPcd) +* 5. [Data privée](#Dataprive) + * 5.1. [Clés](#Cls-1) + * 5.2. [Peers](#Peers-1) + * 5.3. [Process](#Process-1) + * 5.4. [Messages](#Messages-1) + * 5.5. [RequestPrd](#RequestPrd-1) + * 5.6. [RequestPcd](#RequestPcd-1) + + + +## 1. Objectif + +## 2. Portée + +## 3. 3. Documents de référence + +Voir [_Doc_references.md](_Doc_references.md). + +## 4. Data publique + +### 4.1. Clés + +1. ImageRecover + 1.1 KeyRecoverSpend + 1.2 KeyRecoverScan +2. ImageRevoke + 2.1 KeyRevokeSpend + 2.2 KeyRevokeScan + +### 4.2. Peers + +### 4.3. Process + +### 4.4. Messages + +### 4.5. RequestPrd + +### 4.6. RequestPcd + +## 5. Data privée + +### 5.1. Clés + +### 5.2. Peers + +### 5.3. Process + +### 5.4. Messages + +### 5.5. RequestPrd + +### 5.6. RequestPcd diff --git a/doc/Messages-Specs.md b/doc/Messages-Specs.md index ac934ff..548f8e7 100644 --- a/doc/Messages-Specs.md +++ b/doc/Messages-Specs.md @@ -195,14 +195,9 @@ Pour les `RequestPrd` de type `RequestPrdConfirm` : * `code_confirm_enc_by_shared_secret` -Pour les `RequestPrd` de type `RequestPrdKeyBackup` : - -* `device_footprint_enc_by_sp_shared_secret` -* `pre_id_enc_by_sp_shared_secret` -* `shard_enc_by_sp_shared_secret` - -Pour les `RequestPrd` de type `RequestPrdKeyHello` : +Pour les `RequestPrd` de type `RequestPrdList` : +* `item_member_enc_by_sp_shared_secret` * `pre_id_enc_by_sp_shared_secret` Puis le `RequestPrd` est chiffré par la `ProcessKey` du `ItemProcess`. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`. diff --git a/doc/PRD-PCD-Specs.md b/doc/PRD-PCD-Specs.md index 33e2638..b6bbcb8 100644 --- a/doc/PRD-PCD-Specs.md +++ b/doc/PRD-PCD-Specs.md @@ -34,16 +34,8 @@ * 11.1. [Schéma des flux](#Schmadesflux-1) * 11.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) * 11.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 12. [RequestPrdKeyBakcup](#RequestPrdKeyBakcup) - * 12.1. [Schéma des flux](#Schmadesflux-1) - * 12.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 12.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 13. [RequestPrdKeyHello - Échange de Clés et d'Identités](#RequestPrdKeyHello-changedeClsetdIdentits) - * 13.1. [Schéma des flux](#Schmadesflux-1) - * 13.2. [Création : Datas spécifiques](#Cration:Datasspcifiques-1) - * 13.3. [Réception : Datas spécifiques](#Rception:Datasspcifiques-1) -* 14. [Exemples de Code](#ExemplesdeCode) -* 15. [Todo](#Todo) +* 12. [Exemples de Code](#ExemplesdeCode) +* 13. [Todo](#Todo) # `RequestPrd` et `RequestPcd` - Specs -## 1. Objectif +## 1. Objectif Le but de cette section est d'introduire les Portable Contract Document (`RequestPcd`) et Portable Request Document (`RequestPrd`) 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 identités numériques 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. -## 2. Portée +## 2. Portée La spécification couvre la conception, le développement, et l'application pratique des `RequestPcd` et `RequestPrd`.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 `RequestPcd` et `RequestPrd` 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. -## 3. 3. Documents de référence +## 3. 3. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 4. Commun aux `RequestPcd` et RequestPrd +## 4. Commun aux `RequestPcd` et RequestPrd -### 4.1. Création et envoi +### 4.1. Création et envoi Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais. @@ -73,7 +65,7 @@ Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l **Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md). -### 4.2. Réception +### 4.2. Réception Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais. @@ -91,17 +83,17 @@ En cas de `RequestPcd` ou `RequestPrd` en relation via `RequestPcd_reference_has Pour les `RequestPcd` et les `RequestPrd` il faut vérifier que le hash du document n'est pas déjà en cas, si c'est le cas, le message est ignoré. -## 5. Fonction des RequestPcd +## 5. Fonction des RequestPcd Les Portable Contract Documents ( RequestPcd) sont des documents JSON qui encapsulent les listes versionnées d'`Item` dont les attributs sont chiffrés soit en public, soit en confidentiel par rôles soit en privé (cf. [Specs-Security.md](Specs-Security.md)). Les `Item` ainsi échangés via les `RequestPcd` sont vérifiés par les `RequestPrdResponse` afin de vérifier les validations de ces données et leurs conformités avec les `ItemProcess` et les `members` concernés. -### 5.1. Schéma des flux +### 5.1. Schéma des flux ![RequestPcd](diagrams/PCD.png "RequestPcd") -### 5.2. Création et envoi +### 5.2. Création et envoi La création d'un `RequestPcd` suit plusieurs étapes : @@ -111,17 +103,7 @@ La création d'un `RequestPcd` suit plusieurs étapes : 4. Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `ItemProcess` concerné. 5. Traitements communs aux `RequestPcd` et RequestPrd -| `request_type` | Notification user | `transaction SP` + `RequestPrdMessage` | `RequestPcd` to send | `request_type` send to | `RequestPcd` reply waiting | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting | -|-----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------| -| `RequestPrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes | -| `RequestPrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `ItemProcess` | No | Yes | Yes | -| `RequestPrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `ItemProcess` | No | No | if no `raw_transaction_list` | -| `RequestPrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | -| `RequestPrdConfirm` | (option) Waiting `code_confirm_enc_by_shared_secret` | Yes | No | See Received | No | No | No | -| `RequestPrdKeyBackup` | No | No | No | all the members of the `SharedProcess` | No | Yes | No | -| `RequestPrdKeyHello` | No | No | No | all the members of all `Role` into to `ItemProcess` | Yes | Yes | Yes | - -### 5.3. Réception +### 5.3. Réception La réception d'un `RequestPcd` suit plusieurs étapes : @@ -132,17 +114,7 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 5. Déchiffrage des attributs privés des `Item` des `RequestPcd` avec la clé privée `KeyRecover` 6. Mise à jour du cache pour les traitement des RequestPrd. -| `request_type` | Notification user | `RequestPrdConfirm` to send | `RequestPcd` to send | `RequestPrdResponse` to send | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting (from `RequestPrdResponse` send ) | -|-----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------| -| `RequestPrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | -| `RequestPrdUpdate` | Info | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | Yes | -| `RequestPrdMessage` | Waiting `RequestPrdMessage` reply | if no `raw_transaction_list` | No | No | No | No | -| `RequestPrdResponse` | Info | Yes | No | No | No | No | -| `RequestPrdConfirm` | Info | No | No | No | No | No | -| `RequestPrdKeyBackup` | Info | No | No | reply | No | No | -| `RequestPrdKeyHello` | No | Yes | Yes | reply | No | Yes | - -## 6. Fonction des RequestPrd +## 6. Fonction des RequestPrd Les Portable Request Documents ( RequestPrd) sont des documents JSON qui encapsulent les valeurs de signatures et les clés de déchiffrement nécessaires à l'interprétation des `RequestPcd` via l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`. Ils sont utilisés pour demander des actions spécifiques, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. @@ -150,13 +122,13 @@ Les clés de chiffrement des attributs confidentiels par rôles des `Item` des ` Les `RequestPrd` sont de plusieurs types tels que `RequestPrdList`, `RequestPrdMessage`, `RequestPrdUpdate`, etc.: Variations de `RequestPrd` pour différentes actions, telles que l'envoi de messages, la mise à jour des informations contractuelles, ou la confirmation de transactions. -### 6.1. Schéma des flux +### 6.1. Schéma des flux Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma. ![RequestPrd](diagrams/PRD.png "RequestPrd") -### 6.2. Fonctionnalités optionnelles +### 6.2. Fonctionnalités optionnelles L'attribut `sig_value` permet de donner une valeur aux signatures. Les valeurs des signatures sont définies par rôles dans les `ItemProcess` avec des valeurs valant pour `OK` ou `KO` pour `none` pour les validations des `RequestPrd`. @@ -181,7 +153,7 @@ Les adresses et les roles sont précisés en cas d'utilisateurs ayant plusieurs Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoyée de façon confidentielle via `device_footprint_enc_by_shared_secret`. -### 6.3. Création et envoi +### 6.3. Création et envoi La création d'un `RequestPrd` suit plusieurs étapes : @@ -198,7 +170,16 @@ La création d'un `RequestPrd` suit plusieurs étapes : Voir [Silent-Payment-Specs.md](Silent-Payment-Specs.md). -### 6.4. Réception + +| `request_type` | Notification user | `transaction SP` + `RequestPrdMessage` | `RequestPcd` to send | `request_type` send to | `RequestPcd` reply waiting | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting | +|----------------------|-----------------------------------------------------------------------------------|----------------------------------------|----------------------|-----------------------------------------------------------------|----------------------------|------------------------------------|-----------------------------------| +| `RequestPrdList` | No | Yes | No | all the members of the `item_name` `Role` into to `ItemProcess` | Yes | Yes | Yes | +| `RequestPrdUpdate` | waiting `sig_value` | Yes | Yes | all the members of all `Role` into to `ItemProcess` | No | Yes | Yes | +| `RequestPrdMessage` | waiting `sig_value` + `message_public`, `message_confidential`, `message_private` | if no `raw_transaction_list` | No | a member of the `ItemProcess` | No | No | if no `raw_transaction_list` | +| `RequestPrdResponse` | waiting `sig_value` | Yes | No | See Received | No | No | Yes | +| `RequestPrdConfirm` | (option) Waiting `code_confirm_enc_by_shared_secret` | Yes | No | See Received | No | No | No | + +### 6.4. Réception La réception d'un `RequestPcd` suit plusieurs étapes : @@ -214,29 +195,40 @@ La réception d'un `RequestPcd` suit plusieurs étapes : 10. Validation des conditions définies dans le `ItemProcess` pour ce d'`Item` avec le `Role` correspondant dans le `ItemProcess` et dans ce rôles les conditions pour ce type de `RequestPrd` (dans l'attribut `request_prd_type`) telles que définies dans [Specs-Process-Roles-Specs.md](Specs-Process-Roles-Specs.md). 11. Traitements spécifiques au type de RequestPrd. -## 7. RequestPrdList - Demande de Listes ( RequestPcd) +| `request_type` | Notification user | `RequestPrdConfirm` to send | `RequestPcd` to send | `RequestPrdResponse` to send | `RequestPrdResponse` reply waiting | `RequestPrdConfirm` reply waiting (from `RequestPrdResponse` send ) | +|----------------------|-----------------------------------|------------------------------|----------------------|-----------------------------------------------------------------|------------------------------------|---------------------------------------------------------------------| +| `RequestPrdList` | No | Yes | Yes | all the members of the `item_name` `Role` into to `ItemProcess` | No | Yes | +| `RequestPrdUpdate` | Info | Yes | No | all the members of all `Role` into to `ItemProcess` | Yes (other members) | Yes | +| `RequestPrdMessage` | Waiting `RequestPrdMessage` reply | if no `raw_transaction_list` | No | No | No | No | +| `RequestPrdResponse` | Info | Yes | No | No | No | No | +| `RequestPrdConfirm` | Info | No | No | No | No | No | + +## 7. RequestPrdList - Demande de Listes ( RequestPcd) Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le résweau. Chaque `RequestPcd` liste des `Item` d'un même type, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc. -### 7.1. Schéma des flux +### 7.1. Schéma des flux Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma. ![RequestPrdList](diagrams/PRDList.png "RequestPrdList") -### 7.2. Création : Datas spécifiques +### 7.2. Création : Datas spécifiques 1. Traitements des `RequestPrd`, avec le `type_request` -2. Pas de data spécifiques. +2. `item_member_enc_by_sp_shared_secret` en cas de création d'un nouveau ItemMember (création d'un identité numérique), uniquement vers les gestionnaires des membres +3. `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement ver les gestionnaires des membres -### 7.3. Réception : Datas spécifiques +### 7.3. Réception : Datas spécifiques La réception d'un `RequestPrdList` suit plusieurs étapes : 1. Traitements des `RequestPrd` 2. Recherche en cache de la dernière version de la liste du type d'`Item` concerné (voir `RequestPcd` Création et envoi vers l'émetteur du `RequestPrdList`) +3. Si `item_member_enc_by_sp_shared_secret` en cas de création d'un nouveau ItemMember (création d'un identité numérique), uniquement vers les gestionnaires des membres et ajout en cache sans modifier la liste des membres et associé au `pre_id` contenu dans l'`ItemMember` créé. +4. Si `pre_id_sp_enc_by_shared_secret` en cas de connexion avec une identité numérique existante, uniquement ver les gestionnaires des membres pour renvoi du shard correspondant dans le `RequestPrdResponse` -## 8. RequestPrdMessage - Envoi de Messages +## 8. RequestPrdMessage - Envoi de Messages Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats. @@ -247,23 +239,23 @@ Permet la communication : Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi de `raw_transaction_list` (cas d'utilisation du afin de transaférer la `transaction SP` d'un autre `RequestPrd`). -### 8.1. Schéma des flux +### 8.1. Schéma des flux Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma. Cas d'un RequestPrdMesage avec `raw_transaction_list` vide (et son RequestPrdMessage avec `raw_transaction_list` non vide). ![RequestPrdMessage](diagrams/PRDMessage.png "RequestPrdMessage") -### 8.2. Création : Datas spécifiques +### 8.2. Création : Datas spécifiques 1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` 2. Cas de la transmission d'une `Transaction SP` d'un autre vRequestPrd` au format `raw` dans l'attribut `raw_transaction_list` pour la publication de la transaction dans la side chain. -### 8.3. Réception : Datas spécifiques +### 8.3. Réception : Datas spécifiques 1. Traitements des `RequestPrd` -## 9. RequestPrdUpdate - Mises à Jour de RequestPcd +## 9. RequestPrdUpdate - Mises à Jour de RequestPcd `RequestPrdUpdate` est conçu pour demander des mises à jour des listes via des nouvelles versions de `RequestPcd`. @@ -275,25 +267,25 @@ Par exemple, mettre à jour la liste des membres permet d'ajouter de nouveaux ut Les `RequestPrdUpdate` signalent au réseau via l'attribut `RequestPcd_new_version_hash` les nouvelles version des RequestPcd. -### 9.1. Schéma des flux +### 9.1. Schéma des flux Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma. ![RequestPrdUpdate](diagrams/PRDUpdate.png "RequestPrdUpdate") -### 9.2. Création : Datas spécifiques +### 9.2. Création : Datas spécifiques 1. Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdUpdate` 2. Pas de data spécifiques. -### 9.3. Réception : Datas spécifiques +### 9.3. Réception : Datas spécifiques La réception d'un `RequestPrdUpdate` suit plusieurs étapes : 1. Traitements des `RequestPrd` 2. Comparaison de la dernirère version du `RequestPcd` en cache et de nouvelle version du `RequestPcd` associé via `RequestPcd_new_version_hash` et attente si nécessaire. -## 10. RequestPrdConfirm - Confirmation de Réception +## 10. RequestPrdConfirm - Confirmation de Réception Le `RequestPrdConfirm` 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. @@ -301,95 +293,51 @@ Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdRespon `code_confirm_enc_by_shared_secret`: Un code de confirmation chiffré qui valide l'authenticité et l'intégrité de la réponse, assurant que la confirmation est sécurisée et provient de la source attendue. Dans ce cas un output spécifique chiffré par la clé `KeyConfidential` précise ce code, à confirmer dans le RequestPrdConfirm. -### 10.1. Schéma des flux +### 10.1. Schéma des flux ![RequestPrdConfirm](diagrams/PRDConfirm.png "RequestPrdConfirm") -### 10.2. Création : Datas spécifiques +### 10.2. Création : Datas spécifiques 1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdConfirm` 2. Communication éventuelle d'un `code_confirm_enc_by_shared_secret` à confirmer dans le `RequestPrdConfirm`. -### 10.3. Réception : Datas spécifiques +### 10.3. Réception : Datas spécifiques 1. Traitements des `RequestPrd`, pas de traitement suppplémentaire. 2. Vérification du `code_confirm_enc_by_shared_secret` dans le `RequestPrdConfirm` reçu. -## 11. RequestPrdResponse - Répondre à une Demande +## 11. RequestPrdResponse - Répondre à une Demande Le `RequestPrdResponse` permet de répondre spécifiquement à des `RequestPrd` reçus, facilitant un échange interactif d'informations ou de décisions entre les parties. -Les `RequestPrdResponse` répondent aux `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdKeyBackup` et `RequestPrdKeyHello`. +Les `RequestPrdResponse` répondent aux `RequestPrdList`, `RequestPrdUpdate`. Utilisé pour fournir des feedbacks, des confirmations, ou des instructions supplémentaires en réponse à des demandes initiales, supportant une communication bidirectionnelle sécurisée et vérifiable. Aussi le moyen de demander des moyens de paiement ou de dépot ou de preuve, puis de partager le payload de ces actions. -### 11.1. Schéma des flux +### 11.1. Schéma des flux Pour simplifier les RequestPrdConfirm n'ont pas été représentés dans le schéma. ![RequestPrdResponse](diagrams/PRDResponse.png "RequestPrdResponse") -### 11.2. Création : Datas spécifiques +### 11.2. Création : Datas spécifiques 1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdResponse` 2. Attente de la valeur de la signature de l'utilisateur `sig_value` (si non automatique) -3. En cas de réponse à `RequestPrdKeyBackup` :`pre_id_enc_by_sp_shared_secret` avec les shards correspondants à la `pre-id` demandée. +3. En cas de réponse à `RequestPrdKeyList` :`pre_id_enc_by_sp_shared_secret` avec les shards correspondants à la `pre-id` demandée. 4. (option) `shared_secret_key` paratage d'une clé de chiffrement ad'hoc -### 11.3. Réception : Datas spécifiques +### 11.3. Réception : Datas spécifiques 1. Traitements des `RequestPrd` 2. Vérification des conditions de validation des RequestPcd associés. -3. En cas de réponse reçue à `RequestPrdKeyBackup` : Récupération des shards correspondants à la `pre-id` demandée et génération de la clé `KeyRecover` +3. En cas de réponse reçue à `RequestPrdList` : Récupération des shards correspondants à la `pre-id` demandée et génération de la clé `KeyRecover` -## 12. RequestPrdKeyBakcup +## 12. Exemples de Code -Le RequestPrdKeyHelloBakcup permet de demander la stockage de nouveaux shards associés à une `pre-id` . - -### 12.1. Schéma des flux - -![RequestPrdKeyBakcup](diagrams/PRDKeyBakcup.png "RequestPrdKeyBakcup") - -### 12.2. Création : Datas spécifiques - -1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyBakcup` -2. Voir [Auth-Specs.md](Auth-Specs.md) pour la création des shards et de la pre_id - 2.1. Mise à jour de `pre_id_enc_by_sp_shared_secret` - 2.2. Mise à jour de `shard_enc_by_sp_shared_secret` - -### 12.3. Réception : Datas spécifiques - -1. Traitements des `RequestPrd` -2. Voir [Auth-Specs.md](Auth-Specs.md) - 2.1. Si `pre_id_enc_by_sp_shared_secret` n'existe pas encore : enregistrement en cache du shard et de la `pre_id`. - 2.2. Si `pre_id_enc_by_sp_shared_secret` existe déjà : vérification de la transaction SP qui doit venir de l'adresse SP de recovery du membre, et donc mise jour du shard et de la `pre_id`. - -## 13. RequestPrdKeyHello - Échange de Clés et d'Identités - -RequestPrdKeyHello est conçu pour initier ou répondre à des demandes d'échange de clés ou d'informations d'identité, essentiel pour la gestion sécurisée des accès et des identités au sein du réseau. - -Important pour les processus d'onboarding de nouveaux membres, de réinitialisation des accès, ou de renouvellement des clés, facilitant une intégration sécurisée et la mise à jour des identités dans le réseau. - -### 13.1. Schéma des flux - -![RequestPrdKeyHello](diagrams/PRDKeyHello.png "RequestPrdKeyHello") - -### 13.2. Création : Datas spécifiques - -1. Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKeyHello` -2. Voir [Auth-Specs.md](Auth-Specs.md) pour ma mise à jour de `pre_id_enc_by_sp_shared_secret` - -### 13.3. Réception : Datas spécifiques - -1. Traitements des `RequestPrd` -2. Voir [Auth-Specs.md](Auth-Specs.md) - 1. Renvoi des shards dans le champs le `shard_enc_by_sp_shared_secret` du `RequestPrdResponse` à envoyer - 2. Envoi des `RequestPcd` relatif au `Role` de l'utilisateur dans le `ItemProcess` et des `RequestPcd` avec l`item_name` égal à "process" en cache - -## 14. Exemples de Code - -## 15. Todo +## 13. Todo * [ ] Diagrammes de séquences diff --git a/doc/Silent-Payment-Specs.md b/doc/Silent-Payment-Specs.md index 2d8c017..ed68848 100644 --- a/doc/Silent-Payment-Specs.md +++ b/doc/Silent-Payment-Specs.md @@ -25,7 +25,7 @@ Voir [_Doc_references.md](_Doc_references.md). La transaction SP à plusieurs objectifs : -1. Permettre l'horodatage de l'empreinte des `RequestPrd` sur la side chain (hors `RequestPrdKeyBackup` et les `RequestPrdKeyMessage` sans message confidentiel). +1. Permettre l'horodatage de l'empreinte des `RequestPrd` sur la side chain (`RequestPrdKeyMessage` sans message confidentiel). 2. Permettre le partage de la `keyConfidential` pour les `RequestPrd` afin de déchiffrer les données confidentielles, sur d'autres relais que ceux qui ont reçu le `RequestPrd`. La clé `KeyConfidential` d'une`transaction SP` est utilisée pour chiffrer les `RequestPrd`.Cette clé est échangée avec le destinataire via un Diffie-Hellman (cf. [Specs-Security.md](Specs-Security.md)) dans la transaction. diff --git a/doc/Specs-Datamodel.md b/doc/Specs-Datamodel.md index 87cff3b..9701ecf 100644 --- a/doc/Specs-Datamodel.md +++ b/doc/Specs-Datamodel.md @@ -5,92 +5,93 @@ * 2.2. [CommitmentMethod](#CommitmentMethod) * 2.3. [PaymentMethod](#PaymentMethod) * 3. [Items](#Items) - * 3.1. [ItemArtefact](#ItemArtefact) - * 3.2. [ItemCommitmentPublicAttributeGroup](#ItemCommitmentPublicAttributeGroup) - * 3.3. [ItemMemberPublicAttributeGroup](#ItemMemberPublicAttributeGroup) - * 3.4. [ItemDepositPublicAttributeGroup](#ItemDepositPublicAttributeGroup) - * 3.5. [ItemCommitmentRoleConfidentialAttributeGroup](#ItemCommitmentRoleConfidentialAttributeGroup) - * 3.6. [ItemCommitmentPrivateAttributeGroup](#ItemCommitmentPrivateAttributeGroup) - * 3.7. [ItemCommitment](#ItemCommitment) - * 3.8. [ItemDepositRoleConfidentialAttributeGroup](#ItemDepositRoleConfidentialAttributeGroup) - * 3.9. [ItemDepositPrivateAttributeGroup](#ItemDepositPrivateAttributeGroup) - * 3.10. [ItemDeposit](#ItemDeposit) - * 3.11. [ItemEnum](#ItemEnum) - * 3.12. [ItemPaymentPublicAttributeGroup](#ItemPaymentPublicAttributeGroup) - * 3.13. [ItemPaymentRoleConfidentialAttributeGroup](#ItemPaymentRoleConfidentialAttributeGroup) - * 3.14. [ItemPaymentPrivateAttributeGroup](#ItemPaymentPrivateAttributeGroup) - * 3.15. [ItemPayment](#ItemPayment) - * 3.16. [ItemPeerPublicAttributeGroup](#ItemPeerPublicAttributeGroup) - * 3.17. [ItemPeerPrivateAttributeGroup](#ItemPeerPrivateAttributeGroup) - * 3.18. [ItemPeer](#ItemPeer) - * 3.19. [ItemProcess](#ItemProcess) - * 3.20. [ItemProcessPublicAttributeGroup](#ItemProcessPublicAttributeGroup) - * 3.21. [Item](#Item) -* 4. [Encryption](#Encryption) - * 4.1. [KeyEncryption](#KeyEncryption) - * 4.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) -* 5. [Messages](#Messages) - * 5.1. [Message](#Message) - * 5.2. [MessageConnect](#MessageConnect) - * 5.3. [MessageGeneric](#MessageGeneric) - * 5.4. [Pow](#Pow) - * 5.5. [SharedProcess](#SharedProcess) - * 5.6. [SharedPeer](#SharedPeer) -* 6. [Relay](#Relay) - * 6.1. [L1Node](#L1Node) - * 6.2. [L1Miner](#L1Miner) - * 6.3. [L2Node](#L2Node) - * 6.4. [L2Certif](#L2Certif) -* 7. [Metadata](#Metadata) - * 7.1. [MetadataContractPublic](#MetadataContractPublic) - * 7.2. [MetadataPrivate](#MetadataPrivate) - * 7.3. [MetadataRoleConfidential](#MetadataRoleConfidential) - * 7.4. [Amount](#Amount) - * 7.5. [Number](#Number) -* 8. [Request](#Request) -* 9. [RequestPcd](#RequestPcd) - * 9.1. [Pagination](#Pagination) - * 9.2. [RequestPcdItemEncAttributePublic](#RequestPcdItemEncAttributePublic) - * 9.3. [RequestPcdItemEncAttributeRoleConfidential](#RequestPcdItemEncAttributeRoleConfidential) - * 9.4. [RequestPcdItemEncAttributePrivate](#RequestPcdItemEncAttributePrivate) - * 9.5. [RequestPcdItemGenericEnc](#RequestPcdItemGenericEnc) - * 9.6. [RequestPcdItemEnc](#RequestPcdItemEnc) -* 10. [RequestPrd](#RequestPrd) - * 10.1. [RequestPrdResponse](#RequestPrdResponse) - * 10.2. [RequestPrdConfirm](#RequestPrdConfirm) - * 10.3. [RequestPrdKeyBackup](#RequestPrdKeyBackup) - * 10.4. [RequestPrdKeyHello](#RequestPrdKeyHello) - * 10.5. [RequestPrdList](#RequestPrdList) - * 10.6. [RequestPrdMessage](#RequestPrdMessage) - * 10.7. [RequestPrdResponse](#RequestPrdResponse-1) - * 10.8. [RequestPrdUpdate](#RequestPrdUpdate) -* 11. [Roles](#Roles) - * 11.1. [Role](#Role) - * 11.2. [Conditions](#Conditions) - * 11.2.1. [TransactionMode](#TransactionMode) - * 11.2.2. [ConditionPayment](#ConditionPayment) - * 11.2.3. [ConditionCommitment](#ConditionCommitment) - * 11.2.4. [ConditionDeposit](#ConditionDeposit) - * 11.2.5. [ConditionOrchestration](#ConditionOrchestration) - * 11.2.6. [ConditionCap](#ConditionCap) - * 11.2.7. [Condition RequestPrdAddressSet](#ConditionRequestPrdAddressSet) - * 11.2.8. [ConditionPublish](#ConditionPublish) - * 11.3. [RolesGroup](#RolesGroup) - * 11.3.1. [RoleArtefact](#RoleArtefact) - * 11.3.2. [RoleDeposit](#RoleDeposit) - * 11.3.3. [RoleCommitment](#RoleCommitment) - * 11.3.4. [RoleMember](#RoleMember) - * 11.4. [RolePeer](#RolePeer) - * 11.4.1. [RolePayment](#RolePayment) - * 11.4.2. [RoleProcess](#RoleProcess) -* 12. [12. Rust considerations](#Rustconsiderations) - * 12.1. [General Implications for Project Objects](#GeneralImplicationsforProjectObjects) - * 12.2. [Debug](#Debug) - * 12.3. [Default](#Default) - * 12.4. [PartialEq, Eq](#PartialEqEq) - * 12.5. [Hash](#Hash) - * 12.6. [PartialOrd, Ord](#PartialOrdOrd) -* 13. [Todo](#Todo) + * 3.1. [Item](#Item) + * 3.2. [ItemArtefact](#ItemArtefact) + * 3.3. [ItemMember](#ItemMember) + * 3.3.1. [ItemMemberPublicAttributeGroup](#ItemMemberPublicAttributeGroup) + * 3.3.2. [ItemMemberRoleConfidentialAttributeGroup](#ItemMemberRoleConfidentialAttributeGroup) + * 3.3.3. [ItemMemberRolePrivateAttributeGroup](#ItemMemberRolePrivateAttributeGroup) +* 4. [ItemCommitment](#ItemCommitment) + * 4.1. [ItemCommitmentRoleConfidentialAttributeGroup](#ItemCommitmentRoleConfidentialAttributeGroup) + * 4.2. [ItemCommitmentPrivateAttributeGroup](#ItemCommitmentPrivateAttributeGroup) + * 4.2.1. [ItemCommitmentPublicAttributeGroup](#ItemCommitmentPublicAttributeGroup) + * 4.3. [ItemDeposit](#ItemDeposit) + * 4.3.1. [ItemDepositPublicAttributeGroup](#ItemDepositPublicAttributeGroup) + * 4.3.2. [ItemDepositRoleConfidentialAttributeGroup](#ItemDepositRoleConfidentialAttributeGroup) + * 4.3.3. [ItemDepositPrivateAttributeGroup](#ItemDepositPrivateAttributeGroup) + * 4.4. [ItemEnum](#ItemEnum) + * 4.5. [ItemPayment](#ItemPayment) + * 4.5.1. [ItemPaymentPublicAttributeGroup](#ItemPaymentPublicAttributeGroup) + * 4.5.2. [ItemPaymentRoleConfidentialAttributeGroup](#ItemPaymentRoleConfidentialAttributeGroup) + * 4.5.3. [ItemPaymentPrivateAttributeGroup](#ItemPaymentPrivateAttributeGroup) + * 4.6. [ItemPeer](#ItemPeer) + * 4.6.1. [ItemPeerPublicAttributeGroup](#ItemPeerPublicAttributeGroup) + * 4.6.2. [ItemPeerPrivateAttributeGroup](#ItemPeerPrivateAttributeGroup) + * 4.7. [ItemProcess](#ItemProcess) + * 4.7.1. [ItemProcessPublicAttributeGroup](#ItemProcessPublicAttributeGroup) +* 5. [Encryption](#Encryption) + * 5.1. [KeyEncryption](#KeyEncryption) + * 5.2. [Aes256GcmIv96Bit](#Aes256GcmIv96Bit) +* 6. [Messages](#Messages) + * 6.1. [Message](#Message) + * 6.2. [MessageConnect](#MessageConnect) + * 6.3. [MessageGeneric](#MessageGeneric) + * 6.4. [Pow](#Pow) + * 6.5. [SharedProcess](#SharedProcess) + * 6.6. [SharedPeer](#SharedPeer) +* 7. [Relay](#Relay) + * 7.1. [L1Node](#L1Node) + * 7.2. [L1Miner](#L1Miner) + * 7.3. [L2Node](#L2Node) + * 7.4. [L2Certif](#L2Certif) +* 8. [Metadata](#Metadata) + * 8.1. [MetadataContractPublic](#MetadataContractPublic) + * 8.2. [MetadataPrivate](#MetadataPrivate) + * 8.3. [MetadataRoleConfidential](#MetadataRoleConfidential) + * 8.4. [Amount](#Amount) + * 8.5. [Number](#Number) +* 9. [Request](#Request) +* 10. [RequestPcd](#RequestPcd) + * 10.1. [Pagination](#Pagination) + * 10.2. [RequestPcdItemEncAttributePublic](#RequestPcdItemEncAttributePublic) + * 10.3. [RequestPcdItemEncAttributeRoleConfidential](#RequestPcdItemEncAttributeRoleConfidential) + * 10.4. [RequestPcdItemEncAttributePrivate](#RequestPcdItemEncAttributePrivate) + * 10.5. [RequestPcdItemGenericEnc](#RequestPcdItemGenericEnc) + * 10.6. [RequestPcdItemEnc](#RequestPcdItemEnc) +* 11. [RequestPrd](#RequestPrd) + * 11.1. [RequestPrdResponse](#RequestPrdResponse) + * 11.2. [RequestPrdConfirm](#RequestPrdConfirm) + * 11.3. [RequestPrdList](#RequestPrdList) + * 11.4. [RequestPrdMessage](#RequestPrdMessage) + * 11.5. [RequestPrdResponse](#RequestPrdResponse-1) + * 11.6. [RequestPrdUpdate](#RequestPrdUpdate) +* 12. [Roles](#Roles) + * 12.1. [Role](#Role) + * 12.2. [Conditions](#Conditions) + * 12.2.1. [TransactionMode](#TransactionMode) + * 12.2.2. [ConditionPayment](#ConditionPayment) + * 12.2.3. [ConditionCommitment](#ConditionCommitment) + * 12.2.4. [ConditionDeposit](#ConditionDeposit) + * 12.2.5. [ConditionOrchestration](#ConditionOrchestration) + * 12.2.6. [ConditionCap](#ConditionCap) + * 12.2.7. [Condition RequestPrdAddressSet](#ConditionRequestPrdAddressSet) + * 12.2.8. [ConditionPublish](#ConditionPublish) + * 12.3. [RolesGroup](#RolesGroup) + * 12.3.1. [RoleArtefact](#RoleArtefact) + * 12.3.2. [RoleDeposit](#RoleDeposit) + * 12.3.3. [RoleCommitment](#RoleCommitment) + * 12.3.4. [RoleMember](#RoleMember) + * 12.4. [RolePeer](#RolePeer) + * 12.4.1. [RolePayment](#RolePayment) + * 12.4.2. [RoleProcess](#RoleProcess) +* 13. [12. Rust considerations](#Rustconsiderations) + * 13.1. [General Implications for Project Objects](#GeneralImplicationsforProjectObjects) + * 13.2. [Debug](#Debug) + * 13.3. [Default](#Default) + * 13.4. [PartialEq, Eq](#PartialEqEq) + * 13.5. [Hash](#Hash) + * 13.6. [PartialOrd, Ord](#PartialOrdOrd) +* 14. [Todo](#Todo) # Exigences de sécurité et de confidentialité -## 1. Documents de référence + +## 1. Documents de référence Voir [_Doc_references.md](_Doc_references.md). -## 2. Détails de conception +## 2. Détails de conception Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits. @@ -52,23 +53,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. -## 3. Mot de passe +## 3. 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. -## 4. Cache +## 4. Cache Stockage sécurisé du cache par un chiffrement par le mot de passe. -## 5. Chiffrement des communications +## 5. 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 messages chiffrent les `RequestPcd` et `RequestPrd` 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 `RequestPcd` et `RequestPrd`.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. -## 6. Confidentialité des `RequestPcd` et RequestPrd +## 6. Confidentialité des `RequestPcd` et RequestPrd Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes. @@ -82,7 +83,7 @@ Le chiffrement des `RequestPcd` est un chiffrement symétrique conformément aux * **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). -## 7. Confidentialité des messages sur les relais +## 7. Confidentialité des messages sur les relais Les `RequestPcd` et les `RequestPrd` sont envoyés aux relais dans des enveloppes appelées `Message`. @@ -92,89 +93,89 @@ Tous les `RequestPrd` sont confirmés par un et chiffrent les clés transamises 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. -## 8. Clé de chiffrement robuste +## 8. 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. -### 8.1. Résistance aux attaques cryptanalytiques +### 8.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. -### 8.2. Diffusion et confusion +### 8.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é. -### 8.3. Non-linéarité +### 8.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. -## 9. Fonctions de hashage +## 9. 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 : -## 10. Exigences génériques +## 10. Exigences génériques -### 10.1. Pas de secret de la conception +### 10.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. -### 10.2. Validé par la communauté scientifique +### 10.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. -### 10.3. Implémentation correcte +### 10.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/)). -### 10.4. Détermination +### 10.4. Détermination Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie. -### 10.5. Rapidité de calcul +### 10.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. -### 10.6. Diffusion (ou effet avalanche) +### 10.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. -### 10.7. Résistance aux collisions +### 10.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 : -#### 10.7.1. Résistance aux collisions faibles +#### 10.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. -#### 10.7.2. Résistance aux collisions fortes +#### 10.7.2. Résistance aux collisions fortes Il est difficile de trouver deux entrées distinctes qui produisent le même hachage. -### 10.8. Résistance à la pre_id +### 10.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 : -#### 10.8.1. Résistance à la pre_id +#### 10.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. -#### 10.8.2. Résistance à la seconde pre_id +#### 10.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. -### 10.9. Compression +### 10.9. Compression La fonction de hachage doit pouvoir prendre une entrée de taille arbitraire et produire une sortie de taille fixe. -### 10.10. Non réversibilité +### 10.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. -### 10.11. Absence de toute structure prévisible +### 10.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. -## 11. Gestion sécurisée des clés +## 11. 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. @@ -184,24 +185,24 @@ Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffr L'utilisateur 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é. -## 12. Performance +## 12. 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. -## 13. Disponibilité +## 13. 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 `membres` des gestionnaires des membres 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'utilisateur peut de son initiative et en toute autonomie révoquer une identité et en générer une nouvelle. -## 14. Évolutivité +## 14. Évolutivité La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `ItemProcess` . -## 15. Autres Mesures de sécurité +## 15. 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é utilisateur et écrasées des données confirmées reçues du réseau et toutes vérifiables. Tous les autres composants et utilisateurs ont un stockage en mémoire, non persisté (mais restauré à leur propre récupération de leur identité). -## 16. Todo +## 16. Todo diff --git a/doc/diagrams/.$WalletOnboard.drawio.bkp b/doc/diagrams/.$WalletOnboard.drawio.bkp new file mode 100644 index 0000000..444c2a4 --- /dev/null +++ b/doc/diagrams/.$WalletOnboard.drawio.bkp @@ -0,0 +1,494 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/4NK-CheatSheet.drawio b/doc/diagrams/4NK-CheatSheet.drawio new file mode 100644 index 0000000..cac15d9 --- /dev/null +++ b/doc/diagrams/4NK-CheatSheet.drawio @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/doc/diagrams/WalletCreate.drawio b/doc/diagrams/WalletCreate.drawio index 2a7cf9f..78d01a0 100644 --- a/doc/diagrams/WalletCreate.drawio +++ b/doc/diagrams/WalletCreate.drawio @@ -1,11 +1,11 @@ - + - + - - + + @@ -163,14 +163,24 @@ + + + + + + + + + + - + - + - + @@ -180,16 +190,17 @@ - + - - + + + - + @@ -238,8 +249,8 @@ - - + + @@ -358,23 +369,23 @@ - + - - + + - + - + - + @@ -419,15 +430,6 @@ - - - - - - - - - @@ -447,95 +449,74 @@ - - - - - - - - - - - - - - - - - - - - - - + - + - + - - + + - + - + - + - + - + - + - + - - + + - + - + - + - + @@ -546,15 +527,6 @@ - - - - - - - - - @@ -579,58 +551,212 @@ - - + + - + - + - - + + - - + + - + - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/WalletCreate.png b/doc/diagrams/WalletCreate.png index 66e4646..762f555 100644 Binary files a/doc/diagrams/WalletCreate.png and b/doc/diagrams/WalletCreate.png differ diff --git a/doc/diagrams/WalletOnboard.drawio b/doc/diagrams/WalletOnboard.drawio new file mode 100644 index 0000000..1dd5e95 --- /dev/null +++ b/doc/diagrams/WalletOnboard.drawio @@ -0,0 +1,494 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/WalletOnboard.png b/doc/diagrams/WalletOnboard.png new file mode 100644 index 0000000..bf26d1a Binary files /dev/null and b/doc/diagrams/WalletOnboard.png differ diff --git a/doc/diagrams/WalletRecover.drawio b/doc/diagrams/WalletRecover.drawio index 275ba70..8d4a8ee 100644 --- a/doc/diagrams/WalletRecover.drawio +++ b/doc/diagrams/WalletRecover.drawio @@ -1,6 +1,6 @@ - + - + @@ -153,8 +153,7 @@ - - + @@ -202,7 +201,7 @@ - + @@ -283,12 +282,12 @@ - + - + @@ -313,18 +312,16 @@ - + + - - - @@ -342,35 +339,37 @@ - + + + - - - + + + - - - - - - + - - + + + - + + - + - - + + + + + @@ -386,12 +385,12 @@ - + - + @@ -444,7 +443,7 @@ - + @@ -579,15 +578,6 @@ - - - - - - - - - @@ -694,6 +684,124 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/diagrams/WalletRecover.png b/doc/diagrams/WalletRecover.png index e5babf9..18aeee2 100644 Binary files a/doc/diagrams/WalletRecover.png and b/doc/diagrams/WalletRecover.png differ