En la práctica, si el código y las llaves están en una máquina de tarjetas SD, que van a ser capaces de de-compilarlo, que van a ser capaces de descubrir las claves y ellos van a ser capaces de extraer los datos sensibles.
Es como encriptar películas, un DVD tiene que incluir toda la información requerida para desencriptar la película para que pueda mostrarse al espectador, por lo que todos los mecanismos de protección de copia de la película están condenados.
Lo mejor que puede hacer es cambiar la economía de la ingeniería inversa de su producto.
¿Vale la pena el cifrado y / o la ofuscación?
Ahora hemos establecido que no hay forma de protegerse por completo, las preguntas se vuelven
- ¿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 protege su algoritmo y sus datos?
Ofuscación
La opción que sugiere, ofuscar el código, se mete con la economía anterior: trata de aumentar significativamente el costo para ellos (5 arriba) sin aumentar mucho el costo para usted (6). El problema es que, al igual que con el cifrado de DVD, está condenado al fracaso y, si hay suficiente diferencia entre 3, 4 y 5, eventualmente alguien lo hará.
Otra opción podría ser una forma de esteganografía , que le permite identificar quién descifró su código y comenzó a distribuirlo. 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 múltiples copias de los datos de su aplicación, sería obvio que difiere, lo que facilita la identificación del mensaje oculto.
Proteccion
La única opción realmente segura es proporcionar una parte crítica de su software como servicio , en lugar de incluirlo en su aplicación.
Conceptualmente, su aplicación recolectaría todos los datos necesarios para ejecutar su algoritmo, los empaquetaría como una solicitud a un servidor (controlado por usted) en la nube , su servicio calcularía sus resultados y los devolvería al cliente, que lo mostraría.
Esto mantiene todos sus datos y algoritmos confidenciales y de propiedad dentro de un dominio que usted controla por completo, y elimina cualquier posibilidad de que un cliente extraiga tampoco.
La desventaja obvia 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. En el lado positivo, siempre están actualizados con correcciones de errores. Desafortunadamente, muchas personas se oponen a SaaS por exactamente estas razones.
Sin embargo, este sería un gran paso, y podría tener un costo enorme 6 por encima, pero es la única forma en que puedo ver para mantener su algoritmo y sus datos completamente seguros .
