阐述汽车OTA技术的安全风险

随着汽车软件升级逐步在智能网联汽车产品中广泛应用，覆盖研发、生产、售后等多个环节，对企业的技术水平和管理能力均提出新的要求。若生产企业 OTA 管理不当、OTA 技术不成熟，会加剧功能实现的可靠性风险，使升级后的系统将车辆与驾驶人暴露在未知的危险中。本文首先阐述车联网安全现状，之后结合 OTA 风险评估流程对 OTA 带来的网络安全、数据安全和功能安全风险进行分析，提醒企业规避应用 OTA 技术中面临的各种安全风险。

一、车联网安全形势分析

伴随智能化、网联化的不断推进，车辆开放连接逐渐增多，“车、路、云、网”数据交互日益频繁，车联网领域的安全风险边界逐渐延伸。车联网信息安全风险主要集中在车端、平台、通信、数据等方面。

（1）车端安全风险隐患凸显

一是车载软硬件存在安全隐患。当前，汽车电子电气架构正由分布式向域控集中式架构、整车集中式架构不断发展，步入软件定义汽车时代。车载智能网关、远程信息处理控制单元（T-BOX）、电子控制单元（ECU）等车载联网设备目前尚缺乏较高等级的安全校验机制和安全防护能力，近年来陆续披露出一些安全漏洞隐患。

二是车载网络存在安全隐患。CAN 、FlexRay 等车载网络协议缺乏安全设计，车内数据传输主要根据功能进行编码，按照 ID 进行标定和接收过滤，部分仅提供循环冗余校验，缺乏重要数据加密、访问认证等防护措施，导致车载网络容易受到嗅探、窃取、伪造、篡改、重放等攻击威胁，难以保障车载网络的安全性。

（2）车联网平台服务面临的攻击威胁加剧

近年来，汽车远程服务、在线升级（OTA）平台、车辆调度平台等业务服务快速发展，用户的规模逐步扩大，日渐成为网络攻击的重要目标。由于车端用户可通过车联网平台进行信息交互、远程操作，一旦遭受网络攻击控制，可被利用实施对车辆的远程操控，造成严重后果。

（3）车联网通信安全面临挑战

当前，联网车辆数量和通信需求不断增长。在“车-云”通信场景下，网络隔离不到位、通信协议存在漏洞隐患、访问接入缺乏安全认证等问题突出。“车-设备”通信场景下，受限于设备性能等因素，通信安全认证机制尚不完善，存在拒绝服务攻击等漏洞隐患，可导致 WiFi、蓝牙、智能钥匙失效[16]。

在 OTA 功能实现过程中，云端、车端、通信链路、升级包等关键环节均存在被攻击和篡改等安全隐患。OTA 网络安全态势分析如图5- 1所示。

图5-1  OTA 网络安全态势分析图

二、OTA 风险评估方法

基于网络安全、数据安全及功能安全风险评估理论基础、现有的威胁分析以及实践经验，结合汽车本身的复杂特性，可建立以资产为核心的汽车OTA 远程升级安全风险评估模型。

OTA 风险评估方法具体参照 ISO 26262《道路车辆功能安全工程》、ISO/SAE21434 《道路车辆网络安全工程》、SAE J3061《信息物理汽车系统网络安全指南》等标准，主要评估对象包括 OTA 相关项、组件及漏洞。在相关标准中定义有 STRIDE、攻击树、EVITA、HEAVENS、OCTAVE、PASTA 等威胁分析和风险评估方法论，对这些方法论的对比和融合后归纳如表5-1所示。

表5-1 OTA 风险评估归纳表

风险评估对象	威胁分析方法	可行性分析方法	影响分析方法
OTA 相关项和组件	STRIDE 模型 攻击树模型 VAST 模型 故障树模型 …	基于攻击潜力的方法	S（安全）、F（财务）、O （可操作性）、P（隐私）
OTA 安全漏洞	STRIDE 模型 故障树模型 …	基于CVSS 的方法

2.1 OTA 相关项及组件风险评估

以威胁分析及风险评估分析方法 TARA 为例， 建立 OTA 风险评估流程，如

图5-2所示。

图5-2  TARA 风险评估流程

2.1.1 安全相关性判定

