Construir un canal seguro sin SSL / TLS

8

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?

    
pregunta Moustache 18.06.2013 - 12:11
fuente

1 respuesta

6

Tanto el servidor como el cliente saben algo secreto, por lo que pueden confiar en que la comunicación no se modifica en la ruta. Efectivamente, usar una conexión a través de la clave compartida entre ellos es como usar SSL sin un apretón de manos. Normalmente, SSL usaría criptografía asimétrica para a) validar una o más partes en la comunicación yb) establecer una clave compartida para la comunicación.

Sin embargo, usted puede establecer la confianza en la parte a antes de liberar el dispositivo, ya que ambos están en su poder. Siempre que la clave en el dispositivo no esté comprometida (que es la principal debilidad según el uso), si un dispositivo puede comunicarse de manera que descifre, correctamente, el mensaje se originó en el dispositivo. Por lo tanto, solo debe preocuparse por los ataques de repetición, pero cualquier mecanismo simple podría detenerlo (por ejemplo, un contador o una marca de tiempo para evitar la reutilización o el uso de un mensaje anterior al actual).

    
respondido por el AJ Henderson 18.06.2013 - 15:07
fuente

Lea otras preguntas en las etiquetas