基于安全抽象模型（SAM）的汽车网络安全防御与攻击分析

自动驾驶汽车比以往任何一种个人出行交通工具都具有更大的受攻击可能性。这主要是因为这类汽车对通信有极高的需求，一方面是出于功能和安全方面的考虑，另一方面则是为了满足舒适性需求。无人驾驶汽车需要与周围环境进行通信的接口、直接连接（如车对万物，Vehicle-to-X）以及与原始设备制造商（OEM）后端服务或云端的连接。这些通信连接都有可能成为攻击者的后门。目前，大多数应对网络攻击的防御措施，例如采用消息加密技术，都只针对特定的攻击，而没有考虑到现代汽车所提供的各种接入方式的复杂性。这主要是由于在解决安全问题时采用了以解决方案为导向的方法。基于模型的技术 —— 安全抽象模型（SAM），通过明确记录攻击情况并采用适当的安全防御措施对其进行管理，为（汽车）软件架构开发的早期阶段提供了助力。此外，它还为全面的安全分析技术（例如现有的攻击评估方法）奠定了基础。因此，SAM 有助于在早期阶段以问题为导向、不局限于特定解决方案的方式，整合关键利益相关者的知识，形成对安全问题的理解。本文详细介绍了 SAM，并通过与行业专家的访谈以及扎根理论分析，对这项安全技术进行了评估。评估结果表明，SAM 通过促进汽车系统工程师、系统架构师和安全专家之间的协作，将 “设计即安全”原则付诸实践。应用 SAM 旨在降低成本、提高整体质量并获得竞争优势。根据我们的评估结果，SAM 非常适合在工业界应用，且易于理解、内容完备。

现代汽车本身就是一个相互连接的计算机网络，其中许多电子控制单元（ECU，Electronic Control Units）不仅彼此之间进行通信，还与周围环境进行通信（车对万物通信）。近年来，汽车制造商生产的汽车都具备联网功能，并能提供云服务，例如特斯拉（Tesla）的移动应用程序、宝马（BMW）的 iDrive 系统以及奥迪（Audi）的 Connect 系统。在大多数情况下，用户实际上可以通过移动应用程序或云服务监控甚至控制汽车的部分功能。这些便捷功能旨在吸引新客户，但同时也可能成为新的攻击入口 。考虑到自动驾驶汽车出于功能、安全和舒适性的需求，会进一步增加通信接口，而非减少，因此在汽车安全领域开展集体研究就显得十分必要；毕竟，每当这些 “驾驶计算机” 成为攻击目标时，人类的生命安全就会受到威胁。

对于安全专家而言，需要注意的是，攻击者攻击汽车的方式与攻击台式计算机系统的方式有所不同，因为汽车所使用的网络、协议和架构都与台式计算机不同。此外，在汽车的系统设计中，往往包含一些陈旧的遗留机制，这些机制所采用的协议既不安全也未经过加密（例如控制器局域网，CAN），因为这些机制在最初设计时并未遵循如今的安全原则。过去，由于人们普遍存在一种偏见，认为汽车凭借其技术复杂性就足以保证安全（即通过隐匿实现安全，security by obscurity），所以安全的汽车网络架构并未得到优先考虑。加之汽车开发流程进展缓慢、缺乏标准规范指导，且由于实际中遭遇攻击的案例较少，社会层面的压力也较小，这些因素导致汽车开发流程向系统性实施 “设计即安全” 原则的转变进程十分缓慢。

正如佐佩尔特等人所指出的，目前大多数应对网络攻击的防御措施，例如采用消息加密技术对汽车级网络消息进行加密、认证或随机化处理，都仅针对特定攻击，而没有考虑到现代汽车所提供的各种接入方式的复杂性。这主要是因为在解决安全问题时采用了以解决方案为导向的方法。

基于模型的技术 —— 安全抽象模型（SAM），通过明确记录攻击情况并采用适当的安全防御措施对其进行管理，为（汽车）软件架构开发早期不局限于特定解决方案的阶段提供了支持。SAM 作为领域特定架构描述语言 EAST-ADL的附录，将攻击及其动机、漏洞、可攻击属性和其他相关属性的记录与整个系统描述相关联。因此，在汽车系统开发的早期阶段，就能将所有与系统相关的可用信息与潜在的攻击场景关联起来，从而使关键利益相关者之间的协作成为可能。这种以问题为导向的记录方式，使得汽车系统开发人员和安全专家能够在制定解决方案之前，全面了解整体的攻击情况，否则所制定的解决方案可能会目光短浅。

佐佩尔特等人提出了适用于汽车软件系统的安全抽象模型（SAM）。在本文中，我们首次对 SAM 进行了全面描述，将其与自动驾驶面临的关键安全挑战相结合，并通过基于访谈的扎根理论评估对其进行了评价。

本文主要阐述以下内容：

1. 围绕作为常见软件工程实践的 V 模型，系统探讨当前安全技术的发展现状。

2. 详细描述 SAM，包括其所有元模型实体。

3. 通过与行业专家进行扎根理论访谈，对该安全技术进行评估。

本文其余部分的结构如下：第二部分回顾了汽车软件系统安全架构方面的相关研究；第三部分综述了现代汽车面临的攻击以及汽车安全建模的发展现状；第四部分探讨了汽车领域可能出现的攻击场景和安全挑战；第五部分详细描述了安全抽象模型，包括其所有元模型实体；第六部分对 SAM 进行评估，详细介绍访谈过程，并采用扎根理论对结果进行定性分析；第七部分总结全文，并对未来的研究方向进行展望。

在撰写本文时，ISO/SAE 21434《道路车辆 — 网络安全工程》标准正处于制定阶段，该标准提议在 V 模型的基础上引入安全工作包、安全概念和安全架构。它建议在售后阶段之前提供安全支持，特别是在产品验证和量产爬坡阶段。该标准由 12 个国家组成的联盟共同负责制定。该标准的范围是定义一个框架，其中包括网络安全流程的要求，以及为利益相关者之间沟通和管理网络安全风险提供通用语言。本文的研究借鉴了 ISO/SAE 21434 标准早期的努力和设计原则，并将其整合到 EAST-ADL 中。

SAE J3061《网络物理车辆系统网络安全指南》目前也处于制定阶段，该指南旨在为网络物理车辆系统相关的网络安全制定一套高级指导原则，其中包括生命周期流程框架以及有关现有常用工具和方法的信息。

尽管目前关于这些标准的最终信息还比较有限，但我们在研究中整合了许多标准中提议的方法和原则，并展示了这些方法和原则在系统模型中的实际适用性。

PRESERVE 是一个由欧盟资助的项目，该项目旨在提高未来车对车（V2V）和车对基础设施（V2X）通信系统的安全性和隐私性，并提出了汽车安全架构的安全要求 [12]。EVITA 项目则致力于 “设计、验证和原型化一种汽车车载网络架构，在该架构中，与安全相关的组件可防止被篡改，敏感数据可防止被泄露。该项目重点关注 V2X 通信，并为电子安全应用的安全部署奠定基础”。霍尔姆（Holm）提出了适用于企业架构的网络安全建模语言（CySeMoL）。于尔延斯（Juerjens）引入了 UMLSec，该语言允许在系统规范的图表中表达与安全相关的信息。其他相关解决方案还包括国际系统工程协会（INCOSE）在系统工程与系统安全工程整合方面所做的工作、美国国家标准与技术研究院（NIST）的 SP 800-160以及 NIST 在网络物理系统方面的其他研究。

所有这些解决方案都存在一个关键的不足之处：与 SAM（参见第五部分）不同，它们都是独立存在的，并未整合到现有的系统模型中。而 SAM 则完全整合到了 EAST-ADL 中。与其他替代解决方案相比，将安全模型与系统模型紧密结合的方案，能够将安全模型无缝整合到在汽车行业广泛应用的系统模型中。这有助于提高 SAM 的整体认可度，并增加其被采用的可能性。SAM 与现有系统模型的紧密结合，使得架构方面的考量与实际安全方面的考量能够有机地结合在一起。

汽车核心开发流程是按照传统的软件工程 V 模型来组织的。V 模型的每个阶段都代表着一组连贯的流程步骤，在这些步骤中会生成一系列工件。这些阶段是按逻辑顺序组织的，而非按时间顺序。在系统分析阶段，需要获取并记录需求；在系统设计阶段，要构建一个面向功能的逻辑架构，该架构是硬件和软件开发阶段的基础，最终实现汽车系统的开发。接下来，我们将围绕作为常见软件工程实践的 V 模型，探讨当前安全技术的发展现状。为此，我们将软件工程划分为四个主要阶段，即分析阶段、设计阶段、实施阶段和软件测试阶段。此外，由于维护阶段是扩展 V 模型的一部分，我们还将探讨维护阶段的安全技术。

（一）分析阶段的安全技术

在系统分析阶段，需要获取并记录需求。目前，在该阶段应用安全技术的常规做法是从系统模型的规范说明或文本注释中提取需求。安全专家负责识别系统的威胁和漏洞，而软件工程师则负责修复漏洞并实现安全功能（例如加密功能）。系统架构师在设计系统架构（即软件和硬件拓扑结构）时，会将安全需求等因素纳入考量。

佐佩尔特等人开展的一项案例研究表明，文本注释无法以详尽且简洁的方式充分阐释安全场景。由于软件工程师无法确定文本注释的用途或对应的安全目标，攻击的技术细节和威胁的相关性会因此丢失。安全本身具有内在的复杂性，尤其是考虑到其所涉及的各种需求时。仅依靠需求是远远不够的。系统架构师和安全专家需要能够对同一个模型进行相互注释。只有这样，他们才能对系统架构做出必要的调整。更好的做法是确定一系列安全目标，并从通用的架构模型和参考架构中系统地推导出安全需求。

威胁建模和风险评估是制定安全需求的基础。卡迪尔维兰（Kadhirvelan）等人的研究表明，对于评估软件密集型汽车系统的安全性，需要新的流程、标准、方法和工具。

分析阶段的成果（主要是需求）将用于设计阶段，以推导出攻击向量，并根据推导出的需求制定解决方案。

（二）设计阶段的安全技术

在系统设计阶段，会利用分析阶段提出的（软件和硬件）需求，构建一个面向功能的逻辑架构。通过了解、分析或构建攻击者可能用来攻击系统的各种攻击向量，可以做出许多设计决策。

攻击向量是指攻击者能够未经授权访问目标系统或破坏一个或多个安全目标的路径或手段。可以通过攻击树来识别和提取攻击向量。攻击树可用于展示复杂的攻击结构。攻击树的根节点代表攻击的主要目标或动机，例如控制目标车辆的某些功能。要实现父攻击，必须完成所有子攻击。攻击树的叶节点代表原子操作或条件。从任意一个叶节点到根节点的完整路径都代表着一个特定的攻击向量。

此外，设计阶段的安全技术还会采用各种用于攻击评级和威胁分析的系统。例如，通用漏洞评分系统（CVSS）这类技术能够对关键安全措施进行早期评估。CVSS 是公认的行业标准，用于对计算机系统中的漏洞进行评级。CVSS 通过多种不同的指标（如攻击复杂度、对安全目标的影响等）综合威胁分析结果，并生成一个反映漏洞严重程度的数值评分。在设计阶段就迫使开发人员思考攻击向量和漏洞问题，并进行 CVSS 分析，有助于及早发现错误，从而从一开始就避免进行代价高昂的修正。然而，目前实际情况并非如此。当前的常规做法是，原始设备制造商（OEM）在早期阶段往往会忽略这种分析。本文提出的解决方案正是为了应对这一问题。除了并非专门针对汽车领域的 CVSS 之外，还存在其他评分系统，例如 SAHARA 方法中的 SecL 级别。

另一个重要的设计决策是现代汽车如何在不同类型的电子控制单元（ECU）之间传输关键且与安全相关的指令。即便在如今，控制器局域网（CAN 总线）仍然是最常用的广播式通信网络。CAN 总线消息在默认情况下是未加密且未经过认证的，因为在 20 世纪 80 年代 CAN 总线设计之时，汽车安全并未被视为一个重要问题。如果 CAN 总线上的某个 ECU 被远程劫持，将会构成重大的安全威胁，因为攻击者可以通过总线向车辆 ECU 网络的关键部分发送有效的（且可能是有害的）消息。现代汽车拥有大量的远程攻击面，例如无线协议、移动应用程序支持等。具体的远程技术实例包括被动防盗系统（PATS）、胎压监测系统（TPMS）、遥控无钥匙进入系统（RKE）、蓝牙（Bluetooth）、无线电数据系统（如 3G、4G、LTE、5G 等）、无线网络（Wi-Fi）以及远程信息处理系统（Telematics）。通常，信息娱乐系统具备互联网接入功能，并支持第三方应用程序。多项攻击案例表明，攻击者能够通过攻陷车辆的 ECU（或添加外部设备），并向总线上监听的设备发送恶意的 CAN 指令，从而造成严重威胁。一旦攻击者能够发送任意的 CAN 消息，就能够控制制动系统、发动机运行状态、通风口，还能对车门进行上锁或解锁等操作。因此，必须在攻击者获得 CAN 总线访问权限之前对车辆进行安全防护。一旦攻击者获得了对动力传动系统的访问权限，一切就都为时已晚。

