Methods, systems, and computer readable media for protecting sensitive data to be transmitted in 5G and subsequent generation networks

Abstract

According to another aspect of the subject matter described herein, includes receiving or generating a service-based interface (SBI) request message. The method also includes identifying a next hop network function (NF) of the SBI request message. The method also includes determining, from a registered profile of the next hop NF, whether the next hop NF supports handling encrypted SBI request message parameters. The method further includes, in response to determining that the next hop NF supports handling the encrypted SBI request message parameter: encrypting the selected SBI request message parameter; adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of encrypted SBI request message parameters; and transmitting the SBI request message to the next hop NF.

Description

[0001] Priority claim

[0002] This application claims the benefit of priority to U.S. patent application serial No. 17 / 987,817, filed on November 15, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter described herein relates to protecting data in communication networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for protecting sensitive data to be transmitted in 5G and subsequent generation networks. Background Art

[0004] In 5G telecommunication networks, a network function that provides a service is referred to as a producer NF or NF service producer. A network function that consumes a service is referred to as a consumer NF or NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or consumes and produces a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0005] A given producer NF may have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number or a fully qualified domain name (FQDN) that resolves to an IP address and a port number on a network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include more than one NF instance. It should also be noted that multiple NF instances may share the same service endpoint.

[0006] NF registers with the Network Function Repository Function (NRF). NRF maintains profiles of available NF instances identifying the services supported by each NF instance. The profile of an NF instance is referred to as an NF profile in 3GPP TS29.510. An NF instance can obtain information about other NF instances registered with the NRF through an NF discovery service operation. According to the NF discovery service operation, the consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters, which the NRF uses to locate the NF profile of the producer NF that can provide the service identified by the query parameters. The NF profile is a data structure that defines the type of service provided by the NF instance and the contact and capacity information about the NF instance.

[0007] The Service Communication Proxy (SCP) can also call the NF Discovery service operation to learn about the available producer NF instances. The situation where the SCP uses the NF Discovery service operation to obtain information about the producer NF instance on behalf of the consumer NF is called delegated discovery. The consumer NF connects to the SCP, and the SCP balances the traffic load between the producer NF service instances that provide the required service or directly routes the traffic to the destination producer NF instance.

[0008] In addition to SCP, another example of an intermediate proxy that forwards traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). SEPP is a network function used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Thus, SEPP performs message filtering, policing, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] One issue in 5G and other types of networks is protecting sensitive data transmitted over the network. There are many types of sensitive data exchanged between NFs in a 5G network, including subscriber and subscription identification data, such as Subscription Permanent Identifier (SUPI), General Public Subscription Identifier (GPSI), Permanent Equipment Identifier (PEI), other subscriber-related data, or policy data. Such information can be used to masquerade as a legitimate subscriber and gain access to other subscribers' data.

[0010] One way to protect these and other types of data is to encrypt the transmission of data using the secure hypertext transfer protocol (HTTPs). HTTPs relies on transport layer security (TLS) to protect the transmission of data between communication endpoints. Although HTTPs provides adequate data protection when used, HTTPs is not used for all data transmissions in the network. For example, a consumer NF may use HTTP instead of HTTPs when passing requests to a producer NF or load balancer in the same network. The transmission of log and trace data within the service provider's network may be equally insecure. In addition, TLS-level encryption requires encryption of the entire transport layer payload, which is less efficient than encrypting selected message parameters that are considered to have sensitive data. In addition, TLS encryption is point-to-point, which means that the encrypted data must be decrypted and then re-encrypted when sending data through multiple network hops, and if a single hop does not perform TLS encryption, then end-to-end security cannot be guaranteed.

[0011] Since HTTPs is not commonly used for 5G data transmission, a mechanism is needed to protect sensitive data transmitted in 5G and subsequent generation networks. Protecting sensitive data includes determining which NFs support encryption and which do not, indicating when a message contains encrypted sensitive data, indicating which message parameters or attribute values ​​are encrypted, and passing cryptographic parameters between the sending NF and the receiving NF.

[0012] Accordingly, in view of these and other difficulties, there is a need for methods, systems, and computer-readable media for protecting sensitive data transmitted in 5G and subsequent generation networks. Summary of the invention

[0013] A method for protecting sensitive data to be transmitted in 5G and subsequent generation networks includes receiving or generating a service-based interface (SBI) request message. The method also includes identifying a next-hop network function (NF) for the SBI request message. The method also includes determining from the registered profile of the next-hop NF whether the next-hop NF supports handling encrypted SBI request message parameters. The method also includes, in response to determining that the next-hop NF supports handling encrypted SBI request message parameters: encrypting the selected SBI request message parameters; adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters; and transmitting the SBI request message to the next-hop NF.

[0014] According to another aspect of the subject matter described herein, receiving or generating the SBI request message includes generating the SBI request message at a consumer NF.

[0015] According to another aspect of the subject matter described herein, receiving or generating the SBI request message includes receiving or generating the SBI request message at a serving communication proxy (SCP) or a security edge protection proxy (SEPP).

[0016] According to another aspect of the subject matter described herein, the registered profile includes a profile of a next-hop NF registered with an NF Repository Function (NRF).

[0017] According to another aspect of the subject matter described herein, determining whether the next hop NF supports handling encrypted SBI request message parameters includes determining that the next hop NF supports handling encrypted SBI request message parameters, and encrypting the selected SBI request message parameters includes encrypting SBI request message parameters that the network operator deems to contain sensitive data.

[0018] According to another aspect of the subject matter described herein, adding one or more headers to an SBI request message or updating one or more headers in an SBI request message includes adding or updating a first header identifying encrypted SBI request message parameters and at least one second header including at least one parameter for facilitating decryption of the encrypted SBI request message parameters.

[0019] According to another aspect of the subject matter described herein, receiving or generating an SBI request includes receiving an SBI request, wherein the SBI request includes encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters, determining whether the next-hop NF supports handling the encrypted SBI request message parameters includes determining that the next-hop NF supports handling the encrypted SBI request message parameters, and the method also includes decrypting the encrypted SBI request message parameters, and encrypting the selected SBI request message parameters includes re-encrypting the decrypted SBI request message parameters using a secret key shared with the next-hop NF; and adding one or more headers to the SBI request message or updating one or more headers in the SBI request message includes updating the one or more headers to identify the re-encrypted SBI request message parameters and facilitating the next-hop NF to decrypt the re-encrypted SBI request message parameters.

[0020] According to another aspect of the subject matter described herein, receiving or generating an SBI request message includes receiving an SBI request message, wherein the SBI request message includes encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters, and determining whether the next-hop NF supports handling the encrypted SBI request message parameters includes determining that the next-hop NF does not support handling the encrypted SBI request message parameters, and in response: decrypting the encrypted SBI request message parameters to produce plaintext SBI request message parameters; replacing the encrypted SBI request message parameters with the plaintext SBI request message parameters in the SBI request message; and transmitting the SBI request message with the plaintext SBI request message parameters to the next-hop NF.

