Ciberseguridad en el diseño electrónico: por qué debe plantearse desde el hardware

Cuando pensamos en la ciberseguridad de un dispositivo electrónico, es habitual pensar primero en el software.

Cifrado de comunicaciones, contraseñas, autenticación, actualizaciones de firmware o protección de servidores son algunos de los elementos que solemos asociar inmediatamente con la seguridad.

Sin embargo, en un dispositivo conectado la seguridad empieza mucho antes.

La selección del microcontrolador, la arquitectura de memoria, el almacenamiento de claves, las interfaces de comunicación, los mecanismos de arranque y hasta la posibilidad de acceder físicamente a la placa pueden determinar qué nivel de protección puede alcanzar finalmente el producto.

Esto es especialmente importante en equipos IoT, dispositivos industriales, sistemas de control, equipos conectados a la nube y productos que permanecen instalados durante muchos años.

La seguridad de un dispositivo conectado no empieza cuando se escribe la primera línea de firmware, sino cuando se define su arquitectura electrónica.

Cada dispositivo conectado tiene una superficie de ataque. Y cuanto más conectividad, memoria, interfaces y funcionalidades incorpora, más importante resulta diseñar esa superficie desde el principio.

En este artículo veremos cómo incorporar la ciberseguridad al diseño electrónico, desde la selección del microcontrolador hasta el almacenamiento de claves, el secure boot, las actualizaciones de firmware, la protección física y la gestión del ciclo de vida del producto.

En el interior del dispositivo encontramos el microcontrolador o procesador, la memoria donde se almacenan el firmware y los datos, las interfaces de comunicación y, dependiendo del producto, tecnologías como Wi-Fi, Bluetooth, Ethernet, 4G o 5G. A esto se suman los puertos utilizados durante el desarrollo y la depuración, los sensores y actuadores, el almacenamiento y los mecanismos encargados de actualizar el firmware.

Cada uno de estos elementos puede introducir una vía de acceso al sistema. Una interfaz de comunicación puede convertirse en un punto de entrada para un ataque remoto, mientras que una memoria sin protección puede exponer información sensible. Del mismo modo, un puerto de depuración que permanece accesible en el producto final puede proporcionar capacidades que eran necesarias durante el desarrollo, pero que ya no deberían estar disponibles en un dispositivo comercial.

Además, no todos los ataques tienen que realizarse a través de Internet. Si un atacante consigue acceso físico al dispositivo, puede intentar utilizar las interfaces de depuración, extraer información de la memoria, modificar el firmware o analizar la propia placa en busca de puntos débiles.

Por este motivo, la seguridad no debería plantearse únicamente como una función del firmware o de la aplicación que se ejecuta sobre el dispositivo. El hardware determina qué interfaces existen, qué información puede almacenarse, cómo se protegen las claves y qué mecanismos de seguridad puede proporcionar el propio microcontrolador.

La ciberseguridad de un dispositivo conectado empieza, por tanto, en su arquitectura electrónica. Las decisiones tomadas al seleccionar el microcontrolador, definir las memorias, incorporar interfaces o diseñar la PCB pueden condicionar las posibilidades de protección del producto durante todo su ciclo de vida.

Un dispositivo conectado tiene una superficie de ataque

Antes de diseñar las medidas de seguridad de un dispositivo conectado, es necesario entender por dónde podría intentar acceder un atacante. La superficie de ataque no está formada únicamente por la conexión a Internet. Cualquier interfaz que permita intercambiar datos, acceder a la memoria, modificar el firmware o interactuar con el hardware puede convertirse en un punto relevante desde el punto de vista de la seguridad.

En una placa pueden coexistir interfaces inalámbricas como Wi-Fi o Bluetooth, conexiones de red como Ethernet, puertos USB y buses internos como UART, SPI o I²C. También pueden existir interfaces de programación y depuración como JTAG o SWD, además de conexiones destinadas al almacenamiento, a sensores externos o a la actualización del firmware.

Sin embargo, la presencia de una interfaz no significa por sí misma que exista una vulnerabilidad. Lo importante es qué puede hacerse a través de ella, quién puede acceder y en qué momento del ciclo de vida del producto permanece disponible.

Por ejemplo, una UART puede ser perfectamente necesaria durante el desarrollo para cargar firmware, obtener registros de diagnóstico o depurar determinados problemas. Durante la fabricación puede resultar incluso útil para realizar pruebas automáticas. El problema aparece cuando esa misma interfaz permanece accesible y sin protección en el producto que finalmente recibe el cliente.

