SSL/TLS protocol for secure Internet of Vehicles communications

Preface

As car travel becomes increasingly intelligent, we can use our mobile phones to remotely control the vehicle to unlock, start ventilation, and view images around the vehicle. We can also use OTA (over-the-air download technology) to upgrade the vehicle firmware, update map packages, and other operations. Autonomous driving technology can even allow the vehicle to automatically assist in steering, acceleration, and braking based on road conditions.

However, every feature that improves our user experience may become a fatal security vulnerability. Tencent Security Keen Lab has disclosed and demonstrated to the outside world how to remotely hack into smart cars without physical contact through 3/4G networks or WiFi networks to achieve remote control of vehicle lights, display screens, door locks and even brakes. Not only that, "interested parties" can even use a known vulnerability to gain control of the Autopilot of smart cars and control the direction of the vehicle.

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

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

MQTTS protocol for secure communication in connected vehicles

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

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

Confidentiality

Confidentiality is the basis of secure communication. Without confidentiality, anyone who eavesdrops on your communication can easily obtain your key private information such as login passwords, payment passwords, etc. The most common means of achieving confidentiality is encryption, so that the eavesdropper can only get a meaningless string of encrypted data, and only the person holding 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 symmetric encryption and asymmetric encryption. Symmetric encryption means that the same key is used for encryption and decryption, while asymmetric encryption means that different keys are used for encryption and decryption.

In symmetric encryption, since both communicating parties have to use the same key for encryption and decryption, they will inevitably encounter the key distribution problem. That is, if I need the other party to be able to decrypt the ciphertext I sent, I must tell the other party the key I used for encryption. But how can I ensure that the key will not be leaked during the process of synchronizing the key with the other party? This is the key distribution problem of symmetric encryption.

The commonly used solution at present is to use asymmetric encryption and the Diffie-Hellman key exchange algorithm. The core of asymmetric encryption is to generate a pair of keys, one is a public key and the other is a private key. The public key is used for encryption, it is public and can be distributed to anyone for use, and the private key is used for decryption, does not participate in the communication process, and needs to be properly kept, thus solving the key distribution problem. The core idea of ​​the Diffie-Hellman key exchange algorithm is that the communicating parties can calculate the same shared key by exchanging some public information, while the eavesdropper cannot calculate the same key after obtaining the public information. One advantage of the Diffie-Hellman algorithm is that it does not have the performance problem of asymmetric encryption. Although asymmetric encryption solves the key distribution problem, the operation speed of asymmetric encryption algorithms is far less than that of symmetric encryption algorithms, and the difference can even be hundreds of times. Although security is guaranteed, it seriously affects the efficiency of communication and loses practicality. Therefore, in actual 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, it is encrypted with a public key and sent to the other party. After receiving the ciphertext, the other party uses the private key to decrypt and obtain the session key, and subsequent communications will use this session key completely. This solves both the key distribution problem and the performance problem caused by asymmetric encryption. This method is usually called hybrid encryption.

Completeness

Confidentiality alone is not enough to achieve secure communication. "Interested parties" can still tamper with or forge ciphertext content, and the receiver can neither determine whether the ciphertext comes from the correct sender nor whether the decrypted plaintext is tampered with. Although the difficulty of targeted tampering with encrypted ciphertext has increased, for example, the data structure of the plaintext is likely to be destroyed after tampering, in which case the receiver can easily reject the plaintext. However, there is still a probability that the value of some fields in the decrypted plaintext message that have random attributes will change after tampering. For example, the value of the motor speed field changes from 500 to 718, which is nothing more than a change in a few bits. If the receiver accepts these messages normally, it may bring unexpected risks.

Therefore, we need to further ensure the integrity of the 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 and the hash value together to the recipient. The one-way hash function can ensure that even if only 1 bit of the message changes, there is a high probability that a different hash value will be generated. 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.

Identity Authentication

But unfortunately, when an "interested party" forges both the message and the corresponding hash value, the receiver still cannot see through the disguise. Therefore, we not only need to confirm the integrity of the message, but also confirm whether the message comes from a legitimate sender, that is, the identity needs to be authenticated. At this time, we need to use a message authentication code. The message authentication code is still based on a 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 a 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 called authenticated encryption (AEAD). In terms of specific use, the following schemes have been generated:

