UDS 0x29 Authentication Service – The Complete Technical Guide for Automotive Engineers
Introduction: Why UDS 0x29 Authentication Is the Future of ECU Security
If you have worked with automotive diagnostics for any length of time, you already know UDS Service 0x27 — Security Access. Request a seed, compute a key, unlock the ECU. It is simple, lightweight, and it has been the backbone of ECU protection for over two decades.
But here is the problem: the vehicle world has fundamentally changed.
A modern automotive ECU does not sit in an isolated vehicle communicating only with a workshop tester once a year. Today, a single ECU may receive diagnostic commands from an OEM OTA backend over the internet, a supplier’s remote diagnostic tool, a cloud-connected fleet management platform, a manufacturing tester on the production line, a dealer workshop scan tool, and a cybersecurity audit system all potentially within the same week. In that world, a shared secret that proves “you know the password” is simply not enough.
The question the industry had to answer became: how does the ECU know WHO is actually connecting to it, what role they hold, and whether they are genuinely authorized to do what they are asking?
That is the question UDS 0x29 Authentication Service was designed to answer. Introduced in ISO 14229-1:2020, this service brings certificate-based identity verification, Public Key Infrastructure (PKI), and role-based access control directly into the automotive diagnostic layer. It is one of the most significant additions to the UDS standard in its history, and every automotive engineer working in diagnostics, cybersecurity, or AUTOSAR needs to understand it deeply.
In this complete guide, we will cover everything — from first principles to full hex-level request and response examples, all nine sub-functions in detail, both APCE and ACR authentication modes, certificate chain mechanics, role-based access, negative response codes, and implementation guidance for AUTOSAR Classic DCM.
The top keywords this article is built around: UDS 0x29 Authentication, UDS Authentication Service, ECU Authentication, Automotive PKI, UDS ISO 14229 — these will appear naturally and repeatedly throughout because they are what this topic is genuinely about.
1. What Is UDS 0x29 Authentication Service?
UDS 0x29 Authentication is Service ID 0x29 defined in ISO 14229-1:2020 (Road Vehicles — Unified Diagnostic Services, Part 1: Application Layer). Its positive response Service ID is 0x69. Together with 0x27 Security Access, it forms the security gateway of the UDS protocol — but the two services work in fundamentally different ways.
The primary objective of UDS 0x29 Authentication is to establish a standardized, cryptographically strong mechanism by which a diagnostic client (the tester) proves its identity to the server (the ECU). A secondary objective, optionally supported, is to derive session keys for encrypted communication using the Secured Data Transmission Service 0x84.
When the ECU processes a 0x29 Authentication request successfully, it can determine:
- WHO the requester is — not just whether they know a secret, but their actual cryptographic identity
- WHAT role they hold — OEM, dealer, supplier, workshop, or backend system
- WHETHER their certificate is valid, non-expired, and not revoked
- WHETHER the trust chain on their certificate leads back to a Root CA the ECU already trusts
- WHICH diagnostic services and data identifiers this identity is permitted to access
This is a completely different security model from 0x27. Instead of binary locked/unlocked state, 0x29 gives the ECU a full identity context for every session.
The Response SID
The positive response to any 0x29 request always starts with 0x69 (which is 0x29 + 0x40 — the standard UDS positive response offset). Any negative response follows the standard UDS format: 0x7F, 0x29, NRC.
2. The Problem With UDS 0x27 — Why UDS 0x29 Authentication Was Needed
Before diving deep into how UDS 0x29 Authentication works, it is worth spending time understanding exactly what gap in security it fills. This is not about saying 0x27 is bad — it is about understanding the threat model shift.
What 0x27 Does Well
UDS 0x27 Security Access uses a seed-and-key challenge-response protocol. The tester requests a seed, the ECU returns a random nonce, the tester computes a key using an OEM-specific algorithm (typically seeded with a shared secret), and the ECU validates it. For isolated, non-connected ECUs with a single class of diagnostic user (the workshop technician), this is efficient and adequate.
Where 0x27 Falls Short
The fundamental limitation of 0x27 is that it proves knowledge of a secret, not identity. Once someone knows the algorithm and the master key — whether through legitimate access, reverse engineering, or compromise of one diagnostic tool — every ECU using that algorithm across the entire fleet is exposed. There is no granularity: either the ECU is locked or it is fully unlocked. There is no concept of “the OEM backend gets full access but the workshop tool gets read-only.” There is no revocation mechanism — if a supplier’s tool is compromised, there is no way to block it at the protocol level without reflashing all ECUs.
Additionally, 0x27 has no built-in protection against impersonation. If an attacker can capture and replay a seed-key exchange, or if the algorithm is leaked, any tool can impersonate any legitimate tester.
ISO 15765-4 has noted the deprecation direction for 0x27 in modern implementations, and ISO 14229-1:2020 formally introduced 0x29 as the standardized modern replacement for scenarios requiring strong identity assurance.
The Architectural Question
0x27 asks: “Do you know the secret?”
UDS 0x29 Authentication asks: “Who are you, what role do you hold, is your certificate legitimate, and should you be allowed to do this specific thing to this specific ECU?”
That is not an incremental improvement. It is a completely different security architecture.
3. UDS 0x29 Authentication Modes: APCE and ACR
ISO 14229-1 defines two authentication mechanisms for UDS 0x29 Authentication Service. Understanding both is essential before examining the individual sub-functions.
3.1 APCE – Authentication with PKI Certificate Exchange (Primary Mode)
APCE stands for Asymmetric Proof of Possession and Certificate Exchange. This is the primary, recommended mode of UDS 0x29 Authentication and the one supported by AUTOSAR DCM (introduced in AUTOSAR 4.4.0).
APCE uses Public Key Infrastructure (PKI) and asymmetric cryptography. The tester holds a digital certificate issued by a Certificate Authority (CA) that the ECU trusts. During authentication, the tester presents its certificate and cryptographically proves it possesses the matching private key — without ever transmitting that private key. The ECU validates the certificate chain back to a trusted Root CA that was pre-installed at manufacturing.
APCE solves all the limitations of 0x27:
- Each tester has a unique certificate — compromise of one does not expose others
- Certificates are issued by an OEM-controlled CA — no self-signing possible
- Certificates have expiry dates — time-limited access by design
- Certificates can be revoked — a compromised tool is blocked fleet-wide by updating the CRL
- The certificate carries role metadata — role-based access control is native to the protocol
APCE comes in two variants:
- Unidirectional: The ECU verifies the tester’s certificate (most common in workshop/dealer scenarios)
- Bidirectional: Both sides verify each other’s certificates (required for high-security operations like OTA updates)
3.2 ACR – Authentication with Challenge-Response
ACR stands for Authentication Challenge-Response. This mode is conceptually similar to 0x27 but uses asymmetric cryptography and server-generated challenges to eliminate replay attack vulnerabilities.
In ACR, instead of a shared secret algorithm, the ECU has the tester’s pre-installed public key. The ECU issues a challenge (nonce), the tester signs it with its private key, and the ECU verifies the signature using the pre-installed public key. There is no certificate exchange — the ECU already knows the tester’s public key.
ACR eliminates the need for full PKI infrastructure (no certificate chain, no CA), making it simpler to implement. However, it has significant drawbacks: there is no revocation mechanism (you cannot revoke a pre-installed public key without reflashing the ECU), and it raises concerns about private key management and leakage over time. AUTOSAR DCM does not formally recommend ACR as the primary mode.
In practice, APCE is the dominant mode for modern automotive ECU Authentication, and ACR is used primarily in constrained environments or legacy transition scenarios.
4. The Nine Sub-Functions of UDS 0x29 Authentication — Complete Reference
This is the core of the article. UDS 0x29 Authentication defines nine sub-functions in ISO 14229-1:2020, each serving a specific role in the authentication lifecycle. Every automotive engineer implementing or integrating 0x29 must understand all nine.
The request format for all 0x29 sub-functions follows this structure:
[0x29] [Sub-function byte] [Parameters...]The positive response always starts with:
[0x69] [Sub-function echo] [Response parameters...]Below is the list of UDS Service 0x29 Authentication sub-functions.
UDS 0x29 defines nine sub-functions, each used in the authentication lifecycle.
| Sub-function | Name | Purpose |
|---|---|---|
0x01 | deAuthenticate | Close the current authentication session |
0x02 | verifyCertificateUnidirectional | Verify tester certificate; ECU verifies tester only |
0x03 | verifyCertificateBidirectional | Mutual certificate verification; both tester and ECU verify each other |
0x04 | proofOfOwnership | Prove possession of the private key |
0x05 | transmitCertificate | Transmit or provision a certificate to the ECU |
0x06 | requestChallengeForAuthentication | ECU issues a random challenge or nonce |
0x07 | verifyProofOfOwnershipUnidirectional | Verify cryptographic proof from tester to ECU |
0x08 | verifyProofOfOwnershipBidirectional | Verify cryptographic proof in both directions |
0x09 | authenticationConfiguration | Discover supported authentication mechanisms |
Most commonly used production flows are usually 0x06 + 0x07 for unidirectional authentication and 0x06 + 0x08 for bidirectional or mutual authentication.
Sub-function 0x00 – deAuthenticate
Purpose: Close the current authentication session and return the ECU to its unauthenticated state.
This sub-function is the clean exit mechanism for an authenticated session. When a diagnostic tool has finished its work and wants to formally close the authenticated session — rather than waiting for a session timeout — it sends deAuthenticate. The ECU resets all access rights granted during the session and returns to its default security state.
This is important for security hygiene: an authenticated session left open unnecessarily extends the attack window. Any well-behaved diagnostic tool should call deAuthenticate when it is done.
Note: In the APCE AUTOSAR sub-function numbering, deAuthenticate is coded as 0x01 (ISO 14229-1 numbers it 0x00). The EcuBus-Pro implementation example references it as 0x00. Be aware that some toolchains and AUTOSAR BSW layers use slightly different offset conventions — always verify against your specific AUTOSAR version and DCM configuration.
Request:
Byte 1: 0x29 (Service ID — UDS Authentication)
Byte 2: 0x00 (Sub-function — deAuthenticate)Full CAN Frame (ISO-TP Single Frame):
Tester → ECU:
[02] [29] [00]
Byte breakdown:
02 = ISO-TP length (2 data bytes follow)
29 = UDS Service ID (Authentication)
00 = Sub-function (deAuthenticate)Positive Response:
ECU → Tester:
[02] [69] [00]
Byte breakdown:
02 = ISO-TP length
69 = Positive Response SID (0x29 + 0x40)
00 = Echo of sub-functionWhat happens on the ECU side: The ECU clears all role-scoped permissions granted during the authenticated session. The internal authentication state machine transitions back to “deAuthenticated.” Any subsequent requests for services that require authentication will receive NRC 0x34 (authenticationRequired).
Negative Response for deAuthenticate:
ECU → Tester:
[03] [7F] [29] [5D]
7F = Negative Response SID
29 = Service ID that failed
5D = NRC: DeAuthentication failedNRC 0x5D (deAuthenticationFailed) indicates the ECU was unable to cleanly exit the authenticated state — the ECU may still have residual permissions active. This is a rare but critical error case that must be handled in any robust implementation.
Sub-function 0x01 — verifyCertificateUnidirectional
Purpose: Initiate unidirectional certificate verification where the ECU validates the tester’s certificate. This is the first step in APCE unidirectional UDS 0x29 Authentication.
This is the most commonly used 0x29 sub-function in production automotive systems. The tester sends its X.509 certificate (the Leaf Certificate) along with a client-generated random challenge. The ECU parses the certificate, validates the entire certificate chain back to its pre-installed Root CA, checks revocation status, and if the certificate is valid, responds with its own server-generated challenge (nonce) that the tester must then sign in the next step.
Request Parameters:
| Field | Size | Description |
|---|---|---|
| communicationConfiguration | 1 byte | Must be 0x00 (no secure communication setup) |
| lengthOfCertificateClient | 2 bytes | Length of the certificate data in bytes |
| certificateClient | variable | The tester’s X.509 DER-encoded certificate |
| lengthOfChallengeClient | 2 bytes | Length of the client random nonce |
| challengeClient | variable | Cryptographically secure random bytes (typically 32 bytes) |
Request Frame (simplified, certificate represented as [CERT]):
Tester → ECU:
[29] [01] [00] [02] [BC] [CERT...512+bytes] [00] [20] [RND...32 bytes]
Byte breakdown:
29 = Service ID (UDS Authentication)
01 = Sub-function (verifyCertificateUnidirectional)
00 = communicationConfiguration (0x00 = no session key)
02 BC = lengthOfCertificateClient (0x02BC = 700 bytes, example)
[CERT] = DER-encoded X.509 certificate (variable length)
00 20 = lengthOfChallengeClient (0x0020 = 32 bytes)
[RND] = 32 random bytes from testerReal hex example (abbreviated, using short placeholder cert):
REQUEST (Tester → ECU):
29 01 00 00 0A 30 82 00 0A AB CD EF 01 23 45 67
│ │ └──────────────────── cert bytes (10 bytes, abbreviated)
│ └─ lengthOfCertificateClient = 0x000A (10)
└─ communicationConfiguration = 0x00
00 20 A3 F2 7C 9B 11 44 E8 5D 2A 99 07 BC 43 F1
│ │ └──────────────────────────────────────── 32-byte random challenge
│ └─ (part of challenge)
└─ lengthOfChallengeClient = 0x0020 (32)ECU Validation Logic (what the ECU does upon receiving this request):
- Parse the DER-encoded X.509 certificate from the request
- Verify the certificate’s signature against the pre-installed Intermediate CA public key
- Verify the Intermediate CA certificate against the pre-installed Root CA
- Check certificate validity period (NotBefore / NotAfter fields)
- Check certificate revocation via CRL lookup or OCSP query (if configured)
- Check Key Usage and Extended Key Usage extensions permit diagnostic use
- If all checks pass, extract the tester’s public key from the certificate
- Generate a fresh server-side random challenge (nonce)
- Return the server challenge and returnValue = 0x11 (certificate OK, verify ownership next)
Positive Response Parameters:
| Field | Size | Description |
|---|---|---|
| returnValue | 1 byte | Result code (0x11 = certificate verified, proof of ownership required) |
| lengthOfChallengeServer | 2 bytes | Length of server nonce |
| challengeServer | variable | Server-generated random nonce (32 bytes typical) |
| lengthOfEphemeralPublicKeyServer | 2 bytes | Length of ephemeral public key (if session key derivation used) |
| ephemeralPublicKeyServer | variable | ECDH ephemeral public key (0 bytes if no session key) |
Positive Response Frame:
ECU → Tester:
69 01 11 00 20 B7 44 A1 29 F3 8C 0D E5 17 92 3A
│ │ │ │ │ └──────────────────────────────── 32-byte server challenge
│ │ │ │ └─ (part of challenge length)
│ │ │ └─ lengthOfChallengeServer high byte = 0x00
│ │ └─ returnValue = 0x11 (certificate OK, ownership proof required)
│ └─ echo of sub-function = 0x01
└─ Response SID = 0x69
[continuing challenge bytes...]
CC 5B F8 04 71 D3 2E 9A 10 40 07 F6 E4 BB 23 AA
[...16 more bytes of challenge...]
00 00
└─ lengthOfEphemeralPublicKeyServer = 0x0000 (no ECDH key, no session key derivation)Negative Responses specific to verifyCertificateUnidirectional:
[03] [7F] [29] [50] → Certificate verification failed: Invalid Time Period (expired)
[03] [7F] [29] [51] → Certificate verification failed: Invalid Signature
[03] [7F] [29] [52] → Certificate verification failed: Invalid Chain of Trust
[03] [7F] [29] [53] → Certificate verification failed: Invalid Type
[03] [7F] [29] [54] → Certificate verification failed: Invalid Format
[03] [7F] [29] [55] → Certificate verification failed: Invalid Content
[03] [7F] [29] [56] → Certificate verification failed: Invalid Scope
[03] [7F] [29] [57] → Certificate verification failed: Certificate RevokedEach of these NRCs maps to a specific failure point in the certificate chain validation, giving the tester’s diagnostic layer precise information about why verification failed.
Sub-function 0x02 — verifyCertificateBidirectional
Purpose: Initiate bidirectional (mutual) certificate verification. Both the ECU validates the tester’s certificate AND the tester validates the ECU’s certificate. This is the gold standard authentication mode for high-security scenarios.
In bidirectional UDS 0x29 Authentication, neither side trusts the other by default. The ECU verifies the tester’s certificate (same as unidirectional), and additionally sends its own certificate back so the tester can independently verify that it is talking to a legitimate ECU — not a spoofed or cloned device.
This mode is mandatory for:
- OTA firmware update operations
- Security configuration changes
- Key provisioning and certificate injection
- Any operation where ECU impersonation poses an unacceptable risk
Request Parameters: Identical to 0x01 verifyCertificateUnidirectional — the tester sends its certificate and client challenge.
Positive Response Parameters (bidirectional has an additional field):
| Field | Size | Description |
|---|---|---|
| returnValue | 1 byte | 0x11 = certificate OK, ownership proof required |
| lengthOfChallengeServer | 2 bytes | Server nonce length |
| challengeServer | variable | Server-generated nonce |
| lengthOfCertificateServer | 2 bytes | ECU’s own certificate length |
| certificateServer | variable | ECU’s X.509 certificate for tester to verify |
| lengthOfEphemeralPublicKeyServer | 2 bytes | ECDH key length (if session key is being derived) |
| ephemeralPublicKeyServer | variable | ECDH ephemeral public key |
Positive Response Frame (abbreviated):
ECU → Tester:
69 02 11 00 20 [32 bytes server challenge]
00 F4 [244-byte ECU certificate in DER format]
00 00 [no ephemeral key]
Full breakdown:
69 = Response SID
02 = Sub-function echo
11 = returnValue (cert OK, prove ownership)
00 20 = lengthOfChallengeServer (32 bytes)
[challenge...] = 32 random bytes
00 F4 = lengthOfCertificateServer (244 bytes, example)
[ECU cert] = DER-encoded ECU certificate
00 00 = no ECDH keyWhat the tester does after receiving this response:
The tester now performs its own certificate chain verification on the ECU’s certificate using the same Root CA that it has pre-loaded. If the ECU certificate is invalid, the tester aborts the session — it knows it is talking to an unauthorized or cloned device. This protects against man-in-the-middle and ECU spoofing attacks.
Sub-function 0x03 — proofOfOwnership
Purpose: Prove that the tester possesses the private key corresponding to the certificate it presented in the previous verifyCertificate step. This is the second and final step in the APCE unidirectional flow.
After the ECU has verified the tester’s certificate (sub-function 0x01 or 0x02) and sent back its own server challenge, the tester must now prove it actually owns the private key that corresponds to the public key in that certificate. It does this by signing the server’s challenge with its private key. The ECU then verifies this signature using the public key it already extracted from the certificate in the previous step.
This is the core cryptographic proof-of-possession step. Without it, anyone who merely possesses a copy of a certificate (without the private key) could not complete authentication.
Request Parameters:
| Field | Size | Description |
|---|---|---|
| lengthOfProofOfOwnershipClient | 2 bytes | Length of the digital signature |
| proofOfOwnershipClient | variable | Digital signature of the server’s challenge |
| lengthOfEphemeralPublicKeyClient | 2 bytes | ECDH key length (0 if no session key) |
| ephemeralPublicKeyClient | variable | Tester’s ephemeral ECDH public key for key derivation |
How the signature is computed (ECDSA P-256 example):
python
# Tester-side: sign the server challenge with the tester's private key
# The server challenge was received in the verifyCertificate response
server_challenge = bytes.fromhex("B744A129F38C0DE517923ACC5BF80471D32E9A104007F6E4BB23AA...")
# Load private key from HSM or secure storage
private_key = load_ecdsa_p256_private_key("tester_private.key")
# Sign using ECDSA with SHA-256
signature = private_key.sign(server_challenge, algorithm=ECDSA(SHA256()))
# signature is typically 64-72 bytes for P-256Request Frame:
Tester → ECU:
29 03 00 48 [72-byte ECDSA signature bytes]
│ │ │ │
│ │ │ └─ lengthOfProofOfOwnershipClient low byte = 0x48 (72 decimal)
│ │ └─ high byte of length = 0x00
│ └─ Sub-function = proofOfOwnership
└─ Service ID = 0x29
[signature bytes — example with ECDSA P-256:]
29 03 00 48 30 46 02 21 00 A3 F2 9C 11 44 E8 5D
2A 99 07 BC 43 F1 CC 5B F8 04 71 D3 2E 9A 10 40
07 F6 E4 BB 23 02 21 00 B7 11 A9 29 F3 8C 0D E5
17 92 3A CC 5B 08 71 D3 2E 9A 10 40 07 F6 E4 BB
00 00 ← no ephemeral ECDH key (no session key derivation)ECU Verification Logic:
- Retrieve the tester’s public key from the certificate validated in the previous step
- Retrieve the server challenge (nonce) that was sent in the previous response
- Verify the digital signature:
signature.verify(challenge, tester_public_key)using the algorithm declared in the authenticationConfiguration (e.g., ECDSA P-256) - If verification passes, extract role from the certificate’s Subject or extensions field
- Apply the role-to-permissions mapping to grant access rights
- Transition the authentication state machine to “authenticated”
Positive Response Parameters:
| Field | Size | Description |
|---|---|---|
| returnValue | 1 byte | 0x12 = Ownership verified, authentication successful |
| lengthOfSessionKeyInfo | 2 bytes | Session key info length (0x0000 if no session key) |
| sessionKeyInfo | variable | Derived session key parameters (if applicable) |
Positive Response Frame:
ECU → Tester:
69 03 12 00 00
69 = Response SID
03 = Sub-function echo
12 = returnValue (authentication successful)
00 = lengthOfSessionKeyInfo high byte
00 = lengthOfSessionKeyInfo low byte (no session key)At this point, UDS 0x29 Authentication is complete. The session is now authenticated with the role derived from the certificate.
Negative Responses:
[03] [7F] [29] [58] → Ownership verification failed (signature does not match)
[03] [7F] [29] [24] → requestSequenceError (proofOfOwnership called before verifyCertificate)NRC 0x24 (requestSequenceError) is critically important here — if a tester tries to call proofOfOwnership without first completing a successful verifyCertificate step, the ECU must reject it. This state machine enforcement is a key security requirement.
Sub-function 0x04 — proofOfOwnership (for Bidirectional)
In bidirectional UDS 0x29 Authentication flows, after the mutual certificate exchange (sub-function 0x02), both sides need to prove ownership. The tester proves ownership of its private key using this sub-function, and the response contains the ECU’s proof that it possesses its own private key.
The request and response structure is identical to sub-function 0x03, but in the bidirectional context, the response additionally contains the ECU’s own signature over the client challenge that the tester sent in step 0x02.
ECU Proof of Ownership in Response:
ECU → Tester:
69 04 12 00 48 [72-byte ECU signature over client challenge] 00 00
69 = Response SID
04 = Sub-function echo
12 = returnValue (authentication successful)
00 48 = lengthOfProofOfOwnershipServer (72 bytes)
[sig] = ECU's ECDSA signature over the client's challenge
00 00 = no session keyThe tester verifies this ECU signature using the ECU’s public key from the ECU certificate received in step 0x02.
Sub-function 0x05 — transmitCertificate
Purpose: Transfer a new certificate to the ECU for storage. This sub-function is used for certificate provisioning, rotation, and certificate lifecycle management — distinct from the authentication flow itself.
This is an operational sub-function, not an authentication sub-function. It is used in scenarios where the ECU needs to receive and store a new certificate — for example, during initial manufacturing (injecting the ECU’s own certificate), certificate renewal before expiry, or provisioning a new Root CA certificate to expand the trust anchor list.
Important: transmitCertificate requires the session to already be authenticated (typically via verifyCertificateBidirectional) before it can be used. You cannot transmit a certificate to an unauthenticated ECU — that would defeat the entire security model.
Request Parameters:
| Field | Size | Description |
|---|---|---|
| certificateEvaluationId | 2 bytes | Identifies which certificate slot or purpose this targets |
| lengthOfCertificate | 2 bytes | Certificate data length |
| certificate | variable | The DER-encoded certificate to store |
Request Frame:
Tester → ECU:
29 05 00 01 02 BC [700 bytes of DER certificate]
29 = Service ID
05 = Sub-function (transmitCertificate)
00 01 = certificateEvaluationId (slot 1, OEM-defined)
02 BC = lengthOfCertificate (700 bytes)
[CERT] = DER-encoded certificatePositive Response:
ECU → Tester:
69 05 00
69 = Response SID
05 = Sub-function echo
00 = returnValue (certificate stored successfully)Use Case in Manufacturing:
During end-of-line (EOL) production, the ECU starts with only the Root CA pre-installed. The manufacturing tester authenticates using a production-role certificate, then uses transmitCertificate to inject:
- The ECU’s own identity certificate
- The ECU’s own private key (via a secure provisioning channel, not over UDS directly)
- Any additional CA certificates required for the vehicle’s PKI hierarchy
Sub-function 0x06 — requestChallengeForAuthentication
Purpose: Used in the ACR (Authentication Challenge-Response) mode. The tester requests a fresh challenge from the ECU before performing a challenge-response authentication without certificate exchange.
This sub-function is specific to ACR mode — it has no role in the APCE certificate-based flow. In ACR, the tester’s public key is already pre-installed in the ECU. The tester simply asks the ECU for a new random challenge, signs it, and sends the signature back.
Request Parameters:
| Field | Size | Description |
|---|---|---|
| communicationConfiguration | 1 byte | Algorithm and session key configuration |
| algorithmIndicator | 16 bytes | OID or identifier indicating the signature algorithm |
Request Frame:
Tester → ECU:
29 06 00 [16-byte algorithm indicator]
29 = Service ID
06 = Sub-function (requestChallengeForAuthentication)
00 = communicationConfiguration
[OID] = 16 bytes identifying algorithm
Example: 06 08 2A 86 48 CE 3D 04 03 02 (ECDSA-SHA256 OID, padded)Positive Response:
ECU → Tester:
69 06 [algo 16 bytes] 00 20 [32-byte challenge]
69 = Response SID
06 = Sub-function echo
[algo] = echo of algorithm indicator
00 20 = lengthOfChallenge (32 bytes)
[challenge]= fresh random nonce from ECUNegative Response:
[03] [7F] [29] [59] → Challenge calculation failed (ECU could not generate nonce)Sub-function 0x07 — verifyProofOfOwnershipUnidirectional
Purpose: Used in ACR mode. The tester sends its signed challenge back to the ECU for unidirectional verification. This is the completion step for ACR unidirectional authentication.
After receiving the challenge from sub-function 0x06, the tester signs it and sends the signature here. The ECU verifies the signature using the tester’s pre-installed public key.
Request Parameters:
| Field | Size | Description |
|---|---|---|
| algorithmIndicator | 16 bytes | Must match the algorithm from step 0x06 |
| lengthOfProofOfOwnershipClient | 2 bytes | Signature length |
| proofOfOwnershipClient | variable | Digital signature over the challenge |
| lengthOfEphemeralPublicKeyClient | 2 bytes | ECDH key length (optional) |
| ephemeralPublicKeyClient | variable | Ephemeral ECDH key for session key derivation |
Request Frame:
Tester → ECU:
29 07 [16-byte algo indicator] 00 48 [72-byte signature] 00 00
Full example:
29 07
06 08 2A 86 48 CE 3D 04 03 02 00 00 00 00 00 00 ← algorithm indicator (16 bytes)
00 48 ← signature length (72 bytes)
30 46 02 21 00 A3 F2 9C 11 44 E8 5D 2A 99 07 BC ← ECDSA signature start
43 F1 CC 5B F8 04 71 D3 2E 9A 10 40 07 F6 E4 BB ← (continues)
23 02 21 00 B7 11 A9 29 F3 8C 0D E5 17 92 3A CC ← (continues)
5B 08 71 D3 2E 9A 10 40 07 F6 E4 BB 23 AA 5C 01 ← signature end (72 bytes total)
00 00 ← no ephemeral keyPositive Response:
ECU → Tester:
69 07 12 00 00
12 = returnValue (authentication successful)
00 00 = no session keySub-function 0x08 — verifyProofOfOwnershipBidirectional
Purpose: Used in ACR mode for bidirectional verification. Both sides prove ownership in a single exchange.
Same as 0x07 but the ECU additionally returns its own proof of ownership (its signature over the client’s challenge) in the response, enabling mutual verification in ACR mode.
Positive Response (additional ECU proof):
ECU → Tester:
69 08 12 00 48 [72-byte ECU signature over client's challenge] 00 00
12 = authentication successful
00 48 = lengthOfProofOfOwnershipServer
[sig] = ECU's signature for tester to verify
00 00 = no session keySub-function 0x09 — authenticationConfiguration
Purpose: Query the ECU to discover which authentication mechanisms and algorithms it supports. This is the discovery and capability negotiation step, typically the first call in any 0x29 sequence.
Before a tester attempts authentication, it should ask the ECU what it supports. The ECU responds with its authentication configuration — which modes (APCE or ACR), which algorithms (ECDSA P-256, RSA-2048, etc.), and whether session key derivation is supported.
This sub-function is also used to initiate APCE mode in some implementations (as shown in the EcuBus-Pro example where it returns returnValue = 0x02 indicating APCE mode).
Request Frame:
Tester → ECU:
29 09 00
29 = Service ID
09 = Sub-function (authenticationConfiguration)
00 = no additional parametersFull CAN single frame:
[02] [29] [09]Positive Response:
ECU → Tester:
69 09 [returnValue] [configuration bytes...]
Example response (APCE, ECDSA P-256, no session key):
69 09 02 01 16
│ │ └─ algorithmConfig (example: ECDSA P-256 without session key)
│ └─ Number of supported auth methods
└─ returnValue = 0x02 (APCE supported)returnValue codes for authenticationConfiguration:
| Value | Meaning |
|---|---|
| 0x00 | Autonomous / default — use standard challenge-response |
| 0x01 | ACR mode — use Authentication Challenge-Response |
| 0x02 | APCE mode — use PKI Certificate Exchange |
Negative Response:
[03] [7F] [29] [5C] → Configuration data usage failed
[03] [7F] [29] [12] → Sub-function not supported (ECU does not support 0x29)5. Complete APCE Unidirectional Authentication Flow — End to End
Now that all the sub-functions are covered, let us walk through a complete, real-world APCE unidirectional UDS 0x29 Authentication sequence from start to finish. This is what you would see on a CAN bus trace when a dealer tool authenticates to an ECU.
Scenario: An authorized dealer tool is authenticating to a Body Control Module (BCM) ECU. The tester ID is 0x7E0, the ECU ID is 0x7E8.
Step 0 — Enter Extended Diagnostic Session (prerequisite)
Tester → ECU (0x7E0 → 0x7E8):
[02] [10] [03] ← DiagnosticSessionControl, ExtendedDiagnosticSession
ECU → Tester (0x7E8 → 0x7E0):
[06] [50] [03] [00] [32] [01] [F4] ← Session accepted, P2=50ms, P2*=500msStep 1 — Query authentication configuration
Tester → ECU:
[02] [29] [09] ← authenticationConfiguration
ECU → Tester:
[03] [69] [09] [02] ← returnValue=0x02 (APCE mode supported)Step 2 — Verify Certificate Unidirectional (tester presents certificate)
The tester’s certificate is a 512-byte DER-encoded X.509 certificate. The tester also generates a 32-byte random challenge. Because a CAN frame is only 8 bytes, this multi-byte message uses ISO-TP multi-frame transport.
Tester → ECU (ISO-TP First Frame):
[10] [26] [29] [01] [00] [02] [00] [30]
│ │ │ │ │ │ │ └─ cert DER start (first 2 bytes: 30 82...)
│ │ │ │ │ └──┴─ lengthOfCertificateClient = 0x0200 (512 bytes)
│ │ │ │ └─ communicationConfiguration = 0x00
│ │ │ └─ sub-function = 0x01
│ │ └─ Service ID = 0x29
│ └─ Total message length = 0x026 = 550 bytes (512 cert + 32 challenge + headers)
└─ ISO-TP First Frame indicator (0x1x)
ECU → Tester (ISO-TP Flow Control):
[30] [00] [00] ← send all, no separation time
Tester → ECU (Consecutive Frames — certificate continues):
[21] [82] [05] [FF] [30] [82] [05] [FB]
[22] [30] [0D] [06] [09] [2A] [86] [48]
[23] [86] [F7] [0D] [01] [01] [0B] [05]
... (more frames carrying rest of certificate)
[2N] [00] [20] [A3] [F2] [7C] [9B] [11] ← start of 32-byte challenge
[2M] [44] [E8] [5D] [2A] [99] [07] [BC]
[2P] [43] [F1] [CC] [5B] [F8] [04] [71] ← end of challenge
[2Q] [D3] [2E] [9A] [10] [40] [07] [F6]ECU Validates the Certificate and Responds:
ECU → Tester (ISO-TP — total ~40 bytes):
[10] [27] [69] [01] [11] [00] [20] [B7]
│ │ │ │ │ │ │ └─ start of 32-byte server challenge
│ │ │ │ │ └────┘─ lengthOfChallengeServer = 0x0020
│ │ │ │ └─ returnValue = 0x11 (cert OK, prove ownership)
│ │ │ └─ sub-function echo = 0x01
│ │ └─ Response SID = 0x69
│ └─ message length = 0x027 (39 bytes)
└─ ISO-TP First Frame
[30] [00] [00] ← flow control from tester
[21] [44] [A1] [29] [F3] [8C] [0D] [E5]
[22] [17] [92] [3A] [CC] [5B] [F8] [04]
[23] [71] [D3] [2E] [9A] [10] [40] [07]
[24] [F6] [E4] [BB] [23] [AA] [00] [00] ← last 2 bytes: no ephemeral key (0x0000)Step 3 — Tester Signs the Server Challenge and Sends Proof of Ownership
// Tester internal logic (shown as pseudocode):
server_challenge = B744A129F38C0DE517923ACC5BF80471D32E9A104007F6E4BB23AA...
signature = ECDSA_P256_SHA256.sign(server_challenge, tester_private_key)
// signature is 64 bytes (raw) or 70-72 bytes (DER-encoded)
Tester → ECU (ISO-TP):
[10] [4A] [29] [03] [00] [46] [30] [44]
│ │ │ │ │ │ └────── DER signature start
│ │ │ │ └──┘─ lengthOfProofOfOwnershipClient = 0x0046 (70 bytes)
│ │ │ └─ sub-function = 0x03
│ │ └─ Service ID = 0x29
│ └─ total message length = 0x4A (74 bytes)
[30] [00] [00] ← flow control
[21] [02] [20] [00] [A3] [F2] [9C] [11]
[22] [44] [E8] [5D] [2A] [99] [07] [BC]
[23] [43] [F1] [CC] [5B] [F8] [04] [71]
[24] [D3] [2E] [9A] [10] [40] [07] [F6]
[25] [E4] [BB] [23] [02] [20] [00] [B7]
[26] [11] [A9] [29] [F3] [8C] [0D] [E5]
[27] [17] [92] [3A] [CC] [5B] [08] [71]
[28] [D3] [2E] [9A] [10] [40] [07] [F6]
[29] [E4] [BB] [23] [AA] [5C] [01] [AA]
[2A] [00] [00] ← no ephemeral keyECU Verifies Signature and Grants Session:
ECU → Tester:
[03] [69] [03] [12]
69 = Response SID
03 = Sub-function echo (proofOfOwnership)
12 = returnValue = 0x12 (AUTHENTICATION SUCCESSFUL)At this point the ECU transitions to authenticated state with the role granted by the certificate. All subsequent requests in this session are subject to the role-scoped permissions.
6. Complete APCE Bidirectional Authentication Flow
For high-security scenarios like OTA updates, the full bidirectional flow adds certificate exchange in both directions.
Step 1: Tester → ECU: [29][02] + tester cert + client challenge
↓
Step 2: ECU validates tester cert
ECU → Tester: [69][02] + returnValue=0x11 + server challenge + ECU cert + ephemeral key
↓
Step 3: Tester validates ECU cert (protects against ECU spoofing)
Tester signs server challenge
Tester → ECU: [29][04] + tester signature + tester ephemeral key
↓
Step 4: ECU verifies tester signature
ECU signs client challenge
ECU → Tester: [69][04] + returnValue=0x12 + ECU signature + session key info
↓
Step 5: Tester verifies ECU signature (confirms ECU is legitimate)
Mutual authentication complete — session established with full session key7. returnValue Codes — Complete Reference
The returnValue byte in 0x29 responses is specific to UDS 0x29 Authentication and is separate from NRC codes. These are positive-response status codes that guide the state machine.
| returnValue | Meaning | Next Expected Step |
|---|---|---|
| 0x00 | Request accepted, no further action | Session closed / de-authenticated |
| 0x01 | Certificate OK — ownership proof not needed (rare, pre-configured trust) | Session open |
| 0x10 | Certificate request sent to server (bidirectional pending) | Wait for ECU cert |
| 0x11 | Certificate OK — proof of ownership required | Call proofOfOwnership (0x03 or 0x07) |
| 0x12 | Proof of ownership verified — authentication successful | Session is authenticated |
| 0x13 | Certificate OK — ownership proof and certificate from server pending | Bidirectional continuation |
| 0x14 | Ownership accepted — awaiting session key confirmation | Key derivation in progress |
8. Negative Response Codes (NRC) for UDS 0x29 Authentication — Full Table
These are the authentication-specific NRC codes defined in ISO 14229-1. In any implementation of UDS 0x29 Authentication, all of these must be handled on the tester side.
| NRC Code | Name | Meaning |
|---|---|---|
| 0x12 | subFunctionNotSupported | The requested sub-function is not supported |
| 0x13 | incorrectMessageLengthOrInvalidFormat | Wrong byte length or malformed request |
| 0x22 | conditionsNotCorrect | Prerequisites not met (wrong session type) |
| 0x24 | requestSequenceError | Sub-functions called out of order |
| 0x31 | requestOutOfRange | Invalid parameter values |
| 0x33 | securityAccessDenied | General access denial |
| 0x34 | authenticationRequired | Service requires authentication but client is not authenticated |
| 0x50 | certificateVerificationFailed_InvalidTimePeriod | Certificate is expired or not yet valid |
| 0x51 | certificateVerificationFailed_InvalidSignature | Certificate signature invalid |
| 0x52 | certificateVerificationFailed_InvalidChainOfTrust | Chain does not lead to trusted Root CA |
| 0x53 | certificateVerificationFailed_InvalidType | Wrong certificate type for this operation |
| 0x54 | certificateVerificationFailed_InvalidFormat | Certificate format unrecognized |
| 0x55 | certificateVerificationFailed_InvalidContent | Certificate content invalid |
| 0x56 | certificateVerificationFailed_InvalidScope | Certificate scope does not cover this ECU |
| 0x57 | certificateVerificationFailed_InvalidCertificate | Certificate is revoked |
| 0x58 | ownershipVerificationFailed | Signature does not match (wrong private key) |
| 0x59 | challengeCalculationFailed | ECU could not generate a random nonce |
| 0x5A | settingAccessRightsFailed | ECU could not apply the role from the certificate |
| 0x5B | sessionKeyCreationOrDerivationFailed | Could not derive session key |
| 0x5C | configurationDataUsageFailed | authenticationConfiguration data is invalid |
| 0x5D | deAuthenticationFailed | deAuthenticate operation failed — ECU may still be unprotected |
Note on 0x52 vs 0x57: NRC 0x52 (invalid chain of trust) fires when the chain breaks — for example, the leaf certificate was not signed by an intermediate the ECU recognizes, or the intermediate was not signed by the ECU’s trusted Root CA. NRC 0x57 fires specifically when the certificate has been explicitly revoked via CRL or OCSP — the chain is valid but the certificate has been blacklisted.
9. The Certificate Chain — Root CA, Intermediate, and Leaf
Understanding the certificate hierarchy is fundamental to implementing UDS 0x29 Authentication correctly. The Automotive PKI used in 0x29 follows the standard X.509 three-tier hierarchy.
The Three Certificate Layers
Root CA (Certificate Authority)
The Root CA is the apex of the trust hierarchy. Its public key is embedded in the ECU at manufacturing time — this is called the trust anchor. The Root CA private key is kept in the most heavily secured HSM infrastructure the OEM operates. In production, the Root CA never directly signs tester certificates — it only signs Intermediate CA certificates. This limits exposure: if an Intermediate CA is compromised, the Root CA is not affected.
Intermediate CA
The Intermediate CA issues certificates to specific categories of diagnostic entities — dealer tools, supplier tools, OEM backends, etc. An OEM may operate multiple Intermediate CAs, one per partner category, allowing fine-grained revocation. If the “Supplier X” Intermediate CA is revoked, all certificates it issued are automatically invalid, and no other category is affected.
Leaf Certificate (Tester/Tool Certificate)
This is the certificate held by the individual diagnostic tool, backend server, or manufacturing tester. It contains:
- The tester’s public key
- The tester’s identity (OEM code, tool serial, organization)
- The validity period (NotBefore, NotAfter)
- Key Usage and Extended Key Usage fields (which operations are permitted)
- Role/permission metadata (often in custom X.509 extensions or the Subject field)
- The Intermediate CA’s digital signature
Generating a PKI for 0x29 Development (OpenSSL Commands)
bash
# Step 1: Generate Root CA private key (4096-bit RSA for Root, 256-bit EC for production)
openssl ecparam -name prime256v1 -genkey -noout -out root_ca.key
# Step 2: Generate self-signed Root CA certificate (valid 10 years)
openssl req -new -x509 -key root_ca.key -out root_ca.crt -days 3650 \
-subj "/C=DE/O=OEM-Automotive/OU=PKI-Root/CN=OEM-Root-CA"
# Step 3: Generate Intermediate CA key and CSR
openssl ecparam -name prime256v1 -genkey -noout -out intermediate_ca.key
openssl req -new -key intermediate_ca.key -out intermediate_ca.csr \
-subj "/C=DE/O=OEM-Automotive/OU=Dealer-CA/CN=OEM-Dealer-Intermediate"
# Step 4: Sign Intermediate CA with Root CA
openssl x509 -req -in intermediate_ca.csr -CA root_ca.crt -CAkey root_ca.key \
-out intermediate_ca.crt -days 1825 -CAcreateserial \
-extensions v3_ca -extfile openssl.cnf
# Step 5: Generate Tester (Leaf) key and CSR
openssl ecparam -name prime256v1 -genkey -noout -out tester.key
openssl req -new -key tester.key -out tester.csr \
-subj "/C=DE/O=Dealer-ABC/OU=DealerTool/CN=DealerTool-SN-0042"
# Step 6: Sign Tester certificate with Intermediate CA (valid 2 years)
openssl x509 -req -in tester.csr -CA intermediate_ca.crt -CAkey intermediate_ca.key \
-out tester.crt -days 730 -CAcreateserial
# Step 7: Convert Root CA certificate to DER for ECU embedding
openssl x509 -in root_ca.crt -out root_ca.der -outform DER
# This root_ca.der is what gets pre-installed in the ECU at manufacturing10. Role-Based Access Control — How ECU Authentication Maps to Permissions
One of the most powerful capabilities that UDS 0x29 Authentication introduces is genuine role-based access control (RBAC) at the diagnostic layer. This is something fundamentally impossible with 0x27.
How Roles Are Encoded
Roles are embedded in the tester’s certificate. The most common approaches are:
- Subject Distinguished Name (DN): The OU (Organizational Unit) or CN (Common Name) field encodes the role string. For example:
OU=DealerServiceToolorCN=SupplierX-LimitedAccess - Custom X.509 Extension: An OEM-defined OID carries a structured role/permission bitmap. This is the most flexible approach and the one recommended for complex multi-level permission schemes.
- Certificate Policy OID: Standard X.509 Certificate Policy extension with OEM-defined policy OIDs that the ECU maps to access rights.
The Role Hierarchy
A typical automotive PKI for UDS 0x29 Authentication implements four to six role levels:
OEM / Backend (Full Access) Certificates held by OEM cloud backends. These grant access to all diagnostic services on all ECUs, including ECU reprogramming, security configuration, key injection, and RDE (Remote Diagnostic Enable). These are only used in automated backend-to-ECU connections, never in human-operated tools.
Manufacturing / EOL Tester Certificates held by end-of-line production testers. Grant access to initial ECU configuration, key provisioning, ECU flash programming, and calibration. These certificates expire after the manufacturing period.
Dealer / Authorized Service Tool The most common certificate type in field use. Grants access to DTC reading and clearing, ECU flashing (for approved updates), live data viewing, input/output control, and routine execution. Does not grant access to security configuration or key management.
Supplier / Technical Partner Limited-access certificates for suppliers who need to diagnose their specific ECU or sub-component. Grants access only to the DIDs, DTCs, and routines associated with that supplier’s domain. Cannot access other ECUs or cross-domain data.
Workshop / General Technician Read-only or minimal-write certificates for independent garages. Grants access to DTC reading, basic live data, and standardized OBD-equivalent functions. No ECU flashing.
How the ECU Applies the Role
Authentication complete (returnValue = 0x12)
↓
ECU extracts role identifier from certificate
↓
ECU looks up role in internal permission table
↓
Permission table maps role → allowed SIDs + allowed DIDs + allowed RIDs
↓
For every subsequent UDS request in this session:
IF requested_SID is in allowed_SIDs for current_role:
process request
ELSE:
return NRC 0x34 (authenticationRequired) or 0x33 (securityAccessDenied)11. AUTOSAR Classic DCM Integration
For those implementing UDS 0x29 Authentication on AUTOSAR Classic platforms, here is a summary of where 0x29 sits in the BSW layer cake.
DCM Module (Diagnostic Communication Manager)
The DCM is the AUTOSAR module responsible for processing all UDS service requests, including UDS 0x29 Authentication. The DCM manages the authentication state machine per physical connection — meaning each separate CAN channel (or DoIP channel) maintains its own authentication state independently.
The DCM in AUTOSAR 4.4.0 and later supports APCE mode natively. ACR is outside AUTOSAR DCM scope and requires custom implementation.
Key Configuration Points in DCM
- DcmDspAuthentication: The configuration container for 0x29. Set
DcmDspAuthenticationEnabled = TRUE. - DcmDspAuthenticationRole: Defines roles and their associated permission sets.
- DcmDspAuthenticationClass: Maps role to a set of allowed DIDs, services, and sessions.
- DcmDspCertificateReference: Points to the Root CA certificate pre-configured in the BSW.
CSM (Crypto Service Manager)
All cryptographic operations for UDS 0x29 Authentication — certificate validation, signature verification, ECDH key derivation — are routed through the CSM module. The CSM abstracts the underlying hardware: it can call an HSM (Hardware Security Module) driver, a software crypto library, or a dedicated crypto accelerator depending on the hardware platform.
For production-grade AUTOSAR ECUs, all private keys are stored in the HSM and never exposed to the application layer. The CSM interface ensures that the ECU’s private key is used only for signing inside the HSM boundary — the CSM passes data in, and gets a signature out, without the private key material ever crossing the hardware boundary.
AUTOSAR Session Key Limitation
An important note for implementation: as of current AUTOSAR DCM specifications, session key derivation (the optional feature in proofOfOwnership responses that enables secure communication via 0x84 SecuredDataTransmission) is not yet fully supported in AUTOSAR DCM. If your ECU implementation requires encrypted diagnostic data transport in addition to authentication, you will need a custom AUTOSAR extension or a non-AUTOSAR stack component.
12. UDS 0x29 Authentication vs. 0x27 Security Access — The Complete Comparison
| Comparison Dimension | UDS 0x27 Security Access | UDS 0x29 Authentication |
|---|---|---|
| Security Model | Shared secret / seed-key | Certificate + PKI identity |
| Identity Verification | None — proves knowledge only | Full cryptographic identity |
| Standardization | OEM-specific algorithms | ISO 14229-1 standardized |
| PKI Integration | None | Full PKI lifecycle |
| Role Granularity | None — binary locked/unlocked | Multi-level role-scoped sessions |
| Revocation | None — reflash required | CRL / OCSP revocation |
| Scalability | Per-ECU secrets | Interoperable across fleet |
| OTA / Backend Use | Not suitable | Designed for backend auth |
| AUTOSAR Support | Yes (since early releases) | Yes (from AUTOSAR 4.4.0) |
| ISO 15765-4 Status | Deprecated direction | Recommended modern approach |
| Replay Attack Protection | Limited (nonce-based) | Strong (certificate + nonce) |
| Implementation Complexity | Low | Higher but standardized |
13. Real-World Use Cases for UDS 0x29 Authentication
OTA (Over-The-Air) Update Authorization
Every OTA update session begins with the OEM backend authenticating to each target ECU using UDS 0x29 Authentication with bidirectional certificate verification. The backend’s certificate encodes OEM-level permissions, granting authorization to request firmware download (0x34 RequestDownload) and transfer (0x36 TransferData). If the backend’s certificate is revoked due to a security incident, OTA updates are blocked fleet-wide without modifying any ECU firmware.
Manufacturing and End-of-Line Provisioning
Factory testers authenticate using time-limited manufacturing-role certificates to perform initial ECU configuration, inject cryptographic keys, and provision the ECU’s own identity certificate (via sub-function 0x05 transmitCertificate). The manufacturing certificate expires at a defined time after production, ensuring that EOL-level access is not available in the field.
Dealer Service and Diagnostics
Authorized dealer tools carry OEM-issued dealer certificates that grant service-level access to the ECU’s diagnostic capabilities. When a dealer’s tool certificate expires or the dealership loses its authorization, the ECU simply refuses authentication — the tool still physically connects, but it cannot get past step 0x01 of the UDS 0x29 Authentication flow.
Supplier-Scoped Access
A transmission supplier needs to perform field diagnostics on their TCM (Transmission Control Module) but should not have access to the engine ECU, body control module, or ADAS processors. Their supplier certificate encodes a scope that the ECU enforces — the Automotive PKI makes this granularity possible without any per-ECU code changes.
Cybersecurity Incident Response
A Vehicle Security Operations Center (VSOC) running a cybersecurity audit needs read-only access to diagnostic data from all ECUs in a fleet for forensic analysis after a detected intrusion. The VSOC’s certificate encodes a read-only audit role — UDS 0x29 Authentication ensures the VSOC tool can read data but cannot write or reprogram anything.
14. Engineering Reality Check — What UDS 0x29 Authentication Does NOT Guarantee
This is the most important section for any engineer deploying UDS 0x29 Authentication in production.
The protocol standardizes the authentication handshake and provides a framework for identity, roles, and PKI. But security is end-to-end. UDS 0x29 Authentication is one layer. The following weaknesses exist independently of the protocol:
Weak key storage destroys the entire model. If the tester’s private key is stored as a plain file on a Windows laptop instead of in a hardware security token, the key can be stolen. Once stolen, the attacker has a fully valid certificate-key pair and can authenticate as that tester indefinitely (until the certificate is revoked).
Revocation only works if the ECU checks it. CRL checking requires the ECU to have access to a current CRL — either via OTA delivery or by connecting to an OCSP responder. If the ECU never checks revocation (for cost or complexity reasons), a revoked certificate can still authenticate forever.
Secure Boot and code signing are separate. An authenticated session means an authorized entity is connected. It does not mean the firmware running on the ECU is legitimate. A compromised firmware that passes Secure Boot validation cannot be detected by the 0x29 authentication layer.
PKI infrastructure must be protected. If the Root CA private key is compromised, every certificate ever issued by that CA is potentially forged. Root CA key protection — hardware HSMs, offline storage, ceremony procedures — is the most critical security investment in any Automotive PKI deployment.
The state machine must be implemented correctly. Sub-function ordering, replay protection (nonce uniqueness), session timeout handling, and multi-connection isolation are all implementation responsibilities not covered by the protocol specification alone. A subtle state machine bug — for example, allowing proofOfOwnership to be called multiple times with different signatures until one succeeds — can completely bypass authentication.
A proper implementation of UDS 0x29 Authentication, combined with Secure Boot, code signing, HSM-based key storage, and rigorous PKI lifecycle management, delivers enterprise-grade security to automotive diagnostics. Any one of these layers missing significantly weakens the whole.
15. Implementation Checklist for UDS 0x29 Authentication
Use this checklist when implementing or reviewing a UDS 0x29 Authentication integration:
Protocol Implementation
- authenticationConfiguration (0x09) responds correctly with supported modes and algorithms
- State machine enforces correct sub-function ordering — NRC 0x24 on out-of-order calls
- Nonces are generated from a true random source (TRNG or HSM-seeded PRNG)
- Certificate chain validation includes expiry check, signature verification, and chain-of-trust
- Revocation check is implemented (CRL lookup minimum, OCSP if online connectivity exists)
- returnValue codes correctly reflect each state transition
- All 14 authentication-specific NRC codes are implemented and returnable
- Session state is isolated per physical connection (separate CAN channels, separate states)
- deAuthenticate (0x00) correctly resets all role-scoped permissions
Cryptographic Implementation
- Private keys stored in HSM — never in software memory or flash in cleartext
- ECDSA P-256 with SHA-256 is the minimum algorithm level
- Certificate parsing handles DER encoding correctly
- Signature verification uses the public key from the validated certificate only
PKI Infrastructure
- Root CA certificate pre-installed in ECU production flash
- Certificate validity periods are defined per role (not infinite)
- CRL distribution mechanism exists and is configured
- Certificate format includes role/permission metadata in defined fields
Testing
- Test with expired certificate → NRC 0x50
- Test with revoked certificate → NRC 0x57
- Test with wrong signature → NRC 0x58
- Test out-of-order sub-functions → NRC 0x24
- Test with certificate signed by untrusted CA → NRC 0x52
- Verify session permissions are actually enforced post-authentication
- Verify deAuthenticate clears all permissions
Summary
UDS 0x29 Authentication Service is the foundational security primitive of modern automotive diagnostics. Introduced in ISO 14229-1:2020, it brings genuine identity, PKI-based trust, and role-scoped access control to a domain that for decades relied on shared secrets.
The nine sub-functions — deAuthenticate, verifyCertificateUnidirectional, verifyCertificateBidirectional, proofOfOwnership (unidirectional and bidirectional), transmitCertificate, requestChallengeForAuthentication, verifyProofOfOwnershipUnidirectional, verifyProofOfOwnershipBidirectional, and authenticationConfiguration — together form a complete, standards-based authentication framework that works across CAN, Ethernet (DoIP), LIN, and FlexRay transport layers.
UDS 0x29 Authentication addresses every shortcoming of 0x27 Security Access: it provides identity (not just secret knowledge), role granularity (not just binary unlock), revocation (not just reflash), interoperability (not OEM-specific algorithms), and scalability to OTA, fleet, and backend architectures that define the connected vehicle era.
But it is one layer, not the entire solution. Combined with Secure Boot, HSM-backed key management, code signing, OCSP revocation infrastructure, and rigorous AUTOSAR DCM configuration, UDS 0x29 Authentication delivers the identity-aware, role-scoped, PKI-anchored diagnostic security model that ISO/SAE 21434 and UNECE WP.29 R155 compliance demands.
For automotive engineers building the next generation of ECU security, mastering UDS 0x29 Authentication is not optional — it is the foundation everything else is built on.
Related Articles on piembsystech.com:
- UDS 0x27 Security Access — Deep Dive with Hex Examples
- AUTOSAR DCM Configuration Guide — Sessions, Security, and Authentication
- Automotive PKI Design for ISO/SAE 21434 Compliance
- SecOC (Secure Onboard Communication) vs. UDS 0x29 Authentication — When to Use Which
- CAN Bus UDS Protocol Complete Tutorial
Discover more from PiEmbSysTech - Embedded Systems & VLSI Lab
Subscribe to get the latest posts sent to your email.
