安全与升级：SecOC、IDS 与 OTA 工程实践

本页关注通信系统在安全攻击和持续升级场景下的可用性与安全性，涵盖车载通信安全机制与 OTA 全生命周期管理。

1. 车载网络威胁模型

1.1 攻击面分析（STRIDE 框架）

威胁类别	英文	车载场景示例
欺骗	Spoofing	伪造 CAN 消息、伪造 GNSS 信号
篡改	Tampering	修改制动指令、篡改传感器数据
抵赖	Repudiation	否认操作记录
信息泄露	Information Disclosure	窃取驾驶轨迹、用户隐私
拒绝服务	Denial of Service	CAN 总线泛洪、以太网 DoS
特权提升	Elevation of Privilege	从 OBD 口渗透到底盘控制

1.2 典型攻击路径

外部攻击面：
  蜂窝网络 (4G/5G) ───> T-Box ───> 车内网络
  Wi-Fi / 蓝牙      ───> IVI   ───> 跨域渗透
  USB / OBD-II      ───> ECU   ───> 直接访问
  V2X 通信          ───> DSRC/C-V2X ─> 伪造路侧消息

安全设计原则

遵循"深度防御"：每层都假设其他层可能失效。不要依赖单一安全机制。

2. SecOC（安全车载通信）

2.1 基本原理

SecOC 是 AUTOSAR 定义的车载总线消息认证框架，通过在原始 PDU 后附加消息认证码（MAC）和 Freshness Value 来防止消息被篡改和重放。

受保护 PDU 结构：

┌─────────────────────────────────────────────────────────┐
│  原始 Data PDU  │  Freshness Value (部分)  │  MAC (截断)  │
└─────────────────────────────────────────────────────────┘

MAC：通常使用 CMAC-AES-128，截断为 24~64 bit 附在帧中
Freshness Value：单调递增计数器或时间戳，防重放攻击
共享密钥：发送方和接收方共享对称密钥，存储在 HSM 中

2.2 消息认证流程

发送方：
  payload + freshness_value → CMAC(key) → truncate → append → 发送

接收方：
  接收帧 → 提取 MAC → 重新计算 MAC → 比较 → 验证通过/失败
           检查 freshness_value → 防重放

2.3 Freshness Value 管理

Freshness Value 的同步是工程难点：

方案 A：计数器（每次发送递增）—— 需要持久化存储，ECU 重启后的恢复策略
方案 B：时间戳（结合 gPTP 同步时钟）—— 依赖精确时间同步
方案 C：混合（计数器 + 时间窗口）—— 工程中常见折中方案

工程实践

SecOC 的 MAC 验证会增加约 10–50 μs 的处理时延（视芯片和 HSM 性能）。对于高频控制帧（1kHz+），应选用硬件 HSM 加速，避免软件实现成为瓶颈。

3. IDS/IPS（入侵检测/防御系统）

3.1 车载 IDS 架构

┌──────────────────────────────────────────────────────────┐
│                    车载 IDS                               │
│                                                          │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐ │
│  │ 网络探针     │   │ 主机探针      │   │ 日志收集      │ │
│  │ (CAN/ETH)   │   │ (ECU 内部)   │   │ (Syslog)     │ │
│  └──────┬───────┘   └──────┬───────┘   └──────┬───────┘ │
│         └──────────────────┼──────────────────┘          │
│                            ↓                              │
│  ┌─────────────────────────────────────────────────────┐ │
│  │        分析引擎（规则匹配 + 异常检测）               │ │
│  └─────────────────────────────────────────────────────┘ │
│                            ↓                              │
│  ┌─────────────────────────────────────────────────────┐ │
│  │        响应模块（告警/限速/隔离/上报）               │ │
│  └─────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘

3.2 检测方法

方法	描述	优点	局限
基于签名	已知攻击规则匹配	低误报	无法检测未知攻击
基于异常	统计模型偏差检测	可发现新型攻击	误报率较高
基于行为	进程/通信行为建模	细粒度	建模成本高

3.3 响应策略

检测到异常
    │
    ├─ 低置信度：记录日志，上报云端
    ├─ 中置信度：限制可疑 ECU 权限，发送告警
    └─ 高置信度：隔离受影响域，触发降级模式，紧急上报

4. 安全启动链（Secure Boot）

安全启动确保只有经过授权的固件才能运行：

Boot ROM（不可修改）
    │ 验证 Bootloader 签名（公钥内置）
    ↓
Bootloader（已验证）
    │ 验证 OS/内核签名
    ↓
操作系统（已验证）
    │ 验证应用程序签名
    ↓
应用程序（已验证运行）

关键技术：

Root of Trust：不可篡改的基础信任锚点（Boot ROM 中的公钥哈希）
代码签名：ECDSA-256 或 RSA-2048 对固件签名
回滚保护：单调计数器防止降级到有漏洞的旧版本

5. 硬件安全模块（HSM）

HSM 是专用安全协处理器，提供：

功能	说明
密钥存储	密钥永不离开 HSM，只暴露计算结果
加密运算	AES/ECC/RSA 硬件加速
随机数生成	真随机数源（TRNG）
安全存储	防篡改 Flash 存储
安全计数器	Freshness Value 的可信源

典型 HSM 集成路径：SHE（Secure Hardware Extension）或完整 HSM（如 Renesas RH850/P1x HSM、英飞凌 AURIX HSM）。

