Journal Gfsecret, le secret réparti en pratique

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
53
4
sept.
2016

Sommaire

Jour’Nal,

Dans un précédent journal sur la gestion des clefs OpenPGP, je mentionnais en passant la possibilité « d’utiliser une méthode de secret réparti pour partager la clef privée en m fragments, dont n sont nécessaires pour reconstituer la clef complète ».

J’aimerais revenir sur cette méthode pour présenter les outils que j’ai développé pour la mettre en œuvre.

Un peu de théorie : le partage de secret d’Adi Shamir

Il existe plusieurs méthodes de partage de secret, celle qui nous intéresse ici est celle décrite par Adi Shamir en 1979.

Cette méthode est basée sur l’idée que n points sont nécessaires pour définir de manière unique une courbe correspondant à un polynôme de degré n−1.

Par exemple, imaginons que l’on veuille partager une valeur secrète de telle sorte que deux fragments au moins seront nécessaires pour la reconstituer (n = 2). Nous traçons une droite de la forme f(x) = ax + b, où a est une valeur choisie aléatoirement, et b (l’ordonnée à l’origine, c’est-à-dire là où la droite coupe l’axe Y) est la valeur secrète à partager. Un fragment du secret est représenté par les coordonnées d’un point sur cette droite, autrement dit un couple x, f(x).

Si vous n’avez les coordonnées que d’un seul point, vous n’avez aucun moyen de retracer la droite (puisque par ce point peuvent passer une infinité de droites, et vous ne savez pas quelle est la « bonne ») et donc de savoir à quel endroit à coupe l’axe Y.

En revanche, dès l’instant où vous connaissez (au moins) deux points, vous avez tout ce qu’il vous faut pour retracer la droite (deux points suffisent à définir une droite unique). Il est alors trivial de déduire l’ordonnée à l’origine.

Et si on veut que trois fragments soient nécessaires pour reconstituer le secret ? Le principe est le même, mais cette fois-ci, on va tracer une courbe de la forme f(x) = ax² + bx + c, avec a et b choisis aléatoirement, et c (toujours l’ordonnée à l’origine) est la valeur secrète. Maintenant, deux points ne suffisent plus à retracer la courbe, parce que par deux points passent une infinité de paraboles, il faut nécessairement trois points pour définir une parabole unique.

La méthode est aisément généralisable et on peut ainsi partager un secret de telle sorte que n fragments soient nécessaires à sa reconstruction, en utilisant un polynôme de degré n−1.

Gfsecret, une mise en pratique

(L’auto-promotion commence ici.)

Gfsecret est le projet que j’ai initié pour faciliter la mise en œuvre du partage de secret. Il est construit autour de libgfshare, une implémentation de l’algorithme d’Adi Shamir par Daniel Silverstone.

Libgfshare fournit déjà deux outils permettant de partager un secret (gfsplit) et de le reconstituer (gfcombine).

Les deux outils supplémentaires que je propose vont un tout petit peu plus loin en prenant en charge la distribution des fragments sur des supports externes amovibles. Concrètement, ils permettent d’éviter d’avoir à déplacer manuellement les fragments vers des supports amovibles (lors du partage) et à les rapatrier depuis les mêmes supports (lors de la reconstitution).

Pour illustrer son utilisation, je vais prendre le cas de ma propre clef primaire OpenPGP.

Ce qui suit n’est valable que si vous utilisez GnuPG 2.1, qui stocke chaque clef privée dans un fichier séparé. Les versions précédentes stockent toutes les clefs privées dans un fichier unique (~/.gnupg/secring.gpg), et ne permettent pas d’utiliser la méthode décrite ici pour supprimer une seule clef.

Partage

Je commence par obtenir le keygrip de ma clef primaire :

$ gpg2 --list-secret-keys --with-keygrip
/home/alice/.gnupg/pubring.kbx
------------------------------
sec   rsa4096 2015-06-05 [SC] [expires: 2021-05-17]
      318D1F0158F237EB64797C0C5C5CE0D82EADF7D4
      Keygrip = DE389DE3BC42741B44FCB2B56D4C281B7866BA8F
uid           [ultimate] Alice <alice@example.org>
ssb   rsa2048 2015-08-18 [A]
      Keygrip = EFEC66DC7A6BC49CBCFA5B76398BB827B20A5689

La clef primaire a pour keygrip DE389DE3[…]7866BA8F. On peut donc la trouver dans le fichier ~/.gnupg/private-keys-v1.d/DE389DE3[…]7866BA8F.key ; c’est ce fichier que je veux partager sur plusieurs supports.

Je branche mes supports amovibles et je lance l’outil gfsec-split avec l’option -l pour obtenir une liste des supports disponibles :

$ gfsec-split -l
file://  Local filesystem
label://USBKEY  GIO volume
mtp://RF2GB6X704P  Samsung Galaxy A3

