How to get a cellular network working

Abstract

The invention relates to a method for operating a communication system including a primary station linked to a core network and serving a cell, a relay station served by the primary station and a secondary station served by the primary station, the method comprising the steps of the relay station establishing a connection with the primary station, including receiving a first set of configuration parameters in at least one first secure message from the primary station, the secondary station establishing a connection with the primary station, including receiving from the primary station a second set of configuration parameters linked to an upcoming data session in at least one second secure message, the relay station transmitting at least one transmitted service code from the first set of configuration parameters and, if it is determined that the transmitted configuration parameter is included in the second set of configuration parameters, the secondary station establishing a direct communication with the relay station.

Description

[Technical Field]

[0001] The present invention relates to the field of wireless communication, and more particularly to relaying architecture in cellular network environments such as UTMS Long-Term Evolution (LTE) or LTE Advanced (both included in 4G), New Radio (NR) (5G), or other celta networks or mobile communication networks. [Background technology]

[0002] In a conventional cellular network, a primary station serves multiple secondary stations located within the cell it supplies. Radio communication from the primary station to each secondary station takes place on the downlink channel. Conversely, radio communication from each secondary station to the primary station takes place on the uplink channel. Radio communication may include data traffic (sometimes called user data) and control information (sometimes called signaling). This control information typically includes information that helps the primary and / or secondary stations exchange data traffic (e.g., source allocation / requests, physical transmission parameters, information about the status of each station).

[0003] In a cellular network environment standardized by 3GPP®, the primary station is referred to as a base station, specifically 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 has interfaces that function within the Core Network (CN). In the same environment, the secondary station corresponds to a mobile station or user equipment (or UE) in 4G / 5G, which is a radio client device or a specific role played by such a device. The term "node" is also used to refer to either a UE or an eNB / gNB.

[0004] 3GPP® introduces the role of a relay node, as shown in Figure 1. This relay node 120 is a radio communication station 120 that includes the function of relaying communications between the base station 100 and the UE 110. This relay function helps, for example, extend the coverage of cell 10 to a mobile station 110 outside of coverage (OoC). This relay node 120 may be a mobile station or a different type of device. In the 4G specification, the proximity service (ProSe) function is defined, in particular in TS23.303 and TS24.334, along with other functions, to enable connectivity for cellular user equipment (UE) that is temporarily not present in the coverage of the cellular network base station (eNB) 100 supplying cell 10. This particular function is referred to as relaying between the UE and the network by ProSe, or simply as a relay UE. The relay UE 120 relays applications and network traffic bidirectionally between the OoC UE 110 and the eNB 100. Local communication between the relay UE120 and the OoC's UE110 is referred to in TS23.303 and TS24.334 as device-to-device (D2D) communication, or sidelink (also known as PC5) communication. Once the relay relationship is established, the OoC's UE110 is IP-connected via the relay UE120 and functions as a “remote UE” 110. This situation means that the remote UE has indirect network connectivity to selected functions of the core network, as opposed to direct network connectivity to all functions of the core network, as is the case in TS22.261.

[0005] Additionally, in such a system, as shown in Figure 2, A) A remote UE can make calls to the base station / core network via relay between the UE and the network. B) A source UE can make a call to a destination UE via relay between UEs. C)UE groups can communicate with each other as groupcast communications, sometimes via relay between UEs.

[0006] 3GPP® SA2 discusses communication models and procedures and agrees on them for relay-based systems. These procedures are included in TR23.752. 3GPP® SA3 discusses security solutions and procedures and agrees on them for relay-based systems. These procedures are included in TR33.847.

[0007] For example, solution #28 in TR23.752 describes a mechanism in which a remote UE discovers a Layer 3 relay between the UE and the network and establishes a PC5 unicast connection using the relay between the UE and the network. This mechanism does not require interaction with the core network during operation.

[0008] For example, solution #32 in TR33.847 describes a mechanism for a remote UE to protect its PDU parameters from relaying between the UE and the network so that only authorized repeaters can access them. This solution requires interaction with the core network. [Overview of the project] [Problems that the invention aims to solve]

[0009] The current solution discussed in TR23.752 solution #28 offers the advantage of not requiring interaction with the CN during discovery. However, it also presents several problems, such as those related to KI#16 in TR33.847. How to avoid pre-setting slicing information remains unresolved (Problem 1). Also, this solution requires that PDU session parameters be transported in plain text (Problem 2). A possible solution to these challenges in TR33.847 is solution #32. However, this solution requires communication over the core network during operation to achieve privacy protection of PDU parameters (Problem 3).

[0010] One objective of the present invention is to alleviate the problems described above.

[0011] Another object of the present invention is to propose a communication method in a network that enables a secure setup for establishing a protocol data unit (PDU) session for a secondary station.

[0012] Another object of the present invention is to propose a communication method for secondary stations in a network that, once in operation, requires only minimal interaction with the core network. [Means for solving the problem]

[0013] For this purpose, a method for operating the system described in claim 1 and a variant thereof in a dependent claim have been proposed according to a first aspect of the present invention.

[0014] Thus, according to the first aspect of the present invention, the secondary station and the relay station obtain required security elements, such as a signed public key directed to the receiving UE, for example, from the core network at an early stage, for example, at the time of an initial connection to a cell. During, for example, the operation of the network, which is a later phase, the secondary station and the relay station can establish a secure exchange and authentication in order to initiate a PDU session.

[0015] In the exemplary embodiments described below, the configuration parameters included in the first message and the second message can be a relay service code (RSC). However, these configuration parameters can also be different parameters or combinations of parameters, such as any one or more of the following. That is, · A set of access roles, · A set of attributes, · Communication parameters, such as a transmission mode, restrictions on some sets of resources, · Special identifiers, such as an ID for an application, a group ID, a UE, · A policy defining access rights, · A policy defining the type of communication that can be relayed.

[0016] According to a second aspect of the present invention, a method for operating a relay station according to claim 18 is proposed.

[0017] According to a third aspect of the present invention, a method for operating a secondary station according to claim 19 is proposed.

[0018] According to a fourth aspect of the present invention linked to the second aspect of the present invention, a relay station according to claim 20 is proposed.

[0019] According to a fifth aspect of the present invention linked to the third aspect of the present invention, a secondary station according to claim 21 is proposed.

[0020] According to a sixth aspect of the present invention, a computer program product is proposed which, when executed on a computer device, includes coding means that cause steps of the method of the first, second, or third aspect of the present invention to occur.

[0021] Therefore, according to a first aspect of the present invention, a method is proposed for operating a communication system including a primary station linked to a core network and supplying cells, a relay station supplied by the primary station, and a secondary station supplied by the primary station. This method is Steps for a relay station to establish a connection with a primary station include receiving a first set of configuration parameters, which include a service code, in at least one first secure message from the primary station, The steps include the secondary station establishing a connection with the primary station, which include receiving from the primary station a second set of configuration parameters, including a relay service code linked to a future data session in at least one second secure message, The relay station transmits at least one transmitted service code from a first set of configuration parameters, When it is determined that the transmitted service code is included in the second set of configuration parameters, the secondary station establishes direct communication with the relay station, It holds.

[0022] According to a second aspect of the present invention, a relay station configured to communicate in a network is proposed, comprising a primary station linked to a core network and supplying cells, and a secondary station supplied by the primary station, and a method for operating the relay station supplied by the primary station. This method is, Steps for a relay station to establish a connection with a primary station include receiving a first set of configuration parameters, which include several attributes or a set of service codes, in at least one first secure message from the primary station, The relay station transmits at least one attribute from the second set of configuration parameters or a transmitted service code from the second set of configuration parameters. Based on the transmitted service code, when a request is received from a secondary station, the relay station establishes direct communication with the secondary station. It holds.

[0023] According to a third aspect of the present invention, a method is proposed for operating a secondary station for communication in a communication system including a primary station linked to a core network and supplying cells, and a relay station supplied by the primary station. This method is: A step in which a secondary station establishes a connection with a primary station includes receiving from the primary station, in at least one second secure message, a public cryptographic key and a second set of attributes or a relay service code linked to future data exchange with at least one relay station, The secondary station receives at least one transmitted attribute or relay service code from the relay station, The secondary station determines whether the transmitted attribute or relay service code is included in a second set of configuration parameters, and if it determines that the transmitted attribute or relay service code is included in the second set of configuration parameters or satisfies a policy therein, it establishes direct communication with the relay station. It holds.

[0024] According to a fourth aspect of the present invention, a relay station is proposed that is configured to communicate in a network including a primary station linked to a core network and supplying cells, and a secondary station supplied by the primary station, wherein the relay station supplied by the primary station is provided. Transmitter and, Receiver and A controller configured to establish a connection with a primary station and to configure a receiver to receive a first set of configuration parameters, including an attribute or service code, in at least one first secure message from the primary station, Equipped with, The transmitter is configured to transmit at least one transmitted attribute or service code from a first set of configuration parameters. The controller is configured to establish direct communication with the secondary station using a public key when it receives a request based on a service code transmitted from the secondary station.

[0025] According to a fifth aspect of the present invention, a secondary station is proposed that is configured to communicate in a communication system including a primary station linked to a core network and supplying cells, and a relay station supplied by the primary station, wherein the secondary station is supplied by the primary station. Transmitter and, Receiver and A controller configured to establish a connection with a primary station, the controller configuring a receiver to receive a second set of configuration parameters from the primary station, which includes attributes or a relay service code linked to future data exchange with at least one relay station in at least one second secure message; Equipped with, The receiver is configured to receive at least one transmitted attribute or relay service code from the relay station. The controller is configured to determine whether the transmitted attribute or relay service code is included in a second set of configuration parameters or satisfies a policy within them, and if it is determined that the transmitted relay service code is included in the second set of configuration parameters, it causes the transmitter to establish direct communication with the relay station.

[0026] According to a first option which can be combined with any of the first to fifth aspects of the present invention, the first secure message further includes a relay public cryptographic key and a corresponding relay secret cryptographic key.

[0027] Similarly, according to the first to fifth aspects of the present invention or a second option which can be combined with the second option of the present invention, the second secure message further includes a secondary station public cryptographic key and a corresponding secondary station secret cryptographic key.

[0028] In the third option, which can be combined with the second and / or third option, at least one of the first secure messages is at least: Relay public encryption key and One of the attributes of the first set of configuration parameters or one of the service codes of the first set of configuration parameters, Includes at least one first core network signature from the core network generated in, At least one second secure message is, Secondary station public encryption key and At least one attribute of the second set of configuration parameters or one of the service codes of the second set of configuration parameters, It includes at least one second core network signature from the core network, generated in [location].

