Automotive Cybersecurity

1

Automotive Cybersecurity Landscape

5 chapters • 3.8 hrs reading

Threat Landscape - Real Attack Case StudiesFREE PREVIEW 45 min read

▸ Miller & Valasek 2015 Jeep Cherokee hack: attacker exploited Sprint cellular network → Uconnect head unit (WinCE, open TCP port 6667) → reflashed D-Bus service → injected CAN frames on chassis bus (0x3B4 for steering, 0x2B0 for brakes) demonstrating remote arbitrary CAN injection from internet without physical access

▸ Tesla Model S OTA chain (2016): web browser heap overflow via crafted HTML5 → renderer exploit → sandbox escape via kernel 0-day → pivot to gateway ECU over internal Ethernet → CAN injection; attack required only that driver connect to attacker WiFi AP - patched via silent OTA push within days, demonstrating VSOC value

▸ Key fob relay attacks on RKE systems: attacker uses two SDR-based relay boxes (433 MHz or 868 MHz); box 1 near owner amplifies signal, box 2 near vehicle retransmits - latency ≤ 50 ms defeats rolling-code protection; Megamos Crypto transponder (used in VW/Audi) broken via 3-phase challenge-response recovery in 30 min on standard PC; countermeasure: UWB-based ToF distance bounding (≤ 1 m threshold)

▸ BMW ConnectedDrive TLS downgrade (2015): connected services used HTTP fallback when TLS negotiation failed; MITM injected RST packets forcing fallback → attacker sent crafted service request to unlock doors remotely; attack surface: telematics TCU exposed port 443 with no certificate pinning - fixed by enforcing TLS 1.2+ with pinned CA chain and disabling HTTP fallback in firmware update

ISO/SAE 21434 Framework OverviewFREE PREVIEW 50 min read

▸ Standard structure: 15 clauses - Clause 5 (overall cybersecurity management), Clause 6 (project-dependent), Clause 7 (distributed development / supplier management), Clauses 8–15 (TARA, concept, product dev, production, operations, end-of-life); normative requirements tagged [RQ] vs informative notes [NI]

▸ Key concept - cybersecurity lifecycle: item definition (system boundary + operating environment) → TARA → cybersecurity goals (Integrity/Confidentiality/Availability per asset) → cybersecurity concept → product development → validation; each phase requires cybersecurity case artifacts linking back to TARA findings

▸ Cybersecurity interface agreement (CIA): mandatory contract artifact per Clause 7 between OEM and Tier-1 defining shared vs supplier-owned cybersecurity responsibilities, deliverable list (TARA report, security testing evidence, vulnerability disclosure procedure), and right-to-audit clause; maps directly to UNECE R155 supply chain requirements

▸ Vulnerability management (Clause 12): continuous monitoring of published CVEs against item's BOM; severity rating via CVSS 3.1 (Base + Temporal + Environmental vectors); response SLA: CVSS ≥ 9.0 critical → patch within 30 days; requires vulnerability disclosure policy (VDP) and coordinated disclosure process with PSIRT contacts

UNECE R155/R156 Regulatory Requirements 40 min read

▸ UNECE R155 scope and mandate: type-approval regulation (not voluntary standard) applying to all new M, N, O, L vehicle categories in UN member states (EU, Japan, Korea effective July 2022 for new types; July 2024 for all new vehicles); OEM must demonstrate CSMS certification from Technical Service before receiving type approval - no CSMS = no vehicle sale

▸ R155 Annex 5 threat categories: 7 categories including "Vehicle communication channels" (remote attacks via V2X/telematics), "Update procedures" (OTA integrity), "Unintended human actions" (social engineering), and "Physical access to vehicle systems"; each threat must be addressed in TARA with explicit mitigation evidence submitted to Technical Service

▸ UNECE R156 - Software Update Management System (SUMS): companion regulation requiring OEM to maintain SUMS documenting update triggering conditions, update package authorization (digital signature verification), rollback capability, and customer notification process; SUMS audit by Technical Service requires traceability from software version in vehicle to approved update package hash

▸ Compliance evidence package: CSMS certificate (from approved audit body, valid 3 years renewable), vehicle type cybersecurity assessment (VTCA) document, TARA summary with residual risk acceptance, security testing evidence (penetration test reports), and post-production monitoring plan; submitted via DISS (Digital Information Sharing System) to national type approval authority

Cybersecurity Management System (CSMS) 45 min read

▸ CSMS organizational elements per ISO/SAE 21434 Clause 5: cybersecurity policy (scope, objectives, responsibilities), cybersecurity culture program (awareness training, secure-by-design principles), competence management (role profiles for security architect, TARA engineer, penetration tester), and management review cadence (minimum annual CSMS effectiveness review)

▸ Cybersecurity planning per project: Cybersecurity Plan document listing all planned activities (TARA, concept design reviews, security testing), assigned roles, start/end milestones, and entry/exit criteria for each cybersecurity gate; must be reviewed at project checkpoints and updated when scope changes; serves as primary audit artifact for Technical Service assessment

▸ Information security controls in CSMS: access control to cybersecurity artifacts (TARA reports, key material, penetration test findings) via role-based permissions; secure development environment controls (code signing infrastructure, HSM access audit log, binary integrity checks in CI/CD pipeline); incident/breach reporting within 72 hours per OEM PSIRT policy

▸ CSMS audit process: pre-audit document review (CSMS manual, procedures, evidence samples) → on-site audit (interviews, process walkthroughs, artifact spot-checks) → finding categorization (Major non-conformity blocks certification; Minor requires corrective action plan within 90 days; Observation is advisory) → certificate issuance by accredited certification body (TÜV, Bureau Veritas, SGS); valid 3 years

Hands-On: Cybersecurity Policy Definition 50 min read

▸ Draft cybersecurity policy document: define scope (all ECUs and connectivity components for model line X), state cybersecurity objectives (confidentiality of personal data, integrity of safety-critical CAN messages, availability of OTA update channel), assign CISO role with direct board reporting, and specify minimum training hours per role (security architect: 40 h/year, SW developer: 16 h/year)

▸ Define asset register template: for each asset record Asset ID, description, category (software/data/communication channel/hardware), associated vehicle functions, CIA importance rating (1–4 scale), and data sensitivity (PII/functional safety/operational); example entry - Asset A-07: "V2X Certificate Private Key", Category: cryptographic key, Confidentiality: 4 (critical), Integrity: 4, Availability: 3

▸ Establish vulnerability disclosure procedure: create PSIRT contact page (security@oem.com + PGP key), define internal triage SLA (acknowledge within 5 business days, severity classification within 10 days using CVSS 3.1), define coordinated disclosure embargo period (90 days default, extendable to 120 days with researcher agreement), and publish Hall of Fame for valid disclosures

▸ Write cybersecurity interface agreement (CIA) template for suppliers: sections covering supplier CSMS certification requirement (ISO/SAE 21434-aligned), list of cybersecurity deliverables (TARA excerpts, security test reports, software BOM), vulnerability notification obligation (supplier must notify OEM within 48 h of discovering CVE in delivered component), right-to-audit clause, and liability allocation for post-production security incidents

2

Threat Analysis & Risk Assessment

5 chapters • 4.2 hrs reading

