Actualmente, es esencial disponer de sistemas embebidos de seguridad. Los maleantes pueden acceder a herramientas a un precio muy bajo, así que es muy común que exploren las vulnerabilidades de los dispositivos del IoT. Además, en el entorno actual existe un gran número de dispositivos conectados de forma remota, de modo que, si consiguen entrar en un solo dispositivo objetivo, pueden acceder a toda la instalación del IoT.

Introducción
El mundo actual está ultraconectado, un hecho que lo pone el punto de mira de los maleantes, ya que es un entorno global de dispositivos a los que querrán acceder. La seguridad de un dispositivo embebido es primordial para impedir que los hackers lo controlen, pero estos podrían incluso preparar un ataque más dañino en los sistemas conectados del dispositivo. Los ataques remotos, sin embargo, no son su única arma; los ataques locales al dispositivo de hardware físico son otra forma de obtener información secreta. Este tipo de agresiones incluye el acceso a las contraseñas de autenticación del sistema y hasta a la propiedad intelectual del propio código de la aplicación.

En este artículo repasaremos los conceptos básicos para disponer de una seguridad embebida, fiable y sólida en un microcontrolador embebido. Analizaremos principios de seguridad y veremos de cerca las superficies y los vectores de ataque que emplean aquellos con malas intenciones.

Imagen 1: en una instalación del IoT, cuando un solo dispositivo está en peligro, todo el sistema queda abierto al enemigo (fuente: STMicroelectronics)

El factor de la seguridad no debe subestimarse, sin importar el nivel de complejidad que vaya a añadir al sistema embebido. Además, el problema no se reduce a proteger claves criptográficas o firmware embebido, sino también datos personales. Si un jáquer obtiene acceso al firmware de un dispositivo, podría aplicar ingeniería inversa en el código y, si averigua cómo funciona, tendría la capacidad de detectar más vulnerabilidades e introducir código dañino. El acceso a un solo dispositivo desprotegido en un sistema IoT puede poner en peligro toda la instalación (ver imagen 1).

Qué debemos proteger
Antes de analizar las técnicas de seguridad, vamos a repasar y clasificar lo que debemos proteger. Los hackers tienen como objetivo tres aspectos diferentes en un dispositivo IoT. Un objetivo es un dispositivo IoT que debemos proteger. Un activo es la parte específica del objetivo que precisa de protección. En la imagen 2, podemos ver los activos que debemos proteger y los riesgos relacionados dentro de cada objetivo en caso de que haya sido afectado. En lo referente a la implementación de técnicas de seguridad embebida, esta clasificación nos ayuda a seleccionar el método adecuado.

Imagen 2: la clasificación de objetivos, activos y riesgos relacionados nos ayuda a determinar los métodos de seguridad que debemos implementar (fuente: STMicroelectronics)

Tipos de ataques
Los ataques contra dispositivos IoT pueden tener distintos orígenes y, en términos generales, se pueden dividir en ataques contra software y hardware. Los ataques contra el software de un dispositivo se pueden producir de manera local o a través de una red conectada, mientras que los ataques contra el hardware se pueden dividir, a su vez, en invasivos y no invasivos. Un ataque no invasivo tiene lugar de manera local y solo requiere una conexión eléctrica a la placa de circuito impreso del dispositivo IoT en algunas ocasiones.

Por otro lado, un ataque del hardware invasivo supone un acceso eléctrico y físico al microcontrolador del dispositivo. Por lo general, un ataque invasivo es el método más costoso y el hacker necesita conocimientos especializados para ponerlo en marcha. En la imagen 3, podemos ver los tres tipos de ataques mencionados, junto con un resumen de la técnicas empleadas y de los motivos por los que un hacker podría usarlos.

Imagen 3: tipos de ataques y coste asociado (fuente: STMicroelectronics)