在进行 TARA 分析前，需要对相关项的功能及其运行环境进行定义，以充分识别出资产（包括内部实体、外部实体、存储数据、数据流等），实体、数据被破坏后带来的危害场景等。相关项定义（Item Definition）的目的是了解分析对象，了解其业务、功能、流程、边界，OTA 相关项边界定义如图5-3所示。

图5-3 OTA 相关项边界定义示意图

数据流图（Data Flow Diagram）需把该相关项中每个功能用到的数据标识出来，从哪个实体产生，经过哪个实体处理，经过哪个实体转发等。数据流图要素的基本符号如图5-4所示。

图5-4 数据流图要素的基本符号

以 OTA 业务为例，参考数据流图如图5-5所示。

图5-5 OTA 业务参考数据流图

2.1.2 资产识别

资产识别（Asset Identification），是识别车辆在使用的过程中需要被保护不受网络攻击的信息，包括了通讯数据、用户隐私数据、ECU 固件、算法等各种类型的信息。资产定义的目的是识别出这些资产，确定每项资产的网络安全属性,从而分析出潜在的损害场景。资产识别过程表如表5-2所示。

表 5-2  资产识别过程表

资产识别输入	资产识别活动	资产识别输出
已构建完成的数据流图	1）识别资产：获得评估对象在外部实体、功能单元、数据存储和数据流四个方面的资产； 2）识别危害场景：识别资产由于丧失安全属性而出现的危害场景。	1）资产和安全属性； 2）危害场

资产的网络安全属性通常分为机密性(Confidentiality)、完整性(Integrity) 、可用性(Availability)、真实性(Authenticity)、授权性(Authorization)、抗抵赖性(Non-repudiation)、新鲜性(Freshness) 、隐私性（Privacy）。每一个资产都具有相应的网络安全属性如表5-3所示。

经以上分析，OTA 过程中所涉及信息安全资产包括：

零部件资产：T-BOX 、CGW、目标 ECU 及车载总线；

数据资产：升级包、升级日志和升级指令等信息；

软件资产：零部件上所运行系统和升级管理程序。

表 5-3  OTA 过程涉及的资产和损害情况（示例）

资产类别	资产名称	网络安全属性	危害情况
零部件资产	T-BOX	真实性	通过伪造 T-Box 和后台的通讯端口，破坏通讯真实性，使得后台的交互指令发送到非目标对象
	CGW	完整性	通过篡改 Gateway 软件的工作逻辑，破坏资产的完整性，导致软件升级过程被恶意干扰
	ECU	可用性	通过打乱 ECU 软件的工作进程，使其无法正常工作，破坏软件的可用性，导致软件升级过程无法执行
	车载总线	可用性	通过干扰车内信号的交互过程，破坏车内通讯的可用性，导致软件升级过程无法正常执行
数据资产	升级包	完整性	通过篡改待升级软件包的内容，破坏其完整性，构造出恶意软件写入车载 ECU，引起车端功能逻辑错误
	升级日志	完整性	通过篡改升级日志内容，破坏数据完整性，导致升级过程的记录信息错误，导致升级过程无法准确追溯
	升级指令	真实性	通过伪造升级指令，破坏车内通讯的真实性，导致软件升级过程出现错误
软件资产	系统	可用性	通过打乱 Gateway 软件的工作进程，使其无法正常工作，破坏软件的可用性，导致软件升级过程无法执行
	升级管理程序	可用性	通过干扰升级管理程序通讯，破坏通讯过程的可用性，使得升级交互通讯无法进行

2.1.3  威胁分析

威胁场景定义是 TARA 分析的重要环节，TARA 最终输出的风险等级和风险处置决策的对象就是威胁场景。威胁分析过程如表5-4所示。

表 5-4  威胁分析过程表（示例）

威胁分析输入	威胁分析活动	威胁分析输出
相关项判定危害场景	1）威胁场景识别，说明造成危害的时机，环境和攻击方法等要素(STRIDE 分析) 2）攻击可行性评估：确定进入目标系统的攻击向量的攻击潜力 3）影响分析：根据威胁因素和可能的攻击路径推导出相关项或组件可能受到损害的要素及场景（SFOP 定性,HEAVENS）	1) 威胁场景 2) 攻击可行性评级 3) 影响评级

