Validation of NF instance identifiers in issuance of digital certificates using acme protocol

Abstract

Certificate management using Automated Certificate Management Environment (ACME) protocol in a 5G network. In an embodiment, a network function (NF) of the 5G network operates an ACME client to obtain a digital certificate from a certificate authority via 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 write the NF instance identifier as encrypted or a previously-issued certificate to a server under a security domain of the NF in response to the ACME challenge.

Description

[0001] VALIDATION OF NF INSTANCE IDENTIFIERS IN ISSUANCE OF DIGITAL CERTIFICATES USING ACME PROTOCOL

[0002] Technical Field

[0003] This disclosure is related to the field of communication systems and, in particular, to next generation networks.

[0004] Background

[0005] Next generation networks, such as Fifth Generation (5G), denote the next major phase of mobile telecommunications standards beyond Fourth Generation (4G) standards. In comparison to 4G networks, next generation networks may be enhanced in terms of radio access and network architecture. Next generation networks intend to utilize new regions of the radio spectrum for Radio Access Networks (RANs), such as millimeter wave bands.

[0006] With mobile networks widely used across the country and the world, communications may be intercepted or suffer from other kinds of attacks. To ensure security and privacy, the 3rd Generation Partnership Project (3GPP) has set forth security mechanisms for 5G mobile networks, and the security procedures performed within the 5G mobile networks. Due to the importance of security in 5G systems and beyond, it is desirable to continue to develop more robust security mechanisms.

[0007] The Service-Based Architecture (SBA) of 5G core network is composed of multiple services provided by Network Functions (NFs). Digital certificates may be used by NFs and other SBA components to encrypt internal and external communications to prevent attackers from intercepting and stealing sensitive data. A digital certificate is a data file that contains information for verifying a server’s or device’s identity, a public key, a statement of what certificate authority (CA) issued the digital certificate, an expiration date, etc. Although digital certificates provide protection between valid NFs, one potential issue is that a malicious NF may request a digital certificate from a certificate authority.

[0008] Summary

[0009] Described herein are certificate management procedures in a 5G network. As an overview, Automated Certificate Management Environment (ACME) protocol may be used as a protocol for certificate management procedures. An ACME client of an NF sends a certificate request to a certificate authority, and receives an ACME challenge. In response to the ACME challenge, the ACME client provides a “validated” or “trusted” NF Instance Identifier (ID) of the NF to a server, which is retrievable by the certificate authority. For example, the ACME client may encrypt the NF Instance ID with a private key. In another example, the ACME client may provide a previous digital certificate comprising the NF Instance ID that can be validated. An ACME server of the certificate authority may then verify the identity of a requesting NF by comparing the “validated” or “trusted” NF Instance ID with the NF Instance ID provided in the certificate request. One technical benefit is the certificate authority is able to verify or validate the identity of a requesting NF before issuing a digital certificate to the requesting NF. This ensures that a certificate authority does not issue a digital certificate to an NF instance ID that is compromised.

[0010] In an embodiment (also referred to as an aspect), an apparatus comprises 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 configured to operate an ACME client to obtain a digital certificate from a certificate authority via 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 write the NF instance identifier as encrypted or a previously-issued certificate to a server under a security domain of the NF in response to the ACME challenge.

[0011] In an embodiment, the ACME challenge comprises a hypertext transfer protocol challenge, and the ACME client is further configured to write the NF instance identifier as encrypted or the previously-issued certificate with a token to a web server.

[0012] In an embodiment, the ACME challenge comprises a domain name system challenge, and the ACME client is further configured to write the NF instance identifier as encrypted or the previously-issued certificate to a record of a domain name system server.

[0013] In an embodiment, the ACME challenge comprises an application-layer protocol negotiation challenge, and the ACME client is further configured to write the NF instance identifier as encrypted or the previously-issued certificate with a token to an application-layer protocol negotiation server.

[0014] In an embodiment, the ACME client is provisioned with a NF identity encryption key, and the ACME client is further configured to encrypt the NF instance identifier based on the NF identity encryption key. In an embodiment, the ACME client is further configured to calculate a proof of possession signature based on a private key associated with the previously-issued certificate, and write the proof of possession signature along with the previously-issued certificate to the server.

[0015] In an embodiment, a method of performing certificate management in an NF of a 5G network comprises operating an ACME client at the NF to obtain a digital certificate from a certificate authority via ACME protocol for secure communication by the NF. The operating comprises sending a certificate request to the certificate authority indicating an NF instance identifier, receiving an ACME challenge from the certificate authority, and writing the NF instance identifier as encrypted or a previously-issued certificate to a server under a security domain of the NF in response to the ACME challenge.

[0016] In an embodiment, the ACME challenge comprises a hypertext transfer protocol challenge, and the writing comprises writing the NF instance identifier as encrypted or the previously-issued certificate with a token to a web server.

[0017] In an embodiment, the ACME challenge comprises a domain name system challenge, and the writing comprises writing the NF instance identifier as encrypted or the previously- issued certificate to a record of a domain name system server.

[0018] In an embodiment, the ACME challenge comprises an application-layer protocol negotiation challenge, and the writing comprises writing the NF instance identifier as encrypted or the previously-issued certificate with a token to an application-layer protocol negotiation server.

[0019] In an embodiment, the ACME client is provisioned with a NF identity encryption key, and the method further comprises encrypting the NF instance identifier based on the NF identity encryption key.

[0020] In an embodiment, the method further comprises calculating a proof of possession signature based on a private key associated with the previously-issued certificate, and writing the proof of possession signature along with the previously-issued certificate to the server.

[0021] In an embodiment, an apparatus comprises 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 ACME server. The ACME server is configured to receive a certificate request from an NF of a 5G network requesting a digital certificate, where the certificate request indicates an NF instance identifier. The ACME server is further configured to send an ACME challenge to the NF challenging the NF to prove control over a domain, retrieve an encrypted NF instance identifier or a previously-issued certificate from a server under the domain of the NF, perform a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier when decrypted, or a validated NF instance identifier from the previously-issued certificate, and issue the digital certificate to the NF when the verification process passes.

[0022] In an embodiment, the ACME challenge comprises a hypertext transfer protocol challenge, and the ACME server is further configured to retrieve the encrypted NF instance identifier or the previously-issued certificate with a token from a uniform resource locator of a web server.

[0023] In an embodiment, the ACME challenge comprises a domain name system challenge, and the ACME server is further configured to retrieve the encrypted NF instance identifier or the previously-issued certificate from a record of a domain name system server.

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