• Encrypt and MAC: First encrypt the plaintext with a symmetric cipher, then calculate the MAC value of the plaintext, and finally concatenate the two and send them to the recipient.
• MAC then Encrypt: First calculate the MAC value of the plaintext, then encrypt the plaintext and MAC value simultaneously using a symmetric cipher, and send the encrypted ciphertext to the receiver.
• Encrypt then MAC: First encrypt the plaintext with a symmetric cipher, then calculate the MAC value of the ciphertext, and finally concatenate the two and send them to the recipient.

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

Undeniable

Now, we have ensured the confidentiality of the message and can also identify disguise and tampering. However, since the core of the message authentication code requires the communicating parties to share a key, a new problem has arisen, namely, it is impossible to prove to a third party and prevent denial. Assuming that Bob receives a message from Alice and wants to prove to a third party that the message was indeed sent by Alice, he needs to tell the third party the key that only two people knew. This will obviously increase the security risk of continuing to use this key to communicate. At the same time, even if the third party obtains the key, it cannot draw a valid conclusion. For example, Bob can claim that the message was constructed by Alice because Alice also holds the same key.

Therefore, we also need to introduce a digital signature mechanism, which is very similar to asymmetric confidentiality, but just the opposite. Digital signature requires the sender to sign the message with a private key, and then send the message and signature to the receiver. The receiver uses the corresponding public key to verify the signature and confirm that the signature comes from the legitimate sender. Since only the person holding the private key can apply the correct signature, the sender cannot 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 questions in their minds at this point. Yes, how can the person who obtains the public key confirm that the public key is indeed from the communication object he expects? If a "careful person" disguises himself as the sender and gives his public key to the receiver, then the attack can be completed without cracking the digital signature algorithm.

We have fallen into an endless loop. Digital signatures are used to identify message tampering, disguise, and denial, but before that we must obtain an untampered public key from a sender who has not been disguised. At this point, we can only seek help from external forces and entrust a recognized trusted third party, which is what we now call a certification authority or CA, to sign each public key to form a public key certificate. Obviously, the certification authority needs to work hard to ensure that its private key is not stolen to ensure the validity of the digital signature. Although there is still a probability that the private key of the certification authority will be leaked, and even the certification authority itself may be disguised by "interested parties", we still cannot obtain absolute security, but trusting several known certification authorities in advance is always more reliable than obtaining and trusting the public key of a brand new communication object.

The above cryptographic technologies together constitute the cornerstone of modern secure communications. SSL/TLS, as the most widely used cryptographic communication method in the world, uses the aforementioned cryptographic technologies such as symmetric encryption, asymmetric encryption, message authentication code, digital signature, and pseudo-random number generator to provide communication security. Considering that cryptographic technology is constantly improving and developing, or that the currently seemingly reliable encryption algorithm may be declared broken the next day, SSL/TLS does not force the use of a certain cryptographic technology, but provides a mechanism called Cipher Suite. When a certain cryptographic technology is found to have weaknesses, it can be replaced like a part at any time, of course, provided that the client and server use the same cryptographic technology. This also extends the SSL/TLS handshake protocol, and the negotiated cipher suite 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 cracked or verified to have weak security, avoid using pseudo-random number generators that are easily predictable, and try to ensure that each algorithm has similar security (short board effect).

Therefore, how to correctly choose a cipher suite has also become an important part of ensuring security. Here I will also briefly summarize the currently recommended cipher technologies and encryption algorithms, hoping to help readers fill in the gaps:

• Among the symmetric encryption algorithms, RC4, DES, and 3DES are already considered unsafe. 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. To encrypt plaintext of any length, a block mode is required. Early block modes such as ECB, CBC, CFB, and OFB have been identified as having security vulnerabilities. Currently, GCM, CCM, and Poly1305 are more recommended.
• Commonly used asymmetric encryption algorithms include DH, RSA, and ECC. Since DH and RSA do not have forward security, they are no longer recommended. TLS 1.3 directly abolished the DH and RSA algorithms and replaced them with the ECC algorithm, which has significantly better security strength and performance than RSA. It has two sub-algorithms, ECDHE for key exchange and ECDSA for digital signatures. However, it should be noted that since ECDHE/DHE does not provide identity authentication, the server should enable verification of the client certificate.
• As for hash algorithms, the well-known MD5 and SHA-1 have been deemed unreliable and are not recommended for use. Currently, it is generally recommended to use SHA256 or higher.

