Clef dérivé pour émettre dans la blockchain

Nodes
1

A première vu, ce que je propose implique de faire évoluer le protocole.

Actuellement, c’est la même clef privé qui permet d’effectuer des transaction depuis son compte membre de la toile de confiance (et qui reçoi son DU) et qui permet d’émettre des paquets dans la blockchain.

Clef privée dérivée de mon login/mdp (ou assimilé parceque oui, ce n’est pas un login).

Je souhaite pouvoir ne jamais stocker ma clef privée ni ce qui permet de la générer.
Pour cela, si je veux faire un transaction, j’ai besoin de retaper mes secrets pour que soit généré ma clef et pouvoir signer mes transactions.
Jusqu’ici tout va bien.

Je souhaite aussi faire tourner un noeud pour contribuer au fonctionnement du réseau, seulement, je n’ai pas une confiance total en ma compétence à sécuriser mon serveur (ou dans la sécurisation du serveur sur le quel j’héberge mon noeud). Du coup, j’aimerais que mon noeud puisse écrire dans la blockchain sans avoir besoin de stoquer ma clef privé.

Actuellement, pour éviter qu’on puisse monopoliser l’écriture dans la blockchain, les écritures sont restreintes aux membre de la toile de confiance. Je ne propose pas de changer ça.

En revanche, je proposerais bien de signer ces paqué non avec ma clef privé, mais avec une clef dérivée de ma clef privée. Dérivée qui ne permet pas d’effectuer des transactions, mais qui reste vérifiable avec ma clef publique (ou une dérivée) pour valider mes contributions à la blockchain. De cette façon, seule la clef dérivée à besoin d’être stocké sur le serveur, et si celui-ci est compromis, je n’ai pas de risque que mon compte soit vidé.

Et pour gérer le cas ou le serveur est compromis, si les dérivées sont produites dans un ordre déterministe depuis ma clef privé, on peut décidé que d’un qu’une clef dérivé associé à un compte est utilisé pour signer un block, elle invalide les dérivé précédente, comme une révocation automatique.

ça me semble mathématiquement/cryptographiquement faisable, bien que je ne sache pas du tout comment le faire en pratique, et ça me semblerais mieux d’un point de vu sécurité / exposition des secret.

Qu’en pensez vous ?

2 Likes
2

Un simple document “Computer” permettant de créer une clé de calcul liée à l’identité ferait l’affaire en effet :slight_smile:

En terme de clé dérivée, je ne sais pas trop comment ça marche. Peut-être que @Tortue saura nous en dire plus ?

3

Le fait que ce soit la clé personnelle qui calcule les blocs est volontaire : c’est pour éviter la délégation d’écriture qui permettrait un contrôle centralisé de la blockchain.

Ainsi imaginons une organisation qui posséderait un super-calculateur, comme F2Pool. Du fait de la rotation de l’écriture de la blockchain dans Duniter, il suffit que ce calculateur possède 1/3 des clés calculantes pour prendre le contrôle total de l’écriture (en supposant ce calculateur très supérieur à tout nœud calculant qui ne déléguerait pas son écriture).

Or aujourd’hui ce scénario paraît peu probable, car pour ce faire il faut donner sa clé privée de membre à ce calculateur, ce qui signifierai que le pool aurait droit de vie ou de mort sur le compte personnel (donc droit de se faire passer pour l’individu, récupérer sa monnaie produite, certifier à sa place, …). On peut imaginer que peu de personnes souhaitent se placer dans cette position.

Aujourd’hui la délégation n’est pas possible. Et ce que tu proposes est assimilable à une délégation, donc pour l’instant je ne souhaite pas changer le protocole en ce sens.

Je surestime peut-être le danger de la délégation, à vous de me le dire.

5 Likes
4

Oui ce serait dangereux, d’autant plus d’ailleurs que la raison fondamentale pour faire tourner un noeud est de participer et donc d’assurer l’existence même de Ğ1, laquelle repose fondamentalement justement sur les clés privées qui génèrent la monnaie, donc (le calcul de blocs / le DU / les transactions) sont indissociables, sans quoi il n’y a plus d’intérêt personnel à calculer des blocs, alors qu’ajourd’hui cet intérêt du calcul peut s’estimer en Ğ1 [Somme des DUĞ1 personnels générés et générables / N(t)], il est petit, mais pas nul (s’il était nul, alors on pourrait n’avoir personne qui calcule, or ça ne marche pas), et s’en séparer coûterait cher (somme des DU générés et générables).

