2011-03-11 20 views
10

Conozco los muchos proveedores de criptografía que están disponibles en .NET framework junto con los conceptos básicos de cómo usarlos. Esto es bastante simple.Protección de claves de cifrado en C#

Pero mi preocupación es esta.

Digamos que quiero utilizar estas bibliotecas para encriptar objetos serializados XML para evitar manipulaciones y la posibilidad de que cualquiera pueda ver el contenido de estos archivos.

El problema que siempre me queda es que la clave para descifrar esta información debería almacenarse como una constante en algún lugar de mi aplicación. Esencialmente, hace que todo el ejercicio no tenga sentido.

Entonces, ¿cómo se almacena una clave para un algoritmo de cifrado de forma segura dentro de una aplicación desmontable?

EDIT: Si estoy entendiendo ambas respuestas a continuación correctamente. Lo que esto significa es que, esencialmente, cualquier implementación (para ser segura) requiere que sea de solo lectura o de escritura, pero nunca ambas? ¿Es esto correcto?

+0

Ofuscar XML tanto como sea posible (agregar datos aleatorios + utilizar el esquema de cifrado primitivo ROT13 + etc.) y serializarlo en modo binario o en modo Base64.El objetivo es hacer que la decodificación XML a través del desensamblaje del programa sea lo más difícil posible para que el usuario no invierta tiempo en hacerlo ... –

Respuesta

4

No es así. Si la aplicación puede acceder a la clave, es solo seguridad por oscuridad. Es mejor autenticar al usuario de alguna manera (una contraseña es el ejemplo más simple), para asegurarse de que se le permita acceder a los datos. No puede dejar que la aplicación lo haga por usted, porque simplemente no es confiable. Cualquiera puede obtener la información almacenada en la aplicación.

Si la información clave está almacenada en otro lugar, un usuario o aplicación malintencionada también puede acceder a ella. De lo contrario, guarde sus datos directamente en ese lugar mágico seguro.

Ahora, si todavía desea ir por ese camino y almacenar datos confidenciales sin autenticación, su mejor opción - o al menos una manera fácil que es mitad segura - es probablemente el DPAPI (vea la clase ProtectedData en System.Security.Cryptography). Codificará los datos con la tecla de la máquina o con la clave de la cuenta del usuario (puede seleccionar eso). Para que un programa que se ejecute en otra máquina o con otra cuenta de usuario no pueda acceder a él. Windows intentará proteger esas claves, pero en realidad cualquier aplicación que se ejecute en la máquina adecuada o con la cuenta de usuario adecuada podrá acceder a sus datos.

+1

probablemente usando la contraseña del usuario para encriptar y descifrar es una buena idea. Pero, por supuesto, eso expondría la contraseña. Probablemente el hash de la contraseña podría hacer el trabajo, o algún otro valor derivado de la contraseña. –

+0

Si usa una forma personalizada de autenticación y encriptación, probablemente tenga razón. Si está utilizando el DPAPI, se encargará de todo eso automáticamente. Por lo que recuerdo, también se ocupará de que los datos aún se puedan descifrar después de que un usuario haya cambiado su contraseña. – ollb

+0

Eso también crea sus propios problemas. ¿Qué pasa si el usuario quiere cambiar la contraseña? –

0

Existen varias soluciones posibles. Uno de ellos está usando RSA. Alternativamente, puede utilizar el mismo enfoque utilizado en TLS.

Una buena manera sería generar un par de clave pública y privada. Encripta con lo privado y destruye la clave. Con la clave pública, puede descifrar pero no alterar los datos.

+0

Si destruye la clave privada, esta es una solución de solo lectura. Sin embargo, incluso entonces un usuario malintencionado podría simplemente crear un nuevo archivo con su propio par de claves y reemplazar la clave que la aplicación utiliza para el descifrado. Esto, por supuesto, depende de su capacidad para modificar la ubicación donde se almacena la clave pública. – ollb

1

Asumiremos que está utilizando algún tipo de esquema de criptografía de clave pública, porque de lo contrario no tendría sentido.

La respuesta es usted no almacene la clave privada en cualquier lugar de la aplicación. Lo almacena en un lugar donde solo su aplicación puede acceder. Por ejemplo, un archivo en el sistema local que solo los administradores y su aplicación tienen derechos para leerlo. En una red protegida comparte. Etc.

Piense en cómo administramos las llaves como personas. Mantenemos nuestros archivos privados en un archivo, o una unidad USB encriptada o algo así. Los mismos principios se aplican a las aplicaciones.

+0

¿Esto no solo resolverá el problema? Si tiene una ubicación confiable a la que solo su aplicación puede acceder, puede simplemente almacenar los datos allí y terminar con ella. – ollb

+0

No existe una ubicación que "solo los administradores y tu aplicación puedan acceder". Si su aplicación puede acceder a ella, el usuario de su aplicación también puede hacerlo. –