How to join a communication network

Abstract

The present invention relates to an apparatus for verifying information transmitted to a second device, the apparatus including a memory for storing information and a transceiver for transmitting and receiving messages, the apparatus transmits a first message together with the information to the second device, the apparatus receives a verification challenge from the second device, and the apparatus calculates and transmits a response to the second device based on the verification challenge, 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, and in particular, but not exclusively, to a secure method for participating in and communicating in a communications network, such as a cellular network. [Background technology]

[0002] In a cellular network, a primary station serves multiple secondary stations located within the cell it serves. Wireless communication from the primary station to each secondary station occurs on a downlink channel. Conversely, wireless communication from each secondary station to the primary station occurs on an uplink channel. Wireless communication can include data traffic (also called user data) and control information (also called signaling). This control information typically includes information that assists the primary and / or secondary stations in exchanging data traffic (e.g., resource allocations / requests, physical transmission parameters, information about the status of each station).

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

[0004] Furthermore, direct communication can take place between secondary stations, here UEs, for example in the case of PC5 interface or sidelink communication. It is also then possible for the UE to act as a relay, allowing for example out-of-coverage UEs to obtain an intermediate (or indirect) connection to an eNB or gNB. To be able to act as a relay, the UE may use the discovery messages to establish new connections with other UEs.

[0005] The secondary station performs an initial authentication procedure with the core network to mutually authenticate and establish an initial security context. The core network also provides the means for the secondary station to establish a secure communication link with the application function. New access networks have also been designed and deployed that allow secondary stations to access the core network via non-terrestrial networks, either through the use of mobile primary stations or smart repeaters that extend the range of the primary stations.

[0006] Network access protocols may be vulnerable to man-in-the-middle or overshadowing attacks. A man-in-the-middle (MitM) attacker is an attacker that is located between the primary and secondary stations and can forward, modify, insert, or drop messages. In an overshadowing attack, the attacker inserts 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 features of the secondary station. The security features may include confidentiality or integrity algorithms supported by the UE or preferred by the UE (e.g., the New Radio Integrity Algorithm (NIA) or the New Radio Encryption Algorithm (NEA) in 5G). By modifying the preferred or supported security features, a MitM can trigger different types of attacks, such as SUPI catch attacks or IP spoofing attacks.

[0007] Based on the authentication and key agreement phase between the secondary station and the core network, a main key may be derived and stored in the network function (e.g., 5G AUSF) and the secondary station. Based on this key, further keys may be derived, for example, to serve applications. There are multiple challenges in the derivation and management of keys, for example (1) when the secondary station moves from LTE to a 5G network, (2) when an application uses an application key for a long time, or (3) when the secondary station is roaming. This last aspect also concerns, for example, lawful interception, because when the secondary station is roaming in a VPLMN, the VPLMN may want to obtain the decryption key for the communication between the AF and the secondary station regardless of the location of the AF (VPLMN, HPLMN, or external).

[0008] Furthermore, a 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 rough location. Indeed, in this example, the rough location of the secondary station may be needed, for example, to assign the correct AMF to the secondary station. Such parameter sharing may be done after a secure connection between the secondary station and the primary station has been established, to ensure that this information cannot be intercepted. Even if such location sharing can be done securely (protected by AS security), user consent may be required.

[0009] Secondary stations may also share certain identifiers over the air interface without protection. For example, the "priority access" values ​​exchanged in the initial random access procedure are not protected, i.e. the 5G standard allows the establishment reasons such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess" to be transmitted over the air in the clear. If this information is exposed in the clear, an attacker may be able to identify the UE's capabilities or communication capabilities, which may lead to privacy risks. Current solutions do not allow these fields to be protected.

[0010] Similarly, new RAN components such as mobile primary stations or network controlled repeaters (NCRs) are being developed in 3GPP. It is still unclear how such NCRs or mobile primary stations will be authenticated and authorized in the network when they connect to the network. Summary of the Invention

[0011] The object of the present invention is to provide a method that is resistant to these types of attacks.

[0012] Another object of the present invention is to provide enhanced security features (eg, supporting AKMA in roaming scenarios).

[0013] Another object of the present invention is to provide a communication device that is resistant to attacks, in particular to this type of MitM attack, and a communication system that is able to detect attackers in the network if such attacks are attempted.

[0014] Another object of the present invention is to strengthen the overall key agreement and derivation procedure.

[0015] Another object of the present invention is to provide enhanced security features (eg, user consent).

[0016] Another object of the present invention is to provide enhanced security features (eg, a means to authenticate or authorize NCRs).

[0017] Another object of the present invention is to provide enhanced security features (eg, protection of identities over the air interface).

[0018] The reason that an attack can be successful in certain scenarios is that the MitM can modify the message 110 to change parameters such as the preferred / supported security capabilities of the UE 100 (or the UE's location or device type) and give false instructions to the core network 104 (e.g., the use of the NIA0 and NEA0 integrity / encryption algorithms, which correspond to no integrity and no encryption).

[0019] Therefore, according to the current definition of the invention, it is described how this information, i.e. the security functions, can be protected, for example by including security functions in the authentication and key agreement phase 106 such that the authentication checks performed depend on the security parameters sent by the UE.

[0020] According to a first aspect of the invention, there is proposed an apparatus for verifying a sensitive field transmitted to a second device, the apparatus comprising: A memory for storing information; a transceiver for transmitting and receiving messages; The device is - sending the first message to the second device together with the secret field; receiving a verification challenge from the second device; - Compute and send to the second device a response based on the verification challenge, the keying material shared between the first device and the second device, and the secret fields exchanged in the first message.

[0021] According to a second aspect of the present invention, there is proposed an apparatus for verifying a sensitive field received from a first device, the apparatus comprising: A memory for storing information; A transceiver for transmitting and receiving messages, The device is receiving a first message from a first device with a confidential field; receiving a response from the first device; A function of the response is checked to see if it matches a value that depends on the sensitive field received in the first message.

[0022] According to a third aspect of the present invention, there is proposed a system comprising at least one 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.

[0023] According to a fourth aspect of the present invention, there is provided a method for verifying a sensitive field transmitted to a second device, the method comprising the steps of: a. a first device sending a first message with information to a second device; b. receiving a verification challenge from a second device; c. calculating and sending to the second device a response based on the verification challenge, the keying material shared between the first device and the second device, and the secret fields exchanged in the first message.

[0024] According to a fifth aspect of the present invention there is proposed an apparatus for securing messages with a second device, the apparatus comprising: a) Obtain a symmetric key if a security context is available and configured policies permit, or If the security context is not available or 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; (b) sending a secure message protected with the symmetric key and the protected symmetric key, or instructions to obtain the symmetric key, to the second device.

[0025] According to a sixth aspect of the present invention, an apparatus for secure communication in a UE to network relay scenario is proposed, the apparatus comprising: - storing a policy that determines the behavior of the device upon receiving a direct security mode command; - rejecting and / or accepting received direct security mode commands that are unprotected and / or include NULL encryption and integrity algorithms based on a policy, the policy including determining whether the device has previously sent a DCR message that includes an emergency RSC.

[0026] In a variation of the sixth aspect of the invention, a device accepts a received direct security mode command that is unprotected and / or includes a NULL encryption and integrity algorithm only if the device has previously sent a DCR message including an emergency RSC.

[0027] Additionally, a device may reject a received direct security mode command that is unprotected and / or includes a NULL encryption and integrity algorithm if the device has not previously sent a DCR message including an emergency RSC.

[0028] According to a seventh aspect of the present invention, a method for secure communication in a UE-to-network relay scenario is proposed, comprising: a remote UE comprising: - storing a policy determining the behavior of the UE upon receiving a direct security mode command; and - rejecting and / or accepting received Direct Security Mode commands that include unprotected and / or NULL encryption and integrity algorithms based on policy, including determining whether the device has previously sent a DCR message that includes an Emergency RSC.

[0029] According to an eighth aspect of the present invention, there is provided a method of lawful interception, comprising: - a second Network Function (NF) in the second network optionally notifying a first NF in the first network of lawful intercept requirements; - the second NF receives keying material from the first NF; - The second NF decrypts the intercepted traffic exchanged between the user device (UE) and the application function (AF) based on the provided keying material.

[0030] According to a ninth aspect of the present invention, there is provided a method of lawful interception, comprising: - a first Network Function (NF) in a first network optionally receiving a lawful intercept requirement from a second NF in a second network; - The first NF transmits keying material to the second NF so that the second NF can decrypt the intercepted traffic exchanged between the user device (UE) and the application function (AF) based on the provided keying material.

[0031] According to a tenth aspect of the present invention, a second network function (NF) in a second network is proposed, the second network function comprising: - a transmitter for optionally notifying a first NF in a first network of a lawful interception requirement; - a receiver for receiving keying material from a first NF; - a controller for decrypting intercepted traffic exchanged between a user device (UE) and an application function (AF) based on the provided keying material.

[0032] According to an eleventh aspect of the present invention, a first network function (NF) in a first network is proposed, the first network function comprising: - a receiver for receiving notification of a lawful intercept requirement from a second NF in a second network; - a transmitter that transmits keying material to the second NF so that the second NF can decrypt intercepted traffic exchanged between a user device (UE) and an application function (AF) based on the provided keying material.

[0033] Furthermore, the present invention can be implemented by software, and thus one aspect of the present invention includes a storage medium containing code that, when loaded into a computer, enables the computer to perform the steps of the various methods described herein.

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

[0035] These and other aspects of the invention will be elucidated and elucidated with reference to the embodiments described hereinafter. [Brief description of the drawings]

[0036] [Figure 1-2] 1 and 2 represent connection protocols used in conventional systems and are used to explain some embodiments. [Diagram 3] Figure 3 depicts an example of an attack scenario involving MitM. [Figure 4] FIG. 4 depicts an embodiment for updating Kaf. [Diagram 5] FIG. 5 depicts a further embodiment for updating Kaf. [Figure 6] FIG. 6 depicts an embodiment for addressing MitM. [Figure 7] FIG. 7 illustrates an embodiment for AKMA roaming. [Figure 8]FIG. 8 illustrates an additional embodiment for AKMA roaming. [Figure 9] FIG. 9 depicts an additional embodiment for secure access to NTN services. [Figure 10] FIG. 10 depicts an embodiment for establishing a shared key. [Figure 11] FIG. 11 illustrates an embodiment for AKMA roaming. [Figure 12] FIG. 12 illustrates an embodiment for secure access to NTN services. [Figure 13] FIG. 13 illustrates an embodiment for secure access to NTN services. [Figure 14] FIG. 14 depicts an embodiment for authentication and authorization of NCR. [Figure 15] FIG. 15 illustrates an embodiment for authentication and authorization of NCR with EAP-TLS. [Figure 16] Figure 16 shows the key hierarchy. [Figure 17] FIG. 17 depicts an embodiment for lawful interception. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] With reference to Figure 1, an example of a protocol including main phases for a terminal (e.g., UE) to join a communication network, such as a 5G communication network, including multiple entities, is described below. · 100 may be a user equipment in a communication system owned by a user who is trying to join the communication system. · 101 may be a base station in a communication system such as a 5GgNB. · 104 may be a core network of a communication system. · 102 may be a function that handles authentication of UEs in a communication system, such as an authentication and mobility function (AMF) of a 5G core network. · 103 may be a function for storing user data, such as a unified data management (UDM) function of the 5G core network. · 105 represents the overall communication system.

[0038] The arrows in the diagram represent the messages exchanged between these entities, as in this example: ·109 represents the initial connection setup, which may include multiple messages, for example an RRC connection request. ·110 represents an authentication request, for example an attach request or a registration request. · 111 refers to a request for some authentication value depending on the identification information provided in 110, for example a SUPI. · 112 indicates sending an authentication challenge. · 113 is an authentication request which may include input from 112 for example. 114 is an authentication response. · 106 includes messages 111-114 and represents the authentication and key agreement phase. 115 represents a message verifying the security parameters of the communication between 100 and 102 . · 116 represents a confirmation message indicating that the establishment of the communication security link between 100 and 102 is complete. · 117 represents a secured communication between 100 and 102. · 107 represents several messages (eg, 115, 116, 117) for establishing a secure link between 100 and 102 and for the subsequent secure message exchange. · 119 represents a message indicating that a secure link has been established between 100 and 101. · 120 represents a message indicating that the establishment of a secure link between 100 and 101 is complete. · 121 represents a secure exchange of messages between, for example, 100 and 101. · 108 represents a number of messages for establishing a secure link between 100 and 101 and for the subsequent secure message exchange. · 122 represents a message indicating that 100 has successfully joined 105.

[0039] Please note that Figure 1 is for illustrative purposes and some entities may be missing or included in others. For example, in 5G, the Security Anchor Function (SEAF) or Authentication Server Function (AUSF) plays an important role. The AMF and SEAF reside in the serving network, while the AUSF and UDM reside in the home network. The AMF interacts with the SEAF, the SEAF interacts with the AUSF, and the AUSF interacts with the UDM. The SEAF may reject the UE but relies on the UE's home network to accept the authentication.

[0040] One of the 3GPP authentication procedures is the 5G AKA authentication procedure, where, for example, the home network receives a challenge such as: xRES*=Challenge(K,R,SNname), and HXRES*=SHA256(R,xRES*) where K is a symmetric key, R is a nonce generated by the home network, and SNname is the serving network name. Furthermore, the home network obtains a MAC as f_1(K, SQN||RAND||AMF).

[0041] The home network then provides HXRES* to the serving network. In particular, the UDM / ARPF receives the AUTH token, the XRES token, and the key K. AUSF Note that 5G-AKA is initiated by sending an authentication response to the AUSF, which contains an authentication vector consisting of data such as the expected response token (HXRES), and, if applicable, the SUPI (e.g., if the corresponding authentication request contains a SUCI). The AUSF then calculates the hash of the expected response token (HXRES) and obtains the key K. AUSF, and sends an authentication response to the SEAF along with the AUTH token and HXRES. Note that the SUPI is not sent to the SEAF in this authentication response. The SUPI is sent to the SEAF only after the UE authentication is successful.

[0042] The UE side performs the same operation, checks the received MAC and calculates the response RES* as follows: RES*=Challenge(K,R,SNname) The UE then transmits the value RES* to the core network.

[0043] The serving network checks that SHA256(R,RES*) = HXRES* and rejects if they are not equal.

[0044] The home network checks if RES*=xRES* and rejects if they are not equal.

[0045] However, this kind of protocol can be vulnerable to man-in-the-middle or overshadowing attacks. A man-in-the-middle (MitM) attacker is an attacker who sits between 100 and 101 and can forward, modify, insert or drop messages. In an overshadowing attack, the attacker inserts a signal that modifies the message received by the receiver.

[0046] Several specific attacks that a MitM can perform have been described in the literature. The main feature of the attacks is that a MitM may be able to modify fields such as security features 100 of a message 110, as shown in Figure 1. This is illustrated by Figure 3, where 300, 301, 302, 303, 304, and 305 correspond to 100, 101, 102, 103, 104, and 105 in Figure 1. 306 represents a MitM. 309 corresponds to 109. 310, which corresponds to 110, is modified by the MitM creating message 311.

[0047] The security capabilities may include confidentiality or integrity algorithms supported by the UE or preferred by the UE (e.g., New Radio Integrity Algorithm (NIA) or New Radio Encryption Algorithm (NEA) in 5G).

[0048] By changing the preferred or supported security features, the MitM can trigger a SUPI catching, or IP spoofing attack, in which the MitM obtains the UE's 100 long-term identifier.

[0049] Based on the above authentication and key agreement phase 106, a main key (e.g., K_ausf) may be derived and stored in the network function (e.g., 5G AUSF). Based on this key, further keys may be derived, for example to provide services to applications. These keys may include 5G K_akma (stored in the AAnF and UE) or K_af (stored in the Application Function (AF) and the UE), as described in TS 33.535. As described in section 6.1 of TS 33.535, the AUSF derives K_akma and an AKMA key identifier (A-KID) from Kausf and deploys it 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 of TS 33.535 define how to derive Kakma, A-TID, and Kaf.

[0050] Based on the authentication and key agreement phase between the secondary station and the core network, a main key may be derived and stored in the network function (e.g., 5G AUSF) and the UE. Based on this key, further keys may be derived, for example to provide services to applications. These keys may include 5G K_akma (stored in the AAnF and UE) or K_af (stored in the Application Function (AF) and the UE), as described in TS33.535. As described in section 6.1 of TS33.535, the AUSF derives K_akma and AKMA Key Identifier (A-KID) from Kausf and deploys it to the AAnF. The A-KID includes the AKMA Temporary UE Identifier (A-TID), Home Network Identifier (HNI), and Routing Indicator (RID). Clauses A2, A3, and A4 of TS33.535 define how to derive Kakma, A-TID, and Kaf.

[0051] There are multiple challenges in deriving and managing keys that depend on K_ausf. For example, (1) when a UE moves from an LTE network to a 5G network, the LTE K_asme is mapped to the K_amf key so that both the UE and gNB and the UE and AMF can communicate securely, but K_ausf is missing, and therefore K_akma and K_af are also missing. Similarly, (2) if an application uses K_af for a long period of time, the key K_af may expire, but there is no way to update it. Finally, (3) the current AKMA architecture does not account for behavior in roaming. This last aspect also has implications for lawful interception, for example, because when a UE is roaming in a VPLMN, the VPLMN may want to derive the decryption key for the communication 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 accessing via a non-terrestrial network (NTN) may need to share its coarse location. Indeed, in this example, the coarse location of the UE may be needed, for example, to assign the correct AMF to the UE. Such parameter sharing may take place after a secure connection between the UE and the gNB has been established, to ensure that this information cannot be eavesdropped on. Even if such location sharing can be performed securely (protected by AS security), user consent may be required before the location information is actually shared, and the UE's location information may even help determine the user consent itself. Furthermore, the UE needs to receive the user consent preferences securely. However, current solutions do not meet such requirements.

[0052] UEs may also share certain identifiers over the air interface without protection. For example, the "priority access" values ​​exchanged in the initial random access procedure are not protected, i.e. the 5G standard allows establishment reasons such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess" to be transmitted over the air in the clear. If this information is exposed in the clear, an attacker may be able to identify the capabilities of the UE or its communication, which may lead to privacy risks. Current solutions are not able to protect these fields.

[0053] Similarly, a new component, the Network Controlled Repeater (NCR), is being developed in 3GPP. NCRs will be used to improve the coverage of gNBs by relaying / forwarding radio signals. It is still unclear how such NCRs will be authenticated and authorized in the network when connecting to the network.

[0054] EMBODIMENT 1 In a first embodiment, the security capabilities received from the UE in message 110 in the core network should be used in the authentication procedure between the core network and the UE, for example in messages 113 and 114. With particular reference to Figure 1, the security challenge xRES* or HXRES* may be calculated using input information provided in a previous message received from the UE (e.g., initial message 110, e.g., an initial attach or registration request sent by the UE). Examples of input information used include the security capabilities of the UE received by the core network (e.g., the serving network and / or the home network), for example: xRES*=Challenge(K,R,SNname,UE security_capabilities) HXRES*=SHA256(R,xRES*)

[0055] Other parameters that require protection or validation are parameters included in the attach or registration request, such as AN parameters in NG-RAN, registration type, SUCI or 5G-GUTI or PEI, last visited TAI (if available), security parameters, requested NSSAI, requested NSSAI mapping, default configured NSSAI index, 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 forces the use of null cipher and integrity algorithms. Other parameters that require protection could be context UE parameters such as location.

[0056] HXRES* may also be calculated to explicitly include the UE security_capabilities, but this is not required since the UE security_capabilities are implicitly included through xRES*. Similarly, the UE must obtain the response RES* in a similar manner, i.e. to include the UE security_capabilities included in the initial message.

[0057] In one example, RES*=Challenge(K, R, SNname, UE security_capabilities).

[0058] If this is done, the check performed by the serving network whether HXRES*=SHA256(R,xRES*) holds only if the UE security_capabilities have not been modified (by MitM). Furthermore, the check performed by the home network whether RES*=xRES* holds only if the UE security_capabilities have not been modified (by MitM).

[0059] Note that instead of having 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 generating one of the above challenges (e.g. xRES*=Challenge(K,R,SNname,info)), that information may be used together with one of the internal parameters (e.g. key K) to derive another internal parameter (e.g. K'). This may be done, for example, by applying a key derivation (KDF), e.g. K'=KDF(K,info). Then, using this new parameter K', the challenge / response can be derived as usual xRES*=Challenge(K',R,SNname). This note also applies to other embodiments.

[0060] The above calculations refer to Section 6.1.1.3 of TS33.501.

[0061] As a further note, the generation of the above parameter xRES* including UE security_capabilites may require the exchange of the UE security_capabilites 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), as well as the sending of said UE security_capabilities from the AUSF to the UDM in a Nudm_UEAuthenticate_Get request message, so that the UDM can perform the above calculations.

[0062] EMBODIMENT 2 In another embodiment, the UE security capabilities may be included in the home network MAC. Thus, instead of calculating the MAC as f_1(K,SQN||RAND||AMF), the home network may perform the calculation as MAC=f_1(K,SQN||RAND||AMF||UE_SC_F), where UE_SC_F refers to the UE security_capabilities, or generally speaking, the information that needs to be verified.

[0063] This may be performed before sending message 113 in Figure 1. On the UE side, upon receiving message 113, after the USIM has obtained the SQN, the UE can calculate the XMAC in the same way (i.e. using the parameters that need to be verified as input) and compare it with the received MAC.

[0064] EMBODIMENT 3 Introducing a new type of check (as in other embodiments), a situation may arise where the communication system has to distinguish between legacy UEs that do not support the extended authentication procedure and new UEs that do support the extended authentication procedure. It is conceivable that the home network hosting the new UE is the new home network, i.e. it supports the new authentication method even though it may still host legacy UEs. However, the new UE may interact with the new home network via the legacy service network.

[0065] To address this, in an alternative to the first embodiment, the new UE may send in the initial message 110 a recommended authentication method, e.g. an authentication method outlined in another embodiment. This may be signaled by a message field indicating the protocol version. One bit may be sufficient. For a new UE, the home network and the UE may use a solution such as the other embodiments (e.g. embodiment 1.2).

[0066] To address this, in a second alternative, legacy and new UEs may always send identical initial messages 110, i.e. without indicating the protocol version. In this case, the serving network may check (as is done currently): HXRES*=SHA256(R,xRES*)

[0067] Note that security feature checks are already implicit in xRES*, so no changes need to be made in legacy service networks. The home network may first check: RES*=Challenge(K,R,SNname,UE security_capabilities), If this check fails, the following can be checked: RES*=Challenge(K,R,SNname)

[0068] The advantage of this procedure, which does not include the protocol version, is that an attacker does not know which UEs are legacy and which are new, and therefore cannot launch targeted attacks.

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

[0070] EMBODIMENT 4 Clause 6.7.2 of TS33.501 describes possible implementations of messages 115 and 116 with reference to Figure 1. These messages protect the registration request against man-in-the-middle attacks where an attacker modifies the IEs containing the UE security capabilities offered by the UE in the registration request. However, if the MitM configures the IEs containing the security capabilities to contain null integrity / confidentiality, messages 115 and 116 according to clause 6.7.2 of TS33.501, i.e. NAS Security Mode Command and NAS Security Mode Complete, may not apply integrity / confidentiality protection.

[0071] 1, messages 115 and / or 116 are integrity and / or confidentiality protected even if the network (e.g., 102) selects a null integrity and / or null confidentiality setting. These messages are protected by keys derived from a previous authentication step (messages 113 and 114).

[0072] EMBODIMENT 5 In one variation of the above attack, a man-in-the-middle attacker controlling a malicious gNB and a malicious UE may intercept a registration message (e.g., registration request) sent from a victim UE to a legitimate network (e.g., AMF) and modify the message to indicate that the registration is for emergency services (i.e., edit the registration type field to correspond to an emergency registration) and, optionally, to include only null encryption and null integrity algorithms in the security features (i.e., NEA0 and NIA0) or set the null integrity algorithm to the highest priority. The modified registration request is sent by the attacker to the legitimate network. The network may allow or deny the emergency registration request based on a configured policy according to clause 10.2.2.2 of TS33.501. The serving network may also allow or deny an unauthenticated UE to establish bearers for an unauthenticated IMS emergency session, and the AMF may attempt to authenticate the UE after receiving the emergency registration request.

[0073] If the serving network policy allows unauthenticated IMS emergency services and the AMF tries to authenticate the UE, the MitM may forward the NAS_authentication_request to the victim UE, which performs the necessary checks, derives a secret key (e.g., K_AUSF), calculates RES, and sends it to the AMF in a NAS_authentication_response. A MitM attacker may intercept the NAS_authentication_response and change it to AUTHENTICATION FAILURE to trick / force the AMF to use the NULL security algorithm. According to clause 10.2.2.2 of TS33.501, if the serving network policy allows unauthenticated IMS emergency sessions, the AMF may send a NAS SMC with a NULL security algorithm to the UE, regardless of the pre-announced algorithms (e.g., announced in the security capabilities) that the UE supports, in the following cases: - The AMF is unable to identify the subscriber or is unable to obtain an authentication vector (if a SUPI is provided). - UE verification failure. - AMF receives an emergency registration request and an AUTHENTICATION FAILURE message containing an error code as defined in clause 5.4.1.2.4.5 or 5.4.1.3.7 of 24.501.

[0074] A MitM attacker may exploit the last case to trigger a NULL security algorithm selected by the AMF. Following the selection of the NULL encryption / integrity algorithm, as described in TS33.501 clause 6.7.2, a NAS SMC message may be sent unprotected to the victim UE to indicate that a NULL integrity and encryption algorithm has been selected. According to TS33.501 clause 10.2.1.3, notes 1 and 2, the AMF may assume that the UE is ready and that the UE accepts that the SMC procedure will select a NULL integrity and encryption algorithm. Thus, a MitM may trick the victim UE and the AMF into performing a null encryption and integrity algorithm, allowing it to perform a SUPI catch attack and / or an IP spoofing attack.

[0075] Another scenario where a similar MitM attack may work is related to 5G Prose, where a remote UE may try to connect to the network via UE-to-Network (U2N). In case of emergency services via U2N relay, if unauthenticated emergency services are allowed by network policy and the UE (e.g. without USIM) is not authenticated and not allowed to use ProSe U2N relay services, UP traffic may be sent via PC5 link without security protection or with limited integrity protection. For example, the process based on the procedure described in TS33.503 is as follows: After UE-to-Network (U2N) relay discovery, the remote UE sends a DCR message containing emergency RSC and optionally PRUK ID, SUCI, or PEI to the U2N relay. If the CN receives PRUK ID / SUCI in the message forwarded by the U2N relay, the U2N relay may perform UP or CP security procedures according to TS33.503. If only PEI and emergency RSC are received, the U2N relay may skip this procedure if allowed by regulatory / operator policy. If the security procedures of the previous steps are completed, the U2N relay executes a direct security mode command according to TS33.503; otherwise, it sends a direct security mode command with null encryption and integrity protection. If the authentication fails and no PEI was sent by the remote UE in the DCR message, the U2N relay may send a remote ID request to obtain the PEI. Thus, a MitM attacker posing as a (malicious) U2N relay may intercept the victim UE's messages (e.g., direct communication request (DCR)) and, for example, add an emergency RSC and / or include a (fake) identity (e.g., PEI). If the identifier is not included, a remote ID request may be sent to the victim remote UE to obtain it at a later stage.The U2N relay may be forced to skip the UP or CP based security procedures (e.g., the MitM forces it to fail), resulting in a direct security mode command procedure with null encryption and integrity protection. Upon receiving a direct security mode command message with a null security algorithm, the victim remote UE may treat it as not having UP integrity protection enabled for that connection and include the UP integrity protection policy as NOT NEEDED in the direct security mode completion. If not, the MitM attacker may intercept the direct security mode completion message and modify it to include the same indication (i.e., UP integrity not required). Finally, the U2N relay sends a direct communication acknowledgement message to the victim remote UE via the MitM controlled U2N, thus completing the PC5 connection establishment procedure for emergency services. At this stage, a SUPI catch attack may be performed by the MiTM attacker.

