本文主要是介绍UDS关于0x29认证服务诊断签名与验签(一)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1.服务介绍
该服务的目的是为客户提供一种证明其身份的方法，使其能够访问出于安全、排放或安全等原因而限制访问的数据和/或诊断服务。用于将例程或数据下载/上传到服务器以及从服务器读取特定内存位置的诊断服务可能需要身份验证。不适当的例程或下载到服务器的数据可能会造成潜在的损害。
此服务支持两个安全概念：
1.基于PKI证书交换过程，使用非对称加密(证书格式可采用ISO 7816-8标准的CVC和ISO/IEC 9594-8标准的X.509、RFC 5280和RFC 5755或IEEE 1609.2标准。
2.基于没有PKI证书的质询-响应过程，使用带有软件认证令牌的非对称加密或对称加密
2.PKI证书交换认证(APCE)
Authentication服务用于认证、去认证和显式证书传输。' authenticationTask '子函数参数标识要处理的相应任务。
"deAuthenticate "，此子函数参数主动结束已验证状态。
"verifyCertificateUnidirectional"，此子函数参数启动单向认证过程，仅针对服务器对客户端进行认证。
"verifyCertificateBidirectional"，这个子函数身份验证过程对客户端和服务器对客户端进行身份验证。参数提升者双向的.
"proofOfOwnership"，此子函数参数用于向clint传输所有权证明数据。
"transmitCertificate"，此子函数参数独立传输证书或在之前的认证之后传输证书。
反式先决条件:
双方(客户端和服务器端)均应提供不同的证书集(以及相应的私钥):
在单向身份验证的情况下，客户端需要一个带有其私钥的证书客户端，它允许客户端将自己标识为合法客户端。根据公钥基础设施(PKI)的信任模型，服务器可能需要颁发并签署证书客户机的证书颁发机构(CA)的证书。
在双向身份验证的情况下，客户端需要一个带有其私钥的证书客户端，这允许客户端将自己
标识为合法客户端。此外，服务器还需要一个带有其私钥的证书服务器，它允许服务器将自
己标识为合法服务器。根据公钥基础设施(PKI)的信任模型，客户机和服务器可能需要颁发并
签署证书客户机和证书服务器的证书颁发机构(CA)的证书。
“verifyCertificateBidirectional”分两个步骤进行，如图所示：
单向认证:
如果在所有权证明客户端(1)中使用，客户端创建挑战客户端。
建议根据ISO/IEC 9798-3(单边，两道)创建质询身份验证)或作为ISO/IEC 9798-3中与安全相关的等效挑战。
客户端发送其证书客户端，如果在(1)中生成，则通过子函数verifyCertificateUnidirectional(2)发送其挑战客户端。
服务端验证证书客户端(3)。
服务端创建一个挑战服务器(4)。
如果客户端在(2)中表示会话密钥建立基于临时Diffie-Hellman密钥协议，则服务器生成一个临时私钥/公钥对，以便随后派生会话密钥以进一步安全通信(5)。
注意： 如果证书中使用的算法仅可用于签名计算，但不能用于密钥协议，则必须使用Diffie-Hellman密钥协议。
服务端发送挑战服务端，如果在(5)中生成，则发送其临时公钥(7)。
如果客户端在(2)中表示基于临时Diffie-Hellman密钥协议建立会话密钥，那么客户端也会生成一个临时私钥/公钥对，以便随后派生会话密钥以进一步安全通信(9)。
注意：如果证书中使用的算法仅可用于签名计算，但不能用于密钥协议，则必须使用Diffie-Hellman密钥协议。
客户端通过构建一个适当的身份验证令牌来计算所有权证明，该令牌的内容至少包括(部分)质询服务端，如果在(9)中生成，则包括其临时公钥(10)。
建议基于ISO/IEC 9798-3(单边、两次通过的身份验证)构建身份验证令牌，或者作为与ISO/IEC 9798-3中的身份验证令牌的安全相关的等效身份验证令牌。
客户端发送所有权证明，如果在(9)中生成，则通过子函数proofOfOwnership(11)发送其临时公钥。
服务端用收到的证书客户端(12)的公钥验证所有权证明客户端。
如果客户端在(2)中指示会话密钥建立，则服务端创建或派生并启用用于进一步安全通信的会话密钥，并设置会话密钥信息(13)。
服务端根据访问权限(14)授予对诊断对象的访问权限。
服务端响应身份验证成功，如果在(13)中存在，则发送会话密钥信息(15)。
如果客户端在(2)中指示建立会话密钥，则客户端从会话密钥信息中提取会话密钥或派生会话密钥以进一步安全通信(16)。
如果客户端在(2)中指示建立会话密钥，则客户端使用会话密钥(17)验证会话密钥信息。
注意：步骤(17)确保会话密钥建立是完整和有效的。
如果客户端在(2)中指示建立会话密钥，则客户端启用会话密钥以进行进一步的安全诊断通信(18)。
注意：当使用单向身份验证时，服务器不针对客户端进行身份验证。因此，客户机不能确定它正在与正确的服务器通信。
双向认证:
客户端创建挑战客户端(1)，并通过子函数verifyCertificateBidirectional(2)将其与证书客户端一起发送。
服务端验证证书客户端(3)。
服务端创建一个挑战服务器(4)。
如果客户端在(2)中表示会话密钥建立基于临时Diffie-Hellman密钥协议，则服务端生成一个临时私钥/公钥对，以便随后派生会话密钥以进一步安全通信(5)。
注意：如果证书中使用的算法仅可用于签名计算，但不能用于密钥协议，则必须使用Diffie-Hellman密钥协议。
服务端通过构建一个适当的身份验证令牌来计算一个所有权证明服务端，该令牌要签名的内容至少包括(部分)挑战客户端，如果在(5)中生成，则包括其临时公钥(6)，并将其与挑战服务端、其证书服务端以及(5)中生成的临时公钥(7)一起发送。
建议基于ISO/IEC 9798-3(相互的、三次通过的身份验证)构建身份验证令牌，或者作为ISO/IEC 9798-3中与安全相关的等效身份验证令牌。
客户端使用收到的证书服务端(8)的公钥验证证书服务端和所有权证明服务端。
如果客户端在(2)中表示基于临时Diffie-Hellman密钥协议建立会话密钥，那么客户端也会生成一个临时私钥/公钥对，以便随后派生会话密钥以进一步安全通信(9)。
注意：如果证书中使用的算法只能用于签名计算，而不能用于密钥协议，则必须使用Diffie-Hellman密钥协议。
客户端通过构建一个适当的身份验证令牌来计算所有权证明，该令牌的内容至少包括(部分)质询服务端，如果在(9)中生成，则包括其临时公钥(10)。
建议基于ISO/IEC 9798-3(相互的、三次通过的身份验证)构建身份验证令牌，或者作为ISO/IEC 9798-3中与安全相关的等效身份验证令牌。
客户端发送所有权证明，如果在(9)中生成，则通过子函数proofOfOwnership(11)发送其临时公钥。
服务端用收到的证书客户端(12)的公钥验证所有权证明客户端。
如果客户端在(2)中指示会话密钥建立，则服务端创建或派生会话密钥为进一步的安全通信启用会话密钥，并设置会话密钥信息(13)。
服务端根据访问权限(14)授予对诊断对象的访问权限。
服务端响应身份验证成功，如果在(13)中存在，则发送会话密钥信息(15)。
如果客户端在(2)中指示建立会话密钥，则客户端从会话密钥信息中提取会话密钥或派生会话密钥以进一步进行安全通信(16)。
如果客户端在(2)中指示建立会话密钥，则客户端使用会话密钥(17)验证会话密钥信息。
注意：步骤(17)确保会话密钥建立是完整和有效的。
如果客户端在(2)中指示建立会话密钥，则客户端启用会话密钥以进行进一步的安全诊断通信(18)。
如果每次验证都成功，服务端应允许客户端访问证书中信息所引用的诊断服务，并向客户端响应一个肯定的响应。如果在此过程中的任何一点验证失败，服务端或客户端将停止验证处理并发送适当的响应。客户端应显示适当的信息(见外部测试设备规范)。
注意：失败尝试的管理(例如，最大尝试次数，延迟等)由车辆制造商自行决定。
注意：在客户端认证失败的情况下，特别是在服务端已经接受了客户端并设置了访问权限之后，客户端可以选择向服务端发送子函数“deAuthenticate”，以确保服务端离开认证状态并拒绝进一步的未经授权的请求。访问控制是车辆制造商的责任。
在本小节中以任何方式建立的会话密钥在经过认证的会话期间最长有效。
要独立传输证书或在之前的身份验证之后传输证书，可以使用子函数“transmitCertificate”。这个子函数的目的是向服务端提供一个证书以供进一步处理，而不需要任何质询响应序列。该证书可用于额外的权利激活或证明签名的数据(使用证书的嵌入式公钥)。因此需要使用相应的私钥对数据进行签名(数据和签名需要独立发送到服务端)。
对于每个用例，例如额外的权限激活，应提供不同的certifateevaluationld以允许服务端识别证书。此子函数可用于支持一种以上的证书。
注意:通过证书增加权利的机制由车辆制造商自行决定。
ACR (Challenge-Response)认证
先决条件:
在使用非对称加密的情况下，需要存在一个客户端密钥对:客户端私钥存在于客户端，客户端公钥存在于服务端。在双向认证的情况下，应该存在一个额外的服务端密钥对:服务端私钥应该存在于服务端中，服务端公钥应该存在于客户端中。
在使用对称加密的情况下，必须存在一个对称密钥，并在客户端和服务器之间进行预共享。
单向认证:
客户端通过子函数requestChallengeForAuthentication请求身份验证，指示要使用的算法以及是否建立会话密钥(1)。
服务器创建质询服务器(2)。
服务器发送挑战服务器和是否需要提供额外参数的指示(3).
如果在所有权证明客户端(4)中使用，则客户端创建挑战客户端。
建议创建基于ISO/IEC 9798-2或ISO/IEC 9798-4(单边、两路认证)的质询，或作为与ISO/IEC 9798相关的与安全相关的等效质询。
客户端计算客户端所有权证明(POWN)如下(5)所示:
在使用非对称加密的情况下:构建一个适当的(特定于汽车制造商的)令牌(例如基于CVC)内容，其中包含令牌授权、身份验证、权限/角色、服务器端挑战信息，以及客户端挑战信息和其他信息，使用客户端私钥计算令牌内容签名，并构建包含令牌内容和签名的客户端身份验证令牌。得到的客户端身份验证令牌是客户端POWN。
建议基于ISo/IEC 9798-2或ISo/IEC 9798-4(单边、两次通过的身份验证)构建身份验证令牌，或者作为与ISo/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
在使用对称加密的情况下:计算服务器端挑战的签名(例如一次性签名或HMAC或CMAC、GMAC)，并且在这种情况下可能是客户端挑战信息和使用预共享对称密钥的附加参数(例如车辆制造商预定义的权限/角色)。生成的签名是客户端POWN。
建议基于IsO/IEC 9798-2或IsO/IEC 9798-4(单边、两次通过的身份验证)构建身份验证令牌，或者作为与IsO/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
如果服务器在(3)中指定了附加参数，则客户端在需要的附加参数(6)中提供相应的附加参数。
客户端发送客户端POWN，如果在(4)中生成，则发送挑战客户端，如果指明，则发送需要额外的参数通过子函数verifyProofOfOwnershipUnidirectional(7)。
服务器验证客户端POWN(8)。
如果客户端在(1)中指示会话密钥建立，则服务器创建或派生并启用用于进一步安全通信的会话密钥，并设置会话密钥信息(10)。
服务器根据访问权限(11)授予对诊断对象的访问权限。
服务器响应认证成功，如果存在，则发送会话密钥信息(12)。
如果客户端在(1)中指示建立会话密钥，则客户端从会话密钥信息中提取会话密钥或派生会话密钥以进一步进行安全通信(14)。
如果客户端在(1)中指示会话密钥建立，则客户端使用会话密钥(15)验证会话密钥信息。
注意：步骤(15)确保会话密钥建立是完整和有效的。
如果客户端在(1)中指示建立会话密钥，则客户端启用会话密钥以进行进一步的安全诊断通信(16)。
双向认证:
客户端通过子函数requestChallengeForAuthentication请求身份验证，指示要使用的算法以及是否建立会话密钥(1)。
服务器创建质询服务器(2)。
服务器发送挑战服务器和是否需要提供额外参数的指示(3).
客户端创建挑战客户端(4)。
客户端计算客户端所有权证明(POWN)如下(5)所示:
在使用非对称加密的情况下:构建一个适当的(特定于汽车制造商的)令牌(例如基于CVC)内容，其中包含令牌授权、身份验证、权限/角色、服务器端挑战信息，以及客户端挑战信息和其他信息，使用客户端私钥计算令牌内容签名，并构建包含令牌内容和签名的客户端身份验证令牌。得到的客户端身份验证令牌是客户端POWN。
建议基于ISO/IEC 9798-2或ISO/IEC 9798-4(相互的、三次通过的身份验证)构建身份验证令牌，或者作为与ISO/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
在使用对称加密的情况下:计算服务器端挑战上的签名(例如一次性签名或HMAC或CMAC或GMAC)，并且在这种情况下可能是客户端挑战信息和使用预共享对称密钥的附加参数(例如车辆制造商预定义的权限/角色)。生成的签名是客户端POWN。
建议基于ISO/IEC 9798-2或ISO/IEC 9798-4(相互的、三次通过的身份验证)构建身份验证令牌，或者作为与ISO/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
如果服务器在(3)中指示了其他参数(特定于车辆制造商)，则客户端在需要的附加参数中提供适当的附加参数(6)。
客户端通过子函数verifyProofOfOwnershipBidirectional(7)发送客户端POWN、挑战客户端以及所需的附加参数。
服务器验证客户端POWN(8)。
服务器计算服务器端所有权证明(POWN)如下(9)所示:
在使用非对称加密的情况下:构建一个适当的(特定于汽车制造商的)令牌内容，其中包含令牌授权、身份验证、客户端挑战信息以及服务器端挑战信息，使用服务器私钥计算令牌内容签名，并构建包含令牌内容和签名的服务器端身份验证令牌。得到的服务器端身份验证令牌是服务器端POWN。
建议基于ISO/IEC 9798-2或ISO/IEC 9798-4(相互的、三次通过的身份验证)构建身份验证令牌，或者作为与ISO/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
在使用对称加密的情况下:在客户端挑战上计算签名(例如一次性签名或HMAC或CMAC或GMAC)，并且在这种情况下可能是使用预共享对称密钥的服务器端挑战。生成的签名是服务器端POWN。
建议基于ISO/IEC 9798-2或ISO/IEC 9798-4(相互的、三次通过的身份验证)构建身份验证令牌，或者作为与ISO/IEC 9798中的身份验证令牌的安全相关的等效身份验证令牌。
如果客户端在(1)中指示会话密钥建立，那么服务器将创建或派生会话密钥并启用会话密钥以进一步安全通信，并设置适当的会话密钥信息(10)。
服务器根据访问权限(11)授予对诊断对象的访问权限。
服务器响应身份验证成功并发送服务器端POWN，如果存在，则发送会话密钥信息(12)。
客户机验证服务器端POWN(13)。
如果客户端在(1)中指示建立会话密钥，则客户端从会话密钥信息中提取会话密钥或派生会话密钥以进一步安全通信(14)。
如果客户端在(1)中指示会话密钥建立，则客户端使用会话密钥(15)验证会话密钥信息。
注意：步骤(15)确保会话密钥建立是完整和有效的。
如果客户端在(1)中指示建立会话密钥，则客户端启用会话密钥以进行进一步的安全诊断通信(16)。
如果在此过程中的任何一点验证失败，服务器或客户端应停止认证过程并发送相应的响应。客户应显示适当的信息(见外部测试设备规范)。
注意:失败尝试的管理(如最大尝试次数、延迟等)由车辆制造商自行决定。
注意:在客户端认证失败的情况下，特别是在服务器已经接受客户端并设置了访问权限之后，客户端可以选择向服务器发送子函数“deAuthenticate”，以确保服务器离开认证状态，并拒绝进一步的未经授权的请求。
在本小节中以任何方式建立的会话密钥在经过认证的会话期间最长有效。
注注意:步骤(11)中当前授予的诊断对象访问权限可以通过在步骤(4)中添加新的权限/角色再次执行ACR过程来更改。这样，新的权限/角色将取代当前的权限/角色，授予的访问权限也会相应更改。
这篇关于UDS关于0x29认证服务诊断签名与验签(一)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
