# Hybrid Key Exchange and Signature Design for Quantum-safe C-ITS

Brigitte Lonc, Farah-Emma Braiteh, Francesca Bassi

► To cite this version:

Brigitte Lonc, Farah-Emma Braiteh, Francesca Bassi. Hybrid Key Exchange and Signature Design for Quantum-safe C-ITS. IEEE/IFIP Workshop on Secure and Resilient Communication for Drones and Autonomous Vehicle Networks (SRC-DAV 2025), Jun 2025, Paris, France. hal-05074844

HAL Id: hal-05074844

https://hal.science/hal-05074844v1

Submitted on 20 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Hybrid Key Exchange and Signature Design for
Quantum-safe C-ITS

Brigitte LONC

B. Lonc Consulting / IRT SystemX

brigitte.lonc@ext.irt-systemx.fr

Farah-Emma Braiteh

Renault Group / IRT SystemX

farah-emma.braiteh@ampere.cars

Francesca Bassi

IRT SystemX

francesca.bassi@irt-systemx.fr

*Abstract*—Secure vehicular communication systems are critical for enabling technologies like Cooperative Intelligent Transportation Systems (C-ITS), which support the development of Connected Autonomous Vehicles. These critical communications rely on secure protocols that use public-key cryptographic algorithms for digital signatures and encryption within a public-key infrastructure (PKI). However, the emergence of large-scale, fault-tolerant quantum computers poses a significant security threat, as it will eventually compromise current asymmetric cryptographic schemes.

In response to this challenge, our previous research [1] analyzed the performance of Post-Quantum Cryptography (PQC) algorithms under standardization and provided guidance for replacing vulnerable cryptographic schemes. This paper builds on those findings by introducing hybridization solutions to facilitate the transition of C-ITS to quantum-safe cryptography. Specifically, we present the design and specification of a hybrid PKI integrating different certificate types, including partial hybrid certificates for end-entities and full hybrid certificates for PKI authorities. Furthermore, we propose a novel hybrid key establishment scheme that combines Elliptic Curve Integrated Encryption Scheme (ECIES) with Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), ensuring security even if one scheme fails.

*Index Terms*—Cooperative ITS, Hybrid certificate, Hybrid key exchange, PKI, Quantum-safe cryptography.

# I. INTRODUCTION

Cooperative Intelligent Transportation Systems (C-ITS) communication allows the exchange of information and co-operation between the vehicles and their surroundings. This encompasses localized radio communications between vehicles (V2V), with the road-infrastructure (V2I/I2V), and with other road users. C-ITS applications improve road safety and traffic efficiency, and promote green and sustainable transport enabling new mobility types and multi-modality. This serves as a key technology for the development of connected, cooperative and automated mobility (CCAM).

Data transmitted between road actors are used for safety applications and require secured and trusted communications. Ensuring data integrity and source authenticity is particularly critical in this context.

To secure C-ITS communications, IEEE and ETSI have developed a security architecture and protocols [2] [3] that provide authentication, authorization, and confidentiality. The IEEE and ETSI standards are developed in close cooperation and use both public-key digital signature (Elliptic Curve Digital Signature (ECDSA)) and asymmetric encryption (ECIES)

for shared key establishment and encryption of messages. They rely on the deployment and operation of a Public Key Infrastructure (PKI) for the distribution of signature or encryption public-key certificates to Certificate Authorities and to trusted end-entities, called C-ITS stations (C-ITS-S).

Details on the European C-ITS PKI and security services for V2V/ V2I communications are given in [4], [5]. The PKI provides two types of certificates to end-entities: the long-term certificate, called Enrolment Certificate (EC) which is used for authentication and the short-term certificates, called Authorization Tickets (ATs) which are pseudonym certificates without any identification information. ATs are used by C-ITS-S to sign safety messages such as Cooperative Awareness Messages (CAM), or to encrypt messages (e.g. certificate requests). Identity and privacy protection is ensured through the use of pseudonym certificates and pseudonym change strategies.

The long-term security of these cryptographic mechanisms is challenged by emerging technological developments. Quantum Computers (QC) are constantly progressing and pose important threats to the cryptographic algorithms deployed today [6], [7]. When large-scale, fault-tolerant quantum computers, called Cryptographically-Relevant QC (CRQC) will become available, they will be able to break all classical public-key cryptographic schemes, using Shor's quantum algorithm [8]. Even if CRQC are yet years to come, the migration to quantum-safe cryptography should be considered as soon as possible in vehicular communications as the life-time of the equipment in the vehicle and the road infrastructure may be very long, often exceeding 15 or 20 years, thus the migration will take a long time.

To mitigate the quantum threats, a strong involvement of cryptography research and industrial communities has allowed to develop new post-quantum cryptographic algorithms, among which a few proposals have reached sufficient performance and security to be selected for standardization [9]. However, the drop-in replacement of asymmetric cryptographic algorithms raises many challenges for vehicular communications due to larger sizes of PQC public-keys, signatures and ciphertexts. Especially, their integration in C-ITS standards and protocols cannot be transparent due to the specific requirements of embedded devices: limited radio bandwidth, transmission latency constraints, small storage capacity and limited secure memory, implementation complexity.
In our previous research [1], we presented a feasibility study and performance benchmark of PQC algorithms, defined the critical performance requirements which should be fulfilled for the drop-in replacement of crypto-algorithms in C-ITS secured communications, and selected suitable candidates for migration. Based on this, we proposed hybrid solutions for signature and Key Encapsulation Mechanisms (KEMs): a hybrid ECDSA/Falcon approach is selected for signature as the best fit solution and ECIES/KYBER is chosen for key exchange.

