Administración de claves privadas en la memoria

3

Soy un desarrollador que está trabajando en un protocolo de red que incluye cifrado. Realmente no importa, pero solo por el bien de contexto, mencionaré que estoy usando libsodium crypto library. Ahora hay una gran cantidad de código asíncrono en mi implementación y tiendo simplemente a copiar la clave privada que se usa para cifrar los paquetes. La clave privada es una matriz de 32 bytes, por lo que se supone que la copia es barata en cuanto a CPU.

Algunas personas dicen que debería guardar la menor cantidad de copias posible en la memoria, tal vez solo una y usar un puntero compartido en mi aplicación. Por otro lado, si el hacker detecta esta ubicación específica de la memoria, podría reemplazar la clave privada con otra cosa. Por lo tanto, tener varias copias dispersas en la memoria debería hacer que sea más complejo hacerlo, pero también abre más agujeros para buscar la clave privada.

¿Cuáles son las buenas prácticas para administrar las claves privadas / secretas en la memoria?

    
pregunta PovilasB 20.11.2018 - 10:11
fuente

2 respuestas

3

La mejor práctica para administrar las claves privadas / secretas en la memoria es usar una memoria físicamente fuera del alcance de los atacantes, como un HSM, una tarjeta inteligente, un módulo de plataforma confiable o un elemento seguro.

El problema es que es hardware, y en las máquinas modernas (servidores, nube, PC, dispositivos móviles), el hardware confiable no es fácil de usar (aunque a menudo está presente; en particular, veo un renovado interés por TPM 2.0 en el servidor / nube).

Las opciones de solo software son un compromiso. Una razonable para

  • Confíe en el hardware + SO para mantener al menos el contenido de la memoria de un proceso privado, y mantener las claves privadas / secretas es un proceso separado haciendo el cifrado, intercambiando mensajes con el proceso usando el crypto.
  • Y se adhieren a los algoritmos que tienen una protección inherente contra las fugas de procesos laterales / procesos cruzados, porque los ataques en este frente son numerosos. Libsodium es una buena opción desde este punto de vista.

La combinación al menos hace que una filtración de una clave privada / secreta sea improbable como resultado de vulnerabilidades en el proceso mediante el uso de la criptografía (debido a errores prácticamente inevitables en la pila de software inmanejablemente compleja involucrada en una aplicación típica). Un inconveniente es que el acceso al proceso que realiza la criptografía debe administrarse de forma segura (por ejemplo, a través de los derechos de acceso aplicados por el sistema operativo), lo que agrega complejidad.

Una forma de ver los llamados "enclaves" es como una implementación estandarizada de ese principio de diseño.

Mi opinión sobre el tema de multiplicar el secreto frente al uso de punteros a un área centralizada es que es secundario desde el punto de vista de la seguridad, en comparación con el aislamiento del proceso. Tiendo a preferir los punteros, no tanto porque es un poco más eficiente, sino porque evita la molestia de tener que cero copias que ya no están en uso para seguir las pautas que lo requieren. Considero que la reducción a cero no es esencial técnicamente (nuevamente, en comparación con el aislamiento del proceso); pero me gusta usar e > 2 16 en RSA, es algo para inclinarse.

    
respondido por el fgrieu 20.11.2018 - 11:46
fuente
0

Puede cifrar su clave privada con una clave de TPM recién creada; su módulo TPM puede crear una clave de envoltorio, luego puede almacenar esa clave en el disco o en la memoria.

    
respondido por el jbarbosa 21.11.2018 - 09:55
fuente

Lea otras preguntas en las etiquetas