Improved security establishment method and system

Abstract

The present invention relates to a method and apparatus for setting a secure communication channel with an improved key exchange for secure setup protocols or processes.

Description

Technical Field

[0001] The present invention relates to a security establishment process between devices and / or applications in a wired data network or a wireless data 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 the security process is based on the security process. Background Art

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

[0004] A key derivation function (KDF) is a deterministic algorithm for deriving one or more secret keys (cryptographic key material) from a secret value (e.g., a master key, a password, or a passphrase) using a pseudorandom function (PRF) typically using a cryptographic hash function or a block cipher. A password-based KDF (PBKDF) can be defined by selecting a PRF and a fixed iteration count C. The inputs to an execution of a PBKDF may include a password P, a salt value S, and a desired length kLen of the desired master key mk expressed in bits, denoted as an indication of kLen. Symbolically, this may be represented as follows:

[0005] mk=PBKDF (PRF,C) (P,S,kLen).

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

[0007] Modern PBKDFs, such as PBKDF2 (specified in IETF specification RFC 2898), may be based on recognized cryptographic hashes, such as SHA-2, using larger salt values ​​(at least 64 bits and chosen randomly), and high iteration counts.

[0008] Figure 1An example of a PBKDF2 algorithm for deriving a master key from a password is shown, using a keyed-hash message authentication code or hash-based message authentication code (HMAC) and utilizing the Secure 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 involves a cryptographic hash function and a secret encryption key. Like any MAC, it can be used to simultaneously verify the data integrity and authenticity of a message.

[0009] Figure 1 The inputs to the algorithm include the password P, the salt value S, the iteration count C, and the expected length kLen of the master key in bits (at most (232-1) x hLen). The parameters of the algorithm are the PRF (which is an HMAC with an approved hash function) and the digest size hlen of the hash function. The output of the algorithm is the master key mk.

[0010] First, check whether the expected length of the master key is greater than the maximum length. If so, return an error indicator (Err-i) and stop the process.

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

[0012] Figure 2 A signaling diagram showing a message exchange between two devices A and B, including a specific enhanced PAKE procedure (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 procedure, denoted as SPAKE2, as described in W. Ladd et al., "SPAKE2, a PAKE (Draft)", IETF, June 2, 2021.

[0013] SPAKE2+ defines a PAKE that allows two parties (one party can be a device, application, etc.) A and B to agree on a public symmetric key in an authenticated manner, where the authentication is based on a (weak) password. After the initial preamble exchange (pre) to transmit identity, protocol version, PBKDF parameters, etc., the process performs a PAKE involving four messages and two round trips. The first party A calculates the shared secret pA (cpt pA), and the second party B calculates the shared secret pB (cpt pB). The first two messages (including the corresponding shared secrets pA and pB) are used to set up the protocol (su prot) and agree on a public secret. Then, the second party B calculates confirmation cB (cpt cB), and the first party calculates confirmation cA (cptcA). The last two messages (including the corresponding confirmation cB and cA) are used to derive secrets (der scr) and for key confirmation. The two messages can be combined into one (pB+cB) because they are sent continuously in the same direction (from B to A).

[0014] However, in the context of SPAKE2+ or other secure establishment procedures, it is desirable to improve the secure establishment process to further enhance security. Summary of the invention

[0015] It is an object of the present invention to provide enhanced security for communications between devices and / or applications.

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

[0017] Thus, a security establishment message (e.g., a PAKE-type or other key exchange / security establishment message) between two specific communication devices or applications can be associated with a given communication link, for example, by a session identifier, without the session identifiers of communication devices used for the same security establishment process needing to be equal. This may be advantageous when performing security establishment at the application layer, since in this case the security establishment protocol is unaware of the underlying networking identifiers (e.g., MAC or IP addresses).

[0018] Thus, when communicating devices exchange one or more initial messages (eg, preamble messages), it can be ensured that both devices have a single securely established session active, or if they have multiple sessions active, that they are linked to the correct peer device.

[0019] In addition, the security setup messages can be rearranged to require only two round trips in total. This is advantageous to achieve a more efficient protocol by reducing protocol latency and thus increase the user experience. This is also useful in situations where the protocol will be executed on a constrained network and / or with many devices at the same time.

[0020] According to a first aspect (e.g., relating to a first end of a transmission link), there is provided an apparatus for controlling a security establishment procedure between a first communication device and a second communication device on a transmission link, wherein the apparatus is adapted to:

[0021] placing in a preamble message information regarding a reliability setting to be used by the first communications device for communicating with the second communications device; and

[0022] In a preamble stage before the security establishment procedure, a preamble message having information about the reliability setting is sent to the second communication device.

[0023] According to a second aspect (e.g., related to a second end of a transmission link), there is provided an apparatus for controlling a security establishment procedure between a first communication device and a second communication device on a transmission link, wherein the apparatus is adapted to:

[0024] receiving a preamble message from the first communications device in a preamble phase prior to the security establishment procedure, the preamble message including information about reliability settings to be applied by the first communications device for communicating with the second communications device; and

[0025] Based on the received information about the reliability setting of the first communication device and the second communication device's own reliability setting, a reliability setting for an application to communicate with the first communication device is selected.

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

[0027] According to a fourth aspect, a method for controlling a security establishment process between a first communication device and a communication device on a transmission link is provided, the method comprising:

[0028] placing in a preamble message information regarding a reliability setting to be used by the first communications device for communicating with the second communications device; and

[0029] In a preamble phase before the security establishment procedure, the preamble message having information on the reliability setting is sent to the second communication device.

[0030] According to a fifth aspect, there is provided a method for controlling a security establishment process between a first communication device and a second communication device on a transmission link, the method comprising:

[0031] receiving a preamble message from the first communications device in a preamble phase prior to the security establishment procedure, the preamble message including information about reliability settings to be applied by the first communications device for communicating with the second communications device; and

[0032] Based on the received information about the reliability setting of the first communication device and the second communication device's own reliability setting, a reliability setting for an application to communicate with the first communication device is selected.

[0033] According to a sixth aspect, a computer program product is provided, which comprises code means for generating the steps of the method according to the fourth aspect or the fifth aspect when executed on a computer device.

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

[0035] Therefore, when message exchanges occur over an unreliable or less reliable transport layer, the communication devices may adapt reliability settings based on the reliability parameters of the exchanges, thereby ensuring higher reliability.

[0036] According to a first option that can be combined with any one of the first to seventh aspects above, the reliability setting may include at least one reliability parameter defining at least one item selected from the group of retransmission capabilities or timeout values. Thus, the retransmission options and / or delays can be used as parameters for adapting the retransmission settings. In an example, the retransmission capability or timeout value may allow at least one item selected from the following group: a group that indicates that the message is reliable and requires confirmation by the receiver, including information indicating a message that serves as a confirmation for the identified previous message, and including the maximum number of retransmissions required for the message.

[0037] According to a second option which can be combined with the first option or any one of the first to seventh aspects, the first communication device may include a debugging tool configured to use a security establishment process to interact with the second communication device for at least one item selected from the group of debugging, configuration, authentication and authorization or security setting process. Therefore, the proposed security enhancement can be applied to the security establishment in combination with various debugging, configuration, authentication, authorization or security setting processes.

[0038] According to a third option that can be combined with the first option or the second option or any one of the first to seventh aspects, the second communication device can be included in a medical device or a personal healthcare device or a smart home device. Therefore, the proposed security enhancement can be applied to various medical, healthcare and smart home applications.

[0039] According to a fourth option that can be combined with any one of the first to third options or any one of the first to seventh aspects, the apparatus can be configured to run a password-authenticated security establishment protocol (e.g., a password-authenticated key exchange protocol) to mutually authenticate the first communication device and the second communication device and establish a secret. Thus, the proposed security enhancement can be applied in conjunction with password authentication.

[0040] According to the fifth option which can be combined with any one of the first to fourth options or any one of the first to seventh aspects, the preamble message can be exchanged between the first communication device and the second communication device or between the first communication device or the second communication device and the relay device in the initial device discovery phase. Therefore, the initial device discovery phase between related communication devices or via the relay device can be used to exchange the proposed security-enhanced preamble message.

[0041] According to the sixth option which can be combined with any one of the first to fifth options or any one of the first to seventh aspects, the preamble message may include a dedicated field for signaling information about reliability settings. Thus, the available fields of the preamble message can be used to transmit the reliability setting information, thereby reducing the signaling work.

[0042] According to the seventh option which can be combined with any one of the first to sixth options or any one of the first to seventh aspects, the reliability setting applied can be selected so that the highest reliability among the received reliability settings of the corresponding device is adopted, or the lowest reliability among the received reliability settings of each device is adopted, or the received reliability setting is applied. Therefore, a flexible setting process can be provided, which can be adapted based on user preferences and / or application requirements.

[0043] According to the eighth option which can be combined with any one of the first to seventh options or any one of the first to seventh aspects, a set of possible configurations of parameter settings can be preconfigured, wherein the information about the reliability settings identifies the selected configuration. Therefore, the signaling work can be reduced because only the identification (e.g., number, address, etc.) of the selected configuration needs to be signaled in the preamble message.

[0044] According to the ninth option which can be combined with any one of the first to eighth options or any one of the first to seventh aspects, the parameters configured by the third communication device during the initial configuration phase can be used for reliability settings. Therefore, the reliability settings can be controlled by the third communication device (e.g., a debugging tool or other mobile device) during the initial configuration of the first communication device and / or the second communication device.

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

[0046] It shall be understood that the apparatus, the communication device, the method, the computer program product and the system may have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

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

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

[0049] In the following figures:

[0050] Figure 1 The algorithm for calculating the master key using PBKDF is shown;

[0051] Figure 2 shows a signaling diagram including an exchange of messages according to a security establishment protocol (e.g., SPAKE2+ or SPAKE2 procedure);

[0052] Figure 3 schematically illustrates a signaling and processing diagram for an improved security establishment protocol according to various embodiments;

[0053] Figure 4 schematically illustrates a block diagram of a communication device according to various embodiments;

[0054] Figure 5 Schematically illustrates a block diagram of a PBKDF configurator element or function according to an embodiment;

[0055] Figure 6 Schematically illustrates a block diagram of an implicit PBKDF parameter generator element or function according to an embodiment;

[0056] Figure 7 A flow chart of a conditional PBKDF parameter exchange according to an embodiment is shown;

[0057] Figure 8 shows a signaling diagram of a preamble exchange with PAKE support information according to an embodiment;

[0058] Fig. 9 shows a signaling diagram of a preamble exchange with hash function information according to an embodiment;

[0059] Fig.10 shows a signaling diagram of a preamble exchange with reliability information according to an embodiment;

[0060] Fig.11 schematically illustrates a block diagram of lower layer protocol support for segmentation processing according to an embodiment;

[0061] Fig.12 A flow chart of a key derivation process based on exchanged preamble information according to an embodiment is shown;

[0062] Fig.13 schematically illustrates an exemplary protocol stack according to an embodiment;

[0063] Fig.14 A signaling and processing diagram for an improved security establishment procedure with reduced round trip times, eg based on SPAKE2(+), according to an embodiment is schematically shown.

[0064] Fig.15 Schematically illustrates a signaling and processing diagram for a UE to UE relay scenario according to an embodiment;

[0065] Fig.16 Schematically illustrates a signaling and processing diagram for a personal IoT network scenario according to an embodiment;

[0066] Fig.17 Schematically illustrates a signaling and processing diagram for a UE to UE relay scenario according to an embodiment;

[0067] Fig.17b Schematically illustrates a signaling and processing diagram for a UE to UE relay scenario according to an embodiment;

[0068] Fig.18 Schematically illustrates a signaling and processing diagram for a UE to UE relay scenario according to an embodiment;

[0069] Fig.19 Schematically shows the elements and interfaces in a personal IoT network scenario;

[0070] Fig. 20 Schematically illustrates a signaling and processing diagram for a personal IoT network scenario according to an embodiment;

[0071] Fig.21 schematically illustrates a signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment, and

[0072] Fig. 22 A signaling and processing diagram for a UE-to-UE relay scenario according to an embodiment is schematically shown. DETAILED DESCRIPTION

[0073] Embodiments of the present invention are now described based on various modifications of a security establishment procedure or protocol (SEP) that relies on, for example, generic PAKE or SPAKE2 or SPAKE2+, where the protocol allows establishing security properties such as at least one of authorization, mutual authentication based on a shared password, key establishment based on public key exchange, and key confirmation.

[0074] The inventors have recognized that real-world implementations and certain use cases may result in a need to better protect such key exchanges. Wireless networks are vulnerable to things such as man-in-the-middle attacks. Therefore, the inventors have recognized that key exchange messages can be better protected by providing at least one of the bindings to a specific set of communicating parties and / or a specific key exchange process. Likewise, it has been determined that this can benefit from improved derivation of one or more key derivation parameters based on one or more exchanged parameters, and / or support for potential key exchange upgrades to enhance security (e.g., due to increased processing power, such as achieved by quantum computers). Since the communication is susceptible to interception and is time-sensitive due to the possible involvement of users, the communication can benefit from a reduction in the number of round trips for the key exchange process. In addition, if the messages of the PAKE protocol are transmitted over an unreliable channel (e.g., via a relay device (e.g., UE to UE relay - the inventors have determined a use case that exhibits a particular vulnerability) or in a channel between personal IoT networks (PINs)), it may be beneficial to provide means for authentication and authorization or reliable transmission (e.g., retransmission).

[0075] In the following, multiple modifications or enhancements when using SEP are described based on an embodiment in which a first device or application uses PAKE to configure a second device or application. The following embodiments relate to enhancements related to providing details about the preamble, details about how to use exchange parameters in the preamble in PBKDF, details about negotiation of PAKE in the preamble, alternative options for interacting (e.g., selecting a device to start PAKE communication) after the preamble message exhibits different characteristics, and reducing the number of round trips.

[0076] The proposed enhanced SEP process can be applied in a communication network and possibly other networks in combination with a wired or wireless transmission channel or communication flow. In the 3GPP specifications 23.303, 23.304, 24.334 and 24.554 for 4G and 5G networks, respectively, the so-called proximity service (ProSe) function is defined to enable cellular communication devices (e.g., UEs) that are temporarily out of coverage of access devices (e.g., eNBs). This specific function is called ProSe UE to network relay or relay UE. Relay UE is a communication device that helps another out-of-coverage (OoC) UE communicate with an eNB (i.e., access device) by relaying applications and network data services in both directions between the OoC UE and the eNB. Local communication between the relay UE and the OoC-UE is called D2D communication or sidelink communication or PC5 communication. The abbreviation "PC5" specifies the interface for sidelink communication defined by ProSe. In addition, the abbreviation "UL" is used for an uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for a downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UE).

[0077] In addition, 3GPP specifications TR 23.733v15.1.0 and TR 36.746v15.1.1 provide research on architectural enhancements, such as to enable Internet of Things (IoT) devices (in the role of remote UEs) to operate at very low power by using relay UEs to connect to a wider network. Because the relay UE is physically very close, very low power transmission can be used to reach the relay UE. This also includes security, speed, and stability improvements to ProSe. These extensions of ProSe are called enhanced ProSe ("eProSe").

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

[0079] There are IoT networks in which devices communicate with each other and with other networks via gateways. These networks may be referred to as personal IoT networks (PINs), and the devices in such networks may be referred to as 'PIN elements'. Such a network may communicate with another network via a PIN element with gateway capabilities (PEGC). The PIN elements of a PIN may be managed by at least one PIN element with management capabilities (PEMC). An example of another network may be a 5G network, and document TR 23.700-18 describes the enhancements of a 5G system to support PINs according to the service requirements documented in TS22.261.

[0080] According to TR 23.700-88 (for example), a PIN element may be a UE or a non-3GPP device that may communicate within a PIN (via a PIN direct connection, via a PEGC, or via a PEGC and 5G capability (5GC)), or communicate outside a PIN via a PEGC and a 5GC. According to TR 23.700-88, a PIN element with gateway capabilities is a PIN element with the following capabilities: providing connections to and from a 5G network for other PIN elements or acting as a relay for communication between PIN elements. A PIN element with management capabilities is a PIN element with the ability to manage PINs. According to TR 23.700-88, a PIN direct connection refers to a connection between two PIN elements without a PEGC, any 3GPP RAN or core network entity in the middle. A number of key issues are included in TR 23.700-88, including 5GC architecture enhancements for supporting PINs, PIN and PIN element discovery and selection, management of PINs and PIN elements, communication of PINs, authorization of PINs, policy and parameter supply for PINs, or identification of PINs and PIN elements. TR23.700-88 also includes instructions for Fig.13 There are multiple feasible solutions for the protocol layer structure shown. It should be understood that Fig.13 The layer structure is not limited to 5G networks, and many other networks may adopt a similar layer structure.

[0081] Fig.13 An exemplary protocol stack according to an embodiment is schematically shown, which protocol stack can be applied to, for example, TR23.700-88. Figure 6 .0B.2-2 described system.

[0082] like Fig.13As shown, the PIN layer (responsible for processing PIN ID, PIN elements, PEGC and / or PEMC) can be configured to run on multiple transport (TRA) and / or physical (PHY) layers (including WIFI, Bluetooth, 5G ProSe, etc.), and support a higher application (APP) layer (which can be configured to control light bulbs, power sockets, washing machines, or any other controllable devices) to handle key exchange and / or other security establishment functions, as described in the following embodiments.

[0083] In an example, supported PIN element function (S-PEF) can refer to the function of providing communication within the PIN layer (e.g., via PIN direct connection or via PEGC) or providing communication outside the PIN (e.g., via PEGC). The PEF can also communicate with the PEMC for configuration, discovery, and authentication and authorization.

