Method and system for providing identity credentials for direct communications using physical layer security

Abstract

METHOD AND SYSTEM FOR PROVIDING CREDENTIALS FOR DIRECT COMMUNICATION USING PHYSICAL LAYER SECURITY. A method and system for providing credentials for direct communication between a first wireless communication device and a second wireless communication device are disclosed. An exemplary method includes establishing a secret key between the first and second wireless communication devices using physical layer security in a V2X (Vehicle-to-Everything) environment. Furthermore, the method includes the use of the secret key by the first and second wireless communication devices to derive one or more keys for establishing direct communication, or using it directly as a shared key for establishing direct communication. FIGURE 2

Description

Title of the invention: Method and system for providing identity credentials for direct communications using physical layer security. FIELD OF THE INVENTION

[0001] This disclosure relates to wireless communications and, more specifically, to a method and system for making long-term credentials available for establishing direct communication between wireless communication entities in a V2X (vehicle-to-everything), D2D (device-to-device) and / or ProSe (proximity services) environment.

[0002] BACKGROUND OF THE INVENTION

[0003] Existing approaches for establishing direct communication in a V2X environment, for example vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), vehicle-to-device (V2D), and the like, require the provision of credentials to a communicating entity, for example, a user equipment (UE) or a vehicle, as a necessity. However, such provision of credentials to establish direct communication for V2X, for example between vehicles or between a vehicle and a traffic light, is still a complex procedure.

[0004] The 3GPP TS 33.536 specification, "Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services," defines the use of long-term credentials that are made available in UEs and form the security root of the PC5 unicast link, where PC5 denotes a direct link or interface between V2X UEs. In particular, the long-term credentials and the associated authentication method used to establish the keys used to protect the PC5 unicast link can either be specified in the 3GPP specifications or be a method described outside the 3GPP specifications.In the latter case, the document describes that all authentication is specified to be transported in a generic container (called Key_Est_Info) which is included in the message stream for establishing the PC5 security key between UEs during signaling, without providing any details on how to establish credentials as such.

[0005] Consequently, as the art stands, there is no solution that specifically defines how to establish these identity credentials that are made available in the UEs and form the basis of the security of the PC5 unicast link. Summary of the invention

[0006] In certain exemplary embodiments, a method is provided for making identity credentials available for direct communication between a first wireless communication device and a second wireless communication device. The method includes the steps of establishing a secret key between the first wireless communication device and the second wireless communication device using physical layer security (PLS) in a V2X (vehicle-to-everything) environment.The method further includes the use of the PLS-based secret key, by the first wireless communication device and / or the second wireless communication device, to be used as a long-term credential for deriving one or more keys to establish direct communication, or to be used directly as a shared key to establish direct communication, or to establish a secure channel for exchanging a key to establish direct communication.

[0007] In certain exemplary embodiments, direct communication is established via a direct interface between the first wireless communication device and the second wireless communication device. The direct interface, for example, may correspond to the PC5 interface in a V2X communication.

[0008] In some exemplary embodiments, the method further includes preconfiguring one or more master keys in the first wireless communication device.

[0009] In some exemplary embodiments, one or more master keys may be stored in the home network of the first wireless communication device.

[0010] In some exemplary embodiments, the method further includes establishing a secure channel between the first wireless communication device and the second wireless communication device using the PLS-based secret key.

[0011] In some exemplary embodiments, the method, after establishing the secure channel using the PLS-based secret key, further includes sending, by the first wireless communication device, a key derived from the master key(s) to the second wireless communication device using the secure channel.

[0012] In some exemplary embodiments, the derived key comprises one or more device identifiers and a session identifier. The device identifiers correspond to at least one of the identities of the first wireless communication device or the second wireless communication device.

[0013] In some exemplary embodiments, the stored master key(s) or the derived key are retrieved by a lawful interception (LI) entity, in response to a request for the shared key used for direct communication between wireless communication devices.

[0014] In some exemplary embodiments, the secret key includes at least one of a root key, a root key derived from the root key, an encryption key or an integrity key.

[0015] In some exemplary embodiments, the first wireless communication device and / or the second wireless communication device includes V2X / D2D user equipment.

[0016] In certain exemplary embodiments, a system for providing identity documents. The system includes a first wireless communication device comprising one or more processors and a storage medium communicatively coupled to said one or more processors. Said storage medium comprising one or more executable instructions. The system includes a second wireless communication device in direct communication with said first wireless communication device. The system includes at least one communication interface for establishing said direct communication between said first wireless communication device and said second wireless communication device.Furthermore, said one or more processors of said first wireless communication device, upon execution of said one or more executable instructions, are configured to establish a secret key between said first wireless communication device and said second wireless communication device using Physical Layer Security (PLS) in a V2X (vehicle-to-everything) environment. Furthermore, said one or more processors of said first wireless communication device, upon execution of said one or more executable instructions, are configured to use said secret key, through said at least one communication interface, to derive one or more keys to establish said direct communication, or to use it directly as a shared key to establish said direct communication. Brief description of the drawings

[0017] The examples in this disclosure are described herein with reference to the accompanying figures. It should be noted that the description and figures relate to exemplary implementations and should not be construed as a limitation of this disclosure. It should also be understood that various arrangements can be imagined which, although not explicitly described or shown herein, embody the principles of this disclosure. Furthermore, all statements herein referring to principles, aspects, and examples of this disclosure, as well as the specific examples, are intended to encompass their equivalents.

[0018] - Figure [1] illustrates a diagram schematically depicting a system of communication enabling implementations to be carried out, according to an embodiment of this disclosure.

[0019] - Figure 2 illustrates an exemplary process flow for establishing a secret key between UEs using the PLS, according to one embodiment of this disclosure.

[0020] - Figure 3 illustrates another exemplary process flow for establishing a secret key between UEs using the PLS, according to one embodiment of this disclosure.

[0021] - Figure 4 illustrates the storage of a master key in a home network EU, according to an embodiment of this disclosure.

[0022] - Figure 5 illustrates an exemplary process flow for lawful interception for deciphering communication between EUs, according to an embodiment of this disclosure.

[0023] - Figure 6 illustrates a flowchart for an exemplary process for the establishment of a secret key between wireless communication devices, according to an embodiment of this disclosure.

[0024] - Figure 7 illustrates a flowchart for another exemplary method for the establishment of a secret key between wireless communication devices, according to an embodiment of this disclosure.