Following up on this analysis, our contributions in this work are the following:

* We present a brief risk assessment and perform the inventory of crypto-assets, focusing on cryptographic algorithms relevant to C-ITS impacted by QC.

* We specify a new hybrid key establishment scheme allowing to combine the classical ECIES scheme and the ML-KEM (FIPS 203) [10] standard ensuring high security of the combined scheme.

* We propose the design and specification of hybrid C-ITS certificates, including the format of partial hybrid certificates for end-entities and full hybrid certificates for Certificate Authorities (CAs).

## II. RELATED WORKS

In 2016, NIST started a PQC standardization process to discover, analyze and standardize new cryptographic algorithms which are resilient to attacks by both classical and quantum computers. The NIST PQC project includes both quantum-resistant KEM and digital signature algorithms. In July 2022, after three rounds of evaluation, a first set of candidates was selected for standardization and a 4th round evaluation phase was started to select additional KEMs. Recently, NIST announced the publication of the first approved FIPS standards based on the submitted PQC algorithms (FIPS 203, FIPS 204 and FIPS 205) which are based on submitted candidates CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+, respectively. The draft standard based on FALCON (FIPS 206) has been delayed and is expected to be released in 2025. A new call for additional signatures was initiated to provide standards based on lattice or on other hard mathematical problems.

During the transition phase to PQC, some uncertainty is to be expected regarding the robustness of both existing traditional and new quantum-safe cryptographic algorithms. We cannot be fully confident in PQC replacements because they have not undergone extensive scrutiny and real-world testing to discover potential security vulnerabilities or implementation flaws. For a smoothly transition from current to post-quantum algorithms, many governments and security agencies advocate to use hybrid solutions where both a classical and a post-quantum (PQ) algorithm are combined together [7], [11], [12].

Several papers on KEMs hybridization have been published which proposes different key combiner modes, such as concatenation, XOR, XOR then MAC, dual-PRF or nested dual-PRF, concatenate then KDF or cascade [13], [14], [15]. Some of the previous solutions are not recommended due to their

insufficient security (e.g. keys concatenation or XOR [14]). For hybrid KEM schemes, we need to ensure that the hybrid KEM preserves the security of its component KEMs, meaning that composition is secure as long as one of the KEM remains secure. However, the security property of a combined KEM scheme is not straightforward [14] and validated security proofs are needed. Currently, most of the proposed hybrid KEMs are not assessed to provide INDistinguishability under Chosen-Ciphertext Attacks (IND-CCA) security but only a weaker security property is formally proven [12].

ETSI TS 103 744 [15] specifies two generic constructions allowing to perform a quantum-safe hybrid key exchange which can be used in various application protocols such as those defined for C-ITS applications: the concatenate hybrid key establishment (CatKDF) and the cascade hybrid key establishment (CasKDF). However, the combiner methods specified in TS 103 744 are not authenticated. A few papers are proposing hybrid authenticated key exchange methods, but they do not consider ECIES scheme in their specifications.

For hybrid signatures, there are less diversified solutions for the combination of a traditional signature with a quantum signature. In [16], the authors introduce several combiners: concatenation, weakly nested and strongly nested signatures. Especially the hybrid signatures based on concatenation and strong nesting are preserving the unforgeability under chosen message attack (EUF-CMA) security of the hybrid scheme. For the migration to quantum-safe PKIs, different types of solution have been proposed for the transition of X.509 PKI to a hybrid PKI able to handle both traditional and PQC keys (e.g. dual PKI, catalyst, chameleon or composite certificates). But the problem of specifying hybrid certificates for C-ITS stations which rely on the IEEE 1609.2 certificate structure has not received so much attention.

In [17], N. Bindel et al. address the design of practical hybrid signature schemes for V2V short-range communications (ECDSA – PQ hybrid design) focusing on the BSM (Basic Safety Messages) standard used in US. The authors introduce the “pure PQ V2V design” that consists of sending the PQ certificate in several fragments before being able to verify the received BSMs, but this solution seems inappropriate as it introduces complexity and delay in the reception of signed BSMs. They propose three alternative designs for hybrid ECDSA and PQ schemes: the “True Hybrid” using the concatenation of ECDSA and PQ signatures and certificates, the “Backwards-compatible Hybrid” using also two signatures with optional verification of the PQ signature by the receiver and the “Partially PQ Hybrid” where BSMs are signed using ECDSA and the integrity of the ECDSA signature keys is guaranteed by both ECDSA and PQ signatures.

In [18], the authors propose a hybrid certificate format for C-ITS based on the X.509 hybrid certificate design which introduces non-critical extension fields containing an additional public-key and a Certificate Authority (CA) signature for the selected PQC signature algorithm. However, this solution does not comply with the specific V2V protocol constraints such as the maximum frame size and periodicity (the fragmentation of
messages in multiple packets is currently not supported in C-ITS standards).

