Verification of NF instance identifiers in digital certificate issuance using the ACME protocol

Abstract

Certificate management using the Automatic Certificate Management Environment (ACME) protocol in a 5G network. In one embodiment, a network function (NF) of the 5G network operates an ACME client to obtain a digital certificate from a certificate authority via the ACME protocol for secure communication within the NF. The ACME client is configured to send a certificate request indicating an NF instance identifier to the certificate authority, receive an ACME challenge from the certificate authority, and, in response to the ACME challenge, write the NF instance identifier in encrypted form or a previously issued certificate to a server under the security domain of the NF.

Description

Technical Field

[0001] This disclosure relates to the field of communication systems, and in particular to next-generation networks. Background Technology

[0002] Next-generation networks, such as fifth-generation (5G), represent the next major phase of mobile telecommunications standards, surpassing fourth-generation (4G) standards. Compared to 4G networks, next-generation networks can offer enhancements in radio access and network architecture. Next-generation networks aim to utilize new areas of the radio spectrum for radio access networks (RANs), such as millimeter-wave bands.

[0003] With the widespread use of mobile networks across the country and the world, communications may be intercepted or subjected to other types of attacks. To ensure security and privacy, the 3rd Generation Partnership Project (3GPP) has developed security mechanisms and security processes for 5G mobile networks. Given the importance of security in 5G systems and later versions, continued development of even more robust security mechanisms is expected.

[0004] The Service-Based Architecture (SBA) of the 5G core network consists of multiple services provided by Network Functions (NFs). Digital certificates can be used by NFs and other SBA components to encrypt internal and external communications, preventing attackers from intercepting and stealing sensitive data. A digital certificate is a data file containing information used to verify the identity of a server or device, a public key, a statement from the Certificate Authority (CA) that issued the digital certificate, an expiration date, and other information. While digital certificates provide protection between valid NFs, a potential problem is that a malicious NF could request a digital certificate from a Certificate Authority. Summary of the Invention

[0005] This document describes the certificate management process in 5G networks. As an overview, the Automated Certificate Management Environment (ACME) protocol can be used as the protocol for the certificate management process. The ACME client of the NF sends a certificate request to the Certificate Authority and receives an ACME challenge. In response to the ACME challenge, the ACME client provides the server with the NF's "verified" or "trusted" NF instance identifier (ID), which can be retrieved by the Certificate Authority. For example, the ACME client can encrypt the NF instance ID using a private key. In another example, the ACME client can provide a previously issued digital certificate that includes the verifiable NF instance ID. The Certificate Authority's ACME server can then verify the identity of the requesting NF by comparing the "verified" or "trusted" NF instance ID with the NF instance ID provided in the certificate request. One technical benefit is that the Certificate Authority is able to verify or confirm the identity of the requesting NF before issuing a digital certificate to it. This ensures that the Certificate Authority does not issue digital certificates to NF instance IDs that have been leaked.

[0006] In one embodiment (also referred to as an aspect), an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, implement a network function (NF) of a 5G network. The network function is configured to operate an ACME client to obtain a digital certificate from a certificate authority via the ACME protocol for secure communication by the NF. The ACME client is configured to send a certificate request to the certificate authority, indicating an NF instance identifier, receive an ACME challenge from the certificate authority, and, in response to the ACME challenge, write the NF instance identifier in encrypted form or a previously issued certificate to a server under the NF's security domain.

[0007] In one embodiment, the ACME challenge includes a Hypertext Transfer Protocol challenge, and the ACME client is also configured to write the NF instance identifier in encrypted form or to write a previously issued certificate along with a token to the web server.

[0008] In one embodiment, the ACME challenge includes a Domain Name System (DNS) challenge, and the ACME client is further configured to write the NF instance identifier in encrypted form or to write a previously issued certificate into a record on the DNS server.

[0009] In one embodiment, the ACME challenge includes an application layer protocol negotiation challenge, and the ACME client is further configured to write the NF instance identifier in encrypted form or to write a previously issued certificate along with a token to the application layer protocol negotiation server.

[0010] In one embodiment, the ACME client is supplied with an NF identifier encryption key, and the ACME client is also configured to encrypt the NF instance identifier based on the NF identifier encryption key.

[0011] In one embodiment, the ACME client is also configured to calculate a holding proof signature based on a private key associated with a previously issued certificate, and write the holding proof signature together with the previously issued certificate to the server.

[0012] In one embodiment, a method for performing certificate management in a NF (Network Function) of a 5G network includes: operating an ACME client at the NF to obtain a digital certificate from a Certificate Authority (CA) via the ACME protocol for secure communication within the NF. The operation includes sending a certificate request to the CA, the certificate request indicating an NF instance identifier; receiving an ACME challenge from the CA; and, in response to the ACME challenge, writing the NF instance identifier in encrypted form or a previously issued certificate to a server under the NF's security domain.

[0013] In one embodiment, the ACME challenge includes a Hypertext Transfer Protocol challenge, and writing includes writing the NF instance identifier in encrypted form or writing a previously issued certificate along with a token to the web server.

[0014] In one embodiment, the ACME challenge includes a Domain Name System (DNS) challenge, and writing includes writing the NF instance identifier in encrypted form or writing a previously issued certificate to the DNS server.

[0015] In one embodiment, the ACME challenge includes an application layer protocol negotiation challenge, and writing includes writing the NF instance identifier in encrypted form or writing a previously issued certificate along with a token to the application layer protocol negotiation server.

[0016] In one embodiment, the ACME client is supplied with an NF identifier encryption key, and the method further includes encrypting the NF instance identifier based on the NF identifier encryption key.

[0017] In one embodiment, the method further includes calculating a holding proof signature based on a private key associated with a previously issued certificate, and writing the holding proof signature together with the previously issued certificate to a server.

[0018] In one embodiment, an apparatus includes at least one processor and at least one memory storing instructions, which, when executed by the at least one processor, implement a certificate authority configured to operate an ACME server. The ACME server is configured to receive a certificate request for a digital certificate from an NF (Network Function) in a 5G network, wherein the certificate request indicates an NF instance identifier. The ACME server is also configured to send an ACME challenge to the NF challenging the NF to prove control of a domain, retrieve an encrypted NF instance identifier or a previously issued certificate from a server under the NF's domain, perform a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier upon decryption, or matches an verified NF instance identifier from a previously issued certificate, and issue a digital certificate to the NF when the verification process passes.

[0019] In one embodiment, the ACME challenge includes a Hypertext Transfer Protocol challenge, and the ACME server is also configured to retrieve an encrypted NF instance identifier or a previously issued certificate and token from the Uniform Resource Locator of the web server.

[0020] In one embodiment, the ACME challenge includes a Domain Name System (DNS) challenge, and the ACME server is also configured to retrieve an encrypted NF instance identifier or a previously issued certificate from a DNS server record.

[0021] In one embodiment, the ACME challenge includes an application layer protocol negotiation challenge, and the ACME server is also configured to perform a transport layer security handshake with the application layer protocol negotiation server to retrieve an encrypted NF instance identifier or a previously issued certificate and token.

[0022] In one embodiment, the ACME server is supplied with an NF identifier decryption key, and the ACME server is also configured to decrypt the encrypted NF instance identifier based on the NF identifier decryption key, and to compare the decrypted NF instance identifier with the NF instance identifier in the certificate request.

[0023] In one embodiment, the ACME server is further configured to retrieve a first proof of holding signature calculated by the NF based on the private key associated with the previously issued certificate, calculate a second proof of holding signature based on the public key associated with the previously issued certificate, compare the first proof of holding signature with the second proof of holding signature to verify the trust of the previously issued certificate, and compare the NF instance identifier of the previously issued certificate with the NF instance identifier in the certificate request.

[0024] In one embodiment, a method for performing certificate management includes: operating an ACME server at a certificate authority. The operation includes receiving a certificate request for a digital certificate from an NF (Network Function) in a 5G network, wherein the certificate request indicates an NF instance identifier. The method further includes sending an ACME challenge to the NF challenging the NF to prove control over a domain, retrieving an encrypted NF instance identifier or a previously issued certificate from a server under the NF's domain, performing a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier upon decryption, or matches an verified NF instance identifier from a previously issued certificate, and issuing a digital certificate to the NF when the verification process passes.

[0025] In one embodiment, the ACME challenge includes a Hypertext Transfer Protocol challenge, and retrieval includes retrieving an encrypted NF instance identifier or a previously issued certificate and token from the Uniform Resource Locator of the web server.

[0026] In one embodiment, the ACME challenge includes a Domain Name System (DNS) challenge, and retrieval includes retrieving an encrypted NF instance identifier or a previously issued certificate from a DNS server record.

[0027] In one embodiment, the ACME challenge includes an application layer protocol negotiation challenge, and retrieval includes performing a transport layer security handshake with the application layer protocol negotiation server to retrieve the encrypted NF instance identifier or the previously issued certificate and token.

[0028] In one embodiment, the ACME server is provided with an NF identifier decryption key, and the method further includes decrypting the encrypted NF instance identifier based on the NF identifier decryption key, and comparing the decrypted NF instance identifier with the NF instance identifier in the certificate request.

[0029] In one embodiment, the method further includes retrieving a first proof of holding signature calculated by the NF based on a private key associated with a previously issued certificate, calculating a second proof of holding signature based on a public key associated with the previously issued certificate, comparing the first proof of holding signature with the second proof of holding signature to verify trust in the previously issued certificate, and comparing the NF instance identifier of the previously issued certificate with the NF instance identifier in the certificate request.

[0030] In one embodiment, an apparatus includes a network function (NF) of a 5G network. The NF includes components for obtaining a digital certificate from a certificate authority via the ACME protocol for secure communication within the NF. The NF includes components for sending a certificate request to the certificate authority, the certificate request indicating an NF instance identifier; components for receiving an ACME challenge from the certificate authority; and components for, in response to the ACME challenge, writing the NF instance identifier in encrypted form or writing a previously issued certificate to a server within the NF's security domain.

[0031] In one embodiment, an apparatus includes a Certificate Authority (CA), comprising components for receiving a certificate request for a digital certificate from a network function of a 5G network, wherein the certificate request indicates an NF instance identifier. The CA includes components for sending an ACME challenge to the NF to challenge the NF's proof of control over a domain, components for retrieving an encrypted NF instance identifier or a previously issued certificate from a server under the NF's domain, components for performing a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier upon decryption, or whether it matches a verified NF instance identifier from a previously issued certificate, and components for issuing a digital certificate to the NF if the verification process passes.

[0032] Other embodiments may include computer-readable media, other systems or apparatuses, or other methods as described below. Furthermore, one or more embodiments as described above may be combined as illustrated herein.

[0033] The foregoing summary provides a basic understanding of some aspects of this specification. This summary is not a broad overview of the specification. It is not intended to identify key or essential elements of the specification, nor to depict any scope of any particular embodiment or claim. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that follows. Attached Figure Description

[0034] Some embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings. The same reference numerals denote the same elements or elements of the same type throughout all the drawings.

[0035] Figure 1 The high-level architecture of the 5G system is shown.

[0036] Figure 2 The non-roaming architecture of a 5G system is shown.

[0037] Figure 3 This illustrates the interaction between NF service consumers and NF service producers.

[0038] Figure 4 The "request-response" NF service mechanism is shown.

[0039] Figure 5 The NRF that maintains the NF configuration file is shown.

[0040] Figure 6 The security architecture of the 5G system is shown.

[0041] Figure 7 The SBI protocol stack is shown.

[0042] Figure 8 The TLS handshake process between NFs is shown.

[0043] Figure 9 The certificate registration process is shown.

[0044] Figure 10 The initial trust general pattern is shown.

[0045] Figure 11 The process of establishing initial trust is illustrated.

[0046] Figure 12 This is a block diagram of NF and Certificate Authority in an illustrative embodiment.

[0047] Figure 13 Certificate management is illustrated in an illustrative embodiment.

[0048] Figures 14A to 14D This is a flowchart illustrating a method for performing certificate management in an illustrative embodiment.

[0049] Figure 15 This is a block diagram illustrating the domains of NF in an illustrative embodiment.

[0050] Figure 16 An HTTP challenge method is illustrated in an illustrative embodiment.

[0051] Figure 17 A DNS challenge method is illustrated in an illustrative embodiment.

[0052] Figure 18 The ALPN challenge method in an illustrative embodiment is shown.

[0053] Figure 19-22 This is a message diagram illustrating the certificate management process in an illustrative embodiment. Detailed Implementation

[0054] The accompanying drawings and the following description illustrate specific exemplary embodiments. Therefore, it should be understood that those skilled in the art will be able to design various arrangements, which, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments and should be construed as not being limited to these specifically enumerated examples and conditions. Therefore, the inventive concept is not limited to the specific embodiments or examples described below, but is defined by the claims and their equivalents.

[0055] Figure 1 The high-level architecture of a 5G system 100 is illustrated. The 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) comprising a 5G access network ((R)AN) 102 (generally referred to herein as RAN) and a 5G core network (5GC) 104, which communicates with 5G user equipment (UE) 106. RAN 102 and 5GC 104 together may be referred to as a 5G network 101, a 5G mobile network, a 5G communication network, etc. Although the term "5G" is used herein, any next-generation network beyond 5G is also considered.

[0056] RAN 102 provides radio or wireless connectivity to UE 106 and connects UE 106 to 5GC 104. RAN 102 may include a Next Generation Radio Access Network (NG-RAN), a non-3GPP access network, and / or another type of RAN connected to 5GC 104. RAN 102 may support Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., via eNodeB (eNB), gNodeB (gNB), and / or ng-eNodeB (ng-eNB)), Wireless Local Area Network (WLAN) access, Satellite Radio Access, New Radio Access Technology (RAT), etc. The 5G access network may also support fixed access. 5GC 104 interconnects RAN 102 with Data Network (DN) 108. 5GC 104 consists of Network Function (NF) 110, which may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, as a virtualized function instantiated on an appropriate platform (e.g., cloud infrastructure), etc. Data network 108 can be a public or private data network outside the operator, or an internal data network within the operator (e.g., for IP Multimedia Subsystem (IMS) services). UE 106 (also referred to as a mobile terminal) includes 5G-capable devices configured to register with 5GC 104 to access services. UE 106 may include end-user equipment such as mobile phones (e.g., smartphones), tablets, computers with mobile broadband adapters, etc. UE 106 can be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, and / or other services.

