Le 04/01/2020 à 02:50, G2PC a écrit :
Ce n'est pas suffisant. Le chiffrement seul protège contre la divulgation des données en cas de perte ou de vol, mais pas contre une intervention illicite non détectée sur la partie du système qui doit inévitablement rester non chiffrée. Ne pas oublier qu'une installation standard de Debian avec chiffrement laisse l'intégralité de /boot en clair, ce qui inclut le chargeur d'amorçage, l'image du noyau et l'initramfs. GRUB et le noyau peuvent être protégés par le secure boot UEFI, mais pas l'initramfs ni la configuration de GRUB.Pour ma part, j'ai comme un doute pour le secure boot UEFI.
Un doute à propos de quoi exactement concernant le secure boot ?
J'ai installé Debian, Windows, et, Mint, en dual Boot. Pour cela, j'ai bien du désactiver le secure boot UEFI depuis le BIOS.
Pourtant en principe ces trois OS sont compatibles avec le secure boot (Debian depuis la version 10).
Dès lors le chargeur d'amorçage, l'image du noyau et l'initramfs ne sont pas protégés ?
Non puisque le firmware ne va pas vérifier l'intégrité du chargeur d'amorçage qui ne va pas vérifier l'intégrité de l'image du noyau et ainsi de suite.
Quels sont les conséquences ? Le chiffrement du disque pourrait alors être rendu inopérant ?
Un attaquant qui a un accès physique à la machine pourrait modifier l'initramfs pour intercepter et enregistrer la phrase de passe de chiffrement, attendre qu'un utilisateur légitime tape la phrase de passe, puis la récupérer et déchiffrer le disque.
Mais une telle modification est détectable en introduisant dans la partie chiffrée du système (inaccessible à l'attaquant tant qu'il n'a pas récupéré la passphrase) une vérification de l'intégrité des fichiers de démarrage. Pour contrer cette protection, l'attaquant peut introduire dans le noyau (image principale ou module inclus dans l'initramfs) un rootkit qui masque les fichiers modifiés et présente les fichiers originels à la place.
Le secure boot n'empêcherait pas la modification des fichiers de démarrage mais empêcherait de démarrer avec un noyau compromis masquant les modifications. Certes l'initramfs compromis pourrait aussi désactiver la détection une fois le disque déchiffré avant de passer la main au système principal, mais cela suppose que l'attaquant a une connaissance a priori du mécanisme de cette détection, donc accès d'une façon ou d'une autre au système déchiffré ou à ses spécifications.