[0029] Instead, a fourth option, which can be combined with the second and / or third options, includes at least one first secure message, Relay public encryption key and One of the attributes of the first set of configuration parameters or one of the service codes of the first set of configuration parameters, Includes at least one first core network signature from the core network generated in, At least one second secure message is, Parameters included in the second secure message that are relevant to future data sessions, Secondary station public encryption key and At least one attribute of the second set of configuration parameters or one of the service codes of the second set of configuration parameters, It includes at least one second core network signature from the core network, generated in [location].

[0030] In the fifth option, which can be combined with the third or fourth option, the step of establishing direct communication is: a. The secondary station sends a direct communication request to the relay station, b. The relay station responds to the direct communication request with a response message that includes the relay public encryption key, the first core network signature, and the response message signature. c. The secondary station checks the first core network signature and the response message signature contained in the response message, Includes.

[0031] Furthermore, in a fifth option that can be combined with the fourth option, the direct communication request includes a secondary station nonce, and the response message signature is generated by applying the relay secret cryptographic key to at least the secondary station nonce.

[0032] Additionally, in a sixth option which can be combined with the fifth option, the response message signature is generated by applying the relay secret cryptographic key to at least the secondary station nonce and at least one of the core network first signature and the relay public cryptographic key.

[0033] In the seventh option, which can be combined with the fourth, fifth, or sixth option, the response message further includes a relay nonce, the secondary station transmits communication parameters in the configuration message, the configuration message includes a configuration message signature, and the configuration message signature is generated by applying the secondary station's secret cryptographic key to at least the relay nonce.

[0034] In the eighth option, which can be combined with the seventh option, the configuration message signature is generated by applying the secondary station secret cryptographic key to at least the relay nonce and at least one of the core network second signature and the secondary station public cryptographic key.

[0035] In the ninth option, which can be combined with the first to fifth embodiments, the step of establishing direct communication is: a. The secondary station generates or selects a secondary station cryptographic public key, a secondary station cryptographic private key, and a secondary station nonce, and sends a direct communication request to the relay station. b. The relay station responds to the direct communication request with a response message that includes a relay public encryption key, a first core network signature and / or a response message signature, and is encrypted using the public key received in step a. c. The secondary station decodes the response message and checks the first core network signature and the response message signature contained in the response message, Includes.

[0036] In a tenth option that can be combined with any aspect and option of the present invention, the relay station transmits at least one transmitted attribute of a first set of configuration parameters or a service code from the first set of configuration parameters, and at least one of further information, including a data session policy, data session parameters, a first core network signature, and a relay public cryptographic key, and the secondary station establishes direct communication with the relay station when it is determined that the transmitted attribute of the first set of configuration parameters or the transmitted service code is included in a second set of configuration parameters and the further information is compatible with future data sessions.

[0037] An eleventh option, which can be combined with the tenth option, requires that messages transmitted from a relay station include a signature that applies to at least the timestamp.

[0038] In a twelfth option of the present invention, which can be combined with any aspect and option of the present invention, at least one transmitted service code from the first set of configuration parameters is the result of a hashed service code of the first set of configuration parameters combined with a transmitted nonce, and the relay station further transmits the transmitted nonce.

[0039] A thirteenth option of the present invention, which can be combined with the fifth to tenth options, further comprises the step of a secondary station informing the core network whether the first core network signature has failed.

[0040] A 14th option, combined with the first to fifth aspects of the present invention, includes the steps of a relay station establishing a connection with a primary station, the relay station generating a relay public cryptographic key and a relay private cryptographic key, sending the relay public cryptographic key to the primary station for signing by the core network, and receiving, in at least one first secure message from the primary station, a first set of service codes and a first core network signature based on at least the relay public cryptographic key.

[0041] In the first to fifth aspects of the present invention or the fifteenth option of the present invention in combination with the fourteenth option, the step of a secondary station establishing a connection with a primary station includes the steps of the secondary station generating a secondary station public cryptographic key and a secondary station private cryptographic key, sending the secondary station public cryptographic key to the primary station for signing by the core network, and receiving in at least one second secure message from the primary station a second set of service codes and a second core network signature based on at least the secondary station public cryptographic key.

[0042] It should be noted that the above-mentioned devices are implemented based on discrete hardware circuit configurations comprising discrete hardware components, integrated circuits, or chip modules, or on signal processing devices or chips controlled by software routines or programs stored in memory, written on computer-readable media, or downloaded from networks such as the Internet.

[0043] It should be understood that wireless devices, systems, relay stations, cell stations and methods may have similar, corresponding, and / or identical preferred embodiments, particularly as defined in the dependent claims.

[0044] It should be understood that preferred embodiments of the present invention may be dependent claims or any combination of the above embodiments and their respective independent claims. These and other aspects of the present invention are evident from the embodiments described below herein and become clearer with reference to the embodiments described below herein. [Brief explanation of the drawing]

[0045] [Figure 1] This is a previously described schematic diagram representing a cellular system in which the present invention is implemented. [Figure 2] Figure 1 is a schematic diagram, already described, illustrating different possible operating modes in the network. [Figure 3] This is a time diagram of communication using the protocol of the first embodiment of the present invention. [Figure 4] This is a time diagram of communication using the protocol of the second embodiment of the present invention. [Figure 5] This is a time diagram of communication using the protocol of the third embodiment of the present invention. [Figure 6] This is a time diagram of communication using the protocol of the first embodiment of the present invention. [Figure 7] This is a time diagram relating to an improved form made possible by a certain embodiment of the present invention. [Figure 8] This is a time diagram relating to an improved form made possible by a certain embodiment of the present invention. [Figure 9] This is a time diagram of communication by protocol in another embodiment of the present invention. [Figure 10] This is a block diagram showing a secondary station and a relay station according to one embodiment of the present invention. [Modes for carrying out the invention]

[0046] In the following description, solutions to problems 1, 2, and 3 are described in various embodiments. These solutions, in the first embodiment, involve distributing the information signed by the CN, in particular the public key associated with each UE (also referred to as a secondary station, remote UE, and relay station, and also referred to as a relay UE), to each UE. This information distribution phase occurs during the initial provisioning and authorization steps, i.e., early in the connection. The UEs may be remote UEs or relay UEs. The UEs under consideration may have to operate alternately as relay UEs and remote UEs in their operation. With the signed information including the public key, in this first embodiment, the following is permitted: The remote UE checks whether the relay UE is permitted to act as a relay without accessing the CN during operation. - The relay UE may check the PDU parameters of the remote UE without accessing the CN during operation, provided permission is granted. • The remote UE and the relay UE establish a secure PC5 link without accessing the CN during operation.