6. OTA 更新体系

6.1 FOTA vs SOTA

类型	说明	典型内容
FOTA（Firmware OTA）	更新 ECU 固件	底盘 ECU、执行器固件
SOTA（Software OTA）	更新高层软件	算法模型、配置参数、应用程序
DOTA（Data OTA）	更新数据	高精地图、NLU 词库、规则库

6.2 OTA 系统架构

云端 OTA 后台
    │
    │  ① 创建升级包（签名/加密）
    │  ② 版本管理与兼容性校验
    │  ③ 灰度策略配置
    ↓
T-Box（车端接收网关）
    │
    │  ④ 下载（分块、断点续传）
    │  ⑤ 完整性校验（哈希比对）
    │  ⑥ 签名验证
    ↓
OTA Manager（升级管理器）
    │
    │  ⑦ 版本依赖检查
    │  ⑧ 触发时机判断（停车/低速/充电）
    │  ⑨ 协调各 ECU 升级顺序
    ↓
目标 ECU
    │
    │  ⑩ A/B 分区切换
    │  ⑪ 健康检查
    │  ⑫ 成功/失败上报

6.3 A/B 分区切换

存储布局：
┌─────────────────────────────────────────┐
│  Bootloader   │  分区 A    │  分区 B    │
│  (只读)       │  (当前运行) │  (待更新) │
└─────────────────────────────────────────┘

升级流程：
  1. 将新固件写入分区 B（不影响当前运行）
  2. 验证分区 B 完整性
  3. 设置启动标志指向分区 B
  4. 重启，从分区 B 启动
  5. 健康检查通过 → 确认分区 B 为主分区
  6. 健康检查失败 → 自动回滚到分区 A

回滚保护要求

"可回滚"应作为 OTA 的强制设计条件，而非可选功能。L3+ 级别系统要求无论在任何中断情况下（断电、网络中断）都能安全恢复。

6.4 OTA 安全保障

包签名：厂商私钥签名，车端公钥验证
传输加密：TLS 1.3 加密传输通道
完整性校验：SHA-256 哈希对比
版本锁：不允许降级到低于最小安全版本的固件
授权控制：仅在安全状态（停车、充电）下执行关键 ECU 升级

7. 灰度发布策略

7.1 分层发布模型

阶段 0：内部测试车队（10–50 辆）
    ↓ 通过门禁
阶段 1：受控用户（0.1%，~1000 辆）
    ↓ 通过门禁
阶段 2：扩大灰度（5%，按区域/车型）
    ↓ 通过门禁
阶段 3：大规模发布（50%）
    ↓ 通过门禁
阶段 4：全量（100%）

7.2 门禁指标

每个发布阶段应监控以下指标，不通过则暂停：

指标	说明	红线
OTA 成功率	升级完成比例	< 99% 则暂停
回滚触发率	健康检查失败率	> 0.1% 则暂停
关键故障码增长	升级后新增 DTC	任何新增安全级别 DTC 则暂停
接管率变化	升级后 ADAS 接管率	> 基线 10% 则暂停
用户投诉率	NPS 相关指标	异常上升则暂停

8. 合规要求

8.1 ISO/SAE 21434 网络安全工程

ISO/SAE 21434 定义汽车网络安全工程框架，覆盖：

TARA（Threat Analysis and Risk Assessment）：威胁识别与风险评估
概念阶段：安全目标与安全需求定义
产品开发：安全设计、验证与测试
运营阶段：漏洞监控与事件响应
退役阶段：密钥吊销与数据清除

8.2 UN Regulation R155/R156

联合国车辆网络安全（R155）和 OTA（R156）法规：

R155：整车制造商须建立并维护网络安全管理体系（CSMS）
R156：OTA 更新须有型式认证，包含版本验证、回滚机制、用户告知

中国合规要求

中国对应标准：GB/T 38628（车载信息安全技术要求）、MIIT 智能网联汽车数据安全规定。企业须同时满足国内外法规要求。

9. 安全事件应急响应

发现漏洞/攻击
    │
    ├─ 漏洞严重性评估（CVSS 评分）
    │
    ├─ 高危：48 小时内发布热补丁（Hotfix OTA）
    │        通知监管部门（视法规要求）
    │
    ├─ 中危：纳入下个维护版本（2–4 周）
    │
    └─ 低危：纳入常规版本迭代

事件溯源：
    - 通过安全日志分析攻击路径
    - 车端 Secure Logging（防篡改日志）
    - 云端 SIEM 系统分析

10. 运维指标体系

指标	计算方式	建议目标
OTA 成功率	成功升级 / 发起升级总数	> 99.5%
回滚触发率	触发回滚 / 升级总数	< 0.1%
升级后 7 天故障率变化	(升级后故障率 - 基线) / 基线	< +5%
安全事件平均响应时间	发现到处置完成时间	< 24h（高危）
证书更新成功率	车端证书轮换成功比例	> 99.9%
MTTR（平均修复时间）	故障发现到修复时长均值	依级别定义

参考标准

AUTOSAR SecOC 规范（AUTOSAR_SWS_SecureOnboardCommunication）
ISO/SAE 21434:2021（道路车辆网络安全工程）
UN Regulation No. 155 / No. 156
ETSI EN 303 645（消费者 IoT 网络安全）
NIST SP 800-82（工控系统安全指南，参考）