### III. QUANTUM THREATS TO VEHICULAR COMMUNICATIONS AND MITIGATION

Quantum threats on C-ITS security standards should not be neglected: the cryptographic mechanisms used in ETSI standards are not quantum safe and if a large-scale QC could be built, this would completely disrupt the C-ITS trust model. Although, from the experts' opinion, the quantum threat timeline is still far away, with an increasing likelihood in between 15 years and 20 years [6], the risk of a CRQC breaking asymmetric cryptography is considered high in C-ITS, because the impact is critical. If the signature of safety messages can be forged, the messages integrity and authenticity cannot be guaranteed anymore. Moreover, the CAs could be impacted by a QC attack and the attacker could get certificates from the CAs posing as a legitimate C-ITS-S. This is also impacting the certificate and trust lists distribution, such as the ECTL (European Certificate Trust List) and CRL (Certificate Revocation List) on which the C-ITS trust model relies.

Table I shows the impact of QC on the current cryptographic algorithms specified in the C-ITS security standards. Different examples of use cases are given, taking into account both the C-ITS secure communications and the PKI management protocols.

<table><caption>TABLE I: Quantum Threats to Cryptographic Algorithms Used in C-ITS</caption><thead><tr><th>Type</th><th>Name</th><th>Function</th><th>Use cases</th><th>QC Risk Assessment</th></tr></thead><tbody><tr><td rowspan="3">Symmetric Cryptographic Algorithms</td><td>AES-128</td><td>Encryption</td><td>Encrypted V2X messages, for future, emerging C-ITS applications such as CACC, Platooning</td><td>Remains secure, no need to be updated.</td></tr><tr><td>SHA-256</td><td>Hash</td><td>Signed V2X messages</td><td>Remains secure</td></tr><tr><td>HMAC-SHA-256</td><td>MAC</td><td>Secure certificate request (AT)</td><td>Remains secure</td></tr><tr><td rowspan="3">Asymmetric Cryptographic Algorithms</td><td>ECDSA</td><td>Signature</td><td>Signed V2X messages, Secure certificate requests (EC. AT), Signed trust information list, e.g. Certificate Trust List/Revocation List</td><td>No longer secure</td></tr><tr><td>ECIES</td><td>Encryption/ authenticated key agreement</td><td>Encrypted V2X messages, secure certificate request (AT reloading, EC rekeying)</td><td>No longer secure</td></tr><tr><td>ECDH</td><td>Key agreement</td><td>IPsec, TLS, AMQP protocols for Cloud/Edge communication with servers</td><td>No longer secure</td></tr></tbody></table>

As shown in recent publications [19], [20], the impact of QC attacks on symmetric cryptography is not so critical as it was understood before. AES-128 still meets the requirements of Category 1 security, as specified by NIST for PQC standardization process [21]. No change of algorithms and key sizes is expected at the moment for symmetric encryption (AES-128), hash function (SHA-256) and the authentication using a keyed hash MAC based on this hash (HMAC-SHA-256). The security of current public key cryptography algorithms integrated in the secure protocols listed in Table 1 are based on “classical” hard problems assumptions. In 1994, Peter Shor presented an effective method to solve the integer factorization and discrete logarithm problems in polynomial time on a quantum computer [8]. Thus, a CRQC will be able to break cryptographic algorithms, such as ECDSA, Elliptic curve Diffie-Hellman (ECDH) and ECIES and a transition to PQC is required.

### IV. QUANTUM-SAFE HYBRID KEY EXCHANGE APPROACH

#### A. ECIES Scheme and Use Cases

The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public-key authenticated encryption scheme composed by the following cryptographic components: a Key Agreement (KA) protocol based on Diffie-Hellman with cofactor multiplication (DHC), a Key Derivation Function (KDF), a symmetric encryption function (ENC), a Message Authentication Code (MAC) and a hash function used within the KDF and the MAC [22].

ECIES provides ciphertexts and keys of small sizes compared to other public key schemes as RSA; moreover, it is computationally efficient since it requires only one scalar multiplication to derive the shared secrets [22]. Assuming that the Initiator already knows the public key of the Responder, the ECIES only requires a single message to perform the key exchange, which means it only needs a 0.5 round-trip time (RTT). For these reasons, it has been chosen as a fundamental component in the security services of C-ITS. The ECIES scheme is used in C-ITS for the data encryption service which allows transmission of confidential data between C-ITS stations. It is also used for PKI management protocols in the C-ITS trust domain. The specification ETSI TS 102 941, based on the IEEE 1609.2 standard, defines the protocols in the C-ITS trust domain for the PKI certificate management. In the following, we will consider as a working example the case of provision of Enrolment Certificates (EC) and of pseudonym certificates (ATs) to the C-ITS-S, as specified by ETSI TS 102 941. In this case, a single message from the C-ITS-S allows to send the secured AT request to the PKI.

