文章总结： 本文档详细介绍了UDS诊断协议中ISO14229-1标准的29服务(Authentication身份验证)，该服务在2020版本中新增，用于应对网联汽车安全风险。文档阐述了两种认证机制：基于PKI证书交换的APCE(非对称加密)和基于挑战确认的ACR(对称/非对称加密)，并详细说明了单向与双向认证流程。同时介绍了29服务的请求/响应格式、子功能参数定义及常用NRC错误码，为汽车诊断安全通信提供了技术实现参考。 综合评分： 78 文章分类： 车联网安全,安全标准,渗透测试,安全建设,其他

---

UDS诊断（ISO14229-1） 29服务

谈思实验室

2026年2月10日 19:29 上海

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

01

功能简介

29服务，即 Authentication（身份验证）服务，该服务的目的是为客户提供一种证明其身份的方法，使其能够访问出于安全等原因而限制访问的数据和/或诊断服务。

29服务是在ISO 14229-2020版本中首次增加的为应对网联汽车日益增加的安全风险的新服务。

需要认证服务保护的情况包括：调用server的例程服务，数据的上传或下载相关服务、通过诊断服务读取内存中特定地址存储的数据。

1.信息安全概念相关背景知识

• 对称加密：通信双方加密和解密使用相同的密钥
• 非对称加密：通信双方各有一对密钥，分为公钥和私钥，信息的加密使用公钥，解密使用私钥，公钥双方共享，私钥只有自己知道，以此避免消息泄露
• PKI 是Public Key Infrastructure的首字母缩写，翻译过来就是公钥基础设施；PKI的主要任务是在开放环境中为开放性业务提供基于非对称密钥密码技术的一系列安全服务，包括身份证书和密钥管理、机密性、完整性、身份认证和数字签名等。
• CVC 是指在一个在非常紧凑格式下存储的公钥证书
• X.509 是密码学里公钥证书的格式标准。X.509证书里含有公钥、身份信息(比如网络主机名，组织的名称或个体名称等)和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。
• 挑战确认（Challenge-Response） 认证流程：

1. 客户端向服务器发出认证请求；
2. 认证服务器判定用户是否合法，若不是，则不做进一步的处理；
3. 认证服务器内部产生一个随机数，作为Challenge，发送给用户；
4. 客户将口令和随机数合并，使用单向哈希函数 ( 例如MD5算法 ) 生成一个字节串作为Response；
5. 认证服务器将Response与自己的计算结果比较，如两者相同，则通过一次认证，反之认证失败；
6. 认证服务器通知客户端认证成功或失败。

2. 支持的安全概念（Security Concepts）

29服务支持两个安全概念：

1. APCE: 采用非对称加密的基于PKI证书交换程序的认证
2. ACR: 采用对称或非对称加密的基于挑战确认（Challenge-Response）流程的认证

APCE 和 ACR 的区别：

总之，APCE 这种方式是一种更加标准化的一种，目前是行业里面的主流方式。

3. APCE认证流程

上图是APCE的认证流程图，包括单向认证和双向认证。

1、单向认证流程

1. Client 通过 VerifyCertificateUnidirectional(2) 向 Server 发送带有 Client公钥 的证书。
2. Server 收到证书后会 验证证书的有效性(3) ，如果 Client 不合法，则停止流程，验证失败，返回否定响应，如果合法则继续之后的流程。
3. Server 创建Challenge(4)，并向 Client 发送针对证书的Challenge消息(7)，请求Client对所发证书的所有权证明，消息中包含认证所需的随机数。
4. Client 收到Challenge后使用私钥计算所有权证明客户端(10)，并且通过SubFunction ProofOfOwnership(11)发送所有权证明客户端。
5. Server 使用来自Client的公钥验证所有权客户端(12)，与Challenge消息比较，如果验证成功，则根据访问权限(14)，授予对诊断对象的访问权限。并向Client发送相应的响应,表示认证成功。

2、双向认证流程

