Method for operating a cellular network

Abstract

The present invention relates to a method for operating a communications system, the method comprising the steps of: receiving a second discovery protection message from a first device protected with a second set of keys, the second discovery protection message including the first discovery message that has been protected end-to-end with the first set of keys according to a policy or configuration; using the second set of keys to unprotect the received second discovery protection message and verify its integrity and freshness, then extracting the protected first discovery message according to the policy or configuration; constructing a third discovery protection message including the first discovery protection message; protecting the third discovery message using the third set of keys according to the policy or configuration into a third discovery protection message; and transmitting the third discovery protection message to a third device.

Description

[Technical Field]

[0001] The present invention relates to the field of wireless communications, and in particular to security aspects in the context of cellular networks, such as UMTS Long Term Evolution (LTE) or LTE Advanced (both included in 4G), New Radio (NR) (5G), or other cellular or mobile in communication networks. [Background technology]

[0002] In a conventional cellular network, a primary station serves multiple secondary stations located within the cell served by the primary station. Wireless communication from the primary station to each secondary station occurs over a downlink channel. Conversely, wireless communication from each secondary station to the primary station occurs over an uplink channel. Wireless communication may include data traffic (sometimes referred to as user data) and control information (sometimes referred to as signaling). This control information typically includes information to assist the primary and / or secondary stations in exchanging data traffic (e.g., resource allocations / requests, physical transmission parameters, information about the status of each station).

[0003] In the context of cellular networks standardized by 3GPP, a primary station is referred to as a base station, a gNodeB (i.e., gNB) in 5G (NR), or an eNodeB (i.e., eNB) in 4G (LTE). The eNB / gNB is part of the radio access network RAN, which interfaces with functions in the core network (CN). In the same context, a secondary station corresponds to a mobile station, or to a user equipment (i.e., UE) in 4G / 5G, which is a wireless client device or a specific role played by such a device. The term "node" is also used to refer to either a UE or a gNB / eNB.

[0004] Furthermore, direct communication between secondary stations, here UEs, is possible, for example, in the case of PC5 interface or sidelink communication. A UE can also act as a relay, for example, to enable an out-of-coverage UE to gain an intermediate (or indirect) connection to an eNB or gNB. To be able to act as a relay, the UE uses discovery messages to establish new connections with other UEs.

[0005] Therefore, the role of a relay node, as shown in FIG. 1, has been introduced in 3GPP. This relay node 120 is a wireless communication station 120 that includes functionality for relaying communications between a primary station 100, e.g., a gNB, and a secondary station 110, e.g., a UE. This relay function allows, for example, extending the coverage of a cell 10 to an out-of-coverage (OoC) secondary station 110. This relay node 120 can be a mobile station or a different type of device. In the 4G specifications, proximity services (ProSe) functionality is defined, particularly in TS 23.303 and TS 24.334, to enable, for example, connectivity for cellular user equipment (UE) 110 that is temporarily outside the coverage of a cellular network base station (eNB) 100 serving the cell 10. This specific functionality is called ProSe UE-to-Network Relay, or relay UE for short. The relay UE 120 relays application and network traffic in two directions between the OoC UE 110 and the eNB 100. Local communication between the relay UE 120 and the Ooc UE ​​110 is referred to in TS23.303 and TS24.334 as device-to-device (D2D) communication or sidelink communication (also known as PC5). Once a relay relationship is established, the Ooc UE ​​110 is IP connected, for example, through the relay UE 120, and assumes the role of a "remote UE" 110. This situation means that the remote UE has indirect network connectivity to selected functions of the core network, as opposed to direct network connectivity to all core network functions in the normal case.

[0006] Furthermore, the role of an inter-UE relay node is introduced, i.e., a relay node that relays communication between two UE devices, as shown in Figure 3, where a relay node 310 relays communication between a UE device 320 and a UE device 330. When in coverage, the UEs 310, 320, and 330 connect to the core network through a base station 300. Summary of the Invention [Problem to be solved by the invention]

[0007] In general, it is difficult to determine how UEs communicating through UE-to-network or UE-to-UE relays can discover each other in a secure manner or establish secure communications.

[0008] One object of the present invention is to alleviate the above-mentioned problems.

[0009] Another object of the present invention is to better protect discovery messages and security establishment in relay scenarios when using joint discovery or when dealing with integrity failures in the initial steps of establishing communication. Yet another object of the present invention is to provide a better and more secure route switching when using an inter-UE relay, i.e., to improve the way in which two UE devices can switch inter-UE relays securely and privately.

[0010] Yet another object of the invention is to propose a method for a secondary station to communicate in a network, the operation of which requires minimal interaction with the core network. [Means for solving the problem]

[0011] In various aspects of the present invention, several modifications of the security routines are proposed to operationalize the security routines and improve security / privacy protection and performance.

[0012] To achieve this, in a first aspect of the present invention, an apparatus for securely relaying discovery messages is proposed, as claimed in claim 1.

[0013] In a second aspect of the present invention, a method for securely relaying discovery messages is proposed, as claimed in claim 17.

[0014] In a third aspect of the present invention, an apparatus for secure communication, as claimed in claim 18, and a corresponding method for operating the apparatus, as claimed in claim 54, are proposed.

[0015] In a fourth aspect of the present invention, an apparatus for secure communication, as claimed in claim 22, and a corresponding method for operating the apparatus, as claimed in claim 53, are proposed.

[0016] In a fifth aspect of the present invention, there is proposed an apparatus for securely establishing PC5 or sidelink communications, as claimed in claim 27, and a corresponding method for operating the apparatus, as claimed in claim 52.

[0017] In a sixth aspect of the present invention, an apparatus for secure communication, as claimed in claim 37, and a corresponding method for operating the apparatus, as claimed in claim 44, are proposed.

[0018] In a seventh aspect of the present invention, an apparatus for secure and efficient communication is proposed, as claimed in claim 46.

[0019] In an eighth aspect of the present invention, a method for secure communication is proposed, as claimed in claim 50.

[0020] In a ninth aspect of the present invention, there is proposed a computer program product comprising code means for bringing about the steps of the methods of the first to eighth aspects of the present invention when said program product is executed on a computing device.

[0021] It should be noted that the above apparatus may be implemented based on separate hardware circuits having separate hardware components, integrated chips, or chip module arrangements, or based on signal processing devices or chips controlled by software routines or programs stored in memory, written to a computer-readable medium, or downloaded from a network such as the Internet.

[0022] It will be understood that the device and the method have similar, corresponding and / or identical preferred embodiments, particularly as defined in the dependent claims.

[0023] It will be understood that a preferred embodiment of the invention may also be any combination of the dependent claims or the above embodiments with the respective independent claim.

[0024] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0025] It should be noted that the above apparatus may be implemented based on discrete hardware circuits, integrated chips, or chip module arrangements, or based on signal processing devices or chips controlled by software routines or programs stored in memory, written on computer-readable media, or downloaded from a network such as the Internet.

[0026] It will be understood that the apparatus according to claims 1 and 2, the communication device according to claim 11, the method according to claims 13 and 14, the computer program product according to claim 15, and the system according to claim 16 have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0027] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagrammatic representation of a cellular system, already mentioned, in which the present invention is implemented; [Figure 2] FIG. 1 is a diagram illustrating a procedure for joint discovery in UE-to-UE relay communication. [Figure 3] FIG. 1 illustrates schematically the discovery process in a UE-to-UE relaying scenario. [Figure 4] FIG. 10 is a diagram illustrating a procedure for setting up security for a PC5 communication link in a UE-to-UE relaying scenario. [Figure 5] FIG. 2 is a diagram schematically illustrating another cellular system in which the present invention may be implemented. [Figure 6] FIG. 10 is a diagram illustrating a further embodiment of the present invention relating to UE-to-UE joint discovery. [Figure 7] FIG. 10 illustrates a schematic representation of a further embodiment of the present invention relating to UE-UE discovery. [Figure 8] FIG. 10 illustrates a schematic representation of a further embodiment of the present invention relating to UE-UE discovery. [Figure 9] FIG. 10 illustrates a schematic representation of a further embodiment of the present invention relating to UE-UE discovery. [Figure 10] FIG. 10 illustrates a schematic diagram of a procedure for setting up a secure PC5 communication link with joint discovery over UE-to-UE relays. [Figure 11]

[0023] FIG. 10 illustrates schematically a procedure for setting up a secure PC5 communication link with joint discovery over UE-to-UE relay or directly with a source UE. [Figure 12]

[0023] Figure 1 illustrates a schematic diagram of Model A discovery with UE-to-UE relay announcement scheduling assistance for end UEs. [Figure 13] FIG. 10 is a diagram illustrating a schematic of Model A discovery using UE-to-UE relay with on-demand direct discovery set protection. DETAILED DESCRIPTION OF THE INVENTION

[0029] Various aspects of the present invention are detailed in the following embodiments. As detailed above, embodiments of the present invention can relate to various types of wireless communications, and in particular to connection setup of devices attempting to access a wireless network. A typical example is a cellular network, such as a 5G network, possibly including several relay nodes. These relay nodes are implemented by UEs, such as sidelink-compatible UEs, capable of acting as relay nodes, or by other types of repeaters.

[0030] To enable new connections through this type of relay, a discovery phase is required in which discovery messages are sent to or by the relay UE. One of the general objectives of this particular exemplary embodiment is to increase the protection of such discovery messages. Section 6.1.3.4.3 of Technical Specification TS33.303 V17.0.0 describes the protection of discovery messages. It lists three types of security used to protect restricted discovery messages, which are detailed as follows:

[0031] First, as in Open Discovery (see subsection 6.1.3.3.1), integrity protection is provided by appending a Message Identification Code (MIC), which is calculated at the sending UE using the received Discovery User Integrity Key (DUIK) and checked at the receiving UE using the supplied DUIK, or at the ProSe function (relay node) using the DUIK.

[0032] The second is scrambling protection, which ensures that there is no correlation between discovery messages sent by a particular UE, i.e., prevents tracking of the UE over time. A scrambling key stream is calculated from the Discovery User Scrambling Key (DUSK) and a UTC-based counter associated with the discovery slot (see 6.1.3.4.3.5 for calculation details).

[0033] Finally, there is message-specific confidentiality, which provides confidentiality protection for parts of a discovery message. This is used when several UEs use the same DUSK, or when it is desired to obfuscate parts of discovery messages from a subset of UEs that are allowed to discover UEs. A keystream is calculated from the Discovery User Confidentiality Key (DUCK), the message contents, and a UTC-based counter associated with the discovery slot (see 6.1.3.4.3.6 for calculation details).

[0034] The security procedures applied to the transmitting and receiving UEs are controlled by the ProSe function by sending code transmit security parameters and / or code receive security parameters to the appropriate UEs (i.e., the UE assists in all integrity protection, scrambling, and message-specific confidentiality). To achieve integrity protection for ProSe restricted discovery messages, either DUSK or DUIK needs to be provided. If DUCK is used to apply message-specific confidentiality, then DUIK is required for integrity protection since multiple messages are being protected. Examples of discovery user key combinations depending on the type of use case are provided in Annex G.

[0035] In the present invention, the terms "security keying material," "key material," "discovery security parameters," or "security keys / material," and "key set" are used interchangeably and refer to the same set of keys (e.g., discovery keys) including DUIK, DUSK, and DUCK.

[0036] At the receiver, scrambling protection must be removed before any matching is attempted. Given the computationally intensive nature of the operation to remove message-specific confidentiality, the prior matching operation should have a very minimal chance of producing a false positive. To achieve this, the ProSe function should ensure that the number of bits in the discovery message that can be matched after any scrambling is removed is at least 16 (resulting in a false positive probability of 1 in 65,536 or less).

[0037] Technical Specification TS33.503 describes further procedures for protecting discovery messages, where the discovery messages are characterized by their long size. Discovery procedures are also specified in the context of UE-to-network relaying. The main differences with TS33.303 refer to the use of scrambling on up to the first 32 bytes, confidentiality protection of the entire message, and the use of a MIC pair for the random value if the message is not integrity protected.

[0038] Furthermore, section 6.3.5 of TS33.503 describes the procedure for protection of the Direct Communication Request (DCR) message sent by a remote UE to a UE-to-network relay, where the protection mechanism reuses discovery keys. If DUIK is configured, the DCR message is integrity protected. If DUCK or DUSK is configured, the Relay Service Code (RSC) or PRUK-ID is confidentially protected.

[0039] During discovery, referring to FIG. 4, a similar technique applies to establishing a (secure) PC5 communication link in a UE-to-UE relay scenario. In FIG. 4, a UE, e.g., a source UE, sends a Direct Communication Request (DCR) message containing certain parameters, such as the RSC, PRUK ID, or first nonce, used for subsequent key derivation. This information is exchanged in plain text unless procedures such as section 6.3.5 of TS33.503 apply. This procedure and necessity is further indicated by a source UE 420 wishing to establish a secure communication link with a target UE 430 through a UE-to-UE relay 410. The CN, or one or more network functions of the CN 400, performs the setup. In a first step, the remote UEs (source UE and target UE) and the UE-to-UE relay obtain discovery parameters and a ProSe Key Management Function (PKMF) address from the 5G DDNMF, and discovery security material from the PKMF, respectively. Furthermore, the remote UE may be provided with security material for end-to-end security setup via the PKMF. For example, security materials for end-to-end security setup include a ProSe Service Code (PSC) and associated keys. In subsequent steps, the remote UE 420 (i) discovers the UE-to-UE relay, (ii) sends a direct communication request including a relay service code (RSC), a PRUK ID, and nonce 1, and (iii) performs the discovery procedure and PC5 unicast link setup procedure with the UE-to-UE relay 410 by performing authentication and key agreement between the remote UE 420 and the UE-to-UE relay 410, with the key KNRP being derived as a result of successful authentication. The UE-to-UE relay 410 then generates nonce 2 and derives KNRP-SESS using KNRP, nonce 1, and nonce 2. The UE-to-UE relay 410 sends a direct security mode command including nonce 2 to the remote UE 420. The direct security mode command is integrity protected based on KNRP-SESS. The remote UE 410 then derives KNRP-SESS using KNRP, nonce 1, and nonce 2 to check the integrity of the direct security mode command. If the verification is successful, the remote UE 420 sends a direct security mode complete to the UE-to-UE relay 410.For example, as detailed in the exemplary procedure above, to protect certain privacy-sensitive fields or all fields in the DCR message exchange during UE-to-UE relay, one of the keys in the discovery parameters needs to be selected by the transmitting device and the receiving device, e.g. 1. If DUCK is available, it will be used to protect privacy-sensitive fields. 2. If DUCK is unavailable and DUSK is available, DUSK will be used to protect them, otherwise, 3. If neither DUCK nor DUSK is available, privacy-sensitive fields or all fields in the DCR message must be unprotected.

[0040] Once a key is selected (if a key is selected), the sending device can protect the DCR message and send the protected DCR message. Once a key is selected (if a key is selected), the receiving device can receive the protected DCR message and process it securely (decrypt / integrity verify). Note that if the source UE and target UE have a common discovery key set that is unknown to the relay, this set of keys is preferred.

[0041] The embodiments will be described in the context of a UE relay, which allows, for example, an out-of-coverage remote UE to connect to a network. This type of relay is referred to as a UE-to-network relay or U2N relay, etc. A UE relay also allows two end UEs to communicate with each other. This type of relay is referred to as a UE-to-UE relay or U2U relay, etc. End UEs are referred to as a source UE and a target UE, etc. Different peer UEs perform a discovery procedure to find each other and / or send initial communication messages to establish a secure link. For example, a remote UE and a UE-to-network relay discover each other, and then the remote UE sends a direct communication request to the UE-to-network relay. For example, a UE-to-UE relay and two end UEs desire to discover each other, and then one of the end UEs sends a direct communication request to initiate the establishment of a PC5 communication link.

[0042] Throughout this disclosure, the following acronyms have the following definitions:

[0043] KDF is an abbreviation for Key Derivation Function. KDF is defined, for example, in Appendix B.2 of TS33.220 v18.0.0. In this example, the KDF for an input bit string S with key K, i.e., KDF(K,S), is equivalent to HMAC-SHA-256(K,S), where SHA-256 is the hash function used in the HMAC construction. The bit string S is constructed from multiple parameters param1, param2, ..., paramN, as described in TS33.220, concatenated with an assigned length and including a unique identifier, denoted FC, for the specific use of the KDF. It should be understood that sometimes, instead of writing KDF(K,S), it is written as KDF(K,param1,param2,...,paramN), where the bit string S is constructed from fields param1, param2, ..., paramN.

[0044] NEA and NIA: These are the encryption (NEA) and integrity algorithms (NIA). In 5G implementations, these are described in appendices D.2 and D.3 of TS33.501.

[0045] DUSK, DUCK, and DUIK: These refer to the respective keys used for scrambling, encoding, and integrity, respectively. In 5G discovery embodiments, these refer to the discovery user scrambling key, discovery user encoding key, and discovery user integrity key, respectively.

[0046] DP_X-Y: These correspond to some security discovery parameters, e.g. keying material used between entity X and entity Y, e.g. DP_S-UE-to-UE means the discovery security parameters associated with the RSC used between the source UE and the UE-to-UE relay.

[0047] Scrambling / Confidentiality / Integrity Protection Routines for Discovery Messages in UE-to-UE Relay Scenarios In the following embodiments and variants relating to "UE-to-UE" relaying, a use case is presented in which a source user equipment (UE) device needs or desires to communicate with a target UE device through a UE-to-UE relay device. This UE-to-UE relaying use case involves at least two phases: (secure) discovery and (secure) PC5 communication link establishment. These two phases present specific challenges that have already been addressed in some of the above embodiments.

[0048] Regarding the (secure) discovery of UEs (source UE, UE-to-UE relay, target UE), certain architectural solutions require "hop-by-hop" and "end-to-end" discovery. For example, a discovery message sent by a source UE and destined for a target UE (e.g., an advertisement discovery message in Discovery Model A or a solicitation discovery message in Discovery Model B) is (1) first protected with discovery parameters associated with the end-to-end communication link between the source UE and the target UE, where these discovery parameters (DP_S-T) include a DUIK, a DUSK, or a DUCK. Next, the discovery message is (2) second protected with discovery parameters associated with the hop-by-hop communication link between the source UE and the UE-to-UE relay (DP_s-UEtoUE). These parameters also include a DUIK, a DUSK, and a DUCK. When the UE-to-UE relay receives the message, the UE processes the message, where the processing involves security processing of the discovery message using DP_s-UEtoUE. After processing, the UE-to-UE relay can check whether the discovery message is intended for its UE-to-UE relay service by performing a matching operation, such as in TS33.503. If so, the UE-to-UE relay protects the message with a discovery parameter (DP_UEtoUE-T) that is associated with the hop-by-hop communication link between the UE-to-UE relay and the target UE. When the target UE receives the message, it processes the message, where the processing involves (1) security processing of the discovery message using DP_UEtoUE-T, and then (2) security processing of the discovery message using DP_S-T.

[0049] In the supplementary explanation, the security procedure of 5G ProSe UE-to-UE relay discovery model A is described as follows with reference to FIG. 3.

[0050] 3, by performing a relay discovery key request procedure, the announcing UE 320 is provided with discovery security material from the CN 300, e.g., a network function of the 5G PKMF. The discovery security material includes two sets of code transmission security parameters: code transmission security parameters associated with the ProSe service and code transmission security parameters associated with the relay service code (RSC). In addition, a CURRENT_TIME parameter and a MAX_OFFSET parameter are included for each set of code transmission security parameters.

[0051] 3, by performing a relay discovery key request procedure, the ProSe 5G inter-UE relay 310 is provided with discovery security material from the network function of the CN 300. The discovery security material includes both code transmission security parameters and code reception security parameters associated with the RSC. In addition, a CURRENT_TIME parameter and a MAX_OFFSET parameter are included for each set of security parameters.

[0052] 3, by performing a relay discovery key request procedure, the monitoring UE 330 is provided with discovery security material from the network function of the CN 300. The discovery security material includes two sets of code reception security parameters: code reception security parameters associated with the ProSe service and code reception security parameters associated with the RSC. In addition, a CURRENT_TIME parameter and a MAX_OFFSET parameter are included for each set of security parameters.

[0053] 3, if the system-provided UTC-based counter associated with the discovery slot is within the MAX_OFFSET of the announcing UE's ProSe clock and the validity timer has not expired, the announcing UE may start broadcasting an announcement message. The announcing UE may form and protect the announcement message as follows: First, the announcing UE protects the end-to-end (E2E) ProSe discovery information with the code transmission security parameters associated with the ProSe service, and then protects the announcement message with the code transmission security parameters associated with the RSC.

[0054] In step 360 of FIG. 3 , if the UTC-based counter associated with the discovery slot is within the MAX_OFFSET of the ProSe clock of the ProSe 5G inter-UE relay, the ProSe 5G inter-UE relay listens for an announcement message that matches its discovery filter. The ProSe 5G inter-UE relay processes the received announcement message to find a matching message for its discovery filter. When the ProSe 5G inter-UE relay processes the message, it cancels protection of the received message using the code reception security parameter associated with the RSC. Upon identifying a matching message, the ProSe 5G inter-UE relay forms a relayed announcement message that includes the original announcement message and protects the relayed announcement message using the code transmission security parameter associated with the RSC. The ProSe 5G inter-UE relay then starts broadcasting the relayed announcement message.

[0055] In step 370 of Figure 3, the monitoring UE listens to the announcement message relayed from the ProSe 5G UE-to-UE relay. The monitoring UE processes the received relayed announcement message to find a matching message for its discovery filter. When the monitoring UE processes the message, it first revokes protection of the message using the code reception security parameter associated with the RSC, and further revokes protection of the E2E ProSe discovery information using the code reception security parameter associated with the ProSe service.

[0056] In Figure 3, the message in step 350 includes a discovery message type, discoverer information, RSC in an INVITE message, and E2E discovery information. In Figure 3, the message in step 360 includes a discovery message type, discoverer information (i.e., relay user information ID), RSC, relay instruction (to indicate PRoSe direct discovery forwarding), original discoverer information (i.e., source 5G ProSe U2U UE user information ID), and E2E discovery information. Therefore, the message in step 360 includes additional information, including discoverer information, i.e., relay user information ID, and relay instruction.

[0057] In Model A discovery, the source UE is called the announcing UE and the target UE is the monitoring UE, or vice versa. In Model B discovery, the source UE is called the discoverer UE and the target UE is the discovering UE.

[0058] In Model B discovery, the message flow is as in Figure 3, where messages 350 and 360 correspond to the invite message and relayed invite message, and the additional messages sent back by 330 through 310 to 320 correspond to the reply message and relayed reply message.

[0059] The above procedure requires a first consideration: when the source UE protects the message with a DP_S-T that is bound to the end-to-end communication link between the source UE and the target UE, this security processing of the discovery message involves scrambling the first part of the message, e.g., the first 32 bytes of the message. If that is done, the UE-to-UE relay cannot check whether this discovery message is intended for its UE-to-UE relay service, e.g., because certain fields have been scrambled.

[0060] Therefore, in an alternative embodiment, the source UE and target UE must not be configured with a DUSK for the DP_S-T that is associated with the end-to-end communication link between the source UE and the target UE. Since there is no DUSK, no scrambling occurs.

[0061] Therefore, in an alternative embodiment, the source and target UEs and the inter-UE relay must be configured with the same DUSK of DP_S-T and DP_S-UE-2-UE. Because the DUSK is the same, the relay UEs can descramble messages.

[0062] Therefore, in another alternative embodiment, the source UE and the UE-to-UE relay must be configured with a policy that determines that the DUSK of the DP_S-T must not be used for scrambling when the DP_S-T associated with the end-to-end communication link between the source UE and the target UE is used in the context of a UE-to-UE relay discovery procedure.

[0063] Therefore, in another alternative embodiment, the source UE and target UE must be configured with a mask that determines which parts of the message are scrambled with the scrambling key of DP_S-T. Once this is done, the UE-to-UE relay can still unscramble messages with DP_S-UE-2-UE and filter valid messages. For example: Scrambled_message = message XOR((0xFFFF||mask) AND time hash bit sequence).

[0064] For example, the masking is such that fields such as message type and RSC are not masked by the source UE, but fields such as discovery information or end-to-end discovery information of the transmitting device (eg, source UE) are masked.

[0065] Therefore, in another alternative embodiment, the source and target UEs must be configured with a mask that is equal to or derived from the mask used in the confidentiality protection.

[0066] The above procedure requires a second consideration: when the source UE protects the message with a DP_S-T that is associated with the end-to-end communication link between the source UE and the target UE, this first security processing of the discovery message involves adding a first MIC calculated with a first DUIK of the DP_S-T. When the source UE protects the message with a DP_S-UE-to-UE that is associated with the hop-by-hop communication link between the source UE and the UE-to-UE relay, this second security processing of the discovery message requires adding a second MIC calculated with a second DUIK of the DP_S-UE-to-UE.

[0067] Therefore, in another variant, the discovery message has two MICs.

[0068] Thus, in another variant, the discovery message includes two timing values, e.g., the least significant bits of UTC time, a first timing value used with a first MIC and a second timing value used with a second MIC.

[0069] Furthermore, in another variant, the accuracy of the first timing value used for the first MIC for end-to-end communication is less than the accuracy of the second timing value used for the second MIC for hop-by-hop (e.g., relay to target UE) communication. For example, the first timing value is such that a time difference of 2 seconds is tolerated, while the second timing value is such that a difference of 1 second is tolerated. This variant increases the reliability of the protocol. This is also applicable to cases where an inter-UE relay caches messages received from a source UE and continues to rebroadcast them, because the accuracy of the first timing value can be made equal to the relay's cached time value.

[0070] Note that if the first and second timing values ​​refer to several bits of a UTC-based counter, saying that the first timing value is less accurate is equivalent to saying that the first timing value refers to the accuracy of the lowest bit of the UTC-based counter. For example, assume that the entire UTC-based counter is 16 bits long and has an accuracy of one second. For example, assume a UTC-based counter value that is 0x1234 in hexadecimal or 0001 0010 0011 0100 in binary, with the most significant bit on the left and the least significant bit on the right, with an increment of one indicating one second later. In this example, the four least significant bits are 0100 (bits 3-0), providing an accuracy of one second. Because it contains information about the four least significant bits, it can correct an error of up to eight seconds (or even 16 seconds). Assume that four bits of the UTC-based counter are transmitted, corresponding to bits 4-1, i.e., 1010, as in the example above. This timing value has an accuracy of 2 seconds, since the lowest bit has an accuracy of 2 seconds, i.e. this timing value is less accurate. This timing value can correct for an error of up to 16 seconds (possibly 32 seconds).

[0071] Furthermore, in another variant embodiment, UTC time is used to scramble / unscramble messages. According to TS33.503 and TS33.303 (section 6.1.3.4.3.5), the four LSBs of the UTC-based counter are set to 0 for this operation. For example, if an inter-UE relay introduces high processing or caching times (more than 8 seconds) and more than four LSBs of the UTC-based counter are transmitted, this may be insufficient or inefficient (because, as mentioned above, when more than four LSBs are transmitted, the value remains valid for a longer period depending on the index of the most significant bit transmitted). Therefore, the scrambling procedure in TS33.503 / TS33.303 is modified to set x LSBs to 0 when scrambling the Direct Discovery Set exchanged between end UEs, where x is, for example, 5, 6, ... This ensures that the end receiving device can unscramble the message, access the integrity-protected message, minimize the amount of resources required, and therefore proceed with decoding and integrity verification. For example, if the inter-UE relay caches the discovery message for 32 seconds, the end UE advantageously sets at least the six LSBs of the end-to-end UTC-based counter to 0. This variant is configurable (e.g., depending on the ProSe application / code or the RSC used). The absolute / relative value x is also exchanged in the discovery message itself. Note that this variant is similar to using a less accurate UTC-based counter for protecting end-to-end messages (protected by DP_S-T) compared to the UTC-based counter used for protecting discovery messages between end UEs (source UE and target UE) and the inter-UE relay. Note that the effect of this variant is similar to using a less accurate UTC-based counter for protecting end-to-end messages (protected by DP_S-T) compared to the UTC-based counter used for protecting discovery messages between end UEs (source UE and target UE) and the UE-to-UE relay. Note that the effect of this variant is similar to the fact that DUSK of the end-to-end security parameter (DP_S-T) need not be used since it allows unscrambling of the message, and subsequent decoding / integrity verification.This variant embodiment is applicable, for example, to steps 2 and 4 of the security procedure in section 6.1.3.3.3.1 for 5G ProSe UE-to-UE relay discovery with model A, or steps 1, 2, 3, and 4 of section 6.1.3.3.3.2 of draft CR for TS33.503 (TDoc S3-233374).

[0072] In a further related variant embodiment, if the timing values ​​(LSBs of the UTC-based counter) are different or have different accuracy, then those different timing values ​​are also used in the confidentiality and / or scrambling sequences, which allows the relay to cache the discovery messages and retain them for a longer period of time, allowing the target UE to receive them and successfully decode / unscramble them for a longer period of time.

[0073] In a further related embodiment, the second timing value corresponds to the x least significant bits of the UTC-based counter (e.g., bits 0,...,x-1), and the first timing value includes a y subset of those bits (e.g., bits 1,...,y), or the following y bits (e.g., bits x-1,...,x+y-1). This allows a larger time difference to be resolved with fewer bits. In other words, a message can remain valid for a longer period of time while requiring fewer bits to be transmitted.