Los ataques contra software suelen ser los más comunes y consisten en aprovechar errores en el firmware o debilidades conocidas del protocolo a través de los canales de comunicación del dispositivo. Estos ataques tienen un coste relativamente bajo y son fáciles de implementar, ya que se ejecutan de forma remota. Además, es posible que, tras descubrir las vulnerabilidades de un dispositivo, los hackers compartan este conocimiento en su comunidad.

La seguridad en escenarios reales
Para un fabricante de dispositivos, es importante comprender los factores que contribuyen a la seguridad a fin de valorar qué funciones de protección serán necesarias. En los siguientes tres ejemplos, veremos algunas de estas funciones. En la siguiente sección, hablaremos sobre muchas funciones de seguridad y la manera de implementarlas.

Ejemplo 1
Imaginemos una empresa que vende firmware y que tiene como fuente principal de ingresos los derechos de las licencias. Ese firmware es un valioso activo de propiedad intelectual (PI) y debe protegerse. Los clientes usan el firmware junto con el código de la aplicación. Para la empresa, es necesario aislar el firmware del código del cliente. La empresa actualiza el firmware de manera periódica, así que también es necesario instalar y actualizar el firmware de un modo seguro. En este caso, algunas de las funciones de seguridad necesarias serían el aislamiento, la protección de la PI del software y las rutinas seguras para la instalación y actualización del firmware.

Ejemplo 2
La empresa IndustrialAdvantage vende equipos de control de producción a un precio elevado y desea ofrecer actualizaciones de firmware a sus clientes. Una de las condiciones es que, en el equipo suministrado, solo se pueda ejecutar firmware de IndustrialAdvantage. El proceso de actualización debe ser cuidadoso y disponer de comprobaciones de autenticidad. Para asegurarnos de que el equipo solo ejecuta firmware de IndustrialAdvantage, podemos usar la función de arranque seguro. La función de instalación y actualización segura nos permitirá llevar a cabo comprobaciones de integridad y autenticidad. 

Ejemplo 3
Consumer Tech fabrica dispositivos para recabar datos de usuario en el contexto de un sistema más amplio. La empresa cumple con cuidado y en todo momento con las normativas sobre datos de consumidores, como el RGPD. Consumer Tech también quiere asegurarse de que el comportamiento del dispositivo sea sólido y de que solo ejecute el firmware de la empresa. Durante la comunicación del dispositivo con el sistema host, existe la posibilidad de que los datos de los usuarios queden al descubierto; el uso de técnicas de cifrado y de sistemas de identificación y autenticación de dispositivos puede evitar esa vulnerabilidad. La integridad de la plataforma está protegida gracias a una función de arranque seguro.

El marco de seguridad
Para el desarrollador de sistemas embebidos, es imprescindible disponer de un conjunto completo y sólido de funciones de seguridad para la plataforma del microcontrolador de un dispositivo. Un ejemplo de esto es el ecosistema STM32Trust para la serie de microcontroladores STM32 de STMicroelectronics (ver imagen 4).

Imagen 4: ecosistema de funciones de seguridad STM32Trust (fuente: STMicroelectronics)

Las funciones de seguridad del STM32Trust se utilizan en las series de microcontroladores STM32L4 y STML5, con las certificaciones Arm PSA (nivel 2) y SESIP (nivel 3). Las funciones de seguridad se pueden embeber en el silicio del microcontrolador o como firmware, y están asociadas al dispositivo correspondiente.

En el resto del artículo, vamos a analizar dos funciones de seguridad esenciales que están incluidas en el ecosistema STM32Trust y de las que hemos hablado en los ejemplos anteriores: el arranque seguro (SB) y la instalación/actualización segura (SBSFU).

Arranque seguro
El principio básico del arranque seguro es que, al reiniciar un dispositivo, se ejecuta un código de arranque seguro que verifica si el firmware es auténtico antes de permitir el inicio. Esta función se basa en dos parámetros. En primer lugar, el código de arranque seguro es el único que se ejecuta en el reinicio. En segundo lugar, ese código es inalterable; es decir, no se puede modificar en modo alguno. La dirección del código de arranque también es exclusiva, lo que evita que se pueda acceder a una dirección de firmware diferente en el reinicio. La combinación de estos dos principios crea una raíz de confianza para el dispositivo (ver imagen 5).