[0021] According to another aspect of the subject matter described herein, a method for protecting sensitive data to be transmitted in a 5G or subsequent generation network includes detecting the presence of an encrypted SBI request message parameter using one or more headers.

[0022] According to another aspect of the subject matter described herein, the selected SBI request message parameters include a Third Generation Partnership Project (3GPP) defined subscriber or subscription identification parameter at the SBI request message level rather than at a transport layer message level.

[0023] According to another aspect of the subject matter described herein, a system for protecting sensitive data to be transmitted in a 5G or subsequent generation network is provided. The system includes a network function (NF) including at least one processor. The system also includes a service-based interface (SBI) request message data protector implemented by the at least one processor, for: receiving or generating an SBI request message, identifying the next hop NF of the SBI request message, determining from the registered profile of the next hop NF whether the next hop NF supports handling encrypted SBI request message parameters, and in response to determining that the next hop NF supports handling encrypted SBI request message parameters: encrypting the selected SBI request message parameters; adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters; and transmitting the SBI request message to the next hop NF.

[0024] According to another aspect of the subject matter described herein, the NF comprises a consumer NF.

[0025] According to another aspect of the subject matter described herein, the NF includes a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

[0026] According to another aspect of the subject matter described herein, the registered profile includes a profile of a next-hop NF registered with an NF Repository Function (NRF).

[0027] According to another aspect of the subject matter described herein, the SBI request message data protector is configured to determine that the next hop NF supports handling encrypted SBI request message parameters, and encrypt the SBI request message parameters that the network operator deems to contain sensitive data.

[0028] According to another aspect of the subject matter described herein, the SBI request message data protector is configured to add or update a first header identifying encrypted SBI request message parameters and at least one second header including at least one parameter for facilitating decryption of the encrypted SBI request message parameters.

[0029] According to another aspect of the subject matter described herein, an SBI request message data protector is configured to: receive an SBI request, wherein the SBI request includes encrypted SBI request message parameters and one or more headers including data for facilitating identification and decryption of the encrypted SBI request message parameters; determine that the next-hop NF supports handling the encrypted SBI request message parameters; decrypt the encrypted SBI request message parameters; encrypt selected SBI request message parameters by re-encrypting the decrypted SBI request message parameters using a secret key shared with the next-hop NF; and update the one or more headers to identify the re-encrypted SBI request message parameters and facilitate the next-hop NF to decrypt the re-encrypted SBI request message parameters.

[0030] According to another aspect of the subject matter described herein, an SBI request message data protector is configured to receive an SBI request message, wherein the SBI request message includes encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters; and the SBI request message data protector is configured to determine that a next-hop NF does not support handling of the encrypted SBI request message parameters, and in response: decrypt the encrypted SBI request message parameters to produce plaintext SBI request message parameters; replace the encrypted SBI request message parameters with the plaintext SBI request message parameters in the SBI request message; and transmit the SBI request message with the plaintext SBI request message parameters to the next-hop NF.

[0031] According to another aspect of the subject matter described herein, the SBI request message data protector is configured to detect the presence of encrypted SBI request message parameters using one or more headers.

[0032] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon is provided, and the executable instructions control the computer to perform steps when executed by a processor of a computer. These steps include receiving or generating a service-based interface (SBI) request message. These steps also include identifying the next-hop network function (NF) of the SBI request message. These steps also include determining whether the next-hop NF supports handling encrypted SBI request message parameters according to the registered profile of the next-hop NF. These steps also include, in response to determining that the next-hop NF supports handling encrypted SBI request message parameters, encrypting the selected SBI request message parameters, adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters, and transmitting the SBI request message to the next-hop NF.

[0033] The subject matter described herein can be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In an exemplary embodiment, the subject matter described herein can be implemented using a non-transient computer-readable medium having computer-executable instructions stored thereon, which controls the computer to perform steps when executed by the processor of the computer. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transient computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium implementing the subject matter described herein can be located on a single device or computing platform, or can be distributed across multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Exemplary embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0035] Figure 1 is a network diagram illustrating an exemplary 5G system network architecture;

[0036] Figure 2 is a message flow diagram illustrating use of a NF REGISTER service operation to indicate support for encryption of sensitive data in SBI request message parameters and handling of encrypted SBI request message parameters;

[0037] Figure 3 is a message flow diagram illustrating the use of an NF Discovery service operation to determine that another NF supports handling encrypted SBI request message parameters;

[0038] Figure 4 is a message flow diagram illustrating use of NF Update service operations to indicate support for encryption of sensitive data in SBI request message parameters and handling of encrypted SBI request message parameters;

[0039] Figure 5A and 5B is a message flow diagram illustrating the use of nfStatusSubscribe and nfStatusNotify service operations to determine that another NF supports handling of encrypted SBI service request message parameters;

[0040] Figure 6 is a message flow diagram illustrating exemplary messages exchanged in a 5G network when all entities initiating or receiving a service request message support handling of encrypted SBI request message parameters;

[0041] Figure 7 is a message flow diagram illustrating exemplary messages exchanged when encryption of SBI request message parameters begins at a first hop SCP or SEPP;

[0042] Figure 8 is a message flow diagram illustrating exemplary messages exchanged when a first hop SCP supports handling encrypted SBI request message parameters and a second hop SCP does not support handling encrypted SBI request message parameters;

[0043] Fig. 9 is a message flow diagram illustrating messages exchanged when a first hop SCP does not support handling encrypted SBI request message parameters, a second hop SCP or SEPP supports encrypting selected SBI request message parameters, and a producer NF supports handling encrypted SBI request message parameters;

[0044] Fig.10is a block diagram of network functionality that provides support for encryption of selected SBI request message parameters and handling of encrypted SBI request message parameters; and

[0045] Fig.11 is a flow chart illustrating an exemplary process for protecting sensitive data to be transmitted over a 5G or subsequent generation network. DETAILED DESCRIPTION

[0046] Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture in includes NRF 100 and SCP 101, which can be located in the same home public land mobile network (HPLMN). As described above, NRF 100 can maintain profiles of available NF instances and the services they support, and allow consumer NFs or SCPs to subscribe to and be notified of registrations of new / updated NF instances. SCP 101 can also support service discovery and selection of NF instances. SCP 101 can perform load balancing of connections between consumer and producer NFs.

[0047] NRF 100 is a repository for profiles of NF instances. In order to communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile of the producer NF instance from NRF 100. NF profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS29.510. NF profile includes attributes indicating the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0048] exist Figure 1 In the example shown, any network function can be a consumer NF, a producer NF, or both, depending on whether they are requesting services, providing services, or requesting and providing services. In the example shown, the NFs include a policy control function (PCF) 102 that performs policy-related operations in the network, a unified data management function (UDM) 104 that manages user data, and an application function (AF) 106 that provides application services.

