安全电子控制单元（ECU）需考虑的网络安全问题

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

如今，汽车行业难以抵御网络安全威胁。近期诸多案例表明，汽车嵌入式系统易受网络攻击。黑客篡改软件，危及车内人员安全的风险始终存在。例如，黑客可能在车辆行驶时关闭车灯、锁定转向柱、触发安全气囊等。

在安全电子控制单元（ECU）方面，网络安全风险的影响更为显著。此外，ISO 26262 标准也开始关注网络安全问题。

网络安全问题涉及多个领域：

隐私：车辆或个人身份识别与追踪；

金融：个人或智能交通系统（ITS）运营商可能遭受的经济损失；

安全：对功能安全的影响。

例如，一次攻击可能对安全影响较小或无影响，但在侵犯驾驶员隐私或损害汽车制造商声誉方面却存在重大风险。

本文仅考虑网络安全对安全方面的影响。在列举几个安全目标示例后，我们将介绍汽车行业目前仍处于草案阶段的安全标准。接着，提出几个安全防护措施示例。最后，在总结之前，阐述网络安全流程的开发与验证。

汽车嵌入式系统日益复杂，安全风险也随之增加，尤其是那些能够响应并替代驾驶员操作的 ECU，如在车辆靠近前车时自动减速、在光线亮度低于或高于阈值时自动开关车灯、下雨时启动雨刮器等。

（1）安全目标 ASIL QM

在这种情况下，如果车内空调系统突然将冷风开到最大、收音机自动切换到本地嘻哈电台并调至最大音量，或者车载数字显示屏上出现家庭照片，会发生什么呢？

即便驾驶员的生命没有受到威胁，他肯定也会感到不悦。

（2）安全目标 ASIL A 或 ASIL B

继续想象一下，如果驾驶员并未操作，车窗雨刮器却突然启动，且刮水器液模糊了挡风玻璃，会怎么样？

或者在黑暗的无照明高速公路上，近光灯突然熄灭呢？

显然，驾驶员开始面临危险。

（3）安全目标 ASIL C 或 ASIL D

如果油门失灵、汽车在驾驶员无操作的情况下加速，或者在高速行驶时意外熄火，又会如何呢？

或者转向、刹车和变速器都失去控制……？

驾驶员将真正陷入危险，生命受到威胁。

克里斯・瓦拉塞克（Chris Valasek）和查理・米勒（Charlie Miller）就曾利用汽车设计中的一些缺陷，远程控制车辆，上述可怕场景真实发生过。如果联网汽车未考虑网络安全问题，黑客就有可能通过笔记本电脑，向车辆的仪表盘功能、转向、刹车和变速器发送指令，而这台笔记本电脑可能远在世界另一端。这种通过互联网进行的无线控制，甚至可以操控数千辆汽车。

国际标准化组织（ISO）和美国汽车工程师学会（SAE）在道路车辆领域合作紧密。制定了汽车网络安全的首个标准 ——ISO/SAE 21434《道路车辆 —— 网络安全工程》 。最终，该标准应会取代 SAE J3061《信息物理融合汽车系统网络安全指南》。SAE J3061 规范于 2016 年发布，是一份具有实际指导意义的建议文件，为车载系统网络安全的完整设计提供了工程流程框架，以便与其他开发流程相结合。

制定汽车网络安全标准具有诸多益处：为网络安全工程定义一系列标准、统一术语、就网络安全问题达成行业共识等，从而尽量减少汽车行业中汽车制造商和供应商等不同参与者之间的矛盾。

（1）ISO/SAE 21434 标准的适用范围

ISO/SAE 21434 标准适用于道路车辆及其子系统、组件、硬件和软件。其主要目的是建立一个结构化流程，实现 “设计即安全”。

ISO/SAE 21434 标准在开发过程中采用与 ISO 26262 相同的生命周期。在整个生命周期的各个阶段，都必须考虑安全因素。一辆安全的汽车，是在设计阶段实施安全要求的结果。

该标准不会阐述具体的网络安全实践，如应使用的解决方案或技术，也不会推荐加密方法、应对措施等。

图1.网络安全V周期

（2）风险评估

确定合理的高安全风险级别（而非最高安全风险级别）是该标准的主要目标之一。风险评估研究始于 “威胁分析与风险评估”（TARA），其在安全性方面的对应流程是 “危害与风险分析”（HARA）。

与 HARA 类似，TARA 是一种用于识别和评估网络安全风险（攻击、威胁和漏洞）潜在危害的方法。该方法制定了一系列应对措施，以降低风险。风险级别需根据危害场景进行评估，并通过应对措施（如加密）降低风险，直至剩余风险级别可接受。

在 TARA 方法中，确定风险时会涉及多个因素。不仅要考虑影响，还要考虑漏洞是能被所有人利用，还是只有专家才能利用；是可以远程利用，还是需要物理接触车辆；是只影响某一辆特定汽车，还是同一型号的所有汽车……

如果只有专家才能利用漏洞、需要物理接触车辆且只影响某一辆特定汽车（例如，每辆车的加密密钥都是唯一的），那么风险较低。反之，如果所有人都能远程利用漏洞，且影响整个车队（例如，所有汽车的加密密钥都相同），则风险较高。

（3）流程阶段以及 ISO 26262 和 ISO/SAE 21434 之间的关系

安全流程（ISO 26262）不足以涵盖网络安全流程（ISO/SAE 21434）的特殊性。每个标准都有各自的流程。设计者必须兼顾这两个流程。

以下是两个流程的一些异同点。在描述车辆系统时，ISO 26262 使用 “项（item）” 这个术语，而 ISO/SAE 21434 使用 “特征（feature）”。因此，ISO 26262 和 ISO/SAE 21434 必须应用于同一 ECU。

对关键系统的网络攻击有可能导致系统故障，其产生的影响与安全关键系统中的故障类似。两个标准中 “危害” 的概念相同，均指对人员身体的伤害或健康损害。在安全性方面，危害的来源是危险；在网络安全方面，危害的来源是威胁。HARA 和 TARA 是生命周期中的阶段，也有相似之处，它们都提供了降低潜在危害的通用技术。HARA 是定义安全目标、提供安全措施的基础，而 TARA 用于定义网络安全目标并提供网络安全措施。

在两个标准中，目标都是顶层要求，在生命周期阶段会分解为更细化的要求。当同时应用这两个标准时，所有安全和网络安全的顶层要求将用于创建系统架构。

这两个流程都需要高层次的系统描述，以生成初步的架构期望。在系统层面，技术要求被分配到系统架构中，然后细化为硬件和软件架构设计。两个标准的流程阶段及其横向关系如图 2 所示。

图2.两个标准之间的横向关系

在本部分，我们将描述在典型汽车 ECU（如发动机控制单元或车身控制器）中可实施的主要网络安全防护措施。我们不涉及与多媒体功能相关的 ECU，由于存在蓝牙、Wi-Fi 等不同的攻击可能性，这类 ECU 的防护措施必须更加严格。

在我们的案例中，ECU 配备有微控制器，同一芯片内包含用于存储软件和数据的存储器。软件从存储它的闪存中执行（不在随机存取存储器（RAM）中复制），网络通信仅限于汽车中常见的控制器局域网（CAN）或本地互联网络（LIN）。

（1）密钥管理

在网络安全中，资产保护主要基于加密密钥或签名密钥。这些密钥必须保密，否则安全将受到威胁。

可以将密钥存储在称为硬件安全模块（HSM）的特定设备中。通常，HSM 集成在微控制器芯片内，对于多核微控制器，它包含主核心。例如，当一个核心需要加密数据时，会将待加密数据发送到 HSM（通过共享内存）。数据在 HSM 内使用加密密钥进行加密，加密结果返回给核心。通过这种方式，加密密钥在 HSM 中得到安全保护，核心不知道其值，也无法访问。此外，HSM 通过集成硬件加速器（如用于加密和解密的 AES 128）实现快速操作。

一旦加密和签名密钥存储在 HSM 中，攻击者就无法访问。然而，我们必须考虑两点。第一，在将密钥存储到 HSM 之前，必须采取预防措施，避免密钥被访问。这超出了本文的讨论范围，但在计算机中存储密钥以及将其传输到 ECU 的过程也必须具备强大的抗攻击能力。第二点是 HSM 的保护程度。除非微控制器存在已知漏洞，否则攻击者获取 HSM 中的密钥将耗费大量时间和成本，且可能不会成功。然而，如果所有 ECU 的密钥相同，攻击者可能会尝试读取 HSM，因为他们只需操作一次，成本效益比可能对他们有利。但如果密钥不同，攻击者需要重复进行高成本操作，且无法确定是否有效。因此，尽管密钥管理会更困难，但为每个 ECU 设置不同的密钥会更安全。例如，在加密 ECU 中的一个安全数据时，每个 ECU 使用不同的加密密钥会更加安全。在车辆 1 的 ECU1 中，使用密钥 1 进行加密 / 解密；在车辆 2 的同一 ECU1 中，对相同数据使用密钥 2 进行加密 / 解密。最后一点，密钥的选择必须随机，这样就无法根据车辆 1 中的密钥 1 确定车辆 2 中的密钥 2。

图3.汽车中的典型网络架构

（2）安全启动