Algo similar ocurre con JTAG o SWD. Estas interfaces proporcionan un nivel de acceso muy profundo al microcontrolador y son herramientas fundamentales durante el desarrollo, pero en un dispositivo comercial pueden representar un riesgo si permiten acceder directamente a la memoria o modificar el firmware sin ningún mecanismo de autenticación o bloqueo.

Por este motivo, la seguridad debe analizarse teniendo en cuenta todo el ciclo de vida del producto. Una interfaz puede ser necesaria durante el desarrollo y, sin embargo, tener que deshabilitarse, bloquearse o protegerse cuando el dispositivo pasa a producción.

La pregunta que debería hacerse el diseñador no es únicamente qué interfaces tiene la placa, sino qué funciones de acceso necesita realmente el producto y cuáles deben seguir disponibles cuando llegue al cliente.

Esta distinción es especialmente importante en dispositivos IoT, donde una misma PCB puede combinar comunicaciones inalámbricas, conexiones externas, interfaces de mantenimiento y diferentes mecanismos de actualización. Cuantas más vías de acceso existan, más importante resulta definir claramente qué nivel de confianza requiere cada una y qué operaciones puede realizar.

Tradicionalmente, elegir un microcontrolador significa comparar su capacidad de procesamiento, memoria Flash y RAM, consumo, número de GPIO, periféricos, interfaces de comunicación y coste. Estos parámetros siguen siendo fundamentales, pero en un producto conectado existe otra cuestión que puede ser igual de importante: qué capacidades de seguridad incorpora el propio microcontrolador.

Los microcontroladores actuales pueden integrar mecanismos que permiten construir una cadena de confianza desde el arranque del dispositivo. Funciones como Secure Boot, Hardware Root of Trust, aceleradores criptográficos, generación de números aleatorios o protección de memoria permiten que determinadas operaciones críticas se realicen dentro del propio hardware, reduciendo la dependencia de mecanismos implementados únicamente mediante software.

Por ejemplo, Secure Boot permite establecer un proceso de arranque en el que el dispositivo comprueba que el firmware que va a ejecutar es auténtico antes de confiar en él. La protección de memoria puede limitar el acceso de determinadas partes del sistema a zonas concretas, mientras que los aceleradores criptográficos permiten realizar determinadas operaciones de cifrado y autenticación sin depender exclusivamente de implementaciones software.

También es importante analizar cómo gestiona el microcontrolador la información sensible. Un dispositivo conectado puede necesitar almacenar claves criptográficas, certificados, credenciales o información utilizada para autenticarse frente a un servidor. Si el microcontrolador dispone de mecanismos de almacenamiento protegido o de funciones específicas para impedir el acceso no autorizado a determinadas regiones de memoria, estas capacidades pueden simplificar considerablemente la arquitectura de seguridad.

Lo mismo ocurre con las interfaces de depuración. Durante el desarrollo, JTAG o SWD son herramientas esenciales para programar y analizar el funcionamiento del firmware. Sin embargo, el microcontrolador debería ofrecer mecanismos que permitan controlar o deshabilitar estos accesos cuando el producto pasa a producción.

Por tanto, dos microcontroladores con unas prestaciones similares en cuanto a CPU, memoria y periféricos pueden ofrecer posibilidades de seguridad muy diferentes. Esa diferencia puede terminar afectando a la arquitectura completa del producto, al firmware necesario y a la forma de proteger las actualizaciones y los datos sensibles.

Por eso, en un dispositivo conectado la pregunta ya no debería ser únicamente “¿qué microcontrolador tiene las prestaciones que necesitamos?”. También es necesario plantearse “¿qué mecanismos de seguridad proporciona y cómo encajan en la arquitectura que queremos construir?”.

Esta decisión es especialmente importante porque cambiar de microcontrolador cuando la PCB y el firmware ya están desarrollados puede implicar modificaciones importantes. Definir los requisitos de seguridad antes de cerrar la selección del componente permite elegir una plataforma que pueda soportar la estrategia de protección prevista para todo el ciclo de vida del producto.

Uno de los conceptos que está adquiriendo cada vez más importancia es el Hardware Root of Trust.

Podemos entenderlo como una base de confianza sobre la que se construyen otros mecanismos de seguridad del dispositivo.

La idea fundamental es que determinados elementos críticos de seguridad se apoyen en mecanismos hardware que sean más difíciles de modificar o manipular.

Por ejemplo, el sistema puede utilizar una clave, una identidad o un mecanismo de verificación protegido para comprobar que el software que se ejecuta es el esperado.

