服务商和OEM解耦的汽车网络安全密钥管理方案

摘要

汽车行业正经历 “软件即服务” 转型，通过云技术和车与万物通信（V2X），实现软件定义功能与售后更新。汽车的联网功能带来了重大安全挑战，远程攻击车辆的事件日益频发。当前汽车设计需要能覆盖车辆全生命周期的安全解决方案。本文提出将 DNSSEC（域名系统安全扩展）、DANE（基于 DNS 的命名实体认证）和 DANCE（面向所有网络客户端的 DANE 认证）与汽车中间件整合，实现车载服务的认证与授权。该方法借助 DNSSEC 将服务的加密认证与服务部署的加密认证解耦，大幅简化密钥管理。文中提出，车载服务认证所使用的证书仅由服务供应商生成，但在部署时通过完全由原始设备制造商（OEM）签名的 DNSSEC TLSA 记录发布。依托成熟的互联网标准，可确保该方案与当前及未来各类协议的互操作性，并在成熟安全级别下实现数百万联网车辆凭证的可扩展管理。通过使用 STRIDE 威胁模型进行安全分析，以及在真实车载环境中开展评估验证方案有效性，为所提设计方案提供了支撑。

1、引言

车辆是由软件定义功能和硬件控制功能构成的分布式系统。软件创新显著提升了车辆性能、安全性和舒适性，并且在现代汽车价值中占据重要地位。联网车辆进一步拓展了创新空间，支持高级驾驶辅助系统（ADAS）通过车与万物（V2X）通信持续获取基础设施服务和环境数据。总体而言，联网功能催生了新的软件生命周期，其特点是动态更新和功能升级，这不仅提升了汽车行业的灵活性，还拓展了业务模式。

众多供应商参与车载软件研发，这些软件采用松耦合的面向服务架构（SOA）进行组织。车载服务可根据客户选择的配置以及可用的网络和计算资源进行动态编排。然而，这种期望的灵活性与全球互联网暴露相结合，极大地扩大了汽车系统的攻击面。第三方远程操控的风险已在实际网络攻击事件中显现。

车辆属于长生命周期产品，需要耐用的安全解决方案，且该方案需在车辆整个生命周期内可管理、可维护 —— 当前汽车安全标准（如 ISO/SAE 21434）也体现了这一要求。但许多汽车通信协议最初是为封闭系统设计的，完全缺乏安全功能。其中包括 IP 上的可扩展面向服务中间件（SOME/IP），它是汽车开放系统架构（AUTOSAR）当前选用的发布 - 订阅通信协议，已被证明易受多种攻击。以往针对该协议的安全强化尝试，多聚焦于为消息加密、认证或授权设计定制化的紧密集成解决方案。这些方案重新设计加密协议，并依赖所有通信方预共享的证书。

车载服务的复杂性和动态性对安全方案提出两点要求：（1）具备可扩展且稳健的密钥管理；（2）能实现服务与客户端的安全认证和授权。在汽车生态系统中，原始设备制造商（OEM）对汽车的整体安全生命周期（包括其服务）负责。为此，OEM 必须与各类相关方协同，包括提供关键组件的一级供应商、交付专业服务的软件供应商以及提供附加功能的售后开发商。该生态系统的异构性给密钥配置和稳健的凭证管理带来了极大挑战。

本文通过利用成熟的域名系统安全扩展（DNSSEC）生态系统来应对这些挑战，具体如图 1 所示。该方法将更新供应商的软件和密钥与 OEM 的签名凭证解耦。软件供应商对其产品进行签名并提供相应证书，而 OEM 则使用自身独立的凭证，在 DNSSEC TLSA 记录中对证书的部署进行签名。车载缓存的 DNSSEC 委托区域支持安全凭证的离线验证，能应对无互联网接入的中期场景。

图 1、基于 DNSSEC 生态系统的汽车服务分布式安全凭证管理

基于这种 DNSSEC 凭证管理机制，我们为汽车服务架构构建了一个安全层。通过 DNS 中新增的 SVCB（服务绑定）服务端点记录，将基于名称的服务发现和调用整合到汽车软件中。DNSSEC 为其所有记录提供数据完整性和真实性验证。如此一来，DNS 便成为一个可扩展的分布式数据库，在解析器基础设施中存储服务端点安全相关数据，该基础设施包含记录远程更新和密钥轮换的协议与流程。互联网中存在完善的 DNSSEC 部署和维护工具及指南生态系统，可将其应用于汽车领域。具体而言，本文的主要贡献如下：

1. 明确汽车安全需求，并阐述 DNSSEC 生态系统如何满足这些需求（第 3 章）；

2. 提出基于 DNSSEC 的汽车系统中发布者与订阅者的认证和授权机制（第 4 章）；

3. 设计支持安全凭证离线验证和安全密钥生命周期管理的部署场景，以满足汽车系统的实际需求（第 5 章）；

4. 将所提方法与 SOME/IP 整合（第 5.3 节），并对其安全性（第 6 章）和性能（第 7 章）进行评估，以验证其实践有效性。

2、背景与相关工作

汽车行业正积极拥抱 “软件即服务”（SaaS）转型，以提升灵活性、可升级性和定制化水平。面向服务架构（SOA）支持根据客户配置和可用资源实现服务动态编排。此类动态服务的示例包括与驾驶状态相关的功能（如泊车辅助）、售后软件（如信息娱乐应用、高级驾驶辅助系统）以及硬件附加组件（如带传感器、灯光和制动装置的拖车）。因此，这一趋势使得车载网络（IVN）的复杂性不断增加，出现了更多可选功能和变体。

现代车载网络正从传统的电子 / 电气（E/E）架构向更集成化的架构转型。传统架构中，专用电子控制单元（ECUs）按动力传动系统、底盘和信息娱乐等功能域进行组织；而新架构则采用集中式高性能控制器（HPCs）和统一的通信主干网。图 2 展示了未来的区域拓扑结构，其特点是在物理区域内设置多服务计算单元。控制器局域网（CAN）等传统总线系统正逐步被高速以太网主干网取代，朝着采用标准化 IP 协议栈的扁平化拓扑结构发展。IEEE 时间敏感网络（TSN）支持在以太网上同时进行尽力而为通信和实时通信。

图 2、采用区域拓扑结构的现代车载网络（IVN）

中间件层负责服务发现、连接建立和服务质量（QoS）保障。主流中间件包括源自机器人领域的数据分发服务（DDS），以及专为汽车需求设计的 SOME/IP。两者均支持基于事件的发布 - 订阅模型，运行在成熟的传输层协议 UDP 或 TCP 之上。

本文重点研究 SOME/IP，因其在汽车领域应用广泛，且是 AUTOSAR 联盟当前选用的协议。但需强调的是，本文提出的概念具有协议无关性，可轻松适配 DDS。为验证该方法的可行性，我们在真实的车载网络场景中对其进行了评估。

2.1 安全目标、威胁与防护措施

软件定义车辆中，运行时发现的服务包含关键驾驶功能。随着车辆联网程度的提高，强大的网络安全防护变得至关重要。现代汽车的攻击面涵盖物理接口、短距离无线接口和全球可访问的远程接口，威胁可能在车载网络中扩散。日益增多的安全事件和已证实的远程漏洞利用，不仅威胁乘客安全、造成经济损失，还会侵犯隐私。

针对车载网络的攻击包括数据篡改、监控、禁用和伪造。保护车载网络需要确保资源和服务的可用性、保障数据完整性，并验证数据来源和接收方的真实性。动态服务发现需要认证和授权机制，以防止服务宣告、订阅或取消操作被伪造。

