¡Hola, Charlie Miller! Hablemos sobre la protección de los vehículos autónomos

Un artículo reciente de Wired sobre Charlie Miller (infamemente conocido por piratear y controlar un Jeep de forma remota) afirma que la “conversación abierta y la cooperación entre empresas” son requisitos previos necesarios para construir vehículos autónomos seguros. Esto parece bastante inverosímil cuando tantas empresas están compitiendo para dominar el futuro de la industria automotriz, una vez casi muerta pero recientemente revivida (¿recuerdan los tres grandes rescates?). Tan ingenuo como suena esa parte del artículo, lo que realmente me asombró fue la implicación de que la respuesta para rediseñar la seguridad se encuentra únicamente en la industria de los vehículos autónomos.

El concepto de seguridad no se limita a los vehículos autónomos así que no hay ningún beneficio en fingir que ese es el caso. Todas las industrias de IIoT están tratando de resolver problemas similares y están sorprendentemente abiertas a compartir sus hallazgos. No estoy diciendo que Miller necesite emprender un viaje de iluminación a través de todas las demás industrias para crear la solución ideal para la seguridad. Digo que esto ya se ha hecho por nosotros, cortesía del Consorcio de Internet Industrial (IIC).

La CII está formada por más de 250 empresas de varias industrias, incluidos proveedores automotrices como Bosch, Denso y TTTech, con el mismo problema fundamental de equilibrar la seguridad, la protección, el rendimiento y, por supuesto, los costos de sus sistemas conectados. Si está cableado y Miller buscan una conversación abierta; está sucediendo en la CII. La CII publicó la Arquitectura de referencia de Internet industrial, que está disponible para todos de forma gratuita, como en "cerveza gratis", ¡especialmente si el automóvil conduce por usted! Las extensiones de este documento son el Marco de conectividad de Internet industrial (IICF) y el Marco de seguridad de Internet industrial (IISF). Estos documentos brindan orientación desde una perspectiva comercial hasta la implementación, y el IISF es particularmente aplicable ya que aborda Wired's breves menciones para asegurar los puntos finales de conectividad y los datos que pasan entre ellos.

Dé un paseo conmigo y vea cómo podríamos modificar la arquitectura del automóvil conectado para protegerlo de posibles adversarios. Dado que no tenemos ningún ataque malicioso conocido contra automóviles, podemos comenzar con el hack de Jeep de Miller. Gracias a una “función” de puerta trasera en la unidad principal de Harmon Kardon, Miller pudo ejecutar comandos remotos sin protección con bastante facilidad. A través de este exploit inicial, pudo reprogramar un chip conectado al bus CAN. A partir de ahí, tenía el control casi total del coche. Está pensando, "simplemente elimine esa interfaz desprotegida", ¿verdad?

Miller no se habría detenido allí, así que nosotros tampoco. Suponiendo que aún pudiéramos encontrar un exploit que nos otorgó acceso para reprogramar el chip ARM, entonces Wired's El artículo sugiere correctamente el establecimiento de una aplicación autenticada, tal vez comenzando con un arranque seguro para el kernel subyacente, aproveche ARM Trust Zone para la siguiente etapa de software solo crítico e implemente algún tipo de autenticación para procesos de aplicaciones y sistemas operativos de nivel superior. Es posible que el punto final de su dispositivo comience a verse como una pila de aplicaciones de confianza (Figura 1 a continuación). Solo puedo adivinar cuánto cuesta esta unidad principal ahora, pero para ser justos, estas son consideraciones válidas para ejecutar una aplicación confiable. El problema ahora es que en realidad no nos hemos conectado a nada, y mucho menos de forma segura. No te preocupes, no te dejaré junto a la carretera.

Muchas de estas aplicaciones confiables se conectan directamente al bus CAN, que posiblemente expande la superficie de ataque al control del vehículo. Los datos que se transmiten entre estas aplicaciones no están protegidos contra lectores y escritores de datos no autorizados. En el caso de los taxis autónomos, como Wired señala, los piratas informáticos potenciales ahora tienen acceso físico a su objetivo, lo que aumenta sus posibilidades de hacerse cargo de una aplicación o presentar a un impostor. Ahora la pregunta es:¿las aplicaciones pueden confiar entre sí y en los datos del bus CAN? ¿Cómo confía el grupo de instrumentos en los datos de temperatura externos? ¿Realmente lo necesita? Quizás no y eso está bien. Sin embargo, estoy bastante seguro de que el control del vehículo debe confiar en LIDAR, Radar, cámaras, etc. Lo último de lo que alguien quiere preocuparse es de un pirata informático que se lleva el coche de forma remota a dar un paseo.

