preface

In vehicle travel more intelligent today, we can realize mobile phone remote control car unlocking, start the ventilation, to see around the vehicle images, but can be by OTA download technology (air) machine firmware upgrade is complete, updated map operations, such as automatic driving technology but also can make the vehicle according to the implementation of automatic road auxiliary steering, acceleration and braking.

However, every feature that improves our experience of using it has the potential to be a fatal security flaw. Tencent Security Cohen Laboratory has disclosed and demonstrated how to use 3/4G network or WiFi network to hack into intelligent cars without physical contact, and realize remote control of vehicle signal lights, display screens, door locks and even brakes. In addition, an attacker could take advantage of a known vulnerability to gain control of a smart car’s Autopilot, which controls where the vehicle is going.

Therefore, the importance of communication security, identity authentication and data security should be fully recognized in the construction of the Internet of vehicles platform, and relevant encryption authentication and other technical means should be correctly used to provide guarantee.

This article will comprehensively introduce the application of SSL/TLS protocol in the communication security of Internet of vehicles, hoping to make you have a clearer and intuitive understanding of the role of SSL/TLS. In addition, we will explain how to configure SSL/TLS in detail to ensure that you can use SSL/TLS correctly to ensure security.

Internet of vehicles secure communication MQTTS protocol

MQTTS protocol is based on MQTT protocol, encapsulates a layer of encryption protocol based on SSL/TLS (* Transport layer security) *, which ensures that the communication between the vehicle terminal and the vehicle Internet platform is encrypted. However, if SSL/TLS is not configured correctly, there are still many security risks. To really use SSL/TLS, we must understand what problems SSL/TLS solves and have a rudimentary understanding of the cryptography used by SSL/TLS.

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

confidentiality

Confidentiality is the foundation of secure communications, without which anyone eavesdropping on your communications can easily obtain your login passwords, payment passwords and other key private information. The most common method of achieving confidentiality is encryption, so that eavesdroppers can only get a meaningless string of encrypted data, and only those with the key can restore the ciphertext to the correct original message. Encryption can be classified into symmetric encryption and asymmetric encryption according to the key usage method. Symmetric encryption means that encryption and decryption use the same key, asymmetric encryption means that encryption and decryption use different keys.

Symmetric encryption because of communication both sides should use the same key for encryption, so will inevitably encounter the key distribution problem, which I need each other can decrypt I send the past ciphertext, I must tell my encryption keys used in each other, but I how to ensure the key synchronization with each other in the process of the key won’t leak? This is the key distribution problem of symmetric encryption.

The common solution is to use asymmetric encryption and use 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, and it is public and can be sent to anyone, while the private key is used for decryption, does not participate in the communication process, and needs to be kept properly. In this way, the key distribution problem is solved. The core idea of Diffie-Hellman key exchange algorithm is that the communication 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 Diffie-Hellman algorithm is that it does not have the performance problem of asymmetric encryption. Although asymmetric encryption solves the key distribution problem, the calculation speed of asymmetric encryption algorithm is far less than that of symmetric encryption algorithm, and they can even be hundreds of times different. Although the security is guaranteed, the efficiency of communication is seriously affected and the practicability is lost. Therefore, symmetric encryption and asymmetric encryption are usually used together in practical applications. That is, the pseudo-random number generator is used to generate the session key, encrypt the session key with the public key, and send the session key to the peer party. The peer party uses the private key to decrypt the session key after receiving the ciphertext. This method 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 with or forge the ciphertext. However, the recipient cannot determine whether the ciphertext is from the correct sender or whether the decrypted text is untampered. Although targeted tampering of encrypted ciphertext becomes more difficult, for example, the data structure of the plaintext may be damaged after tampering, in which case the receiver can easily reject the plaintext. But there is still a tampering after just get decrypted plaintext message itself has the random nature of the value of the field change probability, such as the value of the motor speed from 500 to 718, are nothing more than a few bits of change, if the receiver to accept these messages, can bring unexpected dangers.

Therefore, we also need to further guarantee 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 a message and then send the message along with the hash value to the receiver. A one-way hash function ensures that a change of even 1 bit in a message has a high probability of producing a different hash value. This allows the receiver to calculate the hash value of the message and then compare the received hash value to determine whether the data has been tampered with.

The identity authentication

