j'ai remarqué qu'a chaque fois qu'on crypte une installation d'une distro avec LUKS la partition boot elle restait sans cryptage.

Quel sont les raison ? ne serait-il pas plus intelligent de crypter depuis le boot et de demander le mot de passe depuis grub au lieu de systemd ?

J'ai pas la réponse à ta question, mais quelques suppositions.

1. Chiffrer /boot avec LUKS demande d'utiliser un bootloader capable de déchiffrer une partition LUKS. C'est le cas de Grub depuis apparemment la 2.0.0 (juin 2012), mais cette version est apparue Debian unstable il y a à peine plus d'un an ; peut-être que c'est encore trop jeune ?
2. C'est pas plus sécurisé si tu considères dans ton modèle de menace qu'un attaquant peut avoir un accès offline au système, puisqu'il pourrait altérer le bootloader non chiffré autant qu'il aurait pu altérer le /boot non chiffré avant [0] (sauf Secure Boot apparemment [1], mais ça demanderait aux distros de signer leur bootloader avec une clé autorisée par Microsoft ou d'ajouter la clé de ta distro au firmware UEFI [2]). Celà dit, sans Secure Boot, c'est peut-être plus technique qu'avec un /boot en clair [3].
3. Ça demande de faire des compromis discutables par rapport à un /boot non chiffré (pour un résultat lui aussi discutable d'après le point précédent). Si tu dis à Grub de déchiffrer la partition de boot, il te demandera le mot de passe au boot, mais tu devras le rentrer à nouveau pendant l'initialisation de ton système, car Grub démonte la partition avant de passer la main au kernel, qui devra à son tour la déchiffrer (que le boot soit sur une partition différente ou pas). Si tu veux rentrer qu'un seul mot de passe, tu dois ajouter une clé de déchiffrement, la stocker sur la partition de boot (chiffrée), et dire au kernel de l'utiliser pour déchiffrer la partition racine. Ça implique qu'elle est en clair dans l'initramfs tant qu'il est monté [4]… mais c'est peut-être pas un problème selon les permissions qui sont mises dessus ?
4. Une autre solution qui semble plus largement adoptée est d'avoir la partition de boot sur un support amovible (et bien sûr de ne pas laisser ce dernier traîner quelque part sans surveillance) – solution qui s'intègre plus facilement que le /boot chiffré, et qui peut être considérée comme plus sécurisée selon l'attention que tu apportes au support amovible qui contient le boot.

[0] https://xercestech.com/full-system-encryption-for-linux.geek
[1] http://michael-prokop.at/blog/2014/02/28/full-crypto-setup-with-grub2/#comment-16035
[2] http://www.howtogeek.com/175641/how-to-boot-and-install-linux-on-a-uefi-pc-with-secure-boot/
[3] https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/
[4] http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#security-considerations

Le 21 mars 2015 à 10:57:21 vava740 a écrit :
J'ai pas la réponse à ta question, mais quelques suppositions.

1. Chiffrer /boot avec LUKS demande d'utiliser un bootloader capable de déchiffrer une partition LUKS. C'est le cas de Grub depuis apparemment la 2.0.0 (juin 2012), mais cette version est apparue Debian unstable il y a à peine plus d'un an ; peut-être que c'est encore trop jeune ?
2. C'est pas plus sécurisé si tu considères dans ton modèle de menace qu'un attaquant peut avoir un accès offline au système, puisqu'il pourrait altérer le bootloader non chiffré autant qu'il aurait pu altérer le /boot non chiffré avant [0] (sauf Secure Boot apparemment [1], mais ça demanderait aux distros de signer leur bootloader avec une clé autorisée par Microsoft ou d'ajouter la clé de ta distro au firmware UEFI [2]). Celà dit, sans Secure Boot, c'est peut-être plus technique qu'avec un /boot en clair [3].
3. Ça demande de faire des compromis discutables par rapport à un /boot non chiffré (pour un résultat lui aussi discutable d'après le point précédent). Si tu dis à Grub de déchiffrer la partition de boot, il te demandera le mot de passe au boot, mais tu devras le rentrer à nouveau pendant l'initialisation de ton système, car Grub démonte la partition avant de passer la main au kernel, qui devra à son tour la déchiffrer (que le boot soit sur une partition différente ou pas). Si tu veux rentrer qu'un seul mot de passe, tu dois ajouter une clé de déchiffrement, la stocker sur la partition de boot (chiffrée), et dire au kernel de l'utiliser pour déchiffrer la partition racine. Ça implique qu'elle est en clair dans l'initramfs tant qu'il est monté [4]… mais c'est peut-être pas un problème selon les permissions qui sont mises dessus ?
4. Une autre solution qui semble plus largement adoptée est d'avoir la partition de boot sur un support amovible (et bien sûr de ne pas laisser ce dernier traîner quelque part sans surveillance) – solution qui s'intègre plus facilement que le /boot chiffré, et qui peut être considérée comme plus sécurisée selon l'attention que tu apportes au support amovible qui contient le boot.

[0] https://xercestech.com/full-system-encryption-for-linux.geek
[1] http://michael-prokop.at/blog/2014/02/28/full-crypto-setup-with-grub2/#comment-16035
[2] http://www.howtogeek.com/175641/how-to-boot-and-install-linux-on-a-uefi-pc-with-secure-boot/
[3] https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/
[4] http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#security-considerations

merci pour ta réponse trés précise