USD

Fundamentos de seguridad de la IoT - Parte 3: Garantizar el arranque seguro y la actualización del firmware

Por Stephen Evanczuk

Colaboración de Editores de Digi-Key de América del Norte

Nota del editor: A pesar de la proliferación de dispositivos de IoT, la seguridad de estos dispositivos sigue siendo una preocupación constante, hasta el punto de que los desafíos de seguridad pueden ser una barrera para la adopción de dispositivos conectados en IoT industrial (IIoT) y aplicaciones de misión crítica donde los datos corporativos y personales pueden verse comprometidos en caso de un ataque exitoso. La seguridad de las aplicaciones de IoT puede ser desalentadora, pero en realidad la seguridad de los dispositivos de IoT se puede construir sobre unos pocos principios relativamente sencillos que se apoyan en los dispositivos de seguridad del hardware. Siguiendo prácticas de seguridad bien establecidas, se pueden abordar estas preocupaciones. Esta serie, que consta de varias partes, ofrece orientación práctica para ayudar a los promotores a asegurarse de que se sigan las mejores prácticas desde el principio. En la Parte 1, se analizan los algoritmos criptográficos que subyacen a los diseños seguros. En la Parte 2, se analiza el papel de las claves privadas, la administración de claves y el almacenamiento seguro en los diseños de IoT segura. En la Parte 3, se examinan los mecanismos incorporados en los procesadores seguros para mitigar otros tipos de amenazas a los dispositivos de IoT. En la Parte 4, se identifica y muestra cómo aplicar mecanismos de seguridad en los procesadores avanzados para ayudar a asegurar el aislamiento necesario para mitigar los ataques al entorno de ejecución de los dispositivos de IoT. En la Parte 5, se describe cómo la seguridad de la IoT continúa desde los dispositivos de IoT a través de medidas de seguridad de mayor nivel utilizadas para conectar esos dispositivos a los recursos de la nube de IoT.

Al utilizarse juntos, la criptografía basada en hardware y el almacenamiento seguro proporcionan las capacidades esenciales necesarias para poner en práctica diseños seguros de la Internet de las cosas (IoT). Sin embargo, una vez desplegados, los dispositivos de IoT se enfrentan a múltiples amenazas diseñadas para subvertir esos dispositivos, para lanzar ataques inmediatos o para amenazas persistentes más sutiles y avanzadas.

Este artículo describe cómo los desarrolladores pueden mejorar la seguridad en los dispositivos de IoT, utilizando una raíz de confianza que se basa en los mecanismos de seguridad subyacentes para proporcionar un entorno de confianza para la ejecución de software en procesadores seguros de Maxim Integrated, Tecnología de microchips, NXP Semiconductores y Silicon Labs, entre otros.

¿Qué es la raíz de la confianza y por qué se necesita?

Los métodos criptográficos y las claves de seguridad son elementos fundamentales para la seguridad de cualquier dispositivo conectado. Como se ha señalado en la Parte 1 y la Parte 2 de esta serie, proporcionan mecanismos fundamentales utilizados por los protocolos de nivel superior para proteger los datos y las comunicaciones. La protección del propio sistema requiere que los desarrolladores tengan en cuenta las vulnerabilidades que pueden afectar al funcionamiento del sistema y a la ejecución del software en los sistemas incorporados.

En un sistema incorporado típico, un reinicio del sistema debido a un fallo de alimentación o a una excepción crítica del software, eventualmente se activa el proceso de arranque del software para recargar una imagen del firmware desde la memoria no volátil. Normalmente, el reinicio del software es un importante mecanismo de seguridad que se utiliza para restablecer el funcionamiento de un sistema que se ha desestabilizado accidental o intencionadamente. En los sistemas conectados, en los que los hackers utilizan diversas herramientas de sombrero negro para comprometer el software, los especialistas en seguridad suelen recomendar el reinicio para contrarrestar las intrusiones que afectan a la ejecución del software. Por ejemplo, en 2018 el FBI recomendó que los consumidores y los propietarios de negocios reiniciaran sus routers para frustrar una campaña masiva de piratería informática que estaba en marcha.

