UDS Security Access (0x27) vs. Authentication (0x29)

Executive Summary

Every embedded ECU that supports firmware flashing, calibration writes, or protected diagnostics must answer a fundamental question: who is allowed in, and how do you prove it? For two decades, UDS Security Access (Service 0x27) handled this with a seed-and-key challenge-response mechanism. In 2020, ISO 14229-1 introduced Authentication (Service 0x29) to address 0x27's structural limitations in connected vehicle environments.

This article provides a service-level deep dive into both mechanisms: how each protocol exchange works byte by byte, what cryptographic assumptions each makes, where each fails, and how to decide which belongs in your bootloader, diagnostic stack, or OTA pipeline.

1. UDS Security Architecture: The Bigger Picture

1.1 Where Authentication Sits in a UDS Session

The Unified Diagnostic Services protocol (ISO 14229-1) structures ECU access as a layered state machine. Before any sensitive service can execute — firmware download (0x34/0x36/0x37), calibration write (0x2E), routine control (0x31) — the tester must occupy the right session and hold the correct security level.

The session ladder works as follows:

• Default Session (0x01): read-only DTC access, no security required.
• Extended Diagnostic Session (0x03): calibration and configuration writes gated behind 0x27 or 0x29.
• Programming Session (0x02): firmware flash operations — the most sensitive context, requires the highest security level.

A tester that drops out of a non-default session (S3Server timeout, ECUReset, or session change) immediately loses its unlocked security level. Every state transition resets the lock. This design choice means authentication is not a one-time ceremony but an active, session-scoped credential.

1.2 The Two Gating Mechanisms

ISO 14229-1:2020 preserves both security services in the standard:

Service 0x27 — SecurityAccess: A challenge-response protocol where the ECU issues a random seed and the tester must return the correct key derived from a shared secret algorithm. The algorithm and key material are OEM-defined and not standardized by ISO.

Service 0x29 — Authentication: Introduced in ISO 14229-1:2020. Supports asymmetric PKI certificate exchange (APCE) and symmetric challenge-response (ACR), with optional bidirectional mutual authentication and session key derivation.

2. Service 0x27 — Security Access: Protocol Deep Dive

2.1 The Seed-and-Key Protocol

Service 0x27 implements a symmetric challenge-response. The ECU (server) and tester (client) share knowledge of a secret algorithm and key material. The ECU verifies the tester's identity by confirming it can produce the correct transformation of a random challenge — the seed.

2.1.1 Message Flow

Step 1 — RequestSeed (subfunction = odd: 0x01, 0x03, 0x05... depending on security level):

Step 2 — Positive Response to RequestSeed (Response SID = 0x67):

Special case: If the ECU is already unlocked at the requested level, it returns a seed of all zeros. The tester must detect this and skip the SendKey step.

Step 3 — SendKey (subfunction = even: 0x02, 0x04, 0x06... level + 1):

Step 4 — Positive Response to SendKey (0x67 + even subfunction). The ECU transitions to the unlocked security level. All subsequent requests in the current session may now access protected services.

2.1.2 Multi-Level Access Architecture

A single ECU commonly exposes multiple security levels, each with a separate seed-key pair and a distinct algorithm or key material:

Each level requires an independent seed-key exchange. Unlocking Level 3 does not imply Level 1 is unlocked. On any session change, ECUReset, or S3Server timeout, the ECU drops to security level 0x00 and the tester must re-authenticate.

2.2 Cryptographic Patterns in 0x27 Implementations

2.2.1 Historical (Weak) Implementations

• Fixed seed: ECU always returns the same seed value. The key is trivially precomputed.
• Simple XOR or CRC: Key = seed XOR constant, or CRC8/CRC16 of seed with a secret polynomial. Vulnerable to brute-force given a few seed-key pairs.
• Deterministic pseudo-random seeds via LFSR: An attacker observing CAN traffic (broadcast — no confidentiality) can reconstruct the seed sequence.

These weaknesses are not theoretical. CAN's broadcast nature means all bus nodes receive every frame, including seed-key exchanges. A passive observer can accumulate seed-key pairs and recover weak algorithms through reverse engineering or brute force.

2.2.2 Modern (Hardened) Implementations

• HMAC-SHA256:Key = Truncate(HMAC-SHA256(K_device, seed || level || context_data)). K_device stored in HSM or secure element. This is the recommended pattern.
• AES-128-CMAC:Seed encrypted or MACed with a stored AES key. Computationally secure if key storage is protected.
• HKDF-based key derivation:Seed used as input keying material; context binds level and session, preventing key reuse across levels.