在设计阶段，常见的防御决策会考虑网络总线隔离。通过在概念上和物理上将与安全相关的 ECU 与其余网络系统隔离开来，可以缓解许多攻击向量带来的威胁。但在实际情况中，许多 ECU 仍然保持物理连接，只是通过更高级别的协议抽象（如统一诊断服务，UDS）或虚拟化应用程序实现逻辑隔离，而这些工作会在实施阶段完成。

（三）实施阶段的安全技术

根据 V 模型，在实施阶段会部署设计阶段提出的防御措施。

在硬件方面，不同的物理总线系统和布线方式会导致实施过程有所差异。如果这些应用程序或服务中的一个或多个存在易受网络攻击的漏洞，攻击者就有可能控制车辆物理网络中的关键部分 ——CAN 总线。在汽车领域，另一种解决方案是汽车以太网（Automotive Ethernet），但预计它无法完全取代 CAN 总线。CAN 总线将继续作为一种低成本组件存在，例如用于将低成本、计算能力较弱的执行器和传感器与其对应的 ECU 或网关连接，而不再作为主要的动力传动系统通信方式。如今，本地互联网络（LIN 总线）被用于此类（低成本、低风险）连接。

在汽车中安装昂贵的硬件时，成本也是一个限制因素。由于汽车市场规模庞大，汽车制造商更愿意在程序员的薪资上投入更多资金（固定成本，适用于整个车型系列），而不愿在汽车的硬件部件上多花一分钱（可变成本，每个车辆都需承担）。这意味着，对于车辆中每个需要通信的部件而言，像可信平台模块（TPM）这样的硬件模块，作为密钥存储解决方案，在成本、重量和空间方面都不具备吸引力。

在软件方面，可以采用不同的协议变体来实施安全措施。一些网络协议，如 ISO-TP（ISO 15765-2，国际标准化组织传输协议）、UDS（统一诊断服务）和 OBD2（第二代车载诊断系统），处于更高的抽象级别，能够在一定程度上弥补 CAN 总线的一些缺陷。图 1 展示了本文讨论的部分汽车协议在 ISO/OSI（国际标准化组织 / 开放系统互连）参考模型中的分类情况。

图1、ISO/OSI参考模型中分类的选定汽车协议

尽管 CAN 协议规范明确指出 CAN 总线消息在默认情况下是未加密的，但为了确保通过这一公共通道安全可靠地分发关键的新软件，仍需要一套完善的加密和认证解决方案。在汽车领域，不仅要考虑软件更新，硬件更新也同样重要。例如，如果维修厂更换了车辆的某个制动部件，可能还需要更换相应的 ECU。在这种情况下，如何获取新的（用于消息加密的）加密密钥呢？像迪菲 - 赫尔曼密钥交换（Diffie-Hellman key exchange）这类常见的密钥分发技术实施起来难度较大，因为许多小型网络节点都是低成本、计算能力较弱的 ECU。这些 ECU 通常没有足够的内存或 CPU 处理能力来执行这些加密算法和方法。在 CAN 总线上实现消息加密之所以困难，不仅是因为网络复杂性高，密钥分发问题难以解决，还因为一旦攻击者控制了某个 ECU，就能获取存储在该设备上的密钥。对于车辆中一些对威胁模型要求更高的部分（如无钥匙进入系统），像密码强化加密（PHE）服务这类新兴技术，有望成为保护系统组件的有效方案，尤其适用于传统的挑战 - 响应技术无法满足需求的场景。例如，UDS 协议的实现中包含一种安全种子机制，该机制能够阻止攻击者获取高级别的安全访问权限。然而，加西亚（Garcia）等人的研究表明，若采用弱加密算法或协议实施不当，仍然会使攻击者有机可乘，成功实施攻击。

（四）软件测试阶段的安全技术

在软件测试阶段，会对设计阶段分析出的攻击向量所对应的防御措施的实施情况进行测试。在 V 模型中，软件测试的目的是验证软件是否按照客户提出的规范进行开发。此外，安全测试技术与传统的软件测试技术有很大差异。正如评估部分后续将展示的，在很多情况下，安全技术甚至并未纳入软件工程流程。渗透测试和漏洞评估是检测系统漏洞和安全措施有效性的常用技术。目前，原始设备制造商（OEM）正开始将这些技术整合到其现有的流程中。常见的渗透测试技术包括对总线网络流量进行逆向工程，或对 ECU 固件镜像进行反汇编，以获取密钥、机密信息或特定消息。

（五）维护阶段的安全技术

车辆在交付后仍需进行维护和测试，因此空中下载（OTA）更新十分重要，但也面临着挑战，因为目前尚未有安全的 OTA 接口。像结合了认证机制的 PHE（密码强化加密）这样巧妙的解决方案或许能够解决这一问题。此外，一个完全安全加密的系统会将维修厂和第三方服务提供商拒之门外，而这些机构需要开放的访问权限。

OTA 更新通常是通过信息娱乐单元获取和接收的，该单元可接入 4G、LTE 或 5G 宽带网络。之后，所有需要更新的 ECU 都必须通过 CAN 总线从信息娱乐单元获取新的固件或软件补丁。在 OTA 更新过程中，通过 CAN 总线传输敏感数据（尤其是新固件或安全补丁）极具风险，并且会带来重大责任问题。原始设备制造商（OEM）的更新在部署到连接 CAN 总线的一系列 ECU 之前，必须经过严格的检查和验证。网络配置错误以及对 OTA 更新和补丁缺乏认证检查，会增加遭受云端攻击和僵尸网络攻击（例如 Mirai 僵尸网络攻击）的风险。从本质上讲，从一开始就应该对云端功能和 OTA 更新持审慎态度。即使软件的分发源是 OEM，攻击仍然有可能发生。潜在的攻击者可能已经找到了通过 OEM 的基础设施（如服务器）分发恶意软件的方法，进而引发信任危机。有理由认为，在密钥分发问题得到解决之前，任何形式的部署（软件更新、云端数据）都是不可信的。即使针对异构 CAN 总线网络的密钥分发问题制定了解决方案，远程攻击向量的数量与直接攻击向量的数量相比，仍可能会大幅增加。

