Method for operating cellular network

Abstract

The present invention relates to a method for operating a communication system, comprising: receiving, from a first device, a second discovery protected message protected with a second set of keys, the second discovery protected message comprising a first discovery message end-to-end protected with a first set of keys according to a policy or configuration, the protection is canceled using a second set of keys and the integrity and freshness of the received second discovery protected message is verified, then the first protected discovery message is extracted according to a policy or configuration, a third discovery message comprising the first discovery protected message is constructed, and the third discovery message is received from the first discovery protected message. And protecting the third discovery message as a third discovery protected message by using a third key set according to a strategy or configuration, and sending the third discovery protected 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 networks or mobile networks in communication networks. Background Art

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

[0003] In the context of cellular networks standardized by 3GPP, the primary station is called a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or 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, the secondary station corresponds to a mobile station or user equipment (or 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 a UE or a gNB / eNB.

[0004] In addition, for example, in the case of PC5 interface or sidelink communication, there can be direct communication between secondary stations (here UEs). The UE can then also operate as a relay to allow, for example, UEs out of coverage to obtain an intermediate (or indirect) connection to an eNB or gNB. In order to be able to work as a relay, the UE can use discovery messages to establish new connections with other UEs.

[0005] Therefore, 3GPP introduced Figure 1The role of the relay node shown. The 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). The relay functionality allows, for example, the coverage of a cell 10 to be extended to an out-of-coverage (OoC) secondary station 110. The relay node 120 may be a mobile station or may be a different type of device. In the 4G specifications, proximity services (ProSe) functionality is defined in TS23.303 and TS24.334 to enable, among other things, connection of a cellular user equipment (UE) 110 that is temporarily out of coverage of a cellular network base station (eNB) 100 serving the cell 10. This particular functionality is referred to as ProSe UE to network relay or simply relay UE. Relay UE 120 relays applications and network services in both directions between OoC UE 110 and eNB 100. The local communication between the relay UE 120 and the OoC UE 110 is referred to as device-to-device (D2D) communication or sidelink (also referred to as PC5) communication in TS 23.303 and TS 24.334. Once the relay relationship is established, the OoC-UE 110 makes an IP connection, for example via the relay UE 120, and acts as a "remote UE" 110. This situation means that the remote UE has an indirect network connection to selected functions of the core network, rather than a direct network connection to all core network functions as is the normal case.

[0006] In addition, the role of UE has been introduced to UE relay node, that is, a relay node that relays communication between two UE devices. Figure 3 , where a relay node 310 relays communications between UE devices 320 and 330. UEs 310, 320, 330 may connect to the core network through base station 300 when within coverage.

[0007] Generally, it is challenging to determine how UEs communicating through a UE-to-network relay or a UE-to-UE relay can perform discovery of each other or establish secure communications in a secure manner. Summary of the invention

[0008] It is an object of the present invention to alleviate the above mentioned problems.

[0009] Another object of the present invention is to better protect the discovery messages and security establishment in relay scenarios when integrated discovery is used or when integrity failures are handled in the initial steps of communication establishment. Another object of the present invention is to better and more securely switch paths in UE to UE relay use cases, i.e., to improve how two UE devices securely and privately switch UE to UE relay.

[0010] Another object of the present invention is to propose a method for a secondary station communicating in a network, which method in operation requires a minimum interaction once with the core network.

[0011] Some modifications of the security routines are proposed according to various aspects of the invention to make them operationally work and improve security / privacy protection and performance.

[0012] To this end, according to a first aspect of the present invention, a device for securely relaying a discovery message as claimed in claim 1 is proposed.

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

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

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

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

[0017] According to 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] According to a seventh aspect of the present invention, an apparatus for secure and efficient communication as claimed in claim 46 is proposed.

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

[0020] According to a ninth aspect of the present invention, a computer program product is proposed, comprising code means for producing the steps of the method of the first to eighth aspects of the present invention when executed on a computer device.

[0021] It should be noted that the above devices can be implemented based on a discrete hardware circuit system having discrete hardware components, an integrated chip or a chip module arrangement, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer-readable medium or downloaded from a network (such as the Internet).

[0022] It shall be understood that the apparatus and the method may have similar, corresponding and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0023] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above-described 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 devices can 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 a memory, written on a computer-readable medium, or downloaded from a network (such as the Internet).

[0026] It should be understood that the apparatus of claims 1 and 2, the communication device of claims 13 and 14, the method of claims 13 and 14, the computer program product of claim 15, and the system of claim 16 may 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 DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A cellular system in which the present invention is implemented has been described and schematically represented;

[0029] Figure 2 The process of integrated discovery in UE-to-UE relay communication is schematically described.

[0030] Figure 3 The discovery process in a UE-to-UE relay scenario is schematically described;

[0031] Figure 4 The process for establishing the security of a PC5 communication link in a UE-to-UE relay scenario is schematically described;

[0032] Figure 5 schematically shows another cellular system implementing the present invention;

[0033] Figure 6 schematically represents a further embodiment of the present invention related to UE-to-UE integrated discovery;

[0034] Figure 7-9 schematically illustrates further embodiments of the present invention related to UE-to-UE discovery;

[0035] Fig.10The process of establishing a secure PC5 communication link with integrated discovery over a UE-to-UE relay is schematically described;

[0036] Fig.11 The process of establishing a secure PC5 communication link with integrated discovery via UE-to-UE relay or directly with a source UE is schematically described;

[0037] Fig.12 Schematically describing Model A discovery assisted by UE-to-UE relay announcement scheduling for terminal UE; and

[0038] Fig.13 Model A discovery using UE-to-UE relay with on-demand direct discovery set protection is schematically described. DETAILED DESCRIPTION

[0039] Various aspects of the present invention will be described in detail in the following embodiments. As mentioned above, embodiments of the present invention may relate to various types of wireless communications, and in particular to connection establishment of a device attempting to access a wireless network. A typical example is a cellular network, such as a 5G network, which may include some relay nodes. These relay nodes may be implemented by a UE, such as a sidelink-compatible UE that can operate as a relay node or implemented by other types of repeaters.

[0040] In order to allow new connections through such a relay, a discovery phase is required, in which discovery messages may be sent to or by the relaying UE. One general purpose of this particular exemplary embodiment is to increase the protection of such discovery messages. Technical specification TS 33.303 v17.0.0 describes the protection of discovery messages in section 6.1.3.4.3. It lists three types of security for protecting restricted discovery messages, as detailed below:

[0041] First, integrity protection is provided by attaching a MIC (Message Identification Code) in the Open Discovery (see subclause 6.1.3.3.1). The MIC is calculated in the sending UE using the received Discovery User Integrity Key (DUIK), and the MIC can be checked at the receiving UE using the provided DUIK or at the ProSe function (relay node).

[0042] Secondly, scrambling protection ensures that there is no relationship between discovery messages sent by a specific UE, i.e., preventing UE tracking over time. The scrambling key stream is calculated based on the Discovery User Scrambling Key (DUSK) and a UTC-based counter associated with the discovery slot (see 6.1.3.4.3.5 for more details on the calculation).

[0043] Finally, message specific confidentiality that provides confidentiality protection for a portion of the discovery message. This is used when several UEs use the same DUSK or when it is desired to obfuscate a portion of the discovery message from some of the UEs that are allowed to discover. The key stream is calculated based on the discovery user confidentiality key (DUCK), the content of the message, and a UTC-based counter associated with the discovery slot (see 6.1.3.4.3.6 for more details on the calculation).

[0044] The security procedures applied at the sending UE and the receiving UE are controlled by the ProSe function by sending code-send security parameters and / or code-receive security parameters to the appropriate UE (i.e., the UE shall support all items in integrity protection, scrambling and message-specific confidentiality). In order to achieve integrity protection of ProSe restricted discovery messages, either DUSK or DUIK needs to be provided. When DUCK is used to apply message-specific confidentiality, DUIK is required for integrity protection since more than one message is protected. Examples of combinations of discovery user keys according to the use case type are provided in Appendix G.

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

[0046] On the receiving side, the scrambling protection must be removed before any matching can be attempted. Given that the operation of removing message-specific confidentiality is computationally intensive, the matching operation preceding it should have a very small chance of false positives. To this end, the ProSe function should ensure that the number of bits in the discovery message that can be matched after any scrambling has been removed is at least 16 (resulting in a false positive chance of 1 in 65536 or less).

[0047] Technical specification TS 33.503 describes further procedures for protecting discovery messages, where discovery messages are characterized by a long size. The discovery procedure is also specified in the context of UE to network relay. The main differences compared to TS 33.303 are the use of scrambling in the first 32 bytes, confidentiality protection for the entire message, and the use of a MIC set to a random value when the message has no integrity protection.

[0048] In addition, TS 33.503 describes in clause 6.3.5 a procedure for protecting a Direct Communication Request (DCR) message sent by a remote UE to a UE-to-network relay, whereby the protection mechanism reuses the discovery key. When DUIK is configured, the DCR message is integrity protected. When DUCK or DUSK is configured, the Relay Service Code (RSC) and PRUK-ID are confidentiality protected.

[0049] Similar techniques can be applied to establish a (secure) PC5 communication link in a UE-to-UE relay scenario, once discovered and referenced Figure 4 , where a UE (e.g., a source UE) may send a direct communication request (DCR) message including certain parameters, such as an RSC or PRUK ID or a first random number for subsequent key derivation. Unless the procedures in clause 6.3.5 in TS 33.503 are applied, this information may be exchanged in plain text. The process and requirements are further illustrated by a source UE 420, which wishes to establish a secure communication link with a target UE 430 via a UE-to-UE relay 410. The CN or one or more network functions in the CN 400 perform the configuration. 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, respectively, and discovery security material from the PKMF. In addition, the remote UE may be equipped with security material for PKMF end-to-end security setup. For example, the security material for the end-to-end security setup includes a Prose Service Code (PSC) and associated keys. In subsequent steps, the remote UE 420 performs a discovery process and a PC5 unicast link establishment process with the UE-to-UE relay 410 in the following manner: (i) discovering the UE-to-UE relay; (ii) sending a direct communication request including a relay service code (RSC), a PRUK ID, and a random number 1; (iii) performing authentication and key agreement between the remote UE 420 and the UE-2-UE relay 410, and as a result of successful authentication, deriving a key KNRP. Subsequently, the UE-2-UE relay 410 generates a random number 2 and derives a KNRP-ESS using KNRP, random number 1, and random number 2. The UE-2-UE relay 410 sends a direct security mode command including random number 2 to the remote UE 420. The direct security mode command is integrity protected based on the KNRP-SESS. Then, the remote UE 410 derives the KNRP-SESS using KNRP, random number 1, and random number 2, and checks 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-2-UE relay 410. In order to protect certain privacy-sensitive fields or all fields in the DCR message exchange during the UE-to-UE relay, for example, as described in the above exemplary process, the sending device and the receiving device need to select one of the keys in the discovery parameters, such as:

[0050] 1. If DUCK is available, DUCK will be used to protect these privacy-sensitive fields, and

[0051] 2. If DUCK is not available and DUSK is available, DUSK will be used to protect these privacy-sensitive fields, otherwise,

[0052] 3. If both DUCK and DUSK are unavailable, then privacy-sensitive fields or all fields in the DCR message shall not be protected.

[0053] Once (and if) a key is selected, the sending device can protect the DCR message and send the protected DCR message. Once (and if) a key is selected, the receiving device can receive the protected DCR message and process it securely (decryption / integrity verification). Note that if the source UE and target UE have a common discovery key set that is unknown to the relay, then this key set may be preferred.

[0054] The 8etwe embodiments are described in the context of a UE relay that can allow a remote UE, which may be out of coverage, for example, to connect to a network. This type of relay is referred to as a UE-to-network relay or U2N relay, etc. The UE relay can also allow two terminal UEs to communicate with each other. This type of relay is referred to as a UE-to-UE relay or U2U relay, etc. The terminal UEs can be represented as a source UE and a target UE, etc. Different peers of the UE can perform a discovery process to discover each other and / or can send initial communication messages to establish a secure 8etween8n8ng8 link. For example, a remote UE and a UE-to-network relay can discover each other, and then the remote UE can send a direct communication request to the UE-to-network relay. For example, a UE-to-UE relay and two terminal UEs may want to discover each other, and then one of the terminal UEs can send a direct communication request to start the establishment of a PC5 communication link.

[0055] Throughout this disclosure, the following acronyms refer to the following corresponding definitions:

[0056] KDF: stands for key derivation function. KDF is defined, for example, in TS 33.220 v18.0.0 in Appendix B.2. In this example, a KDF of an input bit string S with a key K (i.e., KDF(K, S)) may be equivalent to HMAC-SHA-256(K, S), where SHA-256 is the hash function used in the HMAC construction. The bit string S may be constructed from multiple parameters param1, param2, ..., paramN as described in TS 33.220, but these parameters are concatenated with their assigned lengths and include a unique identifier denoted as FC for a specific use of the KDF. Sometimes, instead of being written as KDF(K, S), it is written as KDF(K, param1, param2, ..., paramN), where it should be understood that the bit string S is constructed from fields param1, param2, ..., paramN.

[0057] NEA and NIA: These are the encryption (NEA) and integrity algorithms (NIA). In 5G implementations, these are described in Annexes D.2 and D.3 of TS 33.501.

[0058] DUSK, DUCK, and DUIK: These refer to the corresponding keys used for scrambling, encryption, and integrity, respectively. In the 5G discovery embodiment, these refer to the discovery user scrambling key, the discovery user encryption key, and the discovery user integrity key, respectively.

[0059] DP_X-Y: These correspond to some security discovery parameters, such as key material used between entities X and Y, for example, DP_S-UE-to-UE refers to the discovery security parameters associated with the RSC used between the source UE and the UE-to-UE relay.

[0060] Scrambling / Confidentiality / Integrity Protection Procedures for Discovery Messages in UE-to-UE Relay Scenario

[0061] In the following embodiments, embodiments and embodiment variants related to a "UE to UE" relay use case are presented, where a source user equipment (UE) device needs or wants to communicate with a target UE device via a UE to UE relay device. The UE to UE relay use case involves at least two phases, (secure) discovery and establishment of a (secure) PC5 communication link. These two phases present certain challenges that have been addressed in some of the above embodiments.

[0062] Regarding (secure) discovery of UEs (source UE, UE-to-UE relay, target UE), certain architectural solutions may require "hop-by-hop" and "end-to-end" discovery. For example, a discovery message sent by the source UE and directed to the target UE (e.g., a notification discovery message in discovery model A or a request discovery message in discovery model B) may be (1) first protected with discovery parameters bound to the end-to-end communication link between the source UE and the target UE, and these discovery parameters (DP_S-T) may include DUIK, DUSK, or DUCK. Then, the discovery message may be (2) secondarily protected with discovery parameters bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay (DP_s-UE-to-UE). These parameters may also be DUIK, DUSK, and DUCK. When the UE-to-UE relay receives the message, the UE-to-UE may process the message, where the processing involves secure processing of the discovery message using DP_s-UE-to-UE. After processing, the UE-to-UE relay may check whether the discovery message is for its UE-to-UE relay service, for example by performing a matching action in TS 33.503. If so, it protects the message using the discovery parameters (Dp_UE-to-UE-T) bound to the hop-by-hop communication link between the UE-to-UE relay and the target UE. When the target UE receives the message, the target UE may process the message, where the processing involves (1) security processing of the discovery message using Dp_UE-to-UE-T and then (2) security processing of the discovery message using Dp_S-T.

[0063] In the supplementary description, refer to Figure 3 , describes the security process of 5G ProSe UE to UE relay discovery model A as follows:

[0064] exist Figure 3 In step 340, the discovery security material from the network function (e.g., 5G PKMF) in CN300 is provided to the announcing UE 320 by performing a relay discovery key request procedure. The discovery security material may include two sets of code transmission security parameters: a code transmission security factor associated with the ProSe service and a code transmission security factor associated with the relay service code (RSC). In addition, each code transmission security parameter set includes CURRENT_TIME and MAX_OFFSET parameters.

[0065] exist Figure 3In step 341, by performing a relay discovery key request procedure, the ProSe 5G UE to UE relay 310 may be provided with discovery security material from a network function in the CN 300. The discovery security material includes a code send security parameter and a code receive security parameter associated with the RSC. In addition, each security parameter set may include CURRENT_TIME and MAX_OFFSET parameters.

[0066] exist Figure 3 In step 342, by performing a relay discovery key request procedure, discovery security material from a network function in CN 300 is provided to monitoring UE 330. The discovery security material may include two sets of code reception security parameters: code reception security parameters associated with ProSe services and code reception security parameters associated with RSC. In addition, CURRENT_TIME and MAX_OFFSET parameters are included for each security parameter set.

[0067] exist Figure 3 In step 350, if the UTC-based counter provided by the system associated with the discovery slot is within the MAX_OFFSET of the ProSe clock of the announcing UE and if the validity timer has not expired, the announcing UE may start broadcasting the announcement message. The announcing UE may form the announcement message and protect the message as follows: it first sends security parameters using a code associated with the ProSe service to protect the end-to-end (E2E) ProSe discovery information; then, it sends security parameters using a code associated with the RSC to protect the announcement message.

[0068] exist Figure 3 In step 360, if the UTC-based counter associated with the discovery timeslot is within the MAX_OFFSET of the ProSe clock of the ProSe 5G UE to UE relay, the ProSe 5G UE to UE relay listens for announcement messages that match its discovery filter. The ProSe 5G UE to UE relay processes the received announcement messages to find messages that match its discovery filter. When the ProSe 5G UE to UE relay processes the message, it receives security parameters using the code associated with the RSC to unprotect the received message. Upon identifying a matching message, the ProSe 5G UE to UE relay forms a relay announcement message containing the original announcement message and sends security parameters using the code associated with the RSC to protect the relay announcement message. The ProSe 5G UE to UE relay then starts broadcasting the relayed announcement message.

[0069] exist Figure 3In step 370, the monitoring UE listens to the relay announcement message from the ProSe 5G UE to the UE relay. The monitoring UE processes the received relay announcement message to find a message that matches its discovery filter. When the monitoring UE processes the message, it first uses the code reception security parameter associated with the RSC to unprotect the message, and further uses the code reception security parameter associated with the ProSe service to unprotect the E2E ProSe discovery information.

[0070] exist Figure 3 In step 350, the message may include the type of discovery message, discoverer information, RSC and E2E discovery information in the request message. Figure 3 The message in step 360 may include the type of discovery message, discoverer information (i.e., relay user information ID), RSC, relay indication (used to indicate ProSe direct discovery forwarding), original discoverer information (i.e., source 5G ProSe U2UUE 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 indication.

[0071] In Model A discovery, the source UE may be referred to as an advertising UE, and the target UE may be a monitoring UE, or vice versa. In Model B discovery, the source UE may be referred to as a discoverer UE, and the target UE may be a discovering UE.

[0072] In model B discovery, the message flow is as follows Figure 3 As shown, message 350 and message 360 ​​correspond to request and relay request messages, and the additional message 330 replies to 320 corresponds to response and relay response messages.

[0073] The above process needs to first consider that when the source UE utilizes DP_S-T bound to the end-to-end communication link between the source UE and the target UE to protect the message, this security processing of the discovery message may mean scrambling the first part of the message (e.g., the first 32 bytes of the message). If this is done, the UE-to-UE relay may not be able to check whether the discovery message is for its UE-to-UE relay service, for example, because some fields are scrambled.

[0074] Therefore, in an alternative to one embodiment, the source UE and the target UE shall not be configured with DUSK in the DP_S-T bound to the end-to-end communication link between the source UE and the target UE. Since DUSK does not exist, no scrambling is performed.

[0075] Therefore, in an alternative embodiment, the source UE and the target UE and the UE-to-UE relay must be configured with the same DUSK in DP_S-T and DP_S-UE-2-UE. Since the DUSK is the same, the relay UE-to-UE can descramble the message.

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

[0077] Therefore, in another alternative embodiment, the source UE and the target UE must be configured with a mask that determines which part of the message will be scrambled with the scrambling key in DP_S-T or not. If this is done, the UE-to-UE relay can still descramble the message with DP_S-UE-2-UE and filter the valid message. For example:

[0078] Scrambled message = message XOR ((0x FFFF||mask) AND time hash bit sequence)

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

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

[0081] The above process requires a second consideration: when the source UE uses DP_S-T bound to the end-to-end communication link between the source UE and the target UE to protect the message, this first security processing of the discovery message may mean appending a first MIC calculated with the first DUIK in the DP_S-T. When the source UE uses DP_S-UE to UE bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay to protect the message, this second security processing of the discovery message may require appending a second MIC calculated with the second DUIK in the DP_S-UE to UE.

[0082] Therefore, in another embodiment variant, the discovery message may have two MICs.

[0083] Therefore, in another embodiment variant, the discovery message may contain two timing values, such as the least significant bits of the UTC time. A first timing value is used with the first MIC, and a second timing value is used with the second MIC.

[0084] Furthermore, in another embodiment variant, the accuracy of the first timing value for the first MIC associated with end-to-end communication may not be as accurate as the accuracy of the second timing value for the second MIC associated with hop-by-hop (e.g., relay to target UE) communication. For example, the first timing value may allow a time difference of 2 seconds, while the second timing value may allow a time difference of 1 second. This embodiment variant allows for improved reliability of the protocol. This also applies to situations where a UE-to-UE relay can cache messages received from a source UE and keep retransmitting them. This is because the accuracy of the first timing value can be made equal to the cached time value of the relay.

[0085] It should be noted that if the first timing value and the second timing value refer to certain bits of the UTC-based counter, the fact that the first timing value is less accurate is equivalent to saying that it refers to the accuracy of the lowest bit in the UTC-based counter. For example, assume that the entire UTC-based counter is 16 bits long and has an accuracy of 1 second. For example, assume a UTC-based counter value, represented by hexadecimal 0x1234 and binary 0001 0010 0011 0100, where the most significant bit is on the left and the least significant bit is on the right, and the increment of 1 indicates that it is 1 second later. Then in this example, the 4 least significant bits are 0100 (bits 3-0) and have an accuracy of 1 second. Because it contains information about the 4 LSBs, it can correct errors of up to 8 seconds (16 seconds in some cases). Assume that 4 bits of the UTC-based counter are sent, but correspond to bits 4-1, that is, 1010 in the above example. This timing value has an accuracy of 2 seconds because the lowest bit has an accuracy of 2 seconds, that is, the accuracy of this timing value is lower. This timing value can correct errors of up to 16 seconds (32 seconds in some cases).

[0086] In addition, in another embodiment variant, UTC time is used to scramble / descramble the message. According to TS33.503 and TS 33.303 (clause 6.1.3.4.3.5), the 4 LSBs of the UTC-based counter are set to 0 in this operation. This may not be enough or efficient, for example, if the UE-to-UE relay introduces a high processing or buffering time (more than 8 seconds), and more than 4 LSBs of the UTC-based counter are sent (because as mentioned above, if more than 4 LSBs are sent, the value remains valid for a longer period of time according to the index of the most significant bit sent). Therefore, the scrambling process in TS 33.503 / TS 33.303 is modified to set x LSB to 0 when scrambling the direct discovery set exchanged between terminal UEs, where x can be, for example, 5, 6, ... This ensures that the terminal receiving device can descramble the message and access the integrity-protected message, and minimizes the amount of resources required so that it can continue to decrypt and verify its integrity. For example, if a UE-to-UE relay can cache discovery messages for 32', it is advantageous if the terminal UE sets at least 6 LSBs of the UTC-based end-to-end counter to 0. This embodiment variant may be configurable (e.g., depending on the ProSe application / code or RSC used). The absolute / relative x values ​​may also be exchanged in the discovery message itself. Note that this embodiment variant is similar to using a less accurate UTC-based counter to protect end-to-end messages (protected with DP_S-T) compared to the UTC-based counter used to protect discovery messages between terminal UEs (source UE and target UE) and the UE-to-UE relay. Note that the effect of this embodiment variant is similar to that of DUSK requiring no end-to-end security parameters (DP_S-T) to be used, as it allows the message to be descrambled and subsequent decryption / integrity verification to be performed. This embodiment variant applies, for example, to steps 2 and 4 in clause 6.1.3.3.3.1 of the CR draft of TS 33.503 (TDoc S3-233374) for the security procedure of 5G ProSe UE-to-UE relay discovery using model A, or to steps 1, 2, 3, 4 in clause 6.1.3.3.2.

[0087] In another related embodiment variant, if the timing values ​​(LSB of the UTC-based counter) are different or have different accuracy, these different timing values ​​can also be used in the confidentiality and / or scrambling sequence. This allows the relay to cache the discovery message and retain it for a longer period of time, and allows the target UE to receive the message and successfully decrypt / descramble the message within a longer period of time.

[0088] In another related embodiment, the second timing value may correspond to x LSBs of a UTC-based counter (e.g., bits 0, ..., x-1), and the first timing value may include a subset of y of these bits (e.g., bits 1, ..., y) or less y bits (e.g., bits x-1, ..., x+y-1). This allows larger time differences to be resolved with a smaller number of bits. In other words, the message can remain valid for a longer period of time, which requires fewer bits to be transmitted.

[0089] In another embodiment, the second timing value may be 4 or 8 LSBs of the UTC-based counter, i.e., bits 0-3 and bits 0-7, respectively. In addition, the first timing value may include bits 5-8 or bits 8-15 of the UTC-based counter. In other words, there may be overlap between the timing values. This method of 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 over a longer period of time (longer validity time) without sending additional bits. This longer period of time determined by the number of bits of the LSB of the UTC-based counter, in particular the most significant bit of the UTC-based counter sent, determines the validity period of the message. For example, if the first timing value refers to bits 0-7 of the UTC-based counter, where bit 7 is the most significant bit, the validity period of the message is approximately 2^{7} seconds. For example, if the first timing value refers to bits 4-7 of the UTC-based counter, then the validity period of the message is also ~2^{7) seconds.

[0090] In another embodiment variation related to the previous embodiment, the timing values ​​may have some overlapping bits, for example, the first timing value may be the 4 LSBs of the UTC-based counter, and the second timing value may be the 8 LSBs of the UTC-based counter. When the source UE sends the protected discovery message to the UE-to-UE relay, there is no need to send the overlapping bits twice. For example, in the previous example, due to the overlap between the two timing values, 8 bits may be required to send both timing values. When the UE-to-UE relay forwards / sends the protected discovery message to the target UE, the UE-to-UE relay only includes the first timing value, which in the previous case included the 8 LSBs of the UTC-based counter.

[0091] In another embodiment variant related to the previous embodiment, the first timing value may contain (a part of) the second timing value.

[0092] In another embodiment variant related to the previous embodiment, both timing values ​​may be included at the beginning of the discovery message. In another variant, since the least significant bits of the first timing value of the UTC-based counter are missing, these bits may be set to a predefined value (e.g., all zeros or all ones) when the fully reconstructed UTC-based counter is used in a cryptographic function such as a KDF. For example, if the UTC-based counters of the source UE transmitter are T3, T2, T1, T0, and T0 is not sent but T1 is sent, the target UE receiver will use the received T1 to correct its own UTC-based counters T3', T2', T1', T0'. In both cases, when the UTC-based counters are used, such as when calculating a MIC or generating a pseudo-random bit stream for encryption purposes, the LSBs of the UTC-based counters (i.e., T0 and T0') are set to a predefined value, such as all zeros (e.g., 0x00 if T0 and T0' are 1 byte long).

[0093] In another embodiment, the meaning of the timing value (eg, the first timing value) and / or the correction value of the LSB (which may not be sent) may be determined by policy or pre-configured in the software of the UE.

[0094] In a related embodiment, one of the timing values ​​(eg, the first timing value) is an absolute time value, such that the freshness check of the destination is based on the absolute time, thereby avoiding problems that arise when, for example, a repeater performs discovery message caching.

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

[0096] In another related embodiment, if the timing value for end-to-end communication is valid within T seconds, then the discovery message arrives at the relay with a delay of L, then the relay may retransmit it within TL seconds. For example, T may be determined based on the number of bits of a UTC-based counter or the index of the most significant bit of a UTC-based counter. L may be a configuration parameter, for example, which may determine that the discovery message should be sent at least L seconds before the message validity expires or the MIC-based freshness check is no longer valid.

[0097] In another related embodiment, if the timing value of the end-to-end communication is valid within T seconds, the discovery message arrives at the relay at time t, and then the relay can resend to 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 T may depend on the accuracy of the received timing value. Delta may depend on the safety window to ensure that the message can be successfully authenticated at the receiving end.

[0098] In another related embodiment, discovery parameters such as cache time and / or timing value range / accuracy and / or discovery key to be used and / or other parameters are determined by policy. These parameters can be linked to, for example, discovery code, relay service code or application code such as ProSe code.

[0099] In another embodiment, if one wishes to further optimize the UE-to-UE discovery process, redundant encryption / integrity protection may be avoided by configuring only the appropriate keys. Redundant encryption may mean that if RSC is used only with ProSe services, encryption does not need to be applied in the end-to-end and hop-by-hop links. However, ProSe codes and relay service codes are not mapped to each other, which hinders flexibility. In particular, for a given ProSe application, it may be necessary to:

[0100] - the first ProSe application performs a direct discovery, then all keys (DUSK, DUCK, DUIK) may be configured in the discovery keys associated with (the ProSe code of) said ProSe application,

[0101] - a first ProSe application performs UE-to-UE discovery through a UE-to-UE relay that can be used by a second ProSe application, and then all the keys (DUSK, DUCK, DUIK) can be configured in the discovery key (ProSe code) associated with said ProSe application,

[0102] -The first ProSe application performs UE-to-UE discovery via a UE-to-UE relay that can be used by a second ProSe application, and no keys may be configured in the discovery keys associated with (the ProSe code of) the ProSe application (DUSK, DUCK, DUIK are not configured), and only keys associated with the relay service code (DUSK2, DUCK2, DUIK2) may be configured.

[0103] To achieve this:

[0104] In one variant, a UE may be configured with a ProSe code including an indication of an associated RSC to perform UE-to-UE discovery, whereby the association indicates whether the RSC is shared with other ProSe codes (ProSe applications).

[0105] In a related variation, the ProSe code used for UE-to-UE discovery comprises / is associated with two key sets, a first key set used to protect a direct discovery set as described in other embodiments, and a second key set used to fully protect UE-to-UE discovery messages.

[0106] In a related variation, the ProSe code may include an indication determining whether it is for direct discovery (associated with a single discovery key set) or for UE-to-UE discovery (associated with two discovery key sets).

[0107] In a related variation, the UE may select a ProSe code depending on whether the UE is performing direct discovery or UE-to-UE discovery.The type of code to be used may be determined based on the discovery message being sent / received.

[0108] In another related embodiment, the discovery parameters of the UE are optimized for performance, e.g.

[0109] - If the relay UE can cache the discovery message for time T, the source UE only needs to send a discovery message every T seconds, and the timing value is such that the corresponding time error can be resolved.

[0110] - 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 transmission time is based on the policy, for example, to reduce errors by sending when the current time t modulo T equals 0 or T / 2.

[0111] Therefore, in another embodiment variant, the discovery message may contain a single timing value, such as the least significant bits of the UTC time, and the same timing value is used in the calculation of both the first MIC and the second MIC. The UTC value is the UTC value of the source UE. Upon receiving the message (e.g., Figure 3 350 in DP_UE to UE-T), the UE to UE relay processes the message with end-to-end security parameters including verification of the second MIC. The UE to UE relay integrity protects the discovery message using the third DUIK in DP_UE to UE-T by using the same UTC value in the received message and without updating or setting the UTC counter value in the sent message. This embodiment variant allows bandwidth savings.

[0112] In some cases, the source UE may wish to communicate with multiple N target UEs. In this case, in another embodiment, some parameters of the discovery message defined in TS 33.503 can be reused in the calculation of each target UE, for example, a single timing value can be used to calculate multiple MICs, where each MIC is a MIC for end-to-end protection between the source UE and the target UE k (k=1, ..., N). This has the advantage of reducing the size of the discovery message.

[0113] Therefore, in another embodiment variant, both the first MIC and the second MIC may be included at the beginning of the discovery message. This may require some changes to TS 33.503 and TS 33.303.

[0114] For example, when the UE protects the discovery message using a first key set (e.g., when the source UE protects the discovery message using DP_S-T bound to the end-to-end communication link between the source UE and the target UE), clause 6.1.3.2.3 in TS 33.503 may require that step 3 of clause 6.1.3.4.3.5 in TS 33.303 [4] be XORed with the most significant (L+16) bits of the discovery message (0xFFFF||time-hash bit sequence), and when the UE protects the discovery message using a second key set (e.g., when the source UE protects the discovery message using DP_S-UE-to-UE bound to the end-to-end communication link between the source UE and the UE-to-UE relay), clause 6.1.3.2.3 in TS 33.503 may require that TS Step 3 of clause 6.1.3.4.3.5 of 33.303 [4] is XORed with the most significant (L+16+16) bits of the discovery message (0xFFFF||time-hash-bit-sequence). Here, time-hash-bit-sequence-2 may be 16 bits longer than time-hash-bit-sequence-1.

[0115] For example, clause 6.1.3.2.3 in TS 33.503 may require that the time-hashed bit sequence key stream in A.5 of TS 33.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 to be scrambled and is set to Min(length of the discovery message - 16, 256).

[0116] For example, clause 6.1.3.2.3 in TS 33.503 may require that the time-hashed bit sequence key stream in A.5 of TS 33.303 [4] be set to a variable size, for example, the L or L+16 least significant bits of the KDF output, where L is the bit length of the discovery message to be scrambled and is set to Min(length of the discovery message - 16, 256).

[0117] For example, when the UE protects the discovery message with a second key set, clause 6.1.3.2.3 in TS 33.503 may require step 3 of clause 6.1.3.4.3.5 in TS 33.303 [4] to be XORed with the most significant bits (L+16+16) of the discovery message (0xFFFFFFFF||time-hash bit sequence), for example, when the source UE protects the discovery message with DP_S-UE to UE bound to the end-to-end communication link between the source UE and the UE-to-UE relay, where L is the bit length of the discovery message to be scrambled and is set to Min(length of the discovery message - 16, 256).

[0118] Therefore, in another embodiment variant, the second MIC may be calculated for the entire message after the first security processing, that is, the second MIC also means integrity protection for the first MIC.

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

[0120] In another related embodiment, the single MIC in the third protected (discovery) message is calculated as the XOR of the end-to-end MIC between the source UE and the target UE (calculated using DP_S-T) and the hop-by-hop MIC between the UE-to-UE relay and the target UE (calculated using DR_UE-to-UE-T). This is feasible because the UE-to-UE relay can calculate this second hop-by-hop MIC and use it to XOR the end-to-end MIC received in the second discovery protection message, which becomes the MIC of the third discovery protection message. The target UE can verify the hop-by-hop and end-to-end integrity because the target UE can first calculate the hop-by-hop MIC and "delete" its contribution from the received MIC in the third discovery protection message, thereby obtaining the end-to-end MIC again. The target UE can then verify the end-to-end MIC in a standard manner. This is advantageous because it allows for a reduction in communication overhead while still providing end-to-end and hop-by-hop security.

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

[0122] In another embodiment, the source UE may protect the content of the discovery message as follows:

[0123] 1. Protect N (source UE to target UE) i ) discovery message is sent to a set of up to N different discovery key material sets DP_S-T i N different target UEs, where i=1, ..., N. This can be as follows:

