Encryption has many usage scenarios in cars and computers. Specifically, including the charging system, there is a need and requirement for information encryption from the vehicle end to the CAN bus. Key generation and management are core requirements for Internet of Vehicles security.
Due to the upgrading of the automobile industry, traditional automobile manufacturers are transforming into future-oriented intelligent network automobile manufacturers, which has given rise to IVI, TBOX and other vehicle-side systems with application (APP) and Internet access requirements, as well as the accompanying data and network security requirements. From this perspective, all car-side systems with applications and program processing actually need to encrypt memory and cached data to prevent leakage.
For car-side applications, authentication and access control need to be established to prevent other application components (LIB, SDK) from accessing and reading the resources (LIB, SDK), cache, and memory data of this application. The external access of the vehicle-side system can also be subdivided into request downloads of Internet content, voice assistant background access, backup background access, cloud access, V2X vehicle-to-road and vehicle-to-vehicle mutual visits, etc. These accesses require access to Internet resources, so the requirements for encrypted transmission and peer authentication must be included on the link and in the background. In addition, there is also an implicit need for encryption of hardware, such as hard drives and new energy charging piles.
The Internet of Vehicles security standard system can be subdivided into many directions. Today we mainly study the key security requirements in the Internet of Vehicles security standards.
Algorithm use and management requirements
Among the Internet of Vehicles standards, "Automotive Information Security" is the most comprehensive among all Internet of Vehicles standards. Among them, Chapter 5 and the first half of Chapter 6 correspond to the CSMS requirements of R155 and implement some of the requirements of ISO21434. The parts after Chapter 6 are standard technical requirements, which describe in detail the technical requirements for vehicle information security. This standard covers almost all aspects of Internet of Vehicles security and solves the problem of the lack of corresponding regulations and standards caused by China not being a mandatory party to R155.
6.8 in "Automotive Vehicle Information Security" clarifies the use and management requirements of cryptographic algorithms. If the requirements of international or national standards are not used, the rationality of their use should be explained. Encryption keys of appropriate length and validity period should be selected based on different encryption algorithms and scenarios; use open, published, and effective cryptographic algorithms, select appropriate parameters and options, and check regularly to take appropriate measures.
This requirement clarifies that the key length and parameters of the cryptographic algorithm should be set reasonably and effectively, the key algorithm needs to be unbroken and the validity period of the key algorithm needs to be checked frequently.
For cryptographic modules that do not adopt international or national standard requirements, the rationality of their use should be explained. Here, for your own cryptographic modules or new cryptographic algorithm modules, you can prove the effectiveness of the algorithm yourself and then use it normally.
Verification of authenticity and integrity of communications
7.2.1 of the requirements for third-party applications in "Automobile Information Security" requires that the authenticity and integrity of third-party applications should be tested. This requires either a dedicated network communication (VPN) between the vehicle and the third party, or using TLS1.2 or above for communication.
If you use a VPN, generally speaking, use IPSEC or OPENVPN without outbound calls. IPSEC is an encrypted communication technology that can use tunnel mode. Using IPSEC can realize tunnel encryption and protect the authenticity and integrity of data communication.
Generally speaking, the car-end connection backend and services can consider using IPSEC VPN tunnel mode protection. But for car companies, maintaining hundreds of thousands of IPSEC VPNs may be a cumbersome and redundant cost. Therefore, compared to IPSEC VPN, the industry generally considers using OPENVPN technology to achieve tunneled communication, which can also protect the authenticity and integrity of third-party applications.
OPEN VPN is based on the SSL protocol, and can easily realize dial-up handshake and tunnel establishment through the built-in configuration file of the car and computer. The configuration file of OPENVPN can be injected into the car and computer through batch distribution through software. OPENVPN has connection robustness and is a CS-structured VPN that can be managed directly through the backend. OPENVPN has direct practical significance for the vehicle to connect to the backend server to obtain the upgrade package. An upgrade file is transmitted to the car through the OPENVPN tunnel, which is more secure than any other OTA (update on air) method.
For downloading Internet resources, you don’t need to use a VPN. Such as the operation of obtaining music videos. This download-type operation can protect the authenticity and integrity of the data through TLS1.2. TLS1.2 is actually a kind of SSL VPN, but it is mainly connection-oriented, that is, server and client type. It has the characteristics of flexible deployment and wide application. Theoretically, there is a risk of TLS downgrade, but in actual applications, it can be avoided by deploying security measures.
Certificate authentication and key management
For the identity authentication test method for communication with the service platform, the requirements in 7.2.1 also include the certificate authentication method.
Certificate authentication is essentially an authentication method that uses asymmetric keys for encryption and decryption. First, the automobile manufacturer must generate the private key and public key for authentication, then fill in the information according to its own needs to generate a certificate, and include the public key in the certificate. The certificate typically contains the signature of the manufacturer's private key. The main method of public key authentication is to verify the signature of the certificate, including private key signature verification and third-party signature verification. The so-called private key signature authentication uses the principle of public key decryption of private key signatures to decrypt the private key signature of the certificate to verify the authenticity of the peer sending the information. Third-party signature authentication requires that the third party first signs the certificate with a private key, and then uses the private key signature authentication to verify the signature, thereby realizing the authenticity of the information sent to the other end guaranteed by the third party.
Key management includes two main points in 7.2.1. One is the regular update of keys, which is called regular update in a secure manner. One is the secure storage of keys. Regular security updates can be considered replacements. That is to say, from a general perspective, symmetric keys are used for data encryption; asymmetric keys are used for data encryption and certificate authentication, and they all need to be updated regularly.
Previously, car manufacturers usually opened a "safe zone" in the car's terminal storage to store "password tables" and "certificates." The private key is also listed in the table. Such an approach does not comply with the principles of Internet of Vehicles security. Generally speaking, private keys are theoretically not suitable for storage in the car, and the password table needs to be protected by a hardware encryption scheme, and hardware encryption is also necessary. Therefore, the correct approach to asymmetric keys is to store them in the background, apply for certificates and public keys through the system within the enterprise, and rotate them regularly to ensure that the private keys will not remain "unchanged for a long time."
For symmetric keys, they should be frequently regenerated without relying on the previous key (PFS Perfect Forward Secrecy) and updated to both ends of the data encryption using security algorithms, such as using (DH Group Diffie Hellman Group) or in communication The public key is first used to establish a secure connection and then the keys are exchanged. For asymmetric keys, you should not rely on the previous key (PFS Perfect Forward Secrecy) and regularly update the private key and public key pair, and use a secure key update algorithm to update both ends of the data encryption, such as using (DH Group Diffie Hellman Group).
Key protection and security control
It is proposed in 8.1.2 that security controls should be implemented on stored keys to prevent V2X data counterfeiting attacks. V2X applications include more cumbersome certificate applications. V2X certificates are generally divided into four levels. The certificates used between the vehicle end and the road end are generally pseudonymous certificates.
For car manufacturers, all V2X technology implementations are generally provided by third-party suppliers. So at the bottom level, according to the requirements of R155, the supplier's code and services need to be reviewed first, and at the same time, an agreement must be signed with the supplier to ensure security. V2X data counterfeiting attacks (Sibyl attacks) are attacks based on public key leaks and are directly related to the authentication and recording of data sources. The attacker uses the leaked key to generate data, and then needs to authenticate through the data source to send the tampered data to the V2X data. Therefore, access control and permission management of the key itself are the first layer of prevention for V2X data counterfeiting attacks, while data source authentication is the second layer of guarantee to prevent tampered data from entering the V2X network. In addition, recording can also help prevent V2X data counterfeiting attacks at the audit level.
It is mentioned in 10.1.2 that the vehicle should store encryption keys securely to prevent unauthorized access and acquisition. It mainly contains two levels of requirements. One is that cryptographically stored keys should be stored securely using hardware encryption. It is usually stored in security modules such as TEE, SE, HSM, etc., and also includes secure software storage forms. This requirement can well save the symmetric keys and certificates stored on the car side, but for the particularity of the asymmetric key signing certificate, it is still recommended to save the private key of the asymmetric key in the background, and then use hardware encryption or software Save in an encrypted manner.
Generally speaking, the main points of concern for Internet of Vehicles password security are as follows. First, the key algorithm selection itself requires a safe and reliable algorithm. The second is key access management, which requires permission control and access control. The third is the secure storage of keys, which requires a reliable storage area and a trustworthy secure storage algorithm. The fourth is the secure rotation of the key itself, including the regeneration and secure distribution of symmetric keys; the regeneration and secure distribution of asymmetric keys.
From the perspective of the car terminal, it can be divided into three levels: First, password protection at the system level, including system account management and access control, permission management, and password management. The second is the storage level, encrypting stored data, securely storing keys, cache encryption, and memory encryption. The third is the communication level, including encrypted access to resource downloads, tunnel encrypted access to background upgrades, encrypted transmission of data, etc.
京公网安备 11010802033920号