¿Cómo puedo proteger el software en el Pi para uso comercial?

Me gustaría usar Raspberry Pi en un producto comercial, pero me gustaría evitar la ingeniería inversa del software en el dispositivo. El software en cuestión estaría escrito en Ruby. Supongo que el usuario final tiene acceso físico a la tarjeta SD y es lo suficientemente inteligente como para obtener acceso raíz a la Pi.

A mi modo de ver, las opciones pueden incluir:

• Cifre parte (o la totalidad) de la tarjeta SD
• Ofusque el código Ruby o compílelo en bytecode (JRuby o Rubinius)

El cifrado sería la mejor solución, pero no se me ocurre una forma de descifrar sin pedirle la clave al usuario. La ofuscación de código es definitivamente posible, pero menos segura en mi mente.

¿Es posible encriptar una parte de la tarjeta SD sin pedirle al usuario una clave para desencriptarla? ¿O hay una mejor manera de asegurarse de que el código solo sea accesible en el dispositivo deseado?

Por supuesto, es posible descifrar archivos cifrados / contenedores / etc. sin pedir una contraseña Es suficiente almacenar la contraseña (encriptada) en la tarjeta SD y usarla para descifrar sus datos. Por ejemplo, una openssldemostración fácil podría ser:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

El cifrado se realizaría al instalar el software en el Pi, y el descifrado se realizaría en tiempo de ejecución, posiblemente en la RAM. Por ejemplo, la contraseña podría ser una combinación de algún número de secuencia pseudoaleatoria (conocido por usted) y el número de serie del Pi específico obtenido de a cat /proc/cpuinfo. Luego, debe encontrar una ubicación adecuadamente oculta para almacenar este número pseudoaleatorio que sea, a todos los efectos, " la contraseña " y, por lo tanto, el punto débil de todo el mecanismo de cifrado. Por ejemplo, un sector libre en la SD sería la opción típica, pero incluso puede incrustarlo en uno de sus ejecutables.

En cualquier caso, su mejor opción es cifrar y compilar su software, para agregar diferentes capas de ofuscación a su software.

Finalmente, si su software necesita una conexión a Internet, incluso puede hacer que el Pi solicite la contraseña cada vez. Aún necesitará ocultar la contraseña dentro de la conexión, también deberá usarla httpsy deberá protegerse contra ataques de respuesta, usando la hora actual en saltcuanto al cifrado.

Tiene muchas opciones (baratas) para hacer que su software sea seguro. Pero debe saber que si su software alcanza un umbral de popularidad bien definido, se romperá con seguridad, incluso si invierte cantidades sustanciales de dinero en su protección.

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

1. ¿Qué tan probable es que esto suceda?
2. ¿Cuál es el valor para otra persona 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 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 .

Recientemente he inventado una solución muy elegante para este problema irresoluble. Fue inspirado por este cómic xkcd:

Entonces la solución se llama superpegamento . Si una tarjeta SD superpega al PI, será casi imposible extraer la tarjeta sin dañarla.

¡Incluso puede usar un disco SSD externo, cifrado con una contraseña almacenada en SD y sentirse seguro!

La compilación de bytecode sería el mejor repelente. En cuanto al cifrado, el software podría almacenarse en el volumen TrueCrypt, pero solo si el usuario no obtuvo acceso a la raíz; simplemente no hay forma de almacenar la contraseña de forma segura ya que la memoria / disco se puede volcar en cualquier momento para su inspección. Incluso la ayuda de dispositivos seguros (tarjetas inteligentes) no haría mucho, si el software se ejecuta donde el usuario tiene una gran cantidad de utilidades de Linux. Hasta donde yo sé, el arranque seguro no es una opción en R-Pi que evitaría que el usuario manipule el sistema operativo.

Si desea hacer una verdadera aplicación comercial, entonces el Pi, como está en su forma de usuario final, ¡no es bueno para usted!

Tendrá que diseñar su propia PCB, usar el procesador que está en la Pi, por ejemplo, e incrustar una memoria flash en la PCB.

1. Escriba un firmware de propiedad para el BCM que generó un único código de inicio de sesión basado en algún algoritmo de alto secreto que solo se puede usar en los próximos 10 segundos.
2. Compile su propio kernel con su software propio y habilite algunas características de Linux que le permiten montar root desde un archivo encriptado en el flash, que contiene otra partición encriptada con su software (doble protección)
3. Su firmware BCM generará un secreto superior una vez que se desactive la clave de autenticación en función de algunos algoritmos inteligentes o claves públicas y lo pasará a su kernel de Linux personalizado, que cargará la partición raíz cifrada y hará algunas cosas criptográficas más durante el arranque para cargar su unidad de software cifrada dentro de la imagen encriptada.

