Mission-Aware Attestation Envelopes for Time-Critical Autonomous Action: A Hardware-in-the-Loop V2I Study
Researchers define mission-aware attestation that rejects stale or late integrity evidence on a hardware-in-the-loop V2I platform.
The paper formulates mission-aware attestation as a runtime contract requiring valid integrity evidence, sufficient freshness, and a decision inside a deadline derived from physical state. Evaluated on a hardware-in-the-loop vehicle-to-infrastructure setup, a driving simulator set deadlines while a microcontroller on-board unit and a TPM-backed Linux roadside unit supplied evidence. A security-blind model admitted the whole operating space and a hardware-informed model about three quarters; every refusal failed freshness rather than response time. The authors find the attestation interval is as consequential as a fivefold latency change and cannot be set from security requirements alone.
- Attestation is accepted only if valid, fresh, and decided before a physical deadline.
- The contract separates tampering, stale evidence, and late decisions.
- A hardware-informed model admits about three quarters of the operating space.
- Every refusal failed the freshness margin rather than the response margin.
From the original article
1 min read at arxiv.orgAn autonomous system that asks for a privileged physical action is usually gated on integrity evidence: a platform proves what it is running, and the request is granted or refused on that basis. Such a gate is normally treated as a predicate, yet the evidence behind it has an age, the decision that consumes it has a latency, and the physical system that waits for it has a deadline.
By Dimitrios Nikou · arxiv.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.