Protección de IoT desde la capa de red hasta la capa de aplicación

Wouter van der Beek

La seguridad en el Internet de las cosas (IoT) se ha convertido en un requisito fundamental, con una legislación reciente que exige 'características de seguridad razonables'. Es muy claro que el costo de implementar la seguridad dentro del IoT es necesario y supera con creces el costo de no hacerlo. .

La seguridad se construye en capas; la primera capa que debe protegerse es la capa de hardware, la segunda es la capa de red. En este artículo, la capa de red a la que se hace referencia es la capa de red Thread:una red de IoT mallada de bajo costo y energía.

Sin embargo, la red es una combinación de tecnologías IP inalámbricas y por cable, por lo que también existe la necesidad de seguridad en el nivel de la aplicación. Esto proviene de la capa de aplicación OCF; un dominio seguro donde todos los dispositivos y clientes pueden comunicarse entre sí de forma segura, por ejemplo, Wouter van der Beek, arquitecto senior de IoT, Cisco Systems y presidente del Grupo de Trabajo Técnico, Open Connectivity Foundation y Bruno Johnson, director ejecutivo de Cascoda , miembro de la Open Connectivity Foundation.

Seguridad de hardware

El microcontrolador restringido requiere funciones para protegerlo de códigos maliciosos y espionaje basado en hardware que comprometerían la seguridad. El hardware seguro protege la secuencia de arranque del microcontrolador validando su firma y protege la memoria y el acceso periférico para aislar partes críticas del código. Esto solo permite el acceso a través de una interfaz de programación de aplicaciones (API) bien definida y confiable. Estas funciones minimizan la superficie de ataque de los dispositivos conectados, proporcionando una base segura para la red y la aplicación.

Seguridad de red

La capa de red debe garantizar que los datos enviados por aire no se puedan alterar y que los dispositivos que se unen a la red sean legítimos. Para proteger los datos por aire, Thread utiliza una clave para toda la red que emplea criptografía de clave simétrica conocida como AES-CCM. AES-CCM agrega un código de etiqueta a cada mensaje y lo encripta usando esta clave para toda la red. Si el destinatario tiene la clave, puede descifrar, verificar el origen y verificar que el mensaje no se corrompió en tránsito. Por último, la clave se cambia periódicamente según la clave existente y un contador de secuencia específico en caso de que se vea comprometida.

Sin embargo, cuando un nuevo dispositivo necesita unirse a una red, no conoce la clave de toda la red y, por lo tanto, debe obtenerla. Este proceso se conoce como puesta en servicio. Por supuesto, la clave no se puede transmitir sin cifrado, ya que podría ser interceptada por un atacante. Para superar este problema, la puesta en marcha de subprocesos utiliza un proceso conocido como intercambio de claves autenticadas con contraseña (PAKE), que forma parte del estándar de seguridad de la capa de transporte de datagramas (DTLS).

PAKE utiliza un secreto de baja intensidad junto con la criptografía asimétrica para generar un secreto de alta intensidad entre las dos partes. El secreto de alta resistencia se utiliza para cifrar la comunicación de la clave desde el comisionado de Thread (por ejemplo, un teléfono inteligente conectado a la red de Thread) al dispositivo de unión.

Seguridad de la aplicación

Para garantizar la seguridad de un extremo a otro en la capa de aplicación, OCF ofrece soluciones para transferir la propiedad del fabricante al comprador o de un comprador a otro. El primer paso en la integración es establecer la propiedad del dispositivo. Para ello, OCF emite certificados y mantiene una base de datos para cada dispositivo certificado. En esta etapa, el dispositivo cuenta con esas credenciales para establecer conexiones seguras autenticadas mutuamente con otros dispositivos en el dominio seguro de IoT, gracias a OCF Public Key Infrastructure (PKI).

Las instrucciones de aprovisionamiento se dan luego a través de una conexión segura, cifrada por DTLS. El proceso comienza con la transferencia de propiedad del dispositivo y luego el aprovisionamiento del dispositivo, siguiendo un conjunto de transiciones de estado. Cabe señalar que OCF tiene en cuenta que durante su ciclo de vida, un dispositivo puede cambiar de propiedad. Por lo tanto, OCF requiere que los dispositivos implementen un restablecimiento de hardware para volver a su estado de inicialización.

Además de este proceso de incorporación, los dispositivos OCF se pueden aprovisionar con distintos niveles de seguridad. OCF proporciona un enfoque en capas:control de acceso basado en roles y descripciones de uso del fabricante. El primero aborda la seguridad del dispositivo, mientras que el segundo agrega una capa adicional de protección de la red.

Implementación mediante hardware restringido

La implementación de OCF-over-Thread en hardware restringido es un desafío debido al espacio de código, la memoria y la potencia de cálculo muy limitados de los microcontroladores de bajo costo. Como resultado, es necesario aprovechar la reutilización del código. El mayor ahorro de código proviene de compartir la biblioteca de criptografía central y mbedTLS, común a ambas pilas. Esto es posible porque OCF y Thread se basan en DTLS.

La ejecución de las primitivas de criptografía centrales para DTLS requiere acceso a hardware dedicado para la aceleración, que es mucho más eficiente en tiempo y energía que el software puro. Dicha aceleración de hardware reduce el tiempo de puesta en marcha de Thread en varios órdenes de magnitud, un aumento significativo de la velocidad para la tarea más intensiva en computación de la que es responsable el microcontrolador. Por lo tanto, administrar el acceso a la funcionalidad de criptografía de hardware para ambas pilas a través de la biblioteca mbedTLS es de vital importancia.

Tanto OCF como Thread Group ejecutan proyectos de código abierto para sus respectivas especificaciones. Estas implementaciones concretas eliminan la ambigüedad para los desarrolladores y forjan la interoperabilidad.

Las tecnologías que pueden trabajar juntas desde la aplicación hasta la capa de red forman la mejor plataforma de IoT segura de su clase que se puede implementar hoy.

Los autores son Wouter van der Beek, arquitecto senior de IoT, presidente del grupo de trabajo técnico y de sistemas de Cisco, Open Connectivity Foundation y Bruno Johnson, director ejecutivo de Cascoda, miembro de Open Connectivity Foundation.