TECHNICAL FIELD

The non-limiting and exemplary embodiments of the present disclosure generally relate to the technical field of communications, and specifically to methods and apparatuses for integrity protection.

BACKGROUND

This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

In communication networks for example LTE (Long Term Evolution) and NR (new radio) as defined by 3rd Generation Partnership Project (3GPP), integrity protection may be required to enhanced security. For example, as described in 3GPP TR 33.875 VO.2.0, the disclosure of which is incorporated by reference herein in its entirety, in the case of indirect communication with an SCP (Service Communication Proxy) in the path between an NF (network function) Service Consumer and an NF Service Producer, the integrity protection of the HTTP (Hyper Text Transfer Protocol) messages is provided by TLS (Transport Layer Security) for each hop but not end-to- end between the NF Service Consumer and the NF Service Producer. Critical elements of an HTTP message that are not end-to-end integrity protected could be modified by an attacker. In more detail, a service request in indirect communication could lead to attacks by Man in the Middle, which for instance can intercept the service request and try to modify the content of the message or HTTP (custom) header. This could cause communication failure, lead to DoS (Denial- of-service) attacks. In the case of indirect communication with an SCP in the path between an NF Service Consumer and an NF Service Producer, the communication network such as 5GS (fifth generation system) should support end-to-end integrity protection of critical elements of an HTTP message while allowing the SCP to continue to perform necessary HTTP message mediation.

FIG.1 shows a flowchart of CCA based authentication with HTTP hash enhancement, which is same as Figure 6.5.2-1 of 3GPP TR 33.875 V0.2.0. CCA (Client credentials assertion) based authentication with HTTP hash enhancement can enable end-to-end integrity protection of HTTP body and method.

The core steps of this solution are: -Use Client credentials assertions (CCAs) based authentication as specified in 3GPP TS 33.501 V17.1.0 Clause 13.3.8, the disclosure of which is incorporated by reference herein in its entirety, forNF-NRF (Network Repository Function) or/and NF-NF communication.

-Enhance the Client credentials assertions (CCAs) to include a hash of the HTTP body and HTTP method to protect the message itself.

-The receiving node (NRF or NF producer) computes the hash of the HTTP body and HTTP method and validates that it is identical to the hash received in the Client credentials assertions (CCAs).

At step 1. NF service consumer sends a service request including a signed Client credentials assertion (CCA) token to authenticate against NF service producer or NRF as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8. But for this solution it is also proposed to add an optional field in CCA to protect the part of the message itself. The added field is a hash of HTTP body and HTTP method.

At step 2. NF service producer or NRF validates the CCA as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8.3. But since one optional field is supposed to be added to the CCA, the receiving end point (NF service producer or NRF) also needs to compute the hash of the HTTP body and HTTP method and validates that it is identical to the hash received in the Client credentials assertion.

At step 3. NF service producer or NRF sends a service response to NF service consumer.

The details of the hash are proposed as following:

For computation of the hash of the HTTP body and HTTP method for inclusion into the Client credential assertion, the input S to the KDF (key derivation function) specified in Annex B of 3GPP TS 33.220 V17.0.0, the disclosure of which is incorporated by reference herein in its entirety, is computed as follows:

- P0 = HTTP body;

L0 = length of the HTTP body;

- PI = HTTP method;

LI = length of HTTP method.

The input key KEY is equal to null. Note that the FC value will be allocated in the normative phase. FC is used to distinguish between different instances of the algorithm.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In 3GPP TR 33.875 VO.2.0, a solution was proposed to address the end-to-end integrity of HTTP messages, i.e. enhance the Client Credentials Assertion(CCA) to include a hash of the HTTP body and HTTP method to protect the message itself. Only one Key Derivation Function (KDF) HMAC(Hash-based Message Authentication Code)-SHA(Secure Hash Algorithm)-256 (Key, S) defined in Annex B of 3GPP TS 33.220 V17.0.0 is chosen to do the hash computing.

There are some problems for the CCA based authentication with HTTP hash enhancement. For example, the hash computing of the HTTP body and HTTP method provides the integrity protection of the HTTP message, but the hash computing shall be performed for all messages to be protected which is not a one-time task, performance will be a major concern. The performance of hash computing depends on implementation and underlying infrastructure support. For instance, SHA-512 may be faster (i.e. use fewer CPU (central processing unit) cycles) than SHA-256 on 64-bit systems as it uses a word size of 64 bits rather than the 32-bit word size used for SHA-256. And if the underlying infrastructure supports hardware acceleration of SHA-256, SHA-256 can be faster again. It means for the same NF, the performance of hash computing varies when different hash algorithm is used. Limit hash algorithm to only HMAC-SHA-256 does not provide an optimal solution for application to mitigate the performance impact when enabling the integrity protection of the HTTP message.

