4. SOME/IP身份认证：从MAC到数字签名
身份认证这件事，说白了就是回答一个问题：「你真的是你吗？」
在SOME/IP通信里，这个问题的答案直接决定了ECU能不能信任收到的消息。我参与过好几个量产项目，每次跟客户聊到安全，身份认证总是第一个被问到的点。为什么？因为如果连谁发的消息都确认不了，那加密、防重放什么的都是白搭。
4.1 基于MAC的认证：轻量级方案
先说说MAC认证。这里的MAC不是网卡地址，是消息认证码（Message Authentication Code）。
它的原理很简单：发送方和接收方共享一个密钥。发送方用这个密钥对消息计算出一个MAC值，附在消息后面。接收方收到后，用同样的密钥重新计算MAC，比对一下。如果一致，说明消息没被篡改，而且确实来自持有密钥的发送方。
核心要点：MAC认证依赖共享密钥，不依赖非对称加密。计算速度快，适合资源受限的ECU。
我在一个ADAS项目中用过这种方案。当时摄像头ECU和域控制器之间需要频繁交换图像元数据，每帧都要认证。如果用数字签名，延迟根本扛不住。最后我们选了HMAC-SHA256，效果还不错。
MAC认证的典型流程：
- 发送方组装SOME/IP消息
- 用共享密钥计算消息的MAC值
- 将MAC值填入认证头（Auth Header）
- 接收方收到后，提取MAC值，重新计算
- 比对两个MAC值，一致则通过
注意：MAC认证无法解决密钥分发问题。如果共享密钥被泄露，整个认证体系就崩了。我曾经见过一个项目，密钥硬编码在代码里，结果被逆向工程提取出来...嗯，后来他们改用了密钥协商机制。
4.2 基于数字签名的认证：更强的保障
数字签名和MAC最大的区别在于：它用非对称加密。发送方用自己的私钥签名，接收方用发送方的公钥验证。
这样做的好处很明显：私钥只有发送方知道，接收方不需要共享密钥。即使某个接收方被攻破，攻击者也拿不到私钥，无法伪造签名。
数字签名在SOME/IP中的应用场景：
- ECU固件更新：确保更新包来自OEM，不是第三方恶意注入
- 关键控制指令：比如刹车、转向这类安全攸关的消息
- 诊断会话：防止未授权的诊断操作
我记得有个项目，客户要求所有诊断请求都必须带数字签名。一开始工程师们觉得太慢了，后来我们做了性能测试，发现ECDSA签名在现在的MCU上也就几毫秒的事，完全可以接受。
我的建议：如果ECU算力够，优先选ECDSA而不是RSA。同样的安全强度下，ECDSA的签名更短，计算更快。我在一个基于Cortex-R5的平台上实测过，ECDSA P-256比RSA 2048快3倍左右。
4.3 认证头格式（Auth Header）
说了这么多，认证信息到底放在哪儿？SOME/IP协议定义了一个专门的认证头，紧跟在SOME/IP头部之后。
认证头的结构如下：
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| Auth Type | 1 | 认证类型：0x01=MAC，0x02=数字签名 |
| Auth Length | 2 | 认证数据的长度（不包括本字段） |
| Auth Value | 可变 | 实际的MAC值或数字签名 |
| Freshness Value | 4或8 | 新鲜度值，用于防重放攻击 |
这里有个细节要注意：Freshness Value。它可以是时间戳、计数器或者两者的组合。我习惯用计数器加时间戳的混合方式——计数器防止重放，时间戳防止时钟漂移导致的误判。
一个典型的带认证头的SOME/IP报文结构：
+------------------+
| SOME/IP Header | // 包含Message ID, Length等
+------------------+
| Auth Header | // 认证头
| - Auth Type | // 0x01 或 0x02
| - Auth Length | // 比如32字节
| - Auth Value | // HMAC或ECDSA签名
| - Freshness Value| // 防重放
+------------------+
| Payload | // 实际数据
+------------------+避坑指南：我曾经遇到过一个bug，工程师把Freshness Value放在了Payload里，而不是Auth Header里。结果接收方验证签名时，签名计算包含了Payload中的Freshness Value，但解析时又把它当成了普通数据...嗯，调试了两天才找到问题。记住：认证头里的字段必须参与签名计算，但接收方解析时要能正确区分。
4.4 两种认证方式的对比
到底选MAC还是数字签名？我一般这样判断：
| 对比维度 | MAC认证 | 数字签名认证 |
|---|---|---|
| 计算开销 | 低（对称加密） | 高（非对称加密） |
| 密钥管理 | 需要共享密钥 | 公钥分发即可 |
| 抗抵赖性 | 无（双方都有密钥） | 有（只有发送方有私钥） |
| 典型场景 | 高频传感器数据 | 固件更新、关键指令 |
| 认证头大小 | 小（16-32字节） | 大（64-128字节） |
你想想看，如果只是传输一个车速信号，用数字签名是不是有点大炮打蚊子？反过来，如果是OTA升级包，用MAC认证又不够安全。所以，场景决定方案。
4.5 实践中的注意事项
最后分享几个我在项目中踩过的坑：
- 签名范围要明确：认证头本身要不要参与签名计算？我的做法是：Auth Type和Auth Length不参与，Auth Value本身也不参与，但Freshness Value和Payload必须参与。这样接收方可以先解析头部，再验证签名。
- 新鲜度值的同步：如果使用计数器，发送方和接收方的计数器必须同步。我见过一个案例，ECU重启后计数器归零，导致所有后续消息都被判定为重放攻击。解决方案是在安全启动阶段做一次计数器同步。
- 性能预算：在设计阶段就要算好认证带来的延迟。比如一个100Hz的传感器信号，每次都要做ECDSA签名，那CPU可能就扛不住了。这时候要么降频，要么换MAC。
总结一下：MAC认证适合高频、低延迟的场景；数字签名适合高安全、低频的场景。认证头是SOME/IP安全的核心载体，设计时一定要考虑新鲜度值的防重放机制。选型没有绝对的对错，关键看你的系统约束和威胁模型。
下一章我们会聊SOME/IP的加密通信实现，到时候会讲到如何把认证和加密结合起来，构建一个完整的安全通道。嗯，那个更有意思。