Esto permite construir una cadena de confianza desde el hardware hasta el firmware y, posteriormente, hasta las aplicaciones que se ejecutan sobre el dispositivo.

El concepto es especialmente interesante en dispositivos IoT porque permite establecer una identidad y una base de confianza desde las primeras etapas del arranque.

Uno de los mecanismos más importantes es el Secure Boot.

Su objetivo es impedir que el dispositivo ejecute firmware que no haya sido autorizado.

El funcionamiento conceptual puede representarse así:

Durante el arranque se verifica la autenticidad o integridad del software antes de ejecutarlo.

Esto resulta especialmente importante si un atacante consigue modificar el firmware almacenado en el dispositivo.

Sin un mecanismo de arranque seguro, una actualización maliciosa o una manipulación de la memoria podrían permitir ejecutar código no autorizado.

El cifrado solamente es útil si las claves utilizadas para realizarlo están correctamente protegidas.

Este es uno de los puntos donde la arquitectura hardware adquiere especial importancia.

Guardar una clave sensible como una cadena de texto dentro del firmware puede ser una solución muy débil.

Si un atacante consigue extraer el firmware, podría intentar localizar esa clave.

Por eso, determinados microcontroladores y componentes de seguridad permiten proteger las claves mediante mecanismos específicos de hardware.

Dependiendo de la arquitectura podemos utilizar:

• Secure elements.
• Almacenamiento seguro integrado.
• Regiones de memoria protegidas.
• Hardware criptográfico.
• Claves derivadas.
• Identidades únicas del dispositivo.

El objetivo es que una clave crítica no pueda extraerse simplemente leyendo la memoria del microcontrolador.

Un Secure Element es un componente diseñado específicamente para realizar determinadas operaciones relacionadas con seguridad y proteger información sensible.

Puede utilizarse, por ejemplo, para almacenar claves privadas y realizar operaciones criptográficas sin exponer directamente esas claves al procesador principal.

La arquitectura podría ser conceptualmente:

Esto puede resultar especialmente interesante en dispositivos que necesitan una identidad única o autenticación fuerte frente a un servidor.

No todos los productos necesitan un Secure Element externo.

Algunos microcontroladores modernos incorporan funciones equivalentes o mecanismos de almacenamiento seguro dentro del propio dispositivo.

Por eso, esta decisión debe realizarse durante la selección de la arquitectura.

Proteger el firmware no significa únicamente utilizar Secure Boot.

También debemos pensar qué ocurre con el firmware almacenado en la memoria del dispositivo.

Dependiendo del microcontrolador pueden existir mecanismos para:

• Impedir la lectura externa.
• Restringir el acceso a determinadas regiones.
• Detectar modificaciones.
• Cifrar el firmware almacenado.
• Proteger determinadas zonas de memoria.
• Bloquear accesos desde interfaces de depuración.

La combinación concreta dependerá del microcontrolador utilizado y de los requisitos del producto.

En cualquier caso, la protección debe considerarse desde el diseño de la arquitectura y no como una funcionalidad que se añade después.

Durante el desarrollo, interfaces como JTAG o SWD son extremadamente útiles.

Permiten:

• Programar el microcontrolador.
• Depurar firmware.
• Analizar registros.
• Detectar errores.
• Realizar pruebas.

Pero en un producto terminado pueden convertirse en una vía de acceso al sistema.

Por eso, antes de fabricar un producto debemos preguntarnos:

¿Qué debe ocurrir con el puerto de depuración cuando el dispositivo pasa a producción?

Dependiendo de la arquitectura pueden existir diferentes opciones:

• Deshabilitar completamente el acceso.
• Bloquearlo mediante configuración de seguridad.
• Requerir autenticación.
• Mantener determinadas funciones disponibles para servicio técnico.
• Utilizar mecanismos específicos para permitir una recuperación controlada.

La solución depende del producto.

Un equipo instalado en una fábrica durante diez años puede necesitar una estrategia diferente a la de un dispositivo de consumo.

Un dispositivo conectado probablemente necesitará actualizaciones de firmware durante su vida útil.

Esto puede deberse a:

• Corrección de errores.
• Nuevas funcionalidades.
• Cambios en servicios externos.
• Vulnerabilidades de seguridad.
• Mejoras de rendimiento.

Por eso, la arquitectura electrónica debe prever desde el principio cómo se realizará la actualización.

Una actualización segura debería contemplar mecanismos como:

• Autenticación del firmware.
• Verificación de integridad.
• Firma digital.
• Protección frente a firmware no autorizado.
• Gestión de versiones.
• Recuperación ante una actualización fallida.
• Protección frente a rollback cuando sea necesario.