汽车服务的分层安全措施包括攻击预防、检测和缓解。预防技术包括防火墙、网络流隔离和状态感知防御；入侵检测系统可识别正在发生的攻击，例如利用机器学习检测异常；可通过认证码和加密方法确保车载网络的消息完整性；最后，安全启动和空中下载（OTA）更新可防范未授权的软件修改并修复漏洞。

本文采用 STRIDE 威胁模型（包括欺骗、篡改、否认、信息泄露、拒绝服务、权限提升）以及特定的汽车攻击场景，对所提认证与授权方案进行评估。评估重点关注能够控制电子控制单元（ECUs）和通信信道，且可实施拦截、修改、重放、阻断或注入等操作的远程攻击者。需注意的是，本文不涉及该方案与其他安全措施的交互。

2.2 服务认证与授权

服务认证通过证书验证端点身份来建立信任，证书包含公钥和源自信任锚的签名。实体通过挑战 - 响应协议确认对方真实性，确保服务持有对应的私钥。

传统车载网络依赖特定于协议的认证与授权机制，互操作性有限。例如，CAN 总线安全方案面临带宽和帧大小限制，且是为共享介质设计的。此外，电子控制单元（ECUs）的资源受限问题阻碍了稳健安全方案的实施，因为成熟且经过验证的 ECUs 会跨多代车型使用。而功能更强大的集中式平台则支持更先进的安全机制。

面向服务架构（SOA）协议需要专门的保护机制，以实现服务间访问的认证与授权。SOME/IP 缺乏内置安全功能，理论上可依赖 TLS（传输层安全）或 IPSec（IP 安全协议），但这些协议在汽车领域的应用存在限制。其中，IPSec 与应用无关，无法对服务进行认证；TLS 和 DTLS（数据报传输层安全）的认证握手过程复杂，且不支持授权，同时也无法支持组播信道 —— 而组播信道承载了 75% 的车载控制流。

相关研究已揭示 SOME/IP 存在严重漏洞，包括基于时序的拒绝服务（DoS）攻击、发现消息伪造以及未授权访问。以往研究通过消息加密、认证和访问控制来应对这些问题。Iorio 等人新增了挑战 - 响应握手机制，用于 SOME/IP 有效载荷的认证、授权和加密；Zelle 等人通过电子控制单元（ECU）认证和基于授权服务器的消息验证，为服务发现广播提供安全保障；Ma 等人采用消息认证码（MACs）防止篡改，并利用域控制器实现电子控制单元（ECUs）的双向认证；Lee 等人引入了一种票据系统，由认证服务器授予订阅权限。然而，现有方案依赖定制化握手流程，且通常使用缺乏部署经验的外部认证服务器，这限制了与其他协议的互操作性，还需要专门的安全强化措施。此外，这些方案均未专门针对服务发现和订阅过程进行认证与授权，而该过程对服务可用性和完整性至关重要。

本文设计了一种与协议无关的汽车服务认证与授权机制，基于 DNSSEC 生态系统实现互操作性、长期有效性和可扩展性。鉴于 SOME/IP 在汽车领域的广泛应用及其缺乏稳健安全机制的特点，本文通过将该机制与 SOME/IP 整合来验证其有效性。该方法将挑战 - 响应方案直接融入 SOME/IP 发现消息中，为服务宣告和订阅提供安全保障。

2.3 安全凭证管理

尽管空中下载（OTA）软件更新在汽车领域正逐渐成为标准，但安全凭证更新尚未得到足够关注。在汽车的长生命周期内，静态预部署证书存在重大风险，因为美国国家标准与技术研究院（NIST）建议认证密钥的使用时长不超过 1-2 年。目前缺乏高效、安全的密钥轮换和分发流程，难以在车辆整个生命周期内维持认证与授权功能。

以往的 SOME/IP 安全扩展方案依赖预部署证书和静态访问控制列表，无法更新或管理安全凭证。这种方法在汽车供应链中引发了问题：（1）原始设备制造商（OEM）必须在制造过程中预配置所有潜在对等方的凭证，而添加或更新服务时，由于相关服务的凭证需级联更新，导致系统缺乏灵活性；（2）该系统未为供应商提供软件或凭证更新流程，而这对于在车辆生命周期内维持安全性至关重要。

数据分发服务（DDS）未明确规定证书管理方式，依赖静态证书或公钥基础设施（PKI）。X.509 PKI通过受信任的公共认证机构（CAs）证明互联网应用证书的真实性。然而，公共 CA 模型允许任何受信任的 CA 为任何域名签发证书，可能导致认证冲突。此外，该模型未考虑汽车制造中供应商与 OEM 的关系，证书管理在不同供应商和组件间变得分散。

最近，Püllen 等人提出了一种凭证部署流程，利用中央认证服务器在电子控制单元（ECUs）间分发访问令牌。该方案依赖定制化的自上而下流程，将凭证部署到中央实体，且需要系统设计人员参与凭证管理，这可能影响系统的长期有效性、互操作性和可扩展性。此外，该流程将认证服务器提供的车载信任链与软件供应链中的信任绑定，削弱了安全模型。

Mueller 等人提出了一种基于 DNSSEC 的发布者验证认证方法，用 DNSSEC 查询替代 SOME/IP 的分布式发现机制，且无额外运行开销。但该方法未解决访问控制管理、客户端认证和车载部署细节等问题。本文填补了这些空白，为汽车服务提供了全面的认证与授权框架。由于服务发现具有多种用途（包括服务可用性、服务移动性和服务选择），因此本文并非替换服务发现机制，而是通过安全认证与授权对其进行增强。

本文致力于解决认证与授权问题，并整合证书管理，以补充现有安全措施。目标是利用成熟的 DNSSEC 机制，统一当前和未来汽车协议的凭证管理，提供具有数十年部署经验的可扩展、安全且标准化的解决方案。通过将软件和凭证生成的供应商安全与原始设备制造商（OEM）提供的车载信任链解耦，为多供应商汽车生态系统提供解决方案。

3、DNSSEC、DANE和DANCE的适用性分析

车载通信涉及特定领域功能，需要采取适当的保护措施，以保障联网汽车的安全性和安全性。其中，异构多供应商面向服务架构（SOA）高度依赖组播通信，在动态服务发现、实例化和迁移过程中，易受消息欺诈和未授权访问的威胁。在车辆中实施安全措施必须妥善应对特定领域的需求。

3.1 车载服务认证与授权需求

基于软件定义车辆的背景、安全目标、威胁及已知问题，我们提出汽车系统安全认证与授权的以下需求：

1. 服务连续性：无论是否具备远程联网能力，也无论软件或安全生命周期管理状态如何，汽车都必须始终安全运行；

2. 长期灵活的凭证管理：在多供应商生态系统中，必须具备成熟的签名、证书更新和密钥轮换流程，以管理大规模异构车队在所有车辆生命周期内的安全；

3. 可复制、可缓存的服务凭证：与服务相关的安全凭证必须自洽且可本地验证，不依赖任何（远程）认证服务。安全保障应内生于内容对象本身，而非依赖第三方；

4. 可扩展性：安全解决方案需随服务、客户端、车辆和后端系统数量的增长而扩展；

5. 互操作性与分布式支持：安全解决方案需支持分布式供应商。成熟的标准应确保各供应商间安全协议的稳健互操作性；

6. 性能：尽管服务发现本身对时间不敏感，但认证与授权过程不应引入显著延迟（应小于 200 毫秒）。

3.2 DNSSEC 生态系统

