PKI domain certificate management mechanism based on blockchain technology

ISE trust domain structure model ISE-CBCM based on alliance chain

The blockchain is a database structure that is jointly maintained by all distributed nodes to ensure that the data is transparent and cannot be tampered with. Based on the advantages of the blockchain structure, the ISE trust domain structure model is designed, and the ISE trust domain structure model ISE-CBCM of the alliance chain is obtained. . Set the central trust CA of each trust domain as distributed nodes in the blockchain, such as trust CA, root CA and bridge CA in single trust nodes. These nodes have relatively high credibility and have transactions and accounting For all functions such as, query, other servers as auxiliary nodes can only query data through a predetermined interface.

advantage:

Reduce the burden of certificate management and maintenance, the size of the certificate and the use process are more lightweight, the specific certificate management mechanism will be detailed later;
Reduce the cost of maintaining the trustworthiness of trusted nodes: In the original trust domain structure, the trustworthiness of the CA is mainly maintained by security components, security policies, cryptographic security, etc., which require more maintenance costs. Blockchain is a decentralized database structure with extremely high security. It has zero tolerance for data tampering and data fraud. The ISE-CBCM model is based on the alliance chain design. All nodes trust and supervise each other regularly. Verify identity, reduce human and material costs, and realize full-node supervision;
Improve the complexity of cross-domain interaction and realize cross-domain communication activities between different structural domain models: Under the ISE-CBCM model, in the information service trust domains of various structures, the trusted CAs exist in the form of alliances, which can be reasonably Control the scale and growth rate of different domain structures within the scope. All CAs in the ISE-CBCM model store the same parameters in the model. By designing a blockchain certificate mechanism, it can be used to safely and efficiently achieve cross-domain authentication between different structures. The following sections will make more detailed studies.

Structure design of blockchain certificate based on ISE-CBCM

X.509v3 version of public key certificate and blockchain certificate structure

Blockchain certificate compared to X.509 certificate:

The issuer and subject unique identifiers are omitted. The issuer unique identifier and subject unique identifier are optional in the X.509v3 version to ensure that the CA issuing the certificate and the subject receiving the certificate have unique distinguished names. The number of ISEs in the information service trust domain is relatively limited, which can be uniquely identified by the issuer name and subject name, so these two parts are omitted. In the information service trust domain, there are a large number of users, so the subject alternative name in the extension item is reserved to distinguish a large number of user groups and ensure its unique identification.
All contents related to the signature are discarded, and there is no need to store the signature result of its contents in the certificate after the certificate contents are generated. The name algorithm identifier and related parameters are not necessary in the blockchain certificate, and there is no need for the issuer to sign the certificate after the certificate is generated, so these two parts are deleted. In a digital certificate, the issuer needs to use its own private key to sign the rest to ensure that the certificate is not tampered with; when verifying the validity of the certificate, the verifier needs to query the issuer’s public key based on the signature identifier and The parameters verify the correctness of the signature through calculations, thereby verifying the integrity of the certificate. In the blockchain certificate, the certificate is stored in the block body, and the data can be guaranteed not to be tampered with. Any change to the certificate will cause the failure of the certificate query and realize the natural guarantee of integrity, so this part of the content is deleted.
The start date and end date of the validity period are changed to a longer validity period. The blockchain time stamp technology will indicate the formation time of each data block. Whenever a new data block is packaged and connected to the blockchain, the time stamp of when the block was formed will be recorded in the block header. In order to reduce the size of the certificate, the timestamp can be used as the starting time in the validity period. When querying the validity period, by calculating the time difference with the timestamp, you can compare whether the certificate is in the effective service period.
In the extension part, the basic constraints and name constraints are omitted, and the CRL distribution points are also added to the information service level and type to adapt to the scenario of the information service trust domain. All contents in the extension items are optional. First, the CRL distribution points are deleted. In the use of PKI certificates, the certificate issuance status is the most important and the most difficult. Currently, CRL and OCSP are the most used. Stored on the blockchain, real-time query and return status can be realized by setting the block link port, and no additional certificate revocation list is required. The basic constraints and name constraints are to prevent the scope of trust from being infinitely enlarged to an unmanageable scale. Because the number of information service trust domains is controllable and the structure is relatively simple, vertical growth can be controlled under the blockchain model, so this part is deleted Options. In addition, since the information service entity has additional information such as security level classification and service type indication, in order to facilitate the further management of ISE, this option is added to the expansion item. The blockchain certificate structure is as follows:

The life cycle of a blockchain certificate

Blockchain certificate registration, verification, and issuance

Registration: Entity E will send information that can prove its identity, such as IP address, real name, ID, Email and other personally identifiable information to RA. If entity E is an information service provider (ISE), it needs to provide additional service provider name , ID, relevant information of the person in charge, the type of information service provided, the group providing the service and other relevant information are provided to RA. RA generates a public and private key for it according to the provided information, and the registration is successful.
Verification: After the registration is completed, RA needs to interact with entity E to verify the authenticity of the materials it provides.
Issuance: After the above verification is passed, the RA will provide the above-mentioned materials to the CA, and the CA will generate a blockchain certificate Cert after verifying some necessary information. The CA first issues the certificate to the user, and then uses the selected hash function in the ISE-CBCM model to hash the blockchain certificate to obtain Hash(Cert), store it in the block body and set the certificate status interface to () put issue, Hash(Cert).