[0124] • Each of these source UE to target UE discovery messages may be protected in accordance with TS 33.503 so as to return protected discovery messages.

[0125] The source UE may obtain a portion of the protected discovery message corresponding to the fields that need to be exchanged. This allows the size of the discovery message to be sent to be reduced. For example, if there are two target UEs, two (source UE to target UE) discovery messages may be constructed and structured first, including, for example, timing values ​​(e.g., the LSBs of a UTC-based counter). However, since a single value common to both discovery messages may need to be sent, these timing values ​​may be removed.

[0126] 2. Assemble the (source UE to UE to UE relay) discovery message with (the selected protection fields of) N (source UE to target UE) discovery protection messages.

[0127] · Assembly can be done in a cascade manner.

[0128] • N (source UE to target UE) discovery protection messages may be carried, for example, in the metadata field of the (UE to UE relay source UE to UE to UE relay) discovery message.

[0129] • The assembly may be done by creating a header of a (UE to UE relay source UE to UE to UE relay) discovery message and appending / attaching / inserting N (source UE to target UE) discovery protection messages (or fields selected therefrom).

[0130] The selected protected fields may be, for example, N MICs or a confidentiality protected user information ID.

[0131] 3. According to TS 33.503, the discovery key material DP_S-UE to UE is used to protect the (UE to UE relay source UE to UE to UE relay) discovery messages.

[0132] • In this case, the first timing value associated with the (source UE to target UE) discovery protection message may be greater than the second timing value associated with the (UE to UE relay source UE to UE to UE relay) discovery protection message.

[0133] - In this case, only the first timing value may need to be sent, and the second timing value may be a subset of the first timing value (eg, the LSB).

[0134] 4. Send the discovery protection message to the UE-to-UE relay.

[0135] Figure 7 and Figure 8 The potential message structures in the above embodiments (and other embodiments in the present application) are shown, in particular, UE-to-UE discovery messages between a source UE and a UE-to-UE relay. In these figures, the first field is the message type, followed by a timing value (UTC-based time), followed by a MIC, followed by UE information (e.g., source UE or UE-to-UE relay information), followed by a payload field (e.g., a metadata field). Figure 7 In , the end-to-end discovery messages between the source UE and the target UE are encapsulated / transmitted as generated after applying the security routines in TS 33.503 to protect them. Figure 8 In order to reduce communication overhead, only selected fields of the protected end-to-end discovery message between the source UE and the target UE are encapsulated / transmitted.

[0136] In another embodiment, as described above, the UE-to-UE relay may receive the content of the discovery protection message as follows:

[0137] - Securely handle incoming (UE-to-UE Relay Source UE-to-UE Relay) discovery messages as described above using the discovery key material DP_S-UE-to-UE.

[0138] - Extract (the fields of) N (source UE to target UE) protection discovery messages.

[0139] - (Re)assemble (if necessary) N (source UE to target UE) protected discovery messages, for example, if the timing value is reused for N protected discovery messages, it should be reintroduced when needed. In general, if the (source UE to target UE) discovery message contains two fields (Fa, Fb), and Fa is a field common to multiple (source UE to target UE) discovery messages, and there are a total of N (for example, N=3) (source UE to target UE) discovery messages, then receive (Fa, Fb-1, Fb-2, Fb-3) and reassemble the N=3 (source UE to target UE) discovery messages into (Fa, Fb-1), (Fa, Fb-2), (Fa, Fb-3). Note that, as mentioned above, (Fa, Fb-1, Fb-2, Fb-3) is content that can be transmitted in the metadata field of the (UE to UE relay source UE to UE to UE relay) discovery message.

[0140] In another embodiment, the UE-to-UE relay may cache the (source UE to target UE) discovery message for a given time (e.g., a given time configured in a policy). The UE-to-UE relay may store and forward the discovery message. For example, the given time depends on the freshness value / requirement / timing value of the (source UE to target UE) discovery message. For example, if the (source UE to target UE) discovery message contains a b LSB of a UTC-based timer, the UE-to-UE relay may cache / save / store / send / broadcast the (source UE to target UE) discovery message for up to about 2 b time units (if the time unit is 1 second, then up to 2 b seconds). Once this time is up, the UE-to-UE relay may delete the received / stored discovery message and / or request a new discovery message. The action taken (e.g., how long to delete / store the message) may be done based on configuration / policy.

[0141] It is worth noting that this time validity may also be slightly less than 2^b bits, because if the UTC-based timer has b=4LSB of 1111, but the receiving device is slightly out of sync (e.g., 1 second ahead) and the UTC-based timer has b=4LSB of 0000, then there will be a time synchronization problem because the next bits have changed. Therefore, from this point of view, it is safer to consider 2^{b-1} time units for accuracy and time validity.

[0142] To illustrate this, we can describe a possible routine to reconcile counters a and c with slight desynchronization of up to 2^k time units by transmitting 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 also write ABS(a1*2^m–+a0-c–*2^m-c0) = ABS((a1-c1)*2^m-+a0-c0) < 2^k, where a1 and c1 represent the most significant bits of a and c, and a0 and c0 represent the m least significant bits, starting with bit m. For m = k + 1, if abs(a0–c0) > 2^k, then (a1-c1) cannot equal 0, so the most significant bits of the counters are different and also need to be corrected / reconciled. If device A has counter a, and device C has counter c, and device A receives c0 from C, then device A can reconcile its counter to match the one in C by doing the following:

[0143] If ABS(a0–c0)<2^k, A can keep a1 unchanged and replace a0 with the received c0, and therefore, the coordination counter obtained by A is a1|c0, where | indicates cascading.

[0144] · If ABS(a0–c0) >= 2^k, then device A must 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 replace a0 with the received c0, and thus, the coordinated counter is a1'|c0, where | represents concatenation. When the absolute value difference between the counters is 2^k, given the exchange of the m = k + 1 LSBs of one of the counters, this algorithm allows the coordination of the two counter values a and c. Note that this covers a total time range of 2^m time units, because a can be 2^k time units smaller or larger than c. Thus, the maximum time difference that can be corrected is 2^(m - 1), and thus, this is the maximum time validity of the LSB received in a deterministic / error-free manner. Note that, as described in other embodiments (variants), this may require the exchange of the first timing value bound to the data exchanged end-to-end (between terminal UEs), and corresponds to the LSB of a UTC-based counter, which has more bits than the timing value bound to the hop-by-hop communication (between the end UE and the UE-to-UE relay).

[0145] Note that when the time difference between the LSBs is greater than 2^k, the receiving UE A may attempt to replace its own LSB (a0) of its counter with the LSB (c0) received from C. For example, if the LSB of A is a0 = 0x1 (0001) and it receives 0xB (1011), the difference between the values is 0xA, i.e., 1010. However, since the MSB does not overflow, the replacement works fine, and A can still coordinate the counter. This strategy may sometimes work (i.e., this method is probabilistic), and thus, for a received counter with m = k + 1, the receiver can coordinate m bits.

[0146] Note that the above coordination process assumes that the errors of the two devices A and C can be distributed around a central value, and thus, when the time difference reaches 2^k, the coordination process is effective. If m needs to be larger, e.g., 8 bits, and the error between counters a and b is expected to be small, e.g., up to 2^3, then the above process may not be ideal because only a time difference of 2^7 can be corrected. The following alternative counter coordination process solves this problem and requires:

[0147] - Definition of an offset value related to the maximum allowed absolute value. The time error, e.g., offset = 2^3,

[0148] - The sending device C with counter c', adds offset / 2 to c' to get c = c' + offset / 2,

[0149] - The sending device sends the m LSBs of c0, c = c1*2^m + c0,

[0150] - Receiver device A with counter a', adds offset / 2 to a' to get a = a' + offset / 2 = a1*2^m + a0,

[0151] - In this case,

[0152] · If ABS(a0 – c0) < offset, A can keep a1 unchanged and replace a0 with the received c0, and thus, the coordinated counter obtained by A is a1|c0, where | represents concatenation. Finally, A corrects the added offset / 2 value and obtains the corrected counter a1|c0 – offset / 2.

[0153] · If ABS(a0 – c0) >= offset, device A must 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 replace a0 with the received c0. Thus, the coordinated counter is a1'|c0, where | represents concatenation. Finally, A corrects the added offset / 2 value and obtains the corrected counter a”1|c0 – offset / 2.

[0154] - When the absolute difference between the counters is 2^k, the algorithm allows for coordinating two counter values a and c by swapping m LSBs of one of the counters, achieving a time validity of 2^m - 2^k instead of 2^(m - 1). The algorithm requires standardization / agreement on the offset values to be used by A and C.

[0155] In another embodiment variant, two devices communicating with each other have a specified time counter coordination algorithm (e.g., as described above) used by the receiving UE (e.g., UE-to-UE relay) to deterministically align its own time counter with the time counter value of the sensing UE (e.g., an end UE such as the source UE) / coordinate its own time counter with the time counter value of the sensing UE (e.g., an end UE such as the source UE).

[0156] In another embodiment, once the discovery messages are protected according to the procedure in TS 33.503 using the corresponding discovery key parameter DP_UE-to-UE-T (source UE to target UE), the UE-to-UE relay can forward / broadcast each discovery message in the discovery messages.

[0157] - In this case, these (source UE to target UE) discovery protection messages can be sent together or separately. For example:

[0158] · N (source UE to target UE) discovery protection messages can be sent in a single message protected with the DP_UE-to-UE-T discovery key parameter.

[0159] • N (source UE to target UE) discovery protection messages may be sent in N messages protected with the DP_UE to UE-T discovery key parameter.

[0160] - In this case, the first timing value used to protect the (source UE to target UE) discovery message may be greater than the second timing value used to protect the (UE to UE relay to T-UE) discovery information.

[0161] - In this case, both the first timing value and the second timing value need to be sent.

[0162] In another embodiment, the (source UE to target UE) discovery message or the (source UE to UE to UE relay) discovery message, the (UE to UE relay to target UE) discovery message, or the (target UE to UE to UE relay) discovery message, or the (UE to UE to source UE) discovery message may include one or more fields, which may explicitly or implicitly indicate:

[0163] - the number of carried (source UE to target UE) discovery protection messages N,

[0164] - the size of the parameters used (e.g. the size of the timing value),

[0165] - how the messages (fields) are assembled / organized,

[0166] - What protections are applied.

[0167] In another embodiment, instead of using a UTC based counter, a random number is used so that the store and forward function of the UE to UE relay does not present a problem.

[0168] In another embodiment, one or more target (or source) UEs may send one or more discovery protection messages to a UE-to-UE relay before sending the discovery protection message to the source (or target) UE, and the UE-to-UE relay may perform storage and / or aggregation and / or forwarding functions for the discovery message. In this case:

[0169] - The processing of incoming discovery protection messages from the target (or source) UE is similar to that described in the previous embodiments;

[0170] -UE-to-UE relay can aggregate different target (or source) UE messages in a container message over time, for example, at time t1, a first target (or source) UE can send a first message, and at time t2, a second target (or source UE) can send a second message. Fig. 9, wherein the UE-to-UE relay sends a discovery protection message including the first message received at t1, and after receiving the second discovery protection message, the UE-to-UE relay starts sending a new discovery protection message including the first discovery protection message and the second discovery protection message received from the first target (or source) UE and the second target (or source) UE;

[0171] -UE to UE relay can relay / cache messages within the Max_cache_time_period determined by the policy / configuration. In addition, the validity time of the S-UE to T-UE discovery protection message can also be considered, that is, the S-UE-T-UE validity time should ideally always be greater than the maximum cache period (Max_cache_time_period), otherwise, when the S-UE to T-UE validity time expires, the relay of the discovery protection message (inside the container) will be suspended;

[0172] -The UE-to-UE relay may set a timer to track the freshness of the source UE-to-target UE discovery protection message, and upon receiving a new source UE-to-target UE discovery protection message and / or the current source UE-to-target UE discovery protection message in the container expires, concatenate / delete the source UE-to-target UE message from the container discovery message (i.e., UE-to-UE-to-source UE discovery message);

[0173] - The UE-to-UE relay may calculate a new MIC every time the container discovery message is updated.

[0174] In another embodiment, the UE-to-UE relay is configured with a policy that determines how to route / protect end-to-end discovery protection messages between given source UE / target UE, for example, which sets of DP_S-UE-to-UE and / or DP_UE-to-UE-T to use.

[0175] In another embodiment, Figure 7 , 8 The messages shown in and 9 may implicitly or explicitly determine one or more of the following via new / existing message fields:

[0176] -The number of end-to-end discovery protection messages carried / encapsulated / exchanged;

[0177] - The identity of the source UE and / or target UE, so that the UE-to-UE relay can correctly route and / or protect the message.

[0178] The above process requires a third consideration: when the source UE protects the message using DP_S-T bound to the end-to-end communication link between the source UE and the target UE, it is discovered that this first security processing of the message may mean using the first DUCK in the DP_S-T to confidentially protect the message. When the source UE protects the message using DP_S-UE to UE bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay, it is discovered that this second security processing of the message may mean using the second DUCK in the DP_S-UE to UE to confidentially protect the message. These operations may be redundant.

[0179] Therefore, in another embodiment, the source UE and the UE-to-UE relay do not have to be configured with a DUCK in DP_S-UE-to-UE that is bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay.

[0180] Therefore, in another embodiment, the source UE and the UE-to-UE relay must be configured with the following policy: determining that when the DP_S-UE-to-UE bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay is used in the context of the UE-to-UE relay discovery process, the DUCK in the DP_S-UE-to-UE shall not be used for confidentiality protection.

[0181] Therefore, in another alternative embodiment, the policy is configured by a network function (e.g., 5G PKMF) in CN300.

[0182] Therefore, in another alternative embodiment, the source UE and the UE-to-UE relay must be configured with the following policy: determine that when DP_S-UE-to-UE bound to the hop-by-hop communication link between the source UE and the UE-to-UE relay is used in the context of the UE-to-UE relay discovery process, if the DP_S-T includes DUCK, then the DUCK in the DP_S-UE-to-UE shall not be used for confidentiality protection, and it is used to protect the discovery message end-to-end for confidentiality.

[0183] In another embodiment variant that can be combined with other embodiments or used independently, the source UE and the target UE may have a set of discovery keys bound to the ProSe service Y, and those keys are used when the source UE and the target UE communicate directly with each other. The source UE and the target UE that wish to communicate with each other for the same ProSe service Y on a given UE-to-UE relay may use different sets of keys bound to the end-to-end discovery messages between the source UE and the target UE and hop-by-hop security (source UE to UE-to-UE relay, and UE-to-UE relay to target UE). This allows different sets of keys to be used for the same ProSe service, depending on how the source UE and the target UE communicate with each other directly or indirectly. This means that the terminal 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 via a UE-to-UE relay. When one of the terminal UEs (e.g., the source UE) wishes to directly discover another UE (e.g., the target UE) of a given ProSe service, the first terminal UE uses the ProSe service identifier / key for direct discovery. When the terminal UE wishes to discover another UE indirectly, it uses the ProSe service identifier / key to discover indirectly (through the UE-to-UE relay). In the second case, the direct discovery set (related to the ProSe service) can be protected by DUCK1 / DUSK1 / DUIK1, and the discovery message can be protected by DUCK2 / DUSK2 / DUIK2. Depending on whether the UE-to-UE relay can serve more than one ProSe service, some keys may not be configured. For example, if the relay only serves a single ProSe service, DUCK1, DUSK1, DUIK1 may not be available, and the protection depends only on DUCK2 / DUSK2 / DUIK2. In this embodiment, when the terminal UE (e.g., source UE / target UE) sends a discovery message for a given ProSe service, the terminal UE can select the ProSe service ID and discovery key parameters according to whether the discovery message reaches the other end UE directly (direct discovery) or indirectly (UE-to-UE discovery). This can be determined by policy. The policy can be configured by the core network, for example, when providing / configuring the discovery key parameters.

[0184] In another embodiment similar to the other embodiments for integrated discovery and which can be used in combination with the other embodiments or independently, a source UE and a target UE that wish to communicate with each other through a given UE-to-UE relay or directly for ProSe service Y may use a set of keys bound to end-to-end discovery messages between the source UE and the target UE and a set of keys bound to hop-by-hop security (source UE / target UE to UE-to-UE relay). Since the discovery message sent by the source UE may reach the target UE directly or indirectly, it makes sense that:

[0185] - the discovery message indicates whether it is a first-hop (source UE to UE-to-UE relay) or a second-hop (UE-to-UE relay to target UE) message,

[0186] - The indication may be protected by end-to-end discovery key parameters and / or hop-by-hop discovery key parameters.

[0187] - The direct discovery set is not encrypted with the help of the discovery key parameters related to hop-by-hop security. This allows the target UE to directly access the protected direct discovery set, thus saving computing resources.

[0188] In particular, if the target UE determines that the discovery message reaches it directly, the target UE may ignore the protection related to hop-by-hop security protection (e.g., MIC calculated using the discovery key parameter related to the relay service) and only process the direct discovery set securely with the end-to-end discovery key parameter related to the ProSe service. The target UE may determine this based on some fields in the discovery message (e.g., L2 address or relay indication).

[0189] The above process requires a fourth consideration, namely that having two discovery keying parameter sets, such as DP_S-T and DP_S-UE, increases the configuration complexity to the UE.

[0190] Therefore, in another embodiment, the source UE is required to use DUIK and DUCK DP_S-T, and then use DUIK and DUSKDP_S-UE to UE. This can be done by requiring one or more of the following actions at the sending source UE:

[0191] Step 1 in clause 6.1.3.4.3.2 of TS 33.303 is not modified;

[0192] Step 2 of calculating the first MIC in clause 6.1.3.4.3.2 of TS 33.303 using DUIK DP_S-T as defined in clause 6.1.3.2.3 of TS 33.503;

[0193] Step 3 of clause 6.1.3.4.3.2 of TS 33.303 to add message confidentiality using DUCK in DP_S-T as defined in clause 6.1.3.2.3 of TS 33.503;

[0194] Step 4 of calculating the second MIC in clause 6.1.3.4.3.2 of TS 33.303 using the DUIK in DP_S-UE to UE as defined in clause 6.1.3.2.3 of TS 33.503; and

[0195] Step 5 of clause 6.1.3.4.3.2 in TS 33.303 by scrambling the message using DUSK in DP_S-UE to UE as defined in clause 6.1.3.2.3 in TS 33.503.

[0196] Therefore, in another alternative embodiment, the target UE performs the inverse actions of the above steps.

[0197] Therefore, in another embodiment, the UE-to-UE relay performs only the inverse actions associated with steps 5 and 4; and re-executes those actions using the second hop-by-hop discovery key parameters as:

[0198] Step 4 of calculating the second MIC using the DUIK in DP_UE to UE-T as defined in clause 6.1.3.2.3 of TS 33.503 in clause 6.1.3.4.3.2 of TS 33.303; and

[0199] Step 5 of clause 6.1.3.4.3.2 of TS 33.303 to scramble the message by using DUSK in DP_UE to UE-T as defined in clause 6.1.3.2.3 of TS 33.503.

[0200] In particular, step 4 may be optional.

[0201] In some options, it may be desirable to reuse the security routines in clause 6.1.3.4.3 of TS 33.303 and clause 6.1.3.2.3 of TS 33.503 to protect the direct discovery set (as a discovery message) and use the same security routines to protect the UE-to-UE discovery message (including the direct discovery protection set). However, when protecting the direct discovery set, it may not need to be protected as a discovery message, for example, it may not need to include a header, so that some steps in those clauses can be skipped, as shown in the previous process.

[0202] In a variation, steps of the security routine are reorganized / removed (e.g., as in the above process) to avoid calling the overall security routine (clause 6.1.3.2.3 of TS 33.503) twice, once to protect the direct discovery set as a direct discovery protection message, and once to protect UE-to-UE discovery messages (including direct discovery protected messages) to generate UE-to-UE discovery protection messages.

[0203] In a variant, step 1 in 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 discovery set, for example, as explained in the previous embodiment.

[0204] In a variant, step 5 in 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 discovery set, for example, as explained in the previous embodiment.

[0205] In some options, UE-to-UE discovery messages may transmit certain fields, the protection of which may depend on the application. It may be advantageous to let the application protect or not protect these fields, for example, to allow a passive eavesdropper to identify the message or for legitimate eavesdropping reasons. However, the routines in clause 6.1.3.2.3 of TS 33.503 protect most of the messages identified in A7 of TS 33.503, including:

[0206] KEYSTREAM=output_keystream AND(Encrypted_bits_mask||0xFF..FF)

[0207] =output_keystream AND(Encrypted_bits_mask||EBM')

[0208] Therefore, in a variant, A.7 in TS33.503 is modified to replace EBM'=0xFF..FF with a bit string such that it sets to 0 those bits that do not need to be protected (eg, bits corresponding to UserInfoID).

[0209] In an additional embodiment, assuming that the direct discovery set is not a discovery message but is protected to 1, the LENGTH parameter for discovery defined in A.7 of TS 33.503 in the message-specific confidentiality mechanism may need to be changed to LENGTH: LEN(discovery message)-(LEN(UTC-based counter LSB)+LEN(MIC)), where LEN(x) is the length of x in number of bits, and thus LEN(message type) is discarded because it is not applicable to the direct discovery set.

[0210] For some situations, the above embodiments may require further consideration. The relayed discovery message may include multiple fields, including, for example, the type of discovery message, a counter, a MIC, discoverer information (i.e., relay user information ID), an RSC, a relay indication (to indicate ProSe direct discovery forwarding), an original discoverer information (i.e., the source 5G ProSe U2U UE user information ID), an NCGI or an E2E discovery information. According to TS24.554, the aggregation length may be greater than 32 bytes, and therefore, the scrambling process in TS 33.503 may not be sufficient because it is limited to 32 bytes. To address this issue, the method capable of protecting more than 32 bytes as described above may be applicable to the scrambling of UE-to-UE relay messages.

[0211] For some situations, the above embodiments may require further consideration, namely, it may be advantageous to have end-to-end security (i.e., from source UE to target UE) for some security attributes (e.g., confidentiality or integrity), but to have 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 attributes (e.g., integrity or confidentiality).

[0212] Therefore, in a related embodiment, the discovery message may be protected for confidentiality using a key associated with DP_S-T, and the discovery message may be protected for integrity using keys associated with DP_UE to UE-T and DP_S-UE to UE.

[0213] Thus, in a related embodiment, the device is configured with a policy that determines which keys for which discovery parameters are used to protect discovery messages sent via UE-to-UE relays.

[0214] Thus, in a related embodiment, a device is configured with a policy that determines which keys for which discovery parameters are used to protect discovery messages sent on a UE-to-UE relay when the security routines in TS 33.503 are applied using end-to-end discovery parameter sets and hop-by-hop discovery parameter sets.

[0215] Thus, in a related embodiment, the device is configured with policies that determine how end-to-end and hop-by-hop messages are protected, such as which keys are used for, for example, hop-by-hop or end-to-end confidentiality, whether to use a single MIC or two MICs, in which messages, and whether to reuse a single counter value for end-to-end messages or transmit two counter values, etc.

[0216] In related embodiment variants, the policy / configuration may also relate to the UTC-based counter, e.g., its precision, 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 / descrambling, etc.

[0217] In another embodiment, the UE-to-UE relay may be configured with a policy such that the UE-to-UE relay is only configured to receive and forward protected discovery messages without decrypting or calculating the MIC. This has the advantage of reducing computational resource consumption at the UE-to-UE relay.

[0218] -In a variation of this embodiment, if the source UE and the target UE and the UE-to-UE relay share the same discovery parameters DP_S-UE-to-UE and DP_UE-to-UE-T. In this case, the discovery message sent by the source UE may contain, for example, two MICs, a second MIC calculated using DP_S-UE-to-UE and a first MIC calculated using DP_S-T. Upon receiving the discovery message, the UE-to-UE relay will check whether the second MIC can be successfully verified given the received message and the received UTC-based counter. The UE-to-UE relay may only forward the message if the second MIC verification is successful. The UE-to-UE relay may also store the message for a period of time and forward the message at a later point in time, for example, as long as the second MIC verification is successful. This is particularly applicable to using the same UTC-based counter to calculate both the first MIC and the second MIC.

[0219] - In a variation of this embodiment, given the received message and the received UTC-based counter, if the UE-to-UE relay successfully verifies the second MIC, the UE-to-UE relay may forward the message without the second MIC, i.e., using only the first MIC calculated by the DP_S-T relay. The UE-to-UE relay may also store the message for a period of time and forward the message at a later point in time, for example, as long as the second MIC verification succeeds.

[0220] In another embodiment, the UE-to-UE relay may be configured to receive the discovery message and 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 if successful, determine the entire UTC-based counter. The UE-to-UE relay may then be allowed to forward the message as long as the time window permits. The time window may be policy-based, or may be based on a parameter included in the received discovery message itself (a time window parameter). The time window may be an absolute value or relative to a UTC-based counter used to verify the freshness of the second MIC, for example, it may indicate an offset. The time window may determine how long the first MIC (calculated with DP_S-T) may be correctly verified given the UTC-based counter associated with it.

[0221] In a scenario, a UE-to-UE relay may receive a UE-to-UE discovery message bound to RSC1 according to, for example, model A, as described in the previous embodiment, the UE-to-UE relay may extract the protected end-to-end discovery message (protected direct discovery set) and store it as long as the protected end-to-end discovery message (protected direct discovery set) is valid. The UE-to-UE relay may then send the protected end-to-end discovery message to the target UE in the UE-to-UE discovery message by using RSC2. RSC1 and RSC2 are bound to discovery key material. RSC1 and RSC2 are bound to a security indicator that determines whether the PC5 security process is network assisted or not. When the UE-to-UE relay receives a UE-to-UE discovery message bound to RSC1, the UE-to-UE relay may be able to match RSC1 because the UE-to-UE relay may be in coverage (or out of coverage) and RSC1 is bound to a PC5 security process with (or without) network assistance. However, after storing the protected direct discovery set and when preparing to send a UE-to-UE discovery message, the coverage state of the UE-to-UE relay may have changed. Therefore, a method is needed to determine which RSC will be used in the discovery process and how to notify the end UE. To this end, the following embodiments may be applicable:

[0222] In another embodiment variant, the UE-to-UE relay may be adapted or configured (e.g., with a policy) to store the RSC (and a corresponding indication of the type of PC5 security procedure to which it is bound) alongside the end-to-end protected discovery message / direct discovery set, and wherein the UE-to-UE relay may be configured with a policy to use the same RSC when sending subsequent discovery messages to the target UE, and thus indicate the same type of PC5 security procedure to be used. This further means that the UE-to-UE relay may not forward / send certain direct discovery sets that were previously matched even if they no longer satisfy the network coverage situation of the UE-to-UE relay.

[0223] In another embodiment variant, the UE-to-UE relay can be adapted or configured (e.g., with a policy) to check its coverage status before it relays a discovery message (announcement discovery message in model A / request discovery message in model B) to the target UE, such that if the coverage status of the UE-to-UE relay has changed from the time point of receiving the discovery message (e.g., moved from in-coverage to out-of-coverage or otherwise), a different RSC (e.g., RSC2) associated with the security procedure corresponding to the new coverage status 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.

[0224] In another embodiment variant, if the coverage state of a UE-to-UE relay changes between the time it receives a discovery message from a source UE and the time it relays the discovery message to a target UE, and the UE-to-UE relay selects an RSC for the relayed discovery message, e.g., RSC2, which is associated with a security procedure different from a security procedure associated with an RSC (RSC1) included in the discovery message received from the source UE, the UE-to-UE relay may indicate to the source UE a mismatch between the security procedure to be used and / or the reason (e.g., a change in coverage state).

[0225] In another embodiment variant, a change in the coverage status of a UE-to-UE relay may affect its decision on whether to accept a discovery message. For example, a UE-to-UE relay may be out of coverage and receive a discovery message that includes an RSC1 bound to a PC5 security procedure with network assistance. Even though the UE-to-UE relay may not be able to process it upon receipt, the UE-to-UE relay must store the protected end-to-end discovery message / direct discovery set alongside the RSC1 with the validity time. The UE-to-UE relay can then check its coverage status when sending a UE-to-UE discovery message and then decide whether the message matches, and therefore whether to send it.

[0226] In another embodiment variant, a change in the coverage state of a UE-to-UE relay may affect its decision to relay discovery messages (announce discovery messages in model A / request discovery messages in model B) and cause it to discard discovery messages, for example, if the UE-to-UE relay is not provided with an RSC and / or long-term credentials corresponding to its new coverage state (for example, if out of coverage). In certain scenarios, an out-of-coverage UE (e.g., a UE-to-UE relay) may be able to estimate / predict when and where it may move into 3GPP coverage based on timing and location information of a mobile access device (such as a vehicle-mounted relay or a satellite portion of a non-terrestrial network or a base station mounted on a UAV). The timing and location information may be deployed to the device, for example, according to one of the conclusions in TR 23.700-05 related to KI#7, the information (e.g., duration and location information) may be deployed together with the CAG identifier of a mobile base station relay (MBSR) accessible to the UE. Similarly, according to clause 7.3.1.6 of TR 38.821, ephemeris information and UE location information can be used to help the UE perform measurements and cell selection / reselection. Considering the ability of the UE to estimate when and / or where it can enter 3GPP coverage, the following embodiments can be considered:

[0227] In one embodiment variant, an out-of-coverage UE-to-UE relay or UE-to-network relay may determine, based on the above estimation, whether to cache a message, such as a discovery message including an RSC associated with a security procedure with network assistance or a DCR message including an RSC requiring network assistance to establish a PC5 security link, based on its validity time and the estimated time to enter coverage before sending the message to, for example, a target UE or network.

[0228] In one embodiment variant, a UE-to-UE relay in or out of coverage can determine whether to relay / discard a message, such as a discovery message, based on the above-mentioned estimation, based on whether the security procedure or operation indicated in the message (for example, indicated by the RSC included in one or more discovery messages) is supported at the time when the UE (terminal UE and UE-to-UE relay) initiates the PC5 link establishment procedure through direct communication.

[0229] In one embodiment variant, a UE-to-UE relay in or out of coverage may announce (e.g., via a discovery announcement message) its coverage schedule based on the aforementioned estimation, so that the terminal UE may select RSC and subsequent security procedures supported by the UE-to-UE relay when the PC5 link establishment procedure occurs.

[0230] In a more general definition of this embodiment, a method is described by which a second device receives a discovery message from a first device, wherein the discovery message includes a relay service code associated with an indication of a type of security procedure to be used during PC5 secure link establishment, wherein the second device evaluates whether to relay the discovery message to a third device, and if so, which type of RSC to use, based on the following factors:

[0231] - whether the coverage state of the second device changes between the time it receives the discovery message from the first device and the time it prepares to send the relayed discovery message to the third device, or

[0232] - whether the second device is (pre-)configured with a policy to maintain the same security procedures indicated by the first device via the relay service code, and to discard the discovery message if a change in coverage status requires a change in the security procedures used, or

[0233] - whether the second device is (pre-)configured with a policy to cause the RSC to adapt or select its coverage state so that, if necessary, an RSC supporting different security procedures is selected for the second hop-by-hop link, thereby also notifying the first device of changes in coverage state and, therefore, of the security procedures to be performed, or

[0234] - Whether the second device is (pre-)configured with a policy that enables the device to store the discovery message as long as it is still valid and to check support for the relay service code to be used and the subsequent security procedures when relaying discovery message transmissions.

[0235] Regarding the Model A discovery process, it aims to ensure that the relay discovery notification message is transmitted in time by the relay when transmitting the protected direct discovery set from the notifying UE to the monitoring UE. This can assume the following two situations:

[0236] Scenario 1 (reference Fig.12 ): The terminal UE is discoverable by actively sending an announcement message. The UE-to-UE relay (1202) provides the terminal UE (1201 and 1203) with timing information about its next announcement to ensure real-time transmission of the protected direct discovery set within the proximity relay announcement message. Fig.12 The steps of the process described in are as follows: Step 1210: The UE-to-UE relay may decide to publish relay announcement timing information based on the indication that the RSC supports protection of each direct discovery set. An example of timing information is a time window when the relay expects to receive a notification from the terminal UE in order to notify the terminal UE via the next relay notification.

[0237] Step 1211: The UE-to-UE relay may send a UE-to-UE relay protection discovery message including an RSC, a UE-to-UE relay user information ID, and notification timing information.

[0238] Step 1212: 1201 (notifying UE) schedules the next notification message that may include the protected direct discovery set based on the received published relay notification timing information (e.g., ensuring timely transmission within the published time window). 1203 (monitoring UE) aligns its listening to relay notification messages based on the received published relay notification timing information.

[0239] 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 .

[0240] Step 1214: 1202 verifies that the notification message from 1201 is received within an acceptable time based on the published relay notification timing information. If it does not meet the published relay notification timing information (e.g., the external time window), 1202 can discard the notification message from the node terminal 1201.

[0241] Step 1215: 1202 sends a protected UE-to-UE relay protection (announcement) discovery message to 1201 according to the published announcement timing information, the message including RSC, UE-to-UE relay user information ID, and the protected direct discovery set received from 1201. 1203 (monitoring UE) receives the relay announcement at a time aligned with the announcement timing information published by the relay, and discovers the existence of terminal UE#1 after successfully processing the relay discovery message and the included protected direct discovery set of 1201.

[0242] Although in this first scenario, UE-to-UE relay attempts to ensure that the discovery notification message is relayed from the notifying UE to the monitoring UE in a timely manner, it does not necessarily guarantee the freshness of the direct discovery set. For example, although the timer based on the discovery message UTC can be bound by a time window, thereby ensuring the MIC validity, the UTC-based counter used to calculate the direct discovery set MIC may be exhausted before the discovery notification message reaches the monitoring UE. In this case, the monitoring UE will discard the discovery notification message. In addition, the method described in this scenario does not include a verification step at the end of the monitoring UE. Therefore, another object of the present invention is to solve these problems.

[0243] In one embodiment, the announcement timing information may refer to a time window, or the number of least significant bits to be considered as a timing value for calculating the MIC on the discovery message, or the time a message may remain fresh, or the time a message may be cached by the relay. Thus, these parameters are provided by the relay (e.g., based on local policy) rather than being configured by the NF in the CN as in other embodiments.

[0244] In another embodiment, the UE-to-UE relay does not broadcast its timing information, but the timing information of the UE-to-UE relay (typically, the timing information associated with the RSC) is configured by the CN.

[0245] In an embodiment that can be combined with other embodiments, the terminal UE (notification and monitoring UE) may be configured with a policy / indicator that determines the difference in accuracy (e.g., the number of LSBs of a UTC-based counter) between the timing value announced by the UE-to-UE relay and the timing value used to calculate the MIC on the direct discovery set. The latter may not be as accurate as the timing value announced by the UE-to-UE relay to ensure that the direct discovery set remains valid when it is relayed. For example, the least significant bit of the end-to-end timing value may have an accuracy of 2 seconds, and the least significant bit of the hop-by-hop timing value may have an accuracy of 1 second. Additionally or alternatively, the end-to-end timing value may be longer than the hop-by-hop timing value, for example, the end-to-end timing value may be 8 LSBs of a UTC-based counter, and the hop-by-hop timing value may be 4 LSBs of a UTC-based counter. This has the advantage of allowing the UE-to-UE relay to cache messages when needed and still ensure the validity of the direct discovery set MIC.

[0246] In an embodiment that may be combined with other embodiments, the terminal UE (notifying and monitoring UE) may be configured with a policy that determines the number of required LSBs of the UTC-based counter to be transmitted to ensure that the message can be verified by the other end UE taking into account the timing parameters of the UE-to-UE relay. For example, if the relay sends a message every deltaT seconds, the terminal UE may send a message including more than log2(deltaT) bits so that the exact transmission time can be successfully corrected by other UEs (e.g., monitoring UEs).

[0247] In another embodiment, after receiving the relay discovery notification message, the monitoring UE verifies whether the notification message is received according to the published notification timing information, cancels the confidentiality / privacy protection if applied, and completes the notification message. Then, the monitoring UE verifies whether the direct discovery set is still valid according to the UTC-based counter, the configured timing value accuracy, and whether the MIC is still valid.

[0248] Scenario 2 (reference Fig.13 ): The terminal UE is discoverable while already connected (and not necessarily advertised) to the relay. The relay (1302) obtains the protected direct discovery set from the connected terminal UE (1301) on demand to ensure that the protected direct discovery set in the relay advertisement message is transmitted to the monitoring UE (1303) in near real time. Fig.13 The steps of the procedure described in are as follows:

[0249] Step 1310: If the RSC is configured with an indicator for each direct discovery set protection and the ProSe service requires restricted discovery (i.e., the terminal UE is provided with the corresponding direct discovery set security material), the announcing end UE (1301) may send the ProSe restricted code in a DCR message to the UE-to-UE relay (1302) with the RSC. The relay verifies that the RSC supports each direct discovery set protection and stores the ProSe restricted code in the PC5 unicast link context.

[0250] Step 1311: The UE-to-UE relay (1302) decides to notify the connected UEs.

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

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

[0253] 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 RSC, UE-to-UE relay user information ID, and the protected direct discovery set received from 1301. 1303 (monitoring UE) processes the relay discovery message security and the security of the included protected direct discovery set to discover 1301.

[0254] The method assumes that a PC5 secure link has been established between the UE-to-UE relay and the announcing UE, where the UE-to-UE relay triggers the transmission of a discovery announcement message from the announcing UE by sending a PC5-S request (i.e., announcing and UE-to-UE relay) containing a ProSe restricted code obtained during the direct link establishment between the two UEs. The potential disadvantages of this method are similar to the first scenario, and there is no guarantee that the direct discovery set remains valid when the discovery announcement message is delivered to the monitoring UE. Another disadvantage is that the announcing UE depends on the UE-to-UE decision when to distribute the discovery message (step 3 above). Therefore, the subject of the following embodiments is to address it.

[0255] In an embodiment, the method may be further improved by incorporating aspects of the first scenario (i.e., timing information) into the process. For example, the UE-to-UE relay may publish the next announcement timing information in the PC5-S request in step 3 or separately (e.g., similar to step 1 in scenario 1). The announcing UE then sends a PC5-S response (similar to step 4), where the UE-to-UE relay performs compliance with the timing check before relaying the direct discovery set in step 5 to the monitoring UE. When received by the monitoring UE, another compliance with the timing check is performed before canceling the confidentiality / privacy protection of the protected direct discovery set and verifying its integrity.

[0256] In another embodiment variant, the UE-to-UE relay may publish in the announcement timing information (e.g., the time window to be considered or the number of UTC-counter LSBs) to be used by the announcing UE when calculating the directed discovery set MIC. The monitoring UE verifies that the directed discovery set is still valid based on the UTC-based counter, the timing value announced by the UE-to-UE relay, and whether the MIC is still valid.

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

[0258] In an embodiment that can be used independently, the notifying UE is the UE that transmits its transmission schedule (e.g., timing information, such as in step 1 or step 4 or in the discovery message itself) to the UE-to-UE relay. This ensures that the UE-to-UE relay has and / or can prepare for relay operations (e.g., by reserving resources). This also ensures that the service (relay) provided by the UE-to-UE relay meets the needs of the notifying UE (e.g., timing). In this embodiment, after receiving the timing information of the notifying UE, the UE-to-UE relay can confirm or reject or request modification:

[0259] - If confirmed, the announcing UE may then continue with the announcing message (eg, step 4 above or as in other embodiments).

[0260] - If rejected, the UE is informed that it can retry or search for a different UE-to-UE relay,

[0261] - UE-to-UE may request modification of timing parameters if modification is required. The modification may depend on other notifications connected to the UE-to-UE relay for example.

[0262] In an embodiment variant similar to the previous variant, the advertising UE and the UE-to-UE relay may agree that:

[0263] - Notification UE can send notification message (discovery message) by itself (e.g., step 4 above), and / or

[0264] - Notify that the UE must wait for an indication from the UE-to-UE relay (step 3 above).

[0265] The above embodiment variations may be combined with each other or used together.

[0266] According to the draft CR of TS 33.503 in TDoc S3-233374, clause 6.1.3.3.3.1, step 2, the UE-to-UE relay may receive a UE-to-UE discovery message containing a protected direct discovery set from a terminal UE (e.g., announcing UE, discoverer UE), and / or receive a protected direct discovery set from an already connected terminal UE (e.g., announcing UE, discoverer UE). The UE-to-UE relay is able to integrity verify the message protected with DP_S-UE-to-UE, i.e., the discovery key shared and used between the terminal UE and the UE-to-UE relay. This integrity verification uses a UTC-based timer associated with / used with these keys. However, this UTC-based timer may be different from the UTC-based timer associated with the protected direct discovery set (e.g., because the direct discovery set is protected before (i.e., first) the 5G ProSe UE-to-UE relay discovery or communication message. This may lead to a situation where the UE-to-UE relay needs to decide what the validity of the protected discovery set is. This can be addressed by different embodiment variants:

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

[0268] In an embodiment variant, the UE-to-UE relay may use the time of the LSB of the UTC-based timer included in the direct discovery set to determine the validity time. This may be a - even if the UE-to-UE relay cannot verify it directly.

[0269] According to the draft TS 33.503, clause 6.1.3.3.3.1, step 2 in TDoc S3-233374, the UE-to-UE relay - may - include a list of valid protected direct discovery sets in the notification message when broadcasting the notification message, and use the discovery security material associated with the RSC as specified in clause 6.1.3.2.3 of TS 33.503 to protect the notification message. Then, the 5G ProSe UE-to-UE relay sends the notification message. However, this may result in the loss of some received direct discovery sets. To address this issue, in an embodiment variant, the UE-to-UE relay may have a policy that allows the direct discovery sets to be stored as long as the direct discovery sets remain valid and a given condition applies, such as any of them is about to expire (e.g., expiration time-difference). When any direct discovery set is about to expire, the UE-to-UE relay includes the received list of protected direct discovery sets in the notification message, and uses the discovery security material associated with the RSC to protect the notification message, and then broadcasts the notification message. This embodiment is advantageous because it limits / reduces the number of discarded messages.

[0270] In an embodiment variant, the UE-to-UE relay may be provided with a policy or configured to broadcast a notification message containing a direct discovery set periodically or based on direct discovery set validity, so that the notification message is broadcast regardless of which condition is met first. This has the following advantages: the number of expired direct discovery sets and the number of direct discovery sets to be included in the notification message is reduced to the terminal UE having more opportunities to receive one or more direct discovery sets and establish a communication link.

[0271] When one or more monitoring UEs receive a discovery announcement message broadcast by a UE-to-UE relay containing a direct discovery set, it descrambles and / or decrypts and / or integrity verifies the discovery announcement message, and if successful, the monitoring UE extracts the direct discovery set from the discovery announcement message and then verifies the direct discovery set. Since the direct discovery set is protected as specified in clause 6.1.3.2.3 of TS33.503, the order of security operations is: integrity protection, confidentiality protection, and final scrambling, therefore, in order to verify the direct discovery set, the monitoring UE performs verification in the reverse order (i.e., descrambling, decryption, and final integrity verification). Furthermore, in contrast to the restricted direct discovery scenario, where the ProSe restricted code is included in the discovery message and matched based on the discovery filter in step 2 of clause 6.1.3.4.3.3 of TS 33.303, in the UE-to-UE relay discovery scenario, Tables 10.2.1.12, 10.2.1.13 and 10.2.1.14 in TS 24.554 describe the contents of the UE-to-UE relay discovery announcement, request and response messages, respectively, and the contents of the UE-to-UE relay discovery messages defined in TS 23.304 (e.g., Model B discovery in clause 6.3.2.4.3) do not specify / include the ProSe restricted / application code as an element of the end-to-end direct discovery set. ). Therefore, the monitoring UE has to verify each and every direct discovery set, as it cannot distinguish between one or more direct discovery sets intended for it, which increases the risk that one / some direct discovery sets may become invalid when the monitoring UE attempts to verify. In addition, canceling the confidentiality of a specific message is computationally intensive, so the confidentiality of each direct discovery set must be canceled, and it will be very resource intensive to repeatedly cancel the confidentiality for each received announcement discovery message. To address these issues, the following embodiments are proposed:

[0272] In one embodiment, the order of security operations can be reorganized as: confidentiality protection, integrity protection, and final encryption, so that if (one or more) direct discovery sets are encrypted, the monitoring UE can first descramble and verify the integrity of the message, discard (one or more) non-valid direct discovery sets, and then cancel confidentiality.

[0273] In an embodiment variant, the MIC of the direct discovery set may not require scrambling protection, so the monitoring UE will have direct access to the MIC and can first verify the validity of the direct discovery set, then perform descrambling (if applicable), and finally remove confidentiality protection. Note that the MIC of the direct discovery set is protected by UE-to-UE relay as part of the discovery announcement message.

[0274] In an embodiment intended to assist (one or more) monitoring UEs in distinguishing between (one or more) direct discovery sets intended for it / them and (one or more) direct discovery sets not intended for it / them, (one or more) announcing end UEs may include ProSe restricted codes in (one or more) direct discovery sets. The ProSe restricted code may not be protected by confidentiality, but is only scrambled (e.g., at the end) to enable the monitoring end UE to quickly access it. This has the advantage of enabling the monitoring UE to determine whether the direct discovery set is intended for it without having to revoke confidentiality protection.

[0275] In another embodiment, if the advertising end UE includes the ProSe restricted code in the direct discovery set and applies scrambling last, when extracting the direct discovery set, the monitoring UE can first descramble and match the ProSe restricted code, and discard the direct discovery set that is not intended for it, perform integrity verification, and finally cancel confidentiality protection. This has the advantage of reducing the number of direct discovery sets to only one or more intended for monitoring UEs, and also saves resources because fewer MIC checks and confidentiality checks are performed.

[0276] In one embodiment, to enable ProSe restricted code addition without encrypting it, the LENGTH parameter for the discovery message-specific confidentiality mechanism described in A.7 in TS 33.503 can be changed to: LENGTH: LEN(discovery message)-(LEN(ProSe restricted code)+LEN(UTC-based counter LSB)+LEN(MIC)), where LEN(x) is the length of x in bits.

[0277] In the above embodiment (variant), the strategy can be configured by an entity in the 5G CN to discover parameters, such as security keys such as DUIK, DUSK, DUCK, etc.

[0278] Some of the processing steps in the above description can be done from the perspective of, for example, a sending or receiving device. If the processing of a peer (e.g., a receiving device or a sending device) is not described, it must be understood to be complementary. For example, if a sending device is configured with a policy that does not use a key for a given purpose in some cases, the receiving device also needs to have the same policy configuration that does not use it. The flexibility provided by this policy is advantageous because it allows the security / performance level to be adjusted depending on the communication situation.

[0279] In an embodiment that may be combined with or used independently of other embodiments, during discovery, if the UE-to-UE relay is able to identify a terminal UE with which a secure link has already been established (e.g., through a previous connection with the terminal UE), the UE-to-UE relay may reuse the security context (e.g., key material) to protect discovery messages from (one or more) other terminal UE relays to the terminal UE with which the security context has already been established.

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

[0281] In an embodiment variant, where two security material sets are used and the direct discovery set is integrity protected only, the UE-to-UE relay may be able to identify the terminal UE (eg, the target UE).

[0282] In another embodiment, if the user information ID of the target UE is long enough, the terminal UE (e.g., source UE) may calculate a pseudonym (PID) based on the user information ID of the target UE (e.g., PID=Hash(user information ID of the target UE)) as, for example, a one-way function (e.g., a cryptographic function), and include it in, for example, a UE-to-UE discovery set. The UE-to-UE relay may attempt to identify whether a security context has been established with the target UE by comparing the pseudonym received by the source UE with the PID calculated using the target UE user information ID of the UE with which it has an established security link.

[0283] In an embodiment variant, the source UE may add the salt / random number as a parameter to the function used to calculate the PID, e.g., PID=Hash(salt, target UE's user information ID) to avoid dictionary attacks. The salt / random value may be confidentiality protected and sent as part of the UE-to-UE discovery set.

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

[0285] In one embodiment, where applicable, if the UE-to-UE relay has or obtains an identifier of the terminal UE (e.g., a user information ID or a destination layer 2 ID), it may perform a check based on a policy provided to the UE-to-UE relay to determine whether a secure link has already been established with the terminal UE, and if a secure link has already been established, it may be reused to protect messages (e.g., discovery messages and / or direct communication messages) intended for the terminal UE with which a security context has been established. This has the advantage of providing privacy / integrity protection independent of the ProSe service being used and optimizing secure link establishment (e.g., skipping new key establishment and direct authentication and security mode command procedures).

[0286] After the discovery phase, the UE (i.e., the terminal UE and the UE-to-UE relay) can establish a secure PC5 communication link with the assistance of the network by reusing the security procedures defined in clause 6.3.5 of TS 33.503 (according to clause 6.6.3.1 in the draft in Tdoc S3-233374) by replacing the remote UE by the source UE and the UE-to-UE relay in the first hop and replacing the remote UE by the target UE and the UE-to-UE 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 contain the PRUK-ID), so it is unclear how to protect the DCR message. Therefore, the following embodiments:

[0287] In one embodiment, the same security procedures are applied to protect the DCR messages in clause 6.3.5 in TS 33.503 to protect DCR messages between a source UE and a UE-to-UE relay, and to protect DCR messages from a UE-to-UE relay to a target UE. This has the advantage of reducing code complexity, as the same routine 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, the UE-to-UE relay sets the PRUK-ID field to a predefined value (e.g., all zeros) instead of the PRUK-ID of the source UE when sending the DCR message to the target UE. The target UE processes the incoming message according to clause 6.3.5 in TS 33.503 and ignores the PRUK-ID field.

[0288] In an embodiment variant, if the UE-to-UE relay sets the PRUK-ID to a predefined value (eg all zeros), upon receiving the DCR message, the target UE removes protection and verifies whether the PRUK-ID is set to said predefined value.

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

[0290] In an embodiment variant, the UE-to-UE relay removes the PRUK-ID field of the received DCR message as received from the source UE, since it is not needed in the DCR message from the UE-to-UE relay to the target UE, and reuses the security routine in clause 6.3.5 of TS 33.503. Since this security routine implies confidentiality protection for more RSC and PRUK-ID, the resulting protected DCR message exchanged between the UE-to-UE relay and the target UE protects some additional fields that are normally not protected. This embodiment variant is advantageous because a single security routine (according to clause 6.3.5 in TS 33.503) is needed to handle different types of DCR messages.

[0291] In such a general definition, methods and apparatus are described that may be implemented in a first device for securely protecting a discovery message by using a first set of keys and a second set of keys and optionally using a policy and sending a second protected discovery message, wherein the first device:

[0292] protecting the discovery message based on the first set of keys and the policy for deriving the first discovery protected message, and

[0293] protecting the first discovery protected message based on the second set of keys and the policy for deriving the second discovery protected message, and

[0294] A second discovery protected message is sent.

[0295] The above first discovery protected message may also be referred to as a first protected discovery message.

[0296] In general, methods and apparatus are described that may be implemented in a third device for securely receiving and securely processing (which may include integrity verification and / or descrambling and / or decrypting) a third protected discovery message using a first key set and a third key set and optionally using a policy, wherein the third device:

[0297] receiving a third protected discovery message, and

[0298] securely processing the third protected discovery message based on the third key set and the policy from which the first protected discovery message was derived, and

[0299] The first protected discovery message is securely processed based on the first set of keys and a policy for deriving discovery messages.

[0300] In a more general definition of this embodiment, a method and apparatus are proposed that can be implemented in a second device for securely receiving and securely processing (which may include integrity verification and / or descrambling and / or decryption) a second protected discovery message by using a second key set and, optionally, a strategy for obtaining a first protected discovery message.

[0301] And securely processing (which may include integrity protection and / or scrambling and / or encryption) the first protected message by using a third set of keys and optionally a policy and securely sending a third protected discovery message.

[0302] The third device:

[0303] receiving a second protected discovery message, and

[0304] securely processing the second protected discovery message based on the second set of keys and the policy from which the first protected discovery message was derived, and

[0305] securely processing the first protected discovery message based on the third set of keys and the policy for deriving a third protected discovery message; and

[0306] The third protected message is sent.

[0307] In this defined option, methods and apparatus are proposed which may be implemented on a first device for receiving a first key set and a second key set and optionally a policy from a fourth device.

[0308] In another option of this definition, methods and apparatus are described above that may be implemented on a second device for receiving a second key set and a third key set and optionally a policy from a fourth device.

[0309] In yet another option of this definition, methods and apparatus for receiving the first key set and the third key set, and optionally the policy, from a fourth device are described above and may be implemented on a third device.

[0310] In yet another option of this definition, methods and apparatus are described above in which it may be required that the first key set (or / and the third key set) does not include a scrambling key.

[0311] In yet another option of this definition, a method and apparatus are described above wherein a policy requires that if a discovery process of a third device is performed on a second device, protection of the discovery message based on the first set of keys need not involve scrambling.

[0312] In yet another option of this definition, the method and apparatus described above wherein the second protected message and / or the third protected message includes two MICs.

[0313] In yet another option of this definition, methods and apparatus are described above in which the second protected message and / or the third protected message comprises a single MIC that is updated (ie, the received MIC is verified and recalculated) by the second device.

[0314] In yet another option of this definition, methods and apparatus are described above in which the second protected (discovery) message includes two MICs (as well as an end-to-end MIC and a hop-by-hop MIC) and the third protected (discovery) message includes a single MIC.

[0315] In yet another option of this definition, a method and apparatus are described above wherein protection of the first protected message based on the second key set requires step 3 of clause 6.1.3.4.3.5 of TS 33.303 to be XORed with the most significant (L+16+16) bits of the discovery message (0x FFFFFFFF||time-hash-bit-sequence).

[0316] In yet another option of this definition, methods and apparatus are described above, wherein a second MIC computed with an integrity key from a second set of keys is computed over the entire message including the MIC included in the first protected message.

[0317] In yet another option of this definition, methods and apparatus are described above wherein the second set of keys shall not include a confidentiality key.

[0318] In yet another option of this definition, methods and apparatus are described above, wherein if the first set of keys includes confidentiality keys, then the policy requires that protection of messages based on the second set of keys must not involve confidentiality protection.

[0319] In yet another option of this definition, methods and apparatus are described above wherein policy requires that protection of discovery messages be based on integrity and confidentiality keys of a first set of keys and integrity and scrambling keys of a second set of keys.

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

[0321] It should be noted that the above-mentioned means may be implemented by the first device and / or the second device and / or the third device.

[0322] Generally, a system is described that includes a first device and a second device and a third device.

[0323] Security and privacy-aware path switching in UE-to-UE relay scenarios.

[0324] In the different use cases studied in TR 33.740v0.2.0, the source UE and the target UE communicating through the first UE to UE may need to perform a path switch from the first UE to the UE relay to the second UE to the UE relay. This function needs to ensure the connection between the source UE and the target UE, for example. The security of such a process is therefore crucial. For example, in some solutions, the source UE first triggers the path switch in the first step. Then, the source UE can send a link modification message (including candidate relay ID, source UE link ID and security parameters) to the target UE. The target UE can then select a new relay and establish a new security key, and can reply with a link modification acceptance (including the selected relay, and indicating the target UE link ID and security parameters). The source UE can then establish a new security key and can send a direct communication request including the (new) link ID of the target UE. The target UE can then locate and use the new security key to verify the DCR message and reply to the direct communication acceptance (including the new source UE link ID). Upon receiving the direct communication acceptance, the source UE can locate and use the new security key to verify the direct communication acceptance message. It should be noted that the (e.g., source UE) link ID may be a random number generated locally by, for example, the source UE. In order to avoid replay and linkability / traceability attacks across the path switching process, a new source UE link ID is generated and used each time a new path switch is initiated, i.e., each time a link modification message for a path switch is sent.

[0325] In some related solutions, it is proposed to perform a path switch by sending a link modification request (TS24.554) that carries a list of candidate relay identifiers (RIDs) and source UE link IDs and security parameters. However, in this approach, it is unclear how the source UE can obtain the latest RID list. For example, the source UE may not have collected a list of UE-to-UE relays during discovery, and even if it did, the list may be outdated.

[0326] In some solutions, it is proposed that the source UE performs a trigger for a path switch. However, in this approach, it is unclear how the target UE can trigger a path switch.

[0327] In some solutions, it is proposed that the source UE sends a Link Modification Request message and the target UE replies with a Link Modification Accept message, which is used for the purpose of establishing a new path. However, even though these messages are used to establish a new path and derive key material, they appear to lack any security protection according to TS24.554. In this case, an attacker can inject a Link Modification Request message that could falsely trigger the path switching procedure. Furthermore, any fields exchanged (e.g., the new link ID) are in plain text.

[0328] In some solutions, it is proposed to update the security keys during path switching. However, this may not always be required.

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

[0330] In a first embodiment, which can be used independently or in combination with other embodiments, it is proposed to enhance the link modification request and link modification accept messages with a message integrity code. The MIC can be calculated using the NIA algorithm, or it can be calculated by a pseudo-random function on the content of the message and a random number or a counter. For the counter, a UTC-based counter can be used, from which the least significant bits are exchanged. The MIC can be calculated using a key associated with the current PC5 connection on the first UE to the UE relay (e.g., a key derived from K_NRP or K_NRP-sess). In this embodiment, the first UE (e.g., the source UE) will construct one of these messages (e.g., a link modification message), including, for example, a candidate RID list and / or a source UE link ID, which is used on the source UE to connect the existing PC5 unicast link via relay_1 to a new link with a selected relay (e.g., relay_2) and / or security parameters (i.e., random number_1, K_NRP-sess). NRP-sess The second UE (e.g., the target UE) will associate a new PC5 unicast link with the MSB of the ID of the received UE. Next, it will append a counter or a portion of a counter, and it will include a MIC calculated on the contents of the message and the counter. The second UE (e.g., the target UE) will receive one of those messages (e.g., the protected link modification message) and will verify the received message by recalculating the MIC based on the received message and the counter and comparing the recalculated MIC with the received MIC. If the verification is successful, the second UE can continue with the normal message flow, for example, as described above.

[0331] In another embodiment, which can be used independently or in combination with other embodiments, it is proposed to perform discovery to trigger a UE-to-UE path switch. This can be done, for example, Figure 3In the example above, the discovery model A or similarly the discovery response message from the target UE to the source UE is completed for the discovery model B. The model A and model B discovery messages can be protected 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 on a given UE to UE relay. Since the source UE does not know which other UE to UE relays may be available, the source UE cannot include a list of potential relay identifiers, but it can include the ID of the current UE to UE relay (i.e., the first UE to UE relay) in the initial discovery message (e.g., request or notification discovery message). When the UE to UE relay message forwards the discovery message from the source UE, if the UE to UE relay is the UE to UE relay currently handling the connection, i.e., if it is the first UE to UE relay, the UE to UE relay may not forward it because it can understand that the source UE is triggering a path switching process. The target UE will then receive discovery messages from all potential UE to UE relay devices. It may or may not receive discovery messages from the "first" UE-to-UE relay device (if it does not forward discovery messages). In the case where the target UE receives messages from the first UE-to-UE relay and the target UE has a connection established with the source UE through the first UE-to-UE relay, the target UE may only select it if it is the only option.

[0332] The target UE may then perform one or more of the following actions:

[0333] 1. Do not select a UE-to-UE relay or select one of them and reply with a message (e.g., a Discovery Model B Response message according to TS 33.503) that will be relayed to the source UE via the selected UE-to-UE relay, or reply with a Link Modification Request including the selected relay.

[0334] 2. Reply with a message (eg Link Modification Request or Discovery message) including a list of potential UE-to-UE relays.

[0335] In another embodiment, which may be used independently or in combination with other embodiments, the returned list of potential UE-to-UE relays returned by the target UE during discovery (eg, as in the previous embodiments) is arranged according to their preferences.

[0336] In another embodiment, which may be used independently or in combination with other embodiments, a list of potential UE-to-UE relays sent by a source UE (eg, in a Link Modification Accept) is arranged according to their preferences.

[0337] In another embodiment, which may be used independently or in conjunction with other embodiments, the discovery messages for path switching are enhanced with security parameters that will allow the PC5 security context (K_NRPsess, etc.) to be updated after being established via a new UE-to-UE relay. These security parameters may include K NRP-sess After receiving the first discovery message (e.g., request message), the target UE may perform security processing on the discovery message based on the description in this application or TS 33.503, and use the received security parameters to derive new security parameters, such as generating a new K NRP-sess .

[0338] In another embodiment, which may be used independently or in combination with other embodiments, the switching path process does not involve the K NRP-sess of updates and therefore no exchange of security parameters is required.

[0339] In another embodiment, which may be used independently or in combination with other embodiments, the discovery message for path switching may include a new (randomly generated) identifier, such as a link ID, to prevent tracking and link capability changes.

[0340] In another embodiment, which may be used independently or in combination with other embodiments, the discovery message used for path switching and comprising a new (randomly generated) identifier is protected with end-to-end confidentiality, for example, as described in the above embodiments.

[0341] In a further embodiment, which may be used independently or in combination with other embodiments, the discovery message for path switching may include a current link ID that allows the discovery message to be associated with an existing PC5 unicast link.

[0342] In another embodiment that can be used independently or in combination with other embodiments, the link ID exchanged in the link modification request or in the link modification acceptance or in the discovery message is protected with confidentiality to prevent an attacker from performing a link attack, where the protection can be accomplished, for example, by using the NEA algorithm and a key related to the current PC5 key.

[0343] In another embodiment that can be used independently or in combination with other embodiments, the ID (e.g., link ID) exchanged in a link modification request or in a link modification acceptance or in a discovery message is not protected by confidentiality, but is generated in a way that an attacker cannot link them. For example, if the UE has an ID and a key, the UE can update the ID to ID'=LSB(KDF(K, ID)), where LSB(a) is a function that returns a subset of bits, such as the least significant bits, and the UE sends as a hint of ID' calculated as MSB(PRF(K, ID)), where MSB(a) is a function that returns a subset of bits, such as the most significant bits. KDF refers to a key derivation function.

[0344] In another embodiment, which may be used independently or in combination 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 in link modification request / accept messages, but those link IDs are derived based on current or future keys associated with UE-2-UE communications. For example, the link ID of the source UE may be derived by a key derivation function using 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 additional parameters such as, for example, a bit string identifying the source UE or a UTC-based counter. The actual link ID may be a subset of the output of the key derivation function, e.g., the least significant bits. In this embodiment, no hint ID is exchanged.

[0345] In another embodiment, which may be used independently or in combination with other embodiments, the DCR message is protected as in TS 33.503 clause 6.3.5, but a newly generated key is used to protect the DCR message instead of protecting the discovery key as in clause 6.3.5. Thus, if the source UE sends a DCR during the path switch procedure, the source UE protects it, for example, using a key derived from the current or future K_NRP-sess key used in the PC5 link. A UE that previously received a message indicating a path switch (e.g., a discovery message or a link modification request from a device to which it is currently connected), and then receives a DCR message, the UE will then decrypt / integrity verify the DCR message using a key derived from the current or future K_NRP-sess key used in the PC5 link.

[0346] In another embodiment, which may be used independently or in combination with other embodiments, the target UE may trigger the path switching process by sending a first indication to the source UE. The indication of the path switching requirement may be exchanged via a link modification request. The message may be empty or sent using a well-defined identifier.

[0347] In another embodiment, which may be used independently or in combination with other embodiments, the target UE may trigger the path switching process and then the message flow proceeds in the reverse manner.

[0348] In another embodiment, which can be used independently or in combination with other embodiments, the derivation of the new PC5 key is performed through a direct communication exchange. Specifically, the direct communication request includes information such as random number_1, K NRP-sess The target UE derives the session key K upon receiving the DCR message. NRP-sess , and upon receiving the DCA message, the source UE derives the session key K NRP-sess The previous phases (eg, discovery phase and / or link modification phase) are used for path discovery and / or link ID update.

[0349] In another embodiment, which may be used independently or in combination with other embodiments, path switching is not only used for the purpose of changing the path, but also for the purpose of securely enabling multipath communication between UEs. Thus, once two UEs have an established path on a first UE-to-UE relay, the source UE or the target UE may run a path switching procedure for the purpose of ensuring multipath communication, i.e., having more than one active communication path between the source UE and the target UE. In this case, the described embodiments may be used. It is advantageous to have different link IDs for different paths to hide the multipath capability. It is also advantageous to establish two or more different security contexts for each communication path in the communication path. In this case, the UE may derive different parameters using the identity of the UE-to-UE relay in each of the paths. For example, the KDF may be used according to the K NRP Export K NRP-sess , the KDF takes as input the random numbers (random_1 and random_2) that are typically exchanged in the authentication and key establishment process (e.g., TR 33.740) and the identity of the UE-to-UE relay. In this way, a single set of parameters needs to be exchanged, and different K NRP-sess , one K per link NRP-sess , that is, K NRP-sess (Relay ID) key. Similarly, the link ID to be generated and used by each communication path can be obtained by KDF from a KDF such as K NRP or K NRP-sess The KDF generates a key based on (relay ID), and the KDF takes the key and / or time counter and / or UE role (source / target UE) bit string and / or relay UE ID as input.

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

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

[0352] In another embodiment that can be used independently or in combination with other embodiments, the entire process of UE-to-UE relay path switching includes (1) the exchange of link modification request / link modification acceptance messages and (2) the exchange of direct communication request and direct communication acceptance messages, as described in other embodiments.

[0353] The following table shows some of the multiple combinations that are possible with the previous embodiments to achieve the key functions of path negotiation (i.e., determining a new UE-to-UE relay), key update negotiation (i.e., deriving new keys for the PC5 link), link ID update (i.e., implicitly or explicitly agreeing / generating a new link ID), and confirmation (new link).

[0354]

[0355]

[0356] In another general definition of an embodiment, a method and apparatus for path switching are proposed, which can be implemented on a device including one or more of the following stages:

[0357] Link modification phase, including sending link modification and receiving link modification acceptance messages,

[0358] The direct communication phase includes sending a direct communication request and receiving a direct communication acceptance message.

[0359] Additionally, the secure exchange of the new link ID may include encryption and integrity protection when exchanged during the link modification phase.

[0360] Generally, a method and apparatus as described above are proposed, wherein the DCR message is protected in clause 6.3.5 in TS 33.503 using a newly generated key.

[0361] Generally, a method and apparatus as described above are proposed, which are described above through a discovery phase, wherein link selection is performed in an initial discovery phase rather than in a link modification phase, and the link modification phase is used for the purpose of updating the PC5 key to be used after path switching and / or updating the link ID.

[0362] Generally speaking, a method and apparatus as described above is proposed, which is described above through a discovery phase, wherein link selection is supported by an initial discovery phase returning available UE-to-UE relays to a source UE.

[0363] Selection of the security establishment procedure during path switching

[0364] When the communication between the source UE and the target UE is protected by UE-to-UE relay, a standard security establishment procedure may be used. The standard security procedure is a procedure for establishing security between the source UE and the target UE by UE-to-UE relay when the source UE and the target UE have not yet communicated and / or have not yet established a security context. For example, the standard security establishment solution may be a solution such as solution #3 in TR 33.740 (which is an in-coverage solution that relies on the CN to perform PC5 security establishment, i.e., it is a procedure with network assistance) or solution #4 in TR 33.740 (which is an out-of-coverage solution that does not rely on the core network for PC5 security establishment, i.e., it is a procedure without network assistance).

[0365] In addition, it may be feasible to establish a secure link during a path switch in a UE-to-UE relay scenario, where a source UE and a target UE communicating via a first UE-to-UE relay wish to communicate via a second UE-to-UE relay. The (re)establishment of the secure link during the path switch may be performed in an efficient manner by an optimization procedure, wherein the optimization procedure is more efficient than using a standard security establishment procedure, as described in the above embodiments or as described in solution #14 in TR 33.740.

[0366] However, it may not always be possible to decide which safety program to use, the standard one or the optimized one.

[0367] For example, the initial communication between the source UE and the target UE on the first UE-to-UE relay may have been established via a standard out-of-coverage solution. Then, the second UE-to-UE relay may be in-coverage. The question is whether security during the path switch should rely on an optimized procedure (e.g., one of the above embodiments optimized for the path switch scenario) or on a standard security establishment procedure (e.g., exploiting the fact that the second UE-to-UE relay is in-coverage).

[0368] The aim is to solve this problem by the following embodiments which can be combined with one another.

[0369] In an embodiment, the method for establishing a security context in the case of a UE-to-UE relay path switch may be based on a policy provided to the UE (e.g., a source UE and / or a target UE and / or a UE-to-UE relay). The policy may determine which security method / procedure to use or prefer, such as whether to skip a standard security establishment procedure and use an optimized procedure, for example, by reusing an already established security context (e.g., a security policy and a security algorithm) from a previous PC5 unicast link, for example, for optimization purposes, for example, to allow faster link establishment and path switching, and to minimize service interruption. In this case, the security policy and security algorithm to be used, for example, for end-to-end security on the first relay, are no longer renegotiated during the establishment of the new link on the second relay, but only the agreed security policy and security algorithm from the first link are used to derive 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 UE (e.g., a source UE and / or a target UE and / or a UE-to-UE relay), which may depend on factors including, but not limited to, the following:

[0370] -UE coverage, for example, the coverage of the first UE to UE relay and the coverage of the second UE to UE relay,

[0371] - Ultra-Reliable Low-Latency Communications (URLLC) requirements,

[0372] - performance requirements, e.g. the maximum delay expected to be introduced during a path switch for the current application,

[0373] - whether the keying material used to establish the original security context on the first UE-to-UE relay is still valid / authorized when performing the path switch,

[0374] - Optimization purposes.

[0375] In a related embodiment, reusing the security context from the first link (i.e., between the source UE and the target UE via the first UE-to-UE relay) in the second link to be established (i.e., between the source UE and the target UE via the second UE-to-UE relay) may be affected by negotiation between the terminal UEs (e.g., the source UE and the target UE) and the second UE-to-UE relay, where the result is determined based on the UE (source UE, target UE, UE-to-UE relay) policy.

[0376] For example, during the initial security establishment via the first UE to UE relay, the target UE and the source UE may indicate whether they prefer to use the standard security establishment procedure during the path switch, or prefer the optimized security establishment procedure as in the above-mentioned embodiment or in solution #14 in TR33.740, and the conditions for using the optimized security establishment procedure. The preference may be based on a policy configured by a NF in the network, for example. The negotiation may determine, for example, that the optimized policy can be used only if both the target UE and the source UE agree.

[0377] For example, a UE-to-UE relay may have a policy that determines that both end UEs (source UE and target UE) may only be allowed to perform path switching in an optimized manner if the UE-to-UE relay is out of coverage. If in coverage, a standard security establishment procedure may be required.

[0378] In a related embodiment, the terminal UE (e.g., source UE and target UE) may want to establish multipath communication between them over multiple relays. In this case, the policy of the terminal UE may allow the security context (e.g., security policy and security algorithm) from the first link to be maintained, and only new security keys for other links (e.g., over other UE-to-UE relays) to be derived.

[0379] In another embodiment, when establishing multipath communications and / or path switching, a terminal UE (e.g., a source UE or a target UE) may announce during discovery that it has established a security context and / or wishes to reuse it when available, such that a UE-to-UE relay provided with a policy supporting / not supporting this approach may determine whether to establish / not establish a link with the terminal UE.

[0380] In an embodiment, the source UE may send a first message corresponding to a preferred security procedure for path switching, for example, as agreed upon during an initial security establishment procedure on the first UE-UE relay. The second UE-UE relay may then evaluate its local policy and determine whether the security procedure is appropriate. If not, the request may be rejected, and / or ignored, and / or a different security procedure may be indicated to the source UE for path switching.

[0381] In one embodiment, the source UE may obtain preferences of the UE-to-UE relay regarding the type of security establishment to be used, for example, depending on the coverage conditions or services provided. These preferences may be obtained, for example, on the first UE-to-UE relay during the initial security establishment process and / or by other means, such as listening to and receiving discovery messages from the second UE-to-UE relay that may indicate its preferences or coverage status. Based on this information and / or initial negotiation between the source UE and the target UE through the first UE-to-UE relay during the initial security establishment process and / or local policies at the source UE, the source UE selects the security process to be used during the path switch.

[0382] In general, a method and apparatus are presented for negotiating security procedures used between a source UE and a target UE when switching from a first UE-to-UE relay to a second UE-to-UE relay adapted to perform one or more of the following steps:

[0383] a) receiving configuration / policy to determine the path switching safety process,

[0384] b) negotiating the negotiated preference for a subsequent path switching procedure during a first security establishment procedure during a first UE-to-UE relay,

[0385] c) receiving information about the coverage status of the second UE-to-UE relay,

[0386] d) selecting a security procedure for path switching based on at least one of the following:

[0387] a. Configuration / Strategy,

[0388] b. Negotiation preferences, and

[0389] c. The coverage status of the second UE to UE relay.

[0390] Protection of DCR messages and PC5 security establishment in integrated discovery

[0391] TR 23.700-33 describes the need for discovery integrated into the PC5 unicast link establishment procedure in a UE-to-UE relay scenario. 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 with the help of discovery messages, but relies on direct communication requests, i.e., it is done in an integrated manner.

[0392] This is through Figure 66 , wherein the source UE, the UE-to-UE relay and the target UE interact with each other to establish a PC5 unicast link. In a first step 601, the UE is configured to use key material, for example, if authorized. In step 602, the source UE sends a message DCR to the UE-to-UE relay. In step 603, the message DCR is processed. In step 604, the UE-to-UE relay sends a message DCR' to the TUE.

[0393] TS 33.503 describes how to protect discovery messages (clause 6.1.3.2.3). TS 33.503 also describes how to protect certain fields of DCR messages in UE to network relay scenarios (clause 6.3.5). However, these procedures do not address how to protect DCR messages in the UE to UE relay integrated discovery use case.

[0394] The object of the present invention is to solve this problem.

[0395] In an embodiment, which may be combined with other embodiments, the security information field in the DCR message with integrated discovery may be sent unprotected.

[0396] The first consideration is that the discovery message is scrambled / confidentiality protected / integrity protected according to clause 6.1.3.2.3 of TS 33.503. The DCR message according to clause 6.3.5 is integrity protected and partially encrypted. The problem stems from the fact that the message DCR (step 602) and the message DCR' (step 604) do not have the same format, so the protection routine cannot be reused.

[0397] For example, it is assumed that the DCR contains (encapsulates) a standard discovery message, such as a U2U discovery message for discovering a target UE, and it is assumed that the target UE and the UE-to-UE relay have established a secure connection in a subsequent step using the security mechanism specified in clause 6.2 of TS 33.503. This refers to clause 5.3 in TS 33.536.

[0398] In one embodiment, the entire DCR is protected as if it were a discovery message as in clause 6.1.3.2.3 of TS 33.503 or similar to clause 6.1.3.2.3 of TS 33.503. Some changes may be needed:

[0399] - Scrambling may not be limited to 32 bytes, as the DCR' message may be longer and / or there may be more sensitive fields.

[0400] - The scrambled bytes may make it possible to hide the initial part of the encapsulated discovery message.

[0401] - The DCR' message may be constructed to include a discovery message (of fields) in the beginning of the DCR' message, followed by the remaining fields of the DCR message (eg, PRUK ID or random number or other parameters), such that the security routines in clause 6.1.3.2.3 of TS 33.503 are applicable.

[0402] Another embodiment is to protect some fields of the DCR' message similar to TS 33.503 clause 6.3.5, and the fields of the encapsulated discovery message as in clause 6.1.3.2.3 of TS 33.503. When receiving the message, the receiver can first retrieve the discovery message (descrambling, decryption, MIC verification), and then retrieve the remaining fields of the DCR message.

[0403] In another embodiment, the DCR' message is authenticated by performing blind decryption / descrambling because the relay UE does not know the discovery code (eg, relay code) contained in the discovery message when receiving the DCR' message.

[0404] In another embodiment, a UE (e.g., a UE-to-UE relay / target UE) must try multiple keys (e.g., scrambling keys) to access the message type, relay service code, and / or other identifier type in the DCR (DCR') message, which can be used to determine the integrity / encryption key to use in the processing of the DCR (DCR') message. This is different from the processing of the DCR message in clause 6.5.3 in TS 33.503, where the U2N relay may already know which keys to use based on the previous discovery phase.

[0405] In another embodiment, a field in the DCR' message is useful (ie, included and used) to determine whether the RSC or encryption key or integrity key is scrambled.

[0406] In another embodiment, one or more preconfigured keys (eg, linked to the RSC) may be used to protect fields of the DCR (except for the integrated discovery message), and the integrated discovery message may be protected using a discovery key.

[0407] In another embodiment, the integrated discovery message includes a field (e.g., integrated_discovery_indication) that can be turned on or off (or present / absent) and determines whether discovery is integrated and / or whether it is protected. This can be explicit or implicit. This field can also be integrity protected to ensure that an attacker cannot replay a discovery message into a normal discovery message in an integrated discovery message.

[0408] In another embodiment, an indication (eg, an integrated discovery indication) indicates whether the message is protected.

[0409] In another embodiment, the indication (eg, integrated discovery indication) may indicate the type of protection (eg, confidentiality and / or integrity) applied to the integrated discovery message and / or whether the protection applies to the integrated discovery message or the entire DCR message.

[0410] In another embodiment, an indication (eg, an integrated discovery indication) may be used to enable interoperability with V2X enabled devices.

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

[0412] In another embodiment, a relay service code (RSC) provided at a UE (eg, source, target, and UE-to-UE relay) may implicitly indicate whether discovery is integrated and / or whether it is protected.

[0413] In another embodiment variant, the ProSe restriction code provided at the terminal UE (eg, source UE and target UE) may implicitly indicate whether the direct discovery set is integrated.

[0414] For example, other embodiments of the present application that rely on two discovery key sets may be applicable.

[0415] For example, other embodiments in the present application applicable to UE-to-UE relay discovery security may be applicable.

[0416] In one embodiment, a UE (e.g., a source UE and a target UE) may be provided with two sets of key 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, a portion of a DCR message (e.g., a sensitive field in a DCR message and a discovery message), or the entire DCR message. Note that here and in other parts of the description, direct discovery set (elements) and UE to UE discovery set (elements) refer to two sets of elements in a discovery message.

[0417] In another embodiment variant, the source UE may use a first set of keys (e.g., DP_S-T) to protect the direct discovery set elements and use a second set of keys (e.g., DP_S-UE-to-UE) to protect only the UE-to-UE discovery set elements, such that if, for example, the target UE receives a DCR message with integrated discovery directly from the source UE, the target UE is able to retrieve the direct discovery set.

[0418] In another embodiment variation, DP_S-UE to UE is used to integrity protect the entire DCR message so that the relay can verify the entire DCR message, however, DP_S-UE to UE is only used to scramble / confidentiality protect the fields needed by the relay itself.

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

[0420] 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 established a security context with the target UE, the DCR' may be protected based on a key set corresponding to the established security context.

[0421] In one embodiment, if the source UE and the target UE have an established connection, and one of the terminal UEs decides to path switch (e.g., due to link deterioration) to communicate via a UE-to-UE relay, then after establishing a hop-by-hop security link between the source UE and the UE-to-UE relay and between the UE-to-UE relay and the target UE, the terminal UE may maintain and reuse the already established security context (e.g., security policies and algorithms).

[0422] In an embodiment, one or more UEs (e.g., source UE and / or target UE and / or UE-to-UE relay UE) may be (pre)configured or provided with a policy indicating which communication path and / or message type to prioritize, e.g., if a UE (e.g., target UE) receives one or more messages (types) on one or both paths, e.g.

[0423] - DCR messages from UE-to-UE relays, and / or

[0424] - A DCR message from the source UE, and / or

[0425] - Direct discovery of messages, and / or

[0426] -UE to UE discovery message

[0427] The UE (e.g., target UE) can be configured to prioritize messages or paths (e.g., direct connection with source UE). This can depend on policies and / or communication conditions (e.g., coverage, signal strength, etc.). This allows for better handling of the entire discovery process.

[0428] - Which key materials are used to protect which data fields in the DCR message. For example, the DCR message may be protected with one or two key sets to protect the UE-to-UE discovery message fields, and with another key (set) to protect the DCR fields, which do not include the UE-to-UE discovery message. Or the DCR message may be protected with two key sets, where the DCR message fields are protected with DP_S-UE-to-UE / DP_UE-to-UE-T and DP_S-T key materials.

[0429] - What form of protection is applied, to which data fields of the DCR message, and under what conditions. (e.g. which fields are scrambled / encrypted and integrity protected, which fields are integrity only protected, and which keys are used).

[0430] - If the target UE receives the DCR message directly from the source UE and selects a direct communication path with the source UE, e.g. verifies the DCR MIC, and discards the UE-to-UE discovery set and only processes (e.g. descrambling / decryption / integrity verification) the direct discovery set, how the target UE handles the UE-to-UE discovery set elements (e.g. relay indication, RSC).

[0431] - Which security mechanism is used by UE-to-UE relay to protect DCR', for example, based on whether the DCR message contains the user information ID of the target UE, or whether a security context has been established between UE-to-UE and the target UE.

[0432] In general, we can distinguish two scenarios: a DCR message broadcast by a source UE can be relayed by one (or more UE-to-UE relays) or it can be directly received by a 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., descramble and / or verify the integrity of the content of the received DCR message (e.g., discovery message). Therefore, we can consider the following points:

[0433] In one embodiment, the same security material (e.g., encryption / scrambling / integrity keys) may 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 may be decrypted and / or descrambled and / or integrity verified regardless of whether the target UE receives the DCR message directly or via the UE-to-UE relay.

[0434] In another embodiment, one or more UE-to-UE relays may be (pre)configured or provided with a policy that determines how the DCR message with integrated discovery should be constructed and protected when relaying to the target UE, based on, for example, whether the UE-to-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 whether it already has a security context established with the target UE. For example:

[0435] Example 1: If the UE-to-UE relay cannot identify the target UE (e.g., the user information ID of the T-UE is not included in the DCR message), the UE-to-UE relay may process the DCR message (i.e., descramble and / or decrypt and / or verify the integrity of the discovery message), and if the required verification is successful, the UE-to-UE relay constructs another DCR message (e.g., DCR') by, for example, discarding the relay_indication, and / or including the integrated discovery indication, and / or changing the RSC, and adding the user information ID of the UE-to-UE relay to the DCR', where the UE-to-UE relay protects the UE-to-UE discovery set elements similarly to the source UE. If applicable, the UE-to-UE relay may reuse 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 the DCR' message (e.g., second hop-by-hop security material, i.e., keeping the same RSC). Alternatively, the UE-to-UE relay may use different security material than that used in the first hop-by-hop link, ie, change the RSC in the DCR', and finally broadcast the message of the protected DCR'.

[0436] Example 2: If the UE-to-UE relay processes the DCR message (e.g., similar to the scenario described above) and identifies the target UE (e.g., by the target UE's user information ID or destination layer 2 ID). If a security context has been established with that target UE, the UE-to-UE relay may construct a subsequent message (e.g., DCR') as follows: discard the relay_indication, and include the integrated discovery indication if not already included, and include only the set of direct discovery elements from the integrated discovery message. The entire (or partial) message may then be protected based on the keying material corresponding to the established security context.

[0437] In another embodiment, the UE-to-UE relay may be able to identify the target UE (e.g., by the user information ID of the T-UE in the DCR message or the target layer 2 ID of the target UE), in which case it may establish a secure unicast link with the target UE following the procedure defined in clause 5.3 of TS 33.536, wherein the UE-to-UE relay transmits a DCR' (including the UE-to-UE relay information user ID) including a direct discovery set for end-to-end protection in addition to the Key_Est_Info / security information for direct authentication and key establishment between the UE-to-UE relay and the target UE.

[0438] In an embodiment, the target UE user information ID may be protected as part of the UE-to-UE discovery set so that the UE-to-UE relay may identify the target UE upon receiving a DCR message with integrated discovery.

[0439] In another embodiment, the source UE may calculate a pseudonym (PID) based on the ID as a function, such as a one-way function, such as a cryptographic hash, such as PID=Hash(target UE's user information ID). The source UE may send the PID as part of the UE-to-UE discovery set, or unprotected in another field of the DCR message. In particular, this method may be applicable when the target UE user information ID is long enough.

[0440] In another embodiment variant, the source UE may add the salt / random number as a parameter to the function used to calculate the PID, e.g. PID=Hash(salt, target UE's user information ID) to avoid dictionary attacks. The salt / random value may be protected and sent as part of the UE-to-UE discovery set.

[0441] In another embodiment, the UE-to-UE relay may use the received PID and / or the received ID to determine whether the UE-to-UE relay has a secure connection with the target UE. This then allows the UE-to-UE relay to protect messages (e.g., direct discovery set) using the corresponding key or keys from the established security context.

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

[0443] In another embodiment, the UE-to-UE relay may be able to identify the target UE (e.g., by the target UE's user information ID, or the target layer 2 ID in the DCR message), and have a secure link already established with it (e.g., by a previous link establishment with another source UE). In this case, the UE-to-UE relay can transmit the DCR's message protected with security material from the already established security context. In addition, since the secure link has already been established, the direct authentication and key establishment and direct security mode command procedures can be skipped between the UE-to-UE relay and the target UE.

[0444] In another embodiment, the UE-to-UE relay may use a default destination layer 2 ID that it is provided with, such as clause 5.1.5.1 of TS23.304, which may be associated with a target UE with which the UE-to-UE relay may have established a secure link. In this case, similar to the above embodiment, the UE-to-UE relay may reuse the key material associated with the established security context to protect the DCR' when relaying the DCR' to the target UE. In other words, there is a mapping between the default destination layer 2 ID and the target UE, so that the UE-to-UE relay then knows which security key material to use given the default destination layer 2 ID.

[0445] In another embodiment, if the UE-to-UE relay receives a DCR message with integrated discovery and has a secure link already established with the target UE, the UE-to-UE relay may remove the UE-to-UE discovery set elements (eg, RSC, security information) from the DCR' sent to the target UE.

[0446] In another embodiment variant, the reuse of an existing security context with a terminal UE (e.g., a target UE) by a UE-to-UE relay is not limited to integrated discovery scenarios, but may also be applicable, for example, to a normal discovery process. That is, during the discovery phase, if the source UE intends to establish a secure link with a target UE via a UE-to-UE relay, then if the UE-to-UE relay already has a secure link established with the target UE, the UE-to-UE relay may reuse the key material associated with the established context. The reuse of an existing security context by a UE-to-UE relay may also be applicable to other security processes. For example, how to establish a secure link between two terminal UEs with network assistance is described in Sol#3 in TR 33.740v0.7.0. If UE1 and UE2 are already communicating via a UE-to-UE relay, and then UE3 wishes to communicate with UE2 via the same UE-to-UE relay, UE3 and the UE-to-UE relay need to establish a secure link as described, for example, in Sol#3 in TR 33.740, but the security context between UE2 and the UE-to-UE relay may be retained and reused and does not need to be re-established.

[0447] In another embodiment, all or part of the embodiments related to reusing an existing security context between a UE-to-UE relay and a terminal UE (eg, a target UE) may be combined with other embodiments or used independently and may be applicable to both integration and normal discovery processes.

[0448] In another embodiment, the UE-to-UE relay may not be able to identify the target UE, in which case the UE-to-UE relay may have to broadcast the DCR'. According to clause 5.5.3.1 in TS 33.536, there is no specific procedure defined for protecting the NR-based PC5 broadcast mode, and therefore, the UE-to-UE relay may protect the DCR' as if it were a discovery message as in clause 6.1.3.2.3 of TS 33.503 or similar to clause 6.1.3.2.3 of TS 33.503, where the required changes apply as described in the above embodiments.

[0449] In another embodiment variant, if the UE-to-UE relay supports multiple protection mechanisms, the selection of the security mechanism employed may be configured by the network (eg, by policy). In addition, the UE-to-UE relay may include in the DCR' message an indication of which protection mechanism is employed to protect the message.

[0450] In another embodiment, if the UE-to-UE relay is in 3GPP coverage, the network may assist by, for example, providing key material (e.g., DUIK / DUSK / DUCK) to scramble / encrypt / integrity protect the DCR' message, and / or by providing a security policy (e.g., to determine which security method to adopt (e.g., establishing a new secure link or using an established security context)).

[0451] In reference Figure 2 In another embodiment, use of the above techniques is shown, where a UE-to-UE relay is in 3GPP coverage and supported by the network, establishment of hop-by-hop security links between a source UE and the UE-to-UE relay and between the UE-to-UE relay and a target UE may be performed as follows, whereby (1) not all steps are always required, (2) some steps may be performed multiple times, and (3) some steps may be performed in a different order:

[0452] In the case where 1401 represents a terminal UE (e.g., a source UE), 1402 represents a UE-to-UE relay, 1403 represents a terminal UE (e.g., a target UE), and 1404 represents a 5GC, a secure hop-by-hop link between UEs may be established as follows:

[0453] -Step 1410: Provide discovery parameters, key materials, etc. to the UE when within coverage to establish a PC5 secure communication link.

[0454] - Step 1411: Construct a DCR message with integrated discovery, similar to Fig.12 The source UE may include PRUK-ID1 and K in the security information field of the DCR message (e.g., as defined in clause 6.4.3.7.4 of TS 23.304). NRP1 Freshness parameter 1. Similar to Fig.12 Step 1 in (ie, using the discovery security material provided in step 1410) protects the integrated discovery message.

[0455] - Step 1412: The source UE broadcasts a protected DCR message with integrated discovery.

[0456] -Step 1413: UE-to-UE relay processes the received DCR message, decrypts / descrambles / integrity verifies the protected integrated discovery / DCR message, extracts RSC1, PRUK-ID1 and K NRP1 Freshness parameter 1, then constructs a DCR' including its user information ID and then sends it to the target UE, whereby the DCR' message may include some of these parameters, for example, RSC 1 / 2 is privacy protected, while DCR is integrity protected.

[0457] - Step 1414: The UE-to-UE relay transmits the DCR′ to the target UE. This step may occur before, after, or simultaneously with steps 1415 and 1416.

[0458] - Step 1415 / 1416: The UE-to-UE relay sends a packet to the 5GC containing RSC1, PRUK-ID1 and the K retrieved from the DCR message in step 1413. NRP1 A key request with one or more of the freshness parameters 1, and then receives K from the 5GC NRP1 and K NRP1 Newness parameter 2. This step may also occur at a later point in time, for example, once a secure connection between the UE-to-UE relay and the target UE has been established. Message 1415 may include the identity of the target UE (PRUK-ID2) so that the core network can verify whether the source UE is authorized to communicate with the target UE. If performed before (for example, before step 1414), the UE-to-UE relay can ensure that the source UE is authorized so that the target UE only receives the DCR' message in this event. If performed later, for example after step 1414, or even after steps 1419 / 1420, the UE-to-UE relay can ensure that the target UE is authorized / willing to communicate with the source UE so that the core network is only involved in this case.

[0459] -Step 1417: The target UE may receive multiple DCR messages (e.g., relayed from one or more UEs to UEs); for simplicity, Figure 2 A single DCR message, such as DCR', is shown sent in step 1414. The target UE processes the DCR' message, decrypts / descrambles / integrity verifies the protected integrated discovery / DCR message, and then based on whether a security context has been established with the UE-to-UE relay and policy evaluation, the target UE decides whether to establish a secure link with the UE-to-UE relay.

[0460] - Step 1418: If the target UE is to (re)establish a secure link with the UE-to-UE relay, the target UE sends a packet containing RSC2, PRUK-ID2, and K protected similarly to step 1411. NRP2 Direct authentication and key establishment request with freshness parameter 1.

[0461] - Step 1419 / 1420: Similar to step 1415 / 1416, the UE-to-UE relay will have the parameters (i.e., RSC2, PRUK-ID2, and K NRP2 The key request with freshness parameter 1) is sent to 5GC to the core network, and the key request containing K NRP2 and K NRP2 Key response message with freshness parameter 2. In step 1419 / 1420, the UE-to-UE relay may also include the identity of the source UE (PRUK-ID1) so that the 5GC can verify whether the two UEs are authorized to communicate with each other.

[0462] -Step 1421: Direct Security Mode Command procedure, where the UE-to-UE relay sends K in the Direct Security Mode Command message NRP2 Freshness parameter 2 is transmitted to the target UE, and then the target UE obtains the value from its PRUK, RSC2, K NRP2 Freshness parameters 1 and K NRP2 Freshness parameter 2 derives K NRP2 A successful verification of the Direct Security Mode Command ensures 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.

[0463] - Step 1422: Upon receiving the direct security mode complete message from the target UE, the UE-UE relay verifies whether the target UE is authorized to obtain relay service. If the verification is successful, the UE-UE relay sends a direct communication accept message to the target UE to complete the security link establishment process.

[0464] - Step 1423 / 1424: Similar to step 1421 / 1422, a secure link is established between the source UE and the UE-to-UE relay.

[0465] - Step 1425: If the UE-to-UE relay communication link is established via a layer 2 UE-to-UE relay, an end-to-end secure link is established between the terminal UEs (ie, the source UE and the target UE).

[0466] Steps 1423 and 1424 may be performed after step 1416, concurrently, or after a secure link is established between the UE-to-UE relay and the target UE.

[0467] In one embodiment, in step 1421, the UE to UE sends a message including K NRP2 The target UE then sends a direct authentication and key establishment response based on its PRUK, RSC2, K NRP2 Freshness parameters 1 and K NRP2 Freshness parameter 2 derives K NRP2 Then, the target UE sends a message to the UE-to-UE relay containing, for example, K NRP2 The UE-to-UE relay then sends a direct security mode command message containing, for example, the MSB of the KID to the target UE. Successful verification of the security mode command assures the UE-to-UE relay that the target UE is authorized to receive the relay service. The UE-to-UE relay then sends a direct security mode command message containing, for example, the KID to the target UE. NRP2 Upon receiving the successful authentication of the security mode complete message, the target UE ensures that the UE-to-UE relay is authorized to provide relay services, and then sends (e.g., in step 1422) a direct communication accept message to the UE-to-UE relay to complete the security link establishment process.

[0468] In a related embodiment, which may be combined with other embodiments for integrated discovery or standalone use, the DCR' sent from the UE-to-UE relay to the target UE (in step 1414) does not contain the PRUK-ID, because only RSC2 is protected for confidentiality, while DCR' is protected for integrity. Therefore, the confidentiality protection routine in clause 6.3.5 of TS 33.503 is updated so that only RSC is encrypted. Therefore, in Appendix A.5 in TS 33.503, the DCR confidentiality key stream is set to the L least significant bits of the KDF output, where L = the length of RSC.

[0469] In an embodiment variant, the DCR' sent from the UE to UE relay to the target UE in the step does not contain the PRUK-ID, and therefore the PRUK-ID field may be set to a predefined value (e.g., all zeros) or a random value, so that the confidentiality protection routine defined in clause 6.3.5 of TS 33.503 may be reused to protect the PRUK-ID and RSC. The PRUK-ID predefined value may be discarded when received, decrypted and / or descrambled and / or integrity verified by the target UE. Another difference compared to clause 6.3.5 in TS 33.503 is that in integrated discovery there is no previous discovery phase and therefore, in related embodiments that may be combined with other embodiments for integrated discovery or used independently, the UE-to-UE relay and the target UE must perform blind decryption / integrity verification when receiving the messages DCR (step 1413) and DCR' (step 1417), instead of verifying the integrity of the received DCR message using the code for discovery sending security parameters as described in clause 6.3.5.3 in TS 33.503, and / or decrypting the encrypted PRUK ID and RSC using the code for discovery sending security parameters, and verifying whether the RSC matches the RSC sent in the discovery message as described in clause 6.3.5.2 in TS 33.503.

[0470] Although the UE-to-UE relay does not know which keys to use for integrity verification and decryption of the DCR message (step 1413), the UE-to-UE relay knows which keys to use when receiving a message from the target UE including the target UE's PRUK-ID2, RSC2 (i.e., associated with the RSC2 sent in the DCR'). Therefore, in different embodiments that can be combined with other embodiments for integrated discovery or standalone use, the UE-to-UE relay uses the keys used to encrypt / integrity protect the DCR' message to perform decryption / integrity verification of the message received from the target UE (step 1413). This may require the UE-to-UE relay to keep track of the keys used to protect the DCR' message of step 1413, where the tracking / storage may be limited to multiple keys and / or time limits.

[0471] In an embodiment variant that can be combined with other embodiments for integrated discovery or used independently, 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 when receiving the DCR (step 1413), and then reuses the key (associated with the RSC) to derive the key stream to confidentiality protect the RSC and integrity protect the DCR'. The target UE performs blind decryption / integrity verification when receiving the DCR' (step 1417), and reuses the same key (associated with the RSC) to confidentiality protect the PRUK-ID and RSC and integrity protect the message sent to the UE-to-UE relay (in step 1418). The UE-to-UE relay then performs decryption / integrity verification on the message received from the target UE using the same key used to protect the DCR and DCR' messages. In an embodiment that can be combined with other embodiments for integrated discovery or used independently, the DCR with the integrated discovery message can be received directly by the target UE. In this case, the target UE processes the message differently than when the UE-to-UE relay relays the message. That is, the target UE may not have to decrypt the RSC and PRUK-ID; the target UE may blindly integrity verify the DCR using only the integrated discovery message including the encrypted PRUK-ID and RSC, and if the integrity verification is successful, the target UE may discard the PRUK-ID and RSC. In an alternative, the target UE may not perform integrity verification on the message. The communication link between the source UE and the target UE is then established following the procedure described in 5.3 of TS 33.536.

[0472] In one embodiment, the steps required to establish a hop-by-hop secure link may be repeated / retried (e.g., in the event that (a) fails) multiple times (e.g., N times), which may be determined by a policy provided at the UE (i.e., relay and terminal UE), such as in step 1410.

[0473] In another embodiment, if the target UE receives multiple DCR messages with integrated discovery (e.g., from multiple UE-to-UE relays) and it recognizes that a secure link has been established with one of the relays, if the target UE selects the UE-to-UE relay (e.g., based on the policy evaluation and path selection steps), steps 1418, 1419, 1420, 1421 and 1422 can be skipped and instead the target UE sends a direct communication accept message to the UE-to-UE relay.

[0474] In another embodiment variation, the steps performed between the target UE and the UE-to-UE relay to establish the second hop-by-hop security link may be in the reverse order; that is, the target UE may initiate the security mode command procedure (e.g., in step 1418) and provide its RSC2, PRUK-ID2, and KNRP2 Freshness parameter 1, steps 1419 and 1420 remain the same, and upon successful verification of the target UE's authorization to receive relay services, in step 1422, the UE-to-UE relay sends K to the target UE in a Direct Security Mode Complete message. NRP2 Freshness parameter 2, the target UE then calculates the freshness parameter based on its PRUK, RSC2, K NRP2 Freshness parameters 1 and K NRP2 Freshness parameter 2 derives K NRP2 Successful verification of the Direct Security Mode Complete message ensures 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 Communication Accept message to the UE-to-UE relay (in step 1422) to complete the secure link establishment process.

[0475] In another embodiment, the terminal UE may provide their SUCI / GUTI in steps 1411 (for source UE) and 1418 (for target UE) in addition to or instead of their PRUK-ID for identification and / or authentication and / or authorization purposes.

[0476] The exchanged security parameters may also be applicable to another related embodiment variant, whereby the source UE and the target UE and one or more of the UE-to-UE relays may be out of coverage, and / or the UE may agree or be configured to use a security process without network assistance. In this embodiment variant, a key request / response message with 5GC is not used. The key material may involve an authorization token (similar to Sol#4 in TR 33.740) or a long-term credential that allows the establishment of a PC5 security link. Regarding the authorization token, an authorization token (AT) may be provided by 5GC. The AT from the source UE may be sent in message 1412 and may be verified by the UE-to-UE relay upon receipt of message 1412. If the verification is successful, the UE-to-UE relay may forward its own AT and the AT of the potential source UE in step 1414 (DCR'). The target UE verifies the authorization upon receipt of message 1414. The target UE may then send its AT in message 1418, and upon receipt of 1418, the UE-to-UE relay may verify the authorization of the target UE. In other words, in steps 1415 and 1419, the key request message to the 5GC may be combined to include RSC1, PRUK-ID1, and K NRP1 Freshness parameters 1, RSC2, PRUK-ID2 and K NRP2 One or more of the freshness parameters 1. The key response message from the 5GC in step 1416 / 1420 can be combined to include K NRP1 and K NRP1 Freshness parameter 2, K NRP2 and K NRP2Freshness parameter 2. Once the target UE has replied to the UE-to-UE relay with its direct authentication and key establishment request message, the sending of the combined key request message may occur (step 1418). This method allows the number of round trips to the 5GC to be reduced, and therefore reduces latency. This also allows the 5GC to verify that 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 embodiment variant may be applicable to other types of security establishment in the UE-to-UE relay, for example, it may be applicable to the standard PC5 security establishment procedure with network assistance as Sol#3 in TR 33.740.

[0477] In another embodiment variation, security parameters (such as PRUK-ID or authorization token) included in a DCR message with integrated discovery (eg, DCR') may be protected with discovery material and / or an existing security context as in other embodiments.

[0478] From the side of the target UE, we can distinguish several scenarios. For example, the target UE may receive multiple DCR messages, for example directly from the source UE and / or from one or more UE-to-UE relays, where the UE-to-UE relays may employ different security mechanisms, for example as described above in the UE-to-UE relay security establishment option. Since the target UE performs the path selection, a policy may be (pre)configured / provided to determine how to select such a path (e.g., a direct link, or via a UE-to-UE relay) to establish a communication link with the source UE. The path selection may depend on a variety of factors, including but not limited to signal strength, optimization requirements (e.g., a UE-to-UE relay with an established security context may be more advantageous than a UE-to-UE relay that requires a key establishment step to establish a secure link) and / or relay avoidance (e.g., always select a direct link with the source UE when possible because it minimizes the security procedures that the target UE needs to perform to establish a secure link). Based on the target UE policy, the received DCR message may be processed according to one or more of the following embodiments:

[0479] In one embodiment, if the target UE receives multiple DCR messages from one or more UE-to-UE relays, the target UE is to prioritize the link to one of the relays that has established a security context. This has the advantage that the target UE can skip the direct authentication and key establishment and direct security mode command procedures, thereby more efficiently establishing a connection with the source UE.

[0480] In one embodiment variant, if the target UE receives multiple DCR messages from multiple UE-to-UE relays, the target UE can decrypt / descramble / integrity verify 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 secure link has been established with the UE-to-UE relay.

[0481] In one embodiment variation, if the target UE receives multiple DCR messages from multiple UE-to-UE relays, the target UE may (1) use the L2 address to determine whether a secure link has been established with one of the UE-to-UE relays, and (2) use it to retrieve the security context (e.g., key set) used for decryption / descrambling / integrity verification of the received DCR message.

[0482] In an embodiment variant, if a security material set is used, the UE-to-UE relay may identify the target UE (e.g., by its user information ID), in which case the UE-to-UE relay may send a message to the target UE containing only the direct discovery set and protected using the security material associated with the established link. Alternatively, the UE-to-UE relay may include an integrated_discovery_indication to the message sent to the target UE.

[0483] In an embodiment variant, the target UE may receive several DCR messages, for example, from the source UE and from one of the many UE-to-UE relays. The target UE always preferentially establishes a direct link with the source UE, regardless of whether a security context exists or is established (e.g., with one of the UE-to-UE relays) and / or which security solutions / mechanisms are used.

[0484] In another embodiment, if the target UE receives multiple DCR messages from different UE-to-UE relays, the target UE may select a preferred UE-to-UE relay based on several criteria, such as how the DCR' message is protected and what is required to establish a secure link with the UE-to-UE relay. For example, if a UE-to-UE (e.g., UE-to-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, while another UE-to-UE relay (e.g., UE-to-UE2) sends a partially protected DCR' message (e.g., only the discovery message is protected according to clause 6.1.3.2.3 of TS 33.503), while the rest of the DCR' (e.g., Key_Est_Info) is not protected; the target UE may select UE-to-UE1 because it is more efficient, e.g., to establish a secure link with the source UE. Alternatively, it may select UE-to-UE2, e.g., if the signal quality is better, e.g., so that the target UE does not have to resort to relay reselection if the link with UE-to-UE1 deteriorates.

[0485] In another embodiment, the target UE may receive multiple DCR messages from different UE-to-UE relays at different points in time. For example, the target UE may evaluate and select a specific path and then receive a DCR message from one of the UE-to-UE relays that may have a higher priority (e.g., a security context has been established). For this case, the target UE policy may set a timer to take into account the received DCR and discard any DCR received after the timer expires.

[0486] In one embodiment, the target UE may trigger a path switch or relay reselection based on, for example, link quality deterioration, in which case the target UE may indicate / notify the source UE of its intention to switch paths and whether security policies and algorithms can be maintained (i.e., non-renegotiated through the reselected relay), for example, to optimize the path switch and security establishment procedures.

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

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

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

[0490] In an embodiment, the relay indication may be protected (eg, integrity protected) independently or as part of a DCR message (eg, within a UE-to-UE discovery set).

[0491] In one embodiment, if two discovery security material sets are used, the Relay_Indication may be protected (e.g., integrity protected) by the source UE using end-to-end key material (e.g., DP_S-T) so that if the integrated discovery DCR message is received directly by the target UE, the target UE may verify it. If the DCR message is received by a UE-to-UE relay, then after discarding the Relay_Indication, the UE-to-UE relay may replace the end-to-end calculated MIC with a hop-by-hop calculated MIC so that when the target UE receives the DCR message through the relay, it may verify its integrity using DP_UE-to-UE-T.

[0492] In an embodiment, if the integrated discovery DCR message is relayed, the UE-to-UE relay may protect (eg, encrypt / scramble / integrity protect) the relay indication as part of the UE-to-UE discovery set.

[0493] In an embodiment, if only one discovery security material set is used, the source UE may protect the integrated discovery message using discovery security material associated with the RSC as in clause 6.1.3.2.3 of TS 33.503, including, for example, source user information ID, ProSe service information, RSC, and (if included) target UE user information ID. If the source UE is configured with DUCK, or DUSK and / or DUIK, the RSC and relay_indication may be scrambled, or encrypted and / or integrity protected using the DUCK, DUSK and / or DUIK. Alternatively, the discovery security material may be used to protect the RSC and the relay indication.

[0494] In one embodiment, the integrated discovery message confidentiality protection may be based on the discovery confidentiality mechanism described in A.7 of TS 33.503, where the input parameters of the encryption algorithm are:

[0495] -KEY: The 128 least significant bits of the output of the KDF (DUCK, UTC-based counter, MIC)

[0496] -COUNT: UTC-based counter

[0497] -BEARER: 0x00

[0498] -DIRECTION: 0x00

[0499] - LENGTH: LEN(discovery message)-(LEN(message type)+LEN(UTC-based counter LSB)+LEN(MIC)), where LEN(x) is the length of x in bits.

[0500] in

[0501] - LEN(discovery message) may refer to the length of the (integrated) discovery message, and / or

[0502] - In the integrated discovery scenario, the message type may refer to the ProSe signaling message type defined in clause 11.3.1 Table 11.3.1.1 of TS 24.554.

[0503] In another embodiment, in an integrated discovery scenario, LEN (discovery message) may refer to the length of the integrated discovery message, which includes a direct discovery set (e.g., source and target UE user information IDs) and a UE-to-UE discovery set (e.g., UE-to-UE relay user information ID, RSC) and excludes other DCR fields (e.g., security information).

[0504] In another embodiment variant, LEN(discovery message) may refer to the length of the entire DCR message including the integrated discovery message.

[0505] Where applicable, the above-described embodiments may be considered independently or combined with one another.

[0506] In an embodiment variant, processing at the source UE when protecting a DCR message may involve the following steps:

[0507] 1. Construct a message m1 including the direct discovery set elements, such as source UE and target UE IDs, and a subset of DCR fields, such as Integrated_Discovery_Indication.

[0508] 2. The message m1 may be integrity protected with the MIC calculated with the DUIK as configured in the Direct Code Transmission Security Parameters. The MIC is inserted (eg, concatenated, appended, etc.) in / to m1.

[0509] 3. The privacy sensitive fields in message m1 are protected with confidentiality of DUSK or DUCK as configured in Direct Code Transmission Security Parameters (DP_S-T). This results in a protected message 1, pm1.

[0510] 4. Construct message m2 (unprotected integrated DCR message) which includes pm1, the remaining fields of the DCR message (not included in m1, such as the relay indication) and the UE-to-UE discovery set elements, such as the RSC and the UE-to-UE relay user information ID.

[0511] 5. The message m2 may be integrity protected using the MIC calculated using the DUIK configured in the UE-2-UE code transmission security parameters. The MIC is inserted into the message m2.

[0512] 6. The privacy sensitive fields in message m2 (e.g., RSC in UE-to-UE discovery set) are protected by the confidentiality of DUCK as configured in UE-2-UE code send security parameters (DP_S-UE-to-UE). This results in protected message 2, pm2.

[0513] 7. Privacy-sensitive fields in pm2 that may need to be more easily accessed for performance reasons may be scrambled, resulting in a scrambled protected message 2, spm2.

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

[0515] In an embodiment similar to the other embodiments, protection of some fields in the integrated discovery message using specific keys may be subject to policy, for example, keys in DP_S-T (direct code sending security parameters) and / or keys in DP_S-UE to UE (UE-2-UE code sending security parameters) and which keys (i.e., DUSK and / or DUCK and / or DUIK in DP_S-UE to UE / DP_S-T) are used in the protection of the integrated discovery message.

[0516] The fields in pm1 are excluded from subsequent protection in steps 5 and 6. This allows the target UE receiving the integrated discovery message directly from the source UE to directly access pm1.

[0517] In an embodiment variant, when processing a received protected integrated DCR message, the processing at the target UE may be as follows:

[0518] 1. Check whether the relay_indication field is included. If yes, the target UE can directly process pm1 in step 5.

[0519] 2 Descramble message spm2 by receiving security parameters using UE-2-UE code or with existing context of UE-to-UE relay to obtain pm2.

[0520] 3. Remove confidentiality in pm2 by receiving security parameters using UE-2-UE code or existing context with UE-to-UE relay to obtain m2 and MIC.

[0521] 4. Verify m2 by using received m2, received MIC and UE-2-UE code to receive security parameters or existing context with UE-to-UE relay. If MIC verification is successful, remove MIC to obtain pm1.

[0522] 5. Remove confidentiality from pm1 by receiving security parameters using direct code to obtain m1 and MIC.

[0523] 6. Verify the integrity of m1 by using the received m1, the received MIC and the direct code reception security parameters and PRUK-ID (if it is a predefined value). If the MIC verification is successful, remove the MIC and return m1. The PRUK-ID field can also be b38etween38n38d after successful verification.

[0524] In an embodiment variant, steps 2, 3, 4 always use the same UE-2-UE code to receive security parameters. This has the advantage of adding another layer of security to pm1 through steps 5 and 6.

[0525] In an embodiment variant, if the target UE is configured with a policy that gives priority to reusing an existing security context (eg, between the target UE and a UE-2-UE relay), steps 2, 3, 4 always use the existing context.

[0526] In an embodiment variation, the target UE may determine whether the security context is available by checking the user information ID or layer 2 ID of the UE-to-UE relay.

[0527] In a variant embodiment, when processing a received protected integrated DCR message, the processing at the UE to UE relay may be as follows:

[0528] 1. Check whether the relay indication is included. If not, the relay discards the DCR message.

[0529] 2. Steps 2, 3 and 4 are similar to the same steps of processing a protected DCR message by the target UE.

[0530] 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 indicating a security procedure with network assistance, the UE-to-UE Relay also sets the PRUK-ID field to a predefined value or discards it.

[0531] 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 and produce scrambled protected messages m2', pm2'.

[0532] 9 spm2' are protected DCR messages with integrated discovery that can be relayed by UE-2-UE relays.

[0533] In an embodiment variant, if the UE-2-UE relay reuses the same RSC as used by the source UE, ie the same UE-2-UE code for sending the security material, the protection in steps 6 and 7 may also be applied to pm1.

[0534] In an embodiment variant, after step 4, if the UE-2-UE relay has a security context already established with the target UE, the UE-to-UE discovery set may be removed, and steps 6, 7 and 8 may be based on the security key material corresponding to the already established security context.

[0535] about Fig.10 , where a secure PC5 link may be established between a source UE and a target UE via one or more UE-to-UE relays, the process may be described as follows:

[0536] The source, target and UE-to-UE relays are provisioned with a security policy, and two discovery security material sets and parameters to enable establishment of a secure PC5 link.

[0537] 1. The source UE constructs a DCR message, which includes a direct discovery set, a UE-to-UE discovery set, and fields specific to the DCR message (integrated_discovery_indication and relay_indication). The direct discovery set and the integrated_discovery_indication are protected with direct code transmission security parameters. The entire DCR message is protected with UE-to-UE relay code transmission security parameters, whereby the direct discovery set and the integrated_discovery_indication are not protected for confidentiality.

[0538] 2. When the UE-to-UE relay receives the DCR message and descrambles / decrypts / integrity verifies it. If the integrity verification is successful, the UE-to-UE relay sets the relay indication to "OFF" and constructs another DCR message (e.g., DCR1 or DCR2) in a similar manner to step 1.

[0539] 2.a If the relay (eg, UE-to-UE relay 1 recognizes the target UE and has established a secure link with the target UE), UE-to-UE relay 1 protects DCR1 using security keys corresponding to the security context that has been established with the target UE.

[0540] 2.b If the relay (eg, UE-to-UE Relay 2) cannot identify the target UE or does not have a security context established with it, UE-to-UE Relay 2 sends security parameters using a UE-2-UE code to protect DCR2.

[0541] 3.a / b UE-to-UE relay 1 and UE-to-UE relay 2 send DCR1 and DCR2 to the target UE

[0542] 4. The target UE may receive several DCR messages (e.g., from one or more UE-to-UE relays). When applicable, the target UE descrambles / decrypts / verifies the integrity of the DCR message using the corresponding key (existing context or UE-2-UE code reception security parameters), and then the target UE uses the direct code reception security parameters to decrypt / integrity verify the direct discovery set and integrated_discovery_indication. Based on the policy evaluation and path selection in step 4, a secure link is established in one of the following cases (case 1 and case 2).

[0543] Case 1: Assume that the target UE selects a communication path through UE-to-UE Relay 1.

[0544] 5.a Since the security context has been established, the direct authentication and key establishment and direct security mode command procedures are skipped, and instead the target UE sends a direct communication accept to the UE-to-UE relay 2.

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

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

[0547] Case 2: Assume that the target UE selects a communication path through UE-to-UE relay 2.

[0548] 5.b / 6.b / 7.b corresponds to the establishment of a secure link between the UE-to-UE relay 2 and the target UE.

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

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

[0551] According to clause 5.3 of TS 33.536, secure hop-by-hop or end-to-end links between UE-to-UE relay 2 and terminal UE, between UE-to-UE relay 1 and source UE, and between terminal UEs are established based on the security information in the DCR message.

[0552] The above embodiments of reusing an existing security context (e.g., between a UE-to-UE relay and a target UE) upon receiving a DCR message may be applied to other procedures, such as solution #3 or #4 in TR 33.740, which describes a security procedure for establishing a secure PC5 communication link after a discovery procedure.

[0553] In with Fig.11 In another related embodiment, where a secure PC5 link can be established between a source UE and a target UE directly or via a UE-to-UE relay, the target UE needs to be able to process the incoming integrated DCR message independently of the direct or indirect path. This requires that the target UE has access to a direct discovery set as described in the above embodiments, for example, a direct discovery set associated with the RSC and intended to protect the discovery security material of the hop-by-hop messages that is not protected for confidentiality using a key set associated with the ProSe service.

[0554] The DCR message relayed by UE to UE (i.e., step 3) and the secure link establishment through relay (i.e., steps 6.a to 12.a) are similar to Fig.10 The processing and security link establishment is carried out through UE to UE relay 2.

[0555] The target UE processes message 2.b similar to the DCR' received in step 4, wherein if no relay indication is set and the target UE prioritizes a direct link with the source UE, it may establish a link with the source UE after steps 6.b, 7.b, 8.b.

[0556] In some cases, some configurations may be indicated implicitly or explicitly in the DCR message itself.

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

[0558] The 5G ProSe source UE and 5G ProSe UE-to-UE relay may encrypt the source user information ID, relay user information, target user information ID and RSC as follows:

[0559] 1) If the UE is configured with Discovery User Confidentiality Key (DUCK) / Discovery User Scrambling Key (DUSK), the DCR encryption 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-3 are skipped.

[0560] 2) Set the key stream to the DCR confidentiality key stream calculated using KDCR, UTC-based counter, bearer, direction and length as described in Annex A.7 of TS33.503 [6].

[0561] 3) XOR the message with the key stream.

[0562] However, this approach only addresses privacy / confidentiality protection and does not cover integrity protection. Furthermore, there is no distinction between the protection of DCR messages with integrated discovery sent by the source UE and the protection of DCR messages with integrated discovery sent by UE-to-UE relay. For example, the UE-to-UE relay user information ID may not be part of the integrated discovery message sent 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 U2U discovery set in the discovery message. Therefore, the purpose of the following embodiments is to address these shortcomings.

[0563] In one embodiment related to other embodiments, if DUCK is available, DUCK is used as KDCR; if DUCK is not available, if DUSK is available, DUSK is used as KDCR; if neither DUCK nor DUSK is available, KDCR is not configured and the message is not confidentiality / privacy protected.

[0564] In an embodiment, the transmitter UE (e.g., source UE or UE-to-UE relay) may be provided / 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 the MIC is calculated on the DCR message using KINT and a UTC-based counter. Finally, the MIC IE is set to the calculated MIC. This may be done as described in other embodiments.

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

[0566] In an embodiment variant, if the transmitter UE is not provided / configured with a DUIK, the DCR message is not integrity protected.

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

[0568] In one embodiment variant, the terminal UE (i.e., source UE and target UE) may be provided / configured with only a DUIK associated with a ProSe restricted code, in which case the terminal UE integrity protects the direct discovery set, while the UE-to-UE discovery set or the entire DCR message is not integrity protected.

[0569] In one embodiment, when in coverage, a policy / indicator (e.g., security_material_indication) may be provided / configured by the network to the terminal UEs (i.e., source UE and target UE) indicating whether one or two security material sets are used to protect (e.g., confidentiality, scrambling and / or integrity protection) DCR messages with integrated discovery.

[0570] In one embodiment variant, the UEs (source, target and UE-to-UE relays) may be provided / configured with a policy, RELAY_DISCOVERY_SECURITY_INDICATION, which indicates, for example, which type of protection (e.g., encryption, scrambling, integrity) is applied, and / or whether it is applied to the UE-to-UE discovery set, or to the entire discovery message, or in the case of integrated discovery, to the entire DCR message.

[0571] In some embodiments, DP_S-UE to UE or DP_UE to UE-T refers to a set of keys or security keying materials used to protect discovery messages in a hop-by-hop manner, for example, keying materials associated with a relay service code.

[0572] In some embodiments, DP_S-T refers to a set of keys or security key material used to protect discovery messages in an end-to-end manner, for example, key material associated with a ProSe restricted code.

[0573] In one embodiment, the terminal UEs (source UE and target UE) are provided / configured with policies / indicators, such as direct_discovery_security_indications, which indicate, for example, whether the direct discovery set is protected by its own set of security material (e.g., associated with ProSe restricted codes), and / or which type of protection (e.g., encryption, scrambling, integrity) is applied, and which fields (e.g., integrity protection on the entire direct discovery set (e.g., source UE user information ID, target UE user information ID, and integrated discovery indication), and privacy / confidentiality protection by encryption / scrambling applied only on privacy-sensitive fields (e.g., source and target user information IDs)).

[0574] In one embodiment, the UE may be configured with a first key set and a second key set and a policy, and the UE may protect the first message based on the first key set and the policy for delivering the first protected message, and the UE may then protect the first protected message based on the second key set and the policy for delivering the second protected message, and the second protected message is then sent by the device.

[0575] According to clause 6.4.3.7.4 of TS23.304, the user information ID of the target 5G ProSe terminal UE is an optional field in the DCR message with integrated discovery. Therefore, if the user information ID of the target terminal UE is included and the DCR message (with integrated discovery) is not protected, the privacy-sensitive information of the source UE and the target UE (e.g., the user information ID, and the link between them, i.e., the fact that the source UE is trying to establish a link with the target UE) may be compromised. This may also occur if the UE-to-UE relay is not trusted. Therefore, in one embodiment, when the source UE includes the user information ID of the target UE, the DCR message (with integrated discovery) may need to be protected, for example, end-to-end between the source UE and the target UE. In other words, the protection of the DCR message may depend not only on the coverage status of the UE-to-UE relay or on the type of security procedure to be used in the security setup of the PC5 communication link, but also on the content of the DCR message as constructed by the source UE.

[0576] In an embodiment variant, the source UE may trigger protection of the DCR message (with integrated discovery) if either or both of the following occur:

[0577] - The source UE includes the target UE user information ID in the DCR message with integrated discovery.

[0578] - The source UE selects a secure link establishment procedure for network assistance.

[0579] In an embodiment variant, where both conditions of the previous embodiment are met, the security procedures defined in 6.3.5 of TS 33.503 are reused to protect DCR messages with integrated discovery, where privacy sensitive information (e.g., RSC, PRUK-ID, source, UE-to-UE relay, and user information ID of the target UE) is protected for confidentiality, and the DCR message is integrity protected. Since clause 6.3.5 of TS 33.503 can only protect up to 256 bits, the confidentiality key can be used in conjunction with the NEA algorithm to protect payloads longer than 256 bits.

[0580] In a variant embodiment, if the source UE includes the user information ID of the target UE in the DCR message with integrated discovery, wherein the RSC associated with a disabled network assisted security indicator is used, at least the security procedure defined in 6.1.3.3.2.2 of TS 33.503 and including at least step 2 is reused to protect the DCR message with integrated discovery with two key sets, wherein the discoverer UE is the source UE and the UE to be discovered is the target UE, the solicit discovery message is replaced by the DCR message with integrated discovery, a first key set associated with the Prose service code is used to protect the end-to-end discovery elements, such as the user information ID of the source UE and the target UE, and a second key set associated with the Relay service code is used to protect the DCR message with integrated discovery.

[0581] In one embodiment variant, if the source UE includes the user information ID of the target UE in a DCR message with integrated discovery, where an RSC associated with a disabled network-assisted security indicator is used, the security procedures defined in 6.3.5 of TS 33.503 are reused to protect the DCR message with integrated discovery, where privacy-sensitive information (e.g., RSC, source, UE-to-UE relay, and user information ID of the target UE) is privacy / confidentiality protected and the DCR message is integrity protected based on a set of keys associated with the RSC (e.g., DUIK, DUCK, DUSK).

[0582] In a related embodiment variant, if the source UE is opted in for network-assisted security procedures, only UE-to-UE relays within 3GPP coverage can securely process DCR messages broadcast by the source UE. The UE-to-UE relay can identify whether the security procedure is network-assisted or based on a network-assisted security indicator associated with the RSC used in the DCR message. For example, if the UE-to-UE relay is out of coverage and receives a DCR message with an RSC associated with an enabled network-assisted security indicator, it discards the DCR message, otherwise, it processes the message and uses network assistance to initially establish a secure hop-by-hop link with the source UE.

[0583] In a related embodiment variant, once the UE-to-UE relay (re-)broadcasts a DCR message (e.g., intended for a target UE), the target UE may determine whether to securely 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 enabled network-assisted security procedure, the target UE may provide its PRUK-ID (or SUCI) to the UE-to-UE relay so that the UE-to-UE relay uses network assistance to establish a secure hop-by-hop link with the target UE.

[0584] In an embodiment variation, a target UE that does not have appropriate credentials (eg, valid long-term credentials) and / or prefers network-assisted security procedures may not reply / react to a DCR message that includes an RSC associated with a disabled network-assisted security indicator.

[0585] In an embodiment, if the source UE includes the target UE's user information ID in the DCR message with integrated discovery, this should have no impact on whether UE-to-UE relay security processes the DCR message.

[0586] In a related embodiment, the target UE may decide to securely process the DCR message based on, for example, whether the DCR message is intended for it. For example, a target UE with limited resources may be pre-configured to establish a PC5 communication link (e.g., directly or via UE-to-UE relay) only with a UE requesting its service (e.g., a source UE), such as a UE that includes an identifier corresponding to the target UE (e.g., a user information ID or a destination layer 2 ID) in the DCR message.

[0587] In a related embodiment, in a first stage, a target UE, for example, having limited resources to receive a DCR message, may attempt to determine whether its user information ID and / or destination layer 2 ID is included in the integrated discovery message based on, for example, the message size. For example, if the integrated discovery message size indicates that an identifier (e.g., user information ID / destination layer 2 ID) is not included, the target UE may discard the DCR message.

[0588] In a related embodiment, if the target UE successfully performs a size check to determine whether the identifier is included, it may proceed to check the selected security procedure (e.g., based on the included RSC and the state of the network-assisted security indicator associated therewith). Based on the results of the check against its preferences, the target UE determines whether to continue processing the DCR message or discard the DCR message (e.g., if the security procedure is not supported, for example, due to non-valid / expired credentials).

[0589] In one embodiment variant, the target UE may first extract and process a direct discovery set including user information IDs of terminal UEs (e.g., source UE and target UE), and then determine whether to process or discard the DCR message based on whether the user information ID of the target UE included in the direct discovery set matches his user information ID.

[0590] These embodiments / checks may be performed individually, as they may be combined. When combined, they may be performed in a different order, and / or some of them may be skipped depending on the configuration of the target UE (e.g., preferences, requirements, credential availability, coverage status, etc.).

[0591] In an embodiment variant, if the source UE selects for a network assisted link establishment procedure and also includes the target UE's user information ID in the DCR message, the latter may be protected as described in other embodiments, e.g. Figure 2 The procedure described in .

[0592] In one embodiment variant, the source UE may select a network-assisted link establishment process and send an integrated discovery message. However, the integrated discovery message (i.e., a DCR message with integrated discovery) may also be received directly by the target UE. Therefore, in order to address this situation, it may be necessary to provide a policy to the target UE to determine how to communicate with the source UE, for example, by requesting or replying to allow direct communication between 82n82 with a waiting / preferred relay for communication, where PC5 security is established with network assistance. For example, the target UE may be configured to wait for the DCR message to be relayed by providing a network-assisted UE-to-UE relay, and select a path that supports the selection of the source UE (i.e., link establishment via a UE-to-UE relay with network assistance). Alternatively, if the target UE is able to decrypt / descramble / integrity verify the integrated discovery message, it may be configured to attempt to establish a link directly with the source UE.

[0593] In one embodiment, if the terminal UE (source UE and target UE) is provided with or configured to use only one set of security material (e.g., relay_discovery_security_indication is enabled and direct_discovery_protection_indication is disabled), the terminal UE uses the provided security key associated with the RSC to protect the DCR message with integrated discovery.

[0594] The processing at the UE (source, target and UE-to-UE relay) can be similar to the processing using two sets of security materials described above, with slight changes. They can be described in the following embodiments:

[0595] In an embodiment variant, when the DCR message is protected with a set of security materials, the processing at the source UE may involve the following steps:

[0596] 1. Construct a message M, which includes direct discovery set elements, such as source UE and target UE user information IDs, 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).

[0597] 2. If provided / configured in the UE-2-UE code send security parameters, the message M may be integrity protected using a MIC calculated using the DUIK associated with the RSC. The MIC is inserted into the message M.

[0598] 3. The privacy sensitive fields in message M (eg source UE and target UE user information ID) are protected by the confidentiality of DUCK / DUSK as configured in the UE-2-UE code transmission security parameters. This results in a protected message pm.

[0599] 4. Privacy-sensitive fields in pm2 that may need to be more easily accessible for performance reasons (e.g., RSC) may be scrambled, resulting in a scrambled protected message spm, where spm is a protected DCR message with integrated discovery that may be sent by the source UE.

[0600] In a variant embodiment, the ProSe service information may also be privacy protected in step 3 .

[0601] In an embodiment variant, step 2 may be applied only to the discovery set integrated in the DCR message, or to the entire DCR message (ie, integrating the discovery set and other specific DCR fields, such as security information).

[0602] In another embodiment, when processing a received integrated DCR message protected with one set of security materials, the processing at the target UE may be as follows:

[0603] 1. Obtain pm by descrambling the message spm using the UE-2-UE code received security parameters (e.g., DUSK) or keys associated with an existing security context with UE-to-UE relay.

[0604] 2. Remove the confidentiality of pm by receiving security parameters (e.g., DUCK) using the UE-2-UE code or keys associated with the existing security context of the UE-to-UE relay to obtain m and MIC.

[0605] 3. Verify the integrity of m by using the received m, the received MIC and the UE-2-UE code reception security parameters (e.g., DUIK) or the existing context with UE-to-UE relay. If the MIC verification is successful, remove the MIC, thereby obtaining M.

[0606] In an embodiment variant, the target UE may receive the SPM directly from the source UE, in which case the same processing steps described above apply.

[0607] In another embodiment, when processing a received protected integrated DCR message protected by one set of security materials, the processing at the UE to UE relay may be as follows:

[0608] 1. Check whether the relay indication is included. If not, the relay discards the DCR message.

[0609] 2. Steps 2, 3 and 4 are similar to steps 1, 2 and 3 of processing a protected DCR message by the target UE, but the security material is sent using a code.

[0610] A new message M (eg, M') is constructed 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.

[0611] Steps 4, 5 and 6 are similar to steps 2, 3 and 4 of source UE protection of DCR message with integrated discovery, where the UE-to-UE relay user information ID is also privacy protected (e.g., encrypted), while the RSC can be scrambled, resulting in a scrambled or protected message M', spm'.

[0612] Spm' is a protected DCR message with integrated discovery, which is sent by UE-2-UE relay to the target UE.

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

[0614] According to the general definition of this embodiment, a method and apparatus that can be implemented in a target user equipment (UE) are proposed, so that the apparatus:

[0615] – receiving one or more Direct Communication Request (DCR) messages, such as DCR messages with integrated discovery, from a source UE and / or one or more UE-to-UE relays,

[0616] - Determine how to process and / or prioritize received DCR messages, and / or select a communication path, e.g., to a source user equipment, based on configured policies, where the policies may prioritize:

[0617] UE-to-UE relay with established security context; or

[0618] · Establishing a secure link with fresh security material using and through a UE-to-UE relay; or

[0619] • Setting up a direct link with the source UE.

[0620] In another general definition of this embodiment, a method and apparatus that can be implemented in a UE-to-UE relay are proposed, so that the apparatus

[0621] – Receive, for example, a Direct Communication Request (DCR) message with integrated discovery from the source UE

[0622] - Process the received DCR message and determine whether it can identify the target UE by an identifier (e.g., the target UE user information ID or the destination layer 2 ID of the target UE)

[0623] -Determine how to establish a secure link with the target UE based on a configured policy, where the policy may prioritize:

[0624] • Re-use of security material associated with an established security context to protect messages to be relayed to a target UE, if such a context exists between the UE-to-UE relay and the target UE.

[0625] • Protect the DCR message using the discovered security material and establish a secure link with the target UE using the fresh security material.

[0626] The embodiments can be appropriately combined with each other.

[0627] Verification of messages from remote UE (terminal UE) at (U2N) relay

[0628] In some scenarios, when a remote UE (after discovery) sends a DCR message to a UE-to-network (U2N) relay, the U2N relay verifies the integrity of the received parameters (e.g., RSC). A similar situation may also occur in a UE-to-UE relay scenario when a terminal UE sends a DCR message to a UE-to-UE relay. This integrity verification may be performed as described in the above embodiments or as described in TS33.503 clause 6.3.5. However, if the integrity verification fails, the U2N relay currently does not have a means to notify the remote UE of the failure, so the remote UE will keep retrying until the maximum number of retries is reached. This causes unnecessary delays when establishing a communication link between the remote UE and the CN on the U2N relay. A potential solution is for the U2N relay to send a failure (or rejection) message when the integrity check fails. However, due to the integrity check failure, the U2N relay may not perform integrity protection on such a failure / rejection message. This means that an attacker can use such unprotected failure messages to launch a DoS attack in a very simple way: when a remote UE tries to connect to the U2N relay, the attacker has to just send an unprotected failure message to the remote UE and the latter will simply drop the communication.

[0629] A similar situation also applies to the direct link establishment procedure from UE to network relay, for example. When the U2N relay receives a direct link establishment request in the direct security mode procedure, a similar situation may occur when verifying the direct security mode command message or the direct security mode complete message.

[0630] These specific scenarios can be summarized as a first device attempting to connect to a second device by sending a first message that includes, for example, an identifier (such as a service identifier or session identifier) ​​or a message integrity check (such as a MIC). When the second device receives the first message and processes it, if the identifier check or the integrity check fails, the second device may be instructed not to reply. In this case, the first device is forced to wait (e.g., until a timer expires) and retry. The first device may need to repeat this operation (wait and retry) up to N times, where N may be configurable. The specific potential solutions described above can also be applied to this more general scenario: when the identity or integrity check fails, the second device may need to send a failure (or rejection) message. As previously mentioned, this failure message may not be integrity protected, so the failure message may be abused to launch a DoS attack.

[0631] Therefore, the object is to deal with this security issue and still allow more efficient options than having the first device wait and retry.To achieve this object, the following embodiments are proposed.

[0632] Note that, in general, in the following embodiments:

[0633] 1. U2N relay and remote UE may refer to a second device and a first device, respectively.

[0634] 2. The DCR message may refer to a first message sent by a first device,

[0635] 3. RSC may refer to an identifier such as a session or service identifier.

[0636] 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 succeeds, the U2N relay sends an acceptance message (or success message). This has the following advantages: the remote UE can distinguish the situation when the message is accepted and when the message verification fails.

[0637] In one embodiment, when the integrity verification of the DCR message succeeds, the U2N relay sends an acceptance message (or success message), and when the integrity verification of the DCR message sent by the remote UE fails, no failure message is sent. This has the advantage that the remote UE can identify the situation where the message is accepted.

[0638] In a related embodiment, the accept message is integrity protected and the fail message is sent without integrity protection.

[0639] In an embodiment, the Accept message may be integrity protected in a similar manner as the DCR message (eg, same algorithm and / or integrity key).

[0640] In one embodiment, integrity protection of the accept message is accomplished by including the RSC and encrypting it using the key selected for encryption in the DCR message.

[0641] In one embodiment, integrity protection of the accept message is accomplished by including a MIC (eg, a MIC calculated using the NIA algorithm) and an integrity key (eg, a DUIK) associated with the RSC and used in the DCR message.

[0642] In one embodiment, integrity protection of the accept message is accomplished by including a MIC computed using a KDF that takes as input the DUIK associated with the RSC and used in the DCR message.

[0643] In one embodiment, integrity protection of the acceptance message is done by adding a digital signature calculated with a private key owned by the second device and whose public key is (pre)configured in the first device.

[0644] In one embodiment, the algorithms and / or keys used to protect the accept message are configured by a management entity (eg, a CN in a telecommunications system).

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

[0646] In one embodiment, the MIC of the accept message is calculated by taking as input all or part of the received DCR message (eg, RSC, MIC, PRUKID, ...).

[0647] In one embodiment, the MIC of the accept message is calculated using as input a time-based counter (eg, UTC-based) or a random number (eg, received in a DCR message or determined when the accept message is sensed).

[0648] In one embodiment, the freshness of the received message may be verified based on a random number (implicit (eg, MIC) or explicit (eg, random value)) included in the DCR message or a UTC-based counter. The implicit random number may be the MIC used in the DCR message.

[0649] In one embodiment, the MIC in the Accept message is calculated by taking the MIC of the received DCR message as input to the generation of the MIC in the Accept message. The MIC of the DCR message is a "fingerprint" of the DCR message itself, and if the MIC is calculated based on a UTC-based counter, it is also bound to a time value (i.e., its value changes over time). The advantage of this approach is that the DCR message and the Accept message are bound, which reduces CPU overhead since the MIC is required as input, and provides both integrity and freshness protection.

[0650] In a related embodiment, the accept message is integrity protected and the fail message is also sent with integrity protection.

[0651] In an embodiment, the failure message is integrity protected, for example, in a manner similar to the embodiment described above for the acceptance message.

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

[0653] In one embodiment, the U2N relay has a policy / configuration so that the U2N may not send a rejection message in the following cases:

[0654] - a second DCR message (second "first message") is received (e.g., from an attacker posing as a remote UE), and

[0655] - The second DCR message cannot be integrity verified

[0656] If previously

[0657] - a first DCR message (first "first message") has been received, and

[0658] The first DCR message is successfully integrity verified.

[0659] In one embodiment, the U2N relay has a policy / configuration so that the U2N may not send a rejection message in the following cases:

[0660] - receiving a second DCR message (second "first message"), and

[0661] - The second DCR message is successfully integrity verified

[0662] if

[0663] - a first DCR message (first "first message") has also been received (e.g., from an attacker posing as a remote UE), and

[0664] - The first DCR message cannot be integrity verified

[0665] In a related embodiment, the U2N relay has a policy / configuration to determine whether to send a rejection message based on the receipt of one or more "first messages", at least one of which is successfully authenticated.

[0666] In an embodiment related to the aforementioned embodiment, the U2N relay may have a policy / configuration for sending a notification to a remote UE or NF in the CN to notify an event.

[0667] In a related embodiment, the U2N relay has a policy to prioritize the "first message" that is successfully authenticated, regardless of whether it is the first or second "first message" (DCR message).

[0668] In a related embodiment, the U2N relay has a policy / configuration that specifies not to send a rejection message if the time between receipt of a first DCR message (first first message) and a second DCR message (second first message) is less than a predetermined time (eg, T1 seconds).

[0669] This embodiment and the previous embodiments have the advantage of preventing an attacker from forcing the U2N relay to send a protected reject message by sending / replaying a manipulated DCR message (eg the same first DCR message with some errors) shortly after the remote UE has sent the DCR message.

[0670] In an embodiment, if the reject message cannot be integrity protected, for example, where the U2N relay does not find a suitable integrity key to protect the reject message, the U2N relay may have a configuration / policy that determines that the U2N relay should not send a reject message.

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

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

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

[0674] In an embodiment, the U2N relay may not include the identifier in the reject or accept message.

[0675] This has the advantage of providing higher privacy when indicating denied service, at the expense of the remote UE having to perform a blind search (trying multiple integrity keys).

[0676] In a related embodiment, the remote UE has a policy such that a rejection message is not accepted if a DCR message has not been previously sent within the last time (e.g., T2 seconds) (no first message) and / or there is no ongoing related communication process where a rejection message may be expected.

[0677] This has the advantage of preventing an attacker from forcing receipt of a false rejection message.

[0678] In a related embodiment, a remote UE expecting a protected reject message may have a policy that determines that the reject message should be discarded / ignored if the remote UE does not have a suitable key to perform integrity verification on the reject message. If the protected reject message does not include an identifier, such a policy may allow / prevent the UE from performing a blind search based on, for example, the type of UE and / or time / computation constraints.

[0679] In a related embodiment, a mechanism is described for integrity protecting reject messages (eg, direct communication reject messages and direct security mode reject messages) when a key such as a DUIK is provided for discovery.

[0680] In this embodiment, if the first message cannot be integrity verified (eg, the direct security mode command process fails), protection of the reject message (eg, direct security mode reject message) is performed as follows.

[0681] The protection and / or sending of a reject message may be subject to policy / configuration. For example, it may be subject to one or more conditions such that a U2N relay may not protect and / or send a reject message if:

[0682] The previous first message (e.g., Direct Security Mode Command procedure) has succeeded, including integrity verification;

[0683] said previous first message was received / successfully verified within said last T1 seconds;

[0684] There is established communication;

[0685] ·…

[0686] If the U2N integrity protection rejects the message, the U2N relay does so by sending security parameters using the code used for discovery.

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

[0688] 2. Compute the Message Integrity Check (MIC) using a KINT-based, UTC-based counter via the KDF as in the above embodiments.

[0689] As in the above embodiments, the process may benefit if the rejection message includes an RSC or an identifier linked to the DUIK (or integrity key to be used) so that the recipient can determine the DUIK to use.

[0690] As in the above embodiment, the process may benefit if the rejection message includes (the fingerprint of) the first message whose verification failed, so that if multiple first messages are sent the remote UE can link the messages and for example better determine the cause of the failure.

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

[0692] The U2N relay may have a configuration / policy that determines that if the U2N relay cannot be integrity protected, then a reject message should not be sent, and act accordingly.

[0693] When receiving the rejection message, the 5G ProSe remote UE uses the code reception security parameter for discovery to verify the integrity of the received rejection message.

[0694] If the integrity verification of the rejection message fails, the remote UE may have a policy that determines whether it should ignore the rejection message.

[0695] If the message is not integrity protected or is deemed not integrity protected because the remote UE lacks the integrity key, the remote UE may have a policy that determines whether it should process the message, and act accordingly.

[0696] The remote UE verifies the integrity of the received reject message as follows:

[0697] 5.1. If the UE is configured with DUIK, the integrity key KINT is set to DUIK. Otherwise, the reject message is not integrity protected and step 2 is skipped.

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

[0699] As in the above embodiment, the process may benefit if the rejection message includes (the fingerprint of) the first message whose verification failed, so that if multiple first messages are sent the remote UE can link the messages and for example better determine the cause of the failure.

[0700] 2. Calculate the MIC using KINT, a UTC-based counter and the received rejection message through the KDF, and compare the calculated MIC with the MIC included in the rejection message. If they do not match, the integrity check fails.

[0701] 3. Compare whether the RSC and / or MIC in the previously sent direct communication request message matches the rejection reason in the received direct communication rejection message. If they do not match, reject / ignore the direct communication rejection message.

[0702] In an embodiment variant, the fingerprint included in the message may be a MIC calculated by the relay UE that does not match the MIC included in the direct communication message.

[0703] In an embodiment variant, the fingerprint may not be sent explicitly, but it may be implicit. For example, the MIC in the rejection message may be calculated taking the received direct communication message itself as input. The remote UE calculates the MIC itself upon receiving the rejection message using the direct communication messages it has previously sent and the content of the received rejection message. If the MIC calculated locally by the remote UE does not match the MIC in the received rejection message, the remote UE knows that the rejection message was not addressed to the remote UE.

[0704] In an embodiment variant, the rejection message may include multiple MICs, each MIC calculated with a different DUIK, each MIC associated with a different RSC. This requires the (UE to network) relay UE to calculate multiple MICs and send them.

[0705] In an embodiment variant, the rejection message may include a single MIC, where the DUIK used to calculate the MIC is selected according to a policy (eg, the DUIK linked to the RSC during the discovery process of the last exchange / match).

[0706] In an embodiment variant, the remote UE attempts multiple DUIKs associated with multiple RSCs. For example, if the remote UE has attempted to perform discovery using multiple RSCs associated with multiple key materials, the remote UE may attempt to verify the rejection message using all DUIKs used in the last X discovery messages or T seconds, whereby X and T may be configurable.

[0707] In an embodiment variant, direct disclosure of the RSC using the DUIK to protect the rejection message may lead to privacy issues. Therefore, its pseudo-identifier may be used, such as some bits of the previously used discovery message (eg some bits of the MIC).

[0708] In one embodiment variant, if the remote UE receives a protected rejection message including a fingerprint, if the MIC verification of the rejection message fails but the fingerprint in the rejection message matches (i.e., the rejection message includes a fingerprint that matches the fingerprint of a DCR message that the remote UE has sent), the remote UE may attempt to verify the rejection message using another key (DUIK) associated with another RSC configured in the remote UE. This is done to attempt to determine a public key between the remote UE and the relay UE. This has the advantage of allowing the remote UE to determine the public key. If a key is found that allows verification of the MIC, if the remote UE can accept the RSC for the intended communication service that the remote UE wants to access, the remote UE may retry sending a DCR message protected using a key associated with the RSC, or the remote UE may decide to redo the discovery process.

[0709] In an embodiment variant, the fingerprint in the rejection message may be checked before performing the MIC verification. This allows verifying whether the rejection message is intended for a remote UE before performing any cryptographic operations, i.e. it is more efficient.

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

[0711] In an embodiment, the keys intended to protect only failure messages are configured such that multiple device sets or discovery key material or DCR messages or RSCs are common.

[0712] The last embodiment has the advantage that failure messages can be protected and authenticated even if the specific integrity key used to authenticate the DCR message cannot be used in a successful manner.

[0713] In an embodiment, the failure message includes the reason for the failure, such as RSC mismatch and / or MIC failure and / or other parameters that may allow identification of the failure reason, such as time or key time validity (e.g. in case the U2N relay has identified that the remote UE uses old / expired keys). This has the advantage that the remote UE may then select different parameters to send the DCR message and avoid the failure reason and / or triggering any other procedures (e.g. a request to renew / update configured parameters such as keys).

[0714] In one embodiment, the remote UE includes a policy that determines its behavior when: (1) no message is received when sending a DCR message and / or (2) a failure message is received when sending a DCR message and / or (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.

[0715] In a related embodiment, the policy in the remote UE is configured by a management entity (eg, a CN in a telecommunication system), for example, by a NF (eg, a PKMF or a DDNMF) in the CN.

[0716] In a related embodiment, if no message is received before the timer expires (no failure message and no acceptance message), the policy determines that the remote UE should retry sending the DCR message a number of times.

[0717] In a related embodiment, if only a failure message is received, the policy determines that the remote UE should stop retrying to send the DCR message. This may also indicate that the remote UE should search for a different U2N relay.

[0718] In a related embodiment, if an accept message is received and the accept message is correctly verified, e.g., within a (configured) time window, the policy determines that the remote UE should stop retrying to send the DCR message. The UE may then wait for a given time (which may be specified in the policy) to receive further messages from communications with, e.g., the U2N relay and / or the CN (e.g., authentication process) via the U2N relay.

[0719] In a related embodiment, if both a Failure message and an Accept message are received and the Accept message is correctly verified, the policy determines that the remote UE should stop retrying to send the DCR message. The UE should then wait (e.g., a configured time) to receive further messages from communications with the CN (e.g., an authentication process), for example, via U2N relay. This has the advantage of letting the remote UE handle potential attacks (e.g., if an attacker abuses an unprotected Failure message) and improving performance by giving the Accept message a higher priority / importance via the Failure message (by explicitly signaling that the message is correctly verified via the Accept message).

[0720] In a related embodiment, if only unprotected failure messages are received (e.g., an attacker abuses the failure messages), the policy may determine a timer during which the remote UE should not retry sending a DCR message. If an accept message is received before the timer expires and it is correctly authenticated, the accept message is prioritized.

[0721] In a related embodiment, if only unprotected failure messages are received (e.g., an attacker abuses the failure messages), the policy may determine a timer during which the remote UE should not retry attempts to establish communications with the U2N relay. If an accept message is received before the timer expires and it is properly authenticated, the accept message is prioritized, e.g., communications may continue ignoring the failure message.

[0722] In a related embodiment, the acceptance message may be an explicit message. In other words, it is a message sent with the primary purpose of notifying the remote UE that the integrity verification at the U2N relay is successful.

[0723] In a related embodiment variant, the acceptance message may be implicitly sent via another protected message Y. In other words, if the UE receives the next protected message, the acceptance message is implicitly included (or deemed to have been received). In other words, the acceptance message may be represented by a protected message Y sent by the U2N relay to the remote UE, wherein the protected message Y is sent for a given purpose, such as conveying certain parameters, performing authentication, etc. Such a message may be directly from the UE to the network relay to the remote UE, or may be sent via the U2N relay, for example, when the UE to the network relay forwards a message originating from a third device (e.g., in the core network) to the remote UE. In other words, the purpose of message Y is not only to inform the remote UE that the integrity verification of the U2N relay is successful. If the remote UE receives the message Y, the remote UE implicitly understands that the UE to the network relay is able to verify the DCR message. In the context of other embodiments, if the remote UE receives the protected message Y and the unprotected failure message, the remote UE may prioritize the protected message Y and ignore the unprotected failure message according to a (pre)configured or hard-coded policy.

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

[0725] In an embodiment, the remote UE implements a routine to verify the integrity and / or freshness of the acceptance and / or failure messages as a counterpart to the above-described embodiments.

[0726] In an embodiment, the U2N relay implements routines to verify the integrity and / or freshness of acceptance and / or failure messages as counterparts to the above-described embodiments.

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

[0728] In some cases, an attacker may forge an unprotected failure message, for example, with the goal of preventing a remote UE from connecting to a U2N relay. In telecommunication systems that rely on medium access control coordinated by the RAN, the RAN oversees the performance of resource allocation, for example by means of control messages. In the specific case of a remote UE and a U2N relay, a device connected to the remote UE via a sidelink may also perform local resource allocation, for example using a common resource pool. Therefore, the above problem may also be addressed by improving / monitoring how resource allocation is performed.

[0729] In one embodiment, the transmission of the DCR message and the allocation of resources for the subsequent reply with a failure message or an acceptance message are performed simultaneously. This is advantageous because an attacker has less room to inject arbitrary messages.

[0730] In a related embodiment, the device (remote UE and / or U2N relay and / or RAN and / or CN) monitors that resources are not allocated in an abnormal manner, for example, by monitoring that no message is sent for transmitting a message to the remote UE.

[0731] In a related embodiment, the device may trigger an alarm if resources are allocated in an abnormal manner, wherein the alarm may be sent to, for example, the CN or a remote UE.The above embodiments may be implemented by a computer program executed in a remote UE or in a U2N relay.

[0732] Identifies the key used to decrypt / integrity verify the DCR message

[0733] The fact that a UE relay may not be able to perform integrity verification on messages such as DCR messages may be due to the UE relay not knowing which keys to use. Therefore, in order to alleviate the problem of having a U2N (or UE to UE) relay receiving a message (e.g., a protected DCR message as in other embodiments) from a remote UE (or terminal UE), and after decrypting the RSC in the message, the relay cannot match the RSC (generally, the integrity verification message) with the RSC sent in the discovery message, the following embodiments are proposed, which can be combined with other embodiments (e.g., sending a failure / rejection message) and / or used independently, specifically, the relay UE can take one or more of the following actions:

[0734] - matching the decrypted RSC to an RSC or list of RSCs sent in one of the previous discovery messages (i.e., the decrypted RSC matches the RSC sent in a discovery message), e.g., in the last X discovery messages, where X is configurable, or in the last discovery messages sent within T seconds (where T is also configurable), and / or

[0735] - Match the decrypted RSC to an RSC or list of RSCs that was sent / received in one of the previous discovery messages within the last t seconds, where t is configurable, and / or

[0736] - Match the decrypted RSC to any RSC supported by the relay.

[0737] Note that matching the decrypted RSC with an RSC sent in one of the previous discovery messages and / or supported by the relay may require multiple decryption messages, e.g., using a discovery key associated with each of those RSCs. This embodiment may make the use of failure / reject messages less necessary and / or frequent. And this may be advantageous.

[0738] Note that in the following embodiments, when referring to a type of relay (eg, UE-to-network relay), the embodiments may also be applicable to other types of relays.

[0739] In one embodiment variant, a terminal device (e.g., a remote UE) may signal an identifier (e.g., its layer 2 ID) to a relay (e.g., a UE-to-network relay) in a direct communication request (DCR), where the identifier may be bound to the device (e.g., the layer 2 ID) and / or the RSC used by the device during discovery (e.g., the least significant bits of the MIC in the discovery message). The remote UE may also include the identifier (e.g., the layer 2 ID) in the DCR message to enable the relay (e.g., U2N) to identify the RSC and subsequently enable security key material for decryption, RSC matching, and integrity verification. In this embodiment variant and the related embodiment variants below, the relay (e.g., a UE-to-network relay) may need to track the RSC and identifier used by the remote UE / terminal UE during the discovery process so that when a DCR message including the identifier is received, the relay UE can check which RSC to use.

[0740] In one embodiment variant, the remote UE may attempt PC5 security establishment of 5G ProSe UE-to-network relay communications on both the user plane and the control plane, and the UE-to-network supports two security procedures. The UE-to-network relay may match two RSCs indicating the security procedures, and therefore the remote UE may send a DCR message to initiate either of them. When the remote UE sends a DCR message (including its layer 2 ID) and one of the RSCs protected by the corresponding key material, the UE-to-network relay may select the wrong RSC and subsequently select the wrong security key material, resulting in an RSC mismatch / integrity verification failure. To address this issue, the UE-to-network relay may perform blind decryption / verification of the received DCR message using the security key material associated with the RSC, which in turn is associated with a device identifier (in this case, the layer 2 ID of the remote UE) and has been stored by the UE-to-network relay.

[0741] In another embodiment which may be combined with the previous embodiment or used independently, the layer 2 ID of the remote UE may not be changed / updated during the PC5 link establishment procedure or between the discovery procedure and the direct link establishment procedure, so that the previous embodiment may operate without problems.

[0742] In one embodiment variant, the user information ID of the remote UE may assume a similar role as the layer 2 ID in the previous embodiment, i.e., the UE-to-network relay may perform blind decryption / verification of received DCR messages using the security key material associated with the RSC associated with the user information ID of the remote UE.

[0743] In a related embodiment that addresses the above issues, how the U2N relay performs matching is specified according to a policy (similar to other embodiments), which may be configurable, for example, depending on the number of supported RSCs.

[0744] In a related embodiment to solve the above problem, the policy (as in other embodiments) may further specify whether the U2N relay sends a failure message and / or an acceptance message.

[0745] Depending on how RSC matching is performed, implicit or explicit protection or no protection is performed.

[0746] In another related embodiment that addresses the above-mentioned problem with 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 (e.g., a remote UE), and after decrypting the RSC in the message, the U2N relay cannot match the RSC with the RSC sent in a discovery message (typically, an integrity verification message), the 5G ProSe remote UE and the 5G ProSe UE-to-network can use a portion of the discovery message (e.g., the least significant bits (e.g., the least significant k bits, where k is (pre-)configured by the network or indicated in the message), the k bits of a scrambled message, or the encrypted RSC exchanged in the discovery message, etc.) to identify the discovery key material to be used when protecting the direct communication message. For example, if a remote UE and a UE-to-network relay (similar procedures may apply to other relay procedures) participate in two discovery procedures, e.g., associated with two different relay service codes RSC1 and RSC2, wherein for each discovery procedure, the remote UE and the relay UE exchange discovery messages according to model B, the two UEs may store, e.g., a field of k=12 least significant bits (e.g., MIC or encrypted RSC, ...) in the second discovery message in model B for the two discovery procedures associated with RSC1 and RSC2. In the first discovery procedure, the MIC may be 0xABCD, and in the second discovery procedure, the MIC may be 0x12EF, and then the two UEs may retain the table:

[0747] RSC1,0xBCD

[0748] RSC2,0x2EF

[0749] If the remote UE decides to send a Direct Discovery Request (DCR) message associated with RSC1, the remote UE will protect the DCR message with the discovery key associated with RSC1. To indicate this in a privacy-sensitive manner, the message includes the identifier IDX 0xBCD in the message in plain text. The relay UE can then receive the message, extract the identifier IDX, and use it to look up a table to determine which RSC it is associated with (RSC1 in this example) and retrieve the corresponding key, such as DUCK, DUIK, DUSK associated with RSC1, that allows the message to be processed correctly. This method also applies when two different remote UEs perform two discovery procedures in parallel with the same relay UE. This method also applies to the same UE-to-UE relay when the source UE performs two discovery procedures in parallel using an RSC that supports two security procedures (with and without network assistance). This method allows the keys used in the discovery phase to be linked with the keys used to protect subsequent messages (e.g. DCR messages, rejection messages) in a privacy-sensitive manner before the PC5 security context is established.

[0750] Note that after this is done, it may not be necessary to include the RSC in the DCR message, as 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 whether the decrypted RSC matches the RSC linked to the IDX.

[0751] In another related embodiment, the indication of the security key used may also be exchanged in other messages and calculated in a different manner. For example, the indication or key identifier may be included in the failure message. For example, the indication may be calculated as the least significant bits of the output of a key derivation function with the used key (e.g., the used DUIK) and a time counter as input.

[0752] CT1 LS C1-234362 describes a problem in a remote UE to UE to network relay PC5 link establishment scenario where the UE to network relay is required to retrieve security key material to decrypt and verify the PRUK-ID and RSC. However, the security key material is associated with the RSC, which is sent encrypted in the DCR message. Therefore, the UE to network relay cannot identify which RSC to use, and subsequently which security key material to use to process (e.g., decrypt, integrity verify) the received DCR message. This problem is similar to the problem discussed in the previous embodiment. To solve this problem, a potential approach may be as follows: During the discovery request process, Figure 6In step 4 of .1.3.2.2.1-1 and 6.1.3.2.2.2-1, the 5G DDNMF in the HPLMN of the notifying UE (model A) / discovered UE (model B) returns a key identifier associated with the discovery security material to the notifying UE / discovered UE. The key identifier is also transmitted to the HPLMN of the monitoring UE / discoverer UE (in step 9) and the monitoring UE / discoverer UE obtains the discovery security material and its identifier by relaying the discovery key response, corresponding to steps 10 and 11 of the aforementioned figures, respectively. It is then proposed to include the key identifier in plain text in the DCR message to identify the security key material used to protect the DCR message. The key identifier may also be included in the discovery messages exchanged during the discovery phase. The use of key identifiers has been discussed in previous embodiments. However, this approach may compromise the privacy of the UE, especially when the discovery security material is reused. Since the key identifier is fixed and transmitted in plain text, an eavesdropper can identify when a certain set of security materials is used and through which UEs they are bound to the RSC. Furthermore, if the key identifier is also exchanged during the discovery phase, it can be used as an equivalent of the RSC and therefore, if it is exchanged unprotected, it will affect the privacy of the end UE / user. To address these issues, the following embodiments are considered, which may be applicable to UE to network relays, but also to UE to UE relays:

[0753] In an embodiment variant, the key identifier associated with the discovery security material can be rotated based on conditions (e.g., time, one-time use) that can be configured by the network. For example, the key identifier can be updated / rotated every hour, thereby ensuring that the key identifier is dynamic.

[0754] In an embodiment variant, the remote UE may include the entire key identifier or only a portion thereof (e.g., b LSBs / MSBs) in the DCR message, and in the latter case, the UE-to-network relay may transmit, for example, b MSBs / LSBs corresponding to the same key identifier in response to the remote UE. These MSB / LSB identifiers may be included, for example, in DCR messages and rejection messages.

[0755] In another embodiment variant similar to the other embodiments described above and which may be combined with the previous embodiments, a key identifier may be calculated based on discovery security material and a UTC-based counter fed as input to a KDF, whereby the last b bits of the KDF output are used as the key identifier, which remains valid for, for example, one hour or until it is used.

[0756] In another embodiment, the network (e.g., PKMF, DDNMF, ...) can calculate a list of pseudo IDs based on the provided discovery security material and time period and assign them to UEs (e.g., remote and UE-to-network relay UEs) so that each pseudo ID is valid during a specific time period. This list of pseudo IDs can be calculated as described in the previous embodiment or randomly.

[0757] In a related embodiment that may be combined with or used independently of other embodiments, a UE (e.g., a remote UE and a UE-to-network relay) provided with a list of pseudo IDs may select a key pseudo ID to be used (e.g., included in a DCR message) based on its current timestamp, whereby the timestamp falls within the time range corresponding to the pseudo ID.

[0758] In another embodiment variant, when equipped with discovery security material, a list of pseudo-IDs may be calculated and stored by the UEs (e.g., remote UEs and UE-to-network relays), wherein the b LSBs of a UTC-based counter may be set to zero so that small time differences do not result in different pseudo-IDs ending up at the UEs (remote UEs and UE-to-network relays).

[0759] In another embodiment variation, a UE (eg, a remote UE and a UE-to-network relay or a UE-to-UE relay) may try adjacent / close / subsequent pseudo-IDs to avoid rejecting messages due to time synchronization issues.

[0760] In another embodiment, in case the pseudo ID associated with the discovery security material is updated / changed during the direct communication phase, the UE-to-network relay may not be able to match the pseudo ID transmitted in the DCR message with the updated pseudo ID. In this case, the UE-to-network relay may attempt to match the received pseudo ID with a (previously valid) pseudo ID corresponding to a previous time period.

[0761] In another variation similar to the above-described variation of another embodiment, it is important to retain a list of matching / authorized RSCs and / or key identifiers during the initial discovery phase so that only DCR messages containing a key identifier in the list or bound to one of the matching / authorized RSCs in the list are also authorized. To this end, as shown in the previous embodiment, a relay UE (e.g., a UE to network relay) can track (via a list) the RSCs that matched in the last k discovery messages or within the last T seconds, where k and T are configurable. When the relay UE receives a DCR message with a key identifier, the relay UE can check whether the key identifier corresponds to any RSC stored in the list. The UE relay can only allow DCR messages that include a key identifier / RSC in the list. This is advantageous because it only allows potential authorization checks to be performed during the discovery process.

[0762] In one embodiment, a key identifier used in the DCR message (e.g., a fixed key identifier that may have been configured by the network, and the key identifier is bound to the RSC and discovery key material) may be scrambled with a pseudo-random sequence, for example, pre-configured according to a key or generated from a key, for example, pre-configured or generated using the DUSK in the discovery key material. The UE relay may descramble the message, where the descrambling operation may be performed blindly, i.e., by trying the scrambling keys possessed by the UE and generating a pseudo-random sequence. If the key identifier matches the key identifier bound to the RSC / discovery key material / DUSK used for descrambling, the UE knows that the key identifier is the correct key identifier and may further process the security of the DCR message, i.e., decrypt and integrity verify the DCR message. This embodiment variant may require blind descrambling. Blind descrambling may be improved, for example, by only trying to descramble using the key used in the previously matched discovery message, as in other messages. Scrambling may be accomplished by using a pseudo-random sequence that changes at a low frequency, for example, once an hour. The scrambled key identifier can be calculated as XOR(key identifier, TRUNC(KDF(K, UTC-based counter), b)), where XOR(a, b) returns the bitwise exclusive OR of a and b, TRUNC(a, b) returns the b bits of a, and KDF(K, a) returns the key derivation function in a. Recovery of the key identifier is accomplished by the inverse operation, i.e., exclusive ORing the scrambled key identifier with TRUNC(KDF(K, UTC-based counter), b).

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

[0764] In a general definition of the invention, a method is proposed, by which a discovery security material identifier is bound to a list of authorized relay service codes stored by a second device, wherein the authorized relay service codes stored in the list match relay service codes used in a previous discovery phase and / or are exchanged / used during a time window, whereby the number of discovery phases or time windows is configurable.

[0765] In a general definition, a method is proposed, by which a first device signals to a second device via an identifier which discovery security material to use for processing a DCR or a rejection message / failure message, wherein the identifier is updated periodically / dynamically and / or based on preconfigured conditions and / or in a pseudo-random sequence, whereby said identifier and / or input for calculating the identifier and / or pseudo-random sequence are 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.

[0766] The above described embodiments may represent methods of allowing secure and reliable communications in a telecommunications network.

[0767] The above-described embodiments may represent apparatus that may be implemented in a first device (eg, a remote UE) to achieve secure and efficient operations when connected to a second device (eg, a relay UE).

[0768] The above-described embodiments may represent apparatus that may be implemented in a second device (eg, a relay UE) to achieve secure and efficient operations when providing a connection to a first device (eg, a remote UE).

[0769] Generally, the different embodiments presented in this description can be combined with each other.

[0770] As explained throughout the previous embodiments, the proposed variants of the invention can be implemented in a network, e.g. Figure 5 The cellular network shown is a 5G network. The cells of the network are served by a master station 1000. Under the coverage of the master station 1000 (e.g., a gNB), multiple secondary stations can be connected to the master station. Some secondary stations may be suitable for operating as relay stations 1010. Such a relay station may include a transmitter 1011 coupled to a transmitting antenna and a receiver 1012 coupled to a receiving antenna. Typically, the receiving antenna and the transmitting antenna are the same antenna. In addition, depending on the technology, the antenna can be formed by an antenna array, which can allow different transmit / receive modes, such as MIMO, transmit diversity, and operation on different frequency sets.

[0771] The controller 1013 (e.g., a CPU or a microcontroller (such as a microprocessor dedicated to communication (baseband processor) or a main microprocessor of a device including a UE) operates together with software stored on an internal memory (e.g., ROM, EEPROM, SSD)) is suitable for controlling the transmitter and the receiver and controlling the antenna. It should be noted that some or all of the transmitter, the receiver and the controller may be part of a single baseband processor. In combination with the above-mentioned embodiments, the controller is suitable for establishing a connection between the relay station 1010 and the main station 1000. More specifically, the controller 1013 may configure the receiver 1012 to receive a first configuration parameter set including an attribute or a service code in at least one first security message from the main station 1000.

[0772] The controller 1013 may control the transmitter 1011 to transmit at least one transmitted attribute or service code from the first configuration parameter set. The attribute or service code may be broadcasted for reception by other stations (such as, for example, the secondary stations 1020 or 1030).

[0773] Typically, a relay station can be a UE, such as a sidelink compatible UE, which can therefore behave as a relay station when configured. Alternatively, a relay station can also be another master station, such as an access point, or a gNB or a femtocell gNB.

[0774] The secondary station 1020 (or similar 1030) may be a UE in general and include a transmitter 1021, a receiver 1022, both of which are generally coupled to one or more antennas or antenna arrays. In addition, the secondary station 1020 includes a controller 1023, which is suitable for controlling the receiver 1021, the transmitter 1022 and possibly other elements of the UE. For a relay station, the controller 1023 may be a processor or a CPU and may operate due to software.

[0775] The controller 1023 enables the receiver 1021 and the transmitter 1022 to establish a connection with the master station 1000. This includes, for example, configuring the receiver 1021 to receive from the master station 1000 in at least one second safety message a second set of configuration parameters including attributes or a relay service code linked to an upcoming data exchange with the relay station 1010.

[0776] The receiver 1021 may be adapted to receive at least one transmitted attribute or service code from the relay station 1010, and the controller may be configured to determine whether the transmitted attribute or service code is included in a second configuration parameter set or satisfies a policy therein, and, when it is determined that the transmitted service code is included in the second set, enable the transmitter to establish direct communication with the relay station 1010.

[0777] The secondary stations 1020 and 1030 can also communicate with each other via the relay station 1010 .

[0778] 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.

[0779] The operations described (as shown in the various figures (e.g., Figure 3 and Figure 4 ) can be implemented as program codes by computer programs and / or dedicated hardware of related communication devices or access devices, respectively. The computer program can be stored and / or distributed on suitable media, such as optical storage media or solid-state media, supplied together with other hardware or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

[0780] The above-described embodiments may also be applicable to the establishment of a multi-hop PC5 communication link, wherein a relay (e.g., a UE-to-UE relay) may forward / relay discovery and / or communication messages between terminal UEs and / or between terminal UEs (remote UEs) and networks, taking into account the changes required to adapt the process of the present invention to the multi-hop links. For example, a check is performed at each UE-to-UE relay through which a discovery message is relayed, the check being performed to verify the validity of an end-to-end protected direct discovery set, for example, relayed through multiple relays, and in the case where the kth UE-to-UE relay considers it invalid, the UE-to-UE relay discards the discovery message. For example, in a UE-to-network relay scenario with a relay between a remote UE and a UE-to-network relay, if the RSC does not match or the integrity verification of the message fails in the relay between the remote UE and the UE-to-network relay, a rejection message is sent back to the remote UE by the relay used to establish the link. For example, in order to ensure that the path is retained (i.e., a list of UE-to-UE relays used to establish the link), each relay may store an identifier of the relay from which the message is received, and the relay to which the message is relayed. For example, a relay_indication_counter may be added to the discovery / communication message, such that the counter is updated (e.g., incremented) each time the message is relayed, and in the event that a maximum_limit configurable by the network and / or source UE (e.g., an announcer / discoverer / remote UE) is reached before the discovery / communication information reaches the destination UE (e.g., target end UE / UE to network relay), the message may be discarded. For example, in a UE to network relay scenario, the protection of the DCR message may be adapted to take into account a large number of RSCs that may be used between several relay UEs, while the remote UE identifier (i.e., PRUK-ID / SUCI) that remains intact may be protected end-to-end, for example, between the remote UE and the U2N relay, or protected using hop-by-hop security keys associated with different RSCs used between relay UEs.

[0781] By studying the drawings, the present disclosure and the appended claims, those skilled in the art may understand other variations of the disclosed embodiments, and may realize other variations of the disclosed embodiments when implementing the protected invention. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "one" or "an" does not exclude a plurality. A single processor or other unit may implement the functions of several items recorded in the claims. The mere fact that certain measures are recorded in mutually different dependent claims does not indicate that the combination of these measures cannot be used advantageously. The foregoing description details certain embodiments of the present invention. However, it should be understood that no matter how the foregoing appears in the text, the present invention can be practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of specific terms when describing certain features or aspects of the present invention should not be regarded as implying that the terms are redefined herein as being limited to including any specific characteristics of the features or aspects of the present invention associated with the terms.

[0782] Furthermore, where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is in the sense that a person skilled in the art understands the convention, for example, “a system having at least one of A, B, and C” will include but is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is in the sense that a person skilled in the art understands the convention, for example, “a system having at least one of A, B, and C” will include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Those skilled in the art will further understand that almost any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”.

Claims

1. An apparatus for securely relaying a discovery message from a first device to a third device, wherein: The device is configured to: - receiving from the first device a second discovery protected message protected with a second key set, the second discovery protected message comprising the first discovery message protected end-to-end with the first key set according to a policy or configuration, - cancelling the protection using a second set of keys and verifying the integrity and freshness of the received second discovery protected message, and then extracting the first protected discovery message according to a policy or configuration, - constructing a third discovery message, the third discovery message comprising the first discovery protected message, - protecting the third discovery message as a third discovery protected message using a third key set according to a policy or configuration, - Sending the third discovery protected message to a third device.

2. The device according to claim 1, wherein: The first discovery protected message and the second discovery protected message are respectively associated with a first timing value and a second timing value determined by the policy or configuration, or respectively include a first timing value and a second timing value determined by the policy or configuration, wherein the first timing value has a lower resolution than the second timing value to improve communication reliability.

3. A device according to any one of the preceding claims, wherein: The first discovery protected message is stored with a validity time determined according to: According to the timing value, or According to the number of bits of the timing value, or Depending on the accuracy of the timing value, or According to the index of the most significant bit of the timing value, or is determined as a power of 2, the value of the power being calculated as the index of the most significant bit of the timing value minus 1, or According to the remaining time until the timing value cannot be used to correctly reconstruct the UTC-based counter used for verifying the MIC, descrambling or decrypting, The timing value is included in the first discovery protected message or the second discovery protected message.

4. A device according to any one of the preceding claims, wherein: The first discovery protected message and the second discovery protected message include a MIC, each MIC being calculated according to clause 6.1.3.2.3 in TS 33.

503.

5. A device according to any one of the preceding claims, wherein: The policy or configuration determines that the first protected message is not scrambled.

6. The device according to any one of claims 1 to 4, wherein: The policy or configuration determines that the first protected message is scrambled by setting the b least significant bits of the UTC-based counter to zero, where b can be greater than 4, which is sufficient to ensure that the first protected message can be descrambled if it is buffered for a configurable time greater than 2b seconds.

7. A device according to any one of the preceding claims, wherein: The policy or configuration determines whether the first discovery message and / or the second discovery message or the third discovery message is encrypted or scrambled or integrity protected.

8. A device according to any one of the preceding claims, wherein: If the first discovery protected message received or stored by the apparatus is valid, the first discovery protected message is included in the third discovery message, wherein the validity depends on the validity time of the first discovery protected message and at least one of the following: - the time of constructing said third discovery message, - protecting the time of said third discovery message, - The time at which the third discovery protected message is sent.

9. The device according to any one of the preceding claims, wherein: The condition for sending the third discovery protected message is based on at least one of the following: - time period, - a maximum number of first discovery protected messages included in said third discovery message, -First discovered protected message whose validity period is about to expire.

10. The device according to any one of the preceding claims, wherein: The validity time of the first discovery protected message is determined by the UTC-based timer, or the LSB set of the UTC-based timer, or the number of bits of the timing value associated with the first discovery protected message, or the accuracy of the timing value, or the index of the most significant bit of the timing value.

11. The device according to any one of the preceding claims, wherein: The security operations performed to protect the third discovery message are confidentiality protection, followed by integrity protection, and then scrambling.

12. The device according to any one of the preceding claims, wherein: The apparatus is configured to include one or more of the following in the third discovery protected message: - an indication of the number of first discovery protected messages, - An identifier of the target UE to which each first discovery protected message is addressed.

13. The device according to any one of the preceding claims, wherein: The apparatus is configured to extract a first protected discovery message from the second discovery message by reorganizing and copying redundant message fields contained in the second discovery message.

14. A device according to any one of the preceding claims, wherein: The device is configured with the key set and / or policy or configuration by a network function in the core network.

15. A device according to any one of the preceding claims, wherein: The policy, or parts of the policy, may be hard-coded in the logic of the device.

16. A UE-to-UE relay, comprising the apparatus according to any one of claims 1-15.

17. A method for securely relaying a discovery message from a first device to a third device, wherein: The method comprises the following steps: - a second device receives from the first device a second discovery protected message protected with a second key set, the second discovery protected message comprising the first discovery message end-to-end protected with the first key set according to a policy or configuration, - the second device removes the protection using a second set of keys and verifies the integrity and freshness of the received second discovery protected message, and then extracts the first protected discovery message according to a policy or configuration, - the second device constructs a third discovery message, the third discovery message including the first discovery protected message, - the second device uses a third key set to protect the third discovery message as a third discovery protected message according to a policy or configuration, - The second device sends the third discovery protected message to the third device.

18. An apparatus for secure UE-to-UE communication, configured to: - constructing a direct communication request DCR message with integrated discovery, the integrated discovery including an indication to determine whether the message is protected, - if said indication is enabled, protecting said DCR message using integrated discovery with at least a second set of keys, - Broadcasting the DCR message with integrated discovery.

19. The device according to claim 18, wherein: When network assistance is used for secure link establishment indicated by the included RSC, the second set of keys is used for confidentiality protection of privacy sensitive information, such as RSC, PRUK-ID, and integrity protection of the DCR message with integrated discovery.

20. The device according to claim 19, wherein If the target UE user information ID is included in the DCR message, two sets of security materials are used to protect the DCR message, whereby end-to-end sensitive information (eg, user information ID) is protected with confidentiality and integrity by a first set of keys.

21. A source UE, comprising the apparatus according to any one of claims 18-20.

22. An apparatus for securely relaying a DCR message with integrated discovery from a first device to a third device, configured to: - receiving a DCR message with integrated discovery, the DCR message comprising a protection indication from the first device, - if the protection indication is enabled, cancelling the protection and verifying the integrity and freshness of the DCR message, - constructing a new DCR message with the integrated findings from the previous step including said protection indication, - if the indication is enabled, protecting the new DCR message using integrated discovery with at least one key set, and - broadcasting said protected new DCR message with integrated discovery to said third device.

23. The device according to claim 22, wherein: The device is adapted to identify the protection indication by using a security mechanism to establish the PC5 communication link relying on network assistance.

24. The device according to any one of claims 22-23, wherein: If the protection indication is enabled, the apparatus is adapted to construct a newly constructed DCR message with integrated discovery - the DCR message does not include a PRUK-ID field and the RSC is protected by XORing the RSC with the output of a key derivation function, the output of the key derivation function being truncated to the length of the RSC, or - the DCR message comprises a PRUK-ID field set to a predefined or random value, and the RSC is protected by XORing the RSC with the output of a key derivation function, the output of the key derivation function being truncated to the length of the RSC, or - the DCR message comprises a PRUK-ID field set to a predefined or random value, and the PRUK_ID and RSC are protected by XORing the PRUK-ID and RSC with the output of a key derivation function.

25. The device according to any one of claims 22 to 24, wherein: The received DCR message with integrated discovery is protected using a first key set and a second key set, and the apparatus is configured to: - unprotecting and verifying the integrity and freshness of the DCR message using a second set of keys associated with the first RSC, and - constructing a new DCR message with an integrated discovery containing end-to-end protected information protected with a first set of keys, and - protecting the constructed DCR message with integrated discovery using a third key set associated with the second RSC, and - Broadcasting said protected new DCR message with integrated discovery to third devices.

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

27. A device for securely establishing a PC5 communication link, configured to: - receiving one or more DCR messages with integrated discovery from a second device, the one or more DCR messages including a protection indication, and - If the protection indication is enabled, the protection is cancelled and integrity and freshness verification of the received DCR message with integrated discovery is performed.

28. The device according to claim 27, wherein The device is configured to perform the following operations based on the policy: - Perform path selection to choose the device to respond to, - construct direct communication messages, - if the protection indication is enabled, protecting the direct communication message using at least one key set, and - Sending a protected direct communication message to said device selected in said first step.

29. The device according to claim 28, wherein The policy prioritizes one or more of the following: - a direct communication link with the source UE, - a communication link including a relay device with which a security context has been established, - A communications link including a relay device with which a security context is to be established.

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

31. The device according to any one of claims 27 to 30, wherein: An indication is checked to determine whether the DCR message with integrated discovery is protected, whereby the indication is the RSC, or a security indicator associated with the RSC, or the presence of a PRUK-ID field or the message length.

32. The device according to any one of claims 27 to 31, wherein: If the protection indication is enabled, the device unprotects the DCR message with integrated discovery, verifies its integrity and freshness, and verifies whether the RSC is bound to a security process with network assistance.

33. The device according to claims 27-32, wherein: If the protection indication is enabled and a PRUK-ID field is included in the DCR message with integrated discovery, the apparatus is adapted to perform at least one of the following actions on the PRUK-ID: - checks it against predefined values, - if it matches a predefined value, ignore it, - If the PRUK-ID does not match a predefined value, an alarm is raised.

34. The device according to claims 27-33, wherein: One or more of the received DCR messages with integrated discovery are protected using two sets of security materials, whereby a second set of keys associated with the RSC is used to cancel protection and verify the integrity and freshness of the DCR message, and a first set of keys is used to cancel the protection and verify the integrity and freshness of the end-to-end protected information.

35. The device according to claim 34, wherein The processing of end-to-end protected information is prioritized to determine whether the DCR message is intended for the recipient, for example by checking whether the DCR message includes one or more identifiers thereof, whereby the end-to-end information is not protected by the confidentiality of the second set of keys.

36. A target UE, comprising the apparatus according to any one of claims 27-35.

37. An apparatus for securely and efficiently communicating with a second device, wherein: - the apparatus is configured to send a first message to connect to a second device, wherein the first message comprises a MIC or an encrypted identifier and / or a key identifier; and - the apparatus is configured to receive a failure message when the integrity verification or the RSC integrity check fails at the second device and / or to receive an acceptance message when the integrity verification succeeds at the second device.

38. The device according to claim 37, wherein The device is configured with a policy that determines its behavior based on (1) the absence of receipt of a message and / or the receipt of (2) a failed message or (3) an accepted message or (4) both a failed message and an accepted message.

39. The device according to any one of claims 37-38, wherein: The apparatus is configured to receive a failure message optionally including a failure reason, and the apparatus is configured with a policy that determines how to act based on the received failure reason.

40. The device according to any one of claims 37 to 39, wherein: The apparatus is configured to, when the apparatus receives both a failure message and an acceptance message, and the integrity verification of the acceptance message succeeds, wait for further communication from the second device.

41. The device according to any one of claims 37 to 40, wherein: The apparatus is configured to verify the integrity and / or freshness of the acceptance message and / or failure message by: - Check that the fingerprint exists and matches the fingerprint of a previously sent message, and / or - taking as input at least a fingerprint or value from the first message, a UTC-based counter or an identifier for identifying the integrity key to correctly calculate the MIC in the acceptance message and / or failure message, wherein the integrity key is the DUIK associated with the identifier, and the algorithm used to calculate the MIC is the NIA algorithm or a KDF-based MIC derivation algorithm.

42. The device according to any one of claims 37 to 41, wherein: The apparatus is configured to ignore the rejection message if the first message is not sent.

43. A remote UE comprising an apparatus according to claims 37-42.

44. A method for secure and efficient communication between a first device and a second device, wherein: - the first device sends a first message to connect to the second device, wherein the first message includes a MIC or an encrypted identifier; and - The first device is configured to receive a failure message when the integrity verification fails at the second device and / or to receive an acceptance message when the integrity verification succeeds at the second device.

45. The method of claim 44, wherein: The first device is configured with a policy that determines its behavior based on (1) no reception of a message and / or reception of (2) a failed message or (3) an accepted message or (4) both a failed message and an accepted message.

46. ​​An apparatus for securely and efficiently communicating with a first device, wherein: The apparatus is adapted to receive a first message to provide a connection to a first device, and the apparatus is configured to: - verifying the integrity of the first message by checking the MIC and / or the encrypted identifier using an integrity key, the integrity key being: i. used in a previous discovery process, or ii. bind to one of the configured RSCs in the device, or iii. bound to a previously exchanged message identified by the key identifier; or iv. bound to a key identifier included in the message; and The device is also configured to: i. ignoring the first message when the MIC verification fails, and / or ii. When the integrity verification succeeds but the RSC fails, respond with a failure message, and / or iii. When the integrity verification succeeds, reply with an acceptance message, or - verifying the integrity of the first message by using an integrity key check MIC or an encrypted identifier bound to one of the configured RSCs in the device, or to a previously exchanged message identified by the key identifier; and The apparatus is further configured to ignore the first message if the integrity verification fails.

47. The device according to claim 46, wherein The acceptance message and / or failure message includes a fingerprint and / or MIC from the first message, the MIC being calculated taking as input at least the fingerprint or value from the first message, a UTC-based counter, or an identifier for identifying the integrity key, wherein the integrity key is a DUIK associated with the identifier, and the algorithm for calculating the MIC may be a MIC derivation algorithm based on the NIA algorithm or a KDF.

48. The device according to any one of claims 46-47, wherein The device is configured not to send a failure message if: - the first message previously received has been successfully authenticated, and / or - It can be determined that there is no integrity key to integrity protect the failure message.

49. A UE to Network (U2N) relay comprising an apparatus according to any one of claims 46-48.

50. A method for secure and efficient communication between a first device and a second device, the method comprising: - the second device receives a first message to provide a connection to the first device including the Mic and / or the encrypted identifier; as well as - the second device verifies the integrity of the first message by checking the MIC and / or the encrypted identifier; as well as - When the integrity verification of the encrypted identifier fails, the second device replies with a failure message, and / or when the integrity verification succeeds, the second device replies with an acceptance message.

51. A system comprising the remote UE according to claim 43 and the UE-to-network relay according to claim 49.

52. A method for securely establishing a PC5 communication link, the method comprising: - the apparatus receives one or more DCR messages with integrated discovery from a second device, the one or more DCR messages comprising a protection indication, and - If the protection indication is enabled, the device cancels the protection and performs integrity and freshness verification of the received DCR message with integrated discovery.

53. A method for securely relaying a DCR message with integrated discovery from a first device to a third device, the method comprising, at a second device: - receiving a DCR message with integrated discovery, the DCR message comprising a protection indication from the first device, - if the protection indication is enabled, cancelling the protection and verifying the integrity and freshness of the DCR message, - constructing a new DCR message with integrated discovery from said DCR message received in a previous step including said protection indication, - if said indication is enabled, protecting said new DCR message with integrated discovery with at least one key set, and - Broadcasting a protected new DCR message with integrated discovery to said third device.

54. A method for secure UE-to-UE communication, the method comprising: - a device for constructing a direct communication request DCR message with integrated discovery, the DCR message comprising an indication for determining whether the message is protected, - if the indication is enabled, the apparatus protects the DCR message with integrated discovery using at least a second set of keys, and - The device broadcasts the DCR message with integrated discovery.

Images