For general developers, it is rarely necessary to conduct in-depth research on the basic technologies in the security field, but in view of various security-related problems encountered in daily system development, familiarity and understanding of the basic principles and use of these security technologies The scene is still very necessary. This article will briefly introduce the technologies in the security field such as asymmetric encryption, digital digest, digital signature, digital certificate, SSL, HTTPS, etc., explain the relationship between them, and add some peripheral topics.
There are many technologies in the security field, but in the final analysis, they are all to ensure the following three aspects:
1) Authenticate users and servers to ensure that data is sent to the correct client and server 2) Encrypt data to prevent data theft in the middle 3) Maintain data integrity to ensure data is not altered during transmission.
Symmetric encryption and asymmetric key encryption and decryption For a piece of data, through an algorithm, based on the incoming key (a string of numbers or characters, also called "key"), the plaintext data is converted into The unreadable ciphertext is known as "encryption". Similarly, after the ciphertext reaches the destination, a corresponding algorithm and a key are needed to decrypt the ciphertext into plaintext, which is "decryption". If the same key is used for encryption and decryption, then this is "symmetric key encryption and decryption" (the most common symmetric encryption algorithm is DES). If two different keys are used for encryption and decryption, then this is "asymmetric key encryption and decryption" (the most commonly used asymmetric encryption algorithm is RSA). One of these two different keys is called the public key and the other is called the private key. The public key is open to the public and can be obtained by anyone, while the private key is kept by oneself. In fact, the public key and the The private key is no different. The public key becomes the public key because it will be published, generating any copy for anyone to obtain, while only the service host holds a unique private key. From this From the point of view of the distribution mode, it is not difficult to see the intention. This distribution mode is actually determined by the network topology of the website multi-client (browser) and a single server. Multi-client means that the key can be copied and encrypted. Public access, a single server means that the key is strictly controlled and can only be held by this server, which is actually one of the important reasons why the trusted host can be determined through the data certificate mentioned later. If we jump out of the topology environment of the web site, there is actually no distinction between the public key and the private key. For example, for those SSH hosts that use the key for authentication, a private key is often generated for each user and distributed to the They keep it themselves, the SSH host will keep a copy of the public key, and the public key and the private key will each have a copy, which will not be publicly distributed.
In short:
Symmetric encryption is fast, but the keys for encryption and decryption must be the same. Only both parties can know the key. Asymmetric encryption is slow, and the keys for encryption and decryption are different. A person holds the private key, and anyone can know the public key.
Digital digest--checking data integrity is very simple. When downloading files, we often see that some download sites also provide "digital digests" of the downloaded files for the downloader to verify whether the downloaded files are complete, or Says if it is "exactly the same" as the file on the server. In fact, the digital digest is to use a single Hash function to "digest" the plaintext to be encrypted into a string of ciphertexts of fixed length (128 bits). This string of ciphertexts is also called digital fingerprints. It has a fixed length and different plaintexts. Digest into ciphertext, the result is always different, and the same plaintext must have the same digest. Therefore, "digital digest" may be more appropriate to call "digital fingerprint". The "digital digest" is the fundamental reason why https can ensure data integrity and tamper resistance.
Digital signature - a natural technology Let's take a look at what we can do with the two technologies of "asymmetric key encryption and decryption" and "digital digest"? If the sender wants to send a message to the receiver, before sending the message, the sender uses a hash function to generate a message digest from the message text, and then encrypts the digest with its own private key. This encrypted digest will be used as the "signature" of the message and sent to the receiver together with the message. The receiver first uses the same hash function as the sender to calculate the message digest from the received original message, and then Use the sender's public key to decrypt the digital signature attached to the message. If the two digests are the same, then the receiver can confirm that the message was sent from the sender and has not been omitted or modified! This is what the combination of "asymmetric key encryption and decryption" and "digital digest" technology can do, which is what people call "digital signature" technology. In this process, the process of generating a digest of the transmitted data and encrypting it with a private key is the process of generating a "digital signature". The encrypted digital digest is what people call a "digital signature"! Digital signature technology is the application of "asymmetric key encryption and decryption" and "digital digest". It encrypts the digest information with the sender's private key and transmits it to the receiver together with the original text. The receiver can decrypt the encrypted digest information only with the sender's public key, and then use the HASH function to generate a digest message for the received original text and compare it with the decrypted digest message. If they are the same, it means that the received information is complete and has not been modified during the transmission process; otherwise, it means that the information has been modified, so the digital signature can verify the integrity of the information. (Note that the digital signature can only verify the integrity of the data, whether the data itself is encrypted is not within the control scope of the digital signature) To sum up, the digital signature has two functions: one is to confirm that the message is indeed signed by the sender and sent out Yes, because others cannot fake the sender's signature. Second, the digital signature can determine the integrity of the message.
Digital certificate--trusted public key only from the two security aspects of "accurately authenticate the sender's identity" and "ensure data integrity", digital signature seems to have been completely done, is there any possibility of loopholes? Yes, the vulnerability is not in the digital signature technology itself, but in the key that it relies on, only if the key is authentic and reliable, the use of digital signature is safe and effective. Consider this possible situation: in the above example of sending a message to the receiver, if the public key held by the sender has a problem or has been replaced, then the impersonation receiver holding the corresponding private key It is possible to receive the message sent by the sender. The question here is: for the requesting party, how can it be sure that the public key it gets must have been issued from the target host, and that it has not been tampered with? Or does the requested target host itself engage in improper behavior of stealing user information? At this time, we need an authoritative and trustworthy third-party organization (usually an organization audited and authorized by the government) to uniformly issue the public key of the host organization to the outside world. As long as the requesting party obtains the public key, it avoids the above-mentioned problem occurs. Such organizations are called Certificate Authorities (CAs), and the files they issue containing the name of the host organization and the public key are what people call "digital certificates". The issuance process of digital certificates is generally as follows: the user first generates his own key pair, and transmits the public key and some personal identity information to the certification center. After verifying the identity, the certification center will perform some necessary steps to make sure that the request is indeed sent by the user, and then the certification center will issue a digital certificate to the user, which contains the user's personal information and his public key information , and the signature information of the certification center is also attached. Users can use their digital certificates to carry out various related activities. Digital certificates are issued by independent certificate issuers. Digital certificates vary, each offering a different level of trustworthiness. You can obtain your own digital certificate from a certificate issuing authority. (This paragraph is taken from Baidu Encyclopedia)
SSL
SSL (Secure Socket Layer) is a secure transmission protocol designed by netscape and mainly used for web. This protocol has been widely used on the WEB. IETF ( www.ietf.org ) standardized SSL, that is, RFC2246, and called it TLS (Transport Layer Security). Technically, TLS1.0 and The differences in SSL 3.0 are very minor. Basic principle: First, asymmetric encryption transmits the key used for symmetric encryption, and then both parties use the key to symmetrically encrypt and decrypt the exchanged data.
Requirements: A digital certificate needs to be installed on the server, and the user may need to confirm the certificate. The encryption and decryption process during the session is automatically completed by the browser and the server, which is completely transparent to the user.
Schematic diagram of the SSL handshake phase:
work process:
The browser sends a request to the server to ask the symmetric encryption algorithm and asymmetric encryption algorithm supported by the other party; the server responds to the algorithm it supports. The browser selects an encryption algorithm supported by both parties and requests the server to present its own certificate; the server responds with its own certificate. The browser randomly generates a symmetric encryption key for this session, encrypts the key with the public key attached to the server certificate, and transmits it to the server; the server keeps the symmetric encryption key for this session. The third party does not know the private key of the server and cannot decrypt the data even if it intercepts it. Asymmetric encryption allows any browser to have an encrypted session with the server. The browser uses the symmetric encryption key to encrypt the request message and sends it to the server, and the server uses the symmetric encryption key to decrypt it; the server uses the symmetric encryption key to encrypt the response message and sends it to the browser, and the browser uses the symmetric encryption key. to decrypt. The third party does not know the key of the symmetric encryption, and even if the data is intercepted, it cannot be decrypted. Symmetric encryption increases encryption speed.
HTTPS If we were talking about the HTTPS protocol at the beginning, it would be a big topic, but when we talk about it, we have basically finished all the content about HTTPS, all the security it depends on. The technology is what we mentioned above. As we all know, HTTPS is a network constructed by the SSL+HTTP protocol that can perform encrypted transmission and authentication (to confirm whether the target host connected by the client is a real and correct host). protocol. The security guarantee that https can achieve is exactly the security problem that SSL can solve.
Disadvantages of HTTPS: The main disadvantage of https is performance. There are two reasons why the performance of https is lower than that of http: 1. Encrypting and decrypting data determines that it is slower than http. 2. Another important reason is that https disables caching. Relevant test data shows that the work efficiency of using HTTPS protocol to transmit data is only one tenth of that of using HTTP protocol. Therefore, for a website, only those data with extremely high security requirements will choose to use https for transmission.
Make a centralized illustration of the above knowledge, I believe everyone will have a clearer understanding:
1. Bob has two keys, one is the public key and the other is the private key.
2. Bob gives the public key to his friends—Patty, Doug, Susan—one each.
3. Susan is going to write a confidential letter to Bob. After she writes it, she encrypts it with Bob's public key to achieve the effect of secrecy.
4. After Bob receives the letter, he decrypts it with his private key and sees the content of the letter. It should be emphasized here that as long as Bob's private key is not leaked, the letter is safe and cannot be decrypted even if it falls into the hands of others.
5. Bob writes back to Susan and decides to use a "digital signature". After he finished writing, he used the Hash function to generate a digital digest of the letter.
6. Bob then uses the private key to encrypt this digital digest to generate a "digital signature".
7. Bob attaches this signature to the letter and sends it to Susan together.
8. After Susan receives the letter, she takes off the digital signature and decrypts it with Bob's public key to get the summary of the letter. This proves that the letter is indeed sent by Bob.
9. Susan then uses the Hash function on the letter itself, and compares the result obtained with the summary obtained in the previous step. If the two agree, it proves that the letter has not been revised.
10. A complication arises. Doug wanted to deceive Susan. He secretly used Susan's computer and traded his public key for Bob's public key. At this point, Susan actually had Doug's public key, but thought it was Bob's. So Doug can impersonate Bob, make a "digital signature" with his private key, write to Susan, and ask Susan to decrypt it with the fake Bob's public key.
11. Later, Susan felt something was wrong and found herself unable to determine whether the public key really belonged to Bob. She thought of a way to ask Bob to find a "certificate authority" (CA) to certify the public key. The certificate authority uses its own private key to encrypt Bob's public key and some related information to generate a "Digital Certificate".
12. After Bob gets the digital certificate, he can rest assured. If you write to Susan in the future, you only need to attach the digital certificate when you sign it.
13. After Susan receives the letter, she uses the CA's public key to unlock the digital certificate, and she can get Bob's real public key, and then she can prove whether the "digital signature" is really signed by Bob.
14. Let's look at an example of applying a "digital certificate": https protocol. This protocol is mainly used for web page encryption
15. First, the client makes an encrypted request to the server.
16. After the server encrypts the web page with its own private key, it sends it to the client together with its own digital certificate.
17. The "Certificate Manager" of the client (browser) has a list of "Trusted Root Certification Authorities". Based on this list, the client will check whether the public key for unlocking the digital certificate is in the list.
18. If the URL recorded in the digital certificate is inconsistent with the URL you are browsing, it means that the certificate may be used fraudulently, and the browser will issue a warning.
19. If this digital certificate is not issued by a trusted authority, the browser will issue another warning.
20. If the digital certificate is reliable, the client can use the server public key in the certificate to encrypt the information, and then exchange the encrypted information with the server.
