Journal Le LUKS, version 2

Posté par Glandos le 14 décembre 2017 à 09:46. Licence CC By‑SA.

Étiquettes :

déc.

2017

Bon alors, les crypto-nerds, vous êtes plus flemmard que moi ?

Cryptsetup 2 est sorti

Euh, bon, je met vite fait ce que j'ai vu :

Nouveau format LUKS2, que l'on peut (la plupart du temps) mettre à jour depuis LUKS1
LUKS1 sera supporté pour toujours
LUKS2 sait faire de l'intégrité. Attention, c'est encore expérimental
Support de chiffrement de mot passe plus résistant à la force brute (genre coûteux en mémoire) avec PBKDF et Argon2
Options de montage persistantes dans les en-têtes. Comme tune2fs. Je crois que ça va être bien.
Il est possible (si j'ai bien compris), de dire à cryptsetup de stocker un jeton pour dire de trouver le mot de passe tout seul dans un gestionnaire de clés. C'est pas clair pour moi non plus, parce que j'ai lu en diagonale.

Bonus

Y a du JSON dedans. C'est très hype (mais surtout extensible)

Voilà, c'est très résumé. Parce que je suis tellement flemmard que je dois le répéter deux fois.

# Jeton à l'avance

Posté par Adrien BUSTANY (site web personnel) le 14 décembre 2017 à 10:28. Évalué à 2.

Il est possible (si j'ai bien compris), de dire à cryptsetup de stocker un jeton pour dire de trouver le mot de passe tout seul dans un gestionnaire de clés. C'est pas clair pour moi non plus, parce que j'ai lu en diagonale.

Si j'ai bien compris, c'est pour pour permettre à une autre application de peupler ce jeton (token) avant l'appel à cryptsetup, depuis une source quelconque (smartcard, etc.), dans un endroit sûr (le keyring du kernel).
- [^] # Re: Jeton à l'avance
  
  Posté par Misc (site web personnel) le 14 décembre 2017 à 11:30. Évalué à 6.
  
  Oui, genre tang/clevis, comme expliqué sur https://blog.delouw.ch/2017/10/01/leveraging-network-bound-disk-encryption-at-enterprise-scale/
  
  Tang est dispo dans Centos 7.4 et Fedora, mais j’espère que ça va vite être adopté par les autres distributions Linux.
# Le portage, c'est du LUKS ?

Posté par Renault (site web personnel) le 14 décembre 2017 à 16:20. Évalué à 7.

Nouveau format LUKS2, que l'on peut (la plupart du temps) mettre à jour depuis LUKS1

C'est une procédure simple et sans perte ? Quelles sont les fameux cas gênants ?

Notez le jeu de mot dans le titre.
# Garanties ?

Posté par Kerro le 14 décembre 2017 à 19:45. Évalué à 2.

Deux questions liée à LUKS, mais pas vraiment à ce journal :

Garantie d'effacement des clefs :
Un des points faibles des systèmes de fichiers chiffrés est l'attaque « cold boot » (valable également pour d'autres choses).
Si on a un « capteur de danger », par exemple on retire une clef USB spécifique, ou un détecteur d'intrusion dans l'enceinte du serveur, etc, on peut imaginer que cela verrouille le système de fichiers.
A-t-on la garantie que rien ne reste en mémoire une fois qu'on a fermé le système de fichiers chiffré ? De sorte qu'une attaque cold boot ne donne rien.

Garantie anti-homme-au-milieu :
Si on a une machine distante, par exemple dans un centre de données, comment garantir que personne ne viendra modifier le matériel ou le logiciel afin que la clef ne soit pas interceptée lorsqu'on déverrouille ?
On ne peut pas avec LUKS, mais y-a-t'il moyen d'imaginer un système multi-machines qui fait qu'une machine compromise silencieusement ne permette rien ? J'en doute fortement, mais mes compétences dans ce domaine sont moyennes.
- [^] # Re: Garanties ?
  
  Posté par bubar🦥 (Mastodon) le 14 décembre 2017 à 20:42. Évalué à 5. Dernière modification le 14 décembre 2017 à 22:11.
  
  Comme ton commentaire n'est pas directement en rapport avec le journal, je me permet un commentaire qui n'est pas directement en rapport avec le tiens.
  
  Perso j'utilise usbguard.
  Au lancement il met en liste blanche les éléments connectés. Je prends soin de retirer de cette liste blanche les ilos/aloms/et autres gadgets fournis de base par les loueurs de serveurs. Voilà, aucune clef usb, ou clavier, ou autre, qui serait connecté à mon serveur à chaud ne sera accepté.
  usbguard saybien
- [^] # Re: Garanties ?
  
  Posté par khivapia le 15 décembre 2017 à 17:00. Évalué à 4.
  
  A-t-on la garantie que rien ne reste en mémoire une fois qu'on a fermé le système de fichiers chiffré ?
  Normalement tout logiciel de sécurité devrait effacer ses secrets de la mémoire, de sorte qu'entre autres les clefs ne traînent pas un peu partout (par exemple dans le swap :-).
  
  Si on a une machine distante, par exemple dans un centre de données, comment garantir que personne ne viendra modifier le matériel ou le logiciel afin que la clef ne soit pas interceptée lorsqu'on déverrouille ?
  Tu ne peux pas :-)
  De plus sans garde physique de la machine, rien ne te garantit qu'un attaquant n'est pas venu dumper tes clefs sur ta machine distante allumée, peut-être avec du matériel de folie (ou alors de la virtualisation) dès que tu n'as pas ta machine sous les yeux.
  
  Parfois certains composants sont dédiés à la sécurité pour ce genre de problème (faire de la sécurité en environnement hostile), par exemple les cartes à puce, mais les protocoles gérés sont limités (bref : on n'est alors pas sur un PC).
  Certaines des attaques de type lecture de mémoire ou de bus à chaud sont parées par le chiffrement de la mémoire vive proposé par les processeurs AMD pour serveur les plus récents. Mais ce n'est pas une généralité.
  
  Et quoi qu'il en soit, pour la sécurité une étape de 'bootstrap' est toujours nécessaire, qui doit être faite en environnement de confiance (donc pas à distance). Sinon on n'a proprement aucune garantie.
# Chiffrement sur installation

Posté par ff9097 le 16 décembre 2017 à 17:35. Évalué à 1.

J'ai du mal à trouver une documentation fiable et à jour pour chiffrer une Fedora (/ out /home) post-installation. Quelqu'un a un lien pour moi ? Merci
- [^] # Re: Chiffrement sur installation
  
  Posté par Mathieu le 18 décembre 2017 à 13:27. Évalué à 2.
  EcryptFS fournit ecryptfs-migrate-home qui fait exactement ça (migrer le $HOME d'un utilisateur à la volée). Il est inclut dans le paquet ecryptfs-utils de Debian, ça doit être pareil pour Fedora, je suppose. Pour Debian/Ubuntu, ça donne quelque chose comme ça :
```
# Directement en tant que l'utilisateur à migrer, bob, après s'être déconnecté de X
# et *sans passer par SSH* (sous peine d'avoir une erreur mount: mount(2) failed:
# No such file or directory).
# Ne pas oublier de se (re)connecter *avant* de rebooter !

sudo apt-get install ecryptfs-utils rsync
sudo modprobe ecryptfs
sudo ecryptfs-migrate-home -u bob
# Tuer les éventuels process gênants qui seront détectés.

# Chiffrer aussi la swap :
sudo apt-get install cryptsetup
sudo ecryptfs-setup-swap

# Pour pouvoir s'y logguer avec une clé SSH :
cd /home
sudo umount /home/bob
cd /home/bob
sudo mkdir -m 0700 .ssh
sudo chown bob: .ssh
echo "ssh-rsa AAAAB3..." > .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
```
  - [^] # Re: Chiffrement sur installation
    
    Posté par ff9097 le 18 décembre 2017 à 13:55. Évalué à 1.
    
    Merci je testerai ça et ferai un retour
  - [^] # Re: Chiffrement sur installation
    
    Posté par ff9097 le 18 décembre 2017 à 15:03. Évalué à 1.
    
    Merci je testerai ça et ferai un retour

Suivre le flux des commentaires

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