Journal Gfsecret, le secret réparti en pratique

• # Merci!

  Posté par Martin Peres (site web personnel) le 04 septembre 2016 à 21:14. Évalué à 8.

  

  Excellent sujet, traité bien comme il faut : Se concentrant sur les concepts et des cas d'utilisation au lieu de passer son temps à parler de la théorie mathématique.

  Ce qui manque maintenant, c'est comment faire intervenir plusieurs acteurs pour partager ces fragments. Le problème, c'est qu'on ne peut pas faire confiance à une entité pour collecter les fragments car elle peut les stocker et se faire passer pour nous plus tard. Du coup, faut forcement utiliser un système tier de confiance.

  Un cas d'utilisation pourrait être la signature de documents produits par un conseil d'administration sans pour autant faire signer le document par chaque membre, ce qui donnerait la liste des signataires. Du coup, le conseil aurait sa propre clé privée et il faudrait la majorité des membres pour signer le document et le rendre valide.

  Si on avait un système tier de confiance, administré par un admin de confiance (limite du système), alors chaque signataire pourrait transmettre une partie de la clé (sur une connexion SSL) et faire confiance au serveur pour ne pas la stocker. Une fois que tous les fragments de clés sont disponibles, alors le document pourrait être signé.

  Sinon, pour simplifier le tout, faudrait empêcher le rejeu des fragments. Du coup, faudrait re-générer une nouvelle clé après chaque signature et re-distribuer des fragments à tout le monde. Mais du coup, maintenant, ca demande d'aussi transmettre la nouvelle clé publique à un service qui loggerait toutes les signatures et donnerait un nouveau fragment à chaque membre à chaque fois.

  Bref, prêt pour pour ce challenge? :D

  • [^] # Re: Merci!

    Posté par gouttegd le 04 septembre 2016 à 22:15. Évalué à 4.

    

    Bref, prêt pour pour ce challenge? :D

    Alors, euh… oui, mais non. Mais alors, pas du tout.

    La problématique que tu soulèves (partage d’un secret entre plusieurs acteurs) est intéressante, mais dépasse largement le cas d’utilisation que j’avais en tête.

    Gfsecret fait ce que je voulais, c’est-à-dire permettre à un utilisateur de partager un secret entre plusieurs supports à sa disposition. J’ai encore quelques idées d’améliorations en tête, mais je ne pense pas aller beaucoup plus loin que ça.

    • [^] # Re: Merci!

      Posté par Martin Peres (site web personnel) le 04 septembre 2016 à 23:15. Évalué à 3.

      

      C'est déjà un cas d'utilisation bien sympa :) Tu pourrais décrire mieux la raison pour laquelle tu fais ca?

      • [^] # Re: Merci!

        Posté par gouttegd le 05 septembre 2016 à 08:51. Évalué à 8.

        

        Tu pourrais décrire mieux la raison pour laquelle tu fais ca?

        En gros, c’est pour concilier deux besoins a priori irréconciliables : m’assurer de ne pas perdre ma clef OpenPGP quoi qu’il arrive¹ (pour ça j’ai besoin de copies de sauvegarde, et pas toutes réunies au même endroit), et limiter le risque de compromission de ladite clef (pour ça le mieux serait qu’il n’en existe qu’une seule et unique copie, de préférence toujours sous mon contrôle — dans ma poche par exemple).

        Le secret réparti est une solution à ce dilemme. Je peux créer de multiples fragments et je n’ai aucune crainte à l’idée d’en laisser quelques-uns dans des endroits non-protégés et hors de ma vue, sachant que ces fragments isolés ne sont d’aucune utilité.

        ---

        ¹ Quand je dis « quoi qu’il arrive », j’entends par là « même si je rentre un jour du boulot et que je découvre que mon appartement a brûlé pendant mon absence » — et je ne plaisante pas, ça fait partie des scénarios auxquels je pense : j’ai la hantise de me retrouver, après une catastrophe imprévisible, dans une situation où j’aurais tous mes backups sous la main… mais sans la possibilité de les lire, parce que comme un con je les ai trop bien protégés et que j’ai perdu les clefs de déchiffrement dans la catastrophe.

        • [^] # Re: Merci!

          Posté par djibb (site web personnel) le 07 septembre 2016 à 09:22. Évalué à 3.

          

          si il y a le feu et que tu en perds un (ou corruption de disque dur), tu perds tout, non ?

          • [^] # Re: Merci!

            Posté par Bernez le 07 septembre 2016 à 10:13. Évalué à 1.

            

            Non. Il a écrit :

            Chaque option -s instruit gfsec-split de créer un fragment et de le stocker à l’adresse spécifiée. L’option -n donne le seuil, c’est-à-dire le nombre de fragments requis pour reconstituer le secret (notez que 2 est la valeur par défaut).

            Donc il peut y avoir bien plus de morceaux de secret que le nombre suffisant pour récupérer ses données. Toute combinaison avec le nombre suffisant de morceaux peut marcher.

          • [^] # Re: Merci!

            Posté par gouttegd le 07 septembre 2016 à 10:22. Évalué à 3.

            

            Non, justement un des intérêts du secret réparti est que la perte d’un fragment est sans conséquences (tant qu’il te reste au moins autant de fragments que le seuil fixé lors du partage).

            Si mon appartement brûle, je perds le fragment stocké sur une clef USB dans le tiroir de mon bureau, mais j’ai toujours le fragment stocké sur mon ordinateur portable, celui stocké sur mon téléphone, et celui stocké sur une clef USB sur mon lieu de travail.

            Pour que je perde tout, il faudrait qu’une catastrophe frappe simultanément mon appartement et mon lieu de travail, à 4 km l’un de l’autre, et moi-même… J’aime bien me préparer au pire, mais pas au point d’imaginer des scénarios à la Michael Bay. :)

