GB 44495-2024 English PDF

Delivery: 2 working-hours manually (Sales@ChineseStandard.net)
Need delivered in 3-second? USA-Site: GB 44495-2024
Get Quotation: Click GB 44495-2024 (Self-service in 1-minute)
Historical versions (Master-website): GB 44495-2024
Preview True-PDF (Reload/Scroll-down if blank)

GB 44495-2024: Technical requirements for vehicle cybersecurity
GB 44495-2024
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 43.020
CCS T 40
Technical requirements for vehicle cybersecurity
ISSUED ON: AUGUST 23, 2024
IMPLEMENTED ON: JANUARY 01, 2026
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of China.
Table of Contents
Foreword ... 3
1 Scope ... 4
2 Normative references ... 4
3 Terms and definitions ... 4
4 Abbreviated terms ... 6
5 Requirements for vehicle cybersecurity management system ... 7
6 Basic requirements for cybersecurity ... 8
7 Technical requirements for cybersecurity ... 9
8 Inspection and test methods ... 14
9 Same type determination ... 26
10 Implementation of standards ... 27
Bibliography ... 28
Technical requirements for vehicle cybersecurity
1 Scope
This document specifies the requirements for vehicle cybersecurity management
system, basic requirements for cybersecurity, technical requirements for cybersecurity
and same type identification, and describes the corresponding inspection and test
methods.
This document applies to category M and category N vehicles, as well as category O
vehicles that are equipped with at least one electronic control unit.
2 Normative references
The following documents are referred to in the text in such a way that some or all of
their content constitutes requirements of this document. For dated references, only the
version corresponding to that date is applicable to this document; for undated references,
the latest version (including all amendments) is applicable to this document.
GB/T 40861, General technical requirements for vehicle cybersecurity
GB/T 44373, Intelligent and connected vehicle - Terms and definitions
GB/T 44464-2024, General requirements of vehicle data
GB 44496, General technical requirements for software update of vehicles
3 Terms and definitions
Terms and definitions given in GB/T 40861, GB/T 44373 and GB 44496, as well as the
following, are applicable to this document.
3.1
vehicle cybersecurity
The state where the vehicle's electrical and electronic systems, components and
functions are protected from asset threats.
[Source: GB/T 40861-2021, 3.1]
3.2
cybersecurity management system; CSMS
● Establishing a process to evaluate whether implemented cybersecurity
measures remain effective in the event of the discovery of new cyber-
attacks, cyber threats, and vulnerabilities.
-- Establish a process to manage cybersecurity dependencies between the
enterprise and contract suppliers, service providers, and vehicle manufacturer
sub-organizations.
6 Basic requirements for cybersecurity
6.1 The vehicle product development process shall comply with the requirements for
vehicle cybersecurity management system.
6.2 The vehicle manufacturer shall identify and manage risks associated with vehicles
and suppliers.
6.3 The vehicle manufacturer shall identify the key elements of the vehicle, conduct
risk assessments on the vehicle, and manage the identified risks.
Note 1: The scope of risk assessment includes the various elements of the vehicle and
their interactions, and further considers the interactions with external systems.
Note 2: Key elements include, but are not limited to, elements that contribute to
vehicle security, environmental protection or theft prevention, as well as
system components that provide connectivity or parts of the vehicle
architecture that are critical to cybersecurity.
6.4 The vehicle manufacturer shall take measures based on the requirements of Chapter
7 to protect the vehicle from the risks identified in the risk assessment. If the measures
are not relevant to the identified risks, the vehicle manufacturer shall explain their
irrelevance. If the measures are not sufficient to address the identified risks, the vehicle
manufacturer shall implement other measures and explain the rationality of the
measures used.
6.5 If there is a dedicated environment, the vehicle manufacturer shall take measures to
protect the dedicated environment used by the vehicle to store and execute post-
installed software, services, applications or data.
Note: Such as sandbox dedicated environment, etc.
6.6 The vehicle manufacturer shall verify the effectiveness of the cybersecurity
measures implemented through testing.
6.7 The vehicle manufacturer shall implement appropriate measures for the vehicle to
ensure the following capabilities:
-- Ability to identify vehicle cyber-attacks;
-- Monitoring and data forensics capabilities for vehicle-related cyber-attacks,
cyber threats and vulnerabilities.
6.8 The vehicle manufacturer shall use public, published, and effective cryptographic
algorithms and select appropriate parameters and options based on different
cryptographic algorithms and service scenarios.
6.9 The vehicle manufacturer shall meet one of the following requirements for
cryptographic modules:
-- Adopt cryptographic modules that comply with international, national or
industry standards;
-- For the cryptographic modules not adopting international, national or industry
standards, explain the rationality.
6.10 Vehicles shall adopt default security settings. For example, the default connection
password of WLAN shall meet the complexity requirements.
6.11 Requirements such as in-vehicle data processing, non-collection by default,
application of accuracy range, desensitization processing, personal consent and
prominent notification in motor vehicle data processing activities shall comply with the
provisions of 4.2.2 in GB/T 44464-2024.
7 Technical requirements for cybersecurity
7.1 Security requirements for external connections
7.1.1 General security requirements
7.1.1.1 Vehicle-side systems with remote control functions, authorized third-party
applications and other external connection systems shall not have high-risk or higher
security vulnerabilities that have been announced by the authoritative vulnerability
platforms of the automotive industry for 6 months and have not been handled.
Note 1: Authoritative vulnerability platforms of the automotive industry refer to
NVDB-CAVD, a vulnerability database specifically for Internet of Vehicles,
and other vulnerability platforms approved by government authorities.
Note 2: Handling includes methods such as eliminating loopholes and formulating
mitigation measures.
7.1.1.2 Vehicles shall turn off network ports that are not essential for service operations.
7.1.2 Security requirements for remote controls
7.1.2.1 The authenticity and integrity of remote-control commands shall be verified.
7.2.1 When a vehicle communicates with the vehicle manufacturer’s cloud platform,
the authenticity of the identity of the communication partner shall be verified.
7.2.2 When vehicles conduct V2X direct communications with other vehicles, road side
units, mobile terminals, etc., the validity and legality of the certificates shall be verified.
7.2.3 Vehicles shall use integrity protection mechanisms to protect external wireless
communication channels other than RFID and NFC.
7.2.4 The vehicle shall have an access control mechanism for data operation commands
from the vehicle's external communication channels.
Note: Data operation commands from the vehicle's external communication channels
include code injection, data manipulation, data overwriting, data erasing and
data writing commands.
7.2.5 The vehicle shall verify the validity or uniqueness of the received external key
command data.
Example: For vehicle control commands sent by the remote-control server, the vehicle
side can verify the validity or uniqueness of such commands through the gateway.
Note: Critical command data refers to command data that may affect driving and
property security, including but not limited to vehicle control command data.
7.2.6 The vehicle shall implement confidentiality protection measures for sensitive
personal information sent outside the vehicle.
7.2.7 The vehicle shall be provided with a security mechanism to defend against
physical manipulation attacks, and at least an identity recognition mechanism for
vehicle-to-everything components.
Note: Vehicle-to-everything components include but are not limited to vehicle
information interaction systems, etc., but do not include short-range wireless
sensors.
7.2.8 Vehicle-to-everything components shall have security mechanisms to prevent
unauthorized privileged access.
Note: Unauthorized users may be able to gain root or privileged user privileges on the
system through the debug interface.
7.2.9 The vehicle shall divide the internal network into domains and protect the
boundaries between domains. The cross-domain requests in the vehicle internal
network shall be subject to access control and follow the default denial principle and
the minimum authorization principle.
Note: Protection measures for boundaries between domains include physical isolation,
logical isolation (such as whitelists, firewalls, VLANs), etc.
7.2.10 The vehicle shall be able to identify when the vehicle communication channel is
under denial-of-service attack and handle the attack accordingly.
Note 1: Attack handling includes interception or discarding of attack data packets,
automatic recovery of affected systems, logging, etc.
Note 2: Vehicle communication channels include mobile cellular communication,
V2X, CAN bus, vehicle Ethernet, etc.
7.2.11 The vehicle shall be able to identify malicious V2X data and malicious diagnostic
data and take protective measures.
Note: V2X data includes data sent from the road side unit to the vehicle and data
between vehicles.
7.2.12 It shall have the function of recording key communication cybersecurity event
logs, and the log storage period shall be no less than 6 months.
Note: Critical communication cybersecurity events are determined by the vehicle
manufacturer based on the results of risk assessment, and the log records include
event time, event cause, etc.
7.3 Security requirements for software upgrade
7.3.1 General security requirements
7.3.1.1 The on-board software update system shall use security protection mechanisms
to protect the trusted root, boot loader, and system firmware of the on-board software
update system from being tampered with; if tampered with, the security protection
mechanism shall be used to prevent them from starting normally.
7.3.1.2 The on-board software update system shall not have high-risk or higher security
vulnerabilities that were announced by the authoritative vulnerability platform of the
automotive industry 6 months ago and have not been handled.
Note 1: Authoritative vulnerability platform of the automotive industry refer to
NVDB-CAVD, a vulnerability database specifically for Internet of Vehicles,
and other vulnerability platforms approved by government authorities.
Note 2: Handling includes methods such as eliminating loopholes and formulating
mitigation measures.
7.3.2 Security requirements for over-the-air upgrade
7.3.2.1 The vehicle and over-the-air upgrade server shall be authenticated to verify the
authenticity of their identities and re-authenticated when the download is interrupted
and resumed.
Note: Common authentication methods include using certificates for identity
authentication.
7.3.2.2 The vehicle shall verify the authenticity and integrity of the downloaded
upgrade package.
7.3.2.3 Cybersecurity event logs that occur during the over-the-air upgrade process shall
be recorded and the log storage period shall be no less than 6 months.
7.3.3 Security requirements for offline upgrade
7.3.3.1 If the vehicle uses the on-board software upgrade system for offline upgrade,
the vehicle shall verify the authenticity and integrity of the offline upgrade package.
7.3.3.2 If the vehicle does not use the on-board software upgrade system for offline
upgrade, protective measures shall be taken to ensure the security of the flash access
terminal, or authenticity and integrity of the upgrade package shall be verified.
7.4 Data security requirements
7.4.1 The vehicle shall adopt secure access technology or secure storage technology to
protect the stored symmetric keys and private keys in asymmetric keys to prevent
unauthorized access and acquisition.
7.4.2 The vehicle shall adopt secure access technology, encryption technology or other
security technologies to protect sensitive personal information stored in the vehicle to
prevent unauthorized access and acquisition.
7.4.3 The vehicle shall adopt security defense mechanisms to protect the VIN and other
vehicle identification data stored in the vehicle to prevent unauthorized deletion and
modification.
Note: Security defense mechanisms to prevent data from being deleted and modified
without authorization include secure access technology, read-only technology,
etc.
7.4.4 The vehicle shall adopt security defense mechanisms to protect key data stored in
the vehicle to prevent it from being deleted and modified without authorization.
Note: Key data include key configuration parameters such as braking parameters,
airbag expansion thresholds, power battery parameters, and other data generated
during vehicle operation that may affect driving safety.
8.2.1.2 The submitted documents shall be in Chinese and shall contain at least the
following:
-- Summary document demonstrating that the vehicle meets the requirements of
Chapter 6;
-- A list of documents to be retained for future reference that specifies the
document version information.
8.2.1.3 The vehicle manufacturer shall retain vehicle cybersecurity-related process
documents locally in a secure manner for reference, and shall prevent the retained
documents from tampering with, after completing the inspection.
8.2.1.4 The vehicle manufacturer shall make a self-declaration on the consistency and
traceability of the documents submitted and retained for reference with the vehicle.
8.2.2 Inspection methods
8.2.2.1 Inspect the documents submitted by t...