Asegurar el código en un AVR / Arduino y entregar actualizaciones

9
  1. ¿Cuál es la mejor manera de proteger el código actualizado en cualquier dispositivo basado en AVR de la ingeniería inversa?
  2. ¿Cuál es una manera fácil de proporcionar actualizaciones a los usuarios finales para flashear por su cuenta sin revelar el código? (¿Es con un gestor de arranque que descifra una imagen cifrada?)

No me critiquen por promover DRM, estoy a favor de las plataformas abiertas, solo tengo curiosidad por saber cómo funcionaría.

arduino avr encryption reverse-engineering stbtra
fuente
No lo hagas No hay ninguna manera a su totalidad evitar la posibilidad de una persona con malas intenciones ingeniería inversa sobre su hardware / software. Todo lo que hacen las medidas Anti-RE es hacer que demore más en revertirse.
Connor Wolf

Respuestas:

9

Primero:

Hay fusibles en el chip que se pueden configurar para evitar que las herramientas externas lean el código del chip. Busque los fusibles de protección en su hoja de datos y / o documentación del programador.

No es perfecto, pero te protege de ataques simples.

Segundo:

No puede descargar el firmware de forma segura. El AVR no puede autoprogramar áreas protegidas:

http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf

Lo mejor que puede hacer es utilizar un lenguaje de token cifrado (como básico o posterior) y tener el intérprete protegido en el chip con un gestor de arranque que pueda programar los tokens cifrados en un área abierta. Cuando se ejecuta, el chip descifraría y ejecutaría las instrucciones sobre la marcha.

Adam Davis
fuente
3
Si los fusibles no son perfectos, ¿qué tipo de ataque puede evitarlo?
1
@Anónimo: graba químicamente la cubierta del chip y utiliza microscopios electrónicos, láseres y micro sondas para ver, interactuar y editar el silicio. Cuesta al menos $ 500, pero puede ser más barato que cualquier trabajo que Stbra esté poniendo en el dispositivo.
Kevin Vermeer
@KevinVermeer ¿Querías decir $ 500? Me parece que sería mucho más caro que eso.
NickHalden
Adam, hubo un error, así que
eliminé
3

Si es tan importante y le preocupa especialmente que los competidores roben su código, elimine la protección IP en sus segmentos de código. Debería estar investigando esto si va a intentar ganar dinero con un proyecto de todos modos.

Ciertos elementos del código pueden ser patentados (para métodos de procesamiento específicos y algoritmos novedosos) o registrados como diseños industriales (la apariencia, el diseño y la aplicación de su código a un dispositivo). Es posible que desee consultar a un abogado de propiedad intelectual sobre esto.

Sketchy Fletchy
fuente
1

Si escribió su propio gestor de arranque que aceptaba datos cifrados a través del puerto serie, los descifraba y los almacenaba en el área de almacenamiento de código, podría tener una actualización segura del firmware del código. Cada dispositivo podría incluso tener su propia clave de descifrado única en su gestor de arranque personalizado.


fuente
1
Sin embargo, creo que lo que dice @Adam Davis es que si usa un gestor de arranque (incluso uno que escribió), entonces no puede programar áreas protegidas con bits de bloqueo. Entonces, si escribiste tu propio gestor de arranque cifrado, no podrías evitar que se lea el chip (problema 1). Eso parece ser lo que obtengo del enlace y la hoja de datos, de todos modos.
Lou
si el gestor de arranque y el código están encriptados, resolvería el segundo problema, el primer problema está casi resuelto si utiliza un cifrado lo suficientemente seguro. (la velocidad de uC puede ser un cuello de botella).
Rick_2047
Cierto. @Adam Davis sugirió un lenguaje de token encriptado arriba.
Lou