GB/T 40861-2021General Technical Requirements for Vehicle Cybersecurity

Foreword

This Document was drafted as per the rules specified in GB/T 1.1-2020 Directives for Standardization – Part 1: Rules for the Structure and Drafting of Standardizing Documents.

Please note some contents of this Document may involve patents. The issuing agency of this Document shall not assume the responsibility to identify these patents.

This Document was proposed by Ministry of Industry and Information Technology of the PRC.

This Document shall be under the jurisdiction of National Technical Committee for Standardization of Automobile (SAC/TC 114).

Drafting organizations of this Document: Zhejiang Geely Holding (Group) Co., Ltd.; Huawei Technologies Co., Ltd.; China Automobile Technology and Research Centre Co., Ltd.; Beijing Qihoo Technology Co., Ltd.; Daimler Greater China Ltd.; PSA Peugeot Citroen (China) Automotive Trading Co., Ltd. Shanghai Branch; Pan Asia Technical Automotive Centre Co., Ltd.; Guangzhou Automobile Group Co., Ltd.; Centre of Computer & Micro-Electronics Industry Development of MIIT; BMW China Services Ltd.; Volkswagen (China) Investment Co., Ltd.; Neusoft Corporation; Continental Holding China Co., Ltd.; Beijing Ypgreat Technology Limited.; China Academy of Information and Communications Technology; Dongfeng Motor Corporation Technical Centre; and China First Automobile Group Co., Ltd.

Chief drafting staffs of this Document: Yin Yang, Zhang Xuwu, Zhang Hang, Zhang Rongbo, Pan Kai, WU Hanbing, Zhang Yi, Lv Ming, Feng Zhimin, Feng Haitao, Zhang Jinchi, Guo Ying, Wang Zhe, Zhao Wen, Cheng Jingxiang, Yang Wenchang, Lu Zuohua, Sun Yaping, Li Yan, and Gao Changsheng.

Introduction

With the rapid development and application of intelligent and networking technologies, automobiles have gradually evolved from relatively isolated electromechanical systems to intelligent systems that can interact with the outside world. Information security issues derived from automobile networking have followed.

Different from the information security of communications and other industries that mainly cause property losses, as a high-speed vehicle for manning and carrying objects, when automobile information security problems occur, it shall not only cause property losses, but also seriously threaten personal and public safety.

Based on the hazards and incentives of automobile information security risks, this Document formulates general technical requirements for the protected objects (the technical requirements of the entire automobile and its electronic and electrical systems and components can be determined based on the function design and risk assessment results); is used in conjunction with other management requirements standards; and guides the establishment of an automotive information security technology system. The standard framework is shown in Figure 1. While stipulating basic technical requirements such as principled requirements and systemic defence strategy requirements, specific technical requirements for sub-protected objects are formulated from the following eight dimensions:

1 Scope

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.

3 Terms and Definitions

3.1 Vehicle cybersecurity

The electronic and electrical systems, components and functions of the vehicle are protected, so that its assets are not threatened.

3.2 Authenticity

An entity is a characteristic of the entity it claims.

3.3 Confidentiality

The characteristic that information is unavailable or non-disclosed to unauthorized individuals, entities, or processes.

3.5 Availability

Accessible and usable characteristics according to the requirements of authorized entities.

3.6 Access controllability

The characteristic that is authorized and restricted based on the business and security requirements to ensuring the access to the asset.

3.7 Non-repudiation

The ability to prove the occurrence and origin of the alleged state of affairs or behaviour.

3.8 Accountability

The characteristic that ensures the behaviour of an entity can be uniquely traced back to that entity.

3.11 Distributed denial of service; DDoS

The denial of service is realized by damaging or controlling multiple systems to take flood attack on the bandwidth and resources of the target system.

3.12 Backdoor

The channel that can bypass the management and control of security mechanisms such as system authentication and enter the information system.

3.13 Security important parameter

Security-related information includes authentication data such as secret keys and private keys, passwords, or other password-related parameters information.

3.14 Access control

The manner that ensures the access to assets is authorized and restricted based on business and security requirements.

4 Abbreviations

The following abbreviations are applicable to this Document.

5 Protected Objects

5.1 General

