功能安全 × 信息安全协同工程 — ISO 26262 与 ISO/SAE 21434 的 co-engineering

把三个变化拆开看,会发现它们各自打掉了功能安全长期依赖的一条隐含前提。下表列出变化、被打掉的假设、以及由此产生的协同需求。

协同之所以可行,是因为两套标准的生命周期骨架几乎同构:都走"管理 → 概念 → 产品开发 → 生产后"的 V 流程,概念阶段都先做风险分析(26262 是 HARA,21434 是 TARA),再导出目标(安全目标 / 信息安全目标),再分解到需求,最后用一份 case 论证。正因为结构对齐,二者的工作产物可以共享或互相引用,而不是各写一套互不相认的文档。

这是最容易被忽视、也最危险的方向:一个纯粹的信息安全漏洞,经由攻击被利用后,最终表现为一次会害人的功能失效。例如攻击者向车载网络注入伪造的 CAN / SOME-IP 报文,谎报"前方无障碍"或直接命令意外制动,后果是车辆失稳——这在 26262 眼里是一个 ASIL 危害事件,但它的根因在 21434 的威胁清单里。含义:HARA 必须把"恶意触发"列为 HARA 危害的一种触发源,否则会漏掉一整类高严重度场景。

功能安全为了高可靠性引入的机制,本身可能成为攻击靶子。经典例子是 CAN 总线:它为了实时性和容错被高度优化,却几乎没有鉴权,攻击者因此能轻易伪造/抑制安全报文;再如安全监控用的看门狗、lockstep 比较器,若其触发信号或复位线可被远程置位,攻击者就能反复强制系统进安全状态(拒绝服务)。含义:每一个安全机制(safety mechanism)都要在 TARA 里被当作一项资产,评估它被绕过/触发/瘫痪的可行性。

为达成 fail-operational 引入的冗余、降级通道、诊断接口,几乎都会增加可被攻击的入口。冗余通信意味着多一条可被注入的链路;丰富的 UDS 诊断服务为标定/排故而开放,却也给了攻击者读写内存、刷写固件的入口;安全降级模式如果缺乏鉴权,反而成了攻击者主动触发的目标。含义:任何为 safety 新增的接口/路径,都要回灌进 TARA 的攻击面分析,不能"加了冗余就以为更安全"。

最棘手的不是相互削弱,而是两边的需求在同一个设计点上指向相反方向,无法同时满足,必须裁决。最典型的是 fail-operational(safety 要求失效后继续提供降级功能,例如线控转向不能直接断电)与 fail-secure(security 倾向于一旦检测到入侵就切断/锁死以止损)之间的对立;还有鉴权时延 vs FTTI、刷写可达性 vs 防篡改、日志取证 vs 隐私最小化。这一象限是第 3 章裁决矩阵要解决的核心。

互喂不是"先做完一个再做另一个",而是两条线在概念阶段并行、在固定检查点交换结果形成闭环。HARA 先给出安全攸关功能及其 ASIL 与失效后果,这份清单告诉 TARA"哪些资产一旦被攻破会害人、影响有多严重"(填 TARA 的 S 影响维度);TARA 反过来给出"哪些攻击路径会触发上述安全失效",这些路径作为新的触发源回灌 HARA。下表给出互喂的具体交换物。

并非所有工作产物都该合并:有些天然共享(同一份系统描述),有些只需交叉引用(各保留专属文档但互相指认),有些是某一方独有(21434 的持续监控、26262 的硬件度量)。强行合并独有产物只会制造噪声。下表给出对齐策略。

单独的 FMEA 看不见恶意因果,单独的 attack tree 看不见随机失效后果,协同分析要把二者缝合:在 FMEA 的失效模式行旁挂一列"是否可被恶意诱发 / 攻击路径",对每条会导致安全后果的攻击路径用 attack tree 展开其可行性。学界把这套融合记为 HATARA(HARA + TARA 融合)等方法,本质都是让一张表/一棵树同时承载"故障 → 后果"和"攻击 → 故障"两条因果链,避免两套分析的接缝处漏判。判据:任何一条 attack tree 的叶子若能命中 FMEA 中某个高 ASIL 失效模式,就必须同时拿到 safety 与 security 双方签字。

