A free tool by ITS Roads, LLC
ITS RoadsCV2X
Security lab

Certificates, signed messages, encrypted messages: watch IEEE 1609.2 work

A V2X message is plain, signed or encrypted. Signed is what every SPaT, MAP, TIM and BSM is on a real road: anyone can read it, nobody can forge it. Here you build a demo certificate chain, sign a real J2735 message with it, verify it the way an on-board unit does, encrypt it to one device and fail to decrypt it as another, and inspect any secured frame from your own capture. Everything is encoded with the real IEEE 1609.2 structures (COER) by the portal codec. The demo root is not an SCMS root, and production equipment will ignore it, which is exactly what it should do.

Read first: plain, signed and encrypted messages explained and SCMS for roadside units (providers, contracts, certificate health over SNMP).

1. Build a demo certificate chain

Five certificates, the way an SCMS lays them out: a root CA, an Enrollment CA and an Authorization CA under it, and for your device an enrollment certificate (years, request-only) and an application certificate (short-lived, the PSIDs it may sign). Keys are ECDSA P-256; the private keys are shown here because this is a lab. On a real device they never leave the hardware security module.

Application PSIDs the device may sign

2. The bootstrap: from a bare device to a signing RSU

Where each certificate above comes from, in the order a real device gets them. Click a step to highlight the certificate or operation it produces in this lab.

  1. 1
    Device (RSU or OBU)

    Generates its key pairs inside its hardware security module. Private keys never leave it.

  2. 2
    Operator, through the Device Configuration Manager (DCM)

    In a controlled environment, loads the trust store: the SCMS root certificates and the Certificate Trust List signed by the electors, the Enrollment CA certificate, the Registration Authority address, and the device's identity and permissions (which PSIDs it may request).

  3. 3
    Device to Enrollment CA (ECA)

    Sends an enrollment request signed with its own key (proof of possession). The ECA issues the enrollment certificate: long-lived (years), usable only to request other certificates, carrying certRequestPermissions.

  4. 4
    Device to Registration Authority (RA)

    Requests application certificates, signed with the enrollment certificate and encrypted to the RA. The RA checks the permissions, strips the identity, and forwards to the Authorization CA (also called the Pseudonym CA for vehicles, which get batches of 20 certificates a week, years ahead, through butterfly key expansion and linkage values).

  5. 5
    Authorization CA to device (through the RA)

    Issues the application certificate(s): short validity (one week with a one hour overlap is the common RSU profile), the permitted PSIDs and SSPs, optionally a region. The device downloads them over its backhaul; an RSU that cannot reach the RA for a week goes silent on the air.

  6. 6
    Device on the air

    Signs every message with the current application certificate, attaching the full certificate about once a second and the 8-byte digest otherwise. Receivers verify the chain against the CTL, the validity, the PSID permission, the time and location, then the signature.

  7. 7
    Misbehavior Authority and CRL

    Receivers report misbehavior; the SCMS revokes by certificate hash (RSUs) or linkage value (vehicles) on a Certificate Revocation List the devices fetch regularly. Encrypted messages carry SCMS traffic and misbehavior reports, not safety broadcasts.

Where real certificates come from. An SCMS provider certified under the SCMS Manager's policies, under a root on the elector-signed Certificate Trust List that every production device holds. The SCMS guide names the providers that onboard agencies and what the contract covers. Test certificates for lab work are usually free from the same providers.

3. Sign a message with the application certificate

Pick a J2735 message (a creator template, or paste UPER hex of your own MessageFrame) and the PSID. The lab wraps it as unsecuredData, adds the header, hashes the encoded ToBeSignedData together with the signer certificate, signs with ECDSA, and shows the bytes that would go on the air.

4. Verify a signed message as a receiver

Paste any signed Ieee1609Dot2Data (hex). With your demo chain loaded, the receiver trusts the demo root; without it, it only knows what is inside the message, which is how a real OBU sees an unknown signer.

5. Encrypt to one device, decrypt as that device, fail as another

Encryption in V2X is for the SCMS traffic and misbehavior reports, not for safety broadcasts. The structure is encryptedData: a one-time AES-128 key, wrapped with ECIES to each recipient's encryptionKey, and AES-CCM over the data. Only the private key in the recipient's HSM can unwrap it. There is no master key; the lab shows a second demo device failing.

6. Inspect any secured frame from a capture

Paste hex from a pcap, an RSU log or a vendor tool: a whole Ethernet frame, a WSMP frame or a bare SPDU. The lab peels the layers, names the kind of SPDU, decodes the signer certificate if one is attached, and tells you what a receiver would need to go further. Signed messages are readable by anyone; encrypted ones list their recipients and nothing else.

Training material. The demo chain, keys and messages are generated per visit and kept only in your browser. Production certificates come from an SCMS provider under the SCMS Manager's Certificate Trust List, and the private keys stay in the device's hardware security module. ITS Roads sets up SCMS enrollment, certificate monitoring and the FCC licensing for agency deployments: connected-vehicle services. See also the FCC licensing planner and the hardware build-out.