域名系统（DNS）是互联网上最大的目录服务。多年来，它已发展成为一个涵盖信息、应用和工具的丰富生态系统。各类 DNS 记录可被透明访问、缓存和委托，而 DNSSEC通过签名记录（RRSig）保障这些记录的完整性和真实性。因此，DNSSEC 在互联网规模上具备互操作性和高性能，并支持最先进的加密技术。超过 15 年的运营经验证明其密钥管理的稳健性。

基于 DNSSEC 的命名实体认证（DANE）和面向所有网络客户端的 DANE 认证（DANCE），将密钥和证书存储并签名在 TLSA 记录中。它们在 DNS 层级结构中将证书与命名服务端点绑定，建立从根区域到委托区域的信任链。这不仅避免了 WebPKI PKI中众所周知的认证冲突问题，还特别允许服务资源的证书所有者对服务资源进行独立签名，而 DNS TLSA 记录的所有者对服务部署进行独立签名。我们将利用这一特性，将第三方服务提供商的签名密钥与原始设备制造商（OEM）在汽车中进行的服务安全部署解耦。

DNSSEC、DANE 和 DANCE 的安全性已在 IETF 标准化过程中得到深入讨论，并在大量研究中进行了分析。在互联网中，其稳健性已得到多年验证。

在汽车领域，原始设备制造商（OEM）可控制车队范围的部署和后端系统，既支持完整的 DNSSEC 功能，又能确保客户端与服务器间的兼容性。通过委托区域和私有命名空间，可对不同车辆的凭证进行隔离。各供应商可生成软件更新并创建安全凭证，而 OEM 则维护 DNS 层级结构并确保命名空间完整性。车载本地解析器可缓存记录，支持安全的离线操作，这对远程和无网络连接场景至关重要，使该框架成为汽车安全的稳健、可扩展解决方案。

RFC 6394涵盖了 DANE 的用例和需求，我们认为本文为车载网络（IVN）服务发现、认证和授权设计的协议可满足这些需求。利用 DNSSEC 生态系统，能够实现安全的密钥管理，同时允许服务根据用于授权的名称层级对客户端和服务器进行认证。

下文将介绍汽车协议原语的适配方案，将挑战 - 响应方案整合到 SOME/IP 服务发现中，并在真实的汽车场景中验证其可行性。我们将展示并评估 DNS 生态系统如何在满足上述特定需求的同时，实现全面的车载服务认证与授权。

4、面向发布-订阅系统的基于DNSSEC的认证与授权

本文提出的汽车发布 - 订阅安全方案，利用 DNSSEC 生态系统实现认证与授权。图 3 概述了所涉及的模块和通信流程。DNSSEC 基础设施是一个分布式系统，支持跨区域的区域委托和复制。后端和车辆服务的记录可由原始设备制造商（OEM）控制和配置。

图 3、面向汽车发布-订阅系统的基于DNSSEC的认证与授权方案

汽车中的本地 DNSSEC 解析器缓存所需记录，这些记录可预先加载，也可在客户端请求且本地缺失时从后端查询获取。因此，在正常运行情况下，汽车可离线运行。本地解析器通过 DNSSEC 信任链验证所有记录的真实性和完整性，使得资源受限的电子控制单元（ECUs）无需自行执行验证。不过，应用程序仍可独立验证该信任链。在服务发现过程中，发布者和订阅者会向本地解析器查询所需记录。

4.1 获取有效的端点信息

订阅者可通过可选的查找（find）消息，触发组播方式的服务发现。发布者响应查找请求，或定期发布服务宣告（offer）以表明服务可用，这会促使订阅者更新其订阅。

在发现过程中或收到服务宣告后，订阅者会向本地 DNSSEC 解析器查询发布者端点信息，我们选择将这些信息存储在服务绑定（SVCB）记录中，因其具备灵活性和可扩展性。SVCB 支持多种应用层协议编号（ALPNs）（例如，表示基于 TCP 的 HTTPS），并包含相应的地址和端口信息。

服务查询可能返回多条 SVCB 记录，例如某个服务支持多种协议或存在多个实例时。订阅者会将 DNSSEC 保护的 SVCB 信息与发布者的服务宣告进行比对，确认端点有效后再发起订阅。

4.2 发布者与订阅者认证

DANE和 DANCE利用 TLSA 记录将证书与端点和客户端绑定。借鉴 QUIC 等现有传输层解决方案的思路，并遵循 TLS 1.3 的原则，我们在现有的发布 - 订阅握手中整合了挑战 - 响应机制。

发布者可在其服务宣告中嵌入认证挑战。订阅者则在订阅（subscribe）消息中，使用自身私钥对认证挑战进行签名，并将签名后的响应包含在消息中。订阅者还可在订阅消息中加入挑战，请求发布者进行认证，发布者则在订阅确认（subscribeAck）消息中响应该挑战。

为验证所提供的签名，发布者和订阅者会向本地 DNS 查询对方的 TLSA 记录，记录名称由发现消息中的信息推导得出。第 5.3 节将详细介绍 SOME/IP 的实现方案。TLSA 记录可包含完整证书或用于验证所提供签名的哈希值。DANE-EE（终端实体）选项无需额外的认证机构（CAs），仅依赖 DNSSEC 信任链。同样，一次查询可能返回多条记录，以便支持证书迁移。

为缩短响应时间，订阅者可并行查询 SVCB 和 TLSA 记录。若 SVCB 记录不安全，则忽略 TLSA 记录。若 TLSA 响应不安全（或不存在），双方可根据实施策略建立不安全连接。

4.3 基于名称的服务授权

传统授权机制通常依赖访问控制列表或复杂基础设施，这会导致级联更新和易出错的维护工作。相反，我们将现有 TLSA 记录名称复用为服务授权依据。基于名称的授权支持细粒度策略，同时管理和部署简单，无需额外基础设施或加密开销。

发布者记录名称包含服务名称 / ID、域和车辆信息，格式如 service.domain.vehicle.oem.，前缀还可包含协议信息。订阅者通过验证是否存在与该精确名称匹配且受 DNSSEC 保护的 TLSA 记录，隐式对发布者进行授权，整个过程依赖 DNSSEC 信任链。

订阅者的授权可采用相同机制。此外，我们引入层级化命名方案，支持范围化访问策略（如按域或整车范围）。订阅者名称可在证书中通过可选字段反映这些授权范围，格式如 proto-client.sub [.pub][.domain][.vehicle].oem.。发布者可根据应用需求定义可接受的范围，例如，对于关键服务，要求使用特定于服务的名称以实现更严格的授权。

4.4 会话建立与密钥交换

本文采用 Diffie-Hellman（DH）密钥交换在发布者和订阅者之间建立安全会话。订阅者在订阅消息中包含其公钥份额，发布者则在订阅确认消息中包含其公钥份额。随后，双方均可计算出对称会话密钥。

对于组播端点，会话密钥需在多方间协商，但专用的组密钥协商协议超出了本文研究范围。在本文方案中，发布者作为密钥发起方生成对称组密钥，并通过已建立的安全信道将其提供给订阅者。由于发布者是唯一知晓所有订阅者的实体，因此可通过安全信道向每个订阅者单独分发组密钥，且无额外开销。

无论是单播还是组播场景，对称密钥均可用于对发布的消息进行加密和解密，确保数据的机密性和完整性。发布者可根据需要，通过安全信道更新会话密钥。此外，可借鉴 DTLS 的思路，设计安全且快速的会话恢复机制，以减少开销并提升性能，但这不属于本文研究范围。

5、车载部署与整合