安全启动的目的是确保 ECU 中运行的软件是已知且可信的。在启动软件之前，需检查软件是否有效，未被篡改。一种常见的检查方法是在闪存中软件的末尾写入其循环冗余校验（CRC）值，每次启动时重新计算 CRC 并与闪存中存储的值进行比较。但这种方法不足以确保网络安全，实际上，计算闪存的 CRC 更多是为了检查闪存的完整性，而非软件的有效性。而且 CRC 很容易被破解，攻击者能够修改软件并轻松计算其 CRC。

为实现强大的安全启动，软件必须使用加密算法（如 AES - CMAC - 128）进行签名。与 CRC 类似，每次启动时都会计算软件的签名，并与存储在 HSM 中的签名进行比较。因此，HSM 至少必须存储用于计算签名的加密密钥以及软件的签名。

如果计算出的签名与 HSM 中存储的签名相同，说明软件有效，可以启动。否则，说明软件已被篡改，出于安全考虑，不能运行。如有必要，可以启动安全状态。例如，如果检测到安全气囊软件被篡改，安全气囊软件将被阻止运行，从而避免安全气囊意外弹出，并向驾驶员报告安全气囊系统存在故障。

安全启动的时间性能取决于微控制器本身、其频率、闪存大小以及硬件加速器的设计。在我们的一个 ECU 中，一个 7MB 的软件进行安全启动大约需要 250 毫秒。由于每次启动都会进行安全启动，ECU 启动后并不能立即工作。首先要进行初始化，然后启动安全启动。在前面的例子中，还需要再加上 50 毫秒，所以 ECU 在 300 毫秒后才能准备好工作。对于某些应用来说，等待 300 毫秒再投入运行不是问题，但对其他 ECU 来说，这可能至关重要。因此，在进行安全启动时，我们可以采用两种不同的模式：串行模式和并行模式。在串行模式下，我们有足够的时间，在使用 ECU 之前等待安全启动完成。在并行模式下，由于严格的时间限制，我们无法等待安全启动结束，软件会在安全启动在 HSM 中并行运行时提前启动。如果安全启动后发现软件被篡改，HSM 将阻止正在运行的软件。

串行模式比并行模式更安全，因为在串行模式下，可能被篡改的软件根本不会被执行，而在并行模式下，软件会在短时间内执行，这期间它可能有机会利用微控制器的漏洞。因此，在启动 ECU 没有严格时间限制的情况下，最好采用串行模式。

（3）安全更新

为了实现可靠的安全启动，我们必须确保软件更新使用的是有效软件。实际上，如果我们有强大的安全启动机制，也必须有强大的安全更新机制。否则，攻击者可能会下载被篡改但被视为有效软件的程序。

我们必须使用一种机制来检查软件的有效性。例如，新软件进行签名，在安装之前检查其签名。典型的签名基于成对使用的非对称密钥：私钥和公钥。软件使用私钥进行签名，除了负责签名的机构外，私钥不被其他人知晓，签名会随软件一起发送。安装软件的 ECU 使用公钥计算签名，公钥是公开已知的。计算结果必须一致。如果结果不同，说明要安装的软件无效，安装将被中止。

此描述未提及证书和公钥基础设施（PKI）的使用，而这些对于提高安全性是必要的。此外，对于可通过空中下载的 ECU，传输过程以及后端服务器都必须进行安全防护。但这超出了本文的讨论范围。

使用前面提到的同一 ECU，检查 7MB 软件的签名大约需要 1.5 秒，这是在 HSM 中使用硬件加速器进行计算的时间。在这种情况下，时间不是关键因素，因为 ECU 此时并未运行，我们可能是在工厂或维修车间为 ECU 下载软件。

此外，在汽车行业的大多数情况下，程序内存位于微控制器内部，无需对软件进行加密保护。但二进制文件应受到保护，因为如果落入攻击者手中，他们可以对其进行反汇编，了解软件的工作原理，进而可能发现一些漏洞。

图4.签名验证示例

（4）安全存储

如果安全数据存储在微控制器外部的非易失性存储器（通常是电可擦可编程只读存储器（EEPROM））中，这些数据必须得到保护。我们可以使用 CRC，但同样，CRC 不足以确保网络安全，它很容易被破解。与安全启动一样，最好的解决方案是对数据进行签名，如果还想让安全数据不可读，可以对其进行加密。对于每个网络安全功能，我们必须使用不同的密钥，而不是始终使用同一密钥。

（5）安全调试

对于软件开发团队来说，即使在生产过程中，也常常需要调试软件。但这种调试功能不能成为黑客的后门。

