车辆网络安全开发体系研究

泛亚汽车技术中心有限公司 吴 越

车辆网络安全开发体系研究

泛亚汽车技术中心有限公司 吴 越

一、车辆网络安全简介

曾有人做过统计，一辆现代化的汽车，包含了上百兆的代码程序，分布运行在车辆的50-70个独立的电子控制模块（ECU）中。这些ECU通过整车网络（例如CAN总线）来进行通信。由于现在的车辆ECU软硬件设计基本上都是从功能实现的层面上来考虑的，并没有特意去关注网络安全防护的因素。因此，车内越来越多的ECU的使用必然带来了越来越多的受攻击面。另外，车内越来越开放的信息娱乐系统平台架构以及越来越多的和车外通信能力的建立（例如WIFI，Cell Phone，BT，LTE等）也增加了攻击者对车辆攻击和控制的手段。如图1所示，现代车辆的攻击面非常的多。

图1 ： 现代车辆攻击面分析

综上所述，这些增加中的攻击手段以及越来越多的攻击面给攻击者提供非常多的选择来对汽车进行攻击。由于所有的车辆ECU都挂在整车网络总线上进行通信，所以任何一个点被攻破都会存在巨大的风险，使驾驶者丧失对车辆的控制权，从而导致无法预料的事故发生。

因此，车辆网络安全体系的建立对于整车厂来说，是一件迫在眉睫的事情。这里之所以说是网络安全体系，是因为网络安全防护并非只是针对车内电子系统的抗侵入以及对抗非法控制的安全设计的技术防护手段，也需要包括对整个制造环节的安全管理流程体系的建设。任何一个环节的出错都会导致车辆网络安全防护的崩溃。举个简单的例子，车厂对于车辆网络安全的电子设计防护非常严密，但是由于在安全管理方面对人员的培训不够，导致了密钥或者硬件加密模块的非法流出，造成安全防护设计的失效。另一个可能的例子是，网络安全体系设计很完善，管理流程也非常到位，但是在对ECU的安全防护设计上有某一个ECU的设计没有严格按照网络安全规范来做（可能是供应商的疏漏，或者是设计时未采用安全编程的概念等）导致被攻击者攻击并获取控制权，那么其他的ECU所做的再完美的防护工作也有可能因为这个薄弱环节而变得没有意义。此外，这个体系需要贯穿整个车辆产品生命周期，一旦发生任何被攻击的事件，需要对攻击事件进行快速分析和响应，以期做到将损失降低到最小程度。如何将网络安全防护开发融入到现有的整车电子设计及管理体系中，形成一整套车辆网络安全防护设计管理体系，是我们迫在眉睫的任务。

二、车辆网络安全开发体系研究

网络安全开发体系是现在广泛存在于IT企业的一套体系，其中最著名的是微软公司针对其操作系统的安全性问题而研究出的一套安全开发生命周期体系SDL（Security Development Lifecycle）。事实上，现在大部分IT企业的网络安全开发体系都是针对SDL结合自身产品开发周期的应用。一个标准的SDL开发周期，主要由前期人员培训，需求输入，开发设计，集成实现，测试验证，产品发布以及售后响应这七个步骤来实现的（如图2所示）。

图2 ：标准SDL开发流程

对于车厂来说，SDL也是一个值得参考的安全流程体系，但是如何将SDL融合到本身的整车制造流程体系中，形成符合整车厂开发制造流程的车辆网络安全开发体系是首先需要解决的事情。

1.完成核心培训

在整车制造的设计策略制定（DSI）节点之前，也就是大概在整车制造周期的-172周之前，就必须完成人员培训，主要是针对参与项目设计、开发、测试和制造的相关人员进行车辆网络安全核心培训，强化对于安全设计开发，以及安全管理流程的认识，从而建立起必要的网络安全防护概念。

2.制定需求策略

在设计策略制定（DSI）节点（-172周）到整车项目启动（VPI）节点（-144周）之间28周左右的时间，需要对开始着手制定整车网络安全防护的需求策略，明确防护目标对象以及安全漏洞会造成的潜在威胁，对这些威胁进行风险评估，从而有针对性的制定网络安全需求，以达到平衡网络安全和整车开发成本之间的矛盾。