Imagen 5: principio básico de la función de arranque seguro (fuente: STMicroelectronics)

Se llevan a cabo comprobaciones de integridad y autenticidad en el firmware de la aplicación y se comparan con una firma. La comprobación de integridad compara una función «hash» (también llamada «digest») generada desde el código de la aplicación con una referencia suministrada. La comprobación de autenticidad hace la comparación con una firma computada desde el valor «hash» generado y una clave privada. A continuación, la firma se verifica con una clave pública asociada. El valor de la firma y del «hash» de referencia debe suministrarse junto con el firmware.

Normalmente, se almacena en un contenedor, llamado metadatos o encabezado (ver imagen 6). Debido a su método de generación, los metadatos no requieren cifrado. Si hubiera un firmware dañino, no sería posible lograr que el «hash» del firmware coincidiera con la referencia. En la imagen 6, podemos ver la construcción de la firma de los metadatos mediante la clave privada y el «digest» del firmware con función «hash».

Imagen 6: generación de la firma de los metadatos (fuente: STMicroelectronics)

En la imagen 7, el código de arranque seguro utiliza la firma de los metadatos para confirmar el estado de la autenticidad e integridad del firmware de la aplicación. Si la verificación de la firma resulta en un firmware válido, el proceso de arranque empieza a cargar el código de la aplicación. Si hay diferencias con el firmware de la aplicación o la firma, el arranque no se lleva a cabo.

Imagen 7: validación del firmware de la aplicación mediante la firma de los metadatos antes de cargar la aplicación (fuente: STMicroelectronics)

Actualización segura del firmware
Las etapas más importantes en la actualización del firmware son las siguientes:
• creación de la actualización del firmware de la aplicación,
• generación de los metadatos asociados y
• transmisión al dispositivo de destino.
• La función de arranque seguro utiliza los metadatos para comprobar la integridad y autenticidad del firmware de la aplicación.
• Si la comprobación es correcta, el proceso de arranque seguro instala el nuevo firmware.

La nueva firma de los metadatos se crea usando la misma técnica que para el arranque seguro. En muchos dispositivos del IoT/IIoT conectados de forma remota, el método de transferencia más simple es una actualización OTA (inalámbrica). Los dispositivos sin conexión a Internet necesitan una conexión local, como UART, SPI, USB o una tarjeta microSD. El nuevo firmware de la aplicación se instala en una memoria flash en el dispositivo de destino con un cargador, que suele incluirse en el código de arranque seguro o en el firmware de la aplicación. El nuevo firmware se debe instalar de manera local mientras el firmware actual se ejecuta.

La imagen 8 muestra el proceso de actualización remota del firmware. Hacen falta dos ranuras de memoria, para el firmware actual y para la nueva versión. 

Imagen 8: ejemplo de actualización remota del firmware (fuente: STMicroelectronics)

La última etapa del proceso de actualización consiste en comprobar el nuevo firmware de la aplicación (ver imagen 9). Si se aprueba la comprobación de los metadatos, se produce el intercambio del firmware actual por el nuevo. La actualización ha finalizado.

Conclusión
La seguridad embebida en los dispositivos no es opcional. Todos los dispositivos deben estar protegidos frente a ataques dañinos y posibles vulnerabilidades. La seguridad del dispositivo empieza en el arranque, así que es vital incorporar funciones de seguridad como el arranque seguro y la instalación/actualización segura de firmware. STM32Trust ofrece todas las funciones de seguridad que un desarrollador de sistemas embebidos puede necesitar a fin de proteger sus dispositivos y cumplir con la normativa vigente.

Artículo cedido por Mouser Electronics