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?
Respuestas:
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:
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:
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 .
"AWS-IoT private key."
,"configuration CA certificate."
,"publishing server CA certificate."
,"user personal data."
, ...).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.
fuente
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í:
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:
¿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.crt
que 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:
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.
fuente
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.
fuente
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.
fuente