TARA Methodology - Step by Step 55 min read

▸ Step 1 - Asset identification: define item boundary (e.g., TCU with V2X, Bluetooth, LTE interfaces), enumerate assets (ECU firmware, stored user credentials, CAN bus access, V2X certificates), classify each asset with damage scenario categories: Safety (S), Financial (F), Operational (O), Privacy (P) per ISO/SAE 21434 Table 1

▸ Step 2 - Threat scenario identification: apply STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each asset; example threat scenario TS-14: "Attacker spoofs V2X CAM message to falsely indicate obstacle, causing unnecessary emergency brake" → asset: V2X receive path, damage: Safety S3, Operational O2

▸ Step 3 - Attack path analysis: for each threat scenario, enumerate attack paths (sequences of attack steps from attacker entry point to asset violation); rate each attack path using Attack Feasibility Rating (AFR) scale 1–5 with factors: Elapsed Time (ET), Specialist Expertise (SE), Knowledge of Target (KT), Window of Opportunity (WoO), Equipment (EQ); AFR = sum of factor scores mapped to feasibility level (High/Medium/Low/Very Low)

▸ Step 4 - Risk determination and treatment: Risk Value = Impact × Attack Feasibility (3×3 matrix per ISO/SAE 21434 Annex B); treatment options: Avoid (remove feature), Reduce (add countermeasure to lower feasibility or impact), Transfer (supplier/insurance), Accept (document residual risk with management sign-off); accepted residual risks require monitoring plan and review trigger events (e.g., new published CVE for similar system)

Attack Trees & Attack Feasibility Rating 50 min read

▸ Attack tree structure: root node = threat goal (e.g., "Inject arbitrary CAN frames remotely"); child nodes connected by AND/OR gates - OR gate means any sub-attack path achieves goal, AND gate means all sub-steps required; leaf nodes are atomic attack steps (e.g., "Exploit buffer overflow in Bluetooth stack", "Obtain valid OBD-II session seed"); tree depth typically 3–5 levels for ECU attack scenarios

▸ Attack Feasibility Rating (AFR) per ISO/SAE 21434 Annex B: rate each leaf node on 5 factors - Elapsed Time (ET: ≤ 1 day=0, ≤ 1 week=1, ≤ 1 month=2, ≤ 6 months=3, >6 months=4), Specialist Expertise (SE: layman=0, proficient=2, expert=4, multiple experts=6), Knowledge of Target (KT: public=0, restricted=3, sensitive=7, critical=11), Window of Opportunity (WoO: unlimited=0, easy=1, moderate=4, difficult=10), Equipment (EQ: standard=0, specialized=4, bespoke=7, multiple bespoke=9)

▸ Feasibility aggregation for AND/OR paths: OR node feasibility = maximum of child feasibilities (attacker picks easiest path); AND node feasibility = sum of child AFR scores (all steps required); final total AFR score maps to: 0–13 = High feasibility, 14–19 = Medium, 20–24 = Low, 25+ = Very Low; High feasibility threats require mandatory countermeasure regardless of impact level

▸ Tool support for attack trees: IriusRisk and Foreseeti SecuriCAD support automated attack tree generation from system architecture models; export attack tree to PDF for TARA report; cross-reference each leaf node to CVE database (NVD API) to check if known exploit exists - pre-existing exploit lowers ET to ≤ 1 day, raising feasibility score by 3–4 points automatically

Impact Rating & Risk Determination 40 min read

▸ Impact category ratings per ISO/SAE 21434 Table 1: Safety (S0=no injury, S1=light injury, S2=severe/life-threatening injury, S3=life-threatening/fatal); Financial (F0=negligible, F1=moderate loss ≤ €1M, F2=significant €1M–€10M, F3=severe >€10M); Operational (O0=no degradation, O1=minor, O2=significant, O3=loss of primary function); Privacy (P0=no violation, P1=minor, P2=severe, P3=life-affecting)

▸ Impact rating procedure: for each damage scenario, independently rate all applicable impact categories (S, F, O, P); overall impact = highest single category rating; example damage scenario DS-07: "Attacker injects false ABS commands causing uncontrolled deceleration" → S3 (potentially fatal), F2 (recall cost), O3 (complete loss of braking function) → overall impact: S3 (critical)

▸ Risk value matrix: Risk = f(Impact, Attack Feasibility); typical 4×4 matrix - S3 + High feasibility = unacceptable risk (mandatory reduction), S3 + Low feasibility = medium risk (monitor or reduce), S1 + High feasibility = medium risk; unacceptable risk requires countermeasures until residual risk drops to acceptable level; risk value re-rated after countermeasure is defined to confirm reduction

▸ Risk treatment documentation: each threat scenario record includes original risk value, chosen treatment (reduce/avoid/transfer/accept), countermeasure description (e.g., "Add AES-128-CMAC MAC to ABS CAN message per AUTOSAR SecOC"), residual feasibility after countermeasure (MAC forgery requires brute force: Very Low), residual risk value, and review date (trigger: new CVE for similar MAC implementation)

Cybersecurity Goals & Requirements 45 min read

▸ Cybersecurity goal definition: derived from TARA for each risk-treated threat scenario; goal must state CIA property violated, asset protected, and constraint; example CG-04: "The integrity of CAN messages on the powertrain bus shall be protected such that an attacker cannot inject arbitrary engine torque commands without detection" - linked to TS-11 (threat scenario) with impact S3

▸ Cybersecurity claims and requirements hierarchy: goal (CG) → cybersecurity concept requirement (CCR, system-level) → technical security requirement (TSR, component-level) → implementation specification (IS, code/config level); example chain: CG-04 → CCR-04.1 "PowertrainGateway shall authenticate all CAN frames on bus X using CMAC" → TSR-04.1.1 "AUTOSAR SecOC module shall be configured with AES-128-CMAC, 24-bit truncated MAC, FVM counter length 8 bits"

▸ Requirements allocation to components: use system architecture model to assign TSRs to specific ECUs; for each TSR record: owning ECU, responsible supplier, development interface agreement reference, verification method (static analysis/review/testing), and test case ID; requirements traceability matrix (RTM) links every TSR back to its parent CCR and CG and forward to test evidence

▸ Cybersecurity requirement quality rules: each requirement must be atomic (one condition, one constraint), verifiable (clear pass/fail criterion), complete (fully specify behavior including error handling), and consistent (no conflict with other TSRs or with ISO 26262 safety requirements); conflicting safety-security requirement pairs (e.g., safety mandates redundant broadcast vs security mandates point-to-point authenticated unicast) require co-analysis with safety team and documented resolution

Hands-On: Full TARA for Connected ECU 65 min read

▸ Target system: Telematics Control Unit (TCU) with LTE modem, Bluetooth 5.0, CAN gateway interface (access to powertrain + body CAN buses), OTA update client, and remote diagnostics server (UDS over IP); define system boundary diagram showing external interfaces (internet, smartphone, OBD-II port) and internal interfaces (Ethernet backbone, CAN bus gateway)

