跟我学UDS(ISO14229) ———— 0x29(Authentication)

介绍

 该服务的目的是为客户提供一种证明其身份的方法，允许其访问数据或诊断服务，这部分数据或服务因安全、排放或安全原因而受到限制。 该服务致力于解决将例程或数据下载或上传到服务器并从服务器读取特定内存位置的诊断服务是可能需要身份验证的情况。不当程序或数据可能会损坏电子设备或其他车辆组件，或危及车辆遵守排放、安全或安保标准的风险。 另一方面，从服务器检索数据也可能会违反数据安全性。该服务支持两个安全概念：
  1. 基于使用非对称加密的 PKI 证书交换程序。 作为证书格式，应使用符合 ISO 7816-8 的 CVC 和符合 ISO/IEC 9594-8、RFC 5280 和 RFC 5755 或 IEEE 1609.2 的 X.509。
  2. 基于使用带有软件认证令牌的非对称加密或对称加密的不带 PKI 证书的请求-响应过程。

子功能介绍

 1. authenticationTask —— 身份验证服务用于身份验证、去身份验证和显式证书传输。
 2. deAuthenticate —— 主动结束认证状态。
 3. verifyCertificateUnidirectional —— 启动单向身份验证过程，仅针对服务器对客户端进行身份验证。
 4. verifyCertificateBidirectional —— 启动双向身份验证过程，以针对服务器验证客户端和针对客户端验证服务器。
 5. proofOfOwnership —— 用于将所有权证明数据传输给客户端。
 6. transmitCertificate —— 独立地或在先前的认证之后传输证书。

Authentication with PKI Certificate Exchange

 客户端和服务器应提供不同的证书集和相应的私钥：
  在单向认证的情况下，客户端需要一个带有其私钥的证书客户端，这允许客户端将自己标识为合法客户端。根据公钥基础设施 (PKI) 的信任模型，服务器可能需要颁发和签署证书客户端的证书颁发机构 (CA) 的证书。
  在双向认证的情况下，客户端需要一个带有私钥的证书客户端，这允许客户端将自己标识为合法客户端。此外，服务器还需要一个带有私钥的证书服务器，这允许服务器将自己标识为合法服务器。根据公钥基础设施 (PKI) 的信任模型，客户端和服务器可能需要颁发和签署证书客户端和证书服务器的证书颁发机构 (CA) 的证书。
 具体的流程如下所示：

   注释
     a —— 使用双向身份验证时。
     b —— 仅在使用安全诊断通信时。
     c —— 仅当使用 Diffie-Hellman 密钥协议进行安全诊断通信时。
     d —— 如果在所有权证明客户端中使用挑战客户端。
     e —— 可以选择在每个所有权证明服务器和客户端中包括质询服务器和质询客户端。

单向认证

  1. 如果在所有权证明客户端 (1) 中使用，客户端将创建挑战客户端。
  2. 客户端通过verifyCertificateUnidirectional (2) 发送它的证书客户端，如果在 (1) 中生成，它的质询客户端。
  3. 服务器验证证书客户端 (3)。
  4. 服务器创建挑战服务器 (4)。
  5. 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协议建立会话密钥，则服务器生成一个临时私钥/公钥对，以便稍后派生会话密钥以进行进一步的安全通信 (5)。如果证书中使用的算法仅可用于签名计算，但不能用于密钥协商协议，则 Diffie-Hellman 密钥协商是必要的。
  6. 服务器发送挑战服务器，如果在 (5) 中生成，则发送其临时公钥 (7)。
  7. 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协议建立会话密钥，则客户端还生成临时私钥/公钥对，以便稍后派生会话密钥以进行进一步的安全通信 (9)。如果证书中使用的算法仅可用于签名计算，而不能用于密钥协商协议，则 Diffie-Hellman 密钥协商是必要的。
  8. 客户端通过构建适当的身份验证令牌来计算所有权证明客户端，其要签名的内容至少包括（部分）质询服务器，如果在 (9) 中生成，还包括其临时公钥 (10)。
  9. 客户端通过 SubFunction proofOfOwnership (11) 发送所有权证明客户端和（如果在 (9) 中生成）其临时公钥。
  10. 服务器使用来自接收到的证书客户端 (12) 的公钥验证所有权证明客户端。
  11. 如果客户端在 (2) 中指示会话密钥建立，则服务器创建或派生并启用会话密钥以进行进一步的安全通信并设置会话密钥信息 (13)。
  12. 服务器根据访问权限 (14) 授予对诊断对象的访问权限。
  13. 服务器响应身份验证成功，如果来自 (13)，则发送会话密钥信息 (15)。
  14. 如果客户端在 (2) 中指示会话密钥建立，则客户端从会话密钥 Info 中提取会话密钥或导出会话密钥以进行进一步的安全通信 (16)。
  15. 如果客户端在 (2) 中指示会话密钥建立，则客户端使用会话密钥 (17) 验证会话密钥信息。
  16. 如果客户端在 (2) 中指示会话密钥建立，则客户端启用会话密钥以进行进一步的安全诊断通信 (18)。当使用单向认证时，服务器不对客户端进行认证。因此，客户端无法确定它正在与正确的服务器进行通信。