本节阐述了本文研究方法的动机。阐明这一动机对于凸显汽车攻击场景和攻击向量所带来的威胁与危害至关重要。第五部分将详细介绍如何利用 SAM 对这些威胁和危害进行评估。

真实性、完整性、机密性等安全目标对于确保车辆中与安全相关的软件不被篡改至关重要。以下列出了部分会对汽车软件系统造成重大威胁的攻击向量（并非全部）：

· 从远程攻击后被劫持的 ECU 中注入 CAN 帧（例如重放攻击、泛洪攻击等）

· 通过仲裁 ID 过滤并使用 cansniffer 或其他 can-utils 工具识别帧，对 CAN 帧进行逆向工程

· 向 ECU 部署恶意（可能未签名）固件

· 利用原始设备制造商（OEM）的云端和 / 或移动应用程序基础设施获取车辆的远程控制权

· 通过统一诊断服务（UDS）获取安全访问权限

· 通过车载诊断（OBD）注入控制车辆

· 远程入侵远程信息处理单元

· 利用软件定义无线电破解远程无钥匙进入系统

· 拒绝服务（DoS）攻击，例如帕拉曼卡（Palamanca）等人展示的攻击

· 向系统植入勒索软件

要理解 SAM 元模型，最简单的方法是阐明各个语言组件（在 M2 级别）在具体的 M1 模型中实际代表的信息。因此，在本节中，我们将介绍一个已公开的攻击案例，除了从概念上进行解释外，还将通过该案例具体说明各个语言构建块的应用方式。本文提出的 SAM 为这类安全分析和 “设计即安全” 提供了切实可行的解决方案。所有相关信息都需要记录在一个系统模型中，该模型需考虑汽车软件系统的攻击建模。SAM 的最新版本新增了用于对这类攻击进行评级的属性。

在本节中，我们将介绍我们的创新性研究成果：一种适用于汽车建模环境的安全抽象模型（SAM）语言规范，该规范是对 EAST-ADL 的扩展。我们将阐明安全建模与功能安全建模之间的区别，并描述 SAM 的元模型实体，从而为汽车安全建模提供一个全面的建模环境。这些实体可在类型级别（M1）用于构建安全可靠的汽车系统功能架构。SAM 作为一个开源项目提供，其中包含一组具体的安全建模实体，这些实体完全符合 EAST-ADL 和 AUTOSAR（汽车开放系统架构）规范。因此，SAM 是 EAST-ADL 附录的一个提议，旨在为 EAST-ADL 增加安全建模功能，而现有语言规范目前尚未涵盖这些功能。

（一）SAM 元模型

为了便于理解，我们将以文献中公开的一个攻击案例作为建模示例。在接下来的内容中，我们将在描述用于表示攻击细节的 SAM 实体的同时，简要介绍攻击细节。完整的 SAM 元模型如图 2 所示。之后，图 3 将展示类型级别（M1）上完整的 SAM 模型图。

图2、SAM元模式

图3、特斯拉远程控制攻击的SAM模型

我们将详细描述以下攻击案例：特斯拉远程控制攻击：通过该攻击，攻击者能够借助信息娱乐单元入侵车辆。腾讯科恩安全实验室（Tencent Keen Security Lab）的研究人员展示了如何远程控制和操控车辆、干扰自动雨刷以及关闭车道检测功能。

攻击（Attack）：表示通过攻击向量对系统实施的网络物理攻击。攻击向量是指攻击者能够未经授权访问目标系统或破坏一个或多个安全目标（SecurityGoals）的路径或手段。可以通过攻击树来识别和提取攻击向量。在攻击树中，子节点是使直接父节点成立所必须满足的条件。当根节点的条件得到满足时，攻击即完成。通常，同一层级的子节点之间通过 “或”（OR）条件连接。SAM 使用子攻击组（SubAttackGroup），从而允许在分组的子攻击之间采用 “与”（AND）条件以及其他任何项目特定的条件。

该攻击可通过远程网络连接实施。车辆用户无需主动与车辆交互，攻击即可实施。实施该攻击需要较高的权限级别，并且对机密性、完整性和可用性的影响也很大。因此，攻击者可能会对乘客和其他道路使用者造成严重伤害。由于该攻击是安全专家开展的研究性攻击，实际实施攻击的并非具有恶意意图的现实攻击者。不过，这些安全专家掌握的知识可能会被恶意攻击者利用。

攻击者（Adversary）：攻击行为可由个人或系统环境实施。无论哪种情况，攻击者都属于系统环境的衍生部分，因为他们并非主系统模型的组成部分，而是从外部与系统进行交互。不过，攻击者也可能来自系统内部，例如来自未授权的部件或设备。

环境（Environment）：该实体描述了环境功能描述的集合。许多环境因素对于攻击描述和理解攻击向量都很重要。从概念上讲，攻击者和安全专家都属于环境的一部分。“环境” 并非新引入的实体，它原本就存在于自身的包中，但由于攻击者可能会利用环境实施攻击（例如通过对抗样本进行外部或现实世界的攻击），因此需要对其进行扩展。

在现实场景中，如果具有恶意意图的攻击者实施此类攻击，其动机通常是通过使车辆坠毁来伤害车内乘员或其他道路使用者。因此，该攻击具有很高的安全相关性。

攻击动机（AttackMotivation）：用于抽象表示攻击者的动机。当起初无法获取其他信息（例如被破坏的安全目标）时，攻击动机的作用尤为突出。在这种情况下，攻击动机有助于区分攻击的严重程度，并且可以根据动机对攻击进行优先级排序。此外，判断特定攻击动机是否会引发安全风险也相对容易，例如当攻击涉及篡改安全关键系统或修改与系统可靠性相关的软件组件时。安全相关性可分为 “高”（系统失效）、“低”（失效安全）或 “无” 三个级别。研究发现，每一次攻击（或子攻击）都属于某个更广泛的攻击动机范畴。通过归纳总结，我们发现所有攻击背后主要存在四种更高层次的动机：造成伤害（Harm）、信息获取（Information Retrieval）、经济利益（Financial Gain）和产品篡改（Product Modification）。此外，还存在追求声望等抽象动机，但这些动机本质上都会在上述至少一种动机中产生相应后果，因此未将其单独列出。在攻击树中，至少存在一个攻击动机（作为攻击树的根节点）。攻击动机会与安全目标产生冲突。所有攻击都可归为以下四种更高层次动机中的一种：

