Limpie la RAM al apagar para evitar el ataque de arranque en frío

Mi sistema está encriptado usando Full Disk Encryption, es decir, todo excepto / boot está encriptado usando dmcrypt / luks. Me preocupan los ataques de arranque en frío , donde los investigadores demostraron que el contenido podría extraerse durante unos 5 minutos .

¿Puede proporcionar instrucciones sobre:

• cómo activar kexec en un nuevo núcleo en los últimos pasos del proceso de apagado / reinicio (para garantizar un desmontaje limpio, para evitar la corrupción del sistema de archivos, para garantizar que el antiguo núcleo se sobrescriba)
• cómo crear ese núcleo, que borra todo el carnero

Es decir, ¿puedes explicar por favor cómo hacer lo mismo en Ubuntu?

¿Cómo detectar el apagado? ¿Cómo iniciar el borrado de RAM? La RAM debe limpiarse cuando el usuario hace clic en "apagar" o si comienza un "script de pánico".

¡Gracias por tus esfuerzos!

Trabajo prioritario:

• Introducción a Tails RAM Wipe
• Más información sobre la implementación de Tails RAM Wipe
• Introducción de Liberte Linux RAM Wipe
• Más detalles de implementación sobre la implementación Liberte Linux RAM Wipe
• memtest no borrando todo
• Prueba si RAM Wipe está funcionando
• Discusión de la lista de correo de Tails
• Otra discusión sobre la lista de correo de Tails
• Informe de error del kernel

Si quieres ver que la función se haga realidad, ¡vota en Ubuntu Brainstorm!

http://brainstorm.ubuntu.com/idea/30076/

Si no está utilizando RAM antigua como DDR2, 512 MB o 1024 MB, entonces no debe preocuparse por CBA.

Echa un vistazo a la investigación original aquí (PDF).

Si lo lee detenidamente, descubrirá que solo DDR2 y las versiones anteriores son propensas a este ataque. DDR3 pierde voltaje demasiado rápido para permitir el desmontaje de la caja de la computadora y el procedimiento de congelación. Así que simplemente desconecte el enchufe antes de abrir la puerta.

Además, este documento confirma que DDR3 no es susceptible a un CBA. Si de hecho desea protegerse porque tiene RAM DDR2, habilítelo en BIOS:

1. Inicio automático después de la pérdida de energía
2. Verificación de RAM al momento del arranque

y haga lo mismo que con DDR3, pero después de desconectarlo, vuelva a enchufarlo. Su computadora se iniciará y limpiará el ram al revisarlo. Si no se limpia lo suficientemente eficientemente, el proceso de arranque volverá a cargar el sistema en la RAM. Será demasiado rápido permitir CBA.

Desde el enlace que proporcionó en los comentarios:

Por lo tanto, en conclusión, el ataque de arranque en frío no debe verse como el método principal para adquirir la memoria de un sistema informático sospechoso. En su lugar, deben intentarse otras técnicas, incluida la adquisición basada en software y hardware (es decir, FireWire) antes de llevar a cabo un ataque de arranque en frío contra dicho sistema. Sin embargo, si se produce una situación en la que las técnicas antes mencionadas no están disponibles (es decir, la falta de conexión FireWire o la consola de inicio de sesión del sistema o la adquisición remota de memoria no es posible) o no son efectivas, entonces el ataque de arranque en frío se puede administrar asumiendo que el investigador comprende ambas cómo y dónde puede surgir el problema y salir mal.
Como ha demostrado este estudio, el ataque de arranque en frío no puede establecerse como particularmente forense o confiable, ya que en la mayoría de los experimentos realizados en este documento, las claves de cifrado residentes en la memoria no se pudieron encontrar o extraer de manera consistente, aunque deberían haberlo sido. Lo mismo puede decirse de las diversas cadenas y búsquedas de palabras clave que deberían haber producido muchas más cadenas y palabras clave de las que se encontraron en la mayoría de los experimentos. Además, como se ha demostrado, el simple hecho de congelar la memoria de la computadora no garantiza la adquisición exitosa de dicha memoria. Otros factores y variables ya examinados han examinado completamente estos problemas y sus causas subyacentes. Así,
Finalmente, incluso una adquisición exitosa que ha sufrido poca o ninguna degradación probablemente no se presentará ante un tribunal como evidencia sólida, al menos hasta que haya ocurrido la jurisprudencia y se pueda demostrar que la integridad de la memoria adquirida está intacta usando un sonido y Metodología comprensible. La búsqueda continúa estableciendo una forma más adecuada y confiable de adquirir la memoria de la computadora de un sospechoso ...

Además, si verifica los resultados del experimento, se dará cuenta de que extrajeron con éxito las claves AES solo en el sistema 2 y 6 y que fueron ataques de arranque en caliente cuando mira las especificaciones del sistema 2 - 1024 MB RAM 533 MHz - esto es viejo cosas. El otro sistema, el sistema 6 con 256 RAM / 128 RAM, creo que este se explica por sí mismo.

Esto es exactamente por qué su conclusión fue:

La búsqueda continúa estableciendo una forma más adecuada y confiable de adquirir la memoria de la computadora de un sospechoso ...

En realidad, creo que si tiene datos muy, muy importantes, no solo debe usar Full Drive Encryption, sino también guardarlos en un archivo cifrado separado. Cifrado con algoritmos en cascada y una contraseña diferente a la utilizada durante el cifrado del disco. ¿Desea una forma segura de apagar la PC? Aquí está:

1. Mantenga los datos seguros en el archivo cifrado del algoritmo True Crypt en cascada
2. Usar serpiente
3. Cree un script para manejar el apagado:

Para ventanas:

truecrypt.exe /wipecache
shutdown -s -f -t 1

Para Linux:

truecrypt /wipecache
shutdown -h now

Limpiar caché asegura que no quedan datos vulnerables en la RAM después del apagado. Si alguien realiza un ataque de arranque en frío, tendrá acceso a su sistema en el mejor de los casos. No tendrán datos almacenados en un archivo cifrado por separado.

Peter AH Peterson de UCLA escribió una tecnología de prueba de concepto y desarrolló la teoría para ejecutar de manera segura su sistema con RAM encriptada, y la solución está diseñada expresamente para prevenir ataques de arranque en frío. El nombre de su periódico es Cryptkeeper. No sé si él hace que el software esté disponible para descargar o si es posible obtener una licencia de UCLA. Sin embargo, aparentemente es posible, al menos en principio, diseñar un sistema de cifrado para RAM que sea seguro incluso si se divulga todo el contenido de RAM.

El impacto medido en el rendimiento de esta solución está entre una sobrecarga del 9% y una desaceleración en un factor de 9 , dependiendo de cuán "patológico" sea el escenario. La cifra del 9% se cita como aplicable a la navegación web con Firefox, pero no indicaron qué caso de uso ralentizaría el rendimiento en un factor de 9.

La solución de Peterson no "borra" la RAM como sugiere. Más bien, utiliza un "mecanismo seguro de ocultación de claves" para evitar que la clave de descifrado se divulgue solo en virtud de obtener el contenido de RAM. No estoy seguro de los detalles de la implementación, pero supongo que se explica en el documento.

El artículo fue publicado en 2010.

Está disponible para su compra en el sitio web ieeexplore de IEEE. También está disponible para descarga directa como PDF sin cargo desde el sitio web de alguien; está arriba en los resultados de búsqueda de Google para "cryptkeeper RAM" ... pero no estoy seguro de cuánto tiempo ese resultado permanecerá allí.

Estuve tentado de hacer de esto un comentario en lugar de una respuesta, porque esta solución no "borra" la RAM como usted pidió. Sin embargo, creo que si la investigación de Peterson es técnicamente correcta, esto tendrá el mismo efecto práctico, o posiblemente un efecto "mejor", que limpiar la RAM. La razón es que un atacante físico experto probablemente podría interrumpir el intento de su programa de sistema de borrar la RAM si esperaban que ocurriera tal operación, por ejemplo, sacar la batería de la unidad o mantener presionado el botón de encendido antes de que la operación pueda completar. La solución de Peterson es más segura porque no se basa en un intervalo de tiempo necesario bajo el cual se permite que la computadora continúe ejecutando instrucciones para completar el borrado. En cambio, la memoria es constantemente protegido, incluso si la CPU misma es eliminada instantáneamente por una increíble hazaña de tecnología antes de que incluso tengas la oportunidad de reaccionar ante el atacante.

Y por "increíble hazaña de tecnología" me refiero a algo como Stuxnet.

Me imagino que memtest86 sería bastante bueno para limpiar RAM. Siempre he querido probar lo siguiente, pero no lo he hecho. Si lo intento, lo actualizaré.

Lee la kexecpágina del manual . Y no intente con kexecel .iso, pero necesita desempaquetar la iso y enganchar el binario de arranque. En el sitio memtest86 anterior, solo puede descargar el binario.

Tienes que usar un kexeccomando para cargar lo que estás iniciando primero.

Entonces creo que lo que puedes hacer es:

kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8

y cuando estés listo para apretar el gatillo:

kexec -e

Estoy pensando (pero podría estar equivocado) que el --append=console=ttyS0,115200n8memtest86 funciona sobre el puerto serie. Entonces, si tiene uno, puede verificar que funciona incluso si no aparece en la salida de video, lo cual es una posibilidad ya que memtest86 no realiza la inicialización de video. Matar cualquier instancia de X en ejecución es probablemente una buena idea.

El kexec-toolspaquete Debian (también disponible en Ubuntu) lo conecta a los scripts de apagado, por lo que si edita /etc/default/kexecpuede decirle al proceso de apagado que invoque kexeccomo la última cosa en lugar de reiniciar. Es decir, si está interesado en un cierre limpio.

