SASEInsight | 业内吃瓜：报废汽车竟然异地复活了？！

今天，SASEInsight为大家带来“业内吃瓜”系列专栏，由磐时网络安全专家常城老师创作主持，旨在以轻松有趣的方式解读汽车网络安全行业的热点事件。本专栏巧妙结合真实案例与技术标准，深入剖析行业动态，为网络安全从业者提供扎实的理论参考与实用的操作建议。

本期嘉宾

常城

磐时网络安全专家

5年汽车网络安全攻防经验，技术栈全面；涂鸦硬件安全一号位，蚂蚁移动安全专家，极氪车联网安全架构师，精通泛终端安全攻防。

辅导过多家汽车零部件的1S021434体系建设和流程认证，主导过多家汽车零部件的网络安全测试。

前阵子看到一则行业动态，当时选择了低调吃瓜、静观其变。如今几个月过去，是时候搬个小板凳，和大家聊聊我的看法了。

新闻截图如下：

大家的关注点都在停车场看守不严，拆车件流通混乱等管理问题，但在网络安全从业人员看来，这里暴露了OEM厂商的一个非常严重的安全漏洞：

整车身份依赖单一电子模块，缺少整车构型一致性校验。

智能汽车不应该只信任某一个单独的电子部件（比如 T‑Box、车机或者钥匙），而应该把“整车 + 关键 ECU 列表 + VIN”视为一个整体的数字身份。

在每次上电后都需要对车内关键ECU列表，对应版本，VIN进行绑定关系一致性检查，发现与出厂/授权记录不符时进入“受限模式”。在受限模式下，车辆保留基本行驶安全，但关闭远程控制、数字钥匙、敏感诊断等功能，并向云端报告异常。

问题定位

WENG TI DING WEI

好了，那么让我们回到21434流程体系中，这里是体系流程中的哪个步骤出问题了呢？

01

概念阶段（第 9 章）

- 9.3 Item definition

这里应该把“关键部件被拆装到其他车辆”的场景纳入 item definition中，但实际上多半只描述了“正常用车、维修”等，没把“拆车件迁移”视为业务／安全相关场景。

- 9.4 Cybersecurity goals

从 TARA 导出的目标里，理应出现类似“关键电子部件从原车拆卸并安装到其他车辆后，不得自动继承原车的网络身份和控制权限”的高层目标，但现在看来这一类目标缺失。

- 9.5 Cybersecurity concept

应该在网络安全概念中明确“整车级身份与构型验证”的控制思路（而不是只保护单 ECU），比如：上电时对关键 ECU–VIN–构型做一致性校验，异常则限制远程能力。这一块也没有被展开。

02

产品开发阶段（第 10 章）

在这里应把“整车身份与构型验证”细化成系统级安全需求和架构方案：

- 关键 ECU 与 VIN/整车配置的绑定

- 网关/域控执行构型一致性检查

- 远程控制、数字钥匙等权限依赖于构型校验结果

但现在来看应该是没有细化。

03

安全验证阶段（第 11 章）

在验证计划和用例中，本应包含“关键部件被拆装、迁移到另一车壳”“构型不一致”等负面场景，验证车辆会不会自动降级/停用远控，而现在这一类场景没有被覆盖。

04

生产阶段（第 12 章）

生产阶段应完成关键 ECU 的唯一身份、密钥灌装以及与 VIN/整车配置的初始绑定。

同时定义“授权更换件”的流程：售后更换新 ECU 装车后必须通过 OEM 工具完成合法绑定，否则在车上只能以“未认证件”身份运行。

05

运行和维护阶段（第 13 章）

一旦发生“事故车在别的地方复活、原车主还能远程控制”等事件，OEM 应按第 13 章的流程去分类、调查、处置和经验回溯：

比如冻结相关 VIN 的远程控制、调查关键部件流向、分析是否为系统性缺陷并更新 TARA/需求等。

但从新闻后续来看应该没啥处理。

06

网络安全服务结束与停用阶段

（第14章）

应负责定义车辆退役、回收、拆解时，如何撤销部件的数字身份和远程服务能力，防止拆车件继续在其他车上“带着证书跑”。

当前明显缺的是：没有“关键部件停用/再利用”的安全策略，导致一旦部件流出 OEM 体系，后续行为完全不可控。

问题解决

WENG TI JIE JUE

好了，那么让我们再次回到21434流程体系中，我们应该怎么修复这个问题？

01

概念阶段