▸ Asset enumeration and damage scenarios: identify 12 assets (LTE credentials, CAN gateway routing table, OTA package verification key, UDS session manager, Bluetooth pairing database, stored PII/location data, ECU firmware image, secure boot chain, CAN message integrity, remote access token, diagnostic session authorization, diagnostic log files); for each asset enumerate damage scenarios across S/F/O/P categories - minimum 20 damage scenarios for typical TCU

▸ Attack path construction: for threat scenario TS-09 "Remote attacker obtains valid UDS DiagnosticSessionControl extended session without physical access": attack path AP-09A = LTE interface exploit (0-day in cellular modem firmware) → pivot to application processor → send UDS DiagnosticSessionControl 0x10 0x03 → no OEM-specific authentication required (rating: ET=3, SE=4, KT=3, WoO=1, EQ=0 → AFR score=11 = High feasibility); attack path AP-09B = social engineering to obtain remote access token → use legitimate remote diag portal → no additional exploit needed (ET=1, SE=0, KT=3, WoO=1, EQ=0 → AFR=5 = High feasibility); risk: S2/F2 = Unacceptable

▸ Countermeasure definition and residual risk: for TS-09 define countermeasures CM-09.1 "Require security access seed-key (SID 0x27) with 256-bit random challenge before entering extended session" and CM-09.2 "Enforce TLS 1.3 mutual authentication (mTLS) for all remote diagnostic connections with OEM-issued client certificate"; after CM-09.1+09.2: remote attack AP-09A feasibility drops to Very Low (need to forge valid mTLS certificate + bypass seed-key, ET>6 months); residual risk: S2 + Very Low = Acceptable; document in TARA report and sign off with cybersecurity manager and functional safety manager

3

Secure Communication

5 chapters • 4.0 hrs reading

SecOC - Secure Onboard Communication 55 min read

▸ SecOC AUTOSAR architecture (SWS_SecOC): PDU-level security layer sitting between COM and PDUR; Secured I-PDU = Authentic I-PDU (payload) + Freshness Value (FV) + Truncated MAC; FV prevents replay attacks - sender increments FV counter per transmission, receiver verifies FV is within acceptance window (configurable ±WindowSize to allow lost frames); FV can be embedded in message or managed externally via FreshnessManagement interface

▸ MAC algorithm and truncation: default algorithm AES-128-CMAC (AUTOSAR SWS_Csm for Crypto Service Manager); full CMAC = 128 bits; truncated to 24–64 bits for CAN frames (8-byte payload leaves limited space); truncation reduces security margin - 24-bit MAC has 2^24 brute-force space; attacker with CAN bus access sending 1000 frames/second needs ~4.7 hours to find collision → use 48-bit minimum for safety-critical messages; configure via SecOCAuthInfoTruncLength parameter in ARXML

▸ Key provisioning and management: symmetric session key pre-provisioned into ECU via secure flash during production (SHE key slot KEY_1 or HSM-managed slot); key derivation: master secret → KDF (HKDF-HMAC-SHA256) with context string (ECU ID + bus ID + direction) → session key; key update via AUTOSAR KeyM module - new key encrypted with old key, delivered via UDS WriteDataByIdentifier 0x2E, activated after verification; key lifetime policy: rotate every 200,000 km or 5 years

▸ Gateway handling and CAN-FD adaptation: SecOC gateway (e.g., Central Gateway ECU) must re-authenticate frames when routing between bus segments - strip incoming MAC, verify using source bus key, re-sign with destination bus key before forwarding; for CAN-FD (64-byte payload) increase truncated MAC to 64 bits for improved collision resistance; configure SecOCPduCollection in ARXML to map each Secured I-PDU to source/destination SecOC instances and key handles

TLS/DTLS for Ethernet Communication 45 min read

▸ TLS 1.3 handshake for automotive: Client Hello (supported cipher suites: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256; key_share extension with ECDH P-256 key) → Server Hello + Certificate + CertificateVerify (ECDSA-SHA256 signature over handshake hash) + Finished → Client Finished; total handshake = 1 RTT vs TLS 1.2 2 RTT; session resumption via pre-shared key (PSK) reduces to 0-RTT for reconnecting SOME/IP clients

▸ mTLS (mutual TLS) for automotive services: server presents ECU certificate (issued by OEM PKI intermediate CA); client (e.g., diagnostic tool) presents its certificate; server validates client cert chain back to OEM Root CA; used for remote diagnostics, OTA authorization, and V2X backend communication; certificate revocation via OCSP stapling (server includes OCSP response in ServerHello to avoid client-side revocation check latency)

▸ DTLS 1.3 for UDP-based services: DTLS = TLS adapted for unreliable UDP (adds record sequence numbers, retransmission timer, epoch counter for key changes); used with SOME/IP-SD events and DOIP (Diagnostics over IP, ISO 13400); AUTOSAR TLS module (SWS_TLS) implements both TLS and DTLS; configure TlsJobMappingTable to assign TLS context (cert handle, cipher suite list, version) to each SoAd socket endpoint

▸ Certificate lifecycle in automotive PKI: OEM Root CA (offline, HSM-protected) → Intermediate CA (online, issues ECU certs) → ECU certificate (subject: ECU serial + VIN, SANs: service IDs, validity: vehicle lifetime ~15 years); provisioned during EOL (end-of-line) test in production via AUTOSAR SecureOnboardCommunication provisioning sequence; certificate renewal on-vehicle via AUTOSAR CertMgmt module requesting new cert from OEM PKI backend over TLS-secured DiagnosticSessionService

IPsec & MACsec in Automotive 40 min read

▸ MACsec (IEEE 802.1AE) for in-vehicle Ethernet: operates at Layer 2 (Ethernet frame level); each switch port pair establishes Secure Channel using Connectivity Association Key (CAK) derived via MKA (MACsec Key Agreement protocol, IEEE 802.1X-2020); frame protection: Secure Channel ID (SCI) + Packet Number (PN) in SecTAG header + AES-128-GCM or AES-256-GCM authenticated encryption of payload + 16-byte ICV; PN anti-replay window configurable (typ. 32 or 64 packets); hardware-accelerated in automotive Ethernet switches (NXP SJA1110, Marvell 88Q5050)

▸ MACsec deployment in automotive zonal architecture: configure MKA between zone controller switch port and each domain ECU; each zonal link gets its own Connectivity Association - zone controller acts as Key Server, distributes Secure Association Keys (SAK) to connected ECUs; 802.1Q VLAN tags remain authenticated but unencrypted (tag remains visible for switch forwarding decisions); MACsec protects all traffic on a segment including SOME/IP, DoIP, and raw Ethernet without protocol-specific changes

▸ IPsec for V2X and telematics tunnels: IPsec Transport mode (encrypt IP payload only, preserve IP header) used for ECU-to-backend communication; IKEv2 for session establishment using ECDH + X.509 certificates (ECU cert provisioned at production); ESP (Encapsulating Security Payload) with AES-256-GCM AEAD mode; AUTOSAR IPsec configuration: define Security Policy Database (SPD) entries specifying traffic selectors (src IP, dst IP, port) and associated SA actions (encrypt, bypass, discard)

▸ Protocol selection guidance: MACsec for intra-vehicle Ethernet segment protection (L2, low-latency, zero per-packet overhead beyond ICV); TLS for application-layer service security (flexible, works across routed networks, supports mTLS); IPsec for network-layer tunnel to backend (transparent to application, protects all IP traffic on path); combine MACsec (physical segment) + TLS (application service) for defense-in-depth on Ethernet backbone - attacker must break both L2 and L7 security