[0057] Figure 2 The service-based architecture 200 (SBA) of the 5G system 100 is shown, as further described in 3GPP TS 23.501 (v18.2.0), which is incorporated herein by reference as if fully contained herein. Figure 2The SBA 200 in the diagram illustrates a non-roaming scenario. The SBA 200 consists of Network Functions (NFs) 110 for the 5GC 104, and the NFs 110 for the Control Plane (CP) are separate from the User Plane (UP). For example, the Control Plane of the 5GC 104 includes Authentication Server Function (AUSF) 210, Access and Mobility Management Function (AMF) 212, Session Management Function (SMF) 214, Policy Control Function (PCF) 216, Unified Data Management (UDM) 218, Network Slice Selection Function (NSSF) 220, and Application Function (AF) 222. The Control Plane of the 5GC 104 also includes Network Exposure Function (NEF) 224, NF Repository Function (NRF) 226, Service Communication Broker (SCP) 228, Network Slice Admission Control Function (NSACF) 230, Network Slice-Specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and Edge Application Server Discovery Function (EASDF) 234. The user plane of the 5GC 104 includes one or more user plane functions (UPFs) 240 that communicate with the data network 108. The UE 106 is able to access the control plane and user plane of the 5GC 104 via the RAN 102.

[0058] In SBA 200, system functionality is achieved by a set of NF110s providing services to other authorized NF110s to access their services. An NF service is a capability that an NF110 (NF service producer) exposes to other authorized NFs (NF service consumers) through a service-based interface. For example, the list of NF services is provided in Clause 7 of 3GPP TS 23.501. The Service-Based Interface (SBI) 250 indicates how a given NF110 provides or exposes a set of services. The roles of NF110s within 5GC 104 can be defined as service consumers and service producers, such as... Figure 3 As shown. NF service producer 304 is NF110 that opens NF service 310, while NF service consumer 302 is NF110 that requests NF service 310. NF service 310 can communicate directly between NF service consumer 302 and NF service producer 304 via service-based interface (SBI) 250. NF service 310 can also communicate indirectly between NF service consumer 302 and NF service producer 304 via SCP 228. Figure 3 (Not shown in the image). End-to-end interactions between two NF110s (consumer and producer) within the NF service framework follow two mechanisms: "request-response" and "subscription-notification". Figure 4This illustrates a request-response NF service mechanism. NF service consumer 302 sends a request 410 for a specific NF service to NF service producer 304. NF service producer 304 provides NF service 310 based on the request 410 from NF service consumer 302. To satisfy the request 410, NF service producer 304 may instead consume NF services from other NFs 110. In this request-response mechanism, a one-time response 412 from NF service producer 304 to NF service consumer 302 is expected within a certain timeframe.

[0059] Figure 5 NRF 226, which maintains NF profile 520, is illustrated. As described in 3GPP TS 29.510 (v.18.4.0), which is incorporated herein by reference as if fully contained herein, NRF 226 is the network entity in 5GC 104 that maintains NF profile 520, which maintains available NF instances and the services they support. An NF instance is defined as an identifiable instance of NF 110. In SBA 200, NF 110 can be composed of various microservices that automatically discover each other and utilize the services provided by each other. Therefore, NF 110 can consist of multiple services, each of which may have many instances. As described in 3GPP, SBA can be implemented as a service mesh architecture. A service mesh describes a network of microservices where applications are shared and interaction between applications is possible. NRF 226 acts as a central registry for storing or maintaining information about NF 110 and the services supported by NF 110. The data structure of NF configuration file 520 is specified in section 6.1.6.2.2 of 3GPP TS 29.510, including the NF instance identifier (ID) (i.e., "nfInstanceId"), the NF type (i.e., "nfType") indicating the type of NF 110 (e.g., AMF, AUSF, UDM, etc.), and the list of NF service instances supported by the NF (i.e., "nfServices"). The NF instance ID is a unique identifier (i.e., a string) for the NF instance, and the format of the NF instance ID can be a Universally Unique Identifier (UUID).

[0060] For example, NRF 226 provides services such as Nnrf_NFManagement and Nnrf_NFDiscovery to NF service consumers 302 and NF service producers 304. The Nnrf_NFManagement service allows NF 110 to register, update, or deregister its NF profile 520 in NRF 226. One of the Nnrf_NFManagement services is a registration operation (i.e., NFRegister), in which NF service producer 304 registers with NRF 226 (1). The registration operation provides NRF 226 with the NF profile 520 of NF service producer 304, and NRF 226 marks NF service producer 304 as discoverable by other NF 110s. Another of the Nnrf_NFManagement services is an update operation (i.e., NFUpdate), in which NF service producer 304 uses the update operation to update its NF profile 520 (1).

[0061] The Nnrf_NFDiscovery service allows NF 110 to discover services offered by another NF 110 by querying NRF 226. The service operation defined for the Nnrf_NFDiscovery service is a discovery service operation (i.e., NFDiscover). NF service consumer 302 uses the discovery service operation to query NRF 226 (2) and identify other NF 110s (i.e., NF service producers 304) in the same Public Land Mobile Network (PLMN) or another PLMN. The discovery service operation discovers a group of NF 110s, represented by their NF profile 520, which are currently registered in NRF 226 and satisfy multiple input parameters. In response to the discovery service request, NRF 226 provides NF service consumer 302 with information about NF 110s that match the input parameters. Queries to NRF 226 can be constrained so that not all NF service producers 304 offering the desired service are exposed to NF service consumer 302. For example, based on the identifier of UE 106, the query can be constrained to only those NF service providers 304 that serve UE 106.

[0062] Based on other NFs 110 discovered from NRF 226, NF service consumer 302 selects one or more NF service producers 304 to handle service requests. Assume NF service consumer 302 has multiple control plane (CP) transactions and selects one or more NF service producers 304 to handle the CP transactions. NF service consumer 302 sends NF service requests (3) to NF service producers 304 for one or more CP transactions. Then, the NF service producer 304 provides one or more services based on the NF service requests from the NF service consumer 302.

[0063] Figure 6 The security architecture 600 of a 5G system 100 as described in 3GPP TS 33.501 (v.18.3.0) is shown, which is incorporated herein by reference as if fully contained herein. Figure 6 The following security domains are shown: Network Access Security (I), Network Domain Security (II), User Domain Security (III), Application Domain Security (IV), and SBA Domain Security (V). Network Access Security (I) is a set of security features that enable UE 106 to securely authenticate and access services, including 3GPP and non-3GPP access, particularly preventing attacks on the (radio) interface. Furthermore, Network Access Security includes secure context passing from the Serving Network (SN) to the Access Network (AN) for access security. Network Domain Security (II) is a set of security features that enable network nodes to securely exchange signaling data and user plane data. User Domain Security (III) is a set of security features that protect user access to the Mobile Equipment (ME). Application Domain Security (IV) is a set of security features that enable applications in the user domain and provider domain to securely exchange messages. SBA Domain Security (V) is a set of security features that enable the SBA 200's Network Function (NF) 110 to securely communicate within the Serving Network domain and with other network domains. These security features include security aspects for network function registration, discovery, and authorization, as well as protection for the SBI 250.

[0064] Figure 7The SBI protocol stack 700 for the SBI 250 is shown. For transport layer security protection, the NF 110 supports Transport Layer Security (TLS) 702, and TLS 702 is used for transport protection within the PLMN if network security is not provided by other means. TLS 702 (formerly known as Secure Sockets Layer (SSL)) is an encryption protocol used to authenticate servers in client-server connections and encrypt communication between clients and servers. TLS 702 uses public-key cryptography, which relies on a pair of keys (i.e., a public key and a private key). Data encrypted with the public key can only be decrypted with the private key. Therefore, a server that decrypts data encrypted with the client's public key proves that the server possesses the private key. A digital certificate (also known as a TLS certificate, X.509 certificate, etc.) is a data file containing information used to verify the identity of a server or device, including the public key, a statement about who issued the digital certificate (i.e., which Certificate Authority (CA)), expiration date, etc. TLS 702 uses a handshake process to verify the digital certificate and the server's ownership of the private key. The TLS handshake also establishes how encryption will proceed after the handshake is completed.

