Estoy usando un microprocesador: PIC32MZ2048efm144 MCU que recibe comandos cifrados con una clave específica , los descifra y ejecuta el comando. Los comandos cifrados se almacenan sin conexión , por lo que no puedo cambiar la clave siempre que quiera. La clave está FIJA . Los comandos son encriptados por un servidor y descargados por un teléfono . El teléfono envía los comandos encriptados a la MCU más adelante, cuando no está en línea . Los comandos se cifran antes de que el teléfono los comunique a la MCU, por lo que no es posible una clave de sesión.
Se me permite conectar un módulo externo de cifrado / descifrado al PIC, pero luego los datos pasarán descifrados en al menos una dirección.
La solución traída aquí: almacenar una clave segura en la memoria de un dispositivo incrustado
usa claves de un solo uso para encriptar, pero necesito almacenar una sola clave súper secreta
Lo que requiere mi empleador es que las claves no sean accesibles, por lo que no se considera la protección física además de la que ofrecen los módulos de memoria segura y la MCU.
Suponiendo que no se use equipo de grado militar, ¿hay alguna solución conocida que ustedes sepan y puedan recomendar?
¡Gracias por adelantado!
Respuestas:
Lamento que esta respuesta no resuelva tu problema. Pero es demasiado largo para caber en un comentario, y le permitirá repensar su problema de la manera correcta (porque, como es, creo que es defectuoso).
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:
Usted 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é temes que, potencialmente, algunos pases de datos descifrados entre la MCU y un módulo de cifrado / descifrado? Un pirata informático que tiene acceso al hardware para ver los comandos descifrados podría, de todos modos, actuar directamente sobre los GPIO de la MCU y "activar las cosas" con la misma facilidad.
Segundo ejemplo
Usar teclas a tiempo es una idea. Pero como usted dice, ¿dónde almacena la clave maestra principal utilizada para generar las claves de un solo uso? Te enfrentarás exactamente a las mismas preguntas que en tu problema original.
En realidad, no hay forma de hacer que su sistema sea seguro si supone que un pirata informático puede colarse en cualquier ubicación 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 hacker puede explorar las rutas internas dentro del IC, entre la memoria y el bloque de la CPU.
Una cerradura de puerta eléctrica se asegura porque no es razonable suponer que un hacker puede alcanzar los cables que activan la cerradura.
Etc ... Básicamente, debes comenzar por identificar las cosas que un hacker no podrá hacer, y resolver tu solución completa a partir de ahí. Por ejemplo, ¿es posible poner todo su sistema en una caja segura, físicamente resistente a la manipulación? En este caso, puede tener libremente comandos descifrados 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.
fuente
Este parece un caso clásico en el que el cifrado de clave asimétrica sería útil. En el cifrado de clave asimétrica 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 incorporado.
fuente
No explica por qué quiere cifrar los comandos (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 permite ejecutar comandos que se originan en su servidor?
Si es lo primero, enfrenta 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 el firmware descifre los comandos y luego capturarlos de la memoria.
Si, por otro lado, solo está tratando de asegurarse de que su dispositivo solo ejecutará comandos originados en su servidor, tiene suerte. En este caso, puede usar 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 puede usarse 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 abandonar su servidor. Aún mejor, cifre o firme los comandos en una máquina que no se comunica externamente y solo cópielos en el servidor para que la clave privada nunca se encuentre en un servidor accesible externamente.
fuente