4. 安全需求分解：从TSR到SSR与HSR的落地
好，咱们进入第四讲。前面我们聊了安全目标和ASIL等级，那都是顶层设计。现在要干的事，说白了就是——把那些抽象的安全目标，拆成工程师能直接动手的活儿。
我个人习惯把这一步叫做“从目标到需求的翻译”。你想想看，安全目标说“升级包不能被篡改”，但软件工程师要怎么写代码？硬件工程师要选什么芯片？这中间差着一层呢。
这一层，就是技术安全需求（TSR）、软件安全需求（SSR）和硬件安全需求（HSR）。
4.1 技术安全需求（TSR）的编写
TSR是连接安全目标和具体实现的桥梁。它不关心你用软件还是硬件实现，只描述“系统应该具备什么技术能力来满足安全目标”。
举个例子，安全目标是：“在OTA升级过程中，避免因升级包损坏导致ECU变砖（ASIL B）”。
那么对应的TSR可能是：
- TSR-01：系统必须在升级前对升级包进行完整性校验，校验算法支持SHA-256及以上。
- TSR-02：系统必须在升级过程中检测通信中断，并在中断后30秒内进入安全状态。
- TSR-03：系统必须保留至少一个可回滚的备份版本，备份版本必须通过完整性校验。
写TSR时，我有个经验：每个TSR必须可验证。什么叫可验证？就是测试工程师看到这条需求，知道怎么测。比如“校验算法支持SHA-256”，测试可以写用例验证是否真的用了SHA-256。但如果你写“系统要足够安全”，那测试就懵了。
4.2 软件安全需求（SSR）的分解
TSR写好了，接下来要分给软件和硬件。SSR就是软件部分的安全需求。
我记得在做一个OTA项目时，TSR要求“升级包完整性校验”。软件团队一开始说：“简单，我们在下载完成后算个哈希就行。”但后来发现，如果哈希算法本身被篡改了呢？如果校验代码在升级过程中被覆盖了呢？
所以SSR的分解，不能只是简单地把TSR抄一遍。你得考虑软件架构、模块划分、运行时环境。
从TSR-01分解出来的SSR可能包括：
- SSR-01.1：Bootloader必须在应用启动前，对应用镜像进行SHA-256完整性校验。
- SSR-01.2：校验代码必须存储在受保护的只读存储区，运行时不得被修改。
- SSR-01.3：如果校验失败，Bootloader必须禁止启动新应用，并尝试回滚到备份版本。
你看，一个TSR拆成了三个SSR，每个都对应具体的软件模块和具体行为。这就是分解的意义。
4.3 硬件安全需求（HSR）的分配
硬件这边，HSR的分配往往更依赖芯片选型和硬件架构。我见过不少项目，软件安全需求写得天花乱坠，结果硬件不支持——比如要求硬件安全模块（HSM）做签名验证，结果选的MCU根本没有HSM。
从TSR分解到HSR，常见的方向包括：
- 存储安全：Flash需要支持ECC，防止位翻转导致升级包损坏。
- 通信安全：CAN/CAN FD控制器需要支持硬件时间戳，用于检测消息延迟或重放攻击。
- 安全启动：硬件必须提供安全存储区存放公钥，且该区域在调试模式下不可读。
- 故障响应：硬件看门狗必须在主核挂起时触发系统复位。
举个例子，TSR-02要求“30秒内进入安全状态”。硬件这边可能需要：
- HSR-02.1：硬件看门狗超时时间设置为25秒（留5秒余量给软件处理）。
- HSR-02.2：电源管理芯片（PMIC）必须支持在收到看门狗触发信号后，5ms内切断非安全相关模块电源。
4.4 需求分解的完整流程
说了这么多，咱们用一张图把整个流程串起来。下面这张SVG图，展示了一个典型的OTA升级安全需求分解路径。
4.5 需求追溯矩阵
需求分解完了，怎么保证没漏？我建议你建一个需求追溯矩阵。这玩意儿看着麻烦，但真能救命。
下面是一个简化的例子，针对OTA升级包完整性校验这个场景：
| 安全目标 | TSR编号 | SSR编号 | HSR编号 | 验证方法 |
|---|---|---|---|---|
| SG-01: 防止升级包篡改 | TSR-01 | SSR-01.1, SSR-01.2, SSR-01.3 | HSR-03.1 | 代码审查 + 故障注入 |
| SG-02: 防止通信中断导致变砖 | TSR-02 | SSR-02.1, SSR-02.2 | HSR-02.1, HSR-02.2 | 时序测试 + 硬件在环 |
| SG-03: 保证回滚能力 | TSR-03 | SSR-03.1, SSR-03.2 | HSR-03.2 | 集成测试 |
这个矩阵，每个项目阶段都要更新。我习惯在需求评审会上，直接拿这个矩阵过一遍——看哪个安全目标没有对应的TSR，哪个TSR没有分解到SSR/HSR。嗯，这招帮我抓出过不少遗漏。
4.6 常见误区与避坑
最后，聊几个我亲眼见过的坑：
- 误区一：TSR写得太具体。比如直接写“使用HSM模块的AES-128引擎”。这就把实现方案定死了，万一后面换芯片呢？TSR应该写“提供加密运算能力”，具体用HSM还是软件库，那是SSR/HSR的事。
- 误区二：SSR和HSR重复。比如SSR写了“Flash数据完整性保护”，HSR也写了同样的内容。这会导致测试时两边都测，或者两边都以为对方在测。明确分工：硬件负责ECC检测，软件负责重读校验。
- 误区三：忽略ASIL分解。如果一个TSR是ASIL D，但分解后的SSR只覆盖了ASIL B，那剩下的ASIL D谁来覆盖？要么硬件承担，要么加冗余。别让ASIL等级在分解过程中“缩水”。
好了，这一讲的内容就是这些。记住，安全需求分解是功能安全落地的第一步，也是最重要的一步。分解得好，后面的设计、实现、测试都会顺畅很多。分解得不好……嗯，后面全是坑。