En retour – Dell XPS 13 et chiffrement

UPS m’a livré hier le Dell XPS, 9 jours entre la commande et la livraison (07/10 et 16/10). Point très positif donc puisque je devais initialement le recevoir fin octobre.

Je ne l’ai pas encore allumé, je ne sais pas si je le ferai ce week-end. J’aime prendre mon temps et faire ça au bon moment (en général « quand j’ai le temps » ha ha).

Avant de me mettre à installer un nouveau pc, je réfléchis et me décide : Distribution, partitionnement, système de fichiers, chiffrement, sessions…

Ce sera une Debian Testing, j’arrête Debian bullseye/sid, je n’ai finalement pas besoin du côté sid. Je confirme au passage mon attachement à Debian, à la qualité de cette grande distribution. J’ai souvent pensé que mon chemin « logique » serait ensuite Arch, j’en doute de plus en plus, je n’ai rien qui me manque sur Debian Testing et aucune volonté de me complexifier la vie. Non je ne dis pas que Arch est moins bien ou plus complexe seulement que je bosse sur des serveurs Debian toute la journée, que je suis passé par Xubuntu – Mint – Debian comme distrib sur mes pc donc je suis bien avec du .deb, le gestionnaire de packages, les sources d’information, son double usage serveur/pc.

La seule vraie question était le chiffrement. Je parcourais mon article Spécial NVMe, 8 mois écoulés depuis sa parution et sedutil n’a reçu aucun commit (depuis 3 ans maintenant), projet abandonné à mes yeux. Par conséquent le chiffrement matériel est exclu.

Je reste sur /home chiffré avec eCryptfs ou je passe au chiffrement complet du disque proposé à l’install par Debian ? La seconde option est plus sûre mais aussi plus contraignante et coûteuse, j’ai cependant fait le tour (des problèmes 1, 2) de eCryptfs (même Ubuntu a arrêté de l’utiliser) que je quitte définitivement.

J’ai trouvé les réflexions de The Case Against Full-Disk Encryption très intéressantes et je vais creuser Speeding up Linux disk encryption ce week-end.

Je me souviens avec nostalgie de mes conteneurs TrueCrypt (puis VeraCrypt) sous Windows il y a quelques années. Je me vois tout de même mal ne pas chiffrer intégralement le disque du XPS. Vous faites comment vous, un avis sur la question ?

