Autor: Todd Slack – Desarrollo de negocio | Marketing estratégico y de producto | CI de seguridad para automóviles y comerciales | Microchip Technology
Cuando le digo a la gente que trabajo en el sector de los semiconductores y que me dedico a la seguridad de los automóviles, suelen suponer que se trata de alarmas para coches y mandos de apertura. Aunque el robo de coches sigue siendo una preocupación legítima, hay amenazas de seguridad mucho mayores asociadas a las unidades de control electrónico (ECU) internas y a sus comunicaciones dentro del vehículo y con el mundo exterior. Aproximadamente el 50% de todos los vehículos nuevos que se vendan este año serán vehículos conectados y muchos estiman que el 95% lo serán en 2030. Estas conexiones a través de Bluetooth®, USB, LTE, 5G, Wi-Fi®, etc., aportan mucha comodidad al consumidor, pero los piratas informáticos también están entusiasmados con la creciente área de ataque. Una rápida búsqueda en Google sobre el tema de la piratería informática en los vehículos arrojará un sinfín de fallos de seguridad en el mundo real que han dado lugar a costosas retiradas del mercado, demandas judiciales y una reputación de marca perjudicada. Es un hecho: el software puede ser propenso a los errores y los errores son objetivo de los hackers. Hay muchas cosas que se pueden hacer para minimizar los errores y tomar medidas correctivas una vez detectados; sin embargo, mientras los humanos escriban nuevo código se pueden introducir nuevos errores.
Obtener acceso a la red de área de control del vehículo (bus CAN) es un objetivo común para los hackers. Se han realizado ataques que permitían a los hackers aprovechar un fallo en el Bluetooth que les permitía a su vez encontrar un fallo en el sistema operativo del vehículo que luego proporcionaba acceso remoto para manipular los mensajes en el bus CAN. Los vehículos modernos pueden tener hasta 100 ECUs con muchas ECUs críticas para la seguridad comunicándose en el bus. El bus CAN tiene varias ventajas. Utiliza un protocolo simple que es barato, extremadamente robusto y relativamente inmune a las perturbaciones eléctricas, lo que lo convierte en una opción fiable para que los nodos críticos de seguridad se comuniquen entre sí. La desventaja es que, durante décadas, la seguridad del protocolo ha sido nula, lo que significa que una vez que un pirata informático obtiene acceso, puede enviar mensajes falsos que pueden causar estragos en las comunicaciones dentro del vehículo. Algunos ejemplos son la activación o desactivación de los limpiaparabrisas, el apagado de los faros, la distracción del conductor mediante la manipulación del audio, la creación de falsas alarmas en el cuadro de instrumentos, la visualización incorrecta de la velocidad, el movimiento de los asientos o incluso la salida del coche de la carretera. La buena noticia es que con la llegada de CAN FD hay bytes adicionales disponibles en la carga útil del mensaje para añadir seguridad mediante la inclusión de un código de autenticación de mensajes (MAC) para verificar criptográficamente la autenticidad del mensaje, filtrando así cualquier mensaje falsificado. Hay dos tipos de MAC para elegir: un HMAC basado en hash o un CMAC basado en clave simétrica AES. La CMAC se implementa en la inmensa mayoría de las veces.
Los fabricantes de equipos originales han estado muy ocupados actualizando sus especificaciones de ciberseguridad en respuesta a todos los hackeos que han tenido lugar. Casi todos los fabricantes de equipos originales están exigiendo que las ECUs críticas para la seguridad se actualicen para implementar sus nuevos requisitos de ciberseguridad y algunos fabricantes de equipos originales están exigiendo que el 100% de las ECUs conectadas se actualicen. El bloque de seguridad fundamental es la implementación del arranque seguro, que implica la verificación criptográfica de que el código de arranque y de aplicación que se ejecuta en un controlador de host no se ha modificado y se encuentra en un estado de confianza al encender, reiniciar y, a menudo, repetir en una cadencia prescrita una vez arrancado. En segundo lugar se encuentra el requisito de admitir actualizaciones de firmware seguras. Recordemos que todo el software puede estar sujeto a errores; por lo tanto, a menudo es necesario crear parches de errores de firmware que puedan aplicarse sobre el terreno. Estas actualizaciones de firmware también requieren implementaciones de seguridad criptográfica que normalmente exigen que las cargas útiles del firmware entrante se cifren con una clave simétrica (AES) y se firmen con una clave privada asimétrica, casi siempre criptografía de curva elíptica (ECC). De este modo, cuando se presenta una imagen de actualización al controlador anfitrión, no se realiza ninguna acción hasta que la firma de la carga útil es verificada por la clave pública ECC embebida en el controlador. Una vez verificada la firma, la imagen puede ser descifrada y el firmware del controlador actualizado con el parche de error o la mejora de características. La tercera incorporación en la evolución de la seguridad es la autenticación de los mensajes, como se ha descrito anteriormente.
La necesidad de autentificar las baterías es única en el sector de los vehículos eléctricos. La mayoría de los paquetes de baterías están diseñados con módulos de batería reemplazables dentro del paquete más grande, de modo que cuando un módulo falla puede ser reemplazado sin tener que reemplazar todo el paquete o lidiar con un paquete de bajo rendimiento. Los módulos mal diseñados pueden suponer un riesgo para la seguridad y provocar un incendio en el vehículo; por ello, es importante que los fabricantes de equipos originales apliquen una gestión del ecosistema, lo que significa que cada módulo debe ser autentificado criptográficamente para verificar que la fabricación del módulo ha sido examinada y aprobada por el fabricante antes de permitir su funcionamiento dentro del pack. Un módulo que no provoca incendios, sino que tiene un rendimiento inferior, puede dañar la reputación de la marca OEM, lo que puede dar lugar a una opinión de prensa negativa y a la pérdida de ingresos. Otra razón más para verificar criptográficamente la procedencia del fabricante del módulo.
¿Qué significa verificar criptográficamente un módulo? Esto se consigue configurando claves de firma específicas del cliente que se utilizan para aprovisionar dispositivos con cadenas de certificados x.509 específicas del cliente y un certificado único a nivel de dispositivo basado en un par de claves ECC únicas. El dispositivo aprovisionado se monta en cada módulo de batería. Cuando se sustituye un módulo de batería dentro del pack, el Sistema de Gestión de Baterías (BMS), también conocido como puerta de enlace de la batería, consultará al módulo su certificado X.509 único y verificará las cadenas de firmas hasta una raíz de confianza. Tras la verificación de la firma, se presenta un reto al módulo para que lo firme con la clave privada asociada, demostrando el conocimiento de un secreto sin transmitirlo en el bus, en algunos casos transmitido por RF. El caso de uso a nivel de módulo se detiene ahí. Dentro del BMS, los OEM suelen requerir un caso de uso más complejo. Dado que el BMS/Gateway es el punto de comunicación con el mundo exterior que proporciona informes rutinarios del estado de la batería a la nube, el caso de uso de la seguridad se amplía para incluir el arranque seguro, la actualización segura del firmware y la seguridad de la capa de transporte (TLS) para establecer un canal de comunicación seguro con la nube.
Todas las implementaciones de seguridad analizadas requieren un almacenamiento seguro de las claves, lo que sólo puede lograrse con una verdadera seguridad basada en hardware. Puede ser fácil extraer las claves de los microcontroladores estándar e incluso de muchos que dicen ser «microcontroladores seguros» realizando algunos ataques estándar a través de la microprobación, la inyección de fallos, los ataques de canal lateral electromagnético, los ciclos de temperatura/energía/interferencias de suministro y los ataques de temporización, por nombrar algunos. Es importante seleccionar el dispositivo adecuado para realizar el trabajo criptográfico y proteger las claves contra este tipo de ataques. Los dispositivos de seguridad especializados se presentan en una variedad de arquitecturas y se denominan con diferentes términos, como módulos de seguridad de hardware (HSM), tanto en la placa como externos, elementos seguros, subsistemas de almacenamiento seguro, bóveda de claves, tarjetas inteligentes, etc. Estos dispositivos deben incluir protecciones contra los ataques mencionados para proteger las claves en su memoria segura.
Pero ¿cómo puede un proveedor de primer nivel o un OEM verificar que la seguridad implementada es lo suficientemente buena? La mejor manera de que un proveedor de elementos seguros demuestre que su seguridad es suficiente es someter el dispositivo a un tercero para que realice una evaluación de la vulnerabilidad. El tercero debe estar acreditado por una fuente de confianza, como el NIST (Instituto Nacional de Estándares Tecnológicos), reconocido en Norteamérica, la BSI (Oficina Federal de Seguridad de la Información) en Alemania, o el SOGIS (Grupo de Oficiales Superiores de Seguridad de los Sistemas de Información), reconocido a nivel mundial. Los laboratorios acreditados por SOGIS utilizan un sistema de puntuación de evaluación de vulnerabilidades reconocido mundialmente por la JIL (Joint Interpretation Library) que requiere una evaluación de «caja blanca», lo que significa que el proveedor de circuitos integrados debe proporcionar al laboratorio la documentación sobre el diseño del dispositivo (flujo de datos, subsistema, definición del mapa de memoria), la secuencia de arranque del hardware y el firmware, la descripción de los mecanismos de protección de la seguridad, la hoja de datos completa, la documentación de orientación sobre seguridad y el cargador de arranque, todo el código disponible (nivel RTL y C, biblioteca de criptografía, FW), las implementaciones de algoritmos, los scripts de programación, el protocolo de comunicación, el diseño del chip y el código fuente. A continuación, el laboratorio revisa toda la documentación y traza su plan de ataque contra los dispositivos de muestra presentados. El sistema de puntuación asigna puntos basándose en el tiempo que se tarda en extraer una clave secreta, el nivel de experiencia requerido (desde un reciente graduado universitario hasta múltiples expertos), el conocimiento del objetivo de la evaluación (TOE), el acceso al TOE (cuántos dispositivos de muestra para realizar un ataque con éxito), la complejidad y el coste del equipo de hacking y la facilidad de acceso a las muestras.
Las puntuaciones JIL resultantes comienzan con ninguna calificación, luego Básica, Básica Mejorada, Moderada y Alta, que es la mejor puntuación posible. Todo lo que esté por debajo de JIL Alto significa que el laboratorio fue capaz de extraer la(s) clave(s) privada(s) del dispositivo. Los dispositivos como el HSM externo CryptoAutomotive™ TrustAnchor100 (TA100) de Microchip que han recibido una puntuación de JIL Alta, son capaces de resistir ataques durante más de 3 meses de ataque, momento en el que el laboratorio declara el dispositivo «No práctico» para atacar.
La cuestión es si se trata de un dispositivo «on-die» o «off-die». Las soluciones on-die, como los MCUs de doble núcleo de 32 bits, pueden suponer una costosa actualización de una ECU de la generación anterior que podría haber sido perfectamente servida por un MCU estándar antes de que la verdadera seguridad fuera exigida por un OEM. También pueden introducir retrasos significativos en el tiempo de comercialización debido a la necesidad de rediseñar completamente el código de la aplicación. Puede ser muy arriesgado asumir el desarrollo del código de seguridad en la propia empresa y el coste de pagar a un tercero puede ser prohibitivo. También es difícil para un proveedor de primer nivel proliferar la solución en múltiples tipos de ECUs, dados los diferentes requisitos de rendimiento y periféricos de cada tipo. Aquí es donde los HMS externos o los elementos seguros complementarios pueden reducir significativamente la carga de actualización de la seguridad para los proveedores de primer nivel. Pueden añadirse junto a un MCU estándar en un diseño existente o atornillarse a todos los nuevos diseños con diferentes requisitos del MCU anfitrión. Los HSM externos, como el TA100, vienen preaprovisionados con todos los códigos de seguridad, claves y certificados, lo que reduce drásticamente el tiempo de comercialización. Es fácilmente transportable a cualquier MCU dada la criptobiblioteca asociada que es agnóstica al MCU. El riesgo, el tiempo de comercialización y el coste global se reducen, lo que proporciona a los proveedores de primer nivel una vía ágil para alcanzar negocio antes que su competencia, que sigue un camino totalmente rediseñado.
Con los coches conectados de hoy en día y el intenso tráfico de comunicaciones de red en el vehículo, la necesidad de seguridad en el automóvil se amplía claramente más allá de las alarmas de los coches. Con la seguridad y la reputación de la marca en juego, es más importante que nunca seleccionar dispositivos verdaderamente seguros que hayan sido examinados por terceros al actualizar las ECU para satisfacer la multitud de nuevas especificaciones de ciberseguridad de los OEM, las normas SAE e ISO y los mandatos de seguridad de los gobiernos regionales.
