Journal Le LUKS, version 2

Posté par  . Licence CC By‑SA.
Étiquettes :
17
14
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  (site web personnel) . É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).

  • # Le portage, c'est du LUKS ?

    Posté par  (site web personnel) . É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  . É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  (Mastodon) . É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  . É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  . É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  . É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

Suivre le flux des commentaires

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