Un aspecto especialmente importante es qué sucede si el proceso de actualización se interrumpe.

Si se corta la alimentación mientras se está escribiendo la memoria, el dispositivo debe disponer de una estrategia que evite quedar inutilizado.

Esto puede requerir arquitecturas con diferentes particiones de firmware, mecanismos de recuperación o un bootloader diseñado específicamente para este escenario.

La seguridad no termina cuando el dispositivo sale de fábrica.

Un producto conectado puede permanecer en funcionamiento durante años.

Durante ese tiempo pueden aparecer nuevas vulnerabilidades, cambiar los servicios con los que se comunica o incluso cambiar las amenazas a las que está expuesto.

Por eso debemos considerar diferentes etapas:

Cada una de estas fases puede tener requisitos de seguridad diferentes.

Por ejemplo, las claves utilizadas durante la fabricación no deberían gestionarse necesariamente de la misma forma que las credenciales utilizadas durante la operación del dispositivo.

Cuando un producto electrónico se fabrica en volumen, la seguridad ya no depende únicamente de cómo se ha diseñado la PCB o de las funciones de seguridad del microcontrolador. Durante la fabricación, el dispositivo debe ser programado, configurado y, en determinados casos, recibir las claves y credenciales que utilizará posteriormente para identificarse y comunicarse con otros sistemas.

En este proceso pueden intervenir programadores, equipos de test, ordenadores de producción, servidores y herramientas de configuración. También pueden generarse registros de trazabilidad que relacionan una determinada unidad con su número de serie, firmware, configuración o identidad digital.

Todo este entorno debe considerarse parte del sistema de seguridad.

El aprovisionamiento de las claves es parte del diseño

Uno de los momentos especialmente sensibles es el aprovisionamiento de las credenciales que utilizará cada dispositivo.

Si un producto necesita una clave criptográfica, un certificado o unas credenciales para autenticarse frente a un servidor, hay que definir cómo se generan, dónde se almacenan y cómo llegan hasta el dispositivo. No debería tratarse simplemente como un dato más que se copia durante la programación.

Además, utilizar las mismas credenciales en todas las unidades puede crear un problema importante. Si una de ellas queda comprometida, las mismas credenciales podrían proporcionar acceso a otros dispositivos.

Una arquitectura más robusta puede asignar una identidad propia a cada unidad durante el proceso de fabricación. De esta forma, cada dispositivo puede disponer de sus propias claves o certificados y ser reconocido individualmente por la infraestructura que gestiona el producto.

Esto permite aplicar posteriormente mecanismos como la autenticación individual, la revocación de un dispositivo concreto o la gestión independiente de sus certificados sin tener que sustituir las credenciales del resto de unidades.

La seguridad continúa durante todo el ciclo de vida

La identidad asignada durante la fabricación puede acompañar al dispositivo durante toda su vida útil. Esto permite relacionar una unidad física con su información de fabricación, su firmware y sus credenciales, facilitando tanto la trazabilidad como la gestión posterior.

También resulta importante controlar qué ocurre con los equipos y herramientas utilizados durante la producción. Un ordenador que pueda programar cualquier unidad con credenciales sensibles o un sistema de fabricación que almacene claves sin protección puede convertirse en un punto de acceso crítico.

Por eso, cuando se diseña un producto conectado, no basta con preguntarse cómo protegeremos el dispositivo cuando esté en manos del cliente. También es necesario plantearse cómo se generará su identidad, cómo se incorporará al hardware y quién tendrá acceso a ella durante la fabricación.

La ciberseguridad, en definitiva, debe acompañar al producto desde la primera programación de la PCB hasta el final de su ciclo de vida.

No todos los ataques llegan a través de una red. En determinados productos, el atacante puede tener acceso directo al equipo y disponer del tiempo y las herramientas necesarias para analizar físicamente la electrónica.

Cuando esto ocurre, aparecen posibilidades que no existen en un ataque exclusivamente remoto. El acceso directo a la placa puede permitir intentar leer una memoria, conectar herramientas de depuración, analizar determinados buses o manipular componentes y señales. También puede ser posible acceder a puntos de prueba o conexiones internas que durante el desarrollo eran completamente normales, pero que en un producto comercial pueden proporcionar un nivel de acceso que ya no debería estar disponible.

Por este motivo, la seguridad física debe formar parte del análisis de amenazas cuando existe la posibilidad de que el dispositivo quede expuesto.

Diseñar la electrónica pensando en el acceso físico

