¿Es una mala práctica mantener certificados en la memoria externa?

Estamos trabajando en AWS-IoT utilizando un microcontrolador STM32.

Hasta hoy, estábamos escribiendo los certificados en el flash y bloqueando el flash de la lectura externa. A medida que aumenta el código de la aplicación, estamos obteniendo menos espacio en la memoria flash, por lo que planeamos mover el certificado externamente a una tarjeta SD / EEPROM y leerlo cuando sea necesario antes de conectarnos a AWS-IoT.

Notas:

• La política escrita para la cosa permitirá que solo los dispositivos con nombres particulares se conecten en ese certificado en particular.

• Se permite publicar en solo 2 canales (su nombre y un canal de alimentación de datos) que está conectado a un procesador de datos que ignorará cualquier paquete falso que llegue a él.

• Si la cosa publica / se suscribe a cualquier otro tema, AWS la desconectará de inmediato.

Si detecto que un dispositivo es robado / no autorizado, desactivamos la clave del servidor.

¿Qué puede hacer un explotador con los certificados (RootCA, clave del servidor, clave del cliente)?

¿Es una mala práctica mantener certificados para tal caso de uso en un almacenamiento externo al que pueda acceder un explotador?

Menciona "certificados", pero por contexto, creo que se refiere a dos cosas diferentes.

• Su dispositivo tiene una clave privada , que es exclusiva de este dispositivo y no se conoce fuera del dispositivo. Esta clave identifica su dispositivo. Cualquiera que pueda acceder a esa clave puede hacerse pasar por el dispositivo. Eso significa que pueden, en particular:

  • Publique datos válidos pero incorrectos en los canales a los que su dispositivo está legítimamente autorizado para publicar.
  • Publique datos no válidos que prohibirán el dispositivo legítimo.
  • Posiblemente, dependiendo del caso de uso, exponga alguna información privada del propietario del dispositivo.

  Es mejor que esta clave privada permanezca confidencial.

• Es probable que su dispositivo tenga al menos una clave pública , que le permite reconocer a qué servidores está hablando. Está bien si alguien puede leer esta clave: es pública. Pero un atacante no debería poder modificar la clave. De lo contrario, podrían comunicarse con el dispositivo y hacerse pasar por el servidor. Esto podría permitirles hacer cosas como:

  • Empuje una actualización de firmware al dispositivo.
  • Empuje una actualización de configuración al dispositivo.
  • Haga que el dispositivo cargue sus datos en una ubicación diferente.

La buena noticia es que este análisis de amenazas en realidad no es muy relevante. ¡No necesitas sacrificar ninguna seguridad ! (Al menos no propiedades de confidencialidad y autenticidad: si almacena cosas externamente, entonces la disponibilidad se ve afectada, porque esa es una parte del sistema que podría faltar).

Siempre que tenga al menos 128 bits de almacenamiento en los que pueda escribir al menos una vez, lo que tiene y más, puede implementar una solución segura de almacenamiento remoto. Use el almacenamiento en el dispositivo de espacio limitado para almacenar una clave secreta. Esta clave secreta debe ser única por dispositivo; El STM32 tiene un RNG de hardware, por lo que puede generarlo en el dispositivo durante el primer arranque. Si su dispositivo no tenía un RNG de hardware, podría generar la clave en una ubicación segura fuera del dispositivo e inyectarla en el dispositivo.

Con esta clave, use encriptación autenticada para las cosas que almacena fuera del dispositivo. Cuando desee leer algunos datos del almacenamiento externo, cárguelos, descifre y verifique. Cuando desee escribir algunos datos en un almacenamiento externo, cifre y firme. Esto garantiza que los datos sean tan confidenciales y auténticos como los datos en el almacenamiento interno.

El cifrado autenticado es suficiente para garantizar la confidencialidad y autenticidad de los datos, pero no garantiza su integridad .

