Autor: Kimberly Dinsmore, Security Solutions Manager, Renesas Electronics
Los microcontroladores son pequeños y económicos. Las soluciones de seguridad tienen la reputación de no ser ninguna de las dos cosas. Con una regulación y una legislación cada vez más estrictas, la necesidad de equilibrar ambas es fundamental.
Los microcontroladores (MCU) han recorrido un largo camino desde sus inicios. En el comienzo, solo contaban con 4 bits de datos y todas las instrucciones eran programadas en lenguaje ensamblador, descritas detalladamente en unas pocas páginas de la hoja de datos del dispositivo, el periférico más avanzado era un convertidor A/D y la comunicación tenía que realizarse a través de pines de E/S. Las MCU actuales de 32 bits con gigabytes de almacenamiento interno de memoria de programa no solo admiten una amplia variedad de interfaces de comunicación, sino que también se espera que utilicen esas interfaces para proporcionar soluciones de alta gama, como inteligencia artificial y aprendizaje automático.
La seguridad no era una gran preocupación para las MCU de 4 bits. Por lo general, realizaban una tarea menor en un sistema más grande y, con el código en una ROM o PROM enmascarada, no era posible alterar ese código. Ahora, sin embargo, la MCU es una parte integral del sistema, y a menudo realiza tantas tareas que se requiere un sistema operativo, lo que borra la línea entre un microcontrolador y un microprocesador. Sin embargo, como dice el refrán, “un gran poder conlleva una gran responsabilidad”. Ahora es responsabilidad del microcontrolador proporcionar seguridad al producto en general.
Una seguridad sólida requiere una base sólida. Antes de que la MCU pueda proteger todo el sistema, debe protegerse a sí misma. Si bien es vital determinar el modelo de amenaza y la política de seguridad relevantes para un producto específico, algunas soluciones de seguridad son aplicables de manera muy amplia. Veamos qué preguntas puede hacer para ayudar a determinar qué soluciones podrían ser adecuadas para su aplicación. Como cualquier buena implementación de firmware, intentemos analizarlos de abajo hacia arriba.
En el principio: programación segura de fábrica
Mucho antes de que un cliente final utilice un producto, éste es vulnerable a ataques. Desafortunadamente, los ingenieros que diseñan el producto no suelen considerar estas amenazas, en parte debido a su falta de exposición al proceso de producción, pero también porque están más centrados en la aplicación final, a menudo con la presión adicional de tener que producir un prototipo inicial.
Algunas preguntas que hacerse incluyen:
– ¿Cómo sabes que la MCU en particular que especificaste (¡y pagaste!) realmente está instalada en tu placa de circuito?
– ¿Cómo se entrega su código binario a la empresa de programación? ¿Está cifrado o en texto plano? Si está en texto sin formato, alguien puede copiarlo fácilmente y/o realizar ingeniería inversa.
– Si el binario está cifrado, ¿en qué punto del proceso de programación se descifra? Si se descifra fuera de la MCU, el texto sin formato se puede detectar conectando cables a los pines de programación.
Las soluciones seguras de programación de fábrica pueden proteger contra estas amenazas. Como se muestra en la Figura 1, las soluciones más sólidas son aquellas en las que el binario se cifra utilizando un método que solo es compatible con una MCU genuina, donde el binario se descifra en la propia MCU, de modo que solo se transfieren datos cifrados en los pines de programación. Muchas de estas soluciones requieren el uso de MCU que han sido preprogramadas con un gestor de arranque especial, pero algunas MCU ahora admiten esta capacidad en chips en blanco. Lo bueno de este último es que no se requiere hardware adicional ni infraestructura complicada para transferir claves de descifrado, no se necesita ningún equipo de programación especial y no se requieren MCU preprogramadas.
Para las MCU que no tienen esta característica integrada en su silicio, hay soluciones de programación seguras de fábrica disponibles a través de empresas de programación con experiencia. Estas empresas ofrecerán garantías (certificaciones u otras) de que sus datos se manejarán de manera segura y trabajarán con usted para proporcionarle el hardware, el software y la logística necesarios.
Primero lo sencillo: deshabilitar las interfaces externas
Un elemento de seguridad que puede pasarse por alto fácilmente es la desactivación de las interfaces externas de depuración y programación. Para dispositivos simples que nunca se actualizarán ni depurarán después de la implementación, esto suele ser tan simple como mover un bit o “quemar” un fusible. Pero a medida que las MCU se vuelven más potentes, la necesidad de actualizar el firmware y volver a habilitar el acceso de depuración se están convirtiendo en requisitos esenciales. La flexibilidad requerida para implementar estos requisitos tiende a complicar el proceso para deshabilitar estas interfaces externas, lo que a menudo requiere pasos adicionales o incluso conexiones de pines de MCU adicionales, así que asegúrese de estudiar este aspecto de la MCU antes de diseñar su PCB.
Si personas no autorizadas obtienen acceso a estas interfaces, existe una variedad de posibles ataques que podrían realizar:
– Extraiga todo el código y los datos del dispositivo para realizar ingeniería inversa o clonar su producto.
– Extraer o modificar información sensible, como claves criptográficas y parámetros operativos del producto.
– Reprogramar completamente el dispositivo.
Algunas preguntas que hacerse son:
– ¿Cómo se actualizará el firmware del producto final? ¿El actualizador tendrá acceso físico al dispositivo y utilizará herramientas de programación estándar? En caso afirmativo, es importante que solo las personas autorizadas puedan realizar esta actualización.
– ¿Será necesario depurar el producto una vez entregado al cliente final? Nuevamente, es importante que solo las personas autorizadas puedan volver a habilitar esta función.
– ¿Se requiere alguna conexión externa especial para admitir las funciones de administración del ciclo de vida del dispositivo del chip?
Figura 1. La programación segura de fábrica garantiza silicio genuino y brinda protección IP.
Mantener las cosas separadas: mecanismos de aislamiento
El concepto de aislamiento es nuevo para los microcontroladores. Dado que el código de la MCU suele ser desarrollado por un pequeño equipo o incluso por un solo ingeniero, ¡puede parecer inútil proteger la MCU de sí misma! Pero ahora que las MCU están activas en Internet y las aplicaciones se crean a partir de una cantidad significativa de código de terceros, es necesario considerar ese nivel de protección. Los mecanismos de aislamiento también pueden proteger contra daños involuntarios causados por un código fuera de control, lo que podría servir como característica de seguridad.
Los mejores mecanismos de protección son el aislamiento impuesto por hardware. Las Unidades de Protección de Memoria (MPU) pueden ser muy efectivas, pero a menudo tienen lagunas de cobertura. Los mecanismos propietarios como Arm TrustZone llenan muchos de estos vacíos. Una cosa a tener en cuenta es: ¿cómo se establecen los límites entre las regiones seguras y las que no lo son? Si están configurados en software, un código malicioso podría alterarlos. Las soluciones más sólidas establecen estos límites de manera inmutable, pero esto introduce la posible complicación de requerir que las actualizaciones de firmware permanezcan dentro de un tamaño específico.
Algunas preguntas que hacerse incluyen:
– ¿Qué código de terceros debería aislarse potencialmente?
– ¿Qué código es tan complejo que es imposible proporcionar una cobertura de prueba del 100%?
– ¿Qué activos y servicios necesita proteger contra alteraciones involuntarias o maliciosas?
Protección de actualizaciones de firmware: Bootloader seguro
Puede que su producto no sea tan destacado como un teléfono inteligente, pero incluso dispositivos más sencillos como los termostatos conectados pueden ofrecer a los piratas informáticos una forma de acceder a una infraestructura específica. Como resultado, los consorcios de seguridad y los gobiernos de todo el mundo están reconociendo la necesidad de poder actualizar el firmware de los dispositivos conectados para protegerlos contra amenazas a la seguridad. Para garantizar que esta capacidad no introduzca más problemas, esta actualización debe realizarse de forma segura.
Hay multitud de formas de crear un gestor de arranque seguro y, por muy tentador que sea crear uno desde cero, es mucho más eficiente aprovechar un proyecto de código abierto seguro. Muchos proveedores de MCU incluso ofrecen versiones de estas soluciones en sus paquetes de software. Estas soluciones se pueden configurar para la mayoría de los casos de uso comunes y, dado que son de código abierto, puede modificarlas según sus necesidades específicas. Lo mejor de estas soluciones es que aprovecha años de «lecciones aprendidas» de ingenieros de firmware experimentados, y la implementación está sujeta a inspección y revisión por parte de expertos en seguridad para garantizar que no haya «puertas traseras» ocultas.
Dado que la legislación gubernamental exigirá el soporte de actualizaciones de firmware, las preguntas aquí son más limitadas, simplemente:
– ¿Tiene una interfaz externa a través de la cual se pueda recibir una nueva imagen de firmware?
Figura 2. El proceso de arranque seguro verifica cada parte de la aplicación antes de su ejecución.
Tomando señales de los microprocesadores: Primer paso del bootloader
La solución de cargador de arranque seguro mencionada antes normalmente se centra en garantizar que sólo se acepten actualizaciones de firmware auténticas. Muchas de estas soluciones también ofrecen otra característica: la capacidad de autenticar el código de la aplicación antes de ejecutarla. Pero ¿qué garantiza que el gestor de arranque seguro no se haya dañado?
Los microprocesadores resuelven este dilema mediante el uso de un cargador de arranque de primera etapa: una pequeña cantidad de código ejecutable integrado en el silicio que autentica la solución de arranque seguro de la aplicación, que luego se denomina cargador de arranque de segunda etapa. La Figura 2 ilustra el proceso de inicio seguro cuando también se incluye un mecanismo de aislamiento. Es bueno tener en cuenta que estos gestores de arranque pueden funcionar como una característica de seguridad, asegurando que el código no se haya dañado sin darse cuenta. Una cosa a tener en cuenta: llevará algún tiempo realizar una verificación de autenticidad del código, así que estudie las opciones disponibles para encontrar el mejor equilibrio para su producto.
Algunas preguntas que hacerse incluyen:
– ¿Necesita autenticar o verificar la integridad de todo o parte del código de la aplicación antes de su ejecución?
– ¿Alguna vez querrás actualizar tu gestor de arranque de segunda etapa?
– ¿Tiene algún horario de inicio que deba cumplir?
Las llaves del reino: almacenamiento seguro de claves
De manera similar a proteger la entrada a un edificio, proteger una aplicación integrada a menudo requiere el uso de llaves. El formato criptográfico más que físico puede ser diferente, pero tanto el concepto como las consecuencias de un manejo descuidado son fundamentalmente idénticos. Pierde tus llaves y ya no podrás entrar. Si alguien más las encuentra, ahora tendrá acceso completo. Si copian sus claves, pueden causar daños importantes antes de que usted se dé cuenta de que algo va mal. Esta característica de seguridad es tan crítica que algunas industrias requieren que el mecanismo de almacenamiento de claves tenga certificaciones específicas.
Hay una variedad de formas en que las claves pueden verse comprometidas. Si un atacante solo tiene acceso remoto, las claves almacenadas o utilizadas en texto sin formato son vulnerables si se puede inyectar código malicioso. Si un atacante tiene acceso físico, las claves de texto sin formato son vulnerables si la protección de la interfaz externa se ve comprometida. También existen ataques más sofisticados, como analizar las emisiones electromagnéticas del dispositivo durante una operación criptográfica o medir el tiempo necesario para completar una operación criptográfica. Dado que estos ataques no son invasivos y solo infieren información del comportamiento observado, se denominan ataques de canal lateral. También hay ataques que se pueden realizar haciendo fallar la operación criptográfica y analizando los resultados parciales. Dado que estos ataques requieren alterar el entorno operativo del dispositivo, se denominan ataques de inyección de fallas. Las claves criptográficas son uno de los elementos más críticos de una solución de seguridad, lo que las convierte en un objetivo principal para los ataques.
Las preguntas que hacerse incluyen:
– ¿Requieres almacenamiento de claves con una certificación de seguridad específica? Debido a la naturaleza de las certificaciones FIPS y Common Criteria, estas soluciones tienden a requerir un componente externo, que a menudo tiene las desventajas de un mayor costo, mayor consumo de energía, un tiempo de ejecución más lento y una mayor complejidad de desarrollo. Hay una pequeña cantidad de microcontroladores certificados con almacenamiento de claves seguro integrado, así que asegúrese de revisarlos. Certificaciones como PSA Certified y SESIP ofrecen alternativas al almacenamiento de claves seguro externo, pero asegúrese de consultar los detalles de la certificación para ver exactamente lo que está obteniendo.
– ¿Están los ataques físicos dentro del alcance? Si es así, evite cualquier solución en la que las claves se almacenen o utilicen en texto sin formato. Aquí son útiles las implementaciones criptográficas de hardware con protecciones de canal lateral.
– ¿Están los ataques remotos dentro del alcance? Si es así, intente nuevamente evitar soluciones en las que las claves se almacenen o utilicen en texto sin formato, pero como mínimo, elija una solución que incorpore un mecanismo de aislamiento que pueda ofrecer cierta protección.
Código y datos de protección – DOTF
A diferencia de los microprocesadores, los microcontroladores suelen mantener todo su código y datos dentro del propio chip. Sin embargo, algunas aplicaciones requieren la potencia de procesamiento de una MCU, pero se pueden almacenar más códigos o datos de los que la MCU puede almacenar. La mayoría de las MCU pueden usar interfaces seriales, como SPI o I2C, para interactuar con un dispositivo flash externo, que puede preprogramarse con datos que usará la aplicación o programarse con datos generados por la aplicación. Algunas MCU pueden incluso ejecutar código directamente desde estos dispositivos flash externos. Pero ahora tenemos una nueva consideración de seguridad: ¿cómo podemos proteger la confidencialidad de este código y/o datos externos?
El descifrado sobre la marcha está diseñado para una lectura y/o ejecución fluida de datos externos cifrados. Habrá una penalización de tiempo por leer/ejecutar datos/códigos de texto sin formato; sin embargo, es insignificante en comparación con determinar “manualmente” el bloque requerido, descifrarlo en un búfer temporal y leer/ejecutar desde ese búfer. El desarrollo de aplicaciones también se simplifica, especialmente para el caso de código ejecutable, ya que el código simplemente se compila para ejecutarse en la dirección donde está almacenado en el dispositivo de almacenamiento externo. Como se muestra en la Figura 3, algunas soluciones de descifrado sobre la marcha permiten utilizar diferentes claves en diferentes rangos, incluidas áreas sin cifrado.
Las preguntas aquí incluyen:
– ¿Usarás un dispositivo externo para almacenar código o datos externos?
– ¿Necesita mantener la confidencialidad de ese código/datos?
– ¿Cuáles son las ramificaciones de que un tercero obtenga ese código/datos?
Figura 3. El descifrado sobre la marcha proporciona almacenamiento confidencial de código y datos externos al microcontrolador con un impacto mínimo en la velocidad de ejecución.
Comunicación confidencial: conexión segura a Internet
Cuando los primeros microcontroladores de 8 bits conectados a Internet fueron una novedad, nadie pensó mucho en la seguridad de la conexión. En aquel entonces, estos dispositivos simplemente no eran un objetivo de ataque y el concepto de cadenas de exploits era prácticamente desconocido. Más importante aún, para los ingenieros que desarrollaron estas soluciones de microcontroladores era fundamental que la pila IP fuera liviana y eficiente. Agregar una capa TLS (Seguridad de la capa de transporte), además de ser complicado, produjo un código que no era ninguna de las dos cosas.
Lo bueno es que ahora la mayoría de los desarrolladores comprenden y aceptan la necesidad de una capa de seguridad como TLS en su ruta de comunicación, y la mayoría de los servicios de nube pública la requieren en forma de TLS o DTLS. La única pregunta aquí es: ¿necesita TLS o DTLS? La respuesta dependerá de su protocolo de comunicación específico (basado en TCP o UDP).
Conclusión
La “seguridad” tiene muchas definiciones, con una amplia gama de amenazas y distinta gravedad de consecuencias. Las mitigaciones de estas amenazas suelen tener un profundo impacto en la arquitectura de un producto. Es vital decidir de antemano qué activos deben protegerse y cómo pretende protegerlos de las amenazas identificadas. Sólo entonces podrá crear una especificación de requisitos y un diseño de arquitectura adecuados para su producto.
Sin embargo, algunas de las técnicas de piratería informática más exitosas no implican tecnología. Los ataques de ingeniería social pueden engañar a las personas para que divulguen información confidencial. Los sobornos pueden proporcionar acceso legítimo a usuarios ilegítimos. Como ingenieros, debemos proporcionar una solución que intente encontrar el equilibrio entre las amenazas percibidas y las reales, garantizando que la tecnología no sea la más débil.