[0025] - Figure 8 illustrates a functional diagram of a communication device without a thread that can be used to make identity documents available, according to implementations of this disclosure.

[0026] DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0027] The preferred embodiments according to this disclosure will be described in detail with reference to the accompanying drawings. The detailed descriptions provided below, together with the accompanying drawings, are intended only to explain illustrative embodiments of this disclosure, which should not be considered the only embodiments of this disclosure. The detailed descriptions below include specific information to provide a complete understanding of this disclosure. However, persons skilled in the art will be able to understand that this disclosure can be implemented without specific information.

[0028] In some cases, to avoid obscuring the technical principles of this disclosure, structures and devices well known to the public may be omitted or may be illustrated in the form of functional diagrams using the basic functions of the structures and devices.

[0029] Unless the context otherwise indicates, in the specification and the claims that follow, the word "include" and its variants, such as "comprises" and "comprising," shall be interpreted in an open and inclusive sense, that is, as "comprising, but not limited to." Furthermore, the terms "first," "second," and other similar indicators of the sequence shall be interpreted as interchangeable, unless the context clearly indicates otherwise.

[0030] As used in the description and attached claims, the singular forms "a," "an," and "the" have plural referents, unless the content clearly indicates otherwise. It should also be noted that the term "or" is generally used in its broadest sense, that is, as meaning "and / or," unless the content clearly indicates otherwise.

[0031] “And / or” for two possibilities means either one or the other or both possibilities stated possibilities ("A and / or B" covers A alone, B alone, or A and B together), and when three or more possibilities are stated, this means any individual possibility alone, all the possibilities together, or some combination of possibilities that is less than all the possibilities. The formulation "at least one of the following: A ... and N", where A through N are possibilities, means "and / or" for the stated possibilities (e.g., at least one A, at least one N, at least one A and at least one N, etc.).

[0032] Any reference to any “example” here (e.g., “for example”, “an example of”, “in an example”, etc.) shall be regarded as a non-limiting example, whether or not expressly stated.

[0033] The terms used in this specification generally have their ordinary meaning in the technique, within the context of the disclosure, and in the specific context in which each term is used. Alternative language and synonyms may be used for any or more of the terms referred to herein, and no particular emphasis should be attached to the fact that a term is elaborated or referred to herein. Synonyms for some terms are provided. The enumeration of one or more synonyms does not preclude the use of other synonyms. The use of examples anywhere in this specification, including examples of any term referred to herein, is solely illustrative and is not intended to further limit the scope and meaning of the disclosure or of any exemplified term.

[0034] In order to present a solution to the identified problem of how to establish identity credentials that are made available in UEs, this disclosure proposes to rely on Physical Layer Security (PLS), which provides an additional layer of defense on top of classic cryptographic techniques. More specifically, PLS is used to perform a provision of V2X identity verification, for example between vehicles (V2V), for services such as, but not limited to, platooning, alerts and collision avoidance; or between vehicle and traffic light (V2I) for applications such as, but not limited to, traffic monitoring and / or control, roadside planning and / or monitoring, weather updates, and the like.

[0035] PLS is a promising approach that can benefit traditional encryption methods. The idea behind PLS is to leverage the characteristics of the propagation medium and radio channel degradation to ensure secure communication. PLS is a technology intended to ensure the security of 6G; for example, PLS is mentioned in several white papers on 6G technology. For instance, Apple™ proposed to study its use within the 3GPP framework in contribution S3-213987 presented at the November 2021 SA3 meeting.

[0036] In particular, PLS technology exploits the intrinsic random properties of a wireless channel to establish a secret between two wireless communicating entities, without the need to distribute credentials beforehand (e.g., public keys or certificates). An eavesdropper in the same area cannot guess or retrieve the secret established between the two wireless communicating entities. Essentially, because the secret (e.g., the key) is derived from characteristics that are unique to the specific wireless channel and / or the associated conditions between the communicating entities, it becomes difficult and highly improbable for the eavesdropper to accurately decode the secret.

[0037] More specifically, in PLS-based systems, the legitimate sender and receiver measure the channel characteristics and then use these measurements to derive the secret key. Derivation usually involves quantization by reducing the measurements to discrete values ​​and applying a hash to create a fixed-size key from the quantized values. Therefore, the legitimate parties derive the key using a specific approach or algorithm from these measurements. However, similar measures taken by an eavesdropper to attempt to intercept the secret key would be noisy and inconsistent due to differences in channel conditions. Consequently, the data exchanged between the legitimate entities remains secure, even when an eavesdropper attempts to intercept it without the correct key. Therefore, PLS provides a robust defense against interception by unauthorized entities.

[0038] Different embodiments of the present disclosure will now be described with respect to the accompanying figures.

[0039] Figure 1 illustrates an exemplary communication system 100 (for example, a V2X system), which encompasses a network of interconnected entities, comprising Vehicles 102A-102B, Roadside Units (RSUs) 104, a pedestrian 106 with a communication device 106A, and a communication network 108. System 100 enables real-time communication and data exchange between entities to improve road safety, optimize traffic flow, enhance the overall driving experience, and similar purposes. Although the V2X System 100 is illustrated in [Fig. 1], the solution(s) in this disclosure can be extended to D2D and ProSE communication environments without departing from the scope of this description. D2D communication refers to direct communication between user devices (UDs), such as smartphones or tablets, without routing data through the core network infrastructure.Direct-to-Device (D2D) communication allows devices to communicate directly, reducing latency, improving spectral efficiency, and conserving network resources. This type of communication is particularly useful in environments where traditional network infrastructure is unavailable or insufficient. A D2D communication environment typically consists of multiple User Equipments (UEs) capable of direct communication. UEs can establish a direct communication link using a predefined communication protocol (e.g., LTE, 5G NR) over the PC5 interface. The PC5 interface enables direct communication without involving the Evolved Packet Core (EPC) or 5G Core (5GC) network, thereby reducing the load on the network infrastructure. Proximity Services (ProSe), on the other hand, are a standardized set of features that support D2D communication in LTE and 5G networks.ProSe enables nearby UEs to discover and communicate with each other using direct communication links, which can be established using sidelink interfaces, such as PC5. The ProSe framework includes mechanisms for device discovery, communication authorization, and resource allocation, ensuring secure and efficient communication between devices.