威胁场景应通过目标资产、相关网络安全资产受到的威胁，导致网络安全财产受损的原因推导得出。推导方法包括 EVITA, TVRA, PASTA, STRIDE 等。以 OTA 过程中数据资产升级包的完整性、机密性、可用性被破坏为例，威胁场景识别如表5-5所示。

表5-5 威胁场景识别（示例）

危害情况	威胁场景
篡改待升级软件包内容	完整性被破坏，升级无法正常执行
破解待升级软件包	机密性被破坏，窃取其中的核心算法
干扰升级进程	构造出恶意软件写入车载 ECU，引起车端功能逻辑错误，可用性被破坏或者通过非法指令导致车辆运行状态下，非预期地进入升级模式

攻击路径可基于自上而下的攻击树；自下而上的告警日志、以往安全事件确定的漏洞等方式推导得出。对于每一个攻击路径可基于多维度的攻击潜力难度系数得出攻击潜力值，以及攻击可行性等级，如表5-6所示。

表5-6 攻击可行性评估（示例）

影响等级可分为严重（Server）、主要（Major）、中等（Moderate）、可忽略（Negligible）四个等级，并通过危害对功能安全（Safety）、财务（Financial）、可操作性（Operational）、隐私（Privacy）等维度的影响评估来确定危害的综合影响等级和影响值，如表5-7所示。在实际的影响等级评估中，也可以采用 HEAVENS 方法中提出的定量评估方法，其中安全和财产的影响水平具有较高的权重（0~1000），操作和隐私方面的损害影响相对较低，权重也较低（0~100）。

表5-7 OTA 影响等级分析（示例）

2.1.4  确认风险值

通过结合安全风险的业务影响评级和攻击可行性评级，依据风险评估矩阵评 定风险等级，确定安全风险的处置优先级，为后续的韧性处置方案设定评级目标。风险值确认过程参见表 5-8。

表5-8 风险值确认过程表

输入	风险值确认活动	输出
1）威胁场景 2）攻击可行性评级 3）影响评级	确定每个威胁场景的风险值，风险值可分为：可忽略不计，低危，中危，高危，严重	风险值

根据表5-9风险评估矩阵识别风险值 R。

表5-9 风险评估矩阵

根据表5-10进行风险值分析。

表5-10 风险值分析（示例）

2.1.5 风险处置

根据风险处置方案思维导图，借助风险处置库，设计风险处置的韧性方案。在风险处置方案设计完成后，通过再次评估，判断参与风险是否降至风险等级目标。若残余风险仍未达到风险等级目标，需根据业务的实际情况，考虑是否接受残余风险或进一步增强处置措施形成最终风险处置方案。风险处置活动参见表5-11、表5-12。

表5-11 风险处置过程表

输入	风险处置活动	输出
1）相关项定义 2）威胁情况 3）风险值	对于每种威胁场景，结合其风险值及其等级，确定风险接收、风险缓解、风险规避、风险转移四种中一种或多种风险处置方案。	风险处理决定

表5-12 风险处置活动（示例）

威胁情况	风险值	风险处理方案
通过篡改/伪造升级包内容，使升级无法正常执行——OTA平台网页漏洞扫描-网页扫描/系统漏洞-发现下载升级包链接-获取升级包-篡改升级包内容	低危（2）	降低风险：不存在由权威漏洞平台公开发布 6个月及以上且未经处置的高危安全漏洞；关键零部件应具有存储和隔离敏感数据的安全区域或安全模块；具有防止非授权获取或篡改在安全区域或安全模块中一次性写入的敏感信息的功能
通过获取并破解待升级软件包，窃取其中核心算法——通过汽车远程升级平台或管理平台数据库暴露的后门端口窃取	中（3）	降低风险：在关键网络节点处，如互联网边界处，合理部署可对攻击行为进行检测、阻断或限制的防护设备；关闭云平台不使用的端口，例如TCP、UDP上层应用端口默认全部关闭，并根据实际业务需要开启特定端口（例如 SSH 22、HTTPS 443）；按照一定的安全规则（参数包括：协议类型、端口范围、主机 IP、网段 IP 等）进行访问；配置信息应指定端口进行跨越边界的网络通信，指定端口应配置并启用安全策略。建议只开放业务端口
通过干扰升级过程，导致升级无法正常执行或非法升级——伪造升级指令，使车辆执行非预期的刷新动作和升级	低危（2）	降低风险：使用安全机制确保传输数据（例如：车辆控制指令等）的完整性和可用性。包括车内网络通信完整性检验采用 MAC、车内网络通信采用SECOC、消息新鲜码等防重放攻击机制；应采用控制策略避免大量集中向 CAN 总线发送数据包，以避免造成总线拥塞和拒绝服务