Item的边界增加整车构型管理机制以及与云端后台之间的认证和会话控制。

02

TARA阶段

增加如下损害场景：

损害场景 1：原车主对非权属车辆实施远程控制

关键电子部件拆装到另一辆车后仍与原车主账号绑定，原车主可以远程解锁、开窗或启动车辆，对新车主的人身安全、财产安全构成直接威胁。

损害场景 2：新车主隐私和行驶数据泄露

新车主正常使用车辆时，行程信息、位置轨迹、车机账户数据等仍被归属到原车主或其云端账号，造成严重隐私泄露和数据合规风险。

损害场景 2：新车主隐私和行驶数据泄露

新车主正常使用车辆时，行程信息、位置轨迹、车机账户数据等仍被归属到原车主或其云端账号，造成严重隐私泄露和数据合规风险。

损害场景 3：不合规车辆绕过监管继续上路

事故或报废车辆的关键部件用于拼装车，新构成的车辆由于继承了合法的车联网身份和远程服务能力，在技术上被视为“正常车辆”，从而绕过检验和合规管控，增加交通安全和责任认定难度。

增加如下威胁场景：

威胁场景 1：黑市拆车件被用于拼装车

攻击者（拆解厂、维修厂或黑市从业者）从事故／报废车辆上拆下 T‑Box、车机、网关等关键部件，并安装到另一辆车壳上。由于系统仅依赖部件内部的证书或密钥进行认证，新车在车联网平台上被识别为原车辆，从而继承原车的数字身份和远程功能。

威胁场景 2：利用整车构型缺乏校验逃避身份绑定

攻击者通过非授权手段替换或复制关键部件，不经过 OEM 规定的绑定或重新激活流程。由于车端缺乏对 ECU–VIN–整车构型一致性的检查，只要单个部件通过云端认证，就会被视为合法构型并开放远程服务。

威胁场景 3：利用账号体系与部件绑定缺陷

原车主或获得其账号的第三方，在车辆实物已被处置或拆解的情况下，仍保留对该 VIN 的账号控制权。当关键部件在另一辆车上继续使用时，系统仍将其绑定到原账号，攻击者可持续使用远程控制能力，同时获取新车主的位置信息和使用数据。

网络安全目标：

损害场景 1：原车主对非权属车辆实施远程控制

关键电子部件拆装到另一辆车后仍与原车主账号绑定，原车主可以远程解锁、开窗或启动车辆，对新车主的人身安全、财产安全构成直接威胁。

损害场景 2：新车主隐私和行驶数据泄露

新车主正常使用车辆时，行程信息、位置轨迹、车机账户数据等仍被归属到原车主或其云端账号，造成严重隐私泄露和数据合规风险。

损害场景 3：不合规车辆绕过监管继续上路

事故或报废车辆的关键部件用于拼装车，新构成的车辆由于继承了合法的车联网身份和远程服务能力，在技术上被视为“正常车辆”，从而绕过检验和合规管控，增加交通安全和责任认定难度。

网络安全目标：

目标1：防止关键电子部件在被拆解并安装到其他车辆后自动继承原车辆的车联网身份和远程控制权限。

目标2：确保车辆远程控制能力仅授予当前合法权属车辆及其授权用户，防止原车主或非授权第三方对非权属车辆实施远程操作。

目标3：保护新车主的隐私和数据安全，防止因关键部件迁移导致位置信息、行驶数据等持续暴露给原车主或其他非授权主体。

目标4：通过技术手段降低事故车／报废车关键部件被用于拼装车的风险，使拼装车辆难以以“合法车联网身份”继续运行。

网络安全概念：

为实现上述网络安全目标，需要在整车层面建立“基于关键部件身份与整车构型的一致性验证机制”，而非仅依赖单一电子部件的证书或密钥作为信任依据。网络安全概念包括以下核心思想：

概念1：关键电子部件的唯一身份必须与特定车辆的 VIN 和整车配置数据绑定，单独的部件身份不足以获得完整车联网功能。

概念2：车辆在上电、运行以及完成关键维修或部件更换后，应对关键 ECU 列表、其身份信息及与 VIN 的绑定关系执行整车构型一致性检查，仅在检查通过时才启用远程控制、数字钥匙等高风险功能。

概念3：对于检测到的异常构型（例如关键部件身份与当前 VIN 不匹配、构型与生产记录不符等），车辆应自动进入受限模式：保留必要行驶和安全功能，关闭或降级远程服务、敏感诊断和数据上传能力，并向后台报告。

概念4：关键部件在车辆退役、报废或确认为不可继续安全使用时，应通过撤销密钥、吊销证书或标记为“仅可在原 VIN 使用”等方式，防止其在其他车辆上被重新激活获得完整权限。

03

产品开发阶段

基于上述目标与概念，在产品开发阶段需要将上述思想细化为可实现、可验证的安全需求和架构设计。

安全需求：

需求1：关键 ECU 唯一身份与 VIN 绑定

在生产阶段为 T‑Box、车机、网关、BCM 等关键 ECU 配置唯一身份（安全芯片/HSM 内的密钥或证书），并将该身份与特定 VIN 及整车配置进行加密绑定。

需求2：整车构型一致性检查

车辆上电后，必须由网关/域控对关键 ECU 列表、身份信息及 VIN 绑定关系进行一致性校验，校验结果作为是否启用远程控制、数字钥匙、远程诊断等能力的前置条件。

需求3：异常构型下的功能降级策略

当检测到关键部件身份与当前 VIN 不匹配、关键部件数量/类型与出厂构型不符或存在重复使用的部件身份时，车辆应进入受限模式：

- 禁用或限制远程开锁、远程启动车辆、远程空调等高风险远控功能。

- 禁止将位置信息和细粒度行驶数据上传到绑定账号，直至异常得到处理。

- 在人机界面上提示需要进行合规维修或构型复核。

需求4：关键部件更换与重新绑定流程

定义标准化的“授权更换流程”

- 只有通过 OEM 或授权服务工具执行的更换操作，才能更新 ECU–VIN 绑定关系和整车构型数据库。

- 未通过授权流程写入绑定关系的关键部件，在车内应被识别为“未认证件”，只能以受限权限运行，不得参与车联网认证或远程控制。

架构设计：

在系统架构中指定网关/域控为“整车构型裁决点”负责

聚合关键 ECU 的身份信息与构型数据。

与本地安全数据库中记录的出厂/授权构型进行对比。

向车机、T‑Box 等模块发出“构型校验通过/失败”的状态信号。

在接口设计中明确

车机、T‑Box 的远程服务启动、数字钥匙激活、云端会话建立等操作，必须依赖于来自网关/域控的“构型校验通过”状态，而不得仅依据自身证书或密钥。

云端在收到来自车辆的连接请求时，如检测到该 ECU 身份与历史记录关联多个 VIN 或存在异常迁移，应按策略拒绝提供完整服务或触发人工复核。

04

网络安全验证阶段

在验证阶段需要针对“拆车件跨车”相关场景设计专门的测试用例，以证明上述需求得到正确实现。

验证1：关键部件迁移场景

- 测试步骤：在受控试验环境中，将一辆车辆的 T‑Box/车机迁移到另一辆车壳上，不执行任何授权绑定流程，观察新车的行为。

- 预期结果：新车无法直接获得完整车联网服务，远程控制和数字钥匙功能保持禁用或受限，系统记录并上报构型异常事件。

验证2：合法更换件场景

- 测试步骤：通过 OEM 授权工具对关键部件进行更换并执行绑定更新流程。

- 预期结果：整车构型检查通过，车辆在下一次上电后恢复完整车联网服务和远程控制能力，后台记录合法构型变更事件，用于追踪审计。

验证3：构型异常下的功能降级

- 测试步骤：模拟关键 ECU 身份与 VIN 不匹配、同一 ECU 身份在不同车辆中重复出现等异常情况。

- 预期结果：车辆进入受限模式，高风险远程功能被自动关闭或限制，车内提示用户进行合规检查，同时向后台上报异常事件，触发进一步分析与处置。

05

生产与售后阶段

在生产阶段，需要将前面定义的“关键 ECU–VIN 绑定”和“整车构型信息”固化到制造与出厂流程中，形成后续识别拆车件的基础数据。

生产1：关键 ECU 身份与密钥灌装

-在 ECU 生产或整车下线阶段，通过安全工位为 T‑Box、车机、网关、BCM 等关键部件灌装唯一身份与密钥（或数字证书），确保每个部件在技术上不可克隆。

-同时，将这些身份信息记录到 OEM 内部的安全配置数据库中，为后续 VIN 绑定和构型验证提供依据。

生产2：ECU–VIN–构型绑定

