4. S32G安全网关系统需求分析
S32G作为车载中央网关，同时承担CAN/CAN FD、LIN、FlexRay与车载以太网之间的报文路由、协议转换和域间隔离任务。它既属于功能安全相关部件（网关失效可能导致关键控制报文丢失或延迟），又是信息安全的高价值攻击目标（一旦被攻破，攻击者可跨域横向移动）。因此需求分析必须把功能安全（Safety）与信息安全（Security）两条主线并行展开，并在同一张需求基线上完成威胁建模、攻击面识别和安全目标定义。
一、功能安全需求：从危害到网关安全机制
功能安全需求来源于危害分析与风险评估（HARA）。以“网关转发关键控制报文”为例，可识别出典型危害：制动/转向相关报文被延迟或丢弃，导致整车层面非预期行为。按ISO 26262思路，先确定ASIL等级，再导出安全目标（Safety Goal）与功能安全需求（FSR），最后落到技术安全需求（TSR）。
对S32G网关而言，常见的安全目标可归纳为三类：可用性（关键报文必须在规定周期内被转发）、完整性（转发内容不得被篡改或错序）、及时性（端到端延迟不超过预算）。对应的技术安全需求包括：看门狗与心跳监控、路由表CRC校验、报文超时检测、队列溢出保护、双核锁步（Lockstep）监控、ECC内存保护以及故障降级策略（如进入安全路由模式，仅转发白名单关键报文）。
需要强调的是，功能安全需求必须可度量。例如“关键报文端到端延迟≤5 ms”比“保证实时转发”更可验证；同样，“路由表CRC每100 ms校验一次，连续2次失败进入降级模式”才是可测试的TSR。这些量化指标将直接成为后续安全目标与测试用例的输入。
二、信息安全需求：从资产到安全属性
信息安全需求通常从资产识别开始。S32G网关的核心资产包括：路由配置与防火墙规则、密钥与证书、诊断服务（UDS）、OTA升级镜像、日志与审计数据、以及各网段的报文流。针对每类资产，明确需要保护的CIA属性：
- 机密性：密钥、证书、诊断种子不得明文暴露；
- 完整性：路由表、固件、OTA包必须签名校验；
- 可用性：网关不得被泛洪或重放攻击拖垮；
- 真实性/不可否认性：诊断与升级操作需身份认证与审计。
由此导出信息安全需求，例如：SecOC对关键CAN报文做MAC校验；以太网侧启用IPsec或TLS；UDS诊断需27服务安全访问；OTA镜像需ECDSA签名验证；防火墙按五元组做白名单过滤。这些需求与功能安全需求在S32G上共享硬件资源（HSE安全引擎、CAN加速器、以太网交换），因此必须统一分配算力与内存预算。
三、威胁建模：STRIDE在车载网关上的落地
威胁建模推荐采用STRIDE方法，对S32G网关的数据流逐条分析。以“外部诊断仪→OBD口→网关→动力CAN”这条路径为例：
| STRIDE类别 | 网关场景示例 | 对应缓解 |
|---|---|---|
| Spoofing 仿冒 | 伪造诊断仪身份接入 | 双向认证、证书校验 |
| Tampering 篡改 | 修改路由表或固件 | 签名校验、CRC、HSE |
| Repudiation 抵赖 | 否认执行过诊断写操作 | 安全日志与时间戳 |
| Info Disclosure 泄露 | 窃听以太网明文报文 | IPsec/TLS、SecOC |
| DoS 拒绝服务 | CAN泛洪导致队列溢出 | 限速、优先级队列、看门狗 |
| Elevation 提权 | 绕过安全访问执行刷写 | 权限分级、最小特权 |
建模时应为每条威胁标注攻击路径、所需前提（如物理接触OBD、已控制某ECU）和影响范围（单域/跨域/整车），从而确定优先级。高优先级威胁应直接映射为安全目标。
四、攻击面识别：S32G网关的入口清单
S32G网关的攻击面可分为物理接口、网络接口、软件接口和供应链四类。物理接口包括OBD-II、调试口（JTAG/SWD）、USB；网络接口包括CAN/CAN FD、LIN、FlexRay、100/1000BASE-T1以太网、Wi-Fi/蓝牙（若经网关）；软件接口包括UDS诊断、OTA、Bootloader、Shell/日志口；供应链包括第三方协议栈、AUTOSAR BSW、HSE固件。识别时应记录每个入口的“可达性、认证要求、数据流向”，形成攻击面清单，作为安全目标与测试范围的依据。
五、安全目标定义与需求基线
安全目标是威胁建模与攻击面识别的收敛结果，应满足SMART原则：具体、可度量、可达成、相关、有时限。以S32G网关为例，可定义如下安全目标：
- SG1（可用性）：在CAN总线负载≤70%条件下，关键控制报文端到端延迟≤5 ms，丢包率=0；
- SG2（完整性）：路由表与固件在加载前必须通过ECDSA-P256签名校验，校验失败进入安全模式；
- SG3（真实性）：所有UDS诊断写操作需通过27服务安全访问，连续3次失败锁定10分钟；
- SG4（抗DoS）：在1000帧/s泛洪攻击下，关键报文转发不受影响，非关键报文可降级丢弃；
- SG5（可审计）：所有安全事件（认证失败、签名失败、降级）写入安全日志，日志具备防篡改保护。
这些安全目标向下分解为功能安全需求与信息安全需求，并映射到S32G的具体机制：SG1对应队列优先级与看门狗；SG2对应HSE签名校验与CRC；SG3对应UDS 27服务与密钥管理；SG4对应防火墙限速与队列隔离；SG5对应安全日志与HSE保护的存储区。最终形成一份可追溯的需求基线：每条安全目标都能追溯到威胁与攻击面，每条技术需求都能追溯到安全目标，并配有对应的验证方法（测试用例、渗透测试、故障注入）。
完成需求分析后，下一步才是架构设计与安全机制选型。本节的核心产出是一份经过威胁建模验证、覆盖功能安全与信息安全双主线的安全目标清单，它既是后续S32G网关架构设计的输入，也是最终安全验证与认证（如ISO 21434、ISO 26262）的基线依据。