ChinaAutoRegs|GB/T 47341-2026英文版翻译 智能网联汽车 车载操作系统技术要求及试验方法
Intelligent and Connected Vehicles—Technical Requirements and Test Methods of Vehicle-Info Operating System
CONTENTS
Foreword
1 Scope
2 Normative References
3 Terms and Definitions
4 Abbreviations
5 Technical Requirements for Vehicle-Info Operating System
6 Test Methods of Vehicle-Info Operating System
Annex A (Informative) Vehicle-Info Operating System Architecture
Annex B (Normative) Table of Technical Requirements for Various Categories of Vehicle-Info Operating Systems
Annex C (Informative) Brief Description of Test Methods and Table of Test Methods for Different Objects of Vehicle-Info Operating System
Annex D (Informative) Reference for Onboard Mini-Program API Functions
Annex E (Informative) Typical Application Scenarios for Functional Safety of Vehicle-Info Operating System
Bibliography
1范围
本文件规定了车载操作系统的技术要求,描述了相应的试验方法。本文件适用于具备车载操作系统的M类和N类车辆,其他车辆类型参照执行。
2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 41388-2022信息安全技术 可信执行环境 基本安全规范
GB/T 44464-2024汽车数据通用要求
GB 44495-2024汽车整车信息安全技术要求
GB 44496-2024汽车软件升级通用技术要求
3术语和定义
下列术语和定义适用于本文件。
3.1
车载操作系统vehicle-info operating system
运行于车载信息交互系统及仪表硬件之上,管理和控制智能网联汽车车载软件、硬件资源,为智能网联汽车提供除驾驶自动化功能实现以外的服务的软件集合。
[来源:GB/T 44373-2024,5.15.2]
3.2
单系统架构single system architecture
在同一套硬件之上运行单个车载操作系统的架构。
3.3
多系统架构 multisystem architecture
在同一套硬件之上运行多个车载操作系统的架构,采用硬件隔离、虚拟机管理器、容器三类或者它们的组合方式实现多系统隔离技术方案。
3.4
资源抽象resource abstraction
运行于车载操作系统内核之上,通过创建软件为车载操作系统应用和基础服务提供硬件资源物理特性和接口内容。
3.5
物模型thing model
对一个物体的数字化描述,包括元素、组件和物模板三层结构。
注1:元素主要包括属性、服务(又称行为或者命令)以及事件。
注2:组件是基于物模型元素的一个表示物的抽象层,表示一个包含有元素中多个同类型或者多个不同类型元素的集合。
注3:物模板是基于组件以及元素的一个表示物的抽象层,表示一个包含有组件、元素,以及自定义元素的集合。
[来源:YD/T4915-2024,3.1,有修改]
3.6
虚拟机管理器hypervisor
在多系统架构中,运行于硬件层和多个车载操作系统单系统之间的中间软件层,通过限制或允许访问CPU、中断、内存、外设等资源来定义每个车载操作系统单系统可用的资源。
3.7
容器container
在多系统架构中,运行在资源隔离管理框架之上的进程或应用程序。
3.8
OEM账号OEM account number
车厂的用户账号,一般包括车主账号、非车主账号和游客账号。
注1:车主账号:每个车辆与一个车主账号唯一对应,用户通过该账号登录车辆的车载系统,车主账号拥有对车辆设置和功能的完全控制权。
注2:非车主账号:一种授权账号,由车主账号进行授权,也能由车主账号撤销授权,出于安全考虑,车主账号授权的非车主账号数量有上限,以防止滥用和安全风险。
注3:游客账号:当用户未登录车主账号或非车主账号时,能登录游客账号访问车载操作系统的基本功能,如车辆控制、设置和地图服务等,以确保即使在未登录状态下,用户也能使用车辆的基础功能。
3.9
系统账号system account number
提供访问授权、本地资源管理等服务的车载操作系统账号。
3.10
云端应用账号cloud application account number
提供第三方账户绑定、多账户管理等服务的车载操作系统账号。
4缩略语
下列缩略语适用于本文件。
API:应用程序编程接口(ApplicationProgrammingInterface)
ASIL:汽车安全完整性等级(AutomotiveSafetyIntegrationLevel)
CA:客户端应用(ClientApplication)
CAN:控制器局域网络(ControllerAreaNetwork)
DMS:司机监测系统(DriverMonitoringSystem)
ETC:不停车收费系统(ElectronicTollCollection)
GNSS:全球导航卫星系统(GlobalNavigationSatelliteSystem)
IC:集成电路(IntegratedCircuit)
MCU:微控制单元(MicrocontrollerUnit)
OBD:车载诊断(On-BoardDiagnostics)
OBU:车载单元(On-BoardUnit)
OMS:车内人员监测系统(OccupancyMonitoringSystem)
OTA:空中下载(OvertheAir)
PAN:特权模式不可访问用户态数据(PrivilegedAccessNever)
PXN:特权模式不可执行用户态程序(PrivilegedExecuteNever)
REE:富执行环境(RichExecutionEnvironment)
SE:安全元件(SecurityElement)
TA:可信应用(TrustApplication)
TEE:可信执行环境(TrustedExecutionEnvironment)
VLAN:虚拟局域网(VirtualLocalAreaNetwork)
V2X:车用无线通信技术(Vehicle-to-Everything)
5车载操作系统技术要求
5.1通用要求
车载操作系统架构和功能模块见附录A。
三类车载操作系统(中控操作系统、用于仪表盘的操作系统、用于T-box的操作系统)应支持的功能模块和可选支持的功能模块应符合附录B的要求。
车载操作系统应按照6.1的至少2类通用试验方法进行试验以测试所有的车载操作系统功能模块,每个车载操作系统功能模块适用的试验方法见附录C。
5.2车载操作系统内核
车载操作系统内核分为微内核和宏内核。按照6.2的试验方法,微内核满足下述a)~i),宏内核满足除f)以外的条款。
a)进程应完整执行其生命周期,从启动到终止,并在终止后释放所有占用的资源。
b)对于具有相同优先级的进程组,应确保每个进程都能获得CPU时间片。
c)对于不同优先级的进程组,应确保高优先级进程先于低优先级进程执行。
d)内核应支持内存的分配、回收、隔离和共享功能。
e)应满足进程间通信的时效性,确保数据传输的及时性符合设计规范。
f)用户空间的驱动崩溃不应导致内核崩溃或影响其他进程的正常运行。
g)用户空间应用程序崩溃不应影响其他进程的正常运行或导致内核崩溃。
h)内核应支持至少一种芯片的指令集。
i)可扩展支持USB存储设备的基础协议。
j)操作系统宏内核应为硬件抽象(HAL)提供设备驱动程序框架和设备驱动访问控制功能。
k)操作系统宏内核应支持至少一类文件系统(如EXT3、UFS、FAT32、NFS网络文件系统等)。
l)操作系统宏内核应支持网络协议栈。
5.3资源抽象
5.3.1硬件抽象
按照6.3.1进行试验,硬件抽象应满足下述要求:
a)支持对芯片的资源抽象,并对各抽象接口功能进行测试;
b)支持对屏幕、摄像头、扬声器、麦克风等的感知和执行资源抽象;
c)支持对外围IC(如蓝牙、WLAN、GNSS、FM等)的资源抽象;
d)支持对外围存储设备(如USB存储设备)的资源抽象。
5.3.2整车服务资源抽象
按照6.3.2进行试验,整车服务资源抽象应对各类基础服务和上层应用提供API,例如提供API实现对空调、座椅等的调节和结果显示等服务。
5.4基础库
按照6.4进行试验,基础库应至少为车载操作系统应用提供进程间通信库、网络传输库、安全通信库、图像库、C/C++库,宜提供语言引擎库、密码学算法或对硬件加解密的封装接口。
5.5基础服务
5.5.1互联服务
按照6.5.1进行试验,互联服务应满足下述要求:
a) 支持与T-Box、OBD、Tuner、V2X-OBU、ETC等车载设备互联;
b)支持通过无线(如WLAN、蓝牙)或有线(如USB)方式与智能终端、云端的信息交互互通,实现娱乐智能服务、辅助控制服务等;
c)支持至少一种网络协议(例如TCP/IP、HTTPS、MQTT等)。
5.5.2地图及定位服务
按照6.5.2进行试验,地图及定位服务满足下述要求:
a)地图及定位服务应为包括地图在内的各类应用程序提供位置相关的API;
b)地图及定位服务可结合GNSS、各类传感器以及车辆信号数据,实现位置信息求解;
c)地图及定位服务可实时上传位置数据到云端,同时可接收云端返回的融合数据,为用户提供个性化的服务。
5.5.3语音服务
按照6.5.3进行试验,语音服务满足下述要求:
a)语音交互服务应提供声学前端、语音唤醒、语义理解、对话管理、语音识别、语音合成功能;
b)语音交互服务可提供语音声纹、语义生成、语音自学习、语音交互展示等功能;
c)车载操作系统可提供语音开发框架,将语音服务模块封装为API以供应用或者车载小程序使用。
5.5.4多媒体服务
按照6.5.4进行试验,多媒体服务应支持图像、音频、视频的编解码功能以及播放和控制服务,将服务模块封装为API以供应用或者车载小程序使用。车载小程序的API见附录D。
5.5.5软件升级服务
按照6.5.5进行试验,软件升级服务满足下述要求:
a)应为新发布功能、安全补丁提供升级通道,确保用户及时接收到软件更新;
b)可通过网络自动检测到新版本,在用户确认后开始下载和安装过程;
c)应支持在后台管理下载;
d)下载和安装完成后应提示升级完成结果(成功或失败),若升级失败,可提供原因描述。
5.5.6账号服务
5.5.6.1系统账号服务
按照6.5.6进行试验,系统账号提供的服务应满足下述a)~e)的要求,可满足f)的要求。
a)提供分层的应用授权访问机制,通过系统账号服务端鉴权保证服务端访问的安全性和合法性。
b)支持系统账号服务端鉴权和对本地资源的管理。
c)车辆启动后,先通过登录一种类型的OEM账号来登录对应的系统账号(登录方式包括OEM账号密码登录、扫码登录、数字钥匙等)。
d)系统账号与OEM账号应具备唯一对应关系,同步生成和注销。
e)当用户选择退出账号登录,且车辆处于驻车状态下,系统退出当前的账号;非驻车状态下,用户选择退出登录,系统应提示用户暂时无法退出登录;系统退出登录完成应通过动画等方式进行提示。
f)当OEM账号支持同厂商下多车登录时,系统账号支持多车登录。使用一个OEM账号(一个对应的系统账号)在其他车登录的情况下,系统账号依据OEM账号的设定,支持部分功能受限,例如,不支持下载/删除应用、还原系统设置/车辆设置/车牌号设置/上牌日期设置等。
5.5.6.2云端应用账号服务
按照6.5.6进行试验,云端应用账号应满足下述要求,有一项符合则判定为符合:
a)为车机用户提供一个或多个云端应用账号绑定服务;
b)支持用户授权并登录云端应用账号后,在车上使用第三方提供的内容服务;
c)根据与云端应用账号约定的绑定要求,同步云端应用账号提供的服务和权限;
d)同一辆车支持与云端应用账号保持同步登录和退出;
e)支持多系统账号管理,提供统一的增加、删除功能;
f)支持查询系统账号、获取系统账号授权给应用的ProxyToken等应用开发接口;
g)支持系统和应用/服务对多个系统账号的登录、注册、查询、授权等;
h)支持单车多个系统账户的切换,保证多个系统账户之间的数据隔离和安全,防止多个系统账户并存情况下的应用错误或者非法调用账户服务。
5.5.7驾驶提示服务
按照6.5.7进行试验,驾驶提示服务满足下述要求:
a)仪表盘操作系统应支持驾驶相关故障告警提示服务,如控制器异常、油箱告警、电量告警、胎压告警等;
b)中控操作系统可支持驾驶影像提示服务,如360°环视、倒车影像、盲区提示、压线提示、透明底盘、轮胎轨迹线提示、行人提示、斑马线提示、前车距离提示、车道偏离提示等。
5.5.8车辆设置服务
按照6.5.8进行试验,车辆设置服务满足下述要求:
a)车载操作系统应支持车辆参数设定,如空调设置、电源设置等;
b)车载操作系统可支持智能车辆设定,如结合车辆传感器和预设的配置文件、智能设置空调等。
5.5.9增强的人机交互服务
按照6.5.9进行试验,车载操作系统宜基于人工智能模型(如TensorFlow、PyTorch等)提供增强的人机交互服务,如AR导航、疲劳驾驶、手势识别、人脸/摄像头遮挡识别、分心识别等。
5.5.10显示功能
若车载操作系统支持显示功能,按照6.5.10进行试验,显示功能满足如下要求:
a)应支持仪表显示;
b)可支持行车记录仪显示;
c)可支持OMS显示;
d)可支持DMS显示;
e)可支持多屏幕显示;
f)可支持抬头显示(HUD)。
5.6程序运行框架
5.6.1互联互通框架
按照6.6.1进行试验,互联互通框架应满足下述要求:
a)支持按照不同的接口类型接入WLAN、蓝牙等车载设备,接口类型至少包括设备发现、快速接入、服务发现、协议校验、语音控制、在线升级、流量代理;
b)支持设备组网功能,如WLAN快速接入,以及接入后的设备身份识别和认证;
c)提供设备接入后的连接管理和抽象,应支持至少一种网络协议(如HTTPS、MQTT等)的设备;
d)适配层为智能设备提供SDK,支持以物模型定义的运动相机,行车记录仪等智能设备的接入;
e)支持对接入的智能设备的功能和对上提供的访问控制接口进行抽象,使得应用开发时不需要
关心设备种类和型号的差异,通过统一的互联互通接口层进行数据的访问和共享;
f)支持为上层应用提供业务逻辑数据。
5.6.2服务融合框架
按照6.6.2进行试验,融合多种基础服务的服务融合框架宜提供服务的注册、发现、服务方法的调用,服务数据的订阅和发布,服务安全调用,服务调用并发数,异常调用时返回错误码,调用超时机制等,支持不同类型的服务组合成为新的服务或者应用。
5.6.3多媒体框架
按照6.6.3进行试验,多媒体框架应满足下述要求:
a)支持音频输入输出与合成、预处理(如回声消除、滤波、去噪),后处理(如均衡、重低音、立体音效)和基础的多媒体编解码服务;
b)支持音视频文件播放、音视频文件基本信息扫描和检索、在线音视频播放、音视频录制功能;
c)支持车载操作系统与手机、记录仪等设备的媒体交互功能,如投屏到仪表、手机投屏音视频播放,车内行车记录仪实时视频、小程序多媒体等;
d)支持系统音频策略配置,如配置音乐播放和语音交互同时发生时的音频策略等;
e)支持多种音视频编解码格式,例如音乐支持MP3、WMA格式等,视频支持AVI、RMVB格式等;
f)支持将编解码后的音视频内容可由APP封装和传输;
g)支持多媒体功能的定制化需求,如功能裁剪、仅扫描音乐(不扫描视频和图片)、特殊格式的音视频录制等。
5.6.4多模态交互框架
按照6.6.4进行试验,若车载操作系统支持多模态交互框架,则应提供至少两种交互模态(如语音、视觉、隔空手势、触摸屏、按键等),车载操作系统支持应用程序选择接入一种或者同时接入多种方式来提供交互,例如,抬头显示、虚拟导航、通过手势来接听或者挂断电话等。
5.6.5场景感知理解框架
按照6.6.5进行试验,场景感知理解框架提供计算和理解当前场景的功能,车载操作系统支持应用程序订阅场景感知理解框架的输出信号来执行动作或者推送服务。典型的场景理解结果比如是否发生了事故、是否在颠簸路面、是否违停禁入区域等。
5.6.6用户界面框架
按照6.6.6进行试验,用户界面框架应提供窗口、界面元素和动画的编程接口以及界面资源管理(贴图、多语言文本等),可提供接口供三方渲染引擎来绘制界面,支持2D或3D渲染。
车载操作系统可提供统一的小程序运行环境和小程序用户界面框架,支持开发者开发一份小程序代码可运行在不同车载操作系统中。车载小程序的API要求见附录D。
5.7多系统
5.7.1通用要求
按照6.7.1进行试验,车载操作系统多系统架构应支持5.7.2、5.7.3、5.7.4中至少一种多系统方案。
5.7.2基于硬件隔离的多系统
按照6.7.2进行试验,基于硬件隔离的多系统将硬件资源通过硬件分区的方式进行划分和管理,满足下述要求:
a)应为多系统提供了强制隔离;
b)可将资源划分为与不同执行环境关联的不同所有权组;
c)硬件资源[如SoC外围设备(Resource),内存区域(Memory)和引脚等]的所属分区应具备对该资源的访问和管理权限,其他分区不被允许对该资源进行操作;
d)所有者可配置对资源的访问权限;
e)可支持同时并行访问同一硬件资源;
f)应支持全局电源管理;
g)应支持多操作系统间高效的通信和内存共享。
5.7.3基于虚拟机管理器的多系统
按照6.7.3进行试验,基于虚拟机管理器的多系统将硬件和软件资源通过虚拟机管理器的方式进行划分和管理,应满足下述要求:
a)硬件系统资源分配和共享(静态或动态);
b)外设资源的分配和共享(静态或动态);
c)确保车载操作系统单系统之间的独立性,某个车载操作系统单系统无法访问未提供给自身的资源;
d)支持多操作系统间高效的通信和安全的数据共享;
e)管理各操作系统优先级,根据优先级分配硬件资源,最大化利用硬件资源,并满足对时间敏感需求和系统服务质量的要求;
f)管理各操作系统生命周期,包括启动、运行、关闭、重启、异常退出等状态;
g)虚拟机管理器的存在应保证其低性能损耗,不应对各操作系统性能产生显著影响;
h)具有不同安全性和安全级别的应用程序可以在相同的硬件上运行,通过虚拟机隔离相互保护;
i)多系统间具有全局电源管理功能;
j)共享外设的虚拟化,应采用安全隔离方式,不准许两个操作系统同时访问共享外设。
5.7.4基于容器的多系统
按照6.7.4进行试验,基于容器的多系统将硬件和软件资源通过容器的方式进行划分和管理,应满足下述要求:
a)多个车载操作系统单系统中的非内核部分运行在基于内核(如Linux等)的资源隔离管理框架之上;
b)容器间支持文件系统隔离和网络隔离;
c)基于内核(如Linux等)的资源隔离管理框架支持多个容器的互相隔离,在某个容器中运行的程序无法访问其他容器内的文件和进程;
d)资源隔离管理框架需要提供统一管理框架,支持容器的创建、启动、关闭及状态查询等管理能力,能够自动进行资源分配,最大化利用硬件;
e)支持内核资源隔离,主要包括根文件系统路径、进程、用户、网络和IPC;
f)支持CPU/内存资源的共享调度和配额管理;
g)支持容器间及容器和Host间的通信机制;
h)支持存储空间隔离,每个容器有独立的根文件系统,容器间互不可见对方文件系统;
i)支持容器间进程隔离,一个容器无法访问其他容器的进程;
j)支持网络隔离,每个容器具备完全独立的网络协议栈视图,包括网络设备接口、IPv4和IPv6协议栈、IP路由表、防火墙规则及sockets等;
k)支持容器间故障隔离,一个容器的异常退出或容器内进程的异常终止不影响其他容器的正常运行;
l)支持外设共享技术,可配置多个容器对于外设的共享或独占能力;
m)全局电源管理;
n)管理各操作系统优先级,实现自适应分配,最大化利用硬件资源,并满足对时间敏感需求和系统服务质量的要求。
5.8可信执行环境
可信执行环境的基础要求包括可信根和安全启动。可信根的技术要求及试验方法应依据GB/T 41388-2022中6.2和13.1.2。可信执行环境的安全启动的技术要求及试验方法应依据GB/T 41388-2022中6.3和13.1.3。
可信执行环境的可信操作系统的技术要求及试验方法应依据GB/T 41388-2022中第8章和13.3,并按照6.8进行试验,满足如下要求:
a)可信操作系统应支持日志管理;
b)可信操作系统的内存管理机制应防止内存分配错误引起操作系统崩溃;
c)可信操作系统应确保驱动程序错误不会导致操作系统内核崩溃。
可信执行环境的可信应用与服务管理、可信服务、跨平台应用中间件、可信应用的技术要求及试验方法应分别依据GB/T 41388-2022中第9章~第12章和13.4~13.7。
5.9性能指标
5.9.1通用要求
车载操作系统的性能指标试验应在6.9.1的温度、湿度、环境等条件下进行。
5.9.2热启动时间
按照6.9.2进行试验,采用以下三种方式计算车载操作系统的热启动时间:
a)车载操作系统由STR模式或休眠(standby)模式等切换到仪表信息或倒车影像(倒车雷达)呈现的时间;
b)车载操作系统由STR模式或休眠(standby)模式等切换到操作界面可用的时间;
c)车载操作系统由STR模式或休眠(standby)模式启动到HUD界面稳定显示的时间。
5.9.3冷启动时间
按照6.9.3进行试验,采用以下五种方式计算车载操作系统的冷启动时间:
a)车载操作系统开机上电到仪表信息或桌面(倒车雷达)呈现时间;
b)车载操作系统开机上电到操作界面可用时间;
c)车载操作系统开机上电到操作界面视觉可见时间;
d)车载操作系统开机上电到开机动画界面视觉可见时间;
e)车载操作系统开机上电到HUD界面视觉可见时间。
5.9.4优先级调度响应时间
按照6.9.4进行试验,在高负载条件(CPU平均负载率80%以上,例如语音地图、ADAS渲染、娱乐应用等都运行)下,测量高优先级任务的切换响应时间,应确保实时性。
5.9.5存储空间读写性能
按照6.9.5进行试验,在非负载和相同的温度条件下使用OTG或本地磁盘对1GB 大小的文件进行多次读/写测试(测试时用同样的外挂硬盘),计算平均的读/写速度。
5.9.6虚拟机管理器的资源开销(CPU/GPU)比率
按照6.9.6进行试验,在不开启安全机制且空载条件下,计算车载操作系统多系统架构中虚拟机管理器的资源开销占用CPU和GPU的总资源的比率,计算出该比率为0.80~1.00。
5.9.7多系统间通信
按照6.9.7进行试验,在不开启安全机制且空载条件下,计算车载操作系统多系统架构中不同系统间通信的平均时间、最长时间和最短时间。
多系统架构类型包括5.7中基于硬件隔离的多系统、基于虚拟机管理器的多系统和基于容器的多系统。对于两个操作系统A和B组成的多系统,典型测试方案为:输入命令行,多次进行车载操作系统Aping车载操作系统B,计算平均时间、最长时间和最短时间。
5.9.8可信执行环境的性能要求
5.9.8.1CPU性能
按照6.9.8.1进行试验,可信执行环境的性能指标如下:
a)单核情况下TEE下CPU性能较REE下CPU性能损耗百分比,值越小性能越好;
b)多核情况下TEE下CPU性能较REE下CPU性能损耗百分比,值越小性能越好。
5.9.8.2内存性能
按照6.9.8.2进行试验,计算TEE侧的内存性能较REE侧内存性能损耗百分比,值越小性能越好。
5.9.8.3存储读写性能
按照6.9.8.3进行试验,计算TEE的存储读写与REE的存储读写比率,值越小性能越好。
5.9.8.4加解密性能
按照6.9.8.4进行试验,针对不同的加解密方法,可信执行环境的加解密性能指标如下:
a)对于对称算法,TEE侧加解密性能较REE侧性能损耗百分比,值越小性能越好;
b)对于非对称算法,TEE侧生成密钥对的性能较REE侧性能损耗百分比,值越小性能越好,加密、解密的性能较REE性能损耗百分比,值越小性能越好;
c)对于摘要算法,TEE侧性能较REE侧性能损耗百分比,值越小性能越好。
5.9.8.5通信性能
按照6.9.8.5进行试验,TEE的通信性能指标如下:
a)TA与TA通信时间和TA与CA通信时间,值越小性能越好;
b)TEE应通过通道并发等能力支持多CA同时调用多TA完成一个完整可信任务。
5.10信息安全
5.10.1通用安全
5.10.1.1系统安全
按照6.10.1.1进行试验,车载操作系统的系统安全满足以下要求。
a)系统用户管理要求:
1)禁止特权用户(如root用户)直接登录,应限制登录用户的权限;
2)应区分不同角色的账号使用的权限,宜实施基于账号的访问控制;
3)系统内不应存在开发账号和测试账号,应删除非必要的账号;
4)应通过对不成功的鉴别尝试的值(包括尝试次数和时间的阈值)进行预先定义,并明确规定达到该值时采取的措施来实现鉴别失败的处理;
5)特权用户身份验证应至少支持口令鉴别、基于令牌的动态口令、生物特征识别(刷脸、声纹或虹膜等)、数字证书鉴别等多种方式中的一种,并在访问安全功能相关的操作之前进行鉴别。
b)系统服务管理要求。
1)操作系统应对关键资源实施强制访问控制(MAC)。应用程序只能获得所需的最低权限。
● 应用级程序需配置为最小访问权限。
● 系统级程序应配置有限的访问权限。
● 接口资源访问(如WLAN、蓝牙、USB等接口)的程序应配置最小访问权限。
2)操作系统应对关键资源实施自主访问控制(DAC)。应对文件和可执行文件的访问进行管理和审计,以保护文件和进程免受未经授权的访问和操作。
3)操作系统应关闭不必要的系统服务,如非必要的FTP、Telnet、SSH等。
4)操作系统的正式版本中不应存在为开发和调试阶段使用的服务。
c)系统安全启动要求。
1)车载操作系统应支持基于硬件可信根的安全启动,硬件可信根应是可信任的、物理上无法篡改的。
2)应使用基于可信根的校验机制对根证书的合法性(如公钥的完整性)进行校验。
3)对相关镜像的签名验签应遵循密码相关国家标准和行业标准。
4)车载操作系统应支持基于安全BootLoader的安全启动。安全BootLoader可支持防漏洞设计,包括但不限于栈保护、数据不可执行。
d)系统漏洞管理要求:
依据GB 44495-2024中7.1.1.1的要求,操作系统不应存在由汽车行业权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞。
e)软件升级安全要求:
车载操作系统系统应支持安全的升级,满足GB 44496-2024中的软件升级安全要求。
f)系统内核加固:
车载操作系统内核宜采用安全加固机制进行保护,如PXN、PAN、KASLR、控制流完整性保护、RODATA、ROSYSCALLTable、页表完整性保护等安全加固机制。
g)针对包含只读数据的存储分区,系统应采用一种机制来对数据进行块级或文件级完整性保护。
h)针对包含读写数据的存储分区,系统应采用对数据进行块级或文件级的完整性保护机制和加密保护机制。
i)车载操作系统宜对内核进行完整性保护。
j)车载操作系统应限制进程可执行的系统调用范围,限制进程的特权范围,内核应支持强制访问控制,如SElinux。
k)应提供常见的入侵检测功能,支持针对特定端口或IP的访问控制。
l)应支持地址空间布局随机化机制(ASLR)。
m)应支持可执行空间保护。
n)应支持堆栈保护:“堆栈粉碎保护”或“堆栈保护器”编译器技术。
o)应支持编译时缓冲区溢出检查。
5.10.1.2数据安全
按照6.10.1.2进行试验,车载操作系统的数据安全满足以下要求。
a)当预装应用调用数据采集服务时,系统应明确告知用户采集的目的和范围。
b)当应用获取用户敏感个人信息时,汽车数据处理者应依据授权同意范围处理个人信息,若超出授权同意范围,应重新提出授权同意申请;当授权同意期限届满时,若汽车数据处理者仍需要继续进行除删除外的个人信息处理活动,应重新提出个人信息授权同意申请。
c)应用收集个人信息应限于实现处理目的所必要的最小范围,取得用户的明示同意,特殊情况除外(如紧急呼叫等)。
d)当系统采集远程控制、远程诊断等功能场景下所发送的指令数据时,系统应确保已获得用户在完全知情的基础上自愿给出的、具体的、清晰明确的授权同意。
e)如设备或后台需要存储用户数据,则应告知用户,并获得授权,否则当前用户退出登录后,系统应默认清空个人数据;如用户授权设备后后台存储用户信息,则需提供直观易用的数据删除选项,以及撤回授权的选项;恢复出厂设置应默认清除用户数据,或提供用户数据是否一并删除的选项。
f)系统应防止非授权访问用户数据。
g)在多用户系统中,系统应采用用户间隔离机制,防止用户数据的非授权访问。
h)当车载操作系统提供用户数据采集功能时,系统应提供用户关闭的功能。
i)系统应对用户数据操作(包括采集、传输、存储、销毁)的日志进行存储。
j)敏感个人信息应不以明文传输,应采用加密[例如:SM2、AES(长度不低于128位)等算法]存储,宜采用基于硬件保护的安全存储。
k)系统应使用基于硬件的安全存储生物特征信息,或使用纯硬件的生物特征功能实现。
l)安全重要参数应支持完整性校验,并应防止丢失和误删除,宜采用备份或专用安全空间存储。
m)操作系统应指定默认日志等级且可配置。
n)对GB 44495定义的关键数据宜采用加密存储、访问控制、加密传输等机制进行保护。
o)对于关键数据应覆盖其全生命周期的安全,包括数据的生成、收集、存储、访问、传输、分析、使用、销毁等环节的安全防护。
p)应遵循车企的隐私声明政策,应符合GB/T 44464-2024中5.1~5.6的规定。
5.10.1.3通信安全
按照6.10.1.3进行试验,车载操作系统若具备通信安全能力,其设计满足以下要求。
a)系统内宜设置网络通信白名单、黑名单等,保证只有受到系统信任的URL可以建立通信链接(如HTTPS/以太网/蓝牙等)。
b)应使用TLSv1.2(长度不低于2048的RSA算法或长度不低于256的ECC算法)及以上版本进行通信,当发送敏感个人信息时,应使用TLSv1.2及以上版本进行双向认证。
c)通信协议应支持HTTPS。
d)使用到的随机数应符合随机数相关标准(例如GM/T 0005-2021等),保证由已验证、安全的随机数生成器产生。
e)使用已验证、安全的参数配置(包括设备身份标识、认证机制、安全通信协议、安全服务类型、安全服务描述、安全服务授权信息、安全服务地址、指定哈希算法、指定加密算法、加密密钥、证书类型、证书签发者、证书有效期、证书有效区域、证书权限范围和应用数据签名权限),应只信任被配置为可信的证书或证书链。
f)网络通信时,应支持对数据内容进行完整性校验;数据内容校验失败时,应终止该响应操作。
g)网络通信时,应支持对通信双方进行身份鉴权;发生身份鉴权失败时,应终止该响应操作。
h)操作系统应支持基于PKI的证书管理机制和安全协议。
i)对外部网络与车内网络间进行隔离(如VLAN或物理隔离)。
j)通信宜具备关键事件日志记录能力。
k)网络通信应对异常报文有感知能力,宜具有告警或其他安全响应的能力。
l)操作系统不应存在隐蔽端口,开启端口应是系统运行和业务应用所必要的,无用的端口应关闭。
m)车外网络通信应具备访问控制机制(如防火墙),防止非授权访问。
n)车内具备安全网络域的隔离(如VLAN)。
o)防火墙功能要求:
1)实现对报文的安全过滤,拦截非法数据,避免其进入安全区域;
2)防火墙只准许和预定义的网络进行通信;
3)防火墙的相关数据(如拦截数据流量、防火墙故障状态和防火墙规则数量等)应使用安全存储机制,并支持上报或转发其他模块处理的功能。
5.10.2应用安全
按照6.10.2进行试验,车载操作系统的应用安全满足以下要求:
a)应支持应用的防逆向分析,宜采用地址随机化、代码混淆或加壳等措施;
b)应支持应用软件安装包采用签名认证机制,在安装时应校验其真实性和完整性,在应用加载宜验其完整性;
c)应支持应用在访问、操作和使用系统资源及数据时,应校验其访问权限,宜在访问请求中直接附带应用身份和权限信息,并在服务提供方校验其权限是否足够;
d)应支持应用间采用隔离机制,系统宜用不同密钥对不同应用的重要数据进行加密。
5.10.3审计安全
按照6.10.3进行试验,车载操作系统满足以下安全审计要求:
a)宜对安全相关的以下事件生成审计日志:系统运行记录、报警记录、操作日志、网络流量记录、应用软件运行日志、配置信息等;
b)审计日志的内容应包括事件发生的日期、时间、主体标识、事件类型描述和结果(成功或失败)、
关联的进程等;
c)审计日志应能本地存储,访问本地日志需进行权限管控,本地日志宜加密存储;
d)应满足审计信息的真实性和完整性;
e)审计日志宜能传输到云端;
f)敏感信息审计应审计是否禁用su、sudo命令,禁止敏感IP,禁止明文的密钥文件等;
g)文件系统审计应支持文件权限读写配置、分区挂载可读可写可执行属性配置等;
h)应支持服务审计,如禁用调试服务、调试驱动等;
i)应支持应用审计,如开启Canary栈溢出保护等。
5.10.4多系统安全
按照6.10.4进行试验,车载操作系统若为多系统,除满足5.10.1~5.10.3的安全要求之外,还满足以下安全要求:
a)多系统安全启动的整体流程应具备统一的硬件可信根和完整的信任链,确保多系统代码和数据的完整性和真实性;
b)多系统域隔离安全应确保多操作系统间的空间隔离(如内存、缓存、外设等)、时间隔离(如硬实时、时间窗配置等),多系统域隔离安全应依据6.1.10故障注入的试验方法,每个子系统应有针对DMA攻击的防范措施;
c)多系统权限模型应确保虚拟机的每项资源都能够通过独立的权限进行管理,系统中无具备最高等级权限的虚拟机;
d)应具备多系统间通信身份验证和访问控制的能力;
e)多系统驱动框架应对驱动提供有限防护(例如基于内核安全机制检测、前后端驱动隔离等技术);
f)多系统应采用系统间隔离机制,防止系统数据的非授权访问。
5.11功能安全
车载操作系统ASIL等级应由整车层面的ASIL等级需求进行分解确定。如果没有上层需求作为输入,可采用SEooC方法进行安全假设,从而明确各个模块的ASIL等级。
按照6.11进行试验,车载操作系统供应商应至少在系统层面进行面向功能安全的技术安全概念活动,以保障系统在故障条件下,向驾驶员传递满足安全状态的关键信息。
车载操作系统供应商应进行安全分析活动,并制定对应的安全措施,以说明系统一旦发生失效,该系统将如何避免或减轻可能对驾驶员的安全产生影响的危害。安全分析至少包括以下内容。
a)系统层面的安全分析,可采用潜在失效模式与影响分析(FMEA)、故障树分析(FTA)或任何适合系统安全分析的其他类似过程。
b)应至少考虑如下因素可能导致的危害以开展安全分析:
1)操作系统本身的通信类故障(显示指令信号);
2)显示屏系统故障;
3)应描述对应的安全措施,确保功能安全需求和目标的达成。
车载操作系统供应商应进行安全措施制定,以确保安全概念实现。系统可采取如下安全策略:
a)关键区域(如:告警灯和挡位信息)维持安全状态,其他区域保持正常功能和性能的显示(如:3D渲染);
b)关键区域(如:告警灯和挡位信息)维持安全状态,其他区域显示性能降级(如:2D),并只提供必要信息的显示(如:车速);
c)文字类提示(如:请去4S店维修)。
车载操作系统可参照GB/T 34590.3-2022的危害分析和风险评估的方法确定ASIL等级要求,所使用的底层安全机制应满足相应的ASIL等级要求。
不同类型的车载操作系统应用场景见附录E。车载操作系统的功能安全要求可根据不同类型的应用场景确定相应的ASIL等级。支持仪表告警、驾驶提示、道路安全相关告警等高实时性要求场景的操作系统的ASIL等级宜在B级及以上。
6车载操作系统试验方法
6.1通用试验方法
6.1.1一致性审查
一致性审查的业务功能试验方法如下:
a)提取相关文档中定义的业务功能清单,并确定业务流程;
b)设计典型用户场景;
c)构建正向流程(正常操作)和逆向流程(异常操作)测试用例;
d)采用自动化脚本或手工测试等方法执行测试;
e)记录执行结果。
一致性审查的隐私策略试验方法如下。
a)策略声明审核:检查隐私声明文档是否明确数据采集范围、数据使用目的、数据存储周期及加密方式。
b)动态行为监控:使用工具监控网络流量中的未声明数据传输。使用权限审计工具验证敏感权限调用是否超范围。
c)模拟用户拒绝授权场景,检查系统是否强制退出或降级运行。
一致性审查的安全功能试验方法如下:
a)功能安全试验方法参照GB/T 34590;
b)信息安全试验方法参照GB 44495,生成安全目标符合性报告。
6.1.2自动化静态代码扫描
自动化静态代码扫描的试验方法如下:
a)检查厂商提交的文档,并检查代码的实现情况,分析软件成分清单,包括组件数、许可证数、文件数、代码行数、容量等及各项的详情列表;
b)分析开源成分存在的漏洞风险,包括安全漏洞、高风险许可证、兼容风险等;
c)通过静态代码测试工具,根据代码编程标准检查代码子程序和函数是否采用一个入口和一个出口;
d)通过静态代码测试工具,根据代码编程标准检查代码是否存在动态对象或动态变量,否则需要在其产生过程中对其进行在线测试;
e)通过静态代码测试工具,根据代码编程标准检查代码变量是否初始化;
f)通过静态代码测试工具,根据代码编程标准检查代码是否重复使用变量名称;
g)通过静态代码测试工具,根据代码编程标准检查代码是否限制使用指针;
h)通过静态代码测试工具,根据代码编程标准检查代码是否存在隐式类型转换;
i)通过静态代码测试工具,根据代码编程标准检查代码是否存在隐藏数据流或控制流;
j)通过静态代码测试工具,根据代码编程标准检查代码是否存在无条件跳转;
k)通过静态代码测试工具,使用控制流分析方法检查被测代码的控制结构;
l)通过静态代码测试工具,使用数据流分析方法检查被测代码的差错或异常或代码规范情况。
注:方法b)、c)、e)、f)和g)可能不适用于在基于模型开发中用到的图形模型标记法。
6.1.3代码审计人工复核
代码审计人工复核的试验方法如下。
a)检查厂商提交的文档,并检查代码的实现情况。
b)对自动化静态代码扫描报告进行复核。
c)检查代码和设计的一致性。
d)检查代码执行标准的情况。
e)检查代码逻辑表达的正确性。
f)检查代码结构的合理性。
g)检查代码的可读性。
h)检查代码中与用户信息或软件自身安全密切相关的状态信息没有存储在非授权实体都可以访问的地方;检查代码是否存在被绕过的情况;检查代码中使用的密码相关实现技术是否符合相关规定;应确保访问控制和权限管理得到实现。
i)检查代码中的函数调用安全、异常处理安全、指针安全等。
j)检查代码中是否存在释放资源不当的情况,如内存的分配、释放函数是否成对调用,内存缓冲区边界操作是否发生越界等。
6.1.4形式化数学验证
形式化数学验证的试验方法如下。
a)用户提供如下输入:
1)基于高阶逻辑、谓词逻辑、一阶逻辑等数学描述的系统状态机对象规约;
2)基于高阶逻辑、谓词逻辑、一阶逻辑等数学描述的系统安全属性规约,系统安全属性规约应包含系统不变量,或者使用自动化验证工具时包含的前置条件、后置条件等规约描述;
3)支持形式化验证的验证工具、验证框架、代码生成器等;
4)需要验证的系统代码、通过代码生成工具生成的系统代码,或者人工编写的系统代码;
5)详细的验证过程说明文档;
6)需要验证的系统安全属性,一般为自然语言描述的安全需求。
b)基于求精方法进行验证,需要验证不同层上的规约之间的精化关系。
c)验证系统实现代码与规约之间的精化关系。
d)验证系统状态机对象规约满足系统安全属性规约的要求。
e)验证系统前置条件成立时,后置条件的正确性,以及系统不变量在系统状态变化过程中的不变性。
6.1.5二进制代码检测
二进制代码检测的试验方法如下:
a)准备二进制代码检测工具;
b)使用二进制代码检测工具识别二进制代码中的软件成分,包括识别其中包含的开源组件版本信息、用户名密码等敏感信息、加密算法、CVE/CNNVD漏洞。
6.1.6模糊测试
模糊测试的试验方法如下:
a)对被测程序编译插桩,生成二进制可执行文件;
b)运行被测程序;
c)创建模糊测试项目,启动模糊测试工具;
d)根据初始测试用例进行变异,并输入到被测程序入口;
e)监控被测程序运行状态;
f)发现漏洞问题项,记录并保存。
6.1.7渗透测试
渗透测试的试验方法如下。
a)渗透测试应提供与生产环境相似的仿真环境,以便进行部分可能影响数据完整性及稳定性的侵入式测试,在生产环境中应避免使用可能导致数据完整性及业务稳定性遭受破坏的测试手段。
b)应进行网络安全漏洞扫描测试,对目标主机或网络,搜集目标信息,根据搜集到的信息判断或者进一步测试系统是否存在安全漏洞,设定渗透测试范围,如IP段、域名、整站渗透或者部分模块渗透等,针对找到的安全漏洞制定攻击计划,需考虑安全漏洞原理、可利用工具、目标程序检测机制、攻击是否可以绕过防火墙等。
c)应进行主机漏洞扫描测试,从系统用户的角度检测计算机系统的漏洞,包括应用软件、运行的进程、注册表或用户配置等存在的漏洞,通过渗透测试工具等查找存在的安全漏洞。
d)应进行数据库漏洞扫描测试,通过自动扫描和手动输入发现数据库,经授权扫描、非授权扫描、弱口令、渗透攻击等检测方式发现数据库安全隐患,形成修复建议报告提供给用户。
e)可基于网络安全漏洞研究和挖掘的能力构建安全漏洞库,并使用漏洞库进行定向漏洞扫描,漏洞库应及时更新,在一个月内更新完成。
f)在执行攻击计划后,验证是否可达以下目标:
1)未发现CVE及CNNVD发布超过6个月的CVSS3评分7.0及以上信息安全相关的高危漏洞或漏洞已修复无法成功利用;
2)获取用户账号密码;
3)截取目标程序传输的数据;
4)控制目标主机等。
6.1.8漏洞扫描
漏洞扫描的试验方法如下:
a)测试人员用漏洞扫描工具对车载操作系统所在终端进行漏洞扫描;
b)发现并识别测试模块开放的相关端口、服务、厂商、名称及详细版本信息,判断是否存在已知的高危漏洞。
6.1.9压力测试
压力测试的测试环境应满足如下条件:
a)硬件环境方面,模拟真实场景的物理/虚拟化设备,覆盖主流配置;
b)软件环境方面,部署典型应用服务及用户级进程。
压力测试的试验方法如下。
a)单资源过载:针对CPU进行计算密集型任务测试、针对内存进行大规模动态分配测试、针对磁盘进行持续高吞吐读写测试、针对网络进行极限带宽占用测试,分别施加独立压力。
b)混合资源竞争:同步触发多资源密集型任务,如计算、存储、网络并发负载。
c)连接与通信压力测试方法:模拟外部设备/终端通过不同接口(有线、无线)持续长时间频繁建立/断开连接。
6.1.10故障注入测试
故障注入测试的试验方法如下。
a)基于厂商软件安全分析识别出的典型故障,通过破坏标定参数、损坏软件接口、损坏变量的值、引入代码突变或损坏CPU寄存器的值等方式注入故障到环境模型中或模拟被测模型中,模拟和捕捉系统在故障下的行为。
b)应进行基于硬件的故障注入,对每个子系统开发的驱动进行DMA攻击检测,如能通过直接存储器访问物理地址空间并进行刺探和修改,则说明系统没有针对DMA攻击的防范措施。
1)需要准备一个具备DMA功能的设备,例如一块特制的具有PCI接口的网卡,该卡上带有DMA控制器,从而尝试获取目标系统的物理访问权限。
2)通过恶意的驱动程序、固件漏洞、内核提权来尝试获取对DMA控制器的控制权限,使用DMA控制器将目标系统的内存映射到自己的设备上,尝试直接读取或写入目标系统的内存数据(如密钥、登录凭证等)。
3)通过DMA控制器直接修改目标系统的内存内容,以执行如注入恶意代码等的恶意操作。最后在完成攻击后尝试清理并恢复修改过的内存数据,并释放对DMA控制器的控制权限,观察系统能否防御DMA攻击。
c)应进行基于软件的故障注入,使用软件触发器将故障注入正在运行的软件系统。例如将错误的数据加载到寄存器中,或者修改寄存器的状态来引入错误。注入错误后,观察系统的响应,记录系统在故障注入情况下的行为和结果。根据测试结果,分析系统在故障注入情况下的表现。评估系统的容错性、错误处理能力和恢复能力。
d)应进行基于仿真的故障注入。在已知相关项功能及故障类型的前提下,通过故障注入仿真在危害分析和风险评估流程中得到某一故障产生的影响,并据此细化安全目标。
1)选择基于软件的仿真器、模拟器或虚拟机等来创建虚拟环境,根据已知相关项的主要功能及其故障类型,正确识别功能失效模式,以获得关于其影响的整车层级的数据。
2)在对系统进行初步分析后,配置故障注入试验,包括设置试验和驾驶场景,以及生成故障列表。
3)创建故障化被测系统,故障注入器模块根据故障列表的信息及通用故障模型模板,创建故障发生器代码。将故障化被测系统与无故障系统的模拟结果进行比较,分析故障影响,进而导出适当的安全目标及安全要求。
6.2车载操作系统内核
车载操作系统内核的试验方法如下:
a)在操作系统中同时运行多个程序或反复运行同一个程序,在程序关闭后,确认程序所占用系统资源是否被完全释放;
b)尝试同时创建并执行一定数量的进程并确保这些进程优先级相同,确认是否所有进程都能够获得时间片;
c)尝试同时创建并执行一定数量的进程并确保这些进程优先级各不相同,确认是否优先级高的进程先被执行;
d)进行多次通信测试,记录每次的响应时间,并计算平均值,验证操作系统进程间通信时效性;
e)检查操作系统内核的内存管理策略,尝试进行内存分配、回收、隔离和共享操作;
f)采用文档审查或采用用户空间驱动的开发工具与接口编写测试代码等方式,验证在微内核设计下,驱动或应用程序崩溃时不影响操作系统正常工作;
g)采用文档审查或采用用户空间驱动的开发工具与接口编写测试代码等方式,验证在宏内核设计下,应用程序崩溃时不影响操作系统正常工作;
h)查阅芯片文档,使用支持指令集的汇编语言,编写一个简单的测试代码,确认芯片是否正确执行指令;
i)连接使用不同文件系统格式(如FAT32、NTFS等)格式化的USB存储设备,确认车载系统是否能够正确识别和访问这些不同格式的USB存储设备并能正常进行读取和写入;
j)审查文档及代码,确认宏内核是否支持设备驱动程序框架和设备驱动访问控制功能;
k)审查文档及代码,检查宏内核是否支持至少一类文件系统;
l)审查文档及代码,检查宏内核是否支持网络协议栈。
6.3资源抽象
6.3.1硬件抽象(HAL)
硬件抽象的试验方法如下:
a)检查是否支持对芯片的资源抽象,并对各抽象接口功能进行测试;
b)检查是否支持对屏幕、摄像头、扬声器、麦克风等的资源抽象,尝试使用车载管理系统获取对应资源,尝试使用硬件接口资源抽象获取数据;
c)检查是否支持对外围IC的资源抽象,检查外围IC(如蓝牙、WLAN、GNSS、FM等)的硬件资源抽象和接口,尝试对这些设备进行访问;
d)检查是否支持对外围存储设备(如USB存储设备、SD卡)的资源抽象,尝试对外围存储设备进行访问。
6.3.2整车服务资源抽象
整车服务资源抽象的试验方法如下:
a)检查是否支持对整车服务资源进行抽象;
b)检查是否提供基于以太网通信协议的统一数据上行/下行接口,尝试利用该接口对空调、座椅、挡位、灯等功能进行控制,检查接口功能是否正常。
6.4基础库
基础库的试验方法如下:
a)审查文档,检查基础库的设计;
b)检查基础库是否有进程间通信库、网络传输库、安全通信库、图像库、C/C++库;
c)检查基础库是否有引擎库、密码学算法或对硬件加解密的封装接口。
6.5基础服务
6.5.1互联服务
互联服务的试验方法如下:
a)搭建实车或台架环境;
b) 准备试验工具:市场主流Android/IOS/HarmonyOS手机(支持Carplay、Hicar、Carlink、An-droidAuto等手机有线连接、无线连接、WLAN、蓝牙等),USB数据线,CAN设备,ETC设备,T-BOX;
c)测试车载操作系统与终端通信功能,USB供网、CAN总线通信、诊断功能、收音机、ETC功能,以及连接响应性能及压力测试,不同终端、不同连接方式连接的响应时间及稳定性存在差异;
d)测试车载操作系统与终端的连接功能,包括有线连接、无线连接、蓝牙音乐、蓝牙电话、数字蓝牙钥匙、远程车辆控制、远程车况查询、数据采集上传、在线应用、有线/无线投屏,以及连接响应性能及压力测试,不同终端、不同连接方式连接的响应时间及稳定性存在差异;
e)测试网络协议(包含TCP/IP、HTTPS、MQTT等)的信息同步功能,主要体现在系统与设备端数据传输与显示的准确性及时效性。
6.5.2地图及定位服务
地图及定位服务的试验方法如下:
a)搭建实车环境,可正常收取GNSS信号及网络信号;
b)准备测试电脑、测试手机、测试手机下载OEMAPP及第三方应用;
c)车载系统安装导航地图软件,安装GPS、陀螺仪信息记录软件,OEMAPP及第三方应用绑定车机系统账号;
d)进行行车路试,测试路线包含普通道路、长隧道、立交、高架下、地下车库、高大建筑密集区、高速连续出口、主辅路等,查看记录软件实时显示的卫星定位、陀螺仪定位数据信息;
e)依据相关设计文档,测试车载操作系统定位服务功能,包括地图在内的各类应用程序获取的位置信息,如导航引导定位,天气应用位置,移动端APP远程车况查询、导航到车、第三方应用发送位置到车等,并可实时上传位置数据到云端和接收云端返回的融合数据。
6.5.3语音服务
语音服务的试验方法如下:
a)审查语音服务相关设计文档,确认车载操作系统支持语音服务,如声学前端、语音识别、语音合成,可提供语音声纹、语义理解、对话管理、语义生成、语音自学习、语音交互展示等功能,可提供语音开发框架;
b)搭建实车或台架环境,麦克风及扬声器功能正常,车端或台架网络正常;
c)按照语音服务文档规定,通过实车或台架验证在各种工况下(静态、城市、高速工况等)的功能是否正常。
6.5.4多媒体服务
多媒体服务的试验方法如下:
a)依据相关设计文档,确认车载操作系统支持的文件导入方式,音视频格式、图片/视频分辨率,音频音质,及多媒体音源;
b)搭建实车或台架环境,车端或台架网络正常;
c)选择音源播放来源(蓝牙音乐、U盘音乐、在线音频、U盘视频、在线视频);
d)准备不同格式的图像、音频文件、视频文件;
e)准备不同分辨率图像、不同音质音频、不同分辨率视频文件;
f)采用步骤a)的提供的导入方式、文件及音源,对步骤b)、步骤c)的文件按进行播放控制测试,测试车载操作系统对不同格式的图像、音频、视频的兼容能力验证其H.264等编解码功能,观察播放质量(噪声、帧率、音质、流畅度、清晰度、音视频同步等);
g)检测是否有服务API或者车载小程序。
6.5.5软件升级服务
软件升级服务的试验方法如下:
a)审查软件升级服务相关设计文档,确认车载操作系统是否支持软件升级服务,如OTA升级功能;
b)搭建实车或台架环境,车端或台架网络正常;
c)云端配置车辆或台架数据环境;
d)云端上传升级包;
e)云端发布升级任务,推送至车端或台架;
f)通过实车或台架验证设计文档中规定的软件升级功能是否正常,检查是否升级成功。
6.5.6账号服务
账号服务的试验方法如下:
a)审查账号服务相关设计文档,确认车载操作系统是否支持账号服务,如账号分类、系统账号基础服务、系统账号与OEM账号、系统账号与云端应用账号、多账号管理功能;
b)搭建实车或台架环境,车端或台架网络正常;
c)准备测试手机,并下载OEMAPP、第三方应用;
d)不登录OEM账号使用游客账号,使用OEMAPP绑定及解绑OEM车主账号,OEM车主账号授权及解除非车主账号;
e)系统账号绑定及解绑;
f)第三方应用账号登录及退登;
g)OEM账号绑定系统账号,注销OEM账号或系统账号;
h)驻车及非驻车状态下,退出OEM账号;
i)多车登录同一OEM账号,多车登录同一系统账号;
j)使用第三方应用账号绑定及解绑系统账号;
k)第三方应用绑定系统账号,登录与退出系统账号,检查第三方应用账号登录状态;
l)系统账号与云端应用账号绑定,同一系统账号多端登录,检查第三方应用账号登录状态;
m)切换系统账号,检查账号下用户数据;
n)通过实车或台架验证设计文档中规定的账号功能是否正常。
6.5.7驾驶提示服务
驾驶提示服务的试验方法如下:
a)审查驾驶提示服务相关设计文档,确认仪表盘操作系统应支持驾驶相关故障告警提示服务,如控制器异常、油箱告警、电量告警、胎压告警等;
b)审查驾驶提示服务相关设计文档,确认中控操作系统支持驾驶提示服务,如控制器异常、油箱告警、电量告警、胎压告警、360环视、倒车影像、盲区提示、压线提示、透明底盘、轮胎轨迹线提示、行人提示、斑马线提示、前车距离提示、车道偏离提示等;
c)搭建实车或台架环境,通过实车或台架验证驾驶提示服务文档规定的功能。
6.5.8车辆设置服务
车辆设置服务的试验方法如下:
a)审查车辆设置服务相关设计文档,确认车载操作系统应支持车辆参数设定,如空调设置、电源设置等,可支持智能车辆设定,如结合车辆传感器和预设的配置文件,智能设置空调等;
b)搭建实车或台架环境,通过实车/台架验证车辆设置服务文档规定的功能。
6.5.9增强的人机交互服务
增强的人机交互服务的试验方法如下:
a)审查增强的人机交互服务相关设计文档,确认车载操作系统提供AR导航、疲劳驾驶、手势识别、人脸/摄像头遮挡识别、分心识别等人机交互服务;
b)搭建实车环境,通过实车验证增强的人机交互服务文档规定的功能。
6.5.10显示功能
显示功能的试验方法如下:
a)审查车载操作系统支持显示功能相关设计文档,确认车载操作系统应支持仪表显示,可支持行车记录仪、OMS显示、DMS显示、多屏幕显示、抬头显示;
b)搭建实车或台架环境,通过实车或台架验证车载操作系统支持显示功能文档规定的功能。
6.6程序运行框架
6.6.1互联互通框架
互联互通框架的试验方法如下。
a)查阅接口文档,检查是否支持按照不同的接口类型接入WLAN、蓝牙等车载设备。检查接口类型是否包括设备发现、快速接入、服务发现、协议校验、语音控制、在线升级、流量代理。
b)根据接口文档,编写应用程序调用互联互通框架功能接口,给接口传入给定的参数,使接口执行预期的功能,或使用企业推荐使用的应用程序或方法验证该功能(普适性)。
6.6.2服务融合框架
服务融合框架的试验方法如下。
a)查阅接口文档,检查是否能够提供服务的注册、发现、服务方法的调用、服务数据的订阅和发布、服务安全调用、服务调用并发数、异常调用时返回错误码、调用超时机制等;是否支持不同类型的服务组合成为新的服务或者应用。
b)根据接口文档,编写应用程序调用服务融合框架功能接口,给接口传入给定的参数,使接口执行预期的功能。
6.6.3多媒体框架
多媒体框架的试验方法如下:
a)查阅接口文档,检查是否包括音频输入输出与合成、预处理(如回声消除、滤波、去噪),后处理(如均衡、重低音、立体音效)等增强模块,以及基础的多媒体编解码服务;
b)根据接口文档,编写应用程序调用多媒体框架功能接口,给接口传入给定的参数,使接口执行预期的功能。
6.6.4多模态交互框架
多模态交互框架的试验方法如下:
a)若车载操作系统支持多模态交互框架,查阅接口文档,检查是否支持至少两种交互框架(如语音、视觉、手势、触摸屏、按键等),应用程序是否可选择接入一种或者同时接入多种方式来提供交互(如抬头显示、虚拟导航、通过手势来接听或者挂断电话等);
b)根据接口文档,编写应用程序调用多模态交互框架功能接口,给接口传入给定的参数,使接口执行预期的功能。
6.6.5场景感知理解框架
场景感知理解框架的试验方法如下:
a)查阅接口文档,检查是否支持根据场景规则或者机器学习模型提供计算和理解当前场景的功能,是否可订阅场景感知理解框架的输出信号来执行动作或者推送服务;
b)根据接口文档,编写应用程序调用场景感知理解框架功能接口,给接口传入给定的参数,使接口执行预期的功能。
6.6.6用户界面框架
用户界面框架的试验方法如下:
a)查阅接口文档,检查是否支持供窗口、界面元素和动画的编程接口及界面资源管理(贴图、多语言文本等),是否提供接口供三方渲染引擎绘制界面,是否支持2D或3D渲染;
b)根据接口文档,编写应用程序调用用户界面框架功能接口,给接口传入给定的参数,使接口执行预期的功能。
6.7多系统
6.7.1通用要求
采用文档审查方式,审查车载操作系统所支持的多系统方案。
6.7.2基于硬件隔离的多系统
基于硬件隔离的多系统试验方法如下:
a)审查硬件规格文档,确认是否提供了硬件强制隔离功能;
b)尝试将资源划分为与不同执行环境关联的不同所有权组,确认系统支持该操作且能够成功完成划分;
c)尝试在硬件资源(如SoC外围设备,内存区域和引脚等)所在分区,操作此硬件资源,尝试在其他分区对此硬件资源进行操作;
d)尝试由所有者进行与资源访问权限相关的操作,确认所有者拥有所属资源的访问权限,确认所有者能够查看资源的访问权限,能够修改访问权限;
e)检测是否支持对多个操作系统执行电源管理策略;
f)尝试在多操作系统间运行应用,并同时并行访问同一内存资源,确认通信正常并共享内存。
6.7.3基于虚拟机管理器的多系统
基于虚拟机管理器的多系统试验方法如下。
a)审查设计文档,确认虚拟机管理器具备管理硬件和外设资源的能力。
b)创建多个系统(至少两个),通过操作系统提供的命令或工具查看系统中的硬件资源的分配情况是否与设计文档一致,以验证是否已经将硬件资源分配给多个系统;更改虚拟机配置或重新编译,查看硬件资源能否被成功分配;通过执行并发使用测试、性能测试以及进行资源监控,检查被多个系统共享的硬件资源,是否可被多个系统成功共享。
c)创建多个系统(至少两个),通过操作系统提供的命令或工具查看系统中的外设资源的分配情况是否与设计文档一致,以验证是否已经将外设资源分配给这些系统;检查外设资源是否是通过虚拟机管理而非直接访问;通过执行并发使用测试、性能测试以及进行资源监控,检查被多个系统共享的外设资源,是否可被多个系统成功共享。
d)车载操作系统单系统尝试访问虚拟机管理器为其他操作系统的分配的资源。
e)在低安全级别虚拟机中编写测试程序通过DMA方式映射并访问高安全级别虚拟机所使用的物理地址,确认映射和访问不能够成功。
f)在低安全级别虚拟机中编写测试程序,对GPU等复杂有状态驱动进行故障注入(如reset等),确保高安全级别虚拟机不会受到任何影响。
g)为两个系统设置共享数据,编写测试程序,尝试两个系统访问共享数据,确认共享数据能够正常访问;尝试第三方访问共享数据,确认共享数据不能够被第三方访问。
h)为不同操作系统分配不同的优先级,确认虚拟机管理器能够优先处理高优先级系统发出的请求。
i)编写测试程序,尝试对操作系统执行启动、运行、关闭、重启、异常退出等操作,确认虚拟机管理器能够管理各操作系统的生命周期。
j)创建多个系统并使用此多系统完成多项操作,确认在操作过程中各软件运行流畅无卡顿,确认虚拟机管理器低性能损耗。
k)根据文档并使用此多系统,确认多系统提供全局电源管理。
l)为两个系统设置共享外设,编写测试程序,尝试让两个系统访问共享外设,确保在任何时刻只有一个虚拟机能够成功访问该外设;尝试让两个系统访问共享外设,确认共享外设不能够同时访问。
6.7.4基于容器的多系统
基于容器的多系统试验方法如下:
a)审查文档,确认多个车载操作系统单系统中的非内核部分是否运行在基于内核(如Linux等)的资源隔离管理框架之上;
b)审查不同容器之间是否能相互访问对方的文件系统;
c)检查某容器中的测试程序是否可以访问其他容器的进程,以及此容器是否能访问其他容器中的进程;
d)创建多个容器,检查每个容器的网络协议栈(包括网络设备接口、IPv4和IPv6协议栈、IP路由表、防火墙规则及sockets等)是否是独立的;
e)根据文档,测试资源隔离管理框架是否具备容器创建、启动、关闭及状态查询等管理能力;f)编写测试程序,观察系统能否将不同的应用程序或进程的根文件系统路径进行隔离,用户在系
统中具有不同的权限和访问控制,不同的网络连接无法直接通信,系统能够将不同的进程间通信进行隔离;
g)尝试查看CPU和内存资源的配额情况,确认系统提供相关操作,尝试修改CPU和内存资源的配额情况,确认修改操作能够成功;
h)编写程序,尝试在容器间及容器和Host间进行通信,确认基于容器的多系统支持容器间及容器和Host间的通信机制;
i)创建多个容器,检查不同的容器或应用程序的存储空间的状态,它们在文件系统层面上是否是相互隔离的;
j)编写测试程序,尝试在一个容器中制造异常(异常退出或进程异常),确认此容器的异常不会影响其他容器正常运行;
k)编写程序,尝试不同容器分配共享外设,确认容器能够使用共享的外设,尝试为容器分配独占外设,确认容器能够访问该独占外设,且其他容器不能访问该独占的外设。
6.8可信执行环境
可信执行环境的可信操作系统试验方法如下:
a)审查厂商提交的文档,检查可信操作系统的设计;
b)检查可信操作系统的日志管理功能,检查是否重要的系统操作都能被记录,验证日志记录是否可能被篡改;
c)检查可信操作系统的内存管理功能,尝试分配与回收内存,验证内存隔离机制,验证内存加解密的有效性;
d)检查可信操作系统的设备管理功能,检查设备驱动程序是否存在安全漏洞,验证设备访问权限控制是否有效,测试设备I/O操作是否按预期进行。
6.9性能试验
6.9.1通用要求
性能试验满足如下要求:
a)温度要求:测试环境温度应控制在20℃~30℃;b)湿度要求:测试环境的相对湿度应控制在30%~60%;
c)其他环境因素:应避免其他可能对测试结果产生干扰的因素如强电磁干扰、振动等;
d)环境稳定时间:在开始性能测试之前,应确保测试环境的温度和湿度已稳定在规定的范围内,并保持稳定状态30min以上,避免因环境变化过快对测试结果产生影响。
6.9.2热启动时间
热启动时间性能测试应按照下列流程及要求依次进行。
a)搭建测试环境。
b)将设备格式化并刷入待测系统。
c)系统启动后进入STR模式或休眠(standby)模式。
d)唤醒系统,记录时刻t1。
e)待仪表信息或倒车影像(倒车雷达)呈现,记录时刻t2。
f)待操作界面可用,记录时刻t3。
g)待HUD界面显示稳定,记录时刻t4。
h)得出3个启动时间值:
1)切换到仪表信息或倒车影像(倒车雷达)呈现时间:t2-t1;
2)切换到操作界面可用时间:t3-t1;
3)到HUD界面稳定显示时间:t4-t1。
i)设置系统进入STR模式或休眠(standby)模式。
j)设置循环次数,循环执行步骤d)~i)。
k)根据h)的计算方式得出多组启动时间数据可进行相应的性能结果统计(包括最大、最小、平均值等),得到3个热启动标志性动作的性能结果。
6.9.3冷启动时间
冷启动时间性能测试应按照下列流程及要求依次进行。
a)搭建测试环境。
b)将设备格式化并刷入待测系统。
c)打开设备电源,记录时刻t1。
d)待仪表信息或倒车影像(倒车雷达)呈现,记录时刻t2。
e)待操作界面可用,记录时刻t3。
f)待操作界面视觉可见,记录时刻t4。
g)待开机动画界面视觉可见,记录时刻t5。
h)待HUD界面视觉可见,记录时刻t6。
i)得出5个启动时间值:
1)上电到仪表信息或倒车影像(倒车雷达)呈现时间:t2-t1;
2)上电到操作界面可用时间:t3-t1;
3)上电到操作界面视觉可见时间:t4-t1;
4)上电到开机动画界面视觉可见时间:t5-t1;
5)上电到HUD界面视觉可见时间:t6-t1。
j)关闭设备电源。
k)设置循环次数,循环执行步骤c)~g)。
l)根据i)的计算方式得出多组启动时间数据可进行相应的性能结果统计(包括最大、最小、平均值等),得到2个冷启动标志性动作的性能结果。
6.9.4优先级调度响应时间
优先级调度响应时间测试应按照下列流程及要求依次进行:
a)搭建测试环境;
b)将设备格式化并刷入待测系统;
c)运行测试程序使CPU处于高负载,禁用系统中的其他中断;
d)创建n个不同优先级的周期性实时任务并运行,且每个任务都会设置一个timer,用于周期性的唤醒该任务;
e)设置任务进入睡眠状态,记录时刻t1,睡眠时间为t2;
f)任务被唤醒后记录当前系统时间t3;
g)得出任务系统调度延迟:t3-t2-t1;
h)循环执行步骤e)、f),进行多次测试;
i)在操作结束后,得出高负载时,n个任务的多组调度延迟数据,计算后可得每个优先级任务调度延迟(包括最大延迟、最小延迟、平均延迟)。
6.9.5存储空间读写性能
存储空间读写性能测试应按照下列流程及要求依次进行:
a)搭建测试环境;
b)将设备格式化并刷入待测系统;
c)启动测试程序并设定读/写次数和读/写参数;
d)开始读/写文件,记录时刻t1;
e)完成1GB 大小数据读/写后停止,记录时刻t2;
f)得出读/写1GB 大小数据耗时:t2-t1;g)循环执行步骤c)~f);
h)在操作结束后得出多组参数下1GB 数据读/写耗时后计算平均读/写速度。
6.9.6虚拟机管理器的资源开销(CPU/GPU)比率
虚拟机管理器的资源开销(CPU/GPU)比率性能测试应按照下列流程及要求依次进行。
a)配置一台安装虚拟机管理器的系统A,一台不搭载虚拟机的系统B(A、B为同一系统),分别用于运行评分软件。
b)在所有系统中禁用所有安全机制(如防火墙、SELinux等),以减少干扰。
c)在搭载虚拟机管理器的系统A中运行评分软件,得到:
CPU评分:A1
GPU评分:A2
d)在另一台系统B,进行相同的测试,得到:
CPU评分:B1
GPU评分:B2
e)计算CPU和GPU的性能比率:
CPU比率=A1/B1
GPU比率=A2/B2
f)计算虚拟机管理器带来的资源损耗:
CPU损耗=1-(A1/B1)
GPU损耗=1-(A2/B2)
g)循环执行步骤d)~f)。
h)多次操作取平均值得出虚拟机管理器占用CPU和GPU的总资源的比率。
6.9.7多系统间通信
多系统间通信性能测试应按照下列流程及要求依次进行:
a)搭建测试环境;
b)将设备格式化并刷入待测系统;
c)启动测试程序,关闭安全机制并设定循环次数;
d)发起通信,记录当前系统时间t1;
e)收到响应消息后记录当前系统时间t2;
f)循环执行步骤d)、e);
g)得出多系统间通信时间:t2-t1;
h)在操作结束得出多组数据后计算多系统间通信时间(包括平均时间、最长时间、最短时间)。
6.9.8可信执行环境性能
6.9.8.1CPU性能
CPU性能测试应按照下列流程及要求依次进行:
a)在绑定单核的情况下,分别在TEE侧和REE侧利用CPU求解一定范围内的所有质数,记录处理时间;
b)在绑定多核的情况下,分别在TEE侧和REE侧利用CPU求解一定范围内的所有质数,记录处理时间。
6.9.8.2内存性能
内存性能测试应分别在TEE侧和REE侧进行内存复制操作,记录耗费时间。
6.9.8.3存储读写性能
存储读写性能测试应按照下列流程及要求依次进行:
a)在REE侧对数据分别进行存储与读写操作,记录耗费时间;
b)在TEE侧使用反向调用的方式,对REE侧数据分别进行存储与读写操作,记录耗费时间。
6.9.8.4加解密性能
加解密性能测试应按照下列流程及要求依次进行:
a)在定频定核的情况下,分别在TEE与REE下进行AES256等算法加解密操作,并记录消耗时间;
b)在定频定核的情况下,分别在TEE与REE下利用RSA2048等算法生成密钥对并进行加解密操作,记录耗费时间;
c)在定频定核的情况下,分别在TEE与REE下计算SHA512等哈希值,并记录耗费时间。
6.9.8.5通信性能
通信性能测试应按照下列流程及要求依次进行:
a)编写服务端TA,分别测试客户端TA与客户端CA访问服务端的时间;
b)测试在REE到TEE多条通道完全阻塞的情况下,再启动一条新的通道,确认新的通道是否能正常传输数据。
6.10信息安全试验
6.10.1通用安全
6.10.1.1系统安全
系统安全的试验方法包括系统用户管理、系统服务管理、系统安全启动、系统漏洞管理、软件升级安全、系统内核加固、系统访问控制和编译器的试验方法,具体试验方法如下。
a)系统用户管理的试验方法如下:1)尝试root用户直接登录系统;
2)尝试为不同角色的账号设置使用权限;
3)查看系统中所有账号,尝试以开发账号和测试账号登录系统;
4)编写测试程序,修改各种不成功鉴别尝试值(包括尝试次数和时间的阈值)的预设值,根据修改的值的类型,进行相应的不成功登录,确认当达到预设值时,系统是否能够鉴别失败并进行处理;
5)审查身份验证功能的相关设计文档,确认特权用户身份验证应支持口令鉴别、基于令牌的动态口令、生物特征识别(刷脸、声纹或虹膜等)、数字证书鉴别等多种方式;
6)尝试以特权用户身份进行登录,确认是否在访问安全功能相关的操作之前完成身份验证的鉴别工作。
b)系统服务管理的试验方法如下:
1)审查系统服务相关设计文档,确认操作系统对关键资源实施强制访问控制(MAC);
2)在系统中安装应用级程序、系统级程序、接口资源访问程序,查看应用程序的权限,确认应用程序只能获得最低权限;
3)审查系统服务相关设计文档,确认系统对关键资源实施自主访问控制(DAC);
4)尝试在系统中对文件和可执行文件的访问进行管理和审计;
5)启动操作系统,查看系统中的服务。
c)系统安全启动的试验方法如下:
1)检查操作系统所使用的芯片是否支持安全启动功能,并且其OTP功能被启用;
2)检查芯片安全启动程序相关文档或源代码,如Bootloader,确认是否有根证书验证过程;
3)检查安全启动过程的相关文档或源代码,确认所使用算法是国家密码管理机构推荐的,并符合国家相关标准规定;
4)检查操作系统Bootloader相关安全设计文档,确认Bootloader是否具备防篡改机制。
d)系统漏洞管理的试验方法如下:
1)通过自动化代码扫描结合人工代码审核的方式对操作系统源代码进行审阅;
2)通过二进制代码扫描的方式对操作系统镜像文件进行检查。上述两种试验方法可结合实际情况选择其中一种。
e)软件升级安全的试验方法如下:
1)审查操作系统软件升级方面的设计文档;
2)在服务器放置经过篡改的升级包,并通知操作系统下载升级包;
3)在服务器放置未经数字签名的升级包,并通知操作系统下载升级包。
f)系统内核加固的试验方法如下:
1)查看相关文档,确认车载操作系统内核的安全加固机制,确认内核是否采用了如安PXN、PAN、KASLR、控制流完整性保护、RODATA、ROSYSCALLTable、页表完整性保护等全加固机制;
2)查看车载操作系统对内核的保护机制,确认系统是否对内核进行了完整性保护,尝试破坏内核的完整性,确认内核的保护机制是否能够识别出错误;
3)查看车载操作系统对可执行的系统调用的范围进行了限制,是否限制了进程的特权范围,内核是否支持强制访问控制,如SElinux;
4)审阅相关文档,确认系统是否支持地址空间布局随机化机制(ASLR)。
g)系统访问控制的试验方法如下。
1)查看系统读写权限,并尝试对只读区域写入数据,对包含只读数据的存储分区的保护机制,确认车载操作系统是否采用了一种机制来对数据进行块级或文件级完整性保护;尝试破坏数据的完整性,确认车载操作系统是否能够识别出错误。
2)查看系统对包含读写数据的存储分区的保护机制,确认车载操作系统是否采用一种机制来对数据进行块级或文件级完整性保护;尝试破坏数据的完整性,确认车载操作系统是否能够识别出错误。
3)查看系统确认是否提供了常见的入侵检测功能,是否支持针对特定端口或IP的访问控制;利用6.1.8中的试验方法,对系统进行渗透入侵,确认系统是否能够成功检测到此次入侵;尝试对特定端口或IP进行访问控制操作,确认系统是否提供该操作,并且操作是否能够成功。
h)编译器的试验方法如下:
1)审阅相关文档,并检查编译器,确认编译器是否支持堆栈保护;
2)审阅相关文档,并检查编译器,确认编译器是否支持编译时缓冲区溢出检查。
6.10.1.2数据安全
数据安全的试验方法如下。
a)在系统中运行能够进行数据采集服务的预装应用,启动应用并尝试进行数据采集,确认系统是否能够明确告知用户采集的目的和范围。
b)在系统中运行能够获取多项用户敏感个人信息的应用。尝试在已获取授权同意的情况下采集对应个人信息;尝试在未获取授权同意的情况下采集对应个人信息;尝试在授权同意期满之后再次采集对应个人信息。确认上述采集行为是否符合要求。
c)审查数据安全设计相关文档,查看应用收集个人信息是否限于实现处理目的所必要的最小范围,且需要取得用户的明示同意。
d)在系统中运行能够采集远程控制、远程诊断等功能场景下所发送的指令数据的应用程序,尝试采集远程控制、远程诊断等功能场景下所发送的指令数据,确认是否向用户提出了具体的、清晰明确的授权同意,确认该授权同意是否由用户在完全知情的基础上自愿给出;确认采集动作是否在获得授权同意之后进行。
e)在系统中运行能够让设备或后台存储用户数据的应用,确认在存储数据之前,是否会告知用户并获取授权;用户选择拒绝授权,并退出登录,确认用户个人数据是否被清空;再次运行测试应用并且用户选择授权,确认系统是否为用户提供直观易用的数据删除选项,以及撤回授权的选项;尝试将系统恢复出厂设置,确认用户数据是否被清除,或提供用户数据是否一并删除数据的选项。
f)在系统中运行能够访问用户数据的应用程序,尝试在非授权的情况下访问用户数据,确认系统是否允许访问。
g)查看系统的用户间隔离机制,在系统中创建多个用户,尝试用户在非授权的情况下访问其他用户的数据,确认是否能够访问其他用户的数据。
h)尝试关闭用户数据采集功能,确认系统是否提供了用户关闭功能。
i)尝试进行各种用户数据操作,包括采集、传输、存储、销毁等操作,确认系统是否对相关操作保存了日志。
j)尝试存储敏感个人信息,确认敏感个人信息是否以明文方式存储。
k)查看系统对于生物特征信息的存储方式。
l)查看参数完整性校验功能,确认系统是否对安全重要参数进行了完整性校验,是否采取了相应的措施来避免重要参数的丢失和误删除,是否对安全重要参数采用了备份或安全空间存储。
m)查看系统中的各类日志,确认系统是否为各类日志设置了默认等级,并尝试对日志等级进行修改。
n)查看对车辆内外部通信及相关业务的关键数据的保护机制,确认系统是否对关键数据采用了加密存储、访问控制、加密传输等机制予以保护。
o)查看对关键数据整个生命周期的安全防护机制,确认系统是否对关键数据的全生命周期,包括数据的生成、收集、存储、访问、传输、分析、使用、销毁等环节,提供了安全防护机制。
p)查看系统在进行数据采集时,是否遵循最小采集原则;尝试进行数据采集,确认是否告知用户采集的目的;是否在征得用户同意之后才能够完成数据采集。
q)查看系统是否是否采取了相应的安全机制,以保护存储数据的保密性和完整性;查看系统是否采用了数据脱敏、数据加密技术;查看系统是否使用了安全存储,采用物理安全芯片或可信执行环境、分区隔离等技术。
r)确认系统是否采用了数据使用的授权机制,确认在数据使用时是否提供了权限的验证机制,是否采取了相应措施以验证数据的完整性和真实性。
s)尝试执行数据共享操作,确定在共享时是否询问了个人信息主体的同意,确定是否完成了共享数据的备份。
t)尝试执行数据销毁操作,确认数据是否被彻底销毁,销毁后是否有数据遗留,是否能够恢复数据。
6.10.1.3通信安全
通信安全的试验方法如下。
a)尝试在系统中设置网络通信白名单,确认系统是否提供网络通信白名单功能。
b)在系统中设置网络通信白名单,尝试与受到系统信任的URL建立通信链接(如HTTPS/以太网/蓝牙等),与未信任URL建立通信链接,确认是否只有受到系统信任的URL才能建立通信链接。
c)查看通信加密功能,确认是否使用TLSv1.2(长度不低于2048的RSA算法或长度不低于256的ECC算法)及以上版本进行通信。
d)尝试发送敏感个人信息,确认是否使用TLSv1.2及以上版本进行双向认证。
e)查看通信协议设置,确认系统中是否存在HTTPS和HTTP混合通信;确认系统中是否全部支持HTTPS进行通信。
f)查看随机数生成器的具体设计,确认系统中是否采用了已验证、安全的随机数生成器。
g)尝试生成随机数,确认随机数是否符合随机数相关标准(例如:GM/T 0005-2021等)。
h)查看参数配置的具体设计(包括设备身份标识、认证机制、安全通信协议、安全服务类型、安全服务描述、安全服务授权信息、安全服务地址、指定哈希算法、指定加密算法、加密密钥、证书类型、证书签发者、证书有效期、证书有效区域、证书权限范围和应用数据签名权限),确认参数配置是否是已验证且安全的,确认使用的证书是否全部都是被配置为可信的证书或证书链。
i)审查通信流程,确认网络通信时,系统是否会对数据的完整性进行校验。
j)编写测试程序,尝试在网络通信时发送校验值不正确的数据,确认是否能够成功校验出错误,并且终止响应该操作。
k)审查通信流程,确认在网络通信时,系统会对通信双方进行身份验证。
l)尝试篡改网络通信某一方(或双方)的身份,并进行网络通信,确认身份鉴权是否能够识别发现错误,并终止相应操作。
m)确认系统是否支持基于PKI的证书管理机制和安全协议。
n)审查网络隔离机制,确认是否对外部网络与车内网络间进行隔离(如VLAN或物理隔离)。
o)尝试进行网络通信并完成各种操作,确认系统是否利用日志对关键事件进行记录。
p)尝试在网络通信中发送异常报文,确认系统是否能够感知异常报文。
q)对操作系统进行端口扫描,确认是否存在隐蔽端口;查看所有开启端口,确认这些端口是否是系统运行和业务应用所必要的;确认所有无用的端口是否已经被关闭。
r)确认车外网络通信是否具有访问控制机制(如防火墙)。
s)尝试分别以授权访问和非授权访问两种方式,利用车外网络进行通信,确认访问控制机制是否能够识别出非授权访问,是否能够阻止该非授权访问。
t)审查车内网络隔离机制,确认车内是否具备安全网络域的隔离(VLAN)。
u)使用6.1.6和6.1.8中的试验方法,对防火墙进行模糊测试与渗透测试,确认防火墙是否能够拦截非法报文,确认防火墙是否能够拦截与未定义网络之间的通信。
v)检查防火墙的工作机制,确认在保存防火墙的相关数据时,是否采用了安全存储机制。防火墙相关数据包括拦截数据流量、防火墙故障状态和防火墙规则数量等。
w)检查防火墙的工作机制,确认防火墙是否支持将数据上报或转发其他模块处理的功能。
6.10.2应用安全
应用安全的试验方法如下。
a)确认是否对应用采取了防逆向措施,宜采用地址随机化、代码混淆或加壳等措施。
b)对车载操作系统的应用进行逆向工程,确认应用是否能够防逆向分析。
c)确认是否会利用签名认证机制,对应用软件安装包进行真实性和完整性验证。
d)确认系统加载应用时,是否会验证其完整性。
e)尝试向系统中安装签名有误的应用,确认签名验证机制是否能够成功检测出错误。
f)尝试利用应用访问、操作和使用系统资源及数据,确认系统在执行相关操作时,是否会校验应用的访问权限。
g)查看应用在访问、操作和使用系统资源及数据时的请求,确认访问请求中是否直接附带了应用身份和权限信息;确认服务提供方是否会对权限进行校验。
h)确认应用间是否采用隔离机制。
i)确认系统在对不同应用的重要数据进行加密时,是否采用了不同的密钥。
6.10.3审计安全
审计安全的试验方法如下。
a)运行系统,进行包括触发报警、连接网络、运行应用等在内的任意操作,确认系统是否会对以下事件生成审计日志:系统运行记录、报警记录、操作日志、网络流量记录、应用软件运行日志、配置信息等。
b)查看审计日志的内容,确认其中是否包括事件发生的日期、时间、主体标识、事件类型描述和结果(成功或失败)、关联的进程等。
c)检查日志的本地存储机制,确认审计日志是否在本地保存,尝试将审计日志保存至本地,确认是否能够成功保存。
d)检查日志的权限管控机制,确认系统是否对访问本地日志进行权限管控;在无权限的情况下对本地日志进行访问,再在有权限的情况下对本地日志进行访问,确认对本地日志的权限管控是否有效。
e)检查日志的存储机制,确认系统是否对于本地日志采用了加密存储。
f)确认是否为审计信息提供数字签名和时间戳功能,确认数字签名和时间戳功能是否真实有效。
g)确认审计日志是否能够传输到云端。
h)确认系统是否进行敏感信息审计,是否禁用SU、SUDO命令,是否禁止敏感IP,是否禁止明文的密钥文件;尝试使用su、sudo命令,使用敏感IP,使用明文的密钥文件,确认行为是否被禁止。
i)确认系统是否文件系统审计功能,是否进行文件权限读写配置,是否进行分区挂载rwx属性配置;尝试进行文件权限读、写、执行配置,尝试进行分区挂载rwx属性配置,确认相关操作是否支持。
j)确认服务审计中是否包括禁用调试服务、调试驱动等。
k)确认应用审计是否包括开启Canary栈溢出保护等。
6.10.4多系统安全
多系统安全的试验方法如下。
a)检查多系统安全启动的整体流程,确认流程是否具备统一的硬件可信根和完整的信任链;尝试篡改或指定错误的硬件根和信任链,确认是否能够识别错误。
b)检查多系统域隔离安全机制,确认是否能够确保多操作系统间的空间隔离(如内存、Cache、外设等)、时间隔离(如硬实时、时间窗配置等)。
c)检查多系统权限模型,确认虚拟机的每项资源是否能够通过独立的权限进行管理,确认系统中是否不存在具备最高等级权限的虚拟机,尝试对虚拟机中的资源进行权限管理,确认与设计文档内容相符。
d)检查多系统间通信机制,确认是否具备多系统间通信身份验证和访问控制的能力。
e)尝试以合法身份进行通信,再以不合法的身份进行通信,确认是否只能在通过身份验证的情况下进行多系统间通信。
f)尝试拥有访问权限的前提下发起访问,再以没有访问权限的前提下发起访问,确认事发后只有拥有访问权限才能完成访问。
g)检查多系统驱动框架对驱动的防护机制,确认多系统驱动框架对驱动提供有限防护(例如基于内核安全机制检测、前后端驱动隔离等技术)。
h)检查多系统间隔离机制,确认隔离机制能够防止系统数据的非授权访问。
i)尝试在授权的情况下,访问多系统的系统数据,确认是否能够正常访问;尝试在非授权的情况下,访问访问多系统的系统数据,确认是否无法访问。
6.11功能安全试验
在进行车载操作系统的验证活动中,应基于仿真测试等方法开展验证,应对验证计划和结果进行检查,以证明满足面向功能安全的安全概念。验证应通过向操作系统相关的电子电气组件施加相应的输入,来模拟组件内部典型故障的影响,以检查系统组件发生失效的情况。
现成译文，到款即发（兼具高性价比与及时性）。
下单前可任取样页验证译文质量。
免费提供正规普通增值税电子发票。
请联系手机/微信: 13306496964/Email: standardtrans@foxmail.com 获取完整译文。
本英文译本为纯人工专业精翻版本，保证语法术语准确率和专业度！非AI译文可比！
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！「中国汽车标准译文库」已收录上千个现行汽车国家标准和行业标准的英文版译本，涵盖传统燃油车、新能源汽车和摩托车标准化体系！独家打造千万级汽车专业术语库和记忆库。
The English Translation of this document is readily available, and delivered immediately upon payment.
Sample pages may be requested to your preference before placing order.
Please contact standardtrans@foxmail.com for the complete PDF version in English.
Our well-established database has included almost all Chinese automotive standards in effect, providing one-stop, up-to-date, efficient and professional solution.