Almacenar una clave segura en la memoria de un dispositivo incrustado

Estoy trabajando en un dispositivo integrado que envía / recibe datos y los almacena en modo de texto cifrado (modo cifrado). ¿Cuál es el mejor enfoque para almacenar claves (utilicé la MCU de la serie ARM CORTEX M)?

1-Almacenamiento de claves en la memoria SRAM y en cada secuencia de arranque, inyecte claves en la MCU incorporada y almacénelas en la memoria SRAM. Creo que es la mejor manera, entonces cuando MCU detecta la penetración (con sensor de manipulación o ...) puede borrar la SRAM rápidamente y reiniciarse. Desventaja: si el atacante logra pasar manipulaciones y acceder al dispositivo, qué tan segura es la memoria SRAM (contra la minería de código). No puedo encontrar ninguna capacidad de seguridad para esta memoria en MCU.

2-Genera claves y las almacena en la memoria flash en la programación de MCU. La memoria flash MCU admite CRP (protección de lectura de código) que evita la extracción de código y con la ayuda de su motor interno AES y motor RNG (generación de números aleatorios) podemos hacer una clave aleatoria y cifrar la memoria flash y almacenar esa clave aleatoria en el OTP ( memoria programable de una sola vez -una memoria cifrada de 128 bits), luego en la ejecución del código decodificamos la memoria flash con la clave RNG y accedemos a la clave y los códigos iniciales. Desventaja: las claves almacenadas en una memoria no volátil, las manipulaciones serán inútiles y el atacante tendrá mucho tiempo para extraer las claves.

Clave 3-almacenada en la memoria EEPROM, combinación de 2 enfoques anteriores, clave almacenada en la memoria no volátil, pero cuando la manipulación detecta la penetración, la EEPROM es borrable.

Considero LPC18S57FBD208 (cortex m3 con 1 MB de memoria flash, 180MHZ, 136KB SRAM, 16KB EEPROM y un controlador TFT LCD que necesito para manejar un 7 "TFT LCD y un motor criptográfico AES de 128 bits) para eso hay alguna otra sugerencia mejor?

Ninguna de esas opciones es particularmente mejor o peor que las demás, porque todas son muy inseguras. Voy con la opción 4.

1. SRAM es el lugar más seguro para almacenar claves, pero nunca debe inyectarlas desde el mundo exterior. Deben generarse SIEMPRE dentro del procesador, durante el arranque. Hacer cualquier otra cosa invalida instantáneamente el resto, es automáticamente inseguro.

2. No almacene claves en la memoria no volátil, está en lo correcto. No importa si protege la EEPROM o la memoria flash contra la lectura. El fusible de protección de lectura de código se invierte fácilmente. Un atacante solo necesita decapitar (eliminar o grabar químicamente el embalaje de epoxi negro para exponer el troquel de silicio en el interior). En este punto, pueden cubrir la parte del dado que son celdas de memoria no volátiles (estas secciones son muy regulares y aunque las celdas de memoria individuales son demasiado pequeñas para verse, la estructura más grande puede ser) y una pequeña pieza de algo opaco a UV está enmascarado sobre esa sección. Luego, el atacante puede encender una luz ultravioleta en el chip durante 5-10 minutos y reiniciar todos los fusibles, incluido el fusible CRP. La memoria OTP ahora puede ser leída por cualquier programador estándar.

O, si están bien financiados (por ejemplo, obtener esas llaves valen más de $ 1000 para alguien), simplemente pueden leer las celdas de memoria directamente con varios tipos de microscopios electrónicos.

Para estar seguro, las llaves deben borrarse, no ocultarse.

3. No, por las mismas razones anteriores.

Ahora, a la opción 4:

4. Solo usa encriptación. La distribución de claves es un problema resuelto. Así que usa esa solución fácilmente disponible. El chip debe usar su RNG y deben hacerse varias otras consideraciones para garantizar que tenga un suministro suficiente de entropía disponible, y el gestor de arranque debe arrancar directamente en el programa que genera la (s) clave (s) secreta (s) necesaria (s), que deben ser de uso general se registra y se traslada directamente a SRAM, donde permanecerán hasta que se borren.

Sin embargo, hay un problema, que es que nada, excepto la CPU, tiene idea de cuál es la clave secreta. No hay problema: use la criptografía de clave pública. Lo que SI has almacenado en la memoria OTP es tu clave pública. Cualquiera puede leer esta clave, puede publicarla en el intercambio de pila, puede pintarla al costado de un petrolero en letras de 5 pies de alto, no importa. Lo maravilloso de la criptografía de clave pública es que es asimétrica. La clave para cifrar algo no puede descifrarlo, eso requiere la clave privada. Y a la inversa, la clave para descifrar algo cifrado por la clave pública no se puede utilizar para cifrar algo. Por lo tanto, la CPU genera las claves secretas, utiliza su clave pública almacenada para ENCRITAR las claves secretas y simplemente la envía por USB o RS232 o lo que desee. Leer la clave secreta requiere tu clave privada, que no necesitan ser almacenados, enviados o involucrados con el chip. Una vez que haya descifrado la clave secreta con su clave privada (en otro lugar, fuera del chip), estará listo. Tiene una clave secreta transmitida de forma segura que se GENERÓ completamente dentro del chip, sin tener que almacenar nada excepto una clave pública, que, como se indicó anteriormente, no necesita estar protegida para que no se lea.

Este proceso se denomina formalmente negociación clave, y todo lo utiliza. Lo has usado varias veces hoy. Hay muchos recursos y bibliotecas disponibles para manejarlo. Por favor, nunca 'inyecte' llaves en nada.

Una última cosa para mencionar: todo esto es discutible porque la clave AES se puede recuperar fácilmente mediante ataques de canal lateral, que se encuentran en la fuente de alimentación y miden cambios diminutos en el consumo de corriente y el tiempo entre esos cambios causados ​​por los bits volteando en la CPU como registros. Esto, combinado con el conocimiento de cómo funciona AES (o cualquiera de los muy pequeños conjuntos de algoritmos de cifrado posibles que podrían usarse), hace que sea relativamente fácil y económico recuperar la clave. No permitirá leer la clave, pero puede reducir el espacio de la clave a algo ridículamente pequeño, como 255 posibles claves. El chip tampoco puede detectarlo, ya que está en sentido ascendente.

Esto ha derrotado a los cargadores de arranque cifrados AES-256 en procesadores criptográficos 'seguros' y ni siquiera es tan difícil. Hasta donde yo sé, no hay verdaderas contramedidas de hardware para este ataque. Sin embargo, son los algoritmos de cifrado en sí mismos y la forma en que requieren una CPU para voltear bits, lo que está causando esta vulnerabilidad. Sospecho que los algoritmos resistentes a los canales laterales o a prueba de los canales laterales deberán desarrollarse (y con suerte).

Entonces, tal como está ahora, la verdadera respuesta sobre cómo almacenar una clave (o incluso usar una clave temporal) en un dispositivo incrustado de forma segura es: no puede.

Pero al menos si genera una nueva clave cada vez que usa la negociación de claves en la opción 4, entonces un ataque de canal lateral solo puede comprometer la clave de un canal en uso, y solo si tienen un tiempo para monitorear la potencia mientras encripta los datos . Si con frecuencia negocia nuevas claves generadas internamente, esto puede proporcionarle cantidades útiles de seguridad.

Genere claves y almacénelas durante el menor tiempo posible.