Realmente estamos hablando de la autenticidad de los datos y el control de acceso:dos disposiciones que habrían mitigado aún más el riesgo contra el ataque de Miller. Asegurar las aplicaciones heredadas es un buen paso, pero consideremos el escenario en el que se introduce al sistema un productor de datos no autorizado. Este intruso puede inyectar comandos en el bus CAN, mensajes que controlan la dirección y el frenado. El CAN Bus no impide que los datos se publiquen sin autorización ni garantiza que los datos provengan del productor autenticado. No estoy sugiriendo que reemplazar el CAN Bus sea el camino a seguir, aunque no me opongo a la idea de reemplazarlo con una solución más centrada en los datos. De manera realista, con un marco como los Servicios de distribución de datos (DDS), podemos crear una arquitectura en capas según lo guiado por IISF (Figura 2 a continuación). El bus CAN y los componentes críticos del variador son efectivamente sistemas heredados para los que el riesgo de seguridad se puede mitigar mediante la creación de una barrera de bus de datos DDS. Los nuevos componentes se pueden integrar de forma segura utilizando DDS sin comprometer aún más el control de su vehículo. Entonces, ¿qué es DDS? ¿Y cómo ayuda a asegurar mi vehículo? Me alegro de que lo hayas preguntado.

Imagine una red de sensores automotrices, controladores y otros "participantes" que se comunican entre pares. Cada participante recibe solo los datos que necesita de otro participante y viceversa. Con peer-to-peer, los participantes de esa red pueden autenticarse mutuamente y, si nuestras aplicaciones de confianza se mantienen, también lo hace nuestra conectividad de confianza. ¿Cómo protegemos esas conexiones de igual a igual? TLS, ¿verdad? Posiblemente, pero con la complejidad de asegurar nuestro vehículo, queremos la flexibilidad para intercambiar rendimiento y seguridad y aplicar mecanismos de control de acceso.

Retrocedamos un poco y revisemos nuestra conversación sobre el IICF, que brinda orientación sobre conectividad para sistemas de control industrial. El IICF identifica los estándares abiertos existentes y los atribuye sucintamente a funciones precisas de un sistema de IoT industrial. En esencia, un vehículo autónomo, tan genial como suena, es solo un sistema de IoT industrial en un cuerpo aerodinámico elegante con asientos de cuero opcionales. Entonces, ¿qué sugiere el IICF para la integración de software para un sistema de IoT industrial, o más específicamente, sistemas autónomos? ¡Lo adivinaste! DDS:un conjunto abierto de estándares diseñados y documentados a través de conversaciones abiertas por el Object Management Group (OMG). Una solución automotriz ideal que aprovecha DDS permite que las aplicaciones del sistema publiquen y se suscriban solo a los mensajes que necesitan (consulte la Figura 3 a continuación para ver nuestra visión de una arquitectura autónoma). Con este enfoque centrado en los datos, podemos desglosar arquitectónicamente los mensajes en función de su importancia para la seguridad o la necesidad de integridad de los datos.

Y ahora que hemos establecido una solución de conectividad para nuestro vehículo autónomo, podemos volver a hablar sobre seguridad y nuestra alternativa TLS:una solución de seguridad centrada en datos para un marco de mensajería centrado en datos. Con DDS Security, los arquitectos de sistemas de IoT industrial pueden utilizar complementos de seguridad para ajustar las compensaciones de seguridad y rendimiento, una capacidad necesaria que no ofrece TLS (Figura 4 a continuación). ¿Autenticar solo temas de datos seleccionados, pero no más? Cheque. ¿Encriptar solo información sensible pero no más? Cheque. De hecho, hay más. Dejando de lado a los corredores centralizados, DDS Security ofrece mecanismos de control de acceso distribuidos que dictan lo que los participantes pueden publicar o suscribirse a ciertos temas sin puntos únicos de vulnerabilidad. Esto significa que a la aplicación no autorizada de Miller se le negaría el permiso para publicar comandos para controlar el frenado o la dirección. O si Miller comprometió los dato

[1] [2] 下一页