本文提出的解决方案针对车载运行和汽车行业的特定需求（尤其是原始设备制造商（OEM）和供应商的需求）进行了优化。安全与安全是核心考量，OEM 需对车辆全生命周期（包括第三方组件）负责。独立维修厂的维修和维护工作也是该框架的重要组成部分。通过 DNSSEC，我们将服务供应商的加密认证与 OEM 的加密认证解耦。具体而言，车载服务认证使用由服务供应商生成的证书，但通过仅由 OEM 签名的 DNSSEC TLSA 记录进行发布。

5.1 证书管理

有效的证书管理是本文方案的核心。OEM 负责监管整个车队，而众多供应商则提供软件更新和服务。利用 DNSSEC 基础设施存储和分发服务安全凭证具有显著优势，可简化流程并增强安全性。DNSSEC 生态系统包含完善的工具、最佳实践和深入的安全分析。

5.1.1 服务凭证更新

凭证的定期轮换对于维持安全性至关重要。美国国家标准与技术研究院（NIST）建议认证密钥的使用时长不超过 1-2 年。图 1 展示了多供应商环境下汽车服务的凭证管理流程。为确保系统安全且协调运行，DNSSEC 层级结构由 OEM 维护，OEM 掌控车载服务的部署权限。每辆车的委托区域会在 TLSA 记录中存储服务和客户端凭证（例如 adas.vehicle42.vw.），这符合 DANE 和 DANCE 的规范。每个委托区域使用特定于车辆的唯一 DNSSEC 区域签名密钥（ZSK），该密钥由 OEM 的密钥签名密钥（KSK）签名，从而构建信任链。

当需要软件或凭证更新时，更新供应商生成并签名软件二进制文件、公钥 - 私钥对以及相应证书。OEM 使用新的公钥证书更新 TLSA 记录，并添加用车辆 ZSK 签名的 RRSIG 记录。TLSA 和 RRSIG 记录被部署到 DNS 树中，车载本地解析器可对其进行验证和缓存。同一服务可共存多条 TLSA 记录，以便在旧凭证过期前平稳过渡到新凭证。通过安全的空中下载（OTA）更新流程，将软件部署到汽车中，并将私钥存储在本地（例如硬件安全模块（HSM）的安全元件中）。

该方法将更新供应商的软件签名与 OEM 的记录签名分离，确保 OEM 对 DNS 拥有完全控制权。此外，软件和凭证的处理相互独立，无需第三方参与，降低了私钥泄露风险。OEM 可提供工具，使供应商和独立维修厂能够安全地更新软件和凭证，并按需部署 DNSSEC 记录，保障维修权。

5.1.2 证书唯一性

根据安全需求和供应链关系，证书可按车辆、按服务或按车辆与服务的组合签发。然而，跨车辆复用证书存在重大风险。攻击者可能从某一辆车中提取私钥，并在多辆车上利用该私钥实施攻击。

为每辆车的每项服务使用唯一密钥对，在理论上是一种简单且安全的解决方案，但会带来可扩展性挑战。例如，假设某厂商每年生产 1000 万辆汽车，持续 10 年，每辆车包含 500 项服务，那么该系统需处理至少 5000 亿条记录。这一问题并非本文 DNSSEC 方案所特有，其他需要 OEM 维护所有车辆凭证的解决方案也面临同样挑战。

而分布式且支持委托的 DNS 在此展现出独特优势。我们为每辆车部署专用的 DNSSEC 区域，该区域仅包含所需的数千条记录，易于管理 —— 这与互联网 DNSSEC 部署形成鲜明对比。结构完善的 DNSSEC 委托层级结构可确保可扩展性，同时通过为每辆车使用唯一证书保障安全性。

5.1.3 与预部署证书的区别

本文提出的证书管理流程简化了公钥证书的部署流程，为服务部署提供了更具动态性的方案。预部署证书具有静态特性，要求所有参与方预先知晓所有公钥证书，因此服务修改时必须进行凭证级联更新，难以适应灵活的服务部署需求。当更新或新增服务时，不仅需要部署该服务自身的密钥，还需为所有可能与之交互的其他服务部署公钥证书；反之，交互服务也需更新以加入新的公钥证书。

相比之下，本文方案允许在发现新通信伙伴或部署新服务时，通过 DNSSEC 动态请求证书，无需预先知晓车载服务的完整部署情况。之后，凭证可在其生存时间（TTL）内，以与预部署证书相同的方式使用。预部署证书和动态证书可并行存在。

5.2 在线与离线运行

本文方案主要为常规在线运行设计，便于证书更新和服务部署调整。在汽车领域，联网已成为事实上的标准，例如紧急呼叫（eCall）功能就需要在线能力。此外，许多其他功能（如与后端服务、充电站和其他基础设施的交互）也离不开在线能力。通过为车载服务、OEM 后端服务以及第三方服务和客户端之间提供认证与授权，本文方案支持全面的功能整合。

5.2.1 备用离线运行模式

车辆可能在较长时间内处于离线模式，例如长途旅行或在网络覆盖有限的偏远地区。需注意的是，离线场景下的攻击面会减小，尤其是远程漏洞利用风险降低。本文系统仍支持使用本地解析器缓存并已验证的关键 DNSSEC 记录进行离线验证。但除非预先加载了必要凭证，否则无法进行软件更新或安装新组件。

为确保在典型离线周期（如数周或数月）内系统的可靠性和安全性，记录和证书的有效期必须足够长。可设计降级模式，允许通过延长使用过期证书来实现更长时间的离线运行，但需向用户提示安全级别已降低。此外，可采用基于上次已知会话密钥的会话恢复机制，将密钥更新限制在在线运行时进行。设计此类备用机制时，必须谨慎避免引入针对系统降级的新攻击向量。

5.2.2 生命周期终止考量

OEM 或第三方供应商可能会停止对老旧车型和服务版本的支持，这可能导致证书过期问题。应对措施包括使用自签名证书、构建车载信任链，或部署具有无限有效期凭证的备用证书。证书不安全的车辆不应被允许在联网环境中运行。

尽管厂商停止支持后，车辆功能可能退化且使用寿命可能缩短，这是一个值得关注的问题，但并非新问题。未来（可能具备自动驾驶功能的）联网汽车需要持续的软件和安全维护，才能确保安全可靠运行。DNSSEC 为长期安全维护提供了一种成熟且历经考验的解决方案。

5.3 与 SOME/IP 的整合示例

本文提出的安全框架基于开放标准设计，可兼容各类现有和新兴通信协议。为验证这一点，我们以 AUTOSAR SOME/IP为重点，在保持与现有 SOME/IP 实现兼容性的同时，整合基于 DNS 的认证与授权机制。

5.3.1 消息与配置选项

SOME/IP 消息遵循发布 - 订阅模型，首先通过查找 - 宣告（find-offer）机制发现服务，然后建立订阅。附录 A 概述了 SOME/IP 消息结构（参见图 A.1）。服务发现本身作为一项 SOME/IP 服务，支持单播和组播，使用已知的 UDP-IP 端点、服务 ID、方法 ID 和客户端 ID。

图 A.1、用于服务发现消息的 SOME/IP 消息结构

服务发现消息包含条目列表和选项列表（参见图 A.2）。查找（Find）、宣告（Offer）、订阅（Subscribe）或订阅确认（SubscribeAck）等条目会引用提供端点信息等内容的选项。生存时间（TTL）为零的宣告和订阅条目分别用作停止宣告（StopOffer）和停止订阅（StopSubscribe）消息。

图 A.2、包含在服务发现消息中的 SOME/IP 服务发现条目的结构

