All outbound messages in an ITS system must be cryptographically signed using certificates that encode authorized behaviours. This ensures message integrity, origin authenticity, and accountability. Depending on the communication context, authentication may occur at the message level (e.g., signed BSMs over broadcast) or via mutually authenticated sessions (e.g., secure TCP-based control exchanges using ISO 21177). This pattern enforces trust relationships, supports interoperability, and provides a basis for misbehaviour detection and privacy-preserving identity models. Authenticated messaging requires a valid certificate, trusted anchors, and policy-aware enforcement. In privacy-sensitive applications, pseudonym certificates should be used and rotated regularly.
Key Provisioning: Devices must generate or receive cryptographic keys securely. Certificates must be provisioned via a recognized PKI (e.g., SCMS, CCMS) with correct fields (e.g., PSID, SSP, ITS-AID).
Message Signing: Applications must sign outbound messages with a certificate that explicitly authorizes the message type or service (e.g., an SRM must be signed with a certificate that includes the relevant PSID and SSP).
Session Setup (ISO 21177): For connection-based communications, devices should implement mutual authentication and secure session negotiation. Signed session setup messages form the basis for trust.
Policy Validation: In addition to verifying the certificate’s signature chain, recipients must validate that the certificate includes the correct PSID or ITS-AID for the incoming message, and if applicable, that any SSP constraints are met. Messages that do not meet these criteria must be dropped or logged.
Pseudonym Use and Rotation: For privacy-sensitive messages, pseudonym certificates should be rotated frequently to prevent long-term tracking. Rotation policies should align with privacy requirements and backend validation capabilities.
Trust Anchors: All devices must maintain an up-to-date CTL listing trusted Root CAs. Chains that do not resolve to a listed Root must be rejected.
Certificate Updates: Devices may support secure download of updated certificates or CTLs, either autonomously or during a maintenance cycle. Updates must be validated before use.
Ensures that ITS devices only accept messages that are digitally signed with certificates issued by trusted Certificate Authorities (CAs). Each device validates incoming messages by checking the sender's certificate and confirming that it chains to a known Root CA listed in its Certificate Trust List (CTL). This protects against unauthorized or spoofed messages and enforces compliance with trust policy across deployments.
Signature Validation: Each received message must be digitally signed. The receiving device extracts the certificate from the message and verifies the cryptographic signature.
Certificate Path Building: Devices build a trust path from the sender’s certificate through one or more intermediary certificates to a Root CA listed in the CTL. See Diagram below.
CTL Management: Devices must be provisioned with an up-to-date Certificate Trust List. Only certificates chaining to a listed Root CA are accepted.
Chain Validation Logic: Each certificate in the chain must be valid (not expired or revoked), and its issuer must be the subject of the next certificate in the chain.
Performance Considerations: Trust chain validation and signature checking must be efficient to support real-time message processing in latency-sensitive ITS environments.
Restricts ITS application behaviour to only those actions explicitly authorized through certificate entitlements. Applications are identified using Provider Service Identifiers (PSIDs) or ITS Application Identifiers (ITS-AIDs) with permissions further refined through Service-Specific Permissions (SSPs). These constraints are enforced by both senders and receivers to prevent unauthorized use of ITS messages or services. This pattern enforces least privilege and supports federated trust enforcement.
Certificate Configuration: SCMS/CCMS must issue certificates with valid PSID and optional SSP values appropriate to the role of the device.
Sender Behaviour: Devices must select certificates that match the intended application. This may require runtime certificate selection or predefined associations.
Receiver Behaviour: RSUs or backend systems must inspect both PSID and SSP fields before processing messages. Rejected messages should be logged and discarded.
Local Policy Filters: RSUs or backend systems may apply operational policies to further constrain behaviour (e.g., only vehicles from authorized agencies may request signal priority).
Operational Context: Devices may carry multiple certificates, each with different entitlements. Runtime logic must select the appropriate credential based on the current application and role.