En una emergencia, a sync; kexec -efuncionaría.

Sin embargo, es posible que algunos conjuntos de chips, una vez que se inicializan, provoquen bloqueos si se abordan ciertas áreas de la memoria. No sé cómo funcionaría esto en la práctica.

Un buen compromiso si kexecno funciona es instalar memtest86 en su gestor de arranque, ponerlo como el elemento de arranque predeterminado y tener un retraso de 1 segundo hasta la elección automática (o no demorar y confiar en una pulsación de tecla para abrir el memu). Esto podría llevarlo a memtest86 desde una condición de "arranque nuevo" con bastante rapidez, pero no al instante.

Tenga en cuenta que esto no tiene en cuenta la RAM de video. Una solución para eso es configurar su RAM de video como un dispositivo de bloque y enviarla /dev/randomal dispositivo de bloque durante algunas iteraciones.

Esta es una vieja pregunta, pero creo que puedo contribuir. Como se dijo antes, un borrado de memoria basado en software no es la mejor solución, simplemente porque la energía se puede cortar repentinamente, por lo que el software de borrado no se ejecutará.

Me imagino el mejor escenario para ilustrar el problema: usted ejecuta negocios ilegales en su computadora en su hogar. Un día, la energía eléctrica desaparece repentinamente, y luego un escuadrón del FBI asalta la puerta de su casa, lo arresta y luego un técnico nerd abre rápidamente la carcasa de su computadora y usa dentro de ella un gas frío para congelar el estado de la memoria para comprar algo hora de hacer un ataque de arranque en frío.

Entonces, la mejor manera de resolver este problema es hacer que la carcasa de la computadora sea más segura, haciendo que sea difícil abrirla (algo así como una bóveda), o incluso destruyendo la memoria calentando la placa usando una resistencia alimentada por batería, encendida por un sabotaje cambiar en el caso. Pocos segundos a altas temperaturas pueden destruir los datos, o incluso destruir los chips, lo que no es un gran problema en esta situación.

El problema es si su computadora está funcionando y la pantalla está bloqueada. En este punto, la clave AES se almacena en la RAM y el usuario está lejos de la computadora. Un intruso podría abrir la caja de la computadora y quitar los módulos de RAM, mientras los mantiene encendidos y colocarlos en un dispositivo separado que lea su contenido. No es necesario apagar el sistema ni congelar los módulos antes de la extracción. La RAM no es confiable para mantener la tecla AES, pero la memoria caché del procesador es, como la solución llamada TRESOR. Desafortunadamente, eso requiere un kernel de Linux antiguo y conocimientos avanzados de parchear y compilar el kernel.

Lo siento, pero estás siendo paranoico. Primero, como lo indicaron otros usuarios, aparentemente el Cold Boot Attack solo funciona en hardware antiguo.

Si todavía crees que es una amenaza, limpiar no es la solución.

El ataque de arranque en frío implica:

• arranque en frío de la máquina
• Arrancar un sistema operativo liviano para eliminar las claves de cifrado de la memoria

Si alguien logra realizar el arranque en frío, entonces obviamente su limpiador no tendrá la oportunidad de funcionar. Por lo tanto, no tiene sentido instalar uno.

Este es el caso principal del ataque. Supongamos ahora que el atacante no quiere arrancar en frío el servidor en ejecución (por ejemplo, porque eso desencadenaría una alerta de monitoreo), sino que espera realizar el ataque dentro de los 5 'de un apagado limpio. En este caso:

• Un limpiador de RAM genérico tampoco te servirá de nada. Dado que se supone que el atacante está físicamente presente para encender la máquina y recoger las teclas, también puede arrancar en frío la máquina justo antes de que el limpiador comience a funcionar. (Se esperan alertas de monitoreo en este punto).
• Un programa especializado que primero borra la ubicación exacta de las claves de cifrado FS antes de borrar el resto de la RAM (por ejemplo, truecrypt /wipecachemencionado por mnmnc) podría dificultar el trabajo del atacante. Todavía:
  • El atacante aún podría recuperar algunos de los contenidos de RAM al no permitir que el limpiador recorra toda la RAM. Pero al menos la mayor parte de los datos en el FS estaría a salvo.
  • La solución no sería 100% infalible, solo hace que sea más difícil para el atacante cronometrar el arranque en frío.

Por lo tanto, si está realmente preocupado por este ataque, le sugiero que aprenda kung-fu y haga guardia durante 5 'al lado de la máquina cada vez que la apague. ¿O tal vez use una contraseña de arranque en su BIOS? Ambas medidas sugeridas no necesitan ser 100% efectivas: los atacantes aún pueden vencerlo y leer la contraseña del BIOS de su MB utilizando medios técnicos. Solo necesita retrasarlos por 5 'para que expire el tiempo de ataque.

Finalmente, si le preocupa que alguien realice toda la hazaña de forma remota, ya está empeñado.