图 A.3、包含在服务发现消息中的 SOME/IP 配置选项结构

配置选项（参见图 A.3）符合标准规范，是结构化的应用特定字符串。我们实现了四个自定义选项：（1）挑战（challenge），包含 32 位随机随机数；（2）响应（response），包含已签名的随机数；（3）密钥交换（key exchange），包含 DH 交换的公钥份额和加密参数；（4）会话密钥（session key），用于分发加密的对称密钥，以支持安全组播通信。

5.3.2 协议状态机

SOME/IP 必须整合 DNS 交互、认证和授权功能。图 B 展示了经过适配的协议状态机，为简化表述，省略了初始等待阶段、重传和超时处理逻辑。我们重点关注应用程序主动请求服务的场景。

服务器启动后会定期发送宣告（Offer）消息，这一行为不受本文提出的安全机制影响。客户端侧发现流程（参见图 B.1）始于初始查找（Find）消息和 DNSSEC 查询。客户端需等待 DNS 查找和查找消息处理完成。收到宣告消息后，客户端会根据 SVCB 记录对其进行验证。无效的宣告消息会被忽略，客户端继续等待下一条宣告消息。

图 B.1、客户端侧 SOME/IP 请求服务发现的状态机

图 B.2、客户端侧支持认证与授权的 SOME/IP 订阅处理状态机

客户端侧订阅处理（参见图 B.2）始于发送订阅（Subscribe）消息，随后等待订阅确认（SubscribeAck）消息。会根据之前获取的 TLSA 记录对确认消息进行认证。确认消息有效则建立订阅，否则客户端继续等待下一条确认消息。客户端通过再次发送订阅消息，响应周期性的宣告消息。

服务器（参见图 B.3）缓存活跃的订阅。对于收到的订阅消息，首先根据客户端名称进行授权。服务器等待获取客户端 TLSA 记录，对订阅进行认证，并通过订阅确认消息进行响应。

图 B.3、服务器侧支持 DNS 交互、认证与授权的 SOME/IP 订阅处理状态机

6、安全分析

我们针对常见威胁和已知攻击，评估了基于 DNSSEC 的汽车发布 - 订阅系统认证与授权方案的安全特性。该方案依赖成熟的加密算法和协议（如 DH 密钥交换），未引入新的加密原语。因此，本文不考虑针对加密原语和算法本身的攻击，而是聚焦于协议设计的安全特性及其与汽车中间件 SOME/IP 的整合。首先，我们明确 DNSSEC 生态系统中对汽车安全至关重要的固有特性；随后，结合 STRIDE 威胁分析协议状态转换，并指出当前存在的局限性。

6.1 攻击者与威胁模型

在针对汽车网络安全威胁的分析中，我们假设攻击者具备专业知识和所需工具，这代表了最坏情况。如多项研究所揭示的，车辆存在广泛的攻击面，车辆中的任何设备都可能被攻陷。我们还假设攻击者能够绕过汽车联网网关的任何保护机制，远程访问所有车载通信信道。

本文采用适用于公钥协议的 Dolev-Yao 攻击者模型（该模型此前已应用于汽车网络分析）。在此模型中，攻击者完全控制所有通信信道，可实施拦截、修改、重放、阻断或注入消息等操作。但假设攻击者无法访问（读取 / 写入）设备内部受保护信息（如安全存储的密钥），也无法更改物理网络连接（包括攻击者自身的连接）。尽管实际应用中可能存在防火墙、入侵检测系统和安全流控制等额外安全措施，但本文评估未将其纳入考量。

由于假设加密原语、证书和签名是安全的（例如借助受保护的密钥存储），因此本文不考虑计算能力差异对加密攻击的影响。

6.2 DNSSEC 生态系统的固有特性

以下特性是 DNSSEC、DANE 和 DANCE 固有的，且在本文整合方案中保持不变。

6.2.1 TLSA 证书安全性

证书的安全性依赖于 DANE TLSA 记录，该记录将证书与受 DNSSEC 保护的名称绑定，确保完整性和真实性。通过采用 DANE-EE（终端实体）证书使用方式，可绕过第三方认证机构（CA）检查，因为 TLSA 记录直接引用证书或其公钥。这种简洁的验证方式无需额外检查，减少了潜在不一致性，只要 DNSSEC 基础设施安全，就能确保无冲突验证。

6.2.2 DNSSEC 验证器与缓存

DNSSEC 记录验证对于防止欺骗和服务中断（尤其是在证书轮换等场景下）至关重要。为实现最高级别的端点安全，应在主机系统上进行 DNSSEC 验证，这在本文场景中是可行的。在收到威胁警报时或作为常规安全监控的一部分，车载电子控制单元（ECUs）可检查并验证 TLSA 记录，以防止故障或异常行为。在正常的 DNSSEC 运行中，（车载）递归解析器会执行记录验证，这是资源受限的车载 ECUs 环境中的优选方案。

车载 DNSSEC 解析器不仅提供经过 DNSSEC 验证的数据，还会预加载并缓存车辆的相应区域记录，以支持离线运行。正确实现的解析器会遵循 DNS 生存时间（TTL）和证书有效期，避免出现过期数据滥用或拒绝服务攻击等问题。

服务依赖车载 DNSSEC 解析器确保非本地解析数据（如更新或证书轮换后的数据）的完整性。DNS 通信通过安全信道传输，以防范中间人攻击。但如果解析器本身被攻陷，仍可能验证伪造数据，因此保护 DNSSEC 解析器对于维持数据完整性至关重要。保护措施可包括防火墙等系统安全机制、安全启动，以及入侵检测系统 —— 通过主动监控解析器活动、探测 DNSSEC 验证或创建事件日志来检测潜在攻击。

6.2.3 DNSSEC 密钥管理

DNSSEC 使用加密密钥对记录进行签名，DNSKEY 的安全性取决于技术保护措施、流程控制和人员专业能力。将密钥签名密钥（KSK）与区域签名密钥（ZSK）分离可提升安全性，因为 KSK 适合且建议采用离线存储方式。稳健的 DNSSEC 基础设施需要自动化且安全的管理流程，而这类流程已广泛可用。本文假设汽车 OEM 具备专业知识和能力，能够妥善管理 DNSSEC 基础设施。

6.2.4 针对 DNSSEC 基础设施的攻击

由于密钥使用存在限制，基础设施攻击的影响被大幅降低。DNSKEY 仅对其管理的区域有效，因此某一区域的密钥泄露不会影响其他区域。在本文方案中，每辆车运行在独立区域内，可防止攻击在车辆间扩散。相比之下，公共 CA 等其他认证基础设施可为由任何服务签发证书，从而可能导致攻击扩散。尽管 DNSSEC 和公共 CA 模型都无法完全防范密钥泄露带来的隐蔽攻击，但自动化的 DNSKEY 轮换和吊销机制提供了额外安全层，可降低风险并限制攻击机会。

6.3 STRIDE 威胁分析

本文采用 STRIDE 威胁模型进行威胁分析，该模型涵盖了欺骗、篡改、否认、信息泄露、拒绝服务和权限提升等关键攻击向量。以 SOME/IP 中间件安全防护为例，阐述这些攻击在汽车面向服务架构（SOA）中的表现，以及本文提出的认证与授权机制如何保护服务发现免受此类攻击，具体总结于表 1。

表 1、所提出的基于 DNSSEC 的认证与授权方案的 STRIDE 安全分析

6.3.1 伪造发布者或订阅者身份

