All that stuff about encryption and certificates

Follow + star mark public number, do not miss the latest articles

[TOC]

When I was doing the smart home project before, every time I encountered the problem of certificate and encryption, I was full of searching information, but because every time I stopped after solving the problem, I did not carry out a complete and systematic combing, so I always felt that I understood these concepts, but I could not say why.

In this article, we will comb through these concepts and related steps to use them. Just like associative memory, many scattered things can not be remembered, but if these things are organized in a specific relationship, then it is very easy to remember.

Play a game: write down these ten things in 1 minute: teacup, monkey, glass, trash can, fishing rod, bird’s nest, monk, car, hospital, water fountain. Here’s a good place to pause and see if your memory isn’t what it used to be.

Let’s try a different way of remembering, and connect these ten things together with any absurd logic, such as: a monkey, holding a teacup in his left hand and a glass in his right, walking toward a trash can. Next to the trash can, see a fishing rod, so it used the fishing rod to poke the bird’s nest in the tree. An egg fell from the nest and hit the monk on the head. He bled and stopped a car to go to the hospital. To the hospital, the monk lost too much blood and was thirsty, just to see a drinking machine.

Does it feel easy to think over the tall tale a few times and then try to say these ten things? And you can’t even remember the wrong order! This is the magic of associative memory.

So learning knowledge is also the truth: scattered knowledge can not be remembered, only combing into a system, the connection between each other and grasp the context, and then to understand these scattered points will be easy to remember. The key here is to master the relationship between these knowledge points, like a net, just pick up a knowledge point, can be based on this net to associate other knowledge points.

The contents of this article include:

How does the Internet of Things cloud platform verify the legitimacy of the device side? What is SSL/TLS? What does it do? In what situations? What is OpenSSL? How does it relate to SSL? What is OpenSSH? How is it different from OpenSSL? How is SSL used to exchange secret keys in HTTPS? What are the handshake steps? What is the certificate? What does it do? In what situations? How is the certificate obtained? What is its standard format? What does it include? What is the certification body? What is a chain certificate? How does a certificate relate to SSL? What does a signature mean? What is the relationship with encryption? What is one-way authentication? Two-way authentication?

One more thing: this article only describes the “what”, not the “why”. The “why” is left to the mathematicians and cryptographers.

A typical Iot product

In actual projects, if the cloud platform is used, generally speaking, there are only a few options: amazon is used in foreign countries, Ali Cloud is used in China, and Huawei Cloud is also used in some projects recently. Here is an example of an air purifier project I have done before:

First, Amazon provides an SDK that includes a set of API functions that applications can call to secure connections and send and receive data to the cloud platform. The device certificate file is the most important of the necessary device information that must be provided when the API function is called. That is, the certificate must be stored in the device’s file system.

So, when was the certificate put into the air purifier device? Production, of course. Look at this process:

The production tool software runs on a PC on the production line, connects to the air purifier through a serial port, and reads a unique identification number (such as a MAC address) from the device.

The production tool software upload necessary information (such as the basic information of the manufacturer, the secret key of the manufacturer, and the unique identification code of the air cleaning device) to the AWS cloud platform to obtain a certificate file.

The AWS cloud platform generates a certificate file based on the pre-deployed program on the platform and returns it to the production tool software.

The production tool software sends the certificate file to the air purifier through the serial port.

After receiving the certificate file, the air purifier device stores it in the local file system.

The above process is completed in the process of equipment production. The description here is still in broad strokes. Other important information is not listed, such as: How the AWS backend generates certificates, how the backend validates the validity of devices using certificates during the connection phase, and how the vendor’s secret keys work will become clear at the end of this article.

In the following, according to the relationship between these concepts to step by step, each concept is introduced in accordance with the relationship between each other, so it is recommended to understand in order.

Data encryption

Disadvantages of plaintext transmission

We know that the data transmitted between the client and server is either in plain text or encrypted. The disadvantages of plaintext transmission are obvious:

Data is easier to intercept than third parties; Third parties can tamper with the data; Third parties may pose as servers to communicate with you.

In short: plaintext communication is like streaks, everything is clearly seen by others, malicious third parties can easily use plaintext communication to do some illegal things.

So, it’s better to wear clothes, preferably with a combination lock, so that people can’t see! This is encrypted transmission.

The encrypted

The client encrypts the transmitted information, and the server decrypts the ciphertext after receiving it. For example, in the picture above:

If the client wants to send the string “hello”, it encrypts it to “ifMmp” and sends it. The server receives “ifMmp”, decrypts it, and gets “Hello”.

However, the encryption method in the example is too stupid, a little research will make it clear that the encryption method here is to change each character in the plaintext string into the next word in the ascII code table. When decrypting, the server does the opposite: each character is changed to the previous character in the ascII code table, as long as the client and server have agreed on such encryption and decryption algorithms in advance.

However, this encryption method is too simple to be broken by a malicious third party without any effort. Therefore, a more complex encryption algorithm is needed between the client and server. This is the problem SSL solves, which will be discussed later.

encryption

According to whether ciphertext can be restored to plain text, there are two types of encryption methods:

Reversible encryption; Irreversible encryption.

The encryption and decryption process (“hello”->”ifmmp”->”hello”) described above is reversible encryption, which means that ciphertext can be restored to plain text. It is mainly used in communication scenarios. If a ciphertext cannot be restored to plaintext, it is called irreversible encryption, and irreversible encryption is also very important.

Reversible encryption

As we have just said, reversible encryption is the ciphertext can be restored to plain text, as long as the client and server to discuss the encryption algorithm (such as the use of the ascII table of the next character) can achieve the purpose, that is: The encryption algorithm on the client side is the same as the decryption algorithm on the server side, but the algorithm here is too simple.

We can make it a little more complicated by defining a fixed string “258” and then counting each character in the plaintext “hello” as a fixed string: First add 2, then subtract 5, and finally add 8 to get the encrypted string “MJQQT”. After receiving the string, the server performs the reverse operation to decrypt it and get the plaintext “Hello”. From an algorithmic point of view, the two encryption methods are identical, but the second algorithm makes use of a single, fixed string “258”, which is called the secret key, although the secret key used in actual communication is, of course, more complex. The communication parties use algorithms and secret keys to encrypt and decrypt. In addition, both parties to the communication use the same secret key, which is called symmetric encryption.

Since there is symmetric encryption, there must be asymmetric encryption. That is to say, according to whether the secret keys used by the communication parties are the same, reversible encryption can be divided into two types:

Symmetric encryption;

Asymmetric encryption.

The common symmetric encryption algorithms are: DES, AES; The common algorithms of asymmetric encryption are RSA, DH, and ECC.

Features of symmetric encryption:

Fast calculation speed;

High encryption strength;

A large amount of data can be processed.

Features of asymmetric encryption:

The efficiency is low;

There are limits to the amount of data that can be processed.

Since the disadvantages of asymmetric encryption are so obvious, what does it do?

Back to the communication example scenario: Client and server need to use the same key “258”, so how do they negotiate for the symmetric key? Is it a fixed secret key? Obviously, this answer is unlikely because there are so many devices to communicate with, it can’t be preallocated like the MAC address of a network card, and the secret key can easily be leaked. Therefore, the symmetric secret key is usually obtained through dynamic negotiation between the client and server in the initial handshake phase of communication. In order to prevent the negotiation content from being intercepted by the third party, asymmetric encryption is needed to ensure the data security in the handshake phase.

Since the handshake data only happens at the beginning of the communication, it doesn’t matter if it’s a little inefficient. Security is more important than efficiency.

In short, asymmetric encryption is used in the initial phase of communication during the negotiation process to obtain a symmetric secret key. This negotiation process is called the handshake, and we will look at the handshake process in detail later in HTTPS communication.

Irreversible encryption

As the name suggests, irreversible encryption means that the plaintext is encrypted after the ciphertext, but can not be restored from the ciphertext plaintext. In technical terms, the result of this encryption is generally not referred to as ciphertext, but as a digest or fingerprint.

Irreversible encryption principle: an arbitrary size of data, after a certain algorithm, into a specified length of output. If the content of the data has changed by the slightest trace, encrypting it again yields a different result, and a very different one. From this point of view, wouldn’t it be better to call it a fingerprint?

The most commonly used algorithms for irreversible encryption are MD5 and SHA1.

Recall that when we download some software, we usually see the MD5 code of the software on the server in addition to the download location of the software. After downloading the software to the local, we calculate the MD5, which is the fingerprint of the file, and then compare the MD5 with the MD5 published on the server. If the two MD5s are inconsistent, it means that the downloaded file has been modified by others.

Here is the download page for the Glib library:

Supplement: SHA related knowledge

SHA

SHA security hash algorithm, a set of encryption functions published by the National Institute of Standards and Technology. It is a commonly used summary algorithm, is input a piece of data, output a legal certificate summary information, including SHA0, SHA1, SHA2 and other different versions.

SHA1

Represents secure hash algorithm 1, which receives input and outputs a 160-bit hash value called the message digest. After 2005, SHA1 was deemed unsafe.

SHA2

SHA2 refers to a family of similar hash functions with two different block sizes, including SHA256 and SHA512. SHA256 can output a 256-bit hash value, which is more secure.

A practical usage scenario: OTA upgrades

First, the server sends a string in the format of upgrade. json to the device. The file includes: URL of the download address of the new firmware, MD5 value of the new firmware.

The device downloads the new firmware to the local device according to the URL.

The device calculates the MD5 value of the downloaded new firmware and compares it with the MD5 value in upgrade.json.

If the two MD5 values are the same, the downloaded firmware is fine and the upgrade begins.

To understand the characteristics of irreversible encryption:

Irreversibility: in principle, there is no algorithm to infer the original text from the ciphertext except by exhaustive means.

Avalanche effect: sensitive to input data, small changes to the original data will cause huge differences in the output fingerprint;

Collision prevention: It is difficult to find two different pieces of data and output the same fingerprint.

Public and private keys

With asymmetric encryption mentioned above, private and public keys must be added. They are both secret keys and must be used in pairs. This is called a secret key pair. We can generate our own public and private keys using software tools such as OpenSSL.

Public key: that which is publicly disclosed to others; Private key: it is your own. Keep it as your treasure and never tell anyone.

Public and private keys have two functions:

Data encryption: Public key encryption and private key decryption, used in communication scenarios.

Digital signature: private key encryption, public key decryption, used in non-fiduciary scenarios.

Data encryption is the asymmetric encryption described above, for example:

John wants to send a file to me. In order to prevent the file from being seen by others, He encrypts the file with my public key and then sends the encrypted file to me. After I get the ciphertext, I can use my private key to restore the ciphertext to the original file. Even if others get the ciphertext, they cannot unlock the file without my private key. Here’s the picture:

Digital signature and the signature on the IOUS in our daily life are similar, once signed, have legal effect, cannot play depend on to say: this is not my signature, I do not recognize. The specific process is: I write a file, and then use my private key to encrypt the file, so if I later cheat: this file is not written by me, others can use my public key to try to decrypt the encrypted file. If it succeeds, it means the file must have been encrypted with my private key, which only I have, which means it must have been written by me. The diagram below:

certificate

As mentioned above, the public key is disclosed to others, which is essentially a piece of data. Then in what form or in what carrier is the data sent to others? The answer is: certificates.

How to Apply for a Certificate

Let’s take a website for example. When the browser visits the website, the website sends its certificate to the browser during the handshake phase. So how did this certificate come about?

Step1 At the beginning of the website, you need to put your relevant information in a request file (server.req), and send the request file to an authoritative certification authority. The contents of the request file include:

Website for domain name applicant information public key and other related information

Step2 certification agencies through other ways to determine the applicant is legitimate.

Step3 the certification authority uses an algorithm to calculate the information in the request file server.req and get a digital summary.

Algorithms include:

MD5

SHA-1

SHA-256

The information includes:

Basic information about the applicant: Encryption algorithm and hash algorithm used by the website; The applicant’s public key; Information about the certification authority: Name of the certification authority and expiration time of the certificate.

The Step4 certification authority encrypts the digital digest obtained in Step3 with its own private key to obtain the digital signature (also the certificate signature).

Step5 the certification body will summarize the above information, get the final certificate file server. CRT, and then send it to the applicant.

Finally, the content in the certificate server.crt includes these broad categories:

Basic information about the applicant: Encryption algorithm and hash algorithm used by the website;

The applicant’s public key;

Information about the certification authority: Name of the certification authority and expiration time of the certificate.

Certificate signature of certification authority.

How do I verify the validity of a certificate

Now that the client has received the certificate file from the server, how do you verify that it is a valid certificate?

Step1 read the plaintext information in the certificate, including the basic information about the applicant, the public key of the applicant, and the information about the certification authority.

Step2 find the relevant information of the certification authority from the browser or operating system to obtain the public key of the certification authority.

Supplement: The browser or operating system usually has a list of trusted cas certificates installed, so you can get the cas public key.

Step3 use the same algorithm of the certification authority to calculate the plaintext information in Step1 and get abstract 1.

Step4 use the public key of the certification authority to decrypt the digital signature of the certification authority in the certificate, and get abstract 2.

Step5 compare summary 1 and summary 2 to see if they are the same. If they are the same, the certificate is valid, which proves that the current access is a legitimate server.

One-way authentication and two-way authentication

The authentication process described above is used by the browser to verify that the visited site is a legitimate site; In the example given at the beginning of this article, when an Internet of Things product connects to a cloud platform, the cloud platform verifies that the device it wants to connect to is a legitimate device.

In both scenarios, one-way authentication is used, in which one side of the communication verifies that the other is legitimate. Two-way authentication makes sense: each side of the communication has to authenticate the other.

The choice of one-way or two-way authentication, or even no certificate (using only the user name and password for authentication), depends on the actual usage scenario, security level, and operation difficulty. For example, in the Internet of Things products, each product needs to burn the dynamically generated certificates into the equipment in the production stage, which increases the process and cost of the production link. In order to security, we must not be lazy. Without a certificate to verify it, hackers can simulate countless devices and frequently connect to the cloud platform, which poses a huge security risk.

The certification body

A certificate is essentially a file, but it has a special property: it can be proved to be legitimate. So how do you prove that? This brings us to certification bodies.

CA: Certificate Authority (CA: Certificate Authority) is an authoritative organization, is the Authority structure recognized by the country, the industry, not just any organization is qualified to issue certificates, otherwise it is not called an Authority. A certificate is considered legitimate as long as it can be proved that it was issued by the CA authority. In other words, the credibility of the certificate depends on the trust mechanism.

Just like the bank lending to an individual, the bank will check the credit report of the person in the credit investigation system before making the loan. If the credit investigation system indicates that the person’s credit is ok, the bank trusts the credit investigation system, so the bank trusts the person and can lend to him. This is the transmission of a trust chain.

The CA certification body is similar to the credit investigation system, which is equivalent to the CA structure endorsing the certificate. It guarantees that the certificate issued by it is legal and valid. So as long as we can prove that the certificate is issued by the CA certification body, we can think that the certificate is valid.

The certificate chain

The CA certification authority is a tree-like structure, with the root certification authority at the top. Below are: level 2 certification bodies, level 3 certification bodies… .

The root certification body issues certificates to the secondary certification body, and the secondary certification body issues certificates to the tertiary certification structure… . Different levels of certification bodies have different requirements for audit, so certificates are divided into free, cheap and expensive.

You may ask: Then who signed the certificate of the root certification authority? The answer is: the root certification authority itself, which is also called self-signing. Because the root certification body is recognized by the country or industry organization, it is already a reliable authority, so you can sign for yourself.

In addition, we often use programs provided in OpenSSL to generate self-signed certificates in our testing process. Of course, the self-signed certificates for this test can only be played by you, because people don’t trust you.

Extension name of the certificate file

New to the concept of a certificate of small partners, often confused by the dazzling suffix.

First of all, be clear: The suffix name of the certificate file is just for the sake of meaning, in fact, you can choose any name. Common suffix names include:

Key: private key in pem format. Pub: public key in pem format. Req: request file sent to the CA when applying for a certificate

Format of the certificate file

There are two types of certificate content formats: PEM and DER. The two types of certificate files can be converted to each other by using programs in OpenSSL.

PEM format (Privacy Enhanced Mail)

A certificate in pem format is an encrypted text file, usually in base64 format. You can use a notebook to open a base64 certificate. For example, the following certificate file contains the following contents:

Supplementary: Base64 algorithm is to split the original data into three bytes, three bytes are 24 bits, and then divide the 24 bits into four groups of six bits, and finally add two zeros to each signature of six bits, so that the four groups of bytecode can be represented by ascII code.

DER Format (Distinguished Encoding Rules)

The content of a certificate file in DER format is encrypted binary data, that is, garbled characters are displayed after the file is opened.

X. 509 standard

As mentioned above, the certificate contains the necessary information, so the information is not randomly placed in the file, but stored in a fixed format that can only be generated or parsed by the software. So who defines this fixed format? This is the X.509 standard and public key certificate.

X.509 is a system and standard that specifies the certificate format standard. The CA authentication structure writes all the information in the certificate file according to the standard when generating certificates.

X.509 comes in three versions: V1, V2, and V3. The certificate issued in each version must contain the following information:

Version number: Used to distinguish versions; Series number: A unique number is assigned to each certificate by the CA certification authority. Algorithm signature identifier: Specifies the signature algorithm used by the CA to issue certificates. Certification body: The unique name of the certification body; Validity period: The validity period (start time and end time) of the certificate. Subject information: Basic information about the certificate holder. Public key information: the public key of the certificate holder; Authentication structure signature: to ensure that the certificate has not been tampered with since it was issued;

Certificate format

In short: the core function of a certificate is to securely transfer a public key!

OpenPGP protocol/standard

After introducing the concepts of encryption and certificates, let’s learn about an industry standard: OpenPGP.

What is OpenPGP?

OpenPGP is a non-proprietary protocol that defines a uniform standard for encrypting messages, signatures, private keys, and certificates used to exchange public keys.

Implementation of OpenPGP protocol

The OpenPGP protocol has two implementations:

PGP(Pretty Good Privacy)

GPG(GNU Privacy Guard)

PGP is an encryption program that provides encryption and validation capabilities for data communications, typically used to sign, encrypt, and decrypt text, E-mail, and files.

GPG is an open source implementation of PGP.

This section describes the OpenPGP usage process

Everyone uploads their public key to the public key server (subkeys.pgp.net), and through an exchange mechanism, all the public key servers will eventually contain your public key, just as a DNS server synchronizes resolution information.

Since the public key server has no checking mechanism and anyone can upload a public key in my name, there is no way to guarantee that the public key on the server is reliable. Usually, I can publish a public key fingerprint on a website, have other people download my public key, calculate the public key fingerprint, and then compare it with my published fingerprint to verify the validity of the certificate.

Step2: obtain the public key of another person in order to obtain the public key of another person, you can ask the other person to directly send it to me or download it from the public key server. For security purposes, the downloaded public key needs to be securely authenticated using some other mechanism, such as the fingerprint mentioned earlier.

Step3: Used for encryption Encrypts the file with the public key of the other party and sends it to the other party. The other party decrypts the file with its own private key.

Step4: For signature, encrypt the encrypted file with my private key, and send the encrypted file to the other party. The other party uses my public key to decrypt the file. As long as it can be decrypted correctly, it can prove that the file is indeed encrypted by me.

SSL/TLS

SSL is Secure Socket Layer. It is a security protocol designed to provide Secure data transmission over the Internet.

As SSL works, it leverages the concepts described earlier: symmetric encryption, asymmetric encryption, certificates, and so on. If the previous concepts are clear, understanding SSL should not be a problem.

The SSL protocol has three versions: 1, 2, and 3. TLS is a product of the STANDARDIZATION of SSL V3. In fact, today’s TLS is used, but everyone is used to SSL.

Protocol layer

The biggest advantage of SSL is that it is independent of the application layer. On the upper layer of SSL, some high-level application protocols, such as HTTP, FTP, TELNET, etc. That is, these high-level protocols can be transparently built on top of the SSL protocol layer.

handshake

SSL uses the X.509 standard. Handshake refers to the authentication and negotiation between the client and the server at the beginning of the communication. The final goal is:

Verify that the other party is a legitimate communication object.

Negotiate with the other party to obtain the symmetric encryption key.

Let’s go through the process step by step:

Step1 the Client sends the following information to the Server:

Random number 1; SSL version supported by the Client. List of encryption algorithms supported by the Client.

Step2 Server analyzes the received information and returns the following information to Client:

Random number 2; Selected encryption algorithm; The Server certificate

Step3 the Client verifies whether the certificate sent by the Server is valid. The specific process has been described above.

If the authentication fails, the communication ends. If the verification is successful, the random number 3 is generated, and the random number 1 and 2 are used. Then the selected algorithm is used to generate a symmetric encryption key, which is used for normal data communication.

Then send the following information to the Server:

Random number 3, and using the public key in the server certificate for encryption;

At this point, the Cliend end handshake process is over, because the final purpose of the handshake has been achieved: to confirm that the Server is legal and get the symmetric encryption key.

Step4 when receiving the encrypted random number 3, the Server uses its own private key to decrypt it, and then uses the same algorithm to generate the symmetric encryption secret key together with the previous random number 1 and 2.

At this point, the server-side handshake is over and the data can be encrypted using the symmetric encryption key.

Note: The handshake described above is one-way authentication, with the Client verifying that the Server is valid. If two-way authentication is required, the client should also send its certificate to the Server, which then verifies that the certificate is valid before continuing the handshake process.

Relationship between HTTPS and SSL

After the browser is connected to the server, the SSL handshake process described above is performed. At the end of the handshake, the two parties receive the symmetric encryption key. In the VIEW of THE HTTP protocol, the data is transmitted in plain text. The SSL layer below encrypts and decrypts the data.

OpenSSL

What is OpenSSL?

So much of SSL described above is a protocol (or standard) that specifies what should be done, but who should do the actual code implementation? It seems that we have never implemented this protocol when we write SSL programs, and we call the libraries provided by third parties directly to achieve the purpose of encrypted transmission. Of course, if you have implemented SSL protocol, please allow me to express my admiration to you, give you ten thousand praise!

In programming, there will always be warm-hearted people! OpenSSL is a free SSL/TLS implementation. OpenSSL implements all of the functions defined in the SSL/TLS protocol, including:

SSL2

SSL3

TLSv1

TLSv1.1

TLSv1.2

Moreover, OpenSSL is developed in C language and has excellent cross-platform features, which can be executed on Linux, Windows, BSD, MAC and other platforms.

Specifically, the OpenSSL implementation includes the following functional modules:

Cryptographic library

The cryptographic library includes:

Symmetric encryption algorithms: AES, DES, etc. Asymmetric encryption algorithms include DH, RSA, DSA, and EC.

Information summarization algorithm

Information digest algorithms include MD5 and SHA.

Key and certificate management

The CA application provided by OpenSSL is a small certificate management center, which implements the whole process of certificate issuing and most of the mechanism of certificate management. We usually use the CA program provided by OpenSSL to generate secret key pairs, self-signing, and so on. Specific contents include:

Certificate key generation, request generation, certificate issuance, revocation, and authentication functions; For x.509 standard certificate decoding, PKCS#12/PKCS#7 format codec; Provides functions to generate various secret key pairs;

The SSL protocol library

Implement THE protocols SSLv2, SSLv3 and TLSv1.0.

The application

OpenSSL application is based on the password algorithm library and SSL protocol library implementation, is a very good example of OpenSSL API functions, including: key generation, certificate management, format conversion, data encryption and signature, SSL testing and other auxiliary configuration functions.

What is OpenSSH?

SSH

Let’s start with SSH: Secure Shell, another protocol for logging into a system remotely. We usually use SSH to transmit command-line interfaces and execute commands remotely.

For example, when debugging an ARM system, you can connect to the ARM board through the serial port assistant. However, a more common debugging scenario is to remotely log in to the ARM system on a PC and execute any instruction in ARM, which is achieved by using SSH.

SSH provides two levels of security authentication:

Based on password; Based on the secret key.

Password-based security authentication in SSH

You only need to know your account and password to remotely log in to the system, and that’s the way we usually use it. However, there is no guarantee that the device I am connecting to is the one I want to connect to. There may be another server posing as the real server, which is a “man in the middle” attack.

Of course, we often encounter another kind of error: in the LAN, there are multiple devices, the attempt to connect to the remote device A, because the IP address is wrong, as A result, the remote login to another device B, if your colleague is debugging device B, the next tragic moment!

Key – based security authentication in SSH

Step1 first create a secret key pair for yourself, and put the public key on the server that you need to access in advance, for example, put it in the home directory of the account.

Step2 log in to the server remotely from the client, send the public key to the server, and ask the server to perform security verification.

Step3 after receiving the request, the server searches for the public key in the home directory of the login account, and then compares it with the received public key.

Step4 if the comparison is inconsistent, the communication ends; If they match, the server encrypts a data challenge using the public key and sends it to the client.

Step5 the client receives the challenge, decrypts it with the private key, and sends the result to the server.

The server in Step6 compares the received results with the data in Step4. If the results are consistent, the verification is passed.

The implementation of SSH protocol

Since SSH is a protocol, there must be an implementation, and this is OpenSSH, which is a free and open source SSH implementation.

The OpenSSH implementation makes use of the encryption and algorithm library functions in OpenSSL, and this is the relationship between the two.

conclusion

Here, and encryption, certificate related basic concepts are introduced, do not know whether you have a harvest.

If you’re new to these things, rest assured that even if you understand them now, you’ll have forgotten more than half of them a week from now. Only after experiencing the experience of several projects, can we have a deeper understanding and memory. Finally, I wish you good luck!

If you think the article is good, please forward, share to your friends. I will summarize and share my practical experience in embedded development projects for more than 10 years. I believe you will not be disappointed!