To overcome or mitigate at least one of above mentioned problems or other problems, the embodiments of the present disclosure propose an improved solution for integrity protection.

In a first aspect of the disclosure, there is provided a method performed by a first network function. The method comprises computing a hash related to at least a part of a service request by using a hash algorithm. The method further comprises sending the service request comprising a first token signed by the first network function to a second network function. The first token comprises the hash related to at least a part of the service request and information regarding the hash algorithm.

In an embodiment, the information regarding the hash algorithm comprises string data or integer data for indicating the hash algorithm.

In an embodiment, the method further comprises determining the hash algorithm.

In an embodiment, the hash algorithm is determined based on at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the second network function, a discovery of a profile registered by the second network function, a capacity of the second network function, or a capacity of the first network function. In an embodiment, a capacity of a network function comprises a capacity of hardware acceleration of a specific hash algorithm.

In an embodiment, the method further comprises receiving a service response comprising a second token signed by the second network function from the second network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the method further comprises validating the service response based on the second token.

In an embodiment, the second token is a client credentials assertion (CCA) token.

In an embodiment, the hash algorithm is supported by both the first network function and the second network function.

In an embodiment, the hash algorithm comprises at least one of Secure Hash Algorithm(SHA)-512, SHA-256, Hash-based Message Authentication Code (HMAC)-SHA-256, or HMAC-SHA-512.

In an embodiment, the first network function comprises a network function consumer and the second network function comprises a network function producer or a network repository function.

In an embodiment, the service request comprises a HTTP message.

In an embodiment, the first token is a CCA token.

In an embodiment, at least one service communication proxy (SCP) is used for indirect communication in a path between the first network function and the second network function.

In a second aspect of the disclosure, there is provided a method performed by a second network function. The method comprises receiving a service request comprising a first token signed by a first network function from the first network function. The first token comprises a hash related to at least a part of the service request and information regarding a hash algorithm used to compute the hash related to at least a part of the service request. The method further comprises validating the service request based on the first token.

In an embodiment, the method further comprises sending a service response comprising a second token signed by the second network function to the first network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the method further comprises determining the first hash algorithm.

In an embodiment, the method further comprises computing the hash related to the at least a part of the service response by using the first hash algorithm.

In an embodiment, the first hash algorithm is determined based on at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the first network function, a discovery of a profile registered by the first network function, a capacity of the second network function, or a capacity of the first network function.

In a third aspect of the disclosure, there is provided a first network function. The first network function comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said first network function is operative to compute a hash related to at least a part of a service request by using a hash algorithm. Said first network function is further operative to send the service request comprising a first token signed by the first network function to a second network function. The first token comprises the hash related to at least a part of the service request and information regarding the hash algorithm.

In a fourth aspect of the disclosure, there is provided a second network function. The second network function comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said second network function is operative to receive a service request comprising a first token signed by a first network function from the first network function. The first token comprises a hash related to at least a part of the service request and information regarding a hash algorithm used to compute the hash related to at least a part of the service request. Said second network function is further operative to validate the service request based on the first token.

In a fifth aspect of the disclosure, there is provided a first network function. The first network function comprises a computing module and a sending module. The computing module may be configured to compute a hash related to at least a part of a service request by using a hash algorithm. The sending module may be configured to send the service request comprising a first token signed by the first network function to a second network function. The first token comprises the hash related to at least a part of the service request and information regarding the hash algorithm.

In an embodiment, the first network function further comprises a determining module configured to determine the hash algorithm.

In an embodiment, the first network function further comprises a receiving module configured to receive a service response comprising a second token signed by the second network function from the second network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the first network function further comprises a validating module configured to validate the service response based on the second token.

In a sixth aspect of the disclosure, there is provided a second network function. The second network function comprises a receiving module and a validating module. The receiving module may be configured to receive a service request comprising a first token signed by a first network function from the first network function. The first token comprises a hash related to at least a part of the service request and information regarding a hash algorithm used to compute the hash related to at least a part of the service request. The validating module may be configured to validate the service request based on the first token