La protección física no consiste necesariamente en hacer que el dispositivo sea imposible de abrir. El objetivo es dificultar o impedir aquellos accesos que podrían comprometer la seguridad del sistema.

La propia arquitectura electrónica puede contribuir a ello. Las interfaces de depuración pueden deshabilitarse o protegerse cuando el dispositivo entra en producción, mientras que determinadas señales o memorias pueden quedar situadas en zonas de la PCB menos accesibles. También pueden utilizarse componentes específicos de seguridad, mecanismos de protección de memoria o sistemas capaces de detectar determinados intentos de manipulación.

La carcasa tiene igualmente un papel importante. Dependiendo del producto, puede ser necesario utilizar un encapsulado que dificulte el acceso a la PCB, sistemas de fijación que evidencien una manipulación o incluso mecanismos capaces de detectar que el dispositivo ha sido abierto.

En aplicaciones donde el equipo se encuentra en un entorno accesible para terceros, estas medidas pueden adquirir una importancia considerable. Un dispositivo instalado en el interior de una máquina industrial no presenta necesariamente el mismo nivel de exposición física que un equipo IoT instalado en un espacio público.

Por eso, no existe una única solución de protección física válida para todos los productos. El nivel de protección debe determinarse a partir de qué podría obtener un atacante mediante el acceso físico y de qué consecuencias tendría conseguirlo.

Un diseño seguro debe considerar, por tanto, tanto lo que puede ocurrir cuando alguien intenta acceder al dispositivo a través de una red como lo que podría hacer si consigue tener la propia electrónica en sus manos.

Es habitual asociar ciberseguridad con cifrado de comunicaciones.

Por supuesto, proteger las comunicaciones es fundamental.

Pero podemos tener una conexión perfectamente cifrada y seguir teniendo un dispositivo vulnerable.

Por ejemplo, si:

• El firmware puede modificarse.
• Las claves pueden extraerse.
• El puerto de debug permanece abierto.
• El dispositivo acepta firmware no firmado.
• Las credenciales son iguales para todos los equipos.
• La actualización no está protegida.

Por eso, la seguridad debe contemplarse en diferentes capas.

Una arquitectura de seguridad puede representarse como:

La seguridad de un dispositivo es, por tanto, una combinación de diferentes mecanismos.

Hasta ahora hemos hablado principalmente del microcontrolador, el firmware y la arquitectura de seguridad, pero la propia PCB también puede desempeñar un papel importante en la protección del dispositivo. La distribución física de los componentes determina qué señales están expuestas, qué interfaces pueden alcanzarse físicamente y qué elementos del sistema quedan más o menos protegidos.

Una interfaz que es necesaria durante el desarrollo puede estar situada en una zona de la placa fácilmente accesible para el técnico. Sin embargo, si esa misma interfaz proporciona acceso al microcontrolador, a la memoria o a determinados buses internos, mantenerla expuesta en el producto final puede aumentar innecesariamente la superficie de ataque.

Lo mismo ocurre con los buses y señales sensibles. Una pista que conecta una memoria externa con el microcontrolador, por ejemplo, puede contener información que no debería quedar fácilmente accesible. En determinados productos también puede ser interesante evitar que las conexiones críticas lleguen directamente a un conector exterior o que puedan utilizarse sin desmontar físicamente el equipo.

La distribución de los componentes puede ayudar además a separar diferentes partes del sistema. Los elementos encargados de gestionar información sensible pueden situarse en zonas de la PCB con un mayor nivel de protección física, mientras que las interfaces destinadas al usuario o a mantenimiento pueden diseñarse teniendo en cuenta que estarán más expuestas.

Esta cuestión cobra todavía más importancia cuando el dispositivo puede quedar físicamente accesible. Un atacante que tenga la placa en sus manos puede analizar sus pistas, localizar puntos de prueba, acceder a conectores o intentar conectar herramientas de depuración directamente sobre determinados puntos del circuito. La seguridad física, por tanto, no depende únicamente de una carcasa o de un sistema de bloqueo: también empieza en cómo se ha diseñado y distribuido la propia PCB.

Por eso, el diseño de la placa debería realizarse conjuntamente con la arquitectura de seguridad. No se trata únicamente de conseguir que todas las señales lleguen correctamente a su destino, sino también de decidir qué partes del circuito necesitan estar expuestas, cuáles deben quedar protegidas y qué nivel de acceso físico debe tener cada una.

Una PCB correctamente diseñada puede dificultar determinados accesos y reducir la superficie de ataque del producto. Y, sobre todo, evita que la seguridad dependa exclusivamente de medidas implementadas posteriormente en el firmware.