Figure 1 illustrates how ECIES is used for this case. The Initiator (Alice) represents the C-ITS-S sending an AT request to the PKI (Bob). The symmetric key $A$ is used to encrypt the message $m$ (on the right) using AES-128-CCM. ECIES (on the left) is used by Alice to encrypt the symmetric key $A$ so that it can be securely shared with Bob, and the resulting message $M_{A→B}$ from Alice to Bob consists of the concatenation of the
<figure><img src="image_2.png" /><figcaption>Fig. 1: ECIES Asymmetric Encryption Combined with AES-128-CCM Symmetric Encryption for the confidential message exchange as defined in IEEE 1609.2</figcaption></figure>

information needed to recover the symmetric key (in the green box), the symmetric encryption parameters, and the encrypted message *C*. The yellow box in Figure 1 details the Key Agreement, based on Diffie Hellman with Cofactor (DHC) and the Key Derivation Function (KDF2). In this case, Bob (the PKI) has an encryption public key $pk_B$ in its certificate, which is known at the beginning of the exchange and trusted by Alice (the C-ITS-S). Alice's private key $sk_A$ is ephemeral.

The IEEE 1609.2 standard is based on IEEE 1363a [23] ECIES scheme and specifies the choice of elliptic curves for the public-keys generation, the cryptographic primitives and the parameters set used in the protocol.

## B. Comparison of ECIES and Quantum-Safe KEM

ECIES provides IND-CCA security as long as the DH problem on elliptic curve remains intractable and the encryption and MAC primitives are secure. This was proven on DHIES which is a more generic scheme than ECIES in the paper from M. Abdalla et al. [24].

A quantum safe alternative to ECIES may be obtained using a quantum safe KEM as a replacement. A KEM is a cryptographic primitive consisting of the following elements:

* **KeyGen**: A probabilistic key generation algorithm which generates a private and public keypair ($sk, pk$).

* **Encaps($pk$)**: A probabilistic encapsulation algorithm, which takes as input a public key $pk$ and returns a ciphertext $c$ and a shared secret key $K$, or an error value.

* **Decaps($sk, c$)**: A decapsulation algorithm which takes as input a private key $sk$ and ciphertext $c$ and returns a shared secret $K$ or an error value.

Module Lattice based KEMs (ML-KEM) are quantum safe alternatives satisfying the security properties guaranteed by ECIES. ML-KEM based on CRYSTALS-Kyber (FIPS 203) is proven to be IND-CCA2 secure. FIPS 203 specifies several variants, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, which correspond respectively to NIST security levels 1, 3 and 5.

However, as discussed in the Introduction, there is the need of solutions to ensure security during the migration phase towards quantum-safe technology. In the following section we propose hybrid scheme as a replacement for ECIES for the considered use case, to be used in the migration phase.

## C. Hybrid ECIES/ML-KEM Key Exchange

Our proposed solution is based on KEM combiners [13], and follows the recommendations of BSI [11] for the design of a hybrid key exchange scheme. KEM combining provides a scheme that remains secure as long as at least one of the
<figure><img src="image_3.png" /><figcaption>Fig. 2: Hybrid Key Exchange using a KEM Combiner</figcaption></figure>

component KEMs is secure. This design also allows for the
use of a pre-shared key (PSK) as part of the hybridization.

Figure 2 illustrates how we propose to use the combiner
scheme to functionnally replace the corresponding portion of
the scheme in Figure 1. In the KEM combiner, $K_E$ represents
the shared secret resulting from DHC, as performed in ECIES;
and $K_{PQ}$ represents the shared secret obtained by the ML-
KEM scheme.

ETSI has published the standard TS 103 744 ( [15]) which
specifies two generic combining schemes:

* the concatenate hybrid key establishment mode (CatKDF) which defines a parallel combination method to derive the cryptographic shared key(s) from the shared secrets of the basic components

* the cascade hybrid key establishment mode (CasKDF) which allows to derive key(s) using a serial combination method of the components' encryption keys.

In our solution we consider a combiner function based on
the CatKDF scheme to combine the two components (ML-
KEM/DHC) shared secrets into a single shared secret $K$ using
a KDF function which can be a Hashed-KDF (HKDF) or a
KMAC function as specified in NIST SP800-185. We propose
to take HKDF which consists to apply an extract then expand
function [25]. It allows to generate a secure key of 384 bits
length, which are split in two keys ($K_{MAC}$ and $K_{ENC}$) used
in the last step of the ECIES scheme. Alternatively, KDF2
specified in IEEE 1363a [23] may be used as KDF in our
hybrid method as the C-ITS-Ss already implement it.

The proposed scheme assumes, as before, that the Initiator
(Alice) knows the static public keys of the Responder (Bob).
This means, this time, that Alice has received the classical and
PQC encryption public keys in Bob's certificate beforehand.
This one is assumed to be issued by a CA trusted by Alice and
Bob. This is compatible with the PKI protocols established in
ETSI TS 102 941. More generic encryption use cases using

this hybrid ECIES/ML-KEM key exchange could also use the
ephemeral-ephemeral keys solution presented in [15].

