La seguridad es cada vez más importante para los sistemas integrados a medida que evolucionan de aplicaciones independientes a aplicaciones conectadas que almacenan, reciben y transmiten datos, se actualizan con el software más reciente, se monitorizan de forma remota, etc. Dichos requisitos se propagan incluso en las implementaciones más pequeñas, a pesar de los recursos de memoria y la potencia computacional limitados.
La mayoría de los desarrolladores integrados pueden percibir todo esto como demasiado complejo de utilizar, comenzando por temas relacionados con la criptografía. Pero, de hecho, los aspectos relacionados con la seguridad abarcan muchos aspectos del software y la arquitectura del chip que deben diseñarse específicamente y trabajar juntos sin problemas para lograr sus objetivos. Este artículo repasa los aspectos más relevantes a considerar en relación con las implementaciones de seguridad de microcontroladores para sistemas integrados tan pequeños.
Uno de los primeros pasos para asegurar el acceso a un activo valioso es hacerlo disponible bajo una política de uso específica. Tal política podría, por ejemplo, restringir qué parte del software de la aplicación puede usarla y forzar su uso a través de una interfaz funcional definida que no se puede eludir, en el mejor de los casos implementada en hardware.
La tecnología ARM TrustZone proporciona un ejemplo de dicha capacidad de aislamiento, que permite separar la aplicación del usuario en un entorno llamado «seguro» y «no seguro» dentro del contexto de la CPU. Pero, ¿dónde se aplica la política? En una «etapa» dedicada, antes de que una transacción de memoria se propague al bus interno (más sobre esto más adelante). En caso de violaciones, se lanza una excepción, de acuerdo con la Figura 1:
La aplicación puede decidir de manera reactiva realizar una acción adecuada, como reiniciar un servicio, registrar el evento, señalar un fallo, etc.
Mirando la Figura 1, es fácil ver que el software no seguro puede acceder solo a recursos no seguros; ¿Cómo pueden los dos mundos comunicarse entre sí? Afortunadamente, existe un mecanismo para hacerlo. Para ejecutar una función segura, la CPU puede cambiar su estado a seguro a través de una instrucción especial llamada «puerta de enlace segura» (SG). Una instrucción SG se combina con una rama inmediatamente siguiente (es decir, «saltar») a la dirección de función segura deseada. Cuando vuelve la función segura, el estado del procesador vuelve a cambiar al modo no seguro.
En la Figura 2 se proporciona un ejemplo de asignación de recursos entre un entorno seguro y no seguro:
Los pares de ‘SG + dirección’ se asignan a un área especial definida como invocable no segura; Cualquier parámetro como los punteros de memoria pasados por las funciones invocables no seguras pueden usar una instrucción especializada de «objetivo de prueba» para asegurarse de que un búfer de memoria esté en una memoria no segura y no se superponga con la memoria segura, para evitar la fuga de datos.
Mientras está en modo seguro, es posible que sea necesario devolver la llamada a una función no segura, por ejemplo, para notificar a la función que llama sobre el estado de la solicitud, emitir notificaciones relacionadas con RTOS, etc. El compilador generará la instrucción de bifurcación especial que cambia el estado a no seguro antes de la llamada y envía la dirección de retorno a la pila segura.
Los sistemas integrados están fuertemente impulsados por interrupciones; cuando ocurre una interrupción no segura mientras la CPU está en modo seguro, los registros se apilan de forma predeterminada en la pila segura y su contenido se borra automáticamente. Esto es para evitar la fuga no intencionada de información del área segura. La partición de las excepciones dentro de cada entorno se admite a través de una tabla de vectores de interrupción dedicada para cada uno. De manera similar, existe una implementación separada de los punteros de pila, los temporizadores de sistema, etc.
Todo esto suena genial, pero ¿cómo se definen esas áreas y límites de memoria seguros? Hay dos unidades que son interrogadas en paralelo: la SAU (unidad de atribución de seguridad) y la IDAU (unidad de atribución definida por implementación). En cada acceso a la CPU, ambos responderán con el atributo de seguridad asociado a esa dirección. Su respuesta combinada define el atributo de dirección final, el más restrictivo de los dos «ganadores» (una región segura no puede ser «anulada» por un atributo menos seguro). Finalmente, el resultado se evalúa contra la política definida como en la Tabla 1. Si el acceso es legítimo, puede continuar; de lo contrario, se bloquea y se genera una excepción segura.
Notablemente, la configuración de la SAU (cuántas regiones se admiten, la configuración predeterminada, etc.) se puede definir en el momento del diseño, y la implementación de la IDAU se define, es decir, se deja al fabricante del dispositivo.
Las unidades de protección de memoria (MPU) dentro de cada dominio protegerán los subprocesos individuales entre sí, mejorando la solidez general del software. La Figura 3 muestra un ejemplo de partición en un microcontrolador compatible con TrustZone:
¿Hemos logrado algún objetivo relacionado con la seguridad hasta ahora? En realidad, todavía no. TrustZone puede aislar los subprocesos de la aplicación que se ejecutan en modo seguro de los no seguros, pero no proporciona ninguna «seguridad» per se y no puede imponer la legitimidad de un acceso; más bien evita el uso no deseado o el acceso directo.
El desarrollador debe decidir qué partes de la aplicación se aislarán; TustZone puede ser útil y no se puede omitir en el software (en comparación con una MPU clásica), por lo que las rutinas relacionadas con las operaciones criptográficas son un buen candidato. En cualquier caso, el sistema aplicará la configuración de TrustZone desde el inicio de la ejecución y evitará la alteración de dichos límites (por ejemplo, almacenándolos en un área de memoria que la CPU no puede modificar directamente).
La buena práctica sugiere mantener mínima la cantidad de funcionalidad implementada dentro del entorno seguro. Esto reduce la posibilidad de errores, errores de tiempo de ejecución y explotación maliciosa de cualquier defecto de software. Como efecto secundario, la validación de la funcionalidad se vuelve mucho más ligera durante la depuración y la prueba.
¿Qué recursos criptográficos debe proporcionar una MCU? Depende de la complejidad de la aplicación; para una solución de nivel de entrada, una rutina de software pura podría ser suficiente. Pero el soporte de hardware de algoritmos criptográficos reduce el consumo de energía y el tamaño del código, a una mayor velocidad de ejecución.
Dicho esto, el primer bloque de construcción de la mayoría de los protocolos criptográficos es un TRNG (generador de números aleatorios verdaderos), que debe ser validado y probado por sus propiedades de entropía y calidad de aleatoriedad (ya que un RNG mal construido puede estropear la seguridad de cualquier algoritmo). usarlo).
Para el almacenamiento local, el soporte de algoritmos simétricos como AES con múltiples modos de operación es casi obligatorio para cifrar y descifrar la mayor parte de los datos. En combinación con algoritmos hash («sumas de verificación criptográficamente seguras») como SHA-2 o SHA-3, la aplicación puede realizar comprobaciones de autenticación simples y verificar que el contenido de los datos no se haya modificado.
Para una conectividad avanzada, los algoritmos de cifrado asimétrico como RSA o ECC pueden admitir la verificación de identidad en las conexiones de cliente/servidor, ayudar a obtener claves de sesión efímeras o verificar el origen y la legitimidad de una actualización de firmware. Dichos aceleradores también podrán generar claves en el chip, para uso local.
Pero el problema realmente difícil es la gestión de claves, ya que las claves deben mantenerse confidenciales, enteras y disponibles. Se deben considerar muchos escenarios: cuándo se inyecta (almacena) la clave en la MCU, cómo transportarla, cómo cargarla en el hardware criptográfico y cómo protegerla de fugas.
Idealmente, la aplicación nunca manejará material clave en formato claro, para evitar una exposición peligrosa. Una forma sencilla de evitar esto es manejarlo dentro del área segura de TrustZone, pero lo mejor es dentro de un subsistema aislado dedicado en el chip. Una vez que las claves se almacenan en la memoria no volátil, las técnicas como el «envoltorio» de claves (cifrado de claves) ayudan a proteger la privacidad. Hacer que los datos empaquetados sean únicos en cada MCU mitiga aún más los riesgos de fuga de claves y elimina las amenazas de clonación. Para dicho mecanismo, se necesita una «raíz de confianza» para el almacenamiento, en forma de una «clave de cifrado de clave» exclusiva para cada MCU, para garantizar que ningún dispositivo específico se vea comprometido y permita un ataque de «clase» en todas las unidades similares.
Los ataques DPA y SPA registran y analizan los rastros de consumo de energía para aplicar ingeniería inversa al valor clave. Estos se vuelven cada vez más baratos y rápidos de implementar, incluso para atacantes no altamente calificados con recursos limitados. Si el acceso físico al dispositivo es motivo de preocupación, sin otros medios de control de acceso en el sistema, se requieren contramedidas contra esas amenazas dentro de los motores criptográficos. Además, cualquier monitoreo de las señales conectadas a la carcasa del equipo, que puede notificar a la MCU y posiblemente tomar una marca de tiempo del evento de manipulación, será muy deseable.
El subsistema aislado permitirá a un usuario proporcionar claves elegidas en el dispositivo y tenerlas envueltas y almacenadas de forma segura, listas para uso posterior de la aplicación. La MCU debe admitir alguna interfaz para hacer esto tanto en el campo como en la fábrica, lo que permite una fácil producción inicial y una actualización posterior en el campo. Dichos pasos deberán estar protegidos y no exponer ningún contenido clave durante el tránsito.
En los MCU modernos, otras entidades funcionales pueden transferir datos de manera autónoma hacia y desde la memoria o los periféricos, para mejorar el rendimiento y utilizar el ancho de banda disponible de manera eficiente. Algunos ejemplos son los motores DMA, los controladores de gráficos, los controladores de ethernet, etc. Es de vital importancia que la MCU pueda establecer los atributos de seguridad de dichos agentes e implementar «filtros de acceso» específicos en los puntos de comunicación, como memorias y periféricos mapeados en memoria.
Cualquier procesador es inútil sin capacidad de entrada y salida de señales. Proteger dichas interfaces del uso indebido es un requisito fundamental para evitar la manipulación, ya que esta es la forma natural de interactuar con la MCU. El diseñador cauteloso debe verificar que la MCU pueda restringir el acceso a puertos de E/S y periféricos seguros, evitando así que el software «tome el control», interfiera o husmee maliciosamente en la comunicación, mientras aísla los puertos y periféricos entre sí.
Durante el desarrollo, para probar el software, es casi obligatorio un depurador basado en Jtag. Dicha interfaz puede acceder a la mayoría de los recursos en el chip y, por lo tanto, constituye una puerta trasera crítica para cualquier aplicación implementada en el campo. Los casos de uso para asegurar Jtag son muy diferentes: bloquearlo permanentemente o mantener la capacidad de depuración en el campo, para proteger el acceso. Cualquiera que sea la estrategia que se elija, la protección no permitirá que se eluda, haciendo cumplir la autorización adecuada a través de una clave de autenticación y brindando acceso solo después de completar con éxito un protocolo de desafío-respuesta. Finalmente, el dispositivo debe soportar y asegurar el mecanismo para devolver el dispositivo a la fábrica en caso de análisis de defectos, posiblemente borrando cualquier activo secreto almacenado mientras mantiene la interfaz segura hasta llegar a su destino.
Es posible que la imagen final de la aplicación, una vez implementada en el campo, deba hacerse inmutable en algunas partes, para garantizar que se encuentre en un estado conocido en todo momento. Para respaldar este requisito, el microcontrolador deberá tener la capacidad de proteger permanentemente las partes definidas por el usuario de la memoria no volátil contra modificaciones.
Por último, pero no menos importante, cada microcontrolador se somete a un largo proceso de prueba antes del envío; muchos de estos resultados de pruebas (valores de recorte, datos específicos de producción, etc.) y otras configuraciones se almacenan en el dispositivo. Este modo de prueba especial, aunque no es significativo para un usuario final, puede acceder, controlar y potencialmente alterar todos los recursos del chip. El fabricante debe asegurarse de que dicha puerta trasera potencial no se pueda abrir de manera malintencionada o por error, una vez que el dispositivo esté fuera de la fábrica y en manos del cliente.
Buscar un microcontrolador que admita los requisitos anteriores puede ser una tarea abrumadora. Afortunadamente, Renesas diseñó la serie RA de microcontroladores exactamente con esos objetivos. Las series RA6 y RA4 incluyen dispositivos con una CPU ARM Cortex-M33 con TrustZone y MPU seguras. Permiten programar límites seguros para todos los tipos de memoria integrados de forma fácil y sencilla. Incorporan Secure Crypto Engine, un subsistema criptográfico (Figura 4) que proporciona una funcionalidad de elemento seguro con un mayor rendimiento y un menor costo de materiales. El SCE incluye aceleradores criptográficos de última generación, un TRNG, admite la generación de claves, la inyección de claves implementa contramedidas SPA/DPA y una clave única de hardware como raíz de confianza. Sus controladores DMA, maestros de bus, periféricos, puertos de E/S tienen atributos de seguridad dedicados y se implementa la funcionalidad de detección de manipulación. La gestión integrada del ciclo de vida del dispositivo maneja la depuración segura/no segura, la programación, admite procedimientos de devolución de material y protege el modo de prueba. Las memorias no volátiles se pueden proteger permanentemente en bloque a elección del usuario. Para obtener más información sobre las funciones de seguridad de la familia RA, visite la web de Renesas.
Autor: Giancarlo Parodi, Ingeniero principal, Renesas Electronics
