WO2023069062A1

WO2023069062A1 - Blockchain-based certificate lifecycle management

Info

Publication number: WO2023069062A1
Application number: PCT/US2021/055372
Authority: WO
Inventors: Helen Balinsky; Bruno MEYBOM POSPICHIL; Flavio CAVALCANTE TABOSA; JR. Francisco FERREIRA DE MENDONCA; Lucas Lemos ROSA; Pedro Felippe DOMINGOS FERNANDES; Vitor Nadjim MOTA OUABDELKADER; Wanialdo Eduardo DE LIMA DA SILVA
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2021-10-18
Filing date: 2021-10-18
Publication date: 2023-04-27

Abstract

In one example in accordance with the present disclosure, an electronic device is described. An example electronic device includes a processor. The example processor is to run an application that uses a certificate. The example processor is to run an agent to request the certificate for the application from a blockchain service, and to perform a certificate lifecycle management transaction for the application based on the certificate received from the blockchain service.

Description

BLOCKCHAIN-BASED CERTIFICATE LIFECYCLE MANAGEMENT

BACKGROUND

[0001] Electronic devices may communicate with each other. In some examples, electronic devices may communicate with each other over a network. Some examples of networks include a local area network, a wide area network and the internet.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The accompanying drawings illustrate various examples of the principles described herein and are part of the specification. The illustrated examples are given merely for illustration, and do not limit the scope of the claims.

[0003] Fig. 1 is a block diagram of an electronic device to perform certificate lifecycle management transactions, according to an example.

[0004] Fig. 2 is a block diagram of a system for performing certificate lifecycle management, according to an example.

[0005] Fig. 3 is a flow diagram illustrating a method for performing certificate lifecycle management transactions.

[0006] Fig. 4 is a sequence diagram illustrating certificate issuance, according to an example.

[0007] Fig. 5 is a sequence diagram illustrating certificate issuance, according to an example.

[0008] Fig. 6 is a sequence diagram illustrating certificate revocation, according to an example. [0009] Fig. 7 is a sequence diagram illustrating certificate revocation, according to an example.

[0010] Fig. 8 is a sequence diagram illustrating certificate revocation, according to an example.

[0011] Fig. 9 is a sequence diagram illustrating a certificate update, according to an example.

[0012] Fig. 10 is a sequence diagram illustrating a certificate update, according to an example.

[0013] Fig. 11 is a sequence diagram illustrating a certificate update, according to an example.

[0014] Fig. 12 depicts a non-transitory machine-readable storage medium for certificate lifecycle management, according to an example.

[0015] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings.

DETAILED DESCRIPTION

[0016] Certificates may be used to establish the identity of web services on a network (e.g., the internet). As used herein, a certificate (also referred to as a digital certificate, public key certificate, or identity certificate) is an electronic file used to prove ownership of a public key. Trust in the process of issuing and maintaining certificates is expected by businesses and individuals to continue using web services. With that basic trust, users may be confident that malicious individuals cannot intercept or otherwise interfere with interactions over an otherwise untrusted network infrastructure (e.g., the internet).

[0017] In some examples, certificates that identify web services on the internet are issued by a certificate authority (CA). The process of issuing a certificate involves the generation of a public/private key pair by an entity desiring a certificate. This entity may be referred to as the “subject” of the certificate.

[0018] In some cases, applications may transport sensitive information. For example, web applications may leverage certificates to create secure channels. Issuing, installing, revoking, and removing those security certificates may involve manual operations and configurations. These manual processes may become troublesome as the number of host devices, servers, and services increase.

[0019] Security is a concern for computing. For example, modern web applications may exchange sensitive information through the internet while keeping the sensitive information secret. Applications and servers may provide secure communication channels by leveraging mechanisms such as the Secure Sockets Layer (SSL) or transport layer security (TLS) protocols. These protocols use asymmetric encryption to share secret keys between endpoints and to encrypt communications.

[0020] Servers and services use certificates with private keys to create a secure channel. Certificates may identify an electronic device (e.g., a server) or services. For example, certificates may be used to match a hostname that a computing device access. Certificates may be stored in file formats, trusted platform module (TPM) hardware, certain directories on operating systems, or may be embedded in applications. As seen by these scenarios, these different possibilities make management of certificates difficult.

[0021] In some examples, organizations may perform manual configuration of certificates. This may prove challenging for an organization. For example, system administrators may use special privileges or credentials to install certificates on servers. They may also determine the correct installation procedure and sometimes test applications manually. Depending on the size of the environment, administrators may do that repeatedly, and tasks may span for days leading to human errors or rework. Furthermore, certificates may expire or may be compromised. When this happens, administrators may update or remove the expired or compromised certificates from the servers, also manually. [0022] There are also cases where administrators outsource part of these certificate management tasks to unskilled people. In these cases, this may lead to misconfigurations and social engineering attacks, resulting in improper use of administrative credentials and security certificates.

[0023] As seen by these examples, certificate management involves challenges for computing applications. For example, public key infrastructure (PKI) for an organization may be complex, which may result in a considerable amount of manual work. For example, system administrators of companies may set up and manage certificates manually. PKI may include a framework and services that provide for the generation, production, distribution, control, accounting, and destruction of certificates. Components of a PKI may include the personnel, policies, processes, server platforms, instructions (e.g., code), and workstations used for the purpose of administering certificates and publicprivate key pairs, including the ability to issue, maintain, recover, and revoke certificates.

[0024] In some examples, a PKI may contain various entities. For example, a PKI may include a certificate manager, certificate scanning tool, certificate log server, internal root CA, internal issuing CA, certificate database, hardware security module (HSM), and/or an external CA. Given the security, privacy and verification issues, a PKI may provide valuable security protections as any loss, misuse, disclosure, or unauthorized access to or modification of security keys and certificates would have a debilitating impact on the mission of an organization.

[0025] The present specification describes examples of automated certificate lifecycle management based on a blockchain ledger. In some examples, a PKI may be created using blockchain as the substrate. For example, blockchain may provide a ledger to record certificate managers, certificate agents, certification authority and certificate keys. Smart contracts may be used to keep the integrity of certificate lifecycle operations.

[0026] In some examples, a device with inherent signature key capabilities may be used to provide a secure initial registration of an electronic device on the blockchain ledger. In an example of a PKI, certificate lifecycle management may be handled by independent modules (e.g., an agent associated with a given application). In this blockchain-based approach, a blockchain service using a blockchain ledger may handle certificate lifecycle management activities transparently.

[0027] In some examples, a smart contract and blockchain ledger may be used for certificate management. When managing certificate information, a single blockchain ledger may be used as a part of a smart contract. As used herein, a “smart contract” may include instructions stored on an electronic device that automatically execute based on conditions being met. In the examples described herein, the process of managing the lifetime of a certificate may be fully automated. These processes may include issuance, revocation and update (e.g., rotation, rekeying) of a certificate.

[0028] The features of a blockchain ledger and smart contract may be used to perform certificate management operations and certificate lifecycle operations (referred to herein as certificate lifecycle management). A blockchain ledger can record transactions and keep a trusted record of the transactions. Once recorded in the blockchain ledger, a transaction cannot be altered. A blockchain is a digital ledger of cryptographically signed transactions that are grouped into blocks. Each block in the blockchain ledger is cryptographically linked to the previous block (making it tamper evident) after validation and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify, thus creating tamper resistance. New blocks may be replicated across copies of the blockchain ledger, and any conflicts may be resolved automatically using established rules.

[0029] A blockchain ledger stores private and public keys from certificates that may include certification authority (CA) certificates, application certificates, or a combination thereof. Also, a blockchain service may run smart contracts (SC) that can issue, renew, revoke and rekey certificates. Revocation of certificates is a feature of a PKI. From the perspective of the blockchain ledger, a revocation transaction (RT) may include marking an old certificate as revoked. Renewing and rekeying transactions may work similarly within the blockchain ledger. For example, the SC may create a new certificate with updated information and may revoke the previous certificate on the blockchain ledger. In this specification, renew and rekey operations are described as update certificate transactions (UCT).

[0030] In an example, the present specification describes an electronic device. The electronic device includes a processor. In this example, the processor runs an application that uses a certificate. The processor may also run an agent to request the certificate for the application with a blockchain service. The agent may perform a certificate lifecycle management transaction for the application based on the certificate received from the blockchain service. [0031] In another example, the present specification also describes a method. The method includes registering an agent of an application at a blockchain service. The method also includes performing, by the blockchain service, a certificate lifecycle management transaction with the agent of the application.

[0032] In yet another example, the present specification also describes a non-transitory machine-readable storage medium that includes instructions, when executed by a processor of an electronic device, cause the processor to run an application that uses a certificate. The instructions further cause the processor to send a request to a certificate manager to issue the certificate for the application with a blockchain service. The instructions additionally cause the processor to receive the issued certificate from the blockchain service.

[0033] As used in the present specification and in the appended claims, the term “processor” may be a controller, an application-specific integrated circuit (ASIC), a semiconductor-based microprocessor, a central processing unit (CPU), and a field-programmable gate array (FPGA), and/or other hardware device.

[0034] As used in the present specification and in the appended claims, the term “memory” may include a computer-readable storage medium, which computer-readable storage medium may contain, or store computer-usable program code for use by or in connection with an instruction execution system, apparatus, or device. The memory may take many types of memory including volatile and non-volatile memory. For example, the memory may include Random Access Memory (RAM), Read Only Memory (ROM), optical memory disks, and magnetic disks, among others. The executable code may, when executed by the respective component, cause the component to implement the functionality described herein.

[0035] Turning now to the figures, Fig. 1 is a block diagram of an electronic device 102 to perform certificate lifecycle management transactions, according to an example. As described above, the electronic device 102 includes a processor 104. The processor 104 of the electronic device 102 may be implemented as dedicated hardware circuitry or a virtualized logical processor. The dedicated hardware circuitry may be implemented as a central processing unit (CPU). A dedicated hardware CPU may be implemented as a single to many-core general purpose processor. A dedicated hardware CPU may also be implemented as a multi-chip solution, where more than one CPU are linked through a bus and schedule processing tasks across the more than one CPU. [0036] A virtualized logical processor may be implemented across a distributed computing environment. A virtualized logical processor may not have a dedicated piece of hardware supporting it. Instead, the virtualized logical processor may have a pool of resources supporting the task for which it was provisioned. In this implementation, the virtualized logical processor may be executed on hardware circuitry; however, the hardware circuitry is not dedicated. The hardware circuitry may be in a shared environment where utilization is time sliced.

[0037] In some examples, a memory may be implemented in the electronic device 102. The memory may be dedicated hardware circuitry to host instructions for the processor 104 to execute. In another implementation, the memory 104 may be virtualized logical memory. Analogous to the processor 104, dedicated hardware circuitry may be implemented with dynamic randomaccess memory (DRAM) or other hardware implementations for storing processor instructions. Additionally, the virtualized logical memory may be implemented in an abstraction layer which allows the instructions to be executed on a virtualized logical processor, independent of any dedicated hardware implementation. [0038] The electronic device 102 may also include instructions. The instructions may be implemented in a platform specific language that the processor 104 may decode and execute. The instructions may be stored in the memory during execution. The instructions may include operations executable by the processor 104 to perform certificate lifecycle management transactions. The instructions when executed may enable the processor 104 to run an application 106 that uses a certificate 110. For example, the application 106 may provide a network resource. In some examples, the application 106 may be a web service or may be a component of a web service. Examples of web services include e-commerce, banking services, and email services. The application 106 may use the certificate 110 to prove ownership of a public key used for secure communications.

[0039] The instructions may also include operations executable by the processor 104 to run an agent 108 for the application 106. In some examples, the agent 108 may request the certificate 110 for the application 106 from a blockchain service. The agent 108 may also perform a certificate lifecycle management transaction for the application 106 based on the certificate received from the blockchain service.

[0040] The agent 108 may be implemented in different approaches. In a first example, the agent 108 may be internal to the application 106. For example, in this approach, the agent 108 may be implemented as a software module inside the application 106. The agent 108 may be imported or may be used as a library, package, submodule and so on.

[0041] In another example, the agent 108 may be invisible to the application 106. For example, the application 106 may not be aware of the presence of the agent 108. In this case, the application 106 may run and expects that the certificate 110 it uses will be provided at an expected location. In this approach, the agent 108 may perform certificate management operations for the application 106.

[0042] In another example, the agent 108 may be separate from the application 106, but the application 106 may be aware of the agent 108. In this case, the application 106 may use an application programming interface (API) to communicate with the agent 108. Through this API, the application 106 may request a certificate operation or waits for push certificate operations.

[0043] In some examples, the application 106 may include internal programmatic mechanisms to check the integrity and validity of the certificate 110 that it is using. In this case, the application 106 may not run if an invalid certificate is available. In some examples, a programming language and/or security libraries used by the application 106 may provide validation mechanisms (e.g., exception handling) for the certificate 110.

[0044] In some examples, the application 106, the agent 108, or both may be registered with the blockchain service. Fig. 2 illustrates a system in which the electronic device 102 communicates with a blockchain service.

[0045] Referring briefly to Fig. 2, this block diagram illustrates a system 200 for performing certificate lifecycle management, according to an example. The system 200 includes an electronic device 202 that implements an application 206 and an agent 208 as described in Fig. 1 . The system 200 also includes a certificate manger 212. In this example, the certificate manger 212 is an electronic device to perform certificate management operations within the system 200. For example, an administrator (e.g., an administrative user) may access the certificate manager 212 to perform management operations.

Examples of certificate management operations include issuing a new certificate for the application 206, revoking a certificate, and updating a certificate.

[0046] Another example of a certificate management operation includes registering the application 206 and/or the agent 208 with a blockchain service 214. In some examples, the blockchain service 214 may include a blockchain ledger 218 to record certificate lifecycle management transactions. The blockchain service 214 may record information for a certificate to the blockchain ledger 218. As used herein, a “blockchain ledger” is a series of records (also referred to as blocks) that are linked together using cryptography. Each record in the blockchain ledger 218 may be signed with a cryptographic hash of the previous record. The data in any given record of the blockchain ledger 218 cannot be altered retroactively without altering all subsequent records. As used herein, recording a record to the blockchain ledger 218 may include generating a new record, saving information in the new record and signing the new record with the cryptographic hash of the previous record.

[0047] In some examples, the blockchain ledger 218 may record when a certificate is issued, revoked, and updated. In some examples, the blockchain ledger 218 may also store the certificate in a block. For example, the blockchain ledger 218 may store an issued certificate for an application 206 in a block. At some point, the certificate may be revoked. In this case, the blockchain ledger 218 may store a record of the certificate revocation in another block. The blockchain ledger 218 may also store a revoked certificate in this case in yet another block. If a new certificate is issued, the blockchain ledger 218 may store the new certificate in a block, and so forth. In this manner, the blockchain ledger 218 may make the most current certificate available to the agent 208 of the application 206.

[0048] A smart contract 216 may automate the certificate lifecycle management transaction with the agent 208. For example, the smart contract 216 may automate sending an issued certificate to the agent 208 based on the identity of the agent 208 or application 206.

[0049] In some examples, a registration process may be performed to register the application 206, the agent 208, or both with the blockchain service 214. In some examples, the application 206 or the agent 208 may be registered with a blockchain service 214 with one of a public key exchange, a security phrase, a one-time pad (OTP), or a combination thereof.

[0050] In some examples, an administrator may register the application 206 or agent 208 using hardware-stored signature keys. In this case, signature keys stored in a secure hardware location (e.g., TPM hardware) may be used to identify the application 206 or agent 208 to the blockchain service 214. In some examples, the blockchain service 214 may record the registration of the application 206 or agent 208 in the blockchain ledger 218. Thus, the application 206 and agent 208 may run on an electronic device 202 with security hardware to store a pair of signature keys. The public key of that pair may be enrolled in the blockchain ledger 218 to register the application 206 or agent 208. In this manner, the electronic device 202 may be a blockchain-enabled device from inception. This approach provides a strong identity for the application 206 or agent 208 using the hardware-stored key pair for a signature, thus making the application 206 or agent 208 capable of automatically identifying itself to the blockchain ledger 218 without human intervention. Through this registration process, the end-entities can trust each other automatically.

[0051] Once registered on the blockchain service 214, the smart contract 216 may perform automatic certificate operations with the agent 208 based on the identity of the application 206 or agent 208. For example, communication from the agent 208 to the blockchain service 214 may include the registered public key of the electronic device 202. The smart contract 216 may verify the identity of the agent 208 using this registered public key to allow a certificate lifecycle management transaction to proceed.

[0052] In some examples, the smart contract 216 may allow a given agent 208 to perform certificate lifecycle management transactions based on an assigned role of the agent 208. For example, the smart contract 216 may allow a given agent 208 to request a certificate for a given application 206, where the agent 208 and application 206 are registered in the blockchain ledger 218 as a related pair. As used herein, a “transaction” is an operation performed in the process of issuing, revoking and/or updating a certificate.

[0053] In some examples, the blockchain service 214 may provide functionality that may replace several different modules within a PKI environment. Use of the blockchain service 214 may accelerate the applicationdevelopment process and may also improve control and auditing of certificates. [0054] The blockchain ledger 218, as a secure transaction storage, may provide for the following certificate lifecycle management operations: inventory; accountability; logging source; certificate request reviews (e.g., registration authority; private key security; continuous monitoring of certificates; certificate transparency; and CA trust. The smart contract 216 may provide for the following certificate lifecycle management operations: automation; ownership; enforcing validity periods; security key length; and signing procedures.

[0055] Referring again to Fig. 1 , the agent 108 may identify itself to the blockchain service with a hardware-stored signature keys unique to the electronic device. As described above, an administrator may register the agent 108 and/or the application 106 with the blockchain service using a public key of the electronic device 102 that is stored in a secure hardware location (e.g., a TPM). When communicating with the blockchain service, the agent 108 may include the registered signature key to identify itself to the blockchain service. [0056] In some examples, certificate lifecycle management by the agent 108 may include one of: receiving an initial certificate 110 from the blockchain service, receiving a revoked certificate 110 from the blockchain service, and receiving an updated certificate 110 from the blockchain service.

[0057] In some examples, the application 106 may send a request for a certificate 110 to the agent 108. For example, the application 106 may determine that it lacks a valid certificate 110. In this case, the request may be referred to as an application-initiated request. In an example, the application 106 may never have received an issued certificate 110. In another example, the certificate 110 may be revoked. In yet another example, the application 106 may determine that the certificate 110 is unsafe and should be revoked, in which case, the application 110 may treat the certificate 110 as invalid.

[0058] In some examples, the agent 108 may monitor the application 106 to determine that the application 106 lacks a valid certificate 110. The agent 108 may send a request for a certificate 110 to the blockchain service in response to determining that the application 106 lacks a valid certificate. In this case, the request may be referred to as an agent-initiated request. In some other examples of an agent-initiated approach, the agent 108 may actively query the blockchain service for certificate status and possible pending operations. In other examples, the agent 108 may wait for notification from the blockchain service about certificate status before the agent 108 performs a certificate lifecycle management operation.

[0059] Upon receiving the request from the agent 108, the smart contract of the blockchain service may validate the request based on the registered security key of the agent 108. The blockchain service may retrieve the current certificate 110 from the blockchain ledger based on an instruction of the smart contract. For example, the smart contract may automatically identify which certificate should be retrieved from the blockchain ledger for the application 106. The blockchain service may send the certificate 110 to the agent 108 and may record the transaction in the blockchain ledger.

[0060] Upon receiving the certificate 110 from the blockchain service, the agent 108 may provide the certificate 110 to the application. In some examples, the agent 108 may send the certificate 110 directly to the application 106, and the application 106 may be responsible for saving the certificate 110 in a manner and location to begin using the certificate 110. In some examples, the agent 108 may provide the certificate 110 to the application 106 in an invisible or transparent manner in which the application 106 accesses the certificate 110 in an expected location without having to manage the certificate 110 itself. [0061] The agent 108 may perform a certificate lifecycle management transaction for the application 106 based on the certificate received from the blockchain service. One example of a certificate lifecycle management transaction includes issuing an initial certificate to the application 106. Examples of issuing the certificate 110 are described in Figs. 4-5. In another example of a certificate lifecycle management transaction, the agent 108 may perform certificate revocation to remove a revoked certificate 110. Examples of revoking the certificate 110 are described in Figs. 6-8. In yet another example of a certificate lifecycle management transaction, the agent 108 may update a certificate 110 through renewing or rekeying of the certificate 110. Examples of updating the certificate 110 are described in Figs. 9-11 .

[0062] The examples described herein provide for automatic and secure certificate lifecycle management operations in a trusted way based on the registered identities of the application 106 and agent 108. Messages and transactions may be digitally signed to keep a history and provide integrity to the certificate management process. For example, the blockchain service may provide transaction-based logging and accountability, where certificate operations from ordering to issuance may be stored in the blockchain ledger to provide a transparent history. The same blockchain service may also provide automatic identity verification to enhance accountability to the certificate management process. Furthermore, different revocation processes may be used depending on the conditions of the application 106.

[0063] Fig. 3 is a flow diagram illustrating a method 300 for performing certificate lifecycle management transactions, according to an example. In some examples, the method 300 may be performed by a blockchain service, such as the blockchain service 214 described in Fig. 2. In some examples, the blockchain service may include a blockchain ledger to record a certificate lifecycle management transaction, and a smart contract to automate the certificate lifecycle management transaction with an agent.

[0064] At 302, the blockchain service may register an agent of an application. For example, the blockchain service may register the agent and the application with one of: a public key exchange, a security phrase, and a onetime pad (OTP). In some examples, the blockchain service may register a hardware-stored security key (e.g., public key) that is unique to the electronic device of the agent or application in a blockchain ledger. The agent may identify itself to the blockchain service with the hardware-stored signature key.

[0065] At 304, the blockchain service may perform a certificate lifecycle management transaction with the agent of the application. In some examples, performing the certificate lifecycle management transaction may include issuing an initial certificate. For example, the blockchain service may receive a request for an initial certificate for the application from the agent. The blockchain service may validate the request based on the hardware-stored signature key. The blockchain service may send the certificate to the agent in response to validating the request. For example, the blockchain service may retrieve the issued certificate from the blockchain ledger. The blockchain service may record the initial certificate as a transaction in a blockchain ledger.

[0066] In some examples, performing the certificate lifecycle management transaction may include revoking a certificate. For example, the blockchain service may receive a command to revoke a certificate of the application. In some examples, the revocation command may be received from a certificate manager or the agent. The blockchain service may send a revoked certificate to the agent in response to the command to revoke the certificate. The blockchain service may record the revoked certificate as a transaction in a blockchain ledger.

[0067] In some examples, performing the certificate lifecycle management transaction may include updating a certificate. For example, the blockchain service may receive a command to update a certificate of the application. In some examples, the update command may be received from a certificate manager or the agent. The blockchain service may send an updated certificate to the agent in response to the command to update the certificate. The blockchain service may record the updated certificate as a transaction in a blockchain ledger.

[0068] Fig. 4 is a sequence diagram illustrating certificate issuance, according to an example. In this example, the application 406 determines, at 401 , that it lacks a certificate 410. At 403, the application 406 activates the agent 408 by sending a request for the certificate 410. At 405, the agent 408 requests a valid certificate 410 from the blockchain service 414. If the blockchain service 414 validates the agent 408, then the blockchain service 414 retrieves the certificate 410 from the blockchain ledger 418, and sends the certificate 410 to the agent 408. At 407, the agent 408 returns the requested certificate 410 to the application 406.

[0069] If, at 405, the agent 408 does not receive the requested certificate 410 (e.g., the certificate may not be issued), then the agent 408 may, at 409, send a notification to the certificate manager 412. At 411 , the certificate manager 412 may notify the system administrator 420 that the agent 408 is requesting a certificate for the application 406. At 413, the system administrator 420 may enter an issue certificate command at the certificate manager 412. At 415, the certificate manager 412 may send the issue certificate command to the blockchain service 414, which causes the blockchain service 414 to generate the certificate 410 and record the certificate 410 in the blockchain ledger 418. At 417, the blockchain service 414 may notify the agent 408 that the certificate 410 was issued. The agent 408 may then retrieve the certificate 410 from the blockchain service 414 as described at 405. [0070] Fig. 5 is a sequence diagram illustrating certificate issuance, according to an example. In this example, the agent 508 determines, at 501 , that the application 506 lacks a certificate 510. For example, the agent 508 may monitor the certificate status of the application 506. At 503, the agent 508 requests a valid certificate 510 from the blockchain service 514. If the blockchain service 514 validates the agent 508, then the blockchain service 514 retrieves the certificate 510 from the blockchain ledger 518, and sends the certificate 510 to the agent 508. At 505, the agent 508 returns the requested certificate 510 to the application 506.

[0071] If, at 503, the agent 508 does not receive the requested certificate 510 (e.g., the certificate has not been issued), then the agent 508 may, at 507, send a notification to the certificate manager 512. In some examples, the agent 508 sends a notification to the certificate manager 512 directly or through the blockchain service 514. At 509, the certificate manager 512 sends an issue certificate command to the blockchain service 514, which causes the blockchain service 514 to generate the certificate 510 and to record the certificate 510 in the blockchain ledger 518. At 511 , the blockchain service 514 notifies the agent 508 that the certificate 510 was issued. The agent 508 may then retrieve the certificate 510 from the blockchain service 514 as described at 503.

[0072] Fig. 6 is a sequence diagram illustrating certificate revocation, according to an example. In this example, the administrator 620, at 601 , sends a request to the certificate manager 612 that a first certificate 610a for an application 606 be revoked. At 603, the certificate manager 612 sends a revoke certificate command to the blockchain service 614.

[0073] At 605, the blockchain service 614 records the revocation of the first certificate 610a and generates a revoked certificate 610b in the blockchain ledger 618. The blockchain service 614 then notifies the agent 608 that the first certificate 610a has been revoked.

[0074] At 607, the agent 608 requests the revoked certificate 610b from the blockchain service 614. If the blockchain service 614 validates the agent 608, then the blockchain service 614 retrieves the revoked certificate 610b from the blockchain ledger 618, and sends the revoked certificate 61 Ob to the agent 608. At 609, the agent 608 sends the revoked certificate 61 Ob to the application 606. [0075] In some examples, at 607, instead of requesting revoked certificate 610b from the blockchain service 614, the agent 608 may send a command to the application 606 causing the application 606 to revoke its current certificate. In some examples, at 609, the agent 608 may delete the first certificate 610a from memory to prevent the application 606 from using the first certificate 610a. In some examples, the certificate manager 612 may report, at 611 , the results of the certificate revocation to the administrator 620.

[0076] Fig. 7 is a sequence diagram illustrating certificate revocation, according to an example. In this example, the application 706 determines, at 701 , that a first certificate 710a is unsafe. At 703, the application 706 activates the agent 708 by sending a notification of the unsafe first certificate 710a. At 705, the agent 708 notifies the certificate manager 712 about the unsafe first certificate 710a.

[0077] At 707, the certificate manager 712 sends a revoke certificate command to the blockchain service 714. At 709, the blockchain service 714 records the revocation of the first certificate 710a and generates a revoked certificate 710b in the blockchain ledger 718. The blockchain service 714 then notifies the agent 708 that the first certificate 710a has been revoked.

[0078] At 711 , the agent 708 requests the revoked certificate 71 Ob from the blockchain service 714. At 713, the agent 708 sends the revoked certificate 710b to the application 706. In some examples, at 707, instead of requesting revoked certificate 710b from the blockchain service 714, the agent 708 may send a command to the application 706 causing the application 706 to revoke its current certificate.

[0079] Fig. 8 is a sequence diagram illustrating certificate revocation, according to an example. In this example, the agent 808 determines, at 801 , that a first certificate 810a is unsafe. For example, the agent 808 may monitor the application 806 to determine the state of the first certificate 810a. At 803, agent 808 notifies the certificate manager 812 about the unsafe first certificate 810a. [0080] At 805, the certificate manager 812 sends a revoke certificate command to the blockchain service 814. At 807, the blockchain service 814 records the revocation of the first certificate 810a and generates a revoked certificate 810b in the blockchain ledger 818. The blockchain service 814 then notifies the agent 808 that the first certificate 810a has been revoked.

[0081] At 809, the agent 808 requests the revoked certificate 810b from the blockchain service 814. At 811 , the agent 808 sends the revoked certificate 810b to the application 806. In some examples, at 809, instead of requesting revoked certificate 810b from the blockchain service 814, the agent 808 may send a command to the application 806 causing the application 806 to revoke its current certificate.

[0082] Fig. 9 is a sequence diagram illustrating a certificate update, according to an example. In this example, the administrator 920, at 901 , sends a request to the certificate manager 912 to update a first certificate 910a for an application 906. For example, the first certificate 910a may be outdated or unsafe. At 903, the certificate manager 912 sends an update certificate command to the blockchain service 914.

[0083] At 905, the blockchain service 914 records the update of the first certificate 910a and generates an updated certificate 910b in the blockchain ledger 918. The blockchain service 914 then notifies the agent 908 that the first certificate 910a has been updated. The updating may include renewing or rekeying the first certificate 910a to produce the updated certificate 910b.

[0084] At 907, the agent 908 requests the updated certificate 910b from the blockchain service 914. If the blockchain service 914 validates the agent 908, then the blockchain service 914 retrieves the updated certificate 910b from the blockchain ledger 918, and sends the updated certificate 910b to the agent 908. At 909, the agent 908 sends the updated certificate 910b to the application 906. In some examples, the certificate manager 912 may report, at 911 , the results of the certificate update to the administrator 920.

[0085] Fig. 10 is a sequence diagram illustrating a certificate update, according to an example. In this example, the application 1006 determines, at 1001 , that a first certificate 1010a is unsafe or outdated. At 1003, the application 1006 activates the agent 1008 by sending a notification of the unsafe/outdated first certificate 1010a. At 1005, the agent 1008 notifies the certificate manager 1012 about the unsafe/outdated first certificate 1010a.

[0086] At 1007, the certificate manager 1012 sends an update certificate command to the blockchain service 1014. At 1009, the blockchain service 1014 records the update of the first certificate 1010a and generates an updated certificate 1010b in the blockchain ledger 1018. The blockchain service 1014 then notifies the agent 1008 that the first certificate 1010a has been updated.

[0087] At 1011 , the agent 1008 requests the updated certificate 1010b from the blockchain service 1014. At 1013, the agent 1008 sends the updated certificate 1010b to the application 1006.

[0088] Fig. 11 is a sequence diagram illustrating a certificate update, according to an example. In this example, the agent 1108 determines, at 1101 , that a first certificate 1110a is unsafe or outdated. For example, the agent 1108 may monitor the application 1106 to determine the state of the first certificate 1110a. At 1103, agent 1108 notifies the certificate manager 1112 about the unsafe/outdated first certificate 1110a.

[0089] At 1105, the certificate manager 1112 sends an update certificate command to the blockchain service 1114. At 1107, the blockchain service 1114 records the update of the first certificate 1110a and generates an updated certificate 1110b in the blockchain ledger 1118. The blockchain service 1114 then notifies the agent 1108 that the first certificate 1110a has been updated.

[0090] At 1109, the agent 1108 requests the updated certificate 1110b from the blockchain service 1114. At 1111 , the agent 1108 sends the updated certificate 1110b to the application 1106.

[0091] Fig. 12 depicts a non-transitory machine-readable storage medium 1230 for certificate lifecycle management, according to an example. To achieve its desired functionality, an electronic device 102 includes various hardware components. Specifically, an electronic device 102 includes a processor and a machine-readable storage medium 1230. The machine-readable storage medium 1230 is communicatively coupled to the processor. The machine- readable storage medium 1230 includes a number of instructions 1232, 1234, 1236 for performing a designated function. The machine-readable storage medium 1230 causes the processor to execute the designated function of the instructions 1232, 1234, 1236. The machine-readable storage medium 1230 can store data, programs, instructions, or any other machine-readable data that can be utilized to operate the electronic device 102. Machine-readable storage medium 1230 can store computer readable instructions that the processor of the electronic device 102 can process, or execute. The machine-readable storage medium 1230 can be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Machine-readable storage medium 1230 may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc. The machine-readable storage medium 1230 may be a non-transitory machine-readable storage medium 1230, where the term “non-transitory” does not encompass transitory propagating signals. [0092] Referring to Fig. 12, run application instructions 1232, when executed by the processor, cause the processor to run an application that uses a certificate. Certificate request instructions 1234, when executed by the processor, may cause the processor to send a request to a certificate manager to issue the certificate for the application with a blockchain service. Issued certificate instructions 1236, when executed by the processor, may cause the processor to receive the issued certificate from the blockchain service.

[0093] In some examples, the instructions, when executed by the processor, cause the processor to send a first notification to a certificate manager to issue the certificate. The certificate manager may send an issue certificate command to the blockchain service to issue the certificate. The processor may receive a second notification from the blockchain service that the certificate has issued. The processor may request the issued certificate from the blockchain service in response to receiving the second notification from the blockchain service. The processor may provide the issued certificate to the application in response to receiving the issued certificate from the blockchain service.

[0094] In some examples, the instructions, when executed by the processor, cause the processor to determine that the issued certificate is unsafe. The processor may send a request for a revoked certificate to the blockchain service. The processor may receive the revoked certificate from the blockchain service based on the request. In some examples, the processor may send a notification to the certificate manager that the issued certificate is unsafe. The certificate manager may then send a revoke certificate command to the blockchain service to generate the revoked certificate.

Claims

CLAIMS What is claimed is:

1 . An electronic device, comprising: a processor to: run an application that uses a certificate; and run an agent to: request the certificate for the application from a blockchain service; and perform a certificate lifecycle management transaction for the application based on the certificate received from the blockchain service.

2. The electronic device of claim 1 , wherein the application is registered with a blockchain service with one of: a public key exchange, a security phrase, and a one-time pad (OTP).

3. The electronic device of claim 1 , wherein the agent is to identify itself to the blockchain service with hardware-stored signature keys unique to the electronic device.

4. The electronic device of claim 1 , wherein the certificate lifecycle management by the agent comprises one of: receiving an initial certificate from the blockchain service, receiving a revoked certificate from the blockchain service, and receiving an updated certificate from the blockchain service.

5. The electronic device of claim 1 , wherein the application is to send a request for a certificate to the agent, and wherein the agent is to send the request for the certificate to the blockchain service.

22

6. The electronic device of claim 1 , wherein the agent is to send a request for a certificate to the blockchain service in response to determining that the application lacks a valid certificate.

7. A method, comprising: registering an agent of an application at a blockchain service; and performing, by the blockchain service, a certificate lifecycle management transaction with the agent of the application.

8. The method of claim 7, wherein the blockchain service comprises a blockchain ledger to record the certificate lifecycle management transaction, and a smart contract to automate the certificate lifecycle management transaction with the agent.

9. The method of claim 7, wherein performing the certificate lifecycle management transaction comprises: receiving, at the blockchain service, a request for an initial certificate for the application; validating the request based on a hardware-stored signature key; sending the certificate to the agent in response to validating the request; and recording the initial certificate as a transaction in a blockchain ledger.

10. The method of claim 7, wherein performing the certificate lifecycle management transaction comprises: receiving, at the blockchain service, a command to revoke a certificate of the application; sending a revoked certificate to the agent in response to the command to revoke the certificate; and recording the revoked certificate as a transaction in a blockchain ledger.

11 . The method of claim 7, wherein performing the certificate lifecycle management transaction comprises: receiving, at the blockchain service, a command to update a certificate of the application; sending an updated certificate to the agent in response to the command to update the certificate; and recording the updated certificate as a transaction in a blockchain ledger.

12. A non-transitory machine-readable storage medium comprising instructions, when executed by a processor of an electronic device, cause the processor to: run an application that uses a certificate; send a request to a certificate manager to issue the certificate for the application with a blockchain service; and receive the issued certificate from the blockchain service.

13. The non-transitory machine-readable storage medium of claim 12, wherein the instructions, when executed by the processor, cause the processor to: send a first notification to a certificate manager to issue the certificate, wherein the certificate manager is to send an issue certificate command to the blockchain service to issue the certificate; receive a second notification from the blockchain service that the certificate has issued; request the issued certificate from the blockchain service in response to receiving the second notification from the blockchain service; and provide the issued certificate to the application in response to receiving the issued certificate from the blockchain service.

14. The non-transitory machine-readable storage medium of claim 12, wherein the instructions, when executed by the processor, cause the processor to: determine that the issued certificate is unsafe; send a request for a revoked certificate to the blockchain service; receive the revoked certificate from the blockchain service based on the request; and provide the revoked certificate to the application in response to receiving the revoked certificate from the blockchain service.

15. The non-transitory machine-readable storage medium of claim 14, wherein the instructions, when executed by the processor, cause the processor to: send a notification to a certificate manager that the issued certificate is unsafe, wherein the certificate manager is to send a revoke certificate command to the blockchain service to generate the revoked certificate.

25