Cifrado AES en un dispositivo integrado: ¿puede ser seguro?

Question

Cifrado AES en un dispositivo integrado: ¿puede ser seguro?

Navega tus respuestas

#1 de Steve Sether (3 votos)
#2 de Ben Voigt (2 votos)

10

Planeo crear un programa de cifrado para un dispositivo integrado con las siguientes características:

La CPU es compatible con Intel 80186 @ ~ 20 MHz
128 KB de RAM, de los cuales tengo ~ 20 KB a mi disposición para fines de cifrado
el tamaño binario de la aplicación está limitado a 128 KB, pero me gustaría mantener la parte de cifrado < 16 KB
almacenamiento persistente en la memoria Flash

Estos son los requisitos:

cifrar archivos de texto pequeños y mapas de bits < 32 KB
Siempre puedo descifrar todo el archivo a la memoria RAM, es decir, no necesito acceso aleatorio
los archivos encriptados no están "bloqueados" por el hardware, es decir, se pueden transferir a una PC en cualquier momento, por lo que quiero protegerme contra alguien que roba el dispositivo e intenta descifrar los datos
No me preocupan las vulnerabilidades de software, los registradores de teclado, etc. (suponga que nunca le presto el dispositivo a nadie y lo guardo debajo de mi almohada por la noche) y también asumo que la NSA no ingresa a mi casa para cloroformarme e instalar un exploit dirigido)

Estoy lejos de ser un experto en criptografía, pero pasé un tiempo leyendo Wikipedia en AES, bloqueando modos de cifrado y algoritmos de derivación de claves, y también leí " Si está escribiendo las letras AES en su código, lo está haciendo mal ". Todo esto me ha hecho dudar de si puedo tener éxito debido a las limitaciones del hardware y mi conocimiento superficial del tema, pero lo intentaré.

Los siguientes pasos alinean lo que planeo hacer:

Planeo seguir el procedimiento básico que se describe en en esta respuesta , es decir: encriptación con AES en modo CBC, Derivación clave con PBKDF2, sal aleatoria, IV aleatoria.
Como preferiría AES-256 en lugar de AES-128, usaría PBKDF2 con SHA-512 para poder obtener una clave de doble longitud.
No hay una fuente confiable de números aleatorios en el dispositivo integrado, por lo que mi plan es que el usuario genere la clave aleatoria (k1) en una PC y la transfiera (probablemente al escribirla manualmente). Esto no debería ser un problema porque solo ocurre una vez, es decir, uso la misma clave (k1) para cifrar cualquier número de archivos.
El juego / ensayo "Si estás escribiendo las letras AES en tu código, lo estás haciendo mal" señala los peligros de un atacante que tiene control sobre el proceso de encriptación, es decir, que puede suministrar texto simple arbitrario y tiene está encriptado, porque esto permite todo tipo de ataques de canal lateral como "error oracle". ¿Tengo razón al suponer que esto no es un problema para mí porque el atacante solo puede ver mis archivos cifrados?
Entiendo que debo generar un IV y sal aleatorios para cada cifrado individual para evitar resultados idénticos para texto sin formato idéntico. Pero, ¿la IV y la sal tienen que ser criptográficamente fuertes números aleatorios? Lo mejor que puedo hacer sería un Mersenne Twister (o preferiblemente algo más eficiente) sembrado con hash (concat (tiempo, voltaje de batería)); ¿Pero es esto necesario en absoluto? De todos modos, almaceno IV y sal en texto simple, así que solo debo asegurarme de que sean diferentes cada vez, no de preocuparme por su capacidad de predicción.
Planeo usar esta implementación o una de las implementaciones vinculadas aquí , por supuesto, después de verificarlas con los vectores de prueba NIST. ¿Hay algo más que deba verificar al elegir una implementación?

