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

11

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?

usuario2967920
fuente
¿Estaba utilizando el nivel 2 de protección contra lectura (el permanente) o el nivel 1 para que el flash fuera de solo lectura?
Aurora0001
¿Qué quiere decir exactamente con "certificados"? ¿Se refiere al certificado público (p. Ej., Clave pública y firma de una raíz confiable)? ¿O te refieres a las claves privadas correspondientes? Normalmente se entiende que los certificados significan lo primero, pero su comentario sobre "clave de servidor, clave de cliente" y su pregunta me hacen pensar que es mejor que verifiquemos lo que quiere decir.
DW
¿Qué dispositivo flash estás usando? La mayoría de la prevención de lectura se puede desactivar a través de la interfaz spi con un registro en el flash. El propósito de la prevención de lectura es evitar que el software en la CPU acceda a él, pero cualquier persona con acceso físico al flash puede desactivarlo.
Mariscal artesanal
Ah, sí, el flash incorporado para el chip de brazo, ignore mi declaración anterior, que era para spi flash ic o flash externo.
Mariscal artesanal

Respuestas:

7

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.

Gilles 'SO- deja de ser malvado'
fuente
10

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:

AWS IoT

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:

Criptografía de clave pública.

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.

Aurora0001
fuente
9

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.

Chris Stratton
fuente
Gracias por sus notas, la forma en que la hemos planificado en el extremo receptor del agente MQTT es 1. Si publica en otro canal para el que no está autorizado o 2. Si publica datos falsos en el canal adecuado en desigual o 3 Sabemos que el dispositivo está secuestrado (cuando se abre el dispositivo: sensores de efecto hall). El conjunto de claves en AWS-IoT se destruye, lo que hace que ese conjunto de claves sea inútil. Entonces, si piratea un dispositivo / obtiene la clave de un dispositivo, no podrá hacer mucho, ya que las políticas son muy estrictas para los temas que puede usar el dispositivo (está limitado a 2) y qué datos pasa a través de ellos.
user2967920
5

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.

Sean Houlihane
fuente
1
Punto interesante, pero en cuanto a lo último, un atacante que cambie la clave pública del servidor en un dispositivo en su posesión probablemente le permitiría conectarse a través de un proxy impostor que tenga la coincidencia privada de la clave de reemplazo instalada en su lado descendente, ese proxy luego podría reenviar el tráfico al servidor real de forma transparente mientras lo graba todo en el punto de transferencia entre las sesiones criptográficas legítimas e impostoras. Esto ni siquiera sería tecnología original; tales cajas se venden a instalaciones que requieren dispositivos en su red para confiar en sus certificados impostores.
Chris Stratton
Creo que estás describiendo mi segundo punto aquí. ¿No se utiliza esta tercera clave debajo del protocolo TLS para cifrar aún más los datos transmitidos a través del enlace de confianza?
Sean Houlihane
Normalmente, el ataque "confiar en el certificado de impostor de nuestro proxy" se usa para romper TLS, pero podría usarse básicamente en cualquier cosa en la que pueda obtener / reemplazar suficiente información para suplantar cada punto final al otro.
Chris Stratton
¿Qué le hace pensar que reemplazar la clave pública le permitirá a alguien aplicar ingeniería inversa a la clave privada del cliente? Así no es como funciona TLS. La criptografía de clave pública no funciona de esa manera. Puede habilitar ataques man-in-the-middle, pero no permite que el atacante man-in-the-middle extraiga la clave privada del cliente.
DW