Secure Diagnostics (UDS Security) 45 min read

▸ UDS SecurityAccess (SID 0x27) seed-key mechanism: tester sends 0x27 0x01 (RequestSeed for level 1) → ECU returns 4-byte random seed; tester computes key = HMAC-SHA256(seed || ECU_ID, secret_key) truncated to 4 bytes → sends 0x27 0x02 (SendKey); ECU verifies independently computed expected key; failed attempt counter: 3 fails → lockout delay (typ. 10 s exponential back-off); secret key provisioned to authorized tooling via PKI-protected key management system

▸ Certificate-based authentication (ISO 20080 / AUTOSAR Dcm R22): replaces symmetric seed-key for high-security access levels (e.g., ECU reprogramming, calibration write); tester presents X.509 certificate chain (issued by OEM PKI for authorized workshop) in UDS RequestUpload or via custom CertificateAuthentication service; ECU verifies signature using embedded OEM Root CA public key; supports role-based access: OEM engineering cert allows all levels, workshop cert allows only DTC clear and routine control

▸ Securing DoIP (Diagnostics over IP, ISO 13400): DoIP gateway (vehicle access point) reachable via DHCP-assigned IP on OBD-II Ethernet port; without authentication any host on local network can send UDS frames; secure deployment requires DoIP over TLS (DTLS for UDP transport, TLS for TCP) with mandatory client certificate from authorized diagnostic tool; DoIP RoutingActivation (message type 0x0005) extended to carry authentication token before routing UDS traffic to ECUs

▸ Diagnostic data confidentiality: certain UDS ReadDataByIdentifier (0x22) responses contain sensitive data (VIN, mileage, fault history, encryption counters); encrypt response payload for PII-tagged DIDs using session-specific encryption key derived during SecurityAccess; UDS log: record every SecurityAccess request (timestamp, tester MAC address/certificate subject) to tamper-evident audit log in NVM for forensic analysis; log readable only with OEM-level security access

Hands-On: SecOC Implementation 60 min read

▸ ARXML configuration: in DaVinci Configurator, add SecOc module; create SecOcTxPduProcessing entry for each secured PDU (e.g., EngTorqueCmd_PDU): set SecOCAuthInfoTruncLength=48, SecOCFreshnessValueLength=64, SecOCFreshnessValueTruncLength=16, SecOCUseAuthorizedValidationMode=TRUE; link to CsmJob referencing AES-128-CMAC algorithm via AUTOSAR CryptoStack; repeat for SecOcRxPduProcessing with same parameters and add SecOCReceptionOverflowStrategy=DROP_NEWEST

▸ Freshness value management: implement FreshnessManagement callout SecOC_GetRxFreshness() returning current expected FV; two strategies - (a) counter-based: FV = trip counter (16-bit) + message counter (48-bit), counter stored in NVM, incremented on each send, reset on ECU reset with trip counter increment; (b) time-based: FV = UTC time from secure time source (AUTOSAR StbM + TimeSync over Ethernet, IEEE 802.1AS); verify FV is within SecOCAcceptanceWindow (typ. 10 messages) to tolerate lost frames

▸ Key provisioning in test environment: use SHE (Secure Hardware Extension) key slots - load KEY_1 with 128-bit test key using SHE command CMD_LOAD_KEY; in software simulate key via mock Csm implementation returning fixed CMAC for unit tests; for integration test use Vector CANoe CAPL script to inject both authentic frames (correct CMAC) and attack frames (random CMAC) and verify SecOC drops frames with VerificationStatus = FAILED; log verification results via DET (Default Error Tracer) hook

▸ Verification and debugging: use CANalyzer SecOC plugin to decode secured PDUs - enter key and FV algorithm config, plugin automatically verifies MAC and displays AUTHENTIC/FAILED status for each frame; common failure modes: FV sync loss (counter mismatch after ECU reset without persistent NVM update) → fix by writing FV to NVM before reset using ComM sleep notification; key mismatch (sender and receiver provisioned with different keys) → use SHE M4/M5 verification fields to confirm key identity in both ECUs

4

Cryptography & HSM

5 chapters • 4.2 hrs reading

Automotive Cryptography Fundamentals 45 min read

▸ Symmetric cryptography in automotive: AES-128 (NIST FIPS 197) used for bulk encryption and MAC generation; AES-128-GCM (Galois/Counter Mode) provides AEAD - single pass authentication + encryption, 128-bit authentication tag, 96-bit IV (nonce must never repeat per key); AES-128-CMAC (NIST SP 800-38B) for message authentication only - output is 128-bit MAC, truncated to 32–96 bits for CAN frames; performance on Aurix TC3xx with HSM: AES-128-GCM ~400 MB/s, AES-128-CMAC ~600 MB/s hardware-accelerated

