| 标准编号 | PLAN20191065-T-339-2020 (PLAN20191065-T-339-2020) | | 中文名称 | 汽车信息安全通用技术要求 | | 英文名称 | [20191065-T-339 Draft version] General cybersecurity technical requirements for road vehicles | | 行业 | Chinese Industry Standard | | 字数估计 | 17,186 | PLAN20191065-T-339-2020: 汽车信息安全通用技术要求
PLAN20191065-T-339-2020 英文名称: [20191065-T-339 Draft version] General cybersecurity technical requirements for road vehicles
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会
汽车信息安全通用技术要求
中华人民共和国国家标准
1 范围
本标准规定了汽车信息安全的保护对象和技术要求。
本标准适用于M类、N类汽车整车及其电子电气零部件。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于
本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 29246-2017 信息技术 安全技术信息安全管理体系 概述和词汇
GB/T 34590.3-2017 道路车辆 功能安全 第三部分：概念阶段
3 术语和定义
GB/T 29246-2017界定的以及下列术语和定义适用于本文件。下面定义中列出了标准的出处，
所以导语内容不全
5 保护对象
5.1 总则
汽车作为保护对象可划分为三类子保护对象：车内系统、车外通信和车外系统，如图1所示。
5.2 车内系统
车内系统分为如下子保护对象：
a) 软件系统；
b) 电子电气硬件；
c) 车内数据；
d) 车内通信。
注：车内通信即车内零部件之间的通信，包括但不限于CAN通信，LIN通信，以太网通信等。
5.3 车外通信
车外通信分为如下子保护对象：
a) 车外远距离通信；
b) 车外近距离通信。
注1：车外通信即整车与车外终端的通信。
注2：车外远距离通信如蜂窝移动通信、卫星导航等。
注3：车外近距离通信如OBD、蓝牙、近场无线通信和Wifi等。
6 技术要求
6.1 原则性要求
6.1.1 业务适用性原则
产品的信息安全设计应充分考虑业务或者功能环境的实际需求，功能或者业务的正常使用不应
受到信息安全设计的影响。
6.1.2 软件无后门原则
软件系统不应留有后门。
6.1.3 功能最小化原则
无用的软件组件、协议端口和ECU硬件调试口应禁用或者移除，不宜暴露器件的管脚信息。
6.1.4 最小化授权原则
产品的访问和信息处理活动应只授予必要的权限。
6.1.5 权限分离原则
重要保护对象的信息处理活动应具备两个或两个以上的权限，且权限应相互分离和单独授予。
示例：用户要进行某项保护对象的操作，同时具有登录系统的合法身份和该保护对象的操作权限。
6.1.6 默认设置原则
产品应完成默认的信息安全设置，该设置对用户的信息安全设置诉求应做到最小化和最简单化。
6.2 系统性防御策略要求
6.2.1 总则
产品应至少采用一种如下的系统性防御策略：
a) 纵深防御；
b) 主动防御；
c) 系统的韧性。
注：系统性防御策略，是基于构建系统的整体信息安全防护考虑，所采取的整体防御策略，避免因各个信息安全
防护措施相互孤立而造成整体防护能力不足的问题。
6.2.2 纵深防御要求
纵深防御要求符合以下要求：
a) 根据保护对象所处的环境条件和信息安全管理的要求，应对保护对象实施由外到里或由里
到外，层层设防的防护措施。
b) 各层次的安全措施应相互依托，形成系统化的防护机制，从而提高系统的整体抗攻击能力。
6.2.3 主动防御要求
主动防御应采用包括不限于情报分享、入侵检测技术、信息安全策略动态调整和各信息安全模
块之间的协同措施，使信息系统在发生异常行为时降低其所面临的风险。
6.2.4 系统的韧性要求
信息安全设计应综合考虑可靠性、功能安全等多个方面的工程设计，以提高系统的生存能力和
自愈能力。
6.3 保护维度技术要求
6.3.1 车内系统的保护要求
6.3.1.1 软件系统的保护要求
6.3.1.1.1 真实性要求
软件系统符合以下真实性要求：
a) 在软件、固件和配置文件的升级、加载和安装时，应验证提供方的身份真实性和来源的合
法性。
b) 软件系统应验证登录用户身份的真实性和合法性。
6.3.1.1.2 保密性要求
重要软件系统应防止被逆向分析，宜采用代码混淆或加壳等措施。
6.3.1.1.3 完整性要求
软件系统符合以下完整性要求：
a) 软件、固件和配置文件的升级、加载和安装时，应验证其完整性。
b) 软件系统启动和运行时，应验证其完整性。
6.3.1.1.4 可用性要求
当软件系统设计为符合GB/T 34590.3-2017中ASIL C和 D级时，其应支持防DoS/DDoS攻击。。
6.3.1.1.5 访问可控性要求
软件系统符合以下访问可控性要求：
a) 应具备访问权限控制的管理机制。
b) 应验证对各软件资源和数据资产的访问、操作和使用的权限。
c) 应验证软件、固件和配置文件的升级、加载和安装的权限。
6.3.1.1.6 抗抵赖性要求
软件系统应具有在请求的情况下为数据原发者或接收者提供数据原发证据和数据接收证据的功
能。
6.3.1.1.7 可核查性要求
软件系统符合以下可核查性要求：
a) 应对包括不限于用户活动和操作指令的重要信息安全事件进行记录，记录内容宜包含事件
的时间、用户、事件类型、事件成功情况的信息。
b) 应保护审计日志不被非法篡改、删除和伪造。
6.3.1.1.8 可预防性要求
软件系统应具备对自身受到信息安全攻击的感知能力，当受到信息安全攻击时，宜进行日志记
录、信息安全告警或攻击阻止的响应。
6.3.1.2 电子电气硬件保护要求
6.3.1.2.1 保密性要求
电子电气硬件符合如下保密性要求：
a) 印制电路板上关键信号的线路应在内层走线。
b) 应去除印制电路板上具有标识作用的丝印设计。
6.3.1.2.2 完整性要求
对关键ECU的封装（外壳、封条等）应采用完整性保护。
6.3.1.2.3 访问可控性要求
不必要的调试接口应被移除或者禁止。
6.3.1.3 车内数据保护要求
6.3.1.3.1.1 保密性要求
安全重要参数应符合如下保密性要求：
a) 不应以明文方式传输。
b) 应存储在安全的环境中。
6.3.1.3.1.2 完整性要求
安全重要参数应支持完整性校验。
6.3.1.3.1.3 可用性要求
安全重要参数应防止丢失和被误删除，宜采用备份或专用安全空间存储等措施。
6.3.1.4 车内通信的保护要求
6.3.1.4.1 真实性要求
车内通信应验证通信双方身份的真实性
6.3.1.4.2 保密性要求
车内通信数据应进行加密。
6.3.1.4.3 完整性要求
车内通信数据应采用完整性保护。
6.3.1.4.4 可用性要求
车内通信应具备通信流量控制能力。
6.3.1.4.5 访问可控性要求
车内通信应符合如下访问可控性要求：
a) 应将车内网络划分为不同的信息安全区域，每个信息安全区域之间宜进行网络隔离。
b) 信息安全区域间应采用边界访问控制机制对来访的报文进行控制。
6.3.1.4.6 可核查性要求
车内通信应具备日志记录的能力。
6.3.1.4.7 可预防性要求
车内通信应对异常报文具有感知能力，当感知到异常报文时，宜具有告警或者其他安全响应的
能力。
6.3.2 车外通信的保护要求
6.3.2.1 车外远距离通信的保护要求
6.3.2.1.1 真实性要求
车外远距离通信符合如下真实性要求：
a) 应开启 3G、4G、5G通信网络层的双向认证功能。
b) 蜂窝移动通信网络层之上应支持独立的双向认证机制。
6.3.2.1.2 保密性要求
车外远距离通信符合如下保密性要求：
a) 应具备 3G、4G、5G通信网络层的加密功能。
b) 蜂窝移动通信网络层之上应支持独立的加密机制，应采用 TLS1.2版本及以上的安全协议进
行加密。
6.3.2.1.3 完整性要求
车外远距离通信符合如下完整性要求：
a) 应具备 3G、4G、5G通信网络层的完整性保护功能。
b) 蜂窝移动通信网络层之上应支持独立的完整性机制，应采用 TLS1.2版本及以上安全协议进
行完整性保护。
6.3.2.1.4 可用性要求
车外远距离通信符合如下可用性要求：
a) 与外部通信的部件应支持防 DoS/DDoS攻击。
b) 应支持抗无线干扰。
6.3.2.1.5 访问可控性要求
车外远距离通信应具备对通信报文进行访问控制的能力。
6.3......
|