芯片功能安全实战系列（第 2 期）：车规芯片 ISO/SAE 21434 网络安全——从 TARA 到硬件信任根与 SBOM 供应链
图1 ISO/SAE 21434 车规芯片网络安全主题封面：TARA、硬件信任根、安全岛共存与 SBOM
一句话总结：本文把 ISO/SAE 21434 网络安全工程落到车规芯片上——先讲清一颗脱离上下文开发的芯片在标准里的定位与差距分析，再把 TARA 七步转成芯片层资产与威胁场景，接着给出硬件信任根（HSM/HTA）的需求映射、安全岛与安全核的共存冲突与共因分析、网络安全验证的四类手段，收尾在 CSMS 与 SBOM 供应链传递。上一期埋的三个悬念，本期逐个作答。
零 痛点开场：芯片过了 ASIL-D，客户又问一句"能不能扛住攻击"
问：你把安全手册、FMEDA、故障注入报告都备齐了，芯片拿到了 ASIL-D。客户安全工程师翻到末页问——"这颗芯片的网络安全怎么证明？密钥放哪？调试口关了吗？"你答得上来吗？
这是上一期闭环之后紧接着出现的场景。ISO 26262 回答的是"故障了会不会出事"，ISO/SAE 21434 回答的是"被人攻击了会不会出事"。两件事的失效来源不同：前者是随机硬件故障与系统性故障，后者是有意图的攻击者。安全机制再完善，也挡不住调试口没关、固件没验签、密钥明文存放。
芯片在网络安全链条里处在很特殊的位置：它是整车信任链的起点。安全启动从这里开始，密钥存在这里，固件验签在这里执行。如果芯片这层信任根没建好，上层的车载以太网防护、云端校验、OTA 签名都成了空中楼阁。
本期就按上一期结尾留下的三个悬念展开：网络安全需求怎么映射到硬件信任根？功能安全的安全岛与网络安全的安全核能不能共存？SBOM 怎么跟着一颗芯片走到主机厂？
一 概念与差距分析——21434 对一颗芯片意味着什么
问：ISO/SAE 21434 是整车标准，一颗芯片厂商为什么要管？管到什么程度算够？
ISO/SAE 21434:2021 于 2021 年 8 月发布，是道路车辆网络安全工程的标准，也是支撑 UN R155 法规的关键工程框架。它覆盖组织、项目、概念、开发、验证、生产、运维与退役的全生命周期，其中与芯片关系密切的章节可以这样对应。
芯片在标准里通常不是整车的一个 item，而是"脱离上下文的组件"（component out of context）或"现成组件"（off-the-shelf component）。这个定位决定了芯片厂商做什么、集成方做什么。
💡 关键认知：芯片厂商交出去的不只是芯片，还有一份可核验的"使用假设清单"。假设不成立，证据就作废——这是网络安全里常见的翻车点。
图2 ISO/SAE 21434 生命周期与车规芯片的活动落点
二 体系与架构——TARA 怎么落到芯片，需求怎么映射到硬件信任根
问：TARA 在整车层做得很热闹，落到一颗芯片上，资产和威胁场景长什么样？网络安全需求又怎么映射到 HSM？
TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）在标准中是一套独立方法，包含资产识别、威胁场景识别、影响评级、攻击路径分析、攻击可行性评级、风险值确定与风险处置决策等环节。整车层做 TARA 时，芯片是攻击路径上的一个节点；芯片层自己做 TARA 时，需要把视角切到芯片内部资产。
映射到硬件层面，这些需求大多由芯片内的硬件信任根承担。业界对这块硬件的叫法不统一：HSM（硬件安全模块）、HTA（硬件信任锚）、以及 HIS 组织提出、在 AUTOSAR 生态里被广泛采用的 SHE（安全硬件扩展）规范。不同厂商实现的深度不同，常见的能力分层可参照 EVITA 的Full / Medium / Light 分级思路。
💡 实战提醒：网络安全需求不要只写"使用 HSM"。要写清哪个密钥、什么算法、哪种验签策略、失败后进入什么状态，否则集成方无从验证。
图3 TARA 七步在车规芯片层的落地：资产、威胁与处置
三 过程实施——芯片侧网络安全需求怎么落地
问：需求写完了，芯片开发流程里具体要做哪些事？和上一期讲的 ISO 26262 流程怎么区分？
上一期我们讲过芯片功能安全的六步闭环：定级、架构、FMEDA/DFA、软件安全需求、故障注入、安全档案。网络安全的需求落地可以复用同样的节奏，但内容和验收方式不同：功能安全侧重"故障能不能被诊断"，网络安全侧重"攻击能不能被拦住"。两条线的活动要并行，但证据分开归档。
安全启动链是芯片侧网络安全的核心骨架。它的基本形态是：片内 ROM 中的信任根代码先验证下一级引导程序的签名，验证通过才交出执行权，逐级向上直到应用固件。每一级都要有版本计数，防止攻击者用带漏洞的旧版本固件回滚。
密钥管理则是另一个高频不符合项来源。工程上要回答清楚：密钥在哪个环节导入、由谁持有、更新流程是什么、撤销机制如何生效、量产报废时怎么销毁。只写"密钥存在 HSM 里"远远不够。
图4 硬件信任根（HSM/HTA）能力架构与信任传递
四 安全岛与安全核——能不能在同一颗芯片里共存
问：功能安全要安全岛，网络安全要安全核，两者都往芯片里塞，会不会互相干扰？
会。这正是上一期留下的第二个悬念。安全岛（Safety Island）面向功能安全，典型配置是锁步核、ECC、看门狗与安全监控器，目标是在随机硬件故障发生时进入安全状态；安全核（Security Core）面向网络安全，典型配置是信任根、验签引擎、密钥存储与访问控制，目标是抵御入侵与保护资产。
共存设计有几条实用原则。其一，共享资源要单独列项做共因分析：安全岛和安全核如果共用同一电源域、同一时钟源、同一内存总线，任何一方失效都可能把另一方一起拖垮，这在 DFA 里必须显式列出。
其二，时间预算要一起算。安全启动的验签耗时、密钥运算的延迟，都会占用启动阶段的时间窗口。如果安全状态进入或故障响应也依赖同一条路径，就必须论证在极端工况下仍能满足故障容忍时间。
其三，响应优先级要预先定义。芯片同时收到"硬件监控器报故障"和"验签失败"两个事件时先处理哪个？工程上通常按对人身安全的影响排序，但这个决策必须写进安全概念与网络安全概念，并且两边一致。
💡 关键认知：安全岛和安全核不是两个隔间，而是共享底盘的两套机制。真正的难点不在各自达标，而在共享资源上的互不干扰。
图5 安全岛与安全核：目标差异、机制差异与共存冲突点
五 测试评估——网络安全验证做哪些，和功能安全验证有什么不同
问：上一期讲过功能安全的故障注入，网络安全也要注入故障，两者是一回事吗？
不是一回事，尽管手段相似。功能安全的故障注入目的是证明安全机制能检出故障并进入安全状态；网络安全的故障注入（常称故障注入攻击）目的是证明攻击者无法通过电压毛刺、时钟抖动、激光等手段绕过安全机制。一个验证"机制有效"，一个验证"机制抗绕过"。
渗透测试在芯片层的落地形态常被称为"芯片级渗透测试"或"硬件渗透测试"，由具备资质的实验室执行，产出的是可被评估机构采纳的证据。侧信道与故障注入攻击测试门槛更高，通常需要专业设备，小型团队可以先用威胁场景清单做设计评审，把高风险项外包给专业实验室。
验证结果还要接入漏洞管理闭环。第 8 章的持续网络安全活动要求组织对漏洞进行监控、评估与处置，这意味着拿到测试报告只是起点，后续的 CVE 跟踪、影响分析、补丁发布、客户通知都要有记录。
图6 芯片网络安全验证四类手段与核查点
六 审核与持续改进——CSMS、分布式活动与 SBOM 供应链
问：芯片的 SBOM 要交到哪一环？它和 CSMS、R155 之间是什么关系？
CSMS（网络安全管理体系）是组织层面的能力证明，也是 UN R155 型式批准中整车厂必须展示的内容之一。芯片厂商不一定需要单独通过 CSMS 认证，但其研发流程、漏洞响应机制、供应链管理能力会成为客户审核的对象，并通过第 7 章的分布式活动以接口协议形式固定下来。
SBOM（软件物料清单）则是供应链证据的载体。一颗车规芯片交付时，随附的不只是数据手册，还有固件、驱动、示例代码的成分清单。这份清单沿芯片厂、Tier1、主机厂逐级合并，随后成为整车级 SBOM 的一部分。
SBOM 的常见格式有 SPDX 与 CycloneDX，两者都能表达组件名称、版本、哈希、许可证与依赖关系。工程上真正难的不是生成清单，而是保持清单与实物一致：固件版本一变，SBOM 就要跟着变，并且要能被下游追溯到具体芯片批次。
本章收尾时还要做一次网络安全评估与发布批准。评估回答"证据是否充分"，发布批准回答"能否放行"。两者都要求有明确的责任人与记录，不能靠口头确认。
💡 实战提醒：SBOM 不是交付清单，而是漏洞响应时间赛跑的地图。清单滞后一天，定位受影响范围的时间就多一天。
图7 SBOM 在芯片到整车供应链中的传递链
七 行业案例（据公开资料整理）
以下为公开渠道可查的车规芯片网络安全实践，用于说明能力形态与落地方式。
• 国际芯片厂商 A：其车规 MCU 系列的公开产品资料显示，芯片内集成独立的安全子系统（HSM），具备密钥存储、AES/SHA 硬件加速、真随机数发生器与安全启动能力，并提供量产阶段调试口关闭的机制。该架构在公开技术文章中被描述为"主机核 + HSM 核"的双核形态。
• 国际芯片厂商 B：据公开资料，其为车载网关与域控芯片提供硬件安全引擎，支持安全启动、密钥管理与密码运算能力，并配套提供网络安全相关的应用说明与配置指导，供集成方按整车需求裁剪。
• 国内芯片厂商 C：公开信息显示其车规安全 IP 产品系列按 EVITA Full / Medium / Light 分级提供 HSM 能力，覆盖不同的密码运算与性能需求，便于不同定位的车型选型。
这些案例的共同点是：信任根能力被做成可配置的产品化模块，芯片厂商同时提供配置指导与使用假设，由集成方在整车语境下完成验证。
八 容易踩的坑
❌ 把网络安全需求写成"使用 HSM"一句话 → ✅ 写清密钥、算法、验签策略、失败响应与版本防回滚。
❌ 安全岛与安全核共用资源，DFA 里没单列 → ✅ 共享电源、时钟、总线、内存逐项做共因分析。
❌ 只做功能安全故障注入，不做攻击型故障注入 → ✅ 两类注入目标不同，都要有报告。
❌ SBOM 生成一次就归档，固件升级不更新 → ✅ 版本与哈希随固件变更同步，能追溯到批次。
❌ 调试口在开发态全开，量产没有关闭流程 → ✅ 设计三态通道管理，售后诊断单独授权。
九 本期重点回顾
图8 车规芯片网络安全工程六步闭环：差距分析到审核改进的迭代回路
十 下期预告
第 3 期我们把视线拉到芯片定型之后：生产、运维与退役阶段的安全与网络安全衔接。先抛三个问题：
1. 量产阶段怎么保证每一颗芯片的安全配置与送样时一致？
2. 现场爆出高危 CVE 时，芯片厂商、Tier1、主机厂的响应时限怎么排？
3. 芯片停产与车型退役阶段，密钥销毁与证据归档要做到什么程度？
十一 系列简介
芯片功能安全实战系列聚焦车规芯片的 ISO 26262、ISO/SAE 21434 与相关标准落地，定位"工程师看完就能用"。第 1 期讲车规芯片功能安全从 HSI 定级到故障注入的完整闭环，本期为第 2 期：车规芯片网络安全工程。
— — — — — — — — — — — — — — — —
苏州纳兰企管提供以上专业技术支持，
欢迎联系邮件[email protected]获取解决方案。
