Evaluación de seguridad de una implementación SSL/TLS heredada en un dispositivo IoT
Estoy realizando una evaluación de seguridad sobre la seguridad de la comunicación de un dispositivo IoT heredado. El objetivo es evaluar y encontrar brechas de seguridad en el diseño/implementación actual.
El modo de evaluación es manual, principalmente con la referencia del diseño y código existentes. Esto es solo del lado del cliente en el dispositivo; mientras que el servidor es un servidor basado en la nube. El dispositivo utiliza un módulo GSM (SIMCom SIM900) y realiza una comunicación HTTPS con el servidor a través de Internet mediante comandos GSM AT.
Según mi comprensión de SSL/TLS, estoy considerando los siguientes parámetros o criterios para esta evaluación:
una. Versión del protocolo TLS
b. Conjuntos de cifrado utilizados
C. gestión de certificados y claves
d. CA raíz instaladas en el dispositivo
mi. Aspecto PKI integrado para la gestión de identidad de dispositivos
F. Aspecto criptográfico de hardware (SHE/TPM)
¿Lo estoy haciendo de una manera correcta? Aunque creo que la lista anterior de parámetros no es específica de la plataforma Device HW/SW; más bien genérico. pero supongo que así es como debería ser! Me refiero a que la lista de parámetros será más o menos la misma; sin embargo, la evaluación real de estos dependerá de los requisitos de seguridad y otros aspectos, como la huella del dispositivo y su plataforma, etc.
¿La lista de parámetros de evaluación que estoy considerando es buena y adecuada?
Respuestas
Este es un buen comienzo, pero una evaluación exhaustiva tendría que ir mucho más allá. Por ejemplo:
¿Cómo genera el cliente números aleatorios? ¿Utiliza un CSPRNG ? ¿O utiliza un generador de números aleatorios débil, como el que se usaba en las primeras versiones de Netscape Navigator , donde un atacante pasivo podía adivinar los números aleatorios generados para las claves de sesión y, por lo tanto, descifrar el texto cifrado que circulaba por la red?
¿El cliente pierde información cuando encuentra un error de relleno? Si es así, entonces podría ser susceptible a un ataque de oráculo de relleno , como fue el caso con Steam Gaming Client .
¿Cómo implementa el cliente ECDSA ? ¿El cliente genera una nueva k aleatoria para cada firma que crea? De lo contrario, es posible que un atacante pasivo calcule la clave de firma privada después de observar algunas firmas, como fue el caso con Sony Playstation 3 .
Estos son solo algunos ejemplos. Pero, como puede ver, los errores sutiles en la implementación de la criptografía pueden tener consecuencias desastrosas. Esta es la razón por la cual la criptografía es tan difícil de hacer bien.