Updated 2026-10-14

Three kinds of message

Every byte an RSU or OBU puts on the air is wrapped in an IEEE 1609.2 secured protocol data unit (SPDU). The wrapper is a two-field structure, Ieee1609Dot2Data { protocolVersion 3, content }, and the content is one of three things:

So "secure" on a V2X radio means signed, not secret. A signed SPaT can be read by anyone with the decoder on this site; what the signature adds is proof of who sent it and that nobody changed it.

What a receiver does with a signed message

1. Decode the SPDU (COER encoding, IEEE 1609.2). Our decoder does this automatically when the bytes start with 03 81.
2. Find the signer. About once a second the sender attaches its full certificate; the rest of the time it sends only the HashedId8, the last eight bytes of the SHA-256 of that certificate. A receiver that has not heard the certificate yet asks for it with a peer-to-peer certificate distribution request and cannot verify until it arrives.
3. Walk the chain. The certificate's issuer field is the HashedId8 of the certificate that signed it; that one points to its issuer, and so on up to a root certificate the receiver trusts because it is on the Certificate Trust List published by the SCMS Manager's electors.
4. Check the permissions. The header's PSID must appear in the signer certificate's appPermissions, with any service specific permissions (SSP) the application defines. An RSU certificate that permits SPaT and MAP cannot sign a BSM.
5. Check time, place and revocation. The certificate's validity period must cover the generation time; a region in the certificate must contain the generation location; the certificate must not be on the current revocation list.
6. Verify the signature. The value signed is SHA-256 of the encoded ToBeSignedData concatenated with SHA-256 of the signer certificate, hashed once more inside ECDSA over NIST P-256. If that fails, the message is dropped and may be reported.

The security lab runs these six steps on any signed message you paste and on the ones it signs for you, and shows which step fails when you flip a byte, use the wrong PSID or sign with an expired certificate.

What is in a certificate

An IEEE 1609.2 certificate is much smaller than an X.509 one (150 to 200 bytes) and has no subject name in the usual sense. The lab shows every field decoded; the ones that matter:

• id: a name for infrastructure and CA certificates, linkageData for vehicle pseudonym certificates (so a misbehaving vehicle's batch can be revoked without identifying the vehicle), or none.
• cracaId and crlSeries: which CRL to check.
• validityPeriod: start (seconds since 2004) and duration. Application certificates are short; a week with a one hour overlap is the common RSU profile. Enrollment certificates last years.
• region: where the certificate is valid, as a circle, rectangles, polygon or identified region (country, state).
• appPermissions: the PSIDs and SSPs the holder may sign. certIssuePermissions marks a CA; certRequestPermissions marks an enrollment certificate.
• encryptionKey: the public key others encrypt to.
• verifyKeyIndicator: the ECDSA public key, or for implicit certificates a reconstruction value the receiver turns into the key.
• signature: by the issuer.

Explicit certificates carry the public key; implicit certificates (used for pseudonym certificates) carry a reconstruction value and are smaller. The lab builds explicit ones.

Bootstrap: from a bare device to a signing RSU

1. Keys in the HSM. The device generates its key pairs inside its hardware security module. Private keys never leave it; SCMS Manager's end entity requirements call for FIPS 140-2 level 3 or equivalent storage on production devices.
2. Trust store, in a controlled place. The operator (or the vendor, or a contractor) loads the root certificates and the elector-signed Certificate Trust List, the Enrollment CA certificate, the Registration Authority's address and the device's permitted PSIDs. SCMS Manager requires this secure bootstrap to happen in an approved environment, which is why "factory bootstrapped" and "bootstrapped on the mast arm" are not the same thing.
3. Enrollment. The device sends an enrollment request signed with its own key to the Enrollment CA and receives its enrollment certificate: long-lived, good only for requesting other certificates.
4. Application certificates. The device asks the Registration Authority, signing with the enrollment certificate and encrypting to the RA. The RA checks permissions, hides the device's identity from the CA, and the Authorization CA issues the short-lived application certificates. Vehicles get pseudonym batches (20 a week, years ahead, through butterfly key expansion) so their messages cannot be tracked; RSUs get identified application certificates.
5. On the air. The device signs with the current application certificate, attaching the certificate about once a second and the digest otherwise, and refreshes certificates and the CRL over its backhaul. An RSU that loses its backhaul for a week runs out of certificates and goes silent, which is why the build-out page flags a missing backhaul and the simulator's unsigned RSU is ignored by every OBU.

The lab's bootstrap panel plays these steps with a demo root, Enrollment CA and Authorization CA that it creates for you.

Where certificates come from

Production certificates come from an SCMS provider certified under the SCMS Manager's policies; the root certificates that make them valid are on the Certificate Trust List signed by the SCMS Manager electors, and every production receiver holds that list. The SCMS guide names the providers that onboard public agencies, what the contract covers (enrollment, application certificates, CRL and CTL distribution, misbehavior handling), and the NTCIP 1218 objects that show certificate health on a live RSU. Test certificates for lab work are usually free from the same providers; the demo certificates from our lab are for understanding the format and the process and will be ignored by any production device, which is exactly what a production device should do with an unknown root.

Can I decrypt a secure message?

If "secure" means signed: yes, anyone can read it; paste it into the decoder or the security lab and you get the J2735 content, the signer's certificate and the verification result. If it is encryptedData: only a recipient named in it can decrypt, and only with the private key that matches the encryptionKey in that recipient's certificate. That key lives in the recipient's HSM. There is no master key, and this is deliberate: it is what keeps a vehicle's certificate requests private. The lab lets you encrypt a signed message to your demo device and decrypt it with the demo private key, and shows that a second demo device cannot.

What is signed on the air, by PSID

PSIDs are assigned under IEEE 1609.12; the SSP that goes with each one is defined by the SAE application standard (for example the TIM SSP says which ITIS content an RSU may sign).

Try it

The security lab builds a demo chain, signs any J2735 message from the creator's templates or your own hex, verifies it as a receiver would, shows the certificate fields, encrypts and decrypts, and inspects any frame you paste from a capture. For the standards themselves: IEEE 1609.2 (the structures and the cryptography), IEEE 1609.2.1 (the certificate management protocols between a device and the SCMS), IEEE 1609.12 (PSIDs), and the SCMS Manager's profile and end entity requirements linked from the SCMS guide.