[0025] In an embodiment, the ACME server is provisioned with an NF identity decryption key, and the ACME server is further configured to decrypt the encrypted NF instance identifier based on the NF identity decryption key, and compare the decrypted NF instance identifier with the NF instance identifier in the certificate request.

[0026] In an embodiment, the ACME server is further configured to retrieve a first proof of possession signature calculated by the NF based on a private key associated with the previously-issued certificate, calculate a second proof of possession signature based on a public key associated with the previously-issued certificate, compare the first proof of possession signature with the second proof of possession signature to validate 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.

[0027] In an embodiment, a method of performing certificate management comprises operating an ACME server at a certificate authority. The operating comprises receiving a certificate request from a NF of a 5G network requesting a digital certificate, wherein the certificate request indicates an NF instance identifier. The method further comprises 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 domain of the NF, performing a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier when decrypted, or a validated NF instance identifier from the previously-issued certificate, and issuing the digital certificate to the NF when the verification process passes.

[0028] In an embodiment, the ACME challenge comprises a hypertext transfer protocol challenge, and the retrieving comprises retrieving the encrypted NF instance identifier or the previously-issued certificate with a token from a uniform resource locator of a web server.

[0029] In an embodiment, the ACME challenge comprises a domain name system challenge, and the retrieving comprises retrieving the encrypted NF instance identifier or the previously- issued certificate from a record of a domain name system server.

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

[0031] In an embodiment, the ACME server is provisioned with an NF identity decryption key, and the method further comprises decrypting the encrypted NF instance identifier based on the NF identity decryption key, and comparing the decrypted NF instance identifier with the NF instance identifier in the certificate request.

[0032] In an embodiment, the method further comprises retrieving a first proof of possession signature calculated by the NF based on a private key associated with the previously-issued certificate, calculating a second proof of possession signature based on a public key associated with the previously-issued certificate, comparing the first proof of possession signature with the second proof of possession signature to validate trust of the previously-issued certificate, and comparing the NF instance identifier of the previously-issued certificate with the NF instance identifier in the certificate request.

[0033] In an embodiment, an apparatus comprises a network function (NF) of a 5G network comprising a means for obtaining a digital certificate from a certificate authority via ACME protocol for secure communication by the NF. The NF comprises a means for sending a certificate request to the certificate authority indicating an NF instance identifier, a means for receiving an ACME challenge from the certificate authority, and a means for writing the NF instance identifier as encrypted or a previously-issued certificate to a server under a security domain of the NF in response to the ACME challenge. In an embodiment, an apparatus comprises a certificate authority comprising a means for receiving a certificate request from an NF of a 5G network requesting a digital certificate, where the certificate request indicates an NF instance identifier. The certificate authority comprises a means for sending an ACME challenge to the NF challenging the NF to prove control over a domain, a means for retrieving an encrypted NF instance identifier or a previously-issued certificate from a server under the domain of the NF, a means for performing a verification process to determine whether the NF instance identifier in the certificate request matches the encrypted NF instance identifier when decrypted, or a validated NF instance identifier from the previously-issued certificate, and a means for issuing the digital certificate to the NF when the verification process passes.

[0034] Other embodiments may include computer readable media, other systems or apparatus, or other methods as described below. Also, one or more embodiments as described above may be combinable as described herein.

[0035] The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.

[0036] Description of the Drawings

[0037] Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.

[0038] FIG. 1 illustrates a high-level architecture of a 5G system.

[0039] FIG. 2 illustrates a non-roaming architecture of a 5G system.

[0040] FIG. 3 illustrates an NF service consumer and NF service producer interaction.

[0041] FIG. 4 illustrates a “Request-response” NF Service mechanism.

[0042] FIG. 5 illustrates an NRF that maintains NF profiles.

[0043] FIG. 6 illustrates a security architecture of a 5G system.

[0044] FIG. 7 illustrates the SBI protocol stack.

[0045] FIG. 8 illustrates a TLS handshake process between NFs.

[0046] FIG. 9 illustrates a certificate enrollment process. FIG. 10 illustrates an initial trust general schema.

[0047] FIG. 11 illustrates a procedure for set up of initial trust.

[0048] FIG. 12 is a block diagram of an NF and a certificate authority in an illustrative embodiment.

[0049] FIG. 13 illustrates certificate management in an illustrative embodiment.

[0050] FIGS. 14A-14D are flow charts illustrating a method of performing certificate management in an illustrative embodiment.

[0051] FIG. 15 is a block diagram illustrating a domain of an NF in an illustrative embodiment.

[0052] FIG. 16 illustrates an HTTP challenge method in an illustrative embodiment.

[0053] FIG. 17 illustrates a DNS challenge method in an illustrative embodiment.

[0054] FIG. 18 illustrates an ALPN challenge method in an illustrative embodiment.

[0055] FIGS. 19-22 are message diagrams illustrating certificate management procedures in an illustrative embodiment.

[0056] Description of Embodiments

[0057] The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, 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 are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

[0058] FIG. 1 illustrates a high-level architecture of a 5G system 100. A 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) comprising a 5G Access Network ((R)AN) 102 (referred to herein generally as a RAN) and a 5G core network (5GC) 104 that communicate with 5G User Equipment (UE) 106. The 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 networks beyond 5G are also considered.

[0059] RAN 102 provides radio or wireless connectivity to a UE 106, and connects the UE 106 to the 5GC 104. RAN 102 may comprise a Next Generation Radio Access Network (NG- RAN), a non-3GPP access network, and / or another type of RAN connecting to 5GC 104. RAN 102 may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through an eNodeB (eNB), gNodeB (gNB), and / or ng-eNodeB (ng-eNB)), Wireless Local Area Network (WLAN) access, satellite radio access, new Radio Access Technologies (RAT), etc. A 5G access network may also support fixed access. 5GC 104 interconnects RAN 102 with a data network (DN) 108. 5GC 104 is comprised of Network Functions (NF) 110, which may be implemented either 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., a cloud infrastructure), etc. Data network 108 may be an operator external public or private data network, or an intra-operator data network (e.g., for IP Multimedia Subsystem (IMS) services). A UE 106 (also referred to as a mobile terminal) includes a 5G capable device configured to register with 5GC 104 to access services. UE 106 may include an end user device, such as a mobile phone (e.g., smartphone), a tablet, a computer with a mobile broadband adapter, etc. UE 106 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and / or other services.

