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

simplifications

Browse Source
This commit is contained in:
NicolasCantu 2024-02-13 16:08:49 +01:00
parent c6816044c3
commit 7c4d869677
1 changed files with 19 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
doc/Auth-Specs.md
View File

@ -2,8 +2,6 @@
* 1. [Objectif](#Objectif)
* 2. [Portée](#Porte)
* 3. [3. Documents de référence](#Documentsderfrence)
* 3.1. [Worfklows](#Worfklows)
* 3.2. [Transverse](#Transverse)
* 4. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
* 5. [Connexion via des tiers](#Connexionviadestiers)
* 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
@ -20,19 +18,19 @@
/vscode-markdown-toc-config -->
<!-- /vscode-markdown-toc --># Auth - Specs
## 1. <a name='Objectif'></a>Objectif
## 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).
## 2. <a name='Porte'></a>Portée
## 2. <a name='Porte'></a>Portée
Ce système couvrira la conception et le développement de l'architecture d'authentification, incluant la génération, la gestion, et la validation des identités numériques à travers des formats de conformité spécifiques (Portable Contract Document et Portable Request Document). Il intégrera également l'authentification des utilisateurs, la connexion via des tiers, la récupération d'identités, et une gestion de session basée sur un cache avec des contraintes de sécurité renforcées. La solution sera conçue pour des environnements hautement sécurisés, nécessitant une haute disponibilité, performance, et évolutivité.
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
## 3. <a name='Documentsderfrence'></a>3. Documents de référence
Voir [Doc_references.md](Doc_references.md).
## 4. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
## 4. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `process`.
@ -42,27 +40,27 @@ Les utilisateurs sont reconnus par une adresse Silent Payment dans un ou plusieu
Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par process dans lequel l'utilisateur a un rôle (`onboarding`).
## 5. <a name='Connexionviadestiers'></a>Connexion via des tiers
## 5. <a name='Connexionviadestiers'></a>Connexion via des tiers
Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience utilisateur.
Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`.
## 6. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
## 6. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
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 PCD et PRD correspondants.
## 7. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
## 7. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
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. <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. <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>HD Wallet (BIP32 + BIP44)
#### 8.1.1. <a name='HDWalletBIP32BIP44'></a>HD Wallet (BIP32 + BIP44)
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) :
@ -107,20 +105,7 @@ Dans l'ordre on génère donc :
2. Adresse `faucet_sp_address` de révocation du signet.
3. Adresse `faucet_sp_address` du mainnet.
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) :
1. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de login du signet.
2. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de révocation du signet.
3. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` du mainnet.
4. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de login du signet.
5. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de révocation du signet.
6. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` du mainnet.
7. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de login du signet.
8. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de révocation du signet.
9. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` du mainnet.
10. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de login du signet.
11. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de révocation du signet.
12. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` du mainnet.
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`.
Puis on génère les adresses SP :
@ -173,14 +158,8 @@ Puis (exemple avec 2 membres) :
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 sur le relai 1.
8. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 2.
9. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 3.
10. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 4.
11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 1.
12. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 2.
13. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 3.
14. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 4.
7. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1.
11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2.
##### Étape d'`update` et envoi de l'objet `ItemMember` pour `Onboarding`
@ -212,14 +191,8 @@ Demande d'update de la liste des membres (PCD) d'un process (exemple avec 2 memb
1.4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
1.5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
1.6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
1.7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
1.8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
1.9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
1.10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
1.11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
1.12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
1.13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
1.14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
1.7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1.
1.11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2.
2. Réception des `PRDResponse` en réponse aux `PRDKeyHello` et mise à jour des listes depuis les `PCD` 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 PCD avec l'ajout de l'`ItemMember` créé.
@ -245,7 +218,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`)
#### 8.1.2. <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`.
@ -264,14 +237,8 @@ Puis :
4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1.
11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2.
1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyHello`.
@ -290,6 +257,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
## 9. <a name='ExemplesdeCode'></a>Exemples de Code
Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.