TLS/DTLS for Ethernet Communication - Automotive Cybersecurity

TLS 1.3 Handshake for Automotive ECUs

TLS 1.3 One-RTT Handshake

  Client (ECU / Diagnostic Tool)          Server (OEM Backend / DoIP)
  ─────────────────────────────           ──────────────────────────
  ClientHello:
    cipher_suites: [TLS_AES_128_GCM_SHA256,
                    TLS_CHACHA20_POLY1305_SHA256]
    key_share: ECDH P-256 ephemeral key
    supported_versions: [TLS 1.3]
                              ────────────────────────────────────►
                                              ServerHello:
                                                key_share: server ECDH key
                                              {Certificate: ECU cert chain}
                                              {CertificateVerify: ECDSA-SHA256}
                                              {Finished: HMAC over handshake}
                              ◄────────────────────────────────────
  {Finished: HMAC}
  ─────────────────────────────────────────────────────────────────►
  Application data (encrypted with AES-128-GCM)

  Total: 1 RTT (vs TLS 1.2: 2 RTT)
  PSK resumption: 0-RTT for reconnecting SOME/IP clients

TLS Version	RTTs	Automotive Use	Status
TLS 1.3	1 RTT (0-RTT with PSK)	New deployments; SOME/IP, DoIP, OTA	Preferred for all new automotive deployments
TLS 1.2	2 RTT	Legacy telematics; some backend APIs	Acceptable if TLS 1.3 unavailable; disable TLS 1.1 and below
TLS 1.0/1.1	2 RTT	Deprecated — known vulnerabilities (BEAST, POODLE)	Must be disabled; BMW ConnectedDrive breach used TLS downgrade

mTLS for Automotive Service Authentication

Cmtls_verification.c

/* AUTOSAR TLS module: mTLS certificate verification */
/* Server verifies client certificate before routing UDS to target ECU */

#include "Tls.h"
#include "CertMgmt.h"

TlsVerifyResultType TLS_VerifyClientCertificate(
    const uint8* cert_der, uint32 cert_len)
{
    CertMgmt_CertIdType cert_id;
    CertMgmt_VerifyResultType verify_result;

    /* Parse X.509v3 client certificate */
    if (CertMgmt_ParseX509Cert(cert_der, cert_len, &cert_id) != E_OK) {
        return TLS_VERIFY_FAILED_PARSE;
    }

    /* Verify certificate chain back to OEM Root CA */
    /* Root CA public key hash stored in OTP-protected flash */
    verify_result = CertMgmt_VerifyCertificateChain(cert_id,
                        CERTMGMT_ROOT_CA_SLOT_OEM_WORKSHOP);

    if (verify_result != CERTMGMT_VERIFY_OK) {
        Tls_LogEvent(TLS_EVENT_CERT_VERIFY_FAILED, cert_id);
        return TLS_VERIFY_FAILED_CHAIN;
    }

    /* Check validity period (notBefore <= now <= notAfter) */
    if (CertMgmt_CheckValidity(cert_id) != E_OK) {
        return TLS_VERIFY_FAILED_EXPIRED;
    }

    /* Check KeyUsage: diagnostic tool cert requires digitalSignature */
    if (!CertMgmt_HasKeyUsage(cert_id, CERTMGMT_KU_DIGITAL_SIGNATURE)) {
        return TLS_VERIFY_FAILED_KEY_USAGE;
    }

    return TLS_VERIFY_OK;  /* mTLS handshake complete — client authenticated */
}

DTLS 1.3 for UDP-Based Services

Parameter	DTLS Addition over TLS	Purpose
Record sequence number	64-bit per epoch	Detect out-of-order or replayed packets on unreliable UDP
Epoch counter	16-bit; increments on key change	Demultiplex records from before and after key update
Retransmission timer	Configurable (default 1 s doubling)	Retransmit handshake messages lost on UDP
AUTOSAR module	SWS_TLS (handles both TLS and DTLS)	Single module for TCP and UDP secure transport
Use cases	SOME/IP-SD events, DoIP (ISO 13400) UDP transport	Any UDP-based automotive service requiring message authentication

Certificate Lifecycle in Automotive PKI

Pythonautomotive_pki_lifecycle.py

#!/usr/bin/env python3
# Automotive PKI certificate lifecycle management

pki_hierarchy = {
    "OEM Root CA": {
        "protection": "Offline HSM; air-gapped network; 4-person ceremony to use",
        "validity": "30 years",
        "key": "ECDSA P-384",
        "issues": "Intermediate CAs only",
    },
    "Intermediate CA (Vehicle ECU)": {
        "protection": "Online HSM (FIPS 140-2 Level 3)",
        "validity": "10 years",
        "key": "ECDSA P-256",
        "issues": "ECU leaf certificates during production",
    },
    "ECU Leaf Certificate": {
        "subject": "CN=TCU_TYPE_VIN_SERIAL, O=OEM_GmbH",
        "san": "URI: urn:automotive:ecuid:0xA3 (service binding)",
        "validity": "~15 years (vehicle lifetime)",
        "key_usage": "digitalSignature (firmware certs); keyEncipherment (TLS certs)",
        "provisioned_at": "EOL production via AUTOSAR SecureOnboardCommunication",
    }
}

# Certificate renewal on-vehicle
renewal_process = {
    "trigger": "notAfter within 12 months; or manual VSOC request",
    "protocol": "AUTOSAR CertMgmt module → CSR → OEM PKI backend over TLS",
    "authentication": "Current valid cert used to authenticate renewal request",
    "delivery": "New cert delivered in UDS WriteDataByIdentifier 0x2E over TLS DoIP",
}

import json
print("PKI Hierarchy:")
for ca, details in pki_hierarchy.items():
    print(f"  {ca}: {json.dumps(details, indent=4)}")
print("\nRenewal Process:", json.dumps(renewal_process, indent=2))

Summary

TLS 1.3 is the required transport security protocol for automotive Ethernet communication — 1 RTT handshake, forward secrecy from ECDH, and no legacy cipher suites. mTLS (mutual authentication) is mandatory for remote diagnostics and OTA authorisation: the ECU verifies the diagnostic tool's OEM-issued certificate before routing any UDS traffic. DTLS 1.3 extends TLS to UDP for SOME/IP and DoIP. The automotive PKI hierarchy must be established before production: once ECUs are deployed, updating the root CA public key in OTP memory requires a physical recall.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.