汽车软件开发阶段安全的意义与原则

上海磐时 PANSHI

“磐时，做汽车企业的安全智库”

好书分享/ 《一本书读懂智能汽车安全》

汽车软件开发阶段安全的意义与原则

本文节选自SASETECH 汽车安全社区组织编写的《一本书读懂智能汽车安全》，该书由磐时创始人边俊、博世汽车曲元宁以及吉林大学教授张玉新主导，汇聚了博世、蔚来、小鹏、磐时、卓驭、地平线、上汽、吉林大学等业界和学界在汽车安全领域的实践经验和研究成果。它系统地展示了智能汽车研发全流程的功能安全、预期功能安全和网络安全，以及三者如何在复杂的智能驾驶系统中实现高效安全的融合。书中丰富的案例和实践经验对于提升产品安全性，优化用户体验具有极大的参考价值，是智能汽车开发团队的优秀读物。

以下内容节选自《一本书读懂智能汽车安全》：

无论是功能安全还是网络安全相关的标准，都对软件提出了诸多需求。那么，这些需求背后的逻辑是什么?为什么会有这些需求?回归本质看安全标准背后的东西，我们才能更好地理解需求，更好地落实需求。本节将尝试从原理出发，为大家阐述什么是软件安全。

01.

软件安全的含义

1.1 经典软件事故

回顾刚刚过去的几年里，软件事故发生的频率越来越高。软件事故是指软件出错造成不可恢复的系统故障。在汽车领域，常见的软件事故包括功能安全事故和网络安全事故。下面通过两个例子来分别介绍经典软件事故。

（1）Case 1：功能安全事故

2013年10月24日星期四，俄克拉荷马州的一家法院对丰田公司不当加速导致乘客死亡的案件做出了判决。此案件的核心是发动机控制模块（ECM）的固件。

最终结论是：

◆丰田汽车的电子节气门控制系统（ETCS）源代码不合理。

◆丰田汽车的源代码存在缺陷和错误，包括可能导致意外加速的错误。

◆代码质量指标预测存在其他错误。

◆丰田汽车的失效保护机制存在缺陷和不足。

◆丰田汽车 ETCS 的不当行为是意外加速的原因。

在技术调查中，ECM软件构成了调查的核心。关于堆溢出方面，丰田声称仅使用了分配的堆栈空间的 41%，但专家的调查显示，实际使用的堆栈空间高达 94%。除此之外，在代码中还发现了堆栈终止、MISRAC规则违反递归等问题，并且 CPU 没有结合内存保护来防止堆栈溢出。

内存中的单个位控制着每个任务，因此硬件或软件故障导致的损坏会暂停所需任务或启动不需要的任务。车辆测试证实，某一特定的停滞任务将导致油门控制失效，驾驶员必须在意外加速事件期间将脚完全从制动器上移开，才能结束意外加速。在代码中发现了一系列其他错误，包括缓冲区溢出、不安全的铸造，以及任务之间的竞赛条件。

此外，凯美瑞 ETCS 代码还被发现有11000个全局变量。专家将该代码描述为“意大利面条”(圈复杂度)。丰田宽松地遵循了广泛采用的 MISRAC编码规则，但专家组发现有 80000处代码违规。丰田公司自己的内部标准仅使用了11条MISRAC规则，其中5条在实际代码中被违反。专家还发现，同行代码审查不充分且未经跟踪，丰田也没有任何缺陷跟踪系统。

（2）Case2：网络安全事故

腾讯科恩实验室在 2016 年和 2017年对 Tesla 汽车进行了两次引人注目的远程攻击，成功利用多个高危安全漏洞（包括内核、浏览器、MCU 固件、UDS 协议，以及 OTA 更新过程中的漏洞），攻人了 Tesla 汽车的关键系统，如 CID、IC、网关和自动驾驶模块。这些攻击不仅展示了车联网系统的脆弱性，也促使 Tesla加强了其安全防护措施，包括及时发布安全补丁和更新。同时，这些案例也引起了汽车行业对网络安全的广泛关注，推动了相关标准和法规的制定与完善。

1) Tesla 汽车车联网系统攻击案例分析

首先介绍远程攻击面。Tesla在每辆汽车中都内置了一个 WiFi TeslaService，其密码以明文形式保存在 OtCarNetManager 中,，正常模式下不会自动连接。

首先介绍远程攻击面。Tesla在每辆汽车中都内置了一个 WiFi TeslaService，其密码以明文形式保存在 QtCarNetManager 中，正常模式下不会自动连接。