[0040] Each of the entities 102A-102B and 104 shown in [Fig. 1] is equipped with an integrated wireless communication endpoint device conforming to the V2X standard developed for cellular technology by the standards body 3GPP. Therefore, in the specific context of the V2X standard, these devices are hereafter referred to as V2X user equipment (V2X UE). Without limitation, a UE can be a telecommunications terminal with or without a security element such as a UICC, an eUICC (embedded UICC), an iUICC (integrated UICC), or a hardware-mediated execution environment (HMEE). A UICC is a smart card used in mobile devices to securely store subscriber information and support network authentication, encryption, and secure access to network services, while an eUICC is a A new generation of UICCs is soldered directly onto a device's circuit board, making them non-removable. eUICCs support Remote SIM Provisioning (RSP), enabling over-the-air (OTA) updates to manage mobile network operator (MNO) profiles and subscriptions without physically replacing the card. iUICCs represent a further advancement in SIM technology by integrating UICC functionality directly into the device's system-on-a-chip (SoC). Unlike traditional UICCs or even eUICCs, which are separate physical components, the iUICC is embedded within the silicon of the device's main chipset. Furthermore, a HMEE provides a mechanism for executing software code in a protected environment that is isolated from the rest of the system.Such environments are particularly important in scenarios involving sensitive operations, such as cryptographic calculations, secure data processing, etc.

[0041] Figure 1 shows a plurality of 102A-102B vehicles, each of which can be equipped with an on-board communication module (OCM). The OCM is a communication module integrated into the vehicle that enables direct and network-assisted communication between a vehicle and other entities within the V2X ecosystem. These modules support various communication protocols, including dedicated short-range communications (DSRC). DSRC is a wireless communication technology specifically designed for automotive environments to enable direct vehicle-to-vehicle (V2V) and vehicle-to-road infrastructure (V2I) communication. Operating in the 5.9 GHz band, DSRC supports low-latency and high-reliability communications, essential for safety-critical applications.In addition to DSRC, other communication environments supported by these modules include cellular networks and a direct communication interface such as interface 110, 112, or 114. For example, interface 110, 112, or 114 could be a PC5 interface. Specifically, interface 110 enables vehicle-to-vehicle (V2V) communication without requiring network infrastructure, allowing vehicles to directly exchange information such as their current location, speed, direction, or planned maneuvers. This direct communication is particularly useful in scenarios where low latency is critical, such as collision avoidance.

[0042] The RSU 104s represent intelligent road installations such as traffic lights (as shown in [Fig. 1]), electronic traffic signs, traffic light control devices, and the like, which are installed along the road. The RSU104s are equipped with communication circuit sets or modules that interface with the communication network 108. These communication modules are responsible for broadcasting the current traffic light status (e.g., red, yellow, green) to approaching vehicles (e.g., vehicles 102A-102B). In addition, the communication modules can receive data from neighboring vehicles 102A-102B and adjust the traffic light synchronization to optimize traffic flow based on real-time traffic conditions.

[0043] The pedestrians 106 are represented as mobile entities within the V2X system 100, each carrying a personal communication device 106A, such as a smartphone. The communication device 106A is capable of communicating with nearby vehicles (e.g., vehicles 102A-102B) and the RSU 104. The system 100 allows the pedestrians 106 to broadcast their position and intention to cross to nearby vehicles 102A-102B, enabling vehicles 102A-102B to take appropriate actions, such as slowing down or stopping to allow safe passage.

[0044] The communication network 108 serves as the backbone of the V2X system 100, providing the necessary infrastructure to facilitate data exchange between vehicles 102A-102B, traffic lights 104, and pedestrians 106. The communication network 108 may include cellular networks, DSRC, Wi-Fi, or other wireless communication technologies. Furthermore, the communication network 108 can also interface with a central traffic management system, which collects and analyzes data from all connected entities (such as vehicles 102A-102B, traffic lights 104, pedestrians 106, etc.) within the V2X system 100 to manage traffic flow and improve road safety across the entire network.

[0045] In some embodiments, the communication network 108 may correspond to a V2X server in a data network. The V2X server may host different application platforms for specific applications and thus communicate with various entities. For example, the V2X server may communicate with the respective vehicles 102A-102B through an application (e.g., the V2X application) residing there, via a specific interface such as VL. In other embodiments, the communication network 108 may comprise an embedded server or a cloud server.

[0046] Each of the vehicles 102A-102B transmits / receives information to / from the communication network 108 through respective communication channels / paths represented by 116A-116B. In addition, the RSU 104 and the pedestrian 106, via the communication device 106A, communicate with the communication network 108 through communication channels 118 and 120. respectively, using any of the wireless communication technologies.

[0047] The communication interface 110 allows different V2X entities (such as vehicles 102A-102B) to establish a direct communication channel between them. Furthermore, another communication interface 112 allows direct communication between a vehicle (e.g., vehicle 102A) and the traffic light / RSU 104. In addition, the communication interface 114 allows direct communication between a vehicle (e.g., vehicle 102B) and the communication device 106A associated with the pedestrian 106. Therefore, the V2X UEs create a unicast link between them. However, to establish direct communication between them, the V2X standard requires that security measures be taken to protect the unicast link against man-in-the-middle attacks, rebroadcasting, and to protect privacy. To address these security concerns, 3GPP specifies, in technical specification TS 33.356, corresponding to the V2X security standard, defines a "security context" for any session on such a unicast link between two V2X UEs, i.e., a set of keys organized in a "hierarchy" with, at the root, "long-term credentials." In this context, a key is an integer intended to be shared, i.e., known by the two communicating wireless devices, and to be secret, i.e., unknown to any other wireless communication device.

[0048] In this context, a long-term credential is a shared key used to authenticate one wireless communication device to another. However, the term "long-term" credential is not specified by current standards. By definition, a long-term credential is intended to be used by the wireless communication device more than once, over several sessions, as opposed to a session key generated specifically for the duration of a session and deleted at the end of the session.

[0049] This disclosure proposes to use the PLS framework and Security Knowledge Graph (SKG) to generate or share a secret key and make available long-term credentials for a given pair of V2X UEs and, more generally, for a pair of wireless communication devices.

