Journal Chiffrage : Méthode et Utilité

Posté par  (site web personnel) .
Étiquettes :
6
21
nov.
2008
Salutation, à toi, Ô Journal (et surtout Ô toi lisant ce journal),
J’entends souvent parler de chiffrage de donnée sur disque (entre autre dernièrement avec ACTA et comme quoi les gouvernements souhaiterai s’octroyer le droit de fouiller dans notre privé sans manda, sans juge, …), et je souhaite avoir votre avis.

On connaît déjà le chiffrage des courriers électroniques avec GnuPG et consort. J’ai aussi quelques partitions chiffrées (avec luks) sur mon disque dur contenant les données que j’utilise le moins (album photo, …). Et j’envisage de chiffrer l’intégralité du disque dur pour me permettre de chiffrer les données utilisé quotidiennement (ainsi que le swap, les historiques, les mails, …).

A/ Parfois je me pose la question de l’utilité de chiffrer le disque dur (ne contenant rien de compromettant, des logiciels libres téléchargeable sur Internet, mes logiciels libres, téléchargeable sur Internet). Bien que parfois, je me dis qu’un attaquant ayant accès à mes mails, pourrait avoir accès à plusieurs mots de passe de compte Internet (Achat en ligne, compte LinuxFr, …)

B/ Je me demande l’utilité aussi de chiffrer le disque dur, et derrière en cas de control (par les douanes par exemple), avoir une partition détecté comme crypté, et suscitant donc la curiosité.

C/ J’ai donc commencé à regarder du coté de TrueCrypt, des volumes cachés, et du système d’exploitation caché, et je me demande s’il faut que je sois parano a ce point.

Pour ce dernier point, bien qu’alléchant techniquement (pour le plaisir de tester), je le trouve lourd à mettre en place. En effet, pour ne pas éveiller les soupçons, il faut utiliser le système d’exploitation non caché (decoy system) régulièrement, faire les mises à jours, … Ce qui implique alors de gérer deux systèmes d’exploitations (et les joies du double boot).

Alors je sais comme le proverbe dis : « Plus c’est simple à maintenir, Plus c’est vulnérable ».

De plus j’ai déjà l’ensemble de mes mails sur un serveur dédié, en clair, mais qui me permet d’y accéder de n’importe où.

Voilà où je veux en venir : Ô toi lisant ce journal :
- Chiffres-tu tes disques ?
- Utilises-tu des volumes cachés (où en as-tu l’intention) ?
- Chiffres-tu l’intégralité du système d’exploitation ?
- Utilises-tu TrueCrypt ?
- Connais-tu un moyen de chiffrer les mails sur un serveur dédié, mais que le Webmail (ou le serveur IMAP) puissent les déchiffrer quand tu t’y connectes ? Connais-tu une méthode pour chiffrer automatiquement tous les nouveaux mails avec ta clé publique, ainsi que tous les anciens mails ? Est-ce raisonnable ?

Merci de m'avoir lu,
Sur ce, passez tous un bon fin de semaine.

Pour info:
- http://www.truecrypt.org/docs/?s=hidden-volume
- http://www.truecrypt.org/docs/?s=hidden-operating-system
- http://luks.endorphin.org/