TeslaGuest 是特斯拉 4S 店和充电站提供的 WiFi热点，这一信息被保存在汽车中，以便自动连接。研究人员可以制作一个钓鱼热点，当Tesla用户使用 CID 搜寻充电桩时，可以将OtCarBrowser 的流量重定向到自己的域名，从而达到远程攻击的目的。

除了 WiFi技术，在蜂窝网络下，攻击者如果建立足够多的网站，利用网络钓鱼技术或用户失误，也可以达到入侵的目的。

其次介绍浏览器攻击。从 Tesla 车载浏览器的 user-agent得到“Mozilla/5.0（X11;Linux）AppleWebKit/534.34 （KHTML, Gecko）likeQtCarBrowser Safari/534.34”,可以得出 OtWebkit 的版本是 2.2.x。这是一个比较老的版本，存在许多漏洞。腾讯科恩团队利用了其中两个漏洞实现了任意代码执行，从而攻击浏览器。

2) 语音控制系统破解案例

“海豚音攻击”的原理是将语音命令的频率转换为超声波频率信号，由于该信号超出人耳接收频率的范围，无法被人听见，但可以被手机、智能家居以及智能汽车等智能设备的语音控制系统接收到。

由于麦克风的非线性特性，原本被调制的语音命令会被解调，恢复到调制之前的状态。之后，滤波器会过滤掉人耳不可听到的部分，这样语音指令可以无声无息地被语音识别系统识别到，最终实现攻击。

汽车制造商在面临上述功能安全或网络安全问题时，通常会采取批量召回措施来作为事故后的处理。召回的目的是解决这些问题，确保消费者的安全，并维护企业的声誉。图6-23展示的是我国 2021年缺陷涉及总召回数量的分布。从缺陷涉及的总成来看，发动机和电子电气系统是主要的缺陷产生部件，占总召回数量的 84.3%。因发动机总成缺陷实施召回 50 次，涉及车辆 371.3万辆，占总召回数量的 42.5%;因电子电气系统缺陷实施召回 54 次，涉及车辆 365.0万辆，占总召回数量的 41.8%;因制动系统缺陷实施召回 21 次，涉及车辆 51.0万辆占总召回数量的 5.8%。

一直以来，发动机都是主要缺陷产生的部件。近年来，因发动机问题，无论是合资品牌还是自主品牌，都曾发布过大规模召回公告。随着电动化和智能化的发展，电气设备的安全 问题也逐渐凸显，如今其缺陷占比已经接近发动机缺陷的比例。

值得关注的是，近两年的召回趋势向新能源动力特征变化，软件、电池等的召回逐步增多，类似传统车的发动机缺陷特征。从表 6-2 可以看出，软件性召回在 2023 年爆发式出现。 软件性召回的增多，也说明了无论传统车还是新能源车的软件问题都逐步显现。同时，召回政策和标准也需要不断完善，规范车辆软件设计、编码和测试，从而阻止软件事故的发生。

软件安全是软件开发和运行过程中的一个重要问题，它涉及网络安全、功能安全和性能 安全等多个方面。

随着软件性召回事件的日益增多，这一趋势凸显了在软件开发过程中安全性问题的重要性。这需要考虑功能安全，确保车辆关键系统的可靠性和稳定性，也需要考虑网络安全，防止潜在的远程攻击和数据泄露，另外也要考虑汽车系统在规定的条件下和规定的时间内，完成既定功能的能力（即性能安全）。

网络安全是软件安全的核心内容之一，主要涉及数据和隐私的保护。网络安全包括防止非法访问、防止数据泄露、防止数据篡改等。为了保证网络安全，软件需要采用加密技术身份认证技术、访问控制技术等。

功能安全是指软件在正常运行和故障情况下都能保证其应有的功能服务。它主要涉及软件的可靠性和安全性。确定性虽然没有被功能安全标准提及，但我们认为确定性是 ISO 26262 标准的核心思想。为了保证功能安全，软件需要进行充分的测试和验证，包括单元测试、集成测试、系统测试等。

性能安全是指软件在高负载情况下仍能保持稳定运行。它主要涉及软件的性能优化和高负载能力。为了保证性能安全，软件需要进行性能测试和负载测试，以确保其在高负载情况 下仍能正常运行。

软件安全覆盖了软件生命周期的各个阶段，包括需求分析、设计、实现、测试和维护等。 在软件安全的生命周期中，软件设计和开发是保证软件安全的基础，测试是检验软件安全性的关键，维护是保障软件安全的重要手段。

02.

影响软件安全的因素

从安全的角度看，影响软件安全的因素可以分为运行硬件环境失效、软件自身失效、恶意入侵。