2.3 Negative Response Codes and Lockout Policy

AUTOSAR DCM configuration parameters governing lockout behavior:

• DcmDspSecurityNumAttDelay: number of consecutive wrong keys before lockout (typically 3-5).
• DcmDspSecurityDelayTime: lockout duration in milliseconds (typically 10,000 ms).
• DcmDspSecurityADPUnlockAttemptCounterEnabled: if TRUE, counter persists in NvM across power cycles.

2.4 AUTOSAR DCM Integration for 0x27

In AUTOSAR Classic, Service 0x27 is handled by the DCM module via DcmDspSecurityRow containers — one per security level. Key parameters:

• DcmDspSecurityGetSeedFnc: callback generating the seed (must call TRNG).
• DcmDspSecurityCompareKeyFnc: callback computing the expected key from seed and comparing to tester-supplied key — this is where HMAC-SHA256 lives.
• DcmDspSecurityADPUnlockAttemptCounterEnabled: enables NvM persistence of lockout counter.

With AUTOSAR Classic, there is a single Security Access Level state machine globally, regardless of physical connection channel. A tester on CAN and a tester on Ethernet share the same state — important for multi-interface ECUs.

3. Service 0x29 — Authentication: Protocol Deep Dive

Service 0x29 was introduced in ISO 14229-1:2020 to address structural limitations of 0x27 in connected vehicle environments. It defines a standardized authentication framework with two primary modes and optional bidirectional mutual authentication and session key derivation.

3.1 Authentication Modes Overview

Both modes support two authentication directions:

• Unidirectional: ECU verifies the tester's identity only.
• Bidirectional: Both ECU and tester authenticate each other. Required for OTA and remote diagnostics over untrusted networks.

3.2 APCE Mode — Authentication with PKI Certificate Exchange

APCE is the primary 0x29 mode natively supported by AUTOSAR DCM (from AUTOSAR 4.4.0). It uses X.509 certificates and asymmetric cryptography — typically ECDSA P-256 — to establish identity without sharing secret keys.

3.2.1 PKI Trust Structure

• Root CA: OEM-controlled root of trust. Signs Intermediate CAs.
• Intermediate CA: Issues certificates to suppliers, service tools, and ECUs.
• Tester Certificate: Issued to a specific diagnostic tool. Contains public key and identity attributes.
• ECU Certificate: Contains ECU's public key, optionally bound to VIN or part number.

Each certificate has an expiration date. Revocation is managed via CRLs or OCSP-like mechanisms. Unlike 0x27 where key material is typically static for the ECU's lifetime, certificate lifecycle management enables selective revocation and time-limited access.

3.2.2 Unidirectional APCE Flow

3.2.3 Bidirectional APCE Flow

• Tester sends verifyCertificateBidirectional (0x02), including its certificate AND a challenge nonce for the ECU.
• ECU sends back its own certificate, its signature over the tester's challenge, plus the ECU's challenge for the tester.
• Tester verifies the ECU's certificate and signature, then sends proofOfOwnership (0x03) signing the ECU's challenge.
• ECU verifies the tester's proof; both parties have authenticated each other.

3.3 ACR Mode — Authentication with Challenge-Response

ACR mode simplifies 0x29 deployment for resource-constrained ECUs that cannot support full PKI infrastructure. Instead of exchanging certificates, the ECU and tester rely on pre-shared symmetric keys or pre-installed asymmetric public keys.

ACR avoids PKI complexity but shares 0x27's vulnerability to key compromise: a leaked pre-shared key allows any device to authenticate. Unlike APCE, compromised ACR keys cannot be selectively revoked without re-provisioning all affected ECUs. AUTOSAR DCM does not natively support ACR — it requires custom callout implementation.

3.4 Role-Based Access vs. Level-Based Access

One of 0x29's most significant architectural shifts is the move from numeric security levels to role-based access control. A tester authenticates to a named role — OEM_Engineering, SupplierA_EOL, AfterSales_Technician — rather than unlocking 'Level 3.'

Each role maps to a permitted set of services, DIDs, and routines defined in ECU configuration and referenced in the tester's certificate attributes (e.g., X.509 extension fields). This enables fine-grained access:

• Dealership technician certificate: read-DTC access and actuator tests only.
• Tier-1 supplier certificate: flash programming rights for their specific software module.
• OEM engineering certificate: full diagnostic access including factory routines.

