METHODS AND SYSTEMS FOR IMPROVED SECURITY DEVICE

Abstract

The invention relates to methods and apparatus for establishing a secure communication channel with an improved key exchange for a security device protocol or procedure.

Description

FIELD OF THE INVENTION

[0001] The invention relates to security setup procedures between devices and / or applications in a wired or wireless network, 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 based on a security procedure. BACKGROUND OF THE INVENTION

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

[0004] Key deviation functions (KDFs) are deterministic algorithms used to derive one or more secret keys (cryptographic key generation material) from a secret value, such as a master key, password, or passphrase, using a pseudorandom function (PRF), typically employing a cryptographic hash function or a block cipher. A password-based KDF (PBKDF) can be defined by choosing the PRF and a fixed iteration number C. An input to execute a PBKDF can include a password P, a salt S, and a specification of the desired length kLen of a desired master key mk in bits, denoted kLen. Symbolically, this can be expressed as follows: mk=PBKDF(PRF,C)(P,S,kLen).

[0005] The salt can be a binary value used as input to the PBKDF to enable the generation of a large set of keys for a given password. The iteration number (C) is a fixed value that determines how many times the PRF iterates to generate a block of the master key. The number of iterations can be as large as possible, as long as the time required to generate the key using the input password is acceptable to the user.

[0006] Modern PBKDFs, such as PBKDF2 (specified in the IETF specification RFC 2898), can be based on a recognized cryptographic hash such as SHA-2, use more salt (at least 64 bits and randomly chosen), and use a high iteration count.

[0007] Fig. Figure 1 shows an example of a PBKDF2 algorithm for deriving master keys from passwords, 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 of the hash function in bits is denoted as hLen. HMAC is a specific type of MAC that includes a cryptographic hash function and a secret cryptographic key. Like any MAC, it can be used to simultaneously verify the data integrity and authenticity of a message.

[0008] The input of the algorithm of Fig. 1 includes a password P, a salt S, an iteration count C, and a desired master key length kLen in bits (at most (232 - 1) x hLen). Parameters of the algorithm are the PRF (which is an HMAC with an approved hash function) and a digest size hlen of the hash function. The output of the algorithm is the master key mk.

[0009] First, it checks whether the desired master key length is greater than the maximum length. If this is the case, an error indicator (Err-i) is returned and the procedure terminates.

[0010] If the desired length is within the acceptable range, a loop parameter len is used for an outer loop (i = 1 to len) for code sections T to be combined. i based on the ratio kLen / hLen, and each code section is calculated in an inner loop (j = | to C).

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

[0012] SPAKE2+ defines a PAKE that allows two parties (a party can be a device, an application, etc.) A and B to agree on a shared symmetric key in an authenticated manner, where authentication is based on a (weak) password. After an initial preamble exchange (pre) to communicate identities, protocol version, PBKDF parameters, etc., the procedure executes the PAKE with 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 (including the respective shared secrets pA and pB) are used to establish a protocol (su prot) and agree on a shared secret. Then, the second party B computes an acknowledgment cB (cpt cB), and the first party computes an acknowledgment cA (cpt cA).The last two messages (including the respective confirmations cB and cA) are used to derive secrets (the scr) and for key confirmation. Two of the messages can be combined into one (pB + cB) because they are transmitted sequentially in the same direction (from B to A).

[0013] However, in the context of SPAKE2+ or other safety setup procedures, it is desirable to improve the safety setup procedures to further increase safety. SUMMARY OF THE INVENTION

[0014] An object of the present invention is to provide improved security for communication between devices and / or applications.

[0015] This object is achieved by devices, communication apparatus, devices and systems, methods and computer program products according to the appended claims.

[0016] Thus, security provisioning messages (e.g., PAKE-type or other key exchange / security provisioning messages) between two specific communication devices or applications can be associated with a given communication connection, e.g., by a session identifier, while the session identifiers of the communicating devices for the same security provisioning process do not need to be the same. This can be advantageous when the security provisioning is implemented at the application layer, since in this case, the security provisioning protocol is unaware of the underlying network identifiers (e.g., MAC or IP addresses).

[0017] Thus, when the communicating devices exchange one or more initial messages (e.g., preamble messages), it can be ensured that both devices have a single active security setup session or, if they have multiple active sessions, that they are connected to the correct peer devices.

[0018] Furthermore, the security setup messages can be reordered so that only two round trips are required. This is beneficial for achieving a more efficient protocol by reducing protocol latency and thus increasing usability. This can also be useful in cases where the protocol is to be executed over a restricted network and / or with many devices simultaneously.

[0019] According to a first aspect (e.g., related to a first end of a transmission link), there is provided means for controlling a security setup process between a first communication device and a second communication device over the transmission link, the means being adapted to: Placing information about a reliability setting applied by the first communication device for communication with the second communication device in a preamble message; and Transmitting the preamble message containing the reliability setting information to the second communication device in a preamble phase prior to the security setup process.

[0020] According to a second aspect (e.g. related to a second end of a transmission link), there is provided a device for controlling a security setup process between a first communication device and a second communication device over a transmission link, the device being adapted to: Receiving a preamble message from the first communication device in a preamble phase prior to the security setup process, which preamble message contains information about a reliability setting to be applied by the first communication device for communication with the second communication device; and Selecting an applied reliability setting for communication with the first communication device based on the received information about the reliability setting of the first communication device and a unique reliability setting of the second communication device.

[0021] According to a third aspect, a communication device is provided comprising the device of the first aspect and / or the second aspect.

[0022] According to a fourth aspect, there is provided a method for controlling a security setup process between a first communication device and a communication device over a transmission link, the method comprising: Placing information about a reliability setting applied by the first communication device for communication with the second communication device in a preamble message; and Transmitting the preamble message containing the reliability setting information to the second communication device in a preamble phase prior to the security setup process.

[0023] According to a fifth aspect, there is provided a method for controlling a security setup process between a first communication device and a second communication device over a transmission link, the method comprising: Receiving a preamble message from the first communication device in a preamble phase prior to the security setup process, which preamble message contains information about a reliability setting to be applied by the first communication device for communication with the second communication device; and Selecting an applied reliability setting for communication with the first communication device based on the received information about the reliability setting of the first communication device and a unique reliability setting of the second communication device.

[0024] According to a sixth aspect, there is provided a computer program product comprising code means for generating the steps of the above methods according to the fourth or fifth aspect when executed on a computing device.

[0025] Finally, according to a seventh aspect, a system is provided comprising two or more communication devices of the third aspect.

[0026] Accordingly, if the message exchange occurs over unreliable or unreliable transport layers, the communicating devices can adjust the reliability settings based on the exchanged reliability parameters to ensure higher reliability.

[0027] According to a first option, which can be combined with any of the above-mentioned aspects one to seven, the reliability setting can comprise at least one reliability parameter defining at least one selected from the group of the retransmission function or the timeout value. Retransmission options and / or delays can be used as parameters to adjust the retransmission settings. In one example, the retransmission function or the timeout value can allow at least one selected from the group that identifies a message as reliable and requires acknowledgment by the recipient, including information that identifies a message as acknowledgment for an identified previous message and including a maximum number of retransmissions required for a message.

[0028] According to a second option, which can be combined with the above first option or any of the above first to seventh aspects, the first communication device can comprise a commissioning tool configured to use the security setup process to interact with the second communication device for at least one operation selected from the group of commissioning, configuring, authenticating, and authorizing, or a security setup process. The proposed security enhancement can be applied to the security setup in connection with various commissioning, configuration, authentication, authorization, or security setup processes.

[0029] According to a third option, which can be combined with the first or second option or any of the first to seventh aspects above, the second communication device can comprise a medical device, a personal health device, or a smart home device. Thus, the proposed security improvement can be used for various applications in the medical, healthcare, and smart home fields.

[0030] According to a fourth option, which can be combined with any of the first to third options above or any of the first to seventh aspects above, the device can be configured to execute a password-authenticated security device protocol (e.g., a password-authenticated key exchange protocol) to mutually authenticate the first and second communication devices and establish a secret. The proposed security improvement can be applied in conjunction with password authentication.

[0031] According to a fifth option, which can be combined with any of the first to fourth options or any of the first to seventh aspects above, the preamble message can be exchanged between the first and second communication devices, or between the first communication device or the second communication device and a relay device, during an initial device discovery phase. This allows the initial device discovery phase to be used for exchanging the preamble messages of the proposed security enhancement between the associated communication devices or via a relay device.

[0032] According to a sixth option, which can be combined with any of the first to fifth options or any of the first to seventh aspects mentioned above, the preamble message may include a dedicated field for signaling the reliability setting information. This allows an available field of the preamble message to be used to convey the reliability setting information, thus reducing the signaling overhead.

[0033] According to a seventh option, which can be combined with any of the first to sixth options or any of the first to seventh aspects mentioned above, the applied reliability setting can be selected such that a highest reliability is adopted from the received reliability settings of the respective devices, or such that a lowest reliability is adopted from the received reliability settings of the respective devices, or such that the received reliability setting is applied. In this way, a flexible setting process can be provided that can be adapted based on user preferences and / or application requirements.

[0034] According to an eighth option, which can be combined with any of the first to seventh options or any of the first to seventh aspects mentioned above, a set of possible configurations of parameter settings can be preconfigured, with the reliability setting information identifying a selected configuration. This can reduce the signaling overhead, since only an identification (e.g., number, address, etc.) of a selected configuration needs to be signaled in the preamble message.

[0035] According to a ninth option, which can be combined with any of the first to eighth options or any of the first to seventh aspects mentioned above, a parameter configured by a third communication device during an initial configuration phase can be used for the reliability setting. Thus, the reliability settings can be controlled by a third communication device (e.g., a commissioning tool or other mobile device) during the initial configuration of the first and / or second communication device.

[0036] It should be noted that the above-mentioned devices may be implemented on the basis of discrete hardware circuitry comprising discrete hardware components, integrated chips or arrays of chip modules, or on the basis of signal processing devices or chips controlled by software routines or programs stored in memories, written on computer-readable media, or downloaded from a network such as the Internet.

[0037] It is understood that the devices, the communication apparatus, the methods, the computer program product and the system may have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

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

[0039] These and other aspects of the invention will be apparent from and explained with reference to the embodiments described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In the following drawings: shows Fig. 1 an algorithm for calculating a master key using a PBKDF; shows Fig. 2 a signalling diagram including a message exchange according to a safety device protocol, e.g. the SPAKE2+ or SPAKE2 process; shows Fig. 3 schematically illustrates a signaling and processing diagram for an improved security device protocol according to various embodiments; shows Fig. 4 schematically shows a block diagram of a communication device according to various embodiments; shows Fig. 5 schematically shows a block diagram of a PBKDF configurator element or function according to an embodiment; shows Fig. 6 schematically illustrates a block diagram of an implicit PBKDF parameter generator element or function according to one embodiment; shows Fig. 7 is a flowchart of a conditional PBKDF parameter exchange according to one embodiment; shows Fig. 8 is a signaling diagram of a preamble exchange with PAKE support information according to an embodiment; shows Fig. 9 is a signaling diagram of a preamble exchange with hash function information according to an embodiment; shows Fig. 10 is a signaling diagram of a preamble exchange with reliability information according to an embodiment; shows Fig. 11 schematically illustrates a block diagram of a lower layer protocol support for handling fragmentation according to one embodiment; shows Fig. 12 is a flowchart of a key derivation procedure based on exchanged preamble information according to one embodiment; shows Fig. 13 schematically illustrates an exemplary protocol stack according to an embodiment; shows Fig. 14 schematically shows a signaling and processing diagram for an improved safety setup process, e.g., based on SPAKE2(+), with a reduced number of round trips according to one embodiment; shows Fig. 15 schematically illustrates a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment; shows Fig. 16 schematically illustrates a signaling and processing diagram for personal IoT network scenarios according to an embodiment; shows Fig. 17 schematically illustrates a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment; shows Fig. 17b schematically illustrates a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment; shows Fig. 18 schematically illustrates a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment; shows Fig. 19 schematically shows elements and interfaces in a personal IoT network scenario; shows Fig. 20 schematically illustrates a signaling and processing diagram for personal IoT network scenarios according to one embodiment; shows Fig. 21 schematically shows a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment, and shows Fig. 22 schematically illustrates a signaling and processing diagram for UE-to-UE relay scenarios according to an embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] Embodiments of the present invention will now be described based on various modifications of security establishment procedures or protocols (SEP), e.g., relying on a generic PAKE or SPAKE2 or SPAKE2+ or others, wherein the protocol enables the establishment of a security property such as at least one of authorization, mutual authentication based on a shared password, key establishment based on a public key exchange, and key confirmation.

[0042] The inventor has recognized that real-world implementation and specific use cases may require such key exchanges to be better secured. Wireless networks are vulnerable to things like "man-in-the-middle" attacks. Thus, the inventor has recognized that key exchange messages can be better secured by providing at least one binding to a specific set of communicating parties and / or to a specific key exchange procedure. Likewise, it has been determined that they could benefit from improved derivation of one or more key derivation parameters based on one or more exchanged parameters and / or support for a potential key exchange upgrade to increase security (e.g., due to the higher processing power achieved, for example, by a quantum computer).Since communications are vulnerable to eavesdropping attacks and are time-critical, as a user may be involved, they can benefit from reducing the number of round trips of the key exchange process. Means to provide authentication and authorization, or reliable transmission (e.g., retransmissions), can also be beneficial when PAKE protocol messages are transported over a non-reliable channel (e.g., a channel via a relay device (e.g., UE-to-UE relay—a use case identified by the inventor as particularly vulnerable) or between personal IoT networks (PINs).

[0043] Several modifications or improvements in the use of a SEP based on embodiments are described below, where a first device or application uses PAKE to configure a second device or application. The following embodiments relate to improvements related to providing details about the preamble, details about how the exchange parameters in the preamble can be used in the PBKDF, details about negotiating a PAKE in the preamble, alternative options for interaction (e.g., selecting the device that initiates the PAKE communication) after preamble messages have different characteristics, and reducing the number of round trips.

[0044] The proposed enhanced SEP procedure can be applied in conjunction with wired or wireless transmission channels or communication streams across communication networks and possibly other networks. The 3GPP specifications 23.303, 23.304, 24.334, and 24.554 for 4G and 5G networks, respectively, define so-called Proximity Service (ProSe) functions to enable, among other things, connectivity for cellular communication devices (e.g., UEs) that are temporarily outside the coverage area of ​​an access device (e.g., eNB). This specific function is referred to as ProSe UE-to-Network Relay, or Relay UE. The relay UE is a communication device that helps another out-of-coverage (OoC) UE to communicate with the eNB (i.e., the access device) by forwarding application and network traffic in two directions between the OoC UE and the eNB.The local communication between the relay UE and the OoC UE is referred to as D2D communication, sidelink communication, or PC5 communication. The abbreviation "PC5" denotes an interface for sidelink communication as defined by ProSe. In addition, the abbreviation "UL" is used for the uplink direction from the communication device (e.g., UE) to the access device (e.g., eNB, gNB), the abbreviation "DL" is used for the downlink direction from the access device (e.g., eNB, gNB) to the communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UEs).

[0045] In addition, the 3GPP specifications TR 23.733 v15.1.0 and TR 36.746 v15.1.1 provide studies on architectural improvements that, for example, enable an Internet of Things (IoT) device (in the role of a remote UE) to operate at very low power by using a relay UE to connect to the wider network. Because the relay UE is physically very close, it can be reached with very low transmit power. This also includes security, speed, and stability improvements for ProSe. These extensions to ProSe are referred to as enhanced ProSe ("eProSe").

[0046] ProSe can also be used for direct communication between two UEs. Further details on ProSe, V2X, and sidelink communication at the radio level can be found in the 3GPP specifications TR 37.985, TS 38.300, and TR 38.836.

[0047] There are IoT networks in which devices communicate with each other and with other networks through a gateway. These networks can be referred to as Personal IoT Networks (PINs), and the devices in such a network can be referred to as "PIN elements." Such networks can communicate with the other network through a PIN element with gateway capability (PEGC). The PIN elements of a PIN can be managed by one or more PIN elements with management capability (PEMC). An example of such a network can be a 5G network, and document TR 23.700-18 describes extensions to 5G systems to support PINs according to the service requirements documented in TS 22.261.

[0048] According to TR 23.700-88 (for example), a PIN element can be a UE or a non-3GPP device that can communicate within a PIN (via a direct PIN connection, via a PEGC, or via a PEGC and a 5G (5GC) capability) or outside the PIN via a PEGC and a 5GC. According to TR 23.700-88, a PIN element with gateway capability is a PIN element with the ability to provide connectivity to and from a 5G network for other PIN elements or to act as a relay for communication between PIN elements. A PIN element with management capability is a PIN element with the ability to manage the PIN. According to TR 23.700-88, a direct PIN connection refers to the connection between two PIN elements, without a PEGC, a 3GPP RAN, or core network entity in the middle. Several key questions are addressed in TR 23.700-88, including extensions to the 5GC architecture to support PIN, PIN and PIN element discovery and selection, PIN and PIN element management, PIN communication, PIN authorization, PIN policy and parameter provision, or PIN and PIN element identification. TR 23.700-88 also includes several feasible solutions that illustrate such a protocol layer structure, as described in . Fig. 13. It should be clear that the layer structure of Fig. 13 is not limited to 5G networks and many other networks can use a similar layer structure.

[0049] Fig. 13 schematically shows an exemplary protocol stack according to an embodiment, which can be applied, for example, to a system as described in TR 23.700-88 with reference to its Fig. 6.0B.2-2.

[0050] As in Fig. As shown in Figure 13, a PIN layer (responsible for processing PIN IDs, PIN elements, PEGCs, and / or PEMCs) can be configured to run across multiple transport (TRA) and / or physical (PHY) layers (including WIFI, Bluetooth, 5G ProSe, etc.) and support a higher application (APP) layer (which may be configured to control light bulbs, sockets, washing machines, or any other controllable devices) in handling key exchange and / or other security device functions, as described in the following.

[0051] In one example, a supported PIN element function (S-PEF) may represent functionality that provides communication within the PIN layer (e.g., via a direct PIN connection or via a PEGC) or outside the PIN layer (e.g., via a PEGC). The PEF is also capable of communicating with a PEMC to be configured for discovery, authentication, and authorization.

[0052] An unsupported PEF (NS-PEF) may represent functionalities that communicate directly between the transport layer (TRA layer) and / or physical layer (PHY layer) and the higher application layer without using the intermediate PIN layer.

[0053] In addition, there may be key issues such as protecting PIN identification and PIN privacy, secure communication between PINEs, secure deployment of policies and parameters, authorization of a PIN element (PINE), authorization of PIN and PINE discovery, controlling PIN element access to another (e.g., 5G) network, authentication and authorization of a PINE, secure authentication of PINE, or secure deployment of credentials in non-3GPP devices via PEGC.

[0054] There may be situations where a relay device such as a UE-to-UE relay is involved, i.e., a first device A communicates with a second device B via a third device acting as a relay. In such a use case, issues may arise including privacy protection, integrity protection, confidentiality protection, or authorization via the UE-to-UE relay. The function of a relay can also be seen in a mesh network.

[0055] In the following, various embodiments with improvements of SEPs are described. Further details of the hardware components involved are given later with reference to Fig. 4, while details of the procedure and signaling-related steps are described with reference to Fig. 3 and 5 to 13 are described.

[0056] Some embodiments are in Fig. 3, where a first device or device A wishes to establish a secure communication channel with a second device or device B.

[0057] Fig. Figure 3 schematically shows a signaling and processing diagram for an improved SPAKE-based SEP according to various embodiments. In this diagram, the exchange of information and its direction between the two devices A and B is indicated by a corresponding arrow, and the processing steps are indicated by corresponding blocks, while the time in Fig. 3 progresses from top to bottom. Not all steps may always be required or applied, and some steps may be performed multiple times for greater accuracy or continuous processes.

[0058] The first device A may be 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 a PEGC. Device A and device B may communicate via Wi-Fi or other communication means such as Bluetooth Low Energy (BLE), Thread, or via a 3GPP standard, e.g., using Sidelink, or via a low-power communication protocol.

[0059] It may happen that a device (or a combination of devices) is used to configure other devices, in particular for connection to a specific network. The device(s) may be dedicated for this purpose, or it may be one or more general devices running a function. An example of a function running on a device may be an application (or "app") running on a smartphone. An example of a multiple device providing the function may be a device that forwards the messages used for configuration to another device, such as a server. The term "commissioning tool" may refer to the function provided by the device (or combination of devices) that performs the task of configuration, or it may refer to the device(s) themselves.

[0060] The two devices A and B may need to execute a PAKE, such as an extended or balanced PAKE (e.g., SPAKE2+ or SPAKE2, respectively), to authenticate each other and establish a secret. However, there may be many pairs of devices A and B doing the same thing at the same time. This may be the case, for example, if a commissioning tool (such as device A, if it provides a corresponding function) for the IoT network needs to commission many devices B, or if a device B can be configured by multiple commissioning tools.

[0061] Therefore, it is important to associate the PAKE exchange with a given communication link between two specific devices. Each device A or B can associate such a PAKE exchange with a specific communication (connection), identified by a given communication session identifier. The session identifiers of devices A and B for the same PAKE exchange do not have to be the same. This can be important when the PAKE process is executed at the application protocol layer, because in this case, the PAKE does not know the underlying network identifiers such as MAC (Media Access Control) addresses or IP addresses of the lower protocol layer.

[0062] When devices A and B exchange some initial messages (e.g. preambles, as in Fig. 2), devices A and B may need to ensure that they have only one active PAKE session or, if they have several, that they are connected to the correct peers.

[0063] In one example, Device A may be a commissioning tool that may interact with many potential devices to be commissioned and / or configured and / or authenticated and / or authorized and / or security configured, for example, smart home devices.

[0064] In one example, device B may be a smart home device that needs to handle multiple devices A (e.g., an app running on a mobile phone) running simultaneously when multiple users or multiple apps attempt to connect to it.

[0065] According to various embodiments, during the preamble phase (PRE), two preamble messages Pre_AB (transmitted from device A to device B) and Pre_BA (transmitted from device A to device B) are proposed for exchange.

[0066] In the Pre_AB message, device A can send its short (e.g., 8 bit) PAKE identifier ID_A to device B. As an additional option, device A can also include a (long) random value R_A in the Pre_AB message.

[0067] In the Pre_BA message, device B may send its short (e.g., 8-bit) PAKE identifier ID_B to device A. As an additional option, device B may also include a (long) random value R_B and a previously received R_A'. As a further option, described in later embodiments, device B may include in its Pre_BA message at least one of a PAKE protocol version identifier (PAKE_ID) and a reliability parameter (reli_par).

[0068] After receiving the Pre_BA message, Device A checks in step 301 whether R_A' is equal to R_A, 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, e.g., with an error message or report (e.g., to identify man-in-the-middle or other attacks), or discard the executed protocol, or restart the protocol.

[0069] Then the PAKE phase (which may be a SPAKE2+ process) begins, where in a first round, device A sends its public share p_A in a first message PAKE1 to device B, which in turn responds with its own public share secret p_B in a second message PAKE2. For the purposes of the present, a public share, e.g., p_A or p_B, is a value transmitted by a sending entity that allows the receiving party to derive a shared secret with the sending entity by combining the received public share with a private value known only to the receiving party, e.g., as defined in SPAKE2+. In a second round, both parties can use a unique and secret protocol transcript (TT) to derive a shared symmetric secret (Shared Key) from the protocol transcript.The key confirmations c_A and c_B are derived from the shared symmetric secret and exchanged in the third and fourth messages PAKE3, PAKE4, as initially discussed in the context of . Fig. 2 described.

[0070] In particular, in step 303 of Fig. 3 PBKDF parameters, based, for example, on information provided in the respective fields exchanged with the preamble messages or provided / configured by a central management entity. Then, in step S304, it calculates the shared secret p_A and transmits it in step 305 in the first message PAKE1, along with the most recently received R_B'.

[0071] After receiving R_B', Device B may check in step 306 whether R_B' is equal to R_B, 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 do not match, Device B may abort the process, e.g., with an error message or report (e.g., to identify man-in-the-middle or other attacks), or discard the executed protocol, or restart the protocol.

[0072] In step 308, Device B may determine or apply the PBKDF parameters, e.g., based on information provided in the respective fields exchanged with the preamble messages or as provided / configured by a central management entity. It then calculates the shared secret p_B in the second message PAKE2 and sends it to Device A in step 309. Additionally, Device B derives the shared secret based on the received shared secret p_A in step 310. It then derives the key confirmation c_B in step 311 and sends it to Device A in the third message PAKE3.

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

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

[0075] Finally, the completion message (FM) is transmitted from device B to the initiating device A to complete the procedure.

[0076] In some scenarios, e.g., those covered in TR 33.740, the exchange of preamble messages or some of their fields may occur in an initial discovery phase between UEs by a UE relay or between a UE and a UE relay, e.g., in a discovery phase related to UE-to-UE relay scenarios. In such scenarios, the PAKE exchange may occur during the establishment of a secure PC5 interface, which takes place after the discovery phase. In some scenarios, covered in TR 33.882, the exchange of preamble messages may occur in a discovery phase of a PINE.

[0077] By providing the preamble messages Pre_AB and Pre_BA with the PAKE identifiers ID_A and ID_B and the random values ​​R_A and R_B, respectively, PAKE sessions can be discriminated to ensure that devices A and B have only a single active PAKE session, or, if they have multiple ones, that they are connected to the correct peers.

[0078] In the above application of Fig. 3, a commissioning tool (Device A) may need to interact with many devices simultaneously. However, Device B may only interact with a single commissioning tool at a time. Thus, Device B can have a single active PAKE exchange process at any given time.

[0079] Therefore, in an alternative embodiment, the steps of Fig. 3, which include R_B, since Device B may assume that a single Device A is active at any given time, e.g., if 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, replacing R_B may not even be necessary.

[0080] Similarly, in an alternative embodiment, instead of exchanging two preamble messages Pre_AB and Pre_BA, a single preamble message, e.g., Pre_AB or Pre_BA, may be included. For example, upon receiving Pre_AB, Device B would respond with the first PAKE message. In such an alternative embodiment, Pre_AB may only include certain configuration parameters or preferences. In a specific application of this alternative embodiment with respect to 3GPP Short-Area Services, e.g., for use cases and requirements as in TR 33.740, the content of the Pre_AB message may be included in a discovery message of Model A, i.e., an advertisement message sent by an advertising UE. Upon receipt of the Pre_AB message, i.e., the advertising discovery message, by Device B, i.e.,by a monitoring device, device B would respond with a direct communication request (DCR) initiating the PAKE and including the first PAKE message.

[0081] Fig. 4 schematically shows a block diagram of a communication device 40 according to various embodiments, which may correspond to at least one of the aforementioned devices A and B (including the applications).

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

[0083] A preamble control unit or function (PRE) 48 is provided to send preamble messages (e.g., Pre_AB, Pre_BA in Fig. 3) to generate and decode signals transmitted and received by the transceiver 42 during a preamble phase of a PAKE process.

[0084] In addition, the communication device 40 comprises a PAKE control unit or function 46 for generating and decoding PAKE messages (e.g., PAKE1 to PAKE4 in Fig. 3) that are sent or received by the transceiver 42 during a preamble phase of a PAKE process.

[0085] In addition, the communication device 40 includes a PBKDF control unit or function 44 for deriving keys to be used in the PAKE process.

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

[0087] It should also be noted that the dashed blocks in Fig. 4 represent optional components that are described in more detail in subsequent embodiments.

[0088] The preamble control unit or function 48 may be configured to set and / or derive at least one of a peer session identifier (PSI) 401, a session limitation parameter (LIM) 405, a PAKE protocol version identifier (PV) 404, PBKDF configuration parameters, and PAKE configuration parameters for / from sent / received preamble messages.

[0089] As mentioned above, a unique and secret protocol transcript (TT) 406 can be used to derive a shared symmetric secret ("shared key"). To achieve this, the PAKE controller or function 46 and / or the PBKDF controller or function 44 can have access to the protocol transcript 406.

[0090] In addition, reliability settings (REL) 402 may be stored in the communication device 40, which, as described later, influence the communication behavior of the communication device 40.

[0091] In addition, as already described above, a PAKE ID (PID) 403 and / or a maximum transmission unit (MTU) 407 may be stored or set in the communication device 40.

[0092] In the Fig. 3 use case described above, where Device B may have a limited number of active PAKE sessions at any given time, Device B may need to limit the number of incoming requests.

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

[0094] The respective parameters (e.g., maximum number of preamble messages per time unit, maximum number of assigned peer ID sessions, and / or predefined timeout) may be stored as session limit parameters 405, which may be accessed by the preamble control unit or function 48 and / or the PAKE control unit or function 46.

[0095] The above limit settings are advantageous because otherwise an attacker could inject many potential preamble messages Pre_AB, thereby exhausting the available sessions.

[0096] Fig. 5 schematically shows a block diagram of a PBKDF configurator element or function according to an embodiment.

[0097] The PBKDF configurator element or function can be controlled by the PBKDF control unit or function of Fig. 4 be implemented.

[0098] As initially mentioned in connection with Fig. As described in Section 1, the PBKDF may require several parameters, such as a counter value or a salt value. These parameters can be configured, e.g., out-of-band (i.e., not included in the exchanged preamble and PAKE messages), by default, by manual user operation, or specified in a specification. In this case, however, these parameters are rather static. This can pose a problem in that the output of the PBKDF is always the same after the initial preamble phase is executed. However, in certain cases, it may be preferable to bind a particular preamble execution to a subsequent PAKE execution.

[0099] In one embodiment, the information exchanged in the preamble phase may be used as input to the PBKDF (i.e., to the PBKDF controller or function 46 in Fig. 4).

[0100] In particular, the PBKDF control unit or function 46 of the communication device 40 (e.g., Device A and / or B) may be configured to determine PBKDF parameters (e.g., as defined in Meltem Sönmez Turan et al.: "Recommendation for Password-Based Key Derivation, Part 1: Storage Applications," NIST Special Publication 800-132, December 2010), e.g., the count value or the salt value, as a function of the exchanged parameters in the preamble messages (e.g., Pre_AB, Pre_BA).

[0101] Note that the same embodiment may be applicable if / when another routine (e.g., a hash function or an HMAC) is used to derive a key based on a password (i.e., other than PBKDF).

[0102] As in Fig. 5, the exchanged random parameters R_A and R_B (or at least one of them) may be provided as input values ​​to the PBKDF control unit or function 44 and processed (e.g., logically or arithmetically combined) to obtain at least one of a count value (CV) and a salt value (SALT) of the PBKDF parameters.

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

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

[0105] In a third example, the salt parameter can be calculated as a hash function of one of the aforementioned salt parameter values.

[0106] In a fourth example, the salt parameter can be calculated as a cryptographic function, e.g., a hash function, of a function, e.g., a concatenation, of the exchanged parameters R_A and R_B.

[0107] In a fifth example, the salt parameter may be a subset of bits (e.g., truncation) of one of the aforementioned salt parameter values.

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

[0109] In a seventh example, exchanged parameters (e.g., R_A, R_B) can also be used together with a pre-shared salt parameter associated with the connection to be established.

[0110] Alternatively, the exchanged parameters, e.g., R_A and R_B, can also be used together with the shared password (e.g., concatenated with it).

[0111] As a further alternative, the PAKE identifiers exchanged by device A and B in the preamble messages can also be used as input parameters in the above examples.

[0112] The aforementioned alternatives can be applied, for example, when the PAKE is a balanced PAKE. They are also applicable, for example, when the password is stored in an extended PAKE in a secure element, e.g., a SIM card, that executes the PBKDF and returns only a value or token from which the password cannot be easily retrieved, e.g., only through an offline dictionary attack. This value can be the verification value pair L and w0. The aforementioned alternatives are also applicable when a communication device requests a third communication device to calculate and return such a value or token, taking into account the exchanged input parameters and a password that is not accessible or known to the communication device.

[0113] Alternatively, the values ​​R_A and R_B can also be combined in a later phase of the SEP to link the preamble to the key derived from the PAKE. For example, once the initiator and responder have established a shared secret K, a subsequent session key K' can be derived from K, R_A, and / or R_B.

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

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

[0116] However, exchanging PBKDF parameters may require additional space, such as in the QR code. For example, a QR code may need to encode more information and therefore be larger, requiring additional space on a package or product such as a light bulb. Furthermore, a wireless message may need to be longer, requiring additional power for its transmission.

[0117] One way to address this problem is to exchange PBKDF parameters implicitly. This means that the actual PBKDF parameter information can be read or exchanged for another purpose, e.g., to identify a given network or device type, and this information can be reused as a PBKDF parameter (e.g., a salt or counter value). This can also be advantageous because it allows the initiator to skip the preamble message exchange, meaning the initiator can directly send the first PAKE message.

[0118] Fig. 6 schematically shows a block diagram of an implicit PBKDF parameter generator element or function according to one embodiment.

[0119] For example, when a field for a first purpose (1st PP) 64 is swapped / read out, the same bits or a (predetermined) subset of the bits can be reused as a salt parameter or counter value. To achieve this, an extraction function (EXTR) 62 (e.g., a register or addressable memory section) can be used to copy the bits and provide them to a PBKDF parameter memory or register (PDKDF-P) 66. Examples of the first purpose can include identifying the network or details about the devices, such as their type. In particular, the first purpose can be anything other than the PBKDF operation.

[0120] The bits of the exchanged / read field(s) can also be extended, e.g., by concatenating (a subset of) them with a predefined bit sequence or by using them as input to a function, e.g., a hash function.

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

[0122] Implicitly swapping PBKDF parameters can limit control over their values, allowing at least some PBKDF parameters, such as the counter value, to be set to an inappropriate value. This can be prevented by adding a fixed value (e.g., a number) as an offset to the implicitly derived value, allowing the parameter value to be used (e.g., the counter value) to be calculated by the following function: Parameter value = fixed number + implicitly received value or any other function that guarantees a certain property, such as a minimum value of the PBKDF parameters.

[0123] It should be noted that a password can also be preconfigured, especially for embedded devices without an input device such as a keyboard. An example of such an embedded device is a light bulb. The password should not be exchanged unprotected over the air, but its reading can also be done implicitly. For example, device B may have a QR code encoding certain parameters. Device A can then read the QR code and derive the shared password from all or at least some of the read parameters. It should be noted that the password can also be received during preconfiguration from a central entity, e.g., a network function in a 5G system.

[0124] Fig. 7 shows a flowchart of a conditional PBKDF parameter exchange according to one embodiment that may be implemented by the PAKE controller or function 46.

[0125] The preamble message Pre_AB may be configured to provide an indication of whether or not Device A already knows the required PBKDF parameters. This may be because, in some use cases, Device A may have other access to the PBKDF parameters (e.g., via implicit signaling, as described above).

[0126] However, in other scenarios, it may not be feasible for Device A to know the PBKDF parameters, for example, if Device A is a commissioning tool that sends a request to many devices via Wi-Fi, Ethernet, Bluetooth, or the like. Similarly, in other scenarios, Device A can always know the PBKDF parameters.

[0127] Similarly, in some scenarios, Device A may be a commissioning tool and Device B may be an IoT device. Because IoT devices have widely varying communication and computing capabilities, a given IoT Device B may only support a certain level of security. Thus, Device B may be configured or requested, e.g., to specify its security strength in the preamble Pre_BA transmitted from Device B to Device A, which determines kLen (e.g., as configured by the manufacturer) and possibly the strength of a subsequent PAKE. Upon receiving Pre_BA, Device A may derive appropriate parameters to execute the PAKE using appropriate security parameters.

[0128] An attacker can exploit this flexibility (e.g., introduced by a protocol that specifies whether device A knows PBKDF parameters or not) to disrupt communication in various ways. For example, the attacker might intend to intercept the parameter information to better predict the potential output of the PBKDF. The attacker can trigger this exchange by placing themselves between devices A and B and modifying a respective specification in the Pre_AB message that requires the exchange of the PBKDF parameters. In another example, an attacker might want to modify the parameter information to easily force a failure in the subsequent PAKE phase. To do this, an attacker can place themselves between devices A and B and modify the exchanged information.

[0129] In the present embodiment, the security and robustness of the protocol can be increased by providing conditional transmission of, for example, the PBKDF parameters.

[0130] In step 710, device B checks whether it knows, for example, the PBKDF parameters of device A.

[0131] Note that in some cases, a third device (e.g., a management entity such as a network function in the 5G core network or an application running in the cloud) may perform such a verification on behalf of Device B. In such a case, Device B may (or is requested to) forward the request to the third device. The third device would then perform the verification protocol transcript and provide the verification result to Device B.

[0132] If device B (or a third device on behalf of device B) determines in step 710 that device A cannot know, for example, its PBKDF parameters, the procedure branches to step 720 and device B sends, for example, its PBKDF parameters, for example, in the preamble message Pre_BA, even if the content of the message Pre_AB indicates that device A has (or access to) the PBKDF parameters (since the message Pre_AB may have been maliciously modified).

[0133] Otherwise, if device B determines in step 710 that it knows that device A knows, for example, its PBKDF parameters, the procedure branches to step 730 and device B does not send, for example, its PBKDF parameters in the Pre_BA message, even if the content of the Pre_AB message indicates that device A does not have (or access to) the PBKDF parameters.

[0134] It should be understood that the PKBDF parameters of Device B may have been determined by methods described above, such as deriving a salt from the preamble parameters (e.g., R_A and / or R_B) or by an OOB method. Conditionally sending the PKBDF parameters can then serve as a further security enhancement, in addition to the other measures.

[0135] In one example, Device B may be configured to report or log an event where a preamble message with values ​​different from those expected gives Device B an indication of an ongoing attack.

[0136] The advent of quantum computers may require new cryptographic primitives (algorithms) for key encapsulation and digital signatures. Once a quantum computer is available, many conventional cryptographic primitives will be broken, including, for example, SPAKE2+.

[0137] Thus, an ecosystem, such as a smart home ecosystem, that begins by deploying a system running a protocol based on PBKDF plus SPAKE2+ or another SEP may require a protocol upgrade to integrate a quantum-resistant PAKE. For example, a different PAKE protocol (e.g., as described in Oleg Taraskin et al.: "Towards Isogeny-Based Password-Authenticated Key Establishment" or Xinwei Gao et al.: "Efficient Implementation of Password-Based Authenticated Key Exchange from RLWE and Post-Quantum TLS") can be executed in the PAKE phase after the initial preamble phase.

[0138] While one device, e.g., Device A, may be capable of executing multiple PAKE protocols, another device, e.g., Device B, may only be capable of executing one PAKE protocol (either the older SPAKE2+ or a new PAKE protocol, e.g., a quantum-resistant PAKE protocol). In this example, older devices are only capable of executing SPAKE2+, while new devices can execute a new PAKE protocol.

[0139] Fig. 8 shows a signaling diagram of a preamble exchange with PAKE support information according to one embodiment.

[0140] In this embodiment, a modified preamble message Pre_BA 802 may include a new protocol support field (PAKE-SUPP) indicating the PAKE protocol(s) supported by Device B. In one example, the protocol support field may include a SPAKE2 ID. If Device A receives and reads the corresponding field, then Device A knows which PAKE protocol it needs to execute. If Device A does not receive the new protocol support field, then Device A knows that Device B is an older device, e.g., executing SPAKE2+.

[0141] Similarly, a modified Pre_AB 804 message may include the new protocol support field (PAKE-SUPP), which indicates the PAKE protocol(s) supported by device A. When a new device B receives the protocol support field, device B knows that device A supports multiple PAKE protocols and can select an appropriate one.

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

[0143] It should be noted that other signaling parameters or information described in other embodiments may be combined with the information in the new protocol support field. Furthermore, further information, such as the manner in which the key derivation parameters (e.g., salt and count values) were / are obtained or that the other party used an OOB method, may be included.

[0144] Furthermore, certain parameters of the PBKDF and / or PAKE protocol may be customizable in the future, such as the hash function used in PBKDF. However, this requires both device A and device B to know which algorithm to use.

[0145] To address this problem, information about preferred parameters of device A, e.g., the preferred hash function or the supported hash function, can be exchanged in the Pre_AB message during the preamble phase.

[0146] Fig. 9 shows a signaling diagram of a preamble exchange with hash function information according to one embodiment.

[0147] To address the aforementioned problem, upon receiving a modified Pre_AB message 902 with a new hash function support field (HF-SUPP), device B may make a selection regarding the hash function used and provide (signal) its selection in a modified Pre_BA message 904 with the new hash function support field (HF-SUPP).

[0148] Older devices that are unable to understand the new hash function support field of the embodiment can simply ignore this field. If no corresponding response is returned, Device A can be configured to use older parameters.

[0149] In some cases, message exchange in the preamble and / or PAKE phase may occur over an unreliable transport layer, meaning messages may be dropped and retransmissions may be required. This may require extending the protocol itself with message retransmission capabilities or exchanging certain reliability parameters, e.g., as part of the Pre_AB and / or Pre_BA messages, with a lower-layer protocol (e.g., MAC protocol) capable of providing such reliability capabilities.

[0150] The reliability capability may include at least one of marking a message as reliable, such that the receiver must return an acknowledgment upon receipt of a message; including a field that identifies a message as serving 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 required retransmissions of a message (e.g., until an acknowledgment is received).

[0151] Fig. 10 shows a signaling diagram of a preamble exchange with reliability information according to one embodiment.

[0152] According to the embodiment, the reliability settings REL_A and REL_B (e.g., reliability settings 402 in Fig. 4) exchanged in the preamble phase, e.g., in a modified Pre_AB message 1002 and a modified Pre_BA message 1004 with corresponding new fields, and may apply to all subsequent messages in the protocol or to specific (e.g., marked or predefined) messages requiring reliability.

[0153] An underlying reliability protocol may allow a limited number of pending acknowledgments and retransmissions, e.g., a single one. Device A and Device B may be configured, e.g., when implementing the preamble and PAKE protocols, to accept or allow receipt of a given message only after a previous one has been properly accepted or received and a response provided.

[0154] For example, if device A sends a message M_A1, device B responds with a message M_B1, then device A responds with a message M_A2, then device B responds with a message M_B2, then M_A3, then M_B3, and so on. Then, one of the devices, e.g., device A, can be configured to accept the message M_Bi only after the message M_A(i-1) has been acknowledged.

[0155] In a first example, after receiving the reliability parameters REL_A and REL_B in the Pre_AB and Pre_BA messages, devices A and B may be configured to apply reliability parameters that ensure the highest reliability of the two sets of reliability parameters. For example, if the reliability parameter REL_A requires up to two retransmissions and the reliability parameter REL_B requires up to three retransmissions, then both device A and device B are configured for up to three retransmissions.

[0156] In a second example, after receiving the reliability parameters REL_A and REL_B in the Pre_AB and Pre_BA messages, devices A and B may be configured to apply reliability parameters that ensure the lowest reliability of the two sets of reliability parameters. For example, if the reliability parameter REL_A requires up to two retransmissions and the reliability parameter REL_B requires up to three retransmissions, then both device A and device B are configured for up to two retransmissions.

[0157] In a third example, upon receiving the reliability parameters REL_A and REL_B, devices A and B may be configured to apply the reliability parameters requested by the other party. For example, if the reliability parameter REL_A requires up to two retransmissions and the reliability parameter REL_B requires up to three retransmissions, devices B and A may perform up to two and three retransmissions, respectively.

[0158] The reliability parameters REL_A and REL_B can be preconfigured as a set of configurations, e.g., four possible configurations (which can be binary encoded with two bits) corresponding to different parameters. In one example, the preamble field can include only an identifier that identifies the selected configuration.

[0159] In the above example, the possible configurations may correspond to configurations with increasing reliability. Devices A and B can then be configured to select, for example, a configuration with the highest / lowest reliability offered based on a pre-provisioned and / or configurable policy.

[0160] Certain networks may have a limited MTU size. While SPAKE2+ has a short message length, the use of a future PAKE protocol may involve longer messages. Therefore, determining how to fragment messages and transmit them reliably is challenging.

[0161] Fig. 11 schematically shows a block diagram of a setting of a lower layer protocol for handling fragmentation according to one embodiment.

[0162] Thus, in one embodiment, the reliability parameters exchanged in an initial configuration phase (e.g., exchanged in the Pre_AB and Pre_BA messages of the preamble phase of SPAKE2+) may include an MTU parameter (e.g., MTU parameter 407 of Fig. 4). The MTU exchange parameters may refer to the physical layer MTU of device A, of device B, or of devices A and B. These MTU parameters, together with the PAKE version (e.g., PAKE version 404 in Fig. 4) provide an indication of fragmentation requirements, e.g., fragment size and / or number of fragments of subsequent messages.

[0163] In one embodiment, devices A and B may not know the allowed MTU (e.g., because it was preconfigured). Therefore, the messages exchanged in an initial configuration phase (e.g., preamble phase in SPAKE2+, SPAKE2, a PAKE, or another SEP) may include a parameter such as the size of subsequent messages in the protocol, so that fragmentation requirements in subsequent protocol messages can be derived / determined, e.g., whether certain messages in the subsequent protocol require fragmentation and how many fragments.

[0164] These parameters can be used to set a lower layer protocol that handles fragmentation.

[0165] As in Fig. 11, a lower layer protocol (LLP) 402 can be configured to handle both fragmentation and reliability.

[0166] The configuration (CONF) of a lower-layer fragmentation protocol may be implicit, as the lower-layer protocol 402 may monitor the length of a message (MSG) passed / forwarded by a higher-layer protocol 401 (HLP) and, based on this, determine the number of required fragmented message fragments (FRG-MSG) and, based on this number, the specific reliability parameters. This configuration may also be explicit, e.g., by passing / forwarding the maximum size of subsequent messages, e.g., PAKE messages, in an initial message, e.g., the preamble messages of the PAKE or another SEP.

[0167] The above parameters (e.g. MTU size and / or message size) can be configured in the Fig. 3 may be used to fragment certain messages, in particular, in one embodiment, the messages PAKE1, PAKE2, PAKE3 and PAKE4 may be fragmented, with the messages PAKE1 and PAKE2 having the highest probability of requiring fragmentation.

[0168] In one example, fragments may include a fragment identifier.

[0169] In another example, the configuration message may provide an indication to the lower-layer fragmentation protocol as to whether subsequent messages, for example, sent by Device A, can be fragmented and transmitted together. For example, Device A may require the transmission of messages 1 and 2, each 1200 bytes in length, while the MTU is 1000 bytes. If fragments cannot be transmitted together, a total of four fragmented messages must be transmitted (e.g., 1000 bytes, 200 bytes, 1000 bytes, and 1000 bytes). If fragments can be combined, only three fragmented messages need to be transmitted (e.g., 1000 bytes, 1000 bytes, and 400 bytes).

[0170] In one embodiment, a receiving party may be configured to respond only after all fragments of a particular message, e.g., PAKE 1, have been received and reassembled.

[0171] The underlying reliability / fragmentation protocol running on one device (e.g., Device A) may require the request of specific fragments (of a particular PAKE message) from another device (e.g., Device B) that have not been received, e.g., before a timer expires. Alternatively, a device may also acknowledge the fragments that have been received.

[0172] An entity in the device (e.g. the PAKE protocol (PAKE control unit or function 46 of Fig. 4) itself or an underlying reliability / fragmentation protocol on behalf of the higher layer protocol 401) can be configured so that no subsequent (PAKE) message is sent until all fragments of the previously expected (PAKE) message have been received.

[0173] The reliability parameters applied by a lower-layer reliability / fragmentation protocol may depend on whether a given message needs to be fragmented or not. Furthermore, the reliability parameters may depend on the number of fragments.

[0174] For example, if a message does not require fragmentation, a retransmission may be required within a given timeout. If a message requires fragmentation into multiple fragments, a higher timeout value may be applied.

[0175] In another example, a lower layer reliability / fragmentation protocol can be configured to limit how many fragments of a message can be sent at the same time.

[0176] In one embodiment, a party may request a specific fragment of a message if it has not been received before a timeout. For example, if the message PAKE1 needs to be fragmented into two fragments, Device B may be configured to request the second fragment from Device A if it has not been delivered before a given timeout.

[0177] This fragmentation capability (and such a lower-layer reliability and fragmentation protocol) can be applied not only to a PAKE protocol, but also to similar cryptographic protocols or those involving large messages or other applications that require fragmentation (e.g., due to the use of quantum-resistant primitives). This may include, for example, digital signatures or key encapsulation mechanisms.

[0178] In an alternative embodiment, a SEP including a PAKE may be configured to handle fragmentation of certain messages, e.g., by a lower layer protocol that offers fragmentation / reliability capabilities to higher layers, e.g., the SEP.

[0179] As in connection with Fig. 2 and Fig. 3, after receiving PAKE1 and PAKE2 messages, both the first device (e.g., device A) and the second device (e.g., device B) can be configured to derive secret keys that can be used to protect subsequent communications.

[0180] In a specific example, SPAKE2+ or another SEP may define that a protocol transcript TT (e.g., protocol transcript 406 of Fig. 4 or as defined in Taubert, T. et al.: “SPAKE2+, an Augmented PAKE (Draft)”) by means of a KDF (e.g., at the PBKDF control unit or function 44 of Fig. 4) can be generated based on input parameters from SPAKE2+ (or the other SEP) and PBKDF.

[0181] The encrypted bit sequence TT of the protocol transcript is used to derive the keys Ka and Ke. The key Ka is used to generate the exchange of acknowledgment messages (c_B, c_A) in the PAKE3 and PAKE4 messages. The key Ke is used to protect subsequent traffic.

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

[0183] Fig. 12 shows a flowchart of a key derivation procedure based on exchanged preamble information according to one embodiment.

[0184] In the embodiment, a KDF (e.g., PBKDF) is enabled to use input information exchanged in the preamble phase.

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

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

[0187] In step 1150, the key Ke is used to derive, by means of a KDF (e.g., PBKDF), two keys K_AB and K_BA to be used to protect the communication from the first device A to the second device B and vice versa.

[0188] Then, in step 1160, K_AB (or K_BA) is used to derive an integrity key and a confidentiality key 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 the messages sent from device A to device B (or from device B to device A).

[0189] In one embodiment, the integrity and confidentiality keys K_AB_i and K_AB_c and K_BA_i and K_BA_c can be derived directly from Ke using a single KDF call.

[0190] Such embodiments in which integrity and confidentiality keys are generated are useful, for example, in the context of 3GPP standards, where integrity keys are used to generate a message authentication code, e.g., by using a 5G New Radio Integrity Algorithm (NIA), and confidentiality keys are used to encrypt the messages, e.g., by using a 5G New Radio Encryption Algorithm (NEA).

[0191] Fig. 14 schematically shows a signaling and processing diagram for an improved SPAKE process or other SEP with reduced number of round trips according to one embodiment.

[0192] The protocol design (preamble phase and PAKE phase) of Fig. 3 requires a total of three round trips before the first device (e.g., device A) and the second device complete the exchange.

[0193] However, a protocol that involves multiple round trips results in increased protocol latency and higher utilization of, for example, communication or power resources. If a user is involved, such as a user using device A (e.g., a commissioning tool like an app running on a phone) to configure device B, the user must wait for the protocol to execute, and higher latency degrades the user experience.

[0194] Thus, in the embodiment of Fig. 14 the news of Fig. 3 so that only two round trips are required, reducing protocol latency and thus improving the user experience. This is also useful in cases where the protocol is to be executed over a constrained network and / or with many devices simultaneously.

[0195] To achieve only two round trips and thus a more efficient protocol, the second device (e.g., device B) must send the first PAKE1 message together with the Pre_BA message in step 902. This is feasible because, after receiving the Pre_AB message from the first device (e.g., device A) in step 901, the second device can already execute the PBKDF and generate the PAKE parameters (e.g., SPAKE2+) required for the first PAKE1 message. Note that in some PAKEs, e.g., SPAKE2+, this may require reordering some messages or operations due to their unbalanced nature. For example, a second value could be sent in the first PAKE1 message and a first value could be sent in the second PAKE2 message. In the case of the protocol described in T. Taubert et. al: “SPAKE2+, an Augmented PAKE (draft-bar-cfrg-spake2plus-03)”, 6.July 2021, paragraph 9, the value Y would be sent in the first PAKE1 message and the value X would be sent in the second PAKE2 message, where the values ​​X and Y are as defined in the SPAKE2+ contribution. Note that in some cases, it may also be necessary for the second communication device to prompt a user or for a third communication device to request the password or a password-based value, e.g., the verification value pair L and w0 in SPAKE2+, if the second communication device has not been previously provisioned or configured with it.

[0196] It should be noted that with such a protocol design, device B may be exposed to an increased risk of denial-of-service attacks by an attacker sending many initial Pre_AB messages, which may, for example, exhaust the available PSI. However, to avoid this problem, the present embodiment may be combined with the aforementioned limiting embodiment, with the limit settings based on the limiting parameters 405.

[0197] Furthermore, it should be 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 PBKDF is properly executed in step 905. This also applies if the Pre_BA and PAKE1 messages are combined into a single message. If these verifications are confirmed, device A can proceed to process the PAKE1 message, calculate its public portion, and transmit the PAKE2 message in step 905, keys (e.g., as in Fig. 12) for later communication and transmit PAKE3 in step 907. These messages PAKE2 and PAKE3 may optionally include R_B'.

[0198] Device B, after receiving R_B', PAKE2, and PAKE3 in step 908, may check R_B' for consistency, process PAKE2, and verify the correctness of PAKE3. If so, security keys (e.g., as in Fig. 12) for subsequent communication, and the message PAKE4 may be computed 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 may abort the process, e.g., with an error message or report (e.g., to identify man-in-the-middle or other attacks), or discard the executed protocol, or restart the protocol.

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

[0200] In contrast to the embodiment of Fig. 3, where the finish message (FM) is sent from 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, the present embodiment of Fig. 14 does not receive this termination message, since the first device infers the state of the second device from receiving the fourth PAKE4 message. If some fields in the termination message are required by device A, these fields can be sent along with the PAKE4 message.

[0201] Fig. Figure 15 schematically shows a signaling and processing diagram for UE-to-UE relay scenarios according to one embodiment. Fig. 15, a source UE (S-UE) and a destination UE (T-UE) intend to establish secure communication via a UE-to-UE-UE relay (UE-UE) using the PC5 interface. For example, the source UE may be a smart health sensor, the destination UE may be a smart watch, and the UE-to-UE relay may be a mobile phone. The three UEs may be connected to a core network (CN) via a radio access network (RAN). The devices may also be out of network coverage at some point in time. For this purpose, the UEs may be initially configured in steps 1501, 1502, 1503. These configuration steps may include a request by each of the UEs to the CN requesting authorization to use UE-to-UE relay services. This request may be initiated during the primary authentication of each of the UEs.The authorized UEs may be provided with respective security key creation materials for a subsequent discovery phase and / or security key creation material or authorization information for establishing a secure communication channel in steps 1501, 1502, and 1503. In steps 1504 and 1505, the source UE and the UE-to-UE relay, as well as the target UE and the UE-to-UE relay, may perform a discovery process, e.g., as described in TS 33.503. For example, the UE-to-UE relay may be an advertising UE, and the target and source UEs may be monitoring UEs. The UEs may also perform a Model B discovery, which includes two discovery messages. In steps 1506 and 1508, a password may be entered into the target and source UEs, e.g., in the case of a balanced PAKE.The password or a value derived therefrom can also be derived from the parameters configured in steps 1501 and 1503, e.g., in the case of an extended PAKE. The source UE and the destination UE can then establish a secure and authenticated channel. For this purpose, the source UE and the destination UE can use the protocol (procedure) of . Fig. 3 or Fig. 14 via the UE-to-UE relay. In step 1507, the source and destination UEs may exchange one or two messages, which may correspond to the preamble messages described in previous embodiments. These messages may include a session ID, a random value, an indication of PBKDF parameters, or other parameters as described above. These messages may also include a relay service code or other identifier related to the type of communication service to be established. In step 1509, the source and destination UEs may exchange PAKE messages to establish a secure authenticated channel. The source and destination UEs may optionally also exchange additional key confirmation messages. Finally, in step 1510, the source and destination UEs may communicate securely via the UE-to-UE relay.

[0202] It should be noted that the preamble may be replaced during the investigation phase for reasons of efficiency.

[0203] It should be noted that the investigation phase itself, with or without a preamble, can also be based on a PAKE.

[0204] In one embodiment, which may be combined with other embodiments, the security device may be arranged between a source UE (S-UE) or a destination UE (T-UE) and a UE-to-UE relay (UE-UE), e.g. as shown in Fig. 15, also as indicated in the aforementioned SEP embodiments. For example, the security device between T-UE and UE-UE / S-UE and UE-UE can be integrated / executed in / after steps 1504 and 1505, e.g., as in Fig. 17 shown.

[0205] Fig. Figure 17 schematically shows a signaling and processing diagram for UE-to-UE relay scenarios according to one embodiment. Fig. 17, steps 1701, 1702, 1703 relate to initial authorization and parameter provision. Step 1704 may, for example, relate to an initial discovery message or an initial direct communication request from S-UE to UE-UE. Step 1705 may, for example, relate to an initial discovery message or an initial direct communication request from UE-UE to T-UE. In step 1706, one or more of the steps or messages described in the embodiments may be performed. Note that step 1705 may include fields in Pre_AB as described in the previous embodiments. Step 1707 may, for example, be a direct communication acceptance message. This step may include fields in the last message in the embodiments, e.g., a last acknowledgement message or the PAKE4 message.In step 1708, one or more of the steps or messages described in the embodiments may be performed. Step 1709 may be a direct communication acceptance and may also include fields in the final message in embodiments, e.g., a final confirmation message. In step 1710, one or more of the steps or messages described in the embodiments may be performed.

[0206] In a related embodiment, which can be combined with other embodiments, the method used in the above embodiment and in Fig. 17 may be configured during the initial authorization and parameter provisioning phase, or generated by one device and exchanged with another device over an out-of-band (OOB) channel, or it may be entered by a user.

[0207] In a related embodiment, which can be combined with other embodiments, the method used in the above embodiment and described in Fig. 17 are based on a balanced or an extended PAKE.

[0208] In a related embodiment, which may be combined with other embodiments, the involved devices, e.g., S-UE or UE-UE or T-UE, may exchange an access token when executing the PAKE-based SEP, which may include an identifier, the identifier of the associated session, the user identifier, the identifier of the user's groups, privileges, access rights, etc. This information in the token may have been signed by the CN or an application in the CN and provided by a UE during the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in Fig. 17). This token should be stored in a secure location, e.g., on the SIM card in the UE when delivered to a UE. This token should be exchanged over a secure channel, e.g., after the SEP has been executed.

[0209] In a related embodiment, which may be combined with other embodiments, the involved devices, e.g., S-UE or UE-UE or T-UE, may receive an access token during the execution of the PAKE-based SEP, which may include an identifier, the identifier of the associated session, the user identifier, the identifier of the user's groups, privileges, access rights, etc. This information in the token may have been signed by the CN or an application in the CN and provided by a UE during the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in Fig. 17). This token could be received over a secure channel, e.g., once the SEP (such as a PAKE-based SEP) has been executed. The UE receiving the token may, in the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in Fig. 17) be configured with a policy that allows determining whether the UE sending the token is authorized to use the UE-UE service. Such a communication flow is Fig. 17b illustrates, similarly to Fig. 17, where DCR refers to a direct communication request, DCA refers to a direct communication acceptance, and steps 1724, 1727, and 1730 (further authorization (FA)) are based on such an authentication token. In step 1720, the initial authorization (IA) and the provision of parameters (PP) occur.

[0210] In a related embodiment, which may be combined with other embodiments, the PAKE1 message may be sent in the initial DCR message from the S-UE to the UE-UE and then to the T-UE. The PAKE2 message may then be sent back in the DCA message from the T-UE to the UE-UE relay and then to the S-UE. For example, in steps 1721, 1722, 1725, and 1728 in Fig. 17b. A device or method according to this embodiment may use implicit key confirmation, which does not include PAKE3 and PAKE4 messages. A device A according to this embodiment may transmit messages with Pre_AB-related fields in the DCR message to specify things like the password to be used, key derivation parameters, etc.

[0211] In a related embodiment, based on Fig. 18, steps 1801, 1802, 1803 relate to an initial authorization and parameter provisioning. Steps 1804 and 1805 relate to an initial discovery request message. Steps 1806 and 1807 relate to a subsequent discovery response. Step 1808 relates to the establishment of a secure PC5 connection between S-UE and UE-to-UE. Step 1809 relates to the establishment of a secure PC5 connection between UE-to-UE and T-UE. Step 1810 relates to the establishment of a secure PC5 (L2) or communication (L3) connection between S-UE and T-UE. The security aspects in steps 1808, 1809, and 1810 may be based on a PAKE-based SEP, as described above with reference to Fig. 17, and optionally on a further authorization phase based on authorization tokens.

[0212] In a related embodiment, which can be combined with other embodiments, the access token contains data related to the password used in the SEP. This allows the PAKE-based SEP to be linked to the token exchanged in a later phase.

[0213] In a related embodiment, which may be combined with other embodiments, when an extended PAKE is used in the SEP, the UE-UE relay may have been configured with password-based values ​​(such as the verification value pair L and w0 in SPAKE2+) to ensure that it is difficult for a UE-UE relay to impersonate an S-UE or T-UE. Thus, step 1706 of Fig. 17 may include a Pre_AB message or PAKE1 message, which is first sent from the T-UE to the UE-UE device. Thus, step 1708 of Fig. 17 may include a Pre_AB message which is first sent from the UE-UE device to the S-UE and to which the S-UE responds with a Pre_BA and / or PAKE 1 message.

[0214] In a related embodiment, which may be combined with other embodiments, when an extended PAKE is used in the SEP, the S-UE and the T-UE may have been 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. Thus, step 1706 of Fig. 17 may include a Pre_AB message, which is first sent from the T-UE to the UE-UE device and is answered by a PAKE1 message from the UE-UE relay to the T-UE device. Thus, step 1708 of Fig. 17 may include a Pre_AB message or PAKE 1 message, which is first sent from the UE-UE device to the S-UE.

[0215] In a related embodiment, which may be combined with other embodiments, when an extended PAKE is used in the SEP, the T-UE may have been configured with password-based values ​​(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 Fig. 17 may include a Pre_AB message or PAKE1 message which is first sent from the S-UE to the T-UE device.

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

[0217] In a related embodiment, which may be combined with other embodiments, the key confirmation messages in PAKE3 and PAKE4 may be implicit, such as in CPAKE, so that the exchange of PAKE3 and PAKE4 is not required.

[0218] In a related embodiment, which may be combined with other embodiments, the UE-to-UE relay or the source UE or destination UE may, during the initial authorization and parameter provisioning phase, e.g., related to Fig. 18, with the user information ID, the relay service code(s), the UE-to-UE relay layer indicator(s) and the traffic type (IP or non-IP); the UE-to-UE relay layer indicator indicates whether a particular RSC offers an SG-ProSe Layer 2 or Layer 3 UE-to-UE relay service, default destination Layer 2 IDs, security-related parameters for discovery or PAKE, such as a password or password-based value or a further authorization process, such as an authorization token or policy or cryptographic key material to verify a token, validity period of the parameters.

[0219] In a related embodiment, the provision of security parameters may be performed by the 5G Direct Discovery Name Management Function (DDNMF), the Prose Key Management Function (PKMF), or the PCF.

[0220] In a related embodiment, which may be combined with other embodiments, the required discovery keys and / or passwords and / or public keys and / or policies are configured in the initial authorization and provisioning phase (e.g., steps 1701, 1702, 1703 in Fig. 17). These may, for example, be required to discover other UEs and / or perform a (PAKE-based) SEP and / or verify the access token and / or verify the authorization of a UE based on the token and a policy. A PKMF could be responsible for such parameters as a public key. A UE could contact 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 the respective networks (home and service network) may need to share some of these parameters, in particular the public key used by each of them, which is linked to the secret private key. Once this sharing is established, all relevant public keys can be configured in the initial authorization and provisioning phase.If this is done, the PKMF of a UE (e.g., source UE) may be responsible for signing the access token. Additionally or alternatively, when a UE (when roaming) performs the initial authorization and provisioning phase, a UE may first contact its PKMF and be redirected by its own PKMF to the PKMF responsible for discovery and PCS key generation materials, including access token management (i.e., the home network PKMF). This PKMF may be responsible for managing the public key associated with the private key used to sign the access token. This PKMF may manage policies for authorization or rely on the PCF. The PKMF could thus retrieve (locally or from the PCF) a policy for the UE; the PKMF could also assign access rights to the UE and store them in an access token, which can subsequently be signed.This signed access token is then configured in the UE.

[0221] In a related embodiment, which can be combined with other embodiments relating to parameter provisioning inside and outside the coverage area, the provisioning of passwords can occur either inside the coverage area or outside the coverage area in step 0. If provisioning occurs while a UE is within the coverage area, the UE is configured with one or more passwords (“raw passwords” or “password-derived tokens”). Each “raw password” or “password-derived token” has “metadata” associated with it. The “metadata” can include “password hint,” “expiration date,” and “access rights.” The “password hint” field specifies which password should be used; the “expiration date” field specifies how long a password is valid; and the “access rights” field specifies which authorization a password provides.The bit sequence used as a "password" in a PAKE is calculated as a KDF from the "raw password" and the associated metadata fields. In the case of an extended PAKE, the "password-derived token" can be derived from the "password" itself. As in other embodiments, the parameters can be received from the 5G PKMF and the 5G DDNMF when the UE is within the coverage area.

[0222] In a related embodiment, which may be combined with other embodiments or used independently with respect to in- and out-of-coverage parameter provisioning, a UE is also provisioned with an out-of-coverage policy during in-coverage provisioning that determines whether a UE may use a temporary password (or credentials, e.g., keys) entered or provided by the user when the UE is (or was) outside the coverage area. When outside the coverage area, a UE may be provisioned with a temporary password entered by the user if the out-of-coverage policy allows it.This "out-of-coverage-area policy," configured during the initial authorization and provisioning phase when the UE is within the coverage area, can also be used to control other communication or security aspects when the UEs are outside the coverage area, including a) the security protocol that must / is allowed to be used or b) the security credentials to be used. For example, a UE might be able to establish a secure PC5 connection via a UE-to-UE relay when it is outside the coverage area, e.g., based on some of the aforementioned embodiments or based on some solutions, e.g., in TR 33.740. Note that this is only permitted if the UE has been configured with a policy that allows it.For example, if a UE is configured when it is within the coverage area (e.g., according to the configuration in the aforementioned embodiments or Solution #3 in TR 33740 or in the aforementioned embodiments), the UE may be configured with a policy regarding the type of protocol or configuration parameters to be used outside the coverage area, e.g., with parameters related to Solution #4 in TR 33740. Once a UE, e.g., the source UE, has performed the discovery phase with a UE-to-UE relay, the UE may send a Direct Communication Request (DCR) message. If the UE is outside the coverage area and the preconfigured policy allows it, the UE may use the out-of-coverage solution. In this case, the UE sends a Direct Security Request message as in Solution #4 in TR 33.740 or may prompt the user to enter a short password (e.g., if no password is available or passwords have expired). This DCR message may include a flag indicating the solution choice (e.g., due to out-of-coverage reasons), although this flag may be implicit in the transmission of out-of-coverage parameters. For example, if the UE-to-UE relay receives a DCR message with a specific field, e.g., an authorization token as in step 2 in solution 4 in TR 33.740, then the UE-to-UE relay could proceed to step 3 in solution 4 in TR 33.740 instead of step 3 in solution 3 in TR 33.740. For example, if the UE-to-UE relay receives a DCR message with an out-of-coverage flag, it could prompt the user to enter an out-of-coverage password (if the policy allows it).Furthermore, upon receiving this DCR message, the UE-to-UE relay device may need to check (based on a policy it received when it was in the coverage area) whether the connectivity environment is outside the coverage area and the out-of-coverage-area solution is applicable. If not, the UE-to-UE relay may not respond to the DCR message, or alternatively, the UE-to-UE relay may request a DCR message from the UE that includes the in-coverage-area parameters so that an in-coverage-area solution can be used to establish PC5 security.

[0223] In a related embodiment, which can be combined with other embodiments or used independently, and which relates to parameter provisioning and solutions for use within the coverage area and outside the coverage area, it is advantageous if the verification of the type of solution and the parameters to be used is performed before a key setup and authentication phase. In particular, it is advantageous if the verification of the source UE authorization (step 4 in solution no. 4 in TR 33740) is performed before the direct authentication and key setup procedure (step 3 in solution no. 4 in TR 33740), wherein the source UE authorization is performed by verifying the authorization token received in the DCR message (step 2 in solution no. 4 in TR 33740). The advantage is that in this case, the risk of a denial of service is lower.Furthermore, it is advantageous that resources are saved (step 3) if the UE is unauthorized. In the case of solution #4 in TR 33.740, the verification may include verification of the authorization token and / or verification of the environment outside the coverage area. Note that the above applies, for example, in the case of Sol#4, since the verification of the source UE authorization in Sol#4 is based on authorization tokens shared in the DCR message, and the sharing must be done securely by default, as explained in other embodiments. Since the receiving party (e.g., UE-to-UE relay) already has the authorization token at this point (after receiving the DCR message), the receiving party can verify the authorization without delay. This is not always possible. For example, step 1724 in . Fig. 17b may not be executed before step 1723 because the authorization token exchanged in step 1724 is protected based on the secure connection established in step 1723.

[0224] Thus, in a further related embodiment, the exchange of the authorization token may be integrated into step 1723 itself. The authorization token may, for example, be exchanged once a key has been established in step 1723. For example, with reference to Fig. 14, an authorization token must already be included in the PAKE 2 message. If a PAKE (or more generally an SEP) is integrated / implemented using Direct Auth and Key Establish Request and Direct Auth and Key Establish Response messages (and / or Direct Security Mode Command and Direct Security Mode Complete) as defined in TS 36.536, the authorization tokens can be exchanged in these messages as long as the underlying SEP (transported, for example, using Direct Auth and Key Establish Request and Direct Auth and Key Establish Response messages) allows the authorization token to be protected. This may require defining a new "Authorization Token" message field to indicate that one of these messages includes one or more protected authorization tokens.

[0225] In a related embodiment, the authorization token exchanged in step 2 can advantageously be protected as follows. Instead of using the approach in TS 33.503 paragraph 6.3.5.2 (which can only protect up to 256 bits of data), in which the key selected in step 1 in TS 33.503 paragraph 6.3.5.2 is used to generate a keystream (step 2 in TS 33.503 paragraph 6.3.5.2) used to encrypt the private fields of the message (step 3 in TS 33.503 section 6.3.5.2), the key selected in step 1 in TS 33.503 paragraph 6.3.5.2 is used as the encryption key (or to derive one) used in combination with a NR encryption algorithm (NEA) to encrypt the private fields of the message, e.g. B. the authorization token. An advantage of this approach is that the authorization token (which is longer than 256 bits) generated in step 2 in Sol#4 in TR 33.704. Another advantage is that the same technique can be used to protect the authorization token sent by the UE-to-UE relay to the source UE, e.g., in step 5 in Sol#4 in TR 33.704, where the input fields for the NEA algorithm might differ, e.g., the DIRECTION field might be set to 0 in step 2 and to 1 in step 5.

[0226] In a related alternative embodiment, it may be advantageous in some cases if the authorization token is not exchanged in the DCR message (step 2 in solution no. 4 in TR 33.740), but immediately before the authorization token verification (step 4 in solution no. 4 in TR 33.740) and the direct authentication and key establishment procedure (step 3 in solution no. 4 in TR 33.740), 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 way, namely by using the keys 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 paragraph 6.3.5, which is used to protect DCR messages, since the current protection is limited to a maximum of 256 bits.

[0227] In a related embodiment, which may be combined with other embodiments or used independently with respect to in- and out-of-coverage parameter provision, the negotiation of the type of protocol or parameters to be used (in- or out-of-coverage) may be negotiated, signaled, or verified in the initial discovery phase.

[0228] An embodiment is shown in Fig. 21, wherein in step 2101, the UEs perform initial authorization and parameter provisioning for in-coverage and out-of-coverage situations. This step includes configuring parameters for various solutions / SEPs for in-coverage and out-of-coverage security setup and authorization. In step 2102, the source UE and the UE-to-UE relay perform a discovery phase. In step 2103, the source UE determines its out-of-coverage (in-coverage) situation and selects a security solution / SEP and / or security parameters for its out-of-coverage (in-coverage) situation.The source UE accordingly creates a Direct Communication Request (DCR) based on the selected out-of-coverage (in-coverage) solution and the security parameters. It may include an SEP identifier. In step 2104, the UE-to-UE relay receives the DCR message and determines whether the DCR message implicitly or explicitly contains parameters for an out-of-coverage (in-coverage) solution / SEP. The UE-to-UE relay then checks whether the requested solution / SEP and the security parameters match the out-of-coverage (in-coverage) situation and whether a policy deployed in step 2101, together with the authorization information received in step 2103, allows the use of the solution / SEP and the security parameters.Once this policy has been evaluated and the result is positive, the UE-to-UE relay will proceed with the execution (or facilitation of the execution) of the requested solution / SEP outside the coverage area (inside the coverage area). Alternatively, in case of a negative result, the UE-to-UE relay may indicate the source UE policy mismatch based on the configuration and potentially request another DCR message including a requested solution / SEP and security parameters. In step 2105, the UE-to-UE relay may perform one of the following alternative steps: Step 2105-A, sending a message to the source UE to proceed with an in-coverage area solution. Step 2105-B, sending a message to the core network to proceed with an out-of-coverage area solution.Step 2105-C, Send a message to the source UE indicating that the security setup based on the exchanged parameters is not feasible and requesting alternative parameters. Note that the aforementioned steps can be repeated for the security setup process and authorization between the target UE and the UE-to-UE relay. Note that the aforementioned process illustrates how UEs signal and agree on a solution and the security parameters to be used via the DCR message.

[0229] This signaling and agreement phase can also be carried out during the investigation phase.

[0230] In a related embodiment, the UE-to-UE relay of the source UE or the destination UE could have indicated in the discovery message whether it (the UE-to-UE relay) is within the coverage area or outside the coverage area. This can be done in discovery model A when the UE-to-UE relay acts as the advertising UE. This can be done in discovery model B when the UE-to-UE sends a response discovery message to the source UE indicating whether it is within the coverage area or outside the coverage area.

[0231] In a related embodiment, the relay service code (RSC) specifies the type of service to be used by 5G ProSe source / destination and UE-to-UE relays, and thus the RSC implicitly specifies the type of (security) solution / procedure (e.g., within the coverage area or outside the coverage area, i.e., with core network support or not) that is preferred. For example, - a source UE could use several (e.g. two) different types of relay service code to identify UE-to-UE relays capable of offering the establishment of a secure communication link with and without the assistance of a network. - For example, the service code may specify the type of required and / or preferred security procedure.

[0232] A related embodiment, where signaling and agreement are performed in the discovery phase, is described in Fig. 22. In Fig. 22, step 2202 refers to the initial configuration and authorization step in which source UE / destination UE / UE-to-UE relay devices are configured; step 2202 refers to the initial discovery, which could be Model A or Model B; step 2203 is the policy evaluation, in which at least one of source UE, destination UE, UE-to-UE relay devices determines the preferred solution to be used (e.g.

[0233] In-coverage solution or out-of-coverage solution, i.e., security procedure with or without network support); step 2204 refers to an initial message used to trigger the establishment of the UE-to-UE relay security setup.

[0234] In one variant, which could be combined with other variants, the source UE could send a discovery request message (discovery model B) in step 2202, which can be forwarded by the UE-to-UE relay to the target UE. The target UE can respond with a response discovery message to the source UE via the UE-to-UE relay. In another variant, the source UE could send an advertisement message (discovery model A) in step 2202, which is received by the UE-to-UE relay and forwarded to the target UE. In another variant, in step 2202, the UE-to-UE relay is the device that sends the advertisement / request messages to the source UE and the target UE and potentially receives response messages from the source UE and the target UEs.In these request and announcement discovery messages, the source UE and / or UE-to-UE relay and / or destination UE could indicate their in- or out-of-coverage situation, as well as their preferences for the type of in- / out-of-coverage solution (i.e., a security procedure with or without network support). In the response discovery messages, the UEs could indicate their preferences and / or selections.

[0235] In a variant that could be combined with other variants, in step 2203, one or more of the devices may evaluate a configured policy and decide which solution(s) should be used, preferred solution(s), or proposed for use. For example, the target UE could be configured with a policy that allows selecting a preferred solution, which is then proposed (e.g., via a message) to the UE-to-UE relay and the source UE. For example, the target UE could be configured to indicate (via a message) one, two, or more solutions in preferred order of use. For example, upon receiving the message sent by the target UE, the source UE could review the preferred selection(s) of the target UE and evaluate them against the evaluation of its own policy, e.g.,It could give priority to either its own preference or the preference of the other party. For example, each of the source UE, UE-to-UE, and destination UE can evaluate the policy and select a preferred solution. Then, an exchange of proposal and acceptance / confirmation can occur between the source UE, UE-to-UE, and destination UE.

[0236] In a variant that could be combined with other variants, step 2202 and step 2203 could occur simultaneously, e.g., step 2203 occurs at the target UE after receiving a challenge discovery message and before sending a response discovery message.

[0237] In a variant that may be combined with other variants, step 2203 occurs at the source UE upon receipt of the response determination message.

[0238] In a variant that could be combined with other variants, the selection of the UE-to-UE relay, e.g., as in discovery, could depend on the evaluation of the policy that determines the preferred in- / out-of-coverage solution. For example, a UE-to-UE relay outside the coverage area could be given a lower priority compared to a UE-to-UE relay inside the coverage area. For example, an in-coverage UE-to-UE relay enabling an out-of-coverage situation (e.g., due to recent / unexpired security parameters) could be prioritized compared to an in-coverage UE-to-UE relay with outdated parameters inside the coverage area.

[0239] In a variant that could be combined with other variants, a UE (e.g., UE-to-UE relay) receiving a message in step 2204 may still disagree with the selection made by the sending UE (e.g., source UE) and may, in a similar manner as in the above embodiments and / or as in Fig. Answers as described in 21.

[0240] In one variant, a UE may require UE-to-UE communication for emergency reasons. In this case, the UE, e.g., a source UE, may include an emergency indication such as "Emergency RSC" when, for example, distributing discovery messages or sending an initial DCR message. The UE-to-UE relay receiving this indication may determine how to process the message, e.g., based on its context (e.g., coverage area situation) and / or a policy / configuration. For example, depending on the context and policy, the source / destination UE and / or the UE-to-UE relay may perform one or more of the following actions: - Requesting / providing emergency services based on the policy; - Logging emergency requests based on the policy; - Treating an emergency request as a UE-to-UE communication and / or a UE-to-network communication, depending on the context. For example, if the UE is outside the coverage area, the communication is treated as a UE-to-UE communication (i.e., the communication is directed to other UEs in the area), and if it is within the coverage area, it is treated as a UE-to-network communication (i.e., the communication is directed to the network) and / or a UE-to-UE communication (i.e., the communication is directed to other UEs in the area). - Provision / request UE security capabilities and / or PC5 signaling security policy. - Sending an indication to the core network regarding the emergency service (provided) based on the policy; - Disabling security or not enforcing security, even if the policy requires security under normal circumstances. This can apply to: ◯ The discovery messages exchanged between the source UE and the destination UE via the UE-to-UE relay. ◯ Establishing security in PC5 connections. - Allow / require the use of temporary (e.g., user-entered) credentials (e.g., passwords) to provide a minimum level of security based on the policy.

[0241] This approach has the advantage that communication via UE-to-UE relays can be used in emergency or safety-critical situations, e.g., to enable two UEs that are normally unable to communicate with each other to actually communicate with each other. For example, the source UE could be the UE of a person in need of assistance (e.g., because they are being attacked or suffering an asthma attack), so that when that person requests assistance, the assistance / emergency message can be relayed via a UE-to-UE relay to other UEs in the vicinity, thus allowing the person to quickly receive assistance. For example, the source UE could be a tag attached to a piece of luggage, and if the tag cannot establish a connection with its UE (e.g., the UE of the owner of the luggage), the tag (acting as the source UE) could send an emergency message to attempt to reach "its" UE.

[0242] In a related variant, the message sent by the source UE may include the cause of the emergency or information about the UE / person requesting assistance (e.g., a description of the UE / person or a description of the piece of luggage).

[0243] In a related variant, the message sent by the source UE may include the cause of the emergency or information about the desired destination UE / person (e.g., a description of the UE / person).

[0244] 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., a security procedure with or without network support). This policy may be applied to the source UE and / or the UE-to-UE relay and / or the destination UE. This policy may include one or more of the following: - Which of the supported solutions should be preferred or used or authorized when used within the coverage area or when used outside the coverage area by one or more of the devices involved, namely source UE, destination device A and UE-to-UE relay; - Which authorization mechanism is preferred or used when used within the coverage area or when used outside the coverage area by one or more of the devices involved, namely source UE, destination UE and UE-to-UE relay; - Priorities assigned to different devices, used to determine which solution is preferred, e.g., (1) when different devices have different preferences and / or (2) when the priority might depend on the coverage area of ​​each device. For example, if the source UE is within the coverage area and other UEs are outside the coverage area, then the source UE's solution is prioritized, and if all UEs are outside the coverage area, a default prioritization list determines which of the UEs' solutions to use; - Which parameters of a supported solution are preferred or to be used or authorized within or outside the coverage area; - Whether communication may / can be established, e.g., in an emergency situation (e.g., for emergency services) and what security credentials / security configuration / security mechanism are required, e.g., whether null cipher and / or integrity algorithms are permitted / tolerated; - Whether / how security parameters (such as a password or a key, etc.) of an out-of-coverage solution can be generated and / or entered when the devices are outside the coverage area; - Which (default) authorization capabilities or access rights are assigned to the generated and / or entered (temporary) credentials (e.g. passwords, keys) when other credentials (e.g. long-term credentials) have expired and the UEs (e.g. source UE and UE-to-UE relay) are out of coverage area. - Which UE-to-UE relay is preferred when multiple UE-to-UE relays are available may depend on their conditions (e.g., within coverage area / outside coverage area) and / or the conditions (e.g., within coverage area / outside coverage area) of the source UE (and / or destination UE). For example, in certain situations, a UE-to-UE relay within the coverage area might be preferred, while in other situations, a UE-to-UE relay outside the coverage area might be preferred. - Which security method / procedure is to be used or preferred for path switching or relay reselection, and based on which factors (e.g., coverage area situation, performance requirements, etc.), e.g., whether to use a standard security setup procedure (e.g., a procedure used when no communication between source UE and destination UE via a UE-to-UE relay is available, e.g., Sol #3, or #4, or #10 in TR 33.740), or to skip it and use an optimized procedure, e.g., by reusing the already established security context (e.g., security policies and security algorithms) from the previous PC5 unicast connection to (re-)establish the secure communication connection via a new relay (e.g., as in Sol #14 in TR 33.740), e.g., for optimization purposes.If the source UE and destination UE have a secure communication link via a first UE-to-UE relay established with a security procedure without network support (because the first UE-to-UE relay was outside the coverage area), then an optimized security procedure (e.g., Sol #14 in TR 33.740) may not be preferred when performing a path change and transitioning to a second UE-to-UE relay (which is within the coverage area and can offer a security procedure with network support). - Whether more than one active connection between a source UE and a destination UE via multiple UE-to-UE relays is allowed, based, for example, on the coverage area situations and / or power requirements and / or resource constraints of the UE. - Priorities for choosing a solution in case of a duplicated security association using the same or different (types of) solutions. A first example of this could be that a source UE starts a first security association (e.g., with a DCR message) using an in-coverage (or out-of-coverage) solution and then (e.g., when a timer expires) also sends a second security association (e.g., with a second DCR message) using an out-of-coverage (or in-coverage) solution, at which time the source UE could receive the response for the first security association. The policy could specify (by specifying a priority) which solution to use in such a case. The priority in the policy could, for example, be applied by the UE-to-UE relay or the source UE.A second example of this could be that a source UE initiates a first security association (e.g., with a DCR message) using an in-coverage (or out-of-coverage) solution with a first UE-to-UE relay and sends a second security association (e.g., with a second DCR message) using an in-coverage (or out-of-coverage) solution with a second UE-to-UE relay, at which time the source UE could receive the response for the first security association. The priority in the policy could, e.g., be applied by the source UE or the CN. - Whether two UEs, e.g. source UE and destination UE (sharing / having a first secure communication link via a first UE-to-UE relay established using a security procedure without network assistance because, when the first secure communication link was established, the relay was outside the coverage area) should re-establish the security communication using a security procedure with network assistance when the first UE-to-UE relay returns to the coverage area and / or a second UE-to-UE relay is detected to be within the coverage area. - A threshold / limit on the number of attempts that can be made to find a solution before, for example, stopping the process and / or blacklisting the other device and / or reporting the problem to the core network.

[0245] The end UEs (i.e., source and destination UE) and the UE-to-UE relay may have different preferences for which solutions and / or security parameters (e.g., password, cryptographic keys) should be used, and therefore they may exchange negotiation messages, e.g., as in Fig. 21 Steps 2103, 2104, 2105 to either agree on a solution and / or security parameters or to terminate the connection. The negotiation relies on the security policies provided to the UEs and may take into account the status of the UEs' coverage area at the time of negotiation (e.g., end UE and UE-to-UE relay). The following embodiments may apply.

[0246] In one embodiment, which can be combined with other embodiments or used independently, the end UE may be located within the coverage area, while the UE-to-UE relay may be located outside the coverage area; the end UE may request an within-coverage-area solution, i.e., a security procedure that requires network support, in which case the UE-to-UE relay may approve it if permitted according to its security policy (it may also be requested, but the request may be rejected if the UE is not authorized to use this solution). In this case, it could be the end UE that communicates (or facilitates communication) and is supported by the network in security setup and authorization. For example, TR 33.740 describes solutions (e.g.,Sol #3), where the UE-to-UE relay is the entity that relies on network support to establish the secure connection between the UE-to-UE relay and the destination UE when the UE-to-UE relay is within the coverage area. For example, step 3 in Sol #3 in TR 33.740 v0.6.0 is a key requirement that includes parameters received from one of the end UEs, in this case the destination UE. If the UE-to-UE relay is outside the coverage area, but the destination UE is within the coverage area, the destination UE can act as a UE-to-network relay for the UE-to-UE relay, so that the messages from step 3 are forwarded via the destination UE (e.g., acting as a UE-to-network relay). Similarly, the end UE located within the coverage area may also forward the CN's key response to the UE-to-UE relay in step 4.

[0247] In another related embodiment, which may also be used independently, an end UE (e.g., source UE): - receive an indication from the UE-to-UE relay, e.g. including its identity, - send the content of the initial DCR message to the network, e.g., step 3 in Sol #3, in a key request to the CN on behalf of the UE-to-UE relay, - receive the key response, e.g., step 4 in Sol #3, from the CN on behalf of the UE-to-UE relay, - send a DCR message including the content of the received key response from the CN to the UE-to-UE relay.

[0248] This embodiment allows an end UE (e.g., source UE) that may wish to use a UE-to-UE relay to directly leverage network support to establish the security of this connection between the UE and the UE-to-UE relay. This embodiment has the advantage of reducing the number of exchange messages.

[0249] This embodiment can also be similarly applied to the exchange between a second end UE (e.g., target UE) and a UE-to-UE relay, for example, the key request and key response sent by the (first) end UE. UE exchanges can also refer to the key creation material required to establish the secure connection between the UE-to-UE relay and the second end UE (e.g., target UE).

[0250] In another embodiment, a first UE (e.g., a UE-to-UE relay) may be configured with a policy that determines whether it can perform a given type of security procedure (e.g., with network assistance) with the help / assistance of a second UE (e.g., an end UE) when the first UE is outside the coverage area.

[0251] In another embodiment, the end UEs may be located outside the coverage area, while the UE-to-UE relay may be located within the coverage area; the end UEs may request an out-of-coverage-area solution, i.e., a security procedure that does not require network support, in which case the UE-to-UE relay may approve such a solution if it is permitted according to its security policy. Even if the UE-to-UE relay is involved in a security procedure without network support, the UE-to-UE relay may inform the network about the attempt to establish a connection between the source UE and the destination UE so that the network can provide its feedback (e.g., final authorization) on whether the communication is authorized or not (e.g., if the long-term credentials have expired).Based on feedback from the network, the UE-to-UE relay can continue to forward the messages or abort the communication if the network indicates that the connection is unauthorized (e.g., if one of the end UEs is unauthorized or if it chooses an out-of-coverage solution while within the coverage area).

[0252] In another related procedure, the UE-to-UE relay may request / allow the execution of a security procedure without network support, e.g., for performance reasons or when located outside the coverage area, between an end UE (e.g., source UE or destination UE) and a UE-to-UE relay. However, this communication link, established with a security procedure without network support, may be subject to a communication policy tied to a security procedure without network support (e.g., characterized by a given (limited) data rate, a specific frequency range, a (limited) temporal validity (e.g., up to t seconds), a (limited) local validity).

[0253] In another related procedure, the communication policy may include an access control policy, the content of which may be similar to the authorization policy in a PIN system, as described in related variants of procedures / embodiments.

[0254] In another related procedure, the communication link established with a non-network security procedure may be subject to a communication policy tied to a non-network security procedure.

[0255] In another related procedure, a security procedure of 5G ProSe PC5 Communication for 5G ProSe Layer-3 UE-to-UE relay without network support may be as described in paragraph 6.6.3.2 in TS 33.503 (draftCR in TDoc S3-233374).

[0256] In another related procedure, a 5G ProSe PC5 communication security procedure for 5G ProSe Layer-3 UE-to-UE relay with network support may be as described in paragraph 6.6.3.1 in TS 33.503 (draftCR in TDoc S3-233374).

[0257] In another related procedure, the UEs (e.g., UE-to-UE relay) may require (based on policy / configuration) the execution of a security procedure with network assistance or the (re-)establishment of a secure connection with network assistance between an end UE (e.g., source UE or destination UE) and UE-to-UE relay if the end UE (e.g., source UE or destination UE) and the UE-to-UE relay initially established a secure connection without network assistance, e.g., if the UE-to-UE relay was initially outside the coverage area or for performance reasons. When this new secure connection is / needs to be established may depend on the context (e.g., timeout, UE-to-UE relay back within the coverage area) or the policy.

[0258] In a related procedure, the UE-to-UE relay may be deployed / configured with a policy / security parameter to support the execution of security procedures without network assistance when outside the coverage area. However, once inside the coverage area, the UE-to-UE relay may need to provide a list of (active) communication links between end UEs that need to be verified by the network (e.g., whether UEs are authorized to communicate with each other, whether the security context (e.g., key creation materials) needs to be updated). The network can instruct the UE-to-UE relay accordingly how to handle the communication links it has established outside the coverage area. For example, it may terminate the communication link between two end UEs (e.g.,due to a timeout or a change in authorization), trigger a new key generation procedure, trigger a new security procedure, or keep the communication connection unchanged.

[0259] In a related procedure, which can be combined with other procedures (such as the one described in the previous paragraph), the UE-to-UE relay can trigger the execution of a network-assisted security procedure by sending a message (e.g., a security procedure request), which can be protected with the key creation material of the current Sidelink / PC5 communication connection. Upon receipt of the message, the end UE (e.g., source UE) can provide its credentials to the UE-to-UE relay to perform a network-assisted security procedure, e.g., For example, a Direct Communication Request (DCR) including a Relay Service Code and a PrukID as described in the 5G ProSe PC5 Communication Security Procedure for 5G ProSe Layer-3 UE-to-UE Relay with Network Support, as described in paragraph 6.6.3.1 in TS 33.503 (draftCR in TDoc S3-233374), can be made.

[0260] In another embodiment, one or more Network Functions (NFs) in the CN are responsible for monitoring whether security procedures based on a security procedure without network support are still permitted for the UE (e.g., as provided for in the policies / security key creation materials / credentials) or whether these policies / security key creation materials / credentials have expired / revoked, etc. This NF is then responsible for logging and / or stopping the currently running security procedure. This embodiment has the advantage that the network has precise control over which security associations are allowed to be established and which are not, while UEs (end UEs / UE-to-UE relays) can use security procedures without network support, which can provide improved performance (e.g., lower latency).

[0261] In one embodiment, a UE-to-UE relay may send a message to an end UE (e.g., step 2105-A in Fig. 21) to confirm the solution selection, e.g., if there is a mismatch between the solution requested by an end UE and the solution preferred by the UE-to-UE relay, since the requested solution may be supported after policy verification by the UE-to-UE relay. For example, if the source UE is in the coverage area and requests an in-coverage solution, while the UE-to-UE relay is outside the coverage area, the UE-to-UE relay may send a message to agree to / continue with the in-coverage solution if its policy allows, and the source UE could be supported by the network. Similarly, if a source UE outside the coverage area requests an in-coverage-area solution while the UE-to-UE relay is within the coverage area, the UE-to-UE relay either sends a message (e.g., step 2105-C in Fig. 21) about the mismatch or a message (e.g., step 2105-A in Fig. 21) informing the source UE about the approval of the out-of-coverage solution. Similar information can also be sent during the discovery procedure.

[0262] In a variant of the embodiment, in cases where the solutions (ie requested by an end UE and preferred by a UE-to-UE relay) match, e.g., in step 2105-A in Fig. 2 sent message not required.

[0263] In another alternative embodiment or variant, it may be implicitly understood whether the UE-to-UE relay supports the requested solution and approves it despite a mismatch by simply continuing the connection setup procedure based on the requested solution; in this case, step 4-A may not be required.

[0264] A UE-to-UE relay can be provided with a policy that prohibits the establishment of communication links with end UEs without network support, regardless of whether it is located within the coverage area or outside the coverage area. For example, if a UE-to-UE relay attempts to serve and / or establish communication links with end UEs without network support (e.g., an end UE requests an in-coverage area solution), the network may not be able to intervene (e.g., confirm to the end UE whether the UE-to-UE relay is authorized to establish connections when it is located outside the coverage area) because UEs may be outside the coverage area. For such and similar scenarios, where the network cannot assist or guarantee that the communicating parties are legally authorized, UEs (e.g.,End-UEs and / or UE-to-UE relays) must be able to verify whether the other party is authorized to use a solution requested / approved by it, and embodiments that guarantee this may include, but are not limited to, the following.

[0265] In one embodiment, a service code, e.g., the Relay Service Code (RSC) provided by the network may be associated with one of an in-coverage area solution and an out-of-coverage area solution, such that when using it, the UE receiving the request or approval of a solution is assured that the requesting / approving UE is indeed authorized for an out-of-coverage area solution.

[0266] In a further embodiment, if at least one of the UEs (e.g., source, destination, or UE-to-UE relay) is within the coverage area, that UE may send a request, including the UEs' identifiers and the choice of security solution, to the network, which then verifies the connections to be established and provides final authorization therefor.

[0267] In a further embodiment, UEs may be provided with different credentials (e.g., service codes, discovery key creation materials, passwords, cryptographic keys, etc.) associated with in-coverage solutions and / or out-of-coverage solutions, so that the use of these identifiers / keys may implicitly imply that the UEs intend / are authorized to use the requested or approved security solution.

[0268] In another embodiment, a UE, e.g., an end UE, may create a discovery message M protected with the key creation materials associated with a given service code (e.g., a relay service code). The UE may receive these key creation materials / service codes if the UE is authorized to use a given security procedure (e.g., within the coverage area / outside the coverage area). The UE may select these key creation materials / service codes if the application requires a given type of security procedure, e.g., with or without network support. This indicates the UE's preferences. For example, a UE (e.g., an end UE) may send a discovery message to another UE (another end UE) via a UE-to-UE relay.The application-specific fields of a given ProSe service may be protected with key creation materials tied to a service code, so that the UE-to-UE relay or other UEs (not belonging to or associated with the application, e.g., ProSe service) do not have access to them. A ProSe service may prefer / require the use of a given security procedure, e.g., with or without network support. Based on the preferences, a UE may be entitled to receive credentials (e.g., a relay service code / key creation materials) to select a UE-to-UE relay capable of providing support for this given security procedure. These credentials are provided by the core network. The UE can then use these credentials to also protect the discovery message M or to increase the protection before it is sent.This allows an application requiring a given type of security procedure to allow an end UE to select UE-to-UE relays capable of providing the required type of security procedure for the application.

[0269] In a further embodiment, if an end UE indicates a given preference for a given type of solution, e.g., within the coverage area or outside the coverage area, i.e., with or without network support, and the UE-to-UE relay can provide support for such a solution / security method, the UE-to-UE relay does not need to indicate the status of its coverage area, as this is not required / useful for the end UEs, and this is beneficial for saving bandwidth.

[0270] In a further embodiment, the end UEs indicate the status of their coverage area, e.g., in the discovery message, so that even if a UE-to-UE relay is outside the coverage area, the UE-to-UE relay can accept a request to use an in-coverage-area solution, i.e., a network-assisted security procedure, even if the UE-to-UE relay itself is outside the coverage area.

[0271] In a specific procedure based on the proposed embodiments, 5G ProSe end UEs (e.g., source and destination UEs) and a 5G ProSe UE-to-UE relay can negotiate and select a security mechanism with or without network support based on a policy. The negotiation procedure includes the following steps: Step 0: Initial authorization of the UEs and provisioning / configuration with security parameters for different security mechanisms and policies for negotiating / selecting a security mechanism. Step 1: Source UE and UE-to-UE relay perform the discovery phase and indicate the status of their coverage area. Step 2: The source UE creates a DCR message including its chosen security mechanism (e.g., with / without network support) and security parameters based on local policies that depend, for example, on its coverage situation, service preferences, UE-to-UE relay coverage area specification, etc. Step 3: The UE-to-UE relay receives the DCR message from the source UE and determines whether the DCR message contains an explicit indication of the security mechanism and / or parameters that implicitly indicate a preferred security mechanism (e.g., with or without network support). The UE-to-UE relay verifies whether the security mechanism and / or the security parameters fit into its coverage area situation and whether the policy provided in step 0, in addition to the authorization information received in step 2, allows the use of the preferred security mechanism and the security parameters of the source UE. Based on the result of the assessment, the UE-to-UE relay can either proceed with the execution of the requested security mechanism (e.g., with or without network support) or indicate a non-compliance with the policy to the source UE and send another DCR message with the security mechanism it has (i.e.,the UE-to-UE relay) preferred security mechanism and the corresponding parameters.

[0272] The negotiation of the security mechanism is based on the policies provided to the UEs in Step 0, which include, among others: Which of the supported security mechanisms or security parameters are preferred to establish a secure connection with and without network support by the ProSe service.

[0273] Number of attempts allowed to agree on a security mechanism.

[0274] Default prioritization list that determines which UE security mechanism (e.g., source UE, destination UE, and UE-to-UE relay) is prioritized when UEs prefer different solutions. The prioritization list may depend, for example, on the UE's function (e.g., relay) or the status of its coverage area (e.g., inside or outside the coverage area).

[0275] In a given procedure, the selection procedures between security mechanisms with or without network support are as follows: A network support security indicator via Relay Service Code (RSC) is provided to the UEs to indicate whether the network support security procedure should be used. Based on the network support security indicator, the 5G ProSe end UEs and the 5G ProSe UE-to-UE relay select between security procedures with network support and security procedures without network support. If an RSC associated with the enabled network support security indicator is included in the discovery message, the PC5 security procedures with network support are performed between the end UEs and the UE-to-UE relay.Otherwise, if an RSC associated with the disabled network support security indicator is included in the discovery message, the PC5 security procedures are performed without network support between the end UEs and the UE-to-UE relay. - For 5G ProSe UE-to-UE relay communication with Discovery Model A, if the UE-to-UE relay is within the 3GPP coverage area, the UE-to-UE relay must include the RSC associated with the enabled network support security indicator in the Discovery Announcement message, after which the end UEs and the UE-to-UE relay perform the PC5 security procedures with network support after the discovery procedure. If the UE-to-UE relay is outside the 3GPP coverage area, the UE-to-UE relay must include the RSC associated with the disabled network support security indicator in the Discovery Announcement message, after which the end UEs and the UE-to-UE relay perform the PC5 security procedures without network support after the discovery procedure. - In 5G ProSe UE-to-UE relay communication with Discovery Model B, if the source-end UE includes the RSC associated with the enabled network support security indicator in the Discovery Request message and the UE-to-UE relay is within the 3GPP coverage area, the end UEs and the UE-to-UE relay perform the PC5 security procedures with network support after the discovery procedure. Otherwise, if the source-end UE includes the RSC associated with the disabled network support security indicator in the Discovery Request message, the end UEs and the UE-to-UE relay perform the PC5 security procedures without network support after the discovery procedure.

[0276] This procedure does not allow end UEs that do not support PC5 security procedures with network support to discover each other in Discovery Model A when they are in proximity to a UE-to-UE relay that is within the coverage area. This procedure does not describe how a source end UE decides to include an RSC with or without a network support security indicator in Discovery Model B. This procedure does not describe how a source UE can decide to perform a PC5 security procedure with or without network support when the source UE completes two discovery procedures, one with an RSC associated with the enabled network support security indicator and one with an RSC associated with the disabled network support security indicator.

[0277] To resolve these problems, several procedure variants can be applied, which can be combined with each other or used independently: In a procedural variant, the UE-to-UE relay in Model A may send discovery messages with an RSC associated with the enabled network support security indicator and discovery messages with an RSC associated with the disabled network support security indicator when the UE-to-UE relay is within the coverage area. These messages with different RSCs may be sent alternatively or in any order or timing according to the configuration and / or implementation.

[0278] In one procedure variant, the coverage area status of the UE-to-UE relay (e.g., in Model A) is explicitly sent alongside an RSC so that the end UEs can respond with their preferred solution (with or without network assistance) in a subsequent discovery message (e.g., in Model A).

[0279] In a procedure variant, an RSC can be associated with both a disabled network support security indicator and an enabled network support security indicator that is not associated with a network support security indicator, so that a UE receiving the RSC knows that it can choose a PC5 security procedure with or without network support based on its preference. For example, in Discovery Model A, this RSC can be sent when the UE-to-UE relay is within the coverage area and supports the PC5 security procedure with or without network support. This RSC can be sent together with the coverage area status of the transmitting device (e.g., UE-to-UE relay) to allow the receiving device to select an appropriate security procedure.

[0280] In a procedural variant, the end UEs in Model A may be configured with a policy that determines the preferred RSC (associated with the enabled / disabled network support security indicator) to respond to the received RSCs in the discovery messages, so that a single PC5 security procedure (with or without network support) is executed. For example, if an end UE receives two RSCs, one associated with an enabled network support security indicator and one associated with a disabled network support security indicator, the end UE may have a policy that prefers a PC5 security procedure without network support and will only respond to the discovery message with the RSC associated with a disabled network support security indicator.

[0281] In a procedure variant, the end UEs and / or the UE-to-UE relay may be configured with a policy that determines a time window during which the end UEs and / or the UE-to-UE relay consider the RSCs received in discovery messages, which may be associated with an enabled, disabled, or neither / both network support security indicator(s). The end UEs and / or the UE-to-UE relay may react / respond to or discard the received discovery messages based on the end UEs' preferred solutions determined by their policies, thus executing a single PC5 security procedure. Discovery messages received from the same relay after the time window has expired or after the end UE has already agreed to a security solution may be discarded.

[0282] In a procedure variant, if the UE-to-UE relay is within the coverage area (e.g., in Model A) and transmits discovery messages with RSCs associated with the enabled / disabled network support security indicator or both / neither, the end UEs (e.g., source UE and destination UE) may have different preferences for the security solutions. For example, the source UE may prefer a network-assisted security procedure, while the destination UE may prefer a non-network-assisted security procedure. Thus, the policy can determine whether the UE-to-UE relay can support different security solutions for the first hop-by-hop connection and the second hop-by-hop connection. If a single solution is required for both the first and second hop-by-hop connections, the choice of the security solution is determined by the UE-to-UE relay policy, e.g.,based on the UE-to-UE preference or the preference of the terminating UE that first responds to the advertisement message.

[0283] In a procedural variant, the end UE in Model B may be configured with a policy that determines the preferred RSC (associated with the enabled / disabled network support security indicator) to be used.

[0284] In a procedure variant, the terminating UE in Model B may be configured with a policy that determines the PC5 security procedure to be executed (with or without network support) when the source UE completes two discovery procedures, one with an RSC associated with the enabled network support security indicator and one with an RSC associated with the disabled network support security indicator.

[0285] If, in a procedure variant, the negotiation of both security procedures with and without network support is successful, i.e., if in two parallel discovery procedures, RSC(s) associated with an enabled or disabled network support security indicator match, then the end UE and the UE-to-UE relay perform the PC5 security procedure with network support. This requires one of the end UEs, e.g., the source UE, to send a Direct Communication Request (DCR) message including the RSC with network support bound to the PC5 security procedure. If the UE-to-UE relay matched both RSCs in the previous discovery procedures, the UE-to-UE relay may receive the DCR message and process it (according to paragraph 6.3.5 in TS 33.503) with the security materials bound to both RSCs in a predetermined order.For example, the UE-to-UE relay may first use the security materials associated with the RSC bound to the PC5 security procedure with network support to perform security processing of integrity verification and decryption of the DCR message. If this initial security processing / verification fails, the UE-to-UE relay may attempt to perform integrity verification and decryption of the DCR message using the security materials bound to the PC5 security procedure without network support.

[0286] In general, embodiments that require the configuration and use of a policy to determine which solution / protocol to use and which security parameters (e.g., passwords, cryptographic keys) to use have the advantage that they can help prevent a UE capable of using both an in-coverage solution and an out-of-coverage solution from choosing to use the in-coverage solution when within the coverage area. If a UE does this, not only will interoperability be broken, but security vulnerabilities may also arise if the out-of-coverage solution is more relaxed (in terms of security) than the in-coverage solution.

[0287] These signaling and agreement phases can also be performed in an integrated discovery phase, i.e., the discovery messages are integrated into the DCR message. For example, solution #32 in TR 33.740 v0.6.0 describes an integrated discovery procedure that enables the establishment of a communication link between the source UE and the destination UE when the UE-to-UE relay is within the coverage area, i.e., with network support. The initial DCR message sent by the source UE in such a solution / procedure could also indicate the preferred type of security to be used for the subsequent security setup, e.g., a security type that relies on the core network or not. The source UE / UE-to-UE relay / destination UE then uses the preferred security setup based on the indication, context, and preconfigured policies.

[0288] In general, a method and apparatus are described that can be implemented in a device for: Receiving an indication of the SEP (solution / protocol) and / or security parameters to be used from a first device, wherein the SEP (solution / protocol) and / or the security parameters serve to establish a secure connection between a first and a second device,

[0289] Evaluate whether the specified SEP (solution / protocol) and / or security parameters can be used, and Processing the positive or negative evaluation (i.e., sending a subsequent message determined by a positive or negative evaluation of the received indication) to the first or a third device based on the policy evaluation.

[0290] In general, a method and apparatus are described that can be implemented in a device for: Receiving an indication of the SEP (solution / protocol) and / or security parameters to be used from a first device, wherein the SEP (solution / protocol) and / or the security parameters serve to establish a secure connection between a first and a second device,

[0291] Evaluate whether the specified SEP (solution / protocol) and / or security parameters can be used.

[0292] In general, a method and apparatus as described above are used, wherein the indication of the SEP (solution / protocol) and / or security parameters to be used is signaled in a discovery message or in a DCR message.

[0293] In general, a method and apparatus as described above are used, wherein the indication of the SEP (solution / protocol) and / or security parameters to be used is signalled in a discovery message or in a DCR message and is implicit in the use of a specific service, e.g., a (relay) service code.

[0294] In general, a method and apparatus are described that are capable of processing the positive or negative evaluation (ie, sending a subsequent message determined by a positive or negative evaluation of the received indication) for the first or a third device based on the policy evaluation.

[0295] The ability to manage deployment outside the coverage area provides flexibility. Given that UEs are mobile, they are likely to be outside the coverage area from time to time. Even though they are outside the coverage area, it may be convenient for deployment to occur during this time. For example, if user action is required, it may be convenient for the user to complete their actions at a time when the UE happens to be outside the coverage area.

[0296] In a related embodiment (which can be combined with other embodiments or used independently) relating to parameter provisioning and solutions for use within the coverage area and outside the coverage area, it is advantageous if the verification of the type of solution and the parameters to be used takes place before a key setup and authentication phase. In particular, it is advantageous if the verification of the source UE authorization (step 4 in solution no. 4 in TR 33.740) is performed before the direct authentication and key setup procedure (step 3 in solution no. 4 in TR 33.740). This is advantageous because in this case the risk of a denial of service is reduced. This is advantageous because it saves resources (step 3) in case the UE is unauthorized. In the case of solution 4 in TR 33.740, the verification may include verifying the authorization token received in the DCR message in step 2 and / or verifying the environment outside the coverage area.

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

[0298] In general, it is beneficial to require the configuration and use of a policy to determine the solution / protocol and security parameters (e.g., passwords) to be used, since a UE capable of using both an in-coverage solution and an out-of-coverage solution might otherwise choose to use the out-of-coverage solution when within the coverage area. This not only breaks interoperability but may also introduce security vulnerabilities if the out-of-coverage solution is more relaxed (in terms of security) than the in-coverage solution.

[0299] In a related embodiment, which can be combined with other embodiments relating to the parameters exchanged prior to PAKE execution, several parameters must be exchanged prior to PAKE execution in steps 3, 6, and 9. These parameters may include the Relay Service Code (RSC) or a "password hint" to identify the "raw password." If no explicit password hint is present, the RSC serves as the password hint, i.e., the password is linked to the RSC. In particular, and with reference to Fig. 17b, the DCR message in step 1721 includes the RSC and password hints for the PAKEs in steps 1726 and 1729; the DCR message in step 1722 includes the RSC and password hints for the PAKEs in steps 1723 and 1729. When the UE-to-UE relay receives the message from step 1721, the UE-to-UE relay may remove the password hint for the PAKE in step 1726. Furthermore, the UE-to-UE relay adds its password hint for the PAKE to the DCR message in step 1722. When the target UE receives the message in step 1722, the target UE starts the PAKE in step 1723 based on the received password hint.

[0300] In a related embodiment, which can be combined with other embodiments related to PAKE execution, this embodiment illustrates how a PAKE can be executed in the context of SPAKE2 and SPAKE2+, which involve the exchange of four messages. The first and second PAKE messages are exchanged in a Direct Auth and Key Establish Request and a Direct Auth and Key Establish Response message, respectively, according to TS 33.536. The third and fourth messages are exchanged in Direct Security Mode Command and Direct Security Mode Complete, respectively, as per TS 33.536.

[0301] In a related embodiment, the term long-term credentials, as specified in paragraph 5.3.3.1.2.1 in TS 33.536, may also refer to passwords as used in a PAKE.

[0302] In a related embodiment, which can be combined with other embodiments related to secure data exchange, secure data exchange relies on a shared key Ks between two UEs resulting from the PAKE. This key Ks is K_shared as defined in SPAKE2 or TT as defined in SPAKE2+. In an L2 UE-to-UE relay, Ks is used as a shared secret to derive PC5 keys for user / control planes and encryption / integrity using a key derivation function according to TS 33.220. In an L3 UE-to-UE relay, Ks is used to derive a PSK hint and a PSK. PSK and PSK hint are used in IKE-PSK to secure L3 communication using a key derivation function according to TS 33.220.

[0303] In general, a method and apparatus are described that can be implemented in a device for performing a second PAKE-based SEP between a first and a third device via the relay device. Furthermore, a method and apparatus related to the above method and apparatus are described for performing a first PAKE-based SEP between a first and a relay device and, upon success, authorizing the execution of the second PAKE-based SEP. PERSONAL IoT NETWORKS

[0304] Fig. 16 schematically shows a signaling and processing diagram for personal IoT network (PIN) scenarios according to one embodiment. In the scenario of Fig. 16, a PINE source device (PINE-S), a PEGC and / or PEMC, and a PINE target device (PINE-T) are involved. These devices may be part of a PIN. For example, the PINE source device may be a virtual reality (VR) device (e.g., a headset) that simulates vision to obtain a 3D environment in which the user appears to be immersed while browsing or experiencing it, the PINE target device may be a smart TV, and the PEGC / PEMC may be a mobile phone (UE). The three devices may require connectivity / services from a core network (CN) via a radio access network (RAN). These three devices may further require means for securely communicating with each other. For this purpose, the devices may be initially configured in steps 1601, 1602, and 1603 (as described above in connection with steps 1501 to 1503).The PINE source or destination devices may not be configured directly by the CN, as they may not be 3GPP RAN-capable; instead, they may be configured by an Application Function (AF) via the CN or by the CN if the device is a 3GPP RAN-capable device. The configuration may refer to security keying materials (e.g., PAKE-related, PC5 discovery keying materials according to TS 33.503) or other embodiments described herein, or communication parameters (such as QoS, required communication resources, and maximum latency).

[0305] In step 1604, the PINE source device and the PEGC and / or PEMC may establish an underlying communication channel, e.g., a Wi-Fi channel. The PINE source device may then be triggered to enter a password, e.g., using a keyboard or by scanning a QR code (step 1605). This password may be generated by the PEGC and / or PEMC and displayed on the screen. The password may also be derived from a master secret of the PEGC and / or PEMC using a KDF, e.g., the master secret of the UE used for primary authentication. The PINE source device and the PEGC / PEMC are then able to exchange a preamble / PAKE message / SEP in steps 1606 and 1607, as in the previous embodiments, thereby establishing a secure and authenticated channel. The PEGC / PEMC may then allow the PINE source device to use the 5GC communication resources in step 1608.This step may involve an authentication procedure with an AAA server, e.g., in the application function (AF), which would inform the PEGC / PEMC of the result.

[0306] In an additional variant, the PINE source device and the PEGC and / or PEMC may establish an underlying communication channel, e.g., a Wi-Fi channel, in step 1604. Subsequently, the PEGC / PEMC may be triggered to enter a password, e.g., using a keyboard or by scanning a QR code, e.g., attached to the PINE source device. This password may have been provided by the CN or a third party on PINE. The source PINE device and the PEGC / PEMC are then able to exchange a preamble / PAKE / SEP message in steps 1606 and 1607, as in the previous embodiments, resulting in a secure and authenticated channel and enabling initial access to the CN or an AF utilizing the CN 1608.Additionally, and prior to this step 1608, after successfully establishing a secure and authenticated channel in 1607, the PEGC / PEMC may securely receive further 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 may be verified by the PEGC / PEMC or forwarded for verification by the CN or AF. In this first case, the PEGC / PEMC may grant the PINE source device access to the CN or an AF utilizing the CN. In this second case, where the CN or AF performs the verification, the CN or AF would send an acknowledgment message to the PEGC / PEMC to allow / deny traffic from the PINE source device. Access to this AF utilizing the CN may be provided via a Network Exposure Function (NEF).Note that step 1608 may enable access to the AF through some specific network resources, e.g., specific to the target AF. For example, a task of the AF may be to create a personal IoT network in which all devices are reachable. Thus, a PINE source device that succeeds in steps 1606, 1607, and 1608 may be assigned connectivity resources (e.g., IP address, communication resources ensuring a certain reliability / latency) that meet the needs of the AF. The resources assigned to a PINE after successful authentication / authorization in step 1608 may depend on: a policy configured based on the user subscription in step 1602, and / or the communication requirements for the PINE, which can be configured in the PEGC / PEMC in step 1608 and / or the amount of available resources taking into account other PINE devices connected to the PEGC / PEMC.

[0307] Note that the initial configuration in steps 1601, 1602, and 1603 may be performed by an external AF via the CN or by the CN. This initial configuration may include the distribution of SEP / PAKE-related information, e.g., in an extended PAKE or information enabling the verification of subsequent credentials (e.g., a digital certificate) received from the PINE source device upon establishment of a secure channel (e.g., via a SEP or PAKE-based SEP). This initial configuration may also include the communication policy for a PINE or the communication policy for the PEGC.

[0308] In step 1609, a password / credentials may be entered / provided / used in the PINE source device, and in step 1610, preamble messages may be sent as described in the Fig. 3 or Fig. 14 and the preceding embodiments (equivalent to discovery messages) may be exchanged via the PEGC and / or PEMC with another PINE target device. The PEGC / PEMC may only allow traffic originating from PINE that has already been authenticated / authorized in a preceding step. In step 1611, the same password may be made available to this device. Based on the (preamble) messages in step 1610 and the shared password, both the source and target PINE devices may perform a PAKE in step 1612 as in the preceding embodiments, thereby establishing a secure communication channel between the PINE devices in step 1613.

[0309] In Fig. 16, the CN can include multiple network functions, including, for example, AMF, SMF, or UPF. The UPF can interact with a PIN-related AF located inside or outside the CN. The configuration parameters can be provided / configured, for example, by PCF, UDM, or UDR.

[0310] In an additional (sub)embodiment, an AF, inside or outside the 5G system, can be responsible for managing the PIN. This AF and the PEGC / PEMC establish a secure channel via Authorization and Key Management for Applications (AKMA) (see TS 33.535). Once the PEGC / PEMC is authenticated based on the AKMA-derived keys, the AF can provide 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 an AKMA-derived AF key, the AKMA NF checks with UDM / UDR, directly or indirectly via the AUSF, whether the PEGC / PEMC user is authorized to set a PIN, as well as, for example, subscription data, subscription authentication, PDU session information, and QoS requirements.

[0311] In an additional variant, a PINE device, e.g., a PINE aiming device as in Fig. 16, a cellular interface, and thus, it is feasible to configure this device via a cellular interface, e.g., the Uu interface or the PC5 interface, e.g., in step 1601. The initial configuration includes configuration parameters for setting up the PC5 interface, e.g., discovery security material as described in TS 33.503. This initial configuration also includes PIN configuration information. This information may, for example, be provided by the AF once the PINE (e.g., the PINE target) has established a secure connection with the 5G CN (e.g., after primary authentication) using AKMA-derived keys, which may enable the performance of an authentication / authorization procedure between the PINE and the AF. This initial secure PIN configuration may be performed via the Uu or PC5 interfaces.This initial PIN configuration can be performed before the PINE device has attempted to join a PIN. If the PIN configuration is successful, the PEGC / M is also instructed / configured to forward communication between PINEs. For example, steps 1610, 1612, and 1613 may need to be routed through the PEGC / PEMC. The communication link between the PINE source and PEGC / PEMC may be based on a first communication protocol (e.g., WiFi) and the communication link between the PINE destination and PEGC / PEMC may be 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 can be configured by the 5GC with a configuration policy that determines that certain PC5 traffic (e.g.,for MAC or PDU sessions or IP layers) to another network interface, such as a WiFi, BLE, or IEEE 802.15.4 network interface.

[0312] In a further variant, a PINE device, e.g., the PINE target in Fig. 16, support a cellular interface. Such a PINE device can use unregulated spectrum and therefore does not always have to rely on resource allocation by the RAN.

[0313] In an additional variant, a PINE device, e.g., the PINE target in Fig. 16, establish a secure channel with the PEGC / PEMC using a SEP, e.g., a PAKE-based SEP at the application layer, where the PAKE-based SEP messages can be transported, e.g., in a metadata field of PC5 discovery messages or in another PC5 message.

[0314] In an additional variant, step 1608 may include a (mutual) authentication procedure between PINE and AF / 5GC.

[0315] In a related variant, the PIN AF can play the role of an AAA server or include functionalities of an AAA server.

[0316] In a related variant, the following may occur.

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

[0318] In Phase 2, if this initial (primary) authentication is successful, the UE can request communication with a specific PIN AF; or the CN (e.g., AUSF) can verify the subscriber's preferences, e.g., regarding PIN management. In this case, the CN can authorize the UE, and the UE and PIN AF can establish secure communication, e.g., using a K_AF derived from K_AKMA, as described in TS 33.535.

[0319] In phase 3, the UE and the PIN AF can then perform an authentication / authorization procedure based on K_AF or a key derived from it using a Ua* protocol. Additionally or alternatively, the procedure can also be another high-level application protocol that uses some credentials specific to the PIN;

[0320] In Phase 4, e.g., if authentication / authorization in Phase 3 is successful, the AF can inform the CN (e.g., AUSF or AUSF via AaNF or other NF) about the UE's status and provide some configuration parameters related, for example, to the PIN communication, membership, etc. requirements that the UE must use in its role as a PEGC / PEMC. The CN (e.g., AUSF) can store this information in a database, e.g., in UDM (UDR). The CN (e.g., AUSF) can compare this received configuration with the user's subscription and verify that it complies with it. The billing information can also be updated based on the UE's new status (active PEGC / PEMC).

[0321] In Phase 5, the CN (e.g., AUSF to AMF) may inform the UE of its confirmed role as PEGM or PEMC (e.g., with a NAS message). The CN may also inform the UE of specific PIN configuration information, e.g., how it is shared by the PIN AF and / or verified against the user subscription. The CN may also configure the UE with a policy and configuration parameters to forward PIN-related data (e.g., data originating from a PINE) to the AF via predefined network resources. The CN may also configure the UE with a policy that determines how / if data should be forwarded or which data should be forwarded, e.g., to / from cellular PINE devices from / to non-cellular PINE devices within the PIN. Additionally or alternatively, some of the above information may also be sent by the AF.The UE configuration / policy that determines whether data is forwarded from PINE devices implies that this configuration can be used to authorize the communication of a PINE device.

[0322] In Phase 6, the AF can also configure the PEGM / PEMC with other configurations, e.g., regarding PIN parameters.

[0323] Some of phases 1-6 may, for example, in step 1602 in Fig. 16. They are similar to a security procedure by which a UE can become a PEGC / PEMC of a PIN.

[0324] In Phase 7, when the UE is requested to add a PINE to the PIN or a PINE requests access to the UE PIN, the UE can: (a) establish a secure channel between the UE and PINE, e.g. using a SEP, e.g. a PAKE-based SEP or a protocol based on PINE's wireless communication technology. b) Grant access to the AF based on the configuration obtained in Phase 5 or 6 or other parameters. This access may be time-limited until the CN or AF confirms the successful authentication procedure between PINE and AF. This access may be based on specific communication resources that can be monitored by the CN to ensure PIN subscription compliance.

[0325] Phase 7 can be assigned to steps 1604-1607 in Fig. 16 correspond.

[0326] In phase 8, an authentication and authorization procedure can be performed between PINE and AF. This procedure can take place at the application layer, i.e., outside of any 3GPP specification. It could also be based on secondary authentication. Optionally, additionally, or alternatively, the UE can derive a PINE key (K_PINE), e.g., from K_AF, using a KDF with such a key and, e.g., an identifier provided / scanned by the PINE. The UE can securely share this identifier with the AF, which can derive the same K_PINE since they share K_AF. The UE could also share K_PINE with the PINE. The authentication and authorization procedure could also be based on K_PINE.

[0327] In phase 9, if the authentication / authorization between PINE and AF is successful in step (8), AF informs CN (e.g., AUSF) about the new PINE, the successful authentication status, and the PINE requirements. AUSF adds information about PINE to UDM (UDR). The billing information may also be updated due to the new PIN status (new PINE). The CN can then inform the UE about the successful authentication of the PINE and any configuration information provided by the AF. The CN can also provide the PEGC / PEMC—via a NAS message—with a communication policy to forward data originating from the PINE using specific communication resources or a specific identifier. Additionally or alternatively, the AF can provide the above information to the UE (e.g., via a secure channel protected with K_AF (or a key derived from it)).The UE then informs the CN, e.g., by sending a NAS message to the AMF and then to the AUSF.

[0328] In phase 10, the UE may receive or have received an identifier (scanning a QR code, entering an ID, etc.) from the PINE for identification purposes. This identifier may also have been securely shared with the AF, e.g., in step 8. This identifier, or an identifier derived from it, e.g., using a KDF, may be shared with the CN to identify the PINE.

[0329] In phase 11, a PINE key (K_PINE) related to the UE can be derived, e.g.: • from K_AUSF, including an identifier as input to KDF. • from the current K_AF, including an identifier as input to KDF. • provided by the AF

[0330] The AF can send the PINE key to the PINE securely (application layer), based on a secure connection established, e.g., in step (8) after authentication / authorization. Additionally or alternatively, the UE can share it. Additionally or alternatively, the CN and UE can also generate K_PINE if it is derived from K_AUSF or K_AF.

[0331] This PINE key can also be considered an "access token," which allows the PINE to communicate with the AF or another PINE in the PIN via the PEGC / PEMC. This "access token" ensures that only an authorized PINE can use the PEGC / PEMC after authentication and / or authorization. This PINE key, which acts as an authorization token, could be managed by the CN or the AF and shared by both the PINE and the PEGC to allow 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, as MAC addresses can be easily spoofed.

[0332] In phase 12, K_PINE can allow actions such as the following: • the CN / UE should send certain commands to the PINE. • The PINE should establish a secure channel with the UE / CN so that the PINE can exchange messages securely with the PEGC / PEMC. • the PINE should send certain messages to CN in a secure manner. • The PEGC / PEMC shall send messages to the PINE that are either generated locally at the PEGC / PEMC or forwarded by another PINE or the AF.

[0333] For example, • Each time a PINE sends a message to the AF via the PEGC, the PINE can attach a token based on K_PINE. • This token could, for example, be a MIC based on K_PINE if K_PINE is a symmetric key, where the MIC can be computed over the message or over a parameter that allows checking message freshness (e.g., a UTC-based counter). • For example, this token could be an authorization token that is verified by the PEGC / PEMC each time the PINE sends a message to the PEGC / PEMC and / or the AF and / or another PINE. • For example, this K_PINE could be used to (mutually) authenticate an IKEv2-IKE-based tunnel setup between PINE and PEGC / PEMC, so that all exchanged traffic is protected. • The PIN management entity (e.g., an NF in 5GS or an AF) could be responsible for managing, generating, distributing, etc., the tokens, e.g., the authorization tokens. The PIN management entity could be responsible for providing key generation materials (e.g., a symmetric key or a private key) to the PINEs and / or the PEGC / PEMC so that they can verify the tokens.

[0334] Some of phases 8-12 may be performed in step 1608 in Fig. 16. They are similar to a PINE authentication and authorization process.

[0335] Fig. Figure 20 provides a schematic view of the above phases, where: • in Phase 1, primary authentication can be performed between UE (PEGC / PEMC) and CN; • In Phase 2, the UE (or an application on it) may request PIN access to the CN or to an AF via the CN. This can be done via AKMA (TS 33.535) and AnAF. In this case, K_AKMA is used to derive a K_AF for the specific UE and PIN. Alternatively, another PIN-specific anchor function may be used, e.g., an Anchor PIN Function (AnPF) responsible for PIN Key and Device Management (PKaDMA), e.g., managing a K_PKMA. For example, K_PKMA may play a similar role to K_AKMA, but is specific to the PINs a UE is a member of / responsible for. K_PKMA could be derived in a similar way to K_AKMA, i.e., from K_AUSF, but using other parameters as input parameters in the KDF, such as a bit string identifying PKaDMA. K_PIN can be derived from K_PKMA, similar to K_AF, e.g.using an identifier that identifies the PIN as input. This allows more than a single PIN to be supported. It would be feasible to derive K_PIN or K_PKMA K_PINE, as explained above, a key specific to a given PIN. It is advantageous to have another NF, AnPF, because its PIN range differs from that of the AnAF, allowing the entire PIN functionality to be placed in an isolated NF. • In Phase 3, the UE and AF can perform an authentication and authorization step. This step can be based on the keys distributed in Phase 2. • In phase 4a, the AF can inform the CN about the result of phase 3 and provide a configuration to the CN. This configuration could include information about: PIN identifier, PIN purpose, PIN elements, PIN element capabilities, communication requirements such as QoS, permitted interactions between PINs, etc. In phase 4b, the CN can store the configuration, e.g., in the UDR or the AnPF. • In Phase 5a, the CN may inform the UE of the outcome of Phase 4 and may provide the UE with a configuration. This configuration may be based on the configuration exchange in Phase 4 and may include related elements. This configuration may include rules to enable an authentication and authorization procedure (as in Phase 8) for a PINE (e.g., as required in Phase 7c). This configuration may include an "authorization token" for specific PINEs, as described above. In Phase 5b, the UE may store the configuration. This configuration received from the CN refers to communication parameters associated with the PIN. • In Phase 6, the AF may inform the UE about the outcome of Phase 4 and provide the UE with a configuration, e.g., key creation materials such as certificates, passwords, etc. This configuration received by the AF may relate to application-related aspects that have been associated with the PIN by the AF. • In Phase 7a, the PINE and PEGC / PEMC can establish a secure communication channel. In Phase 7b, the PINE can send a PIN access request to the PEGC / PEMC. In Phase 7c, the PEGC / PEMC can (temporarily) grant access (to the PINE), e.g., based on information received in Phase 5a, to perform Phase 8.

[0336] Phase 7a could be based on a SEP as in the previous embodiments, e.g., a PAKE or another protocol such as the Device Provisioning Protocol (DPP) or Wi-Fi Easy Connect™. The advantage of using a PAKE or DPP is that the communication links are individually protected. • In phase 8, PINE and AF can perform an authentication and authorization step. • In phase 9a, the AF can inform the CN of the result of phase 8 and provide the CN with a configuration related to the PINE. In phase 9b, the CN can save the configuration. In phase 9c, the CN can inform the PEGC / PEMC of the result of phase 8 and provide the PEGC / PEMC with a configuration for the PINE. In phase 9d, the PEGC / PEMC can save the configuration. This configuration received from the CN can refer to communication parameters associated with the PINE. • In phase 10, PINE and PEGC / PEMC can receive an authorization token from the CN. The PINE can receive it via the AF. The purpose of this authorization token is to ensure that only authenticated / authorized PINEs can communicate with / via the PEGC / PEMC. • In Phase 11, data can be exchanged between PINE / PEGC / PEMC that has been authenticated and / or authorized with the authentication token.

[0337] In relation to Fig. 20, phases 1-6 may correspond to the PEGC / PEMC authentication and / or authorization procedure. Phases 7-11 may correspond to the PINE authentication and / or authorization procedure. These procedures can be used together, but they can also be implemented independently.

[0338] The "PIN Access Request" message in Phase 7b is a message that a PINE can send via various lower layers (such as Wi-Fi and PC5) to a UE serving as a PEGC / PEMC. Receipt of this message notifies the UE of the request to join the PIN. This message could be the initial message of Phase 8 (PINE Authentication and Authorization). This message may advantageously include an identifier of the target PIN, e.g., an identifier related to the PIN.

[0339] The PINE may send the PIN access request upon receiving a PIN announcement message. This is a message sent / transmitted by the UE announcing its PIN capabilities. This message may also include additional information that allows a PINE to determine if it is the correct PIN to join. This message could include an identifier of the PINE so that the PINE knows that the UE is attempting to connect to it. The PINE may send the PIN access request during certain out-of-band interactions, such as scanning a QR code displayed by a UE.

[0340] In a variation of this step, since a PIN element can connect to the PEMC and PEGC via the local interface (PC5, Wi-Fi or Bluetooth, etc.) and eventually be authorized by the PEMC to join the PIN, the PEMC / PEGC may require a policy or configuration that determines / specifies one or more of the following: - the types of devices that are allowed to join the PIN, - the types of interactions (authentication with AF, PINE-AF communication, PINE-to-PINE communication, etc.) between the authorized devices (e.g., 3GPP and non-3GPP devices), - the conditions (time, position, context, etc.) under which an interaction / communication is authorized, - the type of permissible lower layers that a PINE can use in a PIN, - the devices that are allowed to join the PIN, - the type of authentication procedures, e.g. based on 1) scope (local, end-to-end, etc.), 2) type (e.g. matter-based, DPP-based, etc.) to support PINE authorization, - Credentials to verify an authorized PINE,

[0341] This policy can be configured by, among other things: - an AF or - a NF in 5GS or - locally in the PEGC / PEMC (e.g. via a user interface).

[0342] In a variation of this step, the PEGC / PEMC could adjust a PINE's access decisions based on configuration or policy.

[0343] In a variation of this step, this guideline can be applied to step 3 of solution 8 in TR 33.882 v 0.4.0.

[0344] Phase 8 is an authentication and authorization step. This can be based on an application layer protocol, secondary authentication, or it can also be based on a peer, pass-through authenticator, and back-end authentication server architecture, using the EAP protocol similar to section 6.1.1.2 in TS 33.501. The peer is the PINE, the authenticator may be the UE (on behalf of the 5GS), and the authentication server is the AF. The peer sends EAP messages using the (wireless) communication technology between the PINE and UE, e.g., EAP over LAN or EAPOL. The UE, acting as the authenticator, then exchanges EAP frames (e.g., directly or encapsulated in a protocol such as "Diameter") with the authentication server, i.e., the AF.

[0345] Fig. Figure 19 schematically provides another view of the elements in a personal IoT network (PIN), similar to Fig. 16. The elements in Fig. 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. The device 1903 is a cellular device capable of managing the PIN, i.e., the PEMC. The device 1904 is a cellular device capable of acting as a gateway of the PIN, i.e., the PEGC. Device 1905 is a cellular PINE device that is part of the PIN. Device 1906 is a communication link between devices 1903 and 1904 The device 1907 is a cellular access device, e.g., a gNB. The device 1908 is the AMF in the CN. The device 1909 is the AUSF in the CN. The device 1910 is a NF in the CN such as UDM, UDR, AKMA, UPF, PCF, NEF, AF, etc. in the CN. Element 1911 is CN. Element 1912 is an AF that is responsible for managing the PIN. The 1913 network is the PIN that includes 1902, 1905 and 1920. The 1914 connection is a non-cellular communication link between 1920 and 1902. The 1915 connection is a cellular communication link (e.g. PC5) between 1905 and 1920. The connection 1916 is a cellular communication connection (e.g. Uu) between 1920 and 1907. The connection 1917 is a communication connection as an interface between 1907 and 1911 or a network function in it. The 1918 connection is a communication link between 1911 and 1912. The 1919 network is a non-cellular network. The device 1920 is a device that includes the functionalities of 1905 and 1906. Device 1921 is a non-cellular device that manages or provides access to the non-cellular network.

[0346] In Fig. 19 shows that device 1920 is part of 1919; for example, it has joined this network and has access credentials, such as a security key. Since device 1920 is part of network 1919, device 1920 can also communicate with device 1902 (also part of network 1919) via connection 1914. Device 1902 has also joined network 1913, where device 1920 has managed the authentication / authorization procedure on behalf of elements 1911 or 1912 to gain access to networks 1913 and connections 1916 or 1915. When device 1902 needs to communicate with device 1905 or vice versa, the communication is routed via device 1920, where device 1920 receives a policy from element 1911 or 1912 that determines which communication flows may be redirected. Fig. 19, device 1921 manages network 1919, and device 1920 is a part of network 1919. This implies that device 1920 also joins network 1919 first. Alternatively, device 1920 may also include the functions of device 1921. In this case, device 1921 regulates which devices join network 1919 first and which of these devices then join network 1913. When a new device is added to network 1913 by device 1920, device 1920 may inform other devices about the newly joined device.

[0347] In general, there is a method and means that can be implemented in a device that enables one or more of the following actions: • Receiving a configuration for a first device (e.g., PEGC / PEMC or cellular PINE) from an AF executing on a third communication device; • Performing a SEP (e.g., DPP, PAKE-based) between the first device and a second device (e.g., non-cellular PINE) that enables the initial establishment of a secure and authenticated channel with the second device over a first communication link, e.g., Wi-Fi; • Forwarding further authentication messages by a first device between the second device and the NF / AF on the third communication device, wherein the communication between the first device and the third device occurs via a second cellular backhaul communication link; • Receiving an authorization confirmation and / or authorization configuration at the first device from the third device that determines the access rights of the second communication device to at least one of the following: ◯ Access to the network of the first device; ◯ Access to the second cellular backhaul communication link (e.g. Uu interface); ◯ Communicate with a fourth device (e.g. cellular PINE) connected to the first device via a cellular communication link (e.g. Sidelink / PC5).

[0348] In at least some of the above embodiments, the PAKE may be SPAKE2+ or another PAKE that is either balanced or enhanced.

[0349] In at least some of the above embodiments, the password may be a shared symmetric key.

[0350] In at least some of the above embodiments, the password (PWD) may consist of a concatenation of (short) shared symmetric keys and metadata that determines the validity of the password and the communication connection, e.g., how long it is valid and what access rights it contains. For example: PWD=K|Metadata, where the metadata may include an access policy or access roles. Note that this approach can also be used with other PAKE schemes. In some cases, it may be necessary to apply a function to the input K | metadata, such as the PBKDF or another function.

[0351] In some embodiments, the "metadata" value may be the root of a Merkle tree computed from a set of leaves, where each leaf includes some information about the device. This allows the device to expose only a portion of its data in its leaves. The device may not exchange the data until the secure connection is established.

[0352] This proposed technique has advantages over alternative techniques that can be used for authentication and authorization. For example: • When using a conventional access token, the initiator and responder can 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 a mutual secret without transmitting it over the Internet). Then, the initiator can send an access token to the responder. The access token can contain information about the initiator's access rights and can be signed by an issuing party trusted by the responder. This scheme may require digital signatures and may still be vulnerable to man-in-the-middle (MitM) attacks. In contrast, the proposed scheme is resistant to MitM attacks and does not require digital signatures. • When the initiator and responder rely on PWD = K | metadata to perform mutual symmetric key authentication and the key agreement protocol. This can reveal which passwords are associated with which devices and thus their identities. Furthermore, if a third device is associated with the same password as the initiator and responder, that third device can gain access to the communication link between the initiator and responder.

[0353] In some of the above embodiments, one of the messages in the preamble or with the PAKE may include a password hint indicating to the receiving party which password or password-based information (e.g., with reference to an extended PAKE, e.g., with SPAKE2+, this password-based information refers to the verification value pair L and w0) to use. In this case, if a password has been configured, e.g., by a central authority such as the 5G CN, or if the user is unsure of which password to use, or if the user is unsure of which QR code (containing the password) to scan, then the device may use the password hint to indicate this so that the other party knows which password to retrieve and use to authenticate the other party after executing the PAKE.Successful authentication may require verification of the password and metadata. The password hint can be obtained, for example, as a function, e.g., a KDF or a hash, of the password and additional parameters such as a salt, a nonce, a counter, etc., as follows: PWD_Note=KDF(PWD|additional parameters) PWD_Note=Hash(PWD|additional parameters) PWD_Note=HMAC(PWD|additional parameters), or the password hint can be a randomly generated bit sequence associated with the password.

[0354] In at least some of the aforementioned embodiments, the password may comprise at least two passwords. A first password provided by a central management entity to both communicating parties and authorizing the establishment of the communication channel, and a second password entered by the user and allowing the user to authorize the establishment of the secure communication channel. PWD=PWD1|PWD2

[0355] In some of the aforementioned embodiments, two PAKEs can be executed in parallel: a first password PWD1 used in a balanced PAKE, where the password can be determined, for example, by the users involved, and a second password PAWD2 used in an extended PAKE, where the password can be determined by the network / system management. The parallel execution of the PAKEs means that the PAKE messages can be sent simultaneously, reducing the number of round trips. For similar PAKEs, steps or operations can be combined. This has the advantage that users can enter their own password to authorize communication, while the network / system can distribute a password to the devices involved in an initial configuration phase, e.g., to authorize the communication link, e.g., a first device (e.g.,Initiator) to communicate with a second device (the responder).

[0356] At least in some of the aforementioned embodiments, a central management party, e.g., the 5GS, may support the authorization of the UE as a UE-to-UE relay in a UE-to-UE relay scenario.

[0357] At least in some of the aforementioned embodiments, a central management party, e.g., the 5GS, may support the authorization of the UE as a source UE or destination UE in the UE-to-UE relay scenario.

[0358] The fact that a PAKE can be extended is a useful feature because if the responder or verifier is compromised, an attacker can at best conduct an offline attack to impersonate the initiator or client. This allows the central managing party to use a password PWD as above, i.e., K | metadata that can be used by the client to show its authenticity and authorization, e.g., to show that it is authorized to act as a source UE for the target UE. A central managing party can, for example, create two types of passwords / keys: K_S and K_T. K_S can be provided to UEs that can only act as a source, K_T can be provided to UEs that can only act as a target. The counterpart of these passwords / keys can be provided to the other party, e.g.A target device that can only act as a target can be provided with a function of a bit string derived from K_S (and metadata) that is difficult to invert (for security purposes). Note that when using a balanced PAKE, a central managing party may also be able to assign a password / key to a pair of devices that authorizes them to communicate with each other.

[0359] In some of the above embodiments, one of the devices, e.g., the responder device, may also retrieve or request the password (or the password-based value in an extended PAKE) from such a central authority, e.g., upon receiving a preamble message containing a password hint. To do this, the device may need to share certain parameters with the central authority, e.g., a password hint or exchanged parameters to be used in the PBKDF. In the case of a password-based value in an extended PAKE, this has the advantage that the responder device can perform the subsequent key exchange, e.g., PAKE, with the initiator device on behalf of the central authority without having access to the password. Since the password-based value may depend on exchanged parameters used in the PBKDF, this value has only a limited validity.Only if the procedure is successful can the responder allow the initiator to perform certain actions, such as gaining access to network resources, the 5G core network, or an application function accessible via the 5G system.

[0360] In some of the above embodiments, an exchanged parameter to be used in a key derivation function may be (the least significant bits) of a UTC-based counter.

[0361] In summary, methods and apparatus for establishing a secure communication channel with an improved key exchange for a SEP have been described.

[0362] Although the invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are to be considered as illustrative or exemplary and not restrictive. It should be understood that embodiments may be combined and that features of one embodiment may be used in combination with another embodiment. The invention is not limited to the disclosed embodiments. The proposed extensions for SEPs (such as SPAKE2+ or SPAKE or PAKEs in general) can be implemented in all types of wired or wireless networks, e.g., they can be applied to devices or applications that communicate using cellular wireless communication standards, in particular using the 3rd Generation Partnership Project (3GPP) 5G and New Radio (NR) specifications.The communication devices or applications can be different types of devices, e.g., mobile phones, smartwatches, smart tags for location tracking and logistics, commissioning devices, applications or tools, vehicles (for vehicle-to-vehicle (V2V) or the 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 use in hospitals or first responders, virtual reality (VR) headsets, etc., and can be deployed, e.g., in personal IoT networks (PIN) and / or ProSe with a focus on UE-to-UE.

[0363] Furthermore, the proposed extensions for SPAKE2+ or PAKEs in general or other SEPs can be used in applications such as Wi-Fi, cloud access, browser synchronization, e-passports, the Thread network protocol for IoT devices, PAKE standards developed by standards development organizations (SDOs) such as IEEE, ISO / IEC or IETF, IEEE 802.11s protocols and WiFi Protected Access (e.g., WPA3 in conjunction with Simultaneous Authentication of Equals (SAE)), protocols for transport layer security (e.g., TLS 1.3) or Internet key exchange (e.g., IKEv2).

[0364] Although ProSe relay and sidelink communication have been mentioned, the present invention can also be applied to other types of relay devices, e.g., proximity services involving direct communication between two UEs, e.g., proximity services involving a UE-to-network relay, ranging services, e.g., (intelligent) repeater devices, IAB (Integrated Access and Backhaul) nodes, or Wi-Fi mesh APs. Furthermore, the techniques mentioned here can also be applied to other procedures, e.g., to solve the main problems for ranging procedures identified in TR 33.893 v0.2.0.

[0365] Furthermore, the invention can be applied in medical applications or connected healthcare involving multiple wirelessly (e.g., 4G / 5G) connected sensor or actuator nodes, in medical applications or connected healthcare where a wirelessly (e.g., 4G / 5G) connected device occasionally consumes or generates a continuous data stream at a certain average data rate, e.g., video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, audio or voice or video streaming devices used by medical personnel, and in general, IoT applications involving wireless, mobile, or stationary sensor or actuator nodes (e.g., smart city, logistics, agriculture, etc.).), in emergency services and critical communication applications, in V2X systems, in systems for improved coverage for 5G mobile networks using high-frequency (e.g. mmWave) radio frequencies, and in all other 5G communication application areas where relaying is used.

[0366] Further variations of the disclosed embodiments may be inferred and effected by those skilled in the art 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 indefinite article "a" or "an" does not exclude a plurality. The foregoing description describes certain embodiments of the invention in detail. It will be apparent, however, that regardless of how detailed the foregoing appears in the text, the invention may be practiced in many ways and is therefore not limited to the disclosed embodiments.It should be noted that the use of particular terminology in describing certain features or aspects of the invention should not be construed as redefining the terminology herein to be limited to specific characteristics of the features or aspects of the invention associated with that terminology.

[0367] Furthermore, where a convention is used analogously to “at least one of A, B, and C, etc.”, such a construction is generally meant in the sense in which those skilled in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. Where a convention is used analogously to “at least one of A, B, or C, etc.”, such a construction is generally meant in the sense in which those skilled in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.Those skilled in the art will further understand that virtually any disjunctive word and / or disjunctive phrase representing two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of including either of the terms, either of the terms, or both of the terms. For example, the phrase "A or B" should be understood to include the possibilities "A" or "B" or "A and B."

[0368] A single unit or device can perform the functions of several elements recited in the claims. The mere fact that certain dimensions are recited in mutually different dependent claims does not indicate that a combination of those dimensions cannot be used advantageously.

[0369] The processes described in the Fig.1 to 3 and 5 to 13 may be implemented as program code means of a computer program and / or as dedicated hardware of the commissioning device or the 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 supplied 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 systems. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature

[0000] Taubert, T. et al.: „SPAKE2+, an Augmented PAKE (Draft)“, IETF, 5. Mai 2022

[0011] W. Ladd et al.: „SPAKE2, a PAKE (Draft)“, IETF, 2. Juni 2021

[0011] Meltem Sönmez Turan et al.: „Recommendation for Password-Based Key Derivation, Part 1: Storage Applications", NIST Special Publication 800-132, Dezember 2010

[0100] Oleg Taraskin et al.: „Towards Isogeny-Based Password-Authenticated Key Establishment

[0137] Xinwei Gao et al.: „Efficient Implementation of Password-Based Authenticated Key Exchange from RLWE and Post-Quantum TLS

[0137] Taubert, T. et al.: „SPAKE2+, an Augmented PAKE (Draft)

[0180] T. Taubert et. al: „SPAKE2+, an Augmented PAKE (draft-bar-cfrg-spake2plus-03)“, 6. Juli 2021

[0195]

Claims

[1] Device for controlling a security setup process between a first communication device (A) and a second communication device (B) via a transmission link, the device being adapted to: Placing information about a reliability setting (REL A) applied by the first communication device (A) for communication with the second communication device (B) in a preamble message (Pre_AB); and Transmitting the preamble message (Pre_AB) with the information about the reliability setting (REL A) to the second communication device (B) in a preamble phase before the safety setup process. [2] Device for controlling a security setup process between a first communication device (A) and a second communication device (B) via a transmission link, the device being adapted to: Receiving a preamble message (Pre_AB) from the first communication device (A) in a preamble phase before the security setup process, which preamble message contains information about a reliability setting (REL A) to be applied by the first communication device (A) for communication with the second communication device (B); and Selecting an applied reliability setting for communication with the first communication device (A) based on the received information about the reliability setting (REL A) of the first communication device (A) and a separate reliability setting (REL B) of the second communication device (B). [3] Device according to claim 1 or 2, wherein the reliability setting (REL A, REL B) comprises at least one reliability parameter defining at least one selected from the group of a retransmission function or a timeout value. [4] The device of claim 3, wherein the retransmission function or the timeout value allows at least one selected from the group that identifies a message as reliable and requires acknowledgment by the receiver, including information that identifies a message as acknowledgment for an identified previous message, and including a maximum number of retransmissions required for a message. [5] The device of any preceding claim, wherein the first communication device (A) comprises a commissioning tool configured to use the security setup process to interact with the second communication device (B) to perform at least one selected from the group of commissioning, configuring, authenticating, and authorizing. [6] Device according to one of the preceding claims, wherein the second communication device (B) comprises a medical device or a personal health device or a smart home device. [7] Device according to one of the preceding claims, wherein the device is configured to execute a password-authenticated security device protocol to mutually authenticate the first and second communication devices (A, B) and to establish a secret. [8] Device according to one of the preceding claims, wherein the preamble message (Pre_AB) is exchanged between the first and the second communication device (A, B) or between the first communication device (A) or the second communication device (B) and a relay device in an initial device detection phase. [9] Device according to one of the preceding claims, wherein the preamble message (Pre_AB) comprises a dedicated field for signaling the information about the reliability setting (REL A). [10] Device according to one of the preceding claims, wherein the device is adapted to select the applied reliability setting such that a highest reliability is adopted from the received reliability settings (REL A, REL B) of the respective devices (A, B) or that a lowest reliability is adopted from the received reliability settings (REL A, REL B) of the respective devices (A, B) or that the received reliability setting (REL A) is applied. [11] Device according to one of the preceding claims, wherein the device is adapted to pre-configure a set of possible configurations of parameter settings, and wherein the reliability setting information identifies a selected configuration. [12] Device according to one of the preceding claims, wherein the device is adapted to use a parameter configured by a third communication device during an initial configuration phase. [13] Communication device (40) comprising a device according to one of claims 1 to 12. [14] A method for controlling a security setup process between a first communication device (A) and a communication device (B) via a transmission link, the method comprising: Placing information about a reliability setting (REL A) applied by the first communication device (A) for communication with the second communication device (B) in a preamble message (Pre_AB); and Transmitting the preamble message (Pre_AB) with the reliability setting information (HF_SUP) to the second communication device (B) in a preamble phase before the safety setup process. [15] A method for controlling a security setup process between a first communication device (A) and a second communication device (B) via a transmission link, the method comprising: Receiving a preamble message (Pre_AB) from the first communication device (A) in a preamble phase before the security setup process, which preamble message contains information about a reliability setting (REL A) to be applied by the first communication device (A) for communication with the second communication device (B); and Selecting an applied reliability setting for communication with the first communication device (A) based on the received information about the reliability setting of the first communication device (A) and a separate reliability setting (REL B) of the second communication device (B). [16] A computer program product comprising code means for producing the steps of claim 14 or 15 when executed on a computing device. [17] A system comprising two or more communication devices according to claim 13.

Images