Fig. 3 shows the flow diagram of the hybrid key exchange (H-KE) solution we propose for C-ITS use cases. In this diagram, ($sk_E, pk_E$) denote the recipients' private and public keys for ECIES scheme, ($sk_{PQ}, pk_{PQ}$) denotes the recipient's private and public keys for ML-KEM scheme. Alice generates an ephemeral elliptic curve keypair ($sk_A, pk_A$), and uses $sk_A$ along with Bob's $pk_B$ to produce the first shared secret $K_E$. Alice generates the second secret $K_{PQ}$, using the ML-KEM encapsulate function with input public key $pk_{PQ}$, thus obtaining the encrypted secret $C_{PQ}$. Finally, the message $M_{A \to B} = (pk_A, C_{PQ})$ is sent by Alice to Bob. Bob is then able to recover both $K_E$ and $K_{PQ}$.

Compared to the cascade mode, which would require two
or more round-trips, the concatenate mode is better satisfying
C-ITS requirements, as it enables to perform the key exchange
in one round; moreover, it could enable the reuse part of
the implementation code such as the X9.63-KDF2 function
which is already implemented in C-ITS end-entities and in
PKI entities.

## D. Security discussions

This section discusses the security properties of the hybrid
ECIES-ML-KEM key exchange protocol.

Confidentiality of the message *c*: The shared secret key *K* is based on two shared secrets $K_E$ and $K_{PQ}$, which can be shared with Bob thanks to his public keys $pk_E$ and $pk_{PQ}$. As Bob's public keys ($pk_E, pk_{PQ}$) are static and contained in a certificate issued by the CA, Alice has the assurance that they are trusted and that the corresponding private keys are owned by Bob, thus ensuring that only Alice and Bob have access to $K_E$ and $K_{PQ}$. This ensures that only Alice and Bob have access to $K_{MAC}$ and $K_{ENC}$ derived in the key derivation process (see Fig.1) and the encrypted data *c* can only be decrypted by Bob.

Data authenticity and integrity: As for ECIES, the encrypted
data are authenticated and integrity protected using the MAC
tag (Fig.1). Only Alice can be the sender of the encrypted data,
as the calculated MAC tag using the $K_{MAC}$ must be identical
for both communicating entities.

Identity authentication: The H-KE protocol specified in Fig. 3 is not vulnerable to a Man-in-The-Middte attack. As Bob uses a static public key contained in a certificate, an attacker cannot replace Bob's public key by its own one, posing as Bob. When verifying the certificate validity, Alice will detect that the public key is invalid. However, in this ephemeral-static mode, Alice cannot be authenticated by Bob. In our example of the certificate secure request protocol, the message MA containing the request must be signed using the private key corresponding to the valid EC certificate of the requesting C-ITS-S.

Indistinguishability under chosen plaintext or ciphertext
attacks: The objective of the CatKDF combiner is that even
if one of the component schemes turns out to be insecure,
but not all of them, the combined scheme remains secure.
<table><caption>Fig. 3: Hybrid Key Exchange (H-KE) Scheme</caption><thead><tr><th>Initiator (Alice)</th><th></th><th>Responder (Bob)</th></tr></thead><tbody><tr><td>Obtain recipient's authentic public keys (pk<sub>E</sub>, pk<sub>PQ</sub>)</td><td></td><td>Recipient key pairs for each of the component scheme (ECIES, ML-KEM) (sk<sub>E</sub>, pk<sub>E</sub>) and (sk<sub>PQ</sub>, pk<sub>PQ</sub>)</td></tr><tr><td>Generate sender's ephemeral elliptic curve private/public keys (sk<sub>A</sub>, pk<sub>A</sub>) = ECKeyGen()</td><td></td><td></td></tr><tr><td>Create the shared secret key K<sub>E</sub> using Diffie-Hellman with cofactor (DHC): K<sub>E</sub> = KA (sk<sub>A</sub>, pk<sub>E</sub>)</td><td></td><td></td></tr><tr><td>(K<sub>PQ</sub>, C<sub>PQ</sub>) or ⊥ = Encaps(pk<sub>PQ</sub>)</td><td></td><td></td></tr><tr><td>Prepare a MA message encoded as an octet string, to be sent to Responder MA = (pk<sub>A</sub>, C<sub>PQ</sub>)</td><td>MA</td><td>Retrieve the shared secret key K<sub>E</sub> using Diffie-Hellman with cofactor (DHC): K<sub>E</sub> = KA (sk<sub>E</sub>, pk<sub>A</sub>) and ML-KEM Decaps: K<sub>PQ</sub> or ⊥ = Decaps (sk<sub>PQ</sub>, C<sub>PQ</sub>)</td></tr><tr><td>Calculate combined key material (K) using the CatKDF method:<br>K = KDF(secret, label, f_context, length)<br>where secret = K<sub>E</sub> || K<sub>PQ</sub><br>KDF is set to HDKF which derives key material as follows:<br>a. PRK = HKDF_Extract (label, secret)<br>b. K = HKDF_Expand (PRK, f_context, length)<br>label = empty string<br>f_context = transcript of exchanged message (MA)<br>length = 384 bits</td><td></td><td>Calculate combined key material (K) using the CatKDF method:<br>K = KDF(secret, label, f_context, length).<br>where secret = K<sub>E</sub> || K<sub>PQ</sub><br>KDF is set to HDKF which derives key material as follows:<br>a. PRK = HKDF_Extract (label, secret)<br>b. K = HKDF_Expand (PRK, f_context, length)<br>label = empty string<br>f_context = transcript of exchanged message (MA)<br>length = 384 bits</td></tr></tbody></table>

