Service Identifier: the first byte of a UDS request message that identifies which diagnostic service is being invoked (e.g., 0x27 Security Access, 0x29 Authentication).
KMS
Key Management Server: a backend system, typically hosted at the OEM's premises, that holds symmetric keys and computes values (such as a CMAC) on behalf of tester tools so the keys themselves never leave it.
ACR
Authentication Challenge-Response: the ECU checks a signature against a public key pre-installed at manufacturing, with no certificate or chain involved.
APCE
Asymmetric Proof of Possession and Certificate Exchange (certificate-based method of UDS Authentication (0x29)): the tester presents a PKI certificate and the ECU's HSM validates the chain to a Root CA before granting access.
ECDH
Elliptic Curve Diffie-Hellman: a key-agreement algorithm that lets two parties derive a shared secret (e.g., a session key) over an insecure channel without transmitting the secret itself.
NRC
Negative Response Code (ISO 14229-1): a value that ECU responds with when a diagnostic request fails, indicating the specific reason (e.g., invalid key, conditions not met etc.)
OBD
On-Board Diagnostics: the standardized system that lets external tools read a vehicle's emissions-related fault codes and live sensor data.
JASPAR
Japan Automotive Software Platform and Architecture: an industry body whose SecOC configuration is standardized as AUTOSAR SecOC Profile 3.
UDS
Unified Diagnostic Services (ISO 14229): the diagnostic communication protocol used for ECU testing, configuration and key updates.
RTE
Runtime Environment: the AUTOSAR layer that connects application software components to the basic software (BSW).
SHE
Secure Hardware Extension: an automotive standard for a lightweight on-chip security module and key store, often used to hold the keys an HSM works with.
I-PDU
Interaction layer PDU: the application-level PDU that carries signals between ECUs in AUTOSAR communication. SecOC protects the Authentic I-PDU and produces the Secured I-PDU.
JTAG
Joint Test Action Group — Standardized hardware interface (IEEE 1149.1) for testing, debugging, and programming chips. Provides low-level access to internals, often targeted in security attacks.
AUTOSAR
AUTomotive Open System ARchitecture — Standardized automotive software architecture for scalable, reusable software across vehicle platforms. Defines layered components, communication mechanisms, and configuration methods.
ARXML
AUTOSAR XML — XML-based file format describing AUTOSAR software components, interfaces, and configurations. Standard data exchange format between AUTOSAR development tools.
AES
Advanced Encryption Standard — Symmetric block cipher standardized by NIST, encrypting data in 128-bit blocks with 128/192/256-bit keys. Core building block in automotive cybersecurity.
HSM
Hardware Security Module — Tamper-resistant hardware component securely storing cryptographic keys and performing crypto operations. Isolates security-critical functions from the main ECU processor.
FVM
Freshness Value Manager — AUTOSAR SecOC sub-module managing freshness values (counters) used to prevent replay attacks. Provides, tracks, and verifies freshness values for authenticated messages.
MAC
Message Authentication Code — Cryptographic checksum using a secret key to verify message integrity and authenticity. Confirms data is unaltered and from a legitimate sender.
CMAC
Cipher-based Message Authentication Code — MAC construction built from a block cipher, standardized as AES-CMAC. Widely used in SecOC to authenticate CAN/Ethernet messages.
ECU
Electronic Control Unit — Embedded computer controlling vehicle subsystems like engine, brakes, or infotainment. Modern cars contain dozens, networked via CAN, LIN, or Ethernet.
PDU
Protocol Data Unit — Data unit exchanged between network layers, containing payload plus protocol control info. Basic building block in AUTOSAR COM/PduR routing.
SecOC
Secure Onboard Communication — AUTOSAR module authenticating in-vehicle messages via freshness counter and truncated MAC. Protects against replay attacks without full encryption.
GB/T
Guobiao Tuijian. China's recommended national standards, including its EV charging connector and protocol.
Pt1000
A platinum resistance temperature sensor (1000 ohms at 0 degrees C) used to monitor contact temperature.
10BASE-T1S
A single-pair Ethernet variant for short, low-speed links, used by the Megawatt Charging System in place of powerline communication.
AFIR
Alternative Fuels Infrastructure Regulation. An EU regulation setting targets and requirements for alternative-fuel infrastructure, including EV charging.
BMS
Battery Management System. The electronics that monitor and protect a battery pack, managing its charge, voltage, temperature and safety.
CAN
Controller Area Network. A robust bus standard that lets controllers and devices communicate without a central computer, widely used in vehicles.
DIN
Deutsches Institut fuer Normung. Germany's national standards organization.
DTC
Diagnostic Trouble Code. A standardized code stored by a vehicle's electronics to record a detected fault.
EVSE
Electric Vehicle Supply Equipment. The equipment that supplies electrical energy to charge an electric vehicle; in everyday terms, the charging station.
IEC
International Electrotechnical Commission. The international body that prepares and publishes standards for electrical and electronic technologies.
ISO
International Organization for Standardization. An independent body that develops and publishes worldwide technical standards.
NRMM
Non-road mobile machinery. Mobile machines not intended for use on public roads, such as construction and agricultural equipment.
RFID
Radio Frequency Identification. Identifying and reading data from a tag wirelessly using radio waves.
SAE
SAE International. A standards organization for the automotive, commercial-vehicle and aerospace industries.
TLS
Transport Layer Security. A cryptographic protocol that encrypts and authenticates data sent over a network.
VCU
Vehicle Control Unit. The central electronic controller that coordinates a vehicle's subsystems.
What is Automotive Diagnostics?
Imagine you're driving your vehicle and all of a sudden, you notice some strange behavior. You take it to the nearest mechanic or a dealer, and they inspect the vehicle and immediately tell you what the issue is.
How do they identify it?
One way is to find the root cause by physically inspecting the components, but that takes time. With the rapid development and integration of software-defined platforms into vehicles, there is a faster way. Technicians simply connect a cable and read the fault codes.
Automotive diagnostics is the term that refers to the mechanisms used to inspect, configure and troubleshoot the vehicle systems. Modern vehicle systems are equipped with diagnostic systems such as UDS and OBD, so technicians can read fault codes, configure the vehicle or perform software updates.
Why is it mandatory to secure diagnostic connections?
As diagnostic interfaces interact with various components and fetch information from various memory locations of an ECU, they open a door for attackers to reach the sensitive functions of an ECU and alter the behavior of the system, for example by disabling safety monitors or completely reprogramming the ECU. This is why securing diagnostics is mandatory.
Secure diagnostics refers to restricting diagnostic operations to authorized dealers, engineers and technicians. Whoever wants to perform diagnostics must first unlock the ECU with a valid key; only then are they allowed to proceed.
How can Secure Diagnostics be implemented?
The UDS Security Access (0x27) service is one of the most widely used secure diagnostic mechanisms to prevent unauthorized access. The main idea behind this service is to validate the key (often output data of an algorithm) received from the tester.
Here is the step-by-step authentication process of Security Access Service 0x27:
1Tester requests a seedThe tester sends SID 0x27 with an odd subfunction, requesting a seed for a specific security level.
2ECU returns a seedThe ECU generates and returns a seed, a value that changes on every request, so a captured exchange cannot simply be replayed later.
3Tester computes the keyThe tester's diagnostic tool computes a key from that seed using an algorithm known only to the OEM, together with a secret shared with authorized tools.
4Tester sends the key backThe tester returns the computed key to the ECU with an even subfunction.
5ECU validates and respondsThe ECU computes the key internally from the same seed and compares it. A match unlocks the requested security level; a mismatch returns a negative response and can trigger a delay or lockout.
So, is one security level enough to perform secure diagnostics?
No. Diagnostic operations should not all have the same privileges, so several security levels should be implemented to differentiate between them. The vehicle manufacturer must decide how many security levels to implement and what kind of diagnostics are allowed at each level. OEMs also make sure to add strong encryption algorithms to the mix, such as AES-128 in combination with a cryptographic operations, to generate the key data, and that the seed values generated are sufficiently random.
What are the drawbacks of UDS Security Access Service 0x27?
The major drawback of Security Access service 0x27 often lies in an applied symmetric mechanism, where the (cryptographic) key material and or generation algorithm must be shared between every legitimate ECU. If a single unit is compromised, every ECU or vehicle that relies on the same algorithm becomes vulnerable to cyber-attacks.
To address this, ISO 14229-1:2020 introduced a new service, Authentication (0x29). Its primary objective is to verify the identity of a tester tool and grant access to restricted services accordingly. This can be done through certificate exchange, where the tester tool presents a signed certificate to the ECU and the ECU validates it, or through a challenge-response exchange using either asymmetric or symmetric keys. Access is granted per role, based on the certificate presented, rather than per algorithm. Authentication can also, optionally, derive a session key during the login exchange. That session key is then used with the Secured Data Transmission service (0x84) to encrypt and integrity-protect the diagnostic traffic that follows, not just the initial handshake.
Here is the detailed description of Authentication (0x29) service for APCE and ACR methods.
Variant
1Discover the methodThe tester asks via authenticationConfiguration; this ECU replies APCE.
2Certificate + client challengeRequest: the tester sends its certificate plus a client challenge, via verifyCertificateUnidirectional or Bidirectional depending on the variant toggle.
3Server challengePositive Response to that same request: a fresh server challenge, plus an optional ECDH key if a session key will be derived. Before replying, the ECU validates the certificate chain to the Root CA and extracts the tester's role in its HSM (dashed arrows -- an internal call, not a separate bus message).
+Bidirectional: verify the ECU firstWith verifyCertificateBidirectional, that same response also carries the ECU's own certificate (certificateServer). The tester verifies it against its own trusted Root CA before it signs and sends anything back -- if the ECU's certificate doesn't check out, it stops here.
4Proof of ownershipRequest: the tester -- and only the tester -- signs the server challenge with the certificate's private key and sends it via proofOfOwnership. Identical request in unidirectional and bidirectional mode; only the ECU's response differs.
5Access granted, session keyPositive Response to that same request: a match grants the role's access level, with an optional ECDH exchange for a session key for 0x84 traffic. The HSM verifies the signature against the certificate's public key internally first (dashed arrows).
+Bidirectional: the ECU's response also proves itselfThe ECU never sends a proofOfOwnership request of its own -- proof of ownership is always something the tester initiates. In bidirectional mode, the ECU's response to that same tester request additionally carries proofOfOwnershipServer: its own signature over the client challenge from step 2. The tester verifies it, completing mutual authentication.
1Discover the methodSame discovery call; this ECU replies ACR instead.
2Challenge requestThe tester asks for a challenge and names its algorithm -- no certificate involved.
3ECU returns a challengePositive Response to that same request: a fresh nonce for the requested algorithm.
4Proof of ownershipRequest: the tester -- and only the tester -- signs the challenge with a pre-shared private key and sends it via verifyProofOfOwnershipUnidirectional or Bidirectional. Same content either way; only the request code and the ECU's response differ.
5Access granted, session key optionalPositive Response to that same request: a match grants access, with a session key derived if configured. The HSM checks the signature against the pre-installed public key internally first (dashed arrows) -- no chain, no revocation check, which is what makes ACR lighter than APCE.
+Bidirectional: the ECU's response also proves itselfThe ECU never sends a proofOfOwnership request of its own. With verifyProofOfOwnershipBidirectional, the ECU's response to the tester's request additionally carries proofOfOwnershipServer -- its own signature, proving it holds the pre-installed private key -- in the same message, not a second round trip. The tester verifies it, completing mutual authentication.
Two ISO 14229-1:2020 Authentication (0x29) methods. APCE (Asymmetric Proof of Possession and Certificate Exchange) validates a certificate chain in the ECU's HSM; ACR (Authentication Challenge-Response) has the HSM check a signature against a key pre-installed at manufacturing, with no certificate or CA involved. Either can run unidirectional (ECU verifies the tester only) or bidirectional (both sides verify each other) -- but proof of ownership is always a request the tester sends; bidirectional mode only adds the ECU's own signature to that same response, never a separate proof-of-ownership request from the ECU.
What are the things to be considered while implementing Secure Diagnostics?
There are several technical concerns that must be considered during secure diagnostics implementation:
1. Brute-Force Prevention: ECUs must be capable of enforcing delays or temporary lockouts after a series of failed attempts and shall log the events and respond with NRC codes 0x36 and 0x37.
2. Session and Timing Behavior: ECUs shall revoke Security Access if the diagnostic session changes, or after a predefined time interval has elapsed, whichever occurs first.
3. Seed-Key Algorithm and Key Management: ECUs shall be equipped with cryptographically strong algorithms, and all keys shall be stored securely in an HSM.
4. Certificate Management: Similar to Key management, all certificates shall be secured, along with the public keys used to validate them.
How renco approaches Secure Diagnostics?
renco recognizes the importance of secure diagnostics. Our software logs and reports every security event triggered by malicious activities, alongside traditional software failures, so the log data can later be used for cyber-forensic analysis. This includes CAN message filtering, where unwanted or blacklisted CAN IDs are blocked from entering the software and reported immediately, replay-attack detection through freshness value tracking, and MAC verification failures on incoming SecOC-protected messages.
For ECUs where running the full Authentication (0x29) service isn’t practical, renco offers a refined security extension for Security Access (0x27) instead, bringing Authentication-style protections into 0x27 itself. The data exchanged between the ECU and the tester tool can, for example, include a role identifier for role-based diagnostic protection (the least-privilege principle), timing values to protect against replay attacks, and also the seed value received from the ECU. Our software also offers secure key management, frequent key updates via Secure Hardware Extension (SHE), and keys that are solely stored and securely managed in the HSM.
To keep symmetric key material off the tester tool, tester tools shall be used or configured to assemble an authentication data portion e.g. from the seed, a role identifier, a timestamp, and other properties. The tester tool shall send this data portion to a backend Key Management Server (KMS), which holds the symmetric key for that particular role and uses it to compute for example a CMAC over the data portion. The KMS returns this CMAC to the tester tool, which appends it to its own data portion to form the refined key (answering the seed request), and forwards the refined key to the ECU for validation. Because the tool never holds the symmetric key itself, as the key is always stored on the KMS at the OEM’s premises, compromising a single tester tool does not expose the key for every other vehicle that uses it.
APlain Security Access (0x27)Tester and ECU share a symmetric algorithm and key. The tester computes a key from the ECU's seed and sends it back, and the ECU's application software compares it internally. Fast, but the same key protects every vehicle using it.
BAuthentication (0x29)The tester first asks what the ECU supports via authenticationConfiguration. ISO 14229-1 defines two answers: APCE, where the tester presents a PKI certificate and the ECU's HSM validates the chain up to a trusted Root CA, and ACR, a lighter challenge-response against a public key the ECU already has pre-installed, with no certificate or chain involved. Either way the ECU issues a fresh challenge, the tester signs it, and the ECU's HSM verifies that signature and can derive a session key, which then secures whatever Secured Data Transmission (0x84) traffic follows. Stronger than 0x27, but needs more resources than many ECUs have.
Crenco's refined Security Access (0x27)The tester never holds the symmetric key. It builds a data portion, seed plus role, timestamp and serial number, and sends it to the OEM's backend KMS, hosted at the OEM's premises. The KMS computes a CMAC over that data portion using the role's key and returns just the CMAC; the tester appends it to its own data portion, and that combination is the refined key, sent to the ECU in the key response. So compromising one tester tool no longer exposes every other vehicle.
What should you take away from this?
As modern vehicles become more sophisticated and software-driven, diagnostic interfaces serve as a critical gateway for maintenance, updates, and reprogramming, one that must be secured. UN Regulation No. 155 requires a cybersecurity management system for vehicle type approval, and ISO/SAE 21434 sets the cybersecurity engineering process behind it, both of which extend to diagnostic interfaces as a documented attack surface. Secure diagnostics should be treated as essential rather than optional: stronger encryption algorithms and better key management are what stand between an authorized technician and an attacker trying to get their hands on sensitive data through the same interface.
Frequently Asked Questions
What is secure diagnostics in automotive ECUs?
Secure diagnostics is the practice of restricting diagnostic operations, reading fault codes, reconfiguring parameters, or reprogramming an ECU, to authorized dealers, engineers, and technicians. It gates these operations behind an authentication step so a diagnostic request only executes once the tester proves it holds the right credentials for that ECU and security level.
What is UDS Security Access (0x27)?
Security Access (SID 0x27) is a seed-key challenge used to gate protected diagnostic services. The ECU issues a seed for a requested security level, the tester computes a key from that seed using an algorithm shared only with authorized diagnostic tools, and the ECU grants access only if the returned key matches the value it derives internally. A fixed password could simply be captured once and reused indefinitely; because the ECU generates a new seed for each request, the key computed from it is only valid for that exchange, so a captured exchange cannot be replayed later to gain access.
What is the difference between Security Access (0x27) and Authentication (0x29)?
Security Access relies on a symmetric algorithm and key shared across every legitimate tester and the ECU, so compromising one tester tool can expose every ECU or vehicle using that same key. Authentication, introduced in ISO 14229-1:2020, instead verifies a tester's identity through certificate exchange or challenge-response with asymmetric or symmetric keys, and grants access per role rather than per shared secret.
How does an ECU protect against brute-force attacks on Security Access?
ECUs enforce delays or temporary lockouts after a series of failed key attempts, logging the events and responding with negative response codes 0x36 (exceeded number of attempts) and 0x37 (required time delay not expired). This forces an attacker into a delay-and-lockout cycle instead of an unlimited guessing loop.
Does entering a diagnostic session automatically grant access to protected services?
No. Entering a session such as the Programming or Extended Diagnostic Session makes certain services reachable, but they remain gated behind Security Access. Even once unlocked, access is revoked if the diagnostic session changes or a predefined time interval elapses, so a tester must reauthenticate rather than staying unlocked indefinitely.
What is Secured Data Transmission (0x84)?
Secured Data Transmission (SID 0x84) encrypts and integrity-protects diagnostic traffic using a session key, most commonly one derived during an Authentication (0x29) exchange. This extends protection beyond the login step itself to the diagnostic requests and responses that follow it.
How does renco secure diagnostics on ECUs where Authentication (0x29) isn't practical?
For ECUs where resource or memory constraints make the full Authentication service impractical, renco offers a refined security extension for Security Access (0x27) instead. The tester tool assembles a data portion from the seed, a role identifier, a timestamp, and a serial number, and sends it to a backend Key Management Server (KMS) at the OEM's premises, which computes a CMAC over that data portion using the role's symmetric key. The KMS returns just that CMAC, and the tester tool appends it to its own data portion to form the refined key, which it then forwards to the ECU for validation. The tester tool never holds the symmetric key itself, and keys are otherwise stored and managed securely in the HSM.
Is secure diagnostics required by automotive cybersecurity regulations?
Regulations do not name Security Access or Authentication directly, but UN Regulation No. 155 requires a cybersecurity management system for vehicle type approval, and ISO/SAE 21434 sets the cybersecurity engineering process behind it, both of which extend to diagnostic interfaces as a documented attack surface. In practice, this makes secure diagnostics close to essential for any type-approved vehicle with software-defined ECUs.
