¿Puede señalar las fallas en el enfoque declarado de agregar un nuevo dispositivo a un sistema seguro de certificados ssl existente?

Question

¿Puede señalar las fallas en el enfoque declarado de agregar un nuevo dispositivo a un sistema seguro de certificados ssl existente?

#1 de Mike Ounsworth (1 votos)

2

Estoy intentando agregar nuevos dispositivos a un sistema seguro. Un sistema seguro en el que un servidor web es identificado por una CA personalizada y todos los clientes también lo son. Es decir, cada cliente que se conecta al servidor tiene su propio certificado. Si debo agregar un nuevo dispositivo móvil al sistema seguro, estos serían los pasos.

El usuario instala la aplicación desde la tienda de aplicaciones
Una vez que se abre la aplicación, el usuario ve una cadena de 16 longitud (el usuario no tiene que iniciar sesión para ver eso). Antes de mostrarlo al usuario, la cadena se envía al servidor web a través de websocket, con hash. El servidor almacena esta cadena de hash con un ttl de 3 minutos.
El usuario inicia sesión en el servidor web con sus credenciales (tiene permisos para agregar un nuevo dispositivo) y ingresa la cadena de 16 longitudes allí. El servidor web lo hash y compara el hash con el guardado.
El servidor web responde a la aplicación móvil en el mismo websocket con un nuevo certificado. La respuesta es encriptada simétricamente con la cadena de 16 longitudes.
Este certificado se utiliza para futuras interacciones con el servidor web, por lo que no necesita intervención humana.

¿Esto no es lo suficientemente seguro? ¿Cuál sería una forma más estándar de hacer esto?

certificates certificate-authority

pregunta Srikanth 07.09.2018 - 13:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas certificates certificate-authority

Firmar muchos mensajes con la misma clave privada [cerrado] ¿Por qué son útiles los firewalls sin estado en las plataformas de nube pública?

score 1 · Accepted Answer

No nos has dado un modelo de amenaza , por lo que Asumiré un entorno corporativo estándar, y el valor de los datos protegidos por este esquema es menos de $ 1 millón de USD.

Ese esquema en realidad me suena bien. La inscripción del dispositivo de arranque es siempre difícil porque necesita algún tipo de secreto de dispositivo conocido tanto por el dispositivo como por el servidor.

Dice "app store", así que asumo que se trata de un dispositivo Android / iOS en lugar de un dispositivo IoT. Vergüenza, porque con un dispositivo IoT es posible que pueda fabricarlo con un secreto conocido por su base de datos o un certificado predeterminado. En su lugar, está generando un secreto y la longitud (16 caracteres de cadena) es un equilibrio de seguridad y facilidad de uso.

Algunos pensamientos:

Espero que tu websocket para cargar el hash esté usando TLS para hacer que sea más difícil de rastrear (porque, ¿por qué no?)
Ya que un atacante tendría que forzar el hash con fuerza bruta y robar un nombre de usuario / contraseña para una cuenta autorizada, puede evitar que el secreto no tenga un total de 128 bits de entropía.
¿Cuál es el conjunto de caracteres más grande que puede usar para el secreto sin causar problemas de uso? Probablemente UPPERS y números? Posiblemente UPPERS, lowers, and numbers? Tendrá que excluir los caracteres que se parecen, 1 / I / l, O / 0, etc.
Cuando dices "La respuesta es encriptada simétricamente con la cadena de 16", ¿cómo estás haciendo esto? ¿Está ejecutando la cadena de 16 bytes a través de una función de derivación de clave para convertirla en una clave AES-128/256 de tamaño completo? ¿El websocket usa TLS y el secreto es el uso de cifrado manual en su interior? ¿Ha considerado abrir un nuevo websocket en este momento con los modos TLS_PSK (clave precompartida) o PAKE (intercambio de clave autorizado por contraseña)?
Cuando dice "El servidor web responde a la aplicación móvil en el mismo websocket con un nuevo certificado". ¿Solo el certificado, o también la clave privada? La forma correcta de hacer esto sería generar la clave privada en el dispositivo (idealmente en el almacén de claves seguro de Android / iOS si es posible) y enviar una CSR al servidor en el paso 2, de esa manera nunca se enviarán claves privadas a través de la red. período.