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

94
doc/Auth-Specs.md
View File

@ -6,11 +6,15 @@
* 5. [Connexion via des tiers](#Connexionviadestiers) * 5. [Connexion via des tiers](#Connexionviadestiers)
* 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse) * 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
* 7. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache) * 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. [Wallet](#Wallet)
* 8.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques) * 8.1. [Descripteurs de wallet](#Descripteursdewallet)
* 8.1.1. [HD Wallet (BIP32 + BIP44)](#HDWalletBIP32BIP44) * 8.2. [Récupération des jetons de faucet](#Rcuprationdesjetonsdefaucet)
* 8.1.2. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover) * 9. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
* 9. [Exemples de Code](#ExemplesdeCode) * 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 <!-- vscode-markdown-toc-config
numbering=true numbering=true
@ -18,19 +22,19 @@
/vscode-markdown-toc-config --> /vscode-markdown-toc-config -->
<!-- /vscode-markdown-toc --># Auth - Specs <!-- /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). 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é. 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). 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`. 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`.
@ -40,27 +44,23 @@ 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`). 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. 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`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux process 4NK. Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`. En parrallèle des flux existant, les hash des requêtes API et de leurs réponses sont signés des clés des parties prenantes pour une vérification de la conformité des données par rapport aux process 4NK.
## 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. 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. 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. 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='Wallet'></a>Wallet
### 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
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) : 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`. 5. Clé privée de dépense mainnet `spend_mainnet`.
6. Clé privée de scan du mainnet `scan_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. 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. 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. ### 9.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
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) 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 : La clé privée `spend_recover` est la clé principale pour forger les identités.
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.
Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Voici les principales étapes : 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. 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 : 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`. 1. Split de `spend_recover`.
2. Chiffrement AES de `Part1`. 2. Chiffrement AES de `Part1`.
3. Mise en cache de `Part1Enc`. 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`. 5. Chiffrement AES de `Part2`.
6. Sharding de `Part2Enc`. 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`. 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.
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. 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`.
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. Dans l'ordre on réalise donc les opérations suivantes pour chaque membres :
6. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 2.
7. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1. 1. Création de `PRDKeyBackup` à destination du membre
11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2. 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` ##### É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. 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`. 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éé. 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. 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. Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.