4. 加密算法实战:Hash(SHA256)、签名(ECDSA)、MAC(CMAC)在AUTOSAR中的应用

加密算法,说白了就是安全启动的“锁”和“钥匙”。很多刚接触AUTOSAR安全的朋友,一上来就被SHA、ECDSA、CMAC这些缩写搞晕了。别急,今天我们就把它拆开揉碎了讲清楚。

我个人习惯把这三类算法比作一个快递系统:Hash是封条,确保包裹没被拆过;MAC是带锁的封条,只有知道密码的人才能验证;签名是身份证,能证明这个包裹确实是你发的。在AUTOSAR安全启动里,它们各司其职,缺一不可。

4.1 SHA256:不可逆的“指纹”

SHA256,全称是安全哈希算法,输出256位(32字节)的摘要。它的核心特性就四个字:不可逆。你没法从摘要反推出原始数据。

在AUTOSAR安全启动中,SHA256主要用来做完整性校验。比如,我们计算Bootloader镜像的哈希值,然后把这个哈希值存到安全存储区。启动时,重新计算一遍,对比一下。不一样?说明镜像被篡改了。

关键点:SHA256只保证完整性,不保证真实性。任何人都可以计算哈希,所以它不能防止“替换攻击”。

我记得有一次,一个客户问我:“我用了SHA256,为什么还是被攻击了?”我一看,他把哈希值存在了明文Flash里。攻击者改了镜像,顺手把哈希值也改了。嗯,这里要注意:哈希值必须放在安全区域,比如HSM(硬件安全模块)内部。

4.1.1 代码示例:AUTOSAR Crypto Driver调用SHA256

/* 伪代码:使用AUTOSAR Crypto Driver计算SHA256 */
Crypto_ResultType Crypto_Example_SHA256(void)
{
    uint8 data[] = {0x01, 0x02, 0x03, 0x04};
    uint8 hash[32];  /* SHA256输出32字节 */
    Crypto_JobType job;

    /* 配置Job */
    job.jobType = CRYPTO_JOB_HASH;
    job.cryptoAlgo = CRYPTO_ALGO_SHA256;
    job.inputPtr = data;
    job.inputLength = sizeof(data);
    job.outputPtr = hash;
    job.outputLength = sizeof(hash);

    /* 同步执行 */
    return Crypto_ProcessJob(&job);
}

这段代码看起来简单,但实际项目中坑不少。我曾经遇到过一个案例:HSM的DMA配置错了,导致输入数据被截断,哈希值一直对不上。排查了整整两天。

4.2 ECDSA:非对称签名的“身份证”

ECDSA(椭圆曲线数字签名算法)是AUTOSAR安全启动的核心。它解决了SHA256的“真实性”问题。你想想看,如果只有SHA256,攻击者可以伪造一个镜像,同时伪造哈希值。但有了ECDSA,攻击者没有私钥,就签不出合法的签名。

ECDSA使用一对密钥:私钥签名,公钥验签。私钥必须锁在HSM里,永远不出去。公钥可以公开,但必须保证它的真实性——通常由OEM在产线烧录时注入。

特性 SHA256 ECDSA
密钥类型 无密钥 非对称密钥对
计算速度 快 慢(尤其是签名)
安全性 防篡改(需配合安全存储) 防伪造+防篡改
典型用途 完整性校验 镜像签名与认证
实战建议:在AUTOSAR安全启动中,通常先用SHA256计算镜像摘要,再用ECDSA对这个摘要签名。这样既保证了效率,又保证了安全性。不要直接对几百KB的镜像做签名,太慢了。

4.2.1 避坑指南:曲线选择

ECDSA依赖椭圆曲线。AUTOSAR标准推荐使用NIST P-256(secp256r1)。为什么?因为大多数HSM硬件加速器都支持这条曲线。我曾经见过一个项目,用了P-384,结果HSM不支持,只能纯软件算,启动时间从200ms飙到了3秒。

所以,我的建议是:除非有特殊安全等级要求,否则无脑选P-256。

4.3 CMAC:对称的“带锁封条”

CMAC(基于密码的消息认证码)是AES的一种工作模式。它和SHA256的区别在于:CMAC需要密钥。只有知道密钥的人,才能生成和验证MAC值。

在AUTOSAR里,CMAC常用于安全通信和安全存储。比如,ECU之间的关键报文,可以用CMAC做认证,防止被篡改或重放。

但注意,CMAC是对称的。签名和验证用同一个密钥。这意味着,如果密钥泄露,整个系统就完了。所以,CMAC的密钥管理比ECDSA更严格。

重要提醒:CMAC不能用于“不可否认性”。因为通信双方都知道密钥,你没法证明某条消息到底是谁发的。需要不可否认性?请用ECDSA。

4.4 三者在AUTOSAR安全启动中的协作

说了这么多,它们到底怎么配合?我画了一张图,你看完就明白了。

AUTOSAR安全启动:Hash + 签名 + MAC 协作流程 原始镜像 SHA256摘要 ECDSA签名 私钥(HSM内部) 加载镜像 重新计算SHA256 ECDSA验签 公钥(安全存储) 验签通过? ✅ 启动正常 ❌ 进入安全模式

流程其实很清晰:

  1. 镜像准备阶段:先对原始镜像做SHA256,得到摘要。再用HSM里的私钥对这个摘要做ECDSA签名。最终,镜像和签名一起烧录到ECU。
  2. 启动验证阶段:Bootloader加载镜像,重新计算SHA256摘要。然后用预置的公钥验签。通过?启动。不通过?进入安全模式,等待刷写。
核心原则:SHA256保证完整性,ECDSA保证真实性。两者结合,才能构建可信的启动链。

4.5 CMAC在AUTOSAR中的其他应用

除了安全启动,CMAC在AUTOSAR里还有两个常见场景:

  • 安全通信(SecOC):ECU之间的CAN报文,用CMAC做认证。防止攻击者注入伪造报文。
  • 安全存储(Crypto Stack):关键数据(如密钥、配置参数)加密存储后,用CMAC做完整性校验。

我曾经在调试一个SecOC项目时,发现CMAC一直验证失败。查了半天,原来是计数器同步出了问题。SecOC的CMAC计算会包含一个新鲜度值(Freshness Value),两边计数器不同步,MAC自然对不上。嗯,这里要注意:调试CMAC时,先确认新鲜度值是否一致。

4.6 性能对比与选型建议

最后,我整理了一张性能对比表。你在做架构设计时,可以参考一下。

算法 典型耗时(HSM加速) 典型耗时(纯软件) 推荐场景
SHA256(1MB数据) 5-10ms 50-100ms 镜像完整性校验
ECDSA P-256 签名 10-20ms 200-500ms 镜像签名(产线或OTA)
ECDSA P-256 验签 5-15ms 100-300ms 启动时验签
AES-128 CMAC(1KB数据) <1ms 5-10ms 报文认证、安全存储
我的建议:如果硬件支持HSM,尽量把SHA256和ECDSA验签卸载到HSM。纯软件算ECDSA,启动时间会很难看。我见过一个项目,为了省成本没用HSM,结果启动时间超标,最后不得不换芯片,得不偿失。