DEFCON 21. Las contraseñas por sí solas no son suficientes, o por qué se "rompe" el cifrado del disco y cómo se puede solucionar. Parte 2

DEFCON 21. Las contraseñas por sí solas no son suficientes, o por qué se "rompe" el cifrado del disco y cómo se puede solucionar. Parte 1

Hay cosas divertidas, como contadores que aumentan monotónicamente, con los que puede controlar la actividad de TMP y luego verificar los valores recibidos. Hay un pequeño rango de memoria no volátil que puede usarse para sus necesidades, no es tan grande como un kilobyte, pero también puede ser útil. Hay un contador de reloj que le permite determinar cuánto tiempo ha estado funcionando el sistema desde el último inicio. Hay comandos que puede darle a TMP para que haga cosas en su nombre, incluida la limpieza de su propia memoria si es necesario.



Luego, queremos desarrollar un protocolo que el usuario pueda ejecutar en la computadora para asegurarse de que la computadora no haya sido pirateada, antes de que se autentique en la computadora y comience a usarla. ¿Qué es útil para tal protocolo? ¿Podemos intentar "sellar" en los registros de configuración de la plataforma?

Tengo un par de sugerencias: estos son tokens para contraseñas de usuario únicas, una imagen o animación única, por ejemplo, su foto, algo original que no es fácil de encontrar en otro lugar. También puede desactivar la "salida de video" en su computadora cuando se encuentra en modo de solicitud y autenticación.

También es posible que desee "sellar" parte de la clave del disco, y hay varias razones por las que desea hacer esto. Bajo ciertas suposiciones de seguridad, esto asegura que el sistema solo se iniciará en alguna configuración de software aprobada que usted controla como propietario de la computadora. En última instancia, esto significa que cualquier persona que quiera atacar su sistema debe hacerlo pirateando TMP o en el entorno limitado que creó para ellos. Por supuesto, esta no es una protección criptográfica particularmente fuerte, ya que no tendrá un protocolo que permita al usuario autenticarse de forma segura con el mismo nivel de seguridad que proporciona AES, por ejemplo. Pero si no puede organizar algo como el cifrado RSA en su propia cabeza, nunca será perfecto.



Mencioné que en TPM hay un comando de borrado automático que se puede ejecutar a través del software. Dado que TPM requiere una determinada configuración del sistema, antes de que revele "secretos", puede hacer algo interesante, por ejemplo, la autodestrucción. Puede desarrollar software y crear su propio protocolo para limitar el número de inicios fallidos de la computadora, puede establecer un tiempo de espera después de que la contraseña haya estado en la pantalla durante un cierto período de tiempo o limitar el número de intentos de ingresar la contraseña incorrecta.

Puede establecer el límite de tiempo para reiniciar la computadora después del ciclo de trabajo anterior, si la computadora estuvo en el "estado congelado" durante una o dos semanas, restrinja el acceso a la computadora por el período de tiempo en el que va a ir al extranjero: la bloquea mientras está en Desbloquear el camino antes de llegar al hotel.

También puede hacer algunas cosas divertidas, por ejemplo, dejar pequeños "canarios" en un disco que contenga datos críticos desde el punto de vista de la seguridad. De hecho, estas serán simplemente "estrías", cuyo desencadenamiento conducirá a un cambio en los valores del contador monótono dentro del TPM.

También puede crear una contraseña de autodestrucción o un código forzado para ejecutar automáticamente un comando de reinicio. Dado que un atacante puede atacar de dos maneras: piratear un módulo de plataforma confiable o ejecutar un software malicioso, puede obligarlo a cumplir con estas reglas y realmente realizar una autodestrucción efectiva.