[0076] In another variation of the 5G ProSe MitM attack scenario, the process based on the procedures described in TS33.503 and TS33.536 can be described as follows: After the detection of the UE-to-Network (U2N) relay, the remote UE sends a DCR message to the U2N relay, which may contain one or more of the following: emergency RSC, PRUK ID, SUCI, or PEI, security capabilities of the remote UE, and / or signaling security policy. The U2N relay can forward these parameters to the CN. If the CN receives the PRUK ID or SUCI in the message forwarded by the U2N relay, the U2N relay may perform the UP or CP security procedures according to TS33.503. If only the PEI and emergency RSC are received, the U2N relay can skip this procedure if allowed by regulatory / operator policy. If the UE's security capabilities and signaling security policy are also included in the DCR, the U2N can perform direct authentication and key establishment procedures based on TS33.536. In such a case, a MitM attacker posing as a (malicious) U2N relay may intercept the victim UE's messages (e.g., Direct Communication Request (DCR)). If the UE's signaling security policy is set to "NOT NEEDED" or "PREFERRED", the MitM attacker may modify the DCR message, e.g., to add an emergency RSC and optionally include (fake) identifying information (e.g., PEI), and set the signaling security policy to "NOT NEEDED" (if not already). If the U2N relay signaling security policy is set to "NOT NEEDED" or "PREFERRED", it may be forced to select the NULL encryption and integrity security algorithms as Chosen_algs in the direct security mode command message. The legitimate U2N returns a direct security mode command message to the remote UE, including the NULL security algorithms, the remote UE's security capabilities, and the signaling security policy.A MitM attacker may intercept the direct security mode command message and change the signaling security policy back to "PREFERRED" if it had previously changed it to "NOT NEEDED" in the DCR message. This ensures that the MitM attack is not exposed when the victim remote UE validates the returned security capabilities and signaling security policy as mandated in step 4 of subclause 5.3.3.1.4.3, Figure 5.3.3.1.4.3.-1. Therefore, upon receiving a direct security mode command message possibly modified by a MitM attacker, the victim remote UE may accept the NULL security algorithm and send an unprotected direct security mode completion message. Finally, the U2N relay sends a direct communication accept message to the victim remote UE via the MitM-controlled U2N, finishing the PC5 connection establishment procedure for emergency services.

[0077] Once a PC5 connection is established between a victim remote UE and a U2N relay with a MitM attacker in the middle, the attacker can perform an attack (e.g., a SUPI catch attack).

[0078] In an embodiment aimed at mitigating attacks, a variation utilizes a registration type field in the registration request indicating the type (e.g., emergency). The registration type may be used by the AMF and may be included in the NAS_authentication_request when the registration request is received (or may be forwarded by the AMF to the home network and included in the NAS_authentication_request). Similar to including UE_security_capabilities in each of the above embodiments, the registration type may be securely sent back to the UE for verification, thereby exposing any changes that the MitM may have made to the registration type. If the UE calculates an XMAC with the registration type used in the registration request and verifies it against the MAC received in the NAS_authentication_request, the verification will fail if the registration type has been changed (e.g., by a MiTM attacker) and the UE will consider the authentication to have failed. A failed authentication procedure from the (victim) UE side may involve the network potentially sending a NAS SMC message with a NULL security algorithm, but the UE rejecting or ignoring it as it is not expecting such a NAS SMC message.

[0079] An advantage of the above solution may be that it prevents all attacks that rely on forging emergency requests to trigger and exploit IMS emergency service scenarios. Furthermore, this solution, in combination with the solutions proposed in other embodiments, may ensure that any changes to the registration type and / or security capabilities of the UE result in an authentication failure on the UE side, thus stopping the attacks.

[0080] In a further embodiment, the UE may be configured to reject NAS SMC messages indicating NULL encryption and integrity algorithms unless the UE requests emergency services, which may be configured through policies managed by the network (e.g., HPLMN) and provisioned to the UE, for example, if the network supports unauthenticated IMS emergency services.

[0081] 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 of support for unauthenticated IMS emergency services. The UE may reject a NAS SMC message indicating NULL encryption and integrity algorithms based on this indicator if the UE is not requesting emergency services.

[0082] In another embodiment addressing potential MitM attacks in 5G Prose scenarios, the remote UE may be configured (e.g., via a provisioned policy or indicator) to discard messages with null encryption and integrity protection (e.g., direct security mode command messages) unless the remote UE is actually requesting emergency services. The policy or indicator may be provisioned to the remote UE, for example, when the remote UE is in coverage range and has been provisioned with detection security material for open or restricted detection, for example, according to step 0b of TS33.503, subclause 6.3.3.2.1, Figure 6.3.3.2.2-1. Alternatively, the policy or rule may be provisioned through the ProSe User Key Response, according to step 1b of the same figure. In either case, the NF, such as the PCF, or the PKMF of the remote UE may manage and / or decide whether the remote UE accepts or rejects the null encryption and integrity protection.

[0083] In another related embodiment, a policy configured / implemented in the remote UE may determine that if the remote UE is not requesting emergency services and the U2N relay requests to obtain the UE's PEI, the remote UE will not disclose its own PEI (particularly if the request is not protected and therefore cannot be verified by the remote UE).

[0084] 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., if 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 to reject unprotected direct security mode command messages that include an emergency RSC while the remote UE is not requesting emergency services.

[0085] Another scenario related to MitM attacks in 5G ProSe scenarios could force the U2N relay to send an unprotected Direct Security Mode command. In this scenario, if the remote UE receives an unprotected Direct Security Mode command, it may accept the message according to Sol#27 of TR33.740. However, this should only happen if the remote UE has requested emergency services, i.e. if the remote UE has sent an emergency RSC within the initial DCR message. If the remote UE does not behave in this way, this would interfere with the PC5 security establishment for 5G ProSe UE-to-Network relay communication over the user plane, as defined for example in clause 6.3.3.2.2 of TS33.503.

[0086] Thus, 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 to accept an unprotected direct security mode command and / or use of a NULL integrity algorithm only if the remote UE has previously requested emergency services (e.g., by sending a DCR message with an emergency RSC). The policy may be configured by the network operator via a network function (e.g., PCF) in the core network of the communication system (e.g., 5GS).

[0087] Thus, 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 to accept the use of the NULL integrity algorithm, but only if it receives such a setting in a protected direct security mode command and the verification is successful. The policy may be configured by the network operator via a network function (e.g., PCF) in the core network of the communication system (e.g., 5GS).

[0088] Accordingly, an apparatus and method for secure communication in a UE-to-Network relay scenario are proposed, which may be implemented in a user equipment, the apparatus comprising: Stores hard-coded / pre-configured policies that determine how the device behaves when it receives a direct security mode command; · Reject / accept received Direct Security Mode commands that contain unprotected and / or NULL encryption and integrity algorithms based on policy and whether the device has previously sent a DCR message containing an Emergency RSC.

[0089] In case of emergency services via U2N relay, if the UE does not have a USIM or is not authenticated and authorized to use ProSe U2N relay services (e.g., if MitM interferes with the authentication process), UP traffic may be sent without protection or with limited integrity protection (or may be requested to send without / with limited protection). For example, to provide limited protection due to data loss due to unintended unstable radio conditions, a MAC-I may be generated using input parameters such as a 32-bit COUNT, a 5-bit bearer ID, a 1-bit transmission direction, and a known 128-bit integrity KEY (e.g., set to all zeros). Since a MitM attacker may forge such a MAC-I, the policy configured in the UE may further determine that the UE cannot use such a configuration if the UE is not requesting emergency services, and thus reject messages with limited protection.

[0090] EMBODIMENT 6 In solutions for emergency access via UE-to-Network Relay (e.g. solution #27 in TR33.740), the DCR message may contain parameters such as the Persistent Identifier (PEI). Even in the case of emergency access, it is advantageous if the PEI is also protected (encrypted / integrity protected). The protection may be performed in a similar way as in clause 6.3.5 of TS33.503, where the PEI is protected next to the RSC or PRUK ID.

[0091] EMBODIMENT 7 In one potential attack, an attacker may be able to violate the privacy of the Subscriber Concealed Identifier (SUCI) by correlating the IMSI (e.g., obtained from a 4G Attach Request using a 4G IMSI-Catcher) with the SUCI (e.g., obtained from a 5G Registration Request or NAS Authentication Response). This attack may work under certain conditions, and can be described as follows: Step 1: When a UE attempts to connect to a legitimate 4G network (e.g., via an attach request), an attacker may intercept the UE's IMSI (e.g., using a 4G IMSI-Catcher). Step 2: The legitimate network may respond to the UE with an authentication request containing valid AUTN and RAND values, which may be captured by the attacker. Step 3: The attacker uses a fake 5G-SA network (e.g., one using a fake gNB) to which the victim UE attempts to connect. Step 4: Upon receiving the registration request from the victim UE, if the SUCI is not included, the attacker sends a NAS ID request (e.g., via the fake gNB), to which the victim UE responds with a NAS ID response that includes the concealed SUPI (i.e., SUCI). Step 5: The attacker reuses the captured RAND and AUTN from the legitimate 4G authentication request captured in step 2 in a crafted 5G NAS authentication request.

[0092] Based on the UE's response to the authentication request, it may be possible to know whether the SUCI corresponds to the IMSI captured in step 1 (e.g., based on a SUCI catcher attack).

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

[0094] This attack may work under the following assumptions and / or conditions: - The IMSI of the UE is already known to the attacker - The attack needs to happen within a short time frame, i.e. it is necessary to capture a legitimate 4G authentication request and replay it as a 5G authentication request so that the sequence number (SQN) in the AUTN is fresh and not rejected by the victim UE.

[0095] The subject of the following embodiments is to address the above potential attacks.

[0096] In one embodiment, the UE may include a freshness parameter / challenge (e.g., a nonce or a time-based counter, e.g., a UTC value) in the registration request, which is included by the network in the NAS authentication request (e.g., similar to UE_security_capabilities in other embodiments).

[0097] In another embodiment, the 5G home network may add a parameter / indication (e.g., “5G”) to the parameters used to derive the MAC. The parameter / indication represents the handshake the UE is about to perform. Thus, instead of calculating the MAC as MAC=f_1(K,SQN||RAND||AMF), the home network may perform the calculation as MAC=f_1(K,SQN||RAND||AMF||“5G”).

[0098] Parameters or indications other than "5G" may also be used to indicate the handshake that the UE is attempting to perform.

[0099] In another embodiment, which may be combined with other embodiments, since the attack depends on the freshness of the intercepted (4G) authentication request and is time-critical (i.e. it is necessary to ensure that the freshness check of the SQN in the USIM is successful), a stricter limit L (as described in TS 33.102, subclause C.2.2) on the difference between SEQ_MS and the received sequence number component SQN may be configured in the UE when it transitions from a 4G to a 5G SA network.

[0100] EMBODIMENT 8 In some situations, non-3GPP compliant devices may connect to the radio access network. These devices do not support all the required features defined in 3GPP RAN. This is problematic because non-compliant devices may interact with compliant devices and affect the overall performance of the RAN, for example if the non-compliant device does not fully comply with the timing of the frequency range.

[0101] The following embodiments aim to address this problem.

[0102] In one embodiment, the device type is included in the UE capabilities and is verified similarly to other embodiments of this application.

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

[0104] 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 obtain the UE capabilities (which may include, for example, the device type) from the AUSF / UDM. The UE may: - the UE capabilities reported (by the UE) (including, for example, device type) and the UE capabilities obtained (from the AUSF / UDM) match, and / or If the UE capabilities (device type) are compliant with 3GPP (registered trademark), (H / V) May participate in PLMN and / or RAN.

[0105] In another embodiment, the compliance status of the device may be verified and / or checked against a compliance ledger owned, operated, and maintained by the 3GPP® organization and members. The ledger may include one or more records of the following: UE type, including e.g. device name, ID, manufacturer ID, chipset ID, firmware version, firmware digest, certificates, status, UE (generic) capabilities, etc. Manufacturer / vendor, including e.g. ID, company name, brand name, URL, certificates, etc. Trusted Certificate Authorities, including, for example, their ID, authority name, root certificate, status, etc.

[0106] The compliance ledger could be a blockchain, or a transparency tree like RFC9162, or simply a trusted central repository.

[0107] The compliance ledger may allow authorized write access and may only be written to by approved manufacturers and / or vendors. Thus, when a vendor releases a new device, an entry containing all the information about that device is written to the compliance ledger.

[0108] When a new device type is added, the device's status may initially be set to none. The status may be updated to compliant or non-compliant based on the reported results of conformance testing performed by a trusted independent test lab or operational network. Future ongoing evaluation / testing of the device's compliance by a trusted test lab and / or network may result in an update to the device's compliance status (e.g., from compliant to non-compliant). The update to the compliance status may include a condition specifying that the device type is not compliant with public validation.

[0109] The manufacturer / vendor may be issued a certificate from a trusted certificate authority and use it to issue a certificate for the UE. The certificate trust chain may be verified upon access registration of the UE, e.g., during the initial registration and / or initial authentication procedures. For example, the base station (or NF in the V / HPLMN) may send a challenge, e.g., including a nonce, to the UE, e.g., in an RRC connection setup. The UE may sign the challenge (e.g., a nonce) and include its own ID, the manufacturer's ID, the nonce, and the signature in a response message (e.g., an RRC setup complete / registration request that is verified by the base station and / or AMF). Using the UE and its manufacturer's ID, a certificate is retrieved from the compliance ledger and used to verify the UE's signature and trust chain, thereby confirming the authenticity of the UE's origin. The compliance of the UE may be indicated by a compliance status associated with the UE's ID in the compliance ledger.

[0110] In a related embodiment, the challenge may include a request for additional parameters, such as a fingerprint of (part of) the firmware. A trusted entity within the device (under test) may be responsible for computing such fingerprints and signatures to ensure that the device is properly attested (e.g., the device is not dependent on a third party to obtain the results).

[0111] In a related embodiment, a compliance check is performed first, and if the compliance status of the UE (of the UE / of the device type to which the UE belongs) in the compliance ledger indicates that it is non-compliant, the network may decide to stop the connection. If the UE is compliant (or belongs to a compliant device type), the network may further check the UE's signature and trust chain to establish the authenticity of the UE's origin.

[0112] In a related embodiment, the UE may not sign anything in response to a challenge from the gNB (generally the testing device). The reason is that signing may create a potential privacy risk 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 nonce) and the device capabilities (e.g., firmware) (e.g., HMAC(nonce, Hash(Firmware(pages_x_y))). In this regard, the testing device may have sent a challenge “(nonce, pages_x_y)” requesting the device to return an HMAC() of a hash of the (device's) firmware in memory page x_y using the received nonce as the HMAC key.

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

[0114] In a related embodiment, the UE may perform the following: - First, it publishes / communicates its device type so that the network can decide whether to enable or disable access based on the device type (e.g. based on local policy, information in the ledger, etc.). - Then, establish a secure channel with the network. - Third, it performs a device authentication phase together with the network, allowing the network to verify that the UE is the device type advertised in the first step.

[0115] In a related embodiment, when a device (UE) is subject to verification / authentication, parameters (e.g., public / private key pair) assigned to the device for verification / authentication may be rotated / changed / updated to avoid privacy issues.

[0116] In a related embodiment, a device (UE) may be verified / certified only if the UE and the gNB share a secret channel to securely exchange parameters such as a challenge or challenge response.

[0117] In a related embodiment, the device (e.g., UE) and the access device (e.g., gNB) may agree on a shared key using a key exchange protocol (e.g., Diffie-Hellman). The shared key may then be used, for example, as an HMAC key or to derive other keys (e.g., keys for encryption or MIC). For example, the access device (e.g., gNB) may broadcast a randomly generated challenge (e.g., a nonce) along with its ID as part of a SIB message, and the device (e.g., UE) may decrypt the contents of the SIB message and use the ID of the access device to determine the public key associated with it. For example, if the UE has locally stored a record obtained from a ledger and containing information related to the access device (e.g., gNB), the UE may use the gNB's public key along with its private key to derive a shared symmetric key K. K may then be used to derive (e.g., by a key derivation function) 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 can identify the UE's public key from the ledger and use it as well (i.e., together with the private key to derive the shared symmetric key K) to derive the keys (e.g., HMAC, and / or MIC, and / or encryption keys) necessary to verify the validity of the UE's response and the origin and compliance of the UE.

[0118] In a related embodiment, the network may start by checking the UE's signature and trust chain. If one check fails, the network may respond with an error message (e.g., incorrect signature) and a new challenge (e.g., a nonce) to be used in subsequent UE attempts. The network may define a limit to the number of attempts (e.g., three) that the UE may use to establish the authenticity of its origin. If all attempts fail, the network may drop the connection and set a cooldown period to prevent the UE from trying to establish the connection again. The network may not rely solely on the information reported by the UE, e.g., the UE's ID and manufacturer ID, to prevent the UE from trying to establish a connection, since these IDs are public and can be used by any UE, e.g., to perform a DoS attack. If the UE's signature and trust chain are verified, the network may check the UE's compliance status and proceed with the primary authentication if compliant, or drop the connection if not.

[0119] In a related embodiment, the authentication procedure may be part of an authentication procedure, such as, for example, a primary authentication procedure between the UE and the home network.

[0120] In related embodiments, if messages exchanged between the UE and the base station support larger sizes of data, the UE origin authenticity and compliance checks may be performed at an earlier stage (e.g., in the initial / random access procedure). In such a scenario, the base station may broadcast a nonce as part of SIB1. Once the UE selects the SSB and extracts the MIB and SIB1 data, the UE may sign the nonce and include its own ID, manufacturer's ID, and signature in the random access procedure message 1. The gNB may obtain information related to the UE and its manufacturer and perform the necessary checks to establish its origin authenticity and compliance as described in the above embodiments. Based on the results of these checks and the connection attempt, the gNB may send a failure message including a new nonce, disconnect the connection, or return a positive response within the random access response (i.e., random access procedure message 2). Once the RRC connection setup is complete, the gNB informs the AMF that the origin and compliance checks have been successfully performed.

[0121] 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: - Determining UE type / ID, - Performing UE attestation.

[0122] In allowing a UE to access a network and / or certain functions within the network, for example, the UE may be allowed to use certain services (e.g., a mobile base station, a RIS, or a smart repeater) only if it is verified that the UE can properly handle those services.

[0123] In a related embodiment, the UE may be required to communicate its device type / ID and / or undergo device certification if required by the network.

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

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

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

[0127] Generally, or in the specific embodiment being mentioned, validation and / or verification of the certificate trust chain may refer to and / or include, but is not limited to, the process of verifying the validity period of an entity's (e.g., base station) certificate (e.g., Certificate_A) and the signature of the authority (e.g., operator) that issued and signed Certificate_A, and the process may be repeated recursively (i.e., verifying the validity period of the authority's (e.g., operator) certificate (e.g., Certificate_B) and the signature of the superior authority (e.g., trusted certificate authority) that issued and signed Certificate_B) until a trusted certificate authority is reached, i.e., the authenticity and trustworthiness of the entity is established.

[0128] In another embodiment, validation may refer to and / or include one or more of the following: - Compliance check: The compliance status corresponding to the identity of the device (e.g. UE) is checked against the ledger records. Firmware version check: A device (e.g., UE) may check the ledger to see if a firmware update is available that corresponds to the device model.

[0129] According to the above embodiment, a method is proposed for an entity (e.g., an access device (e.g., a base station) or an NF) belonging to a network (e.g., a serving network or a home network) to check and verify one or more of the authenticity, origin, and compliance of a user equipment (UE) that may be trying to access the network based on records in a ledger. The method may be implemented on a verifier (e.g., a base station) and may include verifying security information (e.g., signatures, digests, certificates, trust chains) and performing checks (e.g., compliance status checks, firmware update checks) for the user equipment (UE) based on data records stored in the ledger. The verification may be performed by the verifier (e.g., a base station) itself or with the assistance of an NF (e.g., an AMF) in the network.

[0130] The method may rely on different processes to obtain security and / or identification information, for example, as described below, the processes may be performed as in other embodiments. The access device (e.g., base station) sends a randomly generated challenge (e.g., a nonce and a specific firmware page) as part of a SIB message. The UE signs the challenge and / or computes a function (e.g. a cryptographic hash) of the firmware pages using the nonce as key (e.g. HMAC(nonce,Hash(Firmware(pages))))) and adds the required parameters (e.g. ID, chipset ID, firmware version) to the random access procedure message (e.g. message 1) or registration request to perform the necessary checks and verifications.

[0131] An access device (e.g., a base station) or an NF (e.g., an AMF) receives a message including security information and identity information from the UE and performs checks and verifications as described in the above embodiments.

[0132] Embodiment 9: If the message 110 is exchanged in a protected (integrity protected) state, the attack is not feasible since a MitM between the UE 100 and the base station 101 cannot modify the message. However, at this stage the UE 100 and the CN 104 do not share an integrity key, so the message 110 cannot be integrity protected. This can be solved 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. This symmetric key K is then securely transmitted to the core network 104, e.g. in a message 110, and used to integrity protect the message 110 or certain fields (e.g. UE security capabilities) in the message 110. The integrity protection is specifically performed by appending a Message Integrity Code (MIC), which is calculated as MIC(K, message_fields_requiring_integrity_protection).

[0133] When the core network receives the message 110, it first decrypts the key K using the private key that corresponds to the encrypted public key, and then checks the received MIC against a MIC calculated locally using the decrypted key and the received fields in the received message 110.

[0134] Note that the public key is linked to a private key owned by the home (serving) network, which may then inform the serving (home) network about the verification failure.

[0135] Also note that if SUPI and K are not, for example, encrypted together, the MitM could still "replace" the encrypted key with another key K' that the attacker desires and include a MIC calculated with K' and modified message fields. To avoid this situation, key K may be placed next to fields that require verification or are used in subsequent authentication procedures (e.g., SUPI), and both key K and such fields may be encrypted and / or integrity protected together. In that case, when SUPI is decrypted / verified, key K is also decrypted / verified. If an attacker were to interfere and try to replace the combined encryption of SUPI and K, it would fail because the attacker does not know SUPI. Ideally, this public key encryption procedure provides strong guarantees against chosen ciphertext attacks (CCA).

[0136] It is also beneficial if the key is encrypted next to a parameter that prevents replay attacks, such as a nonce or a time-based counter (e.g. a UTC value), otherwise an attacker may be able to replay previous messages where, for example, a message field favorable to the attacker (e.g. a weak choice of UE security_capabilities) was used.

[0137] Note that this embodiment may require an exchange of UE security_capabilites, which the AMF receives in the initial UE message NAS-PDU (registration request in a Nausf_UEAuthenticate_authenticate request sent from the AMF to the AUSF and containing the SUCI, to enable the AUSF to verify the integrity check if the UDM returns an integrity key to the AUSF).

[0138] Additionally or alternatively, it may be necessary to send said UE security_capabilities from the AUSF to the UDM in a Nudm_UEAuthenticate_Get request message so that the UDM can perform said integrity verification.

[0139] Additionally or alternatively, it may be required to send key K to the AMF that received the UE security capability so that the AMF can perform the above integrity verification.

[0140] Note that this embodiment may require the UE to determine the key K and calculate a MIC on the UE security_capabilities field exchanged between the UE and the AMF (e.g. in the initial UE message NAS-PDU: Registration Request). The AMF may need to cache this information until it receives the key K from the AUSF at a later stage (e.g. in the Nausf_UEAuthenticate_authenticate response), and the AMF can validate the received UE security_capabilities based on the received MIC and key.

[0141] The specific message flow for this embodiment variation is as follows: 1. The UE computes a random key K. 2. The UE computes a MIC using K based on the selected UE security capability. 3. The UE sends the UE security capabilities and MIC to the AMF via the gNB in ​​an initial message (e.g., NAS registration request). 4. The UE sends the encryption of the concatenation of SUPI and K (hereinafter SUCIK) to the AMF in a NAS ID response. The encryption is performed according to Annex C.3 of TS 33.501. 5. The AMF forwards the SUCIK to the AUSF in a Nausf_UEAuthenticate_authenticate request. 6.AUSF interacts with UDM to obtain SUPI and K from SUCIK. 7. The AUSF returns the SUPI and K to the AMF in the Nausf_UEAuthenticate_authenticate response. 8. The AMF verifies the security capabilities of the UE based on the received K and MIC.

[0142] Note that some fields may be sent earlier or later, for example the MIC may be sent to the AMF in step 4. In this variant, if an attacker modifies the SUCIK, the verification of the MAC tag value of the SUCIK fails. If an attacker modifies the SUCIK, the MIC verification fails. If an attacker modifies the UE security_capabilities, the MIC verification fails.

[0143] Note that instead of generating a random key K, encrypting it, and transmitting the encrypted key K, the UE could also use other fields already transmitted encrypted as encryption keys to be used in the MIC calculation. However, this is only feasible if those fields are long enough and difficult to predict (e.g., randomized), otherwise they could be inferred from the transmitted MIC. Note that the SUCI protects (encrypts) the MSIN of the SUPI, which may be too short, since it is 10 digits long. Note that this approach can also be combined with the above approach with the generation / encryption / exchange of the key K, which has the advantage that the encrypted key K needs to be transmitted somewhat shorter.

[0144] Generally, the above embodiments provide an apparatus for securing communications with a second device, the apparatus being configured to perform the following steps. (a) encrypting a randomly generated symmetric key using a first public key linked to a private key possessed by a second device; (b) sending the message and the encrypted symmetric key to the second device. In particular, the device may be used to protect the integrity of information exchanged with the second device in the first message, and the device may be able to calculate a message integrity code on certain information (requiring protection in the first message) and send the information and the message integrity code to the second device. In particular, in this device, the information may be a security function. In particular, in this device, the message may be an attach request or a registration request. In particular, the first device may include the device. In particular, the device may encrypt / integrity protect the symmetric key with a secret identifier (e.g., SUPI), which, once decrypted / integrity verified, is used by the recipient to obtain a root secret (e.g., K_AUSF) used to perform subsequent authentication procedures. In particular, the device may encrypt / integrity protect the symmetric key with a parameter that can prevent replay attacks. In particular, the device may use an encryption algorithm that is secure against chosen ciphertext attacks.

[0145] EMBODIMENT 10 If the messages 110 are exchanged in a protected (confidentiality protected) manner, no attack is feasible, since an attacker may not know how to meaningfully modify the information in the messages 110. This can be achieved by encrypting the information in the messages 110 (e.g. UE security parameters) that should be securely transmitted to the core network 104 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 TS33.501. When the core network receives the message 110, it decrypts the encrypted fields of the received message 110 using the private key that corresponds to the encryption public key.

[0146] This approach may be easier for an attacker to circumvent compared to the approach of the above embodiments (e.g., embodiment 3), because the encrypted message may be malleable and the attacker may know how to flip certain bits (where the security capabilities of the UE are swapped) based on the expected security capabilities of the UE.

[0147] EMBODIMENT 11 The above embodiments, e.g., embodiments 9 and 10, describe protecting the integrity / confidentiality of sensitive parameters (e.g., UE security features) by a symmetric key encrypted with the home network's public key. An alternative is to generate a shared secret (e.g., based on Diffie-Hellman as described in other embodiments (e.g., embodiment 12)) and use that key, or a key derived therefrom, to protect the integrity / confidentiality of those parameters (e.g., next to the SUPI). These encrypted and / or integrity protected parameters are then sent by the UE to the core network, where they can be decrypted and integrity verified to securely retrieve them.

[0148] A specific but exemplary message flow for this embodiment may be as follows: 1. The UE obtains a message M by concatenating the SUPI with parameters that require protection (eg UE security capabilities). 2. The UE protects a message M, e.g. as per TS 33.501, Annex C.3. This protected message is called PM. 3. The UE sends the PM to the AMF, for example in a NAS ID response. 4. The AMF forwards the PM to the AUSF, for example within a Nausf_UEAuthenticate_authenticate request. 5.AUSF interacts with UDM to obtain SUPI and parameters from PM. 6. The AUSF returns the SUPI and parameters to the AMF, for example in a Nausf_UEAuthenticate_authenticate response. 7. The AMF uses / verifies parameters (e.g. UE security capabilities). If an attacker modifies the PM, it will no longer be possible to decrypt / integrity verify the protected parameters and the SUPI, and the attack will fail. Because the attacker does not know the UE's SUPI, he cannot replace the PM to contain incorrect parameters. If the attacker were to try to do this, he would use an incorrect SUPI and the primary authentication would fail.

[0149] Generally, the above embodiments provide an apparatus for securing communications with a second device, the apparatus being configured to perform the following steps. (a) deriving a first symmetric key using a first public key linked to a private key possessed by a second device; (b) creating a message including a UE identifier and other parameters requiring secure exchange and / or verification; (c) computing a protected message by using the first symmetric key or a key derived from the first symmetric key to encrypt and / or integrity protect the message; (d) sending the protected message to a second device;

[0150] In particular, the apparatus may be used to integrity protect parameters or information exchanged with the second device in a first message. In particular, in the apparatus, the information may be a security feature. In particular, in the apparatus, the first message may be an attach request or a registration request. In particular, the first device may include the apparatus. In particular, the apparatus may encrypt / integrity protect the parameters together with a secret identifier (e.g., SUPI), which, upon decryption / integrity verification, is used by the recipient to obtain or derive a root secret (e.g., K_AUSF) used to perform a subsequent authentication procedure. In particular, the apparatus may encrypt / integrity protect said parameters together with a parameter that is replay-proof. In particular, the apparatus may use an encryption algorithm that is secure against chosen ciphertext attacks.

[0151] EMBODIMENT 12 In the attack scenario shown in FIG. 3, a man-in-the-middle, consisting of, for example, 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 may randomly generate a key K and encrypt it with a long-term public key of the home network. The home network may then decrypt it and share the decrypted key, or a key derived from it, with a radio access network (RAN), such as a base station, that handles the UE's access. This key shared between the UE and the gNB may be established earlier than KgNB, and thus may provide early protection between the UE and the gNB, for example against man-in-the-middle attacks, as shown in FIG. 6.

[0152] Alternatively, the key K may be based on a Diffie-Hellman (DH) 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 (or may be derived from) prK_UE*puK_HN=prK_HN*puK_UE.

[0153] In FIG. 6, in step 604, the UE 600 establishes a connection with the base station 601. Then, an initial message 605 is sent towards the core network, which is forwarded in message 606 and arrives at an entity (e.g., 5G AMF 602) that handles the registration and mobility of the UE. The messages 605 and 606 contain a key K generated by the UE 600 and encrypted with the public key of the core network. In particular, the function 603 may store a private key that is used to decrypt the key K when it is received in message 607. The function 603 transmits this key K, or another key K' encrypted with K, or another key K' derived from K, to the network function 602 in step 608, which securely shares it with the base station 601 in step 609. The base station can extract the key, e.g., K. The UE and the base station can then protect the message 611, e.g., as shown in embodiment 16.

[0154] Whether or not base station 601 supports the use of K may be broadcast in the system information delivered by the base station.

[0155] Whether the UE requires key establishment may be determined based on a policy deployed on the UE by the home network.

[0156] Generally, the above embodiments provide an apparatus for securing communications with a second device (eg, a base station), the apparatus being configured to perform the following steps. (a) encrypting a (randomly generated) symmetric key using a first public key linked to a private key owned by a third device (e.g., a core network or a sub-entity of the core network); (b) transmitting the first message and the encrypted symmetric key to a third device; (c) securely communicating with the second device using the generated key, or a second key derived from the key, or a second key decrypted by the key. In particular, the apparatus may be used to protect the integrity of information exchanged with the third device in a first message, and the apparatus may be capable of calculating a message integrity code on certain information (requiring protection in the first message) and transmitting the information and the message integrity code to the third device via the second device. In particular, in this apparatus, the information may be a security function. In particular, in this apparatus, the message may be an attach request or a registration request. In particular, the first device (e.g., a UE) may include the apparatus. In particular, the above embodiments provide a method for securing communications between a first device (UE) and a second device (e.g., a base station), in which the first device encrypts a randomly generated symmetric key using a first public key linked to a private key owned by a third device (e.g., a core network), the first device sends a first message including the encrypted symmetric key to the third device, the third device sends a second key to the second device, the second key being the received key, a key derived from the received key, or a key encrypted by the received key, and the first device and the second device communicate securely using the second key.

[0157] EMBODIMENT 13 In another embodiment, modifications to the authentication and key agreement may allow the UE and gNB to derive K_gNB for 5G earlier than is currently possible for 5G, as described in TS33.501 clause 6.2.2.1.

[0158] Generally, referring to FIG. 1, the core network (103) may obtain a shared key SK derived from a master secret MS already shared between the UE (100) and the home core network upon receipt of the initial message 111. This MS may be stored in the USIM. This shared key SK may be derived, for example, by generating the entire key hierarchy (e.g., K_AUSF, K_SEAF, K_AMF, K_gNB), as is done today, or may be generated directly from the master secret MS, for example using a nonce generated by the UE (100) and the CN (103), or a time value such as UTC time, or the name of the serving network, or a parameter associated with the gNB as input, or may be derived from K_gNB as a temporary secret used only in the initial message exchange. The core network 103 may then securely transmit the derived key SK (e.g., the previously generated K_gNB, or another key derived from the MS) to the RAN (e.g., gNB). The core network may further send in message 112 / 113 the parameters necessary for the UE (100) to derive this SK. If the SK relies, for example, on an existing key hierarchy, the UE (100) may need to first process the received message 113 and perform all authentication / freshness checks before the SK is 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 apply, for example whether the nonce sent by the UE in message 110 is used for the key derivation or whether the time parameters used for the key derivation and signaled by the core network (103) are fresh (for example, match the UE's current time). It should be noted that CN entities / functions such as AUSF, SEAF, AMF, etc. may not be aware of the fact that the UE has already generated all the keys, while the CN entities have not yet received the corresponding keys because the current authentication procedure did not help.

[0159] EMBODIMENT 14 In an embodiment relating to the derivation of a key K based on Diffie-Hellman (DH), Figure 10 shows a procedure for deriving such a key, which may include one or more of the following steps: - Step-1: The UE generates a temporary public key pair. - Step-2: Based on the Diffie-Hellman key exchange protocol, the UE calculates a temporary shared key based on the stored public key of the HN and its own temporary private key. - Step-3: The UE derives a temporary symmetric key (Symkey) and a temporary MAC key from the temporary shared key used for encryption and integrity protection of the SUPI. At this stage, the UE derives another key K s = f(ESK,EPK), where ESK and EPK represent the ephemeral shared key and the UE's ephemeral public key. - Step-4: The UE encrypts the MSIN using the Symkey and then calculates a Message Authentication Code (MAC) using the MAC key to ensure the integrity of the SUCI. - Step-5: The UE sends the SUCI, including the temporary public key, the ciphertext and the MAC, to the serving network (SN). - Step-6: The SN sends the received SUCI along with the Serving Network Name (SNN) to the Home Network (HN). The HN extracts the UE's temporary public key from the SUCI, performs steps 2 and 3 using its own private key, and obtains the Symkey, MAC key, and K s = f(ESK,EPK). - Step-7: HN verifies the integrity of SUCI through MAC value and obtains SUPI by decrypting SUCI using Symkey. Step-8: Upon verifying whether the UE is authorized on the network, the HN generates a Home Environment Authentication Vector (HE AV) and derives a Serving Environment Authentication Vector (SE AV) and associates it with K s The same is sent to the SN. Step-9: NAS_authentication_request is sent to the UE. At this stage, sOr a key derived from this may be used to protect the authentication request message, for example at the application, PDCP, RRC, MAC or physical layer.

[0160] EMBODIMENT 15 According to TS 23.502, when a UE performs an initial registration it must indicate its identity in the registration request message to the PLMN. The UE's identity corresponds to 5G-GUTI if available, otherwise the UE must include the SUCI in the registration request as defined in TS 33.501.

[0161] 6.12.4 of TS33.501 specifies when the subscriber identification mechanism (ID request) can be invoked: if the UE cannot be identified by the temporary identifier 5G-GUTI, i.e. if the AMF can obtain a SUPI based on the 5G-GUTI, the subscriber identification mechanism is skipped.

[0162] The key generated by DH (Diffie-Hellman) proposed in the above embodiments, for example, 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, so the temporary public key puK_UE needs to be sent to the home network to generate a key based on DH. If the registration request message includes SUCI, the home network obtains puK_UE and derives a key based on DH. However, if the UE communicates 5G-GUTI in the registration request message and the AMF can obtain a 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 a key based on DH is not communicated.

[0163] 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 the RRC connection setup, and the registration request message may be modified to include the puK_UE in addition to the 5G-GUTI. Alternatively, if the AMF uses the 5G-GUTI to obtain the SUPI, the SUCI may be included so that 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, after which the puK_UE is extracted by the Subscriber Identifier Decryption Function (SIDF) in the UDM.

[0164] In additional or alternative embodiments, which can be used independently, the authentication procedure (eg, primary authentication) may consist of the following steps: - In the first stage when the authentication procedure is performed, the UE uses an encrypted identifier (e.g. SUCI) and potentially also a public key to protect additional sensitive fields (e.g. security features). - Upon successful completion of the authentication procedure, the UE is provisioned by the home network with a temporary identifier (pseudonym) and a temporary secret (eg, a symmetric key). The next time an authentication procedure needs to be performed, the UE can use this pseudonym and the temporary secret. The pseudonym may be used, for example, to identify the UE by the AMF (e.g. in the VPLMN) and the temporary secret may be used to protect sensitive fields.

[0165] In one variation, the UE may use the pseudonym and temporary secret, for example, in the following cases: - The UE can obtain it from the security context. - The policy is (pre)configured in the UE by the network.

[0166] The main difference in this embodiment is the allocation of a temporary secret that can be used in subsequent authentication steps without relying on the public key, thus improving performance. This secret may be used, for example, for the following purposes: - Securely transmit the UE's location information to, for example, the HPLMN and determine whether the user has consented to sharing the location information with the VPLMN. - Safeguard security features. -

[0167] In one variation, the temporary secret may be for protecting communications between the UE and the HPLMN and / or between the UE and the VPLMN, or both.

[0168] In one variation, the temporary secret / key may be used to derive multiple secrets / keys, for example for encryption and integrity protection, for example by a key derivation function for the HPLMN or VPLMN.

[0169] In one variant, if a temporary secret is used to protect communications between the UE and the VPLMN, the HPLMN shares the temporary secret with the VPLMN, for example together with the assigned GUTI.

[0170] In one variant, if the sensitive fields need to be protected from the UE to the HPLMN, the secrets are not shared with the VPLMN.

[0171] In one variation, the next time the pseudonym / temporary secret is used, e.g., if authentication needs to be performed again, the VPLMN / HPLMN may reassign a new pseudonym / temporary secret. - When the UE transmits any data to the HPLMN, the HPLMN may assign a new pseudonym / temporary secret and inform the VPLMN. - If the UE transmits any data to the VPLMN, the VPLMN provides a confirmation of such data sharing to the HPLMN, and the VPLMN may assign a new pseudonym / temporary secret, which may be one determined by the HPLMN. - When the HPLMN / VPLMN needs to transmit some data to the UE, the HPLMN / VPLMN may assign a new pseudonym / temporary secret. In a variant, the temporary secret is used in conjunction with a given encryption algorithm (e.g., NEA) or integrity algorithm (e.g., NIA) that may be negotiated / indicated / set when the temporary secret is set and / or when the temporary secret is used.

[0172] In a variant, a message protected with a temporary secret includes metadata (e.g., an input field (e.g., a counter) for the NEA or NIA algorithm) used to protect the message with the corresponding encryption / integrity algorithm.

[0173] In a variant, in order to avoid the UE / CN having to keep state (e.g. the value of a counter) if the temporary secret is reused multiple times, the temporary secret is used as a root secret that is used to derive one or more keys (e.g. encryption and / or integrity keys), for example by means of a key derivation function and other fields (e.g. a nonce or a counter based on UTC). The derived keys are used to protect messages and the fields used in the key derivation function are included in the exchanged messages.

[0174] EMBODIMENT 16 For example, a way to protect communications at an earlier stage may include applying established keys at the PDCP level, e.g., as described in Figure 6 in connection with embodiment 12 or 13. In particular, the established keys may be used to derive control plane keys that protect the integrity and / or confidentiality of messages (e.g., message 611 in Figure 6) exchanged between the UE and the base station.

[0175] Alternatively, the established key K may be used to protect the communication link at a lower layer (e.g., MAC or physical layer). For this, K may be used to derive one or more keys for the lower layer, for example by applying a KDF. Additional input parameters to the key derivation function may include the layer, the communication direction (e.g., uplink), a time counter (e.g., based on UTC or based on a communication counter such as SFN), etc. For example, in case of the MAC layer, a specific MAC CE from message 611 onwards may be protected, which may involve multiple functions / variants.

[0176] First, it may be necessary to indicate which MAC CEs are protected, which is done, for example, by: (1) including a mask in the / each message. For example, if a message includes four MAC CEs, the mask consists of four bits, with a bit set to 1 indicating that the MAC CE is protected; and / or (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 masks do not have to be exchanged in each message; and / or (3) Pre-configuring a policy, for example in a USIM, that indicates which MAC CEs are protected.

[0177] Second, it may be necessary to agree on a protection algorithm, for example by doing the following: (1) The standard defines a single algorithm that refers to an encryption and / or integrity protection scheme; and / or (2) Including preferences in messages 605 and 606. The preferences may be integrity protected, and the preferences may be indicated in messages 608 and 609.

[0178] Third, it may be necessary to store a policy in the UE such that the UE rejects messages received from the base station if, for example, the message is not protected as expected or if the message is processed in a particular way, where the rejection or processing may depend on the type of message.

[0179] Fourth, the base station may need to store a policy to reject messages received from the UE if the messages are not protected as expected.

[0180] Fifth, it may be necessary to generate a message integrity code on the protected MAC CE, which can be done, for example, by (1) appending a MIC to the message using an integrity algorithm such as NIA, or (2) using a key derivation function whose inputs are the message fields that require protection and a counter (e.g., a counter that identifies the message or SFN) or a UTC time-based counter.

[0181] Sixth, it may be necessary to generate an encryption stream that can be used to encrypt the selected MAC CE field. This can be done using a KDF whose inputs are the derived key, a freshness counter, and a counter that generates an arbitrary length keystream. The output of the KDF is used to XOR the selected MAC CE.

[0182] Seventh, to facilitate message processing (eg, encryption and decryption), it may be necessary to place the protected MAC CE fields next to each other.

[0183] Eighth, a lightweight authentication and encryption scheme may be applied as ASCON, or ASCON based on MAC CE protection.

[0184] Ninth, ASCON takes as input a key, a nonce, and an initialization vector. The initialization vector may depend on a counter such as the SFN. The nonce may depend on an unencrypted field.

[0185] Tenth, ASCON returns a TAG. If integrity protection is required, a subset of the bits of the TAG (e.g., the least significant bits) may be used as a MIC.

[0186] Eleventh, the keys generated, for example during the authentication and key establishment phase of FIG. 1 (for example, primary authentication in 5G), may be long keys, for example 256-bit long keys. With the advent of quantum computers, such long keys may be necessary to ensure long-term security. However, the protection algorithms used for the MAC CE fields may, for performance reasons, only take as input short keys, for example 128-bit keys. The key hierarchy may therefore be such that short keys are derived from long keys. This variant may be applicable independently of other security procedures, such as the PDCP layer in the cellular network.

[0187] 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 that long key, e.g., by a key derivation function, then multiple (e.g., two) shorter keys may be obtained in 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 is twice as long as the short key). These multiple shorter keys may be used as follows: (1) in successive use (e.g., 128 LSBs at time t0, the next 128 bits at time t1, ...), and / or (2) for different uses (e.g., the 128 LSBs are used as a key to protect uplink communications and the 128 MSBs are used as a key for downlink communications), and / or (3) for different purposes (e.g., the 128 LSBs are used as an encryption key and the 128 MSBs are used as an integrity key), and / or (4) for different communication planes (e.g., 128 LSBs are used in the control plane and 128 MSBs are used in the user plane), and / or (5) For different purposes in an encryption / integrity algorithm (e.g., ASCON) (e.g., the 128 LSBs are used as the key and the 128 MSBs are used as the nonce).

[0188] The advantage of the above procedure is that it results in fewer calls to the KDF, improving performance.

[0189] This variant may be applicable independently of other security procedures such as the PDCP layer in the cellular network.

[0190] This embodiment, e.g. protection of the MAC CE field, could be applied using other keys, e.g. the MAC CE field could be protected using a key derived from the 5G KgNB.

[0191] Examples of applications that require protection of the MAC CE field include, for example: (1) Protection of control messages at L1 or L2 used to control smart repeaters (e.g., beamforming of smart repeaters). (2) Protection of messages exchanged at the RRC layer (which are not protected in 5G R17) and which are used, for example, to disconnect a UE connected to an IAB node or a mobile base station when the IAB node (or mobile base station) determines that the radio link with the parent node has failed. (3) "SCell Activation / Deactivation MAC CEs" may be used to disable communication via the SCell so that the UE cannot receive data via that SCell. (4) False “TCI State Indication for UE-specific PDCCH MAC CE” and / or “TCI States Activation / Deactivation for UE-specific PDSCH MAC CE” may be used to request the UE to adjust its Rx beam to a direction that is not preferred for receiving signals from the gNB. (5) Inconsistency may occur between the gNB and the UE regarding CSI feedback by using a false “Aperiodic CSI Trigger State Subselection MAC CE” to select a code point that the base station does not intend to use.

[0192] Generally, the above embodiments provide an enhanced apparatus for securing communication with a second device, the apparatus being 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 2 (L2) message. In particular, the message may be a MAC CE (field). In particular, the apparatus may rely on a policy set by a third device to determine which messages require which type of protection. In particular, the apparatus may include in the exchanged message a mask indicating which fields are protected. In particular, the first device (e.g., UE) may include one or more of these apparatuses. The above embodiment also provides a method for securing communication between a first device and a second device, the method comprising securely exchanging at least one message between the first device and the second device using a key or a second key, or a key established / derived from a KgNB, the message may be a MAC CE field, and the first device and the second device may have policies set by a third device that determine which messages require which protection.

[0193] Cellular networks rely on multiple types of encryption and integrity algorithms. For example, the NEA algorithm (TS33.501, section D2), the NIA algorithm (TS33.501, section D.3), or the subscription persistent identifier hiding algorithm (TS33.501, section C). These algorithms are configured to achieve 128-bit security. However, with the advent of quantum computers, it is expected that new algorithms will be introduced to provide 256-bit security (classical level). For example, ETSI SAGE has developed new 256-bit security algorithms that have never been seen before. To this end, the SAGE group has developed new 256-bit algorithms, including air interface encryption and integrity algorithms (for both user and control plane traffic), as well as authentication and key agreement (AKA) algorithms, to provide long-term resistance against possible future quantum computing attacks in 5G systems. If necessary, the same 256-bit algorithms may be retrofitted to previous generations of mobile systems. In TDoc S3-230642, ETSI SAGE informed SA3 that the Snow 5G, AES-256, and ZUC-256 specifications do not require further evaluation by SAGE. Even if new algorithms are introduced, existing algorithms are unlikely to be immediately phased out. Resource-constrained devices may only support algorithms with 128-bit keys, whether existing or new algorithms such as ASCON, for performance reasons. Even high-end devices may prefer algorithms that rely on 128-bit keys for performance reasons, especially for high data rates.

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

[0195] In an embodiment that can be used independently, the KDF may be based on SHA-3 in FIPS202 or on SHA-3 derivative functions in NIST SP800-155. For example, the KDF may rely on the SHA-3 SHAKE(M,d) function, which can output a variable number of d bits given an input M. For example, the KDF used relies on the SHA-3 cSHAKE(M,d,N,S) function, which can output a variable number of d bits given an input M with a personalization string S and a function name bit string N. For example, the KDF used may 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 personalization string. For example, the KDF may use the XOF function to derive further keys based on the input. For example, the SHA-3 KMACXOF256(K,X,L,S) may be used, where a 256-bit key K is used with a given personalization string S. This has the advantage that if multiple keys are needed, more can be obtained by calling the same function again. This has the advantage that keys of different lengths can be easily generated.

[0196] In an embodiment that can be used independently, the Message Integrity Code (MIC) used in the communication system, for example the MIC used in the PDCP layer or the MAC CE protocol, may be based on SHA-3 in FIPS202 or a SHA-3 derivative in NIST SP800-155. In particular, it may be based on SHA3 KMAC(K,X,L,S), where X corresponds to the message requiring the MIC to be calculated, K corresponds to the key used to calculate the MIC, S corresponds to the personalization string, and L corresponds to the recommended output length.

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

[0198] In a related embodiment, the KDF may also include input parameters indicating usage, i.e., KDF(key, S, Usage, length), which may allow the same key to be used for different purposes, which may be implemented as cSHAKE(key, length, Usage, S).

[0199] In one embodiment, if different key lengths are supported, the communicating parties (e.g., user equipment, access devices, network functions, application functions, etc.) may need to negotiate which key lengths are supported and / or which key lengths will be used. These may be provisioned or configured, such as through policies that specify which keys, input parameter lengths, and / or output key lengths, and / or KDFs are used for which purpose / function.

[0200] In one embodiment, an application or communication layer or device can indicate to a communicating party the required key length. For example, when an AF requests a K_AF key from an AAnF, the AF can include the required key length in K_AF in the key request. - This is necessary because different protocols, such as TLS and OSCORE, may rely on cipher suites that use 128-bit or 256-bit keys, requiring the communicating system to return keys of different lengths, such as 128-bit or 256-bit keys. - When the UE establishes a secure communication link with the core network (NAS security), access device (AS security), the device and / or the core network (home network and / or visited network) and / or the access device indicate the required / achievable security level, e.g., AS security, or NAS security, at the PDCP layer. For example, if 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-bit or 256-bit) and select a security algorithm accordingly.

[0201] 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), while 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 / indicate this exceptional status, for example, in a SIB (e.g., SIB1) and / or an RRC message and / or a NAS message. This exceptional status may allow the network / UE to use a 128-bit security (encryption) algorithm instead of a 256-bit security (encryption) algorithm.

[0202] In a variant, 256-bit security algorithms and keys may always be preferred unless the communicating parties require a downgrade to 128-bit security algorithms and / or keys (eg, backward compatibility).

[0203] The UE may be configured with a given policy by the HPLMN, or the UE may have a particular preference for the use of the 256-bit or 128-bit algorithm. However, while roaming, the UE may be located or accessed via a VPLMN that may have different preferences or capabilities. Thus, it may be necessary for the UE to decide which VPLMN to join, the VPLMN and the HPLMN may need to agree on security requirements, and / or the HPLMN may need to configure temporary policies for the UE as long as the UE is in that VPLMN. To address these requirements,

[0204] In a variant, the network may indicate, inter alia, (e.g. in a SIB, RRC or NAS message, or in an initial authentication procedure (e.g. primary authentication)) the preferred and / or supported security algorithms (e.g. 256-bit or 128-bit), allowing the UE to use this information to select a network that is more suitable for its communication needs. Upon receiving this indication, the UE can check if the indication fits 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, another supports 128-bit security, and another supports both 128-bit and 256-bit security, the UE may prefer (based on policy) to select one of them (e.g. the last one). This policy may be set by the HPLMN and stored in the UDM.

[0205] In a variant, the UE may specifically indicate (e.g., in an RRC establishment request or registration request, e.g., security capabilities) the preferred and / or supported security algorithms (e.g., 256-bit or 128-bit), such that this information can be used by the UE 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 provide service to the UE.

[0206] In variants, the UE / HPLMN may indicate to the VPLMN the requested / offered security level (e.g., 128-bit or 256-bit security) and / or the VPLMN may indicate to the HPLMN / UE that the VPLMN (e.g., a particular access device) can (cannot) provide a particular security level. For example, the UE may request the use of a 128-bit encryption algorithm, while the access device may not support a 128-bit encryption algorithm (this security level is deprecated), or vice versa. The presentation of these information may trigger a temporary reconfiguration of the UE or access device to provide the service, which may be logged.

[0207] In a variant, the supported security algorithms are indicated by a one-bit index, e.g., 0 indicates that 128-bit algorithms are supported, 1 indicates that 256-bit algorithms are supported, and so on.

[0208] In a variant, the preferred security algorithm is indicated by a single bit index, for example 0 indicates that 128-bit algorithms are supported, 1 indicates that 256-bit algorithms are supported, and so on.

[0209] In a variant, the preferred security algorithm may be indicated by a two-bit index, e.g., 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.

[0210] In a variant, the preferred algorithm is indicated by the order of the indicated supported algorithms. For example, if the security algorithms are named NEA0, NEA1, NEA2, NEA3 (as in the case of TS33.503) and NEA4, NEA5, NEA6, for example, corresponding to Snow 5G, AES-256, ZUC-256, the UE can indicate its preference to the network by communicating a list containing the supported / recommended algorithms, with the preference indicated by the order (e.g., NEA5, NEA4, NEA6, NEA2, NEA1). This indicates that the UE supports these five algorithms, with the most preferred being NEA5 (the first one in the list) and the least preferred being NEA1 (the last one in the list).

[0211] Appendix A.7 of TS33.503 describes how message specific confidentiality protection is provided for discovery between ProSe UEs. In this specific example, a 256-bit key is used to derive the key, and the least significant 128 bits of the key are used as input to a 128-bit encryption algorithm as shown in TS33.501 (Appendix D). If a 256-bit encryption algorithm is introduced, this truncation (using the least significant 128 bits as the key) may not be necessary. In some cases, two entities decide to use a 256-bit algorithm, but the KDF output used to feed the 256-bit algorithm is not properly aligned, and the KDF output may still be truncated to a 128-bit key. Thus, the security level is lower than expected. To address these shortcomings,

[0212] In a further 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 (without truncation) or a 128-bit algorithm (with truncation). For example, Appendix A.7 of TS33.503 states that the input parameters to the encryption algorithm are as described in Appendix D of TS33.501[3], where KEY is KDF(DUCK, UTC-based counter, MIC, security level), e.g., LeastSignificantBits(KDF(DUCK, UTC-based counter, MIC), security level), where security level refers to the security level of the selected encryption algorithm (128 or 256) and determines the length of the returned key. This embodiment can be combined with other embodiments, showing the advantage of having a new generalized key derivation function that takes the desired key length / output size as input.

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

[0214] In additional or alternative related embodiments, the key derivation function may also indicate a desired security strength and a desired output size. This may result in a single KDF definition that determines the security strength (e.g., 128 or 256) and may include the output size KDF(key, security_level, output_key_size). This may be implemented, for example, 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).

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

[0216] In additional or alternative embodiments, the level of security and / or function output size may be implicitly determined based on the outcome of a negotiation between the communicating parties (e.g., the end UE and the UE-to-UE relay) as to which algorithm (e.g., 256-bit or 128-bit) to use.

[0217] EMBODIMENT 17 The above embodiments may be modified to facilitate improved security in non-terrestrial networks (NTNs). A particularly interesting use case relates to NTN UEs deployed at geographical borders, since different countries may impose different regulations. Because the UE connects to the NTN via a satellite link, it may be difficult for the satellite to determine the specific location of the UE, and the UE may need to expose its location, or a rough location. This location information may be used by the 5G system (5GS) to improve its operation, for example to assign the UE an appropriate AMF. A specific approach to realizing this functionality is to exchange the (rough) location of the UE in a message 110, as shown in FIG. 1. However, this message is not protected, which creates a privacy risk if the UE's location is exposed.

[0218] The above embodiments, for example embodiment 10, may be modified such that the NTN UE encrypts its (coarse) location if it is disclosed before NAS (or AS) security is established (for example in message 110 of FIG. 1), thus ensuring optimal operation of 5GS without privacy risks. Protection of the (coarse) UE location information can be done in a similar way as in Annex C of TS33.501. The process can be performed as shown in C3.2.

[0219] For example, in an embodiment related to 5g standalone access registration, the NTN gNB may not be able to select an AMF at RRCSetupComplete because the NTN gNB does not know where the UE is located and the UE has published its (coarse) location in a protected message, e.g., RRCSetupComplete. Thus, the NAS-PDU registration request may include a protected field containing the UE's location information. This is the field received from the UE that contains the 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 requests the (default) AUSF that a UDM is required to decode the UE location information field that is forwarded to the (default) AMF. The (default) AMF then triggers, e.g., Namf_Communication_UEContext_Response towards the appropriate AMF selected based on the received UE location information. Furthermore, the (default) AMF may inform the (NTN) gNB of the new AMF. Alternatively, the (default) AMF may share the received UE location information with the NTN gNB, which may then perform AMF selection as usual. The (default) AMF is the AMF to which (all) NTN NAS-PDU registration requests are routed, e.g. when the NAS-PDU registration request contains a protected field containing the UE location information.

[0220] In another embodiment, for example for 5g standalone access registration, the NAS ID response includes a protected field containing the UE's location information. In this case, this response may be processed by the (default) AMF and the (default) AUSF. Here, the (default) AUSF is the AUSF to which (all) NTN NAS ID responses are routed, for example when the NAS ID response includes a protected field containing the UE's location information. The (default) AUSF then requests the UDM to obtain the encrypted UE's location information (and possibly the SUPI). Based on the decrypted UE's location information, the (default) AUSF forwards the information to the (default) AMF, which may select the appropriate AMF and trigger a Namf_Communication_UEContext_Response towards the selected appropriate AMF. Furthermore, the (default) AMF may inform the (NTN) gNB of the new AMF.