[0060] FIG. 2 illustrates a service-based architecture 200 (SB A) of a 5G system 100, as is further described in 3GPP TS 23.501 (vl 8.2.0), which is incorporated by reference as if fully included herein. The SBA 200 in FIG. 2 illustrates a non-roaming scenario. SBA 200 is comprised of Network Functions (NF) 110 for a 5GC 104, and the NFs 110 for the control plane (CP) are separated from the user plane (UP). For example, the control plane of the 5GC 104 includes an Authentication Server Function (AUSF) 210, an Access and Mobility Management Function (AMF) 212, a Session Management Function (SMF) 214, a Policy Control Function (PCF) 216, a Unified Data Management (UDM) 218, a Network Slice Selection Function (NSSF) 220, and an Application Function (AF) 222. The control plane of the 5GC 104 further includes a Network Exposure Function (NEF) 224, a NF Repository Function (NRF) 226, a Service Communication Proxy (SCP) 228, a Network Slice Admission Control Function (NSACF) 230, a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) 232, and an Edge Application Server Discovery Function (EASDF) 234. The user plane of the 5GC 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108. A UE 106 is able to access the control plane and the user plane of the 5GC 104 through RAN 102. In SB A 200, system functionality is achieved by a set of NFs 110 providing services to other authorized NFs 110 to access their services. An NF service is one type of capability exposed by an NF 110 (NF Service Producer) to other authorized NFs (NF Service Consumer) through a service-based interface. For example, a list of NF services is provided in Clause 7 of 3GPP TS 23.501. A service-based interface (SBI) 250 represents how the set of services is provided or exposed by a given NF 110. The roles of NFs 110 within the 5GC 104 may be defined as a service consumer and a service producer, as illustrated in FIG. 3. An NF service producer 304 is an NF 110 that exposes an NF service 310, and an NF service consumer 302 is an NF 110 that requests an NF service 310. An NF service 310 may communicate directly between an NF service consumer 302 and an NF service producer 304 through a servicebased interface (SBI) 250. An NF service 310 may also communicate between an NF service consumer 302 and NF service producers 304 indirectly via an SCP 228 (not shown in FIG. 3). The end-to-end interaction between two NFs 110 (Consumer and Producer) within the NF service framework follows two mechanisms: “Request-response”, and “Subscribe- Notify”. FIG. 4 illustrates a “Request-response” NF Service mechanism. An NF service consumer 302 sends a request 410 for a certain NF service to NF service producer 304. NF service producer 304 provides an NF service 310 based on the request 410 from NF service consumer 302. In order to fulfill the request 410, NF service producer 304 may in turn consume NF services from other NFs 110. In the Request-response mechanism, a one-time response 412 from NF service producer 304 to NF service consumer 302 is expected within a certain timeframe.

[0061] FIG. 5 illustrates an NRF 226 that maintains NF profiles 520. As described in 3GPP TS 29.510 (v.18.4.0), which is incorporated by reference as if fully included herein, NRF 226 is the network entity in the 5GC 104 that maintains the NF profile 520 of available NF instances and their supported services. An NF instance is defined as an identifiable instance of the NF 110. In an SBA 200, NFs 110 may be comprised of individual micro-services coming together to automatically discover each other, and utilize the services offered by each other. Thus, NFs 110 may be composed of a multitude of services, each of which might have many instances. As described by the 3GPP, an SBA may be implemented as a service mesh architecture. A service mesh describes a network of microservices, in which applications are shared and interaction between applications is possible. NRF 226 acts as a central registry for storing or maintaining information about NFs 110 and the services supported by the NFs 110. The data structure of an NF profile 520 is indicated in section 6.1.6.2.2 of 3GPP TS 29.510, and includes an NF instance identifier (ID) (i.e., “nflnstanceld”), an NF type (i.e., “nfType”) indicating the type of NF 110 (e.g., AMF, AUSF, UDM, etc.), a list of NF service instances (i.e., “nfServices”) supported by the NF, etc. The NF instance ID is a unique identity (i.e., string) of an NF instance, and the format of the NF Instance ID may be a Universally Unique Identifier (UUID).

[0062] For example, NRF 226 offers services to NF service consumers 302 and NF service producers 304, such as Nnrf_NFManagement and Nnrf_NFDiscovery. The Nnrf_NFManagement service allows an NF 110 to register, update, or deregister its NF profile 520 in NRF 226. One of the Nnrf_NFManagement services is a register operation (i.e., NFRegister), where an NF service producer 304 uses the register service operation to register with NRF 226 (1). The register service operation is used to provide an NF profile 520 of an NF service producer 304 to NRF 226, and NRF 226 marks the NF service producer 304 as available to be discovered by other NFs 110. Another of the Nnrf_NFManagement services is an update service operation (i.e., NFUpdate), where an NF service producer 304 uses the update service operation to update its NF profile 520 (1).

[0063] The Nnrf_NFDiscovery service allows an NF 110 to discover services offered by another NF 110 through a query to NRF 226. The service operation defined for the Nnrf_NFDiscovery service is a discover service operation (i.e., NFDiscover). An NF service consumer 302 uses the discover service operation to query NRF 226 (2), and identify other NFs 110 (i.e., an NF service producer 304) in the same Public Land Mobile Network (PLMN) or another PLMN. The discover service operation discovers a set of NFs 110, represented by their NF profiles 520, that are currently registered in NRF 226 and satisfy a number of input parameters. In response to the discover service request, NRF 226 provides information for the NF(s) 110 that match the input parameters to NF service consumer 302. The query to NRF 226 may be constrained so not all NF service producers 304 that provide the desired service are exposed to NF service consumer 302. For example, based on the identity of UE 106, the query may be constrained to only those NF service producers 304 that serve UE 106.

[0064] Based on the other NFs 110 discovered from NRF 226, NF service consumer 302 selects one or more NF service producers 304 to handle service requests. It is assumed that NF service consumer 302 has a number of control plane (CP) transactions, and selects one or more NF service producers 304 to handle the CP transactions. NF service consumer 302 sends an NF service request to an NF service producer 304 for one or more of the CP transactions (3). The NF service producer 304 then provides a service or services based on the NF service request from the NF service consumer 302.

[0065] FIG. 6 illustrates a security architecture 600 of a 5G system 100 as described in 3GPP TS 33.501 (v.18.3.0), which is incorporated by reference as if fully included herein. FIG. 6 illustrates the following security domains: 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 a UE 106 to authenticate and access services via the network securely, including 3GPP access and non- 3GPP access, and in particular, to protect against attacks on the (radio) interfaces. In addition, network access security includes the security context delivery from a serving network (SN) to an access network (AN) for the 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 secure the user access to mobile equipment (ME). Application domain security (IV) is a set of security features that enable applications in the user domain and in the provider domain to exchange messages securely. SBA domain security (V) is a set of security features that enables network functions (NF) 110 of the SBA 200 to securely communicate within the serving network domain and with other network domains. Such security features include network function registration, discovery, and authorization security aspects, as well as the protection for the SBIs 250.