[0047] Compared to existing security solutions (Solution #28 in TR23.752 and Solution #32 in TR33.847), the primary advantage of this first embodiment of the present invention is that it does not require access to the core network while operating in a secure manner. This means the following: • Lower workload on the core network, • Once in operation, further checks with the CN are unnecessary, thus reducing the latency required to establish the communication link. • The relay UE may be outside the coverage area. • Remote UEs may be outside the coverage scope. • Privacy-related parameters are not disclosed.

[0048] In this way, this first embodiment presents a solution applicable to solution #28 of TR23.752 to address privacy concerns and avoid problems 1 and 2.

[0049] Although this first embodiment is described in the context of protecting PDU parameters in the context of KI#16 of TR33.847, the same techniques and constructions of other embodiments on those techniques can also be used to address other problems, as shown in the table below. This detailed description includes several embodiments that provide solutions to these problems. In particular, this detailed description provides improvements to solutions #8 and #31 in TR33.847. These two solutions are the only solutions in TR33.847 that use public-key cryptography. Solutions #8 and #31 address KI#6 and KI#7, respectively.

[0050] [Table 1]

[0051] It should be noted that the first embodiment of the present invention is applicable to protecting the confidentiality of other parameters. For example, application functionality is addressed as in solution #21 of TR33.847.

[0052] It should be noted that this solution can also be used independently to establish security in PC5, as an alternative to solutions #1, #6, #10, and #15 of TR33.847.

[0053] Next, a first embodiment is described with reference to Figure 3. In a network similar to that described in the preamble to this description, the CN can generally sign the information. This can be achieved by the Digital Signature Network Function (DSnF) proposed in solution #20 of TR33.809. Alternatively, an application function may be responsible for signing the requested information. In addition, the remote UE is configured with trust anchors that enable verification of the information when it is signed by the CN. These trust anchors may be similar to those in the DSnF solution. In this variant of the first embodiment, these trust anchors may be delivered to the UE during the initial provisioning phase (steps 1.a and 1.b below).

[0054] The first embodiment corresponds to ProSe operation using “Discovery Model A”. In fact, constrained ProSe direct discovery is the process by which a UE detects and identifies other nearby UEs using its radio access direct radio signal with explicit permission from the UE being discovered. According to Discovery Model A ("I'm Here"), two roles of ProSe-enabled UEs are involved: announcing the UE and monitoring the UE. The announcing UE broadcasts discovery messages at predefined discovery intervals, and monitoring UEs interested in these messages read and process them. Instead, Model B ("Who's There?" / "Are You There?") involves two roles of ProSe-enabled UEs: the discovering UE and the discovered UE. It is equivalent to “Who's There / Are You There?” as the discovering UE sends information about other UEs that wish to receive a response from them, and this information could be, for example, about a ProSe application ID corresponding to a group from which members of that group can respond.

[0055] According to the first embodiment, as shown in Figure 3, - In step a, during initial provisioning, the CN distributes a set of configuration parameters to the relay UE, such as the relay service code (RSC) it supports. The configuration parameters may include other capabilities provided by the relay UE, such as which applications it supports. This distribution can be done without disclosing to the relay UE any specific parameters that are privacy-sensitive and linked to each set of configuration parameters, such as the RSC. The CN also creates a key pair of relay public keys for use by the relay UE. The CN may also distribute other information, such as a policy that specifies which types of remote UEs or connections the relay is permitted to supply. The CN may sign (or perform other security processing, such as message encryption) the supported configuration parameters and relay public keys. The CN provides the relay UE with the signed configuration parameters and relay public keys, along with the corresponding relay private keys. This can be done in a single message, as shown in Figure 3, or in multiple separate messages in variants of this embodiment. In the case of signing by CN, the core network public key is also shared at this point. If, for example, the encryption key has already been exchanged or is known by the relay UE, other encryption processes may be involved, such as encrypting the entire first message. - In step b, during initial provisioning, the CN provides the remote UE with a set of configuration parameters linked to specific PDU session parameters, such as the RSC. The CN also creates a key pair of secondary station public keys. The CN signs the configuration parameters and the corresponding PDU parameters. It is possible to include other elements in the signature, such as the secondary station public key. The CN sends the signed secondary station public key, the RSC, the PDU parameters, and the secondary station private key. If the CN signs, the core network public key is also shared at this point. The CN can also distribute other information, such as a policy that specifies which types of relay UEs are allowed to supply the requirements for their communication. If, for example, the encryption key has already been exchanged or is known by the relay UE, other encryption processes may be included, such as encryption of the entire second message. This distribution can also be performed in a single message or in multiple messages, as shown in Figure 3. -In step c, in the example of discovery model A, the relay UE broadcasts some of the supported configuration parameters, such as its RSC, during relay UE discovery. In the case of discovery model B, the remote UE (secondary station) may broadcast a message to indicate its presence. In fact, in discovery model B, the remote UE is the one that sends the discovery message, not the relay UE. To adapt the first embodiment to this alternative scenario, the remote UE sends a discovery message containing its supported configuration parameters, such as its RSC. - In step d, when the remote UE receives the data described above, it checks whether the relay UE supports its PDU communication requirements, for example by matching the RSC. -In step e, it is first determined whether an RSC match exists, and then the remote UE can decide to establish a PC5 connection, for example, as follows: i. The remote UE generates a nonce N_remote and sends it to the relay UE. Optionally, the remote UE may also include specific RSCs of interest so that the relay UE knows about them. ii. The relay UE will send the following: 1. The public key (PuK_relay) and configuration parameters such as RSC, 2. Configuration parameters (e.g., RSC) and the CN signature on the public key received from the CN, i.e., S(PrK_CN,RSCs|PuK_relay), 3. Received remote N_remote (sent as an option, but required in signature calculation) 4. Relay, N_relay. Some or all of these items may be signed using the relay's private key (PrK_relay). In Figure 3, S(PrK,M) represents the signature of message M using the private key PrK. In this explanation, "|" corresponds to a concatenation operation. iii. The remote UE then (i) verifies the CN signature and (ii) verifies the relay signature including the remote nonce (iii). In this way, the remote UE can check that the relay UE was initially authenticated by the core network without needing to contact the CN during the operation. This thus reduces the load on the core network, which would otherwise need to perform authentication operations for each connection between devices. iv. If step iii) is successful, the remote UE can then send the following: 1. In particular, the communication parameters, which are the PDU session parameters linked to the RSC and the public key PuK_remote. 2. Corresponding CN signature for corresponding communication parameters and public key, 3. The nonce received from the relay UE, i.e., N_relay(optional), 4. The above information elements (communication parameters, corresponding CN signature, nonce N_relay (optional)) can be signed using the secondary station's private key (PrK_remote) which is signed by the CN. Next, the entire message can be encrypted using the relay node's public key PuK_relay, and as a result, these parameters and information are not sent in plaintext over the over-the-air (OTA) network. As can be seen in Figure 3, E(PuK,M) represents the encryption of message M using the public key PuK. v. The relay UE decrypts the received information and checks the remote CN signature against the remote UE's signature. If the verification is correct and N_relay exists, the relay UE provides the remote UE's requirements for the disclosed PDU parameters.

[0056] Therefore, as explained earlier, during the connection to the relay UE, neither the relay UE nor the remote UE needs to communicate with the core network for authentication / authorization purposes. All verifications are implemented in advance, resulting in a smooth and secure connection protocol without the need for assistance from the CN during operation. Thus, even outside the coverage area, the UE can securely connect to the PDU session.

[0057] As previously explained, Discovery Model B requires broadcasting to the remote UE in order to connect to the relay UE. Therefore, when implementing a variation of the first embodiment in a specific case of Discovery Model B, in step c, the remote UE broadcasts its configuration parameters, such as its RSC. In a later step of this alternative example, the relay UE matches the received configuration parameters, such as the received RSC, with its own. If a match exists, the relay UE may send its signed RSC, relay nonce, its relay service code and associated CN signature, and / or its public key, similar to the later steps in the first embodiment (Model A).

[0058] In a variant of the first embodiment, it may be impossible to track the relay UE. For this purpose, the remote UE generates a transient public key pair and sends it to the relay UE in step e(i). Since this public key pair is transient, it cannot be used to track the remote UE. The relay UE uses it in step e(ii) to encrypt the message so that the relay parameters remain secret from external (passive) attackers. Thus, the step of establishing direct communication may include a step in which the secondary station generates its own cryptographic public and private keys. With the secondary station nonce, the remote UE can send a direct communication request to the relay station. This first message, similar to that in the first embodiment, is optional but can be secure.

[0059] In response to a direct communication request, the relay station sends a response message containing the relay public cryptographic key, the first core network signature, and / or the response message signature, in which case the message is protected (for confidentiality) using the public key received with the direct communication request.

[0060] Next, the secondary station can decrypt the received message and check the first core network signature contained in the response message and the response message signature.

[0061] It should be noted that, due to the small size of the discovery message, the protocol described above allows for the exchange of the RSC in step c. Another variant of the first embodiment that reduces the number of round trips consists of the relay UE broadcasting its configuration parameters (or a portion thereof), policy, public key, and signature at that point (step c). Once this is done, in step d, the remote UE can already check whether the relay UE's policy supports its PDU communication requirements. If it does, it checks the validity of the policy and public key by verifying the signature. In a subsequent step e according to this variant, the remote UE can decide to establish a PC5 connection as in solution #28, but additionally, this UE shares its signed PDU session requirements encrypted using the relay UE's public key. Finally, in step f, the relay UE can decrypt the remote UE data and verify its signature. If the verification is correct and the parameters are permitted by its policy, the relay UE supplies the needs of the remote UE.

[0062] Here, and anywhere else in this specification, verifying a signature includes checking the signature itself, as well as checking other fields such as the expiration date and issuer. Note that this also includes searching for or accessing invalidation lists that contain invalidated public keys.

[0063] In addition to the variants described above, the following may be done to (further) mitigate replay attacks: In step 1c, the relay UE may use its private key to sign at a timestamp such as the current UTC time, and optionally the rest of the broadcasted information. This signature may also be included in step 1c. In step 1d, the remote UE checks the received signature at UTC time to see if this time is recent. This thus avoids the risk of an attacker remembering and replaying past messages.

[0064] In addition to the variants described above, the following may be done to (further) mitigate MitM attacks: The relay UE can use its private key to sign its current location, which may be, for example, GPS coordinates or building name. This information may be included in step 1c. In step 1d, the remote UE verifies the received signature and checks whether the location matches its own. This avoids the risk of an attacker compromising a relay device at a specific location and reusing its broadcast message at multiple locations. This feature can be used independently and standalone.

[0065] Since broadcasting static RSCs can be considered a privacy risk, other variants of the first embodiment consist of the sender generating a nonce N to derive a pseudo-RSC as pRSC=HASH(RSC|N), where HASH is a hash function that takes the concatenation of RSC and N as input. The sender then broadcasts (pRSC,N) (step c). The receiver must apply this hash function to each of its RSCs to check for a match. For this approach to be secure and collision-free, pRSC, RSC, and N must be sufficiently long. If these values ​​are only small in the discovery message (step c), subsequent messages may contain other pairs (pRSC',N') with longer parameters.

[0066] In the first embodiment and all variants already discussed, if step e, iii fails, the remote UE terminates the connection. The remote UE then notifies the CN of the acknowledgment failure and can relay the relay UE parameters on the next opportunity to connect. Similarly, if step e, v fails, the relay UE refuses to deliver the service. The relay UE can notify the CN of the acknowledgment failure and the remote UE parameters. Thus, if a security risk is discovered, the core network is quickly notified and can check the station of concern.

[0067] In a further variant of the first embodiment, the remote UE receives, for example, the relay UE's public key (or fingerprint) already permitted in step 1b, instead of step eii(1), from the core network.

[0068] As described in the first embodiment, in step 1d, the remote UE checks whether the relay UE supports its PDU requirements by checking whether the RSC matches. This is a one-to-one relationship and is similar to a "role-based access control" approach that uses predefined roles to perform specific actions. In other words, if the relay UE has RSC=x, the relay UE is authorized.

[0069] This signed RSC can be viewed as an "authorization token," and it can be considered a proposed operation in step 1c where the RSC (an unsigned "authorization token") is distributed to perform a first check to match the bandwidth requirements of the discovery message. The complete "authorization token" can then be distributed in step eii if a match is found in the preceding step. This simple, standalone operation can be integrated into, for example, solution #31 of TR33.847.

[0070] It should be noted that in the context of "attribute-based access control," it is possible to define more complex "policies." Instead of having only an RSC, it is also possible to consider more attributes related to the relay UE's device type (e.g., is it a secret device? or a public device?), the action being performed (e.g., is it a data upload? or a data download?), the data being accessed (e.g., the level of secrecy?), the ID of the application, device or group, or the current context (e.g., is it a normal situation or an emergency situation?). The receiver (e.g., remote) may have an XACML access control policy that can be used, for example, to check whether the sender (e.g., relay) is authorized. This policy can be distributed during provisioning along with other configuration parameters that include any device attributes such as the RSC.

[0071] If this solution requests other sets of information or configuration parameters (which can be considered roles or attributes) during discovery, such as Solution #11 or Solution #8 of TR23.752, this information can also be signed and distributed by the CN during the initial provisioning. The CN can also distribute policies during provisioning that describe the requirements that the other party must meet in order to be permitted to act as a relay, remote, or peer. The information sent in steps e-ii and e-iv includes all or part of the information sent during discovery, including corresponding CN signatures so that the data can be verified upon receipt and cross-checked against policies that were also received during provisioning.

[0072] In steps 1a and 1b, the CN generates key pairs for both the remote UE and the relay UE. Alternatively, these key pairs can be generated by the UE, and the public key can be sent to the CN for signing. The advantage of doing this is that the CN does not have any knowledge of the private key.

[0073] In steps 1a and 1b, the CN signs one set of information for both the remote UE and the relay UE. The CN may also sign multiple sets of information so that these UEs can rotate them, i.e., modify them regularly for privacy reasons.

[0074] In steps 1a and 1b, the CN signs public keys for both the remote UE and the relay UE. These public keys are associated with their corresponding private keys. In further variants, these key pairs can be used sometimes for public-key cryptography and sometimes for digital signatures. Generally, it is convenient to reuse the same key pair (in a secure manner) for both signing and encryption. However, this is not a recommended practice because information could be leaked if, for example, encryption is used to break the signature. Therefore, steps 1a and 1b involve the distribution of multiple signed public keys, for example two, so that each of those multiple signatures is used for a different purpose, for example, encryption and signing.

[0075] If a remote UE has multiple RSCs for multiple PDU parameters, one option is for the CN to sign all of that information together. The problem with this approach is that when the remote UE sends this information to the relay UE for confirmation (iv of message e in Figure 3), the remote UE must send all RSCs and PDU parameters, because otherwise the relay UE cannot confirm the message. This again poses a privacy risk. A solution to this could be to construct a Merkle tree with 2n leaves, where n is the number of RSCs the (remote) UE has. In this Merkle tree, leaves 2k and 2k+1 take the k-th RSC and the corresponding PDU parameter as input, respectively, with k=0,...,n-1. The CN signs the root of the Merkle tree. When a remote UE must disclose PDU parameters for its k-th RSC, that remote UE only needs to disclose leaves 2k and 2k+1, the corresponding intermediate nodes in the Merkle tree that enable the computation of the Merkle tree root, and the CN signature at the root of the Merkle tree.

[0076] The same applies to the RSC in a repeater. In this case, the RSC corresponds to a leaf in a Merkle tree. When a repeater discloses a particular RSC in message e ii in Figure 3, it must disclose that RSC, the path in the Merkle tree for recalculating the root, and the signature provided by the CN at the root of the Merkle tree.

[0077] Given the above information, the recipient must use the path of the Merkle tree and the RSC (and PDU parameters) to check that the information allows for the recalculation of the Merkle tree root, and then check the signature.

[0078] In all variants, the appropriate signature algorithm can be the Elliptic Curve (EC) Digital Signature Algorithm (DSA).

[0079] The information provided in the initial provisioning steps may include different signatures for each piece of information, such as each RSC, each public key, and each PDU parameter. The advantage of this is that different pieces of information can be disclosed independently of each other.

[0080] The above explanation used public-key cryptography. This can be replaced by ID-based cryptography (IBE). In IBE, the ID of a UE corresponds to its public key. Given the ID of a UE, the CN uses a master secret to derive the corresponding private key for that UE. The advantage of IBE is that there is no need to exchange public keys. Another advantage is that the public key itself acts as a "certificate," and only "authorized" parties can receive and decrypt privacy-sensitive content. For example, consider a relay with the ID "RSC=x, expiration_date=2022 / 02 / 22". This is information that a relay can broadcast and a remote UE can receive. If RSC=x and expiration_date are acceptable to the remote UE according to the policy the remote UE received from the CN during provisioning, then the remote UE can use this ID of the relay UE "RSC=x, expiration_date=2022 / 02 / 22" as its public key. This means that the remote UE uses this public key to encrypt parameters that are privacy-sensitive, such as PDU parameters, and then sends this encrypted information. Only relays that possess the corresponding secret key issued by the core network can decrypt this information.

[0081] In the above explanation, a UE possesses a private key that can be used to prove its identity. However, digital signatures are too large for some implementations, and their verification requires considerable computation time. This is particularly true for discovery messages that have size limitations, such as being limited to a few hundred bits. An alternative solution to this consists of the CN configuring the announcing UE (e.g., a relay device) and the monitoring UE (e.g., a remote UE) so that a hash chain seed and anchor can be used to prove that several broadcasted messages originate from the announcing UE, with that hash chain link being used. Such a solution is valid, for example, for discovery messages sent by the announcing UE. This discovery message corresponds to message c in Figure 3. The security requirements when protecting these discovery messages are outlined in Key Issue #1 of TR33.847.

[0082] This solution focuses on key challenge #1 (discovery message protection). It proposes reusing the open discovery security mechanism specified in TS33.303 for 5G ProSe open discovery, as done in solution #3 of TR33.847, but with the following points highlighted: • To improve resilience against message modification and replay attacks. • To guarantee the reliability of the source, • Eliminate the need for the core network to verify the integrity of the message being announced.

[0083] The proposed enhancement is motivated by the fact that, in TS33.303, the integrity protection of discovery messages on the PC5 interface requires a discovery user integrity key (DUIK). This key is used to calculate the message integrity code (MIC). The MIC can be verified at the receiving UE if the DUIK is supplied to that UE, or if the ProSe function is using the DUIK. In the first case, the DUIK is supplied to the monitoring UE, which can verify the MIC itself. However, if multiple monitoring UEs receive the same DUIK, integrity protection, replay protection, or source reliability cannot be guaranteed because any of these UEs may be malicious. If the ProSe function must check the MIC, this increases the load on the CN and the overall communication latency.

[0084] The basic idea of ​​this solution is to complement the use of DUIK by using the Discovery User Integrity Hash Chain (DUIHC) for source reliability. ·H j (Input) is TRUNC b (Hash(identifier|j|H j-1 (Input))) indicates, ·H 1 (Input) = TRUNC b It is a (Hash(identifier|1|input)). Here, • The symbol "|" indicates linking. Hash(input) refers to the calculation of a hash function for a given input. • The "identifier" includes fixed and provisioned policies / parameters related to the ID of the announcing UE, such as its L2 identifier, the PLMN announced by the UE, and radio parameters when the UE is "not supplied by NG-RAN." TRUNCb(A) is a function that returns b bits of an input A, such as the least significant b bits of A.

[0085] H j (Input) calculations may optionally include either "j" and / or "identifier", but make the solution more resilient to attacks prior to the calculation. TRUNC b (A) is used for the purpose of reducing communication overhead.

[0086] Using this, DUIHC is obtained from a randomly generated seed S as follows. S→H 1 (S)→H 2 (S)→H 3 (S)→···→H N-2 (S)→H N-1 (S)→H N (S)

[0087] Here, the arrow "→" indicates the direction when generating the hash chain link H 1 (S)→H 2 (S)→···. The last element H N (S) is the anchor of this DUIHC.

[0088] Announcing side UEs such as relay UEs are given the seed S of its DUIHC. All monitoring side UEs are given the anchor of the DUIHC of the announcing side UE. These steps can be performed during device authentication and initial provisioning corresponding to steps a and b in Figure 3. When these parameters are given to the UEs, these UEs are also given a reference time t0 which is the time when it is assumed that the announcing side UE uses the hash chain link, and a time slot duration tDelta.

[0089] When a certain announcing side UE desires to send an announcement message m at UTC time t, this announcing side UE first determines the time when the announcing side UE uses the link H of the DUIHC N-jThe current time slot j is calculated as (t-t0) / tDelta, which means that (S) must be used. Note that this requires Nj>0. The announcing UE calculates the final key used in creating the MIC of message m, along with the DUIK. N-j (S) is used. This key is represented as the discovery user integrity key and hash chain link (DUIKHCHL), and is calculated as follows. DUIKHCL = Hash(DUIK|H N-j (S))

[0090] The reason for including DUIK in the DUIKHCL derivation is to provide interoperability with existing TS33.303 solutions. This also ensures that this solution is as secure as existing solutions. As another option, H N-j It should be noted that sometimes only (S) is used, or a key dependent on it is used in the calculation of MIC.

[0091] Message m's MIC is MIC m It is shown as follows, and the calculation is performed as follows. MIC m =MIC(m,DUKHCL)

[0092] The announcing UE also uses the previous DUIHC link, i.e., the H in the broadcasted announcing message, as shown below. N-j+1 (S) is included. m,H N-j+1 (S), MIC m

[0093] When a monitoring UE receives the above announcement message at time t, the monitoring UE first calculates the time slot j by taking the reference time t0 and the time slot duration tDelta as input. Next, the monitoring device receives the subsequent announcement message H N-jThe received message is cached until the next time slot j+1 to receive (S). N-j Using (S), the monitor-side UE can check the following: a) The validity of the MIC received in the previous message, and therefore the integrity of the message itself. This is determined by recalculating the received MIC by DUIKHCL. m This is done by checking that it matches the calculated MIC. b)H N-j Message freshness and source reliability are verified by checking that the received value of (S) is correct. For this purpose, the monitoring UE uses the received anchor as input.

