almacenamiento y uso seguro de claves en un sistema integrado

Estoy usando un microprocesador: PIC32MZ2048efm144 MCU que recibe comandos encriptados con una clave específica , los descifra y ejecuta el comando. Los comandos encriptados se almacenan sin conexión , por lo que no puedo cambiar la clave cuando lo desee. La clave es FIJA . Los comandos son encriptados por un servidor y descargados por un teléfono . El teléfono envía los comandos cifrados a la MCU en un momento posterior, 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.

Puedo 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 presentada aquí: almacenar una clave segura en la memoria de un dispositivo integrado

usa claves de un solo uso para cifrar, pero necesito almacenar una única clave supersecreta

Lo que requiere Mi empleador es que las claves no sean accesibles, por lo que no se considera protección física además de la que ofrecen los módulos de memoria segura y la MCU.

Suponiendo que no se utilice ningún equipo de grado militar, ¿hay alguna solución que conozcan y puedan recomendar?

¡Gracias por adelantado!

¿Puedes explicar más sobre lo que estás tratando de prevenir? ¿Qué hace el microprocesador? ¿Crees que usar una clave pública/privada podría funcionar? ¿Si almacenó la clave privada en el microprocesador? Luego, los dispositivos que envían comandos crearían una clave de sesión, la cifrarían usando la clave pública y se la enviarían. Después de eso, ambos lados usan la clave de sesión. ¿Qué pasaría si un atacante tuviera la clave pública (que, aunque se llame "pública", en realidad no tiene que ser pública)?
@mkeith Actualicé la pregunta, espero que ayude :)
Ya que ha elegido ese PIC, ¿por qué no usar el "Almacenamiento de claves seguro mediante programación" que proporciona? ¡Tiene su propio módulo criptográfico incorporado!
No creo que hayas cuantificado claramente el valor de tu secreto. Parece que desea un método económico y confiable (que creo que es desconocido). Pida aclaraciones sobre lo que debe ser posible después de encontrar una vulnerabilidad en esta primera solución. Las actualizaciones de firmware inalámbricas firmadas serían mi primera característica no negociable... Siempre es un problema del sistema.
Bueno, si la memoria del PIC está protegida (e incluso tiene un módulo de almacenamiento de claves), ¿por qué no usar un cifrado AES simple? Sé que es simétrico, pero si el servidor es seguro (lo cual debemos asumir), entonces no hay riesgo aquí, ¿o sí?
@ pjc50 esta imagen no es compatible con "Almacenamiento de claves seguro mediante programación" :( solo el PIC24 hace eso ...
Si tiene un número finito de comandos cifrados con una clave estática, existe un tipo de ataque llamado ataque de repetición del que debería preocuparse. La idea es que el atacante vea el comando encriptado, observe el resultado, luego sepa lo que hace ese comando encriptado y pueda reproducirlo. Es posible que el atacante no lo descifre y que no tenga la clave, pero puede enviar el comando encriptado en cualquier momento que lo desee. Si el atacante no puede observar el comando encriptado, entonces no hay necesidad de encriptar en primer lugar.

Respuestas (3)

Lo siento, esta respuesta en realidad no resolverá su 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 hacker potencial puede o no puede hacer.

Por ejemplo:

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

Entonces, ¿por qué tiene miedo de 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, actuar directamente sobre los GPIO de la MCU y "accionar las cosas" con la misma facilidad.

Segundo ejemplo:

Usar claves puntuales es una idea. Pero como dices, ¿dónde almacenas la clave maestra principal utilizada para generar las claves únicas? 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 potencialmente en cualquier ubicación de su sistema (que es lo que me parece que está asumiendo actualmente).

Entonces, ¿qué hace que un sistema sea seguro?

Una tarjeta inteligente se asegura porque no es razonable suponer que un pirata informático puede sondear 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 pirata informático puede alcanzar los cables que activan la cerradura.

Etc... Básicamente, debe comenzar por identificar las cosas que un hacker no podrá hacer y, a partir de ahí, elaborar toda la solución. Por ejemplo, ¿es posible poner todo su sistema en una caja segura y físicamente resistente a la manipulación? En este caso, puede hacer que los comandos descifrados pasen libremente por un bus interno.

No se puede 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.

En primer lugar, ¡gracias por la respuesta elaborada! Actualicé la pregunta de una manera que creo que te responderá :)
Lo que entiendo de la edición de su publicación es que solo las claves deben protegerse. No es necesario proteger los resultados reales de los comandos . En este caso, coloque las claves en un módulo seguro externo como sugirió y acepte que los comandos descifrados se pueden ver en claro. Si mi sugerencia no es válida por alguna razón, tómese el tiempo para explicar en detalle qué es aceptable y qué no . No es solo una oración más en su publicación lo que necesitamos. Necesitamos la imagen completa de la cosa. En realidad.
Además, siento que el cifrado de los comandos no es realmente lo que quieres hacer. Por lo general, necesitamos cifrar datos (alguna información sobre algo, o un documento...). Pero rara vez necesitamos cifrar los comandos enviados a un dispositivo. Lo que generalmente se requiere en los comandos es firmarlos , para garantizar que provienen de la parte autorizada. Pero su contenido rara vez es sensible, en realidad. Así que deberías confirmar esto también.

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 integrado.

El descifrado de los datos se realiza con la clave privada (y el cifrado con la clave pública). De lo contrario, significa que todos pueden descifrar (ya que todos tienen acceso a la clave pública), lo que sería un problema. Por lo tanto, necesita que la clave privada esté en el dispositivo. Entonces, ahora, ¿cómo poner la clave privada en el dispositivo? Bueno, volviendo al problema inicial...
ser capaz de descifrar comandos no permite crear nuevos desde cero, por lo que tener la clave pública accesible de alguna manera no es un gran problema
Esto es generalmente lo mismo que la firma criptográfica; lo que tiene la desventaja de que si alguien tiene la clave pública (en realidad no tiene que ser pública, podría almacenarse de forma tan segura como la clave simétrica) puede descifrar todo; pero, como dice masterX244, generalmente no puede crear/firmar nuevos comandos. Creo que esta es una buena solución.

No explica por qué desea 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, se enfrenta a una tarea casi imposible: su dispositivo debe descifrar los comandos para poder 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á tratando de asegurarse de que su dispositivo solo ejecute comandos que se originen en su servidor, está de suerte. En este caso, puede utilizar el cifrado de clave pública (p. ej., RSA) o un esquema de firma digital de clave pública (p. ej., 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 usa 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 solo cópielos en el servidor para que la clave privada nunca se encuentre en un servidor accesible externamente.

almacenamiento y uso seguro de claves en un sistema integrado
RespuestasAquíPolítica de privacidad1y, 0v