C-ITS ECA Overview

ENTERPRISE This is an EJBCA Enterprise feature.

This overview outlines the C-ITS PKI architecture and concepts and lists relevant C-ITS certificate fields.

For more information about managing C-ITS operations in EJBCA and creating an Enrollment Authority (EA) in a C-ITS PKI, see Managing C-ITS ECAs.

    Cooperative Intelligent Transport Systems (C-ITS) is an ecosystem to facilitate communication between vehicles and between vehicles and infrastructure, jointly known as vehicle-to-everything (V2X). Since the communication involves exchanging sensitive data between the vehicles and other entities, such as road infrastructure and road safety applications, it is crucial to protect and secure this communication. To enable secure V2X communication for C-ITS, Public Key Infrastructure (PKI) is used for the management of the security credentials of the vehicles and infrastructure components, commonly called ITS Stations (ITS-S).

    Technical security standards related to V2X communications are available and under development. The US standard IEEE 1609.2 covers security aspects, including secure message formats and security management. In Europe, ETSI publishes EU standards for C-ITS that extend the IEEE standard. For references to relevant standards and publications related to V2X and C-ITS communications, see References.

    Overview of C-ITS PKI

    The C-ITS Security Management System involves operations that support acquiring or establishing the validity of certificates for C-ITS communications and is built upon an elliptic curve-based PKI. The following provides a simplified overview of the C-ITS PKI architecture and describes the relevant actors involved:

    • Root Certificate Authority (Root CA, RCA)

    • Enrollment Authority (EA)

    • Authorization Authority (AA)

    • ITS station (ITS-S), for example a car or roadside equipment like a traffic signal.

    images/inline/1b9acecd4c21c226bb5b3ac9fb8aa130c18b2303.png

    For more details on the ITS security functional model and architectural overview of certificate authority (CA) roles, refer to the EU standard ETSI 102 940.

    In Europe, the top-level governance roles are defined in the C-ITS Platform Certificate Policy document. The following entities are responsible for the trust management of the C-ITS system and govern all aspects related to the operational PKI:

    • Policy Authority: Designates and authorizes the Trust List Manager (TLM) and the CPOC to operate in the C-ITS trust system. Decides if Root CAs are trustable and approves and/or removes the Root CAs operation in the C-ITS trust domain by notifying the TLM about approved and/or revoked Root CAs certificates.

    • Trust List Manager (TLM): Responsible for creating the list of root CA certificates and TLM certificates and signing it. The signed list issued by the TLM is called the European Certificate Trust List (ECTL).

    • Central Point Of Contact (CPOC): Responsible for establishing and contributing to ensuring communication exchange between the Root CAs, collecting the Root CA certificates, and providing them to the Trust List Manager (TLM). The CPOC is also responsible for distributing the European Certificate Trust List (ECTL) to any interested entities in the trust model.

    There are additional functional roles in the PKI described in ETSI 102 940 such as the Manufacturer and Operator that install necessary information for security management in ITS-S at production and provide updates during its operation.

    EJBCA can act as Enrollment Authority (EC) in C-ITS PKI and implements functionalities supported by EA.

    Actor

    Description

    Root Certification Authority ( RCA)

    Root CAs are located at the European level and controlled by C-ITS Point of Contact (CPOC). Root CAs issue Enrollment Authority (EA) and Authorization Authority (AA) certificates. Root CAs receive off-band signed certificate requests from Enrollment Authority (EA) and Authorization Authority (AA).

    Enrolment Authority (EA)

    The Enrollment Authority issues enrollment credentials (EC) to ITS-S. ITS-S possession of the EC allows for enrollment of Authorization Tickets. ITS-S sends an enrollment request to EA. If the ITS-S is registered to the EA by the Manufacturer or the Operator, and the corresponding request does not violate any constraints imposed during registration, then an EC is issued. EA needs to have a certificate signed by Root CA to be operational, that is to be able to issue enrollment credentials (EC).

    Authorization Authority ( AA)

    ITS-S sends an authorization request to the Authorization Authority (AA) to get Authorization Tickets (AT) . AA sends an authorization validation request to EA to validate such a request. EA fetches the details of the corresponding ITS-S using the identifier present in the request and then performs validation based on the currently active EC. The Itss_withprivacy standard which applies to most ITS Stations ensures that the identity of the ITS-S is only revealed to EA.

    ITS Station (ITS-S)

    ITS-S is configured by manufacturers with Root CA, Enrollment Authority (EA), and Authorization Authority (AA) certificates and the URLs to send enrollment and authorization requests. ITS Stations have a globally unique canonical identifier and canonical key pair. The public key is provided to Enrollment Authority (EA) during the registration process.

    C-ITS Certificate Structure

    C-ITS certificates are OER (Octet Encoding Rules) encoded and only support ECC (Elliptic Curve Cryptography) keys of specific curves. C-ITS certificate attributes are similar to certificate formats such as X.509 certificates but the data model and encoding procedure differ.

    IEEE 1609.2 supports two types of certificates, explicit and implicit certificates. EJBCA supports explicit certificates following EU ETSI standards that the Root CA, EA, AA, and EC certificates must be explicit certificates. ETSI also disables the usage of certain certificate fields defined by IEEE 1609.2, for example, cracaId, crlSeries, etc.
    The following lists relevant certificate fields. For details, refer to IEEE 1609.2 (section 6.4) and ETSI 103 097 (section 6).

    Field

    Description

    Validity Period

    Period during which the certificate is valid (defined in IEEE 1609.2). EJBCA allows the validityPeriod to be specified as a string, for example, "2y 4sh 6h" meaning "2 years 4 sixty-hours and 6hours", thus 2 years and 246 hours. Note that the minimum granularity of certificates is expressed in hours for enrollment credentials (EC) and during authorization validation.

    Certificate Id

    The Identifier chosen by the ITS-S. It should be unique for RCA, EA, and AA. EJBCA uses the ID requested by the ITS-S for EC enrollment.

    Issuer Identifier

    The hashedId8 of the signing certificate. In the case of EC, this is hashedId8 of EA. The hashedId8 is calculated by encoding a certificate as per IEEE 1609.2 section 6.4.3 and then taking the last eight bytes of a SHA256 hash.

    Application Permissions

    Like the key usage field in X.509 certificates, appPermissions defines the intended use of the certificate. ETSI, IEEE, and CPOC describe pre-defined values for this depending on certificate use. For example, an ITS-S enrollment credential will have different appPermissions than an EU-level Root CA.

    Certificate Issuing Permissions

    Similar to appPermissions, Certificate Issuing Permissions restricts what kind of certificate a CA can issue. For example, an EA can only issue enrollment credentials (EC) but not Authorization Tickets (AT).

    Both appPermission and certIssuePermissions are associated with SSPs, Service Specific Permissions. EJBCA does not specify SSPs appPermissions in EA and accepts the SSP requested by ITS-S on an allowed Application Object Identifier (AID). It specifies default SSP values in table 6 of the C-ITS Point of Contact (CPOC) Protocol release 1.2 in certIssuePermissions in EA signed certificate request.

    Public Keys

    C-ITS certificates can have an encryption key (mandatory for EA and AA certificates) and a verification key (mandatory for all certificates).

    C-ITS Specific Attributes


    Geographic Region

    Indicates in which region the certificate is valid. EJBCA supports circular, rectangular, identified European regions.

    Assurance Level

    Indicates the security level of the end entity or ITS-S. Optionally specified during the registration of ITS-S.

    Limitations

    The EJBCA implementation of C-ITS is limited to Enrollment Certification Authority (ECA) operations and issuance of enrollment credentials (EC). The following lists limitations in the current implementation.

    • There is no support for integration or upload of ECTL (European Certificate Trust List) and TLM (Trust List Manager).

    • The ECA keys can currently only be stored in a soft crypto token. HSM support will be added in future releases.

    • Identified geographic regions like country and region in countries are not compatible for validation against geometric regions like circular and rectangular. The only exception is the whole Europe region which considers everything as sub-region. Polygonal geographic region is not supported.

    • Authorization management with Butterfly Keys is not yet supported.

    • Attributes in Enrollment Certificate or EC credentials are not designated as critical. CA certificates are not validated against critical constraints.

    References

    Security standards and publications related to V2X and C-ITS communications.

    US IEEE Standard

    • IEEE 1609.2

    EU ETSI Standards

    • ETSI TS 102 940

    • ETSI TS 102 941

    • ETSI TS 103 097

    • ETSI TS 103 601

    To search for and download standards, refer to etsi.org

    C-ITS Point of Contact (CPOC)

    The C-ITS Point of Contact (CPOC), established by the European Commission to support the deployment of C-ITS services within the European Union C-ITS Security Credential Management System, publishes the following:

    • Trust List Manager (TLM) Certificates

    • European Certificate Trust Lists (ECTL)

    • C-ITS relevant documentation, such as Certificate & Security Policy, CPOC protocol, etc.

    For more information, refer to the C-ITS Point of Contact website.