How SSL works

Disclaimer: Due to my recent interest in security encryption-related technologies, I have translated the working principles of this SSL article. This is a good article. I have introduced the working principle of SSL-Secure Sockets Layer in a simple way. However, due to my encryption knowledge and English proficiency, I feel that translation is poor in many places, but I believe everyone can understand it. :-) The old saying goes, this article welcomes non-commercial reprinting, but please maintain the integrity of the article and indicate the source!

Key password system Introduction

This article explains how Netscape uses RSA's public key cryptography system to achieve Internet security. The implementation of Netscape's Secure Sockets Layer utilizes the technology discussed in this article.

RSA public key cryptography systems are widely used in computer industry authentication and encryption. Netscape is licensed by RSA Data Security to use the public key and password system and other products, especially certification products.

Public key encryption technology uses asymmetric keys for encryption and decryption. Each pair of keys contains a public key and a private key. The public key is public and widely distributed, while the private key is never disclosed, only you know.

Only the private key can decrypt data encrypted with the public key. On the contrary, only the public key can decrypt data encrypted with the private key. This asymmetry makes the public key and password system so useful.

Use the public key and password system for authentication

Authentication is a process of identity authentication. It aims to enable an entity to believe that the other party is the entity he claims. The following examples include Alice and Bob, and demonstrate how to use the public key and password system to easily authenticate an identity. The following {something} key indicates that something has been encrypted or decrypted using the key.

Assume that Alice wants to authenticate Bob, and Bob has a key pair, that is, a public key and a private key. Bob discloses his public key to Alice (his work will be discussed later ). Alice then generates a random message and sends it to Bob.

A --> B random -- message

Bob uses his own private key to encrypt the message, and then returns the encrypted message to Alice .????????

B --> A {random -- message} bobs -- private -- Key

Alice received the message and then decrypted it with the public key sent by Bob. She compares the decrypted message with the original message. If the message matches, she knows that she is communicating with Bob. An attacker should not know Bob's private key, so he cannot properly encrypt the random message that Alice wants to check.

But wait, and there are ......

Unless you know exactly what you are encrypting, it is never a good thing to encrypt something with your private key and then send it to others. This is because the encrypted data may betray you (Remember, only you can encrypt, because only you have a key ).

Therefore, we do not encrypt the original message sent by Alice. Instead, Bob constructs a message digest and encrypts it. A message digest is extracted from a random message in some way and has the following features:

The digest is hard to be reversed. Anyone impersonating Bob cannot get the original message from the Digest.
Counterfeits cannot find different messages with the same digest
Bob can protect himself by using summaries. He first calculates and encrypts the digest of the random message sent to him by Alice, and then returns the encrypted digest to Alice. Alice can calculate the same digest, decrypt Bob's message and then compare it to verify Bob's identity.

A little closer ......

The technology just described is called digital signature. Bob signs the message generated by Alice, which is as dangerous as encrypting the random message generated by Alice. Therefore, our authentication protocols need to be modified more than once. Some (or all) data must be generated by Bob.

A --> B Hello, are you Bob?

B --> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key

When Bob uses this protocol, he knows what messages he sent to Alice, and does not mind signing. He first sent the unencrypted message "Alice, This Is Bob ." Then, the encrypted summary is sent. Alice can easily determine that Bob is Bob, and Bob does not sign anything he does not want to sign.

Distribution Public Key

How can Bob distribute his public key in a trusted manner? Let's assume that the authentication protocol looks like this:

A --> B hello

B --> A Hi, I'm Bob, bobs-public-key

A --> B prove it

B --> A Alice, This Is bob {digest [Alice, This Is Bob]} bobs-private-key

If this protocol is used, anyone can be Bob. All you need is a public key and private key. You and Alice panic to call you Bob, and then you replace Bob's public key with your own public key, then you can prove it by using your private key encryption, so that Alice cannot tell that you are not Bob.

To solve this problem, the Organization for Standardization invented a certificate, which contains the following content:

Name of the Certificate Issuer
Group to which the certificate is sent
Public Key of the topic
Timestamp
The certificate is signed by the private key of the Certificate Issuer. Everyone knows the public key of the certificate issuer (that is, the certificate issuer has a certificate, and so on ). A certificate is a standard method of binding a public key to a name.

By using the certificate technology, everyone can check Bob's certificate to determine whether Bob is forged. If Bob strictly controls his private key and Bob does get his certificate, everything is fine. The following is a compensation agreement:

A --> B hello

B --> A Hi, I'm Bob, bobs-certificate

A --> B prove it

B --> A Alice, This Is bob {digest [Alice, This Is Bob]} bobs-private-key