第 2.4 节的需求冲突不能靠"折中"蒙混,需要一套显式的裁决原则:先看该功能的 ASIL 与 CAL 谁更高、再看失效/被攻破的后果哪个更不可接受,据此决定缺省偏向,并为另一方设计补偿措施(而非牺牲)。下图把几类典型冲突的裁决落到一张矩阵上。

裁决的总原则可以浓缩成三条因果链:其一,生命优先于资产——当继续运行(fail-operational)是避免人身伤害的唯一手段时,默认偏 safety,但对降级通道单独加鉴权/限权以补偿 security;其二,被攻破的安全状态不是安全状态——若攻击者能主动触发"安全降级"并借此扩大危害,则该降级路径必须先满足完整性,fail-secure 在此优先;其三,时延冲突靠架构而非取舍——鉴权撞 FTTI 时,不是删鉴权或放宽 FTTI,而是用硬件加速 MAC / 预计算 freshness / 分级保护(只对安全攸关帧做轻量鉴权)把两者同时压进预算。

协同不等于把两个团队捏成一个、也不等于让一个人精通双方。可行的切分是:方法层各自保留专长(失效建模 vs 攻击建模),接口层共享产物并设固定检查点,治理层设一条统一的冲突升级路径。下表给出三层的归属。

目标 ECU 为乘用车 EPS Motor Control ECU(双通道冗余,ASIL D):

S32K344 内置 Hardware Security Engine(HSE)支持 AES-128/256、HMAC-SHA256、RSA-2048/ECDSA-P256,由安全 MCU 内核通过 MU(Messaging Unit)调用,密钥隔离存放在 HSE Flash 中,主核不可直接读取。

危害 H1 是定级主线:EPS ECU 输出非预期大幅转向扭矩。

危害 H2(参照):EPS 完全失去助力 → ASIL B(S2/E4/C2)。H2 说明"直接切断 EPS"并非无代价——120 km/h 时突然失去助力会让驾驶员可控性降至 C2 级,这正是场景 B 裁决的物理依据。

TARA 接收 HARA SG-01(ASIL D,S3)→ 将"EPS MCU 固件完整性"与"CAN 扭矩指令报文"标注为安全影响 Critical(被攻破即触发 H1 场景):

CAL 3 控制措施清单:固件签名(HSE ECDSA-P256 验签)+ OTA 通道 TLS 1.3 + Secure Boot + SecOC AES-128 CMAC + IDS(异常帧率检测)+ 渗透测试(可行性核验)。

TARA → HARA(新触发源):T1/T2 回灌为 H1 的额外触发源。原始 HARA 仅考虑随机 HW 失效;互喂后,H1 触发源增加"OTA 固件被篡改"与"CAN 报文恶意注入"——这两类攻击驱动的触发必须被 SG-01 安全机制覆盖,仅靠 lock-step 检错不够,还需 SecOC MAC 防注入。

HARA → TARA(S 影响维):TARA 将 CAN 扭矩指令报文的 Safety Impact 标注为 S3(对应 H1 后果),令 T2 的 CAL 评级升至 CAL 3,而非仅凭可用性影响评 CAL 2。

双签触发:T2 attack tree 叶子"CAN 扭矩帧注入"命中 H1(ASIL D 失效模式)→ 该条目须 safety manager + security manager 双方签字,确认 SecOC CMAC 对 H1 场景的覆盖有效性。

AUTOSAR SecOC 选用 AES-128 CMAC(车载首选,比 HMAC-SHA256 快约 10×)。扭矩帧参数:payload = 64 B(PDU 含 3 B freshness counter + 4 B CMAC 截断值 + 实际数据),CAN FD @ 5 Mbps。

帧传输时间:CAN FD 用两段比特率——仲裁段(SOF + 11-bit ID + 控制域,约 22 bit 含 bit stuffing)以标称速率 500 kbps 传输,数据段及 CRC-21(约 544 bit)以 5 Mbps 传输,尾部(ACK/EOF/IFS,约 12 bit)回到标称速率;帧总传输时间约 $22\times 2+544\times 0.2+12\times 2\approx 44+109+24=177\mu \text{s}$。

HSE AES-128 CMAC 计算时间:S32K344 HSE AES-128 吞吐量约 40 Mbps,含密钥加载开销,64 B CMAC 约 $64\times 8/(40\times 10^6)+30\mu \text{s}\approx 43\mu \text{s}$。

单帧 SecOC 总开销约 $43+177=220\mu \text{s}$,FTTI 预算占比:

