Secure Digital certificates

Public key, private key:
exists in asymmetric encryption
Key:
exists in symmetric encryption

The CER file holds the public key and some information about the user (in fact, the digital certificate mentioned below)
P12 (PFX) file (a backup of CER, for others to use, because other people do not have a private key, all P12 also put the private key inside) = CER file + private key

Public Key Cryptography System:
is divided into three parts:
1. Public key
2. Private key
3. Encryption and decryption algorithm
Encryption and decryption process:
Encryption:
Encryption algorithm + Public key + content (or explanatory text) = ciphertext (the encryption process requires a public key)
Decrypt:
Decryption algorithm + private key + ciphertext = plaintext (decryption process requires decryption algorithm and private key)
The contents of the public key encryption can only be decrypted by the private key.
Public keys and algorithms are public;
The private key is confidential.
Symmetric encryption algorithm:
Both encryption and decryption are the same key used (as distinguished from the public key cryptography)
The key needs to be kept confidential and cannot be disclosed externally.
Key:
Typically a string or number that is used by the encryption and decryption algorithm.
Asymmetric Encryption algorithm:
Encryption uses a key that is not the same as the key used for decryption. (for example, the Public key cryptography scheme above)
Rsa:
RSA is a public key cryptosystem, public key, private key secrecy, and its encryption and decryption algorithm is public.
The contents of public key encryption can only be decrypted by the private key;
The contents of the private key encryption can only be decrypted by the public key. (These two points will allow the client to confirm the authenticity of the server, as in the following example)
This pair of RSA public and private keys can be used to encrypt and decrypt
And the encrypted content of one party can be decrypted by and only by the other.
Signature and encryption:
Signature:
Add a piece of content to the back of the message to prove that the information has not been modified.
Practice:
Sender:
Make a hash calculation of the information (MD5) to get a hash value added to the message
This hash value is encrypted and sent out as a signature and message.
Receiving Party:
Decrypt the hash value that came with the message
Recalculate the hash value of the information and compare it with the hash value above
If consistent, the content has not been modified. (The hash value will not be the same because the different content is calculated)
To prevent others from modifying the information content and also modifying the hash value so that they match, so:
Hash values are usually encrypted and sent together with the message.
Evolution of an encrypted communication process:
Suppose that "server" and "customer" want to communicate on the network, they intend to use RSA to encrypt the communication to ensure the security of the conversation.
"Server" needs to publish public key (algorithm does not need to advertise, RSA algorithm Everybody knows), own the private key.
"Customer" has some way to get the public key published by the "server", the customer does not know the private key.
Encryption Evolution Process:
1.
Normal Demo:
"Customer", "Server": Hello
"Server", "Customer": Hello, I am the server
After someone pretends to be a "server":
"Customer", "hacker": Hello//Hackers intercept "customers" on a router between "customer" and "Server" to the server, and then impersonate the "server"
"Hacker", "Customer": Hello, I am the server
Therefore, after receiving the message, the customer is not certain that the message was sent by the "server".
Workaround:
Because only the server has a private key, if you can only confirm that the other side has a private key, then the other side is "server"
2.
Normal Demo:
"Customer", "Server": Hello
"Server", "Customer": Hello, I am the server
"Customer", "Server": Prove to me that you are the server
"Server", "Customer": Hello, I am the server {Hello, I am the server}[private key | RSA]
/*
{} indicates the content after RSA encryption, [|] Indicates what key and algorithm are used for encryption, which is represented in the following example.
For example above {Hello, I am server}[private key | RSA] is the result of encrypting the "Hello, I am the server" with the private key.
*/
How does the server prove itself to be a server?
1. First, this is the use of RSA encryption system
2. The user has a public key published by the server
3. Server Retention Key
4. The server sends the plaintext to the user with ciphertext encrypted with the key
5. The user decrypts the received ciphertext by using the public key published by the server and compares the received plaintext to prove that the server is holding the private key and that it is the server that owns the public key.
6. Guarantee Principle:
Private key encrypted content can only be decrypted by the public key
After someone pretends to be a "server":
"Hacker", "Customer": Hello, I am the server
"Customer", "hacker": Prove to me that you are the server
"Hacker", "Customer": Hello, I am the server {Hello, I am the server}[???| RSA]
Here the hacker cannot impersonate, because he does not know the private key, cannot encrypt a string with the private key and sends it to the customer to verify.
"Customer", "Hacker":????
Since the "hacker" does not have a "server" private key, so it sends the past content, "the customer" is unable to decrypt through the server's public key, therefore can assume the other party is a counterfeit!
3.
With 2, the authenticity of the server can be ensured, but during communication, the content is not kept secret on the network (RSA is used on the fly):
Normal Demo:
"Customer", "Server": Hello
"Server", "Customer": Hello, I am the server
"Customer", "Server": Prove to me that you are the server
"Server", "Customer": Hello, I am the server {Hello, I am the server}[private key | RSA]
"Customer", "server": {My account is AAA, the password is 123, send me the information of my balance see}[public key | RSA]
"Server", "customer": {Your balance is $100}[private Key | RSA]
Here's the problem:
{Your balance is $100} [Private key],{your balance is $100} This is what the "server" encrypts with the private key,
Because the public key is published, everyone knows the public key,
In addition to the "customer", other people can also use the public key to {your balance is 100 yuan}[private key] to decrypt,
Therefore, the server uses the private key to send ciphertext to the customer is meaningless, is not confidential;
And the server cannot use the public key to encrypt plaintext to the client, because the client does not have the private key to get the data can not be solved.
General Solutions:
Introducing symmetric encryption
4.
Normal Demo:
"Customer", "Server": Hello
"Server", "Customer": Hello, I am the server
"Customer", "Server": Prove to me that you are the server
"Server", "Customer": Hello, I am the server {Hello, I am the server}[private key | RSA]
"Customer", "server": {We follow the communication process, with symmetric encryption, here is the symmetric encryption algorithm and the key}[public key | RSA]
Part of the blue font is the symmetric encryption algorithm and the specific contents of the key, which the customer sends to the server. (equivalent to the key passed to the background in the project)
"Server", "customer": {OK, Roger! }[Key | symmetric encryption algorithm]
"Customer", "server": {My account is AAA, the password is 123, send me the information of my balance see}[key | symmetric encryption algorithm]
"Server", "customer": {Your balance is $100}[key | symmetric encryption algorithm]
/*
After the customer confirms the identity of the server, the customer chooses a symmetric encryption algorithm and a key to encrypt the symmetric encryption algorithm and key with the public key and send it to the "server".
Note that because the symmetric encryption algorithm and the key is encrypted with the public key, even if the encrypted content is "hacker" intercepted, because there is no private key, "hackers" do not know the symmetric encryption algorithm and the contents of the key.
*/
Summarize:
RSA encryption algorithm in this communication process has played a major role in two:
1. Because the private key is only owned by the server, the client can determine whether the other party is a "server" by judging whether the other person has a private key.
2. The client through the cover of RSA, secure and server negotiate a symmetric encryption algorithm and key to ensure the security of the content of the subsequent communication process.
How the server publishes public keys externally:
Problematic practices:
A) Place the public key in one of the places on the Internet and download it to the customer beforehand.
Or
b) Each time the customer starts communication, the server sends the public key to the customer.