La ciberseguridad también condiciona la selección de los componentes electrónicos. En un dispositivo conectado, elegir un microcontrolador únicamente por su capacidad de procesamiento, memoria, consumo o número de periféricos puede llevar a una arquitectura que posteriormente resulte difícil de proteger.

Las funciones de seguridad disponibles en el hardware deben analizarse junto con el resto de requisitos del producto.

Por ejemplo, si el dispositivo necesita verificar el firmware antes de ejecutarlo, el microcontrolador debería disponer de mecanismos compatibles con Secure Boot. Si además necesitamos proteger claves criptográficas, debemos comprobar si el propio microcontrolador ofrece almacenamiento seguro o si será necesario incorporar un Secure Element externo.

Esto puede cambiar incluso la arquitectura básica de la placa.

El microcontrolador como elemento de confianza

En un diseño convencional podemos seleccionar el microcontrolador principalmente por sus prestaciones:

CPU + RAM + Flash + periféricos + comunicaciones + consumo

En un producto conectado con requisitos de seguridad debemos añadir otra capa de análisis:

No todos los microcontroladores implementan estas funciones de la misma manera. Algunos integran parte de ellas dentro del propio dispositivo, mientras que otros requieren componentes externos.

Por eso, dos microcontroladores con prestaciones similares desde el punto de vista de procesamiento pueden ofrecer posibilidades muy diferentes para construir una arquitectura segura.

¿Microcontrolador seguro o Secure Element externo?

Una de las decisiones que puede aparecer durante el diseño es determinar dónde se almacenarán y utilizarán las claves criptográficas.

La segunda opción puede resultar interesante cuando el producto necesita una identidad criptográfica protegida o cuando determinadas claves deben permanecer fuera del alcance directo del firmware principal.

Pero añadir un componente de seguridad también implica considerar nuevos aspectos: comunicación entre dispositivos, alimentación, disponibilidad física en la PCB, proceso de aprovisionamiento y coste del componente.

Por tanto, no se trata simplemente de añadir un Secure Element cuando el proyecto está terminado. Es una decisión de arquitectura.

La memoria también forma parte de la decisión

La elección de la memoria puede verse afectada por los requisitos de seguridad.

No es lo mismo almacenar simplemente datos de aplicación que almacenar:

• Firmware.
• Certificados.
• Claves.
• Credenciales.
• Información de configuración.
• Datos sensibles.

En función de la arquitectura, puede ser necesario proteger determinadas regiones frente a lectura, escritura o modificación.

También puede ser necesario cifrar información almacenada en memoria.

Esto afecta a la elección del microcontrolador, la memoria externa y el propio esquema de comunicación entre ambos.

Las interfaces también deben evaluarse

La selección de componentes no debería limitarse a CPU y memoria.

Las interfaces disponibles también forman parte de la superficie de ataque.

Por ejemplo, un microcontrolador puede disponer de:

• USB.
• UART.
• SPI.
• I²C.
• JTAG.
• SWD.
• Ethernet.
• Wi-Fi.
• Bluetooth.

Durante el desarrollo podemos necesitar varias de estas interfaces.

Sin embargo, en producción algunas pueden dejar de ser necesarias.

Esto debe reflejarse en la arquitectura del hardware y en la configuración de seguridad del microcontrolador.

Una interfaz de depuración que resulta imprescindible durante el desarrollo puede convertirse en un riesgo si permanece completamente accesible en el producto final.

La seguridad puede cambiar el diseño de la PCB

Todas estas decisiones terminan teniendo una consecuencia directa sobre la placa electrónica.

Añadir un Secure Element requiere espacio y conexiones adicionales. Utilizar una memoria externa puede modificar el layout. Incorporar determinadas funciones de seguridad puede condicionar el microcontrolador elegido. Y proteger físicamente una interfaz puede afectar a la posición de conectores y componentes.

Por tanto, la seguridad no es una capa independiente situada por encima del hardware.

Forma parte de la propia arquitectura de la PCB.

Podemos resumir

Por eso, los requisitos de seguridad deben definirse antes de cerrar la selección de componentes. Una decisión tomada demasiado tarde puede obligar a cambiar el microcontrolador, añadir componentes, modificar el diseño de la PCB o incluso replantear parte de la arquitectura del producto.

En un dispositivo conectado, seleccionar componentes no consiste únicamente en encontrar un microcontrolador que tenga suficiente potencia y memoria. También debemos comprobar que sus capacidades de seguridad permiten construir la arquitectura que el producto necesitará durante todo su ciclo de vida.

