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

  1. ¿Cuál es la mejor manera de proteger el código flasheado 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 que actualicen por su cuenta sin revelar el código? (¿Es con un gestor de arranque que descifra una imagen cifrada?)

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

No. NO HAY MANERA de evitar por completo la posibilidad de que una persona malintencionada realice ingeniería inversa de su hardware/software. Todo lo que hacen las medidas Anti-RE es hacer que tarde más en revertirse.

Respuestas (3)

Primero:

Hay fusibles en el chip que se pueden configurar para evitar que 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 usar un lenguaje de token encriptado (como básico o similar) y tener el intérprete protegido en el chip con un gestor de arranque que pueda programar los tokens encriptados en un área abierta. Al ejecutarse, el chip descifraría y ejecutaría las instrucciones sobre la marcha.

Si los fusibles no son perfectos, ¿qué tipo de ataque puede evitarlo?
@Anónimo: grabado químico de la cubierta del chip y uso de microscopios electrónicos, láseres y microsondas 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.
@KevinVermeer ¿Quiso decir $500? Me parece que sería mucho más caro que eso.
Adam, hubo un error, así que eliminé mi comentario.

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

Ciertos elementos del código pueden patentarse (para métodos de procesamiento específicos y algoritmos novedosos) o registrarse 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.

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

Sin embargo, creo que lo que dice @Adam Davis es que si usa un gestor de arranque (incluso uno que haya escrito), entonces no puede programar áreas protegidas de bit de bloqueo. Entonces, si escribió su propio cargador de arranque encriptado, no pudo evitar que se leyera el chip (problema 1). Eso parece ser lo que obtengo del enlace y la hoja de datos, de todos modos.
si el cargador de arranque y el código están encriptados, resolvería el segundo problema, el primer problema está casi resuelto si usa un cifrado lo suficientemente seguro. (la velocidad de uC puede ser un cuello de botella).
Verdadero. @Adam Davis sugirió un lenguaje de token encriptado arriba.
Asegurar código en un AVR/Arduino y entregar actualizaciones
RespuestasAquíPolítica de privacidad1y, 0v