Krishna Teja Medam | Searcharxiv

arXiv2026

Automotive HSMs - Architectural Challenges and Security Implications

Automotive electronic control units (ECUs) increasingly depend on hardware-rooted security to protect software integrity, authenticity, and lifecycle management in the presence of remote and physical threats. Hardware Security Modules (HSMs) have become a key building block in automotive system-on-chips (SoCs), providing isolated cryptographic services, secure key storage, and controlled execution under stringent real-time and cost constraints. This paper presents an architectural analysis of automotive HSMs and examines their role in establishing secure boot and hardware roots of trust. We first survey common HSM integration models used in production ECUs and discuss their flexibility and current automotive use cases. We then introduce realistic threat models to motivate hardware-backed security controls and analyze how HSM design choices influence secure boot chains of trust, secure storage, secure execution, and software signing mechanisms. Key tradeoffs between isolation, performance, updateability, and attack surface are discussed, with optional consideration of side-channel implications. The paper concludes by highlighting open challenges and future directions for scalable and resilient automotive hardware security. Finally, we discuss emerging challenges such as cryptographic agility and post-quantum readiness that are likely to shape the next generation of automotive HSM architectures.

cs.CR↗

arXiv2026

Autonomous Cyber Defense in Connected Vehicles: A Multi-Agent Approach to V2X Security

A connected vehicle has roughly 100 milliseconds to decide whether an incoming Basic Safety Message is real or fabricated. If a false emergency braking alert reaches the planning pipeline in time, the car brakes - a safety failure triggered by a security failure. Existing intrusion detection systems are not designed to handle that coupling. They operate per vehicle, per message, with static rules - blind to attack patterns that only emerge across a fleet or over time, and blind to the fundamental tension between dropping a suspicious message and dropping a real emergency alert. We propose a three-tier multi-agent architecture that treats this timing constraint as a hard design requirement, not a performance target. At the vehicle level, an onboard agent classifies each incoming V2X message into one of four actions - Accept, Drop, Quarantine, or Escalate - within a 10-millisecond budget, deliberately biased toward Escalate when uncertain, passing ambiguous cases to the roadside edge agent rather than risking a dropped legitimate alert. The edge agent operates across a roadside unit zone with a 50-millisecond budget, fusing threat assessments from multiple vehicles and resolving safety-security conflicts using complementary sensor observations. The cloud tier refines detection models through Byzantine fault-tolerant federated learning and redistributes updated weights to the fleet. Every timing constraint derives directly from the 100-millisecond Basic Safety Message cycles mandated by SAE J2735 and ETSI EN 302 637-2. No existing framework simultaneously assigns standards-grounded latency budgets to all three deployment tiers while treating safety-security conflict resolution as a first-class design constraint. Remaining open problems - adversarial poisoning at the edge and the absence of regulatory frameworks for autonomous security response - are discussed as future work.

cs.CR↗