扭矩帧周期 5 ms,FTTI 内可完成 30 帧鉴权——SecOC 鉴权开销不影响 FTTI 合规。

三个场景覆盖 EPS ECU 攻击检出的主要触发时刻:

场景 B 的"FTTI 内平滑降至 STO"是硬约束:fail-op 窗口最长 150 ms,不由工程师自由决定。

ASIL D 的 SPFM ≥ 99% 只由 lock-step 等硬件安全机制覆盖随机 HW 失效——SPFM 是 ISO 26262-5:2018 的纯硬件度量(分母是硬件失效率 λ),SecOC 这类信息安全机制没有 λ 可代入、不进 SPFM 计算。对 H1 的全部触发源要靠两条并列独立论证:SPFM ≥ 99% 覆盖随机 HW 失效 + SecOC CMAC 覆盖恶意注入,二者互补,而非合并进同一个 SPFM 数值(呼应 §6 G1:ASIL 与 CAL 正交)。CAL 3 不等于 ASIL D:EPS ECU 攻击面评估为 Medium(需物理接入或 TCU 被攻陷),CAL 3 覆盖该威胁级别;若误套"ASIL D → CAL 4",将带来额外渗透测试与 HSM 认证成本,而实际攻击可行性并不支持 CAL 4 评级。

ASIL 衡量随机硬件失效的覆盖率,CAL 衡量对渗透攻击的抵抗能力——两个维度正交,没有数学映射关系。一个仅挂在厂内 CAN 总线、无任何外部接口的 ASIL D 制动 ECU,其攻击面可以合理评为 CAL 1;相反,向互联网开放的 OTA 服务器虽不直接承载安全功能,却可能需要 CAL 4。误用"ASIL D → CAL 4"会让团队把渗透测试资源堆到攻击面极小的 ECU 上,却对真正高 CAL 需求的 gateway/TCU 轻描淡写——风险分配彻底倒置。正确做法:CAL 由 TARA 独立评估攻击可行性与影响得出;ASIL 仅作为 TARA 的 Safety Impact 输入,不决定 CAL 等级。

传统 HARA 方法遇到"外部人员恶意操控"场景,常以"超出分析范围(OOS)"处理,理由是"故意破坏不属于随机失效"。SDV 架构下这条边界已消失:CAN FD 报文注入在物理层面与随机 bit 翻转没有区别,但攻击者会刻意选择最危险的帧类型与时机。后果:整类"攻击驱动的严重危害"不进 ASIL 分析,安全机制对这类触发没有覆盖声明,遗漏场景也不会出现在验证计划里。修复方式:在 HARA 方法章节显式声明"攻击触发"为合法触发源,并从 TARA 互喂检查点引入具体攻击路径列表作为补充 HARA 场景。

设计 fail-op 降级路径时,工程师常认为"降级状态安全要求更低,鉴权开销可简化",省去 SecOC 或使用弱 MAC。这恰好给了攻击者利用降级通道的窗口:主动触发系统进入降级状态,在降级路径缺少鉴权时注入指令——ASIL D 安全机制被绕过,而攻击者使用的正是 fail-op 设计主动开放的通道。防御原则(§3.4 第二条):降级通道必须先满足完整性,任何为 safety 新开放的接口都必须回灌 TARA 作为新攻击面评估。

MAC 计算加帧传输通常在 100–200 μs 量级,工程师常只算这一项就宣布"SecOC 与 FTTI 兼容"。然而 freshness counter 全局同步(AUTOSAR Full-Scope-Timesync)使用周期性广播帧,典型同步周期 2 ms;节点重启或网络重配时同步报文丢失 → freshness counter 失效。该期间帧的行为取决于 SecOC verificationStatusCallout 配置:若配置为"失效帧视为有效"(保可用性),重同步窗口内无重放保护;若配置为"失效帧丢弃",安全功能中断可能触发 FTTI。正确做法:把 freshness counter 同步延迟和失效处理策略一并纳入 FTTI 预算分析,并在 FSC 里为"SecOC 失效"定义安全状态。

协同分析的锚点是双方共用的 item definition。初始版本在概念阶段签字后,系统迭代加入新传感器或新 OTA 通道——safety 团队做变更影响分析并更新 HARA;security 团队收到的触发只是"safety 说没问题",不知道新接口已游离在 TARA 攻击面之外。两条分析线的 item definition 悄悄分叉,到集成测试才发现双方覆盖的是两个不同的系统边界。修复方式:在治理层定义明确的变更触发规则——item definition 任意接口或边界变更,必须同时触发双方重新评估受影响的 HARA 危害场景和 TARA 攻击路径;变更日志由 assurance case 统一追踪。