CONSEJOS

• Las claves de autenticación correctas no tienen una longitud de 8-16 caracteres. Es importante proporcionar claves de autenticación de 256/512 bytes utilizando más símbolos del sistema (HEX) y menos caracteres (ASCII)
• No use AES, TKIP ya que se agrieta fácilmente
• A partir de hoy, el cifrado Whirlpool es uno de los más complicados de descifrar usando claves 256/512
• Incluso si un hacker puede quitar la unidad flash o volcar el contenido. Su software está encriptado dos veces.
• Si interceptan la clave de autenticación, será muy difícil salir del firmware (porque el BCM puede evitar los volcados de firmware)
• Algunas flash rom inteligentes también tienen una función para evitar volcados de memoria completa.
• Si está diseñando una PCB, implementará (como Dell y Apple) un chip de seguridad que proporciona todos sus datos y claves de cifrado y evita los intentos de fuerza bruta. Algunos Dell tienen una autodestrucción para uso militar. Si ingresa la contraseña del BIOS incorrecta 2 veces, limpia las unidades con bombas de dispersión. Podría implementar lo mismo si detecta manipulaciones de clave de autenticación.

Fin del día. El Raspberry Pi está destinado a fines educativos para que los niños aprendan a usar Linux y a escribir algunos programas.

No es apto para uso comercial de alto perfil. Debe crear su propio dispositivo y crear sus propios sistemas de protección. Porque si solo usted y nadie más sabe cómo protege su información de propiedad, entonces las posibilidades de que alguien la piratee utilizando un exploit o bruto conocido ... es 0.001%

ALTERNATIVAS

• Escriba su software para que pueda compilarse e implementarse en el sistema de destino en formato binario. Ejemplo de EXE para Windows que se ejecuta en .NET, JAR para Java o (¿No está seguro en Linux, C ++?)
• Recuerde, cuanto mejor sea la seguridad que desea, más dinero tendrá que gastar en ella. No hay excepciones

Una de las soluciones es utilizar la dirección MAC de RaspberryPi, que es casi única para un determinado Pi. Verifique esta dirección dentro de su código y proporcione la versión compilada. Esto dificultará la ingeniería inversa.

Para las personas que copian ciegamente la tarjeta SD en una nueva, no les funcionará en otra Pi. Esto alejará a la gran mayoría de las personas que roban su software. Otros que son lo suficientemente inteligentes como para romper esto pueden ser lo suficientemente inteligentes como para rehacer el software, no son numerosos y no creo que perjudiquen sus ventas.

Puede utilizar una solución basada en piggy back: Protección serial de software para Raspberry Pi

¿Por qué no agregar un flash basado en SPI a su placa de operador y almacenar su código en ella? Estoy considerando esta opción para mi propio producto. En caso de que la SD se corrompa, quiero que el usuario final pueda escribir una nueva, que incluye un raspbian personalizado, y el código para montar el flash SPI y ejecutar el ejecutable.

Otra opción es almacenar una clave de cifrado en su RTC. La mayoría de los chips RTC tienen algo de almacenamiento y podrían preprogramarse con la clave que permite desbloquear y montar el ejecutable desde SD o desde flash SPI.

Creo que todas las CPU utilizadas en el rango de Raspberry Pi admiten un arranque seguro propio. Creo que requiere 12 voltios para volver a flashear los 4,8,16,32 o 64K de flash interno o EEPROM que el pi en sí no tiene. Desde allí, puede configurar Trustzone con su código para que no se puedan ver todas las cosas buenas. También entiendo que ambas formas de RAM estática solo son estables para un número dado de reescrituras. Mi primer paso sería tener una CPU de repuesto e intentar actualizar esta memoria de arranque segura durante unas horas o días. Eventualmente, todos los bits se arreglan para que nadie más pueda modificar su código y, dependiendo del producto real, puede solicitar periódicamente una identificación de 2 factores (como bancos) para que el producto escupe un código y el código de reactivación se envíe a la direccion de correo electronico. Si modificas un poco el pi, Creo que ARM también tiene una CPUID, por lo que hay una serie de niveles de seguridad a los que puede optar. Quiero decir, también puedes ofrecer un SMS a un número específico. Muchas maneras