One Article to Fully Understand the Ultrain Blockchain Certificate Management System
Cryptography technology is the cornerstone of information technology. Blockchain uses a lot of technological achievements of modern information security and cryptography, mainly including: hash algorithm, symmetric encryption, asymmetric encryption, digital signature, digital certificate and so on. The hash algorithm solves the problem of information integrity verification, the symmetric algorithm improves the efficiency of encryption operations, the asymmetric algorithm solves the problem of symmetric key transfer, and the digital certificate is endorsed by the public key owner, which solves the problem of the public key holder’s proof , PKI / CA system has formed a complete solution to solve information security, information confidentiality, integrity and non-repudiation.
The current mainstream blockchain technology in China is called an open license chain. What is a license chain? It is the owner of all the nodes that make up the license chain. Their identities are authenticated, and they can only join the blockchain network after being authorized by the license.
In this scenario, the network is open to authorized organizations or institutions, and there is a collaborative relationship between the participants on the chain, with an access mechanism. As a complete solution, the PKI / CA system can provide identity authentication certificates for each participant in the license chain to realize access control. It can be said that the certificate mechanism is the cornerstone of the permission chain network security. After the necessary description of the basic concepts of PKI / CA, this article elaborated the Ultrain certificate management system in detail.
01 Public key infrastructure
Public Key Infrastructure (PKI) is a collection of hardware, software, and policies, which is used to complete the generation, management, storage, distribution, and revocation of keys and certificates based on public key cryptosystem system.
1.1 PKI system
The PKI system includes a certificate authority CA (Certificate Of Authority, certification center), a registration authority RA and a corresponding PKI repository. CA is used to issue and manage certificates; RA can be used as a part of CA, or it can be independent. Its functions include personal identity verification, CRL management, key generation, and key pair backup. The PKI repository includes LDAP (Lightweight Directory Access Protocol, LDAP). Lightweight Directory Access Protocol) directory server and common database, used to store and manage user applications, certificates, keys, CRL (Certificate revocation lists) and logs, and provide certain query functions.
1.2 Certificate application process
• User application:
The user generates his own public key and private key, submits the public key and his own identity information to the security server, and the security server transmits the user’s application information to the RA server.
• RA audit:
The user proves his identity to the RA, and the RA checks after receiving the user’s application. If the RA agrees with the user’s request for a certificate, digitally sign the certificate application information; otherwise, the user’s application is rejected.
• CA issued certificate:
The RA transmits the user application and the RA signature to the CA. The CA authenticates the RA digital signature. If the verification is passed, the CA agrees to the user request, issues a certificate, and then outputs the certificate. If the verification fails, the certificate application is rejected.
• RA forwarding certificate:
The RA obtains a new certificate from the CA, first outputs the certificate to the LDAP server to provide directory browsing, then notifies the user of the successful issuance of the certificate, informs the certificate of the serial number, and downloads the certificate to the specified website.
• User certificate acquisition:
The user uses the certificate serial number to specify the website to download his digital certificate.
1.3 X.509 certificate format
The mainstream certificate format is X.509 format. The X.509 standard stipulates what information a certificate can contain and explains how to record the information.
X.509 structure includes Version Number, Serial Number, Signature Algorithm, Issuer, Validity, Subject, Subject Public Key Information (Subject Public) Key Info), subject public key algorithm (Public Key Algorithm), subject public key (Subject Public Key), certificate signature algorithm (Certificate Signature Algorithm) and certificate signature (Certificate Signature).
1.4 Certificate verification principle
1. Use the same hash function for the plain text in the certificate to get the digest value H1.
2. Use the CA root certificate to verify the signature validity of the client certificate, that is, the signature in the certificate is de-signed with the public key of the CA root certificate, and the de-signed result is compared with H1 in step 1. If they are consistent, the certificate is trusted The root certificate is issued, and the contents of the certificate have not been tampered with.
3. Check whether the client certificate is valid (the current time is within the validity period defined in the certificate structure).
4. Check whether the client certificate is invalid (OCSP method or CRL method).
5. Verify the purpose of the certificate in the client certificate structure.
All the above information is verified, then the public key information of the client in the certificate can be used in subsequent operations.
02 Ultrain Certificate Management System
The authorized nodes of the permission chain form an alliance to share and access data. The PKI system is a complete and mature system for user auditing, identity management and privacy protection. Ultrain defines a set of top-down certificate management processes to achieve permission management and access control of license chain nodes.
2.1 Ultrain certificate system
Ultrain uses a CA-oriented access mechanism to implement authentication and dynamic management based on X.509 format certificates. According to the existing business scenario, the certificate system is shown in Figure 2, and includes the following types from top to bottom: root certificate, chain certificate, node certificate, and user certificate.
Root certificate: The root certificate is a self-signed certificate, which is the root of all certificates, and the corresponding private key file is jointly managed by the alliance committee.
Chain certificate: In a multi-chain architecture, a single chain management agency generates a chain private key and generates a request file chain.csr to send to the alliance committee. After the alliance committee passes the review, the chain certificate chain.crt is issued.
Node certificate: The node certificate is issued by a chain certificate. The node generates and saves its own private key file node.key, and generates a request file node.csr and sends it to the chain management agency. After the chain management agency passes the verification, it issues a node certificate node.crt. The node certificate is the identity certificate of the node. The node with the node certificate can establish an SSL link with the node in the blockchain network to achieve encrypted communication between the nodes.
User certificate: The user certificate is issued by the node that provides the chain access interface. The user generates and saves his own private key file sdk.key, and generates a request file sdk.csr and sends it to the node management organization that needs to be accessed. After the node management organization passes the verification, the user certificate sdk.crt is issued. The user certificate is the client’s identity credential, and the client with the user certificate can access the link port normally.
Ultrain provides a set of certificate application issuance management procedures to facilitate the application, verification and issuance of certificates at all levels.
2.2 Certificate usage scenarios and verification
The root certificate is jointly managed by the Ultrain Alliance Committee. At present, it uses a self-signed certificate. It can also be connected to a commercial certificate issuing agency and use a certificate issued by an authority. When the business needs to establish a new side chain, the side chain management agency submits the certificate request file, and the alliance committee uses the root certificate to issue the chain certificate after the alliance committee passes the review; the chain certificate is managed by the chain management committee, and the chain management committee receives the alliance member to become the operation The node certificate request file is issued by the committee after the committee passes the review; the alliance members use the node certificate to access the side chain node network before they can send and receive consensus and transaction information normally. If the node provides an on-chain data access interface, a user certificate needs to be issued to the client for use; the client uses the user certificate issued by a specific node to access the data interface provided by the node for data reading, transaction sending, etc. operating.
Node certificate verification
Node certificates are used when building chains between nodes. After the link based on certificate verification is established, the node can form a P2P network, so as to achieve the spread of consensus protocol information and transaction information. The following figure shows the process of using the node certificate.
When a node is started, carrying its own node certificate can establish an SSL secure link with a node that also has the node certificate. When the certificate expires and is tampered with, it cannot be added to the P2P network, so the data on the chain cannot be shared and propagated.
In Ultrain’s certificate revocation (CRL) management system, the revocation of the certificate is completed by the certificate issuing authority. Nodes can periodically obtain the CRL list from the CA Management Center. Heartbeat messages between nodes need to carry their own node certificates. When the node certificate is not carried or the carried certificate is in the CRL list, the heartbeat message detection end will actively tear down the link with the detected end to achieve real-time access management control .
User certificate verification
When the client accesses the link port provided by the node, it can choose to verify the node certificate to verify the identity of the node. In this case, a certificate chain composed of a root certificate and a chain certificate needs to be used to verify the node certificate. In addition, the client needs to provide the user certificate to the node. The node’s HTTPS service will verify the user certificate provided by the client (using the root certificate, chain certificate and node certificate to form the certificate chain for verification), and will also check the CRL revocation list , When the verification is passed and the user certificate is not in the CRL list, the SSL link is successfully established for normal communication, otherwise the link cannot be established, thereby ensuring the security of communication between the client and the node.
