Cómo almacenar de forma segura la clave de cifrado en un ensamblado .NET

Question

Para evitar que alguien capture mis datos fácilmente, guardo en caché los datos de mi servicio como archivos cifrados (básicamente protección de copia).

Sin embargo, para hacer esto, debo almacenar la clave de cifrado dentro del ensamblado .NET para que pueda cifrar y descifrar estos archivos.

Conociendo herramientas como el Reflector .NET de Red Gate que puede sacar mi llave, tengo la sensación de que esta no es una manera muy segura de hacerlo ... ¿hay alguna mejor práctica para hacer esto?

Answer 1

Tiene que decidir qué nivel de riesgo es aceptable. No hay una manera "segura" de hacer esto.

Si el riesgo de que alguien use un reflector, o simplemente abra el ensamblado utilizando la clase System.Reflection.Assembly y atrape el recurso de esa manera, es demasiado grande, entonces su siguiente paso es probablemente descargar la clave del servidor cuando comienzas

Entonces alguien tendrá que hacer algo como depurar mientras usa su código y agarrar la llave de esa manera. Puede caducar todo lo almacenado en caché y cambiar las claves. Puede hacer que cada individuo tenga sus propias claves para proteger los datos de un usuario de otro usuario.

Puede hacer muchas cosas, pero si su objetivo es evitar que alguien pueda descifrar la información que un ensamblaje que está colocando en su máquina tiene la capacidad de descifrar, debe saber que es prácticamente imposible. Todo lo que realmente puede hacer es elevar el costo de piratear sus claves/datos; no puedes detenerlo

Answer 2

No se puede impedir decription, pero se puede prevenir la re-cifrado de datos falsificados:

Mientras que su código se ejecuta en un ordenador accesible por los demás, no hay ninguna manera se puede evitar que el examen del programa. Sin embargo, la descompilación y el análisis cuestan tiempo. Como señala MaxGuernseyIII, todo se trata de niveles de amenaza aceptables.

En su caso, el problema no es tanto que un pirata informático pueda descompilar su código, sino mucho más que puedan cambiar los datos que desea proteger (a quién pertenece la licencia).

Para que pueda usar un método public key cryptography para encriptar los datos. De esa forma el hacker puede leer, pero no puede volver a encriptar.

Answer 3

Como Max insinúa, debe considerar un modelo de amenaza.

¿Qué tipo de atacantes te preocupa? (Es legítimo preocuparse por algunos, y no tan legítimo como para preocuparse por los demás). Las categorías típicas podrían ser "usuarios no expertos en computadoras que compraron programas", "personas dedicadas dispuestas a pasar horas en una solución", "usuario casual que sabe cómo encontrar fisuras en línea", etc.

Dependiendo de su situación concreta las soluciones pueden ser diferentes

Un elemento interesante/triste a tener en cuenta, es que si su producto es popular, solo se necesita una o dos personas dedicadas para sentarse y romperlo y luego liberar el parche para todos. Esta es la naturaleza del software, supongo, y es un problema no resuelto cuando toda la aplicación se ejecuta en su máquina.

Claramente, la implicación es que no es un problema si su aplicación se ejecuta como un sitio web, es decir, está en una máquina de su control.

Sé que esta no es una respuesta particularmente útil.