Certificate lifecycle management in a communication network

Abstract

The present disclosure includes a method for managing certificate lifecycle in a communication network, the method being performed by a client provisioned with a pair of public and private keys, and a trust store including one or more certificates from Certificate Authorities, CAs The method comprises sending the message to the server. The message comprises a name of the client, the public key of the client, a list of installed trusted certificates in the trust store of the client. The method further includes receiving, from the server, a response comprising a set of data relating to the public key and / or the trust store of the client, and determining a set of actions relating to the public key of the client and / or the trust store of the client, and executing the set of actions relating to the public key and / or the trust store of the client.

Description

[0001] CERTIFICATE LIFECYCLE MANAGEMENT IN A COMMUNICATION NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a client, a server, a system, and methods performed therein for efficient management of certificates lifecycle in a communication network. Furthermore, a computer program, a computer readable storage medium, and a computer program product are also provided herein. In particular, embodiments herein relate to online certificate lifecycle management in a communication network.

[0004] BACKGROUND

[0005] Public Key Infrastructure (PKI) is an architecture used to manage digital keys and certificates, thereby enabling secure data exchange over the internet. In the PKI, a digital certificate can be generated to verify the ownership of a public key. This certificate is used within a cryptographic protocol to authenticate an end entity, i.e., client, and then provide access to a service.

[0006] Nowadays, telecommunication networks are widely using PKI public key certificates for authentication and secure communication using T ransport Layer Security (TLS) and Internet Key Exchange version 2 (IKEv2) protocols.

[0007] Telecommunication networks are becoming more and more complex, owing to increasingly diverse and demanding use cases, increased virtualization, network slicing, as well as the ongoing disaggregation and distribution of the radio access network (RAN) functions, including shared network with multi-vendor, each one with its own PKI system. In most cases, network elements are provisioned with required certificates in day-0 via a Certificate Management Protocol version 2 (CMPv2) as an example. After that, every operation related to the normal certificate life cycle, such as distribution or removing trusted certificates and / or triggering a new enrollment is performed through different interfaces such as Netconf.

[0008] Due to the network evolution and the requested stricter PKI domains segregation, operational and maintenance activity on a standard PKI system is growing in terms of complexity and costs. More so, depending on different network element capabilities, PKI's operations may require manual activities which may compromise the network security, and, in some cases, a full redeployment of the node which may lead to temporary unavailability of service.

[0009] SUMMARY

[0010] It is an object of the invention to provide an efficient protocol that automatically manages online digital certificates in a communication network. This and other objects of the inventionare achieved by means of different aspects of the invention, as defined by the independent claims. Embodiments of the invention are characterized by the dependent claims.

[0011] According to a first aspect of the invention, a method for managing certificate lifecycle in a communication network is provided. The method is performed by a client provisioned with a pair of public and private keys, and a trust store comprising one or more certificates from Certificate Authorities (CAs). The client is configured to periodically send a message to a server. The method comprises sending a message to the server. The message comprises a name of the client, the public key of the client, and a list of installed trusted certificates in the trust store of the client. The method further comprises receiving a response from the server. The response comprises a set of data relating to the public key and / or the trust store of the client. The method further comprises determining, based on the received set of data, a set of actions relating to the public key of the client and / or the trust store of the client, and executing, in response to the determining, the set of actions relating to the public key and / or the trust store of the client. According to a second aspect of the invention, a method for managing certificate lifecycle is provided. The method is performed by a server comprising a pair of private and public keys, and configured to collaborate with a Public Key Infrastructure (PKI) system. The PKI system comprises a list of of entries, wherein each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities (CAs). The method comprises receiving a message from a client. The message comprises a name of the client, and a list of installed certificates in a trust store of the client. The method further comprises comparing the list of installed certificates in the trust store of the client with an entry of the list of entries of the PKI system, wherein said entry is associated with the client, , and comparing the received public key of the client with said entry of the list of entries of the PKI system. The method further comprises creating a set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client, and sending a response to the client, wherein the response comprises the set of data relating to the public key and / or the trust store of the client. Thus, according to a third aspect of the invention, a client provisioned with a pair of public and private keys, and a trust store comprising one or more certificates from Certificate Authorities (CAs). The client is configured to periodically send a message to a server. The message comprises a name of the client, the public key of the client, and a list of installed certificates in the trust store of the client. The client is further configured to receive a response from the server, wherein the response comprises a set of data relating to the public key and / or the trust store of the client. The client is configured to determine, based on the received set of data, a set of actions relating to the public key of the client and / or the trust store of the client. The client isthen configured to execute, in response to the determining, the set of actions relating to the public key and / or the trust store of the client.