· 造成伤害（Harm）：此类攻击的威胁在于主动或被动地伤害乘客和其他道路使用者，例如使车辆坠毁或对其他道路使用者造成威胁。

· 信息获取（Information Retrieval）：此类攻击的威胁在于侵犯乘客、其他道路使用者以及其他相关方（如原始设备制造商）的隐私。此外，通过逆向工程获取软件 / 固件等其他类型信息，甚至出于学术研究目的尝试入侵系统，都属于此类动机。

· 经济利益（Financial Gain）：此类攻击的威胁在于为攻击者、维修厂或保险公司谋取经济或物质利益，通常会导致车主或原始设备制造商遭受经济损失。

· 产品篡改（Product Modification）：此类攻击的威胁在于篡改产品规格，例如获取车辆更多功能或对软件进行一般性篡改（如下载 / 升级软件或调整性能）。

在特斯拉远程控制攻击中，受影响的部件是自动驾驶 ECU（APE，AutoPilot ECU）。

部件（Item）：部件实体用于确定安全信息的范围以及安全评估的对象。安全分析以部件定义为基础，安全概念也从中推导得出。

在特斯拉攻击案例中，被利用的漏洞是信息娱乐单元的 Webkit 浏览器框架，该框架中的 JSArray 函数可被用于提升权限。

漏洞（Vulnerability）：指一组部件存在的抽象缺陷，即无法满足其一项或多项需求。为了体现系统架构中的薄弱环节，漏洞用于描述这些薄弱点及其与一个或多个部件的关联。漏洞是对存在缺陷的软件、配置的具体定义，并且需要据此推导相应的需求。漏洞具有一定的影响范围。如果一次成功的攻击影响到更多的安全目标和漏洞（即引发后续攻击），那么该漏洞的影响范围就会扩大。

一旦攻击成功实施，攻击者就可能通过篡改或禁用特斯拉车辆的安全关键功能，引发功能性安全风险。

风险（Hazard）：风险元类表示系统中可能导致事故发生的状态或条件。这类风险通常是由电气 / 电子（E/E）安全相关系统的故障行为（包括这些系统之间的相互作用）引起的。

在特斯拉远程控制攻击中，被利用的漏洞扩大了攻击的影响范围，这意味着如果攻击成功实施，所有六项安全目标都将被破坏。

网络安全目标（SecurityGoal）：该实体提供了适用于任何通信或数据流的常见安全目标的枚举，这些目标包括：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）、真实性（Authenticity）、可靠性（Reliability）和可追溯性（Accountability）。

在特斯拉远程控制攻击中，被利用的车辆功能是特斯拉的自动驾驶功能（Autopilot），用于实现自动驾驶。在这种情况下，部件与车辆功能之间存在一对一的对应关系。

车辆功能（VehicleFeature）：由可靠性（Dependability）包提供，车辆功能是一种专门用于车辆级别的功能类型。部件由一组车辆功能构成。

在特斯拉远程控制攻击中，JSArray 函数是攻击者寻找的可攻击属性，即攻击的切入点。可攻击属性是描述潜在攻击面的具体特征，例如是否存在已知的安全漏洞（如 JSArray 函数漏洞）。

可攻击属性（AttackableProperty）：指攻击者为成功实施攻击而寻找或需要的部件特征或属性，例如无线通信能力、所使用的加密算法、功能等。如果这些属性被利用，攻击者就能成功实施攻击，并进而形成漏洞。

通过通用漏洞评分系统（CVSS）指标对攻击属性进行分析后，可以计算出攻击的基础评分和时间评分，并据此推导出需求：为空中下载（OTA）更新提供代码签名保护。

评分（Score）：评分实体用于对攻击进行评级。SAM 支持使用任何通用类型的评分系统。其他实体的属性会提供攻击评级所需的所有相关信息。calculationFormula 属性用于描述所使用的评分系统（如 CVSS、SecL 等）。如果该属性为空，也可以提供经验值或专家意见。第五部分第三节将更详细地介绍 SAM 中使用的评分系统。

需求（Requirement）：为了定义修复漏洞所需的需求，需求实体是从攻击中吸取经验教训后形成的结果，它代表必须（或应该）满足的能力或条件。

特斯拉远程控制攻击只有在车辆 “低速行驶或静止” 时才可能实施；否则，车辆将不允许使用 Webkit 浏览器。不过，一旦攻击者完全控制了系统，就可以在车辆的任何运行状态下通过 CAN 总线对系统进行全面控制。

运行状态（OperationalSituation）：在安全建模中，了解车辆的运行状态通常很有帮助，例如车辆是处于静止、行驶还是停车状态。运行状态是指环境中可能影响车辆的状态、条件或场景，可通过环境模型（EnvironmentModel）中的功能定义进一步细化。例如：“在高速公路上行驶”“在城市中行驶”“处于倒车档”“停车”“任意状态” 等。

SAM 并未对安全概念做出明确规定，但提议将通用准则（CC，Common Criteria）ISO/IEC 15408 保护配置文件作为一种可能的解决方案。通用准则是安全领域公认的标准，为可靠系统的开发提供指导。

网络安全概念（SecurityConcept）：指一组共同满足至少一个安全目标的安全需求。在通用准则（CC）ISO/IEC 15408 中可以找到相应安全需求的示例性结构和分类。理想情况下，安全概念的制定应以对与特定部件相关的已记录攻击的分析为依据（在这种情况下，motivatedBy 属性设置为 “documentedAttacks”）。此外，安全概念也可以根据标准要求或认证需求来制定（此时，motivatedBy 属性可设置为 “standard” 或 “certification”）。

网络安全概念动机（SecurityConceptMotivation）：该实体提供了安全需求动机的枚举，这些动机包括：“标准（standard）”、“认证（certification）” 和 “已记录攻击（documentedAttacks）”。

（二）SAM 的方法学背景

为了保护系统免受攻击和威胁，首先需要识别并对这些威胁进行分类。对攻击动机进行分类，本身就为攻击识别带来了方法学上的便利。通过系统的安全分析，可以量化实施潜在攻击所需的成本。系统工程师设计的安全层级与攻击者付出的攻击成本之间始终存在一种博弈关系。由于没有任何系统能够完全抵御所有类型的攻击，系统工程师会在不同级别的安全抽象之间进行权衡，以达到可接受的安全程度。因此，任何安全系统最终都是一种权衡的结果。

尽管 SAM 本身并不能直接在系统设计中实现安全性，但它能够促使人们（理想情况下是系统工程师和安全专家协作）思考攻击及其对系统造成的后果。虽然 SAM 的元级别（metalevel）相对抽象，但其在元级别 M1 上的应用则更为具体。需要注意的是，攻击动机与部件之间的多重性（multiplicity）为 1..到 1..，这就要求系统工程师为汽车系统的每个部件至少描述一个攻击动机。这是 SAM 安全方法在方法学上的重要支持，有助于发现威胁。如果某个部件没有相关的攻击动机，就需要更加谨慎，例如可能尚未发现针对该部件的攻击方式。在这种情况下，系统工程师可能会忽略对该部件潜在攻击动机的审视。然而，由于存在 1..* 的多重性要求，他们必须思考每个部件至少一种可能的攻击动机。因此，做出这一设计决策的目的是积极推行 SAM 安全方法的方法论。

安全风险与安全威胁之间的主要区别在于，安全威胁并非随机发生（即不受概率限制），而是始终出现在最坏情况场景中。对于安全风险，可以假设其发生具有统计概率。而网络攻击则是由智能攻击者在对其最有利且防御阻力最小的时候发起的。此外，将安全目标与安全需求混淆也可能产生误导。不过，安全威胁可能会引发安全风险，反之亦然。但正如前面所提到的，在系统设计阶段，不建议将二者等同对待。此外，文本注释也不是一种理想的做法。通常，将自然语言注释转化为模型时会存在不精确性，并且在转化过程中，安全专家想要准确表示系统模型及其安全机制的原始意图可能会丢失。通过将 SAM 嵌入到 EAST-ADL 的 “可靠性（Dependability）” 包中，并随后将其整合到 AUTOSAR 中，可以实现安全解决方案的广泛复用。这有助于最大限度地降低开发成本，并在车辆的多种应用场景中实施全面的安全解决方案。

SAM 通过提供攻击者（Adversary）建模实体，使得对社会技术系统（socio-technical systems）进行建模成为可能。安全目标需要在社会技术背景或社会技术系统中实现。社会技术系统是指由人类和相关技术组成的有组织的群体，通过特定的构建方式来实现特定目标。然而，仅仅通过在系统中添加加密技术来提高安全性是一种误区。加密技术最多只能确保机密性，并不能涵盖可用性、可靠性或可追溯性等安全目标。通过我们提出的方法，为汽车软件工程提供了安全与安全协同工程流程（设计即安全与安全）。

（三）SAM 中通用评分系统的应用

SAM 的最新主要版本为建模实体添加了许多新属性，从而能够使用通用漏洞评分系统（CVSS）等知名安全评分系统。为了使 SAM 能够与时俱进，并避免过度依赖某一种特定评分系统以保持灵活性，我们将 SAM 设计为支持任何通用评分系统。在对攻击场景进行建模时，SAM 的使用者可以选择自己偏好的评分系统。本文将以 CVSS 为例进行说明。SAM 的最新版本可通过开源方式获取。目前，架构描述已较为完善，常见评分系统能够获取必要信息并开展分析工作。受 CVSS（公认的计算机系统漏洞评级行业标准）的启发，我们为 SAM 的部分实体添加了新属性。CVSS 提出了三组不同的指标用于计算漏洞评分。下文将阐述 SAM 与这些指标之间的相互作用。需要说明的是，元实体属性的分配及其命名并非源自 CVSS，而是由本文作者自主设计。

基础指标组（Base Metric Group）：反映攻击（Attack）的固有属性。从 SAM 面向汽车领域的角度来看，该指标组体现了当攻击针对整个汽车领域时所具有的特征。可攻击属性（AttackableProperty）涉及受攻击部件的属性，这些属性不受攻击者控制，但却是利用漏洞所必需的。例如，在侧信道攻击中，多核系统内共享缓存的使用就属于此类属性。可攻击属性中的 conditionPrerequisiteComplexity 属性（取值为 “低（Low）” 或 “高（High）”）用于描述出现或创造此类条件的复杂程度。例如，在上述侧信道攻击案例中，由于如今共享缓存已较为常见，conditionPrerequisiteComplexity 属性取值为 “低”；而如果攻击要求所有核心上的所有任务都使用同一个共享缓存，那么该属性取值则为 “高”。在评估该属性时，必须排除利用漏洞所需的所有用户交互要求（这些条件记录在攻击（Attack）的 privilegesRequired 属性中）。conditionPrerequisiteComplexity 属性取值为 “低” 时，攻击的危险性高于取值为 “高” 的情况。privilegesRequired 属性用于描述攻击者成功利用漏洞所需具备的权限级别，权限要求越低，该指标反映的风险程度越高。此外，攻击（Attack）实体还新增了 accessRequired 和 userInteraction 两个属性。accessRequired 属性用于描述利用漏洞的环境条件，需要注意的是，它不应与 SAM 中描述从攻击树的攻击动机到某个叶节点路径的通用攻击向量处理相混淆。userInteraction 属性用于记录车辆用户或驾驶员是否需要以特定方式与系统交互（例如按下按钮）。不需要用户交互的攻击会提高攻击的评分。

时间指标组（Temporal Metric Group）：当获取到更多关于被利用漏洞的信息后，可利用该指标组对评分进行调整。例如，如果公开了漏洞利用代码，或者确认了漏洞报告的可信度，那么时间评分就会提高。在 SAM 中，时间指标属于漏洞（Vulnerability）实体的一部分。

环境评分指标（Environmental Score Metrics）：该指标组能够将基础指标组得出的通用 CVSS 评分调整为适用于特定（汽车）企业的评分。这些指标相当于对基础指标的调整，权重分配与具体企业的基础设施和业务风险相关。SAM 为分析 CVSS 基础指标组提供了全面的基础，这意味着 SAM 也可用于评估环境指标组。环境指标不需要在基础指标之外额外获取信息，只需将分析视角调整到具体企业的实际情况即可。也就是说，安全分析师完全可以根据 SAM 提供的现有信息开展安全评分分析工作。

这种设计使 SAM 具有更高的灵活性，无需为适应 CVSS 未来的更新而对其进行调整。用于攻击评估的所有属性均为字符串（String）类型，这使得 SAM 能够适用于通用评估技术，而不必与 CVSS 的属性描述紧密绑定。此外，在模型内部或直接通过模型无法自动计算 CVSS 评分，因为这需要在行为模型中实现，而 SAM 模型属于结构模型。不过，熟悉 CVSS 的安全分析师可以根据结构模型提供的所有信息计算出 CVSS 评分。因此，尽管在元模型的注释中仍可找到有关属性类型（如 “高”“低” 等）的相关信息，但即便存在不兼容情况，也不会对评分计算造成影响。