[0066] FIG. 7 illustrates the SBI protocol stack 700 for the SBIs 250. For security protection at the transport layer, NFs 110 support Transport Layer Security (TLS) 702 and TLS 702 is used for transport protection within a PLMN if network security is not provided by other means. TLS 702 (formerly called Secure Sockets Layer (SSL)) is an encryption protocol that authenticates the server in a client-server connection, and encrypts communications between the client and the server. 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 be decrypted only with the private key. Therefore, a server that decrypts data encrypted with the public key of a client proves that the server possesses the private key. A digital certificate (also referred to as a TLS certificate, an X.509 certificate, etc.) is a data file that contains information for verifying a server’s or device’s identity, including the public key, a statement of who issued the digital certificate (i.e., which certificate authority (CA)), an expiration date, etc. TLS 702 uses a handshake process for verifying the digital certificate and the server’s possession of the private key. The TLS handshake also establishes how encryption will take place once the handshake is finished.

[0067] FIG. 8 illustrates a TLS handshake process between NFs 110. On receiving an initial communication from an NF service consumer 302, for example, the NF service producer 304 provides its digital certificate 804 to NF service consumer 302. The NF service consumer 302 then verifies the digital certificate 804 of the NF service producer 304. In mutual or two- way authentication, the NF service consumer 302 provides its digital certificate 804 to NF service producer 304. The NF service producer 304 then verifies the digital certificate 804 of the NF service consumer 302. If both digital certificates 804 are authenticated, then NF service producer 304 and NF service consumer 302 may exchange data over an encrypted TLS connection.

[0068] Digital certificates 804 are issued by a certificate authority (CA), such as through a certificate enrollment process. FIG. 9 illustrates a certificate enrollment process 900. In general, a certificate enrollment process (or procedure) is used by an entity (e.g., an NF 110) to request and obtain a digital certificate 804 from a certificate authority (CA) 906. Digital certificates are used to secure communications and authenticate the identity of a server, client, or user in various secure protocols, such as SSL / TLS. In a Public Key Infrastructure (PKI), an NF 110 obtains a key pair 920 comprising a private key 921 (also referred to as a secret key) and a public key 922. The primary purpose of certificate enrollment is to obtain a digital certificate 804 that contains the public key 922 bound to the identity (e.g., NF Instance ID) of the NF 110. To initiate the certificate enrollment process 900, NF 110 generates a Certificate Signing Request (CSR) 904, which includes the public key 922 and information about the NF 110. NF 110 sends the CSR 904 to a certificate authority 906. Certificate authority 906 (also referred to as a registration authority (RA)) is an entity that stores, signs, and issues digital certificates 804. A digital certificate 804 certifies the ownership of a public key by the named subject of the digital certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. Certificate authority 906 therefore acts as a trusted third party that is trusted both by the owner of the digital certificate 804 and by the party relying upon the digital certificate 804. Certificate authority 906 verifies the identity of NF 110 and the information in the CSR 904. When certificate authority 906 has completed the verification process and is satisfied that the NF 110 is legitimate, it issues a digital certificate 804 to NF 110 that contains the public key 922, identity information, a validity period, and the CA’s digital signature. Certificate authority 906 delivers the issued digital certificate 804 to NF 110. NF 110 installs the digital certificate 804 at an appropriate location. When installed, the digital certificate 804 is ready for 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 trustworthy connection.

[0069] The 3GPP has defined certificate management procedures for NFs 110 in 3GPP TS 33.310 (v.18.1.0), which is incorporated by reference as if fully included herein. Certificate management procedures in an SBA 200 for NFs 110 include: set up of initial trust between NF 110 and an operator certificate authority, certificate enrollment and renewal, validation of usage of digital certificates 804 in an SBA 200, and certification revocation procedures. FIG. 10 illustrates an initial trust general schema. Operations, Administration, and Maintenance (0AM) system 1002 comprises processes and / or functions used in provisioning and managing NFs 110. 0AM system 1002 facilitates the initial trust establishment between an NF 110 and an operator certificate authority 1006. One assumption is that 0AM system 1002 is trusted for the operator certificate authority 1006 (i.e., the trust between the 0AM system 1002 and operator certificate authority 1006 is preestablished). The 0AM system 1002 of the NF 110, which instantiates the NF 110, provides NF 110 with the initial trust to be used during the certificate enrollment procedure, as part of initial configuration of the NF 110. The initial trust may be implemented by OAM-issued certificates, an Initial Authentication Key (IAK), or OAM-issued signature of certain NF profile parameters.

[0070] FIG. 11 illustrates a procedure for set up of initial trust. The 0AM system 1002 configures the initial trust used for the enrollment of the operator certificate in the NF 110 (SI). If the initial trust is established by an initial certificate during or after the NF initialization, the local certificate authority in the 0AM system 1002 should issue the initial certificate to the NF 110 as part of its configuration. This certificate is configured with the NF Instance ID in Subject AltName (SAN) field. The NF 110 generates the private -public key pair 920 and the request of an EE operator certificate to the operator certificate authority 1006 (S2). The Certificate Signing Request (CSR) includes the initial trust (initial OAM- issued certificate, signature of NF profile parameters, or IAK) fetched in SI, and the NF Instance ID in SAN field. The NF 110 signs the request with its private key 921 and includes the digital signature in the request. NF 110 sends a certificate enrollment request 1111 to the operator certificate authority 1006 (S3). The operator certificate authority 1006 verifies the initial trust in the request from the NF 110 and the identity of the NF 110 (NF Instance ID) (S4). If verified, the operator certificate authority 1006 generates the EE operator certificate for the NF 110. Specifically, by checking the digital signature on the certificate enrollment request 1111 against the trust anchor configured in SI, the proof of possession of the private key 921 for the requested operator certificate is verified. Operator certificate authority 1006 verifies as well that the NF Instance ID in the SAN field of the certificate enrollment request 1111 corresponds to the NF Instance ID of the initial OAM-issued certificate. If those verifications are successful, then the operator certificate authority 1006 generates an EE certificate for the NF 110. The operator certificate authority 1006 includes the EE certificate for the NF 110 in a certificate enrollment response 1112 (S5).