对于运行硬件环境失效，一般可以归为功能安全中的“硬件随机性失效”与“硬件系统 性失效”，以及预期功能安全中的“硬件性能局限”。此部分内容已在第 5 章展开介绍。

对于软件自身失效，一般可以归为功能安全中的“软件系统性失效”以及预期功能安全 中的“算法性能局限”。此部分内容是本章的关注点。

对于恶意入侵，一般可以归为网络安全的软件威胁。此部分内容是本章的关注点。

2.1 软件自身失效来源及分类

软件系统性失效是指软件系统中出现的一系列相似或相关的错误或缺陷。这些错误或缺陷通常不是由单个错误引起的，而是由系统中的多个因素相互作用而导致的。从整个软件开 发生命周期的角度看，软件系统性失效主要来源如下。

1）软件需求不合理：软件需求不合理是软件系统性失效的主要来源之一。针对传统系统 来说，需求传递不一致（如客户需求和系统需求不一致，软件需求与软件模块需求不一致）是 导致软件需求不合理的主要因素。对于自动驾驶或一些复杂系统而言，需求不合理还源于难 以识别用户需求或场景需求。由于一些 Corner Case 的存在和用户误用的可能，软件需求往往很难考虑周全，这部分属于预期功能安全的范畴。

2）软件设计错误：软件设计错误通常是指在软件设计过程中出现的一系列问题或缺陷。 这些问题或缺陷通常不是由单个错误引起的，而是由设计过程中多个因素相互作用导致的。 导致软件设计错误的最大问题是软件的复杂性和不确定性，比如，多个设计决策之间的冲突、 错误之间的串扰、资源（如内存、 CPU）的非预期占用等。

3）编码错误：编码错误是软件系统性失效的另一个常见来源。编码时的疏忽或者错误的 代码逻辑，导致软件不能正常运行或者出现异常。

4）软件测试不充分：软件测试不充分是软件系统性失效的另一个重要因素。如果软件测试不够严格，漏洞和错误可能不被发现，导致软件系统性失效问题出现。

5）软件算法能力不足：预期功能安全会引入机器学习技术问题。机器学习因算法能力不足或训练数据质量问题会引发软件系统性失效，例如未选择最合适的算法、样本特征选择不当或硬件资源的限制导致的算法性能局限。训练数据的质量问题通常源于数据集的不完整性 或数据标记的不准确性。

2.2 常见的软件威胁及分类

近些年，由于汽车智能化、网联化、电动化和共享化的发展，汽车软件代码量不断增加。2016年，主流车型约含 1.5 亿行源代码。预计到 2025 年，汽车使用的代码量将达到 2 亿行。随着软件代码量的不断增加，对应的软件安全威胁也呈指数级增长。软件层级主要包括“设计阶段的软件威胁及漏洞”和“实施阶段的软件威胁及漏洞”。

（1）设计阶段的软件威胁及漏洞

根据微软的 STRIDE 威胁模型，软件的安全威胁主要分为六类，分别为 Spoofing、 Tampering 、Repudiation 、Information Disclosure 、Denial of Service 和 Elevation of Privilege。

1）Spoofing。这种威胁主要指攻击者假冒合法有效的系统用户来访问系统，从而危及系统安全。

示例：

在车云通信场景中，恶意冒充者伪造正常的 IP 数据包，劫持与服务器的连接。这里的威 胁及漏洞是由于通信协议在设计时未考虑保密性和完整性。

在车云通信或车内通信场景中，不正确使用密钥或密钥泄露可能导致攻击者窃听网络交 互的敏感数据，进而冒充合法用户。这里的威胁及漏洞是由于密钥等数据没有被有效防护。

2）Tampering。这种威胁主要指攻击者对软件或数据在使用、存储、传输过程中进行恶意 修改，以达到对系统破坏或数据篡改的目的。

示例：

在车内或车外通信场景中，对发送的数据进行篡改，例如将车窗控制指令由开更改为关。 这里的威胁及漏洞是由于在通信链路上发送的数据缺乏完整性。

在未授权的情况下修改系统的关键配置文件、用户数据等。这种威胁及漏洞是由于缺少访问检查、没有进行完整性检查等。

3）Repudiation。这种威胁主要指攻击者否认其行为，系统缺乏追踪、日志和溯源的能力，无法证明其行为。

示例：

用户恶意删除系统中的敏感文件，或攻击者频繁使用用户账号登录的行为。这种威胁及漏洞是由于缺少对用户登录行为的有效审计，或对异常登录状态的日志。

4）Information Disclosure。这种威胁主要指泄露用户的敏感信息或关键业务信息给非授权用户。用户能够获得未被授予访问权限的数据，以及攻击者能够在网络传输过程中获取数据等行为，都属于信息泄露威胁。

