¿Cómo ofuscar las constantes de cuerda?

Tenemos una aplicación que contiene información confidencial y estoy haciendo todo lo posible para protegerla. La información sensible incluye:

  1. El algoritmo principal
  2. Las claves para un algoritmo de cifrado / descifrado.

He estado mirando ofuscando el código pero no parece ayudar mucho ya que todavía puedo descomstackrlo. Sin embargo, mi mayor preocupación es que las claves utilizadas para el cifrado de números de serie, etc., son claramente visibles cuando se descomstack el código, incluso cuando está ofuscado.

¿Alguien puede sugerir cómo puedo asegurar estas cadenas?

Me doy cuenta de que uno de los métodos podría ser eliminar cualquier descifrado de la aplicación, mientras que esto puede ser posible en parte, hay algunas características que tienen que usar cifrado / descifrado, principalmente para guardar un archivo de configuración y pasar una ‘autorización’ token a una DLL para realizar un cálculo.

Todos los esfuerzos serán inútiles si alguien está lo suficientemente motivado para romperlo. Nadie ha logrado resolver esto todavía, incluso las compañías de software más grandes.

Estoy haciendo mi mejor esfuerzo para asegurarlo

No estoy diciendo esto como una crítica mordaz, solo necesitas ser consciente de que lo que intentas lograr se supone que actualmente es imposible.

La ofuscación es la seguridad a través de la oscuridad, tiene algún beneficio, ya que disuadirá a los bashs de piratas informáticos más incompetentes, pero en gran parte se desperdicia un esfuerzo que tal vez podría gastarse mejor en otras áreas del desarrollo.

En respuesta a su pregunta original, se encontrará con problemas con los comstackdores inteligentes, ya que podrían ensamblar automáticamente la cadena en la aplicación comstackda, eliminando parte de sus esfuerzos de ofuscación como optimizaciones de comstackción. También sería difícil de mantener, por lo que reconsideraría su modelo de análisis de riesgo y tal vez me resignaría al hecho de que se puede descifrar y que si tiene algún valor probablemente lo será.

Hay formas de hacer lo que quieres, pero no es barato y no es fácil.

¿Vale la pena?

Al considerar si proteger el software, primero tenemos que responder una serie de preguntas:

  1. ¿Qué tan probable es que esto suceda?
  2. ¿Cuál es el valor para alguien más de su algoritmo y datos?
  3. ¿Cuál es el costo para ellos de comprar una licencia para usar su software?
  4. ¿Cuál es el costo para ellos de replicar su algoritmo y datos?
  5. ¿Cuál es el costo para ellos de la ingeniería inversa de su algoritmo y datos?
  6. ¿Cuál es el costo para usted de proteger su algoritmo y sus datos?

Si estos producen un imperativo económico importante para proteger su algoritmo / datos, entonces debería considerar hacerlo. Por ejemplo, si el valor del servicio y el costo para los clientes son altos, pero el costo de ingeniería inversa de su código es mucho más bajo que el costo de desarrollarlo por sí mismo, entonces la gente puede intentarlo.

Por lo tanto, esto lleva a su pregunta

  • ¿Cómo asegurar su algoritmo y datos?

Desaliento

Ofuscación

La opción que sugiere, que confunde el código, confunde con los aspectos económicos anteriores: trata de boost significativamente el costo para ellos (5 arriba) sin boost el costo para usted (6) mucho. La investigación realizada por el Centro de Funcionalidades Encriptadas ha hecho algunas investigaciones interesantes sobre esto. El problema es que, al igual que con el cifrado de DVD, está condenado al fracaso si hay suficiente diferencia entre 3, 4 y 5 y, finalmente, alguien lo hará.

Detección

Otra opción podría ser una forma de esteganografía , que le permite identificar quién descifró sus datos y comenzó a distribuirlos. Por ejemplo, si tiene 100 valores flotantes diferentes como parte de sus datos, y un error de 1 bit en el LSB de cada uno de esos valores no causaría un problema con su aplicación, codifique un identificador único (para cada cliente) en esos bits . El problema es que si alguien tiene acceso a varias copias de los datos de su aplicación, sería obvio que difiere, lo que facilita la identificación del mensaje oculto.

Proteccion

SaaS – El software como servicio

Una opción más segura podría ser proporcionar la parte crítica de su software como un servicio , en lugar de incluirlo en su aplicación.

Conceptualmente, su aplicación recostackría todos los datos necesarios para ejecutar su algoritmo, empaquetarlo como una solicitud a un servidor (controlado por usted) en la nube , su servicio luego calcularía sus resultados y los pasaría de nuevo al cliente. que lo mostraría.

Esto mantiene todos sus algoritmos y datos confidenciales y propietarios dentro de un dominio que usted controla completamente, y elimina cualquier posibilidad de extracción de un cliente.

El inconveniente obvio es que los clientes están vinculados a la provisión de su servicio, están a merced de sus servidores y su conexión a Internet. Desafortunadamente, muchas personas se oponen a SaaS por exactamente estas razones. En el lado positivo, siempre están actualizados con las correcciones de errores, y es probable que su grupo de cómputo tenga un mayor rendimiento que la PC en la que ejecutan la interfaz de usuario.

Sin embargo, este sería un gran paso, y podría tener un costo enorme 6 arriba, pero es una de las pocas maneras de mantener su algoritmo y datos completamente seguros .

Dongles de protección de software

Aunque los dongles de protección de software tradicionales protegen de la piratería de software, no protegen contra algoritmos y datos que se extraen de su código.

Sin embargo, los dongles de transferencia de código más nuevos (como SenseLock ) parecen ser capaces de hacer lo que quieras. Con estos dispositivos, usted saca el código de su aplicación y lo transfiere al procesador seguro de la mochila. Al igual que con SaaS, su aplicación agrupará los datos, los pasará al dongle (probablemente un dispositivo USB conectado a su computadora) y leerá los resultados.

A diferencia de SaaS, es poco probable que el ancho de banda de datos sea un problema, pero el rendimiento de su aplicación puede verse limitado por el rendimiento de su SDP.

† Este fue el primer ejemplo que pude encontrar con una búsqueda en Google.

Plataforma de confianza

Otra opción, que puede volverse viable en el futuro, es utilizar un Módulo de plataforma confiable y una Tecnología de ejecución confiable para asegurar áreas críticas del código. Cada vez que un cliente instala su software, le proporcionarán una huella dactilar de su hardware y usted le proporcionará una clave de deslocking para ese sistema específico.

Esta clave permitiría entonces que el código se descifre y se ejecute dentro del entorno de confianza, donde el código y los datos encriptados serían inaccesibles fuera de la plataforma de confianza. Si cambiara algo el entorno de confianza, invalidaría la clave y esa funcionalidad se perdería.

Para el cliente, esto tiene la ventaja de que sus datos se mantienen locales y no necesitan comprar un nuevo dongle para mejorar el rendimiento, pero tiene el potencial de crear un requisito de soporte continuo y la probabilidad de que sus clientes se frustren con el tenían que saltar para usar el software que habían comprado y por el que habían pagado, perdiendo la buena voluntad.

Conclusión

Lo que quieres hacer no es simple ni barato. Podría requerir una gran inversión en software, infraestructura o ambos. Debe saber que vale la pena la inversión antes de comenzar por este camino.

Recientemente leí una solución muy simple para OP.

Simplemente declare sus constantes como cadena de solo lectura, no como cadena de const. Que simple Al parecer, las variables const se escriben en un área de stack en el binario pero se escriben como texto sin formato, mientras que las cadenas de solo lectura se agregan al constructor y se escriben como una matriz de bytes en lugar de texto.

Es decir, si lo buscas, no lo encontrarás.

Esa era la pregunta, ¿verdad?

El uso de un algoritmo personalizado (¿ seguridad a través de la oscuridad? ), Combinado con el almacenamiento de la clave dentro de la aplicación, simplemente no es seguro.

Si está almacenando algún tipo de contraseña, entonces puede usar una función de hashing de una sola vía para asegurarse de que los datos descifrados no estén disponibles en ningún lugar de su código.

Si necesita utilizar un algoritmo de cifrado simétrico, use uno conocido y probado, como AES-256 . Pero, obviamente, la clave no se puede almacenar dentro de su código.

[Editar]

Como mencionó el cifrado de los números de serie , creo que una función de hashing de una sola vía (como SHA-256 ) realmente se ajustaría mejor a sus necesidades.

La idea es agrupar sus números de serie durante el tiempo de construcción en sus representaciones de hash, que no pueden revertirse (se considera que SHA-256 es un algoritmo bastante seguro , en comparación con, digamos, MD5). Durante el tiempo de ejecución, solo necesita aplicar la misma función hash a la entrada del usuario y comparar solo los valores hash . De esta manera, ninguno de los números de serie reales están disponibles para el atacante.

@Tom Gullen ha dado una respuesta adecuada.

Simplemente recibí algunas sugerencias sobre cómo puede dificultar a los usuarios el acceso a sus claves y algoritmo.

En cuanto al algoritmo: no compile su algoritmo en tiempo de comstackción, sino en tiempo de ejecución. Para poder hacer esto, necesita especificar una interfaz que contenga los métodos para el algoritmo. La interfaz se utiliza para ejecutarlo. Luego, agregue el código fuente del algoritmo como una cadena encriptada (recurso incrustado). Descifre en tiempo de ejecución y use CodeDom para comstackrlo en una clase .NET.

Claves: la forma habitual es almacenar partes separadas de su clave en diferentes lugares de la aplicación. Almacene cada parte como byte[] lugar de string para que sea más difícil encontrarlas.

Si todos sus usuarios tienen una conexión a Internet: busque el código fuente del algoritmo y las claves utilizando SSL.

Tenga en cuenta que todo se ensamblará en el tiempo de ejecución, cualquier persona con un poco más de conocimiento puede inspeccionar / depurar su aplicación para encontrar todo.

No creo que pueda ofuscar fácilmente constantes de cadena, así que, si es posible, no las use 🙂 puede usar recursos de ensamblaje en su lugar, los que puede cifrar como desee.

Depende de lo que intenta hacer, pero ¿puede usar el cifrado asimétrico? De esa manera solo necesitas almacenar claves públicas sin necesidad de ofuscarlas.