Blockchain certificate identity authentication

And digital certificate (digital certificate is also called electronic certificate, or certificate for short. In many occasions, digital certificate, electronic certificate and certificate are synonymous with X.509 public key certificate, which conforms to ITU-T X.509 V3 standard.) The operations such as downloading the revocation catalog in advance are different. In the process of using the blockchain certificate, in addition to verifying the signature, the validity of the certificate can be checked on the blockchain. The query process is simple and the result is clear, so the blockchain certificate The identity authentication process is:

Entity E sends its own certificate Cert to CA, requesting CA to verify its identity;
The CA first reads the information in the certificate and determines that the subject information of the certificate is correct; after the verification is passed, the CA calculates the hash value of the certificate and queries the status of the certificate on the blockchain. If the status is returned, the corresponding certificate status is issued. And use the return time to calculate that the certificate is in the service period, then the identity authentication is successful. If the status of the certificate is revoked or empty, it will return to the authentication failure, if the certificate is not in service, it will return to invalid.

Blockchain certificate expired, renewed, revoked

The expiration and renewal of digital certificates are part of the revocation list. Blockchain certificates are designed with a relatively simple expiration and renewal process to ensure the efficiency of certificate management in the ISE-CBCM model.

Expiration: When the certificate is in the process of using the blockchain and it is found that it is not within the validity period, it will return that the certificate has expired, and entity E needs to register again. At this time, the CA needs to set the old blockchain port of the certificate to put(revoke ,Hash(Cert)).
Update: There are two situations in the renewal process of the certificate. One is that the certificate expires and needs to be re-registered. The other is that the entity's original registration information has changed, such as entity E's IP information, contact information, Email, or ISE service level change , Service object changes, etc., registration information needs to be resubmitted. Entity E sends the re-registered information to RA. The issuance process is similar. Entity E gets a new certificate New Cert; when CA uploads to the blockchain data layer, it needs to upload the hash value Hash(Cert) of the old certificate and the new certificate at the same time. The hash value of the certificate Hash (NewCert). Due to the immutable modification of the saved data by the blockchain, the port number of the new certificate needs to be reset each time the certificate is updated ()put issue, Hash(NewCert), and the old certificate port number is set to invalidate the certificate status ()put revoke, Hash(Cert).
Revocation: Revocation of a blockchain certificate means that the subject of certificate invalidation actively applies for revocation, and the CA sets the status of the certificate blockchain port number to revoke. After the CA receives the information and determines the authenticity, it sends the certificate hash value Hash (Cert) and the revocation request to the blockchain data layer, and sets the port number () put revoke, Hash (Cert). When the certificate of entity E expires or needs to be updated, the registration process is not completed, or when the key of entity E is leaked, or the information service entity provided by the information service entity violates the security level, these certificates need to be revoked immediately to ensure system security In this case, the CA has the right to revoke its certificate voluntarily, and the revoking process is the same as above.

Application examples of blockchain certificates

Scenario 1: User 1 in this domain requests verification of ISE identity.

First, user 1 in this domain wants to receive ISE information services and needs to verify its identity, so it sends an access application and its own blockchain certificate Cert u1 to CA1 in this domain, and sends an access application to ISE to apply for verification of ISE identity;
After receiving the user's access application, ISE responds to the application and sends the certificate Cert ISE to CA1 in the local domain;
After CA1 receives the access application from user 1 and the certificate Cert u1 and certificate Cert ISE, it verifies the identity of user 1 and ISE in this domain by querying the validity of the certificates 1UCert and ISECert on the blockchain. If the identity authentication is passed, CA1 sends a pass verification to user 1 in this domain. If the verification fails, it returns authentication failure to user 1 and ISE at the same time, notifying ISE that it needs to perform identity authentication related operations again.

Scenario 2: External domain user 2 needs to verify the ISE identity.

Foreign domain user 2 wants to receive information services from ISEs that are not in the same trust domain, and needs to verify the identity of the ISE, send an access request and its own blockchain certificate Cert u2 to the CA2 of the local domain, and send an access request to the foreign domain ISE for verification Its identity
ISE sends its own certificate Cert ISE to CA1 of this domain after receiving the access application of user 2;
CA1 verifies the identity of ISE by querying the validity of the certificate Cert ISE on the blockchain; CA2 verifies the identity of user 2 by querying the validity of the certificate Cert u2 on the blockchain;
After all the above authentications are passed, CA1 and CA2 authenticate each other in the ISE-CBCM model. After CA1 and CA2 pass the mutual authentication, CA2 sends the pass authentication directly to user 2.
If any of the above authentication fails, CA1 returns authentication failure to ISE, notifying ISE that it needs to perform identity authentication related operations again, and CA2 returns authentication failure to user 2; where CA1 and CA2 are mutually authenticated in the ISE-CBCM model, you can Using the blockchain certificate, the nodes in the model set the public and private keys in the model in advance through secret sharing, etc., and issue certificates with the same parameters; the public key can also be shared through the key pool technology, and the identity of the other party can be verified by communication with the parameters in the model.