Dado que hay muchas empresas chinas que pueden realizar ingeniería inversa fácilmente en el diseño de PCB y extraer el archivo .hex de los microcontroladores (incluso de el flash seguro), los desarrolladores integrados tienen que agregar más protección a sus productos. En mi caso, estoy usando un STM32F103 y quiero agregar el IC criptográfico ATSHA204A en mi PCB para proteger mi IP. Al hacer esto, espero incluso si pueden sacar el .hex de la MCU y clonar la placa, el archivo hexadecimal se negará a funcionar si no puede reconocer el chip criptográfico en la PCB.
Este IC criptográfico tiene un número de serie único que se escribió mientras se fabricaba y siempre se puede leer. También tiene algunas características como un área segura para mantener algunos datos secretos, la capacidad de generar números aleatorios y enviarlos al host a través de I2C o un cable, la capacidad de calcular el hash SHA-256 de alguna cadena determinada, etc.
Ahora estoy tratando de entender cómo debo trabajar con él, ya que soy un novato en el tema de la autenticación. Por lo que he entendido al leer la hoja de datos, el flujo de trabajo será así:
Personalización del IC criptográfico:
-
El área segura en el cripto El chip será llenado por el host (STM32F103 en mi caso) con alguna clave secreta aleatoria para cada producto, solo una vez.
-
La clave secreta también estará presente en el flash del host memoria.
Autenticación de la placa (según tengo entendido, lo cual probablemente sea incorrecto):
-
El anfitrión solicita un número aleatorio desde el cripto-IC. Luego, el host genera una cadena concatenada con la clave secreta y el número aleatorio (¿nonce?), Y calcula el hash SHA-256 de la misma.
-
Ahora el host debe enviar el clave aleatoria de vuelta al cripto-IC y espere que genere la misma cadena con la clave secreta dentro del cripto-IC y calcule el hash SHA-256 de la misma.
-
Crypto-IC envía el hash calculado al host y el host compara los hash.
-
Si los hashes coinciden, valide. Si no lo hacen, el host se niega a trabajar.
El flujo de trabajo probablemente sea incorrecto, pero la idea principal debería ser algo parecido. ¿Alguien puede explicar esto?
Respuesta
El flujo de trabajo probablemente sea incorrecto, pero la idea principal debería ser algo parecido.
No, esto es básicamente inútil. Esto estaría bien si usara su IC criptográfico, por ejemplo, para validar la autenticidad de un dispositivo adicional (por ejemplo, una impresora que verifica que el cartucho fue fabricado por la misma empresa).
No le ayuda a usted , porque " se niega a trabajar " no volará si alguien tiene el código de máquina de su firmware: encontrar el cheque en el código de máquina desensamblado generalmente no es eso difícil. Luego, es como reemplazar un " saltar a «detenerse y no hacer nada» " con un " saltar al «inicio de funcionalidad útil «"; normalmente, eso implica cambiar un byte.
Necesita cifrar la parte interesante de su firmware en el almacenamiento permanente (normalmente, la memoria flash incorporada de la MCU). Solo un gestor de arranque que utilice el chip criptográfico para descifrar el firmware principal permanecería sin cifrar. En el arranque, el gestor de arranque descifra el firmware en la RAM.
Pequeño problema allí: Debería ser bastante inteligente, en cuanto al hardware, para que uno no pueda simplemente conecte un analizador lógico entre su MCU y el IC criptográfico y olfatee los bytes descifrados.
Hay soluciones que confunden las cosas saltando salvajemente en la memoria mientras descifran cosas, etc. El problema es que no hay nada Un secreto al respecto, es sólo un poco más de trabajo comprender cómo se realiza el salto desde el código de máquina. (Y si logras insertar una sola pieza de código de máquina en ese bus que hace que la MCU transmita toda su RAM a través de algún pin, entonces también se acabó el juego; realmente no te importa si sabes dónde ese fragmento de código termina en la RAM, lo encontrará más adelante en el volcado, solo es importante que se ejecute en algún momento).
En otras palabras, si realmente cree que su firmware es eso comercialmente interesante (¡la gente lo sobreestima enormemente! Para cosas que no son principalmente firmware, como para cualquier dispositivo de consumo y cualquier control industrial, generalmente es difícil obtener todas las piezas y construir el mismo / similar dispositivo más barato que el original, y reescribir completamente el firmware a menudo es fácil en comparación con eso), entonces su única oportunidad es integrar el mantenimiento de secretos, el almacenamiento cifrado y la ejecución segura (de modo que el volcado de RAM sea imposible).
Hay microcontroladores que hacen eso. Por lo general, son un poco más caros.Pero, como puede adivinar, si está, por ejemplo, en un entorno de defensa donde necesita certificar que el firmware no puede ser manipulado, bueno, ese es su camino a seguir.
Nintendo fabrica dispositivos en los que el incentivo financiero para no permitir que nadie lea su firmware o incluso lo modifique es fuerte:
La incapacidad de los usuarios para ejecutar software sin licencia de Nintendo en sus consolas es fundamental para su modelo de negocio. Por lo tanto, ser incapaz de eludir la verificación de las firmas del juego es primordial, y es por eso que un Nintendo Switch hace todo lo posible con múltiples capas de protección. Como puede adivinar, eso no es garantía – simplemente hubo aficionados (¡ni siquiera personas con intereses criminales / comerciales!) Que encontraron una manera de evitar eso.
Pero notará una cosa: el hecho de que sea difícil hacer la perfección no significa que no valga la pena, lo que dificulta la clonación de su dispositivo. En mi humilde experiencia, los clonadores suelen capitular tan pronto como necesite comprender cómo funciona un dispositivo para copiarlo; de lo contrario, estarán en la posición de tener ingenieros que podrían hacer su trabajo, más o menos, y esos ingenieros generalmente trabajan en su sector, no en un laboratorio de falsificaciones. Por lo tanto, una buena disuasión es poner el firmware encriptado en la memoria flash. No es perfecto, pero en el momento en que tengan que sacar el analizador lógico y dedicar semanas a la ingeniería inversa en el protocolo de descifrado de RAM, solo para obtener algo que podrían poder copiar, podría ser suficiente para que consideren el riesgo financiero demasiado alto y opten por otra cosa.
Comentarios
- " la gente sobreestima enormemente que ", pero la gente también sobreestima enormemente el costo de la ingeniería inversa.
- Gracias por la excelente respuesta, no puedo votar por no tener suficiente reputación. Sí, es ' básicamente imposible hacerlo 100% seguro, pero agregar una medida de seguridad muy simple con un chip criptográfico de $ 0.3 podría aumentar el costo de la ingeniería inversa de 3 cifras a $ quizás 5 cifras, mientras aumenta el tiempo requerido de unos días a unos meses si la seguridad está diseñada lo suficientemente inteligente. Y podría repeler a los piratas informáticos (según el potencial financiero del producto). Creo que seguiré adelante cifrando la " parte interesante " del firmware principal.
- Yo ' reduciré su estimación a " aumentando el tiempo de una hora a tal vez unos días ", y el costo es básicamente irrelevante en cualquier caso. El costo sería " esencialmente gratis " para cualquiera que ' tenga las herramientas electrónicas mintiendo de todos modos, e incluso si no, 200 € más una computadora portátil te dan un comienzo razonable.
- Entonces, ¿debería rendirme y no usar ninguna protección? 🙂
- @NotReallyaMaster que ' depende de usted; ' he dedicado todo el último párrafo de mi respuesta a esa pregunta.