3.5 AUTOSAR DCM Integration for 0x29

• DcmDspAuthenticationConfiguration: links to the Csm (Crypto Service Manager) for certificate verification and signature operations.
• DcmDspAuthenticationClass: specifies APCE or ACR (ACR requires custom implementation).
• DcmDspAuthenticationCertificateEvaluationFnc: callback invoked after DCM verifies certificate chain; application layer inspects certificate attributes to determine role assignment.
• DcmDspAuthenticationAccessRights: maps role identifiers to allowed services and DIDs.

With AUTOSAR Adaptive, the 0x29 authentication state machine is per physical connection — unlike Classic where it is global. This enables multi-client Ethernet diagnostics where different testers on different channels hold independent authentication states.

4. Side-by-Side Comparison

5. Attack Surface Analysis

5.1 Attacks on 0x27

5.1.1 Seed Observation and Brute Force

CAN is a broadcast bus — every node receives every frame, including seed-key exchanges. A passive observer accumulating seed-key pairs can apply brute force or lookup table attacks against weak algorithms. For a 16-bit seed space (65,536 values), a complete lookup table is achievable over a vehicle's diagnostic history. XOR and CRC-based algorithms have been publicly documented for numerous OEM implementations.

5.1.2 Algorithm Reverse Engineering

Seed-key algorithms are embedded in diagnostic tester software and ECU firmware. DLL extraction from Windows-based tester tools has historically exposed OEM algorithms. ECU firmware extraction via JTAG, voltage glitching, or side-channel attacks can expose the computation directly.

Mitigation: Store K_device in an HSM or secure element with anti-extraction properties. Use per-device key material (HKDF with hardware UID) so compromise of one ECU does not cascade.

5.1.3 Lockout Bypass

If the attempt counter is RAM-only, toggling ignition resets the lockout. An attacker with physical access can attempt unlimited brute-force with ~3 attempts per boot cycle.

Mitigation: Persist the attempt counter in NvM. Consider progressive delays (10s, 60s, 300s) rather than a fixed delay per lockout event.

5.2 Attacks on 0x29

5.2.1 Certificate Infrastructure Attacks

APCE security depends entirely on the PKI chain. A compromised Root CA private key allows an attacker to issue certificates granting arbitrary roles. Certificate management — key ceremony procedures, HSM storage, CA revocation — becomes a critical operational security discipline.

5.2.2 Replay Attacks