[0071] After initial trust is established, certificate enrollment and renewal procedures may be performed, such as shown in FIG. 9. Virtualization and increased modularity of NFs 110 has resulted in multi-vendor environments becoming more prevalent. It is now common for NFs 110 to come from different vendors and for the cloud native environment in which they run to come from yet another vendor and for all of these to be independent of the certificate authority 906 that is authoritative for the digital certificates 804 used to secure communications. In such deployments, it is impractical to manage digital certificates 804 manually. The 3GPP has indicated that certificate management may be performed using Certificate Management Protocol (CMPv2) procedures. CMPv2 is a protocol between a certificate authority 906 and an end entity, and provides multiple certificate management functions, such as certificate enrollment and certificate update. In embodiments described herein, Automated Certificate Management Environment (ACME) protocol may be used as an alternative protocol for certificate management.

[0072] FIG. 12 is a block diagram of an NF 110 and a certificate authority 906 in an illustrative embodiment. NF 110 is a network element or network function (NF) of a 5G core network 104, and may also generally refer to an SB A component. In an embodiment, NF 110 includes the following subsystems: a network interface component 1202 and a security manager 1204 that operate on one or more platforms. Network interface component 1202 may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages, signaling, or other types of messages with other network elements or NFs and / or other entities over a network connection. Network interface component 1202 may operate using a variety of protocols or reference points. Security manager 1204 may comprise circuitry, logic, hardware, means, etc., configured to support security management procedures for an NF, such as certificate management procedures. One or more of the subsystems of NF 110 may be implemented on a hardware platform comprised of analog and / or digital circuitry. For example, security manager 1204 may be implemented on one or more processors 1210 that execute instructions 1214 (i.e., computer readable code) for software that are loaded into memory 1212. A processor 1210 comprises an integrated hardware circuit configured to execute instructions 1214 to provide the functions of NF 110. Processor 1210 may comprise a set of one or more processors or may comprise a multi-processor core, depending on the particular 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 storing information on a temporary basis and / or a permanent basis. Memory 1212 may comprise a random-access memory, or any other volatile or non-volatile storage device. One or more of the subsystems of NF 110 may be implemented on a cloudcomputing platform or another type of processing platform. NF 110 may include various other components not specifically illustrated in FIG. 12.

[0073] Certificate authority 906 is an entity that stores, signs, and issues digital certificates 804. In an embodiment, certificate authority 906 includes the following subsystems: a network interface component 1222 and a certificate controller 1224 that operate on one or more platforms. Network interface component 1222 may comprise circuitry, logic, hardware, means, etc., configured to exchange messages with network elements or NFs and / or other entities over a network connection. Network interface component 1222 may operate using a variety of protocols or reference points. Certificate controller 1224 may comprise circuitry, logic, hardware, means, etc., configured to support certificate management procedures, such as to issue digital certificates 804.

[0074] One or more of the subsystems of certificate authority 906 may be implemented on a hardware platform comprised of analog and / or digital circuitry. For example, certificate controller 1224 may be implemented on one or more processors 1230 that execute instructions 1234 (i.e., computer readable code) for software that are loaded into memory 1232. One or more of the subsystems of certificate authority 906 may be implemented on a cloudcomputing platform or another type of processing platform. Certificate authority 906 may include various other components not specifically illustrated in FIG. 12.

[0075] In an embodiment, ACME protocol 1250 may be used for certificate enrollment and / or renewal procedures between NF 110 and certificate authority 906, which are referred to generally as certificate management. Thus, security manager 1204 of NF 110 implements, operates, or runs an ACME client 1206, and certificate controller 1224 of certificate authority 906 implements, operates, or runs an ACME server 1226. In general, ACME client 1206 registers with the certificate authority 906, and proves domain ownership through challenges (e.g., HTTP-based or DNS-based). The ACME server 1226 running on the certificate authority 906 presents challenges to the ACME client 1206 to confirm domain ownership. After a validation process, the certificate authority 906 may issue the digital certificate 804 to the ACME client 1206 (if validated).

[0076] FIG. 13 illustrates certificate management in an illustrative embodiment. FIGS. 14A- 14D are flow charts illustrating a method 1400 of performing certificate management in an illustrative embodiment. The steps of method 1400 in FIG. 14A will be described with reference to NF 110 as shown in FIG. 12, and the steps of method 1400 in FIGS. 14B-14D will be described with reference to certificate authority 906 as shown in FIG. 12. Those skilled in the art will appreciate that method 1400 may be performed in other systems, devices, or network functions. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

[0077] In FIG. 14A, ACME client 1206 of NF 110 (also referred to as an NF instance) sends a certificate request to certificate authority 906 requesting a digital certificate 804 (step 1402). As illustrated in FIG. 13, NF 110 transmits a certificate request 1304 (e.g., CSR 904) to certificate authority 906. Each NF 110 of a 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 to the certificate request 1304 that may be used to validate NF 110.

[0078] In FIG. 14B, ACME server 1226 of certificate authority 906 receives the certificate request 1304 from NF 110 (step 1422). In response to the certificate request 1304, ACME server 1226 sends an ACME challenge (or set of challenges) to NF 110 (step 1424). As illustrated in FIG. 13, ACME server 1226 sends an ACME challenge 1306 to NF 110 in response to the certificate request 1304. The ACME challenge 1306 is for NF 110 to prove or validate that NF 110 controls or owns a domain (e.g., a domain name). FIG. 15 is a block diagram illustrating a domain 1500 of NF 110 in an illustrative embodiment. The domain 1500 of NF 110 comprises an administrative structure or system of interconnected network objects, systems, and / or resources for delivering and / or accessing services. As illustrated in FIG. 15, the domain 1500 of NF 110 may comprise one or more servers 1502, such as a web server 1504, a Domain Name System (DNS) server 1506, and / or an Application-Layer Protocol Negotiation (ALPN) server 1508, although other resources or types of resources may be in domain 1500.

[0079] In FIG. 13 and FIG. 14B, ACME server 1226 may challenge NF 110 according to a variety of ACME challenge types. In an embodiment, ACME server 1226 may send an HTTP challenge 1307 (e.g., HTTP-01) to NF 110 (optional step 1426). In an embodiment, ACME server 1226 may send a DNS challenge 1308 (e.g., DNS-01) to NF 110 (optional step 1428). In an embodiment, ACME server 1226 may send an ALPN challenge 1309 (e.g., ALPN-01) to NF 110 (optional step 1430).