--
Ulrich
  • # Pas forcé.

    Posté par  . Évalué à 4.

    Alors je sais comme le proverbe dis : « Plus c’est simple à maintenir, Plus c’est vulnérable ».

    Pas forcément, il faut une troisième composante pour que ça devienne ingérable : l'évolutivité. Autrement, plus un système est simple (ou « moins il est complexe »), plus c'est facile d'identifier et combler les failles potentielles. Mais même un système très complexe, s'il est figé, peut être simple à maintenir et à sécuriser : il suffit de définir à sa conception des référentiels sérieux et d'avoir des procédures identifiées à l'avance.

    La majorité des problèmes venant justement du fait que soit ce travail n'a pas été mené en amont, soit le système évolue trop vite pour que les procédures restent valides jusqu'au moment où elles doivent servir.

    La « péremption » peut d'ailleurs être vertueuse si elle est applicable : pas besoin de passer la moitié de ses profits à se construire une forteresse si les informations ou les produits engendrés viennent se périment avant d'avoir le temps de fuir. On concentre ainsi toute son énergie sur l'activité productive et ça fait autant de choses en plus dans le domaine public à côté.
    • [^] # Re: Pas forcé.

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

      J'ai même tendance à penser que « Plus c’est simple à compliqué, Plus c’est vulnérable »

      Tout simplement parce que quelque chose de compliquer à maintenir ou à utiliser ne sera tout simplement pas maintenu ou utilisé sur le moyen ou long terme.

      Pour moi il y a plus de sécurité dans une solution, certes techniquement un peu moins bonne mais utilisée, qu'une solution parfaite qui ne l'est pas.
  • # détail

    Posté par  . Évalué à 6.

    chiffrage => chiffrement.
    • [^] # Re: détail

      Posté par  . Évalué à 1.

      « passez tous un bon fin de semaine. »
      bonne fin de semaine

      « chiffrage de donnée »
      données
  • # GPG + webmail

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

    http://getfiregpg.org/

    Pas testé, cela dit. Quelqu'un, peut-etre ?
    • [^] # Re: GPG + webmail

      Posté par  . Évalué à 2.

      Oui, quand ça marche c'est bien (il arrive qu'il soit cassé, je pense suite à des modifs sur le webmail de google), mais qui utilise encore un webmail ? :-)
      • [^] # Re: GPG + webmail

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

        Cool. Je vais essayer a l'occasion alors.

        Deux micro questions benetes:

        - pour envoyer ou recevoir des mails chiffrés, il faut respectivement utiliser la clé publique du destinataire, ou que l'envoyeur utilise ma propre clé publique. Juste ?

        - les mails que j'envoie chiffrés, et qui sont déchiffrés par le destinataire, peuvent etre ensuite stockés en clair sur son disque local, voire forwardés a des tiers en clair, non ? Du coup, la fiabilité de la chaine étant celle de son maillon le plus faible, chiffrer ses mails me semble interessant, mais sujet à beaucoup de contournements. Me gourre-je ?
        • [^] # Re: GPG + webmail

          Posté par  . Évalué à 3.

          Si tu envoies un message chiffré à quelqu'un, c'est que tu ne fais confiance qu'à lui pour lire ce message. Puisque tu lui fais confiance, oui, il peut faire ce qu'il veut du message. Si tu ne lui fais pas confiance, il ne faut pas lui envoyer ce message. ;-)

          C'est la différence avec la mal-nommée « informatique de confiance » qui veut te permettre d'envoyer des courriels qui s'auto-détruisent au bout de 5 minutes (désolé pour votre ordinateur monsieur Phelps…).

          Yannick
    • [^] # Re: GPG + webmail

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

      Ca m'a l'air interessant. Je testerai à l'occasion. Le temps que je mette ma clé privé sur un support chiffré ;)
      • [^] # Re: GPG + webmail

        Posté par  . Évalué à 2.

        Je n'ai pas tout saisi là. Tu veux chiffrer tes mails et le consulter n'importe ou. Or... Chiffrement = clefs. Soit tu es avec ton ordi, et donc ta clef, et c'est bon. Soit tu n'es pas avec ton ordi, et dans ce cas il te faut la clef à porté de main. Pour que le webmail déchiffre tes mails, il faut qu'il ai la clef, et donc qu'elle soit sur le serveur. Donc fiabilité 0. non?
        • [^] # Re: GPG + webmail

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

          Tu peux aussi avoir ta clé sur une clé USB par exemple :)
          • [^] # Re: GPG + webmail

            Posté par  . Évalué à 5.

            Une clé GPG (ou pas) en fichier, même chiffrée avec une "passphrase", c'est quand même risqué de l'utiliser sur n'importe quelle machine...

            ... les risques sont quand même importants de voir la clé récupérée par un tiers douteux, qui contrôle les binaires de la machine.

            Après, on peut passer à de l'authentification forte (ce que je suis en train de faire), via par exemple de la smartcard : même si on connaît le PIN (l'équivalent de la "passphrase"), on ne peut extraire ni copier la clé de la carte qu'il faut posséder pour utiliser la-dite clé (à moins de faire de l'attaque physique sur la puce de la carte, auquel cas, il faut quand même posséder cette dernière). Et au bout d'un certain nombre d'essais râtés (3 a priori), la carte se bloque.

            On passe de "quelque chose qu'il faut connaître" à "quelque chose qu'il faut connaître" ET "quelque chose qu'il faut posséder" (d'où l'authentification _forte_ : il faut au moins deux facteurs pour s'authentifier).



            Après, le souci, c'est le nombre de cartes supportées : il y a bien les cartes OpenPGP (dispos chez KernelConcept [1], ou en adhérant à la FSF), mais celles qui se vendent sont limitées à du RSA 1024bits (la spécification va jusqu'à 2048bits, mais il n'y en a pas encore de telles qui soient vendues et soient des "OpenPGP cards" ; malheureusement, ça suffit à me dissuader). En outre, les devs de GPG veulent uniquement utiliser le standard PKCS#15 et se foutent de supporter PKCS#11 (standard de fait, que ça plaise ou pas, ce qui est une toute autre question), ce qui peut limiter l'usage que l'on fait des cartes OpenPGP...

            Sinon, une carte PKCS#11... mais niveau cartes utilisables sous Linux, ce n'est pas la gloire non plus : la mieux supportée est la CryptoFlex e-gate 32k (RSA 2048bits), mais il devient très dur de la trouver, le modèle ne se fabriquant plus (il y en a quand même chez USASmartcard [2]... 18$ la carte, et 27$ de ports ; les miennes devraient arriver lundi :).

            Attention quand même quant aux cartes "supportées"... OpenSC (le backend pour gérer les cartes) en reconnaît pas mal, mais peut être capable d'en utiliser certaines, sans pour autant les initialiser (ce qui relève du standard PKCS#15)... L'idéal serait de supporter les ACOS5 (10€, RSA 2048bits, facilement disponible en France), mais pour l'instant, il ne fait que vaguement les reconnaître...

            On trouve aussi pas mal de "java cards" (cartes qui utilisent un OS java en leur sein), mais pour le support, ça a l'air assez aléatoire...

            Il faudra aussi un lecteur : a priori, tant que ça supporte le standard CCID (comme la plupart des lecteurs), ça devrait le faire. Les lecteurs de chez Eutronsec [3] sont assez sympas (malgré une qualité de fabrication assez médiocre... genre, le bouchon de ma SIM Pocket ne tient pas, le lecteur étant en outre assez énorme en lui-même, et ouvrir le SIM Reader pour y mettre une carte SIM relève un minimum du sport ; m'enfin, ça marche et c'est reconnu sans souci).



            Pour l'utilsation, je compte me servir d'une SIM dans un SIM Pocket pour mes besoins d'authentification, de signature et de chiffrement (on peut stocker des passphrases générés hors cartes en tant qu'objets privés, demandant le PIN, dans la carte : ça marche avec LUKS, par exemple) courants, mais ce lecteur me permettra aussi d'utiliser une carte au format carte bleue pour accéder à mon VPN. Quant au SIM Reader, ce sera pour faire des choses avec des droits plus avancés (administrer, gérer mon CA-maison, déchiffrer les mails d'admin, ...).



            Tiens, d'ailleurs, si quelqu'un sait où on pourrait acheter un porte-monnaie/clés (le genre de porte-monnaie avec des clips pour mettre des clés à l'intérieur), si possible en forme de Tux, pour que je mette tout ça dans ma poche, en les protégeant, ça m'intéresse :)



            [1] http://www.kernelconcepts.de/shop/products/security.shtml?ha(...)
            [2] http://www.usasmartcard.com/component/option,com_virtuemart/(...)
            [3] http://www.eutronsec.com/infosecurity/Contents/ProductLine/D(...)
  • # Utilité de chiffrer et soupçons

    Posté par  . Évalué à 7.

    Je ne chiffre pas mes disques pour l'instant, mais il se peut que je le fasse dans le futur: je ne considère pas que cela soit fait pour cacher des choses qui pourraient être compromettantes, mais comme simple mesure de protection des données.

    Je me demande l’utilité aussi de chiffrer le disque dur, et derrière en cas de control (par les douanes par exemple), avoir une partition détecté comme crypté, et suscitant donc la curiosité.

    C'est la dernière chose dont je me préoccuperais. Avec toutes les bonnes raisons de chiffrer évoquées ci-dessus, il y aura de quoi expliquer tout cela aux douanes le jour ou il y a un problème.
    (il me semble que cela rejoint un peu le troll "faut-il accepter les caméras de surveillance partout parce qu'on a rien à se reprocher ?" )
  • # Impact performance

    Posté par  . Évalué à 2.

    Ca ne fait pas partie de ta problématique, mais sache que l'impact sur les performances de ton ordi en cas de chiffrement complet du système via Truecrypt est loin d'être anodin.

    Mon retour d'expérience concerne un ordinateur portable qui a environ 3 ans, avec un disque dur peu véloce, tournant sous Windows. Ca devient lent à en être pénible
    • [^] # Re: Impact performance

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

      Oui c'est un point auquel je n'avais pas réfléchis. Il faudrait que je fasse des test de perf pour voir a quel point cela se dégrade.

      Et au niveau de l'utilisation mémoire ? Je suppose qu'un système entièrement chiffré nécessite plus de mémoire ?
    • [^] # Re: Impact performance

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

      J'ai testé un installation où tout était chiffré : installation avec une seule partition qui contenait tout. Bah c'est hyper lent. top montrait souvent le processus noyau qui chiffrait le disque. Bref, à éviter à tout prix. Il ne faut que chiffrer l'essentiel : /home voir une partie de /home. Chiffrer la partition swap coûte aussi cher en CPU. Vaut mieux acheter une barrette de RAM en plus.
      • [^] # Re: Impact performance

        Posté par  . Évalué à 2.

        en même temps si ton ordi commence à swapper, faut déja mieux acheter une barette de ram en plus.
        Chiffrer le swap permet d'éviter que les données qui sont écrites en swap (parce que même si ta mémoire est pas utilisé complètement, le swap peut etre utilisé) (usage normal ou hibernation) ne puisse être lu ensuite.

        Sinon je confirme le surcout d'une partoch chiffré.
        Ce surcout dépend aussi des algo utilisé.
        Aes 256 en cbc offrait une vitesse qui pouvait etre deux à trois fois d'autres algo (serpent en lwp ou d'autres trucs comme ça).
      • [^] # Re: Impact performance

        Posté par  . Évalué à 2.

        j'ai chiffre le rootfs...et j'e n'ais pas remarque de perte de performances:
        *pentium M 2ghz
        *2 hdd en raid0
        *1.5GB de ram
  • # Chiffrer les tuyaux...

    Posté par  . Évalué à 3.

    J'ai beau chiffrer swap et /tmp (parce qu'il y a tout et n'importe quoi là-dedans), je ne le fais qu'avec des clés générées à chaque boot.

    Pour ce qui est des données, par contre, globalement, je chiffre très très peu : à la place, je préfère héberger ce qui est "sensible" chez moi, et y accéder avec du tuyau chiffré... je pense d'ailleurs à y déporter ce qui est sensible et très mal protégé, comme les porte-clés de kwallet (que je considère mauvais au possible : pas de support de PAM, pas de support de GPG, pas de support des smartcards, dont je suis en train de m'acheter quelques exemplaires...pour tout dire, tant que je n'aurais pas finalisé sa déportation sur un montage distant avec connexion chiffrée, pas moyen que j'accepte de m'en servir sur mon laptop), ou mes bookmarks. Avec un petit SFTP, ça doit bien se faire. Éventuellement, si je pousse la parano plus loin, je pourrais toujours accéder à des fichiers chiffrés via SFTP, puis les déchiffrer en les remontant...

    Je prends très rarement l'avion, mais je me dis que la prochaine fois que je devrai le faire, si je dois emmener mon laptop, il est exclus que j'emmène des données personnelles avec moi : ça n'a rien à foutre dans les mains de qui que ce soit d'autre que moi. Du coup, je prends les devants...

    ... maintenant, je trouve vraiment dommage que la plupart des devs se foutent de la gestion propre de la vie privée ; les clickodromes libres fuient de partout, à ce niveau... ça mériterait franchement de la spécification Freedesktop (peut-être un sujet à lancer en ML), où il pourrait être conseillé de gérer le montage distant et sécurisé de tout ce qui concerne la vie privée des utilisateurs. Pour faciliter ça et le rendre "user-friendly", tout est à faire ; et pourtant, ça permettrait de se passer du chiffrement des données en elle-mêmes dans bien des cas.
    • [^] # Re: Chiffrer les tuyaux...

      Posté par  . Évalué à 3.

      kwallet (que je considère mauvais au possible : pas de support de PAM, pas de support de GPG, pas de support des smartcards

      À ce propos il y a un nouveau contributeur qui travaille pas mal sur kwallet en ce moment : http://www.confuego.org/archives/12-KDE-Wallet-improvements-(...) . Si tes vœux ne sont pas déjà dans bugs.kde.org, ajoute les, ça pourrait lui donner des idées.
      • [^] # Re: Chiffrer les tuyaux...

        Posté par  . Évalué à 3.

        Il faut que je rajoute la demande d'exporter les porte-clés sur un partage SFTP, mais pour les smartcards, GPG et PAM, ça y est déjà... mais les devs demandaient d'attendre 4.2 pour que les API crypto soient plus utilisables. Si ça pouvait se concrétiser...

        Maintenant, ça ne résout pas le problème des bookmarks, de l'historique, des documents récents, ... il y a pourtant, m'est avis, du gros coup à jouer là-dessus.

        Les systèmes libres ont beau avoir un historique de bonnes pratiques de "sékiourité" (séparation des privilèges, dévoilement public des failles, KISS, ...), l'utilisateur a tendance à être fainéant (moi le premier), et si la surcouche à tout ça est un gruyère qui dévoile tout sur lui... l'OS a beau être "sûr", l'utilisateur est alors exposé.
  • # Réponses

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

    - Chiffres-tu tes disques ?

    Oui (sur mon portable).

    - Utilises-tu des volumes cachés (où en as-tu l’intention) ?

    Jamais.

    - Chiffres-tu l’intégralité du système d’exploitation ?

    Oui (swap incluses).

    - Utilises-tu TrueCrypt ?

    Non.

    - Connais-tu un moyen de chiffrer les mails sur un serveur dédié, mais que le Webmail (ou le serveur IMAP) puissent les déchiffrer quand tu t’y connectes ?

    Je ne connais pas.

    - Connais-tu une méthode pour chiffrer automatiquement tous les nouveaux mails avec ta clé publique, ainsi que tous les anciens mails ?

    mutt doit pouvoir faire ça sans problème pour les nouveaux mails. Pour les anciens, man gpg et puis find pour faire un peu de traitement par lot des anciens mails (sous réserve qu'ils soient stockés au format Maildir).

    - Est-ce raisonnable ?

    Il vaut mieux chiffrer le répertoire contenant les mails à mon avis (moins lourd, tu déverrouilles au lancement du client email, et puis c'est tout).

    Pour la problématique des mails, tu seras peut-être intéressé par http://no-log.org
    • [^] # Re: Réponses

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

      Par curiosité, tu as adopté quelle solution pour chiffrer ton OS complet ?
      • [^] # Re: Réponses

        Posté par  . Évalué à 3.

        - Chiffres-tu tes disques ?
        juste le portable pour l'instant mais ca va venir
        - Utilises-tu des volumes cachés (où en as-tu l’intention) ?
        non
        - Chiffres-tu l’intégralité du système d’exploitation ?
        presque...pas le kernel ni le bios
        - Utilises-tu TrueCrypt ?
        non,j'uttilise LUKS
        - Connais-tu un moyen de chiffrer les mails sur un serveur dédié, mais que le Webmail (ou le serveur IMAP) puissent les déchiffrer quand tu t’y connectes ? Connais-tu une méthode pour chiffrer automatiquement tous les nouveaux mails avec ta clé publique, ainsi que tous les anciens mails ? Est-ce raisonnable ?
        oui il y'en a une...mais le serveur doit avoir la clee..ce qui est inacceptable si tu ne contrôles pas le serveur
        http://www.squirrelmail.org/plugin_view.php?id=153

        Je compte aussi passer a coreboot a cause de:
        http://en.wikipedia.org/wiki/System_Management_Mode
        pour le portable je pense prendre un OLPC...mais je me demande si le chiffrement materiel aes-128 du processeur geode est suffisant et fonctionne bien.

        comment proteger sa vie privee:
        I le materiel:
        J'uttilise exclusivement/uniquement des logiciels dont j'ai les sources,cela me permet de ne pas etre espionne.je n'ai pas de double boot windows.
        Mes Ordinateurs sont tous a jour et j'utilise selinux sur le portable,je vais étendre cela a tous mes ordinateurs quand j'aurais le temps.
        Il faudrait quand même que je passe a paludis au lieu de portage(permet de choisir ses licences)...parce que s'il m'installe des logiciels proprietaires en tant que dépendance...mais pour cela il faudra sans doute faire un "policy" selinux pour paludis(paludis label quand même les fichiers correctements)
        J'ai chiffre mon portable,c'est a dire le rootfs dont voici les partitions des deux disques durs:
        [puppy linux non cryptes][kernels non cryptes][swap1 crypte][swap2 crypte [raid0->cryptage->hdd]
        j'ai un puppy linux pour montrer que mon ordinateur marche...comme ca quand je passe la douane...s'ils me demandent de montrer que mon portable marche j'ai quelque chose d'autre a montrer qu'une demande de mot de passe...
        De plus j'uttilise gentoo...avec les bonnes options de boot il ne te demande meme plus le mot de passe...en gros tu tapes le password sans rien voir....et rien ne s'affiche...
        Je compte faire un lvm+raid6+luks pour l'ordi de bureau(au cas ou je demenage)
        Je pense migrer sous peu sous coreboot parce que le bios peu t'espionner avec le SMI/SMM:
        http://en.wikipedia.org/wiki/System_Management_Mode
        *j'ai un livre qu'un amis m'as prete sur le reverse-engeenering du bios...dedans il y'a aussi comment faire des rootkits pour le bios...
        *phoenix a deja espionne ses utilisateurs et mis de la publicité,cette fonction s'appelait "ebetween"
        II: le reseau:
        comme routeur je vais mettre un piii500 qu'on va me porter sous coreboot(les chips sont deja supportes donc c'est facile) et je compte y mettre:
        *asterisk+openvpn pour cripter les conversations
        *bind pour ne pas dependre du DNS de mon fournisseur
        tor est trop lent pour une uttillisation quotidienne,de plus ca ne regle pas le probleme des mails...bien au contraire(l'exit node peut voir tout le contenu)
        Mais la priorite No1 est google...comment faire pour ne pas être fiche par google tout en continuant a l'uttiliser rapidement?
        existe t'il quelque chose a ce sujet?
        tel que quelquechose qui switcherais de proxy tout les x secondes?

        sinon j'uttilise pas le bit torrent chiffre mais je sait comment faire:
        *uttiliser tor+privoxy pour se procurer les torrents
        *uttiliser tor+privoxy dans le proxy pour le seeding
        *reste non chiffre pour le reste
        • [^] # Re: Réponses

          Posté par  . Évalué à 3.

          je me demande si le chiffrement materiel aes-128 du processeur geode est suffisant et fonctionne bien.
          Il fonctionne très bien sous Linux et il est suffisant dans la plupart des cas, voir mon journal à ce sujet (même proc) https://linuxfr.org/~khivapia/27342.html (recherche hdparm). Il apporte également un générateur d'aléas hardware idéal pour les clefs de chiffrement temporaires.
          Toutefois deux remarques
          1) C'est limité à AES-128, en mode ECB (à proscrire), et CBC (bien, mais il existe mieux, comme CTR, voir la page wikipedia http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation ). Donc pas d'AES-256, ni d'autres modes de chiffrement ni d'autres algorithmes.
          2) La plus grosse limitation reste quand même le processeur si on utilise le mode essiv:sha256 qui doit calculer une clef pour chaque secteur en utilisant SHA-256.

          Mais dans une utilisation au jour le jour c'est vraiment transparent. Toutefois, je recommanderais l'utilisation du padlock VIA pour les raisons suivantes :
          1) est supporté directement par OpenSSL & Co, pour des raisons qu'explique Patrick Lamaizière dans mon journal
          2) Est beaucoup plus complet au niveau algorithmes.
      • [^] # Re: Réponses

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

        > Par curiosité, tu as adopté quelle solution pour chiffrer ton OS complet ?

        Celle proposée par défaut dans l'installateur Debian (à savoir cryptsetup/LUKS).
  • # perso

    Posté par  . Évalué à 2.

    a une epoque je chiffrais le swap, mais bon ce n'est pas super userfriendly du coup j'ai arrété. pour le chiffrement je pense que cela ne sert a rien, SAUF si un jour suite a un controle dans un aeroport et qu'un douanier trouve un .iso quelquepart et que tu passe une nuit en prison.

    pour resumé c'est mieux de le faire car quand tu en auras besoin ce seras trop tard. un peu comme la ceinture de securité dans une voiture
    • [^] # Re: perso

      Posté par  . Évalué à 5.

      > ce n'est pas super userfriendly

      Ce n'est pas super compliqué non plus : une ligne dans le crypttab, le nœud du swap à changer dans le fstab, et zou...

      ... l'installateur de Debian permet d'ailleurs de faire ça facilement (par contre, pas trop d'idée de comment il écrase les données et initie l'entropie).
      • [^] # Re: perso

        Posté par  . Évalué à 5.

        comment il écrase les données et initie l'entropie

        il se connecte sur le serveur de debian, et commence à calculer l'estimation de la sortie de la prochaine version stable, correlé avec les estimations données par les divers flux rss sur les sites linux et les blogs influents.

        Je pense que cela fera suffisemment d'entropie.

        Sinon par rapport à la question, je ne chiffre pas mon swap ou toutes mes partitions, et je n'utilise pas de conteneur type truecrypt. Ce qui me ferait un peu peur avec ça, c'est que si des secteurs sous le conteneur se corromptent, il y a peut être risque de perdre la totalité du conteneur. Avec encfs, il y a peut être un risque similaire si la clé se corrompt, mais c'est plus facile de sauvegarder plusieurs fois une clé qui fait quelques ko, qu'un container complet (ce qui n'empêche pas de sauvegarder les fichiers individuels par ailleurs).

        D'autre part, dans un container la taille est prédéfinie, donc c'est un peu moins souple, mais la préférence va bien entendu selon l'utilisation qu'on en fait.

        Et sinon je ne chiffre pas non plus mes données "publiques" ou destinées à l'être (dessins, site internet, fichiers de programmation même si parfois c'est un peu la honte), seulement les données plus personnelles que je n'aimerais pas retrouver entre les mains d'un douanier ou d'un blogeur influent : photos quand je cours tout nu sur la plage, poèmes éthyliques, comptes bancaires (surtout ceux en suisse), tickets réductions de chez Ed, plans de la navette spaciale, photomontage du pape, projets propriétaires en visual basic etc. (humour hein !)

        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: perso

          Posté par  . Évalué à 3.

          > facile de sauvegarder plusieurs fois une clé qui fait quelques ko, qu'un container complet
          Attention avec ce genre de chose, si la clef chiffrante tombe entre d'autres mains, même protégée par un mot de passe, tu perds la possibilité de changer ton mot de passe. Il en va de même pour GPG, LUKS, etc. (sinon, tu peux aussi sauvegarder l'entête LUKS (c'est expliqué dans la FAQ de LUKS je crois) comme tu fais pour encfs)
          • [^] # Re: perso

            Posté par  . Évalué à 2.

            merci de l'information. Mais pourquoi ? Est-ce que parce que sinon il serait possible de déchiffrer les données à partir de cela ?

            Par contre dans le cas de truecrypt, est-ce que si une partie du container est abimé, cela permet quand même de récupérer le reste ou alors il considère que tout le volume est perdu ?

            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: perso

              Posté par  . Évalué à 2.

              En fait, la clef "maître" (qui sert vraiment à chiffrer tes fichiers) ne change pas, si quelqu'un en garde une copie protégée par un mot de passe, changer ton mot de passe ne changera pas sa copie, et il essayera d'attaquer ton ancien mot de passe. S'il réussit, il ne te reste plus qu'à changer la clef maître (c'est à dire rechiffrer tous tes fichiers) car elle est compromise.
              Il faut voir la version protégée de la clef maître comme étant "marquée", "associée" à un mot de passe particulier. Changer le mot de passe crée une nouvelle version (indépendante de la précédente, l'ancienne est _encore_ valide) de la même clef maître.

              > Par contre dans le cas de truecrypt, est-ce que si une partie du container est abimé, cela permet quand même de récupérer le reste ou alors il considère que tout le volume est perdu ?
              Je ne connais pas truecrypt, mais pour LUKS, je crois que le volume n'est perdu que si l'en-tête LUKS (au début de la partition) est abimé. Si quelques octets sont modifiés en dehors de l'en-tête, on perd seulement les secteurs qui contenait ces octets il me semble. (Je ne sais pas quelle taille font ces secteurs, si ça dépend du type d'objet chiffré (partition de disque dur, LVM)). [Disclaimer : ceci est à prendre avec des pincettes]
  • # C'est aussi un tout

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

    Mon principal soucis n'est pas de protéger mes données en cas de contrôle mais plutôt en cas de vol du Pc. Je n'ai pas envie que qqn se retrouve avec mon mot de passe mail ou mes clefs ssh...

    Je n'ai pas mis de swap, donc rien à chiffrer de ce point de vue là. J'ai mis bcp de répertoires en tempfs pour accellerer les temps d'accès et éviter de surcharger le SSD mais sans chercher avant tout à la sécurité.

    Par contre, j'ai choisi de chiffrer mon /home avec Lucks. Pour garder un petit confort, j'ai préférer sauvegarder le mot de passe sur clef USB ( mot de passe créé à l'aide de /dev/random et que je ne connais pas ). et il me suffit d'insérer la clef lors du login, de me loguer ( avec un mot de passe qui n'a rien à voir avec celui de la clef ), et de retirer la clef une fois que je suis sur mon bureau.

    Comme il s'agit du seul PC pouvant sortir de chez moi, c'est le seul à disposer de partition chiffrée ( et encore, mes mots de passe Wifi sont accessibles en clair à quiconque pouvant lire le disque ).

    Voilà pour les données. Sinon je pense que faire des tourner des logiciels tels que Tor ou Freenet sont aussi de très bon moyens pour assurer un niveau de sécurité. Non pas pour utiliser leur services, mais pour "noyer" les connexions que l'on peut réaliser au milieu de toutes celles relayées par ces services et empêcher de tracer un profil de nos connexions internet.

    Mais c'est un tout, et je me vois mal chiffrer l'ensemble des cartes mémoires ou des clefs USB que je peux conserver chez moi ( et qui doivent sûrement garder des fichiers dont j'ai oublié l'existence et me concernant ), de même qu'il est possible de retrouver mon n° de téléphone en faisant un whois sur mon nom de domaine...

    Je ne suis pas prêt à vivre dans l'anonymat mais tant que je peux trouver des solutions qui m'en rapprochent sans être contraignantes ( AdblockPlus ou ma partition chiffrée ), je les utilise avec plaisir.
  • # Pourquoi (ne pas) chiffrer ?

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

    Le disque dur de mon ordinateur est chiffré (entièrement). Que j'aie des choses "à cacher" ou pas... ça reste très relatif comme notion. À qui ? Selon quel critère ? Pour moi, chiffrer son disque dur, tout comme chiffrer ses mails, c'est un peu comme mettre une enveloppe sur le courrier qu'on envoie : d'une, pas besoin d'avoir des choses à cacher pour tenir à avoir une certaine "intimité". De deux, si on chiffrait seulement les trucs qu'on veut cacher, ça serait un peu voyant... Une des forces des algos de chiffrement, c'est certes le nombre de clés possibles, mais c'est aussi la quantité de données chiffrées dont on ne sait pas lesquelles valent l'effort...

    Observation corollaire : plus tout le monde chiffre ses données, plus ça banalise cette pratique, et protège (des soupçons, des tentatives d'intrusion, etc.) tout le monde en même temps.

    Autre point : la question de vouloir cacher le fait qu'on a des données chiffrées. Ça s'appelle "plausible deniability" en anglais. Ça permet par exemple en théorie de nier que tu as des données chiffrées, au cas où on t'oblige à donner la clé (par la force, la menace, ou la loi, qui est un mélange plus ou moins direct des deux premiers), ou bien de donner une clé qui ouvre l'accès à une partie seulement des données, sans qu'on puisse soupçonner qu'il y en a d'autres. C'est le principe de systèmes tels que Phonebook (vieux, plus développé, je n'en ai pas d'autres en mémoire mais ça se trouve facilement).

    En théorie c'est le système idéal, mais dans la pratique c'est un problème mathématique vraiment complexe. Je crois me souvenir que Bruce Schneier a écrit un article il y a moins d'un an de ça, expliquant un peu les difficultés que ça soulève ; mais par ailleurs c'est un sujet quand même (relativement) pas mal traité.
  • # Pour ma part, les données

    Posté par  . Évalué à 7.

    Oui, je chiffre mes disques durs, tout au moins ceux « vivants » (entendre /home, swap et /tmp).
    Je ne vois pas d'utilité à chiffrer le système, vu que ses sources sont disponibles ailleurs :-).
    J'utilise LUKS, parce que c'est foutrement bien intégré dans le système (avec un petit script maison qui récupère un fichier clef sur une clef USB pour dévérrouiller les partitions /home).
    Par ailleurs, c'est rudement bien intégré dans GNOME : je branche mon DD externe chiffré, il me demande mon mot de passe et le monte. Rien de plus simple (et je suppose que pour KDE4 c'est pareil).

    Je n'ai jamais essayé de chiffrer des mails sur un Webmail, mais comme solution simple, je pense à chiffrer le volume qui les contient.

    Au niveau des arguments, tout ce que j'en pense a déjà été dit, mais je vais essayer d'en faire une synthèse :
    * parce que je peux le faire ;-). Ben oui, tout existe déjà, et comme je suis un bidouilleur invétéré et que ça m'a intéressé un jour, je l'ai fait. Et je ne suis pas déçu, à part un peu pour les perfs, mais ça ne me dérange pas,
    * pour la frime face à mes collègues sous Windows : hé oui, si tu n'as pas la clef de contact, tu ne démarres pas l'ordinateur :-)
    * parce que je tiens à conserver ma vie privée. J'entends souvent l'argument « si tu n'as rien à cacher, il n'y a pas de problème » à quoi je rétorque soit « seuls les Siths sont aussi absolus », soit « ben alors, ça ne te dérangerait pas d'avoir une caméra dans tes toilettes, puisque tu n'as rien à cacher ! ». Hé oui, la notion de vie privée inclus celle d'intimité, souvent oubliée et pourtant fondamentale. Après tout, non, je n'ai rien à cacher, mais je tiens à savoir lorsqu'on fouille dans mes données; donc si légalement j'en suis obligé, je fournirai l'accès, mais sans mon accord, personne ne fouillera. Ça revient à fermer la porte de chez soi, et l'ouvrir quand la police sonne.
    * d'un point de vue proffessionnel, je dois noter certains mots de passe des serveurs qu'on administre car je n'ai pas la mémoire pour retenir 42 mots de passes différents (avec les logins). Donc ici, c'est capital.
    * bien sûr, ne pas chiffrer que ce qui me semble important, mais l'ensemble, pour ne pas éveiller la suspiction,
    * et enfin, ajouter mon propre poids à la masse : plus on sera nombreux, plus cet usage sera courant, et plus ça passera dans les mœurs, et étouffera ce sentiment d'avoir des choses à cacher.

    Bien sûr, je ne me contente pas des données sur support, je m'efforce de chiffrer aussi mes mails lorsque mes correspondants ont une clef publique, ainsi que pour la messagerie instantanée (que j'utilise assez peu, d'ailleurs). Enfin, lorsque je le peux, j'utilise HTTPS (surtout Linuxfr et Wikipédia).

    Il me reste encore à me pencher sur Tor, mais ça demande du temps, et je ne suis pas encore parano à ce point.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pour ma part, les données

      Posté par  . Évalué à 3.

      > Je ne vois pas d'utilité à chiffrer le système, vu que ses sources sont disponibles ailleurs :-).
      Si ta partition racine n'est pas chiffrée, quelqu'un peut insérer des saletés (éventuellement peu visibles) dans ton système de fichiers. Si elle est chiffrée, il pourra juste remplacer complètement ton système de fichiers, ce que tu remarqueras plus vite. (même si on peut imaginer des moyens de trafiquer ça aussi, c'est plus difficile)
      • [^] # Re: Pour ma part, les données

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

        Tu as toujours une partie non chiffrée, à commencer par ton kernel et tout ce qui se fait avant que ton mot de passe soit demandé (c'est le problème de la poule et de l'œuf), donc c'est possible de mettre n'importe quel rootkit pour loguer ta passphrase, compromettre ton système une fois déchiffré, etc. Du coup pour moi le chiffrement c'est vraiment pas une mesure de protection contre la corruption de mon système.

Suivre le flux des commentaires

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