This paper first explains some basic knowledge and concepts of encryption and decryption, and then illustrates the function of encryption algorithm and the role of digital certificate through an example of encryption communication process. This is followed by a detailed explanation of digital certificates, a discussion of managing digital certificates in Windows, and a demonstration of creating digital certificates using Makecert. If you find any mistakes in the article, or what is not clear enough, please point it out!
1. Basic knowledge
This section explains some concepts and terminology. It is best to understand this section first.
1.1 Public-key Cryptography
The public key cryptosystem is divided into three parts: public key, private key, encryption and decryption algorithm. Its encryption and decryption process is as follows:
- Encryption: Encrypts the content (or plaintext) using an encryption algorithm and a public key to obtain ciphertext. The encryption process requires a public key.
- Decryption: Decrypts ciphertext using a decryption algorithm and a private key to obtain plaintext. The decryption process requires decryption algorithms and private keys. Note that contents encrypted with a public key can only be decrypted by the private key, that is, contents encrypted with a public key cannot be decrypted without knowing the private key.
Public key cryptosystems both the public key and the algorithm are public (that’s why they’re called public key cryptosystems), and the private key is private. Everyone is encrypted using a public key, but only the owner of the private key can decrypt it. In practice, people who need them will generate a pair of public and private keys, release the public key to others, and keep the private key for themselves.
1.2. Symmetric Key Algorithms
In symmetric encryption algorithms, the key used for encryption is the same as the key used for decryption. That is, both encryption and decryption use the same key. Therefore, symmetric encryption algorithm to ensure security, the key to do a good job of confidentiality, only let the use of people know, not public. This is different from the public key cryptosystem. In the public key cryptosystem, public keys are used for encryption and private keys are used for decryption. In the symmetric encryption algorithm, the same key is used for encryption and decryption without distinguishing between public keys and private keys.
// The key, usually a string or number, is passed to the encryption/decryption algorithm during encryption or decryption. The public key and private key mentioned in the public key cryptosystem are keys. The public key is the key used for encryption, and the private key is the key used for decryption.
1.3. Asymmetric Key Algorithms
In asymmetric encryption algorithms, the key used for encryption is different from the key used for decryption. The public key cryptosystem mentioned above is an asymmetric encryption algorithm. Its public key and private key cannot be the same, that is to say, the key used for encryption and decryption is different, so it is an asymmetric encryption algorithm.
1.4 introduction to RSA
RSA is a public key cryptosystem that is widely used today. If you are interested in RSA itself, I will see if I have time to write a detailed introduction to RSA.
The RSA cryptosystem is a public key cryptosystem. The public key is public and the private key is private. Its encryption and decryption algorithm is public. Content encrypted by a public key can and can only be decrypted by a private key, and content encrypted by a private key can and can only be decrypted by a public key. That is, both the public and private keys of RSA can be used for encryption and decryption, and the contents encrypted by one party can be decrypted only by the other party.
1.5. Signature and Encryption
When we say encryption, we mean that some content is encrypted, and the encrypted content can be restored through decryption. For example, we encrypt an email, and the encrypted content is transmitted on the network. After receiving it, the recipient can restore the real content of the email through decryption.
Here is the main explanation of the signature, signature is at the back of the information plus a paragraph of content, can prove that the information has not been modified, how can achieve this effect? Generally, you hash the information to get a hash value. Note that this process is irreversible, that is, you cannot hash out the original content of the information. The hash value is encrypted and sent as a signature when the message is sent. After receiving the message, the recipient recalculates the hash value of the message and compares it with the hash value attached to the message (after decryption). If the hash value is the same, it indicates that the content of the message has not been modified. The hash calculation ensures that different contents will get different hash values. The hash value calculated based on the content of the message changes. Of course, someone up to no good could change the contents of the message as well as the hash value to make them match. To prevent this, the hash value is usually encrypted (that is, signed) and sent with the message to ensure that the hash value is not altered. As for how someone can decrypt the signature, this process involves concepts such as digital certificates, which we will discuss later, but you need to understand the concept of signatures first.
2. Evolution of an encrypted communication process
Let’s look at an example. Now assume that the “server” and “client” are communicating over the network, and they intend to use RSA(see the introduction to RSA above) to encrypt the communication to keep the conversation secure. Because RSA is used as a public key cryptosystem, the server needs to publish the public key (the RSA algorithm is known to all) and keep the private key. The customer has somehow obtained the public key published by the Server, and the customer does not know the private key. How does the customer obtain the public key? We will explain later. Let’s look at how the two parties communicate confidentially:
2.1 Round 1:
Customer -> Server: Hello
Server -> Client: Hello, this is server
Customer > Server: ？？？？
Because messages travel over the network, someone can impersonate themselves as a “server” to send messages to clients. For example, the above message can be intercepted by hackers as follows:
Customer -> Server: Hello
Server -> Client: Hello, this is server
“Client” -> “hacker” : hello // The hacker intercepts the information sent by “client” to the server on a router between “client” and “server”, and then impersonates himself as “server”
Hacker -> Client: Hello, this is the server
Therefore, after receiving the message, the “client” cannot be sure that the message is sent by the “server”, and some “hackers” can also pretend to be “server” to send this message. How do you know if the message is sent from the server? There is a solution, because only the server has a private key, so if only you can verify that the other party has a private key, then the other party is a “server.” Therefore, the communication process can be improved as follows:
2.2 Second Round:
Customer -> Server: Hello
Server -> Client: Hello, this is server
Client -> Server: Prove to me that you are the server
“Server” – > “customer” : hello, this is the server} {hello, I’m server [private key | RSA]
/ / note here agreed that {} said the content after the RSA encryption, [|] said what kind of encryption key and the algorithm, the back of the sample in this way, such as the above} {hello, I’m server/private key | RSA means with the private key for “hello, I’m server” will be encrypted in a result.
To prove to the client that it is the server, the server encrypts a string with its private key and sends the plaintext and encrypted ciphertext to the client. For example, here is the string “hello, I am a server” and the string with the private key encrypted content} {hello, I’m server private key | RSA to clients.
After the client receives the message, she decrypts the ciphertext with her own public key and compares the ciphertext with the plaintext. If the ciphertext is the same, the message is indeed sent from the server. That is to say, “customer”} {hello, I’m server [private key | RSA] this content is decrypted with the public key, and then “hello, I’m server”. Because the contents encrypted by the “server” with the private key can be decrypted by and only by the public key, the private key is only held by the “server”, so if the decrypted content is legible, it means that the information must be sent from the “server”.
Suppose the hacker wants to impersonate the server:
Hacker -> Client: Hello, this is the server
Client -> Hacker: Prove to me that you are the server
“Hacker” – > “customer” : hello, I am a server} {hello, I’m server [????? | RSA] / / hackers cannot pretend to be here, because he didn’t know the private key, can’t use the private key to encrypt a string of backwardness to customer to verify.
Customer -> Hacker: ？？？？
Since the “hacker” does not have the “server” private key, so it sends past content, the “client” can not be decrypted through the server’s public key, so can assume that the other party is an impostor!
At this point, the “client” can confirm the identity of the “server” and can safely communicate with the “server”, but there is a problem, the content of the communication is still not confidential on the network. Why can’t it be kept secret? Can’t the communication process be encrypted with public and private keys? RSA private key public key RSA private key public key RSA private key public key
2.3 Round 3:
Customer -> Server: Hello
Server -> Client: Hello, this is server
Client -> Server: Prove to me that you are the server
“Server” – > “customer” : hello, this is the server} {hello, I’m server [private key | RSA]
“Customer” – > “server” : {my account is aaa, the password is 123, the balance of information sent to me I see} [public key | RSA]
The “server” – > “customer” : {your balance is RMB 100} [private key | RSA]
Note that the above information {your balance is RMB 100} [private key], this is the “server” with the private key encrypted content, but we have said before, the public key is released out, so all the people know that the public key, so in addition to the “customer”, other people can use the public key of {your balance is RMB 100} / private key to decrypt. So if the “server” uses a private key to encrypt and send it to the “client”, the information cannot be kept secret because the public key can decrypt the content. However, the “server” cannot encrypt the message with a public key, because the “client” does not have a private key, and the “sending client” cannot decrypt the message.
So the problem comes up again, and how do you solve it? In the actual application process, it is generally through the introduction of symmetric encryption to solve this problem, see the following demonstration:
2.4 Round 4:
Customer -> Server: Hello
Server -> Client: Hello, this is server
Client -> Server: Prove to me that you are the server
“Server” – > “customer” : hello, this is the server} {hello, I’m server [private key | RSA]
“Customer” – > “server” : {behind our communication process, use symmetric encryption for, here is a symmetric encryption algorithm and the key} [public key | RSA] / / blue font part is, the specific content of the symmetric encryption algorithm and key customer send them to the server.
“Server” -> “Client” : {OK, copy! } [key] | symmetric encryption algorithm
“Customer” – > “server” : {my account is aaa, the password is 123, the balance of information sent to me I see} [key] | symmetric encryption algorithm
“Server” – > “customer” : {your balance is RMB 100} [key] | symmetric encryption algorithm
During the communication, after confirming the identity of the server, the client selects a symmetric encryption algorithm and a key, encrypts the symmetric encryption algorithm and the key with the public key, and sends the symmetric encryption algorithm and the key to the server. Note that since the symmetric encryption algorithm and key are encrypted using public keys, even if the encrypted content is intercepted by the “hacker”, since there is no private key, the “hacker” will not know the contents of the symmetric encryption algorithm and key.
Since it is encrypted with a public key, only the private key can be decrypted, which ensures that only the server can know the symmetric encryption algorithm and key, and no one else can (the symmetric encryption algorithm and key are chosen by the “client”, so of course the “client” knows how to decrypt the encryption). This allows the “server” and the “client” to encrypt the content of the communication using symmetric encryption algorithms and keys.
To sum up, RSA encryption algorithm plays two main roles in this communication process:
- Because the private key is owned only by the server, the client can determine whether the other party is a server by determining whether the other party has a private key.
- Under the cover of RSA, the client securely negotiates a symmetric encryption algorithm and key with the server to ensure the security of the content in the following communication process.
If you understand why RSA is not used to encrypt the communication process, but to determine a symmetric encryption algorithm to ensure the security of the communication process, then you have understood the previous content. (If not, please refer to 2.3 and 2.4. If not, we should make this clear and you can leave a comment.)
At this point, the “client” can confirm the identity of the “server” and the communication between the two sides can be encrypted so that no one else can decrypt the intercepted communication. Indeed, it seems that the communication process is more secure.
But there is still a problem. From the beginning, we said that the “server” needs to publish the public key. How does the “server” send the public key to the “client”? The first two things that might come to mind are:
A) Place the public key at a download address somewhere on the Internet and give it to the “customer” in advance.
B) The server sends the public key to the Customer each time it communicates with the Customer.
But there are problems with both methods,
For method a), the “client” cannot determine whether the download address is issued by the “server”, why do you believe that the download address is issued by the “server” and not forged by others, what if a fake download? It is also unrealistic for all “clients” to download public keys before communicating.
There is also a problem with the B) method, because anyone can generate a pair of public and private keys by sending their own private key to the “client” and impersonating the “server.” The schematic diagram is as follows:
“Client” -> “hacker” : Hello // Hackers intercept messages from “client” to “server”
“Hacker” -> “client” : Hello, I am the server, this is my public key // The hacker himself generates a pair of public and private keys, sends the public key to “client”, keeps the private key
Client -> Hacker: Prove to me that you are the server
“Hacker” – > “customer” : hello, I am a server} {hello, I’m server [hacking their private key | RSA] / / customer received “hackers” information that is encrypted with the private key, is “hackers” can be used to your public key to decrypt, so as to be mistaken for “hacker” is the “server”
Therefore, the “hacker” only needs to generate a pair of public and private keys, and then send the public key to the “client” and keep the private key. In this way, since the “client” can use the public key of the hacker to decrypt the contents encrypted by the private key of the hacker, the “client” will believe that the “hacker” is the “server”, resulting in security problems. The root of the problem here is that everyone can generate public and private key pairs, and there is no way to know whose public key pair belongs to. If you can determine who owns the public key, you won’t have this problem. For example, if you receive a public key from a “hacker” posing as a “server”, after some kind of check, it would be nice to find that the public key is not the “server”.
To solve this problem, digital certificates have emerged, which can solve our problem above. A digital certificate contains the following details:
- Certificate issuing authority
- Validity of certificate
- The public key
- Certificate Owner (Subject)
- The algorithm used for the signature
- Fingerprints and fingerprint algorithms
A digital certificate can ensure that the public key in the certificate is the owner of the certificate, or that the certificate can be used to confirm the identity of the other party. That is, we get a digital certificate, and we can figure out who the digital certificate belongs to. How this is determined will be explained later when we discuss digital certificates in detail. Now change the previous communication process using digital certificates to the following:
2.5 Round 5:
Customer -> Server: Hello
“Server” -> “Client” : Hello, I am the server, this is my digital certificate // this uses the certificate instead of the public key
Client -> Server: Prove to me that you are the server
“Server” – > “customer” : hello, this is the server} {hello, I’m server [private key | RSA]
Notice that in the second communication above, the “server” sent its certificate to the “client” instead of sending the public key. The client can verify that the certificate belongs to the “server”, that is, that the owner of the certificate is “server”, and that the public key in the certificate is indeed “server”. At the back of the process is the same as before, “customers” to the “server” to prove their identity, “server” a content together with the clear text is encrypted with the private key to the “customer”, “customer” after the encrypted content using the public key to decrypt the digital certificate and clear contrast, if is consistent, then the other party is indeed a “server”, The two parties then negotiate a symmetric encryption to ensure the security of the communication process. At this point, the whole process is complete, let’s review:
2.6 Complete Process:
Step1: the client sends a communication request to the server
Customer -> Server: Hello
Step2: the “server” sends its own digital certificate to the customer. The certificate has a public key to encrypt information, and the private key is held by the “server”
“Server” -> “Client” : Hello, I am the server, here is my digital certificate
Step3: after the “client” receives the certificate of “server”, it will verify whether the digital certificate belongs to “server” and whether there is any problem with the digital certificate. If there is no problem with the digital certificate, it means that the public key in the digital certificate really belongs to “server”. After check the digital certificate, “customer” will send a random string to the “server” that is encrypted with the private key to server the encryption result is returned to the “customer”, “customer” use public key to decrypt the return result, if the decryption results agree with the generated random string before, that means the other party is, indeed, the private key holder, or the other is the “server”.
“Client” -> “server” : Prove to me that you are the server. This is a random string.
“Server” – > “customer” : {a random string} [private key | RSA]
Step4: After verifying the identity of “server”, “client” generates a symmetric encryption algorithm and key for subsequent communication encryption and decryption. The symmetric encryption algorithm and key will be encrypted by the “client” with the public key and then sent to the “server”. It is useless for others to intercept, because only the “server” has the private key that can be decrypted. In this way, both the “server” and the “client” can use symmetric encryption algorithms to encrypt and decrypt the communication content.
“Server” -> “client” : {OK, we have received your symmetric encryption algorithm and key! What can I do for you? } [key] | symmetric encryption algorithm
“Customer” – > “server” : {my account is aaa, the password is 123, the balance of information sent to me I see} [key] | symmetric encryption algorithm
“Server” – > “customer” : {hello, your balance is RMB 100} [key] | symmetric encryption algorithm
… // Continue other communications
2.7 Other Issues:
The above procedure is very close to the real COMMUNICATION process of HTTPS. You can follow this procedure to understand the working principle of HTTPS. But for the sake of explanation, there are some details that I haven’t covered, so if you’re interested, you can take a look at this. You can skip it. It doesn’t matter.
【 Question 1】
After checking the certificate, the client sends a random string to the server to encrypt with the private key in order to determine whether the client really has the private key. But there is a problem, “hackers” can also be sent to the “server” to encrypt a string and get the encrypted content, such as for the “server” is not secure, because hackers can send some simple regular string for the “server” encryption, so as to find the rule of encrypted could threaten the safety of the private key. Therefore, it is not secure for a “server” to randomly encrypt an unsolicited string with a private key and send the result to the other party.
[Solution]
Each time the server receives a string to be encrypted from the client, instead of actually encrypting the string itself, it hashes the string and sends it to the client, encrypting the hash value of the string instead of the original string. The client decrypts the hash value and computes the hash value of the string itself and compares it to see if it is consistent. That is, instead of encrypting the received string directly, the “server” encrypts a hash value of the string, which avoids encrypting regular strings and reduces the chance of cracking. The client sends the string itself, so it can calculate the hash value of the string itself, and then compare the encrypted hash value sent by the server with its own hash value to determine whether it is the server.
【 Question 2】
In the course of communication between the two parties, the “hacker” can intercept the encrypted content sent, although he cannot decrypt the content, he can disrupt the process, for example by sending the message many times intact.
[Solution]
You can add a serial number or a random value to the content of the communication. If the “client” or “server” receives a message with a serial number or a random value that has appeared before, it means that someone resends the message content to make trouble in the communication process, and the two sides will immediately stop the communication. One might ask, what if someone keeps being disruptive? Isn’t there no communication? The answer is yes, for example, someone who controls your router to the Internet can target you. But some important applications, such as the military or government’s internal networks, do not use the public network we normally use, so the average person will not disrupt their communications.
【 Question 3】
During the communication between the two parties, the hacker can not only send the intercepted message repeatedly, but also modify the intercepted ciphertext and then send it. Although the modified ciphertext cannot completely control the decrypted message content, the decrypted ciphertext is still damaged. Therefore, if the hacker modifies the ciphertext during transmission, the client and the server cannot determine whether the ciphertext is modified. It may not work, but hackers can keep taking chances.
[Solution]
Each time a message is sent, a hash value is calculated for the message content and encrypted with the hash value. The recipient decrypts the received message to obtain the plaintext and hash value. Then the recipient performs a hash calculation on the received message and compares it with the received hash value to check whether the received message matches. If a match is found, the message has not been modified during transmission. If no, it indicates that the encrypted data is deliberately modified during the call. Interrupt the call immediately and perform other processing.