[0221] In an additional embodiment, which may be combined with the above embodiment or used independently, the network and RAN may request (check) user consent to disclose UE location information. The user consent preference may include multiple conditions, such as whether a particular RAN or AMF is allowed to obtain UE location information, a particular area for which consent is / is obtained, a time frame for which consent is / is obtained, etc. The exchange of protected UE location information may serve as an implicit user consent preference validation, and when the UDM receives it, it may check the user consent preference for NTN access, for example in the Unified Data Register (UDR). The UDM may then use this user consent preference to tailor its response to the remaining entities, such as the AMF or RAN. In particular, the UDM may perform the following: Disclose UE location information with lower accuracy. Refuse to disclose UE location information if, for example, AMF or RAN is not authorized. Check whether the current UE location can be published.

[0222] This approach allows a UE to safely disclose its coarse location without knowing whether the user has given permission to disclose location information. Messages received by the UDM are then checked against user consent policies and the response is tailored.

[0223] Therefore, according to this embodiment, a method implementable in a user equipment is proposed. The method is a method of requesting access to a network resource, and includes securely transmitting user location information with coarse accuracy so that a data manager can verify whether a user of the user equipment has consented to the disclosure of the information. In another aspect of the invention, the data manager securely receives the user location information with coarse accuracy and verifies whether the user has consented to the disclosure of the information. This verification may include verifying under what conditions the consent was given. In another aspect of the invention, if the user consent is positive, the data manager provides the location of the user equipment to a third entity, such as a RAN or an AMF.

[0224] In a related embodiment that can be combined with the above embodiment, the sharing of the user's location information may be performed at the time of establishment of the primary authentication, e.g. when the NAS and / or AS security is established. It may also be performed before the primary authentication is performed. The user's location may be securely exchanged end-to-end protected to the home network, e.g. using a key derived from K_AUSF. This ensures that the data is not accessed by NFs in the path that are not allowed to access the data according to the user consent preferences.

[0225] FIG. 9 illustrates an embodiment in which entities 900 (UE), 901 (gNB / RAN), 902 (AMF), 903 (AUSF), 904 (UDM) interact to obtain a user location in a privacy-aware manner and in compliance with user consent preferences. Note that not all steps may always be necessary. Step 905 represents a primary authentication. This step may include (coarse) location information, e.g., end-to-end encrypted between 900 and 903 (or 904), e.g., protected with a key shared between the entities, e.g., the public key of the home network. Steps 906 and 907 represent the establishment of NAS security and the establishment of AS security. In step 908, entity 901 may request the user's (coarse / specific) location. In step 908, entity 900 provides its own (coarse) location. Since the user's consent has not been verified, the (coarse) location information may be provided end-to-end encrypted between 900 and 903 (or 904), for example protected by a key shared between the entities such as KAUSF. Upon receiving message 909 (or 905), entities 903 and / or 904 obtain the (coarse) location. Entities 903 and 904 may interact in steps 910 and 911 to confirm the user's consent to disseminating this location information to nodes 901 / 902. In particular, in step 910 a request is sent to confirm the consent, entity 904 confirms the consent (entity 904 is the point of enforcement) and returns the result in step 911. Alternatively, in step 910 a request including the encrypted (coarse) location to confirm the consent may be sent, entity 904 decrypts and confirms the consent (entity 904 is the point of enforcement) and returns the result in step 911. Alternatively, in step 910, a request may be sent to get a user consent policy, and entity 904 may return the policy, which entity 903 may then evaluate (entity 903 is the enforcement point).If node 901 / 902 has the authority, the location information is shared in step 912. Entity 903 may also set a policy for node 901 / 902 that specifies when node 901 / 902 can request / obtain / receive / process location information from node 900. The policy may include, for example, a time window during which request / obtain / receive / process location information is allowed. In this embodiment, location sharing may be performed in step 905 or step 909, or both. Also, in step 905 or step 909, location information sharing may be performed with very low accuracy to facilitate RAN to make an initial decision (e.g., AMF selection), and more accurate location information may be securely transmitted to the core network.

[0226] In a related embodiment, the UDM may send a Nudm_SDM_Get response to the AMF including a user consent preference regarding UE location information for NTN access. The AMF may store the user consent preference in the UE context or replace the stored user consent preference with the one received from the UDM. In addition, the AMF may send an N2 message (e.g., an initial context setup request) to the NG-RAN including a user consent result or user consent preference for NTN access in addition to the registration approval. Furthermore, after receiving the N2 message, the NG-RAN may store the user consent result or user consent preference in the UE context. Based on the received user consent result / setting, the NG-RAN may determine how to enforce the user consent with appropriate settings on the UE. In addition, the NG-RAN may send an RRCReconfiguration message (including the registration approval and location setting information) to the UE. If the user consent for location reporting is obtained, the NG-RAN sends a setting for the UE to report the location (e.g., by includeCommonLocationInfo in reportConfig). If the user consent for location reporting is not obtained, the NG-RAN does not send such a setting.

[0227] Furthermore, although the user may not have consented to disclosing his / her UE location to a particular NG-RAN or AMF, the NG-RAN or AMF may be able to modify said messages and, in some cases, a malicious NG-RAN or AMF (e.g., in a VPLMN) may enforce different user consent preferences to obtain the UE's location information. Therefore, furthermore, the (user consent) settings sent to the UE to report location information (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 may be considered. In the case of a MIC, it may be a MIC calculated using a key derived from a key shared between the UE and the home network, for example a key derived during primary authentication (e.g., K_ausf) or a key derived from a 5G key.

[0228] In a variation related to Figure 12, entities 1200 (UE), 1201 (gNB / RAN), 1202 (AMF), 1203 (AUSF), 1204 (UDM / UDR) interact with privacy in mind and in compliance with user consent preferences to obtain the user's location (or other personally identifiable information). Not all of the following steps or exchanged data fields may always be necessary. In step 1205, the UE (optionally) transmits its encrypted (coarse) location information to the RAN. This message may include the GUTI and / or SUCI. In step 1206, the RAN forwards this (optionally) encrypted (coarse) location information, including the GUTI and / or SUCI, to the AMF. · In step 1207, the AMF forwards this (optionally) encrypted (coarse) location information to the AUSF. In step 1208, the AUSF forwards it to the UDM, which decrypts it (if encrypted) to obtain the user consent policy associated with the NTN service. The UDM may also obtain the SUPI. The UDM may make a decision regarding user consent for sharing the location information based, for example, on at least one of the SUPI, the obtained policy, the serving network, or (optionally) the decrypted location. · In step 1209, the UDM returns to the AUSF the user consent decision and / or the user consent preferences and / or the location (if decoded) and / or a token relating to the user consent decision that is verifiable by the UE. In step 1210, the AUSF provides these user consent decisions and / or user consent preferences and / or location (if decoded) and / or tokens to the AMF. Depending on the location, the AMF may (proactively) trigger a NG handover to change to the appropriate AMF and deregister the UE. This is in contrast to e.g. clause 16.14.6 of TS38.300 where such a NG handover is triggered by the gNB / RAN (1201). In step 1211, the AMF provides the user consent decision and / or token to the gNB / RAN (1201). In step 1212, the gNB / RAN (1201) provides the UE (1200) with a token and a request to obtain the user location. The UE uses the token to verify the user consent decision, and if positive, e.g. once AS security is established, the UE can execute the request and start providing its location.

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

[0230] In a related variation, it may be necessary to encrypt the location and the SUPI adjacent to each other, as in embodiment 9 above.

[0231] In a related variant shown in Fig. 13, messages 1205 and 1206 correspond to a NAS identity response, message 1207 is a Nausf_UEAuthenticate_authenticate request, and message 1208 is a Nudm_UEAuthenticate_Get request. In this case, the authentication procedure is only initiated if the HPLMN UDM determines that the UE is authorized to communicate using the serving network and if the user consent preferences allow sharing the user location with the network at the current UE location. It should be noted that since the UE can know the type of RAN it is accessing, for example by observing SIB1, it may decide whether to include only the SUCI or the encryption and (coarse) location of the SUPI in the NAS identity response. In a first alternative, this user consent preference and UE location reporting configuration may be exchanged and confirmed by the UE by the primary authentication message flow as in the above embodiments, for example embodiment 1 or 2. For embodiment 2, message 1209 is a Nudm_UEAuthenticate_Get response, message 1210 is a Nausf_UEAuthenticate_authenticate response, message 1211 is an N2 message, and message 1212 is an authentication request. According to the concept of embodiment 1.2 and the general description of FIG. 12, the token exchanged between AUSF and the UE is the MAC of embodiment 1.2 calculated including the new UE location reporting configuration. This configuration is also included in the Nausf_UEAuthenticate_authenticate response message (AUSF to AMF) and the authentication request (AMF to UE) so that the UE can apply and verify it. In a second alternative, if the UDM / UDR performs this check, a key derived from K_ausf that allows protecting the RRC message (e.g., RRCReconfiguration message (e.g., message 1212)) used to securely inform the UE of the new UE location reporting configuration can be delivered to the AMF and RAN (e.g., K_AMF or K_gNB).If at the start of the primary authentication the entity evaluating the user consent preferences already knows the location of the UE, this is only performed after the primary authentication has been successful. Note that this compares favourably with alternatives such as solution #1 in TR33.896, where the AMF retrieves the UE consent policy, but this AMF may be in the serving network and the SUPI is available in step 5, so the primary authentication has been performed and the AMF already has the appropriate key to derive K_gNB and therefore to send the RRCReconfiguration message. However, in this solution this decision is made without access to the UE location, although the UDM / UDR may benefit from knowing it. Moreover, the appropriate AMF can only be selected after the AS has been established and the UE has started reporting location information.

[0232] In this related variant of FIG. 13, in step 1, the UE sends a NAS ID response including the encryption of the SUPI and the (coarse) location. In step 2, the AMF sends a Nausf_UEAuthenticate_authenticate request to the AUSF to obtain (i.e., decrypt) the SUPI and the location. In step 3, relying on the UDM / UDR, the AUSF (i) obtains (i.e., decrypts) the SUPI and the UE location, (ii) accesses the NTN user consent preferences, and (iii) evaluates whether the user has consented to disclosing his / her location to the RAN / serving network based on the user consent policy, the RAN / serving network, and the location. If consent is given in step 4, the UDM / UDR sends the SUPI, the location, and the user consent preferences to the AUSF. In step 5, the AUSF initiates a primary authentication and at the same time provides the location and the user consent preferences to the AMF. The AMF may trigger an AMF relocation procedure if necessary. In step 6, the AMF sends a message providing the user consent preferences and the location to the RAN. In step 7, the RAN may request the UE to provide its location periodically after K_gNB has been configured, and the RAN can securely send the RRCReconfiguration message. Note that this solution is also applicable in the mobility case, in contrast to e.g. solution 1 of TR33.896.

[0233] EMBODIMENT 18 The above embodiments (eg, embodiment 17) may also be applied to related use cases where user consent is required for the use of personally identifiable information (eg, used for network optimization).

[0234] For example, 3GPP Release-18 has studied artificial intelligence (AI) / machine learning (ML) frameworks for NG-RAN, and the results are documented in TR37.817. It includes three main use cases with the goal of optimizing the network: AI / ML-based network energy saving, load balancing, and mobility optimization. These three use cases require the collection of UE location (e.g., at cell level or coordinate granularity), so depending on local regulations, tracking user location may be a privacy issue and require user consent.

[0235] The technical solutions in the above embodiments, for example embodiment 17, are applicable to enforce user consent to the acquisition and use of personally identifiable information used for network optimization.

[0236] For example, according to one embodiment, an apparatus and method are proposed that can be implemented in a user equipment, where the apparatus checks with a data manager whether a user of the user equipment has consented to disclosing information, for example to some network entity, and the data manager provides a protected response to the user equipment regarding the user consent preferences (such that the network entity cannot change it).

[0237] According to this device option, the network entity may be in a VPLMN (eg, a RAN or AMF in the VPLMN) and the data manager may be in a HPLMN (eg, a UDM or AUSF).

[0238] At the device's option, the reply is protected by a MIC calculated using a symmetric key (eg, derived from or based on K_AUSF).

[0239] At the device's option, the response is protected with a digital signature.

[0240] EMBODIMENT 19 The above embodiments (e.g. 17 and 18) describe cases where a UE needs to disclose its location or coarse location (e.g. for AMF selection or network optimization) and privacy protection measures to protect the disclosed information, where User Consent (UC) requests are processed only by the HPLMN.

[0241] For 5G standalone access registration, the VPLMN (e.g., AMF) may need to know the exact location of the UE (e.g., to forward the UE to a more appropriate AMF). Thus, in one embodiment, if the UE is already configured to expose its location during registration request (e.g., in UE local UC preferences), a message such as a NAS-PDU registration request may include a protected field containing the UE's location information. The VPLMN (e.g., AMF) may request the HPLMN (e.g., AUSF and UDM) to decode and forward the UE's location information field to the VPLMN.

[0242] Alternatively or additionally, for example according to embodiments 14 and 15, a secret key (e.g., K_UC) may be derived from the shared temporary key of the UE and the HN to encrypt the UE location information field in the registration request. Upon receiving the registration request, the VPLMN (e.g., AMF) may forward the SUCI (if included in the registration request) or the temporary public key of the UE (if 5G-GUTI is included instead), and the HPLMN may derive and send the user agreement key K_UC back to the VPLMN (e.g., SEAF). The VPLMN may then decrypt the information location field of the UE. Different user agreement keys may be derived for different purposes of the user agreement. In either scenario, the request made to the HPLMN to decrypt the UE location information field or to derive K_UC may serve as proof that the VPLMN has obtained and recorded the user agreement.

[0243] In another embodiment, for example, for 5G standalone access registration, the UE may only convey user consent preferences in a registration request to the VPLMN. The UE's user consent (UC) preferences may be subject to similar protection measures as the UE's security features described in the above embodiments. Furthermore, these preferences are provided to the VPLMN (e.g., AMF) to cover various conditions regarding requests sent by other network entities (e.g., RAN / gNB, network functions (NFs) in the VPLMN, or AFs) to obtain the UE's sensitive information (e.g., precise location information). The UE's UC preferences may have multiple conditions, such as whether a particular RAN or AF or NF is authorized to obtain the UE's information (e.g., location information) for a particular purpose, the specific area where consent is / is obtained, the time frame for which consent is / is obtained, the purpose for which UC is / is obtained, etc. After conveying its preferences in a message such as a registration request, the UE may include UC-related information (e.g., location information) in a protected field of the NAS ID response (depending on the preferences). This field may be protected (e.g., encrypted) using, for example, the same secret key as that used to protect the SUPI. Alternatively, it may be protected (e.g., encrypted) using another key (e.g., K_UC) derived from the temporary shared key. Similar to the above embodiment, the VPLMN (e.g., AMF) may request the HPLMN to verify / decrypt and send back the UE user consent information (e.g., location information data), or may 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 either scenario, the request made to the HPLMN may serve as evidence that the VPLMN has obtained and recorded the user consent and / or preferences.

[0244] In an additional embodiment, which may be combined with the above embodiments or used independently, if the UE provides a UC preference at an earlier stage (e.g., in the registration request), the VPLMN should verify and / or match the UE preference with the UC preference before disclosing and / or processing and / or requesting sensitive information collected from the UE, e.g., when interacting or communicating with the RAN or other network entities (e.g., NF or AF). For example, if the UE's location information is requested by the AF, the VPLMN (e.g., AMF) may perform the following: - Disclose UE location information with low / high accuracy. - Refuse to disclose the UE's location, e.g., if AF is not allowed or if the purpose of the request does not match the UE's UC preferences. - Check whether the current UE location can be published.

[0245] As mentioned above, such an approach allows a UE to securely disclose its (coarse) location without knowing whether the user has given permission to disclose location information. Requests received by the VPLMN (e.g. AMF) from other entities (e.g. RAN or AF) are checked against the UC policy and the response is tailored. This approach has the advantage that the verification of user consent remains within the domain of the VPLMN.

[0246] In a related embodiment, the user may be prompted with a user consent page before, during, or after the authentication procedure before the UE provides its UC preferences to any network entity. The user consent page selects preferences, stores them locally on the UE, and communicates them to the network. The location (e.g., URL) of the user consent page or the page itself may be communicated to the UE by system information or initial access procedure. The user may choose to request a user consent page to adjust his / her user consent preferences compared to the network's default user consent preferences. The user may select this by a setting in the UE. The user may also choose to accept the network's default user consent preferences. The UE may communicate the UC preferences (agree or not agree) as a bitmask for each selected CE option. If the UE does not communicate its UC preferences, the network may assume that the default network UC preferences are accepted.

[0247] In a related embodiment, which may be used independently or in combination with other embodiments, a network (e.g., a VPLMN) may provide to the UE a request for approval / adjustment of UC preferences signed with a private key associated with the network (e.g., a private key owned by the network) to serve as proof of UC selection to a second network (e.g., a HPLMN) or entity.

[0248] These UC preferences may be considered as default preferences and / or selected preferences provided by the UE, for example in the registration request or upon request. In case of a request for information outside the scope of the UC policy or a UC request 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. The UC Update Request redirects the UE to a consent page where the user may select one or more of the following options, where the selected option may be protected as described in other embodiments: - Provide UC and update UC policies to accommodate similar requests in the future. - Providing UC only for this specific request, only to the specific network entity that made the request, and / or only for a limited time. - Suspend UC and update UC policies to accommodate similar requests in the future. - Reserve UC for this specific request only.

[0249] This approach allows the UE to control and verify the conditions governing UC policies (e.g., what information is exposed to which network entities and for how long).

[0250] In an additional embodiment that can be combined with the above embodiment, the VPLMN (e.g., AMF) may be configured to periodically check for updates of the UE's UC preferences (e.g., upon re-authentication), and the AMF may send a UC Update Request to the UE in a NAS ID Request, and the UE may respond by including the (updated) UC policy in a protected field of the NAS ID Response. Alternatively, the UE may be configured to provide the (updated) UC preferences, e.g., in a Registration Request. In such a case, the VPLMN (e.g., AMF) checks whether a UC policy associated with the UE is recorded, and if so, updates accordingly, otherwise records the UE's UC preferences. The UC preferences may be associated with the UE by SUPI / GUTI / SUCI or other IDs (e.g., RAN ID). The network (e.g., VPLMN, e.g., AMF) may send an acknowledgement that the UE's UC preferences have been stored / updated instead of the UC Update Request (e.g., in the NAS ID Request). If the network (e.g., VPLMN, e.g., AMF) has a mapping between 5G-GUTI and SUPI or if the registration request includes SUCI (i.e., no NAS ID request is sent), the VPLMN (e.g., AMF) may send a positive response to the UE, e.g., with a NAS authentication request. In either scenario (i.e., whether the (updated) UC preferences are provided by the UE or at the request of the network), the network records the UC preferences and / or other UC-related information (e.g., location) if provided, and how they were obtained (i.e., by the UE or at the request).

[0251] In related embodiments, the VPLMN (e.g., AMF) may need to report to the HPLMN (e.g., UDM, etc.) UC policies or updates received from the UE or requests made to obtain these UC preferences (updates) and / or user consent related information (e.g., location). When 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) along with the SNN and SUPI / SUCI, for example, for decoding. The HPLMN 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) protected, for example, in the NAS ID response field, the VPLMN may forward the UE's protected response to the HPLMN. The HPLMN may decrypt / verify it and send it back to the VPLMN (e.g. AMF) or send the key to the VPLMN (e.g. SEAF) which may decrypt / verify the UE's UC preferences / information and provide it to the relevant entities (e.g. RAN, AMF, NF, AF, etc.). Regardless of the means and the nature of the information conveyed (i.e. UC policy or location), the VPLMN may be required to provide that information to the HPLMN. Furthermore, the HPLMN (e.g. UDM) may request the VPLMN (e.g. AMF) to provide the recorded UC policies and the respective UE identifiers linked to them to ensure that the VPLMN is applying UC as expected.

[0252] According to this embodiment, a method implementable in a UE is proposed for requesting access to a network source, comprising transmitting user consent preferences and / or user consent information of the UE (e.g. location) in a secured manner such that the data manager can verify whether the user of the UE has consented to the disclosure of the information (e.g. to other network entities).

[0253] In another aspect of the invention and method, the data manager securely receives the UE's UC preferences and verifies whether the user consents to the disclosure of information. This verification may include verifying the conditions under which consent is given. In another aspect, if UC is given, the data manager discloses the UE's sensitive information (e.g., location) to a third party (e.g., the RAN or AF).

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

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

[0256] According to this method, if the HPLMN requires user consent (e.g., during identification / authentication) to disclose information (e.g., location and / or personally identifiable information) or if the UC request to the VPLMN is outside the scope of a stored UC policy, the HPLMN / VPLMN may send a UC request to the UE. The UE is redirected to a consent page where the user of the UE can select handling preferences for that request and future similar requests.

[0257] According to this method, the UE may push updates regarding changes to its UC preferences to the VPLMN (or the VPLMN may request changes). The VPLMN may be required to provide proof to the HPLMN that the UC policies have been updated. Thus, the HPLMN needs to be able to verify that the VPLMN is applying the user consent as expected (e.g., by requesting the VPLMN to provide a user consent record (i.e., UE identifiers and their associated UC policies)).

[0258] EMBODIMENT 20 In the above embodiment, the UE 100 may include fields in the message 110 indicating which fields are encrypted or integrity protected or how subsequent authentication procedures should be performed, e.g. which checks should be calculated.

[0259] This field may be, for example, a default value defined by the standard, or based on the UE version (eg, a particular release of a communications standard), or based on a security policy configured in the UE.

[0260] If the field refers to integrity / confidentiality protection of a particular field, the field may refer to a mask indicating which fields are integrity or confidentiality protected.

[0261] Whether a message is integrity protected may be determined implicitly, for example, by the presence of a MIC in the message 110 .

[0262] EMBODIMENT 21 3GPP Release 18 includes a new study item on primary authentication triggered by the home network, where the home network may trigger an authentication procedure. A possible reason for triggering this authentication could be to check if the UE has established a security link with an appropriate security level (e.g. not susceptible to MitM).

[0263] In this case, in one embodiment, the home network may send message 113 based on currently known information (e.g., identity or security capabilities) of the UE that the home network is attempting to authenticate / verify, which may require, for example, deriving new challenges xRES* and HXRES* as described above.

[0264] In other embodiments, the message may include a field indicating that it is an authentication request triggered by the home network, so that the UE knows that it needs to include some information, such as desired and / or current security capabilities, when calculating the response RES* or parameters used to calculate such a response.

[0265] Upon receiving this message, the UE may respond with message 114 containing RES* calculated as described in other embodiments, for example embodiment 1.

[0266] In a further embodiment, if the home network does not know all the UE parameters and / or wants to verify certain UE parameters, the home network may include an indication in message 113 regarding parameters (e.g. security features) that need to be retransmitted.

[0267] To allow the UE to verify that the re-authentication request is a fresh request from the home network, message 113 may include a MIC calculated using a key shared between the UE and the home network and a timer (e.g., a UTC-based counter). To allow the UE to accurately obtain the UTC-based counter used to calculate the MIC, the message may include the least significant bits of the UTC time.

[0268] Alternatively, a new message may be defined that is sent from the home network towards the UE, which message contains some of the elements above, requesting the UE to restart the authentication procedure starting with the exchange of message 110.

[0269] In a further embodiment, if the home network wishes / requires to verify the compliance of the device / UE, it may trigger a primary authentication, where the device is requested to return at least one of the following: - Device type (e.g. chipset ID), - software version, - 3GPP® features, - A fingerprint of part of the firmware (e.g. Hash / MAC / HMAC). Here, some of the above operations may be performed by a trusted module within the device (eg, the USIM).

[0270] For example, the above information may be returned by the USIM next to a MIC calculated using a shared secret shared between the UE and the home network, the shared secret being stored in the USIM so that the device / UE cannot change it.

[0271] For example, if the home network needs a fingerprint of a portion of the device's firmware, the USIM may receive that request from the home network and ask the device to fingerprint the firmware. The USIM may return the fingerprint, or an extended fingerprint calculated as a function of the previous fingerprint and some additional metadata, e.g., an HMAC of the previous fingerprint and some metadata. The metadata may include the timing required to obtain the fingerprint.

[0272] EMBODIMENT 22 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 in case of 4G to 5G mobility, the re-authentication procedure may fail even if the UE has an (already) active connection. If such a situation occurs, an updated unauthenticated status of the UE needs to be handled.

[0273] This may include one or more of the following variations: Retry the authentication procedure, e.g. a maximum number of times, or e.g. with a different authentication method (e.g. 5G AKA if EAP-AKA' failed first, or vice versa). Linking the authentication confirmation to the Nudm_UECM_Registration procedure from the AMF as described in TS33.501 clause 6.1.4.1a. In particular, the AUSF may request that in case of a home triggered authentication, the failed (or successful) authentication status is stored in the UDM. The fact of a home triggered authentication may be recorded. Also the triggering reason for the home triggered authentication may be recorded, e.g. K_AKMA update or 4G to 5G mobility. In case of authentication failure while the UE is attached, the UDM triggers the removal of all authorizations to the AMF / SEAF (similar to step 4 of TS33.501 clause 6.1.4.1a). In this case, the UDM also removes all authorizations to the AAnF and thus potentially also the AF communicating with the UE via the AKMA.

[0274] EMBODIMENT 23 When the home network triggers the re-authentication procedure, in some cases (e.g., in the case of 4G to 5G mobility), the home network may not know the 5G identity information required to obtain the security parameters from the UDM to trigger the authentication procedure.

[0275] Thus, in other embodiments, e.g. related to embodiment 1, a new message may be defined that is sent from the home network to the UE, which may request the UE to re-initiate the authentication procedure starting with the exchange of message 110. This may include re-requesting the exchange of UE security capabilities, a 5G identifier (e.g. 5G SUCI), or other fields in other embodiments, such as: - User consent preferences, - (rough) location, - parameters required for device compliance, -

[0276] In a variation, the home network (or UE) may determine that the primary authentication fails if one or more fields do not conform to certain policies that may be configured on the device and / or home network, which may trigger UE / network disassociation.

[0277] Alternatively, a decision to request a new authentication procedure may be made in the AMF. This decision may be made based on a policy. For example, if the AMF is responsible for a UE moving from a 5G network, the policy may determine whether the AMF needs to trigger a re-authentication procedure to assist the UE's home network. In this case, the AMF may request that the UE perform the authentication procedure again, starting with the exchange of message 110. This request sent by the AMF could be a NAS secure message, such as a UE configuration update or a deregistration procedure.

[0278] EMBODIMENT 24 Currently, it is not possible to update the AKMA key without re-running the authentication and key agreement phase 106. It may be necessary to update the AKMA key without doing this.

[0279] Thus, in one embodiment, this can be done by generating a new AKMA key in the AuSF that depends on, for example, the VPLMN's ID and / or a counter and / or a nonce and / or the (UTC) time. This can be achieved by extending the definition of the AKMA key derivation function given in A.2 of TS33.535 to include some of these parameters (and associated lengths) in the input string S to the KDF. For example, when the AF requests a K_AF key from the AAnF, the AF may include the required key length for K_AF in the key request. - FC=0xXX - P0="AKMA" - L0 = length of “AKMA” (i.e. 0x00 0x04) - P1=UE ID - L1 = Length of UE ID - P2=VPLMN - L2 = length of VPLMN - P3=UTC time - L3 = length of UTC time

[0280] In a variant, the newly added parameters in the above example are VPLMN and UTC time. VPLMN may be a different identifier that identifies the serving network. UTC time may be a nonce or counter that ensures that different AKMA keys are generated. As in TS33.535, the input key KEY may be a master key derived from the primary authentication (i.e., KAUSF in 5G), and the UE identifier refers to a unique UE identifier such as SUPI in 5G.

[0281] Note that in other embodiments, when updating Kakma, it may be necessary to also update Kaf, as is currently done in TS33.535, or using embodiments of the present invention.

[0282] This embodiment is shown in Figure 4, where the UE 400 performs a primary authentication and derives Kakma and Kaf in step 405 involving the AMF / SEAF 401, AuSF 402, AaNF 403, and AF 404. In step 406, the Kaf expires and the AF 404 sends a request 407 to the (serving) AaNF 403, which may forward it to the (home) AuSF in step 408. The AuSF may generate a new Kakma for the AaNF in step 409 and send it to the AuSF in step 410. The AaNF may then derive a new Kaf in step 411, which is shared with the Kaf in step 412. The AaNF informs the (home) network and the UE in step 413, and the UE and AF can again interact securely in step 414. In particular, in step 413, the serving network (AaNF) may first notify the home network of the update of the key AF, and then the home network may notify the UE of the update of the keys AKMA and AF. If the verification / reception of the message 413 is successful, the UE updates Kakma and Kaf. The message 413 may include parameters required for the UE to update these keys. The message 413 may be a NAS secure message or a message sent by the AuSF.

[0283] EMBODIMENT 25 Currently, it is not possible to update the AF key without re-running the authentication and key agreement phase 106. It may be necessary to update the AF key. This can be done, for example, by generating a new AF key in the AaNF based on the AKMA key and dependent on the AF's identity and / or counter and / or nonce and / or (UTC) time. This can be achieved by extending the definition of the AKMA key derivation function given in A.2 of TS33.535 to include these parameters (and the associated length) in the input string S to the KDF. For example, when the AF requests a K_AF key from the AAnF, the AF may include the required key length for K_AF in the key request. - FC=0xXX - P0=AF_ID - L0 = length of AF_ID - P1=UE ID - L1 = Length of UE ID - P2=VPLMN - L2 = length of VPLMN - P3=UTC time - L3 = length of UTC time

[0284] Similar to TS33.535, the input key may be a key used to derive an AF key, such as Kakma, and the AF_ID may refer to an AF identifier, which may include the security protocol used at the AF, Ua* interface, similar to TS33.535. Additionally, the VPLMN used by the AF to access the device, and / or a unique counter / nonce / UTC time may be included.

[0285] This embodiment is illustrated in FIG. 5, where the UE 500 performs a primary authentication and in step 505, the AMF / SEAF 501, the AuSF 502, the AaNF 503, and the AF 504 are involved to derive Kakma and Kaf. In step 506, the Kaf expires and the AF 504 sends a request 507 to the (serving) AaNF 503, which may process it in step 508 to generate a new Kaf and send it to the AF in step 509. The AuSF may update the Kakma (periodically) in step 510, for example based on a counter used in the KDF, and share it periodically with the AaNF. Thus, a given Kakma may be time-limited and this time-limitation may apply / propagate to the Kaf derived from it. This has the advantage that control of the home network is maintained. Once Kaf is updated, the AaNF may inform the (home) network and the UE in step 511, and the UE and AF can interact securely again in step 512. In particular, in step 511, the serving network (AaNF) may first inform the home network of the update of the key AF, and then the home network may inform the UE of the update of the key AF. 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 secure message or a message sent by the AuSF.

[0286] EMBODIMENT 26 In a related embodiment, which may be combined with other embodiments or used independently, a UE is served by a Serving PLMN (SPLMN) and the UE is attempting to access an AF in a Home PLMN (HPLMN), in which case the SPLMN may host an SAAnF that receives K_AKMA derived from K_AUSF in the AUSF.

[0287] In a variant, in some scenarios (e.g., when communications need to be intercepted for purposes of lawful interception), the HPLMN (e.g., the HAAnF) may need to send the K_AF to the SPLMN upon generation.

[0288] In another variation, the SPLMN may inform the HPLMN of this LI requirement.

[0289] In another variant, the SPLMN (eg, AMF) may use the received K_AF to access traffic exchanged between the UE and the AF.

[0290] According to the above embodiment, a method is proposed for a VPLMN / SPLMN to obtain access to traffic exchanged between user equipment (served by the SPLMN / VPLMN) attempting to access an AF in the HPLMN, the method including: the VPLMN optionally informing the HPLMN of lawful interception requirements, the HPLMN providing keying material (e.g. K_AF and other parameters) to the VPLMN, and the VPLMN (e.g. SEAF) using the provided keying material to decrypt the traffic exchanged between the intercepted UE and the AF.

[0291] According to the above embodiment, a method is proposed whereby the HPLMN provides keying material to a network function in the VPLMN that is responsible for collecting AKMA keying material for the purposes of lawful interception.

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

[0293] In this case, the VPLMN may need to intercept the communication for lawful interception purposes, which is feasible since the VPLMN knows all root keys used for communication between the UE and the AF.

[0294] Optionally, upon interception, the VPLMN may be requested to forward the decrypted traffic to the HPLMN.

[0295] In another option, the VPLMN is requested to reroute the intercepted encrypted traffic to the HPLMN and provide the HPLMN with the K_AKMA or K_AF used to protect the traffic, or the parameters (e.g., counters) used to derive them. According to the above embodiment, a method is proposed for an HPLMN to obtain access to traffic exchanged between UEs served by a VPLMN and attempting to access an AF in the VPLMN, the method including the HPLMN informing the VPLMN of the LI requirements and the VPLMN forwarding the decrypted traffic to the HPLMN or the VPLMN forwarding the encrypted traffic plus keying material (e.g. K_AKMA, K_AF, and other parameters) to the HPLMN.

[0296] According to the above method, another method is proposed that can be combined with other methods and provide keying material (eg, K_AKMA, K_AF) based on the pull / push mechanism and the LI requirements of the PLMN.

[0297] EMBODIMENT 28 In some scenarios, the home network (e.g. UDM) may be able to trigger a primary authentication procedure at any time based on local (operator) policy or upon request from an NF (e.g. AUSF, AAnF), which can 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. - Step 1: The UDM may have pre-configured local policies that determine when to trigger the primary authentication step. - 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 the SUPI, GPSI, and / or another UE identifier, to trigger a primary authentication procedure for the target UE (e.g. refresh of K_AKMA, or rekeying of other procedures such as UPU, SoR, etc.). - Step 3: Based on the received request and / or local policies, if the UDM can trigger a primary authentication, the UDM identifies the serving AMF / SEAF of the target UE, otherwise the UDM sends a Nudm_HNAuthentication_Authenticate_Response message containing the reason for failure. - Step 4: If the serving AMF / SEAF of the target UE is identified, the UDM sends a request (eg, Namf_HNAuthentication_Authenticate Request) message including the UE's identifier (eg, SUPI) to the AMF / SEAF. - Step 5: Based on the UDM's request, if the Serving AMF / SEAF can initiate the primary authentication, it sends a response (e.g. Namf_HN_Authentication_Authenticate_Response) message indicating success to the UDM, otherwise the Namf_HNAuthentication_Authenticate_Response contains the reason for failure. - Step 6: Once the serving AMF / SEAF sends a success notification to the UDM, a primary authentication procedure with the target UE may be initiated. - 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 notification to the NF that requested the home network triggered primary authentication (HONTRA). If the primary authentication was successful, the result indicates that the UE was successfully authenticated. If not, the result indicates the reason for failure (e.g. UDM or AMF / SEAF cannot trigger HONTRA or the UE failed to authenticate).

[0298] Embodiments of the present application may be applied to the above scenarios, for example to ensure lawful interception, as shown below.

[0299] In other embodiments, when the home network triggers a re-authentication procedure (e.g., to refresh the AKMA key or due to e.g. the mobility of the UE into an area served by a (different) VPLMN), if the VPLMN has signaled / signaled LI requirements, the HPLMN (e.g., AUSF) may derive in advance parameters available in the HPLMN (e.g. encryption keys, e.g. the AKMA key as described in other embodiments, and other keys that depend on e.g. the new K_AUSF) and share them with the VPLMN (e.g., AMF / SEAF / UPF or LI NF).

[0300] In other embodiments, the sharing of these keys may be performed using a NF or functional block responsible for lawful interception, which may be in a VPLMN or HPLMN.

[0301] In other embodiments, sharing may occur before the authentication procedure is complete, for example through a NAS_authentication_request.

[0302] In other embodiments, the decision to share the key early may be determined by a policy configured by, for example, a network operator.

[0303] In other embodiments, early key sharing may require a message to be sent from the HPLMN to the VPLMN indicating that a home-triggered re-authentication procedure has been performed and that the previously shared key is still valid. This message may be exchanged between the NF (e.g., UDM) that triggers the primary authentication and the NF or functional block responsible for lawful interception.

[0304] In other embodiments, the NF (e.g., UDM) that triggers the primary authentication sends a message containing the new keying material / information that has been derived or will be derived during the primary authentication to the NF or functional block responsible for lawful interception.

[0305] In other embodiments, the NF or functional block responsible for lawful interception sends a message acknowledging receipt of the keying material / information to the NF triggering a primary authentication (e.g., UDM). For example, this may happen before step 6 above, e.g., just before step 6.

[0306] In other embodiments, the NF or functional block responsible for lawful interception sends a message to the NF (e.g., UDM) that triggers the primary authentication indicating that it refuses to start the HONTRA procedure, for example because it is not ready to start HONTRA.

[0307] In other embodiments, upon receiving the above message, the PLMN (e.g., the NF responsible for LI) can perform close monitoring to determine if the old key may no longer be valid and start using the newly received keying material. This has the advantage that it does not require explicit signaling between NFs or the functional block responsible for lawful interception sends a message to the NF (e.g., UDM) that triggers the primary authentication.

[0308] In other embodiments, key agreement may be performed before primary authentication is re-triggered, which is triggered only when confirmation is received from the corresponding entity that it has received the keying material or is ready for the HONTRA procedure.

[0309] In other embodiments, the exchanged keying material / information may include at least one new root key (e.g., a new K_AUSF), a new validity period, a new key derived from the root key (e.g., K_AKMA), an expected time of HONTRA procedure execution, or a reason for the HONTRA procedure.

[0310] Additionally or alternatively, the HPLMN (e.g., UDM) may not send a Nudm_HNAuthentication_Authenticate_Response message containing a result indication to the NF (e.g., AAnF) that requested the HONTRA unless it receives a validation confirmation (e.g., acknowledgment of receipt of keying material (e.g., keys for UPU, SoR, AKMA, and / or other keys derived from K_AUSF)) from, e.g., a VPLMN (e.g., NF responsible for LI). This has the advantage that the VPLMN (e.g., NF responsible for LI) knows when to start using newly received keying material without having to closely monitor the traffic.

[0311] Early key sharing is made possible by the home network re-authentication procedure, and thus has the advantage that cryptographic keys, such as the AKMA key described in other embodiments, and other keys derived from the new K_AUSF, are available for LI as soon as possible.

[0312] When a UE, for example, wishes to establish an AKMA session with one or more AFs, regardless of the location of the AFs, the keying material (e.g., cipher keys, e.g., AKMA keys described in other embodiments and / or other keys derived from the new K_AUSF), and also the parameters used for their derivation, may be communicated to NFs (e.g., SEAF / AMF / LI NFs) in the (V / H)PLMN as soon as they are derived by the AAnF, and shared with the AFs, etc. only upon receiving an acknowledgment from the VPLMN (e.g., LI NF).

[0313] According to the above embodiment, a lawful interception method is proposed which can be implemented in a network function of a communication system, where a first network function (e.g. UDM) in a first network (e.g. HPLMN) can trigger a home network triggered primary authentication (HONTRA) only upon receiving an acknowledgement from a second network function (e.g. Lawful Interception NF), which may be located in the first or second network, that it has received keying material (e.g. a new K_AUSF and / or a key derived therefrom) and / or is ready to start a HONTRA procedure.

[0314] EMBODIMENT 29 In a related embodiment, which can be combined with other embodiments, when the AAnF is in the serving network, K_AKMA is derived from K_SEAF (defined in Appendix A.6 of TS33.501) instead of K_AUSF, so that the derivation of the new K_AKMA does not involve a root key managed by the home network, but a root key managed by the serving network and provided by the home network after being derived from the root key. When K_AKMA is calculated according to Section 6.1 / Appendix A.2 of TS33.535, K_SEAF may be used as input for the generation of K_AKMA for the serving network. That is, K_SEAF is used instead of K_AUSF.

[0315] In a related variation, K_AKMA may be derived initially as in the above embodiments, e.g. embodiment 24, or as described in TS 33.535, since K_SEAF may be removed as soon as K_AMF is derived in accordance with TS 33.501 clause 6.2.2.1.

[0316] In a related variation, if K_AKMA needs to be updated without re-performing primary authentication, a new K_AKMA may be derived by applying a key derivation function to the previous K_AKMA. Immediately after generating the new K_AKMA, the previous K_AKMA needs to be deleted.

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

[0318] Generally, the above embodiment provides an apparatus 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., nonce, counter, UTC time) and / or a serving network identifier and / or an AP identifier. In particular, the second key may 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., nonce, counter, UTC time) and / or a serving network identifier. In particular, the apparatus may (optionally) trigger key derivation of the second key and the first key, for example upon receiving a message from the core network, which message may be NAS-protected or protected with a current third key. In particular, the second key may be refreshed / updated periodically. Furthermore, the third key may be derived upon a successful authentication procedure in the home network. Furthermore, the third key may be a key distributed to the serving network upon successful authentication procedures with the home network, and the third key (e.g., K_SEAF) is derived from the fourth key (e.g., K_AUSF). Furthermore, the fourth key may be derived upon successful authentication procedures between the UE and the home network. The above embodiments provide devices that implement these apparatuses.

[0319] Generally, the above embodiment provides 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., nonce, counter, UTC time) and / or a serving network identifier, where the second key may be derived by applying a key derivation function to a third key and / or a variable value (e.g., nonce, counter, UTC time) and / or a serving network identifier, and the third key is shared between the first device and the second device, and the first device triggers key derivation of the first key and optionally the second key when the first message is received and verified. Furthermore, the method may derive a third key from a fourth key generated upon a successful authentication procedure between the UE and the home network, and share the third key with the serving network serving the UE.

[0320] EMBODIMENT 30 Based on TR33737-020, when a UE is in a VPLMN (also called SPLMN) and accesses an AF (internal or external) in a HPLMN or VPLMN, it needs to address AKMA roaming.

[0321] As described in the above embodiment, K_AKMA may be generated depending on the PLMN identifier or the SEAF, which has an important advantage to realize the requirement described in TR33737-020, namely that an AF in an HPLMN and an AF in a VPLMN may have different K_AKMA keys.

[0322] In a related embodiment that can be combined with other embodiments, If 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, an AKMA function in the VPLMN. The AKMA function in the VPLMN may then derive K_AF for the AF in the VPLMN.

[0323] If 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 K_AF for the AF.

[0324] To support lawful intercept applications, K_AKMA may be shared with the AMF / SEAF or NF of the VPLMN that may be responsible for performing lawful intercept. Sharing of K_AKMA may be performed as a push action when K_AKMA is generated, or as a pull action when the VPLMN requires a LI.

[0325] 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 may perform the derivation of K_AKMA from K_SEAF (or K_AMF) and then set K_AKMA in the AKMA network function of the VPLMN. If the AF is in the VPLMN, the AKMA network function may derive K_AF and provide it to the AF in the VPLMN. If the AF is in the HPLMN, the AF may obtain or receive K_AF from the AKMA network function in the VPLMN. Alternatively, the AKMA network function in the HPLMN may determine / obtain K_AKMA, for example, from K_AUSF and K_SEAF and derive K_AF from it.

[0326] Note that the K_AKMA used to derive K_AF for an AF in a VPLMN may be different from the K_AKMA used to derive K_AF for an AF in a HPLMN. The K_AKMA used may depend on the location of the UE. If the UE is in a HPLMN, the K_AKMA / K_AF used depends directly on the K_AUSF. If the UE is in a VPLMN, the K_AKMA / K_AF used depends on the K_SEAF.

[0327] This is illustrated in FIG. 7, where the message flows and interactions between network functions are shown. The top of FIG. 7 shows an embodiment of the network functions and messages in the bottom of FIG. 7. Entities 700, 701, 702, 703 may be in a visited (or serving) network. Entities 704, 705, 706, 707 may be in a home network. Entity 703 (e.g., an AF in a serving network) may be outside of a visited / serving network. Entity 707 (e.g., an AF in a home network) may be outside of a 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 performed after it is requested. In step 710, function 701, such as SEAF, derives a serving K_AKMA and pushes / deploys it to 702 (e.g., the serving AKMA). In step 709, the device 700 may generate a home K_AKMA and / or a serving K_AKMA as described above. In steps 711 / 712 / 713 and 714 / 715 / 716, the UE sends a session establishment request to the respective AFs in the serving PLMN and the home PLMN, triggering corresponding requests and responses in the K_AF. Upon request (717) or by default (718), the home PLMN, e.g., the home AKMA network function, may push encryption keys to the serving PLMN (e.g., the serving AKMA or SEAF / AMF) if the K_AF used by 707 (the AF in the home network) depends on the home_K_AKMA. These steps are not required if it depends on the serving K_AKMA.

[0328] This is also shown in Figure 8, where steps 1, 2a, and 4 are as defined in clause 6.1.3 of TS 33.501 and clause 6.1 of TS 33.535. If the UE is in a VPLMN, it may perform step 2b and / or step 2a. Step 2b is as defined in clause 6.1 of TS 33.535, except that a UE roaming in a VPLMN calculates: (1) K_vAKMA uses K_SEAF instead of K_AUSF as described in Appendix A.2 of TS 33.535; and (2) A-vKID is similar to A-KID in clause 6.1 of TS 33.535, except that the realm part of A-vKID contains the serving network identifier and A-vTID is used. (3) A-vTID is the same as A-TID in TS33.535 clause 6.1, except that it is derived as specified in Appendix A.3 using K_SEAF instead of K_AUSF. Step 3 is as defined in TS33.535 clause 6.1, with the same exception as in step 2b, where the SEAF in the VPLMN calculates K_vAKMA. In step 5, the UE requests an application session establishment request with A-vKID to the vAF. In step 6, the vAF discovers the vAAnF and sends a Naanf_AKMA_ApplicationKey_Get request to the vAAnF with A-vKID and AF_ID. In step 7, the vAAnF responds with a Naanf_AKMA_ApplicationKey_Get response containing the registered SN ID. The VPLMN has all the secrets to support LI when the AF is in or attached to the VPLMN. Steps 8, 9, and 10 are the same as TS33.535. In steps 11 and 12, the VPLMN may request AKMA keys for the LI (if the K_AF used by the hAF depends on KAKMA), and the HPLMN provides those keys. Note that in step 4, the HPLMN may derive K_AF depending on KvAKMA instead of KAKMA. In this case, steps 11 and 12 are not necessary, since the VPLMN knows those keys.This is illustrated in Figure 11, where only K_vAKMA is calculated by the UE, and therefore the K_AKMA used is determined only by the UE's location, and not the AF's location as above. In steps 2, 3, 4 of Figure 11, only K_vAKMA and A_vKID are calculated as above, i.e. dependent on K_SEAF. Steps 5-8 and steps 9-12 are similar to TS33.535, but K_vAKMA and A_vKID are used. In steps 13 and 14, the AMF / SEAF in the VPLMN may optionally request other security information for LI from the vAF and / or hAF (e.g. Ua* protocol, security algorithms, etc.). This request may be made to a local vAF or hAF. In steps 15 and 16, the vAF and / or hAF provide the required additional information for LI, when available or when requested.

[0329] Note that additionally or alternatively, identifiers such as A-TID, A_vTID, or keys such as K_AKMA or KvAFMA may be derived using other parameters in the KDF (e.g., AF_ID, (V / H)PLMN, or nonce) as input, as in other embodiments. This is advantageous in limiting privacy issues for the AKMA identifier (i.e., A-TID), which otherwise depends only on the SUPI and KAUSF, and may be (re)used by multiple different applications.

[0330] EMBODIMENT 31 In one embodiment, which may be combined with other embodiments, the A-KID identifier may be in the NAI format described in section 2.2 of IETF RFC 7542 [6], i.e. username@realm.

[0331] The username portion may include a RID (Routing Indicator) and an A-TID (AKMA Temporary UE Identifier), and the realm portion may include a Home PLMN or VPLMN identifier depending on the location of the AF.

[0332] The username portion may also include the serving PLMN.

[0333] This setting aims to meet the requirements of the AKMA key identifier in the roaming case, i.e. the AKMA AF must be able to identify the AAnF serving the UE from the A-KID.

[0334] Referring to FIG. 7, steps 709, 710, and 711 may involve generation of an A-KID identifier.

[0335] EMBODIMENT 32 An eavesdropper (e.g. AF1) may know that the UE is trying to establish a session with another AF (e.g. AF2) and may be able to obtain the UE's identifier (e.g. GPSI, external identifier). To this end, the eavesdropper may intercept the session establishment request (e.g. see step 1 in Figure 6.2-1 of TS33.535) directed to AF2, thus exposing the identity of the AF with which the UE is trying to contact. The eavesdropper may extract the UE's A-KID from the session establishment request. The eavesdropper may combine this with the AF_ID in the AKMA AF key request sent to the AAnF, and finally request and obtain the UE identifier (e.g. GPSI) and K_AF (different from the K_AF established between the UE and AF1). Thus, the way in which the 5G system authorizes the AKMA AF key request may result in a potential AKMA privacy violation, i.e. the UE identifier and the identity of the AF with which the UE is trying to establish a session may be exposed.

[0336] In a variation intended to address this issue, the AKMA session establishment request message may include an AF_ID to identify which AF the request is intended for. This request is sent to the CN / PLMN / NF providing the AKMA service. The request is then unicast (or simply shared) to the relevant target AF, which may then send an AF key request to the AAnF using the received A-KID.

[0337] In a related variant, since the CN / PLMN / NF knows the target AF (because the UE has shared its AF_ID), the CN / PLMN / NF (AAnF) can monitor which AFs are sending AKMA AF key requests and block / reject unauthorized requests.

[0338] In another variation, the AF_ID can be combined with the A-KID to generate an Application Capability Key Identifier (AF-KID), as shown in Figure 16. The AF-KID is in the format username@realm, where username can include: RID (Routing Indicator), and A-TID (AKMA Temporary ID), and / or AF-TID (Application Feature Temporary ID). On the other hand, the domain includes a network (e.g., a home network identifier).

[0339] If the AF-TID is an AF_ID, the variation is similar to the variation above.

[0340] The AF-TID can be derived using a key derivation function (similar to that for the A-TID) that contains the following parameters: The input key KEY may be K_AKMA, or a key derived therefrom, or a key as described in other embodiments. The parameters used to form the input S to the KDF may be a combination of multiple parameters (e.g. "AF-TID" and / or AF_ID and / or salt). If there are three parameters, it may be for example: FC=value to be defined P0 = "AF-TID" (a bit string that identifies the identifier) L0 = Length of "AF-TID" P1=AF_ID L1 = Length of AF_ID P2 = Salt (a random value used to randomize the output) L2 = Salt length

[0341] The UE may send an AKMA Session Establishment Request message including the AF-KID to the relevant AF (or may send different AF-KIDs to different AFs). The CN may store the salt if present for verification. The benefit of including the salt is that, for example, the identifier is randomized for every interaction, making it difficult to guess the identifier in multiple different requests without the salt. An alternative to a salt could be a counter, such as a time-based counter. The AF may use the identifier (i.e., the AF-KID) to identify the AAnF that provides services to the UE. The AF may send an AKMA AF Key Request to the AAnF, including its AF_ID and / or AF-KID. Upon receiving the AKMA AF Key Request message, the AAnF may strip the AF-TID part from the username, leaving the A-KID, which is used to verify whether the subscriber is authorized to use the AKMA service based on the presence of a K_AKMA linked to the A-KID. The AAnF may generate an AF-TID using the K_AKMA (or other key used as input above) identified using the AF_ID and / or salt received from the AF. This may be verified by matching it with the AF-TID received from the AF as part of the AF-KID. If the verification is performed successfully, the AAnF provides the K_AF, K_AF expTime and SUPI / GPSI to the AF, e.g. via a Naaf_AKMA_ApplicationKey_Get_response. Otherwise, the AAnF may send a Naaf_AKMA_ApplicationKey_Get with an error response.

[0342] In an alternative / additional 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 the AKMA session establishment request. The AF may use the A-KID to identify the UE it serves to the AAnF and send an AKMA AF key request including the A-KID, AF-TID, and AF_ID. The AAnF may check the presence of K_AKMA linked to the A-KID and use it (or other keys used as input above) together 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. Depending on whether the verification is successful, the AAnF proceeds as in the above embodiment.

[0343] In an alternative / additional variation, the identifier is randomized using a value such as a salt or a time-based counter, e.g., similar to the variation above. Such parameters (e.g., salt) may be transmitted and stored in the CN and not forwarded to the AF.

[0344] In other variants, the AF_ID may be combined with the A-KID itself and derived from the salt as in the variant above. This may be performed by an NF, such as the AUSF, for each AF to which the user is affiliated or for which services are provided. After the primary authentication, the AUSF may derive AKMA keying material (e.g., K_AKMA) and identifiers (e.g., a list of A-KIDs) and send them to the AAnF, with each A-KID identifying a particular AF in addition to the K_AKMA. 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 (which depends on the AF_ID) in the request.

[0345] In another related variant, the AAnF may receive an AKMA AF key request from the AF, including the AF_ID and A-KID, and send the received request (e.g., A-KID, AF_ID, and / or salt) to the AUSF. The AUSF may verify that it can calculate the received A-KID using the received parameters (e.g., AF_ID, salt). The AUSF then sends a confirmation (e.g., verification result) to the AAnF. In another related variant, the AAnF may receive an AKMA AF key request from the AF, including the AF_ID and A-KID, and the AAnF may send the received AF_ID, SUPI, and / or salt to the AUSF. The AUSF may derive the A-KID and send it back to the AAnF. The AAnF then verifies that the A-KID in the AKMA AF key request from the AF matches the A-KID received from the AUSF, and sends a response to the AF depending on the verification result.

[0346] EMBODIMENT 33 In one embodiment, which may be combined with other embodiments, the VPLMN may not want to allow a UE or AF according to Figure 7 or Figure 11, or TS33.535, to initiate an application session (e.g., Ua* protocol) as requested, for example, in message 714. Thus, messages 717 and 718 (in which the AKMA key is set in the VPLMN by the HPLMN) are executed before message 716 (in which the application key is shared with the AF, 707). The message flow is message 715 (KAF request), message 718 (KLI response to set key), message 717 (KLI set confirmation), message 716 (KAF response).

[0347] Advantageously, message 716 is not exchanged to set the KAF unless the HPLMN has received confirmation from the VPLMN regarding receipt of the AKMA key, a setting that may be stored as a policy within the HPLMN, which may have been received by the VPLMN or may be set forth in a service level agreement.

[0348] Note that an additional benefit of this message flow is that once the VPLMN sends message 717, the VPLMN knows that a new AF is starting a new application session (e.g., Ua*) and can begin monitoring the traffic. Based on the change in traffic patterns immediately after sending message 717, the VPLMN (or an NF in the VPLMN responsible for the LI, e.g., UPF) can identify the protocol flow that corresponds to the new application session.

[0349] Additionally, the application session (e.g. Ua*, e.g. TLS1.2 or TLS1.3 or DTLS) may include the exchange of additional keys required for Lawful Intercept (LI). Thus, the NF (e.g. 704, hAANF) in the HPLMN may provide those additional keys to the NF (e.g. 701, vAANF) in the VPLMN, or to another entity (e.g. AMF or SEAF) that stores the keying material for LI, as soon as the keys determined by the AF are calculated.

[0350] The sequence of messages at the beginning of this embodiment (i.e., KAF request from the AF to the HPLMN, followed by KLI request, KLI response, and KLI configuration confirmation exchanged between the VPLMN (e.g., LI NF / AMF / SEAF) and the HPLMN (e.g., AAnF), and finally the KAF response) ensures that keying material (e.g., K_AF) is provided to the VPLMN (e.g., LI NF / SEAF / AMF). The VPLMN verifies that the received keying material complies with the LI configuration requirements and sends a confirmation to the AAnF. Only after receiving the confirmation from the VPLMN does the AAnF provide the keying material to the AF for establishing a session with the UE.

[0351] According to this embodiment, a lawful interception method is proposed that can be implemented in a network function of a communication system, where 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 keying material (e.g., K_AF) and shares the keying material with a lawful interception entity (e.g., UPF, SEAF, AAnF). The lawful interception entity may be in a second network (VPLMN) or in the first network, and only if the first entity has verified that the key was correctly received does it share the keying material with the requesting entity.

[0352] EMBODIMENT 34 In one embodiment, which may 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) may send an AKMA AF key request to the HPLMN (e.g., an AAnF) and include therein the encryption parameters (e.g., encryption algorithms, encryption keys, and / or parameters for deriving encryption keys) to be used in the session established between the AF and the UE. This has the advantage that it provides the network (HPLMN and / or VPLMN) with all the key material / parameters required for lawful interception.

