Fix role definion (datamodel) (doc)
This commit is contained in:
parent
e7c2c3fd06
commit
dd2592e306
@ -25,7 +25,7 @@
|
||||
|
||||
## 1. <a name='Objectif'></a>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 de messages entre parties prenantes. Le concept de Silent Payment est employé pour authentifier les utilisateurs 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](https://cryptpad.fr/diagram/#/2/diagram/view/GbkNsP8MEh2oSM5442jC9ONiNZhYZvfeWUVEmiIjXHk).
|
||||
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 de messages entre parties prenantes. Le concept de Silent Payment est employé pour authentifier les utilisateurs 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](https://cryptpad.fr/diagram/#/2/diagram/view/GbkNsP8MEh2oSM5442jC9ONiNZhYZvfeWUVEmiIjXHk).
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
@ -55,7 +55,7 @@ Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API d
|
||||
|
||||
En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis.
|
||||
|
||||
Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux RequestPcd et RequestPrd correspondants.
|
||||
Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux `RequestPcd` et `RequestPrd` correspondants.
|
||||
|
||||
## 7. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
|
||||
|
||||
@ -138,7 +138,7 @@ Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Vo
|
||||
|
||||
2. Une `pre-id Part1EncHash` qui identifie l'utilisateur est générée par le hash (SHA 256) de la `Part1` et du mot de passe de l'utilisateur.
|
||||
|
||||
3. Création d'un `RequestPrdKeyBackup` par membre (1 shard par membre), par RequestPrd :
|
||||
3. Création d'un `RequestPrdKeyBackup` 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.
|
||||
|
||||
@ -187,9 +187,9 @@ Pour être `onboard` dans un process, c'est-à-dire avoir un rôle, il faut :
|
||||
|
||||
###### Mise à jour de la liste des membres
|
||||
|
||||
Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du RequestPcd de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce RequestPrd devra recevoir des membres du rôle `Member` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
Pour mettre à jour la liste des membres il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des membres, contenant l'objet `ItemMember` complet aux membres du role `member`. Ce `RequestPrd` devra recevoir des membres du rôle `Member` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
|
||||
C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que `metadadata` privée (chiffrée par la clé de dépense du signet) dans un RequestPcd (et les `RequestPrdUpdate` correspondant).
|
||||
C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que `metadadata` privée (chiffrée par la clé de dépense du signet) dans un `RequestPcd` (et les `RequestPrdUpdate` correspondant).
|
||||
|
||||
Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet.
|
||||
|
||||
@ -198,7 +198,7 @@ Les metadatas des membres propres au process sont décrits dans le process et do
|
||||
L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
1. Création d'un `ItemMember` correspondant à l'utilisateur.
|
||||
2. Création d'une nouvelle version du RequestPcd avec l'ajout de l'`ItemMember` créé.
|
||||
2. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemMember` créé.
|
||||
3. Création de `RequestPrdKeyHello` à destination du membre.
|
||||
4. Création de `Message` du `RequestPrdKeyHello` à destination du membre.
|
||||
5. Envoi de la transaction SP du `Message` du `RequestPrdKeyHello` à destination du membre.
|
||||
@ -208,14 +208,14 @@ L'`ItemMember` est décrit dans la spécification [Specs-Datamodel.md](Specs-Dat
|
||||
|
||||
###### Mise à jour de la liste des process
|
||||
|
||||
Pour mettre à jour la liste des process il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du RequestPcd de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `process`. Ce RequestPrd devra recevoir des membres du rôle `Process` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
Pour mettre à jour la liste des process il faut envoyer un `RequestPrdUpdate` avec une nouvelle version du `RequestPcd` de la liste des process, contenant l'objet `ItemProcess` complet aux membres du role `process`. Ce `RequestPrd` devra recevoir des membres du rôle `Process` du process les `RequestPrdResponse` correspondant aux critères de validation du `process`.
|
||||
|
||||
L'`ItemProcess` est décrit dans la spécification [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
Demande d'update de la liste des membres ( RequestPcd) d'un process vers chaque membre du rôle `Member` du process.:
|
||||
|
||||
1. Création d'un `ItemProcess` correspondant à l'utilisateur.
|
||||
2. Création d'une nouvelle version du RequestPcd avec l'ajout de l'`ItemProcess` créé.
|
||||
2. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemProcess` créé.
|
||||
3. Création de `RequestPrdKeyHello` à destination du membre.
|
||||
4. Création de `Message` du `RequestPrdKeyHello` à destination du membre.
|
||||
5. Envoi de la transaction SP du `Message` du `RequestPrdKeyHello` à destination du membre.
|
||||
@ -236,7 +236,7 @@ Au moment de l'update de l'`ItemMember` il est possible de charger des addresses
|
||||
|
||||
Les clés privées associées sont générées lors de l'update d'un membre, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
|
||||
|
||||
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 RequestPrd concernés.
|
||||
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 `RequestPrd` concernés.
|
||||
|
||||
#### 9.1.3. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
|
||||
|
||||
@ -263,12 +263,12 @@ Demande d'update de la liste des membres ( RequestPcd) d'un process :
|
||||
1. Création et envoi des `RequestPrdList`.
|
||||
2. Réception des `RequestPrdResponse` en réponse aux `RequestPrdList` et mise à jour des listes depuis les `RequestPcd` correspondants.
|
||||
3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
|
||||
4. Création d'une nouvelle version du RequestPcd avec l'ajout de l'`ItemMember` créé.
|
||||
4. Création d'une nouvelle version du `RequestPcd` avec l'ajout de l'`ItemMember` créé.
|
||||
5. Redirection vers la page du process sur le relai.
|
||||
|
||||
## 10. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
## 11. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des RequestPcd et RequestPrd dans des scénarios réels.
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -74,5 +74,5 @@ La richesse et la diversité des métadonnées permettent une personnalisation e
|
||||
|
||||
## 6. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des RequestPcd et RequestPrd dans des scénarios réels.
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -4,43 +4,43 @@
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 4. [## 4. Variable `SharedPeerList` du SDK (Wasm)](#4.VariableSharedPeerListduSDKWasm)
|
||||
* 5. [5. Structure du stockage en cache](#Structuredustockageencache)
|
||||
* 5.1. [5.1. Relais](#Relais)
|
||||
* 5.2. [5.2. Process](#Process)
|
||||
* 5.3. [5.3. Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
|
||||
* 5.4. [5.4. Liste des sockets ouverts](#Listedessocketsouverts)
|
||||
* 5.1. [5.1. Relais](#Relais)
|
||||
* 5.2. [5.2. Process](#Process)
|
||||
* 5.3. [5.3. Liste des hashs des messages reçus](#Listedeshashsdesmessagesreus)
|
||||
* 5.4. [5.4. Liste des sockets ouverts](#Listedessocketsouverts)
|
||||
* 6. [6. Caractéristiques générales des messages de type `Message` et de type `MessageConnect`](#CaractristiquesgnralesdesmessagesdetypeMessageetdetypeMessageConnect)
|
||||
* 6.1. [6.1. SharedPeerList](#SharedPeerList)
|
||||
* 6.2. [6.2. SharedProcessList](#SharedProcessList)
|
||||
* 6.3. [6.3. Taille des données](#Tailledesdonnes)
|
||||
* 6.4. [6.4. Preuve de travail](#Preuvedetravail)
|
||||
* 6.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet)
|
||||
* 6.1. [6.1. SharedPeerList](#SharedPeerList)
|
||||
* 6.2. [6.2. SharedProcessList](#SharedProcessList)
|
||||
* 6.3. [6.3. Taille des données](#Tailledesdonnes)
|
||||
* 6.4. [6.4. Preuve de travail](#Preuvedetravail)
|
||||
* 6.5. [6.5. Adresse SP de faucet](#AdresseSPdefaucet)
|
||||
* 7. [7. Traitements par les clients](#Traitementsparlesclients)
|
||||
* 7.1. [7.1. Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
|
||||
* 7.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
||||
* 7.1.2. [7.1.2. Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
|
||||
* 7.2. [7.2. Envoi de RequestPcd sur les relais via les messages de type `Message`](#EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.3. [7.3. Envoi de RequestPrd sur les relais via les messages de type `Message`](#EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.4. [7.4. Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
|
||||
* 7.1. [7.1. Connexion d'un client à sa liste relais via les messages de type `MessageConnect`](#ConnexiondunclientsalisterelaisvialesmessagesdetypeMessageConnect)
|
||||
* 7.1.1. [7.1.1. Récupération et choix des relais](#Rcuprationetchoixdesrelais)
|
||||
* 7.1.2. [7.1.2. Envoi du message de type `MessageConnect` à chaque relais](#EnvoidumessagedetypeMessageConnectchaquerelais)
|
||||
* 7.2. [7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message`](#EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.3. [7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message`](#EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage)
|
||||
* 7.4. [7.4. Traitement des messages de type `Message` par les clients](#TraitementdesmessagesdetypeMessageparlesclients)
|
||||
* 8. [8. Traitements par les relais](#Traitementsparlesrelais)
|
||||
* 8.1. [8.1. Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 8.2. [8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 8.1. [8.1. Traitement des messages de type `MessageConnect` par les relais](#TraitementdesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 8.2. [8.2. Connexion au réseau de relais via les messages de type `MessageConnect` par les relais](#ConnexionaurseauderelaisvialesmessagesdetypeMessageConnectparlesrelais)
|
||||
* 9. [9. 9. Traitement des messages de type `Message` par les relais](#TraitementdesmessagesdetypeMessageparlesrelais)
|
||||
* 9.1. [9.1. Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
|
||||
* 9.2. [9.2. Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
|
||||
* 9.1. [9.1. Broadcast des messages de type `Message` vers les relais](#BroadcastdesmessagesdetypeMessageverslesrelais)
|
||||
* 9.2. [9.2. Broadcast des messages de type `Message` vers les clients connectés](#BroadcastdesmessagesdetypeMessageverslesclientsconnects)
|
||||
* 10. [10. Connexions aux réseaux de noeuds de bitcoin de réseaux side chain ou mainnet](#Connexionsauxrseauxdenoeudsdebitcoinderseauxsidechainoumainnet)
|
||||
* 10.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
|
||||
* 10.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
|
||||
* 10.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
|
||||
* 10.4. [10.4. Validation et relais](#Validationetrelais)
|
||||
* 10.5. [10.5. Gestion des Forks](#GestiondesForks)
|
||||
* 10.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain)
|
||||
* 10.6.1. [10.6.1. Clients](#Clients)
|
||||
* 10.6.2. [10.6.2. Relais](#Relais-1)
|
||||
* 10.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1)
|
||||
* 10.8. [10.8. Horodatage et ancrage des RequestPrd via les transactions Silent Payment (SP)](#HorodatageetancragedesRequestPrdvialestransactionsSilentPaymentSP)
|
||||
* 10.1. [10.1. Protocole de Découverte des Pairs](#ProtocoledeDcouvertedesPairs)
|
||||
* 10.2. [10.2. Protocole de Transmission des Transactions](#ProtocoledeTransmissiondesTransactions)
|
||||
* 10.3. [10.3. Protocole de Partage des Blocs](#ProtocoledePartagedesBlocs)
|
||||
* 10.4. [10.4. Validation et relais](#Validationetrelais)
|
||||
* 10.5. [10.5. Gestion des Forks](#GestiondesForks)
|
||||
* 10.6. [10.6. Connexion au réseau de nœuds de side chain](#Connexionaurseaudenudsdesidechain)
|
||||
* 10.6.1. [10.6.1. Clients](#Clients)
|
||||
* 10.6.2. [10.6.2. Relais](#Relais-1)
|
||||
* 10.7. [10.7. Connexion au réseau de nœuds de layer 1](#Connexionaurseaudenudsdelayer1)
|
||||
* 10.8. [10.8. Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP)](#HorodatageetancragedesRequestPrdvialestransactionsSilentPaymentSP)
|
||||
* 11. [## 11. Transactions mainnet Bitcoin](#11.TransactionsmainnetBitcoin)
|
||||
* 11.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 11.2. [11.2. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 11.1. [11.1. Horodatage et ancrage des blocs de la side chain sur Bitcoin](#HorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 11.2. [11.2. Remboursement des frais d'horodatage et ancrage des blocs de la side chain sur Bitcoin](#RemboursementdesfraisdhorodatageetancragedesblocsdelasidechainsurBitcoin)
|
||||
* 12. [Exemples de Code](#ExemplesdeCode)
|
||||
* 13. [Todo](#Todo)
|
||||
|
||||
@ -105,7 +105,7 @@ Le cache contient une liste des hashs des messages de type `Message` et de type
|
||||
* MessageHashList: Hashs des objets `Message`.
|
||||
* MessageConnectHashList: Hashs des objets `MessageConnect` (vide pour les clients).
|
||||
* MessageDataEncHashList: Hashs de la donnée encryptée dans les objets `Message`.
|
||||
* RequestPcdHashList: Hashs des `RequestPcd` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant (vide pour les relais) et état actuel de la collecte des RequestPrd correspondants.
|
||||
* RequestPcdHashList: Hashs des `RequestPcd` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant (vide pour les relais) et état actuel de la collecte des `RequestPrd` correspondants.
|
||||
* RequestPrdHashList: Hashs des `RequestPrd` une fois déchiffrés des objets Message `Message`, avec le hash du message correspondant et l'id de la transaction Silent Payment (SP) correspondante (vide pour les relais).
|
||||
* TxFaucetIdList: Liste des transactions classiques du faucet.
|
||||
* TxSpIdList: Liste des transactions silent payment (SP) reçues.
|
||||
@ -167,13 +167,13 @@ L'utilisateur parcourt sa liste de relais et envoie un message de type `MessageC
|
||||
|
||||
Il n'y a pas de retour attendu pour ce message.
|
||||
|
||||
### 7.2. <a name='EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de RequestPcd sur les relais via les messages de type `Message`
|
||||
### 7.2. <a name='EnvoideRequestPcdsurlesrelaisvialesmessagesdetypeMessage'></a>7.2. Envoi de `RequestPcd` sur les relais via les messages de type `Message`
|
||||
|
||||
Une fois le `RequestPcd` finalisé, il est chiffré par la `ProcessKey` du process. Cette partie chiffrée est la valeur de l'attribut `request_enc` du `Message`.
|
||||
|
||||
L'utilisateur parcourt sa liste de relais et envoie un message correspondant de type `Message` en JSON (voir [Specs-Datamodel.md](Specs-Datamodel.md)) à chaque relais pour se connecter, il partage sa liste de relais et sa liste de process.
|
||||
|
||||
### 7.3. <a name='EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage'></a>7.3. Envoi de RequestPrd sur les relais via les messages de type `Message`
|
||||
### 7.3. <a name='EnvoideRequestPrdsurlesrelaisvialesmessagesdetypeMessage'></a>7.3. Envoi de `RequestPrd` sur les relais via les messages de type `Message`
|
||||
|
||||
Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cette transaction plusieurs hashs sont ajoutés sur des outputs aux indexs suivants:
|
||||
|
||||
@ -182,9 +182,9 @@ Une fois le `RequestPrd` finalisé, une transaction SP est réalisée, dans cett
|
||||
3. Le hash du process
|
||||
4. Le hash de l'`item_name` de l'`Item` concerné
|
||||
5. Le hash de la valeur de la signature (attribut `sig_value` du RequestPrd)
|
||||
6. Le hash du `RequestPrd` d'origine associé au RequestPrd (le cas échéant)
|
||||
7. Le hash du `RequestPcd` d'origine associé au RequestPrd (le cas échéant)
|
||||
8. Le hash du `RequestPcd` de référence associé au RequestPrd (le cas échéant)
|
||||
6. Le hash du `RequestPrd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
7. Le hash du `RequestPcd` d'origine associé au `RequestPrd` (le cas échéant)
|
||||
8. Le hash du `RequestPcd` de référence associé au `RequestPrd` (le cas échéant)
|
||||
9. Le hash d'un `Amount` de paiement (le cas échéant)
|
||||
10. Le hash d'un `Amount`de dépôt (le cas échéant)
|
||||
11. Un hash d'un engagement externe ou d'un `Number` (le cas échéant)
|
||||
@ -193,7 +193,7 @@ La clé `KeyConfidential` de cette transaction est utilisée pour chiffrer les c
|
||||
|
||||
* `RequestPcd_keys_role_confidential_list_enc_by_shared_secret`
|
||||
|
||||
Pour les RequestPrd de type `RequestPrdResponse` :
|
||||
Pour les `RequestPrd` de type `RequestPrdResponse` :
|
||||
|
||||
* `payment_method_enc_by_shared_secret`
|
||||
* `deposit_method_enc_by_shared_secret`
|
||||
@ -203,17 +203,17 @@ Pour les RequestPrd de type `RequestPrdResponse` :
|
||||
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||
* `shard_enc_by_sp_shared_secret`
|
||||
|
||||
Pour les RequestPrd de type `RequestPrdConfirm` :
|
||||
Pour les `RequestPrd` de type `RequestPrdConfirm` :
|
||||
|
||||
* `code_confirm_enc_by_shared_secret`
|
||||
|
||||
Pour les RequestPrd de type `RequestPrdKeyBackup` :
|
||||
Pour les `RequestPrd` de type `RequestPrdKeyBackup` :
|
||||
|
||||
* `device_footprint_enc_by_sp_shared_secret`
|
||||
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||
* `shard_enc_by_sp_shared_secret`
|
||||
|
||||
Pour les RequestPrd de type `RequestPrdKeyHello` :
|
||||
Pour les `RequestPrd` de type `RequestPrdKeyHello` :
|
||||
|
||||
* `part_1_enc_hash_enc_by_sp_shared_secret`
|
||||
|
||||
@ -236,7 +236,7 @@ Le client met à jour ses propres listes suivantes :
|
||||
|
||||
Déchiffrement du message avec la `ProcessKey` du process et contrôles suivants :
|
||||
|
||||
* Calcul du hash du RequestPcd ou RequestPrd et vérification de la non-existence du hash dans le cache.
|
||||
* Calcul du hash du `RequestPcd` ou `RequestPrd` et vérification de la non-existence du hash dans le cache.
|
||||
* Voir [ RequestPrd- RequestPcd-Specs.md]( RequestPrd- RequestPcd-Specs.md) pour les détails des contrôles.
|
||||
|
||||
Mises à jour des données du cache.
|
||||
@ -373,7 +373,7 @@ Lorsque deux blocs sont minés presque simultanément, cela peut créer une bifu
|
||||
|
||||
#### 10.6.1. <a name='Clients'></a>10.6.1. Clients
|
||||
|
||||
Les clients se connectent comme un nœud depuis le SDK au réseau de nœuds de side chain via les protocoles p2p de Bitcoin. Ils reçoivent les blocs et les transactions (mempool) de la side chain et scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux RequestPrd, puis les RequestPcd correspondant aux RequestPrd.
|
||||
Les clients se connectent comme un nœud depuis le SDK au réseau de nœuds de side chain via les protocoles p2p de Bitcoin. Ils reçoivent les blocs et les transactions (mempool) de la side chain et scannent les transactions de la side chain pour trouver les transactions Silent Payment (SP) correspondantes aux RequestPrd, puis les `RequestPcd` correspondant aux RequestPrd.
|
||||
|
||||
#### 10.6.2. <a name='Relais-1'></a>10.6.2. Relais
|
||||
|
||||
@ -383,9 +383,9 @@ Les relais hébergent un nœud complet de la side chain, connecté aux autres me
|
||||
|
||||
Les relais hébergent un nœud complet du mainnet, connecté aux autres membres de ce réseau. Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
|
||||
|
||||
### 10.8. <a name='HorodatageetancragedesRequestPrdvialestransactionsSilentPaymentSP'></a>10.8. Horodatage et ancrage des RequestPrd via les transactions Silent Payment (SP)
|
||||
### 10.8. <a name='HorodatageetancragedesRequestPrdvialestransactionsSilentPaymentSP'></a>10.8. Horodatage et ancrage des `RequestPrd` via les transactions Silent Payment (SP)
|
||||
|
||||
Les RequestPrd sont horodatés et ancrés sur la side chain via des transactions Silent Payment (SP) contenant les hashs des messages et des signatures associées ( RequestPrd). Ces transactions sont ajoutées aux blocs, eux-mêmes signés par les nœuds "certificator" de la side chain pour être ajoutés à cette timechain. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée). Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
|
||||
Les `RequestPrd` sont horodatés et ancrés sur la side chain via des transactions Silent Payment (SP) contenant les hashs des messages et des signatures associées ( RequestPrd). Ces transactions sont ajoutées aux blocs, eux-mêmes signés par les nœuds "certificator" de la side chain pour être ajoutés à cette timechain. La dépense des UTXO de la transaction Silent Payment (SP) vaut pour signature (validation de la possession de la clé privée associée). Voir [Specs-Deployment.md](Specs-Deployment.md) pour les détails de déploiement.
|
||||
|
||||
## 11. <a name='11.TransactionsmainnetBitcoin'></a>## 11. Transactions mainnet Bitcoin
|
||||
|
||||
@ -401,5 +401,5 @@ Le minage "vert" de 4NK permet de produire les jetons nécessaires au remboursem
|
||||
|
||||
## 13. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des RequestPcd et RequestPrd dans des scénarios réels.
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
* 1. [Objectif](#Objectif)
|
||||
* 2. [Portée](#Porte)
|
||||
* 3. [3. Documents de référence](#Documentsderfrence)
|
||||
* 4. [Commun aux RequestPcd et RequestPrd](#CommunauxRequestPcdetRequestPrd)
|
||||
* 4. [Commun aux `RequestPcd` et RequestPrd](#CommunauxRequestPcdetRequestPrd)
|
||||
* 4.1. [Création et envoi](#Crationetenvoi)
|
||||
* 4.2. [Réception](#Rception)
|
||||
* 5. [Fonction des RequestPcd](#FonctiondesRequestPcd)
|
||||
@ -41,99 +41,99 @@
|
||||
numbering=true
|
||||
autoSave=true
|
||||
/vscode-markdown-toc-config -->
|
||||
<!-- /vscode-markdown-toc --># RequestPrd et RequestPcd - Specs
|
||||
<!-- /vscode-markdown-toc --># `RequestPrd` et `RequestPcd` - Specs
|
||||
|
||||
## 1. <a name='Objectif'></a>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.
|
||||
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. <a name='Porte'></a>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.
|
||||
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. <a name='Documentsderfrence'></a>3. Documents de référence
|
||||
|
||||
Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux RequestPcd et RequestPrd
|
||||
## 4. <a name='CommunauxRequestPcdetRequestPrd'></a>Commun aux `RequestPcd` et RequestPrd
|
||||
|
||||
### 4.1. <a name='Crationetenvoi'></a>Création et envoi
|
||||
|
||||
Les RequestPcd et les RequestPrd sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
Les `RequestPcd` et les `RequestPrd` sont envoyés sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
|
||||
Les messages contiennent des RequestPrd ou des RequestPcd encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
|
||||
**Création du message et envoi**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
|
||||
|
||||
### 4.2. <a name='Rception'></a>Réception
|
||||
|
||||
Les RequestPcd et les RequestPrd sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
Les `RequestPcd` et les `RequestPrd` sont reçus sous forme de `message` (JSON) depuis les websockets des relais.
|
||||
|
||||
Les messages contiennent des RequestPrd ou des RequestPcd encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
Les messages contiennent des `RequestPrd` ou des `RequestPcd` encapsulés dans l'attribut `request_enc`, chiffré par la clé `ProcessKey` du `process` concerné.
|
||||
|
||||
A la réception des messages, ils sont tous déchiffrés puis conservés ou non en fonction du `process hash` du RequestPcd ou du RequestPrd (dans l'attribut `request`). Si le `process hash` n'est pas reconnu, le message est ignoré.
|
||||
A la réception des messages, ils sont tous déchiffrés puis conservés ou non en fonction du `process hash` du `RequestPcd` ou du `RequestPrd` (dans l'attribut `request`). Si le `process hash` n'est pas reconnu, le message est ignoré.
|
||||
|
||||
Les RequestPrd et RequestPcd sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
Les `RequestPrd` et `RequestPcd` sont au format JSON. Voir [Specs-Datamodel.md](Specs-Datamodel.md).
|
||||
|
||||
Les types RequestPrd et RequestPcd sont distingués par l'attribut `request_type` dans le `message`.
|
||||
Les types `RequestPrd` et `RequestPcd` sont distingués par l'attribut `request_type` dans le `message`.
|
||||
|
||||
En cas de RequestPcd ou RequestPrd en relation via `RequestPcd_reference_hash` ou `request_prd_reference_hash` ou `RequestPcd_origin_hash` ou `request_prd_origin_hash` ou `item_reference_hash` (dans des RequestPcd), il avoir reçu ou attendre ces documents pour traiter le message.
|
||||
En cas de `RequestPcd` ou `RequestPrd` en relation via `RequestPcd_reference_hash` ou `request_prd_reference_hash` ou `RequestPcd_origin_hash` ou `request_prd_origin_hash` ou `item_reference_hash` (dans des RequestPcd), il avoir reçu ou attendre ces documents pour traiter le message.
|
||||
|
||||
**Réception du message**: voir [Message-SP-Specs.md](Message-SP-Specs.md).
|
||||
|
||||
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é.
|
||||
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. <a name='FonctiondesRequestPcd'></a>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 `process` et les `members` concernés.
|
||||
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 `process` et les `members` concernés.
|
||||
|
||||
### 5.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
La création d'un RequestPcd suit plusieurs étapes :
|
||||
La création d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. **Chargement de la dernière version de la liste ( RequestPcd)**: Récupération de la dernière version de la liste du type d'`Item` à partir de la source de données, telle qu'une base de données ou un système de stockage.
|
||||
2. **Mise à jour**: Ajouts et modifications eventuelles des `Item`
|
||||
3. **Chiffrement des attributs**: Chiffrement des attributs de chaque Item selon les règles de confidentialité et de partage des clés (cf. [Specs-Security.md](Specs-Security.md)).
|
||||
4. **Chiffrement du RequestPcd**: Chiffrement du RequestPcd avec la clé `ProcessKey` du `process` concerné.
|
||||
5. Traitements communs aux RequestPcd et RequestPrd
|
||||
4. **Chiffrement du RequestPcd**: Chiffrement du `RequestPcd` avec la clé `ProcessKey` du `process` concerné.
|
||||
5. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
|
||||
### 5.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un RequestPcd suit plusieurs étapes :
|
||||
La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. Traitements communs aux RequestPcd et RequestPrd
|
||||
2. Recherche des RequestPrd en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` de ces RequestPrd et attente si nécessaire.
|
||||
3. Déchiffrage des attributs publics des `Item` des RequestPcd avec la `ProcessKey` du `process` concerné.
|
||||
4. Déchiffrage des attributs confidentiels des `Item` des RequestPcd avec les clés de déchiffrement depuis l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret` des RequestPrd.
|
||||
5. Déchiffrage des attributs privés des `Item` des RequestPcd avec la clé privée `KeyRecover`
|
||||
1. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
2. Recherche des `RequestPrd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` de ces `RequestPrd` et attente si nécessaire.
|
||||
3. Déchiffrage des attributs publics des `Item` des `RequestPcd` avec la `ProcessKey` du `process` concerné.
|
||||
4. Déchiffrage des attributs confidentiels des `Item` des `RequestPcd` avec les clés de déchiffrement depuis l'attribut `RequestPcd_keys_role_confidential_list_enc_by_shared_secret` des RequestPrd.
|
||||
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.
|
||||
|
||||
## 6. <a name='FonctiondesRequestPrd'></a>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.
|
||||
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.
|
||||
|
||||
Les clés de chiffrement des attributs confidentiels par rôles des `Item` des RequestPcd sont chiffrées dans les RequestPrd avec le chiffrement du RequestPrd par la clé `KeyConfidential` d'une transaction Silent Payment SP (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des RequestPcd (rôles dans les `process`).
|
||||
Les clés de chiffrement des attributs confidentiels par rôles des `Item` des `RequestPcd` sont chiffrées dans les `RequestPrd` avec le chiffrement du `RequestPrd` par la clé `KeyConfidential` d'une transaction Silent Payment SP (cf. [Specs-Security.md](Specs-Security.md)). Ces clés ne sont distribués qu'aux `members` concernés par les `Item` des `RequestPcd` (rôles dans les `process`).
|
||||
|
||||
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.
|
||||
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. <a name='Fonctionnalitsoptionnelles'></a>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`.
|
||||
|
||||
Lorsque que la réponse fait référence à un RequestPcd il est précisé dans `RequestPcd_reference_hash`, idem pour les RequestPrd avec `request_prd_reference_hash`.
|
||||
Lorsque que la réponse fait référence à un `RequestPcd` il est précisé dans `RequestPcd_reference_hash`, idem pour les `RequestPrd` avec `request_prd_reference_hash`.
|
||||
|
||||
Lorsque que la réponse fait suite directement à un RequestPcd il est précisé dans `RequestPcd_origin_hash`, idem pour les RequestPrd avec `request_prd_origin_hash`.
|
||||
Lorsque que la réponse fait suite directement à un `RequestPcd` il est précisé dans `RequestPcd_origin_hash`, idem pour les `RequestPrd` avec `request_prd_origin_hash`.
|
||||
|
||||
Les `RequestPrdResponse` signalent de façon confidentielle :
|
||||
|
||||
* soient des conditions ad'hoc déjà remplies via l'attribut `payment_method_enc_by_shared_secret`, `deposit_method_enc_by_shared_secret`, `commitment_method_enc_by_shared_secret`, `commitment_request_pcd_hash_list` pour les paiements et preuves ad'hoc éventuellements associés aux RequestPcd de la nouvelle version.
|
||||
* soient des conditions ad'hoc déjà remplies via l'attribut `payment_method_enc_by_shared_secret`, `deposit_method_enc_by_shared_secret`, `commitment_method_enc_by_shared_secret`, `commitment_request_pcd_hash_list` pour les paiements et preuves ad'hoc éventuellements associés aux `RequestPcd` de la nouvelle version.
|
||||
* soient des appels pour recevoir les moyens de satisfaire ces conditions via les attributs `ask_payment_method_enc_by_shared_secret`, `ask_deposit_method_enc_by_shared_secret`, `ask_commitment_method_enc_by_shared_secret`.
|
||||
|
||||
Les `Item` associés sont référencés dans des RequestPcd identifiés par `payment_request_pcd_hash_list_enc_by_shared_secret`, `cap_request_pcd_hash_list_enc_by_shared_secret` (cas des payments temporaires en l'attente du passage d'un cap), `deposit_request_pcd_hash_list_enc_by_shared_secret` et `commitment_request_pcd_hash_list_enc_by_shared_secret`.
|
||||
Les `Item` associés sont référencés dans des `RequestPcd` identifiés par `payment_request_pcd_hash_list_enc_by_shared_secret`, `cap_request_pcd_hash_list_enc_by_shared_secret` (cas des payments temporaires en l'attente du passage d'un cap), `deposit_request_pcd_hash_list_enc_by_shared_secret` et `commitment_request_pcd_hash_list_enc_by_shared_secret`.
|
||||
|
||||
Des champs messages peuvent accompagner les RequestPrd via `message_public`, `message_confidential`, `message_private`.
|
||||
Des champs messages peuvent accompagner les `RequestPrd` via `message_public`, `message_confidential`, `message_private`.
|
||||
|
||||
Il est aussi possible de partager des clés de chiffrement ad'hoc via `certif_key_enc_by_shared_secret`.
|
||||
|
||||
@ -145,54 +145,54 @@ Tous les échanges sont complétés de l'empreinte du device de l'emetteur envoy
|
||||
|
||||
### 6.2. <a name='FonctiondestransactionssilentpaymentSPassociesauxRequestPrd'></a>Fonction des transactions silent payment SP associées aux RequestPrd
|
||||
|
||||
La clé `KeyConfidential` d'une transaction Silent Payment 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. Cette information est parrallèle aux RequestPrd et permet une meilleur sécurité et confidentialité des échanges.
|
||||
La clé `KeyConfidential` d'une transaction Silent Payment 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. Cette information est parrallèle aux `RequestPrd` et permet une meilleur sécurité et confidentialité des échanges.
|
||||
|
||||
La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des RequestPrd donc de la validation des données des RequestPcd. Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et RequestPrd (sauf `RequestPrdKeyBackup`) et des RequestPcd. Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.
|
||||
La transaction Silent Payment SP a aussi une fonction d'horodate et de preuve de publication des `RequestPrd` donc de la validation des données des `RequestPcd`.Les outputs de la transaction Silent Payment SP contiennent les empreintes cryptographiques des `messages` et `RequestPrd` (sauf `RequestPrdKeyBackup`) et des `RequestPcd`.Ainsi l'infrastructure blockchain de signet de 4NK permet de vérifier l'intégrité des flux, leur ordre de référence (horodatage) et leur preuve de publication.
|
||||
|
||||
Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des RequestPrd sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).
|
||||
Les `RequestPrdConfirm` qui sont des accusés automatiques de réception des `RequestPrd` sont aussi associés à une transaction Silent Payment SP, ce qui permet d'ajouter les preuves de réception des demandes et des validations (ou non).
|
||||
|
||||
### 6.3. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
La création d'un RequestPrd suit plusieurs étapes :
|
||||
La création d'un `RequestPrd` suit plusieurs étapes :
|
||||
|
||||
1. **Chargement des clés de chiffrement confidentiel'**: Récupération des clés de chiffrement confidentiel des attributs des items d'un RequestPcd.
|
||||
2. **Chiffrement du RequestPrd**: Chiffrement du RequestPrd avec la clé `ProcessKey` du `process` concerné.
|
||||
3. **Création de l'adresse SP**: (Sauf `RequestPRDKeyBackup`) Création d'une adresse Silent Payment SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du RequestPrd dans la side chain.
|
||||
4. **Création du message**: Création du `message` contenant le RequestPrd chiffré, la preuve de travail, l'adresse de faucet
|
||||
2. **Chiffrement du RequestPrd**: Chiffrement du `RequestPrd` avec la clé `ProcessKey` du `process` concerné.
|
||||
3. **Création de l'adresse SP**: (Sauf `RequestPRDKeyBackup`) Création d'une adresse Silent Payment SP pour le partage de la `KeyConfidential` et pour l'horodatage du hash du `RequestPrd` dans la side chain.
|
||||
4. **Création du message**: Création du `message` contenant le `RequestPrd` chiffré, la preuve de travail, l'adresse de faucet
|
||||
5. **Sélection des relais pour le message**: Sélection de 4 relais pour le message selon l'historique des pings et des réponses retournées.
|
||||
6. **Sélection des noeuds de signet pour la transaction silent Payment (SP)**: (Sauf `RequestPRDKeyBackup`) Sélection de 4 noeuds de signet pour l'envoi de la transaction Silent Payment SP.
|
||||
7. **Envoi du message**: Envoi du message aux relais
|
||||
8. **Envoi de la transaction**: (Sauf `RequestPRDKeyBackup`) envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la transaction Silent Payment SP avec le hash du RequestPrd dans l'attribut `request_prd_reference_hash`.
|
||||
8. **Envoi de la transaction**: (Sauf `RequestPRDKeyBackup`) envoi de la transaction aux noeuds de signet à travers un `RequestPrdMessage` pour la publication de la transaction Silent Payment SP avec le hash du `RequestPrd` dans l'attribut `request_prd_reference_hash`.
|
||||
|
||||
### 6.4. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un RequestPcd suit plusieurs étapes :
|
||||
La réception d'un `RequestPcd` suit plusieurs étapes :
|
||||
|
||||
1. Traitements communs aux RequestPcd et RequestPrd
|
||||
2. Recherche des RequestPcd en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
3. Vérification de la conformité des RequestPcd en relation.
|
||||
4. Recherche des RequestPrd en relation via `request_prd_reference_hash` et `request_prd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
5. Vérification de la conformité des RequestPrd en relation.
|
||||
1. Traitements communs aux `RequestPcd` et RequestPrd
|
||||
2. Recherche des `RequestPcd` en relation via `RequestPcd_reference_hash` et `RequestPcd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
3. Vérification de la conformité des `RequestPcd` en relation.
|
||||
4. Recherche des `RequestPrd` en relation via `request_prd_reference_hash` et `request_prd_origin_hash` et attente si nécessaire et traitement de ceux ci.
|
||||
5. Vérification de la conformité des `RequestPrd` en relation.
|
||||
6. Recherche de l'`Item` associé via `item_reference_hash` et attente si nécessaire et traitement de celui ci.
|
||||
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du RequestPrd dans l'output `2` de la transaction.
|
||||
7. (Sauf `RequestPRDKeyBackup`) Déchiffrage des attributs confidentiels notés `<attribut>_enc_by_shared_secret` depuis la `KeyConfidential` de la transaction silent payment SP correspondante via hash du `RequestPrd` dans l'output `2` de la transaction.
|
||||
8. Mise à jour du cache pour les traitement des RequestPrd.
|
||||
9. Traitements spécifiques au type de RequestPrd.
|
||||
|
||||
## 7. <a name='RequestPrdList-DemandedeListesRequestPcd'></a>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éseau. Chaque RequestPcd liste des `Item` d'un même type, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
||||
Utile pour les utilisateurs cherchant à consulter ou à explorer des listes de contrats, de membres, ou d'autres items dans le réseau. Chaque `RequestPcd` liste des `Item` d'un même type, par exemple les `ItemProcess`, les `ItemMember`, les `ItemPeer`, les `ItemPayment`, etc.
|
||||
|
||||
### 7.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
L'envoi d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdList` incluant l'envoi de la transaction Silent Payment SP via un `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 7.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des RequestPrd
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList` et envoie de la transaction Silent Payment SP associée avec
|
||||
3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
||||
4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné.
|
||||
@ -203,7 +203,7 @@ La réception d'un `RequestPrdList` suit plusieurs étapes :
|
||||
|
||||
## 8. <a name='RequestPrdMessage-EnvoideMessages'></a>RequestPrdMessage - Envoi de Messages
|
||||
|
||||
Le RequestPrdMessage facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
||||
Le `RequestPrdMessage` facilite l'envoi de messages sécurisés entre utilisateurs ou entre utilisateurs et processus/contrats.
|
||||
|
||||
Permet la communication directe et sécurisée au sein du réseau, supportant des échanges d'informations critiques ou des notifications entre parties.
|
||||
|
||||
@ -213,13 +213,13 @@ Les `RequestPrdMessage` répondent aux `RequestPrdMessage` sauf en cas d'envoi d
|
||||
|
||||
### 8.1. <a name='Crationetenvoi-1'></a>Création et envoi
|
||||
|
||||
Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la transaction Silent Payment SP via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
Traitements des `RequestPrd`, avec le `type_request` spécifique à `RequestPrdMessage` incluant l'envoi de la transaction Silent Payment SP via un autre `RequestPrdMessage` pour la publication de la transaction dans la side chain.
|
||||
|
||||
### 8.2. <a name='Rception-1'></a>Réception
|
||||
|
||||
La réception d'un `RequestPrdMessage` suit plusieurs étapes :
|
||||
|
||||
1. Traitements des RequestPrd
|
||||
1. Traitements des `RequestPrd`
|
||||
2. Création et envoi d'un `RequestPrdConfirm` pour confirmer la réception du `RequestPrdList`.
|
||||
3. Recherche en cache de la dernière version de la liste du type d'`Item` concerné.
|
||||
4. Création et envoi d'un `RequestPcd` avec la dernière version de la liste du type d'`Item` concerné.
|
||||
@ -247,7 +247,7 @@ Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdUpd
|
||||
|
||||
## 10. <a name='RequestPrdConfirm-ConfirmationdeRception'></a>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.
|
||||
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.
|
||||
|
||||
Les `RequestPrdList`, `RequestPrdUpdate`, `RequestPrdMessage`, `RequestPrdResponse` et `RequestPrdKeyHello` reçoivent systématiquement un `RequestPrdConfirm` depuis leur réception par le destinataire.
|
||||
|
||||
@ -263,7 +263,7 @@ Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdCon
|
||||
|
||||
## 11. <a name='RequestPrdResponse-RpondreuneDemande'></a>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.
|
||||
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`.
|
||||
|
||||
@ -303,5 +303,5 @@ Traitements des RequestPrd, avec le `type_request` spécifique à `RequestPrdKey
|
||||
|
||||
## 15. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des RequestPcd et RequestPrd dans des scénarios réels.
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -33,7 +33,7 @@
|
||||
|
||||
## 1. <a name='Objectif'></a>Objectif
|
||||
|
||||
Cette section vise à présenter en détail les Documents de Contrat Portable ( RequestPcd) et les Documents de Demande Portable ( RequestPrd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les RequestPcd et RequestPrd assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
|
||||
Cette section vise à présenter en détail les Documents de Contrat Portable ( RequestPcd) et les Documents de Demande Portable ( RequestPrd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les identités numériques, les `RequestPcd` et `RequestPrd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
|
||||
|
||||
## 2. <a name='Porte'></a>Portée
|
||||
|
||||
@ -145,5 +145,5 @@ L'ItemProcess et ItemProcessPublicAttributeGroup offrent un cadre pour l'intégr
|
||||
|
||||
## 10. <a name='Todo'></a>Todo
|
||||
|
||||
* [ ] Extraits de code illustrant l'utilisation des RequestPcd et RequestPrd dans des scénarios réels.
|
||||
* [ ] Extraits de code illustrant l'utilisation des `RequestPcd` et `RequestPrd` dans des scénarios réels.
|
||||
* [ ] Diagrammes de séquences
|
||||
|
||||
@ -40,7 +40,7 @@ Les parties prenantes ont tous les moyens organisationnels dans les process, pou
|
||||
|
||||
## 3. <a name='Journalisationetmonitoring'></a>Journalisation et monitoring
|
||||
|
||||
Tous les utilisateurs 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 RequestPcd sont les listes à jour de l'état de validation de tous les éléments échangés, et les RequestPrd sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un process (possible de segmenter par zones et services).
|
||||
Tous les utilisateurs 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 `RequestPcd` sont les listes à jour de l'état de validation de tous les éléments échangés, et les `RequestPrd` sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un process (possible de segmenter par zones et services).
|
||||
|
||||
Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents sur les relais qui ne sont pas critiques unitairement, tous les flux sont fongibles, chiffrés, anonymes, et peuvent passer par des relais non révélés. Cependant, l'optimisation des listes de pairs et de contrats, pourrait passer par un système de réputation qui nécessitera un historique. À ce stade, la gestion "qualitative" et "quantitative" des relais et des contrats est gérée en mémoire, non persistée et restaurée par chaque connexion à un nouveau pair.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -29,7 +29,7 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
* **Relay**: Un serveur web socket qui relaie en peer to peer les messages entre les autres pairs du réseau de relais et avec les clients connectés.
|
||||
|
||||
* **Message**: Enveloppe commune au RequestPrd et RequestPcd lorsqu'ils sont transmis au relais.
|
||||
* **Message**: Enveloppe commune au `RequestPrd` et `RequestPcd` lorsqu'ils sont transmis au relais.
|
||||
|
||||
* **Process**: Contrat off-chain définissant des conditions d'affichage, légales, de validation cryptographique et de rémunération des signatures.
|
||||
|
||||
@ -81,9 +81,9 @@ Voir [Doc_references.md](Doc_references.md).
|
||||
|
||||
## 5. <a name='Data'></a>Data
|
||||
|
||||
* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les process découverts et les pairs du réseau. Une fois identifié auprès des membres d'un process et avec son identité `member` récupérée, l'objet member et les RequestPcd et RequestPrd du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée.
|
||||
* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les process découverts et les pairs du réseau. Une fois identifié auprès des membres d'un process et avec son identité `member` récupérée, l'objet member et les `RequestPcd` et `RequestPrd` du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée.
|
||||
|
||||
* **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les RequestPcd et RequestPrd, dans les navigateurs web.
|
||||
* **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les `RequestPcd` et RequestPrd, dans les navigateurs web.
|
||||
|
||||
## 6. <a name='ExemplesdeCode'></a>Exemples de Code
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
* 3. [Mot de passe](#Motdepasse)
|
||||
* 4. [Cache](#Cache)
|
||||
* 5. [Chiffrement des communications](#Chiffrementdescommunications)
|
||||
* 6. [Confidentialité des RequestPcd et RequestPrd](#ConfidentialitdesRequestPcdetRequestPrd)
|
||||
* 6. [Confidentialité des `RequestPcd` et RequestPrd](#ConfidentialitdesRequestPcdetRequestPrd)
|
||||
* 7. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
|
||||
* 8. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
|
||||
* 8.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
|
||||
@ -66,25 +66,25 @@ Stockage sécurisé du cache par un chiffrement par le mot de passe.
|
||||
|
||||
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.
|
||||
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. <a name='ConfidentialitdesRequestPcdetRequestPrd'></a>Confidentialité des RequestPcd et RequestPrd
|
||||
## 6. <a name='ConfidentialitdesRequestPcdetRequestPrd'></a>Confidentialité des `RequestPcd` et RequestPrd
|
||||
|
||||
Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes.
|
||||
|
||||
Le chiffrement des RequestPcd est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des clés de chiffrement dans les RequestPrd est un chiffrement symétrique conformément aux exigences suivantes selon :
|
||||
Le chiffrement des `RequestPcd` est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des clés de chiffrement dans les `RequestPrd` est un chiffrement symétrique conformément aux exigences suivantes selon :
|
||||
|
||||
* **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer.
|
||||
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPcd**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un RequestPcd.
|
||||
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les RequestPcd et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
|
||||
* **Données confidentielles avec les membres d'un `role` d'un `process` dans les RequestPrd**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256 générée à la volée dans les `RequestPcd` et alors transmises par le RequestPrd, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
|
||||
|
||||
* **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. <a name='Confidentialitdesmessagessurlesrelais'></a>Confidentialité des messages sur les relais
|
||||
|
||||
Les RequestPcd et les RequestPrd sont envoyés aux relais dans des enveloppes appelées `Message`.
|
||||
Les `RequestPcd` et les `RequestPrd` sont envoyés aux relais dans des enveloppes appelées `Message`.
|
||||
|
||||
Ces enveloppent communique les `RequestPcd` et les `RequestPrd` de façon chiffrée par la `ProcessKey`. Ainsi les messages sont rendus fongibles sur le réseau de relais.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user