Exploring Asymmetric Encryption Principles
While reading about the principles of https today, I found that it uses the knowledge of asymmetric encryption, so I went to explore the basic principles of asymmetric encryption.
Asymmetric encryption
In asymmetric encryption algorithm, there are two kinds of keys, public and private, where the public key is public and does not need to be kept secret and the private key is held by individuals and must be kept secure and confidential. The use of two different keys for encryption and decryption is the reason for its name.
Each public key corresponds to a private key.
In the key pair, the one that makes everyone know is the public key, and the one that is not told to everyone and only known to you is the private key.
If the data is encrypted with one of the keys, only the corresponding one can be decrypted.
If it is possible to decrypt the data with one of the keys, the data must be encrypted with the corresponding one.
A and B communicate with each other, and if they do not want the content of the communication to be known by others, they can encrypt the content of the communication asymmetrically.
For example, in the BC architecture, the data communication between the browser and the server, the server can send its public key to the browser, the browser can encrypt the information it wants to send to the server using the public key, and when the server receives the information, it can decrypt the information using its own private key to obtain the content before encryption, while ensuring that no one else can break the information. At the same time, it is guaranteed that no one else can crack the information.
The server can also encrypt the returned information with its own private key, and the browser can then decrypt it with the public key sent to it by the server.
Public Key Authentication
Digital signature
The communication process described inside the public key encryption and decryption may seem simple, but think about this problem: In the above process, how does A know if B’s reply letter to him has been modified during the transmission process? This brings us to the concept of digital signature.
To achieve this, a hash calculation is generally done on the message to get a hash value. Note that this process is irreversible, which means that the original message content cannot be recovered through the hash value. When the message is sent out, the hash value is encrypted and sent out as a signature together with the message. After receiving the message, the receiver will recalculate the hash value of the message and compare it with the hash value attached to the message (after decryption), if it is the same, it means that the content of the message has not been modified, because here the hash calculation can guarantee that different contents will definitely get different hash values, so as soon as the content is modified, the hash value calculated according to the content of the message will change. Of course, an unsuspecting person can modify the message content and also modify the hash value so that they can match. To prevent this, the hash value is usually encrypted (i.e., signed) and then sent together with the message.
The process is illustrated by the following example:
B replied to A with a digital signature
1, B first use the hash function, to generate a summary of the letter (digest)
2. B uses his private key to encrypt this digest, so that a digital signature is generated (signature)
3, B will be attached to this signature to reply to the message, together with the message sent to A
4、A receives B’s message, takes down the digital signature and decrypts it by B’s public key to get the summary information of the letter
5, A uses the hash function specified by B in the message sent by B itself, and compares the result with the digest obtained by decryption in the previous step, if they are consistent, it means that the message sent by B has not been modified.
Is this the end of the problem? Far from it. Imagine that although A is sure that the message sent back to him by B is unmodified, how can he be sure that it is B who sent him the message back? What if an unsuspecting C secretly replaces B’s public key saved by A with his own and sends a message to A under B’s name?
To solve this problem, A just needs to be able to determine whether the public key he holds is B’s or not, which requires the use of a digital certificate.
Digital certificate
A digital certificate is used to verify the identity of the user to whom the public key belongs. In our daily life, if we want to verify a person’s identity, the usual practice is to check his ID card. We trust the credibility of the ID card issuer, i.e., the government agency, so as long as we verify that a person’s ID card is not forged, we believe that the person’s identity is consistent with what is described on the ID card.
A digital certificate is a person’s or organization’s ID card in the network world, and its issuing authority is the certificate authority (CA), which uses its own private key to sign the user’s identity information (mainly the user name and the user’s public key), and the signature and the user’s identity information together form the certificate.
Digital certificates are generally issued by digital certificate certification authorities and require
- The applicant generates a pair of public key and key through asymmetric encryption algorithm (RSA), and then sends the required application information (country, domain name, etc.) together with the public key to certificate authority (CA).
- The CA structure confirms that the message is correct and then generates a digest signature M of the entire application message using ** message digest algorithm** (MD5, SHA), and then encrypts the signature M and the digest algorithm used with CA’s own private key.
Composition
- The issuing authority of the certificate (Issuer)
Indicate what authority issued the certificate, that is, specify which certificate center (certificate authority, or CA) issued the certificate (only the creation of the certificate, not the user of the certificate). - the validity of the certificate (Valid from , Valid to)
That is, the validity of the certificate, or the period of use of the certificate. After the validity period, the certificate will be invalidated and can not be used. - public key
This was introduced earlier when we introduced the public key cryptosystem. The public key is used to encrypt and decrypt the message and is a long string of numbers. - certificate owner (Subject)
To whom this certificate is issued, or the owner of the certificate, is usually a person or a company name, the name of an organization, the URL of a company website, etc. - the algorithm used for the signature (Signature algorithm)
This refers to the encryption algorithm used for the digital signature of this digital certificate, so that the public key inside the certificate of the certificate issuing authority can be used to decrypt the fingerprint according to this algorithm. The encryption result of the fingerprint is the digital signature - fingerprint and fingerprint algorithm (Thumbprint, Thumbprint algorithm)
This is used to ensure the integrity of the certificate, that is, to ensure that the certificate has not been modified. The principle is that when issuing a certificate, the issuer 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/she also calculates the hash value (fingerprint) of the certificate according to the fingerprint algorithm, and if it is correct with the initial value, it means that the certificate has not been modified, because after the content of the certificate is modified, the hash value (fingerprint) calculated according to the content of the certificate will change. The hash value (fingerprint) calculated according to the content of the certificate will be changed after the content of the certificate is modified.
In fact, any individual/organization can become a CA (self-signed certificate), but the certificate client you issue is not trusted, also on the aforementioned need for authority. For example Symantec, Comodo, Godaddy, Digicert.
Clients trusting these CAs keep the root certificate (root certificate) of these CAs locally, root certificate is the CA’s own certificate, which is the beginning of the certificate verification chain. The root certificate has no authority (which is already an authority) to do digital signatures for it again, so it is all self-signed.
The CA will use intermediate-certificate to sign the server-side certificate instead of the root certificate, ensuring that the root certificate key is absolutely inaccessible.
Certificate Trust Chain
As mentioned before, when applying for a certificate from CA, we need CA’s private key to do asymmetric encryption on the signature digest of the whole certificate, that is, the certificate can be decrypted by CA’s public key to get signature digest of the certificate. When we sign the whole certificate again with the same digest algorithm (the algorithm used is stored inside the certificate), if the obtained signature is consistent with the signature on the certificate, it means that the certificate is trustworthy.
Similarly, intermediary certificates can be proven to be trustworthy in this way. Such a whole process is called Chain of trust.
It is I absolutely believe in you (A>B); you absolutely believe in him (B>C); equal to I absolutely believe in him (A>C)
The client gets the certificate returned by the server, and by reading it, it gets the issuing authority (Issuer) of the server-side certificate
The client goes to the OS to find the certificate of this publisher, and if it is not the root certificate it continues recursively until it gets the root certificate (usually stored in a more secure place, such as the source code of the framework, etc.).
Use the public key of the root certificate to decrypt and verify the legitimacy of the certificate on the previous layer, and then take the public key of the certificate on the previous layer to verify the legitimacy of the certificate on a higher layer; recursive backtracking.
Finally, verify that the server-side certificate is trusted.
Introduction to RSA principles
| 1 | Find the prime numbers | P, Q | - |
|---|---|---|---|
| 2 | Calculate the common modulus | N = P * Q | - |
| 3 | Euler function | φ(N) = (P-1)(Q-1) | - |
| 4 | Compute the public key E | 1 < E < φ(N) | E must be an integer E and φ(N) must be mutually prime |
| 5 | Compute the private key D | E * D % φ(N) = 1 | - |
| 6 | Encryption | C = M E mod N | C: ciphertext M: plaintext |
| 7 | Decryption | M = C D mod N | C: ciphertext M: plaintext |
Reference article: