• Une idée naïve pour sécuriser des échanges

    Le NIH est stigmatisé, surtout en matière de sécurité, et je suis convaincu que c'est à juste titre ; je vais tout de même tenter ma propre idée dont l'implémentation me rendrait grand service. J'ai bien veillé à ne pas inventer de nouvel algorithme, et me fonde sur le seul que je comprenne : XOR.

    capture d'écran du site www.nih.gov

    XOR exige que la clef, jetable, soit aussi longue que les données échangées, et ceci est désormais possible grâce à la baisse du prix des supports amovibles : les clefs USB de 8 voire 64 Go sont aujourd'hui abordables, et nul besoin d'en posséder de rapides (elles doivent être juste aussi rapides que le réseau).

    Il reste donc à déterminer comment nous pourrions utiliser cette merveille qu'est XOR.

    Prérequis

    Contact physique régulier entre les administrateurs des systèmes pour partager leurs clefs.

    Format et fabrication de la clef

    Dans le principe, nous avons une énorme clef de chiffrement partagée entre deux hôtes, qui sera consommée au fur et à mesure de la transmission. Nous devons maintenir à jour l'information sur les parties de la clef de chiffrement non encore consommées.

    Un moyen simple de résoudre cette difficulté (avec un peu de perte) est de découper la grosse clef en de nombreux fichiers au nom aléatoire, plus exactement un UUID correspondant à la session de génération de clef suivi d'un nombre aléatoire suffisamment long.

    Exemple : fd064ce5-8f97-53d9-a286-ba94ca7f5c1f.bdcc14797f8168c14e17535ca2a1dc668331366f6826d9c278d173bcac1c

    Ensuite, il faut mettre les pairs d'accord sur le morceau qu'ils vont utiliser, et on en profite pour le supprimer du support sitôt qu'il a été chargé en mémoire : tous les morceaux encore présents sur le support sont donc valides.

    Faille possible : l'affaiblissement de clef dû à un système non contrôlé, par exemple un /dev/urandom qui utiliserait en fait un Mersenne avec une graine connue… ou rootkit, ou fuite des précieuses données… enfin bref.

    X-OR existe depuis très longtemps

    Protocole de choix de la clef et début de l'échange

    Il faut implémenter un protocole de sélection résistant au deni de service en évitant de charger en mémoire (et donc détruire) une clef que ne possède pas l'hôte d'en face. Le protocole d'échange pourrait être le suivant (avec arrêt de la transmission à chaque erreur) :

    1. A -> B « As-tu la clef 1ca9f03a-068b-5027-8cce-862662103da4.3ea17d2760421eac4f042dc8025a5ec3ee4e76f24d4a9ab ?»
    2. B peut répondre
      • « Oui, as-tu la clef 1ca9f03a-068b-5027-8cce-862662103da4.83b6c51b97b85c2c665d747fa1dbadb63a22467ccb63bcbfb ? »
      • « Non » - À ce moment, A jette la clef essayée et peut faire un nouvel essai.
    3. A et B chargent leurs clefs en mémoire et les retirent du support.
    4. A <trafic encodé avec l'une des clefs> -> B+ B <trafic encodé avec l'autre clef> -> A

    Lorsque l'un des pairs arrive au bout de sa clef de codage, il propose une autre clef. Il peut-être opportun que les hôtes se précisent l'un à l'autre les UUID des clefs qu'ils possèdent (éventuellement plusieurs UUID, car le pseudo hasard étant long à obtenir, on peut vouloir utiliser plusieurs machines pour le générer, ou le générer en plusieurs sessions).

    Déni de service possible : si lors du 4., un intermédiaire perturbe l'échange et rend le trafic indécodable, on peut être amené à gaspiller des clefs, il vaudrait mieux changer de route.

    Une idée naïve pour sécuriser des échanges

    Exemples d'utilisation qui m'intéressent

    SSH

    La durée de vie d'une clef XOR de 8Go sur un lien SSH utilisé pour le shell (et pas pour le f2f ;-) me semble quasiment infinie.

    VPN

    OpenVPN est pratique, mais moins fiable que la présente solution, qui, de plus, ne peut contenir de failles de sécurité autres que déni de service.

    Réseau local

    Je pourrais remplir des clefs USB avec des clefs partagées entre les machines du réseau local deux à deux : facile de sécuriser le wifi !

    Problèmes à résoudre

    Coder, implémenter la chose en électronique (c'est pour une fois un protocole de sécurité très peu exigeant en CPU et électricité).

    J'aimerais idéalement pouvoir implémenter un matériel électronique simple et assez peu cher, qui contiendrait une source de hasard, sur lequel on brancherait les deux clefs, et qui les remplirait. Éventuellement, le même matériel ou un autre servirait d'intermédiaire entre l'ordinateur et la mémoire de masse pour essayer de garantir que la lecture d'un fichier implique sa suppression.

    Taille optimale des morceaux de clef de chiffrement. Peut-être disposer de petits morceaux et de très gros, mais dans un premier temps, une seule taille, qui doit tenir dans un read().

    « Attention, raccourci dangereuxsncf et travelling salesman »

    Tags Tags : , , ,
  • Commentaires

    Aucun commentaire pour le moment

    Suivre le flux RSS des commentaires


    Ajouter un commentaire

    Nom / Pseudo :

    E-mail (facultatif) :

    Site Web (facultatif) :

    Commentaire :