Improvement of security establishment methods and systems

Abstract

The present invention relates to a method and device for setting up a secure communication channel with an improved key exchange for security establishment protocols or procedures.

Description

[Technical Field]

[0001] The present invention relates to security establishment procedures between devices and / or applications in wired or wireless data networks, such as, but not limited to, Password Authenticated Key Exchange (PAKE).

[0002] In another embodiment, one or more network functions (NFs) in the CN are responsible for monitoring whether security procedures are being performed in accordance with the security procedures. [Background technology]

[0003] A password or passphrase is a string of characters, typically chosen by a user. Passwords are often used to authenticate a user to allow access to resources. Because most user-chosen passwords have low entropy and weak randomness characteristics, these passwords are not used directly as cryptographic keys.

[0004] A Key Derivation Function (KDF) is a deterministic algorithm used to derive one or more private keys (cryptographic key material) from a secret value such as a master key, password, or passphrase, typically using a pseudorandom function (PRF) that employs a cryptographic hash function or block cipher. A Password-Based KDF (PBKDF) is defined by the choice of a PRF and a fixed number of iterations C. The inputs to a PBKDF run include the password P, the salt S, and the desired length kLen of the desired master key mk, denoted as kLen, in bits. Symbolically, it can be expressed as follows: mk=PBKDF (PRF,C) (P, S, kLen)

[0005] The salt is a binary value used as input to the PBKDF to allow for the generation of a large set of keys for a given password. The iteration count (C) is a fixed value that determines the number of times the PRF iterates to generate one block of the master key. The iteration count is chosen to be as large as possible while still ensuring that the time required to generate a key using the input password is acceptable to the user.

[0006] Modern PBKDFs, such as PBKDF2 (specified in IETF specification RFC2898), are based on recognized cryptographic hashes such as SHA-2 and can use larger salts (at least 64 bits, chosen randomly) and higher iteration counts.

[0007] Figure 1 shows an example of the PBKDF2 algorithm for deriving a master key from a password, using a keyed-hash message authentication code or hash-based message authentication code (HMAC) with Secured Hash Algorithm 1 (SHA-1) as the PRF. The digest size in bits of the hash function is denoted by hLen. HMAC is a specific type of MAC that involves a cryptographic hash function and a secret encryption key. Like other MACs, it is used to simultaneously verify both data integrity and message authenticity.

[0008] The inputs to the algorithm in Figure 1 include the password P, the salt S, the number of iterations C, and the desired length in bits of the master key kLen (up to (2-1) × hLen). The parameters of the algorithm are the PRF (HMAC with an approved hash function) and the digest size of the hash function hlen. The output of the algorithm is the master key mk.

[0009] First, it is checked whether the required length of the master key is greater than the maximum length: if so, an error indicator (Err-i) is returned and the procedure stops.

[0010] If the required length is within the allowable range, the joined code part T i The loop parameter len of the outer loop (i=1 to len) is determined based on the ratio kLen / hLen, and each code portion is calculated in the inner loop (j=1 to C).

[0011] Figure 2 shows a signaling diagram of a message exchange between two devices A and B involving a specific augmented PAKE process (called "SPAKE2+") as described in "SPAKE2+, an Augmented PAKE (Draft)," Taubert, T. et al., IETF, May 5, 2022. A similar message exchange also applies to a specific balanced PAKE process called SPAKE2 as described in "SPAKE2, a PAKE (Draft)," W. Ladd et al., IETF, June 2, 2021.

[0012] SPAKE2+ defines PAKE, which allows two parties (parties can be devices, applications, etc.) A and B to agree on a common symmetric key in an authenticated manner, where authentication is based on a (weak) password. After an initial preamble exchange (pre) to communicate identity, protocol version, PBKDF parameters, etc., the PAKE procedure involves four messages and two round trips. The first party A computes a shared secret pA (cpt pA), and the second party B computes a shared secret pB (cpt pB). The first two messages (containing the respective shared secrets pA and pB) are used to set up the protocol (su prot) and agree on a common secret. The second party B then computes a confirmation cB (cpt cB), and the first party computes a confirmation cA (cpt cA). The final two messages (containing the respective confirmations cB and cA) are used to derive the secret (der scr) and confirm the key. Two of the messages are sent consecutively in the same direction (from B to A) and are therefore combined into one (pb+cB).

[0013] However, in the context of SPAKE2+ or other security establishment procedures, it is desirable to improve the security establishment procedures, thereby further enhancing security. Summary of the Invention [Problem to be solved by the invention]

[0014] An object of the present invention is to enhance the security of communications between devices and / or applications. [Means for solving the problem]

[0015] This object is achieved by an apparatus, a communication device, an apparatus and system, a method and a computer program product according to the appended claims.

[0016] Thus, security establishment messages (e.g., PAKE-type or other key exchange / security establishment messages) between two particular communication devices or applications may be associated with a given communication link by, for example, a session identifier, but the session identifiers for communication devices of the same security establishment process need not be the same. This is advantageous when security establishment is performed at the application layer, because in this case the security establishment protocol is unaware of the underlying network identifiers (e.g., MAC addresses or IP addresses).

[0017] Thus, when communicating devices exchange one or more initial messages (e.g., preamble messages), it is ensured that both devices have a single valid security establishment session, or, if they have multiple valid sessions, that they are linked to the correct peer device.

[0018] Additionally, security establishment messages can be reorganized to require only two round trips in total. This is advantageous for achieving a more efficient protocol by reducing protocol latency and improving user experience. This is also useful when the protocol is run over constrained networks and / or on a large number of devices simultaneously.

[0019] It should be noted that the above apparatus may be implemented based on a separate hardware circuit comprising an organization of discrete hardware components, integrated chips, or chip modules, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written to a computer-readable medium, or downloaded from a network such as the Internet.

[0020] It is to be understood that the apparatus, communication devices, methods, computer program products and systems may have similar and / or identical preferred embodiments, particularly as defined in the dependent claims.

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

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

[0023] [Figure 1] FIG. 1 illustrates an algorithm for calculating a master key using a PBKDF. [Figure 2] 1 is a signaling diagram including message exchanges according to a security establishment protocol, for example, a SPAKE2+ or SPAKE2 process. [Figure 3]FIG. 1 illustrates a schematic diagram of a signaling and processing diagram of an improved security establishment protocol, according to various embodiments. [Figure 4] FIG. 1 illustrates a block diagram of a communication device, according to various embodiments. [Figure 5] FIG. 1 illustrates a block diagram of PBKDF configurator elements or functions, according to an embodiment. [Figure 6] FIG. 2 illustrates a block diagram of an implicit PBKDF parameter generation element or function, according to an embodiment. [Figure 7] FIG. 10 is a flow diagram of a conditional PBKDF parameter exchange, according to an embodiment. [Figure 8] FIG. 10 is a signaling diagram of a preamble exchange including PAKE support information according to an embodiment. [Figure 9] FIG. 10 is a signaling diagram of a preamble exchange including hash function information according to an embodiment. [Figure 10] FIG. 1 is a signaling diagram of a preamble exchange including reliability information according to an embodiment. [Figure 11] FIG. 2 illustrates a block diagram of a lower layer protocol configuration for fragmentation handling, according to an embodiment. [Figure 12] FIG. 10 is a flow diagram of a key derivation procedure based on exchanged preamble information, according to an embodiment. [Figure 13] FIG. 2 is a diagram illustrating an exemplary protocol stack according to an embodiment. [Figure 14] FIG. 10 illustrates a schematic signaling and processing diagram of an improved security establishment process with reduced round trips, for example based on SPAKE2(+), according to an embodiment. [Figure 15] FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. [Figure 16] FIG. 1 illustrates a schematic diagram of a signaling and processing diagram for a personal IoT network scenario according to an embodiment. [Figure 17]FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. [Figure 17b] FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. [Figure 18] FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. [Figure 19] FIG. 1 is a schematic diagram illustrating elements and interfaces in a personal IoT network scenario. [Figure 20] FIG. 1 illustrates a schematic diagram of a signaling and processing diagram for a personal IoT network scenario according to an embodiment. [Figure 21] FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. [Figure 22] FIG. 10 illustrates a schematic diagram of a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0024] Embodiments of the present invention are described based on various modifications of security establishment procedures or protocols (SEPs), such as relying on generic PAKE, SPAKE2, or SPAKE2+, where the protocols allow establishing security properties such as at least one of authorization, mutual authentication based on a shared password, key establishment based on public key exchange, and key confirmation.

[0025] The inventors recognized that real-world implementations and specific use cases create a need for making such key exchanges more secure. Wireless networks are vulnerable to attacks, such as man-in-the-middle attacks. Accordingly, the inventors recognized that key exchange messages can be made more secure by providing at least one of binding to a specific set of communicating parties and / or a specific key exchange procedure. Similarly, the inventors determined that benefits could be derived from improved derivation of one or more key derivation parameters based on one or more exchange parameters, and / or support for potential key exchange upgrades to enhance security (e.g., through increased processing power enabled by quantum computers). Because communications are susceptible to eavesdropping and are time-sensitive due to user involvement, benefits could be derived from reducing the number of round trips in the key exchange process. Additionally, when PAKE protocol messages are transmitted over unreliable channels, such as channels through relay devices (e.g., UE-to-UE relays, a use case the inventors determined to be particularly vulnerable), or between personal IoT networks (PINs), means for providing authentication and authorization or reliable transmission (e.g., retransmissions) would also be helpful.

[0026] The following describes several modifications or extensions to using SEP based on an embodiment in which a first device or application uses PAKE to configure a second device or application, including providing details of the preamble, details of how the exchanged parameters in the preamble can be used in a PBKDF, details of the negotiation of PAKE in the preamble, alternative options for interaction after the preamble message indicates different capabilities (e.g., selection of the device that initiates the PAKE communication), and enhancements related to reducing the number of round trips.

[0027] The proposed enhanced SEP procedure applies to wired or wireless transmission channels or communication streams over the communication network and possibly other networks. 3GPP® specifications 23.303, 23.304, 24.334, and 24.554 for 4G and 5G networks, respectively, define a so-called Proximity Services (ProSe) function to enable, among other things, the connection of cellular communication devices (e.g., UEs) that are temporarily out of coverage of an access device (e.g., eNB). This specific function is called a ProSe UE-to-network relay, or relay UE. A relay UE is a communication device that assists another out-of-coverage (OoC) UE in communicating with an eNB (i.e., an access device) by relaying application and network data traffic bidirectionally between the OoC UE and the eNB. Local communication between a relay UE and an OoC-UE is called device-to-device (D2D) communication, sidelink communication, or PC5 communication. The abbreviation "PC5" refers to the interface for sidelink communication defined by ProSe. Furthermore, the abbreviation "UL" is used for the uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for the downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UEs).

[0028] Additionally, 3GPP® specifications TR23.733 v15.1.0 and TR36.746 v15.1.1 provide research into architectural enhancements, such as enabling Internet of Things (IoT) devices (the role of remote UEs) to operate at very low power by using relay UEs to connect to the wider network. Because relay UEs are physically very close, they can be reached using very low-power transmissions. This also includes improvements to the security, speed, and stability of ProSe. These extensions to ProSe are referred to as enhanced ProSe ("eProSe").

[0029] ProSe can also be used for direct communication between two UEs. For additional radio level details regarding ProSe, V2x, and sidelink communications, see 3GPP specifications TR37.985, TS38.300, and TR38.836.

[0030] There are IoT networks in which devices communicate with each other and with other networks through gateways. These networks are called Personal IoT Networks (PINs), and devices in such networks are called "PIN Elements." Such networks can communicate with other networks through PIN Elements with Gateway Functionality (PEGCs). The PIN Elements of a PIN are managed by at least one PIN Element with Management Functionality (PEMC). An example of another network is a 5G network, and document TR23.700-18 describes the enhancement of 5G systems to support PINs in accordance with the service requirements described in TS22.261.

[0031] According to TR 23.700-88 (for example), a PIN element is a UE or non-3GPP® device that can communicate within the PIN (via a PIN direct connection, a PEGC, or a PEGC and 5G functionality (5GC)) or outside the PIN via a PEGC and 5GC. According to TR 23.700-88, a PIN element with gateway functionality is a PIN element with the functionality to provide other PIN elements with connectivity to the 5G network or to act as a relay for communications between PIN elements. A PIN element with management functionality is a PIN element with the functionality to manage PINs. According to TR 23.700-88, a PIN direct connection refers to a connection between two PIN elements without an intermediate PEGC, 3GPP® RAN, or core network entity. TR 23.700-88 covers several key issues, including PIN, PIN and PIN element discovery and selection, PIN and PIN element management, PIN communication, PIN authorization, PIN policy and parameter provisioning, or enhancements to the 5GC architecture to support PIN and PIN element identification. TR23.700-88 also includes several possible solutions showing a protocol layer structure as shown in Figure 13. It should be understood that the layer structure of Figure 13 is not limited to 5G networks, and many other networks employ similar layer structures.

[0032] FIG. 13 illustrates, in schematic form, an exemplary protocol stack, according to an embodiment, as applied to a system described, for example, in TR23.700-88 with reference to FIG. 6.0B.2-2 thereof.

[0033] As shown in FIG. 13, the PIN layer (responsible for processing the PIN ID, PIN element, PEGC, and / or PEMC) is configured to run on top of multiple transport (TRA) layers and / or physical (PHY) layers (including Wi-Fi, Bluetooth, 5G ProSe, etc.) and support a higher application (APP) layer (configured to control a light bulb, a power socket, a washing machine, or any other controllable device) in processing key exchange and / or other security establishment functions, as described in the following embodiments.

[0034] In one example, a Supported PIN Element Function (S-PEF) represents functionality that provides communication within the PIN layer (e.g., via a direct PIN connection or through a PEGC) or outside the PIN layer (e.g., through a PEGC). The PEF can also communicate with a configured PEMC for discovery, authentication, and authorization.

[0035] Non-Supported PEF (NS-PEF) refers to the ability to communicate directly between the transport (TRA) layer and / or physical (PHY) layer and higher application layers without using an intermediate PIN layer.

[0036] Furthermore, there are important issues such as PIN identification and PIN privacy protection, secure communication between PINEs, secure policy and parameter provisioning, authorization of PIN elements (PINEs), authorization of PIN and PINE discovery, control of PIN element access to other (e.g., 5G) networks, authentication and authorization of PINEs, secure authentication of PINEs, or secure provisioning of credentials in non-3GPP devices via PEGC.

[0037] There are situations involving relay devices such as UE-to-UE relays, i.e., a first device A communicates with a second device B through a third device acting as a relay. In such use cases, issues arise including privacy protection, integrity protection, confidentiality protection, or authorization via the UE-to-UE relay. Relay functionality is also found in mesh networks.

[0038] Various improved embodiments of the SEP are described below, with further details of the hardware components involved being provided below with reference to Figure 4, and details of the procedures and signalling steps being provided with reference to Figures 3 and 5 to 13.

[0039] FIG. 3 summarizes several embodiments in which a first device or device A wishes to set up a secure communication channel with a second device or device B.

[0040] Figure 3 shows a schematic diagram of a signaling and processing diagram for a SPAKE-based SEP, according to various embodiments. In this diagram, the exchange of information between two devices A and B and its direction are indicated by corresponding arrows, processing steps are represented by respective blocks, and time progresses from top to bottom in Figure 3. Not all steps are always necessary or applicable, and some steps may be performed multiple times for improved accuracy or continuous processing.

[0041] A first device A is a mobile application used to configure a second device B, e.g., a medical device, a personal healthcare device, or a smart home device. The first device may also be a PEMC or PEGC. Device A and device B communicate via WiFi or other communication means such as Bluetooth Low Energy (BLE), Thread, or a 3GPP standard or low-power communication protocol, e.g., using Sidelink.

[0042] A device (or combination of devices) may be used to configure other devices specifically for connection to a given network. The device (or devices) may be dedicated to this purpose or may be a more general-purpose device on which the function is performed. An example of a function performed on a device is an application (or "app") running on a smartphone. An example of devices providing a function is a device that relays messages used for configuration to another device, such as a server. The term "commissioning tool" is used to refer to the function provided by a device (or combination of devices) that performs a configuration task, or to the device itself.

[0043] Two devices A and B need to run a PAKE, such as Extended PAKE or Balanced PAKE (e.g., SPAKE2+ or SPAKE2, respectively), to mutually authenticate and establish secrets. However, there can be many pairs of devices A and B doing the same thing at the same time. This occurs, for example, when an IoT network commissioning tool (such as device A when providing functionality for this purpose) needs to commission many devices B, or when device B is configured by multiple commissioning tools.

[0044] It is therefore important to associate a PAKE exchange with a given communication link between two specific devices. Each device A or B associates such a PAKE exchange with a given communication (link) identified by a given communication session ID. The session identifiers for devices A and B in the same PAKE exchange need not be the same. This is important when the PAKE process is performed at the application protocol layer, because in this case, PAKE does not recognize the underlying network identifiers, such as media access control (MAC) addresses or IP addresses, of the lower protocol layers.

[0045] When devices A and B exchange initial messages (e.g., the preamble described in Figure 2), they need to ensure that they have a single valid PAKE session, and if they have multiple valid PAKE sessions, they need to ensure that they are linked to the correct peer.

[0046] In one example, device A is a commissioning tool that interacts with many potential devices, such as smart home devices, that are subject to commissioning, configuration, authentication, authorization, and / or security configuration.

[0047] In one example, device B is a smart home device that needs to handle multiple commissioning devices A (e.g., apps running on a mobile phone) at the same time when multiple users or multiple apps are trying to connect.

[0048] According to various embodiments, during the preamble phase (PRE), it is proposed to exchange two preamble messages Pre_AB (sent from device A to device B) and Pre_BA (sent from device A to device B).

[0049] In the message Pre_AB, device A can send a short (eg, 8-bit) PAKE identifier ID_A to device B. As an additional option, device A also includes a (long) random value R_A in the message Pre_AB.

[0050] In the message Pre_BA, device B can send a short (e.g., 8-bit) PAKE identifier ID_B to device A. As an additional option, device B also includes a (long) random value R_B and a previously received R_A'. As a further option, which will be described in a later embodiment, device B further includes at least one of an identifier of the PAKE protocol version (PAKE_ID) and a reliability parameter (reli par) in the message Pre_BA.

[0051] Upon receiving the Pre_BA message, device A checks whether R_A' is equal to R_A in step 301, and if so, device A sets the peer session identifier to be used in subsequent messages as ID_B (step 302). If R_A' and R_A do not match, device A may abort the process, for example with an error message or report (e.g., to identify a man-in-the-middle or other attack), or may abort the executed protocol or restart the protocol.

[0052] The PAKE phase then begins (a SPAKE2+ process), during which during the first round, device A sends a public share p_A to device B in a first message, PAKE1, and device B responds with its own public shared secret p_B in a second message, PAKE2. For purposes of this invention, a public share, e.g., p_A or p_B, is a value sent by a sending entity that allows the receiving party to derive a sending entity and shared secret by combining the received public share with a secret value known only to the receiving party, e.g., one defined in SPAKE2+. In the second round, both parties use a unique secret protocol transcript (TT) to derive a shared symmetric secret (shared key) from the protocol transcript. Key confirmations c_A and C_B are derived from the shared symmetric secret and are exchanged in a third message, PAKE3, and a fourth message, PAKE4, as first described in connection with FIG. 2.

[0053] 3, device A determines or applies PBKDF parameters based on, for example, information provided in the respective fields exchanged with the preamble message or information provided / configured by a central management entity, then calculates a shared secret p_A in step S304 and sends it in a first message PAKE1 together with the latest received R_B′ in step S305.

[0054] Upon receiving R_B', device B checks whether R_B' is equal to R_B in step 306, and if so, device B sets the peer session identifier to be used in subsequent messages as ID_A in step 307. If R_B' and R_B are not equal, device B may abort the process, for example with an error message or report (e.g., to identify a man-in-the-middle or other attack), or interrupt the executed protocol or restart the protocol.

[0055] In step 308, device B determines or applies PBKDF parameters, for example based on information provided in the respective fields exchanged in the preamble message or information provided / configured by a central management entity. Then, in step 309, device B calculates and sends a common secret p_B in a second message PAKE2 to device A. Furthermore, device B derives a shared secret in step 310 based on the received common secret p_A. Then, device B derives and sends a key confirmation c_B in step 311 to device A in a third message PAKE3.

[0056] In step 312, device A derives a shared secret based on the common secret p_B received in the second message PAKE2, then verifies the key confirmation c_B received in the third message PAKE3 in step 313 and derives the key confirmation c_A, which it sends to device B in a fourth message PAKE4 in step 314.

[0057] The key confirmations c_A and c_B in the final round trip are authentication keys derived from the shared symmetric secret. In one example, both devices A and B are configured to compute authentication tags using the authentication keys generated via the protocol transcript.

[0058] Finally, a final message (FM) is sent from device B to initiating device A to end the procedure.

[0059] In some scenarios, for example, those addressed in TR33.740, the exchange of preamble messages or some of their fields is performed during an initial discovery phase between UEs via a UE relay or between a UE and a UE relay, e.g., the discovery phase associated with a UE-to-UE relay scenario. In such scenarios, the PAKE exchange is performed during the establishment of a secure PC5 interface after the discovery phase. In some scenarios, such as those addressed in TR33.882, the exchange of preamble messages is performed during the discovery phase of PINE.

[0060] Thus, by providing the preamble messages Pre_AB and Pre_BA with PAKE identifiers ID_A and ID_B and random values ​​R_A and R_B, respectively, it is possible to distinguish between PAKE sessions and ensure that devices A and B have a single valid PAKE session, or, if they have multiple valid PAKE sessions, that they are linked to the correct peer.

[0061] In the above use case in Figure 3, the commissioning tool (Device A) needs to interact with many devices at the same time. However, Device B can only interact with one Commissioning Tool at a time. Therefore, Device B has only one PAKE exchange process active at any given time.

[0062] Thus, in an alternative embodiment, the step in Figure 3 involving R_B is removed because it can be assumed that a single device A is active at any given time, for example, when device A is a commissioning tool such as an app running on a mobile phone and device B is a smart home device. In such a situation, replacement does not require replacement of R_B at all.

[0063] Similarly, instead of requiring the exchange of two preamble messages, Pre_AB and Pre_BA, an alternative embodiment involves a single preamble message, e.g., Pre_AB or Pre_BA. For example, upon receiving Pre_AB, device B responds with a first PAKE message. In such an alternative embodiment, Pre_AB includes only certain configuration parameters or settings. In a specific application of this alternative embodiment related to 3GPP proximity services, for use cases and requirements such as TR33.740, the content of the Pre_AB message is included in a Model A detection message, i.e., an announce message sent by the announcing UE. Upon receiving the Pre_AB message, i.e., an announce detection message, by device B, i.e., the monitoring device, device B initiates PAKE and responds with a direct communication request (DCR) message including the first PAKE message.

[0064] FIG. 4 illustrates, in accordance with various embodiments, a block diagram of a communication device 40 corresponding to at least one of the above devices A and B (including applications).

[0065] The communication device 40 includes a transceiver (TRX) 42 (e.g., a radio frequency (RF) front end or any other communication unit) for transmitting and receiving messages over a communication channel or link of a wired or wireless network, or the like.

[0066] A preamble control unit or function (PRE) 48 is provided to generate and decode preamble messages (eg, Pre_AB, Pre_BA in FIG. 3) transmitted and received by transceiver 42 during the preamble phase of the PAKE process.

[0067] Additionally, communication device 40 includes a PAKE control unit or function 46 for generating and decoding PAKE messages (eg, PAKE1-PAKE4 in FIG. 3) sent and received by transceiver 42 during the preamble phase of the PAKE process.

[0068] Additionally, the communication device 40 includes a PBKDF control unit or function 44 for deriving keys used in the PAKE process.

[0069] It should be noted that at least some of the preamble control unit or function 48, PAKE control unit or function 46, and PBKDF control unit or function are combined into a single control unit (e.g., a software-controlled processor or computer) and are implemented by respective software routines that control the processor or computer device.

[0070] It should further be noted that dashed blocks in FIG. 4, which will be described in more detail in subsequent embodiments, represent optional components.

[0071] The preamble control unit or function 48 is configured to set and / or derive at least one of a peer session identifier (PSI) 401, a session limit parameter (LIM) 405, a PAKE protocol version identifier (PV) 404, a PBKDF configuration parameter, and a PAKE configuration parameter to or from a sent / received preamble message.

[0072] As already mentioned above, a unique secret protocol transcript (TT) 406 is used to derive a shared symmetric secret (shared key). To achieve this, the PAKE control unit or function 46 and / or the PBKDF control unit or function 44 have access to the protocol transcript 406.

[0073] Additionally, reliability settings (REL) 402 are stored in the communication device 40 that affect the communication behavior of the communication device 40, as will be described below.

[0074] Furthermore, as already mentioned, a PAKE ID (PID) 403 and / or a maximum transmission unit (MTU) 407 are stored or set in the communication device 40, as will be described below.

[0075] In the above use case of Figure 3, if device B is allowed to have a limited number of PAKE active sessions at any given time, then device B needs to limit the number of incoming requests.

[0076] Thus, if device B sets the peer session identifier 401 to be used in subsequent messages as ID_A already upon reception of the preamble message Pre_AB (e.g., because R_B is not in use) and before receiving the first PAKE message (e.g., the first message of the SPAKE2+ process), device B is configured to limit the number of preamble messages Pre_AB allowed per unit time, to limit the maximum number of assigned peer ID sessions, and / or to discard the assigned ID_A if the first PAKE message PAKE1 is not received before a predetermined timeout. This is particularly advantageous if R_B is not in use, or at least not checked.

[0077] Each parameter (e.g., maximum number of preamble messages per unit time, maximum number of allocated peer ID sessions, and / or predetermined timeout) is stored as a session limit parameter 405 accessible by the preamble control unit of function 48 and / or the PAKE control unit of function 46.

[0078] The above limit setting is advantageous in that an attacker would otherwise inject a large number of potential preamble messages Pre_AB, exhausting the available sessions.

[0079] FIG. 5 shows a schematic block diagram of PBKDF configurator elements or functions, according to an embodiment.

[0080] The PBKDF configurator element or function is implemented by the PBKDF control unit or function of FIG.

[0081] As initially described in connection with FIG. 1, the PBKDF requires several parameters, such as a counter value or a salt value. These parameters may be set, for example, out-of-band (i.e., not included in the exchanged preamble and PAKE messages), by default, by manual user action, or specified in a specification. However, in this case, these parameters are rather static. This creates the problem that the output of the PBKDF is always the same after an initial preamble phase run. However, in certain cases, it is desirable to bind a given preamble run to a subsequent PAKE run.

[0082] In one embodiment, to address this issue, the information exchanged in the preamble phase is used as input to the PBKDF (ie, to the PBKDF control unit or function 46 in FIG. 4).

[0083] More specifically, the PBKDF control unit or function 46 of the communication device 40 (e.g., device A and / or B) is configured to determine PBKDF parameters (e.g., as defined in "Recommendation for Password-Based Key Derivation, Part 1: Storage Applications" by Meltem Sonmez Turan et al., NIST Special Publication 800-132, December 2010), such as a count value or a salt value, as a function of parameters exchanged in the preamble messages (e.g., Pre_AB, Pre_BA).

[0084] Note that the same embodiment is applicable if a different routine (eg, a hash function or HMAC) for deriving a key based on a password (ie, different from PBKDF) is used.

[0085] As shown in FIG. 5, the exchanged random parameters R_A and R_B (or at least one of them) are provided as inputs to a PBKDF control unit or function 44 and processed (e.g., logically or arithmetically combined) to obtain at least one of a PBKDF parameter count value (CV) and a salt value (SALT).

[0086] In the first example, the salt parameter is calculated as a logical XOR combination of the exchanged R_A and R_B parameters.

[0087] In a second example, the salt parameter is calculated as a logical XOR combination of the exchanged R_A and R_B parameters and a pre-configured salt (P-SALT) set and stored in the communication device 40.

[0088] In a third example, the salt parameter is calculated as a hash function of one of the above salt parameter values.

[0089] In a fourth example, the salt parameter is calculated as a cryptographic function, eg, a hash function, of a function such as the concatenation of the exchanged R_A and R_B parameters.

[0090] In a fifth example, the salt parameter is a subset (eg, a truncation) of the bits of any of the above salt parameter values.

[0091] In a sixth example, the count value is set to a minimum value, e.g., 1000 (e.g., a value defined in the standard), but depends on the exchanged parameters, e.g., the R_A and R_B parameters, e.g., (R_A+R_B) (modulo K), where K is a system parameter indicating the maximum number of additional iterations.

[0092] In a seventh example, the exchanged parameters (eg, R_A, R_B) are used together with a pre-shared salt parameter associated with the connection to be established.

[0093] Alternatively, the exchanged parameters, eg, R_A, R_B, are also used together (eg, concatenated) with a shared password.

[0094] As a further alternative, the PAKE identifiers exchanged by devices A and B in the preamble messages are used as input parameters in the above example.

[0095] The above alternatives are applicable, for example, when the PAKE is a balanced PAKE. They are also applicable, for example, when the password for the extended PAKE is stored in a secure element that runs a PBKDF, such as a SIM card, and returns only a value or token that makes the password difficult to obtain, for example, by an offline dictionary attack. This value is the verification value pair L and w0. The above alternatives are also applicable when a communications device requests a third communications device, given the entered exchange parameters and a password that is inaccessible or unknown to the communications device, to calculate and return such a value or token.

[0096] As a further alternative, the values ​​R_A and R_B are combined at a later stage in the SEP to link the preamble to a key derived from PAKE. For example, once the initiator and responder have established a shared secret K, a subsequent session key K' is derived from K, R_A, and / or R_B.

[0097] It should be understood that deriving the salt parameters from values ​​exchanged in the preamble (such as R_A and / or R_B) as described above may be combined with limiting the rate of preamble messages or the number of peer sessions, as previously described.

[0098] As indicated above, the PBKDF parameters, e.g., salt and / or counter value, are received in the pre-configuration phase or exchanged through another channel, e.g., read by device A from a QR code (or barcode or other scannable code) attached to device B, or exchanged out-of-band, e.g., through near field communication (NFC), BLE, or other wireless communication channel. These parameters are also received during pre-configuration from a central entity, e.g., a network function in a 5G system.

[0099] However, exchanging PBKDF parameters requires additional space, e.g., in a QR Code. For example, a QR Code needs to encode more information and therefore needs to be larger in size, taking up extra space on packaging or on products such as light bulbs. Furthermore, wireless messages are longer, requiring additional energy to transmit.

[0100] A way to address this issue is to exchange PBKDF parameters implicitly, i.e., the actual information of the PBKDF parameters is read or exchanged for another purpose, such as to identify a given network or device type, and this information is reused as the PBKDF parameters (e.g., salt or counter values). This also has the advantage that it allows the initiator to skip the exchange of preamble messages, i.e., the initiator sends the first PAKE message directly.

[0101] FIG. 6 illustrates a schematic block diagram of an implicit PBKDF parameter generation element or function, according to an embodiment.

[0102] For example, if a field is swapped / read for a first purpose (first PP) 64, the same bits or a (predetermined) subset of bits are reused as a salt parameter or counter value. To achieve this, an extraction function (EXTR) 62 (e.g., a register or addressable memory portion) is used to copy the bits and provide them to a PBKDF parameter memory or register (PDKDF-P) 66. Examples of first purposes include network identification, or details about the device such as the type of device. Notably, the first purpose is other than a PBKDF operation.

[0103] The bits of the field to be exchanged / read may also be extended, for example, by concatenating (a subset of) the bits into a predefined bit string, or by using them as input to a function such as a hash function.

[0104] Implicitly signaled PBKDF parameters are advantageous in that the QR Code can be kept small and the PAKE process is linked to information contained in the QR Code and used for other purposes.

[0105] The implicit exchange of PBKDF parameters limits control over their values, and therefore at least some PBKDF parameters, e.g., the counter value, are set to inappropriate values. This can be prevented by adding a fixed value (e.g., a number) as an offset to the implicitly derived value, and the parameter value used (e.g., the count value) is calculated by the following function: Parameter value = fixed value + implicitly obtained value Or any other function that guarantees a certain property, for example a minimum value for PBKDF parameters.

[0106] It should be noted that the password is pre-configured, especially in embedded devices that lack an input device such as a keyboard. An example of such an embedded device is a light bulb. The password should not be exchanged over the air in an unprotected manner, but rather the password is read implicitly. For example, device B has a QR code that encodes certain parameters. Device A then reads the QR code and derives a shared password from all or at least some of the read parameters. It should be noted that the password is received during pre-configuration from a central entity, for example, a network function in a 5G system.

[0107] FIG. 7 shows a flow diagram of a conditional PBKDF parameter exchange, according to an embodiment, which is performed by the PAKE control unit or function 46.

[0108] The preamble message Pre_AB is configured to indicate whether device A already knows the necessary PBKDF parameters, because in some use cases device A may have other access to the PBKDF parameters (e.g., via the implicit signaling described above).

[0109] However, in other scenarios, it is not feasible for device A to know the PBKDF parameters, for example, when device A is a commissioning tool that sends requests to multiple devices over WiFi, Ethernet, Bluetooth, etc. Similarly, in other scenarios, device A always knows the PBKDF parameters.

[0110] Similarly, in some scenarios, device A is a commissioning tool and device B is an IoT device. Because IoT devices have significantly different communication and computational capabilities, a given IoT device B only supports a specific security level. Therefore, device B is configured or required to indicate, for example, in a preamble Pre_BA sent from device B to device A, the security strength that determines kLen (e.g., configured by the manufacturer) and possibly the strength of the subsequent PAKE. Upon receiving Pre_BA, device A derives the appropriate parameters for executing PAKE using the appropriate security parameters.

[0111] Attackers use this flexibility (e.g., introduced by the protocol indicating whether device A is aware of the PBKDF parameters) to disrupt communications in various ways. For example, an attacker may want to intercept parameter information to more accurately predict the potential outputs of the PBKDF. The attacker can insert himself between devices A and B and trigger this exchange by modifying the respective instructions in the Pre_AB message that request the exchange of PBKDF parameters. In another example, an attacker may want to modify the parameter information to simply force a failure in the subsequent PAKE phase. The attacker can do this by inserting himself between devices A and B and modifying the information that is exchanged.

[0112] This embodiment may increase the security and robustness of the protocol, for example by providing for conditional transmission of PBKDF parameters.

[0113] In step 710, device B checks whether it has knowledge of its PBKDF parameters from device A, for example.

[0114] Note that in some cases, a third device (e.g., a network function in a 5G core network or a management entity such as an application running in the cloud) performs such a check on behalf of device B. In such cases, device B (should) forward (or is requested to forward) the request to the third device, which then executes the check protocol transcript and provides the results of the check to device B.

[0115] If in step 710 device B (or a third device acting on behalf of device B) determines that device A does not, for example, know its PBKDF parameters, the procedure branches to step 720, where device B transmits, for example, its PBKDF parameters, for example in a preamble message Pre_BA, even if the contents of message Pre_AB indicate that device A has (has access to) the PBKDF parameters (because message Pre_AB has been maliciously modified).

[0116] Otherwise, if in step 710 device B determines that device A is aware of, for example, its PBKDF parameters, the procedure branches to step 730, where device B does not send, for example, its PBKDF parameters in message Pre_BA, even if the contents of message Pre_AB indicate that device A does not have (does not have access to) the PBKDF parameters.

[0117] It should be understood that the PBKDF parameters for device B have been determined by the methods described above, such as deriving a salt from preamble parameters (e.g., R_A and / or R_B), or by an OOB method. The conditional transmission of the PBKDF parameters serves as an additional security enhancement in addition to other measures.

[0118] In one example, device B is configured to report or log events where a preamble message having a different value than expected indicates an ongoing attack on device B.

[0119] The advent of quantum computers requires new cryptographic primitives (algorithms) for key encapsulation and digital signatures. When quantum computers become available, many traditional cryptographic primitives will be broken, including, for example, SPAKE2+.

[0120] Therefore, ecosystems, such as smart home ecosystems, that begin deploying systems running PBKDF and SPAKE2+ or another SEP-based protocol will need to upgrade their protocols to incorporate quantum-resistant PAKE. For example, a different PAKE protocol (such as those described in "Towards Isogeny-Based Password-Authenticated Key Establishment" by Oleg Taraskin et al. or "Efficient Implementation of Password-Based Authenticated Key exchange from RLWE and Post-Quantum TLS" by Xinwei Gao et al.) is implemented in the PAKE phase after the initial preamble phase.

[0121] A device, say device A, can run multiple PAKE protocols, while another device, say device B, can only run one PAKE protocol (either the traditional SPAKE2+ or a new PAKE protocol, e.g., a quantum-resistant PAKE protocol). In this example, the legacy device can only run SPAKE2+, while the new device can run the new PAKE protocol.

[0122] FIG. 8 shows a signaling diagram of a preamble exchange including PAKE support information according to an embodiment.

[0123] In this embodiment, the modified preamble message Pre_BA 802 includes a new protocol support field (PAKE-SUPP) that indicates the PAKE protocol supported by device B. In one example, the protocol support field includes a SPAKE2 ID. When device A receives and reads the corresponding field, device A knows which PAKE protocol it needs to run. If device A does not receive the new protocol support field, device A knows that device B is a legacy device running, for example, SPAKE2+.

[0124] Similarly, the modified message Pre_AB 804 includes a new protocol support field (PAKE-SUPP) that indicates the PAKE protocols supported by device A. When the new device B receives the protocol support field, it recognizes that device A supports multiple PAKE protocols and selects the appropriate protocol.

[0125] Similarly, the modified message Pre_AB 804 includes a request to receive a new protocol support field from device B.

[0126] Note that other signaling parameters or information described in other embodiments are combined with the information in the new protocol support field, as well as additional information such as how key derivation parameters (e.g., salt and count values) are / were obtained or whether other parties used OOB methods.

[0127] Additionally, in the future, certain parameters of the PBKDF and / or the PAKE protocol, such as the hash function used in the PBKDF, may be customizable, however this requires that both devices A and B know which algorithm to use.

[0128] To address this issue, information about device A's preferred parameters, such as preferred or supported hash functions, is exchanged during the preamble phase in message Pre_AB.

[0129] FIG. 9 shows a signaling diagram of a preamble exchange including hash function information according to an embodiment.

[0130] To address the above issue, when device B receives the modified Pre_AB message 902 that includes the new hash function support field (HF-SUPP), it makes a selection regarding the hash function to be used and provides (signals) that selection in the modified Pre_BA message 904 that also includes the new hash function support field (HF-SUPP).

[0131] Legacy devices that cannot understand the new hash function support field of this embodiment will ignore this field. If no corresponding response is returned, device A will be configured to use legacy parameters.

[0132] In some cases, the message exchange in the preamble and / or PAKE phase occurs over an unreliable transport layer, i.e., the messages are interrupted and, for example, require retransmission. This requires either an enhancement of the protocol itself with message retransmission capabilities, or the exchange of specific reliability parameters, for example as part of the Pre_AB and / or Pre_BA messages, with a lower layer protocol (e.g., a MAC protocol) that provides such reliability capabilities.

[0133] The reliability features include at least one of indicating that the message is reliable and that the receiver should return an acknowledgment upon receipt of the message, including a field indicating that the message serves as an acknowledgment for a given previous message (e.g., identified by a message identifier such as a counter), and including a maximum number of retransmissions required for the message (e.g., until an acknowledgment is received).

[0134] FIG. 10 shows a signaling diagram of a preamble exchange including reliability information according to an embodiment.

[0135] According to this embodiment, the reliability settings REL_A and REL_B (e.g., reliability setting 402 in FIG. 4) are exchanged in the preamble phase, for example, in a modified Pre_AB message 1002 and a modified Pre_BA message 1004 with corresponding new fields, and are applied to all subsequent messages in the protocol or to specific (e.g., marked or predetermined) messages that require reliability.

[0136] The underlying reliability protocol limits the number of pending acknowledgments and retransmissions (e.g., only once). Device A and device B may be configured, for example, when executing the preamble and PAKE protocols, to not accept or allow receipt of a given message until the previous message has been properly accepted or received and an acknowledgement provided.

[0137] For example, device A sends message M_A1, device B responds with message M_B1, device A responds with message M_A2, device B responds with message M_B2, M_A3, then M_B3, etc. One of the devices, say device A, is then configured not to accept message M_Bi before message M_A(i-1) has been acknowledged.

[0138] In a first example, upon receiving the reliability parameters REL_A and REL_B in the Pre_AB and Pre_BA messages, devices A and B are configured to apply the reliability parameter that ensures the highest reliability from the two sets of reliability parameters. For example, if the reliability parameter REL_A requires a maximum of two retransmissions and the reliability parameter REL_B requires a maximum of three retransmissions, then both devices A and B are configured to perform a maximum of three retransmissions.

[0139] In a second example, upon receiving the reliability parameters REL_A and REL_B in the Pre_AB and Pre_BA messages, devices A and B are configured to apply the reliability parameter that ensures the lowest reliability from the two sets of reliability parameters. For example, if the reliability parameter REL_A requires a maximum of two retransmissions and the reliability parameter REL_B requires a maximum of three retransmissions, both devices A and B are configured to perform a maximum of two retransmissions.

[0140] In a third example, upon receiving reliability parameters REL_A and REL_B, devices A and B are configured to apply the reliability parameter requested by the other party. For example, if reliability parameter REL_A requires a maximum of two retransmissions and reliability parameter REL_B requires a maximum of three retransmissions, devices B and A will retransmit a maximum of two and three times, respectively.

[0141] The reliability parameters EL_A and REL_B are pre-configured as a set of four possible configurations (binary-encodeable in 2 bits) corresponding to different parameters, for example. In one example, the preamble field contains only an identifier that identifies the selected configuration.

[0142] In the above example, the possible configurations correspond to configurations of increasing reliability, and devices A and B are configured to select, for example, the configuration that offers the most / least reliability based on pre-deployed and / or configurable policies.

[0143] Some networks have MTU size limitations. While SPAKE2+ message lengths are short, future uses of the PAKE protocol may include longer messages. Therefore, determining how to fragment messages and transmit them reliably is a challenge.

[0144] FIG. 11 illustrates a block diagram of a lower layer protocol configuration for fragmentation handling, according to an embodiment.

[0145] Thus, in one embodiment, reliability parameters exchanged during the initial configuration phase (e.g., exchanged in the Pre_AB and Pre_BA messages of the preamble phase of SPAKE2+) include an MTU parameter (e.g., MTU parameter 407 of FIG. 4). The exchanged MTU parameter references the physical layer MTU of device A, device B, or devices A and B. This MTU parameter, together with the PAKE version (e.g., PAKE version 404 of FIG. 4), provides an indication of fragmentation requirements, such as fragmentation size and / or number of fragments, for subsequent messages.

[0146] In one embodiment, devices A and B are unaware of the allowed MTU (e.g., it is pre-configured), and therefore messages exchanged during the initial configuration phase (e.g., preamble phase in SPAKE2+, SPAKE2, PAKE, or another SEP) contain parameters such as the size of subsequent messages in the protocol, which can derive / determine the fragmentation requirements for subsequent protocol messages, e.g., whether fragmentation is required for a particular message in the subsequent protocol, and how many fragments.

[0147] These parameters are used to configure the fragmentation process for lower layer protocols.

[0148] As shown in FIG. 11, the lower layer protocol (LLP) 402 is configured to handle both fragmentation and reliability.

[0149] The configuration (CONF) of the lower layer fragmentation protocol is implicit, since the lower layer protocol 402 can monitor the length of the message (MSG) passed / forwarded by the upper layer protocol (HLP) 401, determine the required number of fragments of the fragmented message (FRG-MSG) based on that, and determine certain reliability parameters based on this number. This configuration may also be explicit, for example by passing / forwarding the maximum size of a subsequent message, for example a PAKE message, in an initial message, for example a preamble message of a PAKE or another SEP.

[0150] The above parameters (e.g., MTU size and / or message size) are used to fragment certain messages in the protocol shown in FIG. 3; in particular, in one embodiment, messages PAKE1, PAKE2, PAKE3, and PAKE4 are fragmented, with messages PAKE1 and PAKE2 being most likely to require fragmentation.

[0151] In one example, the fragment includes a fragment identifier.

[0152] In another example, a configuration message instructs the lower layer fragmentation protocol whether subsequent messages sent, for example by device A, should be fragmented and sent together. For example, device A requests the transmission of messages 1 and 2, each 1200 bytes long, when the MTU is 1000 bytes. If the fragments cannot be sent together, a total of four fragmented messages must be sent (e.g., 1000 bytes, 200 bytes, 1000 bytes, and 1000 bytes). If the fragments can be combined, only three fragmented messages must be sent (e.g., 1000 bytes, 1000 bytes, and 400 bytes).

[0153] In one embodiment, the receiver is configured not to respond until all fragments of a particular message, eg, PAKE1, have been received and reassembled.

[0154] The underlying reliability / fragmentation protocol running on a device (e.g., device A) needs to request from another device (e.g., device B) certain fragments (fragments of a given PAKE message) that have not been received, such as those that were received before a timer expires. Alternatively, the device also acknowledges received fragments.

[0155] An entity within the device (e.g., the PAKE protocol (PAKE control unit or function 46 in FIG. 4) itself, or an underlying reliability / fragmentation protocol in place of the upper layer protocol 401) is configured not to send a subsequent (PAKE) message until all fragments of the previously expected (PAKE) message have been received.

[0156] The reliability parameters applied by the lower layer reliability / fragmentation protocol depend on whether a given message requires fragmentation, and further depend on the number of fragments.

[0157] In one example, if a message does not require fragmentation, it will need to be retransmitted within a given timeout. If a message needs to be fragmented into multiple pieces, a higher timeout value applies.

[0158] In another example, the lower layer reliability / fragmentation protocol is configurable as to how many fragments of a message can be sent simultaneously.

[0159] In one embodiment, a party requests a particular fragment of a message if it is not received before a timeout has elapsed. For example, if message PAKE1 needs to be fragmented into two fragments, device B is configured to request the second fragment from device A if the second fragment has not been delivered by a given timeout.

[0160] This fragmentation functionality (and such lower-layer trust and fragmentation protocols) applies not only to the PAKE protocol, but also to similar cryptographic protocols or those involving large messages, or other applications requiring fragmentation (e.g., due to the use of quantum-resistant primitives), including, for example, digital signatures or key encapsulation mechanisms.

[0161] In an alternative embodiment, the SEP including the PAKE is configured to handle fragmentation of a particular message, for example, by a higher layer, eg, a lower layer protocol, that provides fragmentation / reliability functionality to the SEP.

[0162] As described in connection with Figures 2 and 3, upon receiving the PAKE1 and PAKE2 messages, both the first device (e.g., device A) and the second device (e.g., device B) are configured to derive a private key that can be used to protect subsequent communications.

[0163] In a specific example, SPAKE2+ or another SEP defines that a protocol transcript TT (e.g., protocol transcript 406 in FIG. 4, or one defined in "SPAKE2+, an Augmented PAKE (Draft)" by Taubert, T. et al.) is generated by a KDF (e.g., PBKDF control unit or function 44 in FIG. 4) based on input parameters of SPAKE2+ (or another SEP) and the PBKDF.

[0164] The encoded bit string TT of the protocol transcript is used to derive keys Ka and Ke. Key Ka is used to generate the confirmation messages (c_B, c_A) exchanged in the PAKE3 and PAKE4 messages. Key Ke is used to protect subsequent traffic.

[0165] However, the initial preamble exchange and subsequent PAKE messages are not properly linked, since the protocol transcript does not directly depend on the information exchanged in the preamble. Furthermore, the Ke key is a single key used to protect traffic, whereas certain protocols, such as the 3GPP protocol, require two keys: one for integrity and one for encryption.

[0166] FIG. 12 shows a flow diagram of a key derivation procedure based on exchanged preamble information according to an embodiment.

[0167] In this embodiment, the KDF (eg, PBKDF) is enabled to use the input information exchanged in the preamble phase.

[0168] In step 1120 in the preamble phase, for example, a session ID (SID) and / or random values ​​R_A and / or R_B are exchanged between devices A and B. This information is used in step 1130 to derive a protocol transcript (TT).

[0169] Then, in step 1140, the Ke key is derived from the protocol transcript.

[0170] In step 1150, the Ke key is used to derive, using a KDF (e.g., PBKDF), two keys K_AB and K_BA that are used to protect communications from a first device A to a second device B and vice versa.

[0171] Then, in step 1160, K_AB (or K_BA) is used to derive integrity and confidentiality keys K_AB_i and K_AB_c (or K_BA_i and K_BA_c) using a KDF (e.g., PBKDF) to ensure the integrity and confidentiality of messages sent from device A to device B (or from device B to device A).

[0172] In one embodiment, the integrity and confidentiality keys K_AB_i and K_AB_c, and K_BA_i and K_BA_c are derived directly from Ke by a single KDF invocation.

[0173] Such an embodiment in which an integrity key and a confidentiality key are generated is useful, for example, in the context of the 3GPP standard, in which the integrity key is used to generate a message authentication code, for example by using the 5G New Wireless Integrity Algorithm (NIA), and the confidentiality key is used to encrypt a message, for example by using the 5G New Wireless Encryption Algorithm (NEA).

[0174] FIG. 14 illustrates a schematic signaling and processing diagram for an improved SPAKE process or other SEP with reduced round trips, according to an embodiment.

[0175] The protocol design of FIG. 3 (preamble and PAKE phases) requires a total of three round trips before a first device (eg, device A) and a second device complete the exchange.

[0176] However, using a protocol that involves multiple round trips increases the latency of the protocol, which in turn increases the usage of, for example, communication or energy resources. When a user is involved, for example, when a user uses device A (e.g., a commissioning tool such as an app running on a phone) to configure device B, the user must wait until the protocol is executed, resulting in a poor user experience due to the increased latency.

[0177] Thus, in the embodiment of Figure 14, the messages of Figure 3 are rearranged to require only two total round trips, thereby reducing protocol latency and therefore improving the user experience, which is also useful when the protocol is run over constrained networks and / or on a large number of devices simultaneously.

[0178] A way to achieve only two round trips, and therefore a more efficient protocol, is to have the second device (e.g., device B) send the first PAKE1 message along with the Pre_BA message in step 902. This is feasible because, upon receiving the Pre_AB message from the first device (e.g., device A), the second device already performed PBKDF in step 901 to generate the PAKE (e.g., SPAKE2+) parameters needed for the first message, PAKE1. Note that this requires rearranging some messages or operations within some PAKEs, e.g., SPAKE2+, due to their unbalanced nature. For example, a second value could be sent in the first PAKE1 message and a first value in the second PAKE2 message. For the process described in section 9 of "SPAKE2+, an Augmented PAKE (draft-bar-cfrg-SPAKE2plus-03)" by T. Taubert et al., July 6, 2021, value Y is sent in the first PAKE1 message and value X is sent in the second PAKE2 message, where values ​​X and Y are defined in the SPAKE2+ paper. Note also that if the second communication device has not previously been provided with or configured with a password or password-based value, the second communication device may need to request from the user or a third communication device to obtain the password or password-based value, e.g., the verification value pair L and w0 in SPAKE2+.

[0179] It should be noted that such a protocol design puts device B at increased risk of a denial of service attack by an attacker sending a large number of initial Pre_AB messages, e.g., exhausting the available PSI. However, to avoid this problem, this embodiment is combined with the above restriction embodiment involving a limit setting based on the limit parameter 405.

[0180] It should be further noted that the first device (e.g., device A) only needs to process PAKE1 if the Pre_BA message is successful or acceptable, e.g., if the check (R_A'=R_A) in step 903 is positive and the PBKDF is properly performed in step 905. This also applies if messages Pre_BA and PAKE1 are combined into a single message. If these verifications are confirmed, device A proceeds to process message PAKE1, calculates its public shares and sends a PAKE2 message in step 905, derives a key for subsequent communications (e.g., as described in FIG. 12), and sends PAKE3 in step 907. These messages PAKE2 and PAKE3 optionally include R_B'.

[0181] Upon receiving R_B', PAKE2, and PAKE3, device B checks the consistency of R_B' and processes PAKE2 to verify the accuracy of PAKE3 in step 908. If this is true, the security keys for subsequent communications (as described in FIG. 12) can be derived in step 910, and message PAKE4 can be calculated and sent to device A in step 911 as confirmation that the protocol was successful. If R_B and R_B' do not match, device B can abort the process, for example with an error message or report (e.g., to identify a man-in-the-middle or other attack), or abort the executed protocol or restart the protocol.

[0182] Finally, in step 912, device A derives the shared symmetric secret from the PAKE4 message and verifies the confirmation in step 913.

[0183] While in the embodiment of Figure 3 a Finish message (FM) is sent by the second device (e.g., device B) to the first device (e.g., device A) so that the first device knows that the second device has (successfully) finished the exchange, in the present embodiment of Figure 14 this Finish message is not necessary because the first device infers the state of the second device from receiving the fourth message, PAKE4. If some fields in the Finish message are required by device A, those fields are sent together with the PAKE4 message.

[0184] FIG. 15 schematically illustrates a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. In FIG. 15, a source UE (S-UE) and a target UE (T-UE) wish to establish secure communication via a UE-to-UE relay (UE-UE) using a PC5 interface. For example, the source UE is a smart health sensor, the target UE is a smart watch, and the UE-to-UE relay is a mobile phone. The three UEs are connected to a core network (CN) via a radio access network (RAN). The devices will also be out of coverage at some point. Therefore, the UEs are initially configured in steps 1501, 1502, and 1503. These configuration steps include a request by each of the UEs to the CN requesting authorization to use the UE-to-UE relay service. This request is initiated upon primary authentication of each of the UEs. The authorized UEs are provided with their respective security keying material for the subsequent discovery phase and / or authorization information for setting up a secure communication channel in steps 1501, 1502, and 1503. In steps 1504 and 1505, the source UE and the UE-to-UE relay and the target UE and the UE-to-UE relay perform a discovery process, for example, as described in TS33.503. For example, the UE-to-UE relay is the announcing UE, and the target UE and the source UE are monitoring UEs. The UEs also perform Model B discovery, which includes two discovery messages. In steps 1506 and 1508, for example, in the case of Balanced PAKE, a password is entered into the target UE and the source UE. The password, or a value derived therefrom, is also obtained from the parameters configured in steps 1501 and 1503, for example, in the case of Extended PAKE. The source UE and the target UE then establish a secure and authenticated channel. To this end, the source UE and the target UE perform the protocol (procedure) of FIG. 3 or FIG. 14 via the UE-to-UE relay. In step 1507, the source UE and the target UE exchange one or two messages corresponding to the preamble messages described in the above embodiments. These messages may include a session ID, a random value, an indication of PBKDF parameters, or any other parameters mentioned above.These messages also include a relay service code or any identifier related to the type of communication service being established. In step 1509, the source UE and target UE exchange PAKE messages to establish a secure authenticated channel. The source UE and target UE also optionally exchange additional messages for key verification. Finally, in step 1510, the source UE and target UE can communicate securely via the UE-to-UE relay.

[0185] Note that for efficiency purposes, preambles are exchanged during the detection phase.

[0186] Note that the detection phase itself is also based on PAKE, with or without a preamble.

[0187] In one embodiment, which may be combined with other embodiments, the security establishment between the source UE (S-UE) or target UE (T-UE) and the UE-to-UE relay (UE-UE) is also performed as shown in the above SEP embodiment, as in the procedure introduced in Figure 15. For example, the security establishment between the T-UE and UE-UE / S-UE and UE-UE is integrated / performed in / after steps 1504 and 1505, for example, as shown in Figure 17.

[0188] FIG. 17 schematically illustrates a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment. In FIG. 17, steps 1701, 1702, and 1703 refer to initial authorization and parameter provisioning. Step 1704 may refer, for example, to an initial detection message or initial direct communication request from S-UE to UE-UE. Step 1705 may refer, for example, to an initial detection message or initial direct communication request from UE-UE to T-UE. In step 1706, one or more steps or messages described in the embodiment are executed. Note that step 1705 includes fields in Pre_AB as described in the above embodiment. Step 1707 is, for example, a direct communication accept message. This step includes fields in the last message in the embodiment, for example, a last confirmation message or a PAKE4 message. In step 1708, one or more steps or messages described in the embodiment are executed. Step 1709 is a direct communication accept, which includes fields in the last message in the embodiment, for example, a last confirmation message. In step 1710, one or more steps or messages described in the embodiment are executed.

[0189] In a related embodiment that may be combined with other embodiments, the password used in the previous embodiment and described in FIG. 17 is configured during the initial authorization and parameter provisioning phase, generated by the device and exchanged with another device over an out-of-band (OOB) channel, or entered by the user.

[0190] In a related embodiment, which may be combined with other embodiments, the SEP used in the previous embodiment and illustrated in FIG. 17 relies on a balanced or extended PAKE.

[0191] In a related embodiment that can be combined with other embodiments, when a PAKE-based SEP involving devices such as an S-UE, a UE-UE, or a T-UE is performed, an access token is exchanged that includes an identifier, an identifier of the associated session, a user identifier, an identifier of a user group, privileges, access rights, etc. This information in the token is signed by the CN or an application in the CN and provided to the UE during the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in FIG. 17). After being delivered to the UE, this token needs to be stored in a secure location, e.g., on a SIM card in the EU. This token needs to be exchanged over a secure channel, e.g., after the SEP is performed.

[0192] In a related embodiment that may be combined with other embodiments, upon execution of a PAKE-based SEP involving a device, e.g., an S-UE, a UE-UE, or a T-UE, the device receives an access token that includes an identifier, an identifier of the associated session, a user identifier, an identifier of a user group, privileges, access rights, etc. This information in the token is signed by the CN or an application in the CN and provided to the UE during an initial authorization and provisioning phase (e.g., steps 1701, 1702, and 1703 in FIG. 17). The token may be received over a secure channel, for example, after an SEP (e.g., a PAKE-based SEP) is executed. The UE receiving the token has a policy in place during the initial authorization and provisioning phase (e.g., steps 1701, 1702, and 1703 in FIG. 17) that enables the UE transmitting the token to determine whether it is authorized to use the UE-UE service. Such a communication flow is shown in Figure 17b, similar to Figure 17, where DCR refers to Direct Communication Request, DCA refers to Direct Communication Accept, and steps 1724, 1727, and 1730 (Further Authorization (FA)) are based on such authentication tokens. In step 1720, Initial Authorization (IA) and Parameter Provisioning (PP) are performed.

[0193] In a related embodiment that can be combined with other embodiments, the PAKE1 message is sent in an initial DCR message from the S-UE to the UE-UE and then to the T-UE. The PAKE2 message is then sent back in a DCA message from the T-UE to the UE-UE relay and then to the S-UE, for example, as performed in steps 1721, 1722, 1725, and 1728 in Figure 17b. A device or method according to this embodiment uses implicit key confirmation, which does not include PAKE3 and PAKE4 messages. A device according to this embodiment sends a message that includes fields related to Pre_AB in the DCR message to indicate the password to use, parameters for key derivation, etc.

[0194] In a related embodiment shown by Figure 18, steps 1801, 1802, and 1803 refer to the initial authorization and parameter provisioning. Steps 1804 and 1805 refer to the initial discovery request message. Steps 1806 and 1807 refer to the subsequent discovery response. Step 1808 refers to the establishment of a secure PC5 link between the S-UE and the UE. Step 1809 refers to the establishment of a secure PC5 link between the UE and the T-UE. Step 1810 refers to the establishment of a secure PC5 (L2) or communication (L3) link between the S-UE and the T-UE. The security aspects in steps 1808, 1809, and 1810 are based on a PAKE-based SEP as described in the previous embodiment shown by Figure 17, optionally with a further authorization phase relying on authorization tokens.

[0195] In a related embodiment, which may be combined with other embodiments, the access token contains data related to a password used in the SEP, allowing a PAKE-based SEP to be linked to a token that is exchanged at a later stage.

[0196] In a related embodiment that can be combined with other embodiments, when extended PAKE is used in the SEP, the UE-UE relay is configured with a password-based value (such as the verification value pair L and w0 in SPAKE2+) to ensure that it is difficult for the UE-UE relay to impersonate the S-UE or T-UE. Accordingly, step 1706 of Figure 17 includes a Pre_AB message or a PAKE1 message that is first sent by the T-UE to the UE-UE device. Accordingly, step 1708 of Figure 17 includes a Pre_AB message that is first sent by the UE-UE device to the S-UE, to which the S-UE responds with a Pre_BA and / or PAKE1 message.

[0197] In a related embodiment that can be combined with other embodiments, the S-UE and T-UE are configured with password-based values ​​(such as the verification value pair L and w0 in SPAKE2+) to ensure that it is difficult for these devices to impersonate the UE-UE relay when extended PAKE is used in the SEP. Accordingly, step 1706 of FIG. 17 includes a Pre_AB message that is first sent by the T-UE to the UE-UE device and returned by the UE-UE relay to the T-UE device via a PAKE1 message. Accordingly, step 1708 of FIG. 17 includes a Pre_AB message or a PAKE1 message that is first sent by the UE-UE device to the S-UE.

[0198] In a related embodiment that can be combined with other embodiments, when extended PAKE is used in the SEP, the T-UE is configured with a password-based value (such as the verification value pair L and w0 in SPAKE2+) to ensure that it is difficult for the T-UE to impersonate the S-UE. Thus, step 1710 of Figure 17 includes a Pre_AB message or PAKE1 message that is first sent by the S-UE to the T-UE device.

[0199] In a related embodiment, which may be combined with other embodiments, the balanced PAKE is a CPAKE and the extended PAKE is an OPAQUE.

[0200] In a related embodiment, which can be combined with other embodiments, the key confirmation messages in PAKE3 and PAKE4 are performed implicitly, such as in CPAKE, making the exchange between PAKE3 and PAKE4 unnecessary.

[0201] In a related embodiment that may be combined with other embodiments, for example during the initial authorization and parameter provisioning phase associated with FIG. 18, the UE-to-UE relay, source-UE or target UE is configured with a user information ID, a relay service code, a UE-to-UE relay layer indicator, a traffic type (IP or non-IP), and the UE-to-UE relay layer indicator indicates whether a particular RSC is providing 5G ProSe Layer-2 or Layer-3 UE-to-UE relay service, a default destination Layer-2 ID, security related parameters for discovery or PAKE such as a password or password-based value, or further authorization process parameters such as an authorization token, or policy or cryptographic key material for validating the token, validity time of the parameters.

[0202] In related embodiments, the provisioning of security parameters is performed by a 5G Direct Discovery Name Management Function (DDNMF), a ProSe Key Management Function (PKMF), or a PCF.

[0203] In a related embodiment that can be combined with other embodiments, the necessary discovery keys, passwords, public keys, and / or policies are configured during the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in FIG. 17). These are necessary to discover other UEs, perform (PAKE-based) SEPs, verify access tokens, and / or verify the UE's authorization based on the tokens and policies. The PKMF is responsible for parameters such as public keys. The UE connects to the DDNMF to obtain the PKMF address. If multiple networks are involved and some of the devices are roaming (e.g., the source UE), the PKMFs of each network (home and serving) need to share some of their parameters with each other, particularly the public keys used by each network and linked to the private keys. Once this sharing is performed, the relevant public keys can be configured during the initial authorization and provisioning phase. Once this is performed, the PKMF of the UE (e.g., the source UE) is responsible for signing the access token. Additionally or alternatively, when a UE (roaming) performs the initial authorization and provisioning phase, it first connects to its PKMF and is routed from its own PKMF to a PKMF (i.e., the PKMF of the home network) that is responsible for discovery, including management of access tokens, and PC5 keying material. This PKMF is responsible for managing the public key linked to the private key used to sign the access token. This PKMF manages the authorization policy or relies on the PCF. Thus, the PKMF obtains the UE's policy (locally or from the PCF) and also allocates access rights for the UE and places them in an access token that can be signed later. This signed access token is then configured in the UE.

[0204] In a related embodiment that may be combined with other embodiments relating to in-coverage and out-of-coverage parameter provisioning, password provisioning can be performed in either in-coverage or out-of-coverage in step 0. When provisioning is performed while the UE is in-coverage, the UE is configured with one or more passwords, "raw passwords" or "password-derived tokens." Each "raw password" or "password-derived token" is associated with "metadata." The "metadata" includes a "password hint," "expiry date," and "access rights." The "password hint" field indicates the password to use, the "expiry date" field indicates the password validity period, and the "access rights" field indicates authorization to provide the password. The bit string used as the "password" in the PAKE is calculated as the KDF of the "raw password" and the associated metadata field. In the case of extended PAKE, the "password-derived token" is derived from the "password" itself. As with other embodiments, when the UE is in-coverage, parameters can be received from the 5G PKMF and 5G DDNMF.

[0205] In a related embodiment, which may be combined with other embodiments relating to in-coverage and out-of-coverage parameter provisioning or may be used independently, during in-coverage provisioning, the UE is also provisioned with an “out-of-coverage policy” that determines whether the UE will use a temporary password (or credentials, e.g., a key) entered or provisioned by the user when the UE is (or was) out-of-coverage. When out-of-coverage, the “out-of-coverage policy” can be provisioned to the UE using the temporary password entered by the user, if enabled. This “out-of-coverage policy,” configured during the initial authorization and provisioning phase when the UE is in coverage, is also used to control other communication or security aspects when the UE is out-of-coverage, including a) the security protocols that must / are allowed to be used, or b) the security credentials to use. For example, the UE can set up a secure PC5 connection via a UE-to-UE relay when out-of-coverage, e.g., based on some of the above embodiments or, e.g., based on some solutions in TR33.740. Note, however, that this is only permitted if the UE has a policy configured to allow it. For example, if the UE is configured when in coverage (e.g., according to the above embodiment or the configuration in Solution #3 in TR33.740), the UE can be configured with a policy regarding the type of protocol or configuration parameters to be used out of coverage, e.g., parameters related to Solution #4 in TR33.740. When a UE, e.g., a source UE, performs a detection phase using a UE-to-UE relay, the UE can send a direct communication request message. If the UE is out of coverage and a pre-configured policy allows it, the UE can use the out-of-coverage solution. In this case, the UE can either send a direct security request message as in Solution #4 in TR33.740, or prompt the user to enter a short password (e.g., if no password is available or if the password has expired).This DCR message includes a flag indicating the solution selection (e.g., due to out-of-coverage reasons), but this flag is implicitly applied to the transmission of out-of-coverage parameters. For example, if a UE-to-UE relay receives a DCR message containing a specific field, such as an authorization token, in step 2 of Solution #4 in TR33.740, the UE-to-UE relay proceeds to step 3 of Solution #4 in TR33.740 instead of step 3 of Solution #3 in TR33.740. For example, when a UE-to-UE relay receives a DCR message with the out-of-coverage flag, the UE-to-UE relay prompts the user to enter an out-of-coverage password (if allowed by policy). Furthermore, upon receiving this DCR message, the UE-to-UE relay device needs to check whether the connection environment is out-of-coverage (based on the policy received in coverage) and whether an out-of-coverage solution is applicable. If this is not the case, the UE-to-UE relay does not respond to the DCR message, or instead the UE-to-UE relay requests a DCR message from the UE containing in-coverage parameters to enable the use of the in-coverage solution for PC5 security establishment.

[0206] In a related embodiment, which may be combined with other embodiments or used independently, relating to parameter provisioning and solutions for use in coverage and out-of-coverage, it is advantageous to perform verification of the type and parameters of the solution used before the key establishment and authentication phase. In particular, it is advantageous to perform source UE authorization verification (step 4 of Solution #4 in TR 33.740) before the direct authentication and key establishment procedure (step 3 of Solution #4 in TR 33.740), where source UE authorization is performed by verifying the authorization token received in the DCR message (step 2 of Solution #4 in TR 33.740). The advantage of this is a reduced risk of denial of service. It is also advantageous to save resources if the UE is not authorized (step 3). In the case of Solution #4 in TR 33.740, the verification includes verification of the authorization token and / or verification of the out-of-coverage environment. Note that this also applies to e.g. Sol#4, since the verification of source UE authorization in Sol#4 is based on the authorization token shared in the DCR message, and as described in other embodiments, the sharing must be performed in a secure manner by default. The receiver (e.g., UE-to-UE relay) can check the authorization without delay, since it already has the authorization token at that point (after receiving the DCR message). This is not always possible. For example, step 1724 in Figure 17b is not performed before step 1723, since the authorization token exchanged in step 1724 is protected based on the secure link established in step 1723.

[0207] Therefore, in a further related embodiment, the exchange of authorization tokens is integrated into step 1723 itself. For example, authorization tokens are exchanged as soon as keys are established in step 1723. For example, referring to FIG. 14, the authorization token is already included in message PAKE2. When PAKE (or, in general, SEP) is integrated / implemented by Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages (and / or Direct Security Mode Command and Direct Security Mode Complete) according to TS36.536, authorization tokens are exchanged in those messages as soon as the underlying SEP (e.g., carried by the Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages) allows for the protection of authorization tokens. This requires defining a new message field "authorization token" that allows for indicating that one of those messages contains one or more protected authorization tokens.

[0208] In a related embodiment, the authorization tokens exchanged in step 2 are advantageously protected as follows: instead of using the approach in TS33.503 clause 6.3.5.2 (which can only protect up to 256 bits of data), and if the key selected in step 1 in TS33.503 clause 6.3.5.2 is used to generate a keystream (step 2 in TS33.503 clause 6.3.5.2) that is used to encrypt the private fields of the message (step 3 in TS33.503 clause 6.3.5.2), the key selected in step 1 in TS33.503 clause 6.3.5.2 is used as (or to derive) the encryption key that is used in combination with the NR Encryption Algorithm (NEA) to encrypt the private fields of the message, e.g., the authorization tokens. The advantage of this approach is that it allows the authorization tokens (longer than 256 bits) exchanged in step 2 of Sol#4 in TR33.704 to be protected. Another advantage is that this same technique can be used to protect the authorization token sent by the UE-to-UE relay to the source UE, for example in step 5 of Sol#4 in TR33.704, where the input fields to the NEA algorithm are different, e.g., the DIRECTION field is set to 0 in step 2 and to 1 in step 5.

[0209] In a related alternative embodiment, authorization tokens are not exchanged in the DCR message (step 2 of Solution #4 in TR 33.704), but may be advantageously exchanged just prior to authorization token verification (step 4 of Solution #4 in TR 33.704) and the direct authentication and key establishment procedure (step 3 of Solution #4 in TR 33.704), as in other embodiments in this application. An advantage of this embodiment is that both authorization tokens associated with the source UE and the UE-to-UE relay can be protected in a similar manner, i.e., by using the key derived during the direct authentication and key establishment procedure. A further advantage is that this embodiment does not require any changes to TS 33.503 clause 6.3.5 used to protect the DCR message, since the current protection is limited to a maximum of 256 bits.

[0210] In a related embodiment, which may be combined with other embodiments relating to in-coverage and out-of-coverage parameter provisioning or may be used independently, negotiation regarding the type of protocol or parameters to use (in-coverage or out-of-coverage) is negotiated, signaled, or verified during the initial detection phase.

[0211] In this embodiment, shown in FIG. 21, in step 2101, the UE performs initial authorization and parameter provisioning for in-coverage and out-of-coverage situations. This step includes configuring various solution / SEP parameters for in-coverage and out-of-coverage security establishment and authorization. In step 2102, the source UE and UE-to-UE relay perform a detection phase. In step 2103, the source UE determines the out-of-coverage (in-coverage) situation and selects a security solution / SEP and / or security parameters appropriate for the out-of-coverage (in-coverage) situation. In response, the source UE formulates a direct communication request based on the selected out-of-coverage (in-coverage) solution and security parameters, which includes a SEP identifier. In step 2104, the UE-to-UE relay receives the DCR message and determines whether the DCR message implicitly or explicitly includes the out-of-coverage (in-coverage) solution / SEP parameters. The UE-to-UE relay then checks whether the requested solution / SEP and security parameters are compatible with the out-of-coverage (in-coverage) situation and whether the policy deployed in step 2101 and the authorization information received in step 2103 allow the use of said solution / SEP and security parameters. This policy is evaluated, and if the result is positive, the UE-to-UE relay continues to execute (or facilitates execution of) the requested out-of-coverage (in-coverage) solution / SEP. Alternatively, if the result is negative, the UE-to-UE relay may, based on calibration, indicate a source UE policy inconsistency and request another DCR message including the requested solution / SEP and security parameters. In step 2105, the UE-to-UE relay performs one of the following alternative steps: Step 2105-A: Send a message to the source UE to continue with the in-coverage solution; Step 2105-B: Send a message to the core network to continue with the out-of-coverage solution.Step 2105-C sends a message to the source UE indicating that security establishment based on the exchanged parameters is not feasible and requests alternative parameters. Note that the above steps can be repeated for the security establishment process and authorization between the target UE and the UE-to-UE relay. Note that the above process shows how the UEs use the DCR message to signal and agree on the solution and security parameters to be used.

[0212] This signaling and agreement phase is also performed during the detection phase.

[0213] In a related embodiment, the UE-to-UE relay indicates whether it is in-coverage or out-of-coverage in a detection message to the source UE or target UE. This can be done in detection model A if the UE-to-UE relay acts as an announcing UE. This can be done in detection model B if the UE-to-UE relay sends a reply detection message to the source UE indicating whether it is in-coverage or out-of-coverage.

[0214] In related embodiments, the Relay Service Code indicates the type of service used by the 5G ProSe source / target and UE-to-UE relay, and thus the RSC implicitly indicates the type of preferred (security) solution / procedure (e.g., in-coverage or out-of-coverage, i.e., with or without core network support). For example: The source UE uses multiple (eg, two) different types of relay service codes to discover UE-to-UE relays that can provide for the establishment of a secure communication link with or without network assistance. For example, the service code indicates the type of security procedures that are required and / or preferred.

[0215] A related embodiment in which signaling and agreement are performed in the discovery phase is shown in Figure 22. In Figure 22, step 2202 refers to the initial configuration and authorization step in which the source UE / target UE / UE-to-UE relay device are configured, step 2202 refers to the initial discovery, which is Model A or Model B, step 2203 is a policy evaluation in which at least one of the source UE, target UE, and UE-to-UE relay device decides the preferred solution to use (e.g., in-coverage or out-of-coverage solution, i.e., security procedure with network support or security procedure without network support), and step 2204 refers to the initial message used to trigger security setup of the UE-to-UE relay security.

[0216] In a variant that can be combined with other variants, in step 2202, the source UE sends a detection request message (detection model B) that is forwarded by the UE-to-UE relay to the target UE. The target UE responds with a response detection message to the source UE via the UE-to-UE relay. In another variant, in step 2202, the source UE sends an announce message (detection model A), which is received by the UE-to-UE relay and forwarded to the target UE. In another variant, in step 2022, the UE-to-UE relay is a device that sends announce / invite messages to the source UE and target UE and, optionally, receives response messages from the source UE and target UE. In these request and announce detection messages, the source UE, the UE-to-UE relay, and / or the target UE indicate the configuration of the in-coverage or out-of-coverage situation and the type of in-coverage / out-of-coverage solution (i.e., security procedures with network support or security procedures without network support). In the response detection message, the UE indicates its configuration and / or selection.

[0217] In a variation that can be combined with other variations, in step 2203, one or more of the devices evaluate configured policies and determine which solution to use, which solution is preferred to use, or which solution is proposed to be used. For example, the target UE has a policy configured to select a preferred solution, and the preferred solution is proposed (e.g., by a message) to the UE-to-UE relay and the source UE. For example, the target UE is configured (by a message) to indicate one, two, or more solutions in a preferred order of use. For example, upon receiving the message sent by the target UE, the source UE verifies the target UE's preferred selection and evaluates it against its own evaluation of the policy, e.g., prioritizing either its own preference or the preference of the other party. For example, the source UE, UE-to-UE, and target UE all evaluate policies and select a preferred solution. Proposals and approval / confirmation exchanges then occur between the source UE, UE-to-UE, and target UE.

[0218] In a variation that can be combined with other variations, step 2202 and step 2203 occur simultaneously, for example, step 2203 occurs at the target UE upon receipt of the solicit detect message and before sending the reply detect message.

[0219] In a variation that can be combined with other variations, step 2203 occurs at the source UE upon receipt of the response detected message.

[0220] In a variant that may be combined with other variants, the selection of an inter-UE relay, e.g., as performed during discovery, depends on the evaluation of a policy that specifies a preferred out-of-coverage / in-coverage solution. For example, an out-of-coverage inter-UE relay is given lower priority compared to an in-coverage inter-UE relay. For example, an in-coverage inter-UE relay that allows out-of-coverage (e.g., because its security parameters are up-to-date / not outdated) is given higher priority compared to an in-coverage inter-UE relay with out-of-coverage parameters that are out of date.

[0221] In a variation that can be combined with other variations, the UE (e.g., UE-to-UE relay) receiving the message in step 2204 still does not agree with the selection made by the transmitting UE (e.g., source UE) and responds in a manner similar to that in the above embodiments and / or described in FIG. 21.

[0222] In a variant, the UEs require UE-to-UE communication for emergency reasons. In this case, the UE, e.g., source UE, includes an emergency indication such as "emergency RSC", e.g., when distributing the discovery message or sending the initial DCR message. The UE-to-UE relay receiving this indication decides how to process the message, e.g., based on its context (e.g., coverage situation) and / or policies / configuration. For example, the source / target UE and / or the UE-to-UE relay may perform one or more of the following actions depending on the context and policies:

[0223] Request / provide emergency services in accordance with policy;

[0224] Log emergency requests based on policy;

[0225] The emergency request is treated as a UE-to-UE communication and / or as a UE-to-network communication depending on the situation, e.g., if the UE is out of coverage, the communication is treated as a UE-to-UE communication (i.e., the communication is directed to other UEs in the area), and if in coverage, the communication is treated as a UE-to-network communication (i.e., the communication is directed to the network) and / or as a UE-to-UE communication (i.e., the communication is directed to other UEs in the area).

[0226] Provides / requires UE security capabilities and / or PC5 signaling security policy.

[0227] Sending instructions regarding emergency services (provided) to the core network based on policy;

[0228] Disable or do not apply security even if policy requires it under normal circumstances. This applies to the following cases:

[0229] Discovery messages exchanged between source UE and target UE via UE-to-UE relay.

[0230] Establishing security on PC5 links.

[0231] Allow / require the use of temporary (e.g., user-entered) credentials (e.g., passwords) to provide a minimum level of security based on policy.

[0232] This approach has the advantage that in emergency or safety-critical situations, communication via UE-to-UE relays is used, e.g., allowing two UEs that would normally not be able to talk to each other to actually talk to each other. For example, the source UE may be the UE of a person in need of help (e.g., under attack or having an asthma attack), and when the person requests help, a help / emergency message is distributed to other UEs nearby via the UE-to-UE relay, and in this way the person gets help quickly. For example, the source UE may be a tag attached to a piece of luggage, and if the tag loses connection with its UE (e.g., the UE of the owner of the luggage), the tag (acting as the source UE) will send an emergency message in an attempt to reach "that" UE.

[0233] In a related variation, the message sent by the source UE includes information related to the cause of the emergency or the UE / person requesting help (e.g., a description of the UE / person, or a description of the package).

[0234] In a related variation, the message sent by the source UE includes information related to the cause of the emergency or the desired target UE / person (e.g., a description of the UE / person).

[0235] In general, the above embodiments require a policy for selecting a preferred solution, in particular a preferred in-coverage and / or out-of-coverage solution (i.e., security procedures with or without network support). This policy is deployed in the source UE, the UE-to-UE relay, and / or the target UE. This policy includes one or more of the following:

[0236] which of the supported solutions is preferred or used or accepted by one or more of the involved devices, i.e. source UE, target UE and UE-to-UE relay, when in coverage or out of coverage;

[0237] which authorization mechanism is preferred or used by one or more of the involved devices, i.e. source UE, target UE and UE-to-UE relay, when in coverage or out of coverage;

[0238] The priorities assigned to different devices are used to determine which solution is prioritized, e.g., (1) if different devices have different configurations, and / or (2) the priority depends on the coverage status of each of the devices, e.g., if the source UE is in coverage and other UEs are out of coverage, the source UE's solution is prioritized, and if all UEs are out of coverage, a default priority list determines which UE's solution is used;

[0239] Which parameters of the supported solutions are preferred or used or approved when in coverage or out of coverage;

[0240] For example, whether communications are / are allowed to be established in emergency situations (e.g. emergency services) and what security credentials / security configurations / security mechanisms are required, e.g. whether null encryption and / or integrity algorithms are / are allowed;

[0241] Whether / how security parameters (such as passwords or keys) of the out-of-coverage solution are generated and / or entered when the device is out of coverage;

[0242] (Default) authorization capabilities or access rights to be assigned to generated and / or entered (temporary) credentials (e.g., passwords, keys) when other credentials (e.g., long-term credentials) expire and the UE (e.g., source UE and UE-to-UE relay) is out of coverage.

[0243] When multiple inter-UE relays are available, which inter-UE relay is prioritized depends on their status (e.g., in-coverage / out-of-coverage) and / or the status (e.g., in-coverage / out-of-coverage) of the source UE (and / or target UE). For example, in certain situations an in-coverage inter-UE relay is prioritized, while in other situations an out-of-coverage inter-UE relay is prioritized.

[0244] Which security method / procedure is used or prioritized for path switching or relay reselection, and based on which factors (e.g. coverage conditions, performance requirements, etc.), e.g. whether to use the standard security establishment procedure (e.g. the procedure used when no communication is available between source UE and target UE via UE-to-UE relay, e.g. Sol#3, #4 or #10 in TR33.740) or whether, for optimization purposes, to skip it and use an optimized procedure, e.g. by reusing the security context (e.g. security policy and security algorithms) already established from the previous PC5 unicast link, to (re)establish a secure communication link via a new relay (e.g. Sol#14 in TR33.740). For example, if a source UE and a target UE have a secure communication link via a first UE-to-UE relay established using security procedures without network assistance (because the first UE-to-UE relay was out of coverage), then when performing a path switch to move to a second UE-to-UE relay (which is in coverage and can provide security procedures with network assistance), the optimized security procedures (e.g., Sol#14 in TR33.740) will not be preferred.

[0245] For example, whether it is permitted to have multiple active connections between a source UE and a target UE via multiple UE-to-UE relays based on the UE's coverage situation, performance requirements, and / or resource constraints.

[0246] Priority of solution selection in the case of overlapping security associations using the same or different (types of) solutions. A first example of this is when a source UE initiates a first security association (e.g., using a DCR message) using an in-coverage (or out-of-coverage) solution and then (e.g., if a timer times out) also sends a second security association (e.g., using a second DCR message) using an out-of-coverage (or in-coverage) solution, at which point the source UE receives a response for the first security association. The policy specifies (by indicating a priority) which solution to use in such cases. The priority in the policy is applied, for example, by the UE-to-UE relay or the source UE. A second example of this is when a source UE initiates a first security association (e.g., using a DCR message) using an in-coverage (or out-of-coverage) solution with a first UE-to-UE relay, and then sends a second security association (e.g., using a second DCR message) using an in-coverage (or out-of-coverage) solution with a second UE-to-UE relay, at which point the source UE receives a response for the first security association. The priority within the policy may be applied, for example, by the source UE or the CN.

[0247] Whether two UEs, e.g., a source UE and a target UE (which share / have a first secure communication link via a first UE-UE relay that was established using security procedures without network assistance because the relay was out of coverage when the first secure communication link was established) should re-establish secure communication using security procedures with network assistance when the first UE-UE relay is in coverage again and / or when a second UE-UE relay is detected to be in coverage.

[0248] A threshold / limit on the number of attempts made when trying to agree on a solution before stopping the process, blacklisting other devices, and / or reporting the issue to the core network.

[0249] The end UEs (i.e., source UE and target UE) and the UE-to-UE relay may have different configurations regarding the solution and / or security parameters (e.g., passwords, encryption keys) to use, and therefore exchange negotiation messages as shown in steps 2103, 2104, 2105 in Figure 21 to agree on the solution and / or security parameters or to terminate the connection. The negotiation depends on the security policies provisioned in the UEs and takes into account the coverage status of the UEs (e.g., end UE and UE-to-UE relay) at the time of the negotiation. The following embodiments apply:

[0250] In one embodiment, which may be used independently and combined with other embodiments, the end UE is in coverage but the UE-to-UE relay is out of coverage, and the end UE requests an in-coverage solution, i.e., a security procedure requiring network assistance, which the UE-to-UE relay approves if permitted by security policy (which may be required, but the request is rejected if the UE is not approved to use the solution). In this case, it may be the end UE that communicates (or facilitates communication) and receives assistance from the network in security establishment and approval. For example, TR33.740 describes a solution (e.g., Sol#3) in which, when the UE-to-UE relay is in coverage, the UE-to-UE relay is an entity that relies on network assistance to set up a secure link between the UE-to-UE relay and the target UE. For example, step 3 of Sol#3 in TR33.740 v0.6.0 is a key request containing parameters received from one of the end UEs, in this case the target UE. If the inter-UE relay is out of coverage but the target UE is in coverage, the target UE acts as a UE-to-network relay for the inter-UE relay, and the message in step 3 is forwarded through the target UE (e.g., acts as a UE-to-network relay). Similarly, the end UE that is in coverage also forwards the key response message in step 4 from the CN to the inter-UE relay.

[0251] In another related embodiment that may be used independently, an end UE (eg, a source UE) does the following:

[0252] obtaining instructions from the UE-to-UE relay, including, for example, its identity;

[0253] Sending the content of the initial DCR message to the network, for example in step 3 of Sol#3, in a key request to the CN on behalf of the UE-to-UE relay;

[0254] For example, in step 4 of Sol#3, a key response is received from the CN on behalf of the UE-to-UE relay;

[0255] A DCR message including the contents of the key response received from the CN is sent to the UE-to-UE relay.

[0256] This embodiment allows an end UE (e.g., a source UE) that wishes to use a UE-to-UE relay to directly use network assistance to establish security for the connection between the UE and the UE-to-UE relay, which has the advantage of reducing the number of exchanged messages.

[0257] This embodiment also applies in a similar manner to exchanges between a second-end UE (e.g., target UE) and a UE-to-UE relay, e.g., key requests and key responses from the (first) end UE. The UE exchanges also relate to key material necessary to establish a secure link between the UE-to-UE relay and the second-end UE (e.g., target UE).

[0258] In another embodiment, a first UE (e.g., UE-to-UE relay) is configured with a policy that determines whether to perform a given type of security procedure (e.g., with network assistance) with the assistance / support of a second UE (e.g., end UE) when the first UE is out of coverage.

[0259] In another embodiment, the end UE is out of coverage while the UE-to-UE relay is in coverage, and the end UE requests an out-of-coverage solution, i.e., a security procedure that does not require network assistance, in which case the UE-to-UE relay accepts such a solution if permitted by its security policy. Even if the UE-to-UE relay performs security procedures without network assistance, the UE-to-UE relay still notifies the network of the link establishment attempt between the source UE and the target UE to provide feedback (e.g., final acceptance) on whether the communication is accepted (e.g., when long-term credentials expire). Based on the network feedback, the UE-to-UE relay continues relaying messages or discontinues communication if the network indicates that the connection is not accepted (e.g., if one of the end UEs is not accepted or has accepted the out-of-coverage solution despite being in coverage).

[0260] In another related procedure, a UE-to-UE relay requests / allows the execution of a network-unassisted security procedure between an end UE (e.g., source UE or target UE) and a UE-to-UE relay, e.g., for performance reasons or in out-of-coverage cases, etc. However, this communication link established using the network-unassisted security procedure is subject to a communication policy bound to the network-unassisted security procedure (e.g., characterized by a given (limited) data rate, a specific frequency range, a (limited) temporal validity (up to t seconds), a (limited) local validity).

[0261] In another related procedure, the communication policy includes an access control policy similar in content to the authorization policy in a PIN system, as described in the related procedure / embodiment variant.

[0262] In another related procedure, a communication link established using a network-unassisted security procedure is subject to a communication policy bound to the network-unassisted security procedure.

[0263] In another related procedure, the security procedures for 5G ProSEPC5 communication for 5G ProSe layer-3 UE-to-UE relay without network assistance are described in clause 6.6.3.2 of TS33.503 (draft CR in TDoc S3-233374).

[0264] In another related procedure, the security procedures for 5G ProSEPC5 communication for 5G ProSe layer-3 UE-to-UE relay with network assistance are described in clause 6.6.3.1 of TS33.503 (draft CR in TDoc S3-233374).

[0265] In another related procedure, if an end UE (e.g., source UE or target UE) and a UE-to-UE relay initially established a secure link without network assistance, e.g., if the UE-to-UE relay was initially out of coverage or for performance reasons, the UE (e.g., UE-to-UE relay) may need to perform (based on policy / configuration) network-assisted security procedures or (re-)establish a network-assisted secure link between the end UE (e.g., source UE or target UE) and the UE-to-UE relay. When this new secure link is or needs to be established depends on the context (e.g., timeout, re-relay between in-coverage UEs) or policy.

[0266] In the related procedures, the UE-to-UE relay is provisioned / configured with policies / security parameters to support performing security procedures without network assistance when out of coverage, but once in coverage, the UE-to-UE relay needs to provide a list of (active) communication links between the end UEs for the network to check (e.g., whether the UEs are authorized to communicate with each other, whether the security context (e.g., keying material) needs to be updated). The network instructs the UE-to-UE relay how to handle the communication links established while out of coverage, e.g., interrupt the communication link between the two end UEs (e.g., due to timeout or authorization change), trigger a rekey procedure, trigger new security procedures, or keep the communication link as is.

[0267] In a related procedure that may be combined with other procedures (such as those described in the previous paragraph), the UE-to-UE relay triggers the execution of a network-assisted security procedure by sending a message (e.g., a security procedure request), whereby the message is protected using the key material of the current sidelink / PC5 communication link. Upon receiving the message, the end UE (e.g., source UE) provides credentials to the UE-to-UE relay to execute the network-assisted security procedure, e.g., a direct communication request including a relay service code and a PrukID. Security procedures for 5G ProSE PC5 communication for network-assisted 5G ProSe layer-3 UE-to-UE relay are described in clause 6.6.3.1 of TS33.503 (draft CR in TDoc S3-233374).

[0268] In another embodiment, one or more Network Functions (NFs) in the CN are responsible for monitoring whether security procedures based on security procedures without network assistance can still be provisioned to the UE (e.g., as predicted by policies / security keying material / credentials), or whether those policies / security keying material / credentials have expired / revoked, etc. The NFs are responsible for logging and / or terminating ongoing security procedures. This embodiment has the advantage that the network ensures strict control over whether security connections are established, while the UEs (end-UE / UE-to-UE relay) can use security procedures without network assistance, improving performance (e.g., reducing latency).

[0269] In one embodiment, the UE-to-UE relay sends a message to the end UE confirming the selection of a solution (e.g., step 2105-A in FIG. 21 ), for example, if there is a mismatch between the solution requested by the end UE and the solution preferred by the UE-to-UE relay because the requested solution is supported by the UE-to-UE relay upon policy verification. For example, if the source UE is in-coverage and requests an in-coverage solution and the UE-to-UE relay is out-of-coverage, the UE-to-UE relay sends a message agreeing / proceeding with the in-coverage solution if policy allows and the source UE may be assisted by the network. Similarly, if the UE-to-UE relay is in-coverage and a source UE that is out-of-coverage requests an out-of-coverage solution, the UE-to-UE relay sends a message indicating the mismatch (e.g., step 2105-C in FIG. 21 ) or sends a message informing the source UE of the acceptance of the out-of-coverage solution (e.g., step 2105-A in FIG. 21 ). Similar indications are also sent during the detection procedure.

[0270] In a variation of the embodiment, if the solutions (ie the solutions requested by the end UEs and preferred by the UE-to-UE relay) match, the message sent, for example in step 2105-A in FIG. 21, is not required.

[0271] In another alternative embodiment or variation, by simply continuing the link establishment procedure based on the requested solution, it is implicitly understood whether the UE-to-UE relay supports the requested solution and accepts it despite the discrepancy, in which case step 2105-A is not required.

[0272] A UE-to-UE relay is provisioned with a policy that prohibits it from establishing a communication link with an end UE without network assistance, regardless of whether it is in coverage or out of coverage. For example, if a UE-to-UE relay attempts to provide and / or establish a communication link with an end UE without network assistance (e.g., if the end UE requests an out-of-coverage solution), the network cannot intervene because the UE is out of coverage (e.g., the UE-to-UE relay cannot confirm with the end UE whether it is authorized to establish a link when out of coverage). In such and other similar scenarios, if the network cannot assist or ensure that the communicating parties are legitimately authorized, the UE (e.g., end UE and / or UE-to-UE relay) needs to be able to verify whether it is authorized to use the solution requested / approved by the other party, and embodiments for ensuring this include, but are not limited to, the following:

[0273] In one embodiment, a network-provisioned service code, e.g., a Relay Service Code (RSC), is associated with either an in-coverage / out-of-coverage solution, and when that code is used, a UE receiving a request or grant for a solution is assured that the requesting / granting UE is in fact authorized for the out-of-coverage solution.

[0274] In a further embodiment, if at least one of the UEs (e.g., source, target, or UE-to-UE relay) is in coverage, the UE sends a request to the network including the UE's identifier and a selection of security solutions, and the network then verifies and provides final approval for the link to be established.

[0275] In further embodiments, the UE is provisioned with various credentials (e.g., service codes, discovery key material, passwords, encryption keys, etc.) associated with in-coverage and / or out-of-coverage solutions, and use of these identifiers / keys implicitly implies that the UE intends to use / is authorized to use the requested or authorized security solution.

[0276] In a further embodiment, a UE, e.g., an end UE, constructs a discovery message M protected using key material associated with a given service code (e.g., a relay service code). The UE receives these key material / service codes if it is authorized to use a given security procedure (e.g., in-coverage / out-of-coverage). The UE selects these key material / service codes if an application requires a given type of security procedure, e.g., with or without network assistance. This indicates a UE configuration. For example, a UE (e.g., an end UE) sends a discovery message to another UE (another end UE) via a UE-to-UE relay. Application-specific fields of a given ProSe service are protected using key material bound to the service code, and therefore cannot be accessed by the UE-to-UE relay or other UEs (not belonging to or associated with said application, e.g., the ProSe service). The ProSe service prefers / requires the use of a given security procedure, e.g., with or without network assistance. Based on the configuration, the UE may be entitled to receive credentials (e.g., a relay service code / key material) to select a UE-to-UE relay that can provide support for the given security procedure. These credentials are provided by the core network and are then used by the UE to protect or even add protection to the discovery message M before transmitting it, thereby allowing an application requiring a given type of security procedure to allow the end UE to select an inter-UE relay that can provide the type of security procedure required for said application.

[0277] In a further embodiment, if the end UE indicates a given preference for a given type of solution, e.g. in-coverage or out-of-coverage, i.e. with or without network assistance, and the UE-to-UE relay can provide support for such solutions / security procedures, the UE-to-UE relay does not need to indicate the coverage status as it is not mandatory / useful for the end UE, which is advantageous to save bandwidth.

[0278] In a further embodiment, the end UE indicates its coverage status, e.g. in a detection message, so that even if the UE-to-UE relay is out of coverage, the UE-to-UE relay accepts requests to use an in-coverage solution, i.e. security procedures with network assistance, even if the UE-to-UE relay itself is out of coverage.

[0279] In a specific procedure based on the proposed embodiment, a 5G ProSe end UE (e.g., a source UE and a target UE) and a 5G ProSe UE-to-UE relay negotiate and select a security mechanism based on a security policy, with or without network assistance. The negotiation procedure includes the following steps:

[0280] Step 0: Initial authorization of the UE and provisioning / configuration with security parameters of various security mechanisms and security mechanism negotiation / selection policies.

[0281] Step 1: The source UE and the UE-to-UE relay perform a detection phase and indicate their coverage status.

[0282] Step 2: The source UE constructs a direct communication request message including the selected security mechanism (e.g., with or without network assistance) and security parameters based on local policies that depend on the coverage situation, service configuration, UE-to-UE relay coverage indication, etc.

[0283] Step 3: The UE-to-UE relay receives the source UE's DCR message and determines whether the DCR message contains an explicit security mechanism indication and / or parameters that implicitly indicate a preferred security mechanism (e.g., with or without network assistance). The UE-to-UE relay verifies whether the security mechanism and / or security parameters are compatible with the coverage situation and whether the source UE's preferred security mechanism and security parameters are authorized for use according to the policy provisioned in step 0 and the authorization information received in step 2. Based on the result of the evaluation, the UE-to-UE relay either continues with the execution of the requested security mechanism (e.g., with or without network assistance) or indicates the policy mismatch to the source UE and requests another DCR message containing its (i.e., the UE-to-UE relay's) preferred security mechanism and parameters.

[0284] The negotiation of security mechanisms is based on the policies provisioned to the UE in step 0, which may include but are not limited to:

[0285] Which of the supported security mechanisms or security parameters will be prioritized for establishing a secure link, with or without network assistance from the ProSe service?

[0286] The number of attempts allowed to agree on a security mechanism.

[0287] A default priority list that determines which UE's (e.g., source UE, target UE, and UE-to-UE relay) security mechanism is prioritized when the UE prioritizes different solutions. The priority list depends, for example, on the UE's capability (e.g., relay) or coverage status (e.g., in-coverage vs. out-of-coverage).

[0288] In a specific procedure, the method for selecting a security mechanism with or without network assistance is as follows: A network-assisted security indicator is provisioned in the UE for each Relay Service Code (RSC) to indicate whether to use a network-assisted security procedure. The 5G ProSe end UE and the 5G ProSe UE-to-UE relay select a security procedure with network assistance or without network assistance based on the network-assisted security indicator. If the discovery message contains an RSC associated with a valid network-assisted security indicator, the network-assisted PC5 security procedure is performed between the end UE and the UE-to-UE relay. Otherwise, if the discovery message contains an RSC associated with an invalid network-assisted security indicator, the network-assisted PC5 security procedure is performed between the end UE and the UE-to-UE relay.

[0289] For 5G ProSe UE-to-UE relay communication with Model A detection, if the UE-to-UE relay is within 3GPP® coverage, the UE-to-UE relay needs to include an RSC associated with a valid network-assisted security indicator in the detection announce message, and then the end UE and the UE-to-UE relay perform the PC5 security procedure with network assistance after the detection procedure. If the UE-to-UE relay is out of 3GPP® coverage, the UE-to-UE relay needs to include an RSC associated with an invalid network-assisted security indicator in the detection announce message, and then the end UE and the UE-to-UE relay perform the PC5 security procedure without network assistance after the detection procedure.

[0290] In the case of 5G ProSe UE-to-UE relay communication with Model B detection, if the source end UE includes an RSC associated with a valid network-assisted security indicator in the detection request message and the UE-to-UE relay is within 3GPP coverage, then the end UE and the UE-to-UE relay perform the PC5 security procedure with network assistance after the detection procedure. Otherwise, if the source end UE includes an RSC associated with an invalid network-assisted security indicator in the detection request message, then the end UE and the UE-to-UE relay perform the PC5 security procedure without network assistance after the detection procedure.

[0291] This procedure states that end UEs that do not support network-assisted PC5 security procedures cannot detect each other in detection model A when they are near an in-coverage UE-to-UE relay. This procedure does not describe how a source end UE decides whether to include an RSC with or without a network-assisted security indicator in detection model B. This procedure does not describe how a source UE can decide to perform PC5 security procedures with or without network assistance when it has completed two detection procedures: one with an RSC associated with a valid network-assisted security indicator and one with an RSC associated with an invalid network-assisted security indicator.

[0292] To address these issues, several procedural variants are applied, either combined with each other or used separately.

[0293] In a variation of the procedure, the UE-to-UE relay in Model A transmits a discovery message including an RSC associated with a valid network-assisted security indicator and an RSC associated with an invalid network-assisted security indicator when the UE-to-UE relay is in coverage. These messages with different RSCs may be transmitted alternately or in any order or timing, depending on the configuration and / or implementation.

[0294] In a variant of the procedure, the coverage status of the UE-to-UE relay (e.g., in model A) is explicitly sent next to the RSC, so that the end UE can respond with a preferred solution (with or without network assistance) in a subsequent detection message (e.g., in model A).

[0295] In a variant of the procedure, the RSC is associated with both an invalid network-assisted security indicator and a valid network-assisted security indicator that is not associated with any network-assisted security indicator, so that a UE receiving the RSC knows that it can select a PC5 security procedure with or without network assistance based on its own preference. This RSC is sent, for example, in detection model A, when a UE-to-UE relay is in coverage and supports PC5 security procedures with or without network assistance. This RSC is sent together with the coverage status of the sending device (e.g., UE-to-UE relay) so that the receiving device can select the appropriate security procedure.

[0296] In a variant of the procedure, the end UE in Model A is configured with a policy that determines a preferred RSC (associated with a valid / invalid network-assisted security indication) to react / reply to the RSC received in the discovery message, such that a single PC5 security procedure (with or without network assistance) is executed. For example, if the end UE receives two RSCs, one associated with a valid network-assisted security indication and the other associated with an invalid network-assisted security indication, the end UE has a policy that prioritizes the PC5 security procedure without network assistance and will react / reply to the discovery message only using the RSC associated with the invalid network-assisted security indication.

[0297] In a variant of the procedure, the end UE and / or UE-to-UE relay is configured with a policy that determines a time window during which the end UE and / or UE-to-UE relay considers received RSCs in discovery messages associated with valid, invalid, or neither / both network-assisted security indicators. The end UE and / or UE-to-UE relay reacts / replies to or aborts the received discovery message based on the end UE's preferred solution determined by the policy, thus executing a single PC5 security procedure. Discovery messages received from the same relay after the time window has timed out or after the end UE has already agreed on a security solution are aborted.

[0298] In a variation of the procedure, when a UE-to-UE relay is in coverage (e.g., in Model A) and transmits a discovery message containing an RSC associated with a network-assisted security indicator that is enabled / disabled, or both / none, the end UEs (e.g., source UE and target UE) have different preferences for security solutions. For example, the source UE prefers network-assisted security procedures, while the target UE prefers non-network-assisted security procedures. Therefore, whether the UE-to-UE relay supports different security solutions for the first and second hop-by-hop links is determined by its policy. Furthermore, if a single solution is required for both the first and second hop-by-hop links, the selection of the security solution is determined by the UE-to-UE relay policy, for example, based on the priority between the UEs or the priority of the end UE that responds to the announce message first.

[0299] In a variant of the procedure, the end UE in model B is configured with a policy that determines the preferred RSC (associated with enabled / disabled network-assisted security indication) to use.

[0300] In a variant of the procedure, the end UE in Model B is configured with a policy that determines which PC5 security procedure (with or without network assistance) to perform if the source UE completes two detection procedures: one using an RSC associated with a valid network-assisted security indicator and one using an RSC associated with an invalid network-assisted security indicator.

[0301] In a procedure variant, if the negotiation of both network-assisted and network-unassisted security procedures is successful, i.e., if the RSCs associated with the valid or invalid network-assisted security indicators match in the two parallel detection procedures, the end UE and the UE-to-UE relay must perform the network-assisted PC5 security procedures. This requires one of the end UEs, e.g., the source UE, to send a Direct Communication Request (DCR) message containing the RSC bound to the network-assisted PC5 security procedures. If the UE-to-UE relay matched both RSCs in the previous detection procedures, the UE-to-UE relay receives the DCR message and processes it using the security material bound to both RSCs according to a predefined order (per Section 6.3.5 of TS33.503). For example, the UE-to-UE relay first uses the security material linked to the RSC bound to the network-assisted PC5 security procedures to perform the integrity verification and decryption of the DCR message. If this initial security processing / verification fails, the UE-to-UE relay attempts to process the integrity verification and decryption of the DCR message without network assistance using security material bound to the PC5 security procedures.

[0302] In general, embodiments that require the configuration and use of policies to determine which solutions / protocols to use and which security parameters (e.g., passwords, encryption keys) to use have the advantage that they help prevent a UE that is capable of using both in-coverage and out-of-coverage solutions from deciding to use an out-of-coverage solution when it is in coverage, which not only hurts interoperability but could also create security weaknesses if the out-of-coverage solution is less secure than the in-coverage solution.

[0303] This signaling and agreement phase is also performed in joint discovery, i.e., discovery messages are integrated into the DCR message. For example, Solution #32 in TR33.740 v0.6.0 describes a joint discovery procedure that allows a communication link between a source UE and a target UE to be established when the UE-to-UE relay is in coverage, i.e., when there is network assistance. The initial DCR message sent by the source UE in such a solution / procedure also indicates the preferred type of security to use for subsequent security establishment, whether or not it relies on the core network. The source UE / UE-to-UE relay / target UE then use the preferred security establishment based on the indication, context, and pre-configured policy.

[0304] in general, receiving instructions from a first device regarding a SEP (solution / protocol) and / or security parameters to use, the SEP (solution / protocol) and / or security parameters for establishing a secure link between the first device and a second device; Evaluating whether the indicated SEP (solution / protocol) and / or security parameters can be used; Methods and apparatuses that can be implemented in a device are described for processing a positive or negative evaluation of a first device or a third device based on a policy evaluation (i.e., sending a subsequent message determined by a positive or negative evaluation of a received instruction).

[0305] in general, receiving instructions from a first device regarding a SEP (solution / protocol) and / or security parameters to use, the SEP (solution / protocol) and / or security parameters for establishing a secure link between the first device and a second device; A method and apparatus that can be implemented in a device for evaluating whether a given SEP (solution / protocol) and / or security parameters can be used is described.

[0306] Generally, such methods and apparatus are described in which an indication of the SEP (solution / protocol) and / or security parameters to use is signaled in a discovery message or a DCR message.

[0307] Generally, such methods and apparatus are described where an indication of the SEP (solution / protocol) and / or security parameters to use is signaled in the discovery or DCR message and is implicit in the use of a particular service, e.g., a (relay) service code.

[0308] Generally, methods and apparatus are described that are capable of processing the positive or negative evaluation of a first device or a third device based on a policy evaluation (i.e., sending a subsequent message determined by the positive or negative evaluation of the received instruction).

[0309] Being able to manage out-of-coverage provisioning provides flexibility. Because UEs are mobile, they are likely to be out of coverage from time to time. It can be useful to perform provisioning during this time despite being out of coverage. For example, if a user action is required, it can be useful for the user to complete the action when the UE happens to be out of coverage.

[0310] In related embodiments (which may be combined with other embodiments or used independently) relating to parameter provisioning and solutions for use in and out of coverage, it is advantageous to perform verification of the type and parameters of the solution used before the key establishment and authentication phase. In particular, it is advantageous if the verification of source UE authorization (step 4 of Solution #4 in TR 33.740) is performed before the direct authentication and key establishment procedure (step 3 of Solution #4 in TR 33.740). This is advantageous because it reduces the risk of denial of service. It is also advantageous because it saves resources if the UE is not authorized (step 3). In the case of Solution #4 in TR 33.740, the verification includes verification of the authorization token received in the DCR message of step 2 and / or verification of the out-of-coverage environment.

[0311] In a related embodiment, which may be combined with other embodiments relating to in-coverage and out-of-coverage parameter provisioning or may be used independently, negotiation regarding the type of protocol or parameters to use (in-coverage or out-of-coverage) is negotiated, signaled, or verified during the initial detection phase.

[0312] In general, requiring the configuration and use of policies to determine which solutions / protocols to use and which security parameters (e.g., passwords) to use is advantageous because otherwise a UE that is capable of using in-coverage and out-of-coverage solutions may decide to use the out-of-coverage solution when it is in coverage, which not only hurts interoperability but also could create security weaknesses if the out-of-coverage solution is less secure than the in-coverage solution.

[0313] In a related embodiment that may be combined with other embodiments regarding parameters exchanged before PAKE execution, several parameters need to be exchanged before PAKE execution in steps 3, 6, and 9. These parameters include a relay service code or a "password hint" used to identify a "plain password." In the absence of an explicit password hint, the RSC serves as the password hint, i.e., the password is linked to the RSC. In particular, referring to FIG. 17b, the DCR message in step 1721 includes the PAKE RSC and password hint in steps 1726 and 1729, and the DCR message in step 1722 includes the PAKE RSC and password hint in steps 1723 and 1729. When the UE-UE relay receives the message in step 1721, the UE-UE relay deletes the PAKE password hint in step 1726. Furthermore, the UE-UE relay adds the PAKE password hint to the DCR message in step 1722. When the target UE receives the message in step 1722, the target UE initiates PAKE in step 1723 based on the received password hint.

[0314] In a related embodiment that may be combined with other embodiments in connection with PAKE execution, this embodiment clarifies how PAKE can be executed in the context of SPAKE2 and SPAKE2+ with an exchange of four messages: the first PAKE message and the second PAKE message are exchanged in the Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages, respectively, in accordance with TS 33.536; and the third and fourth messages are exchanged in the Direct Security Mode Command and Direct Security Mode Complete messages, respectively, in accordance with TS 33.536.

[0315] In a related embodiment, the term long-term credential specified in clause 5.3.3.1.2.1 of TS33.536 also refers to a password used in PAKE.

[0316] In a related embodiment that can be combined with other embodiments in connection with secure data exchange, the secure exchange of data relies on a shared key Ks between two UEs that is the result of PAKE. This key Ks is K_shared as defined in SPAKE2 or TT as defined in SPAKE2+. For L2 UE-to-UE relay, Ks is used as a shared secret to derive user / control plane and cipher / integrity PC5 keys using the key derivation function per TS33.220. For L3 UE-to-UE relay, Ks is used to derive a PSK hint and a PSK. The PSK and PSK hint are used in IKE-PSK to secure L3 communications using the key derivation function per TS33.220.

[0317] Generally, methods and apparatuses are described that may be implemented in a device for executing a second PAKE-based SEP between a first device and a third device through a relay device. Methods and apparatuses related to the foregoing methods and apparatuses are further described for executing the first PAKE-based SEP between the first device and the relay device and, if successful, authorizing the execution of a second PAKE-based SEP.

[0318] Personal IoT Network FIG. 16 illustrates a schematic signaling and processing diagram of a Personal IoT Network (PIN) scenario, according to an embodiment. The scenario of FIG. 16 involves a PINE source device (PINE-S), a PEGC and / or PEMC, and a PINE object device (PINE-T). These devices are part of the PIN. For example, the PINE source device is a virtual reality (VR) device (e.g., a headset) that simulates vision and provides a 3D environment in which the user appears immersed while viewing or experiencing it, the object PINE device is a smart TV, and the PEGC / PEMC is a mobile telephone (UE). These three devices require connectivity / services from the core network (CN) via the radio access network (RAN). These three devices also require a means to securely communicate with each other. To this end, the devices are first configured in steps 1601, 1602, and 1603 (as described above in connection with steps 1501-1503). A PINE source device or target device is not 3GPP® RAN capable and therefore cannot be directly configured by the CN, but instead is configured by an Application Function (AF) through the CN, or by the CN if the device is a 3GPP® RAN capable device. The configuration relates to security key material (e.g., PAKE related, PC5 discovery key material in accordance with TS33.503) or other embodiments described herein, or communication parameters (such as QoS, required communication resources, and maximum delay).

[0319] In step 1604, the PINE source device and the PEGC and / or PEMC establish an underlying communication channel, e.g., a Wi-Fi channel. The PINE source device is then triggered to enter a password (step 1605), for example, using a keyboard or by scanning a QR code. This password is generated by the PEGC and / or PEMC and displayed on the screen. The password is derived by a KDF from a master secret on the PEGC and / or PEMC, e.g., the UE's master secret used in primary authentication. The source PINE device and the PEGC / PEMC can then exchange preambles / PAKE messages / SEPs in steps 1606 and 1607, similar to the above embodiment, resulting in a secure and authenticated channel. The PEGC / PEMC then makes 5GC communication resources available to the source PINE device in step 1608. This step includes an authentication procedure, for example, by an AAA server in the Application Function (AF), and notifies the PEGC / PEMC of the result.

[0320] In a further variation, in step 1604, the PINE source device and the PEGC and / or PEMC establish an underlying communication channel, e.g., a Wi-Fi channel. The PEGC / PEMC is then triggered to enter a password, e.g., using a keyboard or by scanning a QR code attached to the PINE source device. This password is provided by the CN or a third party on the PINE. The source PINE device and the PEGC / PEMC can then exchange Preamble / PAKE / SEP messages in steps 1606 and 1607, similar to the above embodiment, resulting in a secure and authenticated channel and enabling initial access to the CN or AF using the CN 1608. Furthermore, prior to this step 1608, upon successful establishment of the secure and authenticated channel in 1607, the PEGC / PEMC securely receives additional security information from the PINE source device, e.g., a digital certificate that allows the PEGC / PEMC to verify the identity of the PINE source device. This digital certificate is verified by the PEGC / PEMC or forwarded for verification by the CN or AF. In this first case, the PEGC / PEMC grants the PINE source device access to the CN or the AF using the CN. In this second case, where the CN or AF performs the verification, the CN or AF sends a confirmation message to the PEGC / PEMC to enable / disable traffic from the PINE source device. This access to the AF using the CN is done through the Network Publish Function (NEF). Note that in step 1608, access to the AF is granted through specific network resources, e.g., specific to the target AF. For example, the purpose of the AF is to create a personal IoT network where all devices can reach it. Therefore, the PINE source device that succeeded in steps 1606, 1607, and 1608 is assigned connection resources that match the needs of the AF (e.g., IP address, communication resources that guarantee certain reliability / latency).The resources allocated to PINE when authentication / authorization is successful in step 1608 are: In step 1602, a policy configured based on user subscriptions, In step 1608, the communication requirements of the PINE configured in the PEGC / PEMC, and / or It depends on the amount of available resources considering other PINE devices connected to the PEGC / PEMC.

[0321] It should be noted that the initial configuration in steps 1601, 1602, and 1603 is performed by the external AF through the CN or by the CN. This initial configuration includes, for example, information that enables the distribution of SEP / PAKE related information in extended PAKE or the validation of subsequent credentials (e.g., digital certificates) received from the PINE source device upon establishment of a secure channel (e.g., by a SEP or PAKE-based SEP). This initial configuration also includes the PINE's communication policy or the PEGC's communication policy.

[0322] In step 1609, a password / credentials is entered / provided / used in the PINE source device, and in step 1610, a preamble message (corresponding to a discovery message) as in Figure 3 or Figure 14 and the above embodiments is exchanged with another PINE target device via the PEGC and / or PEMC. The PEGC / PEMC only allows traffic originating from a PINE that has already been authenticated / authorized in the previous step. In step 1611, the same password is made available to this device. Based on the (preamble) message and the shared password in step 1610, both the source PINE device and the target PINE device execute PAKE in step 1612 as in the above embodiments, resulting in a secure communication channel between the PINE devices in step 1613.

[0323] In Figure 16, the CN includes multiple network functions, including, for example, an AMF, an SMF, or a UPF. The UPF interacts with a PIN-related AF within the CN or outside the CN. Configuration parameters are provided / configured by, for example, a PCF, a UDM, or a UDR.

[0324] In an additional (sub)embodiment, an AF within or outside the 5G system is responsible for managing the PIN. This AF and the PEGC / PEMC establish a secure channel via Application Authorization and Key Management (AKMA) (see TS33.535). Once the PEGC / PEMC is authenticated based on the AKMA-derived key, the AF provisions the PEGC / PEMC with PIN configuration parameters (e.g., in step 1602). Before the AKMA Anchor Network Function (AaNF) is allowed to provide the AF with the AKMA-derived AF key, the AKMA NF checks, either directly with the UDM / UDR or indirectly through the AUSF, whether the user of the PEGC / PEMC is authorized to configure the PIN and, for example, subscription data, subscription authentication, PDU session information, and QoS requirements.

[0325] In a further variant, the PINE device, e.g., the PINE object in FIG. 16, supports a cellular interface, and thus, for example, in step 1601, the PINE device can be configured via a cellular interface, such as a Uu interface or a PC5 interface. The initial configuration includes configuration parameters for setting up the PC5 interface, for example, detection security materials as described in TS33.503. This initial configuration also includes PIN configuration information. This information is provided by the AF, for example, via an AKMA-derived key that enables the execution of authentication / authorization procedures between the PINE and the AF once the PINE (e.g., the PINE object) establishes a secure connection with the 5GCN (e.g., during primary authentication). This initial secure PIN configuration is performed via the Uu or PC5 interface. This initial PIN configuration is performed before the PINE device attempts to participate in the PIN. If the PIN configuration is successful, the PEGC / PEMC is also instructed / configured to route communications between PINEs, e.g., steps 1610, 1612, and 1613 should be routed through the PEGC / PEMC, where the communication link between the PINE source and the PEGC / PEMC is based on a first communication protocol (e.g., WiFi) and the communication link between the PINE target and the PEGC / PEMC is based on a second cellular communication protocol. This configuration can be pulled by the PEGC / PEMC or pushed by the PIN AF. Thus, the PEGC / PEMC is configured by the 5GC with a configuration policy that determines the routing of specific PC5 traffic (e.g., MAC or PDU sessions, or IP layer) to another network interface, e.g., a WiFi, BLE, or IEEE 802.15.4 network interface.

[0326] In a further variation, a PINE device, e.g., the PINE object in Figure 16, supports a cellular interface. Such a PINE device uses unregulated spectrum and therefore does not necessarily have to rely on resource allocation from the RAN.

[0327] In a further variant, the PINE device, e.g., the PINE object in FIG. 16, establishes a secure channel with the PEGC / PEMC at the application layer by using a SEP, e.g., a PAKE-based SEP, where the PAKE-based SEP message is forwarded, e.g., in a metadata field of a PC5 discovery message or in another PC5 message.

[0328] In a further variant, step 1608 involves a (mutual) authentication procedure between PINE and AF / 5GC.

[0329] In a related variant, the PIN AF acts as or includes the functionality of an AAA server.

[0330] In a related variant, the following occurs:

[0331] In phase 1, a UE that is a candidate to become the PEGC / PEMC of the PIN performs an initial (primary) authentication with the core network, for example, using a root key (e.g., K_AUSF in 5G) shared by the UE and an authentication entity in the CN (e.g., AUSF in 5G).

[0332] In phase 2, if this initial (primary) authentication is successful, the UE requests communication with a specific PIN AF or the CN (e.g., AUSF) checks the subscriber's settings, e.g., settings related to PIN management. In this case, the CN authorizes the UE and the UE and the PIN AF set up secure communication using K_AF, derived from K_AKMA, e.g., according to TS33.535.

[0333] In step 3, the UE and PIN AF communicate with each other via K_AF or Ua * The protocol can be used to perform an authentication / authorization procedure based on keys derived therefrom, which may additionally or alternatively be another higher-level application protocol that uses some credential specific to the PIN.

[0334] In step 4, for example, if authentication / authorization was successful in step 3, the AF informs the CN (e.g., AUSF, AUSF via AaNF, or other NF) of the UE status and provides some configuration parameters related to PIN communication requirements, membership, etc. that the UE needs to use in its PEGC / PEMC role. The CN (e.g., AUSF) stores this information in a database, e.g., UDM (UDR). The CN (e.g., AUSF) checks this received configuration against the user subscription and verifies whether it satisfies the subscription. Charging information is also updated with the UE's new status (active PEGC / PEMC).

[0335] In step 5, the CN (e.g., AUSF to AMF) informs the UE (e.g., using a NAS message) about its confirmed role as a PEGC or PEMC. The CN also informs the UE of any specific PIN configuration information, such as that shared by the PIN AF and / or verified for the user subscription. The CN also configures the UE with policies and configuration parameters to route PIN-related data (e.g., data generated in the PINE) to the AF using predefined network resources. The CN configures the UE with policies that determine how / whether to route data or which data to route between cellular and non-cellular PINE devices within the PIN. Additionally or alternatively, some of the above information is also sent by the AF. The UE configuration / policy that determines whether to route PINE device data implies that this configuration can be used for authorization of PINE device communications.

[0336] In step 6, the AF also configures the PEGC / PEMC with other configurations, such as configurations related to PIN parameters.

[0337] Some of steps 1 to 6 are included in, for example, step 1602 in Figure 16. These are similar to security procedures that allow the UE to become the PEGC / PEMC of the PIN.

[0338] In step 7, if the UE is requested to add a PINE to the PIN, or if the PINE requests access to the UE PIN, the UE: a) setting up a secure channel between the UE and the PINE, for example using a protocol based on the SEP, for example a PAKE-based SEP or a PINE wireless communication technology; b) Granting access to the AF based on the configuration or other parameters received in step 5 or 6. This access is limited to the time until confirmation from the CN or AF that the authentication procedure between the PIN and the AF has been successful. This access is based on specific communication resources that can be monitored by the CN to ensure compliance with the PIN subscription.

[0339] Stage 7 corresponds to steps 1604 to 1607 in FIG.

[0340] In step 8, an authentication and authorization procedure is performed between PINE and AF. This procedure is performed at the application layer, e.g., outside the 3GPP specifications. It may also be based on secondary authentication. Optionally, additionally, or alternatively, the UE derives a PINE key (K_PINE) from e.g., K_AF by using a KDF that includes such key and an identifier provided / scanned by PINE. The UE securely shares this identifier with the AF that can derive the same K_PINE, since they share K_AF. The UE also shares K_PINE with PINE. The authentication and authorization procedure is also based on K_PINE.

[0341] In stage 9, if the authentication / authorization between the PINE and the AF in step (8) is successful, the AF notifies the CN (e.g., AUSF) of the new PINE, the successful authentication status, and the PINE requirements. The AUSF adds information about the PINE to the UDM (UDR). The charging information is also updated with the new status of the PIN (new PINE). The CN then notifies the UE of the successful authentication of the PINE and any configuration information provided by the AF. The CN also provides the PEGC / PEMC, via an NAS message, with a communication policy for routing data generated in the PINE using a specific communication resource or a specific identifier. Additionally or alternatively, the AF provides the UE with the previous information (e.g., using a secure channel protected with K_AF (or a key derived therefrom)). The UE then notifies the CN, for example, via an NAS message to the AMF and then to the AUSF.

[0342] In step 10, the UE obtains or has obtained (scanning a QR code, entering an ID, etc.) an identifier from the PINE for identification purposes. This identifier has also been shared in a secure manner with the AF, e.g., in step 8. This identifier, or an identifier derived from it, e.g., by a KDF, is shared with the CN for identification purposes of the PINE.

[0343] In step 11, a PINE key (K_PINE) associated with the UE is provided, for example, by the AF. From K_AUSF, which contains the identifier as input in the KDF, It is derived from the current K_AF, which includes the identifier as input in the KDF.

[0344] Upon authentication / authorization, the AF sends the PINE key to PINE in a secure manner (application layer), e.g., based on the secure link established in step (8). Additionally or alternatively, the UE shares it. Additionally or alternatively, the CN and UE also generate K_PINE, if derived from K_AUSF or K_AF.

[0345] This PINE key is also considered an "access token" that allows a PINE to communicate with an AF or another PINE in the PIN through the PEGC / PEMC. This "access token" ensures that only authorized PINEs can use the PEGC / PEMC during authentication and / or authorization. This PINE key, acting as an authorization token, is managed by the CN or AF and shared by both the PINE and the PEGC, allowing the PEGC / PINE to verify the authentication / authorization of exchanged messages. This is advantageous because other authorization mechanisms, such as filtering by MAC address, do not provide strong security guarantees since MAC addresses can be easily forged.

[0346] In stage 12, K_PINE allows the following actions: CN / UE sends a specific command to PINE. PINE establishes a secure channel with the UE / CN, allowing PINE to exchange messages securely with the PEGC / PEMC. PINE sends a specific message to CN in a secure manner. The PEGC / PEMC sends messages to the PINE that are generated locally at the PEGC / PEMC or forwarded from other PINEs or AFs.

[0347] for example, Every time PINE sends a message to AF via PEGC, PINE attaches a token based on K_PINE.

[0348] For example, if K_PINE is a symmetric key and the MIC is computed over the message or over a parameter that allows verification of the message freshness (e.g., a UTC-based counter), then this token is a MIC based on K_PINE.

[0349] For example, this token is an authorization token that is verified by the PEGC / PEMC every time the PINE sends a message to the PEGC / PEMC, an AF, and / or another PINE.

[0350] For example, this K_PINE is used to (mutually) authenticate the IKEv2 IKE-based tunnel setup between PINE and PEGC / PEMC so that all traffic exchanged is secured.

[0351] A PIN management entity (e.g., NF or AF in 5GS) is responsible for managing, generating, distributing, etc. said tokens, e.g., said authorization tokens. The PIN management entity is responsible for providing key material (e.g., symmetric or private keys) to the PINE and / or PEGC / PEMC so that tokens can be validated.

[0352] Some of steps 8 to 12 are included in step 1608 in Figure 16. These are similar to the authentication and authorization process of PINE.

[0353] FIG. 20 shows a schematic view of the above steps.

[0354] In phase 1, primary authentication is performed between the UE (PEGC / PEMC) and the CN.

[0355] In stage 2, the UE (or an application on it) requests PIN access to the CN or through the CN to the AF. This is done through the AKMA (TS33.535) and the AnAF. In this case, K_AKMA is used to derive K_AF for the specific UE and PIN. Alternatively, another PIN-specific anchor function is used, such as a PIN Key and Device Management (PKaDMA), e.g., an Anchor PIN Function (AnPF) responsible for managing K_PKMA. For example, K_PKMA plays a similar role as K_AKMA, but is specific to the PIN of which the UE is a member / responsible. K_PKMA is derived in a similar manner to K_AKMA, i.e., from K_AUSF, but the KDF uses other parameters, such as a bit string identifying the PKaDMA, as input parameters. From K_PKMA, K_PIN can be derived in the same way as was done for K_AF, e.g., using an identifier identifying the PIN as input. This allows for support of multiple PINs. As explained above, from K_PIN or K_PKMA it is possible to derive K_PINE, a key that is specific to a given PIN. Having a different NF AnPF is advantageous because the PIN scope is different from that of the AnAF, allowing all PIN functionality to be located in a separate NF.

[0356] In phase 3, the UE and AF perform authentication and authorization steps, which are based on the keys distributed in phase 2.

[0357] In step 4a, the AF notifies the CN of the results of step 3 and provides the CN with a configuration, which includes information about the PIN identifier, the purpose of the PIN, the PIN elements, the functionality of the PIN elements, communication requirements such as QoS, allowed interactions between PINs, etc. In step 4b, the CN stores the configuration, for example in the UDR or the AnPF.

[0358] In step 5a, the CN informs the UE of the results of step 4 and provides the UE with a configuration. This configuration is based on and includes the relevant configuration exchange in step 4. This configuration includes rules that enable authentication and authorization procedures (as in step 8) for the PINE (e.g., the one requested in step 7c). This configuration includes the "authorization token" for the specific PINE, as described above. In step 5b, the UE stores the configuration. This configuration received from the CN is related to the communication parameters assigned to the PIN.

[0359] In step 6, the AF informs the UE of the results of step 4 and provides the UE with configuration such as certificates, key material such as passwords, etc. This configuration received from the AF relates to application-related aspects assigned by the AF to the PIN.

[0360] In step 7a, the PINE and the PEGC / PEMC set up a secure communication channel. In step 7b, the PINE sends a PIN access request to the PEGC / PEMC. In step 7c, the PEGC / PEMC grants (temporary) access (to the PINE) to perform step 8, e.g., based on the information received in step 5a.

[0361] Stage 7a, like the previous embodiment, is based on SEP, e.g., PAKE, or another protocol such as Device Provisioning Protocol (DPP) or Wi-Fi Easy Connect™. The advantage of using PAKE or DPP is that the communication links are individually protected.

[0362] In step 8, PINE and AF perform authentication and authorization steps.

[0363] In step 9a, the AF notifies the CN of the results of step 8 and provides the CN with the configuration related to the PINE. In step 9b, the CN stores the configuration. In step 9c, the CN notifies the PEGC / PEMC of the results of step 8 and provides the PEGC / PEMC with the configuration of the PINE. In step 9d, the PEGC / PEMC stores the configuration. This configuration received from the CN is related to the communication parameters assigned to the PINE.

[0364] In step 10, the PINE and the PEGC / PEMC receive an "authorization token" from the CN. The PINE receives it through the AF. The purpose of this "authorization token" is to ensure that only authenticated / authorized PINEs can communicate with / through the PEGC / PEMC.

[0365] In step 11, data is exchanged between PINE / PEGC / PEMC authenticated and / or authorized using said authentication token.

[0366] With reference to Figure 20, steps 1-6 correspond to the PEGC / PEMC certification and / or approval procedure. Steps 7-11 correspond to the PINE certification and / or approval procedure. These procedures may be used together or may be performed separately.

[0367] The message "PIN Access Request" in step 7b is a message that PINE can send to the UE acting as PEGC / PEMC via various lower layers (such as Wi-Fi and PC5). Upon receiving this message, the UE is informed of the request to join the PIN. This message is the initial message of step 8 (PINE Authentication and Authorization). It is convenient for this message to include an identifier of the object PIN, e.g. an identifier associated with the PIN.

[0368] When PINE receives the "PIN Announcement" message, it sends a "PIN Access Request." This is a message sent / broadcast by the UE to announce its PIN capabilities. This message also contains additional information that allows PINE to determine if it is the correct PIN to join. This message contains the PINE's identifier, which allows PINE to recognize that the UE is attempting to connect. PINE sends a "PIN Access Request" when certain out-of-band interactions occur, such as the UE scanning a displayed QR code.

[0369] In a variation of this step, since the PIN element establishes a connection to the PEMC and PEGC using a local interface (such as PC5, WLAN, or Bluetooth) and is eventually approved to participate in the PIN by the PEMC, the PEMC / PEGC requires a policy or configuration that determines / specifies one or more of the following: The types of devices that can participate in the PIN, the type of interaction between authorized devices (e.g., 3GPP devices and non-3GPP devices) (authentication by AF, PINE-AF communication, PINE-PINE communication, etc.); the conditions under which the interaction / communication is authorized (time, place, context, etc.); The permitted lower layer types that PINE can use in PINs, Devices that are allowed to participate in PIN, For example, the type of authentication procedure based on 1) the scope (local, end-to-end, etc.), 2) the type to support PINE authorization (e.g., Matter-based, DPP-based, etc.), Credentials to verify approved PINE.

[0370] This policy, among other things, AF or By NF in 5GS, or Configured locally (eg, via the UI) at the PEGC / PEMC.

[0371] In a variation of this step, the PEGC / PEMC adjusts the access decisions of the PINE based on said configuration or policy.

[0372] In a variation of this step, this policy applies to step 3 of solution 8 in TR33.882 v 0.4.0.

[0373] Step 8 is the authentication and authorization step. This may be performed based on an application layer protocol, secondary authentication, or relay peer, pass-through authenticator, back-end authentication server architecture, using an EAP protocol similar to clause 6.1.1.2 in TS33.501. The peer is the PINE, the authenticator is the UE (instead of 5GS), and the authentication server is the AF. The peer sends EAP messages via a (wireless) communication technology between the PINE and the UE, for example, EAP over LAN, i.e., EAPOL. The UE, acting as the authenticator, then exchanges EAP frames (for example, directly or encapsulated in a protocol such as diameter) with the authentication server, i.e., the AF.

[0374] Figure 19 shows a schematic diagram of elements in a personal IoT network (PIN) from another perspective, similar to Figure 16. The elements in Figure 19 are as follows: Device 1901 is a non-cellular device that is not part of the PIN. Device 1902 is a non-cellular device that is part of the PIN. Device 1903 is a PIN-managed cellular device, or PEMC. Device 1904 is a cellular device that can act as a PIN gateway, ie, a PEGC. Device 1905 is a cellular PINE device that is part of PINE. Device 1906 is a communication link between devices 1903 and 1904 . Device 1907 is a cellular access device, such as a gNB. The device 1908 is an AMF in the CN. Device 1909 is an AUSF in the CN. The device 1910 is an NF in the CN, such as a UDM, UDR, AKMA, UPF, PCF, NEF, or AF in the CN. Element 1911 is CN. Element 1912 is the AF responsible for managing the PIN. Network 1913 is a PIN that includes 1902, 1905, and 1920. Link 1914 is a non-cellular communication link between 1920 and 1902 . Link 1915 is a cellular communication link (eg, PC5) between 1905 and 1920. Link 1916 is a cellular communication link (eg, Uu) between 1920 and 1907 . Link 1917 is a communications link that interfaces 1907 and 1911, or a network function therein. Link 1918 is the communication link between 1911 and 1912 . Network 1919 is a non-cellular network. The device 1920 is a device that includes the functions of 1905 and 1906 . Device 1921 is a non-cellular device that manages or accesses a non-cellular network.

[0375] In FIG. 19 , device 1920 can be seen to be part of 1919; for example, device 1920 has joined the network and has credentials such as security keys. Because device 1920 is part of network 1919, device 1920 can also communicate with device 1902 (part of network 1919) via link 1914. Device 1902 also joins network 1913, and device 1920 manages the authentication / authorization procedures on behalf of element 1911 or 1912 to access network 1913 and links 1916 or 1915. When device 1902 needs to communicate with device 1905, or vice versa, the communication is routed through device 1920, and device 1920 receives policies from element 1911 or 1912 that determine which communication flows are allowed to be rerouted. In FIG. 19 , device 1921 manages network 1919, and device 1920 is part of network 1919. This implies that device 1920 also joins network 1919 first. Alternatively, device 1920 includes the functionality of device 1921. In this case, device 1921 handles which devices join network 1919 first, and then which of those devices join network 1913. Once a new device is accepted in network 1913 by device 1920, device 1920 notifies other devices about the newly joined device.

[0376] In general, there are methods and apparatuses that can be implemented in a device and that enable one or more of the following actions:

[0377] Receiving a configuration (e.g., PEGC / PEMC or cellular-based PINE) of the first device from an AF running on a third communication device.

[0378] Executing a SEP (e.g., DPP, PAKE-based) between a first device and a second device (e.g., a non-cellular PINE) to enable the initial establishment of a secure and authenticated channel with the second device over a first communications link, such as Wi-Fi.

[0379] and routing further authentication messages through the first device between the second device and the NF / AF on the third communication device if the communication between the first device and the third device passes through a second cellular backhaul communication link.

[0380] receiving an authorization confirmation and / or authorization configuration at the first device from the third device; accessing a first device network; access to a second cellular backhaul communications link (e.g., a Uu interface); communication with a fourth device (e.g., cellular PINE) connected to the first device through a cellular communication link (e.g., sidelink / PC5); Determine the access rights to at least one of the following:

[0381] In at least some of the above embodiments, the PAKE is SPAKE2+ or a different PAKE that is balanced or extended.

[0382] In at least some of the above embodiments, the password is a shared symmetric key.

[0383] In at least some of the above embodiments, the password (PWD) is a concatenation of a (short) shared symmetric key and metadata that determines the validity of the password and communication link, e.g., the validity period and the access rights involved. For example: PWD=K|Metadata Here, the metadata includes access policies or access roles. Note that this approach can be used in other PAKE schemes. In some cases, it may be necessary to apply a function such as PBKDF or another function to the input K| metadata.

[0384] In some embodiments, the "metadata" value is the root of a Merkle tree computed from a set of leaves, each of which contains some information about the device. This allows devices to expose only a portion of the data in the leaves. Devices exchange data only when a secure connection is established.

[0385] This proposed technique has advantages over alternative techniques that can be used to grant authentication and authorization, for example: When traditional access tokens are used, the initiator and responder first establish a secure channel, for example, using the Diffie-Hellman (DH) algorithm (a key exchange protocol that allows two parties communicating over a public channel to establish mutual secrecy without transmitting data over the Internet). The initiator then sends an access token to the responder. The access token contains information indicating the initiator's access rights and is signed by an issuing party trusted by the responder. This scheme requires a digital signature and is still subject to man-in-the-middle (MitM) attacks. In contrast, the proposed scheme is resistant to MitM attacks and does not require a digital signature.

[0386] If the initiator and responder rely on the PWD=K| metadata to perform a symmetric-key mutual authentication and key agreement protocol, which passwords are assigned to which devices, and therefore their identities, are revealed. Furthermore, if a third device is assigned the same password as the initiator and responder, the third device can access the communications link between the initiator and responder.

[0387] In some of the above embodiments, the preamble or one of the messages in the PAKE includes a password hint that indicates to the receiving party which password or password-based information to use (e.g., referring to extended PAKE, e.g., in SPAKE2+, this password-based information refers to the pair of verification values ​​L and w0). In this case, if the password is configured by a central authority such as 5GCN, and the user does not know which password to use or which QR (containing the password) to scan, the device uses the password hint to indicate this so that the other party, after executing the PAKE, knows which password to obtain and use to authenticate the other party. Successful authentication implies verification of the password and metadata. For example, the password hint is obtained as a function, e.g., a KDF or hash, of the password and additional parameters such as a salt, nonce, and counter, as follows: PWD_Hint=KDF(PWD|additional parameters) PWD_Hint=Hash(PWD|Additional parameters) PWD_Hint=HMAC(PWD|additional parameters) Alternatively, the password hint is a randomly generated bit string that is associated with the password.

[0388] In at least some of the above embodiments, the password comprises at least two passwords: a first password provided to both communicating parties by a central management entity to authorize the establishment of the communication channel, and a second password entered by the user to enable the user to authorize the setting up of the secure communication channel. PWD=PWD1|PWD2

[0389] In some of the above embodiments, two PAKEs are run in parallel, with a first password, PWD1, used in the balanced PAKE, where the password is determined, for example, by the users involved, and a second password, PAWD2, used in the extended PAKE, where the password is determined by network / system administration. Running the PAKEs in parallel means that PAKE messages are sent simultaneously, reducing the number of round trips. In a similar PAKE, steps or operations can be combined. This has the advantage that a user can enter their own password to authorize communication, while the network / system can distribute passwords to the devices involved in an initial configuration phase, for example, to authorize a communication link for a first device (e.g., initiator) to communicate with a second device (responder).

[0390] In at least some of the above embodiments, a central administration party, e.g., 5GS, supports authorizing a UE as a UE-to-UE relay in a UE-to-UE relay scenario.

[0391] In at least some of the above embodiments, a central control party, e.g., 5GS, supports authorizing UEs as source UEs or target UEs in UE-to-UE relay scenarios.

[0392] The fact that PAKE is extensible is a useful feature because if a responder or verifier is compromised, the best an attacker can do to impersonate the initiator or client is to launch an offline attack. This allows the central control party to deploy a password PWD, as described above, i.e., K|metadata that can be used by clients to indicate their authenticity and authorization, e.g., to indicate that they are authorized to act as a source UE for a target UE. The central control party creates two types of passwords / keys, e.g., K_S and K_T. K_S is provided to UEs that can only act as sources, and K_T is provided to UEs that can only act as targets. One of these passwords / keys is provided to the other party; e.g., a target device that can only act as a target is provided with a function of a bit string that is difficult to invert (in a security sense) derived from K_S (and the metadata). Note that when balanced PAKE is used, the central control party can also assign passwords / keys to pairs of devices to authorize them to communicate with each other.

[0393] In some of the above embodiments, one of the devices, e.g., the responding device, also obtains or requests a password (or a password-based value in the Extended PAKE) from such a central authority upon receiving, e.g., a preamble message including a password hint. This requires the device to share certain parameters with the central authority, e.g., the password hint or the exchange parameters used in the PBKDF. The password-based value in the Extended PAKE has the advantage that the responder device performs the subsequent key exchange, e.g., PAKE, with the initiator device on behalf of the central authority without having access to the password. Because the password-based value depends on the exchange parameters used in the PBKDF, the validity of this value is limited. Only if the procedure is successful does the responder allow the initiator to perform a specific action, e.g., access to network resources, the 5G core network, or application functions accessible through the 5G system.

[0394] In some of the above embodiments, the exchange parameter used in the key derivation function is (the least significant bits of) a UTC-based counter.

[0395] In summary, a method and device for setting up a secure communication channel with improved key exchange for SEP has been described.

[0396] While the present invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are to be considered exemplary or illustrative and not restrictive. It is to be understood that embodiments may be combined and that any feature of an embodiment may be used in combination with another embodiment. The present invention is not limited to the disclosed embodiments. The proposed enhancements of SEP (such as SPAKE2+, SPAKE, or general PAKE) may be implemented in any type of wired or wireless network and may be applied, for example, to devices or applications that communicate using cellular wireless communication standards, specifically the 3rd Generation Partnership Project (3GPP®) 5G and New Radio (NR) specifications. The communication devices or applications can be of different kinds of devices, such as mobile phones, smart watches, smart tags for location tracking and logistics, commissioning devices, applications or tools, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2x devices, IoT hubs, IoT devices including low power medical sensors for health monitoring, medical (emergency) diagnostic and treatment devices for hospitals or emergency personnel, virtual reality (VR) headsets, etc., and are used, for example, in Personal IoT Networks (PINs) and / or ProSe focused between UEs.

[0397] Furthermore, the proposed enhancements to SPAKE2+, general PAKE, or other SEPs can be used in applications such as Wi-Fi, cloud access, browser sync, e-passports, the Thread network protocol for IoT devices, PAKE standards developed by Standards Development Organizations (SDOs) such as IEEE, ISO / IEC, or IETF, the IEEE 802.11S protocol, and WiFi Protected Access (e.g., WPA3 in connections with Simultaneous Authentication of Equals (SAE)), Transport Layer Security (e.g., TLS 1.3), or Internet Key Exchange (e.g., IKEv2) protocols.

[0398] Although ProSe relay and sidelink communication have been described, the present invention also applies to other types of relay devices, e.g., proximity services involving direct communication between two UEs, proximity services involving relay from a UE to a network, ranging services, e.g., (smart) repeater devices, integrated access and backhaul (IAB) nodes, or Wi-Fi mesh APs. Furthermore, the techniques described herein also apply to other procedures, e.g., to address key issues identified in the ranging procedure in TR33.893 v0.2.0.

[0399] Furthermore, the present invention applies to medical applications or connected healthcare where multiple wireless (e.g. 4G / 5G) connected sensor or actuator nodes participate, medical applications or connected healthcare where wireless (e.g. 4G / 5G) connected equipment consumes or generates continuous data streams at certain average data rates from time to time, such as video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, audio, voice or video streaming devices used by medical staff, general IoT applications (e.g. smart cities, logistics, agriculture, etc.) involving wireless, mobile or fixed sensor or actuator nodes, emergency services and critical communication applications, V2X systems, systems for improving the coverage of 5G cellular networks using high frequency (e.g. mmWave) RF, and any other application area of ​​5G communications where relays are used.

[0400] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the use of an "a" or "an" element does not exclude a plurality. The above description details specific embodiments of the present invention. However, no matter how detailed the foregoing appears in text, it will be understood that the invention may be embodied in many ways and is therefore not limited to the disclosed embodiments. It should be noted that when certain terms are used in describing particular features or aspects of the present invention, this should not be construed as implying that the terms have been redefined herein and are limited to include the specific characteristics of the feature or aspect of the invention with which they are associated.

[0401] Furthermore, when a convention similar to "at least one of A, B, and C, etc." is used, generally such a configuration is intended in the sense that one of ordinary skill in the art would understand that convention; for example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together. When a convention similar to "at least one of A, B, or C, etc." is used, generally such a configuration is intended in the sense that one of ordinary skill in the art would understand that convention; for example, "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together. Furthermore, it will be understood by those skilled in the art that virtually any separating word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" is understood to encompass the possibilities of "A" or "B" or "A and B."

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

[0403] The described operations as shown in Figures 1-3 and 5-13 may be implemented as program code means of a computer program and / or as dedicated hardware in the commissioning device or luminaire 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, provided together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications system.

Claims

1. executing a security establishment protocol (SEP) with a second communication device to enable initial establishment of a secure and authenticated channel with said second communication device over the first communication link; routing an authentication message of the second communication device over a second cellular backhaul communication link to a third communication device; An apparatus for secure communications that receives a second configuration of the second communications device from the third communications device.

2. The device of claim 1 , further comprising: scanning a QR code prior to executing the security establishment protocol.

3. 3. The apparatus of claim 1 or 2, further comprising: after scanning the QR code, receiving the first configuration from a third communication device.

4. 4. The apparatus of claim 3, further comprising: an AKMA authentication to the third communications device prior to the reception of the first configuration.

5. The device of claim 1 , wherein the security establishment protocol is one of SPAKE, SPAKE+, or DPP.

6. The apparatus of claim 5 , wherein a Wi-Fi or Thread communication channel is established prior to the security establishment protocol.

7. 7. The apparatus of claim 1, wherein the routing of authentication messages includes routing an authentication procedure between the second communication device and the third communication device, blocking any other communications.

8. The apparatus of claim 7 , wherein the authentication messages are exchanged with an AAA server.

9. The second configuration is accessing a local network managed by said device; accessing a personal IoT network management by said device comprising at least one local network; accessing the second cellular backhaul communication link; communicating with a fourth device connected to the apparatus through a cellular communication link within the personal IoT network; 9. The apparatus of claim 1, further comprising a policy that determines the access rights of the second communication device to do at least one of the following:

10. The first configuration is a type of second communication device that is allowed to join the local network; and the type of the second communication device that is authorized to join the personal IoT network; and the type of interaction between the second communication devices that is authorized; and The conditions under which the interaction or communication is authorized; - the types of allowed lower layers that a second communication device can use in a local network or personal IoT network managed by said device; the identity of a second communication device that is authorized to join the local or personal IoT network; and A type of authorized authentication procedure based on scope, the scope being either local or end-to-end; a type of security protocol to support the authorization of the second communication device; and Credentials for verifying an authorized second communication device; 10. The apparatus according to claim 2, comprising at least one of:

11. A user device implementing the apparatus of any one of claims 1 to 10.

12. executing a security establishment protocol between a first communication device and a second communication device, the security establishment protocol enabling the initial establishment of a secure and authenticated channel with the second communication device over a first communication link; routing a further authentication message of the second communication device through the first communication device to a third communication device over a second cellular backhaul communication link; and receiving, at the first communication device, a second configuration of the second communication device from the third communication device.

13. A computer program product which, when executed on a computer, causes the computer to carry out the method of claim 12.

Images