Agregue un elemento seguro para incorporar seguridad del borde a la nube en un diseño de IoT
Colaboración de Editores de DigiKey de América del Norte
2019-09-10
La ciberseguridad sigue siendo un problema universal al momento de diseñar e implementar cualquier sistema conectado al Internet público. En el Internet de las cosas (IoT), los problemas de seguridad son especialmente graves a medida que los usuarios comienzan a cuestionar la capacidad de los dispositivos conectados para admitir aplicaciones de forma segura en hogares inteligentes, fábricas inteligentes o ciudades inteligentes. Sin embargo, al enfrentar cronogramas de entrega más ajustados, los desarrolladores de dispositivos IoT a menudo sienten que no pueden costear los recursos del dispositivo, y mucho menos disponer del tiempo adicional que se necesitaba en el pasado para implementar el amplio conjunto de capacidades requeridas para una solución de seguridad eficaz.
Los proveedores de semiconductores están ayudando a lograr un equilibrio al ofrecer soluciones de seguridad más fáciles de implementar. En este artículo, se analiza el problema de la seguridad primero, para luego presentar una solución de NXP Semiconductors, concretamente, el elemento seguro (SE) EdgeLock SE050. A continuación, se les muestra a los desarrolladores cómo usar este dispositivo de un solo chip para implementar rápidamente la seguridad del borde a la nube en sus dispositivos IoT.
El problema de seguridad de IoT
Lamentablemente, los dispositivos IoT con seguridad deficiente han demostrado ser un objetivo atractivo para los ataques cibernéticos. Una vez comprometidos, los dispositivos pueden ceder datos confidenciales del usuario, como también proporcionar información valiosa necesaria para crear copias falsificadas de los dispositivos. Asimismo, los piratas informáticos usan estos dispositivos expuestos para hacer mayores estragos, al penetrar con más profundidad en las redes hasta llegar a otros dispositivos, sistemas y recursos empresariales conectados. En consecuencia, los efectos de los dispositivos de IoT comprometidos se extienden a través de las múltiples capas de la jerarquía de IoT, e incluso amenazan la seguridad pública en aplicaciones de IoT emergentes, como la automatización de edificios, los sistemas industriales, el transporte y los dispositivos médicos.
Para los desarrolladores encargados de ofrecer diseños de IoT más eficientes, la seguridad puede ser una adición indeseada a una lista creciente de requisitos, ya dominada por la demanda de un mayor rendimiento y un menor consumo de energía. De hecho, la seguridad efectiva depende de una lista cada vez más extensa de requisitos necesarios para mitigar las amenazas que se extienden desde el borde hasta la nube.
Aplicadas de forma aislada, incluso las técnicas conocidas, como el cifrado y la autenticación son insuficientes por sí solas. Es indispensable que la seguridad de IoT se base en una raíz de confianza diseñada para garantizar que los mecanismos y protocolos de seguridad estén protegidos contra los peligros. Al mismo tiempo, los métodos de seguridad deben aplicarse cada vez con mayor granularidad, para proteger no solo las conexiones entre los dispositivos IoT, sino también las conexiones entre los componentes de un diseño de IoT individual.
NXP EdgeLock SE050 SE está diseñado específicamente para proporcionar la gama de mecanismos y protocolos de seguridad que se necesitan para construir seguridad del borde a la nube en dispositivos IoT.
Solución de seguridad robusta
Diseñado como una solución llave en mano para la seguridad de dispositivos IoT, NXP SE050 se basa en la amplia experiencia de NXP en seguridad de tarjetas inteligentes para proporcionar una raíz de confianza de hardware para los diseños de IoT. El dispositivo combina un microcontrolador dedicado y un almacenamiento de credenciales seguro, con una pila de software integrada en el sistema operativo (SO) de tarjeta inteligente Java Card OpenPlatform (JCOP). Certificada de forma independiente hasta el nivel del sistema operativo con el Criterio Común (CC) del Nivel de evaluación de seguridad (EAL), Nivel 6 aumentado (EAL 6+), la plataforma operativa SE050 ofrece un nivel excepcional de seguridad para operar en entornos de alta amenaza (Figura 1).
Figura 1: Entre los productos certificados, la plataforma SE050 ofrece un nivel excepcional de seguridad, con una certificación hasta el nivel del sistema operativo de CC EAL 6+. (Fuente de datos: Common Criteria)
Optimizado para ejecutarse en esta robusta plataforma de seguridad, un applet de seguridad de IoT NXP dedicado utiliza una biblioteca criptográfica incorporada que admite un conjunto completo de algoritmos de criptografía, como los siguientes:
- Criptografía simétrica que utiliza los algoritmos de Estándar de cifrado avanzado (AES) y Estándar de cifrado de datos (DES).
- Criptografía asimétrica que utiliza los algoritmos de Criptografía de curva elíptica (ECA) y Rivest-Shamir-Adleman (RSA), compatible con varias curvas ECC, como las curvas estándar que determina el Instituto Nacional de Estándares y Tecnología (NIST).
- Múltiples funciones hash utilizadas para crear códigos de autenticación de mensajes (MAC).
- Algoritmos de función de derivación de clave múltiple (KDF) utilizados para la función de hashing de contraseñas, acuerdo de claves y fortalecimiento de claves, entre otros métodos.
Para acelerar el rendimiento, el dispositivo SE050 integra aceleradores de hardware para el Estándar de cifrado avanzado (AES), el Estándar de cifrado de datos (DES) y la criptografía de Cifrado de mensajes basado en atributos rápido (FAME).
Para proteger las credenciales utilizadas durante las operaciones criptográficas, el dispositivo proporciona hasta 50 kilobytes (Kbytes) de Memoria Flash segura del usuario y ya viene provisto de claves raíz diseñadas para admitir transacciones típicas de IoT. Los desarrolladores que crean diseños de gran volumen también pueden aprovechar las claves personalizadas y las credenciales que provee de forma segura NXP o proveedores terceros autorizados.
Además de la Memoria Flash integrada, el dispositivo admite el acceso a la memoria de acceso aleatorio (RAM) para almacenar certificados públicos; por ejemplo, mientras las claves privadas asociadas permanecen en la Memoria Flash segura. Además, el applet IoT SE050 incorpora una función segura de importación/exportación, que permite que los desarrolladores almacenen claves o datos arbitrarios de forma segura en la memoria externa. Aun así, el dispositivo usa una unidad de administración de memoria que limita el acceso a distintas partes de la memoria solo para el applet IoT, lo que impide el acceso no autorizado a través del microcontrolador. Para una mayor protección contra la manipulación y los sofisticados ataques de canal lateral, el dispositivo también incorpora múltiples barreras lógicas y físicas contra el acceso no autorizado.
Sin embargo, la seguridad implica tanto permitir el acceso a dispositivos autorizados como establecer barreras para el acceso no autorizado.
Autenticación del dispositivo
Al servir como una raíz de confianza para los dispositivos IoT, los mecanismos de criptografía de SE050 y las capacidades de almacenamiento seguro admiten directamente las conexiones seguras que se esperan en las comunicaciones con hosts remotos autorizados, como los servidores en la nube. De hecho, esas mismas capacidades permiten que los desarrolladores garanticen la autenticidad de las conexiones en los niveles más bajos de la jerarquía de IoT entre dispositivos IoT separados integrados en los elementos seguros SE050.
Empleando un método similar a la autenticación de Internet convencional, un sensor inteligente de IoT puede, por ejemplo, autenticarse a sí mismo en un dispositivo de control de IoT. Este proceso comienza cuando el dispositivo de detección envía al dispositivo de control el certificado almacenado en su almacenamiento seguro de SE050. El dispositivo de control a su vez valida el certificado recibido utilizando las características de cifrado de SE050. Tras una validación exitosa, el dispositivo de control envía un valor aleatorio, llamado desafío, al dispositivo sensor. Este, a su vez, utiliza su elemento seguro SE050 para firmar el desafío con la clave privada asociada con el mismo certificado que le envió antes al dispositivo de control. Debido a que ese desafío firmado solo se puede validar utilizando la clave pública asociada, el dispositivo de control está seguro de que el certificado que envió originalmente el dispositivo sensor es realmente propiedad de ese dispositivo. En consecuencia, el dispositivo de control puede autenticar de manera confiable el dispositivo sensor.
Al cambiar los roles en el mismo proceso, el dispositivo de control puede autenticarse a la inversa en el sensor.
Este tipo de proceso de autenticación mutua es esencial para construir redes IoT confiables, especialmente, ante la aparición de más capas intermedias, como los dispositivos informáticos de borde. Si el proceso de autenticación mutua es sencillo, incluso los errores de implementación simples o las diferentes interpretaciones del protocolo pueden dar lugar a graves fallas de seguridad. En los diseños de IoT con recursos limitados, en particular, la necesidad de contar con un almacenamiento seguro y una ejecución rápida de algoritmos criptográficos complejos puede complicar aún más la implementación confiable. Al agregar el SE050 a cualquier diseño de IoT, los desarrolladores pueden implementar características críticas de seguridad, como la autenticación mutua, sin comprometer el rendimiento ni la seguridad general del diseño.
Integración simple y segura
Como complemento a las capacidades avanzadas de SE050, está la facilidad de rediseño. Los desarrolladores pueden integrar fácilmente el dispositivo en sus diseños de hardware de IoT con un impacto mínimo en la complejidad del diseño o la huella. Diseñado para servir como un dispositivo de complemento, el dispositivo de 3 milímetros (mm) x 3 mm proporciona un conjunto simple de interfaces seriales (Figura 2).>
Figura 2: NXP SE050 SE proporciona múltiples interfaces, lo que permite su uso como esclavo I2C para conexiones con microcontroladores host, como maestro I2C para conexiones basadas en ISO 7816 con sensores digitales y como interfaz sin contacto de comunicación de campo cercano (NFC) ISO 14443. (Fuente de la imagen: NXP)
Para comunicarse con el microcontrolador host, el dispositivo sirve como esclavo I2C. SE050 también puede funcionar como maestro I2C para conexiones basadas en ISO 7816 con otro dispositivo en serie, como un sensor digital. El dispositivo también admite una tercera interfaz para conectividad sin contacto NFC ISO 14443.
Para sus diferentes conexiones, el applet IoT de SE050 organiza claves seguras y reglas de control de acceso para configurar y administrar las sesiones para cada conexión.
Para comunicarse con el host, SE050 proporciona autenticación basada en sesiones, concebida para evitar la intercepción de comandos I2C y datos, y la práctica de ataques de “hombre en el medio”. Para iniciar una sesión de conexión en serie, los desarrolladores pueden autenticarse con un ID de usuario, que funciona como una contraseña o un número de identificación personal (PIN).
La autenticación básica basada en contraseña entre el microcontrolador y SE050 no siempre es suficiente para algunas aplicaciones. Para aplicaciones críticas, es posible que los desarrolladores necesiten garantizar que las comunicaciones entre el microcontrolador host y SE050 SE sean confidenciales para evitar ataques que reproduzcan sesiones, envíen fragmentos de sesión fuera de servicio o sustituyan algoritmos criptográficos con versiones pirateadas destinadas a extraer datos confidenciales.
Transacciones seguras de bus
Con SE050 SE, los desarrolladores pueden usar métodos de autenticación para crear un canal de comunicaciones seguro entre SE050 y el microcontrolador host. Para tal fin, los desarrolladores pueden utilizar la compatibilidad del CI de SE050 con el estándar SCP03 del Protocolo de canal seguro (SCP), que es muy utilizado para asegurar las comunicaciones bidireccionales entre un dispositivo Java Card y un host.
Para diseños basados en microcontroladores integrados en SE050 SE, el uso del protocolo SCP03 básicamente vincula el SE050 SE al microcontrolador host durante la autenticación de la sesión del bus I2C, lo que permite usar mensajes cifrados durante la sesión. Para el cifrado de mensajes dentro del protocolo SCP03, el mensaje de texto sin formato se cifra primero utilizando el algoritmo AES y se genera un MAC para el mensaje cifrado. Al enviar tanto el mensaje cifrado como el MAC asociado, este método denominado "cifrado-luego-MAC" protege el mensaje cifrado y permite que el receptor detecte alteraciones en el mensaje.
SE050 también extiende una forma de protección a los datos del sensor. En este caso, los desarrolladores pueden solicitar al SE050 que aumente las respuestas a los comandos del host con metadatos de certificación, que incluyan un identificador único, datos de actualización en forma de un valor aleatorio para cada instancia, una marca de tiempo y una firma. Dentro del host, el software examina los datos de certificación recibidos del SE050 para validar la fuente y la oportunidad de los datos desde los sensores conectados a la interfaz maestra I2C de SE050.
A medida que los datos de los sensores individuales se combinan en flujos que circulan por la jerarquía de IoT, las aplicaciones pueden usar estos datos de certificación para identificar la fuente de patrones de datos inusuales que podrían indicar sensores dañados, fallados o comprometidos. Gracias a las sesiones de host SCP03 y a la certificación de datos del sensor, los desarrolladores pueden adquirir de manera confiable y segura los datos esenciales del sensor para las aplicaciones críticas.
Interfaz funcional
Las solicitudes y respuestas de certificación, como sucede en todas las interacciones entre el microcontrolador host y el SE050 SE, se transmiten por una pila de comunicación definida en los estándares de interfaz funcional ISO 7816 para dispositivos de tarjeta inteligente (Figura 3). Este estándar de Unidad de datos de protocolo de aplicación (APDU) define el formato, el contenido y el protocolo para el intercambio de mensajes entre un dispositivo host (HD) y un elemento seguro (SE).
Figura 3: Las comunicaciones entre un NXP SE050 SE y un HD se realizan a través de una pila estándar de tarjetas inteligentes ISO 7816, que comprenden solicitudes y respuestas a nivel de la aplicación mediante el estándar APDU ISO 7816, transmitido por una capa de enlace de datos que usa el protocolo semidúplex ISO 7816-3 T=1 sobre I2C. (Fuente de la imagen: NXP)
Partiendo de la capa física I2C, la capa de enlace de datos descompone las solicitudes y la respuesta de la capa de la aplicación en una secuencia de transacciones que siguen el protocolo ISO 7816-3 T=1 sobre I2C para la comunicación semidúplex. En este protocolo, la capa de enlace de datos en el HD y en el SE espera el acuse de recibo después de cada transmisión en una secuencia de transacción.
Por ejemplo, para una solicitud de lectura emitida por la aplicación de host, la capa de enlace de datos del host sondea primero el SE y espera una respuesta de confirmación (ACK), que indica que el SE está listo para enviar (Figura 4).
Figura 4: La capa de enlace de datos procesa las solicitudes del HD, incluida la solicitud de lectura que se muestra aquí, como una serie de transacciones que se ajustan al protocolo T=1 sobre I2C, y que comienzan con un bucle de sondeo que repite la solicitud hasta recibir una respuesta de confirmación (ACK), que indica que el SE está listo para transmitir datos. (Fuente de la imagen: NXP)
Después de la respuesta de confirmación (ACK), la capa de enlace de datos en el SE envía datos al host como una secuencia de transferencias de bloque de datos, y espera un acuse de recibo de la capa de enlace de datos del host para cada transferencia de bloque (Figura 5). Finalmente, se envía la respuesta completa a la aplicación host.
Figura 5: Después de indicar que está listo para enviar datos, el SE envía una respuesta de datos como una secuencia de bloques de datos y espera un acuse de recibo del HD antes de enviar el siguiente bloque en la secuencia. (Fuente de la imagen: NXP)
Implementación de software
A nivel de la aplicación, los intercambios entre el microcontrolador host y SE050 SE se llevan a cabo utilizando el estándar APDU ISO 7816. Para el SE050, los APDU para comandos y respuestas se basan en el formato de Etiqueta, Longitud, Valor (TLV) definido en ISO 7816-4. Como mínimo, cada APDU comprende un byte de clase (CLA) (un valor fijo para todas las operaciones de SE050), un byte de instrucción (INS) y dos bytes de parámetro (P1, P2). Las solicitudes y respuestas de datos también pueden incluir campos adicionales para el número de bytes que se leerán (Le), la longitud del campo de datos (Lc) y el campo de datos.
Por ejemplo, una solicitud de lectura de la aplicación host usaría un par de TLV para configurar la interfaz SE050 I2C y realizar la solicitud de lectura (Listado 1). Como se señaló anteriormente, la capa de enlace de datos del host descompone esta solicitud en una serie de transacciones de bus I2C de acuerdo con el protocolo T=1.
Copy static smStatus_t i2cm_Read( ex_sss_boot_ctx_t *pCtx, uint8_t *readbuf, uint32_t readLength) { smStatus_t status; TLV[0].type = kSE05x_I2CM_Configure; TLV[0].cmd.cfg.I2C_addr = I2C_SENSOR_BUS_ADDRESS; TLV[0].cmd.cfg.I2C_baudRate = kSE05x_I2CM_Baud_Rate_400Khz; TLV[1].type = kSE05x_I2CM_Read; TLV[1].cmd.rd.readLength = readLength; TLV[1].cmd.rd.rdBuf = readbuf; status = Se05x_i2c_master_txn(&pCtx->session, &TLV[0], 3); return status; }
Listado 1: El middleware NXP Plug & Trust incluye código fuente que demuestra el uso del formato TLV ISO 7816-4 en comandos de host como este comando de lectura básico para NXP SE050 SE. (Fuente del código: NXP)
Como se ejemplifica en el Listado 1, el código usa una estructura C simple para codificar los TLV para la configuración y las solicitudes de lectura. En el ejemplo, cada TLV se instancia usando una estructura SE05x_I2CM_cmd_t (Listado 2).
Copy typedef struct _SE05x_I2CM_cmd { SE05x_I2CM_TLV_type_t type; SE05x_I2CM_INS_type_t cmd; } SE05x_I2CM_cmd_t; typedef enum _SE05x_I2CM_TLV_type { kSE05x_I2CM_None = 0, kSE05x_I2CM_Configure, //kSE05x_I2CM_Security, kSE05x_I2CM_Write = 3, kSE05x_I2CM_Read, kSE05x_I2CM_StructuralIssue = 0xFF } SE05x_I2CM_TLV_type_t; typedef union _SE05x_I2CM_INS_type { SE05x_I2CM_configData_t cfg; SE05x_I2CM_securityData_t sec; SE05x_I2CM_writeData_t w; SE05x_I2CM_readData_t rd; SE05x_I2CM_structuralIssue_t issue; } SE05x_I2CM_INS_type_t; typedef struct _SE05x_I2CM_readData { uint16_t readLength; SE05x_I2CM_status_t rdStatus; /* Output. rdBuf will point to Host buffer */ uint8_t *rdBuf; } SE05x_I2CM_readData_t;
Listado 2: La distribución de software NXP Plug & Trust proporciona estructuras para definir el tipo de solicitud (resaltado en verde) y los parámetros de comando asociados (resaltado en azul). (Fuente del código: NXP)
Dentro de esa estructura SE05x_I2CM_cmd_t, el miembro de tipo se define mediante una enumeración C, SE05x_I2CM_TLV_type_t, que enumera los valores posibles, incluido el valor estándar 4 para una APDU de solicitud de lectura (kSE05x_I2CM_Read). El miembro cmd de la estructura SE05x_I2CM_cmd_t se define en una unión de estructuras. En este caso, el miembro cmd es una estructura rd, que a su vez comprende miembros que especifican la longitud de los datos solicitados (readLength) y el puntero del búfer de destino (rdBuf).
Este conjunto de definiciones se resume en unas pocas líneas de código que establecen el miembro de tipo de la instancia TLV [1] en el Listado 1, para indicar una solicitud de lectura (kSE05x_I2CM_Read) y establecer el miembro cmd en el readLength y puntero de búfer readBuf deseados.
Apoyo al desarrollo
Para simplificar el desarrollo de software, NXP sintetiza las interacciones del host con SE050 SE a través de su middleware Plug & Trust y las interfaces de programación de aplicaciones (API) de bibliotecas asociadas (Figura 6). El paquete de distribución de middleware NXP Plug & Trust combina middleware y API con un conjunto de aplicaciones de muestra integradas en mbed TLS, OpenSSL y otros paquetes. Además, una interfaz de línea de comandos (CLI) basada en Python permite a los desarrolladores usar las características de SE050 en un modo interactivo.
Figura 6: Junto con el software de muestra, el paquete de software NXP Plug & Trust incluye el middleware y las API asociadas que resumen los detalles de las interacciones con el SE050 a través de la pila basada en ISO 7816, que comprende la capa de aplicación APDU, T=1 sobre la capa de enlace de datos I2C y la capa física I2C. (Fuente de la imagen: NXP)
Junto con el software NXP Plug & Trust, los desarrolladores pueden evaluar rápidamente el SE050 utilizando el kit de desarrollo OM-SE050ARD, que combina un SE050 SE y un circuito de soporte simple con múltiples encabezados. Junto con los conectores para una interfaz externa I2C y acceso directo a los pines de SE050, la placa OM-SE050ARD incluye un encabezado Arduino-R3. Usando el encabezado Arduino-R3, los desarrolladores pueden conectar fácilmente la placa OM-SE050ARD con varias placas de desarrollo, incluida la placa de evaluación NXP I.MX 6ULTRALITE y la placa de evaluación NXP FRDM-K64F.
Con las placas de evaluación compatibles, los desarrolladores pueden explorar rápidamente casos de uso específicos para la seguridad, ya sea mediante programación a través de las muestras de software Plug & Trust o de manera interactiva a través de la CLI basada en Python. Entre las aplicaciones de muestra en la distribución de software Plug & Trust, el software de muestra ejemplifica el proceso completo para leer los datos del sensor de lectura a través de la interfaz maestra SE050 I2C. Los desarrolladores pueden reconstruir rápidamente esta aplicación de muestra para reemplazar las lecturas I2C convencionales con lecturas de certificación. El uso de lecturas de certificación no requiere cambios en la configuración de TLV que se muestra en el Listado 1. De hecho, los cambios implican en gran medida reemplazar la función de lectura I2C, Se05x_i2c_master_txn (), que se muestra en el Listado 1, con la versión de lectura certificada, Se05x_i2c_master_attst_txn (), junto con sus parámetros de función asociados.
Otras aplicaciones de muestra demuestran el paso final en términos de seguridad del borde a la nube: autenticación y comunicaciones seguras con servicios en la nube. En las muestras de software Plug & Trust, los desarrolladores pueden encontrar instrucciones paso a paso para usar el SE050 para proporcionar autenticación y conexiones seguras a los servicios de nube pública, como Microsoft Azure, IBM Watson, Amazon Web Services (AWS) y Google Cloud Platform (GCP). La mayor parte del esfuerzo implementado en estas muestras de conexión a la nube radica en crear una cuenta en el servicio en la nube respectivo y cargar claves y certificados (también incluidos en las rutinas de la muestra). SE050 SE se ocupa del trabajo pesado que los desarrolladores suelen necesitar implementar para garantizar una conectividad segura en la nube.
Al usar la pila de software NXP Plug & Trust en combinación con las placas de desarrollo NXP, los desarrolladores pueden aprovechar rápidamente el soporte integral de SE050 SE para la seguridad del borde a la nube para los dispositivos IoT.
Conclusión
Los dispositivos IoT con seguridad deficiente amenazan con exponer grandes volúmenes de datos confidenciales y pueden convertirse en puntos de entrada a otros recursos conectados. Los desarrolladores deben crear diseños de IoT sobre una base segura que se extienda desde el dispositivo hasta la nube y admita el ciclo de vida completo del dispositivo IoT. Como se mostró, esta condición se puede lograr al ampliar los diseños con el SE050 de NXP. Usando este SE, los desarrolladores pueden cumplir con los requisitos emergentes para una seguridad más efectiva, que se extienda desde el borde hasta la nube.
Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de DigiKey o de las políticas oficiales de DigiKey.