示例：

通过使用一些工具（例如 CANOE），可以获取车内通信的 CAN 报文，并从未加密的数据包中轻松地得到车辆的控制指令，或者传输的用户数据、OTA 数据包等敏感信息。

5）Denial of Service。这种威胁主要指攻击者将系统资源耗尽，导致系统不可用或无法提供正常服务，进而影响用户的正常使用，损害整体功能。

示例：

在 HTTP 通信场景中，SYN 泛洪攻击会导致正常用户无法连接服务器，甚至可能导致服务器崩溃。

薄弱的软件设计或配置，导致一个进程占用了几乎所有的 CPU 资源。

6）Elevation of Privilege。这种威胁主要指普通用户获取了系统的访问权限，从而拥有足够的权限达到损害或破坏整个系统的目的。

示例：

在未经授权用户同意的情况下运行可执行文件来实现攻击。

(2) 实施阶段的软件威胁及漏洞

正如上文所说，在设计阶段存在多种威胁及漏洞，但是即使对“设计阶段的软件威胁及漏洞”采取了措施，也无法完全避免在软件具体实现过程中出现安全威胁及漏洞。同时，安全编码不完善导致的实施阶段的威胁及漏洞可能会引发严重的损害。根据 CWE 披露的安全缺陷 CWE TOP 25，常见的软件安全漏洞类型如下。

1）越界写入。越界写入即缓冲区溢出，指当应用程序在预期输入缓冲区的边界之外写入数据时出现这种安全漏洞。当应用程序执行指针运算或更改索引以引用内存缓冲区之外的位置时，也可能导致该弱点，通常会导致意外执行非预期的代码、程序崩溃或数据损坏。

2）越界读取。越界读取指的是当应用程序读取超出预期输出缓冲区边界之外的数据时出现这种安全漏洞。攻击者可以通过读取越界内存中的敏感信息，获取绕过身份验证机制的信息，并利用其他弱点进一步获取敏感数据。

3）输入验证不当。输入验证是一种常用技术，用于检查潜在的危险输入，确保在代码处 理或与其他组件通信时输入是安全的。当软件不能正确验证输入时，攻击者能够以应用程序其他部分不期望的形式设计输入。这将导致系统接收到意想不到的输入，可能引起控制流的改变、资源的任意控制或任意代码的执行。

4）释放后使用。释放后使用主要指的是相关内存在被释放后的某个时间点被重新分配给另一个指针。指向已释放内存的原始指针再次被使用，并指向新分配内存的某处。数据被更改时，将破坏有效使用的内存，导致不确定的异常事件发生。

5）NULL 指针取消引用。NULL 指针取消引用是指应用程序解引用一个它认为有效的指针，但该指针实际为空，这通常会导致程序崩溃或退出。 NULL 指针取消引用问题可能由多种缺陷引起，包括竞争条件和简单的编程遗漏。NULL 指针取消引用通常会导致进程失败，尽管某些平台具有异常处理机制，但即使使用异常处理机制，也很难将软件恢复到安全的运行状态。

03.

功能安全软件的核心要求

3.1 功能安全软件与非功能安全软件的差异

在软件层面，相比于非功能安全软件，功能安全软件在开发过程中的差异主要体现在以 下几个方面。

（1）需求分析

在功能安全软件的需求分析过程中，我们需要将安全性作为重要的考虑因素，并制定相 应的安全性要求。而在非功能安全软件的需求分析过程中，我们则更加注重用户需求和技术实现等方面的考虑。

（2）设计过程

在功能安全软件的设计过程中，我们需要采用相应的安全设计原则，例如防御性编程、安全架构设计等，以确保软件的安全性。而在非功能安全软件的设计过程中，我们则更加注重功能实现和性能等方面的考虑。同时，为了进一步减少软件的系统性失效和硬件随机性失效，功能安全软件往往设计了许多用于故障检测的诊断功能。故障检测的颗粒度和时效性要求，往往是非功能安全软件不具备的。例如，针对单点失效，功能安全软件要求故障诊断和处理的时间需要小于故障可能造成危害的时间，这就导致功能安全诊断往往是实时的且间隔时间非常短（如小于 500ms）。

（3）测试流程

功能安全软件的单元测试需要涵盖所有的安全性要求，并进行全面的测试覆盖，以确保软件的安全性。而非功能安全软件的单元测试则更加注重功能的实现和代码的正确性。功能安全软件的集成测试需要测试软件各个部分之间的交互和协作，以确保整个系统的安全性。非功能安全软件的集成测试则更加注重系统的性能和用户体验。功能安全软件的嵌入式测试需要进行各种可能的场景测试，包括异常情况和故障恢复等方面的测试，以确保软件的安全性。非功能安全软件的嵌入式测试则更加注重系统的可靠性、可维护性和可扩展性。

