Read the certificate in cryptography in one article

Read the certificate in cryptography in one article

In the previous article, we talked about digital signatures. The role of digital signatures is to prevent tampering and disguise, and to prevent denial. However, there is a very big premise for the correct use of digital signature technology, that is, the public key used to verify the signature must really belong to the sender.

If the public key you obtained is forged, no matter how perfect your signature algorithm is, you will get the wrong result.

So how can we secure the public key of the sender? Here you need to use the certificate. The so-called certificate is obtained by signing the sender's public key through a third-party trusted institution.

There are two concepts here: public key certificate (Public-Key Certificate, PKC) and certification authority (Certification Authority, CA). Friends familiar with blockchain should often hear the term CA, CA is the certification body here.

Examples of certificates

We look at an example that may be encountered in practice:

If A wants to send a message to B, this message wants to use B's public key to encrypt, but A can't know in advance what B's public key is, then you can use the following certificate architecture:

1. In the first step, B needs to generate his own key pair and then register the public key with the CA. Here CA is a trusted third-party organization.
2. After the CA obtains B's public key, it uses its own private key to sign B's public key to obtain a certificate.
3. A obtains the certificate and the CA's public key from the CA (CA is a trusted institution and can be obtained from a public site), and uses the CA's public key to verify the validity of the certificate signature.
4. A obtains B's public key and uses B's public key to encrypt the message.
5. B decrypts the message with his private key and gets the plaintext.

Well, this is the simplest example of certificate use.

Certificate standards and generation

Because the certificate is issued by the certification body, the user needs to verify it, then a standard certificate format is needed to facilitate the user. One of the most extensive certificate standard formats is the X.509 specification formulated by ITU (International Telecommunication Union) and ISO (International Organization for Standardization).

x.509 has many extended formats including: DER, CRT, CER, PEM, etc. They have different uses in different environments.

So how do you generate a certificate? You can use third-party tools, or you can use command line commands such as openssl to generate. The specific generation command will not be elaborated here.

PKI

With the format of the certificate, is it possible to actually use the certificate?

In fact, this is still not enough, we also need to define who should issue the certificate, how to issue it, if the certificate is invalid, etc. PKI (Public-Key Infrastructure) is a series of specifications and protocols formulated for the effective use of certificates.

The composition of PKI has three main parts:

1. user

Users are people who use PKI, that is, people who need to use CA to publish their own public keys and obtain others' public keys.

2. Certification body

The certification body is the CA. It is the person who manages the certificate. In addition to generating certificates, CA also has a very important task of invalidating certificates.

Because the user may lose the key, or for certain reasons, some certificates are discarded. Then you can initiate a revocation request to the CA. The invalid certificate will be stored in the CRL. CRL is an external certificate obsolescence list. When using a certificate, the user must first check whether the certificate is in the CRL list. If it is, the certificate cannot be used.

3. warehouse

The warehouse is a database for storing certificates. The certificates generated after user registration are stored in the warehouse for other users to obtain and use.

CA hierarchy

We learned about the concept of a root CA in Fabric. What does this mean?

We can know from the above introduction that, in fact, CA can not only be held by an organization, anyone can build a CA as long as they sign the public key.

If a large organization wants to build a CA, for example, a head office wants to build a CA, then it can build a root CA first, and then build sub-CAs under the root CA. These sub-CAs are responsible for issuing certificates for specific users at the bottom. .

Attacks on certificates

Because certificates are based on digital signature technology, all attacks based on digital signature technology are applicable to certificates.

Here is an introduction to the attacks on the PKI system:

1. Replace the public key before the public key is registered.

If user B wants to generate a certificate, he needs to register with CA and submit his public key to CA. Then, before the public key is submitted, it may be replaced maliciously.

2. Steal the certification authority's private key

All user public keys are signed by the CA's private key. If the CA's private key is stolen, all certificates are insecure.

CA is actually a centralized organization, and such problems often occur in centralized organizations. Breaking through one breaks everything.

3. Disguised as a certification body

The attacker can pretend to be a certification authority and let the user be fooled. So users must be careful when registering.

4. CRL time difference attack

If B's ​​key is lost, then he will submit a discard application to the CA, but there is a time difference between the submission of the application and the application taking effect, and the generation of the CRL. The discarded key can still be legally used during this time.

For more information, please visit http://www.flydean.com/certificate/