Evite el robo de firmware

Me gustaría saber si hoy existe una opción 100% segura para evitar la copia de firmware de MCU. La mayoría de los MCU pueden tener una opción configurada en la programación que bloqueará cualquier extracción de código, pero esto suele ser fácil de piratear, especialmente si usa ácidos para acceder al dado y sondearlo.

Una vez vi que algunas MCU usan soluciones criptográficas, pero no estoy seguro de cómo funcionan, supongo que prueban algún hardware externo en busca de claves específicas, pero esto es fácil de cambiar en el código una vez que se extrae.

Una opción 100% segura para evitar el robo de firmware es no crear nunca el producto. No existe una opción 100% segura. Una persona/equipo/empresa dedicada lo conseguirá si lo desea lo suficiente.
No existe tal cosa. Lo mejor que puede hacer para tratar de hacerlo demasiado caro para el adversario.
Crypto es todo una cuestión de tiempo; eventualmente se romperá, así que todo lo que puedes hacer es asegurarte de que tarde 10.000 años en romperse. Entonces, ¿tal vez usar un microprocesador para descifrar el código sobre la marcha? Pero si el código está encriptado, la clave está en algún lugar del tablero y podría recuperarse. Entonces... Supongo que todo el sistema operativo tiene que estar encriptado. Solo un pensamiento.
Si una parte interesada puede obtener su dispositivo, puede observar sus acciones y probablemente crear su propio programa para duplicar las acciones de su dispositivo.
Cuando los gobiernos tienen que prevenir seriamente el robo de firmware, detectan el ataque físico (el atacante ingresa al gabinete) y borran el firmware. La suposición es que si un atacante puede poner sus manos en la placa de circuito, puede hacer cualquier cosa desde ese punto.
Nunca crear el producto tampoco es 100% seguro: ¡No quiero pensar en la cantidad de productos que nunca creé (solo para estar seguro) que algún competidor se adelantó y copió de todos modos!
@NickAlexeev dio con el gran problema de los dispositivos criptográficos. La detección de manipulación da como resultado una limpieza, aunque con suficientes dispositivos de muestra, uno podría presumiblemente aplicar ingeniería inversa a la detección de manipulación y solucionarlo.

Respuestas (3)

Si sabe que su MCU siempre tendrá energía, en teoría podría mantener su firmware en la RAM y aplicar medidas externas que cortarán la energía de la RAM/la borrarán para que el firmware se pierda si el usuario hace algo como quitar una cubierta. Esto se hace para algunas aplicaciones bancarias (aunque generalmente solo borran claves criptográficas). No está 100% garantizado, pero probablemente lo acercará lo suficiente como para que sea inviable para casi todos los atacantes.

Puede encontrar más ideas en este video de desmontaje de una máquina de tarjetas de crédito .

En realidad, no veo la necesidad de este nivel de protección de hardware para el firmware. No será barato de hacer y un competidor oportunista podría fácilmente aplicar ingeniería inversa a la funcionalidad y vender un producto más barato que usted.

A veces, proteger un algoritmo es lo que hace que su sistema sea único, como los algoritmos de control de motores de precisión, etc., y el almacenamiento en RAM no es tan borrable como la gente piensa, los datos permanecen en la memoria durante un minuto más o menos... y se escriben encima. debería ser mejor... gracias por el enlace
Depende del tipo de RAM que tengas. Algunos se especifican para este propósito cuando tiene datos críticos que necesitan protección. Soy de la opinión de que los casos que involucran la protección de códigos/algoritmos especiales en un grado tan alto son aquellos que son problemas de "seguridad nacional", por ejemplo, sistemas de guía de misiles (aunque si el atacante tiene acceso al hardware, está en problemas). ya). Simplemente elimine los encabezados de depuración y posiblemente encapsular su dispositivo detendrá a casi todos los empresarios nefastos.
No sé sobre SRAM, pero creo que ha habido experimentos en los que el contenido de DRAM se ha conservado usando criogenia el tiempo suficiente para obtener información útil de ellos. Sin embargo, creo que, por lo general, el software llevaría a cero la región sensible, lo que aumentaría enormemente la dificultad de recuperar los datos.
@RJP También he visto este experimento criogénico, es preferible poner a cero la RAM, pero esto solo se aplica a los sistemas donde habrá energía todo el tiempo

