Protection of communications by user equipment relays

Abstract

This application relates to devices and components, including apparatuses, systems, and methods for protected user equipment communications through user equipment relays. In some embodiments, symmetric or asymmetric encryption can be used for the protected user equipment communications.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of International Application No. PCT / CN2020 / 103719, filed July 23, 2020, which application is hereby incorporated by reference in its entirety for all purposes. BACKGROUND

[0003] The Third Generation Partnership Project (3GPP) describes various Proximity Services (ProSe) architectures, signaling procedures, and use cases. To effectively integrate ProSe-enabled User Equipment (UE) into 3GPP New Radio (NR) networks, additional considerations can need to be addressed. BRIEF DESCRIPTION OF DRAWINGS

[0004] Figure 1 A network environment is shown in accordance with some embodiments.

[0005] Figure 2 A process for establishing a secure connection is shown in accordance with some embodiments.

[0006] Figure 3 A process for establishing a secure connection is shown in accordance with some embodiments.

[0007] Figure 4 A process for establishing a secure connection is shown in accordance with some embodiments.

[0008] Figure 5 A process for establishing a secure connection is shown in accordance with some embodiments.

[0009] Figure 6 A protocol stack that can be implemented by a user equipment is shown in accordance with some embodiments.

[0010] Figure 7 An operational flow / algorithmic structure is shown in accordance with some embodiments.

[0011] Figure 8 An operational flow / algorithmic structure is shown in accordance with some embodiments.

[0012] Figure 9 An operational flow / algorithmic structure is shown in accordance with some embodiments.

[0013] Figure 10 A device is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0014] The following detailed description is directed to the drawings. Like numbers in different drawings can identify like or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments can be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods can be omitted so as not to obscure the description of various embodiments with unnecessary detail. For the purposes of the present document, the phrase “A or B” means (A), (B), or (A and B).

[0015] The following is a glossary of terms that can be used in the present disclosure.

[0016] As used herein, the term “circuitry” refers to, is part of, or includes: hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and / or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA)), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable system-on-a-chip (SoC), a digital signal processor (DSP), etc., that are configured to provide the described functionality. In some embodiments, circuitry can execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” can also refer to the combination of

[0017] As used herein, the term “processor circuitry” refers to, is part of, or includes: circuitry capable of sequentially and automatically processing a series of arithmetic or logical operations or recording, storing, and / or transmitting digital data. The term “processor circuitry” can refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions such as program code, software modules, and / or functional processes.

[0018] As used herein, the term “interface circuitry” refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” can refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, and the like.

[0019] As used herein, the term “user equipment” or “UE” refers to a device with radio communication capabilities and that can describe a remote user of network resources in a communication network. Further, the terms “user equipment” or “UE” can be considered synonymous, and can be referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, and the like. Further, the terms “user equipment” or “UE” can include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0020] As used herein, the term “computer system” refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the terms “computer system” and / or “system” can refer to various components of a computer that are communicatively coupled to one another. Further, the terms “computer system” and / or “system” can refer to multiple computer devices and / or multiple computing systems that are communicatively coupled to one another and configured to share computing and / or networking resources.

[0021] As used herein, the term “resource” refers to a physical or virtual device, a physical or virtual component within a computing environment, and / or a physical or virtual component within a particular device, such as a computer device, a mechanical device, memory space, processor / CPU time and / or processor / CPU usage, processor and accelerator load, hardware time or usage, power supply, input / output operations, port or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and application, units of work, and the like. A “hardware resource” can refer to computing, storage, and / or network resources provided by a physical hardware element. A “virtualized resource” can refer to computing, storage, and / or network resources provided by a virtualization infrastructure to an application, device, system, and the like. The term “network resource” or “communication resource” can refer to resources accessible to a computer device / system via a communication network. The term “system resource” can refer to any kind of shared entity that provides a service, and can include computing resources and / or network resources. A system resource can be viewed as a set of coherent functionalities, network data objects, or services that are accessible through a server, where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0022] As used herein, the term "channel" refers to any tangible or intangible medium utilized to convey or transmit data or a data stream. The term "channel" can be synonymous with and / or equivalent to a communication channel, a data communication channel, a transmission channel, a data transmission channel, an access channel, a data access channel, a link, a data link, a carrier wave, a radio frequency carrier wave, and / or any other similar term denoting a pathway or medium through which data is conveyed. Additionally, as used herein, the term "link" refers to a connection between two devices for transmitting and receiving information.

[0023] As used herein, the terms "instantiate," "instantiation," and the like refer to the creation of an instance. An "instance" refers to a concrete occurrence of an object, which can occur, for example, during execution of program code.

[0024] The term "connect" can mean that two or more elements have an established signaling relationship with each other over a communication channel, link, interface, or reference point at a common communication protocol layer.

[0025] As used herein, the term "network element" refers to physical or virtualized equipment and / or infrastructure used to provide wired or wireless communication network services. The term "network element" can be considered synonymous with and / or referred to as a networked computer, networked hardware, network equipment, network node, virtualized network function, etc.

[0026] The term "information element" refers to a structural element containing one or more fields. The term "field" refers to individual content of an information element, or a data element containing content. An information element can include one or more additional information elements.

[0027] Figure 1 A network environment 100 is shown in accordance with some embodiments. The network environment 100 can include multiple UEs, including, for example, UE1 104, a UE-to-UE relay UE 108 (or simply a relay UE 108), and UE2 112. The UEs can operate in accordance with, or in a manner compatible with, the Long Term Evolution (LTE) or Fifth Generation (5G) NR system standards provided by 3GPP TS technical specifications.

[0028] The UEs of the network environment 100 can be configured for Proximity Service (ProSe) communication, in which the UEs can communicate directly with each other without the communication traversing an access node 120 providing a radio access network cell. The UEs can be mobile telephones, consumer electronic devices, tablet computers, wearable computer devices, vehicle computer devices, infrastructure equipment, sensors, etc.

[0029] One or more of the UEs can communicate with an access node 120 that provides a wireless access cell, e.g., an LTE cell or an NR cell. The access node 800 can be an eNB that provides an LTE access cell and is coupled with an Evolved Packet Core (EPC) network; an ng-eNB that provides an LTE access cell and is coupled with a 5G Core network (5GC); or a gNB that provides an NR access cell and is coupled with a 5GC.