与直接提供属性信息和漏洞评分相比，SAM 模型的额外优势在于，它不仅可以使用 CVSS（或其他评分系统），还能够通过子攻击和后续攻击构建攻击树。SAM 也是一种对攻击向量进行分层处理的方法。从实质上讲，这超出了传统的攻击评级范畴。SAM 为软件架构师提供了使用评分系统的途径，换句话说，SAM 的优势在于能够与现有的汽车架构整合。它将架构方面的考量与针对攻击本身的纯粹安全考量（可从中推导出的攻击向量、攻击动机、攻击目标区域）以及已知的所有评分系统（能够从属性中获取所有必要信息）有机地结合在一起。

为了验证 SAM 的可行性，我们通过扎根理论访谈的方式，对来自两家不同汽车软件公司的两位行业专家（下文分别简称 E1和E2）进行了访谈，以评估我们提出的解决方案。两位访谈对象均具备汽车系统工程和 / 或嵌入式安全领域的专业背景。访谈结构如下：首先，我们就汽车安全建模以及当前在分析、设计、实施和测试阶段的流程提出了一些一般性问题。随后，本文作者对 SAM 进行了简要介绍和说明。在介绍过程中，我们展示了一个真实的攻击案例，以演示 SAM 的使用方法。我们与访谈对象共同为一个真实的应用场景创建了一个参考 SAM 模型。图 4 展示了一个功能解锁攻击（Function Unlock Attack）案例，该攻击描述了一种攻击向量，攻击者（此处为第三方维修厂）可通过篡改时间服务器（TimeServer）部件，为车辆驾驶员解锁特定的车辆功能。访谈后续的问题均围绕该建模示例展开。最后，我们就适用性、可扩展性、可理解性、完整性和工具支持五个方面向行业专家提问。

图4、功能解锁攻击的SAM模型

（一）总体发现

访谈结果显示，目前汽车行业尚未形成清晰的安全工程流程，各企业仍在积极制定相关流程。业内期望这些流程能够参考 ISO 21434 和 ISO 26262 等安全标准（目前这些标准被视为汽车工程师的通用指南）。对于希望开展安全工程工作的工程师而言，SAE J3061 标准也不失为一个良好的起点。访谈结果表明，行业迫切需要一套详细的安全需求开发流程。目前，行业内的许多项目由服务提供商承担，委托企业会将安全功能整合到已完成的标准组件中。而一级供应商（Tier 1）在安全开发流程方面也没有具体的规范。

两位专家均证实，他们确实在按照 V 模型开展工作，并且拥有较为清晰的流程模型。理想情况下，他们会先获取需求规范，编写需求说明文档，设计软件架构，制定模块规范，根据规范设计测试用例，对模块进行测试，然后再进行集成测试。根据最终需要开发的产品，他们会开发相应的软件或完整的电子控制单元（ECU）。之后，按照 V 模型的流程逐步回溯，直至完成所有规范需求的测试，并且这一过程会覆盖所有需求。

对于部分需求而言，安全并非重点考量因素。即便涉及安全问题，也往往只是通过实施说明或指定使用的软件间接提及。尽管将安全概念整合到 V 模型的所有阶段可能面临挑战，但这无疑是业界所期望的。

（二）适用性

我们询问专家现有流程能否在当前工作流中应用 SAM，或者 SAM 是否有可能整合到现有流程中。我们还向专家解释了 SAM 旨在促进安全专家、软件架构师和软件工程师之间交流协作的初衷，并询问 SAM 是否达到了这一目的。此外，我们还试图了解 SAM 是否适合在行业中应用，能否解决当前行业面临的问题，以及 SAM 是否已具备支持自动驾驶汽车系统开发的条件，还有哪些方面有待完善。以下是专家回答的总结：

两位专家一致认为可以应用 SAM，因为它为攻击的可比性提供了良好的方法。目前缺失的一个流程是，在模块规范阶段，必须将每个部件都视为可能存在攻击风险的对象。主要问题在于，开发过程中通常只进行一次相关流程，而攻击却往往发生在维护阶段。不过，像 SAM 模型这样的可视化工具会对此有所帮助。将 SAM 整合到现有流程中的一个可行方案是，将 SAM 模型用作安全漏洞报告。借助 SAM，相关人员可以提前掌握各种约束条件。当前流程通常仅涵盖开发和交付阶段，团队需要建立类似 “安全响应团队” 的组织。该团队负责监控整个系统，了解已部署的软硬件组合情况以及存在的问题（如 SPECTRE 漏洞），这类问题可能会突然影响大量已投入使用的产品。安全响应团队可以利用 SAM 对这类攻击进行分类。

对于服务提供商而言，将 SAM 整合到工作流程中难度较大，但对于原始设备制造商（OEM）而言则完全可行。与根据 ISO 26262 标准考虑汽车安全完整性等级（ASIL）类似，SAM 完全可以在原始设备制造商层面实现整合。SAM 提高了透明度，有助于更好地理解攻击。经过团队培训后，SAM 无疑会对工作有所帮助，尤其是在目前缺乏替代方案的情况下，能够简化沟通。不过，如果没有额外的文本说明，人们可能无法理解构建不佳的 SAM 模型。

关于 SAM 在自动驾驶领域的适用性，专家们认为目前尚无法给出确切答案。SAM 需要先在实践中验证效果，人们也需要通过实际使用来熟悉它，之后才能确定其在自动驾驶领域的应用价值。即使未来系统在结构上可能变得更加简单，但软件开发复杂度可能会大幅增加，因为代码量会显著增多。此外，安全措施必须确保安全机制能够正常运行，并且在可用性、安全性和安全性之间取得平衡。如果车辆因轻微的安全疑虑就进入失效安全模式，那么在这种情况下，自动驾驶将无法实现。

一位专家提出，为机器学习组件添加一些建模实体可能会有所帮助，但由于机器学习组件具有 “黑箱” 特性，这一工作颇具挑战性。

（三）可理解性

我们询问行业专家 SAM 是否存在难以理解的部分。尽管专家们表示能够理解 SAM 的全部内容，但他们认为通过示例进行介绍将有助于初学者入门，因为 SAM 更侧重于实用性，形式化程度相对较低。

（四）可扩展性

在这一评估维度中，我们探讨了 SAM 最适合何种复杂度或规模的软件项目，以及开发人员在实际应用中应如何合理使用 SAM。

行业专家在这一问题上存在分歧。虽然针对更复杂的场景可以轻松创建多个 SAM 模型，但一位专家认为，对于大型项目而言，SAM 的可扩展性可能不佳。例如，对于整辆车而言，可能无法通过 SAM 全面了解其整体安全状况。要实现 SAM 的可扩展性，就需要将多个 SAM 模型关联起来。然而，由于所有内容都与某个部件相关，且车辆系统极为复杂，整体模型可能会变得混乱难懂。不过，他也表示，SAM 对于小型项目而言是一种合适的方法。

另一位专家则认为，汽车工程师必须为安全工程工作分配足够的时间。SAM 对此会有所帮助，因为如果所有人都使用统一的 “语言”（即 SAM），最终将节省时间。同时，还需要为安全技术提供支持。负责掌握当前市场上产品、软件和硬件情况的中央部门，可以利用 SAM 来开展相关工作。

相反，部分开发人员可能不愿意使用 SAM，因为它的抽象级别相对较高。不过，幸运的是，SAM 与统一建模语言（UML）有较高的相似性，开发人员可以较快地熟悉并掌握 SAM 的使用方法。通过需求的可追溯性来推动开发人员采用 SAM，将是一个有效的策略。因为开发人员严格按照需求和 V 模型开展工作，通过 SAM 可以验证需求的有效性。

（五）完整性

为确保 SAM 的完整性，我们询问专家 SAM 的说明和属性是否完备，是否存在可以删减的内容，以及如何为 SAM 添加测试功能，可能的解决方案是什么。

在与专家的讨论中，我们发现目前部分实体存在信息冗余的情况。不过，本文所呈现的 SAM 版本已包含最新的修改，其中也融入了访谈后根据反馈进行的优化调整。此外，一位专家认为评分（Score）实体可能存在冗余，因为所有相关信息已包含在其他实体的属性中，并且可以通过这些属性计算得出评分结果。从理论上讲，评分实体属于冗余信息。如果当前有合适的建模工具，评分可以在后台自动计算并实时显示，无需将其作为一个独立实体存在。但目前，评分仍然以单独实体的形式呈现。

总体反馈表明，若 SAM 的使用者具备一定的安全知识背景，就能理解 SAM 中的所有术语和说明。SAM 在揭示系统薄弱环节方面表现出色。基于 SAM 模型，可以推导出测试用例并进一步细化，对防御措施进行测试，以达到特定的 CVSS 评分标准。同时，还可以根据评分调整测试策略，例如确认某种攻击已不再可行，并在必要时推导出新的测试用例。然而，SAM 实际上只是向工程师指出了问题所在，即攻击场景。后续的应对措施主要包括两个方面：修复漏洞和测试漏洞修复效果。发现漏洞后，必须对架构进行相应修改。可复用性是一个重要因素。相关人员需要对修改进行测试，并确保未来的模型或产品不再出现类似漏洞。此外，还需考虑是否可以将测试抽象化，以便在未来的测试中重复使用。不过，要实现测试的自动化生成，还需要更多详细信息。尽管如此，测试人员仍可以通过查看 SAM 模型，自行编写相应的测试用例。

（六）工具支持

目前，尚未实现从 SAM/EAST-ADL 到 AUTOSAR 的无缝工具支持。我们询问专家是否需要此类工具支持，自动生成 SAM 模型（例如从测试或代码中生成）是否有用，以及是否有其他建议或反馈。

一位专家不确定 SAM 是否必须与 AUTOSAR 直接适配。SAM 在攻击建模方面具有实用价值，而 AUTOSAR 则用于软件建模。不过，支持 SAM 模型创建或自动计算评分的工具将有助于提高 SAM 的可用性，是非常有益的。如果 SAM 使用便捷且有合适的工具支持，开发人员肯定会愿意使用它。

另一位专家则持不同意见，他认为目前自动生成 SAM 模型并非必要。同时，他表示行业目前尚不确定是否会继续依赖 AUTOSAR。不过，目前 SAM 可以独立使用。根据他在 AUTOSAR 方面的经验，不建议过度依赖 AUTOSAR 进行扩展开发。可以在建模完成后，通过后处理自动生成或更新 SAM 模型，就像目前可以自动生成代码、头文件、模板等一样。目前，SAM 保持现有状态（即不支持自动生成），有助于促使相关人员从一开始就主动思考安全问题。

专家们还提出了一些一般性建议，例如编写 “入门指南” 或 “使用教程” 文档，这将有助于 SAM 在实际应用中的推广和接受。最后，专家建议 SAM 应更多地在原始设备制造商（OEM）层面使用，因为车辆是结构复杂的产品，目前只有产品所有者能够全面了解车辆的各个组件。借助 SAM，相关人员可以充分记录安全方面的思考、研究成果以及评估过程。

（七）总体结果

我们的行业评估表明，SAM 作为一种解决方案是切实可行的，并且将其所采用的方法整合到行业流程中也是可行的。此外，受访行业专家认为 SAM 易于理解。尽管 SAM 在大型软件项目中的可扩展性可能存在不足，但它为小型项目提供了一个可行的起点和实施流程。评估结果还显示，SAM 内容完备，为威胁建模和攻击评级提供了足够的工具、方法和说明。关于工具支持的评估结果存在分歧，因此有必要进一步研究实用的工具支持方案。

表二总结了评估结果，表一中对符号含义进行了解释。

表一：评估结果表符号说明

表二：评估结果总结

本文详细描述了安全抽象模型（SAM），包括其所有元模型实体。有证据表明，本文提出的方法是可行的。我们通过与行业专家的访谈以及扎根理论分析，对该安全技术进行了评估。评估结果显示，SAM 通过促进汽车系统工程师和安全专家之间的协作，将 “设计即安全” 原则付诸实践。未来的工作将侧重于自下而上的方法，即在应用层改进嵌入式安全和网络安全，以及设计加密协议（例如利用密码强化加密，PHE）。下一步需要开发切实可行的汽车软件解决方案，并将其纳入安全概念中。我们的研究重点尤其放在了适用于自动驾驶汽车共享场景的 PHE 认证机制以及指纹识别系统上。本文的研究旨在为汽车行业的 “设计即安全” 提供支持，而 SAM 则为该领域开展进一步相关研究提供了必要的见解和基础。