万字长文解读汽车信息安全框架

在汽车电子与软件三大安全中，预期功能安全仍然处于理论逻辑层面，尚不足以支撑企业开展具体工作，暂不多论。功能安全则早已声名鹊起，而今甚至已走进逐渐沉寂的阶段。

近两年，信息安全的名气慢慢振作，并且前景广阔，但至少在现在，其体系的完整性和落地的成熟度仍不如功能安全，还需要一定时间的发展。

不过，有一条是功能安全完全不可比拟的，就是信息安全涉及法的强制性，好似道德与法律的关系。

在此背景下，本文会用10000字左右系统阐释其基本概念、法规标准及技术框架。

1信息安全的概念

现在谈汽车，都得挂个智能二字，即智能汽车，但更学术、更完整的叫法应该是智能网联汽车，而智能网联进一步会分为智能和网联两部分。

在《GB/T 44373-2024 智能网联汽车：术语与定义》中，智能功能被定义为环境感知、智能决策、自动控制等功能，网联功能被定义为利用通信技术实现车辆与外界（车外的车辆、行人、云端、基础设施等）信息交互的功能。

我们今天的讨论大体是落于网联范畴的，实际上，以中文直观感觉而言，从网联到网络安全在认知和交流上比信息安全更具便利性，但在国内汽车行业的标准里，我们更多使用信息安全这个说法。日常沟通中，可将二者视为等同。

进一步再看下信息安全与信息安全体系的定义：

汽车信息安全：汽车的电子电气系统、组件和功能被保护，使其资产不受威胁的状态（来源于《GB/T 40861-2021 汽车信息安全通用技术要求》）。

汽车信息安全管理体系：包括组织流程、责任和治理的基于风险的系统方法，以处理与车辆网络威胁相关的风险并保护车辆免受网络攻击（来源于《GB/T 44373-2024 智能网联汽车：术语与定义》）。

这么理解还是有些宽泛，继续来看。

2功能安全大概是什么

汽车安全探讨中，传统意义上的被动安全是大家最具共识性的，也是消费者最易理解的，但被动安全已经足够得成熟和足够得不必争论。

所以，老百姓不太理解，但理论体系和实践经验更为充实的功能安全实际上成了当下事实上的核心安全主题（注意是当下）。

我们不妨先从功能安全讲起，来引出信息安全的内涵。

2.1 如何理解功能安全里的安全

这里有3点要注意。

(1) 安全即风险够低

第一，这世上没有绝对的安全。所谓安全与否，是指风险高低，只要风险够低就是安全，如图1所示。

进一步问，高与低的界线在哪里呢？在老百姓心里。不过，对老百姓更精准的表达应该是State of the Art，即当前技术水平。

也就是说，功能安全的目标是将风险降低到大众可接受的水平。这有很大的伦理意味，这也是目前自动驾驶要考虑的课题。

图1 风险与安全的含义

(2)本质安全

第二，虽然这世上没有绝对安全，但有本质安全，本质安全是消除内在的风险。举个例子。

小的时候，离家不远的地方有一条铁轨，横穿过离家的小路，这不仅仅让行人车辆经常与火车擦肩而过，也是我们小孩子压硬币和铁钉的乐园，自是十分危险。

后来不知是谁在铁轨之间加装了方便快速通过的木板，并且增加了简易栏杆，火车快到时，还有红色警示灯......

不过，还是不够，直到有一次，还是出了一次惨烈的事故。再后来，铁轨下深挖了一个小的隧道，路口附近的铁轨也都被围栏围了起来，尽管下雨总是聚水，但再没听说过什么事故......

这个小事例说了两个安全，铁轨下挖隧道就属于从根本上规避风险的本质安全，而加装木板、栏杆及警示灯等安全机制属于无法实现本质安全后的功能安全的范畴，如图2所示。

图2本质安全与功能安全

(3)以人为本

第三，功能安全以人为本，关注的是人身安全的伤害，包括驾驶员、乘客、行人及其他车辆内的人员，并不关注财产的安全。

2.2 功能安全的对象

ISO 26262标准里明确指出，功能安全适用的对象是汽车里的电子电气系统，具体来看就是包含软件与硬件的系统，不涉及机械、液压、化学等领域。

但要注意，功能安全面对的是整个控制系统的安全回路，是面向整车的，不是某个单一功能零部件，一般至少要包含一个传感器和一个执行器。最典型的就是ECU系统。

而且，只有那些分析后确实涉及功能安全的产品才会启动进一步的功能安全开发，比如，涉及制动、转向、停车、巡航、气囊及安全带、照明、车身控制、悬架控制、电机控制、电池管理等功能的系统或ECU。

对于所谓的智能座舱之类的娱乐系统，则完全不涉及或者只有少量组件（如仪表）涉及低等级的功能安全。

2.3 功能安全解决什么问题

功能安全虽然带有功能二字，但不能解决功能不足、性能不好的问题（属于SOTIF），也就是不改变系统的标称特性，而是正向指导我们如何通过降低系统失效风险达到安全目标，并最终来减少对人的伤害。

比如，电子手刹，功能安全是要实现避免非预期刹车失灵的安全目标，关注的是整个电子手刹回路某一环节发生失效时的诊断、监控及处理行为，不是增加卡钳设计夹紧力改变功能与性能。

再进一步看，功能安全要处理的失效来源于哪里呢？两方面。

第一，人总是有局限的，所以人在产品及项目开发过程中，会为软件或硬件带来系统性失效，比如，标定时设置错了参数值或方向，理论上，这些失效是有确定根因的，只能通过过程执行或设计变更来消除。

第二，物总是不完美，硬件会出现符合概率分布的随机硬件失效，如电磁干扰、冲击振动、高温老化等，而这类失效是无法避免的、不可预测的，它们是源自半导体的材料与工艺本身的属性。

2.4 功能安全如何处理这些失效

失效很重要，但不是最重要的。我们要关注失效给人身安全带来的风险。风险也很重要，但依然不是最重要的，因为没有100%的零风险与安全。所以我们要识别出不可接受的风险，然后通过一些安全机制（过程与技术）将其降低到可接受的程度。不那么精准的说法就是足够的功能安全。

这里其实引出了功能安全方法论的核心目的是，通过增加安全机制将不可接受的风险降低到可接受的程度。

3对比功能安全，理解信息安全

本节通过对比功能安全来看信息安全的特点。

3.1 从伤人到伤心

功能安全的指向很明确，就是关注对人的伤害，且限于肉体的伤害，姑且称之为伤人，为什么说信息安全是伤心呢？这不得不引出第一节也提到的信息安全的一个核心概念资产，资产的破坏将导致伤心。

(1)资产

在中文的语境里，提到资产，很容易想到钱，钱和资产有部分关系，但不能用钱来直接代替，这里的资产的概念更加宽泛。

接下来，我们从更学术的角度看，先串一下21434中资产及附属概念的含义。

资产：有价值或对价值有贡献的对象（有形的或无形的），它具有一个或多个值得保护的属性（即信息安全属性），其违背可能导致一个或多个不良后果（即损害场景）。

信息安全属性：包括机密性、完整性、可用性。其中，机密性是信息不泄露，如个人车机账户；完整性是信息准确性，不能被非授权修改；可用性是指授权的用户能有效使用。注意，关于信息安全属性，不同的模型有不同的定义，这里只是一种。

损害场景（damage scenario）：涉及车辆或车辆功能，并给司机、乘客、行人、车主等道路使用者带来不良后果。

威胁场景（threat scenario）：造成一个或多个信息安全属性被违背的潜在原因，会最终造成损害场景。

(2)信息安全的目的

对应地，我们来寻找信息安全要解决的问题，汽车E/E系统或组件（即item）拥有一些对人有价值的资产，这资产里的一些属性被损害后，会对人造成一些不良后果。

信息安全要做的就是，通过保护资产的属性尽可能不被破坏，来让这不良后果的风险达到可以接受的程度，让相关人不要太伤心（伤人也属于一种伤心，即信息安全也会关注对人的伤害），如图3所示。

图3 汽车信息安全的基本目的

3.2 从HARA到TARA

再回顾下功能安全的开发逻辑，大体是从危害事件来识别risk大小，并定义ASIL及对应的安全目标，从而获得功能安全的大目标和总标准，随后通过拆解而进入V模型的常规开发中。对于功能安全而言，HARA是核心的增量方法。

现在来看信息安全，大家大的指引方向都是，让对人不好的东西的发生被控制在较低的水平。于是，信息安全引出了一个核心方法论TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）。

看到这个词，大家首先会注意到其中威胁，延伸一点，威胁其实是来源于威胁场景这个概念，它可以类似对应于功能安全中的危害，即潜在的危险（在26262中也明确指出，可以从功能安全角度将信息安全威胁作为危害进行分析，以支持危害分析和风险评估以及安全目标的完整性）。而前述的损害场景相当于功能安全中的伤害，即由潜在的危险转化而成的实际发生的后果。后面的风险评估又和HARA在字面上完全一致（具体方法会有些不同）。

这样一对比，TARA和HARA有着高度紧密的映射关系，基本的方法论逻辑是一致的。类似于HARA，TARA也是信息安全的主要增量内容，我们也可以TARA来牵引出信息安全开发的脉络。

写到这里，大约是对汽车信息安全是什么有了一个模糊的轮廓，但很多细节还未展开，比如，威胁的源头是什么，资产主要包括什么，属性里的机密性、完整性及可用性怎么理解，怎么保护，不良后果的影响有哪些，形成的概率高低，相应的风险等级如何评定，TARA如何将这些东西串联起来......关于这些问题将在下面回答。

4TARA

TARA主要分为7个部分，逐个来展开。但要注意一点，在21434中，整体并不具有明确的线性化次序，包含TARA中7个部分在内的各个部分都会有一定的独立性，输入输出相互交织。

4.1 资产识别

资产的识别有一定的事后性与动态性，也就是说资产不会全部清清楚楚摆在一个列表里（一般会有一部分参考，但不是唯一来源），需要分析、确认、更新。

其他渠道有哪些呢？一般，可以在相关项定义中识别、从威胁场景中获取，以及通过不良后果的影响评级来判断。

当然，这种泛泛之谈会让人不明就里，我们通过一个实例来理解下这个逻辑。

先回顾下有关资产的定义，资产是有价值或对价值有贡献的对象（有形的或无形的），它具有一个或多个值得保护的属性，其违背可能导致一个或多个不良后果。

(1)潜在资产识别

于是，第一步，在相关项定义中识别研究对象时，我们可以先粗略划定一个有价值对象的范围。比如，分析到软件中的刹车CAN报文，它的被篡改可能会造成功能的缺失，显然面向价值，这就可以被划归为潜在的资产范围。

(2)威胁与损害场景识别

再进一步，还提到了资产的3个属性机密性、完整性与可用性，对应于刹车CAN报文的篡改，它可划归为完整性的违背，它会首先形成一个威胁场景。

那么，这个威胁场景会带来什么呢？或许会造成刹车失灵，乃至车毁人亡，这种后果就是所谓的损害场景。

(3)影响评级

可是这损害场景的影响真的如此严重吗？我们需要再进行影响评级，如果评下来发现，确实挺严重，那这时就可以将这条刹车CAN报文作为资产了，或者说有必要开展进一步信息安全活动的资产。

所以说，资产的识别对应着一个认识的过程。为了更具象地理解什么是资产，举一些典型的例子，如表1所示。

表1信息安全资产示例

看得出来，这些资产和钱有关系，但不那么紧密。

最后，总结一下，在该环节需要输出的内容包含：资产、资产的信息安全属性及违反相关属性导致的损害场景。

4.2 威胁场景识别

威胁场景是损害场景的潜在来源，其识别是对技术根因的向上溯源。

通常，需要体现出什么信息安全属性被违背及违背的原因是什么，比如，对EPS转向助力CAN报文进行欺骗篡改会导致CAN报文的完整性被违背，从而导致转向助力功能的异常。

4.3 影响评级

影响评级实际上是对损害场景的评估，也就是向下探测后果的过程。

前面我们说了资产不只是钱，影响也不仅仅是钱（财产）的损失，如果按照SFOP的模型，可以将影响分为4类：

safety（人身安全）financial（财产）operational（车辆操作）privacy（个人隐私）

当然，也可以有其他合理的分类方式，但需要在开发供应链中达成共识。

从级别的角度看，每个类别可以从以下4个等级展开：

severe（严重的）major（重大的）moderate（中等的）negligible（可忽略的）

其中，safety的部分在功能安全中有较为全面的、详细的论述，完全可以参考，必要时，也可以结合暴露度与可控度来综合定义，相对而言，safety的评价会更充分。对于其余类别，基于经验的、基于团队评价的模式居多。

4.4 攻击路径分析

走到这里，我们还没有谈到另一个重要的因素，究竟是谁造成了这种后果？信息安全本质是人与人的攻防较量，我们需要知道攻击者是如何执行攻击的，是如何造成威胁场景的，而这攻击者的一系列有预谋的蓄意行为就是攻击路径的概念。比如，对于第2部分威胁场景识别处的示例，黑客通过网关转发反向助力信号就是一条攻击路径。

形式上，攻击路径的分析可以按照自上而下和自下而上的方式展开。

自上而下是从威胁场景始，考虑其可能实现的不同方式，进而推断攻击路径。自下而上的方法是，从已识别的漏洞来构建攻击路径。

4.5 攻击可行性评级

信息安全中有一个基本策略是，让攻击者的攻击成本大于攻击收益，如果达到这种态势，通常来说，会大幅降低攻击者的意愿。攻击可行性就是指攻击路径成功实现的成本高低，我们也会分为高、中、低、很低这4个级别。

具体的方法一般有基于攻击潜力的方法、基于CVSS（Common Vulnerability Scoring System，通用漏洞评分系统，是一个用于评估软件安全漏洞严重性的公共框架）的方法和基于攻击向量的方法，下面简单描述。

(1)基于攻击潜力的方法

攻击潜力取决于5个重要参数，即：

所需攻击时间。一个专家从漏洞识别到开发应用的持续时间。所需专业知识。普通小白和攻击各个步骤都需要专业人士的难度显然不同。需要对产品或部件的了解程度。有些攻击可能只有内鬼才能做到。机会窗口。可攻击的时间段，比如，漏洞公开到修复这段时间或者蓝牙连接过程的时间段）。所需设备。发现漏洞和执行攻击是否需要专业的工具。

在确定好各个参数的取值并相加后，再根据预先定义的取值范围进行等级评定。

(2)基于CVSS的方法

21434中选择了CVSS评估框架中的可利用度指标来评价可行性等级，而可利用度指标是将以下4个参数的取值代入特定公式中进行计算得到的。

攻击向量。在攻击可行性评级随物理或逻辑的攻击距离增加而增加的前提下评价，比如，从JATG口、U盘、蓝牙到移动网络的攻击可行性依次升高。攻击复杂度。攻击者成功利用漏洞前所需要的条件多寡难易。权限要求。攻击者在利用漏洞时需要的权限级别和授权次数等。用户交互。攻击者与受攻击者越需要交互攻击可行性越低，比如，需要诱导用户点击车机链接提示。

(3)基于攻击向量的方法

仅利用攻击向量评价也是一种简单粗暴的方法，这种方式常用于项目早期或其他还没有充足信息的阶段的粗略估计。

4.6 风险值确定

损害场景的影响等级和相关攻击路径的攻击可行性等级确定之后，最好能有一个综合性的指标来表征信息安全威胁场景的风险水平，也就是这里所讲的风险值确定，比如，通过基于经验值的风险矩阵或者加权公式计算等来确定。

另外，一个威胁情景有可能对应一个以上的损害情景，以及一个损害场景还可能继续带来多个影响类别，我们可以对这一个威胁场景衍生出来的每个影响类别确定单独的风险值。

不过，如果一个威胁场景对应多个攻击路径时，就需要对攻击可行性这个维度进行聚合分析，比如，将对应攻击路径的攻击可行性评级中最大的一个分配给该威胁场景，因为我们在这里关注的是形成后果的可行性、可能性，而这取决于木桶最短那块板子。

4.7 风险应对决策

基于风险值高低，需要确认下一步的应对策略，一般分以下4种：

风险规避，比如，删除某个功能。风险减轻，比如，强化安全控制过程或修复漏洞。风险转移，比如，通过购买保险或者签署合同转移。风险接受。

由于后两种并没有针对风险本身做什么处理，整个供应链的风险并未得到处理，所以需要特定的声明或监管。

在这里，我们会发现一个情况，就是风险值实际上是随着应对举措的执行而变化的。

那么，我们用什么目标线来确定该做什么和做到什么程度，类似于功能安全中的ASIL和预期功能安全中的两层接受准则。信息安全中增加了一个逻辑类似ASIL的概念CAL（CybersecurityAssuranceLevel，信息安全保证等级），它会作为一个固定的指标来牵引要做的信息安全活动及严格程度。

5信息安全相关的法规及标准

第三节和第四节的内容参考自工程视角下比较知名的21434，但信息安全体系当然不仅仅止于此，本节会做一个汇总。

5.1 国际典型法规标准

坦白讲，同很多其他领域一样，国外在信息安全法规标准的建立上仍然领先于我们。其中，最典型、最流行的是R155、R156、21434。

(1)R155

R155，即《关于批准车辆信息安全和信息安全管理体系的统一规定》，是全球第一个汽车信息安全强制性规范，由联合国欧洲经济委员会（UNECE）的世界车辆法规协调论坛（WP29）发布的第155号法规，自2021年1月21日生效，标志着汽车信息安全进入法治时代。

R155法规只适用于《1958年协定书》的缔约国，包含欧盟国家、日本、韩国、澳大利亚等62个国家，因为中国还未加入该协定，国内车企不会受到直接影响，但是如果要出口到这些国家，仍然需要通过认证。

R155的核心要求包含两大部分：

OEM必须建立和实施网络安全管理体系（CSMS），主要包含安全策略与目标、风险管理过程、安全开发生命周期、安全运维这四部分，旨在处理与网络威胁相关的风险，并保护车辆免受网络攻击。

OEM必须通过车辆型式认证（VTA），而通过VTA主要需满足两个条件：一是具备CSMS合格证书；二是证明CSMS已在对于车型项目上有效地执行。

这意味着R155的法律主体责任在OEM。当然，OEM会将要求传递到整个供应链。

此外，该法规生效后有一定的过渡期，各国具体落实时会有差异，欧盟时间节奏比较有代表性，如下：

2022年7月1日起适用于新车型，但不涉及电子电器变化的现有架构小改款可以豁免。

2024年7月1日起适用于所有车型，即尚未停产的旧车型也需要升级以满足。

在2022年至2024年期间，对于现有架构的新车型上市，若无法按照CSMS开发，则VTA应证明在开发阶段已充分考虑网络安全。

2025年1月1日起，过渡期结束，要求所有主机厂的所有车型必须通过CSMS+VTA的认证，标志着法规的全面实施和严格监管的开始。

(2)R156

R156，即《关于批准软件升级与软件升级体系的统一规定》，要求OEM建立完善的软件升级管理体系，以确保汽车软件安全可靠的升级，包含软件升级的流程与策略、升级前的验证、升级过程中的监控以及升级后的验证等环节。

与R155一样，该法规同样在2021年1月22日生效，并适用于《1958年协定书》的缔约国，认证方式也为车辆软件升级管理体系（SUMS）认证+车型（VTA）认证。但在实施时间上，除了欧盟于2022年7月正式实施这一信息外，而并未见其余过渡时间点的定义。

(3)21434

ISO/SAE 21434，即《道路车辆-信息安全工程》是汽车信息安全领域首个国际标准，于2021年8月31日正式发布，覆盖了汽车完整的生命周期，包括概念、开发、生产、运维、停运等所有过程。

大家很自然会问到R155和21434之间的关系。整体来说，R155法规只规定了做什么，从概念层面进行了宽泛的要求，而不能指导如何做，21434则可以作为标准来指导我们的具体实践以满足R155法规要求。

5.2 国内法规标准框架

在国内，从最高的层面来看，我们有国字头的法律，包括《网络安全法》、《数据安全法》、《个人信息保护法》、《密码法》等.

在此基础上，工信部办公厅于2022年2月25日印发了《车联网网络安全和数据安全标准体系建设指南》，从而系统地牵引信息（网络）安全标准体系建立的框架（如图4所示），截止指南发布时，已有103项法规标准已发布或正在制定中，如表2（指南发布时的状态，当前已有变化，仅参考条目内容）。

其中，最值得关注的是，类似于R155与R156的《GB 44495-2024 汽车整车信息安全技术要求》与《GB 44496-2024 汽车软件升级通用技术要求》，二者均于2024年8月23日发布，并于2026年1月1月实施，为国内强标。

图4 车联网网络安全和数据安全标准体系框架图

表2 车联网网络安全和数据安全相关标准项目明细表

5.3 已发布的重要法规标准汇总

目前已经发布的重要法规标准总结如表2。

表2 已发布的主要汽车信息安全法规标准

6汽车信息安全保护模型及常见风险

汽车信息安全是一个非常宏大且冗长的体系，会比传统意义上的汽车软件工程有更大的范畴。

为了获得一个整体的视角，我们从信息安全要保护的对象或者说可能有风险的对象来划分范畴，即可分为车内系统、车外通信和车外系统，如图5所示。本文中，我们把重点放在与汽车更紧密的车内系统和车外通信上。

图5 信息安全保护对象模型

6.1 车内系统

车内系统分为软件系统、电子电气硬件、车内数据、车内通信（即车内系统、组件之间的CAN、LIN、以太网通信等）。总结常见信息安全威胁如下。

ECU篡改：反汇编二进制文件、更改程序代码等。使用非制造商生产的软件更新ECU。地图数据库中毒。使用或安装恶意软件。滥用特权窃听并注入新消息。远程代码执行。密码/密钥攻击。总线关闭攻击。用户通过越权方式访问软件系统。利用用户身份认证不充分或默认账号密码未修改等问题非法访问。利用不安全的远程访问或控制组件远程非法访问。利用隐藏的服务和端口攻击系统。操纵软件升级的确认机制。重放合法的升级软件包。软件升级时缺乏来源合法性和完整性检查。缺乏信息安全日志或其他事件记录系统。软件系统缺乏可信的启动机制。访问认证机制缺乏防暴力破解措施。对接收到的输入命令不校验格式合法性。通过后门非法进入软件系统。缺乏预警与监控机制。芯片缺乏独立的信息安全存储空间。针对芯片的信息安全存储进行攻击。攻击基于芯片的软件系统可信启动机制。直接接入硬件JTAG调试接口进行非法调试。攻击物理设备或利用物理泄露进行攻击。车内系统对安全重要参数存储缺乏有效的保护措施。车内系统对存储的数据缺乏有效的访问权限控制。车内软件涉及安全重要参数保护不当而泄露。车内系统的配置参数缺乏有效的保护。车辆共享同样的安全重要参数导致代码注入攻击。

6.2 车外通信

车外通信，即整车与车外终端的通信，具体分为车外远距离通信（蜂窝移动通信、卫星导航等）、车外近距离通信（蓝牙、NFC和Wi-Fi等）。总结常见信息安全威胁如下。

（1）远距离通信

窃听或修改两个节点之间的通信数据。嗅探并接管已建立的会话。用海量消息淹没通信通道，耗尽资源。重复发送过去未过期的信号。消息篡改，删除或更改数据内容。假装是合法节点发送虚假消息。伪造网络标识符并传递给合法节点。不可抵赖性攻击：否认通信行为。密钥/证书复制：使用重复的密钥或证书。发送极端路由以溢出路由表。强制连续ACK和重新同步TCP连接。修改路由信息或更改转发路由请求的条数。广播欺骗数据包，包含恶意节点路由。创建假的路由节点，吞噬数据包。仅抑制或修改来自某些节点的数据包。利用漏洞混淆路由机制。创建路由循环，转发数据包而非最佳路由。快速转发路由请求以增加发现攻击者路由的概率。向网络或总线注入任意消息。创建并发送虚假消息。查找密码、密钥等以授予访问权限。窃取个人数据或网络信息。利用时间差异推断敏感信息。对汽车实现通信欺骗：伪造基站、路基通信设施身份等。利用通信通道实施DoS/DDoS攻击。架设无线干扰器干扰信号。通信加密密钥被窃取或明文通信。通信通道完整性保护密钥被窃取或未采用保护措施。发送伪造的服务拒绝响应消息。针对证书发放系统的攻击。

（2）近距离通信

对摄像头的干扰攻击，使摄像头失明。激光雷达的致盲攻击和欺骗攻击。超声波干扰器干扰。雷达干扰攻击。GPS干扰和欺骗。超声波和雷达欺骗攻击。摄像头的欺骗攻击。Wi-Fi相关攻击：端口攻击、弱口令攻击、协议栈攻击、内网渗透、中间人攻击、钓鱼攻击。蓝牙相关攻击：数据加密攻击、关键业务认证缺陷、协议栈漏洞、重放攻击。无线电信号干扰和遥控钥匙干扰。位置跟踪攻击和轨迹跟踪攻击。车内网络未采用分区分域信息安全隔离方式。车内网络连接缺乏真实性和完整性校验机制。车内网络系统缺乏防DDoS或流控措施。通过OBD接口或植入恶意软件监听车总线。伪造门禁控制命令和车钥匙。伪造近距离通信报文。通过接触式通信接口入侵车内系统。针对车内无线局域通信的攻击。

78个信息安全设计原则

信息安全的技术手段有很多，本文不做扩展，仅从设计原则的角度进行总结。

业务适用性原则：产品的信息安全设计应结合业务或功能环境的实际需求，同时考虑对业务或功能的正常使用的影响。

软件无后门原则：软件系统不应留有后门。

功能最小化原则：越复杂的系统有越多的潜在攻击面，无用的软件组件、协议端口和ECU硬件调试接口应禁用或移除；器件的管脚信息不宜暴露。

最小化授权原则：产品的访问和信息处理活动应只授予最小的必要权限。

权限分离原则：重要保护对象的信息处理活动应具备两个或两个以上的权限，且各权限应相互分离和单独授予。

默认设置原则：产品应完成默认的信息安全设置，该设置对用户的信息安全设置诉求应做到最小化和最简单化，即尽可能默认设置下就是安全的。

失效安全原则：即便系统崩溃，信息安全机制仍然有效。

不信任原则：第三方软硬件及数据须先完成合法性检验，再进行使用。

8车上易受攻击的6类产品

在日常的工作中，我们会更多聚焦在产品上，本节总结易受攻击的产品类别及攻击手法示例。

8.1 智能座舱系统

控制智能座舱相关系统：攻击者可以通过IVI系统控制车辆的关键功能，如打开和关闭麦克风、监听驾驶员谈话、获取通话历史和汽车通讯录等，严重威胁到车主的隐私安全。

获取IVI控制权：通过ADB（Android调试桥）连接到车机系统，攻击者可以轻易地安装恶意软件、修改系统设置、查看敏感信息等，进而实现对车辆的完全控制。

远程攻击：攻击者可以利用云端或社交软件的漏洞，向车主发送恶意文件或消息，一旦车主点击或下载，恶意代码便会在IVI系统中执行，导致车辆被远程控制或数据泄露。

8.2 智能网联系统（T-BOX）

中间人攻击：攻击者可以通过车载Wi-Fi热点进入车机网络，利用未隔离的域控制网关访问各种ECU，进而实现对车辆的控制。

固件攻击：攻击者可以提取、逆向、篡改T-BOX的固件，从而控制T-BOX，甚至进一步控制车辆。

CAN总线注入：通过向CAN总线发送恶意数据帧，攻击者可以模拟动力域的启动指令，实现对动力系统的控制，导致车辆被非法启动或行驶。

8.3 中央网关

OBD攻击：通过OBD接口注入恶意数据帧，攻击者可以控制车辆的CAN总线，进而实现对车辆的控制。

USB、蓝牙、Wi-Fi攻击：利用这些外部接口，攻击者可以获取车辆的访问权限，进行未授权访问，甚至植入恶意软件。

OTA升级攻击：通过绕过签名验证等安全机制，攻击者可以篡改车辆的固件，实现对车辆的控制或植入后门。

8.4 智能驾驶系统

机器学习对抗：攻击者可以通过对抗性机器学习技术，对车辆的感知系统进行攻击，如混淆限速标志等，导致车辆做出错误的决策。

致盲攻击：利用强光干扰摄像头、激光雷达等传感器的正常工作，导致车辆感知系统失效。

欺骗攻击：通过发送虚假信号欺骗传感器，使车辆做出错误的决策，如误判交通信号灯等。

多传感器融合攻击：攻击者可以利用多传感器融合算法的漏洞，实现对车辆的欺骗或控制。

无线通信攻击：通过蓝牙、Wi-Fi、GNSS等无线通信方式，攻击者可以实现对车辆的远程控制或数据窃取。

8.5 手机APP

数据泄露：攻击者可以通过手机APP获取车主的重要数据信息，如车辆位置、行驶轨迹等。

网络钓鱼攻击：攻击者可以伪造手机APP或发送伪装成官方通知的恶意链接，诱骗车主输入敏感信息。

恶意软件：攻击者可以在手机APP中植入恶意软件，实现对车辆的控制或窃取车主数据。

越权访问：如果云端服务存在漏洞，攻击者可以冒充车主控制他人车辆，造成严重的安全隐患。

8.6 智能钥匙

重放攻击：攻击者可以录制无线钥匙的解锁信号，并在适当的时候进行重放以解锁车辆。

中继攻击：利用中继装置延长无线信号的传输距离，攻击者可以在车主不知情的情况下解锁车辆。

蓝牙钥匙攻击：针对采用蓝牙通信的智能钥匙，攻击者可以通过蓝牙通信漏洞实现对车辆的远程控制或数据窃取。

9全文小结

本文首先从汽车电子与软件的三大安全引出，通过对比与功能安全的差异，介绍了信息安全的基本概念和21434中分析方法（TARA）。

标准显然不止21434，故梳理了国内外法规标准的框架和已发布标准的现状，圈定了我们大体的工作目标与范围。

此外，结合信息安全保护对象模型框定了我们汽车信息安全的技术范畴。同时，总结了常见的威胁。而对应于威胁，阐释了8个信息安全设计与防护的原则。

最后，从易受攻击的产品角度，对常见攻击手法进行了汇总，以给读者更直观的感受。

10写在最后

汽车信息安全所涉及的工程层级之深、技术栈之广、供应链之长以及生命周期覆盖之全，是很少有其他主题能够相当的。

这倒是侧面反映出智能汽车生态剧变和新技术高度融合碰撞的特点。

原文标题:万字长文解读汽车信息安全框架

来源：OFweek