[0030] The access node 120 can be coupled with a core network 124 (which can be an EPC or a 5GC) to provide service to UEs. The core network 124 can include network elements configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UEs) connected to the core network 124 via access cells provided by access nodes 120. The components of the core network 124 can be implemented in one physical node or separate physical nodes, including components to read and execute instructions from machine-readable or computer-readable media (e.g., machine-readable storage media). In some embodiments, network function virtualization (NFV) can be used to virtualize any or all of the above-described network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of the core network 124 can be referred to as a network slice, and a logical instance of a portion of the core network 124 can be referred to as a network sub-slice. NFV architectures and infrastructures can be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches, alternatively executed by specialized hardware. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more components / functions.

[0031] The core network 124 can include a ProSe function 126, which is a logical function for network-related actions related to ProSe operation. The ProSe function 126 can interface with UEs over a PC3 interface and with a ProSe application server 128 over a PC2 interface.

[0032] The ProSe function 126 can control a Direct Provisioning Function (DPF) for provisioning of necessary parameters to UEs for use in ProSe direct discovery. The DPF can provision a UE with Public Land Mobile Network (PLMN) specific parameters that allow the UE to use ProSe in a specific PLMN. The DPF can also provision a UE with parameters that can be used for direct communication when the UE is not served by a radio access network cell. The ProSe function 126 can also include a Direct Discovery Name Management Function for opening ProSe direct discovery to allocate and handle mapping of ProSe application identifiers and ProSe application codes used in ProSe direct discovery.

[0033] The ProSe application server 128 can store and manage various ProSe identifiers, metadata, and authorizations related to various discovery operations.

[0034] At a particular time, UEs can be within or outside the coverage of a radio access network cell provided by an access node, such as the access nodes 120. For example, at a given time, the UEs of the network environment 100 can be in a full coverage scenario (e.g., all UEs are within cell coverage), a partial coverage scenario (e.g., a subset of UEs can be within cell coverage), or an out-of-coverage scenario (e.g., no UEs are within cell coverage).

[0035] The UEs can communicate with each other over a sidelink (SL) interface. The SL interface can alternatively be referred to as a ProSe interface, a device-to-device (D2D) interface, or a PC5 interface or reference point.

[0036] In some embodiments, the network environment 100 can be deployed within a vehicular communication system. In a vehicular communication system, UEs can communicate with each other using cellular vehicle-to-everything (V2X) communications. V2X can involve vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (VTN), or vehicle-to-pedestrian (V2P) communications.

[0037] In some embodiments, UE1 104 can wish to establish a security association with UE2 112 over an end-to-end protected unicast link. However, given proximity or other considerations, UEs 104 and 112 can not be able to effectively communicate directly with each other but can communicate through a relay UE 108. Various embodiments describe how UEs 104 and 112 can establish a security association via relay UE 108.

[0038] In embodiments in which UE1 104 initiates the procedure for establishing a connection, it can be referred to as the initiating or source UE. In this case, UE2 112 can be referred to as the receiving or target UE.

[0039] Relay UE 108 can enable UE-to-UE relaying by facilitating discovery or acting as a repeater / amplifier. To provide these functionalities, relay UE 108 can need to know routing information with respect to UEs 104 and 112. However, it can be desirable for relay UE 108 to not have visibility into the content of subsequent communications, as there can not be a security relationship between UE 108 and either or both of UEs 104 and 112. Thus, various embodiments describe security-related procedures to be used when establishing end-to-end protected unicast link 116. These procedures can include UEs 104 and 112 negotiating a security context via relay UE 108, with relay UE 108 not knowing or discovering information about the security context itself.

[0040] In addition to the modifications and improvements described herein, embodiments of the present disclosure can be compatible with the UE-to-UE connection procedures described in 3GPP Technical Report (TR) 23.752, v0.4.0 (2020-06). While some embodiments are described with respect to solutions consistent with clause 6.9 of TR 23.752, the security establishment principles described herein can be used with respect to other connection procedures, including those described in other clauses of TR 23.752.

[0041] Figure 2 A procedure 200 for establishing a connection is shown in accordance with some embodiments. In procedure 200, UEs 104 and 112 can utilize asymmetric cryptography to encrypt their communications and avoid revealing information to relay UE 108.

[0042] In some embodiments, the asymmetric cryptography used by UEs 104 and 112 can be based on public-key cryptography, in which a public key can be shared throughout the system (e.g., through a broadcast message), while a private key is known only to the owner. Communications encrypted by a UE’s public key can only be decrypted using the UE’s private key.

[0043] Algorithms for asymmetric cryptography can include, but are not limited to, Rivest-Shamir-Adleman (RSA), Elliptic Curve Cryptography (ECC), identity-based cryptography (e.g., SM9), etc.

[0044] At 202, procedure 200 can include provisioning a UE with keys and any other security information (e.g., security algorithms, credentials, etc.) that can be used for asymmetric cryptography. In various embodiments, the UE can be provided with the public / private keys themselves or information for generating the public / private keys, such as a key generation program.

[0045] In some embodiments, some or all of the provisioning can be performed by a network element, such as ProSe Function 126. In other embodiments, a UE can be pre-provisioned with some or all of the key / credential information. For example, in embodiments that rely on identity-based cryptography, a public key can be based on the identity of the UE itself. Thus, in some of these embodiments, a UE can not need additional information about the public key. In these cases, the UE can be considered to be pre-provisioned with information related to the public key.

[0046] At 204, procedure 200 can include relay UE 108 registering with a network (e.g., access node 120 or core network 124) and providing its UE relay capabilities to the network. The network can then provision relay UE 108 with relay policy parameters and a unique relay identifier (ID).

[0047] At 208, UE2 112 can determine a target Layer-2 ID for signaling reception for PC5 link establishment. This can be similar to that described in clause 5.6.1.4 of 3GPP Technical Specification (TS) 23.287 v16.3.0 (2020-07-09). UE2 112 can be configured with a target Layer-2 ID, as described in, for example, TS 23.287, clause 5.1.2.1.

[0048] At 212, the application layer of UE1 104 can provide information to the ProSe layer of UE1 104 for PC5 unicast communication. The information can include, for example, the broadcast Layer-2 ID, the ProSe Application ID, the application layer ID of UE1 104, the application layer ID of UE2 112, and a relay eligible indication. The provision of this information can be similar to that described in, for example, TS 23.287, clause 6.3.3.1. After provisioning the information, the ProSe layer of UE1 104 can send (e.g., broadcast) a direct communication request message to trigger a peer discovery procedure. The direct communication request message can be sent using the source Layer 2 ID and the broadcast Layer-2 ID as targets. UE1 104 can also include other parameters in the direct communication request, as described in, for example, TS 23.287, clause 6.3.3.1.

[0049] UE1 104 can also generate the direct communication request to include a first information element (IE) including a list of supported security algorithms and a second IE including a public key of UE1 104. The list of supported security algorithms can indicate the security algorithms supported by UE1 and can be used as a basis for negotiating an asymmetric algorithm that can be used by both UE 104 and 112. In some embodiments, the negotiation of the asymmetric algorithm can be omitted in embodiments where the UE is mandated to support one or more specific algorithms.

[0050] At 216, relay UE 108 can receive the broadcast direct communication request message and verify whether it is configured to relay the application. This verification can include, for example, comparing the advertised ProSe Application ID to its provisioned relay policy parameters. If the ProSe Application ID matches the provisioned relay policy parameters, relay ID 108 can assign a relay Layer-2 ID (e.g., R-L2 ID-a) for UE1 104 to itself. This relay Layer-2-ID can be related to or otherwise associated with the L2 ID of UE1 104 in, for example, a mapping table at relay UE 108.

[0051] Upon verifying that the relay UE 108 is configured to relay the application, the relay UE 108 can forward the direct communication request to the UE2 112 along with an IE including a list of supported security algorithms and the public key of the UE1 104.

[0052] At 220, the UE2 112, which is interested in the advertised application, can check to determine whether it can support one or more of the security algorithms in the direct communication request. If so, as a response to the direct communication request, the UE2 112 can generate a direct communication accept message. The direct communication accept message can include at least one security algorithm that it supports selected from the algorithms in the direct communication request and the public key of the UE2 112. The indication of the supported algorithm and the public key can be set in respective IEs. The UE2 112 can send the direct communication request message to the relay UE 108.

[0053] The relay UE 108 can set the source field of the message to R-L2-ID-b as found in the mapping table and can set the target field to the L2 ID of the UE1 104 as found in the mapping table. The relay UE 108 can then forward the modified message to the UE1 104 at 224.

[0054] At 228, an extended and end-to-end protected unicast link is formed via the relay UE 108. The extended unicast link is end-to-end protected using the public keys of the UEs 104 and 112, while the routing information, which can include layer-2 IDs, is left outside the protected unicast link unimpeded.

[0055] For example, messages transmitted on the protected unicast link can be secure and opaque to the relay UE 108. However, in some embodiments, the routing information corresponding to the messages (e.g., layer-2 IDs) can be unprotected and visible to the relay UE 108. These IDs, which can be stored in a mapping table at the relay UE 108, can be used by the relay UE 108 so that the relay UE can complete its routing operations. Thus, while the messages themselves can be opaque to the relay UE 108, the L2-IDs of the UEs 104 and 112 can be accessible.

[0056] In this way, confidential, integrity-protected, or relay-protected messages (e.g., data or PC5 signaling (PC5-S”)) can be securely transmitted between the UE1 104 and the UE2 112 within the protected unicast link without compromising the relay functionality provided by the relay UE 108.

[0057] Figure 3A process 300 for establishing a connection is shown in accordance with some embodiments. The process 300 can utilize symmetric cryptography based on symmetric key cryptography to protect a communication channel between the UE1 104 and the UE2 112.

[0058] At 302, the process 300 can include provisioning operations similar to those described above with respect to the operations 202 of the provisioning of the Figure 2 However, at 302, the UE can be configured with information for configuring symmetric cryptography.

[0059] In some embodiments, the UE can be configured with information for providing a Diffie-Hellman key agreement protocol. The information configured to the UE can include security algorithms, such as a cipher suite that provides a set of algorithms that can be used to protect a connection. The information can also include credentials, which can include anything needed to execute the associated security algorithms. For example, a prime number and an integer can be security credentials that can be used to execute a Diffie-Hellman security algorithm.

[0060] The Diffie-Hellman key agreement protocol can rely on a key generated using a cryptographic algorithm based on a mathematical problem to produce a one-way function. For example, a UE can be configured with security credentials that include a prime modulus and a generator, as well as an unpredictable number (typically large and random) as a private key. Consider a UE1 104 with a private key (PRK1); a UE2 112 with a private key (PRK2); a prime modulus (PM); and a generator (G). The UE1 104 can determine its public key (PBK1) based on G PRK1 mod PM and send PBK1 to the UE2 112. The UE2 112 can determine its public key (PBK2) based on G PRK2 modulus PM and send PBK2 to the first UE. Then, the first UE can determine a shared key (Kshare) as the result of PBK2 PRK1 mod PM; and the UE2 can determine the same shared key (Kshare) as the result of PBK1 PRK2 mod PM. The shared secret (Kshare) can be used directly as a key or can be used to derive another key to encrypt subsequent communications using symmetric key cryptography. Without knowledge of the private key, the relay UE 108 can not be able to derive the shared key.

[0061] In some embodiments, the UE can be configured with an elliptic curve public-private key pair and any other credentials that can be needed for use in an Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol, which can be a variant of the Diffie Hellman protocol using elliptic curve cryptography. In some embodiments, the security credentials can correspond to multiple elliptic curves that can be used with the ECDH key agreement protocol. In general, elliptic curve protocols such as ECDH provide shorter encryption keys that use less memory and CPU resources to achieve comparable security as, for example, RSA.

[0062] Operations 304 and 308 can be similar to Figure 2 corresponding operations 204 and 208, respectively.

[0063] At 312, the process can include UE1 104 generating a direct communication request message to include the public key of UE1 104. Because the direct communication request message is to be broadcast and not all target UEs can support ECDH, UE1 104 can also include an ECDH indication within the direct communication request message. In this way, a receiving UE can know that the security algorithm to be used to establish a protected connection is the ECDH key agreement protocol. The direct communication request message can be transmitted to the relay UE 108, which forwards the direct communication request message including the public key of UE1 104 and the indication of ECDH to UE2 112 at 316. The forwarding of the direct communication request message can be similar to the forwarding described above with respect to 216.

[0064] At 318, UE2 112 can process the direct communication request message to obtain the transmitted information. If UE2 112 supports the ECDH key agreement protocol, UE2 112 can proceed to generate a shared key (Kshare) using the private key of UE2 112 and the public key of UE1 104 according to the ECDH key agreement protocol.

[0065] At 320, UE2 112 can generate a direct communication accept message including the public key of UE2 112 and transmit the direct communication accept message to UE relay 108. At 324, the relay UE 108 can forward the direct communication accept message to UE1 104. The forwarding of the direct communication accept message can be similar to the forwarding described above with respect to 324.

[0066] At 326, UE1 104 can generate a shared key (Kshare) using the private key of UE1 104 and the public key of UE2 112 according to the ECDH key agreement protocol. At this point, both UE1 104 and UE2 112 can have access to the same shared key.

[0067] At 328, an end-to-end protected unicast link can be established via the relay UE 108. Communications over the unicast link can be encrypted using Kshare available to both UE1 104 and UE2 112, and routing information can be left outside the protected unicast link.

[0068] In some embodiments, the credentials provisioned to the UEs 104 and 112 at 302 can include multiple elliptic curves that can be used in the ECDH key agreement protocol. These elliptic curves can be, for example, the secp256kl curve, X25519 (or curve 25519), X448 (or curve 448), etc. Provisioning the UEs 104 and 112 with multiple options for utilizing the ECDH key agreement protocol can result in uncertainty as to the credentials to be used in a particular instance. Accordingly, some embodiments can also include a negotiation or other configuration that can cause the UEs 104 and 112 to align on the public credentials to be used with the ECDH key agreement protocol. Figure 4 and Figure 5 A process is shown that can allow the UEs 104 and 112 to negotiate the particular credentials that can be used to generate a shared key to protect a connection.

[0069] Figure 4 A process 400 for establishing a connection is shown in accordance with some embodiments. Similar to process 300, process 400 can utilize symmetric cryptography based on the ECDH key agreement protocol.

[0070] Operations 402, 404, and 408 can be similar to respective operations 302, 304, and 308 as described with respect to process 300. Figure 3

[0071] At 412, process 400 can include UE1 104 generating a direct communication request message to include a public key of the UE 104 and an indication of the ECDH key agreement protocol, as described above with respect to operation 312. However, the direct communication request message generated at 412 can also include a credential ID to facilitate negotiation of the ECDH credential configuration.

[0072] ​The ProSe application of UE1 104 can implement multiple credentials of ECDH, which can have been provisioned in the key and security information provisioning at 402. Additionally, other UEs that have installed the ProSe application can also be capable of implementing the various credentials. In some embodiments, each UE that has installed the ProSe application can also have downloaded the credentials and associated credential IDs. This association information can additionally / alternatively be communicated to UEs 104 and 112 through the key and security information provisioning at 402. Thus, the inclusion of the credential ID in the direct communication request message generated by UE1 104 at 412 can uniquely identify the provisioned credential to be used for the ECDH key agreement protocol. The transmission of the credential ID can protect the identity of the underlying credential, at least with respect to devices that have not downloaded the same application program. Furthermore, the transmission of the credential ID as opposed to the credential itself can also use less control signaling overhead.

[0073] At 416, the process 400 can include the relay UE 108 forwarding the direct communication request message with the public key of UE1 104, the indication of ECDH, and the credential ID to UE2 112. The forwarding of the direct communication request message can be similar to the forwarding described above with respect to 216.

[0074] UE2 112 can process the direct communication request to receive the transmitted information including the credential ID. At 418, the process 400 can include UE2 112 generating a shared key using the private key of UE2 112 and the public key of UE1 104 through the ECDH key agreement protocol based on the credential corresponding to the credential ID.

[0075] The process 400 can also include operations 420, 424, 426, and 428, which can be similar to the respective operations 320, 324, 326, and 328 described above with respect to Figure 3

[0076] Figure 5 A process 500 for establishing a connection is shown, in accordance with some embodiments. Similar to the processes 300 and 400, the process 500 can utilize symmetric cryptography based on the ECDH key agreement protocol.

[0077] The operations 502, 504, and 508 can be similar to the respective operations 302, 304, and 308 described above with respect to Figure 3

[0078] At 512, the process 500 can include UE1 104 generating a direct communication request message to include the public key of UE1 104 and the indication of ECDH, as described above with respect to the operation 412.

[0079] ​​The security credential (e.g., elliptic curve) can not be private information. Thus, in this implementation, rather than including the credential ID in the direct communication request message, the credential itself can be included. For example, as shown in Figure 5 UE1 104 can generate a direct communication request message to include an indication that curve X25519 is to be used.

[0080] At 516, process 500 can include the relay UE 108 forwarding the direct communication request message to UE2 112 with the public key of UE1 104, the indication of ECDH, and the credential to be used (e.g., curve X25519). The forwarding of the direct communication request message can be similar to the forwarding described above with respect to 216.

[0081] UE2 112 can process the direct communication request to receive the transmitted information including the credential. If UE2 112 supports the credential, then process 500 can include UE2 112 generating a shared key based on the credential at 518 using the private key of UE2 112 and the public key of UE1 104 through the ECDH key agreement protocol.

[0082] Process 500 can also include operations 520, 524, 526, and 528, which can be similar to respective operations 420, 424, 426, and 428 described above with respect to Figure 4

[0083] Processes 400 and 500 describe UEs 104 and 112 determining which of a plurality of provisioned credentials to use to establish a shared key to protect an extended unicast link. In other implementations, the negotiation of processes 400 and 500 can be avoided by limiting the number of provisioned credentials. For example, a UE can be configured with only one credential for ProSe support (e.g., curve X25519). Thus, the UE can not need to negotiate which credential to use.

[0084] Figure 6 A protocol stack 600 that can be implemented by a UE is shown in accordance with some embodiments. The control plane protocol stack 600 can provide a UE-to-UE layer-2 relay.

[0085] UE1 104 can include an application (APP) layer 602 coupled with a corresponding APP layer 604 of UE2 112. The APP layer can use lower layers to provide data transfer services.

[0086] UE1 104 can include a ProSe layer 604 coupled with a corresponding ProSe layer 606 of UE2 112.

[0087] ​The ProSe layer can be used to establish a protected connection as described herein. The ProSe layer can perform various other ProSe operations, including those that can terminate at one or more other ProSe elements within the network. For example, additional ProSe operations can include those involving ProSe signaling of control information with other ProSe-enabled UEs over a PC5 signaling (PC5-S) interface; ProSe discovery operations for discovery of other ProSe-enabled UEs over a PC5 discovery (PC5-D) interface; service authorization, configuration, provisioning of ProSe functionality over a PC3 interface; etc.

[0088] In the control plane, the ProSe layer can also perform one or more radio resource control (RRC) layer operations. For example, the ProSe layer can provide connection establishment and release functions, broadcast of system information, radio bearer establishment, reconfiguration, and release, mobility, and paging functions.

[0089] In the data plane, the ProSe layer can perform service data adoption protocol (SDAP) layer operations. SDAP layer operations can include mapping between quality of service (QoS) flows and data radio bearers and marking of QoS flow identifiers as well as downlink packets and uplink packets.

[0090] UE1 104 can also include a packet data convergence protocol (PDCP) layer 608 coupled with a corresponding PDCP layer 610 of UE2 112. The PDCP layer can control transfer of user / control plane data, header compression, ciphering, and integrity protection. The PDCP layer can establish end-to-end security between UEs 104 and 112. This can allow signaling messages to be transferred between UEs 104 and 112 through the relay UE 108 transparently without any modification other than the source and target layer-2 IDs.

[0091] UE1 104 can also include a radio link control (RLC) layer 612 coupled with a corresponding RLC layer 614 in the relay UE 108. The relay UE 108 can also include another RLC layer 616 coupled with a corresponding RLC layer 618 in UE2 112.

[0092] The RLC layer can transfer upper layer protocol data units as well as operate in acknowledged mode, unacknowledged mode, or transparent mode. The RLC layer can manage RLC service data units and protocol data units separately for each of these modes to provide error detection and recovery.

[0093] UE1 104 can also include a medium access control (MAC) layer 620 coupled with a corresponding MAC layer 622 in the relay UE 108. The relay UE 108 can also include another MAC layer 624 coupled with a corresponding MAC layer 626 in UE2 112.

[0094] The MAC layer can perform mapping between logical channels and transport channels for a sidelink transmitter (TX) and receiver (RX); multiplexing for a sidelink TX; demultiplexing for a sidelink RX; scheduling information reporting for a sidelink TX; error correction through hybrid automatic repeat request (HARQ) for a sidelink TX / RX; logical channel prioritization for a sidelink TX; and radio resource selection for a sidelink TX.

[0095] The MAC layer, which can be at Layer 2, can also manage aspects of routing through L2 IDs, as described in processes 200, 300, 400, and 500. For example, the MAC layer of the relay UE 108 can manage a mapping table that associates R-L2 ID-a with the L2 ID of UE1 104 and R-L2 ID-b with the L2 ID of UE2 112, as well as updates to routing information in messages forwarded to UE1 104 and UE2 112.

[0096] UE1 104 can also include a physical (PHY) layer 628 coupled with a corresponding PHY layer 630 in the relay UE 108. The relay UE 108 can also include another PHY layer 632 coupled with a corresponding PHY layer 634 in UE2 112.

[0097] The PHY layer, which can also be referred to as Layer 1 (LI), provides physical layer processing as well as transmission and reception across the air interface. The PHY layer can add cyclic redundancy check bits to a transport block at the transmitter to allow for error detection at the receiver. The PHY layer can also perform channel coding, interleaving, and modulation to efficiently transmit / receive information over the air interface.

[0098] Figure 7 An operational flow / algorithmic structure 700 can be included in accordance with some embodiments. The operational flow / algorithmic structure 700 can be used by an initiating UE to establish a protected unicast link between two UEs via a relay UE.

[0099] In some embodiments, the operational flow / algorithmic structure 700 can be performed by an initiating UE, such as UE1 104, UE 1000, or a component thereof (e.g., a baseband processor of the processor 704).

[0100] The operational flow / algorithmic structure 700 can include accessing provisioning information at 704. The provisioning information can be accessed from a memory / storage device (e.g., memory / storage device 1012) of the device.

[0101] In some embodiments, the provisioning information can be provisioned to the UE through a configuration message transmitted from a network element such as, but not limited to, a ProSe function (such as ProSe function 126). In other embodiments, some or all of the provisioning information can be pre-provisioned or pre-configured at the UE.

[0102] In various embodiments, the provisioning information can include identity information, key information, security credential information, and the like.

[0103] The operational flow / algorithmic structure 700 can also include broadcasting a direct communication request message at 708. The direct communication request message can be broadcast to initiate a peer discovery procedure. Broadcasting of the direct communication request message can be achieved through use of a broadcast L-2 address as a destination address in the direct communication request message.

[0104] In various embodiments, the direct communication request can be generated to include asymmetric or symmetric cryptography information that can be used to protect a unicast link resulting from the peer discovery procedure. The cryptography information can include, for example, a list of supported security algorithms, public key information of the initiating UE, an indication that an ECDH key agreement protocol will be used for symmetric encryption, an indication of a security credential (e.g., an identifier or name) to be used with the ECDH key agreement protocol, and the like.

[0105] The operational flow / algorithmic structure 700 can also include receiving a direct communication accept message at 712. In various embodiments, the direct communication accept message can include public key information of the receiving UE, and optionally a security algorithm selected by the receiving UE. In some embodiments, the direct communication accept message can be encrypted based on a private key of the initiating UE.

[0106] The operational flow / algorithmic structure 700 can also include decrypting communications at 716. In embodiments utilizing asymmetric cryptography, decryption of communications at 716 can involve decrypting messages (e.g., the direct communication accept message or other messages) received from the receiving UE based on a private key of the initiating UE.

[0107] In embodiments utilizing symmetric cryptography, the initiating UE can generate a shared key based on information transmitted in the direct communication accept message, including, for example, the public key of the receiving UE. Subsequent communications from the receiving UE can be decrypted based on the shared key. In some embodiments, generation of the shared key can be based on a security algorithm negotiated or otherwise known to both the initiating UE and the receiving UE.

[0108] Figure 8 An operational flow / algorithmic structure 800 in accordance with some embodiments can be included. The operational flow / algorithmic structure 800 can be used to establish a protected unicast link between two UEs via a relay UE.

[0109] In some embodiments, the operational flow / algorithmic structure 800 can be performed by an initiating UE (e.g., UE1 104), a receiving UE (e.g., UE2 112), or a component thereof (e.g., a baseband processor of the processor 704). For the purposes of this description, the operational flow / algorithmic structure 800 can be considered as being performed by the first UE.

[0110] The operational flow / algorithmic structure 800 can include determining a public key associated with a second UE at 804. In some embodiments, the public key can be generated by the second UE using security credential information configured to the second UE. The public key of the second UE can be transmitted to the first UE in a direct communication accept message as part of establishing a peer UE connection through a relay UE.

[0111] The operational flow / algorithmic structure 800 can also include determining a credential for an ECDH key agreement protocol at 808. In some embodiments, the first UE can determine the security credential based on configuration information provided to the first UE as part of a provisioning process. The provisioning process can include information transmitted to the first UE from a ProSe function of a network.

[0112] In some embodiments, the first UE can receive an indication of a plurality of security credentials supported by the second UE in a direct communication request message. In these embodiments, the first UE can determine which of the security credentials are also supported by the first UE, and if more than one, select one of the mutually supported security credentials. The selected security credential can be communicated back to the second UE.

[0113] The operational flow / algorithmic structure 800 can also include determining a shared key at 812. The first UE can determine the shared key using the security credential, the public key of the second UE, and a private key of the first UE.

[0114] The operational flow / algorithmic structure 800 can also include communicating with the second UE using the shared key at 716. The shared key can be used to encrypt communications sent to the second UE and to decrypt communications received from the second UE through the protected unicast link across the relay UE.

[0115] Figure 9 An operational flow / algorithmic structure 900 in accordance with some embodiments can be included. The operational flow / algorithmic structure 900 can be used to establish a protected unicast link between two UEs via a relay UE.

[0116] In some embodiments, the operational flow / algorithmic structure 900 can be performed by an initiating UE, such as UE1 104, or a component thereof (e.g., a baseband processor of the processor 704).

[0117] The operational flow / algorithmic structure 900 can include, at 904, transmitting a direct communication request message. The direct communication request message can be broadcast to initiate a peer discovery procedure. As described herein, the broadcast can include setting a destination address to a broadcast L-2 address.

[0118] The direct communication request message can include an indication of an ECDH key agreement protocol to be used to secure communications between the initiating UE and a receiving UE. The direct communication request message can also include a public key associated with the initiating UE. In some embodiments, the direct communication request message can also include a plurality of security credentials of the ECDH key agreement protocol supported by the initiating UE.

[0119] The operational flow / algorithmic structure 900 can also include, at 908, receiving a direct communication accept message. The direct communication accept message can include a public key associated with the receiving UE. In some embodiments, the direct communication accept message can also include an indication of a selected security credential to be used to generate a shared secret.

[0120] The operational flow / algorithmic structure 900 can also include, at 912, determining a shared secret. The shared secret can be determined based on the security credential, the public key of the receiving UE, and a private key of the initiating UE.

[0121] The operational flow / algorithmic structure 900 can also include, at 916, communicating based on the shared secret. The shared key can be used to encrypt communications sent to the receiving UE and to decrypt communications received from the receiving UE over a protected unicast link through a relay UE.

[0122] Figure 10 A UE 1000 is shown in accordance with some embodiments. The UE 1000 can be similar to any of the UEs of FIG. 1 and substantially interchangeable therewith. Figure 1

[0123] The UE 1000 can be a consumer electronic device, a cellular phone, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, a vehicle infotainment device (e.g., an infotainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a dashboard mobile equipment, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, etc.), an infrastructure device, a sensor, an embedded system, a microcontroller, a control module, a connected or (smart) appliance, an MTC device, an IoT device, etc.

[0124] ​The UE 1000 can include a processor 1004, RF interface circuitry 1008, memory / storage 1012, and a user interface 1016. The components of the UE 1000 can be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. Figure 10 The block diagram of FIG. 10 is intended to show a high-level view of certain ones of the components of the UE 1000. However, some of the components shown can be omitted in some embodiments, additional components can be present, and different arrangements of the components shown can occur in other embodiments.

[0125] The components of the UE 1000 can be coupled through one or more interconnects 1028, which can represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows the various circuit components (on common or different chips or chip sets) to interact.

[0126] The processor 1004 can include processing circuitry such as an application processor, a digital signal processor, a graphics processing unit, a central processing unit, and / or a baseband processor. The processor 1004 can execute or otherwise operate computer-executable instructions such as program code, software modules, and / or functional processes from the memory / storage 1012 to cause the UE 1000 to perform operations as described herein.

[0127] In some embodiments, the processor 1004 can access a communication protocol stack 1020 in the memory / storage 1012 to communicate over a SL or 3GPP-compatible network as described herein. In some embodiments, the processor 1004 can implement the communication protocol stack 1020 to perform one or more of the operations described with respect to Figures 2 to 5 the processes of FIG. 9, Figure 6 the protocol stack of FIG. 10, or Figures 7 to 9 the operational flow / algorithmic structures described with respect to FIG. 11. Generally, an application processor can access the communication protocol stack to perform APP layer functions, and a baseband processor can access the communication protocol stack to perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer, and control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and non-access stratum (NAS) layer. In some embodiments, PHY layer operations can additionally / alternatively be performed by components of the RF interface circuitry.

[0128] The baseband processor can generate or process baseband signals or waveforms carrying information in a sidelink or 3GPP-compatible network. In some embodiments, the waveform for LTE can be orthogonal frequency division multiplexing (OFDM) in the downlink and single carrier-frequency division multiple access (SC-FDMA) in the uplink. In NR, the waveform can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink. In LTE-Advanced (LTE-A), DFT-S-OFDM can be used for sidelink. In NR, CP-OFDM or DFT-S-OFDM can be used for sidelink.

[0129] The baseband processor can also access information in provisioned information 1024 in the memory / storage 1012 to establish a protected unicast channel through a relay. As described herein, the provisioned information 1024 can include security credentials and key information.

[0130] The memory / storage 1012 can include any type of volatile or nonvolatile memory usable to store information or data related to operational instructions or software, such as for the application server 1002. Volatile memory can require power to maintain its stored information or data, and nonvolatile memory can retain its stored information or data even after the loss of power. Examples of volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM). Examples of nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, solid state memory, or other appropriate memory devices.

[0131] The RF interface circuitry 1008 can include transceiver circuitry and radio frequency front module (RFEM) that allow UE 1000 to communicate with other devices over a radio access network. The RF interface circuitry 1008 can include various elements arranged in transmit or receive paths. These elements can include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0132] In the receive path, the RFEM can receive a radiated signal from the air interface via an antenna and continue to filter and amplify the signal (with a low noise amplifier). The signal can be provided to a receiver of the transceiver that down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 1004.

[0133] In the transmit path, a transmitter of the transceiver up-converts and filters the baseband processor's output signal to RF frequencies and provides a modulated RF signal to the RFEM. The RFEM amplifies the RF signal and provides the modulated RF signal via an antenna to the RF interface circuitry 1008.

[0134] In various embodiments, the RF interface circuitry 1008 can be configured to transmit / receive signals in a manner compatible with LTE or NR access technologies.

[0135] User circuitry 1016 includes various input / output (I / O) devices that are designed to enable user interaction with the UE 1000. User interface 1016 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for entering or providing input to the UE 1000. More specifically, input device circuitry includes one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, key pad, mouse, touch pad, touch screen, microphone, scanner, headset, etc. Output device circuitry includes any physical or virtual means for showing or communicating information (such as sensor readings, actuator positions, or other similar information) to the user. Output device circuitry can include any number and / or combination of audio or visual display, specifically including one or more simple visual outputs / indicators (e.g., binary status indicators such as light emitting diodes (LEDs)), multi-character visual outputs, or more complex outputs such as display devices or touch screens (e.g., liquid crystal displays (LCD), LED displays, quantum dot displays, projectors, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced from the operation of the UE 1000.

[0136] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled in a way to minimize risk of unintentional or unauthorized access or use of the data, and every effort should be made to ensure that authorization for the disclosure of certain data is clearly indicated.

[0137] For one or more embodiments, at least one of the components shown in one or more of the preceding figures can be configured to perform one or more operations, techniques, processes, and / or methods as described in the following Examples section. For example, the baseband circuitry described above in connection with one or more of the preceding figures can be configured to operate in accordance with one or more of the following examples. For another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the preceding figures can be configured to operate in accordance with one or more of the examples shown in the following Examples section.

[0138] Example

[0139] In the following sections, additional example embodiments are provided.

[0140] Example 1 can include a method of operating a source UE, the method comprising: accessing provisioning information to determine a cryptographic key pair associated with the source UE, the cryptographic key pair comprising a public key and a private key; broadcasting a direct communication request comprising the public key to trigger peer UE discovery; receiving a direct communication accept message from a target UE comprising a public key associated with the target UE; decrypting communications from the target UE based on the private key associated with the source UE; and encrypting communications to the target UE based on the public key associated with the target UE.

[0141] Example 2 can include the method of example one or some other example herein, wherein the method further comprises: transmitting the encrypted communications to the target UE over an end-to-end protected unicast link between the source UE and the target UE.

[0142] Example 3 can include the method of example 2 or some other example herein, wherein the end-to-end protected unicast link traverses a relay UE.

[0143] Example 4 can include the method of example 3 or some other example herein, wherein the method further comprises: generating a message having a source layer-2 identifier accessible to the relay UE to include the encrypted communications.

[0144] Example 5 can include the method of example one or some other example herein, further comprising: generating the direct communication request to include a list of supported security algorithms.

[0145] Example 6 can include the method of example 5 or some other example herein, further comprising: extracting from the direct communication accept message a security algorithm selected by the target UE from the list of supported security algorithms.

[0146] Example 7 can include the method of example 6 or some other example herein, further comprising: encrypting communications to the target UE based on the security algorithm; and transmitting the encrypted communications to the target UE over an end-to-end protected unicast link via a UE-to-UE relay.

[0147] Example 8 can include the method of example one or some other example herein, further comprising: generating the direct communication request to include an indication that an Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol is to be used to protect a unicast link between the source UE and the target UE.

[0148] Example 9 can include the method of example 8 or some other example herein, further comprising generating a shared key based on the ECDH key agreement protocol, the public key associated with the target UE, and the private key associated with the source UE; and encrypting communications to the target UE using the shared key.

[0149] Example 10 can include a method of operating a first UE, the method comprising storing a private key associated with the first UE and a security credential for an Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol; determining a public key associated with a second UE; and determining a shared key based on the security credential, the public key associated with the second UE, and the private key associated with the first UE.

[0150] Example 11 can include the method of example 11 or some other example herein, further comprising transmitting, to the second UE, a direct communication accept message with an indication of the public key associated with the first UE.

[0151] Example 12 can include the method of example 10 or some other example herein, wherein the first UE is a target UE, the second UE is a source UE, and the method further comprises receiving, from the source UE, a direct communication request including an indication of the public key associated with the source UE and an indication of the security credential.

[0152] Example 13 can include the method of example 12 or some other example herein, wherein the indication of the security credential is a credential identifier or name of the security credential.

[0153] Example 14 can include the method of example 13 or some other example herein, wherein the indication of the security credential is a credential identifier and the method further comprises receiving, from a proximity services function in a core network, provisioning information mapping one or more credential identifiers to corresponding one or more credentials; and determining, based on the provisioning information, that the credential identifier corresponds to the security credential.

[0154] Example 15 can include the method of example 12 or some other example herein, wherein the direct communication request includes an indication of a plurality of security credentials including the security credential and the method further comprises selecting the security credential based on the security credential being available at the first UE; and including, within a direct communication accept message, an indication of the selection of the security credential.

[0155] Example 16 can include the method of example 10 or some other example herein, wherein the first UE is a source UE, the second UE is a target UE, and the method further includes generating the direct communication request to include the public key associated with the first UE, and an indication that the ECDH key agreement protocol is to be used and an indication of the security credential; and transmitting the direct communication request to a relay UE.

[0156] Example 17 can include a method of operating a first UE, the method comprising: transmitting a direct communication request including a public key associated with the first UE and an indication that an Elliptic Curve Diffie Hellman (ECDH) key agreement protocol is to be used to establish a secure connection; receiving, from a second UE via a relay UE, a direct communication accept message including a public key associated with the second UE; and determining a shared secret based on the ECDH key agreement protocol and the public key associated with the second UE.

[0157] Example 18 can include the method of example 17 or some other example herein, further comprising generating the direct communication request to further include an indication of a security credential to be used with the ECDH key agreement protocol.

[0158] Example 19 can include the method of example 18 or some other example herein, wherein the indication is a name of the security credential or a credential identifier associated with the security credential.

[0159] Example 20 can include the method of example 17 or some other example herein, further comprising receiving configuration information to configure the first UE with only one security credential to be used with the ECDH key agreement protocol; and determining the shared secret using the one credential through the ECDH key agreement protocol.

[0160] Example 21 can include an apparatus comprising means for performing one or more elements of a method described in or related to any of examples 1-20, or any other method or process described herein.

[0161] Example 22 can include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-20, or any other method or process described herein.

[0162] Example 23 can include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-20, or any other method or process described herein.

[0163] Example 24 can include a method, technique, or process as described in or related to any of examples 1-20, or portions or parts thereof.

[0164] Example 25 can include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process as described in or related to any of examples 1-20, or portions thereof.

[0165] Example 26 can include a signal as described in or that supports carrying the

[0166] Example 27 can include a datagram, information element, packet, frame, segment, PDU, or message as described in or that supports carrying the

[0167] Example 28 can include a signal encoded with data as described in or that supports carrying the

[0168] Example 29 can include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or that supports carrying the

[0169] Example 30 can include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform a method, technique, or process as described in or related to any of examples 1-20, or portions thereof.

[0170] Example 31 can include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to perform a method, technique, or process as described in or related to any of examples 1-20, or portions thereof.

[0171] Example 32 can include a signal in a wireless network as shown and described herein.

[0172] Example 33 can include a method of communicating in a wireless network as shown and described herein.

[0173] Example 34 can include a system for providing wireless communication as shown and described herein.

[0174] Example 35 can include an apparatus for providing wireless communication as shown and described herein.

[0175] Any of the above examples can be combined with any other example (or combination of examples), unless otherwise expressly stated. The foregoing description of one or more implementations provides functionality and / or technical advantages, but that does not mean that every implementation necessarily makes use of every

[0176] Although the above implementations have been described in considerable detail, variations and modifications are possible to those skilled in the art once they fully understand the basic inventive concepts. The disclosure is intended to be broadly construed, and the following claims are intended to include all such variations and modifications.

Claims

1. One or more computer-readable media having instructions that, when executed by one or more processors, cause a source user equipment (UE) to: access provisioning information to determine a cryptographic key pair associated with the source UE, the cryptographic key pair comprising a public key and a private key; broadcast, by the source UE, a direct communication request comprising the public key to trigger a peer UE discovery; receive, from a target UE, a direct communication accept message comprising a public key associated with the target UE; decrypt, based on the private key associated with the source UE, a communication from the target UE; and encrypt, based on the public key associated with the target UE, a communication to the target UE.

2. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the source UE to: transmit, to the target UE, an encrypted communication over an end-to-end protected unicast link between the source UE and the target UE.

3. The one or more computer-readable media of claim 2, wherein the end-to-end protected unicast link traverses a relay UE.

4. The one or more computer-readable media of claim 3, further comprising: generating a message having a source layer-2 identifier accessible to the relay UE to include the encrypted communication.

5. The one or more computer-readable media of claim 1, wherein the instructions, when executed, further cause the source UE to: generate the direct communication request to include a list of supported security algorithms.

6. The one or more computer-readable media of claim 5, wherein the instructions, when executed, further cause the source UE to: extract, from the direct communication accept message, a security algorithm selected by the target UE from the list of supported security algorithms.

7. The one or more computer-readable media of claim 6, wherein the instructions, when executed, further cause the source UE to: encrypt, based on the security algorithm, a communication to the target UE; and transmit, to the target UE, an encrypted communication over an end-to-end protected unicast link via a UE-to-UE relay.

8. The one or more computer-readable media of any of claims 1-7, wherein the instructions, when executed, further cause the source UE to: generate the direct communication request to include an indication that an Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol is to be used to protect a unicast link between the source UE and the target UE.

9. The one or more computer-readable media of claim 8, wherein the instructions, when executed, further cause the source UE to: generate, based on the ECDH key agreement protocol, the public key associated with the target UE, and the private key associated with the source UE, a shared key; and encrypt, using the shared key, a communication to the target UE.

10. A first user equipment (UE) comprising: a memory circuit to store a private key associated with the first UE and a security credential for an Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol; and a processing circuit coupled with the memory circuit, the processing circuit to: determine, at the first UE, a public key associated with a second UE; and determine, at the first UE, a shared key based on the security credential, the public key associated with the second UE, and the private key associated with the first UE.

11. The first UE of claim 10, wherein the processing circuit is further to: transmit, to the second UE, a direct communication accept message with an indication of the public key associated with the first UE.

12. The first UE of claim 10 or 11, wherein the first UE is a target UE, the second UE is a source UE, and the processing circuit is further to: receive, from the source UE, a direct communication request including an indication of the public key associated with the source UE and an indication of the security credential.

13. The first UE of claim 12, wherein the indication of the security credential is a credential identifier or name of the security credential.

14. The first UE of claim 13, wherein the indication of the security credential is a credential identifier, and the processing circuit is further to: receive, from a proximity services function in a core network, provisioning information mapping one or more credential identifiers to a corresponding one or more credentials; and determine, based on the provisioning information, that the credential identifier corresponds to the security credential.

15. The first UE of claim 12, wherein the direct communication request includes an indication of a plurality of security credentials including the security credential, and the processing circuit is further to: select the security credential based on the security credential being available at the first UE; and include, within a direct communication accept message, an indication of the selection of the security credential.

16. The first UE of claim 10, wherein the first UE is a source UE, the second UE is a target UE, and the processing circuit is further to: generate a direct communication request to include the public key associated with the first UE, an indication that the ECDH key agreement protocol is to be used, and an indication of the security credential; and transmit the direct communication request to a relay UE.

17. A method of operating a first user equipment (UE), the method comprising: transmitting a direct communication request including a public key associated with the first UE and an indication that an Elliptic Curve Diffie Hellman (ECDH) key agreement protocol is to be used to establish a secure connection; receiving, from a second UE via a relay UE, a direct communication accept message including a public key associated with the second UE; and determining a shared secret based on the ECDH key agreement protocol and the public key associated with the second UE.

18. The method of claim 17, further comprising: generating the direct communication request to further include an indication of a security credential to be used with the ECDH key agreement protocol.

19. The method of claim 18, wherein the indication is a name of the security credential or a credential identifier associated with the security credential.

20. The method of any of claims 17-19, further comprising: receiving configuration information to configure the first UE with only one security credential to be used with the ECDH key agreement protocol; and determining the shared secret using the one credential through the ECDH key agreement protocol. ​

Images