双向认证

  1. 客户端创建挑战客户端 (1) 并通过 SubFunction verifyCertificateBidirectional (2) 将其与其证书客户端一起发送。
  2. 服务器验证证书客户端 (3)。
  3. 服务器创建挑战服务器 (4)。
  4. 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协议建立会话密钥，则服务器生成一个临时私钥/公钥对，以便稍后派生会话密钥以进行进一步的安全通信 (5)。
  5. 服务器通过构建适当的身份验证令牌来计算所有权证明服务器，其要签名的内容至少包括（部分）质询客户端，如果在 (5) 中生成，则包括其临时公钥 (6)，并将其与质询服务器、其证书服务器以及（如果在 (5) 中生成）其临时公钥 (7)。
  6. 客户端使用来自接收到的证书服务器的公钥验证证书服务器和所有权证明服务器 (8)。
  7. 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协议建立会话密钥，则客户端还生成临时私钥/公钥对，以便稍后派生会话密钥以进行进一步的安全通信 (9)。
  8. 客户端通过构建适当的身份验证令牌来计算所有权证明客户端，其要签名的内容至少包括（部分）质询服务器，如果在 (9) 中生成，还包括其临时公钥 (10)。
  9. 客户端通过 SubFunction proofOfOwnership (11) 发送所有权证明客户端和（如果在 (9) 中生成）其临时公钥。
  10. 服务器使用来自接收到的证书客户端 (12) 的公钥验证所有权证明客户端。
  11. 如果客户端在 (2) 中指示会话密钥建立，则服务器创建或派生并启用会话密钥以进行进一步的安全通信并设置会话密钥信息 (13)。
  12. 服务器根据访问权限 (14) 授予对诊断对象的访问权限。
  13. 服务器响应身份验证成功，如果来自 (13)，则发送会话密钥信息 (15)。
  14. 如果客户端在 (2) 中指示会话密钥建立，则客户端从会话密钥信息中提取会话密钥或导出会话密钥以进行进一步的安全通信 (16)。
  15. 如果客户端在 (2) 中指示会话密钥建立，则客户端使用会话密钥 (17) 验证会话密钥信息。
  16. 如果客户端在 (2) 中指示会话密钥建立，则客户端启用会话密钥以进行进一步的安全诊断通信 (18)。

 如果每次验证成功，服务器应允许客户端访问证书客户端中的信息所引用的诊断服务，并以肯定的响应响应客户端。如果在此过程中的任何时候验证失败，服务器或客户端应停止验证过程并发送适当的响应。客户端应显示适当的消息（参见外部测试设备规范）。失败尝试的管理（例如最大尝试次数、延迟等）由车辆制造商自行决定。如果客户端验证失败，特别是在服务器已经接受客户端并设置访问权限后，客户端可以选择向服务器发送 SubFunction “deAuthenticate” 以确保服务器离开已验证状态并拒绝进一步的未经授权的请求。访问控制由车辆制造商负责。要独立传输证书或在之前的认证之后传输证书，可以使用子函数“transmitCertificate”。这个 SubFunction 的目的是向服务器提供一个证书以供进一步处理，而无需任何质询响应序列。该证书可用于额外的权限激活或证明签名数据（使用证书的嵌入公钥）。因此，数据应使用相应的私钥进行签名（数据和签名应独立发送到服务器）。通过证书添加权限的机制由车辆制造商自行决定。

Authentication with Challenge-Response (ACR)

 在使用非对称加密的情况下，应存在客户端密钥对：客户端私钥应存在于客户端中，客户端公钥应存在于服务器中。 在双向认证的情况下，应存在附加的服务器密钥对：服务器私钥应存在于服务器中，而服务器公钥应存在于客户端中。在使用对称加密的情况下，应存在对称密钥，并应在客户端和服务器之间预先共享。
 具体的流程如下所示：

   注释
     a —— 使用双向身份验证时。
     b —— 仅当服务器需要其他参数进行身份验证时。
     c —— 仅在使用安全诊断通信时。
     d —— 如果在所有权证明客户端中使用挑战客户端。
     e —— 可以选择在每个所有权证明服务器和客户端中包括质询服务器和质询客户端