Añadir mecanismos de seguridad cuando el hardware ya está diseñado puede ser mucho más complicado de lo que parece. Algunas funciones pueden incorporarse mediante una actualización de firmware, pero otras dependen directamente de las capacidades físicas del microcontrolador, de la memoria disponible o de la arquitectura de la propia placa.

Imaginemos un producto que ya tiene definida su electrónica y que, durante una fase avanzada del desarrollo, necesita incorporar Secure Boot. Si el microcontrolador utilizado no dispone de los mecanismos necesarios para establecer una cadena de confianza desde el arranque, no será suficiente con modificar el firmware. Puede ser necesario cambiar la plataforma sobre la que se ejecuta el producto.

Algo parecido ocurre con la protección de claves. Si inicialmente no se había previsto un mecanismo adecuado para almacenar material criptográfico y posteriormente se decide incorporar un Secure Element, habrá que encontrar espacio para el nuevo componente, añadir la interfaz de comunicación necesaria y revisar tanto el diseño de la PCB como el firmware que tendrá que utilizarlo.

También puede ocurrir que las nuevas necesidades de seguridad requieran más memoria para almacenar certificados, claves, imágenes de firmware o diferentes versiones del software. En ese caso, una modificación aparentemente relacionada únicamente con la seguridad puede terminar afectando a la selección del microcontrolador o de la memoria externa.

El problema puede extenderse incluso al proceso de fabricación. Si las claves deben introducirse de forma segura durante el aprovisionamiento del dispositivo, será necesario definir cómo se generan, dónde se almacenan y en qué momento se incorporan al producto. Una decisión de seguridad puede terminar afectando, por tanto, no solo al hardware y al firmware, sino también a la fabricación y a la gestión del dispositivo durante su ciclo de vida.

Cuanto más avanzado está el proyecto, más difícil resulta realizar este tipo de cambios sin generar efectos secundarios. Modificar el microcontrolador puede obligar a rediseñar la PCB; añadir memoria puede afectar al layout; cambiar la arquitectura de actualización puede requerir modificaciones importantes en el firmware y en la infraestructura que gestiona los dispositivos.

Por eso, la seguridad debería definirse junto con la arquitectura del producto y no como una capa que se incorpora cuando el desarrollo ya está terminado. Decidir desde el principio cómo se protegerá el firmware, dónde se almacenarán las claves, cómo se realizará una actualización segura y qué accesos estarán disponibles en producción puede evitar rediseños importantes cuando el producto ya está avanzado.

Antes de cerrar el diseño de un dispositivo conectado podemos revisar algunos puntos.

Hardware

• ¿El microcontrolador dispone de las funciones de seguridad necesarias?
• ¿Existe un Hardware Root of Trust?
• ¿Las claves pueden almacenarse de forma segura?
• ¿Necesitamos un Secure Element?
• ¿La memoria puede protegerse frente a lectura o modificación?
• ¿Las interfaces de debug están protegidas?
• ¿La PCB dificulta el acceso físico a señales sensibles?
• ¿Existen interfaces innecesarias que puedan eliminarse?

Firmware

• ¿Está implementado Secure Boot?
• ¿El firmware está autenticado?
• ¿Las actualizaciones están firmadas?
• ¿Existe protección frente a firmware no autorizado?
• ¿Se controla la versión del firmware?
• ¿Existe un mecanismo de recuperación?
• ¿Se ha considerado la protección frente a rollback?

Comunicaciones

• ¿Las comunicaciones están cifradas?
• ¿El dispositivo autentica al servidor?
• ¿El servidor autentica al dispositivo?
• ¿Cada dispositivo dispone de una identidad propia?
• ¿Cómo se gestionan las credenciales?

Producción

• ¿Cómo se introducen las claves en cada dispositivo?
• ¿Cada unidad tiene credenciales únicas?
• ¿Cómo se protegen durante fabricación?
• ¿Existe trazabilidad de las unidades?
• ¿Qué ocurre con las claves utilizadas durante el proceso de producción?

Ciclo de vida

• ¿Cómo se actualizará el dispositivo dentro de cinco o diez años?
• ¿Cómo se revocará un dispositivo comprometido?
• ¿Cómo se gestionarán las vulnerabilidades?
• ¿Qué ocurre cuando termina el soporte?
• ¿Cómo se realizará el borrado seguro de información?

La ciberseguridad de un dispositivo conectado no puede reducirse a añadir cifrado al firmware.

Es el resultado de diferentes decisiones que empiezan mucho antes:

arquitectura → microcontrolador → memoria → claves → PCB → firmware → comunicaciones → fabricación → actualizaciones → ciclo de vida.

