Protección de claves secretas de API en una aplicación de cliente pesado

Question

Dentro de una aplicación, tengo claves secretas que se utilizan para calcular un hash para una llamada API.En una aplicación .NET es bastante fácil usar un programa como Reflector para extraer información del ensamblaje para incluir estas claves.

¿Ocultar el ensamblaje es una buena forma de proteger estas claves?

Answer 1

Probablemente no.

Busque la criptografía y los mecanismos integrados de ocultación de información de Windows (DPAPI y almacenamiento de claves en una clave de registro restringida por ACL, por ejemplo).Eso es lo mejor que obtendrá por la seguridad que necesita para mantener en el mismo sistema que su aplicación.

Si está buscando una manera de evitar que alguien sentado físicamente frente a la máquina obtenga su información, olvídelo.Si alguien está decidido y tiene acceso irrestricto a una computadora que no está bajo su control, no hay manera de estar 100% seguro de que los datos estén protegidos en todas las circunstancias.Alguien que esté decidido lo conseguirá si así lo desea.

Answer 2

No lo creo, ya que ofuscar (al menos según tengo entendido) simplemente alterará los nombres de los métodos para hacer que sea difícil (pero no imposible) entender el código.Esto no cambiará los datos de la clave real (que supongo que habrá almacenado en una constante en algún lugar).

Si solo desea que sea un poco más difícil de ver, puede ejecutar un cifrado simple en el texto sin formato (como ROT-13 o algo así) para que al menos no se almacene sin cifrar en el código mismo.Pero eso ciertamente no impedirá que un hacker decidido acceda a su clave.Un método de cifrado más seguro no ayudará porque aún necesitaría almacenar la clave para ESO en el código, y no hay nada que lo proteja.

Lo único realmente seguro que se me ocurre es mantener la clave fuera de la aplicación de alguna manera y luego restringir el acceso a la clave.Por ejemplo, podría guardar la clave en un archivo separado y luego proteger el archivo con una restricción basada en el usuario a nivel del sistema operativo;eso probablemente funcionaría.Podría hacer lo mismo con una conexión de base de datos (nuevamente, confiando en la restricción de acceso basada en el usuario para mantener a los usuarios no autorizados fuera de la base de datos).

Jugué con la idea de hacer esto para mis aplicaciones, pero nunca lo implementé.

Answer 3

DannySmurf tiene razón en que no se pueden ocultar claves a la persona que ejecuta una aplicación;Si la aplicación puede llegar a las llaves, la persona también puede hacerlo.

Sin embargo, ¿qué estás tratando de lograr exactamente?

Dependiendo de lo que sea, a menudo hay formas de lograr su objetivo que no dependen simplemente de mantener un "secreto" secreto en la máquina de su usuario.

Answer 4

Llega tarde al juego aquí...

El enfoque de almacenar las claves en la configuración de ensamblaje/ensamblaje es fundamentalmente inseguro.No existe una forma estricta de almacenarlo, ya que un usuario determinado tendrá acceso.No me importa si utilizas el mejor o más caro producto de ofuscación del planeta.No me importa si usas PDAPI para proteger los datos (aunque esto es mejor).No me importa si utiliza un almacén de claves local protegido por el sistema operativo (esto es aún mejor).Ninguno es ideal ya que todos padecen el mismo problema central:el usuario tiene acceso a las claves y están ahí, sin cambios, durante días, semanas, posiblemente incluso meses y años.

Un enfoque mucho más seguro sería proteger sus llamadas API con PKI probada y verdadera.Sin embargo, esto tiene una sobrecarga de rendimiento obvia si las llamadas a la API son conversacionales, pero para la gran mayoría de las aplicaciones esto no es un problema.

Si le preocupa el rendimiento, puede utilizar Diffie-Hellman sobre PKI asimétrica para establecer una clave simétrica secreta compartida para usar con un cifrado como AES."compartido" en este caso significa compartido entre el cliente y el servidor, no entre todos los clientes/usuarios.No hay una clave codificada/integrada.En cualquier lugar.

Las claves son transitorias, se regeneran cada vez que el usuario ejecuta el programa o, si está realmente paranoico, podrían expirar y requerir recreación.

Las claves simétricas secretas compartidas calculadas se almacenan únicamente en la memoria, en SecureString.Son difíciles de extraer, e incluso si lo hace, sólo sirven por un tiempo muy corto y sólo para la comunicación entre ese cliente en particular (es decir, esa sesión).En otras palabras, incluso si alguien piratea sus claves locales, sólo sirven para interferir con la comunicación local.No pueden usar este conocimiento para afectar a otros usuarios, a diferencia de una clave incorporada compartida por todos los usuarios a través de código/configuración.

Además, las claves completas nunca pasan a través de la red.El cliente Alice y el servidor Bob los calculan de forma independiente.En teoría, la información que pasan para hacer esto podría ser interceptada por un tercero Charlie, lo que le permitiría calcular de forma independiente la clave secreta compartida.Es por eso que se utiliza esa PKI asimétrica (significativamente más costosa) para proteger la generación de claves entre Alice y Bob.

En estos sistemas, la generación de claves suele ir acompañada de autenticación y, por tanto, de creación de sesiones.Usted "inicia sesión" y crea su "sesión" a través de PKI, y una vez completado, tanto el cliente como el servidor tienen de forma independiente una clave simétrica que puede usarse para un cifrado de orden de magnitud más rápido para todas las comunicaciones posteriores en esa sesión.Para servidores de gran escala, esto es importante para ahorrar ciclos de cómputo en el descifrado en lugar de usar, por ejemplo, TLS para todo.

Pero espera:Aún no estamos seguros.Sólo hemos impedido la lectura de los mensajes.

Tenga en cuenta que aún es necesario utilizar un mecanismo de resumen de mensajes para evitar la manipulación del intermediario.Si bien nadie puede leer los datos que se transmiten, sin un MD no hay nada que les impida modificarlos.Entonces, aplica un hash al mensaje antes del cifrado y luego envía el hash junto con el mensaje.Luego, el servidor vuelve a cifrar la carga útil al descifrarla y verifica que coincida con el hash que formaba parte del mensaje.Si el mensaje se modificó en tránsito, no lo harán y el mensaje completo se descarta/ignora.

El último mecanismo necesario para protegerse son los ataques de repetición.En este punto, ha impedido que las personas lean sus datos, así como que los modifiquen, pero no les ha impedido simplemente enviarlos nuevamente.Si esto es un problema para su aplicación, su protocolo debe proporcionar datos y tanto el cliente como el servidor deben tener suficiente información con estado para detectar una repetición.Esto podría ser algo tan simple como un contador que forme parte de la carga útil cifrada.Tenga en cuenta que si está utilizando un transporte como UDP, probablemente ya tenga un mecanismo para manejar paquetes duplicados y, por lo tanto, ya pueda manejar ataques de repetición.

Lo que debería ser obvio es que hacer esto bien no es fácil.Por lo tanto, utilice PKI a menos que ABSOLUTAMENTE no pueda hacerlo.

Tenga en cuenta que este enfoque se utiliza mucho en la industria de los juegos, donde es muy deseable gastar la menor cantidad de computación posible en cada jugador para lograr una mayor escalabilidad y, al mismo tiempo, brindar seguridad contra piratas informáticos y miradas indiscretas.

Entonces, en conclusión, si esto es realmente algo que le preocupa, en lugar de intentar encontrar un lugar seguro para almacenar las claves API, no lo haga.En su lugar, cambie la forma en que su aplicación usa esta API (suponiendo que tenga control de ambos lados, naturalmente).Utilice una PKI o utilice un híbrido simétrico compartido por una PKI si la PKI será demasiado lenta (lo que RARA VEZ es un problema hoy en día).Entonces no tendrá nada almacenado que sea un problema de seguridad.