Trusted Platform Module está específicamente diseñado para ser muy difícil de copiar, por lo que no es posible simplemente clonarlo. De esta manera, puede usar cosas como contadores monótonos para detectar cualquier ataque de recuperación o reproducción de disco. Y tan pronto como se ejecute el comando clear en TPM, para un atacante que quiera acceder a sus datos, el juego terminará.
Hay algunas similitudes con el sistema que Jacob Appelbaum discutió en la conferencia del Congreso de Comunicación del Caos hace muchos años, en 2005. Sugirió usar un servidor de red remoto para implementar muchas de estas opciones, pero reconoció que sería difícil de usar en la práctica. Como TPM es un componente integrado del sistema, puede obtener muchos beneficios solo con el módulo TPM incorporado, y no con el módulo ubicado en el servidor remoto. Un enfoque híbrido es potencialmente posible. Puede configurar el sistema, por ejemplo, como en el departamento de TI, cuando bloquea temporalmente el sistema, y ​​puede estar disponible solo después de conectarlo a la red, llame a su administrador de TI y lo desbloquearán. Dudo en empujar la pila de red al comienzo del proceso de arranque, simplemente porque aumenta significativamente la superficie de ataque. Pero aún es posible.

Quiero aclarar que un atacante solo puede hacer esto, suponiendo que no podrá romper TPM fácilmente. La siguiente diapositiva muestra una imagen del diseño del chip TPM, realizado por Chris Tarnovsky con un microscopio. Chris habló con DefCon el año pasado e hizo una presentación en la conferencia BlackHat sobre la seguridad de TPM hace unos años.
Realmente hizo un gran trabajo para comprender lo difícil que es romper esto. Enumeró las contramedidas, descubrió lo que se necesitaría para romper esto, y luego probó todo el chip. Hay detectores de luz, redes activas en la placa TPM, se implementan varios esquemas completamente locos para engañar al atacante en cuanto a lo que realmente hace este módulo.

Pero si dedica suficiente tiempo y recursos y tiene cuidado, puede sortear la mayoría de las medidas de protección. Puede quitar el chip, colocarlo con un microscopio electrónico en una estación de trabajo, encontrar dónde está ubicado el bus con datos no encriptados y extraer todos los secretos de él. Sin embargo, tal ataque, incluso si se preparó cuidadosamente para ello y se da cuenta de dónde se encuentra utilizando un microscopio costoso, aún requerirá tiempo y esfuerzo para eliminar la protección física del chip y no "freírlo" accidentalmente durante el desmantelamiento .



Considere un ataque de reinicio. Mencioné anteriormente que en casi todos los casos, TPM es un chip separado en la placa base. Este es un enlace muy bajo en la jerarquía del sistema. No es parte de la CPU, como se hace con DRM en las consolas de video. Por lo tanto, si un hacker logra reiniciar TPM, esto no tendrá un efecto irreversible en el sistema. Esto es malo, porque tal ataque puede pasar desapercibido para usted.



Este suele ser un chip que se encuentra fuera del bus de la computadora LPC, que en sí mismo es un bus obsoleto y se encuentra fuera del puente sur de la placa base. En los sistemas modernos, las únicas cosas ubicadas en la superficie de la placa base son TPM, BIOS, controladores de teclado, pero creo que, de hecho, los controladores flexibles ya no lo usan. Y si encuentra una manera de reiniciar el bus con una pequeña cantidad de contactos, restablecerá el TPM al estado de arranque del "nuevo sistema operativo". Probablemente perderá acceso al teclado a través del conector PS / 2, pero esto no es un gran problema, pero puede reproducir la secuencia de arranque TPM en la que los datos secretos están "sellados" sin realizar una secuencia segura, y puede usarla para extraer los datos.

Hay varios ataques que intentan usar este método. Si TPM usa un modo antiguo llamado Raíz de confianza estática para la medición (SRTM), puede hacerlo con bastante facilidad. No he visto ninguna investigación sobre ataques exitosos contra nuevas tecnologías confiables para implementar opciones de activación de módulos Intel. Probablemente todavía sea posible capturar el bus LPC y lo que pasa a la CPU es un área que necesita más investigación. Esta podría ser otra forma de atacar un módulo de plataforma confiable.
Entonces, veamos un diagrama de lo que necesitamos para tener un sistema de arranque en frío con una configuración confiable. Hay muchos componentes bastante vulnerables en la arquitectura de la PC.



Por ejemplo, en el BIOS puede capturar la tabla de vectores de interrupción y modificar los derechos de lectura del disco, o interceptar la entrada del teclado, enmascarar todas las funciones de los registros de la CPU: hay muchas opciones de ataque. En mi opinión, no necesita hacer una comprobación de seguridad en el modo de arranque real del BIOS, solo necesita medir el rendimiento del proceso de arranque.