[0094] The resulting message flow is similar to that of Solution #3 in TR33.847 and the Open Discovery Security Mechanism identified in TS33.303. Referring to Figure 6.3.2-1, the following key differences arise from using DUIHC after DUIK. Step 4 (Discovery Response) also includes the DUIHC seed S, reference time t0, and time slot duration. Step 5 (Announcement Start) is modified to use the link in DUIHC when calculating the broadcasted MIC as described above. Step 9 (Discovery Response) includes the DUIHC anchor, reference time t0, and time slot duration. Step 10 (receiving the announced code) is modified to use the received anchor of DUIHC in Step 9 to verify the integrity, freshness, and source authenticity of the broadcasted and received message as described above. Steps 11-15 are not required. In addition, If the monitoring UE detects a discovery message with an incorrect MIC or DUIHC link, the monitoring UE can notify the HPLMN or M-UE's DDNMF about the event. • If the announcing UE is disabled, HPLMN or MU DDNMF must notify any monitoring UEs that have expressed interest in discovering the announcing UE. • In Step 9, the DUIHC anchor received by the monitoring UE corresponds to the latest or most recently disclosed link for the DUIHC on the announcing UE.

[0095] The basic ideas described above can also be applied to restricted discovery mode A.

[0096] The basic idea described above can also be applied to restricted discovery mode B. This requires that both the discovered UE and the discovering UE can be owners of the DUIHC to prove their IDs based on the policy. Owning the DUIHC is particularly useful for the discovered UE if multiple discovering UEs can discover the same discovered UE and the confirmation of the response (response code) from the discovering UE is performed locally by the discovered UE.

[0097] The following are alternative methods to improve security assurance in discovery messages, which can be used with or without the DUICH approach described above: In Mode B, see TS33.303, the discovering UE is required to send a query code to the discovered UE. The discovered UE must check its integrity / newness / source reliability, and if the verification is successful, the discovered UE responds to the discovering UE using a response code. The discovering UE must be able to check the integrity / newness / source reliability of this message. TS33.303 states that verification by the discovered UE based on DUIK can only occur locally, while DUIK-based verification by the discovered UE can occur locally or remotely in a core network based on matching reports. This means that, for example, if multiple discovering UEs can discover the same discovered UE, one of the discovering UEs might misbehave and impersonate the discovered UE. This situation can be mitigated by having two DUIKs: a DUIKre from the discovering UE to the discovered UE, and a DUIKer from the discovered UE to the discovering UE. This means that if multiple discovering UEs discover the same discovered UE, and the MIC of the response code is confirmed by matching reports, it is impossible for any of the discovering UEs to impersonate the response code generated by the discovered UE. Further details and clarifications regarding this second point are as follows. Key Issue #1 in TR33.847 indicates that limited discovery has integrity protection, novelty, and source reliability as potential security requirements. Key Issue #1 also indicates that a potential threat is the possibility of an attacker impersonating the discovered or found UE. ○ Solution #4 reuses the LTE solution from TS33.303. In Mode B, a Discovery User Integrity Key (DUIK) is used to protect the query code and response code. The discovering UE sends the query code to the discovered UE. The discovered UE responds to the discovering UE using the response code. The discovered UE cannot use a match report to verify the MIC of the received query code. The discovering UE can use a match report to verify the MIC of the received response code. ○ This solution describes how the code-ejecting security parameters of the discovery-side UE are linked to the code-receiving security parameters of the discovered-side UE. This pair of security parameters is referred to as the query code security parameters. ○ This solution describes how the code-transmitting security parameters of the discovered UE are linked to the code-receiving security parameters of the discovering UE. This pair of security parameters is referred to as the response code security parameters. ○ This solution does not state anywhere that the security key in the query code security parameter must be different from the security key in the response code security parameter, which could create a potential security issue. In fact, steps 4 and 11 in Figure 6.4.2.2-1 show that the two sets of security parameters are identical. ○ If this is not explicitly stated as a requirement, a simple error can occur. For example, suppose the exact same DUIK is set for both the query code security parameter and the response code security parameter. In this situation, the discovering UE can impersonate the discovered UE. This can happen even if the discovering UE is required to use matching reporting to verify the MIC of the received response code. ○ This issue can be addressed by requiring that the security key, such as DUIK, in the code transmission security parameters of the discovery-side UE must not be the same as the security key in the code transmission security parameters of the discovered-side UE. In other words, the two DUIKs, DUIKre (from the discovery-side UE to the discovered-side UE) and DUIKer (from the discovered-side UE to the discovery-side UE), must be different from each other. ○ The way this property is explained in TR33.847 and TS33.303 is as follows: ■ The code transmission security parameters of the discovery-side UE and the code reception security parameters of the discovered-side should be referred to as query code security parameters. ■ The code transmission security parameters of the discovered UE and the code reception security parameters of the discovery side should be referred to as response code security parameters. ■ It should be stated that query code security parameters and response code security parameters must be different.

[0098] Tdoc S3-212464, submitted to 3GPP(registered trademark) SA3#104e, describes keying procedures for group member and repeater discovery. In particular, this Tdoc describes how a UE obtains the security parameters necessary to support group member and repeater discovery both within and outside of coverage, for example, in a publicly available secure scenario. Tdoc S3-212464 states, "Group member discovery is a restricted type of discovery and is expected to be supported both within and outside of coverage. Group member discovery uses provisioned keys to support the integrity, confidentiality, and untraceability of discovery messages. A discovery root key, from which other keys can be derived, is used to secure OTA discovery and communications. This root key can be provisioned by 5G DDNMF and / or 5G PKMF." Tdoc S3-212464 further proposes a further solution based on TS33.303[2], namely, "the same solution is provided for both public secure discovery scenarios, group member discovery and relay discovery, wherein a public secure discovery key (PSDK) is provisioned as a root key used to protect public secure discovery messages and is associated with one or more discovery group IDs or their respective relay service codes (RSCs). Both of these identifiers are defined in TS23.303[5]." The steps for group member discovery are "Step 0: The UE connects to the network and obtains authorization from the PCF to perform group member discovery. The UE also obtains the 5G DDNMF and / or 5G PKMF addresses of its HPLMN."In addition to the security policy, the following additional parameters are sent to the UE: the IDs of one or more application layer groups, the IDs of (ProSe) layer 2 groups, user information, discovery group IDs, and their expiration times. Step 1: The UE establishes a secure connection with the 5G DDNMF or its HPLMN's 5G PKMF. The UE's ID is authenticated and authorized by the 5G DDNMF or 5G PKMF. Step 2: The UE sends a discovery key request to the 5G DDNMF or its HPLMN's 5G PKMF. This key request includes at least the following information: the UE's ID, the IDs of one or more discovery groups, and their expiration times. Step 3: The 5G DDNMF or 5G PKMF checks whether the UE is authorized for group member discovery. Step 4: If the check in Step 3 is successful, the 5G DDNMF or 5G PKMF generates a public secure discovery key (PSDK) corresponding to the discovery group ID and its PLMN ID. Multiple PSDKs may be generated, but the total validity period should match the validity period of the corresponding set of discovery group IDs in Step 2. Step 5: The 5G DDNMF or 5G PKMF sends a key response to the UE. This key response message includes at least the following information: the UE ID, the PDSK identifier, the PDSK, and the validity period. For repeater discovery, the procedure / steps for repeater discovery are the same as those for group discovery described above, with the following exceptions. That is, (i) the UE is now a relay between the remote UE or the UE and the network, (ii) the relay service code is used instead of the parameter discovery group ID, (iii) the destination Layer 2 ID is used instead of the Layer 2 group ID, and (iv) the application layer group ID is not used.The proposed solution, Tdoc S3-212464, does not identify the need for different keys for the query code security parameters and response code security parameters used during the discovery phase as described in the previous embodiment. If a single PSDK is provisioned as the root key used to protect publicly secure discovery messages, as proposed in Tdoc S3-212464, and even if key derivation functionality is applied so that the query code security parameters and response code security parameters have different DUIKs, the involved devices are capable of generating all of these keys, and thus the discovering UE may be able to impersonate the discovered UE, as described above. To address this security challenge, the keying procedure for discovery must distribute different master keys, i.e., different PSDKs, used for the derivation of the query code security parameters and response code security parameters. For example, two different master keys could be PSDK_QCSP and PSDK_RCSP, where PSDK_QCSP is used to generate query code security parameters (including DUIK, DUSK, and / or DUCK), and PSDK_RCSP is used to generate response code security parameters (including DUIK, DUSK, and / or DUCK). In this way, impersonation attacks become unfeasible. PSDK_QCSP and PSDK_RCSP are generated independently and randomly, or generated from the master key by applying a key derivation function. In the latter case, K is not disclosed to UEs, particularly remote UEs and relay UEs, because otherwise, impersonation attacks would become feasible. The generation or retrieval of these keys can be performed in step 4 when the corresponding network functions in the core network, for example, DDNMF or PKMF, authorizes the UE and identifies its role, for example, whether the UE is a remote UE, a relay UE, or both.The distribution of these keys takes place in step 5 described above.

[0099] TR33.847 v0.7.0(08 / 2021) includes solution #37 after the construction of SA3#104e in the revised version of Tdoc S3-212464. Solution #37 indicates that different master keys must be distributed for the keying procedure for discovery. This updated protocol is somewhat improved to circumvent the aforementioned attack, because a UE can now receive several PDSKs, such as two PDSKs, for example, one for query code security parameters and one for response code security parameters. This is an improvement over section 6.6.7 of TS33.303, which describes the protection of discovery messages between multiple UEs, including the fact that a (single) PDSK is distributed to the UE and the key derivation function (KDF) allows the generation of discovery keys (DUSK, DUCK, DUIK) from the PDSK. However, the explanation in solution #37 of TR33.847 v0.7.0(08 / 2021) is still insufficient. This is because the discovery-side UE using matching reports should not receive the DUIK used to verify the MIC or any other key that can be used to derive the DUIK. The problem is not solved if the PDSK used to derive the DUIK is distributed to the UE because it enables the generation of the DUSK and DUCK, since the UE has the PDSK and therefore can generate the DUIK. Thus, an improved keying procedure applicable to TR33.847 v0.7.0(08 / 2021) consists of distributing the following to the UE, especially the discovery-side UE: ○ A first PDSK that enables the generation of a first set of DUIK, DUSK, and DUCK used to ensure query code security parameters, and ○ A second DUCK and / or second DUSK used to decrypt / descramble response code security parameters, but without the second DUIK. These second DUCK, DUSK, and DUIK keys can be generated by the KDF, for example, from a second PSDK.

[0100] TR33.847 v0.7.0(08 / 2021) reaches its conclusion after SA3#104e concerning Key Issues (KI) #1 and #2. For KI #1 for restricted ProSe direct discovery scenarios, Solution #4 is used as the basis for normative work, which includes the note that "the security key in the code-ejecting security parameters of the discovering UE and the security key in the code-ejecting security parameters of the discovered UE must be generated independently and randomly. This ensures that impersonation of the discovered UE is not feasible when the discovering UE utilizes the match reporting." The statement that the keys are generated independently and randomly is consistent with the above embodiments that require these keys to be different in order to avoid impersonation attacks. KI#2 states, "The conclusions for direct discovery are as follows: (1) The discovery key includes the cryptographic key, integrity key, and scramble key. (2) For open discovery, only the integrity key is assigned by the 5G DDNMF and used to provide integrity protection for the announcement message. (3) For restricted discovery, the 5G DDNMF assigns the discovery key based on the requirements of the Prosecut Service." The conclusions in KI#2 are insufficient to overcome the aforementioned spoofing attack and are inconsistent with Solution #4 because the conclusions in KI#2 limit the number of DUIKs to 1. Therefore, the conclusions for KI#2 should be updated to state, "The discovery key includes at least the cryptographic key, at least the integrity key, and at least the scramble key."

[0101] Clause 6.3 in TS33.503 describes security for relay communications between the UE and the network in 5G ProSe. Regarding security for 5G ProSe communications and control plane in relays between the UE and the network over 5G ProSe Layer 3 (Clause 6.3.3.3 in TS33.503), it states that "the PCF shall provision authorization policies and parameters for discovery and communications of relays between the UE and the network in 5G, as specified in 5.1.4 in TS23.304[2]." Clause 5.1.4 in TS23.304 states that "whether security parameters can be provided by the PCF and the details of the security parameters shall be determined by the WG of SA3." The first two steps of the message flow in Figure 6.3.3.3.2-1 of TS33.503 state that "the remote UE and the relay UE must be registered with the network." The documentation states that "a relay between the UE and the network must be authenticated and authorized by the network in order to be supported as a relay UE. A remote UE must be authenticated and authorized by the network in order to function as a remote UE." For this purpose, remote UEs and relay UEs must contact their respective AMFs. The AMFs serve as entry points for registration in the network. According to clause 4.3.4 of TS23.304, the AMF selects a PCF that "supports the provisioning of 5G ProSe policies / parameters based on the instruction for 5G ProSe capabilities as part of the '5GMM capability' in the registration request." Subsequently, it states that "the remote UE must initiate the discovery procedure using either the Model A or Model B method, as specified in clauses 6.3.1.2 or 6.3.1.3 of TS23.304[2], respectively."In a later stage of the process (step 4 in Figure 6.3.3.3.2-1 in TS33.503), the AMF of the relay UE authorizes the relay UE to function as a relay (for the remote UE). Note that the AMF does this by contacting the UDM to obtain the subscription information related to the 5G ProSe from the UDM and store it as part of the UE context data, in accordance with clause 4.3.4 of TS23.304.

[0102] It is impossible for two different entities to be responsible for managing the parameters and discovery keys that need to be distributed to both the relay UE and the remote UE for the discovery procedure to function. Therefore, the current specification in TS33.503 does not resolve which entity manages the discovery parameters and keys, and which entity authorizes the UE to obtain the discovery parameters and keys. In particular, it is possible for a single network function in a single network to be responsible for managing the discovery keys, which could be a PCF, PKMF, DDNMF, or other NF in one of the networks.

[0103] In a first embodiment that overcomes the problems described above, a remote UE (or relay UE) is registered with its network and seeks authorization for a given network relay service provided by a different network, for example, the relay UE's (or remote UE's) network. In this case, the remote UE's (or relay UE's) network (e.g., passing through AMF or PCF) informs the relay UE's (or remote UE's) network, in particular, the key management function responsible for the PCF or the relay UE's (or remote UE's) discovery key (e.g., PKMF, DDNMF), about the remote UE (or relay UE) (or its ID or the relay service requested by it). When doing so, the relay UE's (or remote UE's) network (e.g., PCF) provides the remote UE's (or relay UE's) network with the corresponding discovery parameters and keys for the remote UE (or relay UE). The remote UE's network and the relay UE's network can cooperate to create a discovery credential or key based on input from both networks (e.g., partial key, UE ID, or network ID). Once this is complete, the remote UE (or relay UE) is registered, authenticated, and authorized by the network of the remote UE (or relay UE), as described in steps 0a and 0b of the message flow in Figure 6.3.3.3.2-1 of TS33.503. In particular, it receives discovery parameters and keys at this stage. The network of the remote UE (or relay UE) (e.g., PCF) must contact the network of the relay UE (or remote UE) (e.g., PCF) which will then be responsible for updating the parameters to the relay UE (or remote UE) each time it updates the discovery parameters and keys.

[0104] In a second embodiment that overcomes the problems described above, a remote UE (or relay UE) is registered with its home network and seeks authorization for a given network relay service provided by a different network, for example, the relay UE's (or remote UE's) network. In this case, the remote UE's (or relay UE's) network (e.g., passing through the AMF or PCF) informs the relay UE's (or remote UE's) network, in particular the relay UE's (or remote UE's) PCF, of the remote UE's (or relay UE's) ID and the need for the relay service. Furthermore, the remote UE's (or relay UE's) network (e.g., passing through the AMF or PCF) informs the remote UE (or relay UE) of the relay UE's (or remote UE's) network, in particular the relay UE's (or remote UE's) AMF or PCF, and / or the key management function that is responsible for discovery keys and must be contacted for registration, authentication and authorization and / or discovery key retrieval in steps 0a and 0b of the message flow in Figure 6.3.3.3.2-1 in TS33.503. This means that, when this second embodiment is used, both the remote UE and the relay UE will look up discovery parameters and keys from the same network, i.e., the network providing the service. In particular, both the remote UE and the relay UE will look up discovery parameters and keys from the corresponding PCF, for example.

[0105] In a third embodiment that can be combined with the embodiments described above, the relay UE network and the remote UE network interact to match or align relay service codes. For example, in the first embodiment described above, when the remote UE (or relay UE) network informs the relay UE (or remote UE) network of the relay UE (or remote UE) about the relay service requested (given) by the relay UE (or remote UE), the relay UE (remote UE) network matches / aligns the relay service code of the other network with the relay service code used in its own network.

[0106] Clause 6.3 of TS33.503 describes security for relay communications between the UE and the network in 5G ProSe. For security for 5G ProSe communications via relay between the UE and the network at Layer 3 in 5G ProSe, the user plane (UP) approach (Clause 6.3.3.2 of TS33.503) and the control plane (CP) (Clause 6.3.3.3 of TS33.503) are described for relay authorization and security establishment between the UE and the network at Layer 3 in 5G ProSe. Figure 7 refers to Figure 6.3.3.2.2-1 of TS33.503 (Authorization and Secure PC5 Link Establishment Procedure for Relay between UE and Network in UP), and Figure 8 refers to Figure 6.3.3.3.2-1 of TS33.503 (Authorization and Secure PC5 Link Establishment Procedure for Relay between UE and Network in CP). In both UP-based and CP-based procedures, there are three phases (as shown in Figures 7 and 8): - The first phase involves provisioning discovery parameters, including discovery keys. - A second phase involving a discovery procedure that relies on provisioned discovery parameters, and - This is the third phase for PC5 authorization and security establishment.

[0107] While the second phase relies on the same discovery protocol, the first and third phases may involve different protocols or entities (network functions). This can lead to interoperability issues, such as the UE being configured using discovery parameters / keys based on the first phase of UP, even though the third phase is CP-based with respect to PC5 authorization and security establishment. This interoperability issue can stem from the lack of initialization of certain network functions, for example, the interoperability between the first phase of a UP-based approach (CP-based approach) and the third phase of a CP-based approach (UP-based approach).

[0108] Figure 9 provides a more complete explanation when entities involved in both the UP and CP procedures are included. Figure 9 outlines some of the interactions and communications that ensure interoperability between the first and third phases of the UP / CP-based approach.

[0109] In Figure 9, in relation to reference code (a), if the UE is configured via the UP approach in the first phase, a relay authorization (step 4 in Figure 8) may occur when the UE initiates a CP-based third phase, by the relay PKMF interacting with the network function in the relay network, which is, for example, the AMF or UDM, via a communication interface. This communication interface is indicated as Npc10 by Tdoc S2-2200214 (a reference point between the UDM and the 5G PKMF, used to provide subscription information to authorize whether the UE can function as a relay between the UE and the network by the 5G ProSe remote UE or the 5G ProSe). This communication may occur on demand, for example, after the UE has been configured via the UP approach (i.e., the PKMF pushes the configuration to the AMF) or when the UE initiates a CP-based third phase (i.e., the AMF sends a request to the PKMF).

[0110] In Figure 9, in relation to reference code (b), the remote PKMF and the remote AUSF / UDM communicate with each other via a communication interface to inform each other about the remote configuration so that they are ready for the CP-based third phase procedure and the remote UE's network can authorize its remote. This communication can occur on demand, for example, after the UE has been configured via the UP approach (i.e., PKMF pushes the configuration to AUSF / UDM), or when the UE initiates the CP-based third phase (i.e., AUSF / UDM sends a request to PKMF), as in steps 4-10 of Figure 8.

[0111] In Figure 9, in relation to reference code (c), the AMF-PCF(remote), PCF(remote)-PCF(remote), PCF-DDNMF, and DDNMF-PKMF(remote) interactions are shown for retrieving keys managed by PKMF(remote) for the initial first phase (discovery parameter / key setting) in the CP-based procedure. Here, network functions such as PKMF(remote) manage keys for both UP and CP.

[0112] Figure 9 shows, in relation to reference code (d), the interactions for retrieving the key from PKMF (repeater) for the initial first phase (discovery parameter / key setting) in a CP-based procedure: AMF-PCF, PCF-DDNMF, DDNMF-PKMF (repeater), and finally PKMF (remote)-PKMF (repeater). Here, network functions such as PKMF (repeater) manage the keys for both UP and CP.

[0113] Different embodiments are described below. Following KI#16 of TR33.847, the first embodiment and its variants described above address / are applicable to other keying challenges related to relaying between the UE and the network, including at least the following: Key Issue #4 (KI#4) concerns authorization in relay scenarios between the UE and the network, specifically how to authorize a relay UE to function as a relay. This can be done in step 1, e.iii, where the remote UE can check the relay's RSC and, if its signature is valid, confirm that it has been authorized by the CN to provide the corresponding service. Key Issue #3 (KI#3), which concerns the security of relaying between the UE and the network, and Key Issue #9 (KI#9), which concerns key management in 5G proximity services for relay communication between the UE and the network, relate to how keys should be handled and how PC5 links are protected.

[0114] The setup described in the first embodiment can be extended to address these key challenges. To secure the PC5 communication link between the remote UE and the relay UE, it is possible to exchange a shared secret key K'. One option is for the remote UE to randomly generate the shared secret key K' before step e.iv. In step e.iv, it sends K to the relay UE in a secure manner by encrypting it. The signature included in step e.iv can also have the (encrypted) K as input so that the relay can check the integrity of K. For example, in step e.vi, the shared secret key K' is computed by applying the KDF to the concatenation of K, N_remote and N_relay. This is shown in Figure 4. If extension 1 is available, another option arises. In this case, in step e.ii, K can be generated by the relay UE and sent to the remote UE.

[0115] A suitable approach for key exchange is the elliptic curve (EC) Diffie-Hellmann method. A suitable approach for public-key cryptography is the EC Integrated Cryptographic Scheme.

[0116] The above paragraph describes distributive alternatives to TR33.847 solutions #1, #6, #10, and #15 for addressing KI#9. In these solutions, the core network is involved in the generation and distribution of shared symmetric keys between the remote UE and the relay UE. Specifically, the remote UE sends a "direct communication request" to the relay UE that triggers a further request to the CN to distribute / generate a shared secret key that can be used to secure PC5 between the remote UE and the relay UE.

[0117] Key Issue #11 (KI#11) concerns the protection of the UE's ID during ProSe discovery, that is, how the UE's ID should be protected during discovery. This is done as in step 1, e.iv, where the remote UE responds with a nonce only upon receiving the RSC broadcast by the repeater. This nonce can serve two purposes here. The first purpose is related to novelty, as already explained in the main protocol. The second purpose is to act as a temporary identifier for the UE so that its true ID is not disclosed until the remote UE confirms that the repeater UE is authorized to function as a repeater. The true ID of the remote UE is disclosed in step 1, e.iv, along with the PDU parameters.

[0118] The first embodiment and its variants described above may address / apply to other key challenges related to relaying between UEs. In a relaying scenario between UEs, two remote UEs need to communicate with each other directly, or via a relay UE.

[0119] Note that in TR23.752, Solution #11 is selected as the minimum for Model A discovery, and Solution #8 is selected as the minimum for Model B discovery. In the case of Solution #11, the discovery information includes (i) Type = Announcement, (ii) Discovery Type = Inter-UE Relay Discovery, (iii) Announcer Information (i.e., Higher Layer Identifier for UE-R User), (iv) UE ID in UE-R's ProSe (i.e., UE-R's Layer 2 Identifier), and (v) a list of “Target User Information” parameters (or attributes) collected during group member discovery in Step 2 (including users of UE-1 and UE-2). “Target User Information” is a higher layer parameter that identifies the target user. To support Layer 2 communication via stateful inter-UE relay, “Target User Information” also includes the Layer 2 identifier of the target user’s UE. In Solution #8, discovery information is provided not by individual discovery messages, but by sending a "broadcasted" direct communication request. This direct communication request includes source UE information, target UE information, application ID, and relay service code.

[0120] Key Issue #6 (KI#6) concerns the integrity and confidentiality of information in relaying between UEs, i.e., how to protect communication between two remote UEs communicating via a relay UE. In particular, following the above solution, once the two UEs identify and connect to a suitable relay, these two UEs can use the same information set by the CN to exchange symmetric keys (as in Extension 2) which can be used to secure communication between both UEs.

[0121] Relevant work and differences: It should be noted that solution #8 of TR33.847 also uses public keys to address the same scenario. However, the current solution has some FFS that are addressed in this solution. Solution #16 also addresses KI#6, although it does not directly mention public-key cryptography.

[0122] The following explains how Solution #8 can be improved by using public-key cryptography. Some of these improvements can also be applied to Solution #16.

[0123] The first point that still needs to be discussed is how the public key is bound to a specific UE. This means that the solution does not provide a means of authentication and is vulnerable to a human attacker in the middle. In this solution, this is resolved because the public key assigned to the UE is signed by the CN.

[0124] Solution #8 also describes the exchange of public keys in messages 2 and 4, and in step 6 it states that "the extended link is end-to-end secure using the public keys of the source UE and target UE, while the routing information remains in plaintext." From this description, it appears to rely on the Diffie-Hellman key exchange scheme, in which the private key is equal to pr_A*PU_B = pr_B*PU_A, where pr means private key and PU means public key. This solution therefore does not cover ECIES or Key Encapsulation Mechanisms (KEMs) standardized by, for example, NIST's Post-Quantum Cryptography (PQC). Examples of KEMs in PQC include SABER, Round5, Kyber, or NTRU. The difference in this respect is that in message 2, the source UE sends its public key, and the target UE, upon receiving it, randomly generates a random key K that is encapsulated using the source UE's public key. Message 4 contains a transient public key component derived from the target UE and the encapsulated key.

[0125] Another FFS in Solution #8 concerns how to verify that the DCA message is trustworthy. This can be verified if the public key is signed by the CN, as is done in steps 1.a and 1.b of the current solution. As mentioned above, the IBE solution can also be used in a similar manner.

[0126] Solution #8 configures the relay using policies / parameters in step 0, and then relays the message in step 3 if the policies match and the relay is permitted to relay the message. This approach has several challenges, including the following: *Firstly, message #2 (a direct communication request from the source UE to the UE inter-relay) can be replayed. This can be avoided if the message contains a nonce that is first disclosed by the relay and signed by the source UE. Alternatively, the source UE can also sign the current time, thereby ensuring that the relay only accepts messages that fall within a given time window. This is similar to e.iv in step 1. *Secondly, the parameters in message #2 are left in plaintext and their integrity is not protected. This means they could be modified by an attacker. By observing whether the relay or target UE responds to messages 2 and 3, an attacker can also find out, for example, which ProSe applications the relay or target UE supports. This can be resolved if the relay first discloses its public key (for example, by sending it to the source UE), and the source UE uses it to encrypt any privacy-sensitive parameters. This is similar to e.ii in step 1.

[0127] Figure 5 illustrates how Solution #8 can be improved based on the above ideas. *Steps a0, a1, and a2 concern the initial provisioning of UEs and repeaters. This initial provisioning is similar to steps a and b in the main solution, but the addition / difference is that these devices are provisioned with information / policies related to their ability to relay information when used between UEs. *Step c is the same as in the first embodiment or its variant. *Step ei is the same as in the first embodiment or its variant. *Step e.ii is the same as in the first embodiment or its variants, but this time the addition / difference is that the relay station distributes signed information relating to its ability to relay information in the case of use between UEs. *If this information is successfully verified by the source UE, the source UE will respond using e.iv, as in the case of the main solution. It should be noted that since the source UE has the relay's public key, these parameters can be encrypted to ensure privacy. It should be noted that since the source UE's public key is signed by the CN, the source UE can sign any communication parameters to avoid MitM / replay attacks. Some of these ProSe parameters (e.g., broadcasted Layer 2 ID, ProSe application ID, UE's application layer ID, target UE's application layer ID, relay applicable instructions) are also directly signed by the CN and provided to the source UE in step a0. *Step eV checks whether the repeater can / is allowed to transmit information over this connection. The repeater also checks whether the source UE is as it claims. These checks are very similar to those in the first embodiment. *Step e.vi consists of transferring information to the target UE. However, it must be considered that the information in e.iv is encrypted using the relay's key, and the target UE does not possess the corresponding secret key. However, the target UE can decrypt and re-encrypt the information based on its public key. Alternatively, the relay may use a symmetric key shared between the target UE and the remote UE, which was established earlier, i.e., when the target UE connected to the relay, passing through steps c ei, e.ii, and e.iv itself. The relay already knows the target UE's preferences / policies (e.g., whether they have been disclosed to the relay beforehand), and therefore the relay will only transfer the message if it satisfies the target UE's policies. This step also includes one or more nonces, such as the nonce in step ei, the nonce in step e.ii, or a combination thereof. *Step e.vii concerns the target UE checking the incoming message. It checks whether the source UE satisfies its policy / communication requirements. The target UE can do this because it receives the source UE's communication information signed by the CN and / or source UE. In certain options in step e.vii, the target UE can randomly generate a symmetric key and use the source UE's received (quantum-resistant) public key to encapsulate / encrypt the randomly generated symmetric key K, and the source UE generates its transient public key for this purpose. *Step e.viii is used to verify the communication and contains the public key of the target UE. It may also contain further information from the target UE, such as being signed by the CN so that the source UE can verify it. This information can be encrypted using an encapsulated key (step e.vii) or using the public key of the source UE. This information is also signed by the target UE. Alternatively, a message authentication code may also be obtained using a symmetric key previously established between the relay and the target UE. The purpose of the signature or MAC is to inform the relay that this is a trustworthy message and can be forwarded. This message may also contain a nonce in step e.vi so that the relay and the source UE can check the freshness of the message. *Step e.ix concerns the relay checking the signature or MAC exchanged in step e.viii. *Step ex contains the e.viii message, which does not have a signature or MAC. Upon receiving this message, the source UE can decapsulate the symmetric key and decrypt any information related to the target UE. After decryption, the source UE can verify the information by checking the signature and its novelty by checking the nonce.

[0128] The steps in Figure 5 (mentioned above) and the steps in Figure 6.8.2.1-1 of TR33.847 correspond to each other as follows:

[0129] [Table 2]

[0130] Key challenge #7 concerns authorization in relay scenarios between UEs, specifically how remote UEs can verify that they are authorized to interact with each other. In particular, once two UEs identify and connect to the appropriate relay after the above solution, the following can be assumed: ■ In the very initial setup phase, the CN network in the initial provisioning phase must provide each UE with a policy describing its communication attributes and a policy determining which attributes the UE requires to allow device-to-device communication links with other UEs. Each UE must also receive a public key signed by the CN. The UE must possess a corresponding private key, or similarly receive one from the CN.

[0131] During the operation, two options are considered, as follows: ■ Option 1: During the operation, one of the UEs sends its communication policy to the other UE. The second UE checks it, and if it is authorized, it sends its own communication policy to the first device. If the first device also authorizes the second device, it sends a confirmation to the second device. ■ Option 2: When a UE joins a group during an operation, that UE first receives parameters from a repeater signed by the CN. This is similar to step e.ii in Figure 3. The UE then checks whether its repeater is authorized for communication between UEs and supports the need for communication (RSC). This check is similar to the check in step e.iii in Figure 3. Next, the UE sends its communication parameters to the repeater UE, which is similar to e.iv in Figure 3. The repeater UE checks them (step e.v in Figure 3).

[0132] The first embodiment and its variants described above are also applicable to addressing / applicable to other keying issues related to groupcast communications. In particular, this is partially related to KI#13 of TR33.847, which concerns linkability with respect to the security and privacy of groupcast communications, traceability and protection of L2 IDs, and also to the integrity / confidentiality of communications.

[0133] Next, we present a solution to address the problems arising from option 2 mentioned above regarding key issue #7. After performing the steps described in option 2, the repeater can check whether the UE is authorized to participate in communication with other UEs that are already part of a group of multiple UEs. If the UEs are authorized to communicate with each other, the repeater notifies each of the UEs in the group. In particular, assume that a new UE, Z, has joined. When the repeater notifies the remote UEs (A, B, ..., Y) about Z, the UE newly joining the group, the repeater sends N-1 messages M, but one message M is sent to each of the UEs (A, B, ..., Y) that were already in the group. Message M is similar to e.iv in Figure 3, where (i) PuK_relay is replaced with the public keys of A, B, ..., (ii) N_relay is replaced with the nonce previously sent by A, B, ..., Y, (iii) S(PrK_CN,RSC|PDU_param|PuK_remote) is a signature from the core network regarding the capabilities of the new device Z, which is a replacement for the remote device, and (iv) S(PrK_remote, ...) is replaced with a signature from the relay device regarding the parameters sent. Furthermore, the relay must also inform the new device Z about the existing devices (A, B, ..., Y). For this purpose, the relay sends message M' to Z. M' is similar to M, but instead of containing information about a single device, it contains information about N-1 devices.

[0134] In addition to the above, the repeater can handle a master group key that can be used for communication within the group. The repeater randomly generates this master group key K, which can be distributed to the UE, protected within the messages M and M' described above. A new master group key can be generated each time a new device joins or leaves the group. The derived group key K' can be derived as a key derivation function that takes K and a nonce for all devices in the group as input. For example, a hash function can be applied to the concatenation of K and each of the nonce sorted by an incrementing value and a counter i. This counter i can be used to rotate K' over time.

[0135] This key can also be used to derive the destination L2-ID, for example, by applying a key derivation function to K' and taking the least significant bit.

[0136] It should be noted that this approach to checking mutual authorization and distribution within a group means that the relays must send a total of N-1 messages. 2 This is an improvement over solutions where each UE authenticates / authorizes each other, which can require the overhead of individual messages. Such advantages are also mentioned in solution #12 addressing KI#8, which states, "UE1 can communicate with multiple target UEs over a PC5 unicast link via intermediaries between UEs. In this case, all target UEs must be informed of UE1's new IP address / prefix."

[0137] This solution is shown in Figure 6, and its main steps are as follows: *Steps a, b, and c relate to initial provisioning and are the same as steps a and b in Figure 3. *Step d refers to discovery and decentralized authentication / authorization. This includes steps similar to c, d, e i, e ii, e iii, e iv, and e v in Figure 3. *Step e concerns checking whether the new UE, Z, is authorized within a group that follows the policies of other UEs. *Step f concerns the generation of a master group key that has already been defined. *Step g concerns sending message M to each UE that was already part of the group. *Step h concerns sending message M' to the new UE. *Step i concerns the generation of the current group key.

[0138] Other variations of the disclosed embodiments will be understood and derived by those skilled in the art by examining the drawings, disclosures, and appended claims in practice of the claimed invention. In the claims, the terms “having,” “equipped with,” and “including” do not exclude other elements or steps, and singular elements do not exclude plural elements. A single processor or other unit may satisfy the functions of multiple items described in the claims. The mere fact that certain means are described in different dependent claims does not imply that it is impossible for a combination of these means to be used to produce a benefit. The above description details certain embodiments of the invention. However, no matter how detailed the above description may be in the text, the invention can be realized in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of certain terms when describing certain features or aspects of the invention should not be interpreted as implying that those terms are redefined herein to be limited to any particular characteristic of any of the features or aspects of the invention to which they relate.

[0139] As described throughout the preceding embodiments, proposed variants of the present invention can be implemented in a network, such as a cellular network, like the 5G network shown in Figure 10. The cells of the network are supplied by a primary station 1000. In the coverage of the primary station 1000 (e.g., a gNB), multiple secondary stations can be connected to that primary station. Some secondary stations may be configured to operate as relay stations 1010. Such a relay station comprises a transmitter 1011 coupled to a transmitting antenna and a receiver 1012 coupled to a receiving antenna. Typically, these receiving and transmitting antennas are the same antenna. Furthermore, depending on the technology, these antennas may be formed by antenna arrays that allow different transmit / receive modes, such as MIMO, transmit diversity, and operation at different sets of frequencies.

[0140] For example, a controller 1013, which is a CPU or microcontroller operating using software, is configured to control the transmitter and receiver and the antenna. It should be noted that some or all of the transmitter, receiver and controller may be part of a single baseband processor. In relation to the embodiments described above, the controller is configured to establish a connection between the relay station 1010 and the primary station 1000. More specifically, the controller 1013 may configure the receiver 1012 to receive a first set of configuration parameters, including attributes or service codes, in at least one secure message from the primary station 1000.

[0141] The controller 1013 controls the transmitter 1011 and causes the transmitter to transmit at least one transmitted attribute or service code from a first set of configuration parameters. This attribute or service code can be broadcast to be received by other stations, such as secondary station 1020.

[0142] Furthermore, the controller 1013 may be configured to then establish direct communication with the secondary station 1020 using a public key when requested by the secondary station, where the request is based on a transmitted service message.

[0143] Typically, a relay station is a UE (Unified Elemental Device) that is sidelink compatible and therefore capable of behaving as a relay station once configured. Alternatively, a relay station can also be another primary station, such as an access point, gNB (Global Network Module), or femtocell gNB.

[0144] A secondary station 1020 is typically a UE and comprises a transmitter 1021 and a receiver 1022, both typically coupled to one or more antennas or antenna arrays. Furthermore, the secondary station 1020 includes a controller 1023 configured to control the receiver 1021, the transmitter 1022, and possibly other elements of the UE. In the case of a relay station, the controller 1023 is a processor or CPU and is operated by software.

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

[0146] Receiver 1021 is configured to receive at least one transmitted attribute or service code from relay station 1010, and the controller may be configured to determine whether to allow the transmitter to establish direct communication with relay station 1010 when it determines that the transmitted attribute or service code is included in a second set of configuration parameters or satisfies a policy therein.

[0147] The operations described, as shown in Figures 3 to 9, can be implemented as program code means for a computer program and / or as dedicated hardware for the associated communication or access device, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but it may also be distributed in other forms, such as via the Internet or other wired or wireless communication systems.

Claims

1. A method for operating a communication system including a primary station linked to a core network and supplying to cells, a relay station supplied by the primary station, and a secondary station supplied by the primary station, the method being: The relay station establishes a connection with the primary station, comprising the step of receiving a first set of configuration parameters, including a service code, in at least one first secure message from the primary station, The steps include the secondary station establishing a connection with the primary station, which include receiving from the primary station a second set of configuration parameters, including a relay service code linked to a future data session in at least one second secure message; The relay station transmits at least one transmitted service code from the first set of setting parameters, When it is determined that the at least one transmitted service code is included in the second set of configuration parameters, the secondary station establishes direct communication with the relay station, A method having

2. The method according to claim 1, wherein the at least one first secure message further includes a relay public cryptographic key and a corresponding relay secret cryptographic key.

3. The method according to claim 1 or 2, wherein the at least one second secure message further includes a secondary station public encryption key and a corresponding secondary station secret encryption key.

4. The aforementioned at least one first secure message includes at least, Relay public encryption key and At least one attribute of the first set of setting parameters or one of the service codes of the first set of setting parameters, This includes at least one first core network signature from the core network generated in the above, The aforementioned at least one second secure message is at least, Secondary station public encryption key and At least one attribute of the second set of setting parameters or one of the service codes of the second set of setting parameters, The method according to claim 2 or 3, comprising at least one second core network signature from the core network generated in the above.

5. The aforementioned at least one first secure message includes at least, Relay public encryption key and At least one attribute of the first set of setting parameters or one of the service codes of the first set of setting parameters, This includes at least one first core network signature from the core network generated in the above, The aforementioned at least one second secure message is at least, Parameters relating to the aforementioned future data session and included in the aforementioned at least one second secure message, Secondary station public encryption key and At least one attribute of the second set of setting parameters or one of the service codes of the second set of setting parameters, The method according to claim 2 or 3, comprising at least one second core network signature from the core network generated in the above.

6. The step of establishing direct communication is: a. The secondary station sends a direct communication request to the relay station, b. The relay station responds to the direct communication request with a response message including the relay public encryption key, the first core network signature, and the response message signature, c. The secondary station checks the first core network signature and the response message signature included in the response message, The method according to claim 4 or 5, including the method described in claim 4 or 5.

7. The method according to claim 6, wherein the direct communication request includes a secondary station nonce, and the response message signature is generated by applying a relay secret cryptographic key to at least the secondary station nonce.

8. The method according to claim 7, wherein the response message signature is generated by applying the relay secret cryptographic key to at least the secondary station nonce and at least one of the core network first signature and the relay public cryptographic key.

9. The method according to any one of claims 6 to 8, wherein the response message further comprises a relay nonce, the secondary station transmits communication parameters in a configuration message, the configuration message comprises a configuration message signature, the configuration message signature is generated by applying the secondary station secret cryptographic key to at least the relay nonce.

10. The method according to claim 9, wherein the configuration message signature is generated by applying the secondary station secret cryptographic key to at least the relay nonce and at least one of the core network second signature and the secondary station public cryptographic key.

11. The step of establishing direct communication is: a. The secondary station generates or selects a secondary station cryptographic public key, a secondary station cryptographic private key, and a secondary station nonce, and sends a direct communication request to the relay station. b. The relay station responds to the direct communication request with a response message which includes a relay public encryption key, a first core network signature and / or a response message signature, and is encrypted using the public key received in step a. c. The secondary station decodes the response message and checks the first core network signature and the response message signature contained in the response message, The method according to claim 1, including the method described in claim 1.

12. The method according to any one of claims 1 to 11, wherein the relay station transmits at least one transmitted attribute of the first set of configuration parameters or a service code from the first set of configuration parameters, and at least one of further information, a data session policy, data session parameters, a first core network signature, and a relay public cryptographic key, and the secondary station establishes direct communication with the relay station when it is determined that the transmitted attribute of the first set of configuration parameters or the transmitted service code is included in the second set of configuration parameters and the further information is compatible with the upcoming data session.

13. The method according to claim 12, wherein the message transmitted from the relay station includes a signature applied to at least the timestamp.

14. The method according to any one of claims 1 to 13, wherein the at least one transmitted service code from the first set of configuration parameters is the result of a hashed service code of the first set of configuration parameters combined with a transmitted nonce, and the relay station further transmits the transmitted nonce.

15. The method according to claim 6 or 11, further comprising the step of the secondary station informing the core network whether the step of checking the first core network signature has failed.

16. The method according to claim 1, wherein the step of the relay station establishing a connection with the primary station includes the steps of the relay station generating a relay public cryptographic key and a relay private cryptographic key, sending the relay public cryptographic key to the primary station for signing by the core network, and receiving in at least one first secure message from the primary station the first set of service codes and a first core network signature based on at least the relay public cryptographic key.

17. The method according to claim 1 or 16, wherein the step of the secondary station establishing a connection with the primary station includes the steps of the secondary station generating a secondary station public cryptographic key and a secondary station private cryptographic key, sending the secondary station public cryptographic key to the primary station for signing by the core network, and receiving in at least one second secure message from the primary station the service code of the second set of configuration parameters and a second core network signature based on at least the secondary station public cryptographic key.

18. A relay station for communication in a network including a primary station linked to a core network and supplying cells, and a secondary station supplied by the primary station, and a method for operating the relay station supplied by the primary station, the method being: Steps for establishing a connection between the relay station and the primary station include receiving a first set of configuration parameters, which include several attributes or a set of service codes, in at least one first secure message from the primary station, The relay station transmits at least one attribute from a second set of configuration parameters, or a service code from the second set of configuration parameters, which was transmitted from the primary station. The step of the relay station establishing direct communication with the secondary station upon receiving a request from the secondary station based on the transmitted service code, A method having

19. A secondary station for communication in a communication system including a primary station linked to a core network and supplying to cells, and relay stations supplied by the primary station, and a method for operating the secondary station supplied by the primary station, the method being: The steps include the secondary station establishing a connection with the primary station, which include receiving from the primary station, in at least one second secure message, a public cryptographic key and a second set of attributes or a relay service code linked to future data exchange with at least one relay station; The secondary station receives at least one transmitted attribute or relay service code from the relay station, The secondary station determines whether the transmitted attribute or relay service code is included in the second set of configuration parameters, and if it determines that the transmitted attribute or relay service code is included in the second set of configuration parameters or satisfies the policy, it establishes direct communication with the relay station. A method having

20. A relay station for communication in a network including a primary station linked to a core network and supplying cells, and a secondary station supplied by the primary station, wherein the relay station is supplied by the primary station, and the relay station is Transmitter and, Receiver and A controller establishes a connection with the primary station and configures the receiver to receive a first set of configuration parameters, including an attribute or service code, in at least one first secure message from the primary station. Equipped with, The transmitter transmits at least one transmitted attribute or service code from the first set of setting parameters, The controller is a relay station that, upon receiving a request from the secondary station based on the transmitted service code, establishes direct communication with the secondary station using a public key.

21. A secondary station for communication in a communication system including a primary station linked to a core network and supplying cells, and relay stations supplied by the primary station, wherein the secondary station is supplied by the primary station, and the secondary station is Transmitter and, Receiver and A controller for establishing a connection with the primary station, the controller for configuring the receiver to receive a second set of configuration parameters from the primary station, which includes an attribute or a relay service code linked to future data exchange with at least one relay station in at least one second secure message; Equipped with, The receiver receives at least one transmitted attribute or relay service code from the relay station, The controller determines whether the transmitted attribute or relay service code is included in the second set of setting parameters or satisfies the policy, and if it is determined that the transmitted relay service code is included in the second set of setting parameters, it causes the transmitter to establish direct communication with the relay station, a secondary station.

Images