4、密码学基础：对称加密（AES）、非对称加密（RSA/ECC）、哈希（SHA-2）、MAC、密钥派生与随机数生成

在AUTOSAR信息安全架构中，SecOC（Secure On-Board Communication）与HSM（Hardware Security Module）的协同工作，其底层支撑完全依赖于密码学原语的正确选型与实现。本章将系统梳理车载嵌入式环境中六类核心密码学组件：AES对称加密、RSA/ECC非对称加密、SHA-2哈希、消息认证码（MAC）、密钥派生函数（KDF）以及密码学安全随机数生成器（CSPRNG）。理解这些原语的安全属性、性能特征与典型应用场景，是设计可靠HSM固件与SecOC通信策略的前提。

4.1 对称加密：AES在SecOC与HSM中的核心地位

核心原理

AES（Advanced Encryption Standard）是当前车载嵌入式系统中最广泛使用的对称分组密码算法，分组长度固定为128位，支持128/192/256位三种密钥长度。在AUTOSAR SecOC框架中，AES-128通常用于MAC计算（CMAC模式），而AES-256则用于需要更高安全等级的密钥加密存储或安全通信信道。AES的硬件实现在HSM中通常以专用加密引擎形式存在，支持ECB、CBC、CTR、GCM等多种工作模式，其中GCM模式同时提供加密与完整性校验，适合用于安全固件升级或诊断通信。

操作流程与判断方法

在SecOC中，AES-CMAC的计算流程如下：

1. 将待保护PDU（含新鲜度值、数据ID、载荷）按128位分组填充；
2. 使用AES-128密钥K对最后一个分组进行CBC-MAC迭代运算；
3. 取MAC输出前64位（或按配置截断至32位）作为认证标签；
4. 将截断后的MAC附加到PDU尾部，组成完整SecOC帧。

选择AES工作模式时需注意：ECB模式不适合多分组数据，CBC模式需要处理IV同步，CTR模式支持并行计算但无完整性保护，GCM模式在硬件资源充足时是首选。

案例拆解：ECU间安全通信的AES-CMAC配置

某OEM在车身控制域中部署SecOC，要求网关与车门控制器之间每条CAN-FD报文增加32位MAC。初始现象：使用软件AES实现时，网关CPU占用率上升15%，报文周期抖动超过500μs。分析过程：通过HSM硬件加速后，单条报文MAC计算时间从120μs降至8μs，CPU占用率降至2%。实际操作：将AES密钥存储在HSM非易失性安全存储区，每次上电通过KDF派生会话密钥，CMAC计算完全在HSM内部完成。结果对比：报文周期抖动控制在100μs以内，满足设计要求。风险提示：密钥更新策略需与整车OTA机制联动，防止密钥泄露后的大规模重放攻击。

4.2 非对称加密：RSA与ECC在密钥管理与身份认证中的应用

核心原理

非对称加密使用公钥/私钥对，公钥可公开分发，私钥必须安全存储在HSM内部。RSA基于大整数分解难题，密钥长度通常为2048或3072位，计算开销大，适合低频次的身份认证与密钥交换。ECC（椭圆曲线密码）基于椭圆曲线离散对数难题，在相同安全强度下密钥长度更短（256位ECC约等于3072位RSA），计算效率更高，特别适合资源受限的车载ECU。在AUTOSAR体系中，ECC主要用于SecOC的签名验证（ECDSA）和TLS握手过程中的密钥协商（ECDH）。

操作流程与选择依据

在HSM中执行非对称操作时，私钥永远不离开硬件边界。典型流程：

• 密钥生成：HSM内部调用TRNG生成随机数，计算公私钥对；
• 签名生成：私钥对哈希值进行签名（RSA-PSS或ECDSA）；
• 签名验证：公钥验证签名，公钥可存储在普通Flash中但需防篡改；
• 密钥交换：ECDH协商出共享密钥，再经KDF派生为AES会话密钥。

选择RSA还是ECC，需综合考量：

案例拆解：OTA固件升级中的签名验证

某Tier1为域控制器设计OTA升级流程，要求固件包必须经过OEM根证书签名。初始方案：使用RSA-2048验证每个固件块，实测验证耗时3.2ms/块，升级100MB固件需额外等待约10分钟。优化方案：采用"哈希链+单次签名"策略——先对固件整体计算SHA-256哈希，仅对哈希值做一次RSA签名；接收端先验证签名，再逐块校验哈希。结果：签名验证时间降至4ms（一次性），整体升级时间几乎无感知。复盘经验：非对称加密应只用于保护关键摘要，而非直接加密大数据流；同时需在HSM中预置根证书公钥哈希，防止公钥被替换。

4.3 哈希函数：SHA-2系列与完整性校验

核心原理

SHA-2（Secure Hash Algorithm 2）包括SHA-224、SHA-256、SHA-384、SHA-512等变体，其中SHA-256在AUTOSAR中最常用。哈希函数将任意长度输入映射为固定长度摘要，具有单向性、抗碰撞性和雪崩效应。在SecOC中，SHA-256用于：计算新鲜度值的哈希、生成密钥派生函数的中间输入、验证固件镜像完整性。HSM中通常集成SHA-256硬件加速器，吞吐量可达1-10 Gbps。

操作流程与注意事项

使用SHA-256进行完整性校验的标准流程：

1. 发送方计算固件镜像的SHA-256摘要，并用私钥签名；
2. 接收方使用公钥验证签名，获得原始摘要；
3. 接收方重新计算本地镜像的SHA-256摘要；
4. 比对两个摘要，一致则完整性验证通过。

