RAS当信息安全措施超出FTTI——用STPA填补HARA与TARA之间的空白
01摘要
02场景：必须在50 ms内完成的制动，每条消息都要增加的验证
前视摄像头和雷达检测到一辆静止车辆。ADAS域中的AEB控制器判断存在碰撞风险，并通过车辆总线发送紧急制动请求。请求消息带有SecOC认证标签（CMAC）和新鲜度计数器。线控制动的制动ECU重新计算标签，确认请求确实来自AEB控制器之后，才施加制动压力。
Electronics Weekly的文章正是以这一过程为例。线控制动和线控转向的FTTI通常为10～50 ms，任何延迟都会直接转化为制动距离。如果制动ECU以软件方式进行AES-128验证、每条消息耗时2 ms，而CAN总线又处于饱和状态，累积的延迟就会大幅侵蚀FTTI裕量。文章的结论很明确：如果制动消息因信息安全设计而超出FTTI，那就是ISO 26262意义上的功能安全失效。
没有人会反对这一结论。但在实际项目中，这句话写在哪里呢？
03HARA表和TARA表中都没有时间栏
| 关注的内容 | 不关注的内容 | |
|---|---|---|
| HARA (ISO 26262-3) | 危害事件的严重度（S）、暴露度（E）和可控性（C），ASIL，安全目标 | 当信息安全措施位于保障安全目标的路径上时，还剩下多少时间 |
| TARA (ISO/SAE 21434) | 资产，损害场景及其影响（安全、财务、运营、隐私），攻击路径及其可行性 | 措施（认证、加密）占用了安全功能多少时间预算 |
| FTTI与安全机制 (ISO 26262-4、-5) | 故障检测与响应时间，FTTI | 信息安全措施共用同一时间预算这一事实 |
即使两项分析在同一个研讨会上进行，只要表格的栏目是这样，这一冲突最终也只会在会议纪要中留下一行。安全团队提出“FTTI 50 ms”作为要求，信息安全团队提出“认证成功前不得执行”作为要求，而两项要求在同一个50 ms内发生冲突这一事实，要到集成测试时才会暴露出来。
有一点需要更正。文章建议“直接从HARA的ASIL中”推导TARA的影响等级。然而在ISO/SAE 21434中，损害场景的安全影响等级是以ISO 26262-3的严重度（S）为基础确定的。ASIL中混合了暴露度和可控性，如果原样沿用，就会忽略攻击可能改变暴露度或可控性这一点。应当沿用的是S，而不是ASIL。
04STPA通过UCA追问时间
对于控制器发出的每一个控制行为，STPA都会询问它是否可能以四种方式变得不安全：未提供；在不安全时提供；提供过早、过晚或顺序错误；停止过早或持续过久。第三个问题正是FTTI所在的位置。
而且，在STPA的控制结构中，认证和总线直接位于控制路径和反馈路径之上。认证验证位于制动ECU的控制算法之中，总线延迟位于控制路径之中，新鲜度计数器同步位于制动ECU的过程模型之中。由于信息安全措施不再是“安全分析之外的另一份文档”，而是成为控制回路的一部分，因此在编写损失场景时自然就会被识别出来。
05示例：AEB紧急制动请求路径
这是一个用于教学的虚构系统（并非任何特定车辆或制造商的设计）。FTTI设定为说明用的示例值50 ms。损失有两项：人员伤亡和财产损失；危害有两项：“未能保持安全距离”（H-1）和“在不需要时紧急制动”（H-2）。系统约束写为：
该约束将HARA的安全目标与TARA的网络安全目标原本分别表述的内容合并成了一句话。
4个UCA
| ID | 控制行为 | 不安全控制行为 | 危害 |
|---|---|---|---|
| UCA-T-1 | 紧急制动请求 | 存在前方碰撞风险，但AEB控制器发送请求过晚，导致制动ECU完成认证验证的时间点超出FTTI预算 | H-1 |
| UCA-T-2 | 施加制动压力 | 请求已经到达，但制动ECU等待认证验证，在FTTI之后才开始施加制动压力 | H-1 |
| UCA-N-3 | 施加制动压力 | 请求已经到达，但制动ECU因认证失败而丢弃请求，未施加制动压力 | H-1 |
| UCA-P-4 | 施加制动压力 | 不存在碰撞风险，但制动ECU接受了伪造或重放的请求并施加制动压力 | H-2 |
UCA-P-4在TARA中会被写成威胁场景。在STPA中，它与UCA-T-2并列在同一张表中。放宽认证，T-2减少而P-4增加；收紧认证，情况则相反。能在同一个界面上看到这种平衡，正是本文的要点。
5个损失场景
| ID | UCA | 场景概要 | 揭示的问题 |
|---|---|---|---|
| LS-1 | T-2 | 以软件方式验证认证，每条消息约2 ms；总线饱和又带来排队和重传，累积延迟超出FTTI。验证时间只在正常负载下测量过 | 正是文章中的案例。对策：最坏情况测量和HSM |
| LS-2 | T-2 | 制动ECU算法只定义了“认证前不得制动”，未定义验证未能在FTTI内完成时的行为。两项要求分别存在于HARA和TARA文档中，因此冲突从未暴露 | 缺失的栏目本身 |
| LS-3 | T-1 | 摄像头和雷达数据同样经过认证、通过同一总线传输，总线过载会同时延迟目标物数据和制动请求 | 共因；与上一篇文章中组合原型的结构相同 |
| LS-4 | N-3 | 制动ECU复位后新鲜度计数器失步，合法请求被判定为重放攻击而被丢弃。由于没有“认证失败”反馈，AEB控制器以为制动已经施加 | 信息安全措施造成的隐蔽 |
| LS-5 | P-4 | 信息娱乐域被攻破，网关未过滤制动请求ID。为减少延迟而放宽了新鲜度计数器的接受窗口，导致重放的请求得以通过 | 为节省时间而做的设置变成了信息安全漏洞 |
将这5个场景并列来看，会发现其中混有方向相反的场景。LS-1和LS-2是因为信息安全措施太慢而产生的，LS-5则是因为试图让它更快而产生的。LS-4是信息安全措施拦截了合法请求，并且掩盖了这一事实。如果将安全与信息安全分开分析，前三个场景很可能出现在安全团队的文档中，LS-5出现在信息安全团队的文档中，而LS-4则哪一方都不会记录。
6项对策
| ID | 对策 | 关联场景 |
|---|---|---|
| CM-1 | 将认证验证移至HSM加密加速器；在包括总线饱和在内的最坏情况下测量验证时间，并记录在延迟预算中 | LS-1 |
| CM-2 | 在FTTI内为每个阶段（检测 → 决策 → 认证生成 → 传输 → 验证 → 执行）分配延迟上限，并作为要求明确写出 | LS-1, LS-3 |
| CM-3 | 在安全概念中定义验证未能在预算内完成或认证失败时的行为（例如驾驶员警告、降级模式）。哪种行为属于安全侧，需要结合HARA和TARA的结果来决定 | LS-2, LS-4 |
| CM-4 | 将“认证失败、请求已丢弃”状态反馈给AEB控制器，并定义新鲜度计数器重新同步流程 | LS-4 |
| CM-5 | 为安全关键消息确保总线优先级和带宽（CAN FD、车载以太网）；进行抖动仿真 | LS-3 |
| CM-6 | 网关进行域间过滤，HSM密钥与应用核分离，新鲜度接受窗口与延迟预算一并决定 | LS-5 |
CM-3需要谨慎对待。选择“验证延迟时先制动再说”可以防止LS-1，却会重新打开LS-5。这一决定无法由安全团队或信息安全团队单方面做出，这也正是两项分析需要建立在同一模型之上的原因。
06延迟预算：将SC-2转化为数字
系统约束SC-2只有变成下面这样的表格才能得到验证。表中数字为说明用的示例。
| 阶段 | 示例上限 | 负责方 | 依据 |
|---|---|---|---|
| 目标物检测与识别 | 15 ms | ADAS | 实测传感器周期和处理时间 |
| 碰撞决策与请求生成 | 10 ms | ADAS | 算法最坏情况执行时间 |
| 认证标签生成 | 1 ms | 信息安全 | HSM测量值 |
| 总线传输（最坏情况） | 5 ms | 架构 | 总线负载和优先级分析，抖动仿真 |
| 认证验证 | 1 ms（HSM） / 2 ms或以上（软件） | 信息安全 | 最坏情况测量 |
| 制动压力建立 | 15 ms | 底盘 | 执行器响应测试 |
| 合计 | 47 ms ≤ FTTI 50 ms | 安全 | 预算审批 |
这张表中的每一格都对应STPA控制路径和反馈路径上的一个要素。损失场景追问“哪一格可能溢出？”，对策则决定“由谁来证明这一格的上限？”。
07明天要检查的事项
功能安全
- 安全目标的FTTI预算中，是否将信息安全措施（认证生成和验证）作为单独的条目列出？
- 认证验证时间是否在最坏情况下而非正常负载下测量？
网络安全
- TARA损害场景的安全影响等级是否取自严重度（S），而非HARA的ASIL？
- 新鲜度计数器的接受窗口以及认证失败时的行为，是否与安全团队共同决定？
架构师
- “认证失败、请求已丢弃”状态是否反馈给了发送请求的控制器？
- 是否已通过抖动仿真确认安全关键消息不会被加密的低优先级流量挤占？
08结语
VisualPro可以在同一个项目中完成HARA、TARA和STPA。本文中的STPA示例使用VisualPro STPA制作。
09常见问题
Q1把HARA和TARA一起做难道还不够吗？为什么还需要STPA？
Q2使用HSM不就能解决问题吗？
Q3如果认证验证过晚，为什么不直接制动？
Q4从HARA沿用TARA影响等级的正确方法是什么？
Q5我们从未使用过STPA，应该从哪里开始？
· Electronics Weekly, "Linking functional safety with cybersecurity in the automotive industry", 2026年10月13日（Diego de Azcuénaga） — 原文
· ISO 26262-1:2018 FTTI定义；ISO 26262-3:2018 HARA
· ISO/SAE 21434:2021 — 损害场景的影响等级（安全影响以ISO 26262-3的严重度为基础）
· AUTOSAR Specification of Secure Onboard Communication (SecOC)
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — STPA Handbook (PDF) / MIT PSASS STAMP Tools