![]()
![]()
当下，汽车产业正在进行着深刻的变革，不断地朝着“四化”（智能化、电动化、网联化、共享化）方向进行着转型升级。而这一进程中，需要依赖车载控制器作为支撑。那么，控制器支撑的核心又是什么呢？就是它所承载的软件。所以，SDV（Software-Defined Vehicle ，软件定义汽车）已不再是一个时髦的词汇，而是真实的扮演着举足轻重的角色。但是，车载控制器软件的开发并不是一个简单的过程，在它工程落地的过程中，会遇到各式各样的问题，在 ETAS 最近发布的白皮书《汽车微控制器软件开发的五大挑战》(1) 中，总结了五个方面： 高度集成任务、标定过程复杂、测试和调试耗时、可拓展和灵活性的限制、整体网络安全需求。既然车辆需要变得更“聪明”，就需要控制器之间进行大量的信息交互，也因此，这些交互的控制器构成了局部网络。当车辆内的各个局域网的信息进行交互时，又构成了更大的网络簇。更进一步的，车辆网络与外界交互时，车辆就成了一个网络移动终端，成了万物互联的一部分。当车辆成为网络的一份子时，它不得不面对复杂的网络威胁和攻击。因此，网络安全就不得不引起我们的格外关注，更具体的说：车辆传输和记录的敏感信息安全，不可忽视！那么，什么是汽车信息安全（Vehicle cybersecurity）呢？按照法规(2)解释：汽车的电子电器系统、组件和功能被保护，使其资产不受威胁的状态。不可置否，车辆信息安全已经进入法规强标阶段。出口海外的车辆，需要满足联合国世界车辆法规协调论坛（简称为UN/WP.29）发布的R155和R156要求。在国内，《汽车数据安全管理若干规定（试行）》于2021年 10月 1 日起施行，《汽车数据通用要求》于2024年8月23起实施，《汽车整车信息安全技术要求》将于2026年1月1 日起实施...由此可以看出，车辆信息安全已然成为软件开发不可忽视的问题。那么，为什么车辆信息安全近些年会引起如此关注和重视呢？甚至于通过法规进行强制性约束呢？这与近些年不断攀升的信息安全事件密不可分，部分车辆信息安全事件如下：（1）丰田汽车数据泄露事件。2023 年 5 月，丰田汽车公司发布公告称，由于云平台系统配置错误，约 215 万日本车主的部分车辆数据在近十年间处于公开状态，包括车载设备 ID、底盘号码、车辆位置信息等(3)；（2）蔚来汽车电池数据被篡改事件。2023 年 5 月，蔚来汽车的电池数据被篡改，犯罪团伙通过将事故车和故障电池组的数据写入完好电池组，使其可以重新充电上路(4)；（3）高通芯片黑客攻击事件。2024 年 10 月，高通公司发现其多达 64 款芯片组中存在严重漏洞，可能导致内存损坏，黑客可以利用这些漏洞对智能网联汽车进行远程控制，威胁车主的生命安全(5)；如上的汽车安全问题事件很多，近些年更为突出。据 Upstream 发布的《2024 年全球汽车网络安全报告》显示，近 5 年汽车安全事件不断攀升，如下所示：![]()
那么，造成车辆信息安全问题的途径有哪些呢？车辆被攻击的路径包含车内和车外两条路径。车内信息安全威胁源主要是持有恶意攻击软件的 ECU。车外信息安全威胁源包括：外部设备连接，比如：通过 OBD（On-Board Diagnostics）连接的诊断仪等外部设备，Debug 调试口，XCP 标定口，OTA（Over-The-Air）、蓝牙、WIFI 等。示意如下：
如上是我们可以直接想到的攻击路径，具体的车辆网络攻击方式远比我们认知的方式多的多。相比以往，2023 年，网络攻击变得更为复杂和频繁，攻击的目标包括各种车辆系统和组件，以及智能出行平台、物联网设备和应用程序。新的攻击方法让行业深刻认识到：任何连接点都可能成为攻击的目标(6)。
面对严峻的车辆信息安全事件，从控制器软件供应商到 OEM 都已深刻意识到车辆信息安全的重要性。但是，这并不等同于可以开发出符合预期的软件，那么，车辆信息安全的工程落地，到底有哪些难点呢？任何软件的开发，第一步就是搞清需求。只有准确理解需求，才有可能开发出符合预期的软件。目前，信息安全在项目实施过程中，需求握手还很难一次性达成。很难一次性达成的原因大致有如下几点：首先，汽车行业从业者对信息安全的需求认知薄弱。不同于互联网行业，车辆信息安全在汽车行业刚刚兴起，所以，汽车信息安全工程师解读需求还需要时间以及工程项目的沉淀。举例：信息安全中有“验签”（verification）需求，可是在拆分需求时，有时系统工程师也分不清验签的工程使用场景，进而导致对具体算法的使用场景一知半解。所以，在理解需求之前，需要理解清楚验签的使用场景。首先， 软件程序升级时需要验签。其次，每次控制器上电，运行程序前需要验签每一个需要执行的程序。需求初步分解示意如下：需求理解到如上颗粒度（Granularity）就可以吗？不能。实际的工程中，不同控制器，芯片选型不同。不同的芯片类型，能满足的信息安全功能程度又不同，或者说对应的信息安全功能硬件化程度也就不同，需求也就不能一概而论。所以，信息安全需求解读难的第二个点就是对使用的芯片认识不足。对于信息安全系统工程师而言，针对信息安全需求的拆解必须结合项目使用的芯片类型。但是，如果要了解芯片特性，就需要“啃”那厚厚的芯片手册，而这无疑是耗费费力的事情，甚至会让不少系统工程师望而却步。如果不能深刻的认识芯片，那么，在信息安全需求沟通中，就可能产生理解偏差，甚至产生开发结果与需求不符的窘境。这里举一个工程案例：需求要求实现随机数功能，如果所用芯片支持真随机（True Random Number）功能，则随机数必须由硬件实现。如上需求表明了随机性功能的实现优先由硬件实现。可是，工程师沿用了之前软件实现的方案。这问题之所以被暴露出来是因为软件升级过程中，诊断获取的随机种子偶有全 0x00 情况，细致追查发现：软件的随机性实现存在一定的 Bug，偶有返回异常，进而返回全 0x00 工况。这个问题看似简单，但是，如果需求没有充分解析并执行，那么，就可能引入更多的 Bug。当然，信息安全对汽车领域从业者，不仅新，而且，随着信息安全的需求不断扩充，使得需求需要解读的信息量不断增加，这亦增加工程师的解读成本。通过需求拆解以后，对于软件开发工程师而言，就需要设计软件架构，之后，按照软件架构实现信息安全的功能。信息安全软件的实现又难在哪里呢？首先，软件架构不统一。在实际项目开发过程中，软件工程师很多时候会从其他的项目中“搬运”已有的功能，如果搬运的功能模块与新的项目软件架构冲突，工程师往往会做一些手动修改，如此，就会引入未知变量，增加潜在软件漏洞。举例：工程中可能会遇到这样的场景，即：只有 HSM 的软件包，但是，Host 端的软件程序没有配套的信息安全软件接口。为了降低成本，需要工程师开发对应 Host 的信息安全接口。如此，带来的直接问题就是两者的框架不统一，而这就是一个安全隐患。软件架构设计中，某个功能的实现由一个工程师完整实现能最大程度的保证一致性，如果一个功能由两个或者多个工程师实现，则很难做到预期的一致性。 示意如下：其次，软件调试困难。软件开发的好坏很大程度上依赖软件的调试环境。调试软件不仅仅需要价格昂贵的硬件调试设备，还需要对应的调试软件，这些软硬件设备的使用需要工程师的储备，这无疑增加了软件开发的困难。这里以英飞凌 TC3xx 芯片的信息安全调试为例。如果一个信息安全工程师需要调试信息安全功能，基本的硬件环境包括：包含所需软件的电脑、调试器硬件、目标控制器对应的芯片。示意如下：软件的编译需要对应的编译器（compiler），而且编译器需要支持信息安全工程的编译与非信息安全工程的编译；软件调试，调试器需要对应的软件，调试的信息安全，如果包含异构多核，调试器则需要多个 license，以便于支持多核调试。实际的开发中，除此之外，工程师还可能需要了解第三方工具的配置和使用环境，eg：MCAL 配置 工具，BSW 配置工具等。再次，手动软件质量不可控。实际的工程开发中，有些功能属于项目特有的，这些功能无法通过工具链自动化实现，因此，需要软件工程师手动编码实现。手动编码的质量很大程度上依赖于工程师的编码水平和对需求的理解，所以，这也在一定程度上增加了信息安全开发的难度。软件开发完成以后，工程的接力棒需要递交给测试人员，由测试人员通过压测识别出软件潜在的漏洞。那么，对于信息安全来说，测试的难点在哪里呢？首先，测试用例设计难。由于测试人员和开发人员的属性不同，测试人员往往不关注实现的细节，因此，也不会过多的关注芯片手册信息。但是，脱离了这些细节信息，往往又会使得测试人员难以理解测试的需求，进而在设计测试用例时，会出现测试边界模糊，测试方案不准确的问题。其次，测试设备使用成本。信息安全的测试中，需要用到的测试设备或者环境不同于传统开发，因此，具体信息安全测试前，需要测试工程师对信息安全的测试环境有一定的经验。而且，信息安全功能需要与 Host 进程（eg：Bootloader 工程、Application 程序等）进行交互。这样的交互系统，无疑增加了测试的复杂度。对于测试人员，这样复杂的系统交互场景，靠传统的测试工具并不能达到测试目标。Host 进程与信息安全进程通过IPC（Inter-Process Communication， 进程间通信）交互的场景，示意如下：再次，白盒打桩测试强依赖开发环境。信息安全的测试中，部分测试需要通过软件打桩的方式进行白盒测试，而这无疑增加了测试的难度。具体难点：信息安全工程师需要有一定编码能力，同时，需要知道如何编码对应的信息安全功能接口，进而达到条件修改测试的目的。除了如上的测试困境以外，还需要考虑测试的如下问题：CWE （CommonWeakness Enumeration）缺陷测试。既然信息安全工程是一个独立的软件进程，首先需要确保该工程的可靠性，尽可能的通过软件的静态测试和扫描（eg：TESSY 测试等），发现可能导致安全问题的编码错误或者设缺陷。当然，随着车辆接入网络的程度越来越高，网络攻击的途径和方式也越多，在成本允许的条件下，可进行渗透测试（Penetration Testing），以此识别出系统中的安全漏洞。你可能好奇：对于MCU级的控制器，有这样的攻击场景吗？有。网络的攻击已经不仅仅局限于以太网。CAN总线的攻击也变得越来越多，比如：CAN DOS（Denial ofService，拒绝服务）攻击、CAN 报文窃取、CAN报文重放、CAN 报文丢失等。所以，这些测试用例的设计和覆盖，本身亦是一个艰巨的任务。面对复杂多变的车辆安全威胁，法规不断强化信息安全规范。然而，信息安全的工程落地依然面临着这样、那样的难点。这包括信息安全需求解读难、开发难以及测试难等诸多问题。如何应对这些难点，使其真正的落地工程，还有很长的路走。
参考文献：
（1）易特驰白皮书发布-汽车微控制器软件开发的五大挑战
（2）GB 44495-2024《汽车整车信息安全技术要求》（3）https://mp.weixin.qq.com/s?__biz=MzAwMDE1NzIwMw==&mid =2652221905&idx=1&sn=4643d5a5fecb34ea6a3b5029d2f5fd77& chksm=810c22adb67babbb36419ef2c6f92316ac1d3025648530061 c53f968fc98a87d61d0a42844ff&scene=27（4）https://news.sohu.com/a/808555084_121738491（5）https://baijiahao.baidu.com/s?id=1815249214872984940&wfr=spi der&for=pc（6）Upstream_2024_Global_Automotive_Cybersecurity_Report.pdf-end-
本专栏是由汽车电子与软件打造的中立性技术科普专栏，将系统地阐述软件定义汽车下的关键挑战和工程实践。欢迎订阅本专栏！
![]()
![]()