由于每个车型的受攻击面是不同的，因此需要根据每个车型所使用的通信和接口类型进行系统分析，识别出潜在的受攻击面，也可以引入之前的一些安全问题的案例来明确车辆网络安全防护的目标对象。对于这些识别出的目标，需要进行潜在威胁分析。潜在威胁分析的手段有很多，可以通过一定的流程，来确定目标可能面临的受攻击环境（可以通过一些测量，假设以及总结的经验教训）来定义攻击模型，确定可行的攻击手段和攻击路径。此外，开发人员还可以通过查询通用缺陷列表（Common Weakness Enumeration，CWE）来识别潜在威胁。CWE是一个计算机通用安全缺陷列表，由来自企业、学术机构和政府部门的大量国际安全专家编译和更新，列表包含了足够的深度和广度的已知安全缺陷，足够作为开发人员进行威胁分析的参考文件。

对于已经识别出的潜在威胁，安全开发人员还必须对这些威胁进行风险分析。一般风险分析主要分为两大部分，主要是评估一个潜在威胁目标的被攻击难易度(Attack Potential)以及受到攻击后所造成的破坏程度(Damage Potential)，而目标对象的风险就是受攻击的可能性乘以收到攻击后所造成的破坏，也就是：

Risk＝

整车厂商需要根据自身对于车辆的认识知识以及外部资源来制定对于AP以及DP的评判标准，以便结合自身实际情况来最好的分析整车安全威胁的风险情况。以此来识别出哪些威胁是必须要进行安全防护的，哪些则可以不用，以便最好的来平衡安全措施和整车成本之间的关系。

3.制定安全规范

在整车网络安全需求策略确定之后，就必须要开始针对需求进行网络安全设计工作，与此相对应的是SDL体系中的Security Design阶段。此阶段我们需要制定相关的网络安全规范，并且对制定的规范进行仔细的梳理，来分析我们所做的安全设计工作是否能够满足网络安全需求。网络安全规范主要应该包括了系统架构，软件开发，硬件设计，数据通信加密，安全测试验证等基本规范。对于整车研发体系来说，还需要制定生产线以及售后安全防护规范，IT签名服务器安全规范以及相关涉及到开发和生产使用的安全工具的规范。此外，安全规范也应该包括版本控制，安全审核，开发各阶段的评审要点指导文件，最佳实践以及经验总结等操作流程规范的制定。而对制定的规范进行梳理也需要遵循一些原则，例如需要确保制定的规范能够完全覆盖前一阶段输入的网络安全需求；还需要确保各子系统组成的系统也能够满足需求；还需要确保规范的要求的一致性（不同规范可能对某些技术要求有不一致的规定）以及准确性。在完成安全设计工作之后，我们还需要针对应用了安全设计规范后的整个系统再进行一次风险分析，确保我们的网络安全设计能够有效的增加攻击难度（AP），降低整个系统的安全风险，使风险降低到一个整车厂可接受的程度。

网络安全防护需求和网络安全设计这两个阶段的工作需要在整车项目启动（VPI）节点之前的28周左右的时间内完成，作为项目启动的输入文档。在VPI之后，项目定点供应商（如有）之前，在对供应商进行常规的技术方案评审的阶段，我们需要增加安全开发能力的技术评审。对供应商输入安全需求，评估他们的方案。如果没有供应商参与，零部件软硬件均为自主设计开发的，也需要在VPI之后花一些时间让参与设计开发的工程师和负责安全设计的工程师进行充分交流，确保理解安全需求和设计规范。

4.安全技术的集成和实现

