路径: 主页 > MISC > 第332页 > TCSAE101-2018 | 标准编号 | T/CSAE 101-2018 (T/CSAE101-2018) | | 中文名称 | 智能网联汽车车载端信息安全技术要求 | | 英文名称 | Intelligent and Connected Vehicles On-Board Terminal Cyber Security Technical Requirements | | 行业 | Chinese Industry Standard | | 中标分类 | T47 | | 字数估计 | 18,111 | | 发布日期 | 6/19/2018 | | 发布机构 | 中国汽车工程学会 | T/CSAE 101-2018: 智能网联汽车车载端信息安全技术要求
T/CSAE 101-2018 英文名称: Intelligent and Connected Vehicles On-Board Terminal Cyber Security Technical Requirements
Intelligent and Connected Vehicles On-Board Terminal Cyber Security
Technical Requirements
智能网联汽车车载端信息安全技术要求
1 范围
本标准规定了智能网联汽车车载端信息安全技术要求。智能网联汽车车辆整体信息安全技术要
求及车联网相关的云端信息安全技术要求、通信协议信息安全技术要求不在本标准的范围之内。
本标准仅适用于具备联网功能的车载端，联网范畴包括车载移动互联网、车际网和车内网。
本标准适用但不限于车载 T-BOX、车载信息娱乐系统 In-Vehicle Infotainment（IVI）等车载端信息系统。
5 车载端安全技术要求
5.1 整体安全性
5.1.1 安全技术的选择与实施
5.1.1.1 应通过风险评估过程，全面分析网联接口与威胁攻击路径，明确车辆整体安全需求与
车载端安全需求，综合选择身份认证、访问控制、检测响应等多种技术措施对车载端自身进行安全
防护，并将车载端安全防护作为车辆整体安全防护体系的有机组成部分，以实现车辆整体安全目标
（例如：确保驾驶员和交通参与人员的人身安全）。
5.1.1.2 应综合考虑整体网络安全防护需求，车载端的安全技术措施能够有效地与云端安全技
术措施和通信网络安全技术措施相配合。
5.1.1.3 车载端安全技术措施的选择和实施，应与整车设计开发验证测试流程紧密结合。
5.2 硬件安全
5.2.1 设计安全
5.2.1.1 车载端系统所使用的芯片不能存在可以非法对芯片内存进行访问或者更改芯片功能的
隐蔽接口。芯片在设计验证阶段使用的调试接口应在上市产品中禁用。
5.2.1.2 车载端系统的电路板不能存在用以标注芯片、端口和管脚功能的可读丝印。
5.2.1.3 车载端系统芯片之间敏感数据的通信线路应尽量隐蔽（例如：使用多层电路板的车载
端系统采用内层布线方式隐藏通信线路），对抗针对车载端内部数据传输的窃听和伪造攻击。
5.2.1.4 车载端所使用的关键芯片应尽量减少暴露管脚（例如：采用 BGA/LGA 封装的芯片）。
5.2.2 访问控制
5.2.2.1 车载端具备硬件实现的安全区域或安全模块，实现车载端设备重要数据安全存储与隔离。
5.2.2.2 在安全区域或安全模块中一次性写入的敏感信息，应保证无法非授权获取或者篡改。
5.2.2.3 安全区域或安全模块应具备检测与处置非授权访问的能力，对抗暴力破解。
5.2.3 抗攻击防护
5.2.3.1 使用必要的安全机制（例如：封装），防御针对芯片的电压、时钟、电磁、激光等方式的故障注入攻击。
5.2.3.2 使用必要的防护措施，对抗针对加密芯片的简单功耗分析（SPA）攻击、一阶差分功
耗分析（DPA）攻击、相关功耗分析（CPA）攻击，以及利用运行时间、温度等其它信息进行的侧信道攻击。
5.2.3.3 使用必要的防护机制，对抗针对车载端设备内存的侵入和篡改攻击。
5.3 操作系统安全
5.3.1 操作系统安全启动
5.3.1.1 应在安全存储区域存储操作系统签名。操作系统启动时应使用可信机制，在验证操作
系统签名并判定通过后，再从可信存储区域加载车载端操作系统，避免加载被篡改的操作系统。
5.3.2 多操作系统隔离
5.3.2.1 如车载端存在多个操作系统，须采用隔离机制，保证不同操作系统之间的安全防护。
5.3.3 操作系统加载应用程序
5.3.3.1 应提供安全机制，保证操作系统只能加载启动可信的车载端应用程序，能够验证应用
的来源和完整性，避免运行恶意程序。
5.3.4 系统安全防护
5.3.4.1 应采用完整性校验手段（例如：基于哈希算法的数字摘要技术或数字签名技术），对
关键代码或文件进行完整性保护。
5.3.4.2 车载端系统不存在后门，也不存在于“中国汽车行业漏洞共享平台（CAVD）”以及“国
家信息安全漏洞共享平台（CNVD）”发布了 6 个月及以上的高危安全漏洞。系统应具有能够及时
进行漏洞修复的方式。
5.3.5 资源访问控制
5.3.5.1 应采取适用于汽车各应用场景的告知和控制方式，实现当应用对系统敏感资源调用（例
如：使用位置信息）时用户可知。并提供设置开关，供用户同意或者拒绝该项调用。
5.3.5.2 通过可信执行环境，为基于敏感数据的关键应用提供安全执行空间，控制对关键资源
（例如：密钥、CAN 控制器）的访问，保护资源和数据的保密性和完整性，对抗非授权访问和篡改等多种攻击。
5.3.6 安全日志记录及审计控制
5.3.6.1 支持对操作系统关键事件的日志功能，记录事件的时间、对象、描述和结果等。
5.3.6.2 支持日志上传功能，上传时对云端进行认证；根据云端管理需求，采取安全的方式传
输日志，确保数据的完整性和可认证性。
5.3.6.3 应采取访问控制机制，对日志读取写入的权限进行管理；应对日志存储进行安全防护。
5.3.7 系统软件更新与固件更新
5.3.7.1 只接收在约定的工况（例如：非行驶状态）和车辆系统状态（例如：电瓶电量满足要求）
下发起的车载端操作系统和应用等软件的更新请求，并在用户确认后执行更新操作。
5.3.7.2 软件更新时，应能够对提供更新软件包的来源进行鉴别，并对接收到的更新文件进行
完整性校验。软件升级应不影响用户设置和用户数据。系统应具有备份和恢复能力，能够在软件更
新发生异常时进行必要的操作，避免更新失败导致系统失效。系统应对连续升级行为进行记录，设
定一段时间内升级尝试次数上限，避免通过车载端升级尝试对车辆资源进行过度消耗。
5.3.7.3 车载端在向其他车内系统或设备（例如：ECU）传输更新文件和更新命令的时候，应
能够及时声明自己的身份和权限，供车内系统或设备进行认证；只有认证通过后，操作才可以继续执行。
5.3.8 介质接口安全
5.3.8.1 车载端不应存在未经声明的外围介质（例如：CD/DVD、SD 卡、USB）接口。
5.3.8.2 车载端应定义通过外围接口接入的存储介质上的文件类型和权限，并限制通过介质接
口对车载端进行的操作类型。
5.3.8.3 应使用必要的方法，对可能修改系统配置或者运行状态的文件进行检测，并根据检测结果告警及处置。
5.4 应用软件安全
5.4.1 应用软件安全基本要求
5.4.1.1 通用应用软件不应存在后门，也不存在于“中国汽车行业漏洞共享平台（CAVD）”
以及“国家信息安全漏洞共享平台（CNVD）”发布了 6 个月及以上的高危安全漏洞。
5.4.1.2 应用软件不应含有非授权收集或泄露用户信息、非法数据外传等恶意行为。
5.4.1.3 应用不以明文形式存储用户敏感信息（例如：用户口令、证件号、交易口令、私钥）。
5.4.1.4 应用软件应使用安全机制（例如：混淆、加壳），对抗针对应用的逆向分析。
5.4.2 应用软件签名认证机制
5.4.2.1 应用软件应采用代码签名认证机制，且代码签名机制符合相关标准要求。
5.4.3 应用软件运行要求
5.4.3.1 关键应用程序在启动时应执行自检，检查程序运行时所必须的条件，确保程序自身和
所处运行环境的安全性。
5.4.3.2 应用软件运行期间，应具备运行验证及编译混淆能力，防止运行数据被非法分析或代码被非法执行。
5.4.3.3 使用安全机制，防止和检测应用软件之间不必要的访问，避免数据泄漏、非法提权等安全问题。
5.4.3.4 具备识别、阻断恶意软件的能力，隔绝已经被感染的文件，拒绝软件的恶意访问。
5.4.4 安全审计要求
5.4.4.1 应用程序应具备记录应用状态及使用情况的日志功能，并支持集中管理。
5.4.5 应用流程安全性要求
5.4.5.1 应用程序与服务器之间的交互，应使用安全通信协议（例如：TLS1.2）。
5.4.5.2 应用程序访问服务器需有双向认证机制。
5.5 对内通信安全
5.5.1 对车内子系统访问的安全控制
5.5.1.1 使用必要的技术手段，对包括车载端在内的车内各电子电气系统进行子系统或者域的
划分。子系统或者域应有不同的信息安全等级。
5.5.1.2 建立跨子系统或者域间通信的安全访问策略，车载端与高安全级别的子系统（例如：
动力系统）之间应采取访问控制措施。并通过与功能逻辑设计的配合，避免由于车载端的信息安全
问题造成该类子系统功能的错误或异常。
5.5.1.3 车载端应在与车内各电子电气系统的通信数据上加载身份标识，供其他车内电子电
系统验证。同时车载终端应具有验证所接收到的通信数据的发送方身份的能力。
5.5.2 对车内部通信可靠性和可用性的安全防护
5.5.2.1 车载端具备冗余备份和重发机制，保证对电子电气系统发送重要数据时（例如：ECU
固件升级包），传输数据的可靠性。
5.5.2.2 车载端向车内电子电气系统发送数据和转发数据时，应采用相应技术避免大量集中发
送数据包导致的总线拥塞和拒绝服务。
5.5.2.3 车载端应建立监测模块，实时监测向车内电子电气系统发送数据的数量与质量，对于
异常情况应及时发现并告警。
5.6 对外通信安全
5.6.1 蜂窝网络通信安全
5.6.1.1 车载端应使用安全机制，识别伪基站，确保接入真实可靠的蜂窝网络。
5.6.1.2 车载端与核心业务平台的通信应采用专用网络或者虚拟专用网络通信，与公网隔离。
5.6.1.3 车载端应能够识别来自蜂窝网络的非法连接请求，过滤恶意数据包。
5.6.1.4 车载端应采取技术措施，禁用业务所不需要的蜂窝网络通信功能（例如：彩信）。
5.6.1.5 通过蜂窝网络传送的针对车载端的关键操作（例如：用户号码写入），应采用强验证
手段，确保只有授权的主体可以实施相应的操作。
5.6.1.6 应根据不同应用的重要性划分优先级，保障关键业务（例如：监管平台信息采集）具
有网络通信的优先使用权。
5.6.2 车车通信、车路协同通信安全
5.6.2.1 车载端具备保证唯一性的身份标识，并可以对所连接的通信节点（例如：路侧设施，
请求通信连接的车辆）进行身份验证，且该身份标识不应泄露用户隐私。
5.6.2.2 车载端应支持数字证书或完备的密钥生成机制和管理机制，用于身份认证、通信加密和完整性保护。
5.6.3 短距离无线连接安全
5.6.3.1 车载端应具备用户手动打开、关闭短距离无线连接的能力。
5.6.3.2 已建立的短距离无线连接，应在相应的输出设备上有明确的连接状态显示。
5.6.3.3 车载端的应用调用短距离无线连接功能时，车载端能够明示用户，并提供配置能力和符合场景的配置方式。
5.6.3.4 车载端只在特定工况下接受外来通信连接请求（例如：蓝牙连接配对请求）以保证车
辆安全，并对发起连接请求的设备进行认证授权。需要用户操作的步骤，应向用户提供符合应用场景的处理方式。
5.6.3.5 车载端发起对外连接时，应对外部设备进行认证，并尽量启用通信协议所支持的安全模式进行通信。
注：短距离无线连接包括但不限于Wi-Fi、蓝牙、ZigBee。
5.7 用户数据安全技术要求
5.7.1 数据安全采集
5.7.1.1 车载端所采集的与用户身份、位置信息等相关的敏感数据，应通过显式的方式告知用
户并获得用户确认，应说明数据采集所依据的国家法律法规或者业务需求。
5.7.1.2 车载端对用户数据的采集应在提供相应服务的同时进行。若出于业务需要而必须
事先采集相关数据，应向用户明示事先采集的目的和范围，并且只有在用户同意的情况下方可继续。
5.7.1.3 车载端采集用户使用行为等用户数据时，应提示用户并向用户提供关闭数据采集的功
能。在执行此类操作前，应首先对用户身份进行认证。
5.7.1.4 车载端应具备支持国家监管部门依法进行数据采集工作的能力。
5.7.2 数据安全存储
5.7.2.1 车载端在将用户敏感数据（例如：用户身份、位置信息）存储在车内系统时，应为保
存数据的文件设置适当的权限，以防止未授权的访问和篡改。
5.7.2.2 存储涉及用户生物特征的数据时，应采用加密形式保存。
5.7.2.3 车载端不应有未向用户明示且未经用户同意，擅自修改用户数据的行为。
5.7.2.4 安全存储的文件应具备标识信息，无法在非授权设备中使用。
5.7.3 数据安全传输
5.7.3.1 应使用防护措施，对所传输数据的完整性和可认证性进行保护。
5.7.3.2 应使用国密算法对重要数据进行加密传输。
5.7.4 数据安全删除
5.7.4.1 共享类应用（例如：共享汽车），在当前用户退出后，该用户的敏感数据应被清空。
5.7.4.2 通过车载端采集的用户数据，在传送到云端服务器后，应具备相应的脱敏措施，防止
用户隐私信息泄露。
5.7.4.3 车载端设备更换件后，换下的旧件所存放的数据需安全删除，相关用户数据需同步新
件，以防止用户数据泄漏或丢失。
6 车载端安全技术要求分级
6.1 各级之间的关系
根据车载端技术要求的防护强度，将车载......
|