总的来说，功能安全软件和非功能安全软件在开发过程中存在较大差异。为了保证功能安全软件的安全性，我们需要进行更加严格的开发和测试，并采用相应的安全设计原则。

3.2 常见的软件威胁及分类

安全论证是实施功能安全的重要环节。论证方法多种多样，从形式上来看，可以通过非 形式化的测试确认、过程确认等，也可以通过形式化的验证方式。其中，常用的形式化方法 是 GSN（Goal Structuring Notation）。

它通过图形化的结构，更好地展现某个论点在不同应用场景中的真实性及支持证据。GSN 广泛应用于安全性非常重要的行业，例如汽车、航空飞行器等。它是撰写安全案例的有力工具，可以以图形化的方式系统性地论证安全案例的正确性。

GSN 中的安全论证模型可以清楚展现证明文件中的论据及其相互之间的逻辑关系。每一个建立的安全论证模型都有完善和规范的体系，为后续第三方评估提供全面参考。

安全论证方法论总体思想见图 6-24。简而言之，安全案例的论证需要做到“有理有据”。“理”指的是要有道理，采用的标准、原理依据、必要的假设等；“据”指的是有证据，用真实、具体的证据证明安全目标。

GSN 相关的语法及语义如表 6-3 所示。

图 6-25 是典型的 GSN 示例。将 GSN 的各主要要素连接在一起，构成树状架构（即Goal Structure）。GSN 通过对安全目标的一步步分解和论证，直达叶子节点，即真实、具体的证据（又称 Solution）。在论证过程中，展现论证的策略以进行定量或定性分析、全量或部分分析，采用的原理和标准，必要的假设等，真正体现安全观点的有理有据。

04.

网络安全对软件的核心要求

随着汽车中嵌入的软件数量的增加，网络安全对于汽车软件变得越来越重要。广义上讲，汽车软件分为支持智能网联服务的云端软件和车端软件。作为移动的主体，随着网联化的进一步发展，汽车暴露的外部端口及信息也在增多。同时，随着世界各国对个人隐私数据保护的重视和各种法规的出台，车端软件的网络安全成为关注的重点。为保障车端软件的合规性以及网络安全性，车端软件需要满足以下核心要求。

◆信息的机密性保护：车辆必须保护所有敏感数据，如用户隐私、车辆位置、个人信息、 账号密码等。车辆必须使用加密技术来保护这些敏感数据，以避免被非法获取。常用 的方法是使用 TEE 分区，实现敏感数据和非敏感数据的隔离。

◆通信安全的保障：伴随车载以太网的部署，车辆软件必须使用安全的通信协议来与其他设备和服务进行通信。这些协议必须提供加密和身份验证功能，以确保通信的机密性和完整性。安全通信协议需要覆盖 OSI 的物理层、数据链路层、网络层、传输层、 会话层、表示层、应用层。每一层都需要根据实际的汽车电子电气架构，采用合理的 安全协议，例如网络层的 IPSec 和传输层的 TLS1.0 等。

◆软件和数据的完整性保障：确保汽车软件不被恶意软件或黑客篡改。使用数字签名、 数字证书和其他技术来验证软件和数据的完整性。当然，带来的新挑战是如何有效管 理数字证书的有效性。

◆车辆的可用性防护：车辆必须保护其软件和数据的可用性，以确保它们不受到拒绝服 务攻击或其他形式的恶意攻击。车辆必须使用安全的网络协议和硬件来防止此类攻击。

◆安全的软件更新：车辆软件必须能够安全更新，以免受已知漏洞攻击。安全更新必须 能够安全下载和验证，以避免恶意软件注入。

◆安全的系统启动：车辆软件必须通过安全启动过程来确保启动的软件没有被篡改或入侵。安全启动可以使用数字签名和硬件保护来实现。

◆安全事件预警：车辆软件需要通过内嵌的安全探针实时监控车辆安全漏洞，并能够远程上报至 VSOC 平台，实现智能化的预警及安全事件反馈。

在工程落地实践中，网络安全与功能安全会出现交叉，需要负责网络安全与负责功能安全的工程师密切配合。当然，我们也必须意识到，网络安全是无止境的。过度的安全防控会导致汽车性能和使用便捷性下降。因此，网络安全做什么，如何做，以及如何实现网络安全与整车性能的均衡，是汽车工程实践的核心工作。