[0065] Figure 8 The TLS handshake process between NF 110s is illustrated. Upon receiving initial communication from NF service consumer 302, for example, NF service producer 304 provides its digital certificate 804 to NF service consumer 302. NF service consumer 302 then verifies the digital certificate 804 of NF service producer 304. In mutual or two-way authentication, NF service consumer 302 provides its digital certificate 804 to NF service producer 304. NF service producer 304 then verifies the digital certificate 804 of NF service consumer 302. If both digital certificates 804 are authenticated, NF service producer 304 and NF service consumer 302 can exchange data via an encrypted TLS connection.

[0066] Digital certificates 804 are issued by Certificate Authorities (CAs), for example, through the certificate registration process. Figure 9The certificate registration process 900 is illustrated. Typically, the certificate registration process (or procedure) is used by an entity (such as NF 110) to request and obtain a digital certificate 804 from a Certificate Authority (CA) 906. Digital certificates are used to protect communications and authenticate the identity of a server, client, or user in various security protocols, such as SSL / TLS. In Public Key Infrastructure (PKI), NF 110 obtains a key pair 920 including a private key 921 (also called a secret key) and a public key 922. The primary purpose of certificate registration is to obtain a digital certificate 804, which contains the public key 922 bound to the identity of NF 110 (e.g., an NF instance ID). To initiate the certificate registration process 900, NF 110 generates a Certificate Signing Request (CSR) 904, which includes the public key 922 and information about NF 110. NF 110 sends the CSR 904 to the Certificate Authority 906. The Certificate Authority 906 (also called a Registration Authority (RA)) is the entity that stores, signs, and issues digital certificates 804. Digital certificate 804 proves ownership of the public key by the designated subject of the digital certificate. This allows other parties (dependent parties) to rely on the signature or assertions made about the private key corresponding to the authenticated public key. Therefore, certificate authority 906 acts as a trusted third party, trusted by the owner of digital certificate 804 and the party relying on it. Certificate authority 906 verifies the identity of NF 110 and the information in CSR 904. When certificate authority 906 completes the verification process and is convinced that NF 110 is legitimate, it issues digital certificate 804 to NF 110, which contains the public key 922, identification information, validity period, and the CA's digital signature. Certificate authority 906 delivers the issued digital certificate 804 to NF 110. NF 110 installs digital certificate 804 in the appropriate location. After installation, digital certificate 804 is ready for use with secure communication protocols. Other entities interacting with NF 110 can verify the authenticity of the digital certificate 804 through the digital signature of the certificate authority 906, ensuring a secure and trusted connection.

[0067] The certificate management procedures for NF 110 are defined in 3GPP TS 33.310 (v.18.1.0), which are incorporated herein by reference as if fully contained herein. The certificate management procedures for NF 110 in SBA 200 include: initial trust establishment between NF 110 and the operator's certificate authority, certificate registration and renewal, verification of the use of digital certificate 804 in SBA 200, and certificate revocation procedures. Figure 10A general pattern for initial trust is illustrated. Operations, Administration, and Maintenance (OAM) system 1002 includes processes and / or functions for provisioning and managing NF 110. OAM system 1002 facilitates the establishment of initial trust between NF 110 and the operator's certificate authority 1006. It is assumed that OAM system 1002 is trusted by the operator's certificate authority 1006 (i.e., the trust between OAM system 1002 and operator's certificate authority 1006 is pre-established). OAM system 1002, which instantiates NF 110, provides the NF 110 with initial trust used during the certificate registration process as part of the initial configuration of NF 110. This initial trust can be implemented through a certificate issued by OAM, an Initial Authentication Key (IAK), or a signature of certain NF profile parameters issued by OAM.

[0068] Figure 11 The procedure for establishing initial trust is illustrated. OAM system 1002 is configured with initial trust for registering operator certificates in NF 110 (S1). If the initial trust is established via an initial certificate during or after NF initialization, the local certificate authority in OAM system 1002 should issue the initial certificate to NF 110 as part of its configuration. The certificate is configured with an NF instance ID in the SubjectAltName (SAN) field. NF 110 generates a private-public key pair 920 and requests an EE operator certificate from operator certificate authority 1006 (S2). The certificate signing request (CSR) includes the initial trust obtained in S1 (the certificate issued by the initial OAM, a signature of the NF profile parameters, or an IAK), and the NF instance ID in the SAN field. NF 110 signs the request with its private key 921 and includes a digital signature in the request. NF 110 sends a certificate registration request 1111 to operator certificate authority 1006 (S3). The operator certificate authority 1006 verifies the initial trust and the identifier (NF instance ID) of NF 110 in the request from NF 110 (S4). If the verification passes, the operator certificate authority 1006 generates an EE operator certificate for NF 110. Specifically, it verifies the ownership proof of the private key 921 of the requested operator certificate by checking the digital signature on the certificate registration request 1111 according to the trust anchor configured in S1. The operator certificate authority 1006 also verifies that the NF instance ID in the SAN field of the certificate registration request 1111 corresponds to the NF instance ID of the certificate initially issued by OAM. If these verifications are successful, the operator certificate authority 1006 generates an EE certificate for NF 110. The operator certificate authority 1006 includes the EE certificate for NF 110 in the certificate registration response 1112 (S5).

[0069] After establishing initial trust, certificate registration and renewal procedures can be performed, such as... Figure 9 As shown. The virtualization and increased modularity of NF 110 have led to the increasing prevalence of multi-vendor environments. It is now common for NF 110s to come from different vendors, for their cloud-native environments to run from another vendor, and for all of this to be independent of the Certificate Authority 906 that holds the authority over the digital certificates 804 used to secure communications. In such deployments, manually managing the digital certificates 804 is impractical. 3GPP has indicated that certificate management can be performed using the Certificate Management Protocol (CMPv2) procedure. CMPv2 is a protocol between the Certificate Authority 906 and the end entity, providing various certificate management functions such as certificate registration and certificate renewal. In the embodiments described herein, the Automatic Certificate Management Environment (ACME) protocol can be used as an alternative protocol for certificate management.

[0070] Figure 12 This is a block diagram of NF 110 and Certificate Authority 906 in an illustrative embodiment. NF 110 is a network element or network function (NF) of the 5G core network 104, and can also refer to an SBA component in general. In one embodiment, NF 110 includes the following subsystems: a network interface component 1202 and a security manager 1204 operating on one or more platforms. Network interface component 1202 may include circuitry, logic, hardware, components, etc., and is configured to exchange control plane messages, signaling, or other types of messages with other network elements or NFs and / or other entities via a network connection. Network interface component 1202 can operate using various protocols or reference points. Security manager 1204 may include circuitry, logic, hardware, components, etc., and is configured to support the security management procedures of the NF, such as a certificate manager.

[0071] One or more subsystems of NF 110 can be implemented on a hardware platform consisting of analog and / or digital circuitry. For example, security manager 1204 can be implemented on one or more processors 1210 that execute instructions 1214 (i.e., computer-readable code) of software loaded into memory 1212. Processor 1210 includes integrated hardware circuitry configured to execute instructions 1214 to provide the functionality of NF 110. Processor 1210 may include one or more processors, or may include a multiprocessor core, depending on the specific implementation. Memory 1212 is a non-transitory computer-readable storage medium for data, instructions, applications, etc., and is accessible by processor 1210. Memory 1212 is a hardware storage device capable of temporarily and / or permanently storing information. Memory 1212 may include random access memory or any other volatile or non-volatile storage device. One or more subsystems of NF 110 can be implemented on a cloud computing platform or another type of processing platform. NF 110 may include... Figure 12 Various other components not specifically shown in the text.

[0072] Certificate Authority 906 is the entity that stores, signs, and issues digital certificates 804. In one embodiment, Certificate Authority 906 includes the following subsystems: a network interface component 1222 and a certificate controller 1224 operating on one or more platforms. Network interface component 1222 may include circuitry, logic, hardware, components, etc., and is configured to exchange messages with network elements or NFs and / or other entities via a network connection. Network interface component 1222 can operate using various protocols or reference points. Certificate controller 1224 may include circuitry, logic, hardware, components, etc., and is configured to support certificate management procedures, such as issuing digital certificates 804.

[0073] One or more subsystems of Certificate Authority 906 can be implemented on a hardware platform consisting of analog and / or digital circuitry. For example, the certificate controller 1224 of Certificate Authority 906 can be implemented on one or more processors 1230 that execute instructions 1234 (i.e., computer-readable code) of software loaded into memory 1232. One or more subsystems of Certificate Authority 906 can be implemented on a cloud computing platform or another type of processing platform. Certificate Authority 906 may include... Figure 12 Various other components not specifically shown in the text.

[0074] In one embodiment, the ACME protocol 1250 can be used for certificate registration and / or renewal procedures between the NF 110 and the Certificate Authority 906, procedures commonly referred to as certificate management. Therefore, the security manager 1204 of the NF 110 implements, operates, or runs the ACME client 1206, and the certificate controller 1224 of the Certificate Authority 906 implements, operates, or runs the ACME server 1226. Typically, the ACME client 1206 registers with the Certificate Authority 906 and proves domain ownership through a challenge (e.g., an HTTP-based or DNS-based challenge). The ACME server 1226 running on the Certificate Authority 906 challenges the ACME client 1206 to confirm domain ownership. Following the verification process, the Certificate Authority 906 can issue the digital certificate 804 to the ACME client 1206 (if verification is successful).

[0075] Figure 13 Certificate management is illustrated in an illustrative embodiment. Figures 14A-14D This is a flowchart illustrating a method 1400 for performing certificate management in an illustrative embodiment. Figure 14A The steps of method 1400 will be referred to Figure 12 The NF 110 shown is described, and Figure 14B-14D The steps of method 1400 will be referred to Figure 12 The certificate authority 906 shown is described. Those skilled in the art will understand that method 1400 can be performed in other systems, devices, or network functions. The steps in the flowchart described herein are not exhaustive and may include other steps not shown, and the steps may be performed in an alternative order.

[0076] exist Figure 14A In this process, the ACME client 1206 (also known as the NF instance) of NF 110 sends a certificate request to the Certificate Authority 906 to request a digital certificate 804 (step 1402). Figure 13 As shown, NF 110 sends a certificate request 1304 (e.g., CSR 904) to Certificate Authority 906. Each NF 110 of 5GC 104 is assigned a unique identifier or identity (i.e., NF instance ID 1310), and ACME client 1206 inserts or appends the NF instance ID 1310 to the certificate request 1304. ACME client 1206 may also insert or append other information that can be used to verify NF 110 to the certificate request 1304.

[0077] exist Figure 14BIn this process, the ACME server 1226 of the Certificate Authority 906 receives the certificate request 1304 from NF 110 (step 1422). In response to the certificate request 1304, the ACME server 1226 sends an ACME challenge (or a set of challenges) to NF 110 (step 1424). Figure 13 As shown, ACME server 1226 responds to certificate request 1304 by sending ACME challenge 1306 to NF 110. ACME challenge 1306 is used by NF 110 to prove or verify that NF 110 controls or owns a domain (e.g., a domain name). Figure 15 This is a block diagram illustrating domain 1500 of NF 110 in an illustrative embodiment. Domain 1500 of NF 110 includes a management structure or system for interconnecting network objects, systems, and / or resources for delivering and / or accessing services. Figure 15 As shown, domain 1500 of NF 110 may include one or more servers 1502, such as network server 1504, domain name system (DNS) server 1506 and / or application layer protocol negotiation (ALPN) server 1508, although other resources or resource types may be in domain 1500.

[0078] exist Figure 13 and Figure 14B In this embodiment, ACME server 1226 can issue challenges to NF 110 according to various ACME challenge types. In one embodiment, ACME server 1226 can send HTTP challenge 1307 (e.g., HTTP-01) to NF 110 (optional step 1426). In one embodiment, ACME server 1226 can send DNS challenge 1308 (e.g., DNS-01) to NF 110 (optional step 1428). In one embodiment, ACME server 1226 can send ALPN challenge 1309 (e.g., ALPN-01) to NF 110 (optional step 1430).

[0079] exist Figure 14A In this process, ACME client 1206 receives ACME challenge 1306 from certificate authority 906 (step 1404). ACME client 1206 responds to ACME challenge 1306 to prove control over domain 1500 (step 1406). For example, ACME client 1206 writes, uploads, or publishes certain information to server 1502 under domain 1500 of NF 110. In one embodiment, ACME client 1206 may write an encrypted NF instance ID 1510 to server 1502 (step 1408), such as... Figure 15As shown. For example, ACME client 1206 can be supplied with an NF identifier encryption key, and ACME client 1206 can encrypt the NF instance ID 1310 based on the NF identifier encryption key to generate the encrypted NF instance ID 1510 (step 1410). In one embodiment, ACME client 1206 can write the previous certificate 1512 to the server 1502 (step 1412), such as Figure 15 As shown. For example, NF 110 may have obtained a previous certificate 1512 from another certificate authority. (See attached image.) Figure 15 As shown, a private or domain certificate authority 1520 can issue a prior certificate 1512 (also referred to as a previously issued certificate, initial certificate, etc.) to NF 110. The private or domain certificate authority 1520 may be owned or operated by a network operator or similar party and is separate from certificate authority 906 (e.g., a third-party authority). For example, the prior certificate 1512 may include an initial certificate issued by the operator's certificate authority 1006 during the initial trust establishment period.

[0080] In one embodiment, ACME client 1206 may sign the previous certificate 1512 for further verification. For example, ACME client 1206 may calculate a proof of ownership (POPO) signature based on the private key associated with the previous certificate 1512 and write the POPO signature along with the previous certificate 1512 to server 1502 (step 1414).

[0081] ACME client 1206 can respond to ACME challenge 1306 in various ways based on challenge type. In one embodiment, when using HTTP challenge 1307, ACME client 1206 can write the encrypted NF instance ID 1510 and / or the previous certificate 1512 along with the token to web server 1504 (optional step 1416). Figure 16 An HTTP challenge method is illustrated in an illustrative embodiment. An HTTP challenge 1307 from a certificate authority 906 challenges an ACME client 1206 of NF 110 to create a file or token 1602, and writes the token 1602 to a Uniform Resource Locator (URL) 1604. In one embodiment, the ACME client 1206 writes or appends the encrypted NF instance ID 1510 and / or the previous certificate 1512 to the token 1602 written to the URL 1604 of the web server 1504 (i.e., as part of the token or appended to the token). The ACME client 1206 may also perform additional functions in response to the HTTP challenge 1307.

[0082] In one embodiment, when using DNS challenge 1308, ACME client 1206 can write the encrypted NF instance ID 1510 and / or the previous certificate 1512 into a record of DNS server 1506. Figure 14A (Optional step 1418). Figure 17 A DNS challenge method is illustrated in an illustrative embodiment. A DNS challenge 1308 from a certificate authority 906 challenges NF110 and writes it to a specific record on a DNS server 1506. In one embodiment, in response to the DNS challenge 1308, the ACME client 1206 writes the encrypted NF instance ID 1510 and / or the previous certificate 1512 to record 1706 on the DNS server 1506. The ACME client 1206 may also perform additional functionality in response to the DNS challenge 1308.