Tan pronto como ingresa al modo "preboot", que es realmente solo su sistema operativo, como el disco RAM inicial de Linux, comienza a ejecutar su protocolo y hacer estas cosas. Quiero decir, tan pronto como comiences a usar los recursos del sistema operativo, lo que alguien haga a nivel de BIOS, que opera con la tabla de interrupciones, no te afectará de ninguna manera. Realmente no te importará.

Puede verificar el rendimiento de los registros. Por ejemplo, si trabaja con el procesador Core i5, entonces sabe que admitirá cosas como el bit de prohibición de ejecución, los registros de depuración y otras cosas que las personas pueden intentar disfrazar en las capacidades de registro.

Esta diapositiva muestra cómo debería verse el diagrama del sistema cuando se inicia en una configuración de trabajo.



Hubo un proyecto llamado BitVisor que implementó muchos aspectos de la seguridad de cifrado de disco utilizando registros de procesador y protección IOMMU en su memoria principal. El problema es que BitVisor es un programa bastante específico y poco utilizado.
Xen es una especie de hipervisor canónico de código abierto que participa en muchos estudios de seguridad, durante los cuales las personas están convencidas de que funciona. En mi opinión, deberíamos usar el hipervisor Xen como interfaz de hardware de nivel básico y luego agregarle el dominio administrativo dom0 de Linux para inicializar su hardware.

Nuevamente, en Xen, todos sus dominios virtualizados funcionan en modo no privilegiado, por lo que en realidad no tiene acceso directo a los registros de depuración, esta es una de las cosas que ya se ha hecho. Xen crea hipercalls que le dan acceso a tales cosas, pero puede desactivar esta función en el software.

Entonces, el enfoque que uso es que colocamos la clave maestra en los registros de depuración. Distinguimos los dos primeros registros de depuración para almacenar la clave AES de 128 bits, que es nuestra clave maestra.



Esto nunca abandona los registros de la CPU después de que es ingresado por un proceso que acepta credenciales de usuario. Luego usamos los dos segundos registros como registros específicos de la máquina virtual: pueden usarse como registros de depuración ordinarios o, como en este caso, podemos usarlos para cifrar la memoria principal. En este caso particular, necesitamos tener varios dispositivos que estén directamente conectados al dominio administrativo. Este es un procesador de gráficos, que es un dispositivo PCI, teclado, TPM, todo esto debe ser accesible directamente.

No puede usar la protección IOMMU para estas cosas, pero puede configurar esta protección para un controlador de red, controlador de almacenamiento, dispositivos arbitrarios en el bus PCI, es decir, para componentes que no tienen acceso al dominio administrativo o espacios de memoria del hipervisor. Puede acceder a cosas como una red colocando el controlador de red en una máquina virtual Net VM dedicada. Estas cosas se asignarán a dispositivos específicos que tengan configurada la seguridad de IOMMU, de modo que dicho dispositivo solo pueda acceder al área de memoria de esta máquina virtual.

Puede hacer lo mismo con el controlador de almacenamiento y luego ejecutar todas las aplicaciones en máquinas virtuales de aplicaciones con acceso directo al hardware absolutamente cero. Por lo tanto, incluso si alguien toma el control de su navegador web o le envía un archivo PDF malicioso, no recibirá nada que pueda comprometer seriamente el cifrado del disco.

No puedo asumir la responsabilidad de este diseño arquitectónico, porque de hecho es la base de un excelente proyecto llamado Qubes OS.



Sus desarrolladores describen este proyecto como una formación pragmática de Xen, Linux y varias herramientas personalizadas para implementar muchas de las cosas de las que acabo de hablar. Qubes OS implementa una política de invitados no privilegiados y crea un entorno de sistema unificado, por lo que parece que está trabajando con el mismo sistema, pero de hecho es un montón de máquinas virtuales diferentes "bajo una sola capucha". Utilizo esta idea para implementar mi código base.