Unfortunately, when an attacker forges both the message and the corresponding hash value, the recipient is still unable to see through the disguise. So not only do we need to verify the integrity of the message, but we also need to verify that the message is from a legitimate sender, which means we also need to authenticate the identity. This is where the message authentication code is needed. The message authentication code is still based on a one-way hash function, but its input includes a shared key between sender and receiver in addition to the original message. The message authentication code itself does not guarantee the confidentiality of the message. Therefore, symmetric encryption and message authentication code are usually combined in practice to meet the requirements of confidentiality, integrity, and authentication. This mechanism is also called Authentication encryption (AEAD). In terms of specific usage, the following schemes are produced:

  1. Encrypt and MAC: Encrypt the plain text with a symmetric password, calculate the MAC value of the plain text, and combine the two values to send to the receiver.
  2. MAC then Encrypt: Calculates the plaintext MAC value, encrypts both the plaintext and THE MAC value with a symmetric password, and sends the encrypted ciphertext to the recipient.
  3. Encrypt THEN MAC: Encrypts the plain text with a symmetric password, calculates the MAC value of the ciphertext, and concates the two values for the receiver.

For a long time, SSL/TLS has adopted the second solution, but in fact the above three solutions have been verified as having security vulnerabilities. Historical POODLE and Lucky 13 attacks on SSL/TLS have been implemented against vulnerabilities in the MAC Then Encrypt scheme. Currently, the AEAD algorithm is recommended. In SSL/TLS version 1.3, other encryption modes are abolished and only AEAD encryption is supported.

There is no denying that

Now, we have guaranteed the confidentiality of the message, and we can also detect masquerade and tampering, but the core of the message authentication code is the need for both communication parties to share the key, which raises new problems, namely the inability to prove to third parties and the inability to prevent denial. Suppose that Bob receives a 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 originally, which will obviously increase the security risk of using this key for subsequent communication. At the same time, even if a third party gets the key, it cannot draw a valid conclusion. For example, Bob can claim that the message was constructed by Alice, because Alice also has the same key.

Therefore, we also need to introduce a digital signature mechanism, which works in much the same way as asymmetric secrets, but in the opposite way. Digital signature requires the sender to use the private key to sign the message, and then send the message and the signature together to the receiver. The receiver verifies the signature using the corresponding public key to confirm that the signature is from a 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 sent to anyone. Sensitive readers may have some questions in mind by now. Yes, how can the person who has obtained the public key be sure that the public key is indeed from the intended communication object? If the attacker masquerades as the sender and gives his public key to the recipient, the attack can be completed without cracking the digital signature algorithm.

We are already stuck in a loop where digital signatures are used to tamper, masquerade and deny identification messages, but before that we have to get an untampered public key from an unmasqueraded sender. At this point, we can only rely on external help, entrust a recognized trusted third party, that is, we now commonly said certification authority or CA, by it to sign each public key, the public key certificate. Obviously, certification authorities need to work hard to ensure that their private keys are not stolen 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 attackers, we still cannot obtain absolute security, but it is always more reliable to trust several known certification authorities in advance, than to obtain and trust his public key from a brand new communication object.

Together, these cryptographic techniques constitute the cornerstone of modern secure communication. SSL/TLS, as the most widely used cryptographic communication method in the world, comprehensively uses the previously mentioned symmetric encryption, asymmetric encryption, message authentication code, digital signature, pseudorandom number generator and other cryptographic technologies to provide communication security. Given that cryptography is constantly evolving, or that currently seemingly reliable cryptography algorithms can be declared breached the next day, SSL/TLS does not mandate the use of a particular cryptography technology, but rather provides a Cipher Suite mechanism for when weaknesses in a cryptography technology are found. It can be replaced like a piece at any time, provided of course that the client and server use the same cryptography. This also extends to the SSL/TLS handshake protocol, where the cipher suite used for negotiation is one of the main jobs of this part of the protocol.

For SSL/TLS to have good security, you need to avoid using encryption algorithms that have been compromised or verified to be weak, avoid using pseudo-random number generators that are easy to predict, and try to ensure that each algorithm has similar security (short board effect).