According to the category of protected objects, automobiles can be divided into three types of sub-protected objects: in-vehicle systems, out-of-vehicle communications, and out-of-vehicle systems, as shown in Figure 2.

NOTE 1: This document does not involve out-of-vehicle systems.

communications are listed in Appendix A, A.1 and A.2.

5.2 In-vehicle system

The in-vehicle system is divided into the following sub-protected objects:

NOTE: In-vehicle communication is the communication between in-vehicle systems and components, such as CAN communication, LIN communication, Ethernet communication, 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.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

6.2.1 General

The product can adopt one of the following systemic defence strategies:

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.3 Requirements for active defence

The active defence shall adopt measures including but not limited to intelligence sharing, intrusion detection technology, dynamic adjustment of information security strategies, and coordination among various information security modules to reduce the risks faced by information systems when they are attacked by networks. […]

6.2.4 Requirements for resilience defence

Information security design shall comprehensively consider reliability, functional safety and other aspects of engineering design to improve the survivability and self-healing ability of the system.

6.3 Protection dimension requirements

6.3.1 Protection requirements for the in-vehicle system

6.3.1.1 Protection requirements for software systems

6.3.1.1.1 Authenticity

The software system shall meet the following authenticity requirements:

identity and the legitimacy of the source;

b) Verify the authenticity and legitimacy of the login user identity.

6.3.1.1.3 Integrity

When the software system is started, upgraded, loaded and installed, its integrity shall be verified.

6.3.1.1.4 Availability

When the design of software system complies with the Level-C and Level-D of ASIL in GB/T 34590.3-2017, it shall support anti-DoS/DDoS attacks.

6.3.1.1.5 Access controllability

The software system shall meet the following access controllability requirements:

a) Have a management mechanism for access control;

b) Verify the authority to access, operate and use various software system resources and data assets;

c) Verify the authority to upgrade, load and install the software system.

6.3.1.1.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.

6.3.1.2 Protection requirements for electronic and electrical hardware

6.3.1.3 Protection requirements for in-vehicle data

6.3.1.3.2 Integrity

Security Important parameters shall support integrity verification.

6.3.1.4 Protection requirements for in-vehicle communication

6.3.2 Protection requirements for out-of-vehicle communication

6.3.2.1 Protection requirements for long-distance communication outside the vehicle

6.3.2.2 Protection requirements for short-distance communication outside the vehicle

Appendix A Information Security Threats

A.1 Information security threats to in-vehicle system

Table A.1 lists the information security threats that software system may face.

Users access the software system through unauthorized means, including two aspects:

accessing data and files outside the permissions;

b) Use the system access mechanism to set up inappropriate vulnerabilities (such as not setting the minimum permissions for the user), and access resources that should not be accessed identity authentication or the default account password has not been modified The attacker uses insecure remote access or control components in the software system (such as Telnet, FTP, TFTP, and other remote-control components that do not require strong authentication and unencrypted transmission) to remotely and illegally access the in-vehicle system The attacker discovers and exploits hidden services and ports such as unused components and protocol ports in the software system that have not been removed or prohibited in the functional business to attack the system The attacker manipulates the software upgrade confirmation mechanism to make the software system reject normal software upgrades or allow the vehicle to stop at an inappropriate time and place for software upgrades upgrade software package to interfere with the normal operation of the vehicle vehicle The software system of the vehicle does not have a sufficiently complete information security log or other event recording system, which leads to the inability to perceive attacks and abnormal behaviours, and brings difficulties to the investigation, evidence collection and traceability of information security accidents after the event.

measures, so that attackers can use brute force to directly crack the accessed account and password received input command, resulting in an injection attack The attacker illegally enters the in-vehicle software system through "backdoor" (such as: key combinations, special mouse clicks, connection to specific interfaces, use of specific clients, use of special URLs, hidden access accounts, hidden remote access channels, etc.)

behaviours that it faces, causing users or back-end servers to be unable to take timely countermeasures

A.1.2 Examples of information security threats to hardware

Table A.2 lists the information security threats that electrical and electronic hardware may face. store important security parameters such as keys and user authentication biometric information, which leads to leaks of the secret. For example, leaking secrets through OS memory; […]

Bibliography