The proposed hybrid scheme is IND-CPA robust as it reuses the CatKDF construct [26], as long as one of the underlying KEM is IND-CPA and the KDF is secure. Moreover, as proven in [26], CatKDF is IND-CCA secure as long as one of the components is robust against one way under chosen-ciphertext attacks (OW-CCA).

## V. DESIGN AND SPECIFICATION OF A HYBRID APPROACH FOR DIGITAL SIGNATURE

Currently, C-ITS Day1 use cases focusing on driver awareness and information are largely deployed which use standardized messages such as Cooperative Awareness Messages (CAMs) and Decentralised Environmental Notification Message (DENMs). Other advanced use cases are also emerging such as Collective Perception Service (allowing the sharing of

perception sensor data collected by vehicle or the infrastructure), cooperative manoeuver or platooning.

CAMs which contain vehicle kinematic data such as position, speed and heading are periodically broadcasted by vehicles at variable frequency (1 to 10 Hertz). Based on pilot experiments, the typical size of a CAM payload ranges from 160 bytes for small CAM and 480 bytes for larger CAM with optional fields [27]. Collective Perception Messages (CPM) containing sensor information, perception regions information and detected objects are larger sized messages, up to 1200 bytes.

All C-ITS messages are broadcasted with the message signature and the signer certificate (AT) which allows surrounding receivers to check their integrity and the authenticity of the sender. In the case of CAM transmission, the complete certificate is included only once a second, and a certificate
<figure><img src="image_4.png" /><figcaption>Fig. 4: Signed message format with Certificate (AT) or Certificate Digest</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Pk: Public key, Sign: Signature</figcaption></figure>

<caption>Fig. 5: Different Types of Certificates for End-entities and CAs</caption>

digest is included otherwise (see Fig. 4).

In our previous work [1], a performance benchmark of the NIST 3rd Round PQC signature algorithms was done to evaluate their suitability for the signature “drop in” replacement in C-ITS protocols. The study focused on the critical requirements (performance, security and backward compatibility) for the short-range broadcast communications of critical-safety messages such as CAMs, DENMs and CPMs. Although Falcon-512 provides superior performance for signing and verifying operations compared to ECDSA, a full hybrid ECDSA-Falcon approach raises many challenges due to the large keys and signature sizes and a practical solution needs to be designed for applications with limited network bandwidth.

As introduced in [1], different types of certificates for end-entities (ATs) are defined as shown in Fig.5: (A) is the AT certificate with standard attributes and permissions except the key and signature, (B) is the current certificate we use with ECC, (C) is a replacement of ECDSA with the PQC signature candidate, (D) embeds both PQC and ECDSA and (E) is a lighter hybrid approach that is been called “partial PQC hybrid scheme”. Table II shows the size of the various certificate types and the size of signed messages containing a small CAM messages (160 bytes payload).

As the C-ITS station is changing frequently its AT for privacy protection, the AT signature key is only used during a short period, less than 1 hour and is only reused occasionally during its maximum validity period of 1 week. Based on this frequent change of keys, we consider that even a quantum attacker cannot forge ECDSA signatures within such short time and we select the Partial Hybrid certificate for ATs (Fig.5(E)). For the hybridization of CA certificates, the format of Full PQC hybrid certificate is required (Fig.5 (D)).

Thus, the format of the signed message does not change as it carries only one ECDSA signature. Fig.4 shows the format of a signed message containing a CAM, a DENM or a CPM

<table><caption>Fig. 6: IEEE 1609.2 Certificate Format</caption><thead><tr><td>Version</td><td>Type</td><td>Issuer ID</td><td>Certificate Header (Certificate ID, Validity Period, Region, Permissions, Public Encryption Key, Public Verification Key, etc.)</td><td>Signature</td></tr></thead><tbody></tbody></table>

payload. The signerId (SignerIdentifier) determines the keying material and the digital signature algorithm used to sign the data. It can contain either the certificate digest (HashedId8 of the certificate) or the AT certificate used by the sender to sign the message.

<table><caption>TABLE II: Certificate and Signed Message Sizes (in Bytes)</caption><thead><tr><td>Name</td><td>(B) or (C) AT Certificate</td><td>(D) AT Full Hybrid Certificate w/ Nist-P256</td><td>(E) AT Partial Hybrid Certificate w/ Nist-P256</td><td>(1) Signed message with CAM payload (AT Partial Hybrid)</td><td>(2) Signed message with CAM payload (certificate digest)</td></tr></thead><tbody><tr><td>ECDSA NIST P-256</td><td>160</td><td></td><td></td><td></td><td></td></tr><tr><td>ECDSA NIST P-384</td><td>208</td><td></td><td></td><td></td><td></td></tr><tr><td>ECDSA NIST P-521</td><td>262</td><td></td><td></td><td></td><td></td></tr><tr><td>Falcon-512</td><td>1 651</td><td>1 747</td><td>850</td><td>1 074</td><td>232</td></tr><tr><td>Falcon-1024</td><td>3 187</td><td>3 283</td><td>1 490</td><td>1 714</td><td>232</td></tr></tbody></table>