Estaré agradecido por los comentarios que me dicen qué partes están mal, no están seguras o deberían mejorarse. Además, si hay una implementación AES-256 confiable para Intel 80186, me encantaría saberlo. Y, por último, si crees que es inútil, no dudes en decírmelo.

random aes embedded-system

pregunta Moritz Beutel 08.02.2015 - 12:15

fuente

2 respuestas

Lea otras preguntas en las etiquetas random aes embedded-system

¿Cómo manejar los correos electrónicos como nombres de usuario bajo GDPR? ¿Cuáles son las formas de implementar la autenticación de dos factores?

score 3 · Answer 1

No especificas un caso de uso para esto, por lo que es difícil entender las limitaciones, y si esto es "seguro".

No mencionó el uso de un HMAC, pero supongo que está al tanto de la necesidad de uno bajo ciertas aplicaciones.

Desea utilizar AES-256 sobre AES-128, pero no especifique por qué. AES-256 requiere 14 rondas, frente a solo 10 para AES-128, por lo que AES-128 es considerablemente más rápido, lo que puede ser significativo en el entorno muy limitado con el que está tratando (palabras de 16 bits, por ejemplo). AES-128 ya es extremadamente seguro, y hay poca o ninguna seguridad adicional ofrecida por un espacio de teclas más grande, especialmente si está utilizando contraseñas escritas por el usuario que casi nunca tienen una entropía de 128 bits.

IV no necesita ser impredecible (la IV debe ser conocida por cualquier atacante). Lo único importante de una IV es que no se reutiliza. Personalmente utilizaría un valor aleatorio aleatorio cada vez que se encripta un archivo nuevo, y los resultados guardan el hash aleatorio. La próxima IV siempre será predecible, pero dada la entropía inicial suficiente nunca se reutilizará, ni siquiera globalmente en todos los dispositivos.

score 2 · Answer 2

La seguridad de este esquema depende exactamente de lo que el atacante pueda leer. Recuerde que el dispositivo incorporado está realizando descifrado, por lo que claramente tiene todas las partes necesarias para hacerlo (datos cifrados, clave y algoritmo)

Si el atacante tiene algún tipo de conexión de depuración con el sistema (por ejemplo, JTAG) - Game Over (inmediatamente y sin esfuerzo). El atacante simplemente puede leer el contenido descifrado de la RAM.
Si él puede leer solo tus archivos de datos, y tu clave AES es una de ellas: Game Over.
Si puede leer solo sus archivos de datos, y su clave AES está incrustada en el código en una memoria separada: Ok (quizás).
Si puede leer tanto los archivos de datos como la memoria de códigos y la clave AES se almacena en el código: Game Over. El atacante ni siquiera necesita aplicar ingeniería inversa a la clave, solo puede ejecutar el código y dejar que descargue el contenido descifrado en la memoria. Encontrar entornos virtuales capaces de ejecutar código x86 es trivial.
Si puede leer tanto los archivos de datos como la memoria de código, pero el código extrae la clave AES de una memoria segura en el troquel diseñada explícitamente para la protección de la clave a prueba de manipulaciones. Debería estar bien. A menos que el atacante pueda hacer que el microcontrolador ejecute el código modificado y copie los datos descifrados de la memoria del microcontrolador.
Si él puede leer archivos de datos, y la clave AES se almacena en una memoria segura, pero esa memoria no está en la matriz, no es buena. El atacante puede robar la clave mientras se transmite entre el almacenamiento seguro y el núcleo del procesador. Más difícil que los ataques de solo software, pero aún inseguros.

Básicamente, la protección del código y los datos fuera del chip requiere un chip diseñado con fusibles para quemar la interfaz de depuración, el código almacenado en el chip con todos los accesos externos denegados por esos mismos fusibles, datos cifrados y una clave a prueba de manipulaciones a bordo. almacenamiento. Es muy poco probable que un chip de la era 80186 tenga estas características (especialmente la última), aunque se basa en el tamaño de la memoria y la velocidad del reloj, este es un clon moderno de 80186 que podría.