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 '