伪造发布者或订阅者身份是汽车服务发现中的重大问题。本文通过挑战 - 响应握手机制，为此前未经验证的 SOME/IP 宣告（Offer）、订阅（Subscribe）和订阅确认（SubscribeAck）消息提供保护。签名会根据 TLSA 记录中存储的证书进行验证，确保发布者和订阅者的真实性。DNSSEC 可防范虚假证书关联（参见第 6.2 节），确保仅对有效证书进行认证。根据 SOME/IP 和 DNS 设计，查找（Find）消息未被加密保护，所有端点均可发现所有服务。

为防止虚假服务宣告，订阅者会使用 DNS SVCB 记录验证服务端点，仅向匹配的端点发送订阅消息。订阅者对宣告消息中挑战包含的随机数进行签名，并将其随订阅消息一同发送。发布者获取 TLSA 记录后，可安全地对订阅者进行认证和授权。对于订阅确认消息，发布者会对订阅消息中的随机数进行签名并返回，使订阅者能够根据发布者 TLSA 记录对响应进行认证。停止宣告（StopOffer）和停止订阅（StopSubscribe）消息也通过相同机制进行认证。通过这种方式，可拒绝无效的发布者或订阅者，防范伪造攻击。

6.3.2 消息篡改

对发现或订阅消息的篡改会破坏真实性，而本文提出的保护机制可缓解这一问题。尽管本文重点并非此方面，但此前已有研究探讨了 SOME/IP 的防篡改保护，例如引入消息认证码（MACs）确保消息完整性。此外，安全凭证会根据受保护的 DNSSEC 记录进行验证。在对方完成认证和授权前，不会共享机密信息。通过整合的 DH 密钥交换机制，后续通信可使用推导的会话密钥进行加密，确保数据机密性和完整性。

6.3.3 行为否认

在访问服务前，发布者和订阅者的身份会经过认证和授权，使交互与应用程序直接关联。记录所有行为有助于追溯操作或变更，防范否认攻击。

6.3.4 信息泄露

服务通过名称层级确定授权访问范围，仅具有有效 TLSA 记录的名称可获得授权。尽管可推断车内服务间的关系，但此类数据不敏感，且也可通过 SOME/IP 服务发现获取。

在双方完成认证和授权前，不会通过通信信道传输任何数据。订阅过程中，发布者和订阅者之间会建立具有前向安全性的安全信道。对于组播场景，发布者通过该安全信道与有效订阅者共享会话密钥。可使用对称会话密钥对事件通知进行加密。发布者应定期更新组播会话密钥，以防止已过期订阅者访问历史会话。不过，结合汽车应用场景，订阅者在每次行驶中可能都会重新订阅。

6.3.5 拒绝服务

服务可用性也是车辆运行的安全要求，尤其是在行驶过程中。但服务发现阶段对时间不敏感，且当前汽车设计并未保证服务可用性。现有汽车系统的冗余度较低，但仅在关键服务启动且通信建立后才能运行。

已有研究指出 SOME/IP 服务发现存在拒绝服务（DoS）攻击风险，这类攻击主要通过伪造消息，利用协议中的状态转换或时序特性实施。但本文提出的认证方案可缓解伪造问题（参见第 6.3.1 节）。此外，通过合理配置 SOME/IP 协议栈也可防范此类攻击。

解析 DNSSEC 记录可能会延迟服务发现过程。但当前的 DNSSEC 解析器已高度优化，能够并行处理大量请求。不过，大量请求仍可能引发 DoS 攻击。如文献所建议的，可通过网络中的速率限制或防火墙机制，防范 DNS 查询中的源地址伪造导致的反射攻击，从而识别每个客户端 ECU。未来汽车中计划采用的时间敏感网络（TSN）协议，还可保护时间敏感流免受非时间敏感 DNS 请求的延迟影响。

攻击者可能针对 DNSSEC 解析器发起攻击，例如请求包含长 DNSSEC 链的已存在记录，导致大量加密运算。在汽车中，可通过限制解析器仅访问与车辆运行相关的预获取区域，来防范此类攻击。此外，车载解析器仅允许车内访问，外部服务无法利用其发起攻击。最后，大多数解析器都具备防御机制，可终止高负载或长时间验证的查询。

6.3.6 权限提升

认证过程中，发布者会根据订阅者的 DNS 名称决定是否授权其订阅。TLSA 证书关联被限制在特定名称、协议和端口范围内，进一步缩小了攻击面。受 DNSSEC 保护的记录可防范权限提升，因为冒充服务并使用其身份需要持有正确的私钥。通过严格的职责分离，OEM 可独立于更新供应商管理 DNSSEC 基础设施，维持 DNSSEC 信任链。

6.4 讨论与局限性

本文提出的方案利用成熟的互联网标准 DNSSEC、DANE 和 DANCE，成功解决了认证与授权问题，并实现了稳健的凭证生命周期管理。通过该方案，可保护 SOME/IP 免受常见 STRIDE 威胁。但方案仍存在一些局限性，具体讨论如下。

6.4.1 混合安全级别

本文分析聚焦于为汽车服务发现提供最高安全级别，但部分服务可能无需如此高的安全级别。允许混合安全状态可提高与现有系统的向后兼容性。车辆中可能存在不同安全级别，例如并非所有服务都需要数据加密。订阅者和发布者可根据服务需求，请求认证、授权和加密，本文方案可轻松实现这一适配。然而，对于接受混合安全级别的服务，需考虑并防范降级攻击，但这不属于本文研究范围。

6.4.2 供应链攻击

尽管凭证管理通过 DNSSEC 信任链得到保护，但本文分析未涵盖针对软件生产、凭证生成或安全空中下载（OTA）分发的特定攻击。本文方案将软件生产与凭证管理解耦。更新供应商对新凭证和二进制文件进行签名，OEM 可在部署前验证其完整性和真实性。OEM 自行对 DNSSEC 记录进行签名，因此车辆完全依赖通过 DNSSEC 信任链建立的对 OEM 的信任，无需依赖第三方信任锚。汽车领域可通过安全构建系统、凭证生成、OTA 更新和启动引导等措施保护软件供应链。这些措施需要独立的详细安全分析，超出了本文研究范围。

6.4.3 私钥泄露

尽管使用硬件安全模块（HSM）时私钥泄露风险较低，但如果攻击者通过物理方式获取电子控制单元（ECU）访问权限，并具备所需工具、知识和时间，仍可能导致私钥泄露。若发布者私钥被泄露，攻击者可利用被盗证书提供服务。本文方案将欺诈性服务宣告限制在 SVCB 记录中包含有效端点信息且存在匹配 TLSA 记录的服务范围内。同样，订阅者私钥泄露会使攻击者能够访问与泄露客户端密钥关联的 TLSA 记录所对应的服务。需强调的是，每辆车的服务区域都使用唯一密钥对，因此私钥泄露仅影响该私钥所在的特定车辆。

6.4.4 发现延迟

尽管本文方案缓解了伪造攻击和大多数拒绝服务（DoS）攻击，但仍可能出现发现延迟。在获取 DNSSEC 记录前，可能会收到冲突消息，导致订阅者收到同一发布者服务的多条宣告（Offer）或停止宣告（StopOffer）消息。一旦 DNSSEC 记录解析完成，仅会验证最新的宣告消息，这就为文献中所述的时序攻击留下了窗口期。最坏情况下，订阅者需等待下一条有效的周期性宣告消息，发现延迟最多增加一个周期。类似地，在获取客户端证书前，发布者可能收到同一客户端的多条订阅（Subscribe）消息。尽管缓存这些消息可缓解延迟问题，但可能引入新的攻击向量。最终，一旦获取 DNSSEC 记录，所有冲突请求都会得到解决，因此发现延迟的漏洞窗口较小。在车辆启动前建立安全连接，可减轻此类延迟的影响。

