4. ST Stellar 安全启动与安全通信

在 Stellar 这类面向域控与区域控制器的车规 MCU 上，功能安全（ISO 26262）与信息安全（ISO/SAE 21434）是两条并行但相互支撑的主线。安全启动解决的是“我运行的代码是不是被授权、被篡改过的代码”；安全通信解决的是“我在总线上收发的报文是不是真实、完整、新鲜的”。本节围绕 Stellar 的 HSM（Hardware Security Module）、安全启动链、SecOC 与 E2E 保护，讲清楚实现要点与工程落地方式。

一、安全启动：从 Boot ROM 到应用的可信链

Stellar 的安全启动不是单一动作，而是一条逐级验证的信任链。上电复位后，首先执行固化在芯片内的 Boot ROM，它使用芯片内不可改写的信任根（Root of Trust，通常基于硬件密钥与 ROM 代码哈希）验证第一阶段引导程序（如 HSM 固件或 Flashloader）的签名。验证通过后，控制权才交给下一级；下一级再用同样的非对称验签方式验证应用固件。任何一级验签失败，芯片会停留在安全状态（如进入恢复模式或停止启动），而不是继续执行可疑代码。

工程实现上，需要关注几个关键点。第一，镜像签名格式：Stellar 通常采用“镜像头 + 签名 + 证书链”的结构，镜像头中包含版本号、长度、目标地址、哈希算法标识等元数据，签名覆盖镜像头与镜像体。第二，密钥管理：量产密钥应存放在 HSM 的受保护密钥槽中，调试密钥与量产密钥分离，避免开发阶段密钥泄露影响量产安全。第三，回滚保护：通过单调计数器（Monotonic Counter）记录已接受的最低安全版本，防止攻击者刷入旧版本固件利用已知漏洞。第四，启动时间预算：验签（尤其是 RSA 或 ECDSA）会消耗时间，需在启动时序与安全强度之间做权衡，例如对实时性要求高的 ECU 可采用 ECDSA P-256 而非 RSA-4096。

二、HSM 使用要点：不只是“放密钥的地方”

Stellar 的 HSM 是一个独立的安全核，拥有自己的 CPU、RAM、ROM 和密码外设，与主核通过受控的邮箱（Mailbox）或共享内存通信。使用 HSM 时，主核不能直接读取 HSM 内部密钥，只能请求 HSM 执行“用某密钥做验签/解密/MAC”这类操作，密钥始终不出安全边界。这是与软件加密库最本质的区别。

实际开发中，HSM 的典型使用包括：安全启动验签、SecOC 的 CMAC 计算、诊断安全访问（UDS 0x27）的种子密钥运算、以及安全日志的签名。配置时需要注意：HSM 固件与主核应用固件需分别签名、分别升级；HSM 与主核之间的共享内存要定义清晰的命令/响应协议，避免主核通过恶意参数诱导 HSM 执行越权操作；HSM 的调试接口在量产阶段必须关闭或锁定。

三、SecOC：总线上的报文认证

SecOC（Secure Onboard Communication）解决的是 CAN/CAN FD 或以太网报文被伪造、重放、篡改的问题。其核心机制是：发送端对报文的“数据 + 新鲜度值（Freshness Value）”计算 CMAC，并将截断后的 MAC 附加在报文尾部；接收端用同样的新鲜度值和密钥重新计算 CMAC，与收到的 MAC 比对，一致才接受报文。

在 Stellar 上实现 SecOC，关键点有三个。第一，新鲜度值管理：通常由主核维护一个单调递增的计数器，或由 HSM 提供受保护的新鲜度源，防止攻击者重放旧报文。第二，CMAC 计算位置：为降低主核负载并保护密钥，CMAC 应尽量由 HSM 完成，主核只负责组包和比对。第三，截断长度与总线负载的权衡：MAC 截断越短，总线开销越小，但抗暴力破解能力越弱。工程上常见做法是截断到 24～64 位，并结合报文周期和总线负载率确定。

四、E2E 保护：端到端的完整性防线

E2E（End-to-End）保护与 SecOC 不同：SecOC 主要防外部攻击，E2E 主要防“链路内部”的随机故障与系统性错误，例如 CRC 校验、计数器、数据 ID、超时监控。AUTOSAR E2E Profile 1/2/4/5/6/7/11/22 各有适用场景，Stellar 上常与 SecOC 叠加使用：SecOC 提供密码学认证，E2E 提供功能安全层面的数据完整性监控。

实现时，E2E 的计数器、CRC 和数据 ID 通常由软件在 COM 层或 RTE 层插入，接收端由 E2E 库校验。需要特别注意的是：E2E 的计数器与 SecOC 的新鲜度值是两套独立机制，不能互相替代；E2E 的 CRC 多项式、初始值、字节序必须与通信矩阵严格一致，否则会出现“功能正常但 E2E 持续报错”的典型问题。

五、落地检查清单