单向认证

  1. 客户端通过 SubFunction requestChallengeForAuthentication 请求验证，指示要使用的算法以及是否应建立会话密钥 (1)。
  2. 服务器创建挑战服务器 (2)。
  3. 服务器发送挑战服务器和是否应提供附加参数的指示 (3)。
  4. 如果在所有权证明客户端 (4) 中使用，客户端创建挑战客户端。
  5. 客户端计算客户端所有权证明（POWN）如下（5）：
    5.1 在使用非对称加密的情况下：构建车辆制造商特定的令牌内容，其中包含令牌权限、身份验证、权限/角色、服务器端质询信息，视情况可能是客户端质询信息和附加信息，使用客户端私钥计算令牌内容签名，并构建包含令牌内容和签名的客户端身份验证令牌。生成的客户端身份验证令牌是客户端 POWN。
    5.2 在使用对称加密的情况下：计算服务器端质询的签名（例如一个时间签名或 HMAC 或 CMAC 或 GMAC），视情况可能是客户端质询信息和附加参数（如权限） /roles 由车辆制造商预定义）具有预共享的对称密钥。生成的签名是客户端 POWN。
  6. 如果附加参数在(3)中由服务器指示，则客户端在需要的附加参数(6)中提供适当的附加参数。
  7. 客户端发送客户端 POWN（如果在 (4) 中生成）、质询客户端以及（如果指示）通过 SubFunction verifyProofOfOwnershipUnidirectional (7) 所需的附加参数。
  8. 服务器验证客户端 POWN (8)。
  9. 如果客户端在 (1) 中指示会话密钥建立，则服务器创建或派生并启用会话密钥以进行进一步的安全通信并设置会话密钥信息 (10)。
  10. 服务器根据访问权限 (11) 授予对诊断对象的访问权限。
  11. 服务器响应身份验证成功，如果存在，则发送会话密钥信息 (12)。
  12. 如果客户端在 (1) 中指示会话密钥建立，则客户端从会话密钥信息中提取会话密钥或导出会话密钥以进行进一步的安全通信 (14)。
  13. 如果客户端在 (1) 中指示会话密钥建立，则客户端使用会话密钥 (15) 验证会话密钥信息。
  14. 如果客户端在 (1) 中指示会话密钥建立，则客户端启用会话密钥以进行进一步的安全诊断通信 (16)。

双向认证

  1. 客户端通过 SubFunction requestChallengeForAuthentication 请求验证，指示要使用的算法以及是否应建立会话密钥 (1)。
  2. 服务器创建挑战服务器 (2)。
  3. 服务器发送挑战服务器和是否应提供附加参数的指示 (3)。
  4. 客户端创建挑战客户端 (4)。
  5. 客户端计算客户端所有权证明（POWN）如下（5）：
    5.1 在使用非对称加密的情况下：构建适当的（车辆制造商特定的）令牌（例如，基于 CVC）内容，其中包含令牌权限、身份验证、权限/角色、服务器端质询信息，视情况可能是客户端质询信息和附加信息，使用客户端私钥计算令牌内容签名，并构建包含令牌内容和签名的客户端身份验证令牌。生成的客户端身份验证令牌是客户端 POWN。
    5.2 在使用对称密码学的情况下：计算服务器端质询的签名（例如一次性签名或 HMAC 或 CMAC 或 GMAC），视情况可能是客户端质询信息和附加参数（例如由车辆制造商预定义的权限/角色）具有预共享的对称密钥。生成的签名是客户端 POWN。
  6. 如果附加参数（车辆制造商特定的）在（3）中由服务器指示，则客户端在需要的附加参数（6）中提供适当的附加参数。
  7. 客户端通过 SubFunction verifyProofOfOwnershipBidirectional (7) 发送客户端 POWN、质询客户端以及所需的附加参数（如果指示）。
  8. 服务器验证客户端 POWN (8)。
  9. 服务器计算服务器端所有权证明（POWN）如下（9）：
    9.1 在使用非对称加密的情况下：构建适当的（车辆制造商特定的）令牌内容，其中包含令牌权限、身份验证、客户端质询信息以及服务器端质询信息（视情况而定），使用服务器私有计算令牌内容签名密钥并构建包含令牌内容和签名的服务器端身份验证令牌。生成的服务器端身份验证令牌是服务器端 POWN。
    9.2 在使用对称加密的情况下：计算客户端质询的签名（例如一次性签名或 HMAC 或 CMAC 或 GMAC），并且视情况可能是使用预共享对称密钥的服务器端质询。生成的签名是服务器端 POWN。
  10. 如果客户端在 (1) 中指示会话密钥建立，则服务器创建或派生并启用会话密钥以进行进一步的安全通信并设置适当的会话密钥信息 (10)。
  11. 服务器根据访问权限 (11) 授予对诊断对象的访问权限。
  12. 服务器响应身份验证成功并发送服务器端 POWN 和会话密钥信息（如果存在）（12）。
  13. 客户端验证服务器端 POWN (13)。
  14. 如果客户端在 (1) 中指示会话密钥建立，则客户端从会话密钥信息中提取会话密钥或导出会话密钥以进行进一步的安全通信 (14)。
  15. 如果客户端在 (1) 中指示会话密钥建立，则客户端使用会话密钥 (15) 验证会话密钥信息。
  16. 如果客户端在 (1) 中指示会话密钥建立，则客户端启用会话密钥以进行进一步的安全诊断通信 (16)。

 如果在此过程中的任何时候验证失败，服务器或客户端应停止验证过程并发送适当的响应。 客户端应显示适当的消息。 失败尝试的管理由车辆制造商自行决定。 如果客户端认证失败，特别是在服务器已经接受客户端并设置访问权限后，客户端可以选择向服务器发送 SubFunction “deAuthenticate” 以确保服务器离开认证状态并进一步拒绝 未经授权的请求。 在步骤 (11) 中授予的对诊断对象的当前访问权限可以通过在步骤 (4) 中使用新的权限/角色再次执行 ACR 过程来更改。 通过这样做，新的权限/角色会替换当前的权限/角色，并且授予的访问权限也会相应地更改。