从零部件供应商（如有）定点到整车工程发布（IVER，-86周）节点这一段时间内，就是安全技术的集成和实现阶段，相对应的是SDL中的Implementation阶段，是零部件或者子系统开发人员针对安全技术规范的具体实现的阶段，需要开发人员严格按照技术规范以及采用相关的安全工具来进行开发，也需要项目管理人员严格按照网络安全开发流程来进行项目管理，对开发文档进行检查，并且使用相关工具对开发人员编写的代码进行自动静态分析，通过静态反编译、模型检验等技术来分析软件可能产生的执行流程和可能达到的状态，实现对软件内部机理的解析，以确保所有的安全编程策略都能够被严格的遵照执行。举个例子，如果系统使用C语言进行开发，那么可以按照MISRA-C的规则来进行开发，相应的就必须使用对应的静态分析工具来确保所有的规则被有效的执行了。但是静态分析工具难以全面分析软件运行中的所有行为，尤其是当软件中包含自修改代码等动态生成代码时，静态分析工具就显得无能为力了。因此，光靠静态分析是无法识别出所有的安全编程问题的，在必要的情况下，还是需要请安全专家对代码进行人工的审核，以及在测试阶段使用动态分析工具来分析软件的执行过程（这个会在后续测试环节具体展开）。在集成实现阶段，开发团队需要确保安全开发能够在技术上以及流程管理上完全覆盖所有的安全规范。

5.测试验证

在整车工程发布节点（IVER）之后，到车辆测试完成（VTC，-21周）这个节点的这段时间，需要对子系统零件进行测试验证，对应标准SDL中的Validation这个环节。测试验证既是整车零部件开发流程中的一个重要环节，也是整个车辆网络安全开发中的重要一环。如何有效的进行网络安全方面的测试，识别出尽可能多的潜在安全漏洞，防止零日攻击（0-Day Attack）在汽车领域发生，值得我们好好研究。一般来说，子系统安全测试包括几个方面，首先测试工程师需要针对零部件的安全设计规范来制定针对零部件的测试验证流程文档，主要针对设计系统的软硬件，及功能等进行测试。举个例子，如果子系统安全规范规定了硬件设计在产品阶段不能留编程接口，或者规定了软件设计不能使用一些函数，那么在测试中，都需要对这些要求进行验证，详细检查软硬件的设计是否执行了规范的要求。此外，功能测试也是一个可以检查系统安全问题的方法，一些功能上的缺陷故障，是可以被攻击者利用来攻击或者控制系统的。所以越少的功能缺陷故障也意味着越少的被攻击可能性。我们还需要采用一些标准的测试向量来对于一些使用了标准加密算法或者标准加密模块的系统进行测试。例如对于AES、RSA、MAC等标准加密算法的测试，以及对于SHE这样的标准硬件加密模块的功能测试。需要注意的是，测试流程编写者一定要避免自己来编写测试向量，一定要采用国际或者国内标准组织（例如NIST Cryptographic Algorithm Validation Program）所提供的测试向量来进行测试。

当然光有上述这些基本测试是不够的，针对网络安全的很多特性是无法使用普通测试来验证的。标准SDL中的软件动态分析，以及模糊（Fuzzing）测试等方式也同样适用于整车电子系统测试验证中（尤其是信息及娱乐系统）。一般来说，我们需要采用一些受信任的安全动态分析工具来对正在执行中的系统软件进行过程监控，提取数据，分析软件的行为和内部逻辑实现，以此来挖掘软件运行过程中的缺陷导致的漏洞，检测软件隐藏功能导致的后门。模糊测试是另一个非常重要的测试软件、网络和系统接口安全性的方法，本质上也是动态分析的一部分，其主要是通过向系统发送各种有问题或者大量的随机数据来检测系统在处理这些异常输入时是否会导致异常，从而检测出安全缺陷。模糊测试可以是安全专家针对特定系统特定软件做的定向测试，也可以使用一些特定的工具来针对系统的网络，接口，所使用的标准协议以及相关配置文件等进行扫描来发现系统的安全缺陷。例如，Codenomicon的Defensics就可以针对当前IT行业中的大量标准协议进行安全漏洞扫描，从而来发现使用这些标准协议的系统的安全漏洞。除了模糊测试之外，另外一个必要的网络安全测试手段是渗透测试。渗透测试本质上是对系统的硬件、软件以及使用的网络进行受许可的黑客攻击行为，来发现系统易受黑客攻击的漏洞，是一种实战的攻防行为。安全专家可以采用任意手段来攻击系统，最终来攻陷以及控制系统。通常，渗透测试的手段能够有效的检测出系统的软件，硬件以及网络的各种漏洞，属于系统发布之前对其所有实行的网络安全防护策略的实战检验，一般需要有丰富经验的安全专家来主导进行此类测试。