[0080] In FIG. 14A, ACME client 1206 receives the ACME challenge 1306 from certificate authority 906 (step 1404). ACME client 1206 responds to the ACME challenge 1306 to prove control over the domain 1500 (step 1406). For example, ACME client 1206 writes, uploads, or posts certain information to a server 1502 under the domain 1500 of the NF 110. In an embodiment, ACME client 1206 may write an encrypted NF instance ID 1510 to the server 1502 (step 1408), as shown in FIG. 15. For example, ACME client 1206 may be provisioned with an NF identity encryption key, and ACME client 1206 may encrypt the NF instance ID 1310 based on the NF identity encryption key to generate the encrypted NF instance ID 1510 (step 1410). In an embodiment, ACME client 1206 may write a previous certificate 1512 to the server 1502 (step 1412), as shown in FIG. 15. As an example, NF 110 may have acquired a previous certificate 1512 from another certificate authority. As shown in FIG. 15, a private or domain certificate authority 1520 may issue a previous certificate 1512 (also referred to as a previously-issued certificate, an initial certificate, etc.) to NF 110. The private or domain certificate authority 1520 may be owned or operated by a network operator or the like, and is separate from certificate authority 906 (e.g., a third-part authority). For example, the previous certificate 1512 may comprise an initial certificate issued by the operator certificate authority 1006 during establishment of initial trust.

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

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

[0083] In an embodiment, when a DNS challenge 1308 is used, ACME client 1206 may write the encrypted NF instance ID 1510 and / or the previous certificate 1512 to a record of a DNS server 1506 (optional step 1418 of FIG. 14A). FIG. 17 illustrates a DNS challenge method in an illustrative embodiment. The DNS challenge 1308 from the certificate authority 906 challenges the ACME client 1206 of NF 110 to write to a particular record of DNS server 1506. In an embodiment, the ACME client 1206 writes the encrypted NF instance ID 1510 and / or the previous certificate 1512 to the record 1706 of DNS server 1506 in response to the DNS challenge 1308. ACME client 1206 may also perform additional functions in response to the DNS challenge 1308.

[0084] In an embodiment, when an ALPN challenge 1309 is used, ACME client 1206 may write the encrypted NF instance ID 1510 and / or the previous certificate 1512 with a token to an ALPN server 1508 (optional step 1420 of FIG. 14A). FIG. 18 illustrates an ALPN challenge method in an illustrative embodiment. The ALPN challenge 1309 from the certificate authority 906 challenges the ACME client 1206 of NF 110 to create a file or token 1802, and write the token 1802 to an ALPN server 1508. In an embodiment, the ACME client 1206 writes or appends the encrypted NF instance ID 1510 and / or the previous certificate 1512 with the token 1802 (i.e., as part of or appended to the token) that is written to the ALPN server 1508. ACME client 1206 may also perform additional functions in response to the ALPN challenge 1309. At this point, ACME client 1206 may send a challenge response to certificate authority 906 depending on the challenge method.

[0085] In FIG. 14B, ACME server 1226 retrieves, fetches, or reads the encrypted NF instance ID 1510 and / or the previous certificate 1512 from the server 1502 as written by the ACME client 1206 in response to the ACME challenge 1306 (step 1432). ACME server 1226 may retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 in a variety of ways based on the challenge type. In an embodiment, when an HTTP challenge 1307 is used, ACME server 1226 may retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 with a token 1602 from a URL 1604 of web server 1504 (optional step 1434). In an embodiment, when a DNS challenge 1308 is used, ACME server 1226 may retrieve the encrypted NF instance ID 1510 and / or the previous certificate 1512 from a record 1706 of a DNS server 1506 (optional step 1436). In an embodiment, when an ALPN challenge 1309 is used, 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 with a token 1802 (optional step 1438).

[0086] ACME server 1226 then performs a verification or validation process (step 1440). For the verification process, in an embodiment, ACME server 1226 may determine whether the NF instance ID 1310 in the certificate request 1304 matches the encrypted NF instance ID 1510 when decrypted (step 1442). For example, ACME server 1226 may be provisioned with an NF identity decryption key. As illustrated in FIG. 14C, ACME server 1226 may decrypt the encrypted NF Instance ID 1510 based on the NF identity decryption key (step 1462), and compare the decrypted NF Instance ID with the NF instance ID 1310 in the certificate request 1304 (step 1464).

[0087] In an 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 (step 1444 of FIG. 14B). As illustrated in FIG. 15, when the private or domain certificate authority 1520 issues a previous certificate 1512, the previous certificate 1512 includes an NF instance ID 1516. In an embodiment, ACME server 1226 may validate the NF instance ID 1516 of the previous certificate 1512. For example, ACME client 1206 may calculate a (first) POPO signature for the previous certificate 1512, and write the POPO signature to the server 1502 with the previous certificate 1512. As illustrated in FIG. 14D, ACME server 1226 may retrieve the (first) POPO signature calculated by the ACME client 1206 along with the previous certificate 1512 from the 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 may then compare the (first) POPO signature and the (second) POPO signature to validate trust of the previous certificate 1512 (step 1476). If the POPO signatures match, then ACME server 1226 considers the NF instance ID 1516 of the previous certificate 1512 as “validated” or “trusted”. ACME server 1226 may 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 is already considered “validated” or “trusted”, then ACME server 1226 may 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 validating the POPO signature.

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

[0089] One technical benefit is ACME protocol 1250 may be used to provide automated certificate management. Another technical benefit is the certificate authority 906 is able to verify or validate the identity of a requesting NF 110. As indicated by the 3GPP, a certificate authority 906 should be able to verify that the NF instance ID 1310 in a certificate request belongs to the NF instance requesting the digital certificate 804. A malicious or compromised NF instance may send a rogue certificate request using a compromised NF instance ID. With the security mechanisms described above, a certificate authority 906 is able to verify that the NF instance ID 1310 in a certificate request 1304 belongs to the NF instance requesting the digital certificate 804. This improves security in a 5G system 100.

[0090] FIG. 19 is a message diagram illustrating a certificate management procedure in an illustrative embodiment. 0AM 1002 configures NF 110 with an NF identity encryption key 1901 along with an NF Instance ID 1310, slice information, and / or other NF profile details or parameters (SI). 0AM 1002 also configures the NF profile parameters to be validated at certificate authority 906, such as an NF Instance ID, Fully Qualified Domain Name (FQDN), Internet Protocol (IP) address, NF slice list, an NF identity decryption key 1902, web server 1504 or DNS server 1506 information, etc. (S2). NF 110 requests a digital certificate 804 (with the public key 922, the NF Instance ID 1310 (in SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME Server 1226) (S3). In response to the CSR 904, certificate authority 906 sends an ACME challenge 1306 to NF 110 to write a unique token on web server 1504 or to write a specific value in a text record of DNS server 1506 (S4). NF 110 encrypts the NF Instance ID 1310 with the NF identity encryption key 1901 to generate an encrypted NF Instance ID 1510, and writes a token with the encrypted NF Instance ID 1510 to the web server 1504 or writes the encrypted NF Instance ID 1510 to a text record of DNS server 1506 (S5). NF 110 then sends a challenge completion message to the certificate authority 906 (S6).

[0091] Certificate authority 906 performs the validation process. Certificate authority 906 gets the token / record and validates control of NF 110 over the domain 1500 (S7a). Certificate authority 906 gets the NF Instance ID 1310 from the SAN field of the CSR 904, and fetches the NF identity decryption key 1902 stored against the NF Instance ID 1310 of the NF profile 520 (S7b). Certificate authority 906 decrypts the encrypted NF Instance ID 1510 with the NF identity decryption key 1902, and compares the decrypted NF instance ID with the NF instance ID 1310 present in the CSR 904 (S7c). When there is a match (and other parameters of the NF profile 520 match with the CSR 904), certificate authority 906 issues the digital certificate 804 (S7d). Certificate authority 906 sends the digital certificate 804 to NF 110 (S8).

[0092] FIG. 20 is a message diagram illustrating a certificate management procedure in an illustrative embodiment. 0AM 1002 configures NF 110 with an NF identity encryption key 1901 along with an NF instance ID 1310, slice information, and / or other NF profile details or parameters (SI). 0AM 1002 also configures the NF profile parameters to be validated at certificate authority 906, such as NF instance ID, FQDN, IP address, NF slice list, an NF identity decryption key 1902, ALPN server information, etc. (S2). NF 110 requests a digital certificate 804 (with the public key 922, the NF instance ID 1310 (in SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME Server 1226) (S3). In response to the CSR 904, certificate authority 906 sends an ACME challenge 1306 to NF 110 to write a unique token on an ALPN server 1508 (S4). NF 110 encrypts the NF Instance ID 1310 with the NF identity encryption key 1901 to generate an encrypted NF Instance ID 1510, and writes a token with the encrypted NF Instance ID 1510 to the ALPN server 1508 (S5). Certificate authority 906 performs a TLS handshake with the ALPN server 1508 (S6a). The ALPN server 1508 responds to the TLS handshake by presenting the requested token appended with encrypted NF Instance ID 1510 in the ALPN extension data (S6b).

[0093] Certificate authority 906 performs the validation process. Certificate authority 906 gets the token and validates control of NF 110 over the domain 1500 (S7a). Certificate authority 906 gets the NF Instance ID 1310 from the SAN field of the CSR 904, and fetches the NF identity decryption key 1902 stored against the NF Instance ID of the NF profile 520 (S7b). Certificate authority 906 decrypts the encrypted NF Instance ID 1510 with the NF identity decryption key 1902, and compares the decrypted NF Instance ID with the NF Instance ID 1310 present in the CSR 904 (S7c). When there is a match (and other parameters of the NF profile 520 match with the CSR 904), certificate authority 906 issues the digital certificate 804 (S7d). Certificate authority 906 sends the digital certificate 804 to NF 110 (S8).

[0094] FIG. 21 is a message diagram illustrating a certificate management procedure in an illustrative embodiment. 0AM 1002 configures NF 110 with a previous certificate 1512 (having a validated NF Instance ID 1516, FQDN, etc.) signed from a domain certificate authority, a private certificate authority, etc. (Sla). NF 110 calculates a proof-of-possession (POPO) signature 2101 of the previous certificate 1512 based on the private key associated with the previous certificate 1512 (Sib). 0AM 1002 configures the trust anchor of the domain / private certificate authority 1520 at certificate authority 906 (S2). NF 110 requests a digital certificate 804 (with the public key 922, the NF Instance ID 1310 (in SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME Server 1226) (S3). In response to the CSR 904, certificate authority 906 sends an ACME challenge 1306 to NF 110 to write a unique token on web server 1504 or to write a specific value in a text record of DNS server 1506 (S4). NF 110 writes a token with the previous certificate 1512 and the POPO signature 2101 to the web server 1504 or writes the previous certificate 1512 and the POPO signature 2101 to a text record of DNS server 1506 (S5). NF 110 then sends a challenge completion message to the certificate authority 906 (S6).

[0095] Certificate authority 906 performs the validation process. Certificate authority 906 gets the token / DNS record and validates NF control over the domain (S7a). Certificate authority 906 gets the previous certificate 1512, and verifies the POPO signature 2101 with the public key of the previous certificate 1512 (S7b). When POPO signature validation is successful, certificate authority 906 validates the trust of the previous certificate 1512 (S7c). When trust of the previous certificate 1512 is validated, certificate authority 906 compares the validated NF Instance ID 1516 from the previous certificate 1512 with the NF Instance ID 1310 present in the CSR 904 (S7d). Certificate authority 906 also compares other parameters of the CSR 904 with parameters of the previous certificate 1512 (S7d). When there is a match, certificate authority 906 issues the digital certificate 804 (S7e). Certificate authority 906 sends the digital certificate 804 to NF 110 (S8).

[0096] FIG. 22 is a message diagram illustrating a certificate management procedure in an illustrative embodiment. 0AM 1002 configures NF 110 with a previous certificate 1512 (having an NF Instance ID 1310, FQDN, etc.) signed from a domain certificate authority, a private certificate authority, etc. (Sla). NF 110 calculates a POPO signature 2101 of the previous certificate 1512 based on the private key associated with the previous certificate 1512 (Sib). 0AM 1002 configures the trust anchor of the domain / private certificate authority 1520 at certificate authority 906 (S2). NF 110 requests a digital certificate 804 (with the public key 922, the NF Instance ID 1310 (in SAN field), etc.) by sending a CSR 904 to certificate authority 906 (i.e., ACME Server 1226) (S3). In response to the CSR 904, certificate authority 906 issues an ACME challenge 1306 to NF 110 to write a unique token on an ALPN server 1508 (S4). NF 110 writes a token with the previous certificate 1512 and the POPO signature 2101 to ALPN server 1508 (S5). Certificate authority 906 performs a TLS handshake with the ALPN server 1508 (S6a). The ALPN server 1508 responds to the TLS handshake by presenting the requested token appended with the previous certificate 1512 and the POPO signature 2101 in the ALPN extension data (S6b).

[0097] Certificate authority 906 performs the validation process. Certificate authority 906 gets the token and validates NF control over the domain (S7a). Certificate authority 906 gets the previous certificate 1512, and verifies the POPO signature 2101 with the public key of the previous certificate 1512 (S7b). When POPO signature validation is successful, certificate authority 906 validates the trust of the previous certificate 1512 (S7c). When trust of the previous certificate 1512 is validated, certificate authority 906 compares the validated NF Instance ID 1516 from the previous certificate 1512 with the NF Instance ID 1310 present in the CSR 904 (S7d). Certificate authority 906 also compares other parameters of the CSR 904 with parameters of the previous certificate 1512 (S7d). When there is a match, certificate authority 906 issues the digital certificate 804 (S7e). Certificate authority 906 sends the digital certificate 804 to NF 110 (S8)

[0098] Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.

[0099] Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0100] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0101] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry);