2.1.6  处置跟踪验证

对上述修复的结果进行测试验证， 由相关技术人员或第三方根据处置方案进行测试验证。

2.1.7  残余风险评估

残余风险主要方式产生如表5-13所示。针对残余风险应重新进行特定范围的风险评估，并识别是否达到可接受风险水平。处于不可接受范围的残余风险须进一步增加相应的管理和控制措施，在所有的残余风险处于可接受范围的水平后，应发布风险声明并加强日常网络安全监测。

表5-13 残余风险产生方式

产生方式	解释
有意识接受的风险	指的是在风险处置阶段，通过风险接受或风险转移方式所衍生的残余风险；
已识别但误判断的风险	指的是在风险评估阶段已完成识别的风险项，但由于风险评级识别错误，导致在测试验证阶段发现残余风险无法达到可接受风险水平；
未识别风险	指的是在风险处置或测试验证阶段，识别出存在其他安全威胁的风险；

2.1.8  风险闭环

梳理风险评估流程文档，为后续网络安全日常运维或安全审计提供支持。

2.2 OTA 安全漏洞风险评估

OTA 安全漏洞指硬件、软件、协议的具体实现或系统安全策略上存在缺陷，从而使攻击者能够在未授权的情况下访问或破坏系统。应对安全漏洞进行识别、风险评估、修复、测试验证等操作以保证系统安全。以下提供了安全漏洞处置流程及技术方法，可用于针对某 OTA 业务场景所涉及零部件和环境进行漏扫，以得出具体漏洞信息。OTA 安全漏洞评估流程见图5-6。

图5-6 OTA 安全漏洞风险评估流程图

2.2.1  漏洞识别

漏洞识别方式：漏洞公告、漏洞扫描、渗透测试、白帽测试等；

漏洞类型识别：如 STIRDE 威胁模型中的仿冒、篡改、信息泄露等类型。

2.2.2  风险评估定级

Common Vulnerability Scoring System（CVSS）提供了一种方法来描述可利用性的主要特征，并生成分值反应其严重程度，使得人们确定处理它们的优先级[17]。

CVSS 评分方法如表5-14所示。

表5-14 CVSS 评分方法

CVSS 可利用性值与攻击可行性的映射示例如表5-15所示。

表5-15 基于CVSS的攻击可利用性映射表

CVSS 可利用性值：E	攻击可行性评级
2.96-3.89	高
2.00-2.95	中等
1.06- 1.99	低
0.12- 1.05	非常低

2.2.3  修复可行性评估

修复可行性评估首先需要根据上文风险处置的方式初步筛选出漏洞的处置方式，针对具体的修复方式（如补丁升级、版本升级、更换组件等）进行测试验证，评估对 OTA 系统是否造成影响或引入新的高危及以上风险。

2.2.4  测试验证

对已经修复的漏洞进行测试验证，如重新漏洞扫描、渗透测试、人工复现等

进行验证。

2.2.5  闭环

在测试验证阶段确认漏洞修复有效后，对相关风险评估和测试验证过程文档进行归档保存，最后可流程闭环。

三、OTA 网络安全风险分析

根据 OTA 威胁分析和风险评估流程，OTA 面临的网络安全风险包括 OTA平台安全风险、通信安全风险、车端安全风险和升级包安全风险。

3.1 OTA 平台安全风险

OTA 平台安全风险主要包括云平台自身安全、第三方应用安全两个主要方面。

（1）云平台自身安全风险