把"IDS 检测到网络异常"直接触发"系统进安全状态(STO)"看似合理——检测到攻击就进安全状态。问题在于攻击者只需持续注入异常帧,就能反复把车辆推入安全状态(availability attack via safety reaction)。IDS 的"异常检出"是统计置信,不是"确认攻击已影响安全功能"——只有后者才应触发 safety reaction。正确架构:IDS 检出只触发告警 + 锁诊断/OTA 接口;仅当数据完整性(SecOC MAC 验证失败)或功能完整性(lockstep 比较器异常)出现实证错误时,才在 FTTI 内触发 safety reaction。

combined FMEA 引入"attack tree 叶子命中高 ASIL 失效模式 → 双签"规则后,落地时常被误解为:safety manager 要 review 每条 TARA 威胁,security manager 要 review 每条 FMEA 失效模式——工作量急剧放大,两方都叫苦。实际触发条件精确得多:仅"某 attack tree 叶子命中 FMEA 中 ASIL C/D 级失效模式"的条目需双方签字确认安全机制覆盖有效性。普通 TARA 威胁(影响 QMS 或可用性但不危及安全功能)与普通 FMEA 低 ASIL 失效模式,各团队自行处理即可。在启动协同分析时把双签触发范围讲清楚是最重要的一步,否则协同会退化为互相审批、互相拖延。

EPS ECU 的 OTA 安装必须同时满足信息安全门控(固件包 ECDSA-P256 签名验证通过 + TLS 1.3 通道完整 + RXSWIN 版本号追踪)和功能安全门控(车速为 0 + 驻车制动激活 + 驾驶员充分告知)。两个门控逻辑上串行叠加,缺一不触发安装。行驶中收到 OTA 推送时,必须先进入"后台下载+验证(不影响 EPS 运行)"状态,等待下一次安全停车窗口才执行安装+重启。若安装执行期间 EPS 功能下线,FSC 必须要求降级指示(告警灯 + HMI 提示),确保驾驶员已知并处于低风险驾驶状态。裁决原则:安装触发时刻由功能安全决定(车辆状态是硬门),安装包完整性由信息安全决定(签名链是硬门),任何一方拒绝即不安装。

AUTOSAR SecOC 用 freshness counter(FC)防重放:接收端比较帧中 FC 与本地 FC,偏差超出允许窗口则丢帧。FC 需全车周期同步(AUTOSAR TimeSync over SOME/IP)。若攻击者在 timesync 通道注入重放的旧 timesync 帧,接收节点 FC 被强制回滚 → 旧 steering torque 帧的 FC 重新落入允许窗口 → SecOC 重放保护失效。防御需两层并举:第一层,timesync 报文本身也需 SecOC 保护(用独立 KDF 或硬件时钟做初始锚点,避免 bootstrap 循环);第二层,FC 单次跳变超过阈值(单次 timesync 导致 FC 回滚超过 N 帧)时触发 IDS 异常告警而非直接接受。FTTI 分析必须把"FC 被攻击期间的最大重放窗口 $T$"纳入最坏情况:必须满足 $T\ll 150\text{ms}$(FTTI),否则 SecOC 重放保护在攻击窗口内等同失效。

ISO 26262 要求 ASIL D 功能分解为独立通道(如 ASIL B/B 双 MCU)以消除共因失效。分解的前提是两通道"充分独立"——信息安全引入的问题是:两个独立 ASIL B MCU 可能共享同一 OTA 固件供应链,若 OTA 被攻击,同一批恶意固件同时刷入两通道 → 物理独立但软件同源 → CCF 通道被攻击打通。26262-9 的 CCF β 因子估算假设通道独立性,但供应链攻击在软件层面击穿了这个假设。正确处理方式:在 FSC 独立性论证中增加"软件供应链独立性"维度,要求两冗余通道固件包在 OTA 前分开签名验证(不同子 CA 密钥),并在安装前 diff 比对确认非同源;CCF β 重新评估时把"固件 OTA 共因路径"的 β 贡献单独列出,引导向安全机制设计,而非被隐藏在整体 β 估值里。