Entonces, la herramienta que estoy desarrollando es un código experimental que confirma este concepto, lo llamé Phalanx. Este es un Xen parcheado que le permite implementar cifrado de disco utilizando la tecnología que describí.



La clave maestra se encuentra en los primeros 2 registros de depuración DR1-2, los segundos dos registros de depuración DR2-3 son absolutamente ilimitados por domU. Por razones de seguridad, XMM registra 0-12, utilizado como memoria operativa, DR2-3, y la clave se cifra cuando la máquina virtual cambia de contexto. También hice una implementación de cifrado muy simple usando el módulo de kernel zRAM de Linux, porque es un elemento incorporado que hace casi todo excepto la criptografía, por lo que para el cifrado agregué un pequeño fragmento de código encima. Como sabe, el código más seguro es el código que no necesita escribir. Una buena característica de zRAM es que le proporciona un montón de bits que son necesarios para implementar de forma segura cosas como AES Counter-Mode.

Tenemos varios requisitos de hardware. Necesita un sistema que admita las nuevas instrucciones AES, que son bastante comunes, pero no todos los sistemas las tienen. Lo más probable es que si tiene un procesador Intel i5 o i7, estas instrucciones sean compatibles.



Pero el resto del "hardware" debe verificarse para asegurarse de que sea compatible con todas las funciones necesarias. Las extensiones de hardware de virtualización HVE se generalizaron alrededor de 2006. Será un poco más difícil encontrar una computadora con IOMMU. Esto no se indica en la especificación de la unidad del sistema, y ​​deberá profundizar en sus características, y también averiguar cuál es la diferencia entre VTX y VTD, etc. Por lo tanto, es posible que deba buscar un sistema que admita estas cosas. Y, por supuesto, necesita un sistema con un módulo de plataforma TPM confiable, porque de lo contrario no podrá medir las métricas de carga. Por lo general, observa las computadoras de clase empresarial donde puede verificar la disponibilidad de los componentes necesarios. Si encuentra Intel TXT con tecnología Trusted Execution, tendrá casi todo lo que necesita. El equipo de Qubes en su Wiki presenta una excelente lista de compatibilidad de hardware, que enumera los detalles de muchos sistemas que implementan tales cosas.

Entonces, para garantizar la seguridad, tenemos varios supuestos sobre algunos componentes del sistema. TPM, por supuesto, es un componente muy importante para garantizar la integridad del arranque. Debe asegurarse de que no haya una puerta trasera que pueda restablecer la NVRAM, manipular contadores monótonos o hacer que el sistema piense que está utilizando un estado confiable, aunque en realidad no lo es. Basado en los comentarios de Tarnovsky, quien realizó la ingeniería inversa de estos chips, establecí un límite de aproximadamente 12 horas de acceso exclusivo a la computadora, que es necesario si desea lanzar un ataque TPM para obtener todos los secretos.

\

Hay varias suposiciones con respecto al procesador, el controlador de memoria y la IOMMU, principalmente con respecto al hecho de que no están pirateadas e implementan correctamente sus funciones. Algunas de estas suposiciones no tienen que ser muy estrictas, porque Intel puede sortear fácilmente algunas de estas cosas, y no tenemos forma de averiguarlo.

Algunos de los supuestos de seguridad conciernen a Xen. Este es un software que tiene un sistema de seguridad muy poderoso, pero nada es perfecto, y algunas veces surgen vulnerabilidades incluso en un sistema seguro. Dado que Xen tiene una posición privilegiada en el sistema, es muy importante asegurarse de que se encuentre en un estado seguro.
, . , , , , - . , . , .
, – . , , , , .



, , , . , , , — , , , .

— , . FDE , RAM.

, IOMMU, . TPM NVRAM, , – , , .

, , , 12 . , .

, , . , .

TPM — NVRAM, / LPC. TPM , , , , .



RAM . , RAM RAM, , , . , , Sony PS3.

, . , . , , , , , TPM . , , , , , RIPA – , .
. , , , . .

-, . OpenSSL , API, .

Qubes OS.



: , . .

– .

, , -. , , , . Gracias por su atencion!


Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta la primavera sin cargo al pagar durante medio año, puede ordenar aquí .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?