Due to the large size of PQC signature in the partial hybrid certificate used by C-ITS station, we consider that the addition of certificate in the signed messages shall not be used as in the current protocols. Consequently, the signer certificate (AT) should either be transmitted every second in an additional beacon message, i.e. a small CAM containing only mandatory fields or sent as a response to a Peer-to-Peer certificate distribution request.

The general description of a public-key certificate is given in IEEE 1609.2 and used as a basis in ETSI TS 103 097. Only explicit certificate types are used in the European C-ITS deployment and this specification only focus on the definition of explicit certificates. The structure of an explicit certificate is shown in Fig. 6. The issuer component identifies the issuer of the certificate and the signature component shall always be present and contain the ECDSA signature calculated by the signer identified by the issuer component. The certificate attributes are contained in the *toBeSigned* component of the certificate which is specified in the ASN.1 data type *ToBeSignedCertificate*.

In this work, we specify a hybrid certificate format as shown in Fig. 7: the ASN.1 structure is extended after the extension
```
ToBeSignedCertificate ::= SEQUENCE {
    id                 CertificateId,
    cracaId            HashedId3,
    crlSeries          CrlSeries,
    validityPeriod      ValidityPeriod,
    region             GeographicRegion OPTIONAL,
    assuranceLevel      SubjectAssurance OPTIONAL,
    appPermissions      SequenceOfPsidSsp OPTIONAL,
    certIssuePermissions SequenceOfPsidGroupPermissions
OPTIONAL,
    certRequestPermissions SequenceOfPsidGroupPermissions
OPTIONAL,
    canRequestRollover  NULL OPTIONAL,
    encryptionKey      PublicEncryptionKey OPTIONAL,
    verifyKeyIndicator  VerificationKeyIndicator,
    ...
    flags BIT STRING {usesCubk (0)} (SIZE (8))
OPTIONAL,
    appExtensions SequenceOfAppExtensions,
    certIssueExtensions SequenceOfCertIssueExtensions,
    certRequestExtension
SequenceOfCertRequestExtensions,
    altVerificationKey PublicVerificationKey OPTIONAL,
    altSignatureValue Signature OPTIONAL
}
(WITH COMPONENTS {..., appPermissions PRESENT}|
WITH COMPONENTS {..., certIssuePermissions PRESENT}|
WITH COMPONENTS {..., certRequestPermissions PRESENT})
```

<caption>Fig. 7: Specifications of Hybrid Certificate Format</caption>

mark to include the extension fields similar to the X.509 non-critical extension fields used for X.509 hybrid certificates. Two extension attributes in the *ToBeSignedCertificate* are specified for this purpose: the alternative verification key of type *PubicVerificationKey* which may contain the Falcon512 public-key and the alternative signature value of type *Signature* which may contain the Falcon512 signature. Using this extended certificate format, the Partial Hybrid certificate must contain the extension *altSignatureValue*, while the Full Hybrid certificate for CAs must include both extensions (*altVerificationKey* and *altSignatureValue*). The IEEE 1609.2 and ETSI TS 103 097 standards support multiple cryptographic algorithms for the signature and the ASN.1 data type (*Signature*) is extensible to support more. So, this hybridization solution is backward compatible, as the legacy systems which do not support Falcon-512 will just ignore the alternative key and alternative signature value, if present in the certificates.

## VI. CONCLUSION

As shown in recent studies [19], Grover quantum algorithm (which is proven to be optimal) is not providing any quantum advantage to break symmetric cryptography. So, using AES with 128 bits key as well as SHA-256 is sufficiently secure for the migration to post-quantum era. But the main challenge is the replacement of asymmetric crypto-algorithms used in vehicular communications such as V2V/V2I which are not quantum-safe.

As recommended by NIST [21] and other governmental agencies, migration to PQC should be ready by 2035 and the transition using hybridization solutions should be started

as soon as the new PQC standards are available. For KEM, the ML-KEM standard based on Kyber was published in July 2024 but Falcon is still delayed. However, Lattice Based cryptography is a mature technology and it is very likely that the standard will leverage on recent research results or on new Lattice-based signature algorithms submitted to NIST (e.g. HAWK) to reach increased performance and solve current short-comings of Falcon [28].

Unfortunately, the updating of C-ITS base standards and the certification of vehicle on-board units or road-side equipment with their secure components (HSM), based on certified protection profiles are required. Thus, the full transition will be very long for such embedded systems and it needs to be anticipated. A clear migration road-map is needed but still not agreed upon by the whole ecosystem.

In this paper, we attempt to close the gap of missing hybridization solution for the replacement of the key encryption scheme based on ECIES in C-ITS, which has not been addressed until now, and propose a candidate design for the hybrid ECIES/ML-KEM key exchange. To enable the transition to a realistic hybrid signature solution for C-ITS, an upgraded certificate specification is proposed, using the concept of “Partial Hybrid” certificate for end-entities and of “Full PQC Hybrid” for CAs.

## ACKNOWLEDGMENTS

This work has been supported by the French government under the “France 2030” program, as part of the Cybersecurity for Trusted Mobility (CTM) project at the SystemX Technological Research Institute.