Si cree que el acceso al troquel ácido es fácil, hay pocas soluciones difíciles :-).

Una "caja" externa que procesa los datos suministrados con un algoritmo o proceso útil y desconocido y al que se accede por medios criptográficamente seguros (por ejemplo, criptografía de clave pública) y devuelve un resultado útil hace que el sistema sea tan seguro como el dispositivo externo o como la dificultad. de replicar el algoritmo o proceso. Ambos se pueden hacer "muy duros". [por ejemplo, un dispositivo alimentado internamente con energía o detección de intrusos a través de una red codificada semialeatoriamente de alambre de cobre fino que se envuelve alrededor del dispositivo con todo el conjunto en una matriz cerámica resistiría la mayoría de los métodos de ataque sensibles.]

Aquí hay uno de esos sistemas de hace mucho tiempo {1987!} -
que describe un sistema titulado "Ninox"*. Este documento también estaba destinado a tener mi nombre adjunto, pero no pude hacer que el archivo adjunto fuera criptográficamente seguro :-). El mérito actualmente percibido de esta 'sugerencia' puede indicarse por el hecho de que el documento ahora está disponible para su compra por $1.98.

Abstracto:

Este documento describe un sistema de protección de software que probablemente será ampliamente utilizado en los próximos años en un esfuerzo por controlar los problemas de piratería de software experimentados por los desarrolladores de software para microcomputadoras.

El sistema descrito fue desarrollado por el autor y un asociado. Varios otros investigadores han ideado técnicas similares de forma independiente, pero creemos que el trabajo descrito en este documento incluye algunos nuevos desarrollos útiles. Hemos llamado al sistema Ninox.

El sistema utiliza un dispositivo serializado en cada sistema informático y proporciona facilidades para que el software suministrado al usuario pueda ejecutarse solo en la máquina del usuario y es imposible modificar el software para ejecutarlo en otra máquina.

La criptografía de clave pública se utiliza para cifrar programas y se describe un método de distribución de programas. El documento también examina algunas de las dificultades con el sistema y sugiere algunos de los métodos por los cuales el sistema podría ser atacado y cómo resiste estos ataques. En general, se sostiene (y se apoya en el análisis formal de la teoría de la información) que es imposible crear un sistema totalmente seguro.

  • Ninox novaeseelandiae es el búho de Nueva Zelanda, comúnmente denominado Morepork (por su llamada) o Ruru en maorí (también por su llamada). Elegí el nombre porque 'Ninox' puede (más que la mayoría) ver en la oscuridad. Más

ingrese la descripción de la imagen aquí

Muy interesante, gracias!

Recientemente hice una placa ARM personalizada para mi robot de combate, y el Atmel SAM3S4 que usé en él tiene un pin de borrado que, cuando se ejerce, literalmente deja en blanco su microcontrolador.

Esto está pensado como una característica de seguridad para el espionaje industrial, donde puede instalar un sensor/interruptor/dispositivo engañoso que activa esto al detectar una intrusión. Todo lo que queda es el cargador de arranque SAMBA que estos dispositivos Atmel restauran al borrar todo lo demás.

Esa función también se usa para los programas USB Flash en el dispositivo, a menos que, por supuesto, tenga una conexión JTAG, ese proceso es innecesario.

Sí, estos pines ayudan, pero dependen de que sus sensores funcionen bien, mire el video helloworld922 enviado por mike, también muestra este tipo de pin
Por curiosidad, ¿realmente necesitabas un ARM para un Combot? Solía ​​competir mucho en los EE. UU. y Brasil, y la mayoría de los robots son realmente simples en términos de electrónica integrada para la necesidad de una MCU ARM.
@mFeinstein, el robot de combate de peso de pulgas fue solo una aplicación inicial para mi tablero, el objetivo final es hacer una visión de robot de baja resolución para la adquisición de objetivos y SLAM visual (ratSLAM), entre otras cosas. También por interés personal en MCU ARM porque he hecho demasiados microcontroladores AVR de 8 bits integrados, pensé en aventurarme en la tierra ARM.
Evite el robo de firmware
RespuestasAquíPolítica de privacidad1y, 0v