In an embodiment, the second network function further comprises a sending module configured to send a service response comprising a second token signed by the second network function to the first network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the second network function further comprises a determining module configured to determine the first hash algorithm.

In an embodiment, the second network function further comprises a computing module configured to compute the hash related to the at least a part of the service response by using the first hash algorithm.

In a seventh aspect of the disclosure, there is provided a computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first and second aspects.

In an eighth aspect of the disclosure, there is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first and second aspects.

Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, the proposed solution can optimize the performance of hash computing by selecting a most suitable hash algorithm for example according to at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the second network function, a discovery of a profile registered by the second network function, a capacity of the second network function, or a capacity of the first network function. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:

FIG.1 shows a flowchart of CCA based authentication with HTTP hash enhancement;

FIG.2 schematically shows a high level architecture in the fifth generation network according to an embodiment of the present disclosure;

FIG.3 shows a flowchart of a method according to an embodiment of the present disclosure;

FIG.4 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG.5 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG.6 shows a flowchart of CCA based authentication with HTTP hash enhancement according to an embodiment of the present disclosure;

FIG.7 shows a flowchart of CCA based authentication with HTTP hash enhancement according to another embodiment of the present disclosure;

FIG.8 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure;

FIG.9 is a block diagram showing a first network function according to an embodiment of the disclosure; and

FIG.10 is a block diagram showing a second network function according to an embodiment of the disclosure.

DETAILED DESCRIPTION

The embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.

As used herein, the term “network” refers to a network following any suitable communication standards such as new radio (NR), long term evolution (LTE), LTE-Advanced, wideband code division multiple access (WCDMA), high-speed packet access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Address (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency-Division Multiple Access (OFDMA), Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), etc. UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, Ad-hoc network, wireless sensor network, etc. In the following description, the terms “network” and “system” can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the communication protocols as defined by a standard organization such as 3GPP. For example, the communication protocols may comprise the first generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols, and/or any other protocols either currently known or to be developed in the future.

The term “network device” or “network node” or “network function (NF)” refers to any suitable network entity which can be implemented in a network entity (physical or virtual) of a communication network. For example, the network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. For example, the 5G system (5GS) may comprise a plurality of NFs such as AMF (Access and mobility Function), SMF (Session Management Function), AUSF (Authentication Service Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NEF (Network Exposure Function), UPF (User plane Function) and NRF (Network Repository Function), RAN (radio access network), SCP (service communication proxy), NWDAF (network data analytics function), NSSF (Network Slice Selection Function), NSSAAF (Network Slice-Specific Authentication and Authorization Function), etc. For example, the 4G system (such as LTE) may include MME (Mobile Management Entity), HSS (home subscriber server), Policy and Charging Rules Function (PCRF), Packet Data Network Gateway (PGW), PGW control plane (PGW-C), Serving gateway (SGW), SGW control plane (SGW-C), E-UTRAN Node B (eNB), etc. In other embodiments, the network function may comprise different types of NFs for example depending on a specific network.

The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE), or other suitable devices. The UE may be, for example, a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA), a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms “terminal device”, “terminal”, “user equipment” and “UE” may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP (3rd Generation Partnership Project), such as 3GPP’ LTE standard or NR standard. As used herein, a “user equipment” or “UE” may not necessarily have a “user” in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3 GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3 GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed terms.

As used herein, the phrase “at least one of A and B” or “at least one of A or B” should be understood to mean “only A, only B, or both A and B.” The phrase “A and/or B” should be understood to mean “only A, only B, or both A and B”.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and/or “including”, when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof.

It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar/same meanings may also be used.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a communication system complied with the exemplary system architecture illustrated in FIG.2. For simplicity, the system architectures of FIG.2 only depict some exemplary elements. In practice, a communication system may further include any additional elements suitable to support communication between terminal devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or terminal device. The communication system may provide communication and various types of services to one or more terminal devices to facilitate the terminal devices’ access to and/or use of the services provided by, or via, the communication system.

FIG.2 schematically shows a high level architecture in the fifth generation network according to an embodiment of the present disclosure. For example, the fifth generation network may be 5GS. The architecture of FIG.2 is same as Figure 4.2.3-1 as described in 3GPP TS 23.501 V17.0.0, the disclosure of which is incorporated by reference herein in its entirety. The system architecture of FIG.2 may comprise some exemplary elements such as AUSF, AMF, DN (data network), NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP (Service Communication Proxy), NSSAAF (Network Slice-Specific Authentication and Authorization Function), NSACF (Network Slice Admission Control Function), etc.