[0084] A non-supported PEF (NS-PEF) may refer to a function that communicates directly between the transport (TRA) and / or physical (PHY) layers and higher application layers without using an intermediate PIN layer.

[0085] Additionally, there may be critical issues such as protecting the identity of the PIN and PIN privacy, secure communication between PINEs, secure policy and parameter provisioning, authorization of a PIN element (PINE), PIN and PINE discovery authorization, controlling PIN element access to other (e.g., 5G) networks, authentication and authorization of PINEs, secure authentication of PINEs, or secure provisioning of credentials in non-3GPP devices via PEGC.

[0086] There may be scenarios involving relay devices such as UE-to-UE relays, i.e., a first device A talks to a second device B through a third device acting as a relay. In such use cases, there may be issues including privacy protection, integrity protection, confidentiality protection, or authorization on the UE-to-UE relay. The functionality of a relay can also be seen in mesh networks.

[0087] In the following, various embodiments with improvements to SEP are described. Figure 4 Describes further details of the hardware components involved, and also refers to Figure 3 and Figures 5 to 13 Describe the details of its process and signaling steps.

[0088] Some embodiments are Figure 3 In summary, a first device or apparatus A wishes to set up a secure communication channel with a second device or apparatus B.

[0089] Figure 3A signaling and processing diagram for an improved SPAKE-based SEP according to various embodiments is schematically shown. In the diagram, information exchange between two devices A and B and their directions are indicated by corresponding arrows, and processing steps are indicated by corresponding blocks, while time is from Figure 3 Not all steps are always needed or applied, and some steps may be performed multiple times to increase accuracy or a continuous process.

[0090] The first device A may be a mobile application for configuring the second device B (e.g., a medical device or a personal health care 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 WiFi or other communication means (such as Bluetooth Low Energy (BLE), Thread) or via 3GPP standards (e.g., using a sidelink) or via a low power communication protocol.

[0091] It may be the case that a device (or combination of devices) is used to configure other devices, in particular for connecting to a given network. One or more devices may be dedicated to this purpose, or it (they) may be a more general device with functionality running on it (they). An example of functionality running on a device may be an application (or 'app') running on a smartphone. An example of multiple devices providing functionality may be one device that relays messages for configuration to another device (such as a server). The term "debugging tool" may be used to refer to the functionality provided by a device (or combination of devices) that performs the task of configuration, or it may be used to refer to the device itself.

[0092] Two devices A and B may need to run PAKE, such as enhanced or balanced PAKE (e.g., SPAKE2+ or SPAKE2, respectively) to authenticate each other and establish secrets. However, there may be multiple pairs of devices A and B doing the same operation at the same time. This may happen, for example, when a debugging tool for an IoT network (such as device A, when providing functionality for that purpose) needs to debug many devices B, or when device B can be configured by multiple debugging tools.

[0093] Therefore, it is important to associate a PAKE exchange to a given communication link between two specific devices. Each device A or B can associate such a PAKE exchange to a given communication (link) identified by a given communication session identifier. The session identifiers of devices A and B for the same PAKE exchange do not need to be equal. This may be important when the PAKE process is performed at the application protocol layer, because in this case, PAKE is not aware of the underlying networking identifiers, such as the media access control (MAC) addresses or IP addresses of the lower protocol layers.

[0094] When devices A and B exchange some initial messages (e.g. Figure 2 ), devices A and B may need to ensure that they have a single PAKE session active, or that they are linked to the correct peer if they have multiple PAKE sessions active.

[0095] In an example, device A may be a commissioning tool that may interact with many potential devices (eg, smart home devices) to be commissioned and / or configured and / or authenticated and / or authorized and / or securely configured.

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

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

[0098] In the message Pre_AB, device A may send its short (eg, 8 bits) PAKE identifier ID_A to device B. As an added option, device A may also include a (long) random value R_A in the message Pre_AB.

[0099] In the message Pre_BA, 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 a later embodiment, device B may also include at least one of an identifier (PAKE_ID) of a PAKE protocol version and a reliability parameter (reli par) in its message Pre_BA.

[0100] Upon 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 as ID_B in subsequent messages (step 302). If R_A' and R_A do not match, device A can abort the process, for example, with an error message or report (e.g., identifying a man-in-the-middle or other attack) or discard the executed protocol or restart the protocol.

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

[0102] More specifically, in Figure 3 In step 303, device A determines or applies PBKDF parameters based on information provided in corresponding fields, for example, exchanged with the preamble message or provided / configured by the central management entity. Device A then calculates the public secret p_A in step S304 and sends it in step 305 in a first message PAKE1 together with the most recently received R_B'.

[0103] Upon 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 as ID_A in subsequent messages in step 307. If R_B' and R_B are not equal, device B may abort the process, e.g., with an error message or report (e.g., identifying a man-in-the-middle or other attack), or discard the executed protocol or restart the protocol.

[0104] In step 308, device B may determine or apply PBKDF parameters based on information provided, for example, in corresponding fields exchanged with the preamble message or provided / configured by the central management entity. Then, in step 309, device B calculates the public secret p_B in the second message PAKE2 and sends it to device A. In addition, device B derives the shared secret in step 310 based on the received public secret p_A. Then, in step 311, device B derives the key confirmation c_B in the third message PAKE3 and sends it to device A.

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

[0106] The key confirmation c_A and c_B in the last round trip may be an authentication key derived from a shared symmetric secret. In an example, both device A and device B may be configured to compute an authentication tag using the authentication key generated on the protocol copy.

[0107] Finally, a final message (FM) is sent from device B to the initiating device A to close the process.

[0108] In some scenarios, such as those addressed in TR 33.740, the exchange of preamble messages or some of their fields may be done between UEs, through a UE relay or during an initial discovery phase between a UE and a UE relay (e.g., a discovery phase associated to a UE to UE relay scenario). In such scenarios, the PAKE exchange may be done during the establishment of a secure PC5 interface that occurs after the discovery phase. In some scenarios, such as those addressed in TR 33.882, the exchange of preamble messages may be done during the discovery phase of a PINE.

[0109] Therefore, by providing preamble messages Pre_AB and Pre_BA with PAKE identifiers ID_A and ID_B and random values ​​R_A and R_B, respectively, PAKE sessions can be distinguished to ensure that device A and device B have a single PAKE session active, or if device A and device B have multiple PAKE sessions active, they are linked to the correct peer.

[0110] exist Figure 3 In the above use case, the debug tool (device A) may need to interact with many devices at the same time. However, device B may be allowed to interact with a single debug tool at a time. Therefore, device B may have a single PAKE exchange process active at any point in time.

[0111] Therefore, in an alternative embodiment, Figure 3 The step involving R_B is removed because device B can expect a single device A to be active at any point in time, for example, when device A is a debugging tool (such as an app running on a mobile phone) and device B is a smart home device. In this case, the exchange may not require the exchange of R_B at all.

[0112] Similarly, in an alternative embodiment, instead of requiring the exchange of two preamble messages Pre_AB and Pre_BA, a single preamble message may be involved, such as Pre_AB or Pre_BA. For example, upon receiving Pre_AB, device B will reply to the first PAKE message. In this alternative embodiment, Pre_AB may only include certain configuration parameters or preferences. In a specific application of this alternative embodiment related to 3GPP proximity services, for example, for use cases and requirements in TR 33.740, the content in the Pre_AB message may be included in a model A discovery message, i.e., in a notification message sent by the notifying UE. When the Pre_AB message (i.e., the notification discovery message) is received by device B (i.e., by the monitoring device), device B will reply to a direct communication request (DCR) message that initiates PAKE and includes the first PAKE message.

[0113] Figure 4 A block diagram of a communication device 40 according to various embodiments is schematically shown, which may correspond to at least one of the above-mentioned device A and device B (including applications).

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

[0115] A preamble control unit or function (PRE) 48 is provided for generating and decoding a transmitted preamble message (e.g. Figure 3 Pre_AB, Pre_BA in the PAKE process, which are respectively received by the transceiver 42 during the preamble stage of the PAKE process.

[0116] In addition, the communication device 40 includes a device for generating and decoding the transmitted PAKE message (e.g., Figure 3 The PAKE control unit or function 46 of PAKE1 to PAKE4 in FIG. 1 is respectively received by the transceiver 42 during the preamble phase of the PAKE process.

[0117] Additionally, the communication device 40 comprises a PBKDF control unit or function 44 for deriving a key to be used in the PAKE process.

[0118] 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 can be combined in a single control unit (e.g., a software-controlled processor or computer) and can be implemented by corresponding software routines controlling the processor or computer device.

[0119] It should be further noted that Figure 4The dashed boxes represent optional components that will be described in more detail in subsequent embodiments.

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

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

[0122] Additionally, reliability settings (RELs) 402 may be stored in the communication device 40 that affect the communication behavior of the communication device 40, as described later.

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

[0124] exist Figure 3 In the above use case, when device B is allowed to have a limited number of PAKE sessions active at any point in time, device B may need to limit the number of incoming requests.

[0125] Thus, if device B has set the peer session identifier 401 to be used as ID_A in subsequent messages upon receiving the preamble message Pre_AB (e.g., due to not using R_B) and before receiving the first PAKE message (e.g., the first message of the SPAKE2+ procedure), device B may be configured to limit the number of preamble messages Pre_AB allowed per unit time, and / or to limit the maximum number of peer ID sessions allocated, and / or to discard the allocated ID_A if the first PAKE message PAKE1 is not received before a predetermined timeout. This may be particularly advantageous in the case where R_B is not used or at least not checked.

[0126] The corresponding parameters (e.g., the maximum number of preamble messages per unit time, the maximum number of allocated peer ID sessions and / or a predetermined timeout) can be stored as session limit parameters 405 accessible to the preamble control unit and / or PAKE control unit of function 48 or function 46.

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

[0128] Figure 5 A block diagram schematically illustrates elements or functions of a PBKDF configurator according to an embodiment.

[0129] The PBKDF configurator element or function can be composed of Figure 4 The PBKDF control unit or function is implemented.

[0130] As initially combined Figure 1 As described, a PBKDF may require several parameters, such as a counter value or a salt value. These parameters may be configured by default settings, by manual user action, for example out-of-band (i.e., not included in the exchanged preamble and PAKE messages), or may be specified in the specification. However, in this case, these parameters are fairly static. This may raise the question of whether the output of the PBKDF will always remain the same after the initial preamble phase is executed. However, in some cases, it may be desirable to bind a given preamble execution to a subsequent PAKE execution.

[0131] In an embodiment, to solve this problem, the information exchanged in the preamble phase can be used as a reference to the PBKDF (i.e., to Figure 4 The PBKDF control unit or function 46 in is an input.

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

[0133] It should be noted that the same embodiments are applicable if / when a different routine (eg, a hash function or HMAC) is used for deriving keys based on a password (ie, different than PBKDF).

[0134] like Figure 5As indicated, the exchanged random parameters R_A and R_B (or at least one of these) may be provided as input values ​​to a PBKDF control unit or function 44 and may be processed (e.g., logically or arithmetic combined) to obtain at least one of a PBKDF parameter count value (CV) and a salt value (SALT).

[0135] In a first example, the salt parameter may be calculated as a logical XOR combination of the swapped R_A and R_B parameters.

[0136] 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 set of salt values ​​(P-SALT) and stored in the communication device 40 .

[0137] In a third example, the salt parameter may be calculated as a hash function of one of the salt parameter values ​​described above.

[0138] In a fourth example, the salt parameter may be calculated as a cryptographic function, such as a hash function, of a function (eg, a concatenation) of the exchanged R_A and R_B parameters.

[0139] In a fifth example, the salt parameter may be a subset (eg, truncated) of the bits of any of the above salt parameter values.

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

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

[0142] Alternatively, exchanged parameters (eg, R_A and R_B) may also be used with a shared password (eg, concatenation).

[0143] As a further alternative, the PAKE identifier exchanged by devices A and B in the preamble message may also be used as an input parameter in the above example.

[0144] For example, when the PAKE is a balanced PAKE, the above alternatives may be applied. The above alternatives also apply, for example, when the password in the enhanced PAKE is stored in a secure element (e.g., a SIM card) that performs a PBKDF, and only returns a value or token from which the password cannot be easily retrieved, for example, only by an offline dictionary attack. The value may be a verification value pair L and w0. The above alternatives also apply when the communication device requests a third communication device to calculate and return a value or token for a password that is not accessible or known to the communication device given input exchange parameters and.

[0145] As another alternative, the values ​​R_A and R_B may also be combined at a later stage of the SEP to link the preamble to a key derived from PAKE. For example, once the initiator and responder have established a shared secret K, a subsequent session key K' may be derived from K, R_A and / or R_B.

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

[0147] As indicated above, the PBKDF parameters (e.g., salt value and / or counter value) may be received during the pre-configuration phase, or the PBKDF parameters may be exchanged over a different channel, e.g., these parameters 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 (e.g., a network function in a 5G system) during pre-configuration.

[0148] However, the exchange of PBKDF parameters may require additional space, for example, in a QR code. For example, a QR code may need to encode more information and, therefore, may require a larger amount of additional space on a package or on a product such as a light bulb. In addition, wireless messages may need to be longer, which requires additional energy for their transmission.

[0149] The way to handle this problem is to exchange PBKDF parameters implicitly, i.e., the actual information for the PBKDF parameters can be read or exchanged for different purposes, e.g., to identify a given network or device type, and this information can be reused as PBKDF parameters (e.g., salt or counter values). This can also be beneficial because it can allow the initiator to skip the exchange of preamble messages, i.e., the initiator can directly send the first PAKE message.

[0150] Figure 6 Schematically illustrated is a block diagram of implicit PBKDF parameter generator elements or functions according to an embodiment.

[0151] For example, if the first purpose (1 st PP) 64, the same bits or a (predetermined) subset of bits may be reused as a salt parameter or counter value. To achieve this, an extractor function (EXTR) 62 (e.g., a register or addressable memory portion) may be used to copy the bits and provide them to a PBKDF parameter memory or register (PDKDF-P) 66. Examples of a first purpose may include an identification of a network or details about devices, such as their type. In particular, the first purpose may be any purpose other than a PBKDF operation.

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

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

[0154] Implicit exchange of PBKDF parameters may have limited control over their values, and thus at least some PBKDF parameters (e.g., counter values) may be set to inappropriate values. This may be prevented by adding a fixed value (e.g., a number) as an offset to the implicitly derived value, so that the parameter value to be used (e.g., counter value) may be calculated by the following function or any other function that guarantees a certain property (e.g., a minimum value of a PBKDF parameter):

[0155] Parameter value = fixed number + implicitly obtained value

[0156] It should be noted that the password may also be pre-configured, in particular in embedded devices without input devices such as keyboards. An example of such an embedded device is a light bulb. The password should not be exchanged unprotected over the air, but its reading may also be implicit. For example, device B may have a QR code encoding certain parameters. Device A may then read the QR code and derive a shared password based on all or at least part of the read parameters. It should be noted that the password may also be received from a central entity (e.g. a network function in a 5G system) during pre-configuration.

[0157] Figure 7 A flow chart of a conditional PBKDF parameter exchange according to an embodiment is shown, which may be implemented by the PAKE control unit or function 46.

[0158] The preamble message Pre_AB may be configured to provide an indication as to whether the required PBKDF parameters are already known by device A. The reason for this may be that in some use cases, device A may have other access to the PBKDF parameters (eg, via implicit signaling as described above).

[0159] However, in other scenarios, it may not be feasible for device A to know the PBKDF parameters, for example, when device A is a debugging tool that sends requests to many devices via WiFi or Ethernet or Bluetooth, etc. Similarly, in other scenarios, device A may always know the PBKDF parameters.

[0160] Similarly, in some scenarios, device A may be a debugging tool, and device B may be an IoT device. Since IoT devices have very different communication and computing capabilities, a given IoT device B may only support a certain security level. Therefore, device B may be configured or requested, for example in a preamble Pre_BA sent from device B to device A, to indicate the security strength of its determination of kLen (e.g., configured by the manufacturer), and may indicate the strength of the subsequent PAKE. Upon receiving Pre_BA, device A may use the appropriate security parameters to derive appropriate parameters for performing PAKE.

[0161] An attacker can use this flexibility (e.g., introduced by the protocol giving an indication of whether device A knows the PBKDF parameters) to disrupt communications in a variety of ways. For example, an attacker may wish to intercept parameter information to better predict the potential output of the PBKDF. An attacker can trigger this exchange by placing itself between device A and device B and modifying the corresponding indication in the Pre_AB message that the PBKDF parameters need to be exchanged. In another example, an attacker may wish to modify the parameter information to easily force a failure in a subsequent PAKE phase. An attacker can do this by placing itself between device A and device B and modifying the information exchanged.

[0162] In this embodiment, the security and robustness of the protocol may be increased by providing, for example, conditional transmission of PBKDF parameters.

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

[0164] Note that in some cases, a third device (e.g., a management entity such as a network function in a 5G core network or an application running in the cloud) may perform such a check on behalf of device B. In such a case, device B may (need to) forward (or be requested to forward) the request to the third device, which will then perform a copy of the check protocol and provide the results of the check to device B.

[0165] 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, then even if the content of message Pre_AB indicates that device A does have (access to) the PBKDF parameters, the process branches to step 720 and device B sends, for example, its PBKDF parameters in, for example, the preamble message Pre_BA (because message Pre_AB may have been maliciously modified).

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

[0167] It should be understood that the PKBDF parameters of device B may have been determined by the methods described previously, such as deriving a salt value from the preamble parameters (e.g., R_A and / or R_B) or by OOB methods. Then, on top of other metrics, the conditional transmission of the PKBDF parameters can serve as a further security enhancement.

[0168] In an example, device B may be configured to report or log events where a preamble message having a different value than expected gives device B an indication that an attack is in progress.

[0169] Due to the advent of quantum computers, new cryptographic primitives (algorithms) for key encapsulation and digital signatures may be needed. Once quantum computers are available, many conventional cryptographic primitives will be broken, including, for example, SPAKE2+.

[0170] Therefore, ecosystems that begin to deploy systems running protocols based on PBKDF plus SPAKE2+ or another SEP (e.g., smart home ecosystems) may require protocol upgrades to incorporate quantum-resistant PAKE. For example, different PAKE protocols (e.g., as described in "Towards Isogeny-Based Password-Authenticated Key Establishment" by Oleg Taraskin et al. or "Efficient Implementation of Password-Based Authenticated Key Exchange from RLWE and Post-Quantum TLS" by Xinwei Gao et al.) can be performed in the PAKE phase after the initial preamble phase.

[0171] While a device (e.g., device A) may be able to run multiple PAKE protocols, another device (e.g., device B) may only be able to execute one PAKE protocol (either the legacy SPAKE2+ or a new PAKE protocol, e.g., a quantum resistant PAKE protocol). In this example, the legacy device may only be able to run SPAKE2+, while the new device may run the new PAKE protocol.

[0172] Figure 8 A signaling diagram of a preamble exchange with PAKE support information according to an embodiment is shown.

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

[0174] Similarly, the modified message Pre_AB 804 may include a new protocol support field (PAKE-SUPP) indicating one or more PAKE protocols supported by device A. If new device B receives the protocol support field, device B knows that device A supports multiple PAKE protocols and can pick the appropriate protocol.

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

[0176] 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. In addition, further information, such as how to obtain key derivation parameters (such as salt values ​​and count values), or whether the other party uses an OOB method.

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

[0178] To address this issue, information about device A's preferred parameters (eg, preferred hash functions or supported hash functions) may be exchanged in the message Pre_AB during the preamble phase.

[0179] Fig. 9 A signaling diagram of a preamble exchange with hash function information according to an embodiment is shown.

[0180] To address the above issue, device B may make a choice regarding the hash function to be used upon receipt of a modified Pre_AB message 902 having a new hash function support field (HF-SUPP), and provide (signal) its choice in a modified Pre_BA message 904 having a new hash function support field (HF-SUPP).

[0181] Legacy devices that cannot understand the new hash function support field of an embodiment may simply ignore the field. If no corresponding answer is returned, device A may be configured to use legacy parameters.

[0182] In some cases, the message exchange in the preamble and / or PAKE phase may occur over an unreliable transport layer, i.e., messages may be dropped and, for example, may need to be retransmitted. This may require enhancing the protocol itself with the ability to retransmit messages or to exchange certain reliability parameters, for example, as part of the Pre_AB and / or Pre_BA messages, with a lower layer protocol (e.g., a MAC protocol) that can provide such reliability capabilities.

[0183] Reliability capabilities can involve at least one of: indicating a message as reliable such that when the message is received, the receiver is required to send back an acknowledgment; including a field indicating a message that acts as an acknowledgment for a given previous message (e.g., identified by means of a message identifier such as a counter); and including a maximum number of retransmissions required for a message (e.g., until an acknowledgment is received).

[0184] Fig.10 A signaling diagram of a preamble exchange with reliability information according to an embodiment is shown.

[0185] According to this embodiment, reliability settings REL_A and REL_B (eg, Figure 4 The reliability setting 402 in the protocol is exchanged with the corresponding new field in the preamble stage (e.g., in the modified Pre_AB message 1002 and the modified Pre_BA message 1004) and can be applied to all subsequent messages in the protocol or to specific (e.g., marked or predetermined) messages that require reliability.

[0186] The underlying reliability protocol may allow a limited number of pending acknowledgments and retransmissions, such as a single For example, when executing the preamble and PAKE protocols, device A and device B may be configured to force them not to accept or allow receipt of a given message until a previous message has been correctly accepted or received and a reply has been provided.

[0187] For example, if device A sends message M_A1, device B replies with message M_B1, then device A replies with message M_A2, then device B replies with message M_B2, then M_A3, then M_B3, etc. Then, one of the devices (e.g., device A) may be configured not to accept message M_Bi until message M_A(i-1) has been acknowledged.

[0188] In a first example, upon receiving reliability parameters REL_A and REL_B in Pre_AB and Pre_BA messages, device A and device B may be configured to apply the reliability parameter that ensures the highest reliability from the two reliability parameter sets. For example, if reliability parameter REL_A requires up to two retransmissions and reliability parameter REL_B requires up to three retransmissions, both device A and device B are configured to retransmit up to three times.

[0189] In a second example, upon receiving reliability parameters REL_A and REL_B in Pre_AB and Pre_BA messages, device A and device B may be configured to apply a reliability parameter that ensures the lowest reliability from the two reliability parameter sets. For example, if reliability parameter REL_A requires up to two retransmissions and reliability parameter REL_B requires up to three retransmissions, both device A and device B are configured to retransmit up to two times.

[0190] In a third example, upon receiving reliability parameters REL_A and REL_B, device A and device B may be configured to apply the reliability parameters required by the other party. For example, if reliability parameter REL_A requires up to two retransmissions and reliability parameter REL_B requires up to three retransmissions, device B and device A may retransmit up to two and three times, respectively.

[0191] The reliability parameters REL_A and REL_B may be preconfigured as a configuration set, for example, four possible configurations corresponding to different parameters (which may be binary encoded with two bits). In an example, the preamble field may only include an identifier identifying the selected configuration.

[0192] In the above example, the possible configurations may correspond to configurations with increased reliability. Device A and device B may then be configured to select, for example, the configuration with the highest / lowest provided reliability based on pre-deployed and / or configurable policies.

[0193] Some networks may have a limited size MTU. While SPAKE2+ has a small message length, future uses of the PAKE protocol may involve longer messages. Therefore, determining how to segment the message and send it in a reliable manner is a challenge.

[0194] Fig.11A block diagram schematically illustrates a lower layer protocol setup for segmentation processing according to an embodiment.

[0195] Therefore, in one embodiment, the reliability parameters exchanged during the initial configuration phase (e.g., exchanged in the Pre_AB and Pre_BA messages of the preamble phase of SPAKE2+) may include the MTU parameter (e.g., Figure 4 The exchange MTU parameter may refer to the physical layer MTU of device A, device B, or both. The MTU parameter is consistent with the PAKE version (e.g. Figure 4 The PAKE version 404 in the message provides an indication of fragmentation requirements, such as the fragment size and / or number of fragments for subsequent messages.

[0196] In one embodiment, device A and device B may not know the allowed MTU (e.g., this may have been pre-configured). Therefore, messages exchanged in an initial configuration phase (e.g., a preamble phase in SPAKE2+, SPAKE2, PAKE, or another SEP) may include parameters 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 will need to be fragmented and how many fragments are needed.

[0197] These parameters can be used to set up lower layer protocols to handle fragmentation.

[0198] like Fig.11 As indicated, the lower layer protocol (LLP) 402 may be configured to handle segmentation and reliability.

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

[0200] The above parameters (e.g., MTU size and / or message size) can be set in Figure 3 The illustrated protocol is used to segment certain messages. In particular, in one embodiment, messages PAKE1, PAKE2, PAKE3, and PAKE4 may be segmented, where messages PAKE1 and PAKE2 may have the highest chance of needing segmentation.

[0201] In an example, a segment may include a segment identifier.

[0202] In another example, the configuration message may provide an indication to a lower layer segmentation protocol as to whether subsequent messages sent by, for example, device A, may be segmented and sent together. For example, device A may require message 1 and message 2, each with a transmission length of 1200 bytes, while the MTU is 1000 bytes. If the segments cannot be sent together, a total of four segment messages need to be sent (e.g., 1000 bytes, 200 bytes, 1000 bytes, and 1000 bytes). If the segments can be combined, only three segment messages need to be sent (e.g., 1000 bytes, 1000 bytes, and 400 bytes).

[0203] In one embodiment, the recipient may be configured not to reply until all fragments of a message (eg, PAKE1) have been received and reassembled.

[0204] The underlying reliability / segmentation protocol executed at a device (e.g., device A) may need to request specific segments (of a given PAKE message) that have not yet been received (e.g., received before a timer expires) from another device (e.g., device B). Alternatively, a device may also acknowledge segments that have already been received.

[0205] Entities in the device (e.g., PAKE protocol ( Figure 4 The PAKE control unit or function 46) itself or a lower layer reliability / segmentation protocol on behalf of a higher layer protocol 401 may be configured not to send a subsequent (PAKE) message until all segments of a previously expected (PAKE) message have been received.

[0206] The reliability parameter applied by the lower layer reliability / segmentation protocol may depend on the fact whether a given message needs to be segmented. Furthermore, the reliability parameter may depend on the number of fragments.

[0207] In one example, if the message does not require segmentation, retransmission may be required within a given timeout. If the message requires segmentation of the message into multiple fragments, a higher timeout value may be applied.

[0208] In another example, a lower layer reliability / fragmentation protocol may be configured for how many fragments of a message may be sent simultaneously.

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

[0210] This segmentation capability (and such lower layer reliability and segmentation protocols) can be applied not only to the PAKE protocol, but also to similar cryptographic protocols or to other applications involving large messages or requiring segmentation (e.g., due to the use of quantum resistant primitives). This can involve, for example, digital signatures or key encapsulation mechanisms.

[0211] In an alternative embodiment, a SEP including a PAKE may be configured to handle fragmentation of certain messages, for example, via a lower layer protocol that provides fragmentation / reliability capabilities to upper layers (eg, the SEP).

[0212] As combined Figure 2 and Figure 3 As explained, upon receiving the PAKE1 and PAKE2 messages, both the first device (eg, device A) and the second device (eg, device B) may be configured to derive a secret key that may be used to protect subsequent communications.

[0213] In a specific example, SPAKE2+ or another SEP may define a protocol copy TT (e.g., Figure 4 or as defined in Taubert, T. et al., "SPAKE2+, an Augmented PAKE (Draft)") by a KDF (e.g., Figure 4 The PBKDF control unit or function 44) is generated based on SPAKE2+ (or another SEP) and the input parameters of the PBKDF.

[0214] The coded bit string TT of the protocol copy is used to derive the keys Ka and Ke. The key Ka is used to generate the confirmation message (c_B, c_A) exchange in the PAKE3 and PAKE4 messages. The key Ke is used to protect subsequent services.

[0215] However, the protocol copy does not directly depend on the information exchanged in the preamble, so that the initial preamble exchange and the subsequent PAKE message are not well linked. In addition, the Ke key is a single key used to protect the service, but some protocols (e.g., 3GPP protocols) require two keys, one for integrity and one for encryption.

[0216] Fig.12 A flow chart of a key derivation process based on exchanged preamble information according to an embodiment is shown.

[0217] In this embodiment, a KDF (eg, PBKDF) can use input information exchanged in the preamble phase.

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

[0219] Then, in step 1140, the Ke key is derived based on the protocol copy.

[0220] In step 1150, the Ke key is used to derive two keys K_AB and K_BA by means of a KDF (eg, PBKDF) for protecting communications from the first device A to the second device B, and vice versa.

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

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

[0223] Such embodiments of generating integrity and confidentiality keys are useful, for example, in the context of the 3GPP standard, where integrity keys are used to generate message authentication codes, for example by using the 5G New Radio Integrity Algorithm (NIA), and confidentiality keys are used to encrypt messages, for example by using the 5G New Radio Encryption Algorithm (NEA).

[0224] Fig.14 A signaling and processing diagram of an improved SPAKE procedure or other SEP with reduced round trip times according to an embodiment is schematically shown.

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

[0226] However, having a protocol involving multiple round trips results in increased latency of the protocol and higher usage of, for example, communication or energy resources. When a user is involved (e.g., a user using device A (e.g., a debugging tool such as an app running on a phone) to configure device B, the user needs to wait for the protocol to be executed and the higher latency reduces the user experience.

[0227] Therefore, in Fig.14 In the embodiment, Figure 3The messages are rearranged to require only two round trips in total, thereby reducing protocol latency and thus improving user experience. This is also useful in situations where the protocol will be executed on a constrained network and / or executed with many devices at the same time.

[0228] A way to achieve only two round trips, and therefore, a more efficient protocol, is to have the second device (e.g., device B) send the first PAKE1 message together with the Pre_BA message in step 902. This is possible because, upon receiving the Pre_AB message from the first device (e.g., device A), the second device may have already performed PBKDF in step 901 and generated the PAKE (e.g., SPAKE2+) parameters required for the first message PAKE1. Note that due to its unbalanced nature, this may require rearranging some messages or operations in some PAKEs (e.g., in SPAKE2+). For example, the second value may be sent in the first PAKE1 message, and the first value may be sent in the second PAKE2 message. In the case of the process described in T. Taubert et al., "SPAKE2+, an Augmented PAKE (draft-bar-cfrg-spake2plus-03)", July 6, 2021, section 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 defined in the SPAKE2+ file. Note that in some cases, when the second communication device has not been previously provided or configured with a password or a password-based value (e.g., the verification value pair L and w0 in SPAKE2+), the second communication device may also be required to request the user or a third communication device to retrieve the password or password-based value.

[0229] It is to be noted that in such a protocol design device B may be subject to an increased risk of denial of service attack by an attacker sending many initial Pre_AB messages, which may, for example, exhaust the available PSI. However, to avoid this problem, this embodiment can be combined with the above-mentioned limiting embodiment with a limiting setting based on limiting parameter 405.

[0230] Note also that the first device (e.g., device A) only needs to process PAKE1 if the Pre_BA message is successful or acceptable, e.g., if the check (R_A'=R_A) in step 903 is positive, and the PBKDF is performed correctly in step 905. This also applies if the messages Pre_BA and PAKE1 are combined in a single message. If these verifications are confirmed, then in step 905, device A can continue to process message PAKE1, calculate its public share and send the PAKE2 message, deriving the key (e.g., as shown in step 907) in step 908. Fig.12) for later communication and sends PAKE3. These messages PAKE2 and PAKE3 may optionally include R_B'.

[0231] Device B, upon receiving R_B', PAKE2 and PAKE3, can check the consistency of R_B' in step 908, process PAKE2 and verify the correctness of PAKE3. If this is true, a security key for subsequent communication can be derived in step 910 (e.g., Fig.12 ), and message PAKE4 may be calculated and sent to device A in step 911 as confirmation of the success of the protocol. If R_B and R_B' do not match, device B may abort the process, for example, with an error message or report (e.g., to identify a man-in-the-middle attack or other attack) or discard the executed protocol or restart the protocol.

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

[0233] and Figure 3 In contrast to an embodiment of the present invention, in which a finish message (FM) is sent by a second device (e.g., device B) to a first device (e.g., device A) so that the first device knows that the second device has (successfully) completed the exchange, Fig.14 The current embodiment of does not require this end message, because the first device infers the state of the second device from the reception of the fourth message PAKE4. If device A needs to complete some fields in the message, these fields can be sent together with the PAKE4 message.

[0234] Fig.15 The signaling and processing diagram of the UE to UE relay scenario according to the embodiment is schematically shown. Fig.15In the example of FIG5 , a source UE (S-UE) and a target UE (T-UE) may want to establish secure communications over a UE-to-UE UE relay (UE-UE) utilizing a PC5 interface. For example, the source UE may be a smart health sensor, the target 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 device may also be out of coverage at a certain point in time. To this end, the UE may be initially configured in steps 1501, 1502, and 1503. These configuration steps may involve each UE making a request to the CN for authorization to use the UE-to-UE relay service. The request may be initiated at the time of initial authentication of each UE. The authorized UE may be provided with corresponding security key material for a subsequent discovery phase and / or security key material or authorization information for setting up a secure communication channel in steps 1501, 1502, and 1503. In steps 1504 and 1505, the source UE and the UE-to-UE relay and the target UE and the UE-to-UE relay may perform a discovery procedure, e.g., as described in TS 33.503. For example, the UE-to-UE relay may be an advertising UE and the target UE and the source UE may be monitoring UEs. The UEs may also perform a Model B discovery involving two discovery messages. In steps 1506 and 1508, a password may be entered in the target UE and the source UE, e.g., in the case of balanced PAKE. The password or a value derived therefrom may also be retrieved from the parameters configured in steps 1501 and 1503, e.g., in the case of enhanced PAKE. The source UE and the target UE may then establish a secure and authenticated channel. To this end, the source UE and the target UE may run a Figure 3 or Fig.14 Protocol (process). In step 1507, the source UE and the target UE may exchange one or two messages that may correspond to the preamble message described in the above embodiments. These messages may include a session ID, a random value, an indication of PBKDF parameters, or any other parameters as described above. These messages may also include a relay service code or any identifier related to the type of communication service to be established. In step 1509, the source UE and the target UE may exchange PAKE messages to establish a secure authentication channel. The source UE and the target UE may also optionally exchange additional messages for key confirmation. Finally, in step 1510, the source UE and the target UE may communicate securely via a UE-to-UE relay.

[0235] It should be noted that preambles may be exchanged in the discovery phase for efficiency purposes.

[0236] It should be noted that the discovery phase itself, with or without a preamble, may also be based on PAKE.

[0237] In embodiments that can be combined with other embodiments, for example Fig.15 In the process introduced in , the security establishment between the source UE (S-UE) or the target UE (T-UE) and the UE to UE UE relay (UE-UE) can also be completed as indicated in the above SEP embodiment. For example, the security establishment between the T-UE and the UE-UE / S-UE and the UE-UE can be integrated / performed in / after steps 1504 and 1505, for example, as Fig.17 shown.

[0238] Fig.17 The signaling and processing diagram of the UE to UE relay scenario according to the embodiment is schematically shown. Fig.17 In the embodiment, steps 1701, 1702, and 1703 involve initial authorization and parameter supply. Step 1704 may refer to, for example, an initial discovery message or an initial direct communication request from an S-UE to a UE-UE. Step 1705 may refer to, for example, an initial discovery message or an initial direct communication request from a UE-UE to a T-UE. In step 1706, one or more steps or messages described in the embodiment may be performed. It should be noted that step 1705 may include fields in Pre_AB as described in the above embodiments. Step 1707 may be, for example, a direct communication acceptance message. This step may include fields in the last message in the embodiment, for example, a last confirmation message or a PAKE4 message. In step 1708, one or more steps or messages described in the embodiment may be performed. Step 1709 may be direct communication acceptance, and it may also include fields in the last message in the embodiment, for example, a last confirmation message. In step 1710, one or more steps or messages described in the embodiment may be performed.

[0239] In related embodiments that can be combined with other embodiments, the Fig.17 The password described in may be configured during the initial authorization and parameter provisioning phase, or generated by a device and exchanged with another device via an out-of-band (OOB) channel, or may be entered by a user.

[0240] In related embodiments that can be combined with other embodiments, the Fig.17 The SEP described in can rely on balanced or enhanced PAKE.

[0241] In a related embodiment that may be combined with other embodiments, after performing PAKE-based SEP of the device involved (e.g., S-UE or UE-UE or T-UE), an access token may be exchanged, which may include an identifier, an identifier of an associated session, a user identifier, an identifier of a user group, privileges, access rights, etc. This information in the token may have been signed by the CN or an application in the CN and provided to the UE during the initial authorization and provisioning phase (e.g., Fig.17 The token should be stored in a secure location, such as a SIM card in the UE, when delivered to the UE. The token should be exchanged over a secure channel, for example, once the SEP has been executed.

[0242] In a related embodiment that may be combined with other embodiments, when performing a PAKE-based SEP involving a device (e.g., S-UE or UE-UE or T-UE), an access token may be received, which may include an identifier, an identifier of an associated session, a user identifier, an identifier of a group of the user, privileges, access rights, etc. This information in the token may have been signed by the CN or an application in the CN and provided to the UE during the initial authorization and provisioning phase (e.g., Fig.17 The token may be received via a secure channel, for example, once a SEP (such as a PAKE-based SEP) has been executed. The UE receiving the token may have been configured with policies in the initial authorization and provisioning phase (e.g., Fig.17 1701, 1702, 1703), which allows to determine whether the UE sending the token is authorized to utilize the UE-UE service. Fig.17b As shown in Fig.17 , where DCR refers to Direct Communication Request, DCA refers to Direct Communication Acceptance, and steps 1724, 1727 and 1730 (Further Authorization (FA)) are based on such an authentication token. In step 1720, Initial Authorization (IA) and Parameter Provisioning (PP) are performed.

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

[0244] In passing Fig.18In the illustrated related embodiment, steps 1801, 1802, 1803 relate to initial authorization and parameter provisioning. Steps 1804 and 1805 refer to initial discovery solicitation messages. Steps 1806 and 1807 refer to subsequent discovery responses. Step 1808 relates to establishing a secure PC5 link between S-UE and UE-UE. Step 1809 refers to establishing a secure PC5 link between UE-UE and T-UE. Step 1810 refers to establishing a secure PC5 (L2) or communication (L3) link between S-UE and T-UE. The security aspects in steps 1808, 1809 and 1810 can be based on the use of Fig.17 The SEP based on PAKE described in the previous embodiment shown is optionally based on a further authorization stage relying on an authorization token.

[0245] In a related embodiment, which may be combined with other embodiments, the access token contains data related to the password used in the SEP. This allows a PAKE-based SEP to be connected to tokens exchanged at a later stage.

[0246] In a related embodiment that may be combined with other embodiments, if enhanced PAKE is used in 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 the UE-UE relay to impersonate an S-UE or T-UE. Therefore, Fig.17 Step 1706 may involve a Pre_AB message or a PAKE1 message first sent by the T-UE to the UE-UE device. Fig.17 Step 1708 may involve a Pre_AB message that is first sent by the UE-UE device to the S-UE and the S-UE replies with a Pre_BA and / or PAKE1 message.

[0247] In a related embodiment that may be combined with other embodiments, if enhanced PAKE is used in SEP, the S-UE and 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 a UE-to-UE relay. Fig.17 Step 1706 may involve a Pre_AB message first sent by the T-UE to the UE-UE device and replied by a PAKE1 message relayed from the UE-UE to the T-UE device. Fig.17 Step 1708 may involve a Pre_AB message or a PAKE1 message first sent by the UE-UE device to the S-UE.

[0248] In a related embodiment that may be combined with other embodiments, if enhanced PAKE is used in 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. Fig.17 Step 1710 may involve a Pre_AB message or a PAKE1 message first sent by the S-UE to the T-UE device.

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

[0250] In a related embodiment, which may be combined with other embodiments, the key confirmation messages in PAKE3 and PAKE4 may be done implicitly as in, for example, CPAKE, thereby eliminating the need for the exchange of PAKE3 and PAKE4.

[0251] In related embodiments that can be combined with other embodiments, for example, Fig.18 During the associated initial authorization and parameter provisioning phase, the UE-to-UE relay or source UE or target UE may be configured with a user information ID, a relay service code, a UE-to-UE relay layer indicator, a service type (IP or non-IP); the UE-to-UE relay layer indicator indicates whether a specific RSC is providing 5G ProSe layer 2 or layer 3 UE-to-UE relay service, a default target layer 2 ID, security-related parameters for discovery or PAKE (such as a password or a password-based value), or further authorization procedures (such as an authorization token or policy or cryptographic key material for verification tokens), and the validity period of the parameters.

[0252] In a related embodiment, the provisioning of security parameters may be accomplished by a 5G Direct Discovery Name Management Function (DDNMF), a ProSe Key Management Function (PKMF), or a PCF.

[0253] In a related embodiment that may be combined with other embodiments, during the initial authorization and provisioning phase (e.g., Fig.171702, 1703 in steps 1701, 1702, 1703). These may require these things to discover other UEs and / or perform (PAKE-based) SEPs and / or verify access tokens and / or verify the authorization of the UE based on tokens and policies. The PKMF may be responsible for such parameters, such as public keys. The UE can contact the DDNMF to obtain the PKMF address. In the case where multiple networks are involved and some devices are roaming (for example, the source UE), the PKMFs of the corresponding networks (home and service) may need to share some of these parameters with each other, in particular the public keys used by each of them and linked to the secret private key. Once this sharing is completed, any relevant public keys can be configured in the initial authorization and provisioning phase. If these are completed, the PKMF of the UE (for example, the source UE) may be responsible for signing the access token. Additionally or alternatively, when a UE (in roaming) performs an initial authorization and provisioning phase, the UE may first contact its PKMF and based on its own PKMF may be routed to a PKMF responsible for discovery and management of PC5 key material including access tokens (i.e., the PKMF of the home network). This PKMF may be responsible for managing public keys linked to private keys used to sign access tokens. This PKMF may manage authorization policies or rely on the PCF. Thus, the PKMF may retrieve the UE's policy (locally or from the PCF), the PKMF may also assign access rights to the UE and place them in an access token that may then be signed. This signed access token is then configured in the UE.

[0254] In a related embodiment that may be combined with other embodiments involving parameter provisioning in and out of coverage, the provisioning of passwords may be completed in coverage or outside of coverage in step 0. When provisioning is completed while the UE is in coverage, the UE is configured with one or more passwords "original passwords" or "password derivation tokens". Each "original password" or "password derivation token" is associated with "metadata". "Metadata" may include "password hint", "expiration date" and "access rights". The field "password hint" indicates which password is used; the field "expiration date" indicates the time when the password is valid; the field "access rights" indicates which authorization provides the password. The bit string used as "password" in PAKE is calculated as the KDF of the "original password" and the associated metadata fields. In the case of enhanced PAKE, the "password derivation token" can be derived from the "password" itself. As in other embodiments, parameters can be received from 5G PKMF and 5G DDNMF when the UE is in coverage.

[0255] In a related embodiment that can be combined with other embodiments or used independently for parameter provisioning inside and outside coverage, during provisioning inside coverage, the UE is also provisioned with an "out-of-coverage policy" that determines whether the UE can use a temporary password (or credential, such as a key) entered or supplied by the user when it is (or was) outside coverage. When the UE is outside coverage, if the "out-of-coverage policy" allows it, the temporary password entered by the user can be provided to the UE. When the UE is in coverage, the "out-of-coverage policy" configured in the initial authorization and provisioning phase can also be used to control other communication or security aspects when the UE is outside coverage, including a) the security protocols that need / are allowed to be used or b) the security credentials to be used. For example, when the UE is out of coverage, the UE may be able to set up a secure PC5 connection via a UE-to-UE relay, for example, based on some of the above embodiments or based on some solutions, such as the solution in TR33.740. Please note that this is only allowed if the UE has been configured with a policy that allows it to do so. For example, when the UE is configured in coverage (e.g., following the above embodiments or solution #3 in TR 33.740 or the configuration in the above embodiments), the UE may be configured with a policy regarding the type of protocol or configuration parameters to be used out of coverage, such as parameters associated with solution #4 of TR 33.740. Once a UE (e.g., a source UE) has performed a discovery phase via a UE-to-UE relay, the UE may send a direct communication request message. If the UE is out of coverage and the pre-configured policy allows, the UE is allowed to use the out-of-coverage solution. In this case, the UE will send a direct security request message as in solution #4 in TR 33.740, or may request the user to enter a short password (e.g., if no password is available or the password has expired). The DCR message may include a flag indicating the solution selection (e.g., due to out-of-coverage reasons), although the flag may be implicit in the transmission of the out-of-coverage parameters. For example, if the UE-to-UE relay receives a DCR message with a specific field, such as the authorization token in step 2 in solution #4 in TR 33.740, the UE-to-UE relay may proceed to step 3 of solution #4 of TR 33.740 instead of step 3 in solution 3 of TR 33.740. For example, if the UE-to-UE relay receives a DCR message with an out-of-coverage flag, the UE-to-UE relay may request the user to enter an out-of-coverage password (if the policy allows). In addition, after receiving the DCR message, the UE-to-UE relay device may need to check (based on the policy received when in-coverage) whether the connection environment is out of coverage and whether the out-of-coverage solution is applicable. If this is not the case, the UE-2-UE relay may not reply to the DCR message, or the UE-2-UE relay may request a DCR message including an in-coverage parameter from the UE so that the in-coverage solution can be used to establish PC5 security.

[0256] In a related embodiment, which may be combined with other embodiments or used independently for parameter provisioning and solutions both in-coverage and out-of-coverage, it is advantageous if verification of the type of solution and parameters to be used is performed before the key establishment and authentication phase. In particular, it is advantageous if verification of source UE authorization (step 4 in solution #4 in TR 33.740) is performed before the direct authentication and key establishment procedure (step 3 in solution #4 in TR 33.740), in which authorization of the source UE is performed by verifying the authorization token received in the DCR message (step 2 in solution #4 in TR 33.740). The advantage is that in this case the risk of denial of service is reduced. It is also advantageous that it saves resources (step 3) in case the UE is not authorized. In the case of solution #4 in TR 33.740, the verification may involve verification of the authorization token and / or verification of the out-of-coverage environment. It should be noted that in the case of Sol#4 for example, the above situation holds true because the verification of the source UE authorization in Sol#4 is based on the authorization token shared in the DCR message, and the sharing needs to be done in a secure manner by default, as described in other embodiments. Since the receiver (e.g., UE-to-UE relay) already has the authorization token at this point in time (after receiving the DCR message), the receiver can check the authorization without delay. This is not always possible. For example, Fig.17b Step 1724 in may not be performed before step 1723 because the authorization token exchanged in step 1724 is protected based on the security link established in step 1723.

[0257] Thus, in further related embodiments, the exchange of authorization tokens may be integrated into step 1723 itself. For example, once the keys are established in step 1723, the authorization tokens may be exchanged. For example, referring to Fig.14 , the authorization token may already be included in the message PAKE 2. If PAKE (or in general, SEP) is integrated / implemented via Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages (and / or Direct Security Mode Command and Direct Security Mode Complete) as described in TS 36.536, then the authorization tokens may be exchanged in these messages as long as the underlying SEP (transmitted via e.g. Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages) allows for the protection of the authorization tokens. This may require the definition of a new message field: "Authorization Token" that allows for the indication that one of these messages includes one or more protected authorization tokens.

[0258] In a related embodiment, the authorization tokens exchanged in step 2 may advantageously be protected as follows. Instead of using the method in TS 33.503 clause 6.3.5.2 (which can only protect up to 256 bits of data), and where the selected key in step 1 of TS 33.503 clause 6.3.5.2 is used to generate a key stream (step 2 of TS 33.503 clause 6.3.5.2) that is used to encrypt private fields of a message (step 3 of TS 33.503 clause 6.3.5.2), the selected key in step 1 of TS 33.503 clause 6.3.5.2 is used as (or used to derive) an encryption key for use in conjunction with the NR encryption algorithm (NEA) to encrypt private fields of a message, such as the authorization token. This method has the advantage that the authorization tokens (longer than 256 bits) exchanged in step 2 of Sol #4 of TR 33.704 can be protected. Another advantage is that this same technique can be used to protect the authorization token sent by UE-to-UE relay to the source UE, for example in step 5 of Sol#4 in TR 33.704, where the input fields to the NEA algorithm may be different, for example, the DIRECTION field may be set to 0 in step 2 and to 1 in step 5.

[0259] In a related alternative embodiment, in some cases it may be advantageous if the authorization token is not exchanged in the DCR message (step 2 in solution #4 in TR 33.740), but is only exchanged before the verification of the authorization token (step 4 in solution #4 in TR 33.740) and the direct authentication and key establishment procedure (step 3 in solution #4 in TR 33.740), as in other embodiments of the present application. This embodiment has the advantage that the authorization token associated to both the source UE and the UE-to-UE relay can be protected in a similar manner, i.e. by using the keys derived during the direct authentication and key establishment procedure. Another advantage is that this embodiment does not require changes to TS 33.503 clause 6.3.5 for protecting the DCR message, since the protection is currently limited to a maximum of 256 bits.

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

[0261] Fig.21An embodiment is shown in , where in step 2101, the UE performs initial authorization and parameter provisioning for in-coverage and out-of-coverage situations. This step includes the configuration of parameters of different solutions / SEPs for in-coverage and out-of-coverage security establishment 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 constructs a direct communication request accordingly based on the selected out-of-coverage (in-coverage) solution and security parameters. It may include a SEP identifier. In step 2104, the UE-to-UE relay receives a DCR message and determines whether the DCR message implicitly or explicitly contains parameters of the out-of-coverage (in-coverage) solution / SEP. The UE-to-UE relay then checks that the requested solution / SEP and security parameters are suitable for its out-of-coverage (in-coverage) situation, and checks whether the policy deployed in step 2101, together with any authorization information received in step 2103, allows the use of the solution / SEP and security parameters. Once the policy is evaluated, if the result is positive, the UE-to-UE relay will continue to execute (or facilitate execution) the requested out-of-coverage (in-coverage) solution / SEP. Alternatively, if the result is negative, the UE-to-UE relay can indicate to the source UE based on the configuration that the policy does not match, and may request a different DCR message including the requested solution / SEP and security parameters. In step 2105, the UE-to-UE relay can take one of the following alternative steps: Step 2105-A, sending a message to the source UE to continue with the in-coverage solution. Step 2105-B sends a message to the core network to continue with the out-of-coverage solution. Step 2105-C sends a message to the source UE indicating that security establishment based on the exchanged parameters is not feasible and requesting alternative parameters. It should be noted that the above steps may be repeated for the security establishment procedure and authorization between the target UE and the UE-to-UE relay.It should be noted that the above procedure shows how the UE signals and agrees on the solution and security parameters through the DCR message.

[0262] This signaling and protocol phase may also be performed during the discovery phase.

[0263] In a related embodiment, the UE-to-UE relay may have indicated in a discovery message to the source UE or target UE whether it (the UE-to-UE relay) is in coverage or out of coverage. If the UE-to-UE relay operates as an advertising UE, this may be done in discovery model A. If the UE-to-UE sends a response discovery message to the source UE indicating whether it is in coverage or out of coverage, this may be done in discovery model B.

[0264] In a related embodiment, the Relay Service Code indicates the type of service to be used by the 5G ProSe Source / Target and UE-to-UE Relay, and therefore the RSC implicitly indicates the type of preferred (security) solution / procedure (e.g., in-coverage or out-of-coverage, i.e., supporting core network).

[0265] - A source UE may use multiple (eg, two) different types of relay service codes to discover a UE-to-UE relay that is capable of providing establishment of a secure communication link with and without network assistance.

[0266] - For example, the service code may indicate the type of security procedure required and / or preferred.

[0267] exist Fig. 22 A related embodiment of performing signaling and negotiation in the discovery phase is shown in FIG. Fig. 22 In the embodiment, step 2202 refers to the initial configuration and authorization step, in which the source UE / target UE / UE-to-UE relay device is configured; step 2203 refers to the initial discovery which may be model A or model B; step 2203 is a policy evaluation, in which at least one of the source UE, target UE, and UE-to-UE relay device can determine the preferred solution to be used (for example, an in-coverage or out-of-coverage solution. That is, a security process with or without network support); step 2204 refers to the initial message for triggering the setting of security settings for UE-to-UE relay security.

[0268] In a variant that can be combined with other variants, in step 2202, the source UE can send a discovery solicitation message to the target UE that can be forwarded by the UE-to-UE relay (discovery model B). The target UE can reply to the source UE with a response discovery message through the UE-to-UE relay. In another variant, in step 2202, the source UE can send a notification message to the target UE that is received by the UE-to-UE relay and forwarded to the target UE (discovery model A). In another variant, in step 2022, the UE-to-UE relay is a device that sends notification / solicitation messages to the source UE and the target UE, and potentially receives response messages from the source UE and the target UE. In these solicitation and announcement discovery messages, the source UE and / or the UE-to-UE relay and / or the target UE can indicate its preference for in-coverage or out-of-coverage scenarios and the type of in-coverage / out-of-coverage solutions (i.e., security procedures with or without network support). In the response discovery message, the UE can indicate its preferences and / or selections.

[0269] In a variant that can be combined with other variants, in step 2203, one or more of the devices can evaluate the configured policies and can decide which solution(s) to use, which solution(s) to use preferably, or which solution(s) can be proposed for use. For example, the target UE may have been configured with a policy that allows the selection of a preferred solution, which is then proposed (e.g., by means of a message) to the UE-to-UE relay and the source UE. For example, the target UE can be configured to indicate (by a message) one, two or more solutions in a preferred order of use. For example, upon receiving a message sent by the target UE, the source UE can verify the target UE's (one or more) preferred selections and evaluate them against the evaluation of its own policy, for example, the policy can give priority to its own preferences or the preferences of the other party. For example, any one of the source UE, UE-to-UE, and target UE can evaluate the policy and select the preferred solution. Then, the exchange of proposals and acceptance / confirmation can occur between the source UE, UE-to-UE, and target UE.

[0270] In a variant that may be combined with other variants, step 2202 and step 2203 may occur simultaneously, for example, step 2203 occurs at the target UE upon receiving the solicitation discovery message and before sending the response discovery message.

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

[0272] In a variant that may be combined with other variants, UE-to-UE relay selection (e.g., as done during discovery) may depend on an evaluation of a policy that specifies preferred out-of-coverage / in-coverage solutions. For example, out-of-coverage UE-to-UE relays may be prioritized over in-coverage UE-to-UE relays. For example, in-coverage UE-to-UE relays that allow out-of-coverage (e.g., due to recent / unexpired security parameters) may be prioritized over in-coverage UE-to-UE relays with expired out-of-coverage parameters.

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

[0274] In a variant, a UE may need UE-to-UE communication due to emergency reasons. In this case, a UE (e.g., a source UE) may include an emergency indication, such as "Emergency RSC" when distributing, for example, a discovery message or sending an initial DCR message. A UE-to-UE relay receiving the indication may determine how to handle the message based on, for example, its context (e.g., coverage situation) and / or policy / configuration. For example, depending on the context and policy, the source / target UE and / or UE-to-UE relay may perform one or more of the following actions:

[0275] -Request / provide emergency services based on policy;

[0276] - Log emergency requests based on the policy;

[0277] - Depending on the context, the emergency request is processed as UE-to-UE communication and / or UE-to-network communication. For example, if the UE is out of coverage, the communication is processed as UE-to-UE communication (i.e., the communication is directed to other UEs in the area), and if in coverage, it is processed as UE-to-network communication (i.e., the communication is directed to the network) and / or UE-to-UE communication (i.e., the communication is directed to other UEs in the area).

[0278] - Provide / request UE security capabilities and / or PC5 signaling security policies.

[0279] - sending an indication about the (provided) emergency service to the core network based on the policy;

[0280] - Disable security or do not enforce security even if the policy normally requires it. This can apply to:

[0281] • Discovery messages are exchanged between the source UE and the target UE via UE-to-UE relay.

[0282] · Establish security in PC5 links.

[0283] - Allow / request the use of temporary (eg, entered by the user) credentials (eg, password) to provide a minimum level of security based on policy.

[0284] The advantage of this approach is that communication over the UE-to-UE relay can be used for emergency or safety-critical situations, for example, so that two UEs that might not normally interact with each other actually interact with each other. For example, the source UE can be the UE of a person who needs help (for example, because they are being attacked or because they are suffering from an asthma event), so that when the person requests help, the help / emergency message can be distributed to other nearby UEs through the UE-to-UE relay, and in this way, they can get help quickly. For example, the source UE can be a tag attached to luggage, and when the tag misses connection with its UE (for example, the UE of the owner of the luggage), the tag (acting as the source UE) can send an emergency message to try to reach "its" UE.

[0285] In a related variation, the message sent by the source UE may include the cause of the emergency or information related to the UE / person requesting help (eg, a description of the UE / person or a description of the luggage).

[0286] In a related variation, the message sent by the source UE may include the cause of the emergency or information related to the desired target UE / person (eg, a description of the UE / person).

[0287] In general, the above embodiments require a policy to select a preferred solution, in particular a preferred in-coverage and / or out-of-coverage solution (i.e., with or without network-supported security procedures). The policy may be deployed to the source UE and / or UE-to-UE relay and / or target UE. The policy may include one or more of the following:

[0288] - which of the supported solutions is preferred or which of the supported solutions is to be used or which of the supported solutions is authorized when within coverage of one or more of the involved devices (i.e. source UE, target UE and UE-to-UE relay) or out of coverage of one or more of the involved devices (i.e. source UE, target UE and UE-to-UE relay);

[0289] - which authorization mechanism is preferred or to be used when within coverage of one or more of the involved devices (i.e. source UE, target UE and UE-to-UE relay) or out of coverage of one or more of the involved devices (i.e. source UE, target UE and UE-to-UE relay);

[0290] - Priorities assigned to different devices for determining which solution is preferred, e.g., (1) in cases where different devices have different preferences, and / or (2) priorities may depend on the coverage status of each device. For example, if the source UE is in coverage and other UEs are out of coverage, the source UE's solution is prioritized, and if all UEs are out of coverage, a default priority list determines which UE solutions to use;

[0291] - Which parameters of the supported solutions are preferred or to be used or authorized when in coverage or out of coverage;

[0292] - whether communications can / are allowed to be established, e.g. in emergency situations (e.g. for emergency services), and what security credentials / security configuration / security mechanisms are required, e.g. whether null encryption and / or integrity algorithms are allowed / tolerated;

[0293] - When the device is out of coverage, security parameters (such as passwords or keys, etc.) of the out-of-coverage solution can be generated and / or input / how to generate and / or input security parameters (such as passwords or keys, etc.) of the out-of-coverage solution;

[0294] - Which (default) authorization capabilities or access rights are assigned to the generated and / or entered (temporary) credentials (e.g., password, key) when other credentials (e.g., long-term credentials) have expired and the UE (e.g., source UE and UE-to-UE relay) is out of coverage.

[0295] - In the case where multiple UE-to-UE relays are available, which UE-to-UE relay is preferred may depend on their conditions (e.g., in-coverage / out-of-coverage) and / or the conditions of the source UE (and / or target UE) (e.g., in-coverage / out-of-coverage). For example, in-coverage UE-to-UE relay may be preferred in some situations, while out-of-coverage UE-to-UE relay may be preferred in other situations;

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

[0297] - Whether to allow more than one active connection between the source UE and the target UE via multiple UE-to-UE relays based on, for example, UE coverage conditions and / or performance requirements and / or resource constraints.

[0298] - Priority for selecting a solution in case of repeated security associations using the same or different (types of) solutions. A first example of this may be that the source UE may start a first security association using an in-coverage (or out-of-coverage) solution (e.g. using a DCR message), and then (e.g. if a timer expires), it also sends a second security association using an out-of-coverage (or in-coverage) solution (e.g. using a second DCR message), and at this point in time the source UE may receive a reply to the first security association. The policy may specify (by indicating a priority) which solution to use in this case. The priority in the policy may be applied, for example, by a UE-to-UE relay or by the source UE. A second example of this may be that the source UE may start a first security association using an in-coverage (or out-of-coverage) solution with a first UE-to-UE relay (e.g. using a DCR message), and send a second security association using an in-coverage (or out-of-coverage) solution with a second UE-to-UE relay (e.g. using a second DCR message), and at this point in time the source UE may receive a reply to the first security association. The priority in the policy may be applied, for example, by the source UE or the CN;

[0299] -If the first UE-to-UE relay is in coverage again and / or discovers a second UE-to-UE relay in coverage, whether two UEs (e.g., a source UE and a target UE (which shared / had a first secure communication link on the first UE-to-UE relay established by a security procedure without network assistance because the relay was out of coverage when the first secure communication link was established) should use a security procedure with network assistance to re-establish secure communication.

[0300] - A threshold / limit on the number of attempts that can be performed before trying to agree on a solution, such as stopping the process and / or adding other devices to a blacklist and / or reporting the problem to the core network.

[0301] The terminal UEs (ie, source UE and target UE) and the UE-to-UE relays may have different preferences for which solutions and / or security parameters (eg, passwords, cryptographic keys) to use, and thus may be configured, for example, as Fig.21 Negotiation messages are exchanged as in steps 2103, 2104, and 2105 to agree on a solution and / or security parameters or to drop the connection. Negotiation depends on the security policy provided at the UE, and the coverage status of the UE (e.g., terminal UE and UE-to-UE relay) may be considered during negotiation. The following embodiments may apply.

[0302] In an embodiment that can be combined with other embodiments or used independently, the terminal UE can be in coverage and the UE-to-UE relay can be out of coverage; the terminal UE can request an in-coverage solution, i.e., a security procedure that requires network assistance, in which case the UE-to-UE relay can approve it if it is allowed by its security policy (it can also be requested, but if the UE is not authorized to use the solution, the request can be rejected). In this case, it can be the terminal UE that communicates (or facilitates communication) and is assisted by the network in security establishment and authorization. For example, TR 33.740 describes a solution (e.g., Sol#3) in which if the UE-to-UE relay is in coverage, the UE-to-UE relay is the entity that relies on network assistance to set up a secure link between the UE-to-UE relay and the target UE. For example, step 3 in Sol#3 in TR 33.740v0.6.0 is a key request including parameters received from one of the terminal UEs (in this case, the target UE). If the UE-to-UE relay is out of coverage, but the target UE is in coverage, the target UE may act as a UE-to-network relay for the UE-to-UE relay so as to forward the message of step 3 through the target UE (e.g., acting as a UE-to-network relay). Similarly, the terminal UE in coverage may also forward the message in step 4, the key response from the CN to the UE-to-UE relay.

[0303] In another related embodiment, which may also be used independently, a terminal UE (eg, a source UE) may:

[0304] - Relaying from UE to UE to obtain indications, e.g. including their identities.

[0305] - in step 3, e.g. in Sol#3, sending the contents of the initial DCR message to the network in a Key Request to the CN on behalf of the UE-to-UE Relay,

[0306] - Receive the key response from the CN on behalf of the UE to UE relay, e.g. step 4 in Sol#3,

[0307] - Send a DCR message including the content of the received Key Response from the CN to the UE-to-UE Relay.

[0308] This embodiment allows a terminal UE (eg a source UE) that may wish to use a UE-to-UE relay to directly use network assistance to establish the security of the connection between the UE and the UE-to-UE relay.This embodiment has the advantage of reducing the number of exchanged messages.

[0309] This embodiment may also be applied in a similar manner to the exchange between the second terminal UE (e.g., the target UE) and the UE-to-UE relay, e.g., a key request and a key response of the (first) terminal UE. The UE exchange may also involve the key material required to establish a secure link between the UE-to-UE relay and the second terminal UE (e.g., the target UE).

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

[0311] In another embodiment, the terminal UE may be out of coverage while the UE-to-UE relay may be in coverage; the terminal UE may request an out-of-coverage solution, i.e., a security procedure that does not require network assistance, in which case the UE-to-UE relay may approve such a solution if it is allowed by its security policy. Even if the UE-to-UE relay participates in the security procedure without network assistance, the UE-to-UE relay may still notify the network of the link establishment attempt between the source UE and the target UE so that the network provides feedback (e.g., final authorization) as to whether the communication is authorized (e.g., when long-term credentials have expired). Based on the network's feedback, the UE-to-UE relay may carry the relay message or drop the communication if the network indicates that the connection is not authorized (e.g., if one of the terminal UEs is not authorized or if it is selecting an out-of-coverage solution when in coverage).

[0312] In another related process, the UE-to-UE relay may request / allow the performance of security procedures between a terminal UE (e.g., a source UE or a target UE) and the UE-to-UE relay without network assistance (e.g., due to performance reasons or when out of coverage). However, this communication link established using the security procedure without network assistance may be subject to a communication policy bound to the security procedure without network assistance (e.g., characterized by a given (limited) data rate, a specific frequency range, a (limited) time validity (e.g., up to t seconds), a (limited) local validity).

[0313] In another related process, the communication policy may include an access control policy, the content of which may be similar to the authorization policy in the PIN system as described in the related process / embodiment variant.

[0314] In another related process, a communication link established with a security process without network assistance may be subject to a communication policy that is bound to the security process without network assistance.

[0315] In another related procedure, the security procedures for 5G ProSe PC5 communication for 5G ProSe layer 3 UE-to-UE relay without network assistance may be as described in clause 6.6.3.2 in TS 33.503 (draftCR in TDoc S3-233374).

[0316] In another related procedure, the security procedures for 5G ProSe PC5 communication with network-assisted 5G ProSe layer 3 UE-to-UE relay may be as described in clause 6.6.3.1 in TS 33.503 (draft CR in TDoc S3-233374).

[0317] In another related process, if the terminal UE (e.g., source UE or target UE) and the UE-to-UE relay initially established a secure link without network assistance, for example, if the UE-to-UE relay was initially out of coverage or for performance reasons, the UE (e.g., UE-to-UE relay) may need to (based on policy / configuration) perform security procedures with network assistance, or (re) establish a network-assisted secure link between the terminal UE (e.g., source UE or target UE) and the UE-to-UE relay. When this new secure link is established / needed to be established may depend on the context (e.g., timeout, UE-to-UE relaying again within coverage) or policy.

[0318] In the relevant process, policies / security parameters may be provided / configured to the UE-to-UE relay to support the execution of security procedures without network assistance when out of coverage, however, once in coverage, the UE-to-UE relay may need to provide a list of (active) communication links between the terminal UEs for the network to check (e.g., whether the UEs are authorized to communicate with each other, whether the security context (e.g., key material) needs to be refreshed). The network may accordingly instruct the UE-to-UE relay how to handle the communication link it established out of coverage. For example, it may drop the communication link between the two terminal UEs (e.g., due to timeout or authorization change), trigger a re-key process, trigger a new security process, or keep the communication link unchanged.

[0319] In a related procedure that may be combined with other procedures (e.g., the procedure described in the previous paragraph), the UE-to-UE relay may trigger the performance of a security procedure with network assistance by sending a message (e.g., a security procedure request), whereby the message may be protected with key material for the current sidelink / PC5 communication link. Upon receiving the message, the terminal UE (e.g., the source UE) may provide its credentials to the UE-to-UE relay to perform a security procedure with network assistance, e.g., a direct communication request including a relay service code and a PrukID, as described in clause 6.6.3.1 of TS 33.503 (draftCR in TDoc S3-233374) for 5G ProSe layer 3 UE-to-UE relay security procedures for 5G ProSe-PC5 communication with network assistance.

[0320] In another embodiment, one or more network functions (NFs) in the CN are responsible for monitoring whether security procedures based on security procedures without network assistance are still allowed (e.g., as foreseen by policy / security key material / credentials) to be provided to the UE, or whether these policies / security key materials / credentials have expired / revoked, etc. This NF is then responsible for recording and / or stopping the security procedures currently in progress. This embodiment has the following advantages: it ensures that the network has close control over which security connections can or cannot be established, while the UE (terminal UE / UE-to-UE relay) can use security procedures that can provide enhanced performance (e.g., lower latency) without network assistance.

[0321] In one embodiment, the UE-to-UE relay may send a message to the terminal UE (eg, Fig.21 Step 2105-a) in to confirm the solution selection, for example, when the solution requested by the terminal UE does not match the solution preferred by the UE-to-UE relay, this is because the requested solution may be supported by the UE-to-UE relay after policy verification. For example, if the source UE is in coverage and requests an in-coverage solution, and the UE-to-UE relay is out-of-coverage, if its policy allows, the UE-to-UE relay can send a message to agree / continue to use the in-coverage solution, and the source UE can be assisted by the network. Similarly, if the out-of-coverage source UE requests an out-of-coverage solution, when the UE-to-UE relay is in coverage, the UE-to-UE relay will send a message indicating the mismatch (e.g. Fig.21 2105-C) or a message notifying the source UE that it approves the out-of-coverage solution (e.g. Fig.21 Similar instructions may also be sent during the discovery process.

[0322] In an embodiment variant, in case the solution (ie requested by the terminal UE and preferably UE-to-UE relay) matches, it is not necessary to have e.g. Figure 2 The message sent in step 2105-A in .

[0323] In another alternative embodiment or variation, the UE-to-UE relay may implicitly understand whether the requested solution is supported and approve it despite the mismatch by simply continuing the link establishment process based on the requested solution; in this case, step 4-A may not be required.

[0324] A UE-to-UE relay may be provided with a policy that prohibits establishing a communication link with a terminal UE without network assistance, regardless of whether it is in coverage or out of coverage. For example, if a UE-to-UE relay attempts to serve and / or establish a communication link with a terminal UE without network assistance (e.g., the terminal UE requests an out-of-coverage solution), the network may not be able to intervene (e.g., confirm to the terminal UE whether the UE-to-UE relay is authorized to establish a link when out of coverage) because the UE may be out of coverage. For this and other similar scenarios, where the network cannot assist or ensure that the communicating party is properly authorized, the UE (e.g., the terminal UE and / or the UE-to-UE relay) needs to be able to verify whether the other party is authorized to use the solution it requested / approved, and ensuring that the embodiments may include, but are not limited to, the following.

[0325] In an embodiment, a service code (e.g., a relay service code (RSC)) provided by the network can be associated with the in-coverage / out-of-coverage solution so that when the service code is used, the UE receiving a request or approval for the solution is assured that the requesting / approving UE is indeed authorized for the out-of-coverage solution.

[0326] In a further embodiment, if at least one of the UEs (e.g., source, target, or UE-to-UE relay) is within coverage, the UE may send a request including an identifier of the UE and a selection of a security solution to the network, which then verifies and provides final authorization for the link to be established.

[0327] In a further embodiment, the UE may be provided with different credentials (e.g., service codes, discovery key material, passwords, cryptographic keys, etc.) associated with in-coverage and / or out-of-coverage solutions such that use of these identifiers / keys may implicitly indicate that the UE intends / is authorized to use the requested or approved security solution.

[0328] In a further embodiment, a UE (e.g., a terminal UE) may construct a discovery message M protected by key material associated with a given service code (e.g., a relay service code). The UE may receive these key materials / service codes when the UE is authorized to use a given security procedure (e.g., in-coverage / out-of-coverage). The UE may select these key materials / service codes if the application requires a given type of security procedure (e.g., with or without network assistance). This indicates the UE's preference. For example, a UE (e.g., a terminal UE) may send a discovery message to another UE (another terminal UE) on a UE-to-UE relay. Application-specific fields of a given ProSe service may be protected with key material bound to the service code so that the UE-to-UE relay or other UEs (which do not belong to the application or are associated with the application, such as a ProSe service) cannot access them. The ProSe service may prefer / require the use of a given security procedure, such as with or without network assistance. Based on the preference, the UE may be eligible to receive credentials (e.g., relay service code / key material) to select a UE-to-UE relay that can provide support for the given security procedure. These credentials are provided by the core network. The UE may then use these credentials to protect or add protection to the discovery message M before sending it. This allows an application requiring a given type of security procedure to enable the terminal UE to select a UE-to-UE relay that can provide the required type of security procedure for the application.

[0329] In a further embodiment, if the terminal UE indicates a given preference for a given type of solution (e.g. in-coverage or out-of-coverage, i.e. with or without network assistance), and the UE-to-UE relay can provide support for such solutions / security procedures, then the UE-to-UE relay does not need to indicate its coverage status as this is not required / useful for the terminal UE and this helps save bandwidth.

[0330] In a further embodiment, the terminal UE indicates its coverage status, for example in a discovery message, so that even if the UE-to-UE relay is out of coverage, the UE-to-UE relay can accept the request to use an in-coverage solution, i.e., with network-assisted security procedures, even if the UE-to-UE relay itself is out of coverage.

[0331] In a specific process based on the proposed embodiment, 5G ProSe terminal UEs (e.g., source UEs and target UEs) and 5G ProSe UE-to-UE relays can negotiate and select security mechanisms with or without network assistance based on security policies. The negotiation process includes the following steps:

[0332] Step 0: Initial authorization of the UE and provisioning / configuration of security parameters for different security mechanisms and negotiation / selection strategies of security mechanisms.

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

[0334] Step 2: The source UE constructs a direct communication request message based on local policies, including its selected security mechanism (e.g., with / without network assistance) and security parameters, according to, for example, its coverage situation, service preference, UE-to-UE relay coverage indication, etc.

[0335] Step 3: The UE-to-UE relay receives the DCR message of the source UE and determines whether the DCR message contains an explicit security mechanism indication and / or parameters that implicitly indicate a preferred security mechanism (e.g., with or without network assistance). The UE-to-UE relay verifies whether the security mechanism and / or security parameters are appropriate for its coverage situation and whether the policy provided in step 0 allows the use of the preferred security mechanism and security parameters of the source UE in addition to any authorization information received in step 2. Based on the evaluation results, the UE-to-UE relay may continue to execute the requested security mechanism (e.g., with or without network assistance), or indicate to the source UE that the policy does not match and request a different DCR message with its (i.e., the UE-to-UE relay's) preferred security mechanism and parameters.

[0336] The security mechanism negotiation is based on the policy provided to the UE in step 0, including but not limited to the following:

[0337] Which of the supported security mechanisms or security parameters is more suitable for establishing a secure link with or without network assistance of ProSe services.

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

[0339] A default priority list that determines which UEs (e.g., source UE, target UE, and UE-to-UE relay) are prioritized for security mechanisms when the UE prefers different solutions. The priority list may depend on, for example, the functionality of the UE (e.g., relay) or its coverage status (e.g., in-coverage vs. out-of-coverage).

[0340] In a specific process, the selection method between a security mechanism with or without network assistance is as follows: A network-assisted security indicator for each relay service code (RSC) is provided in the UE to indicate whether to use a network-assisted security process. The 5G ProSe terminal UE and the 5G ProSe UE-to-UE relay select between a security process with network assistance and a security process without network assistance based on the network-assisted security indicator. If the RSC associated with the enabled network-assisted security indicator is included in the discovery message, a PC5 security process with network assistance is performed between the terminal UE and the UE-to-UE relay. Otherwise, if the RSC associated with the disabled network-assisted security indicator is included in the discovery message, a PC5 security process without network assistance is performed between the terminal UE and the UE-to-UE relay.

[0341] -For 5G ProSe UE-to-UE relay communication with Model A discovery, when the UE-to-UE relay is within 3GPP coverage, the UE-to-UE relay shall include the RSC associated with the enabled network-assisted security indicator in the discovery announcement message, and then the terminal UE and the UE-to-UE relay shall perform the PC5 security procedure with network assistance after the discovery procedure. When the UE-to-UE relay is not within 3GPP coverage, the UE-to-UE relay shall include the RSC associated with the disabled network-assisted security indicator in the discovery announcement message, and then the terminal UE and the UE-to-UE relay shall perform the PC5 security procedure without network assistance after the discovery procedure.

[0342] -For 5G ProSe UE-to-UE relay communication with Model B discovery, if the source UE includes an RSC associated with an enabled network-assisted security indicator in the discovery solicitation message and the UE-to-UE relay is within 3GPP coverage, the UE and the UE-to-UE relay perform PC5 security procedures with network assistance after the discovery procedure. Otherwise, if the source UE includes an RSC associated with a disabled network-assisted security indicator in the discovery solicitation message, the UE and the UE-to-UE relay perform PC5 security procedures without network assistance after the discovery procedure.

[0343] This procedure does not allow source UEs that do not support PC5 security procedures with network assistance to discover each other in discovery model A when approaching UE-to-UE relays within coverage. This procedure does not describe how the source UE decides to include RSC with or without network-assisted security indicator in discovery model B. This procedure does not describe how the source UE decides to perform PC5 security procedures with or without network assistance if the source UE completes two discovery procedures, one with RSC associated with an enabled network-assisted security indicator and one with RSC associated with a disabled network-assisted security indicator.

[0344] To solve these problems, several process variants can be applied which can be combined with each other or used independently:

[0345] In one process variation, when the UE-to-UE relay is in coverage, the UE-to-UE relay in Model A may send a discovery message with an RSC associated with an enabled network-assisted security indicator and a discovery message with an RSC associated with a disabled network-assisted security indicator. Depending on the configuration and / or implementation, these messages with different RSCs may be sent optionally or in any order or timing.

[0346] In one procedure variant, the coverage status of the UE-to-UE relay (e.g., in Model A) is explicitly sent alongside the RSC so that the terminal UE can reply with its preferred solution (with or without network assistance) in a subsequent discovery message (e.g., in Model A).

[0347] In one process variation, the RSC may be associated with a disabled network-assisted security indicator, and an enabled network-assisted security indicator may not be associated with any network-assisted security indicator, so that a UE receiving the RSC knows that it can choose the PC5 security procedure with or without network assistance according to its preference. For example, when a UE-to-UE relay is in coverage and supports PC5 security procedures, the RSC may be sent in discovery model A, with or without network assistance. The RSC may be sent together with the coverage status of the sending device (e.g., a UE-to-UE relay) so that the receiving device can select the appropriate security procedure.

[0348] In a procedure variation, the terminal UE in Model A may be configured with a policy to determine a preferred RSC (associated with an enabled / disabled network-assisted security indication) to react / reply to an RSC received in a discovery message, thereby performing a single PC5 security procedure (with or without network assistance). For example, if the terminal UE receives two RSCs, one associated with an enabled network-assisted security indication and the other associated with a disabled network-assisted security indication, the terminal UE may have a policy to prefer a PC5 security procedure without network assistance, and will only react / reply to the discovery message using the RSC associated with a disabled network-assisted security indication.

[0349] In one process variant, the terminal UE and / or UE-to-UE relay may be configured with a policy that determines a time window within which the terminal UE and / or UE-to-UE relay considers an RSC received in a discovery message that may be associated with an enabled network-assisted security indicator, a disabled network-assisted security indicator, or both, or neither. The terminal UE and / or UE-to-UE relay may react / reply to or discard the received discovery message based on the terminal UE's preferred solution as determined by its policy, thereby performing a single PC5 security process. Discovery messages received from the same relay may be discarded after the time window has expired or after the terminal UE has agreed to a security solution.

[0350] In one process variation, when a UE-to-UE relay is within coverage (e.g., in Model A) and sends a discovery message using an RSC associated with an enabled / disabled network-assisted security indicator, or associated with both, or associated with neither, the terminal UEs (e.g., a source UE and a target UE) may have different preferences for security solutions. For example, the source UE may prefer a network-assisted security procedure, while the target UE prefers a security procedure without network assistance. Therefore, whether the UE-to-UE relay can support different security solutions for the first hop-by-hop link and the second hop-by-hop link can be determined by its policy. In addition, if a single solution is required for both the first hop-by-hop link and the second hop-by-hop link, the selection of the security solution is determined by the UE-to-UE relay policy, for example, based on the UE-to-UE preference or the preference of the terminal UE that responds to the announcement message first.

[0351] In one process variation, the terminal UE in Model B may be configured with a policy that determines the preferred RSC (associated with enabled / disabled network assisted security knowledge) to use.

[0352] In one process variation, the terminal UE in Model B may be configured with a policy that determines the PC5 security procedures (with or without network assistance) to be performed when the source UE completes two discovery procedures, one with an RSC associated with an enabled network-assisted security indicator, and one with an RSC associated with a disabled network-assisted security indicator.

[0353] In one process variant, when the negotiation of two security processes with and without network assistance is successful, that is, when two parallel discovery process RSCs associated with an enabled or disabled network-assisted security indicator match, the terminal UE and the UE-to-UE relay shall perform the PC5 security process with network assistance. This requires one of the terminal UEs, such as the source UE, to send a direct communication request (DCR) message including an RSC bound to the PC5 security process with network assistance. If the UE-to-UE relay matches two RSCs in a previous discovery process, the UE-to-UE relay can receive the DCR message and process it using the security materials bound to the two RSCs in a predetermined order (according to Section 6.3.5 in TS 33.503). For example, the UE-to-UE relay can first use the security materials linked to the RSC bound to the PC5 security process and perform security processing for the integrity verification and decryption of the DCR message with network assistance. If this first security processing / verification fails, the UE-to-UE relay can attempt to process the integrity verification and decryption of the DCR message using the security materials bound to the PC5 security process without network assistance.

[0354] In general, embodiments that require configuration and use of policies to determine which solution / protocol to use and which security parameters (e.g., passwords, cryptographic keys) to use have the advantage that it can help prevent a UE that is capable of using both an in-coverage solution and an out-of-coverage solution from deciding to use an out-of-coverage solution when in-coverage. Not only would this break interoperability, but it could also introduce security vulnerabilities if the out-of-coverage solution is more lax (in terms of security) than the in-coverage solution.

[0355] This signaling and protocol phase may also be performed in an integrated discovery, i.e. the discovery message is integrated in the DCR message. For example, solution #32 in TR 33.740 v0.6.0 describes an integrated discovery procedure that allows a communication link to be established between a source UE and a target UE when the UE-to-UE relay is in coverage, i.e. with the support of the network. The initial DCR message sent by the source UE in such a solution / procedure may also indicate the preferred security type for subsequent security establishment, e.g. whether to rely on the core network. The source UE / UE-to-UE relay / target UE shall use the preferred security establishment based on the indication, context and pre-configured policies.

[0356] Generally speaking, a method and apparatus are described that can be implemented in a device for:

[0357] receiving an indication from the first device regarding a SEP (solution / protocol) and / or security parameters to be used, the SEP (solution / protocol) and / or security parameters being used to establish a secure link between the first device and the second device,

[0358] assess whether the indicated SEP (solution / protocol) and / or security parameters can be used, and

[0359] The positive or negative evaluation is processed based on the policy evaluation (ie, a subsequent message determined by the positive or negative evaluation of the received indication is sent) to the first device or the third device.

[0360] Generally speaking, a method and apparatus are described that can be implemented in a device for:

[0361] receiving an indication from the first device regarding a SEP (solution / protocol) and / or security parameters to be used, the SEP (solution / protocol) and / or security parameters being used to establish a secure link between the first device and the second device,

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

[0363] Generally speaking, a method and apparatus as described above is described, wherein an indication of a SEP (solution / protocol) and / or security parameters to be used is signaled in a discovery message or a DCR message.

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

[0365] Generally speaking, methods and apparatus are described that enable processing of a positive or negative evaluation (ie, sending a subsequent message determined by a positive or negative evaluation of a received indication) to a first device or a third device based on a policy evaluation.

[0366] Being able to manage out-of-coverage provisioning provides flexibility. Given that UEs are mobile, it is likely that they will be out of coverage at times. While they are out of coverage, provisioning during that time may be convenient. For example, in the case of a user action being required, it may be convenient for the user to complete their action at the time when the UE happens to be out of coverage.

[0367] In a related embodiment related to parameter provisioning and using in-coverage and out-of-coverage solutions (which may be combined with other embodiments or used independently), it is advantageous if verification of the type of solution and parameters to be used is performed before the key establishment and authentication phase. In particular, it is advantageous if verification (step 3 in solution #4 in TR 33.740) of source UE authorization (step 4 in solution #4 in TR 33.740) is performed before the direct authentication and key establishment process. This is advantageous because in this case the risk of denial of service is reduced. It is advantageous because resources are saved in case the UE is not authorized (step 3). In the case of solution #4 in TR 33.740, the verification may involve verifying the authorization token received in the DCR message in step 2 and / or verifying the out-of-coverage environment.

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

[0369] In general, it is advantageous to require configuration and usage policies to determine which solution / protocol to use and which security parameters (e.g., passwords) to use, because otherwise a UE that is capable of using both the in-coverage and out-of-coverage solutions may decide to use the out-of-coverage solution when in-coverage. This not only breaks interoperability, but can also introduce security vulnerabilities if the out-of-coverage solution is more lax (in terms of security) than the in-coverage solution.

[0370] In a related embodiment that may be combined with other embodiments related to parameters exchanged before PAKE is performed, in steps 3, 6, and 9, several parameters need to be exchanged before PAKE is performed. These parameters may include a relay service code or a "password hint" that identifies the "original password". In the absence of an explicit password hint, the RSC acts as a password hint, i.e., the password is linked to the RSC. In particular, reference Fig.17b , the DCR message in step 1721 includes the RSC and password prompt of PAKE in steps 1726 and 1729; the DCR message in step 1722 includes the RSC and password prompt of PAKE in steps 1723 and 1729. When the UE-to-UE relay receives the message of step 1721, the UE-to-UE relay may delete the password prompt of PAKE in step 1726. In addition, in step 1722, the UE-to-UE relay adds the password prompt it uses for PAKE to the DCR message. When the target UE receives the message in step 1722, the target UE initiates PAKE in step 1723 based on the received password prompt.

[0371] In a related embodiment that may be combined with other embodiments involving PAKE execution, this embodiment illustrates how to execute PAKE in the context of SPAKE2 and SPAKE2+ involving the exchange of four messages. The first PAKE message and the second PAKE message are exchanged in the Direct Authentication and Key Establishment Request and Direct Authentication and Key Establishment Response messages in TS 33.536, respectively. The third message and the fourth message are exchanged in the Direct Security Mode Command and Direct Security Mode Complete, respectively, in TS 33.536.

[0372] In a related embodiment, as described in clause 5.3.3.1.2.1 of TS 33.536, the term long-term credentials may also refer to a password used in PAKE.

[0373] In a related embodiment, which may be combined with other embodiments relating to the secure exchange of data, the secure exchange of data relies on a shared key Ks between the two UE results of PAKE. This key Ks is K_shared defined in SPAKE2 or TT defined in SPAKE2+. For L2 UE to UE relaying, Ks is used as a shared key to derive PC5 keys for user / control plane and encryption / integrity through a key derivation function according to TS 33.220. For L3 UE to UE relaying, Ks is used to derive PSK hint and PSK. PSK and PSK hint are used in IKE-PSK to protect L3 communications through a key derivation function according to TS 33.220.

[0374] In general, a method and apparatus that can be implemented in a device are described for performing a second PAKE-based SEP between a first device and a third device through a relay device. A method and apparatus related to the foregoing method and apparatus are further described for performing a first PAKE-based SEP between a first device and a relay device, and if successful, authorizing the performance of a second PAKE-based SEP.

[0375] Personal IoT Network

[0376] Fig.16 The signaling and processing diagram of a personal IoT network (PIN) scenario according to an embodiment is schematically shown. Fig.16In the scenario of , a PINE source device (PINE-S), a PEGC and / or PEMC, and a PINE target device (PINE-1) 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, ultimately forming a 3D environment in which the user appears to be immersed when browsing or experiencing it, the target PINE device may be a smart TV, and the PEGC / PEMC may be a mobile phone (UE). These three devices may need to obtain connectivity / services from a core network (CN) through a radio access network (RAN). These three devices may also require units for secure communication between each other. To this end, the devices may initially be configured in steps 1601, 1602, and 1603 (as described above in conjunction with steps 1501 to 1503). The PINE source or target device may not be configured directly by the CN because it may not support 3GPP RAN; instead, they may be configured by an application function (AF) through the CN, or by the CN if the device is a device that supports 3GPP RAN. The configuration may involve security keying material (eg, PC5 discovery keying material in accordance with TS 33.503 associated with PAKE) or other embodiments described herein, or communication parameters such as QoS, required communication resources and maximum latency.

[0377] In step 1604, the PINE source device and the PEGC and / or PEMC may set up an underlying communication channel, such as a Wi-Fi channel. The PINE source device may then be triggered to enter a password, such as via a keyboard or by scanning a QR code (step 1605). The password may be generated by the PEGC and / or PEMC and may be displayed on the screen. The password may also be derived via a KDF based on a master key on the PEGC and / or PEMC (e.g., the UE's master key used in initial authentication). The source PINE device and the PEGC / PEMC may then exchange preambles / PAKE messages / SEPs in steps 1606 and 1607 in the above embodiment, thereby generating a secure and authenticated channel. In step 1608, the PEGC / PEMC may allow the source PINE device to use 5GC communication resources. This step may involve an authentication process with an AAA server, such as in an application function (AF), which will notify the PEGC / PEMC of the result.

[0378] In an additional variation, in step 1604, the PINE source device and the PEGC and / or PEMC may set up an underlying communication channel, such as a Wi-Fi channel. The PEGC / PEMC may then be triggered to enter a password, such as via a keyboard or scanning a QR code, such as attached to the PINE source device. This password may be provided by the 5CN or a third party on the PINE. The source PINE device and the PEGC / PEMC may then exchange preamble / PAKE / SEP messages in steps 1606 and 1607 of the above-described embodiments, thereby generating a secure and authenticated channel and utilizing the CN 1608 for initial access to the CN or AF. In addition, prior to this step 1608, upon successful establishment of a secure and authenticated channel in 1607, the PEGC / PEMC may securely receive further security information from the PINE source device, such as a digital certificate allowing the PEGC / PEMC to verify the identity of the PINE source device. The digital certificate may be verified by the PEGC / PEMC or forwarded to the CN or AF for verification. In the first case, the PEGC / PEMC can allow the PINE source device to access the CN or use the AF of the CN. In the second case (CN or AF performs authentication), the CN or AF will send a confirmation message to the PEGC / PEMC to allow / disallow the service from the PINE source device. Accessing this AF using the CN can be performed through the network exposure function (NEF). It should be noted that step 1608 can access the AF through some specific network resources (e.g., network resources specific to the target AF). For example, the goal of the AF may be to create a personal IoT network that all devices can access. Therefore, the successful PINE source device in steps 1606, 1607 and 1608 can be allocated connection resources that match the AF requirements (e.g., IP address, communication resources that ensure a certain reliability / latency). The resources allocated to the PINE upon successful authentication / authorization in step 1608 may depend on:

[0379] In step 1602, based on the policy configured by the user subscription, and / or

[0380] The communication requirements of the PINE that may be configured in the PEGC / PEMC in step 1608, and / or

[0381] Take into account the amount of available resources of other PINE devices connected to the PEGC / PEMC.

[0382] It should be noted that the initial configuration in steps 1601, 1602 and 1603 may be done by an external AF through or via the CN. The initial configuration may include, for example, the distribution of SEP / PAKE related information in an enhanced PAKE or information that allows subsequent credentials (e.g., digital certificates) received from a PINE source device to be verified when establishing a secure channel (e.g., with the aid of a SEP or a PAKE-based SEP). The initial configuration may also include a communication strategy for the PINE or a communication strategy for the PEGC.

[0383] In step 1609, a password / credential may be entered / provided / used in a PINE source device, and in step 1610, such credentials may be exchanged with another PINE target device via PEGC and / or PEMC. Figure 3 or Fig.14 and the preamble message in the above embodiment (equivalent to the discovery message). PEGC / PEMC may only allow services originating from PINEs that have been authenticated / authorized in the previous step. In step 1611, the same password may be made available to the device. Based on the (preamble) message in step 1610 and the shared password, both the source PINE device and the target PINE device may run PAKE as in step 1612 in the above embodiment, thereby bringing about a secure communication channel between the PINE devices in step 1613.

[0384] exist Fig.16 In the CN, the CN may include several network functions, including for example AMF, SMF or UPF. The UPF may interact with PIN-related AFs located in or outside the CN. Configuration parameters may be provided / configured by, for example, the PCF, UDM or UDR.

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

[0386] In additional variations, a PINE device (e.g., Fig.16The PINE target in the 5G CN supports a cellular interface, and therefore, it is feasible to configure the device on a cellular interface (e.g., a Uu interface or a PC5 interface), for example, in step 1601. The initial configuration includes configuration parameters for setting up the PC5 interface, for example, discovering security material as described in TS 33.503. The initial configuration also includes PIN configuration information. This information can be provided, for example, by the AF once the PINE (e.g., the PINE target) has established a secure connection with the 5G CN (e.g., at the time of initial authentication) with the help of an AKMA derived key that can allow authentication / authorization procedures to be performed between the PINE and the AF. This initial security PIN configuration can be performed on the Uu or PC5 interface. This initial PIN configuration can be performed before the PINE device attempts to join a PIN. If the PIN configuration is successful, the PEGC / M is also instructed / configured to route communications between the PINEs, for example, steps 1610, 1612 and 1613 may need to be routed through the PEGC / PEMC, where the communication link between the PINE source and the PEGC / PEMC may be based on a first communication protocol (e.g., WiFi), and the communication link between the PINE target and the PEGC / PEMC may be based on a second cellular communication protocol. The configuration may be pulled by the PEGC / PEMC or pushed by the PIN AF. Thus, the PEGC / PEMC may be configured by the 5GC with a configuration policy that determines that certain PC5 services (e.g., at the MAC or PDU session or IP layer) will be routed to different networking interfaces, for example, WiFi or BLE or IEEE802.15.4 networking interfaces.

[0387] In additional variations, a PINE device (e.g., Fig.16 A PINE target in a cellular interface can support a cellular interface. Such a PINE device can use unregulated spectrum and therefore may not always need to rely on resource allocation from the RAN.

[0388] In additional variations, a PINE device (e.g., Fig.16 PINE target in the PC5 discovery message) can establish a secure channel with the PEGC / PEMC by using a SEP (e.g., a PAKE-based SEP at the application layer), where the PAKE-based SEP message can be transmitted, for example, in the metadata field of the PC5 discovery message or in other PC5 messages.

[0389] In an additional variation, step 1608 may involve a (mutual) authentication process between the PINE and the AF / 5GC.

[0390] In a related variation, the PIN AF may play the role of or include the functionality of an AAA server.

[0391] In a related variation, the following operations may occur.

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

[0393] In phase 2, if this initial (initial) authentication is successful, the UE may request communication with a certain PIN AF; or the CN (e.g., AUSF) may check subscriber preferences, e.g., related to PIN management. In this case, the CN may authorize the UE, and the UE and PIN AF may set up secure communication, e.g., using a K_AF derived from K_AKMA as in TS 33.535;

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

[0395] In phase 4, for example, if the authentication / authorization succeeded in phase 3, the AF may inform the CN (e.g., AUSF or AUSF through AaNF or other NF) of the UE status and may provide some configuration parameters related to, for example, PIN communication requirements, membership, etc. that the UE must use in its role of PEGC / PEMC. The CN (e.g., AUSF) may store this information in a database, for example, in the UDM (UDR). The CN (e.g., AUSF) may check the received configuration against the user subscription and verify that the received configuration satisfies the user subscription. Due to the new status of the UE (active PEGC / PEMC), the billing information may also be updated.

[0396] In stage 5, the CN (e.g., AUSF to AMF) may inform (e.g., using NAS messages) the UE of its confirmed role as a PEGM or PEMC. The CN may also inform the UE about any specific PIN configuration information, for example shared by the PIN AF and / or verified for user subscription. The CN may also configure the UE with policies and configuration parameters to route PIN-related data (e.g., data originating from a PINE) to the AF using predefined networking resources. The CN may also configure the UE with policies that determine how / whether to route data within the PIN or what data within the PIN to route, for example, from a non-cellular PINE device to a cellular PINE device / from a cellular PINE device to a non-cellular PINE device. Additionally or alternatively, some of the above information may also be sent by the AF. The UE configuration / policy that determines whether to route data for a PINE device means that the configuration can be used to authorize communication for the PINE device.

[0397] In stage 6, the AF may also configure the PEGM / PEMC with other configurations, eg related to PIN parameters.

[0398] For example, in Fig.16 In step 1602, some of the stages 1-6 may be included. They are similar to the security process of PEGC / PEMC through which the UE can become a PIN.

[0399] 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 may:

[0400] a) Setting up a secure channel between the UE and the PINE, for example, using a SEP (eg, a PAKE-based SEP or a protocol of a PINE-based wireless communication technology).

[0401] b) Access to the AF is given based on the configuration or other parameters received in Phase 5 or Phase 6. This access may be time-limited while waiting for the CN or AF to confirm a successful authentication process between the PINE and the AF. This access may be based on specific communication resources that the CN may monitor to ensure PIN subscription compliance.

[0402] Stage 7 may correspond to Fig.16 Steps 1604-1607 in .

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

[0404] In stage 9, if the authentication / authorization between the PINE and the AF is successful in step (8), the AF notifies the CN (e.g., AUSF) of the new PINE, the successful authentication status, and the PINE requirements. The AUSF adds information about the PINE to the UDM (UDR). Due to the new status of the PIN (new PINE), the billing information may also be updated. The CN may then notify the UE of the successful authentication of the PINE and any configuration information provided by the AF. The CN may also use NAS messages - utilizing communication policies to provide PEGC / PEMC - to route data initiated in the PINE using specific communication resources or specific identifiers. Additionally or alternatively, the AF may provide the previous information to the UE (e.g., using a secure channel protected by K_AF (or a key derived therefrom). The UE then notifies the CN, for example, by means of a NAS message to the AMF and then to the AUSF.

[0405] In phase 10, the UE may obtain or have obtained an identifier from the PINE (scanning a QR code, entering an ID, ...) for identification purposes. This identifier may also be shared with the AF in a secure manner, for example in step 8. This identifier or an identifier derived therefrom (e.g. with the aid of a KDF) may be shared with the CN for identification purposes of the PINE.

[0406] In stage 11, the UE-related PINE key (K_PINE) can be derived, for example:

[0407] Based on the K_AUSF including the identifier as input in the KDF.

[0408] • Depending on the current K_AF, include the identifier as input in the KDF.

[0409] Provided by the AF

[0410] The AF may send the PINE key to the PINE in a secure manner (application layer) based on the secure link established at authentication / authorization, e.g. in step (8). Additionally or alternatively, the UE may share it. Additionally or alternatively, the CN and UE may also generate K_PINE if they derive it from K_AUSF or K_AF.

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

[0412] In phase 12, K_PINE may allow actions such as:

[0413] The CN / UE sends certain commands to the PINE.

[0414] The PINE establishes a secure channel with the UE / CN, so that the PINE can exchange messages with the PEGC / PEMC securely.

[0415] The PINE sends certain messages to the CN in a secure manner.

[0416] PEGC / PEMC sends messages to PINE. The messages are generated locally in PEGC / PEMC or forwarded from other PINEs or AFs.

[0417] For example,

[0418] Whenever PINE sends a message to AF through PEGC, PINE can attach a token based on K_PINE.

[0419] • For example, if K_PINE is a symmetric key, the token can be a MIC based on K_PINE, where the MIC can be calculated over the message or can be calculated over a parameter that allows verification of the freshness of the message (e.g., a UTC-based counter).

[0420] • For example, the token may 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.

[0421] For example, this K_PINE can be used to (mutually) authenticate an IKEv2 IKE based tunnel setup between PINE and PEGC / PEMC so that all exchanged traffic is protected.

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

[0423] Some of the stages 8-12 may be included in Fig.16 In step 1608. They are similar to the authentication and authorization process of PINE.

[0424] Fig. 20 A schematic diagram of the above stages is provided, where:

[0425] In Phase 1, initial authentication may be performed between the UE (PEGC / PEMC) and the CN;

[0426] In phase 2, the UE (or an application on it) may request a PIN for access to the CN or AF through the CN. This may be done via the AKMA (TS 33.535) and the AnAF. In this case, the K_AKMA is used to derive the K_AF and PIN for a specific UE. Alternatively, a different anchor function specific to the PIN may be used, such as an anchor PIN function (AnPF) responsible for PIN key and device management (PKaDMA), e.g., managing the K_PKMA. For example, the K_PKMA may play a role similar to the K_AKMA, but specific to the PIN of which the UE is a member / responsible. The K_PKMA may be derived in a similar manner to the K_AKMA, i.e. from the K_AUSF, but using other parameters (e.g., a bit string identifying the PKaDMA) as input parameters in the KDF. The K_PIN may be derived from the K_PKMA, similar to what is done for the K_AF, e.g., using as input an identifier identifying the PIN. This allows support for more than a single PIN. It may be feasible to derive the K_PINE from the K_PIN or from the K_PKMA, as explained above, a key specific to a given PINE. Having a different NF AnPF is advantageous because its PIN range is different from that of AnAF and allows placing all PIN functionalities in an isolated NF.

[0427] In phase 3, the UE and AF may perform authentication and authorization steps. This step may be based on the keys distributed in phase 2. In phase 4a, the AF may inform the CN of the results of phase 3 and provide the CN with a configuration. The configuration may include information about: PIN identifier, PIN purpose, PIN element, PIN element capabilities, communication requirements such as QoS, allowed interactions between PINs, etc. In phase 4b, the CN may store the configuration, for example in the UDR or in the AnPF.

[0428] In phase 5a, the CN may inform the UE of the results of phase 4, and may provide the UE with a configuration. The configuration may be based on the configuration exchange in phase 4, and it may include relevant. The configuration may include rules (e.g., as required in phase 7c) for implementing the authentication and authorization process for the PINE (as in phase 8). The configuration may include an "authorization token" for the specific PINE as described above. In phase 5b, the UE may store the configuration. The configuration received from the CN relates to the communication parameters assigned to the PIN.

[0429] - In phase 6, the AF may inform the UE of the result of phase 4 and may provide the UE with configuration, e.g. key material such as certificates, passwords etc. This configuration received from the AF may concern application-related aspects of the PIN assigned by the AF.

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

[0431] Phase 7a may be based on a SEP as in the above embodiments, such as PAKE or another protocol such as the Device Provisioning Protocol (DPP) or Wi-Fi Easy Connect TM The advantage of using PAKE or DPP is that the communication links are individually protected.

[0432] In Phase 8, PINE and AF may perform authentication and authorization steps.

[0433] In stage 9a, the AF may inform the CN of the results of stage 8 and may provide the CN with a configuration related to the PINE. In stage 9b, the CN may store the configuration. In stage 9c, the CN may inform the PEGC / PEMC of the results of stage 8 and may provide the PEGC / PEMC with a configuration for the PINE. In stage 9d, the PEGC / PEMC may store the configuration. The configuration received from the CN may relate to communication parameters assigned to the PINE.

[0434] In phase 10, the PINE and PEGC / PEMC may receive an "Authorization Token" from the CN. The PINE may receive it via the AF. The goal of this "Authorization Token" is to ensure that only authenticated / authorized PINEs can communicate with / through the PEGC / PEMC.

[0435] - In phase 11, data may be exchanged between PINE / PEGC / PEMC using the authentication token for authentication and / or authorization.

[0436] and Fig. 20 Relatedly, stages 1-6 may correspond to the PEGC / PEMC authentication and / or authorization process. Stages 7-11 may correspond to the PINE authentication and / or authorization process. These processes may be used together, but they may also be implemented independently.

[0437] The message "PIN Access Request" in phase 7b is a message that the PINE can send to the UE acting as PEGC / PEMC over different lower layers (such as Wi-Fi and PC5). Receipt of this message gives an indication to the UE of the request to join the PIN. This message can be the initial message of phase 8 (PINE authentication and authorization). This message can advantageously include an identifier of the target PIN, for example an identifier associated with the PIN.

[0438] A PINE may send a "PIN Access Request" upon receiving a "PIN Advertisement" message. This is a message sent / broadcasted by the UE announcing its PIN capabilities. The message may also include additional information that allows the PINE to determine if the correct PIN is to be joined. The message may include an identifier for the PINE so that the PINE knows that the UE is trying to connect to it. A PINE may send a "PIN Access Request" upon certain out-of-band interactions (e.g., scanning a QR code displayed by the UE).

[0439] In a variation of this step, since the PIN element can establish a connection to the PEMC and PEGC using a local interface (PC5, WLAN or Bluetooth, etc.), and can ultimately be authorized to join the PIN by the PEMC, the PEMC / PEGC may need to determine / specify policies or configurations for one or more of the following:

[0440] - Types of devices that are allowed to join the PIN,

[0441] - the type of interaction between authorized devices (e.g., 3GPP and non-3GPP devices) (authentication with AF, communication PINE-AF, communication between PINEs, etc.),

[0442] - the conditions under which the interaction / communication is authorized (time, location, context, etc.),

[0443] -PINEThe types of allowed lower layers that can be used in PIN,

[0444] - devices that allow joining PIN,

[0445] - Type of authentication process, e.g. based on 1) scope (local, end-to-end, etc.), 2) type (e.g. matter-based, DPP-based, etc.) to support PINE authorization,

[0446] - Credentials used to verify the authorized PINE,

[0447] This policy can be configured in the following ways:

[0448] -AF or

[0449] -NF in 5GS or

[0450] - Locally in the PEGC / PEMC (eg, by means of a UI).

[0451] In a variation of this step, the PEGC / PEMC may adjust the access decision of the PINE based on the configuration or policy.

[0452] In a variation of this step, this strategy can be applied to step 3 of solution 8 in TR 33.882 v0.4.0.

[0453] Phase 8 is the authentication and authorization step. This can be done based on an application layer protocol, a secondary authentication, or it can also be relayed on a peer, a pass-through authenticator and a backend authentication server architecture and use an EAP protocol similar to that in clause 6.1.1.2 in TS 33.501. The peer is the PINE, the authenticator can be a UE (representing 5GS), and the authentication server is the AF. The peer sends EAP messages via a (wireless) communication technology between the PINE and the UE, such as EAP over LAN or EAPOL. The UE, acting as an authenticator, then exchanges EAP frames with the authentication server (i.e., the AF) (e.g., directly or encapsulated in a protocol such as diameter).

[0454] Fig.19The schematic provides different views of the elements in a personal IoT network (PIN), similar to Fig.16 . Fig.19 The components in are as follows:

[0455] Device 1901 is a non-cellular device that is not part of the PIN.

[0456] Device 1902 is the non-cellular device portion of the PIN.

[0457] Device 1903 is a cellular device capable of managing PINs (ie, PEMC).

[0458] Device 1904 is a cellular device capable of acting as a gateway for a PIN (ie, a PEGC).

[0459] Device 1905 is the cellular PINE device portion of the PIN.

[0460] Device 1906 is a communication link between device 1903 and device 1904 .

[0461] Device 1907 is a cellular access device, such as a gNB.

[0462] Device 1908 is the AMF in the CN.

[0463] Device 1909 is an AUSF in the CN.

[0464] Device 1910 is a NF in CN, such as UDM, UDR, AKMA, UPF, PCF, NEF, AF, etc.

[0465] Element 1911 is CN.

[0466] Element 1912 is the AF responsible for managing the PIN.

[0467] Network 1913 is a PIN including 1902, 1905 and 1920.

[0468] Link 1914 is a non-cellular communication link between 1920 and 1902 .

[0469] Link 1915 is a cellular communication link between 1905 and 1920 (eg, PC5).

[0470] Link 1916 is a cellular communication link (eg, Uu) between 1920 and 1907 .

[0471] Link 1917 is a communication link that interfaces 1907 and 1911 or the network functions therein.

[0472] Link 1918 is the communication link between 1911 and 1912.

[0473] Network 1919 is a non-cellular network.

[0474] Device 1920 is a device including the functions of 1905 and 1906 .

[0475] Device 1921 is a non-cellular device that manages or grants access to a non-cellular network.

[0476] exist Fig.19 , it can be seen that device 1920 is part of 1919, e.g., it has joined the network and has credentials, such as a security key. Since device 1920 is part of network 1919, device 1920 can also communicate with device 1902 (part of network 1919) via link 1914. Device 1902 also has joined network 1913, where device 1920 manages the authentication / authorization process on behalf of element 1911 or 1912 in order to access network 1913 and link 1916 or 1915. When device 1902 needs to communicate with device 1905, or vice versa, the communication is routed through device 1920, where device 1920 receives policies from element 1911 or element 1912 that determine which communication flows are allowed to be rerouted. In . Fig.19 In the embodiment, device 1921 manages network 1919, and device 1920 is part of network 1919. This means that device 1920 also first joins network 1919. Alternatively, device 1920 may include the functionality of device 1921. In this case, device 1921 first handles which devices join network 1919, and then which devices join network 1913. When device 1920 accepts a new device in network 1913, device 1920 may notify other devices of the newly joined device.

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

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

[0479] Performing SEP (e.g., DPP, PAKE-based) between a first device and a second device (e.g., non-cellular PINE), thereby allowing initial establishment of a secure and authenticated channel with the second device over a first communication link (e.g., Wi-Fi);

[0480] routing further authentication messages through the 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 is over the second cellular backhaul communication link;

[0481] Receiving, at the first device, from the third device, an authorization confirmation and / or an authorization configuration, the authorization confirmation and / or the authorization configuration determining access rights of the second communications device to at least one of:

[0482] o access to the first device network;

[0483] o accessing the second cellular backhaul communication link (eg, Uu interface);

[0484] o with a fourth device (e.g., cellular PINE) connected to the first device via a cellular communication link (e.g., sidelink / PC5)

[0485] to communicate.

[0486] In at least some of the above embodiments, the PAKE may be a balanced or enhanced SPAKE2+ or a different PAKE.

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

[0488] In at least some of the above embodiments, the password (PWD) may be a concatenation of a (short) shared symmetric key and metadata that determines the validity of the password and the communication link, e.g. how long it is valid and which access rights it relates to. For example:

[0489] PWD=K|metadata,

[0490] The metadata may include access policies or access roles. It should be noted that this method can be used with other PAKE schemes. In some cases, it may be necessary to apply a function to the input K|Metadata, such as PBKDF or other functions.

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

[0492] The proposed technique has advantages over alternative techniques that can be used to grant authentication and authorization. For example:

[0493] If a conventional access token is used, the initiator and responder may first establish a secure channel, for example, using the Diffie-Hellman (DH) algorithm (which is a key exchange protocol that enables two parties to communicate over a public channel to establish mutual secrets without sending them over the Internet). The initiator may then send an access token to the responder. The access token may contain information asserting the initiator's access rights and may be signed by an issuer that the responder trusts. This scheme may require digital signatures and may still be vulnerable to man-in-the-middle (MitM) attacks. In contrast, the proposed scheme resists MitM attacks and does not require digital signatures.

[0494] If the Initiator and Responder rely on PWD=K|metadata to perform symmetric key mutual authentication and key agreement protocols. This can expose which passwords are assigned to which devices and therefore expose their identities. In addition, if the same password is assigned to a third device as the Initiator and Responder, the third device can access the communication link between the Initiator and Responder.

[0495] In some of the above embodiments, one of the messages in the preamble or PAKE may include a password hint that indicates to the recipient which password or password-based information to use (e.g., referring to enhanced PAKE, for example, in SPAKE2+ the password-based information refers to the verification value pair L and w0). In this case, if the password has been configured, for example, by a central authority such as 5G CN, or if the user is not sure which password to use, or if the user is not sure which QR (containing the password) to scan, the device may indicate it using a password hint so that the other party knows which password to retrieve after performing PAKE and use to authenticate the other party. Successful authentication may imply verification of the password and metadata. For example, the password hint may be obtained as a function (e.g., KDF or hash) of the password and additional parameters (such as salt values, random numbers, counters, etc.), as shown below:

[0496] PWD_Hint = KDF (PWD | additional parameters)

[0497] PWD_Hint = Hash(PWD|AdditionalParameters)

[0498] PWD_Hint = HMAC (PWD | additional parameters),

[0499] Or the password hint can be a randomly generated bit string associated with the password.

[0500] In at least some of the above embodiments, the password may include at least two passwords. A first password provided by the central management entity to the two communicating parties authorizes the establishment of a communication channel, and a second password entered by the user enables the user to authorize the setup of a secure communication channel.

[0501] PWD=PWD1|PWD2

[0502] In some of the above embodiments, two PAKEs may be performed in parallel, the first password PWD1 being used in a balanced PAKE, where the password may be determined, for example, by the users involved, and the second password PAWD2 being used in an enhanced PAKE, where the password may be determined by network / system management. Executing PAKE in parallel means that PAKE messages may be sent simultaneously, thereby reducing the number of round trips. In similar PAKEs, steps or operations may be combined. This has the advantage that users may enter their own passwords to authorize communications, while the network / system may distribute passwords to the devices involved during an initial configuration phase, for example to authorize a communication link, such as a first device (e.g., an initiator) communicating with a second device (a responder).

[0503] In at least some of the above embodiments, a central authority (e.g., 5GS) may support authorization of a UE to act as a UE-to-UE relay in a UE-to-UE relay scenario.

[0504] In at least some of the above embodiments, a central authority (e.g., 5GS) may support authorization of a UE as a source UE or a target UE in a UE-to-UE relay scenario.

[0505] The fact that PAKE can be enhanced is a useful feature because if the responder or verifier is compromised, the best way for an attacker to act as an initiator or client is to mount an offline attack. This allows the central management party to deploy passwords PWD as described above, i.e., K|metadata that can be used by the client to show its authenticity and authorization, for example, to show that it is authorized to act as a source UE to a target UE. The central management party can create, for example, two types of passwords / keys: K_S and K_T. K_S can be provided to UEs that can only act as sources, and K_T can be provided to UEs that can only act as targets. The counter part of those passwords / keys can be provided to the other party, for example, a target device that can only act as a target is provided with a function of a bit string that is difficult to reverse (in a security sense) derived from K_S (and metadata). It should be noted that if a balanced PAKE is used, the central management party may also be able to assign passwords / keys to a pair of devices that authorize them to communicate with each other.

[0506] In some of the above embodiments, one of the devices (e.g., the responder device) may also retrieve or request a password (or a password-based value in enhanced PAKE) from such a central authority, for example, upon receiving a preamble message containing a password prompt. To do this, the device may need to share certain parameters with the central authority, such as a password prompt or exchange parameters to be used in PBKDF. In the case of a password-based value in enhanced PAKE, this has the advantage that the responder device can perform subsequent key exchanges, such as PAKE, with the initiator device on behalf of the central authority without the need for an access password. Since the password-based value may depend on the exchange parameters to be used in PBKDF, the validity of the value is limited. Only when the process is successful can the responder allow the initiator to perform certain operations, such as access to networking resources, a 5G core network, or application functions accessed through the 5G system.

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

[0508] In summary, methods and apparatus for setting up a secure communication channel using improved key exchange for SEP have been described.

[0509] Although the present invention has been shown and described in detail in the drawings and the foregoing description, such illustration and description should be considered illustrative or exemplary rather than restrictive. It should be understood that the embodiments can be combined and that the features of any one of the embodiments can be used in combination with another embodiment. The present invention is not limited to the disclosed embodiments. The proposed enhancements to SEP (such as SPAKE2+ or SPAKE or PAKE in general) can be implemented in all types of wired or wireless networks, for example, it can be applied to devices or applications that communicate using cellular wireless communication standards, in particular the Third Generation Partnership Project (3GPP) 5G and New Radio (NR) specifications. The communication device or application can be different types of devices, such as mobile phones, smart watches, smart tags for location tracking and logistics, commissioning devices, applications or tools, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, IoT hubs, IoT devices including low-power medical sensors for health monitoring, medical (emergency) diagnostic and treatment devices for hospital use or first responder use, virtual reality (VR) headsets, etc., and can be used, for example, in personal IoT networks (PINs) and / or with ProSe focused on UE to UE.

[0510] Furthermore, the proposed enhancements to SPAKE2+ or PAKE in general or other SEPs may be used for applications such as Wi-Fi, cloud access, browser synchronization, e-passports, Thread network protocols for IoT devices, for PAKE standards developed by standards development organizations (SDOs) such as IEEE, ISO / IEC or IETF, for IEEE 802.11 protocols and WiFi Protected Access (e.g., WPA3, e.g., associated with Simultaneous Authentication with Equalizer (SAE)), for transport layer security protocols (e.g., TLS1.3) or Internet Key Exchange (e.g., IKEv2).

[0511] Although ProSe relay and sidelink communication have been mentioned, the present invention is also applicable to other types of relay devices, such as proximity services involving direct communication between two UEs, proximity services involving UE to network relays, ranging services, such as (smart) repeater devices, integrated access and backhaul (IAB) nodes, or Wi-Fi mesh APs. In addition, the techniques mentioned here can also be applied to other procedures, for example, to solve the key issues identified in TR 33.893v0.2.0 for the ranging procedure.

[0512] In addition, the present invention can be applied to medical applications or connected healthcare involving multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes, to medical applications or connected healthcare in which wireless (e.g., 4G / 5G) connected devices occasionally consume or generate continuous data streams of a certain average data rate, such as video, ultrasound, X-ray, computed tomography (CT) imaging equipment, real-time patient sensors, audio or voice or video streaming devices used by medical personnel, to general IoT applications involving wireless, mobile or fixed, sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.), to emergency services and critical communications applications, to V2X systems, to systems for improved coverage of 5G cellular networks using high-frequency (e.g., millimeter wave) RF, and to any other application areas of 5G communications using relays.

[0513] Other variations to the disclosed embodiments may be understood and implemented by those skilled in the art in practicing the claimed invention by studying the drawings, the present 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 details certain embodiments of the invention. However, it should be understood that, regardless of how 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 specific terms when describing certain features or aspects of the invention should not be taken as implying that the term is redefined herein to be limited to include any specific characteristics of the features or aspects of the invention associated with the term.

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

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

[0516] As in Figures 1 to 3 and Figures 5 to 13 Those operations indicated in can be implemented as program code units of a computer program and / or dedicated hardware of a debugging device or lighting device, respectively. The computer program can be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with other hardware or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. A device for controlling a security establishment process between a first communication device (A) and a second communication device (B) on a transmission link, wherein: The device is suitable for: placing in a preamble message (Pre_AB) information about a reliability setting (REL A) to be applied by said first communication device (A) for communicating with said second communication device (B); as well as In a preamble phase prior to the security establishment procedure, the preamble message (Pre_AB) with information on the reliability setting (REL A) is sent to the second communication device (B).

2. A device for controlling a security establishment process between a first communication device (A) and a second communication device (B) on a transmission link, wherein: The device is suitable for: receiving a preamble message (Pre_AB) from the first communication device (A) in a preamble phase prior to the security establishment procedure, the preamble message (Pre_AB) comprising information about a reliability setting (REL A) to be applied by the first communication device (A) for communicating with the second communication device (B); as well as Based on the received information about the reliability setting (REL A) of the first communication device (A) and the own reliability setting (REL B) of the second communication device (B), a reliability setting for an application communicating with the first communication device (A) is selected.

3. The apparatus according to claim 1 or 2, the reliability settings (REL A, REL B) comprising at least one reliability parameter defining at least one item selected from the group of retransmission capability or timeout value.

4. The device according to claim 3, wherein: The retransmission capability or the timeout value allows at least one item to be selected from the following group: a group indicating that a message is reliable and requires confirmation by the receiver, which includes information indicating that the message serves as an confirmation for the identified previous message, and includes a maximum number of retransmissions required for a message.

5. An apparatus according to any preceding claim, wherein: The first communication device (A) comprises a debugging tool configured to use the security establishment procedure to interact with the second communication device (B) to perform at least one selected from the group of debugging, configuration, authentication and authorization.

6. An apparatus according to any preceding claim, wherein: The second communication device (B) is included in a medical device or a personal healthcare device or a smart home device.

7. An apparatus according to any preceding claim, wherein: The apparatus is configured to run a password authenticated security establishment protocol to mutually authenticate the first communication device (A) and the second communication device (B) to each other and establish a secret.

8. An apparatus according to any preceding claim, wherein: The preamble message (Pre_AB) is exchanged between the first communication device (A) and the second communication device (B) or between the first communication device (A) or the second communication device (B) and a relay device in an initial device discovery phase.

9. An apparatus according to any preceding claim, wherein: The preamble message (Pre_AB) comprises a dedicated field for signaling information about the reliability setting (REL A).

10. An apparatus according to any preceding claim, wherein: The device is suitable for selecting the reliability setting to be applied so that the highest reliability among the reliability settings (REL A, REL B) received from the corresponding devices (A, B) is adopted, or the lowest reliability among the reliability settings (REL A, REL B) received from the corresponding devices (A, B) is adopted, or the received reliability setting (REL A) is applied.

11. An apparatus according to any preceding claim, wherein: The apparatus is adapted to pre-configure a set of possible configurations of parameter settings, and wherein the information about the reliability settings identifies a selected configuration.

12. An apparatus according to any preceding claim, wherein: The arrangement is adapted to use parameters configured by the third communication device during an initial configuration phase.

13. A communication device (40) comprising the apparatus according to any one of claims 1 to 12.

14. A method for controlling a security establishment process between a first communication device (A) and a second communication device (B) on a transmission link, wherein: The method comprises: placing in a preamble message (Pre_AB) information about a reliability setting (REL A) to be used by the first communication device (A) for communicating with the second communication device (B); and In a preamble phase before the security establishment procedure, a preamble message (Pre_AB) with information about the reliability setting (HF_SUPP) is sent to the second communication device (B).

15. A method for controlling a security establishment process between a first communication device (A) and a second communication device (B) on a transmission link, wherein: The method comprises: receiving a preamble message (Pre_AB) from the first communication device (A) in a preamble phase prior to the security establishment procedure, the preamble message (Pre_AB) comprising information about a reliability setting (REL A) to be applied by the first communication device (A) for communicating with the second communication device (B); and Based on the received information about the reliability setting of the first communication device (A) and the own reliability setting (REL B) of the second communication device (B), a reliability setting of an application for communicating with the first communication device (A) is selected.

16. A computer program product comprising code means for producing the steps of claim 14 or 15 when executed on a computer device.

17. A system comprising two or more communication devices according to claim 13.

Images