[0012] According to a fourth aspect of the invention, a server comprising a pair of private and public keys, configured to collaborate with a Public Key Infrastructure (PKI). The PKI system comprises a list of entries, wherein each entry is associated with one client, a public key of said client, and a list of trusted Certificate Authorities, CAs, The server is configured to receive a message from a client, wherein the message comprises a name of the client, a public key of the client, and a list of installed certificates in a trust store of the client. The server is configured to compare the list of installed certificates in the trust store of the client with an entry of the list of entries of the PKI system, wherein said entry is associated with the client. The server is further configured to compare the received public key of the client with said entry of the list of entries of the PKI system. The server is configured to create a a set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client, and send a response to the client. The response comprises the set of data relating to the public key and / or the trust store of the client.

[0013] According to a fifth aspect of the invention, a system for managing lifecycle of certificates in a communication network is provided. The system comprises a server according to the fourth aspect and a client according to third aspect. The server comprises a pair of private and public keys configured to collaborate with a Public Key Infrastructure, PKI. The PKI system comprises a list of entries, wherein each entry is associated with one client, a public key of said client, and a list of trusted Certificate Authorities, CAs. The client comprises a private key, a public key and provisioned with a trust store comprising certificates from CAs. The client is configured to perform a method according to the first aspect. The server is configured to perform a method according to the second aspect.

[0014] According to a sixth aspect of the present invention, there is provided a computer program, a computer-readable storage medium, and a product comprising the computer readable storage medium on which the computer program according to an embodiment of the first and second aspect of the invention is stored.

[0015] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For better understanding of the present disclosure, and to show more readily how the invention may be carried into effect, reference will now be made, by way of example, to the following drawings, in which:Figure 1 illustrates a schematic overview depicting a communication network according to embodiments herein;

[0017] Figure 2 shows a schematic flowchart depicting a method performed by a client according to embodiments herein;

[0018] Figure 3 shows a schematic flowchart depicting a method performed by a server according to embodiments herein;

[0019] Figure 4 shows a block diagram depicting a client according to embodiments herein;

[0020] Figure 5 shows a block diagram depicting a server according to embodiments herein; and Figure 6 shows a block diagram depicting a system comprising a client and a server, and a PKI system collaborating with the server according to embodiments herein.

[0021] DETAILED DESCRIPTION

[0022] Embodiments herein relate to communication networks in general, and more specifically to managing certificate lifecycle(s) in communication networks.

[0023] Figure 1 is a schematic overview depicting a communication network 100. The communication network 100 illustrated in Figure 1 shows a client 400, in a Radio Access Network (RAN), wherein the client is within radio coverage of a radio network node 120. The client 400 is further shown to be configured to communicate with a server 500 and a PKI system 600, which are shown to be arranged within a Network Management System (NMS). The NMS may be understood to be comprised by the communication network 100. Details regarding, and / or examples of, the communication network 100, the client 400, the RAN, the radio network node 120, the NMS, the server 500 and the PKI system 620 will be discussed in the below.

[0024] The communication network 100 comprises one or more (RANs and one or more Core Networks (CNs; not shown). The communication network 100 may use a number of different technologies, such as wired or wireless technology, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, NR, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications / Enhanced Data rate for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

[0025] In the communication network 100, a client 400, e.g., a user equipment (UE) such as a mobile station, a non-access point (non-AP) ST A, a STA, a wireless device and / or a wireless terminal, communicate via a RAN to one or more CNs. It should be understood by those skilled in the artthat a "client" and a "UE" are non-limiting terms which mean any terminal, wireless communication terminal, internet of things (loT) capable device. Machine Type Communication (MTC) device. Device to Device (D2D) terminal, or node e.g. smartphone, laptop, mobile phone, sensor, relay, mobile tablets or even a base station communicating within a cell.

[0026] The communication network 100 comprises a radio network node 120 providing radio coverage over a geographical area of a first radio access technology (RAT), such has NR, LTE, UMTS, WiFi or similar. The radio network node 120 may be a radio access network node such as radio network controller or an access point such as a wireless local area network (WLAN) access point or an Access Point Station (AP ST A), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved NodeB (eNB, eNodeB), a base transceiver station. Access Point Base Station, base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of serving a UE or client 400 within a service area served by the radio network node 120 depending e.g. on the first radio access technology and terminology used.

[0027] The communication network 100 may further comprise a number of network nodes 120 providing network functions (NFs) or actual instantiation of NFs, also referred to as NF instances.

[0028] The communication network 100 comprises a server 500, for example, an Online Certificate Lifecycle Management (OCLM) server, and a PKI System 620, for example, a Public Key Infrastructure (PKI) server, (the terms PKI server and PKI system will be used interchangeably in the following), comprising a list of entries. The list of entries may be a list of PKI entities, or End Entities. Alternatively, the PKI system 620 may comprise the one or more PKI entities, also known as the PKI End Entities. The PKI System 620 may be configured as, for example, a Network Function (NF), or an application or service running on a, for example, a network node in the communication network 100.

[0029] The PKI system 620 may be configured to communicate with one or more Certificate Authorities, CAs. The PKI system 620 may comprise one or more CAs. The public key of a CA can be distributed to clients 400, thereby enabling a client 400 to trust a counterpart to which a secure connection is required. A client 400, the public key of the client 400 and the trust store (comprising one or more certificates) of the client 400 may, within the context of PKI, together be understood as a PKI End Entity (EE). Further, a public key of a CA may be understood as a trusted certificate.The each of the respective network nodes 120 may be a stand-alone server, a cloud-implemented server, a distributed server or processing resources in a server farm or same node. Embodiments herein may be implemented as physical bare metal, virtual or cloud native such as Kubernetes or CoreDNS environment in, e.g., hyper-cloud networks.

[0030] The server 500 and the PKI system 620 are illustrated in Figure 1 as being comprised by, hosted by, or arranged inside, a Network Management System (NMS). Parts of, or all of the NMS can be hosted in different places, such as within the RAN or the CN of the communication network 100.

[0031] The client 400 is configured to send, periodically, a message to the server 500. Such a message, sent from the client 400 to the server 500, comprises name of the client 400, the public key of the client 400, and a list of installed trusted certificates in the trust store of the client 400. The client 400 and the server 500 may be configured to communicate using a predetermined protocol. The predetermined protocol may be configured to run on the Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) transport layer. The predetermined protocol may be an Online Certificates Lifecycle Management (OCLM) protocol, which is specifically configured for managing certificate lifecycles in communication networks.