6.4.5 复杂性攻击

复杂性攻击利用系统状态或增加协议的加密运算量，导致系统变慢或过载。在正常模式下，DNSSEC 的所有非对称加密运算都由内部递归解析器异步执行，仅在服务会话建立初始阶段需要生成随机数、生成签名和验证签名。该阶段的复杂性攻击会延迟或中断汽车启动。车辆可通过关闭网关或加强防火墙来缓解远程攻击。若内部组件发起攻击，车辆可能需要通过 OTA 或离线服务维护进行软件重置。

状态攻击针对服务宣告、未认证订阅请求和活跃订阅所占用的内存。尽管所提供服务和活跃订阅的状态与 SOME/IP 相似，但本文方案由于新增了随机数、证书和签名，会增加内存占用。对于未认证订阅请求，基于 DNSSEC 的验证需要存储传入请求直至完成验证，与静态预部署证书相比，这会增加状态量。此类攻击需要大量恶意请求，可通过监控请求模式来缓解。

7、真实车载场景中的评估

本文将基于 DNSSEC 的认证与授权方案的性能，与原生 SOME/IP 服务发现及预部署证书方案进行对比。为此，在 Mininet 环境中复现了 Meyer 等人提出的真实车载场景，重点评估服务发现性能、加密运算和 DNSSEC 解析时间。

本文实现基于开源项目，包括 SOME/IP 参考实现 vsomeip。通过 DNS 查询库（c-ares）和加密库（Crypto++），为方案添加认证功能。所有服务均在虚拟机（Ubuntu 22.04.5 LTS，32 GB 内存，16 个 Intel®13900K 性能核）上运行，每个服务使用独立的 SOME/IP 协议栈，确保服务发现不依赖本地连接。采用 Mininet构建虚拟网络，使用 NSD 作为 DNSSEC 解析器。根据匿名评审意见，本文实现（包括配置和评估设置）将以开源形式发布。

表2、车辆 1. 原始设备制造商（vehicle1.oem）委托区内的发布者（服务 42、实例 1、主版本 2、次版本 3）和订阅者（客户端 17）记录

SOME/IP 服务发现配置采用 vsomeip 订阅示例的默认设置：初始延迟为 10-100 毫秒（用于分散请求），最多重复 3 次查找 / 宣告（find/offer）消息（延迟从 200 毫秒开始递增），周期性宣告延迟为 2 秒。

本文测量了服务发现延迟、DNSSEC 查询时间以及相关加密运算的计算开销。通过对比三种方案评估基于 DNSSEC 的认证与授权的影响：（1）原生 vsomeip：添加性能测量统计功能的参考实现；（2）预部署证书：使用静态证书实现发布者和订阅者的完整认证；（3）DNSSEC、DANE 和 DANCE：结合本地 DNS 解析的基于 DNSSEC 的认证与授权。

7.1 真实车载网络配置

本文基于真实开源车载网络（IVN）模型构建实验环境，该模型源自真实车辆并已转换为区域拓扑结构。为简化 Mininet 配置，将冗余环形主干网替换为星形拓扑（见图 2）。该网络包含 5 个交换机、4 个激光雷达系统、2 个摄像头、4 个区域控制电子控制单元（ECUs），以及 3 个分别用于高级驾驶辅助系统（ADAS）、信息娱乐和远程信息处理服务的高性能控制器（HPCs）。将所有流量源和接收方转换为 SOME/IP 发布者和订阅者，同时保留原有的通信关系和应用主机。该配置部署了 212 个发布者和 448 个订阅者，每个发布者平均对应 2.1 个订阅者（最少 1 个，最多 4 个），且仅使用组播端点。每个节点平均包含 16 个本地发布者（最少 0 个，最多 79 个）和 35 个远程订阅者（最少 0 个，最多 174 个），同时包含 35 个本地订阅者（最少 0 个，最多 131 个）和 35 个远程发布者（最少 0 个，最多 79 个）。

7.1.1 证书与密钥生成

为实现安全通信，所有发布者和订阅者均使用 OpenSSL [61] 生成的唯一证书和密钥（SHA-256 哈希算法，2048 位 RSA 密钥，加密强度约等同于椭圆曲线 prime256v1）。原生 vsomeip 场景不使用任何证书；预部署证书场景中，证书直接链接到应用配置，因此每个发布者都知晓其订阅者的证书；在 DNSSEC、DANE 和 DANCE 场景中，发布者和订阅者仅存储自身私钥，公钥证书通过 DNSSEC 解析获取。

7.1.2 DNSSEC 记录

本文为车辆 vehicle1.oem. 创建了 DNSSEC 区域，并将其划分为两个子区域：.client. 和.service.。整个车载网络共需 872 条记录，每条记录都配有相应的 RRSIG 签名记录。DNSSEC 客户端依赖解析器进行验证，但在本评估中，未验证到根区域的信任链。

.service. 区域包含 212 个发布者的 SVCB 和 TLSA 记录。SVCB 数据描述与 SOME/IP 宣告消息匹配的发布者信息，使用 RFC 9460支持的自定义键值对。更通用的名称（如 someip.42.service.）下可共存多条 SVCB 记录，这些记录指向相同的发布者数据，但支持查询任何版本和实例的所有记录，这一设计借鉴了 Mueller 等人的方案。TLSA 记录始终与完整服务信息一一对应，且采用 DANE-EE 证书关联类型，无需额外认证机构（CAs）。

.client. 区域包含 448 个订阅者的 TLSA 记录，这些记录包含订阅者的完整证书。客户端 - 服务专用 TLSA 记录是服务访问认证与授权的必要条件。由于无法从原始网络的匿名服务中合理预测通配符，因此未使用通配符。

7.2 性能评估

本文在单主机系统上初始化 660 个应用程序，构建高负载场景进行性能评估。由于启动时间、宣告周期、初始化延迟以及 16 核系统上的并发处理等随机因素影响，该场景存在显著的性能波动。仅在系统上启动所有应用程序就需要约 300 毫秒。每种场景均收集 25 次运行的指标数据（见表 3），分析最小值、平均值和最大值。此外，通过 1 个发布者和 1-50 个订阅者的简单可扩展性分析，评估订阅延迟的变化。

表 3、三种场景下车载网络（IVN）启动延迟

7.2.1 建立时间

服务建立时间指从发布者首次发送宣告（Offer）消息到所有订阅者完成确认和验证的持续时间。这是衡量系统性能的关键指标，直接影响应用程序的可用时间。

表 3 显示了三种场景下每个服务建立时间的最小值、平均值和最大值，数据显示存在显著抖动，这可能是由消息丢失、重传和并行处理导致的。该时间包含消息传递、所有加密运算、DNSSEC 查询以及消息丢失时的重传。错过宣告消息的订阅者需等待下一次宣告消息。三种场景下，网络中所有服务的总建立时间范围为 1.3-3.3 秒。但在不同运行轮次中，随机因素可能产生显著影响，例如预部署证书场景的性能可能慢于 DNSSEC 查询场景。

为进一步分析订阅建立时间，设计了包含 1 个发布者和 1-50 个订阅者的小规模实验。图 4 显示了所有同时进行的订阅的平均建立时间。三种方案均可在数毫秒内为该服务建立 50 个订阅。与原生 SOME/IP 相比，安全运算增加约 2 毫秒延迟，而 DNSSEC 解析额外增加约 1 毫秒延迟。

