车辆与外部实现远近场通信的两种主要连接方式：如包括蓝牙、毫米波传感器、RFID及未来DoIP（Diagnostic Over Internet Protocal）在内的远程连接；外部诊断设备通过DLC口与整车CAN总线直接建立通讯的物理连接等。需要意识到的是：

• 任何外部设备与车内子网连接的关系都会增加车辆受到安全攻击的隐患，或造成车辆远程受控，或是恶意代码的注入。

• 任何未经授权尝试对车辆E/E电子架构访问的行为都有可能会引起致命的后果。

车辆远程诊断

目前整车厂所使用的两种车辆诊断，第一种是由模块软件自诊断实现的在线诊断模式（On-board Diagnostic System），第二种就外部诊断设备与DLC口相连，来对整车ECU节点进行诊断的离线诊断模式（Offboard Diagnostic System）。

诊断设备广泛应用于工程产品开发、工厂生产制造过程EOL阶段及售后模式的诊断，由于应用场景不同，所使用的工具不同，但通讯连接原理一致。

诊断设备Diagostic Tester(TST)通过车辆通信接口Vehicle Communication Interface(VCI)与诊断口Data Link Connector(DLC)连接。目前TST与VCI之间常见的连接方式有USB，蓝牙及WIFI，而VCI与DLC口之间则主要通过传统CAN方式及今后的Ethernet连接。

无论外部诊断设备是通过物理连接与车辆CAN总线建立通讯或是用DoIP远程诊断的方式，两者实现目的一致：通过既有的诊断服务Service，获取车辆ECU包括故障码在内的节点信息，或是对车辆ECU的Operation Software及标定文件进行FLASH Program。 
优势是DoIP远程诊断的方式能同时实现一台服务器对多台车辆进行并行更新。

下图是针对车辆以太网诊断结构的协议栈，其中使用的诊断规范为UDS。 

安全诊断服务

对于诊断工程师或诊断设备工程师而言，UDS诊断协议并不陌生，且目前在业内趋于标准化推广。需要认识的是，整车数据通讯报文可分为两类，in-vehicle communication以及diagnostic communication。

前者是在车辆总线上传输的数据帧报文，用于模块间、子网间的通讯。而后者则指的是外部诊断设备与车辆内部子网或模块的诊断通信，所使用的服务即定义在诊断协议中。

UDS的诊断服务如下： 
 

当由外部设备对ECU节点发送物理寻址或者功能寻址的诊断服务时，对应节点会对其给出相应的反馈，正响应则会去实现对应的操作，或是由于不支持不满足条件等而会拒绝。

那么车辆需要在什么样的条件下对外部诊断服务给出正响应呢？

如在UDS协议中，0x28是对车内Communication进行控制的Service，在设备发送1003使节点进入ExtensionMode后，紧接发送1003使节点进入ExtensionMode后，紧接发送28 03后，模块即会禁止发送及接收来自其他节点的应用报文或网络管理报文。试想，假如一辆车上并未对诊断服务进行安全策略的约束，那么在车辆高速行驶过程中，Hacker远程对TCM或者ECM发送了禁止通信的报文，车辆各模块之间在powertrain上的报文即会终止，后果可想而知。

又如0x11Service能对ECU进行Reset，以及0x31Service用于Start对模块运行状态起作用的Routine Control等等。

此类诊断服务若无严谨的安全诊断策略进行定义，将会使得外部发起攻击异常简单。

几条常见安全策略

• 安全诊断策略 
  针对上面提及的不同诊断服务，定义必须满足的前置条件，如0x28的服务，可以车辆车速或轮速作为判断依据，在大于某阈值情况下，即使收到了禁止通讯的报文，亦直接拒绝而不对其做出禁应用报文的操作。 
  通过对外部诊断服务的限制，可以有效提高各节点的防御能力。

• Security Access安全访问 
  传统模块端本身是存在安全访问机制的，在UDS诊断服务中可见0x27 Service。 
  此服务机制是Seed-Key映射关系，原理为：外部设备给目标节点发送0x27 01服务，ECU反馈其Seed值，诊断设备拿到Seed后根据先前既定的算法进行加密后返回给ECU,两者认证后一致则模块安全访问认证通过。 
  0x27服务务必作为所有会对模块功能造成变更的诊断服务及数据的基本限制条件，至于关键算法如何进行控制，字节长度以及动静态处理则应由各主机厂各自策略决定。

• 如何保证安全策略不被泄漏 
  最后一点，综上提及的及未被提及的策略，如涉及到的其中加密算法文件，如何能够保证使用者身份合法，也就是如何保证拥有这些策略的人不会泄漏相关策略。

Domain架构概念

