GB/T 40861-2021 English PDF (GBT40861-2021)
GB/T 40861-2021 English PDF (GBT40861-2021)
GB/T 40861-2021: General technical requirements for vehicle cybersecurity
NATIONAL STANDARD OF THE
PEOPLE REPUBLIC OF CHINA
CCS T 40
General Technical Requirements for Vehicle
ISSUED ON: OCTOBER 11, 2021
IMPLEMENTED ON: MAY 01, 2022
Issued by: State Administration for Market Regulation;
Standardization Administration of PRC.
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 6
2 Normative References ... 6
3 Terms and Definitions ... 6
4 Abbreviations ... 8
5 Protected Objects ... 9
5.1 General ... 9
5.2 In-vehicle system... 9
5.3 Out-of-vehicle communication ... 10
6 Technical Requirements ... 10
6.1 Principled requirements ... 10
6.2 Systematic defence strategy requirements ... 11
6.3 Protection dimension requirements ... 12
Appendix A (Informative) Information Security Threats ... 18
Bibliography ... 23
General Technical Requirements for Vehicle
This Document specifies the protected objects and technical requirements of vehicle cybersecurity.
This Document is applicable to M and N categories of vehicles, their electrical and electronic systems and components.
2 Normative References
The provisions in following documents become the provisions of this Document through reference in this Document. For the dated documents, only the versions with the dates indicated are applicable to this Document; for the undated documents, only the latest version (including all the amendments) is applicable to this Document. GB/T 29246-2017 Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary
GB/T 34590.3-2017 Road Vehicles - Functional Safety - Part 3: Concept Phase 3 Terms and Definitions
For the purposes of this Document, the terms and definitions given in GB/T 29246- 2017 and the following apply.
3.1 Vehicle cybersecurity
The electronic and electrical systems, components and functions of the vehicle are protected, so that its assets are not threatened.
An entity is a characteristic of the entity it claims.
[Source: GB/T 29246-2017, 2.8, modified]
a) Software system;
b) Electrical and electronic hardware;
c) In-vehicle data;
d) In-vehicle communication.
NOTE: In-vehicle communication is the communication between in-vehicle systems and components, such as CAN communication, LIN communication, Ethernet communication, etc. 5.3 Out-of-vehicle communication
The out-of-vehicle communication is divided into the following sub-protected objects: a) Long-distance communication outside the vehicle;
b) Short-distance communication outside the vehicle.
NOTE 1: The out-of-vehicle communication refers to the communication between the entire vehicle and the terminal outside the vehicle.
NOTE 2: The long-distance communication outside the vehicle refers to cellular mobile communication, satellite navigation, etc.
NOTE 3: The short-distance communication outside the vehicle refers to Bluetooth, near-field wireless communication and Wi-Fi, etc.
6 Technical Requirements
6.1 Principled requirements
6.1.1 Principle of business suitability
The information security design of the product shall be combined with the actual needs of the business or functional environment, while considering the impact on the normal use of the business or function.
6.1.2 Principle of no backdoor for software
The software system shall not have a backdoor.
6.1.3 Principle of function minimization
The useless software components, protocol ports, and ECU hardware debugging interfaces shall be disabled or removed; device pin information should not be exposed. 6.1.4 Principle of minimize authorization
Only necessary permissions shall be granted for product access and information processing activities.
6.1.5 Principle of permissions separation
The information processing activities of important protected objects shall have two or more authorities; and each authority shall be separated from each other and granted separately.
6.1.6 Principle of default settings
The product shall complete the default information security settings; this setting shall minimize and simplify the user's information security requirements.
6.2 Systematic defence strategy requirements
The product can adopt one of the following systemic defence strategies: a) Defence-in-depth;
b) Active defence;
c) Resilient defence.
NOTE: Systematic defence strategy is an overall defence strategy based on constructing the overall information security protection of the system to avoid the problem of insufficient overall protection capabilities due to the isolation of various information security protection measures. 6.2.2 Requirements for Defence-in-depth
The Defence-in-depth meets the following requirements:
a) According to the environmental conditions of the protected object and the requirements of information security management, protective measures shall be implemented from the outside to the inside for the protected object at various levels;
b) Security measures at all levels shall rely on each other to form a systematic protection mechanism, thereby improving the overall anti-attack capability of the system.
6.2.3 Requirements for active defence
The active defence shall adopt measures including but not limited to intelligence c) Verify the authority to upgrade, load and install the software system. 188.8.131.52.6 Non-repudiation
The software system shall have the function of providing evidence of data origin and data receipt to the originator or recipient of the data upon request.
EXAMPLE: Using digital signature technology, etc.
The software system shall meet the following accountability requirements: a) Record important information security events, including but not limited to user activities and operating instructions; the content of the record should include information such as the time of the event, the user, the type of the event, and the result of the event;
b) Protect the audit log from illegal tampering, deletion and forgery.
The software system shall have the ability to perceive information security attacks on itself. When an information security attack is detected, it should respond with log records, information security alarms or attack prevention.
184.108.40.206 Protection requirements for electronic and electrical hardware
Integrity protection shall be adopted for the ECU package (case, seal, etc.). EXAMPLE: Use a seal that shall leave a sign when it is opened.
220.127.116.11.2 Access controllability
Electronic and electrical hardware shall remove or prohibit unnecessary debugging interfaces.
NOTE: In order to better understand the technical requirements of the protected objects in different dimensions, the typical security threats faced by the in-vehicle hardware are listed in A.1.2.
18.104.22.168 Protection requirements for in-vehicle data
Important safety parameters shall meet the following confidentiality requirements: EXAMPLE: Using message filtering mechanism, message overload control mechanism and user access authority control mechanism, etc.
In-vehicle communication shall have the ability to log records.
Example: Record phenomena such as traffic overload and abnormal messages received at a high frequency.
In-vehicle communication shall have the ability to perceive abnormal messages; when abnormal messages are perceived, they should have the ability to alert or other safe responses.
EXAMPLE: Receiving abnormal phenomena such as high-frequency replay messages or messages that have been tampered.
6.3.2 Protection requirements for out-of-vehicle communication
22.214.171.124 Protection requirements for long-distance communication outside the vehicle
The long-distance communication outside the vehicle shall meet the following authenticity requirements:
a) Turn on the two-way authentication function of the 3G, 4G, and 5G
communication network layer;
b) An independent two-way authentication mechanism is supported on the cellular mobile communication network layer.
The long-distance communication outside the vehicle shall meet the following confidentiality requirements:
a) Possess encryption functions of 3G, 4G, and 5G communication network layer; b) The independent encryption mechanism is supported on the cellular mobile communication network layer, and the security protocol of TLS1.2 version and above should be adopted.
The long-distance communication outside the vehicle shall meet the following integrity requirements:
a) Possess the integrity protection function of the 3G, 4G, and 5G communication network layer;
b) The independent integrity mechanism is supported on the cellular mobile communication network layer, and the security protocol of TLS1.2 version and above should be adopted.
The components communicating with the outside shall support DoS/DDoS attacks. 126.96.36.199.5 Access controllability
The long-distance communication outside the vehicle shall have the ability to control the access of the communication message.
EXAMPLE: white-list access control, message filtering, anti-communication traffic overload mechanism, etc.
The long-distance communication outside the vehicle shall meet the following non- repudiation requirements:
a) Ensure the uniqueness of the communication ID of the cellular mobile communication network layer (such as: International Mobile Subscriber Identity IMSI, Integrated Circuit Card Identity ICCID, etc.);
b) The independent non-repudiation mechanism (such as the use of a certificate mechanism, etc.) is supported on the cellular mobile communication network layer.
The long-distance communication outside the vehicle shall have the ability to monitor the security of communication messages and the ability to perceive attack behaviour; when the information security is attacked, it should carry out the response to the message cleaning, flow control or prevent the attack behaviour.
188.8.131.52 Protection requirements for short-distance communication outside the vehicle
The identity authentication function shall be turned on for short-distance