图 4、在一项综合研究中，不同实现方式下，1 个发布者对应 1 到 50 个订阅者时的平均订阅建立时间

7.2.2 加密运算

两种安全场景均需执行加密运算，包括随机数生成、消息签名 / 验证和哈希生成。这些运算对建立延迟有显著影响（见表 3），且两种场景的性能相近。DNSSEC 方案还需验证端点（将 SVCB 条目与宣告消息比对），该操作的影响可忽略不计，平均仅需 0.0003 毫秒。结果中仍观察到较大抖动，这可能是由于同一系统上并行执行大量加密运算导致的。平均而言，签名生成（2.6-4.2 毫秒）比签名验证（0.3-0.5 毫秒）耗时更长。尽管与 10-100 毫秒的默认初始延迟相比，加密开销较低，但运行多个服务的电子控制单元（ECUs）可能需要硬件安全模块（HSM）支持以实现高效运算。

7.2.3 DNSSEC 解析

本文提出的认证与授权方案要求每个发布者进行两次 DNSSEC 查询，每个订阅者进行一次 DNSSEC 查询。本地解析（同一机器上）的最短查询时间为 0.1 毫秒，符合预期。平均值和最大值较高，可能是由消息丢失和 c-ares 库超时导致的。并行 DNSSEC 解析的通道数量限制可能在峰值时段造成延迟，失败的解析会在下次宣告周期重试。由于发布者解析可在发送第一条宣告消息前开始，因此发布者 DNS 解析的最大时间可能超过总建立时间。

7.3 讨论与局限性

本文评估成功验证了基于 DNSSEC 的认证与授权方案在真实车载网络（IVN）中的可行性。评估结果为原始设备制造商（OEM）车队的实际部署提供了有价值的参考，每个车辆区域约需 1000 条记录。与其他方案不同，DNSSEC 区域支持记录管理和证书生命周期的安全委托，构建可扩展的基础设施，且不会产生证书关联冲突。

7.3.1 评估环境的局限性

由于所有服务在单系统上并行执行，汽车网络表现出显著的性能抖动。但可扩展性分析表明，单个服务的建立时间受订阅者数量影响较小，且远低于 200 毫秒的要求。由于服务发现对时间不敏感，因此初始服务建立的延迟是可接受的。

本评估未考虑网络传输时间，因为交换机是使用 Mininet 中的 Open vSwitch 模拟的。通过跟踪通信并测量消息间延迟等替代方法，可能获得更深入的见解。此外，将应用程序与服务发现解耦，可能减少发现实例数量，进而提升性能。

初始化阶段可能因消息泛滥导致消息丢失，此时需同时处理大量 DNSSEC 解析、查找（Find）和宣告（Offer）消息。通过优化发现消息的分散策略、DNS 解析或并行执行配置，可提升性能。这些挑战并非本文方案特有，原生 vsomeip 场景也存在类似问题。

7.3.2 DNSSEC 解析

在本地环境中，单次请求的解析时间非常短。DNSSEC 解析器针对多查询解析进行了充分优化，因此单次查询的延迟可忽略不计。但本文实现未针对大量请求的并行解析进行优化，导致出现显著抖动。在实际场景中，优化消息丢失处理和发现过程重传策略，对缩短总体建立时间至关重要。

本评估未包含远程 DNSSEC 解析，但此前研究已对其性能进行了分析。预计 DNSSEC 解析主要在更新过程中进行，而非车辆启动时，因此对性能影响较小。

7.3.3 凭证管理

评估环境显示，节点平均需通过 DNSSEC 解析 70 个远程发布者和订阅者的 TLSA 证书。随着汽车行业向 “软件即服务” 转型，可选服务增多、更新频繁以及售后安装服务增加，这一数字预计会进一步增长。

传统预部署证书方案面临诸多管理挑战。节点必须安全存储所有潜在应用（即使当前未安装）的凭证，以确保与未来更新或新增服务的兼容性。如第 5.1 节所述，这会带来巨大的管理开销。尽管减少证书数量（如每个 ECU 使用一个证书）可简化部署，但会严重限制服务移动性，并降低访问控制的粒度。

本文提出的基于 DNSSEC 的方案简化了证书管理。通过将证书安全存储在 DNSSEC 区域中，系统可按需获取所需凭证，大幅减少节点存储未使用远程服务凭证的需求。发布者和订阅者可按需获取所需证书，减少不必要的维护工作。在节点上缓存公钥证书，可使性能达到接近预部署证书系统的水平。但需谨慎管理证书有效期，防止使用过期或已吊销的凭证。该架构支持服务更新或证书过渡期间并行存在多条 SVCB 或 TLSA 记录，确保更新过程中持续的安全运行，并便于高效的证书吊销。

7.3.4 会话恢复优化

发布者和订阅者在多次车辆运行中经常重复交互，通过会话恢复可进一步优化性能。这可通过复用会话密钥或会话 ID，减少加密握手开销。节点还可缓存 DNS 响应（遵循记录的 TTL 值），进一步缩短建立延迟。

由于车载网络在连续行驶过程中保持稳定，可能每趟行程仅需执行一次完整的加密握手。例如，可在车辆充电时重新初始化所有会话。行驶过程中，通过周期性的宣告（Offer）和订阅（Subscribe）消息维护会话密钥，可在不影响安全性的前提下提高效率。

8、结论与展望

汽车服务架构缺乏稳健的安全机制。然而，随着车辆联网程度不断提高，亟需认证与授权机制，以及稳健、安全的凭证管理方案。当前提出的静态预部署证书在车辆长生命周期内存在重大风险，因为美国国家标准与技术研究院（NIST）建议每 1-2 年更换一次认证密钥。

本文提出了一种汽车生态系统的密钥管理解决方案，通过 DNSSEC TLSA 记录将服务提供商密钥与服务部署密钥解耦。该方案大幅简化了第三方服务提供商与原始设备制造商（OEM）之间的安全管理。利用 DNSSEC、DANE 和 DANCE 对汽车发布 - 订阅系统进行认证，并通过 TLSA 记录的存在实现隐式授权。同时，提出了适用于汽车应用的部署策略，包括安全凭证的离线验证和安全密钥生命周期管理。

设计了基于 DNSSEC 的 SOME/IP 中间件认证方案。安全分析表明，该方案可有效防范 SOME/IP 中已知的伪造身份、未授权访问和拒绝服务等威胁。为降低私钥泄露的影响，每辆车使用唯一密钥对，并通过自身 DNSSEC 区域进行认证。这样可确保私钥泄露仅影响特定车辆，保障其他车辆的安全。

在真实车载场景中进行的性能评估，验证了该解决方案在汽车服务认证与授权中的可行性。与预部署证书方案不同，本文方案减少了对所有交互方本地存储凭证的依赖，同时通过车载 DNSSEC 解析器支持离线运行。这是该方案相对于需要连接外部认证机构（CAs）的传统公钥基础设施（PKI）解决方案的显著优势。

这一具有前景的方案为未来研究指明了三个方向：首先，在真实车辆环境中使用专用硬件和交换机进行性能评估，可进一步揭示该方案的可扩展性和稳健性，并探索通过不同密钥和签名算法以及后量子密码学进行优化的可能性。其次，针对会话恢复的进一步研究可减少车辆启动时的开销，尤其是考虑到服务在多次行程中可能与相同节点通信。最后，尽管本文聚焦于汽车应用，但该方案可扩展到工业控制系统或智能家居等其他本地网络，展现更广泛的应用价值。