Gfsec-split me propose donc trois supports : le disque dur local, une clef USB avec le label USBKEY, et un smartphone Android (vu comme un périphérique MTP, ce qui à ma connaissance est le cas de tous les Android à partir de la version 4 — les versions précédentes étaient vues comme des périphériques USB mass storage, autrement dit comme des clefs USB) avec le numéro de série RF2GB6X704P.

Je relance à présent gfsec-split en lui demandant de partager la clef secrète identifiée ci-dessus en trois fragments, un pour chacun des supports disponibles :

$ gfsec-split \
  -c /home/alice/.config/gfsecret/master.conf \
  -s file:///home/alice/.local/share/gfsecret/master-key \
  -s label://DATAKEY/master-key \
  -s mtp://RF8GB1X407P/Documents/master-key \
  -n 2 \
  /home/alice/.gnupg/private-keys-v1.d/DE389DE3[…]7866BA8F.key

L’option -c indique le nom du fichier de configuration à créer. Ce fichier sera utilisé par l’outil gfsec-use pour reconstituer le secret partagé (voir plus bas). (Par défaut, gfsec-split génère un fichier de configuration dans $XDG_CONFIG_HOME/gfsecret avec le même nom que le fichier à partager, mais ce n’est pas très pratique dans le cas d’une clef GnuPG dont le nom est un keygrip de 40 caractères.)

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).

Enfin, vient le chemin vers le fichier à partager. Ce fichier est automatiquement supprimé si le partage s’est déroulé correctement (utilisez l’option -k pour ne pas supprimer le fichier quoi qu’il arrive).

On peut vérifier auprès de GnuPG que la clef primaire secrète n’est plus disponible :

$ gpg2 --list-secret-keys
/home/alice/.gnupg/pubring.kbx
------------------------------
sec#  rsa4096 2015-06-05 [SC] [expires: 2021-05-17]
      318D1F0158F237EB64797C0C5C5CE0D82EADF7D4
uid           [ultimate] Alice <alice@example.org>
ssb   rsa2048 2015-08-18 [A]

(Notez le symbole # après le mot-clé sec, qui indique l’absence de la clef privée correspondante.)

Reconstitution

Passons maintenant à la reconstitution, possible avec l’outil gfsec-use. Celui-ci s’utilise avec un fichier de configuration qui décrit l’emplacement des fragments, le nombre minimal de fragments requis et le nom du fichier original à reconstituer. Un tel fichier est automatiquement généré par gfsec-split lors du partage.

Il me suffit alors d’appeler gfsec-use en lui précisant le nom du fichier de configuration à utiliser (ou le chemin complet, si le fichier est situé ailleurs que dans $XDG_CONFIG_HOME/gfsecret) :

$ gfsec-use -c master
Found share data in file:///home/alice/.local/share/gfsecret/master-key.070
gfsec-use: Cannot reconstitute the secret: Not enough shares available

Ici, la reconstitution a échoué parce que seul le fragment stocké sur le disque dur local a été trouvé. Si je connecte un des deux supports amovibles (disons la clef USB) avant de relancer la commande :

$ gfsec-use -c master
Found share data in file:///home/alice/.local/share/gfsecret/master-key.070
Found share data in label://DATAKEY/master-key.134
gfsec>

Cette fois‐ci, la reconstitution a réussi et gfsec-use me laisse dans un nouveau shell dans lequel je peux faire ce que j’ai besoin de faire avec mon secret reconstitué. Sitôt que je quitte ce shell, le fichier reconstitué est automatiquement supprimé à nouveau :

gfec> ^D
Removing secret.

Il est possible de spécifier une commande arbitraire à exécuter plutôt qu’un shell. Par exemple, si je veux reconstituer ma clef primaire le temps de signer la clef de Bob, je peux directement lancer l’éditeur de clefs de GnuPG :

$ gfsec-use -c master gpg2 --edit-key bob@example.com
Found share data in file:///home/alice/.local/share/gfsecret/master-key.070
Found share data in label://DATAKEY/master-key.134

pub  rsa2048/21321A16B4902A74
     created: 2015-06-05  expires: never       usage: SC  
     trust: full          validity: unknown
sub  rsa2048/E32EF7E899E238AD
     created: 2015-06-05  expires: never       usage: E   
[ unknown] (1). Bob du 92 <bob92@provider.example>
[ unknown] (2)  Robert <bob@example.com>

gpg>

La clef primaire reconstituée sera automatiquement supprimée sitôt que je quitterai l’éditeur.

Talk is cheap. Show me the code.

Le code est distribué sous licence GPL v3. Évidemment, il est fourni sans le moindre garantie — gardez ça à l’esprit, si vous voulez vous en servir sur votre porte‐feuille de bitcoins (pensez aussi à l’option -k)…

  • # Merci!

    Posté par  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . Évalué à 5.

        C'est fait.

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

        Posté par  . É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  (site web personnel) . É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  . É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  (site web personnel) . Évalué à 2.

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

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # .

    Posté par  (site web personnel) . É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  (site web personnel) . É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  . É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.