For a:
"Customer" cannot determine if this is a "server" published
For B:
Anyone can generate a pair of public and private keys on their own, so he can impersonate a "server" by sending his own public key to the "customer". The schematic is as follows:
"Customer", "hacker": Hello
Hackers intercept "customer" messages sent to "server"
"Hacker", "Customer": Hello, I am the server, this is my public key
The hacker generates a pair of public and private keys themselves, sends the public key to the "customer", and retains the private key
"Customer", "hacker": Prove to me that you are the server
"Hacker", "Customer": Hello, I am the server {Hello, I am the server}[hacker own private key | RSA]
After the customer receives the "hacker" to encrypt the information with the private key, it can be decrypted by the "hacker" to the public key, thus mistaken that "hacker" is "server"
Source of the problem:
You can generate a public key, a private key pair, and you can't confirm who the public key is.
If you receive a "hacker" impersonating the "server" sent over the public key, after some kind of check, if you can find that the public key is not "server" is good (this is the key)
Solution:
Introduction of digital certificates:
A digital certificate contains the following:
1. Issuing authority for certificates
2. Validity of the certificate
3. Public key
4. Certificate owner (Subject)
5. Algorithms used for signing
6. Fingerprint and fingerprint algorithm
A digital certificate ensures that the public key in the digital certificate is indeed the owner (Subject) of the certificate,
Or the certificate can be used to confirm the identity of the other
That
To get a digital certificate, we can tell who the digital certificate is.