After understanding the recommended cryptographic technologies, we may want to modify the cipher suite configuration on the client or server, but at this time we may find that the names of these cipher suites are a bit difficult to understand. For example, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, where TLS only represents the protocol, ECDHE represents the key exchange algorithm, ECDSA represents the authentication algorithm, AES_256_CBC represents the bulk encryption algorithm, and SHA384 represents the message authentication code MAC algorithm. This is usually the naming format of the cipher suite in TLS 1.2, and there are some changes in TLS 1.3. Since TLS 1.3 only accepts the use of the ECDHE algorithm for key exchange and ECDSA for authentication, its cipher suite name can be simplified to the format of TLS_AES_256_GCM_SHA384.

If only from the perspective of security, 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 in RSA mode in use, we still need to choose whether to continue using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 according to our own situation.

Constructing a typical architecture of 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 is also a typical security management system for most car companies. Its main design ideas are as follows:

• Identity identification based on digital certificates: Establish strict certificate management and usage specifications through the PKI/CA system, issue digital certificates for Internet of Vehicles applications and terminals, bind virtual identities and real identities, and solve identity identification and uniqueness issues (one machine, one password or one type, one password can be achieved);
• The authenticity of the identity is proved by the unique identity identification of the terminal during all data interactions to prevent malicious intrusion by third parties;
• Based on the digital certificate security function, it provides multiple functions such as identity identification, identity authentication, data encryption and decryption, digital signature and verification, etc., to meet the security needs of multiple businesses such as TSP and OTA in the Internet of Vehicles.

The secure communication interaction process of the Internet of Vehicles platform generally involves applying for a terminal certificate on the vehicle side, downloading and fully installing it, and then requesting to establish a secure connection with the cloud platform through the MQTTS security protocol. In the cloud, we can choose to perform authentication and authorization on the cloud vendor's load balancing product, the LB layer built by ourselves based on Nginx/HAProxy, or the MQTT Broker layer. At the same time, through proxy_protocol v2, the vehicle side's ID information, username and password, and the CN/SN of the certificate are uniquely authenticated by calling the PKI/CA unified authentication interface to achieve one machine one key or one type one key security authentication.

Configuration methods for single and two-way authentication in MQTTS communication

SSL/TLS connection authentication verifies the identity of the other party, whether it is a trusted communication object, and the basis for authentication is the certificate provided by the communication object. Usually, the client authenticates the identity of the server, which is the so-called one-way authentication. Then, as the name suggests, two-way authentication is based on one-way authentication, and 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 organization, that is, using the public key in the trusted CA certificate 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 server certificate is not directly issued by the top-level CA organization, but the root CA organization digitally signs the public key of the lower-level CA organization to form an intermediate CA certificate. Such a relationship may have as many as several layers to protect the security of the root certificate as much as possible. In most cases, the root CA certificates and intermediate CA certificates of common CA organizations are already built into our operating system. Only in a few cases do you need to add trusted CA certificates yourself.

The authentication process of multi-level certificates or certificate chains is 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 all the intermediate CA certificates between the root CA certificate and the server certificate during the handshake phase. Only when the client has a complete certificate chain can it verify layer by layer through its own root CA certificate. The lack of intermediate CAs will cause the certificate chain to be incomplete or contain the wrong intermediate CA, which will cause the trust chain to be interrupted and fail the authentication.

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), as well as the server private key file on the server. The client needs to trust the corresponding root CA certificate. The trust can be specified when connecting or added to the trust list through the certificate management tool. Usually the client library also provides a peer verification option to allow you to choose whether to verify the certificate. Turning off peer verification will directly create an encrypted TLS connection without verifying the certificate. However, this will bring security risks of man-in-the-middle attacks, so it is strongly recommended to enable peer verification.

When peer authentication is enabled, the client will usually also check whether 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 the server or establish a connection.

The configuration method of two-way authentication only requires enabling peer verification on the server side based on one-way authentication, which means enabling two-way authentication, and then correctly configuring the client certificate by referring to the configuration method of the server 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 to configure these options, we will briefly sort out and introduce these common TLS options:

• certfile is used to specify the server or client certificate and the intermediate CA certificate. When multiple certificates need to be specified, they are usually simply merged into one certificate file.
• keyfile is used to specify the server or client private key file.
• cacertfile is used to specify the Root CA certificate. In one-way authentication, the client needs to configure this option to verify the server certificate. In two-way authentication, the server also needs to configure this option to verify the client certificate.
• verify, used to specify whether to enable peer verification. After enabling peer verification, the client usually checks whether the domain name of the connected server matches the domain name in the server certificate. Enabling both the client and the server means that this will be a two-way authentication.
• fail_if_no_peer_cert is a server-side option, usually used when the server enables peer authentication. Setting it to false allows the client to not send a certificate or send an empty certificate, which is equivalent to enabling both one-way authentication and two-way authentication at the same time, which increases the risk of man-in-the-middle attacks.
• versions, specifies the supported TLS versions. During the handshake process, both communicating parties will send the version specified in the versions option to each other, and then switch to the highest version supported by both parties. At the same time, the cipher suite will also be negotiated based on the protocol version.
• ciphers, specifies the supported cipher suites. Note: Avoid using the cipher suites mentioned above or other cipher suites that are considered to be weak in security. When using a cipher suite that includes the ECDSA signature algorithm, pay extra attention to whether your certificate is of the ECC type.
• server_name_indication, server name indication, is a client option. It is usually used when the client enables peer verification and the domain name of the connected server does not match the domain name in the server certificate. For example, if 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, you can set server_name_indication to disable to turn off this check, but this will increase the risk of man-in-the-middle attacks, which is generally not recommended.

Example

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

(1) One-way authentication

Modify the EMQ X configuration as follows:

 #We use the default listening port 8883
 listener . ssl . external = 8883
 #Server private key file
 listener . ssl . external . keyfile = etc / certs / zhouzb . club / Nginx / 2_ zhouzb . club . key
 #Certificate bundle file, including the server certificate and intermediate CA certificate
 listener . ssl . external . certfile = etc / certs / zhouzb . club / Nginx / 1_ zhouzb . club_bundle . crt
 #Do not enable peer verification
 listener . ssl . external . verify = verify_none
 #Support TLS 1.2 and TLS 1.3
 listener . ssl . tls_versions = tlsv1 .3 , tlsv1 .2
 #Cipher suites supported by the server
 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 ​

Use the ssl:connect/3 function to connect:

 % % 1. Specify the Root CA certificate used to verify the server certificate
 % % 2. Enable peer authentication
 % % 3. Only supports TLS 1.2
 % % 4. Only the cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is supported
 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" ]}]).

(2) Two-way authentication

In order to get to the point as soon as possible, we will continue to use the server certificate as the client certificate. This will have serious security risks and is prohibited in production environments!

Modify the EMQ X configuration as follows:

 #We use the default listening port 8883
 listener . ssl . external = 8883
 #Server private key file
 listener . ssl . external . keyfile = etc / certs / zhouzb . club / Nginx / 2_ zhouzb . club . key
 #Certificate bundle file, including the server certificate and intermediate CA certificate
 listener . ssl . external . certfile = etc / certs / zhouzb . club / Nginx / 1_ zhouzb . club_bundle . crt
 #Specify the Root CA certificate used to verify the client certificate
 listener . ssl . external . cacertfile = etc / certs / zhouzb . club / DigiCertGlobalRootCA . crt . pem
 # Enable peer verification
 listener . ssl . external . verify = verify_peer
 #Require the client to provide a certificate
 listener . ssl . external . fail_if_no_peer_cert = true
 #Support TLS 1.2 and TLS 1.3
 listener . ssl . tls_versions = tlsv1 .3 , tlsv1 .2
 #Cipher suites supported by the server
 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. Specify the Root CA certificate used to verify the server certificate
 % % 2. Enable peer authentication
 % % 3. Only supports TLS 1.2
 % % 4. Only the cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is supported
 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" ]}]).

Conclusion

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 a standard system for Internet of Vehicles network security and data security should be established. Network communication security and data security in the field of Internet of Vehicles will receive more and more attention and will be one of the key factors affecting the competitiveness of Internet of Vehicles companies. I hope that through this article, readers can master the use of SSL/TLS protocols, apply them correctly in actual business scenarios, and achieve Internet of Vehicles communication security.