Therefore, how to choose the correct password suite has become an important link to ensure security. Here I will also make a simple collation of the current recommended cryptographic techniques and encryption algorithms, hoping to help readers to fill in the gaps:

  • RC4, DES, and 3DES are considered insecure. Currently, AES and ChaCha20 are recommended. ChaCha20 is an encryption algorithm designed by Google to provide better performance than AES if the CPU or software does not support the AES instruction set.
  • Symmetric encryption algorithms such as AES can encrypt only fixed-length plaintext. To encrypt plaintext of any length, you need to use the grouping mode. Earlier groupings such as ECB, CBC, CFB and OFB have been identified as having security vulnerabilities, and GCM, CCM and Poly1305 are now recommended.
  • Common asymmetric encryption algorithms include DH, RSA, and ECC. DH and RSA are not recommended because they do not provide forward security. In TLS 1.3, THE DH and RSA algorithms are directly abolished and replaced by the ECC algorithm, which has two sub-algorithms. ECDHE is used for key exchange. ECDSA is used for digital signatures. Note, however, that since ECDHE/DHE does not provide authentication, the server should enable authentication of the client certificate.
  • Hashing algorithms, known as MD5 and SHA-1, have been deemed unreliable and are not recommended. SHA256 or later is generally recommended today.

After knowing the recommended cryptography, we might want to change the client or server password suite configuration, but at this point we might find the names of the password suites a little hard to understand. For example, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, where TLS indicates protocol, ECDHE indicates key exchange algorithm, ECDSA indicates identity authentication algorithm, and AES_256_CBC indicates batch encryption algorithm. SHA384 indicates the MAC algorithm of the message authentication code. This was usually the naming format for the cipher suite in TLS 1.2, but with TLS 1.3 it has changed a bit. Because TLS 1.3 accepts only the ECDHE algorithm for key exchange and uses ECDSA for identity authentication, its cipher-suite name can be reduced to TLS_AES_256_GCM_SHA384.

To ensure security, you are advised to use TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 and TLS_AES_256_GCM_SHA384. However, there are still many RSA certificates in use. Therefore, you need to choose whether to continue using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 based on your own situation.

Construct a typical architecture of security certification system

The adoption of digital certificate system based on PKI/CA is a key step to solve the security of Internet of vehicles, and is also a typical security management system of most vehicle enterprises. The main design ideas are as follows:

  1. Identity identification based on digital certificate: establish strict certificate management and use specifications through PKI/CA system, issue digital certificates for applications and terminals of the Internet of vehicles, bind virtual identity and real identity, and solve identity identification and uniqueness problems (one machine with one security or one type with one security);
  2. All data interaction through the terminal unique identity identification to prove the authenticity of identity, to prevent third-party malicious intrusion;
  3. Based on the security function of digital certificate, it provides multiple functions such as identity authentication, identity authentication, data encryption and decryption, digital signature and signature verification, etc., meeting the security requirements of multi-service such as TSP and OTA in the Internet of vehicles.

The security communication interaction process of the Internet of vehicles platform is generally to establish a secure connection with the cloud platform request through MQTTS security protocol after the application terminal certificate is downloaded and installed completely. In the cloud, we can choose the load balancing products of cloud manufacturers, LB layer based on Nginx/HAProxy or MQTT Broker layer for authentication. At the same time, proxy_protocol V2 is used to invoke the PKI/CA unified authentication interface for unique authentication of the ID information, user name, password, and CN/SN of the vehicle and the machine to achieve one-machine one-security authentication or one-type one-security authentication.

This section describes how to configure single and bidirectional authentication in MQTTS communication

SSL/TLS connection authentication verifies the identity of the peer and whether it is a trusted communication object. The authentication is based on the certificate provided by the communication object. Usually, the client authenticates the identity of the server, which is called one-way authentication. Two-way authentication means that the server authenticates the identity of the client on the basis of one-way authentication.

Certification is actually very simple, the principle of the one-way authentication, for example, the simplest case is the server sends the server certificate in the SSL/TLS handshake phase, the client to test whether the certificate issued by a trusted CA institution, also is to use a trusted CA certificate of public key to verify the digital signature of 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 CA, but by the root CA authority to impose a digital signature on the public key of the lower CA authority to form the intermediate CA certificate, such relationship may be as many as several layers, to protect the root certificate security as much as possible. In most cases, the root CA certificate and the intermediate CA certificate of the common CA organization are already built into our operating system, and there are only a few cases where you need to add your own trusted CA certificate.

The multi-level certificate or certificate chain authentication process is a little more complicated, but it’s actually easy to understand if you understand the certificate issuing logic. Take one-way authentication as an example. If the client trusts only the root CA certificate, the server sends all intermediate CA certificates between the root CA certificate and the server certificate during the handshake. Only when a client obtains a complete certificate chain, it can verify the root CA certificate from layer to layer. If an intermediate CA is missing, the certificate chain is incomplete or contains an incorrect intermediate CA, the trust chain is interrupted and authentication fails.