Déjà 24 avis pertinents dans En retour – Dell XPS 13 et chiffrement

  • Salut. À mon sens l’intérêt de chiffrer le disque entier est limité, à vrai dire je ne vois pas trop de cas où ça s’avère nécessaire, le `$HOME` (et éventuellement le swap) c’est suffisant. Ça protège les données en cas de perte, de vol ou de perquisition de l’ordinateur, et je pense que c’est suffisant pour moi et la quasi-totalité des gens.
  • Damien Delurier
    Je chiffre le home également. Comme le dit c’est pour limiter la casse en cas de perte ou de vol de l’ordinateur :)
  • Hello, perso sur le laptop du taf c’est chiffrement intégral proposé à l’installation par Calamares (j’utilise Manjaro). Bon là, temporairement, et suite à un souci de mise à jour que j’ai très très mal géré, j’ai tout crash, et Calamares m’a salement jeté un bug qu’il pouvait pas appliquer le chiffrement sur une des partitions. J’ai donc réinstallé sans, mais c’est une situation transitoire.

    Sur le fait du chiffrement que du /home, faut pas oublier que même en ayant un usage plus que limité du compte root, on n’est jamais à l’abri que certains éléments sensibles y soient stockés, pareil pour certains paramétrages. Donc perso c’est full chiffrement ou rien. Par contre, ça a un putain d’impact sur les perfs, même si j’ai vu qu’il y avait un peu de mouvement du côté de LUKS pour mieux exploiter certaines instructions CPU afin de gagner du temps et donc des performances.

  • Chiffrement total du PC boulot car déplacé, donnees sensibles etc…. Pas de chiffrement du home du perso qui ne me sers que de « machine à écrire » et ne bouge pas avec trois ou quatre fichiers, le reste est au chaud ailleurs si besoin.
    Bref, faut vraiment distinguer les utilisations mais je pense comme seboss666.
  • Salut , je me met dans la catégorie des personnes qui n’ont pas besoin de plus que chiffrer leur `$HOME`. Mais en effet à la réflexion il peut y avoir des chose dans `/etc` comme les configurations de VPN ou Wifi, mais bon ce n’est pas extrêmement sensible non plus et ça n’entre pas dans mon modèle de menace.
  • Erwann
    La discussion est passionnante.
    Personnellement, pour mon nouveau laptop en attente de configuration, je pensais d’une part utiliser veracrypt sur toutes les partitions à l’exception de la partition système.
    D’autre part, je prévois de mettre les applications de travail et les données dans des machines virtuelles stockées sur les partitions « veracryptées ».
    Ainsi, j’évacue les problèmes potentiels de compatibilité / corruption des partitions boot et système.
    Qu’en pensez-vous ?
    Je suis ouvert à toute remarque et suggestion.
    Merci d’avance pour vos retours.
  • Pierre
    Pour moi c’est du full disk encryption.
    C’est plus sécure, plus simple et plus performant. La seule contrainte serait éventuellement l’impossibilité de faire du wake-on-lan ce dont je n’ai pas besoin.

    On peut aussi trouver des données sensibles dans `/tmp` dans le swap, etc…

  • Erwann
    @Cascador: Merci pour ta réponse.
    Néanmoins, je ne pense pas que mon idée soit une « usine à gaz ».

    Voici mes principaux soucis/besoins :
    1/ En cas de dommage du PC (un PC peut mourir sans crier gare), je veux pouvoir sortir le disque et transférer les données vers un autre support, voire réinstaller le disque dans une autre machine sans problème. Je ne suis pas sûr de pouvoir faire une telle manipulation si tout est chiffré dès l’installation.
    2/ En cas de bug (parfois cela peut arriver, ce n’est pas réservé à M$), je ne veux pas perdre l’accès complet au disque, voire ne plus du tout pouvoir booter.
    3/ Passant régulièrement les frontières (en temps normal), si nécessaire, je veux pouvoir laisser des données (non sensibles) apparentes, tout en préservant les données sensibles.
    4/ Pour des raisons de cybersécurité, je pense confiner la partie messagerie dans une VM spécifique.

    On peut effectivement penser que cela semble être compliqué. Personnellement, je ne le pense pas. En revanche, le choix de l’outil de chiffrement – performant et fiable – reste mon principal souci : quels sont les risques de fiabilité et de performance si je choisis VeraCrypt pour les partitions concernées, ou si j’utilise les outils « natifs » du type eCryptfs.

  • jean-francois gros
    Arch est mieux pour moi sans aucun doute, je suis passe de Debian a Arch (non dérivé) et ne me suis jamais retourne. Mais c’est encore plus important d’etre consistent et de pas se disperser donc je pense que ton choix de rester sur du package .deb est le bon.
    Pour le chiffrement note que lorsque tu utilises AES-NI c’est quasiment du chiffrement hardware et ca ne coute pas trop cher.

    Yo!

  • Pierre
    pourtant tu l’as bien cité la conclusion

    > While full disk encryption consumes more CPU cycles than the home directory encryption, as shown by these test results, the performance tends to be significantly better than with home directory encryption ».

    La puissance des processeurs est faite pour être exploitée, perso à part quand je compile des gros trucs, il est rare que les CPU tournent à 100% donc je préfère un truc dont les performances sont significativement meilleures et qui consomme 4% de CPU qu’un truc plus lent mais qui ne consomme qu’1%.

    C’est comme ces personnes qui ont des machines modernes avec des Gigas de RAM mais qui utilisent un environnement de bureau léger ou qui désactivent plein de trucs pour économiser de la mémoire. Sur une machine aux ressources limitées, je veux bien, c’est logique mais sur une machine de course, je n’en vois pas l’intérêt, autant exploiter la puissance de la bécane pour offrir une meilleur expérience à l’utilisateur.

  • jean-francois gros
    L’utilisation de CPU et de RAM est d’une part pas bonne pour la planete et d’autre part souvent due soit a une certaine fainéantise soit a un code trop complexe. Sur ce dernier point je citerais suckless.org « Code complexity is the mother of bloated, hard to use, and totally inconsistent software. With complex code, problems are solved in suboptimal ways, valuable resources are endlessly tied up, performance slows to a halt, and vulnerabilities become a commonplace. The only solution is to scrap the entire project and rewrite it from scratch. ». Je préfère ne pas m’engager dans la voie, j’ai une becane de compet donc ca m’evite de reflechir, j’envoie la totale, c’est une pente glissante.
    Yo!
  • Pierre
    je ne comprend pas trop le rapport avec le sujet à moins de sous-entendre que parce que le chiffrement du disque consomme plus de CPU que le chiffrement du répertoire home, le code du premier est sans doute plus complexe/moins optimisé et plus susceptible d’être affecté par des vulnérabilités que celui du second or le nombre de vulnérabilités ayant touché le chiffrement du répertoire home est plus important que celui pour le chiffrement du disque et si le chiffrement du disque consomme plus, il s’avère plus performant (donc les tâches s’exécutent plus rapidement, donc elle consomment moins longtemps, donc au final l’impact sur l’autonomie et donc sur l’environnement (parce que la planète elle sera toujours là même si le climat est déréglé) entre les deux solutions est peut-être négligeable selon les usages)
  • Ton ordinateur a un Core-i5 ou un Core-i7 de (quasi) dernière génération, avec les instructions AES-NI, et le stockage est assuré par un SSD en NVMe, je suis pas sûr que tu vas sentir l’impact du chiffrement en terme de performances, ça devrait être négligeable ou du moins imperceptible, donc pour moi y’a pas à hésiter : utilise LUKS car il est proposé par toutes les distributions lors de l’installation donc aucune manip à faire. J’ai testé eCryptfs il y a quelques années et c’était de la merde car un jour j’ai voulu récupérer mes données en LiveUSB etpas moyen, même avec mes mots de passe et clés impossible de déchiffrer. A l’inverse LUKS c’est super fiable. A plus.

Les commentaires sont fermés.