OTA 平台大多数部署在云端服务器中，会面临传统云平台的所有安全威胁，包括网络威胁、主机威胁、应用威胁、数据威胁等。攻击者利用 Web 漏洞、数据库漏洞、接口 API 安全注入漏洞等手段发起 DDoS 攻击、MITC 攻击、跨云攻击、编排攻击、加密劫持等，可能导致 AccessKey 泄露风险、用户敏感信息泄露、推送的升级包被篡改、升级策略更改等风险。

（2）第三方应用安全风险

随着车载平台的发展，第三方应用也会随之增长，第三方应用的 OTA 也将会成为一个很重要的部分。升级后的第三方产品可能存在系统兼容性或者系统漏洞，甚至严重的 BUG，所以 OTA 平台也需要考虑到第三方应用的升级流程与规范要求。

3.2 通信安全风险

OTA 通信安全风险主要包括身份认证、传输加密、中间人攻击三个主要方面。

（1）身份认证安全风险

身份认证风险体现在通信过程中未对通信对象进行有效身份验证，攻击者通过使用基站伪造、身份伪造、动态劫持等方式冒充合法参与者，参与车云通信，非法监听通信信息。例如，OTA 云服务推送软件升级包到车端的过程，若采用弱认证方式或明文传输，容易遭受中间人攻击、窃听攻击等。终端下载升级包的传输流程中，如果终端在升级流程中同时缺少验证机制，那么被篡改的升级包即可顺利完成升级流程，达到篡改系统，植入后门等恶意程序的目的。攻击者还可能对升级包进行解包分析、篡改升级包信息等，或者获取一些可利用的信息，如漏洞补丁等，可能导致关键信息泄露、代码业务逻辑泄露等风险。

（2）传输过程安全风险

传输风险主要发生在车辆通信信息在未进行加密、加密强度较弱、密钥信息暴露等情况下，导致容易遭受恶意攻击，造成通信信息的泄漏、非法篡改和破坏。例如，云端与车端的通信过程若采用不安全的通信协议或通信过程不采用认证机制、明文通信等，容易遭受中间人攻击、窃听攻击、重放攻击、DoS 攻击等，可能导致车端升级信息错误、敏感信息泄露、拒绝服务等风险。

（3）中间人攻击安全风险

中间人攻击体现在协议链路层通信未进行加密，攻击者可以通过抓取链路层标识实现会话劫持，攻击者可以基于中间人伪造协议而实施对升级包的篡改，窃取等。此外，在自动驾驶情况下，汽车使用了篡改后的升级包，攻击者通过利用升级包中预植的木马，干扰车辆正常控制，带来交通安全风险。

3.3 车端安全风险

车端安全风险主要包括版本回退、车端升级程序被破解绕过、拒绝更新三个主要方面。此外，车端系统出现公开漏洞，若不及时进行修复，可能导致黑客利用漏洞进行攻击，造成车辆、财产乃至人身安全风险。

（1）版本回退风险

一般场景下的升级都是由低版本升级到高版本系统，但如果车端升级未对升级包版本进行判断，攻击者可以利用此漏洞，使用存在已知安全漏洞的低版本系统覆盖现有的系统，将导致车辆面临安全风险。

（2）车端升级程序被破解绕过

按照 OTA 和安全相关的国际和国家标准要求，升级过程都需要在车辆端对升级包进行加密和签名验证等一系列验证环节，经过验证的升级包才能进行正常的升级流程。如果验证的算法过于简单或者验证流程存在漏洞，攻击者可以利用这些漏洞构造有效的升级包或者绕过验证流程，在部件上加载运行恶意篡改过的固件，对车辆进行进一步的攻击或者控制等恶意行为。

（3）拒绝更新风险

在车辆升级过程中，攻击者可能会阻止车辆修复功能漏洞，通过控制车辆拒绝访问更新而无法解决车辆潜在漏洞或其他问题。常见的攻击方式包括：通过阻断或拦截外部或内部网络通信流量，阻止车端 ECU 接收任何更新。

3.4 升级包安全风险

涉及升级包的应用场景分为升级包车云传输、升级包车内传输、升级包安装。三类应用场景中，升级包安全风险主要包括升级包信息泄露、升级包信息篡改、升级包信息伪造三个主要方面。

（1） OTA 升级包信息泄露风险

OTA 升级包的机密性破坏，攻击者可轻易捕获并分析通信数据，导致升级包信息泄露风险。