宝马与奥迪目前正在进行全新End-To-End的电子架构设计，相似的是都在整车架构内采用了单个或多个高性能的中央计算单元节点（如英伟达，高通，mobileye等提供的芯片）对各功能不同的域层进行管理。同时这些节点会与各OEM云平台进行数据交互，来实现定位，通信，路径规划，以完成自动驾驶、V2X、OTA等功能。

奥迪命名为中央计算集群（central computing cluster） 
Audi’s End-2-End Architecture 

类似的架构宝马称之为中央计算平台（Central Computing Platform） 
BMW’s New Architecture 
 

全新的域层架构设计则如下图，包括Powertrain，底盘，车身控制，娱乐信息系统，自动驾驶等功能在内的域层以以太网作为传输介质，通过车内网关来实现数据传输。

由于此网关具有特殊功能需求，通常情况都会留有两个外部通信接口，一个用于OBD设备诊断通信使用，另一个为蜂窝移动模块，使用LTE或Wifi与云端服务器通信，用于采集如地图定位，路径规划，加密处理等。 
 

为严格控制车辆架构内各安全域层之间的通信隔离，如最容易受到攻击的娱乐信息系统不允许与Powertrain等功能安全相关的Domain直接进行通讯；以及对具有安全隐患的外部请求进行身份授权认证等，架构顶层引入了网关/防火墙Firewall来确保仅相同域内的ECU节点及可靠的用户或Service才可与目标节点进行合法数据交互。

传统IT防火墙分类

传统IT行业的防火墙模块，会对各安全区域之间所有可能的通信通路进行可靠性管理，即在所有区域边界上，根据事件event对网络流量进行监控，并根据既定安全策略（如Whitelist）来允许指令请求的通行，能抵挡住来自不安全网络的攻击与入侵，以保障内网安全。

• 数据包过滤防火墙 
  包过滤防火墙工作在OSI模型的网络层，基于目标地址及源地址对数据包进行过滤，但对于传输层数据，只能识别出是TCP/UDP类型及所使用的端口信息。

• 应用代理防火墙 
  应用代理防火墙则是彻底隔离了内外网直接通信，当内部网络有对外通讯需求时，必须是由防火墙对外网的访问，再由防火墙转发给内网，即通信是基于应用层的代理软件实现，应用层的协议会话须符合代理的安全策略。

• 状态检测防火墙 
  与包过滤防火墙不同的是，它更注重传输层的控制能力，重点在于建立状态连接表，来跟踪每一个进出网络的会话状态信息，监控了数据包是否符合会话所处的状态。针对TCP，防火墙会对TCP头信息进行解析，用于确认是首次连接或已经建立通信，因此不仅能减少数据包穿过防火墙的时间，同时可以有效检测出DoS攻击。

车辆防火墙需求定义

针对汽车防火墙需求定义，首先，由于在车内的分布式总线系统上，车辆ECU对不同Domain之间通信时的响应时间有着极为严苛的要求，因此防火墙须满足执行的实时性（real-time），且在运算时必须比消费电子领域防火墙占用更少的CPU资源。

考虑到车载网络防火墙位于整车架构最外围，如OBD口或远程通信的入口，受到攻击的频次势必最高，因此对于软件Update问题，Firewall应具备足够Flexibility，如同传统防火墙一致，车厂会要求Firewall能及时实现快速升级，完成防火墙策略及软件协议栈的更新，确保迅速修复安全漏洞以抵御快速更迭的攻击方式。软件运行于Firewall的操作系统OS之上，假如OS受到病毒攻击或非法篡改，所有安全策略都将不再适用，因此OS也应支持远程升级。

在此过程中，任何供应商留Backdoor行为都不应被允许。最后应具备完备的Log记录功能，以对任何攻击行为进行记录并远程传输给服务器端，用于后期对攻击数据进行分析。

防火墙硬件方面，首先需满足传统IT行业的防火墙策略规范，也就是网络通信时所应具备的安全筛选隔离功能。其次就是在汽车这个特殊场景下的需求，如作为嵌入式芯片，应满足低功耗以及适应各种极端天气下仍能正常工作的需求。能完成对Closed-loop 闭环系统的整车信息安全路由控制。

在正常通信层面，由于Domain架构设计需求，Firewall后通常会直接连接多路总线，因此Firewall在设计数据包吞吐量时也应适应不同总线的通信速率。

在进行防火墙芯片选择时，不同于传统消费类电子防火墙，传统OEM会对芯片有定制化需求，因此CPU负载能力，RAM大小都直接决定了防火墙的硬件成本，这里不进行讨论。

目前传统越来越多的整车厂开始在架构设计中加入了防火墙，可见信息安全的理念逐渐开始深入。由于车辆场景太过特殊，车辆防火墙须确保整车的功能安全在驾驶过程中不受到破坏，因此其地位也将会随着车辆智能化的发展愈加重要，这就需要整车厂OEM，芯片半导体公司，软件公司的共同努力了。