almacenar y usar claves de forma segura en un sistema integrado

Lo siento, esta respuesta no resolverá tu problema. Pero es demasiado largo para caber en un comentario, y le permitirá repensar su problema de la manera correcta (porque tal como está, creo que tiene fallas).

Este tipo de problemas deben resolverse teniendo en cuenta todos los componentes del sistema y haciendo suposiciones razonables sobre lo que un pirata informático potencial puede o no puede hacer.

Por ejemplo:

Dice: "el PIC32MZ2048efm144 (MCU) recibe comandos cifrados con una clave específica, los descifra y ejecuta el comando". Supongo que el resultado de la ejecución del comando es alternar algunos GPIO para activar cosas.

Entonces, ¿por qué teme que, potencialmente, algunos datos pasen descifrados entre la MCU y un módulo de cifrado / descifrado? Un pirata informático que tenga acceso al hardware para ver los comandos descifrados podría, de todos modos, ser capaz de actuar directamente sobre los GPIO de la MCU y "activar las cosas" con la misma facilidad.

Segundo ejemplo:

Usar las teclas de tiempo es una idea. Pero, como usted dice, ¿dónde guarda la llave maestra principal utilizada para generar las teclas de un solo uso? Enfrentarás exactamente las mismas preguntas que en tu problema original.

En realidad, no hay forma de proteger su sistema si cree que un pirata informático puede colarse en cualquier lugar de su sistema (que es lo que me parece que está asumiendo actualmente) ).

¿Qué hace que un sistema sea seguro, entonces?

Una tarjeta inteligente se hace segura porque no es razonable suponer que un pirata informático puede probar las rutas internas dentro del IC, entre la memoria y el bloque de la CPU.

Un bloqueo de puerta eléctrico se hace seguro porque no es razonable suponer que un pirata informático puede alcanzar los cables que activan el bloqueo.

Etc ... Básicamente, tienes que comenzar por identificar las cosas que un pirata informático no podrá hacer, y resolver tu solución completa desde allí. Por ejemplo, ¿es posible colocar todo su sistema en una caja segura y resistente a las manipulaciones físicas? En este caso, puede haber descifrado libremente los comandos que pasan a través de un bus interno.

No puedes construir un sistema seguro sin saber qué es lo que el hacker no puede hacer razonablemente. No nos dijiste eso. Por lo tanto, no podemos proponer una solución completa.

Esto parece un caso clásico donde el cifrado de clave asimétrico sería útil. En el cifrado de clave asimétrico tiene dos claves, una privada y una pública. Desea proteger completamente la clave privada, pero la clave pública puede hacerse pública y no necesita protección. es posible que pueda mantener la clave privada en el sistema seguro y la clave pública en el dispositivo integrado.

No explica por qué quiere que los comandos estén encriptados (en otras palabras, cuál es su modelo de amenaza). ¿Su propósito es evitar que un adversario en posesión del dispositivo basado en PIC determine cuáles son los comandos que se le envían? ¿O está tratando de evitar que el dispositivo basado en PIC ejecute un conjunto de comandos sustituidos por un adversario y solo le permita ejecutar comandos que se originan en su servidor?

Si es el primero, se enfrenta a una tarea casi imposible: su dispositivo debe descifrar los comandos para ejecutarlos: la posesión del dispositivo PIC significa la posesión de la clave de descifrado. Un adversario puede extraer la clave (almacenada en el dispositivo PIC que posee) o simplemente esperar hasta que su firmware descifre los comandos y luego capturarlos de la memoria.

Si, por otro lado, solo estás tratando de asegurarte de que tu dispositivo solo ejecutará comandos que se originan en tu servidor, estás de suerte. En este caso, puede utilizar el cifrado de clave pública (por ejemplo, RSA) o un esquema de firma digital de clave pública (por ejemplo, DSS). En estos, su dispositivo solo almacena la clave pública: esto es suficiente para descifrar los comandos (o verificar la firma digital), pero no se puede usar para cifrar comandos (o generar una firma digital) que el dispositivo aceptará. Eso requiere la clave privada, que utiliza para cifrar (o firmar) los comandos antes de enviarlos. La clave privada nunca necesita salir de su servidor. Aún mejor, cifre o firme los comandos en una máquina que no se comunica externamente y cópielos solo en el servidor para que la clave privada nunca se encuentre en un servidor accesible externamente.