[0083] In one embodiment, when using ALPN challenge 1309, ACME client 1206 can write the encrypted NF instance ID 1510 and / or the previous certificate 1512 along with the token to ALPN server 1508. Figure 14A (Optional step 1420). Figure 18 An ALPN challenge method in an illustrative embodiment is shown. An ALPN challenge 1309 from a certificate authority 906 challenges an ACME client 1206 of NF 110 to create a file or token 1802, which is then written to an ALPN server 1508. In one embodiment, the ACME client 1206 writes the encrypted NF instance ID 1510 and / or the previous certificate 1512 to or appends to the token 1802 written to the ALPN server 1508 (i.e., as part of the token or appended to the token). The ACME client 1206 may also perform additional functions in response to the ALPN challenge 1309. In this case, the ACME client 1206 may send a challenge response to the certificate authority 906 according to the challenge method.

[0084] exist Figure 14BIn this process, ACME server 1226 retrieves, acquires, or reads the encrypted NF instance ID 1510 and / or the previous certificate 1512 written to server 1502 by ACME client 1206 in response to ACME challenge 1306. ACME server 1226 can retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 in various ways based on the challenge type. In one embodiment, when using HTTP challenge 1307, ACME server 1226 can retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512, along with token 1602, from URL 1604 of web server 1504 (optional step 1434). In one embodiment, when using DNS challenge 1308, ACME server 1226 can retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 from record 1706 of DNS server 1506 (optional step 1436). In one embodiment, when using ALPN challenge 1309, ACME server 1226 may perform a TLS handshake with ALPN server 1508 to retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 and token 1802 (optional step 1438).

[0085] Then, ACME server 1226 performs a verification or confirmation process (step 1440). For this verification process, in one embodiment, ACME server 1226 may determine whether the NF instance ID 1310 in the certificate request 1304 matches the decrypted encrypted NF instance ID 1510 (step 1442). For example, ACME server 1226 may be supplied with an NF identifier decryption key. Figure 14C As shown, ACME server 1226 can decrypt the encrypted NF instance ID 1510 based on the NF identifier decryption key (step 1462), and compare the decrypted NF instance ID with the NF instance ID 1310 in the certificate request 1304 (step 1464).

[0086] In one embodiment, ACME server 1226 may determine whether the NF instance ID 1310 in the certificate request 1304 matches the NF instance ID 1516 from the previous certificate 1512. Figure 14B Step 1444). For example... Figure 15As shown, when a private or domain certificate authority 1520 issues a previous certificate 1512, the previous certificate 1512 includes an NF instance ID 1516. In one embodiment, the ACME server 1226 can verify the NF instance ID 1516 of the previous certificate 1512. For example, the ACME client 1206 can calculate a (first) POPO signature for the previous certificate 1512 and write the POPO signature along with the previous certificate 1512 to the server 1502. Figure 14D As shown, ACME server 1226 can retrieve the (first) POPO signature calculated by ACME client 1206 along with the previous certificate 1512 from server 1502 (step 1472), and calculate a (second) POPO signature for the previous certificate 1512 based on the public key associated with the previous certificate 1512 (step 1474). ACME server 1226 can then compare the (first) POPO signature and the (second) POPO signature to verify the trust of the previous certificate 1512 (step 1476). If the POPO signatures match, ACME server 1226 considers the NF instance ID 1516 of the previous certificate 1512 to be "verified" or "trusted". ACME server 1226 can then compare the NF instance ID 1516 of the previous certificate 1512 with the NF instance ID 1310 in the certificate request 1304 (step 1478). If the previous certificate 1512 has been deemed "verified" or "trusted", the ACME server 1226 can compare the NF instance ID 1516 of the previous certificate 1512 with the NF instance ID 1310 in the certificate request 1304 (step 1478) without verifying the POPO signature.

[0087] For the verification process, ACME server 1226 may compare other parameters of the certificate request 1304 with the parameters of the NF profile 520 of the requesting NF 110 and / or the previous certificate 1512 (step 1446). When verification passes, ACME server 1226 issues the digital certificate 804 to NF 110 (step 1448). When verification fails, ACME server 1226 refuses to issue the digital certificate 804 to NF 110 (step 1450).

[0088] One technical advantage is that the ACME protocol 1250 can be used to provide automated certificate management. Another technical advantage is that the Certificate Authority 906 can verify or confirm the identity of the requesting NF 110. As noted by 3GPP, the Certificate Authority 906 should be able to verify that the NF instance ID 1310 in the certificate request belongs to the NF instance requesting the digital certificate 804. A malicious or compromised NF instance might use a compromised NF instance ID to send a malicious certificate request. Through the aforementioned security mechanism, the Certificate Authority 906 can verify that the NF instance ID 1310 in the certificate request 1304 belongs to the NF instance requesting the digital certificate 804. This improves the security of the 5G system 100.

[0089] Figure 19 This is a message diagram illustrating the certificate management procedure in an illustrative embodiment. OAM 1002 configures NF 110 with NF identifier encryption key 1901, NF instance ID 1310, slice information, and / or other NF profile details or parameters (S1). OAM 1002 also configures the NF profile parameters to be verified in Certificate Authority 906, such as NF instance ID, fully qualified domain name (FQDN), Internet Protocol (IP) address, NF slice list, NF identifier decryption key 1902, network server 1504 or DNS server 1506 information, etc. (S2). NF 110 requests digital certificate 804 (containing the public key 922, the NF instance ID 1310 (in the SAN field), etc.) by sending CSR 904 to Certificate Authority 906 (i.e., ACME server 1226) (S3). In response to CSR 904, Certificate Authority 906 sends ACME Challenge 1306 to NF 110 to write a unique token to a text record of network server 1504 or a specific value to DNS server 1506 (S4). NF 110 encrypts the NF instance ID 1310 using the NF identifier encryption key 1901 to generate an encrypted NF instance ID 1510, and writes a token with the encrypted NF instance ID 1510 to a text record of network server 1504 or DNS server 1506 (S5). Then, NF 110 sends a challenge completion message to Certificate Authority 906 (S6).

[0090] Certificate Authority 906 performs the verification process. Certificate Authority 906 obtains the token / record and verifies NF 110's control over Domain 1500 (S7a). Certificate Authority 906 retrieves the NF Instance ID 1310 from the SAN field of CSR 904 and obtains the NF identifier decryption key 1902 stored for NF Instance ID 1310 in NF Profile 520 (S7b). Certificate Authority 906 uses the NF identifier decryption key 1902 to decrypt the encrypted NF Instance ID 1510 and compares the decrypted NF Instance ID with the NF Instance ID 1310 present in CSR 904 (S7c). When a match is found (and other parameters of NF Profile 520 match CSR 904), Certificate Authority 906 issues the digital certificate 804 (S7d). Certificate Authority 906 sends the digital certificate 804 to NF 110 (S8).

[0091] Figure 20 is a message diagram illustrating the certificate management process in an illustrative embodiment. OAM 1002 configures the NF identifier encryption key 1901, NF instance ID 1310, slice information, and / or other NF profile details or parameters for NF 110 (S1). OAM 1002 also configures the NF profile parameters to be verified at Certificate Authority 906, such as NF instance ID, FQDN, IP address, NF slice list, NF identifier decryption key 1902, ALPN server information, etc. (S2). NF 110 requests a digital certificate 804 (containing public key 922, NF instance ID 1310 (in the SAN field), etc.) by sending CSR 904 to Certificate Authority 906 (i.e., ACME server 1226) (S3). In response to CSR 904, Certificate Authority 906 sends ACME challenge 1306 to NF 110 to write a unique token on ALPN server 1508 (S4). NF 110 encrypts NF instance ID 1310 using NF identifier encryption key 1901 to generate encrypted NF instance ID 1510, and writes a token with encrypted NF instance ID 1510 to ALPN server 1508 (S5). Certificate Authority 906 performs a TLS handshake with ALPN server 1508 (S6a). ALPN server 1508 responds to the TLS handshake by presenting the requested token with encrypted NF instance ID 1510 appended to the ALPN extended data (S6b).

[0092] Certificate Authority 906 performs the verification process. Certificate Authority 906 obtains the token and verifies NF 110's control over domain 1500 (S7a). Certificate Authority 906 retrieves the NF instance ID 1310 from the SAN field of CSR 904 and obtains the NF identifier decryption key 1902 stored for the NF instance ID in NF profile 520 (S7b). Certificate Authority 906 decrypts the encrypted NF instance ID 1510 using the NF identifier decryption key 1902 and compares the decrypted NF instance ID with the NF instance ID 1310 present in CSR 904 (S7c). When a match is found (and other parameters of NF profile 520 match CSR 904), Certificate Authority 906 issues digital certificate 804 (S7d). Certificate Authority 906 sends digital certificate 804 to NF 110 (S8).