（2） OTA 升级包信息篡改风险

OTA 升级包的完整性破坏，攻击者获取 OTA 通信数据并进行篡改，造成升级包被篡改或升级指令错误。

（3） OTA 升级包信息伪造风险

车云之间失去身份的真实性，攻击者伪造非法信息进入平台或车辆，导致下发恶意升级指令或上传虚假信息等。

（4） OTA 升级包代码安全风险

未对升级包进行代码检测，以及对代码所应用的第三方开源代码进行溯源和分析，导致升级包中存在缺陷（bug）。

四、OTA 数据安全风险分析

汽车 OTA 带来对已售车型大量应用服务的数据井喷，还面临在保证用户个人信息安全的前提下，企业如何实施数据利用共享，OTA 相关数据如何跨境流通等问题。这些安全风险都对企业的合规管理与创新发展提出新的要求。

4.1 用户隐私信息泄漏风险

汽车远程升级整个过程中涉及到云端服务器安全、车端安全、车云通信安全，也关系到生产者、用户及汽车软件供应商等其他主体之间的数据收集、数据传输等多个处理环节。在这些过程之中如果存在网络攻击风险，可能导致 OTA 系统遭受破坏，不法分子可以通过 OTA 系统窥探到用户的隐私信息，如车辆位置、行车路线等行为习惯。同时，第三方应用平台可能存在非法获取其他应用和车载端数据的风险。

4.2 数据出境合规风险

随着系列政策文件均提出汽车产生的个人信息和重要数据出境管理要求，智 能网联汽车作为重点监管对象，产生的大量数据为数据跨境管理带来新的风险。对跨国企业而言，涉及技术研发的数据免不了出境或远程跨国访问，若分布于各国的数据只能本地存储而无法出境交互，将动摇跨国车企一直以来采取的开发、维护、集中化管理模式，导致车企需重新对一国市场进行单独资源调配，建立和总部一致的技术团队，成本不可估量[18]。因此在车辆售出后， 面对远程升级需要的软件版本号、升级包名称、升级时间等决定功能实现的数据如何合法地出境流动仍然存在管理规定不明晰带来的风险。

五、OTA 功能安全风险分析

当涉及车辆核心功能如动力、制动和电池管理系统等模块的远程升级时，可能对车辆的功能安全带来新的挑战，升级后的系统将车辆与驾驶人暴露在未知的危险中。OTA 功能安全风险可举例为：

5.1 车端升级条件判断不当导致的安全风险

车辆远程升级是一个比较长的过程，而且升级过程中车辆大部分功能可能无法正常使用，所以一般都要求车辆在P档、电池电量充足等一定条件下才能进行。如果车辆对于升级条件的判断存在问题，可能导致在非预想的情况下触发升级事件，对车辆和车内人员人身安全造成威胁。

5.2 车端升级失败导致的车辆功能不可用

在车辆升级过程中可能出现断电等异常情况导致升级失败的情况，如果没有对升级失败的情况进行妥善的容灾处理，可能导致车辆无法启动，甚至零部件损坏等严重事件。

5.3 OTA 升级软件自身缺陷导致的风险

软件更新后未进行充分验证和测试就直接部署到车辆上，软件自身的缺陷可能会使软件运行出现意外行为，导致系统崩溃、触发车辆失控等安全事故。

5.4 软件不兼容风险

在车辆升级过程中，升级软件可能引入新的功能和接口，如果车辆硬件不支

持或不兼容，可能导致升级后系统无法正常工作，造成行车安全隐患。

为应对上述 OTA 安全风险，总体来说，在云平台端可采用证书，签名和加密机制，负责为 OTA 服务平台提供安全服务，包括密钥证书管理服务，数据加密服务，数字签名服务等，保证升级包不会随意被制作和发布，升级包的内容不会被恶意获取。在通信链路端，可通过可靠的物理链路和安全传输协议来保证网络传输安全。在车端，可通过汽车的功能域隔离，划分不同 ASIL 等级，通过冗余设计保证整车的功能可靠性；车辆终端 OTA 组件对升级包进行合法性验证，适配安全升级流程，通过安全启动来保证可信的软件在 ECU 上加载启动运行。

 





审核编辑：刘清