In accordance with an exemplary embodiment, the UE can establish a signaling connection with the AMF over the reference point Nl, as illustrated in FIG.2. This signaling connection may enable NAS (Non-access stratum) signaling exchange between the UE and the core network, comprising a signaling connection between the UE and the (R)AN and the N2 connection for this UE between the (R)AN and the AMF. The (R)AN can communicate with the UPF over the reference point N3. The UE can establish a protocol data unit (PDU) session to the DN (data network, e.g. an operator network or Internet) through the UPF over the reference point N6.

As further illustrated in FIG.2, the exemplary system architecture also contains the service- based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf, Nnsacf and Nsmf exhibited by NFs such as the NRF, the NEF, the AUSF, the UDM, the PCF, the AMF, the NSACF and the SMF. In addition, FIG.2 also shows some reference points such as Nl, N2, N3, N4, N6 and N9, which can support the interactions between NF services in the NFs. For example, these reference points may be realized through corresponding NF service-based interfaces and by specifying some NF service consumers and providers as well as their interactions in order to perform a particular system procedure.

Various NFs shown in FIG.2 may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP, NSACF may include the functionality for example as defined in clause 6.2 of 3GPP TS 23.501 V17.0.0 . FIG.3 shows a flowchart of a method according to an embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network function or communicatively coupled to the first network function. As such, the apparatus may provide means or modules for accomplishing various parts of the method 300 as well as means or modules for accomplishing other processes in conjunction with other components.

The first network function may be any suitable network device or node or entity or function which needs to use a service provided by another network function. For example, the first network function may be a consumer of a network function service producer.

At block 302, optionally, the first network function may determine a hash algorithm. The hash algorithm may be used to compute a hash related to at least a part of a service request. The first network function may determine the hash algorithm in various ways, such as by configuration, negotiation, etc.

The hash algorithm may comprise any suitable hash algorithm. In an embodiment, the hash algorithm comprises at least one of Secure Hash Algorithm (SHA)-512, SHA-256, Hash-based Message Authentication Code (HMAC)-SHA-256, or HMAC-SHA-512.

In an embodiment, the hash algorithm may be determined based on at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the second network function, a discovery of a profile registered by the second network function, a capacity of the second network function, or a capacity of the first network function.

For example, the supported hash algorithms may be included in a predefined list, which does not limit to HMAC-SHA-256 and can also include some other hash algorithms like HMAC-SHA- 512 or SHA-512, etc. The predefined list may be configured to the network function. Different NFs may have respective predefined list.

The selection of hash algorithm shall be aligned between (HTTP) message sender and (HTTP) message receiver, i.e., the hash algorithm shall be supported by both sides. For instance, the hash algorithm can be aligned by local configuration or by dynamic negotiation procedure between the message sender (such as NF service consumer and NF service producer or NRF) and the message receiver(such as NF service producer or NRF).

In an embodiment, the first network function may determine the hash algorithm based on the local configuration of the first network function. For example, when the first network function is configured with one hash algorithm, the first network function may select the configured hash algorithm. When the first network function is configured with multiple hash algorithms for example in a preferred order, the first network function may select a preferred hash algorithm according to the preferred order. In an embodiment, the first network function may determine the hash algorithm based on the local configuration of the second network function. In this embodiment, the first network function may obtain the local configuration of the second network function. For example, when the second network function is configured with one hash algorithm, the first network function may select the configured hash algorithm. When the second network function is configured with multiple hash algorithms for example in a preferred order, the first network function may select a preferred hash algorithm according to the preferred order.

In an embodiment, the first network function may determine the hash algorithm based on the local configuration of the first network function and the local configuration of the second network function. In this embodiment, the hash algorithm shall be supported by both sides. For example, the first network function may select a preferred hash algorithm supported by both sides.

In an embodiment, the first network function may determine the hash algorithm based on a negotiation between the first network function and the second network function.

In an embodiment, the first network function may determine the hash algorithm based on a discovery of a profile registered by the second network function. For example, the profile registered by the second network function may include information regarding the supported or preferred hash algorithm(s) of the second network function. The first network function may determine the hash algorithm based on the discovery of a profile registered by the second network function.

In an embodiment, the first network function may determine the hash algorithm based on the capacity of the second network function and/or the capacity of the first network function. For example, the performance of hash computing may depend on implementation and underlying infrastructure support. For instance, SHA-512 may be faster (i.e. use fewer CPU cycles) than SHA-256 on 64-bit systems as it uses a word size of 64 bits rather than the 32-bit word size used for SHA-256. And if the underlying infrastructure supports hardware acceleration of SHA-256, SHA-256 can be faster again. It means for the same NF, the performance of hash computing varies when different hash algorithm is used. When the first network function obtains information regarding the capacity of the second network function and/or the capacity of the first network function, it may determine the hash algorithm based on the capacity of the second network function and/or the capacity of the first network function.

In an embodiment, a capacity of a network function comprises a capacity of hardware acceleration of a specific hash algorithm.

In an embodiment, the hash algorithm is supported by both the first network function and the second network function. At block 304, the first network function may compute a hash related to at least a part of a service request by using the hash algorithm. The service request may be any suitable service request. In an embodiment, the service request may comprise a HTTP message. The part of a service request may be any suitable part of the service request. In an embodiment, when the service request is the HTTP message, the part of the service request may comprise the HTTP body and HTTP method.

In an embodiment, the KDF (key derivation function) specified in Annex B of 3 GPP TS 33.220 V17.0.0 may be used to do the hash computing except that the hash algorithm may be replaced with the hash algorithm of block 304.

At block 306, the first network function may send the service request comprising a first token signed by the first network function to a second network function. The first token comprises the hash related to at least a part of the service request and information regarding the hash algorithm. In an embodiment, the first token is a CCA token.

In an embodiment, the first network function comprises a network function consumer. In an embodiment, the second network function comprises a network function producer or a network repository function.

In an embodiment, at least one service communication proxy (SCP) is used for indirect communication in a path between the first network function and the second network function.

The information regarding the hash algorithm may comprise any suitable information for indication the hash algorithm. In an embodiment, the information regarding the hash algorithm comprises string data or integer data for indicating the hash algorithm. For example, a new attribute in the definition of type ClientCredentialsAssertion can be defined as a string data type or an integer data type, to indicate which hash algorithm is used by the first network function such as NF service consumer when generating the hash value.

FIG.4 shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a first network function or communicatively coupled to the first network function. As such, the apparatus may provide means or modules for accomplishing various parts of the method 400 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.

At block 402, the first network function may receive a service response comprising a second token signed by the second network function from the second network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm. In an embodiment, the first hash algorithm may be the hash algorithm as determined in block 302 of FIG.3. In another embodiment, the first hash algorithm may be the hash algorithm as determined in block 506 of FIG.5. For example, similar to the first network function, the second network function may determine the hash algorithm and compute a hash related to at least a part of a service response by using the hash algorithm and generate the second token. In an embodiment, the service response may be a successful response having CCA.

In an embodiment, the second token is a client credentials assertion (CCA) token.

At block 404, the first network function may validate the service response based on the second token. For example, the first network function such as NF service consumer may validate the CCA as described in 3GPP 33.501 Clause 13.3.8.3. But since one optional field is supposed to be added to the CCA, the receiving end point (the first network function) also needs to compute the hash related to at least a part of a service response (such as the HTTP body and HTTP method) with the hash algorithm indicated in the CCA, and validates that it is identical to the hash received in the Client credentials assertion.

FIG.5 shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a second network function or communicatively coupled to the second network function. As such, the apparatus may provide means or modules for accomplishing various parts of the method 500 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.

At block 502, the second network function may receive a service request comprising a first token signed by a first network function from the first network function. The first token comprises a hash related to at least a part of the service request and information regarding a hash algorithm used to compute the hash related to at least a part of the service request. For example, the first network function may send the service request comprising a first token signed by the first network function to the second network function at block 306 of FIG.3, and the second network function may receive the service request from the first network function. In an embodiment, the first token is a client credentials assertion (CCA) token.

At block 504, the second network function may validate the service request based on the first token. For example, the second network function such as NF service producer or NRF may validate the CCA as described in 3GPP 33.501 Clause 13.3.8.3. But since one optional field is supposed to be added to the CCA, the receiving end point (the second network function) also needs to compute the hash related to at least a part of the service request (such as the HTTP body and HTTP method) with the hash algorithm indicated in the CCA, and validates that it is identical to the hash received in the Client credentials assertion. At block 506, optionally, the second network function may determine a first hash algorithm. In an embodiment, the first hash algorithm may be the hash algorithm as determined by the first network function in block 302 of FIG.3. In this embodiment, the second network function may just reuse the hash algorithm used by the first network function and does not need do a determination again. In another embodiment, the first hash algorithm may be the hash algorithm determined by the second network function for example based on at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the first network function, a discovery of a profile registered by the first network function, a capacity of the second network function, or a capacity of the first network function. In this embodiment, the second network function may do the determination again, which may lead to a different hash algorithm. For example, it is possible to use different hash algorithm for the service response than the service request.

At block 508, optionally, the second network function may compute the hash related to the at least a part of the service response by using the first hash algorithm. For example, similar to the first network function, the second network function may compute a hash related to at least a part of a service response by using the first hash algorithm and generate the second token. In an embodiment, the KDF (key derivation function) specified in Annex B of 3GPP TS 33.220 V17.0.0 may be used to do the hash computing except that the hash algorithm may be replaced with the first hash algorithm of block 506. Alternatively the second network function may send a service response without the second token to the first network function.

At block 510, optionally, the second network function may send a service response comprising a second token signed by the second network function to the first network function. The second token comprises a hash related to at least a part of the service response and information regarding the first hash algorithm.

FIG.6 shows a flowchart of CCA based authentication with HTTP hash enhancement according to an embodiment of the present disclosure.

At step 601. NF service consumer selects a hash algorithm, does the hash computing related to a part of service request (such as the HTTP body and HTTP method of the service request), and includes information regarding the used hash algorithm as an optional field in the CCA. In an embodiment, the KDF specified in Annex B of 3GPP TS 33.220 V17.0.0 may be used to do the hash computing except that the hash algorithm may be replaced with the hash algorithm of block 601.

At step 602. NF service consumer sends, to the NF service producer or NRF, the service request including a signed Client credentials assertion (CCA) token to authenticate against NF service producer or NRF as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8. In 3GPP TR 33.875 VO.2.0, it is proposed to add an optional field in CCA to protect the part of the message itself. The added field is a hash of HTTP body and HTTP method of the service request. In the present embodiment, the information regarding the used hash algorithm is also included in the CCA as an optional field.

At step 603. NF service producer or NRF validates the CCA as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8.3. But since an optional field regarding the used hash algorithm is supposed to be added to the CCA, the receiving end point (NF service producer or NRF) also needs to compute the hash related to the part of service request (such as the HTTP body and HTTP method) with the hash algorithm indicated in the CCA, and validates that it is identical to the hash received in the Client credentials assertion.

At step 604. NF service producer or NRF sends a service response to the NF service consumer.

FIG.7 shows a flowchart of CCA based authentication with HTTP hash enhancement according to another embodiment of the present disclosure.

At step 701. NF service consumer selects a hash algorithm, does the hash computing related to a part of service request (such as the HTTP body and HTTP method of the service request), and includes information regarding the used hash algorithm as an optional field in the CCA. In an embodiment, the KDF specified in Annex B of 3GPP TS 33.220 V17.0.0 may be used to do the hash computing except that the hash algorithm may be replaced with the hash algorithm of block 601.

At step 702. NF service consumer sends, to the NF service producer or NRF, the service request including a signed Client credentials assertion (CCA) token to authenticate against NF service producer or NRF as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8. In 3GPP TR 33.875 V0.2.0, it is proposed to add an optional field in CCA to protect the part of the message itself. The added field is a hash related to HTTP body and HTTP method of the service request. In the present embodiment, the information regarding the used hash algorithm is also included in the CCA as an optional field.

At step 703. NF service producer or NRF validates the CCA as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8.3. But since an optional field regarding the used hash algorithm is supposed to be added to the CCA, the receiving end point (NF service producer or NRF) also needs to compute the hash related to the part of service request (such as the HTTP body and HTTP method) with the hash algorithm indicated in the CCA, and validates that it is identical to the hash received in the Client credentials assertion.

At step 704. NF service producer or NRF does the hash computing related to a part of service response (such as the HTTP body and HTTP method of the service response) by using the hash algorithm, and includes the used hash algorithm as an optional field in the CCA. At step 705. NF service producer or NRF sends, to the NF service consumer, the service response including a signed Client credentials assertion (CCA) token to authenticate against the NF service consumer as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8. It is proposed to add an optional field in CCA to protect the part of the message itself. The added field is a hash related to HTTP body and HTTP method of the service response. In the present embodiment, the information regarding the used hash algorithm is also included in the CCA as an optional field.

At step 706. the NF service consumer validates the CCA as described in 3GPP TS 33.501 V17.1.0 Clause 13.3.8.3. But since one optional field is supposed to be added to the CCA, the receiving end point (NF service consumer) also needs to compute the hash related to the part of service response (such as the HTTP body and HTTP method) with the hash algorithm indicated in the CCA, and validates that it is identical to the hash received in the Client credentials assertion.

In an embodiment, Table 5.2.3.2.11-1 of 3GPP TS 29.500 V17.2.0, the disclosure of which is incorporated by reference herein in its entirety, may be amended as following.

Table 5.2.3.2.11 -1: Definition of type ClientCredentialsAssertion

In an embodimnt, an optional field may be added in the Client Credentials Assertion (CCA) to indicate what hash algorithm is in use. This new attribute “halg” is added to the definition of type ClientCredentialsAssertion described in 3GPP TS 29.500 V17.2.0 Table 5.2.3.2.11 -1.

Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, the proposed solution can optimize the performance of hash computing by selecting a most suitable hash algorithm for example according to at least one of a local configuration of the first network function, a local configuration of the second network function, a negotiation between the first network function and the second network function, a discovery of a profile registered by the second network function, a capacity of the second network function, or a capacity of the first network function. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

FIG.8 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure. For example, any one of the first network function or the second network function described above may be implemented as or through the apparatus 800.

The apparatus 800 comprises at least one processor 821, such as a digital processor (DP), and at least one memory (MEM) 822 coupled to the processor 821. The apparatus 800 may further comprise a transmitter TX and receiver RX 823 coupled to the processor 821. The MEM 822 stores a program (PROG) 824. The PROG 824 may include instructions that, when executed on the associated processor 821, enable the apparatus 800 to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor 821 and the at least one MEM 822 may form processing means 825 adapted to implement various embodiments of the present disclosure.

Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor 821, software, firmware, hardware or in a combination thereof.

The MEM 822 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.

The processor 821 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non limiting examples.

In an embodiment where the apparatus is implemented as or at the first network function, the memory 822 contains instructions executable by the processor 821, whereby the first network function operates according to any of the methods related to the first network function as described above.

In an embodiment where the apparatus is implemented as or at the second network function, the memory 822 contains instructions executable by the processor 821, whereby the second network function operates according to any of the methods related to the second network function as described above. FIG.9 is a block diagram showing a first network function according to an embodiment of the disclosure. As shown, the first network function 900 comprises a computing module 901 and a sending module 902. The computing module 901 may be configured to compute a hash related to at least a part of a service request by using a hash algorithm. The sending module 902 may be configured to send the service request comprising a first token signed by the first network function to a second network function. The first token comprises the hash related to at least a part of the service request and information regarding the hash algorithm.

In an embodiment, the first network function 900 further comprises a determining module 903 configured to determine the hash algorithm.

In an embodiment, the first network function 900 further comprises a receiving module 904 configured to receive a service response comprising a second token signed by the second network function from the second network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the first network function 900 further comprises a validating module 905 configured to validate the service response based on the second token.

FIG.10 is a block diagram showing a second network function according to an embodiment of the disclosure. As shown, the second network function 1000 comprises a receiving module 1001 and a validating module 1002. The receiving module 1001 may be configured to receive a service request comprising a first token signed by a first network function from the first network function. The first token comprises a hash related to at least a part of the service request and information regarding a hash algorithm used to compute the hash related to at least a part of the service request. The validating module 1002 may be configured to validate the service request based on the first token

In an embodiment, the second network function 1000 further comprises a sending module 1003 configured to send a service response comprising a second token signed by the second network function to the first network function. The second token comprises a hash related to at least a part of the service response and information regarding a first hash algorithm.

In an embodiment, the second network function further comprises a determining module 1004 configured to determine the first hash algorithm.

In an embodiment, the second network function further comprises a computing module 1005 configured to compute the hash related to the at least a part of the service response by using the first hash algorithm.

The term unit or module may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

With function units, the first network function or the second network function may not need a fixed processor or memory, any computing resource and storage resource may be arranged from the first network function or the second network function in the communication system. The introduction of virtualization technology and network computing technology may improve the usage efficiency of the network resources and the flexibility of the network.

According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods as described above.

According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods as described above.

In addition, the present disclosure may also provide a carrier containing the computer program as mentioned above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory), a ROM (read only memory), Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.