En la práctica, el reinicio no garantiza la integridad del sistema. Después de reiniciar con una imagen de firmware comprometida, el sistema sigue bajo el control del hacker. Para mitigar este tipo de amenazas, los desarrolladores necesitan asegurarse de que su software se ejecuta en una cadena de confianza que se basa en una raíz de confianza establecida en el momento del arranque y que se extiende a través de todas las capas del entorno de ejecución del software. La capacidad de alcanzar este nivel de seguridad depende fundamentalmente de que se asegure que el proceso de arranque se inicie con un firmware de confianza.

Verificar las imágenes del firmware para un arranque seguro

En un sistema integrado, el procesador host carga una imagen de firmware de la flash en la memoria principal y comienza a ejecutarla (o comienza a ejecutarla directamente desde la flash con capacidad de ejecución en el lugar (XIP)). Si los hackers han comprometido la imagen del firmware, el proceso de arranque resulta en un sistema comprometido.

Para verificar la integridad del firmware antes de arrancar con él, los desarrolladores utilizan un proceso de firma de código que comienza al principio de la cadena de suministro. Dentro de una instalación segura, la imagen del firmware del sistema se firma con una clave privada de un par de claves privadas-públicas creadas con un algoritmo criptográficamente sólido, como el Algoritmo de Firma Digital de Curva Elíptica (ECDSA). Aunque la llave privada nunca sale de la instalación, la llave pública del sistema se envía con el sistema. Durante el arranque, el procesador aplica esta clave pública del sistema para verificar la firma del firmware antes de usar la imagen.

Por supuesto, el proceso que se acaba de describir deja la propia clave pública vulnerable y, por extensión, deja el firmware del sistema vulnerable a la sustitución no autorizada. Si la clave pública permanece desprotegida en el sistema incorporado, los piratas informáticos podrían sustituirla por una clave pública de un par de claves privadas-públicas generadas por ellos mismos. Si reemplazan la imagen del firmware del sistema por un firmware malicioso firmado con la clave privada asociada en su posesión, la firma del firmware comprometido pasa el proceso de verificación y el proceso de arranque procede, resultando en un sistema comprometido.

Por esta razón, los sistemas seguros se basan en una clave pública válida que se suministra en un elemento seguro dentro de la instalación de seguridad. Los circuitos integrados de seguridad como el DS28C36 de Maxim Integrated y el ATECC608A de Microchip Technology proporcionan tanto el almacenamiento seguro de un elemento seguro tradicional, como la ejecución segura de algoritmos de autenticación -como el ECDSA- para la verificación de la firma del firmware.

Antes de arrancar, el procesador host puede enviar el firmware a través de una interfaz serial al DS28C36, por ejemplo. A su vez, el DS28C36 utiliza la clave pública del sistema proporcionada anteriormente en la instalación segura para verificar que la firma del firmware se creó efectivamente con la clave privada asociada en la misma instalación segura. Finalmente, el DS28C36 señala el resultado de la verificación al procesador host, que procede a cargar la imagen del firmware si la firma es válida (Figura 1).

Diagrama de del CI de seguridad de DS28C36 de Maxim IntegratedFigura 1: Los desarrolladores pueden usar CI de seguridad como el DS28C36 de Maxim Integrated para verificar las firmas del firmware para evitar que el procesador del host arranque el firmware comprometido. (Fuente de la imagen: Maxim Integrated).

Un proceso de arranque más seguro protege la imagen del firmware para eliminar cualquier preocupación sobre claves o imágenes comprometidas. Al utilizar almacenamiento seguro y aceleradores de criptografía, se incorporan efectivas capacidades de arranque seguro en un número creciente de procesadores, incluyendo los procesadores Gecko Serie 2 de Silicon Laboratories,LPC55S69JBD100 de NXP, MAX32520 de Maxim Integrated y ATSAML11D16A de Microchip Technology, entre otros. Al usar estas capacidades, esta clase de procesadores seguros puede proporcionar la raíz de la confianza necesaria para crear un entorno de confianza para la ejecución del software de sistemas y aplicaciones.