[0353] In alternative embodiments, the keying material / parameters may be sent in the same first message in which K_AF is requested, or in a second, separate message before / after / alongside / with the first message.

[0354] In alternative embodiments, the AF may provide these encryption keying material and / or parameters after the HPLMN has provided the AF with K_AF, for example according to procedures described in other embodiments.

[0355] With reference to FIG. 17, in a further embodiment that may be combined with other embodiments, an NF (e.g., 1701) in the VPLMN (e.g., SEAF) may verify the keying material / parameters that an AF (e.g., 1703, HPLMN AF or an external AF) is going to use to encrypt traffic in a session with the UE (e.g., 1700) before the HPLMN (1702) provides the K AF to the AF.

[0356] For example, consider the following message flow in relation to FIG. 17, where such verification is performed and where certain steps / messages are performed in an exemplary mode (i.e., steps may be performed multiple times and / or in a different order and / or may be optional). In this example, 800 may send a message, such as an AKMA Session Establishment Request, to 1703 in message 1710. Additionally, 1700 may initiate a security association (e.g., a security association for the Ua* protocol), such as initiating a handshake (e.g., a TLS handshake) with a ClientHello in message 1711. 1703 may send an AKMA AF Key Request in message 1712. Message 1712 may include the A-KID and encryption parameters (e.g., encryption algorithm, encryption / decryption key, other security parameters (e.g., nonce)) to 1702. 1701 may send a KLI request to 1702 after messages 1710 and 1711. 1701 may not be sent, or may have been sent at an earlier stage, or may be sent at a later stage. 1702 may calculate K_AF and store or send for storage some of the encryption parameters. 1702 responds with a message KLI Response (message 1714) containing K_AF and / or the encryption parameters. 1703 may send a security association message (e.g., a message of the Ua* protocol, e.g., a TLS ServerHello Response) in message 1715. 1701 (or 1702) may, for example, intercept this message and use it, for example, to verify the encryption parameters received in step 1716. The verification may be performed, for example, by checking whether the private key AF provided in message 1712 corresponds to the public key intercepted in message 1715. If the verification is successful, 1701 may send a positive response (e.g., KLI Confirmation) to 1702. If the verification is not successful, 1701 may send a failure message to 1702 indicating the problem.1702 may send an AKMA AF key response including K_AF to 1703 in message 1718. If 1702 intercepts 1715, 1702 may release it to 1700 so that the security association may be further established.

[0357] In the above scenario, the fact that message 1715 is intercepted and possibly cached / stopped has the advantage that the entity performing the interception can ensure that no communication occurs unless message 1715 is released. It may therefore be advantageous if certain messages exchanged over the communication system between the UE and the AF (e.g. messages of the Ua* protocol) have a specific field indicating that they are important messages for establishing security associations. For example, this may be the case for ServerHello responses.

[0358] Thus, in other embodiments, the entity performing the interception is configured with policies that determine which messages require interception, and the policies may be configured by a law enforcement agency that oversees lawful interception within the jurisdiction in which the communication system and UEs reside. It is further advantageous if the entity performing the interception / caching is located within the VPLMN, such that the VPLMN is independent of the HPLMN.

[0359] In the above embodiment, message 1715 is the message that is intercepted and possibly cached / stopped because message 1715 may represent a response from 1703 for the establishment of a Ua* security association. However, message 1711 may also be the message that is intercepted and possibly cached / stopped.

[0360] In the above embodiment, message 1711 is sent from 1700 to 1703 and message 1715 is sent from 1703 to 1700. However, security association messages 1711 and 1715 may also be exchanged in the opposite direction, i.e. 1711 is sent from 1703 to 1700 and 1715 is sent from 1700 to 1703.

[0361] In general, a lawful interception method is proposed that can be implemented in a lawful interception entity, e.g., a NF in a communication system, in which: - a first entity (e.g., an AF) sends a key request and security parameters to a second entity (e.g., an AAnF) in the first network; - the second entity determines a key and shares the key and security parameters with a third entity (e.g., a lawful intercept entity in the first network or the second network); - A third entity monitors / intercepts / caches messages sent from the first entity to a fourth entity (e.g. a UE) and uses it to verify the validity of the received security parameters.

[0362] In a related embodiment, - the third entity further transmits a result of the validation to the second entity; - The second entity shares the key if the validation is successful.

[0363] In a related method, the message is released from the third entity to the fourth entity only if the validation is successful. Furthermore, a lawful interception method is proposed that can be implemented in a UE, in which: - a fourth entity sends a first message (e.g., an application session establishment request) to the first entity; - the fourth entity sends a second message (e.g., a security association initial message of the Ua* protocol, e.g., a ClientHello message of TLS) to the first entity; - The fourth entity receives a third message (eg, an application session establishment response).

[0364] EMBODIMENT 35 In some cases, an AKMA may support multiple security protocols such as TLS, DTLS, OSCORE, etc. Protocols such as OSCORE or COAP are used to secure the Constrained Application Protocol (CoAP), for example. Each of these security protocols has a different purpose, for example TLS may be used in standard applications, while OSCORE may be focused on IoT devices. This increases the complexity of the NF, for example the LI NF responsible for the LI of the communication related to the AKMA.

[0365] For example, Constrained Application Protocol (CoAP) may be used between the UE and the AF, and a CoAP client (e.g., a UE) may initiate communication over the Ua* reference point and attempt to establish a DTLS tunnel with the AF. The CoAP client may inform the AF that AKMA-based authentication is supported, and the AF may select an AKMA for deriving keys (e.g., to compute a MIC and / or to encrypt traffic).

[0366] The aim is to address this increasing complexity by the following embodiments, which can be combined with each other as appropriate.

[0367] In one embodiment, an entity running LI (e.g., a LI NF in a VPLMN) may be configured with policies that determine which messages / protocols need to be intercepted and in what context. For example, as long as the OSCORE / CoAP communication flows fit the communication patterns of smart devices such as smart meters, the policy may not require processing of OSCORE-related keys, but if the communication pattern is different, e.g., if CoAP is supposed to be used for message exchange, then OSCORE-related keys need to be processed.

[0368] In a related embodiment, the policy may be set by a law enforcement agency that oversees lawful interception within the jurisdiction that the communication system and UEs reside in. It is advantageous if the entity performing the interception / caching is located within the VPLMN, such that the VPLMN is independent of the HPLMN.

[0369] In other embodiments, the entity performing the LI may inform the NF responsible for the key (e.g., UDM or AUSF or AaNF in the HPLMN) about messages / protocols that require lawful interception derived from the policy.

[0370] In other embodiments, the entity performing the LI may provide the policy to the NF responsible for the key (eg, the UDM or AUSF or AaNF in the HPLMN).

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

[0372] In other embodiments, the NF in charge of the keys (e.g., UDM or AUSF or AaNF in the HPLMN) may provide only the necessary keys to the entity performing LI according to the policy. This has the advantage that the HPLMN is not overloaded when processing keys that may or may not be required for LI.

[0373] In other embodiments, when 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 keying material (e.g., K_AF) associated with a security protocol (e.g., OSCORE or DTLS) used to protect the application communication protocol unless the HPLMN (e.g., AAnF) has received a positive response from the VPLMN (e.g., LI NF) requesting delivery of keys for this security protocol.

[0374] Referring to FIG. 17, in one embodiment, a LI NF (e.g., 1701) in a V / HPLMN may be able to derive an OSCORE security context that an AF (1703, e.g., HPLMN AF or an external AF) and a UE (e.g., 1700) attempt to establish when the CoAP security protocol OSCORE is used as a Ua* protocol between 1700 and 1703 via an HPLMN (e.g., 1702).

[0375] 17, where steps / messages are provided in an exemplary mode (i.e., some steps are performed multiple times and / or in a different order and / or may be optional), and assuming OSCORE is used as the Ua* protocol, 1700 may initiate a security association (e.g., communicate OSCORE parameters) via a CoAP request (e.g., message 1711). This request may include or replace an application session establishment request and may include at least one of the following: - CoAP method (e.g. POST) - URI of the AKMA resource on 1703 (e.g.<AF_IP_or_FQDN> / akma, where AF_IP or FQDN indicates the IP address or FQDN of the host on 1703), - Payload: CoAP security protocol identifier, A-KID, and OSCORE specific parameters N1, AF-SID, and / or OSC-NIP, where When using OSCORE, the CoAP security protocol identifier is set to the value "01", A-KID is the AKMA key identifier, N1 is the nonce generated by 1700, · AF-SID is an OSCORE sender identifier that the 1700 generates for the 1703 (to allow for short locally unique identifiers), · ?OSC-NIP is an optional parameter that indicates additional OSCORE input that 1700 may provide to 1703.

[0376] To obtain key material (e.g., K_AF), 1703 may send an AKMA AF key request in message 1712 to the NF (e.g., AAnF) in 1702. This may include the AEstablishmentRequest KID in addition to the OSCORE parameters, which may include the following: - Response code (e.g. "Created") - Payload: N2 and UE-SID (N2 is the nonce generated by 1703, and UE-SID is the OSCORE sender identifier for 1700 (e.g. UE) generated by 1703). Received OSCORE parameters (e.g. N1) may also be included.

[0377] Upon detecting a CoAP request (i.e., message 1711), 1701 may optionally send a LI request message (e.g., message 1713) before or after 1703 sends message 1712 to 1702. In response to message 1713 and / or upon receiving message 1712 (e.g., if 1701 did not send a LI request), 1702 sends message 1714 (e.g., LI response) including keying material (e.g., K_AF, salt, and other parameters) including the OSCORE parameters of 1703. 1701 may derive an OSCORE security context in step 1716 using the OSCORE parameters from 1700 (e.g., intercepted from message 1711) and the keying material (e.g., K_AF, salt, and / or other parameters) including the OSCORE parameters from 1703 (e.g., conveyed in message 1714). Only then may 1701 provide an acknowledgment message (e.g., confirmation message 1717) to 1702, which can then provide the keying material (e.g., K_AF) to 1703 in message 1718 (e.g., AKMA key response) for deriving the OSCORE security context.

[0378] In response to message 1711 (e.g., CoAP request), 1703 may send message 1715 (e.g., CoAP) including 1703's OSCORE parameters (e.g., response code, N2, UE-SID). 1701 may intercept message 1715 and verify that the OSCORE parameters it contains match the OSCORE parameters received in message 1714. If the verification is successful, 1701 may forward message 1715 to 1700, which may derive the OSCORE security context at that stage.

[0379] In a related embodiment, message 1715 (e.g., CoAP response) may be sent to 1700 before the AKMA AF key request (e.g., message 1712) is made, in which case 1701 may intercept and cache / stop message 1715 until it has derived the OSCORE security context. If other parameters are needed to derive the context, 1701 may indicate which parameters are needed in message 1713 (e.g., LI request), and once provided in message 1714 and verified in step 1716, 1701 may send an acknowledgement message (e.g., 1717) to 1702. 1702 may then provide the keying material (e.g., K_AF) to 1703.

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

[0381] According to the above embodiment, an apparatus and method are proposed in which an NF (e.g., UDM, AUSF, or AAnF) responsible for keys and / or key derivation in a first network (e.g., HPLMN) is configured (e.g., via policy) by a lawful interception entity / NF located in the same network or in a second network (e.g., VPLMN). The configuration / policy determines the context, protocols (TLS, DTLS, OSCORE, etc.) and / or messages (e.g., AKMA-specific) that require interception.

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

[0383] EMBODIMENT 36 It is possible that during an ongoing Ua* session between the AF and the UE, the K_AF may expire and therefore require a refresh (e.g. by triggering a home-triggered primary authentication). In such a situation, the keying material is updated and the ongoing Ua* session must continue as normal and lawful intercept requirements must be met. To address this situation, the following embodiment, which may be combined with other embodiments, may be applied.

[0384] In a first embodiment, the AF may request a new KAF from the HPLMN (e.g., AAnF), which may include 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 a LI setup confirmation from the VPLMN. Upon receiving the keying material (e.g., KAF and security parameters) from the HPLMN, the VPLMN (e.g., LI NF / SEAF) may verify whether the provided keying material (e.g., KAF and security parameters) meets the LI setup requirements, and if so, send a confirmation to the HPLMN. The HPLMN then provides the new K_AF to the AF.

[0385] In a further embodiment, 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 for encryption of the Ua* session. The AF may need to notify the HPLMN (e.g., AAnF) by a message such as a request for a new K_AF and provide new security parameters (e.g., encryption algorithms, encryption / decryption keys, and other parameters (e.g., nonce, counter)). The provision of the new K_AF and / or the approval to use the new security key for encryption depends on the positive response of the VPLMN (e.g., LI NF / SEAF). That is, 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 AF with the new K_AF and / or provide approval to update the security keys.

[0386] 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. This request may be intercepted by the VPLMN and used to verify whether the security parameters sent by the AF in the request (e.g., key update request) to the HPLMN are sufficient to meet the LI requirements of the VPLMN (i.e., to allow the LI NF in the VPLMN to decrypt the traffic). If so, the VPLMN may verify the security parameter update request and send a confirmation to the HPLMN (e.g., AAnF), which forwards it to the AF.

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

[0388] Some embodiments are described as having a VPLMN and an HPLMN. However, in some cases, there may be a single network (e.g., HPLMN). In this case, the first NF (e.g., AAnF) in the HPLMN may send the K_AF to the AF only after the encryption key / K_AF is configured in the second NF (responsible for lawful interception) in the network and a confirmation / acknowledgement is provided to the first NF.

[0389] In some embodiments, the description is given in terms of a lawful interception NF, which can also be understood without loss of generality as a lawful interception entity that may be part of the NF or that may interact with the (core network of) the communication system. In general, different ways are proposed by which the VPLMN can verify and authorize updates of security parameters (e.g., encryption keys, K_AF) during an ongoing Ua* session between the AF and the UE. In this method, the AF sends a request to an NF (e.g., AAnF) in a first network (e.g., HPLMN) to request approval to update / refresh security parameters (e.g., encryption key, K_AF), the first network (e.g., HPLMN) forwards the request to an NF (e.g., LI NF / SEAF) in a second network (e.g., VPLMN), the second network verifies that the new security parameters meet the LI requirements (i.e., provide a means to decrypt traffic) and sends a confirmation to the first network, and finally, the first network sends the new K_AF and / or approval for the key update to the AF.

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

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

[0392] EMBODIMENT 38 In one embodiment, which can be combined with other embodiments, a first network (e.g., HPLMN) sends AKMA-related parameters, such as K_AKMA and / or AKMA indication and / or routing indicator, to a second network (e.g., VPLMN), so that the second network knows whether the UE supports the AKMA service and how to handle the AKMA service.

[0393] For example, when the first network provides K_SEAF (or K_AKMA) to the second network after the primary authentication, an entity in the first network that handles the UE's long-term credentials / policies / subscriptions (e.g., the UDM in the HPLMN) returns AKMA-related parameters to the NF in the second network. This can be performed by the UDM, but may also be performed using the "Nudm_UEAuthentication_Get service operation" service (clause 14.2.2 of TS33.501). This service may, for example, return (1) the SUPI if the SUCI was used as input, (2) depending on the authentication method, authentication data for the SUPI (e.g., the AKA authentication vector), or (3) an AKMA indication and a routing indicator if the subscriber has an AKMA subscription according to TS33.535.

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

[0395] In further embodiments, which may be combined with other embodiments, for example, the UE may provide one or more AKMA-related parameters to the VPLMN if or when the VPLMN indicates support for the AKMA service.

[0396] In a further embodiment, which may be combined with other embodiments, for example, the UE may receive one or more AKMA-related parameters from the VPLMN if or when the VPLMN indicates support for the AKMA service.

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

[0398] In one embodiment, the routing indicator to use when the UE is roaming is a default routing indicator, so there is no need to communicate the routing indicator to the VPLMN and the UE that knows it is roaming can select it. In this case, the AAnF NF consumer can select any AAnF instance in the VPLMN.

[0399] In one embodiment, the routing indicator that a UE from a HPLMN uses when roaming is the default routing indicator associated with the HPLMN, so there is no need to communicate a routing indicator to the VPLMN and a UE that knows it is roaming can select it, in other words all UEs in the HPLMN use the same AAnF in the VPLMN associated with the HPLMN.

[0400] EMBODIMENT 39 In a further embodiment, which may be used independently or in combination with other embodiments, the VPLMN may provide AKMA services, but the HPLMN may not provide AKMA services.

[0401] Deriving AKMA keys in the VLPMN from keys such as K_SEAF is beneficial because it allows AKMA services to be implemented in the VLPMN even if the HPLMN does not implement such services.

[0402] Alternatively, even if the HPLMN itself does not provide an AKMA service, a function may always be available in the HPLMN that allows it to derive K_AKMA (such as TS 33.535). This function may reside, for example, in the AUSF or UDM. K_AKMA may be provided to the VPLMN together with K_SEAF.

[0403] The HPLMN may also indicate to the VPLMN that the device is an AKMA-capable device, regardless of whether the HPLMN itself supports the AKMA service, allowing the VPLMN to provide the AKMA service if it supports it.

[0404] The UE may indicate to the VPLMN that it is an AKMA-capable device, regardless of whether the HPLMN itself supports the AKMA service, so that the VPLMN can provide the AKMA service if it supports it.

[0405] The VPLMN may provide the AKMA configuration parameters to the UE securely, for example via a NAS message or protected by a VPLMN AKMA specific key, as in other embodiments.

[0406] The VPLMN may provide an indication of support for AKMA services to the HPLMN, allowing the HPLMN to provide the necessary parameters to the VPLMN only when requested.

[0407] In a specific example of this embodiment, if the VPLMN provides the AKMA service, in accordance with section W.4.1.3 of TS33.501, the VPLMN may enable the UE to authenticate to the MBSTF based on the AKMA (e.g., to register for MBS services and receive MBS traffic) if the HPLMN does not provide the AKMA service, while the UE in the HPLMN may use the GBA.

[0408] EMBODIMENT 40 An authentication proxy (AP) is an HTTP proxy that serves as a network authentication function for the UE. The AP performs a TLS security connection with the UE so that the application server (AS) does not need to be involved. The AP can assure the AS that the request is sent from an authorized UE. The AP is useful, for example, because it can reduce the consumption of authentication vectors. By introducing the AP in the AKMA, different application functions in the AKMA in the same trust domain or edge node can rely on the AP to perform the AKMA procedure. Thus, in the above embodiment, the AP may be located, for example, between the AF and some other network function (e.g., AaNF or AuSF). In that case, the AP may process Kaf on behalf of Afs. Since multiple Afs (in a common security domain) are behind the same AP, a single user plane interface between the UE and the AP may be required. Furthermore, the key derivation function used to derive Kaf or Kakma may include a parameter to identify a given AP. In particular, there may be a Kap that can be generated in the same manner as above on behalf of an Af in the same security domain behind a common AP. In particular, Kap may be associated with an Af in the serving PLMN or the home PLMN. Referring to Figure 7, entity 703 may be an AP in a serving PLMN that serves an AF in the serving PLMN. Referring to Figure 7, entity 707 may be an AP in a home PLMN that serves an AF in the home PLMN.

[0409] The AP may also play a role in Lawful Interception (LI). This may be especially the case when the AF is external to the HPLMN and the UE is in the VPLMN. The reason is that for LI, all necessary exchanged data needs (or may need) to be shared with the VPLMN. Thus, an external AF that requires AKMA security may (may need) to be performed via an AP in the HPLMN. This may be policy based. For example, if the external AF refuses to exchange encryption keys, the (operator of) the HPLMN may deploy and enforce a policy of the services that the AP provides to that AF in the HPLMN. Additionally or alternatively, in a first variant, the AP in the HPLMN may (should) share the AKMA / AF keys and other necessary parameters (e.g., Diffie-Hellman keys, encryption algorithms, protocols) with the VPLMN (e.g., AMF / SEAF of the VPLMN). This allows the appropriate NF (e.g., UPF) in the VPLMN to perform the decryption of the data, if necessary. Additionally or alternatively, in another variation, the AP may share data with the VPLMN (data decoded at the AP before being further exchanged with the AF). This is possible because the AP acts as a middlebox used for LI at the HPLMN and shares data with the VPLMN.

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

[0411] Note that if K_AF depends on K_SEAF, the VPLMN can directly derive K_AF without the assistance of the HPLMN as described in the above embodiment, but the HPLMN still needs to support the VPLMN for LI obligations by providing other parameters required for decoding at the VPLMN.

[0412] For LI, it is / may be necessary to exchange all information necessary for decryption, or even the decrypted data itself. This may include K_AF, other keying material (e.g., Diffie-Hellman key), the selected security algorithm, etc.

[0413] Note that the AP has an additional advantage with respect to LI, since less information (eg, encryption keys) needs to be shared and eavesdropping itself may be simplified.

[0414] According to the above embodiment, a method is proposed for a VPLMN having lawful interception requirements to obtain access to traffic exchanged between a UE served by the VPLMN and an AF that is outside the range of the HPLMN and served by an authentication proxy (AP). The method includes the AP providing keying material (e.g., K_AKMA, K_AF, and other parameters) to an NF (e.g., SEAF) in the VPLMN. Then, an NF (e.g., UPF) in the VPLMN decrypts the intercepted traffic exchanged between the UE and the AF. Alternatively, the AP may decrypt the traffic exchanged between the UE and the AF and forward it to the VPLMN.

[0415] EMBODIMENT 41 In 3GPP, a new component, the network-controlled repeater, is under development. In 3GPP networks, the repeater is a device used to supplement areas that are not well served by the base station. Functionally, it is a simple bidirectional amplifier that forwards uplink and downlink signals between one antenna pointed to the base station and another antenna pointed to areas with poor coverage. An exemplary application scenario is the use of repeaters to extend outdoor coverage to indoor locations (O2I). In this scenario, UEs inside a building cannot establish a direct link with the base station due to the building materials used in its construction. To provide better service to UEs inside the building, repeaters can be used to forward signals from outside to inside or vice versa. Repeaters are simply amplifiers and do not modify the signals that pass through them. They are said to be transparent with respect to the traffic forwarded through them. Compared to more complex concepts such as Integrated Access and Backhaul (IAB), repeaters provide a simple and cost-effective solution for simple cases. A drawback of current repeaters is that the amplifiers are always running, even when there is no traffic to relay. This can cause excessive noise in the repeater's coverage area, since any in-band signal or noise that arrives at the downlink input is repeated, whether it is a valid signal or not. Base stations can also have similar problems in the uplink. In principle, if some of the repeater's behavior could be controlled by the base station, the overall performance of the repeater installation could be improved. As a simple example, the amplifiers may be switched off when there are no signals to forward. The base station has full control over the schedule of both uplink and downlink transmissions, so that the amplifiers can be turned on only when necessary. 3GPP Release 18 started the development of network-controlled repeaters (NCRs) that operate in exactly such a way.In addition to the forwarding module (NCR-Fwd), the NCR includes a mobile termination (NCR-MT) module that controls the operation of the NCR according to instructions from the gNB. The conceptual model is shown in Figure 5-1 of TR38.867v1.0.0. Data traffic is forwarded via the backhaul (gNB-NCR) and access (NCR-UE) links. Meanwhile, a control link is established between the gNB and the NCR-MT module, through which the gNB sends instructions to the NCR-MT regarding the desired repeater operation. In addition to controlling the amplifiers, the ability to control the repeaters allows additional functions such as beamforming at the access antennas. Such functions can be used to further improve performance.

[0416] The NCR-MT generally behaves similarly to a UE in terms of the control plane protocols used, but uses new signaling to control the operation of the repeaters. Another aspect in which the NCR-MT may differ from a UE is the NCR identification and authentication steps required when the NCR is first installed in the network. Several proposals are outlined in TR38.867v1.0.0, and these are briefly summarized here.

[0417] Proposal 3 (similar to IAB, section 8.1.3 of TR38.867v1.0.0) and Proposal 4 (similar to RedCap, section 8.1.4 of TR38.867v1.0.0) are similar to each other and to the procedures used for conventional UEs. The usual steps used by the UE are followed by an initial step where the NCR-MT establishes access to the gNB and the NCR-MT. In Proposal 3, during this process, the NCR-MT indicates that it is an NCR and not a UE. The next step involves the use of the network-based Access and Mobility Function (AMF) to authorize the NCR-MT as an NCR and establish link security.

[0418] These proposals have the advantage of using well-established protocols as a basis, which can be modified to support NCR if necessary, but may also require modifications to the core network (AMF), which complicates deployment compared to legacy repeaters.

[0419] In proposal 1 (clause 8.1.1 of TR38.867v1.0.0), link security is established using the AMF, but authorizes the NCR as the UE. Thus, no changes are required in the core network. If the NCR provides the gNB with appropriate credentials, an additional check on the validity of the NCR is performed by the gNB.

[0420] Proposal 2 (Section 8.1.2 of TR38.867v1.0.0) replaces the AMF with an Operations and Maintenance (OAM) module that is part of the Radio Access Network (RAN) rather than the core network. Because link security is not established by the CN, link security must be established by the OAM to ensure that NCR control traffic is not sent in the clear. The proposal description indicates that "security for OAM traffic can be provided by application layer security mechanisms such as SSH / TLS between the NCR and OAM."

[0421] The following disclosures propose authentication and identification methods that prevent, for example, naive UEs from spoofing the NCR or prevent MitM attacks. These disclosures may be applied to Proposal 2, where link security is not established by the core network. They may also have relevance for other methods where a secure link can be established, but further validation of the NCR needs to be performed without the help of the network. Proposal 1 shows one possible process. It is also noted that the disclosed methods are not limited to scenarios where the device connected to the network is the NCR, but may also be applicable to other situations where authentication and validation needs to be performed without the assistance of the CN.

[0422] Figure 14 shows a typical deployment where an NCR currently serves a single UE. The NCR may be owned by a first network (Network1). The NCR may connect via RANs of the first or second network (Network2), i.e., RAN1 and RAN2. The RANs may interact with the corresponding AMF / SEAF. Primary authentication of the NCR-MT is performed using the AUSF / UDM of Network1. A management entity, e.g., an Application Function (AF) or OAM, may manage the configuration of the NCR. This AF may be AF1 if it is in Network1, AF2 if it is in Network2, or AF3 if it is elsewhere.

[0423] EMBODIMENT 42 In a first embodiment, focusing on a simplified deployment of NCRs where a single NCR connects to a single gNB, the NCR is owned by the operator and deployed at a fixed location to serve a specific gNB. In such an embodiment, security credentials are preloaded on both sides of the link and indexed at the gNB by identifiers, which are shared with the NCR. These credentials can range from a complete set of security keys to a shared secret that can be used to derive all security keys. There are various ways to generate and share such credentials. A simple example of a shared secret is a QR code or security PIN that is given to a home Wi-Fi router. Entering this into a PC, phone, or other device gives both the device and the router a shared secret from which further security credentials can be securely derived using protocols such as TLS.

[0424] EMBODIMENT 43 In other embodiments, the NCR becomes a network component with more flexible deployment opportunities. For example, in one type of embodiment, the NCR is owned and operated by an entity other than the network operator. For example, in the previous example, it could be owned by the building owner. In yet another embodiment, the NCR is used to provide fill-in coverage to multiple networks simultaneously, i.e., the NCR is shared by two or more networks. In such an embodiment, it is not necessarily practical to pre-load the necessary security information on both sides, and an alternative method of securely establishing a shared secret is required.

[0425] One type of method that can do this is based on public key cryptography. These methods use asymmetric cryptography to exchange enough information to derive a shared secret. Since only the public key is available, a third-party device without 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. One well-known algorithm that uses this method is the Diffie-Hellman key exchange.

[0426] This embodiment relies on a security mechanism based on EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). EAP-TLS is defined in RFC5216 and forms the basis of the WPA2 security used in Wi-Fi. An overview of the EAP-TLS process is shown in Figure 15 (Reference: David D. Coleman, David A. Westcott, Bryan Harkins, "CWSP: Certified Wireless Security Professional Study Guide CWSP-205", Wiley, Second Edition, September 16, 2016, DOI: 10.1002 / 9781119419341).

[0427] A device wishing to access the network (called a supplicant in EAP terminology) first establishes a data link with the authenticator and informs the authenticator of its identity. The authenticator then informs the authentication server that the supplicant is requesting access, and the authentication server provides mutual authentication by exchanging certificates with the supplicant. If this is successful, the authentication server notifies the authenticator, and the authenticator performs a four-way handshake to securely establish security keys on both sides of the link. Once this process is successfully completed, the supplicant and authenticator can establish a secure channel for data transfer.

