Overview
This series explains how a connected-vehicle backend can authenticate one vehicle yet expose another vehicle’s topic, object, or command when identity is not bound to the requested resource. It traces the vehicle, app, and cloud roles; separates seed access from victim impact; compares MQTT, HTTPS, and SMS evidence; and evaluates fixes. The study covers five production vehicles in three OEM ecosystems, not universal fleet prevalence.
Learning outcomes
- Authentication identifies a vehicle session; authorization must bind it to the exact topic, object, or command requested.
- A local seed foothold is distinct from victim impact; target mutation tests whether the backend enforces that boundary.
- MQTT, HTTPS, and SMS require different checks, but each must preserve identity-to-resource scope.
- Effective fixes combine per-resource checks, uniform backend deployment, and verification at the resulting vehicle or object.
- The five-vehicle study provides bounded evidence, not a universal prevalence estimate; observed counts and vendor scope differ.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Why doesn’t vehicle authentication authorize access to another vehicle?
Vehicle authentication proves which vehicle established the session, not which resources it may use. Another vehicle’s topic, object, or command requires a separate authorization decision.
How did the study test cross-vehicle authorization?
Researchers used a controlled seed vehicle, established a fresh valid session, and changed only the application-level target. They compared the result with a seed-scoped baseline and required meaningful resource or state evidence.
What did the study find across MQTT, HTTPS, and SMS?
In the evaluated paths, MQTT exposed out-of-scope traffic and accepted cross-tenant commands, HTTPS returned a victim-scoped media object, and SMS accepted wrongly targeted commands. Each result required its own resource-level evidence.
What does the study’s evidence show about fleet-wide risk?
It demonstrates authorization failures in five production vehicles across three OEM ecosystems, not universal prevalence. The 574-VIN observation is a bounded lower bound, while the approximately 1.44-million figure was vendor-reported deployment scope.
What should a real connected-vehicle fix verify?
A real fix should verify denial or absence of effect when a valid identity requests an out-of-scope target. That check must hold across broker clusters, object delivery, fallback commands, and changing vehicle generations.