[0049] Figure 1 The NF shown in FIG. 1 also includes a session management function (SMF) 108, which manages sessions between the AMF 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by the mobility management entity (MME) in a 4G network. An authentication server function (AUSF) 112 performs authentication services for user equipment (UE) such as user equipment (UE) 114 seeking to access the network.

[0050] NSSF 116 provides network slicing services for devices seeking to access specific network capabilities and features associated with network slices. NSSF provides NSSelection services and NSSAIAvailability services. NSSelection services allow NFs to request information about network slices, and NSSAIAvailability services enable NFs to update and subscribe to receive update notifications of NSSAI availability information.

[0051] The Network Exposure Function (NEF) 118 provides an Application Programming Interface (API) for application functions seeking to obtain information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0052] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via wireless links. gNB ( Figure 1 The UE 114 may use a wireless access point (not shown) or other wireless access point to access the radio access network 120. The user plane function (UPF) 122 may support various proxy functions for user plane services. An example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that the UE 114 may use to obtain network performance measurements. Figure 1 Also illustrated in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0053] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. The SEPP 126 can communicate with a SEPP in an external PLMN that manages the security of the external PLMN. Therefore, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the external PLMN. A unified data repository (UDR) 128 stores subscription data for the UE. A binding support function (BSF) 130 manages the binding between PDU sessions and PCFs.

[0054] As mentioned above, one of the issues in 5G networks is how to protect sensitive data transmitted over the network. Based on the use case, certain attributes in the service request message may be considered sensitive. Examples of such attributes that may be considered sensitive include SUPI, GPSI, PEI, subscriber-related data, policy data, etc. Although the 3rd Generation Partnership Project (3GPP) standards have taken various security measures to ensure the security of data transmission, the data may still be maliciously accessed by other parties, for example due to vulnerabilities in the security process. Examples of situations where data security may be compromised include:

[0055] Send over an insecure transport from consumer to producer, for example, using HTTP instead of HTTPs.

[0056] Within internal services, for example, use HTTP instead of HTTPs for insecure data transfer from or to a load balancer or within the service model of an SCP or producer NF.

[0057] Logs / traces generated by intermediary nodes (or observability components such as a service mesh) that contain sensitive data.

[0058] Therefore, there is a need to provide an alternative mechanism whereby sensitive data between 5G endpoints can be securely transmitted.

[0059] The Internet Engineering Task Force (IETF) provides guidance for hiding sensitive data in Request for Comments (RFC) 2661. This model has been successfully adapted to enable encryption of data using Diameter or Radius protocols. However, there are still challenges in implementing the security model recommended by RFC 2661 in 5G data transmission. First, the characteristics of the data security model in RFC 2661 will be described. Next, the challenges of implementing the security features of RFC 2661 will be described. After that, solutions for implementing the identified challenges in 5G and subsequent generation networks will be described.

[0060] It should be noted that IETF RFC 2661 defines the security procedures implemented for the Layer 2 Tunneling Protocol (L2TP), which is used at Layer 2 of the Open Systems Interconnection (OSI) model, and not at the SBI request message parameter level in 5G networks. According to RFC 2661, the H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in clear text. The H bit must be set only when a shared secret exists between the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). Hiding the AVP value is accomplished in several steps. The data is encrypted using the shared secret S, the random vector (RV), and the attribute value (AV) (i.e., the value being encrypted). If the H bit is set in any (one or more) AVPs in a given control message, then the random vector AVP must also be present in the message and must be located before the first AVP with the H bit set to 1.

[0061] In summary, according to RFC 2661, the random vector and the encrypted data are transmitted over the wire. The sender and receiver know the shared secret before transmitting between them. In order to decrypt the encrypted properties in the message, the receiver needs the shared secret (known offline), the random vector (from the message), and the encrypted data (from the message).

[0062] Challenges in implementing RFC 2661 or similar security features in 5G and subsequent generation networks include the following:

[0063] 1. Determine whether the producer NF or SCP / SEPP supports handling of encrypted SBI message parameters.

[0064] • The consumer NF / SCP / SEPP may be communicating with the same type of producer NF from different vendors. The consumer NF / SCP / SEPP needs a way to identify whether the producer NF or other next hop NF supports handling encrypted SBI request message parameters.

[0065] 2. Who should encrypt data?

[0066] • Whether the data must be encrypted by the consumer NF, or whether the encryption can be done by the SCP / SEPP so that sensitive data can only be securely transferred between SCP / SEPP to producer, or SCP to SEPP, or SEPP to SCP, or SCP to SCP.

[0067] 3. Shared secrets or keys required to encrypt and decrypt sensitive data.

[0068] As part of their security strategy, network operators may need to rotate shared secrets to avoid security threats.

[0069] When secrets are rotated, there is a window where the client may have the new secret and the recipient may have the old secret (or vice versa). Therefore, changes to shared secrets need to be handled gracefully and securely. Rotation and exchange of shared secrets goes beyond the security features described in RFC2661.

[0070] 4. How should the encryption data, random vectors and other security related parameters be placed in the 5G service request? How should the 5G sender (such as a consumer NF, SCP or SEPP) communicate with the receiver (such as an SCP, SEPP or producer NF) which parameters are encrypted in the service request message?

[0071] To address the first challenge (how to convey support for handling encrypted SBI request message parameters), the subject matter described in this article enables a NF to register support for handling encrypted SBI request message parameters using the NFRegister service operation described in 3GPP TS29.510, and use the NF discover service operation to discover the NF's support for handling encrypted SBI request message parameters for other NFs. Figure 2 is a message flow diagram illustrating the use of the NFRegister service operation to indicate support for handling encrypted SBI request message parameters. Figure 2, in line 1, the NF service consumer 200 (i.e., the producer NF that is consuming the service of the NRF) sends a NFRegister request to the NRF 100. The NFRegister request carries the service profile or NF of the NF service consumer 200. The NF service consumer 200 adds an indication of support for handling encrypted SBI request message parameters to the NFRegister request. In one example, the indication of support for handling encrypted SBI request message parameters can be carried in the supportedVendorSpecificFeatures attribute of the NF or service profile. 3GPP TS29.510 allows the producer NF to provide the supportedVendorSpecificFeatures attribute in its NF or service NF profile. The supportedVendorSpecificFeatures attribute contains a mapping of vendor-specific features. In this example, one of the features is the encryptedSensitiveData feature, which indicates support for handling encrypted SBI request message parameters. Similarly, an SCP / SEPP that supports handling encrypted SBI request message parameters can add the EncryptedSensitiveData feature to the supportedVendorSpecificFeatures attribute of its SCP or SEPP profile.

