UDS 31服务安全访问项目实战操作指南

UDS 31服务实战：如何用Routine Control构建高安全性的ECU访问控制

一个真实的开发困境

你正在调试某款新能源车的VCU（整车控制器），准备进行OTA升级。一切就绪后，通过诊断仪发送写Flash请求——失败。再试一次，依然被拒绝。

查看日志发现：“Access Denied: Security Access Required”。

你确认已经进入了扩展会话（Extended Session），也调用了27 01尝试标准安全解锁，但ECU根本不响应这个服务。

这时，团队里有位老工程师走过来问了一句：“他们是不是没用0x27？有没有查过31服务？”

你愣了一下：31服务不是用来跑自检或初始化内存的吗？怎么跟安全访问扯上关系了？

答案是：在很多实际项目中，尤其是涉及IP保护、防克隆、定制加密逻辑的系统里，UDS 31服务早已成为实现安全访问的核心手段之一。

今天我们就来揭开这层“非标却关键”的技术面纱——如何利用Routine Control服务（0x31）完成真正的安全解锁流程。

为什么标准0x27不够用了？

先说清楚一件事：ISO 14229-1定义的标准安全访问服务是0x27，它采用挑战-响应机制：

Tester → ECU: 27 01 // 请求进入安全访问模式 ECU → Tester: 67 01 [S] // 返回Seed Tester → ECU: 27 02 [K] // 发送计算后的Key ECU → Tester: 67 02 // 验证通过，解锁

这套流程清晰、规范、通用性强，OEM和Tier1广泛采用。那问题来了——为什么还要绕开0x27，改用31服务？

因为现实世界比标准复杂得多

1. 需要绑定硬件特征值
   比如你的算法要结合HSM输出的UID + 当前时间戳 + Seed生成Key，而0x27的数据字段太固定，无法传递这些动态参数。

2. 想做双因素认证
   不只是“我知道什么”（密钥），还要“我拥有什么”（设备唯一性）。这时候你需要自定义流程，把VIN、序列号等信息作为输入参与验证。

3. 防止逆向工程
   标准0x27容易被诊断工具自动探测破解。而使用31服务配合私有例程ID，相当于“隐藏入口”，提升攻击门槛。

4. Bootloader阶段资源受限
   在刷写初期，完整的UDS协议栈还没加载，但又要实现基本的身份认证。此时精简版的31服务更灵活，代码量小，易于集成。

所以你看，31服务虽然名义上叫“例行控制”，但在安全场景下，它其实是“可编程的安全门禁”。

Routine Control服务的本质是什么？

我们回到ISO标准对Service 0x31的定义：

“用于启动、停止或查询ECU内部某个特定例程的执行状态。”

听起来很普通？别急，重点在于那个词：“特定例程”。

你可以把它理解为——一段可以被外部触发的专用函数，就像API接口里的endpoint。

它的请求格式非常简洁：

[0x31] [Sub-function] [Routine ID (2 bytes)] [Optional Data]

支持三种操作：
-0x01Start Routine —— 启动任务
-0x02Stop Routine —— 停止任务（少见）
-0x03Request Routine Results —— 查询结果

比如你要让ECU执行一次ADC校准，就可以发：

31 01 0100

其中0x0100是你自己定义的“ADC Calibration”例程ID。

而在安全访问中，常见的两个私有例程是：

这两个看似简单的功能，组合起来就是一套完整的挑战-响应认证体系。

它是怎么工作的？一步步拆解真实流程

假设你现在要为一个车身控制器（BCM）设计安全访问机制，目标是在允许修改标定参数前完成身份验证。

第一步：生成Seed（启动例程）

诊断仪发送：

31 01 0201

表示：“请启动ID为0x0201的例程——生成种子”。

ECU收到后，调用随机数生成器（最好来自TRNG硬件模块），得到一个4字节随机值，例如：

Seed = 0xA5, 0x3C, 0x8E, 0x1F

然后缓存到RAM，并返回正响应：

71 01 0201

注意：这里不直接带回Seed数据。想要获取结果，必须下一步主动查询。

第二步：读取Seed结果

诊断仪再发：

31 03 0201

意思是：“我要查询刚才那个例程的执行结果”。

ECU检查该例程是否已完成，若成功，则将Seed打包进响应：

71 03 0201 A5 3C 8E 1F

到这里，挑战部分完成。

第三步：客户端计算Key

假设你们约定的算法是：

Key = Seed XOR 0x5A5A5A5A

那么：

A5 ^ 5A = FF 3C ^ 5A = 66 8E ^ 5A = D4 1F ^ 5A = 45 → Key = FF 66 D4 45

第四步：提交Key验证

诊断仪发送：

31 01 0202 FF 66 D4 45

即：“启动验证例程，并传入这4个字节作为参数”。

ECU端执行以下逻辑：

if (memcmp(input_key, expected_key, 4) == 0) { g_security_level = SECURITY_LEVEL_3; // 提升权限 return POSITIVE_RESPONSE; } else { increment_attempt_counter(); // 计数+1 return NRC_INCORRECT_KEY; }

如果匹配成功，标志位设置，后续即可开放WriteDataByIdentifier(0x2E)、WriteMemoryByAddress(0x3D)等敏感服务。

关键设计细节：别让一个小坑毁掉整个系统

我在多个项目中见过因细节疏忽导致的安全漏洞或产线卡顿。以下是几个必须注意的实战要点。

1. Seed不能重复！否则等于裸奔

曾经有个项目，Seed每次都是0x12345678，为什么？

因为开发人员写了这么一行代码：

rand(); // 忘记赋初值

没有调用srand()，PRNG每次都从同一个种子开始，结果完全可预测。

✅ 正确做法：

srand(GetSystemTick() ^ ReadTemperatureNoise() ^ GetHardwareJitter()); GenerateRandomBytes(seed, 4);

尽可能引入物理噪声源，哪怕是ADC采样GPIO浮空电压也好。

2. 字节序问题能让你怀疑人生

你在PC上用Python算出Key是FF 66 D4 45，发给ECU却失败。

排查半天才发现：ECU是大端模式，你传进去的是小端排列！

比如你发的数据是：

[FF][66][D4][45]

但ECU interpret 成：

0xFF66D445 vs 0x45D466FF

完全不同。

🔧 解决方案：
- 明确文档中规定字节传输顺序（通常按MSB→LSB）
- 在处理时统一转换为主机字节序
- 或干脆使用数组逐字节比较，避免整型强转

3. 输入长度必须校验

别以为发过来的数据一定完整。CAN总线可能丢帧、诊断仪可能截断。

务必检查inputLen：

if (subFunc == 0x01 && routineId == ROUTINE_ID_VERIFY_KEY) { if (inputLen < 4) { SendNegativeResponse(NRC_INVALID_FORMAT); return; } // 继续验证 }

否则攻击者发个31 01 0202不带数据，可能导致内存越界读取。

4. 安全计数器必须持久化

连续输错3次就锁住？听起来合理。

但如果重启一下就好了呢？那这个防护形同虚设。

✅ 必须将尝试次数写入EEPROM或Flash备份区：

uint8_t g_auth_retry_count; void increment_attempt_counter(void) { g_auth_retry_count++; EEPROM_Write(ADDR_RETRY_COUNT, &g_auth_retry_count, 1); } void OnPowerUp_Init(void) { EEPROM_Read(ADDR_RETRY_COUNT, &g_auth_retry_count, 1); }

并且建议加入递增延迟机制：
- 第1次错误：等待1秒
- 第2次错误：等待5秒
- 第3次及以上：30秒甚至更长

既防暴力破解，也不影响正常调试效率。

实战案例：OTA升级中的双因素认证

这是我现在负责的一个项目的真实架构。

车辆发起远程升级时，云端服务器不会直接下发固件，而是先走一轮身份认证。

流程如下：

1. 车端进入Programming Session
2. 发送31 01 0201获取Seed
3. 结合以下三项生成Key：
   - Seed（动态挑战）
   - VIN（车辆唯一标识）
   - ECU Serial Number（硬件指纹）
4. 将Key上传至TSP云平台验证
5. 验证通过后，才允许下载并刷写固件

这样即使有人截获了通信报文，也无法复现Key，因为缺少VIN和SN这两个“实体因子”。

这种设计本质上就是基于31服务的轻量级双向认证协议，成本低、安全性高，特别适合资源有限的MCU环境。

如何调试？推荐这几套工具链

1. CANoe + CAPL脚本自动化测试

编写一个CAPL函数，一键完成整个流程：

msTimer t_seed; on key 'F8' { output(EncodeByte(0x31, 0x01, 0x02, 0x01)); // 请求生成Seed setTimer(t_seed, 100); } on timer t_seed { output(EncodeByte(0x31, 0x03, 0x02, 0x01)); // 读取Seed }

还可以用CAPL解析接收到的Seed，本地计算Key，再自动发送验证请求，极大提升调试效率。

2. Python + python-can 快速验证算法

适合在办公室快速模拟客户端行为：

import can import time bus = can.interface.Bus(channel='can0', bustype='socketcan') def send_request(data): msg = can.Message(arbitration_id=0x7E0, data=data, is_extended_id=False) bus.send(msg) # Step 1: Start Generate Seed send_request([0x31, 0x01, 0x02, 0x01]) time.sleep(0.1) # Step 2: Read Result send_request([0x31, 0x03, 0x02, 0x01]) time.sleep(0.1) # Step 3: Submit Key (example) key = [0xFF, 0x66, 0xD4, 0x45] send_request([0x31, 0x01, 0x02, 0x02] + key)

搭配Wireshark或CANalyzer抓包，能迅速定位协议层问题。

3. 添加运行时日志打印（仅限调试版）

在关键节点加log输出：

printf("[SEC] Start Routine 0x%04X, Sub=%02X\n", routineId, subFunc); if (routineId == 0x0201 && subFunc == 0x01) { printf("[SEC] Generated Seed: %02X %02X %02X %02X\n", seed[0], seed[1], seed[2], seed[3]); }

注意：正式量产版本必须关闭此类日志，防止信息泄露。

最佳实践总结：写出稳定又安全的31服务逻辑

还有一个重要提醒：不要滥用31服务代替0x27。

如果你的产品要通过主机厂的诊断一致性测试（DCM Conformance Test），那么主路径仍然应该优先使用标准0x27服务。31服务更适合作为补充机制，用于实现差异化安全策略。

写在最后：掌握这项技能意味着什么？

当你能在Bootloader中用31服务实现带HSM签名的认证流程，
当你能用CAPL脚本一键跑通整套安全解锁+刷写动作，
当你的固件不再轻易被拷贝、篡改、仿制……

你就不再是只会调API的初级开发者，而是真正理解汽车电子安全底层逻辑的系统级工程师。

而这一切的起点，也许只是搞懂了这一条看似普通的诊断命令：

31 01 0201

如果你在实现过程中遇到了其他挑战，欢迎在评论区分享讨论。