A 2024 academic evaluation (CSCS '24, ACM) demonstrated practical replay-based attacks against 0x29 implementations that did not correctly enforce nonce freshness. Both APCE and ACR include nonce-based challenges to defeat replay, but weak PRNG usage or failure to enforce single-use nonces creates exploitable windows.

Mitigation: Use a TRNG for challenge generation. Enforce each challenge is single-use within a session. Embed a monotonic counter or timestamp in the signed data.

5.2.3 Man-in-the-Middle on Remote Diagnostics

Remote diagnostics over cellular or Wi-Fi expose the channel to man-in-the-middle attacks impossible on physical CAN. Without bidirectional authentication and session key derivation (0x84), even an authenticated 0x29 session can have subsequent diagnostic traffic intercepted and manipulated.

Mitigation: For OTA and remote diagnostics, mandate bidirectional APCE with DHE session key derivation and SecuredDataTransmission (0x84) for all post-authentication frames.

6. Bootloader Integration: Practical Patterns

6.1 The Standard ECU Flash Programming Sequence

Security gates Step 2: the 0x34/0x36/0x37 download sequence must be blocked until the tester holds the correct security level (0x27) or authenticated role (0x29). In AUTOSAR DCM, DcmDspServiceSecurityLevelRef and DcmDspServiceSessionRef enforce this declaratively in configuration.

6.2 0x27 in Bootloaders: Why It Dominates

• Memory footprint: HMAC-SHA256 requires ~4-8 KB of flash. A PKI ECDSA stack requires 20-50+ KB.
• ROM constraints: Microcontrollers with 64-256 KB flash (common in gateway, body, and sensor ECUs) cannot accommodate a full mbedTLS or wolfSSL stack in the bootloader partition.
• Boot time: ECDSA on a Cortex-M0+ without hardware crypto acceleration can take 500+ ms — unacceptable in a production bootloader.
• Tooling maturity: OEM flash tools, J2534 pass-throughs, and tester suites have extensive 0x27 support. Migrating to 0x29 requires tester-side PKI integration and certificate provisioning workflows.

6.3 0x29 APCE in Bootloaders: When It Applies

• The ECU runs on an SoC with hardware cryptographic acceleration (AES engine, PKA, SHA engine). Cortex-M4F/M33 class processors with dedicated crypto units can complete ECDSA P-256 verification in under 50 ms.
• The ECU supports OTA firmware updates over Automotive Ethernet (DoIP). Mutual authentication and session key derivation are mandatory for any credible OTA security posture.
• UN Regulation No. 156 (SUMS) or ISO/SAE 21434 compliance requires demonstrable update access control auditability. APCE's certificate-based traceability directly satisfies audit requirements.

7. Migration Strategy: From 0x27 to 0x29

7.1 Coexistence: Running Both Services

ISO 14229-1 does not prohibit an ECU from supporting both 0x27 and 0x29 simultaneously. A common migration pattern:

• Continue 0x27 for in-workshop physical diagnostics. Dealership tooling retains backward compatibility.
• Require 0x29 APCE for any OTA or remote diagnostic path over DoIP/Ethernet. The gateway enforces transport-specific security requirements.
• Deprecate 0x27 for programming operations over model generations as tooling catches up.

7.2 Strengthening 0x27 While Migrating

7.3 PKI Infrastructure Planning for 0x29

• Root CA key ceremony: offline HSM, dual-control procedures, physical security.
• Certificate profiles: X.509 v3 extension structure for role encoding, ECU binding (VIN, part number), validity period policy.
• Tester certificate issuance: supplier onboarding, tool provisioning, certificate request/signing workflow.
• Revocation: CRL distribution point configuration in certificates, update cadence, ECU-side CRL storage and refresh mechanism.
• ECU certificate provisioning: manufacturing-line provisioning of ECU certificates and private keys into secure storage; HSM-backed key generation preferred.

8. Decision Framework

9. Frequently Asked Questions

Is 0x27 deprecated?

ISO 15765-4 (the CAN-specific UDS transport) has deprecated 0x27. ISO 14229-1 itself still includes both services. For new ECU designs, 0x29 is the recommended direction, but 0x27 remains widely deployed and is dominant in production vehicles through at least the 2025-2026 model years.

Can 0x27 be made secure enough for production use?

Yes, with the right implementation. 0x27 with HMAC-SHA256, a per-device key in an HSM, a TRNG-generated 128-bit seed, and a NvM-persisted lockout counter is computationally secure. The residual risk is key management: a compromised K_device affects all ECUs sharing that key. Per-device key derivation via HKDF with the hardware UID limits blast radius significantly.

Does 0x29 replace 0x27 in AUTOSAR?

AUTOSAR Classic DCM supports both. AUTOSAR 4.4.0 added 0x29 APCE support natively. The two services coexist and are not mutually exclusive in configuration. AUTOSAR Adaptive natively supports 0x29 with per-connection authentication state machines.

What is the relationship between 0x29 and SecuredDataTransmission (0x84)?

Service 0x84 encrypts and authenticates individual diagnostic messages using a session key derived during a 0x29 APCE exchange with DHE enabled. Without 0x29, there is no standardized UDS mechanism to derive a per-session key for 0x84. Service 0x27 does not produce a session key.

What cryptographic algorithms does 0x29 standardize?

ISO 14229-1:2020 defines algorithm suites including ECDSA P-256 and P-384 for signatures, AES-128-GCM and AES-256-GCM for session encryption (combined with 0x84), SHA-256 and SHA-384 for hashing, and ECDH for key agreement. The communicationConfiguration sub-function negotiates the specific suite.

10. Summary

Service 0x27 Security Access is a mature, broadly deployed mechanism well-suited to resource-constrained ECUs with physical diagnostic access models. Its weakness is not fundamental — a well-implemented 0x27 with HMAC-SHA256 and per-device keys is computationally sound — but structural: it cannot provide bidirectional mutual authentication, certificate-based role management, or session key derivation for encrypted channels.

Service 0x29 Authentication solves these structural problems at the cost of PKI infrastructure complexity and asymmetric computational overhead. It is the correct choice for ECUs that participate in OTA update flows, remote diagnostics over untrusted transports, or multi-supplier access control scenarios where per-entity accountability and revocability matter.

For most embedded programs, the answer is not either/or. Existing ECUs benefit from 0x27 hardening. New platforms should design for 0x29 on the OTA path, with 0x27 retained for backward-compatible workshop access during the transition period. Both services can coexist within a single ECU, and the decision should be driven by the threat model, resource constraints, and tooling reality of each specific program.