4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

simplification

Browse Source
This commit is contained in:
NicolasCantu 2024-02-14 15:43:32 +01:00
parent c96154ab36
commit 12815c2c3d
1 changed files with 42 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
doc/Auth-Specs.md
View File

@ -6,11 +6,15 @@
* 5. [Connexion via des tiers](#Connexionviadestiers)
* 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
* 7. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
* 8. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
* 8.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
* 8.1.1. [HD Wallet (BIP32 + BIP44)](#HDWalletBIP32BIP44)
* 8.1.2. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
* 9. [Exemples de Code](#ExemplesdeCode)
* 8. [Wallet](#Wallet)
* 8.1. [Descripteurs de wallet](#Descripteursdewallet)
* 8.2. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
* 9. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
* 9.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
* 9.1.1. [Gestion de la clé servant à l'ID `spend_recover`](#GestiondelaclservantlIDspend_recover)
* 9.1.2. [Backup de `Part2Enc`](#BackupdePart2Enc)
* 9.1.3. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
* 10. [Exemples de Code](#ExemplesdeCode)
<!-- vscode-markdown-toc-config
numbering=true
@ -56,11 +60,7 @@ Une image de révocation est générée à la création d'une identité pour pou
Le système ne maintiendra pas de session traditionnelle sur le serveur. La navigation de l'utilisateur persiste grâce à un cache local dans IndexedDB ou en mémoire, avec une politique de sécurité stricte forçant la resaisie du mot de passe après un rafraîchissement de la page ou une inactivité prolongée, déterminée par une durée maximale sans login.
## 8. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
### 8.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
#### 8.1.1. <a name='HDWalletBIP32BIP44'></a>Wallet
## 8. <a name='Wallet'></a>Wallet
Les transactions SP ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) :
@ -89,7 +89,7 @@ Dans l'ordre on génère donc :
5. Clé privée de dépense mainnet `spend_mainnet`.
6. Clé privée de scan du mainnet `scan_mainnet`.
##### Descripteurs de wallet
### 8.1. <a name='Descripteursdewallet'></a>Descripteurs de wallet
Les descripteurs de wallet sont une méthode standardisée pour décrire les scripts que le wallet peut utiliser pour dépenser des bitcoins. Ils fournissent une manière compacte et compréhensible de représenter les scripts, incluant les informations sur le type d'adresse (par exemple, P2PKH, P2SH, P2WPKH, etc.), et les clés ou chemins de clés impliqués.
@ -109,35 +109,23 @@ Ici, cprvN représente un placeholder pour le chemin de dérivation de chaque cl
Ici il s'agit du format de stockage des privées, ce pourquoi la clé privée est indiquée dans le descripteur au lieu de la `xpub` plus classiquement utilisées pour ne pas exposer les clés privées.
##### Génération des adresses SP
### 8.2. <a name='Rcuprationdesjetonsdefaucet'></a>Récupération des jetons de faucet
Le relais partage leur liste de relais au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedPeer`.
Le relais retournent des jetons à la connexion et à l'envoi de messages afin de créer les `UTXO` nécessaires pour les transactions SP.
Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
Pour revoir ces jetons l'utilisateur doit générer les adresses sur lesquelles il souhaite recevoir les jetons.
Ces relais envoient en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis ces clés privées).
A chaque nouveau message il génère de nouvelles addresses pour la clé qui va dépenser des jetons de signet. Soit une nouvelle adresse (publique) de la clé privée `spend_recover`.
Avec ces `UTXO` et les clés de dépense et de scan, on génère 1 `adresse SP` pour le réseau signet et 1 pour le réseau mainnet et chacun pour leurs clés de login et de révocation.
Ces adresses apparaîtront dans l'attribut `faucet_sp_address` des messages envoyés aux relais.
Dans l'ordre on génère donc :
## 9. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
1. Adresse `faucet_sp_address` de login du signet.
2. Adresse `faucet_sp_address` de révocation du signet.
3. Adresse `faucet_sp_address` du mainnet.
### 9.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
Puis on se connecte aux relais selon (on se connecte à plusieurs relais afin de pallier aux indisponibilités éventuelles ou au manque de jetons éventuel sur le relai) via un `MessageConnect`.
#### 9.1.1. <a name='GestiondelaclservantlIDspend_recover'></a>Gestion de la clé servant à l'ID `spend_recover`
Puis on génère les adresses SP :
1. Adresse `id_SP` de login du signet depuis `spend_recover` et `scan_recover` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de login du signet.
2. Adresse `id_SP` de révocation du signet depuis `spend_revoke` et `scan_revoke` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de révocation du signet.
3. Adresse `id_SP` du mainnet depuis `spend_mainnet` et `scan_mainnet` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` du mainnet.
##### Clés de dépense du signet du login
Le relais partage leur liste de process au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedProcess`.
La clé privée de dépense du signet du login est la clé principale pour forger les identités.
La clé privée `spend_recover` est la clé principale pour forger les identités.
Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Voici les principales étapes :
@ -147,7 +135,7 @@ Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Vo
1.2. `Part2`, c'est la partie qui sera décomposée par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres du process.
2. Une `préimage 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.
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 `PRDKeyBackup` par membre (1 shard par membre), par PRD :
@ -166,20 +154,22 @@ Dans l'ordre on réalise donc les opérations suivantes donc :
1. Split de `spend_recover`.
2. Chiffrement AES de `Part1`.
3. Mise en cache de `Part1Enc`.
4. Création de la préimage
4. Création de la pre-id
5. Chiffrement AES de `Part2`.
6. Sharding de `Part2Enc`.
Puis (exemple avec 2 membres) :
#### 9.1.2. <a name='BackupdePart2Enc'></a>Backup de `Part2Enc`
1. Création de `PRDKeyBackup` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
2. Création de `PRDKeyBackup` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
3. Création de `Message` du `PRDKeyBackup` à destination de membre 1.
4. Création de `Message` du `PRDKeyBackup` à destination de membre 2.
5. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 1.
6. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1.
11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2.
Les relais initialisent le SDK (Wasm) par défaut avec une liste `SharedProcessList` de `SharedProcess` contenant les membres du rôle `member` du `process` 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 `PRDResponse` en réponse à un `PRDKeyBackup`.
Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
1. Création de `PRDKeyBackup` à destination du membre
2. Création de `Message` du `PRDKeyBackup` à destination du membre.
3. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination du membre.
4. Envoi du `Message` du `PRDKeyBackup` à destination du membre.
##### Étape d'`update` et envoi de l'objet `ItemMember` pour `Onboarding`
@ -238,7 +228,7 @@ Ces clés sont générées lors de l'update d'un membre, avec déjà une identit
Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les PRD concernés.
#### 8.1.2. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
#### 9.1.3. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
Comme pour la création de compte, les relais partagent leur liste de relais et de process au setup du SDK (Wasm), ces listes sont stockées en cache sous forme d'objets `SharedPeer` et `SharedProcess`.
@ -277,6 +267,6 @@ Demande d'update de la liste des membres (PCD) d'un process :
4. Création d'une nouvelle version du PCD avec l'ajout de l'`ItemMember` créé.
5. Redirection vers la page du process sur le relai.
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
## 10. <a name='ExemplesdeCode'></a>Exemples de Code
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.