Uso de AES para la seguridad de IoT

El principal problema que veo con este esquema es lo que se llama el Problema de distribución de claves : ¿cómo se entrega de forma segura password_b al dispositivo?

En el paso 2, el usuario ingresa password_b en un formulario web. Presumiblemente, en el paso 5%, password_b se envía al dispositivo a través de una conexión websocket no segura. A partir de ese momento, el dispositivo cifra todos los datos de websocket utilizando AES con una clave derivada de password_b .

Mi problema es con el paso 5: si se envía en texto sin formato, entonces un atacante en la misma red que el dispositivo podría sacar la contraseña del paquete. Incluso si utiliza una conexión TLS autenticada por el servidor estándar, el servidor no tendría manera de probar con qué dispositivo está hablando y un atacante podría conectarse y decir que es el dispositivo y hacer que el servidor lo envíe password_b .

Mi sugerencia es que si puedes permitirte ejecutar una biblioteca TLS, entonces dale a cada dispositivo un cliente certeficite durante la fabricación y haga que el servidor mantenga una tabla de qué clave pública pertenece a qué número de serie del dispositivo. De esta manera, cuando un dispositivo se conecta al servidor a través de TLS, el servidor sabe con qué dispositivo se está comunicando solo desde la clave / firma pública.

Por lo general, usaría un conjunto de cifrado SSL / TLS que envuelve AES, en lugar de inventar su propio protocolo porque, como sugiere @Rook, hay muchas formas de dispararse a sí mismo. Entiendo que algunos dispositivos de bajo consumo pueden hacer AES pero no tienen la huella de memoria para una biblioteca TLS completa. Bien, pero tendrás que convertirte en un experto en criptografía, o contratar a uno, para asegurarte de que lo estás haciendo bien porque te estás yendo por ahí.

Esta no es una forma segura de comunicarse. Hay muchas cosas que pueden salir mal.

Como se mencionó anteriormente, si puedes, solo usa una conexión TLS. Debería poder usar el mismo certificado que usa para su servidor HTTPS. Así que solo obtenga un servidor websocket que admita TLS y listo. Sin embargo, quiero centrarme en su pregunta sobre el uso de AES y pasar por algunos ataques básicos.

Echando un vistazo al protocolo de enlace websocket, vemos que algunos datos son siempre los mismos (como "HTTP / 1.1 101 Protocolos de conmutación"):

enlace

Esto permite ataques conocidos de texto simple . Por ejemplo, un atacante sabe que ese texto simple específico se convierte al texto cifrado observado. Además, su esquema no parece proteger contra los ataques de reproducción, donde reenvío un paquete observado.

AES es un cifrado de bloque que convierte un bloque de datos de texto simple en un bloque de texto cifrado de la misma longitud. Hay varias formas de enviar un montón de bloques a través de la línea. Ver:

enlace

El más simple es el BCE. Aquí solo tienes que enviar bloque tras bloque. Esto significa que cualquier bloque que contenga el mismo texto simple contendrá el mismo texto cifrado. Entonces, si conozco el texto en claro para algún bloque de texto cifrado, y veo el mismo texto cifrado en otra parte, sé que contiene el mismo texto en claro. Además, con el BCE, un atacante también puede intercambiar un bloque por otro, que intercambiará los bloques de texto sin formato después del descifrado.

Un uso más común del encadenamiento de bloques es CBC. Esto encadenará bloques junto con un IV, de modo que no dos bloques de texto plano (o un grupo de bloques) se convertirán en los mismos bloques de texto cifrado. Sin embargo, esto también está lleno de peligro. Si observa detenidamente el esquema de descifrado para CBC, puede ver que al xorar un byte en un bloque de texto cifrado se obtendrá un xor del mismo valor para el bloque de texto simple un bloque después de eso. Hay todo tipo de ataques de bitflipping y cosas que puedes hacer. Además, si el servidor responde de manera diferente cuando el relleno de AES es correcto o no, partes del texto sin formato se pueden recuperar con un padding oracle attack .

Los ataques anteriores funcionan porque no veo nada sobre la verificación de integridad (con un HMAC, por ejemplo) que no impida que un atacante altere el texto cifrado.

Estos son solo algunos ejemplos de cosas que pueden salir mal. También puedes ver los ataques de tiempo si quieres entrar y estás buscando algunas lecturas interesantes. Por favor, no implemente su propio criptográfico.

Y aparte de obtener la contraseña en el dispositivo como mencionó Mike, veo un gran problema al permitir que los usuarios elijan una contraseña para cifrar los datos. Sin un algoritmo de expansión clave, podría simplemente forzar la contraseña para un texto cifrado.