With the networking and intelligence of automobiles, cars are no longer isolated and are increasingly integrated into the Internet. At the same time, cars are gradually becoming potential targets of cyber attacks. The network security of cars has become the foundation of car safety and has received more and more attention and attention. AUTOSAR is currently a globally recognized automotive embedded software architecture. The integrated related information security modules fully support the realization of information security needs, such as protecting in-vehicle communications or protecting confidential data. Due to the different architectures of CP AUTOSAR and AP AUTOSAR, there are also differences in the relevant technical implementations of information security modules.
1. SecOC
In vehicle networks, CAN bus is one of the commonly used communication buses. Most of its data is broadcast in plain text and received without authentication. This solution has the advantages of low cost and high performance. However, with the business needs of connected and intelligent vehicles, data security is becoming more and more important. The traditional method of adding RollingCounter and Checksum information to messages has very limited security and is easy to be reverse cracked, so that messages can be forged to control vehicles.
SecOC is an information security component added to the AUTOSAR software package, which mainly adds a series of functions and new requirements such as encryption and decryption operations, key management, fresh value management and distribution. The main function of this module is to provide authentication for data transmitted on the bus. It can effectively detect attacks such as data playback, deception and tampering.
Figure 4.1-1 Message authentication and freshness verification process
In the SecOC standard, AUTOSAR mainly implements data authenticity and integrity verification based on MAC authentication and Freshness anti-replay attack. First of all, MAC (Message Authentication Code) is one of the cryptographic methods to ensure information integrity and authentication. Among them, CMAC (Cipher based MAC) is generally used for symmetric encryption. The vehicle manufacturer can statically assign keys when the vehicle is offline and the program is flashed, or it can choose to use a cloud server to dynamically assign keys to the vehicle. It is a common solution for vehicle bus encryption authentication. The role of MAC is not to prevent valid data from being leaked, but to protect the data from being tampered with by the attacker, that is, to complete the authentication of the data source. If the communication data needs to be protected from being monitored by the attacker, the valid data of the message needs to be additionally encrypted.
In order to reduce the risk of repeated attacks, it is necessary to add a freshness value to the Secured I-PDU. The Freshness Value is a value that is continuously updated according to a certain logic. There are various ways to update the Freshness Value. The AUTOSAR standard uses counter-based or time-based freshness values as typical options.
In the CP AUTOSAR platform, the SecOC module relies on the API and functions of the PduR, and provides the upper and lower layer API functions required by the PDU Router. It relies on the encryption algorithm provided by the CSM module in AUTOSAR. The SecOC module requires API functions to generate and verify cryptographic signatures or message authentication codes. It provides an API with management functions for RTE to call as a service interface.
The SecOC communication protocol features are also applicable to the AP AUTOSAR platform standard. Its main goal is to achieve interoperability with the CP AUTOSAR platform SecOC function, especially for messaging scenarios using UDP multicast (SecOC is the only protocol currently supported) and signal-based network binding secure communication scenarios with CP AUTOSAR.
Figure 4.1-2 SecOC in AP AUTOSAR communication management
To achieve interoperability with the CP AUTOSAR platform, SecOC is also used in Adaptive CM. The authentication information includes the authenticator (e.g., message authentication code) and an optional freshness value. In order to maintain interoperability with the CP AUTOSAR platform and provide optional freshness value management functions, AP AUTOSAR CM will rely on a pluggable freshness value management library. This library will provide APIs related to freshness value management, including copies of the CP AUTOSAR platform's Freshness Management client and server interfaces and related call definition functions.
The core idea of SecOC is communication authentication, but it does not involve message encryption. Although the difficulty of forging messages has been greatly improved, there are still certain risks in the use of plain text transmission during the communication process; the strength of authentication information is related to the length of the information. The communication authentication scheme will increase the message load (the load of the traditional CAN message only uses 8-64 bytes), which will lead to an increase in the load rate and a decrease in the real-time communication, which may affect the normal function. The balance between information security strength and communication real-time should be considered; MAC technology should consider the management and sharing of symmetric keys. At present, most MCUs do not have security functions, and the symmetric keys are also stored in the system or memory in plain text. When sharing the key, plain text communication is used, which is very unsafe. However, the computing power and storage space of the MCU are limited. After the security mechanism is adopted, it will inevitably occupy a lot of resource consumption. The stability of the system should be fully considered to ensure the normal operation of the business and security mechanism; SecOC is used to ensure secure communication, which inevitably involves the management of keys. The filling, updating and maintenance of the key should be considered, and the consistency of the key after the replacement should also be considered.
2. TLS
As the backbone of the transport layer, TLS (Transport Layer Security) can support upper-layer protocols such as SOME/IP, MQTT and HTTP. It can be used not only for secure communication of V2X, but also for secure communication between communication nodes within the vehicle. Of course, for nodes such as T-BOX that can communicate with nodes outside the vehicle, their security requirements are higher, and a more complete generalized TLS can be applied, which is both safe and flexible. Generally, the IP addresses, ports, service interfaces, etc. within the vehicle are fixed, and the security requirements are not as high as those of T-BOX. In this case, the pre-shared key (TLS_PSK) and other suites in the generalized TLS can be applied, which are both efficient and stable.
TLS is a protocol that works at the transport layer. It lies between the underlying transport layer protocol and the upper application protocol. The Ethernet transport layer mainly has two underlying protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). The two have their own characteristics and complement each other. Whether on the traditional Internet or on the in-vehicle Ethernet, both are common underlying transport layer protocols. Different underlying transport layer protocols actually correspond to different transport layer security protection protocols. If TCP is used for transmission, TLS is used for protection. If UDP is used for transmission, DTLS is used for protection. The full name of DTLS is Datagram Transport Layer Security. The extra "D" compared to TLS refers to the "D" in UDP. TLS and DTLS have different versions. Currently, the mainstream supported versions are 1.2 and 1.3.
The AUTOSAR standard provides an ISO DoIP solution based on the Ethernet architecture. The full name of DoIP is Diagnostic Over IP, which means IP-based diagnosis. DoIP has the advantages of processing large amounts of data, saving reprogramming time, convenient access to IT facilities, and flexible use of standard communications. Ordinary DoIP is based on TCP for diagnostic communication. The ISO 13400-2 2019 version defines a secure DoIP session, which is based on TLS for diagnostic communication.
The DoIP server protocol stack determines whether to use TCP or TLS for the transmission of diagnostic information based on the request of the DoIP client entity. TLS allows the establishment of an authenticated and encrypted communication channel between the Client DoIP entity and the Server DoIP entity. The verification of the identity of the Client DoIP entity can be implemented in the diagnostic application layer, such as the 0x29 service defined in ISO 14229.
TLS technology still has its own technical limitations. Most controllers use MCUs, which have limited computing power and storage space. Security mechanisms such as encryption and decryption algorithms, message digest algorithms, and signature verification algorithms are used, which will inevitably consume a lot of resources. It should be considered that the security strategy can be implemented normally without affecting normal functions. SSL/TLS uses security authentication to identify the identity of the other party. Security certificates need to be pre-installed. If the controller is replaced, the consistency of the certificate should be ensured so that the new controller can verify the legal identity and communicate normally. In actual application scenarios, most controllers may not have a secure storage environment (SE or HSM, etc.), and it should be considered to ensure the secure storage of certificates and private keys. When using TLS for secure authentication communication, the efficiency of communication will inevitably be reduced, and the real-time nature of communication should be considered. The application of security technology will also bring some resource consumption and certain limitations. Under the principle of meeting the relevant regulations and standards for automotive information security, technical means should be selected to complete the integrated deployment without affecting the normal operation of the controller. If the internal security communication technology consumes too many controller resources and affects the normal business operation, the security level should be appropriately reduced. Both the controller operation and internal security communication must be taken into account.
Previous article:Brief Analysis of Automotive Ethernet Test Content and Test Methods
Next article:Power Inverter - A critical safety system for electric vehicles
- Popular Resources
- Popular amplifiers
- Design and implementation of Ethernet communication system for domain controller based on AUTOSAR
- Automotive Software Architectures: An Introduction
- AUTOSAR Specification and Automotive Controller Software Development
- Research and design of electric vehicle drive motor ECU control software based on AUTOSAR
- Huawei's Strategic Department Director Gai Gang: The cumulative installed base of open source Euler operating system exceeds 10 million sets
- Analysis of the application of several common contact parts in high-voltage connectors of new energy vehicles
- Wiring harness durability test and contact voltage drop test method
- Sn-doped CuO nanostructure-based ethanol gas sensor for real-time drunk driving detection in vehicles
- Design considerations for automotive battery wiring harness
- Do you know all the various motors commonly used in automotive electronics?
- What are the functions of the Internet of Vehicles? What are the uses and benefits of the Internet of Vehicles?
- Power Inverter - A critical safety system for electric vehicles
- Analysis of the information security mechanism of AUTOSAR, the automotive embedded software framework
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
- Huawei's Strategic Department Director Gai Gang: The cumulative installed base of open source Euler operating system exceeds 10 million sets
- Download from the Internet--ARM Getting Started Notes
- Learn ARM development(22)
- Learn ARM development(21)
- Learn ARM development(20)
- Learn ARM development(19)
- Learn ARM development(14)
- Learn ARM development(15)
- Analysis of the application of several common contact parts in high-voltage connectors of new energy vehicles
- Wiring harness durability test and contact voltage drop test method
- A strange MIC (microphone) signal amplifier circuit, I thought about it for a long time but still couldn't understand it
- My Journey of MCU Development (Part 7)
- [TI recommended course] #Common errors and solutions in DC/DC converter design#
- Pyboard timer terminal callback function problem
- Relay wiring
- Blood pressure monitor diastolic and systolic blood pressure
- How to analyze this kind of circuit? I need your advice. It can be paid.
- The 59GHz oscilloscope has arrived. Those who want to test it, please take a look.
- [Hua Diao Experience] 02 Simple use of Xingkong board
- TI live broadcast at 8pm tonight [Innovation of next-generation automotive gateway system]