[0074] In a further embodiment, the second timing value is the four or eight LSBs of the UTC-based counter, i.e., bits 0-3 and bits 0-7, respectively. Furthermore, the first timing value includes bits 5-8 or bits 8-15 of the UTC-based counter. In other words, overlap may occur between the timing values. This approach to constructing the first timing value ensures that the first timing value can be used to correct the time difference between the source UE and the target UE for a longer period (longer validity time) without the need to transmit additional bits. This longer period, determined by the number of LSB bits of the UTC-based counter, and specifically the most significant bit of the transmitted UTC-based counter, determines the validity time of the message. For example, if the first timing value references bits 0-7 of the UTC-based counter, where bit 7 is the most significant bit, the message is valid for approximately 2^{7} seconds. For example, if the first timing value references bits 4-7 of the UTC-based counter, the message is also valid for approximately 2^{7} seconds.

[0075] In a further variation of the above embodiment, the timing values ​​have some overlapping bits, e.g., the first timing value is the four LSBs of the UTC-based counter and the second timing value is the eight LSBs of the UTC-based counter. When the source UE transmits the protected discovery message to the UE-to-UE relay, the overlapping bits do not need to be transmitted twice. For example, in the above example, eight bits need to be transmitted for both timing values ​​due to the overlap between them. When the UE-to-UE relay forwards / transmits the protected discovery message to the target UE, the UE-to-UE relay includes only the first timing value, which in the above example includes only the eight LSBs of the UTC-based counter.

[0076] In a further variant related to the previous embodiment, the first timing value comprises (a part of) the second timing value.

[0077] In a further variation related to the above embodiment, both timing values ​​are included at the beginning of the discovery message. In yet another variation, since the least significant bits of the first timing value of the UTC-based counter are absent, those bits are set to a predetermined value (e.g., all 0s or all 1s) when using the complete reconstructed UTC-based counter in a cryptographic function such as a KDF. For example, if the source UE transmitter's UTC-based counter is T3, T2, T1, T0, and T0 is not transmitted but T1 is, the target UE receiver uses the received T1 to modify its own UTC-based counters T3', T2', T1', T0'. In either case, when the UTC-based counter is used, for example, in computing a MIC or generating a pseudorandom bitstream for encryption purposes, the LSBs of the UTC-based counters (i.e., T0 and T0') are set to a predetermined value, for example, all 0s (e.g., 0x00 if T0 and T0' are one byte long).

[0078] In a further embodiment, the meaning of the timing value (e.g., the first timing value) and / or the correction value for the (untransmitted) LSB is determined by policy or pre-configured in software in the UE.

[0079] In a related embodiment, one of the timing values, e.g., the first timing value, is an absolute time value so that freshness checks at the destination are based on absolute time, thereby avoiding problems, for example, when a relay caches discovery messages.

[0080] In a related embodiment, if the timing value is an absolute time value, one or more of the integrity / confidentiality / scrambling routines use only the LSBs of said absolute time value (e.g., UTC time) as input in generating a MIC or pseudo-random sequence (used for confidentiality by XORing it with the plaintext discovery message).

[0081] In a further related embodiment, if the timing value for end-to-end communication is valid for T seconds, a discovery message arrives at a relay with latency L, and then the relay retransmits it for TL seconds. For example, T is determined from the number of bits in a UTC-based counter or the index of the most significant bit of a UTC-based counter. L is a configuration parameter that determines, for example, that a discovery message should be transmitted at least L seconds before the message validity expires or a MIC-based freshness check is no longer valid.

[0082] In a further related embodiment, if the timing value for end-to-end communication is valid for T seconds, and a discovery message arrives at the relay at time t, then the relay will retransmit until time t+T delta, where delta is a configurable safety time window to ensure that the destination UE can successfully process the received discovery message. The value of T depends on the accuracy of the received timing value. Delta depends on the safety window to ensure that the message can be successfully verified at the receiving end.

[0083] In further related embodiments, discovery parameters, such as cache time, range / accuracy of timing values, discovery keys to use, and / or other parameters, are determined by policy, and these parameters are linked to application codes, such as discovery codes, relay service codes, or ProSe codes.

[0084] In a further embodiment, if it is desired to further optimize the UE-UE discovery procedure, redundant encryption / integrity protection is avoided by configuring only the preferred key. Redundant encryption means that if the RSC is only used for ProSe services, there is no need to apply encryption on the end-to-end link and hop-by-hop link. However, ProSe codes and relay service codes are not mapped to each other, which hinders flexibility. Specifically, for a given ProSe application, - when a first ProSe application performs direct discovery, all keys (DUSK, DUCK, DUIK) are configured with the discovery key associated with the (ProSe code of) said ProSe application; - when a first ProSe application performs UE-UE discovery through an UE-UE relay used by a second ProSe application, all keys (DUSK, DUCK, DUIK) are configured with a discovery key associated with (the ProSe code of) said ProSe application; - When a first ProSe application performs UE-to-UE discovery through a UE-to-UE relay used by a second ProSe application, it is desirable that the keys (DUSK, DUCK, DUIK) are not configured with a discovery key associated with the ProSe application (its ProSe code), and only the keys (DUSK2, DUCK2, DUIK2) associated with the relay service code are configured.

[0085] To achieve this, in a variant, the UE is configured with a ProSe code that contains an indication of the associated RSC for performing UE-to-UE discovery, and this association indicates whether the RSC is shared with other ProSe codes (ProSe application or not).

[0086] In a related variation, the ProSe code used for UE-to-UE discovery includes or is associated with two sets of keys, the first set of keys being used for direct discovery protection as described in other embodiments, and the second set of keys being used for full protection of UE-to-UE discovery messages.

[0087] In a related variation, the ProSe code includes an indicator that determines whether the ProSe code is used for direct discovery (associated with a single set of discovery keys) or UE-to-UE discovery (associated with two sets of discovery keys).

[0088] In a related variation, the UE selects a ProSe code depending on whether the UE is performing direct discovery or UE-to-UE discovery, and the type of code to use is determined based on the discovery messages sent and received.

[0089] In further related embodiments, the UE discovery parameters are optimized for performance, e.g. - if the relay UE can cache the discovery message for time T, the source UE only needs to send the discovery message every T seconds, and the timing value is such that the corresponding time error can be eliminated; - If the relay UE can cache the discovery message for time T, then the source UE is only required to send the discovery message every T seconds, the transmission time complying with a strategy to reduce errors, e.g. by transmitting when the current time t modulo T is equal to 0 or T / 2.

[0090] Thus, in another variant, the discovery message includes a single timing value, e.g., the least significant bits of the UTC time, and the same timing value is used in the calculation of both the first and second MICs. This UTC value is the UTC value of the source UE. Upon receiving the message, e.g., at 350 in FIG. 3, the UE-to-UE relay processes the message with the end-to-end security parameters, including verifying the second MIC. The UE-to-UE relay integrity protects the discovery message with the DP_UE-to-UE-T third DUIK by using the same UTC value in the received message to calculate a third MIC without updating or setting the UTC counter value in the transmitted message. This variant allows for bandwidth savings.

[0091] In some cases, a source UE wishes to communicate with multiple N target UEs. In this case, in a further embodiment, some parameters of the discovery message as defined in TS33.503 are reused in the calculation for each of the target UEs, e.g. a single timing value is used for the calculation of multiple MICs, where each MIC is MIC k, for k=1,...,N, for end-to-end protection between the source UE and the target UE. This has the advantage of reducing the size of the discovery message.

[0092] Therefore, in another alternative embodiment, both the first and second MICs are included at the beginning of the discovery message, which requires specific changes in TS33.503 and TS33.303.

[0093] For example, section 6.1.3.2.3 of TS33.503 requires that when a UE protects a discovery message with a first set of keys, e.g., when the source UE protects the discovery message with a DP_S-T that is bound to the end-to-end communication link between the source UE and the target UE, step 3 of section 6.1.3.4.3.5 of TS33.303[4] be XOR(0xFFFF|| time hash bit sequence) with the most significant (L+16) bits of the discovery message. Clause 6.1.3.2.3 of TS33.503 requires that when the UE protects the discovery message with a second set of keys, for example, when the source UE protects the discovery message in a DP_S-UE-to-UE where the source UE is associated with an end-to-end communication link between the source UE and the UE-to-UE relay, step 3 of clause 6.1.3.4.3.5 of TS33.303[4] must be XOR(0xFFFF||time hash bit sequence) with the most significant (L+16+16) bits of the discovery message. In this case, time hash bit sequence 2 is 16 bits longer than time hash bit sequence 1.

[0094] For example, Section 6.1.3.2.3 of TS33.503 requires that the time hash bit sequence keystream of A.5 of TS33.303[4] be set to the L+16 least significant bits of the output of the KDF, where L is the bit length of the discovery message scrambled and set to Min(length of discovery message - 16,256).

[0095] For example, Section 6.1.3.2.3 of TS33.503 requires that the time hash bit sequence keystream of A.5 of TS33.303[4] be set to the variable-sized, e.g., L or L+16, least significant bits of the output of the KDF, where L is the bit length of the discovery message scrambled and set to Min(length of discovery message - 16,256).

[0096] For example, clause 6.1.3.2.3 of TS33.503 requires that step 3 of clause 6.1.3.4.3.5 of TS33.303[4], when the UE protects the discovery message with a second set of keys, e.g., when the source UE protects the discovery message in a DP_S-UE-to-UE that is associated with an end-to-end communication link between the source UE and the UE-to-UE relay, be XOR(0xFFFFFFFF||time hash bit sequence) with the most significant (L+16+16) bits of the discovery message, where L is the bit length of the discovery message that is scrambled and set to Min(length of discovery message-16,256).

[0097] Therefore, in another variant, after the first security processing, a second MIC is calculated over the entire message, ie the second MIC also involves integrity protection of the first MIC.

[0098] In another embodiment, the second discovery protection message includes two MICs (an end-to-end MIC calculated on DP_S-T and a hop-by-hop MIC calculated on DP_S-UE-to-UE), and the third discovery protection message includes a single MIC.

[0099] In a further related embodiment, this single MIC for the third protection (discovery) message is computed as the XOR of the end-to-end MIC between the source UE and target UE (computed in DP_S-T) and the hop-by-hop MIC between the UE-to-UE relay and the target UE (computed in DP_UE-to-UE-T). This is feasible because the UE-to-UE relay can compute this second hop-by-hop MIC and use it to XOR the received end-to-end MIC for the second discovery protection message, which becomes the MIC for the third discovery protection message. The target UE can first compute this hop-by-hop MIC and "subtract" its contribution from the received MIC for the third discovery protection message to again obtain the end-to-end MIC, allowing the target UE to verify both hop-by-hop and end-to-end integrity. The target UE can then verify this end-to-end MIC normally. This is advantageous because it reduces communication overhead while still providing both end-to-end and hop-by-hop security.

[0100] In some use cases, a source UE desires to communicate with multiple N target UEs (target_1, target_2, ..., target_N). For example, according to TR 23.700-33, for UE-to-UE relay model A discovery, there is a description of the discovery message type, UE-to-UE relay discovery message, where a list of UE-to-UE relay user information IDs, RSCs, and / or target UE user information IDs are included in the announcement message. This requires further consideration of how such messages should be protected.

[0101] In a further embodiment, the source UE protects the contents of the discovery message as follows. 1. Discover at most N different sets of keying material DP_S-T, where i=1,...,N i N (source UE to target UE) signals to be transmitted to N different target UEs having i Protect the discovery message (fields in the message) as follows: · Protection of each of these discovery messages from source UE to target UE is performed as per TS33.503 so that protected discovery messages are returned. The source UE extracts the parts of the protected discovery messages that correspond to the fields that need to be exchanged, thereby reducing the size of the discovery messages to be sent. For example, if there are two target UEs, two discovery messages (from source UE to target UE) are first formed and constructed, including, for example, timing values ​​(e.g., the LSBs of a UTC-based counter). However, these timing values ​​are removed, as a single value common to both discovery messages needs to be transmitted. 2. Assemble the discovery message (from source UE to UE-to-UE relay) with (the selected protection fields of) N discovery protection messages (from source UE to target UE). Assembly is done by joining. · The N discovery protection messages (from source UE to target UE) are carried, for example, in the metadata field of a discovery message (from UE-to-UE relay source UE to UE-to-UE relay). Assembling is done by creating a header for the discovery message (UE-to-UE relay source UE to UE-to-UE relay) and appending / attaching / inserting N discovery protection messages (source UE to target UE) (or selected fields from them). The selected protected fields are, for example, N MICs or confidentiality protected user information IDs. 3. Protect discovery messages (UE-to-UE relay source UE to UE-to-UE relay) with discovery keying material DP_S-UE-to-UE as per TS33.503. In this case, the first timing value associated with the discovery protection message (from the source UE to the target UE) is greater than the second timing value associated with the discovery protection message (from the UE-to-UE relay source UE to the UE-to-UE relay). In this case, only the first timing value needs to be transmitted, and the second timing value is a subset of the first timing value (e.g., the LSBs). 4. Send the discovery and protection message to the UE-to-UE relay.

[0102] 7 and 8 illustrate potential message structures for the above embodiment (and other embodiments of the present application), specifically illustrating a UE-to-UE discovery message between a source UE and a UE-to-UE relay. In these figures, the first field is the message type, then a timing value (UTC-based time), then a MIC, then UE information (e.g., source UE or UE-to-UE relay information), and then a payload field (e.g., a metadata field). In FIG. 7, the end-to-end discovery message between the source UE and the target UE is encapsulated / transmitted as generated after applying TS33.503 security routines to protect the end-to-end discovery message. In FIG. 8, only selected fields of the protected end-to-end discovery message between the source UE and the target UE are encapsulated / transmitted to reduce communication overhead.

[0103] In a further embodiment, the UE-to-UE relay receives the contents of the above-mentioned discovery protection message as follows. - Secure the incoming discovery message mentioned above (UE-to-UE relay source UE to UE-to-UE relay) with discovery keying material DP_S-UE-to-UE. - Extract (fields of) N protection discovery messages (from source UE to target UE). - (Re)assemble (if necessary) N protected discovery messages (from source UE to target UE). For example, if a timing value is reused for N protected discovery messages, then that timing value should be re-introduced where necessary. In general, if a protected discovery message (from source UE to target UE) contains two fields (Fa, Fb), where Fa is a field that is common to multiple discovery messages (from source UE to target UE), and there are a total of N (e.g., N=3) discovery messages (from source UE to target UE), then (Fa, Fb-1, Fb-2, Fb-3) will be received and N=3 discovery messages (from source UE to target UE) will be reassembled as (Fa, Fb-1), (Fa, Fb-2), (Fa, Fb-3). Note that, as mentioned above, (Fa, Fb-1, Fb-2, Fb-3) are what are transported, for example, in the metadata field of the discovery message (from the UE-to-UE relay source UE to the UE-to-UE relay).

[0104] In a further embodiment, the inter-UE relay caches the discovery message (from source UE to target UE) for a given time, e.g., a given time set in a policy. The inter-UE relay stores and forwards the discovery message. For example, the given time depends on the freshness value / requirements / timing values ​​of the discovery message (from source UE to target UE). For example, if the discovery message (from source UE to target UE) contains b LSBs of a UTC-based timer, the inter-UE relay may cache the discovery message for up to approximately 2 b Unit time (maximum 2 if the time unit is 1 second) b seconds), the UE-to-UE relay caches / retains / stores / transmits / broadcasts the discovery message (from source UE to target UE). At the end of this time, the UE-to-UE relay deletes the received / stored discovery message and / or requests a new discovery message. The action taken (e.g., how long to delete / store the message) is based on the configuration / policy.

[0105] Note that if the b=4 LSBs of a UTC-based timer are 1111, but the receiving device is slightly out of sync (say 1 second ahead) and its b=4 LSBs of the UTC-based timer are already 0000, then this time validity is still slightly less than 2^b bits, as there will be time synchronization issues due to the later bits already changing. Therefore, from this perspective, it is safer to consider accuracy and time validity to be 2^{b-1} time units.

[0106] To illustrate this, we can describe a possible routine for harmonizing counters a and c, considering a small desynchronization of up to 2^k time units by transmitting the m=k+1 least significant bits. Assume ABS(aC)<2^k, where a and c are two counters, and (c) returns the absolute value of the integer value c. We can further write ABS(a1×2^m-+a0-c1×2^m-c0)=ABS((a1-c1)×2^m-+a0-c0)<2^k, where a1 and c1 refer to the most significant bits of a and c starting from bit m, and a0 and c0 refer to the m least significant bits. For m=k+1, if abs(a0-c0)>2^k, then (a1-c1) cannot be equal to 0, and therefore the most significant bits of the counters are different and need to be corrected / harmonized as well. If device A has counter a, device C has counter c, and device A receives c0 from C, device A can reconcile its counters so that one of C's matches by doing the following: If ABS(a0-c0)<2^k, A can keep a1 and replace a0 with the received c0, and the harmonized counter obtained by A is therefore a1|c0, where | denotes concatenation. ·When ABS(a0 - c0) ≥ 2^k, device A needs to modify a1 to a1’ by adding 1 (i.e., a1’ = a1 + 1 when a0 > c0) or subtracting 1 (i.e., a1’ = a1 - 1 when a0 < c0), and then replacing a0 with the received c0. Thus, the reconciled counter becomes a1’|c0, where | represents concatenation. This algorithm enables the reconciliation of two counter values a and c by considering the exchange of m = k + 1 least significant bits (LSBs) of one of the counters when the difference between the counters is 2^k in absolute value. Note that since a can be at most 2^k time units less or more than c, it covers a total time range of 2^m time units. Therefore, the maximum correctable time difference is 2^(m - 1), and thus this is the maximum time validity of the received LSBs in a deterministic / error - free manner. As described in other (variant) embodiments, this requires exchanging the first timing value associated with the end - to - end exchanged data (between end UEs) and corresponding to the LSBs of a UTC - based counter having more bits than the timing values associated with hop - by - hop communication (between an end UE and a UE - to - UE relay).

[0107] When the time difference between the LSBs is greater than 2^k, the receiving UE A attempts to replace its own LSB (a0) of its own counter with the LSB (c0) received from C. For example, if A has a0 = 0x1 (0001) as the LSB and receives 0xB (1011), the difference between the values is 0xA, i.e., 1010. However, since there is no overflow to the MSB, the exchange works and A can still reconcile the counter. Since this strategy sometimes works (i.e., this approach is probabilistic), the receiver can reconcile m bits with m = k + 1 received counters.

[0108] The above harmonic procedure assumes that two devices A and C can have errors distributed around the median value, and thus the harmonic procedure functions when the time difference is at most 2^k. If m is larger, for example, needs to be 8 bits, the error between counter a and counter b is small, for example, is expected to be at most 2^3, and the above procedure is not ideal as it only allows a correction time difference of 2^7. The following alternative harmonic procedure addresses this problem, - the definition of an offset value related to the maximum possible absolute time error, for example, offset = 2^3, and - the transmitting device C with counter c’ adds offset / 2 to c’, obtaining c = c’ + offset / 2, - the transmitting device transmits c0, c = c1×2^m + c0, - the receiving device A with counter a’ adds offset / 2 to a’, obtaining a = a’ + offset / 2 = a1×2^m + a0, - in this situation, · If ABS(a0 - c0) < offset, A can keep a1 as it is and replace a0 with the received c0. Thus, the harmonized counter obtained by A is a1|c0, where | represents concatenation. Finally, A corrects the added offset / 2 value and obtains a1|c0 - offset / 2 as the corrected counter. · If ABS(a0 - c0) ≥ offset, the device A needs to correct a1 to a1” by adding 1 (when a0 > c0), i.e., a1” = a1 + 1, or subtracting 1 (when a0 < c0), i.e., a1” = a1 - 1, and then replacing a0 with the received c0. Thus, the harmonized counter becomes a1”|c0, where | represents concatenation. Finally, A corrects the added offset / 2 value and obtains a”1|c0 - offset / 2 as the corrected counter. - This algorithm makes it possible to reconcile two counter values ​​a and c, taking into account the exchange of m LSBs of one of the counters when the difference between them is 2^{k} in absolute value, achieving a time validity of 2^m-2^k instead of 2^{m-1}. This algorithm is required to unify / match the offset values ​​that A and C need to use.

[0109] In a further variant embodiment, two devices communicating with each other have a specified time counter reconciliation algorithm (e.g., as described above) that is used by the receiving UE (e.g., a UE-to-UE relay) to deterministically match / reconcile its own time counter with the time counter value of the sensing UE (e.g., an end UE such as a source UE).

[0110] In a further embodiment, the UE-to-UE relay forwards / rebroadcasts each discovery message (from source UE to target UE) once the discovery message has been protected using the corresponding discovery key parameter DP_UE-to-UE-T according to the procedures of TS33.503. In this case, these discovery and protection messages (from source UE to target UE) can be transmitted all together or individually, e.g. · The N discovery protected messages (from source UE to target UE) are transmitted in a single message protected with the discovery key parameter DP_UE-to-UE-T. · The N discovery protected messages (from source UE to target UE) are transmitted in N messages protected with the discovery key parameter DP_UE-to-UE-T. In this case, the first timing value used to protect the discovery message (from the source UE to the target UE) is greater than the second timing value used to protect the discovery message (from the UE-to-UE relay to the target UE). In this case, both the first and second timing values ​​need to be transmitted.

[0111] In a further embodiment, the discovery message (from source UE to target UE), the discovery message (from source UE to UE-to-UE relay), the discovery message (from UE-to-UE relay to target UE), the discovery message (from target UE to UE-to-UE relay), or the discovery message (from UE-to-UE to source UE) - the number N of discovery and protection messages to be carried (from source UE to target UE); - the size of the parameters used (e.g. the size of the timing values), - How the message (fields) are assembled / organized, - what protections apply; It contains one or more fields that explicitly or implicitly indicate

[0112] In a further embodiment, instead of using a UTC-based counter, a nonce is used to avoid issues arising from the store-and-forward functionality of the UE-to-UE relay.

[0113] In a further embodiment, one or more target UEs (or source UEs) transmit one or more discovery protection messages to an inter-UE relay that performs discovery message storage, aggregation, and / or forwarding functions before transmitting the discovery protection messages to the source UE (or target UEs). - The processing of the discovery protection message coming from the target UE (or source UE) is similar to that described in the previous embodiment. The inter-UE relay collects different target UE messages (or source UE messages) into a container message over time, for example at time t1 when a first target UE (or source UE) sends a first message and at time t2 when a second target UE (or source UE) sends a second message. This is shown in Figure 9, where the inter-UE relay sends a discovery protection message including the first message received at t1, and upon receiving the second discovery protection message, the inter-UE relay starts sending a new discovery protection message including both the first and second discovery protection messages received from the first target UE (or source UE) and second target UE (or source UE). - The inter-UE relay relays / caches messages for the Max_cache_time_period determined by the policy / configuration. Furthermore, it is considered that the validity time of the discovery protection message from source UE to target UE, i.e. S-UE-T-UE validity time, should ideally always be greater than the maximum cache period (Max_cache_time_period), otherwise relaying of the discovery protection message (in the container) will be interrupted as the validity time from source UE to target UE expires. - The Inter-UE relay sets a timer to track the freshness of the source UE to target UE discovery protection message and to concatenate / remove the source UE to target UE message from the container discovery message (i.e., the Inter-UE to source UE discovery message) when a source UE to target UE discovery protection message is received and / or when the current source UE to target UE discovery protection message in the container expires. The UE-to-UE relay calculates a new MIC each time the container discovery message is updated.

[0114] In a further embodiment, the UE-to-UE relay is configured with a strategy to determine how end-to-end discovery protection messages between a given source UE / target UE are delivered / protected, e.g. with which pairs of DP_S-UE-to-UE and / or DP_UE-to-UE-T.

[0115] In further embodiments, the messages shown in Figures 7, 8 and 9 implicitly or explicitly determine one or more of the following via new / existing message fields: - Number of end-to-end discovery protection messages carried / encapsulated / exchanged - the identity of the source UE and / or target UE, so that an inter-UE relay can properly deliver and / or protect the message;

[0116] The above procedure requires a third consideration: when the source UE protects messages with a DP_S-T that is associated with the end-to-end communication link between the source UE and the target UE, this first security processing of the discovery message involves confidentiality protecting messages with the first DUCK of the DP_S-T. When the source UE protects messages with a DP_S-UE-to-UE that is associated with the hop-by-hop communication link between the source UE and the UE relay, this second security processing of the discovery message involves confidentiality protecting messages with the second DUCK of the DP_S-UE-to-UE. These operations are redundant.

[0117] Therefore, in another alternative embodiment, the source UE and the UE-to-UE relay may not be configured with a DP_S-UE-to-UE DUCK associated with the hop-by-hop communication link between the source UE and the UE-to-UE relay.

[0118] Therefore, in another alternative embodiment, the source UE and the UE-to-UE relay must be configured with a strategy to determine that when the DP_S-UE-to-UE associated hop-by-hop communication link between the source UE and the UE-to-UE relay is used in the context of a UE-to-UE relay discovery procedure, the DP_S-UE-to-UE DUCK must not be used for confidentiality protection.

[0119] Thus, in other alternative embodiments, the policy is configured by a network function of the CN300, for example, a 5G PKMF.

[0120] Therefore, in another alternative embodiment, the source UE and the UE-to-UE relay must be configured with a strategy to determine that when the DP_S-UE-to-UE associated with the hop-by-hop communication link between the source UE and the UE-to-UE is used in the context of a UE-to-UE relay discovery procedure, if the DP_S-T includes a DUCK and the DUCK is used to confidentially protect discovery messages end-to-end, then the DUCK of the DP_S-UE-to-UE must not be used for confidentiality protection.

[0121] In another variant embodiment, which may be combined with other embodiments or used independently, the source UE and the target UE have a set of discovery keys bound to ProSe service Y and use those keys when the source UE and the target UE communicate with each other directly. A source UE and a target UE that want to communicate with each other for the same ProSe service Y through a given UE-to-UE relay use different sets of keys that are bound to end-to-end discovery messages between the source UE and the target UE and hop-by-hop security (from the source UE to the UE-to-UE relay and from the UE-to-UE relay to the target UE). This allows the source UE and the target UE to use different sets of keys for the same ProSe service depending on how they communicate with each other directly or indirectly. This means that the end UEs (source UE and target UE) are configured with different ProSe service identifiers (and corresponding keys) corresponding to the same ProSe service Y depending on whether the ProSe service is established directly or through a UE-to-UE relay. When one of the end UEs (e.g., source UE) wants to directly discover other UEs (e.g., target UEs) for a given ProSe service, the first end UE uses the ProSe service identifier / key for direct discovery. When an end UE wants to indirectly discover other UEs, the end UE uses the ProSe service identifier / key for indirect discovery (through an inter-UE relay). In the second case, the direct discovery set (for ProSe services) is protected by DUCK1 / DUSK1 / DUIK1, and the discovery messages are protected by DUCK2 / DUSK2 / DUIK2. Depending on whether the inter-UE relay provides two or more ProSe services, some of the keys are not configured. For example, if the relay provides only a single ProSe service, DUCK1, DUSK1, and DUIK1 are not available, and protection relies only on DUCK2 / DUSK2 / DUIK2.In this embodiment, when an end UE (e.g., source UE / target UE) transmits a discovery message for a given ProSe service, the end UE selects a ProSe service ID and discovery key parameters depending on whether the discovery message reaches another end UE directly (direct discovery) or indirectly (UE-UE discovery), which is determined by a policy. The policy is configured by the core network, for example, when the discovery key parameters are defined / configured.

[0122] In another embodiment similar to the other embodiments for joint discovery, and which may be combined with other embodiments or used independently, a source UE and a target UE that wish to communicate with each other through or indirectly with a given UE-to-UE relay for ProSe service Y use a set of keys that are bound to end-to-end discovery messages between the source UE and the target UE, and a set of keys that are bound to hop-by-hop security (from the source UE / target UE to the UE-to-UE relay). Since discovery messages sent by the source UE reach the target UE directly or indirectly, - if the discovery message indicates whether it is a first hop message (from source UE to UE-to-UE relay) or a second hop message (from UE-to-UE relay to target UE); - if this indication is protected by end-to-end discovery key parameters and / or hop-by-hop discovery key parameters, It makes sense if this direct discovery set is not encrypted with discovery key parameters for hop-by-hop security, which allows the target UE to directly access the protected direct discovery set and saves computational resources.

[0123] Specifically, if the target UE determines that the discovery message reaches the target UE directly, it ignores the protection related to hop-by-hop security protection (e.g., MIC calculated with discovery key parameters for relay services) and only performs security processing of the direct discovery set with end-to-end discovery key parameters for ProSe services. The target UE makes this determination based on some of the fields in the discovery message, such as the L2 address or relay instruction.

[0124] The above procedure requires a fourth consideration, namely the increased configuration complexity of having two sets of discovery key parameters, eg, DP_S-T and DP_S-UE-to-UE.

[0125] Therefore, in another alternative embodiment, the source UE is required to use DUIK and DUCK DP_S-T and then DUIK and DUSK DP_S-UE-to-UE, by requiring one or more of the following actions at the transmitting source UE: Step 1 in section 6.1.3.4.3.2 of unmodified TS33.303; Step 2 in TS 33.303, section 6.1.3.4.3.2, to calculate the first MIC using DUIK DP_S-T as defined in TS 33.503, section 6.1.3.2.3; Step 3 in TS33.303 section 6.1.3.4.3.2 to add message confidentiality using DUCK of DP_S-T as defined in TS33.503 section 6.1.3.2.3; Step 4 in TS 33.303 clause 6.1.3.4.3.2 for calculating the second MIC using the DP_S-UE-to-UE DUIK as defined in TS 33.503 clause 6.1.3.2.3; and Step 5 in TS33.303 clause 6.1.3.4.3.2 to scramble the message by using DP_S-UE-to-UE DUSK as defined in TS33.503 clause 6.1.3.2.3.

[0126] Therefore, in another alternative embodiment, the target UE performs the opposite of the above steps.

[0127] Therefore, in another embodiment, the UE-to-UE relay only performs the opposite actions with respect to steps 5 and 4: Step 4 in TS 33.303 clause 6.1.3.4.3.2 for calculating the second MIC using the DP_UE-to-UE-T DUIK as defined in TS 33.503 clause 6.1.3.2.3; and Step 5 in TS33.303 clause 6.1.3.4.3.2 to scramble messages by using DP_UE-to-UE-T DUSK as defined in TS33.503 clause 6.1.3.2.3 The second hop-by-hop discovery key parameter is used as the second hop-by-hop discovery key parameter to re-perform those actions.

[0128] Step 4 is specifically optional.

[0129] In some options, it may be desirable to reuse the security routines of TS33.303 clause 6.1.3.4.3 and TS33.503 clause 6.1.3.2.3 to protect direct discovery sets (as discovery messages) and to protect UE-UE discovery messages (including direct discovery protection sets) using the same security routines. However, as shown in the previous procedure, when protecting direct discovery sets, it is not required to protect the direct discovery sets as discovery messages, e.g., it is not required to include headers so that some steps in those clauses are skipped.

[0130] In a variant, steps of the security routine are rearranged / removed (e.g., as in the procedure above) to avoid double invocation of the overall security routine (section 6.1.3.2.3 of TS33.503), i.e., once to protect the direct protection set as a direct discovery protection message, and again to protect the UE-to-UE discovery message (including the direct discovery protection message) to generate the UE-to-UE discovery protection message.

[0131] In a variant, step 1 of clause 6.1.3.4.3.2 of TS 33.303, which is based on clause 6.1.3.2.3 of TS 33.503, is not performed to protect the direct protection set, for example as described in the previous embodiment.

[0132] In a variant, step 5 of clause 6.1.3.4.3.2 of TS 33.303 based on clause 6.1.3.2.3 of TS 33.503 is not performed to protect the direct protection set, for example as described in the previous embodiment.

[0133] In some options, UE-to-UE discovery messages transport specific fields whose protection depends on the application. For example, to allow a passive eavesdropper to identify the message, or for lawful interception reasons, it may be advantageous to allow the application to protect or not protect those fields. However, the routines in TS33.503, section 6.1.3.2.3, keystream = output_keystream AND (Encrypted_bits_mask||0xFF FF) =output_keystream AND (Encrypted_bits_mask||EBM') This protects the majority of the message as determined by A.7 of TS33.503.

[0134] Therefore, in a variant, A.7 of TS33.503 is modified to replace EBM'=0xFF...FF with a bit string that sets to 0 the bits that do not need to be protected, for example the bits corresponding to the user information ID.

[0135] In an additional embodiment, taking into account that the direct discovery set is not a discovery message but is protected as a whole, the length parameter of the message-specific confidentiality mechanism for discovery defined in A.7 of TS33.503 is: Length: LEN(discovery message) - (LEN(LSB of UTC-based counter) + LEN(MIC)) where LEN(x) is the length in bits x, so simply discarding LEN(message type) is inappropriate for direct discovery sets.

[0136] The above embodiment requires further consideration for some cases. The relayed discovery message includes multiple fields, including discovery message type, counter, MIC, discoverer information (i.e., relay user information ID), RSC, relay indication (to indicate PRoSe direct discovery forwarding), original discoverer information (i.e., source 5G ProSe U2U UE user information ID), NCGI, or E2E discovery information. According to TS24.554, the aggregated length is greater than 32 bytes, and therefore the scrambling procedure in TS33.503, which is limited to 32 bytes, is insufficient. To address this issue, the above-mentioned technique, which can protect more than 32 bytes, can be applied to scramble UE-to-UE relay messages.

[0137] The above embodiments require further consideration for some cases, namely, that it is advantageous to have end-to-end security (i.e., from source UE to target UE) for some security properties (e.g., confidentiality or integrity) and hop-by-hop security (i.e., from source UE to UE-to-UE relay and from UE-to-UE relay to target UE) for other security properties (e.g., integrity or confidentiality).

[0138] Thus, in a related embodiment, the discovery message is confidentiality protected with a key associated with DP_S-T, and the discovery message is integrity protected with a key related to DP_UE-to-UE-T and DP_S-UE-toUE.

[0139] Thus, in a related embodiment, the device is configured with a strategy for determining which keys for which discovery parameters are used to protect discovery messages sent through UE-to-UE relays.

[0140] Thus, in a related embodiment, a device is configured with a strategy for determining which keys for which discovery parameters are used to protect discovery messages sent through UE-to-UE relays when the security routines of TS33.503 are applied in conjunction with the set of end-to-end discovery parameters and the set of hop-by-hop discovery parameters.

[0141] Thus, in related embodiments, devices are configured with strategies to determine how end-to-end and hop-by-hop messages are protected, e.g., which keys are used for hop-by-hop or end-to-end confidentiality, in which messages a single MIC or two MICs are used, whether a single counter value is reused or two counter values ​​are transmitted for end-to-end and hop-by-hop messages, etc.

[0142] In related embodiments, the strategies / configurations also relate to the UTC-based counter, such as its accuracy, the number of transmitted LSBs of the UTC-based counter, the number of LSBs of the UTC-based counter that are set to 0 when scrambling / unscrambling, etc.

[0143] In a further embodiment, the inter-UE relay is configured with a strategy such that the inter-UE relay is configured only to receive and forward protection discovery messages without decrypting or computing a MIC, which has the advantage of reducing computational resource consumption at the inter-UE relay. In a variation of this embodiment, if the source UE, target UE, and UE-to-UE relay share the same discovery parameters DP_S-UE-to-UE and DP_UE-to-UE-T, the discovery message sent by the source UE includes, for example, two MICs: a second MIC calculated with DP_S-UE-to-UE and a first MIC calculated with DP_S-T. Upon receiving the discovery message, the UE-to-UE relay checks whether the verification of the second MIC can be successfully verified in light of the received message and the received UTC-based counter. If the verification of the second MIC is successful, the UE-to-UE relay simply forwards the message. The UE-to-UE relay also stores the message for a certain period of time and forwards it at a later point in time, as long as the verification of the second MIC is successful. This is particularly true if both the first MIC and the second MIC are calculated using the same UTC-based counter. In a variation of this embodiment, if the inter-UE relay's verification of the second MIC is successful, taking into account the received message and the received UTC-based counter, the inter-UE relay forwards the message without the second MIC, i.e., with only the first MIC calculated with DP_S-T. The inter-UE relay also stores the message for a certain time and forwards it at a later point in time, as long as the verification of the second MIC is successful.

[0144] In a further embodiment, the UE-to-UE relay is configured to receive the discovery message, verify the MIC calculated with a second set of discovery parameters (e.g., DP_S-UE-to-UE or DP_UE-to-UE-T), and determine the entire UTC-based counter if the verification is successful. The UE-to-UE relay is then allowed to forward the message as long as a time window allows. This time window may be based on a strategy or on a parameter (time window parameter) included in the received discovery message itself. The time window may be absolute or relative to the UTC-based counter used to verify the freshness of the second MIC, e.g., it indicates a drift. This time window determines how long the first MIC (calculated with DP_S-T) can be correctly verified, taking into account the UTC-based counter associated with the first MIC.

[0145] In one scenario, the UE-to-UE relay receives a UE-to-UE discovery message bound to RSC1, for example, according to Model A, as described in the previous embodiment. The UE-to-UE relay extracts the protected end-to-end discovery message (protected direct discovery set) and stores it as long as the protected end-to-end discovery message (protected direct discovery set) is valid. The UE-to-UE relay then transmits the protected end-to-end discovery message of the UE-to-UE discovery message to the target UE by using RSC2. RSC1 and RSC2 are bound to discovery keying material. RSC1 and RSC2 are bound to a security indicator that determines whether the PC5 security procedure is with network assistance. When the UE-to-UE relay receives the UE-to-UE discovery message bound to RSC1, the UE-to-UE relay is in-coverage (or out-of-coverage) and RSC1 is bound to the PC5 security procedure with (or without) network assistance, so the UE-to-UE relay can match RSC1. However, after storing the protected direct discovery set, when preparing to transmit a UE-UE discovery message, the coverage status of the UE-UE relay may have changed. Therefore, a method is needed to determine which RSC to use in the discovery procedure and how to notify the end UE. To achieve this, the following embodiment can be applied.

[0146] In a further variant embodiment, the UE-to-UE relay is adapted or configured (e.g. with a policy) to store the RSC (and the corresponding indication regarding the type of PC5 security procedure it is associated with) following the end-to-end protection discovery message / direct discovery set, wherein the UE-to-UE relay is configured with the policy to use the same RSC when sending subsequent discovery messages to the target UE, thereby indicating the same type of PC5 security procedure to be used. This further implies that the UE-to-UE relay will not forward / transmit a particular direct discovery set that no longer satisfies the network coverage situation of the UE-to-UE relay, even if it previously matched.

[0147] In a further variant embodiment, the inter-UE relay is adapted or configured (e.g. with a strategy) to check its coverage state before relaying the discovery message (advertisement discovery message in model A / solicitation discovery message in model B) to the target end UE, so that if the coverage state of the inter-UE relay has changed since the time of receiving the discovery message (e.g. moving from in-coverage to out-of-coverage or vice versa), a different RSC, e.g. RSC2, associated with the security procedures corresponding to the new coverage state is used in the second hop-by-hop link instead of the original RSC, e.g. RSC1, received in the discovery message from the source UE.

[0148] In another variant embodiment, if the coverage conditions of the UE-to-UE relay change over time, the UE-to-UE relay receives a discovery message from the source end UE and the time at which the UE-to-UE relay relays the discovery message to the target end UE, and selects an RSC for the relayed discovery message, e.g., RSC2, associated with a security procedure different from the security procedure associated with the RSC, RSC1, included in the discovery message received from the source end UE. The UE-to-UE relay indicates to the source end UE a discrepancy between the security procedures to be used and / or the cause (e.g., a change in coverage conditions).

[0149] In another variant embodiment, changes in the coverage state of the UE-to-UE relay affect its decision to accept or not accept a discovery message. For example, the UE-to-UE relay is out of coverage and receives a discovery message containing RSC1 associated with a PC5 security procedure with network assistance. Even if the UE-to-UE relay is unable to handle the discovery message at the time of receipt, the UE-to-UE relay needs to store the protected end-to-end discovery message / direct discovery set and RSC1 next to the validity time. The UE-to-UE relay then checks its coverage state at the time of transmission of the UE-to-UE discovery message to determine whether the message matches and therefore whether the message should be transmitted.

[0150] In another variant embodiment, a change in the coverage state of a UE-to-UE relay influences its decision to relay a discovery message (announcement discovery message in Model A / solicitation discovery message in Model B) and cause the UE-to-UE relay to drop the discovery message, for example, if the UE-to-UE relay has not been provided with an RSC and / or a long-term certificate corresponding to its new coverage state (e.g., in the out-of-coverage case). In certain scenarios, an out-of-coverage UE (e.g., UE-to-UE relay) can estimate / predict when and where it will move into 3GPP coverage based on timing and location information of a mobile access device, such as a vehicle-mounted relay, a non-terrestrial network, or a base station mounted on a UAV. The timing and location information can be deployed in the device. For example, according to one of the conclusions of KI#7 of TR 23.700-05, information (e.g., length of time and location information) can be deployed along with CAG identifiers for mobile base station repeaters (MBSRs) that the UE can access. Similarly, according to section 7.3.1.6 of TR38.821, ephemeris information and UE location information can be used to assist the UE in making measurements and cell selection / reselection. Considering the ability of the UE to estimate when and / or where it will enter 3GPP® coverage, the following embodiments can be considered:

[0151] In a variant embodiment, the UE-to-UE relay or the out-of-coverage UE to network relay decides based on the above estimation whether to cache messages such as discovery messages containing RSCs related to security procedures with network assistance or DCR messages containing RSCs requiring network assistance for setting up a PC5 security link, based on the validity time and estimated time to coverage before the messages are sent, for example, to the target end UE or network.

[0152] In a variant embodiment, the in-coverage or out-of-coverage UE-to-UE relay decides whether to relay / drop a message, e.g., a discovery message, based on the above estimation, e.g., whether the security procedures or operations indicated in the discovery message by the RSC included in the message are supported by the time the UEs (end UE and UE-to-UE relay) initiate the PC5 link establishment procedure through direct communication.

[0153] In an alternative embodiment, the in-coverage or out-of-coverage UE-to-UE relay advertises (e.g., via a discovery advertisement message) its coverage schedule based on the above estimation, such that the end UE selects the RSC and subsequently the security procedures supported by the UE-to-UE relay by the time the PC5 establishment procedure is performed.

[0154] A more general definition of this embodiment describes a method in which a second device receives a discovery message from a first device, where the discovery message includes a relay service code associated with instructions determining the type of security procedures to be used during establishment of a PC5 secure link, and the second device evaluates whether to relay the discovery message to a third device, and if so, with what type of RSC, based on: - whether the coverage status of the second device changes between the time the second device receives the discovery message from the first device and the time the second device is ready to send the relayed discovery message to the third device; - whether the second device is (pre-)configured with a strategy for maintaining the same security procedures instructed by the first device through the relay service code and for dropping discovery messages if a change in coverage conditions requires a change in the security procedures used; - whether the second device is (pre-)configured with a strategy for adapting or selecting an RSC to its coverage conditions, such that an RSC supporting different security procedures is selected for the second hop-by-hop link, if necessary, with the first device further informed of the change in coverage conditions and the resulting security procedures to be performed, or - whether the second device is (pre-)configured with measures that allow the device to store discovery messages as long as they are valid and that allow the device to check at the time of transmitting the relayed discovery message whether the relay service code and the resulting security procedures to be used are supported;

[0155] Considering a Model A discovery procedure intended to ensure timely transmission of relay discovery announcement messages by relays when transporting protected direct discovery sets from announcing end UEs to monitoring end UEs, we assume the two scenarios described below.

[0156] (See FIG. 12) Scenario 1: End UEs are discoverable by actively sending announcement messages. The inter-UE relay (1202) provides timing information about its next announcement to end UEs (1201 and 1203) to ensure near real-time transmission of the protected direct discovery set in the relay announcement message. The steps of the procedure described in FIG. 12 are as follows: Step 1210: The inter-UE relay can decide to advertise relay announcement timing information based on the indication that the RSC supports per direct discovery set protection. An example of the timing information is a time window when the relay expects to receive the end UE's announcement for the end UE to be announced via the next relay announcement.

[0157] Step 1211: The inter-UE relay may send an inter-UE relay protection discovery message including an RSC, an inter-UE relay user information ID, and announcement timing information.

[0158] Step 1212: 1201 (announcement UE) schedules its next announcement message containing the protected direct discovery set based on the received advertisement relay announcement timing information (e.g., ensuring timely transmission within the advertised time window). 1203 (monitoring UE) lines up listening for the relay announcement message based on the received advertisement relay announcement timing information.

[0159] Step 1213: 1201 may send a protected UE-to-UE relay discovery announcement message including the RSC and the protected direct discovery set from 1201.

[0160] Step 1214: 1202 verifies that the announcement message from 1201 is received within an acceptable time based on the advertised relay announcement timing information. 1202 discards the announcement message from endpoint 1201 if it does not comply with the advertised relay announcement timing information (e.g., outside the time window).

[0161] Step 1215: 1202 sends a protected (advertisement) discovery message to the protected UE-UE relay, including the RSC, UE-UE relay user information ID, and protected direct discovery set received from 1201 according to the advertised advertisement timing information. 1203 (monitoring UE) receives the relay advertisement when aligned with the relay advertisement timing information, and discovers the presence of end UE#1 after successfully processing the relay discovery message and the included protected direct discovery set of 1201.

[0162] In this first scenario, the UE-to-UE relay attempts to ensure that discovery announcement messages are relayed from the announcing UE to the monitoring UE in a timely manner, but the UE-to-UE relay does not necessarily guarantee the freshness of the direct discovery set. For example, the UTC-based timer of the discovery message is bounded by a time window and therefore guarantees MIC validity, but the UTC-based counter used to calculate the MIC of the direct discovery set may expire before the discovery announcement message reaches the monitoring UE. In such a case, the monitoring UE discards the discovery announcement message. Furthermore, the approach described in this scenario does not include a verification step at the end of the monitoring UE. Therefore, it is a further object of the present invention to address these issues.

[0163] In one embodiment, the advertised timing information refers to a time window, the number of least significant bits to consider as the timing value used to calculate the MIC for a discovery message, the time a message remains fresh, or the time a message is cached by a relay. These parameters are therefore provided by the relay (e.g., based on a local strategy) instead of being configured by the NF of the CN as in other embodiments.

[0164] In a further embodiment, the UE-to-UE relay does not broadcast its timing information, but the timing information of the UE-to-UE relay, which is typically the timing information associated with the RSC, is configured by the CN.

[0165] In one embodiment, which can be combined with other embodiments, the end UEs (announcer UE and monitoring UE) are configured with a strategy / indicator that determines the difference in accuracy (e.g., the number of LSBs of a UTC-based counter), e.g., as a factor, between the timing values ​​advertised by the UE-UE relay and the timing values ​​used to calculate the MIC for the direct discovery set. The latter are less accurate than the timing values ​​advertised by the UE-UE relay to ensure that the direct discovery set remains valid during relaying. For example, the least significant bit of the end-to-end timing value has an accuracy of 2 seconds, and the least significant bit of the hop-by-hop timing value has an accuracy of 1 second. Additionally or alternatively, the end-to-end timing value is longer than the hop-by-hop timing value, e.g., the end-to-end timing value is 8 LSBs of a UTC-based counter, and the hop-by-hop timing value is 4 LSBs of a UTC-based counter. This has the advantage that it allows the UE-UE relay to cache messages if necessary and still guarantee the MIC validity of the direct discovery set.

[0166] In one embodiment, which can be combined with other embodiments, the end UEs (announcer UE and monitor UE) are configured with a strategy to determine the required number of LSBs of a UTC-based counter to transmit to ensure that the message is checked by other end UEs, taking into account the timing parameters of the UE-to-UE relay. For example, if the relay transmits a message every delta T seconds, the end UE will transmit a message containing more than log2(delta T) bits so that the exact transmission time can be successfully corrected by other UEs (e.g., monitor UEs).

[0167] In another embodiment, when the monitoring UE receives a relay discovery announcement message, it verifies whether the announcement message was received according to the advertised announcement timing information, cancels confidentiality / privacy protection if applicable, and performs integrity verification of the announcement message. The monitoring UE then verifies that the direct discovery set is still valid based on the UTC-based counter, the accuracy of the configured timing value, and whether the MIC is still valid.

[0168] Scenario 2 (see Figure 13): An end UE is discoverable (without necessarily advertising) while already connected to the repeater. The repeater (1302) obtains the protected direct discovery set from the connected end UE (1301) on demand and ensures near real-time transmission of the protected direct discovery set in a relay advertisement message to the monitoring UE (1303). The steps of the procedure described in Figure 13 are as follows:

[0169] Step 1310: If the RSC is configured with an indicator for each direct discovery set protection and the ProSe service requires restricted discovery, the announcing end UE (1301) can use the RSC to send the ProSe restriction code in the DCR message to the inter-UE repeater (1302) (i.e., the corresponding direct discovery set security material has been provided to the end UE). The repeater verifies that the RSC supports each direct discovery set protection and stores the ProSe restriction code in the context of the PC5 unicast link.

[0170] Step 1311: The inter-UE relay (1302) decides to advertise the connected UE.

[0171] Step 1312: For each connected end UE (1301) with a stored ProSe restriction code, 1302 sends a PC5-S request message including the ProSe restriction code previously received from 1301 to request a corresponding protected direct discovery set.

[0172] Step 1313: 1301 generates a secure PC5-S response message containing the RSC and the direct discovery set protected using the provided direct discovery security material. 1301 protects the PC5-S message with the PC5 link security context and sends it to 1302.

[0173] Step 1314: 1302 processes the PC5-S response message security and extracts the included protected direct discovery set. 1302 sends a UE-to-UE relay protected discovery message including the RSC, the UE-to-UE relay user information ID, and the protected direct discovery set received from 1301, where the UE-to-UE relay discovery message is protected using security material associated with the RSC. 1303 (monitoring UE) processes the security of the relay discovery message security and the security of the included protected direct discovery set to discover 1301.

[0174] This approach assumes that a PC5 secure link has already been established between the UE-to-UE relay and the announcing UE, where the UE-to-UE relay triggers a discovery announcement message transmission from the announcing UE by sending a PC5-S request containing a ProSe restriction code obtained during the direct link establishment between the two UEs (i.e., the announcing UE and the UE-to-UE relay). A potential drawback of this approach is similar to the first scenario: it does not guarantee that the direct discovery set remains valid at the time the discovery announcement message is delivered to the monitoring UE. Another drawback is that the announcing UE relies on the UE-to-UE decision (step 3 above) on when to distribute the discovery message. Addressing this is therefore the subject of the following embodiments.

[0175] In one embodiment, this approach is further improved by incorporating an aspect of the first scenario, i.e., timing information, into the procedure. For example, the UE-to-UE relay advertises the following advertising timing information in a PC5-S request (e.g., similar to step 1 in scenario 1) or separately in step 3. The advertising UE then sends a PC5-S response (similar to step 4), where the UE-to-UE relay dutifully performs a timing check before relaying the direct discovery set to the monitoring UE in step 5. When received by the monitoring UE, another timing check is dutifully performed before revoking confidentiality / privacy protection of the protected direct discovery set and verifying its integrity.

[0176] In another variant embodiment, the UE-to-UE relay advertises the advertised timing information (e.g., the time window or the number of LSBs of the UTC counter to consider) used by the advertising UE to calculate the direct discovery set MIC, and the monitoring UE verifies that the direct discovery set is still valid based on the UTC-based counter, the timing value advertised by the UE-to-UE relay, and whether the MIC is still valid.

[0177] In another embodiment that can be combined with other embodiments, if the UE-to-UE relay advertises timing information (e.g., a time window or the number of LSBs of the UTC counter to be considered) in the announcement and multiple announcing UEs send announcement messages, the UE-to-UE relay can cache the announcement messages, collect them, and send them to the monitoring UE as long as the individual discovery announcement messages received from the announcing UEs remain valid.

[0178] In an independent use embodiment, the announcing UE communicates its transmission schedule, e.g., timing information, to the UE-to-UE relay, e.g., in step 1, step 4, or in the discovery message itself. This ensures that the UE-to-UE relay is ready and / or able to perform relaying operations (e.g., by reserving resources). This also ensures that the service (relaying) provided by the UE-to-UE relay is suited to the needs (e.g., timing) of the announcing UE. In this embodiment, upon receiving the announcing UE's timing information, the UE-to-UE relay confirms, rejects, or requests modification. If confirmed, the announcing UE proceeds to announce the message (eg as in step 4 above or other embodiments). - if rejected, the announcing UE may try again or search for a different inter-UE relay; - If a modification is required, the inter-UE relay requests a modification of the timing parameters, which may depend for example on other notifying UEs connected to the inter-UE relay.

[0179] In an alternative embodiment similar to the previous embodiment, the announcing UE and the inter-UE relay: - whether the advertising UE sends an advertisement message (discovery message) itself (e.g., step 4 above); and / or - Agree on whether the announcing UE needs to wait for instructions from the UE-to-UE relay (step 3 above).

[0180] The above variants may be combined or used in conjunction with one another.

[0181] According to the draft CR for TS33.503 of TDoc S3-233374, section 6.1.3.3.3.1, step 2, a UE-to-UE relay receives a UE-to-UE discovery message from an end UE (e.g., announcing UE, discoverer UE) that includes a protected direct discovery set, and / or receives a protected direct discovery set from an already connected end UE (e.g., announcing UE, discoverer UE). The UE-to-UE relay is capable of integrity verifying messages protected with DP_S-UE-to-UE discovery keys, i.e., discovery keys shared and used between the end UE and the UE-to-UE relay. This integrity verification utilizes a UTC-based timer associated with / used with those keys. However, the UTC-based timer is not the same as the UTC-based timer associated with the protected direct discovery set (e.g., because the direct discovery set is protected before (i.e., first) any 5G ProSe UE-to-UE relay discovery or communication messages). This may lead to a situation where the UE-to-UE relay needs to determine the validity of the protected discovery set. This can be solved by various variants.

[0182] In one variant embodiment, the UE-to-UE relay needs to verify that the LSBs of the received UTC-based timers are close to each other, e.g., they differ by 0 (identical), 1, or 2. Note that in the case of a UTC-based counter, this difference needs to be calculated modulo 2 raised to the power of the size of the LSB, e.g., if the UTC-based counter is 8 bits long, then 0xFF and 0x00 are close.

[0183] In one variant, the UE-to-UE relay uses the time of the LSB of the UTC-based timer contained in the direct discovery set to determine the validity time, which is 1 even though the UE-to-UE relay cannot verify it directly.

[0184] According to draftCR for TS33.503 of TDoc S3-233374, section 6.1.3.3.3.1, step 2, when the inter-UE relay broadcasts an announcement message, it includes a list of valid protected direct discovery sets in the announcement message and protects the announcement message using RSC-related discovery security material specified in section 6.1.3.2.3 of TS33.503. The 5G ProSe inter-UE relay then transmits the announcement message. However, this may cause the loss of some of the received direct discovery sets. To address this issue, in one variant embodiment, the inter-UE relay has a strategy that allows it to store the direct discovery sets as long as they remain valid and a given condition applies, such as any of the direct discovery sets being close to expiring (e.g., expiration-delta). When any of the direct discovery sets are about to expire, the UE-to-UE relay includes a list of the received protected direct discovery sets in an advertisement message, protects the advertisement message using the discovery security material associated with the RSC, and then broadcasts the advertisement message. This embodiment is advantageous because it limits / reduces the number of discarded messages.

[0185] In one variant embodiment, the UE-to-UE relay is provided with or configured to broadcast advertisement messages containing direct discovery sets periodically or based on direct discovery set availability such that the advertisement messages are broadcast regardless of which condition is met first. This has the advantage of reducing the number of outdated direct discovery sets and the number of direct discovery sets included in the advertisement messages, since the end UEs have more opportunities to receive the direct discovery sets and establish a communication link.

[0186] When a monitoring UE receives a discovery announcement message broadcast by a UE-to-UE relay containing direct discovery sets, the monitoring UE unscrambles, decodes, and / or integrity verifies the discovery announcement message, and if successful, extracts the direct discovery sets from the discovery announcement message and then verifies those direct discovery sets. Because the direct discovery sets are protected as specified in TS33.503, section 6.1.3.2.3, the order of security operations is integrity protection, confidentiality protection, and finally scrambling; therefore, to verify the direct discovery sets, the monitoring UE performs the verification in the reverse order (i.e., unscrambling, decoding, and finally integrity verification). Also, in contrast to the restricted direct discovery scenario in which ProSe restriction codes are included in discovery messages and matched based on the discovery filters described in step 2 of TS 33.303 subclause 6.1.3.4.3.3, in the UE-to-UE relay discovery scenario, Tables 10.2.1.12, 10.2.1.13, and 10.2.1.14 of TS 24.554, which respectively describe the contents of UE-to-UE relay discovery announcement messages, solicitation messages, and response messages, and describe the contents of UE-to-UE relay discovery messages defined in TS 23.304 (e.g., Model B discovery in subclause 6.3.2.4.3), do not specify / include ProSe restriction / App codes as elements of the end-to-end direct discovery set. Therefore, a monitoring UE cannot distinguish between direct discovery sets that target the monitoring UE and must verify each direct discovery set in its entirety. This increases the risk that one or some direct discovery sets will be invalid by the time the monitoring UE attempts to verify them. Furthermore, revoking message-specific confidentiality requires extensive computation, and therefore, having to repeatedly revoke confidentiality on all received advertised discovery messages for each direct discovery set is extremely resource-intensive. To remedy these problems, the following embodiments are proposed.

[0187] In one embodiment, the order of security operations is rearranged to confidentiality protection, integrity protection, and finally scrambling, so that if the direct discovery set is scrambled, the monitoring UE can first unscramble and verify the integrity of the message, discard the invalid direct discovery set, and then revoke confidentiality.

[0188] In one variant embodiment, the MICs of the direct discovery set do not require scrambling protection, and thus the monitoring UE has direct access to the MICs, first verifying the validity of the direct discovery set, then unscrambling (if applicable), and finally revoking confidentiality protection. Note that the MICs of the direct discovery set are protected by the UE-to-UE relay as part of the discovery announcement message.

[0189] In another embodiment aimed at helping the monitoring UE distinguish between direct discovery sets targeted to the monitoring UE and direct discovery sets not targeted to the monitoring UE, the announcing end UE includes a ProSe restriction code in the direct discovery set. The ProSe restriction code is not confidentiality protected, but instead is only scrambled (e.g., at the end) to make it quickly accessible to the monitoring UE. This has the advantage that it allows the monitoring UE to determine whether a direct discovery set is targeted to the monitoring UE without having to revoke confidentiality protection.

[0190] In an additional embodiment, if the announcing end UE includes a ProSe restriction code in its direct discovery set and applies scrambling last when extracting the direct discovery set, the monitoring UE first unscrambles and matches the ProSe restriction code, discards the direct discovery set that is not intended for the monitoring UE, performs integrity verification, and finally revokes confidentiality protection. This has the advantage of reducing the number of direct discovery sets to only those intended for the monitoring UE, and also saves resources by performing fewer MIC and confidentiality checks.

[0191] In one embodiment, to allow for the ProSe restriction code to be added without encryption, the length parameter of the message specific confidentiality mechanism for discovery described in A.7 of TS33.503 is changed to Length: LEN(discovery message)-(LEN(ProSe restriction code)+LEN(LSB of UTC-based counter)+LEN(MIC)), where LEN(x) is the length of the number of bits x.

[0192] In the above (variant) embodiment, the strategy is configured by an entity in the 5G CN that configures discovery parameters, for example security keys such as DUIK, DUSK, DUCK, etc.

[0193] Some processing steps in the above description are performed from the perspective of, for example, a transmitting device or a receiving device. If the processing of a corresponding part (e.g., a receiving device or a transmitting device) is not described, it should be understood that it is complementary. For example, if a transmitting device is configured with a policy of not using a key for a given purpose in some circumstances, the receiving device should also be configured with the same policy of not using that key. The flexibility provided by this policy is advantageous because it allows adapting the security / performance level depending on the communication situation.

[0194] In one embodiment, which may be combined with other embodiments or used independently, if during discovery the UE-to-UE relay is able to identify an end UE with which a secure link is already established (e.g., through a pre-connection with said end UE), the UE-to-UE relay reuses the security context (e.g., keying material) to protect discovery messages relayed from other end UEs to end UEs with which a security context is already established.

[0195] In one variant embodiment, if the discovery message is protected with only one set of security material (eg, associated with the RSC), the UE-to-UE relay is able to identify the end UE (eg, target UE).

[0196] In an alternative embodiment, if two sets of security material are used and only the direct discovery set is integrity protected, the UE-to-UE relay can identify the end UE (eg, target UE).

[0197] In another embodiment, if the target UE's user information ID is long enough, the end UE (e.g., source UE) calculates a pseudonym (PID) based on the target UE's user information ID as a function, e.g., a one-way function, e.g., a cryptographic function (e.g., PID=Hash(target UE's user information ID)), and includes it in, e.g., a UE-to-UE discovery set. The UE-to-UE relay attempts to identify whether a security context is established with the target UE by performing the calculation by comparing the pseudonym received by the source UE with the PID calculated using the target UE's user information ID of the UE with which the secure link has been established.

[0198] In one variant, the source UE adds a salt / nonce as a parameter to the function used to calculate the PID to avoid dictionary attacks, e.g., PID=Hash(Salt, UserInfoID of target UE). The salt / nonce value is confidentiality protected and transmitted as part of the UE-to-UE discovery set.

[0199] In another alternative or variant embodiment, if the source UE has the destination Layer-2 ID of the target UE, the source UE sends the destination Layer-2 ID of the target UE protected in the UE-to-UE discovery set (e.g., using a hop-by-hop security key, i.e., associated with the RSC).

[0200] In one embodiment, when the inter-UE relay has or obtains an identifier of an end UE (e.g., User Info ID or Destination Layer 2 ID), if applicable, the inter-UE relay checks to determine whether a secure link is already established with said end UE. If a secure link is already established based on a policy provided to the inter-UE relay, the secure link is reused to protect messages (e.g., discovery messages and / or direct communication messages) intended for the end UE for which a security context is already established. This has the advantage of independently providing privacy / integrity protection for the ProSe service used and optimizing secure link establishment (e.g., skipping new key establishment, direct authentication, and security mode command procedures).

[0201] After the discovery phase, the UEs (i.e., the end UE and the UE-to-UE relay) establish a secure PC5 communication link with network assistance (as per section 6.6.3.1 of draftCR of Tdoc S3-233374) by reusing the security procedures defined in section 6.3.5 of TS33.503 by replacing the remote UE with the source UE and the UE-to-network relay in the first hop, and replacing the remote UE with the target UE and the UE-to-network relay in the second hop. However, for the DCR message relayed from the UE-to-UE relay to the target UE, the content of the DCR message is different (e.g., it does not include the PRUK-ID). Therefore, it is unclear how the DCR message is protected. Therefore, the following embodiment is proposed.

[0202] In one embodiment, the same security procedures for protecting DCR messages in clause 6.3.5 of TS33.503 are applied to protect DCR messages between the source UE and the UE-to-UE relay and to protect DCR messages from the UE-to-UE relay to the target UE. This has the advantage of reducing code complexity, since the same routines can be used for multiple types of DCR messages. However, the DCR message exchange between the UE-to-UE relay and the target UE does not include the PRUK-ID (because it is the UE-to-UE relay that sends the message to the target UE). Therefore, when sending a DCR message to the target UE, the UE-to-UE relay sets the PRUK-ID field to a predetermined value (e.g., all zeros) instead of the PRUK-ID of the source UE. The target UE processes the incoming message according to clause 6.3.5 of TS33.503 and ignores the PRUK-ID field.

[0203] In one variant embodiment, if the UE-to-UE relay sets the PRUK-ID to a predetermined value (e.g., all zeros), the target UE, upon receiving the DCR message, cancels protection and verifies whether the PRUK-ID is set to said predetermined value.

[0204] In an alternative embodiment, the UE-to-UE relay sets the PRUK-ID field to a random value instead and reuses the same security procedures to protect the DCR message to be sent to the target UE.

[0205] In one variant embodiment, since the PRUK-ID field is not required in the DCR message from the UE-to-UE relay to the target UE, the UE-to-UE relay strips said PRUK-ID field from the received DCR message as it is received from the source UE and reuses the security routine in TS33.503 clause 6.3.5. This security routine involves more RSC and PRUK-ID confidentiality protection, so the resulting protected DCR message exchanged between the UE-to-UE relay and the target UE protects some additional fields that are not normally protected. This variant is advantageous because a single security routine (as per TS33.503 clause 6.3.5) needs to handle different types of DCR messages.

[0206] In this general definition, a method and apparatus implementable in a first device is described for securely protecting a discovery message by using a first set of keys and a second set of keys and optionally a strategy, and for transmitting a second protected discovery message, the first device comprising: protecting the discovery message based on a first set of keys and a strategy derived from the first discovery protection message; protecting the first discovery protection message based on a second set of keys and a strategy derived from the second discovery protection message; A second discovery and protection message is transmitted.

[0207] The above first discovery protection message is also referred to as a first protected discovery message.

[0208] Generally, methods and apparatus are described that may be implemented in a third device for securely receiving and securely processing (including integrity verifying, unscrambling, and / or decrypting) a third protected discovery message by using a first set of keys and a third set of keys and optionally a strategy, the third device comprising: receiving a third protected discovery message; securely processing a third protected discovery message based on a third set of keys and a policy derived from the first protected discovery message; The first protected discovery message is securely processed based on the first set of keys and a policy derived from the discovery message.

[0209] In a more general definition of this embodiment, for securely receiving and securely processing (including integrity verifying, unscrambling, and / or decrypting) a second protected discovery message by using a second set of keys and optionally a strategy for obtaining the first protected discovery message; and a method and apparatus implementable in a second device are proposed for securely processing (including integrity protecting, scrambling, and / or encrypting) the first protected message by using a third set of keys and optionally a strategy, and for securely transmitting a third protected discovery message; The third device is receiving a second protected discovery message; securely processing the second protected discovery message based on the second set of keys and the policy derived from the first protected discovery message; securely processing the first protected discovery message based on a third set of keys and a policy derived from the third protected discovery message; Send a third secured message.

[0210] In one option of this definition, the methods and apparatus proposed above can be implemented in a first device to receive a first set of keys and a second set of keys and optionally a policy from a fourth device.

[0211] In another alternative to this definition, the methods and apparatus described above can be implemented in a second device to receive a second set of keys and a third set of keys and optionally a policy from a fourth device.

[0212] In yet another alternative to this definition, the methods and apparatus described above are implementable in a third device to receive the first set of keys and the third set of keys and optionally a policy from a fourth device.

[0213] A further alternative to this definition may require that in the methods and apparatus described above, the first set of keys (or / and the third set of keys) does not include a scrambling key.

[0214] In yet another alternative to this definition, in the methods and apparatus described above, the measures require that if the discovery process of the third device is performed through the second device, protection of the discovery message based on the first set of keys must not involve scrambling.

[0215] In yet another alternative to this definition, in the methods and apparatus described above, the second protected message and / or the third protected message includes two MICs.

[0216] In yet another alternative to this definition, in the methods and apparatus described above, the second protected message and / or the third protected message include a single MIC that has been updated (i.e., the received MIC has been verified and recalculated) by the second device.

[0217] In yet another alternative to this definition, in the methods and apparatus described above, the second protected (discovery) message includes two MICs (and an end-to-end MIC and a hop-by-hop MIC), and the third protected (discovery) message includes a single MIC.

[0218] In yet another alternative to this definition, in the method and apparatus described above, protection of the first protected message based on the second set of keys requires that step 3 of clause 6.1.3.4.3.5 of TS33.303 be XORed (0xFFFF|| time hash bit sequence) with the most significant (L+16+16) bits of the discovery message.

[0219] In yet another alternative to this definition, in the method and apparatus described above, protection of the first protected message based on the second set of keys requires that step 3 of clause 6.1.3.4.3.5 of TS33.303 be XORed (0xFFFFFFFF|| time hash bit sequence) with the most significant (L+16+16) bits of the discovery message.

[0220] In yet another alternative to this definition, in the methods and apparatus described above, the second MIC, calculated with an integrity key from the second set of keys, is calculated over the entire message, including the MIC contained in the first protected message.

[0221] A further alternative to this definition is that in the methods and apparatus described above, the second set of keys must not include a confidentiality key.

[0222] In yet another alternative to this definition, in the methods and apparatus described above, the policy requires that if the first set of keys includes a confidentiality key, then protection of messages based on the second set of keys must not involve confidentiality protection.

[0223] In yet another alternative to this definition, in the methods and apparatus described above, the strategy requires that protection of the discovery message be based on an integrity key and a confidentiality key of the first set of keys and an integrity key and a scrambling key of the second set of keys.

[0224] It should be noted that the above options may be used in various combinations or independently of each other.

[0225] It should be noted that the apparatus described above may be implemented by a first device, a second device, and / or a third device.

[0226] Generally, the described system includes a first device, a second device, and a third device.

[0227] Secure and Privacy-Aware Path Switching in UE-to-UE Relay Scenarios In a different use case under study in TR33.740 v0.2.0, a source UE and a target UE communicating through a first UE-UE relay need to perform a path switch from a first UE-UE relay to a second UE-UE relay. This functionality is required, for example, to ensure connectivity between the source UE and the target UE. Security and privacy of such a procedure are of paramount importance. For example, in some solutions, the source UE first triggers the path switch in a first step. The source UE then sends a link modification message (including candidate relay IDs, source UE link ID, and security parameters) to the target UE. The target UE then selects a new relay, establishes new security keys, and returns a link modification accept (including the selected relay and indicating the target UE link ID and security parameters). The source UE then establishes new security keys and sends a direct communication request including the (new) link ID of the target UE. The target UE then retrieves and uses the new security keys to verify the DCR message and returns a direct communication accept (including the new source UE link ID). Then, when the source UE receives this direct communication accept, it looks up and uses the new security key to verify the direct communication accept message. Note that the link ID (e.g., of the source UE) is a random number generated, e.g., locally by the source UE. To avoid replay attacks and linkability / tracking attacks throughout the path switching procedure, a new source UE link ID is generated and used every time a new path switch is initiated, i.e., every time a link modification message for a path switch is sent.

[0228] Some related solutions propose to perform path switching by sending a link modification request (TS24.554) that carries a list including candidate relay identifiers (RIDs) and source UE link IDs and security parameters. However, with such an approach, it is unclear how the source UE obtains an up-to-date list of RIDs. For example, the source UE does not collect a list of UE-to-UE relays during discovery, and even if it does, this list may be out of date.

[0229] Some solutions propose that the source UE triggers the path switch, but in such approaches it is unclear how the target UE can trigger the path switch.

[0230] In some solutions, the source UE sends a link modification request message and the target UE replies with a link modification accept message, which serves the purpose of establishing a new path. However, these messages, even when used to establish the new path and derive keying material, appear to lack any security protection, such as in TS 24.554. In this situation, an attacker can introduce a link modification request message that can unfairly trigger the path switching procedure. Furthermore, any exchanged fields (e.g., new link ID) are not encrypted.

[0231] Some solutions propose updating security keys during path switching, but this is not always required.

[0232] In some solutions, new identifiers such as link IDs need to be exchanged, but this requires additional bandwidth and message modifications.

[0233] In a first embodiment, which can be used independently or combined with other embodiments, it is proposed to enhance the Link Modify Request and Link Modify Accept messages with a Message Integrity Code. This MIC is calculated with the NIA algorithm or by a pseudo-random function on the contents of the message and a nonce or counter. For the counter, a UTC-based counter can be used, the least significant bits of which are then swapped. The MIC can be calculated using a key related to the current PC5 connection across the first UE-to-UE relay, e.g., a key derived from K_NRP or K_NRP-sess. In this embodiment, the first UE (e.g., source UE) constructs one of the messages (e.g., Link Modify Message) including, for example, a candidate RID and / or source UE link ID. The one message is sent at the source UE to transmit the existing PC5 unicast link via Relay_1 to the selected relay (e.g., Relay_2) and / or security parameters (i.e., nonce_1, K NRP-sess The first UE then appends a counter, or a portion of a counter, and the first UE includes a MIC calculated over the contents of the message and the counter. A second UE (e.g., target UE) receives one of the messages (e.g., a protected link modification message) and verifies the received message by recalculating the MIC based on the received message and counter and comparing the recalculated MIC with the received MIC. If the verification is successful, the second UE is allowed to proceed with normal message flow, e.g., as described above.

[0234] In a further embodiment, which can be used independently or combined with other embodiments, it is proposed to perform discovery to trigger UE-to-UE path switching. This is done, for example, as in FIG. 3 for discovery Model A, or similarly for Model B, which includes a discovery response message from the target UE to the source UE. The Model A and Model B discovery messages can be secured as described in the above embodiments. The difference compared to the initial UE-to-UE discovery is that in this subsequent UE-to-UE discovery, both the source UE and the target UE already have an active PC5 connection over a given UE-to-UE relay. Because the source UE does not know which other UE-to-UE relays are available, the source UE cannot include identifiers of potential relays, but includes the ID of the current UE-to-UE relay (i.e., the first UE-to-UE relay) in the initial discovery message, e.g., an invite or advertise discovery message. When the inter-UE relay device forwards this discovery message from the source UE, if the inter-UE relay currently handling the connection, i.e., the first inter-UE relay, the inter-UE relay will understand that the source UE will trigger the path switching procedure, and therefore the inter-UE relay will not forward the discovery message. The target UE then receives discovery messages from all potential inter-UE relay devices. The target UE may or may not receive the discovery message from the "first" inter-UE relay device (if the "first" inter-UE relay device did not forward the discovery message). If the target UE receives the message from the first inter-UE relay and has an established connection with the source UE through this first inter-UE relay, the target UE will only select the first inter-UE relay if it is the only option.

[0235] The target UE then takes one or more of the following actions: 1. Select none or one of the UE-to-UE relays and return a message (e.g., a discovery model B response message such as TS33.503) that is relayed to the source UE through the selected UE-to-UE relay, or a link modification request that includes the selected relay. 2. Return a message (eg, a link modification request or discovery message) containing a list of potential UE-UE relays.

[0236] In a further embodiment, which can be used independently or combined with other embodiments, the returned list of potential UE-to-UE relays returned by the target UE during discovery (e.g., as in the previous embodiment) is arranged according to their priority.

[0237] In a further embodiment, which can be used independently or combined with other embodiments, the list of potential UE-to-UE relays sent by the source UE, for example in a link modification acceptance, is arranged according to their priority.

[0238] In a further embodiment, which can be used independently or combined with other embodiments, the discovery message used for path switching is enhanced with security parameters that allow updating the PC5 security context (such as K_NRPsess) after it has been established through the new UE-to-UE relay. These security parameters include nonce_1, K NRP-sess When the target UE receives a first discovery message, e.g., an INVITE message, it can security process the discovery message as described in this application or TS33.503 and use the received security parameters to derive new security parameters, e.g., a new K NRP-sess can be used to generate

[0239] In another embodiment, which can be used independently or combined with other embodiments, the switching path procedure is NRP-sess , and therefore security parameters do not need to be exchanged.

[0240] In a further embodiment, which can be used independently or combined with other embodiments, the discovery message used for path switching includes a new (randomly generated) identifier, e.g., a link ID, to prevent tracking and linkability.

[0241] In a further embodiment, which can be used independently or combined with other embodiments, the discovery message used for path switching and containing the new (randomly generated) identifier is confidentiality protected end-to-end, e.g., as described in the above embodiment.

[0242] In a further embodiment, which can be used independently or combined with other embodiments, the discovery message used for path switching includes a current link ID that allows the discovery message to be associated with an existing PC5 unicast link.

[0243] In another embodiment, which can be used independently or combined with other embodiments, the link IDs exchanged in the link modification request, link modification accept, or discovery messages are confidentiality protected to prevent attackers from performing linkage attacks, for example, by using the NEA algorithm and a key related to the current PC5 key.

[0244] In another embodiment, which can be used independently or combined with other embodiments, IDs, e.g., link IDs, exchanged in link modification request, link modification accept, or discovery messages are confidentiality protected, but the IDs are generated so that an attacker cannot link them. For example, if the UE has an ID and a key, the UE updates the ID as ID' = LSB(KDF(K, ID)), where LSB(a) is a function returning, e.g., a subset of the least significant bits, and the UE sends as ID' hint, which is calculated as MSB(PRF(K, ID)), where MSB(a) is a function returning, e.g., a subset of the most significant bits. KDF means key derivation function.

[0245] In another embodiment, which can be used independently or combined with other embodiments, new link IDs to be used after a path switch are not exchanged, e.g., they are not exchanged in discovery messages or link modification request / accept messages, but are derived from either the current key or a future key associated with UE-to-UE communications. For example, the link ID of the source UE is derived by a key derivation function that uses the current key (e.g., K_NRP or K_NRP-sess) or the future key after the path switch (e.g., K_NRP or K_NRP-sess) and an additional parameter, e.g., a bit string identifying the source UE or a UTC-based counter. The actual link ID is a subset of the output of the key derivation function, e.g., the least significant bits. In this embodiment, the hint ID is not exchanged.

[0246] In another embodiment, which can be used independently or combined with other embodiments, the DCR message is protected as per TS33.503 clause 6.3.5, but a newly generated key is used to protect the DCR message instead of the discovery key as per clause 6.3.5. Thus, when the source UE sends a DCR during a path switch procedure, it protects the DCR with a key derived from, for example, the current or future K_NRP-sess key used on the PC5 link. A UE that has previously received a message indicating a path switch (e.g., a discovery message or link modification request from a currently connected device) subsequently receives the DCR message, and that UE uses a key derived from the current or future K_NRP-sess key used on the PC5 link to decrypt / integrity verify the DCR message.

[0247] In another embodiment, which can be used independently or combined with other embodiments, the target UE can trigger the path switch procedure by first sending an indication to the source UE. This indication of the path switch requirement is exchanged by a link modification request. This message can be sent empty or with a well-defined identifier.

[0248] In another embodiment, which can be used independently or combined with other embodiments, the target UE can trigger the path switching procedure and the message flow is in the reverse format.

[0249] In another embodiment, which can be used independently or combined with other embodiments, the derivation of the new PC5 key is performed by a direct communication exchange. Specifically, the direct communication request includes nonce_1, K NRP-sess The session key K contains security parameters such as the MSB of the ID, and the direct communication acceptance contains security parameters such as nonce_2. NRP-sess is derived by the target UE upon receiving the DCR message, and the session key K NRP-sessis derived by the source UE upon receiving the DCA message. The previous phases, e.g., the discovery phase and / or the link modification phase, are used for path discovery and / or link ID update.

[0250] In a further embodiment, which can be used independently or combined with other embodiments, path switching not only serves the purpose of changing paths but also of securely enabling multipath communication between UEs. Thus, once two UEs have established a path across a first UE-to-UE relay, the source or target UE performs a path switching procedure with the goal of ensuring multipath communication, i.e., having two or more active communication paths between the source and target UEs. In this case, the described embodiments can be used. To conceal the multipath capability, it is advantageous to have different link IDs for the different paths. It is also advantageous to establish two or more different security contexts for each of the communication paths. In this case, the identity of the UE-to-UE relay in each of the paths can be used by the UE to derive different parameters. For example, K NRP-sess is calculated by a KDF that takes as input the nonce_1 and nonce_2, which are normally exchanged in the authentication and key establishment procedure, e.g., TR33.740, and the identity of the UE-to-UE relay. NRP In this way, a single set of parameters needs to be exchanged, one for each link, with different K NRP-sess , i.e., K NRP-sess Similarly, the link ID to be generated and used for each communication path is K NRP or K NRP-sess (relay ID) by a KDF that takes as input the key, a time counter, a bit string of the UE role (source UE / target UE), and / or the relay UE ID.

[0251] In other embodiments that can be used independently or combined with other embodiments, the overall process for UE-to-UE relay path switching includes (1) a discovery phase as in the above embodiment, and (2) an exchange of direct communication requests and direct communication accepts as described in other embodiments.

[0252] In other embodiments that can be used independently or combined with other embodiments, the overall process for UE-to-UE relay path switching includes (1) a discovery phase as in the above embodiment, (2) an exchange of link modification request messages / link modification accept messages, and (3) an exchange of direct communication request messages and direct communication accept messages as described in other embodiments.

[0253] In other embodiments that can be used independently or combined with other embodiments, the overall process for UE-to-UE repeater path switching includes (1) exchanging a link modification request message / link modification accept message, and (2) exchanging a direct communication request message and a direct communication accept message as described in other embodiments.

[0254] The table below shows some of the possible combinations of the above embodiments to achieve the key functionality of path negotiation (i.e. determining a new UE-to-UE relay), key update negotiation (i.e. deriving a new key for the PC5 link), link ID update (i.e. implicitly or explicitly agreeing / generating a new link ID), and confirmation (of the new link).

[0255] [Table 1]

[0256] In a general definition of another embodiment, a method and apparatus for path switching that can be implemented in a device is proposed, the method and apparatus comprising one or more of the following phases: The link correction phase consists of sending a link correction and receiving a link correction acceptance message. A direct communication phase consisting of sending a direct communication request and receiving a direct communication acceptance message.

[0257] Additionally, the secure exchange of new link IDs includes encryption and integrity protection when the exchange occurs during the link modification phase.

[0258] Generally, a method and apparatus as described above is proposed in which the DCR message is protected as per section 6.3.5 of TS33.503 using a newly generated key.

[0259] In general, methods and apparatus as described above are proposed which are driven by a discovery phase, where link selection is performed in an initial discovery phase instead of a link modification phase, and the link modification phase serves the purpose of updating the PC5 keys and / or link IDs to be used after a path switch.

[0260] Generally, methods and apparatus as described above are proposed that are driven by a discovery phase, where link selection is supported by an initial discovery phase that returns available UE-to-UE relays to the source UE.

[0261] Selection of security establishment procedures during path switching A standard security establishment procedure is used to ensure communication between the source UE and the target UE through the UE-to-UE relay. The standard security establishment procedure is a procedure used to establish security between the source UE and the target UE through the UE-to-UE relay when the source UE and the target UE are not yet communicating and / or have not yet established a security context. For example, the standard security establishment solution is a solution such as Solution #3 of TR33.740 (which is an in-coverage solution that relies on the CN for PC5 security establishment, i.e., a procedure with network assistance) or Solution #4 of TR33.740 (which is an out-of-coverage solution that does not rely on the core network for PC5 security establishment, i.e., a procedure without network assistance).

[0262] Furthermore, it is feasible to establish a secure link during path switching in a UE-to-UE relaying scenario, where a source UE and a target UE, communicating through a first UE-to-UE relay, wish to communicate through a second UE-to-UE relay. This (re)establishment of a security link during path switching is done efficiently by an optimized procedure, which is more efficient than using standard security establishment procedures as described in the above embodiments or as described in Solution #14 of TR33.740.

[0263] However, it is not always possible to decide whether to use standard security procedures or optimized security procedures.

[0264] For example, initial communication between a source UE and a target UE through a first UE-UE relay may have been established using a standard out-of-coverage solution, with a second UE-UE relay in coverage. The question now is whether security during path switching should rely on an optimized procedure (e.g., one of the above embodiments optimized for the path switching scenario) or on a standard security establishment procedure (e.g., taking advantage of the fact that the second UE-UE relay is in coverage).

[0265] It is an aim to address this issue through embodiments that can be combined with each other.

[0266] In one embodiment, a method for establishing a security context in the case of an inter-UE relay path switch is based on a policy provided to the UEs (e.g., source UE, target UE, and / or inter-UE relay). This policy determines which security method / procedure should be used or preferred, and whether to skip the standard security establishment procedure and use an optimized procedure, e.g., by reusing the security context (e.g., security policy and security algorithms) already established from, e.g., a previous PC5 unicast link, e.g., for optimization purposes to enable faster link setup and path switch and minimize service outages. In this case, the security policy and security algorithms to be used for end-to-end security, e.g., across the first relay, are not renegotiated during the establishment of the new link across the second relay; instead, the agreed-upon security policy and security algorithms from the first link are used to derive only new security keys for the new link. In a related embodiment, skipping the standard security establishment procedure is subject to a policy provided to the UEs (e.g., source UE, target UE, and / or inter-UE relay), which depends on factors including, but not limited to: - a coverage status of a UE, for example, a coverage status of a first inter-UE relay and a coverage status of a second inter-UE relay; - Ultra-reliable low latency communication (URLLC) requirements - performance requirements, e.g., the maximum desired introduced delay during path switching for the application at hand; - whether the keying material used to establish the original security context across the first UE-to-UE relay is still valid / approved at the time of the path switch; - Optimization objectives

[0267] In related embodiments, the reuse of security context from a first link (i.e., between source UE and target UE via a first UE-to-UE relay) on a future established second link (i.e., between source UE and target UE via a second UE-to-UE relay) is subject to negotiation between the end UEs (e.g., source UE and target UE) and the second UE-to-UE relay, the outcome of which is determined based on UE (source UE, target UE, UE-to-UE relay) policy.

[0268] For example, during the initial security establishment across the first inter-UE relay, the target UE and source UE indicate whether they prefer to use the standard security establishment procedure during path switching, or whether they prefer an optimized procedure, such as the above embodiment or e.g., Solution #14 of TR33.740, and the conditions for using the optimized procedure. This preference is based on, e.g., a policy configured by the NF of the network. The negotiation determines, e.g., that the optimized procedure is to be used only if both the target UE and the source UE agree.

[0269] For example, the inter-UE relay has a strategy to determine that two end UEs (source UE and target UE) are only allowed to perform path switching in an optimized manner when the inter-UE relay is out of coverage, otherwise, standard security establishment procedures are required when the inter-UE relay is in coverage.

[0270] In a related embodiment, end UEs (e.g., source UE and target UE) desire to establish multipath communication between them through multiple relays. In such a case, the end UE's policy allows them to retain the security context (e.g., security policy and security algorithms) from the first link and only derive new security keys for other links (e.g., through other UE-to-UE relays).

[0271] In another embodiment, when establishing multipath communication and / or path switching, an end UE (e.g., source UE or target UE) may indicate during discovery that it already has a security context established and / or wishes to reuse a security context if available, so that an inter-UE relay that is provided with a policy that supports / does not support this approach may decide whether to establish / not establish a link with the end UE.

[0272] In one embodiment, the source UE sends a first message corresponding to a preferred security procedure for the path switch, e.g., as agreed upon during an initial security establishment procedure across the first UE-to-UE relay. The second UE-to-UE relay then evaluates its local strategy and determines whether the security procedure is suitable. If not, the second UE-to-UE relay, e.g., rejects the request, ignores the request, and / or indicates to the source UE that a different security procedure for the path switch is required.

[0273] In one embodiment, the source UE obtains the inter-UE relay's preferences regarding the type of security establishment to use, e.g., depending on coverage conditions or the services offered. These preferences are obtained, e.g., during an initial security establishment procedure over the first inter-UE relay, and / or by other means, e.g., by listening and receiving discovery messages from the second inter-UE relay indicating its preferences or coverage conditions. Based on this information, the initial negotiation between the source UE and the target UE during the initial security establishment procedure over the first inter-UE relay, and / or local policies at the source UE, the source UE selects the security procedures to use during the path switch.

[0274] Generally, a method and apparatus are proposed for negotiating security procedures between a source UE and a target UE when switching a path from a first inter-UE relay to a second inter-UE relay, the method and apparatus being adapted to perform one or more of the following steps: a) receiving a configuration / policy and determining path switching security procedures; b) negotiating, during a first security establishment procedure across a first inter-UE relay, a negotiated preference for a subsequent path switching procedure. c) receiving information about the coverage status of the second inter-UE relay. d) selecting a security procedure for the path switching based on at least one of the following: a. Structure / Measures, b. Negotiated preferences, and c. Coverage state of the second inter-UE relay.

[0275] Protecting DCR messages and establishing PC5 security in integrated discovery TR 23.700-33 describes the need for discovery integrated into the PC5 unicast link establishment procedure in UE-to-UE relay scenarios. This procedure can largely reuse the mechanisms of the restricted discovery procedure and the direct security establishment procedure defined in TS 33.503. However, in such an integrated procedure, the source UE does not search for a suitable UE-to-UE relay by discovery messages, but instead relies on a direct communication request, i.e., the direct communication request is made in an integrated manner.

[0276] This is illustrated by Figure 6, in which a source UE, an inter-UE relay, and a target UE interact with each other to establish a PC5 unicast link. In a first step 601, the UE is configured, if authorized, with e.g. keying material. In step 602, the source UE sends a message DCR to the inter-UE relay. In step 603, the message DCR is processed. In step 604, the inter-UE relay sends a message DCR' to the TUE.

[0277] TS33.503 describes how to protect discovery messages (Section 6.1.3.2.3). TS33.503 also describes how to protect specific fields of the DCR message in a UE-to-network relay scenario (Section 6.3.5). However, these procedures do not address how to protect the DCR message in a UE-to-UE relay joint discovery use case.

[0278] One object of the present invention is to address this problem.

[0279] In one embodiment, which can be combined with other embodiments, the security information field of the DCR message with the joint discovery is sent unprotected.

[0280] The first consideration is that the discovery message is scrambled / confidentiality protected / integrity protected as per TS33.503 section 6.1.3.2.3. The DCR message per section 6.3.5 is integrity protected and partially encrypted. A problem arises because message DCR (step 602) and message DCR' (step 604) do not have the same format and therefore the protection routines cannot be reused.

[0281] For example, assuming that the DCR contains (encapsulates) standard discovery messages, e.g., UE-UE discovery messages to discover a target UE and its target UE and UE-UE relay, the security mechanisms specified in TS 33.503 clause 6.2 are used in subsequent steps to establish a secure connection, which refers to TS 33.536 clause 5.3.

[0282] In one embodiment, the entire DCR is protected as if it were a discovery message, as per or similar to TS33.503 section 6.1.3.2.3. Some modifications are required. - Scrambling is not limited to 32 bytes, as DCR' messages are longer and / or have more sensitive fields. - The scrambled bytes are intended to hide the initial part of the encapsulated discovery message. - The DCR' message is structured to contain the discovery message (fields) at the beginning of the DCR' message followed by the remaining fields of the DCR message (e.g. PRUK ID, nonce, or other parameters) so that the security routines of TS 33.503 clause 6.1.3.2.3 can be applied.

[0283] A further embodiment is to protect some fields of the DCR' message similar to section 6.3.5 of TS33.503, and the fields encapsulating the discovery message as in section 6.1.3.2.3 of TS33.503. When receiving a message, the receiver first retrieves the discovery message (unscrambling, decryption, MIC verification), and then retrieves the remaining fields of the DCR' message.

[0284] In a further embodiment, since the relay UE does not recognize the discovery code (eg, relay code) included in the discovery message when the DCR' message is received, the DCR' message is verified by performing blind decoding / unscrambling.

[0285] In a further embodiment, the UE (e.g., UE-to-UE relay / target UE) needs to try multiple keys (e.g., scrambling keys) to access the message type, relay service code, and / or other identifier type of the DCR (DCR') message that can be used to determine the integrity / encryption key to use in processing the DCR (DCR') message. This is different compared to the processing of the DCR message in TS33.503 section 6.5.3, where the U2N relay already knows which key to use based on a previous discovery phase.

[0286] In a further embodiment, a field of the DCR' message is useful (ie, included and used) to determine whether the RSC, encryption key, or integrity key has been scrambled.

[0287] In a further embodiment, one or more pre-configured keys (e.g., linked to the RSC) are used to protect fields of the DCR (except the aggregate discovery message), and a discovery key is used to protect the aggregate discovery message.

[0288] In a further embodiment, the integrated discovery message includes a field (e.g., integrated_discovery_indication) that is on or off (or present / absent) and determines whether discovery is integrated and / or whether discovery is protected. This field is also integrity protected to ensure that an attacker cannot reflect the discovery message of the integrated discovery message as a normal discovery message.

[0289] In a further embodiment, the indication (eg, the synthetic discovery indication) indicates whether the message is protected or not.

[0290] In a further embodiment, the instruction (e.g., an aggregate discovery instruction) indicates the type of protection (e.g., confidentiality and / or integrity) being applied to the aggregate discovery message and / or indicates whether the protection is applied to the aggregate discovery message or the entire DCR message.

[0291] In a further embodiment, the indication (e.g., joint discovery indication) functions to enable interoperability with V2X-enabled devices.

[0292] In another variant embodiment, the integrated_discovery_indication is confidentiality and / or integrity protected as part of the direct discovery set element.

[0293] In a further embodiment, a relay service code (RSC) provided at the UE (e.g., source, target, and inter-UE relay) implicitly indicates whether discovery is integrated and / or whether discovery is protected.

[0294] In another variant embodiment, the ProSe restriction code provided at the end UEs (eg, source UE and target UE) implicitly indicates whether the direct discovery sets are integrated or not.

[0295] Other embodiments of the present application are applicable, for example those that rely on two sets of discovery keys.

[0296] Other embodiments of the present application, for example applicable to UE-to-UE relay discovery security, are applicable.

[0297] In one embodiment, the UEs (e.g., source UE and target UE) are provided with two sets of keying material, such that a first set of keys (e.g., DP_S-T) is used to protect direct discovery set elements, and a second set of keys (e.g., DP_S-UE-to-UE and / or DP_UE-to-UE-T) is used to protect UE-to-UE discovery set elements, the entire UE-to-UE discovery message, portions of the DCR message (e.g., sensitive fields in the DCR message and discovery message), or the entire DCR message. Note that here and elsewhere in this specification, direct discovery set (elements) and UE-to-UE discovery set (elements) refer to the two sets of elements in the discovery message.

[0298] In another variant embodiment, the source UE uses a first set of keys (e.g., DP_S-T) to protect the direct discovery set elements and a second set of keys (e.g., DP_S-UE-to-UE) to protect only the UE-to-UE discovery set elements, for example, so that the target UE can recover the direct discovery set when it receives a DCR message with joint discovery directly from the source UE.

[0299] In another variant embodiment, DP_S-UE-to-UE is used to integrity protect the entire DCR message so that the repeater can verify the entire DCR message, but DP_S-UE-to-UE is only used to scramble / confidentiality protect fields required by the repeater itself.

[0300] In one embodiment, the joint discovery message includes an indication that determines whether the message is protected with a single set of keys (e.g., DP_S-UE-to-UE / DP_UE-to-UE-T) or with two sets of keys (e.g., DP_S-UE-to-UE / DP_UE-to-UE-T and DP_S-T).

[0301] In one embodiment, if the DCR message includes the user information ID of the target UE and the UE-to-UE relay receiving the DCR message has an already established secure context for the target UE, the DCR' is protected based on the key pair corresponding to the established secure context.

[0302] In one embodiment, when a source UE and a target UE have an established connection and one of the end UEs decides to path switch (e.g., due to link degradation) to communicate through a UE-to-UE relay, the end UE maintains and reuses the already established security context (e.g., security policies and algorithms) after hop-by-hop secure links are established between the source UE and the UE-to-UE relay and between the UE-to-UE relay and the target UE.

[0303] In one embodiment, a UE, e.g., a target UE, transmits one or more messages (types) over one or two paths, e.g., - DCR message from the UE-to-UE relay; - a DCR message from the source UE; - Direct discovery messages, and / or - UE-UE discovery messages, When receiving a UE, one or more UEs (e.g., source UE, target UE, and / or UE-to-UE relay UE) are (pre)configured or defined with a strategy indicating which communication paths and / or message types are preferred.

[0304] A UE, such as a target UE, may be configured to prioritize certain messages or paths, such as direct communication with a source UE, depending on the strategy and / or communication conditions (e.g., coverage conditions, signal strength, etc.), which may allow for a better handling of the overall discovery process. - What keying material is used to protect which data fields of the DCR message. For example, the DCR message is protected with one or two sets of keys to protect the UE-UE discovery message fields and another set of keys to protect DCR fields other than the UE-UE discovery message. Otherwise, the DCR message is protected with two sets of keys, where the DCR message fields are protected with DP_S-UE-to-UE / DP_UE-to-UE-T keying material and DP_S-T keying material. - What form of protection is applied, under what conditions, and on which data fields of the DCR message (e.g., which fields are scrambled / encrypted and integrity protected, which are only integrity protected, and using which keys). - If the target UE receives the DCR message directly from the source UE and chooses to communicate directly with the source UE, how the target UE handles the UE-to-UE discovery set elements (e.g., Relay Indication, RSC), e.g., how it verifies the DCR MIC and discards the UE-to-UE discovery set and processes (e.g., unscrambles / decodes / integrity verifies only the direct discovery set). - Which security mechanism is used by the UE-to-UE relay to protect the DCR', based for example on whether the DCR message contains the user information ID of the target UE or whether there is an already established security context between the UE-to-UE and the target UE.

[0305] In general, a distinction can be made between two scenarios: the DCR message broadcast by the source UE may either be relayed by one (or more) UE-to-UE relay(s) or may be received directly by the target UE. Regardless of how the DCR message reaches the target UE, the target UE should always be able to process the received message, e.g., always be able to unscramble, decode, and / or verify the integrity of the content of the received DCR message (e.g., a discovery message). Therefore, the following is taken into consideration:

[0306] In one embodiment, the same security material (e.g., encryption / scrambling / integrity keys) can be used to protect the first hop-by-hop link (i.e., between the source UE and the UE-to-UE relay) and the second hop-by-hop link (i.e., between the UE-to-UE relay and the target UE) so that the DCR message can be decrypted, unscrambled, and / or integrity verified regardless of whether the target UE receives the DCR message directly or through the UE-to-UE relay.

[0307] In other embodiments, the inter-UE relay is (pre)configured or defined with a strategy that determines how the DCR message with joint discovery should be structured and protected when relayed to the target UE, for example depending on whether the inter-UE relay can identify the target UE (i.e. depending on whether the DCR contains the user information ID of the target UE) and / or if the inter-UE relay already has a security context established with said target UE. For example: Example 1: If the UE-to-UE relay cannot identify the target UE (e.g., the target UE's user information ID is not included in the DCR message), the UE-to-UE relay processes the DCR message (unscrambling, decoding, and / or integrity verifying the discovery message). If the required verifications are successful, the UE-to-UE relay constructs another DCR message (e.g., DCR'), where the UE-to-UE relay protects the UE-to-UE discovery set elements in the same way as the source UE, e.g., by discarding the relay_indication, including an integrated discovery indication, and / or modifying the RSC to add the UE-to-UE relay's user information ID to DCR'. If applicable, the UE-to-UE relay reuses the security material (e.g., first hop-by-hop security material) used to protect the UE-to-UE discovery set in the DCR message to protect the UE-to-UE discovery set in DCR' (e.g., second hop-by-hop security material, i.e., keeping the same RSC). Alternatively, the inter-UE relay may use a different security material than that used in the first hop-by-hop link, ie, change the RSC of the DCR', and finally broadcast the secured DCR' message.

[0308] Example 2: A UE-to-UE relay processes a DCR message (e.g., similar to the scenario above) and identifies the target UE (e.g., via the target UE's User Info ID or Destination Layer 2 ID). If a security context is already established with this target UE, the UE-to-UE relay constructs a subsequent message (e.g., DCR') as follows: it discards the relay_indication and includes the joint discovery indication if the security context is not already included, and includes only the direct discovery set of elements from the joint discovery message. The whole message (or part of it) is then protected based on the keying material corresponding to the established security context.

[0309] In another embodiment, the UE-to-UE relay can identify the target UE (e.g., through the target UE's User Info ID or the target UE's Destination Layer 2 ID in the DCR message), in which case the UE-to-UE relay establishes a secure unicast link with the target UE according to the procedures defined in clause 5.3 of TS33.536, and the UE-to-UE relay sends a DCR' (including the UE-to-UE Relay Info User ID) containing the end-to-end protected direct discovery set in addition to Key_Est_Info / security information used for direct authentication and key establishment between the UE-to-UE relay and the target UE.

[0310] In one embodiment, the target UE user information ID is secured as part of the UE-to-UE discovery set so that the UE-to-UE relay can identify the target UE when a DCR message with joint discovery is received.

[0311] In a further embodiment, the source UE calculates a pseudonym (PID) based on an ID, e.g., PID=Hash(target UE's User Info ID), as a function, e.g., a one-way function, e.g., a cryptographic function. The source UE sends the PID as part of the UE-to-UE discovery set or unprotected in another field of the DCR message. This approach is particularly applicable when the target UE's User Info ID is long enough.

[0312] In another variant embodiment, the source UE adds a salt / nonce as a parameter to the function used to calculate the PID to avoid dictionary attacks, e.g., PID=Hash(Salt, UserInfoID of target UE). The salt / nonce value is protected and transmitted as part of the UE-to-UE discovery set.

[0313] In another embodiment, the UE-to-UE relay uses the received PID and / or the received ID to determine whether the UE-to-UE relay already has a secure connection with the target UE, which allows the UE-to-UE relay to protect the message (e.g., direct discovery set) with the corresponding key / keys from the already established security context.

[0314] In another variant embodiment, if the source UE has the destination Layer 2 ID of the target 5G ProSe terminating UE, it is transmitted instead of or together with the target UE's user information ID as described in the above embodiment, while the target UE's user information ID is protected and transmitted as part of the direct discovery set.

[0315] In another embodiment, the UE-to-UE relay can identify the target UE (e.g., through the target UE's User Info ID or the DCR message's Destination Layer 2 ID) and may have already established a secure link with the target UE (e.g., through a previous link setup with another source UE). In such a case, the UE-to-UE relay transmits the DCR' message protected using security material from the already established security context. Furthermore, because a secure link is already established, the direct authentication and key establishment and direct security mode command procedures are skipped between the UE-to-UE relay and the target UE.

[0316] In another embodiment, the inter-UE relay uses a default destination Layer 2 ID as specified in TS 23.304, clause 5.1.5.1, which is associated with a target UE with which the inter-UE relay has already established a secure link. In this case, similar to the above embodiment, the inter-UE relay reuses the established security context and associated keying material to protect the DCR' when relaying it to the target UE. In other words, there is a mapping between the default destination Layer 2 ID and the target UE, so the inter-UE relay knows which keying material to use given the default destination Layer 2 ID.

[0317] In another embodiment, if the UE-to-UE relay receives a DCR message with joint discovery and has already established a secure link with the target UE, the UE-to-UE relay removes the UE-to-UE discovery set elements (e.g., RSC, security information) from the DCR′ sent to the target UE.

[0318] In another variant embodiment, the reuse of an existing security context of an end UE (e.g., a target UE) by an inter-UE relay is not limited to an integrated discovery scenario, but may also be applied to, for example, a normal discovery procedure. That is, during the discovery phase, when a source UE intends to establish a secure link with a target UE through an inter-UE relay, if the inter-UE relay has already established a secure link with the target UE, the inter-UE relay reuses keying material associated with the established context. The reuse of an existing security context by an inter-UE relay may also be applied to other security procedures. For example, Sol#3 of TR33.740 v0.7.0 describes how a secure link is established between two end UEs with network assistance. If UE1 and UE2 are already communicating through an inter-UE relay, and UE3 wants to communicate with UE2 through the same inter-UE relay, UE3 and the inter-UE relay need to establish a secure link as described in Sol#3 of TR33.740, but the security context between UE2 and the inter-UE relay may be retained and reused and does not need to be re-established.

[0319] In other embodiments, all or part of the embodiments relating to reusing an existing security context between an inter-UE relay and an end UE (e.g., a target UE) may be combined with other embodiments or used independently and are applicable to the integrated discovery procedure and the normal discovery procedure.

[0320] In another embodiment, if the inter-UE relay has to broadcast the DCR', the inter-UE relay cannot identify the target UE. According to clause 5.5.3.1 of TS33.536, no specific procedure is defined to secure the PC5 broadcast mode under NR, therefore the inter-UE relay protects the DCR' as if it were a discovery message as or similar to clause 6.1.3.2.3 of TS33.503, with necessary modifications applied as described in the above embodiment.

[0321] In another variant embodiment, if the inter-UE relay supports multiple protection mechanisms, the choice of security mechanism to be employed is configured by the network (e.g., through a policy), and the inter-UE relay includes in the DCR' message an indication of which protection mechanism was used to protect the message.

[0322] In another embodiment, if the UE-to-UE relay is within 3GPP® coverage, the network assists, e.g. by providing keying material such as DUIK / DUSK / SUCK to scramble / encrypt / integrity protect the DCR' message and / or by providing security measures, e.g. to decide which security method to employ (e.g. establish a new secure link or use an established security context).

[0323] In another embodiment, referring to FIG. 2 , the use of the above technique is shown, where the UE-to-UE relay is within 3GPP® coverage and supported by the network, and establishment of hop-by-hop secure links between the source UE and the UE-to-UE relay and between the UE-to-UE relay and the target UE is performed as follows, where (1) not all steps are always required, (2) some steps are performed multiple times, and (3) some steps are performed in a different order.

[0324] Where 1401 represents an end UE (e.g., a source UE), 1402 represents an inter-UE relay, 1403 represents an end UE (e.g., a target UE), and 1404 represents a 5GC, a secure hop-by-hop link between UEs is established as follows: Step 1410: When the UE is in coverage, it is provided with discovery parameters, keying material for establishing a PC5 secure communication link, etc. Step 1411: Construct a DCR message with joint discovery, similar to step 1 of Fig. 12. The source UE uses PRUK-ID1 and K NRP1 Include a freshness parameter 1 in the security information field (e.g., as defined in TS 23.304, subclause 6.4.3.7.4). The synthetic discovery message is protected in the same manner as in step 1 of Figure 12 (i.e., using the discovery security material provided in step 1410). - Step 1412: The source UE broadcasts a protected DCR message with joint discovery. Step 1413: The inter-UE relay processes the received DCR message, decrypts / unscrambles / integrity verifies the protected joint discovery / DCR message, and decrypts RSC1, PRUK-ID1 and K NRP1 extract the freshness parameter 1, construct a DCR' including the user information ID, and send the DCR' to the target UE, where the DCR' message contains some of these parameters, e.g., RSC, which is privacy protected while the DCR' is integrity protected; 1 / 2 Includes. Step 1414: The inter-UE relay transmits the DCR' to the target UE. This step may occur before, after, or simultaneously with steps 1415 and 1416. Step 1415 / 1416: The UE-to-UE relay receives RSC1, PRUK-ID1 and K NRP1 Send a key request to the 5GC that includes one or more of the freshness parameters 1, and then receive K from the 5GC. NRP1 and K. NRP114. This step also occurs later, for example after a secure connection between the UE-to-UE relay and the target UE has been established. Message 1415 contains the identity of the target UE (PRUK-ID2), so the core network can verify whether the source UE is authorized to communicate with the target UE. If steps 1415 / 1416 are performed earlier (for example before step 1414), the UE-to-UE relay can be sure that the source UE has authorization and therefore the target UE will only receive the DCR' message in this case. If steps 1415 / 1416 are performed later, for example after step 1414, or even after steps 1419 / 1420, the UE-to-UE relay can be sure that the target UE is authorized / willing to communicate with the source UE and therefore only the core network is involved in this case. Step 1417: The target UE receives multiple DCR messages (e.g., from one or more UE-to-UE relays). For simplicity, Fig. 2 shows a single DCR message, e.g., DCR', as sent in step 1414. The target UE processes the DCR' message and decrypts / unscrambles / integrity verifies the protected joint discovery / DCR message, after which, based on whether a security context is already established with the UE-to-UE relay and on the strategy evaluation, the target UE decides whether to (re-)establish a secure link with the UE-to-UE relay. Step 1418: When the target UE (re)establishes a secure link with the UE-UE relay, the target UE receives RSC2, PRUK-ID2 and K, which are protected in the same way as in step 1411. NRP2 Send a direct authentication and key establishment request with a freshness parameter of 1. Step 1419 / 1420: Similar to step 1415 / 1416, the UE-to-UE relay sends the parameters (i.e. RSC2, PRUK-ID2 and K NRP2 Send a key request to 5GC along with the freshness parameter 1) and NRP2 and K. NRP2A key response message is received which includes freshness parameter 2. In steps 1419 / 1420, the UE-to-UE relay also includes the identity of the source UE (PRUK-ID1) so the 5GC can verify whether both UEs are authorized to communicate with each other. Step 1421: The inter-UE relay NRP2 a direct security mode command procedure for transmitting a freshness parameter 2 to a target UE in a direct security mode command message, wherein the target UE NRP2 PRUK, RSC2, K NRP2 Freshness parameters 1 and K NRP2 It is derived from freshness parameter 2. Successful verification of the direct security mode command assures the target UE that the UE-to-UE relay is authorized to provide relay services. If the verification is successful, the target UE sends a direct security mode complete message to the UE-to-UE relay. Step 1422: Upon receiving the direct security mode complete message from the target UE, the inter-UE relay verifies whether the target UE is authorized to obtain relay service, and if the verification is successful, the inter-UE relay sends a direct communication accept message to the target UE to complete the secure link establishment procedure. - Step 1423 / 1424: Similar to steps 1421 / 1422, a secure link is established between the source UE and the UE-to-UE relay. Step 1425: If the inter-UE relay communication link is established through the layer 2 inter-UE relay, an end-to-end secure link is established between the end UEs (ie, the source UE and the target UE). Steps 1423 and 1424 are performed after step 1416, simultaneously, or after a secure link is established between the UE-to-UE relay and the target UE.

[0325] In one embodiment, in step 1421, the UEs NRP2 The target UE then sends a direct authentication and key establishment response including the freshness parameter 2 to the target UE. NRP2 PRUK, RSC2, KNRP2 Freshness parameters 1 and K NRP2 After that step, the target UE sends a direct security mode command message to, for example, K NRP2 The inter-UE relay then sends a security mode complete message to the target UE, e.g., K NRP2 Upon receiving the security mode complete message verification, the target UE is assured that the UE-to-UE relay is authorized to provide relay services, and then (e.g., in step 1422) sends a direct communication accept message to the UE-to-UE relay to complete the secure link establishment procedure.

[0326] In a related embodiment, which may be combined with other embodiments or used independently for joint discovery, the DCR' sent from the UE-to-UE relay to the target UE (at step 1414) does not include the PRUK-ID, and therefore the DCR' is integrity protected while only RSC2 is confidentiality protected. Thus, the confidentiality protection routine in clause 6.3.5 of TS33.503 is updated so that only the RSC is encrypted. Thus, in Annex A.5 of TS33.503, the DCR confidentiality keystream is set to the L least significant bits of the output of the KDF, where L = the length of the RSC.

[0327] In a variant embodiment, the DCR' sent in the step from the UE-to-UE relay to the target UE does not include the PRUK-ID, and therefore the PRUK-ID field is set to a predetermined value (e.g. all zeros) or a random value so that the confidentiality protection routines defined in TS33.503 clause 6.3.5 can be reused to protect the PRUK-ID and RSC. The predetermined value of the PRUK-ID is discarded when it is received, decoded, unscrambled and / or integrity verified by the target UE. A further difference compared to clause 6.3.5 of TS33.503 is that in joint discovery there is no previous discovery phase, therefore in related embodiments, whether combined with other embodiments or used independently for joint discovery, the UE-UE relay and target UE must perform blind decoding / integrity verification upon receiving messages DCR (step 1413) and DCR′ (step 1417) instead of verifying the integrity of the received DCR message by using the code transmission security parameters used for discovery as specified in clause 6.3.5.3 of TS33.503 and / or verifying whether the RSC matches the one sent in the discovery message as specified in clause 6.3.5.2 of TS33.503.

[0328] While the UE-to-UE relay does not know which key to use to integrity verify and decrypt the DCR message (step 1413), the UE-to-UE relay does know which key will be used when receiving a message from the target UE containing the target UE's PRUK-ID2, RSC2 (i.e., associated with RSC2 sent in the DCR'). Thus, in a different embodiment, which may be combined with other embodiments for joint discovery or used independently, the UE-to-UE relay decrypts / integrity verifies (step 1418) the message received from the target UE using the key that was used to encrypt / integrity protect (step 1413) the DCR' message. This requires the UE-to-UE relay to keep track of the keys used for step 1413 to protect the DCR' message, and this tracking / storage may be limited to the number of keys and / or time limits.

[0329] In an alternative embodiment, which may be combined with other embodiments or used independently for joint discovery, if the same RSC is used between the source UE and the UE-to-UE relay and between the UE-to-UE relay and the target UE, the UE-to-UE relay performs blind decryption / integrity verification upon receiving the DCR (step 1413) and then reuses the key (associated with the RSC) to derive a keystream for confidentially protecting the RSC and integrity protecting the DCR'. The target UE performs blind decryption / integrity verification upon receiving the DCR' (step 1417) and reuses the same key (associated with the RSC) to confidentially protect the PRUK-ID and RSC and integrity protect the message transmitted to the UE-to-UE relay (step 1418). The UE-to-UE relay then decrypts / integrity verifies the message received from the target UE using the same key used to protect the DCR and DCR' messages. In one embodiment, which may be combined with other embodiments or used independently for joint discovery, the DCR with the joint discovery message is received directly by the target UE. In such a case, the target UE processes the message differently than when the message is relayed by an inter-UE relay. That is, the target UE does not need to decode the RSC and PRUK-ID, and the target UE only performs a blind integrity verification of the DCR with the joint discovery message including the decoded PRUK-ID and RSC, and if the integrity verification is successful, the target UE discards the PRUK-ID and RSC. Alternatively, the target UE does not integrity verify the message. A communication link between the source UE and the target UE is then established according to the procedure described in 5.3 of TS33.536.

[0330] In one embodiment, the steps required to establish a hop-by-hop secure link are repeated / retried (e.g., in case of failure) a number of times (e.g., N times) determined by a strategy defined in the UEs (i.e., relay UE and end UE), e.g., in step 1410.

[0331] In another embodiment, if the target UE receives multiple DCR messages with joint discovery (e.g., from multiple UE-to-UE relays), the target UE determines that a secure link with the relay is already established. If the target UE selects a UE-to-UE relay (e.g., according to the strategy evaluation and path selection steps), steps 1418, 1419, 1420, 1421, and 1422 are skipped, and instead the target UE sends a direct communication accept message to the UE-to-UE relay.

[0332] In another variant embodiment, the steps performed between the target UE and the UE-to-UE relay to establish the second hop-by-hop secure link are reversed: the target UE initiates a security mode command procedure (e.g., at step 1418) and sends its RSC2, PRUK-ID2, and K NRP2 Providing a freshness parameter of 1, steps 1419 and 1420 remain the same, and upon successful verification that the target UE is authorized to receive the relay service, in step 1422 the inter-UE relay NRP2 The freshness parameter 2 is transmitted to the target UE in a direct security mode complete message, and the target UE transmits its PRUK, RSC2, K NRP2 Freshness parameters 1 and K NRP2 Freshness parameters 2 to K NRP2 Successful verification of the direct security mode complete message assures the target UE that the UE-UE relay is authorized to provide relay services. If the verification is successful, the target UE sends (in step 1422) a direct communication accept message to the UE-UE relay to complete the secure link establishment procedure.

[0333] In other embodiments, the end UEs provide their SUCI / GUTI in addition to or instead of their PRUK-ID in step 1411 (for the source UE) and step 1418 (for the target UE) for identification, authentication, and / or authorization purposes.

[0334] The exchanged security parameters are also applicable to other related variants, where one or more of the source UE, target UE, and UE-to-UE relay may be out of coverage, and / or the UEs agree to or are configured to use security procedures without network assistance. In this variant, key request / key response messages with the 5GC are not used. The keying material includes an authorization token (similar to Sol#4 of TR33.740) or a long-term certificate that enables the establishment of a PC5 security link. Regarding the authorization token, an authorization token (AT) is provided by the 5GC. The AT from the source UE is sent in message 1412 and verified by the UE-to-UE relay upon receiving message 1412. If the verification is successful, the UE-to-UE relay forwards its own AT and potentially the source UE's AT in step 1414 (DCR'). The target UE verifies the authorization upon receiving message 1414. The target UE then transmits its AT in message 1418, and upon receiving 1418, the UE-UE relay verifies the target UE's authorization. In another embodiment, which may be combined with other embodiments or used independently, steps 1415 / 1416 and 1419 / 1420 of Fig. 2 are further performed in parallel. In other words, the key request messages to the 5GC in steps 1415 and 1419 include RSC1, PRUK-ID1, K NRP1 Freshness parameters 1, RSC2, PRUK-ID2, and K NRP2 The key response message from the 5GC in step 1416 / step 1420 is combined to include one or more of the freshness parameters K NRP1 , K. NRP1 Freshness parameter 2, K NRP2 , and K NRP2The combined key request message is combined to include freshness parameter 2. The transmission of the combined key request message occurs after the target UE replies to the UE-to-UE relay with a direct authentication and key establishment request message (step 1418). This approach reduces the number of round trips to the 5GC, thereby reducing latency. It also allows the 5GC to verify whether the UE-to-UE relay is authorized to establish a communication link between the source UE and the target UE in a single step. This variant embodiment is applicable to other types of security establishment at the UE-to-UE relay, for example, it is applicable to standard PC5 security establishment procedures with network assistance, such as Sol#3 of TR33.740.

[0335] In another variant embodiment, security parameters included in the DCR message with the integrated discovery (e.g., DCR'), such as the PRUK-ID or authorization token, are protected by the discovery material and / or an existing security context as in other embodiments.

[0336] From the target UE side, a distinction can be made between several scenarios. For example, the target UE receives multiple DCR messages, e.g., directly from the source UE and / or from one or more UE-to-UE relays, with the UE-to-UE relays potentially utilizing different security mechanisms, e.g., as described in the UE-to-UE relay security establishment option above. Since the target UE performs the path selection, the target UE is (pre)configured / defined with a strategy for determining how such a path is selected (e.g., via a direct link or a UE-to-UE relay) to establish a communication link with the source UE. The path selection depends on factors including, but not limited to, signal strength, optimization requirements (e.g., a UE-to-UE relay with which a security context is already established is preferred over a UE-to-UE relay that requires a key establishment step to establish a secure link), and / or relay avoidance (e.g., a direct link with the source UE is preferred whenever possible, since a direct link with the source UE minimizes the security procedures the target UE needs to perform to establish a secure link). Based on the target UE's strategy, the received DCR messages are handled according to one or more of the following embodiments.

[0337] In one embodiment, when the target UE receives multiple DCR messages from one or more UE-to-UE relays, the target UE will prioritize a link with one of the relays with which a security context is already established, which has the advantage that the target UE can skip the Direct Authentication and Key Establishment and Direct Security Mode Command procedures and thus more efficiently establish a connection with the source UE.

[0338] In one variant embodiment, when the target UE receives multiple DCR messages from multiple UE-to-UE relays, the target UE decodes / unscrambles / integrity verifies the received DCR messages, and based on the UE-to-UE relay user information ID in the discovery set, the target UE can determine whether a security link with the UE-to-UE relay has already been established.

[0339] In one variant embodiment, when the target UE receives multiple DCR messages from multiple UE-to-UE relays, the target UE (1) uses the L2 address to determine whether a security link is already established with one of the UE-to-UE relays, and (2) uses it to retrieve a security context (e.g., a key pair) to be used to decrypt / unscramble / integrity verify the received DCR messages.

[0340] In one alternative embodiment, if one set of security material is used, the UE-to-UE relay identifies the target UE (e.g., through its user information ID). The UE-to-UE relay then transmits to the target UE a message that includes only the direct discovery set and is protected using the security material associated with the already established link. Alternatively, the UE-to-UE relay includes an integrated_discovery_indication in the message transmitted to the target UE.

[0341] In one variant embodiment, the target UE receives several DCR messages, for example from the source UE and from one of a number of UE-to-UE relays, and regardless of whether a security context exists or is established (e.g., with one of the UE-to-UE relays) and / or which security solution / mechanism is used, the target UE always prefers to establish a direct link with the source UE.

[0342] In another embodiment, when the target UE receives multiple DCR messages from different UE-UE relays, the target UE selects a preferred UE-UE relay based on several criteria, such as how the DCR' messages are protected and what is required to establish a secure link with the UE-UE relay. For example, if a UE-UE (e.g., UE-UE1) has already established a secure link with the T-UE and its DCR' message (e.g., DCR'1) is protected using the security material of the already established security context, and another UE-UE relay (e.g., UE-UE2) transmits a DCR' message (e.g., DCR'2) that is partially protected (e.g., only the discovery message is protected as per TS33.503 section 6.1.32.3), while the rest of the DCR' (e.g., Key_Est_Info) is unprotected, the target UE may select UE-UE1, e.g., because it is more efficient to establish a secure link with the source UE. Alternatively, the target UE may select UE-UE2, e.g., because the signal quality is better, so that the target UE does not need to resort to relay reselection if the link with UE-UE1 deteriorates.

[0343] In another embodiment, the target UE receives multiple DCR messages from different UE-to-UE relays at different times. For example, the target UE evaluates and selects a particular path and receives a DCR message from one of the UE-to-UE relays that has a higher priority (e.g., a security context has already been established). In such a case, the target UE strategy sets a timer to consider the received DCRs and discards any DCRs received after the timer expires.

[0344] In one embodiment, the target UE triggers a path switch or repeater reselection, e.g., based on link quality degradation, in which case the target UE indicates / informs the source UE of its intention to switch paths and whether security policies and algorithms will be maintained (i.e., not renegotiated over the reselected repeater), e.g., to optimize the path switch and security establishment measures.

[0345] In one embodiment, the target UE (or / and the inter-UE relay) checks whether the DCR message is protected by an indication, which may be the RSC used, a security indicator associated with the RSC, the presence of a PRUK-ID field, or the length of the message.

[0346] In one embodiment, if the DCR message with integrated discovery is protected, the target UE revokes the protection and verifies the freshness and integrity of the DCR message and whether the PRUK-ID field is set to a predetermined value (e.g., all zeros).

[0347] In one embodiment, if the DCR message with integrated discovery is protected, the target UE revokes the protection, verifies the freshness and integrity of the DCR message, and checks whether the included RSC is bound to a network-assisted security procedure.

[0348] In one embodiment, the relay indication is either independently protected (eg, integrity protected) or protected as part of the DCR message (eg, within a UE-UE discovery set).

[0349] In one embodiment, when two sets of discovery security material are used, the relay_indication is protected (e.g., integrity protected) by the source UE using end-to-end keying material (e.g., DP_S-T) that can be verified by the target UE when the joint discovery DCR message is received directly by the target UE. When the DCR message is received by the UE-to-UE relay, after discarding the relay_indication, the UE-to-UE relay replaces the end-to-end calculated MIC with a hop-by-hop calculated MIC so that the target UE can verify its integrity using DP_UE-to-UE-T when it receives the DCR message through the relay.

[0350] In one embodiment, if the joint discovery DCR message is relayed, the UE-to-UE relay protects (eg, encrypts / scrambles / integrity protects) the relay indication as part of the UE-to-UE discovery set.

[0351] In one embodiment, if only one set of discovery security material is used, the source UE protects the aggregate discovery message, including, for example, the source user information ID, ProSe service information, RSC, and, if included, the target UE user information ID, using the discovery security material associated with the RSC as per TS33.503 clause 6.1.3.2.3. If the source UE is configured with DUCK, or DUSK, and / or DUIK, the RSC and relay_indication are scrambled, encrypted, and / or integrity protected using DUCK, DUSK, and / or DUIK. Alternatively, the RSC and relay indication are protected using discovery security material.

[0352] In one embodiment, confidentiality protection of the integrated discovery message is based on the discovery confidentiality mechanism described in A.7 of TS33.503, and the input parameters to the encoding algorithm are: - Key: 128 least significant bits of the output of the KDF (DUCK, UTC-based counter, MIC) - Count: UTC-based counter - Bearer: 0x00 - Direction: 0x00 - Length: LEN(Discovery Message) - (LEN(Message Type) + LEN(LSB of UTC-based Counter) + LEN(MIC)), where LEN(x) is the length of x in bits; where LEN(Discovery Message) means the length of the (aggregated) discovery message, and / or - Message types in the integrated discovery scenario refer to the ProSe signal message types defined in Table 11.3.1.1 of Section 11.3.1 of TS 24.554.

[0353] In another embodiment, LEN(Discovery Message) in the integrated discovery scenario refers to the length of the integrated discovery message, including the direct discovery set (e.g., source UE user information ID and target UE user information ID) and the UE-UE discovery set (e.g., UE-UE relay user information ID, RSC), excluding other DCR fields (e.g., security information).

[0354] In another variant embodiment, LEN(discovery message) refers to the length of the entire DCR message including the aggregate discovery message.

[0355] The above embodiments are to be considered independently or in combination with one another where applicable.

[0356] In one variant embodiment, the process at the source UE when protecting the DCR message includes the following steps: 1. Construct a message m1 that includes direct discovery set elements, eg, source UE ID and target UE ID, and a subset of DCR fields, eg, integrated_discovery_indication. 2. Message m1 is integrity protected with a MIC computed over a DUIK configured with direct code transmission security parameters. The MIC is inserted into m1, e.g., by concatenation, appending, etc. 3. The privacy-sensitive fields of message m1 are confidentiality protected by DUSK or DUCK configured with the Direct Code Transmission Security Parameter (DP_S-T), resulting in protected message 1, pm1. 4. Construct message m2 (unprotected consolidated DCR message) containing pm1, the remaining fields of the DCR message (not included in m1, e.g. relay instructions), and UE-to-UE discovery set elements, e.g. RSC and UE-to-UE relay user info ID. 5. Message m2 is integrity protected with a MIC calculated over the DUIK configured with the UE-to-UE code transmission security parameters. The MIC is inserted into message m2. 6. The DUCK configured with the UE-to-UE code transmission security parameter (DP_S-UE-to-UE) confidentiality protects the privacy-sensitive fields of message m2, such as the RSC of the UE-to-UE discovery set. This results in protected message 2, pm2. 7. The privacy-sensitive fields of pm2, which need to be easier to access for performance reasons, are scrambled, thus resulting in a scrambled and protected message 2, spm2.

[0357] Spm2 is a protected DCR message with integrated discovery that may be conveyed by the source UE.

[0358] In one embodiment, similar to other embodiments, the protection of some fields of the integrated discovery message with specific keys is subject to a policy regarding whether, for example, DP_S-T (Direct Code Transmission Security Parameters) keys and DP_S-UE-to-UE (UE-to-UE Code Transmission Security Parameters) keys are used in protecting the integrated discovery message, and which keys (i.e., DUSK, DUCK, and / or DUIK in DP_S-UE-to-UE / DP_S-T) are used.

[0359] The pm1 field is excluded from subsequent protection in steps 5 and 6. This allows the pm1 field to be directly accessed by target UEs that receive the joint discovery message directly from the source UE.

[0360] In one variant embodiment, the process at the target UE when processing the received protected consolidated DCR message is as follows. 1. Check whether the relay_indication field is included. If it is included, the target UE can process pm1 directly in step 5. 2. Descramble message spm2 to obtain pm2 by using the inter-UE code received security parameters or an existing context with the inter-UE relay. 3. Remove confidentiality from message pm2 by using the inter-UE code received security parameters or an existing context with the inter-UE relay to obtain m2 and MIC. 4. Verify m2 by using the received m2, the received MIC, and the UE-to-UE code received security parameters or an existing context with the UE-to-UE relay. If the MIC verification is successful, remove the MIC and obtain pm1. 5. Remove the confidentiality of pm1 by using the direct code receive security parameters, thus obtaining m1 and MIC. 6. Verify the integrity of m1 by using the received m1, the received MIC, and the direct code received security parameters, and the PRUK-ID if it is a predetermined value. If the MIC verification is successful, remove the MIC and return m1. The PRUK-ID field is also removed if authentication is successful.

[0361] In one variant, steps 2, 3 and 4 always use the same UE-to-UE code reception security parameters, which has the advantage of adding another layer of security to pm1 through steps 5 and 6.

[0362] In one variant embodiment, if the target UE is configured with a policy that prioritizes reusing existing security context, for example between the target UE and a UE-to-UE relay, steps 2, 3 and 4 always use the existing context.

[0363] In one variant embodiment, the target UE determines whether a security context is available by checking the User Info ID or the Layer 2 ID of the UE-to-UE relay.

[0364] In one variant embodiment, the process at the UE-to-UE relay when processing the received protected consolidated DCR message is as follows. 1. Check whether the relay instruction is included. If not, the relay drops the DCR message. 2. Step 2, step 3 and step 4 are similar to the same steps in processing the protected DCR message by the target UE. 5. Construct a new message m2 (e.g., m2') by adding the UE-to-UE relay user information ID to the UE-to-UE discovery set, discarding the relay_indication, and optionally updating the RSC. If the RSC is associated with a network-assisted security indicator that indicates a security procedure with network assistance, the UE-to-UE relay further sets the PRUK-ID field to a predetermined value or discards the PRUK-ID field. 6. Steps 6, 7 and 8 are similar to steps 5, 6 and 7 of the source UE construction and protection of the DCR message, resulting in spm2', which is the scrambled and protected message m2'. 9.spm2' is a protected DCR message with joint discovery that can be relayed by UE-to-UE relays.

[0365] In an alternative embodiment, if the UE-to-UE relay reuses the same RSC, i.e. the same UE-to-UE code transmission security material, as used by the source UE, the protection in steps 6 and 7 also applies to pm1.

[0366] In one variant embodiment, after step 4, if the UE-to-UE relay has already established a security context with the target UE, the UE-to-UE discovery set is removed, and steps 6, 7, and 8 are based on the security keying material corresponding to the already established security context.

[0367] With reference to FIG. 10, where a secure PC5 link may be established between a source UE and a target UE through one or more inter-UE relays, the procedure can be described as follows.

[0368] The source, target and UE relays are specified with a security policy and two sets of discovery security materials and parameters to enable the establishment of a secure PC5 link.

[0369] 1. The source UE constructs a DCR message containing a direct discovery set, a UE-UE discovery set, and fields specific to the DCR message (integrated_discovery_indication and relay indication). The direct discovery set and integrated_discovery_indication are protected with the direct code transmission security parameter. The entire DCR message is protected with the UE-UE relay code transmission security parameter, and the direct discovery set and integrated_discovery_indication are not confidentiality protected.

[0370] 2. When the inter-UE relay receives the DCR message, it descrambles / decodes / integrity verifies the DCR message. If the integrity verification is successful, the inter-UE relay sets the relay indication to "off" and constructs another DCR message (e.g., DCR1 or DCR2) in the same manner as in step 1.

[0371] 2.a. If a relay, for example, UE-to-UE relay 1, identifies the target UE and a secure link with the target UE has already been established, the UE-to-UE relay 1 protects DCR1 using a security key corresponding to the security context with the already established target UE.

[0372] 2.b. If the relay, e.g., UE-to-UE relay 2, cannot identify the target UE or no security context has been established with the target UE, the UE-to-UE relay 2 protects the DCR2 using the UE-to-UE code transmission security parameters.

[0373] 3.a / b. The inter-UE relay 1 and the inter-UE relay 2 transmit the DCR1 and DCR2 to the target UE.

[0374] 4. The target UE receives several DCR messages (e.g., from one or more UE-to-UE relays). If applicable, the target UE unscrambles / decrypts / integrity verifies the DCR messages with the corresponding keys (either existing context or UE-to-UE code reception security parameters). The target UE then decrypts / integrity verifies the direct discovery set and integrated_discovery_indication using the direct code reception security parameters. Based on the strategy evaluation and path selection in step 4, a secure link is established in one of the following cases: Case 1 and Case 2.

[0375] Case 1: Assume that the target UE selects the communication path that passes through the inter-UE relay 1. 5.a. Since the security context is already established, the direct authentication and key establishment and direct security mode command procedures are skipped and instead the target UE sends a direct communication acceptance to the UE-to-UE relay 2.

[0376] 6.a / 7.a / 8.a correspond to the establishment of a secure link between the source UE and the inter-UE relay 1.

[0377] Finally, in step 9.a, an end-to-end secure link is established between the source UE and the target UE through the inter-UE relay 1.

[0378] Case 2: Assume that the target UE selects the communication path that passes through the inter-UE relay 2. 5.b / 6.b / 7.b correspond to the establishment of a secure link between the inter-UE relay 2 and the target UE.

[0379] 8.b / 9.b / 10.b correspond to the establishment of a secure link between the inter-UE relay 2 and the source UE.

[0380] Finally, in step 11.b, an end-to-end secure link is established between the source UE and the target UE through the inter-UE relay 2.

[0381] Secure hop-by-hop or end-to-end links between the inter-UE relay 2 and the end UE, between the inter-UE relay 1 and the source UE, and between the end UEs are established according to clause 5.3 of TS33.536 based on the security information in the DCR message.

[0382] The above embodiment, in which an existing security context (e.g., between an UE-to-UE relay and a target UE) is reused upon receipt of a DCR message, applies to other procedures, e.g., solutions #3 or #4 of TR33.740, which describe security procedures for establishing a secure PC5 communication link after a discovery procedure.

[0383] 11, where a secure PC5 link may be established between the source UE and the target UE directly or through a UE-to-UE relay, the target UE needs to be able to process the incoming consolidated DCR message regardless of the direct or indirect path taken. This requires that the target UE has access to the direct discovery set as described in the above embodiment; e.g., security material related to the RSC and intended to protect hop-by-hop messages is not used to confidentiality protect the direct discovery set, which is protected with the key set related to the ProSe service.

[0384] The DCR message by the UE-to-UE relay (ie, step 3) and the establishment of the secure link through the relay (ie, steps 6.a to 12.a) are similar to the process and secure link establishment through the UE-to-UE relay 2 in FIG.

[0385] The target UE processes message 2.b in the same way as the DCR' received in step 4. If the relay indication is not set, the target UE will prioritize a direct link with the source UE and establish a link with the source UE after steps 6.b, 7.b, and 8.b.

[0386] In some cases, some configurations are implicitly or explicitly indicated in the DCR message itself.

[0387] The solution related to TR33.740 v0.5.0 in section 6.30 is as follows:

[0388] The 5G ProSe source UE and the 5G ProSe inter-UE relay encrypt the source user information ID, relay user information, target user information ID, and RSC as follows: 1) If the UE is configured with a discovery user confidentiality key (DUCK) / discovery user scrambling key (DUSK), the DCR encoding key KDCR is set to DUCK / DUSK. If the UE is not configured with DUCK / DUSK, the DCR message is not protected and steps 2 and 3 are skipped. 2) Set the keystream to the DCR confidentiality keystream calculated using KDCR, a UTC-based counter, bearer, direction, and length as described in Annex A.7 of TS33.503 [6]. 3) The message is XORed with the keystream.

[0389] However, this approach only addresses privacy / confidentiality protection, not integrity protection. Furthermore, no distinction is made between protecting the DCR message in the joint discovery transmitted by the source UE and protecting the DCR message in the joint discovery transmitted by the UE-to-UE relay. For example, the UE-to-UE relay user information ID is not part of the joint discovery message transmitted by the source UE. This approach also assumes that only one set of security material is used to protect both the direct discovery set and the UE-to-UE discovery set of the discovery message. Therefore, it is the purpose of the following embodiments to address these shortcomings.

[0390] In one embodiment related to other embodiments, if DUCK is available, DUCK is used as KDCR, if DUCK is unavailable and DUSK is available, DUSK is used as KDCR, and if neither DUCK nor DUSK are available, KDCR is not set and messages are not confidentiality / privacy protected.

[0391] In one embodiment, the sender UE (e.g., source UE or UE-to-UE relay) is defined / configured with a Discovery User Integrity Key (DUIK). If this key is available, it is used to protect the integrity of the message. The DCR integrity key KINT is set to the DUIK, and a MIC is calculated over the DCR message using KINT and a UTC-based counter. Finally, the MIC IE is set to the calculated MIC. This is done as described in other embodiments.

[0392] In a related embodiment, the receiver performs the opposite operation to verify the integrity of the message.

[0393] In one variant embodiment, if the transmitter UE is not defined / configured with a DUIK, the DCR message is not integrity protected.

[0394] In one variant embodiment, the end UEs (i.e., source UE and target UE) are provided with two sets of security material such that a first discovery user integrity key DUIK1 associated with a ProSe restriction code is used to integrity protect the direct discovery set, and a second discovery user integrity key DUIK2 associated with a relay service code (RSC) is used to integrity protect the UE-UE discovery set or the entire DCR message. The UE-UE relay is provided with only the set of security material associated with the RSC and intended to integrity protect the UE-UE discovery set or the entire DCR message including the direct discovery set.

[0395] In one variant embodiment, the end UEs (i.e., the source UE and the target UE) are defined / configured with only the DUIK associated with the ProSe restriction code, in which case the end UE integrity protects the direct discovery set, while the UE-to-UE discovery set or the entire DCR message is not integrity protected.

[0396] In one embodiment, the end UEs (i.e., source UE and target UE) are defined / configured by the network with a strategy / indicator, such as security_materials_indication, when in coverage, that indicates whether one or two sets of security materials are used to protect (e.g., confidentiality, scrambling, and / or integrity protection) the DCR messages with joint discovery.

[0397] In one variant embodiment, the UEs (source, target, and UE-to-UE relay) are defined / configured with a policy, Relay_discovery_security_indication, that indicates, for example, what type of protection (e.g., encryption, scrambling, integrity) is applied and / or whether that protection is applied to the UE-to-UE discovery set, the entire discovery message, or the entire DCR message in the case of integrated discovery.

[0398] In some embodiments, DP_S-UE-to-UE or DP_UE-to-UE-T refers to a key or security keying material used to protect discovery messages hop-by-hop, e.g., a set of keying material related to a relay service code.

[0399] In some embodiments, DP_S-T refers to the set of keys or security keying material used to protect discovery messages end-to-end, for example, keying material related to ProSe restriction codes.

[0400] In one embodiment, the end UEs (source UE and target UE) are defined / configured with a policy / indicator, e.g., direct_discovery_security_indication, that indicates whether the direct discovery set is protected with its own set of security material (e.g., related to ProSe restriction codes) and / or what kind of protection (e.g., encryption, scrambling, integrity) is applied to which fields (e.g., integrity protection over the entire direct discovery set, e.g., source UE user info ID, target UE user info ID, and integrated_discover_indication, and privacy / confidentiality protection by encryption / scrambling applied only to privacy-sensitive fields, e.g., source user info ID and target user info ID).

[0401] In one embodiment, the UE is configured with first and second sets of keys and policies, the UE protects a first message based on the first set of keys and policies for delivering the first protected message, and the UE protects the first protected message based on the second set of keys and policies for delivering a second protected message transmitted by the device.

[0402] According to clause 6.4.3.7.4 of TS23.304, the user information ID of the target 5G ProSe end UE is an optional field in the DCR message with joint discovery. Therefore, if the user information ID of the target end UE is included and the DCR message (with joint discovery) is not protected, the privacy-sensitive information of the source and target UEs (e.g., the user information ID and the link between them, i.e., that the source UE is attempting to establish a link with the target UE) will be compromised. This also occurs when the inter-UE relay is not trusted. Therefore, in one embodiment, if the source UE includes the user information ID of the target UE, the DCR message (with joint discovery) needs to be protected, e.g., end-to-end protected, between the source UE and the target UE as described in the above embodiment. In other words, the protection of the DCR message not only depends on the coverage status of the inter-UE relay or the type of security procedures to be used in the security configuration of the PC5 communication link, but also on the content of the DCR message being constructed by the source UE.

[0403] In one variant embodiment, the source UE triggers protection of the DCR message (with joint discovery) if either or both of the following occur: - The source UE includes the target UE user information ID in the DCR message with joint discovery. - The source UE chooses the network-assisted secure link establishment procedure.

[0404] In an alternative embodiment in which both conditions of the previous embodiment are met, the security procedures defined in 6.3.5 of TS33.503 are reused to protect the DCR message with joint discovery, where privacy-sensitive information (e.g., RSC, PRUK-ID, and user information IDs of source, UE-to-UE relay, and target UE) are confidentiality protected and the DCR message is integrity protected. Since TS33.503 clause 6.3.5 can only protect up to 256 bits, a confidentiality key is used in combination with the NEA algorithm to protect payloads longer than 256 bits.

[0405] In one variant embodiment, when the source UE includes the user information ID of the target UE in the DCR message with joint discovery and an RSC associated with an unavailable network-assisted security indicator is used, the security procedures defined in 6.1.3.3.2.2 of TS33.503 are reused at least up to step 2 using two sets of keys to protect the DCR message with joint discovery, where the discoverer UE is the source UE, the discoveree UE is the target UE, the solicitation message is replaced with the DCR message with joint discovery, and a first set of keys associated with the ProSe service code is used to protect the end-to-end discovery elements, e.g., the user information ID of the source UE and the target UE, and a second set of keys associated with the relay service code is used to protect the DCR message with joint discovery.

[0406] In one variant embodiment, if the source UE includes the user information ID of the target UE in the DCR message with joint discovery and an RSC associated with an unavailable network-assisted security indicator is used, the security procedures defined in 6.3.5 of TS33.503 are reused to protect the DCR message with joint discovery, where privacy-sensitive information (e.g., RSC and user information IDs of the source, UE-to-UE relay, and target UE) are privacy / confidentiality protected and the DCR message is integrity protected based on a key pair (e.g., DUIK, DUCK, DUSK) associated with the RSC.

[0407] In a related variant embodiment, if the source UE selects the network-assisted security procedure, only the inter-UE relay within 3GPP® coverage performs security processing on the DCR message broadcast by the source UE. The inter-UE relay recognizes whether the security procedure is network-assisted or not based on the network-assisted security indicator associated with the RSC used in the DCR message. For example, if the inter-UE relay is out of coverage and receives a DCR message with an RSC associated with an available network-assisted security indicator, the inter-UE relay drops the DCR message; otherwise, the inter-UE relay processes the message and first establishes a secure hop-by-hop link with the source UE using network assistance.

[0408] In a related variant embodiment, after the inter-UE relay (re)broadcasts a DCR message (e.g., intended for a target UE), the target UE decides whether to security process the received DCR message based on whether it supports / prefers non-network / network-assisted security procedures. For example, if the target UE receives a DCR message with an RSC associated with an available network-assisted security procedure, the target UE provides the PRUK-ID (or SUCI) to the inter-UE relay so that the UE-UE relay establishes a secure hop-by-hop link with the target UE using network assistance.

[0409] In one variant embodiment, a target UE that does not have an appropriate certificate (e.g., a valid long-term certificate) and / or prefers network-assisted security procedures does not reply / react to a DCR message that includes an RSC associated with an unavailable network-assisted security indicator.

[0410] In one embodiment, if the source UE includes the user information ID of the target UE in the DCR message with joint discovery, it should not affect whether the UE-to-UE relay securely processes the DCR message.

[0411] In a related embodiment, the target UE decides to security process the DCR message based, for example, on whether the DCR message is intended for the target UE. For example, a target UE with limited resources may be pre-configured to only establish PC5 communication links (e.g., directly or through a UE-to-UE relay) with UEs requesting its service (e.g., source UEs), e.g., UEs that include an identifier (e.g., User Info ID or Destination Layer 2 ID) corresponding to the target UE in the DCR message.

[0412] In a related embodiment, a target UE receiving a DCR message, e.g., with limited resources, first attempts to determine whether its UserInfo ID and / or Destination Layer 2 ID are included in the integrated discovery message, e.g., based on the size of the message. For example, if the size of the integrated discovery message indicates that an identifier (e.g., UserInfo ID and / or Destination Layer 2 ID) is not included, the target UE drops the DCR message.

[0413] In a related embodiment, if the target UE successfully performs the size check to determine whether an identifier is included, the target UE proceeds to check the selected security procedures (e.g., based on the state of the included RSC and its associated network-assisted security indicator). Based on the outcome of the check against its preferences, the target UE decides whether to continue processing the DCR message or to drop the DCR message (e.g., if the security procedures are not supported, e.g., due to an invalid / expired certificate).

[0414] In one variant embodiment, the target UE first extracts and processes a direct discovery set containing the user information ID of the end UE (e.g., source and target UE), and then decides whether to process the DCR message or drop the DCR message based on whether the user information ID of the target UE included in the direct discovery set matches it.

[0415] These embodiments / checks are performed separately since they are combined, and when combined they may be performed in different orders and / or some of them may be skipped depending on the target UE configuration, e.g. preferences, requirements, certificate availability, coverage conditions, etc.

[0416] In a variant embodiment, if the source UE chooses the network-assisted link establishment procedure and also includes the user information ID of the target UE in the DCR message, this DCR message is protected as described in other embodiments, for example according to the procedure described in Figure 2.

[0417] In one variant, the source UE chooses the network-assisted link establishment procedure and transmits an integrated discovery message. However, this integrated discovery message, i.e., the DCR message with integrated discovery, is also directly received by the target UE. Therefore, to handle this situation, the target UE needs to be provided with a strategy to decide how to communicate with the source UE, for example, by requesting or replying to enable direct communication and waiting / preferring relayed communication in which PC5 security is established with network assistance. For example, the target UE is configured to wait for the DCR message to be relayed through a UE-to-UE relay that provides network assistance and select a path favorable to the source UE's selection (i.e., network-assisted link establishment through the UE-to-UE relay). Alternatively, if the target UE can decode / unscramble / integrity verify the integrated discovery message, the target UE is configured to instead attempt to establish a link directly with the source UE.

[0418] In one embodiment, if the end UEs (source UE and target UE) are provided with or configured to use only one set of security materials (e.g., Relay_discovery_security_indication is available and Direct_discovery_protection_indication is not available), the end UEs use the provided security keys associated with the RSC to protect DCR messages with joint discovery.

[0419] The processing procedures by the UEs (source, target, and inter-UE relay) may be similar to the above procedures using two sets of security materials with slight modifications, which are described as the following embodiments.

[0420] In one variant embodiment, the process at the source UE in protecting the DCR message with a set of security material includes the following steps. 1. Construct a message M containing direct discovery set elements such as source UE user info ID and target UE user info ID, integrated_discovery_indication, UE-to-UE discovery set elements such as relay indication, and other DCR fields such as ProSe service information and security information. 2. If the message M is specified / configured in the UE-to-UE code transmission security parameters, it is integrity protected by a MIC calculated over the DUIK associated with the RSC. The MIC is inserted into the message M. 3. The privacy-sensitive fields of message M, such as Source UE User Info ID and Target UE User Info ID, are confidentiality protected with DUCK / DUSK as configured in the UE-to-UE code transmission security parameters. This results in the protected message pm. 4. Privacy-sensitive fields in pm2 (e.g., RSC) that need to be easier to access for performance reasons are scrambled, thus resulting in a scrambled and protected message spm, where spm is a protected DCR message with joint discovery that can be conveyed by the source UE.

[0421] In a variant embodiment, the ProSe service information is also privacy protected in step 3.

[0422] In one alternative embodiment, step 2 applies to the DCR message either to the aggregate discovery set only, or to the entire DCR message (ie, the aggregate discovery set and other specific DCR fields, such as security information).

[0423] In another embodiment, the process at the target UE in processing the received aggregate DCR message protected with a set of security material is as follows. 1. Unscramble the message spm by using the UE-to-UE code received security parameter (eg DUSK) or a key associated with an existing security context with the UE-to-UE relay, thereby obtaining pm. 2. Remove confidentiality from message pm by using the UE-to-UE code received security parameters (eg, DUCK) or a key associated with an existing security context with the UE-to-UE relay, thereby obtaining m and MIC. 3. Verify the integrity of m by using the received m, the received MIC, and the UE-to-UE code received security parameter (e.g., DUIK) or an existing context with the UE-to-UE relay. If the MIC verification is successful, remove the MIC, thereby obtaining M.

[0424] In an alternative embodiment, the target UE receives spm directly from the source UE, in which case the same processing steps as above apply.

[0425] In another embodiment, the process at the UE-to-UE relay when processing a received protected aggregate DCR message protected with a set of security material is as follows. 1. Check whether the relay instruction is included. If not, the relay drops the DCR message. 2. Steps 2, 3, and 4 are similar to steps 1, 2, and 3 in the processing of the protected DCR message by the target UE, except that code transmission security material is used. Construct a new message M (eg, M') by adding the UE-UE relay user information ID to the UE-UE discovery set, discarding the relay_indication, and optionally updating the RSC. Steps 4, 5, and 6 are similar to steps 2, 3, and 4 of source UE protection of DCR messages with joint discovery, except that the inter-UE relay user information ID is further privacy protected (e.g., encrypted) while the RSC is scrambled, thus resulting in scrambled and protected messages M′, spm′.

[0426] spm' is the protected DCR message with joint discovery transmitted by the UE-to-UE relay to the target UE.

[0427] Alternatively, if a security context has already been established between the UE-to-UE relay and the target UE, and the UE-to-UE relay has identified the target UE (e.g., M including the target UE user information ID), then in step 3, the UE-to-UE constructs a new message M (e.g., M”) including an end-to-end / direct discovery discovery element, protects M” using the security key associated with the established security context, and sends it to the target UE.

[0428] According to the general definition of this embodiment, a method and an apparatus are proposed to be implemented in a target user equipment (UE), the apparatus comprising: - receiving one or more direct communication request (DCR) messages from a source UE and / or one or more UE-to-UE relays, e.g., with joint discovery; - determining how to process and / or prioritize received DCR messages and / or how to select a communication path, e.g., to a source user equipment, based on a configured policy, the policy including: Inter-UE relays where a security context has already been established; Establishing a secure link with and through an inter-UE relay using fresh security material; or ·Prefer to set up a direct link with the source UE.

[0429] In another general definition of this embodiment, a method and apparatus are proposed that are implemented in an inter-UE relay, the apparatus comprising: - receiving a Direct Communication Request (DCR) message from a source UE, e.g., with integrated discovery; - Process the received DCR message and determine whether the target UE can be identified through an identifier, for example, a target UE user information ID or a destination layer 2 ID of the target UE; - determining how a secure link with the target UE is established based on a configured policy, the policy comprising: reusing security material associated with an established security context when such a context exists between the UE-to-UE relay and the target UE to protect messages being relayed to the target UE; · Use discovery security material to protect the DCR message and prioritize using fresh security material to establish a secure link with the target UE.

[0430] The embodiments may be advantageously combined with one another.

[0431] (U2N) Verification of messages from remote UEs (end UEs) at relays In some scenarios, when a remote UE sends a DCR message to a UE-to-Network (U2N) relay (after discovery), the U2N relay verifies the integrity of the received parameters (e.g., RSC). The same can occur in a UE-to-UE relay scenario when an end UE sends a DCR message to a UE-to-UE relay. This integrity verification is performed as described in the above embodiment or as described in Section 6.3.5 of TS33.503. However, if the integrity verification fails, there is currently no way for the U2N relay to notify the remote UE about the failure, and therefore the remote UE continues to retry until the maximum number of retries is reached. This creates unnecessary delays when setting up a communication link between the remote UE and the CN through the U2N relay. A potential solution is for the U2N relay to send a failure (or reject) message when the integrity check fails. However, because the integrity check has failed, the U2N relay does not integrity protect such failure / reject messages. This means that such unprotected failure messages can be used by an attacker to launch a very simple form of DoS attack: when a remote UE attempts to connect to a U2N repeater, the attacker simply sends an unprotected failure message to the remote UE, causing the remote UE to drop the communication.

[0432] A similar situation applies to the direct link establishment procedure, e.g., from the UE to the network relay, when the U2N relay receives a direct link establishment request during the direct security mode procedure, upon verification of the direct security mode command message or the direct security mode complete message.

[0433] These specific situations can be generalized to a first device attempting to connect to a second device by sending a first message that includes an identifier (such as a service identifier or a session identifier) ​​or a message integrity check, such as a MIC. When the second device receives and processes the first message, it is instructed not to reply if the identifier or integrity check fails. In this situation, the first device is forced to wait and retry (e.g., until a timer expires). The first device must repeat this action (wait and retry) up to N times, where N is configurable. The specific potential solutions above can also be applied to a more general scenario in which the second device needs to send a failure (or rejection) message when an identity or integrity check fails. As discussed above, this failure message is not integrity protected and therefore could be exploited to launch a DoS attack.

[0434] Therefore, the objective is to address this security issue and still allow for more efficient options than the first device waiting and retrying. To achieve this objective, the following embodiments are proposed.

[0435] Generally, in the following embodiments: 1. U2N repeater and remote UE refer to the second device and the first device respectively. 2. DCR message means the first message sent by the first device. 3. Note that RSC refers to an identifier such as a session identifier or a service identifier.

[0436] In one embodiment, when the integrity verification of the DCR message sent by the remote UE fails, the U2N relay sends a failure message, and when the integrity verification of the DCR message is successful, the U2N relay sends an acceptance message (or a success message), which has the advantage that the remote UE can distinguish between the situation where the message is accepted and the situation where the message verification fails.

[0437] In one embodiment, the U2N repeater sends an accept message (or success message) when the integrity verification of the DCR message is successful, and does not send a failure message when the integrity verification of the DCR message sent by the remote UE fails, which has the advantage that the remote UE can determine the circumstances under which the message is accepted.

[0438] In a related embodiment, the acceptance message is integrity protected and the failure message is sent without integrity protection.

[0439] In one embodiment, the acceptance message is integrity protected in the same manner as the DCR message (eg, with the same algorithm and / or the same integrity key).

[0440] In one embodiment, the accept message is integrity protected by including the RSC and encrypting it with the key selected for encryption in the DCR message.

[0441] In one embodiment, the accept message is integrity protected by including a MIC, calculated using, for example, the NIA algorithm and an integrity key, for example, the DUIK, associated with the RSC and used in the DCR message.

[0442] In one embodiment, the accept message is integrity protected by including a MIC that is computed using a KDF that accepts as input the DUIK associated with the RSC and used in the DCR message.

[0443] In one embodiment, the integrity protection of the acceptance message is performed by adding a digital signature computed using a private key owned by the second device and whose public key is (pre)configured on the first device.

[0444] In one embodiment, the algorithms and / or keys to be used to protect the acceptance message are configured by an administrative entity, for example the CN of the telecommunications system.

[0445] In one embodiment, the algorithm to be used to protect the acceptance message is determined based on the security capabilities associated with the remote UE and sent in the DCR message.

[0446] In one embodiment, the MIC of the acceptance message is calculated by taking as input all or part of the received DCR message (eg, RSC, MIC, PRUK ID, etc.).

[0447] In one embodiment, the MIC of the acceptance message is calculated by taking as input a time-based counter (e.g., UTC-based) or nonce, for example received in the DCR message or determined at the time of sensing the acceptance message.

[0448] In one embodiment, the freshness of the acceptance message is verified based on an implicit (e.g., MIC) or explicit (e.g., random value) nonce included in the DCR message or a UTC-based counter. The implicit nonce is the MIC used in the DCR message.

[0449] In one embodiment, the MIC of the acceptance message is calculated by taking the MIC of the received DCR message as input for generating the MIC of the acceptance message. The MIC of the DCR message is a "fingerprint" of the DCR message itself, and if the MIC is calculated from a UTC-based counter, it is also tied to a time value (i.e., its value changes over time). This approach has the advantages of binding the DCR message and the acceptance message, reducing CPU overhead since a MIC is required as input, and providing both integrity and freshness protection.

[0450] In a related embodiment, the acceptance message is integrity protected and the failure message is also sent with integrity protection.

[0451] In one embodiment, the failure message is integrity protected, for example, similar to the embodiment described above for the acceptance message.

[0452] In one embodiment, the U2N relay sends a failure message when the integrity verification of the DCR message sent by the remote UE fails.

[0453] In one embodiment, the U2N repeater comprises: - when a second DCR message (a second "first message") is received (e.g., from an attacker posing as a remote UE), and - if the second DCR message cannot be integrity verified, in advance - the first DCR message (the first "first message") has already been received, and - have a policy / configuration such that if this first DCR message is successfully integrity verified, U2N does not send a reject message.

[0454] In one embodiment, the U2N repeater comprises: - when a second DCR message (a second "first message") is received, and - if this second DCR message is successfully integrity verified, - a first DCR message (first "first message") is received / has been received (e.g., from an attacker posing as a remote UE), and - have a policy / configuration such that U2N does not send a rejection message if it cannot verify the integrity of this first DCR message;

[0455] In a related embodiment, the U2N repeater has a policy / configuration for determining whether to send a rejection message in response to receiving one or more "first messages" in which at least one of the "first messages" is successfully verified.

[0456] In one embodiment related to the previous embodiment, the U2N repeater has a policy / configuration to send notifications to a remote UE or NF in the CN to notify them about the event.

[0457] In a related embodiment, the U2N repeater has a strategy for prioritizing the successfully verified "first message", regardless of whether the successfully verified "first message" was the first "first message" (DCR message) or the second "first message".

[0458] In a related embodiment, the U2N repeater has a policy / configuration that specifies that no reject message is sent if the time between receiving the first DCR message (first first message) and receiving the second DCR message (second first message) is less than a predetermined time, for example T1 seconds.

[0459] This embodiment and the previous embodiment have the advantage that an attacker can prevent a U2N repeater from forcing a protected rejection message by sending / reflecting a manipulated DCR message (e.g., the same first DCR message with some errors) immediately after the remote UE sends the DCR message.

[0460] In one embodiment, the U2N repeater has a configuration / policy that determines that the U2N repeater should not send the rejection message if it cannot integrity protect the rejection message, for example, if the U2N repeater does not find a suitable integrity key to protect the rejection message.

[0461] This has the advantage of reducing communication overhead, particularly if the remote UE has a policy that unprotected reject messages should be rejected.

[0462] In one embodiment, the U2N repeater includes an identifier in the rejection or acceptance message that allows the remote UE to determine the key to be used for integrity verification. This identifier is the RSC in the first message or a fingerprint of the first message. This field is also used as input in the generation of the MIC.

[0463] This has the advantage of finding the correct integrity key efficiently.

[0464] In one embodiment, the U2N repeater does not include an identifier in the rejection or acceptance message.

[0465] This has the advantage of providing more privacy when indicating service to be denied at the cost of the remote UE having to perform a blind search (trying multiple integrity keys).

[0466] In a related embodiment, the remote UE has a policy such that a reject message is not accepted if a DCR message (first message) has not been sent previously within the last time (e.g., T2 seconds) and / or a related communication procedure that expects a reject message has not been performed.

[0467] This has the advantage that it prevents an attacker from forcing the receipt of a false denial message.

[0468] In a related embodiment, a remote UE expecting a protected rejection message has a policy to determine that the rejection message should be dropped / ignored if the remote UE does not have a suitable key to integrity verify the rejection message. If the protected rejection message does not include an identifier, such a policy allows / prevents the UE from performing a blind search, depending on, for example, the type of UE and / or time / computational constraints.

[0469] In related embodiments, mechanisms are described for integrity protecting denial messages (eg, direct communication denial messages and direct security mode denial messages) when a key such as a DUIK is provided for discovery.

[0470] In this embodiment, if the first message cannot be integrity verified (eg, the Direct Security Mode Command procedure fails), protection of the reject message (eg, the Direct Security Mode Reject message) is performed as follows.

[0471] The protection and / or transmission of the denial message is subject to policy / configuration, e.g., The previous first message (e.g., a Direct Security Mode command procedure) successfully included integrity verification. The previous 1st message was received / successfully verified in the last T1 seconds Subject to one or more conditions such that the U2N repeater does not protect and / or send rejection messages when established communication exists, etc.

[0472] If the U2N integrity protects the denial message, the U2N repeater does so by using the code transmission security parameters used for discovery.

[0473] 1. If the UE is configured with a DUIK, the integrity key KINT is set to the DUIK. Otherwise, the direct communication reject message is not integrity protected and steps 2 and 3 are skipped.

[0474] 2. Calculate the message integrity check (MIC) using the KDF and a KINT, UTC-based counter as in the above embodiment.

[0475] As in the above embodiment, the procedure can benefit if the rejection message includes an RSC or identifier linked to the DUIK (or integrity key to use) so that the recipient can determine the DUIK to use.

[0476] As in the above embodiment, the procedure can benefit if the remote UE can link the messages when multiple first messages are sent and if the rejection message includes (a fingerprint of) the first message that failed verification, e.g. to be able to better determine the cause of the failure.

[0477] 4.3. Set the MIC IE to the calculated MIC.

[0478] The U2N repeater has a configuration / policy that determines that if the reject message cannot be integrity protected, the U2N repeater should not send the reject message, and acts accordingly.

[0479] When the 5G ProSe remote UE receives the rejection message, it verifies the integrity of the received rejection message using the code reception security parameter used for discovery.

[0480] If the integrity verification of the reject message fails, the remote UE has a strategy to determine whether to ignore the reject message or not.

[0481] If the message is not integrity protected, or is deemed not to be integrity protected because the remote UE lacks an integrity key, the remote UE has a strategy for determining whether or not to process the message and acts accordingly.

[0482] The remote UE verifies the integrity of the received reject message as follows. 5.1 If the UE is configured with a DUIK, the integrity key KINT is set to the DUIK, otherwise the reject message is not integrity protected and step 2 is skipped. As in the above embodiment, the procedure can benefit if the rejection message includes an RSC or identifier linked to the DUIK (or integrity key to use) so that the recipient can determine the DUIK to use. As in the above embodiment, the procedure can benefit if the remote UE can link the messages when multiple first messages are sent and if the rejection message includes (a fingerprint of) the first message that failed verification, e.g. to be able to better determine the cause of the failure. 2. The KDF calculates a MIC using the KINT, a UTC-based counter, and the received denial message, and compares the calculated MIC with the MIC included in the denial message. If they do not match, the integrity check fails. 3. Compare whether the RSC and / or MIC of the previously sent direct communication request message matches the rejection cause of the received direct communication rejection message. If they do not match, the direct communication rejection message is rejected / ignored.

[0483] In one alternative embodiment, the fingerprint included in the message is a MIC calculated by the relay UE that does not match the MIC included in the direct communication message.

[0484] In one variant, the fingerprint is not explicitly transmitted but is implicit. For example, the MIC of the reject message is calculated taking as input the received direct communication message itself. Thus, when the remote UE receives the reject message, it calculates the MIC itself using the contents of the previously sent direct communication message and the received reject message. If the MIC calculated locally by the remote UE and the MIC of the received reject message do not match, the remote UE recognizes that the reject message was not intended for it.

[0485] In one variant, the rejection message includes multiple MICs, each of the multiple MICs calculated with a different DUIK and each of the multiple MICs associated with a different RSC, which requires the relay UE (from the UE to the network) to calculate and transmit multiple MICs.

[0486] In one variant, the denial message includes a single MIC, selected according to a strategy, for example the DUIK used to calculate the MIC, for example the DUIK linked with the RSC in the last exchange / reconciliation procedure.

[0487] In one alternative embodiment, the remote UE performs attempts with multiple DUIKs associated with multiple RSCs. For example, if the remote UE attempts discovery with multiple RSCs associated with multiple keying materials, the remote UE attempts to verify the rejection message with all DUIKs used in the last X discovery messages or T seconds, where X and T are configurable.

[0488] In one variant, direct disclosure of the RSC in which the DUIK is used to protect the rejection message would raise privacy concerns, so a pseudo-identifier, e.g., some bits of a previously used discovery message (e.g., a MIC), is used.

[0489] In one variant embodiment, when a remote UE receives a protected rejection message containing a fingerprint, if verification of the MIC of the rejection message fails but the fingerprint of the rejection message matches (i.e., the rejection message contains a fingerprint that matches the fingerprint of the DCR message sent by the remote UE), the remote UE attempts to verify the rejection message with another key (DUIK) associated with the RSC configured in the remote UE. This is done to attempt to determine a common key between the remote UE and the relay UE. This has the advantage of allowing the remote UE to determine the common key. If a key that allows verification of the MIC is found, the remote UE may retry sending a DCR message protected with the key associated with that RSC if this RSC is acceptable to the remote UE for the intended communication service to which the remote UE wishes to access, or the remote UE may decide to repeat the discovery process.

[0490] In a variant embodiment, the fingerprint in the rejection message is checked before the MIC verification is performed, which makes it possible to verify whether the rejection message is intended for a remote UE before performing any cryptographic operations, i.e. more efficient.

[0491] In one embodiment, the failure message is integrity protected with a key configured to protect only the failure message.

[0492] In one embodiment, a key intended only to protect failure messages is configured such that the key is common to multiple sets of devices, discovery keying material, DCR messages, or RSCs.

[0493] The last embodiment has the advantage that even if the particular integrity key used to verify the DCR message cannot be successfully used, the failure message is still protected and verified.

[0494] In one embodiment, the failure message contains the cause of the failure, e.g. RSC mismatch and / or MIC failure, and / or other parameters that allow identification of the failure cause (e.g. time (if the U2N repeater identifies that an old / expired key was used by the remote UE) or key time validity). This has the advantage that the remote UE may choose different parameters for sending the DCR message to avoid the failure cause and / or trigger any other procedures (e.g. request to refresh / update configured parameters such as keys).

[0495] In one embodiment, the remote UE includes a policy that determines its behavior when (1) no message is received when sending a DCR message, (2) a failure message is received when sending a DCR message, (3) an acceptance message is received when sending a DCR message, and / or (4) both a failure and an acceptance message are received when sending a DCR message.

[0496] In a related embodiment, the policy at the remote UE is configured by a management entity, eg a CN of a telecommunication system, eg by an NF at the CN, such as a PKMF or DDNMF.

[0497] In a related embodiment, the strategy determines that the remote UE should retry sending the DCR message multiple times if no messages (failure message and acceptance message) are received before the timer expires.

[0498] In a related embodiment, the strategy determines that if only a failure message is received, the remote UE should stop retrying sending the DCR message, which also indicates that the remote UE should look for a different U2N repeater.

[0499] In a related embodiment, the strategy determines that if an acceptance message is received and correctly verified, e.g., within a (configured) time window, the remote UE should stop retrying sending the DCR message, after which the UE waits a given time (specified in the strategy) to receive further messages, e.g., from the U2N repeater and / or communication with the CN through the U2N repeater (e.g., authentication process).

[0500] In a related embodiment, the strategy determines that if both the failure message and the acceptance message are received and the acceptance message is correctly verified, the remote UE should stop retrying sending the DCR message. The UE should then wait (e.g., for a configured time) to receive further messages from communication with the CN (e.g., authentication process), for example, through a U2N repeater. This has the advantage of allowing the remote UE to handle both potential attacks (e.g., if an attacker exploits an unprotected failure message) and improved performance (by explicitly signaling that the message is properly verified by the acceptance message) by giving higher priority / importance to the acceptance message than to the failure message.

[0501] In a related embodiment, the policy determines a timer such that the remote UE should not retry sending the DCR message if only unprotected failure messages are received (e.g., an attacker exploits the failure messages). If an acceptance message is received before the timer expires and the acceptance message is correctly verified, the acceptance message is given priority.

[0502] In a related embodiment, the policy determines a timer where no retries should be made to try to set up communication with a U2N repeater if only unprotected failure messages are received (e.g., an attacker exploits the failure messages). If an acceptance message is received before the timer expires and the acceptance message is correctly verified, the acceptance message takes precedence, e.g., allowing communication to continue ignoring the failure messages.

[0503] In a related embodiment, the acceptance message is an explicit message, in other words, a message sent with the primary purpose of informing the remote UE that the integrity verification at the U2N relay has been successful.

[0504] In a related variant embodiment, the acceptance message is implicitly transmitted by another protected message Y. In other words, when the UE receives the protected message of the next step, the acceptance message is implicitly included (or is considered to be received). In other words, the acceptance message is represented by a protected message Y transmitted by a U2N relay to a remote UE, and the protected message Y is transmitted for a given purpose, such as communicating specific parameters or performing authentication. Such a message is transmitted directly from a UE-to-network relay to the remote UE, or through a U2N relay, for example, when the UE-to-network relay forwards a message originating from a third device (e.g., a core network) to the remote UE. In other words, the purpose of message Y is not only to notify the remote UE that the integrity verification at the U2N relay was successful. When the remote UE receives message Y, the remote UE implicitly understands that the UE-to-network relay was able to verify the DCR message. In the context of another embodiment, if a remote UE receives said protected message Y and an unprotected failure message, the remote UE will prioritize processing of the protected message Y and ignore the unprotected failure message according to a (pre)configured or hard-coded strategy.

[0505] In a related embodiment, the strategy determines that if both the failure message and the acceptance message are received and the acceptance message is correctly verified, the remote UE should send an attack notification message to a management entity (e.g., a CN of a telecommunications system).

[0506] In one embodiment, the remote UE implements a routine to verify the integrity and / or freshness of the acceptance and / or failure messages that is a counterpart of the above embodiment.

[0507] In one embodiment, the U2N repeater implements routines for verifying the integrity and / or freshness of the acceptance and / or failure messages that are counterparts of the above embodiments.

[0508] In a related embodiment, the remote UE performs integrity verification by checking the MIC calculated by the relay UE, as described above.

[0509] In some situations, an attacker may spoof an unprotected failure message, e.g., with the goal of preventing a remote UE from connecting to a U2N repeater. In telecommunication systems relying on RAN-coordinated medium access control, the RAN oversees the implementation of resource allocation, e.g., by control messages. In the specific case of remote UEs and U2N repeaters, devices connecting to the remote UEs over a sidelink also perform local resource allocation, e.g., using a common resource pool. Thus, the above problem is also addressed by improving / monitoring how resource allocation is performed.

[0510] In one embodiment, the resource allocation for the transmission of the DCR message and the subsequent return of the failure or acceptance message is done simultaneously, which is advantageous as it leaves less room for an attacker to interject arbitrary messages.

[0511] In a related embodiment, the device (remote UE, U2N repeater, RAN, and / or CN) monitors that resources are not irregularly allocated, for example by monitoring that no messages are sent for transmission of messages to the remote UE.

[0512] In a related embodiment, the device triggers an alarm if resources are irregularly allocated, where the alarm is sent to, for example, the CN or a remote UE. The above embodiment is implemented by a computer program running on the remote UE or U2N repeater.

[0513] Identifying the key that should be used to decrypt / integrity verify the DCR message The inability of the UE Relay to integrity verify messages such as DCR messages arises from the UE Relay not knowing which key to use. Therefore, to mitigate the problem of having a U2N (or UE-to-UE) Relay receiving a message (e.g. a protected DCR message as in the other embodiments) from a remote UE (i.e. end UE) where the Relay is unable to match the RSC (which would typically integrity verify the message) with the RSC sent in the discovery message after decoding it, the following embodiment is proposed to be used independently and / or in combination with other embodiments (e.g. sending a failure / reject message), in particular the Relay UE will take one or more of the following actions: - matching the decoded RSC against the RSC or list of RSCs sent in one of the previous discovery messages (i.e. the decoded RSC matches the RSC sent in the discovery message), for example the X previous discovery messages, where X is configurable, or the discovery message sent T previous seconds, where T is also configurable; - matching the decoded RSC against an RSC or list of RSCs sent / received in one of the previous discovery messages in the previous t seconds, where t is configurable; and / or - Matching the decoded RSC with one of the RSCs supported by the repeater.

[0514] Note that matching the decoded RSC with an RSC sent in one of the previous discovery messages and / or supported by the repeater requires decrypting the message multiple times, e.g., with the discovery key associated with each of those RSCs. This embodiment makes the use of failure / rejection messages less necessary and / or frequent, which is advantageous.

[0515] It should be noted that in the following embodiments, when a type of relay is mentioned, for example a UE-to-network relay, the embodiments are also applicable to other types of relays.

[0516] In one variant, an end device (e.g., a remote UE) signals an identifier (e.g., its Layer 2 ID) in a Direct Communication Request (DCR), where the identifier is tied to the device (e.g., Layer 2 ID) and / or the RSC (e.g., the least significant bits of the MIC in the discovery message) to a relay, e.g., a UE-to-network relay, used by the device during discovery. The remote UE further includes the identifier (e.g., Layer 2 ID) in the DCR message to allow the relay, e.g., a U2N, to identify the RSC and subsequent security keying material to use for decryption, RSC alignment, and integrity verification. In this variant and the related variants below, a relay, e.g., a UE-to-network relay, needs to keep track of the RSCs and identifiers used by the remote / end UE in the discovery procedure, so that the relay UE can check which RSC is intended for use when a DCR message containing the identifier is received.

[0517] In one variant embodiment, the remote UE attempts PC5 security establishment for 5G ProSe UE-to-network relay communications across both the user plane and control plane, and the UE-to-network relay supports both security procedures. The UE-to-network relay matches both RSCs indicating the security procedures, and the remote UE then sends a DCR message to initiate one of them. When the remote UE sends a DCR message containing one of the RSCs protected with its Layer 2 ID and corresponding keying material, the UE-to-network relay may select an incorrect RSC and subsequently select incorrect security keying material, resulting in an RSC mismatch / integrity verification failure. To address this issue, the UE-to-network relay performs blind decryption / verification on the received DCR message using the security keying material associated with the RSC associated with the device identifier, in this case the Layer 2 ID of the remote UE, that has been stored by the UE-to-network relay.

[0518] In another embodiment, combined with the previous embodiment or used independently, the Layer 2 ID of the remote UE is not changed / updated during the PC5 link establishment procedure or between the discovery procedure and the direct link establishment procedure, so the previous embodiment can work without any problems.

[0519] In one variant embodiment, the remote UE's User Info ID plays a similar role to the Layer 2 ID in the previous embodiment, i.e. the UE-to-network relay performs blind decryption / verification of the received DCR message using security keying material associated with the RSC associated with the remote UE's User Info ID.

[0520] In a related embodiment that addresses the above problem, how U2N repeaters perform matching is specified according to a configurable strategy (similar to other embodiments) depending on, for example, the number of RSCs supported.

[0521] In related embodiments that address the above issues, the strategy (like other embodiments) further specifies whether the U2N repeater sends failure and / or acceptance messages that are protected or unprotected, implicit or explicit, depending on how the RSC matching is performed.

[0522] In other related embodiments that address the above problem of having a UE (e.g., a UE-to-network relay) that receives a message (e.g., a protected DCR message as in other embodiments) from another UE, such as a remote UE, and after decoding the RSC of the message, the U2N relay is unable to match the RSC (which typically integrity verifies the message) with the RSC sent in the discovery message, the 5G ProSe remote UE and the 5G ProSe UE-to-network use part of the discovery message (e.g., the least significant bits (e.g., the k least significant bits, where k is (pre)configured by the network or indicated in the message) of the MIC exchanged in a previous or matched discovery message, the k bits of the scrambled message, or the encrypted RSC exchanged in the discovery message) to identify discovery keying material for use in protecting direct communication messages. For example, if a remote UE and a UE-to-network relay (similar procedures are applicable to other relay procedures) are engaged in two discovery procedures, e.g., associated with two different relay service codes RSC1 and RSC2, and for each of the discovery procedures the remote UE and relay UE exchange discovery messages according to Model B, then both UEs store the k=12 least significant bits of a field (e.g., MIC or encrypted RSC) in the second discovery message of Model B for both discovery procedures, e.g., associated with RSC1 and RSC2. In the first discovery procedure, the MIC is 0xABCD, and in the second discovery procedure, the MIC is 0x12EF, then both UEs store the k=12 least significant bits of the ... second discovery procedure, the MIC is 0x12EF, then both UEs store the k=12 least significant bits of the field (e.g., MIC or encrypted RSC) in the second discovery message of Model B for both discovery procedures, e.g., associated with RSC1 and RSC2. In the first discovery procedure, the MIC is 0xABCD, and in the second discovery procedure table RSC1, 0xBCD RSC2, 0x2EF , which is the key associated with RSC1. If the remote UE then decides to send a Direct Discovery Request (DCR) message associated with RSC1, it protects the DCR message with the discovery key associated with RSC1. To indicate this in a privacy-sensitive manner, the message includes an identifier IDX 0xBCD in the message in plain text. The relay UE then receives the message, extracts the identifier IDX, and uses it to look up in a table to determine which RSC is involved (RSC1 in this example), and obtains the corresponding key, e.g., DUCK, DUIK, or DUSK associated with RSC1, which enables correct processing of the message. This approach is also applicable when two different remote UEs are performing two discovery procedures in parallel with the same relay UE. This approach is also applicable when a source end UE is performing two discovery procedures in parallel with the same UE-to-UE relay using an RSC that supports two security procedures (one with network assistance and one without). This approach allows the keys used in the discovery phase to be linked in a privacy-sensitive manner with the keys used to protect subsequent messages (e.g., DCR messages, denial messages) before a PC5 security context is established.

[0523] Note that when this is done, there is no need to include the RSC in the DCR message since the newly included identifier already identifies it, even though in some cases (e.g. when the DCR message is not integrity protected) it may make sense to check that the decoded RSC matches the RSC linked to the IDX.

[0524] In other related embodiments, the indication on the security key to be used is exchanged in another message and is calculated differently, for example, the indication or key identifier is included in the failure message, for example, the indication is calculated as the least significant bits of the output of a key derivation function that takes as input the key to be used (e.g., the DUIK to be used) and a time counter.

[0525] In a PC5 link establishment scenario from a remote UE to a UE-to-network repeater, CT1 LS C1-234362 describes a problem where the UE-to-network repeater needs to obtain security keying material to decrypt and verify the PRUK-ID and RSC. However, the security keying material is associated with the RSC, and the RSC is sent encrypted in the DCR message. As a result, the UE-to-network repeater cannot identify which RSC is used and which security keying material to use to process (e.g., decrypt, verify integrity) the subsequently received DCR message. This problem is similar to the problem discussed in the previous embodiment. To address this problem, a potential approach is as follows: During the discovery request procedure, the 5G DDNMF in the HPLMN of the announcing UE (of model A) / discoveree UE (of model B) returns a key identifier associated with the discovery security material to the announcing UE / discoveree UE in step 4 of Figures 6.1.3.2.2.1-1 and 6.1.3.2.2.2-1. The key identifier is also communicated to the HPLMN of the monitoring UE / discoverer UE (step 9), and through a relayed discovery key response, corresponding to steps 10 and 11 in the preceding figure, the monitoring UE / discoverer UE obtains discovery security materials and their identifiers. It is then proposed to include the key identifier in the DCR message in clear text to identify the security key material used to protect the DCR message. The key identifier is also included in discovery messages exchanged during the discovery phase. The use of key identifiers has already been discussed in the previous embodiment. However, this approach compromises the privacy of the UE, especially when discovery security materials are reused. Because the key identifiers are fixed and communicated in clear text, an eavesdropper may be able to determine when a particular set of security materials is used and by which UE they are bound to an RSC. Furthermore, if the key identifiers are also exchanged during the discovery phase, they act as equivalents to the RSCs, and therefore affect the privacy of the end UE / user if they are exchanged unprotected.To address these concerns, the following embodiments are considered, which are applicable to both UE-to-network and UE-to-UE relays.

[0526] In one alternative embodiment, the key identifiers associated with the discovery security material are rotated based on conditions configurable by the network (e.g., time, one use), for example, the key identifiers are updated / rotated hourly, thereby ensuring that the key identifiers are dynamic.

[0527] In a variant embodiment, the remote UE includes the entire key identifier or only a part of it (e.g., b LSB / MSB) in the DCR message, and in the latter case, the UE-to-network relay, when responding to the remote UE, conveys, e.g., b MSB / LSB, corresponding to the same key identifier, and these MSB / LSB identifiers are included, e.g., in the DCR message and the rejection message.

[0528] In another variant embodiment similar to the other embodiments described above and combined with the previous embodiment, a key identifier is calculated based on the discovered security material and a UTC-based counter provided as input to the KDF, and the last b bits of the KDF output are taken as the key identifier that remains valid for, e.g., one hour or for the duration of use.

[0529] In another embodiment, the network (e.g., PKMF, DDNMF, etc.) calculates and assigns a list of pseudo-IDs to UEs (e.g., remote UEs and relay UEs from the UE to the network) based on the discovery security material and time period provided, such that each pseudo-ID is valid for a specific time period. This list of pseudo-IDs may be calculated as described in the previous embodiment or randomly.

[0530] In a related embodiment, which may be combined with other embodiments or used independently, UEs (e.g., remote UEs and UE-to-network relays) that are provided with a list of pseudo-IDs select key pseudo-IDs to use (e.g., include in DCR messages) based on their current timestamps, where the timestamps fall within the time ranges that the pseudo-IDs correspond to.

[0531] In another variant embodiment, the list of pseudo IDs is calculated and stored by the UE (e.g., remote UE and UE-to-network repeater) when provided with discovery security material, and the b LSBs of the UTC-based counter are set to zero so that small time differences do not result in different pseudo IDs at the UE (remote UE and UE-to-network repeater) end.

[0532] In another variant embodiment, the UEs (remote UEs and UE-to-network or UE-to-UE relays) try adjacent / close / following pseudo IDs to avoid message rejection due to time synchronization issues.

[0533] In other embodiments where the pseudo-ID associated with the discovery security material is updated / changed during the direct communication phase, the UE-to-network relay does not match the pseudo-ID communicated in the DCR message with the updated pseudo-ID, in which case the UE-to-network relay attempts to match the received pseudo-ID against a (previously valid) pseudo-ID corresponding to a previous period.

[0534] In another variant embodiment similar to the other variants described above, it is important to keep a list of matched / approved RSCs and / or key identifiers during the initial discovery phase so that only DCR messages containing a key identifier in the list or a key identifier bound to one of the matched / approved RSCs in the list are further accepted. To achieve this, as shown in the previous embodiment, the relaying UE (e.g., a relay from the UE to the network) keeps track (by a list) of matched RSCs in the last k discovery messages or in the last T seconds, where k and T are configurable. When the relaying UE receives a DCR message with a key identifier, it checks whether the key identifier corresponds to any RSC stored in the list. The UE-Relay only accepts DCR messages containing a key identifier / RSC in the list. This is advantageous because it allows for a potential authorization check to be performed only during the discovery procedure.

[0535] In one embodiment, the key identifier used in the DCR message (e.g., a fixed key identifier configured by the network, the key identifier being bound to the RSC and discovery keying material) is scrambled with a pseudo-random sequence, e.g., pre-configured or generated from a key, e.g., DUSK of the discovery keying material. The UE-Relay descrambles the message, where the descrambling operation is performed blindly, i.e., by trying a scrambling key possessed by the UE to generate the pseudo-random sequence. If the key identifier matches the key identifier bound to the RSC / discovery keying material / DUSK used for descrambling, the UE knows that the key identifier is the correct key identifier and can further process the security of the CR message, i.e., decrypt and integrity verify the DCR message. This variant requires blind descrambling. Blind descrambling can be improved by only attempting descrambling with keys used in previously matched discovery messages, e.g., other messages. The scrambling is performed by using a pseudo-random sequence that changes infrequently, e.g., once an hour. The scrambled key identifier can be computed as XOR(key identifier, TRUNC(KDF(K, UTC-based counter), b)), where XOR(a, b) returns the bitwise xor of a and b, TRUNC(a, b) returns b bits of a, and KDF(K, a) returns the key derivation function of a. Recovery of the key identifier is done by the inverse operation, i.e., XORing the scrambled key identifier with TRUNC(KDF(K, UTC-based counter), b).

[0536] Thereby, according to this embodiment, a method is proposed which includes a UE relay receiving a key identifier of a DCR message, said key being scrambled by a pseudo-random sequence, the UE relay unscrambling the key identifier, and the UE relay further processing the DCR message security in determining that the unscrambled key identifier matches the key identifier of the key used for descrambling.

[0537] In a general definition of the invention, a method is proposed in which the discovery security material identifier is tied to a list of approved relay service codes stored by the second device, the approved relay service codes stored in the list matching the relay service codes used in the previous discovery phase and / or exchanged / used during a time window, the number of discovery phases or time windows being configurable.

[0538] In a general definition, a method is proposed in which a first device signals to a second device which discovery security material to use for processing a DCR message or a rejection / failure message by means of an identifier, which is updated periodically / dynamically, based on pre-set conditions and / or using a pseudo-random sequence, said identifier, inputs for calculating the identifier and / or pseudo-random sequence being either determined by themselves (e.g. in a previous communication phase) or assigned to the first and second devices by a network entity and stored by the devices themselves.

[0539] The above embodiments represent a method for enabling secure and reliable communications in a telecommunications network.

[0540] The above embodiments represent apparatus that may be implemented in a first device (eg, a remote UE) to enable secure and efficient operation when connecting to a second device (eg, a relay UE).

[0541] The above embodiments represent apparatus that may be implemented in a second device (e.g., a relay UE) to enable secure and efficient operation in providing connectivity to a first device (e.g., a remote UE).

[0542] In general, the different embodiments presented herein may be combined with each other.

[0543] As detailed through the previous embodiments, the proposed variants of the present invention can be implemented in a network, for example a cellular network such as a 5G network as shown in FIG. 5. A cell of the network is provided by a primary station 1000. Under the coverage of the primary station 1000 (e.g., a gNB), multiple secondary stations can connect to the primary station. Some secondary stations are adapted to operate as relay stations 1010. Such a relay station comprises a transmitter 1011 coupled to a transmit antenna and a receiver 1012 coupled to a receive antenna. Typically, the receive antenna and the transmit antenna are the same antenna. Furthermore, depending on the technology, the antenna is formed by an antenna array. The antenna array enables different transmit / receive modes such as MIMO, transmit diversity, and operation at different sets of frequencies.

[0544] The controller 1013, e.g., a CPU or microcontroller (such as a dedicated communications microprocessor (baseband processor) or the main microprocessor of the device including the UE) running on software stored in an internal memory (e.g., ROM, EEPROM, SSD), is adapted to control the transmitter and receiver and to control the antenna. It should be noted that some or all of the transmitter, receiver, and controller may be part of a single baseband processor. With respect to the above-described embodiment, the controller is adapted to establish a connection between the relay station 1010 and the primary station 1000. More specifically, the controller 1013 can configure the receiver 1012 to receive a first set of configuration parameters including an attribute or service code in at least one first secure message from the primary station 1000.

[0545] The controller 1013 can control the transmitter 1011 to transmit at least one transmitted attribute or service code from a first set of configuration parameters, which attribute or service code may be broadcast for reception by other stations, such as secondary stations 1020 or 1030.

[0546] Typically, a relay station is a UE, such as a sidelink compatible UE, that can act as a relay station if configured as such. Alternatively, a relay station may also be another primary station, such as an access point, gNB, or femtocell gNB.

[0547] The secondary station 1020 (or similarly 1030) is typically a UE and comprises a transmitter 1021 and a receiver 1022, both of which are typically coupled to one or more antennas or antenna arrays. Additionally, the secondary station 1020 includes a controller 1023 adapted to control the transmitter 1021, the receiver 1022, and possibly other elements of the UE. For a relay station, the controller 1023 is a processor or CPU and is software-driven.

[0548] The controller 1023 can cause the receiver 1021 and transmitter 1022 to establish a connection with the primary station 1000. This includes configuring the receiver 1021 to receive a second set of configuration parameters from the primary station 1000 in at least one second secure message, including, for example, attributes or relay service codes involved in future data exchanges with the relay station 1010.

[0549] The receiver 1021 is adapted to receive at least one attribute or service code transmitted from the relay station 1010. The control device is configured to determine whether the transmitted attribute or service code is included in a second set of configuration parameters or satisfies a policy thereof, and to cause the transmitter to establish direct communication with the relay station 1010 upon determining that the transmitted service code is included in the second set.

[0550] Secondary stations 1020 and 1030 may also communicate with each other via relay station 1010 .

[0551] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0552] The described operations as shown in the different figures, e.g., Figures 3 and 4, can be implemented as program code by a computer program and / or as dedicated hardware in the respective associated communication or access device. The computer program can be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but also in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0553] The above embodiments are also applicable to multi-hop PC5 communication link establishment, where relays (e.g., UE-to-UE relays) forward / relay discovery and / or communication messages between end UEs and / or between end UEs (remote UEs) and the network, taking into account modifications that need to be implemented to adapt the inventive procedure to multi-hop links. For example, checks to verify the validity of an end-to-end protected direct discovery set relayed through multiple relays are performed at each UE-to-UE relay through which a discovery message is relayed, and if the discovery message is deemed invalid by the kth UE-to-UE relay, it is dropped by the UE-to-UE relay. For example, in a UE-to-network relaying scenario involving relays between a remote UE and a UE-to-network relay, if the RSC does not match or message integrity verification fails at the relay between the remote UE and the UE-to-network relay, a rejection message is sent back to the remote UE through the relay used to establish the link. For example, to ensure that the path (i.e., the list of UE-to-UE relays used to establish the link) is maintained, each relay stores the identifiers of the relays from which the message was received and the relays to which the message was relayed. For example, a relay_indication_counter is added to the discovery / communication message, the counter is updated (e.g., incremented) each time the message is relayed, and if a max_limit configured by the network and / or source UE (e.g., advertiser / discoverer / remote UE) is reached before the discovery / communication message reaches the destination UE (e.g., target end UE / UE to network relay), the message is dropped. For example, in a UE to network via relay scenario, the protection of the DCR message is adapted to take into account multiple RSCs that may be used between several relay UEs, while the remote UE identifier (i.e., PRUK-ID / SUCI), which remains intact, is protected, for example, end-to-end between the remote UE and the U2N relay, or protected using hop-by-hop security keys associated with the different RSCs used between relay UEs.

[0554] Other variations to the disclosed embodiments may be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the singular form of an element does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing specification details particular embodiments of the invention. However, no matter how detailed the above appears in text, it should be understood that the invention may be embodied in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of a particular term in describing a feature or aspect of the invention should not be taken as suggesting that the term be redefined herein to be limited to include any specific characteristics of the feature or aspect of the invention with which the term is associated.

[0555] Furthermore, in instances where a convention similar to "at least one of A, B, and C, etc." is used, such construction is generally intended to mean that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In instances where a convention similar to "at least one of A, B, or C, etc." is used, such construction is generally intended to mean that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those skilled in the art that virtually any disjunction word and / or phrase presenting two or more alternative expressions, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of those expressions, either one of those expressions, or both of those expressions. For example, the phrase "A or B" is understood to include the possibilities of "A," "B," or "A and B."

Claims

1. 1. An apparatus for securely relaying a discovery message from a first device to a third device, the apparatus comprising: receiving a second discovery protection message from the first device protected with a second set of keys, the second discovery protection message including the first discovery message protected end-to-end with a first set of keys according to a policy or configuration; using the second set of keys to unprotect the received second discovery protected message, verify its integrity and freshness, and then extract the protected first discovery message according to a policy or configuration; constructing a third discovery message that includes the first discovery protection message; protecting the third discovery message using a third set of keys into a third discovery protected message according to a policy or configuration; and transmitting the third discovery and protection message to the third device.

2. 2. The apparatus of claim 1, wherein the first discovery protection message and the second discovery protection message include or are associated with first and second timing values, respectively, determined by the policy or configuration, the first timing values ​​having lower resolution than the second timing values ​​for improved communication reliability.

3. the first discovery and protection message: determined from the timing values, determined from the number of bits in the timing value, determined from the accuracy of the timing values; determined from the index of the most significant bit of said timing value; determined as 2 raised to the power of a value calculated by subtracting 1 from the index of the most significant bit of the timing value; or stored together with a validity time determined from the time remaining until said timing value can no longer be used to correctly reconstruct a UTC-based counter used for verifying, unscrambling, and decoding the MIC; The apparatus of claim 1 or 2, wherein the timing value is included in the first discovery protection message or the second discovery protection message.

4. 4. The apparatus of claim 1, wherein the first discovery protection message and the second discovery protection message include a MIC, each MIC calculated in accordance with TS 33.503, section 6.1.3.2.

3.

5. The apparatus of claim 1 , wherein the policy or configuration determines that the first protected message is not scrambled.

6. 5. The apparatus of claim 1, wherein the measure or configuration determines that the first protected message is scrambled by setting b least significant bits of the UTC-based counter to zero, where b can be greater than 4 sufficient to ensure that the first protected message can be descrambled if it is cached for a configurable time greater than 2 to the power of b seconds.

7. 7. The apparatus of claim 1, wherein the policy or configuration determines whether the first discovery message, the second discovery message, or the third discovery message is encrypted, scrambled, or integrity protected.

8. If the first discovery protection message is valid, the first discovery protection message received or stored by the device is included in the third discovery message, and validity is determined by the validity time of the first discovery protection message; a time when constructing the third discovery message; a time for protecting the third discovery message; The apparatus of claim 1 , wherein the time for transmitting the third discovery protection message depends on at least one of the time for transmitting the third discovery protection message and the time for transmitting the third discovery protection message.

9. a condition for transmitting the third discovery protection message; period, a maximum number of the first discovery protection messages included in the third discovery message; The apparatus of claim 1 , based on at least one of the first discovery protection messages being close to expiring.

10. 10. The apparatus of claim 1, wherein the validity time of the first discovery protection message is determined by a UTC-based timer, a set of LSBs of the UTC-based timer, a number of bits in a timing value, an accuracy of the timing value, or an index of a most significant bit of the timing value associated with the first discovery protection message.

11. The device of claim 1 , wherein the security operations performed to protect the third discovery message are confidentiality protection, then integrity protection, and then scrambling.

12. The device includes in the third discovery and protection message: an indication of the number of the first discovery protection messages; and and an identifier of a target UE to which each first discovery protection message is addressed.

13. 13. The apparatus of claim 1, wherein the apparatus extracts the first protected discovery message from the second discovery message by reassembling and duplicating redundant message fields included in the second discovery message.

14. 14. The device of claim 1, wherein the device is configured with the policy or configuration and / or the set of keys by a network function of a core network.

15. 15. The device of claim 1, wherein the strategy or part of the strategy is hard-coded into the logic of the device.

16. An inter-UE relay comprising an apparatus according to any one of claims 1 to 15.

17. 1. A method for securely relaying a discovery message from a first device to a third device, the method comprising: receiving, by a second device, a second discovery protection message from the first device protected with a second set of keys, the second discovery protection message including the first discovery message protected end-to-end with a first set of keys according to a policy or configuration; the second device deprotecting the received second discovery protection message using the second set of keys, verifying integrity and freshness, and then extracting the first discovery protection message according to a policy or configuration; the second device constructing a third discovery message that includes the first discovery protection message; the second device protecting the third discovery message using a third set of keys into a third discovery protected message according to a policy or configuration; the second device sending the third discovery and protection message to the third device.

18. 1. An apparatus for secure UE-to-UE communications, the apparatus comprising: constructing a direct communication request (DCR) message with an integrated discovery that includes instructions for determining whether the message is protected; If the indication is available, protecting the DCR message with the joint discovery with at least a second set of keys; A device that broadcasts the DCR message with joint discovery.

19. 19. The apparatus of claim 18, wherein when network assistance is used for secure link establishment as indicated by an included RSC, the second set of keys is used to confidentiality protect privacy-sensitive information, e.g., the RSC, PRUK-ID, and integrity protect the DCR message with integrated discovery.

20. 20. The apparatus of claim 19, wherein the DCR message is protected with two sets of security material, whereby end-to-end sensitive information, e.g., UserInfoID, is confidentiality and integrity protected with a first set of keys if target UE UserInfoID is included in the DCR message.

21. A source end UE comprising an apparatus according to any one of claims 18 to 20.

22. 1. An apparatus for securely relaying a DCR message with joint discovery from a first device to a third device, comprising: receiving the DCR message with an integrated discovery including a protection instruction from the first device; If the protection indication is available, revoke the protection and verify the integrity and freshness of the DCR message; constructing a new DCR message with an integrated discovery from the received DCR message including the protection indication; If the indication is available, protecting the new DCR message with the joint discovery with at least one set of keys; The apparatus broadcasts the new DCR message protected with joint discovery to the third device.

23. 23. The device of claim 22, wherein the device identifies the protection indication by utilizing a security mechanism to establish a PC5 communication link that relies on network assistance.

24. If the protection indication is available, the device constructs a newly constructed DCR message with integrated discovery, the newly constructed DCR message comprising: the RSC is protected by XORing it with the output of a key derivation function, the output of which is shortened to the length of the RSC, without including a PRUK-ID field, or The RSC is protected by XORing the RSC with the output of the key derivation function, which includes a PRUK-ID field set to a predetermined or random value, and the output is shortened to the length of the RSC; or 24. The apparatus of claim 22 or 23, wherein the PRUK-ID and RSC are protected by XORing the PRUK-ID and RSC with the output of the key derivation function, the output of which includes the PRUK-ID field set to a predetermined or random value, the output being shortened to the length of the PRUK-ID and RSC.

25. The received DCR message with joint discovery is protected with a first set of keys and a second set of keys, and the device: Revoke the protection and verify the integrity and the freshness of the DCR message using the second set of keys associated with a first RSC; constructing a new DCR message with integrated discovery that includes end-to-end protection information protected with the first set of keys; protecting the constructed DCR message with the joint discovery with a third set of keys associated with a second RSC; 25. The apparatus of claim 22, wherein the apparatus broadcasts the new protected DCR message with integrated discovery to the third device.

26. 26. An inter-UE relay comprising an apparatus according to any one of claims 22 to 25.

27. 1. An apparatus for securely establishing a PC5 communications link, said apparatus comprising: receiving one or more DCR messages with integrated discovery including protection instructions from a second device; If the protection indication is available, the device revokes protection of the received DCR message with synthetic discovery and performs integrity and freshness verification.

28. The device, based on a strategy, The first step is to perform path selection to select the responding device; Build direct communication messages, If the protection indication is available, protecting the direct communication message with at least one set of keys; 28. The apparatus of claim 27, further comprising transmitting the protected direct communication message to the device selected in the first step.

29. The measure is: a direct communication link with a source end UE; a communication link including an intermediate device with which a security context has already been established; 30. The apparatus of claim 28, wherein the apparatus prioritizes one or more of a communication link with an intermediate device over which a security context is established.

30. 30. The apparatus of any one of claims 27 to 29, wherein the direct communication message includes a protected PRUK-ID.

31. 31. The apparatus of claim 27, wherein an indication is checked to determine whether the DCR message with integrated discovery is protected, the indication being an RSC, a security indicator associated with the RSC, the presence of a PRUK-ID field, or a message length.

32. 32. The device of claim 27, wherein if the protection indication is available, the device revokes protection of the DCR message with integrated discovery, verifies its integrity and freshness, and verifies whether the RSC is associated with a security procedure with network assistance.

33. If the protection indication is available, the PRUK-ID field is included in the DCR message with joint discovery, and the device: checking the PRUK-ID against a predetermined value; ignoring the PRUK-ID if the PRUK-ID matches the predetermined value; 33. The apparatus of any one of claims 27 to 32, wherein if the PRUK-ID does not match the predetermined value, the apparatus takes at least one of the following actions on the PRUK-ID: issuing an alarm.

34. 34. The apparatus of claim 27, wherein one or more of the received DCR messages with integrated discovery are protected with two sets of security material, a second set of keys associated with the RSC is used to revoke the protection and verify the integrity and freshness of the DCR message, and a first set of keys is used to revoke the protection and verify the integrity and freshness of end-to-end protection information.

35. 35. The apparatus of claim 34, wherein processing of the end-to-end protected information is prioritized to determine whether the DCR message is intended for a recipient, for example by checking whether the DCR message includes an identifier thereof, and the end-to-end information is not confidentiality protected by the second set of keys.

36. A target end UE comprising an apparatus according to any one of claims 27 to 35.

37. 1. An apparatus for secure and efficient communication with a second device, comprising: The apparatus sends a first message to connect with the second device, the first message including a MIC or an encrypted identifier and / or a key identifier; The apparatus receives a failure message when integrity verification or an RSC integrity check fails at the second device, and / or receives an acceptance message when the integrity verification is successful at the second device.

38. 38. The device of claim 37, wherein the device is configured with a strategy to determine its behavior in response to (1) not receiving a message, (2) receiving the failure message, (3) receiving the acceptance message, or (4) receiving the failure message and the acceptance message.

39. 39. An apparatus according to claim 37 or 38, wherein the apparatus receives the failure message, optionally including a cause of failure, the apparatus being configured with a strategy for deciding how to act based on the received cause of failure.

40. 40. The apparatus of any one of claims 37 to 39, wherein the apparatus waits for further communication from the second device when it receives both the failure message and the acceptance message and the integrity verification of the acceptance message is successful.

41. The device, by checking that the fingerprint exists and matches the fingerprint of a previously sent message, and / or 41. The apparatus of claim 37, wherein the apparatus verifies the integrity and / or freshness of the acceptance message and / or the failure message by taking as input at least the fingerprint or value from the first message, a UTC-based counter, or an identifier used to identify an integrity key, and accurately calculating a MIC in the acceptance message and / or the failure message, wherein the integrity key is a DUIK associated with the identifier, and the algorithm used to calculate the MIC is an NIA algorithm or a KDF-based MIC derivation algorithm.

42. 42. The device of any one of claims 37 to 41, wherein if the first message has not been sent, the device ignores a rejection message.

43. A remote UE comprising an apparatus according to any one of claims 37 to 42.

44. 1. A method for secure and efficient communication between a first device and a second device, comprising: The first device sends a first message to connect with the second device, the first message including a MIC or an encrypted identifier; The method, wherein the first device receives a failure message when integrity verification fails at the second device and / or receives an acceptance message when the integrity verification succeeds at the second device.

45. 45. The method of claim 44, wherein the first device is configured with a strategy to determine its behavior in response to (1) not receiving a message, (2) receiving the failure message, (3) receiving the acceptance message, or (4) receiving the failure message and the acceptance message.

46. 1. An apparatus for secure and efficient communication with a first device, the apparatus receiving a first message for providing connectivity with the first device, the apparatus comprising: i. The integrity key used in the previous discovery procedure; ii. An integrity key bound to one of the device's configured RSCs; iii. An integrity key bound to a previously exchanged message identified by a key identifier, or iv. Bound to the key identifier included in the message verifying the integrity of the first message by checking the MIC and / or encrypted identifier using an integrity key; The apparatus further comprising: i. ignoring said first message when MIC verification fails; ii. Returning a failure message when the integrity verification is successful but the RSC fails; and / or iii. returning an acceptance message if said integrity verification is successful; or Or, verifying the integrity of the first message by checking the MIC or the encrypted identifier using the integrity key bound to one of the configured RSCs of the device or the integrity key bound to the previously exchanged message identified by the key identifier; The apparatus further comprising: ignoring the first message if the integrity verification fails.

47. the acceptance message and / or the failure message, a fingerprint from the first message, and / or a MIC calculated taking as input at least the fingerprint or value from the first message, a UTC-based counter, or an identifier used to identify an integrity key; 47. The apparatus of claim 46, comprising: the integrity key is a DUIK associated with the identifier; and the algorithm used to calculate the MIC is an NIA algorithm or a KDF-based MIC derivation algorithm.

48. The device, if the previously received first message has been successfully verified; and / or if the integrity key cannot be determined to integrity protect the failure message; 48. Apparatus according to claim 46 or 47, wherein the failure message is not sent.

49. 49. A U2N repeater from a UE to a network comprising the apparatus of any one of claims 46 to 48.

50. 1. A method for secure and efficient communication between a first device and a second device, the method comprising: the second device receiving a first message providing connectivity with the first device including a Mic and / or an encrypted identifier; the second device verifying the integrity of the first message by checking the Mic and / or the encrypted identifier; the second device returning a failure message when the integrity verification of the encrypted identifier fails, and / or returning an acceptance message when the integrity verification is successful; A method comprising:

51. A system comprising a remote UE according to claim 43 and a UE2N relay according to claim 49.

52. 1. A method for securely establishing a PC5 communication link, the method comprising: receiving, by the device, one or more DCR messages with integrated discovery including protection instructions from a second device; If the protection indication is available, the device revokes protection of the received DCR message with integrated discovery and performs integrity and freshness verification.

53. 1. A method for securely relaying a DCR message with joint discovery from a first device to a third device, the method comprising: receiving the DCR message with an integrated discovery including a protection indication from the first device; If the protection indication is available, revoking protection and verifying the integrity and freshness of the DCR message; constructing a new DCR message with integrated discovery from the DCR message received in the previous step, including the protection indication; If the indication is available, protecting the new DCR message with the joint discovery with at least one set of keys; and broadcasting the new protected DCR message with integrated discovery to the third device.

54. 1. A method for secure UE-to-UE communication, the method comprising: The device constructs a direct communication request (DCR) message with an integrated discovery that includes instructions for determining whether the message is protected; If the indication is available, the device protects the DCR message with the joint discovery with at least a second set of keys; the device broadcasting the DCR message with joint discovery.

Images