V2X / ITS · ETSI TS 103 097

ETSI TS 103 097 Secured-Message Reference

The wire-format specification that wraps every signed V2X message in the ETSI ITS stack. Defines the SecuredMessage structure, the header info fields, the signer-info modes, and the application-profile constraints. Layered on top of IEEE 1609.2 cryptographic primitives via an explicit equivalence mapping.

Scope & status

What 103 097 defines

The on-wire format for secured V2X messages in the ETSI ITS-G5 protocol stack: SecuredMessage envelope, payload framing, header-info population rules, signer-info choice, and per-application profile constraints (CAM, DENM, SPaT/MAP, IVI).

Relationship to 1609.2

Modern editions of 103 097 reference IEEE 1609.2 for the underlying certificate format and cryptographic primitives. The two standards are intentionally aligned: a 103 097 SecuredMessage carries a 1609.2 certificate or its HashedId8 digest. Implementations share the COER decoder.

Profiles

Profiles constrain what may appear in the header info, which signer-info mode is permitted for which message type, and how often a full certificate must be included rather than just its digest. The CAM profile (Cooperative Awareness Message) is the most studied; DENM (Decentralized Environmental Notification) has stricter freshness requirements.

`SecuredMessage` structure

protocolVersion

Uint8 — current spec version. Sentinel for receiver dispatch to the correct parser.

headerFields

SequenceOf HeaderField — ordered list of header info entries (generation time, expiry, signer info, generation location, etc.). Order is canonical for replay-resistance.

payloadFields

SequenceOf Payload — the protected application data. Typically a single signed payload carrying the unsecured ITS message (CAM, DENM, SPaT/MAP) as an opaque OCTET STRING.

trailerFields

SequenceOf TrailerField — carries the ECDSA signature field at the end of the message. Single-element in practice for signed messages.

`HeaderField` entries

generation_time

Time64 (microseconds since IEEE 1609 epoch, 2004-01-01) — when the sender generated this message. Receivers reject messages with generation_time too far in the past or future.

expiry_time

Optional Time64 — explicit expiry. Many profiles omit this and rely on generation_time + profile-defined freshness window.

generation_location

Optional ThreeDLocation — ITS-coordinate latitude/longitude/elevation. Required by some profiles where the verifier checks the message's geographic plausibility.

signer_info

SignerInfo CHOICE: self, certificate_digest_with_sha256 (just the HashedId8), certificate (full cert inline), certificate_chain (cert + intermediates). Cadence governed by the profile: every Nth message includes the full certificate, the rest reference its digest.

its_aid

Optional IntX — the ITS Application ID (PSID-equivalent). Identifies the application type for verifier policy.

its_aid_list

Optional list variant for messages carrying multiple application contexts.

`SignerInfo` modes & the digest cadence

Digest mode

certificate_digest_with_sha256 — carries only the HashedId8 of the signing PC. The receiver must already have the full certificate cached from a prior message; otherwise verification stalls until a refresh.

Full-certificate mode

certificate — carries the signing PC inline. Larger message, but lets a fresh receiver verify immediately without certificate-fetch round-trips.

Chain mode

certificate_chain — carries the PC plus intermediate AA certificate. Used when a receiver may not have the issuing AA's trust anchor cached. Rare in steady-state vehicular traffic; more common in infrastructure broadcasts.

Cadence pattern

Profiles typically specify: include the full certificate every N messages or every T milliseconds, whichever comes first. Between full-certificate beacons, messages carry only the HashedId8. The trade-off is bandwidth vs verifier cold-start latency.

Application-profile constraints

CAM (Cooperative Awareness)

Periodic broadcast at 1–10 Hz. Profile mandates generation_time, generation_location, ITS-AID for CA service. Certificate-inclusion cadence typically every 1 second or every 10 messages.

DENM (Decentralized Environmental Notification)

Event-triggered. Higher integrity bar: stricter validity windows, mandatory generation_location, often full certificate inline because the receiver may not have seen the sender previously.

SPaT / MAP

Infrastructure-originated signal-phase-and-timing and intersection-map broadcasts. RSU-signed, low frequency (~1 Hz), receivers cache the RSU's certificate aggressively because RSU identity is stable across thousands of vehicle interactions.

IVI (In-Vehicle Information)

Infrastructure-originated signage and warnings. Similar caching profile to SPaT/MAP; geographic-region restriction in the signing certificate is more commonly populated.

Equivalence with IEEE 1609.2

The two standards align at the cryptographic primitive layer; what differs is the wire format and the operational profiles. The table below shows the structural equivalents.

Concept	ETSI TS 103 097	IEEE 1609.2
Signed message wrapper	`SecuredMessage`	`Ieee1609Dot2Data` with `signedData`
Certificate format	References 1609.2 `Certificate`	`CertificateBase`
Signer digest	`certificate_digest_with_sha256`	`HashedId8`
Generation time	`Time64` (µs)	`Time64` (µs)
Encoding	COER	COER
Signature	`EcdsaP256Signature` in trailer	`Signature` CHOICE

Implementation implications

Bandwidth budgeting

A CAM with full-certificate signer info is ~250 bytes; with digest-only signer info, ~80 bytes. At 10 Hz per vehicle on PC5, the certificate-inclusion cadence directly drives channel load. Profiles balance this against verifier cold-start latency.

Receiver cert cache

A verifier maintains a cache of recently-seen signing certificates indexed by HashedId8. Cache size, TTL, and replacement policy are implementation decisions; the standard specifies the on-wire format, not the cache.

Replay window

Generation-time validation defines an implicit replay-resistance window. A few hundred milliseconds is typical for CAMs; DENMs use longer windows because the event-triggered messages may be rebroadcast.

SE signing cost

Each signed message requires one ECDSA signature inside the secure element. At 10 Hz CAM, that is 10 signatures per second per vehicle. The chosen SE silicon must sustain this throughput at automotive temperature ranges — a hard requirement on the silicon spec.

Companion AmbiSecure pages

Tools

IEEE 1609.2 V2X Certificate Parser · V2X Certificate Chain Validator — parse certificates referenced inside a SecuredMessage signer_info.

Architecture

V2X PKI technology page · V2X security solution · Connected mobility

Adjacent references

IEEE 1609.2 · ETSI TS 102 941 · ISO 21177

Hardware

IoT Security Co-Processor — secure-element silicon that satisfies the 10 Hz signing throughput requirement.

External references

Standards bodies

ETSI Technical Committee ITS · ETSI TS 103 097 (latest edition) · ETSI TS 103 097-2 (testing) · ETSI EN 302 663 (ITS-G5 access layer)

Disclaimer

This page is a structural reference summary of publicly available ETSI TS 103 097 concepts. For implementation conformance, consult the published ETSI standard directly.