Researchers built a hardware-in-the-loop vehicle-to-infrastructure system that checks whether a security verdict is still useful when an autonomous vehicle needs to act. Its mission-aware attestation envelope combines platform integrity, evidence age and decision latency, showing that trustworthy proof can arrive too late—or describe a system state that is already too old—to safely authorize a time-critical action.
What did the researchers build?
The researchers built a test system for a vehicle asking roadside infrastructure to authorize a time-critical action. A vehicle-to-infrastructure (V2I) connection carries the request from an onboard unit, or OBU, to a roadside unit, or RSU. The RSU checks the requester’s identity and consults hardware-backed evidence about the platform’s software before returning a decision.
The test combines the CARLA driving simulator with a physical OBU and a TPM-backed roadside unit. CARLA supplies the vehicle’s position and speed, letting the researchers test different approach distances and timing conditions without staging road experiments. The RSU records both its verdict and the timestamp of the integrity evidence used to reach it. That timestamp matters: without it, the system cannot tell whether the evidence describes the platform now or an earlier state.
The central contribution is a contract for deciding when evidence is actionable, not just whether it is cryptographically valid. It requires three conditions at once: the measured platform passes its integrity check, the evidence is fresh enough, and the decision arrives before the vehicle’s physical action window closes. A four-outcome decision scheme keeps those failure reasons separate instead of reducing them to a single “allow” or “deny.”
What were the key results?
The experiments show that security evidence and physical timing must be assessed together. The result is an operating envelope: the set of combinations of evidence age, decision latency and vehicle state where the RSU can still make a useful, secure decision. A model that ignores the cost of obtaining assurance makes that envelope look larger than it does when hardware-backed attestation is included. In this study, the difference is concentrated in evidence age rather than decision latency.
The sensitivity analysis gives two concrete comparisons. Scaling latency by a factor of five removes 19 feasible operating points. Increasing the attestation interval from its configured two seconds to the ten seconds tolerated by the verifier removes 22. These are counts of operating points in the tested envelope, not measurements of attacker effort or proof that an attack can cause either change.
| Change in the tested configuration | Effect on feasible operating points |
|---|---|
| Latency scaled by five | 19 fewer |
| Attestation interval increased from 2 seconds to 10 seconds | 22 fewer |
The platform measured end-to-end latency, status-query duration and evidence age, and the analysis considered mean, median, 95th-percentile and maximum observed latency. The reported text does not supply the raw latency values, so no absolute response-time figure can be compared here. Crucially, the maximum observed latency is not a guaranteed upper bound: the study establishes no execution-time or network bound.
How does mission-aware attestation work?
The contract tracks three separate questions. Is the evidence valid? The integrity measurement must show that the measured platform has not violated its policy. Is the evidence fresh? Its age must remain within a configured limit. Is the decision timely? The request, checks and response must finish while the vehicle still has enough time to act.
The physical deadline depends on the request’s state, including the vehicle’s distance and speed. The research uses that state to calculate a per-request action window, then compares it with the measured end-to-end decision time. In simple terms, a valid verdict is useful only if it reaches the vehicle before the relevant physical opportunity has passed. The evidence-age limit and the response deadline are distinct margins: satisfying one does not guarantee the other.
The decision scheme distinguishes four outcomes: allow when all conditions pass; deny for an integrity violation; deny because the evidence is stale; and deny because a valid, fresh decision arrived too late. This distinction helps operators tell a security problem from a timing problem. There is an important interaction, however: when the freshness limit is tight enough, every late decision is already stale. Under the contract’s precedence rule, those cases are reported as stale, so a separate late outcome cannot appear.
The measurements cover several parts of the loop, but not every component separately. End-to-end latency includes request transport, identity checking, the status query, policy evaluation and response transport. The status-query duration is also measured; the remaining terms are not individually isolated. The OBU publishes at a different quality-of-service level from the other components, adding an acknowledgement round trip to each end-to-end measurement.
Why does this matter for robotics?
Robots and autonomous vehicles often act on decisions assembled from remote software checks, sensors and communications. For a time-sensitive action, a correct security result can still be operationally useless if it arrives after the robot’s safe action window. Conversely, a quick decision based on old evidence can create unjustified confidence. The envelope provides a way to reason about both risks together.
For system designers, the key lesson is that an attestation interval cannot be chosen on security grounds alone. A shorter interval can keep evidence newer, but it changes the operating envelope; communication load and verification time also affect whether a decision remains timely. The right settings depend on the mission’s physical horizon and the assurance process’s measured costs. Operators can use the same reasoning when evaluating connected autonomy systems, including mobile robots that rely on infrastructure services. Teams comparing platforms can also browse used robots for sale.
The study does not show that this approach makes every action safe. It offers a more informative authorization decision: one that can distinguish compromised integrity, stale proof and a missed deadline. That can help developers diagnose why a system refused an action and help operations teams understand whether a security policy fits the timing demands of deployment.
What are the limitations and open questions?
The tests use a hardware-in-the-loop setup, not a live road deployment. CARLA supplies the physical scenario, while the study measures a particular OBU, roadside unit, verifier interface and communication configuration. Different hardware, networks or workloads could produce a different envelope. The paper also reports maximum observed values, not guaranteed worst-case response times, because it establishes no bound on execution or network delay.
The threat model allows a rogue OBU, file modifications to measured software and arbitrary channel traffic. It assumes the attacker cannot forge platform-integrity evidence, defeat the measurement policy or compromise the plant. The researchers did not perform an attack; the sensitivity results describe how the envelope changes, not whether an adversary can cause those changes in practice. The tamper test demonstrates detection of a policy-covered modification under a non-adversarial decision process, not protection against a compromised decision point.
What should readers know?
Does a valid attestation prove that a robot can safely act? No. The evidence must also be fresh, and the decision must arrive before the physical deadline.
What does the attestation envelope represent? It is the set of tested conditions under which integrity, evidence age and decision timing all meet the contract.
Why are stale and late decisions treated separately? Stale evidence concerns how old the proof is; lateness concerns whether the decision arrived in time. One decision can fail both conditions, and the contract prioritizes the stale label in that case.
Does the study prove that an attacker can delay the system? No. It measures how the feasible operating region changes under latency scaling, but does not establish attacker effort or demonstrate an attack.
What is the takeaway?
Security evidence is useful for autonomous action only when it is valid, recent and delivered in time. This V2I study shows why those conditions belong in one mission-aware decision contract, while also making clear that measured performance is not a worst-case guarantee.