通用需求

 身份验证旨在保护适用的诊断会话/功能/服务。 因此，需要以下服务顺序：
   1. 身份验证服务，
   2. 任何受身份验证保护或限制的诊断服务。
 对于身份验证，与诊断会话或安全级别没有直接关系。 一旦通过身份验证，服务器应处于身份验证状态，只有在发生安全超时、达到里程偏移限制或“deAuthenticate”请求有意离开身份验证状态时才应离开该状态。 只要客户端经过身份验证，分配给相应身份验证设置的适用诊断服务就应该可以访问。离开认证状态有几种可能性：
   1. 显式地：应使用 SubFunction 参数“deAuthenticate”调用认证请求。
   2. 隐式使用超时作为回退：应安装计时器。计时器应在转换到已验证状态时启动。如果定时器超时，则认证状态将结束。超时可以单独设置，也可以绑定到现有的时序参数。至少传输协议层收到的同一诊断协议的每个请求消息都应保持已验证状态激活并重置超时期限。
   3. 隐式使用里程偏移限制作为后备：应安装里程监控。里程监控将在转换到认证状态时开始。如果达到里程限制，则结束认证状态。
 显式退出条件是强制性的，至少一个隐式退出条件的实现是强制性的，两者都是可选的。如果服务器支持认证并且在收到来自同一客户端的认证请求消息时已经处于认证状态，则该服务器应保持认证状态，直到再次成功完成认证。服务器应将其状态更改为新收到的认证信息。访问已验证状态的不成功尝试不应阻止其他诊断通信。认证状态应链接到某个诊断通道。可以在具有不同身份验证设置的多个通道上处理多个客户端。其基础是多用户服务器系统。如果在服务器处于非身份验证状态时请求安全服务，则提供安全性的服务器应支持 NRC 34 “authenticationRequired”。可以建立会话密钥并将其用于进一步保护客户端和服务器之间的通信。这可以使用以下方法来实现：
   1. 通过在服务器端创建会话密钥并加密传输到客户端
   2. 或通过使用非对称密钥协商协议
   3. 或通过推导双方现有的预共享密钥（在对称加密的情况下）。

诊断请求格式

SubFunction = deAuthenticate.

SubFunction = verifyCertificateUnidirectional

SubFunction = verifyCertificateBidirectional

SubFunction = proofOfOwnership

SubFunction = transmitCertificate

SubFunction = requestChallengeForAuthentication

SubFunction = verifyProofOfOwnershipUnidirectional

SubFunction = verifyProofOfOwnershipBidirectional

SubFunction = authenticationConfiguration

正响应格式

SubFunction = deAuthenticate

SubFunction = verifyCertificateUnidirectional

SubFunction = verifyCertificateBidirectional

SubFunction = proofOfOwnership

SubFunction = transmitCertificate

SubFunction = requestChallengeForAuthentication

SubFunction = verifyProofOfOwnershipUnidirectional

SubFunction = verifyProofOfOwnershipBidirectional

SubFunction = authenticationConfiguration

负响应格式

 具体的评估系列见下图：