Asegurar la comunicación entre sistemas integrados limitados
Actualmente estoy tratando de fortalecer la comunicación a través de un canal de comunicación físico limitado en un sistema integrado.
El escenario
Creo que el sistema es bastante típico para pequeñas aplicaciones integradas:
Los sistemas embebidos involucrados son pequeños microcontroladores sin ningún sistema operativo, que se puede asumir que están en un entorno físico seguro. El canal de conexión es físicamente accesible para los agresores, pueden interferir con los mensajes según se desee.
Son posibles diferentes canales de comunicación: p. Ej. RS485 o RS232. Existe un protocolo crudo que maneja cosas como direccionamiento e integridad cruda (por ejemplo, CRC16 para bitflips) sobre el cual podemos construir. Piense en ello como un TCP lento.
Cada socio de comunicación conoce un certificado raíz que puede actuar como una CA y tiene un certificado único (+ clave) firmado por él. Los certificados son autofirmados, curva elíptica prime256v1
La biblioteca mbedTLS está disponible para estos sistemas (con DH, AES, ..).
La mayoría de las veces no hay Internet disponible.
Los sistemas pueden mantener el tiempo y pueden crear suficientes números aleatorios
Quiero alcanzar la privacidad, la autenticidad y la integridad.
Cómo podría resolverse
Una regla en los protocolos criptográficos es nunca implementarlos por su cuenta. Desafortunadamente, no encontré nada que coincida con este caso de uso.
También revisé las preguntas existentes, pero nada proporcionó la solución completa que estaba buscando.
Finalmente, en esta respuesta, la implementación de un protocolo propio se da como última opción.
Es por eso que se me ocurrió la solución que se describe a continuación, pero no estoy completamente seguro de ello. Me orienté en esta respuesta sobre cómo autenticar un intercambio de claves Diffie-Hellmann , esta respuesta sobre cómo verificar la integridad y este hilo me dio algunas ideas sobre cómo implementar dicho protocolo .
Protocolo para asegurar la comunicación
Lo primero que debe hacer es generar aleatoriamente una clave simétrica K. Lo primero que se envía es un mensaje de reconocimiento. Tiene los siguientes campos:
| Campo | Descripción |
|---|---|
| DH | El intercambio de claves Diffie-Hellmann msg g K |
| Cert | El certificado (-chain) del dispositivo de envío |
| MsgIdNonce | Un valor aleatorio de 64 bits |
| Firma | Una firma del mensaje completo utilizando la clave privada de Cert |
Ambos dispositivos envían (y reciben) dicho mensaje.
Cuando se recibe un mensaje, se hace lo siguiente:
- Verifique si el certificado está firmado por la CA esperada (debe estar en cadena)
- Compruebe si msg está correctamente firmado con cert y su clave
Cuando estas comprobaciones tienen éxito, los mensajes DH g K enviados y recibidos se utilizan para calcular una clave simétrica.
A partir de este momento, las aplicaciones pueden enviar mensajes cifrados con AES-CBC. Como los mensajes se pueden perder con relativa frecuencia, IV siempre está en el mensaje.
Este es el formato del mensaje:
| Campo | Descripción | Cifrado |
|---|---|---|
| IV | Inicialmente Random IV para AES | No |
| MsgIdNonce | Apretón de manos / Último MsgIdNonce + 1 o + 2 | si |
| Datos de la aplicación | Los datos / comandos a proteger | si |
| CMAC truncado a 64 bits | MAC para verificar la integridad | si |
Para que un mensaje sea aceptado, debe
- Tener el MsgIdNonce esperado (1 o 2 por encima del último recibido) - evitando ataques de repetición, permitiendo perder 1 mensaje
- Tener un CMAC válido para prevenir ataques a la integridad
- Ser recibido máx. T segundos después del último mensaje: prevención de ataques de retraso
Si algo no es como se esperaba, se vuelve a enviar el protocolo de enlace y, a continuación, se vuelve a enviar el mensaje con los parámetros recién intercambiados.
Preguntas
¿Estoy en el camino correcto o debería probar algo completamente diferente?
¿Proporciona esto mis objetivos de seguridad o me olvido de alguna vulnerabilidad obvia aquí?
¿Puede esto funcionar?
Espero que pueda ayudarme a mí y a otros ingenieros integrados que enfrentan problemas similares.
Respuestas
Una regla en los protocolos criptográficos es nunca implementarlos por su cuenta. Desafortunadamente, no encontré nada que coincida con este caso de uso.
¿Ha considerado DTLS ? Eso intenta abordar el mismo problema (excepto las marcas de tiempo; que podrían agregarse insertando la marca de tiempo en el datagrama), y ya tiene las cosas bien pensadas. Otra posibilidad sería IPsec; sin embargo, DTLS parece estar más cerca de abordar el problema que tiene (a menos que el tráfico de datos que está protegiendo sea tráfico IP).
Dicho esto, aquí hay algunas ideas sobre el protocolo que describió:
¿Qué sucede si se descartan dos mensajes secuenciales (por ejemplo, se reciben incorrectamente)? ¿Se darán cuenta las dos partes de lo que sucedió, o procederán a eliminar todos los mensajes posteriores (debido a la regla de 'nonce tiene que incrementar no más de 2')?
Suponiendo que intenten una nueva clave, ¿cómo se coordina? Si un lado piensa que aún no ha cambiado la clave y el otro piensa que sí, ¿qué pasará con los mensajes cifrados con la clave anterior? En general, nos parece útil incluir una etiqueta 'en qué clave está cifrada' con el texto cifrado (en DTLS, esta es la 'época').
¿Puede su canal de comunicación reordenar los mensajes? Sospecho que no puede en su caso, pero si puede, debería pensar en cómo debería manejarse.
¿Qué sucede si alguien inyecta un mensaje de reconocimiento previo (válido)? ¿Cómo confundirá eso las cosas?
En la ruta de cifrado de datos, utiliza el cifrado CBC y la integridad CMAC. Si bien esta es una solución viable, es propensa a varios ataques de relleno si no se integran correctamente. La moda actual es usar un modo AEAD (como GCM o Chacha20 / Poly1305) que hace ambas cosas.
¿El tráfico cifrado es unidireccional o bidireccional? Si el tráfico va en ambos sentidos, ¿utiliza el mismo conjunto de claves para proteger ambos conjuntos de tráfico?
"Si algo no es como se esperaba, se vuelve a enviar el protocolo de enlace y, a continuación, se vuelve a enviar el mensaje con los parámetros recién intercambiados". - ¿Cómo funciona? Si el destinatario decidió que no le gustaba el mensaje, ¿cómo sabe el remitente que debe reenviarlo?