¿Es una contraseña preestablecida en un sistema integrado lo suficientemente segura?

Muy bien, la principal preocupación aquí es que un atacante podría interceptar el tráfico entre la compañía de chipset y su servidor.

¿Cómo sabe el dispositivo que está hablando con el servidor correcto? Si intercepté el tráfico entre el dispositivo y el servidor y simulé que era el servidor, ¿el dispositivo me dará su contraseña? / p>

La forma "correcta" de hacer esto es usar SSL autenticado por el cliente. Esto significa que en lugar de una "contraseña", cada dispositivo obtiene un único RSA o ECC par de llaves, y un certificado correspondiente del servidor (que es un Autoridad de certificación en este caso). Esto le permite usar el Handshake TLS autenticado por el cliente .

Hay formas seguras de realizar la autenticación utilizando un secreto precompartido que tanto el servidor como el cliente conocen, pero "¡aquí está mi contraseña, asegúrese de que coincida!" no es uno de ellos (al menos no sin resolver de forma independiente el problema "¿cómo sé que estoy hablando con el servidor correcto?"). Una forma es tener ambos extremos MAC el masaje con una clave derivada del secreto compartido. Luego, la otra parte puede calcular el mismo MAC usando su copia del secreto compartido y asegurarse de que tengan el mismo MAC. Otra forma es usar AES en modo de cifrado autenticado (AE) .

... O como apunta @SEJPM, omita todo lo relacionado con "rodar su propia cosa" y simplemente use uno de los Ciphersuites (TLS-PSK) .

Sin que el cliente verifique el servidor, cualquier esquema como este es vulnerable a la suplantación. Específicamente, al implementar un servidor falso y obligar al cliente a conectarse a él (quizás a través de una regla de firewall), el servidor falso recibiría los detalles enviados por el cliente, y luego podría usarlos para enviar más contenido malicioso al servidor legítimo. .

Para protegerse contra esto, el cliente podría comparar el certificado del servidor legítimo con el del servidor al que se está conectando y solo enviar datos si coinciden. Sin embargo, esto requeriría que el cliente conozca el certificado público correspondiente a la parte privada utilizada por el servidor, lo que no siempre es posible en los dispositivos integrados (por ejemplo, tienden a carecer de la capacidad de actualización después de los cambios de certificado).

Por lo tanto, sería posible utilizar otros métodos que permitan que ambos extremos verifiquen el otro: tal vez un nonce, generado por el servidor y enviado al cliente, utilizando un método predefinido (por ejemplo, concatenando un definió la cadena para el nonce, y luego el hashing con un algoritmo de hashing criptográfico), y devolvió. Dado que la cadena predefinida nunca se envía, esto debería ser difícil de romper sin acceso al dispositivo o al servidor (ambos necesitan conocer la cadena), incluso si conoce el nonce para una solicitud determinada.

Esencialmente, necesita verificar que se está comunicando con el otro dispositivo esperado, desde ambos extremos, para asegurarse de que sus datos no puedan ser alterados. Sin embargo, esto implica varios pasos.

A riesgo de ser demasiado amplio, su solución es segura, salvo en dos circunstancias.

  

"Cada dispositivo tiene su propia copia de la clave pública de la nube de partículas"

Esto significa que (salvo un error de software que permita que algo como engañar al cliente para que use una versión débil de TLS / SSL) el dispositivo solo se sentirá cómodo al hablar con el servidor que tiene la clave privada correcta, a saber, la "nube de partículas" anfitrión. Por lo tanto, el servidor y el dispositivo tienen una forma de autenticación bidireccional y se realiza en secreto para que haya confidencialidad y no rechazo.

El otro extremo flexible es, ¿qué sucede si se compromete la clave privada de la Nube de partículas? La gestión adecuada de certificados (a través de una CA) permite esta inevitabilidad al invalidar una clave y reemplazarla por una nueva. Si la clave está codificada, esto suena como que solo es posible a través de una actualización de firmware.

¿Hay actualizaciones de firmware disponibles en banda? ¿fuera de banda? ¿Solo como parte de esta mecanización de la nube? ¿De ningún modo? La respuesta a eso podría ser lo que determina qué tan cómodo se siente usted al creer que el canal de comunicación está listo para las aplicaciones de seguridad personal. Cualquier problema con estas dos advertencias puede dejar a los dispositivos tristemente desprotegidos hasta que se realice una actualización del firmware para parchear el problema a todos los dispositivos, de una manera segura (no puedo confiar en la nube para que la presione más si la clave está comprometida, ¿eh?)