Proporcionar una base de confianza a través de un arranque seguro

Los procesadores seguros de esta clase proporcionan opciones de arranque seguro diseñadas para asegurar la integridad de la imagen del firmware que subyace en la raíz de la confianza. Por ejemplo, los procesadores EFR32MG21A y EFR32BG22 Gecko Serie 2 de Silicon Laboratories construyen esta base de confianza a través de un proceso de arranque en varias etapas basado en un elemento seguro de hardware y un elemento seguro virtual (VSE), respectivamente (Figura 2).

Diagrama del procesador Gecko Series 2 EFR32MG21A de Silicon LaboratoriesFigura 2: El procesador Gecko Series 2 EFR32MG21A de Silicon Laboratories utiliza un elemento seguro de hardware integrado en la primera etapa de su proceso de arranque multietapa (que se muestra aquí), mientras que el EFR32BG22 inicia su proceso de arranque multietapa con un elemento seguro virtual. (Fuente de la imagen: Silicon Laboratories)

En el EFR32MG21A, un núcleo de procesador dedicado proporciona funcionalidad criptográfica junto con un elemento de hardware seguro para el almacenamiento seguro de la clave. Con el apoyo de esta capacidad dedicada, el procesador inicia el proceso de arranque utilizando el código almacenado en la memoria de solo lectura (ROM) para verificar el código del cargador de arranque de la primera etapa (FSB). Una vez verificado, se ejecuta el código FSB, que a su vez verifica la firma del código del cargador de la segunda etapa (SSB). La secuencia de arranque continúa con la ejecución del SSB verificado, que a su vez verifica la firma del código de aplicación, que generalmente incluye tanto el código de nivel de sistema como el código de aplicación de nivel superior. Por último, se ejecuta el código verificado de la aplicación, y las operaciones del sistema proceden según lo requerido por la aplicación.

Debido a que este proceso comienza con el código de la ROM y solo se ejecuta el FSB, el SSB y el código de la aplicación verificados, este enfoque resulta en una cadena de confianza verificada para la ejecución del código. Debido a que el primer eslabón de esta cadena de confianza se basa en el código ROM que no puede ser modificado, cada eslabón subsiguiente de la cadena extiende este entorno de confianza. Al mismo tiempo, este enfoque permite a los desarrolladores actualizar con seguridad el código de la aplicación, e incluso el código del cargador de arranque de primera y segunda etapa. Mientras cada paquete de códigos proporcione una firma verificada, el entorno de confianza permanece intacto.

Los procesadores que proporcionan este tipo de arranque seguro con una base de confianza suelen soportar múltiples modos y opciones. Por ejemplo, los procesadores Gecko Serie 2 de Silicon Laboratories proporcionan una capacidad de arranque seguro más fuerte basada en certificados.

Utilizados en las transacciones rutinarias de infraestructura de clave pública (ICP), los certificados contienen la clave pública junto con una referencia a uno o más certificados asociados que en última instancia apuntan a un certificado raíz concedido por una autoridad de certificación (AC). Cada certificado de esta cadena sirve para verificar el o los certificados que se encuentran debajo de él, lo que da lugar a una cadena de confianza basada en una CA digna de confianza. Los navegadores confían en esta cadena de confianza durante la fase de autenticación de la Seguridad de la Capa de Transporte (TLS) para confirmar la identidad de los servidores web. De la misma manera, los sistemas incorporados pueden utilizar certificados para confirmar la identidad de la fuente del cargador de arranque o del código de aplicación. En este caso, el proceso de arranque en varias etapas procede como se ha descrito anteriormente, pero con una verificación adicional del certificado asociado a cada etapa (Figura 3).

