Creo que la versión actual de GRUB2 no tiene soporte para cargar y descifrar particiones LUKS por sí mismo (contiene algunos cifrados pero creo que se usan solo para su soporte de contraseña). No puedo verificar la rama de desarrollo experimental, pero hay algunos indicios en la página de GRUB de que se planea algún trabajo para implementar lo que desea hacer.
Actualización (2015) :la última versión de GRUB2 (2.00) ya incluye código para acceder a las particiones cifradas LUKS y GELI. (El enlace xercestch.com que proporcionó el OP menciona los primeros parches para eso, pero ahora están integrados en la última versión).
Sin embargo, si intenta cifrar todo el disco por motivos de seguridad, tenga en cuenta que un gestor de arranque sin cifrar (como TrueCrypt, BitLocker o un GRUB modificado) no ofrece más protección que un /boot sin cifrar. partición (como señaló JV en un comentario anterior). Cualquier persona con acceso físico a la computadora puede reemplazarla fácilmente con una versión personalizada. Eso incluso se menciona en el artículo en xercestech.com que vinculó:
Para ser claros, esto de ninguna manera hace que su sistema sea menos vulnerable a un ataque fuera de línea, si un atacante reemplazara su gestor de arranque con el suyo propio, o redirigiera el proceso de arranque para arrancar su propio código, su sistema aún puede verse comprometido.
Tenga en cuenta que todos los productos basados en software para el cifrado de disco completo tienen esta debilidad, sin importar si utilizan un gestor de arranque sin cifrar o una partición de arranque/prearranque sin cifrar. Incluso los productos compatibles con chips TPM (Trusted Platform Module), como BitLocker, se pueden rootear sin modificar el hardware.
Un mejor enfoque sería:
- descifrar a nivel de BIOS (en la placa base o adaptador de disco o hardware externo [tarjeta inteligente], con o sin un chip TPM), o
- llevar el código PBA (autorización previa al arranque) (el
/bootpartición en este caso) en un dispositivo extraíble (como una tarjeta inteligente o una memoria USB).
Para hacerlo de la segunda manera, puede consultar el proyecto Linux Full Disk Encryption (LFDE) en:http://lfde.org/ que proporciona un script posterior a la instalación para mover el /boot partición a una unidad USB externa, encriptando la clave con GPG y almacenándola también en el USB. De esa forma, la parte más débil de la ruta de arranque (el /boot no cifrado partición) está siempre con usted (usted será el único con acceso físico al código de descifrado Y la clave). (Nota :este sitio se ha perdido y el blog del autor también desapareció, sin embargo, puede encontrar los archivos antiguos en https://github.com/mv-code/lfde (solo tenga en cuenta que el último desarrollo se realizó hace 6 años). Como alternativa más ligera, puede instalar la partición de arranque sin cifrar en una memoria USB mientras instala su sistema operativo.
Saludos, MV
Haga que su disco RAM inicial y la carpeta /boot no usen cifrado.
Esto abrirá un kernel "mínimo", con controladores y soporte para cambiar al sistema de archivos raíz "real" que es encriptado.
Antes de afirmar que "esto es un truco", recuerde:la mayoría (si no todas) las distribuciones de Linux arrancan de esta manera hoy por defecto. Esto permite explícitamente que su sistema arranque y cargue su FS raíz, utilizando módulos que necesita cargar desde un sistema de archivos. (Una especie de problema del huevo y la gallina). Por ejemplo, si su sistema de archivos raíz estaba en un volumen RAID de hardware y necesitaba cargar su controlador antes de poder montar su FS raíz.
Revisé el enlace que publicaste:aunque no hay una partición de arranque, todavía hay un cargador de arranque sin cifrar en el disco duro al que se puede acceder y comprometer mediante un ataque de sirvienta malvada. He estado investigando una configuración similar, en la que no hay datos sin cifrar en el disco duro, pero hasta ahora solo he encontrado la posibilidad de ejecutar un cargador de arranque desde una unidad extraíble.