¿Por qué cifrar los datos en la memoria?

En un mundo perfecto, tienes razón: no debería tener ningún sentido mantener los datos cifrados en la RAM. El sistema operativo debe mantener una fuerte separación entre los procesos, borrar la RAM cuando se reasigna a otro proceso y, si el modelo de ataque permite que un atacante robe el dispositivo luego y realice un análisis de disco duro, encripte el intercambio (o no use ningún intercambio en absoluto). lo que puede tener más sentido para un dispositivo con almacenamiento basado en Flash).

En un mundo realista, donde los sistemas operativos y la administración de sistemas son esfuerzos humanos y, por lo tanto, inherentemente no son perfectos, es posible que desee agregar algunas medidas de seguridad, como mantener los datos cifrados en la RAM e indicar al sistema operativo no para escribir datos en el espacio de intercambio (en sistemas similares a Unix, esto se hace con mlock() ). Aún así, este cifrado en RAM es más un ritual psicológico que una verdadera defensa; Su principal virtud es hacer que el desarrollador se sienta mejor.

De todos modos, no te molestes en hacer eso en Java. El recolector de basura copiará los objetos en la RAM de manera transparente (esto es parte de los algoritmos GC más eficientes y no puede evitarlo), por lo que el nivel de cifrado de su aplicación no garantizará que exista una versión clara de las claves en la RAM en ningún momento.

Los sistemas operativos modernos funcionan con la administración de memoria virtual, de modo que, de manera predeterminada, no es posible que los procesos de espacio de usuario / modo de usuario accedan directamente a la memoria de otros procesos.

Pero en Windows (no sé si esto también se aplica a Linux) hay interfaces que permiten a los usuarios estándar acceder a la memoria de procesos de otros procesos que se ejecutan con las mismas credenciales.

Hay muchos programas que utilizan esta interfaz. Un ejemplo muy simple es HxD : un editor hexadecimal gratuito que permite ver e incluso editar la memoria de procesos de otros procesos.

La memoria puede ser visible para otros procesos al:

1. estar disponible una vez que el proceso original que lo usa lo haya devuelto al sistema operativo. La memoria no se borra y un proceso sucesivo podría realizar un malloc() y recuperar la información que pertenece a un proceso que se está ejecutando anteriormente (observe capítulo 8 de los controladores de dispositivos de Linux (especialmente la nota al pie de la primera página)
2. páginas que el sistema operativo está cambiando a disco. Estos pueden estar disponibles para un proceso que mira el disco / almacenamiento.

En consecuencia, la memoria no encriptada puede hacerse visible a otros procesos.

Este es un enlace muy interesante, y tenga en cuenta esta cita:

  

Sin embargo, esta volatilidad depende en gran medida de la computadora en cuestión.   para cuando una computadora no está haciendo nada, la memoria anónima puede persistir   por largos periodos de tiempo. Por ejemplo, en algunas computadoras, contraseñas y   Otros datos precalculados se recuperaron fácilmente muchos días después de ser   escrito o cargado en la memoria

Hay algunos problemas que son específicos del mundo Java que debes considerar. Es una práctica normal que uno haga volcados de pila de la JVM si surge un problema técnico. Estoy tratando con una aplicación que incluso tiene una interfaz de usuario dedicada para eso. Esto podría ser increíblemente valioso, por ejemplo. para encontrar fugas de memoria. Y seguro, sí, la información confidencial va al vertedero. Entonces, si alguien interrumpe la aplicación (por ejemplo, omite el inicio de sesión con una inyección SQL :)) ...: X. O si el usuario administrativo es una persona curiosa ...: X

Sé que esto no debería ocurrir en el "mundo ideal".

También puede configurar la JVM para hacer un volcado en las excepciones de memoria insuficiente. Desde Java 1.4 esto podría verse así:

-XX:-HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>

¡Un atacante puede encontrar un exploit que hace que la aplicación se quede sin memoria y puede encontrar otro exploit (por ejemplo, error en la ruta del archivo) para robar tu volcado!

La otra cosa en la que debes pensar es que algunos datos confidenciales tendrán que ingresar a tu aplicación de alguna manera. Así que en ciertos momentos lo tendrás en la memoria. Hay poco o nada que puedas hacer al respecto. Pero lo que puedes hacer es limpiarlo más rápido. Por ejemplo, tomar una contraseña de usuario. Si lo almacena en una instancia de String, entonces no tiene mucho control sobre cuándo se recolectará la basura. Por lo tanto, las API-s agradables sí procesan dichos datos en matrices de caracteres (char []) que pueden ponerse a cero después del uso.

Google tiene un exploit llamado RowHammer que permite una el usuario debe leer el contenido de la RAM que se encuentra junto a los datos que se están escribiendo. Cifrar la RAM haría que esta explotación sea mucho más difícil.

  

"Rowhammer" es un problema con algunos dispositivos DRAM recientes en los que el acceso repetido a una fila de la memoria puede causar que los bits se inviertan en filas adyacentes. Probamos una selección de computadoras portátiles y encontramos que un subconjunto de ellas presentaba el problema. Construimos dos explotaciones de escalamiento de privilegios de trabajo que utilizan este efecto. Un exploit utiliza los cambios de bits inducidos por el martillo de fila para obtener privilegios del kernel en x86-64 Linux cuando se ejecuta como un proceso de usuario sin privilegios. Cuando se ejecuta en una máquina vulnerable al problema de rowhammer, el proceso pudo inducir cambios de bits en las entradas de la tabla de páginas (PTE). Fue capaz de usar esto para obtener acceso de escritura a su propia tabla de páginas y, por lo tanto, obtener acceso de lectura y escritura a toda la memoria física.

     

No sabemos con certeza cuántas máquinas son vulnerables a este ataque ni cuántas máquinas vulnerables existentes se pueden reparar. Nuestro exploit utiliza la instrucción CLFLUSH x86 para generar muchos accesos a la DRAM subyacente, pero otras técnicas también podrían funcionar en sistemas que no sean x86.

     

Esperamos que nuestro exploit basado en PTE pueda funcionar en otros sistemas operativos; no es inherentemente específico de Linux. Causar cambios de bit en PTE es solo una avenida de explotación; Otras vías para explotar los cambios de bits pueden ser prácticas también. Nuestro otro exploit lo demuestra al escapar del entorno limitado de Native Client.

La razón por la que suena como una buena idea es que usted querrá proteger los datos para que no sean robados mientras se encuentren en la memoria. Esto se hace bajo el supuesto de que los datos en la base de datos real están cifrados (como debería estarlo toda la información de identificación personal) pero se guardan sin cifrar en la memoria a medida que se procesan. Esto sería bastante difícil de hacer por una variedad de razones expuestas por otros comentaristas e introduciría una gran complejidad en términos de cómo funcionarán las aplicaciones con los datos cifrados en la memoria.

Lo que es una solución mejor y más viable es garantizar un control de acceso adecuado a la Base de datos / sistema y también a garantizar que el DBMS se ejecute con una cuenta de usuario "normal" y no con una cuenta elevada como SYSTEM, etc. controles de detección que puede implementar, como una herramienta de monitoreo de DBMS que puede configurar para observar grandes selecciones en tablas sensibles, etc. e informar sobre cualquier cosa fuera de lo común. De esta manera puede ver si hay alguna selección o proceso que intenta obtener grandes cantidades de datos.