Almacenamiento de una clave segura en la memoria de un dispositivo integrado

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. SIEMPRE deben generarse 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, tiene razón en esto. No importa si protege la EEPROM o la memoria flash para que no se lea. Ese fusible de protección de lectura de código se invierte fácilmente. Un atacante solo necesita destapar (quitar o grabar químicamente el empaque de epoxi negro para exponer el troquel de silicona en el interior). En este punto, pueden cubrir la parte del troquel que son células de memoria no volátiles (estas secciones son muy regulares y aunque las células de memoria individuales son demasiado pequeñas para ser vistas, la estructura más grande puede serlo) y una pequeña pieza de algo. opaco a los rayos UV está enmascarado sobre esa sección. Luego, el atacante puede hacer brillar una luz ultravioleta en el chip durante 5 a 10 minutos y restablecer 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 (digamos, obtener esas claves vale más de $ 1000 para alguien), pueden simplemente leer las celdas de memoria directamente con varios tipos de microscopios electrónicos.

Para estar seguras, las claves 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 use esa solución fácilmente disponible. El chip debe usar su RNG y se deben hacer varias otras consideraciones para garantizar que tenga un suministro suficiente de entropía disponible, y el cargador de arranque debe iniciarse directamente en el programa que genera la(s) clave(s) secreta(s) necesaria(s), que debe ser de uso general se registran y se mueven 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: utilice criptografía de clave pública. Lo que SÍ tiene almacenado en la memoria OTP es su clave pública. Cualquiera puede leer esta clave, puede publicarla en el intercambio de pilas, puede pintarla en el 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 usar para cifrar algo. Entonces, la CPU genera las claves secretas, usa su clave pública almacenada para CIFRAR las claves secretas y simplemente las envía a través de USB o RS232 o lo que desee. Leer la clave secreta requiere su clave privada, que no necesitan ser almacenados, enviados o involucrados en absoluto 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 en absoluto para que no se pueda leer.

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' claves 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 ubican en la fuente de alimentación y miden cambios mínimos en el consumo de corriente y el tiempo entre esos cambios causados ​​por cambios de bits en la CPU. como registros. Esto, combinado con el conocimiento de cómo funciona AES (o cualquiera que sea el conjunto muy pequeño de posibles algoritmos de encriptación 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 claves posibles. El chip tampoco puede detectarlo, ya que está aguas arriba.

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 existen verdaderas contramedidas de hardware para este ataque. Sin embargo, son los algoritmos de encriptación en sí mismos, y cómo requieren una CPU para voltear bits, lo que está causando esta vulnerabilidad. Sospecho que será necesario (y con suerte se están) desarrollando algoritmos resistentes al canal lateral oa prueba del canal lateral.

Entonces, tal como está ahora, la respuesta real a cómo almacenar una clave (o incluso usar una clave temporal) en un dispositivo integrado 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 energía mientras cifra los datos. . Si negocia con frecuencia nuevas claves generadas internamente, esto puede proporcionar cantidades útiles de seguridad.

Genere claves y guárdelas durante el menor tiempo posible.