Ceci étant dit on pourrait éviter de stocker la clé privée sur le DD avec :

$ duniter -decrypt xxxx yyyy start

Où yyyy déchiffre xxxx en la clé privée, uniquement dans la RAM. Ainsi duniter ne stocke rien, et il est bien plus difficile d’aller compromettre la RAM (volatile et difficilement analysable, surtout si les données chiffrées sont groupées au même endroit de la mémoire).

On peut même imaginer un algorithme complexe de déplacement / roulement des données dans la RAM qui rend quasi impossible la récupération même dans le cas où on saurait photographier la RAM, tant il y aurait de données éparses à prendre en compte.

5

Je corrige l’estimation avec :

VIC(x,t) = Estimation de l’intérêt du calcul pour “x” = (Somme des DUĞ1 personnels générables) / N(t)

En enlevant des DUĞ1 générés, puisqu’ils sont probablement déjà sur une autre clé.

Ce qui fait qu’avec la révocation possible à tout instant le risque sera encadré (et l’intérêt du piratage fortement diminué pour tout compte membre bien géré qui enverra ses DUĞ1 à peine générés sur un porte monnaie tiers.

A noter que :

Somme[WoTĞ1,t ->t+40ans] VIC(x,t) = Ğ1[t+40ans] - Ğ1[t] = Ğ1(t+40ans) à un % négligeable près

Où l’on voit donc que in-fine le calcul c’est Ğ1, bien que pour 1 seul membre sa valeur soit petite…

6

Je viens d’imaginer la solution suivante qui crée une sorte de connexion ssh hyper ciblée entre l’instance de Duniter et le possesseur X de la clé privée.

1°) on lance Duniter avec sa clé publique Duniter -encrypt mypubkey
2°) Duniter génère sa propre paire de clés et envoie sa clé publique chiffrée à la clé publique de X (par mail, ou affiché à l’écran, peu importe, c’est chiffré…)
3°) X envoie sous format chiffré sa clé privée sur la clé publique de l’instance de Duniter.
4°) Duniter tourne avec en mémoire une instance spécifique de déchiffrement de la clé privée

Rien n’est stocké nulle part, et chaque lancement d’instance Duniter crée un chiffrement spécifique, qui ne tourne qu’en RAM. Même le possesseur X de la clé privée ne connaît pas la clé privée de l’instance de Duniter ! Il sait juste que Duniter sait lire sa clé au fait qu’il calcule des blocs :slight_smile:

Idéalement il faut penser à bien nettoyer la RAM à chaque opération pour ne garder que le nécessaire.

Ceci rajouté au transfert régulier de ses DU sur un compte tiers + la révocation du compte possible à tout moment, rend le truc quasi incassable et si cassable c’est sans bénéfice…

7

Oui, les possibilités sont infinies … après dans tous les cas on a à un moment donné la clé en RAM.

Déjà qu’elle ne soit qu’en RAM me paraît être un critère important, mais pour aller plus loin il faudrait l’avis de spécialistes de la question “crypto et RAM”.

1 Like
8

Sur stackoverflow ya des tonnes de discussions là dessus. security - how to keep c++ variables in RAM securely? - Stack Overflow

Le truc de base c’est d’utiliser au moins les bons flags pour que la clé en se retrouve pas dans le swap malencontreusement.

9

Encore une idée : un serveur double ! Ainsi si l’un s’arrête, l’autre aussi (ce qui vide la RAM etc…), avec des clés de chiffrement de l’un à l’autre (même exemple type ssh) de sorte que pour pirater le truc il faudrait pirater les 2 en même temps à la microseconde près ! Quasi impossible à cause de la relativité (les temps ne sont jamais 100% synchrones, surtout sur des PC spatialement distants !).

1 Like
10

Vous m’avez l’air d’imaginer des solutions vachement plus compliqué que ce que je proposais, et qui m’ont l’air de moins répondre à la problématique que j’évoquais :confused:

Le fait que ce soit la clé personnelle qui calcule les blocs est volontaire : c’est pour éviter la délégation d’écriture qui permettrait un contrôle centralisé de la blockchain.

