ISO 21177 ITS Station Security Services
The session-layer security framework for cooperative ITS stations. Defines the security service primitives that an ITS application invokes, the secure-session establishment protocol between ITS stations, and the bridge from the 1609.2 / 102 941 PKI primitives down into application-layer secure sessions.
Scope & status
What 21177 defines
Session-layer security services for ITS station-to-station communication. Service Access Point (SAP) definitions, secure session establishment using 1609.2 certificates, mutual authentication, key derivation, and integrity protection for unicast ITS sessions (as distinct from broadcast V2X messages).
How 21177 fits
Sits above 1609.2 / 102 941 (which provide certificates and PKI) and below ITS applications (which consume security services through SAPs). The standard is what application code talks to when it needs an authenticated session with another ITS station.
Where 21177 applies
ITS station-to-station sessions: vehicle ↔ backend, RSU ↔ central management, OBU ↔ OBU unicast sessions. NOT the broadcast V2X case (CAMs, DENMs) — those are message-by-message signed under 103 097 and do not establish a session.
Service primitives
Session establishment
Initiates a secure session between two ITS stations. Either party authenticates with a 1609.2 certificate; mutual authentication is the typical mode. Returns a session context the application uses for subsequent secured data exchange.
Session data exchange
Application data sent through an established session is integrity-protected and authenticated using session keys derived during establishment. Confidentiality is optional and is selected at establishment time.
Session termination
Explicit or implicit (timeout-based) closure. Session keys are wiped from the secure element on termination; subsequent traffic to the same peer requires a fresh session.
Peer authentication query
An application may query the session context for the peer's authenticated identity (the certificate the peer used to establish). This is what an application uses to enforce authorisation policy based on certificate permissions.
Session establishment flow
1. Initiator hello
Initiating ITS station sends a session-establishment request: its 1609.2 certificate (or the digest if cached), an ephemeral key contribution, a nonce, and the session-parameter selection (cipher suite, confidentiality on/off).
2. Responder hello + signature
Responder validates the initiator's certificate against trust anchors, returns its own certificate, its ephemeral key contribution, and a signature over the exchange transcript. Optionally indicates which application services it accepts.
3. Initiator signature
Initiator validates the responder, computes the shared secret from the two ephemeral contributions, derives session keys, signs the transcript. Sends the signature to the responder.
4. Confirmed session
Both sides derive matching session keys from the ephemeral contributions and the long-term certificate identities. Subsequent application data is protected under these keys. The signature step makes the exchange replay-resistant.
Certificate use within sessions
EC vs PC at session layer
Sessions are typically authenticated with ECs (long-lived identity) rather than PCs (short-lived broadcast credentials). A session to a backend identifies the device; pseudonymity does not apply to unicast traffic where the backend already knows which device it is talking to.
Permission-bound sessions
A certificate's appPermissions SSPs constrain what services it may invoke through an established session. Verifiers enforce this at SAP boundary: a CAM-permitted certificate cannot establish a maintenance-management session.
Hardware-bound endpoints
The session private key remains in the secure element. Session-key derivation, ephemeral contribution generation, and signature operations are SE-side. The host MCU receives session-encrypted application data but never holds the session-derivation material.
Revocation during a session
If the peer's certificate is revoked mid-session, the session does not automatically terminate — revocation enforcement is implementation-dependent. Most implementations re-check at next session re-key.
Implementation implications
SE session-key custody
The secure element holds the long-term EC private key and performs the ECDH contribution for ephemeral key agreement. The session symmetric keys may live in the SE (high assurance) or be exported under a wrapped channel (performance-sensitive paths).
Round-trip cost
The 4-message handshake adds latency before application traffic flows. For long-lived sessions (RSU ↔ central management) this is negligible; for short-burst sessions, the handshake cost dominates.
Certificate caching at the responder
An RSU servicing many OBU sessions caches OBU certificates it has previously authenticated, allowing digest-only references on subsequent re-handshakes within a short window.
SAP integration
Application authors invoke the security SAP rather than direct certificate operations. This abstracts the difference between 1609.2 and other underlying PKI primitives; the same SAP shape can be backed by different PKI material.
Companion AmbiSecure pages
Architecture
V2X PKI technology page · V2X security solution · Device identity at scale
Adjacent references
IEEE 1609.2 certificate format · ETSI TS 103 097 (broadcast V2X) · ETSI TS 102 941 (PKI architecture)
Hardware
IoT Security Co-Processor — secure-element silicon for session-key custody and ECDH operations.
External references
Standards bodies
ISO TC 204 (Intelligent transport systems) · ISO 21177 (Cooperative ITS security services) · ISO 21217 (ITS station reference architecture) · ISO 24102 (ITS station management)
Aligned ETSI / IEEE work
ETSI TS 102 941 (PKI architecture this slots into) · IEEE 1609.2 (underlying certificate format)
Disclaimer
This page is a structural reference summary derived from publicly available ISO 21177 concepts. For implementation conformance, consult the published ISO standard directly.