[0102] (b) combinations of hardware circuits and software, such as (as applicable):

[0103] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware; and

[0104] (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

[0105] (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

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

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

Claims

Claims:

1. 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 network function of a 5G network configured to operate an Automated Certificate Management Environment (ACME) client to obtain a digital certificate from a certificate authority via ACME protocol for secure communication by the network function; the ACME client configured to: send a certificate request to the certificate authority indicating a network function instance identifier; receive an ACME challenge from the certificate authority; and write the network function instance identifier as encrypted or a previously- issued certificate to a server under a security domain of the network function in response to the ACME challenge.

2. The apparatus of claim 1, wherein: the ACME challenge comprises a hypertext transfer protocol challenge; and the ACME client is further configured to write the network function instance identifier as encrypted or the previously-issued certificate with a token to a web server.

3. The apparatus of claim 1, wherein: the ACME challenge comprises a domain name system challenge; and the ACME client is further configured to write the network function instance identifier as encrypted or the previously-issued certificate to a record of a domain name system server.

4. The apparatus of claim 1, wherein: the ACME challenge comprises an application-layer protocol negotiation challenge; and the ACME client is further configured to write the network function instance identifier as encrypted or the previously-issued certificate with a token to an application-layer protocol negotiation server.

5. The apparatus of claim 1, wherein:the ACME client is provisioned with a network function identity encryption key; and the ACME client is further configured to encrypt the network function instance identifier based on the network function identity encryption key.

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

7. A method of performing certificate management in a network function of a 5G network, the method comprising: operating an Automated Certificate Management Environment (ACME) client at the network function to obtain a digital certificate from a certificate authority via ACME protocol for secure communication by the network function; the operating comprising: sending a certificate request to the certificate authority indicating a network function instance identifier; receiving an ACME challenge from the certificate authority; and writing the network function instance identifier as encrypted or a previously- issued certificate to a server under a security domain of the network function in response to the ACME challenge.

8. The method of claim 7, wherein: the ACME challenge comprises a hypertext transfer protocol challenge; and the writing comprises writing the network function instance identifier as encrypted or the previously-issued certificate with a token to a web server.

9. The method of claim 7, wherein: the ACME challenge comprises a domain name system challenge; and the writing comprises writing the network function instance identifier as encrypted or the previously-issued certificate to a record of a domain name system server.

10. The method of claim 7, wherein: the ACME challenge comprises an application-layer protocol negotiation challenge; and the writing comprises writing the network function instance identifier as encrypted or the previously-issued certificate with a token to an application-layer protocol negotiation server.

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

12. The method of claim 7, further comprising: calculating a proof of possession signature based on a private key associated with the previously-issued certificate; and writing the proof of possession 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 Automated Certificate Management Environment (ACME) server; the ACME server configured to: receive a certificate request from a network function of a 5G network requesting a digital certificate, wherein the certificate request indicates a network function instance identifier; send an ACME challenge to the network function challenging the network function to prove control over a domain; retrieve an encrypted network function instance identifier or a previously- issued certificate from a server under the domain of the network function; perform a verification process to determine whether the network function instance identifier in the certificate request matches the encrypted network functioninstance identifier when decrypted, or a validated network function instance identifier from the previously-issued certificate; and issue the digital certificate to the network function when the verification process passes.

14. The apparatus of claim 13, wherein: the ACME challenge comprises a hypertext transfer protocol challenge; and the ACME server is further configured to retrieve the encrypted network function instance identifier or the previously-issued certificate with a token from a uniform resource locator of a web server.

15. The apparatus of claim 13, wherein: the ACME challenge comprises a domain name system challenge; and the ACME server is further configured to retrieve the encrypted network function instance identifier or the previously-issued certificate from a record of a domain name system server.

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

17. The apparatus of claim 13, wherein: the ACME server is provisioned with a network function identity decryption key; and the ACME server is further configured to: decrypt the encrypted network function instance identifier based on the network function identity decryption key; and compare the decrypted network function instance identifier 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 a first proof of possession signature calculated by the network function based on a private key associated with the previously-issued certificate; calculate a second proof of possession signature based on a public key associated with the previously-issued certificate; compare the first proof of possession signature with the second proof of possession signature to validate trust of the previously-issued certificate; and compare the network function instance identifier of the previously-issued certificate with the network function instance identifier in the certificate request.

19. A method of performing certificate management, the method comprising: operating an Automated Certificate Management Environment (ACME) server at a certificate authority; the operating comprising: receiving a certificate request from a network function of a 5G network requesting a digital certificate, wherein the certificate request indicates a network function instance identifier; sending an ACME challenge to the network function challenging the network function to prove control over a domain; retrieving an encrypted network function instance identifier or a previously- issued certificate from a server under the domain of the network function; performing a verification process to determine whether the network function instance identifier in the certificate request matches the encrypted network function instance identifier when decrypted, or a validated network function instance identifier from the previously-issued certificate; and issuing the digital certificate to the network function when the verification process passes.

20. The method of claim 19, wherein: the ACME challenge comprises a hypertext transfer protocol challenge; and the retrieving comprises retrieving the encrypted network function instance identifier or the previously-issued certificate with a token from a uniform resource locator of a web server.

21. The method of claim 19, wherein: the ACME challenge comprises a domain name system challenge; and the retrieving comprises retrieving the encrypted network function instance identifier or the previously-issued certificate from a record of a domain name system server.

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

23. The method of claim 19, wherein: the ACME server is provisioned with a network function identity decryption key; and the method further comprises: decrypting the encrypted network function instance identifier based on the network function identity decryption key; and comparing the decrypted network function instance identifier with the network function instance identifier in the certificate request.

24. The method of claim 19, further comprising: retrieving a first proof of possession signature calculated by the network function based on a private key associated with the previously-issued certificate; calculating a second proof of possession signature based on a public key associated with the previously-issued certificate; comparing the first proof of possession signature with the second proof of possession signature to validate trust of the previously-issued certificate; and comparing the network function instance identifier of the previously-issued certificate with the network function instance identifier in the certificate request.

Images