-在整车最终装配及下线检验环节，将关键部件的身份信息与整车 VIN、车型、配置清单进行绑定，并写入车端本地安全存储以及后台系统。

-形成“某 VIN 对应的关键 ECU 列表及其身份”的基线数据，用于后续整车构型一致性检查和异常检测。

生产3：授权更换件流程预置

在生产和售后支持体系中，预置用于关键部件更换的授权工具与流程：

-授权工具在更换时读取新 ECU 身份，与后台交互完成 VIN 绑定和构型数据更新。

-未通过授权工具登记的更换操作，在后台被视为异常行为，可触发警告或限制相应车辆的远程服务。

06

安全事件响应阶段

当类似“事故车拆件在他处复活、原车主仍可远程控制”的情况发生时，应按照网络安全事件响应流程进行处置和经验回写。

事件响应步骤1：事件识别与初步分类

当收到用户投诉或监控系统发现异常构型（如 ECU 身份与 VIN 不匹配、多车共享同一 ECU 身份）时，将其分类为网络安全相关事件，进入正式事件响应流程。

事件响应步骤2：遏制与临时处置

a.对涉及 VIN 和关键部件身份的相关车辆，临时冻结或限制远程控制和高风险网络服务，以防止原车主或第三方继续通过远程手段影响车辆安全。

b.视事件严重程度，可能需要与车主、维修渠道及相关部门沟通，提示潜在风险。

事件响应步骤3：根因分析与经验回写

a.分析关键部件流转路径、拆装过程和系统设计缺陷，确认是单次操作问题还是体系性缺口。

b.将分析结论回写到：

- TARA 与损害场景/威胁场景库中，补充相应场景。

- 第 9 章网络安全目标与概念，确保“整车身份与构型验证”类目标得到强化。

- 第 10 章的需求与架构设计，以及后续的生产和停用流程中，形成可执行的改进措施。

07

网络安全服务结束及停用阶段

在车辆停用、报废或 OEM 决定停止对某型号提供网络安全支持时，需要对关键部件的身份和权限进行妥善处置，以减少拆车件在其他车辆上被复用的风险。

停用1：关键部件身份撤销与限制

在车辆确定停用或报废时，通过后台将相关 VIN 及其绑定的关键 ECU 身份标记为“停用状态”：

-撤销相应证书或密钥的信任关系。

-或将其标记为“仅可在原 VIN 使用，不可再绑定新 VIN”。

-即使拆车件被物理移植到其他车辆上，也无法在逻辑上获得完整车联网服务和远程控制权限。

停用2：停用信息与构型数据归档

-将停用车辆及其关键部件的身份、状态信息归档，用于后续安全分析和异常识别。

-若在后续监控中发现“停用状态的部件身份在其他 VIN 上出现”，应直接视为高风险事件，触发事件响应流程。

吃瓜总结

CHI GUA ZONG JIE

通过上述分析可以看到，本次“事故车关键部件被拆解并用于其他车辆，仍然继承原车联网身份和远程控制权限”的问题，并不是单一实现缺陷，而是贯穿 ISO/SAE 21434 多个阶段的体系性空白。

◉第9 章未

将“关键部件跨车使用”场景纳入 item definition和网络安全目标／概念，导致“整车身份与构型验证”这一控制思想没有在概念层被确立。

◉第 10 章

产品开发阶段因缺乏上游输入，没有形成“关键 ECU–VIN 绑定、整车构型一致性检查、异常构型降级”等明确的网络安全需求和架构设计。

◉第 11 章

验证阶段测试用例未覆盖“关键部件拆装到另一辆车”的负面场景，导致问题在量产前没有被发现。

◉第 12 章

生产及售后流程中，关键部件身份灌装和 VIN 绑定没有与授权更换流程紧密结合，使得 OEM 难以有效管理部件在生命周期内的真实流转。

◉第 13 章和第 14 章

安全事件响应和停用阶段尚未建立针对停用车辆和拆车件的身份撤销与异常监测机制，拆出的关键部件在其他车辆上重新获得完整功能缺乏技术阻断。

因此，问题解决的重点，不是单点“修一个接口”，而是沿着9->10->11->12/13/14这一链路，补齐从场景识别、目标和概念、需求与架构、验证测试，到生产、事件响应和停用控制的一整套闭环，使关键部件即便在物理上离开原车，也无法在其他车辆上自动继承原有的数字身份与远程控制权限。

这个瓜你吃明白了吗？

作者名片|ZUO ZHE MING PIAN

作者：常城