¿Cómo aseguro la comunicación entre la aplicación y el dispositivo IoT?


18

Actualmente estoy trabajando en un proyecto que incluye la comunicación Bluetooth entre una aplicación móvil (actualmente usando la plataforma Ionic) y un dispositivo integrado. A modo de comparación, nuestro producto es similar a una cerradura inteligente .

La seguridad es de suma importancia, y estamos buscando formas de garantizar que nuestro hardware y software no sean pirateables. ¿Qué pasos debemos tomar para garantizar que nuestro sistema sea seguro?

Editar: Sí, actualmente estamos encriptando comunicaciones y usando HTTPS cuando el dispositivo se comunica con nuestro servidor.


¿Usar HTTPS? ¿Estás codificando ambos dispositivos? Cifrado?
Mawg dice que reinstalar a Monica el


2
@Mawg Hasta donde yo sé, HTTPS no es aplicable a bluetooth (o al menos, no en un sentido normativo / sensato).
Ricitos

1
Estoy votando para cerrar esta pregunta como fuera de tema porque no puede mostrar cómo esto es específico de IoT. Es solo asegurar la comunicación entre dispositivos.
Helmar

44
@Helmar La comunicación entre dispositivos es una característica bastante importante de IoT, incluso una característica definitoria, por lo que no veo por qué esta pregunta estaría fuera de tema.
Gilles 'SO- deja de ser malvado'

Respuestas:


13

Para garantizar que su dispositivo sea lo suficientemente seguro, tengo varios consejos:

  1. Agregue un poco de encriptación a la comunicación Bluetooth. Recomiendo mantener las claves de cifrado fuera del aire. Por ejemplo, puede pedirle al usuario que escanee un código QR que está en el dispositivo, impreso en la caja, etc. en la configuración inicial de la aplicación móvil, ¿tal vez con una clave AES? Depende de usted. Esto es para evitar que alguien vea la contraseña transmitida por el aire con texto sin formato.
  2. Si puede, manténgase alejado del modo ECB (use CBC) del algoritmo de cifrado que elija, ya que podría proporcionar cierta información sobre los datos transmitidos. Más información sobre eso se puede encontrar aquí .
  3. En la transmisión de datos bluetooth, asegúrese de incluir una identificación única para que el mensaje no pueda repetirse (por ejemplo, puede incluir una marca de tiempo). También puede implementar algún sistema similar a TOTP.
  4. Coloque un puerto en el dispositivo que permita que se actualice fácilmente, de modo que en caso de que se dé cuenta de que el software tiene un error (y por alguna razón no pueda actualizarlo OTA), el dispositivo no es un pisapapeles costoso, solo un dispositivo que debe conectarse a una PC y actualizarse a un nuevo software.
  5. Extra: para asegurarse de que alguien con un certificado raíz no autorizado (probablemente autoemitido e instalado en el dispositivo cliente) no pueda interceptar las comunicaciones de su servidor, verifique el certificado HTTPS. Aquí hay un SO que lo solicita para Android, también debe poder encontrar recursos similares para iOS .

Además, si desea obtener más información sobre la criptología y el cifrado que utilizará para proteger su dispositivo, consulte este libro electrónico (gratuito) . Habla mucho sobre implementaciones buenas y malas de algoritmos de cifrado, y debería ayudarlo a asegurar su producto. (Nota 1: Por favor, no cree su propio algoritmo. Nota 2: No estoy afiliado con crypto101 o lvh).


2
"Si puedes, mantente alejado del BCE". No, mal consejo. Un consejo aceptable sería "nunca use el BCE", pero sigue siendo incompleto. Una mejor respuesta diría que si está escribiendo las letras CBC en su código, lo está haciendo mal . En particular, AES-CBC no garantiza la integridad o autenticidad de la comunicación.
Gilles 'SO- deja de ser malvado'

