1. 前言
USD协议诊断主要采用“问 - 答”模式，即诊断仪像车辆指定的ECU发送请求(Request)，指定的ECU会做出相对应的响应(Response)，并将响应返回给诊断仪。从而可以依据定义好的诊断描述文件，就可以将相对应的数据转化为相对应的问题和描述。
常见的UDS服务类型可以参考
这一篇博客对UDS诊断服务功能和描述较为完整，推荐阅读。
UDS(ISO14229)诊断服务功能及描述完结篇_uds的数据存储在哪里_小趴菜詹的博客-CSDN博客
2. 29服务（Authentication）
该服务的目的是为客户提供一种证明其身份的方法，允许其访问数据或诊断服务，这部分数据或服务因安全、排放或安全原因而受到限制。 该服务致力于解决将例程或数据下载或上传到服务器并从服务器读取特定内存位置的诊断服务是可能需要身份验证的情况。不当程序或数据可能会损坏电子设备或其他车辆组件，或危及车辆遵守排放、安全或安保标准的风险。 另一方面，从服务器检索数据也可能会违反数据安全性。该服务支持两个安全概念：
1. 基于使用非对称加密的 PKI 证书交换程序。 作为证书格式，应使用符合 ISO 7816-8 的 CVC 和符合 ISO/IEC 9594-8、RFC 5280 和 RFC 5755 或 IEEE 1609.2 的 X.509。
2. 基于使用带有软件认证令牌的非对称加密或对称加密的不带 PKI 证书的请求-响应过程。
说到29服务，不得不提27服务。
27服务在汽车OTA升级中是非常常见的。
27 安全访问服务 保证是有权限的人员或者设备才能够进行刷写，安全访问服务子功能请求种子向 ECU 请求安全认证种子。
但是27安全访问服务是脆弱的。容易存在“移位计算算法简单”、“种子随机性低”、“种子长度过短”、“逆向获取计算算法”等问题。
饭饭是我的朋友，他对UDS服务有一定研究，他的这篇文章很好的讲述了他从安全的角度在研究UDS服务的一些收获。
所以，使用29服务替代27服务，29服务支持非对称算法，安全性能够得到很大的提升。即使算法泄露，也不会造成影响。
29服务的详细知识关注这篇博客：
跟我学UDS(ISO14229) ———— 0x29(Authentication)_小趴菜詹的博客-CSDN博客
3. 84服务(SecuredDataTransmission)
此请求用于传输受加密方法保护的诊断数据。为此，必须实现位于应用程序层与测试仪和ECU的应用程序之间的“安全子层”。数据根据ISO 15764（扩展数据链接安全性）进行处理。
某次，一个朋友找我看一道题目，如下。
需要从以下报文中找正确的数据标志符
0x701 10 11 84 00 61 00 00 06
0x708 30 00 00 FF FF FF FF FF
0x701 21 22 F1 22 F1 8C 22 F1
0x701 22 89 22 F1 88 FF FF FF
0x708 10 21 C4 00 20 00 00 06
0x701 30 00 00 FF FF FF FF FF
0x708 21 22 F1 62 F1 8C 62 F1
0x708 22 91 62 F1 90 62 F1 A0
0x708 23 62 F1 A1 62 F1 87 FF
0x708 22 62 F1 89 62 F1 88 FF起初没有看懂，后来根据多帧报文格式规范，定位到这是84服务(SecuredDataTransmission)，找到了正确的答案flag{F18C}。
84服务的详细知识关注这篇博客：
跟我学UDS(ISO14229) ———— 0x84(SecuredDataTransmission)_uds84服务_小趴菜詹的博客-CSDN博客
4.最后
起初，我认为UDS协议只能只能传输明文，并不设计密码学算法。后来发现并非如此，但是由于历史传统和资源耗费的问题，目前还是以一些传统UDS服务为主。