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
Journal Chiffrage : Méthode et Utilité
21
nov.
2008
# Pas forcé.
Posté par Obsidian . Évalué à 4.
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 beagf (site web personnel) . Évalué à 3.
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 cowboy . Évalué à 6.
[^] # Re: détail
Posté par olympi . Évalué à 1.
bonne fin de semaine
« chiffrage de donnée »
données
# GPG + webmail
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
Pas testé, cela dit. Quelqu'un, peut-etre ?
[^] # Re: GPG + webmail
Posté par TNorth . Évalué à 2.
[^] # Re: GPG + webmail
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
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 Yannick . Évalué à 3.
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 phoenix (site web personnel) . Évalué à 1.
[^] # Re: GPG + webmail
Posté par Le Gall Sébastien . Évalué à 2.
[^] # Re: GPG + webmail
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: GPG + webmail
Posté par Aefron . Évalué à 5.
... 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 TNorth . Évalué à 7.
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 mizu . Évalué à 2.
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 phoenix (site web personnel) . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Impact performance
Posté par briaeros007 . Évalué à 2.
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 GNUtoo . Évalué à 2.
*pentium M 2ghz
*2 hdd en raid0
*1.5GB de ram
# Chiffrer les tuyaux...
Posté par Aefron . Évalué à 3.
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 med . Évalué à 3.
À 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 Aefron . Évalué à 3.
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 MrLapinot (site web personnel) . Évalué à 3.
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 aurel (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Réponses
Posté par GNUtoo . Évalué à 3.
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 khivapia . Évalué à 3.
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 MrLapinot (site web personnel) . Évalué à 1.
Celle proposée par défaut dans l'installateur Debian (à savoir cryptsetup/LUKS).
# perso
Posté par Anonyme . Évalué à 2.
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 Aefron . Évalué à 5.
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 B16F4RV4RD1N . Évalué à 5.
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 Octabrain . Évalué à 3.
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 B16F4RV4RD1N . Évalué à 2.
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 Octabrain . Évalué à 2.
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 chimrod (site web personnel) . Évalué à 4.
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 davux (site web personnel) . Évalué à 7.
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 zebra3 . Évalué à 7.
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 Octabrain . Évalué à 3.
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 davux (site web personnel) . Évalué à 2.
[^] # Re: Pour ma part, les données
Posté par Octabrain . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.