SSL/TLS protocol for vehicle networking communication security

foreword

In today's increasingly intelligent car travel, we can realize the remote control of the mobile phone to unlock the vehicle, start the ventilation, and view the surrounding images of the vehicle. We can also upgrade the vehicle firmware and update the map package through OTA (over-the-air download technology). It also allows the vehicle to automatically assist in steering, acceleration and braking according to road conditions.

However, every feature that enhances our experience has the potential to become a fatal security hole. Tencent Security Cohen Lab has disclosed and demonstrated to the outside world how to use 3/4G network or WiFi network to invade smart cars without physical contact remotely, and realize remote control of vehicle lights, displays, door locks and even brakes . Not only that, attackers can even exploit a known vulnerability to gain Autopilot control of a smart car and manipulate the direction of the vehicle.

Therefore, we should also fully recognize the importance of communication security, identity authentication, and data security when building the Internet of Vehicles platform, and correctly use relevant encryption authentication and other technical means to provide protection.

In this article, we will comprehensively introduce the application of the SSL/TLS protocol in the communication security of the Internet of Vehicles, hoping to give everyone a clearer and intuitive understanding of the role of SSL/TLS. In addition, we will also explain in detail how to configure SSL/TLS to ensure that you can use SSL/TLS correctly and achieve security.

Internet of Vehicles Safety Communication MQTTS Protocol

The MQTTS protocol encapsulates a layer of encryption protocol based on SSL/TLS ( Transport Layer Security) on the basis of the MQTT protocol , which ensures that the communication between the vehicle terminal and the vehicle networking platform is encrypted. However, if SSL/TLS is not properly configured, there will still be many security risks. To really use SSL/TLS well, we must understand what problems SSL/TLS solves and have a preliminary understanding of the cryptographic techniques used by SSL/TLS.

Typically, a communication process needs to have the following four properties to be considered secure: confidentiality, integrity, authentication, and non-repudiation.

confidentiality

Confidentiality is the foundation of secure communication. Without confidentiality, anyone who eavesdrops on the communication can easily obtain your key private information such as login password and payment password. The most common method to achieve confidentiality is encryption, so that the eavesdropper can only get a meaningless string of encrypted data, and only the person who holds the key can restore the ciphertext to the correct original information. According to the method of using the key, encryption methods can be divided into two types: symmetric encryption and asymmetric encryption. Symmetric encryption means using the same key for encryption and decryption, while asymmetric encryption means using different keys for encryption and decryption.

Symmetric encryption Since both parties use the same key for encryption and decryption, they will inevitably encounter the problem of key distribution, that is, if I need the other party to be able to decrypt the ciphertext I sent in the past, I must use the key I used for encryption. tell the other party, but how can I ensure that the key is not leaked during the synchronization of the key with the other party? This is the key distribution problem for symmetric encryption.

A common solution today is to use asymmetric encryption and use the Diffie-Hellman key exchange algorithm. The core of asymmetric encryption is to generate a pair of keys, one is the public key and the other is the private key. The public key is used for encryption. It is public and can be distributed to anyone. The private key is used for decryption and does not participate in the communication process. , which needs to be properly kept, thus solving the key distribution problem. The core idea of the Diffie-Hellman key exchange algorithm is that the two communicating parties can calculate the same shared key by exchanging some public information, but the eavesdropper cannot calculate the same key after obtaining the public information. One advantage of the Diffie-Hellman algorithm is that there is no performance problem of asymmetric encryption. Although asymmetric encryption solves the problem of key distribution, the operation speed of asymmetric encryption algorithms is far less than that of symmetric encryption algorithms, and they can even be hundreds of times faster. gap. Although security is ensured, it seriously affects the efficiency of communication and loses practicability. Therefore, in practical applications, symmetric encryption and asymmetric encryption are usually used in combination, that is, after using a pseudo-random number generator to generate a session key, encrypt it with the public key and send it to the other party. The session key, which will be used exclusively for subsequent communications. This not only solves the key distribution problem, but also solves the performance problem caused by asymmetric encryption, which is often called hybrid encryption.

integrity

