AUTOSAR Cybersecurity（网络信息安全）

随着汽车智能化、网联化与 OTA 的普及，车载 ECU 的安全威胁日益突出。AUTOSAR 针对 Classic 平台引入了完整的安全机制（AUTOSAR Cry-Sec / SecOC / E2E / CSM 等），并在 AUTOSAR Adaptive 中提供更完整的网络安全能力。本笔记梳理 Classic 平台下的网络安全核心概念与实践。

1. 为什么需要 Automotive Cyber 安全

车载系统遭受的安全威胁（攻击面）包括：

无线/远程攻击：蓝牙、Wi-Fi、蜂窝（4G/5G）、V2X、NFC。
总线攻击：通过 CAN/LIN/Ethernet 注入伪造报文、重放攻击。
OBD 端口：外部诊断工具（如刷写、标定工具）被滥用。
盗密/窃听：读取密钥、固件逆向、篡改标定。
OTA 风险：恶意固件升级。

后果：车辆被盗、数据泄露、安全功能失效（刹车/转向）、隐私泄露，甚至远程控制车辆。

因此 ISO/SAE 21434（汽车网络安全工程）与 UNECE R155/R156（网络安全与软件更新）已成为法规强制要求，AUTOSAR 的安全组件是落地这些要求的技术基础。

2. AUTOSAR 网络安全分层/组件

AUTOSAR 提供了三个层面的安全支撑：

┌────────────────────────────────────────────────────────────┐
│        应用层（SWC 算法/加密生态调用）                 │
├────────────────────────────────────────────────────────────┤
│   CSM（Crypto Service Manager，密码服务管理）           │
├────────────────────────────────────────────────────────────┤
│   E2E（End-to-End Protection，端到端保护）              │
│    SSeOC（Secure Onboard Communication，安全板通信）     │
├────────────────────────────────────────────────────────────┤
│ 通信栈（CanIf/Com/Eth） + NvM（安全存储）            │
├────────────────────────────────────────────────────────────┤
│   Crypto Driver（Crypto_M/安全硬件如 HSM/TEE）       │
└────────────────────────────────────────────────────────────┘

2.1 Crypto Driver（密码学驱动）

直接对接 MCU 的密码学硬件（HSM/Hardware Security Module、Secure Element、TEE、加密引擎）或软件实现。
提供对称/非对称加密、哈希、签名、随机数生成（TRNG）等原语。
将硬件能力抽象为统一的 API（Crypto 模块规范，如 Crypto_Encrypt/Decrypt/GenerateMAC/Signature）。

2.2 CSM（Crypto Service Manager）

为上层（应用 SWC）和 BSW 提供统一的密码学服务（加密、解密、MAC、签名、散列）。
管理：key（密钥）的生成、绑定、生命周期；CRYINIT 等。
常见能力：Encrypt、Decrypt、GenerateMAC、VerifyMAC、GenerateSignature、VerifySignature、Hash、Random。
上层通过 RTE/确定性接口 调用。

2.3 E2E（End-to-End Protection，端到端保护）

保护网络/总线上的信号完整性，防篡改、防重放、防丢/乱序。
在发送端计算并附加 CRC + 计数器（Counter）+ 数据 ID，接收端验证。
典型保护状态（E2E state）：__OK / __REPEATED / __WRONGCA / __RESET / __NOE 等。
常用于安全关键 ECU 通信（如加速度、转向、油门等）。

2.4 SecOC（Secure On-board Communication）自

专门针对安全板上通信（总线报文）的认证保护，防止伪造 & 重放。
流程：
1. 发送方使用密钥（Key / 自同步序列 Freshness（新鲜度））计算 MAC（Message Authentication Code）。
2. 将 MAC + freshness 附加到 PDU。
3. 接收方用相同密钥数据重新计算 MAC 并校验，识别非法/重放报文。
需要 SecOC 密钥管理（Key DB） 与 Freshness（新鲜度计数器/时间戳），并与网络管理、BSS 紧密配合。

3. 密钥管理

网络安全密钥（SecKey）保存在安全存储（HSM 内部 Key Store、NvM 安全区域、防伪区）。
密钥生命周期：生成 → 分发 → 使用 → 更新/轮换 → 撤销。
支持证书（X.509）与 PKI，用于安全启动（SecureBoot）验证固件签名，以及安全刷写（OTA 固件签名验证）。
KMS（Key Management System）：远程密钥/证书管理，配合 OTA 与云端安全。

4. 安全启动（Secure Boot）与安全刷写（Secure Flash）

4.1 安全启动（Secure Boot）

RoT（Root of Trust）：上电首先执行不可更改的代码（安全固件 Boot ROM）。
逐级验证：BootROM → Bootloader（验证签名）→ 应用（验证签名）。
任何环节签名验证失败则拒绝执行（进入恢复/安全模式），防止恶意固件注入。

4.2 安全刷写（Secure OTA）

固件镜像带数字签名（基于 PKI/证书），Dcm 加 安全访问（0x27）。
校验完整性（CRC/HMAC）与来源合法性（签名验证）。
结合版本回滚保护（Rollback protection，防止降级到有漏洞版本）。

5. SecOC 实现细节（重要）

Freshness（新鲜度/新鲜值）：
- 单调递增计数器或时间戳，防重放攻击。
- 可以是全局共享（同一网络同一计数器）或每 ECU 独立。
MAC 计算：消息体 + 新鲜度值通过密钥（AES-CMAC、GMAC）计算。
Sec-Ocm（Secure OCM）：实际 A/SIG 分发（PDU 传递时携带）。

接收方流程：

收到报文-> 提取 freshness + MAC-> 重放校验（freshness 是否在合法窗口）-> 密钥校验 MAC == 重新计算值？-> 通过 => 接收并送入上层；失败 => 丢弃/告警/进入降级

6. 与本方案中其他模块的关系

模块	作用
EcuM	安全启动、生命周期管理
NvM / 安全区	存储密钥、证书、新鲜度计数器
Dcm	叠加安全访问（0x27）、刷写签名验证、更新安全
加密（CSM/Crypto）	提供加解密、签名、MAC 原语
RTE/COM	传递带安全保护的数据（SecOC 附加在 PDU）