Esta es la solución más completa que encomtrarás dar, sin embargo obsérvala pausadamente y analiza si se adapta a tu trabajo.
Solución:
Hay maneras de hacer lo que quieres, pero no es barato y no es fácil.
¿Vale la pena?
Al analizar si proteger el software, primero debemos responder una serie de preguntas:
- ¿Qué tan probable es que esto suceda?
- ¿Cuál es el valor para otra persona de su algoritmo y datos?
- ¿Cuál es el costo para ellos de comprar una licencia para usar su software?
- ¿Cuál es el costo para ellos de replicar su algoritmo y datos?
- ¿Cuál es el costo para ellos de la ingeniería inversa de su algoritmo y datos?
- ¿Cuál es el costo para usted de proteger su algoritmo y sus datos?
Si esto produce un imperativo económico significativo 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 la ingeniería inversa de su código es mucho más bajo que el costo de desarrollarlo ellos mismos, entonces las personas pueden intentarlo.
Entonces, esto lleva a tu pregunta.
- ¿Cómo asegura su algoritmo y sus datos?
Desánimo
Ofuscación
La opción que sugiere, ofuscar el código, interfiere con la economía anterior: intenta aumentar significativamente el costo para ellos (5 arriba) sin aumentar mucho el costo para usted (6). La investigación del Center for Encrypted Functionalities ha realizado algunas investigaciones interesantes al respecto. 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 difieren, lo que facilita la identificación del mensaje oculto.
Proteccion
SaaS – Software como servicio
Una opción más segura podría ser proporcionar la parte crítica de su software como servicio, en lugar de incluirla en su aplicación.
Conceptualmente, su aplicación recopilaría todos los datos necesarios para ejecutar su algoritmo, los empaquetaría como una solicitud a un servidor (controlado por usted) en la nubesu servicio luego calcularía sus resultados y se los devolvería al cliente, que los mostraría.
Esto mantiene todos sus datos y algoritmos confidenciales y patentados dentro de un dominio que usted controla por completo, y elimina cualquier posibilidad de que un cliente los extraiga.
La desventaja obvia es que los clientes están atados a su prestación de servicios, están a merced de sus servidores y su conexión a Internet. Desafortunadamente, muchas personas se oponen a SaaS exactamente por estas razones. En el lado positivo, siempre están actualizados con correcciones de errores, y es probable que su clúster 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 formas de mantener su algoritmo y datos completamente seguro.
Dongles de protección de software
Aunque los dongles de protección de software tradicionales protegerían contra la piratería de software, no lo harían contra la extracción de algoritmos y datos en su código.
Dongles de portabilidad de código más nuevos (como SenseLock†) parecen ser capaces de hacer lo que quieres sin embargo. Con estos dispositivos, extrae el código de su aplicación y lo transfiere al procesador de dongle seguro. Al igual que con SaaS, su aplicación agruparía los datos, los pasaría al dongle (probablemente un dispositivo USB conectado a su computadora) y volvería a 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 usar 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á una huella digital de su hardware y usted le proporcionará un desbloqueo. key para ese sistema específico.
Esta key permitiría entonces que el código se descifre y se ejecute dentro del entorno de confianza, donde el código y los datos cifrados serían inaccesibles fuera de la plataforma de confianza. Si algo cambiara en el entorno de confianza, invalidaría el key y esa funcionalidad se perdería.
Para el cliente, esto tiene la ventaja de que sus datos permanecen 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 sientan frustrados con el obstáculos que tuvieron que atravesar para usar el software que compraron y pagaron, perdiendo su 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.
Todos los esfuerzos serán inútiles si alguien está lo suficientemente motivado para romperlo. Nadie ha logrado resolver esto todavía, ni siquiera las compañías de software más grandes.
Estoy haciendo todo lo posible para asegurarlo.
No digo esto como una crítica mordaz, solo debe ser consciente de que lo que intenta lograr actualmente se supone que es imposible.
La ofuscación es seguridad a través de la oscuridad, tiene algunos beneficios, ya que disuadirá a los piratas informáticos más incompetentes, pero en gran medida es un esfuerzo desperdiciado que quizás podría gastarse mejor en otras áreas de desarrollo.
En respuesta a su pregunta original, se encontrará con problemas con los compiladores inteligentes, es posible que reúnan automáticamente el string en la aplicación compilada eliminando algunos de sus esfuerzos de ofuscación como optimizaciones de compilación. También sería difícil de mantener, por lo que reconsideraría su modelo de análisis de riesgo y tal vez se resigne al hecho de que puede ser descifrado y, si tiene algún valor, probablemente lo sea.
Recientemente leí una solución muy simple para OP.
Simple declara tus constantes como de solo lectura stringno constante string. Así de sencillo. Aparentemente, las variables constantes se escriben en un área de pila 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 un byte. array en lugar de texto.
Es decir, si lo buscas, no lo encontrarás.
Esa era la pregunta, ¿no?
Puntuaciones y comentarios
Al final de todo puedes encontrar las críticas de otros programadores, tú incluso tienes la libertad de mostrar el tuyo si lo crees conveniente.