When Alice receives Bob's first message, she can check the certificate, verify the signature (as above, use digest and public key encryption), and then verify the topic (Bob name) to determine whether Bob is true or not. In this way, she believes that the public key is Bob's public key and asks Bob to prove his identity. Bob re-executes the same process, computes the message digest, and sends the signature to Alice. Alice can use the public key obtained from the certificate to check Bob's message digest to determine Bob's identity.

A bad guy-let's call him Mallet-you can do the following:

A --> M hello

M --> A Hi, I'm Bob, bobs-certificate

A --> M prove it

M --> ????

However, Mallet cannot satisfy Alice in the final message. Mallet does not have Bob's private key, so he cannot construct a message that makes Alice trust Bob.

Exchange secrets

Once Alice authenticates Bob, she can do another thing-she can send a message that only Bob can decode:

A --> B {secret} bobs-public-key

The only way to discover this secret is to use Bob's private key to decrypt the above message. Exchanging the secret is another powerful usage of the public key and password system. Even if the communication between Alice and Bob is monitored, no one except Bob can get the secret.

This technology enhances the security of the Internet. It treats this password as another key, but now it is the key of symmetric cryptographic system algorithms (such as DES, RC4, IDEA ). Alice knows this secret because it was generated before she sent it to Bob. Bob knows this secret because Bob has a private key that can decrypt Alice's message. Because they all know this secret, they can initialize a symmetric cryptographic algorithm and start to transmit messages encrypted with it. The following is the revised Protocol:

A --> B hello

B --> A Hi, I'm Bob, bobs-certificate

A --> B prove it

B --> A Alice, This Is bob {digest [Alice, This Is Bob]} bobs-private-key

A --> B OK bob, here is a secret {secret} bobs-public-key

B --> A {some message} secret-key

The Calculation of secret-key depends on the Protocol definition, but it can be simplified into a copy of secret.

What do you mean?

There are many tricks in the Mallet bag. Although Mallet cannot discover the secrets Alice and Bob exchange, he can intervene and disrupt their conversations. For example, if Mallet is located at Alice and Bob, he can choose to let the majority of messages return and continue to transfer forward without changing, but destroy the special positioning message (this is very easy for him, because he knows the protocol for communication between Alice and Bob ).

A --> M hello

M --> B hello

B --> M Hi, I'm Bob, bobs-certificate

M --> A Hi, I'm Bob, bobs-certificate

A --> M prove it

M --> B prove it

B --> M Alice, This Is bob {digest [Alice, This Is Bob]} bobs-private-key

M --> A Alice, This Is bob {digest [Alice, This Is Bob]} bobs-private-key

A --> M OK bob, here is a secret {secret} bobs-public-key

M --> B OK bob, here is a secret {secret} bobs-public-key

B --> M {some message} secret-key

M --> A Garble [{some message} secret-key]

Mallet keeps the data unchanged until Alice and Bob share a secret. Then, Mallet changes the message sent by Bob to Alice to enter this method. Alice believes in Bob at this time, so she may believe in the changed message and follow it. Note that Mallet does not know this secret-all he can do is destroy the data encrypted with this secret key. He may not be able to use this Protocol to create a valid message, but next time, he may be lucky.

To prevent such damages, Alice and Bob introduce a message authentication code (MAC) in their protocol ). MAC is calculated based on the secret key and transmitted data. The Digest algorithm described above can be used to construct MAC functions that resist Mallet.

MAC: = Digest [some message, secret] ???

Because Mallet does not know the secret key, he cannot calculate the correct value of this abstract. Even if the Mallet randomly changes the message, if the digest data is large, the probability of success is also very small. For example, by using MD5 (a good cryptographic Digest algorithm invented by RSA), Alice and Bob can send 128-bit MAC values together with their messages. In Mallet's guess, the probability of a correct MAC value is 1 out of 18,446,744,073,709,551,616-that is, it never guessed it.

The sample protocol is revised again below:
A --> B hello

B --> A Hi, I'm Bob, bobs-certificate

A --> B prove it

B --> A {digest [Alice, This Is Bob]} bobs-private-key

OK bob, here is a secret {secret} bobs-public-key
{Some message, MAC} secret-key

Mallet is in trouble now. Mallet can change any message, but MAC computing will expose his fraud. Alice and Bob can detect the forged MAC value and stop the session, so Mallet cannot forge Bob's message.

When did this happen?

Last, but it is also important to prevent the Mallet parrot. If Mallet records the session process, although he may not know the session content, he can replay the sessions. In fact, Mallet can do something really refreshing between Alice and Bob. The solution is from the two sides of the session due to random factors.