Introduction à DeepKey
Parce que DeepKey sera si étroitement intégré à tant de hApps et au noyau Holochain, nous voulons qu'il soit aussi stable que possible.
C'est pourquoi nous voulons que son champ d'application soit restreint et clair. Il doit servir deux objectifs principaux :
- Fournir l'infrastructure publique pour la gestion des clés
- Permettre aux utilisateurs d'unifier l'agence sur tous leurs appareils.
Gestion des clés
Dans les systèmes cryptographiques, les clés sont le principal moyen de signaler l'autorité et l'identité. En d'autres termes, vous interprétez quelque chose comme provenant d'un agent s'il l'a signé avec sa clé privée (de signature) et s'il est la bonne personne pour le lire s'il peut le décrypter avec sa clé privée (de cryptage).
Ainsi, d'un point de vue cryptogaphique, clé=agent et la possession d'une clé privée est une agence fonctionnelle.
Cependant, ce n'est pas ainsi que fonctionne le monde des humains. Les gens ne savent pas (encore) gérer les clés de manière responsable. Plusieurs milliards de dollars en crypto-monnaies ont été perdus, parce que les gens ont perdu leurs clés, et qu'ils n'ont aucun moyen de les remplacer.
DeepKey résout ce problème dans l'espace Holochain. Les fonctions de base qu'il doit réaliser sont :
- publier des clés (CreateEntry)
- remplacer les clés (UpdateEntry)
- révoquer les clés (DeleteEntry)
Cas d'utilisation 1 - clés perdues :
Alice utilise un certain nombre de hApps sur son ordinateur portable. Le disque dur de son ordinateur portable est corrompu et elle a besoin d'un moyen déterministe pour régénérer ses clés afin de ne pas perdre l'accès, le contrôle ou la propriété de ses données, son identité, ses devises, etc.
Clés déterministes héritières
Le cas d'utilisation ci-dessus avec Alice montre la nécessité d'avoir un moyen cohérent de générer des clés, de sorte que nous puissions les régénérer en cas de perte.
Pour cela, nous pouvons utiliser une graine maîtresse et enregistrer (de manière privée) les dérivations utilisées pour générer les clés.
Cas d'utilisation 2 - clés volées :
Bob a quelques hApps qu'il exécute sur son téléphone, dont HoloFuel. Son téléphone a été volé, et il veut empêcher quiconque de se faire passer pour lui dans ses hApps ou de dépenser son HoloFuel.
Note : Techniquement, sans DeepKey et avec le Holochain natif, vous pouvez signer une nouvelle clé d'agent dans votre chaîne de sources en utilisant votre ancienne clé. Bien que cela vous permette de remplacer une clé, malheureusement, cela ne résout aucun des cas d'utilisation ci-dessus. Bien au contraire, cela pourrait permettre à la personne qui a volé le téléphone de Bob de remplacer les clés, bloquant ainsi Bob.
Publication des clés
Remplacer ou révoquer des clés
Unification de l'agence à travers les appareils
Le deuxième objectif de DeepKey concerne le fait que les humains disposent de plusieurs appareils qui devraient chacun, pour des raisons de sécurité, avoir des clés cryptographiques différentes. Il faut donc trouver un moyen d'unifier l'agence humaine dans le contexte d'une agence cryptographique multiple.
Cas d'utilisation 3 - confiance en soi sur plusieurs dispositifs :
Aperçu de l'implémentation :
Pour respecter les principes de base de l'infrastructure à clé publique distribuée (DPKI), nous devons pouvoir générer des clés de différents types (révocation, identité, cryptage, signature) à partir de graines, et nous devons être en mesure de générer ces graines à partir de graines primaires, de sorte qu'un agent humain puisse créer des "agents de dispositif" liés, de manière prouvable, sous son contrôle.
Après avoir étudié un certain nombre de cas d'utilisation, y compris l'inscription initiale, la révocation des clés, etc., nous sommes arrivés à la conclusion qu'il était nécessaire de créer un système de génération de clés déterministe hiérarchique, basé sur une graine primaire, à partir de laquelle des graines supplémentaires peuvent être générées, qui sont ensuite utilisées pour générer de nombreuses paires de clés. Cela nous permet, par convention, d'utiliser la première graine générée par la graine primaire comme graine pour les clés de révocation, et les graines suivantes comme graines pour les clés de dispositifs Holochain séparés dont on peut prouver qu'ils sont sous le contrôle du détenteur de la graine primaire.
[WIP] Statut :
Caractéristiques actuelles :
- dpki_init
- créer_un_nouveau_agent
- is_initialized
- Nécessité de suivre le processus de dérivation
- Génération de la clé racine
- Génération de la clé de révocation
- Génération de la clé d'autorisation
- Signature de votre clé d'autorisation avec votre clé de révocation
Que fait l'ADN actuellement :
- Il s'attend à ce que vous initialisiez
- transmettre la clé publique de révocation et une clé d'autorisation signée avec votre clé de révocation.
- Cela enregistre le KeyRootSet
Différence entre dpki et DeepKey
dpki
DPKI (Distributed Public Key Infrastructure) est une bibliothèque centrale holochain qui est utilisée pour créer/générer des clés, à la fois des clés de signature et de chiffrement.
Application DeepKey
Note : Ceci est utilisé pour 'gérer' vos clés d'application holochain.
C'est une application holochain (hApp) qui est utilisée pour gérer les clés de vos applications holochain qui sont installées sur vos conducteurs holochain. DeepKey est une hApp "globale" qui permet à n'importe quelle hApp de faire un pont vers DeepKey pour valider n'importe quelle clé d'agent en vérifiant le statut CRUD du lien de la clé d'agent vers le KeySetRoot de cet agent.
Détails techniques de la mise en œuvre du DPKI
Keystore
Pour chaque instance Holochain DNA, le Conductor maintient un Keystore, qui contient les "secrets" (graines et clés) nécessaires à la signature et au chiffrement cryptographiques. Chacun des secrets du Keystore est associé à une chaîne de caractères qui est un identifiant nécessaire à l'utilisation de ce secret pour une opération cryptographique. Notre implémentation cryptographique est basée sur libsodium, et les graines utilisent leurs notions de contexte et d'index pour les chemins de dérivation des clés. Cette mise en œuvre permet aux développeurs d'ADN d'appeler en toute sécurité les fonctions cryptographiques de WASM qui seront exécutées dans l'espace mémoire sécurisé du conducteur lors du traitement cryptographique.
Le décryptage d'un secret à partir du keystore invoque un service de gestionnaire de passphrase, qui est utilisé pour collecter la passphrase d'un utilisateur final. Ce service est spécifique à l'implémentation. Actuellement, nous avons des implémentations pour la collecte de la phrase de passe en ligne de commande pour une utilisation dans la commande hc keygen, ainsi qu'une implémentation en ligne de commande dans le conducteur.
Mode autonome
Si la configuration du Conductor n'inclut pas de section DPKI, alors le Conductor suppose qu'il est en mode autonome et prend la responsabilité d'ajouter la génération de nouveaux secrets d'agent lorsqu'il reçoit des demandes admin/add_agent via l'interface d'administration. Ce mode est également utilisé par l'outil de ligne de commande hc.
Mode DPKI
Si la configuration du Conductor spécifie une instance DPKI, le Conductor démarre initialement l'instance DPKI et délègue également toutes les demandes admin/add_agent à l'application DPKI pour traitement. Notez que le Conductor suppose que la clé de base de l'agent sera créée par l'application DPKI afin qu'il puisse effectivement créer le fichier keystore de l'agent au nom de l'application DPKI.
Utilisation de Holochain et Holo de DeepKey
Définition du problème :
Comment gérer les différentes clés (c'est-à-dire les clés holochain et holo) sur DeepKey ? Lorsque vous commencez à utiliser Holo ou Holochain, vous avez créé un Root Seed. Dans Holo, il s'agit du sel aléatoire que vous avez créé dans la mine de sel. Et dans Holochain, il s'agit de la graine générée en exécutant hc dpki genroot.
Il y a deux cas pour ce problème.
- Quand quelqu'un utilise déjà hc et veut maintenant utiliser holo. (c'est-à-dire qu'il utilise d'abord Holochain puis Holo).
- Quand mamie qui utilise holo geeks out et utilise holochain.
Cas 1 :
Définition du scénario :
Dans ce scénario, l'utilisateur utilise déjà Holochain localement. Cela signifie qu'il a configuré son instance dpki (DeepKey) et généré toutes les clés requises (Root Seed, Revocation Seed, Authorization Seed).
L'utilisateur décide maintenant d'utiliser Holo.
COMMENT L'UTILISATEUR PEUT-IL RELIER SON COMPTE HOLO À SON COMPTE HOLOCHAIN ?
Solution :
Dans ce cas, avant de nous connecter à Holo, nous créons un Device Seed en utilisant notre root seed localement. Et nous utilisons ce Device Seed comme sel pour nous connecter à Holo (c'est-à-dire que nous n'avons pas besoin d'un sel aléatoire).
- Cela pourrait causer certains problèmes et rendre le processus Holo complexe et peu convivial.
- Nous avons donc besoin d'un processus plus général.
Cas 2 :
Définition du scénario :
Dans ce scénario, l'utilisateur a déjà utilisé un compte Holo. Maintenant, si l'utilisateur veut passer à l'utilisation de Holochain (c.-à-d. exécuter un conducteur holochain localement).
COMMENT L'UTILISATEUR PEUT-IL RELIER SON COMPTE HOLOCHAIN À SON COMPTE HOLO ?
Solution :
En termes simples "Comment gérer les clés lorsqu'un utilisateur a deux graines racines et que nous voulons les gérer comme un seul utilisateur".
Ce n'est pas un problème complexe, même si nous utilisons des clés HD (Hierarchical Deterministic) pour générer des clés, nous n'avons pas construit DeepKey pour correspondre nécessairement à ce modèle.
Pour déterminer si deux appareils sont liés l'un à l'autre, tout ce que nous avons à faire est "Device Handshake". Cela nous donne la possibilité de lier des appareils avec des clés racine différentes ensemble.
Plus d'information au original article "Everything you need to know about DeepKey"
0 Commentaires