[0072] return Figure 2 If the NFRegister service operation is successful, the NRF 100 will respond with a 200OK message indicating successful registration of the NF or service profile as indicated in line 2a. If the NFRegister request is redirected or the processing of the NFRegister request is unsuccessful, the NRF 100 will respond with a 4xx or 5xx message indicating the details of the problem or a 3xx message indicating redirection as indicated in line 2b. Once the NF or service profile is successfully registered with the NRF 100, other NFs can use the NFDiscover service operation to determine whether the peer NF (e.g., producer NF, SCP, or SEPP) supports handling encrypted SBI request parameters.

[0073] Figure 3 is a message flow diagram illustrating exemplary messages exchanged in the operation of the NFDiscover service. Figure 3, in step 1, the NF service consumer 300 seeking to discover information about other NFs in the network sends a NFDiscover request to the NRF 100. The NFDiscover request includes query parameters, which the NRF 100 uses to generate a list of NFs or service profiles of producer NFs that can provide the services indicated by the query parameters. If the NFDiscover service operation is successful, the NRF 100 will respond with a 200OK message containing a list of NFs or service profiles of producer NFs that match the query parameters as indicated in line 2a. According to one aspect of the subject matter described herein, for producer NFs that have registered support for handling encrypted SBI request message parameters, the NF or service profile may include the above-mentioned indication of support for handling encrypted SBI request message parameters. For example, for producer NFs that support handling encrypted SBI request message parameters, the NF or service profile may include a supportedVendorSpecificFeatures attribute with an EncryptedSensitiveData feature as one of the features in the feature list. If the NFDiscover service operation is unsuccessful or redirected, the NRF 100 will respond with a 4xx or 5xx message indicating the details of the problem or a 3xx message indicating a redirection as indicated in line 2b. Once the NF service consumer 300 knows that the producer NF, SCP or SEPP supports handling encrypted SBI request message parameters, the consumer NF 300 can include the encrypted message parameters in the service request message transmitted to the producer NF, SCP or SEPP. The NF service consumer 300 still has to solve the problem of who should encrypt the data, how to encrypt it, and how to pass on which data is encrypted in the message to the recipient.

[0074] It should be noted that the subject matter described herein is not limited to using the NFRegister service operation to register support for handling of encrypted data. For example, an NF service consumer may use the NFUpdate service operation to update an existing NF or service profile to the NRF to indicate support for handling of encrypted SBI request message parameters. Figure 4 is a message flow diagram illustrating the NFUpdate service operations and its support for handling of encrypted SBI request message parameters. Figure 4, in line 1, the NF service consumer 200 sends an NFUpdate request to the NRF 100 to update its NF or service profile to the NRF 100. In this example, the NFUpdate request contains the complete NF or service profile of the NF service consumer 200 to replace the existing NF or service profile of the NF service consumer 200 registered with the NRF 100. In an alternative example, if a partial NF or service profile update is requested, the NFUpdate request will contain the attributes of the replaced NF or service profile, and the HTTP PATCH method will be used in the NF service request instead of the HTTP PUT method. In either case, the attributes of the complete NF profile or the replaced NF service profile will include an indication of the above-mentioned encrypted SBI request message parameter handling. If the NFUpdate service operation is successful, the NRF 100 will respond with a 200OK message as indicated in line 2a. If the NFUpdate or service request is unsuccessful or redirected, the NRF 100 will respond with a 4xx or 5xx message indicating the problem details or a 3xx message indicating redirection as indicated in line 2b. Once a NF or service profile is updated to include an indication of support for handling encrypted message parameters, other NFs can use the NFDiscover service operation to learn about support for handling encrypted message parameters.

[0075] The subject matter described herein is not limited to the consumer NF using the NFDiscover service operation to learn support for handling encrypted message parameters. For example, the consumer NF can also use the NFStatusSubscribe and NFStatusNotify service operations to learn support for handling encrypted message parameters by another NF. Figure 5A and 5B Illustrate support for handling encrypted SBI request message parameters using the NFStatusSubscribe and NFStatusNotify service operations. Figure 5A , in line 1, the NF service consumer 300 sends a NFStatusSubscribe request to the NRF 100. The NFStatusSubscribe request includes subscription data indicating the types of events for which the NF service consumer expects to receive notifications. In this example, the events include changes to the NF or NF service profile that indicate the addition or removal of support for handling encrypted SBI request message parameters. If the subscription creation is successful, the NRF 100 will respond with a 201Created message containing subscription data (such as subscription Id) as indicated in line 2a. If the subscription creation is unsuccessful or if the request is redirected, the NRF 100 will respond with a 4xx or 5xx message specifying the details of the problem or a 3xx message indicating redirection as indicated in line 2b.

[0076] refer to Figure 5B , when the NRF 100 detects an event that matches the subscription data of one of the subscriptions created with the NRF 100, the NRF 100 will respond by sending a notification request message to the subscribing NF (such as the NF service consumer 300) as indicated in line 1. The notification request message includes notification data for the event that matches the subscription data. In this example, the notification data includes an indication of support for handling encrypted SBI request message parameters. If the NF service consumer 300 successfully processes the notification request, the NF service consumer 300 will respond with a 204 No Content message. If the NF service consumer 300 does not successfully process the notification request or the notification request is redirected, the NF service consumer 300 will respond with a 4xx or 5xx message indicating details of the problem or a 3xx message indicating redirection as indicated in line 2b.

[0077] Now turn to the second challenge of implementing the handling of encrypted SBI request message parameters in 5G networks, namely, who should encrypt the data, the options are the consumer NF that initiates the service request message or the SCP or SEPP that forwards the service request message. The use of the subject encryption message parameters described in this article can be performed at any or all of the consumer NF, SCP or SEPP. In one example, in order to enable encryption of sensitive data in the SBI request message parameters, it is recommended that the consumer NF encrypt sensitive data when the next hop SCP / SEPP supports encryption attribute handling (i.e., as indicated by the encryptedSensitiveData feature in the supportedVendorSpecificFeatures attribute of the NF profile of the SCP / SEPP). However, even if the consumer NF or the previous hop SCP sends sensitive data in plain text format, the intermediate SCP / SEPP can also encrypt the sensitive data based on the encryptedSensitiveData feature in the supportedVendorSpecificFeatures attribute of the profile of the next hop SCP, SEPP or producer NF. An example of a message flow for encrypting sensitive data at the initiating NF and the intermediate NF is described in detail below.

[0078] To address the third challenge of disposing encrypted SBI request message parameters using a shared secret key, the Key Id (kid) header parameter described in IETF RFC 7515 Section 4.1.4 can be used to indicate which key should be used to decrypt the encrypted message parameters. According to RFC 7515 Section 4.1.4, the Key ID header parameter provides a hint that indicates which key was used to protect JavaScript web signatures (JWS). This parameter allows the initiator to explicitly signal a key change to the recipient. The structure of the "kid" value is unspecified. Its value must be a case-sensitive string. The use of this header parameter is optional. When used with a JWK, the "kid" value is used to match the JWK "kid" parameter value.

