Forum Linux.général Un backdoor pour son accès SSH

Posté par  (site web personnel) .
Étiquettes : aucune
0
1
avr.
2008
Bonjour,

voilà j'me posais une question... Actuellement j'ai pas accès à ma clé usb en mission, du coup j'ai pas accès à ma clé privée RSA 4096 bits (ouai je sais ca sert à rien aussi grand, mais ca fait bien devant les filles ;)

Je pensais la stocker sur un site web avec un nom à la con (genre KiKouLOL.ziP) et j'aurai pris soin avant de changer 1 ou 2 caractères de la clé histoire de la rendre non compatible avec sa clé publique dans le cas improbable où quelqu'un la trouve.

J'ai testé ça marche plutôt bien :)

Ma question est plutôt, si on a la clé dans sa totalité, mais qu'un caractère a été changé (ou 2, ou 3, etc), est il possible de les deviner (par un principe mathématique genre somme qui mettrait en avant les caractère non probable après une génération de clé). Le tout étant de savoir si donner ma clé en pature, même modifiée, est suicidaire ou pas)

Merci :)



Sinon, que pensez vous d'un système basé sur 12 clés privés, une par heure, avec un script qui reload la config ssh toutes les heures pour changer sa clé publique ?


cho7, mode parano en ce moment ^^
  • # Et la passphrase ?

    Posté par  (site web personnel) . Évalué à 5.

    De toute façon, si tu es parano, tu as bien évidemment choisi au moment de générer ta clé une passphrase longue et pleine de caractères spéciaux. Donc même si quelqu'un trouve ta clé USB, il ne pourra rien en faire.

    Avec l'utilisation de ssh-agent, c'est quand même bien plus simple que de t'amuser à modifier quelques caractères de ta clé chaque fois que tu veux l'utiliser.
    • [^] # Re: Et la passphrase ?

      Posté par  (site web personnel) . Évalué à 2.

      Bien sûr, ma passphrase fait 20 caractères, dont des espaces, des apostrophes, des majuscules... mais surtout pas d'accents ! J'ai déjà donné dans les problèmes d'encodages rendant un mdp valide sous X et pas en mode console (ou vice versa) :-/

      Mais c'était juste par curiosité en fait, ma question... Je voulais savoir si c'était envisageable (ou bien totalement contradictoire du point de vue "sécurité") de stocker sa clé privée, légèrement modifiée, sur un site internet (qui peut être protégé ou non) dans le cas où on ne peut pas utiliser (ou bien on l'a oubliée) sa clé usb.
  • # Quitte à être parano...

    Posté par  . Évalué à 4.

    autant mémoriser la clef privée par cœur...

    Sinon, un truc con: ça s'appelle mot de passe... c'est moins long à mémoriser mais ça permet d'avoir une sécurité raisonnable si c'est fait intelligemment.
    • [^] # Re: Quitte à être parano...

      Posté par  (site web personnel) . Évalué à 1.

      Effectivement, c'est quoi l'objectif de tout ça ?

      Tu dois avoir des choses précieuses à protéger avec la mise en place de tout ceci. Combien de To de films et de fichiers audio ?!

      Bref, un mot de passe correct te suffirait amplement, comme le dit ragoutoutou.

      Alexandre COLLIGNON

      • [^] # Re: Quitte à être parano...

        Posté par  (site web personnel) . Évalué à 1.

        Mince, ce que vous êtes terre à terre sur linuxfr...

        Où sont passés les geeks et leurs lubies ? :+)
        • [^] # Re: Quitte à être parano...

          Posté par  . Évalué à 1.

          Baff... Normalement la passphrase fait l'affaire mais si tu est vraiment parano, t'as qu'a chiffrer ton archive zip en AES puis en Serpent puis en Twofish avec trois clés différentes. Normalement, ça de devrait aller
  • # Ce n'est pas une bonne idée

    Posté par  . Évalué à 3.

    Si quatre caractères (8 bits consécutifs par exemple, ou 4 si c'est en hexadécimal) ont été changés à des places aléatoires, pour bruteforcer il suffit d'essayer
    binomial(4096, 4) (places) * (4*2^8) (nombre de caractères possibles) soit environ 2^52 possibilités. Ceci n'offre pas une sécurité très importante (surtout si tu es parano ;-) et utilises des clefs de 4096 bits), un ordinateur moyen (2 GHz soit 2^31 opérations par secondes) pourrait y arriver en plus ou moins 2^21 secondes, soit à peu près 24 jours. (en comptant large, un test de clef par cycle ; à noter que ce nombre est à diviser par le nombre de processeurs disponibles : un supercalculateur avec 10 000 processeurs mettra moins d'une demi-heure).

    Ensuite étant donné la structure très forte d'une clef privée RSA, il y a de bonnes chances pour qu'on puisse réduire très rapidement le nombre de possibilités à tester, et donc affaiblir encore plus la sécurité de la chose.

    La meilleure chose à faire est de faire confiance aux outils existants, et d'utiliser des phrases de passes (ou un poème épique de passe comme Bruce Schneier).
    • [^] # Re: Ce n'est pas une bonne idée

      Posté par  (site web personnel) . Évalué à 1.

      > en comptant large, un test de clef par cycle

      Ca me semble plutôt de l'impensable que du large. Il faudrait regarder l'algorithme nécessaire à tester la clef, mais un processeur ne fait pas grand chose de très complexe en un seul cycle...
      • [^] # Re: Ce n'est pas une bonne idée

        Posté par  . Évalué à 2.

        oui évidemment, c'est donc une approximation et le cas le pire qui puisse arriver.

        Cela dit, tester si un truc est une clef privée RSA peut sans aucun doute se ramener à quelques dizaines de cycles en moyenne.
        Quand on réussit à pipeliner tout ça, en régime permanent on peut descendre encore...
  • # Merci

    Posté par  (site web personnel) . Évalué à 1.

    On s'est mal compris je crois. J'ai aussi une passphrase dans ma clé privée ! Et comme dit plus haut, elle fait 20 caractères, et elle est plutôt tordue :)

    Maintenant, ma question était vraiment de la curiosité, point barre.
    Donc d'après la réponse de khivapia, je comprend que laisser trainer ma clé altérée de 1 caractère, revient à la révéler complètement (en gros). Donc après, il ne reste que la protection de la passphrase à déjouer (ce qui en soit me parait déjà pas mal !)

    Merci à lui pour cette explication, même si j'ai pas tout compris :)
    • [^] # Re: Merci

      Posté par  (site web personnel) . Évalué à 2.

      Parcontre, son raisonnement (que je viens de relire) implique deux choses :
      1/ Savoir précisément combien de caractères ont été altérés
      2/ Savoir que des caractères ont été altérés !

      Et ça, si je le dis pas, ça aide pas à trouver ma clé.

      Ensuite, il reste la passphrase à trouver, tout de même...

      Donc avec un peu de chance, l'assaillant va tenter de trouver la passphrase de ma clé privée traffiquée (car il ne sait pas a priori qu'elle est fausse), ce qui va lui faire perdre du temps !

      Sinon, ma question était en gros de savoir si modifier 4 caractères pouvait se repérer (d'un point de vue mathématique)
      • [^] # Re: Merci

        Posté par  . Évalué à 2.

        ça te sert à quoi d'utiliser une clé RSA qui semble plus te poser problème qu'autre chose, alors qu'un mot de passe assez long serait suffisant au point de vue sécurité ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Merci

          Posté par  (site web personnel) . Évalué à 3.

          C'est avant tout pour le plaisir intellectuel. J'suis une quiche en maths, en crypto, toussa toussa, mais les clés publiques/privées, ca m'a toujours fasciné

          Sinon, concernant mes "problèmes", je n'en ai pas pour tout le restant de l'année. C'est la première fois que je me retrouvais dans une boite où je ne pouvais pas plugger ma clé usb...

          Bref, sinon je suis un linuxien de base, çad un peu geek sur les bords, qui aime ce qui est inutile, rien de choquant non ?
      • [^] # Re: Merci

        Posté par  . Évalué à 4.

        En effet. Ceci s'appelle de la sécurité par l'obscurité : si la méthode d'altération est inconnue elle peut faire perdre du temps, en revanche une fois qu'elle est dévoilée elle risque d'apporter peu de sécurité en plus.

        À noter que dans ce cas là, si on sait que des caractères ont été altérés, on peut se douter qu'ils sont en nombre faible/intuitifs à retenir (sinon autant retenir carrément toute la clef privée ;-) ). On peut alors imaginer des attaques similaires à celles par dictionnaire sur les mots de passe (type John the Ripper), par exemple essayer les altérations de 1, 2, ... caractères, essayer un caractère altéré sur 100, etc. etc.
        • [^] # Re: Merci

          Posté par  (site web personnel) . Évalué à 1.

          Oui admettons qu'il sait que 3 caractères ont été altérés par exemple, mais si ton programme bruteforce ma clé caractère par caractère, comment peut il s'assurer qu'il a isolé les 3 "bons" caractères tant qu'il ne connait pas la passphrase pour valider sa réussite ?

          Ca fait un peu serpent qui se mord la queue, non ?
          • [^] # Re: Merci

            Posté par  . Évalué à 3.

            Certes, la sécurité de la passphrase reste à peu près inchangée (mais on pourrait imaginer des schémas où le fait d'ajouter une opération de chiffrement par-dessus la précédente fait tomber la sécurité de l'ensemble, ce n'est pas une loi générale).

            Le truc c'est plutôt de se dire "Qu'est-ce que 3 (ou x) caractères de modifiés apportent comme sécurité en plus de la phrase de passe ?"
            La réponse est "pas grand-chose en fait".

            En fait ça multiplie le temps de calcul nécessaire à casser la phrase de passe par le temps passé à tester tous les caractères.

            Mais d'une manière générale en crypto, on considèrera que si on peut casser la phrase de passe en un temps raisonnable, alors le fait de modifier n caractères ne va pas augmenter suffisamment le temps nécessaire à casser la combinaison des deux pour pouvoir être considéré comme sûr.

            Bon, c'est sûr que s'il faut 2^50 opérations pour casser la passphrase et 2^50 pour trouver les caractères s'il n'y avait pas de passphrase, alors il faudrait 2^100 opérations pour le tout et ce serait acceptable.
            Mais s'il faut seulement 2^6 opérations pour trouver les caractères, le temps total par rapport à trouver la passphrase directement est multiplié par 2^6 = 32, et la sécurité apportée n'est pas suffisamment importante pour valoir le coup. En effet, si quelqu'un attache beaucoup d'importance à ta clef secrète parce que tu as tout un tas de documents secrets qui l'intéressent/émet des signatures auxquelles beaucoup de monde attache de l'importance, il se permettra d'attendre le temps qu'il faudra (au lieu d'un jour, un mois, au lieu d'un mois, trois ans) pour trouver ta clef.
          • [^] # Re: Merci

            Posté par  (site web personnel) . Évalué à 2.

            Déjà utilise DSA au lieu de RSA, c'est plus secure :)

            "La première sécurité est la liberté"

            • [^] # Re: Merci

              Posté par  (site web personnel) . Évalué à 1.

              Beh justement, c'est pas si évident. Ya des tonnes de threads sur le sujet, et j'avoue qu'à l'époque je n'avais pas sû me décider :)

              A taille de clé égale, j'avais lu que RSA était plus performant. Et qu'une clé RSA de 2096bits ou plus n'était pas cassable dans un avenir proche. Comme quoi...
              • [^] # Re: Merci

                Posté par  (site web personnel) . Évalué à 2.

                Performant rapide tu veux dire ?

                Moi, j'avais entendu que si beaucoup d'échange crypté (en mode clef public/privé, pas avec une clef de session) ont lieu, on peut plus facilement reconstruire la clef avec RSA qu'avec DSA.

                "La première sécurité est la liberté"

              • [^] # Re: Merci

                Posté par  . Évalué à 2.

                Selon la DCSSI http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecan(...)
                les problèmes de factorisation et de logarithme discret dans Z/pZ semblent comparables en termes de complexité, c'est-à-dire que RSA et DSA auraient sensiblement la même sécurité.

                Cela dit, le DSA est très dépendant de son générateur aléatoire.
        • [^] # Re: Merci

          Posté par  . Évalué à 1.

          Je plussoie ardemment. Il y a peu de principes surs en sécurité informatique, mais le danger de "security par obscurity" en est un. Quand on fait un audit d'un système, on considère que l'ensemble des codes sources, méthodes, connaissances des utilisateurs sont disponibles à l'attaquant.

          Tant qu'à être parano, on peut aussi utiliser un périphérique crypto qui protège par emprunte digitale une clef protégée par phrase de passe. Ca ça a peu de chance d'être cassé :-) Par contre je n'ai aucune idée de l'état du support de ce genre de périphériques par Linux.
          • [^] # Re: Merci

            Posté par  . Évalué à 3.

            Il y a eu une dépêche de Patrick_g il y a quelques mois sur le sujet :
            https://linuxfr.org//2007/11/22/23395.html

            À noter qu'une empreinte digitale se trouvant très facilement (ne serait-ce que sur le clavier ;-) ), étant clonable de façon raisonnablement accessible, et surtout n'étant pas révocable, elle ne servira pas à protéger directement un secret mais servira plutôt de login dans le processus d'authentification permettant d'accéder à ce secret.
            • [^] # Re: Merci

              Posté par  . Évalué à 2.

              Yep, l'emprunte digitale, c'est du pipeau...

              Dans les méthodes d'authentication, il y a 3 familles:

              - le "j'ai"
              - le "je sais"
              - le "je suis"

              et de ces trois là, le "je suis" est généralement le moins efficace vu que la majorité des méthodes pour tester le je suis sont falsifiables et tout particulièrement l'emprunte digitale.

              Un système relativement sûr reste l'authentication par digipass car elle combine le "j'ai" (le digipass) et le "je sais" (le code pour obtenir la clef du digipass).

              Maintenant, il faut bien constater, surtout au regard de toute cette discussion au dessus, que la sécurité est en général plus un prétexte masturbatoire ou de compétition pour savoir qui a la plus grosse qu'une véritable préoccupation rationnelle.
              • [^] # Re: Merci

                Posté par  (site web personnel) . Évalué à 0.

                Maintenant, il faut bien constater, surtout au regard de toute cette discussion au dessus, que la sécurité est en général plus un prétexte masturbatoire ou de compétition pour savoir qui a la plus grosse qu'une véritable préoccupation rationnelle.

                Presque. T'as oublié le pretexte ludique. Je m'inquiète vraiment, ya vraiment plus de geek sur linuxfr, ces gars qui font des trucs inutiles, possédant des montres binaires, toussa toussa ? :)
                • [^] # Re: Merci

                  Posté par  . Évalué à 2.

                  En fait on plaisante rarement quand on parle de sécurité ;-)
                  • [^] # Re: Merci

                    Posté par  . Évalué à 2.

                    si, si... mais faut bosser dans une équipe de sécurité pour s'en rendre compte...

                    Et puis bon, il y a assez de conneries sur la sécurité sur internet pour ne pas apporter sa pièce à l'édifice...

Suivre le flux des commentaires

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