@Gilles ECB es ciertamente mejor que todos los dispositivos iot que existen hoy en día que solo transmiten cosas como texto sin formato o simplemente xor con un valor establecido, pero sí, ECB casi no hace que su producto sea "no pirateable" (técnicamente nada lo hace, pero puede intentar hacer algo que lo mantenga lo más seguro posible en la actualidad durante el mayor tiempo posible, y que no implique BCE, sino una implementación adecuada de AES-CBC 256).
Ave

13

Si puede tener TCP de extremo a extremo, utilice TLS de extremo a extremo (por ejemplo, con HTTPS).

No reinvente la rueda, especialmente cuando se trata de criptografía: la mayoría de las personas se equivocan. A menos que el dispositivo tenga demasiados recursos para soportar TLS, si llega al nivel de AES, lo está haciendo mal . El error n. ° 1 es cifrar y olvidarse de la autenticación: si tiene un canal cifrado entre su servidor y un intermediario, en lugar de un canal cifrado entre su servidor y su dispositivo, el cifrado no ha proporcionado ningún beneficio . Si no puede usar TLS, asegúrese de que cualquier protocolo que esté utilizando autentique todo y encripte lo que debe ser confidencial.

Para usar TLS de forma segura, piense en las garantías que necesita tener, desde el punto de vista de cada participante. En general, el dispositivo necesita saber que está hablando con el servidor legítimo. Eso significa que debe verificar el certificado del servidor. El dispositivo debe tener el certificado X.509 de una autoridad certificadora registrada como confiable; esto requiere un almacenamiento que no puede ser modificado por un atacante, pero no requiere ninguna confidencialidad del almacenamiento. Tenga en cuenta que no debe codificar directamente el certificado del servidor, ya que eso no le permitiría reemplazar fácilmente ese certificado si se ve comprometido. En cambio, el dispositivo almacena la identidad esperada(nombre de host) del servidor y el certificado de una autoridad de certificación que garantiza que una determinada clave pública pertenece al nombre de host esperado. Una vez más, no reinvente la rueda, confíe en la verificación de certificados provista por su biblioteca o aplicación TLS.

Si el servidor necesita saber que está hablando con un cliente legítimo, entonces cada cliente debe tener su propio certificado de cliente. Eso requiere almacenamiento confidencial en el cliente. Pase el certificado del cliente a la función de apertura de sesión TLS desde su biblioteca TLS, o configúrelo en la configuración de la aplicación.

Eso se encarga de asegurar la comunicación entre su servidor y su dispositivo. Si la aplicación móvil puede comunicarse directamente con el dispositivo (por ejemplo, para permitir la operación desconectada mientras está en la red wifi local), primero debe realizar el emparejamiento entre el interruptor inteligente y el teléfono móvil. Emparejamiento significa un intercambio de claves, preferiblemente un intercambio de claves públicas si los recursos lo permiten, de lo contrario, un acuerdo de claves secretas. El objetivo de este emparejamiento es garantizar que cada dispositivo sepa con quién está hablando.

También deberá asegurar el canal de control, ya sea que vaya directamente desde el dispositivo móvil al conmutador inteligente o mediante un servidor. Piense en la autorización: ¿hay diferentes niveles de acceso al conmutador, por ejemplo, un nivel de control que permita realizar la reconfiguración y un canal básico que solo permita el encendido / apagado? Esto generalmente se maneja mediante un paso de autenticación después de establecer el canal seguro (TLS si es posible).

Otra consideración son las actualizaciones de firmware. Eso es complicado: por un lado, no existe la seguridad absoluta, por lo que tendrá parches de seguridad para aplicar de vez en cuando. Por otro lado, un mecanismo de actualización de firmware es algo complejo y podría tener errores. Como mínimo, asegúrese de que sus actualizaciones de firmware estén firmadas. Confiar únicamente en la seguridad del canal de comunicación para las actualizaciones es dudoso, porque la base confiable para un canal seguro es más grande que para una verificación de seguridad estática, y a veces es posible que desee aplicar actualizaciones de firmware sin una conexión de red. Además de verificar la firma, idealmente debería tener alguna protección contra la reversión, para que un adversario pueda '

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.