Seleccionar un microcontrolador con funciones de seguridad, proteger las claves, implementar Secure Boot, controlar las interfaces de depuración y diseñar un sistema de actualizaciones seguro puede cambiar completamente el nivel de protección de un producto.

Y cuanto más tarde se tomen estas decisiones, más difícil puede resultar incorporarlas.

La seguridad de un dispositivo conectado no empieza cuando se escribe la primera línea de firmware, sino cuando se define su arquitectura electrónica.

Por eso, la ciberseguridad debe formar parte de las especificaciones del producto desde las primeras fases del desarrollo.

La ciberseguridad de un dispositivo conectado no debería considerarse una funcionalidad que se añade al final del desarrollo.

La elección del microcontrolador, la protección de las claves, el almacenamiento de información sensible, el Secure Boot, las interfaces de depuración, las actualizaciones y la propia arquitectura de la PCB pueden determinar qué nivel de seguridad puede alcanzar el producto.

Además, un dispositivo conectado puede permanecer operativo durante muchos años. Por eso, la arquitectura debe contemplar no solamente cómo proteger el equipo cuando sale de fábrica, sino también cómo actualizarlo, mantenerlo y gestionar su identidad durante todo su ciclo de vida.

En definitiva:

la ciberseguridad empieza en el diseño electrónico.

Cuanto antes se incorporen estos requisitos al proyecto, más posibilidades tendremos de construir un producto conectado que pueda protegerse, actualizarse y mantenerse durante toda su vida útil.

Diseñar un producto IoT seguro requiere coordinar hardware, firmware, comunicaciones y fabricación desde el principio.

En Kenso Circuits desarrollamos productos electrónicos conectados, desde la definición de la arquitectura y selección de componentes hasta el diseño de la PCB, firmware, prototipado y validación.

La incorporación de requisitos de seguridad durante estas primeras fases permite tomar decisiones de hardware compatibles con las necesidades futuras del producto.

Si estás desarrollando un dispositivo IoT, industrial o conectado y quieres plantear su arquitectura desde el principio, podemos ayudarte a definir el hardware necesario para el proyecto.

¿Por qué la ciberseguridad debe plantearse desde el hardware?

Porque algunas funciones de seguridad dependen directamente de la arquitectura del dispositivo. La protección de claves, Secure Boot, almacenamiento seguro, interfaces de depuración o determinadas funciones criptográficas pueden requerir capacidades específicas del microcontrolador o componentes adicionales.

¿Qué es Hardware Root of Trust?

Es una base de confianza implementada mediante mecanismos de hardware sobre la que pueden construirse otros sistemas de seguridad del dispositivo. Puede utilizarse para establecer una identidad y verificar el software que se ejecuta.

¿Qué es Secure Boot?

Es un mecanismo que permite verificar el firmware durante el proceso de arranque antes de ejecutarlo. Su objetivo es impedir que se ejecute software que no haya sido autorizado.

¿Qué es un Secure Element?

Es un componente especializado en seguridad que puede almacenar claves criptográficas y realizar determinadas operaciones de seguridad sin exponer directamente las claves al procesador principal.

¿Es necesario utilizar un Secure Element en todos los dispositivos IoT?

No necesariamente. Algunos microcontroladores incorporan mecanismos de seguridad suficientes para determinados productos. La necesidad de utilizar un Secure Element depende de los requisitos de seguridad, identidad, almacenamiento de claves y arquitectura del dispositivo.

¿Qué hacer con JTAG o SWD en un producto terminado?

Depende de las necesidades del producto. Las interfaces de depuración pueden deshabilitarse, bloquearse o protegerse mediante mecanismos de autenticación. La decisión debe tomarse antes de cerrar la arquitectura de producción.

¿Las actualizaciones de firmware también forman parte de la ciberseguridad?

Sí. Las actualizaciones deberían contemplar mecanismos que permitan verificar la autenticidad e integridad del firmware y evitar la instalación de versiones no autorizadas.

¿La PCB influye en la ciberseguridad?

Sí. La distribución de componentes, las interfaces accesibles, la exposición de buses y la posibilidad de acceder físicamente a determinadas señales pueden formar parte de la superficie de ataque de un dispositivo.

¿Cuándo debe definirse la arquitectura de seguridad?

Lo recomendable es hacerlo durante las primeras fases del desarrollo, antes de cerrar la selección del microcontrolador, memoria, interfaces y arquitectura de la PCB. De esta forma, los requisitos de seguridad pueden formar parte de las decisiones de hardware desde el principio.