¿Cómo impiden los programas que se filtren datos?

Aquí está mezclando cosas por separado, a saber, software de cifrado y administradores de contraseñas . No obstante, no hay forma de almacenar la clave en la memoria y los problemas se pueden reducir a uno:

• Si desea almacenar contraseñas como en KeePassX, debe desbloquear la base de datos de contraseñas una vez y mantenerla abierta (para poder autotipinarlas a través de teclas de acceso rápido).
• Si cifras archivos, debes ingresar tu contraseña maestra una vez y mantener los archivos abiertos.

En cualquier caso, la contraseña estará en la memoria por un tiempo finito y deberá sobrescribirla después de usarla para asegurarse de que no se quede allí. Si simplemente reasigna la memoria, no se garantiza que se sobrescriba nunca.

memset puede establecer un bloque de memoria para lo que quieras que sea, por lo que podría ayudarnos aquí. Problema : si utiliza optimizaciones del compilador, el compilador podría pensar que memset es inútil y eliminarlo para mayor eficiencia.

Esta es la razón por la que, por ejemplo, VeraCrypt incluye funciones especiales como RtlSecureZeroMemory y su método de envoltura burn para garantizar que la memoria se reinicie, como esta:

BootArgs = *bootArguments;
BootArgsValid = TRUE;
burn (bootArguments, sizeof (*bootArguments));

Por supuesto, esto no hace que la eliminación esté 100% garantizada, porque ahora debe asegurarse de que no haya una ruta de ejecución posible que olvide llamar a esta función.

En la última auditoría de VeraCrypt se reveló que hay una ocasión en la que burn se llama después de un segmento de código donde se puede lanzar TC_THROW_FATAL_EXCEPTION , por lo tanto, lleva a datos confidenciales que quedan en la memoria.

Este es generalmente uno de los problemas en el diseño de programas seguros, si implementas métodos para evitar las pérdidas de memoria, debes asegurarte de que no haya manera de evitar que se los llame.

  

¿Cómo los programas como VeraCrypt, 1password, keepass, GPG, LastPass, AES Crypt y muchos otros tratan estos problemas de copias múltiples de archivos y tener una copia de la contraseña / clave / datos en la memoria u otros lugares de un disco duro?

Variará de un producto a otro. Es por esto que las auditorías de terceros son valiosas, para validar que el enfoque es seguro e implementado correctamente.

  

¿Estas cosas son incluso una preocupación de seguridad?

Sí y no. A menudo es importante poner las preguntas de seguridad en contexto. Tener copias adicionales de una base de datos de contraseñas no es ideal, ya que hace que la divulgación de información sea más probable, pero si existen las protecciones adecuadas para los archivos y la base de datos está encriptada, es poco probable que se explote.

En una nota similar, tener contraseñas en la memoria no es opcional si está usando un almacén de contraseñas. ¿Vale la pena el riesgo? Probablemente.

Aislamiento del proceso

Tener datos confidenciales en la memoria no es un problema de seguridad por sí solo: en cualquier sistema "correcto" no es accesible a otros procesos y se puede usar solo de la manera adecuada y segura.

Esto implica un cierto riesgo de divulgar esos datos, es decir, dejar una copia temporal después de que la memoria se desasigne y luego se asigne a otro proceso; o si el área de la memoria se cambia al disco, pero se pueden mitigar con medidas técnicas razonablemente simples, por ejemplo. sobrescribiendo el área de la memoria después del uso y antes de la desasignación, y marcando la página de la memoria para que no esté disponible para el intercambio respectivamente. Al desarrollar dicho software, debe asegurarse de que se hayan tomado estos pasos y que los datos confidenciales no se "filtren" de esta manera.

Fuera de eso, el sistema operativo aplicará el aislamiento del proceso para que estos datos confidenciales (como todos los demás datos) no sean accesibles para otros procesos. Aún debe tomar medidas para minimizar el tiempo que los datos confidenciales están en la memoria para reducir los riesgos en caso de un compromiso en su software o en el sistema operativo (por ejemplo, la vulnerabilidad openssl "heartbleed"), por lo que es una preocupación de seguridad pero es una práctica aceptable y segura mantener los datos confidenciales en la memoria cuando sea necesario .