例如，联合测试行动小组（JTAG）制定了片上仪器标准。它规定使用一个专用的调试端口，实现串行通信接口，大多数汽车用微控制器都具备这一接口。借助该接口，开发人员可以访问整个内存、寄存器，设置断点并记录执行的代码部分。这对开发人员非常有用，但从网络安全角度来看，这种访问极具危险性。通过该接口甚至有可能获取加密密钥。为避免这种情况，必须在访问调试功能前进行身份验证等保护措施，或者在 ECU 大规模生产时直接禁用调试功能。

（6）通信

在汽车领域，CAN 网络应用广泛。当接收器接收到一条消息时，它不知道发送者是谁。实际上，网络中的任何节点都可以发送消息。我们可以想象，原本应该发送消息的 ECU 被断开连接，取而代之的是一个工具发送消息。这使得攻击者能够发送错误消息，而接收者却认为这些消息是正确的。我们还可以想象，一个 ECU 的软件被入侵，攻击者重新编程使其发送包含错误数据的特定消息，这可能会对安全产生影响。在这种情况下，接收者无法检测到接收到的数据是错误的。

端到端（E2E）传输是一种常见的数据保护方法，通过在数据帧中添加计数器、校验和或 CRC 来保护数据。但 E2E 传输的主要目的是检查是否存在传输错误，而非防范攻击。攻击者可以轻松复制 E2E 传输。

为了防范攻击，我们可以在 CAN 网络中使用更复杂的系统。例如，发送者必须对发送到网络的每条消息进行签名。接收者在处理消息数据之前先检查签名。当然，为了避免重放攻击（攻击者记录两个 ECU 之间的通信并重新发送），每个发送帧的签名必须不同。因此，必须采用一种基于加密密钥的特定算法。

此外，在汽车领域，目前有许多工作致力于在 CAN 网络上部署入侵检测系统（IDS）。其目的是检测不应接收的消息。例如，一条消息应每隔 100 毫秒定期发送一次，但在上一条消息发送 20 毫秒后就收到了，这种情况将被报告并可能被视为虚假消息。

一些 ECU 可能有其他通信方式。例如，以太网在汽车领域的应用越来越广泛，尤其是在先进驾驶辅助系统（ADAS，如紧急制动、车道保持辅助等）和多媒体系统中。以太网也有其弱点，可以通过 IDS 和防火墙来弥补。

此外，一些 ECU 还可能具备蓝牙、Wi-Fi 或 2G/3G/4G 等无线连接。这些连接必须进行高度保护，因为通过这些连接，攻击者可以远程访问这些 ECU。通常，其保护措施与计算机中的类似。

图5.签名帧交换示例

网络安全级别越高，对规范制定、开发和验证环节的要求也就越高。网络安全保证级别（CAL）可用于确定网络安全活动的严格程度。CAL 分为从 CAL1 到 CAL4 的四个级别，其中 CAL4 为最高级别。目前并没有确定 CAL 的特定规则，不过其级别可以依据攻击影响和攻击途径来确定，例如是需要物理接触 ECU 的攻击，还是远程攻击。

网络安全流程与安全流程非常相似。因此，我们不会详细阐述开发和验证活动，而是重点关注其特殊性。

在网络安全领域讨论验证时，和其他领域一样，主要是基于对需求的验证。然而，在网络安全中，漏洞可能会在渗透测试（penetration test，简称 pentests）中被发现。这是网络安全特有的环节，会模拟网络攻击，目的是评估系统的优缺点，以及网络攻击的风险和后果。通过了解渗透测试的结果，我们可以采取措施来提高系统的安全性。

在汽车行业，渗透测试可以在特定的 ECU 上进行，也可以针对与特定功能相关的一组 ECU，甚至可以在整辆汽车上开展。渗透测试能够帮助我们了解漏洞及其可能带来的后果，一系列渗透测试之后可能会产生新的需求。

渗透测试的主要目标包括确认密钥无法被访问、无法下载未经授权的软件、无法启动恶意软件，以及无法访问调试功能等。

在渗透测试过程中，有一种特殊的技术叫做模糊测试（Fuzzing testing），它会将随机数据作为输入提供给系统。嵌入式软件必须足够健壮，以避免崩溃或出现内存泄漏的情况。在通信方面，也会自动发送随机消息作为系统的输入，系统在接收这些输入时，不能出现可被利用的安全漏洞。

汽车行业的网络安全标准即将出台，其方法与安全标准以及 ISO 26262 类似。和安全一样，网络安全也必须在开发初期就加以考虑。

保护 ECU 免受恶意软件攻击的方法有很多，但并非每个 ECU 都需要采用所有方法，这取决于网络安全分析和风险分析的结果。这些保护措施实施起来可能比较复杂，当然也会产生成本。

为了保障安全，必须将网络安全纳入考量。仅应用安全方法是不够的，因为这些方法只能预防故障，无法防范黑客入侵。