Autonomous Driving Cybersecurity for Over-the-Air Updates

Overview of Technical Issues:

During over-the-air software updates, external cyber threats can penetrate the communication interface and corrupt the update transmission pathway due to insufficient authentication verification and encryption protection, potentially allowing malicious code to reach vehicle control units and compromise safety-critical driving functions; the goal is to ensure secure OTA updates that maintain system integrity against sophisticated cyberattacks.

Solution directions generated for this problem

Problem Direction 1 :

ImproveAuthentication verification strength
VS
ConstraintSystem computational overhead

Inspiration 1 : Cross-domain reference

Application Principle: #2 Taking out (Extraction)
Cross-domain applicability Assess applicability
Communication system for supporting carrier aggregation and method and apparatus for updating system information thereof
Innovative Solution Refine solution

Dedicated Hardware Security Module for OTA Authentication Offloading

Offload authentication to dedicated HSM chip
How to solve :
  • Install a dedicated Hardware Security Module (HSM) chip on vehicle gateway — performs RSA-2048/ECC-256 asymmetric cryptography, HMAC-SHA256 operations, and certificate chain validation independently from main ECU
  • Main control unit receives pre-validated authentication tokens (16-byte lightweight format) instead of executing full cryptographic operations, reducing ECU computational load from 50% to under 8%
  • HSM operates at 200MHz clock with AES/RSA hardware accelerators, completes multi-factor authentication in 80-120ms, issues time-stamped tokens valid for single OTA session with embedded integrity checksums
Expected Effect : ECU CPU load -84%; authentication time <120ms; token validation <5ms
Risk Control :
  • HSM chip supply chain dependency
  • token replay attack if timestamp validation fails
  • HSM firmware update complexity

Problem Direction 2 :

ImproveEncryption protection level
VS
ConstraintSystem computational overhead

Inspiration 1 : Cross-domain reference

Application Principle: #2 Taking out (Extraction)
Cross-domain applicability Assess applicability
Communication system for supporting carrier aggregation and method and apparatus for updating system information thereof
Innovative Solution Refine solution

Dedicated cryptographic co-processor offloading for OTA encryption

Offload encryption to dedicated hardware accelerator
How to solve :
  • Integrate a dedicated AES cryptographic co-processor (e.g., ARM TrustZone CryptoCell or NXP CAAM) into the vehicle gateway architecture to handle all AES-256 encryption/decryption operations independently from the main ECU CPU
  • Pre-provision session keys in the co-processor's secure key storage during vehicle manufacturing, enabling the co-processor to autonomously execute block cipher operations (128-bit blocks, CBC mode) at hardware speed (≥1 Gbps throughput) without main CPU intervention
  • Implement a DMA-based data pipeline where incoming OTA packets are routed directly to the co-processor's input buffer via direct memory access, encrypted/decrypted in hardware (latency <10 μs per block), then transferred to target ECU memory—main CPU only handles lightweight packet routing logic consuming <5% CPU cycles
Expected Effect : Main CPU load reduced from 50% to <5%; encryption throughput ≥1 Gbps; total system overhead <8%
Risk Control :
  • co-processor integration compatibility with existing ECU architecture
  • secure key provisioning process vulnerability during manufacturing
  • DMA bus contention with safety-critical real-time tasks

Problem Direction 3 :

ImproveUpdate transmission integrity
VS
ConstraintUpdate process duration

Inspiration 1 : Cross-domain reference

Application Principle: #10 Preliminary action
Cross-domain applicability Assess applicability
Method and apparatus for selecting an access and mobility management function in a mobile communication system
Innovative Solution Refine solution

Pre-computed signature cache with idle-time verification for secure OTA updates

Cache cryptographic operations during vehicle idle time
How to solve :
  • Generate digital signatures and SHA-256 checksums on server side before transmission
  • embed in package header with timestamp validity of 72 hours, eliminating real-time hash computation during 15-20 minute update window
  • Deploy idle-time pre-validation during vehicle parking or charging periods — gateway downloads signature database and performs preliminary certificate chain verification, storing results in secure enclave (≥AES-256 protected)
  • Implement lightweight token-based verification during actual OTA session — ECU validates pre-computed signatures via fast lookup (≤50ms per chunk) instead of computing hashes for multi-GB firmware, reducing verification from 15-20 minutes to under 2 minutes
Expected Effect : Update duration reduced 40-50%; integrity verification maintained at cryptographic-grade
Risk Control :
  • signature cache expiration management
  • idle-time availability insufficient
  • secure enclave storage capacity

Problem Direction 4 :

ImproveCyber threat detection capability
VS
ConstraintUpdate process duration

Inspiration 1 : Cross-domain reference

Application Principle: #10 Preliminary action
Cross-domain applicability Assess applicability
Threat mitigation system and method
Innovative Solution Refine solution

Pre-staged threat signature caching with idle-time intrusion database synchronization

Cache threat signatures during vehicle idle time to eliminate real-time lookups
How to solve :
  • Download and cache intrusion detection signature database to vehicle gateway during overnight parking or charging sessions (≥2 hours idle time), storing 50,000+ attack patterns locally in 256MB flash memory
  • perform local pattern matching during OTA updates using pre-loaded signatures, eliminating cloud database query latency (5-10 min per lookup) and enabling sub-millisecond threat identification
  • implement incremental signature updates every 24 hours during idle periods, synchronizing only delta changes (typically 2-5MB) to maintain current threat intelligence without impacting OTA session duration
Expected Effect : Update duration maintained at 15-20 min; threat detection coverage 99.7%; zero real-time lookup delay
Risk Control :
  • signature database staleness between updates
  • flash memory wear from frequent writes
  • synchronization failure during short idle periods

Problem Direction 5 :

ImproveAuthentication verification strength
VS
ConstraintMust not deteriorate

Inspiration 1 : Cross-domain reference

Application Principle: #10 Preliminary action
Cross-domain applicability Assess applicability
Mesh network commissioning
Innovative Solution Refine solution

Pre-staged cryptographic token authentication for OTA security

Shift heavy authentication to idle time, use lightweight tokens during updates
How to solve :
  • Execute full multi-factor authentication and RSA-2048 signature verification during vehicle idle periods (parked, charging, ignition-off >30min), generating time-limited authentication tokens valid for 24-48 hours stored in secure enclave
  • During actual OTA update, vehicle ECU validates only the pre-issued token using HMAC-SHA256 (consuming <5% CPU vs 50% for full cryptographic operations), with token expiry and revocation checks via lightweight lookup tables
  • Implement token refresh mechanism—if update exceeds token validity or threat detected, system pauses update, re-executes full authentication during next idle window, then resumes with new token
Expected Effect : CPU load during update reduced from 50% to <5%; authentication strength maintained at RSA-2048 equivalent; update time reduced by 12-18 minutes vs real-time cryptographic verification
Risk Control :
  • token storage security breach risk
  • clock synchronization drift causing premature expiry
  • idle period insufficient for full authentication completion
Patsnap Eureka Solution