常见误区：将SHA-256直接当作MAC使用。哈希函数不包含密钥，攻击者可以同时修改数据和哈希值，因此必须配合签名或MAC机制。

案例拆解：SecOC新鲜度值的哈希链

某项目要求防止重放攻击，采用基于哈希链的新鲜度值管理。初始设计：使用单调计数器，但计数器溢出后需要重新同步。改进方案：发送方维护一个哈希链（H^n(seed)），每次发送前一个哈希值，接收方验证H(收到的值)是否等于上一个值。关键参数：链长10000，SHA-256计算，HSM中预存链尾值。结果：重放攻击检测率100%，且无需计数器同步。风险：链耗尽后需通过安全通道重新初始化，需设计自动重同步机制。

4.4 消息认证码（MAC）：CMAC与HMAC的工程选型

核心原理

MAC（Message Authentication Code）同时提供数据完整性验证与来源认证。CMAC（Cipher-based MAC）基于AES分组密码，适合硬件实现；HMAC（Hash-based MAC）基于SHA-2哈希，适合软件实现。在AUTOSAR SecOC规范中，CMAC-AES-128是默认推荐算法，因为其硬件开销低、延迟小。HMAC-SHA256则常用于密钥派生和TLS握手。

操作流程与对比

CMAC计算流程：将消息填充至128位倍数，使用AES-128进行CBC-MAC迭代，最后使用子密钥K1/K2处理最后一个分组。HSM中需预先生成子密钥并安全存储。

案例拆解：CAN-FD报文MAC截断长度优化

某OEM在动力域CAN-FD总线（2Mbps）上部署SecOC，初始使用64位MAC，导致有效载荷减少8字节，影响控制周期。分析：攻击者物理接触总线的概率低，且新鲜度值窗口为100ms，32位MAC在窗口内伪造概率为2^-32，可接受。优化：将MAC截断至32位，释放4字节用于扩展诊断数据。结果：控制周期从10ms降至8ms，安全风险可控。复盘：安全等级需结合物理访问难度、报文频率、攻击者能力综合评估，避免过度设计。

4.5 密钥派生函数（KDF）与随机数生成

核心原理

KDF（Key Derivation Function）从主密钥或共享秘密中派生出一个或多个安全密钥。AUTOSAR中常用HKDF（HMAC-based KDF），其核心是提取-扩展（Extract-Expand）结构。随机数生成器分为伪随机（PRNG）和真随机（TRNG），HSM必须包含TRNG作为熵源，再通过DRBG（Deterministic Random Bit Generator）扩展输出。AUTOSAR要求所有密钥生成、IV生成、nonce生成必须使用CSPRNG（密码学安全伪随机数生成器）。

操作流程与工程要求

HKDF-SHA256派生流程：

1. 提取阶段：使用HMAC-SHA256(盐, 输入密钥材料IKM)生成伪随机密钥PRK；
2. 扩展阶段：使用HMAC-SHA256(PRK, 信息+计数器)生成所需长度的输出密钥；
3. 输出密钥用于AES会话密钥、MAC密钥或新鲜度值种子。

随机数生成要求：

• TRNG必须通过NIST SP 800-90B健康测试；
• DRBG推荐使用CTR_DRBG（基于AES）或HMAC_DRBG；
• 每次上电需重新种子化，定期进行重新种子化；
• 禁止使用未加密的定时器值或ADC噪声作为唯一熵源。

案例拆解：会话密钥派生与更新策略

某网关与云端通信，需要每24小时更新TLS会话密钥。初始设计：直接使用预置主密钥加密通信。风险：主密钥泄露则所有历史通信可解密。改进：使用HKDF从主密钥派生每日会话密钥，并设置密钥更新触发条件（时间、流量阈值、安全事件）。关键参数：HKDF盐使用HSM生成的16字节随机数，信息字段包含ECU ID和日期。结果：即使某日会话密钥泄露，仅影响当日数据，主密钥安全。复盘：密钥分层管理（主密钥-会话密钥-报文密钥）是HSM设计的核心原则。

4.6 综合实践：SecOC报文保护中的密码学组件协同

完整流程

一个典型的SecOC发送端处理流程整合了本章所有密码学组件：

1. HSM的TRNG生成新鲜度值（如32位计数器+随机数）；
2. 使用AES-CMAC计算MAC，密钥由KDF从主密钥派生；
3. MAC截断后附加到PDU；
4. 接收端使用相同KDF派生验证密钥；
5. 接收端重新计算CMAC并比对；
6. 若验证失败，触发安全事件并进入降级模式。

该流程中，随机数保证新鲜度，KDF保证密钥隔离，CMAC保证完整性与认证，SHA-256用于密钥派生内部计算。任何组件的弱化都会破坏整体安全性。

常见误区总结

• 误区一：使用SHA-256代替MAC进行报文认证——缺少密钥，无法防伪造；
• 误区二：所有ECU共享同一把AES密钥——一旦单点泄露，沦陷，应使用分组密钥或每对通信节点独立密钥；
• 误区三：随机数生成使用rand()库函数——可预测，必须使用HSM的CSPRNG；
• 误区四：密钥长期不变——应设计定期更新机制，结合KDF派生临时密钥；
• 误区五：忽略HSM的侧信道防护——软件实现AES时，缓存时序可能泄露密钥，必须使用硬件引擎。

在AUTOSAR项目中，建议在系统设计阶段就明确密码学算法套件、密钥管理方案和HSM资源预算，避免后期因性能或安全缺陷进行架构级返工。通过合理组合AES、ECC、SHA-2、MAC、KDF和CSPRNG，可以构建满足ISO 21434要求的车载安全通信基础。