Forma correcta de usar el TPM para el cifrado completo del disco

18

Actualmente estoy configurando un equivalente de BitLocker usando un TPM y LUKS. Tengo los conceptos básicos correctos y puedo medir el proceso de arranque y sellar la clave FDE con el TPM.

Cada vez que se actualizan las partes sensibles (firmware, cargador de arranque, kernel), se usa el siguiente comando para sellar la clave de cifrado al nuevo estado del sistema:

tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>

Cuando se inicia el sistema, se usa lo siguiente para abrir la clave que luego se pasa a LUKS para montar el volumen cifrado:

tpm_unsealdata -i <sealed keyfile> -o <temporary keyfile stored in RAM>

Esto funciona y tiene el comportamiento deseado: si el proceso de inicio se ha alterado (digamos que se agrega init=/bin/sh a la línea de comando del kernel para evitar una contraseña de root), el TPM se niega a abrir la clave y el sistema es seguro. .

Sin embargo, tengo algunas preguntas:

Primero, el TPM requiere la contraseña SRK cada vez que se realiza una operación de sellado / desellado. Me gustaría evitar eso y hacer que se comporte como BitLocker, que es transparente y no solicita nada. He pensado en usar una contraseña SRK predeterminada pero aparentemente es inseguro , sin embargo, las respuestas no indican si un atacante que sabe que la contraseña puede desbloquear una clave si los PCR no coinciden con el estado en que se encontraban cuando se selló la clave.

Otra pregunta es qué forma debo usar para sellar las claves, mi forma involucra tpm_sealdata / tpm_unsealdata pero otro proyecto tpm -luks usa tpm-nvread / tpm-nvwrite en su lugar. Me gustaría saber las diferencias y si una forma es más segura que la otra.

    
pregunta André Borie 27.05.2016 - 08:40
fuente

1 respuesta

10

Primero que todo: NO el sistema es 100% seguro, pero usar TPM es mejor que no tener TPM. El chip TPM es solo una especie de almacenamiento encriptado, que reside en la placa base de las computadoras compatibles con el entorno de plataforma confiable, y tiene BIOS preparados para manejarlo.

Los PCR son registros con funciones específicas que se manejan a través de la operación TPM_Extend . No pueden ser "establecidos", solo extendidos (new_hash = [old_hash || new_measurement]).

TPM tiene una raíz estática de confianza para las mediciones (SRTM) y una raíz dinámica de confianza para las mediciones (DRTM), y la combinación de ambas crea un entorno seguro. Este tipo explica muy bien cómo se hace esto. Es una cadena de confianza entre elementos fijos y dinámicos.

Volver a los PCR, son registros independientes de la plataforma, y los más comunes son:

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used 

Los portátiles basados en Intel utilizan comúnmente los primeros 16 registros, pero podrían extenderse a otros softwares / usos.

Mientras escribe información (sellado) en TPM, puede agregar una clave de raíz de almacenamiento (SRK) que de alguna manera es una "clave de administración" y se usa para agregar otras claves a este almacenamiento. Según páginas de manual , usar -z establecerá TSS_WELL_KNOWN_SECRET (20 zero bytes) .

-z, --well-known
    Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password. 
    You will not be prompted for the SRK password with this option. 

Por lo tanto, tener este SRK configurado en el secreto predeterminado ( TSS_WELL_KNOWN_SECRET ) no será suficiente para atacar a alguien, ya que el TPM solo se puede deseleccionar si los PCR actuales coinciden con los utilizados para sellar los datos. Además, parte del manejo de la PCR ocurre en el momento del arranque (BIOS) y es muy difícil manipularlos y, por lo tanto, crear PCR "falsos". BIOS es el único lugar donde los PCR se ven como ceros antes de que tenga lugar el resto del proceso.

El único ataque FASABLE es el que apunta a las comunicaciones MITM entre BIOS y PCR a ceros PCR sin reiniciar la máquina para poner el sistema en estado "confiable". Este ataque se conoce como TPM Reset Attack .

  

El ataque

     

Entonces, dado todo lo que hemos visto anteriormente, debería ser muy difícil   Falsificar un proceso de arranque confiable, siempre y cuando el BIOS tome los primeros   mediciones. El supuesto crítico aquí es que los PCR no pueden ser   Restablecer fácilmente sin reiniciar toda la plataforma que el TPM   reside en. Si un atacante es capaz de controlar las medidas.   enviados a los PCR por el BIOS (con, por ejemplo, un analizador lógico, consulte   este documento), y capaz de poner a cero los PCR sin reiniciar   la máquina, entonces ella podría tomar una plataforma en cualquier configuración y   ponerlo en un estado de "confianza". Entonces, la parte difícil es conseguir el   TPM para restablecer sin derribar toda la máquina. Vale la pena   Mencionando que también hemos examinado la memoria interpuesta y otros tales   cosas para cambiar el sistema en ejecución después de que se ha medido, pero debido   a la velocidad de los buses donde se encuentran la memoria y los discos duros, esto es   Un esfuerzo complicado. Atacar a un autobús más lento es mucho más fácil.

     

Los TPM normalmente residen en el bus de Low Pin Count (LPC). El bus LPC   Es compatible con una línea de reinicio por tierra. Esto significa que cuando este   Línea particular en el bus es conducida a tierra cada dispositivo en este   Se supone que el autobús se reinicie. Otros dispositivos conectados a este bus incluyen   El BIOS, y los controladores de teclado y mouse heredados. El video de abajo   demuestra que conducir esta línea es de hecho posible, y bastante   fácil de hacer. Tenga en cuenta que en el video, estamos accediendo a la   ordenador en cuestión a través de una sesión remota ssh. Esto es porque el   el controlador del teclado y el mouse se reinician cuando manejamos el pin de reinicio,   pero la tarjeta de red no lo hace. Más detalles de este ataque (y   otros!) se pueden ver en mi tesis de honores: una evaluación de seguridad   de Trusted Platform Modules, Dartmouth College Computer Science   Informe Técnico TR2007-597.

Tenga en cuenta que esta es una versión simplificada de TODAS LAS COSAS que involucran a Trusted Computing . Por favor, eche un vistazo a la Documento de Arquitectura de TPMv2 para obtener más información sobre todas las operaciones que ocurren entre biografías, hardware y software durante la configuración de un entorno confiable.

tl; dr : el uso de la clave de la raíz de almacenamiento predeterminada (20 bytes cero) no es suficiente para crear un sistema inseguro.

Cosas relacionadas:

respondido por el nwildner 03.06.2016 - 19:12
fuente

Lea otras preguntas en las etiquetas