Continued encryption evolution (using digital certificates):
5.
"Customer", "Server": Hello
"Server", "Customer": Hello, I am the server, here is my digital certificate
The certificate is used instead of the public key
"Customer", "Server": Prove to me that you are the server
"Server", "Customer": Hello, I am the server {Hello, I am the server}[private key | RSA]
/*
"Server" sends its own certificate to "customer" instead of sending the public key
What is the difference between this and the above server publishing public key mode B?
The difference is:
As you might expect, it would be nice if the client could know if the public key was published by the server.
"Customer" can verify whether the certificate is "server" according to the certificate,
That is, can verify that the owner of this certificate is not a "server",
This confirms that the public key in this certificate is indeed a "server" (the verification method is explained below)
The following procedure is the same as before:
"Customer" lets "server" prove its identity,
"Server" encrypts a piece of content with the private key and sends it to the "customer" together with the plaintext,
"Customer" decrypts the encrypted content with the public key in the digital certificate and compares it with the plaintext,
If consistent, then the other side is really a "server",
The two sides then negotiate a symmetric encryption to ensure the security of the communication process.
Here, the whole process is complete.
*/
Communication encryption Complete Process:
1. "Customer" sends a communication request to the server:
"Customer", "Server": Hello
2. The server sends its own digital certificate to the customer. A public key in the certificate is used to encrypt information, and the private key is held by the "server"
"Server", "Customer": Hello, I am the server, here is my digital certificate
3. After the "customer" receives the "server" certificate, it will verify that the digital certificate is not "server", digital certificate is not a problem, digital certificate if the check is not a problem, it means that the public key in the digital certificate is indeed "server".
(The verification method is explained below)
4. After checking the digital certificate, "customer" will send a random string to the "server", the "server" with the private key to encrypt, the server to return the encrypted results to the "customer", "customer" with the public key to decrypt the return result, if the decryption result and the previous generated random string consistent, That means that the other person is indeed the owner of the private key, or that the other person is indeed a "server".
"Client", "server": Prove to me you are the server, this is a random string
In the previous example, in order to facilitate the explanation, the use of "Hello" and so on, the actual situation is generally randomly generated a string.
"Server", "customer": {a random string}[private key | RSA]
5. After verifying the identity of the "server", "customer" generates a symmetric encryption algorithm and key for subsequent communication encryption and decryption. This symmetric encryption algorithm and key, "customer" will be encrypted with the public key sent to the "server", others intercepted also useless, because only the "server" in the hands of the private key can be decrypted. In this way, both "server" and "client" can use symmetric encryption algorithms to encrypt and decrypt the communication content.
"Customer", "server": {We follow the communication process, with symmetric encryption, here is the symmetric encryption algorithm and the key}[public key | RSA]
"Server", "customer": {OK, already received the symmetric encryption algorithm and key you sent! What can I do for you? }[Key | symmetric encryption algorithm]
"Customer", "server": {My account is AAA, the password is 123, send me the information of my balance see}[key | symmetric encryption algorithm]
"Server", "customer": {Hello, your balance is 100 Yuan}[key | symmetric encryption algorithm]
...//Continue other communications
Enhanced version:
Question 1:
For step 4, in fact, for the server is a threat, because the string in 4 is not processed, the hacker can also send some simple and regular strings to "server" encryption, so as to find the law of encryption, may threaten the security of the private key
Solution:
The "server" is not the real encryption of the string itself, but instead of a hash of the string, encrypt the string hash value (not the original string) sent to the "customer", "Customer" After receiving decryption of the hash value and calculate the hash value of the string and then the comparison is consistent, also can determine whether the other side is a "server."
Question 2:
In the process of communication between the two sides, "hackers" can intercept the sent encrypted content, although he cannot decrypt the content, but he can disrupt, for example, the message is sent intact, disrupting the communication process.
Solution:
You can add a serial number or a random value to the content of the communication, if the "customer" or "server" received the information in the previous sequence or random values, then the communication process to re-send information content to disrupt, the two sides will immediately stop communication.
Question 3:
In the process of communication between the two sides, the "hacker" in addition to the simple repetition of the interception of messages, but also modify the interception after the redaction of the changes to send, because the changes are ciphertext, although the message can not completely control the decrypted content, but still will destroy the decrypted cipher.
Solution:
Each time the message is sent, the content of the information is first hashed to calculate a hash value, the content of the information and the hash value is encrypted and sent. The receiving party decrypts the content and hash value after receiving the message, and then the receiving party makes a hash calculation of the received information, and compares it with the hash value received to see if it matches.
If the match is true, the information has not been modified during transmission.
If the mismatch indicates that the encrypted data has been deliberately modified, interrupt the call process and do other processing immediately.
The composition and principle of the certificate:
Part of the composition (most of the content):
1.Issuer (issuing authority for certificates)
Indicate which company created the certificate (just create the certificate, not the user of the certificate)
2.Valid from, Valid to (validity of certificate)
After the expiry date, the certificate will be void and cannot be used.
3.Public key (Public key)
4.Subject (Theme)
The certificate is issued to WHO, or the owner of the certificate, usually a person or a company name, the name of the organization, the company's website URL, etc.
5.Signature algorithm (algorithm used for signing)
The cryptographic algorithm used by the digital signature of this digital certificate, so that it can be decrypted using the public key of the certificate publisher's certificate, based on the algorithm. The fingerprint encryption results in a digital signature.
6.Thumbprint, thumbprint algorithm (fingerprint and fingerprint algorithm)
Guarantee the integrity of the certificate, that is, to ensure that the certificate has not been modified,
The principle is that when the certificate is issued, the publisher calculates the hash value (fingerprint) of the whole certificate according to the fingerprint algorithm (a hash algorithm) and puts it together with the certificate, and when the user opens the certificate, he also calculates the hash value of the certificate according to the fingerprint Algorithm (fingerprint)
This fingerprint will use "Securetrust CA" This certificate authority's private key with the signature algorithm (Signature algorithm) encryption and the certificate put together, so modify the contents of the certificate and then modify the hash value is also useless, because there is no private key
(Just like above
"Server", "Customer": Hello, I am the server {Hello, I am the server}[private key | RSA]
How does the server prove itself to be a server?
1. First, this is the use of RSA encryption system
2. The user has a public key published by the server
3. Server Retention Key
4. The server sends the plaintext to the user with ciphertext encrypted with the key
5. The user decrypts the received ciphertext by using the public key published by the server and compares the received plaintext to prove that the server is holding the private key and that it is the server that owns the public key.
6. Guarantee Principle:
Private key encrypted content can only be decrypted by the public key
This RSA way to prove that you want to be the same server)
/*
To ensure security, the certificate's fingerprint and fingerprint algorithm are encrypted and posted together with the certificate when it publishes the certificate, in case someone modifies the fingerprint and then forges the corresponding digital certificate. (Just like the hacker above wants to forge himself as a server)
Here comes the question again, what is the fingerprint and fingerprint algorithm used to encrypt the certificate? They are encrypted with the private key of the certificate publisher. The fingerprint and fingerprint algorithm can be decrypted with the public key of the certificate publisher, which means that the certificate publisher has his own certificate in addition to the certificate issued by the issuing authority.
Where does the certificate authority's certificate come from???
The certificate publisher's digital certificate (typically generated by himself) is installed in the operating system by Microsoft (or another operating system developer) when our operating system is just installed (for example, Windows XP).
(This can be understood as above as the operating system is the customer, the certificate authority is the server, the operating system is the certificate is the server to send customers a digital certificate to enable customers to verify that they are the correct server,
That is, let the operating system to take the system exists digital certificate (with a public key) to verify that the certificate Publisher is the real certificate issuing agency (by taking the public key to the fingerprint decryption compared to the fingerprint of the same to determine the authenticity of the certificate))
Because of the digital certificates issued by these agencies in the operating system, the public key can verify the validity of the certificate for the digital certificate that they have generated for the company.
These certificate publishers own the private key corresponding to his own digital certificate, and he uses the private key to encrypt the thumbprint of all the certificates he publishes as a digital signature.
*/
How to apply for a certificate to the issuing authority of the certificate:
When the certificate issuing authority publishes the certificate, it writes the information such as Issuer,public Key,subject,valid From,valid to the certificate in clear text.
Then we use a fingerprint algorithm to calculate a fingerprint of the contents of these digital certificates,
and the fingerprint and fingerprint algorithm with their own private key to encrypt, and then published with the contents of the certificate,
At the same time, the certificate issuing agency will give us a private key to our company.
Put the certificate into use, we at the beginning of the communication process will send the certificate to each other, how the other party to check the certificate is indeed legitimate and is our company's certificate?
First, the application (the other communication program, such as IE, Outlook, etc.) reads the certificate in the issuer (publisher) as "Securetrust CA",
The certificate for the "Securetrust CA" is then found in the certificate of the trusted publisher in the operating system.
If you can't find it, it means that the issuing agency of the certificate is a parallel importer, the certificate may be faulty and the program will give you an error message.
If the "Securetrust CA" certificate is found in the system, the application will remove the "Securetrust CA" Public key from the certificate.
Then the fingerprint and fingerprint algorithm in our ABC company's certificate is decrypted with this public key,
This fingerprint algorithm is then used to calculate the fingerprint of the "ABC Company" certificate, comparing the computed fingerprint with the fingerprint placed in the certificate.
If it is consistent, the certificate of "ABC Company" is definitely not modified and the certificate is published by "Securetrust CA", the public key in the certificate must be "ABC Company".
The other person can then confidently use this public key to communicate with our "ABC company".
/* This part needs to be understood in context */

Certificate Issuing Authority:
In fact, all companies can issue certificates, but their own issued certificates are not recognized by the authorities,
Microsoft in its operating system, and does not trust us this certificate issuing agency,
When the application checks the certificate's legitimate letter, the publisher of the certificate is not the publisher that the operating system trusts, and an error message is thrown.
This means that the certificate issued by our Certificate authority is not pre-installed in the Windows operating system.

iOS operations on CER:

Secure Digital certificates