• Si hay más de una porción de datos, cuando el dispositivo vuelve a leer una porción de datos, no puede estar seguro de que esta sea la porción correcta. Solución: incluye un identificador único en el contenido de cada bloque (por ejemplo, comenzar cada trozo con una de "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Si actualiza los datos en algún momento, cuando los vuelve a leer, no puede estar seguro de que está obteniendo la última versión de esos datos. Si alguien puede modificar el almacenamiento externo, no puede poner datos falsos porque eso podría fallar la verificación de autenticidad, pero puede restaurar datos antiguos, porque lo que solía ser auténtico sigue siendo auténtico. Solución: en cada fragmento de datos que se almacena externamente, incluya un contador que incremente cada vez que escriba una nueva versión de ese fragmento. Cuando leas un fragmento, verifica que sea la versión esperada.

Para evitar bloquear un dispositivo en caso de que el almacenamiento externo se dañe o se pierda, en el espacio limitado que tiene espacio en el almacenamiento interno, debe dar prioridad a lo que sea necesario para restablecer el dispositivo a un estado "bueno", por ejemplo, un restablecimiento de fábrica . La segunda prioridad serán las consideraciones de rendimiento.

Un poco de contexto

Como está usando MQTT con AWS IoT, se espera que use certificados X.509 para autenticación y seguridad. Amazon tiene un poco de orientación sobre cómo debe proteger sus certificados, así que lo citaré aquí:

Los certificados permiten utilizar claves asimétricas con dispositivos. Esto significa que puede grabar claves privadas en un almacenamiento seguro en un dispositivo sin permitir que el material criptográfico sensible abandone el dispositivo.

Como actualmente está utilizando la Protección de lectura (RDP) de STM32 , todos los atacantes menos los más determinados tendrán problemas para acceder a sus certificados en su esquema actual:

La protección de lectura global permite que el código de firmware incorporado (precargado en la memoria Flash) proteja contra la ingeniería inversa, el volcado mediante herramientas de depuración u otros medios de ataque intrusivo.

• Nivel 0: sin protección (predeterminado)
• Nivel 1: la memoria flash está protegida contra la lectura mediante depuración o descarga de código mediante el código cargado de RAM
• Nivel 2: todas las funciones de depuración están deshabilitadas

¿El almacenamiento externo va a ser seguro?

Probablemente no sea tan seguro . Si se roba la clave privada de su cliente, un atacante puede enviar datos que parecen ser de su dispositivo, cuando en realidad no lo es. Aunque no está claro qué datos está enviando, cualquier dato no confiable puede ser un riesgo de seguridad.

¿Qué partes necesito para mantener en privado?

Cuando cree un certificado de dispositivo en AWS IoT, debería ver una imagen como esta:

^{Imagen de la página Crear y activar un certificado de dispositivo de la documentación de AWS IoT.}

La clave privada es lo que realmente necesita mantener ... privada , y definitivamente debe almacenarse en la memoria protegida contra lectura si es posible. La clave pública y el certificado están diseñados para ser compartidos, por lo que si se está quedando sin espacio, puede moverlos de forma segura a un almacenamiento externo. Puede obtener un poco más de contexto en la página ¿Cómo funciona SSL / TLS? en Information Security Stack Exchange y criptografía de clave pública en Wikipedia. Creo que te estaría perjudicando si no incluyera esta imagen para explicar por qué la clave privada debe ser secreta:

.

^{Imagen de Wikipedia , lanzada al dominio público.}

La clave pública de su dispositivo es lo que AWS IoT usa para firmar mensajes para enviar a su dispositivo (pero no prueba quién está enviando el mensaje ). Entonces, realmente, no es un gran desastre si alguien roba la clave pública, porque no debe ser un secreto.

La clave privada es lo que usa su dispositivo para descifrar mensajes, por lo que es un problema un poco mayor si un atacante roba esto.

También preguntó qué pasaría si el atacante robara el certificado RootCA. Si alguien robara la clave privada de AWS IoT , sería desastroso, pero el certificado RootCA en su dispositivo no lo es . Lo RootCA.crtque Amazon le brinda es completamente público , y el propósito es que pueda verificar que no está siendo atacado de ninguna manera (lo más probable es que sea un intermediario que finja ser servidores de AWS IoT).

¿Qué daño podría hacer un dispositivo pirateado?

Su dispositivo robado solo puede realizar las acciones enumeradas en la política . Trate de seguir el principio del menor privilegio ; solo conceda a su dispositivo los privilegios que necesita absolutamente , por lo que si sucede lo peor, no puede causar demasiados estragos. Para su caso específico:

Se permite publicar en solo 2 canales (su nombre y un canal de alimentación de datos) que está conectado a un procesador de datos que ignorará cualquier paquete falso que llegue a él.

Eso es bueno. Cualquier ataque debe aislarse solo en los dos temas MQTT en los que el dispositivo puede publicar, para que no cause daños a gran escala.

Idealmente, desea que su sistema general tenga un diseño tal que al diseccionar una sola unidad se rompa solo esa unidad, y no el sistema en general.

Especialmente si está almacenando claves en una memoria distinta de modo que crucen una interfaz eléctrica estándar entre chips, entonces solo deberían ser claves que ya sean seguras para publicar, o exclusivas de esa instancia física particular del dispositivo.

Si se extrae una clave individual de un solo dispositivo y comienza a ser abusada o aparece en un volumen de tráfico que debe provenir de múltiples clones no autorizados, entonces puede prohibir esa clave en el lado del servidor.

Por supuesto, sus claves deben tener la propiedad de no ser algo que una parte no autorizada pueda adivinar a partir de algunos ejemplos extraídos o generar sus propias instancias compatibles originales, es decir, necesita un registro de las claves que ha generado donde están las válidas. solo una parte pequeña e impredecible de un enorme espacio de posibilidades, de lo contrario, debe firmar las claves que genera y hacer que su sistema solo acepte una clave en combinación con su prueba de firma.

Debe intentar mantener el secreto de la clave del cliente (pero comprenda la implicación de perderlo (1), como se describe en las otras respuestas). La clave pública del servidor y el certificado público de AWS son importantes para asegurar en el extremo del dispositivo no porque desee mantenerlos en secreto, sino porque al reemplazar el certificado de AWS (en un dispositivo comprometido) un atacante puede persuadir al dispositivo para que realice un intercambie con el host del atacante o comunique sus comunicaciones con AWS.

Al hacer esto (2), un atacante puede eliminar la seguridad de TLS, lo que puede resultar en una reducción suficiente de la seguridad que puede aplicar ingeniería inversa a la clave del cliente.

Según este razonamiento, la única clave que es segura exponer en un dispositivo de memoria externo es la clave pública del servidor. Cambiar esto (3) solo permitiría que su dispositivo se vea obligado a conectarse a un servicio de AWS falso al que probablemente sea difícil acceder por ingeniería. Incluso filtrar solo esta clave podría permitir a alguien espiar o falsificar algunas transmisiones (por ejemplo, si la capa TLS se puede degradar de alguna manera).

En resumen, el riesgo no es simplemente la pérdida de información, existe el riesgo de que el firmware (supuestamente confiable) pueda recibir información segura no confiable.