Abstract
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 into the ledger. The certificates (public-key and attribute certificates) are thoroughly validated by the local node and if successful form 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 any other way. The certificate information in the DPKI directory may be accessed at every node by entities requiring that information.
Justification for a Decentralized Public-Key Infrastructure (DPKI) standard
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. 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 proposal subject for this article. The result is a specification for a decentralized PKI (DPKI).
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 1 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 1 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 the substantial work still to be done.