Diagrama de los procesadores Gecko Series 2 de Silicon Laboratories (haga clic para ampliar)Figura 3: Los procesadores Gecko Serie 2 de Silicon Laboratories mejoran la seguridad del sistema verificando los certificados de las claves públicas utilizadas durante la verificación de la firma en cada etapa del proceso de arranque. (Fuente de la imagen: Silicon Laboratories)

Otros procesadores, como el LPC55S69JBD100 de NXP, admiten varias opciones diferentes para la imagen del firmware. Además de las imágenes de firmware firmadas, estos procesadores admiten imágenes de arranque utilizando el estándar de la industria del motor de composición de identificadores de dispositivos (DICE) del Trusted Computing Group. Una tercera opción permite a los desarrolladores almacenar imágenes en regiones especiales de flash del procesador que soportan el cifrado PRINCE, que es un cifrado en bloque de baja latencia que puede lograr una fuerza de seguridad comparable a la de otros cifrados, pero en un área de silicio mucho más pequeña. Al implementarse en el LPC55S69JBD100, el cifrado PRINCE puede realizar el descifrado sobre la marcha del código cifrado o de los datos almacenados en las regiones PRINCE dedicadas de flash del procesador. Debido a que las claves secretas utilizadas para el descifrado solo son accesibles para el motor de criptografía PRINCE, este proceso de descifrado permanece seguro. De hecho, esas claves secretas están protegidas por una clave de cifrado de claves (KEK) generada por la función física de función no clonable (PUF) del LPC55S69JBD100. (Para más información sobre el uso del PUF y el KEK, ver la Parte 2.)

Este enfoque proporciona a los desarrolladores la capacidad de almacenar imágenes de firmware adicionales, una capacidad necesaria para proporcionar a los dispositivos de IoT con métodos de actualización de firmware por aire (FOTA) sin el riesgo de "bloquear" el dispositivo. Si el procesador solo puede utilizar una ubicación para almacenar imágenes de firmware, una imagen de firmware defectuosa puede enviar al procesador a un estado indeterminado o bloqueado que bloquea, o bloquea, el dispositivo. Al almacenar imágenes de firmware en las regiones flash habilitadas para PRINCE del LPC55S69JBD100, los desarrolladores pueden utilizar estrategias de retroceso que restauran una versión anterior de trabajo del firmware si la nueva versión se inicia en un estado no funcional.

Debido a que todas estas nuevas imágenes de firmware deben pasar los controles de verificación de firmas requeridos en el proceso de arranque subyacente, los desarrolladores pueden aprovechar al máximo la seguridad de FOTA para añadir nuevas características o corregir errores sin que ello afecte al sistema o a su cadena de confianza.

Conclusión

La seguridad a nivel de sistema y de aplicación requiere un entorno de ejecución que solo permita el funcionamiento de software autorizado. Aunque la verificación de la firma del código es una característica esencial para hacer posible este tipo de entorno, los sistemas seguros deben recurrir a un conjunto más amplio de capacidades para crear la cadena de confianza necesaria para garantizar la ejecución de programas informáticos fiables. La base de estos entornos de confianza reside en una raíz de confianza proporcionada a través de mecanismos de arranque seguros apoyados por procesadores seguros. Al usar esta clase de procesadores, los desarrolladores pueden implementar dispositivos seguros de IoT capaces de soportar ataques destinados a paralizar la ejecución del software en un sistema o secuestrar el sistema por completo.

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 Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Acerca de este autor

Stephen Evanczuk

Stephen Evanczuk tiene más de 20 años de experiencia escribiendo para y sobre la industria de electrónica en un amplio rango de temas, entre ellos hardware, software, sistemas y aplicaciones, que incluyen IoT. Se doctoróen neurociencias (redes neuronales) y trabajó en la industria aeroespacial en sistemas seguros con distribución masiva y métodos de aceleración de algoritmos. Actualmente, cuando no escribe artículos sobre tecnología e ingeniería, trabaja en aplicaciones de aprendizaje profundo sobre sistemas de reconocimiento y recomendaciones.

Acerca de este editor

Editores de Digi-Key de América del Norte