作者：黄惠斌
电子电气架构的演进
近年来，汽车电子电气架构随着新四化的推进在加速演进。多家机构及头部零部件供应商对此均做过总结。图中是其中一种对于电子电气架构演进路线的总结。一共分为六个阶段。
第一阶段是模块化的架构，每个功能对应一个控制器，我们可以称之为模块化阶段。
第二阶段是多个功能集成至一个控制器，但是本质上只是多合一的功能集成形式，这个阶段叫做集成化阶段。
第三阶段是将功能按照域进行划分，例如底盘域、动力域与智驾域，此时部分域中的功能由一个在中心的域控制器实现大部分控制功能，例如域控制器，这个阶段叫做中心化。
第四阶段会有部分功能跨域进行融合，此时某个功能很可能是跨域来实现的，从功能本身来举例，全车 OTA 功能就是明显的例子，这个阶段叫做域融合阶段。
第五阶段是当域融合到一定程度后，大部分控制器的功能都集成到了一个中央行车电脑里面，并且全车大部分算力也都集中在这个控制器里，外围只剩下传感器及执行器，这个阶段我们可以称之为中央行车电脑的阶段。
第六阶段是当中央行车电脑的功能与运算任务，部分由云端实现的架构，这个阶段是云计算的阶段。
从市场上很多公开的信息来看，大部分车型都处在第三、第四阶段，有少数在研新车型已经行进到了第五阶段，也有处于两个阶段之间的在研车型，因此并不能简单的将某款车型的电子电气架构认为完全是处在某个阶段。并且单从功能层面来讲，甚至部分功能已经是主要由云计算来实现了，而电子电气架构却还在第三阶段。
电子电气架构演进的特点
那么电子电气架构的演进有什么样的特点，我们通过这张图来展示。最近软件定义汽车的话题很火，并且也已经有部分 OEM 在研新车型已经使用了 SOA 架构及开发模式。一方面是新技术的诞生与需求的变化导致电子电气架构加速演进，另一方面电子电气架构的演进反过来给 SOA 的部署带来了很大的便利。因此我们可以认为电子电气架构带来的第一个新事物就是 SOA。
同时，高级别自动驾驶，智能座舱等热门功能对总算力的需求进一步增加，在电子电气架构上也可以明显的看到为了满足高算力的需求，分布在 E/E 架构中的各个控制器的集成程度进一步提升，这个也带来了集成化的趋势。除此之外，在原先 IT/ICT 领域的成熟技术也在大量移植到汽车工业中。例如以太网和安卓，以及在这之上的各种协议和应用，其中以太网的应用对电子电气架构及网络拓扑带来了非常深远的影响，技术移植过来就用，也是一个比较大的特点。
集中化带来了算力集中，而算力集中了之后，需要能够有效利用算力去实现不同场景的业务需求，在这个背景之下，虚拟化技术也得到了应用，使得多个类型的操作系统运行在同一芯片上。除此之外，虽然算力分布是在继续集中，但是业务场景与计算能力的多样化却在继续，在同一个控制器里面集成 CPU/GPU/NPU/MCU 等异构处理器处理复杂任务和场景的情况却越来越普遍。最后一个我们识别到的特点，就是现在几乎所有的新车型都是联网的，而且还有近场端通信，加上全车 OTA 刷新也在推广，这样我们可以看到的是，几乎所有控制器都可直接或者间接远程访问并可以刷新。
以上是我们在 E/E 架构演进中观察到的，那么这些特点和变化对信息安全有会有什么样的影响，会带来什么样的挑战呢？
电子电气架构演进带来的相关的信息安全挑战
图片
我这里挑了几个点来做分析，这个分析本身只是示例，我希望这里能够起到一个抛砖引玉的作用。我们首先看一下 SOA 带来哪些挑战。SOA 的功能与服务解耦。功能实现是抽象的。而且为了定制和迭代功能，SOA 平台中的服务往往选择开放，功能也可定制化。这样在通信层面可利用这些已有的服务，通过伪造身份实施攻击，例如 DoS 攻击。
同时，由于 SOME/IP 的 C/S 连接是在需求方有需要时建立连接，属于动态连接，用传统数据流的方法分析安全风险非常复杂。这个是 SOA 带来的一些挑战。
那么虚拟化又会带来什么呢？由于多操作系统运行在一个芯片上，不仅脆弱性增加了，漏洞的管理，修复也会更加复杂，有点牵一发而动全身的感觉。同时，虚拟机本身也可能带来额外的脆弱性。
那么异构计算又会带来什么呢？由于使用多种异构芯片，芯片之间也会交换大量片间数据，这可能导致成功实施侧信道攻击或故障注入攻击的可能性增加。
最明显的集成化趋势又会带来什么样的挑战呢？由于控制器不断集成，数量不断减少，网络层级层数也在不断减少，这样的结果就是，原先需要合并多个脆弱性构建的攻击路径会变短，在先进架构上面可能只需要合并利用少量脆弱性，跨越 2 个控制器，可能 T-Box 与中央行车电脑，大约 4 颗芯片就可以接触到执行器从而实现远程操控了。
下一个特点是现有技术的移植。现在的控制器经常大量使用开源组件，而开源组件本身就有一定风险，零日漏洞被发掘出来的可能性也大很多。并且大多数先进架构中都会使用以太网及移动 OS，原先很多分析攻击的思路，攻击用的工具也可以在车上使用。最后一个特点到不是完全由 E/E 架构演进带来的。就是网联化与全车 OTA。这个变化带来的是，几乎车上的所有控制器，随时，随地都可能遭受攻击。
这里只列举了很少一部分新挑战，实际上挑战比这里列的肯定要多得多。那么我们应该怎样去应对这些挑战呢？
如何应对新的挑战
关于应该如何应对这些挑战，我这里提出两个观点：
第一个观点，我们要具备全网络空间视角。这里指的是，在评估风险的时候，将云管端核，以及所有已售出在运行的同类型车辆当作一个整体来考虑。而要做到这样，其实对人的能力要求非常之高。
第二个观点，就是我们可以将网络空间粗略分成云管端核四个层级，我们在导出信息安全需求的时候会发现，有很多需求跨了多个层级，要实现相应的设计工作，需要有一个顶层视角开展顶层设计，最后将需求层层落实。
我将如何应对 E/E 架构演进带来的挑战归纳为以下 5 个步骤：
第一步，将全网络空间当作整体进行分析评估，这里的方法论使用 ISO21434。
第二步，在该网络空间中构建安全架构覆盖可能产生风险的方方面面。
第三步，将导出的安全需求分层布置，跨层跨终端的需求从顶层设计，部分部署在云端，路端的需求在这个层级就已经可以落地了。
第四步，将拆解到整车的信息安全需求分解到整车，此时整车会被视为一个终端。
第五步，将需求进一步分解到控制器层级，最后在控制器层级实施落地。以上是在应对新挑战时，应该关注的 2 个要点以及 5 个步骤。
可选解决方案示例
说了这么多，我们到底有没有什么切实可落地的方案呢。当然有，而且还很多。如果要设计一个可以在全网络空间中应对信息安全挑战的方案，可能最终出来一个非常庞杂的需求。如果按照 ASPICE 流程要求做条目化，可能所有层级的需求加起来会有几万条甚至更多。那我们来看一下这几个例子。
对于 SOA 架构带来的问题，其中一条需求是将服务区分成安全相关服务与非安全相关服务，在安全相关服务中执行双向身份认证。对于虚拟化带来的问题，其中一条是使用覆盖多平台的自动化漏洞管理系统。对于异构计算带来的问题，其中一条是，尽可能选择能够抵抗侧信道攻击与故障注入攻击的芯片。条件允许的情况下也可以进行相关的测试。
对于集成化趋势诞生的中央行车电脑，具有远程连接功能的控制网或者通信单元或者是域控制器，由于其在整车架构中的重要作用，可以直接把目标设定到最高，也就是参考 ISO21434 的 CAL 等级，可以直接设定到 CAL4。所有能做到的需求都上，测试也全上。对于技术移植带来的问题，可以这样考虑。既然 ICT 领域有这么多现成的工具，为什么不移植过来做测试呢。设计人员也可以学习渗透工具的嘛。比如 Kali Linux 上面的各种工具，可能已经有很多人这样做了。当然，仅限于测试用途。
解决方案在整车层级的部署
当我们生成了大量的需求，整合层一个大的综合方案之后。在整车级怎么部署呢？首先还是将需求分层，我们从顶层视角看的时候，会发现有大量的需求是部署在云端和管端的，而且在云端部署的这些需求，大多都是跨层级跨终端的需求。例如 PKI, 漏洞管理系统，IDPS 在云端的安全日志分析器等等。然后下一步就是将远程通信，近场端通信，车内通信的通信协议及安全措施定下来。比如 TLS 和 SecOC。而制定通信协议类的需求，也是需要从整体考虑的。你会发现信任链和 TEE 的建立，会一直从芯片内核的 HSM 一直延伸到云端。
解决方案在控制器层级的实施
在控制器层级的需求实施，决定了需求最终的落地，这里需要将控制器当成一个终端，整车当成一个网络。之后在系统架构中，将需求进一步定位到芯片。这里可以 ISO21434 的开发流程做指导。
电子电气架构演进的特点
我们在应对 E/E 架构的变革带来的挑战时，需要具备全网络空间的视角，因为 E/E 架构演进带来的影响并不仅仅只体现在车上，实际上体现在了网络空间里，因此我们不能只考虑车，而应该从网络空间整体考虑，覆盖 E/E 架构演进造成的方方面面的风险。
在如何解决问题上，我们需要有顶层设计，这样才能够使得跨终端的解决方案更容易实现。而正是由于解决方案很多都是跨终端的，在实际车型开发过程中，跨终端方案带来大量协调与沟通的工作，因此时间成本与开发成本也都非常巨大，如果能够有一个整体打包的综合解决方案，不论对于具体的零部件供应商，集成商还是 OEM，都将会节省大量的成本，我们相信，这样的 All-in-one 解决方案是市场趋势。虽然网络安全问题很复杂，甚至还在变得更复杂，但是能提供这样 All-in-one 解决方案的供应商是可以让这个问题变得很简单的。而中汽创智正在朝着这个方向前进。
