What happens after a vehicle is reported in C-ITS

Most of what gets written about V2X security stops at detection: the moment a vehicle decides that a received message is a lie. That is the part a researcher enjoys, where the machine-learning papers and the plausibility checks live. It is also the easy half. A vehicle that catches a false hazard warning knows something the rest of the network does not, and the sender keeps broadcasting until that knowledge travels somewhere and comes back as an action. ETSI TS 103 759 specifies that second half: the report a station files, how it reaches the authority, and what the authority may do with it. What it does not do is make the liar stop quickly, and it is honest about why.

A valid signature is not a true message

The C-ITS trust model answers one question well and stays silent on another. It can prove a message came from a station that enrolled correctly and carries a valid certificate. It cannot prove that what the station said is true.

The standard names the gap in its definitions. A misbehaving entity (clause 3.1) is an ITS station that sends false or misleading messages while holding valid certificates, and the wording covers both a faulty station and a malicious one with legitimate credentials. A drifting sensor or a compromised unit signs its phantom pedestrian with the same cryptography as everyone else. The signature verifies; the content is false. Detection is the local judgement that the content is false despite the signature, and that is where TS 103 759 picks up.

The report carries a pseudonym the authority cannot unwind

A misbehaviour report is a structured message, well beyond a flag. It ties observations to specific messages the suspect sent: only something traceable to a particular ITS service and message can go into a report, and a suspicion that cannot be tied to an application goes through a reserved ITS-AID for unknown applications.

Two properties govern how it travels, and one of them is easy to get backwards. The report is signed, but it is signed with an Authorization Ticket, the same short-lived pseudonym a vehicle uses to send a CAM, carrying the permission to sign misbehaviour reports (clause 7.2; the ticket profile is in TS 103 097). It is encrypted to the authority, so the accusation is unreadable in transit. What the signature does not do is tell the authority who filed it: the standard requires the report to be designed so that the authority cannot link the reporter’s short-term pseudonym to its long-term identity (clause 4.2.4). An authority that wants to weight a reporter by reliability does it through a separate Diagnostic on Reporter function, which reads no name off the signature.

The report has a shape, and the shape is normative

The format is specified down to the ASN.1. The top-level protocol unit is a type called EtsiTs103759Data; its security envelope, EtsiTs103759MbrSec, is a choice of three forms, plaintext, signed, or signed-and-encrypted (clauses 7.1 and 7.2, the envelope in 7.2). The report bodies live in the normative modules of Annex A: a core module, an app-agnostic reporting module, one each for CAM and DENM, shared base types, and a module, SaeJ3287AsrBsm, that carries the SAE Basic Safety Message. That last module is why a European authority and a North American one can read the same report shape.

The content of a report is not left to taste either. Clause 6 sorts individual detectors into five classes and fixes the evidence each class must carry: a Class 1 observation shall include the triggering message; a Class 2 observation shall include at least two messages of the same type from the same station. So the standard fixes the envelope, the destination, and the minimum evidence. What it leaves to the builder is which checks raise a report at all, and those it sketches in the informative Annex D and the pre-standardization study TR 103 460.

How the report travels

For all the ASN.1, the transport is ordinary web plumbing, which is the part an implementer actually has to build. A report goes up over TLS as an HTTP POST to https://<host>:443/uploadMR-v1/<subpath> (clause 5.3), with a body of application/octet-stream and a plain status code back: 200 accepted, 400 for a malformed report, 500 for a failure on the authority’s side. The subpath selects the security form, /Plain, /Signed, or /SignedAndEncrypted, with the bare endpoint defaulting to signed-and-encrypted (clause 5.3). The destination is configurable, and how a vehicle discovers which authority to talk to is explicitly out of scope. One line in the same clause sets expectations for everything downstream: a vehicle does not wait for a decision, and the reporting process is not real-time.

The authority: preprocess, detect, respond

At the far end sits the Misbehaviour Authority. Its components are the ones defined in TS 102 940 (clause 4.1), and the detailed view in the informative Annex B draws it as more than a mailbox, as one example among those the standard allows. An optional preprocessing stage can sit in front, and this is where the Diagnostic on Reporter lives, establishing how reliable a report’s source is before the report itself is weighed. Global Misbehaviour Detection then does the backend work in two parts: investigation decides which station was at fault, and analysis establishes the facts on the ground. Only then does Response and Remediation act, and it holds four distinct levers:

• a Certificate Revocation List distributed to the ITS stations;
• a denylist, or Internal Block List, distributed to the certificate authorities so they stop issuing to the offender;
• an enforced software update;
• in-person remediation, physical action at the station.

The one everybody names first, revocation, is often the weakest here. Authorization tickets are short-lived, so a certificate on a revocation list can expire before the list reaches everyone; stopping issuance at the certificate authorities, through the denylist, bites harder.

How far the loop actually closes

So the loop is real, but it is slow, and part of it is not built yet. TS 103 759 specifies the report, its transport, and the authority’s interfaces. The certificate policy that would mandate misbehaviour handling notes that the function is not yet defined and may be designed in a future revision, and no authority runs this as a deployed European service today. Even once one does, the standard’s own timing is not the timing a safety engineer might hope for. The sender keeps emitting while a report is filed, investigated and answered, and while a revocation list or denylist propagates. That is hours or days.

The design also has to survive being used as a weapon. A report is an accusation, so a fleet of coordinated reporters or a flood aimed at one authority is a live concern; the pseudonymous-but-authenticated signing and the reporter diagnostic are what keep an accusation from being free, without pretending to make abuse impossible. And an authority only collects what it is authorized to. Its certificate carries a service permission listing the message types it may process (clause 8), which also fixes the certificate a reporter encrypts to, so the authorization closes on both ends before any of the four responses can fire.

Read it yourself

The report, its transport and the certificate profiles are in ETSI TS 103 759 V2.2.1: the architecture in clause 4, the dissemination protocol in clause 5, the evidence classes in clause 6, and the format and certificate profiles in clauses 7 and 8. The detection side it hands off to is the informative Annex D and the pre-standardization study TR 103 460 V2.1.1. For where the authority sits among the other trust roles, see TS 102 940 V2.1.1; for the Authorization Ticket profile the report is signed under, TS 103 097 V2.2.1. The SaeJ3287AsrBsm module carries the SAE Basic Safety Message.

For the layered picture these messages travel through, see the C-ITS architecture. For the messages a vehicle sends in the first place, the ones a report is about, see the ETSI C-ITS message set.