Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Linux.general : Un backdoor pour son accès SSH

Posté par cho7 (page perso, ) le 01 avril 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 ^^

> Lire le message (26 commentaires, moyenne: 2).  

Vous avez demandé le commentaire #918634.

Merci

Posté par cho7 (page perso, ) le 01/04/2008 à 15:06. (lien). É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 :)

--
le python, c'est bon
  • [^]Re: Merci

    Posté par cho7 (page perso, ) le 01/04/2008 à 15:11. (lien). É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)

    --
    le python, c'est bon
    • [^]Re: Merci

      Posté par Farvardin (page perso, ) le 01/04/2008 à 17:40. (lien). É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é ?

      --
      Tous ensemble contre l'esclavitude des logiciels privateurs !
      • [^]Re: Merci

        Posté par cho7 (page perso, ) le 01/04/2008 à 19:44. (lien). É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 ?

        --
        le python, c'est bon

      [^]Re: Merci

      Posté par khivapia () le 01/04/2008 à 20:11. (lien). É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 cho7 (page perso, ) le 01/04/2008 à 21:00. (lien). É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 ?

        --
        le python, c'est bon
        • [^]Re: Merci

          Posté par khivapia () le 01/04/2008 à 23:54. (lien). É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 Nicolas Boulay () le 02/04/2008 à 14:04. (lien). Évalué à 2.

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

          • [^]Re: Merci

            Posté par cho7 (page perso, ) le 02/04/2008 à 14:11. (lien). É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...

            --
            le python, c'est bon
            • [^]Re: Merci

              Posté par Nicolas Boulay () le 02/04/2008 à 16:55. (lien). É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.

              [^]Re: Merci

              Posté par khivapia () le 02/04/2008 à 17:00. (lien). É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 stephane martin () le 01/04/2008 à 21:44. (lien). É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.

        --
        Every time you write invalid markup, God kills a kitten
        • [^]Re: Merci

          Posté par khivapia () le 01/04/2008 à 23:57. (lien). É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 ragoutoutou () le 02/04/2008 à 09:48. (lien). É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 cho7 (page perso, ) le 02/04/2008 à 14:14. (lien). É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 ? :)

              --
              le python, c'est bon
              • [^]Re: Merci

                Posté par khivapia () le 02/04/2008 à 17:01. (lien). Évalué à 2.

                En fait on plaisante rarement quand on parle de sécurité ;-)

                • [^]Re: Merci

                  Posté par ragoutoutou () le 02/04/2008 à 17:13. (lien). É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...