Asegurar un dispositivo

4

Scenario:

Estamos en posición de ofrecer un dispositivo local para ejecutar una versión de nuestro software propietario, que normalmente se proporciona como SaaS.

Pregunta :

¿Qué pasos se pueden tomar para mitigar la ingeniería inversa trivial en un entorno no confiable, donde tendrán acceso físico a la caja?

Claramente, es 100% imposible prevenir completamente las fugas de IP, ya que el acceso físico es el acceso total.

Dicho esto, ¿qué técnicas técnicas podrían aplicarse para hacer que la ingeniería inversa sea difícil / inviable?

Editar, para más detalles:

  • El proyecto es internacional, legalmente limitado
  • El acceso a la red está disponible, por lo que quizás un plan podría ser: almacenar aplicaciones en un sistema de archivos encriptado, requerir una conexión a uno de nuestros servidores para recuperar la clave para el descifrado, o algo así. ¿Alguien tiene alguna experiencia o conocimiento?
pregunta Admin 11.07.2013 - 16:25
fuente

2 respuestas

2

Los tokens de seguridad del hardware como se mencionó pueden proporcionar cierta seguridad contra la piratería.

Al no saber qué es su software o qué hace, es difícil saber qué soluciones podrían funcionar. ¿Está poniendo la caja en el sitio porque es más eficiente? ¿Está colocando la caja en el sitio para que el cliente pueda administrarlo ellos mismos? ¿Es porque el cliente lo está ejecutando en una red aislada?

Muchas soluciones de nivel empresarial utilizan estrictos acuerdos de licencia y claves de software criptográficas seguras con el nombre de la empresa compradora y la fecha de caducidad claramente en ellos. Esto significa que incluso los empleados que roban el código solo tienen un uso limitado, ya que los límites de origen y tiempo de uso son claros.

Pero todo esto hace poco o nada para proteger contra la ingeniería inversa.

Los ofuscadores de código y los compiladores de ofuscación pueden ayudarte un poco. De nuevo, depende de su aplicación, su equipo de aplicación, etc.

La resistencia a la manipulación física también podría ayudar, pero limita su capacidad para admitir el hardware físico. La industria de tarjetas de pago utiliza una malla de alambre dentro de su hardware con las claves almacenadas en la memoria volátil, de modo que si se manipula el caso, se pierden importantes claves de descifrado, lo que hace que el dispositivo sea inútil. Técnicas similares se aplican a los HSM (Módulos de seguridad de hardware), que son, efectivamente, bóvedas a prueba de manipulaciones para almacenar claves de cifrado importantes.

Todo el juego es la gestión de riesgos. El costo de iniciar una demanda, el daño causado por una fuga, el costo de asegurar el código, todo debe ser pesado. Pocos secretos son tan importantes que necesitan ser protegidos a toda costa. La demora en el mercado puede costarle su tiempo de ventaja, permitiendo a un competidor alcanzar una solución comparable a un mejor precio antes de que pueda obtener su versión bloqueada por la puerta.

    
respondido por el mgjk 11.07.2013 - 17:12
fuente
0

Puede usar una ofuscación que puede volverse incómoda / compleja, y si no está documentada, no es una buena idea, o puede usar algo como Sentinel HASP . Sin embargo, en una situación de negocios, SLA, TOS y garantías de anulación tienen fuertes impactos cuando se explican claramente. "USTED NO ACCEDERÁ / INGENIERO REVERSO / etc, etc." No detendrá la reversión, pero las empresas toman en serio la pérdida financiera. Más opciones serían el cifrado de arranque, las contraseñas a través del arranque, etc., sin embargo, esas también pueden convertirse en un dolor de cabeza de administración

EDITADO PARA AGREGAR UN ENLACE

enlace

    
respondido por el munkeyoto 11.07.2013 - 16:37
fuente

Lea otras preguntas en las etiquetas