Ainsi imaginons une organisation qui posséderait un super-calculateur, comme F2Pool.

Quel intérêt ont les membre à confier à un super-calculateur la création de block ? En faire plus pour recevoir plus de don remuniter ?

Je comprend le risque d’un calculateur centralisé qui monopolise l’écriture sur la blockchain. Je ne comprend pas ce qui pousserais les membres à laisser un calculateur central forger les block à leur place.
J’ai l’impression que la sécurité apporté par la signature associé à un membre de la toile de confiance est suffisente pour rendre très improbable ce cas de figure, même s’il s’agit de signature dérivé. Mais je me trompe peutêtre, si c’est le cas je veux bien quelques explication complémentaire à ce sujet.

la raison fondamentale pour faire tourner un noeud est de participer et donc d’assurer l’existence même de Ğ1, laquelle repose fondamentalement justement sur les clés privées qui génèrent la monnaie, donc (le calcul de blocs / le DU / les transactions) sont indissociables, sans quoi il n’y a plus d’intérêt personnel à calculer des blocs

La raison fondamentale, ok, et sans faire tourner le system pas de DU, ni de possibilité de faire des transaction.
En revanche, je ne vois pas en quoi se baser sur une clef dérivé de la clef privé (clef qui ne permet pas de déterminer la clef privé, mais qui permet de signer avec une signature associable à la clef publique) enlève au fonctionnement et à sa fiabilité.
En revanche, je comprend la réticence à faire tourner un noeud personnel si sa clef privé est exposé à qui pourrais compromettre ce noeud (genre stocké sur un serveur mutualisé, et accessible au root du serveur).

Ne stocker la clef privé qu’en ram, ça me semble compliquer beaucoup la tache au gestionnaire du noeud pour un gain de sécurité certe important, mais inferieur à l’usage d’une clef dérivée, qui elle ne complique pas la gestion du noeud.
Si je doit déchiffrer ma clef en ram à chaque lancement ça veux dire que le reboot de la machine (ou de la VM) n’est plus autonome, il y a besoin d’une intervention humaine du possesseur de la clef à chaque reboot pour relancer le noeud. Pour de l’hébergement à l’ancienne, ou l’admin vénère son uptime, c’est pas nécessairement un problème.
Pour une démocratisation de la chose ou le moindre utilisateur à sa brique, ou un noeud volatile sur son mobile, ça me semble déjà bien plus problématique. Et pour une version docker qui dans certains cas peut avoir des raison d’être rebooter plusieurs fois par minutes, c’est juste impensable (loadbalencing entre plusieurs services dans un pool de conteneur réparti sur plusieurs machines physiques)

Bref, j’aurais besoin de comprendre pourquoi vous semblez si rétissent à ces clef dérivé par rapport au gain qu’elle me semble approté en utilisabilité pour réduire la surface d’exposition du secret de sa clef privé de membre.

En effet, même si on vire ses DU sur un autre compte dès réception, si sa clef privé de membre est compromise, et que du coup on doit la répudier, ça veux dire qu’il faut se faire re-certifier sur un autre compte, ce qui me semble bien plus compliqué à faire que de changé de clef dérivé si seul une clef dérivée ayant des possibilité moindre est répudié.

11

Je pense que la réticence vient du fait que du même coup tu autorises la création de « pools », ce qui n’est pas désirable, et qui est impossible avec le système actuel (qui serait assez fou pour donner sa clé de membre à une entité tierce? Espérons personne dans la TdC). Est-ce que les gens utiliseraient vraiment des pools? Peut-être pas. Probablement pas. Mais si oui, alors on aurait potentiellement un problème qui n’aurait jamais dû exister, et on ne pourra de toute façon pas se battre contre la liberté de ceux voulant les utiliser. En même temps, je comprends bien ton problème de sécurité, je suis moi-même assez peu confortable à l’idée d’avoir ma clé stockée, mais avec les contraintes de ne pas vouloir déléguer (et ce, à tout prix), je ne vois pas comment on peut le résoudre sans faire intervenir l’humain possesseur de la clé à chaque démarrage.

2 Likes
12

Au hasard : « Bonjour je m’appelle D2Pool. Si tu acceptes de me déléguer ta clé d’écriture dans la blockchain, je te paye X unités de telle valeur ».