[0050] The use of PLS ​​with SKG consists of establishing keys (integers) from the channel state (or at least one physical property of the channel). In order to perform channel estimation, each of the wireless communication devices can, for example, directly measure reference signals, synchronization signals (primary or secondary), or other pilot signals, for example DM-RS or others, normally sent on the PC5 V2X radio interface for sidelinking between the two wireless communication devices. Channel estimation can also be performed indirectly if each wireless communication device uses an interface such as the Uu radio interface (i.e., between the UE and the eNB / gNB base station) to send polling reference signals (SRS). Then, if each UE uplinks the SRS to its own eNB / gNB, the other UE can directly measure the uplink SRS Uu (and not the PC5 V2X signal drivers) and deduce a secret key even before the PC5 V2X interface is activated for the first time. Similarly, it is possible to use the DM-RS Uu or another uplink reference signal Uu. In this case, the V2X UEs do not necessarily need to transmit a radio signal on the PC5 V2X interface to derive the secret key.Furthermore, regardless of the estimation technique, for example on Uu or PC5 or on the WiFi radio interface or others, the base station (the same base station or a different base station per UE) can provide each UE with the time interval during which channel matching or estimation between two UEs / end devices must be performed. Such information can be sent securely using RRC or NAS protocol messages or be pre-configured on the devices according to a certain protocol based on the frame (system) number, subframe number, slot number, or symbol number in which the reference signals are sent.

[0051] In addition, the use of PLS ​​with secret coding (SC) consists of establishing secret codes that mitigate the information disclosed to a third party while correcting transmission errors between legitimate parties, and then transmitting secret keys confidentially using these secret codes.

[0052] Furthermore, the use of a beacon signal with an interrogation and acknowledgment sequence (IAS) makes it possible to establish acknowledgment beacon signals that remain undetectable by any third party. The beacon signal can be used as an integrity and encryption header in a secure symmetric scheme. In addition, the beacon signal can be used as an air interface encryption (AIE) to scramble secret keys when they are transmitted by radio between legitimate parties, and can also support the establishment of secret codes.

[0053] Specific embodiments describing the use of PLS ​​with the SKG framework to generate a secret key will now be described with respect to the accompanying figures.

[0054] Figure 2 illustrates an exemplary process flow for establishing a secret key between V2X entities (such as vehicles 102A-102B) using PLS, according to one embodiment of the present disclosure.

[0055] As shown in [Fig. 2], at a high level, a UE1 V2X 202 (such as vehicle 102A) uses the PLS to send a direct communication request to a UE2 V2X 204 (such as vehicle 102B). The UE2 204, after receiving the request, can choose to respond and can initiate the key establishment procedure (step 206) to generate a shared secret key based on PLS which serves as a shared secret between the communicating entities.

[0056] To generate the shared secret key based on PLS in step 206, the communicating UEs, i.e., UE1 V2X 202 and UE2 V2X 204, can first perform channel measurements. For example, channel conditions can be measured, for instance, by sending and receiving pilot signals or training sequences, in order to identify channel attributes / parameters and estimate channel state information (CSI). Then, UE1 V2X 202 and UE2 V2X 204 can exchange CSI through signaling messages, either directly or via a core network entity. By exploiting the randomness of the physical channel parameters / properties / measurements, the exchange of CSI enables the generation of a secret key. For example, the secret key can be generated using cryptographic hash functions, quantification and / or physically layer assisted key agreement (PL-AKA) authentication protocols.The generated key is used to encrypt and authenticate communication between the V2X UE1 202 and the V2X UE2 204. In a further step, the integrity of the generated key can be confirmed by additional signaling to verify that both UEs have the same key.

[0057] In step 208 of [Fig.2], the PLS-based secret key can be used as a long-term credential to derive a V2X shared key for the direct communication interface 110 (PC5), which is used to establish direct communication between the UE1 202 and the UE2 204. Advantageously, step 210 describes that the PLS-based secret key can also be used directly as a V2X shared key for the direct communication interface 110 (PC5) to establish direct communication.

[0058] In accordance with the key hierarchy defined in the 3GPP TS 33.536 specification, different key layers can be used for the PC5 unicast link facilitating direct communication between V2X UEs. These different key layers can include long-term credentials, a root key (e.g., KNRP), a session key (e.g., KXRP sess), an encryption key (e.g., the NR PC5 encryption key (NRPEK)), and an integrity key (e.g., the NR PC5 integrity key (NRPIK)). Within the context of the V2X communication described herein, long-term credentials are made available in the UEs to generate the root key, which is shared between the two entities communicating using the NR PC5 unicast link. The root key can then be used to derive a session key, which is in turn used to derive real encryption and integrity keys using privacy and integrity algorithms chosen respectively to protect PC5-S signaling, PC5 RRC signaling and PC5 user plane data.

[0059] In light of the preceding embodiments, the PLS-based secret key can be used as one of the keys in the key hierarchy mentioned above to establish direct V2X / D2D communication between UEs without the need for a complex signaling procedure. For example, the PLS-based secret key can have attributes similar to the root key in the key hierarchy to further derive one or more additional keys that are used to establish direct V2X / D2D communication over the PC5 interface / V2X layer between the UEs. As another example, the PLS-based secret key can have attributes similar to the session key in the key hierarchy that is used to secure the communication session established between the UEs for V2X / D2D communication.As another example, the PLS-based secret key may have attributes similar to those of the encryption or integrity key in the key hierarchy that are used for PC5 signaling between UEs.

[0060] In the process described in [Fig.2], it is advantageous that it is not necessary to preconfigure the communicating UEs (UE1 202 and UE2 204) with any identity credentials to establish the V2X / D2D key hierarchy for direct communication between the V2X / D2D UEs 202 and 204. Therefore, the solution proposed in [Fig.2] reduces the signaling, processing and storage requirements at the UE end.

[0061] Figure 3 illustrates another exemplary process flow for establishing a secret key between UEs using the PLS, according to one embodiment of the present disclosure. The process flow shown in Figure 3 differs from that of Figure 2 in that, in Figure 3, a master key is preconfigured as a prerequisite at step 302. The process of preconfiguring and storing the master key is explained later with reference to Figure 4.

[0062] Similar to step 206 in [Fig. 2], a shared secret key is established between UE1 202 and UE2 204 using PLS at step 304. The signaling steps for establishing the PLS-based shared secret key are similar to those described previously with reference to step 206. The PLS-based key, in an exemplary scenario established between vehicles in a vehicular network, can be derived by hashing each of the vehicle's quantized CSI vectors. Through a key agreement between the communicating vehicles, both vehicles can derive the same key value.

[0063] At step 306, the established PLS-based shared secret key is used by the communicating UEs to establish a secure communication channel between them. The secure communication channel is a result of successful contact between UEl 202 and UE2 204 via an exchange of signaling information.

[0064] Once the secure communication channel is established, at step 308, UE1 202 derives a key from the master key preconfigured at step 302 to be shared with the other UE (e.g., UE2 204). The derived key is generated using the master key and other parameters, such as random values ​​or nonces, through cryptographic algorithms. This ensures that each session or communication channel has its own unique key set, thereby enhancing security. Each derived key serves a specific purpose in the security architecture. For example, in various communication technologies, different derived keys are used to encrypt signaling and user data and to ensure data integrity.

[0065] In one embodiment, the key derivation process at step 308 may involve generating one or more session keys from the preconfigured master key. The key derivation process involves selecting an appropriate KDF for the security requirements. For example, the KDF may include HMAC, HKDF (HMAC-based key derivation function), etc. Furthermore, the key derivation process requires a master key from which the derived key(s) will be generated, input parameters (or contextual information), and optional key labels that specify the type of derived key (e.g., encryption key, integrity key, etc.). The input parameters may include device or UE identifiers (IDs) corresponding to UE1 202 or UE2 204, as well as a session ID. The device identifier can be associated with a unique identity of the UEl 202 or the UEl 204.

[0066] In one embodiment, the device identifier can be the International Mobile Subscriber Identity (IMSI). The IMSI is a unique identifier assigned to each mobile subscriber within a network. In the V2X communication network, for example, the IMSI serves as a unique identifier for vehicles or devices. Typically, the IMSI is stored on the SIM card (Subscriber Identity Module) and comprises a combination of the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Mobile Subscriber Identity Number (MSIN).

[0067] In another embodiment, the device identifier may be the International Mobile Equipment Identity (IMEI). LTMEI is a unique number assigned to each mobile device, including devices used in the V2X communication network. LTMEI is typically a 15-digit number, comprising the first eight digits of the Type Assignment Code (TAC) identifying the device model and manufacturer, with the following six digits providing a serial number. The (SR) is unique to the device, and the last digit, called the check digit (CD), is used for error detection and IMEI validation. In the V2X communication network, the IMEI can be assigned to each device, such as a vehicle's on-board unit or a V2X communication module, as described with reference to [Fig. 1]. For example, when a vehicle with an on-board unit equipped with V2X communication capabilities connects to the network, its IMEI can be used to identify the device.

[0068] In yet another embodiment, the device identifier can be the Cellular Vehicle-to-Everything (C-V2X) identifier. C-V2X is defined by the Third Generation Partnership Project (3GPP) and operates in both direct communication (without relying on the cellular network) and network-based communication (through the cellular network). The C-V2X identifier uniquely identifies each device participating in C-V2X communication, including vehicles, RSUs, and other infrastructure components. Typically, the C-V2X identifier comprises a combination of device-specific attributes, network-related information, and standardized identifiers.

[0069] In yet another embodiment, the device identifier can be the Subscription Permanent Identifier (SUPI). The SUPI is typically formatted as a globally unique identifier, such as an IMSI or a private identifier, depending on the network configuration and privacy requirements. In the V2X communication network, the SUPI serves as a unique identifier for each V2X device or vehicle within the network. For example, a vehicle equipped with V2X communication capabilities will have a SUPI that the network will use to identify and manage that specific vehicle.

[0070] Other device identifiers, besides those mentioned above, may be implemented without departing from the scope of this disclosure.

[0071] In addition, or alternatively, the input parameters in the key derivation process may include random values ​​or nonces.

[0072] Consequently, in the key derivation process, at step 308, the KDF is used to process the master key and the input parameters in order to generate the derived key(s).

[0073] Although step 308 is shown after steps 302, 304 and 306 in the process flow, this step can take place before the specified order.

[0074] At step 310, the derived key generated at step 308 is sent, via the secure PLS channel 312 (previously established at step 306), from UE1 202 to UE2 204. The reception of the derived key by UE2 204 is represented by step 314. Thus, each UE has the same derived key at its disposal by means of the secure PLS channel 312.

[0075] Then, either of the UEs, at the respective stages 316 and 318, can use the derived key as proof of identity (e.g., long-term proof of identity) or can advantageously be used directly as a shared key (e.g., V2X / D2D keys) for the direct interface (PC5) in V2X / D2D communication.

[0076] Figure 4 illustrates the storage of a master key in a UE's home network, according to one embodiment of the present disclosure. As briefly mentioned in step 302, the process flow in [Fig. 4] requires the preconfiguration of a master key in a UE (e.g., UE1 202) to allow the derivation of other keys that are used for V2X / D2D communication between UE1 202 and UE2 204. The master key preconfigured in UE1 202 is stored in step 402 in the UE1 202 home network 400. The UE1 202 home network 400 may include a network node such as the Authentication Credential Processing and Repository Function (ARPF) or Unified Data Management (UDM), or the Authentication Center (AuC), or a private network hosting radio network / core network nodes related to wireless communication technologies (e.g., LTE, 5G, or 6G).For example, the UDM manages and stores device profile data, including authentication credentials (e.g., cryptographic keys such as the master key, private key, etc.) and service information. The UDM verifies credentials, authenticates the device, and grants access based on the subscription and policy. The ARPF is a functional component of the UDM, responsible for generating authentication vectors for the 5G home environment (5G HE AV) based on the subscriber's shared secret key. As another example, the AuC manages authentication credentials, such as the IMSI and cryptographic keys, used to authenticate V2X devices. The AuC stores and processes vehicle credentials to verify their authenticity before allowing them to participate in V2X communications.In 5G networks, AuC collaborates with the UDM to validate device identity credentials and enforce security policies during V2X communication. In some embodiments, the V2X UE's home network (e.g., UE 400 of UE 202) can be cloud-native and manage network user data in a centralized element. Data stored in the UE 400 home network may include authentication and / or encryption keys used to protect data confidentiality and integrity and to verify the legitimacy of the UE's identity.

[0077] It should be noted that the master key is preconfigured in one of the two UEs communicating with each other. As described herein, the master key is preconfigured in Uel 202, but not in UE2 204. Consequently, the preconfigured master key is stored in the 400 home network associated with the Uel 202 that hosts the preconfigured master key. Although [Fig. 4] is described in the context of preconfiguring the master key in Uel 202 and storing it in the 400 home network of Uel 202, without limitation, the master key can alternatively be preconfigured in UE2 204 and stored in its corresponding home network instead of preconfiguring the master key in Uel 202 and its corresponding home network.

[0078] In addition, without departing from the scope of this disclosure, one or more master keys may be preconfigured in one of the two communicating UEs (for example, UEl 202) to establish a secure channel using PLS.

[0079] Figure 5, as shown, illustrates a Lawful Interception (LI) entity 500 that uses the pre-configured master key of the UEl 202 for a specific implementation of decrypting communication between the UEl 202 and the UEl 204. In particular, LI 500 refers to an entity that is authorized to access and monitor communications for specific purposes defined by law. These specific purposes may include, but are not limited to, national security, criminal investigations, public safety, the verification of evidence, and the like. LI 500, in its capacity as such, may intercept data or transmit data to third parties depending on the specific purpose.

[0080] If we return to [Fig.5], step 402 is the same as that shown in [Fig.4] and is not explained again for the sake of brevity. At step 502, LI 500 can request the secret used for direct communication between UE 202 and UE 204 from the UE 400 home network. This secret may include the preconfigured master key or the derived key (discussed in previous figures) used for V2X / D2D communication between UE 202 and UE 204. In response to LI 500's request, at step 504, the UE 400 home network can retrieve the preconfigured master key from UE 202. Based on the credentials stored in the UE 202 home network 400, LI 500 can retrieve the shared secret, which may include the stored master key or any derived key, to decrypt the communication between UE 202 and UE 204.Without departing from the scope of this disclosure, the LI 500 may access any authentication or security data from a UE's home network depending on the use case.

[0081] Therefore, the present solution referred to in Figures 3 to 5 meets the requirements for lawful interception to decrypt communications between V2X / D2D devices, where applicable.

[0082] In the process examples discussed for V2X / D2D communication in Figures 2 to 5, the fact that the secret key is established using PLS at the physical layer and that the V2X / D2D key(s) are established at the PC5 interface level using the PLS-based secret key simplifies the process of providing long-term credentials to UEs for direct V2X / D2D communication. Furthermore, PLS technology uses channel attributes, sender / receiver attributes, and secret metrics to achieve better key management and distribution, reduce power consumption, address sender and receiver restrictions, and enhance security control for data exchange compared to conventional approaches.

[0083] Figure 6 illustrates a flowchart for an exemplary method for establishing a secret key between wireless communication devices, according to an embodiment of the present disclosure. The flowchart will be explained in conjunction with the preceding figures.

[0084] At step 602, a secret key is established between a first wireless communication device and a second wireless communication device using physical layer security. In some embodiments, the first and second wireless communication devices may correspond to a UE within a V2X / D2D / ProSe environment. By way of example, the first or second wireless communication device may correspond to vehicle 102A, vehicle 102B, RSU 104, or communication device 106A, which communicate with each other via one or more direct interfaces. The secret key is established between these wireless communication devices using PLS, which utilizes the random attributes of the wireless channel between these entities.Such channel attributes can include received signal strength (RSS), power spectral density (PSD), channel intensity coefficients (CSI), channel power delay profile (PDP), channel frequency response (CFR), among others. Ensuring the security and privacy of these communications at the physical layer can significantly improve overall network security and reliability. In some embodiments, applying encryption techniques directly at the physical layer to protect data from unauthorized access may involve the application of sophisticated coding schemes and encryption algorithms designed for high-speed communications.

[0085] In different embodiments, as described previously with reference to [Fig.2], the secret key established at step 602 can be a root or master key, a session key, an encryption key or an integrity key, among other variants.

[0086] Once the secret key is established, at step 604, the established key is either used to derive one or more keys for direct communication between wireless devices (or UEs) or used directly as the shared key for the direct interface to establish direct communication. In some embodiments, the direct interface can correspond to any of interfaces 110, 112, and 114 (described previously in [Fig. 1]) depending on the wireless devices involved in the direct communication. The PLS-based secret key can be used directly for the PC5 interface between wireless devices or entities (e.g., vehicles) for direct communication without the intervention of any network node.The PLS-based secret key can also be used as a long-term credential to derive other keys using identifiers and authentication signaling between wireless devices.

[0087] In one embodiment, when the secret key established between the wireless entities is a root key or a master key, then the root key can be used to derive one or more keys (for example, session keys) for direct communication between the wireless devices using the key derivation process described above, employing appropriate KDF and key protocol algorithms. In another embodiment, when the secret key established between the wireless entities is a session key, then the session key can be used directly as a shared key for the direct interface to establish direct communication between the wireless devices. The session key can be derived from the master key for specific communication sessions between the wireless devices. To maintain security, the session key can be refreshed periodically during extended sessions.This involves generating a new session key and updating both wireless entities or UEs. Furthermore, UEs can renegotiate session keys if the original key is compromised or if security conditions change. In yet another embodiment, when the secret key established between the wireless entities is an encryption or integrity key, then the encryption or integrity key can be used directly as a shared key for the direct interface to establish direct communication between the wireless devices.

[0088] Various embodiments presented here elucidate the use of a PLS-based secret key as a shared V2X / D2D key for V2X / D2D communication via a direct interface. This feature opens the way to a whole range of applications in the field of vehicle networks involving real-time and high-speed communication. The low-latency communication paths established through current solutions enable real-time autonomous driving, efficient road and traffic monitoring, issuing alerts related to road and traffic conditions, collision avoidance and grouping into platoons.

[0089] Figure 7 illustrates a flowchart 700 for another exemplary method for establishing a secret key between wireless communication devices, according to an embodiment of this disclosure. The flowchart 700 will be explained in conjunction with the preceding figures. Although the example method used for the flowchart 700 represents a particular sequence of operations, the sequence can be modified without departing from the scope of this disclosure. For example, some of the operations described can be performed in parallel or in a different sequence that does not materially affect the function of the flowchart 700. In other examples, different components of an example device or system that implements the flowchart 700 can perform functions substantially at the same time or in a specific sequence.

[0090] Initially, at step 702, a master key is preconfigured in a first wireless communication device. Preconfiguration involves securely embedding or loading the master key into the device's hardware or software before its deployment or use. In some embodiments, a vehicle or UE in V2X / D2D communication can be configured with a master key, which can function as a fundamental cryptographic key used as a basis for generating other keys (e.g., a session key, an encryption key, an integrity key). In some embodiments, the master key can be preconfigured in the first wireless communication device during the manufacturing process. This involves securely programming the master key into the device's hardware or firmware before it is shipped to end users.In alternative embodiments, the provisioning of the master key in the first wireless communication device can take place after manufacturing. The master key can be provided or updated remotely via over-the-air (OTA) radio mechanisms, enabling secure updates of the master key without physical access to the device.

[0091] In step 704, a secret key is established between the first and second wireless communication devices using physical layer security. This step is similar to step 602 mentioned earlier with reference to [Fig. 6], so details are omitted for brevity. The established secret key is used to establish a secure channel between the communication devices.

[0092] At step 706, a key is derived from the master key by the first wireless communication device and transmitted over the secure channel to the second wireless communication device. The process of deriving a key from the master key is similar to step 308 mentioned earlier with reference to [Fig. 3], so details are omitted for brevity. Transmitting the derived key from the first wireless communication device to the second wireless communication device ensures that the key was derived correctly. This may include verifying the integrity of the derived key or confirming its authenticity. In the embodiments discussed here, sharing the derived key between the two communication devices at the physical layer ensures confidentiality, integrity, and authentication, while mitigating interference or attacks on channel security. The derived key, for example, could be a session key, an encryption key, an integrity key, and the like.

[0093] Furthermore, at step 708, the derived key is either used as a credential (e.g., long-term credential) or used directly as a shared key for the direct interface to establish direct communication. The derived key can be used for continuous operations rather than for individual communication sessions between the first and second wireless communication devices. Using the derived key as a long-term credential simplifies, to some extent, the exchange of complex authentication signaling between the UEs.

[0094] The use of the shared secret key, as described in various embodiments, facilitates direct communication between wireless devices (e.g., V2X UEs) via the PC5 interface (e.g., in a V2X environment). Several types of data can be transferred between V2X UEs over the PC5 interface, such as, but not limited to, traffic management messages, basic safety messages, emergency vehicle warning messages, cooperation awareness (CAM) messages, application-specific data, multimedia content, command and management messages, safety-related messages, and the like.

[0095] Traffic management messages are used to communicate traffic control information, such as traffic light phases, road closures, speed limits, traffic notices, congestion warnings, and the like. For example, a V2X UE can communicate a message about an impending red light or road closure to another approaching V2X UE in the V2X network.

[0096] Basic safety messages are used to share information about the vehicle's status. The content of these messages may include data relating to the vehicle's location (e.g., GPS coordinates), speed, acceleration, and other parameters necessary for collision avoidance and the situational awareness. For example, a V2X UE can broadcast its position and speed to other vehicles and RSUs in order to avoid collisions and improve traffic flow.

[0097] Emergency vehicle warning messages can be used to inform other road users of the presence and location of emergency vehicles, such as ambulances, fire trucks, or police cars. Such messages may include the location, direction, and planned route of the emergency vehicle. For example, an ambulance transporting a patient may broadcast its position and planned route to ensure that other nearby vehicles do not block the way, allowing the ambulance to make its way to the medical facility. The role of emergency vehicle warning messages is critical in situations where time is of the essence and life is at risk, when the patient requires immediate care.

[0098] CAMs include data relating to vehicle identification, position, speed, and other dynamic information such as planned actions or maneuvers. These messages can be shared with nearby vehicles and infrastructure in a V2X environment to improve situational awareness. For example, a V2X UE can send a CAM to warn nearby vehicles of its intention to change lanes. Such a message, sent in a timely manner by one V2X UE to another nearby V2X UE, can prevent collisions and road accidents, thereby improving road safety.

[0099] V2X UEs can exchange application-specific data to support one or more V2X applications. Such data may include information related to carpooling, parking, tolls, road surveillance cameras, nearby restaurants, and nearby medical assistance, among other things. For example, V2X UEs can exchange data to coordinate platooning or carpooling.

[0100] In addition, V2X UEs can exchange multimedia content such as music, videos, or maps directly with other vehicles or passengers for infotainment or navigation control purposes. For example, one V2X UE can share navigation route details with another V2X UE to reach a common destination.

[0101] Command and management messages can be exchanged for efficient use of the PC5 interface. Such messages may relate to the allocation of a communication channel, synchronization information, and the like. For example, V2X UEs can coordinate to avoid interference.

[0102] In addition, V2X UEs can exchange security-related messages, such as identity credentials or certificates, to verify vehicle identity and guarantee authorized access. For example, V2X UEs can exchange authentication tokens to establish trust before sharing sensitive data.

[0103] Data communication between V2X UEs using the aforementioned data types is crucial for the efficient operation of the V2X communication network, thereby improving safety, efficiency and the overall user experience on the road.

[0104] Figure 8 illustrates a functional diagram of a wireless communication device 800 that can be used to make credentials available, according to implementations of this disclosure. In some embodiments, the wireless communication device 800 may correspond to a V2X UE (e.g., vehicles 102A-102B, UE1 202, UE2 204), an RSU 104, a communication device 106A, or any wireless entity capable of establishing communication with another entity in V2X / D2D / ProSe networks. In other embodiments, the wireless communication device 800 may implement a function of the V2X server 108, which may be a general-purpose server or a dedicated server.

[0105] The wireless communication device 800 comprises one or more processor(s) 802, a memory 804, a communication interface 806 and input / output devices 808. Each of these components can be functionally coupled to a communication bus 810, which can be configured, for example, for optical and / or electrical communication.

[0106] The 802 processor(s) may include a central processing unit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), or another type of processing circuit. The 802 processor(s) may be implemented using a mainframe computer, a distributed processor, multiple cores, a parallel architecture, a grid, or other architectures. The 802 processor(s) may be configured to implement the functions, procedures, and / or methods proposed by this disclosure, as described in Figures 1 through 7. In addition, layers of a wireless interface protocol may be implemented by the 802 processor(s).

[0107] Memory 804 can be any suitable medium that participates in providing instructions to processor(s) 802 for execution. For example, memory 804 can be a non-transient or non-volatile medium, such as a magnetic disk or solid-state non-volatile memory, or a volatile medium such as random access memory (RAM). The instructions or modules stored in memory 804 can include machine-readable instructions, executed by processor(s) 802, which cause processor(s) 802 to perform the identity device setup processes and functions.

[0108] In addition, the 804 memory can be communicatively coupled to the 802 processor(s) and store information relating to the operations of the 802 processor(s). The 804 memory can be located inside or outside the 802 processor and can be connected to the 802 processor(s) through various well-known means.

[0109] The 806 communication interface can use any device such as a transceiver or an RF module to communicate with another device or a communication network such as Ethernet, a radio access network (RAN), or a wireless local area network (WLAN). In other examples, the 806 communication interface can be a local area network (LAN) interface, an 802.11x wireless interface, a 3G, 4G, 5G, or 6G mobile wide area network, or a WiMAX wide area network.

[0110] The input / output devices 808 may include one or more input and output devices. The input device may be a keyboard, mouse, joystick, remote control (infrared), camera, card reader, fax machine, electronic key, biometric reader, microphone, touchscreen, touchpad, trackball, sensor (for example, accelerometer, light sensor, GPS, gyroscope, proximity sensor or similar), stylus, scanning device, storage device, transceiver, video device / source, viewers, etc.The output device can be a printer, fax machine, video display, liquid crystal display (LCD), light-emitting diode (LED), organic light-emitting diode (OLED), quantum dot light-emitting diode (QLED), micro-LED, mini-LED, quantum dot LED (QLED-QD), audio speaker, etc.

[0111] Other modules, circuit assemblies, and / or components may be included in the 800 wireless communication device but are not shown for the sake of brevity. For example, a communication module (as described earlier with reference to [Fig. 1]) may be included to manage communications with other wireless devices (e.g., UEs, vehicles, etc.) and the infrastructure. In addition, a navigation module may be included for location services, route planning, and guidance. Furthermore, various sensors may be present within the 800 wireless communication device to collect data on its environment (e.g., the vehicle environment).

[0112] Although [Fig. 8] is shown with respect to a single wireless communication device, it will be apparent that a system comprising a plurality of wireless communication devices (e.g., UE1 202 and UE2 204) can be implemented, each device communicating with the other device via of known communication technologies and appropriate communication interfaces.

[0113] This disclosure applies to various wireless communication systems such as, but not limited to, 3GPP LTE / LTE-A, 5G and 6G systems, and shall be interpreted accordingly.

[0114] In addition, this disclosure can be applied to many ground-to-ground transmissions such as, but not limited to, Bluetooth or Bluetooth Low Energy (BLE) wireless devices and communications, IoT, WLAN, HyperLAN, and the like.

[0115] In addition, this disclosure may be applied to aeronautical communications such as, but not limited to, communications used in air traffic management (ATM) systems or air traffic control (ATC) communication systems.

[0116] The implementations and all functional operations described in this description can be carried out in digital electronic circuit assemblies, or in software, firmware or computer hardware, including the structures disclosed in this description and their structural equivalents, or in combinations of one or more of them.

[0117] The preceding disclosure is provided for illustrative and descriptive purposes only. The foregoing is not intended to limit the disclosure to the form or forms disclosed herein. In the preceding detailed description, for example, various features of the disclosure are grouped into one or more examples, configurations, or aspects for the purpose of simplifying the disclosure. The features of the examples, configurations, or aspects of the disclosure may be combined into other examples, configurations, or aspects than those described above. Accordingly, this disclosure and the drawings should not be considered exhaustive, as it should be understood that an invention presented within a disclosure is in no way limited to the specifically illustrated examples.

[0118] Accordingly, the above description and the accompanying drawings, illustrations, and figures are illustrative but not restrictive. The scope of any invention presented in this disclosure should therefore not be determined by mere reference to the above description and the examples shown in the figures, but rather by reference to the dependent claims, with their full scope or their equivalents.

Claims

Demands

1. Method of making identity credentials available for direct communication between a first wireless communication device (202) and a second wireless communication device (204), said method comprising: the establishment (206; 304) of a secret key between said first wireless communication device (202) and said second wireless communication device (204) using physical layer security, PLS, in a V2X (vehicle-to-everything) environment; and the use (208, 210; 316, 318) of said secret key, by said first wireless communication device (202) and / or said second wireless communication device (204), to: derive one or more keys from said secret key to establish said direct communication, or use directly as a shared key to establish said direct communication.

2. A method according to claim 1, wherein said direct communication is established via a direct interface, said direct interface comprising a PC5 interface (110) between said first wireless communication device (202) and said second wireless communication device (204).

3. A method according to any one of the preceding claims, further comprising preconfiguring (302) a master key in said first wireless communication device (202).

4. Method according to claim 3, wherein said master key is stored in a home network (400) of said first wireless communication device (202).

5. A method according to claim 4, further comprising the establishment (306) of a secure channel between said first wireless communication device (202) and said second wireless communication device (204) using said secret key.

6. Method according to claim 5, further comprising sending (310), by said first wireless communication device (202), a key derived from said master key to said second wireless communication device (204) using said secure channel.

7. A method according to any one of claims 1 to 6, wherein at least one of said stored master key or said derived key is retrieved by a lawful interception entity, LI (500), in response to a request (502) for said one or more keys or said shared key used for said direct communication between said first wireless communication device (202) and said second wireless communication device (204).

8. Method according to claim 6, wherein said derived key comprises one or more device identifiers and a session identifier.

9. Method according to claim 8, wherein said device identifiers correspond to at least one identity of said first wireless communication device (202) or of said second wireless communication device (204).

10. A method according to any one of the preceding claims, wherein said secret key comprises at least one of a root key, a key derived from said root key, an encryption key, or an integrity key.

11. A method according to any one of the preceding claims, wherein said first wireless communication device (202) and / or said second wireless communication device (204) comprises D2D (device-to-device) user equipment.

12. Identity credential provisioning system, said system comprising: a first wireless communication device (202) comprising one or more processors (802) and a storage medium (804) communicatively coupled to said one or more processors (802), said storage medium (804) comprising one or more executable instructions; a second wireless communication device (204) in direct communication with said first wireless communication device (202); and at least one communication interface (806) for establishing said direct communication between said first wireless communication device (202) and said second wireless communication device (204), wherein said one or more processors (802) of said first wireless communication device (202), when executing said one or more executable instructions, are configured to: establish a secret key between said first wireless communication device (202) and said second wireless communication device (204) using Physical Layer Security (PLS) in a V2X (vehicle-to-everything) environment; and use said secret key, through said at least one communication interface (806), to derive one or more keys to establish said direct communication, or use it directly as a shared key to establish said direct communication.

13. System according to any one of the preceding claims, wherein said first wireless communication device (202) and / or said second wireless communication device (204) comprises D2D (device-to-device) user equipment.

14. A system according to any one of the preceding claims, wherein said secret key comprises at least one of a root key, a key derived from said root key, an encryption key, and an integrity key.

15. System according to any one of the preceding claims, wherein said at least one communication interface (806) comprises a PC5 interface between said first wireless communication device (202) and said second wireless communication device (204).

Images