Software criptográfico: sobrescribir el búfer sensible

4

¿Es común implementar software criptográfico de tal manera que los buffers sensibles se sobrescriban antes de liberar memoria? Por ejemplo, cuando contienen una clave privada o el mensaje de texto sin formato.

    
pregunta firefexx 24.04.2014 - 19:50
fuente

2 respuestas

3

Es común, pero también un poco de mito. En días anteriores , se consideró que la sobrescritura era importante debido a lo siguiente:

  • Algunos sistemas operativos ampliamente implementados (en particular, Windows desde el linaje "3.1" hasta Windows 98 y Millenium inclusive) no ajustaron a cero las páginas de memoria antes de entregarlas a las aplicaciones, por lo que una aplicación podría obtener extractos de la memoria antigua de otra aplicación.
  • Los datos en la RAM pueden filtrarse en el disco a través de memoria virtual .
  • En algún momento se creyó que la "fuga parcial" podría prevalecer, por ejemplo. que un desbordamiento de búfer de solo lectura podría revelar parte de la RAM pero no todo.

Estas propiedades han quedado bastante obsoletas en la actualidad. En particular, los sistemas operativos modernos (incluidos Windows 2000, XP y sucesores) hacen cero las páginas de forma sistemática. Además, el uso del archivo de intercambio ha disminuido; Los dispositivos como los teléfonos inteligentes y las tabletas no usan swap en absoluto, y están contentos con eso (y también lo hago en mis computadoras portátiles). Más importante aún, la gente ha comenzado a comprender que el problema de los datos filtrados tiene un gran alcance: cuando descifra un mensaje privado, la clave privada es, de hecho, una pieza de datos confidenciales, pero también lo es el mensaje en sí. Y los buffers de memoria utilizados para mostrar dicho mensaje en la pantalla, también. Además de todos los búferes temporales para el algoritmo que calculaba la forma en que el texto privado tenía que dividirse en párrafos debidamente justificados para su visualización. Y así sucesivamente.

Al mismo tiempo, el ecosistema de software ha evolucionado, y ahora usamos muchos más lenguajes de programación que asignan memoria a través de recolector de basura (p. ej., Java, C #, Python, PHP, Javascript, Perl, Ruby ... todos usan un GC). Los algoritmos eficiente GC mueven los objetos en la RAM, de manera transparente. Y por "mover" me refiero a "copiar". Una consecuencia es que el "borrado" de la memoria del programa ya no garantiza que no quede ningún rastro de los datos.

La conclusión sintética es que borrar los datos del código de la aplicación es una mala respuesta al problema general de la fuga de datos. Es común , pero no es lo mismo que recomendado . Si el modelo de seguridad local requiere tal eliminación, entonces debe hacerse de manera sistemática y en todo el sistema, mediante el asignador de memoria (por ejemplo, el GC, para idiomas que están basados en GC), no saturando la aplicación. código con llamadas explícitas a memset() .

Un primer paso, que es bastante fácil de aplicar, es ver si no se puede desactivar el espacio de intercambio por completo. Esto eliminaría la fuente de las fugas más graves (fugas a medios físicos).

    
respondido por el Thomas Pornin 24.04.2014 - 20:37
fuente
1

Sí, y no solo el software de cifrado, incluso el software normal que guarda información no sensible en la memoria como la clave privada y la contraseña.

Se recomienda mantener estos datos por un corto tiempo en la memoria y luego sobrescribirlos (no solo eliminar).

Los riesgos detrás de esto son las posibilidades de hibernación, volcado de memoria y copia de memoria en un archivo de intercambio.

Por lo tanto, se recomienda sobrescribir la memoria y usarla por el menor tiempo posible.

Vea este proyecto: Buffer con protección de sobrescritura y asignación de memoria en Exigir también tiene una explicación más detallada y un ejemplo real.

    
respondido por el Akam 24.04.2014 - 20:20
fuente

Lea otras preguntas en las etiquetas