▸ Asymmetric cryptography: RSA-2048 (PKCS#1 v2.2 OAEP for encryption, PSS for signatures) - 256-byte signature, verify time ~1 ms on Cortex-M7 @ 400 MHz; ECDSA-P256 (FIPS 186-4) - 64-byte signature, verify time ~0.1 ms, preferred for ECU firmware signature verification; ECDH-P256 for key exchange (ephemeral keys for TLS); post-quantum consideration: ML-KEM (Kyber) and ML-DSA (Dilithium) NIST finalized 2024, automotive migration timeline 2028–2032 per SAE J3101

▸ Hash functions and KDFs: SHA-256 (FIPS 180-4) - 32-byte digest, collision resistance 128-bit, preimage resistance 256-bit; SHA-256 hardware support in SHE and most automotive HSMs; HKDF (RFC 5869, HMAC-based key derivation): Extract(salt, IKM) → HMAC-SHA256 pseudorandom key → Expand(PRK, context, length) → derived key material; used to derive per-ECU, per-session, per-direction keys from master secret to prevent key reuse; SP 800-135 compliant KDF required for FIPS-aligned OEM deployments

▸ Random number generation: automotive-grade TRNG (True Random Number Generator) built into HSM/SHE hardware; AUTOSAR Csm CryIf_RandomSeed() and CryIf_RandomGenerate() interfaces; TRNG quality: NIST SP 800-90B health tests (repetition count test, adaptive proportion test) run continuously; TRNG output feeds DRBG (HMAC-DRBG per SP 800-90A) for higher throughput; never use software PRNG seeded from cycle counter in cryptographic context - deterministic and exploitable

Hardware Security Modules (HSM/SHE) 55 min read

▸ SHE (Secure Hardware Extension, HIS SHE spec v1.1): automotive-specific security module for microcontrollers; provides hardware-isolated AES-128 engine, 17 dedicated key slots (MASTER_ECU_KEY, BOOT_MAC_KEY, KEY_1…KEY_10, RAM_KEY, plus wildcard slots); all key slots are write-once after production lock; SHE commands via CMD register: CMD_LOAD_KEY, CMD_LOAD_PLAIN_KEY (RAM_KEY only), CMD_EXPORT_RAM_KEY, CMD_GET_ID, CMD_INIT_RNG, CMD_GENERATE_MAC, CMD_VERIFY_MAC, CMD_ENC_ECB/CBC, CMD_DEC_ECB/CBC; key loading uses Miyaguchi-Preneel KDF-based protocol (M1–M5 message sequence)

▸ HSM (full Hardware Security Module, e.g., Infineon SLx 9670, NXP SE050, STM32 TrustZone + SE): more capable than SHE - supports RSA-2048/4096, ECDSA P-256/P-384/P-521, AES-256, SHA-256/384/512, multiple key types (symmetric, asymmetric, certificate storage), secure key generation with internal TRNG, FIPS 140-2/3 Level 2+ certification; automotive MCUs with embedded HSM: Infineon Aurix TC3xx (eHSM), NXP S32K (CSEc+ HSM), Renesas RH850 (HSM); HSM runs isolated firmware on dedicated CPU core with no shared memory with main application

▸ Secure boot using HSM: boot ROM (immutable, in OTP or masked ROM) → loads Boot Software from flash → before executing, requests HSM to verify CMAC/signature of Boot SW image; SHE-based secure boot: Boot ROM computes AES-128-CMAC of entire application flash region using BOOT_MAC_KEY → compares to stored BOOT_MAC in protected SHE slot → mismatch halts execution and asserts ERROR_PIN; HSM-based secure boot: verify ECDSA-P256 signature over SHA-256 hash of each boot stage (Boot Manager, MCAL, BSW, Application) - each stage chained to next via signed manifest

▸ AUTOSAR Crypto Stack integration: AUTOSAR CryptoStack = CryptoDriver (hardware abstraction) → CryIf (Crypto Interface, PDU routing) → Csm (Crypto Service Manager, job management); configure CryptoDriverObject pointing to HSM or SHE driver; define CsmJob (e.g., CsmJob_AES128_CMAC_Generate) with algorithm = AES-128/CMAC/16-byte MAC, processing mode = SYNC, key reference = HSM_SLOT_KEY1; application calls Csm_MacGenerate(jobId, inputBuffer, length, macBuffer) → CryIf dispatches to correct CryptoDriver primitive → result available synchronously or via callback

Key Management & Distribution 50 min read

▸ Key hierarchy design: Root Key (hardware-protected in OEM HSM, never exported) → Vehicle Master Secret (derived per-VIN using HKDF: VMS = HKDF(Root Key, VIN)) → ECU Session Key (derived per-ECU: ESK = HKDF(VMS, ECU_ID || bus_ID || direction)); hierarchical derivation means compromise of one ECU's key does not expose other ECUs; key rotation: session keys rotated at each ignition cycle via KeyM module using derived keys; master keys rotated on VSOC security event signal

▸ Production key provisioning: OEM Key Management System (KMS) generates VMS per VIN; KMS exports SHE M1–M5 provisioning messages (encrypted key loading sequence) for each ECU; provisioning station at EOL test inserts ECU, sends M1–M5 via SHE CMD_LOAD_KEY over SPI/FlexRay diagnostic channel; ECU verifies M3 (KDF-based authentication proof) before storing key; M4+M5 returned by ECU serve as provisioning proof archived in KMS for audit; provisioning station must be air-gapped from internet with HSM-protected KMS access

▸ Over-the-air key update via AUTOSAR KeyM: OEM backend generates new SAK (Secure Association Key) encrypted with current ECU master key → packages in AUTOSAR KeyM UpdateRequest structure → delivers via UDS TransferData (0x36) over TLS-secured DoIP channel → ECU KeyM module decrypts, verifies integrity, stores in protected NVM slot; KeyM activation: atomic swap - new key active on next ignition cycle start; rollback protection: new key slot version counter ≥ current (prevents replay of older key packages)

▸ Key compromise response procedure: VSOC detects anomaly suggesting key compromise (high rate of SecOC FAILED verifications on a bus) → triggers emergency key rotation for affected bus → KMS generates replacement keys using new HKDF context string (includes incident ID) → OTA pushes new keys to all ECUs on segment with 24-hour SLA; revoke and blacklist compromised key fingerprint in KMS; file incident report per ISO/SAE 21434 Clause 12 with root cause analysis and corrective action (e.g., patch that allowed key extraction)

Digital Signatures & Certificate Chains 40 min read

▸ ECDSA signature generation and verification: sign(private_key, message): compute e = SHA-256(message) → select random ephemeral k → compute curve point (x1,y1) = k×G → r = x1 mod n → s = k⁻¹(e + r×private_key) mod n → signature = (r,s); verify: compute u1 = e×s⁻¹ mod n, u2 = r×s⁻¹ mod n → (x1,y1) = u1×G + u2×public_key → valid if x1 mod n = r; critical: k must be unique per signature (RFC 6979 deterministic k derivation from private_key + message hash prevents nonce reuse vulnerability)

▸ X.509v3 certificate structure for automotive PKI: TBSCertificate fields - serialNumber (unique per CA, used for revocation), validity (notBefore/notAfter, vehicle lifetime ~15 years), subject (CN=ECU_TYPE_VIN_SERIAL, O=OEM), subjectPublicKeyInfo (ecPublicKey, P-256), extensions: BasicConstraints (cA=FALSE for leaf certs), KeyUsage (digitalSignature for firmware certs, keyEncipherment for TLS certs), SubjectAlternativeName (URI: urn:automotive:ecuid:0xA3 for service binding); signed by Intermediate CA using ECDSA-SHA256

▸ Certificate chain validation in ECU: root CA public key embedded in secure boot ROM (hash stored in OTP for tamper protection); runtime validation chain: leaf cert → verify ECDSA signature against intermediate CA public key → verify intermediate CA signature against root CA public key (embedded) → check validity period → check KeyUsage flags → result: VALID or INVALID; on validation failure: halt operation and log event via DET; optimized for embedded: use AUTOSAR CertMgmt ParsX509Cert() and VerifyCertificateChain() with pre-allocated memory pools

▸ Firmware signing workflow: build system → final binary → compute SHA-256 hash → HSM/Code Signing Server signs with ECDSA P-256 private key (key stored in hardware HSM, never exported) → appends signature block to binary (format: 0xDEADBEEF magic + SHA-256[32] + r[32] + s[32] + cert_chain_DER[variable]) → signs package manifest JSON listing all binaries + their hashes → ECU bootloader reads manifest, verifies manifest signature, then verifies each binary's signature before loading; revocation: code signing cert serial added to CRL embedded in next OTA update

Hands-On: HSM-Based Secure Boot 60 min read

▸ Target hardware: Infineon Aurix TC397 with integrated eHSM (Enhanced HSM, 200 MHz ARM Cortex-M core, SHE+ compatible, 512 kB HSM RAM, AES-128/256 + RSA-2048 + ECC P-256 hardware engines); boot flow: Startup Software (SSW, in OTP Boot ROM) → reads HSM firmware from dedicated HSM flash region → HSM boots independently → SSW requests HSM to verify application boot code MAC → on VALID: SSW transfers execution to Boot Software → Boot Software requests HSM to verify AUTOSAR SBL signature → on VALID: SBL loads and verifies BSW image

▸ HSM firmware configuration: in Aurix HSM Config Tool, enable SecureBoot mode (HSM_SB_CTRL register), specify BOOT_MAC_KEY slot for CMAC-based Boot ROM verification, configure secondary SHE-compatible interface for application use; load Boot MAC: compute AES-128-CMAC over [Boot SW start address, Boot SW length, Boot SW SHA-256 hash] using BOOT_MAC_KEY → store result in HSM NVM BOOT_MAC slot; lock BOOT_MAC_KEY slot (SET_WRITE_PROTECTION flag) - cannot be overwritten after lock; generate test M1–M5 provisioning sequence using HSM Simulator SDK

▸ AUTOSAR SecBoot integration: in DaVinci Developer, configure Fls + Fee (flash abstraction), BswM rules for boot state machine, and SecBoot module parameters: SecBootAlgorithm=AES128_CMAC, SecBootKeyRef=HSM_BOOT_MAC_KEY, SecBootCheckAddress=0x80000000 (start of application flash), SecBootCheckLength=0x100000 (1 MB application size); SecBoot_VerifyBootImage() returns E_OK or E_NOT_OK; on E_NOT_OK: BswM triggers BOOT_FAILURE state → DCM activates programming session for recovery reflash; integrate with MCAL Mcu reset handling to detect verification failure source

▸ Testing and attack simulation: positive test - flash valid signed image, power cycle, verify SecBoot passes and normal BSW init completes (log BOOT_VERIFIED event in Det); negative test 1 - flip single byte in application flash (bit-flip corruption), verify HSM detects CMAC mismatch, system halts at BswM BOOT_FAILURE state; negative test 2 - load image signed with wrong key, verify signature verification fails; attack test - attempt to reprogram BOOT_MAC NVM region via UDS WriteMemoryByAddress 0x3D without valid SecurityAccess → verify NVM write protection blocks the attempt; document test evidence in security test report for TARA countermeasure verification

5

Secure Development & Testing

5 chapters • 4.0 hrs reading

Secure Coding Practices for Embedded 45 min read

▸ Memory safety in C for automotive (MISRA C:2012 + SEI CERT C): Rule 18.1 (no out-of-bounds pointer arithmetic), Rule 21.3 (no dynamic memory allocation in safety-critical code - use static pools instead); CERT C INT30-C (use unsigned arithmetic to detect wrap), STR31-C (ensure destination buffer large enough before strcpy - use strncpy or memcpy with explicit length); buffer overflow prevention pattern: always pass buffer + sizeof(buffer) as length parameter pair; enable stack canaries (-fstack-protector-strong) and ASLR where MCU supports it

▸ Input validation at all trust boundaries: for UDS received data - validate DID byte count matches expected length before memcpy (e.g., if (dataLength != sizeof(Expected_t)) return E_NOT_OK); for CAN received signals - apply range check (signal_value >= MIN && signal_value <= MAX) before passing to application; for external configuration data loaded from NVM - verify CRC-32 before use; never pass external string data to printf-family functions without format string sanitization (use puts() or explicit format "%s" never variable format)

▸ Timing attack countermeasures: constant-time comparison for MAC verification - never use memcmp() (short-circuits on first mismatch revealing timing information); implement fixed-time compare: result = 0; for(i=0; i

▸ Compiler and linker hardening flags for automotive: GCC/LLVM: -D_FORTIFY_SOURCE=2 (adds runtime buffer overflow checks), -fstack-protector-strong (canary on functions with arrays), -Wformat-security (warns on unsafe printf), -fno-common (prevent BSS symbol merging vulnerabilities); linker: -z relro (read-only relocation table after startup), -z now (immediate binding to prevent lazy binding attacks), --gc-sections (remove unused code reducing attack surface); verify with checksec tool; document hardening flags in software architecture specification as mandatory compiler configuration

Static & Dynamic Security Analysis 40 min read

▸ SAST (Static Application Security Testing) tools for automotive C/C++: Coverity SAST - detects CWE-119 (buffer overflow), CWE-416 (use-after-free), CWE-476 (null dereference), CWE-369 (divide-by-zero); Polyspace Code Prover - formal verification proving absence of run-time errors (green/orange/red color coding: green = proven safe, orange = potential issue, red = proven defect); MISRA C checker integrated into Polyspace; configure CI pipeline: run Coverity on every PR, block merge on CVSS ≥ 7.0 findings; run Polyspace on release branch with 100% code coverage requirement for safety-critical modules

▸ Binary analysis for black-box security: Ghidra (NSA open source) or IDA Pro for disassembly - identify hard-coded cryptographic keys (entropy analysis: byte sequences with Shannon entropy > 7.5 flagged as potential keys), find unsafe string operations (reference to strcpy/gets in disassembly), locate debug backdoors (reference to "debug_password" or hardcoded "1234" in string table); binwalk for firmware extraction - scan for embedded filesystem signatures (squashfs, cramfs, jffs2), extract and analyze each partition independently

▸ DAST (Dynamic Analysis) with instrumented firmware: compile with AddressSanitizer (-fsanitize=address) for host-based unit test execution - detects heap/stack overflows at runtime with byte-precise error messages; Valgrind for host-based memory error detection (uninitialized reads, heap overflows, memory leaks); for ECU target: use AUTOSAR DET (Default Error Tracer) hooks to catch OS API misuse at runtime; AUTOSAR RTE mode management errors captured via RteError hooks; integrate runtime analysis results in CI test report

▸ Taint analysis for automotive ECU code: track untrusted input propagation from CAN receive buffers, UDS received data, and NVM reads through the codebase to sinks (memcpy, array indexing, function pointer calls); CodeSonar Taint Analysis or custom LLVM taint tracking pass; example finding: UDS received length field (tainted) used directly as memcpy length without bounds check → CWE-805 buffer access with incorrect length value → assign CVSS 8.8 (High) → mandatory fix before release; document taint analysis coverage in cybersecurity testing evidence for Technical Service submission

Vulnerability Scanning & Fuzzing 45 min read

▸ Network-level vulnerability scanning: use Nmap against vehicle's Ethernet interface (DoIP port 13400/TCP, SOME/IP-SD port 30490/UDP) - nmap -sV -sC -p 13400,30490 192.168.1.x to fingerprint service versions; Nessus or OpenVAS with custom automotive plugins to check for known CVEs in embedded OS (Linux kernel version, GENIVI components, OpenSSL version); SHODAN queries for exposed telematics backends before on-vehicle testing; output: vulnerability report with CVE IDs, CVSS scores, and affected component

▸ Protocol fuzzing for UDS: use Bosch CANToolz or Scapy-based UDS fuzzer to send malformed UDS requests - random SID bytes (0x00–0xFF), invalid DID lengths, oversized payloads exceeding buffer expectations, boundary values (length=0, length=MAX_UINT16); monitor ECU for unexpected resets (via CAN bus silence), error responses (NRC 0x10 generalReject) vs. crashes; for each crash: record exact payload sequence, reproduce, and root-cause via debugger or JTAG core dump; automate with AFL-based binary fuzzer if source is available

▸ CAN bus fuzzing: inject high-frequency random CAN ID + data combinations using PEAK PCAN-USB adapter and python-can library: send 1000 frames/s with random IDs (0x001–0x7FF range) and random 8-byte data; monitor for gateway ECU resets (bus goes silent), unexpected actuator activations, or DTC storage; targeted fuzzing: enumerate expected CAN IDs from DBC file, then fuzz only message payloads for signals with safety implications (torque commands, brake pressure, gear selector); use CANalyzer CAN Disturbance Tool for controlled bit-error injection

▸ Ethernet/IP fuzzing with Boofuzz: model SOME/IP message structure (8-byte header + payload) in Boofuzz Session; define fuzzable fields: ServiceID (2 bytes), MethodID (2 bytes), Length (4 bytes, include off-by-one values), payload (variable length); run mutational fuzzing campaign (10,000+ iterations per service); monitor target health via ping and CAN bus activity; integrate with ASAN-enabled firmware on QEMU for higher throughput fuzzing without hardware; report all unique crashes with minimized reproducer payload and call stack from ASAN output

Penetration Testing for ECUs 50 min read

▸ Penetration test scope definition: attack surface = all external interfaces (OBD-II port CAN/Ethernet, Bluetooth, LTE, V2X DSRC); threat actor profiles from TARA (opportunistic attacker with commodity tools: AFR High, nation-state attacker with custom hardware: AFR Low); pentest objectives linked directly to TARA threat scenarios requiring evidence of countermeasure effectiveness; scope approved and signed by OEM cybersecurity manager before testing begins

▸ Reconnaissance and interface mapping: enumerate all ECUs on vehicle using UDS BroadcastAddress 0x7DF request UDS ReadDataByIdentifier 0xF18B (ECU manufacturing date) - observe which IDs respond with positive response; map network topology using DoIP EntityStatusRequest; for Bluetooth: use hcitool scan + btlejuice to enumerate GATT services/characteristics; document each interface: protocol, physical connector, authentication required, observed services, ECU addresses; this map drives remaining test phases

▸ Exploitation phase using hardware tools: JTAG/SWD debug port - use OpenOCD + FTDI FT232H adapter to connect to exposed JTAG pads on PCB; attempt to read flash (success = critical finding: firmware extraction possible); attempt to set breakpoints in running application (success = debug backdoor left active in production firmware); hardware side-channel: power analysis using ChipWhisperer to attempt AES key extraction during CMAC computation - record 10,000 power traces, apply CPA (Correlation Power Analysis) to correlate with Hamming weight model

▸ Penetration test report structure: Executive Summary (overall risk rating, critical findings count), Methodology (attack surface, tools, threat actor assumptions), Findings (for each: CVE/CWE reference, CVSS 3.1 score, technical description, reproduction steps, evidence screenshots/logs, recommended fix, fix verification method), Countermeasure Verification (re-test after fixes showing residual risk), Cybersecurity Case Contribution (map each finding to TARA threat scenario, confirm acceptance or risk reduction); report submitted to TARA team to update residual risk ratings

Hands-On: Security Testing Pipeline 60 min read

▸ CI/CD pipeline integration: GitLab CI pipeline stages - (1) SAST: Coverity scan on changed C files, fail build on CVSS ≥ 7.0 new findings; (2) Dependency check: OWASP Dependency-Check against software BOM (SPDX format), flag components with CVE in NVD; (3) Secret scanning: truffleHog scan for hardcoded credentials, API keys, private keys in commits; (4) Binary hardening check: checksec.sh against compiled ELF binaries, fail on missing stack canary or NX; (5) MISRA check: PC-lint Plus report, fail on any MISRA Required violations

▸ Automated UDS fuzzing stage: Docker container running custom python-can UDS fuzzer connected to Vector VN5640 CAN hardware via USB; fuzzer runs 5000 iterations per build (random SID mutations + length boundary tests + malformed multi-frame ISO-TP sequences); target ECU heartbeat monitored via 100ms CAN frame on 0x3C5 - if heartbeat absent >500ms, crash detected; each crash archived with payload, timestamp, and pre-crash DTC snapshot; fuzzing results gate release build: zero new crashes required

▸ Software Bill of Materials (SBOM) management: generate SBOM in SPDX 2.3 format from Yocto build recipe (bitbake -c spdx target) or from CMake via cmake2spdx; SBOM includes: package name, version, supplier, license, checksum (SHA-256), declared dependencies; publish SBOM to internal repository; nightly job correlates SBOM against NVD CVE feed via OSV.dev API - new CVE match triggers Jira ticket creation with CVSS score, affected component, and 30-day fix SLA for CVSS ≥ 7.0; SBOM submitted as part of UNECE R155 compliance evidence

▸ Security regression test suite: maintain library of reproducer payloads from previous penetration tests and fuzzing campaigns (stored in Git-LFS); on each CI run, replay all known-crash payloads against new firmware build - any payload that now passes (no crash) marks regression test PASSED; regression test framework: Python scripts using python-can + udsoncan libraries sending precisely crafted payloads; failed regression (previously fixed vulnerability re-introduced) triggers build block and Slack alert to security team; test suite is living document updated after every pentest engagement

6

Incident Response & Monitoring

4 chapters • 2.8 hrs reading

Vehicle Security Operations Center (VSOC) 45 min read

▸ VSOC architecture: vehicle fleet → TCU (Telematics Control Unit) collects IDS events + security logs → LTE/5G uplink to VSOC ingestion layer → Kafka message broker (topic: vehicle-security-events, partition by VIN) → VSOC SIEM (Splunk or Elastic SIEM) for correlation; data rate: typical vehicle generates 10–100 security events/day under normal conditions; anomalous conditions (IDS alert storm) may generate 10,000+/day; VSOC must handle 1M+ vehicles = 10B+ events/day at fleet scale

▸ VSOC detection rules (SIEM correlation): Rule 1 - CAN injection detection: >5 SecOC VERIFICATION_FAILED events for same PDU within 60 seconds from same VIN → Severity HIGH, trigger incident workflow; Rule 2 - Brute-force SecurityAccess: >3 NRC 0x35 (InvalidKey) responses within 10 minutes → Severity MEDIUM, flag for review; Rule 3 - Anomalous geolocation: vehicle ECU clock reports ignition-on at location A while OBD-II last contact was location B (>200 km gap) within 30 minutes → potential relay attack → Severity HIGH; correlate all rules across fleet for campaign detection

▸ Fleet-level threat intelligence: VSOC analysts compare IDS alert patterns across VIN population - if same attack signature appears on 50+ vehicles in 48 hours, classify as coordinated attack campaign; generate threat intelligence report for PSIRT and OEM security team; share IoC (Indicators of Compromise: CAN ID + payload pattern, IP addresses, MAC addresses of attacking devices) with automotive ISAC (Information Sharing and Analysis Center, AUTO-ISAC) for industry-wide awareness; receive back peer OEM threat intelligence feeds to enrich detection rules

▸ VSOC UNECE R155 compliance requirements: OEM must demonstrate to Technical Service that VSOC is operational, monitors fleet continuously (24/7), has documented escalation procedures, and generates periodic security monitoring reports; minimum metrics to report: number of vehicles monitored, incident detection rate, mean time to detect (MTTD target: ≤ 24 hours for high-severity incidents), mean time to respond (MTTR target: ≤ 72 hours for critical incidents including OTA patch deployment); retain security event logs for minimum 3 years for regulatory audit

Intrusion Detection Systems (IDS) 40 min read

▸ AUTOSAR IdsM (Intrusion Detection System Manager, AUTOSAR R22): standardized interface between ECU security sensors and VSOC reporting; IdsM IdsEventIdType identifies each security event (e.g., IDS_EVENT_SECOC_VERIFICATION_FAILED, IDS_EVENT_SECURITY_ACCESS_DENIED, IDS_EVENT_INVALID_PDU_LENGTH); IdsM_ReportSecurityEvent(eventId, contextData) API called by BSW or SWC when anomaly detected; IdsM aggregates events, applies filter (suppression window to avoid storm), forwards via IdsR (IdsM Reporter) to TCU log buffer for VSOC upload

▸ CAN-based IDS detection methods: (1) Frequency-based: monitor actual CAN message frequency vs. expected from DBC (e.g., engine torque expected every 10 ms; >15 ms gap or <5 ms = anomaly); (2) Content-based: compare signal values against physics-based plausible ranges (vehicle_speed < 300 km/h, engine_rpm < 8000); (3) Sender authentication: SecOC CMAC verification - FAILED status for safety-critical PDU triggers immediate IDS event; (4) Network-level: unexpected CAN ID (not in DBC whitelist) triggers IDS_EVENT_UNEXPECTED_MSG_ID; implement in gateway ECU with full bus monitoring capability

▸ Ethernet/IP IDS using Argus Cyber Security or CYMOTIVE: deep packet inspection of SOME/IP and DoIP traffic; signature-based rules: flag UDS requests with SID combinations indicating reconnaissance (rapid enumeration of 0x22 ReadDataByIdentifier across all DID range 0x0000–0xFFFF); anomaly-based: machine learning baseline of normal SOME/IP service call patterns per ECU - flag deviations >3 sigma from baseline; deploy as passive monitoring tap on automotive Ethernet switch span port; no latency impact on vehicle functions

▸ IDS alert enrichment and correlation: each IDS alert tagged with ECU ID, bus ID, timestamp (GPS-synchronized via AUTOSAR StbM), trip counter, and contextual signals (vehicle speed, ignition state, door status) to enable forensic reconstruction; correlate: SecOC FAILED alert on CAN bus X + simultaneous unexpected Bluetooth connection event + OTA update request = likely coordinated attack; VSOC correlation rule fires with Severity CRITICAL → automated protective response: disable OTA client, restrict remote diagnostic session, trigger operator notification for manual investigation

Incident Response & Forensics 40 min read

▸ Incident response phases for automotive (ISO/SAE 21434 Clause 13): Detect (VSOC alert or external report) → Triage (CVSS severity classification, affected VIN count, safety impact assessment) → Contain (OTA disable of affected feature, kill-switch via remote UDS RoutineControl 0x31) → Investigate (root cause analysis, exploit path reconstruction) → Remediate (patch development, security review, integration testing) → Recover (OTA deployment to fleet, regression testing) → Post-incident review (TARA update, lessons learned); target timelines: Contain ≤ 4 hours for safety-critical, Remediate ≤ 30 days for CVSS ≥ 9.0

▸ Vehicle forensics data collection: connect via OBD-II DoIP, enter programming session with OEM security access → read all ECU extended DTCs (UDS 0x19 0x02 0xFF) to capture fault history → read IDS event logs via custom DID (0xF1A0 IDS_LOG_BUFFER) → extract tamper-evident event log from NVM via UDS ReadMemoryByAddress 0x23 (log signed with ECU private key for integrity verification) → save raw UDS log to .pcap file using Wireshark + DoIP dissector; for CAN evidence: collect CANalyzer .blf recording files from VIN-specific fleet telemetry archive in VSOC

▸ Root cause analysis methodology: binary diffing between compromised firmware version and previous safe version using Bindiff (Zynamics); identify changed functions - focus on security-relevant modules (SecOC, UDS session management, CAN gateway routing); reconstruct attack path using VSOC event timeline (IDS alerts with timestamps) correlated with CANalyzer recordings; identify entry point (Bluetooth stack heap overflow at 14:23:07 UTC) → pivot (privilege escalation via kernel CVE-2023-XXXX at 14:23:12) → objective achieved (CAN injection starting at 14:23:15); timeline precision enables attribution and patch targeting

▸ Post-incident TARA update: after root cause confirmed, update TARA worksheet - (1) add new threat scenario if not previously modeled, (2) if existing TS - update attack path with actual observed method (ET=minutes if exploit publicly available), (3) recalculate AFR (existing countermeasures clearly failed → raise feasibility score), (4) add new countermeasures targeting identified weakness, (5) re-rate residual risk; notify Technical Service of significant security incident as required by UNECE R155; publish coordinated disclosure advisory with CVE assignment via MITRE CNA; update SBOM affected component to patched version

OTA Security & Secure Update 45 min read

▸ AUTOSAR UCM (Update and Configuration Management) architecture: UCM Master (in central gateway) orchestrates update campaign across vehicle; UCM per ECU receives and installs software packages; package format: AUTOSAR Software Package (SWCL manifest + software cluster binary, ARXML defined); package delivery: SOMA (Software Over the air Manager) downloads from OEM backend via HTTPS → decrypts + verifies package signature (ECDSA-P256) → forwards to UCM Master → UCM coordinates update order respecting inter-ECU dependencies defined in VehiclePackage manifest

▸ Secure package integrity and authenticity: OEM build system signs each SoftwareCluster package: SHA-256 hash of binary → ECDSA-P256 signature with OEM code-signing private key (stored in offline HSM) → signing certificate chain embedded in package manifest; on-vehicle UCM verifies: cert chain valid (against embedded Root CA trust anchor) → signature verifies over binary hash → software version ≥ current installed version (anti-rollback: reject if VersionNumber in manifest < SecurityVersionNumber stored in ECU OTP fuse); reject package if any check fails before writing to flash

▸ A/B partition update mechanism: ECU flash divided into Partition A (active, currently running) and Partition B (update target); UCM writes new software to Partition B while vehicle running (background download + write); on next controlled power cycle, bootloader reads UCM swap flag → boots from Partition B → verifies image integrity before marking B as active; if verification fails or application crashes within first 5 boot cycles (health counter in NVM), bootloader rolls back to Partition A - ensures vehicle never stuck in unbootable state; A/B requires 2× flash size but eliminates update brick risk

▸ Campaign management and consent: VSOC sends targeted update campaign specifying affected VINs (from SBOM CVE match), update priority (safety-critical = mandatory, no opt-out), and deployment strategy (staged rollout: 1% of fleet → 10% → 100% with 24-hour soak period between phases); vehicle-side: UCM checks campaign authorization token (JWT signed by OEM backend, includes VIN + campaign ID + expiry) before accepting package; driver notification via HMI; update status telemetry uploaded to VSOC: DOWNLOAD_STARTED, VERIFICATION_PASSED, INSTALL_COMPLETE, ACTIVATION_PENDING, ROLLBACK_OCCURRED (triggers immediate VSOC investigation)

Automotive Cybersecurity

Overview

Course Modules

Tools Used

What You'll Learn

Prerequisites

This course includes: