Tendencias de la seguridad en la automoción:
La atención que se presta a la seguridad también ha aumentado debido a la adopción de una arquitectura zonal frente a la tradicional arquitectura de dominio. En la arquitectura de dominio, las unidades de control electrónico o ECU (Electronic Control Units) con funciones similares están interconectadas en una subred y como resultado de ello existen numerosos dominios independientes. Los dominios se dividen en propulsión y transmisión, control de la carrocería, dominios de control de la climatización, etc., y cada uno de ellos se podría desarrollar para cumplir un nivel se seguridad diferente en función de su relevancia para los vehículos. En cambio, en el concepto zonal, las ECU están conectadas a un controlador de zona local y a pasarelas (gateways). En la arquitectura zonal, las funciones de varios controladores de dominio se concentran en un controlador centralizado. Esta concentración disminuye el coste y la complejidad del sistema porque se opta cada vez más por esta arquitectura zonal en lugar de la arquitectura de dominio. Un inconveniente de la arquitectura zonal es que necesita ECU de diferentes dominios para compartir la red de comunicación, lo cual significa que todas las ECU de la arquitectura zonal deben adoptar unos niveles más altos de seguridad.
Figura 1. Arquitectura de dominio frente a arquitectura zonal.
Para abordar la seguridad en los automóviles, los organismos públicos y las instituciones internacionales de normalización exigen a los fabricantes adoptar nuevas normas como ISO/SAE 21434 y reglamentos como UNECE (United Nations Economic Commission for Europe) WP.29 R155/R156, así como otros similar que se aplican en determinadas zonas geográficas.
ISO 21434 es una norma de ciberseguridad relativamente reciente en la industria de automoción. Se centra en los requisitos de ingeniería y de los procesos a lo largo de la vida útil del producto e incluye políticas organizativas, procesos de desarrollo de producto y gestión de problemas de seguridad durante la vida útil del producto. Para que los vehículos cumplan las normas de ciberseguridad, esta norma debe ser adoptada en toda la cadena de suministro, tanto por parte de los propios fabricantes como de suministradores directos y proveedores de software y componentes semiconductores.
UNECE R155 y R156 son reglamentos de ciberseguridad que han sido adoptados por 65 países hasta ahora. Los fabricantes de coches deben implementarlos para comercializar sus vehículos en estos países y desde julio de 2024 su cumplimiento es obligatorio para todos los vehículos nuevos en producción.
El reglamento UNECE se refiere a las especificaciones de ingeniería de ISO 21434 y exige implementar un sistema de gestión de la ciberseguridad o CSMS (Cybersecurity Management System). Este sistema debe abarcar toda la vida útil del automóvil, desde su desarrollo hasta el fin. A lo largo de todo este tiempo, el CSMS exige monitorizar las ciberamenazas e implementar un proceso para mitigarlas. En algunos casos, la técnica de mitigación puede consistir en reparar a tiempo el firmware en una ECU vulnerable. De ahí que las actualizaciones inalámbricas del firmware se hayan hecho necesarias en todos los vehículos para cumplir los reglamentos UNECE. El sistema embebido de la ECU debe incorporar arranque seguro, actualizaciones seguras del firmware y comunicación segura para garantizar una robusta actualización inalámbrica del firmware.
Un ejemplo de aplicación que requiere capacidad de actualización inalámbrica y un alto nivel de autentificación es la carga inalámbrica de dispositivos personales en el habitáculo. El WPC (Wireless Power Consortium), que gestiona las especificaciones de alimentación inalámbrica Qi®, está preocupado por los cargadores maliciosos que dañan los teléfonos y otros dispositivos. Qi 1.3 y la reciente Qi 2.0 exigen que los cargadores inalámbricos se autentifiquen criptográficamente a sí mismos para su carga a alta potencia. Para permitir esta autentificación, los cargadores inalámbricos conformes con Qi deben estar certificados (Product Unit Certificates) en el hardware del dispositivo. Estos certificados son certificados de claves públicas que los fabricantes pueden obtener de Autoridades Certificadoras Autorizadas por el WPC. Los cargadores también necesitan disponer de elementos de hardware de alta seguridad CC EAL (Common Criteria Evaluation Assurance Level) o JIL (Joint Interpretation Library) capaces de realizar una autentificación basada en firmas ECC, almacenamiento seguro de claves y almacenamiento seguro del certificado X.509.
Seguridad del software y el hardware
La función de arranque seguro es primordial para establecer la raíz de confianza en la ECU ya que el cargador de arranque seguro garantiza que el firmware ejecutado en el dispositivo sea auténtico y no haya sido manipulado durante y después de la producción en la fábrica. Por tanto, el cargador de arranque es el responsable de garantizar que el firmware utilizado sea el genuino del fabricante o proveedor directo. El segmento de memoria de los controladores que almacena el cargador de arranque seguro debe ser inmutable (o no modificable) por lo que debería estar protegido frente a escritura y programable una sola vez durante la programación inicial en la fábrica. En la secuencia de inicio, el controlador de señal digital en tiempo real ejecuta el cargador de arranque seguro para comprobar la autenticidad y la integridad de las imágenes de la aplicación. Tanto la autenticidad como la integridad se pueden comprobar con el algoritmo ECDSA (Elliptic Curve Digital Signature Algorithm) y algoritmos Hash. La Figura 2B indica los pasos para crear una aplicación con una imagen firmada y la Figura 2C muestra el proceso para verificar la aplicación por medio de un controlador de señal digital en tiempo real embebido. La Figura 2C muestra el uso de la función hash SHA-256 para obtener una síntesis y verificar el paso mediante ECDSA y el algoritmo ECDSA P-256.
Figura 2. Proceso de arranque seguro, actualización del firmware y mapa de memoria del controlador.
La función de actualización segura del firmware puede ser una sección inmutable del controlador de señal digital en tiempo real y es la responsable de interactuar con la pasarela central a través de la red del vehículo para recibir la nueva imagen de la aplicación. Como la imagen de la aplicación incorpora la IP funcional del nodo, los diseñadores se han de plantear el uso de cifrado y autentificación del nodo mediante la interfaz de comunicación para no exponer la imagen del firmware. La Figura 2A muestra el mapa de memoria para un controlador que tenga una función de actualización del firmware; generalmente necesita tres secciones de la aplicación: una sección para la imagen activa actualmente, una sección para descargar la nueva imagen y una sección de reinicio de fábrica para almacenar la imagen por defecto como mecanismo de recuperación en caso de fallo. La actualización del firmware también ha de verificar la autenticidad y la integridad, así como el proceso de arranque seguro, y necesita implementar una política de actualización para que el firmware sólo se pueda actualizar a una versión más nueva. La actualización del firmware también ha de implementar un método de recuperación del sistema que sea beneficioso en ciertas situaciones, por ejemplo cuando la imagen de la aplicación activa o la aplicación descargada no superen una comprobación de autenticidad.
Para implementar estos recursos de seguridad, la técnica recomendada consiste en utilizar un módulo HSM (Hardware Security Module) externo junto con un microcontrolador o un controlador de señal digital (Digital Signal Controller, DSC) seguro o bien un microcontrolador/DSC con un HSM integrado en un mismo encapsulado. Un microcontrolador/DSC con HSM integrado es ventajoso cuando el diseño debe ser de pequeño tamaño. Las soluciones de seguridad embebida con DSC dsPIC33, por ejemplo, admiten HSM internos y externos; ambos son ampliamente aceptados por los fabricantes de automóviles. Los HSM sirven como enclave de seguridad cuando el área de almacenamiento de claves seguras y los módulos criptográficos están separados del sistema microcontrolador/DSC principal. Esto disminuye el riesgo para la seguridad si se compara con un microcontrolador que almacene las claves en su memoria interna. El microcontrolador/DSC seguro complementa un HSM externo con funciones como memoria de arranque seguro inmutable, Flash programable una sola vez y desactivación del acceso al modo de depuración. Una plataforma ECU basada en un HSM y una familia de microcontroladores seguros se adapta mejor ya permite escoger el microcontrolador adecuado en función de los requisitos de memoria y de las funciones.
El desarrollo con un HSM externo o integrado exige conocer con detalle la seguridad y estudiar los numerosos ajustes de la configuración para cubrir los requisitos de seguridad de cada aplicación y los perfiles de seguridad buscados. Por eso es importante iniciar el desarrollo con un ecosistema de herramientas que ofrezca el desarrollo rápido de prototipos de hardware y configuradores gráficos. Otro aspecto importante es programar claves y datos secretos en el HSM durante la etapa de producción de manera segura sin exponer la información secreta. Esta preocupación se ha visto aliviada por algunos proveedores de semiconductores HSM que ofrecen un suministro seguro del HSM. Estos dispositivos facilitan enormemente la producción.
Las ECU modernas se han desarrollado de acuerdo con la arquitectura AUTOSAR (AUTomotive Open System ARchitecture). Por tanto, el desarrollo de la seguridad necesita el HSM y un microcontrolador/ DSC seguro compatible con los componentes de software AUTOSAR existentes en el mercado. AUTOSAR admite una implementación de seguridad por medio de varios bloques funcionales.
La Figura 3 muestra un diagrama conceptual de la arquitectura AUTOSAR. En la parte inferior se encuentra un DSC o microcontrolador físico y en la parte superior se halla el software básico o BSW (Basic Software). El BSW se divide a su vez en la capa de servicio, la capa de abstracción de ECU y una capa de abstracción de microcontrolador o MCAL (Microcontroller Abstraction Layer). Por encima está la capa RTE (Run-Time Environment), que proporciona una interfaz estandarizada para que una aplicación acceda a las capas subyacentes, además de facilitar la comunicación entre los componentes de la aplicación superior, programar el BSW, gestionar los recursos y los casos del BSW. En la parte superior, la capa de aplicación se segmenta en los componentes de software de AUTOSAR o SW-C (AUTOSAR Software Components). La capa de aplicación estará compuesta por muchos componentes de software, cada uno de los cuales aporta una función a la ECU.
El BSW tiene una interfaz estándar para el uso de funciones de seguridad como periféricos criptográficos, anclas de confianza y módulos HSM. La arquitectura AUTOSAR divide la implementación de la criptografía en tres capas: capa de servicio, capa de abstracción de hardware y MCAL. La capa de servicio contiene el CSM (Crypto Service Manager). Los componentes de la aplicación interactuarán con el CSM para acceder a la biblioteca criptográfica subyacente, el HSM y programar las funciones criptográficas.
La pila criptográfica (Crypto Stack) se puede configurar para utilizar las funciones criptográficas de hardware disponibles en el DSC o dispositivos criptográficos externos como un HSM auxiliar externo. La pila de AUTOSAR puede incorporar el uso de un HSM externo por medio la interfaz SPI (Serial Peripheral Interface) de MCAL y el driver criptográfico (Crypto Driver) apropiado del suministrador del HSM.
La principal función de seguridad es proporcionada por la Crypto Stack, que tiene acceso a los primitivos criptográficos y la gestión de claves. AUTOSAR admite tres protocolos de comunicación segura: SecOC (Secure Onboard Communication), TLS (Transport Layer Security) e IPsec (Internet Protocol Security). SecOC es un estándar abierto definido por la organización AUTOSAR y es el preferido para la comunicación segura entre ECU. Se puede utilizar sobre una red CAN, Ethernet o LIN. El BSW de AUTOSAR incorpora diagnóstico seguro y detección de intrusiones. En la Crypto Stack se pueden implementar otras funciones, como las actualizaciones seguras de firmware.
Figura 3. Funciones criptográficas de AUTOSAR.
Conclusión
La tendencia en el mercado de coches conectados genera preocupación por la privacidad y la seguridad a organismos públicos, fabricantes de automóviles y conductores. De ahí que las nuevas normas exijan que los coches incorporen ciberseguridad para proteger la privacidad de los datos y mejorar la seguridad. La ciberseguridad abarca toda la cadena de suministro, desde los fabricantes de automóviles hasta los proveedores de componentes. Los diseñadores pueden recurrir a un módulo HSM junto con un microcontrolador/DSC seguro o un microcontrolador/DSC con un HSM integrado en un mismo encapsulado. Además, un ecosistema formado por herramientas para el desarrollo rápido de prototipos, bibliotecas y configuradores gráficos para HSM facilita el desarrollo. Las bibliotecas AUTOSAR disponibles y el suministro de soporte también reducen el esfuerzo de ingeniería. El ecosistema ideal para un DSC o microcontrolador en el automóvil necesita ser totalmente compatible con AUTOSAR, la seguridad funcional de ISO 26262, certificación añadida de seguridad funcional y bibliotecas de seguridad. Consulte el ecosistema para automoción de los DSC dsPIC33 para más información sobre AUTOSAR, ciberseguridad del automóvil y seguridad funcional con ISO 26262.
Autor: Nelson Alexander, ingeniero jefe y responsable de marketing de producto en la unidad de negocio DSC de Microchip Technology.