6.发布

在经过大量的独立的针对车辆网络安全防护的测试之后，需要对受测试的模块或系统出具测试报告，在相关安全专家的指导之下，开发团队需要对测试中发现的问题进行修复解决，如果是软件问题，那么发布新版本软件并再次交由测试团队进行测试验证；如果是硬件问题，则需要在新版硬件设计发布之后先进行DV及EMC测试，通过后在进行网络安全验证，从而形成一个闭环。并且在车辆测试完成的时间节点之前，完成最终的网络安全测试，提交测试报告，交由车辆网络安全防护团队签字确认。如果经测试发现有设计问题导致无法满足网络安全规范，但是该问题的解决可能会明显导致整个车辆Launch时间的推迟，那么就需要网络安全团队出具针对该问题的安全隐患的后果以及分析出现该问题的潜在可能性报告，提交项目管理团队研究是否同意偏差认可来保证整车的Launch时间或者是通过推迟发布来解决问题。零部件或子系统设计发布工程师需要将最终的网络安全测试报告（以及偏差认可）包含在最终的发布文档之内。

7.售后响应

有一点我们必须清楚的是，即使完全通过了测试，也并不能说发布的零部件就万无一失永远不会被黑客攻破了，这个世界上不存在永远无法被攻破的系统。因此，当零部件或子系统正式发布之后，网络安全团队还必须制定一套售后问题应急响应措施。一旦售后出现车辆网络安全问题时，就必须能够做到五个快速：快速响应、快速定位问题、快速出具补救方案、快速测试验证以及快速发布上线。从而尽量减小由售后产生的网络安全问题对车辆造成的危害。

综上所述，根据标准SDL的开发流程，结合整车子系统开发的要求，和整车开发的流程体系融合，我们可以设计出一套针对车辆开发的网络安全通用体系结构（如图3所示）。

每个整车厂可以根据不同的车辆开发体系流程来对上述体系进行调整，只要上述通用体系内的所有的元素都能被包含在整车开发流程之中，那么网络安全开发的架构就能被初步搭建完成。

三、结语

如果车辆的外部的接口越多，那么收到攻击的可能性就越大，而现代车辆随着越来越多的信息娱乐的元素的引入，以及更多通信，诊断等需求，对网络安全的要求越来越高。诚然，网络安全防护并不能让车辆本身产生任何直接的价值，对这方面的投入并非是可以直观感受得到的。但是，对车辆网络安全防护的投入往往是巨大的，很多时候人们会有疑问，这种投入是否值得？但就像对安全带，安全气囊等车辆功能安全性投入一样，网络安全防护措施也是属于那种不会使用到时没有任何价值，但是一旦发生事故，没有这些措施往往会造成非常严重的后果。从某种角度来说，车辆网络安全的地位在未来会比车辆功能安全更加重要，试想一下，一辆车功能安全性不好，可能会使驾驶该辆车的消费者产生严重的安全性隐患；而如果这辆车的网络安全性不好，那么一旦被黑客攻破，可能会让这个车型的已发售车辆同时产生巨大的潜在安全隐患，造成巨大的社会负面效益，甚至是恐慌。未来的车自动化程度越来越高，相信没人愿意自己的车辆的控制权掌握在别人的手里，政府也不会愿意看到路上跑的车辆被不怀好意的攻击者所控制，造成严重的安全事故。因此，每一个负责任的整车制造企业，都至少应该将车辆网络安全防护作为一个重要程度与车辆功能安全同等安全性要求来对待，并尽快建立起网络安全的相关专业团队，做好面对将来网络安全的严峻挑战。政府方面，也应该积极引导企业建立起网络安全防护的体系，制定相应的国家规范和标准，为将来的智能交通网络的建设做好充足的准备工作。

图3 ：车辆系统网络安全开发体系