## REFERENCES

[1] B. Lonc, A. Aubry, H. Bakhti, M. Christofi, and H. A. Mehrez, “Feasibility and benchmarking of post-quantum cryptography in the cooperative its ecosystem,” in *IEEE Vehicular Networking Conference (VNC)*, Istanbul, Turkey, Apr 2023, (hal-04050027).

[2] IEEE Std 1609.2TM-2022, “IEEE Standard for Wireless Access in Vehicular Environments – Security Services for Applications and Management Messages,” 2022.

[3] ETSI TS 103 097, “Intelligent Transport Systems (ITS); Security; Security Header and Certificate Formats.”

[4] B. Lonc, F. Haidar, and D. Filatov, “Cooperative its security standards: Implementation, assessment and next challenges,” in *ITS European Congress*, Lisbonne (virtual), Portugal, Nov 2020.

[5] H. Bakhti, B. Lonc, and A. Kaiser, “Innovative c-its security services implementation and validation by simulation and open-road live trials,” in *ITS European Congress*, Toulouse, Nov 2022.

[6] M. Mosca and M. Piani, “Quantum threat timeline report 2023,” Global Risk Institute in Financial Services (GRI), Tech. Rep., Dec 2023.

[7] ENISA, “Post-quantum-cryptography – current state and quantum mitigation - v2,” Tech. Rep., May 2021.

[8] P. W. Shor, “Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer,” *SIAM J. COMPUT.*, vol. 26, no. 5, pp. 1484–1509, 1997. [Online]. Available: https://arxiv.org/abs/quant-ph/9508027

[9] “NIST Post-quantum Cryptography Standardization,” https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms, accessed: 2025-05-16.

[10] NIST FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf, 2024.

[11] BSI, “Quantum-safe cryptography – fundamentals, current developments and recommendations,” Tech. Rep., May 2022.
[12] M. Rossi, "PQC Transition in France - ANSSI views," Real World Post-Quantum Cryptography, Mar 2023.

[13] F. Giacon, F. Heuer, and B. Poettering, "Kem combiners," in PKC 2018, 2018, pp. 190-218.

[14] N. Bindel, J. Brendel, M. Fischlin, B. Goncalves, and D. Stebila, "Hybrid key encapsulation mechanisms and authenticated key exchange," in PQCRYPTO 2019, 2019.

[15] ETSI TS 103 744 V1.2.1, "CYBER; Quantum-safe Hybrid Key Exchanges," Apr 2025.

[16] N. Bindel et al., "Transitioning to a quantum-resistant public key infrastructure," PQCrypto 2017, 2017. [Online]. Available: https://eprint.iacr.org/2017/460

[17] Bindel, N. and others, "Drive (Quantum) Safe! – Towards Post-Quantum Security for V2V Communications," https://eprint.iacr.org/2022/483, Apr 2022.

[18] T. Yoshizawa and B. Preneel, "Post-Quantum Impacts on V2X Certificates – Already at The End of The Road," in IEEE 97th Vehicular Technology Conference (VTC2023-Spring), 2023.

[19] T. Hoefler, T. Häner, and M. Troyer, "Disentangling hype from practicality: On realistically achieving quantum advantage," https://cacm.acm.org/magazines/2023/5/272276-disentangling-hype-from-practicality-on-realistically-achieving-quantum-advantage/fulltext, 2023.

[20] R. Babbush, J. McClean, M. Newman, C. Gidney, S. Boixo, and H. Neven, "Focus beyond quadratic speedups for error-corrected quantum advantage," https://arxiv.org/pdf/2011.04149.pdf, 2020.

[21] NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," Nov 2024, Initial Public Draft.

[22] V. G. Martínez, L. H. Encinas, and C. S. Ávila, "A Survey of the Elliptic Curve Integrated Encryption Scheme," Journal of Computer Science And Engineering, vol. 2, no. 2, Aug 2010.

[23] IEEE Std 1363a™-2004, "IEEE Standard Specifications for Public Key Cryptography—Amendment 1: Additional Techniques," 2004.

[24] M. Abdalla, M. Bellare, and P. Rogaway, "Dhies: An encryption scheme based on the diffie-hellman problem," https://web.cs.ucdavis.edu/rogaway/papers/dhies.pdf, Sep 2001.

[25] IETF RFC, "RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF)," 2010.

[26] A. Petcher and M. Campagna, "Security of Hybrid Key Establishment using Concatenation," IACR eprint 2023-972, Jun 2023. [Online]. Available: https://eprint.iacr.org/2023/972.pdf

[27] Car2Car Communication Consortium, "Survey on ITS-G5 CAM statistics," https://www.car-2-car.org/fileadmin/documents/General_Documents/C2CCC_TR_2052_Survey_onCAM_statistics.pdf, 2018.

[28] T. Espitau, Q. T. T. Nguyen, C. Sun, M. Tibouchi, and A. Wallet, "Antrag: Annular Ntru Trapdoor Generation," in ASIACRYPT 2023 - 29th International Conference on the Theory and Application of Cryptology and Information Security, Guangzhou (Canton), China, Dec 2023, pp. 1-56, (hal-04258578).