[0093] Figure 21 is a message diagram illustrating the certificate management process in an illustrative embodiment. OAM 1002 configures a previous certificate 1512 (with a verified NF instance ID 1516, FQDN, etc.) for NF 110, which is signed by a domain certificate authority, a private certificate authority, etc. (S1a). NF 110 calculates a proof of possession (POPO) signature 2101 for the previous certificate 1512 based on the private key associated with the previous certificate 1512 (S1b). OAM 1002 configures a trust anchor for the domain / private certificate authority 1520 at certificate authority 906 (S2). NF 110 requests a digital certificate 804 (with a public key 922, NF instance ID 1310 (in the SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME server 1226) (S3). In response to CSR 904, Certificate Authority 906 sends ACME Challenge 1306 to NF 110 to write a unique token on Network Server 1504 or a specific value in a text record of DNS Server 1506 (S4). NF 110 writes the token with the previous certificate 1512 and POPO signature 2101 to Network Server 1504, or writes the previous certificate 1512 and POPO signature 2101 to a text record of DNS Server 1506 (S5). NF 110 then sends a challenge completion message to Certificate Authority 906 (S6).

[0094] Certificate Authority 906 performs the verification process. Certificate Authority 906 obtains the token / DNS record and verifies the NF's control over the domain (S7a). Certificate Authority 906 retrieves the previous certificate 1512 and verifies the POPO signature 2101 using the public key of the previous certificate 1512 (S7b). When the POPO signature verification is successful, Certificate Authority 906 verifies the trust of the previous certificate 1512 (S7c). When the trust of the previous certificate 1512 is verified, Certificate Authority 906 compares the verified NF instance ID 1516 in the previous certificate 1512 with the NF instance ID 1310 existing in CSR 904 (S7d). Certificate Authority 906 also compares other parameters of CSR 904 with the parameters of the previous certificate 1512 (S7d). When a match is found, Certificate Authority 906 issues digital certificate 804 (S7e). Certificate Authority 906 sends digital certificate 804 to NF 110 (S8).

[0095] Figure 22 is a message diagram illustrating the certificate management process in an illustrative embodiment. OAM 1002 configures a previous certificate 1512 (with NF instance ID 1310, FQDN, etc.) for NF 110, which is signed by a domain certificate authority, a private certificate authority, etc. (S1a). NF 110 calculates a POPO signature 2101 for the previous certificate 1512 based on the private key associated with the previous certificate 1512 (S1b). OAM 1002 configures a trust anchor for the domain / private certificate authority 1520 at certificate authority 906 (S2). NF 110 requests a digital certificate 804 (with public key 922, NF instance ID 1310 (in the SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME server 1226) (S3). In response to CSR 904, Certificate Authority 906 issues ACME Challenge 1306 to NF 110 to write a unique token on ALPN server 1508 (S4). NF 110 writes the token with the previous certificate 1512 and POPO signature 2101 to ALPN server 1508 (S5). Certificate Authority 906 performs a TLS handshake with ALPN server 1508 (S6a). ALPN server 1508 responds to the TLS handshake by presenting the requested token with the previous certificate 1512 and POPO signature 2101 appended to the ALPN extended data (S6b).

[0096] Certificate Authority 906 performs the verification process. Certificate Authority 906 obtains the token and verifies the NF's control over the domain (S7a). Certificate Authority 906 retrieves the previous certificate 1512 and verifies the POPO signature 2101 using the public key of the previous certificate 1512 (S7b). When the POPO signature verification is successful, Certificate Authority 906 verifies the trust of the previous certificate 1512 (S7c). When the trust of the previous certificate 1512 is verified, Certificate Authority 906 compares the verified NF instance ID 1516 in the previous certificate 1512 with the NF instance ID 1310 existing in CSR 904 (S7d). Certificate Authority 906 also compares other parameters of CSR 904 with the parameters of the previous certificate 1512 (S7d). When a match is found, Certificate Authority 906 issues digital certificate 804 (S7e). Certificate Authority 906 sends digital certificate 804 to NF 110 (S8). Any of the various elements or modules shown in the figures or described herein can be implemented as hardware, software, firmware, or some combination thereof. For example, an element can be implemented as dedicated hardware. A dedicated hardware element can be referred to as a "processor," a "controller," or some similar term. When provided by a processor, functionality can be provided by a single dedicated processor, by a single shared processor, or by multiple separate processors, some of which may be shared. Furthermore, the explicit use of the terms "processor" or "controller" should not be construed as referring exclusively to hardware capable of executing software, and may implicitly include, but is not limited to, digital signal processor (DSP) hardware, network processors, application-specific integrated circuits (ASICs) or other circuitry, field-programmable gate arrays (FPGAs), read-only memory (ROM) for storing software, random access memory (RAM), non-volatile memory, logic, or certain other physical hardware components or modules.

[0097] Furthermore, a component can be implemented as instructions that are executed by a processor or computer to perform the component's functions. Some examples of instructions are software, program code, and firmware. When executed by a processor, the instructions are operable to instruct the processor to perform the component's functions. The instructions can be stored on a processor-readable storage device. Some examples of storage devices are digital or solid-state memory, magnetic storage media (such as disks and tapes), hard disk drives, or optically readable digital data storage media.

[0098] As used in this application, the term "circuit" may refer to one or more, or all of the following: (a) Hardware circuit implementation only (e.g., implementation only in analog and / or digital circuits); (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of analog and / or digital hardware circuitry with software / firmware; and (ii) Any part of the hardware processor works in conjunction with software (including digital signal processors), software, and memory to enable a device (e.g., a mobile phone or server) to perform various functions; and (c) Hardware circuitry and / or processors, such as microprocessors or a portion thereof, which require software (e.g. firmware) to operate, but may be absent when operation is not required.

[0099] This definition of "circuit" applies to all uses of the term in this application, including in any claim. As a further example, as used in this application, the term "circuit" also covers only hardware circuitry or a processor (or multiple processors) or a portion of hardware circuitry or a processor and its accompanying software and / or firmware implementation. The term "circuit" also covers, for example and if applicable to a particular claim element, baseband integrated circuits or processor integrated circuits for mobile devices or similar integrated circuits in servers, cellular network devices or other computing or network devices.

[0100] Although specific embodiments have been described herein, the scope of this disclosure is not limited to those specific embodiments. The scope of this disclosure is defined by the following claims and any equivalents thereof.

Claims

1. An apparatus comprising: At least one processor and at least one memory storing instructions, which, when executed by the at least one processor, implement network functions of a 5G network, the network functions being configured to operate an Automatic Certificate Management Environment (ACME) client to obtain digital certificates from a certificate authority via the ACME protocol for secure communication by the network functions; The ACME client is configured as follows: Send a certificate request to the certificate authority, the certificate request indicating a network function instance identifier; Receive the ACME challenge from the certificate authority; as well as In response to the ACME challenge, the network function instance identifier is written in encrypted form or a previously issued certificate is written to the server under the security domain of the network function.

2. The apparatus according to claim 1, wherein: The ACME challenges include the Hypertext Transfer Protocol Challenge; and The ACME client is also configured to write the network function instance identifier in encrypted form or to write the previously issued certificate along with a token to the network server.

3. The apparatus according to claim 1, wherein: The ACME challenges include the Domain Name System challenge; and The ACME client is also configured to write the network function instance identifier in encrypted form or the previously issued certificate into a record on the domain name system server.

4. The apparatus according to claim 1, wherein: The ACME challenges include application layer protocol negotiation challenges; and The ACME client is also configured to write the network function instance identifier in encrypted form or to write the previously issued certificate along with the token to the application layer protocol negotiation server.

5. The apparatus according to claim 1, wherein: The ACME client is supplied with a network function identification encryption key; and The ACME client is also configured to encrypt the network function instance identifier based on the network function identifier encryption key.

6. The apparatus of claim 1, wherein the ACME client is further configured to: Calculate a proof-of-ownership signature based on the private key associated with the previously issued certificate; and Write the possession certificate signature along with the previously issued certificate to the server.

7. A method for performing certificate management in network functions of a 5G network, the method comprising: The Automatic Certificate Management Environment (ACME) client operates at the network function to obtain digital certificates from the Certificate Authority via the ACME protocol for secure communication by the network function. The operation includes: Send a certificate request to the certificate authority, the certificate request indicating a network function instance identifier; Receive the ACME challenge from the certificate authority; and In response to the ACME challenge, the network function instance identifier is written in encrypted form or a previously issued certificate is written to the server under the security domain of the network function.

8. The method according to claim 7, wherein: The ACME challenges include the Hypertext Transfer Protocol Challenge; and The writing includes writing the network function instance identifier in encrypted form or writing the previously issued certificate together with the token to the network server.

9. The method according to claim 7, wherein: The ACME challenges include the Domain Name System challenge; and The writing includes writing the network function instance identifier in encrypted form or the previously issued certificate into a record on the domain name system server.

10. The method of claim 7, wherein: The ACME challenges include application layer protocol negotiation challenges; and The writing includes writing the network function instance identifier in encrypted form or writing the previously issued certificate together with the token to the application layer protocol negotiation server.

11. The method of claim 7, wherein: The ACME client is supplied with a network function identification encryption key; and The method further includes encrypting the network function instance identifier based on the network function identifier encryption key.

12. The method of claim 7, further comprising: Calculate the proof of possession signature based on the private key associated with the previously issued certificate; as well as Write the possession certificate signature along with the previously issued certificate to the server.

13. An apparatus comprising: At least one processor, and at least one memory storing instructions that, when executed by the at least one processor, implement a certificate authority configured to operate an Automatic Certificate Management Environment (ACME) server; The ACME server is configured as follows: A certificate request for a digital certificate is received from a network function of a 5G network, wherein the certificate request indicates a network function instance identifier; Send an ACME challenge to the network function to challenge the network function to prove its control over the domain; Retrieve the encrypted network function instance identifier or previously issued certificate from the server under the domain of the network function; The verification process is performed to determine whether the network function instance identifier in the certificate request matches the encrypted network function instance identifier when decrypted, or matches the verified network function instance identifier from the previously issued certificate. as well as When the verification process is successful, the digital certificate is issued to the network function.

14. The apparatus according to claim 13, wherein: The ACME challenges include the Hypertext Transfer Protocol Challenge; and The ACME server is also configured to retrieve the encrypted network function instance identifier or the previously issued certificate and token from the network server's Uniform Resource Locator.

15. The apparatus according to claim 13, wherein: The ACME challenges include the Domain Name System challenge; and The ACME server is also configured to retrieve the encrypted network function instance identifier or the previously issued certificate from records on the Domain Name System server.

16. The apparatus of claim 13, wherein: The ACME challenges include application layer protocol negotiation challenges; and The ACME server is also configured to perform a transport layer security handshake with the application layer protocol negotiation server to retrieve the encrypted network function instance identifier or the previously issued certificate and token.

17. The apparatus according to claim 13, wherein: The ACME server is supplied with a network function identifier decryption key; and The ACME server is also configured to: Decrypt the encrypted network function instance identifier based on the network function identifier decryption key; and The decrypted network function instance identifier is compared with the network function instance identifier in the certificate request.

18. The apparatus of claim 13, wherein the ACME server is further configured to: Retrieve the first proof-of-hold signature calculated by the network function based on the private key associated with the previously issued certificate; Calculate a second holding proof signature based on the public key associated with the previously issued certificate; The first proof of possession signature is compared with the second proof of possession signature to verify the trust in the previously issued certificate; as well as The network function instance identifier of the previously issued certificate is compared with the network function instance identifier in the certificate request.

19. A method for performing certificate management, the method comprising: Operate the Automated Certificate Management Environment (ACME) server at the Certificate Authority; The operation includes: A certificate request for a digital certificate is received from a network function of a 5G network, wherein the certificate request indicates a network function instance identifier; Send an ACME challenge to the network function, challenging the network function to prove its control over the domain; Retrieve the encrypted network function instance identifier or previously issued certificate from the server under the domain of the network function; The verification process is performed to determine whether the network function instance identifier in the certificate request matches the encrypted network function instance identifier upon decryption, or matches a verified network function instance identifier from the previously issued certificate; and When the verification process is successful, the digital certificate is issued to the network function.

20. The method of claim 19, wherein: The ACME challenges include the Hypertext Transfer Protocol Challenge; and The retrieval includes retrieving the encrypted network function instance identifier or the previously issued certificate and token from the Uniform Resource Locator of the network server.

21. The method of claim 19, wherein: The ACME challenges include the Domain Name System challenge; and The retrieval includes retrieving the encrypted network function instance identifier or the previously issued certificate from the records of the Domain Name System server.

22. The method of claim 19, wherein: The ACME challenges include application layer protocol negotiation challenges; and The retrieval includes performing a transport layer security handshake with the application layer protocol negotiation server to retrieve the encrypted network function instance identifier or the previously issued certificate and token.

23. The method of claim 19, wherein: The ACME server is supplied with a network function identifier decryption key; as well as The method further includes: Decrypt the encrypted network function instance identifier based on the network function identifier decryption key; as well as The decrypted network function instance identifier is compared with the network function instance identifier in the certificate request.

24. The method of claim 19, further comprising: Retrieve the first proof-of-hold signature calculated by the network function based on the private key associated with the previously issued certificate; Calculate a second holding proof signature based on the public key associated with the previously issued certificate; The first proof of possession signature is compared with the second proof of possession signature to verify the trust in the previously issued certificate; as well as The network function instance identifier of the previously issued certificate is compared with the network function instance identifier in the certificate request.

Images