[0428] In the NCR scenario, the NCR plays the role of the supplicant, the gNB plays the role of the authenticator, and the OAM plays the role of the authentication server. This is suitable because it allows the OAM to serve multiple gNBs that make up the radio access network, and it allows flexibility in the deployment of the NCR in case the OAM also serves to inform the gNBs of the NCR capabilities. To support operation across multiple RANs, the OAM may be located deeper in the network, or OAMs belonging to different RANs may communicate with each other to share information about the NCR. In FIG. 14, the RANs may directly communicate with one or more OAMs, represented as AF1, AF2, and AF3 in FIG. 14.

[0429] Meanwhile, the gNB is responsible for the day-to-day operation of the NCR and can obtain the necessary configuration information from OAM or from the NCR itself without the need to pre-load it.

[0430] Since EAP-TLS was developed for operation in WLAN, there may be some differences in the details between a WLAN implementation and a similar mechanism adapted for operation in 5G. For example, protocols other than RADIUS may be used in the interaction between the gNB and the OAM. EAP-TLS expects certificates based on X.509, but other formats for certificates may be appropriate.

[0431] Other changes may reflect different perceived levels of security required. For example, in a WLAN environment, it is important that both sides can authenticate each other. In the case of NCR, it is important that the RAN can authenticate the NCR, but since the rewards of unauthorized access to the NCR are limited, it may not necessarily be important that the NCR can authenticate the RAN. In particular, user data is not decrypted by the NCR and therefore cannot be exposed to malicious users.

[0432] Some of these variations may also be reflected in other variations of EAP, and therefore, although this discussion is provided in the context of EAP-TLS, it should not be considered limiting in this regard.

[0433] An authentication and authorization procedure, such as the EAP-TLS procedure described above, may be included in step 7 of Figure 8.1.2-1 of TR38.867v1.0.0. Successful authentication and authorization results in message 8 in the figure. This message may include a key K that is shared with the NCR (NCR-MT) based on the authentication and authorization procedure. Thus, subsequent control messages sent from the gNB to the NCR-MT are protected. This key may be used to protect standard RRC messages extended by NCR-specific control fields. Alternatively, this key may be used to protect specific L2 or L1 messages, for example as shown in the above embodiment.

[0434] The use of such a key K in combination with RRC messages or L2 or L1 messages may be used to protect traffic in other embodiments.

[0435] EMBODIMENT 44 In a related embodiment, the specific keying material is securely configured in the NCR during manufacture. The OAM may obtain the specific NCR from the manufacturer and securely receive pre-configured keying material from the manufacturer. The pre-configured keying material may be used in the (EAP-based) authentication and authorization procedures described above.

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

[0437] In a related embodiment, the keying material is stored in a USIM for an NCR mobile terminal.

[0438] EMBODIMENT 45 In the current solution of TR38.867v1.0.0, the NCR-MT exposes its capabilities before the security context is established. Therefore, these security capabilities may change. For example, NCR indication information is exposed in the RRCSetupComplete message. Some solutions, such as solution 1, include an NCR validation phase (steps 12 and 13 in Figure 8.1.1-1 of TR38.867v1.0.0) once AS security is established, while others do not. Therefore, it would be beneficial if parameters that need to be exchanged at an earlier stage, such as RRCSetupComplete, were already protected at that stage (for example, as is done in the above embodiment with UE security capabilities).

[0439] EMBODIMENT 46 In solution 1, the gNB may perform an additional NCR verification, which can be done by checking if the NCR notification received in the RRCSetupComplete matches with information stored locally in the gNB, but it is not described how this information can be configured. In a first alternative, the NCR may act as a radio repeater for a gNB operating in non-standalone (NSA) mode. In this case (e.g. solution 1), the UE part of the NCR may perform an authentication procedure with the LTE core network. Once the UE part of the NCR is authenticated, the LTE CN can check the user subscription of the UE and inform the eNB of the result. If successful, the UE part of the NCR may prepare for a handover to an NCR-capable gNB and perform additional NCR validations. In this way, the NCR can be used on an NSA network without modifying the LTE CN.

[0440] EMBODIMENT 47 In solutions such as solutions 3 and 4, it is stated that the AMF and other CN entities perform further authentication and that the AMF then provides the gNB with "NCR authenticated". However, it is not described how this is done. Another embodiment that achieves this / describes how this is achieved, for example in the context of solution 3, is the following: When the gNB sends an INITIAL UE MESSAGE to the AMF containing NCR indication information in message 9 of figure 8.1.3-1 of TR38.867v1.0.0, the AMF must forward the information to the AUSF. The AUSF then obtains the SUPI of the NCR-MT and obtains the data associated with the SUPI(NCR-MT) regarding its capabilities. The AUSF may obtain the data, for example, from or by interacting with the UDM, UDR, PCF, or other network functions. If these functions do not match, the AUSF may decide to stop the authentication process.

[0441] EMBODIMENT 48 In a related embodiment, the UE part of the NCR may first perform a primary authentication procedure, and if successful, the AMF may obtain the associated UE's user subscription capabilities from the AUSF / UDR and verify that the UE is NCR as claimed in the received NCR indication. If the claim is correct, the AMF provides an "NCR approved" indication to the gNB.

[0442] EMBODIMENT 49 Solutions such as solutions 3 and 4 state that the AMF and other CN entities perform further authentication, which requires the gNB to select an NCR-enabled AMF in additional embodiments.

[0443] EMBODIMENT 50 When authenticating with the NSA network, e.g. in solution 3 or solution 4, the UE part of the NCR may perform an authentication procedure with the LTE core network. Once the UE part of the NCR is authenticated, the LTE CN may verify the user subscription of the UE and verify if it is an NCR. If so, the LTE CN may inform the gNB, e.g. via the eNB, and the gNB may store the capabilities of the UE part of the NCR. Once this is done, the UE part of the NCR may send a secure message (e.g. RRCSetupComplete) indicating its capabilities. The gNB may verify these capabilities by comparing them with previously received capabilities. 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.

[0444] EMBODIMENT 51 Another embodiment that addresses the needs of other embodiments is to protect the initial NCR indication information as described in the above embodiment, for example by a primary authentication procedure or by protecting it with the public key of the home network.

[0445] EMBODIMENT 52 An external AF may be responsible for at least partial management of the NCR. For example, if the NCR is deployed in a private building, the building owner may want to determine when the NCR in the building is active, which areas need more coverage, etc. This external AF may manage the configuration of the NCR using the AKMA as described in TS33.535. In this case, the AF may use the AKMA-derived key to set up a secure channel protected by the Ua* protocol and configure certain parameters in the NCR. This can also be applied in situations where the NCR-MT is roaming as described in the above embodiment.

[0446] EMBODIMENT 53 Yet another embodiment applicable to the above solution is to configure the UE, i.e., NCR-MT, with an authentication token (e.g., a set of properties associated with the UE, e.g., the fact that the UE is an NCR-MT). This configuration may be performed in the NCR-MT before deployment, or may be securely transmitted to the NCR-MT after the NCR-MT has successfully completed the authentication and authorization procedure as in embodiment 5c. The next time the NCR-MT attempts to join another gNB, the NCR-MT will share such token with the gNB, allowing the gNB, or a network function in the CN, to verify the authentication of the NCR-MT.

[0447] EMBODIMENT 54 In yet another embodiment, once the NCR is authenticated and authorized, for example as described in the above embodiment, the NCR may send or receive its configuration and capabilities. The configuration may refer to the configuration as described in section 7.2 of TR38.867, and may include one or more configurations of PHY channels for carrying L1 / L2 signaling (including configurations for receiving PDCCH and PDSCH, for transmitting PUCCH as required, or for transmitting PUSCH as required), and configurations of L1 / L2 signaling (including configurations of DCI, UCI as required, and MAC CE as required). The capabilities may include parameters as shown in the following table. One or more of these parameters may be exchanged and stored. [Table 1] TIFF2025515724000003.tif110140

[0448] EMBODIMENT 54 The above management solutions may coexist, in which case it may be necessary to move / roam / export / import NCR data from one management system to another. For example, in solution 2, OAM may store information about deployed NCRs, their capabilities / configuration, encryption keys, authentication status, etc. If one or more NCRs need to be migrated to another solution (e.g. solution 3), data must be exchanged and stored in the corresponding entities (e.g. network functions in the core network, AMF, UDM, UDR, etc.). This data may be exchanged via the NEF.

[0449] EMBODIMENT 55 Once the NCR is authenticated and authorized, one or more of the above NCR capabilities must be configured in the gNB, which the gNB can use to determine how to connect to the NCR and how to optimize the control or forwarding links.

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

[0451] In other embodiments, 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 securely and proactively send these 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. The management entity (AF) may retrieve the NCR capabilities, for example, from a database, after authenticating the NCR. After authentication and authorization, the management entity may share one or more NCR capabilities with the gNB.

[0452] EMBODIMENT 56 The above embodiments (e.g., related to NCR) may also be applied to Mobile Base Station Relays (MBSRs) or Vehicle-mounted Relays. The service requirements for these relays are studied in TR 22.839 and specified in TS 22.261. MBSR refers to a mobile base station (e.g., a mobile IAB node) mounted on a vehicle such as a bus, a drone, or a satellite. The MBSR may move as needed to provide enhanced connectivity. The MBSR may be owned by a third party or may roam to a network to which the MBSR does not subscribe. This differs from existing IAB architectures, which assume that the IAB node is owned and operated by the same PLMN as the PLMN to which the IAB node has a subscription.

[0453] EMBODIMENT 57 In one scenario, the UE part of the MBSR (corresponding to the IAB-MT of the IAB) may be registered in the network, e.g., in the HPLMN as usual (e.g., by primary authentication) via a gNB managed by the VPLMN. The VPLMN may be seeking the services of the MBSR. The question that arises in this situation is how to allow the VPLMN to use the MBSR. This concerns the authorization of the HPLMN or the owner of the MBSR to allow the VPLMN to use the MBSR.

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

[0455] In one embodiment, the gNB, or an NF in the network (e.g., VPLMN) may know that the UE portion registered is part of the MBSR, which may require the gNB to send a message to the CN or VPLMN OAM informing it of this fact and / or to the entity responsible for the MBSR (e.g., the HPLMN, a third party, or an OAM in the HPLMN) requesting the use of the MBSR.

[0456] In one embodiment, the network (e.g., VPLMN) may need additional resources and may send a request to the MBSR owner with its requirements (e.g., location where additional connectivity is needed, type of service, etc.). The network may send a request to the NF (e.g., AMF) and / or RAN indicating that the new MBSR unit may join / register in the network.

[0457] In one embodiment, an AMF in a network (e.g., VPLMN) may use a message (e.g., NAS message) to provide the MBSR with the credentials used to connect to the network (e.g., VPLMN) OAM, allowing the MBSR to obtain configuration parameters (e.g., assigned PCI, beam configuration, etc.) for that network (e.g., VPLMN).

[0458] In one embodiment, an AMF (or other NF) in a network (e.g., VPLMN) can use a NAS message to provide the MBSR configuration parameters (e.g., which PCIs are assigned to the MBSR, MBSR beam configuration, etc.) for the network (e.g., VPLMN) to the MBSR. The AMF may obtain this information from the VPLMN OAM.

[0459] In one embodiment, a gNB central unit (CU) in the network may provide the MBSR configuration parameters (e.g., PCI assigned to the MBSR, MBSR beam configuration, etc.) for the network (e.g., VPLMN) to the MBSR using a configuration message. The gNB-CU may obtain this information from the network OAM.

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

[0461] In a related embodiment, the request to the HPLMN or AF may include the required services requested from the MBSR, which may include the location or timing at which the services are required, etc.

[0462] In one embodiment, the MBSR accepts the above security credentials / configuration parameters only if it receives a positive confirmation from the HPLMN or AF responsible for the MBSR or MBSR owner regarding providing service to the network. This confirmation may be based on a protected message (e.g., an integrity protected message) sent from the HPLMN / AF to the UE in an end-to-end protected manner.

[0463] In a related embodiment, the protected message may include a configuration including details of the MBSR indicating services that may be provided by the MBSR to a network (eg, a VPLMN).

[0464] In a related embodiment, this protected message may be protected end-to-end from the HPLMN to the UE by a UE Parameters Update (UPU) in accordance with clause 6.15.2.1 of TS33.501.

[0465] In a related embodiment, the MBSR may belong to a third party that manages the MBSR through an AF that connects to the MBSR by an AKMA. In a related embodiment, protected messages are exchanged between the AF and the MBSR via the Ua* interface.

[0466] In a related embodiment, an NF in a VPLMN may contact an NF in an AF or HPLMN, and the latter may send the above-mentioned Confirmation / Configuration Parameter message and other configuration parameters to the MBSR.

[0467] In a related embodiment, the MBSR belongs to a third party, and the MBSR and the third party authenticate via secondary authentication, and upon successful secondary authentication, configuration parameters are securely exchanged over an EAP connection.

[0468] In a related embodiment, the MBSR is configured with an authentication token that is securely provided by an entity that manages the MBSR, and may be configured with policies that determine the (types of) networks that the MBSR will access and provide connectivity services to.

[0469] In a related embodiment, the MBSR may be configured with a unique authentication token and / or may share an authentication token with other MBSRs, and may be configured with its own policy or may share the same policy with other MBSRs, which determines the (type of) network that the MBSR can access and provide connectivity services to.

[0470] In a related embodiment, the MBSR sends an authentication token to the network, which allows the network to verify the credentials / authentication authority to provide the MBSR service to the network. The entity that verifies the credentials may be, for example, the gNB-CU or the AMF.

[0471] In a related embodiment, a third party managing the MBSR provides an authentication token to a network willing to use the MBSR. The authentication token determines the access rights (services) that the network will request from the MBSR for which the service is sought when the authentication token is published to the MBSR. In this manner, a network can acquire / purchase a number of authentication tokens and use them as needed.

[0472] In a related embodiment, the MBSR may need to send the "used" token to a third party so that it can be marked as used. The "used" token is stored in a list of "used" (or expired) tokens shared by all MBSRs, allowing the MBSR to verify that the received token is valid or still valid.

[0473] In a related embodiment, the tokens may have a shorter validity period, i.e., they are only valid for a short period of time, and a revocation list may not be necessary.

[0474] In a related embodiment, the MBSR and the network exchange authentication tokens over a secure interface, such as an RRC message, or over the F1-C interface, or over a NAS message.

[0475] In a related embodiment, the network may send a (secure) confirmation (e.g., an authentication token) that acknowledges that the service is being provided by the MBSR, which may be shared with the MBSR owner for billing purposes.

[0476] The above embodiments can be combined with each other as necessary.

[0477] The above embodiments relating to smart repeaters and MBSRs are also generally applicable to other types of network access devices, such as smart repeaters, MBSRs, Unmanned Aerial Vehicles (UAVs), satellites, and Reflective Intelligent Surfaces.

[0478] Generally, a method and apparatus are described that can be implemented in a (mobile) network access device for processing authorization to provide a service to a network, the apparatus comprising: - configured with policies that determine the conditions under which a device can connect to the network and an access token for connecting to the network; - If the conditions are met, it establishes a (secure) connection with the network, - Sending an access token to the network as proof of authorization. - The device may receive an authentication token from the network to prove service provisioning for billing purposes.

[0479] EMBODIMENT 58 In TR33.870, v0.4.0, privacy of identifiers exchanged over radio access networks is studied. The challenge of this TR is main challenge #2, which is related to the fact that the "priority access" value exchanged in the initial random access procedure is not protected; in other words, the 5G standard allows the use of establishment reasons such as "highPriorityAccess", "mps-PriorityAccess", "mcs-PriorityAccess", etc., which are allowed to be transmitted in the clear.

[0480] A potential solution to this problem involves the following steps: 1. If the base station is in the serving / home network, the UE performs the random access procedure with the base station as usual, with the “RANDOM VALUE” included in message 3. 2. The UE performs primary authentication with the home network via the serving network. 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 may be the serving network key pair. This configuration may be pre-configured. 4. Once AS security is established, the UE transitions to RRC_Connected state. 5. If the UE moves to RRC_idle or RRC_INACTIVE state, the UE must perform a connection establishment again (by a new random access procedure, e.g., a 4-message random access procedure). a. The UE transmits an initial preamble b. The gNB responds with a random access response c. The UE uses the public key from step 3 to encrypt, e.g., 5G-S-TMSI-part1 or I-RNTI together with the establishment or resumption reason ("priority access") and sends this to the gNB. d. The gNB decrypts the message using the private key from step 3 and responds with message 4 (RRCSetup). e. The UE sends RRCSetupComplete to terminate the procedure and transition to the RRC_Connected state.

[0481] Steps 1-4 can be considered as setup steps, and step 5 can be considered as an operational phase that can give security guarantees ("priority access") for the privacy of the establishment reasons.

[0482] Problems with the above approach include the following: Because public keys are long and public key operations are expensive, it is more efficient to replace long keys and / or expensive operations with simpler ones when possible. The public key encrypted value may be large and may not fit into message 3. The gNB needs to be configured with the serving network's private key, which creates security risks. Thus, in one embodiment, step 3 is replaced by sharing a symmetric key and / or a one-time pad and / or an identifier (of the key / one-time pad) that the UE can use to protect steps 5c-d.

[0483] In one embodiment, which can be combined with other embodiments, step 5d is enhanced by requesting the AMF (or other NFs in the serving network, such as UDM) to decrypt the received message using the serving network's private key, thereby eliminating the need to configure the serving network's private key in the gNB.

[0484] In one embodiment, which can be combined with other embodiments, step 3 is replaced by a public key pair specific to the gNB, thereby eliminating the need to configure the gNB with the serving network's private key.

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

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

[0487] In a further embodiment, which can be combined with other embodiments, the message is encrypted using a key of the NEA algorithm, the plaintext input is the part of the message that needs protection, and the provided key is used as the encryption key.

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

[0489] In a further embodiment, which can be combined with other embodiments, the message is encrypted using a key according to the NEA algorithm, and other inputs include a counter value that depends on the UTC time.

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

[0491] In a further embodiment, which can be combined with other embodiments, the one-time pad key is a key (e.g., K gNB ) or from a key derived from it by a key derivation function.

[0492] In a further embodiment, which can be combined with other embodiments, the gNB may store a one-time pad key for encrypting the RRC resume reason from where the UE should extract it (e.g., K gNB The first and second nodes may randomly select and transmit (eg, in step 5b) an index that defines the location of the first and second nodes (location in the first and second nodes).

[0493] In a further embodiment, which may be combined with other embodiments, the gNB and the UE gNB The RRC resume reason may be encrypted (e.g., at the UE side) and decrypted (e.g., at the gNB side) using the first k bits of, or a key derived therefrom by a KDF. This has the advantage that no index and / or key identifier needs to be conveyed to the UE. The gNB may derive the correct K from the UE's security context based on the ID (e.g., full / shortened I-RNTI) included in the RRCResumeRequest. gNB Get the.

[0494] In a further embodiment, which can be combined with other embodiments, the message fields to be protected may include 5G-S-TMSI-part1 or the reason for establishment ("priority access").

[0495] In a further embodiment, which can be combined with other embodiments, the message is encrypted by XORing the message to be protected with the output of a key derivation function, whose inputs may include a provided key, or a UTC-based counter (such as those used in TS33.503), or other fields in the message.

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

[0497] In a further embodiment, which can be combined with other embodiments, the message includes an identifier that enables the gNB to determine the key or one-time pad to use for decryption.

[0498] In a further embodiment, which can be combined with other embodiments, the encrypted message includes an identifier (encrypted or in the clear) that enables the gNB to determine the key or one-time pad to use for decryption.

[0499] 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 received message 3, the gNB may search for it in another gNB (e.g., a nearby gNB) or within the AMF.

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

[0501] In a further embodiment, which can be combined with other embodiments, searching for a key / one-time pad may require sending a request including an identifier for that one-time pad or key.

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

[0503] In a further embodiment, which can be combined with other embodiments, for example when the serving network has a single symmetric key or a single private key, the identifier field is not included in message 3.

[0504] In a further embodiment, which can be combined with the previous embodiment, the concatenation of the fields serves as the “random value” in message 3 .

[0505] In an embodiment, which can 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 is unable to decrypt, the gNB indicates this fact in message 4 (step 5d). For example, if the UE moves to another gNB that does not know the pre-configured key / one-time pad, or if the gNB no longer stores those parameters, the gNB may not be able to decrypt it.

[0506] In an embodiment that can be combined with the previous embodiments, if the UE receives message 4 indicating that it is unable to decrypt message 3 encrypted using a symmetric key / one-time pad, the UE may perform step 5c again using the serving network's public key and attempt to encrypt parameters requiring privacy protection in step 5c.

[0507] 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. The method includes receiving an encryption key K linked to the access device and the UE, determining or receiving an L-bit sequence s, encrypting s to V with K, and transmitting V.

[0508] Therefore, according to this embodiment, a method is proposed which further comprises receiving a public key associated with the access device or the serving network.

[0509] Therefore, according to this embodiment, an apparatus for securely performing a random access procedure is proposed, the apparatus comprising a transceiver and a control unit, and configured to receive an encryption key linked to an access device and a UE, determine or receive an L-bit sequence s, encrypt s to V using K, and transmit V.

[0510] 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, the method including: receiving an encrypted message, obtaining an encryption key, and decrypting the message.

[0511] Techniques from different embodiments may be combined with each other.

[0512] EMBODIMENT 58 A potential solution to KI#2 of TR33.870, which protects the privacy of the RRC resume cause, may assume that the UE establishes an AS security context while in RRC_CONNECTED state, before transitioning to RRC_INACTIVE state. The UE may indicate to the network whether it supports encryption of resumeCause and its capabilities (e.g., supported encryption algorithms and encryption keys). This 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 resumeCause in plaintext may remain the same as the encrypted resumeCause bit string.

[0513] On the UE side, when the UE is transitioning from RRC_INACTIVE state to RRC_CONNECTED state by sending a RRCResumeRequest, the solution may use a RRCRelease message sent from the network to inform the UE of the key and encryption algorithm to be used to encrypt the resumeCause in the subsequent RRCResumeRequest message.

[0514] On the network side, the gNB / ng-eNB uses the I-RNTI sent by the UE in the RRCResumeRequest message to obtain the UE context and cipher keys required for decrypting the resumeCause. Decryption may be performed by the source or target gNB / ng-eNB.

[0515] The following embodiments may be applied to further improve the security of this scheme.

[0516] In a first embodiment, the algorithms and / or keys used are determined by a policy that can be set by default or on demand, which has the advantage that the encryption algorithms and / or keys do not need to be indicated in the RRCRelease message, nor do they need to be changed.

[0517] In a second embodiment, the algorithms and / or keys to be used are determined and indicated by the UE, since not all UEs have the same capabilities or preferences, which has the advantage of better serving multiple UEs with different security preferences.

[0518] In further embodiments, the network may send a message such as a RRCRelease message to inform the UE of the key, encryption algorithm, and parameters to use to encrypt the resumeCause in a subsequent RRCResumeRequest message. For example, if the UE needs to use the NR encryption algorithm (NEA) algorithm, additional configuration parameters (counters, bearers, etc.) that both parties need to know are also required.

[0519] In a further embodiment, a UE with the capability to protect resumeCause indicates the fact that the resumeCause is protected, allowing the gNB to thereby identify whether the resumeCause is protected and process accordingly. This embodiment has the advantage of ensuring backward compatibility.

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

[0521] In a further embodiment, the symmetric key is calculated as follows:

[0522] When deriving a symmetric key K to protect resumeCause, one or more of the following parameters may be used to form the input to the KDF used to derive the key: An identifier, e.g., I-RNTI (shortened or full I-RNTI, depending on whether the useFullResumeID field is present in SIB1), The length of the identifier, e.g. the length of the I-RNTI, Time counters, e.g. UTC-based counters, A nonce determined by the gNB, A nonce determined by the UE.

[0523] The KDF input key is, for example, the key K established before the UE switches to the RRC_INACTIVE state. gNB or K RRCEnc It could be.

[0524] In further embodiments, the bit sequence used to protect resumeCause is determined and used according to one or more of the following variations. In one variant, if b bits need to be protected, then b bits of the key are used as the bit sequence. In one variant, the protection is performed by XORing the b bits that need to be protected (eg resumeCause) with a bit sequence. In one variant, the length of resumeCause is always 4 bits (b=4), regardless of whether the UE uses RRCResumeRequest or RRCResumeRequest1 (depending on the presence of the useFullResumeID field in SIB1). Thus, if a one-time pad mechanism is used to protect resumeCause, the bit sequence used as the one-time pad key can be, for example, the first or last b (e.g. b=4) bits, or any b (=4) bit subset, of the symmetric key K derived from K_gNB as described in the previous embodiment. In one variant, the gNB may determine (e.g. randomly) an index from which the UE should extract a bit sequence of length b (e.g. b=4) bits and send it to the UE as part of the suspendConf parameter in the RRCRelease message. In this case, the gNB may need to store the index in the UE's context, e.g. if the index is UE specific. In one variant, the gNB may determine (e.g. randomly) an index from which the UE should extract a 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 SIB1. This has the advantage that the gNB does not need to store the index for a long time. In one variant, the ResumeCause is protected using the (derived) key with the NEA algorithm, and the counter field can be a time-based counter. The NEA algorithm is thus used to generate a bit sequence and use it to protect the resumeCause.

[0525] In a further embodiment, if a nonce (or something else in addition to a nonce) is used in the derivation of the key or in the process of protecting the information resumeCause, the gNB may include a randomly generated nonce in the suspendConf parameter of the RRCRelease message that the UE uses (e.g., as a parameter of the KDF to derive K). Additionally or alternatively, the UE may include this nonce in the message to the gNB. The nonce may be 5G-S-TMSI-part1 or a part of it. In other words, the nonce may be an explicit new field or may be a nonce that is implicitly transmitted by reusing an existing field.

[0526] In a further embodiment, if a UTC-based counter is used in the derivation of the key or in the process of protecting the information resumeCause, the least significant bit of the counter may be included in the message from the gNB to the UE or the message from the UE to the gNB. The techniques of different embodiments may be combined with each other.

[0527] EMBODIMENT 60 Another potential solution to the problem described in the above embodiment can be described as follows.

[0528] During the access control check procedure (specified in subclause 4.5.4 of TS 24.501), the UE determines whether the network is overloaded based on the barring control information broadcast by the NG-RAN. Specifically, if the barring control information is broadcast by the NG-RAN, the UE considers the network to be overloaded, and if the barring control information is not broadcast, the UE considers the network to be not overloaded.

[0529] For UEs with RRC establishment cause value "mps-PriorityAccess" and "mcs-PriorityAccess", the reported RRC establishment cause value is determined by the following rules: - If the network is not overloaded (i.e. no forbidden control information is broadcast), the UE hides its high priority attribute and the reported RRC re-establishment reason is determined according to the UE's access category. If the UE is rejected after an RRCSetupRequest, the UE reports the high priority access reason values ​​("mps-PriorityAccess" and "mcs-PriorityAccess") in the next RRC Connection Request message. - If the network is overloaded (i.e. when prohibition control information is broadcast), the high-priority access cause values ​​'mps-PriorityAccess' and 'mcs-PriorityAccess' are used directly, similar to the current mechanism.

[0530] For UEs with an establishment cause of "highPriorityAccess", the reported RRC establishment cause is determined according to the UE's access category instead of "highPriorityAccess".

[0531] This approach requires several considerations.

[0532] First, the establishment reason "highPriorityAccess" is not considered in the solution. That is, when the UE indicates "highPriorityAccess", it is proposed to determine the establishment reason based on the UE's access category instead of using "highPriorityAccess". However, according to clause 8.7.7 of TS38.413, when the AMF is overloaded, the AMF may request the NG-RAN to reduce the signaling load on itself and allow only certain RRC connection establishments such as high priority sessions and mobile terminated services (i.e., to allow only traffic corresponding to the RRC reasons "highPriorityAcces", "mps-PriorityAcces", "mcs-PriorityAcces", and "mt-Acces" of TS38.331, or the RRC reasons "highPriorityAcces", "mo-ExceptionDat", and "mt-Acces" of TS36.331). Therefore, this solution cannot cover the establishment reason "highPriorityAccess". Furthermore, the paragraph in TS 38.300, section 7.4, which explains the probability reasons that gNB deals with, states:

[0533] "The gNB shall process access attempts with establishment reasons 'emergenc', 'mps-PriorityAcces' and 'mcs-PriorityAcces' (i.e. emergency call, MPS, MCS subscriber) with high priority and shall respond with RRC reject to these access attempts only in case of extreme network load conditions that may threaten the stability of the gNB". This is not consistent with TS38.413, where the AMF may inform the NG-RAN that it is overloaded, in which case the AMF expects the establishment reason "highPriorityAccess" to be handled by the NG-RAN. This contradicts the above solution, because based on this, for a UE with establishment reason "highPriorityAccess", the reported RRC establishment reason is determined according to the UE's access category, not "highPriorityAccess".

[0534] Therefore, in a first embodiment addressing this issue, the gNB can indicate by a message (e.g. in SIB1) whether the AMF is overloaded. This has the advantage that the UE can choose to use its normal UE access category (if the AMF is not overloaded) or to use the "highPriorityAccess" access if the AMF is overloaded. That is, the access reason is not exposed in normal circumstances, but only when the AMF is overloaded. This embodiment has the advantage that the privacy risk can be reduced in a practical way, i.e., it can only occur when the AMF is overloaded.

[0535] In a further embodiment addressing this issue, a UE with an establishment cause of "highPriorityAccess" may use the UE's access category as the access category. If the UE is rejected after an RRCSetupRequest, the UE reports the high priority access cause value ("highPriorityAccess") in the next RRC connection request message. That is, the access cause is not disclosed under normal circumstances, and is only disclosed when the UE is rejected (e.g., due to AMF being overloaded). This embodiment mitigates privacy risks in a practical way.

[0536] In a further embodiment, a policy may be configured in the gNB such that an overloaded AMF will only process access attempts with establishment reasons "emergency", "mps-PriorityAcces", and "mcs-PriorityAcces", but not "highPriorityAccess". This has the advantage of ensuring consistency of the configured policy and limiting the possibility of misusing the "highPriorityAccess" reason value (e.g., for DoS attacks).

[0537] Another problem with this solution is that when the UE reports a high priority access cause value as the establishment reason (e.g. when the network is not overloaded and the UE is rejected after the RRCSetupRequest or when the network is overloaded), it does so without any form of protection. Therefore, an attacker (e.g. a man-in-the-middle attacker) may use a fake base station to broadcast forbidden control information or indicate that the AMF is overloaded (e.g. via SIB1). In that case, the victim UE reports its own high priority access cause value as clear text in the RRCSetupRequest.

[0538] In an embodiment aimed at addressing the above problem, if a security context (e.g., an AS security context) is available or can be established and the UE needs to report its resumeCause (e.g., a high priority access reason because the network is overloaded), the UE may protect the RRC establishment / resume cause, for example using an (existing) symmetric key (e.g., K_gNB) or a key derived from it, such as by a key derivation function.

[0539] In a related embodiment aimed at further minimizing privacy risk priority access reasons, the UE may protect the RRC establishment / resumption reason using a symmetric key (e.g., K_gNB) or a key derived from the symmetric key (e.g., by a key derivation function) regardless of whether the UE needs to convey a high priority access reason value (e.g., because the AMF is overloaded). This has the advantage that it does not implicitly leak that the protected part of the message is related to a high priority access reason.

[0540] In a related embodiment aimed at further minimizing privacy risk priority access reasons while optimizing performance, the UE may have to protect RRC establishment / resumption reasons if the device rejects the first message from the device and / or if the second device indicates an overloaded AMF.

[0541] In a related embodiment, the gNB uses the UE ID (e.g., I-RNTI) included in the RRCResumeRequest to identify the gNB hosting the security context of the UE and, accordingly, to obtain the corresponding keying material (e.g., K gNB or K RRCEnc ) can be obtained.

[0542] In another embodiment, the UE may protect the RRC establishment / resumption reason via a one-time pad mechanism using a subset of the symmetric key (e.g., K_gNB) or a key derived therefrom (e.g., by a key derivation function).

[0543] In another embodiment, the encryption key used to protect the RRC establishment or resumption reason is K RRCenc or it may be a key derived from it (eg, by a key derivation function).

[0544] In another embodiment, the UE may encrypt the entire RRC Establishment / Resumption Reason or RRCSetupRequest / RRCResumeRequest message using a (pre-configured) public key (e.g., distributed to the UE when the NAS security context is established). In such a case, the gNB decrypts the RRC Establishment / Resumption Reason or RRCSetupRequest / RRCResumeRequest message using a private key associated with the public key used for encryption.

[0545] In another embodiment, the asymmetric key may be identity-based, allowing a central party (e.g., NF) to calculate a private key associated with the identity. The UE may determine the public key for protecting the RRCResume reason based on public parameters shared by the central party while the UE is in RRC_CONNECTED state, such as as part of the suspendConf parameter in the RRCRelease message or via SIB1 broadcasted by the gNB. Upon receiving the RRCResumeRequest, the gNB forwards the UE identity (e.g., I-RNTI) used to derive the public key to the central party to request / obtain the corresponding private key. The gNB uses the provided private key to obtain the protected resume reason.

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

[0547] In another related embodiment, the gNB may indicate a (key) identifier and / or index in a message such as a Random Access Response, which the UE may use to select and / or determine the key to use for protecting the RRC Establishment / Resumption Reason or RRCSetupRequest / RRCResumeRequest.

[0548] In another embodiment, when transitioning from RRC_INACTIVE to RRC_ACTIVE, the UE sends RRCResumeRequest (or RRCResumeRequest1) with a protected resumeCause to the gNB. The gNB 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 of TS38.300, it is possible that the gNB fails to obtain or verify the UE context, in which case the gNB performs a fallback to establish a new RRC connection by sending an RRCSetup to the UE. An alternative approach could be to send an RRCReject to the UE with a reason for the failure (e.g. failure to resolve the gNB ID) and request the UE to send RRCResumeRequest1 with the full I-RNTI.

[0549] In a related embodiment that can be combined with the above embodiment, the gNB may send an RRCReject to the UE with a reason for the failure (e.g. failure to resolve gNB ID) and request the UE to use a different approach to protect the RRCResumeRequest (e.g. based on a (pre)configured public key). The gNB may indicate to the UE which approach to use (e.g. which public key to use) by including an identifier or part of an identifier in the RRCReject message.

[0550] In a related embodiment, the use of encryption / protection of fields such as resumeCause may require the use of a long I-RNTI. This may be advantageous to obtain the correct security context. This also means that if a field is encrypted or 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 fail not because the gNB resolved an old gNB ID, but because it failed to validate the UE context (e.g., the gNB obtained the UE context but failed to decrypt resumeCause). In such a case, the gNB may send an RRCReject to the UE with a reason for the failure (e.g., failure to validate the UE context) and request the UE to retry resuming the RRC connection using the (pre-)configured public key.

[0551] In related embodiments, the gNB may determine that decoding has failed if, for example: - if the decoded field (e.g. resumeCause) is not valid, and / or - If the CRC fails, and / or - If a MIC is available and the MIC verification fails.

[0552] In a related embodiment, the UE may be configured with policies (which may be hard-coded in the source code or configured by the CN or RAN) that determine how the UE (re)establishes or resumes an RRC connection depending on the following non-limiting factors: - reason for failure (e.g. failure to resolve old gNB ID, failure to validate UE context), and / or - I-RNTI type (e.g., truncated or full), and / or - Is the public key (pre-configured) in the UE?

[0553] Additionally, if a high priority establishment or resumption reason cannot be protected (e.g., initial joining of the network or failure of RRCResumeRequest due to no public key available and UE context validation failure), the policy may allow the UE to use a non-high priority reason or an "emergency" reason, which has the advantage that the UE can establish a connection without revealing its identity.

[0554] In related embodiments, protecting the message may refer to encrypting the message, and / or protecting the integrity of the message, and / or protecting the freshness of the message.

[0555] In a further embodiment, when the above solution is used, the AMF experiencing the load problem should not set a policy that allows the gNB to access “highPriorityAccess”.

[0556] In yet another embodiment, when the above solution is used, the AMF experiencing the load problem can set a policy to allow the gNB to access “highPriorityAccess”, but based on the above solution, the “highPriorityAccess” UE is used.

[0557] According to the above embodiment, an apparatus and a method are proposed for securely conveying an establishment / resumption reason associated with an access ID of the user equipment from the user equipment to a network entity (e.g., a base station or an access device) in a message of a random access procedure. The method includes: indicating / (pre)configuring by the network entity to the user equipment an encryption key to be used during (re)establishment or resumption of an RRC connection; the UE protecting the establishment / release reason with the encryption key and sending an RRCSetupRequest or an RRCResumeRequest including the protected establishment / resumption reason and a UE ID associated with the UE context; the network entity retrieving the UE context and / or the encryption key associated with the UE ID and revealing the protected establishment / resumption reason using the key.

[0558] According to the above embodiments, an apparatus and method are proposed which can be implemented in a first device (e.g., user equipment), enabling the first device to securely communicate fields associated with the device's access identity (e.g., establishment / resumption reason) to a second device (e.g., access device), wherein the method / apparatus is adapted to one or more of the following: - receiving an indication from the second device about the AMF load status and using the "highPriorityAccess" access only if the AMF is overloaded; - using 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 a first message (e.g. an RRC Setup Request);

[0559] The priority access reason is protected (e.g., encrypted) only if the device is initially rejected and / or a second device indicates AMF overload.

[0560] EMBODIMENT 62 The Subscription Concealment Identifier (SUCI) was introduced to conceal and protect the privacy of the Subscription Permanent Identifier (SUPI). As specified in TS 33.501 clause 6.12.2, the SUCI contains six parts: SUPI type, home network identifier, routing indicator, protection key identifier, home network public key identifier, and key output. The Home Network Identifier (HNI) and Routing Indicator (RID) (defined in TS 23.003 clause 2.2B) are used to identify and route communications to the subscriber's home network.

[0561] The fact that the home network identifier and routing indicator are not hidden / encrypted / protected in the SUCI may raise privacy issues. For example, an adversary eavesdropping on the air interface may be able to identify and track subscribers with sensitive home network identifiers, e.g., distinguish public safety personnel (e.g., police) with UEs subscribed to a public safety PLMN from other (nearby) UEs and / or subscribers of 5G private networks. This is similar to the issues discussed in other embodiments, e.g., the need to share the (rough) location of the UE in NTN use cases.

[0562] The objective is therefore to provide a means to prevent an attacker from eavesdropping on the wireless interface to obtain these private information. This objective may be addressed by one or more embodiments, which may be combined with each other as required.

[0563] In one embodiment, a UE attempting to attach to a network (e.g., a home network) / performing initial registration may: - deriving a SUCI (hidden first identifier) ​​by hiding / encrypting one or more first identifiers (e.g., SUPI) as described in TS 33.501; - deriving a hidden home network identifier and routing indicator (CHNIRI) by hiding / encrypting one or more second identifiers (e.g., a home network identifier (HNI) and / or a routing indicator (RID)) using a public key of a serving network (e.g., a VPLMN); - The concealed first identifier (SUCI) and the concealed second identifier (CHNIRI) may be transmitted to the serving network via the radio access network.

[0564] In a related embodiment, concealment / encryption may refer to security protection such as confidentiality protection or integrity protection.

[0565] In a related embodiment, if the UE is served by an HPLMN, then for performance purposes both the first and second identifiers are hidden / encrypted with the same key, for example the public key of the HPLMN.

[0566] In a related embodiment, when the UE is served by an HPLMN, the first and second identifiers may be hidden / encrypted by two keys, e.g., two public keys, associated with the HPLMN, and the first key may be stored in an NF (e.g., UDM) responsible for decrypting the hidden first identifier, and the second key may be stored / used in an NF (e.g., AMF / SEAF) responsible for access and session management.

[0567] In a related embodiment, if an identifier (e.g., SUCI and CHNIRI) is hidden with two different keys, common input parameters for the hiding process may 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 may be used for both hiding / encryption processes.

[0568] In related embodiments, the HNI and RID may refer to the HNI and RID, but may also refer to other parameters that the VPLMN may need to receive and that may pose a privacy risk. In a related embodiment, the UE transmits a concatenation of the SUCI and the CHNIRI to the network, in particular to the VPLMN or HPLMN.

[0569] In a related embodiment, an NF in a VPLMN receives a concatenation of the SUCI and the CHNIRI, and the VPLMN decodes the HNI and RID from the CHNIRI and routes the SUCI to the HPLMN indicated by the HNI.

[0570] In a related embodiment, the RAN of the (V / H)PLMN makes the public key of the (V / H)PLMN available to the UE, which allows the UE to encrypt the HNI and RID, e.g., the public key may be shared on demand in a SIB.

[0571] In a related embodiment, the RAN of the (V / H)PLMN makes the identifiers of the supported (V / H)PLMNs available to the UE, allowing the UE to select an appropriate key, e.g., a public key, to encrypt the HNI and RID, which may be (pre)configured and stored locally in the UE / USIM.

[0572] In a related embodiment, the HPLMN is responsible for configuring the UE with the public key to use when connecting to a different VPLMN. For example, if the HPLMN has an agreement with VPLMN1, the HPLMN (pre-)configures the UE with the public key to use when served by VPLMN1 and provides the corresponding private key to VPLMN1. This approach has the advantage that key configuration in the UE relies on the HPLMN, thus simplifying the key configuration, but the VPLMN may need to perform multiple decryptions (blind decryptions) to determine the correct key.

[0573] In a related variant, the key may refer to an identity-based key, where the identity of the serving network is used as the public key, which reduces the communication overhead for distributing / storing the public key to the UE.

[0574] In a related variant, a UE seeking to establish communication via a VPLMN / serving PLMN may transmit a temporary identifier (e.g., GUTI) so that neither the (hidden) first identifier nor the (hidden) second identifier needs to be exchanged.

[0575] In a related embodiment, the first and / or second identifiers are protected (e.g., encrypted) such that the protected (e.g., encrypted) first and / or second identifiers and / or the concatenation of the first and second identifiers are of a fixed length. This aims to reduce communication overhead while preventing an attacker from knowing / guessing the first or second identifiers.

[0576] In a related embodiment, the first and / or second identifiers are protected (e.g., hidden / encrypted) such that the first identifier (e.g., SUCI) is hidden as described in TS33.501 and the second identifier (e.g., HNI, RID) is concatenated to the hidden first identifier and the whole is encrypted / hidden as described in the above / below embodiments. This has the advantage of preventing an attacker from knowing / guessing the first and / or second identifiers.

[0577] In a related embodiment, the message including the UE's identifier includes an implicit / explicit identifier indicating how the first and second identifiers are protected. The implicit identifier may be based on a field present in the message or on the length of the message. The explicit identifier may be based on an indication of whether the first and / or second identifiers are protected.

[0578] In another 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 serving network's (e.g., VPLMN) public key, and the UE uses its own temporary private key and the VPLMN's public key to derive a temporary shared key (or a key derived therefrom) and encrypts / hides the HNI and RID using the derived temporary shared key. Upon receipt by the NF (e.g., AMF) in the serving network (e.g., VPLMN) (e.g., in the registration request or NAS ID response), a decryption function is invoked to derive a temporary shared key from the UE's temporary public key (contained in the SUCI) and the serving network's private key, and the key (or a key derived therefrom) is used to decrypt / decrypt the HNI and RI. This has the advantage that the same temporary key pair used to protect the SUPI can be reused to establish a symmetric key with the serving network. This ensures that only the intended serving network obtains the HNI and RI.

[0579] In another variation, the UE may generate a second ephemeral key pair and use it to derive a symmetric key shared with the serving network (e.g., VPLMN) to protect the HNI and RID as in the previous embodiment.

[0580] In another embodiment, whenever the UE sends a registration request (e.g., when the UE sends a SUCI instead of a 5G-GUTI) and / or sends a NAS ID response (e.g., when the AMF sends a NAS ID request), and / or the UE needs to convey the HNI and RI to the serving network, any one of the protection mechanisms described in the above embodiments may be used.

[0581] Generally, a method is proposed that may be implemented in a user equipment device configured as follows. - hiding the first identifier (e.g., SUPI) into a hidden first identifier (e.g., SUCI) by using a key associated with the HPLMN; - hiding a second identifier (e.g., a home network identifier) ​​into a hidden second identifier by using a key associated with the VPLMN or the serving network; - Sending the concealed first identifier and the concealed second identifier to the VPLMN or the serving network via the access network.

[0582] The different embodiments and variants can be combined with each other as required.

[0583] EMBODIMENT 62 Potential privacy issues regarding the HNI and RID described in the above embodiment may affect not only the SUCI but also the AKMA Key Identifier (A-KID) which has the format username@realm. The username includes a Routing Indicator (RID) and an AKMA Temporary ID (A-TID), and the realm includes the HNI. According to clause 6.2.1 of TS33.535, the UE includes 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.

[0584] In one embodiment, the UE and the AF (e.g., a local AF in the same serving network, or an AF in the HPLMN, or an external AF in the 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 the AKMA application session establishment request.

[0585] In a related embodiment, the private key may be a symmetric key, or may be a public / private key pair, where the public key is configured in the UE and the private key is held by the AF.

[0586] In another embodiment, when a UE is roaming in a serving network (e.g., VPLMN) and is trying to establish a session with an AF in the same network (e.g., VPLMN), the UE may send a hidden / encrypted (e.g., using the public key of the VPLMN) A-KID along with the application function's ID (AF_ID) to the serving network (e.g., VPLMN). After decrypting / decrypting the A-KID, the VPLMN may send / forward an AKMA session establishment request to the AF.

[0587] In another variation, when the UE is roaming in a serving network (e.g., a VPLMN) and is trying to establish a session with an AF in the same VPLMN, the UE may send the A-KID encrypted (e.g., using the public key of the VPLMN) in an AKMA Session Establishment Request message to the AF, and the AF may send the A-KID to an NF (e.g., a SEAF) in the serving network for decryption.

[0588] In another embodiment, when a UE is roaming in a serving network (e.g., VPLMN) and is trying to establish a session with an AF in a HPLMN, the UE may send a hidden / encrypted A-KID (e.g., using the public key of the HPLMN) to the AF in an AKMA session establishment request message. The AF may then send the encrypted A-KID to an NF (e.g., AUSF) in the HPLMN, which may decrypt it and send it back to the AF. Alternatively, the AF may send its AF_ID to the AUSF (instead of the AAnF) along with the encrypted A-KID to obtain the K_AF. The AUSF may decrypt it and forward the AF_ID and A-KID to the AAnF determined by the RID. The AAnF may derive the K_AF based on the AF_ID and the K_AKMA linked to the A-KID and send it to the AF.

[0589] In another embodiment, when a UE is roaming in a serving network (e.g., VPLMN) and is going to establish a session with an AF in a HPLMN, the UE may send an A-KID encrypted / hidden using a public key of the serving network, or a symmetric key (e.g., a temporary shared key as described in embodiment 7 or a key derived therefrom) to an NF (e.g., AMF / SEAF) in the serving network. The encrypted A-KID is then decrypted by an NF (e.g., SEAF) in the serving network (e.g., VPLMN) and forwarded to an AF in the HPLMN. According to embodiment 7.1, a method implementable in a user equipment device is proposed, and the UE is configured as follows: - Establishing a key or being (pre-)configured with said key by a network entity (e.g. AF) or the network (V / H PLMN), - hiding an identifier (e.g., a home network identifier, a routing indicator) using a key associated with a network entity (e.g., an AF) or a network (V / H PLMN) served by said network entity; - Transmitting the hidden identity to the network entity or to the network it serves (V / H PLMN).

[0590] EMBODIMENT 63 In some circumstances, such as when a device is maliciously manipulated or compromised, a simple (single-factor) authentication procedure based on a cryptographic key may be insufficient. Addressing this need may require strengthening the authentication procedure with a second or multiple authentication factors (e.g., location, device type, device speed, device motion, sensor data collected by sensors on the device).

[0591] According to another aspect, which can be used independently of the same objective of increasing signal integrity in the signaling network, a node in a procedural dialogue with a peer (e.g., a UE connecting to an access device, a UE authenticating with a core network, a UE authenticating with an AF, etc.) may measure additional parameters, such as: - the physical layer parameters of each transmitted signal received by the node from its peers, and / or - sensor data from the UE (e.g. from an accelerometer), and / or - Biometric data (e.g. the user's voice), and / or - other parameters that may act as second authentication factors (e.g. physical layer measurements).

[0592] The measurements may be combined to create a "fingerprint" that represents, for example, the transmitted signal from the peer node (e.g., access device) as seen by the first node (e.g., UE) and other parameters that may be measured by the UE. If the dialogue is interrupted / altered / etc. by transmissions from a third node, whether intentionally or unintentionally (e.g., overshadowing attack), the combined measurements by the first node (e.g., UE) will result in a fingerprint that is significantly different from the expected one. Even if another user is using the UE, the measurements of the UE parameters by the peer node will result in a fingerprint that is different from the expected one. It is also detected if the location of the UE is different from the expected one. This can be used by any of the communicating parties to take appropriate action. For example, the communicating parties may discard the signal without trying to read it, set the device / communication to a compromised / unauthenticated / etc. state. For example, the communicating parties may resend the last signal they sent to the peer, or instruct the peer to abort or resume a procedure in progress.

[0593] In one embodiment, the physical parameters include one or more measurements related to the position.

[0594] For example, an estimate of the distance between two nodes. For example, a measurement of the angle of arrival of a received signal from a peer node. The first node may use multiple antennas to gather more detailed information. In another example, the physical parameter may include a measure of a characteristic of the signal itself, for example, the received signal strength, or a measure of the quality of the signal or a component of the signal. For example, a measure of the frequency of the carrier.

[0595] In a related embodiment, a measure of distance is calculated between the fingerprint of the last received signal and a weighted average of multiple previous fingerprints. If the calculated distance exceeds a threshold, the first node may consider that the signal did not arrive from a peer node. The weighting used may take into account the opera...

Claims

1. 1. An apparatus for verifying a sensitive field transmitted to a second device, the apparatus comprising: A memory for storing information; A transceiver for transmitting and receiving messages, The apparatus comprises: Sending a first message to the second device along with the confidentiality field; receiving a verification challenge from the second device; and computing and transmitting a response to the second device based on the verification challenge, keying material shared between the first device and the second device, and the secret field exchanged in the first message.

2. The confidential field is Security features, Device type, The apparatus of claim 1 , wherein the at least one of

3. 3. The apparatus of claim 1, wherein the response is computed as a cryptographic function of K and the secret field.

4. The apparatus of claim 1 , wherein the response is calculated as Challenge(K, R, SNname, secret field).

5. 5. The apparatus of claim 1, wherein the first message includes a field indicating that the response should be calculated including information requiring verification exchanged in the first message.

6. 1. An apparatus for verifying a sensitive field received from a first device, the apparatus comprising: A memory for storing information; a transceiver for transmitting and receiving messages, The apparatus comprises: receiving a first message from the first device along with the confidentiality field; receiving a response from the first device; The apparatus checks whether a function of the response matches a value that is dependent on the sensitive field received in the first message.

7. The apparatus of claim 6 , wherein the apparatus determines the check to perform based on a field included in the first message.

8. The apparatus of claim 6, further comprising: checking if the response matches a cryptographic function of K and a UE security function, e.g. Challenge(K, R, SNname, UE security function).

9. 9. The device of claim 8, wherein if the previous check was not valid, the device checks whether the response matches a cryptographic function of K, e.g. Challenge(K, R, SNname).

10. A system comprising at least a first communication device according to any of claims 1 to 5 and at least one second device according to claims 6 to 9.

11. 1. A method for verifying a sensitive field transmitted to a second device, the method comprising: a. a first device sending a first message with information to the second device; b. receiving a verification challenge from the second device; c) calculating and sending to the second device a response based on the verification challenge, keying material shared between the first device and the second device, and the secret field exchanged in the first message.

12. 1. An apparatus for securing messages with a second device, the apparatus comprising: a) obtain a symmetric key if a security context is available and configured policies permit, or if the security context is unavailable or 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; (b) sending a secure message protected with the symmetric key and the protected symmetric key, or an instruction to obtain the symmetric key, to the second device.

13. The apparatus of claim 12 , wherein the message is an initial registration request.

14. The device uses the symmetric key to: one or more private fields, and a secret identifier; or The apparatus of claim 13 , further comprising: protecting one or more private fields if the message includes a pseudo-identifier of the covert identifier.

15. The apparatus of claim 12 , wherein the message is a random access message.

16. The sensitive field is 16. The apparatus of claim 13, further comprising at least one of the following: security features, location, user consent preferences, and ResumeCause.

17. 17. The apparatus of claim 14, wherein one or more fields are shared with a third device (e.g., an AMF).

18. A request to share the user's location; Confirmation of security features, 18. An apparatus according to any one of claims 12 to 17, comprising a receiver adapted to receive a protected message together with at least one of the confirmations of user consent preferences.

19. An apparatus for secure communication in a UE to network relay scenario, the apparatus comprising: storing a policy that determines the behavior of the device upon receiving a direct security mode command; The device performs the rejection and / or acceptance of received direct security mode commands that are unprotected and / or include NULL encryption and integrity algorithms based on the policy, the policy including determining whether the device has previously sent a DCR message that includes an emergency RSC.

20. 20. The device of claim 19, wherein the device accepts a received direct security mode command that is unprotected and / or includes a NULL encryption and integrity algorithm only if the device has previously sent a DCR message that includes an emergency RSC.

21. 21. The device of claim 20, wherein the device rejects a received direct security mode command that is unprotected and / or includes a NULL encryption and integrity algorithm if the device has not previously sent a DCR message including an emergency RSC.

22. A method for secure communication in a user device (UE) to network relay scenario, comprising: storing a policy that determines the behavior of the UE upon receiving an immediate security mode command; and 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, including determining whether the device has previously sent a DCR message that includes an emergency RSC.

23. A method of lawful interception comprising: A second network function (NF) in the second network optionally notifies a first NF in the first network of lawful intercept requirements; the second NF receiving keying material from the first NF; The method, wherein the second NF decrypts intercepted traffic exchanged between a User Device (UE) and an Application Function (AF) based on the provided keying material.

24. 24. The method of claim 23, wherein the second NF receives keying material from the first NF, the second NF being responsible for collecting AKMA keying material for purposes of lawful interception.

25. A method of lawful interception comprising: A first network function (NF) in a first network optionally receives lawful intercept requirements from a second NF in a second network; The method of claim 1, wherein the first NF transmits keying material to the second NF so that the second NF can decrypt intercepted traffic exchanged between a user device (UE) and an application function (AF) based on the provided keying material.

26. 26. The method of claim 25, wherein the first NF provides keying material to the second NF, the second NF being responsible for collecting AKMA keying material for purposes of lawful interception.

27. 27. The method of claim 25 or 26, wherein the first network triggers a Home Network Triggered Primary Authentication (HONTRA) only upon receiving a positive response from the second NF, which may be located in the first or second network, the positive response acknowledging that the keying material has been successfully received.

28. the first NF receives a key request; The first NF calculates the required keying material and shares the keying material with the second NF; 28. The method of any one of claims 25 to 27, wherein upon verifying correct reception of a key, the first NF shares the keying material with a requesting entity.

29. 29. The method of any one of claims 23 to 28, wherein the second network is the same as the first network.

30. the first NF receiving a key request and security parameters from a third NF (e.g., an AF); 30. The method of claim 25, wherein the first NF determines the keying material and shares the keying material and the security parameters with the second NF, thereby enabling the second NF to monitor, intercept or cache messages sent from the third NF to other entities (e.g., UEs) and use them to verify the validity of the received security parameters.

31. the second NF receives the keying material and security parameters from the first NF after a key request from a third entity, the key request being sent together with the security parameters; 25. The method of claim 23 or 24, wherein the second NF monitors, intercepts or caches messages sent from the third NF to other entities (e.g. UEs) and uses them to verify the validity of the received security parameters.

32. 32. The method of claim 31 , wherein if the verification is successful, the message is released by the second NF to the other entity.

33. A second Network Function (NF) device in a second network, the device comprising: a transmitter for optionally notifying a first NF in a first network of a lawful interception requirement; a receiver for receiving keying material from the first NF; and a controller for decrypting intercepted traffic exchanged between a user device (UE) and an application function (AF) based on the provided keying material.

34. A first Network Function (NF) device in a first network, the device comprising: a receiver for receiving notification of a lawful intercept requirement from a second NF in a second network; and a transmitter that transmits keying material to the second NF so that the second NF can decrypt intercepted traffic exchanged between a user device (UE) and an application function (AF) based on the provided keying material.

35. A storage medium comprising code which, when loaded into a computer, enables said computer to carry out the steps of the method according to any one of claims 22 to 32.

Images