Method for joining communication network

Abstract

The present invention relates to an apparatus for verifying information sent to a second device, the apparatus comprising: a memory adapted to store information and a transceiver adapted to send and receive messages wherein the apparatus is configured to send a first message with said information to said second device, wherein the device is configured to receive a verification challenge from the second device, and wherein the apparatus is adapted to calculate and send a response to the second device based on the verification challenge, a key material shared between the first device and the second device, and information exchanged in the first message.

Description

Technical Field

[0001] The present invention relates to security applications, in particular to security methods for joining and communicating in a communication network, such as - but not limited to - a cellular network. Background Art

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

[0003] In the context of cellular networks standardized by 3GPP, the primary station is called a base station, or a gNodeB (or gNB) in 5G (NR) or an eNodeB (or eNB) in 4G (LTE). The eNB / gNB is part of the radio access network RAN, which interfaces with functions in the core network (CN). In the same context, the secondary station corresponds to a mobile station or user equipment (or UE) in 4G / 5G, which is a wireless client device or a specific role played by the device. The term "node" is also used to refer to a UE or a gNB / eNB.

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

[0005] The secondary station performs an initial authentication process with the core network to authenticate each other and establish an initial security context. The core network also provides a unit for the secondary station to establish a secure communication link with the application function. New access networks are also being designed and deployed to enable secondary stations to access the core network through non-terrestrial networks by using mobile primary stations or intelligent repeaters that extend the range of primary stations.

[0006] The network access protocol may be vulnerable to man-in-the-middle attacks or overshadow attacks. A man-in-the-middle (MitM) attacker is an attacker that is placed between the primary station and the secondary station and is able to forward, modify, inject or drop messages. In an overshadow attack, the attacker injects a signal that modifies the message received by the receiver. Several specific attacks that a MitM can perform are described in the literature. For example, a MitM may be able to modify the security capabilities of a secondary station. Security capabilities may include confidentiality or integrity algorithms supported by the UE or preferred by the UE, such as the New Radio Integrity Algorithm (NIA) or the New Radio Encryption Algorithm (NEA) in 5G. By modifying the preferred or supported security capabilities, a MitM can be managed to trigger different types of attacks, such as a SUPI capture attack or an IP spoofing attack.

[0007] Based on the authentication and key agreement phase between the secondary station and the core network, a master key can be derived and stored at the network function (e.g., 5G AUSF) and the secondary station. Based on this key, additional keys can be derived, for example to serve applications. There are several issues regarding the derivation and management of keys. For example, (1) when the secondary station moves from LTE to a 5G network, (2) when an application has been using an application key for a long time, or (3) when the secondary station is roaming. This last aspect also involves, for example, lawful interception, because when the secondary station is roaming in a VPLMN, the VPLMN may want to have decryption keys for communications between the AF and the secondary station, regardless of the location of the AF (VPLMN, HPLMN, or external).

[0008] In addition, the secondary station may also need to share certain parameters (or personally identifiable information) with, for example, the primary station (RAN) or some network functions. For example, a secondary station accessed via a non-terrestrial network (NTN) may need to share its coarse location. In fact, in this example, the coarse location of the secondary station may be required, for example, to assign the correct AMF to the secondary station. Sharing such parameters can occur after a secure connection is established between the secondary station and the primary station to ensure that the information is not eavesdropped. Even if the sharing of such location information can be done in a secure manner (protected by AS security), user consent may still be required.

[0009] Secondary stations may also share certain identifiers over the radio interface without protection. For example, the "Priority Access" value exchanged during the initial random access procedure is not protected, in other words, the 5G standard allows establishment causes such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess" to be sent in plain text over the air. Exposing this information in plain text may allow an attacker to identify characteristics of the UE or the communication causing privacy risks. Current solutions do not protect these fields.

[0010] Similarly, in 3GPP, new RAN components such as mobile master stations or network controlled relays (NCRs) are being developed. However, when these NCRs or mobile master stations are connected to the network, it is unclear how they are authenticated and authorized in the network. Summary of the invention

[0011] It is an object of the present invention to provide a method that is resilient to these types of attacks.

[0012] Another object of the present invention is to provide enhanced security capabilities, such as supporting AKMA in roaming scenarios.

[0013] Another object of the invention is to provide a communication device that is resilient to attacks, in particular MitM attacks of this type. Another object of the invention is to provide a communication system that can detect an attacker using attacks of this type when attempted in a network.

[0014] It is another object of the present invention to enhance the overall key agreement and derivation process.

[0015] It is another object of the present invention to provide enhanced security capabilities, such as user consent.

[0016] It is another object of the present invention to provide enhanced security capabilities, such as units for authenticating and authorizing NCRs.

[0017] It is another object of the present invention to provide enhanced security capabilities, such as protecting identifiers over wireless interfaces.

[0018] The reason why the attack can be successful in certain scenarios is because the MitM is able to modify the message 110 in such a way that parameters such as the preferred / supported security capabilities of the UE 100 (or its location, or the type of device in which the UE is located) are changed, thereby giving a false indication to the core network 104, for example, using NIA0 and NEA0 integrity / encryption algorithms which are equivalent to no integrity and no encryption.

[0019] Therefore, according to the present definition of the invention, it is described how this information (ie the security capabilities) can be protected, for example by including it in the authentication and key agreement phase 106, such that the authentication check performed depends on security parameters sent by the UE.

[0020] According to a first aspect of the present invention, a device for verifying a sensitive field sent to a second device is provided, the device comprising:

[0021] a memory adapted to store information; and

[0022] a transceiver adapted to send and receive messages,

[0023] Wherein, the device is configured as follows:

[0024] - sending a first message having a sensitive field to the second device;

[0025] - receiving a verification challenge from the second device,

[0026] - Computing a response based on the authentication challenge, key material shared between the first device and the second device, and the sensitive fields exchanged in the first message and sending the response to the second device.

[0027] According to a second aspect of the present invention, an apparatus for verifying a sensitive field received from a first device is provided, the apparatus comprising:

[0028] a memory adapted to store information; and

[0029] a transceiver adapted to send and receive messages,

[0030] Wherein, the device is configured as follows:

[0031] receiving a first message having a sensitive field from a first device,

[0032] receiving a response from the first device, and

[0033] The function that checks the response whether a match depends on the value of the sensitive field received in the first message.

[0034] According to a third aspect of the present invention, a system is proposed, which comprises at least a first communication device according to the first aspect of the present invention and at least one second device according to the second aspect of the present invention.

[0035] Furthermore, according to a fourth aspect of the present invention, a method for verifying a sensitive field sent to a second device is proposed, the method comprising:

[0036] a. the first device sends a first message having the information to the second device,

[0037] b. receiving a verification challenge from a second device,

[0038] c. Calculate and send a response to the second device based on the authentication challenge, the key material shared between the first device and the second device, and the sensitive fields exchanged in the first message.

[0039] According to a fifth aspect of the present invention, an apparatus for protecting a message by using a second device is provided, wherein the apparatus is configured to perform the following steps:

[0040] a) if the security context is available and the configured policy permits, retrieve the symmetric key; or

[0041] If no security context is enabled or the configured policy requires it, generating a symmetric key and encrypting the generated symmetric key using a first public key bound to a private key owned by the second device, and

[0042] (b) sending a secure message protected by the symmetric key to the second device along with the protected symmetric key or an instruction to retrieve the symmetric key.

[0043] According to a sixth aspect of the present invention, a device for secure communication in a UE to network relay scenario is proposed, wherein the device is suitable for:

[0044] - storing a policy that determines the behavior of the device when a direct security mode command is received; and

[0045] - Rejecting and / or accepting a received direct security mode command that is unprotected and / or includes a null encryption and integrity algorithm based on the policy, the policy including determining whether the device has previously sent a DCR message including an emergency RSC.

[0046] In a variant of the sixth aspect of the invention, it is proposed that the apparatus is adapted to accept a received direct security mode command that is unprotected and / or comprises a null encryption and integrity algorithm only if a DCR message comprising an emergency RSC has been previously sent.

[0047] Furthermore, if the apparatus may be adapted to reject a received direct security mode command that is unprotected and / or comprises a null encryption and integrity algorithm without previously sending a DCR message comprising an emergency RSC.

[0048] According to a seventh aspect of the present invention, a method for secure communication in a UE to network relay scenario is proposed, wherein the remote UE is adapted to:

[0049] - storing a policy that determines the UE's behavior when a direct security mode command is received; and

[0050] - Rejecting and / or accepting a received direct security mode command that is unprotected and / or includes null encryption and integrity algorithms based on a policy that includes determining whether the device has previously sent a DCR message including an emergency RSC.

[0051] According to an eighth aspect of the present invention, a lawful interception method is proposed, wherein:

[0052] - the second network function NF in the second network optionally signals a lawful interception requirement to the first NF in the first network, and

[0053] - the second NF receives key material from the first NF;

[0054] - The second NF decrypts the intercepted traffic exchanged between the user equipment UE and the application function AF based on the provided key material.

[0055] According to a ninth aspect of the present invention, a lawful interception method is proposed, wherein:

[0056] - the first network function NF in the first network optionally receives signalling of a lawful interception requirement from a second NF in the second network, and

[0057] - The first NF sends key material to the second NF, so that the second NF can decrypt intercepted services exchanged between the user equipment UE and the application function AF based on the provided key material.

[0058] According to a tenth aspect of the present invention, a second network function NF device in a second network is provided, comprising:

[0059] - a transmitter for optionally signaling a lawful interception requirement to a first NF in the first network, and

[0060] - a receiver adapted to receive key material from the first NF, and

[0061] - A controller adapted to decrypt intercepted traffic exchanged between the User Equipment UE and the Application Function AF based on the provided key material.

[0062] According to an eleventh aspect of the present invention, a first network function NF device in a first network is provided, comprising:

[0063] - a receiver for receiving signalling of a lawful interception requirement from a second NF in a second network, and

[0064] - A transmitter for sending key material to the first NF so that the second NF can decrypt intercepted traffic exchanged between the User Equipment UE and the Application Function AF based on the provided key material.

[0065] In addition, the present invention can be implemented by software. Therefore, one aspect of the present invention includes a storage medium containing codes. Once the codes are loaded onto a computer, the computer can execute the steps of the various methods described in this application.

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

[0067] 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

[0068] Figure 1 and Figure 2 represents a connection protocol used in conventional systems and is used to illustrate some embodiments.

[0069] Figure 3 Figure 2 shows an exemplary attack scenario involving MitM.

[0070] Figure 4 Represents an embodiment of Kaf update.

[0071] Figure 5 Another embodiment of Kaf update is shown.

[0072] Figure 6 Represents an embodiment of handling MitM.

[0073] Figure 7 An embodiment of AKMA roaming is shown.

[0074] Figure 8 Another embodiment for AKMA roaming is shown.

[0075] Fig. 9 Further embodiments for secure access to NTN services are shown.

[0076] Fig.10 An embodiment for establishing a shared key is shown.

[0077] Fig.11 An embodiment for AKMA roaming is shown.

[0078] Fig.12 An embodiment showing secure access to NTN services.

[0079] Fig.13 An embodiment showing secure access to NTN services.

[0080] Fig.14 An embodiment of authentication and authorization for NCR is shown.

[0081] Fig.15 An embodiment of authenticating and authorizing the NCR through EAP-TLS is shown.

[0082] Fig.16 Indicates the key hierarchy.

[0083] Fig.17 An embodiment for lawful intercept is shown. DETAILED DESCRIPTION

[0084] refer to Figure 1, this document describes an example of a protocol including the main phases for a terminal (e.g., UE) to join a telecommunication operation such as a 5G telecommunication network involving multiple entities such as:

[0085] 100 may be a user device owned by a user in the telecommunication system who attempts to join the telecommunication system.

[0086] 101 may be a base station in a telecommunication system, such as a 5G gNB.

[0087] 104 may be a core network of a telecommunication system.

[0088] 102 may be a function that handles authentication of a UE in a telecommunications system, such as an Authentication and Mobility Function (AMF) of a 5G core network.

[0089] 103 may be a function for storing user data, such as a unified data management (UDM) function of a 5G core network.

[0090] · 105 represents the entire telecommunication system.

[0091] The arrows in the diagram represent the message exchanges between these entities. In this example,

[0092] 109 represents the initial connection establishment which may involve multiple messages (eg, RRC Connection Request).

[0093] 110 refers to an authentication request, such as an attach or registration request.

[0094] 111 refers to a request for some authentication value given the identity provided in 110, such as a SUPI.

[0095] ·112 refers to the delivery of an authentication challenge.

[0096] 113 is an authentication request which may include some input from 112, for example.

[0097] 114 is the authentication response.

[0098] · 106 including messages 111-114 refers to the authentication and key agreement phase.

[0099] 115 represents a message confirming the security parameters used for the communication between 100 and 102.

[0100] 116 represents a confirmation message indicating that the establishment of the secure link for communication between 100 and 102 is completed.

[0101] 117 indicates protected communication between 100 and 102.

[0102] 107 represents several messages (eg, 115, 116, and 117) used to establish a secure link between 100 and 102 and later secure exchange of messages.

[0103] 119 indicates a message indicating that a secure link is established between 100 and 101.

[0104] 120 represents a message indicating that the establishment of the security link between 100 and 101 is completed.

[0105] 121 represents a secure exchange of messages between, for example, 100 and 101.

[0106] 108 represents a plurality of messages used to establish a secure link between 100 and 101 and a later secure exchange of messages.

[0107] 122 represents a message indicating that 100 has successfully joined 105.

[0108] Notice, Figure 1 are illustrative and some entities may be missing or included in other entities. For example, in 5G, the Security Anchor Function (SEAF) or the Authentication Server Function (AUSF) plays an important role. AMF and SEAF are in the serving network, while AUSF and UDM are in the home network. AMF interacts with SEAF, SEAF interacts with AUSF, and AUSF interacts with UDM. SEAF may reject the UE, however, it relies on the UE's home network to accept the authentication.

[0109] One of the authentication procedures in 3GPP is the 5G AKA authentication procedure, where, for example, the home network obtains a challenge as follows:

[0110] xRES*=Challenge(K, R, SNname), and

[0111] HXRES*=SHA256(R, xRES*)

[0112] Where K is a symmetric key, R is a random number generated by the home network, and SNname is the serving network name. In addition, the home network obtains the MAC as

[0113] f_1(K, SQN||RAND|||AMF)

[0114] The home network then provides HXRES* to the serving network. Note that in particular, UDM / ARPF starts 5G-AKA by sending an authentication response to AUSF, where the authentication vector includes AUTH token, XRES token, key K AUSFand SUPI (if applicable) (e.g., when SUCI is included in the corresponding authentication request) and other data. The AUSF calculates a hash of the expected response token (HXRES) and stores the key K AUSF , and sends the authentication response together with the AUTH token and HXRES to SEAF. Note that the SUPI is not sent to SEAF in this authentication response. It is only sent to SEAF after the UE authentication is successful.

[0115] The UE performs similar operations on its side and checks the received MAC and calculates the response RES* as:

[0116] RES*=Challenge(K,R,SNname)

[0117] The UE then sends the value RES* to the core network.

[0118] The serving network checks if SHA256(R, RES*) is equal to HXRES*. If not, reject.

[0119] The home network checks if RES* is equal to xRES*. If not, it rejects.

[0120] However, this protocol may be vulnerable to man-in-the-middle attacks or mask attacks. A man-in-the-middle (MitM) attacker is one that is placed between 100 and 101 and is able to forward, modify, inject, or drop messages. In a mask attack, the attacker injects a signal that modifies the message received by the receiver.

[0121] Several specific attacks that MitM can perform are described in the literature. Figure 1 , the main feature of the attack is that the MitM may be able to modify fields in message 110, such as the security capabilities of 100. This is achieved by Figure 3 As shown, 300, 301, 302, 303, 304, 305 correspond to Figure 1 100, 101, 102, 103, 104, 105 in . 306 indicates MitM. 309 is equivalent to 109. 310 which is equivalent to 110 is modified by MitM which makes message 311.

[0122] Security capabilities may include confidentiality or integrity algorithms supported by the UE or preferred by the UE, such as the New Radio Integrity Algorithm (NIA) or New Radio Encryption Algorithm (NEA) in 5G.

[0123] By modifying the preferred or supported security capabilities, MitM may be managed to trigger SUPI capture, where the long-term identifier of the UE 100 may be captured by a MitM or IP spoofing attack.

[0124] Based on the above-mentioned authentication and key agreement phase 106, a master key (e.g., K_ausf) can be derived and stored at the network function (e.g., 5G AUSF) and the UE. Based on this key, further keys can be derived, for example to serve applications. These keys may include 5G K_akma (stored at AAnF and UE) or K_af (stored at the application function (AF) and UE), as described in TS33.535. As described in clause 6.1 of TS33.535, the AUSF derives K_akma and AKMA key identifier (A-KID) from Kausf and deploys them to the AAnF. The A-KID includes an AKMA temporary UE identifier (A-TID), a home network identifier (HNI), and a routing indicator (RID). Clauses A2, A3, and A4 in TS33.535 define how to derive Kakma, A-TID, and Kaf.

[0125] Based on the authentication and key agreement phase between the secondary station and the core network, a master key can be derived and stored at the network function (e.g., 5G AUSF) and the UE. Based on this key, further keys can be derived, for example to serve applications. These keys may include 5GK_akma (stored at AAnF and UE) or K_af (stored at the application function (AF) and UE), as described in TS33.535. As described in clause 6.1 of TS33.535, the AUSF derives K_akma and AKMA key identifier (A-KID) from Kausf and deploys them to AAnF. A-KID includes an AKMA temporary UE identifier (A-TID), a home network identifier (HNI), and a routing indicator (RID). Clauses A2, A3, and A4 in TS33.535 define how to derive Kakma, A-TID, and Kaf.

[0126] There are multiple issues regarding the derivation and management of keys that rely on K_ausf. For example, (1) when the UE moves from LTE to a 5G network, the LTE K_asme is mapped into the K_amf key, allowing the UE and gNB as well as the UE and AMF to communicate in a secure manner, however, K_ausf is lost, and therefore K_akma and K_af are also lost. Similarly, (2) when an application has used K_af for a long time, the key K_af may expire, however, there is no way to update it. Or finally, (3) the current AKMA architecture does not describe how it operates with roaming. The last aspect also involves lawful interception, because when the UE roams in a VPLMN, the VPLMN may want to have decryption keys for communications between the AF and the UE, regardless of the location of the AF (VPLMN, HPLMN, or external). The UE may also need to share certain parameters (or personally identifiable information) with, for example, the gNB (RAN) or some network functions (for example, a UE accessed via a non-terrestrial network (NTN) may need to share its coarse location). Indeed, in this example, a rough location of the UE may be needed, for example, to assign the correct AMF to the UE. Sharing such parameters may occur after a secure connection is established between the UE and the gNB to ensure that this information is not eavesdropped. Even if sharing of such location information can be done in a secure manner (protected by AS security), user consent may still be required before the location is actually shared, and knowledge of the UE location may benefit the user consent decision itself. Furthermore, the UE should be securely informed of the user consent preferences. However, current solutions do not meet such requirements.

[0127] The UE may also share certain identifiers over the radio interface without protection. For example, the "Priority Access" value exchanged during the initial random access process is not protected, in other words, the 5G standard allows establishment of reasons such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess" to be sent in plain text over the air. Exposing this information in plain text may allow an attacker to identify the characteristics of the UE or communications that pose a privacy risk. Current solutions cannot protect these areas.

[0128] Similarly, in 3GPP (new component), Network Controlled Repeaters (NCRs) are being developed. NCRs are used to improve the coverage of gNBs by repeating / forwarding their radio signals. However, it is unclear how such NCRs are authenticated and authorized in the network when they are connected to the network.

[0129] Example 1

[0130] In the first embodiment, the security capabilities received from the UE in the message 110 in the core network should be used in the authentication process between the core network and the UE, for example, in messages 113 and 114. Figure 1 , the security challenge xRES* or HXRES* may be calculated using information provided in a previous message received from the UE (e.g., an initial message 110, such as an initial attach or registration request sent by the UE) as input. Examples of the input information used are the security capabilities of the UE received by the core network (e.g., a serving and / or home network), such as

[0131] xRES*=Challenge(K, R, SNname, UE security capability)

[0132] HXRES*=SHA256(R, xRES*)

[0133] Other parameters that need to be protected or verified are those included in the Attach or Registration Request, such as AN parameters in NG-RAN, Registration Type, SUCI or 5G-GUTI or PEI, last accessed TAI (if available), security parameters, requested NSSAI, mapping of requested NSSAI, default configured NSSAI indication, UE radio capability update, UE MM core network capabilities, PDU session status, etc. Note that the Registration Type indicates whether the UE wants to perform an Emergency Registration which will force the use of null ciphers and integrity algorithms. Other parameters that need to be protected may be contextual UE parameters, such as their location.

[0134] HXRES* may also be calculated, including explicit UE security capabilities, although this is not necessary as these are implicitly included via xRES*. Similarly, the UE must obtain its response RES* in a similar manner, i.e. including its UE security capabilities included in the initial message.

[0135] In the example, RES*=Challenge(K, R, SNname, UE security capabilities)

[0136] If this is done, the check performed by the serving network on whether HXRES* is equal to SHA256(R, xRES*) will only hold if the UE security capabilities have not been modified (by MitM). Furthermore, the check performed by the home network on whether RES* is equal to xRES* will only hold if the UE security capabilities have not been modified (by MitM).

[0137] It is important to note that instead of using the information to be verified "info" (e.g., other fields exchanged in an initial message such as a NAS Registration Request) as part of the input to the function that generates one of the above challenges, for example, in xRES*=Challenge(K, R, SNname, info), this information can be used together with an internal parameter (e.g., a key K) to derive another internal variable, such as K'. This can be achieved by, for example, applying a key derivation (KDF). For example, K'=KDF(K, info). This new parameter K' can then be used to derive the challenge / response as usual: xRES*=challenge(K', R, SNname). This statement also applies to the other embodiments.

[0138] The above calculations refer to clause 6.1.1.3 in TS33.501.

[0139] An additional remark is that the generation of the above parameters xRES* including the UE security capabilities may require the exchange of the UE security capabilities received by the AMF in the initial UE message NAS-PDU: Registration Request in Nausf_UEAuthenticate_authenticate Request sent from the AMF to the AUSF and including the SUCI. Similarly, the UE security capabilities may need to be sent from the AUSF to the UDM in a Nudm_UEAuthenticate_Get Request message so that the UDM can perform the above calculations.

[0140] Example 2

[0141] In an alternative embodiment, the UE security capabilities may be included in the home network MAC. Thus, instead of calculating the MAC as

[0142] f_1(K, SQN||RAND|||AMF),

[0143] The home network can calculate this as

[0144] MAC=f_1(K,SQN||RAND|||AMF||UE_SC_F).

[0145] Among them, UE_SC_F refers to UE security capabilities, or generally refers to information that needs to be verified.

[0146] This can be Figure 1 On the UE side, upon receipt of message 113, once the USIM has retrieved the SQN, the UE can calculate the XMAC in the same way (ie, using the parameters to be authenticated as input) and compare it with the received MAC.

[0147] Example 3

[0148] Introducing new types of checks (as in other embodiments) may result in situations where the telecommunications system must distinguish between legacy UEs that do not support the enhanced authentication procedure and new UEs that do support the enhanced authentication procedure. It may be assumed that the home networks hosting the new UEs are new home networks, i.e., support the new authentication method even though they may still host legacy UEs. However, the new UEs may interact with the new home network through a legacy serving network.

[0149] To address this issue, in an alternative to the first embodiment, the new UE may send a preferred authentication method in the initial message 110, for example, as outlined in other embodiments. This may be signaled via a message field that may indicate a protocol version. A single bit may be sufficient. If it is a new UE, the home network and the UE may use, for example, the solutions in other embodiments (e.g., embodiment 1.2).

[0150] To address this issue, in a second alternative, legacy UEs and new UEs may always send the same initial message 110, i.e., without an indication of the protocol version. In this case, the serving network may check (as currently does), i.e.:

[0151] HXRES*=SHA256(R, xRES*)

[0152] Note that the security capability check is already implicitly included in xRES*, so that nothing needs to be changed in the legacy serving network. The home network may first check:

[0153] RES*=Challenge(K, R, SNname, UE security capabilities),

[0154] And if that check fails, check whether

[0155] RES*=Challenge(K,R,SNname)

[0156] This process in which the protocol version is not included has the advantage that the attacker does not know which UEs are legacy and which are new, so that the attacker cannot launch a targeted attack.

[0157] If the above checks fail, the home network may inform the (legacy) serving network of the failed authentication process.

[0158] Example 4

[0159] TS 33.501 Clause 6.7.2 Reference Figure 1Possible implementations of messages 115 and 116 are described. These messages protect the Registration Request from a man-in-the-middle attack, where the attacker modifies the IE containing the UE security capabilities provided by the UE in the Registration Request. However, if the MitM sets the IE containing the security capabilities to include null integrity / confidentiality, then messages 115 and 116 (i.e., NAS Security Mode Command and NAS Security Mode Complete) according to TS 33.501 clause 6.7.2 may not apply integrity / confidentiality protection.

[0160] Therefore, in reference Figure 1 In a further embodiment, even if the network (e.g., 102) has selected a null integrity and / or null confidentiality configuration, messages 115 and / or 116 are integrity protected and / or confidentiality protected. These messages are protected with a key derived from a previous authentication process (messages 113 and 114).

[0161] Example 5

[0162] In a variation of the above attack, a man-in-the-middle attacker controlling a malicious gNB and a malicious UE can intercept a registration message (e.g., Registration Request) sent from a victim UE to a legitimate network (e.g., AMF) and change it to indicate that the registration is intended for emergency services (i.e., edit the Registration Type field to correspond to an emergency registration), and optionally include only null encryption and null integrity algorithms (i.e., NEA0 and NIA0) in the security capabilities or set the null integrity algorithm to the highest priority. The modified Registration Request is sent by the attacker to the legitimate network, which can allow or deny the emergency Registration Request based on its configured policies according to TS 33.501 clause 10.2.2.2. The serving network can also allow or deny the unauthenticated UE to establish a bearer for an unauthenticated IMS emergency session, and the AMF can attempt to authenticate the UE after receiving the emergency Registration Request.

[0163] If the policy of the serving network allows unauthenticated IMS emergency services and the AMF attempts to authenticate the UE, the MitM can forward the NAS_authentication_request to the victim UE which performs the necessary checks, derives the key (e.g., K_AUSF), then calculates the RES and sends it to the AMF in the NAS_authentication_response. The MitM attacker can intercept the NAS_authentication_response and change it to AUTHENTICATIONFAILURE to trick / force the AMF to use the NULL security algorithm. According to TS 33.501 clause 10.2.2.2, if the serving network policy allows unauthenticated IMS emergency sessions, the AMF can send a NAS SMC with a null security algorithm to the UE, regardless of the algorithms supported by the UE and previously announced (e.g., in its security capabilities) in the following cases:

[0164] - The AMF cannot identify the subscriber or cannot obtain the authentication vector (when SUPI is provided).

[0165] -UE authentication failed.

[0166] - The AMF receives an Emergency Registration Request and an Authentication Failure message with an error code as defined in 24.501 clause 5.4.1.2.4.5 or 5.4.1.3.7.

[0167] The last case can be exploited by a MitM attacker to trigger a NULL security algorithm to be selected by the AMF. After selecting the NULL encryption / integrity algorithm, a NAS SMC message as described in TS 33.501 clause 6.7.2 can be sent unprotected to the victim UE and indicate that the NULL integrity and encryption algorithms were selected. According to TS 33.501 clause 10.2.1.3, Note 1 and Note 2, the AMF can assume that the UE is ready and will accept the selection of the NULL integrity and encryption algorithms in the SMC procedure. Therefore, the MitM can trick the victim UE and the AMF into continuing with the NULL encryption and integrity algorithms, allowing the MitM to perform a SUPI capture attack and / or an IP spoofing attack.

[0168] Another scenario where a similar MitM attack may work involves 5G ProSe, where a remote UE may attempt to connect to the network via UE-to-network (U2N). In the case of emergency services over a U2N relay, if the network policy allows unauthenticated emergency services and the UE (e.g., no USIM) cannot be successfully authenticated and authorized to use ProSe U2N relay services, UP traffic may be sent via a PC5 link without security protection or with limited integrity protection. For example, the process described in TS33.503 is established as follows: After UE-to-network (U2N) relay discovery, the remote UE sends a DCR message to the U2N relay, which includes an emergency RSC and optionally a PSUK ID, SUCI, or PEI. If the CN receives a PRUK ID / SUCI in a message forwarded by the U2N relay, the U2N relay may perform UP or CP security procedures as in TS33.503. If only PEI and an emergency RSC are received, the U2N relay may skip this step if permitted by the regulations / operator policy. If the security procedure in the previous step is completed, the U2N relay performs a direct security mode command as in TS 33.503. Otherwise, it sends a direct security mode command with empty encryption and integrity protection. If authentication fails and the remote UE does not send PEI in the DCR message, the U2N relay can send a remote identity request to retrieve the PEI. In this way, a MitM attacker as a (malicious) U2N relay can intercept a message of the victim UE (e.g. a direct communication request (DCR)) and can change it to add, for example, an emergency RSC and / or include a (fake) identity (e.g. a PEI); if the identifier is not included, a remote identity request can be sent to the victim remote UE to retrieve it at a later stage. The U2N relay can be forced to skip the UP or CP based security procedure (e.g., the MitM forces it to fail) and can therefore perform a direct security mode command procedure with empty encryption and integrity protection. Upon receiving the Direct Security Mode Command message with the Null Security Algorithm, the victim remote UE may treat UP integrity protection as not activated for the connection and include the UP integrity protection policy as not rejected in the Direct Security Mode Complete; otherwise, the MitM attacker may intercept and alter the Direct Security Mode Complete message to include the same indication (i.e., UP integrity is not required). Finally, the U2N Relay may send a Direct Communication Accept message to the victim remote UE via the MitM controlled U2N to complete the PC5 connection establishment procedure for emergency services. At this stage, the SUPI Capture attack may be performed by the MiTM attacker.

[0169] In another variation of the 5G ProSe MitM attack scenario, the process establishment described in TS 33.503 and TS 33.536 can be described as follows: After UE to Network (U2N) relay discovery, the remote UE sends a DCR message to the U2N relay, and the DCR message may include one or more of an emergency RSC, a PSUK ID, a SUCI, or a PEI, the remote UE's security capabilities, and / or a signaling security policy. The U2N relay may forward the parameters to the CN. If the CN receives a PRUK ID or SUCI in the message forwarded by the U2N relay, the U2N relay may perform the UP or CP security process as in TS 33.503. If only PEI and an emergency RSC are received, the U2N relay may skip this step if permitted by the regulations / operator policy, and if the UE's security capabilities and signaling security policies are also included in the DCR, the U2N may perform a direct authentication and key establishment process based on TS 33.536. In this case, a MitM attacker acting as a (malicious) U2N relay can intercept messages of the victim UE, such as Direct Communication Request (DCR); if the UE's signaling security policy is set to "not required" or "preferred", the MitM attacker can change the DCR message to add, for example, an emergency RSC, and optionally include a (fake) identity, such as PEI, and set the signaling security policy to "not required" if it is not already "not required". If the U2N relay signaling security policy is set to "not required" or "preferred", it may be forced to select null encryption and integrity security algorithms as Chosen_algs in the Direct Security Mode Command message. The legitimate U2N sends the Direct Security Mode Command message (including the NULL security algorithm, the remote UE's security capabilities and the signaling security policy) back to the remote UE. The MitM attacker can intercept the Direct Security Mode Command message and change the signaling security policy back to "preferred" if it has been previously changed to "not required" in the DCR message. This ensures that when the victim remote UE verifies the returned security capabilities and signaling security policy, as in clause 5.3.3.1.4.3, Figure 5 .3.3.1.4.3-1, as specified in step 4, without exposing the MitM attack. Thus, upon receiving the Direct Security Mode Command message that may have been altered by the MitM attacker, the victim remote UE may accept the null security algorithm and send an unprotected Direct Security Mode Complete message. Finally, the U2N relay may send a Direct Communication Accept message to the victim remote UE via the MitM controlled U2N to complete the PC5 connection establishment process for emergency services.

[0170] After a PC5 connection is established between the victim remote UE and the U2N relay, with the MitM attacker in between, the latter can perform an attack (e.g., a SUPI capture attack).

[0171] In an embodiment intended to mitigate an attack variant utilizing a Registration Type field indicating the type (e.g., emergency) in a Registration Request. The Registration Type may be used by the AMF upon receipt of a Registration Request to be included in a NAS_authentication_request (or forwarded by the AMF to the home network). Similar to the inclusion of UE_security capabilities in the above embodiments, the Registration Type may be securely sent back to the UE for verification, exposing any potential changes that a MitM may have made to the Registration Type. When the UE calculates the XMAC using the Registration Type it used in the Registration Request and verifies it against the MAC received in the NAS_authentication_request, if the Registration Type has been changed (e.g., by a MiTM attacker), the verification will fail and the UE will therefore consider the authentication to be unsuccessful. A failure in the authentication process from the (victim) UE side means that although the network may send a NAS SMC message with a null security algorithm, the UE will not expect such a NAS SMC message and may therefore reject or ignore it.

[0172] The advantage of the solution proposed above may be to prevent all attacks that rely on triggering and exploiting IMS emergency service scenarios by forging emergency requests. In addition, this solution may be combined with the solutions proposed in other embodiments to ensure that any changes to the registration type and / or the security capabilities of the UE will result in an authentication failure on the UE side, thereby stopping the attack.

[0173] In a further embodiment, the UE may be configured to reject a NAS SMC message indicating a null encryption and integrity algorithm unless the UE has requested emergency services. For example, if the network supports unauthenticated IMS emergency services, the UE may be configured via a policy that may be managed by the network (e.g., HPLMN) and provided to the UE.

[0174] In another embodiment, the network (e.g., HPLMN) may include an indicator (e.g., a 1-bit indicator) as part of the NAS_authentication_request that informs the UE that it supports unauthenticated IMS emergency services. In the event that the UE has not requested emergency services, the UE may rely on this indicator to reject a NAS SMC message indicating a null encryption and integrity algorithm.

[0175] In another embodiment to address potential MitM attacks in 5G Prose scenarios, the remote UE may be configured (e.g., through a specified policy or indicator) to discard any (e.g., direct security mode command message) with null encryption and integrity protection unless the remote UE is actually requesting emergency services. The policy or indicator may be provided to the remote UE, for example, when the remote UE is in coverage, and, for example, as per TS 33.503 clause 6.3.3.2.1. Figure 6 Step 0b in 3.3.2.2-1 is provided with discovery security material for open or restricted discovery. Alternatively, in the same figure, as per step 1b, it may be provided with policies or rules via the ProSe User Key Response. In both cases, a NF such as a PCF or a PKMF of the remote UE may manage and / or determine whether the remote UE may accept or reject null encryption and integrity protection.

[0176] In another related embodiment, if the remote UE does not request emergency services, and in particular if the request is not protected (and therefore cannot be verified by the remote UE), a policy configured / implemented in the remote UE may determine that the remote UE may not disclose its PEI if the U2N relay requests to retrieve it.

[0177] In another embodiment aimed at mitigating MitM attacks in 5G ProSe scenarios, if the received direct communication request indicates that the remote UE is requesting emergency services (i.e., an emergency RSC is included in the DCR message), the U2N relay may include (or replay) the emergency RSC in the unprotected direct security mode command message. As such, the remote UE may be configured (e.g., via a security policy) to reject unprotected direct security mode command messages that do not include an emergency RSC and unprotected direct security mode command messages that include an emergency RSC when the remote UE has not requested emergency services.

[0178] In another scenario related to MitM attacks in 5G ProSe scenarios, the U2N relay may be forced to send an unprotected Direct Security Mode Command. In this scenario, if the remote UE receives an unprotected Direct Security Mode Command, the remote UE may accept the message according to Sol#27 in TR 33.740. However, this should only happen if the remote UE has requested emergency services, for example if the remote UE has sent an emergency RSC in the initial DCR message. If the remote UE does not behave in this way, this will interfere with the PC5 security establishment of 5G ProSe UE to network relay communications on the user plane as defined in clause 6.3.3.2.2 in TS 33.503, for example.

[0179] Therefore, in an embodiment that addresses this scenario, the remote UE is configured with a policy (which may be hard-coded in source code or configured on the UE) that determines that the remote UE should only accept unprotected direct security mode commands and / or accept the use of a null integrity algorithm if the remote UE has previously requested emergency services (e.g., by sending a DCR message including an emergency RSC). The policy may have been configured by a network operator through a network function (e.g., PCF) in the core network of a telecommunications system (e.g., 5GS).

[0180] Therefore, in an embodiment addressing this scenario, the remote UE is configured with a policy (which may be hard-coded in source code or configured on the UE) that determines that the remote UE should only accept the use of the null integrity algorithm if the remote UE receives such configuration in a protected direct security mode command and the verification is successful. The policy may have been configured by a network operator through a network function (e.g., PCF) in the core network of the telecommunications system (e.g., 5GS).

[0181] Therefore, an apparatus and method for secure communication in a UE to network relay scenario that can be implemented in a user equipment is proposed, whereby the apparatus:

[0182] o storing hard-coded / pre-configured policies that determine device behavior when a direct security mode command is received; and

[0183] o Reject / accept received Direct Security Mode Commands that are unprotected and / or include null encryption and integrity algorithms based on the policy and whether the device has previously sent a DCR message including an emergency RSC.

[0184] In the case of emergency services over U2N relay, if the UE is USIM-less or cannot be successfully authenticated and authorized to use the ProSe U2N relay service (e.g., if MitM interferes with the authentication process), UP traffic may be sent without protection or with limited integrity protection (or requested to be sent without protection / with limited protection), for example, a MAC-I with input parameters including a 32-bit COUNT, a 5-bit bearer identity, a 1-bit transmission direction, and a known 128-bit integrity key (e.g., set to all zeros) may be generated to provide limited protection, for example, against data loss due to unintentional unstable radio conditions. Since a MitM attacker may forge such a MAC-I, a policy configured in the UE may also determine that the UE may not use such a configuration and therefore reject messages with limited protection if the UE has not requested emergency services.

[0185] Example 6

[0186] In solutions for emergency access through UE to network relay (e.g., solution #27 in TR 33.740), the DCR message may include parameters such as a permanent equipment identifier (PEI). Even for emergency access, it is beneficial if the PEI is also protected (encrypted / integrity protected). The protection may be done in a similar manner as in clause 6.3.5 in TS 33.503, where the PEI is protected alongside the RSC or PSUK ID.

[0187] Example 7

[0188] In a potential attack, an attacker may be able to compromise the privacy of the Subscriber Hidden Identifier (SUCI) by correlating the IMSI (e.g., captured from a 4G Attach Request using a 4G IMSI Capturer) with the SUCI (e.g., captured from a 5G Registration Request or NAS Authentication Response). The attack may work under certain conditions specified below and can be described as follows:

[0189] Step 1: When the UE attempts to connect to a legitimate 4G network (e.g., through an Attach Request), the attacker can intercept the UE's IMSI (e.g., using a 4G IMSI catcher).

[0190] Step 2: The legitimate network can respond to the UE with an authentication request, which includes valid AUTN and RAND values ​​and is captured by the attacker.

[0191] Step 3: The attacker uses a fake 5G-SA network (e.g., using a fake gNB) to which the victim UE attempts to connect.

[0192] Step 4: Upon receiving a Registration Request from the victim UE, if the SUCI is not included, the attacker can (e.g., via a fake gNB) send a NAS Identity Request, to which the victim UE responds with a NAS Identity Response containing its hidden SUPI (i.e., SUCI).

[0193] Step 5: The attacker reuses the RAND and AUTN captured from the legitimate 4G authentication request captured in step 2 in the crafted 5G NAS authentication request.

[0194] Based on the UE's response to the authentication request, it may be known whether the SUCI corresponds to the IMSI captured in step 1 (eg, based on a SUCI catcher attack).

[0195] Such an attack may allow an attacker to identify, locate and / or track a UE whose IMSI is already known.

[0196] The attack works under the following assumptions and / or conditions:

[0197] - The attacker already knows the UE's IMSI.

[0198] - The attack must occur within a short time window, i.e., capturing a legitimate 4G authentication request and replaying it as a 5G authentication request must occur such that the sequence number (SQN) in the AUTN is fresh and not rejected by the victim UE.

[0199] The subject of the following embodiments is to address the above-mentioned potential attacks.

[0200] In an embodiment, the UE may include a freshness parameter / challenge (e.g., a random number or a time-based counter, such as a UTC value) to the Registration Request, which is included by the network in the NAS Authentication Request (e.g., similar to UE_Security_Capabilities in other embodiments).

[0201] In an alternative embodiment, the 5G home network may add a parameter / indication (e.g., "5G") to the parameters used to derive the MAC, where the parameter / indication indicates the handshake that the UE intends to perform. For example, instead of calculating the MAC as

[0202] MAC = f_1(K, SQN||RAND||AMF)

[0203] The home network can calculate this as

[0204] MAC=f_1(K,SQN||RAND||AMF||"5G")

[0205] Other parameters or indications besides "5G" may be used to indicate the handshake that the UE intends to perform.

[0206] In another embodiment that may be combined with other embodiments, since the attack relies on the freshness of the intercepted (4G) authentication request and is time critical (i.e., the freshness check of the SQN in the USIM must be guaranteed to succeed), the UE may be configured with a stricter limit L (described in clause C.2.2 in TS 33.102) on the difference between the SEQ_MS and the received sequence number component SQN when the UE transitions from a 4G to a 5G SA network.

[0207] Example 8

[0208] In some cases, non-3GPP compliant devices can be connected to the radio access network. These devices do not support all mandatory features defined in 3GPP, RAN. This is a problem because non-compliant devices may interact with compliant devices and thus affect the overall performance of the RAN, for example, if the non-compliant device does not fully respect the timing of the frequency range.

[0209] The following embodiments are intended to solve this problem:

[0210] In one embodiment, the device type is included in the UE capabilities and verified as in other embodiments in this application.

[0211] In one embodiment, the device type is specified by a chipset ID or a MUD file according to RFC8520.

[0212] In one embodiment, the device type may be included in the UE capabilities. The UE capabilities may be reported to the AMF. As in other embodiments, the AMF may retrieve the UE capabilities (e.g., which may include the device type) from the AUSF / UDM. The UE may be allowed to join the (H / V)PLMN and / or RAN if:

[0213] - the UE capabilities (e.g. including device type) reported (by the UE) and retrieved (from AUSF / UDM) match, and / or

[0214] -UE capabilities (device type) are 3GPP compliant.

[0215] In another embodiment, the compliance status of the device may be verified and / or checked against a compliance ledger owned, operated, and maintained by 3GPP entities and members. The ledger may include records of one or more of the following:

[0216] o UE type including, for example, device name, id, manufacturer id, chipset id, firmware version, firmware summary, certificates, status, UE (generic) capabilities, etc.

[0217] ο Manufacturer / supplier including e.g. ID, legal entity name, brand name, URL, certifications, etc.

[0218] o Trusted certificate authorities including, for example, id, certificate subject name, root certificate, status, etc.

[0219] The compliance ledger could be a blockchain, or a transparent tree as in RFC9162, or just a central trusted repository.

[0220] The compliance ledger may allow permissioned write access so that only authorized manufacturers and / or suppliers can write to it. Thus, once a supplier releases a new device, an entry including all information about the device is written to the compliance ledger.

[0221] When a new device type is added, initially, the device status may be set to None. The status may be updated to Compliant or Non-Compliant based on the reported results of conformance testing conducted by a trusted, independent test lab or an operational network. Future continuous evaluation / testing of device compliance by a trusted test lab and / or network may result in a compliance status update (e.g., from Compliant to Non-Compliant) for the device. A compliance status update may include a condition where the device type is non-compliant for public verification.

[0222] The manufacturer / supplier may be issued certificates by a trusted certificate authority and may use them to issue certificates for the UE. For example, during the initial registration process and / or the initial authentication process, the certificate trust chain may be verified when the UE accesses the registration. For example, a base station (or NF in a V / HPLMN) may send a challenge to the UE, for example, including a random number, in, for example, an RRC connection establishment. The UE may sign the challenge (e.g., a random number) and then include its ID, the manufacturer's ID, the random number, and the signature in a reply message (e.g., an RRC establishment completion / registration request to be verified by, for example, a base station and / or AMF). Using the UE and its manufacturer's ID, their certificates may be retrieved from the compliance ledger and used to verify the UE's signature and trust chain, thereby confirming the authenticity of the UE's provenance. The compliance of the UE may be indicated by a compliance status associated with the UE ID in the compliance ledger.

[0223] In a related embodiment, the challenge may include a request for additional parameters, such as a fingerprint of (a portion of) the firmware. A trusted entity in the device (under test) may be responsible for calculating such a fingerprint and signature to ensure that the device is properly certified (e.g., the device does not rely on a third party to obtain the result).

[0224] In a related embodiment, a compliance check may be performed first, and in the event that the compliance status of the UE (of / of a non-compliant device type) in the compliance ledger indicates that it is non-compliant, the network may decide to drop the connection. In the event that the UE (of a compliant device type) is compliant, the network may further check the UE's signature and trust chain to establish the UE's provenance authenticity.

[0225] In a related embodiment, the UE may not sign anything as a response to a challenge from the gNB (typically, the test device). The reason is that signing may result in potential privacy risks if the same private / public key pair is used for a long time. Instead, the UE may simply return, for example, a function (e.g., a cryptographic hash) of the challenge (e.g., a random number) and device characteristics (e.g., firmware), such as HMAC(random number, Hash(Firmware(pages_x_y))). In this regard, the test device may have sent a challenge "(random number, pages_x_y)" requesting the device to return an HMAC() of a hash of its firmware in memory page x_y using the received random number as the HMAC key.

[0226] In a related embodiment, signatures may be exchanged only when a secure channel has been established, for example, after a primary authentication.

[0227] In a related embodiment, the UE may:

[0228] - First, expose / transmit its device type so that the network can decide whether to enable / disable access based on the device type (e.g., based on local policy, information in the ledger, etc.);

[0229] -Second, establish a secure channel with the network;

[0230] - Thirdly, a device attestation phase is performed towards the network so that the network can verify that the UE is the type of device advertised in the first step.

[0231] In a related embodiment, if a device (UE) is subject to authentication / certification, parameters (eg, a public / private key pair) assigned to the device for authentication / certification may be rotated / changed / updated to avoid privacy issues.

[0232] In a related embodiment, once a device (UE) and a gNB share a confidential channel to securely exchange parameters (such as challenges or challenge responses), the UE can be authenticated / proven.

[0233] In a related embodiment, a device (e.g., UE) and an access device (e.g., gNB) may employ a key exchange protocol (e.g., Diffie-Hellman) to agree on a shared key that is subsequently used as, for example, an HMAC key, or to derive other keys (e.g., for encryption or MIC). For example, in addition to its id, the access device (e.g., gNB) may broadcast a randomly generated challenge (e.g., a random number) as part of a SIB message; the device (e.g., UE) may decode the contents of the SIB message and use the access device's id to identify the public key associated with it, e.g., if the UE has locally stored a record containing information related to the access device (e.g., gNB) from a ledger, it may use the gNB's public key and its private key to derive a shared symmetric key K. K may then be used (e.g., via a key derivation function) to derive other keys (e.g., HMAC keys, MIC keys, encryption keys) that the UE may use to protect and / or sign challenge responses. The UE may also include its id in the response so that the gNB identifies the UE’s public key from the ledger and similarly uses it (i.e., together with its private key to derive the shared symmetric key K) and derive the necessary keys (e.g., HMAC and / or MIC and / or encryption keys) to verify the UE’s response validity and subsequently its provenance and compliance.

[0234] In a related embodiment, the network may first start by checking the UE's signature and trust chain. In the event that one of the checks fails, the network may respond with an error message (e.g., a faulty signature) and a new challenge (e.g., a random number) to be used in subsequent UE attempts. The network may define a limit on the number of attempts allowed that the UE can use to establish the authenticity of its origin (e.g., three attempts). If all attempts fail, the network may discard the connection and set a cool-down period to prevent the UE from retrying to establish the connection again. The network may not rely solely on information reported by the UE (e.g., ID and manufacturer ID) to prevent the UE from attempting to establish a connection, because these IDs are public and any UE can use them to prevent DoS attacks. In the event that the UE's signature and trust chain are verified, the network can check the UE's compliance status, and if compliance is carried on the primary authentication, the connection may be discarded if it is not compliant.

[0235] In a related embodiment, the attestation process may be part of an authentication process, such as a primary authentication process between the UE and a home network.

[0236] In a related embodiment, if the messages exchanged between the UE and the base station support larger data size, the UE's provenance authenticity and compliance checks can be performed at an earlier stage (e.g., initial / random access procedure). In this scenario, the base station can broadcast the random number as part of SIB1. When the UE selects the SSB, extracts the MIB and SIB1 data, it can sign the random number and include its id, manufacturer's id and signature in the random access procedure message 1. The gNB can obtain information related to the UE, its manufacturer, and then perform the necessary checks to establish its provenance authenticity and compliance as described in the above embodiments. Based on these checks and the results of the connection attempt, the gNB can send a failure message with a new random number, drop the connection, or respond with an acknowledgement in a random access response (i.e., random access procedure message 2). Once the RRC connection establishment is completed, the gNB indicates to the AMF that the provenance and compliance checks were successfully performed.

[0237] In a related embodiment that may be used independently, the access device may broadcast (in a SIB, e.g., SIB1) and / or communicate (e.g., in an RRC message or NAS) the fact that the network requires one or more of the following:

[0238] - determine the UE type / ID,

[0239] - perform UE authentication,

[0240] To allow the UE to access the network and / or certain functions in the network, for example, the UE may only be allowed to use certain services (eg, mobile base station or RIS or smart repeater, etc.) if the UE is verified to be able to handle them correctly.

[0241] In a related embodiment, the UE may need to transmit a device type / ID and / or undergo device authentication if required by the network.

[0242] In a related embodiment, the HPLMN performs the above actions (eg, requiring a device type ID and / or performing device certification), for example, as part of a primary authentication.

[0243] In a related embodiment, the HPLMN may communicate the results of the above actions (eg, requiring a device type ID and / or performing device certification) to the VPLMN.

[0244] In a related embodiment, the VPLMN performs the above actions (eg, requiring a device type ID and / or performing device certification), for example, as part of a primary authentication.

[0245] In general, or in a specific embodiment in which it is mentioned, certificate trust chain verification and / or validation may refer to and / or include, but is not limited to, a process of verifying the validity period of an entity's (e.g., base station) certificate (e.g., Certificate_A) and the signature of an authority (e.g., an operator) that issued and signed Certificate_A, followed by recursively repeating the process (i.e., verifying the validity period of an authority's (e.g., operator's) certificate (e.g., Certificate_B) and the signature of a higher authority (e.g., a trusted certificate authority) that issued and signed Certificate_B) until a trusted certificate authority is reached, thereby establishing the authenticity and trustworthiness of the entity.

[0246] In another embodiment, verification may also refer to and / or include one or more of the following:

[0247] - Compliance check: whereby the compliance status corresponding to the id of a device (eg UE) is checked against the records on the ledger.

[0248] -Firmware version check: whereby a device (e.g., UE) can check on the ledger whether any update to the firmware corresponding to the device model is available.

[0249] According to the above embodiments, a method is proposed, by which an entity (e.g., an access device (e.g., a base station) or a NF) belonging to a network (e.g., a service or home network) can check and verify one or more of the authenticity, origin, and compliance of a user equipment (UE) that can attempt to access the network based on records in a ledger, wherein the method can be implemented on a verifier (e.g., a base station) and includes verifying security information (e.g., a signature, a digest, a certificate, a trust chain) and performing checks (e.g., compliance status checks, firmware update checks) on the user equipment (UE) based on data records stored in the ledger, whereby the verifier (e.g., a base station) can perform the verification itself, or perform the verification with the assistance of a NF (e.g., an AMF) in the network.

[0250] The method may rely on different processes to obtain security and / or identification information, for example, the process may be as in other embodiments:

[0251] o An access device (e.g., a base station) that sends a randomly generated challenge (e.g., a random number and a specific firmware page) as part of a SIB message

[0252] o The user device signs the challenge with a random number as a key (e.g., HMAC(random number, hash(firmware(page)))) and / or calculates a function of the firmware page (e.g., a cryptographic hash), and adds the parameters required to perform the necessary checks and verifications (e.g., id, chipset id, firmware version) to the random access procedure message (e.g., message 1) or registration request.

[0253] The access device (e.g., base station) or NF (e.g., AMF) receives a message containing security and identification information from the UE and performs the checks and verifications described in the above embodiments. Embodiment 9:

[0254] If the message 110 is exchanged in a protected (integrity protected) manner, the attack is not feasible because the message cannot be modified by a MitM between the UE 100 and the base station 101. However, the message 110 cannot be integrity protected because the UE 100 and the CN 104 do not share an integrity key at this stage.

[0255] This can be addressed by encrypting a symmetric key K using a public key owned by the core network 104 (e.g., a public key owned by the home network and used to encrypt the SUPI), which is then sent to the core network 104 in a secure manner (e.g., in the message 110) and used to integrity protect the message 110 or certain fields in the message 110 (e.g., UE security capabilities), specifically by attaching a message integrity code (MIC) calculated as follows:

[0256] MIC(K, message_fields_requiring_integrity_protection).

[0257] When the core network receives the message 110 , the core network first decrypts the key K using the private key corresponding to the encryption public key, and then checks whether the received MIC matches the MIC calculated locally using the decrypted key and the received fields in the received message 110 .

[0258] Note that the public key is linked to a private key owned by the home (serving) network, which can then notify the serving (home) network of a failed authentication.

[0259] Note that the MitM may still "replace" the encryption key with a different key K' it desires, and then include the MIC calculated with K' and the modified message fields in the case that the SUPI and K are not encrypted together, for example. To avoid this, the key K can be placed next to the fields that need to be verified or used in a subsequent authentication process, such as the SUPI, and both the key K and such fields will be encrypted and / or integrity protected together. Then, when the SUPI is decrypted / verified, the key K is also decrypted / verified. If an attacker interferes with and tries to replace the combined encryption of the SUPI and K, the attacker will fail because the attacker does not know the SUPI. Ideally, this public key encryption process provides strong guarantees against chosen ciphertext attacks (CCA).

[0260] Note that it is also beneficial if the key is encrypted alongside a parameter that prevents replay attacks, such as a nonce or a time-based counter (e.g., a UTC value). Otherwise, it may be feasible for an attacker to replay a previous message where, for example, some message field is used that is beneficial to the attacker, such as a weak choice of UE security capabilities.

[0261] Note that this embodiment may require the exchange of UE security capabilities received by the AMF in the Initial UE Message NAS-PDU: Registration Request in Nausf_UEAuthenticate_authenticate Request sent from the AMF to the AUSF and including the SUCI, so that if the UDM returns an integrity key to the AUSF, the AUSF can verify the integrity check.

[0262] Additionally or alternatively, it may be necessary to send the UE security capabilities from the AUSF to the UDM in a Nudm_UEAuthenticate_Get Request message so that the UDM can perform the above-mentioned integrity verification.

[0263] Additionally or alternatively, it may be necessary to send the key K to the AMF which has received the UE security capabilities so that the AMF performs the integrity verification.

[0264] Note that this embodiment may require the UE to determine the key K and calculate the MIC on the UE security capabilities field exchanged between the UE and the AMF, for example, in the initial UE message NAS-PDU: Registration Request. The AMF may need to cache this information until the key K is received from the AUSF at a later stage (for example, in Nausf_UEAuthenticate_authenticate Response), and the AMF may verify the received UE security capabilities based on the received MIC and key.

[0265] The specific message flow of this variant embodiment is as follows:

[0266] 1.UE calculates the random key K.

[0267] 2. The UE uses K to calculate the MIC based on its selected UE security capabilities.

[0268] 3. The UE sends the UE security capabilities and MIC to the AMF via the gNB in ​​the initial message (e.g. NAS Registration Request).

[0269] 4. The UE sends the encrypted concatenation of SUPI and K (in the following SUCIK) to the AMF in the NAS Identity Response, where the encryption is performed as in TS 33.501 (Annex C.3).

[0270] 5.AMF forwards the SUCIK to AUSF in the Nausf_UEAuthenticate_authenticate Request.

[0271] 6.AUSF interacts with UDM to retrieve SUPI and K from SUCIK.

[0272] 7.AUSF returns SUPI and K to AMF in Nausf_UEAuthenticate_authenticate Response.

[0273] 8.AMF verifies UE security capabilities based on the received K and MIC.

[0274] Note that some fields may be sent earlier or later, for example, the MIC may also be sent to the AMF in step 4. In this embodiment variant, if an attacker modifies the SUCIK, the MAC tag value verification of the SUCIK will fail. If an attacker changes the SUCIK, the MIC verification will fail. If an attacker modifies the UE security capabilities, the MIC verification will fail.

[0275] Note that instead of having to generate a random key K, encrypt the generated random key K, and send the encrypted key K, the UE may also use other fields that have been transmitted as encryption keys used in the MIC calculation. Note that this is only a feasible approach if these fields are long enough and difficult to predict (e.g., randomized), otherwise it would be feasible to guess these fields from the sent MIC. Note that the SUCI protects (encrypts) the MSIN of the SUPI. The MSIN is 10 digits, so it may be too short. Note that this method may also be combined with the above methods involving generation / encryption / exchange of the key K, with the advantage that the encryption key K that needs to be sent may be slightly shorter.

[0276] Generally, the above embodiments provide an apparatus for protecting communication with a second device, wherein the apparatus is configured to perform the following steps:

[0277] (a) encrypting a randomly generated symmetric key using a first public key linked to a private key owned by the second device, and

[0278] (b) Sending a message and an encrypted symmetric key to a second device. Specifically, the device can be used to integrity protect the information exchanged with the second device in the first message, and can calculate a message integrity code on certain information (which requires protection in the first message), and send the information and the message integrity code to the second device. In particular, in the device, the information can be a security capability. In particular, in the device, the message can be an attachment or registration request. In particular, the first device can include the device. In particular, the device can encrypt / integrity protect a symmetric key and a secret identifier (e.g., SUPI), which, once decrypted / integrity verified, the receiver uses to retrieve a root secret (e.g., K_AUSF) for performing a subsequent authentication process. In particular, the device can encrypt / integrity protect a symmetric key and parameters that can prevent replay attacks. In particular, the device can use an encryption algorithm that is secure against selected ciphertext attacks.

[0279] Example 10

[0280] If the message 110 is exchanged in a protected (confidentiality protected) manner, the attack is not feasible because the attacker may not know how to modify the information in the message 110 in a meaningful way. This can be achieved by using a public key owned by the core network 104 (e.g., a public key owned by the home network and used to encrypt the SUPI, as described in clause 6.12.2 and Annex C of TS 33.501) to encrypt the information in the message 110 (e.g., UE security parameters), which will be sent in a secure manner to the core network 104. When the core network receives the message 110, the core network uses the private key corresponding to the encryption public key to decrypt the encrypted fields of the received message 110.

[0281] We note that this approach - compared to the approach in the above embodiments, e.g., embodiment 3 - may be more easily circumvented by an attacker. The reason is that the encrypted message may be malleable, and thus an attacker may know how to flip certain bits (which swaps out the UE's security capabilities) based on the UE's expected security capabilities.

[0282] Embodiment 11

[0283] The above embodiments, such as embodiments 9 and 10, describe the integrity / confidentiality protection of parameters (e.g., UE security capabilities) that are susceptible to modification by symmetric keys encrypted using the public key of the home network. An alternative is to generate a shared secret (e.g., a Diffie-Hellman-based shared secret as described in other embodiments (e.g., embodiment 12) and use that key or a key derived therefrom to integrity / confidentiality protect those parameters, e.g., immediately adjacent to the SUPI. The UE then sends its encryption and / or integrity protection to the core network for decryption and integrity verification, thereby allowing secure retrieval of those parameters.

[0284] The specific but exemplary message flow of this embodiment is as follows:

[0285] 1. The UE concatenates the SUPI and the parameters to be protected (e.g. UE security capabilities) into a message M.

[0286] 2. The UE protects the message M, for example as in TS 33.501, Annex C.3. This protected message is denoted PM.

[0287] 3. The UE sends a PM to the AMF, for example in a NAS Identity Response.

[0288] 4.AMF forwards the PM to AUSF, for example, in Nausf_UEAuthenticate_authenticate Request.

[0289] 5. AUSF interacts with UDM to retrieve SUPI and parameters from PM.

[0290] 6. The AUSF returns the SUPI and parameters to the AMF, for example in Nausf_UEAuthenticate_authenticate Response.

[0291] 7.AMF uses / verifies parameters (e.g. UE security capabilities).

[0292] If an attacker modifies the PM, the protected parameters and SUPI cannot be decrypted / integrity verified and the attack therefore fails. The attacker cannot replace the PM to contain incorrect parameters because the attacker does not know the UE's SUPI. If the attacker attempts to do so, the attacker will use the wrong SUPI and primary authentication will fail.

[0293] Generally, the above embodiments provide an apparatus for protecting communication with a second device, wherein the apparatus is configured to perform the following steps:

[0294] (a) deriving a first symmetric key using a first public key linked to a private key owned by a second device,

[0295] (b) creating a message containing the UE identifier and other parameters that need to be securely exchanged and / or authenticated,

[0296] (c) computing a protected message by using the first symmetric key or a key derived therefrom to encrypt and / or integrity protect the message,

[0297] (d) Sending a protected message to the second device.

[0298] In particular, the device can be used to integrity protect parameters or information exchanged with a second device in a first message. In particular, in the device, the information can be a security capability. Specifically, in the device, the first message can be an attachment or registration request. In particular, the first device can include the device. In particular, the device can encrypt / integrity protect parameters and a secret identifier (e.g., SUPI), which, once decrypted / integrity verified, the receiver uses to retrieve or derive a root secret (e.g., K_AUSF) for performing a subsequent authentication process. In particular, the device can encrypt / integrity protect parameters and parameters that can prevent replay attacks. In particular, the device can use an encryption algorithm that is secure against selected ciphertext attacks.

[0299] Example 12

[0300] exist Figure 3 In the attack scenario described in , the middleman (e.g., consisting of a fake base station and a fake UE) is located between the UE and the gNB. In an embodiment related to embodiment 9 or 10, the UE can randomly generate a key K and encrypt it with the long-term public key of the home network. The home network can then decrypt it and share it or a key derived from it with the radio access network (RAN) (e.g., the base station that handles the UE's access). This shared key between the UE and the gNB can be established earlier than KgNB and therefore provide earlier protection between the UE and the gNB, such as Figure 6 Shown, for example, is protection against MitM.

[0301] Alternatively, the key K may also be based on a DH (Diffie-Hellman) key generated by a temporary key pair (prK_UE, puK_UE) generated by the UE and a long-term key pair (prK_HN, puK_HN) of the home network. For example, the key K may be prK_UE*puK_HN=prK_HN*puK_UE (derived from prK_UE*puK_HN=prK_HN*puK_UE).

[0302] exist Figure 6, the UE 600 establishes a connection with the base station 601 in step 604. It then sends an initial message 605 to the core network, which is forwarded to the entity handling the registration and mobility of the UE (e.g., 5GAMF 602) in message 606. Messages 605 and 606 include a key K generated by the UE 600 and encrypted with the public key of the core network. In particular, function 603 can store a private key for decrypting the key K when received in message 607. In step 608, function 603 can send the key K or another key K' encrypted with K or another key K' derived from K to the network function 602, which will securely share the key K with the base station 601 in step 609. The base station can extract the key, such as K. The UE and the base station can then protect message 611, for example, as indicated in embodiment 16.

[0303] Whether the base station 601 supports the use of K may be broadcast in the system information distributed by the base station.

[0304] Whether the UE may need to establish keys may be based on policies deployed on the UE by the home network.

[0305] In general, the above embodiments provide an apparatus for protecting communication with a second device (eg, a base station), wherein the apparatus is configured to perform the following steps:

[0306] (a) encrypting a (randomly generated) symmetric key using a first public key bound to a private key owned by a third device (e.g. the core network or a sub-entity of the core network), and

[0307] (b) Sending the first message and the encrypted symmetric key to the third device

[0308] (c) securely communicate with a second device using a generated key or a second key derived from the key or a second key decrypted by means of the key. Specifically, the device can be used to integrity protect information exchanged with a third device in a first message, and can calculate a message integrity code on certain information (which requires protection in the first message), and send the information and the message integrity code to the third device through the second device. In particular, in the device, the information can be a security capability. In particular, in the device, the message can be an attachment or registration request. Specifically, the first device (e.g., UE) can include the device. Specifically, the above embodiment provides a method for protecting communication between a first device (UE) and a second device (e.g., a base station), wherein the first device uses a first public key linked to a private key owned by a third device (e.g., a core network) to encrypt a randomly generated symmetric key, and the first device sends a first message including the encrypted symmetric key to the third device, and the third device sends a second key to the second device, wherein the second key can be a received key or a key derived from the received key or a key encrypted by means of the received key, and the first device and the second device use the second key to communicate securely.

[0309] Embodiment 13

[0310] In various embodiments, authentication and key agreement may be modified such that the UE and gNB may derive K_gNB for 5G as described in TS 33.501 in clause 6.2.2.1 earlier than is currently possible in 5G.

[0311] Generally speaking and with reference to Figure 1, the core network (103) may have obtained a shared key SK derived from a master secret MS shared between the UE (100) and the home core network upon receipt of the initial message 111. The MS may be stored in the USIM. The shared key SK may be derived as currently done, for example, to generate the entire key hierarchy (e.g., K_AUSF, K_SEAF, K_AMF, K_gNB), or may be generated directly from the master secret MS using, for example, a random number or time value (e.g., UTC time or name of the serving network) generated by the UE (100) and the CN (103) or some parameters associated with the gNB as input, or may be derived from K_gNB as a temporary secret used only in the initial exchange of messages. The core network 103 may then securely send the derived key SK (e.g., an earlier generated K_gNB or a different key derived from the MS) to the RAN (e.g., gNB). The core network may further send the parameters (100) required by the UE to derive the SK in messages 112 / 113. If the SK depends on, for example, an existing key hierarchy, the UE (100) may first be required to process the incoming message 113 and perform all authentication / freshness checks before the SK can be used. This may also apply if the SK is derived in a different way. If the SK is derived in a different way, additional checks may also be applicable, for example, whether the random number sent by the UE in the message 110 is used for key derivation, or whether the time parameters used for key derivation and signaled by the core network (103) are fresh, for example, matching the current time of the UE. It should be noted that the CN entity / function (e.g. AUSF, SEAF or AMF) may not be aware of the fact that the UE has generated all keys while the CN entity has not yet received the corresponding keys because the current authentication process is not useful.

[0312] Embodiment 14

[0313] In a related embodiment related to deriving the key K based on Diffie-Hellman (DH), Fig.10 The process of deriving such a key is shown. It may involve one or more of the following steps:

[0314] Step 1: UE generates a temporary public key pair.

[0315] Step 2: Based on the Diffie-Hellman key exchange protocol, the UE calculates a temporary shared key based on the public key of the HN and its temporary private key that it has stored.

[0316] Step 3: UE derives a temporary symmetric key (Symkey) and a temporary MAC key based on the temporary shared key for encryption and integrity protection of SUPI. At this stage, the UE can derive another key Ks=f(ESK,EPK), where ESK and EPK represent temporary shared keys, and UE represents a temporary public key.

[0317] Step 4: Using the symmetric key (Symkey), the UE encrypts the MSIN, and then it uses the MAC key to calculate a message authentication code (MAC) to ensure the integrity of the SUCI.

[0318] Step 5: The UE sends a SUCI to the serving network (SN), which contains its temporary public key, ciphertext and MAC.

[0319] Step 6: The SN sends the received SUCI together with the Serving Network Name (SNN) to the Home Network (HN). The HN extracts the UE's temporary public key from the SUCI and uses its private key to perform steps 2 and 3 to derive the symmetric key, MAC key, and K s =f(ESK,EPK).

[0320] Step 7: HN verifies the integrity of SUCI through the MAC value, and then uses the symmetric key to hide SUCI to retrieve SUPI.

[0321] Step 8: When verifying whether the UE is allowed on the network, the HN generates a Home Environment Authentication Vector (HE AV), derives a Service Environment Authentication Vector (SE AV), and then combines it with K s Send to SN together.

[0322] Step 9: Send NAS_authentication_request to UE. s The authentication request message or a key derived therefrom may be used to protect the authentication request message, for example, at the application, PDCP, RRC, MAC or physical layer.

[0323] Embodiment 15

[0324] According to TS 23.502, when a UE is performing an initial registration, it shall indicate its identity to the PLMN in the Registration Request message. The UE's identity corresponds to the 5G-GUTI (if available), otherwise the UE shall include its SUCI in the Registration Request as defined in TS 33.501.

[0325] TS 33.501 6.12.4 specifies when the Subscriber Identification mechanism (Identity Request) can be invoked. That is, when the temporary identifier 5G-GUTI cannot identify the UE, that is, when the AMF is able to retrieve the SUPI based on the 5G-GUTI, the Subscriber Identification mechanism is skipped.

[0326] Since the DH (Diffie-Hellman) generated key proposed in the above embodiments (e.g., Embodiment 12) is based on a temporary key pair (prK_UE, puK_UE) and a long-term key pair (prK_HN, puK_HN) of the home network, the temporary public key puK_UE needs to be sent to the home network to generate a DH-based key. If SUCI is included in the Registration Request message, puK_UE is retrieved by the home network and the DH-based key is derived. However, if the UE transmits a 5G-GUTI in the Registration Request message and the AMF manages the retrieval of the SUPI corresponding to the 5G-GUTI received from the UE, the SUPI is forwarded to the home network together with the serving network name, and the temporary public key puK_UE required to derive the DH-based key is not transmitted.

[0327] To ensure that the temporary public key puK_UE is always sent to the home network, the UE may generate a temporary public key pair after RRC connection establishment, and the Registration Request message may be modified to include puK_UE in addition to the 5G-GUTI. Alternatively, the SUCI may be included so that if the AMF retrieves the SUPI using the 5G-GUTI, the puK_UE is extracted and sent together with the SUPI and the Serving Network Name (SNN). Otherwise, the AMF forwards the SUCI and SNN to the home network, which then extracts puK_UE via the Subscriber Identifier De-hiding Function (SIDF) in the UDM.

[0328] In additional or alternative embodiments that may be used independently, the authentication process (e.g., primary authentication) may include the following steps:

[0329] – The first time during which the authentication procedure is performed, the UE uses an encrypted identifier (e.g., SUCI), and the UE may use the public key to protect any additional sensitive fields, e.g., security capabilities,

[0330] - Once the authentication process is successfully completed, the home network provides the UE with a temporary identifier (pseudonym) and a temporary secret, such as a symmetric key,

[0331] - A subsequent time, if an authentication procedure needs to be performed, the UE may use the pseudonym and the temporary secret, where the pseudonym may be used, for example, by the AMF (e.g., in a VPLMN) to identify the UE and the temporary secret may be used to protect sensitive fields.

[0332] In an embodiment variant, the UE may use the pseudonym and the temporary secret if, for example:

[0333] - the UE can retrieve it from the security context,

[0334] - The UE is (pre-)configured with policies by the network.

[0335] The main difference in this embodiment is the allocation of a temporary secret. This secret can be used in subsequent authentication processes without relying on / using the public key, resulting in improved performance. This secret can be used, for example:

[0336] - securely send the UE's location to, for example, the HPLMN to determine whether the user agrees to share the location with the VPLMN,

[0337] - Safely protect security capabilities,

[0338] …

[0339] In an embodiment variant, the temporary secret may be used to protect the communication between the UE and the HPLMN and / or between the UE and the VPLMN or both.

[0340] In an embodiment variant, the temporary secret / key may be used to derive a plurality of secrets / keys, for example by means of a key derivation function, for example for the HPLMN or for the VPLMN; for example for encryption and integrity protection.

[0341] In an embodiment variant, if a temporary secret is to be used to protect the communication between the UE and the VPLMN, the HPLMN shares the temporary secret with the VPLMN, for example together with the allocated GUTI.

[0342] In an embodiment variant, if sensitive fields require protection from the UE to the HPLMN, the secret is not shared with the VPLMN.

[0343] In a variant embodiment, if the pseudonym / temporary secret is used at a subsequent time, for example, when authentication needs to be performed again, the VPLMN / HPLMN may reallocate a new pseudonym / temporary secret.

[0344] - If the UE sends some data to the HPLMN, the HPLMN can assign a new pseudonym / temporary secret and inform the VPLMN.

[0345] - If the UE sends some data to the VPLMN, the VPLMN may provide the HPLMN confirmation of such data sharing and the VPLMN may assign a new pseudonym / temporary secret which may have been determined by the HPLMN.

[0346] - If the HPLMN / VPLMN needs to send some data to the UE, the HPLMN / VPLMN may allocate a new pseudonym / temporary secret.

[0347] In a variant embodiment, the temporary secret is used with a given encryption algorithm (e.g., NEA) or integrity algorithm (e.g., NIA), which can be negotiated / indicated / configured when the temporary secret is configured and / or when the temporary secret is used.

[0348] In an embodiment variant, the message protected with the temporary secret comprises metadata (eg an input field (eg a counter) in the NEA or NIA algorithm) for protecting the message by means of the corresponding encryption / integrity algorithm.

[0349] In an embodiment variant, if the temporary secret is reused multiple times in order to prevent the UE / CN from having to maintain state (e.g., the value of a counter), the temporary secret is used as a root secret for deriving one or more keys (e.g., encryption keys and / or integrity keys), for example, with the aid of a key derivation function and other fields (e.g., a random number or a UTC-based counter). The derived keys are then used to protect the messages, and the fields used in the key derivation function are included in the exchanged messages.

[0350] Example 16

[0351] The communication is protected, for example, at an earlier stage, by applying a key established, for example, as in connection with embodiments 12 or 13. Figure 6 Specifically, the established keys can be used to derive protection for messages exchanged between the UE and the base station (e.g., Figure 6 Control plane keys for integrity and / or confidentiality of message 611).

[0352] An alternative is to use the established key K to protect the communication link at a lower layer (e.g., MAC or physical layer). To this end, K can be used to derive one or more keys of the lower layer, for example, by applying a KDF. Additional input parameters to the key derivation function may include layer, communication direction (e.g., uplink), time counter (e.g., UTC-based or based on a communication counter such as SFN), etc. For example, for the MAC layer, a specific MAC CE in message 611 and later MAC CEs may be protected, which may involve multiple functions / variants.

[0353] First, it may be necessary to indicate which MAC CEs are protected, e.g.

[0354] (1) including a mask in / in each message, e.g., if the message includes four MAC CEs, the mask may consist of 4 bits, where a bit set to 1 indicates that the MAC CE is protected, and / or

[0355] (2) exchanging policies indicating protection requirements, e.g. from the UE to the base station or from the (home) core network to the (serving) base station, so that the mask does not need to be exchanged in every message, and / or

[0356] (3) Pre-configured policies, for example in the USIM, which indicate which MAC CEs are (to be) protected.

[0357] Second, it may require agreement on the algorithms used for protection, e.g.

[0358] (1) Define a single algorithm in a standard specification, where an algorithm refers to an encryption scheme and / or an integrity protection scheme, and / or

[0359] (2) Including preferences in messages 605 and 606 , where the preferences may be integrity protected, and the preferences may be indicated in messages 608 and 609 .

[0360] Third, it may be necessary to store a policy in the UE so that the UE, for example, rejects incoming messages from a base station if they are not protected as expected or if the message is processed in a particular way. The rejection or processing may also depend on the message type.

[0361] Fourth, if an incoming message from a UE is not protected as expected, a policy to reject the incoming message may need to be stored in the base station.

[0362] Fifth, it may be necessary to generate a message integrity code on the protected MAC CE. This can be done, for example, by: (1) using an integrity algorithm (e.g., NIA) and appending the MIC to the message, or (2) using a key derivation function that has as input the message fields that need to be protected and a counter (e.g., a counter identifying the message or SFN) or a counter based on UTC time.

[0363] Sixth, it may be necessary to generate an encryption stream that can be used to encrypt the selected MAC CE field, which can be done by using a KDF with a derived key, a counter for freshness, and a counter for generating a key stream of arbitrary length as input. The output of the KDF is used to XOR the selected MAC CE.

[0364] Seventh, it may be desirable to place protected MAC CE fields adjacent to each other to facilitate processing of the message (eg, encryption and decryption).

[0365] Eighth, it can apply the lightweight authentication and encryption scheme as ASCON or ASCON based on the protection of MAC CE.

[0366] Ninth, ASCON takes as input a key, a random number, and an initialization vector. The initialization vector can depend on a counter, such as SFN. The random number can depend on an unencrypted field.

[0367] Tenth, ASCON returns TAG. If integrity protection is required, a subset of the bits of TAG (eg, the least significant bits) can be used as MIC.

[0368] Eleventh, the generated key (for example, in Figure 1 During the authentication and key establishment phase in 5G (e.g., primary authentication in 5G), a long key, such as a 256-bit key, may be used. Such a longer key may be required to ensure long-term security in the presence of quantum computers. However, for performance reasons, the protection algorithm for the MAC CE field may only take a shorter key (e.g., a 128-bit key) as input. Therefore, the key hierarchy may be such that the short key is derived from the long key. This embodiment variant may also be independently applied to other security processes in the cellular network, for example, at the PDCP layer.

[0369] Twelfth, if a long key is derived or obtained during the initial authentication and key establishment phase and a shorter key is derived / obtained from the long key, e.g., with the aid of a key derivation function, then multiple (e.g., 2) short keys may be obtained by a single call to the key derivation function, e.g., if the key derivation function returns an output of the same length as the long key, and the long key has twice the length of the short key. These multiple short keys may be used:

[0370] (1) in subsequent use (e.g., 128 LSBs at time t0, subsequent 128 bits at time t1), and / or

[0371] (2) for different purposes (e.g., 128 LSBs are used as a key to protect uplink communications, and 128 MSBs are used as a key for downlink communications), and / or

[0372] (3) for different purposes (e.g., using the 128 LSBs as encryption keys and the 128 MSBs as integrity keys) and / or

[0373] (4) for different communication planes (e.g., using 128 LSBs in the control plane and 128 MSBs in the user plane) and / or

[0374] (5) For different purposes in encryption / integrity algorithms (e.g., ASCON) (e.g., 128 LSBs are used as keys and 128 MSBs are used as NONCEs).

[0375] The advantage of the above process is that fewer calls to the KDF are required, which improves performance.

[0376] This embodiment variation may also be independently applied to other security procedures in the cellular network, for example, at the PDCP layer.

[0377] This embodiment (e.g., protection of the MAC CE field) can be applied using other keys. For example, a key derived from the KgNB of 5G can be used to protect the MAC CE field.

[0378] Example applications requiring protection of the MAC CE field may include, for example

[0379] (1) Protecting control messages at L1 or L2 used to control smart repeaters, such as beamforming of smart repeaters,

[0380] (2) protection of messages exchanged below the RRC layer (because those messages are not protected in 5G R17), and for example for releasing a UE connected to an IAB node or mobile base station once the IAB node (or mobile base station) determines that the radio link with the parent node has failed,

[0381] (3) “SCell Activation / Deactivation MAC CE” can be used to deactivate communications on the SCell, so the UE will not be able to receive data on the affected SCell.

[0382] (4) Incorrect “TCI state indication for UE-specific PDCCH MAC CE” and / or “TCI state activation / deactivation for UE-specific PDSCH MAC CE” may be used to request the UE to adjust the Rx beam towards a direction that is not conducive to receiving signals from the gNB.

[0383] (5) A fake “Aperiodic CSI Triggering State Subselection MAC CE” may be used to select a codepoint that is not intended to be used by the base station, thereby creating a misalignment between the gNB and the UE in terms of CSI feedback.

[0384] In general, the above embodiments provide an enhanced device for protecting communication with a second device, wherein the device is configured to securely exchange at least one message with the second device using a key or a second key or a key established / derived from a root key associated with an access device (e.g., KgNB). In particular, the message may be a layer two (L2) message. Specifically, the message may be a MAC CE (field). In particular, the device may rely on a policy configured by a third device to determine which messages require which type of protection. Specifically, the device may include a mask indicating which fields are protected in the exchange message. Specifically, a first device (e.g., UE) may include these devices. The above embodiments also provide a method for protecting communication between a first device and a second device, wherein the method uses a key or a second key or a key established / derived from a KgNB to securely exchange at least one message between the first device and the second device, wherein the message may be a MAC CE field, and wherein the first device and the second device may have been configured with a policy by a third device that determines which messages require which protection.

[0385] Cellular networks rely on multiple types of encryption and integrity algorithms. For example, NEA algorithm (clause D.2 in TS33.501), NIA algorithm (clause D.3 in TS33.501) or algorithm for hiding subscription permanent identifier (clause C in TS33.501). These algorithms are configured to achieve 128-bit security. However, with the advent of quantum computers, it is foreseeable that new algorithms will be introduced to provide 256-bit security (classical level). For example, ETSI SAGE has been developing new 256-bit algorithm security. For this reason, the SAGE group develops new 256-bit algorithms - including radio interface encryption and integrity algorithms (for both user plane and control plane services) and authentication and key agreement (AKA) algorithms - to provide long-term resistance to possible future quantum computing attacks in 5G systems. If necessary, these same 256-bit algorithms can also be potentially retrofitted to previous generation mobile systems. In TDoc S3-230642, ETSI SAGE informed SA3 that the specifications for Snow5G, AES-256, and ZUC-256 do not require further evaluation from SAGE. Even if new algorithms are introduced, it is not possible to simply deprecate existing algorithms. For performance reasons, more resource-constrained devices may only support algorithms with 128-bit keys, existing keys or new keys, such as ASCON. For performance reasons, even high-end devices may prefer to rely on algorithms with 128-bit keys, especially for high data rates.

[0386] Supporting 256-bit security algorithms may require changing (e.g., adding padding to some parameters and / or changing the maximum length values ​​of some parameters) the lengths of input and / or output parameters to utilize such algorithms. Where necessary, if variable length keys are supported (e.g., to maintain backward compatibility with legacy systems), the KDF may output a variable length key that may be split, e.g., into two 128-bit keys, or truncated, e.g., to only the first or last 128 bits, or start from a random index that may, e.g., be determined by one communicating party and communicated to the other communicating party or mutually agreed upon.

[0387] In an embodiment that can be used independently, the KDF can be based on SHA-3 as in FIPS202 or SHA-3 derivation functions as in NIST SP800-155. For example, the KDF can rely on the SHA-3SHAKE(M, d) function, which allows a variable number of d bits to be output given an input M. For example, the KDF used relies on the SHA-3cSHAKE(M, d, N, S) function, which allows a variable number of d bits to be output given an input M, with a personalized string S and a function name bit string N. For example, the KDF used can rely on SHA3 KMAC(K, X, L, S), where K is the input key, X is the input string, L is the number of bits required, and S is the personalized string. For example, given an input, the KDF can use the XOF function to derive another key. For example, SHA-3KMACXOF256(K, X, L, S) can be used, where a 256-bit key K is used with a given personalized string S. This has the advantage that keys of different lengths can be easily generated.

[0388] In an embodiment that can be used independently, the message integrity code (MIC) used in the telecommunications system (e.g., in the MIC used at the PDCP layer or in the MAC CE protocol) can be based on SHA-3 as in FIPS202 or a SHA-3 derived function as in NISTSP 800-155. Specifically, it can be based on SHA3 KMAC (K, X, L, S), where X can correspond to the message for which the MIC needs to be calculated, K corresponds to the key used to calculate the MIC, S corresponds to the personalized string, and L corresponds to the preferred output length.

[0389] In an embodiment, the introduction of the 256 encryption algorithm may require the use of a new general key derivation function different from the general key derivation function in Appendix B.2 of TS33.220. The KDF can take as input a key (similar to TS33.220), a string S (similar to TS33.220), and a desired output length L (i.e., KDF (key, S, length)). This can be implemented as LSB (HMAC-SHA-256 (key, s), b), where LSB (a, b) returns the b least significant bits of a. This can be implemented as cSHAKE (key, length, "", S).

[0390] In a related embodiment, the KDF may also include an input parameter indicating the use, i.e., KDF(key, S, use, length), and may allow the same key to be used for different purposes. This may be implemented as cSHAKE(key, length, use, S).

[0391] In one embodiment, if different key lengths are supported, the communicating parties (e.g., user equipment, access device, network function, application function, etc.) may need to negotiate which key lengths are supported and / or used. These may be provided or configured, for example, by a policy that specifies which keys, input parameter lengths, and / or output key lengths, and / or KDFs are to be used for which purpose / function.

[0392] In an embodiment, the application or communication layer or device may indicate the required key length to the communicating parties. For example:

[0393] - When the AF requests the K_AF key from the AAnF, the AF may include the key length required by the K_AF in the key request. This is necessary because different protocols, such as TLS, OSCORE, etc. may rely on ciphertexts using 128 or 256 bit keys, and the telecommunications system must be able to return keys of different lengths, such as 128 or 256 bit keys.

[0394] -When the UE establishes a secure communication link with the core network (NAS security) or the access device (AS security), the device and / or the core network (home network and / or access network) and / or the access device indicates the required / feasible security level, for example, AS security or NAS security in the PDCP layer. For example, when the PDCP layer requires user plane integrity or confidentiality protection, the PDCP layer may be configured with a given required security level (e.g., 128 or 256 bits) and the security algorithm is selected accordingly.

[0395] In an embodiment that can be used independently, the network (e.g., AMF or access device) and / or UE may be configured to use a high security level (e.g., 256-bit security), but the network entity (e.g., AMF or access device) and / or UE may not be able to handle it, for example, because the network is overloaded. In this case, the network entity (e.g., AMF or access device) and / or UE may indicate / signal the abnormal state, for example, in a SIB (e.g., SIB1) and / or an RRC message and / or a NAS message. The abnormal state may allow the network / UE to use a 128-bit security (encryption) algorithm instead of a 256-bit security (encryption) algorithm.

[0396] In embodiment variations, 256-bit security algorithms and keys may always be preferred unless the communicating parties are subject to conditions requiring a downgrade to 128-bit security algorithms and / or keys (eg, backward compatibility).

[0397] The UE may be configured with a given policy by the HPLMN, or may have certain preferences regarding the use of 256 or 128 bit algorithms. However, when roaming, the UE may be located at or accessed by a VPLMN which may have different preferences or capabilities. Therefore, as long as the UE is in said VPLMN, the UE needs to determine which VPLMN to join, the VPLMN and the HPLMN need to agree to security requirements and / or the HPLMN may need to configure a temporary policy for the UE. To address these requirements:

[0398] In an embodiment variant, the network may indicate (e.g. in an SIB or RRC or NAS message or an initial authentication procedure (e.g. primary authentication)) the preferred and / or supported security algorithms, in particular (e.g. 256 bits or 128 bits), so that the UE can use this information to select a network suitable for its communication needs. When the UE receives the indication, the UE may check whether the indication complies with its current policy and select / reject the connection. For example, if the UE observes three access devices (gNBs), one of which supports only 256-bit security and another supports 128-bit security and another supports both 128 and 256-bit security, the UE may prefer (based on policy) to select one of them, such as the last one. The policy may be configured by the HPLMN and may be stored in the UDM.

[0399] In a variant embodiment, the UE may indicate (e.g., in an RRC establishment request, or in a registration request, e.g., in security capabilities) preferred and / or supported security algorithms, in particular (e.g., 256 bits or 128 bits), so that the UE can use this information to select a network suitable for its communication needs, and / or an access device or network entity (e.g., AMF) can evaluate and determine whether it can serve the UE.

[0400] In a variant embodiment, the UE / HPLMN may indicate to the VPLMN the required / provided security level (e.g., 128 or 256 bit security), and / or the VPLMN may indicate to the HPLMN / UE that the VPLMN (e.g., a given access device) is (not) able to provide a given security level. For example, when the UE needs to use a 128 bit encryption algorithm, the access device may not support the 128 bit encryption algorithm (this security level is deprecated). Or on the other hand. These indications may trigger a temporary reconfiguration of the UE or access device to provide the service, wherein the temporary reconfiguration may be recorded.

[0401] In an embodiment variant, the supported security algorithms are indicated by a single bit index, for example: 0 indicates a supported 128-bit algorithm, and 1 indicates a supported 256-bit algorithm.

[0402] In a variant embodiment, the preferred security algorithm is indicated by a single bit index, for example: 0 indicates support for 128-bit algorithms, and 1 indicates support for 256-bit algorithms.

[0403] In an embodiment variation, the preferred security algorithm may be indicated by a 2-bit index, for example: 00 indicates support for 128-bit algorithms, 01 indicates support for 256-bit algorithms, 10 indicates support for both 128-bit and 256-bit algorithms, and 11 is reserved for future use.

[0404] In an embodiment variant, the preferred algorithm is indicated by the indicated ordering of the supported algorithms. For example, if the security algorithms are named NEA0, NEA1, NEA2, NEA3 (as in TS33.503) and NEA4, NEA5, NEA6 corresponding to, for example, Snow5G, AES-256 and ZUC-256, the UE can indicate its preference to the network by transmitting a list including supported / preferred algorithms, where the ordering indicates the preference, for example, NEA5, NEA4, NEA6, NEA2, NEA1. This will indicate that the UE supports these five algorithms, and the most preferred one is NEA5 (the first in the list), and the least preferred one is NEA1 (the last in the list).

[0405] In Annex A.7 in TS33.503, it is described how to provide message-specific confidentiality protection for discovery between ProSe UEs. In this specific example, a 256-bit key is used to derive the key, from which the 128 least significant bits are used as input to a 128-bit encryption algorithm as in TS33.501 (Annex D). If a 256-bit encryption algorithm is introduced, this truncation (using 128 least significant bits as the key) may not be needed. In some cases, it may happen that two entities decide to use a 256-bit algorithm, but the KDF output used to feed the 256-bit algorithm is not well aligned, and the KDF output is still truncated to a 128-bit key. Therefore, the security level will be lower than expected. In order to address these shortcomings:

[0406] In another embodiment, whether the 256-bit key is truncated (generally, whether a subset of bits is selected) is determined by the selection / use of a 256-bit algorithm (not truncated) or a 128-bit algorithm (truncated). For example, Appendix A.7 in TS33.503 should state that the input parameters of the encryption algorithm are as described in Appendix D in TS33.501 [3], where KEY is KDF(DUCK, UTC-based counter, MIC, security level), for example, LeastSignificantBits(KDF(DUCK, UTC-based counter, MIC), security level), and the security level refers to the security level of the selected encryption algorithm (128 or 256), and determines the returned key length. This embodiment can be combined with other embodiments and shows the benefits of having a new generalized key derivation function that takes the desired key length / output size as input.

[0407] In additional or alternative embodiments, the key derivation function outputs a key of a desired size, the key derivation function takes as input the desired key length (e.g., 128 or 256 bits), and uses it as input in the KDF itself.

[0408] In an additional or alternative related embodiment, the key derivation function may also indicate the desired security strength and the desired output size. This may allow for a single KDF definition that allows for the determination of the security strength (e.g., 128 or 256) and includes the output size KDF(key, security_level, output_key_size). This may be achieved, for example, by using the underlying building blocks of SHA-3 (FIPS202), i.e., Keccak, e.g., KDF(key, security_level, output_key_size) = KECCAK[2*security_level](key|suffix, output_key_size), where "|" indicates concatenation with the suffix (e.g., for domain separation).

[0409] The advantage of introducing a new generic key derivation in a more transparent way defining output key length and / or security strength and / or purpose etc. (compared to the current KDF definition in TS33.220) is that it facilitates the use of multiple encryption algorithms with different key sizes and reduces the risk of misconfiguration.

[0410] In additional or alternative embodiments, the level of security and / or functional output size may be implicitly determined based on the results of the communicating parties (e.g., end users and UE-to-UE relays) negotiating which algorithms to use (e.g., 256 bits or 128 bits).

[0411] Embodiment 17

[0412] The above-described embodiments may be adapted to facilitate improved security in non-terrestrial networks (NTNs). In particular, use cases of interest relate to NTN UEs deployed to geographical borders, as different countries may require different regulations. Since the UE is connected to the NTN via a satellite link, it is difficult for the satellite to determine the specific location of the UE, and the UE may need to disclose its location or a rough location. The 5G system (5GS) may use this location information to improve operation, for example, assigning the right AMF to the UE. A specific method of implementing this capability is to exchange the (rough) location of the UE in message 110, such as Figure 1 However, this message is not protected and therefore, the disclosure of the UE location represents a privacy risk.

[0413] The above embodiments (eg, embodiment 10) may be adapted to enable NTNUE to be protected in NAS (or AS) security (eg, in Figure 1 The UE encrypts its (rough) location before establishing it in message 110 in TS 33.501, thereby ensuring optimized operation of the 5GS without introducing privacy risks. The protection of the (rough) UE location information can be done in a similar way as in Annex C in TS 33.501. It can be processed as indicated in C3.2.

[0414] In embodiments referring to e.g. 5g standalone access registration, the NTN gNB may not be able to select an AMF at the time of RRCSetupComplete because the gNB does not know where the UE is located and the UE has disclosed its (coarse) location in a protected message (e.g. within RRCSetupComplete). Therefore, the NAS-PDU Registration Request may include a protected field, the protected field including the UE location information. This is the field received from the UE including its protected (coarse) UE location information. If this field is included in the NAS-PDU Registration Request, the initial request may be routed to the (default) AMF, which will request the (default) AUSF, which will ask the UDM to decrypt the UE location information field to be transmitted to the (default) AMF. The (default) AMF will then trigger, for example, a Namf_Communication_UEContext_Response to select a suitable AMF based on the received UE location information. Additionally, the (default) AMF may notify the (NTN) gNB of the new AMF. Alternatively, the (default) AMF may share the received UE location information with the NTN gNB which will perform AMF selection as usual. The (default) AMF is the AMF to which (all) NTN NAS-PDU Registration Requests are routed when, for example, the NAS-PDU Registration Request includes a protected field containing UE location information.

[0415] In an alternative embodiment and with reference to e.g. a 5g standalone access registration, the NAS Identity Response will include a protected field containing the UE location information. In this case, the response may be processed by the (default) AMF and the (default) AUSF, where the (default) AUSF is the AUSF to which (all) NTN NAS Identity Responses are routed when, for example, the NAS Identity Response includes a protected field containing the UE location information. The (default) AUSF will then request the UDM to retrieve the encrypted UE location information (and possibly the SUPI). Given the decrypted UE location information, the (default) AUSF may forward this information to the (default) AMF, which may select an appropriate AMF and trigger a Namf_Communication_UEContext_Response to the appropriate AMF. Additionally, the (default) AMF may notify the (NTN) gNB of the new AMF.

[0416] In further embodiments that may be combined with the above embodiments or used independently, the network and RAN may require (check) user consent for disclosing UE location information. The user consent preference may have multiple conditions, such as if a specific RAN or AMF is allowed to obtain the UE's location information or not, a specific area where consent may be granted / granted, a time window where consent may be granted / granted, etc. The exchange of protected UE location information may be used as an implicit user consent preference verification, and when it is received by the UDM, the UDM may check the user consent preference regarding NTN access, for example in the UDR (Unified Data Register). The UDM may then use this user consent preference to adjust its response to the remaining entities (e.g., AMF or RAN). Specifically, the UDM may:

[0417] Loss of UE location with lower accuracy,

[0418] • If for example AMF or RAN is not allowed, then the disclosure of UE location is rejected.

[0419] Check whether the UE location can be made public at the current time.

[0420] This method allows the UE to disclose its coarse location in a secure manner, even if the UE does not know whether the user has allowed this information to be disclosed. The message received by the UDM is then checked against the user consent policy to adjust the response.

[0421] Therefore, according to this embodiment, a method is proposed that can be implemented in a user equipment, the method for requesting access to network resources, comprising sending the user location with rough accuracy in a protected manner for a data manager to check whether the user of the user equipment agrees to disclose the information. In another aspect of the invention, the data manager receives the user location with rough accuracy in a protected manner and checks whether the user agrees to disclose the information. The check may include checking under which conditions the agreement is given. In another aspect of the invention, if the user consent is affirmative, the data manager provides the location of the user equipment to a third entity (e.g., RAN or AMF).

[0422] In a related embodiment that may be combined with the previous embodiment, sharing of user location information may be performed when primary authentication is established, e.g., NAS and / or AS security is established. This may also be done before performing primary authentication. The user location may be exchanged in a protected manner to ensure that it is protected end-to-end until the home network, e.g., using a key derived from K_AUSF. This ensures that NFs in the path that are not allowed to access data according to user consent preferences do not access it.

[0423] Fig. 9An embodiment is described in which entities 900 (UE), 901 (gNB / RAN), 902 (AMF), 903 (AUSF), 904 (UDM) interact to retrieve the user location in a privacy-aware manner and in accordance with user consent preferences, where not all steps are always required. Step 905 represents primary authentication. This step may include encrypted (coarse) location information encrypted end-to-end between, for example, 900 and 903 (or 904), for example, protected with a key shared between those entities (e.g., the public key of the home network). Steps 906 and 907 represent NAS security establishment and AS security establishment. In step 908, entity 901 may request the user's (coarse / specific) location. In step 908, entity 900 may provide its (coarse) location. Since user consent has not yet been verified, it may provide a (coarse) location encrypted end-to-end between 900 and 903 (or 904), for example, protected with a key shared between those entities (e.g., KAUSF). Entity 903 and / or 904 retrieves the (rough) location upon receiving message 909 (or 905). Entities 903 and 904 may interact in steps 910 and 911 to check user consent to distribute the location information to node 901 / 902. In particular, in step 910, a request to check consent may be sent, and entity 904 may check the consent with a result returned in step 911 (entity 904 is an enforcement point). Alternatively, in step 910, a request including an encrypted (rough) location may be sent to check consent, and entity 904 may decrypt and check the consent (entity 904 is an enforcement point), thereby returning a result in step 911. Alternatively, in step 910, a request may be sent to retrieve a user consent policy, and entity 904 may return the policy so that entity 903 may evaluate it (entity 903 is an enforcement point). If node 901 / 902 is authorized, the location information is shared in step 912. Entity 903 may also configure node 901 / 902 with a policy that determines when node 901 / 902 is allowed to request / retrieve / receive / process location information from node 900. The policy may include, for example, a time window during which requesting / retrieval / receiving / processing location information is allowed. In this embodiment, location sharing may be done in step 905 or step 909 or both. It is also possible that in step 905 or step 909, location sharing is done with very low accuracy to facilitate the RAN to make a first decision, for example, regarding AMF selection, while sending a higher accuracy location to the core network in a secure manner.

[0424] In a related embodiment, the UDM may send a Nudm_SDM_Get response to the AMF, which includes a user consent preference for UE location information for NTN access, so that the AMF stores the user consent preference in the UE context or replaces its stored user consent preference with the user consent preference received from the UDM. In addition, the AMF may send an N2 message (e.g., an initial context establishment request) to the NG-RAN, which includes a user consent result or user consent preference for NTN access in addition to the registration acceptance. In addition, after receiving the N2 message, the NG-RAN may store the user consent result or user consent preference in its UE context. Based on the received user consent result / preference, the NG-RAN may determine how to implement the user consent with the appropriate configuration on the UE. In addition, the NG-RAN may send an RRCReconfiguration message (including registration acceptance and location configuration information) to the UE. If user consent for location reporting is granted, the NG-RAN sends a configuration for the UE to report its location (e.g., via includeCommonLocationInfo in reportConfig); if user consent for location reporting is not granted, the NG-RAN does not send such a configuration.

[0425] In addition, the user may not have granted consent to disclose its UE location to certain NG-RAN or AMF, but the NG-RAN or AMF may be able to modify the above message, and in some cases, a malicious NG-RAN or AMF (e.g., in a VPLMN) may implement different user consent preferences in order to obtain the UE location. Therefore, in addition, the (user consent) configuration sent to the UE to report its location (or other data, such as personally identifiable information) may also include an end-to-end integrity check. For example, a MIC or a digital signature. In the case of a MIC, it can be a MIC calculated with a key derived from a key shared between the UE and the home network (e.g., a key derived at primary authentication, such as K_ausf or a key derived from a key in 5G).

[0426] In with Fig.12 In a related embodiment variant, entities 1200 (UE), 1201 (gNB / RAN), 1202 (AMF), 1203 (AUSF), 1204 (UDM / UDR) interact to retrieve user location (or other personally identifiable information) in a privacy-aware manner and in compliance with user consent preferences. Not all of the following steps or exchanged data fields may always be required:

[0427] - The UE sends its (optionally) encrypted (coarse) position to the RAN in step 1205. This message may include the GUTI and / or the SUCI.

[0428] In step 1206, the RAN forwards the (optionally) encrypted (coarse) location including its GUTI and / or SUCI to the AMF.

[0429] In step 1207, the AMF forwards the (optionally) encrypted (coarse) location to the AUSF.

[0430] In step 1208, the AUSF forwards it to the UDM, which may proceed to decrypt it (if encrypted) and retrieve the user consent policy related to the NTN service. The UDM may also retrieve the SUPI. The UDM may decide that the user consents to sharing the location information based on, for example, at least one of the SUPI, the retrieved policy, the serving network, or (optionally) the decrypted location.

[0431] • In step 1209, the UDM returns to the AUSF the user consent decision and / or user consent preferences and / or location (if decrypted) and / or a token verifiable by the UE upon user consent decision.

[0432] The AUSF provides the user consent decision and / or user consent preference and / or location (if decrypted) and / or token to the AMF in step 1210. Depending on the location, the AMF may (proactively) trigger a NG handover to change to an appropriate AMF and deregister the UE (1201), compared to clause 16.14.6 in TS 38.300 where for example such NG handover is triggered by the gNB / RAN.

[0433] In step 1211, the AMF provides the user consent decision and / or token (1201) to the gNB / RAN.

[0434] In step 1212, the gNB / RAN (1201) provides the token to the UE (1200) along with a request to retrieve the user location. The UE may verify the user consent decision with the help of the token, and if positive, the UE may execute the request and start providing its location, for example, once AS security is established.

[0435] In a related embodiment variant of independent interest, the AMF actions in step 1210 may be used independently or in combination with other solutions (e.g., solution #1 in TR33.886). For example, if the AMF receives a user consent preference indicating that a given AMF located in a given country is not preferred, the AMF is required to deregister the UE. Similarly, the AMF may trigger a NG handover to an appropriate AMF.

[0436] In a related embodiment variation, the location and SUPI may need to be encrypted adjacent to each other, as in embodiment 9 above.

[0437] exist Fig.13 In the illustrated variant of the related embodiment, messages 1205 and 1206 correspond to a NAS Identity Response, and message 1207 is a Nausf_UEAuthenticate_authenticate Request, and message 1208 is a Nudm_UEAuthenticate_Get Request. In this case, the authentication process is only started when the HPLMN UDM determines that the UE is authorized to communicate using the serving network and when the user consents to preferences allowing sharing of the user location with the network for a given current UE location. It should be noted that the UE can determine whether the NAS Identity Response should include only the encryption of the SUCI or SUPI and the (coarse) location, as the UE can know the type of RAN it is accessing, for example by observing SIB1. In a first alternative, the user consent preferences and UE location reporting configuration can be exchanged and confirmed to the UE via a primary authentication message flow as in the above embodiments (e.g., embodiments 1 or 2). In the case of embodiment 2, message 1209 is Nudm_UEAuthenticate_Get Response, message 1210 is Nausf_UEAuthenticate_authicateResponse, message 1211 is N2 message, and message 1212 is authentication request. Fig.12In a general description of the embodiment 1.2, the token exchanged between the AUSF and the UE is a MAC including the new UE location reporting configuration calculated in Example 1.2. The configuration is also included in the Nausf_UEAuthenticate_authenticate Response message (from AUSF to AMF) and the authentication request (from AMF to UE) so that the UE can apply it and verify it. In a second alternative, if the UDM / UDR performs this check, it is feasible to distribute the keys derived from K_ausf to the AMF and RAN (e.g., K_AMF or K_gNB), which allows protecting RRC messages, such as RRCReconfiguration messages (e.g., message 1212), for securely notifying the UE about the new UE location reporting configuration. This is done once the primary authentication is successful, only if the UE location is known to the entity evaluating the user consent preference at the point in time when the primary authentication is started. It should be noted that this is advantageous compared to alternatives such as solution #1 in TR 33.896. In this solution, the AMF retrieves the UE consent policy, but this AMF may be in the serving network and since the SUPI is available in step 5, this means that primary authentication has been performed and the AMF already has the appropriate keys to derive K_gNB and therefore sends the RRCReconfiguration message. However, in this solution, this decision is taken without access to the UE location, while the UDM / UDR may benefit from knowing it. In addition, the right AMF can only be selected after AS establishment once the UE starts reporting location.

[0438] exist Fig.13In this related embodiment variant, in step 1, the UE sends an encrypted NAS Identity Response containing the SUPI and the (rough) location. In step 2, the AMF sends a Nausf_UEAuthenticate_authenticateRequest to the AUSF to retrieve (i.e., decrypt) the SUPI and location. In step 3, the AUSF relies on the UDM / UDR to (i) retrieve (i.e., decrypt) the SUPI and UE location, (ii) access the NTN user consent preferences, and (iii) evaluate whether the user has consented to disclose his location to the RAN / service network based on the user consent policy, the RAN / service network location. In step 4, if consent is granted, the UDM / UDR sends the SUPI, location and user consent preferences to the AUSF. In step 5, the AUSF starts primary authentication while providing the location and user consent preferences to the AMF. If necessary, the AMF can trigger the AMF relocation procedure. In step 6, the AMF sends a message to the RAN providing the user consent preferences and location. And in step 7, once the UE has been configured with K_gNB, the RAN can request the UE to provide its location periodically, and the RAN can securely send the RRCReconfiguration message. It should be noted that compared to solution 1 in, for example, TR33.896, this solution is also applicable to mobility situations.

[0439] Embodiment 18

[0440] The above embodiments (e.g., Embodiment 17) are also applicable to related use cases where the user is required to consent to the use of personally identifiable information, e.g., for network optimization.

[0441] For example, in 3GPP Release 18, research on the artificial intelligence (AI) / machine learning (ML) framework for NG-RAN was performed, and the results were recorded in TR37.817. Three main use cases are included, namely AI / ML-based network energy saving, load balancing, and mobility optimization, with the goal of optimizing the network. These three use cases require the location collection of the UE (e.g., at the cell level or coordinate granularity), making user location tracking a privacy issue that may require user consent, depending on local regulations.

[0442] The technical solutions in the above embodiments, such as Embodiment 17, may be applied to force users to agree to obtain and use personally identifiable information for network optimization.

[0443] For example, according to an embodiment, a device and method that can be implemented in a user device are proposed, which is used to use a data manager to check whether the user of the user device agrees to disclose information, for example, using some network entities, and the data manager provides a protected reply to the user device regarding the user's consent preference (so that the network entity cannot modify it).

[0444] Depending on the options of the device, the network entity may be in the VPLMN (e.g., RAN or AMF in the VPLMN) and the data manager may be in the HPLMN (e.g., UDM or AUSF).

[0445] At the option of the device, the reply is protected with a MIC calculated using a symmetric key derived, for example, or based on K_AUSF.

[0446] Depending on the device's options, the reply may be protected with a digital signature.

[0447] Embodiment 19

[0448] The above embodiments (e.g., 17 and 18) describe situations where the UE may need to disclose its location or rough location (e.g., for AMF selection or network optimization), and privacy protection measures are taken to protect the disclosed information, where the user consent (UC) request is only processed by the HPLMN.

[0449] With reference to 5G independent access registration, the VPLMN (e.g., AMF) may need access to the precise location of the UE (e.g., to forward the UE to a more appropriate AMF). Therefore, in an embodiment, as long as the UE has been configured (e.g., in the UE local UC preferences) to disclose its location during the registration request, a message such as a NAS-PDU registration request may include a protected field containing the UE location information. The VPLMN (e.g., AMF) may request the HPLMN (e.g., AUSF and UDM) to decrypt the UE location information field and transmit it to the VPLMN.

[0450] Alternatively or additionally, according to, for example, embodiments 14 and 15, a secret key (e.g., K_UC) may be derived based on the shared temporary key of the UE and the HN to encrypt the UE location information field within the registration request. Upon receiving the registration request, the VPLMN (e.g., AMF) may forward the SUCI for the HPLMN (if included in the registration request) or the UE's temporary public key (if 5G-GUTI is included instead) to derive the user consent key K_UC and send it back to the VPLMN (e.g., SEAF), which may then decrypt the UE's information location field. Different user consent keys may be derived for each user consent purpose. In both cases, the request to the HPLMN to decrypt the UE's location information field or to derive K_UC may be used as proof that the VPLMN has obtained and recorded the user consent.

[0451] In an alternative embodiment and with reference to, for example, 5G standalone access registration, the UE may transmit its user consent preferences to the VPLMN only in the registration request. The UE's user consent (UC) preferences may be subject to similar protection measures as the UE's security capabilities covered in the previous embodiments. In addition, these preferences are provided to the VPLMN (e.g., AMF) to cover different conditions regarding requests made by other network entities (e.g., RAN / gNB, network functions (NFs) or AFs in the VPLMN) to obtain sensitive information (e.g., precise location) of the UE. The UE's UC preferences may have multiple conditions, such as if a specific RAN or AF or NF is allowed to obtain the UE's information (e.g., location information) or not for a given purpose, a specific area where consent may be granted / granted, a time window where consent may be granted / granted, a purpose for which UC may be granted / granted, etc. After having transmitted its preferences in a message (e.g., a registration request), the UE may (depending on its preferences) include its UC related information (e.g., location information) in a protected field of the NAS Identity Response, which may be protected (e.g., encrypted) using, for example, the same key that protects the SUPI. Alternatively, the key may be protected (e.g., encrypted) using another key derived from the temporary shared key (e.g., K_UC). Similar to the previous embodiment, the VPLMN (e.g., AMF) should request the HPLMN to verify / decrypt the UE user consent information (e.g., location information data) and send it back, or derive K_UC and send it to the VPLMN (e.g., AMF) to verify / decrypt the user consent information (e.g., UE location information) field. In both cases, the request made to the HPLMN can be used as proof that the VPLMN has obtained and recorded the user consent and / or preference.

[0452] In a further embodiment, which may be combined with or used independently of the above embodiments, when the UE provides its UC preferences at an earlier stage (e.g., a registration request), the VPLMN is required to verify the UE preferences and / or check these UC preferences before disclosing and / or processing and / or requesting any sensitive information collected from the UE, for example, when interacting or communicating with the RAN or other network entities (e.g., NF or AF). For example, when the AF requests the location information of the UE, the VPLMN (e.g., AMF) may:

[0453] -Disclose the location of the UE with low / high accuracy.

[0454] - If, for example, AF is not allowed or the purpose for which the request is made does not match the UE's UC preference, the disclosure or the UE's location is rejected.

[0455] - Check if the UE's location can be disclosed at the current time.

[0456] As mentioned before, this approach allows the UE to disclose its (rough) location in a secure way, even if the UE does not know whether the user has allowed this information to be disclosed. Requests received by the VPLMN (e.g. AMF) from other entities (e.g. RAN or AF) are checked against the UC policy to tailor the response. This approach has the advantage that user consent verification remains in the domain of the VPLMN.

[0457] In a related embodiment, before the UE provides its UC preferences to any network entity, the user may be prompted with a user consent page before, during, or after the authentication process, where the preferences are selected and saved locally on the UE and transmitted to the network. The location of the user consent page (e.g., URL) or the page itself may be transmitted to the UE via system information or during the initial access process. The user may choose to opt-in to request a user consent page to adjust his or her user consent preferences compared to the network's default user consent preferences. The user may select this through a configuration in the UE. The user may also choose to accept the network's default user consent preferences. The UE may transmit its UC preferences (agree or disagree) as a bit mask for each selected CE option. If the UE does not transmit its UC preferences, the network may assume that the default network UC preferences are accepted.

[0458] In a related embodiment, which may be used independently or in combination with other embodiments, a network (e.g., a VPLMN) may provide a request to the UE to accept / adjust UC preferences signed with a private key associated with the network (e.g., a private key owned by the network) so that it may be used as proof of UC selection towards a second network (e.g., a HPLMN) or entity.

[0459] These UC preferences may be considered as default and / or selected preferences provided by the UE, for example, in a registration request or upon request. For information requests that fall outside the scope of the UC policy or for UC requests made by the HPLMN during identification / authentication, the VPLMN (e.g., AMF) and / or the HPLMN may send a UC update request to the UE, redirecting it to a consent page where the user may select one or more of the following options, and where the selected options may be protected, as described in other embodiments:

[0460] - Provide UC and update UC policy to address similar future requests.

[0461] - UC is provided only for that specific request, for the specific network entity making the request and / or for a limited time.

[0462] -Rescind the UC and update the UC policy to address similar future requests.

[0463] - Revoke UC for that specific request only.

[0464] The method allows the UE to control and verify the conditions governing the UC policy, such as what information is disclosed, to which network entities, and for how long.

[0465] In a further embodiment that may be combined with the above embodiment, the VPLMN (e.g., AMF) may be configured to periodically check for updates in the UE's UC preferences (e.g., upon reauthentication); the AMF may send a UC update request to the UE in a NAS Identity Request, to which the UE responds by including the (updated) UC policy in a protected field in the NAS Identity Response. Alternatively, the UE may be configured to provide its (updated) UC preferences in, for example, a Registration Request. In this case, the VPLMN (e.g., AMF) is to check whether it has a UC policy recorded and associated with the UE, if so, it updates it accordingly, otherwise, it records the UE's UC preferences. The UC preferences may be associated to the UE by means of its SUPI / GUTI / SUCI or other identity (e.g., RAN identity). Instead of sending a UC update request, for example, in a NAS Identity Request, the network (e.g., VPLMN, e.g., AMF) may send an acknowledgement that it has stored / updated the UE's UC preferences. If the network (e.g. VPLMN, e.g. AMF) has a mapping between 5G-GUTI and SUPI, or if the Registration Request contains SUCI (i.e. no NAS Identity Request is sent), the VPLMN (e.g. AMF) may send its confirmation to the UE together with, e.g., a NAS Authentication Request. In both scenarios (i.e. (updated) UC preferences provided by the UE or upon network request), the network records the UC preferences and / or other UC related information (e.g. location) if provided, and how to obtain them (i.e. by the UE or upon request).

[0466] In a related embodiment, the VPLMN (e.g., AMF) may be required to report to the HPLMN (e.g., UDM) any UC policies or updates it receives from the UE, or any requests to obtain these UC preferences (updates) and / or user consent related information (e.g., location). If the UE sends its UC preferences (e.g., in a registration request), the VPLMN (e.g., AMF) may forward these UC preferences to the HPLMN (e.g., UDM) with the SNN and SUPI / SUCI for, for example, decryption, which may record the UE's UC preferences and the VPLMN that received them. Similarly, if the UE shares its UC preferences and / or UC information (e.g., location, regardless of accuracy), for example, protected in a NAS identity response field, the VPLMN may forward the UE's protected response to the HPLMN, which may then decrypt / verify the UE's protected response and send it back to the VPLMN (e.g., AMF), or send a key to the VPLMN (e.g., SEAF), which may then decrypt / verify the UE's UC preferences / information and provide it to the relevant entities (e.g., RAN, AMF, NF, AF, ...). Regardless of the means and nature of the information transmitted (i.e., UC policy or location), the VPLMN may be required to provide the information to the HPLMN. In addition, the HPLMN (e.g., UDM) may request from the VPLMN (e.g., AMF) that the recorded UC policies and the corresponding UE identifiers to which they are linked be provided to it for the purpose of verifying that the VPLMN is applying UC as intended.

[0467] According to this embodiment, a method that can be implemented in a UE is proposed, which is used to request access to a network source, including sending user consent preferences and / or UE user consent information (e.g., location) in a protected manner for a data manager to check whether the user of the UE agrees to disclose his or her information, for example, to other network entities.

[0468] In another aspect of the present invention and method, a data manager that receives the UE's UC preferences in a protected manner checks whether the user consents to disclose the information. The check may include checking the conditions for granting consent. In another aspect, if the UC is granted, the data manager discloses sensitive information (e.g., location) to a third party (e.g., RAN or AF) UE.

[0469] According to this method, a network entity (e.g., AMF) in the VPLMN may maintain a record of the means (i.e., how) and network entity (e.g., AF) by which UE information (e.g., location) is requested.

[0470] According to the method, the network entity in the VPLMN (e.g., AMF) that records the user's consent may provide proof to the HPLMN (e.g., UDM) that it has recorded the user's consent. Providing such proof to the HPLMN may be triggered by receiving a user consent response / decision, which is then forwarded to the HPLMN, or the user consent response / decision is forwarded to the HPLMN upon request by the HPLMN.

[0471] According to this approach, if the HPLMN requires user consent (e.g., during identification / authentication) to disclose information (e.g., location and / or personally identifiable information) or for a UC request made to the VPLMN that falls outside the scope of the UC policy it has in storage, the HPLMN / VPLMN may send a UC request to the UE that redirects it to a consent page where the user of the UE selects their preferences for handling that request and potentially future similar requests.

[0472] According to this approach, the UE may push updates to the VPLMN regarding any changes to its UC preferences (or the VPLMN may request changes). The VPLMN may be required to provide proof to the HPLMN that its UC policy has been updated. Therefore, the HPLMN should be able to verify that the VPLMN is applying user consent as expected (e.g., by requesting the VPLMN to provide its user consent record, i.e., the UE identifier and the UC policy associated therewith).

[0473] Embodiment 20

[0474] In the above embodiments, the UE 100 may include fields in the message 110 indicating which fields are encrypted or integrity protected or how subsequent verification procedures are to be performed (eg, which checks should be calculated).

[0475] This field may be a pre-configured value, for example, determined in the standard or based on the UE version (eg, a specific version in a telecommunications standard), or it may be based on a security policy configured in the UE.

[0476] If this field relates to integrity / confidentiality protection of certain fields, this field may relate to a mask indicating which fields are integrity or confidentiality protected.

[0477] When a MIC is present in, for example, message 110, it may be implicitly determined whether the message is integrity protected.

[0478] Embodiment 21

[0479] 3GPP Release 18 includes a new study item on home network triggered primary authentication, where the home network can trigger the authentication process. The reason for triggering this authentication can be to check whether the UE has established a secure link with an appropriate security level (e.g., not affected by MitM).

[0480] In this case, in an embodiment, the home network may, based on currently known information (e.g. identity or security capabilities) of the UE it wants to authenticate / verify, send message 113. This may require deriving new challenges xRES* and HXRES*, e.g. as indicated above.

[0481] In a further embodiment, the message may include a field indicating that it is a home network triggered authentication request so that the UE knows that it must include some information, such as its desired security capabilities and / or current security capabilities, when calculating the response RES* or parameters for calculating such a response.

[0482] Upon receiving this message, the UE may reply with a message 114 including the calculated RES* as described in other embodiments (eg, Embodiment 1).

[0483] In a further embodiment, if the home network does not know all UE parameters and / or wishes to verify certain UE parameters, the home network may include in the message 113 an indication of the parameters (eg, security capabilities) that need to be sent again.

[0484] The message 113 may include a MIC calculated using a key and a timer (e.g., a UTC-based counter) shared between the UE and the home network in order to allow the UE to verify that the reauthentication request is from its home network and that it is a new request. The message may include the least significant bits of the UTC time so that the UE can obtain the exact UTC-based counter used in the calculation of the MIC.

[0485] Alternatively, a new message sent from the home network to the UE may be defined, which includes some of the above elements and requests the UE to start again the authentication procedure started with the exchange of messages 110 .

[0486] In further embodiments, if the home network may want / need to verify the compliance of the device / UE, the home network may trigger a primary authentication where the requesting device returns at least one of the following:

[0487] -Device type, such as chipset ID.

[0488] - Software version,

[0489] -3GPP capabilities

[0490] - a fingerprint of a portion of the firmware (e.g., hash / MAC / HMAC),

[0491] Some of the above actions may be completed by a trusted module (eg, USIM) in the device.

[0492] For example, the above information may be returned by the USIM alongside the MIC, which is calculated using a shared key shared between the UE and the home network, where the shared key is stored in the USIM such that the device / UE cannot modify it.

[0493] For example, if the home network requires a fingerprint of a portion of the device's firmware, the USIM may receive the request from the home network and request the fingerprint of its firmware from the device. The USIM may return the fingerprint or an enhanced fingerprint calculated from a previous fingerprint and some additional metadata (e.g., an HMAC of a previous fingerprint and some metadata). The metadata may include the timing required to obtain the fingerprint.

[0494] Embodiment 22

[0495] When the home network triggers a re-authentication procedure, e.g. to verify security parameters or to generate security keys K_AUSF or K_SEAF, e.g. in case of mobility from 4G to 5G, the re-authentication procedure may fail even if the UE (already) has an active connection. If this happens, the updated unauthenticated state of the UE needs to be handled.

[0496] This may involve one or more of the following embodiment variations:

[0497] Going through the authentication process, e.g., a maximum number of times, or, e.g., using a different authentication method, e.g., 5G AKA or other when EAP-AKA previously failed.

[0498] · Link the authentication confirmation to the Nudm_UECM_Registration procedure from the AMF, as in TS 33.501 clause 6.1.4.1a. Specifically, the AUSF may request the failed (or successful) authentication status from the storage in the UDM at the time of the home triggered authentication. The fact that it is a home triggered authentication may be recorded. The reason for triggering the home triggered authentication may also be recorded, such as K_AKMA update or 4G to 5G mobility, etc. In the event of an authentication failure when the UE is connected, the UDM will trigger the removal of any authorization to the AMF / SEAF (similar to step 4 in clause 6.1.4.1a in TS 33.501). In this case, the UDM may also remove any authorization to the AAnF and therefore the AF for communicating with the UE via the AKMA.

[0499] Embodiment 23

[0500] When the home network triggers the re-authentication process, in some cases (e.g., in case of mobility from 4G to 5G), the home network may not be aware of the 5G identity that may be needed to retrieve security parameters from the UDM to trigger the authentication process.

[0501] Therefore, in a further embodiment related to, for example, embodiment 1, a new message sent from the home network to the UE may be defined, which requests the UE to restart the authentication process started with the exchange of message 110. This includes requesting again to exchange UE security capabilities, 5G identifiers (e.g., 5G SUCI) or other fields in other embodiments, such as:

[0502] -User consent preferences,

[0503] - (rough) location

[0504] – Parameters required for device compliance,

[0505] …

[0506] In an embodiment variation, the home network (or UE) may determine that the primary authentication has failed if one or more fields do not conform to a given policy that may have been configured on the device and / or the home network. This may trigger a release of the UE / network.

[0507] Alternatively, a decision to request a new authentication process may be made at the AMF. The decision may also be based on policy. For example, when the AMF is responsible for the UE moving from a 5G network, the policy may determine whether the AMF must trigger a re-authentication process for the home network that assists the UE. In this case, the AMF may create a request for the UE to re-authenticate starting with the exchange of message 110. The request sent by the AMF may be a NAS security message, such as a UE configuration update or de-registration process.

[0508] Embodiment 24

[0509] Currently, the AKMA keys cannot be updated without re-running the authentication and key agreement phase 106. It may be desirable to update the AKMA keys without doing this.

[0510] Therefore, in an embodiment, this can be done by generating a new AKMA key at the AuSF that depends on, for example, the VPLMN identity and / or a counter and / or a random number and / or the (UTC) time. This can be achieved by extending the definition of the AKMA key derivation function in A.2 of TS 33.535, also including some of these parameters (and associated lengths) in the input string S of the KDF. For example:

[0511] - FC = 0xXX;

[0512] -P0="AKMA";

[0513] - L0 = length of "AKMA" (i.e., 0x00 0x04);

[0514] - P1 = UE ID;

[0515] - L1 = length of UE ID.

[0516] -P2=VPLMN

[0517] -L2 = length of VPLMN

[0518] -P3 = UTC time

[0519] -L3 = UTC time length

[0520] In a variant embodiment, the newly added parameters in the above example are VPLMN and UTC time. VPLMN can be a different identifier that identifies the serving network. UTC time can also be a random number or counter to ensure that different AKMA keys are generated. As in TS 33.535, the input key KEY can be a master key derived from the primary authentication, i.e., KAUSF in 5G, and UE ID refers to a unique UE identifier, such as SUPI in 5G.

[0521] Note that in further embodiments, when Kakma is updated, Kaf may also need to be updated as currently in TS 33.535 or using embodiments of the present invention.

[0522] This embodiment Figure 44, where UE 400 performs primary authentication and derives Kakma and Kaf in step 405, involving AMF / SEAF 401, AuSF 402, AaNF 403, and AF 404. In step 406, Kaf expires, and AF 404 may send a request 407 to (serving) AaNF 403, which forwards the request 407 to the (home) AuSF in step 408, which may proceed to generate a new Kakma for AaNF in step 409 and may send it to AuSF in step 410. AaNF may then derive a new Kaf in step 411 that is shared with Kaf in step 412. AaNF may notify the (home) network and UE in step 413, and in step 414, UE and AF may interact again in a secure manner. Specifically, in step 413, the service network (AaNF) may first notify the home network of the key AF update, which then proceeds to notify the UE of the key AKMA and AF key update. Upon successful verification / reception of message 413, the UE updates Kakma and Kaf. Message 413 includes parameters required for the UE to update these keys. Message 413 may be a NAS security message or a message sent by AuSF.

[0523] Embodiment 25

[0524] Currently, the AF key cannot be updated without re-running the authentication and key agreement phase 106. It may be necessary to update the AF key. This can be done by generating a new AF key at the AaNF based on the current AKMA key depending on, for example, the AF identity and / or a counter and / or a random number and / or the (UTC) time. This can be achieved by extending the definition of the AKMA key derivation function in A.2 of TS 33.535, also including some of these parameters (and associated lengths) in the input string S of the KDF. For example:

[0525] - FC = 0xXX;

[0526] -P0=AF_ID;

[0527] - L0 = length of AF_ID

[0528] - P1 = UE ID;

[0529] - L1 = length of UE ID.

[0530] -P2=VPLMN

[0531] -L2 = length of VPLMN

[0532] -P3 = UTC time

[0533] -L3 = UTC time length

[0534] As in TS 33.535, the input key may be a key used to derive an AF key, such as Kakma and AF_ID may refer to an AF identifier, which may be included in the AF, as in TS 33.535, which is a security protocol used on the Ua* interface. In addition, it may include the VPLMN and / or a unique counter / random number / UTC time used by the AF to access the device.

[0535] This embodiment Figure 5 504, wherein the UE 500 performs primary authentication and derives Kakma and Kaf in step 505, involving AMF / SEAF 501, AuSF 502, AaNF 503 and AF 504. In step 506, Kaf expires, and AF 504 may send a request 507 to the (serving) AaNF 503, which may proceed to generate a new Kaf in step 508 and send it to the AF in step 509. The AuSF may (periodically) update Kakma in step 510, for example, based on a counter used in the KDF, and periodically share it with the AaNF. Thus, a given Kakma may be limited in time, and this time limit may be applied / propagated to the Kaf derived from it. This has the advantage that the home network remains in control. When Kaf is updated, the AaNF may notify the (home) network and the UE in step 511, and in step 512, the UE and the AF may interact again in a secure manner. In particular, in step 511, the serving network (AaNF) may first notify the home network of the key AF update, which then proceeds to notify the UE of the key AF update. Upon successful verification / reception of message 511, the UE updates Kaf. Message 511 may include parameters required for the UE to update Kaf. Message 511 may be a NAS security message or a message sent by AuSF.

[0536] Embodiment 26

[0537] In a related embodiment that can be combined with other embodiments or used independently, the UE is served by a serving PLMN (SPLMN) and the UE attempts to access an AF in a home PLMN (HPLMN). In this case, the SPLMN can host a SAAnF, which can receive a K_AKMA derived from the K_AUSF at the AUSF.

[0538] In embodiment variations, in some scenarios (eg, when communications may need to be intercepted for lawful interception purposes), the HPLMN (eg, HAAnF) may need to send the K_AF to the SPLMN upon generation.

[0539] In a further embodiment variant, the SPLMN may signal the LI requirement to the HPLMN.

[0540] In a further embodiment variant, the SPLMN (eg AMF) may then use the received K_AF to access the services exchanged between the UE and the AF.

[0541] According to the above embodiments, a method is proposed, by which a VPLMN / SPLMN obtains access to services exchanged between user equipment (served by the SPLMN / VPLMN) attempting to access an AF in the HPLMN, wherein the method includes: the VPLMN optionally signals a lawful interception requirement to the HPLMN, and the HPLMN provides key material (e.g., K_AF and other parameters) to the VPLMN, and then the VPLMN (e.g., SEAF) uses the provided key material to decrypt the intercepted services exchanged between the UE and the AF.

[0542] According to the above embodiments, a method is proposed by which the HPLMN provides key material to a network function in the VPLMN to be responsible for collecting AKMA key material for lawful interception purposes.

[0543] Embodiment 27

[0544] In a related embodiment, which may be used in combination with or independently of other embodiments, the UE is served by a VPLMN and the UE attempts to access an AF in the VPLMN and the (H / V)PLMN has LI requirements for UE communications.

[0545] In this case, the VPLMN may be required to intercept the communication for lawful interception purposes. This is possible because the VPLMN knows all the root keys used for communication between the UE and the AF.

[0546] In an option, upon interception, the VPLMN may be requested to forward the decrypted traffic to the HPLMN.

[0547] In another option, the VPLMN is requested to reroute the intercepted encrypted traffic to the HPLMN, and to deliver the K_AKMA or K_AF used to protect the traffic or the parameters (eg, counters) used to derive them to the HPLMN.

[0548] According to the above embodiments, a method is proposed by which the HPLMN is given access to services exchanged between UEs served by a VPLMN and attempting to access an AF in the VPLMN, wherein the method includes the HPLMN signaling a LI requirement to the VPLMN, and then the VPLMN forwarding the decrypted services to the HPLMN, or alternatively, in addition to the encrypted services, the VPLMN also forwards key materials (e.g., K_AKMA, K_AF and other parameters) to the HPLMN.

[0549] According to the above method, another method is proposed which can be combined with other methods, and through this method, key materials (eg, K_AKMA, K_AF) can be provided based on the pull / push mechanism and the LI requirements of the PLMN.

[0550] Embodiment 28

[0551] In some scenarios, the home network (e.g., UDM) may be able to trigger the primary authentication process at any time based on local (operator) policy or a request from a NF (e.g., AUSF, AAnF), and may be described by the following steps. Note that some steps may be performed in a different order, some steps may be optional, and some steps may be performed multiple times:

[0552] - Step 1: The UDM may be pre-configured with local policies that determine when to trigger the primary authentication process; or

[0553] - Step 2: The NF (e.g., AAnF) may send a request (e.g., Nudm_HNAuthentication_Authenticate_request) to the UDM, which may include at least one of SUPI, GPSI and / or another UE identifier to trigger a primary authentication procedure for the target UE, for example, to refresh K_AKMA, or to perform key update for other procedures such as UPU, SoR.

[0554] - Step 3: Based on the received request and / or its local policy, if UDM can trigger primary authentication, then UDM identifies the serving AMF / SEAF of the target UE, otherwise, UDM sends a Nudm_HNAuthentication_Authenticate_Response message with failure cause.

[0555] - Step 4: If the serving AMF / SEAF of the target UE is identified, the UDM sends a request (e.g., Namf_HNAuthentication_Authenticate Request) message containing the identifier of the UE to the AMF / SEAF.

[0556] - Step 5: Based on the request of UDM, if the serving AMF / SEAF can start primary authentication, it sends a response (e.g., Namf_HNAuthentication_Authenticate_Response) message with a success indication to UDM, otherwise, Namf_HNAuthentication_Authenticate_Response contains the failure reason

[0557] - Step 6: If the serving AMF / SEAF sends a success indication to the UDM, it may start the primary authentication procedure with the target UE.

[0558] -Step 7: Based on the result of the primary authentication, the UDM may send a response (e.g., Nudm_HNAuthentication_Authenticate_Response) message containing a result indication to the NF requesting the home network to trigger the primary authentication (HONTRA). If the primary authentication is successful, the result indicates that the UE has been successfully authenticated, otherwise, the result indicates the reason for the failure, such as the UDM or AMF / SEAF cannot trigger the HONTRA or the UE authentication fails.

[0559] The embodiments of the present application may be applied to the above-mentioned scenarios, for example, to ensure lawful interception.

[0560] In a further embodiment, when the home network triggers a re-authentication procedure (e.g., refreshing AKMA keys or due to UE mobility, e.g., entering an area served by (another) VPLMN), if the VPLMN signals / has signaled a LI requirement, the HPLMN (e.g., AUSF) may derive and share in advance parameters available in the HPLMN with the VPLMN (e.g., AMF / SEAF / UPF or LINF) (e.g., encryption keys, e.g., AKMA keys as described in other embodiments and other keys, e.g., depending on the new K_AUSF).

[0561] In a further embodiment, sharing of these keys may be done with a NF or functional block responsible for lawful interception, where the NF or functional block may be in the VPLMN or the HPLMN.

[0562] In a further embodiment, sharing may be done before the authentication process ends, for example, via a NAS_authentication_request.

[0563] In a further embodiment, the decision on early sharing of the key may be determined by a policy configured, for example, by a network operator.

[0564] In a further embodiment, early sharing of keys may require a message sent from the HPLMN to the VPLMN indicating that a home-triggered re-authentication process is being performed and that the previously shared keys are still valid. The message may also be between the NF that triggered the primary authentication (e.g., UDM) and the NF or functional block responsible for lawful interception.

[0565] In a further embodiment, the NF (eg, UDM) that triggered the primary authentication sends a message to the NF or functional block responsible for lawful interception, including new key material / information that was or is to be derived during the primary authentication.

[0566] In a further embodiment, the NF or functional block responsible for lawful interception sends a message to the NF to trigger a primary authentication (e.g., UDM) confirming receipt of key material / information. For example, this can occur anywhere before step 6 above, for example, just before step 6.

[0567] In a further embodiment, the NF or functional block responsible for lawful interception sends a message to the NF to trigger a primary authentication (e.g., UDM) indicating that the start of the HONTRA procedure is rejected, e.g., because it is not ready to start HONTRA.

[0568] In a further embodiment, upon receiving the message, the PLMN (e.g., the NF responsible for LI) may perform proximity monitoring to decide when the old key may no longer be valid and start using the newly received key material. This has the advantage that no explicit signaling is required between the NF or the functional block responsible for lawful interception to send a message (e.g., UDM) to the NF triggering the primary authentication.

[0569] In a further embodiment, sharing of the key may be performed before the primary authentication has been re-triggered and the primary authentication is only triggered when a confirmation is received from the corresponding entity stating that the key material has been received or is ready for use in the HONTRA process.

[0570] In a further embodiment, the exchanged key material / information may include at least one new root key (e.g., a new K_AUSF), a new validity time, a new key derived from the root key (e.g., K_AKMA), an expected time to perform the HONTRA process, or a reason for the HONTRA process.

[0571] Additionally or alternatively, the HPLMN (e.g., UDM) may not send a Nudm_HN_Authentication_Authenticate_Response message with a result indication to the NF requesting HONTRA (e.g., AAnF) as long as it has not received a verification confirmation (e.g., confirmation of receipt of key material, e.g., keys for UPU, SoR, AKMA and / or other keys derived from K_AUSF) from, e.g., the VPLMN (e.g., the NF responsible for LI). This has the advantage that the VPLMN (e.g., the NF responsible for LI) knows when to start using the newly received key material without having to closely monitor the traffic.

[0572] Early sharing of keys is enabled by the home network reauthentication procedure and therefore has the advantage of ensuring that, for example, encryption keys (e.g., AKMA keys described in other embodiments and other keys derived from the new K_AUSF) are available for LI purposes as early as possible.

[0573] When the UE attempts to establish, for example, an AKMA session with one or more AFs, regardless of where the AFs are, key material (e.g., encryption keys, such as AKMA keys described in other embodiments and / or other keys derived from the new K_AUSF) and parameters used in their derivation may also be transmitted to the NFs in the (V / H)PLMN (e.g., SEAF / AMF / LI NF) as soon as they are derived by the AAnF, and shared with, for example, the AF only when a confirmation is received from the VPLMN (e.g., LI NF).

[0574] According to the above-mentioned embodiments, a method for lawful interception is proposed, which can be implemented in a network function of a telecommunication system, whereby a first network function (e.g., UDM) in a first network (e.g., HPLMN) may only be allowed to trigger Home Network Triggered Primary Authentication (HONTRA) if the first network function (e.g., UDM) receives confirmation from a second network function (e.g., Lawful Interception NF) that it has received key material (e.g., a new K_AUSF and / or keys derived therefrom) and / or is ready to start from the HONTRA procedure.

[0575] Embodiment 29

[0576] In a related embodiment that may be combined with other embodiments, when the AAnF is in the serving network, K_AKMA is not derived from K_AUSF, but from K_SEAF (defined in Appendix A.6 in TS 33.501), so that the derivation of the new K_AKMA does not involve a root key managed by the home network, but involves a root key managed by the serving network and provided by the home network when derived from the root key. When K_AKMA is calculated as in clause 6.1 / Appendix A.2, K_SEAF may also be used as input for generating K_AKMA for the serving network, i.e., K_SEAF is used instead of K_AUSF.

[0577] In a related embodiment variant, since K_SEAF can be deleted once K_AMF is derived according to TS 33.501 clause 6.2.2.1, K_AKMA can be derived for the first time as in the above embodiments (e.g., embodiment 24) or as in TS 33.535.

[0578] In a related embodiment variation, if K_AKMA needs to be updated without re-running the priority authentication, a new K_AKMA can be derived by applying a key derivation function on the previous K_AKMA. Once a new K_AKMA is generated, the previous K_AKMA should be deleted.

[0579] In a related embodiment variation, if K_SEAF is not updated, a new K_AKMA for the serving network may be derived from K_SEAF and the counter.

[0580] In general, the above embodiments provide a device for deriving / refreshing a first key (e.g., Kaf) by applying a key derivation function to a second key (e.g., K_AKMA) and an application identifier and / or a variable value (e.g., a random number, a counter, UTC time) and / or a service network identifier and / or an AP identifier. Specifically, the second key can be derived by applying a key derivation function to a third key (e.g., K_AUSF / K_SEAF) and / or a variable value (e.g., a random number, a counter, UTC time) and / or a service network identifier. In particular, the device can trigger (optionally) a key derivation of the second key and the first key, for example, when a message is received from a core network, wherein the message can be NAS protected or can be protected with a current third key. In particular, the second key can be refreshed / updated in a conventional manner. In addition, the third key can be derived upon a successful authentication process with a home network. In addition, the third key can be a key distributed to the service network upon a successful authentication process with the home network, wherein the third key (e.g., K_SEAF) is derived based on a fourth key (e.g., K_AUSF). In addition, the fourth key may be derived upon a successful authentication process between the UE and the home network.The above embodiments provide a device for implementing these means.

[0581] In general, the above embodiments provide a method for deriving / refreshing a first key (e.g., Kaf) by applying a key derivation function to a second key and an application identifier and / or a variable value (e.g., a random number, a counter, a UTC time) and / or a serving network identifier, wherein the second key can be derived by applying a key derivation function to a third key and / or a variable value (e.g., a random number, a counter, a UTC time) and / or a serving network identifier, wherein the third key is shared between a first device and a second device, and the first device triggers the key derivation of the first key and the optional second key upon receiving and verifying a first message. In addition, the method allows a third key to be derived based on a fourth key generated upon a successful authentication process between the UE and the home network, and the third key is shared with the serving network serving the UE.

[0582] Embodiment 30

[0583] Based on TR 33737-020, when a UE is in a VPLMN (also denoted as SPLMN) and accesses an AF (internal or external) in a HPLMN or VPLMN, AKMA roaming needs to be addressed.

[0584] As described in the above embodiments, K_AKMA may be generated in a manner that depends on the PLMN identifier or the SEAF. This has the key advantage of fulfilling the requirement in TR 33737-020 that the AFs in the HPLMN and VPLMN may have different K_AKMA keys.

[0585] In related embodiments that may be combined with other embodiments:

[0586] For the case where the AF is in a VPLMN and K_AKMA depends on the PLMN identifier, the AUSF may derive K_AKMA and share it with, for example, the AKMA function in the VPLMN. The AKMA function in the VPLMN may then derive K_AF for the AF in the VPLMN.

[0587] For the case where the AF is in the HPLMN, the AKMA network function in the HPLMN may receive K_AKMA from the AUSF. The AKMA network function may then derive the K_AF of the AF.

[0588] To support lawful interception purposes, K_AKMA may be shared with AMF / SEAF or NF of VPLMN, which may be responsible for performing lawful interception. K_AKMA sharing may be done as a push action once K_AKMA is generated or as a pull action when VPLMN requires LI.

[0589] If K_AKMA depends on K_SEAF, the HPLMN (AUSF) may not need to share K_AKMA with the AKMA network function in the VPLMN, but the AMF / SEAF can perform the derivation of K_AKMA from K_SEAF (or K_AMF), and then K_AKMA can be configured in the AKMA network function of the VPLMN. If the AF is in the VPLMN, the AKMA network function can then derive K_AF and provide the AF in the VPLMN together with it. If the AF is in the HPLMN, the AF can also retrieve or receive K_AF from the AKMA network function in the VPLMN. Alternatively, the AKMA network function in the HPLMN can determine / retrieve K_AKMA, for example, from K_AUSF and K_SEAF, and can derive K_AF based on it.

[0590] It should be noted that the K_AKMA used to derive the K_AF for an AF located in a VPLMN and the K_AKMA used to derive the K_AF for an AF located in an HPLMN may be different. The K_AKMA used may depend on the UE location. If the UE is located in an HPLMN, a K_AKMA / K_AF that depends directly on the K_AUSF is used. If the UE is located in a VPLMN, a K_AKMA / K_AF that depends on the K_SEAF is used.

[0591] This is Figure 7 , which shows the message flow and the interaction between network functions. Figure 7 The top shows Figure 7. Entities 700, 701, 702, 703 may be located in an access (or service) network. Entities 704, 705, 706, 707 may be located in a home network. Entity 703 (e.g., an AF in a service network) may also be located outside the access / service network. Entity 707 (e.g., an AF in a home network) may also be located outside the home network. In step 708, a primary authentication process is performed. In step 711, function 705, such as AUSF, generates a home K_AKMA that is shared / pushed / deployed to function 704. This may be done after a request. In step 710, function 701, such as SEAF, exports a service K_AKMA and pushes / deploys it to 702, such as a service AKMA. In step 709, device 700 may generate a home K_AKMA and / or a service K_AKMA as described above. In steps 711 / 712 / 713 and 714 / 715 / 716, the UE sends a session establishment request to the corresponding AF in the serving and home PLMN to trigger the corresponding request and response of K_AF. According to the request (717) or default (718), if the K_AF (AF in the home network) used by 707 depends on home_K_AKMA, the home PLMN (e.g., the home AKMA network function) can push the encryption key to the serving PLMN, such as to the serving AKMA or SEAF / AMF. If it depends on the serving K_AKMA, these steps are not required.

[0592] This is also Figure 8, where steps 1, 2a, and 4 are as defined in TS 33.501 clause 6.1.3 and TS 33.535 clause 6.1. When located in a VPLMN, the UE may perform step 2b and / or step 2a. Step 2b is as defined in TS 33.535 clause 6.1, with the exception that a UE roaming in a VPLMN calculates the following: (1) K_vAKMA is calculated using K_SEAF instead of K_AUSF as in TS 33.535 Annex A.2; (2) A-vKID is calculated in the same manner as A-KID in TS 33.535 clause 6.1, with the exception that the domain part of A-vKID shall include a serving network identifier and be calculated using A-vTID; and (3) A-vTID is calculated in the same manner as A-TID in TS 33.535 clause 6.1, but shall be derived using K_SEAF instead of K_AUSF as specified in Annex A.3. Step 3 is as defined in TS 33.535 clause 6.1 with SEAF in the VPLMN to calculate K_vAKMA, with the same exceptions as in step 2b. In step 5, the UE requests an application session establishment request with A-vKID to the vAF. In step 6, the vAF will discover the vAAnF and will send a Naanf_AKMA_ApplicationKey_Get request with A-vKID and AF_ID to the vAAnF. In step 7, the vAAnF shall respond with a Naanf_AKMA_ApplicationKey_Get response containing the registered SNID. When the AF is in the VPLMN or attached to the VPLMN, the VPLMN has all secrets to support LI. Steps 8, 9, 10 are as in TS 33.535. In steps 11, 12, the VPLMN can request AKMA keys for LI purposes (when the K_AF used by the hAF depends on KAKMA), and the HPLMN provides them. Note that in step 4, the HPLMN can also derive K_AF from KvAKMA instead of KAKMA. In this case, steps 11 and 12 are not required, since these keys are known to the VPLMN. Fig.11 , where only K_vAKMA is calculated by the UE, and therefore, the K_AKMA to be used is determined only by the UE position, not by the AF position, as described above. Fig.11In steps 2, 3 and 4 of TS33.535, only K_vAKMA and A_vKID are calculated as described above, i.e., dependent on K_SEAF. Steps 5-8 and steps 9-12 are the same as in TS33.535, but using K_vAKMA and A_vKID. In steps 13 and 14, the AMF / SEAF in the VPLMN may optionally request additional security information for LI purposes from the vAF and / or hAF, such as Ua* protocol, security algorithms, etc. This request may be made to the local vAF or hAF. In steps 15 and 16, the vAF and / or hAF pass any additional information required for LI purposes when available or requested.

[0593] It should be noted that, additionally or alternatively, identifiers such as A-TID, A_vTID or keys such as K_AKMA or KvAFMA may also be derived using other parameters in the KDF (such as AF_ID, (V / H)PLMN or random numbers, etc., in other embodiments) as input. This has the advantage of limiting privacy issues in the AKMA identifier (i.e., A-TID), which otherwise depends only on SUPI and KAUSF and may be (re)used by multiple / different applications.

[0594] Embodiment 31

[0595] In an embodiment that may be combined with other embodiments, the A-KID identifier may be in the NAI format as specified in clause 2.2 of IETF RFC7542 [6], ie, username@domain.

[0596] The username part may include a RID (Routing Indicator) and an A-TID (AKMA Temporary UE Identifier), and the domain part may include a Home PLMN or VPLMN identifier, depending on where the AF is located.

[0597] The serving PLMN may also be included in the username portion.

[0598] This construction is intended to meet the requirement for AKMA key identifier in roaming situations, i.e., the AKMA AF should be able to identify the AAnF serving the UE from the A-KID.

[0599] refer to Figure 7 , steps 709 , 710 , and 711 may also involve the generation of an A-KID identifier.

[0600] Embodiment 32

[0601] An eavesdropper (e.g., AF1) may be able to learn that the UE is trying to establish a session with another AF (e.g., AF2) and obtain the UE's identifier (e.g., GPSI, external identifier). To this end, the eavesdropper may intercept the session establishment request for AF2 (e.g., see TS 33.535). Figure 6 .2-1), thereby leaking the identity of the AF that the UE is trying to contact. An eavesdropper can extract the UE's A-KID from the session establishment request. An eavesdropper can combine it with its AF_ID in the AKMA AF Key Request sent to the AAnF to ultimately request and retrieve the UE identifier, such as GPSI and K_AF (different from the K_AF established between the UE and AF1). Therefore, the way the 5G system authorizes AKMA AF key requests may lead to potential AKMA privacy violations, i.e., disclosing the UE identifier and the identity of the AF with which the UE is trying to establish a session.

[0602] In an embodiment variant aimed at solving this problem, the AKMA session establishment request message may include an AF_ID to identify which AF the request is intended for. The request is sent to the CN / PLMN / NF providing the AKMA service. The request may then be unicast (or just shared) to the relevant target AF, which may then use the received A-KID to send an AF key request to the AAnF.

[0603] In a related embodiment variant, since the CN / PLMN / NF knows the target AF (because the UE shares the AF_ID), the CN / PLMN / NF (AAnF) has the ability to monitor which AF is sending the AKMA AF Key Request and block / reject unauthorized requests.

[0604] In another embodiment variation, AF_ID may be combined with A-KID to generate an application function key identifier (AF-KID), such as Fig.16 As shown, AF-KID uses the format username@domain, so that the username can include:

[0605] RID (Routing Indicator) and

[0606] A-TID (AKMA Temporary ID) and / or

[0607] AF-TID (Application Function Temporary ID),

[0608] The realm includes a network (eg, home network) identifier.

[0609] If the AF-TID is AF_ID, this embodiment variant is similar to the previous embodiment variant.

[0610] The AF-TID may be derived by using a key derivation function (for A-TID) with the following parameters:

[0611] - As in other embodiments, the input key KEY may be K_AKMA or a key or keys derived therefrom.

[0612] - The parameters used to form the input S of the KDF can combine multiple parameters, such as "AF-TID" and / or AF_ID and / or Salt. If there are three parameters, it can be, for example, as follows:

[0613] ο FC = value to be defined;

[0614] ο P0 = "AF-TID"; (bit string identifying the identifier)

[0615] ο L0 = length of "AF-TID";

[0616] ο P1 = AF_ID;

[0617] ο L1 = length of AF_ID.

[0618] ο P2 = Salt (random value used to randomize output)

[0619] ο L2 = length of Salt.

[0620] The UE may send an AKMA session establishment request message with an AF-KID to the relevant AF (or send different AF-KIDs to different AFs). The CN may keep Salt (if present) for verification purposes. The advantage of including Salt is that, for example, in each interaction, the identifier is randomized, making it difficult to guess the identifier in different requests without access to Salt. An alternative to Salt may be a counter, such as a time-based counter. The AF may use an identifier (i.e., AF-KID) to identify the AAnF serving the UE. The AF may send an AKMA AF key request containing its AF_ID and / or AF-KID to the AAnF. Once the AAnF receives the AKMA AF key request message, it may omit the AF-TID portion from the username leaving the A-KID, and the A-KID is then used to verify whether the subscriber is authorized to use the AKMA service based on the presence of the K_AKMA linked to the A-KID. The AAnF may generate the AF-TID using the K_AKMA (or other key used as the above input) identified using the AF_ID and / or salt received from the AF. This can then be verified against the AF-TID received from the AF as part of the AF-KID. If the verification is performed successfully, the AAnF proceeds to provide the AF with, for example, a Naaf_AKMA_ApplicationKey_Get_response with K_AF, K_AF expTime and SUPI / GPSI. Otherwise, the AAnF may send a Naaf_AKMA_ApplicationKey_Get with an error response.

[0621] In an alternative / additional embodiment variant, the AF-TID may be sent to the AF separately from the A-KID (e.g., in a different message or message field) in an AKMA session establishment request. The AF may use the A-KID to identify the AAnF serving the UE and send an AKMA AF key request containing the A-KID, AF-TID, and AF_ID. The AAnF may verify the presence of the K_AKMA linked to the A-KID, which it may then use (or other keys used as input as described above) with the received AF-ID and / or salt to generate the AF-TID. The AAnF then compares the generated AF-TID with the AF-TID received from the AF. The AAnF proceeds similarly to the previous embodiment, depending on whether the verification is successful.

[0622] In an alternative / further embodiment variant, a value such as a salt or a time-based counter is used to randomize the identifier, for example as in the previous embodiment variant. Such a parameter (e.g., salt) may be sent and maintained at the CN and may not be forwarded to the AF.

[0623] In another embodiment variant, the AF_ID is combined in the A-KID itself and can also be derived from the salt, as in the above embodiment variant. This can be done by a NF such as the AUSF for each AF that the user has a subscription to, or for each AF for a service. After primary authentication, the AUSF can derive AKMA key material (e.g., K_AKMA) and identifiers (e.g., a list of A-KIDs) so that each A-KID identifies a specific AF in addition to the K_AKMA, and send them to the AAnF. Then when the AF sends an AKMA AF key request to the AAnF, the AAnF can verify whether the AF is authorized based on the A-KID in the request (depending on the AF_ID).

[0624] In a further related embodiment variation, the AAnF may receive an AKMA AF key request including an AF_ID and an A-KID from the AF, and may send the received request, e.g., the A-KID, AF_ID, and / or salt, to the AUSF so that the AUSF may verify the received parameters (e.g., the AF_ID, salt, etc. may be used to calculate the received A-KID). The AUSF then sends a confirmation (e.g., a verification result) to the AAnF. In a further related embodiment variation, the AAnF may receive an AKMA AF key request including an AF_ID and an A-KID from the AF, and the AAnF may send the received AF_ID, SUPI, and / or salt to the AUSF so that the AUSF may derive the A-KID and send it back to the AAnF. The AAnF then verifies whether the A-KID in the AKMA AF key request from the AF matches the A-KID received from the AUSF, and then sends a response to the AF accordingly.

[0625] Embodiment 33

[0626] In an embodiment that may be combined with other embodiments, the VPLMN may not wish to Figure 7 or Fig.11 Or TS33.535 allows the UE or AF to start an application session (e.g., Ua* protocol), for example, as requested in message 714. Therefore, messages 717 and 718 (where the VPLMN is configured with the AKMA key by the HPLMN) are performed before message 716 (where the application key is shared with the AF 707). The message flow will be message 715 (KAF request), message 718 (K LI response to configure the key), message 717 (K LI configuration confirmation), message 716 (KAF response).

[0627] As long as the HPLMN has not received confirmation from the VPLMN about the receipt of the AKMA key, it is advantageous not to exchange messages 716 to configure the KAF. This is a configuration that can be stored as a policy in the HPLMN. This configuration may have been received by the VPLMN or may be stated in a service level agreement.

[0628] Note that another advantage of this message flow is that once message 717 is sent by the VPLMN, the VPLMN knows that the new AF will start a new application session (e.g., Ua*), so it can start monitoring the service. The change in service mode soon after sending message 717 allows the VPLMN (or the NF in the VPLMN responsible for LI, such as UPF) to determine the protocol flow corresponding to the new application session.

[0629] In addition, the application session (e.g., Ua*, e.g., TLS1.2 or TLS1.3 or DTLS) may involve exchanging other keys required for lawful interception (LI) purposes. Therefore, the NF (e.g., 704) (e.g., hAANF) in the HPLMN may provide the NF (e.g., 701) (i.e., vAANF) in the VPLMN or another entity (e.g., AMF or SEAF) storing such key material for LI with further keys once those keys determined by the AF have been calculated.

[0630] The sequence of messages in the beginning of the embodiment (i.e., KAF request from AF to HPLMN, followed by messages K LI request, K LI response, and K LI configuration confirmation exchanged between VPLMN (e.g., LI NF / AMF / SEAF) and HPLMN (e.g., AAnF), and finally KAF response) ensures that the key material (e.g., K_AF) is provided to the VPLMN (e.g., LI NF / SEAF / AMF), which confirms that the received key material matches its LI configuration requirements, and then it sends a confirmation to AAnF. Only after AAnF receives the confirmation from VPLMN, it provides the key material to AF to establish a session with the UE.

[0631] According to this embodiment, a method for lawful interception is proposed, which can be implemented in a network function of a telecommunication system, whereby a first entity (e.g., AAnF) in a first network (e.g., HPLMN) receives a key request (e.g., K_AF request), the first entity calculates the requested key material (e.g., K_AF) l, and shares the key material with a lawful interception entity (e.g., UPF, SEAF, AAnF), wherein the lawful interception entity can be in a second network (VPLMN) or in the first network, and the first entity shares the key material with the requesting entity only upon confirmation that the key has been correctly received.

[0632] Embodiment 34

[0633] In an embodiment that can be combined with other embodiments, when the UE sends an AKMA session establishment request to the AF, the AF (e.g., an AF in the HPLMN or an external AF) can send an AKMA AF key request to the HPLMN (e.g., AAnF) and include therein encryption parameters (e.g., encryption algorithm, encryption key and / or parameters for deriving encryption keys) intended to be used in the session to be established between the AF and the UE. This has the advantage of providing the network (HPLMN and / or VPLMN) with all the required key materials / parameters required for lawful interception.

[0634] In alternative embodiments, the key material / parameters may be sent in the same first message requesting the K_AF, or in a second separate message before / after / together with the first message.

[0635] In an alternative embodiment, the AF may provide these encryption key materials and / or parameters after the HPLMN provides K_AF to the AF following, for example, the procedures described in other embodiments.

[0636] In further embodiments that can be combined with other embodiments, reference is made to Fig.17 Before the HPLMN (1702) provides the K AF to the AF (1703, e.g., as an HPLMN AF or an external AF), the NF (e.g., 1701) in the VPLMN (e.g., SEAF) may be able to verify the key material / parameters that the AF intends to use to encrypt the traffic in its session with the UE (e.g., 1700).

[0637] For example, consider Fig.17Related to the following message flow, where such verification occurs and where steps / messages are performed at a given time in an exemplary mode, i.e., steps may be performed more than once and / or in a different order and / or may be optional. In this example, 800 may send messages in messages 1710 to 1703, such as an AKMA session establishment request. In addition, 1700 may start a security association, such as a security association of the Ua* protocol, for example, it may start a handshake (e.g., a TLS handshake) with ClientHello in message 1711. 1703 may send an AKMA AF key request in message 1712. Message 1712 may include an A-KID and encryption parameters (e.g., encryption algorithm, encryption / decryption key and other security parameters, such as a random number) to 1702. 1701 may send a K LI request to 1702 after messages 1710 and 1711. 1701 may also not be sent, or it may have been sent earlier, or it may be sent later. 1702 calculates K_AF, and it may store or send some encryption parameters for storage. 1702 replies with a message K LI response (message 1714) containing K_AF and / or encryption parameters. 1703 may send a security associated message (e.g., a message of the Ua* protocol, e.g., a TLS ServerHello response) in message 1715, which 1701 (or 1702) may intercept and use to verify the encryption parameters received, e.g., in step 1716. The verification may be done, e.g., by checking that the private key AF provided in message 1712 corresponds to the public key intercepted in message 1715. Upon successful verification, 1701 may send a confirmation, e.g., a K LI confirmation, to 1702. If the verification is unsuccessful, 1701 may send a failure message to indicate 1702 the problem. 1702 may then send an AKMA AF key response containing K_AF to 1703 in message 1718. If 1702 is intercepted 1715, 1702 may then release it to 1700 so that a security association is further established.

[0638] In the above scenario, the fact that message 1715 is intercepted and possibly cached / stopped has the advantage that the entity performing the interception has the ability to ensure that no communication occurs as long as message 1715 has not been released. It may therefore be advantageous if certain messages exchanged between the UE and the AF over the telecommunication system (e.g. messages of the Ua* protocol) have a certain field indicating that they are essential for establishing a security association. This may be, for example, a ServerHello response.

[0639] Therefore, in a further embodiment, the entity performing the interception is configured with a policy for determining messages that require interception, wherein the policy may have been configured by a legal enforcement authority that oversees lawful interception in the jurisdiction in which the telecommunications system and the UE are located. It is further advantageous if the entity performing the interception / caching is located in the VPLMN, such that the VPLMN is not dependent on the HPLMN.

[0640] In the above embodiment, message 1715 is a message that is intercepted and can be cached / stopped, because in the above embodiment, message 1715 can represent a reply from 1703 for establishing a Ua* security association. However, message 1711 can also be a message that is intercepted and can be cached / stopped.

[0641] In the above embodiment, message 1711 is transferred from 1700 to 1703, and message 1715 is transferred from 1703 to 1700. However, security association messages 1711 and 1715 may also be exchanged in another manner, that is, 1711 may be from 1703 to 1700, and 1715 may be from 1700 to 1703.

[0642] In general, a method for lawful interception is proposed, which may be implemented in a lawful interception entity (e.g., a NF in a telecommunication system), whereby:

[0643] - a first entity (e.g., AF) sends a key request and security parameters to a second entity in the first network (e.g., AAnF),

[0644] - the second entity determines the key and shares the key and security parameters with a third entity (e.g. a lawful interception entity in the first network or the second network),

[0645] - the third entity monitors / intercepts / caches the message sent by the first entity to the fourth entity (e.g., UE) and uses it to verify the validity of the received security parameters,

[0646] In a related embodiment,

[0647] - the third entity further sends the validity verification result to the second entity;

[0648] - The second entity shares the key after successful validity verification.

[0649] In a related method, the message is only released by the third entity to the fourth entity if the authentication is successful.

[0650] A method for lawful interception is also proposed, which may be implemented in a UE, whereby:

[0651] - The fourth entity sends a first message (eg, an application session establishment request) to the first entity;

[0652] - the fourth entity sends a second message to the first entity (for example, an initial message of a security association in the Ua* protocol, such as a ClientHello message in TLS);

[0653] - The fourth entity receives the third message (eg, application session establishment response).

[0654] Embodiment 35

[0655] In some scenarios, AKMA can support multiple security protocols (e.g., TLS, DTLS, OSCORE, etc.). Protocols such as OSCORE or CoAP are used to protect, for example, Constrained Application Protocol (CoAP). These security protocols have different purposes, for example, TLS can be used by standard applications, while OSCORE is focused on IoT devices. This increases the complexity of the NF, such as the LI NF of the LI responsible for AKMA-related communications.

[0656] For example, a Constrained Application Protocol (CoAP) may be used between the UE and the AF. A CoAP client (e.g., a UE) may start communication via a Ua* reference point and attempt to establish a DTLS tunnel with the AF. The CoAP client may indicate to the AF that AKMA-based authentication is supported, and the AF may select AKMA to derive keys (e.g., to calculate MIC and / or encrypt traffic).

[0657] The aim is to address this increased complexity with the aid of the following embodiments which can be combined with one another as appropriate.

[0658] In one embodiment, the entity performing LI (e.g., LI NF in a VPLMN) may be configured with a policy that determines the messages / protocols that need to be intercepted and in which context. For example, as long as the communication flow of OSCORE / CoAP conforms to the communication mode of a smart device (e.g., a smart meter), the policy may not require processing of OSCORE-related keys, whereas when the communication mode is different, such as when CoAP appears to be used for message transfer, OSCORE-related keys should be processed.

[0659] In a related embodiment, the policy may have been configured by a law enforcement authority that oversees lawful interception in the jurisdiction in which the telecommunications system and UE are located. Advantageously, the entity performing interception / caching is located in the VPLMN, such that the VPLMN is independent of the HPLMN.

[0660] In a further embodiment, the entity performing LI may inform the NF responsible for the key (eg, UDM or AUSF or AaNF, eg, in HPLMN) of the message / protocol requiring lawful interception as derived from the policy.

[0661] In a further embodiment, the entity performing LI may provide the policy to the NF responsible for the key (eg UDM or AUSF or AaNF, eg in HPLMN).

[0662] An advantage of these embodiments is that the HPLMN is not overloaded with processing keys for protocols that may or may not be needed by the LI (eg OSCORE).

[0663] In a further embodiment, the NF responsible for keys (e.g. UDM or AUSF or AaNF, e.g. in the HPLMN) may provide the entity performing the LI with only those keys that are required according to the policy. This has the advantage that the HPLMN is not overloaded when handling keys that may or may not be required for the LI.

[0664] In a further embodiment, if a given application communication protocol (e.g., CoAP) is used between the UE and the AF, the HPLMN (e.g., AAnF) may not provide the AF with key material (e.g., K_AF) associated with a security protocol (e.g., OSCORE or DTLS) used to protect the application communication protocol as long as it has not received confirmation from the VPLMN (e.g., LI NF) requiring the delivery of keys for that security protocol.

[0665] In one embodiment, reference Fig.17 , in the case where the CoAP security protocol OSCORE is used as the Ua* protocol between 1700 and 1703 to the HPLMN (e.g., 1702), the LI NF (e.g., 1701) in the V / HPLMN may be able to derive the OSCORE security context that the AF (1703, e.g., HPLMN AF or external AF) and the UE (e.g., 1700) attempt to establish.

[0666] Considering Fig.17 In a further embodiment of the message flow in , where the steps / messages are provided in an exemplary mode, i.e., some steps may be performed more than once, and / or in a different order, or may be optional, and assuming that OSCORE is used as the Ua* protocol, 1700 may start a security association (e.g., transmit its OSCORE parameters) via a CoAP request (e.g., message 1711), which may include / replace an application session establishment request and may contain at least one of the following:

[0667] - CoAP method (e.g., POST); and

[0668] - The URI of the AKMA resource at 1703 (e.g.<AF_IP_or_FQDN> / akma, where AF_IP or FQDN indicates the IP address or FQDN of the host of 1703); and

[0669] - Payload: CoAP security protocol identifier, A-KID and OSCORE specific parameters N1, AF-SID and / or ?OSC-NIP, where:

[0670] In case of OSCORE use, the CoAP security protocol identifier is set to the value "01";

[0671] A-KID is the AKMA key identifier;

[0672] N1 is a random number generated by 1700;

[0673] AF-SID is the OSCORE sender identifier generated by 1700 for 1703 (to enable short locally unique identifiers),

[0674] ? OSC-NIP is an optional parameter representing any additional OSCORE input 1700 may provide to 1703.

[0675] To obtain key material (e.g., K_AF) 1703 may send an AKMA AF key request to the NF in 1702 (e.g., AAnF) in message 1712, which may include the A-KID in addition to OSCORE parameters such as:

[0676] - A response code, such as "Created"; and

[0677] - Payload: N2 and UE-SID, such that N2 is a random number generated by 1703 and UE-SID is an OSCORE sender identifier for 1700 (eg, UE) generated by 1703. It may also include received OSCORE parameters, such as N1.

[0678] Upon detecting the CoAP request (i.e., message 1711), 1701 may optionally send a LI request message (e.g., message 1713) before or after 1703 has sent message 1712 to 1702. In response to message 1713 and / or upon receiving message 1712 (e.g., in the case where 1701 did not send a LI request), 1702 sends message 1714 (e.g., LI response) containing key material (e.g., K_AF, salt, and other parameters) including the OSCORE parameters of 1703. In step 1716, 1701 may derive an OSCORE security context using key material (e.g., K_AF, salt, and / or other parameters) including the OSCORE parameters from 1700 (e.g., intercepted from message 1711) and the OSCORE parameters from 1703 (e.g., transmitted in message 1714). Then, and only then, 1701 may provide 1702 a confirmation message (eg, confirmation message 1717 ) which allows 1702 to provide 1703 key material (eg, K_AF) in message 1718 (eg, AKMA Key Response) to derive the OSCORE security context.

[0679] In response to message 1711 (e.g., CoAP request), 1703 may send message 1715 (e.g., CoAP response) containing OSCORE parameters (e.g., response code, N2, and UE-SID) of 1703. 1701 may intercept message 1715 to verify that the OSCORE parameters it includes match the OSCORE parameters it received in message 1714. Upon successful verification, 1701 may forward message 1715 to 1700, which may derive an OSCORE security context at that stage.

[0680] In a related embodiment, message 1715 (e.g., CoAP response) may be sent to 1700 before making an AKMA AF key request (e.g., message 1712), in which case 1701 may intercept and cache / stop message 1715 until it has derived the OSCORE security context. In the event that any additional parameters are required to derive the context, 1701 may indicate which parameters are required in message 1713 (e.g., LI request), and once provided in message 1714 and verified in step 1716, 1701 may send a confirmation message (e.g., 1717) to 1702, which may then and only then provide key material (e.g., K_AF) to 1703.

[0681] In a further embodiment, which may be combined with other embodiments, the entity performing the interception may be configured with a policy that determines the protocols and / or messages that need to be intercepted and / or cached, wherein the policy may have been configured by a law enforcement agency that oversees lawful interception in the jurisdiction in which the telecommunications system and 1700 (e.g., UE) are located. It is further advantageous if the entity performing the interception / caching is located in 1701 (e.g., a VPLMN) such that the VPLMN is independent of the HPLMN.

[0682] According to the above embodiments, a device and method are proposed, by which an NF (e.g., UDM, AUSF, or AAnF) in a first network (e.g., HPLMN) responsible for keys and / or key derivation is configured (e.g., through a policy) by a legal interception entity / NF located in the same network or a second network (e.g., VPLMN), wherein the configuration / policy determines the context, protocol (TLS, DTLS, OSCORE, ...) and / or message (e.g., AKMA-specific) that needs to be intercepted.

[0683] According to the above embodiments and the apparatus / methods proposed above, the NF (e.g., UDM, AUSF, or AAnF) may also be requested to provide key material (e.g., K_AF and / or other parameters) to a requesting entity (e.g., AF) communicating with a device (e.g., a smart device / UE) in a second network (e.g., VPLMN). The NF (e.g., UDM, AUSF, or AAnF) may do so (e.g., provide key material to the requesting entity) only upon receiving confirmation / verification confirmation from the legitimate entity interception entity.

[0684] Embodiment 36

[0685] During an ongoing Ua* session between the AF and the UE, K_AF may expire and therefore may need to be refreshed (e.g. by triggering a primary authentication triggered by home). In this case, the key material is updated and the ongoing Ua* session needs to proceed as usual and must meet the lawful interception requirements. To address this situation, the following embodiments, which may be combined with other embodiments, may be applied:

[0686] In a first embodiment, the AF may request a new KAF from the HPLMN (e.g., AAnF), which may include any security parameters that may be used to derive security material, and the HPLMN may notify the VPLMN (e.g., LI NF / SEAF) of the request received from the AF, share the new KAF and security parameters with the VPLMN (e.g., LI NF / SEAF), and wait for LI configuration confirmation from it. Upon receiving the key material (e.g., KAF and security parameters) from the HPLMN, the VPLMN (e.g., LI NF / SEAF) may check that the provided key material (e.g., KAF and security parameters) meets its LI configuration requirements, and if so, the VPLMN may send a confirmation to the HPLMN, which then provides the new K_AF to the AF.

[0687] In further embodiments, which may be combined with other embodiments, during an ongoing Ua* session (e.g., a TLS / DTLS session) between the AF and the UE, the K_AF may expire and / or the AF may want to update or refresh the security keys / parameters used to encrypt the Ua* session. The AF may need to notify the HPLMN (e.g., AAnF) and provide new security parameters (e.g., encryption algorithm, encryption / decryption keys, and any other parameters, e.g., random numbers, counters) via a message (e.g., a request for a new K_AF). Providing a new K_AF and / or approving the use of new security keys for encryption is subject to confirmation by the VPLMN (e.g., LI NF / SEAF), i.e., the HPLMN may need to provide the security parameters and / or the new K_AF to the VPLMN, which verifies them before sending a confirmation to the HPLMN. If the VPLMN approves, the HPLMN may provide the new K_AF and / or approval to update the security keys to the AF.

[0688] In a further embodiment, which may be combined with other embodiments, the AF may send a request to the UE to update security parameters (e.g., encryption keys), for example, during an ongoing Ua* session. The request may be intercepted by the VPLMN and used to verify that the security parameters AF sent to the HPLMN in a request (e.g., a key refresh request) are sufficient to meet the LI requirements of the VPLMN (i.e., to enable the LI NF in the VPLMN to decrypt the service). If so, the VPLMN may confirm the request to update the security parameters and send a confirmation to the HPLMN (e.g., AAnF), which the HPLMN forwards to the AF.

[0689] In further embodiments, which may be combined with other embodiments, the AF may be required to assist the VPLMN in verifying its security parameters, for example by providing further parameters upon request (e.g. parameters used in key derivation). This may involve, for example, the VPLMN sending a request to the AF (via the HPLMN).

[0690] In some embodiments, a description with VPLMN and HPLMN has been completed. However, in some cases, there may be a single network (e.g., HPLMN). In this case, the first NF in the HPLMN (e.g., AAnF) may only send K_AF to the AF once the second NF in the network (responsible for lawful interception) has been configured with the encryption key / K_AF and has provided confirmation / confirmation to the first NF.

[0691] In some embodiments, the description has been made in terms of a lawful interception NF, however, this may also be understood, without loss of generality, as a lawful interception entity, which may be part of the NF or interact with the (core network) of the telecommunication system.

[0692] Generally, another method is proposed, by which the VPLMN can verify and allow the update of security parameters (e.g., encryption key K_AF) during an ongoing Ua* session between the AF and the UE, wherein the AF sends a request to the NF (e.g., AAnF) in the first network (e.g., HPLMN) to request approval of the update / refresh of the security parameters (e.g., encryption key K_AF), the first network (e.g., HPLMN) forwards the request to the NF (e.g., LI NF / SEAF) in the second network (e.g., VPLMN), the second network verifies that the new security parameters meet its LI requirements (i.e., means to provide decryption services) and sends a confirmation to the first network, and finally the first network sends approval of the new K_AF and / or updated key to the AF.

[0693] Embodiment 37

[0694] In one embodiment, AKMA is extended and / or configured to use the ETSI Middlebox Security Protocol (MSP). For example, AKMA is configured to be used as Ua* protocol ETSI TS103 523-2 or TS103523-3. For example, in the case of TS103 523-3V1.1.1, eTLS runs between the application proxy or AF (e.g., in the HPLMN or VPLMN) and the UE described in other embodiments. The middlebox is located, for example, between the HPLMN or VPLMN.

[0695] If such an ETSI Middlebox Security Protocol (MSP) is used, the middlebox (e.g., a NF in a VPLMN such as SEAF or UPF) may be configured with an AKMA key and / or a middlebox security protocol key (e.g., an eTLS key) through messages explained in other embodiments (e.g., Embodiment 33).

[0696] Embodiment 38

[0697] In an embodiment that can be combined with other embodiments, the first network (e.g., HPLMN) sends AKMA-related parameters such as K_AKMA and / or AKMA indication and / or routing indicator to the second network (e.g., VPLMN) so that the second network can know whether the UE supports AKMA services and how to handle them.

[0698] For example, when the first network provides K_SEAF (or K_AKMA) to the second network after primary authentication, the entity in the first network that handles the long-term credentials / policies / subscriptions of the UE (e.g., the UDM of the HPLMN) will return AKMA-related parameters to the NF in the second network. This can be done with the help of UDM, but using the "Nudm_UEAuthentication_Get Service Operation" service (TS 33.501, clause 14.2.2), which can return, for example: (1) SUPI if SUCI is used as input; (2) authentication data for SUPI (e.g., AKA authentication vector) depending on the authentication method, or (3) AKMA indication and routing indicator if the subscriber has AKMA subscription according to TS33.535.

[0699] In a further embodiment, which may be combined with other embodiments, the second network may determine some AKMA parameters itself upon receiving an indication (e.g., a key for deriving an AKMA key, such as K_AKMA or K_SEAF) that the second network is responsible for handling AKMA for the UE when the UE is within its range. For example, receiving K_AKMA from the HPLMN may be used as an implicit AKMA indication. For example, the second network may determine a routing indicator to be used when providing AKMA services to the UE.

[0700] In further embodiments, which may be combined with other embodiments, the UE may provide one or more of the AKMA-related parameters to the VPLMN, for example, once or if the VPLMN has indicated support for AKMA services.

[0701] In further embodiments, which may be combined with other embodiments, the UE may receive one or more of the AKMA-related parameters from the VPLMN, for example, once or if the VPLMN has indicated support for AKMA services.

[0702] In one embodiment, the HPLMN may provide the AKMA indication to the VPLMN (SEAF / AMF) as part of the subscription data.

[0703] In one embodiment, the routing indicator to be used when the UE is roaming is a default routing indicator so that it does not need to be transmitted to the VPLMN and the UE can select it knowing that it is roaming. In this case, the AAnF NF consumer can select any AAnF instance within the VPLMN.

[0704] In one embodiment, the routing indicator used when the UE from the HPLMN is roaming is the default routing indicator associated to the HPLMN, so that it does not need to be transmitted to the VPLMN, and the UE can select it knowing that it is roaming. In other words, all UEs from the HPLMN will use the same AAnF in the VPLMN associated to the HPLMN.

[0705] Embodiment 39

[0706] In further embodiments, which may be used independently or in combination with other embodiments, the VPLMN may provide AKMA service, but the HPLMN may not provide AKMA service.

[0707] Deriving the AKMA keys at the VPLMN from a key such as K_SEAF is beneficial because it allows AKMA services to be implemented at the VLPMN even if the HPLMN does not implement such services.

[0708] Alternatively, even if the HPLMN itself does not provide AKMA service, functionality to always derive K_AKMA (e.g. as in TS 33.535) may be available at the HPLMN. This functionality may be at the AUSF or UDM, for example. K_AKMA may be provided to the VPLMN together with K_SEAF.

[0709] The HPLMN may also indicate whether the VPLMN device is a device supporting AKMA independently of whether the HPLMN itself supports AKMA service, so that the VPLMN may provide AKMA service if it supports AKMA service.

[0710] The UE may also independently indicate whether the VPLMN is an AKMA-capable device or whether the HPLMN itself supports AKMA services, so that the VPLMN may provide AKMA services if supported.

[0711] The VPLMN may, for example, provide its AKMA configuration parameters to the UE in a secure manner, for example by means of NAS messages or protected with VPLMN AKMA specific keys as in other embodiments.

[0712] The VPLMN may also provide the HPLMN with an indication about supporting the AKMA service, so that the HPLMN only provides the required parameters to the VPLMN as needed.

[0713] In a specific example of this embodiment, when AKMA service is provided, according to TS 33.501 clause W.4.1.3, the VPLMN can also enable the UE to authenticate to the MBSTF based on AKMA, such as registering for MBS service and receiving MBS service, while if the HPLMN does not provide AKMA service, the UE in the HPLMN can use GBA.

[0714] Embodiment 40

[0715] An authentication agent (AP) is an HTTP proxy that acts as a network authentication function for the UE. It performs a TLS secure connection with the UE so that the application server (AS) does not need to be involved. The AP can ensure the AS that the request comes from an authorized UE. The AP is meaningful because it can reduce the consumption of authentication vectors, for example. The AP can be introduced in the AKMA so that different application functions in the AKMA in the same trust domain or edge node can rely on the AP to perform the AKMA process. Therefore, in the above embodiments, the AP can be located, for example, between the AF and some other network functions (e.g., AaNF or AuSF). Kaf can then be processed at the AP on behalf of Af. A single user plane interface between the UE and the AP may be required because multiple Afs (in a public security domain) will be behind the same AP. In addition, the key derivation function used to derive Kaf or Kakma may include parameters for identifying a given AP. In particular, there may be a Kap that can be generated on behalf of an Af in the same security domain behind a public AP in a similar manner as above. Specifically, Kap may be related to Af in a serving PLMN or a home PLMN. Reference Figure 7 Entity 703 may be an AP in the serving PLMN that provides services to an AF in the serving PLMN. Figure 7 , entity 707 may be an AP in the home PLMN that serves the AF in the home PLMN.

[0716] The AP may also play a role in legal interception (LI). This may be particularly the case where the AF is outside the HPLMN and the UE is in the VPLMN. The reason is that for LI, all required exchange data needs (or may need) to be shared with the VPLMN. Therefore, an external AF that requires AKMA security may (need) be executed on an AP in the HPLMN. This can be based on policy. For example, if an external AF refuses to exchange encryption keys, the (operator) of the HPLMN can deploy and implement policies by which the AP should serve the AF in the HPLMN. In addition or alternatively, in a first variant, the AP at the HPLMN may (must) share the AKMA / AF keys and other required parameters (e.g., diffie-hellman keys, encryption algorithms, protocols) with the VPLMN (e.g., the AMF / SEAF of the VPLMN) so that the appropriate NF in the VPLMN (e.g., UPF) can perform data decryption when needed. In addition or alternatively, in another variant, the AP may share data with the VPLMN (decrypted data at the AP before further exchange with the AF). This is possible because the AP acts as a middlebox for the LI at the HPLMN and shares data with the VPLMN.

[0717] Additionally or alternatively, the AP may be integrated with the UPF.

[0718] It should be noted that if K_AF depends on K_SEAF, the VPLMN can derive K_AF directly without the help of the HPLMN, as described in the above embodiments. However, the HPLMN still needs to support the VPLMN with LI obligations by providing any other parameters required for decryption at the VPLMN.

[0719] For LI, all information needed for decryption needs / may need to be exchanged or the decrypted data itself. This can include K_AF as well as any other key material (e.g., diffie-hellman keys), selected security algorithms, etc.

[0720] It should be noted that AP has additional benefits over LI in that less information needs to be shared (eg, fewer encryption keys) and the interception itself can be simplified.

[0721] According to the above embodiment, a method is proposed by which a VPLMN with a lawful interception requirement obtains access to services exchanged between a UE served by it and an AF that is outside the HPLMN and served by an authentication agent (AP), wherein the method includes providing key materials (e.g., K_AKMA, K_AF, and other parameters) to an NF of the VPLMN (e.g., SEAF). Then, the NF in the VPLMN (e.g., UPF) decrypts the intercepted services exchanged between the UE and the AF. Alternatively, the AP can decrypt the services exchanged between the UE and the AF and forward them to the VPLMN.

[0722] Embodiment 41

[0723] In 3GPP (new component), network-controlled repeaters are being developed. In 3GPP networks, a repeater is a device used to provide fill coverage for areas that are poorly served by base stations. Functionally, it is a simple bidirectional amplifier that transmits uplink and downlink signals between one antenna toward the base station and another antenna toward the poor coverage area. An illustrative application scenario is the use of repeaters to extend outdoor coverage to indoor locations (O2I). In this scenario, UEs inside the building are prevented from establishing a direct link with the base station due to the materials used in the construction of the building. In order to achieve better service for UEs inside the building, repeaters can be used to transmit signals from the outside to the inside and vice versa. The repeater is just an amplifier and does not otherwise modify the signal passing through it. That is, it is transparent to the business transmitted through it. Compared with more complex concepts such as integrated access and backhaul (IAB), repeaters provide a simple and cost-effective solution for direct situations. The disadvantage of current repeaters is that the amplifier is always in operation even when there is no business to repeat. This can lead to excessive noise in the coverage area of ​​the repeater, since any in-band signal or noise arriving at the input of the downlink is repeated, whether or not it is a valid signal. The base station may also suffer from similar problems on the uplink. In principle, if aspects of the behavior of the repeater installation can be controlled by the base station, the overall performance of the repeater installation can be improved. As a simple example, the amplifier can be turned off unless there is a signal to be transmitted. Since the base station is fully responsible for the scheduling of uplink and downlink transmissions, it can turn the amplifier on only when it is needed. In Release 18, 3GPP began developing network controlled repeaters (NCRs), which operate only in this way. In addition to the forwarding module (NCR-Fwd), the NCR also includes a mobile terminal (NCR-MT) module that controls the behavior of the NCR under instructions from the gNB. In TR 38.867v1.00 Figure 5-1The conceptual model is shown in Figure 1. Data traffic is transmitted over the backhaul (gNB-NCR) and access (NCR-UE) links. At the same time, a control link is established between the gNB and NCR-MT modules, through which the gNB sends instructions to the NCR-MT regarding the desired repeater behavior. In addition to the control of the amplifier, the ability to control the repeater allows for additional features such as beamforming at the access antenna. Such features can be used to obtain further improvements in performance.

[0724] The NCR-MT generally behaves similarly to the UE in terms of the control plane protocols used, but uses new signaling to control the repeater operation. Other aspects in which the NCR-MT may differ from the UE are the NCR identification and authentication steps required when the NCR is first installed onto the network. A number of proposals are outlined in TR 38.867 v1.0.0 and these are briefly outlined here.

[0725] Proposal 3 (IAB-like, clause 8.1.3 in TR 38.867v1.0.0) and Proposal 4 (RedCap-like, clause 8.1.4 in TR38.867v1.0.0) are similar to each other and to the procedures used for regular UEs. The initial steps for the NCR-MT to establish access to the gNB and the NCR-MT follow the normal steps used by the UE. In Proposal 3, during this process, the NCR-MT indicates that it is an NCR and not a UE. Next, the network-based Access and Mobility Function (AMF) is used to authorize the NCR-MT as an NCR and establish link security.

[0726] These proposals have the advantage of using a recognized protocol as a basis, modified as needed to support NCR. Modifications to the core network (AMF) may also be required, making deployment less straightforward than traditional repeaters.

[0727] In Proposal 1 (clause 8.1.1 in TR 38.867v1.0.0), the AMF is used to establish link security, but the NCR is authorized to the UE, so no modifications to the core network are required. When the NCR provides the appropriate credentials to the gNB, the gNB performs any additional checks on the validity of the NCR.

[0728] Proposal 2 (clause 8.1.2 in TR 38.867v1.0.0) goes further by replacing the AMF with an OAM (operation and maintenance) module that is part of the Radio Access Network (RAN) rather than the core network. Since link security has not been established by the CN, if the NCR control traffic is not sent in plain text, it needs to be established by the OAM. The proposal description suggests that "security for OAM traffic can be provided by application layer security mechanisms (such as SSH / TLS between the NCR and OAM").

[0729] The following disclosures propose authentication and identification methods to prevent, for example, impersonation of a simple UE to an NCR or to prevent MitM attacks. These disclosures may be applied to Proposal 2 where the core network does not establish link security. They may also have some relevance to other methods where a secure link can be established but further verification of the NCR must be performed without the help of the network. Proposal 1 shows one possible process. It should also be noted that the disclosed methods are not limited to scenarios where the device to be connected to the network is an NCR and may be applicable to other situations where authentication and verification need to be performed without CN assistance.

[0730] Fig.14 A general deployment is described in which the NCR is currently serving a single UE. The NCR can be owned by the first network (network 1). The NCR can be connected through the RAN (i.e., RAN1 and RAN2) of the first network or the second network (network 2). The RAN can interact with the corresponding AMF / SEAF. The primary authentication of the NCR-MT is performed using the AUSF / UDM of network 1. A management entity (e.g., an application function (AF) or OAM) can manage the configuration of the NCR. If located in network 1, the AF can be AF1, if located in network 2, the AF can be AF2, or if located elsewhere, the AF can be AF3.

[0731] Embodiment 42

[0732] In a first embodiment focusing on a simplified deployment of NCRs where a single NCR is connected to a single gNB, the NCRs are owned and deployed by an operator in a fixed location to serve a specific gNB. For such an embodiment, security credentials can be preloaded on each side of the link, indexed at the gNB by an identifier shared by the NCRs. The credentials can range from a complete set of security keys down to a shared secret from which all security keys can be derived. There are various ways such credentials can be generated and shared. A simple example of a shared secret is a QR code or security PIN attached to a home Wi-Fi router. By entering it into a PC, phone or other device, both the device and the router have a shared secret that they can use to derive further security credentials in a secure manner using a protocol such as TLS.

[0733] Embodiment 43

[0734] In further embodiments, the NCR becomes a network component with more flexible deployment opportunities. For example, in one class of embodiments, the NCR is owned and operated by an entity other than the network operator. For example, in the earlier example, it may be owned by the owner of the building. In yet another class of embodiments, the NCR is used to provide infill coverage for more than one network simultaneously, i.e., it is shared by two or more networks. In such embodiments, it is not always feasible to preload the necessary security information to both sides, and an alternative method of securely establishing a shared secret is needed.

[0735] One class of methods that can do this is based on public key cryptography. It uses asymmetric cryptography to exchange enough information to derive a shared secret. Since only the public key is available, any third-party device that does not have access to the corresponding private key cannot derive the shared secret, even if it manages to capture the entire message exchange between the first two parties. A well-known algorithm that uses this method is the Diffie-Hellman key exchange.

[0736] This embodiment relies on a security mechanism based on EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). EAP-TLS is defined in RFC 5216 and forms the basis of WPA2 security for Wi-Fi. A graphical overview of the EAP-TLS process is provided in Fig.15 (Reference: David D.Coleman, David A.Westcott, Bryan Harkins, " Certified Wireless Security Professional Study Guide CWSP-205: Certified Wireless Security Professional Study Guide CWSP-205”, Wiley, 2nd edition, September 16, 2016, DOI: 10.1002 / 9781119419341).

[0737] The device that wants to access the network (the supplicant in EAP terminology) first establishes a data link with the authenticator and identifies itself to the authenticator. The authenticator notifies the authentication server that the supplicant is requesting access, and the authentication server then performs a certificate exchange with the supplicant to provide mutual authentication. If successful, the authentication server notifies the authenticator, and the authenticator then performs a 4-way handshake that securely establishes security keys on both sides of the link. Once the process is successfully completed, the supplicant and authenticator can establish a secure channel for data transmission.

[0738] For the NCR scenario, the NCR performs the role of the requestor, the gNB performs the role of the authenticator, and the OAM performs the role of the authentication server. This is suitable as it allows the OAM to serve multiple gNBs that comprise the radio access network, thereby allowing the NCR to have some flexibility in deployment in scenarios where the OAM also has the role of informing the gNB of the NCR capabilities. To support operation across multiple RANs, the OAM may be placed deeper in the network, or alternatively, OAMs belonging to different RANs may be allowed to communicate with each other and share information about the NCR. Fig.14 In the RAN, you can directly communicate with Fig.14 The communication is performed by one or more OAMs represented by AF1, AF2 and AF3.

[0739] Meanwhile, the gNB is responsible for the daily operation of the NCR and can obtain necessary configuration information from OAM or from the NCR itself without pre-loading it.

[0740] Since EAP-TLS was developed for operation in WLAN, there may be some detail differences between its implementation and similar mechanisms applicable to operation in 5G. For example, the conversation between the gNB and OAM may use protocols other than RADIUS. While EAP-TLS expects X.509-based certificates, other forms of certificates may be appropriate.

[0741] Other modifications may reflect perceived differences in the level of security required. For example, in a WLAN environment, it is important that both sides can authenticate each other. In the case of an NCR, it is important that the RAN can authenticate the NCR, but it may not necessarily be that important that the NCR can authenticate the RAN, since the reward for unauthorized access to the NCR is limited. In particular, user data is not decrypted by the NCR and is therefore not available to malicious users.

[0742] Some of these variations may also be reflected in other variations of EAP.Thus, although this description has been provided in the context of EAP-TLS, it should not be viewed as limiting in this regard.

[0743] Authentication and authorization procedures such as the EAP-TLS procedure described above may be implemented in TR 38.867v1.00. Figure 8.1.2-1 in step 7. Successful authentication and authorization results in message 8 in the same figure. This message may include the key K that has also been shared with the NCR (NCR-MT) based on the authentication and authorization process. Thus, subsequent control messages sent from the gNB to the NCR-MT can be protected. This key can be used to protect standard RRC messages enhanced with NCR-specific control fields. Alternatively, this key can be used to protect specific L2 or even L1 messages, for example, as shown in the above embodiments.

[0744] In other embodiments, such a key K may be used to protect traffic using in conjunction with RRC messages or L2 or L1 messages.

[0745] Embodiment 44

[0746] In a related embodiment, the NCRs are securely configured with certain keying materials during manufacturing. The OAM may obtain certain NCRs from the manufacturer, and the OAM may securely receive pre-configured keying materials from the manufacturer. The pre-configured keying materials may be used for the above-described (EAP-based) authentication and authorization processes.

[0747] In a related embodiment, the key material consists of at least one symmetric key.

[0748] In a related embodiment, the key material is stored in the USIM of the NCR mobile terminal.

[0749] Embodiment 45

[0750] In the current solution in TR 38.867v1.0.0, the NCR-MT exposes its capabilities before any security context has been established. And therefore, these security capabilities can be modified. For example, they expose the NCR indication information in the RRCSetupComplete message. Although some solutions (such as solution 1) include an NCR verification phase as soon as AS security is established (in TR 38.867v1.0.0, Figure 8 .1.1-1), but other solutions do not. Therefore, it would be beneficial if those parameters that need to be exchanged at an early stage (e.g., in RRCSetupComplete) could be protected at that stage, for example, as done in the above embodiments with UE security capabilities.

[0751] Embodiment 46

[0752] In solution 1, the gNB may perform an additional NCR verification. This can be done by checking whether the NCR indication received in RRCSetupComplete matches the information stored locally at the gNB. However, it is not described how this information is configured.

[0753] In a first alternative, the NCR can be used as a wireless repeater for a gNB operating in non-standalone (NSA) mode. In this case, the UE part of the NCR (e.g., in Solution 1) can perform an authentication process with the LTE core network. Once the UE part of the NCR is authenticated, the LTE CN can verify the UE's user subscription and notify the eNB of the result. If successful, the UE part of the NCR can arrange for a handover to a gNB with NCR capabilities and perform additional NCR authentication. In this way, the NCR can be used on an NSA network without changing the LTE CN.

[0754] Embodiment 47

[0755] Solutions such as solution 3 and 4 state that the AMF and other CN entities do further authorization, and it states that the AMF then provides the gNB with an "NCR authorization". However, it is not described how to do this. A further embodiment that achieves this / describes how to do it in the context of solution 3 for example is as follows: Once the gNB is in TR 38.867v1.0.0 Figure 8 .1.3-1 to the AMF, the AMF shall forward said information to the AUSF. The AUSF shall then retrieve the SUPI of the NCR-MT and retrieve data about its capabilities associated to the SUPI (NCR-MT). The AUSF may, for example, retrieve data from or interact with the UDM, UDR or PCF or other network functions. If these capabilities do not match, the AUSF may decide to stop the authentication process.

[0756] Embodiment 48

[0757] In a related embodiment, the UE part of the NCR may first perform a primary authentication procedure, and if successful, the AMF may retrieve the associated UE's user subscription capabilities from the AUSF / UDR and check whether the UE is an NCR as required in the received NCR indication. If so, the AMF provides an "NCR Authorized" indication to the gNB.

[0758] Embodiment 49

[0759] Solutions such as Solution 3 and 4 state that the AMF and other CN entities perform further authorization, for which, in another embodiment, the gNB is required to select an AMF with NCR capabilities.

[0760] Embodiment 50

[0761] When authenticating with the NSA network, the UE part of the NCR (e.g., in Solution 3 or Solution 4) can perform an authentication process with the LTE core network. Once the UE part of the NCR is authenticated, the LTE CN can verify the UE's user subscription and verify whether it is an NCR. If so, the LTE CN will notify the gNB, for example through the eNB, and the gNB can store the capabilities of the UE part of the NCR. Once this is completed, the UE part of the NCR can send a security message indicating its capabilities, such as RRCSetupComplete. The gNB can then verify these capabilities using the capabilities previously received. In this way, the LTE CN performs the necessary NCR authentication, but the day-to-day operation of the NCR becomes the responsibility of the 5G gNB.

[0762] Embodiment 51

[0763] Another further embodiment that addresses the needs in other embodiments includes protecting the initial NCR indication information as described in the above embodiments, for example, by means of a primary authentication process or protecting it with a public key of the home network.

[0764] Embodiment 52

[0765] The external AF may be responsible for at least part of the management of the NCR. For example, if the NCR is deployed in a private building, the building owner may wish to determine when the NCR is active in the bus, which areas need further coverage, etc. The external AF can manage the settings in the NCR by using AKMA as in TS 33.535, where the AF can use the keys derived from AKMA to set up a secure channel protected by the Ua* protocol to configure certain parameters in the NCR. This also applies to the case where the NCR-MT is roaming as described in the above embodiments.

[0766] Embodiment 53

[0767] Another further embodiment applicable to the above solution includes configuring the UE, i.e. the NCR-MT, with an authorization token (e.g., a set of attributes associated to the UE, such as the fact that the UE is an NCR-MT). This configuration can be done in the NCR-MT before deployment, or it can be securely sent to the NCR-MT once the NCR-MT has successfully completed the authentication and authorization steps as in embodiment 5c. The next time the NCR-MT attempts to join another gNB, the NCR-MT can share such a token with the gNB so that the network function in the gNB or CN can verify its authorization.

[0768] Embodiment 54

[0769] In another further embodiment, once the NCR has been authenticated and authorized, for example, as described in the above embodiments, the NCR may send or receive its configuration and capabilities. The configuration may refer to the configuration in clause 7.2 of TR 38.867, and may include one or more configurations of a PHY channel to carry L1 / L2 signaling including configurations for receiving PDCCH and PDSCH, for sending PUCCH (if necessary) or for sending PUSCH (if necessary), and L1 / L2 signaling including configurations for DCI, UCI (if necessary) and for MAC CE (if necessary). Capabilities may include parameters such as those in the following table. One or more of these parameters may be exchanged and stored:

[0770]

[0771]

[0772] Embodiment 54

[0773] The above management solutions may coexist, in which case it may be necessary to move / roam / export / import NCR data from a management system to another management system. For example, in solution 2, OAM can store information about the deployed NCRs, their capabilities / configurations, encryption keys, authorization status, etc. When one or more NCRs need to be migrated to a different solution (e.g., solution 3), the data needs to be exchanged and stored in the corresponding entity (e.g., network function in the core network, as it can be AMF, UDM, UDR, etc.). This data can be exchanged through NEF.

[0774] Embodiment 55

[0775] Once the NCR is authenticated and authorized, the gNB needs to be configured with one or more of the above NCR capabilities. This can be used by the gNB to determine how to connect to the NCR and optimize the control or forward link.

[0776] In one embodiment, if the gNB and NCR-MT share one or more keys, the gNB may request specific parameters, e.g., via an RRC message, or the NCR-MT may securely and proactively send those parameters to the gNB, e.g., also in an RRC message.

[0777] In a further embodiment, if the NCR-MT and the gNB do not share a common secret, the gNB may request the NCR capabilities from a management entity (e.g., AF or AMF). The management entity may also securely and proactively send those parameters to the gNB. For example, in the context of the above embodiment, the management entity (AF) may receive the NCR capabilities from the NCR during the authentication / authorization process. Once the NCR is authenticated, the management entity (AF) may also retrieve them from, for example, a database. Upon authentication and authorization, the management entity may share one or more of those NCR capabilities with the gNB.

[0778] Embodiment 56

[0779] The above embodiments (e.g., related to NCR) may also be applicable to mobile base station relays (MBSRs) or vehicle-mounted relays, whose service requirements have been studied in TR 22.839 and specified in TS22.261. MBSR refers to a mobile base station (e.g., a mobile IAB node) installed on, for example, a vehicle (such as a bus, a drone, or a satellite). The MBSR can move around when / where needed and provide enhanced connectivity. The MBSR may be owned by a third party, or may roam to a network to which the MBSR is not a subscriber. This is different from the existing IAB architecture, in which the IAB node is assumed to be owned and operated by the same PLMN to which the IAB node has a subscription.

[0780] Embodiment 57

[0781] In one scenario, the UE part of MBSR (equivalent to IAB-MT in IAB) can register in the network (e.g., HPLMN) through the gNB managed by the VPLMN as usual (e.g., through primary authentication). The VPLMN may be looking for services of MBSR. The question raised by this situation is how to allow the VPLMN to utilize MBSR. This involves authorization from the HPLMN or the MBSR owner to allow the VLPLMN to use the MBSR.

[0782] In an embodiment, the UE part of MBSR may indicate the fact that it is MBSR in the UE capabilities (eg, exchanged in an RRC message or a registration message) so that the network (eg, VPLMN) is aware of this fact.

[0783] In one embodiment, the gNB or NF in the network (e.g., VPLMN) may be informed of the fact that the UE part being registered is part of MBSR. This may also require the gNB to send a message to the CN or VPLMN OAM to notify this fact and / or send a message to the entity responsible for MBSR (e.g., HPLMN or a third party or OAM in the HPLMN) requesting the use of MBSR.

[0784] In an embodiment, the network (e.g., VPLMN) may require additional resources and may send a request to the MBSR owner with its requirements (e.g., location requiring additional connectivity, service type, etc.). The network may send a request to the NF (e.g., AMF) and / or RAN indicating that a new MBSR unit may join / register with the network.

[0785] In one embodiment, the AMF in the network (e.g., VPLMN) may use a message (e.g., a NAS message) to provide the MBSR with credentials for connecting to the network (e.g., VPLMN) OAM so that the MBSR may retrieve configuration parameters for the network (e.g., VPLMN), such as which PCI is assigned, beam configuration, etc.

[0786] In one embodiment, the AMF (or other NF) in the network (e.g., VPLMN) may use NAS messages to provide MBSR with MBSR configuration parameters for the network (e.g., VPLMN), such as which PCI is allocated to MBSR, MBSR beam configuration, etc. The AMF may obtain this information from the VPLMN OAM.

[0787] In one embodiment, a gNB-Central Unit (CU) in the network may use a configuration message to provide MBSR with MBSR configuration parameters for the network (e.g., VPLMN), such as which PCI is allocated to MBSR, MBSR beam configuration, etc. The gNB-CU may obtain this information from the network OAM.

[0788] In a related embodiment, the network (e.g., VPLMN (e.g., AMF)) may send a request to use / terminate / modify MBSR services to the HPLMN (e.g., AMF or NF or function responsible for managing MBSR) or AF (responsible for MBSR).

[0789] In a related embodiment, the request to the HPLMN or AF may include the services required by the MBSR, which may include the location or timing of the required services.

[0790] In one embodiment, the MBSR will only accept the security credentials / configuration parameters if it has received a positive confirmation from the HPLMN or AF responsible for the MBSR or MBSR owner serving network. The confirmation may be based on a protected (e.g., integrity protected message), end-to-end protected message sent from the HPLMN / AF to the UE.

[0791] In a related embodiment, the protected message may include a configuration with details for MBSR stating which services may be provided by MBSR to the network (eg, VPLMN).

[0792] In a related embodiment, according to TS 33.501 clause 6.15.2.1, the protection message may be end-to-end protected from the HPLMN end to the UE via UE parameter update (UPU).

[0793] In a related embodiment, the MBSR may belong to a third party that manages the MBSR through the AF, which is connected to the MBSR through an AKMA. In a related embodiment, protected messages are exchanged between the AF and the MBSR through a Ua* interface.

[0794] In a related embodiment, the NF in the VPLMN may contact the AF or the NF in the HPLMN so that the latter sends the confirmation / configuration parameter message and other configuration parameters to the MBSR.

[0795] In a related embodiment, the MBSR belongs to a third party, and the MBSR and the third party are authenticated through secondary authentication, and once the secondary authentication is successful, configuration parameters are securely exchanged through an EAP connection.

[0796] In a related embodiment, the MBSR is configured with an authorization token securely provided by an entity managing the MBSR.The MBSR may also be configured with a policy that determines (the type of) network the MBSR should access and provide connectivity services to.

[0797] In a related embodiment, an MBSR may be configured with a unique authorization token and / or share authorization tokens with other MBSRs. An MBSR may also be configured with a unique policy or share the same policy that determines the (type of) network it should access and provide connection services to other MBSRs.

[0798] In a related embodiment, the MBSR sends an authorization token to the network so that the network can verify the credentials / authorization authority to provide MBSR services to the network. The entity that checks the credentials can be, for example, the gNB-CU or AMF.

[0799] In a related embodiment, a third party managing MBSR provides authorization tokens to networks willing to use MBSR. The authorization tokens determine the access rights (services) that the network needs from MBSR, and when the authorization tokens are disclosed to MBSR, the services of MBSR are requested. In this way, the network can obtain / purchase multiple authorization tokens and use them as needed.

[0800] In a related embodiment, the MBSR may need to send a "used" token to a third party so that the "used" token is marked as used. The "used" token may be stored in a list of "used" (or revoked) tokens shared with all MBSRs so that the MBSR can check whether the received token is / remains valid.

[0801] In a related embodiment, the token may have a short lifespan, ie, be valid only for a short period of time, so that a revocation list is not required.

[0802] In a related embodiment, the MBSR and the network exchange authorization tokens over a secure interface (eg, in an RRC message or over an F1-C interface or in a NAS message).

[0803] In a related embodiment, the network may send a (protected) confirmation (eg, an authorization token) confirming that the service is being provided by the MBSR. This confirmation may be shared with the MBSR owner for billing purposes.

[0804] The above-described embodiments may be combined with each other where applicable.

[0805] In the above embodiments related to smart repeaters and MBSRs, it can generally be applied to other types of network access devices, such as smart repeaters, MBSRs, unmanned aerial vehicles (UAVs), satellites, reflective smart surfaces, etc.

[0806] Generally, a method and apparatus are described which may be implemented on a (mobile) network access device for handling authorization to serve a network, whereby the apparatus:

[0807] – is configured with a policy that determines the conditions under which it can connect to the network and access a token to connect to the network,

[0808] - when the conditions are met, establish a (secure) connection to the network,

[0809] -Sends an access token to the network to prove its authorization.

[0810] - An authorization token may be received from the network to prove service provisioning for billing purposes.

[0811] Embodiment 58

[0812] TR 33.870, v 0.4.0 studies the privacy of identifiers exchanged over the radio access network. The issue in this TR is key issue #2 and is related to the fact that the "priority access" value exchanged during the initial random access process is not protected, in other words, the 5G standard allows the use of establishment causes such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess" to be sent over the air in plain text.

[0813] Potential solutions to this problem include the following steps:

[0814] 1. The UE performs a random access procedure as usual with the base station, including the “random value” in message 3, where the base station is in the serving / home network.

[0815] 2. The UE performs primary authentication with the serving network and the home network.

[0816] 3. Once the NAS security context is established, a public / private key pair is distributed from the HN to the UE and gNB. This key pair can be the key pair of the serving network. This configuration can also be pre-configured.

[0817] 4. Once AS security is established, the UE moves to the RRC_Connected state.

[0818] 5. When the UE moves to the RRC_idle or RRC_INACTIVE state, the UE must perform connection establishment again (through a new random access procedure, such as a 4-message random access procedure).

[0819] a.UE sends initial preamble

[0820] b.gNB replies with a Random Access Response

[0821] c. The UE uses the public key from step 3 to encrypt e.g. 5G-S-TMSI-part1 or I-RNTI with establishment or resumption reason (“Priority Access”) and sends it to the gNB.

[0822] d. The gNB uses the private key from step 3 to decrypt the message RRCSetup which it replies with message 4.

[0823] e. The UE completes the process of sending RRCSetupComplete and moves to the RRC_Connected state.

[0824] Steps 1-4 may be considered configuration steps, and step 5 may be considered an operational phase, where privacy of the establishment reason ("priority access") may be given security guarantees.

[0825] Problems with the above approach include:

[0826] Public keys are long and public key operations are expensive, making it more efficient to try to replace those long keys / expensive operations with simpler operations when feasible;

[0827] The value encrypted using the public key is large and may not fit in message 3;

[0828] It requires configuring the serving network’s private key in the gNB, which poses a security risk.

[0829] Therefore, in an embodiment, step 3 is replaced by sharing a symmetric key and / or one-time pad and / or an identifier (of the key / one-time pad) which may be used by the UE to protect steps 5c-d.

[0830] In an embodiment that may be combined with other embodiments, step 5d is enhanced by requesting the AMF (or other NF in the serving network, such as UDM) to decrypt the received message using the private key of the serving network, so that the gNB does not need to be configured with the private key of the serving network.

[0831] In an embodiment that may be combined with other embodiments, step 3 is replaced by a gNB-specific public key pair so that the gNB does not need to be configured with the serving network's private key.

[0832] In a further embodiment, which may be combined with other embodiments, the UE encrypts the message using a key or a one-time pad and sends the encrypted message in step 5c.

[0833] In a further embodiment, which may be combined with other embodiments, the gNB decrypts the message using a key or a one-time pad and sends the encrypted message in step 5d.

[0834] In a further embodiment, which may be combined with other embodiments, the message is encrypted using a key using the NEA algorithm, wherein the plain text input is the portion of the message that needs to be protected and the provided key is used as the encryption key.

[0835] In a further embodiment, the provided key is derived from K_gNB by means of a key derivation function.

[0836] In a further embodiment, which may be combined with other embodiments, the message is encrypted using a key with the NEA algorithm, wherein other inputs include a counter value depending on the UTC time.

[0837] In a further embodiment, which may be combined with other embodiments, the message is encrypted by XORing the message field to be protected with the received one-time pad.

[0838] In further embodiments that may be combined with other embodiments, the key (e.g., K gNB ) or extract the one-time padding key based on the key derived from it using a key derivation function.

[0839] In a further embodiment that may be combined with other embodiments, the gNB may randomly select and send (e.g. in step 5b) a location (e.g. in K ) from which the UE should extract the one-time pad key to encrypt the RRC resumption cause. gNB in).

[0840] In a further embodiment that may be combined with other embodiments, the gNB and the UE may use KDF from K gNB The first k bits or the first k bits from K gNB The gNB uses the derived key to encrypt (e.g. on the UE side) and decrypt (e.g. on the gNB side) the RRC resumption cause. This has the advantage that the index and / or key identifier does not have to be transmitted to the UE. The gNB retrieves the correct K from the UE's security context based on its identity (e.g. full / short I-RNTI) included in the RRCResumeRequest. gNB .

[0841] In a further embodiment, which may be combined with other embodiments, the message fields to be protected may include: 5G-S-TMSI-part1 or establishment cause ("Priority Access").

[0842] In a further embodiment, which may be combined with other embodiments, the message is encrypted by XORing the message to be protected with the output of a key derivation function, the input of which may include a provided key or a UTC-based counter (e.g., as used in TS 33.503) or other fields in the message.

[0843] In a further embodiment, which may be combined with other embodiments, the encryption parameters (symmetric key / one-time pad) are stored in the gNB or in a NF (e.g. AMF) including an identifier.

[0844] In a further embodiment, which may be combined with other embodiments, the message includes an identifier allowing the gNB to determine the key or one-time pad to be used in decryption.

[0845] In a further embodiment, which may be combined with other embodiments, the encrypted message includes an identifier (encrypted or plain text) that allows the gNB to determine the key or one-time pad to be used in decryption.

[0846] In a further embodiment, which may be combined with other embodiments, if the gNB does not store the key / one-time pad required to decrypt the incoming message 3, the gNB may look for it in a different gNB (e.g. a switched-off gNB) or in the AMF.

[0847] In a further embodiment, which may be combined with other embodiments, the gNB may include a key identifier in the random access response (message 2), which the UE uses to select the key / one-time pad required to encrypt message 3 in step 5-c.

[0848] In further embodiments, which may be combined with other embodiments, looking up a key / one-time pad may require sending a request including an identifier of said one-time pad or key.

[0849] In a further embodiment that may be combined with other embodiments, the encrypted message consists of 48 bits, where: k bits may be used to identify a key or a one-time pad identifier, t bits are the encrypted message, and 48-kt is other information (e.g., random data and / or a UTC-based counter).

[0850] In further embodiments, which may be combined with other embodiments, the identifier field is not included in the message 3, for example if a single symmetric key or a single private key exists in the serving network.

[0851] In a further embodiment, which may be combined with the previous embodiment, a concatenation of fields is used as a “random value” in message 3 .

[0852] In an embodiment that may be combined with other embodiments, the UE may attempt to perform the encryption of step 5c using a symmetric key or one-time pad, and if the gNB cannot decrypt, the gNB signals this fact in message 4 (step 5d). The gNB may not be able to decrypt it if, for example, the UE moves to a different gNB that does not know the preconfigured key / one-time pad, or if the gNB no longer stores those parameters.

[0853] In an embodiment that can be combined with the previous embodiment, if the UE receives a message 4 indicating that the message 3 encrypted with the symmetric key / one-time pad cannot be decrypted, the UE may attempt to perform step 5c again using the public key of the serving network to encrypt the privacy-sensitive parameters in step 5c.

[0854] Therefore, according to this embodiment, a method for securely performing a random access process between a user equipment, a UE and a base station (or an access device) in a wireless network is proposed, wherein the method includes: receiving an encryption key K linked to the access device and the UE; determining or receiving an L-bit sequence s; and encrypting s with K into V; and sending V.

[0855] Therefore, according to this embodiment, a method is proposed, which also includes receiving a public key associated to an access device or a service network.

[0856] Therefore, according to this embodiment, a device for securely performing a random access process is proposed, wherein the device includes a transceiver and a control unit, and the device is arranged to receive an encryption key linked to an access device and a UE; determine or receive an L-bit sequence s; and encrypt s with K into V; and send V.

[0857] Therefore, according to this embodiment, a method for securely performing a random access procedure between a user equipment UE and a base station (or access device) in a wireless network is proposed, wherein the method includes receiving an encrypted message, retrieving an encryption key, and decrypting the message.

[0858] The techniques in different embodiments may be combined with each other.

[0859] Embodiment 58

[0860] A potential solution to KI#2 in TR33.870 to protect the privacy of the RRC resume reason may be to assume that the UE has established an AS security context while in the RRC_CONNECTED state before transitioning to the RRC_INACTIVE state. The UE may indicate to the network whether it supports encryption of the resume cause (resumeCause) and its capabilities, such as the supported encryption algorithms and encryption keys. The symmetric key may be part of the UE's AS security context. The encryption may be length-preserving, i.e., the length of the bit string representing the resume reason in plain text remains the same as the bit string of the encrypted resume reason.

[0861] On the UE side, when the UE transitions from the RRC_INACTIVE state to the RRC_CONNECTED state by sending an RRCResumeRequest, the solution may use the RRCRelease message sent by the network to inform the UE which key and encryption algorithm to use to encrypt the resumption cause in consecutive RRCResumeRequest messages.

[0862] On the network side, the gNB / ng-eNB uses the I-RNTI sent by the UE in the RRCResumeRequest message to retrieve the UE context and encryption keys required to decrypt the resumption cause. The decryption can be done by the source gNB / ng-eNB or the target gNB / ng-eNB.

[0863] The following embodiments may be applied to further improve the security of the solution.

[0864] In a first embodiment, the algorithm and / or key to be used is determined by a policy that can be configured in the initial configuration or on demand. This has the advantage that the encryption algorithm and / or key in the RRCRelease message does not need to be indicated and does not need to be changed.

[0865] In a second embodiment, the algorithm and / or key to be used is determined and indicated by the UE, since not all UEs may have the same capabilities or preferences. This has the advantage of better adapting to UEs with different security preferences.

[0866] In a further embodiment, the network may send a message such as a RRCRelease message to inform the UE which key, encryption algorithm and parameters to use to encrypt the recovery cause in the consecutive RRCResumeRequest messages. For example, if the UE must use the NR encryption algorithm (NEA) algorithm, it also requires some additional configuration parameters (counters, bearers, ...) that both parties need to know.

[0867] In a further embodiment, a UE with the capability to protect the resumption cause may indicate the fact that the resumption cause is protected so that the gNB can determine whether it is protected or not and handle it accordingly. This embodiment has the advantage of ensuring backward compatibility.

[0868] In a further embodiment, a UE with the capability to protect the recovery cause may protect the recovery cause only if the gNB has indicated, for example in SIB1, that it can handle the protected recovery cause field. This embodiment has the advantage of ensuring backward compatibility.

[0869] In a further embodiment, the symmetric key may be calculated as follows:

[0870] When deriving a symmetric key K to protect recovery reasons, one or more of the following parameters may be used to form the input to the KDF used to derive the key:

[0871] o an identifier, such as an I-RNTI (short or full I-RNTI, depending on whether the field useFullResumeID is present in SIB1),

[0872] o the length of the identifier, for example the length of the I-RNTI,

[0873] o a time counter, such as a UTC-based counter,

[0874] ο a random number determined by the gNB,

[0875] o A random number determined by the UE.

[0876] The KDF input key may be, for example, the key K established before the UE switches to the RRC_INACTIVE state. gNB or K RRCEnc .

[0877] In a further embodiment, the bit sequence for the protection restoration reason is determined and used according to one or more of the following variations:

[0878] - In a variant, if b bits need to be protected, b bits of the key are used as the bit sequence.

[0879] - In a variant, the protection is performed by XORing the b bits that need to be protected (eg the recovery reason) with the bit sequence.

[0880] - In a variant, regardless of whether the UE uses RRCResumeRequest or RRCResumeRequest1 (depending on the useFullResumeID field present in SIB1), the resume cause is always 4 bits (b=4) long. As such, if a one-time pad mechanism is used to protect the resume cause, the bit sequence used as a one-time pad key may be, for example, the first b or last b (e.g., b=4) bits or any subset of the b (=4) bits of the symmetric key K derived from K_gNB, as described in the previous embodiments.

[0881] - In a variant, the gNB may determine (e.g. randomly) the index from which the UE should extract the bit sequence of length b (e.g. b=4) bits and send it to the UE as part of the suspendConf parameter of the RRCRelease message. In this case, the gNB may need to save the index in the context of the UE if, for example, the index is UE-specific.

[0882] - In a variant, the gNB may (e.g. randomly) determine the index from which the UE should extract the bit sequence of length b (e.g. b=4) bits and send it to the UE as part of the random access procedure message 2 (i.e. the random access response) or in SIB 1. This has the advantage that the gNB does not have to save the index for a longer period of time.

[0883] - In a variant, a (derived) key is used in the NEA algorithm to protect the recovery reason, wherein the counter field may be a time-based counter. Thus, the NEA algorithm is used to generate a bit sequence and use it to protect the recovery reason.

[0884] In a further embodiment, if a random number (or more than one random number) is used in the derivation of keys or in the process of protecting information (resumption reasons), the gNB may include a randomly generated random number in the suspendConf parameter of the RRCRelease message, which the UE uses, for example, as a parameter of the KDF to derive K. Additionally or alternatively, the UE may include the random number in its message to the gNB. The random number may be 5G-S-TMSI-part1 or a part thereof. In other words, one or more random numbers may be an explicit new field or an implicitly sent random number that reuses an existing field.

[0885] In a further embodiment, if a UTC-based counter is used in the derivation of keys or in the process of protecting information (recovery reasons), the least significant bits of the counter may be included in the message from the gNB to the UE or from the UE to the gNB.

[0886] Embodiment 60

[0887] Another potential solution to the problem described in the previous embodiment can be described as follows:

[0888] During the access control check procedure (specified in subclause 4.5.4 of TS24.501), the UE determines whether the network is overloaded based on the prohibition control information broadcast by the NG-RAN. Specifically, if the prohibition control information is broadcast by the NG-RAN, the UE considers that the network is overloaded, and if the prohibition control information is not broadcast, the UE considers that the network is not overloaded.

[0889] For UEs with RRC establishment cause values ​​"mps-PriorityAccess" and "mcs-PriorityAccess", the value of the reported RRC establishment cause is determined by the following rules:

[0890] - If the network is not overloaded (i.e., the inhibition control information is not broadcast), the UE hides its high priority attribute and determines the reported RRC re-establishment cause based on the UE's access category. If the UE is rejected after RRCSetupRequest, the UE reports its high priority access cause value ("mps-PriorityAccess" and "mcs-PriorityAccess") in the next RRC Connection Request message.

[0891] - If the network is overloaded (ie control information is prohibited from being broadcast), the high priority access cause values ​​"mps-PriorityAccess" and "mcs-PriorityAccess" are used directly for the current mechanism.

[0892] For a UE with an establishment cause of "highPriorityAccess", the reported RRC establishment cause is determined according to the access category of the UE instead of "highPriorityAccess".

[0893] This approach requires several considerations:

[0894] First, the solution does not consider the establishment cause "highPriorityAccess", that is, when the UE indicates "highPriorityAccess", it is recommended to determine the establishment cause based on the access category of the UE instead of using "highPriorityAccess". However, according to clause 8.7.7 in TS 38.413, if the AMF is in an overload state, it can request from the NG-RAN to reduce the signaling load toward it and only allow certain RRC connection establishments, such as RRC connection establishments for high priority sessions and mobile terminated services (that is, only allow services corresponding to the RRC causes "highPriorityAcces", "mps-PriorityAcces", "mcs-PriorityAcces" and "mt-Acces" in TS 38.331 or "highPriorityAcces", "mo-ExceptionDat" and "mt-Acces" in TS36.331). Therefore, the solution misses covering the establishment cause "highPriorityAccess". In addition, in clause 7.4 of TS 38.300, the paragraph describing which establishment causes are handled by the gNB is as follows:

[0895] "The gNB handles access attempts with establishment cause "emergenc", "mps-PriorityAccess" and "mcs-PriorityAccess" (i.e. emergency call, MPS, MCS subscribers) with high priority and responds to these access attempts with RRC Reject only under extreme network load conditions that could threaten the stability of the gNB". This is inconsistent with TS 38.413 as the AMF can indicate to the NG-RAN that it is overloaded, in which case it would expect the establishment cause "highPriorityAccess" to be handled by the NG-RAN. This conflicts with the above solution as, based on this, for a UE with establishment cause "highPriorityAccess", the reported RRC establishment cause is determined based on the UE's access class rather than "highPriorityAccess".

[0896] Therefore, in a first embodiment to address this issue, the gNB can indicate whether the AMF is overloaded, for example, by a message in SIB1. This has the advantage of allowing the UE to choose whether to use its normal UE access category (if the AMF is not overloaded) or to use the "highPriorityAccess" of the AMF overload. This means that in normal cases, the access reason is only disclosed when the AMF is overloaded. This embodiment has the advantage of reducing the privacy risk in a practical way, i.e. the privacy risk only arises when the AMF is overloaded.

[0897] In another embodiment that addresses this issue, a UE with a setup cause "highPriorityAccess" can use the UE's access category as the access category. If the UE is rejected after an RRCSetupRequest, the UE reports its high priority access cause value ("highPriorityAccess") in the next RRC Connection Request message. This means that under normal circumstances, no access cause is disclosed, and only when the UE is rejected (for example, because the AMF is overloaded), the access cause is disclosed. This embodiment reduces privacy risks in a practical way.

[0898] In another embodiment, the overloaded AMF may set a policy in the gNB such that only access attempts with establishment cause "emergency", "mps-PriorityAccess" and "mcs-PriorityAccess" are processed, while access attempts with establishment cause "highPriorityAccess" are not processed. This has the advantage of ensuring consistency of the configured policy and limiting the possibility of misusing the "highPriorityAccess" cause value (e.g. for DoS attacks).

[0899] Another problem with this solution is that when the UE reports its high priority access cause value in the setup cause (e.g. if the network is not overloaded and the UE is rejected after the RRCSetupRequest, or if the network is overloaded), it does so without any form of protection. This way, an attacker (e.g. a man-in-the-middle attacker) can use a fake base station to broadcast inhibit control information or indicate (e.g. via SIB1) that the AMF is overloaded, in which case the victim UE will report its high priority access cause value in plain text in the RRCSetupRequest.

[0900] In an embodiment aimed at solving the above-mentioned problem, if a security context (e.g., AS security context) is available or can be established and the UE has to report its resumption reason (e.g., a high priority access reason, e.g., because the network is overloaded), the UE can, for example, protect the RRC establishment / resumption reason using an (existing) symmetric key (e.g., K_gNB) or a key derived therefrom, e.g., with the aid of a key derivation function.

[0901] In a related embodiment aimed at further minimizing the privacy risk Priority Access Cause, the UE may protect the RRC Establishment / Resumption Cause using a symmetric key (e.g., K_gNB) or a key derived therefrom (e.g., by means of a key derivation function) regardless of whether a high priority access cause value needs to be transmitted (e.g., due to AMF overload). This has the advantage of not implicitly leaking that the protected part of the message relates to a high priority access cause.

[0902] In a related embodiment intended to further minimize privacy risk priority access reasons while optimizing performance, UE-protected RRC establishment / recovery causes may be required if the device has first rejected a first message from the device and / or a second device has indicated an overloaded AMF.

[0903] In a related embodiment, the gNB may use the UE identity (e.g., I-RNTI) included in the RRCResumeRequest to identify the security context of the gNB hosting the UE and, if necessary, retrieve the corresponding key material, e.g., K gNB or K RRCEnc .

[0904] In another embodiment, the UE may protect the RRC establishment / recovery cause via a one-time padding mechanism using a subset of the symmetric key (e.g., K_gNB) or a key derived therefrom (e.g., via a key derivation function).

[0905] In another embodiment, the encryption key used to protect the RRC establishment or recovery reason may be K RRCenc Or a key derived therefrom (e.g., with the aid of a key derivation function).

[0906] In another embodiment, the UE may encrypt the RRC Setup / Resume Cause or the entire RRCSetupRequest / RRCResumeRequest message using a (pre-configured) public key (e.g. assigned to the UE when the NAS security context is established). In this case, the gNB decrypts the RRC Setup / Resume Cause or the RRCSetupRequest / RRCResumeRequest message using a private key associated with the public key used for encrypting.

[0907] In another embodiment, the asymmetric key may be ID-based, enabling the central party (e.g., NF) to compute a private key associated with the ID. The UE may determine the public key used to protect the RRCResume cause protection based on a common parameter shared by the central party when the UE is in RRC_CONNECTED state, as part of the suspendConf parameter of the RRCRelease message, or through, for example, SIB1 broadcast by the gNB. When the gNB receives the RRCResumeRequest, it forwards the UE identity (e.g., I-RNTI) used to derive the public key to the central party in order to request / retrieve the corresponding private key. The gNB retrieves the protected resume cause using the provided private key.

[0908] In a related embodiment, the information to be used as an ID to derive the public key may be explicitly broadcast by the gNB as part of SIB1. As such, the UE may protect the entire RRCSetupRequest or RRCResumeRequest / RRCResumeRequest1, including the UE identity (e.g., 5G-S-TMSI-Part1 or I-RNTI) and the establishment or resumption cause, with the derived public key. If the gNB does not already have the private key, it requests / retrieves the private key from the relevant central party.

[0909] In another related embodiment, the gNB may indicate in a message (e.g., a random access response) a (key) identifier and / or index that the UE may use to select and / or determine a key to be protected for an RRC establishment / resumption cause or RRCSetupRequest / RRCResumeRequest.

[0910] In another embodiment, when transitioning from RRC_INACTIVE to RRC_ACTIVE, the UE sends a RRCResumeRequest (or RRCResumeRequest1) with a protected resumption cause to the gNB; the latter uses the I-RNTI to resolve the gNB ID of the gNB that allocated the UE context. However, according to clause 9.2.2.4.1 in TS 38.300, the gNB may not be able to retrieve or verify the UE context, in which case it performs a fallback by sending an RRCSetup to the UE to establish a new RRC connection. An alternative approach could be to send an RRCReject with a failure cause (e.g., failure to resolve the gNB ID) to the UE and instead request the UE to send an RRCResumeRequest1 with the full I-RNTI.

[0911] In a related embodiment that may be combined with the previous embodiment, the gNB may send an RRCReject with a failure cause (e.g., failure to resolve the gNB ID) to the UE and request the UE to use an alternative method (e.g., based on a (pre-)configured public key) to protect the RRCResumeRequest. The gNB may include an identifier or part thereof in the RRCReject message to indicate to the UE which method to use, e.g., which public key to use.

[0912] In a related embodiment, the use of encryption / protection of fields such as the resumption cause may require the use of a long I-RNTI. This may facilitate retrieving the correct security context. This also means that if the field is / needs to be encrypted, a long I-RNTI is used. If the field is not protected, a short I-RNTI is used. This may be determined by policy. In another embodiment, the RRCResumeRequest may not fail due to the gNB resolving the old gNB ID, but due to a failure to verify the UE context (e.g., the gNB may retrieve the UE context, but the decryption of the resumption cause failed). In this case, the gNB may send an RRCReject to the UE with a failure cause (e.g., failure to verify the UE context) and request the UE to retry resuming the RRC connection again using the (pre-)configured public key.

[0913] In a related embodiment, the gNB may determine that decryption has failed if, for example:

[0914] - the decrypted field (e.g., recovery reason) is invalid, and / or

[0915] -CRC failed, and / or

[0916] -MIC is available, and MIC verification fails.

[0917] In a related embodiment, the UE may be configured with a policy (which may also be hard-coded in the source code or configured by the CN or RAN) that determines how the UE should (re)establish or resume an RRC connection, depending on factors including but not limited to:

[0918] - Failure reason (e.g., failure to resolve old gNB ID or UE context verification failure); and / or

[0919] -I-RNTI type (e.g., short or full); and / or

[0920] - Whether the UE is (pre-)configured with a public key.

[0921] Additionally, in situations where high priority establishment or recovery reasons cannot be protected (e.g., joining the network for the first time, or a RRCResumeRequest failure due to a failed UE context verification with no public key available), the policy may allow the UE to use a non-high priority reason or an "emergency" reason. This has the advantage of letting the UE establish a connection without revealing its identity.

[0922] In related embodiments, a protected message may refer to an encrypted message and / or an integrity protected message and / or a freshness protected message.

[0923] In another embodiment, if the above solution is used, the AMF experiencing load difficulties should not set a policy in the gNB to allow access "highPriorityAccess".

[0924] In another embodiment, if the above solution is used, the AMF experiencing load difficulties can set a policy in the gNB to allow access "highPriorityAccess", however, based on the above solution, "highPriorityAccess" UEs will be used.

[0925] According to the above embodiments, a device and method for securely transmitting an establishment / recovery cause associated with an access identity of a user equipment from a user equipment to a network entity (e.g., a base station or an access device) in a message of a random access process are proposed, wherein the method includes: the network entity indicates an encryption key to the user equipment / the network entity (pre-)configures the user equipment with an encryption key to use the encryption key during the (re)establishment or resumption of an RRC connection; the UE uses the encryption key to protect the establishment / release cause, and sends an RRCSetupRequest or RRCResumeRequest containing the protected establishment / recovery cause and the UE identity associated with the UE context; the network entity retrieves the UE context and / or encryption key associated with the UE identity, and uses the key to reveal the protected establishment / recovery cause.

[0926] According to the above embodiments, an apparatus and method that can be implemented in a first device (e.g., a user equipment) is proposed to securely transmit a field (e.g., an establishment / recovery reason) associated with an access identity of the device to a second device (e.g., an access device), wherein the method / apparatus is applicable to one or more of the following:

[0927] - receive an indication from the second device about the AMF load status and only use "highPriorityAccess" access if the AMF is overloaded;

[0928] - Use a high priority access cause value ("highPriorityAccess") in a second message (e.g., an RRC Connection Request message) only if the UE is rejected after the first message (e.g., an RRCSetupRequest);

[0929] The priority access cause is only protected (e.g., encrypted) if the device has been rejected the first time and / or the second device has indicated an overloaded AMF.

[0930] Embodiment 62

[0931] The Subscription Hidden Identifier (SUCI) is introduced to hide and preserve the privacy of the Subscription Permanent Identifier (SUPI). As specified in clause 6.12.2 of TS33.501, the SUCI contains six parts: SUPI Type, Home Network Identifier, Routing Indicator, Protection Scheme Identifier, Home Network Public Key Identifier, and Scheme Output. The Home Network Identifier (HNI) and Routing Indicator (RID) (defined in clause 2.2B of TS 23.003) are used to identify and route communications to the subscriber's home network.

[0932] Potential privacy issues may arise from the fact that the home network identifier and routing indicator are not hidden / encrypted / protected in the SUCI. For example, an adversary listening on the air interface may be able to identify and track subscribers with sensitive home network identifiers, e.g. public safety officials (e.g. police) with UEs subscribed to a public safety PLMN may be distinguished from other (nearby) UEs and / or subscribers of the 5G private network. This is similar to the issues described in other embodiments, where the (rough) location of the UE needs to be shared, e.g. in the NTN use case.

[0933] Therefore, an object is to provide a means to prevent an attacker from learning these private information by eavesdropping on the air interface.This object can be solved by one or more embodiments which can be suitably combined with each other.

[0934] In an embodiment, a UE attempting to connect to a network / perform initial registration (e.g., home network) may do the following:

[0935] - Hiding / encrypting one or more first identifiers (eg SUPI) as described in TS 33.501, thereby deriving SUCI (first hidden identifier).

[0936] - Using a public key of a serving network (eg, VPLMN) to hide / encrypt one or more second identifiers (eg, a home network identifier (HNI) and / or a routing indicator (RID), etc.), thereby deriving a hidden home network identifier and routing indicator (CHNIRI).

[0937] -Sending the first hidden identifier (SUCI) and the second hidden identifier (CHNIRI) to the serving network through the radio access network.

[0938] In related embodiments, hiding / encrypting may also refer to security protection, such as confidentiality protection or integrity protection.

[0939] In a related embodiment, if the UE is served by the HPLMN, then for performance purposes, both the first identifier and the second identifier are hidden / encrypted by the same key (eg, the public key of the HPLMN).

[0940] In a related embodiment, if the UE is served by the HPLMN, the first identifier and the second identifier may be hidden / encrypted by two keys (e.g., two public keys) associated to the HPLMN, whereby the first key may be stored in the NF responsible for de-hiding the first hidden identifier (e.g., UDM), and the second key may be stored / used in the NF responsible for access and session management (e.g., AMF / SEAF).

[0941] In a related embodiment, if two different keys are used to hide the identifiers (e.g., SUCI and CHNIRI), common input parameters for the hiding process can be reused, e.g., for performance purposes. For example, if a nonce or counter (e.g., a time-based counter, such as a UTC-based counter) is used, the same nonce / counter can be used for both hiding / encryption processes.

[0942] In a related embodiment, HNI and RID may refer to HNI and RID, but may also refer to other parameters that may need to be received by the VPLMN and may pose a privacy risk.

[0943] In a related embodiment, the UE sends the concatenation of SUCI and CHNIRI to the network, specifically, to the VPLMN or HPLMN.

[0944] In a related embodiment, the NF in the VPLMN receives the concatenation of the SUCI and the CHNIRI, the VPLMN decrypts the HNI and RID from the CHNIRI, and routes the SUCI to the HPLMN indicated by the HNI.

[0945] In a related embodiment, the RAN of the (V / H)PLMN makes the public key of the (V / H)PLMN available to the UE. This may allow the UE to encrypt the HNI and RID, for example, the public key may be shared in the SIB, for example, as needed.

[0946] In a related embodiment, the RAN of the (V / H)PLMN makes the identifiers of the (V / H)PLMNs it supports available to the UE. This may allow the UE to select a suitable key (e.g., a public key) to encrypt the HNI and RID, wherein the key may have been (pre)configured and stored locally in the UE / USIM.

[0947] In a related embodiment, the HPLMN is responsible for configuring the UE with a public key for use when connecting to a different VPLMN. For example, if the HPLMN has an agreement with VPLMN1, the HPLMN (pre-)configures the UE with a public key to be used when served by VPLMN1, and provides the corresponding private key to VPLMN1.

[0948] This approach has the advantage that the key configuration in the UE is simplified since it depends on the HPLMN, but the VPLMN may have to perform multiple decryptions (blind decryptions) to determine the correct key.

[0949] In a related embodiment variant, the key may refer to an identity-based key, such that the identity of the serving network is used as the public key. This reduces the communication overhead of distributing / storing the public key in the UE.

[0950] In a related embodiment variation, a UE attempting to establish communications via a VPLMN / serving PLMN may send a temporary identifier (eg, a GUTI) such that neither the first (hidden) identifier nor the second (hidden) identifier needs to be exchanged.

[0951] In a related embodiment, the first identifier and / or the second identifier is protected (e.g., encrypted) such that the first protected (e.g., encrypted) identifier and / or the second protected (e.g., encrypted) identifier and / or the concatenation of the first identifier and the second identifier has a constant length. This is intended to reduce communication overhead while preventing an attacker from learning / guessing the first identifier or / and the second identifier.

[0952] In a related embodiment, the first identifier and / or the second identifier are protected (e.g., hidden / encrypted) such that the first identifier (e.g., SUCI) is hidden as described in TS 33.501, and then the second identifier (e.g., HNI, RID) is concatenated to the first hidden identifier and the whole is encrypted / hidden as described in the previous / following embodiments. This has the advantage of preventing an attacker from learning / guessing the first identifier and / or the second identifier.

[0953] In a related embodiment, the message including the identifier of the UE includes an implicit / explicit identifier indicating how to protect the first identifier and the second identifier. The implicit identifier can be based on a field present in the message or the message length. The explicit identifier can be based on an indication of whether the first identifier and / or the second identifier are protected.

[0954] In another embodiment variant, the UE may use a symmetric key derived from the UE's temporary key pair (i.e., the key pair used to derive the SUPI protection key) and the public key of the serving network (e.g., VPLMN), wherein the UE uses its temporary private key and the VPLMN public key to derive a temporary shared key, which (or a key derived therefrom) is used to encrypt / hide the HNI and RID. When received by a NF (e.g., AMF) in the serving network (e.g., VPLMN) (e.g., in a Registration Request or NAS Identity Response), a de-hiding function may be invoked to derive the temporary shared key from the UE's temporary public key (included in the SUCI) and the serving network's private key, and then use it (or a key derived therefrom) to decrypt / de-hide the HNI and RI. This has the advantage of reusing the same temporary key pair used to protect the SUPI to establish a symmetric key with the serving network, thereby ensuring that only the intended serving network obtains the HNI and RI.

[0955] In another embodiment variation, the UE may generate a second temporary key pair and use it to derive a symmetric key shared with the serving network (eg, VPLMN) and similar to the previous embodiment to protect the HNI and RID.

[0956] In another embodiment, the UE may employ any of the protection mechanisms described in the above embodiments when sending a registration request (e.g., when the UE sends a SUCI instead of a 5G-GUTI) and / or a NAS identity response (e.g., when the AMF sends a NAS identity request), and / or whenever the UE is required to transmit the HNI and RI to the serving network.

[0957] Generally, a method is proposed that may be implemented in a user equipment device adapted to perform the following operations:

[0958] - concealing the first identifier (e.g. SUPI) as a first concealed identifier (e.g. SUCI) by using a key associated to the HPLMN;

[0959] - Hiding the second identifier (eg, the home network identifier) ​​as a second hidden identifier by using a key associated to the VPLMN or the serving network.

[0960] - Sending the first hidden identifier and the second hidden identifier to the VPLMN or the service network through the access network.

[0961] The different embodiments and embodiment variations can be combined with one another as appropriate.

[0962] Embodiment 62

[0963] The potential privacy issues regarding HNI and RID described in the above embodiments may affect not only SUCI, but also AKMA key identifier (A-KID) having the format username@domain, where the username includes a routing indicator (RID) and an AKMA temporary ID (A-TID), and the domain includes the HNI. According to clause 6.2.1 in TS 33.535, the UE shall include the derived A-KID in the application session establishment request message sent to the AKMA application function. Therefore, the HNI and RID can be obtained by intercepting the application session establishment request message.

[0964] In an embodiment, the UE and the AF (e.g., such as a local AF in the same serving network, or an AF in the HPLMN, or an external AF in a data network) may establish / agree on a secret key at the application level to protect / encrypt the A-KID before sending the A-KID in an AKMA application session establishment request.

[0965] In a related embodiment, the secret key may be a symmetric key, or it may be a public / private key pair, where the public key is configured in the UE and the AF stores the private key.

[0966] In another embodiment, if the UE is roaming in a serving network (e.g., a VPLMN) and attempts to establish a session with an AF within the same network (e.g., a VPLMN), the UE may send a hidden / encrypted A-KID (e.g., using the public key of the VPLMN) together with the application function ID (AF_ID) to the serving network (e.g., the VPLMN), and have the VPLMN send / forward an AKMA session establishment request to the AF after de-hiding / decrypting the A-KID.

[0967] In another embodiment variation, if the UE is roaming in a serving network (e.g., a VPLMN) and attempts to establish a session with an AF within the same VPLMN, the UE may send the A-KID encrypted (e.g., using the VPLMN's public key) in an AKMA Session Establishment Request message to the AF, which then sends the A-KID to a NF in the serving network (e.g., SEAF) for decryption.

[0968] In another embodiment, if the UE is roaming in a serving network (e.g., a VPLMN) and attempts to establish a session with an AF within the HPLMN, the UE may send an A-KID hidden / encrypted (e.g., using the HPLMN's public key) in an AKMA Session Establishment Request message to the AF. The AF may then send the encrypted A-KID to a NF (e.g., AUSF) in the HPLMN, which decrypts the encrypted A-KID and sends it back to the AF. Alternatively, to obtain the K_AF, the AF may send its AF_ID along with the encrypted A-KID to the AUSF (instead of the AAnF), which decrypts the encrypted A-KID and forwards the AF_ID and A-KID to the AAnF determined by the RID, which may then derive the K_AF based on the AF_ID and K_AKMA linked to the A-KID and send it to the AF.

[0969] In another embodiment, if the UE is roaming in a serving network (e.g., VPLMN...

Claims

1. An apparatus for verifying a sensitive field sent to a second device, the apparatus comprising: a memory adapted to store information, and a transceiver adapted to send and receive messages, Wherein, the device is configured as follows: - sending a first message having the sensitive field to the second device, - receiving a verification challenge from the second device, - Computing a response based on the authentication challenge, key material shared between the first device and the second device and the sensitive fields exchanged in the first message and sending the response to the second device.

2. The device according to claim 1, wherein: The sensitive field is at least one of the following: The first device: - Security capabilities, -Device type.

3. A device according to any one of the preceding claims, wherein: The response is calculated as a cryptographic function of K and the sensitive fields.

4. A device according to any one of the preceding claims, wherein: The response is calculated as Challenge(K, R, SNname, sensitive fields).

5. A device according to any one of the preceding claims, wherein: The first message includes a field indicating that the response including the information requiring verification exchanged in the first message is to be calculated.

6. An apparatus for verifying a sensitive field received from a first device, the apparatus comprising: a memory adapted to store information, and a transceiver adapted to send and receive messages, Wherein, the device is configured as follows: receiving a first message having the sensitive field from the first device, receiving a response from the first device, and Whether the function of checking the response matches depends on the value of the sensitive field received in the first message.

7. The device according to claim 6, wherein: The apparatus determines the check to be performed based on a field included in the first message.

8. The device according to claim 6, wherein: The device checks whether the response matches a cryptographic function of K and UE security capabilities, for example, Challenge(K, R, SNname, UE security capabilities).

9. The device according to claim 8, wherein: If the previous check is invalid, the device checks whether the response matches a cryptographic function of K, for example, Challenge(K, R, SNname).

10. A system comprising at least a first communication device according to any one of claims 1-5 and at least one second device according to any one of claims 6-9.

11. A method for verifying a sensitive field sent to a second device, the method comprising: a. the first device sends a first message having information to the second device, b. receiving a verification challenge from the second device, c. Compute a response based on the authentication challenge, key material shared between the first and second devices, and the sensitive fields exchanged in the first message and send the response to the second device.

12. An apparatus for protecting a message using a second device, wherein: The apparatus is configured to perform the following steps: a) if the security context can be used and the configured policy allows the security context, retrieving the symmetric key; or If no security context is available or the configured policy requires the security context, generating a symmetric key and encrypting the generated symmetric key using a first public key bound to a private key owned by the second device, and b) sending a security message protected by the symmetric key and the protected symmetric key or an instruction for retrieving the symmetric key to the second device.

13. The device according to claim 12, wherein: The message is an initial registration request.

14. The device according to claim 13, wherein: The apparatus is configured to use the symmetric key to protect: - one or more private fields and a secret identifier; or - if the message comprises a pseudo-identifier of the secret identifier, one or more private fields.

15. The device according to claim 12, wherein: The message is a random access message.

16. The device according to claims 13-15, wherein: The private field includes at least one of the following: - Security capabilities, -Location, -User consent preferences, -Resume reason.

17. The device according to claims 14-16, wherein: One or more fields are shared with a third device (e.g., AMF).

18. The apparatus according to claims 12-17, comprising a receiver adapted to receive a protected message having at least one of the following: - a request to share the user's location, - confirmation of said security capabilities, -Confirmation of user consent preferences.

19. An apparatus for secure communication in a UE to network relay scenario, wherein: The device is suitable for: - storing a policy determining the behavior of the device when a direct security mode command is received; as well as - rejecting and / or accepting a received direct security mode command that is unprotected and / or includes a null encryption and integrity algorithm based on the policy, the policy including determining whether the device has previously sent a DCR message including an emergency RSC.

20. The device according to claim 19, wherein The device is adapted to accept a received direct security mode command that is unprotected and / or comprises a null encryption and integrity algorithm only if the device has previously sent a DCR message comprising an emergency RSC.

21. The device according to claim 20, wherein: The apparatus is adapted to reject a received direct security mode command that is unprotected and / or includes a null encryption and integrity algorithm if the apparatus has not previously sent a DCR message including an emergency RSC.

22. A method for secure communication in a UE to network relay scenario, wherein: Remote UE is suitable for: - storing a policy determining the UE's behavior when a direct security mode command is received; and - Rejecting and / or accepting a received direct security mode command that is unprotected and / or includes null encryption and integrity algorithms based on a policy that includes determining whether the device has previously sent a DCR message including an emergency RSC.

23. A method for lawful interception, wherein: - the second network function NF in the second network optionally signals a lawful interception requirement to the first NF in the first network, and - the second NF receives key material from the first NF, and - The second NF decrypts the intercepted traffic exchanged between the User Equipment UE and the Application Function AF based on the provided key material.

24. The method according to claim 23, wherein: The second NF receives key material from the first NF, wherein the second NF is responsible for collecting the AKMA key material for lawful interception purposes.

25. A method for lawful interception, wherein: - the first network function NF in the first network optionally receives signalling of a lawful interception requirement from a second NF in the second network, and - The first NF sends key material to the first NF, so that the second NF can decrypt the intercepted traffic exchanged between the user equipment UE and the application function AF based on the provided key material.

26. The method according to claim 25, wherein: The first NF provides key material to the second NF, wherein the second NF is responsible for collecting the AKMA key material for lawful interception purposes.

27. The method according to claims 25-26, wherein: The first network triggers a Home Network Triggered Primary Authentication (HONTRA) only upon receiving an acknowledgement from the second NF, the HONTRA may be located in the first network or the second network, the acknowledgement confirming that the key material has been successfully received.

28. The method according to claims 25-27, wherein: - The first NF receives a key request; - the first NF computes the requested key material and shares the key material with the second NF, - and upon confirming correct receipt of the key, the first NF shares the key material with the requesting entity.

29. The method according to claims 23-28, wherein: The second network is the same as the first network.

30. The method of claims 25-29, wherein - the first NF receives a key request and security parameters from a third NF (e.g., AF), -The first NF determines the key material and shares the key material and the security parameters with the second NF, so that the second NF can monitor or intercept or cache messages sent by the third NF to other entities (e.g., UE) and can use the messages to verify the validity of the received security parameters.

31. The method according to claims 23-24, wherein - the second NF receives the key material and security parameters from the first NF following a key request from a third entity, the key request being sent together with the security parameters, - The second NF monitors or intercepts or caches messages sent by the third NF to other entities (eg, UE), and uses the messages to verify the validity of the received security parameters.

32. The method according to claim 31, wherein: If the verification is successful, the second NF releases the message to the other entity.

33. A second network function NF device in a second network, comprising: - a transmitter for optionally signaling a lawful interception requirement to a first NF in the first network, and - a receiver adapted to receive key material from said first NF, and - A controller adapted to decrypt intercepted traffic exchanged between the User Equipment UE and the Application Function AF based on the provided key material.

34. A first network function NF device in a first network, comprising: - a receiver for receiving signalling of a lawful interception requirement from a second NF in a second network, and - A transmitter for sending key material to said first NF, so that said second NF can decrypt intercepted traffic exchanged between a User Equipment UE and an Application Function AF based on the provided key material.

35. A storage medium comprising code which, once loaded onto a computer, enables the computer to perform the steps of the method according to claims 22-32.

Images