If the client has some intermediate CA certificates besides the root CA certificate, the server can omit the sending of these intermediate CA certificates during authentication to improve the handshake efficiency.

Therefore, when configuring one-way authentication, you need to specify the server certificate and intermediate CA certificate (optional), as well as the server private key file on the server side. The client needs to trust the corresponding root CA certificate, either by specifying it at connection time or by adding the root CA certificate to the trust list using a certificate management tool. Typically, client libraries also provide peer authentication options that allow you to select whether or not to authenticate the certificate. Turning off peer authentication creates an encrypted TLS connection without verifying the certificate. However, this brings security risks of man-in-the-middle attacks, so it is strongly recommended to enable peer authentication.

After peer authentication is enabled, the client usually checks whether the domain name (SAN field or CN field) in the server certificate matches the domain name of the connected server. If the domain names do not match, the client will refuse to authenticate or establish a connection to the server.

To configure bidirectional authentication, you only need to enable bidirectional authentication on the server and configure the client certificate by referring to the configuration of the server certificate.

This section describes common TLS options

When using EMQX to configure SSL/TLS connections, there are usually certfile and keyfile options. To help you understand how to configure these options, we will briefly introduce these TLS options.

  • Certfile, used to specify server or client certificates and intermediate CA certificates. When multiple certificates need to be specified, they are usually simply merged into one certificate file.
  • Keyfile, which specifies the server or client private keyfile.
  • Cacertfile: specifies the Root CA certificate. This parameter is required for one-way authentication and bidirectional authentication to verify the client certificate.
  • Verify: specifies whether peer authentication is enabled. After peer authentication is enabled, the client usually checks whether the connected server domain name matches the domain name in the server certificate. Enabling both the client and the server means that this is a two-way authentication.
  • Fail_if_no_peer_cert: this option is usually used when peer authentication is enabled on the server. If the value is set to false, the client is allowed to send no certificate or an empty certificate. It is equivalent to enabling one-way and two-way authentication at the same time, which increases the risk of man-in-the-middle attacks.
  • Versions: Specifies the supported TLS version. During the handshake, the communication parties send the version specified in the Versions option to the other party and switch to the version supported by both parties. The password suite is also negotiated based on the protocol version.
  • Ciphers, which specifies the supported cipher suite. Note: Avoid using the above mentioned cryptosuite or other cryptosuite that is considered weak security, and when using a cryptosuite that includes the ECDSA signature algorithm, pay extra attention to whether your certificate is of the ECC type.
  • Server_name_indication, server name indication, which is a client option. This parameter is used when peer authentication is enabled on the client and the connected server domain name 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 is connected to 123.com, the client needs to specify server_name_Indication as abc.com to indicate that it trusts the domain name to pass the certificate check. Alternatively, set server_name_Indication to disable to turn this check off, but this increases the risk of man-in-the-middle attacks and is generally not recommended.

The sample

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

One-way authentication

Modify the EMQ X configuration as follows:

We use the default 8883
listener.ssl.external = 8883
Server private key file
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
The certificate bundle contains the server certificate and intermediate CA certificate
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# Disable peer authentication
listener.ssl.external.verify = verify_none
TLS 1.2 and TLS 1.3 are supported
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
Password suite 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_SHA2 56,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384Copy the code

Start EMQ X and enter the console:

$ ./emqx console
Copy the code

Use SSL :connect/3 to connect:

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

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, which has serious security risks. Please do not use this in production environment!

Modify the EMQ X configuration as follows:

We use the default 8883
listener.ssl.external = 8883
Server private key file
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
The certificate bundle contains 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 validate the client certificate
listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem
# Enable peer authentication
listener.ssl.external.verify = verify_peer
The client must provide a certificate
listener.ssl.external.fail_if_no_peer_cert = true
TLS 1.2 and TLS 1.3 are supported
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
Password suite 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_SHA2 56,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384Copy the code

Start EMQ X and go to the console, then connect using SSL :connect/3:

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

conclusion

It is clearly pointed out in the Guideline for The Construction of Standard System for Network Security and Data Security of The Internet of Vehicles issued by the Ministry of Industry and Information Technology that a standard system for network security and data security of the Internet of vehicles should be established. 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 affecting the competitiveness of Internet of vehicles enterprises. It is hoped that readers can master the use of SSL/TLS protocol and correctly apply it in actual business scenarios to ensure the communication security of the Internet of vehicles.

Copyright: EMQ

Original link: www.emqx.com/zh/blog/ssl…