En soudoyant suffisamment de membres, tu peut mettre un sacré bazar ! Et pas besoin de « bloquer » réellement la blockchain, il suffit d’ennuyer suffisamment les membres pour qu’une perte de confiance s’opère, et que la monnaie soit abandonnée.

Je dis bien suffisamment de membres, c’est-à-dire qu’il ne s’agit pas juste du sous-ensemble des membres calculants, mais bien de l’ensemble de la toile de confiance ! Ça fait un sacré paquet de clients potentiels.

A propos de la « dérivation de clé liée à l’ancienne », d’abord je ne sais pas si c’est possible (apparemment oui dans Monero), mais cela ne change pas le fait qu’il s’agit d’une délégation et qu’elle subit forcément le problème mentionné ci-dessus, malheureusement :confused:

13

A noter que, en fait, ce n’est pas si « grave » de voir sa clé personnelle corrompue si tant est qu’on a bien sauvegardé son document de révocation.

Car finalement, constatant la clé corrompue, on peut immédiatement la révoquer et créer un nouveau compte ! Il nous faudra alors recueillir à nouveau les certifications que les membres nous avaient émises (qui n’auront pas de raison de refuser, constatant la révocation en blockchain).

Certes ce pourrait être pénible et pénalisant en termes de production de monnaie selon le délai. Mais est-ce vraiment gênant ?

3 Likes
14

Ca ne semble pas une mauvaise chose que ça puisse coûter quelque chose… Il faut bien faire attention à sa clé privée en effet, car tout Ğ1 repose sur cette attention de chacun.

15

c’est justement en faisant attention à ma clef privé que je me dit que l’avoir de stocké sur un serveur n’est pas la meilleur idée qui soit…

Mais ok, je comprend la démarche, j’ai juste peur que du coup, ça réduise fortement le nombre de membre qui face tourner un nœud, et que du coup ce soit plus contreproductif en ayant une sécurité technique supérieur qui par induction de comportement humaine amène à une fiabilité global moindre.

Cas concret :
Sacha à monté un nœud hébergé chez aquilenet. Pour que ce nœud puisse participer à la blockchain, il faudrait qu’un membre certifié y soit associé. Sacha ne l’est pas. Moi oui. Du coup faisant confiance à Sacha pour ne pas faire n’importe quoi, je pourrais mettre mettre ma clef pour faire tourner le nœud. Chose qui me semblerais tout à fait acceptable si elle n’était pas stocké sur le serveur… ou qu’elle ne permettais pas de faire de transaction.
Là du coup, je vais attendre de prendre le temps de mettre un nœud héberger chez moi physiquement pour participer au réseau. Chose que je n’ai pas planifié pour l’instant.

16

Il vaut mieux peu de nœuds sûrs que beaucoup de nœuds pas sûrs. Avec 5% des membres ayant un nœuds calculateur c’est déjà largement suffisant :wink:

Je suis de l’avis de @cgeek que la possibilité de délégué son pouvoir d’écriture en blockchain est beaucoup trop dangereux, nous devons nous projeter à long terme, et ne pas oublier que le jours la première économie libre aura de l’ampleur nous aurons des ennemis !

2 Likes
17

C’est un comportement tout à fait possible, oui.

Mais après tout c’est la liberté 0 : la monnaie libre se choisit, et on n’est pas obligé de mettre un nœud pour la faire fonctionner. D’autres le font, peut-être est-ce suffisant, peut-être pas, à chacun de faire selon ce qu’il pense.

En fait dès aujourd’hui tu peux faire fonctionner le nœud en ayant la clé uniquement en mémoire : il faut lancer le nœud avec l’option --keyprompt. Genre :

duniter direct_start --keyprompt
2017-04-05T17:29:39+02:00 - debug: Plugging file system...
2017-04-05T17:29:39+02:00 - debug: Loading conf...
? Modify you keypair? Yes
? Key's salt ***
? Key's password ***

Cela créera la clé uniquement en mémoire. Le nœud fonctionnera avec le temps de la commande.

Après pour conserver le programme lancé, il faudrait peut-être utiliser screen ou programme dans le même genre.

2 Likes
18

merci je viens de redémarrer tout mes nœuds de cette façon et ça fonctionne, c’est top :wink: