Background
Introduction and abstract
Rec. ITU-T X.509 | ISO/IEC 9594-8 (ITU-T X.509) provides the framework for the public-key infrastructure (PKI). ITU-T X509 is one of the more important cybersecurity standards being widely used for securing online banking, e-health, e-government, and lately also used for securing other areas such as the power industry and Internet of Things (IoT). It has served well within countries where trust can be established by a so-called trust anchor trusted by everybody in the PKI domain.
This page describes a proposal for a new public-key infrastructure (PKI) where certification authorities (CAs) and attribute authorities (AAs) are interconnected through a blockchain network to form a decentralized public-key infrastructure (DPKI). By connecting to a blockchain node in the DPKI, a CA may forward public-key certificate information, and an AA may forward attribute certificate information together with status information into the ledger. The certificates (public-key and attribute certificates) are thoroughly validated by the local node and if successfully validated the node forms transactions to be validated by other nodes through a consensus process. Transactions are then formed into blocks to be added to the blockchain and reflected in a DPKI directory also part of the ledger. Data stored in the ledger can be considered genuine, eliminating the need for providing revocation information in other ways. The certificate information in the DPKI directory may be accessed at every node by entities requiring that information.
Relationship with NIS 2
There is very little relationship, but there is one point where NIS 2 is specific as seen here.
Relationship with EU Cyber Resilience Act (CRA)
The DPKI is relevant in a Cyber Resilience Act (CRA) context especially for stadardization requests 6, 7, 16 and especially for request 24.
Relationship with EU Rolling Plann for ICT standardization
How DPKI relates to EU Rolling Plan for ICT standardization on blockchain may be found here.
The concept of trust
Authentication
Figure 1 shows a simple example of the use of PKI as a very gently introduction. Alice sends a digit signed message to Bob. Alice has a public-key certificate. The private key associated with that public-key certificate is used to sign the message. For Bob to verify the signature he needs the corresponding public key. Alice therefore attaches to the message her public-key certificate that holds the public-key. Bob received the public-key certificate and wonder whether he can trust the information in that public-key certificate as he is relying on that information and therefore is called the relying party. Bob wants to be sure that the message was sent by Alice by assuring that the received public-key certificate is owned by Alice. Alice’s public-key certificates is issued by a certification authority (CA) that certify by its digital signature that the public-key in the public-key certificate is owned by Alice. To prove that Alice also includes the CA certificate of the issuing CA.
Single PKI domain
It is here trust comes into the picture. PKI depends on the existence of an entity that is trusted by users in in a specific area It could be a government institution. If the trust anchor has signed the CA certificate, we have established a certification path.’
Figure 2 show a simple picture of PKI domain reflecting the same situation as in Figure 1 but illustrates the chain of public-key certificates that make up a certification path. It is also seen that the situation is quite simple when the certificate owner and the relying party is within the same domain.
The certificate owner is also called the subject, as the identity of the owner is specified in the subject component of the public-key certificate.
When Bob answers Alice the roles are switched. Bob becomes the subject and Alice the relying party. The certificatio path is also chnaged.
Commnication between domains
Worldwide federated PKI
Figure 4 illustrates the case where PKI domains all over the world are interconnected to form a worldwide federated PKI. It is obvious that this results in long chains of trust which dilute the trust or is dependent on that certain trust anchors are trusted over the most of the world which in divided world is infeasible. The issue on a long chain of trust is illustrated next.
Diluted chain of trust
Figure 5 illustrates a long chain of trust, where A trusts B, B trusts C, C trusts D, —- and I trusts J. Does A the trust J? A chain of trust becomes diluted the longer it is. Establishing a worldwide federated PKI seems impossible.
Justification for a Decentralized Public-Key Infrastructure (DPKI) standard
However, it has proved difficult or impossible to establish a global trust based on trust anchors for a wider area with several interconnected PKI domains. There is an increasing need for having such a worldwide set of interconnected PKI domains providing global trust. The solution seems to establish trust achieved by consensus rather than relying on local trust anchors that are not trusted in a wider context. Having global trust by consensus implies the use of blockchain technology for interconnecting PKI domains. This is the approach taken by the project subject for this article. The result is a specification for a decentralized PKI (DPKI).
General decentralization concepts
Sample blockchain network
Figure 6 shows an (small) example of a blockchain network where nodes are interconnected either directly or through relaying nodes.
Communication among nodes mostly happens through broadcasting. When A CA submits a public-key certificate or an AA submits an attribute certificate to a node, the resulting transaction is then broadcast by the node to all its neighboring nodes, also called peer nodes or just peers. When a peer receives the transaction, it shall further broadcast it, and so on. The protocol behind this type of broadcast is called the consensus protocol. A resilient consensus protocol is only useful when it continues to deliver the intended service under a wide range of adversarial influence on the nodes and the network. Detailed analysis and formal argumentation are necessary to gain confidence that the consensus protocol achieves its goal by preventing, deterring, withstanding or tolerate any influence that could hinder the consensus protocol from accomplishing its task.
Besides a single CA, zero or more AAs may add PKI related information to a node on the blockchain. Zero or more relying parties (RPs) may have read access to a node but are not able to affect the content of the ledger.
Synchronous vs. asynchronous processing
Whether processes interact synchronously or asynchronously characterizes a decentralized system, The difference between the two types of processing is illustrate in Figure 7 by comparing a synchronous and an asynchronous process.
The two processes can be in the same system using either multi-threading or using multi-processing. The two processes can also be in different systems.
The term synchronous has a little different meaning in plain English and within the context of ICT. In plain English it means “happening at exactly at the same time, while in ICT it means that some tasks rare executed within specified time limit and the result is only useful when all tasks have completed.
In the synchronous case process A makes a call to process B and waits for the result of that call before continue processing.
In the asynchronous case process A also issues a call to the process B not waiting for the result, but continuous to process on issues not dependent on the result of the call at the same time listing for the result. When the result is ready, process A is interrupt and may now process the result in the same way as for the synchronous case. Having processed the response, the asynchronous case is in the same state as the synchronous case with respect to handling the response from process B.
The FLP (Fischer-Lynch-Paterson) impossibility theorem states that no deterministic protocol can receive consensus in the asynchronous model, with just a single faulty node even if this node has suffered a crash fault.
No deterministic consensus protocol can guarantee all three of safety, liveness, fault tolerance in an asynchronous system.
A deterministic protocol has no element of randomness and given a particular input it always produces the same output.
A blockchain as shown in Figure 1 is inherently asynchronous system but may be what is called an eventual synchronous network. In such a network messages among well-behaved nodes may be delayed arbitrarily but will eventually be delivered to well-behaved nodes.
Design considerations
Introduction
As it is well known, a decentralized ledger consists of a blockchain, where blocks of transactions are chained together. In the case of DPKI, it also includes a database or directory function. This is like the Hyperledger-fabric platform used in the commercial area. Every node in a blockchain holds a replica of the ledger. Figure 6 depicts the node structure.
The control center is shown as a central entity and is composed of several logical modules each described separately but interacting with each other. Inside the node is also a replica of the DPKI directory and a replica of the transaction blockchain. The implementation may not exactly follow the module structure.
The figure also shows that a CA is outside the network. It is closely related to the node to which it is attached, and the node takes the identity of the CA. AAs are also outside the node to which they are attached. The CAs and the AAs do not need to be changed except for providing an interface to the node and to be able to communicate over that interface. The CAs and AAs can continue their traditional local roles in addition to their roles on the blockchain. A CA or an AA may choose not to submit all its certificates into the blockchain. Only certificates having global interest should be inserted in the ledger. Certificates only having local significance should not be inserted in the blockchain.
Figure 6 also shows that users of certificate information, also called relying parties, may access or be informed about the status of certificates.
General approach
As DPKI is intended to be an international standard, it cannot be based on an existing blockchain platform, as current blockchain platforms are outside the jurisdiction of any standard development organization. DPKI therefore includes a complete specification for a standardized blockchain platform. This is a major undertaken. Data types, protocols and similar specifications are expressed using the abstract syntax notation one (ASN.1) because of its versability and support of compact encoding.
DPKI will be a permissioned blockchain. Only well-behaved CAs should be allowed to join the network. CAs need approval of their national authorities to participate. However, DPKI must be able cope with the situation where a well-behaved CA or AA turns into a misbehaved CA or AA. There could be several reasons for such a change, e.g., a CA or AA may be taken over by an adversary.
Attribute authorities (AAs) and attribute certificates are in line with CAs and public-key certificates part of DPKI. This is different from the current ITU-T X.509, where AAs and attribute certificates form their own infrastructure (privilege management infrastructure or PMI). Having included AAs and attribute certificates, DPKI enables support for access control. It is planned to change ITU-T X.509 to include AAs and attribute certificates in a traditional PKI.
Zero or more AAs may attach to a blockchain node in addition to the CA associated with the node and may submit attribute certificates into the blockchain through the node.
A node will validate public-key certificate information transmitted from a CA over the CA-node interface. If the validation fails, a diagnostic code is returned, and the information is discarded. The same happens for attribute certificate information issued by an AA. Together with a certificate a CA or AA also supplies status information about the certificate. Only new certificates having a status of normal will be accepted but may later be changed to have status of been revoked with an indication of the revocation reason.
The validation is intended to be very thorough to ensure that only genuine information is placed in the blockchain and in the DPKI directory. A relying party should in this way be able to make sound decisions based on the information retrieved from the DPKI directory.
Validated certificate information is then by the transaction generation module transformed to transactions to be validated on the blockchain using the consensus protocol.
Module handling within the control centre
Use and migration of cryptographic algorithms
Operation and cybersecurity of a blockchain are dependent on robust cryptographic algorithms including algorithms for digital signature, hash pointers for block chaining, key establishment, and integrity. DPKI, in contrast to other blockchain platforms, does not specify specific algorithms to be used. That will be specified at the establishment of a DPKI. The control centre of each of the nodes holds a configural configuration file holding the currently used cryptographic algorithms eliminating the need for signalling the algorithms in the protocols.
Migration of cryptographic algorithms needs to be prepared either because of detected weakness in currently used algorithms or the entrance of quantum computers able to break used algorithms. DPKI has built-in migration capabilities allowing for a smooth migration during an agreed migration period. The configuration file can hold alternative cryptographic algorithms during a migration period.
Handling of certificates and transaction generation
When a CA insert public-key certificate information, or an AA insert attribute certificate information into a node, the CA handling module or the AA handling module quite thoroughly validates the information for accuracy and consistency. If the validation fails, the certificate information is discarded and error information is returned to the submitting CA or AA. If the information is validated positively, the information is passed to the transaction generation module.
The type of information inserted by a CA, or an AA may be a new certificate together with status information, updated certificate status information, replacement of a certificate, and deletion of a certificate.
After successful validation, the certificate and status information are by the transaction generation module transformed into transactions to be transmitted to neighbouring nodes for validation by consensus.
Peer-to-peer protocol
In a blockchain network the nodes are interconnected having peer-to-peer connections. Most likely, a large global network will not be fully interconnected, i.e., a node may not be directly connected to any other node. Some nodes will act as relay nodes for other nodes. The connections are independent of each other with respect to how the protocol is initiated and operating. A peer-to-peer protocol is protected by digital signature during establishment and symmetric keys are created for protection of the connection during the data phase.
Schedular
The schedular receives transactions from other nodes and routes transactions to other nodes. The data received from other nodes may be transactions to be validated by the transaction validation function, it may be completed blocks to be added to the blockchain and reflected in the DPKI directory, or it may be management information for update of the configuration file. Validated transactions received from by the validation functions may transmitted to one or more neighbouring nodes.
Transaction validation
A node will receive transactions from other nodes holding certificate information. Such transactions are validated in the same way as local certificate information is validated except that no diagnostic code is generated, but just a valid or invalid outcome.
Directory Access
The DPKI directory module has several responsibilities. Based on completed and validated transactions it will update the DPKI directory to reflect the changes resulting from the transaction. It is accessed by other modules as to the status which affects the handling of transactions, and it may provide information services to outside users needed information about certificates and their status.
Relying party handling
ITU-T X.509 uses the term relying party for entities that needs to check whether it can rely on the information in reived certificate(s) together with some data from a communication partner. In a traditional PKI, checking is partly done by accessing either so-called certificate revocation lists or using the online certificate status protocol (OCSP). DPKI will provide certificate status information about any certificate all the area covered by DPKI. In addition to retrieving certificate status information from the DPKI, it is also possible to establish a subscription service where relying parties can be informed when status is changed for selected certificates.
Support of access control
DPKI can give some general support for any type of access control and any type of usage. It becomes more relevant when global support for access control is required, Access control makes use of attribute certificates to hold privileges that can be verified as being part of a PKI that brings confidence in the information provided in the attribute certificates. Attribute certificates stored in a DPKI can be accessed anywhere within the area covered by the DPKI. In some cases that could be worldwide.
Final comments
The development of the DPKI standards is on its way but there is substantial work still to be done.