1. Client 创建Challenge客户端(1)，并通过SubFuntion Vertify Certificate Bidirectional向Server发送Challenge客户端和含有公钥的证书客户端。
2. Server验证证书是否有效(3)，如果无效，则验证失败，返回否定响应。如果有效，则进行后续的流程。
3. Server创建Challenge服务端，并且通过客户端发来的Challenge和自己的私钥计算出所有权证明(6)，并向Client发送Challenge服务端、服务端证书、服务端的所有权证明以及临时公钥(7)。
4. Client根据所得的临时公钥验证服务器证书和所有权证明是否有效(8)，有效之后根据服务端发来的Challenge和客户端私钥计算客户端所有权证明(10)，并通过ProofOfOwnership向Server发送客户端所有权证明(11)。
5. Server收到所有权证明后进行验证是否通过(12)，通过后发送访问权限(14)以及相应的响应(15)，认证成功。

图中(5)，(9)跟安全诊断通信有关，(16)，(17)，(18)跟创建会话密钥有

4. ACR认证流程

上图是 ACR 的认证流程图，包括单向认证和双向认证。

ACR认证前提条件

• 非对称加密： 具有客户端密钥对：客户端存在客户端私钥，服务器中存在客户端公钥。如果是双向认证的话，还需要在服务器端加个密钥对：客户端存在服务器公钥，服务器端存在服务器私钥。
• 对称加密： 和27服务的流程相似，在客户端和服务端同时存在对称密钥。

1、单向认证流程

1. Client通过RequestChallengeForAuthentication请求验证(1)。
2. Server创建Challenge数据(2)并发送Challenge数据(3)。
3. Client计算所有权证明(5)。
4. Client通过VerifyProofOfOwnershipUnidirectional发送所有权证明(7)。
5. Server验证所有权证明(8)，如果验证成功发送访问权限。

其中(14)，(15)，(16)是关于建立会话密钥使用的。

2、双向认证流程

1. Client通过SubFunction RequestChallengeForAuthentication请求验证(1)。
2. Server创建Challenge数据(2)，并且发送Challenge数据(3)。
3. Client创建Challenge数据(4)，并且计算Client所有权证明，并通过VerifyProofOfOwnershipBidirectional发送给服务器端(7)。
4. Server验证所有权证明(8)。
5. 如果验证成功，Server计算所有权证明(9)，并且发送访问权限(11)。
6. Client验证服务器的所有权证明(13)，如果验证成功，访问成功。

02

请求和响应

1、请求

基本格式

归纳起来，诊断的request格式无非以下两种：

+ +

+

即有无sub-function的区别。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数视具体要求而定。

以 29 01 、 29 02 为例

2、子功能

子功能参数定义（1字节数据）：

Bit7：抑制肯定响应消息指示位suppressPosRspMsgIndicationBit

• 0=False：需要肯定响应
• 1=True：禁止肯定响应

Bit6-0：子功能参数值（0x00~0x7F）

3、肯定响应

基本格式：

+ +

+

要注意，第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的，具体要看协议规定。

4、否定响应

基本格式:

<0x7F> + +

看起来比较简单，格式比较固定，只要是Negative Response，第一字节就是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因

5、NRC优先级

在ISO14229-1中未明确定义NRC优先级，可以参考下方优先级顺序：

NRC 判断优先级顺序：

备注：可以使用 0x50 到 0x5D 的NRC，也可以使用通用 NRC10。

03

UDS中常用 NRC

来源：CSDN@「up up day」

https://blog.csdn.net/m0_56208280/article/details/148351908

谈思-汽车出海安全合规（欧洲）

交流群

谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台，以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流，都将通过本平台为您提供持续支持。社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。

谈思-SDV&AIDV技术出海

交流群

诚邀行业同仁加入谈思SDV&AIDV出海技术交流群，聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题，欢迎大家加群交流探讨~~社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自：

新势力车企：

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上)：

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：谈思实验室 《UDS诊断（ISO14229-1） 29服务》