Castell · SkyV2X

Misbehaviour · TS 103 759

When a station
lies. Or breaks.

Misbehaviour reporting is the part of C-ITS PKI where the trust framework reacts to receivers that detect attackers, faulty stations or implementations gone wrong. ETSI TS 103 759 specifies the report formats and the authority that consumes them. Castell runs one.

Misbehaviour report submission and acknowledgement flow Reporter vehicle with AT observed misbehaviour builds MR-1 or MR-2 MA misbehaviour authority 405D3CF914EB9E05 verifies outer sig vs AA assigns report ID bumps mr_received_total Audit trail append-only log {id, reporter, cause} signed by MA POST MR ack signed persist
Submit. Acknowledge. Persist.

What ETSI TS 103 759 specifies

TS 103 759 (current version v2.2.1) defines the Misbehaviour Reporting framework for C-ITS: who can submit a report, what the report contains, how the receiving authority — the Misbehaviour Authority (MA) — authenticates the submitter, and how the resulting evidence is structured for downstream forensic or revocation use.

Two top-level report variants are defined. They differ in what evidence accompanies the claim:

MR-1 — Generic misbehaviour

The reporter says: "I observed a station behaving incorrectly". The report contains an enumerated cause code, the offending station's identity and the reporter's own pseudonym cert. No raw signed message is attached. Lightweight; suitable for transient or aggregated reports.

MR-2 — Reported signed message with proof

The reporter says: "Here is the exact signed message I'm complaining about". The report wraps an ASR — Application Signed Report — containing the original SignedData the reporter received, plus context about why it was deemed misbehaving (geometric impossibility, replay, signature failure). The MA can verify the inner signature independently.

How Castell's MA works

Castell exposes a Misbehaviour Authority at HashedId8 405D3CF914EB9E05. The MA cert is downloadable at GET /ma, served as COER-encoded bytes under application/x-its-cert. Submitters pin this cert to verify acknowledgements signed by the MA.

Reports are submitted as IEEE 1609.2 signed messages addressed to the MA's HashedId8. The MA validates the outer signature (the reporter must hold a valid AT cert issued by a Castell AA), parses the report payload, and records the entry in an audit trail.

# MA cert fetch
curl -sS https://pki.skyv2x.com/ma -o ma.coer
wc -c ma.coer
# ~189 bytes (TS 103 097 explicit cert, NIST P-256)

# Counters of received reports are exposed live
curl -sS https://pki.skyv2x.com/status.json | jq .counters.mr_received_total

What Castell currently does — and what it doesn't yet

Castell accepts both MR-1 and MR-2 outer envelopes today. The outer signature is verified against the issuing AA. The report enters the audit log and bumps the mr_received_total counter regardless of whether the inner ASR payload can be fully strict-decoded.

Inner ASR payload strict decode (parsing AsrCam / AsrDenm evidence per the ETSI ASN.1 Information Object Class definitions of TS 103 759) is not yet implemented in Castell. It is on the roadmap. Reports submitted today are accepted at the envelope level; inner payload introspection is best-effort. See the changelog for status.

Submitting a report

Reports are POSTed as IEEE 1609.2 signed envelopes. The endpoint, full schema and a minimal Python example are in the integration walkthrough. Briefly:

  1. You already hold an AT cert issued by Castell — if not, see the integration walkthrough for the EC→AT flow.
  2. Build the inner report payload — MR-1 (cause code) or MR-2 (wrapped signed message you want to report).
  3. Sign the report with your AT private key, addressed to MA HashedId8 = 405D3CF914EB9E05.
  4. POST the resulting envelope to the MA endpoint. The MA responds with a signed acknowledgement carrying the report's assigned ID.
  5. Verify the ack signature against the pinned MA cert. Persist the report ID for any follow-up.

Why this exists at all

In C-ITS, every vehicle gets a pseudonym cert every few minutes. There is no continuous identity binding to a human or a VIN. Attribution of a misbehaving station requires the report to reach an authority that can correlate pseudonyms back to enrolments — only the EA holds that linkage, and only on the basis of a report it considers credible.

The MR/MA protocol is how that credible evidence reaches the EA. Without it, a station could spam the network with invalid CAMs indefinitely; with it, repeated reports drive the EA to revoke the offending enrolment, after which no further AT certs are issued and the station can no longer participate.

Related material