Estoy buscando posibles opciones para construir un canal seguro entre múltiples dispositivos integrados con capacidades de criptografía limitadas y un servidor HTTP (podría ser algún tipo de servicio web).
1. Contexto
Los dispositivos solo admiten HTTP, algunos algoritmos de clave simétrica y algunas funciones de hash a través de un marco de desarrollo en los dispositivos. Desafortunadamente, SSL / TLS no es compatible y, por lo tanto, no es una opción aquí.
En el momento del arranque, los dispositivos se ponen en contacto con el servidor HTTP para recuperar su configuración específica. Tengo un control completo sobre los dispositivos antes de que se envíen en libertad.
Algunas de las amenazas identificadas son:
- Descarga de un archivo de configuración malicioso.
- Descarga del archivo de configuración incorrecto (desde otro dispositivo).
- Descarga múltiple del mismo archivo de configuración.
- Escuchando el archivo de configuración por un tercero no autorizado fiesta.
- Acceso fraudulento al servidor HTTP (no necesariamente relevante aquí).
El proceso de recuperación del archivo de configuración debería ocurrir idealmente solo una vez. Una vez que se descargue el archivo de configuración, el acceso al servidor HTTP se descartará para ese dispositivo en particular.
2. Propuesta
Ya que puedo cargar un secreto compartido temporal en los dispositivos antes de dejarlos en libertad, estaba pensando en utilizar HMAC con clave (código de autenticación de mensaje de hash) para autenticar el dispositivo sin tener que enviar La clave secreta en el cable. Algo similar al diseño AWS API y utiliza el número de serie único del dispositivo como Clave de identificación.
Una vez autenticado, al dispositivo se le otorga acceso a un recurso, en este caso el archivo de configuración. Para mitigar algunas de las amenazas identificadas, el archivo de configuración debe estar cifrado y firmado (?) Durante la transferencia.
Para este propósito, estaba pensando en utilizar un modo de cifrado autenticado.
Solo puedo usar AES256 en modo CBC y HMAC-SHA256 . Otro algoritmo de cifrado autenticado "correcto" no está disponible dentro del marco.
3. Preguntas
¿Tiene sentido?
Para evitar agregar complejidad en algo suficientemente complejo, ¿es una opción usar el secreto compartido precargado como clave para la función HMAC y el hash secreto compartido como clave de cifrado para el cifrado AES?
¿Permite la mitigación de las amenazas identificadas en ese escenario en particular?
¿Se puede simplificar el proceso y mantener sus propiedades de seguridad?
3. Recursos
Cómo elegir un modo de cifrado autenticado
Cifrado autenticado y cómo no quedar atrapado persiguiendo a un coyote
Autenticación de solicitudes mediante la API REST de AWS
Diseño de una API REST (Web) segura sin OAuth
¿Por qué no puedo usar la misma clave para el cifrado y MAC?