[0079] The "kid" value or similar concept can be used to convey the identity of the key that can be used to decrypt the message attributes to the receiving NF. The encryption entity (e.g., the sending NF) provides the key Id of the shared secret used to encrypt the attributes in the 5G Service Request message. The receiving NF will then use the key Id to access the shared secret and use the shared secret to decrypt the encrypted message parameters or attributes.

[0080] It should be noted that intermediate nodes (such as SCP / SEPP) can decrypt and re-encrypt using the updated key / shared secret (if necessary) before forwarding to the next hop NF. This is based on how the network operator sets up the scope of key Ids and shared secrets between various SCP / SEPP instances in their network. How the operator enables sharing of key Ids and associated secrets with NFs and SCPs is implementation specific. There are many open source and proprietary solutions available to enable loading of one or more key Ids and certificates / secrets with multiple applications.

[0081] To address the fourth challenge described above of how the sending NF indicates to the receiving NF that the message contains encryption parameters, which parameters in the message are encrypted, and data that facilitates decryption, the sending NF may update or add one or more vendor-encrypted* headers to the SBI request message (where "*" is a wildcard to indicate that there may be more than one type of vendor-encrypted header). The presence of the vendor-encrypted-* header allows the receiving producer NF / SCP / SEPP to know that the service request has encrypted properties. If the service request is received at an intermediate SCP / SEPP (i.e., an SCP or SEPP that is not the final destination of the service request), then the presence of the vendor-encrypted-* header allows the intermediate SCP / SEPP to select a producer NF that supports handling messages with encryption parameters. For example, if there are multiple producer NFs that provide the service requested by the service request received by the SCP or SEPP, and the service request includes encryption parameters, then the SCP or SEPP may select one of the producer NFs that supports handling messages with encryption parameters. If there is no producer NF that supports handling messages with encrypted parameters, the SCP or SEPP may decrypt the encrypted parameters, replace the encrypted parameters in the message with the decrypted parameters, and forward the message with the decrypted parameters to one of the producer NFs that can provide the service requested by the service request message. The SCP or SEPP may run this additional logic (in addition to the SCP or SEPP routing logic) to handle the encrypted service request (e.g., during SCP to SCP, SEPP to SCP, SCP to SEPP, SCP to producer NF, or SEPP to producer NF routing).

[0082] One type of vendor-encrypted-* header that can be added to a message with an encrypted attribute is a custom header called a "vendor-encrypted-params" header. The vendor-encrypted-params header can indicate which parameters in the message are encrypted. In one example, the vendor-encrypted-params header can include a comma-delimited list that identifies the parameters in the body of the SBI message that are encrypted by the sending NF. Nested parameters can be specified using the JavaScript Object Notation (JSON) annotation format, for example, ab

[0083] Another type of vendor encrypted-* header that the sending NF can add to a message with encryption parameters is a "vendor-encrypted-random-id" header containing a random vector string (as described in IETF RFC 2661). According to RFC 2661, the random vector string is part of the Random Vector AVP that the party sending the encrypted information uses to create the MD5 hash.

[0084] In particular, RFC 2661 instructs to perform an MD5 hash on the concatenation of:

[0085] The 2-octet attribute number of the AVP,

[0086] + shared secret, and

[0087] +A random vector of arbitrary length.

[0088] The MD5 hash is XORed with the first 16 octets (or less) of the Hidden AVP subformat and placed in the Attribute Value field of the Hidden AVP. The Hidden AVP subformat contains the original value being encrypted and the length (in octets) of the attribute value to be masked. The original value is replaced with (hash value) XOR (original attribute value). The example parameter encryption operation specified in RFC 2661 is as follows:

[0089] Call the shared secret S, the random vector RV, and the attribute value AV. Split the value field into 16-octet chunks p1, p2, etc. The last one is padded with random data at the end to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We will also define intermediate values ​​b1, b2, etc.

[0090]

[0091] The sending or intermediate NF can perform these operations to encrypt message attributes containing sensitive data before transmitting the request message over the 5G network.

[0092] The sending or intermediate NF can add a third header containing the above mentioned key Id to the service request message. The third custom header is called the "vendor-encrypted-id" header. The next hop SCP / SEPP / producer NF will use the key Id to get the key / shared secret and use the key or shared secret to decrypt the encrypted parameters in the message.

[0093] Figure 6 is a message flow diagram illustrating exemplary messages exchanged when all entities in a 5G network in a routing path of an SBI request message support handling encrypted SBI request message parameters. Figure 6In step 1, the consumer NF 600 selects a next-hop SCP or SEPP to route the SBI request message. In step 2, the consumer NF 600 accesses the SCP or SEPP profile of the next-hop SCP / SEPP 101A or 126A to determine whether the SCP / SEPP 101A or 126A supports handling encrypted SBI request message parameters. The consumer NF 600 may have used the NFDiscover or NFStatusSubscribe service operations from the NRF ( Figure 6 In this example, based on the presence of the encryptedSensitiveData feature in the VendorSpecificFeatures attribute of the SCP or SEPP profile, the consumer NF 600 determines that the next hop SCP / SEPP 101A or 126A supports handling of encrypted SBI request message parameters.

[0094] In step 3, the consumer NF 600 encrypts the sensitive data to be inserted into the SBI request message, inserts the encrypted data into the SBI request, and sends the SBI request to the next hop SCP / SEPP 101A or 126A. The specific parameters that are encrypted may depend on the network operator configuration. Examples of parameters that may be encrypted include subscription and / or subscriber identification parameters, such as those described above. The consumer NF 600 also adds the above-mentioned vendor-encrypted-* header to the message.

[0095] In step 4, the SCP / SEPP 101A or 126A determines whether the next hop network function supports handling encrypted SBI request message parameters. The SCP / SEPP 101A or 126A may make this determination by accessing the SCP or SEPP profile of the SCP / SEPP 101B or 126B, which the SCP / SEPP 101A or 126A obtains from the NRF using the NFDiscover or NFStatusSubscribe service operations. In step 6, the SCP / SEPP 101A or 126A encrypts or re-encrypts the sensitive data in the message based on the operator configuration and updates the custom vendor-encrypted-* header with the required information. For example, if SCP / SEPP 101A or 126A determines that SCP / SEPP 101B or 126B supports handling of encrypted SBI request message parameters, then SCP / SEPP 101A or 126A may decrypt the encrypted message parameters using a secret shared with consumer NF 600, re-encrypt the parameters using a secret shared with SCP / SEPP 101B or 126B, and update the vendor-encrypted-* header to include an indication of which parameters are encrypted and a random string and key Id to facilitate decryption of the parameters. Alternatively, if consumer NF 600 and SCP / SEPP 101B or 126B use the same shared secret, then decryption and re-encryption may not be required.

[0096] In step 8, SCP / SEPP 101B or 126B receives the SBI request message, performs similar operations as SCP / SEPP 101A or 126A, and forwards the SBI request message to producer NF 602. In step 9, producer NF 602 identifies the encrypted message parameters and decrypts the encrypted message parameters using the data in the vendor-encrypted-* header. Figure 6 In the method shown in , when all entities in the routing path of the message support processing encrypted SBI request message parameters, the sensitive data carried in the SBI request message attributes can be protected end-to-end.

[0097] Figure 7 is a message flow diagram illustrating exemplary messages exchanged when encryption of message parameters begins at the first-hop SCP or SEPP. Figure 7 , in step 1, because the consumer NF 600 does not support selective encryption of sensitive data in the SBI request, the consumer NF 600 sends the SBI request with the sensitive data in plain text to the next hop SCP / SEPP 101A or 126A.

[0098] In step 2, the SCP / SEPP 101A or 126A receives the SBI request and determines whether the next-hop NF supports handling encrypted SBI request message parameters. The SCP / SEPP 101A or 126A may make this determination by accessing the SCP or SEPP profile of the SCP / SEPP 101B or 126B, which the SCP / SEPP 101A or 126A obtains from the NRF using the NFDiscover or NFStatusSubscribe service operations. In step 3, the SCP / SEPP 101A or 126A encrypts the sensitive data in the message based on the operator configuration and adds a custom vendor-encrypted-* header with the required information. In step 4, the SCP / SEPP 101A or 126A sends the message to the next-hop SCP / SEPP 101B or 126B.

[0099] In step 5, the SCP / SEPP 101B or 126B receives the SBI request message and determines from the NF or service profile of the next hop NF whether the next hop NF supports handling encrypted SBI request message parameters. In this example, the SCP / SEPP 101B or 126B determines that the producer NF 602 supports handling encrypted SBI request message parameters. Accordingly, in step 6, the SCP / SEPP 101B or 126B performs the necessary encryption and / or decryption and re-encryption, and updates the vendor-encrypted-* header in the message based on the newly encrypted parameters. In step 7, the SCP / SEPP 101B or 126B sends the SBI request to the producer NF 602.

[0100] In step 8, the producer NF 602 receives the SBI request, identifies the encrypted message parameters, and decrypts the encrypted message parameters using the data in the vendor-encrypted-* header. Figure 7 In the method shown in , the first-hop SCP / SEPP and subsequent entities in the network all support selective encryption of message parameters and handle encrypted message parameters when the consumer NF that originates the message does not support encryption of the selected message parameters.

[0101] Figure 8 is a message flow diagram illustrating exemplary messages exchanged when a first hop SCP supports handling encrypted SBI request message parameters, and a second hop SCP does not support handling encrypted SBI request message parameters. Figure 8In step 1, the consumer NF 600 determines from the SCP or SEPP profile of the first-hop SCP / SEPP 101A or 126A that the first-hop SCP / SEPP 101A or 126A supports handling encrypted SBI request message parameters. Accordingly, in step 2, the consumer NF 600 encrypts the message parameters containing sensitive data selected by the network operator, generates a vendor-encrypted-* header, and adds the vendor-encrypted-* header and the encrypted parameters to the SBI request. In step 3, the consumer NF 600 sends the SBI request to the next-hop SCP / SEPP 101A or 126A.

[0102] In step 4, the SCP / SEPP 101A or 126A receives the SBI request and determines that the next-hop NF does not support handling encrypted SBI request message parameters. The SCP / SEPP 101A or 126A may make this determination by accessing the SCP or SEPP profile of the SCP / SEPP 101B or 126B, which the SCP / SEPP 101A or 126A obtains from the NRF using the NFDiscover or NFStatusSubscribe service operations. In step 5, the SCP / SEPP 101A or 126A decrypts the encrypted message parameters and removes the vendor-encrypted-* header. In step 6, the SCP / SEPP 101A or 126A sends the message with the message parameters in plain text format to the next-hop SCP / SEPP 101B or 126B. In step 7, the SCP / SEPP 101B or 126B receives, processes and sends the SBI request with the parameters in plain text format to the producer NF 602. Thus, Figure 8 Illustrated is a case where an intermediate SCP or SEPP intelligently determines that the next hop NF does not support handling encrypted SBI request message parameters, decrypts the parameters, and removes headers related to the previously encrypted parameters before sending the message to the next hop NF.

[0103] Fig. 9 is a message flow diagram illustrating messages exchanged when the first hop SCP does not support handling encrypted SBI request message parameters, the second hop SCP or SEPP supports encrypting selected SBI request message parameters, and the producer NF supports handling encrypted SBI request message parameters. Fig. 9In step 1, the consumer NF 600 determines from the SCP or SEPP profile of the first-hop SCP / SEPP 101A or 126A that the first-hop SCP / SEPP 101A or 126A does not support handling encrypted SBI request message parameters. Accordingly, in step 2, the consumer NF 600 sends an SBI request with sensitive data in plain text format to the next-hop SCP / SEPP 101A or 126A. In step 3, the SCP / SEPP 101A or 126A receives the SBI request and forwards the SBI request with sensitive data in plain text format to the next-hop SCP / SEPP 101B or 126B.

[0104] In step 4, the SCP / SEPP 101B or 126B receives the SBI request message and determines from the NF or service profile of the next hop NF whether the next hop NF supports handling encrypted SBI request message parameters. In this example, the SCP / SEPP 101B or 126B determines that the producer NF 602 supports handling encrypted SBI request message parameters. Accordingly, in step 5, the SCP / SEPP 101B or 126B encrypts the selected message parameters and adds a vendor-encrypted-* header to the message based on the encrypted parameters. In step 6, the SCP / SEPP 101B or 126B sends the SBI request to the producer NF 602.

[0105] In step 7, the producer NF 602 receives the SBI request, identifies the encrypted message parameters, and decrypts the encrypted message parameters using the data in the vendor-encrypted-* header. Fig. 9 In the method shown in , when the first-hop SCP or SEPP does not support handling encrypted SBI request message parameters, the consumer NF determines not to encrypt the message parameters, and when the next-hop NF supports handling encrypted SBI request message parameters, the subsequent SCP or SEPP in the routing path of the SBI request encrypts the selected message parameters.

[0106] Fig.10 is a block diagram of network functionality that provides support for encryption of selected SBI request message parameters and handling of encrypted SBI request message parameters. Fig.10, the NF 1000 includes at least one processor 1002 and a memory 1004. The NF 1000 may be a consumer NF, a producer NF, an SCP, or a SEPP. The NF 1000 further includes an SBI request message data protector 1006. The SBI request message data protector 1006 may be implemented by the processor 1002, and is configured to receive or generate an SBI request message, identify a next hop NF of the SBI request message, determine from a registration profile of the next hop NF whether the next hop NF supports handling encrypted SBI request message parameters, and in response to determining that the next hop NF supports handling encrypted SBI request message parameters: encrypt the selected SBI request message parameters; add one or more headers to the SBI request message or update one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters; and transmit the SBI request message to the next hop NF. The SBI request message data protector 1006 may also encrypt selected SBI request message parameters and generate and add or update a vendor-encrypted-* header to the SBI request message before transmitting the message to a next-hop network function that supports handling the encrypted SBI request message parameters.

[0107] Fig.11 is a flow chart illustrating an exemplary process for protecting sensitive data to be transmitted over a 5G or subsequent generation network. Fig.11 In step 1100, the process includes receiving or generating an SBI request message. For example, the message may be initiated by a consumer NF, or may be received by an intermediate NF such as an SCP or a SEPP.

[0108] In step 1102, the process includes identifying the next hop NF for the SBI request message. If the NF originates the message, then depending on the communication model used, the NF may send the message directly to the producer NF, in which case the producer NF is the next hop NF, or to an intermediate NF, such as an SCP or SEPP. If the NF is an intermediate NF, such as an SCP, then the SCP may identify the next hop NF using a service identification parameter in the message. For example, if the producer NF is in the same network as the initiating NF, then the SCP may identify the producer NF as the next hop NF. If the SEPP receives the message, then the next hop NF will be another SEPP if the message leaves a network protected by the SEPP. If the message enters a network protected by the SEPP, then the next hop NF will be an SCP or a producer NF within the network protected by the SEPP.

[0109] In steps 1104 and 1106, the processing includes determining from the registration profile of the next hop NF whether the next hop NF supports handling encrypted SBI request message parameters. For example, the NF processing or generating the SBI request may check the NF, service, SCP or SEPP profile of the next hop NF, determine whether the NF profile contains the encryptedSensitiveData feature in the supportedVendorSpecificFeatures attribute. If the encryptedSensitiveData feature exists, then the NF may determine that the next hop NF supports handling encrypted SBI request message parameters. If the encryptedSensitiveData feature does not exist, then the NF may determine that the next hop NF does not support handling encrypted SBI request message parameters.

[0110] In step 1108, the processing includes: in response to determining that the next hop NF supports handling of encrypted SBI request message parameters, encrypting selected SBI request message parameters, adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters, and transmitting the SBI request message to the next hop NF. For example, if the NF processing or sending the SBI request determines that the next hop NF supports handling of encrypted SBI request message parameters, the NF may encrypt the SBI request message parameters that the network operator considers to contain sensitive data using a secret key shared with the next hop NF. The NF may also add or update a vendor-encrypted-* header to indicate which parameters are encrypted and include cryptographic parameters such as a key Id and a random string.

[0111] In step 1110, the process includes: in response to determining that the next hop NF does not support handling of encrypted SBI request message parameters, decrypting any encrypted SBI request message parameters in the message (i.e., those parameters encrypted by the previous hop NF), removing encryption-related headers, and transmitting the message to the next hop NF. Step 1110 will be performed for the case where an intermediate node (such as an SCP or SEPP) receives a message with encrypted SBI request message parameters and determines that the next hop does not support handling of encrypted SBI request message parameters. The encrypted parameters will be decrypted using a secret key shared with the previous hop NF. The vendor-encrypted-* header will be removed. The encrypted parameters in the message will be replaced with the decrypted parameters, and the message will be transmitted to the next hop NF in plain text format along with the SBI request message parameters.

[0112] The solution described herein is applicable to communication models A, B, C, and D defined in 3GPP TS23.501 Annex E. The solution provides encryption from any NF to any other NF, including consumer NF to producer NF, consumer NF to SCP or SEPP, SCP to SEPP, SCP to SCP, and SEPP to SCP. Therefore, if the SCP is co-located with the NF, the SCP can provide an encrypted message flow from the consumer NF to the producer NF, and vice versa. If encryption and decryption are provided by intermediate nodes (such as SCP and SEPP), the consumer and producer NFs can remain unchanged. In some embodiments, the source entity can determine which parameters are sensitive and can encrypt the selected parameters. Based on the vendor-encrypted-params header, the target entity can identify and decrypt the encrypted parameters. Similarly, the intermediate entity can encrypt additional parameters (if necessary, based on the operator policy on the intermediate node). SEPP can provide inter-PLMN protection by encrypting sensitive data. The solution can also be used to encrypt sensitive data at the interworking function (for example, at the interworking function between 4G and 5G networks). Since the solution is based on the supportedVendorSpecificFeatures attribute value, the consumer NF, SCP or SEPP can enable / disable the solution by adding or removing the attribute value from its NF, service, SCP or SEPP profile.

[0113] As described herein, selective SBI request message parameter encryption is superior to TLS-level encryption because TLS encryption requires encryption of the entire transport layer payload, which is less efficient than encrypting selected message parameters that are considered to have sensitive data. By encrypting only selected HTTP parameters and / or other 3GPP-defined subscriber or subscription identification parameters at the SBI request message level, the subject described herein is more efficient than TLS. In addition, if the jump uses the same shared secret key, the encryption performed in this article can be enabled on end-to-end or multi-hop between the producer NF and the consumer NF without intermediate decryption and re-encryption. Even if intermediate decryption and re-encryption are required, the subject described herein provides end-to-end security, while TLS is only implemented in a point-to-point manner. The current deployment of HTTP deploys NF as a sidecar, that is, as an application using HTTPs as a service, which ensures the security of sidecar communications between NF and load balancers and between load balancers and endpoints. In some cases, there may be message jumps without HTTPs security, such as in sidecar to application communications. The subject described herein provides end-to-end secure communication of sensitive data, thereby avoiding the limitations of hop-by-hop security.

[0114] While the subject matter described herein relates to intelligently and selectively encrypting and decrypting SBI request message parameters for transmission in a network, it should be understood that intelligent SBI request message encryption and decryption will also be performed in the opposite direction for SBI response messages.

[0115] The disclosure of each of the following references is hereby incorporated by reference in its entirety.

[0116] References

[0117] 1.3 rd Generation Partnership Project; Technical Specification GroupServices and System Aspects; System Architecture for the 5GSystem; Stage 2 (version 17) 3GPP TS23.501V17.6.0 (2022-06)

[0118] 2.3 rd Generation Partnership Project; Technical Specification GroupCore Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (version 17) 3GPP TS29.510V17.6.0 (2022-06)

[0119] 3. Townsley et al.; Layer Two Tunneling Protocol "L2TP", IETF RFC 2661, August 1999

[0120] 4. Jones et al., JSON Web Signature (JWS), IETF RFC 7515, May 2015

[0121] It should be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for purposes of illustration only and not for purposes of limitation, as the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for protecting sensitive data to be transmitted over a 5G or subsequent generation network, the method comprising: Receive or generate service-based interface (SBI) request messages; Identify the next hop network function (NF) of the SBI request message; Determining from the registered profile of the next-hop NF whether the next-hop NF supports handling encrypted SBI request message parameters; as well as In response to determining that the next hop NF supports handling of encrypted SBI request message parameters: Encrypt selected SBI request message parameters; adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of encrypted SBI request message parameters; as well as Transmit the SBI request message to the next hop NF.

2. The method of claim 1, wherein receiving or generating the SBI request message comprises generating the SBI request message at a consumer NF.

3. The method of claim 1 or claim 2, wherein receiving or generating the SBI request message comprises receiving or generating the SBI request message at a serving communication proxy (SCP) or a security edge protection proxy (SEPP).

4. A method as claimed in any preceding claim, wherein the registered profile comprises a profile of a next-hop NF registered with an NF Repository Function (NRF).

5. The method of any preceding claim, wherein determining whether the next-hop NF supports handling of encrypted SBI request message parameters comprises determining that the next-hop NF supports handling of encrypted SBI request message parameters, and wherein encrypting the selected SBI request message parameters comprises encrypting SBI request message parameters that the network operator deems to contain sensitive data.

6. The method of claim 5, wherein adding one or more headers to the SBI request message or updating one or more headers in the SBI request message comprises adding or updating a first header and at least one second header, the first header being used to identify the encrypted SBI request message parameters, and the at least one second header comprising at least one parameter for facilitating decryption of the encrypted SBI request message parameters.

7. A method as claimed in any preceding claim, wherein: Receiving or generating the SBI request includes receiving the SBI request, wherein the SBI request includes encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters; Determining whether the next hop NF supports handling of encrypted SBI request message parameters includes determining that the next hop NF supports handling of encrypted SBI request message parameters, and the method further includes decrypting the encrypted SBI request message parameters; and Encrypting the selected SBI request message parameters includes re-encrypting the decrypted SBI request message parameters using a secret key shared with the next hop NF; and Adding one or more headers to the SBI request message or updating one or more headers in the SBI request message includes updating the one or more headers to identify the re-encrypted SBI request message parameters and facilitating the next hop NF to decrypt the re-encrypted SBI request message parameters.

8. A method as claimed in any preceding claim: wherein receiving or generating the SBI request message comprises receiving the SBI request message, wherein the SBI request message comprises encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters; and Wherein determining whether the next hop NF supports handling the encrypted SBI request message parameters comprises determining that the next hop NF does not support handling the encrypted SBI request message parameters, and in response: decrypting the encrypted SBI request message parameters to generate plaintext SBI request message parameters; In the SBI request message, the encrypted SBI request message parameters are replaced with the plain text SBI request message parameters; as well as The SBI request message with plain text SBI request message parameters is transmitted to the next hop NF.

9. The method of claim 8, comprising detecting the presence of an encrypted SBI request message parameter using the one or more headers.

10. A method as claimed in any preceding claim, wherein the selected SBI request message parameters comprise a subscriber or subscription identification parameter defined by the Third Generation Partnership Project (3GPP) at the SBI request message level rather than at the transport layer message level.

11. A system for protecting sensitive data to be transmitted over a 5G or subsequent generation network, the system comprising: A network function (NF) comprising at least one processor; as well as A service-based interface (SBI) request message data protector implemented by the at least one processor to: receive or generate an SBI request message, identify a next-hop NF for the SBI request message, determine from a registered profile of the next-hop NF whether the next-hop NF supports handling of encrypted SBI request message parameters, and in response to determining that the next-hop NF supports handling of encrypted SBI request message parameters: encrypt selected SBI request message parameters; add one or more headers to the SBI request message or update one or more headers in the SBI request message to facilitate identification and decryption of the encrypted SBI request message parameters; And transmit the SBI request message to the next hop NF.

12. The system of claim 11, wherein the NF comprises a consumer NF.

13. The system of claim 11 or claim 12, wherein the NF comprises a service communication proxy (SCP) or a security edge protection proxy (SEPP).

14. The system of claims 11-13, wherein the registered profile comprises a profile of a next-hop NF registered with an NF Repository Function (NRF).

15. The system of claims 11-14, wherein the SBI request message data protector is configured to determine that the next-hop NF supports handling encrypted SBI request message parameters, and encrypt the SBI request message parameters that the network operator considers to contain sensitive data.

16. The system of claim 15, wherein the SBI request message data protector is configured to add or update a first header and at least one second header, the first header being used to identify the encrypted SBI request message parameters, and the at least one second header comprising at least one parameter for facilitating decryption of the encrypted SBI request message parameters.

17. The system of claims 11-16, wherein the SBI request message data protector is configured to: receiving an SBI request, wherein the SBI request includes encrypted SBI request message parameters and one or more headers including data for facilitating identification and decryption of the encrypted SBI request message parameters; Determine that the next hop NF supports handling the encrypted SBI request message parameters and decrypts the encrypted SBI request message parameters; as well as encrypting the selected SBI request message parameters by re-encrypting the decrypted SBI request message parameters using a secret key shared with the next hop NF; as well as The one or more headers are updated to identify the re-encrypted SBI request message parameters and to facilitate the next hop NF to decrypt the re-encrypted SBI request message parameters.

18. The system according to claims 11-17: wherein the SBI request message data protector is configured to receive an SBI request message, wherein the SBI request message includes encrypted SBI request message parameters and one or more headers for facilitating identification and decryption of the encrypted SBI request message parameters; and Wherein the SBI request message data protector is configured to determine that the next hop NF does not support handling of encrypted SBI request message parameters, and in response: decrypting the encrypted SBI request message parameters to generate plaintext SBI request message parameters; In the SBI request message, the encrypted SBI request message parameters are replaced with the plain text SBI request message parameters; as well as The SBI request message with plain text SBI request message parameters is transmitted to the next hop NF.

19. The system of claim 18, wherein the SBI request message data protector is configured to detect the presence of encrypted SBI request message parameters using the one or more headers.

20. A non-transitory computer readable medium having executable instructions stored thereon, wherein when the executable instructions are executed by a processor of a computer, the computer is controlled to execute the following steps: Receive or generate service-based interface (SBI) request messages; Identify the next hop network function (NF) of the SBI request message; Determining from the registered profile of the next-hop NF whether the next-hop NF supports handling encrypted SBI request message parameters; as well as In response to determining that the next hop NF supports handling of encrypted SBI request message parameters: Encrypt selected SBI request message parameters; adding one or more headers to the SBI request message or updating one or more headers in the SBI request message to facilitate identification and decryption of encrypted SBI request message parameters; as well as Transmit the SBI request message to the next hop NF.

Images