[0032] Further, the client 400 may comprise a component 420. The client 400 may be configured to communicate with the server 500, via the predetermined protocol, using the component 420. Phrased differently, the client 400 may be configured to interact with the server 500 using the component 420. The component 420 may be an OCLM component or an OCLM client. Further, the component 420 of the client 400 may be configured to perform the periodic sending of the message to the server 500.

[0033] The server 500 is then configured to compare the list of installed certificates, comprised in the message, with a list of entries of the PKI system 620. Each entry on the list of entries is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs. Thereby, the PKI system 620 knows from which CAs that each client 400 should have an installed certificate. For example, the list of installed certificates, comprised in the message sent from a client 400, may include three certificates from three different CAs, and then the entry associated with said client 400 may comprise said three different CAs. In such an example, the comparison would show that everything is as it should be. In another example, there might be one or more differences between the list of installed certificates and the list of trusted CAs. Such a difference may be that the list of installed certificates includes an installed certificate which is from a CA which is not on the list of trusted CAs, and then an action may bethat the client 400 should remove said installed certificate. Another difference may be that the list of trusted CAs includes a trusted CA for which there isn't a corresponding installed certificate on the list of installed certificates, and then an action may be that the client 400 should request / install a certificate from said trusted CA. This comparison may therefore be understood as the server 500 being configured to identify the entry(i.e., the entry, such as a PKI EE, associated with the client 400, its public key and its trust store) as it is defined by the PKI system 620, and compare information comprised in the message with information of the entry.

[0034] Further, the server 500 is configured to compare the public key, comprised in the message, with the entry, associated with the client 400, of the PKI system 620. This comparison may therefore be understood as the server 500 being configured to compare the public key, comprised in the message, with the public key of the associated entry, such as a PKI EE, of the PKI system 620. It may therefore be understood that the server 500 may be configured to communicate with the PKI system 620 in order to perform these comparisons. More specifically, the server 500 may be configured to receive information relating to one or more PKI EEs, which are associated with respective clients 400, i.e., the list of entries. The communication between the server 500 and the PKI system may be made using any Application Programming Interface (API), such as, but not limited to, an API based on HTTP or HTTPS.

[0035] The system 500 is then configured to create a set of data based on these comparisons and send a response, comprising the set of data, to the client 400.

[0036] If everything as it should be, with regards to the public key and / or the list of certificates in the trust store of the client 400, then the set of data may indicate that everything is as it should be and / or that no action is needed to be done by the client 400.

[0037] On the other hand, if there is any discrepancy or error, then the set of data may indicate that a set of actions relating to the public key and / or the trust store of the client 400 needs to be performed by the client 400. Further, the set of data may itself comprise a set of actions relating to the public key and / or the trust store of the client 400. In other words, client 400 and / or the server 500 may be configured to determine the set of actions based on the set of data.

[0038] An action of the set of action may relate to a rekeying process, commonly referred to as a "rekey". A rekey is a process through which a client 400 requests a new certificate from a PKI system 620. The request, i.e., the communication, from the client 400 to the PKI system 620 may be done using any standard PKI protocol, such as, but not limited to, the CMPv2 protocol.The above described interactions / communication between the client 400 and the system 500 simplifies the handling with regards to the PKI system 620. It is to be noted that Figure 1 only illustrates a single client 400. However, it follows that there may exist a large number of clients 400 which all periodically sends messages to a system 500 as described in the above. Therefore, the simplification is furthered, thereby making the handling much more efficient.

[0039] The PKI handling is made simpler and more efficient by the enabling of automatic updates of the trust store of clients 400 without the need for manual activity, due to the periodic sending of the above described message between the client 400 and the system 500. Further, the above described interactions ensure that only certificates from trusted and / or required CAs are installed / stored at the client 400. Furthermore, it enables the PKI system 620 to more easily trigger a rekey when such is required. Additionally, it reduces the complexity and costs of Operation and Maintenance (OAM) activities. Further, it enables the server 500 to implement anomaly detection mechanisms which can take automatic, corrective, preventative and / or recovery actions.

[0040] Figure 2 illustrates embodiments of a method 200 for managing certificate lifecycle in a communication network.

[0041] The method 200 is being performed by a client 400, such as the client400 illustrated in Figure 1 and described in the text relating thereto. The client 400 is provisioned with a pair of public and private keys, and a trust store comprising one or more certificates from Certificate Authorities, CAs. The client 400 is configured to periodically send a message to a server 500, such as the client 500 illustrated in Figure 1 and described in the text relating thereto.

[0042] The server 500 may have been provisioned with a pair of public and private keys, which may be asymmetric. Further, the server 500 may comprise a Certificate Authorities Hierarchy (CAH) comprising a list of certificates of one or more clients 400.

[0043] The client 400 may have been provisioned with a pair of public and private keys issued by the server 500. The client 400 also has a trust store which houses the certificates from CAs. The client 400 may have been pre-provisioned with valid trusted certificates and a pair of asymmetric public and private keys issued by a PKI system 620.

[0044] The method 200 comprises, sending 201 the message to the server 500, wherein the message comprises a name of the client 400, the public key of the client 400, a list of installed trusted certificates in the trust store of the client 400. The message may further comprise a random transaction identity, and a message signature signed with the private key of the client 400. In the message sent to the server 500, the name of the client 400 may be a distinguishing identitythat allows the server 500 to identify the client 400, and consequentially the trust store of the client 400 that contains the certificates from required trusted CAs. Examples of digital certificates comprise an X.509 certificate, an OpenPrettyGoodPrivacy certificate. Raw Public Key certificate, and a 1609Dot2 certificate. The transaction identity is expected to be returned by the server 500 when responding to the sent message. The message may be an HyperText Transfer Protocol (HTTP) POST request.

[0045] The message may be a PKIEndEntityHello message, thereby allowing the server 500 to identify the client 400 sending the message. Consequentially, the server 500 is thereby also able to identify the trust store, of the client 400, that comprises the required trusted certificates. The PKIEndEntityHello message may further comprise a list of supported key sizes and algorithms. The key sizes may include Rivest-Shamir-Adleman, RSA (2048-bit, 3072-bit, and 4096-bit), Elliptic Curve Cryptography, ECC (256-bit, 384-bit, and 521-bit), and Advanced Encryption Standard, AES (128-bit, 192-bit, and 256-bit). The supported algorithms may include RSA, ECC (with curves such as secp256rl and secp384rl), AES, and hash functions such as SHA-256, SHA-384, and SHA-512. The supported key sizes and algorithms can advantageously be managed by the server 500 for monitoring and to determine if stronger values can be used instead of current ones.

[0046] The method 200 further comprises, receiving 202 a response from the server 500. The received response may comprise a set of data relating to the public key and / or the trust store of the client 400. The response may further comprise the random transaction identity, a message signature signed with a private key of the server 500, and / or a public key of the server 500. If the transaction identity is comprised in the response, then it is expected to be the same as, i.e., equal to, the one sent to the server 500 in the message.

[0047] The method 200 may further comprise validating 203 the signature of the received message using the public key of the server 500. The method 200 may be configured to not proceed further if the signature is deemed to not be valid.

[0048] After having received 202 the response, and optionally also validating 203 the signature, the method 200 comprises the client 400 determining 205, based on the received set of data, a set of actions relating to the public key of the client 400 and / or the trust store of the client 400. The method 200 further comprises, executing 206, in response to the determining 205, the set of actions relating to the public key and / or the trust store of the client 400.

[0049] The validating 203 may be understood as a standard procedure of establishing secure communication between the client 400 and the server 500. The message and / or the responsemay include all information needed in order to perform authentication between the client 400 and the server 500, thereby providing integrity of the message and / or the response.

[0050] The set of data may comprise information and / or a set of actions relating to the public key and / or the trust store of the client 400. For instance, the set of data may comprise new and / or updated trusted certificates that the client 400 needs to install in the trust store. Furthermore, the set of data may also comprise one or more list of trusted certificates that the client 400 needs to remove from the trust store as a result of the one or more list of certificates being outdated, inactive, or revoked.

[0051] In an instance, the public key of the client 400 may require an update. Hence, the set of actions that the server 500 transmits to the client 400, based on the public key of the client 400, may comprise a rekey process indication. The rekey process indication informs the client 400 that the current public key is outdated and therefore needs to be updated. Hence, when the client 400 executes the received set of actions relating to the public key, the client 400 then sends a rekey request to the PKI system 620.

[0052] Figure 3 shows an example flow chart illustrating steps for performing a method 300 for managing certificate lifecycle.

[0053] The method 300 is performed by a server 500 such as an OCLM server according to embodiments of the invention. The server 500 comprises a pair of private and public keys, and configured to collaborate with a Public Key Infrastructure, PKI, system 620, wherein the PKI system 620 comprises a list of entries. Each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs.

[0054] The method 300 comprises receiving 301 a message from a client 400. The message comprises a name of the client 400, a public key of a client 400, and a list of installed certificates in a trust store of the client 400. The message may further comprise a signature signed with a private key of the client 400, and / or a random transaction identity.

[0055] The method 300 may comprise validating 302 the signature of the message. The method 300 may be configured to not proceed further if the signature is deemed to not be valid.

[0056] After having received 301 the message, and optionally also validating 302 the signature, the method 300 comprises comparing 304 the list of installed certificates in the trust store of the client 400 with the with an entry of the list of entries of the PKI system, wherein said entry is associated with the client 400.The method 300 further comprises comparing 305 the received public key of the client 400 with with said entry of the list of entries of the PKI system 620. The method 300 comprises creating 306 a set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client 400.

[0057] The method 300 further comprises sending 307 a response to the client 400, wherein the response comprises the set of data relating to the public key and / or the trust store of the client 400. The response may further comprise the public key of the server 500, a message signature signed with the private key of the server 500, and / or the random transaction identity provided in the message.

[0058] The response may be a PKIEndEntityHello response. The server 500 may be an Online Certificate Lifecycle Management, OCLM, server. The server 500 may be integrated into a PKI system 620. In other words, the PKI system 620 may comprise the server 500, or be configured to act as the server 500, or be configured to perform the functions of the server 500.

[0059] The set of data may comprise a set of information, and / or a set of actions relating to the public key and / or the list of certificates in the trust store of the client 400. The set of actions in the set of data may relate to the list of certificates in the trust store of the client 400.

[0060] Figure 4 is a block diagram illustrating an embodiment of the client 400, comprising a communication circuitry 402, a processing circuitry 404, and a computer program product 409 in the form of a computer readable storage medium, such as the memory 406.

[0061] The processing circuitry 404 may comprise one or more processors, such as Central Processing Units (CPUs), microprocessors, application processors, application-specific processors, Graphics Processing Units (GPUs), and Digital Signal Processors (DSPs) including image processors, or a combination thereof, and the memory 406 comprising a computer program 408 comprising instructions. When executed by the processor(s), the instructions cause the client 400 to become operative in accordance with embodiments of the invention described herein, in particular with reference to Figure 2.

[0062] The memory 406 may, e.g., be a Random-Access Memory (RAM), a Read-Only Memory (ROM), a Flash memory, or the like. The memory 406 of the client 400 comprises one or more units to be used to store data on, such as indications, certificates, security information, reconfiguration, applications to perform the method disclosed in figure 2 when being executed. The client 400 further comprises a communication circuitry 402 comprising transmitter, receiver, transceiver, and / or one or more antennas. The processing circuitry 404 may alternatively or additionally comprise one or more Application-Specific Integrated Circuits (ASICs), Field-ProgrammableGate Arrays (FPGAs), or the like, which are operative to cause the client 400 to become operative in accordance with embodiments of the invention described herein.

[0063] The memory 406 of the client 400 may configured to store the data related to the trust store of the client 400. Further, the processing circuitry 404 may be configured to execute instructions of the computer program 408 so as to run, or operate, the trust store.

[0064] Figure 5 is a block diagram illustrating an embodiment of the server 500, comprising a communication circuitry 502, a processing circuitry 504, and a computer program product 509 in the form of a computer readable storage medium, such as the memory 506.

[0065] The processing circuitry 504 may comprise one or more processors, such as Central Processing Units (CPUs), microprocessors, application processors, application-specific processors, Graphics Processing Units (GPUs), and Digital Signal Processors (DSPs) including image processors, or a combination thereof, and the memory 506 comprising a computer program 508 comprising instructions. When executed by the processor(s), the instructions cause the server 500 to become operative in accordance with embodiments of the invention described herein, in particular with reference to Figure 3.

[0066] The server 500 further comprises a memory 506. The memory comprises one or more units to be used to store data on, such as indications, certificates, validation information, indications, reconfiguration, applications to perform the methods disclosed herein when being executed, and similar. The server 500 comprises a communication circuitry 502 comprising transmitter, receiver, transceiver, and / or one or more antennas.

[0067] Thus, it is herein provided said server 500 comprising a pair of private and public keys, configured to collaborate with a Public Key Infrastructure, PKI, system. The PKI system comprises a list of entries, wherein each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs. The server 500 comprises processing circuitry 504 and a memory 506, said memory 506 comprising instructions executable by said processing circuitry 504, whereby said server 500 is operative to perform any of the methods herein, in particular, with reference to Figure 3.

[0068] The methods 200, 300 according to the embodiments described in Figures 2 and 3, relating to the client 400 and the server 500, are respectively implemented by means of e.g. a computer program product 409, 509 comprising instructions, i.e., software code portions, which, when executed on at least one processor 404, 504, cause the at least one processor 404, 504 to carry out the actions described herein, as performed by the client 400 or the server 500, respectively. The computer program product 409, 509 may be stored on a computer-readable storagemedium, e.g. a USB stick, a disc or similar. The computer-readable storage medium, having stored thereon the computer program product 409, 509, may comprise the instructions which, when executed on at least one processor 404, 504, cause the at least one processor to carry out the actions described herein. In some embodiments, the computer-read able storage medium may be a non-transitory or transitory computer-readable storage medium.

[0069] As will be readily understood by those familiar with communications design, that functions means or modules may be implemented using digital logic and / or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and / or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a radio network node, for example. Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term "processor" or "controller" as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random-access memory for storing software and / or program or application data, and non-volatile memory. Other hardware, conventional and / or custom, may also be included. Designers of communications receivers will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

[0070] Figure 6 is a block diagram depicting a system 600 comprising a client 400 and a server 500 according to embodiments herein.

[0071] Figure 6 comprises a system 600 based on an Online Certificate Lifecycle Management (OCLM) protocol comprising a client 400 and a server 500 communicating over a communication network 100. The client 400 and the server 500 may be configured to communicate using a predetermined protocol, such as a OCLM protocol. The server 500 may be an Online Certificate Lifecycle Management (OCLM) server 500 configured to collaborate with a PKI system 620. The PKI system 620 comprises system comprises a list of entries 622 , wherein each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs. The PKI system 620 may comprise, or be configured to communicate with one or more CAs. The PKI system 620 may further comprise, or be configured to communicate with one or more PKI Registration Authorities (RA) which authorizes creation of a certificate and provides validated user information to a CA.As part of day-0 standard procedure, the client 400 may be provisioned with a pair of public and private keys. Further, the client 400 has also installed a certificate issued by a PKI RA, and a list of trusted and valid CAs. The client 400 may further comprise an enrolment trust store. The day-0 standard procedure may be performed by an orchestrator, an operator, or a network administrator. Further, the client 400 may also comprise the information about an enrolment server such as the PKI RA server. The provisioned public key and private keys may be asymmetric.

[0072] Further, the client 400 may have been configured to have the address of the OCLM server 500, and to start sending a periodically scheduled message to the OCLM server 500. This configuration setting is also part of the day-0 standard procedure. The client 400 then sends 602 a message to the OCLM server 500, wherein the message comprises a name of the client 400, the public key of the client 400, a list of installed trusted certificates in the trust store of the client 400. The message may further comprise a random transaction identity that the client 400 is expecting in the response, and a message signature signed with the private key of the client 400.

[0073] The message may be a PKIEndEntityHello message. The PKIEndEntityHello message may comprise a list of supported key sizes and algorithms. The list of supported key sizes and algorithms may be used by the server 500 to provide a proper information to the received PKIEndEntiryHello message. The message that the client sends to the server may be a HTTP POST request.

[0074] When the OCLM server 500 receives the message from the client 400, the OCLM server 500, either integrated in or configured to collaborate with the PKI system 620. The OCLM server 500 may be configured to authenticate 604 the client 400 validating, or checking, the signature of the received message to determine the integrity of the request. Further, the OCLM server 500 sends 606 a request to the PKI system 620 for a current public key of the client and a list of required and trusted CAs. Further, the PKI system 620 transmits to the OCLM server 500, the current public key of the client and the list of required trusted CAs that are expected to be installed in the trust store of the client 400. The OCLM server 500 then compares the public key in the message with the current public key received from the PKI system 620. The OCLM server 500 further compares the list of installed certificates in the trust store of the client 400 with with an entry of the list of entries of the PKI system 620, wherein said entry is associated with the client 400.Based on the comparisons of the public key and / or the list of certificates in the trust store of the client 400, the OCLM server 500 creates a set of data. The set of data comprises a set of information, and / or a set of actions relating to the public key and / or the list of certificates in the trust store of the client 400. The set of information may comprise information or details on the status of the public key such as an outdated key. The set of information may further comprise information on the status of a one or more certificates in the list of installed certificates in the trust store of the client 400. The set of actions may further comprise instruction based on the public key and / or the list of certificates in the trust store of the client. In an example, when there is no difference in the comparisons performed by the OCLM server 500 based on the public key and / or the list of certificates in the trust store of the client 400, then the set of actions and / or instruction is empty, or is, alternatively not transmitted. The OCLM server 500 may identify an anomaly regarding the public key, for example, an outdated public key or an outdated certificate. The OCLM server 500 may optionally be configured to report anomaly conditions in an audit log. The OCLM server 500 is then configured to create an action for the client 400 that a rekey is required. The OCLM server 500 may identify an anomaly regarding the list of certificates in the trust store of the client 400, and as a result, creates an action for the list of certificates in the trust store of the client 400. For example, if the client 400 needs to install a new trusted CA that has been provided by the PKI system 620, then the OCLM server 500 creates an action for the list of certificates in the trust store of the client 400. The OCLM server 500 may provide the list of CA that needs to be added / installed, and / or removed from the trust store of the client 400.

[0075] The OCLM server 500 is further configured to send 611 or transmit a response to the client 400. The response may be a PKIEndEntityHello response. The response may comprise a message signature signed with the private key of the server 500, the public key of the server 500, the set of data, and / or the random transaction identity provided in the message. The response that the OCLM server 500 transmits or sends 611 to the client 400 may be an HTTP POST request. When the client 400 receives the response from the OCLM server 500, the client 400 may be configured to validate 612 the signature of the response, using the public key of the OCLM server 500, before continuing. The client 400 is configured to determine 612, based on the received set of data from the OCLM server 500, a set of actions relating to the public key of the client 400 and / or the trust store of the client 400.The set of data may comprise information and / or a set of actions relating to the public key and / or the trust store of the client 400. The set of data may comprise information on the status of the public key and / or the trust store of the client 400. Further, the set of data may comprise a set of actions or instructions that the client 400 needs to take with regards to its current public key and / or its trust store. Furthermore, theclient 400 is configured to execute 613, in response to the determined set of actions relating to the public key and / or the trust store of the client 400.

[0076] If the OCLM server 500, via the transmitted set of data, informs the client 400 that a rekey is required, then the client 400 may start the rekey process by sending a Key Update Request (KUR) to the OCLM server 500. The KUR process comprises the client 400 sending a KUR message to the OCLM server 500. The OCLM server 500, in collaboration with the PKI system 620, authenticate and issue a new public key which is being sent back to the client 400.

[0077] The client 400 may need to take an action with regards to the trust store based on information that one or more certificates in the trust store have to be removed or uninstalled. The client 400 may execute a set of actions relating to installing one or more active and trusted certificates in the trust store. The one or more active and trusted certificates may be provided by the OCLM server 500 in the set of data in the transmitted response.

[0078] The invention, as disclosed in the present disclosure, enables automatic update(s) of a trust store of a client without any manual activity. Such manual activity may further require the use of other Operation and Maintenance interfaces, that could be unavailable when needed.

[0079] However, the invention as herein disclosed also removes such requirements. Thereby, the complexity and cost of routine Operation and Maintenance activities (needed for any PKI) is greatly reduced.

[0080] Furthermore, the invention as herein disclosed ensures that only the strictly required CAs are installed on a client. In other words, the invention makes sure that unnecessary CAs are removed, thereby providing an increased reliability and reduced storage use.

[0081] The invention further enables the server 500 to be able to trigger a new rekey for a client 400 when a rekey is required. Additionally, the invention further allows the server 500 to implement anomaly detection mechanisms to take automatic corrective or preventive actions with regards to CAs and PKIs.

[0082] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1. A method (200) for managing certificate lifecycle in a communication network (100), the method being performed by a client (400) provisioned with a pair of public and private keys, and a trust store comprising one or more certificates from Certificate Authorities, CAs, wherein the client (400) is configured to periodically send a message to a server (500), the method (200) comprising:sending (201) the message to the server (500), wherein the message comprises a name of the client, the public key of the client, and a list of installed trusted certificates in the trust store of the client;receiving (202) a response from the server (500), wherein the response comprises a set of data relating to the public key and / or the trust store of the client¬ determining (205), based on the received set of data, a set of actions relating to the public key of the client and / or the trust store of the client; andexecuting (206), in response to the determining, the set of actions relating to the public key and / or the trust store of the client.

2. The method (200) according to claim 1, wherein the message further comprises:a random transaction identity, and / ora message signature signed with the private key of the client; andwherein the response further comprises:the random transaction identity, and / ora message signature signed with a private key of the server and a public key of the server.

3. The method (200) according to claim 2, further comprising:validating (203) the signature of the received message using the public key of the server, and if the signature is valid:determining (205), based on the received set of data, the set of actions relating to the public key of the client and / or the trust store of the client; and executing (206), in response to the determining, the set of actions relating to the public key and / or the trust store of the client.

4. The method (200) according to any one of claims 1 to 3, wherein the message is a PKIEndEntityHello message.

5. The method (200) according to claim 4, wherein the PKIEndEntityHello message further comprises a list of supported key sizes and algorithms.

6. The method (200) according to any one of claims 1 to 5, wherein the set of data comprises information and / or a set of actions relating to the public key and / or the trust store of the client.

7. The method (200) according to any one of claims 1 to 6, wherein the set of actions relating to the trust store of the client comprises an instruction to add and / or remove one or more trusted certificates in the trust store of the client.

8. The method (200) according to any one of claims 1 to 6, wherein the set of actions on the public key of the client comprises a rekey process indication; andwherein the executing, in response to the determining, the set of actions further comprises an instruction to send a rekey request to a PKI system 620.

9. A client (400) provisioned with a pair of public and private keys, and a trust store comprising one or more certificates from Certificate Authorities, CAs, wherein the client is configured to periodically send a message to a server (500), and the client (400) is configured to:send (201) the message to the server (500), wherein the message comprises a name of the client, the public key of the client, a list of installed trusted certificates in the trust store of the client, a random transaction identity, and a message signature signed with the private key of the client;receive (202) a response from the server (500), wherein the response comprises the random transaction identity, a message signature signed with a private key of the server, a public key of the server, the random transaction identity, and a set of data relating to the public key and / or the trust store of the client;determine (205), based on the received set of data, a set of actions relating to the public key of the client and / or the trust store of the client; andexecute (206), in response to the determining, the set of actions relating to the public key and / or the trust store of the client.

10. The client (400) according to claim 9 configured to perform the method according to any one of claims 2 to 8.

11. A method (300) for managing certificate lifecycle, the method performed by a server (500) comprising a pair of private and public keys, and configured to collaborate with a Public Key Infrastructure, PKI, system (620), wherein the PKI system comprises a list of entries, wherein each entry is associated with one client (400), a public key of said client (400), and a list of trusted Certificate Authorities, CAs, the method (300) comprising:receiving (301) a message from a client (400), wherein the message comprises a nameof the client, a public key of the client, and a list of installed certificates in a trust store of the clien ¬ comparing (304) the list of installed certificates in the trust store of the client with an entry of the list of entries of the PKI system, wherein said entry is associated with the client (400);comparing (305) the received public key of the client with said entry of the list of entries of the PKI system;creating (306) a set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client; andsending (307) a response to the client (400), wherein the response comprises the set of data relating to the public key and / or the trust store of the client.

12. The method (300) according to claim 11, wherein the message further comprises:a random transaction identity, and / ora message signature signed with the private key of the client; andwherein the response further comprises:the random transaction identity, and / ora message signature signed with a private key of the server and a public key of the server.

13. The method (300) according to claim 12, further comprising:validating (302) the signature of the message, and if the signature is valid:comparing (304) the list of installed certificates in the trust store of the client with an entry of the list of entries of of the PKI system, wherein said entry is associated with the client (400);comparing (305) the received public key of the client with said entry of the list of entries of the PKI system;creating (306) the set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client; andsending (307) the response to the client (400),14. The method (300) according to any one of claims 11 to 13, wherein the response is a PKIEndEntityHello response.

15. The method (300) according to any one of claims 11 to 14, wherein the server (500) is an Online Certificate Lifecycle Management, OCLM, server.

16. The method (300) according to any one of claims 11 to 15, wherein the server is integrated into a PKI system.

17. The method (300) according to any one of claims 11 to 16, further comprising:detecting if there is a difference based on the comparison performed on the public key and / or the certificates in the trust store of the client.

18. The method (300) according to claim 17, further comprising:reporting the detected difference in an audit log.

19. The method (300) according to any one of claims 11 to 18, wherein the set of data comprises a set of information, and / or a set of actions relating to the public key and / or the list of certificates in the trust store of the client.

20. The method (300) according to claim 19, wherein the set of actions relating to the list of certificates in the trust store of the client comprises:sending an instruction to add and / or remove one or more trusted certificates in the trust store of the client.

21. A server (500) comprising a pair of private and public keys, configured to collaborate with a Public Key Infrastructure, PKI, system (620), wherein the PKI system comprises a list of entries, wherein each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs,; and the server is configured to:receive (301) a message from a client (400), wherein the message comprises a public key of the client, a list of installed certificates in a trust store of the client, a signature signed with a private key of the client, and a random transaction identity;compare (304) the list of installed certificates in the trust store of the client with an entry of the list of entries of the PKI system, wherein said entry is associated with the client (400); compare (305) the received public key of the client with said entry of the list of entries of the PKI system ;create (306) a set of data, based on the comparisons of the public key and / or the list of certificates in the trust store of the client; andsend (307) a response to the client (400), wherein the response comprises a message signature signed with the private key of the server, the public key of the server, the set of data, and the random transaction identity provided in the message.

22. The server (500) according to claim 21 configured to perform the method according to any one of claims 12 to 20.

23. A system (600) for managing lifecycle of certificates in a communication network, wherein the system comprises a server (500) and a client (400), the server (500) comprises a pair of private and public keys configured to collaborate with a Public Key Infrastructure, PKI, system (620), wherein the PKI system comprises a list of entries, wherein each entry is associated with one client 400, a public key of said client 400, and a list of trusted Certificate Authorities, CAs;, and wherein the client (400) is provisioned with a pair of private and public keys and a trust store comprising certificates from Certificate Authorities, CAs;wherein the client (400) is configured to perform the method according to any one of claims 1 to 8; andwherein the server (500) is configured to perform the method according to any of claims 11 to 20.

24. A computer program (408, 508) comprising instructions which, when executed by a processor of a communication device, configure the communication device to perform the method according to any of claims 1 to 8, or 11 to 20.

25. A computer-readable storage medium (406, 506) having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a communication device, configuring the communication device to perform the method according to any of claims 1 to 8, or 11 to 20.

26. A carrier containing the computer program (408, 508) of claim 24, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

27. A computer program product (409, 509) comprising a computer readable storage medium on which the computer program (408, 508) according to claim 24 is stored.

Images