Almacenamiento seguro de entropía opcional durante el uso de DPAPI

Question

Por lo tanto, estoy tratando de almacenar la clave simétrica utilizando DPAPI. Todo está bien y genial, pero ¿qué hacer con la entropía? Esta pregunta contestada here realmente no proporciona suficiente información. Parece una pendiente resbaladiza: podría usar la tienda de máquinas para almacenar la entropía, pero ¿qué impide que alguien se meta en eso también? Nota: Estoy almacenando la clave actual usando el alcance del usuario.

Entonces mi pregunta es: ¿cuál es la mejor manera de almacenar la entropía usando DPAPI?

Answer 1

Cualquier cosa que almacene localmente puede verse comprometida. Pero hay pasos que puede tomar para hacerlo más difícil. Hay un documento en Handling Passwords que puede considerar revisar. Considera que su clave Entropy es una contraseña específica para su aplicación.

Voy a referirme a su Entropy como su clave , ya que es funcionalmente una clave adicional.

Lo que no quiere hacer es almacenar su clave localmente en un formato no encriptado. En su lugar, desea cifrar su clave o derivarla de otra fuente obvia. Por supuesto, si cifras la clave, entonces necesitas almacenar la clave utilizada para encriptarla, pero muchas veces esta sola capa de indirección es suficiente para desalentar a la mayoría de los retadores.

Esa sería la ventaja de derivar su clave. Puede derivarlo como un hash de otra pieza de datos constantes (debe ser algo que no cambie con las revisiones de su aplicación). Sin embargo, un truco al derivar un hash es combinar el hash con algún otro valor constante (como un GUID o un gran número aleatorio) para que otra persona no pueda combinar un conocido algoritmo hash y obtener su clave. Esta es una alternativa mucho mejor que crear tu propio algoritmo hash (lo cual nunca debes hacer, a menos que tengas un PHD en Matemáticas).

En algún momento va a necesitar algún tipo de clave codificada en su aplicación. Esta clave se combina con algunos otros datos en un hash para crear su clave de entropía, o se usa para descifrar la clave de entropía. En realidad, puede cambiar la clave con una nueva revisión de su aplicación, siempre que mantenga la clave anterior para descifrar la clave existente. Luego puede volver a cifrarlo con la nueva clave o método.

Si quiere la mejor seguridad, puede almacenar la llave Entropy fuera de la computadora. Esto requeriría una conexión a Internet y un certificado SSL, pero luego la clave nunca se conserva localmente para ser descubierta. Para hacer esto, puede configurar un sistema de respuesta de desafío más sólido, de modo que la autenticación de solicitud sea diferente cada vez, y la clave se entregue a través del cifrado SSL para que no se pueda interceptar. Una vez que se usa la llave, se descarta. Por supuesto, este tipo de estrategia frustra el propósito de muchos escenarios en los que está utilizando DPAPI para el almacenamiento seguro local.

Hagas lo que hagas, ten en cuenta que se verá comprometido, eso siempre ocurre cuando alguien tiene acceso completo a la máquina local y a los datos almacenados en ella. La solución a eso es seguir lanzando actualizaciones que cambien el método lo suficiente como para que el viejo crack ya no funcione. Esto hará que la distribución de una grieta sea menos valiosa ya que será difícil encontrar una para la versión correcta.

Answer 2

En primer lugar, permítanme abordar la pregunta original de la publicación. Todo se reduce al hecho de que la entropía debe almacenarse bajo la autoridad del usuario y/o la autoridad de la aplicación si se va a utilizar para el almacenamiento persistente. Supongo que podría usar una clave almacenada con la aplicación para cifrar la información en la tienda persistente, pero nuevamente una aplicación maliciosa podría acceder a esta clave de cifrado. Por lo tanto, no creo que haya un medio para protegerse contra el escenario que menciona en los comentarios. Sin embargo, dado lo que ha dicho es el uso previsto de la entropía, no creo que ayude a resolver su problema.

Parece que el problema real es establecer un canal seguro de comunicación entre su aplicación cliente y el servidor. En su diseño, está intercambiando claves que se utilizarán para cifrar la comunicación. Creo que intentar usar un código personalizado para resolver este problema generará vulnerabilidades de seguridad adicionales.

Dado todo eso, sugeriría crear un servicio WCF (Windows Communication Foundation) que se utiliza para recuperar información confidencial. Obviamente, podría utilizarse para recuperar toda la información, pero la menor cantidad de cambios sería limitar el servicio a la información confidencial.

Con WCF, puede configurar tanto el cliente como el servidor para usar un canal seguro. WCF tiene muchas opciones para establecer un canal seguro de comunicación con el servidor.

<wsHttpBinding> 
    <binding> 
     <security mode="Transport"> 
      <transport clientCredentialType="Windows" /> 
     </security> 
    </binding> 
</wsHttpBinding> 

Una vez que tiene un canal seguro, muchos de los otros problemas son más simples, como el acceso a los datos CC. Si los datos se envían a un canal seguro, se convierte en una cuestión de autorización en lugar de seguridad del canal.

Ver How to: Create a Secure Session para más.