智能座舱系统的网络安全需求分析和要求(超详细含架构图)
1. 术语与定义
1.1 术语
| 术语 | 定义 |
|---|---|
| 智能座舱 | 定义了一种智能服务系统,是整个移动过程中给用户提供人、车、环境需求和信息交互的空间。作为集合智能网联与驾乘体验的高附加值的电子系统,是未来汽车核心三大域之一 |
| 座舱设备 | 本文简称为“设备”,定义为具有独立运算空间的硬件及其上的驱动、内核、操作系统等组成的功能独立体,座舱设备之间可以通过媒介(比如蜂窝、CAN-bus、Wifi)进行数据通信,以完成设备功能。 |
| 座舱应用 | 由用户操作,与网络服务连接,能对智能汽车进行远程或者近场操作的应用程序。 |
| 云服务平台 | 指智能网联汽车服务平台,是能够实现智能网联汽车的接入和管理,为汽车提供设备管理、操作、控制等应用服务的平台系统。也称为云服务平台或云平台。 |
| 以太网 | 通过无线介质进行数据传送的局域网。这里特指通过车内WIFI互联的局域网。 |
| 个人身份信息 | 以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然人活动情况的各种信息。也称为个人信息。 |
1.2 符号
| 符号 | 英文全称 | 中文全称 |
|---|---|---|
| ICT | Information and communications technology | 信息通信技术 |
| IOT | Internet of Things | 物联网 |
| OBU | On board Unit | 车载单元 |
| RSU | Road Side Unit | 路侧单元 |
| HMI | Human Machine Interface | 人机接口 |
| HSM | Hardware security module | 硬件安全模块 |
| ADAS | Advanced Driving Assistance System | 高级驾驶辅助系统 |
| CAN | Controller Area Network | 控制器域网 |
| T-BOX | Telematics BOX | 远程信息处理设备 |
| RTE | Run Time Environment | 运行时环境 |
| BSP | Board Support Packet | 板级支持包 |
| HTTP | Hyper Text Transfer Protocol | 超文本传输协议 |
| IP | Internet Protocol | 因特网协议 |
| OWASP | Open Web Application Security Project | 开放式应用安全项目 |
| SHA | Secure Hash Algorithm | 安全杂凑算法 |
| SQL | Structured Query Language | 结构化查询语言 |
| SSL | Secure Sockets Layer | 安全套接层 |
| TLS | Transport Layer Security | 传输层安全协议 |
2. 座舱架构描述
2.1 座舱构成
由于当前智能座舱系统架构的多样化,但是基本的数据信息流过程和交互单元几乎一致。因此,本文所指的智能座舱系统构成示意图如下所示。智能座舱系统的构成分为智能座舱域控制器以及仪表盘、中控屏、车载娱乐系统、智能座椅等,并通过T-BOX与TSP云端服务传递指令和状态数据等。
2.2 网络拓扑
智能座舱系统在整车架构中位置及其与其他设备之间组成的网络拓扑,决定了数据通信协议和信息流的流转方式,也是安全威胁面分析的重点对象。智能座舱的网络拓扑图如图所示。
注:LVDS(低电压差分信号)GNSS(全球导航卫星系统)DMS(座舱监测技术)AVM(全景式监控影像系统) W-HUD(直投挡风玻璃HUD)AR-HUD(增强现实HUD)FM/AM(调频/调幅)
2.3 平台框架
智能座舱系统涉及的硬件设备和车机应用众多,与外围设施的通信交互也具有多样化的特点。但是,总体上可归纳为座舱设备、座舱应用和云端服务三者之间的交互,包括远程操作模式和本地操作模式等。远程操作是用户通过互联网座舱模块进行远程管理、控制和查询,通常需要经过云端服务平台。本地网络操作模式是用户通过座舱应用对同一局域网中的座舱模块进行管理、控制和查询。智能座舱平台框架如图所示。
因此,本文的安全目标范围主要包括座舱设备、云服务平台、座舱应用组成的智能座舱系统,以及系统中各部分之间的交互流程。
3. 安全技术分析与要求
3.1 座舱设备安全
3.1.1 安全启动
a) 座舱设备启动时,Bootloader需要校验代码的完整性和合法性(代码签名验证)
b) FOTA升级的通道,需要保证其安全性,需要具备防恶意篡改功能,如双向认证的TLS安全通道。
c) 若使用线下烧写固件代码的方式,需要对烧写工具做访问控制措施。
3.1.2 身份鉴别
- 设备身份鉴别
a) 座舱各设备之间进行通信前,应对通信双方端点的身份进行鉴别,包括但不限于口令鉴别、证书鉴别等;
b) 如采用口令鉴别方式,应在首次使用时修改出厂默认口令;
c) 服务平台提供数字证书进行身份认证,证书签名采用SHA256以上算法;
d) 设备应使用随机令牌作为云平台的身份验证的一部分(关键设备信息使用随机生成的字符串);
e) 重新建立会话或会话超时,应重新进行身份验证。
f) 车机与手机互联时,需要做配对核查措施,并在出现异常配对情况时,及时向车主报警或阻断,或者由车主做应用授权。
- 证书处理
a) 设备工程团队应保护高等级商业私人TLS数字证书,不得披露信息,该规范符合有关系统运行所涉及的加密和密钥托管安全性的区域法律法规。
- 证书供应
a) 设备应采用高级商用私有TLS数字证书,用于通信链路安全,这是自身独有的,符合有关系统运行所涉及的加密和密钥托管安全性的区域法律法规;
b) 该设备独特的高级商用私有TLS数字证书应存放在采用硬件公开保护机制的微处理器上。
- 证书验证
a) 设备应验证数字证书以及数字证书的颁发者;
b) 设备应阻止用户绕过证书验证。
3.1.3 通信安全
a) 建立会话前,应协商密钥,协商出的加密密钥长度应不小于128位,传输数据应采用加密密钥进行加密;如需传递加密密钥,应对加密密钥采取保护措施;
b) 进行数据传输时,应对传输数据进行完整性校验,避免遭受篡改、删除、插入等数据完整性攻击。一旦检测到数据完整性被破坏,应丢弃所接收的数据或采用其他安全操作;
c) 会话过程中,应采用时间戳或者类似机制以抵御重放攻击;
d) 重新建立会话或会话时间持续超过24小时,应重新协商密钥。
e) HMI、中控、T-BOX以及网关之间,需要建立具备双向认证的安全通道后方可传输指令和数据。
f) 应对灯光、车窗、方向盘等设备发出和接收的指令做严格的身份认证,确保每个控制指令是正常的操作指令。指令的发出端和接收端需要做强认证策略,以避免中间人劫持,恶意更改指令。
g) 空调温度、风速、模式调节等,同样需要强认证手段验证各指令的完整性和可靠性。
h) 双向认证使用的证书和密钥文件等,应有必要的安全存储区域,比如HSM、加密芯片等。
3.1.4 数据保护
- 数据披露
a) 应采用硬件和软件机制来保护传输过程中的数据;
b) 应采用硬件和软件机制来保护固件信息免受泄露。
- 数据存储
a) 设备应按
