Primero, debes definir con precisión contra qué tipo de ataque estás tratando de defenderte:
- ¿Temes a los atacantes que espían los mensajes intercambiados entre el sensor y el servidor y aprendes el contenido de los mensajes?
- ¿Temes a los atacantes que se hacen pasar por el servidor y hablan con el sensor como si fueran el servidor?
- ¿Temes a los atacantes que se hacen pasar por el sensor y envían solicitudes falsas al servidor?
- ¿Tiene miedo de los atacantes que sueltan, duplican, reproducen y reordenan los mensajes entre el cliente y el servidor?
Un protocolo ligero, solo simétrico, que cubre todo lo anterior, hasta cierto punto, tiene este aspecto:
- Para cualquier canal de comunicación entre el sensor y el servidor, existen dos claves simétricas que tanto el servidor como el sensor conocen, una para los datos enviados por el servidor al sensor y otra para los datos enviados por el sensor al servidor .
- Todos los mensajes enviados por el servidor o el sensor están encriptados con AES en modo EAX .
- El modo EAX requiere una IV no repetitiva; el sensor y el servidor utilizarán contadores .
- Cada mensaje contiene el IV (valor de contador) para ese mensaje, seguido del cifrado AES-EAX del mensaje.
- Para cada canal de comunicación, el sensor almacena el valor de contador actual para el mensaje que envía y el IV del último mensaje que recibió del servidor a través de ese canal.
- Cuando envía un mensaje nuevo, el sensor incrementa su contador (para ese canal), almacena el nuevo valor y luego (solo entonces) usa el nuevo valor como IV para AES-EAX.
- Cuando recibe un mensaje del servidor, el sensor comprueba que el nuevo mensaje utiliza un IV que es estrictamente mayor que el último recibido del servidor; el sensor almacena ese nuevo IV y luego (solo entonces) descifra y procesa el mensaje desde el servidor.
- El servidor emplea las mismas técnicas que el sensor (contador de los mensajes que envía, guardado IV del último mensaje del sensor, etc.).
Suponiendo que los contadores comienzan en 0, esto significa que el primer mensaje que enviará el sensor usará 1 como IV; El segundo mensaje usará 2, y así sucesivamente. Del mismo modo para los mensajes enviados por el servidor. Esto permite que el servidor y el sensor detecten mensajes reproducidos, mensajes desordenados y mensajes faltantes; lo que deben hacer en tal caso depende de usted decidirlo.
En EAX: la combinación de cifrado y MAC con una clave dada no es del todo fácil. Reutilizar la misma clave para el cifrado y el MAC es, en teoría, arriesgado. Un modo de encriptación autenticado como EAX se encarga de los detalles finos. Como un bono extra, EAX no necesita IV aleatoriamente impredecible, como CBC; solo requiere que los valores de IV nunca se repitan (para una clave determinada), por lo que un contador está bien, siempre que pueda almacenar el valor de IV actual de manera flexible y hacerlo en el momento adecuado. ¡Cuidado con un atacante que apaga el sensor para forzar un reinicio IV!
En las teclas: He hablado aquí sobre los canales bidireccionales. Necesita una tecla por dirección del canal. Esto significa dos claves para la cosa HTTP (una para solicitudes, una para respuestas) y una clave para el canal de comando, asumiendo que es unidireccional (comandos del servidor al sensor, no hay respuesta del sensor). Si almacenar tres claves de 128 bits es problemático, puede almacenar una clave única de 128 bits (una "clave maestra") y reconstruir dinámicamente las tres claves a partir de eso, con un función de derivación de claves . Ya que está en un entorno restringido, y EAX solo usa AES, le sugiero usar AES para eso también: usando la llave maestra como clave, cifre tres valores constantes fijos (por ejemplo, "0", "1" y "2") con una una sola invocación AES en bruto para cada uno; esto producirá tres bloques de 128 bits que funcionarán bien como sus claves de canal.
Sobre resistencia a la manipulación: Supongo que los sensores se desplegarán "en el campo", por lo que un atacante puede tener éxito en atrapar un sensor, abrirlo y luego intentar recuperar su contenido lógico. A menos que el sensor esté especialmente reforzado contra la manipulación (como lo sería una tarjeta inteligente), esto significa que el atacante podrá aprender las teclas del sensor y, a partir de ese momento, "emular" el sensor como lo ve el servidor. Como mínimo, cada sensor desplegado debe tener sus propias claves, y el servidor tendrá que conocer las claves de todos los sensores desplegados.