📚 课程目录第2章 ISO21434核心概念与AURIX适配

2. ISO21434核心概念与AURIX适配

ISO/SAE 21434 把“网络安全”从一句口号拆解成一条可追溯的工程链条：先识别资产，再分析威胁与脆弱性，推导攻击路径，评估风险，确定网络安全目标，最后用CAL 等级约束开发过程的严格程度。理解这条链条，是后续在 AURIX 上落地安全机制的前提。

一、五个核心概念：从“保护什么”到“保护到什么程度”

资产（Asset）是“一旦被破坏就会造成损害的对象”。在 AURIX 项目里，资产不只是密钥，还包括：HSM 内的密钥槽与固件、Boot ROM 与 PFlash 中的启动代码、UCB（User Configuration Block）中的调试保护与生命周期配置、CAN/FlexRay 报文中的安全信号、以及诊断服务（UDS）的会话与安全访问状态。资产必须可枚举、可定位，否则后续分析无从谈起。

威胁（Threat）是“可能对资产造成损害的潜在原因”，通常用“攻击者+动作+目标”描述，例如“攻击者通过未锁定的调试口读取 PFlash 中的标定数据”。脆弱性（Vulnerability）是资产或系统中可被威胁利用的弱点，例如调试口未禁用、UCB 未写入保护、HSM 固件版本过旧、软件缺少完整性校验。威胁是“外部意图”，脆弱性是“内部缺口”，二者结合才形成可实施的攻击。

攻击路径（Attack Path）是把威胁与脆弱性串起来的可执行步骤序列。例如：物理接触 → 进入调试模式 → 读取内存 → 提取密钥 → 伪造报文。攻击路径的价值在于暴露“哪一步最容易被切断”，从而指导安全机制部署位置。

风险（Risk）由“攻击可行性”和“损害影响”共同决定。ISO/SAE 21434 用攻击可行性等级（高/中/低/极低）与影响等级（严重/重大/中等/轻微）构成风险矩阵，输出风险值 1~5。风险值决定是否需要新增安全目标，以及 CAL 等级的下限。

网络安全目标（Cybersecurity Goal）是对资产要达成的保护性陈述，例如“防止未授权读取 HSM 密钥”“确保启动代码完整性可验证”。目标必须可映射到具体机制，否则无法验证。

二、CAL 等级：把风险翻译成开发严格度

CAL（Cybersecurity Assurance Level）分为 CAL1~CAL4，等级越高，要求的分析深度、验证独立性和文档追溯性越强。CAL 不是对“功能”的要求，而是对“过程保证”的要求。一个常见映射原则是：风险值 1~2 对应 CAL1/CAL2，风险值 3 对应 CAL3，风险值 4~5 对应 CAL4。实际项目中，OEM 可能对特定资产（如密钥）直接规定 CAL4，而不完全依赖风险矩阵计算结果。

CAL 等级决定“做多少证据”，安全机制决定“做什么防护”。两者不能互相替代：CAL4 的流程不能弥补一个未锁定的调试口。

三、AURIX 安全模块与标准条款的映射

AURIX TC3xx 提供了一组硬件安全模块，它们与 ISO/SAE 21434 的条款存在天然对应关系：

HSM（Hardware Security Module）：独立核、独立存储、独立密钥管理，对应“密钥保护”“安全启动”“加密服务”等目标，支撑条款 10（产品开发）中的安全机制实现与 11（验证）中的功能验证。
UCB 与调试保护：通过 UCB 配置调试口禁用、生命周期状态、Flash 保护，对应“防止未授权物理访问”，支撑条款 9（概念阶段）中攻击路径的切断。
SMU（Safety Management Unit）与安全管理：虽然主要面向功能安全，但其告警与状态监控可用于检测异常，支撑条款 8（风险评估）中的威胁监控与响应。
Secure Boot（基于 HSM 的启动校验）：对应“启动代码完整性”目标，支撑条款 10 中的安全启动实现与条款 11 中的启动验证。
CSRM（Cybersecurity Real-time Monitoring）：部分 AURIX 型号提供运行时监控，对应“运行时异常检测”，支撑条款 12（生产与运维）中的持续监控。

映射关系不是“一个模块对应一个条款”，而是“一个安全目标可能由多个模块共同支撑，一个模块也可能服务多个条款”。例如，HSM 既支撑密钥保护，也支撑安全启动和加密通信。

四、从概念到 AURIX 配置的示例

假设某项目识别出资产“HSM 密钥槽”，威胁“攻击者通过调试口读取密钥”，脆弱性“调试口未禁用”。攻击路径为：物理接触 → 调试口使能 → 读取 HSM 密钥。风险影响为“严重”，攻击可行性为“中”，风险值 4，对应 CAL4。网络安全目标为“防止未授权读取 HSM 密钥”。

在 AURIX 上的实现动作包括：在 UCB 中写入调试保护配置，禁用 JTAG/DAP；在 HSM 中启用密钥槽访问控制，仅允许授权核访问；在启动阶段由 HSM 校验 PFlash 完整性，防止固件被篡改。验证时，通过调试口尝试连接应被拒绝，通过 HSM 日志确认密钥访问被记录，通过篡改 PFlash 后启动应失败。这些证据对应条款 11 的验证要求，并作为 CAL4 的追溯材料。

五、落地时的关键判断

在实际项目中，最容易出问题的不是“不知道有哪些模块”，而是“资产识别不完整”和“攻击路径切断点选错”。建议在概念阶段就建立一张资产-威胁-脆弱性-机制-验证的追溯表，每新增一个资产，就追问三个问题：它被谁访问？访问路径上有哪些控制点？控制点失效后如何检测？AURIX 的 UCB、HSM、SMU 和 CSRM 正好提供了从物理层到运行时的多层控制点，但前提是这些控制点被正确配置并纳入验证范围。

不要把 CAL 等级当成“安全功能等级”。CAL4 只说明过程保证要求高，不代表系统一定安全；真正的安全性来自资产识别完整、攻击路径被有效切断、验证证据可追溯。

下一阶段进入具体条款时，应始终回到这条概念链：资产决定保护对象，威胁与脆弱性决定攻击面，攻击路径决定控制点位置，风险决定 CAL 等级，网络安全目标决定验证准则，AURIX 安全模块决定实现手段。六者对齐，ISO/SAE 21434 的落地才不会变成文档堆砌。