• # ssss

  Posté par karteum59 le 05 septembre 2016 à 00:24. Évalué à 7. Dernière modification le 05 septembre 2016 à 00:26.

  

  FYI une autre implémentation (GPLv2) de l'algorithme de Shamir est ssss
  (je manque de temps pour comparer. Si quelqu'un a un avis…)

  • [^] # Re: ssss

    Posté par gouttegd le 05 septembre 2016 à 17:04. Évalué à 5.

    

    je manque de temps pour comparer. Si quelqu'un a un avis…

    Pour commencer, je dirais déjà que ce n’est pas tant à mon projet (celui présenté dans le journal) que ssss doit être comparé, mais plutôt au projet libgfshare.

    Après un bref coup d’œil au code et sauf erreur de ma part, je pense que la différence la plus importante est que ssss semble appliquer l’algorithme de Shamir sur l’intégralité du secret en un seul bloc, raison pour laquelle le programme est limité au partage de secret d’au maximum 128 octets (1024 bits).

    Libgfshare, de son côté, applique l’algorithme octet par octet, et n’a de fait pas de limitation intrinsèque sur la taille du secret à partager.

    Sur un plan plus pratique, le mode de fonctionnement de ssss-combine, où l’utilisateur est supposé rentrer les valeurs des fragments « à la main » à l’invite du programme, me semble beaucoup plus fastidieux et error-prone que le mode de fonctionnement de gfcombine, qui lit les fragments depuis des fichiers.

• # Le nom des programmes

  Posté par Michaël (site web personnel) le 05 septembre 2016 à 07:24. Évalué à 5.

  

  Salut, et bravo pour ton projet! J'ai une remarque à la limite de l'impertinence: c'et mieux d'utiliser le souligné _ que le tiret - dans les noms de programme. Hum, hum, mais pourquoi donc, te demandes-tu? La raison est que le souligné est un caractère valide dans une nom de fonction shell et pas le tiret. Donc par exemple, si dans un script shell qui utilise gfsec_split j'ai envie de tracer les appels à cet outil, simuler des conditions d'erreurs, ou plus généralement faire du “mocking” sur cet outil je peux définir une fonction gfsec_split qui ajoute le comportement souhaité, et ce de façon transparente. Mais si le programme a un tiret dans son nom, cette technique est plus laborieuse à mettre en œuvre.

  Sinon une petite question mathématique: tu utilises des corps finis pour faire ton interpolation de Lagrange? Comment est-ce que tu choisis la caractéristique? Z/pZ ou bien des extensions?

  • [^] # Re: Le nom des programmes

    Posté par gouttegd le 05 septembre 2016 à 09:06. Évalué à 4.

    

    c'et mieux d'utiliser le souligné _ que le tiret - dans les noms de programme

    Je trouve ça moche. (Comment ça, c’est pas une raison valable ?)

    Mais si le programme a un tiret dans son nom, cette technique est plus laborieuse à mettre en œuvre.

    Si c’est réellement important, tu peux utiliser l’option --program-transform-name lors de la configuration des sources :

    $ ./configure --program-transform-name='s/-/_/'

    Ça changera automatiquement le nom des programmes et des pages de manuel associées (mais pas la documentation, évidemment…).

    Sinon une petite question mathématique: tu utilises des corps finis pour faire ton interpolation de Lagrange? Comment est-ce que tu choisis la caractéristique? Z/pZ ou bien des extensions?

    Pour ces questions, le mieux est que je te renvoie à la page de la bibliothèque libgfshare, l’implémentation de la méthode d’Adi Shamir que j’utilise. Mais en gros, oui, c’est un corps fini de cardinal 256.

• # Où est M ?

  Posté par claudex le 05 septembre 2016 à 08:00. Évalué à 8.

  

  Au début, tu parles de n fragments dont m sont nécessaires. Cependant dans la suite tu ne parles que de n. Où donc est passé m (ou c'est le manque de café qui me joue des tours) ?

  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • [^] # Re: Où est M ?

    Posté par gouttegd le 05 septembre 2016 à 08:54. Évalué à 4.

    

    C’est une légère incohérence de ma part, désolé (voilà ce que c’est que de ne pas écrire le paragraphe d’intro le même jour que le reste du journal…).

    Le m de l’introduction (le seuil, le nombre de fragments nécessaires) est devenu n dans le reste du journal.

    À l’occasion, si quelqu’un peut corriger (le plus simple serait d’inverser n et m dans la phrase d’introduction)…

    • [^] # Re: Où est M ?

      Posté par patrick_g (site web personnel) le 05 septembre 2016 à 10:00. Évalué à 5.

      

      C'est fait.

    • [^] # Re: Où est M ?

      Posté par claudex le 05 septembre 2016 à 18:46. Évalué à 5.

      

      C’est une légère incohérence de ma part, désolé

      Ne soit pas désolé, ce n'est pas une si petite faute qui ruine un journal intéressant comme le tiens.

      Le m de l’introduction (le seuil, le nombre de fragments nécessaires) est devenu n dans le reste du journal.

      Du coup, je ne vois pas comment, avec ton outil, faire m fragments donc n nécessaires pour reconstruire la clef.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Où est M ?

        Posté par gouttegd le 05 septembre 2016 à 19:37. Évalué à 6.

        

        Du coup, je ne vois pas comment, avec ton outil, faire m fragments donc n nécessaires pour reconstruire la clef

        Ce n’est peut-être pas assez clairement expliqué.

        Le fait est qu’il n’y a pas d’options pour spécifier m (le nombre de fragments total à générer). C’est le nombre de fois que tu utilises l’option -s (qui spécifie l’emplacement d’un fragment) qui détermine le nombre de fragments.

        Donc, si tu veux générer 5 fragments, tu appeleras gfsec-split avec l’option -s répétée cinq fois.

        Avec le recul, je réalise que cette interface n’est pas des plus logiques. Notamment, -s ne devrait pas être une option (elle n’est pas du tout optionnelle puisqu’il faut obligatoirement la spécifier, et plusieurs fois en plus). Il aurait sans doute été plus logique d’avoir une syntaxe dans ce genre-là :

        $ gfsec-split [options] fichier_à_partager fragment1 fragment2 fragment3...

        qui a l’avantage de bien séparer les arguments optionnels des arguments obligatoires.

        • [^] # Re: Où est M ?

          Posté par claudex le 05 septembre 2016 à 20:07. Évalué à 3.

          

          Merci, c'est beaucoup plus clair.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • [^] # Re: Où est M ?

    Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 06 septembre 2016 à 09:58. Évalué à 2.

    

    m-1 c'est le degré du polynôme dont on connaît des points.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

• # .

  Posté par Sufflope (site web personnel) le 07 septembre 2016 à 16:29. Évalué à 4.

  

  As-tu étudié les bonnes valeurs de (m,n) pour un bon équilibre sécurité contre les accidents vs. sécurité contre les attaques ?

  Car si je ne m'abuse, mettons que j'ai très peur des incendies et que je génère m=5 fragments avec n=2 ; je suis assez peinard à moins qu'Armaggedon soit un documentaire, par contre ça devient "facile" de me voler 2 des 5 fragments et avoir ma clé. Inversement avec n = m-1, plus m est grand plus c'est compliqué de me voler assez de fragments, mais plus je suis vulnérable à un double accident.

  • [^] # Re: .

    Posté par gouttegd le 07 septembre 2016 à 18:02. Évalué à 5. Dernière modification le 07 septembre 2016 à 18:05.

    

    Ça je dirais que c’est à chacun de faire sa propre évaluation. Je peux détailler mes choix mais je ne peux pas les conseiller comme s’ils étaient applicables à tout le monde.

    Pour ma part, j’ai tendance à penser que le risque de perte accidentelle (crash disque, incendie, vol à l’arraché du téléphone — non pas par quelqu’un qui voudrait ma clef, mais juste par quelqu’un qui voudrait le téléphone lui-même —, etc.) est plus vraisemblable que le vol, raison pour laquelle je fais légèrement pencher la balance en faveur de la facilité de reconstitution.

    J’ai donc opté pour m = 4, n = 2.

    ça devient "facile" de me voler 2 des 5 fragments et avoir ma clé.

    Facile, facile… Faut quand même le dire vite. Dans mon cas, si je soupèse les risques qui pèsent sur mes quatre fragments :

    • le fragment stocké sur une clef USB chez moi : hors scénario à la 007 (l’espion monte-en-l’air qui pénètre chez moi en passant par la fenêtre, trouve la clef, en fait une copie, et repart sans laisser de traces), je le considère raisonnablement à l’abri ;
    • le fragment stocké sur une clef USB sur mon lieu de travail : pareil (le lieu de travail en question est un labo de recherche, ce n’est pas le bâtiment le mieux sécurisé du monde mais on n’y rentre quand même pas comme ça) ;
    • le fragment stocké sur mon téléphone portable : le stockage est chiffré, il faut donc non seulement me subtiliser le téléphone mais aussi le déverouiller (je ne dis pas que c’est impossible, mais il faut quand même y mettre les moyens, demandez au FBI ce qu’ils en pensent…) ;
    • le fragment stocké sur mon ordinateur portable : pareil, disque dur chiffré, il faut soit mettre la main dessus à chaud, soit obtenir ma phrase de passe, soit casser le chiffrement.

    J’estime pour ma part que c’est amplement suffisant. Ou plutôt, j’estime que si ils sont après moi, ils m’attaqueront sur un point plus faible, ce n’est pas ma clef OpenPGP fragmentée qui me perdra.

    (Sur ce dernier point, et puisqu’il est question d’Adi Shamir dans le journal, il a aussi énoncé ce qui est devenu la « loi de Shamir » : “Cryptography is bypassed, not penetrated” — l’adversaire ne s’en prend jamais à la cryptographie de front, il la contourne. Au grand dam des crypto-nerds qui s’imaginent que la toute puissante crypto va automagiquement les mettre à l’abri de tout — mais seulement si vous avez une grosse clef, c’est très important d’avoir une grosse clef.)

• # Man in the middle

  Posté par n0wic le 11 octobre 2016 à 00:16. Évalué à -9.

  

  C'est bien pationnant ton truc mais il y a un truc qui ne va pas.

  Dans ton application tu utilises différents périphériques amovibles mais tu n'assures aucun mécanisme d'authentification. Donc cette technique est sensible à une attaque de type man in the middle qui pourra faire rejouer tes fragments et reconstituer la clé s'il accède à la machine.

  Cette faille est critique dans la mesure où il est simple de corrompre ansi ta clé.

  Dans l'état actuel des choses de la description de ton implémentation tu ne peux pas bloquer/controler la génération de fragments.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.