Confidentiality alone is not enough to achieve secure communication. An attacker can still tamper or forge the content of the ciphertext, and the receiver can neither judge whether the ciphertext is from the correct sender nor whether the decrypted plaintext is untampered. of. Although it is more difficult to tamper with the encrypted ciphertext, for example, the data structure of the plaintext after tampering is likely to be damaged, and the receiver can easily reject the plaintext in this case. However, there is still a probability that the value of some fields with random attributes in the decrypted plaintext message will change after tampering. For example, the value of the motor speed field has changed from 500 to 718, which is nothing more than a change of a few bits. If the receiver accepts these messages normally, it may bring unexpected hidden dangers.

Therefore, we also need to further ensure the integrity of information on the basis of confidentiality. A common practice is to use a one-way hash function to calculate the hash value of the message, and then send the message along with the hash value to the recipient. A one-way hash function ensures that even a 1-bit change in a message has a high probability of producing a different hash value. In this way, the receiver can calculate the hash value of the message, and then compare the received hash value to determine whether the data has been tampered with.

Authentication

But unfortunately, when the attacker forges the message and the corresponding hash value at the same time, the receiver still cannot see through the forgery. Therefore, we not only need to confirm the integrity of the message, but also whether the message is from a legitimate sender, which means that the identity needs to be authenticated. At this time, we need to use the message authentication code. The message authentication code is still based on the one-way hash function, but its input includes a key shared between the sender and the receiver in addition to the original message. Since the message authentication code itself does not provide the guarantee of message confidentiality, in actual use, symmetric encryption is usually used in combination with the message authentication code to meet the requirements of confidentiality, integrity and authentication at the same time. This mechanism is also used. It is called Authenticated Encryption (AEAD). Specifically how to use, the following solutions have been produced:

1. Encrypt and MAC: First encrypt the plaintext with a symmetric cipher, then calculate the MAC value of the plaintext, and finally combine the two and send it to the receiver.
2. MAC then Encrypt: Calculate the MAC value of the plaintext first, then encrypt the plaintext and MAC value with a symmetric cipher at the same time, and send the encrypted ciphertext to the receiver.
3. Encrypt then MAC: First encrypt the plaintext with a symmetric cipher, then calculate the MAC value of the ciphertext, and finally combine the two and send it to the receiver.

For a long time, SSL/TLS has adopted the second scheme, but in fact the above three schemes have been verified as security vulnerabilities one after another. Both POODLE and Lucky 13 attacks in the history of SSL/TLS were implemented for vulnerabilities in the MAC then Encrypt scheme. The current security solution recommended by the industry is to use the AEAD algorithm. In SSL/TLS 1.3 version, other encryption methods are officially abolished, and only AEAD encryption is supported.

undeniable

Now, we have guaranteed the confidentiality of the message, and can also identify forgery and tampering, but since the core of the message authentication code is that the two parties of the communication need to share the key, it has caused a new problem, that is, it is impossible to prove to a third party and Denial cannot be prevented. Assuming that Bob receives the message from Alice, and wants to prove to the third party that the message is indeed sent by Alice, he needs to tell the third party the key that only two people know, which obviously will increase the subsequent use of this key. Communication security risks. At the same time, even if a third party gets the key, it cannot draw valid conclusions. For example, Bob can claim that this message was constructed by Alice, because Alice also holds the same key.

Therefore, we also need to introduce a digital signature mechanism, which works much like asymmetric secrets, but just the opposite. Digital signature requires the sender to sign the message with the private key, and then send the message together with the signature to the receiver, and the receiver uses the corresponding public key to verify the signature to confirm that the signature comes from the legitimate sender. Since only the person holding the private key can impose the correct signature, there is no way for the sender to deny it. The public key is only used to verify the signature, so it can be distributed to anyone at will. Sensitive readers may have some doubts here. Yes, how can the person who obtained the public key confirm that the public key is indeed from the intended communication partner? If the attacker pretends to be the sender and gives the receiver his public key, he can complete the attack without breaking the digital signature algorithm.

We've fallen into an infinite loop where digital signatures are used to identify messages for tampering, spoofing, and denial, but before that we have to get an untampered public key from a sender that hasn't been spoofed. At this point, we can only use the help of external forces to entrust a recognized trusted third party, which is what we often call a certification authority or CA, to apply a signature to each public key to form a public key certificate. Obviously, certification authorities need to work hard to ensure that their private keys are not stolen in order to ensure the validity of digital signatures. Although the private key of the certification authority still has the probability of leakage, and even the certification authority itself may be disguised by the attacker, we still cannot obtain absolute security, but trusting several known certification agencies in advance is always better than from a brand-new communication object It is much more reliable to obtain and trust his public key.

These cryptographic techniques together constitute the cornerstone of modern secure communications. As the most widely used cryptographic communication method in the world, SSL/TLS comprehensively uses the aforementioned cryptographic techniques such as symmetric encryption, asymmetric encryption, message authentication code, digital signature, and pseudo-random number generator to provide communication security. Assure. Considering that cryptography technology is constantly advancing and developing, or that currently seemingly reliable encryption algorithms may be announced to be broken the next day, SSL/TLS does not force the use of a certain cryptographic technology, but provides Cipher Suite is a mechanism, when a certain cipher technology is found to be weak, it can be replaced like a part at any time, of course, the premise is that the client and the server use the same cipher technology. This also extends the SSL/TLS handshake protocol, and the cipher suite used for negotiation is one of the main tasks of this part of the protocol.

If you want SSL/TLS to have good security, you need to avoid using encryption algorithms that have been compromised or verified as weak security, avoid using easily predictable pseudo-random number generators, and try to ensure that each algorithm has similar security (short board effect).

Therefore, how to choose the cipher suite correctly has also become an important part of ensuring security. Here, I will also make a simple arrangement of the currently recommended cryptographic techniques and encryption algorithms, hoping to help readers find and fill in the gaps:

• Among the symmetric encryption algorithms, RC4, DES, and 3DES have all been considered insecure. Currently, only AES and ChaCha20 are recommended. ChaCha20 is an encryption algorithm designed by Google. If the CPU or software does not support the AES instruction set, ChaCha20 can provide better performance than AES.
• Symmetric encryption algorithms such as AES can only encrypt plaintext of a fixed length. If you want to encrypt plaintext of any length, you also need to use the grouping mode. Early grouping modes such as ECB, CBC, CFB, and OFB have been identified as having security vulnerabilities. Currently, GCM, CCM and Poly1305 are recommended.
• Commonly used asymmetric encryption algorithms include DH, RSA, and ECC. Since DH and RSA do not have forward security, they are not recommended at present. In TLS 1.3, the DH and RSA algorithms are directly abolished, and replaced by the ECC algorithm whose security strength and performance are significantly better than RSA. It has two A sub-algorithm, ECDHE is used for key exchange, and ECDSA is used for digital signature. However, it should be noted that since ECDHE/DHE does not provide authentication, the server should enable the verification of the client certificate.
• In terms of hashing algorithms, the well-known MD5 and SHA-1 have been identified as no longer reliable and are not recommended for continued use. Currently SHA256 or higher is generally recommended.

After understanding the recommended cipher techniques, maybe we want to modify the cipher suite configuration on the client or server side, but at this time we may find the names of these cipher suites a bit difficult to understand. For example, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, in which TLS only represents the protocol, ECDHE represents the key exchange algorithm, ECDSA represents the identity authentication algorithm, AES_256_CBC represents the batch encryption algorithm, and SHA384 represents the message authentication code MAC algorithm. This is usually the naming format for cipher suites in TLS 1.2, and has changed a bit in TLS 1.3. Since TLS 1.3 only accepts the ECDHE algorithm for key exchange and uses ECDSA for authentication, its cipher suite name can be reduced to the format TLS_AES_256_GCM_SHA384.

If only from a security point of view, I personally recommend using TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 and TLS_AES_256_GCM_SHA384. However, considering that there are still many certificates issued by RSA in use, we also need to choose whether to continue to use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 according to our own situation.

Building a typical architecture of a security certification system

Adopting a digital certificate system based on PKI/CA is a key step in solving the security of the Internet of Vehicles, and it is also a typical security management system for most car companies. Its main design ideas are as follows:

1. Identity based on digital certificate: Establish strict certificate management and usage specifications through the PKI/CA system, issue digital certificates for applications and terminals of the Internet of Vehicles, bind virtual identities and real identities, and solve the problems of identity and uniqueness (can Realize one machine, one password or one type, one password);
2. When all data is exchanged, the authenticity of the identity is proved by the unique identification of the terminal to prevent malicious intrusion by third parties;
3. Based on the digital certificate security function, it provides various functions such as identity authentication, identity authentication, data encryption and decryption, digital signature and signature verification, etc., to meet the multi-service security requirements of TSP and OTA in the Internet of Vehicles.

The security communication interaction process of the Internet of Vehicles platform is generally to apply for a terminal certificate from the vehicle terminal, download and complete the installation, and request to establish a secure connection with the cloud platform through the MQTTS security protocol. In the cloud, we can choose the load balancing product of the cloud manufacturer, the LB layer built on the basis of Nginx/HAProxy, or the MQTT Broker layer for authentication and authentication. /SN and other information is uniquely authenticated by calling the PKI/CA unified authentication interface to achieve one-machine, one-key or one-type, one-key security authentication.

The configuration method of single and two-way authentication in MQTTS communication

SSL/TLS connection authentication verifies the identity of the other party and whether it is a trusted communication object. The basis of authentication is the certificate provided by the communication object. Usually, the identity of the server is authenticated by the client, which is the so-called one-way authentication. Then two-way authentication, as the name suggests, is based on one-way authentication, the server authenticates the identity of the client.

The principle of authentication is actually very simple. Taking one-way authentication as an example, the simplest case is that the server sends the server certificate during the SSL/TLS handshake phase, and the client verifies whether the certificate is issued by a trusted CA, that is, using a trusted CA The public key in any CA certificate is used to verify whether the digital signature in the server certificate is legal. Of course, most cases are slightly more complicated than this, that is, the certificate of the server is not directly issued by the top-level CA authority, but the root CA authority applies a digital signature to the public key of the lower-level CA authority to form an intermediate CA certificate, such as Relationships may be as many as several layers to keep the root certificate as secure as possible. In most cases, the root CA certificates and intermediate CA certificates of common CA agencies are already built into our operating system, and only in a few cases, you need to add trusted CA certificates by yourself.

The authentication process of multi-level certificates or certificate chains will be slightly more complicated, but if we understand the certificate issuance logic mentioned above, it is actually very simple to understand. Taking one-way authentication as an example, if the client only trusts the root CA certificate, then the server needs to send the server certificate and the root CA certificate to all intermediate CA certificates between the server certificate during the handshake phase. Only when the client has obtained the complete certificate chain can it be verified layer by layer through the root CA certificate held by itself. The lack of an intermediate CA leads to an incomplete certificate chain or contains a wrong intermediate CA, which will cause the chain of trust to be interrupted and unable to Certified.

If the client holds some intermediate CA certificates in addition to the root CA certificate, the server can also omit the sending of these intermediate CA certificates during the authentication process to improve the handshake efficiency.

Therefore, when we configure one-way authentication, we need to specify the server certificate and intermediate CA certificate (optional) on the server, as well as the server private key file. The client needs to trust the corresponding root CA certificate. The trust method can be specified when connecting or adding the root CA certificate to the trust list through the certificate management tool. Usually the client library also provides a peer verification option that allows you to choose whether to verify the certificate. Disabling peer verification will directly create an encrypted TLS connection without verifying the certificate. However, this poses a security risk of man-in-the-middle attacks, so it is strongly recommended to enable peer-to-peer authentication.

When peer verification is enabled, the client also typically checks that the domain name (SAN field or CN field) in the server certificate matches the domain name of the server it is connecting to. If the domain names do not match, the client will refuse to authenticate to the server or establish a connection.

The configuration method of two-way authentication only needs to be based on one-way authentication. Enabling peer-to-peer authentication on the server side means enabling two-way authentication, and then refer to the configuration method of server certificate to correctly configure the client certificate.

Introduction to common TLS options

When using EMQX to configure an SSL/TLS connection, there are usually options such as certfile and keyfile. In order to help you better understand how these options are configured, we will briefly sort out and introduce these common TLS options:

• certfile, used to specify the server or client certificate and the intermediate CA certificate. When multiple certificates need to be specified, they are usually simply combined into one certificate file.
• keyfile, used to specify the server or client private key file.
• cacertfile is used to specify the Root CA certificate. The client needs to configure this option to verify the server certificate during one-way authentication, and the server also needs to configure this option to verify the client certificate during two-way authentication.
• verify, which is used to specify whether to enable peer verification. After the client enables peer-to-peer authentication, it usually checks whether the domain name of the connected server matches the domain name in the server certificate. Having both client and server enabled means that it will be a two-way authentication.
• fail_if_no_peer_cert, this is a server-side option, which is usually used when the server enables peer-to-peer authentication. Setting it to false means that the client is allowed to not send a certificate or send an empty certificate, which is equivalent to enabling one-way authentication and two-way authentication at the same time, which will increase Risk of man-in-the-middle attacks.
• versions, specifies the supported TLS versions. During the handshake process, both parties will send the version specified in the versions option to each other, and then switch to the highest version supported by both parties. Cipher suites are also negotiated based on the protocol version.
• ciphers, specifies the supported cipher suites. Note: Avoid using the aforementioned or other cipher suites that are considered weak security, and when using cipher suites that include the ECDSA signature algorithm, you need to pay extra attention to whether your certificate is of the ECC type.
• server_name_indication, the server name indication, this is a client-side option. Usually used when the client has peer-to-peer authentication enabled and the connected server domain name does not match the domain name in the server certificate. For example, the domain name in the server certificate is abc.com, and the client connects to 123.com, then the client needs to specify server_name_indication as abc.com when connecting to indicate that it trusts the domain name to pass the certificate check. Alternatively, set server_name_indication to disable to turn off this check, but this increases the risk of man-in-the-middle attacks and is generally not recommended.

Example

For the convenience of demonstration, we will use EMQX (version 4.3.0 and above) as the server, and use Erlang's ssl:connect/3 function as the client in the EMQX console.

One-way authentication

Modify the EMQ X configuration as follows:

 # 监听端口我们使用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，包含了服务端证书和中间 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 不开启对端验证
listener.ssl.external.verify = verify_none
# 支持 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端支持的密码套件
listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Start EMQ X and enter the console:

 $ ./emqx console

To connect using the ssl:connect/3 function:

 %% 1. 指定用于验证服务端证书的 Root CA 证书
%% 2. 启用对端验证
%% 3. 仅支持 TLS 1.2
%% 4. 仅支持 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这一个密码套件
ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
                                  {verify, verify_peer},
                                  {versions, ['tlsv1.2']},
                                  {ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).

Two-way authentication

In order to get to the point as soon as possible, the server certificate will continue to be used as the client certificate, which will have serious security risks. Please prohibit such use in the production environment!

Modify the EMQ X configuration as follows:

 # 监听端口我们使用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，包含了服务端证书和中间 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 指定用于验证客户端证书的 Root CA 证书
listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem
# 启用对端验证
listener.ssl.external.verify = verify_peer
# 要求客户端必须提供证书
listener.ssl.external.fail_if_no_peer_cert = true
# 支持 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端支持的密码套件
listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Start EMQ X and enter the console, then use the ssl:connect/3 function to connect:

 %% 1. 指定用于验证服务端证书的 Root CA 证书
%% 2. 启用对端验证
%% 3. 仅支持 TLS 1.2
%% 4. 仅支持 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这一个密码套件
ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
                                  {certfile, "etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt"},
                                  {keyfile, "etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key"},
                                  {verify, verify_peer},
                                  {versions, ['tlsv1.2']},
                                  {ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).

Epilogue

The "Guidelines for the Construction of Internet of Vehicles Network Security and Data Security Standard System" issued by the Ministry of Industry and Information Technology clearly pointed out that it is necessary to build a standard system for Internet of Vehicles network security and data security. Network communication security and data security in the field of Internet of Vehicles will receive more and more attention, which is one of the key factors for improving the competitiveness of Internet of Vehicles enterprises. It is hoped that through this article, readers can master the use of the SSL/TLS protocol, apply it correctly in actual business scenarios, and realize the security of Internet of Vehicles communication.

Copyright statement: This article is original by EMQ, please indicate the source when reprinting.

Original link: https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security