书签 分享 收藏 举报 版权申诉 / 125

类型中国汽车工业协会:中国汽车基础软件信息安全研究报告1.0(2022)(125页).pdf

  • 上传人:大***
  • 文档编号:107203
  • 上传时间:2022-11-24
  • 格式:PDF
  • 页数:125
  • 大小:7.82MB
  • 配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    中国汽车工业 协会 中国汽车 基础 软件 信息 安全 研究 报告 1.0 2022 125
    资源描述:

    1、中国汽车工业协会中国汽车基础软件生态委员会(AUTOSEMO)地址:北京市丰台区汽车博物馆东路诺德中心11号楼33层邮政编码:110160联系电话:010-63979900 邮箱:autosemo-网址:2022中国汽车基础软件信息安全研究报告 1.0发布单位:中国汽车工业协会软件分会 中国汽车基础软件生态委员会(AUTOSEMO)序 言随着人工智能的广泛普及,智能汽车已经逐渐在向社会的舞台中心走去。从安全的视角来说,安全是一个伴生技术,一旦出现了新的信息技术,自然会伴生有相应的安全问题。在有信息通信的年代,通信安全成为人们关注的话题;在计算机、计算机网络出现之后,计算机安全、网络安全也就应运

    2、而生;随着移动互联网、物联网、云计算、大数据、区块链、人工智能、量子计算、工业互联网、元宇宙等新技术的出现,移动互联网安全、物联网安全、云安全、大数据安全、区块链安全、人工智能安全、量子安全、工业互联网安全、元宇宙安全的研究领域也自然伴随着出现。显然,智能汽车的出现,智能汽车安全就势必成为制约智能汽车发展的主要因素,从而需要不断加以攻关与突破。一般来说,智能汽车安全可以从三个视角来进行观察:第一个视角是智能汽车安全问题所存在的层面,其安全问题反映在硬件层、代码层、数据层和应用层四个层面。其中,在硬件层表现在电磁安全方面,即电磁干扰会导致汽车电子部件失灵,如 ABS、安全气囊、发电机调节器等;在

    3、代码层表现在软件安全方面,即进入到亿行代码阶段的汽车电子平台软件,其不可避免的软件漏洞必将引发风险;在数据层表现在信息安全方面,即智能网联车具有监管数据、特征数据、网络数据、业务数据、应用数据等各类数据需要通过网络上传,所涉及的隐私面临着被窃取、伪造、篡改、破坏等方面的风险;在应用层表现在功能安全方面,即智能汽车可能存在因软件、算法等方面的原因导致汽车功能失能致使失控的情况发生,从而会引发人身安全。第二个视角是智能汽车需要安全稳定的四个核心功能,其安全问题反映在信息获取、信息传输、信息处理和信息利用四个核心功能。其中,在信息获取功能方面可能会表现出环境感知的安全问题,如超声波雷达、毫米波雷达、

    4、鱼眼摄像等获取设备可能会因为外部攻击而形成错误的感知,致使信息获取方面的错误;在信息传输方面可能会表现出网络传输的安全问题,如 CAN 总线、LTE-V2X 车联网、5GUU 空口传输等传输环境可能会因网络攻击而导致信息被窃取或攻击信息的插入;在信息处理功能方面可能会表现出决策执行的安全问题,如执行单元、接口单元、娱乐单元都有可能存在着黑客攻击的入口,从而会导致对车辆的本地控制及对其它车辆的远程操作控制,致使汽车电子系统易被劫持;在信息利用功能方面可能会表现出行驶控制的安全问题,如控制单元、转向系统、制动系统等一旦被远程控制,将会造成汽车安全事故。第三个视角是智能汽车在安全领域的四种表现形态,

    5、其安全问题反映在赋能攻击、赋能防御、内生安全和衍生安全四个安全现象。其中,在赋能攻击方面可能会表现出信息安全问题,如智能汽车强大的感知能力与网络回传能力可能会被用于情报收集领域;在赋能防御方面可以表现出辅助安全的能力,如智能汽车强大的决策响应能力在辅助驾驶时可以有效帮助驾驶员回避危险;在内生安全方面可能会表现出决策安全问题,如神经网络算法的基础是标注数据,其不可解释性容PREFACE易被非标注数据形成对抗样本攻击从而导致误判;在衍生安全方面可能会表现出人身安全问题,如当人工智能技术运用于控制汽车电子系统时,可能会因为人工智能技术的不被掌控属性,导致像速度与激情 8电影中所描述的那样形成僵尸车队

    6、,从而会对人类产生威胁。总之,智能汽车安全是针对智能汽车的电磁安全、软件安全、信息安全、功能安全四个安全层面,围绕着环境感知、网络传输、决策执行、行驶控制四个核心功能来保障其安全可靠;同时,既要应对新技术引发的汽车自身的决策安全,也要应对因汽车活动而衍生的威胁他人的信息安全与人身安全的情况。智能汽车的安全作用是在驾驶领域中发挥出辅助安全的赋能效应。智能汽车安全的底座是汽车基础软件信息安全,其所涉及的技术面非常广,需要不同领域的专家来共同研究与探讨。为此,在中国汽车工业协会的指导下,AUTOSEMO组织了一个由21家企业与院校组成的编委会,把各家最新的研究成果和最佳实践提炼、总结、分享出来,通过

    7、撰写本汽车基础软件信息安全研究报告,以共同推动汽车基础软件信息安全的技术研发、标准建立、应用落地及产业化发展。中国工程院院士2022年11月6日今天,百年历史的汽车行业正经历着颠覆性的变革。随着汽车电动化、网联化、智能化的发展,汽车已经从一个运输的工具,演变成一个移动的智能空间,一个大数据的交互平台,一个分布式储能单元和一个大算力的运算中心。快速演进中的汽车网联化、智能化使得汽车信息安全(网络安全、数据安全)成了一个越来越不容忽视的重要问题。国际、国内的研究报告显示,智能网联带来的各类网络攻击的风险大大增加,网络安全事件层出不穷,智能网联汽车的信息安全不仅涉及车辆自身的安全,而且关乎个人、社会

    8、、国家的安全,车辆受到网络攻击所造成的危害日益严重。以UNECE/WP.29(R155、R156)和 ISO/SAE 21434 为代表的汽车信息安全的国际法规与标准的发布与实施,以国家网络安全法、数据安全法、个人信息保护法的实施,以及一系列国家部委的相关政策与指南的发布和技术标准的制定,对汽车信息安全提出了越来越严格的要求和更高的标准。因此,汽车信息安全已经成为整个汽车行业乃至社会面临的新的严峻挑战。在汽车行业进入软件定义时代,以及汽车的电子电气架构从分布式向集中式演进中,汽车基础软件起着更为关键的作用。汽车基础软件是用于实现汽车系统软硬件解耦,与用户应用功能无关,但提供汽车系统服务的支撑集

    9、合,是一个开发汽车控制及应用功能的嵌入式软件平台。汽车基础软件的定义表明,它应具备以下特点:包括具备基本功能的操作系统(OS)、中间件、应用软件接口以及相应的开发工具链;支持软件和硬件分离;支持丰富的、分布式协同的应用软件生态体系、重复使用性和跨平台移植性。毋容置疑,作为汽车应用的基础支撑系统,汽车基础软件的信息安全对于保障整车系统的稳定安全运行起着重要的作用。尤其是在汽车信息安全已从边界防护向纵深主动防御发展的今天,汽车基础软件信息安全所起到的作用更是至为关键。汽车基础软件的信息安全除了需满足机密性、完整性、可用性等安全基本要素的要求,以及采用基础的底层安全技术,如算法技术、安全协议、安全机

    10、制等以外,还具有以下特点:1.在软件定义汽车、数据驱动下,汽车基础软件作为创新的重要组成部分,适应新一代 EE 架构与车路协同应用的要求,支持异构多核高算力与冗余的多样化硬件平台、支持多网络协议、支持 SOA,满足高实时、多级功能安全与信息安全的特点,并需支撑车辆级、车路一体系统级的纵深主动防御式的安全防护和监控架构的需求;2.汽车基础软件信息安全需满足基础软件可剪裁、可配置、实时性等特点的需求,并结合基础软件采用相适应的机制和策略;前 言3.智能网联汽车的信息安全(包括网络安全与数据安全)与功能安全之间存在相关性,并与应用场景密切相关,而这一特点也将反应在汽车基础软件信息安全中。这份研究报告

    11、分为三个部分:第一部分 研究背景,包括汽车基础软件信息安全概述和国内外政策、法规与标准现状两个章节。在这一部分中我们将在对该研究的背景、范围、目的,以及研究意义与作用,该技术领域的发展历程与现状做个介绍,并对国内国外相关的政策、法规、标准,以及内汽车基础软件信息安全的这些特性使得它所涉及的技术面非常广,需要不同领域的专家来共同研究与探讨。为此,在中国汽车工业协会的指导下,我们组织了一个由21家企业与院校组成的编委会,和一个由方滨兴院士领衔的专家指导委员会,并通过大家广泛的讨论确定了这份研究报告的大纲,希望能够借此机会把各家最新的研究成果和最佳实践提炼、总结、分享出来,共同推动汽车基础软件信息安

    12、全的技术研发、标准建立、应用落地及产业化发展。外标准法规的差异性进行汇总和分析。在指导委员会专家们的指导下,经过 21 个单位和近百位专家的共同努力,这部研究报告终于完成并得以发布,希望它能够对在这一领域进行研究的专家们和实际应用的工程师们提供有价值的参考。在此,也衷心地感谢所有参加研究报告编辑和评审的专家和对这第三部分 应对未来,包括基础软件信息安全的发展挑战,汽车基础软件安全标准化建议,汽车基础软件信息安全典型案例三个章节。汽车基础软件信息安全是一个全新的并且不断发展的研究与应用实践的领域。我们努力探讨正在和将面临的挑战,及其应对的策略和研究方向,并对相应的标准化建设提出几点建议。这一部分

    13、以几个编辑单位贡献的典型第二部分 重点技术,包括汽车基础软件安全关键技术和汽车基础软件信息安全与AUTOSAR 两个章节。我们将从信息安全基础概念开始,然后对汽车基础软件信息安全的需求,关键技术及其应用,数据安全合规,以及安全测评验证技术等展开讨论,并重点介绍复杂的车用操作系统的信息安全技术。AUTOSAR 作为汽车行业公认的基础软件框架,它已经将多个相关的信息安全模块集成到它的标准框架中,构建了一定的基础软件信息安全的基础。由于这部分研究的特殊性,我们用了一个章节进行详细的分析介绍。案例的介绍结尾,希望能在分享实践经验的同时,推动技术的创新与落地应用。份研究报告的发布做出贡献的同事们。由于本

    14、研究涉及的是一个新的技术发展领域,其技术的专业面又很广,而且许多行业的专家和在汽车基础软件信息安全领域已有较深入研究的单位还没有完全参与到这份报告的编辑中,所以这份研究报告也会出现某些遗漏和不尽完善的地方。我们欢迎国内外的专家学者和广大读者提出宝贵意见,并参与我们工作组后续的讨论和研究,贡献你们的智慧与研究成果,共同推动汽车信息安全技术领域的创新发展与产业化应用实践。今天,汽车信息安全已经从事件驱动步入了以法规标准驱动的新的发展阶段,我们既面临许多新的挑战,也迎来了巨大的发展机遇。希望这份研究报告的发布能够对构建汽车信息安全产业生态并促进其健康发展做出贡献。基础软件信息安全研究报告编辑委员会2

    15、022 年 9 月I第1章汽车基础软件信息安全概述1.1 研究背景 0011.1.1 安全车控操作系统 0021.1.2 智能驾驶操作系统 0031.1.3 车载操作系统 0041.2 研究范围 0041.3 研究意义 005第2章国内外政策、法规与标准现状 2.1 国际政策、法规的现状与趋势0062.1.1 信息安全法规 0062.1.2 数据安全法规 0072.1.3 发展趋势 0082.2 国际标准现状与趋势0092.2.1 生命周期要求 0092.2.2 软件平台规范 0092.2.3 软件代码级规范 0102.2.4 数据安全规范 0102.2.5 其他规范 0102.3 国内政策与

    16、法规现状与趋势0112.4 国内标准现状与趋势0142.4.1 标准体系规划情况 0142.4.2 汽标委(TC114)0162.4.3 信安标委(TC260)0182.4.4 CCSA 0202.4.5 其他标准化组织 0212.4.6 发展趋势 0232.5 国内外法规及标准差异分析023本章小结024目CONTENTS录II第3章汽车基础软件信息安全关键技术3.1 信息安全基础概念 0253.1.1 常见信息安全属性 0253.1.2 常见安全分析模型 0253.2 汽车基础软件信息安全生命周期 0323.2.1 概念开发阶段 0323.2.2 产品开发阶段 0333.2.3 后开发阶段

    17、(生产、运维、报废)0343.3 汽车基础软件信息安全需求 0353.3.1 安全启动 0353.3.2 安全通信 0353.3.3 安全诊断 0363.3.4 安全调试 0373.3.5 安全升级 0373.3.6 安全存储 0373.4 关键技术研究与应用分析 0373.4.1 综述 0373.4.2 外部安全通信 0383.4.3 内部安全通信 0393.4.4 应用软件安全防护 0413.4.5 系统安全防护 0433.4.6 安全可信启动 0473.4.7 身份鉴别 0493.4.8 访问控制 0513.4.9 安全监测 0543.4.10 系统日志管理 0573.4.11 虚拟化安

    18、全 0593.4.12 TEE 可信执行环境 0623.4.13 加密芯片应用 0653.5 车用操作系统的安全技术 0663.5.1 传统实时操作系统 0663.5.2 自适应操作系统 0663.6 汽车基础软件的数据安全合规 0673.6.1 数据采集安全 0673.6.2 数据传输安全 0683.6.3 数据存储 0683.6.4 数据处理安全 069III 第3.6.5 数据交换安全 0693.6.6 数据销毁安全 0693.7 汽车基础软件安全测试评价0703.7.1 测试评价的必要性 0703.7.2 测试评价对象 0703.7.3 测试评价范围 0703.7.4 测试评价依据 0

    19、713.7.5 测试评价方法 0724章汽车基础软件信息安全与 AUTOSAR4.1 AUTOSAR 信息安全框架和关键技术分析 0784.1.1 SecOC 0784.1.2 TLS 0804.1.3 IPsec 0814.1.4 Crypto Stack 0824.1.5 IAM 0844.1.6 KeyM 0864.1.7 IdsM 0874.2 AUTOSAR 信息安全趋势分析 0874.3 AUTOSAR 信息安全对策 088第5章汽车基础软件信息安全发展挑战5.1 未来的挑战 0895.2 汽车芯片和汽车基础软件信息安全 0905.3 汽车基础软件信息安全与功能安全 0915.3.

    20、1 汽车基础软件信息安全和功能安全的分析方法模型 0915.3.2 汽车基础软件信息安全加固机制与功能安全优化设计 0915.4 汽车基础软件信息安全产业化 092第6章汽车基础软件信息安全标准化建议6.1 标准化的总体思路、目标 0956.2 标准化建议 095IV第7章汽车基础软件信息安全典型案例7.1 操作系统内核-中兴通讯 0977.1.1 背景描述 0977.1.2 实现概要 0977.1.3 实现详细(入侵检测)0997.2 安全启动-云驰未来 0997.2.1 背景描述 0997.2.2 实现概要 0997.2.3 实现详细(签名与验签)1007.3 安全监测-中汽创智 1017

    21、.3.1 背景描述 1017.3.2 实现概要 1017.3.3 实现详细(HIDPS-USB 接口检测防御)1037.4 车辆入侵检测-为辰信安 1037.4.1 背景描述 1037.4.2 实现概要(日志监控系统)1037.4.3 实现详细(日志监控系统)1047.4.4 实现概要(网关监控系统)1047.4.5 实现详细(网关监控系统)1067.5 TEE 可信安全执行环境实现虚拟 HSM-豆荚科技 1067.5.1 背景描述 1067.5.2 实现概要 1067.5.3 实际应用 1097.6 域控制器芯片 HSM 国密算法安全固件-伊世智能 1097.6.1 背景描述 1097.6.

    22、2 实现概要 1097.6.3 实现详细(Host 端软件升级)1107.7 安全存储-芯驰半导体 1117.7.1 背景描述 1117.7.2 实现概要 1117.7.3 实现详细(安全存储接口)112第8章主要贡献单位中国汽车基础软件信息安全研究报告 1.0001第1章汽车基础软件信息安全概述1.1 研究背景为了更好的应对软件定义汽车发展需求,近年来汽车行业开始重点关注整车软件开发平台,以确保实现在不影响车辆安全的前提下,利用开放的车辆应用程序编程接口和软件工具包,完成汽车软件的快速迭代,从而缩短汽车软件开发和部署周期。基础软件是汽车行业进入软件定义时代的关键一环,也是整个产业链除芯片硬件

    23、之外,最基本的底层能力标签。它之所以能在汽车智能化中扮演越来越重要的角色,首先就是因为汽车智能化、网联化发展,整车电子电气架构从过去的分布式架构逐渐过渡到基于域控制器的架构,促使 ECU 功能区域集中化,使得车内控制系统趋于形成统一的软件架构标准及通用的硬件平台。汽车基础软件是用于实现汽车系统软硬件解耦,与用户应用功能无关,但是提供汽车系统服务的一系列支撑的软件集合,是一个开发汽车控制和应用功能的完整嵌入式平台软件,其中内核、虚拟化、中间件及功能软件共同组成了基础软件平台。基础软件平台与硬件共同构成了计算基础平台。计算基础平台与应用软件最终构成了计算平台。图1.1-1基础软件平台架构2019

    24、年中国软件评测中心和赛迪(浙江)汽车检测服务有限公司发布了车载智能计算基础平台参考架构 1.0,对自动驾驶操作系统的定义是基于异构分布硬件架构,包含系统软件和功能软件的整体基础框架软件。系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境。系统软件一般包含异构分布系统的多内核设计及优化、Hypervisor、POSIX/ARA(AUTOSAR Runtime forAdaptive Applica-tions)、分布式系统 DDS(数据分发服务)等。2021 年 7 月汽标委发布了 车控操作系统架构研究报告、车控操作系统总体技术要求研究报告、车载操作系统架构研究报告、车载操作系统总体技术要

    25、求研究报告等 4 份研究报告,对汽车基础软件进行了明确定义。002 车载芯片软件即为微控制器的驱动软件,包括 CAN 驱动,I/O 驱动,SPI 驱动,ADC 驱动等,对于高性能计算单元而言,芯片驱动包含芯片外设驱动、Bootloader、硬件抽象层等,芯片驱动的作用是实现芯片功能,并为车载操作系统提供应用平台。车用操作系统主要分为车控操作系统和车载操作系统,如下图所示。图1.1-2车用操作系统分类车控操作系统运行于车载智能计算基础平台异构硬件之上,支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合。车控操作系统中支撑驾驶自动化功能实现的复杂大规模嵌入式系统运行环境,分为安全车控操作系

    26、统和智能驾驶操作系统。安全车控操作系统主要是实时操作系统(RTOS),主要应用对象是 ECU。ECU 对安全车控操作系统最基本的要求是高实时性,系统需要在规定时间内完成资源分配、任务同步等指定动作。嵌入式实时操作系统具有高可靠性、实时性、交互性以及多路性的优势,系统响应速度极高,通常在毫秒或者微秒级别,满足了高实时性的要求。目前,主流的安全车控操作系统都兼容 OSEK/VDX 和Clas-sic AUTOSAR 这两类汽车电子软件标准。其中,Classic 平台基于 OSEK/VDX 标准,定义了安全车控操作系统的技术规范。车载操作系统主要面向信息娱乐和智能座舱,主要应用于车机中控系统,对于安

    27、全性和可靠性的要求处于中等水平,但由于它是一个车辆重要的信息与数据交互中心,因而对数据安全合规性的要求很高。该类操作系统发展迅速,依托于该类操作系统的生态也处于迅速发展时期。虚拟化(Hypervisor)是一种硬件虚拟化技术,管理并虚拟化硬件资源(如 CPU、内存和外围设备等),提供给运行在 Hypervisor 之上的多个内核系统。中间件是一套满足标准接口和协议的通用平台,它可以实现不同系统的软件互联,具有高度的移植性。1.1.1 安全车控操作系统安全车控操作系统主要面向经典车辆控制领域,如动力系统、底盘系统和车身系统等,该类操作系统对实时性和安全性要求极高,生态发展已趋于成熟。面向安全车控

    28、操作系统的车规级安全实时操作系统内核要求支持 MCU 等控制芯片,兼容国际主流的系统软件中间件如 Classic AUTOSAR 标准等,满足实时控制功能安全应用需求,应部分达到 ISO26262 ASIL-D 级安全认证。安全车控操作系统主要由实时操作系统(Real Time Operating System)、硬件抽象层、基础软件、运行时环境和实时域控功能服务组成。其主要应用对象为 ECU 设备。ECU 对安全车控操作系统最基本的中国汽车基础软件信息安全研究报告 1.0003要求是高实时性,系统需要在规定时间内完成资源分配、任务同步等指定动作。嵌入式实时操作系统具有高可靠性、实时性、交互性

    29、以及多路性的优势,系统响应时间极短,通常在毫秒或者微秒级别,满足了高实时性的要求。目前,主流的安全车控操作系统都兼容 OSEK/VDX 和 Classic AUTOSAR 这两类汽车电子软件标准。其中,Classic AUTOSAR 平台基于 OSEK/VDX 标准,定义了安全车控操作系统的技术规范。图1.1-3安全车控操作系统纵向架构1.1.2 智能驾驶操作系统智能驾驶操作系统主要面向智能驾驶领域,应用于智能驾驶控制器,该类操作系统对安全性和可靠性要求较高,同时对性能和运算能力的要求比较高。面向智能驾驶操作系统的系统软件以车规级操作系统内核,支持高算力计算异构芯片,以标准的 POSIX 接口

    30、为基础,兼容国际主流的系统软件中间件如Adaptive AUTOSAR 等,满足智能驾驶不同应用所需的功能安全和信息安全等要求。与安全车控操作系统相比,智能驾驶操作系统平台要求主要体现在如下方面:1.强大的计算能力,以满足图像识别和决策计算的要求;2.强大的数据吞吐能力,以满足多传感器数据的实时接入和处理;3.高度的灵活性、扩展性、可编程性,以满足多种算法模型的需要;4.需要快速学习和易用性,以满足 ADAS 和自动驾驶算法所需调试、调优、测试。根据当前异构分布硬件架构各单元所加载的内核系统安全等级有所不同,AI 单元内核系统支持 QM到 ASIL-B 安全等级,计算单元内核系统支持 QM 到

    31、 ASIL-D 安全等级。智能驾驶操作系统发展趋势和特点是纵向分层,以实现层与层之间的解耦,方便快速开发和移植。图1.1-4智能驾驶操作系统纵向架构中国汽车基础软件信息安全研究报告 1.00041.1.3 车载操作系统车载操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台,是汽车实现座舱智能化与多源信息融合的运行环境。车载操作系统应用于车机中控、仪表、T-BOX 等系统,提供导航、多媒体娱乐、语音、辅助驾驶、AI 以及网联等功能,对于安全性和可靠性的要求处于中等水平,但对数据安全合规性有特殊的要求。车载操作系统由系统软件和功能软件两部分构成。图1.1-5车载操作系统纵向架构1.2 研究

    32、范围在软件定义汽车的背景下,汽车基础软件的信息安全日趋重要。传统的汽车应用比较封闭,功能较单一,且分布式的架构使得系统相对安全。随着系统的复杂度和开放程度越来越高,架构越来越集中化,以及服务越来越网联化,使得整个系统功能越来越丰富的同时,也为外部入侵提供了途径。信息安全和功能安全的重要性也开始逐渐凸显,网联网关的安全防护和主动检测,应用模块隔离和系统的访问控制,功能备份和异常恢复等各种防护手段,都逐步汇成车载系统重要的安全屏障。1.汽车基础软件的重要性及复杂性带来的信息安全风险基础软件用于实现汽车系统软硬件解耦,为后续汽车系统服务提供可复用、稳定的软件支撑,其架构与性能直接影响上层应用的开发效

    33、率和质量,帮助实现上层软件的创新发展。在汽车中,基础软件起到可维护、可升级、可扩展的作用,提高整车开发的效率,为上层多元的应用软件开发提供通用化平台,成基础软件作为汽车应用的支撑系统,位于应用程序和硬件抽象层之间,需要确保其自身的安全性并为应用提供安全服务或安全支撑能力,其重要性不言而喻。传统汽车基础软件信息安全是指通过对汽车基础软件的合理保护,保证车辆的运行和控制的合法、可靠,同时也保证用户个人数据的安全,避免被非法获取。本研究报告从以下几个方面来进行阐述分析:为“软件定义汽车”中不可或缺的关键基础技术。对于汽车基础软件在给行业发展带来便捷性的同时,因为其高复杂度、高要求、高统一化对于汽车信

    34、息安全也带来了更高的挑战。例如,汽车通信协议栈是汽车基础软件平台的重要组成部分,传统的基于CAN 总线的信号传输已经无法满足需求,而各类新型总线传输协议标准,如时间敏感性网络(TSN)等,还在不断完善,而上层应用协议生态还没有成熟,各企业在 SOME/IP、DDS、PCIE 的协议应用仍处于论证阶段,这些不确定性都给基础软件平台的发展带来挑战。在诸多通信协议中怎样在既保证通信的可靠性、保密性的同时,又保证通信的实时性要求,对于信息安全来说带来了更高的挑战。对于智能驾驶和网联功能的应用,硬件采用高性能计算单元是未来趋势,而基于高性能计算单元的005软件开发需要搭载复杂操作系统,例如:Linux、

    35、QNX、VxWorks 等。基础软件平台需要为上层应用开发提供统一接口,多种操作系统的共生需要开发 Hypervisor。为了满足这类需求,基础软件平台中的车载操作系统、Hypervisor 和中间件需要进行无缝集成,并且兼容不同应用开发。这些技术在车上的应用给智能网联汽车信息安全风险带来更多的挑战,如系统潜在漏洞的威胁、车辆隐私数据保护的威胁、车辆更新程序的威胁、外部连接的威胁、代码问题的威胁等等。2.汽车信息安全的政策、法规和标准汽车信息安全作为一个汽车行业的新兴技术领域,其技术标准目前仍尚处于规划阶段与建设。当前国内在该相关领域的标准组织包括全国信息安全标准化技术委员会(简称信安标委,T

    36、C260)、全国汽车标准化技术委员会(简称汽标委,TC114)和中国汽车工程学会(CSAE)等。国内外各个组织对网络安全和数据安全制定了各种标准规范。研究报告需要针对各个国家和地区的各个标准规范进行相关解读,并作为参考去指引信息安全的实施落地,并最终反哺相关标准的进一步研究和制定。4.汽车基础软件信息安全挑战针对汽车基础软件信息安全这个新兴领域,未来整个行业面临各种可能存在的挑战,例如因汽车芯片国产化而带来的产业链协同问题;汽车信息安全和功能安全的方法论统一、生命周期管理等;汽车基础软件信息安全上下游产业协同等各种问题。这些尚未有明确解决方案的问题的识别,有助于推动未来汽3.针对信息安全风险和

    37、现状,如何利用安全技术高效地解决主要问题面对这些问题行业正在积极开发,推动各种信息安全技术降低汽车基础软件安全风险。通过安全芯片中内置的加密算法、访问控制管理、信息完整性校验,得以提升智能汽车的安全级别;利用加密和认证技术为车辆提供数字证书用于身份认证、证书加密通道;数据签名验签等;利用检测与防御信息安全攻击的入侵检测与防御技术在一定范围内识别黑客攻击,第一时间上报主机厂及车主,并做出抵御措施,实现对车辆信息安全的实时性监测与防护。该类技术已经逐渐在各主机厂开展应用,详细技术报告将在第三章节中进行具体阐述。车基础软件信息安全不断向前发展。1.3 研究意义汽车基础软件是汽车软件核心与重要基础,不

    38、同于传统的主动安全和被动安全,基础软件信息安全问题一旦爆发带来的影响巨大,不仅会损害驾乘人员的人身安全和财产安全,给企业终端产品及业务带来巨大损失,甚至会影响到国家安全和社会稳定。因此,有必要对汽车基础软件信息安全开展深入研究,并以此推动汽车信息安全技术的创新和产业与生态的持续健康发展。该研究报告重点包括以下几个方面:1.现有国际、国内法规、政策与标准的分析;2.现阶段该领域研究成果的梳理和总结(包括落地实践的探索);3.未来的挑战与发展方向的展望;4.相关标准建设的建议。006第2章国内外政策、法规与标准现状2.1 国际政策、法规的现状与趋势鉴于对交通安全、社会安全甚至国家安全的重要影响,汽

    39、车网络安全、数据安全得到各相关国家和地区的高度重视,纷纷出台相关法规、标准。2.1.1 信息安全法规2020 年 6 月,联合国世界车辆法规协调论坛(简称为 UN/WP.29)发布了 3 项关于智能网联汽车的重要法规 R155/R156/R157,即信息安全(Cybersecurity)/软件升级(Software updates)/自动车道保持系统(ALKS),其中有关汽车网络安全、软件升级的 2 项法规 R155、R156,均涉及到对汽车基础软件的相关内容,包括防止非特权用户 root 用户访问权限、软件更新、代码安全、密码安全、软件错误或漏洞等。法规明确要求了整车企业内部开发体系需满足网

    40、络安全管理体系的要求,以及获得认证的要求。在此基础上,车型开发需满足网络安全管理体系的要求,包括开发、测试、运维、报废全生命周期的管理。R155 法规适用范围覆盖了乘用车及商用车,适用于 M 类、N 类车型,装备了至少一个 ECU 的 O 类车型,以及具备 L3 及以上自动驾驶功能的 L6 和 L7 类车型。此法规适合于 1958 协议国(包括欧洲、日本、俄罗斯、澳大利亚等)。根据欧盟要求,从2022年7月起所有新车型必须满足该法规,获取了WVTA(Whole Vehicle Type Approval)证书才能在欧盟上市销售。2024 年 7 月起制造的车辆必须满足该法规要求方可出厂销售。R

    41、155 法规框架如下图所示:图2.1-1 R155法规框架007VDA 黄皮书定义了评估 OEM 是否满足 CSMS 合规要求的方法以及评级方案,以及达到 CSMS 最低要求的必要措施。CSMS 认证审查车辆制造商是否在车辆完整生命周期的各个阶段均制订了网络安全管理流程,以确保汽车全生命周期中都有对应的流程措施,保证信息安全设计、实施以及响应均有流程体系指导。R155 法规中“7.2 网络安全管理体系要求”具体阐述了 OEM 应该满足的 CSMS 认证的内容要求。7.2.2 明确规定 OEM 需要提供证据证明在车辆整个生命周期中各个阶段都制订了网络安全管理体系要求,同时充分考虑了安全性以及风险

    42、和减缓措施。CSMS 要求 OEM 对网络攻击、威胁以及漏洞进行持续监测,并对发现的网络威胁和漏洞要在合理时间范围内响应并得到缓解。此外还要求 OEM 证明对供应商、服务提供商、子公司的管理均符合 7.2.2 要求,以保证车辆网络安全开发的一致性。VTA 认证则是进一步针对在车型开发过程中具体工作进行网络安全审查,保证在进行审查认证时车辆的网络安全技术已足够完备。关于 VTA 认证的要求内容在 R155 法规中“7.3 车辆型式需求”具体阐述。首先第一条就是 OEM 须持有与认证车型相关的 CSMS 证书。此外还提出了 OEM 在车型开发过程中需进行车型要素识别,做到详尽的风险评估,管理并实施

    43、对应缓解措施来应对评估出的风险。同时在车辆认证之前,OEM 应对这些安全措施进行验证来确保其有效性。此外,NHTSA(美国高速公路交通安全管理局)于 2020 年发布了更新版的Cybersecurity Best Practices for the Safety of Modern Vehicles,对于密码、诊断、车辆内部通信安全、事件日志、网络端口/协议/服务、外部通信、路由变更、软件更新等方面内容;ENISA(欧盟网络安全局)于 2019 年底发布的ENISA GOOD PRACTICES FOR SECURITY OF SMART CARS对于安全检测、网络和协议保护、软件信息安全、云

    44、端信息安全、密码技术、访问控制等提出了要求。用于改进和评估汽车机械系统开发过程的标准 ASPICE(Automotive SPICE)目前广泛应用于汽车领域,它是一个适用于传统和敏捷开发的框架,支持产品工程,与功能安全和信息安全息息相关。Automotive SPICE 第 3.x 版定义了“插件概念”,对于电子电气部分的开发过程越来越受关注。ASPICE 定义了系统级别、领域子系统级别、组件级别以及单元级别的开发活动,明确了整车企业及供应商在各阶段开发活动中的职责,提出了包含过程维度与能力维度的过程能力评估模型。汽车基础软件的开发也需要满足 ASPICE 中提出的相关要求,包括信息安全方面的

    45、需求、设计、测试与验证等环节的要求。2.1.2 数据安全法规随着智能网联汽车产业竞争加剧,各国均希望在数据安全规则层面占领制高点,全球范围数据安全领域进入立法高峰期,汽车数据安全相关法规明显增多。2016 年德国发布了使用联网和非联网车辆时的数据保护,要求“在车辆使用过程中产生的数据,如果与车辆识别号码或车牌有联系,就可以被视为德国联邦数据保护法意义上的个人数据”,提高了车辆使用过程中产生数据的保护等级。2017 年英国智能网联汽车网络安全关键原则提出了保障数据存储和传输安全可控等在内的八大原则、二十九项细则,将网络数据安全责任拓展到车联网产业链的每个主体,并强调应在汽车生命全周期内纳入网络数

    46、据安全问题。2017 年,美国出台了汽车安全与隐私法案,对车联网相关数据的收集和产生提出了两大原则:透明和消费者所有,即要求厂商在数据采集的范围和内容上必须透明,告诉消费者采集了哪些数据;在数据的使用上必须得到消费者的许可。2020 年 1 月美国自动驾驶汽车准则 4.0确立了自动驾驶十大原则,强调了安全和网络安全,特别是确保隐私和数据安全。2016 年 4 月,欧盟议会批准发布 GDPR 通用数据保护条例,是一项对欧洲自然人数据的管理和安008全问题进行规范的欧盟新法规,用于取代 1995 年发布的数据保护指令(DPD)。GDPR 于 2018 年 5 月25 日正式生效,包含 11 章共

    47、99 条要求。条例对个人数据、个人敏感数据等进行了定义,违反 GDPR 的行为,可处 2000 万欧元行政罚款或集团全球前一年营业额 4%(最高)。(根据 TUV SUD 的相关统计,至 2020 年 10 月,在欧洲各国的执法机构已处罚 48 例,约 51,800,000 欧元。)目前,GDPR 监管和执行的逻辑日益清晰,以风险为导向的数据合规管控方式日益深化。2016 年 11 月,欧盟发布了欧盟网联汽车战略,表明了个人数据和隐私保护对于自动驾驶汽车能否成功落地应用起着决定性作用。在该战略中,欧盟认为所有车联网产生数据都是用户个人数据,因此欧盟区域内车联网产生的数据同样属于消费者。欧盟数据

    48、保护委员会(EDPB)发布了车联网个人数据保护指南。2021 年 3 月欧洲车联网个人数据保护指南 2.0指出“联网车辆下任何涉及处理个人数据的数据处理情形均适用 GDPR”,在 GDPR 规范的个人数据保护框架下进一步细化了汽车数据治理规则。2.1.3 发展趋势UN/WP.29 提出的 R155 法规是全球第一个汽车信息安全的强制法规,法规对符合信息安全和数据安全做出来具体的合规性要求,车辆在特定国家范围内想要批准上市销售的前提条件是获得两个部分的合规认证:一是网络安全管理体系认证 CSMS,二是车辆网络安全型式认证 VTA。WP29 R155 系列法规适用于 1958 协议下成员国,虽然还

    49、有很多国家未加入到 1958 协议国中,但是生产的汽车只要销售到这些国家中就必须通过相关认证。R155 法规的时间规划为:1.2022 年 7 月起适用于新车型;2024 年 7 月起适用于所有车型;2.2022 年-2024 年两年内的现有架构新车型上市,若无法按照 CSMS 开发,则 VTA 必须证明在开发阶段已充分考虑网络安全;3.2025 年 1 月过渡期结束,要求所有架构所有车型通过认证(CSMS+VTA)。图2.1-2 R155法规时间规划在数据安全方面,各个国家、地区有关的法规、标准各不相同,如欧盟是 GDPR 和数据法案,中国是个人信息保护法和数据安全法,其他国家也有相应的隐私

    50、法案。一个相同的发展趋势是,各国家、地区都在加快数据安全相关标准、法规的制定和落地实施,对数据安全的重视已经被提升到了与网络信息安全同等的高度。0092.2 国际标准现状与趋势在汽车电子系统发展的早期,汽车电子基础软件是没有统一标准的,各个 OEM、Tier1、Tier2 等厂商针对不同领域的不同型号 ECU 开发不同的软件,开发工作量大、成本高。一些问题逐渐显露出来,如由于实时操作系统的应用程序接口不同而导致的应用程序移植性差等。随着汽车电子技术的不断发展,1993 年德国汽车工业界提出了 OSEK 汽车电子开放式系统及其接口的体系,这是汽车电子基础软件最初的行业标准,解决了应用软件移植和重

    51、用的问题。但随着汽车智能网联化的飞速发展,传统的汽车电子架构已经不能满足整车的业务需要,汽车电子架构正朝着由封闭到开放、由分布式到集中式,软件定义汽车、面向服务的软件架构的出现,都对汽车电子基础软件的发展提出了新的挑战。同时,汽车智能网联化伴随来的还有信息安全问题,不论是驱动、OS 或是中间件,一旦遭受到信息安全攻击,将不能安全稳定地为汽车服务提供支撑,那么汽车会处于未知的风险中,不但影响驾驶体验,甚至可能威胁生命。因此,一些基础软件相关信息安全标准应运而生。2.2.1 生命周期要求2016 年,美国汽车工程师学会(SAE)发布了 SAE J3061(Cybersecurity Guidebo

    52、ok for Cy-ber-Physical Vehicle Systems),其提供了车辆网络安全的流程框架和指导,考虑了车辆的整个生命周期,从概念到生产、运行、维护和报废。旨在帮助企业识别和评估网络安全威胁,导入网络安全到车辆的整个开发流程内。2021 年 8 月,国际标准化组织(ISO)和 SAE 联合起草发布了 ISO/SAE 21434 道路车辆信息安全工程(Road vehicles-Cybersecurity engineering),ISO 21434 是基于 SAE J3061 制定的,针对车辆整个生命周期的标准。其主要从风险评估管理、产品开发、运行维护、流程审核等四个方面来

    53、保障汽车信息安全工程工作的开展。目的是通过该标准设计、生产、测试的产品具备一定信息安全防护能力。从组织/企业级、项目级、分布式开发、持续网络安全管理、概念阶段、产品开发阶段、后开发阶段等明确了关于流程要求、人员职责分配要求等。提供了威胁分析与风险评估(TARA)统一的方法论,便于在产品开发过程中进行漏洞的分析、定级以及安全目标的制定。该标准对汽车软件开发的信息安全过程提出了要求,相关要求适用于汽车基础软件。2.2.2 软件平台规范2003 年 7 月,AUTOSAR(AUTomotive Open System ARchitecture)组织建立,旨在为汽车电气/电子构架开发一套开放的行业标准

    54、。AUTOSAR 核心成员主要由宝马、博世、大陆、戴姆勒、福特、通用、标致、丰田、大众这 9 家世界顶级主机厂和供应商组成,目前在全球范围内已发展成为包含 220+家合作伙伴,覆盖整车 OEM 厂商、零部件供应商、软件供应商、芯片和硬件供应商、测评服务等汽车产业链相关企业和机构的国际化组织。AUTOSAR 平台是目前国际上广泛认可的汽车电子系统基础软件平台(包括汽车操作系统),在发布4.2.2 版本后,AUTOSAR 的标准体系分为基础标准(Foundation)、经典平台(classic platform)、自适应平台(adaptive platform)和符合性测试(Acceptance

    55、Tests)等 4 个部分。在 AUTOSAR 经典平台中,以硬件安全模块(HSM,Hardware Security Module)为基础,提供了密码服务方面的层次架构,使得AUTOSAR 经典平台的服务分为四个方面:系统、存储、密码和通信。基于密码服务,AUTOSAR 经典平台提供了安全通信组件 SecOC(Secure Onboard Communication),为车内网络 ECU 之间的通信提供了真实性、完整性方面的保护能力。此外,为了保证对信息安全持续监控的实现,AUTOSAR 从基础软件角度提供了 IDS(Intrusion Detection System,入侵检测系统)。01

    56、0在目前常见的 4.4.0 版本中针对信息安全做出了以下改进:安全事件内存(Security Event Memory)密钥管理/密钥分发(Key Management/Key Distribution)认证同步的时间(Authentic Synchronized Time)针对诊断访问的动态权限管理(Dynamic Rights Management for Diagnostic Access)改进的证书处理(Improved Certificate Handling)另外,针对 V2X 的通信安全,AUTOSAR 标准也提出了一系列的信息安全要求,包括消息签名的加密验证、端到端安全、证书管

    57、理、应用程序安全相关机制等。2.2.3 软件代码级规范嵌入式系统常用的 C 语言是一种“不安全”的语言,例如 C 语言的指针很容易导致堆栈溢出、内存泄漏等各种问题。规范代码的格式是有效解决办法之一,即不要使用比较容易出错的代码格式。1998 年,汽车产业软件可靠性协会(MISRA)针对 C 语言易出错的特性,提出了 C 语言的编码规范 MISRAC;旨在提高关键应用程序中 C 代码的可靠性,重点是避免容易出错的功能,而不是强制执行特定的编程风格。MISRAC 最初就应用于汽车行业,后经过两次修订。当前版本是 MISRA C:2012,在此版本的 Amendment 1 中,提供了针对信息安全的

    58、代码规范。随着汽车为了提供更多更强大的功能,车载嵌入式软件和物联网设备越来越多,更多的代码连接到Internet。研究表明,汽车上已包含超过 1 亿行代码,对于如此大型,复杂的系统,我们必须开始认真对待软件安全性。嵌入式软件中的安全漏洞增加了恶意行为者攻击的机会,这些攻击会注入恶意软件、窃取信息或执行其他未经授权的任务。2008 年 10 月,美国软件工程学院(SEI)提出了 CERT C 编程语言安全编码规范,其目的是通过避免对安全性问题更敏感的编码结构来开发符合功能安全、信息安全的可靠的系统。它更加关注安全的编码实践,而不仅仅是症状(例如,始终验证输入是一种安全的编码实践,而 SQL 注入

    59、是一种症状)。CERT 分析了哪些准则最为关键,可以对其进行认真分析,然后分为应遵循的“规则”和不太重要或缺乏声音分析能力的“建议”。这有助于快速将静态分析结果调整到最关键的水平。安全编码实践更大程度地消除了这些漏洞,减少了“恶意软件”、“窃取信息”或“执行其它未经授权的任务”等攻击行为的攻击面,减小了恶意行为者攻击的机会。CERT 提供了较为全面的安全措施,如敏感信息的保护、注入或劫持的预防等等是值得所有开发人员学习的。但 CERT 更专注于安全问题,适合与其他规范配合使用。2.2.4 数据安全规范AutoMat Common Vehicle Information Model:欧盟于 20

    60、18 年 3 月发布了其 AutoMat 项目所研究的通用车辆信息模型(CVIM:Common Vehicle Information Model),即开放和品牌独立的车辆大数据模型。针对大量持续收集的汽车数据,AutoMat 项目的核心意图是利用目前从联网汽车收集的未使用信息,为汽车大数据创新一个开放的生态系统,以跨境汽车大数据市场的形式实现。与市场的接口来自一个通用车辆信息模型(CVIM),该模型使跨行业服务提供商可以访问来自各个 OEM 厂商挖掘的匿名车辆数据。随着来自汽车的大量易失性数据,AutoMat 生态系统极大地建立在当前大数据趋势的基础上。该规范提供了模型的架构、概念和方法、信

    61、号层规范、测量层规范、数据层规范。2.2.5 其他规范NIST SP800 是美国国家标准与技术研究院 NIST(National Institute of Standards and Technolo-011gy)发布的一系列关于信息安全的指南,已成为美国和国际安全界广泛认可的事实标准和权威指南。例如,NIST SP 800-131A 定义了有效的密码算法,以及需要的密码算法参数值以能够在特定的时间段内实现特定的安全强度。2002 年 12 月,NIST 发 布 了 FIPS Publication 140-2(Federal Information Processing Stand-ard

    62、s 140),该标准是针对密码模块的安全需求,为密码模块评测、验证和最终认证提供基础,作为联邦信息处理标准在政府机构广泛采用。2.3 国内政策与法规现状与趋势我国已将发展智能网联汽车上升到国家战略高度,国家各部委根据在车联网关键部件和生命周期各环节的职责划分,制定相关政策及执行监管,包括网信办、工信部、交通运输部、公安部、国标委等,共同推动建立健全智能网联汽车信息安全管理机制。国家设计智能网联汽车顶层产业发展政策方针过程中将信息安全纳入考虑,进行了不同程度的规划和要求。有关智能网联汽车网络安全与数据安全的主要法规如下表所示。表2.3-1 智能网联汽车网络安全、数据安全主要法律法规和指导意见序号

    63、文件名称发布机构发布时间1中华人民共和国网络安全法全国人大常委2016 年 11 月2车联网(智能网联汽车)产业发展行动计划工信部2018 年 12 月3关于促进道路交通自动驾驶发展的指导意见(征求意见稿)交通部2019 年 5 月4新能源汽车产业发展规划 2021-2035工信部2019 年 12 月5智能汽车创新发展战略发改委等 11 部委2020 年 2 月6节能与新能源汽车技术路线图 2.0中汽学会2020 年 10 月7关于进一步加强汽车远程升级(OTA)技术召回监管的通知市场监管总局2020 年 11 月8关于促进道路交通自动驾驶技术发展和应用的指导意见交通运输部2020 年 12

    64、 月9道路交通安全法全国人大常委2021 年 4 月10智能网联汽车生产企业及产品准入管理指南(试行)(征求意见稿)工信部2021 年 4 月11关于加强车联网(智能网联汽车)网络安全工作的通知(征求意见稿)工信部2021 年 6 月12中华人民共和国数据安全法全国人大常委2021 年 6 月012序号文件名称发布机构发布时间13关于汽车远程升级(OTA)技术召回备案的补充通知市场监管总局2021 年 6 月14车联网(智能网联汽车)网络安全标准体系建设指南(征求意见稿)工信部2021 年 6 月15智能网联汽车道路测试与示范应用管理规范(试行)工信部2021 年 7 月16关于加强智能网联汽

    65、车生产企业及产品准入管理的意见工信部2021 年 8 月17汽车数据安全管理若干规定(试行)国家网信办、发改委、工信部、公安部和交通部联合发布2021 年 10 月18中华人民共和国个人信息保护法全国人大常委2021 年 8 月19关于加强汽车网络安全和数据安全工作的通知工信部2021 年 9 月20关于加强车联网卡实名登记管理的通知工信部2021 年 9 月21数据出境安全评估办法国家网信办2022 年 7 月中华人民共和国网络安全法:网络安全法是我国网络安全领域的基本大法,是指导我国各行业、各领域网络安全工作的纲领性文件和基本要求,也是我国汽车信息安全标准体系建设需要遵从的根本性文件。网络

    66、安全法明确了网络安全事故的责任主体,在汽车信息安全方面对整车制造商、车载信息系统提供商及网络服务运营商提出了法律层面的要求,使得汽车行业在汽车信息安全功能产品的生产和运营上实现了“有法可依”。车联网(智能网联汽车)产业发展行动计划:以强化管理、保障安全为原则,重点明确主体责任,健全管理制度,强化防护机制,构建确保人身安全的管理体系。提出推进车联网无线通信安全、车联网平台及应用安全、数据安全和用户个人信息保护的相关标准研究制定;以产品和系统的运行安全、网络安全和数据安全为重点,明确相关主体责任,定期开展安全监督检查。完善车联网网络和数据安全的事件通报、应急处置和责任认定等安全管理工作;重点突破产

    67、业的功能安全、网络安全和数据安全的核心技术研发,支持安全防护、漏洞挖掘、入侵检测和态势感知等系列安全产品研发。督促企业强化网络安全防护和数据安全防护,构建智能网联汽车、无线通信网络、车联网数据和网络的全要素安全检测评估体系,开展安全能力评估。新能源汽车产业发展规划(2021-2035 年):新能源汽车与信息通信融合发展,打造网络安全保障体系,加快完善适应智能网联汽车发展要求的道路交通、事故责任、数据使用等政策法规。提出打造网络安全保障体系,健全新能源汽车网络安全管理制度,构建统一的汽车身份认证和安全信任体系。推动密码技术深入应用,加强车载信息系统、服务平台及关键电子零部件安全检测,强化新能源汽

    68、车数据分级分类和合规应用管理,完善风险评估、预警监测、应急响应机制,保障“车端传输管网云端”各环节013信息安全。智能汽车创新发展战略:提出将网络安全作为六大主要任务之一,特别提出要“构建全面高效的智能汽车网络安全体系”,主要包括完善网络安全管理联动机制、提升网络安全防护能力、加强数据安全监督管理等方面。在加强网络安全系统防护能力方面,提出了对于车载信息系统、服务平台以及关键电子零部件的安全要求。中华人民共和国数据安全法:要求针对数据的收集、存储、使用、加工、传输、提供、公开等各种数据处理行为,应通过采取必要措施,确保数据处于有效保护和合法利用的状态,以及具备保障持续安全状态的能力。相关组织应

    69、建立健全数据安全治理体系,提高数据安全保障能力。要求相关行业组织按照章程,依法制定数据安全行为规范和团体标准。该法律还具体针对数据安全与发展、数据安全制度、数据安全保护义务、相关法律责任等进行了规定。中华人民共和国个人信息保护法:作为中国首部针对个人信息保护的专门性立法,进一步强化个人信息安全监管与治理,在有关法律基础上,进一步细化、完善个人信息保护应遵循的原则和个人信息处理规则。明确了个人信息和敏感个人信息的处理规则,完善个人信息保护投诉、举报工作机制。强调处理个人信息应遵循合法、正当、必要和诚信原则,具有明确、合理的目的并与处理目的直接相关,采取对个人权益影响最小的方式,限于实现处理目的的

    70、最小范围,公开处理规则,保证信息质量,采取安全保护措施等。关于进一步加强汽车远程升级(OTA)技术召回监管的通知:规范了 OTA 技术在召回工作中的应用,明确要求生产者采用 OTA 方式消除汽车产品缺陷、实施召回的,须向市场监管总局备案。要求车企在使用 OTA 开展技术服务活动时,需向市场监管总局质量发展局备案;车企如果使用 OTA 消除车辆缺陷、实施召回的,也需要向市场监管总局质量发展局备案。工信部于 2021 年 4 月 7 日公开征求对智能网联汽车生产企业及产品准入管理指南(试行)(征求意见稿)的意见,并于 2021 年 8 月 12 日印发关于加强智能网联汽车生产企业及产品准入管理的意

    71、见。智能网联汽车生产企业及产品准入管理指南(试行)要求智能网联汽车生产企业应满足企业安全保障能力要求,针对车辆的软件升级、网络安全、数据安全等建立管理制度和保障机制,建立健全企业安全监测服务平台。智能网联汽车生产企业应建立覆盖车辆全生命周期的网络安全防护体系,采取必要的技术措施和其他必要措施,有效应对网络安全事件,保护车辆及其联网设施免受攻击、侵入、干扰和破坏;智能网联汽车生产企业应依法收集、使用和保护个人信息,实施数据分类分级管理,制定重要数据目录,不得泄露涉及国家安全的敏感信息等等。该指南给出了智能网联汽车生产企业安全保障能力要求、智能网联汽车产品准入过程保障要求、智能网联汽车产品准入测试

    72、要求。关于加强智能网联汽车生产企业及产品准入管理的意见明确要求了整个产业链的企业要保证汽车的数据安全、网络安全、软件升级、功能安全这些要求。汽车数据安全管理若干规定(试行):根据中华人民共和国网络安全法等法律法规规定,旨在加强个人信息和重要数据保护,规范汽车数据处理活动,维护国家安全和公共利益。规定将整个汽车行业全链条上几乎所有的经营者都纳入了适用范围,将汽车行业作为单独个体,通过定义和列举的方式,明确了汽车行业中的重要数据范围;明确汽车数据处理者处理个人信息和重要数据的原则:车内处理原则、默认不收集原则、精度范围适用原则、脱敏处理原则;明确个人信息与重要数据的境内存储要求以及跨境传输的相关要

    73、求;对汽车数据处理者提出报送数据安全年报制度的要求。加强数据安全管理的平台建设、建立投诉举报通道,扩大接受用户投诉举报的范围。014关于加强车联网网络安全和数据安全工作的通知:重点针对智能网联汽车生产企业和车联网服务平台运营企业,旨在加强车联网网络安全和数据安全管理工作,健全完善车联网安全保障体系。通知提出数据安全重点关注的四个方向,包括加强数据分类分级管理、提升数据安全技术保障能力、规范数据开发利用和共享使用、强化数据出境安全管理。数据出境安全评估办法:是为了规范数据出境活动,保护个人信息权益,维护国家安全和社会公共利益,促进数据跨境安全、自由流动而制定的;且是依据中华人民共和国网络安全法、

    74、中华人民共和国数据安全法、中华人民共和国个人信息保护法等法律法规起草的。总体来看,智能网联汽车信息安全会愈加重要,对信息安全做出要求的相关政策、法律法规可大致分为六个方面,分别为国家安全、网络安全、数据安全、个人信息安全、地理信息安全、产品责任与事故责任(准入、召回、OTA 软件升级等)。车联网信息安全政策法规制定可分为三个阶段,即启动规划(2017 年12 月-2020 年 2 月)、推动形成指导意见(2020 年 8 月-2021 年 8 月)和建立具体参考标准(预计于2023 年初步构建起车联网网络安全标准体系,完成 50 项以上重点继续安全标准的制修订,2025 年形成较为完备的车联网

    75、网络安全标准体系,完成 100 项以上重点标准),目前政策法规体系初具雏形。诸多法律法规已陆续开始施行,预计未来监管会更加严格。首先,陆续会有相配套的政策解读文件和标准出台,以支撑该法律法规的实施。其次,信息安全保障工作的进度和力度也会随之加快和提升。最后,信息安全检测评估、认证等工作也会快速展开,相关主管部门将推出针对信息安全检测评估和认证体系。另外,智能网联汽车成为数据的核心载体和纽带,面临多主体、多环节以及多应用场景的数据采集、存储、使用及管理问题和风险,数据合规要求也逐渐延伸至汽车企业和车联网服务运营企业。2.4 国内标准现状与趋势2.4.1 标准体系规划情况2017 年,工业和信息化

    76、部、国家标准化管理委员会联合发布国家车联网产业标准体系建设指南(智能网联汽车),对我国智能网联汽车标准体系做出了系统的规划和部署。提出针对智能网联汽车通用规范、核心技术与关键产品应用,有目的、有计划、有重点地指导车联网产业智能网联汽车标准化工作,将信息安全作为智能网联汽车标准体系建设的重要内容,加快构建包括整车及关键系统部件功能安全和信息安全在内的智能网联汽车标准体系。车联网(智能网联汽车)网络安全标准体系建设指南:从智能网联汽车、V2X 通信网络、车联网服务平台、车联网应用程序、数据保护等车联网关键环节和重点对象出发,面向车联网典型应用场景,建立车联网(智能网联汽车)网络安全标准体系。从车联

    77、网基本构成要素出发,针对车载联网设备、基础设施、网络通信、数据信息、平台应用、车联网服务等关键环节,提出覆盖终端与设施安全、网联通信安全、数据安全、应用服务安全、安全保障与支撑等方面的技术架构。2022 年 2 月 25 日,工业和信息化部办公厅印发车联网网络安全和数据安全标准体系建设指南,进行车联网网络安全和数据安全标准体系建设。体系包含总体与基础共性、终端与设施网络安全、网联通信安全、数据安全、应用服务安全和安全保障与支撑六大部分,全面搭建相关标准内容。预计于 2023 年初步构建起车联网网络安全标准体系,完成 50 项以上重点安全标准的制订、修订,2025 年形成较为完备的车联网网络安全

    78、标准体系,完成 100 项以上重点标准制定。015图2.4-1 车联网网络安全和数据安全标准体系框架在数据安全方面,我国近几年开始重视汽车数据安全问题,并积极开展汽车数据安全的法规标准制定工作,在个人信息保护法 网络安全法 数据安全法三大上位法的前提和基础下,我国已初步形成汽车领域数据安全制度框架。表 2.4-1 数据安全标准体系序号类别数据安全标准规划标准号/计划号状态1通用要求智能网联汽车数据通用要求20213606-T-339制定中2智能网联汽车数据安全共享模型与规范待制定3智能网联汽车数据安全共享参考架构T/TIAA020-2021已发布4智能网联汽车数据安全要求待制定5智能网联汽车数

    79、据保护密码应用技术要求待制定6车联网数据安全保护能力参考框架待制定016序号类别数据安全标准规划标准号/计划号状态7分类分级车联网信息服务数据安全技术要求YD/T3751-2020已发布8车联网服务平台重要数据记录系统技术规范待制定9数据出境安全车联网数据跨境流动安全管理要求待制定10车联网数据跨境流动安全评估规范待制定11个人信息保护车联网信息服务用户个人信息保护要求YD/T3746-2020已发布12基于移动互联网的汽车用户数据应用与保护技术要求2018-0182T-YD制定中13基于移动互联网的汽车用户数据应用与保护评估方法2018-0183T-YD制定中14车联网用户个人信息合规检测要

    80、求待制定15应用数据安全信息安全技术网络预约汽车服务数据安全指南20205164-T-469制定中16网络预约出租汽车服务平台数据安全防护要求2017-0938T-YD制定中17车联网信息服务数据安全保护能力评估规范2020-1317T-YD制定中18车联网应用服务数据脱敏实施方法待制定2.4.2 汽标委(TC114)近年来,全国汽标委智能网联汽车分标委(SAC/TC114/SC34)持续贯彻落实有关文件要求,依托先进驾驶辅助系统、自动驾驶、信息安全、网联功能与应用、资源管理与信息服务等专项标准研究工作组,目前已完成标准体系建设第一阶段目标,初步建立起能够支撑驾驶辅助及低级别自动驾驶的智能网联

    81、汽车标准体系,为智能网联汽车行业管理和促进产业高质量发展提供了坚实保障。截至 2022 年 6 月,智能网联汽车标准体系项目已累计完成发布和报批 39 项,完成标准立项及草案编制 26 项,提交申请立项标准 16 项。表 2.4-2 汽标委智能网联汽车网络安全、数据安全主要相关标准序号标准编号/名称标准类型当前状态1GB 39732-2020 汽车事件数据记录系统(UN R160)国家强制标准已发布2GB/T 40861-2021 汽车信息安全通用技术要求国家推荐标准已发布017序号标准编号/名称标准类型当前状态3GB/T 40857-2021 汽车网关信息安全技术要求及试验方法国家推荐标准已

    82、发布4GB/T 40855-2021 电动汽车远程服务与管理系统信息安全技术要求及试验方法国家推荐标准已发布5GB/T 40856-2021 车载信息交互系统信息安全技术要求及试验方法国家推荐标准已发布620192313-T-339 电动汽车充电系统信息安全技术要求国家推荐标准报批720211169-T-339 汽车诊断接口信息安全技术要求国家推荐标准已立项820213606-T-339 智能网联汽车 数据通用要求国家推荐标准已立项920213611-T-339 汽车信息安全应急响应管理指南国家推荐标准已立项1020214423-Q-339 汽车软件升级通用技术要求(UN R156)国家强制标

    83、准已立项1120214420-Q-339 智能网联汽车 自动驾驶数据记录系统国家强制标准已立项1220214422-Q-339 汽车整车信息安全技术要求(UN R155)国家强制标准已立项13道路车辆 信息安全工程(ISO 21434)国家推荐标准申请立项14智能网联汽车 车载操作系统技术要求及试验方法国家推荐标准申请立项15智能网联汽车 车控操作系统技术要求及试验方法国家推荐标准申请立项16汽车数字证书应用规范国家推荐标准申请立项17汽车密码应用技术要求国家推荐标准申请立项GB/T 40857-2021汽车网关信息安全技术要求及试验方法:从硬件、通信、固件、数据等四个角度明确了网关的信息安全

    84、要求。包括后门接口、调试接口、访问控制、拒绝服务攻击检测、数据帧健康检测、数据帧异常检测、UDS 会话检测、网络分域、安全启动、安全日志等。并针对以上安全要求,提出了018对应的检测方式。GB/T 40855-2021电动汽车远程服务与管理系统信息安全技术要求及试验方法:从车载终端、平台间通信安全、平台安全要求。其中车载终端包含对安全启动、软件系统、数据存储、端口传输、远程升级、终端日志的要求。平台间通信包含了通信协议栈以及安全通信协议的要求,此外法规还针对上述要求说明了相应的测试方法。GB/T 40856-2021车载信息交互系统信息安全技术要求及试验方法:从硬件安全要求、通信协议与接口安全

    85、要求、操作系统安全要求、应用软件安全要求和数据安全要求五个角度进行说明。其中对外通信安全包括安全连接、传输安全、终止响应安全、通信协议安全、内部通信安全等,此外还包括操作系统安全配置、安全功能调用、敏感功能控制等。数据安全从数据采集、存储、传输、销毁四个方面进行说明,此外法规还针对上述要求说明了相应的测试方法。2019 年 10 月,汽标委发布了车用操作系统标准体系,规范了车用操作系统定义,划分了车用操作系统边界,明确了车用操作系统分类,构建了车用操作系统标准体系。车用操作系统标准体系的发布,为操作系统标准化工作的开展指明了方向。汽标委(TC114)于 2020 年启动开展了一系列有关车用操作

    86、系统的标准研究项目,于 2021 年 7 月发布了车控操作系统架构研究报告、车控操作系统总体技术要求研究报告、车载操作系统架构研究报告、车载操作系统总体技术要求研究报告等 4份研究报告,其中对车控、车载操作系统的信息安全要求均提出了标准化要求。车控操作系统的信息安全要求主要包括可信执行环境、密码应用支撑、访问控制与身份鉴别、车内总线安全通信、安全外部通信、安全可信启动、系统安全、应用安全、数据安全、安全监控与防御、面向业务的安全支撑机制与功能等。鉴于车载操作系统内核功能的复杂性,要求车载操作系统应构建完整的信息安全防护机制,降低内核漏洞对系统安全的危险,强化内核的安全防护能力。系统应具备多域隔

    87、离、一致性检查、安全启动、安全存储、安全输入、加密文件系统等技术,应具备系统镜像完整性及合法性验证机制、系统镜像回退功能。汽标委目前已启动了智能网联汽车 车控操作系统技术要求、智能网联汽车 车载操作系统技术要求标准的研制工作,其中均包含信息安全方面的要求。2.4.3 信安标委(TC260)TC260 于 2020 年发布首个汽车电子系统网络安全推荐性标准 GB/T38628-2020信息安全技术 汽车电子系统网络安全指南,该标准主要针对汽车信息安全生命周期过程提出了要求,其中涉及到汽车软件开发中的框架性安全要求,适用于车控及车载系统的基础软件。另外,推荐性标准信息安全技术-车载网络设备信息安全

    88、技术要求处于送审稿阶段。在数据安全方面,信安标委目前已发布一系列相关标准,如下表所示。表2.4-3 信安标委相关数据安全标准序号标准编号标准名称1GB/T 352732020信息安全技术 个人信息安全规范2GB/T 379642019信息安全技术 个人信息去标识化指南3GB/T 379882019信息安全技术 数据安全能力成熟度模型4GB/T 393352020信息安全技术 个人信息安全影响评估指南019序号标准编号标准名称5GB/T 413912022信息安全技术 移动互联网应用程序(App)收集个人信息基本要求6GB/Z 288282012信息安全技术 公共及商用服务信息系统个人信息保护指

    89、南7-信息安全技术 重要数据识别指南8-汽车采集数据处理安全指南920205164-T-469信息安全技术 网络预约汽车服务数据安全指南其中汽车采集数据处理安全指南于 2021 年 10 月 8 日发布,为汽车制造商开展汽车的设计、生产、销售、使用、运维提供数据保护实施规范,同时也为主管监管部门、第三方评估机构等对汽车采集数据处理活动进行监督、管理和评估提供依据。指南 中将汽车采集数据的内容划分为车外数据、座舱数据、运行数据以及位置轨迹数据四类,并明确了各类数据的范围以及可能涉及的个人信息、敏感个人信息和重要数据。针对不同类别的汽车采集数据制定针对性的传输、存储、出境的相关要求,确保各类数据受

    90、到恰当的保护,使相关数据处理活动处于安全可控的状态。明确规定了传输要求、存储要求以及数据出境要求,要求中具体到数据内容以及例外情形,避免了一刀切的安排,为企业实施数据保护措施提供明确参照。至于汽车数据出境问题,指南中明确要求“车外数据、座舱数据、位置轨迹数据不应出境;运行数据如需出境,应当通过国家网信部门组织开展的数据出境安全评估”,由此认为三类数据原则上不应出境。在操作系统信息安全方面,信安标委现已发布多项相关标准,如下表所示。表2.4-4 信安标委发布的操作系统安全相关标准序号标准编号标准名称1GB/T 20008-2005信息安全技术 操作系统安全评估准则2GB/T20272-2019信

    91、息安全技术 操作系统安全技术要求3GB/T 30284-2020移动通信智能终端操作系统安全技术要求4GB/T 34976-2017信息安全技术 移动智能终端操作系统安全技术要求和测试评价方法5GB/T 36630.3-2018信息安全技术 信息技术产品安全可控评价指标 第 3 部分:操作系统6GB/T 394122020信息安全技术 代码安全审计规范GB/T20272-2019信息安全技术 操作系统安全技术要求:将对操作系统的安全技术要求分为 5个保护级,即用户自主保护级、系统审计保护级、安全标记保护级、结构化保护级和访问验证保护级,要求的内容也逐渐由弱到强,包括自主访问控制、强制访问控制、

    92、标记数据流控制、身份鉴别、用户数据保密性、安全审计、用户数据完整性、可信路径等。其主要针对的是传统(或通用)操作系统的,其中的技020术要求并不是都能适合汽车领域的情况。GB/T34976-2017信息安全技术 移动智能终端操作系统安全技术要求和测试评价方法的安全技术要求包括安全功能要求和安全保障要求两大部分,其中安全功能要求包括身份鉴别、访问控制、安全审计、用户数据安全、数据安全、存储介质管理、应用软件安全管理、用户策略管理、运行安全保护、升级能力、超时锁定或注销、运行监控、可靠时钟、可用性等,安全保障要求包括对开发、指导性文档、生命周期支持、测试、脆弱性评定等。总体来看,TC260 尚未专

    93、门针对汽车领域操作系统开展标准化工作。2.4.4 CCSA中国通信标准化协会(China Communications Standards Association,CCSA)TC8 的研究领域包括面向公众服务的互联网的网络与信息安全标准、电信网与互联网结合中的网络与信息安全标准、特殊通信领域中的网络与信息安全标准等。面向汽车领域已发布和正在制定一系列有关网络、信息安全和数据安全的标准。表2.4-5 CCSA已发布相关标准序号标准编号标准名称标准类型1YD/T 3750-2020车联网无线通信安全技术指南行业标准2YD/T 3737-2020基于公众电信网的联网汽车信息安全技术要求行业标准3YD

    94、/T 3594-2019基于 LTE 的车联网通信安全技术要求行业标准4YD/T 3751-2020车联网信息服务 数据安全技术要求行业标准5YD/T 3746-2020车联网信息服务 用户个人信息保护要求行业标准6YD/T 3752-2020车联网信息服务平台安全防护技术要求行业标准7T/CCSA 3392021车联网网络安全防护定级备案实施指南团体标准表2.4-6 CCSA正在制定中车联网安全相关标准序号标准名称标准类型状态1车联网网络安全防护定级备案实施要求行业标准提交立项2车联网服务平台网络安全防护要求行业标准提交立项3车联网信息服务平台安全防护检测要求行业标准2021-0192T-Y

    95、D征求意见4车联网在线升级(OTA)平台安全技术要求及检测方法国家标准提交立项021序号标准名称标准类型状态5车联网安全管理平台接口规范国家标准提交立项6车联网信息服务 数据安全保护能力评估规范行业标准2020-1317T-YD征求意见7网络预约出租汽车服务平台数据安全防护要求行业标准2017-0938T-YD已立项8车联网网络安全通用术语和定义行业标准提交立项9车联网网络安全总体架构行业标准提交立项10车云通信密码应用基本要求行业标准提交立项11基于 LTE 的车联网无线通信技术安全认证技术要求行业标准2019-0021T-YD已立项12基于 LTE 的车联网无线通信技术安全证书管理系统技术

    96、要求行业标准2020-CCSA-36已立项13基于 LTE 的车联网无线通信技术安全认证测试方法行业标准2019-0022T-YD已立项14基于 NR-V2X 的车联网无线通信安全技术要求行业标准提交立项15基于 PKI 的车联网应用服务安全认证体系框架行业标准提交立项16基于移动互联网的汽车用户数据应用与保护技术要求行业标准2018-0182T-YD提交立项17基于移动互联网的汽车用户数据应用与保护评估方法行业标准2018-0183T-YD提交立项2.4.5 其他标准化组织表2.4-7 其他标准化组织发布及正在研制的相关标准序号标准编号/名称标准类型标准化组织1T/TIAA 020-2021

    97、 智能网联汽车数据安全共享参考架构团体标准TIAA2T/TIAA 101-2021 T/CSAE 211-2021 智能网联汽车数据共享安全要求团体标准TIAA/CSAE3T/TIAA 015-2019 车联网网络安全防护要求团体标准TIAA022序号标准编号/名称标准类型标准化组织4T/TIAA 016-2019 智能网联汽车车载终端信息安全要求团体标准TIAA5T/CAAMTBxxxx 智能网联汽车数据安全评估指南团体标准中国汽车工业协会6T/CAAMTBxxxx 汽车传输视频及图像脱敏技术要求与方法团体标准中国汽车工业协会7自动驾驶系统功能测试第 9 部分:信息安全评价测试团体标准中国汽

    98、车工业协会8GB/T 37376-2019交通运输 数字证书格式国家推荐标准全国智能运输系统标委会 TC2689GB T 37374-2019智能交通数字证书应用接口规范国家推荐标准全国智能运输系统标委会 TC26810智能网联汽车车载端信息安全技术要求团体标准CSAE11智能网联汽车车载端信息安全测试规程团体标准CSAE12V2X 车载终端安全芯片处理性能测试规范团体标准CSAE13车控操作系统功能软件架构及接口要求团体标准CSAE14智能网联汽车 车控操作系统功能安全技术要求团体标准CSAE15智能网联汽车人机环系统交互安全技术要求及测试方法团体标准CSAE16汽车以太网交换机设备安全技术

    99、要求团体标准CSAE17智能汽车用数据分发服务(DDS)测试方法团体标准CSAE18GMT008-2012安全芯片密码检测准则行业标准国家密码管理总局19GM/T0002-2012SM4 分组密码算法行业标准国家密码管理总局20GM/T 0004-2012SM3 密码杂凑算法行业标准国家密码管理总局21GM/T0005-2012随机性检测规范行业标准国家密码管理总局0232.4.6 发展趋势智能网联汽车应用的高速发展,车用操作系统(包括车控操作系统和车载操作系统)作为智能网联汽车的基础软件和技术支撑,具体的功能模块和接口也会随着系统的不断演进而演进,需要通过技术要求和测试方法的标准化来适应快速

    100、变化的市场需求。其中信息安全是车用操作系统产品可靠安全运行的必要组成部分。对于车用操作系统的攻击,可能直接影响到智能网联汽车的功能安全和人身安全,也会涉及到个人隐私数据和重要数据的处理。对于车用操作系统的安全要求类的标准制定,可以依据国家网络安全法、数据安全法、个人信息保护法三大法为原则,设定操作系统安全基线,最大限度保护智能网联汽车的安全运行、数据的安全存储和处理。汽车电动化、智能化、网联化交融发展,车辆功能安全、网络安全和数据安全风险交织叠加,安全形势复杂严峻;随着数据逐步成为驱动汽车发展的重要价值点,汽车数据安全与消费者利益息息相关,对智能网联汽车从数据的全生命周期角度的安全要求逐步提高

    101、。车企或相关运营者从用户设备、车辆和能源产品等渠道搜集车辆用户多维度的数据信息,将其用于数字服务,并可能分享给服务提供商、业务合作伙伴、用户授权的地方及法律要求的其他第三方等。智能网联汽车企业及相关方,搜集用户数据量大、商业价值不菲,超乎普通用户的直观感受。另一个方面,随着汽车市场的竞争加剧,数据将成为车企在智能网联时代决胜的关键因素之一,而法规是汽车数据安全建设的核心驱动力。目前看来,中国智能网联汽车数据安全法律法规体系尚未完善,另外,汽车数据安全具有全球性,其他国家和地区也在积极应对和制定相关政策措施,因此数据安全相关法规的制定也需要考虑与国际接轨。对于智能网联汽车数据治理,除了政府主管部

    102、门外,作为利益相关方的汽车制造商、相关行业组织、技术提供商、网约车企业、车主等也应参与其中,共同做出合理和适当的决策。2.5 国内外法规及标准差异分析不论是国内还是国际,近几年有关汽车信息安全的法规、标准密集发布,涉及包括网络安全、数据安全、国家安全等多个方面,不论是 WP29 R155/156 的发布,还是国内各领域网络安全法规指南的发布,都说明信息安全正逐步成为各行各业需要关注的重点,安全的保证已经从一个产品、一个行业的安全上升到了国家安全的维度。1.强制与推荐目前国际法规如 WP29 R155/R156 等已强制实施,欧盟 2022 年 7 月之后上市的新车均需保证其网络安全流程的合规性

    103、和产品开发的安全性,并配套了相关的国际标准配合法规落地实施。这势必要求相关市场的整车厂、零部件供应商必须保证其流程乃至产品的合规,要求相关厂商从技术、成本、流程多个维度需要得到极大的提升。目前国内安全领域除了三大上位法,各个部委也出台了相应的政策规范与指南,已发布的配套标准均属于推荐标准,包括诸如汽车网关信息安全技术要求及试验方法、电动汽车远程服务与管理系统信息安全技术要求及试验方法等,尚未提出强制要求。然而,鉴于信息安全对于汽车行业的重要性,国内也在加快相关强制标准的制定,例如汽车整车信息安全技术要求、汽车软件升级通用技术要求、智能网联汽车 自动驾驶数据记录系统等强制标准已在制定中,相信在不

    104、久的将来,随着行业整体技术的积累,方案的成熟,相关强制标准也会制定并实施,实现与国际市场的接轨。2.流程与技术目前国际发布的法规、标准如 R155、ISO21434 等,首先从流程的角度提出安全保证的要求,包括整024个组织级的管理体系、特定项目的管理、供应商与主机厂的交互、产品的后期维护报废流程等,都首先强调流程的重要性,相关产品认证与上市的前提条件都是组织流程首先满足法规的要求。国内标准的制定关注重点在具体技术的落地实施上,包括关键部件如网关、T-BOX 的信息安全技术及测试方法、车联网各实体间的相互认证与通讯等。总的来说,流程与技术是相互支撑、相辅相成的,信息安全说到底是与人息息相关的,

    105、再先进的技术如果没有合适的人来执行也是一纸空谈,没有合理的流程也很难保证技术的顺利实施。但是如果没有明确的技术积累,而只是谈论流程,也是无法落地的概念。针对我国国情,技术的快速落地反而能快速推动行业的进步。当然,流程相关的法规制定也会随着技术水平的逐步提升而得到进一步落地。3.基础软件信息安全要求制定路径此外,国际上以 AUTOSAR 为典型代表,已逐渐形成完善的面向车控、车载的基础软件平台规范体系。然而在早期的 AUTOSAR 规范中,尚未涉及到有关信息安全的内容。近年来随着信息安全在汽车领域应用需求与技术的发展,在 AUTOSAR 规范中逐渐引入了信息安全有关的内容,包括密码相关软件栈、安

    106、全通信组件、入侵检测组件、V2X 通信安全等,如本报告第 2.2 节所述,并且各主要模块已形成详细的设计规范,给出了具体的功能规范、API 规范、运行时序及配置参数等。国内对于汽车基础软件规范标准研制的起步较晚,开始也较多地在参考、引用诸如 AUTOSAR 平台的软件规范,目前尚未形成成熟的汽车基础软件规范体系。随着汽车智能化、网联化、自动化在国内的快速发展,正在加快形成支持国内自主智能网联汽车的硬件、软件平台标准或规范。如前所述,目前已在汽标委立项国家推荐标准智能网联汽车 车控操作系统技术要求及试验方法、智能网联汽车 车载操作系统技术要求及试验方法以形成针对车用操作系统的基本要求,而在行业组

    107、织如 CSAE 立项若干关于车用操作系统设计实现细节要求的团体规范与标准。有关车用操作系统的信息安全要求自上述标准立项时就予以考虑并作为重要的内容,这是与国际上相关规范标准制定在路径上存在差异的地方。另外,国内在其他领域已经制定的操作系统相关安全技术标准也可为汽车领域标准的制定提供经验和借鉴。近年来,随着汽车信息安全问题的日益突出,国际国内有关汽车信息安全的法规、标准等正在加快建设、发布与实施,也为汽车基础软件的信息安全标准化提出了迫切的需求。汽车基础软件的平台规范以AUTOSAR 组织为典型代表,经过二十余年的发展,已形成了较为成熟完善的平台规范体系,受到业内广泛关注及认可,然而有关信息安全

    108、的需求、规范定义也是在近些年随着汽车向智能化、网联化、自动驾驶方面的快速发展而逐步完善的。总体而言,软件是作为车辆系统的组成部分而存在的,当前的标准制定侧重在整车、零部件的维度,专门针对汽车基础软件如车控操作系统、车载操作系统等的标准尚处于起步阶段。未来随着汽车信息安全标准体系的不断发展和成熟,有关汽车基础软件的信息安全标准会逐步丰本章小结富和细化,形成可指导具体开发的技术要求与测评方法。025第3章汽车基础软件信息安全关键技术3.1 信息安全基础概念3.1.1 常见信息安全属性汽车的信息安全包括几个重要的安全属性,包括机密性(Confidentiality)、完整性(Integrity)、可

    109、用性(Availability)和不可抵赖性(Non-repudiation),每个属性的主要表现均不相同。1.机密性(Confidentiality)机密性,指的是对信息开放范围的控制,确保信息没有非授权的泄漏,不被非授权的个人、组织和程序使用。需要保密的信息可以是车辆自身的密钥、证书、配置参数,也可以是车辆使用者的相关隐私,包括用户密码、定位轨迹、消费记录等,甚至包括车外行人车辆的音视频信息。保护机密性取决于信息定义和实施适当的访问级别,这种做法常常涉及将信息分为访问权限和机密等级分级。一些最常用的手段包括的文件权限设置、通信加密、访回控制列表以及文件数据加密等。2.完整性(Integri

    110、ty)该属性的关键是保护数据不被未授权方修改或删除,防止由于如通信或者固件被篡改导致的黑客利用。具体需要重点防护的数据包括车辆控制器内关键的配置参数、固件、操作系统、个人资料、通信报文信息等。常用于完整性保护的技术手段包括消息校验码、数字签名、安全启动等。3.可用性(Availability)可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。为保证可用性,可以采用冗余的方式进行,包括报文信号的冗余、传感器/控制器/执行器的冗余、控制信号通道的冗余以及供电等基础设施的冗余等。4.不可抵赖性(Non-repudiation)不可抵赖性主要应用在电子商务领域,如移动支付等场景,保证用

    111、户对自己行为的不可抵赖及对行为发生时间的不可抵赖。通过进行身份认证和数字签名可以避免对交易行为的抵赖,通过数字时间戳可以避免对行为发生的抵赖。3.1.2 常见安全分析模型1.STRIDE 安全建模方法微软最早提出的 STRIDE 安全建模方法代表六种安全威胁:身份假冒(Spoofing)、篡改(Tamper-ing)、抵赖(Repudiation)、信息泄露(Information Disclosure)、拒绝服务(Denial of Service)、特权提升(Elevation of Privilege)。026表3.1-1六种安全威胁属性威胁定义例子认证Spoofing(假冒)冒充 EC

    112、U 或者用户模 拟 某 ECU 进 行 报文发送完整性Tampering(篡改)修改数据修改配置变量,修改报文信息不可抵赖性Repudiation(否认)宣称未做过某个行为否认购买支付记录机密性Information Disclosure(信息泄露)暴露信息给未经授权的访问者密钥,定位信息可用性Denial of Service(拒绝服务)使服务对用户拒绝访问或降级车辆无法启动,功能无法使用授权Elevation of Privilege(权限提升)未经授权获取权限租 用 车 辆 人 员 获 取 车主权限第一步:绘制数据流图。根据功能逻辑,绘制数据在实体间的传递和存储。其中数据流图包含四个要素

    113、:实体、数据处理、数据存储、数据流。其中实体代表处理数据的用户、设备等实体;数据处理表示针对数据的处理过程,有输入输出路径;数据存储表示存储数据的内部实体,如数据库、消息队列、文件等;数据流表示实体与数据处理、数据处理之间或数据处理与数据存储之间的交互。图 3.1-1 数据流图第二步:识别威胁。STRIDE威胁建模方法已经明确了每个数据流图元素具有不同的威胁,其中外部实体只有仿冒(S)、抵赖(R)威胁,数据流只有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,出来过程有所有六种(STRIDE)威胁,存储过程有篡改(T),信息泄露(I)、拒绝服务(D)威胁,但如果是日志类型存储则还有抵赖(R)威

    114、胁。具体可以对照如下表格进行识别。027表 3.1-2 要素与威胁类型关联要素STRIDE实体数据处理数据存储数据流第三步:确定应对措施。针对不同的威胁确定应对措施,如为检测存储数据的篡改可以通过消息校验码、签名等方式进行检测。若实体的假冒导致了危害,可以通过身份认证方式进行。参考的应对措施如下表:表 3.1-3 参考应对措施图 3.1-2威胁类型应对措施S身份认证、数字证书、声纹、虹膜、个人信息T完整性校验、访问控制R安全审计、数字签名 I权限管理、数据加密D灾备设施、流量过滤E权限最小化2.HEAVENS 安全模型根据 SAEJ3061 法规,可以使用 HEAVENS 安全模型进行风险等级

    115、评估,包括威胁等级评估,影响等级评估,并最终得到影响等级,并确定安全需求。HEAVENS安全模型第四步:安全验证。在威胁建模完成后,需要对整个过程进行回顾,不仅要确认缓解措施是否能够真正缓解潜在威胁,同时验证数据流图是否符合设计,代码实现是否符合预期设计,所有的威胁是否都有相应的缓解措施。最后威胁家命名报告留存档案,座位后续迭代开发、增量开发时威胁建模的参考依据。028风险评估一旦确定了相关资产的威胁,下一步就是对威胁进行排序。这是风险评估期间所做的工作。威胁和资产之间的映射与威胁级别(TL)(图中的 In_03)和影响级别(IL)(图中的 In_04)参数一起用作输入。威胁级别参数(威胁级别

    116、(TL)和影响级别参数(影响级别(IL)见下表)。作为风险评估的威胁分析 功能用例的描述(图中的 In_01)是威胁分析过程的输入。威胁分析产生两个输出:(1)每个资产的威胁和资产之间的映射(图中的 Out_01)和(2)威胁与安全属性之间的映射(图中的Out_02)以确定哪些安全属性因资产上下文中的特定威胁而受到影响最终结果,确定了与 TOE/用例的每个资产相关的每个威胁的安全级别(图中的 Out_03)。表 3.1-4 TL评分指标经验所需知识机会窗口设备取值普通人公开极难标准0精通限制高专业1专家敏感中定制2多专家绝密低多重定制3表 3.1-5 TL等级TL 参数和TL 等级TL 值9无

    117、07-9低14-6中22-3高30-1极重要4表 3.1-6 IL评分指标经济安全操作性隐私取值无无伤害无影响无影响0低低1低轻到中中中10中严重高高100高致命1000029表 3.1-7 IL等级TL 参数和TL 等级TL 值0无01-19低120-99中2100-999高31000极重要4表 3.1-8 安全等级(SL)3.CVSSCVSS 全称为 Common Vulnerability Scoring System,即“通用漏洞评分系统”,是一个行业公开的标准。其被设计用来评测漏洞的严重程度,并帮助确定所需反应的紧急度和重要度。历经 1.0、2.0、3.0、3.1 版本,目前最新的是

    118、 3.1 版本。表 3.1-9 CVSS评分指标维度版本指标计算公式基础评价2.0攻击途径、攻击复杂度、认 证、机 密 性、完 整 性、可 用 性、权值倾向攻击途径*攻击复杂度*认证*(机密性+完整性+可用性)*权重)3.1可利用性、影响度可利用性+影响度030维度版本指标计算公式生命周期评价2.0、3.1利用代码成熟度、补丁完善水平、报告可信度10*利用代码成熟度*补丁完善水平*报告可信度环境评价2.0危害影响程度、目标分布范围(生命周期评价+(10-生命周期评价)*危害影响程度)*目标分布范围3.1保密性需求、完整性需求、可用性需求影响度 0且无修正,Roundup(Roundup(Min

    119、(M,影响度+M,可利用性),10)*利用代码成熟度*补丁完善水平*报告可信度影 响 度 0 且 有 修 正,Roundup(Roundup(Min1.08*(M,影响度+M,可利用性),10)*利用代码成熟度*补丁完善水平*报告可信度4.Attack TreesAttack Trees 最初是作为一种独立方法应用的,后来与其他方法和框架结合使用,如 STRIDE 模型、CVSS等。Attack Trees是以树图的形式描述对系统的攻击,树的根是攻击的目标,叶是实现该目标的方法。表 3.1-10 攻击树结构类型描述图示攻击目标、攻击手段使用或门来代表可以通过多条路径得到攻击目标031类型描述图

    120、示使用与门来代表必须同时具备多个条件才能达到攻击目标使用菱形代表待设计事件使用圆形代表基础事件032 图 3.1-3 Attack Tree安全模型3.2 汽车基础软件信息安全生命周期3.2.1 概念开发阶段概念开发阶段主要的目的是通过整车功能,如远程控制功能、转向功能等的分析,应用 3.1 章节的信息安全分析模型识别信息安全漏洞,评估安全等级。针对安全等级较高的漏洞设计安全机制来应对黑客的攻击。信息安全的实现并非是通过独立的安全机制可以实现的,需要进行信息安全纵深防御体系设计。从云端-车云通讯-车端控制器-应用软件-基础软件-硬件等多个维度进行层层防御,设计相应的安全措施提升安全性。基础软件

    121、的安全需求主要来自以下两个方面:1.实现更高一级来自于功能/控制器的信息安全需求。如特定控制器需实现加密通讯,基础软件需要保证安全通讯协议、密钥管理、加密认证、加密存储等功能。2.基础软件自身安全的要求。为保证上述功能的安全实现不被绕过,基础软件还需保证自身的安全,如不存在公开漏洞、安全启动等。0333.2.2 产品开发阶段软件安全需要基于完整的安全分析进行设计,从硬件的安全信任根开始,保证每层的程序调用都是基于经过验证的,包括程序完整性的验证,访问权限的验证,参数合理性验证等。软件实现过程是一个容易引入信息安全问题的过程,有三个方面需要重点关注:1.开源代码。随着业界开源的范围越来越广,从操

    122、作系统到基础软件、加密算法,都有很多开源库供程序编写人员使用,虽加快了软件实现的速度,但是良莠不齐的开源库也会带来很多信息安全问题。有些开源库长期无人维护,已存在大量的漏洞,若不加鉴别直接使用,就会导致整个系统漏洞百出。因此在使用开源代码时,优先选择得到持续支持的开源库,并且持续关注其信息安全相关的补丁,并及时进行更新。2.开发周期长。汽车行业相较于功能先进性,控制器的稳定性是更加追求的要素。一款车型开发周期动辄 2-3 年,使用的软件版本也是相对成熟。这就会导致在车辆开发过程中,所使用的软件就可能被挖掘出多个漏洞,若不及时进行更新或者修复漏洞,刚上市的新车就可能有很多已知漏洞的存在。因此,在

    123、正式量产之前,一定需要对其产品进行漏洞扫描,防止已知漏洞的存在。3.开发人员信息安全意识缺乏。在程序开发过程中,由于进度要求,开发人员天然会更加关注功能的实现,而对信息安全的防护意识不足,导致实现的程序遗留了可以被黑客利用的漏洞。因此,加强开发人员的信息安全意识,加强程序释放过程中信息安全的检测势在必行。在完成基础软件的开发后,需要针对其安全性进行测试,包括软件本身是否正确实现相关需求以及是否有未知漏洞两个方面进行测试。静态代码检查,可以通过商业工具如 QAC 进行静态代码检查,保证其符合 CERT C 等信息安全代码规范;图 3.2-1 静态代码检查034 在保证软件实现与需求一致后,需要通

    124、过以下三种测试手段确认软件的安全性:漏洞扫描,通过漏洞扫描软件如 defensecode 进行现有漏洞的扫描,防止软件存在已知漏洞;模糊测试,通过大量的随机请求,测试软件的鲁棒性,探测其是否有未知漏洞;需求一致性测试,通过单元测试、集成测试等方法,确定软件的实现与软件设计需求保持一致;渗透测试,通过专业渗透人员的分析,寻找程序逻辑中的漏洞,并尝试进行利用。若发现新的漏洞,则反馈给开发人员进行修正。3.2.3 后开发阶段(生产、运维、报废)在生产阶段,要保证基础软件和应用软件在产线的正常刷写。产线软件的注入需要保证刷写方经过认证,例如供应商完成基础软件的刷写,内部包含初始密钥。OEM 在产线刷写

    125、更新密钥、证书、配置等内容前,需首先完成与控制器的相互认证。信息安全是一个动态的过程,在软件使用过程中,随着技术的进步,之前安全的软件可能会出现(或发现)新的漏洞。因此软件维护人员需持续监控最新的漏洞消息,及时更新相关软件补丁,保持软件的安全性。在更新过程中,也需保证对更新源的认证,更新软件完整性校验,版本校验,防止黑客利用更新的漏洞进行软件的恶意修改。在车辆的使用过程中,控制器内可能存储了大量的用户使用信息。在车辆的报废/买卖,或者某一部件的更换的情况下,用户信息会有泄露风险。为保证车辆的数据安全,基础软件需支持敏感数据(如密钥、证书、用户资料、指纹识别信息等)的一键销毁。图 3.2-2 需

    126、求一致性测试0353.3 汽车基础软件信息安全需求信息安全的实现并非是通过独立的安全机制可以实现的,需要进行信息安全纵深防御体系设计。从云端-车云通讯-车端控制器-应用软件-基础软件-硬件等多个维度进行层层防御,设计相应的安全措施提升安全性。基础软件的安全需求主要来自以下两个方面:1.实现更高一级来自于功能/控制器的信息安全需求。如特定控制器需实现加密通讯,基础软件需要保证安全通讯协议、密钥管理、加密认证、加密存储等功能。2.基础软件自身安全的要求。为保证上述功能的安全实现不被绕过,基础软件还需保证自身的安全,如不存在公开漏洞、安全启动等。3.3.1 安全启动安全启动(SecureBoot)是

    127、 MCU 的基本功能,通过硬件加密模块来实现,该机制必须独立于用户程序运行,不能被破坏。作为整个安全启动信任链的基础,安全启动必须主要用于在 MCU 启动之后,用户程序执行之前,对用户定义的 Flash 中关键程序的数据完整性和真实性进行验证,确定是否被篡改。如果验证失败,说明 MCU 处于不可信的状态,部分功能甚至整个程序不能运行。3.3.2 安全通信在目前的车载网络中,大部分数据传输都是在没任何安全措施的情况下进行的。例如应用最广的CAN 通讯设计之初是没有考虑过信息安全问题的,其明文传输、报文广播传输、极少网络分段等特性,让进入整车网络的黑客如同进了游乐场,轻松便可以伪造报文对车辆进行控

    128、制。SecOC 是在 AUTOSAR 软件包中添加的信息安全组件(组件位置及可应用的通讯方式如下图所示),该 Feature 增加了 CMAC 运算、秘钥管理、新鲜值管理和分发等一系列的功能和新要求。SecOC 模块在PDU 级别上为关键数据提供有效可行的身份验证机制,认证机制与当前的 AUTOSAR 通信系统无缝集成,同时对资源消耗的影响应尽可能小,以便为旧系统提供附加保护。图3.3-1安全启动流程此外,车云通讯的安全性主要依靠 TLS/SSL 协议保证。TLS 协议采用主从式架构模型,用于在两个应用程序间透过网络创建起安全的连接,防止在交换数据时受到窃听及篡改。036图3.3-2 TLS协

    129、议结构3.3.3 安全诊断一些用于将例程或数据下载/上传到服务器以及从服务器读取特定内存位置的诊断服务可能需要进行身份验证。不正确的程序或下载到服务器的数据可能会潜在地损害电子设备或其他车辆部件,或可能违背车辆的排放或安全等标准。另一方面,当从服务器检索数据时,可能会违反数据安全性。因此需在这些服务执行前,要求客户证明其身份,在合法身份确认之后,才允许其访问数据和诊断服务。所以安全诊断是通过某种认证算法来确认客户端的身份,并决定客户端是否被允许访问。可以通过对随机数种子生成的非对称签名进行验证或者通过基于对称加密算法的消息校验码来验证其身份。图3.3-3 安全诊断流程 Client Serve

    130、r 应用信息安全相关算法计算 Key 应用相同信息安全相关算法计算得到Key,与收到 Client 端 Key 比较 0373.3.4 安全调试现在基本控制器都配备了基于硬件的调试功能,用于片上调试过程。安全 JTAG 模式是指通过使用基于挑战/响应的身份验证机制来限制 JTAG 访问。检查对 JTAG 端口的任何访问,只有授权的调试设备(具有正确响应的设备)才能访问 JTAG 端口,未经授权的 JTAG 访问尝试将被拒绝。在生产或者下线阶段,必须要禁用或者锁定相关的调试诊断接口,禁用意味着无法与硬件调试接口建立连接,锁定意味着硬件调试接口受到保护,只能根据安全调试解锁来访问。3.3.5 安全

    131、升级随着越来越复杂的网络环境,在软件升级更新过程中,保证升级包的发布来源有效、不被篡改、数据不丢失以及升级内容不被恶意获取变得越来越重要。传统升级过程升级包的数据基本上是以明文传输,数据校验方式也是安全性较低的散列算法。安全升级在传统升级基础上,一方面使用添加签名的固件和在固件验证过程中额外执行签名验证来增强固件完整性验证,保证数据来源可靠,数据完整没有被篡改;另一方面还增加了对通过服务器加密固件的解密功能,传输数据过程通过密文传输,有效的降低 OTA 无线更新时数据暴露的风险。图3.3-4 OTA升级流程3.3.6 安全存储一次性可编程存储器 OTP(On Chip One Time Pro

    132、grammable ROM,On-Chip OTP ROM),也称为eFuse,是芯片中特殊存储模块,字段中的任何 eFuse 位都只能从 0 编程为 1(融合),只能被烧写一次,但是读取操作没有限制。安全存储还可以通过将 Flash 某些区域设置只读或者只写来实现,防止非法访问和篡改。Flash 保护区域的数量和大小会根据 Flash 的类型和该 Flash 块的大小而有所不同。3.4 关键技术研究与应用分析3.4.1 综述汽车基础软件提供了虚拟化、操作系统内核及服务(如系统日志)、基础软件中间件、内/外部通讯、防火墙、访问控制等重要功能,这些是汽车信息安全的基础;随着汽车向智能化网联化发展

    133、,对于基础软件安全性的要求在提升,需要引入加密芯片及 TEE 基于硬件的安全手段来强化安全能力;同时对于基础038软件的应用安全防护支撑、身份鉴别和安全监测能力也提出了更高的要求。本章节针对这些汽车基础软件研究对象的信息安全需求进行关键技术的研究和应用分析。3.4.2 外部安全通信智能化、网联化作为汽车发展的趋势和方向,使得智能网联汽车的信息安全变得尤为重要,汽车电子系统的外部通信安全作为其中不可分割的一部分,也需要制定完整严密的技术方案来保证,外部安全通信可分为近程通信、远程通信和云端通信三类的安全通信。图3.4-1 车辆外部通信近程通信主要包括用户可以通过车载蓝牙连接移动智能设备,利用 N

    134、FC(近距离无线通讯技术)解锁进入车辆,利用 WIFI 的热点共享功能等与车辆建立联系,从安全通信的角度来说,近程通信也面临着越来越大的挑战。已知针对蓝牙的安全威胁包括蓝牙漏洞攻击、蓝牙劫持、拒绝服务攻击、中间人攻击、配对窃听等;Sub-G 的中间人攻击可以通过复制车辆钥匙,使得攻击人盗取车辆或者车内的贵重物品;通过攻击运营商的 WIFI 通道,就可以实现登入汽车终端,获取用户隐私数据、历史记录等。针对蓝牙已知的漏洞和风险,可以保持使用最新版本的蓝牙实现,并且在建立蓝牙通信时,增加基于可信第三方的认证,选用复杂的 PIN 码,来防止安全攻击;针对 NFC 等无实体车钥匙入侵方式,可增加 PIN

    135、 码认证车辆启动的方式,以及随身携带用于启动汽车的 NFC 设备,来防止安全攻击;针对 WIFI热点攻击,在不使用的情况下保持关闭热点状态,以及设置复杂的热点密码来保证其安全性。远程通信基于网络通信的优势,也继承了对应的安全风险。主要包括虚假终端、伪基站、数据窃听、数据篡改、数据重放等攻击,影响车辆业务的正常运行,最终实现对车载终端的入侵与控制。例如车载T-BOX 具有车辆远程控制、远程数据传输等功能,其安全隐患主要体现在三个方面。一是固件逆向,攻击者通过固件分析、逆向工程,解密通信协议;二是信息泄露,通过对预留调试接口读取内部数据,解密通信协议;三是远程控制,通过仿冒云平台的控制指令,将指令

    136、发送到汽车内部,实现对汽车的远程控制。另外,车与车、车与路边单元的专用高效通信技术也为黑客入侵提供了新的方式。针对远程通信的威胁,可使用增加硬件防火墙的方式,来保证车辆安全;在终端做固件加固,访问控制,加密认证等方式,保证其合法可靠性。在通信过程中,可使用防火墙与入侵检测等技术,实现车机内网的安全隔离、访问控制及异常连接的检测与防御。039云端通信可能会遭受黑客攻击,产生信息泄露及信息篡改等方面的严重后果。车载终端设备应具备证书管理功能和TLS安全通信功能。通过基于TLS安全通信协议,并结合商用密码的数字证书、数字签名、数据加密等技术,能够实现车载终端设备与云端服务平台的双向身份认证、通信数据

    137、加密、通信数据完整性校验等安全通信能力。3.4.3 内部安全通信目前,车内通信仍以 CAN/CANFD 车载以太网通信为主。随着汽车智能网联业务快速发展,整车功能越发复杂,汽车对外接口、整车内部单元之间通信的数据量日益逐增,车内网通信的安全性问题越来越引起大家的关注。一方面,CAN 等传统车载网络协议缺乏安全设计,车内数据通信主要通过报文 ID 进行接收过滤,部分报文仅提供 CRC 校验,缺乏重要身份鉴别、通信加密等防护措施;另一方面,随着整车高速通信需求的日益增多,逐渐催生出了车载以太网协议,如 OSI 七层模型的 5-7 层 SOME/IP、DOIP协议,其需要运行于 TCP/IP 协议栈

    138、之上,对内部通信安全提出了更高要求。图3.4-2 车内网络通信拓扑示例040图3.4-3 以太网通信协议模型车载以太网协议虽然可以满足高频大规模数据传输的需求,但如果没有一定的安全措施,将会存在着一定的安全威胁。攻击者可以通过监听工具或其他方式对车辆内部的报文进行非法监听获取敏感数据,甚至篡改报文内容后转发送给其他 ECU 设备意图控制其他 ECU 设备,影响整车正常工作,严重时会危及车内人员的生命安全,目前常见的攻击包括重放攻击、嗅探攻击和侧信道攻击。在此背景下随着汽车对信息安全的需求提高,车内网通信的信息安全防护机制变的越来越重要。车内网通信安全主要通过身份认证、通信加密和数据可靠性三方面

    139、来保障。1.身份认证模块之间应采用访问权限控制的方式,不同的子系统应根据通信业务的重要性划分不同的信息等级权限。建立合理的安全访问策略,并通过与功能逻辑设计的配合,避免由于车载通信终端的信息安全问题导致子系统功能异常。每个子系统通信时应当添加上身份标识,供其他子系统认证,同时子系统应当具备认证其他子系统的能力。基于 CAN 通信的 SecOC 技术采用了 MAC 算法保证了车内通信的可认证性。MAC 算法选择 AES-128-CMAC,不同的控制器使用相同的对称密钥对 CAN 报文进行 MAC 值的计算,这样就实现了不同控制器在车内通信过程中的身份认证。外部诊断仪接入 OBD 口实现 UDS

    140、诊断的过程中,0 x27 服务 Secu-rityAccess 通过挑战响应的方式可完成诊断仪的身份认证。车内以太网通信可采用 TLS 协议保证车内通信的可认证性,TLS 协议安全传输建立过程中,主要包含密钥协商和身份认证过程,因此,可以选择性能合适的算法套件,进行密钥协商以及身份认证。2.通信加密为了保证数据的机密性,每个子系统之间的通信数据应进行加密。CAN 通信对于实时性要求高,而加密算法相对耗时,因此 CAN 通信加密方案应考虑性能开销及其对时延的影响。车载以太网通信中的TLS 协议在安全传输建立过程中,可以设置指定安全算法套件,选择性能合适的算法套件,进行数据加解密,也可在应用层指定

    141、合适的安全算法进行数据加解密。3.数据可靠性汽车系统应具备实时监控检测异常的报文和非法入侵的能力,并提供相应的分析报告和告警。该系统具备冗余备份和重发机制,在对电子系统发送重要任务时,保证传输数据的可靠性,同时系统应当具备抵抗拒绝服务攻击。子系统数据交互期间,应使用相应技术避免大量数据集中发送,从而导致总线堵塞,041对相关的网络访问操作和安全事件生成日志记录。CAN 通信采用 SecOC 技术,其中的新鲜度值管理可抵御 CAN 报文重放攻击,MAC 算法可抵御CAN 报文篡改。在车载网关中部署 CAN IDS 技术,主要对报文的流量进行实时监测统计,对每个报文进行基础的检测,如报文长度、周期

    142、、频率、信号阈值等检测;对工况状态、报文相关性进行检测,将检测到的异常事件通过车载 T-BOX 上报到云端服务器。车载以外网通信采用时间戳等方式抗重放攻击,需要保证通信双方时间同步,且保证来自合法权威的时间源。详细的技术可以参见第四章节,此处就不再进行赘述。3.4.4 应用软件安全防护随着智能网联汽车的发展,车用应用软件正逐步向智能手机应用趋同,其使用过程中的安全性问题被越来越多 v 用户所关注。车的信息既涉及用户个人数据,也涉及车本身的属性数据,后者对于车辆的安全行驶有重要的意义。应用软件安全防护的目标是要保证安装或预置到车辆上的应用软件可知可控,可知是指用户应知晓应用将要进行的行为、行为的

    143、目的、行为的方式、应用场景以及可能造成的后果,可控是指用户应有自主选择权,可选择是否允许该行为的执行。应用软件安全包括以下典型场景:非法安装未知来源的应用软件,车用操作系统缺乏安全机制来识别应用软件来源;超过应用本身功能之外的过高权限,非法操作重要外设或读取敏感数据;非授权地跨应用数据访问,应用间缺乏数据隔离能力,一个应用非授权地可访问另外一个应用的数据;非授权地跨应用服务访问能力,一个应用的原子化服务能力被非授权应用访问;一个应用被另外一个应用的故障或漏洞波及影响,应用软件间缺乏隔离机制;应用本身的加固措施缺乏,应用被逆向工程、代码注入等恶意行为破坏,导致被破解、被篡改、被攻击以及被动的信息

    144、泄露等不良后果产生。应用软件安全防护需要从平台和应用两方面入手,整体安全架构如下图。图3.4-4 应用软件安全防护架构操作系统 Kernel 作为底层的基础软件,管理各类系统资源并具备最高的特权。Kernel 需要提供全面的信息安全机制,从而支持应用使用此操作系统建立产品内生的安全特性。CPU 支持 MMU 及运行级别分层等硬件特性,MMU 机制使得不同应用程序的物理地址空间隔离,避免应用间的内存相互干扰;CPU042运行级别分层使得应用和 Kernel 运行隔离,避免应用对内核的非法访问。以 Linux+X86 为例,X86 支持4 个运行级别 RING0RING3,操作系统(内核)代码运行

    145、在最高运行级别 RING0 上,可以使用特权指令控制中断及修改页表等,应用程序的代码运行在最低运行级别 RING3 上,访问内核功能需要通过系统调用,将 CPU 的运行级别从 RING3 切换到 RING0,并跳转到系统调用对应的内核代码位置执行,完成相关操作后再从 RING0 返回 RING3。这种 CPU 的硬件特性保证了应用间物理地址空间的隔离、用户空间和内核空间的隔离,是应用软件安全防护的硬件基础。主动防御指改变防御方被动局面,通过基础软件(编译器、操作系统)实现动态、主动地防御;攻击者往往利用代码符号的规律进行漏洞挖掘和系统突破,针对攻击方式,主动防御主要研究程序地址布局随机化、全局

    146、符号布局随机化、关键数据结构布局随机化技术,打破攻击者所依赖的规律。对象访问控制为上层应用访问资源提供安全机制,定义了所有的进程对系统的其他部分(文件、文件夹、设备、socket、端口和其它进程等)进行操作的权限或许可。TEE 是可信执行环境,是一项硬件特性,当前主流的 X86 或 ARM CPU 均支持该特性,它能够从硬件层面来保护执行在 TEE 中的应用和数据安全。对于安全高度敏感的应用,可以把应用安全敏感功能逻辑拆分到 TEE 中执行,敏感数据存储到 TEE 中,从硬件层面来防护应用软件的信息安全。在框架层面,需要建立应用签名验证、权限管理及应用沙箱机制。应用签名主要解决应用的来源合法性

    147、问题,利用密码算法,采用证书对应用进行签名,框架层在应用安装时对证书进行验证,证书合格的应用将被允许安装,框架可以根据证书的类型赋予应用不同权限的能力。权限管理解决应用权限授予问题,包括检查权限、请求权限和处理权限三部分。应用权限由用户确认,只有用户认可才会被授予,应用默认没有任何权限;应用对外开放的服务需要按照规范发布,第三方应用只有明确声明并授权才能获取另外一个应用的服务访问能力。应用沙箱是为执行中的程序提供隔离环境的一种安全机制,它将各应用与关键系统组件、数据以及其他应用隔离开来,当一个应用受到恶意软件的破坏时,应用沙箱会自动将其阻止,确保设备和信息的安全,应用沙箱实现依赖 Kernel

    148、 提供的对象访问控制能力。应用加固能有效防止应用被反编译、嵌入病毒、非法扣费等,有效确保应用程序逻辑安全和代码安全。图3.4-5 应用安全加固043对 Dex 文件进行加密,防止被逆向工具进行反编译和破解,完全不对程序的可执行代码进行修改,且不影响程序的正常执行;对 so 文件进行加壳保护,增加 so 文件被破解和分析的难度,防止用户 C/C+层代码逻辑泄露,保护 C/C+层的代码安全;对图片、音频、汉化文件等关键资源文件进行加密保护;使用双进程反调试技术对应用进行保护,全面对抗动态调试工具,防止非法操作者通过调试器对应用进行动态分析,保护应用程序安全;内存保护主要防止使用 gdb 和 ida

    149、 等工具 dump 有效的内存镜像,通过加密 Dex 文件中关键部分,使得内存中存在的 Dex 并不完整,防止通过 Dump 工具对内存进行窃取并还原 Dex 文件;通过进程检测、底层 Hook 等技术,有效对抗各类脱壳工具的攻击,防止对内存关键指针的 dump;针对指定 API 进行保护,提升加固后应用执行效率,防止 apktool,jeb,baksmali 等进行反编译得到源码。应用软件的加固技术经历了几代的发展演变,在防逆向脱壳的难度上也越来越大,安全性也越来越高。加固技术的发展经历了如下几个阶段:Dex 动态加载技术、Dex 类抽取技术、自定义 VMP 技术、Java2C技术。图3.4

    150、-6 Java2C技术流程图应用软件安全防护是个系统性的工程,需要硬件、Kernel、框架及应用的综合作用,尤其是 Kernel 和框架,是应用信息安全的基础,在保障自身免受漏洞和缺陷攻击的前提下,应提供尽可能丰富的安全手段,保护应用及其数据的安全,而且,这个过程对应用尽可能透明和无感。对于应用本身,除了保证本身的实现逻辑及代码安全性符合要求,还需要对应用做加固处理,保护源代码和程序逻辑的安全。3.4.5 系统安全防护基础软件系统安全包括了车用操作系统内核、中间件软件如 AutoSAR CP、AutoSAR AP 等基础软件的整体安全。车联网时代,汽车通过基础软件系统可与智能终端、互联网等进行

    151、连接,实现娱乐、导航、交通信息等服务。基础软件系统常基于 Linux、QNX 等操作系统内核开发,由于操作系统内核代码庞大且存在不同程度的安全漏洞,操作系统内核自身的安全脆弱性将直接导致应用系统面临被恶意入侵、控制的风险。044除此之外,用户的智能终端也存在被入侵、控制的风险,一旦智能终端被植入恶意代码,用户在使用智能终端与基础软件系统互连时,智能终端里的恶意软件就会利用基础软件系统可能存在的安全漏洞,实施恶意代码植入、攻击或传播,从而导致基础软件系统异常甚至接管控制汽车。基础软件系统通常面临的安全威胁有非授权访问、暴力破解、溢出攻击、恶意软件、资源垄断、残余信息利用、数据传输窃听和重放攻击。

    152、1.非授权访问非授权用户或进程访问基础软件系统的安全功能数据和用户数据,并对安全功能数据和用户数据进行恶意操作。2.暴力破解运用各种软件工具和安全漏洞,破解合法用户的口令或避开口令验证过程,然后冒充合法用户潜入基础软件系统,夺取基础软件系统控制权的攻击形式。3.溢出攻击利用堆栈生长方向和数据存储方向相反的特点,用后存入的数据覆盖先前压栈的数据直至覆盖函数的返回地址,函数执行完返回时改变程序的正常执行流程,从而达到攻击目的的行为。4.恶意软件恶意软件可能通过伪装成授权应用或进程访问用户数据和基础软件系统敏感资源。5.资源垄断恶意进程/线程绕过操作系统内核调度机制,长时间持续占用 CPU 资源,导

    153、致其他用户/主体无法获取 CPU 资源,破坏操作系统内核的可用性。6.残余信息利用恶意进程可能利用操作系统内核对于残留信息的处理缺陷,在执行过程中对未删除的残留信息进行利用,以获取敏感信息或滥用操作系统内核的安全功能。7.数据传输窃听恶意用户或进程可能监听基础软件系统与远程可信实体间传递的用户数据。8.重放攻击非授权用户利用所截获地授权用户信息,重新提交给基础软件系统,以假冒授权用户访问基础软件系统的功能和数据。针对基础软件系统面临的安全威胁,基础软件系统安全的目标是通过符合车端应用场景的身份权限管理和访问控制机制,正确地响应授权操作和处理异常行为,对抗针对基础软件系统的溢出攻击、暴力破解、中

    154、间人攻击、重放、篡改、伪造等多种安全威胁,保证基础软件系统文件和数据的可用性、保密性、完整性和可审计性,保证对各类资源的正常访问,基础软件系统能够按照预期正常运行或在各种操作情况之下处于安全状态,为此分层的安全系统架构如下图所示:045图3.4-7 分层的安全系统架构在最底层的硬件层,提供安全芯片作为系统的信任锚。安全芯片通常采用 HSM(Hardware Security Module),配备独立的 CPU 核和针对特定算法的硬件加速器(如 AES-128、SHA-256 等)。HSM 通常还拥有单独的存储区,包括 RAM 和 NVM,HSM 的存储区在正常运行状态下应只允许 HSM 核读写

    155、,主核不能读写。这样就可以把算法密钥等重要数据存储在HSM存储区,与主核进行隔离,进一步加强安全性。此外 HSM 模块还会带有真随机数生成器等加密算法常用外设。TEE 是一种具有运算和储存功能,能提供安全性和完整性保护的独立处理环境。其基本思想是:在硬件中为敏感数据单独分配一块隔离的内存,所有敏感数据的计算均在这块内存中进行,并且除了经过授权的接口外,硬件中的其他部分不能访问这块隔离内存中的信息。以此来实现敏感数据的隐私计算。具体实现参考 3.4.10TEE 可信执行环境。在硬件层之上的操作系统内核层面,操作系统内核应为用户态应用程序的存储访问提供隔离措施,以保证每个存储访问相互隔离。操作系统

    156、内核应提供措施来约束每个进程在执行过程中不会使用超过其预先分配的资源,应对操作系统内核的地址空间进行保护,并为应用程序提供访问操作系统内核地址空间的安全接口,以支持安全相关的进程间通讯。在操作系统内核空间出现异常时,如非法系统调用、堆栈溢出、指针异常访问、内存越界、死循环、死锁、超时等,操作系统内核应立即调用内核异常处理程序,并上报对应的故障代码。操作系统内核应尽可能地监控每个用户态进程的资源消耗,如 CPU、内存等。提供栈溢出诊断机制,以探测已经发生的栈溢出错误并调用内核异常处理程序。对于内核服务接口,操作系统内核应向用户态软件模块提供安全的服务接口(如 I/O 操作、信号处理等),不正确地

    157、调用这些服务接口不应导致内核崩溃。当出现不正确的操作系统内核服务接口调用(例如,传递非法地址、无效参数、非法的上下文等)时,操作系统内核服务接口不应执行对应的服务,并且立即返回错误代码。安全启动(Secure Boot)就是在基础软件系统启动过程中,前一个系统验证后一个系统的数字签名,验证通过后,运行后一个系统。在可信计算体系中,建立信任需要先拥有可信根(Root of Trust),然后建立一条可信链(chain of Trust),再将信任传递到系统的各个模块,之后就能建立整个系统的可信。安046全启动的原理就是硬件信任锚+信任链。而 HSM 在安全启动中就充当了硬件信任锚的角色,具体安全

    158、启动流程可参见 3.4.5 安全可信启动章节。基础软件系统本身应当执行系统加固,以减少遭受外部攻击的可能性,具体说来基础软件系统应遵循最小化原则:移除不必要的服务程序,关闭不需要的端口和服务;移除开发、编译、调测类、网络嗅探类的服务和工具;去除安装、显示和调整系统安全策略的服务和工具;检查不应存在任何后门和隐藏接口。基础软件系统应执行漏洞扫描,不应存在由权威漏洞平台 6 个月前公布且未经处置的高危及以上的安全漏洞。主动防御是利用操作系统内核与工具链对整个基础软件系统引入动态、随机、多样的安全基因。使整个基础软件系统在没有外界辅助手段支撑的情况下仍具有发现和抵抗各种“病毒”(包括未知威胁)的能力

    159、。具体说来就是针对“系统探测”-“漏洞挖掘”-“系统突破”-“系统控制”的攻击链,主动防御能在不同的攻击步骤上通过随机化(运行地址随机化、全局符号随机化、数据结构随机化)、异构发布等手段,改变攻击过程所依赖的系统规律,通过编译器产生具有随机、多样性特征的多变体,使被攻击路径呈现为随机、多样的特征,提高攻击、破解基础软件系统的难度。基于硬件和操作系统内核的安全支撑,基础软件系统还能提供防火墙和入侵检测来应对外部网络攻击。防火墙可以隔离内外部网络,入侵检测可以及时阻止基础软件系统内部异常的通信。为了进一步提高内部网络的安全,还可以按风险、业务将内部网络分割成互相隔离的部分。针对车内常见的 CAN

    160、通信,采用 SecOC 来保证通信的可靠性。防火墙可以提供针对特定端口或 IP 的访问控制实现防 DDos 攻击功能,实现对报文的安全过滤,拦截非法数据,避免其进入安全区域。防火墙的相关数据(如拦截数据流量、防火墙故障状态和防火墙规则数量等)也可以存储在相应的安全区域,并及时上报或转发其它模块处理。入侵检测(IDS)实时监视系统,一旦发现异常情况就发出警告。根据信息来源可分为基于主机 IDS、基于 CAN 和以太网的 IDS。基于主机的入侵检测系统作为基础软件系统的监视器和分析器,它并不作用于外部接口,而是专注于系统内部,监视系统全部或部分的动态行为以及整个计算机系统的状态,包括对系统配置文件

    161、、系统日志、进程、系统调用、文件系统的监控及异常发现和告警能力。基于 CAN 总线和以太网的入侵检测可以通过车内接口,实时采集 CAN 总线和以太网的通信数据,并根据策略分析是否有异常流量的数据包,并及时上传到相关控制器和云端。根据检测方法又可分为异常入侵检测和误用入侵检测,前者先要建立一个系统访问正常行为的模型,凡是访问者不符合这个模型的行为将被断定为入侵;后者则相反,先要将所有可能发生的不利的、不可接受的行为归纳建立一个模型,凡是访问者符合这个模型的行为将被断定为入侵。为了提高网络通信的安全性,还可以采用网络分割来防御车内网络攻击。将关键安全网络和非关键安全的网络或者是能与外部链接的网络隔

    162、离,通过受限制在不同的网络中,网络间的通信限制通过防火墙或者安全网关,单独允许一个可选择的信任帧列表从低信任的广播到高信任的网络,使攻击者实现攻击难度大大增加。目前在车内应用最广的 CAN 通讯设计之初没有考虑信息安全。其明文传输、报文广播传输、极少网络分段等特性带来了很大的安全风险。为了给 CAN 通讯增加一定的安全性,响应汽车行业对数据加密和验证的需求,AUTOSAR 组织补充了全称为 Secure Onboard Communication(SecOC)的组件,为车载通讯总线引入了一套通信加密和验证的标准,增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求(相关技术的详细

    163、介绍可参考 4.1.1 节)。SecOC 模块在 PDU 级别上为关键数据提供047有效可行的身份验证机制。认证机制与当前的 AUTOSAR 通信系统无缝集成,同时对资源消耗的影响应尽可能小,以便可为旧系统提供附加保护。基础软件系统安全是一个综合课题,需要在不同层次、不同维度对基础软件系统面临的威胁进行分析,结合对安全资产、攻击者角度、攻击路径、造成的危害综合评判,采用不同的安全技术对基础软件系统进行保护,并且随着新的漏洞发现和攻击技术的出现,及时更新基础软件系统的防护能力。3.4.6 安全可信启动目前主流的嵌入式设备都采用可编程片上系统(System on a Chip,SOC)作为其嵌入式

    164、系统。在SOC 启动过程中存在一定的安全风险,恶意软件有可能会修改引导加载程序等固件。比如,使 SOC 受到Rootkit攻击。Rootkit等恶意软件通过修改系统的启动过程,安装到系统内以达到持久驻留系统的目的,SOC 一旦受到 Rootkit 等恶意代码感染,即使重新安装系统也无法清除。因此有必要对 SOC 进行安全保护,防止在启动过程中固件被恶意篡改。图3.4-8 安全可信启动由于操作系统启动时需要有多个启动镜像,因此在安全启动过程中通过建立信任链。每个固件在加载运行前都经过数字签名的验证,只有当前阶段对后续待启动的模块进行验证通过后,才会加载和执行后续的模块。以上述为例,安全启动的流程

    165、如下,1.在 SOC 系统上电后,首先初始化 Bootrom,这是 SOC 厂商出厂配置的启动文件。2.Bootrom 初始化完成后装载用于后续验证镜像文件的公钥,并对其进行自检。3.确认公钥的合法性后,Bootrom 使用公钥对 Bootloader 的镜像文件进行验签。4.验签完成并确认 Bootloader 完整性后,利用公钥对其下一级镜像 OS 文件进行验签。5.在确认 OS 的完整性后,OS 启动所需的应用程序。当前镜像合法性的确认是在上一级镜像安全的基础上进行的,也就是建立信任链。因此,需要保证初级镜像 Bootrom 是合法性的,使其可作为信任根。通常 Bootrom 在出厂时是

    166、存储在 OTP(One Time Programmable,一次性可编程)区域,使其只能读不能写。OTP 特性保证了器件被编程一次后其内容不能被再次更改,但可被多次读取,出厂状态下所有 OTP 的 bit 均为 0,刷写后一旦某位 bit 变成 1 后将无法修改,也称该操作为硬件熔断。由于镜像文件的验签操作依赖于公钥,若 SOC 系统的密钥被攻击者替换,那么攻击者只需要用与其匹配的私钥制作镜像签名即可。因此必须确保 SOC 系统上的公钥不被替换。通常的做法是将公钥存储在 OTP 区域。但由于 OTP 可用区域是有限的,而为了确保每次安全启动所用的公钥是有效的,需要在048OTP 区域存储公钥摘

    167、要。在每次系统上电之前,Bootrom 都会使用 OTP 中公钥摘要值来验证公钥的完整性,而公钥是保存在镜像的配置文件中。图3.4-9 安全启动流程图在安全启动过程,分别读取启动镜像、对应签名文件以及公钥。使用相同的 HASH 算法对启动镜像计算 HASH 值,常用的 HASH 算法有 SHA-256 等。接着通过公钥对签名文件进行解密得到 HASH 值。两个 HASH 值进行比较,如果一致,说明验签校验通过,验证了启动镜像的身份,镜像可以加载;否则镜像可能被篡改,不能被加载。图3.4-10 安全启动公私钥对生成流程在 SOC 系统中安全启动所用的启动镜像、启动镜像签名文件、公钥摘要、公钥通常

    168、在线下可信环境中制作。通过 HSM(Hardware Security Model,硬件安全模块)生成公私钥对,并通过 HASH 算法计算出049公钥摘要。其中,公钥摘要需要在出厂前灌装到 OTP 区域,然后使用私钥对启动镜像进行签名,得到签名文件。3.4.7 身份鉴别身份鉴别技术是我们大多数人最熟悉的安全技术,在各种信息系统中,身份鉴别通常是进入系统获得系统服务所必需的第一道关卡,确保身份识别的安全性对系统的安全至关重要。身份鉴别的目的是确认用户身份的合法性以及用户间传输信息的完整性与真实性,是最基本的安全技术也是最重要的安全技术,因为其他安全技术(比如权限控制、安全审计等)都要依赖用户身份

    169、信息,如果身份信息不可信,安全就失去了根基。身份鉴别的核心理论都是通过 3 个问题来识别确认身份:你知道什么,你拥有什么,你的唯一特征是什么。你知道什么,就是根据你知道的信息来证明你的身份。核心在于你知道的信息一定是保密的,别人不知道或难以猜测的。你拥有什么,就是根据你拥有的东西来证明你的身份。核心在于你拥有的东西一定是有特征的,可以被对方辨识并认可的东西。你的唯一特征是什么,根据你的唯一特征来证明你的身份。核心在于你具有唯一的生物特征,这个生物特征可以准确对应到你这个人。基于上述 3 个核心理论,并伴随着科学技术的快速发展,以及计算机与光学、声学、生物传感器和生物统计学等高科技手段的综合运用

    170、,衍生出了多种多样的身份鉴别技术,其中车载系统中常用的技术包括:1.口令这是靠“你知道什么”来验证身份的鉴别技术。依靠密码来进行身份鉴别是最基础的鉴别技术,也是适用性最广的技术。现在虽然有了其他多种身份鉴别技术,在多因子认证方案里,基于密码鉴别身份也是其中必选的基本技术。2.数字证书这是靠“你拥有什么”来验证身份的鉴别技术。数字证书就是互联网通讯中标志通讯各方身份信息的一系列数据,其中包含了持有者的信息、公钥以及证明该证书有效的数字签名。3.动态令牌这是靠“你拥有什么”来验证身份的鉴别技术。动态令牌(OTP,One time password)是客户手持用来生成动态密码的终端,主要基于时间同步

    171、方式,每隔一定周期变换一次动态口令,口令一次有效,它产生一个动态数字进行一次一密的方式认证。4.短信验证码这是靠“你拥有什么”来验证身份的鉴别技术。身份认证系统以短信形式发送随机密码到客户的手机上,客户在登录或者交易认证时候输入此动态密码,从而确保系统身份认证的安全性。5.蓝牙钥匙这是靠“你拥有什么”来验证身份的鉴别技术。蓝牙钥匙具有硬件加密功能,有较高的安全性。这是一种基于公钥密码的身份认证技术,蓝牙钥匙中常保存着用户的证书(公钥)和密钥(私钥)。6.指纹认证这是靠“你的唯一特征是什么”来验证身份的鉴别技术。指纹是指手指末端正面皮肤上的凸凹不平的纹路,这些纹路包含大量的信息。这些皮肤的纹路在

    172、图案、断点和交点上各不相同的,这些信息就是“指050纹特征”,指纹特征具有唯一性和永久性,通过比较指纹特征,就可以验证一个人的真实身份。7.声纹认证这是靠“你的唯一特征是什么”来验证身份的鉴别技术。所谓声纹(Voiceprint),是用电声学仪器显示的携带言语信息的声波频谱。每个人的语音声学特征既有相对稳定性,又有变异性。由于每个人的发音器官都不尽相同,因此在一般情况下,人们仍能区别不同的人的声音或判断是否是同一人的声音。下面以基于 RSA 非对称算法的诊断协议 0 x27 服务认证应用实例为例,描述工具对车载 ECU 进行访问的整个认证流程。车载系统需要判断外部接入设备是否具有访问权限,不同

    173、的功能根据其重要性配置不同的权限等级,想要执行相关功能需要经过相应层级的权限认证,通常会采用 UDS 的 0 x27 服务来验证访问权限,如 FOTA 升级,参数修改,信息查询等应用,接入设备只有经过授权后才允许对 ECU 进行相应的操作。图3.4-11 0 x27认证应用实例051(1)当 Tool 设备接入车载网络时,服务器端会先使用内部的密钥对 Tool 的身份信息进行验证,若Tool 身份验证通过后,后续 Tool 与服务器之间的信息交互会使用 TLS 技术对交互数据进行加密。(2)设备与服务端之间认证完成之后,Tool 设备向 ECU 发送请求设备 ID 的指令。(3)ECU 将其自

    174、身的设备 ID 发送给 Tool。(4)Tool 向 ECU 设备请求包含有 Level 等级的 Seed。(5)ECU 收到请求后,在内部使用零件号和计数器生成一个 SecretSeed,然后使用公钥对 Secret-Seed 进行加密,发送给 Tool。(6)Tool 收到 ECU 的设备 ID 和加密后的 SecretSeed 后连同解锁请求发送给服务器。(7)服务器端根据收到的 Tool 发送来的设备 ID,在内部寻找对应的私钥对 SecretSeed 进行解密,解密成功后使用私钥对 SecretSeed 进行签名发送给 Tool,Tool 再将签名后的 SecretSeed 发送给

    175、ECU。(8)ECU 使用公钥进行验签,并将验证结果返回给 Tool,如果验证通过,则 Tool 可以对 ECU 进行相应 level 下的访问,否则 ECU 仍处于上锁状态,不被允许访问。身份鉴别技术主要的发展方向有两个:一是用户接口(UI),主要是人机交互鉴权;另一个是机器的全自动鉴权,包括:进程、芯片、控制器等。用户身份鉴别目前主要是通过车钥匙、人脸、密码等方式,对用户的使用过程是有感知的。未来身份鉴别的方向应是让用户更少的感知身份识别,减少钥匙、密码这类的操作和输入,通过快速的生物识别方式识别用户合法性和配置映射,用户从接近车辆到进入车辆后车辆加载用户配置无需用户参与。对于设备(如车载

    176、 ECU、路侧 RSU 等)的接入认证,一项正在研究的技术是基于其独特的、唯一的物理指纹特征进行身份验证。机器鉴权目前在设备上的鉴权主要依赖于证书、密钥和访问仲裁,例如:在通讯中一般会依赖 TLS、SecOC 等通讯协议的认证、校验流程;进程权限、访问权限则由访问控制模块进行鉴权;在证书和密钥更新方向没有统一的方法,PKI 等系统的全自动化更新证书、密钥也没有统一规范的方案。未来应在机器鉴权方向重点做自动化更新鉴权证书和密钥的方案,并统一规范。3.4.8 访问控制访问控制是操作系统安全控制保护中重要的一环,在身份鉴别的基础上,根据身份对提出的资源访问请求加以控制,其模型如下图所示。图3.4-1

    177、2 访问控制模型 主体:即访问操作的执行者,一般指进程。客体:即主体需要访问的资源,一般指文件、设备、服务等系统资源,在访问操作后,客体的内容可能被改变。操作:访问中主体对客体的操作,如文件的读、写、执行;设备使用;服务访问等。052 访问控制规则:规定了主体可以对哪些客体执行什么访问操作、客体由哪些主体执行什么访问操作。访问控制即是在主体对客体进行访问操作前,根据访问规则对主体的权限进行检查,确定主体有权执行后续的访问操作,并阻止主体的越权访问。目前常用的访问控制可分为自主访问控制和强制访问控制两大类。自主访问控制让客体的所有者来定义访问控制规则,管理员理论上不需要对访问控制规则进行维护。强

    178、制访问控制将主体和客体划分成不同的安全级别和类型,对每一类主体进行规则制定,规定其有权访问哪些级别或类型的客体,并拒绝所有非授权的访问。强制访问控制的规则(策略)通常由管理员制定,主体和客体的所有者无权修改规则。下面以 Linux 系统为例对自主访问控制(DAC)和强制访问控制(MAC)进行说明。1.Linux 系统 DACDAC 提供了基于 owner、group、other 角色的访问权限控制能力,基于角色可以控制对文件的读、写、执行权限。Linux 系统对其每一个用户都赋予一个用户 ID(UID);并可以设定用户组,每个用户组可以赋予一个用户组 ID(GID),一个用户可以归类于多个不同

    179、的用户组。操作系统中的进程由用户执行,所以每一个进程都属于一个用户,也可以属于该用户对应的用户组,于是操作系统可以获得该进程的 UID和 GID。通过 UID 和 GID,操作系统即可识别进程(访问控制主体)的身份和类型。Linux 系统中的文件(或文件夹)属于其创建用户,也可以设定属于某一个用户组。DAC 权限系统依此将文件(访问控制客体)的操作者分成三种类型:即文件的所有者(user)、文件的所属组的用户(group)和其他用户(other,其他用户,为不属于 user 和 group 用户的所有用户)。对于文件的访问操作,DAC 系统将其分为读、写、运行三种类型,对于每一个文件,都规定好

    180、 user 用户可以执行什么操作、group 用户可以执行什么操作,以及 other 用户可以执行什么操作。而文件所属的用户,则可以自由更改文件的访问操作权限,例如对一个文件增加 group 用户的写权限,取消 other 用户的读权限等等。这样在操作系统运行时,既可通过 UID 和 GID 来确定一个进程的身份,也可以根据文件的权限设定确定该进程对于一个文件来说属于哪种用户(user、group 还是 other),进而确定该进程是否可以对该文件执行所请求的操作。可以看出,DAC 权限的控制策略非常简洁,所以其 DAC 检查的系统开销非常小。但是它的问题是其对客体类型和访问操作的划分粒度过大

    181、,操作系统中的各类资源,如设备、服务、套接字等,都统一划归为文件,而访问操作类型也只划分为读、写、运行三大类,这样很难实现精细管理。另一方面,Linux 系统中还存在 root 用户,该用户相当于管理员,有所有文件的一切操作权限,并可修改任意文件的归属和访问权限,这为访问控制管理带来了极大的风险,当攻击者获取了 root 权限,DAC 权限系统即被攻破。DAC 权限系统的广泛的应用于车载系统之中,它既用于嵌入式 Linux 系统,也用于基于 Linux 的Android 系统,很多其他操作系统中也有类似于 Linux 的 DAC 权限系统。2.Linux MAC随着芯片性能的提高,车载系统已经

    182、可以提供更多的硬件性能和系统开销,这样,为了弥补 DAC 权限系统的缺点,强制访问控制系统也被引入车载系统。MAC 提供了对系统资源访问的更高安全能力,此安全机制是限制了用户(Subject)对自己所创建的对象(Object)所拥有的“控制级别”。与 DAC 不一样,在 MAC 中,对所有的文件系统 Objects 增加了额外的 Labels 或 Categories。在 Subjects(用户或进程)与 Objects 交互之前,它们必须对这些 Categories 或 Labels 进行合适的访问(即先要进行权限判断)。对访问的控制彻底化,对所有的文件、目录、端口的访问,都是基于策略设定的

    183、。这些策略是由管理员设定的、一般用户是无权更改的。053强制访问控制系统的代表为 SELinux,它支持多种安全策略模型,支持策略的灵活改变,使用类型增强(TE)、基于角色的访问控制(RBAC)和多级安全技术(MLS)保证系统安全。SELinux 最初由美国国家安全局(NSA)实现的强制访问系统,其可以作为安全子系统运行在 Linux、Android 或其他类似操作系统中。SELinux 中的访问控制主体也是操作系统的进程,但与 DAC 权限系统不同的是,SELinux 根据进程本身进行主体类型划分,而不是简单的将进程归类于启动它的用户。SELinux 对每一个进程根据其执行文件进行类型标记,

    184、基本上每一个可执行文件的访问控制主体类型都不同,而多个不同的主体类型也可以标记归类于一个大类(类似与 DAC 中的组)。比如在采用 SELinux 的 Android 系统中,每一个可执行程序或守护进程都被标记成一个独立的类型,这些进程同时也可以标记归类于 coredomain(核心域)、ap-pdomain(应用域),或根据其网络功能标记为 netdomain(网络域)、根据其应用签名标记为 platform_app(平台应用)等等。对于操作系统中的资源,SELinux 进行了细致类型划分,访问控制的客体被划分为文件、文件夹、服务、系统参数、设备等等,操作系统的每一个文件、每一个服务都被归类

    185、于一个客体类型,或者可以单独为该项资源定义一个客体类型(另外进程类型作为访问控制的主体的同时,也可以作为访问控制的客体)。与访问控制的主体一样,多个客体类型也可以被归类于某一个大类。而对于访问控制的操作,SELinux 首先明确操作目标的类型,而后再根据操作目标划分出所有可行的操作。比如如果操作目标是文件,那么操作类型可以是读、写、执行等等;但如果目标是文件夹,那么操作类型可以是读、写、查找等等,但无法是执行。这样访问操作的类型可以涵盖操作系统中所有资源的操作子类,使精细化管理成为可能。在明确了访问控制的主体、客体、与操作类型之后,就可以制订访问控制的策略(规则)。SELinux的访问控制策略

    186、规定了哪些主体可以对哪些客体的什么操作目标进行什么样的操作。比如,可以规定主体 kernel 允许对客体 app_data_file 的操作目标 file 进行读操作(策略条目为:allow kernel app_data_file:file read)。操作系统中每一项允许主体对客体的操作,都需要有相应的 SELinux 访问策略条目规定,否则就不符合访问控制策略。在 SELinux 开启的操作系统运行中,违背访问控制策略操作会被操作系统拒绝执行。在车载系统中,SELinux 的访问控制策略一般需要在操作系统编译之前制订好,与操作系统源码一同编译,且与操作系统的镜像一起下载至车载设备中。正常

    187、情况下,车载系统运行时,SELinux 的访问控制策略无法被改变。这样,即使攻击者获取了操作系统的超级用户身份,其操作权限仍旧被限制在 SELinux访问控制策略规定的范围内,大大提高了操作系统的安全性。总的来说,以 SELinux 为代表的强制访问控制系统,与 Linux DAC 为代表的自主访问控制系统相比,其安全性大大提高;但需要更多的维护成本来精细化定义访问控制策略,同时也牺牲了系统的自由度,并需要比 DAC 系统更多的系统资源。在实际的车载系统中,由于车载芯片功能的增强,以及人们安全意识的提高,强制访问控制系统与自主访问控制系统常常共同存在于操作系统中,共同执行系统的访问控制规则,维

    188、护系统安全。DAC和MAC访问控制技术各有其优缺点,在实际的Linux系统中往往同时被部署,在系统执行控制时,一般先检测 DAC 规则,如果能通过,就继续执行 MAC 机制,只有在 DAC/MAC 检测同时通过的前提下,主体才被允许执行访问客体的操作。054图3.4-13 访问控制流程鉴于目前国内自主研发操作系统逐步崛起,业内建议设计统一的简易操作系统权限管理系统,且对应用层用 Hook 的模式提供仲裁接口,以便基础软件平台的信息安全模块处理仲裁。根据目前的使用场景,操作系统的权限仲裁接口应满足以下的功能:提供用户空间的应用层 API 接口,以供用户空间的仲裁进程处理仲裁逻辑。Hook 收到访

    189、问请求后,应将请求内容传给仲裁进程注册的回调函数进行仲裁。仲裁回调应分为文件类、网络类等。仲裁范围应可控制进程-文件、进程-网络、进程-进程等。3.4.9 安全监测智能网联汽车安全监测是为车联网中车辆、终端设备、云端平台等构建以主动防御为核心的,以数据为驱动的车联网安全监测平台,以应对复杂的“人-车-路-云”系统协同下的车联网环境,通过各类数据的关联分析,利用人工智能等先进技术感知正在攻击或已经发生攻击的安全事件,实施主动防御机制,实现事件快速感知定位,同时做到快速响应安全事件,降低攻击带来的直接和间接损失,保护未来出行的健康发展。智能网联汽车安全监测应由车载安全探针(又称入侵检测与防御系统

    190、IDPS)和车辆安全运营中心(VSOC)两部分组成,以车联网安全监测系统形式对车辆网络安全威胁进行监测和防御,有效的实现外防和内控,保障车联网生态下的全面信息安全。其中车载安全探针(IDPS)负责采集安全数据,可本地化分析和执行预置安全策略,并与车联网安全监测平台进行深度关联。安全服务人员利用采集的安全数据结合云端情报对事件进一步研判,若决定启动应急处置流程,可通过OTA形式更新策略下发给车端探针,优化采集、分析与安全策略,形成闭环。1.车载安全探针 IDPSIDPS 包括网络入侵检测(IDS)、文件完整性检测、系统安全检测、应用监测、系统清单监测、报文检测、安全日志(Security Log

    191、ger)和防火墙等模块,集成 HIDS(主机型)、NIDS(网络型)和 EDR 能力,并对网络攻击具备阻断(Prevention)能力,为车载 ECU 提供网络攻击检测、安全审计、基线评估以及网络攻击拦截等功能,可借助安全日志模块,支持对整车控制器搭载业务系统(PKI、SecOC、OTA、安全055启动等安全中间件)日志进行收集、分析。安全探针与安全运营中心实时协作,将监测的安全事件、日志、资产信息实时上报车辆安全运营中心,为平台安全分析、溯源提供基础数据支撑。同时借助可动态配置的安全规则库,持续动态对安全事件监测分析结果降噪、调优,能够将车辆网络安全攻击事件误报、漏报率降低至 5%以下,并实

    192、时响应平台的安全策略、应急响应指令,保护车载控制器安全。图3.4-14 车载安全探针IDPS2.车辆安全运营中心车辆安全运营中心提供安全大数据处理能力,对车载安全探针上传的日志、安全告警等数据进行解析、标准化、丰富化、检索、计算、管理等,整体由安全运营系统、安全分析系统和数据管理系统组成,通过三个系统协作,为车联网环境构建一套监测、感知、分析、处置系统,从而对车联网安全威胁、攻击事件进行实时监控、提前预判,为车联网系统的安全建设与运营提供动态的安全保障。图3.4-15 车联网安全运营中心056(1)安全运营系统安全运营系统提供包含安全概览、资产管理、安全事件、风险预警和应急响应、策略管理、系统

    193、管理在内安全运营服务。其中,事件告警安全运营团队进行人工及自动化方式进行持续安全监测能力支撑。图3.4-16 安全运营系统(2)安全分析系统安全分析系统是安全监测平台将安全分析概念进行独立设计,从实际运营需求出发涉及多样化安全分析能力,从而实现多维度对威胁攻击进行全方位的检测和分析、自动化安全编排响应、多场景防御能力评估等目标。图3.4-17 安全分析系统057(3)数据管理系统数据管理系统是针对车载联网终端进行核心安全数据采集,通过采集将获取车载联网终端的安全事件监测数据,用于发现针对整个联网汽车的攻击行为,为反映整个车载终端的宏观安全态势提供数据支撑。数据管理系统需要将采集的海量数据通过可

    194、及时配置后清洗形成符合数据标准的统一格式,并存入支持结构化和非结构化数据的大数据存储框架进行数据的长周期存储。图3.4-18 数据管理系统通过车联网安全监测平台的大数据处理集群的能力,采用数据“采集-存储治理-分析-应用”分层体系架构,结合对安全数据进行集中统一的收集和数据格式处理,利用大数据技术手段,构建多维、立体化数据分析模型。同时将开源漏洞、威胁情报赋能体系引入本地安全监测平台安全应用之中,实现本地网络安全数据与云端安全大数据深度融合,将数据管理系统所采集的海量日志、流量等元数据与威胁情报信息进行碰撞,发现潜在的风险,并针对车载联网终端,通过对开源漏洞库进行监控,匹配公开漏洞对应的 CP

    195、E(Common Platform Enumeration),定位资产是否存在被漏洞利用的可能性。从而从多个维度、多个层次实现对被保护目标实时安全监测分析,有效发现隐蔽或高级攻击威胁,实现汽车信息安全防护切实有效的安全监测。3.4.10 系统日志管理基础软件系统的日志管理包括了对操作系统内核、中间件基础软件、应用系统等运行日志数据的记录、存储、分析和处理,特别是对关键安全事件的管理。一方面,通过对运行日志的实时监测,可以实现整车系统安全状态的监控。日志管理可以帮助将有关活动的原始日志数据转换为有关安全或性能问题的可操作信息,还可以提高数据的安全性和优化性能。另一方面,在受到外部攻击时,可以对攻

    196、击行为和足迹进行溯源。日志是整车系统安全结构中的一个重要内容,它是提供攻击发生的唯一真实证据。通过对安全审计的策略设置,可以提供整车系统安全的可追溯能力,进而通过对日志的分析找出整车系统存在的安全漏洞并进行安全治理,提升整车系统的安全性。058系统日志管理经常会面临以下的风险。1.容量汽车整车软件系统在运行过程中会持续产生日志,而基础软件系统的容量通常是受限的,因此需要考虑日志数据的存储空间,需要能及时上传到云端服务器,避免日志数据的丢失。2.保密性日志数据经过分析产生的安全事件很有可能涉及到用户的隐私数据和基础软件系统的机密数据,因此在保存和传输过程中必须保证数据的保密性,以免被非法访问。3

    197、.完整性日志数据及产生的安全事件记录被非法篡改,造成后续问题定位及溯源的困难。日志管理需要管理操作系统内核、中间件基础软件和应用系统的日志,其系统架构可以参考下图:图3.4-19 日志系统的架构图在基础软件系统中操作系统内核通常会提供日志管理的两个服务:其一是日志服务(例如 Linux 的rsyslog 系统),用来记录系统中的各种信息,如安全、调试、运行信息等,并通过日志设置提供日志存储安全策略。其二是审计服务(例如 Linux 的 audit 服务),审计服务专门用来记录安全信息,用于对系统安全事件的追溯,同时可提供配置安全事件记录策略。AutoSAR AP 基础中间件也提供 Log an

    198、d Trace 管理和检测 AUTOSAR 自适应平台的日志记录功能,可以在开发期间以及生产中和生产后使用日志记录和追踪功能。Log and Trace 组件允许灵活的检测和配置日志记录,可以根据配置将日志记录信息转发到多个接收器,例如通信总线、系统上的文件和串行控制台。AutoSAR AP 所提供的日志信息标记有严重性级别,并且可以对 Log and Trace 组件进行配置,使其仅在特定严重性级别上记录信息,以便在日志记录客户端实现复杂的筛选和直接的问题故障检测。对于每个严重性级别,AutoSAR AP 提供了一种单独的方法,供应用程序或功能集群使用。AUTOSAR AP平台和日志记录功能

    199、集群负责维护平台稳定性,以免系统资源过载。为了保证溯源的便利性,建议对日志系统数据内容和功能需求形成行业要求。在数据内容方面,整车软件系统生成的安全事件记录应包括安全事件的主体、客体、时间、类型和结果等内容。生成的安全事件应包括以下事件:身份鉴别、自主访问控制等安全功能的使用;创建、删除客059体的操作;网络会话;所有管理员的操作,身份标识和鉴别事件类审计记录应包括请求的源(如末端号或网络地址)。创建和删除客体事件的审计记录应包括客体的名字。网络会话事件审计记录应包括:网络程序名称、协议类型、源地址、目的地址、源端口、目的端口、会话总字节数等字段。在功能需求方面,基础软件系统应提供系统日志的查

    200、询功能,支持按条件或逻辑组合进行选择和排序查阅,并能导出查询结果。基础软件系统应提供审计日志的保护功能:保证审计机制默认处于开启状态,且对审计日志的开启和关闭进行保护;保护审计日志不被未授权的访问;保证审计日志不被篡改和删除。审计日志应存储在掉电非遗失性存储媒体中,系统管理员应能定义超过审计跟踪存储极限的阈值,当超过阈值时将向管理员报警。当审计存储空间被耗尽时,应覆盖所存储的最早的审计记录。基础软件系统应支持日志上传功能,上传时对云端进行认证,根据云端管理需求,采取安全的方式传输日志,确保数据的完整性和可认证性。基础软件系统应采取访问控制机制,对日志读取写入的权限进行管理,对日志存储进行安全防

    201、护。3.4.11 虚拟化安全汽车电子电器架构正从分布式到域集中式架构到中央集中式架构转变,支撑架构转变的重要因素之一是算力平台。随着算力平台的能力增强,通过虚拟化技术,将不同功能安全等级的系统部署到同一个硬件平台上是一个趋势,虚拟化技术按照虚拟化层次可以分为硬件虚拟化和操作系统虚拟化两类。硬件虚拟化可细分为 Type1 和 Type2 两类,Type1 类型的虚拟机,直接运行在裸硬件上,比如 XEN;TYPE2类型的虚拟机,驻留在 OS 的内核,比如 KVM。在汽车领域,由于对功能安全等级及实时性有较高要求,一般均使用 TYPE1 虚拟机管理器(Hypervisor),Hypervisor 之

    202、上直接运行多个客户操作系统(GuestOS),实现对资源的隔离和调度。操作系统虚拟化一般指容器技术,通过内核提供的 Namespace 和 Cgroup 等资源隔离和配额管理机制实现对多系统运行能力的支持,在这种虚拟化机制下,操作系统内核被每个容器共享。目前容器化场景在汽车中还没看到实际应用,下文所述虚拟化安全主要指虚拟机管理器 Hyper-visor 的安全。随着虚拟化技术在汽车上的商用化加快部署,虚拟化安全性正日益得到产业的关注。这些安全性包括:虚拟机管理器和虚拟机之间的信任链问题。利用虚拟化技术在一个可信物理平台上创建出多个虚拟机,并将从硬件可信根开始构建的信任链传递到每一个虚拟机,从而

    203、在一个可信物理平台上构建多个虚拟的可信计算平台,有些解决方案缺乏虚拟机管理器到虚拟机之间的信任链验证。虚拟机间的攻击:恶意入侵者可以通过利用虚拟机管理程序中的漏洞,通过同一物理主机上存在的另一个虚拟机来获得对虚拟机的控制,从而破坏目标虚拟机。虚拟机资源掠夺:系统或应用程序中存在的漏洞会导致整个系统的异常行为,他们利用系统资源,导致同一主机上的其他虚拟机出现饥饿或故障。虚拟机逃逸:利用虚拟机软件或者虚拟机中运行的软件的漏洞进行攻击,以达到攻击或控制虚拟机宿主操作系统的目的。虚拟机回滚:虚拟机可以回退到以前的状态,有害病毒/蠕虫可能将受感染的虚拟机回滚到以前的状态,在回滚时,虚拟机会将其重新暴露给

    204、安全漏洞。Hypervisor 自身漏洞:导致虚拟机信息被窃取或篡改。为了提高 Hypervisor 的安全性,建立相应的安全性目标很重要,相关要求目标如下表所示:060表3.4-1 Hypervisor的安全性目标安全目标要求隔离性vCPU 调度隔离安全、内存隔离、网络隔离、存储隔离物理资源可被唯一指定分配给虚拟处理器,资源包括:SOC 的某个或某几个 CPU 核、SOC 的一段连续或不连续的内存、SOC 的外设寄存器(如串口、USB)、SOC 的中断资源(可直接绑定到 vCPU 核某个 Guest OS 上,通过 Hypervisor 透传)Hypervisor完整性为了实现整体系统完整性

    205、,建立并维护 Hypervisor 组件的完整性。平台完整性Hypervisor 的完整性取决于它所依赖的硬件和软件的完整性,需要利用加密芯片(如TPM)等硬件和固件机制来保护和检测底层平台的完整性。如果平台完整性受到损害,Hypervisor 和客户机将无法运行。Audit支持安全审计功能,可捕获和保护系统上发生的事件,以便安全复盘。Hypervisor 的安全性能力可以从三个维度进行提升。一是需要建立安全边界,这个边界由 Hypervi-sor 严格定义并且实施。Hypervisor 安全边界的保密性、完整性和可用性需要得到保证。边界能防御一系列攻击,包括侧向通道信息泄漏、拒绝服务和特权提

    206、升。虚拟机监控程序安全边界还提供网络流量、虚拟设备、存储、计算资源和所有其他虚拟机资源的隔离能力。图3.4-20 虚拟机监控程序安全边界安全边界的保密性可以通过传统的密码学方法来实施,完整性通过可信度量机制来保障,可信报告机制实现不同虚拟环境的可信互通,监控机制动态度量实体的行为,发现和排除非预期的互相干扰。虚拟技术提供的隔离机制将实体运行空间分开。整体虚拟化安全架构如下图。061图3.4-21 虚拟化安全架构安全边界的隔离通过Hypervisor的vCPU调度隔离安全、内存隔离、网络隔离和存储隔离技术来支持,实现了同一物理机上 Hypervisor 和虚拟机之间的隔离。vCPU 调度隔离安全

    207、:处理器架构为了保护指令运行,提供了指令运行的不同特权级别,X86 架构有 Ring0-3 四个级别,Ring0 安全级别最高,一般运行操作系统,Ring3 最低,运行应用;ARM 架构有 EL0-EL3 四个级别,EL3 安全级最高,Hypervisor 运行在 EL2,GuestOS 运行在 EL1,应用运行在EL0。各个级别可运行的指令是不一样的,Hypervisor 运行在 Ring0 或 EL2,负责 vCPU 的上下文切换,能有效防止 GuestOS 运行特权指令,实现了 Hypervisor 和 GuestOS 的隔离;应用程序运行在 Ring3 或EL0,实现了 GuestOS

    208、 和应用的隔离。Hypervisor 也支持虚拟机和 vCPU 绑定,使得 GuestOS 运行在独立的 vCPU(组)上,实现了 GuestOS 间的隔离。内存隔离:X86 和 ARM 架构均支持 MMU 技术,MMU 实现了虚实地址的映射。在 Hypervisor 虚拟化架构下,GuestOS 虚拟地址到物理地址的映射由 Hypervisor 来实现,Hypervisor 可以使 GuestOS 的虚拟地址映射到不同的物理内存段上,保证了 GuestOS 间的内存隔离。网络隔离:从 GuestOS 接收或发动的数据包都会经过 Hypervisor,通过在 Hypervisor 中支持虚拟的

    209、防火墙及路由器功能,可以实现数据包的过滤和完整性检查,结合数据包标签及许可证,可实现 Gues-tOS 间网络数据隔离。存储隔离:Hypervisor 架构下的设备驱动可划分为前端驱动程序、后端驱动程序和原生驱动三个部分,062其中前端驱动在虚拟机中运行,而后端驱动和原生驱动则在 Hypervisor 中运行。虚拟机的 I/O 请求通过前端驱动会传递到 Hypervisor 中的后端驱动,后端驱动解析 I/O 请求并映射到物理设备,提交给相应的设备驱动程序控制硬件完成 I/O 操作。这种模型下,虚拟机所有的 I/O 操作都会由 Hypervisor 截获处理,Hypervisor 保证虚拟机只

    210、能访问分配给它的物理磁盘空间,从而实现不同虚拟机存储空间的安全隔离。二是需要建立深度防御漏洞的缓解机制。对于安全边界存在的潜在漏洞,Hypervisor 需要有一定的技术手段进行主动防御,这些技术手段包括地址空间布局随机化(ASLR)、数据执行保护(DEP)、任意代码保护、控制流保护和数据损坏保护等。三是建立强大的安全保障流程。与 Hypervisor 相关的攻击面包括虚拟网络、虚拟设备和所有跨虚拟机表面,所有虚拟机攻击面建议都实施威胁建模、代码审核、模糊(fuzzed)测试,通过建立自动化构建及环境,触发定期安全检查。虚拟化技术作为云计算场景的重要技术,在 10 多年的生产实践中已经积累了很

    211、多安全范式,这些经验也可被汽车场景借鉴。但是与云场景相比,汽车场景的虚拟化技术也有其特殊性,如虚拟机不需要动态迁移/创建,Hypervisor 有功能安全等级的要求等等,其安全性手段需要在实践中不断丰富和完善。3.4.12 TEE 可信执行环境智能网联汽车的发展,带动了面向服务体系架构(Serivice-Oritened Architecture)的推广,目前作为 SOA 载体的操作系统代码庞大、业务数量多、车内外通信复杂,导致漏洞风险也就越大。如果系统被非法入侵和破坏,如何保护 SOA 架构下的安全资产,已成为车载的主要安全课题。解决这种课题的思想是在开放的环境里创建隔离的环境,在这个环境中

    212、,即使操作系统受到破坏,安全资产也会受到保护,这就是我们所说的可信执行环境。可信执行环境(Trusted Execution Environment)是 CPU 芯片层面上单独划分出来的一片“区域”,是独立于 REE(Rich Execution Environment,例 Linux、Android、AUTOSAR 等系统)而存在的可信的、隔离的、独立的执行环境,与 REE 并行运行。TEE 可给数据和代码的执行提供一个更安全的空间,并保证它们的机密性和完整性,对安全性要求更高的业务(如身份认证、密钥证书保护、安全支付等)可部署到 TEE 中。目前各主流的芯片厂商均支持 TEE 技术,下表是

    213、对主流 CPU TEE 技术的比较。表3.4-2 主流CPU TEE技术的比较厂商/架构隔离技术度量支持运行态内存加密隔离区ALLTPM/TCMNAIntelTXTNASGX1/SGX2(self)UTDXK/U(VM)AMDSMENASEV(-ES)K/U(VM)063厂商/架构隔离技术度量支持运行态内存加密隔离区ARMTrust-ZoneEL0-3RealMEL0-3RISC-VSPMP/SMPUS/M飞腾FT2000/2500ARMv8架构Trust-ZoneEL0-3海光CSV(China Security Virtualization),类同 AMD SEV,海光内存加密技术 SME

    214、(Se-cure Memory Encryption)使用 SM4 国密算法,加密每次写入内存的数据。在 面 向 消 费 类 电 子 及 车 载 场 景 中,ARM 架 构 的 CPU 占 据 主 导 地 位,下 面 重 点 描 述 基 于ARMTrustZone 的 TEE 技术。TrustZone 技术是 ARM 公司为了解决可能遇到的软硬件安全问题提出的一种硬件解决方案。其关键设计思想就是硬件隔离,包括片上和片外的 ROM/RAM 隔离、外设隔离、CPU 核隔离、中断隔离和内存隔离等。基于这种硬件架构设计的 TEE,能在很大程度和范围内保证系统的安全性,使软硬件破解都变得相对困难。201

    215、0 年国际组织 GP(Global Platform)发布了 TEE 规范和应用开发的接口规范,目前的开源或商业版 TEE OS 都支持该规范,方便基于规范开发的可信应用(Trusted Application,TA)在不同的 TEE 移植。TEE 主要安全特性包括:硬件机制保护:TEE 物理隔离于 REE、TEE 可以访问 REE 的内存、REE 无法访问受硬件保护的TEE 内存,只能通过特定的入口与 TEE 通信。三层隔离机制:支持 TEE 和 REE 间隔离,TA 间相互隔离,TA 和 TEE 内核间隔离。支持多 TA 运行:TEE 中可以同时运行多个 TA,服务于 REE 侧的安全应用

    216、。支持安全启动:TEE 和 TA 中的可执行代码在执行前先要被验证。安全存储机制:存储证书密钥等重要数据,满足认证性、完整性和机密性需求。高性能运行:TEE 运行时独占 CPU 核的全部性能,TA 运行完释放 CPU 资源。灵活易扩展:TEE 存储、运行空间可定制,TA 支持静态、动态加载,易于开发维护。开发接口规范化:遵从国际 GP 标准,安全应用可在多种平台上移植。适配 AUTOSAR 接口:AUTOSAR 安全需求组件可通过 TEE 实现,在 REE 侧适配 AUTOSAR 标准接口,例加解密组件、更新管理组件等。基于 TEE 系统的软件栈主要组件如下图所示。064图3.4-22 基于T

    217、EE系统的软件栈组件软件栈主要由 REE、TEE、安全后台、产线工具组成。客户端应用运行在 REE 侧,调用 TEE Client API,再通过 REE 通信代理和 TEE 通信代理实现与 TEE 环境的交互,对应的 TA 完成特定安全功能。安全后台主要负责可信服务的后台业务逻辑,实现端到后台的闭环安全流程,例如设备管理、密钥管理、软件更新等功能。产线工具主要负责设备信息的导入导出,包括根证书密钥等信息。TEE 主要提供运行环境、可信基础服务、通用可信应用、客户客制化可信应用,TEE 运行环境一般采用 Trusted Kernel 实现。可信基础服务基于Trusted Kernel开发,基于

    218、这些可信基础服务提供满足GP规范要求的TEEInternalAPI接口,用于开发通基础业务和客户客制化业务。可信基础服务主要功能说明如下:表3.4-3 可信基础服务主要功能基础服务功能说明安全存储为数据提供加密存储或可信存储区域,保证数据的机密性和完整性,防止数据被非法篡改或非法获取。加密密钥动态生成且不出可信安全域。安全加解密支持国际或国密算法,包括对称密码算法、公钥密码算法、散列密码算法等。可支持芯片内置加解密引擎或外接加解密硬件模块。安全时间提供不能被非法篡改的时间接口,仅存于安全可信环境下,主要用于安全日志、视频数据等可审计的场景。真随机数支持在可信环境下获取硬件产生的随机源,且在 R

    219、EE 侧无法获取此随机源。主要用于密码算法的随机因子。安全校验检查安全应用 TA 加载时的镜像完整性和真实性,确保未被非法篡改。065基础服务功能说明密钥管理为每个安全应用 TA 随机产生共享密钥,保护各 TA 的数据,且 TA 间互不可见密钥。可信根绑定硬件唯一标识信息,运行阶段生成。在可信环境下可以获取此信息,且各设备都不同且唯一。安全驱动外部设备仅允许 TEE 侧的访问(例 SPI、UART、I2C 等),而 REE 侧无法访问。TEE 技术目前已成为移动终端的标配,不仅提供了合适的保护强度,也平衡了成本和易开发性,并日趋成熟。其安全性、稳定性、灵活性、扩展性越来越得到车企的重视,随着车

    220、载的安全合规性要求和车企的主动防御需求,TEE 技术也为车企提供了更多的选择,目前 TEE 技术已应用在车载的信息娱乐系统、中央计算单元、车联网系统等部件中,以保护设备的安全资产,相信 TEE 技术会在今后的车载信息安全上发挥更大的作用。图3.4-23 TEE技术架构3.4.13 加密芯片应用随着信息安全需求的增加,在业务正常运行的情况下,SoC/MCU 已无法满足纯软加密对资源的需求,且关键数据和密钥的安全存储依赖加密芯片或 SoC/MCU 内置可信安全存储区。目前常见的解决方案一种是 SoC/MCU 内置加密模块和可信安全存储区,满足加密算法加速和可信存储的要求;另一种则是在芯片外挂专用的

    221、高性能加密芯片,通过 SPI 等总线与芯片进行数据交互。芯片上内置的加解密模块普遍性能偏低,一般只有对称加密算法和哈希算法。非对称加解密的数据需求是无法被满足的,但芯片内置的加密模块不会有与业务芯片通讯总线被监听的拆件破解风险。内置加密模块一般用于可信启动和高安全要求的加解密计算的应用中,具体场景包括:可信启动:一般使用可信安全存储区,将用于校验 BootLoader 和 OS 等关键初始启动部分的证书/公钥存入,防止通过篡改证书/公钥的方式替换非法的 OS。高安全要求加解密:根据目前行业的惯例,非对称算法主要用于身份验证和对称密钥协商,实际的数据加解密依然会使用资源消耗更低的对称算法。在数据

    222、保密要求高的情况下,一般直接使用SoC/MCU 内置的加解密模块,数据的加解密过程不会有明文数据流出芯片,安全性更高。066外置加密芯片一般会包含常用的对称、非对称、哈希、随机数等算法,基本能满足全部业务所需的功能。并且专用加密芯片都带有可信安全存储区,可以满足密钥和关键数据的存储需求。此种芯片一般用于内置加密模块或纯软加密无法满足业务需求的场景:1.车云交互通讯:数据量较大且和其他业务同时运行,要避免影响 CPU 的算力。2.OTA 升级包校验:数据量大,且依赖 HASH 和非对称算法校验签名,专用芯片的算力会更高更适合此场景。3.密钥管理:专用芯片的可信存储区的根密钥可以做到以电荷形式存储

    223、,破坏芯片会导致存储区损坏,可信区的安全性极高。3.5 车用操作系统的安全技术3.5.1 传统实时操作系统传统车载 ECU 上,以单片机 MCU 为核心,运行 AUTOSAR CP OS、UCOS 等实时性较高的操作系统。传统 ECU 上,运行环境相对简单,通信方式通常以 CAN 总线为主,该类操作系统上应用的安全技术也相对简单,包括如下技术:1.内存保护大多数主流的MCU中都具备MPU(Memory Protection Unit,内存保护单元)。OS在进行系统调度时,可通过在MPU中配置不同的地址段及其读/写/执行权限,实现内存保护的功能,确保用户任务在运行时,不能够访问没有权限的地址范围

    224、。2.服务保护OS 中可配置不同对象(任务,中断,报警等)的访问权限,当前任务或中断在运行时,能否访问其他的 OS 对象(例如激活其他的任务)是受限的,可信应用无法获取执行特定的服务例如 Shutdown的权限3.基于 CAN 总线的入侵检测基于 CAN 总线的入侵检测一般部署在网关节点,可用于检测 CAN 总线的入侵事件。包括负载率、报文 ID、报文周期、DLC、CRC、报文的固定格式、信号值上下文、应用层协议等内容。检测到入侵时间后,可将相关事件日志进行记录和上报。4.HSM主流的 MCU 中大多集成了 HSM 部件,HSM 通常是独立的内核,与 MCU 其他正常功能的内核是隔离开的。HS

    225、M 中可以支持的安全技术包括:随机数生成、密钥及安全数据的存储、基于硬件加速更加高效的加解密算法、串行或并行的安全启动特性,可以检测应用程序是否被恶意篡改。HSM 的固件一般由芯片厂商提供,也可基于不同客户的需求进行定制开发,例如,可以在 HSM 中支持更多的非对称算法以适应不同的项目需求。3.5.2 自适应操作系统近年来,随着智能驾驶,车联网,智能座舱等需求的不断增长,传统的 MCU 及实时车载操作系统已经无法满足要求。车机、T-BOX、智能座舱中央控制器、域控制器等控制器更多的会使用 Linux、安卓、QNX 等操作系统。该类控制器通常以以太网为主干,其功能更加复杂,更加灵活,其安全风险也

    226、更多。前文提及的各类关键技术,在该类控制器上都有相关的应用场景。0671.基于以太网总线的入侵检测和防御。随着技术的进步,以车载以太网作为主干网的车型越来越多,车辆也不再是一个封闭的世界,需要通过联网与外界进行交互。这满足了越来越多样的用户需求,但同时也带来了更多的信息安全方面的风险。基于Ethernet的IDPS,可以检测和防护来自Ethernet的攻击事件,并进行存储和上报。包括泛洪攻击、欺骗攻击、畸形报文、黑名单、白名单等,也可支持上层 DOIP、SOME/IP 等协议的检测。2.TEETEE(可信执行环境)是与设备上的 Rich OS(如 Android、Linux 等)并存的运行环境

    227、,主要功能包括在设备中提供了安全区域,用于存储、隔离和处理安全数据,提供各类安全服务,管理各类安全 APP 等。在传统的手机 IT 行业中,TEE 有着广泛的应用。在车载环境下,随着用户需求的增长,车辆控制器需要支持指纹识别、面部识别、在线支付,软件更新下载,车辆远程操控等等功能,都会涉及到用户私密信息的安全性。在车载系统中加入 TEE,来支持相关的需求,是十分必要的。3.系统日志管理系统需要记录、存储和上传系统中关键的事件,供后期审计,以便发现安全风险和漏洞。常见的事件包括:用户的登录与注销;用户信息的变更;车载 APP 的安装与卸载;软件版本的 OTA 升级;系统检测到的可能的安全事件;安

    228、全策略的升级等等。4.访问控制与身份鉴别车辆联网后,需要对通过网络与车辆连接的设备进行鉴别,防止非法设备对车辆进行攻击。常见场景包括:请求远程控制的设备是否合法,请求 OTA 升级的设备是否合法,当前接入的设备具备哪些权限,可以访问那些功能等等。5.系统安全增强通过对系统地址空间布局随机化,使得系统上运行进程的内存地址无法被预测,以及增加程序控制流保护,当控制流发生意外更改时,必须执行预定义的操作,或者实施栈保护等措施,增强系统运行安全,防止代码意外执行。3.6 汽车基础软件的数据安全合规3.6.1 数据采集安全数据采集安全主要包含数据分级分类、采集安全管理、数据源鉴别和数据质量管理四项内容。

    229、随着汽车的智能化及网联化,搭载着摄像头、激光雷达等高级传感设备的车辆收集的数据越来越多。据统计,一辆自动驾驶测试车辆一天可采集的数据高达 10TB。如此海量的数据如果都无差别地进行安全防护,则无疑会增加企业数据防护的成本和人力。为此,就需要企业根据数据的价值、内容敏感程度、影响和分发范围等因素,并结合自身的应用场景来考虑数据的分类。根据汽车收集到的数据,可分为六大类:汽车属性类数据、车辆工况类数据、环境感知类数据、车控类数据、应用服务类数据和用户个人信息。068表 3.6-1 汽车数据类型及描述序号数据类型描述1汽车属性类数据指汽车在出厂后自带的属性数据,如车辆的VIN码、车辆颜色、动力参数、

    230、零部件号等。2车辆工况类数据指车辆在实际运行特征或车辆实际系统操作有关的数据,可分为车辆运行工况类数据和车辆静态工况类数据。如车速、水温、加速度等。3环境感知类数据主要是与车辆通过摄像头、激光雷达等传感器采集到所处外部环境信息,车外图像、车辆位置、点云数据等。4车控类数据指车辆操控直接相关的指令数据,主要包括智能决策车控类数据和车辆远程操控类数据。如加速请求、转向请求等数。5应用服务类数据指车辆给用户提供的服务类信息,如天气、涉车服务、交管通知等数据。6用户个人信息指在数据采集传输和使用销毁等过程中与用户密切相关的数据信息,这些数据信息能够一定程度上识别车联网用户个人身份或反映用户个人活动情况

    231、。如人脸、虹膜、指纹、位置、身份证号码等。3.6.3 数据存储数据存储安全主要包含存储介质安全、逻辑存储安全和数据备份恢复三个方面。存储介质安全是数据存储安全中的一个重要部分,对数据的存储介质(如磁盘,硬盘,虚拟容器,虚拟机等)进行管理,可以有效防范因为存储介质的不当使用而引发的数据泄露风险。车辆在运行过程中为了确保在发生交通事故时可还原出真实的情景,往往需要车辆对责任判定所需的数据在最小允许范围内进行收集并存储。为3.6.2 数据传输安全数据传输安全分别为数据传输加密和网络可用性管理。数据安全事件频发的阶段主要集中在数据传输阶段,而数据传输加密是保障数据传输安全的主要手段,数据传输加密可以帮

    232、助数据在不可信或安全性较低的网络中传输,能够有效防止数据遭到窃取,泄露和篡改。网络可用性管理可以用于保障数据在网络中传输的稳定性,可以将网络故障和网络瘫痪的可能性降到最低,同时要求网络和业务恢复时间处在可控范围之内。了确保数据安全的存储,因此需要数据在存储过程满足以下要求:1.境内存储,根据法律法规要求,在中华人民共和国境内收集和产生的个人信息和重要数据应在境内存储。2.存储时间最小化原则,信息保存的实际时间应与使用目的在程度上保持一致,在超过保存期限后,应对信息进行删除或匿名化处理。3.存储数据的完整性、保密性和可用性,存储个人信息和重要数据的介质应通过技术手段确保数据的安全,如数据加密、容

    233、灾备份、访问控制等。0693.6.4 数据处理安全逻辑存储安全对数据的逻辑存储(认证鉴权,访问控制,日志管理,安全配置等)进行管理,可以有效保证数据存储安全。数据备份是指对存储数据定期进行冗余备份,而数据恢复则是指数据在受到灾难性打击后,能够将备份数据立即启用的能力。数据处理安全包含数据脱敏、数据分析安全、数据正当使用、数据处理环境安全、数据导入导出安全五个维度。数据脱敏是指通过对敏感的数据进行变形和加密,将处理过的数据呈现在用户面前,从而既能满足数据挖掘的需求,又能实现对敏感数据的有效保护,如自动驾驶涉及的人脸车牌信息需经过脱敏才可以使用。数据本身其实并不具备任何价值,数据价值大小完全取决于

    234、数据挖掘的投入,或者说数据的分析,如果投入越大那么所发现的价值也就越大,与此同时暴露出来的安全风险也在增大,所以为了防止在数据分析过程中可能会出现的数据泄露和数据篡改等安全问题,就需要对数据分析的过程进行安全管理。如采用差分隐私保护技术等可以避免个人信息的识别。大数据时代下,每个事物都有两面,正如一个硬币有正反两面一样,所以数据能够得到正当的使用,是非常重要的,如果数据被非法使用,则会造成无法想象的灾难,尤其是组织内部的人员,如果被数据的高价值所吸引而做出了错误的行为,就会使得本就脆弱的组织内部安全建设雪上加霜,因此为了避免数据被非法获取、使用和处理,控制器需针对不同数据的使用进行权限管理,包

    235、括 MAC、DAC 等措施。数据处理环境安全是指对数据运行环境进行管理与检测,以避免在数据正当使用过程中,由于软硬件故障所造成的数据损坏或丢失的情况,控制器基础软件需实时监控运行状态,及时保存备份重要数据。数据导入导出是数据交换过程中的重要步骤,因为在数据交换的过程中存在着大量数据导入导出的场景及需求,而在此过程中,由于导入导出的数据量一般来说都是比较大的,因此数据导入导出过程更容易成为攻击者瞄准的目标。控制器对外接口如 OBD、JTAG 等在访问前需进行严格的身份认证,防止数据的恶意窃取。3.6.5 数据交换安全数据交换安全主要包括数据共享安全、数据发布安全和数据接口安全。为了挖掘数据的更多

    236、价值,组织机构通常会将数据共享给外部组织机构或第三方合作伙伴,然而数据在共享的过程中可能会面临巨大的安全风险。一方面数据本身可能具有敏感性,很多企业可能会将敏感数据共享给本应无权获得的企业;另一方面,在数据共享的过程中,数据有可能会被篡改或伪造,所以为了保护数据共享后的完整性、保密性和可用性,对数据共享安全进行管理是十分合理且有必要的。随着万物互联的发展,车车通讯逐步成为可能,为防止自车信息的隐私泄露,匿名化技术就必不可少。在数据交换过程中,获取数据最常见的方式是使用数据接口,所以数据接口也成为了攻击者重点关注的对象,因为一旦数据接口出现问题,就会导致数据在通过数据接口时发生数据泄露等风险。因

    237、此需增加诸如入侵检测、身份认证等技术来保证数据接口的安全性和合法性。3.6.6 数据销毁安全数据销毁安全主要包括数据销毁处置和存储媒体销毁处理两个方面。为了满足合规要求,在车辆报废时需要对数据进行销毁处理。数据销毁处理要求针对数据的内容进行清除和净化,以确保攻击者无法通过存储介质中的数据内容进行恶意恢复,从而造成严重的敏感信息泄露问题。在数据销毁过程中,为了防止攻击者通过对存储介质进行数据恢复操作,以至造成数据泄露的安全问题,需要对被替换或淘汰的存储介质进行物理销毁,不同的存储介质会使用不同的销毁方法。070一方面,智能网联汽车基础软件整体架构信息安全水平是 OEM 首要关注的;另一方面,智能

    238、网联汽车基础软件信息安全要求又需要分解到各个基础软件模块,这些零部件的信息安全水平反过来又决定了基础软件信息安全水平。因此,智能网联汽车基础软件信息安全测试评价体系不仅需要能对汽车基础软2.国家上层法律法规对汽车基础软件发展大力支持,基础软件的信息安全相关需求也会成倍增加。3.主机厂对汽车基础软件开发需求变大,汽车基础软件信息安全测评市场潜力巨大。3.7.2 测试评价对象虽然目前的基础软件相关标准已经包含相应试验方法,但这些标准只能作为信息安全测试评价方案3.7.1 测试评价的必要性1.汽车软件硬件架构的演变及解耦合,汽车开源式软件架构带来更多功能,也引入更多安全风险面3.7 汽车基础软件安全

    239、测试评价测试评价和脆弱点。的输入,需要有一套汽车基础软件信息安全测试评价体系把上述标准组合起来。件的信息安全水平做出真实的评价,还应该能对基础软件模块进行信息安全测试评价。3.7.3 测试评价范围目前,从法规要求来看,智能网联汽车基础软件信息安全测试评价应包含管理体系和产品体系两部分,因此提出的智能网联汽车基础软件信息安全测试评价体系在测试评价范围上包含了管理体系和产品体系两方面,如图 3.7-1 所示。对管理体系和产品体系的测试评价涵盖概念、设计、开发、测试、生产、运行、维护、报废各个阶段,应对产品全生命周期的各种风险。图3.7-1 安全测试评价范围管理体系的测试评价范围主要涉及组织策略和流

    240、程相关的审计(如表 3.7-1 所示),组织策略方面包括企业的网络安全制度、网络安全文化、人员角色等,流程方面包括企业网络安全流程文件、模板、工具等。071表3.7-1 智能网联汽车管理体系信息安全测试评价范围示例维度内容示例方式组织策略网络安全制度网络安全方针、策略、管理发文等审计网络安全文化能力管理、意识管理、持续改进等人员角色负责人及相应权限、支持网络安全的资源等流程网络安全流程网络安全概念、设计、开发、验证、生产、运维等流程文件模板TARA 分析模板、设计模板、事件响应计划模板等工具开发工具、验证工具等产品体系的测试评价范围主要涉及产品技术要求相关的文档检视和产品测试(如表 3.7-2

    241、 所示),技术要求文档包括产品设计文档、测试规范等,测试包括基于技术要求开展的符合性测试、漏洞测试、Fuzz-ing 测试、渗透测试等。表 3.7-2 智能网联汽车产品体系信息安全测试评价范围示例维度内容示例审查方式技术要求产品设计文档架构设计文档、系统设计文档、功能设计文档等文档检视测试规范测试工具、测试环境、测试用例等产品测试符合性测试、漏洞测试、Fuzzing 测试、渗透测试等测试上述测试范围可根据测试对象的不同要求进行裁剪,管理体系和产品体系的测试评价更为严格,这将体现在需要检视的文档更多、范围更大,执行的测试更为全面深入等方面。3.7.4 测试评价依据智能网联汽车基础软件信息安全测试

    242、评价体系应基于标准构建,表 3.7-3 列出了建议参考的部分标准。在管理体系方面,可依据GB/T 道路车辆信息安全工程对企业组织、流程进行审计。在产品体系方面,可依据整车和零部件标准对产品进行测试评价,包括GB 汽车整车信息安全技术要求及试验方法、GB/T 40856-2021 车载信息交互系统信息安全技术要求及试验方法、GB/T 40857-2021 汽车网关信息安全技术要求及试验方法、GB/T 40855-2021 电动汽车远程服务与管理系统信息安全技术要求及试验方法、GB 汽车软件升级通用技术要求等标准。072表 3.7-3 智能网联汽车基础软件信息安全测试评价依据示例项目标准说明管理体

    243、系GB/T 道路车辆-信息安全工程ISO 21434 转化国标,定义网络安全管理体系要求,包括组织和流程要求产品体系GB 汽车整车信息安全技术要求及试验方法整车角度的信息安全要求和相应测试方法GB/T 40856-2021 车载信息交互系统信息安全技术要求及试验方法T-BOX、IVI 的 信 息 安 全 要 求 和 相 应 测试方法GB/T 40857-2021 汽车网关信息安全技术要求及试验方法车载网关的信息安全要求和相应测试方法GB/T 40855-2021 电动汽车远程服务服务与管理系统信息安全技术要求及试验方法GB/T 32960 配套信息安全标准GB 汽车软件升级通用技术要求OTA

    244、标准,内含信息安全要求3.7.5 测试评价方法1.管理体系测试评价方法本测评方案基于标准道路车辆信息安全工程中相关要求,从企业治理、项目管理、概念阶段、产品开发阶段、验证阶段、生产阶段、运维阶段、供应商管理等模块开展审计工作。图3.7-2 基于道路车辆 信息安全工程的管理体系测试评价审计针对每个模块的检查项进行审计,并完成相应打分,得出模块的得分。然后基于每个模块的得分汇总为管理体系的总体得分,如果总体得分高于事先设定的门限,则表明通过管理体系测试。2.产品体系测试评价方法本测评体系参考 ISO/SAE 21434 标准等相关风险评估方法,首先制定智能网联汽车基础软件漏洞风险评估方法,为汽车漏

    245、洞评级提供技术支撑。其次在此基础上对汽车基础软件存在的攻击面进行分类,073对单一攻击面存在的若干漏洞评估结果进行融合,从而得到单一攻击面的风险评估结果,然后对汽车各个攻击面的风险评估结果进行整合,得到汽车基础软件模块的风险评估结果。最后汇总汽车基础软件各模块的风险评估结果,得到智能网联汽车基础软件信息安全风险评估结果。图3.7-3 智能网联汽车部件级风险评估方法架构从图 3.7-3 看到,部件级风险评估方法包括两个部分,第一部分是对汽车漏洞进行风险评估,第二部分是基于汽车漏洞风险评估结果,完成部件级风险评估。3.风险评估方法流程本测评体系中的风险评估流程与 ISO/SAE 21434 标准中

    246、的风险评估流程保持一致,流程见图3-33。在此基础上,本测评体系对攻击可行性评级和攻击影响评级进行了明确说明和解释。图3.7-4 智能网联汽车漏洞风险评估流程 攻击可行性 攻击可行性代表了漏洞可被攻击者利用的程度,越容易被利用的漏洞则对汽车风险越高。下表对攻击可行性的四个级别进行了说明,四个等级分别代表了四种不同程度攻击的威胁。074表 3.7-4 等级和相应标准等级说明高容易完成攻击中使用适度的方法可实现攻击低通过高难度的方法可实现攻击极低很难或几乎永远不可能完成攻击 攻击影响评级 由于攻击者使用漏洞会造成汽车资产在安全、财产、运行和隐私方面的损害,因此 ISO/SAE 21434 对攻击影

    247、响评级包含了安全、财产、运行和隐私四个方面。本规范结合当前相关法规和标准,同时为了扩大风险评估覆盖面,攻击影响增加 CIA 维度。安全损害影响等级对产品的功能失效所引起人员伤害程度(包括个人车主及行人)进行了定义,详细定义如下:表3.7-5 安全影响等级影响等级安全影响等级指标致命个人车主及行人角度:S3:危及生命的伤害(生存不确定),致命严重个人车主及行人角度:S2:严重危及生命的伤害(可能存活)一般个人车主及行人角度:S1:轻中度伤害无个人车主及行人角度:S0:无伤害财产损失影响等级定义了利益相关者的财产损失程度,详细定义如下:表3.7-6 财产损失影响等级影响等级财产损失影响等级指标致命

    248、(1)OEM/供应商角度:漏洞符合产品缺陷定义,将导致 OEM 车型召回,遭到行政处罚,引起公司声誉受损,市场份额受损。公司无法承受引起的相关经济损失(如破产,公司倒闭等)。(2)运营商:漏洞会引起运营商经营行为无法进行(受召回影响),引起运营商声誉受损,市场份额受损。运营商无法承受引起的相关经济损失(如破产,公司倒闭等)。(3)个人车主角度:漏洞会引起个人车主无法承受的整车价值全部损失,如导致车辆报废、整车被盗、个人电子支付被入侵等。075影响等级财产损失影响等级指标严重(1)OEM/供应商角度:漏洞符合产品缺陷定义,将导致 OEM 车型召回,引起公司声誉受损。公司可承受引起的相关经济损失。

    249、(2)运营商:漏洞会引起运营商业务受到影响(受召回影响),声誉受损,运营商可承受引起的相关经济损失。(3)个人车主角度:漏洞会引起个人车主可承受的财产损失,财产损失范围为车辆价值的 10%-99%,如车辆部件损坏、付费功能激活等。一般(1)OEM/供应商角度:漏洞被攻击者利用可导致公司产品非预期功能激活,对公司财产造成损失。如付费功能非法使用等。(2)运营商:漏洞会引起运营商车辆产品非预期功能激活。如付费功能非法使用等。(3)个人车主角度:漏洞会引起个人车主车辆价值 10%以下的财产损失。如车辆付费功能激活、个人电子支付被入侵等。无财产损失不会产生任何影响,忽略不计。运行异常影响是指汽车功能运

    250、行异常对个人车主驾驶车辆产生影响的程度,详细定义如下所示:表 3.7-7 运行异常影响等级影响等级运行影响等级指标致命个人车主角度:资产被攻击后,导致车辆无法工作。功能出现重大中断,无法被人为控制消除。或者不符合安全或法规要求。涉及与车辆行驶相关的制动系统、动力系统和转向系统功能失效。严重个人车主角度:资产被攻击后,导致车辆部分功能丧失。车辆进入跛行模式,仍然可以运行,无法被人为控制消除。如变速箱档位切换异常,新能源电池管理异常、发动机转速异常等。一般个人车主角度:资产被攻击后,造成部分功能降级或性能下降。驾驶员可以人为消除。如车辆外观有一定异常,或者驾驶舱出现噪音,引起驾驶员困扰。车载娱乐系

    251、统、车身舒适系统、车辆辅助功能(与行驶控制无关)等功能降级。无个人车主角度:资产被攻击后,不会导致车辆功能降级或性能下降。隐私泄露影响是车辆受到攻击后个人隐私指泄露影响程度,详细定义如下所示:076表3.7-8 隐私泄露影响等级影响等级隐私泄露影响等级标准致命个人车主角度:利用漏洞造成的隐私泄露会对用户造成严重或不可逆转的影响。隐私信息包括对机构的承诺、无法偿还的债务、个人健康生理信息、宗教或哲学信仰、婚史、种族或民族血统、个人生物识别信息、性取向、未公开的违法犯罪记录、残障自然人的特殊需要、刑事调查报告或者由于隐私泄露会形成自然人破产、丧失工作能力以及形成的心理和物理创伤的信息。严重个人车主

    252、角度:利用漏洞造成的隐私泄露会对用户造成重大影响。隐私信息包括银行账户、鉴别信息(口令)、存款信息(包括资金数量、支付收款记录等)、房产信息、信贷记录、征信信息、交易和消费记录、流水记录、虚拟货币、虚拟交易、游戏类兑换码等虚拟财产信息、个人身份信息、社保信息、纳税信息、行踪轨迹、住宿信息、精准定位信息、处罚信息、通信记录和内容、通讯录、好友列表、群组列表等,或者由于隐私泄露引起银行黑名单、资产损失、失业、个人声誉受损的信息。一般个人车主角度:利用漏洞造成的隐私泄露会对用户造成较大的麻烦。隐私信息包括个人电话号码、网络身份识别信息、设备信息、个人偏好、教育状况、兴趣爱好、个人电子邮件地址、姓名、

    253、年龄、自然人可识别的照片或视频等信息,或者导致骚扰电话、骚扰信息、诈骗的信息。无个人车主角度:隐私泄露不会带来任何影响或可以忽略不计的后果,例如账单等。CIA 影响性指标组反映漏洞成功利用后所带来的机密性影响、完整性影响和可用性影响。通过计算安全损害、财产损失、运行异常、隐私泄露和 CIA 五个维度数值,计算得到攻击影响综合评级。风险评估评级 对攻击可行性和攻击影响结果进行综合性风险评估,风险评估结果分为致命、严重、一般、提示和无等五个级别。4.汽车风险评估方法基于汽车漏洞风险评估方法,整合部件攻击面,完成部件级风险评估。077图3.7-5 部件攻击面根据部件所处的位置与整车安全关联关系的不同

    254、,部件级风险评估分为关键节点软硬件、车内网络、车外通信以及车联网业务安全四个攻击面。通过汽车漏洞风险评估方法可得到漏洞风险评估结果,基于漏洞与攻击面的对应关系可以得到各攻击面与漏洞风险评估结果的对应表,从而计算各攻击面的风险评估结果。获得部件风险评估结果后,整车风险评估结果可依据各部件在整车的重要程度通过加权计算得出。078第4章汽车基础软件信息安全与AUTOSAR4.1 AUTOSAR 信息安全框架和关键技术分析随着汽车网联化和智能化,汽车不再孤立,越来越多地融入到互联网中。在这同时,汽车也慢慢成为潜在的网络攻击目标,汽车的网络安全已成为汽车安全的基础,受到越来越多的关注和重视。AUTO-S

    255、AR 作为目前全球范围普遍认可的汽车嵌入式软件架构,已经集成的相关信息安全模块对实现信息安全需求有着充分的支持,例如保护车内通信或保护机密数据。由于 CP AUTOSAR 和 AP AUTOSAR 的体系结构不同,目前信息安全模块的相关技术实现也存在差异。4.1.1 SecOC在车载网络中,CAN 总线作为常用的通讯总线之一,其大部分数据是以明文方式广播发送且无认证接收,这种方案具有低成本、高性能的优势。但是随着汽车网联化、智能化的业务需要,数据安全性越来越被重视。传统的针对报文添加 RollingCounter 和 Checksum 信息的方法,实现的安全性十分有限,也容易被逆向破解,进而可

    256、以伪造报文控制车辆。SecOC 是在 AUTOSAR 软件包中添加的信息安全组件,主要增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。该模块的主要作用是为总线上传输的数据提供身份验证,它可以有效地检测出数据回放、欺骗以及篡改等攻击。图4.1-1消息认证和新鲜度验证流程079在 SecOC 标准中,AUTOSAR 主要基于 MAC 的身份验证和 Freshness 的防重放攻击,来实现数据的真实性和完整性校验。首先 MAC(Message Authentication Code)是保障信息完整性和认证的密码学方法之一,其中 CMAC(Cipher based MAC)一般用于

    257、对称加密,整车厂可在车辆下线刷写程序时静态分配密钥,也可选择使用云端服务器动态地给车辆分配密钥)是车载总线加密认证常用方案。MAC 的作用不是防止有效数据被泄露,而是为了保护数据不会被攻击方篡改,即完成数据来源的认证。如需保护通信数据不被攻击方监听,则报文的有效数据还需要进行额外的加密。为了降低重复攻击的风险,则需要在 Secured I-PDU 中加入新鲜度值,Freshness Value 是一个根据一定逻辑不断更新的数值,Freshness Value 的更新方法多种多样,AUTOSAR 标准将基于计数器或基于时间的新鲜度值作为典型选项。在 CP AUTOSAR 平台,SecOC 模块依

    258、赖于 PduR 的 API 和功能,提供了 PDU Router 所需的上下两层 API(upper and lower layer API)功能。依赖于由 CSM 模块在 AUTOSAR 中提供的加密算法。SecOC 模块需要 API 函数来生成和验证加密签名(Cryptographic Signatures)或消息验证码(Message Authentication Codes)。为 RTE 提供具有管理功能的 API 作为服务接口进行调用。SecOC 通信协议特性同样适用于 AP AUTOSAR 平台标准中,其主要目标是实现与 CP AUTOSAR平台 SecOC 功能互操作性,尤其适用

    259、于使用 UDP 多播的消息场景(SecOC 是目前唯一支持的协议)和与 CP AUTOSAR 之间基于信号的网络绑定的安全通信场景。图4.1-2 AP AUTOSAR通信管理中的SecOC为了实现与 CP AUTOSAR 平台的互操作性,SecOC 同样应用于 Adaptive CM 中。认证信息包括认证器(例如,消息认证码)和可选的新鲜度值。为了保持与 CP AUTOSAR 平台的互操作性并提供可选的新鲜度值管理功能,AP AUTOSAR CM 将依赖于可插入的新鲜度值管理库。该库将提供新鲜度值管理相关的 API,包含 CP AUTOSAR 平台关于 FreshnessManagement

    260、客户端、服务端接口的副本以及调用定义的相关功能。080SecOC 的核心思想在于通信认证,但是不涉及报文加密。虽然伪造报文的难度已经大大提升了,但是在通信过程中采用明文传输,依旧有一定的风险;认证信息的强度和信息长度相关,通信认证方案会加大报文负载(传统 CAN 报文的负载只用 8-64 个字节),从而导致负载率提升,通信实时性下降,可能使得正常功能受到影响,应考虑信息安全强度与通信实时性的相互平衡;MAC 技术应考虑对称密钥的管理和共享的问题,目前大部分 MCU 是没有安全功能的,对称密钥也是明文保存在系统或者内存中。共享该密钥时采用明文通信,这是非常不安全的。但 MCU 的计算能力和存储空

    261、间是有限的,采用了安全机制以后,必然占用很大的资源消耗,应充分考虑系统的稳定性,以保障业务与安全机制能够正常运行;SecOC 用于保证安全通信,必然涉及密钥(key)的管理,应考虑灌装、更新和维护该 key,同时还需考虑换件后 key 的一致性。4.1.2 TLSTLS(Transport Layer Security)作为传输层的中坚力量,可以支撑上层的 SOME/IP、MQTT 和HTTP 等协议。不但可以用于 V2X 的安全通讯,也可以用于车内通讯节点之间的安全通讯。当然像 T-BOX等可以与车外节点通讯的节点来说,其安全性要求更高,可以应用更加完整的广义 TLS,既安全,又灵活。而车内

    262、之间一般 IP 地址、端口、服务接口等都固定,安全性要求也不如 T-BOX 高,则可以应用广义 TLS中的预共享密钥(TLS_PSK)等套件,既高效,又稳定。TLS 属于工作在传输层的协议,它介于传输层底层协议和上层应用协议之间。而以太网的传输层主要有两大底层协议:TCP(Transmission Control Protocol)和 UDP(User Datagram Protocol)。二者各有特点,互为补充。不管在传统互联网上,还是车载以太网上,两者都是常见的传输层底层协议。不同的传输层底层协议实际上对应着不同的传输层安全保护协议,采用 TCP 传输的,就用 TLS 保护。采用 UDP

    263、传输的,就用 DTLS 保护。DTLS 的全称是 Datagram Transport Layer Security,比 TLS 多出来的“D”,指的就是 UDP 中的“D”。TLS 和 DTLS 各有不同的版本,目前主流支持的还是 1.2 和 1.3版本。AUTOSAR 标准基于 Ethernet 架构同时提供了 ISO DoIP 的解决方案。DoIP 全称是 Diagnostic Over IP,顾名思义就是基于 IP 的诊断。DoIP 具有处理大量数据、节省重编程时间、方便接入 IT 设施、标准通信灵活使用等优势。普通的 DoIP 是基于 TCP 进行诊断通信,在 ISO 13400-2

    264、 2019 版本中定义了安全的 DoIP 会话,即基于 TLS 进行诊断通信。DoIP server 协议栈会根据 DoIP client 实体的请求,确定使用 TCP 还是 TLS 进行诊断信息的传输。TLS 允许在 Client DoIP 实体和 Server DoIP 实体之间建立经过身份认证和加密的通信通道,Client DoIP实体身份的验证可以在诊断应用层中实现,例如 ISO 14229 中定义的 0 x29 服务。TLS 技术仍有自身的技术局限性。大部分控制器都是采用了 MCU,计算能力和存储空间都是有限的,采用了安全机制,例如加解密算法、消息摘要算法、签名验签算法等,必然占用很

    265、大的资源消耗,应考虑在不影响正常功能的情况下安全策略能够正常实施。SSL/TLS 采用安全认证的方式来识别对方身份,需要提前灌装安全证书,如果控制器进行换件,应保证证书的一致性,让新的控制器能够进行身份的合法验证,从而正常通信。在实际应用场景中,大部分控制器可能没有安全存储环境(SE 或者 HSM 等),应考虑保证证书和私钥的安全存储。在采用 TLS 进行安全认证通信中,必然会降低通信的效率,应考虑通信的实时性。安全技术应用的同时会带来一些资源消耗,产生一定的局限性。应当在满足汽车信息安全相关法规标准的原则下,技术手段在不影响控制器正常运行的前提下,进行方案选型完成集成部署,如果内部安全通信技

    266、术手段消耗过多的控制器资源并影响了正常业务运行,应适当降低安全等级,必须同081时兼顾控制器运行和内部安全通信。随着汽车网联化的发展,以太网通讯已经在车内通讯及车联网普及,TLS 和 DTLS 也更多地出现在汽车行业的视野里。AUTOSAR 在 CP 和 AP 中也加入了 TLS 和 DTLS 的规范。从 AUTOSAR CP 4.4 标准开始就明确了支持 1.2 和 1.3 版本,优先选择 1.3 版本。AP R21-11 中只描述了 1.2 版本,但相信将来版本也会加上 1.3 版本。4.1.3 IPsecIPsec(Internet Protocol Security)是网络安全协议,运

    267、行在 OSI 模型的第三层(Internet Proto-col,IP 层),在 VPN(Virtual Private Network)应用很广泛。IPsec 在 IP 层对报文提供数据机密性、数据完整性、数据来源认证、防重放等安全服务,定义了如何在 IP 数据包中增加字段来保证 IP 包的完整性、私有性和真实性,以及如何加密数据包。图4.1-3 IPsec协议及组件功能IPsec 提供了两种安全机制:认证和加密。认证机制使 IP 通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性,以防数据在传输过程中被窃听。IPse

    268、c 的安全体系由验证头协议(Authentication Header,AH)、安全封装协议(Encapsulating Security Payload,ESP)及安全联盟(Security Association,SA)三部分组成。AH 是认证头协议(IP协议号为 51),主要提供的功能有数据源验证、数据完整性校验和防报文重放功能,可选择的散列算法有MD5(Message Digest),SHA1(Secure Hash Algorithm)等。ESP 是报文安全封装协议(IP 协议号为 50),ESP 将需要保护的用户数据进行加密后再封装到 IP 包中,验证数据的完整性、真实性和私有性。

    269、可选择的加密算法有 DES,3DES,AES 等。SA(Security Association)是 IPsec 的基础,也是 IPsec的本质,IPsec 对数据流提供的安全服务通过 SA 来实现,它包括协议、算法、密钥等内容。IPsec 有隧道(tunnel)和传输(transport)两种运行模式,运行模式和安全体系中的 AH 及 ESP 组合形成 4 种情况:隧道模式+AH、隧道模式+ESP、传输模式+AH 以及传输模式+ESP。AUTOSAR CP R19-11标准在TCP/IP模块加入IPsec相关功能介绍,并对功能实现进行了条件约束,目前只支持 IPsec 运输运行模式,隧道运行

    270、模式、IPv6 和多点传播都暂不支持。并规定了其他模块可执行的操作内容,KeyM 模块可为 IPsec 子模块提供证书处理,CSM 允许执行 IPsec 子模块所使用的加密作业和密钥操作。082AUTOSAR AP 中 IPsec 协议实施的目标是在车载 IP 网络中提供安全的通信通道。在 AUTOSAR 自适应平台中实施 IPsec 将为网络节点之间的通信提供保密性、完整性或两者兼备的选项。IPsec 作为标准网络安全协议提供了安全通信的手段,同时支持多供应商堆栈互操作性。自适应平台没有为电子控制单元指定任何操作系统,因此是 IPsec 功能最好的实践方式。4.1.4 Crypto Stac

    271、k为了汽车软件提供统一的安全加密/解密接口,AUTOSAR 在 4.3 版本推出 Crypto Stack 模块。Crypto Stack 是 AUTOSAR 架构体系中负责数据加密保护和密钥管理的模块,由 Crypto Service Man-ager,Crypto Interface,Crypto Driver 三个部分组成,为应用程序和系统服务提供了标准化的密码服务接口。密码服务可以是哈希计算,非对称签名验证,对称加密等。其主要应用于 ECU 通信加密、Securi-ty Access 流程保护和 KEY 的管理等使用场景。CSM(Crypto Service Manager)是加密服务

    272、管理器,位于 AUTOSAR 的 SYS 模块最高层的服务层。服务层是基础软件的最高层,它的任务是为应用软件和基本软件模块提供基本服务,即为应用软件和基本软件模块提供最相关的功能。CSM 基于一个依赖于软件库或硬件模块的加密驱动程序来提供加密功能的服务,也可以使用多个加密驱动程序的混合设置。CSM 通过 CryIf(Crypto Interface)访问不同的加密驱动程序。图4.1-4 CSM和邻近模块的关系CSM作为服务层,为SWC或BSW提供加密操作的接口。CSM的主要任务是对服务进行调度和排序,并调用加密接口(CryIf)进行进一步操作。CryIf 将请求调度到加密驱动程序及其静态分配给

    273、该服务的加083密驱动程序对象。CSM 使用基元(CsmPrimitives,已配置加密算法的实例)的静态配置来定义加密操作。然后将这样的基元分配给 Job(Job 是配置过的 CsmJob,指的是密钥、密码原语和参考信道),该配置决定进一步的属性,如优先级、异步或同步执行以及程序执行中应使用的密钥。需要注意的是,密钥总是位于加密驱动程序本身中,CSM 只使用对它的引用。密钥和基元的分离允许加密操作和密钥管理 API 分离。这使得应用程序可以专注于所需的加密操作,如 MAC 计算和验证,而密钥管理器则在配置设置期间提供密钥。CSM 的 API 大致可以分为两类:直接 API(主要用于密钥管理)

    274、和基于 Job 的 API(主要用于加密操作)(见下图)直接 API 与 CryIf 和 Crypto Driver 中的函数有直接对应关系,这些函数只能同步调用,CSM将把参数从应用程序直接传递给函数调用。基于 Job 的 API 使用一个 Job 结构,即 Crypto_JobType,它包含静态和动态参数以及对结构的引用,为执行该 Job 的加密驱动程序提供所有必要的信息,使用Job 的每个服务都将使用此结构。服务的所有必要参数将由 CSM 打包到结构的元素中,然后调用 CryIf,然后调用配置好的 Crypto Driver。图4.1-5 CSM、CryIf和Crypto的Job AP

    275、I和直接API调用树Job 可以同步运行,也可以异步运行,这取决于静态配置。加密服务信息、加密算法族和模式的参数决定了加密驱动程序中要执行的确切的加密算法。CryIf(Crypto Interface)是加密接口模块,位于 BSW(Basic SoftWare)的抽象层。CryIf 模块提084供了唯一的接口来管理不同的加密硬件和软件解决方案,如 HSM、SHE 或基于软件的 CDD。图4.1-6 AUTOSAR Layered View with Crypto-InterfaceCryDrv 有如下两种实现方式:1.Crypto(HW based):硬件加密模块的驱动程序,用于控制 HSM(

    276、Hardware Security Module)或 SHE(Security Hardware Extensions),和具体芯片有关。2.Crypto(SW based):基于软件的 CDDs(Complex Device Drivers)实现的加密算法,如AES-128 等算法。基于以上两种不同的实现方式,CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案。因此,基于 CryIf 维护的映射方案,CSM 模块可以使用多个底层的 Crypto HW 以及 Crypto SW 解决方案。此外,CryIf 还确保了对加密服务的并发访问,从而能够同时处理多个加密任务。与 CP A

    277、UTOSAR 不同,AUTOSAR 自适应平台支持用于通用加密操作和安全密钥管理的 API。该API 支持在运行时动态生成密钥和加密作业,以及对数据流进行操作。API 实现可以引用一个中央单元(加密服务管理器)来实现平台级任务,例如跨应用程序一致地进行访问控制和证书存储。该实现还可以使用加密服务管理器来协调功能到加密驱动程序的卸载,例如硬件安全模块(HSM)。为了在潜在的应用程序受损的情况下支持密钥的安全远程管理,Crypto Stack 集成了密钥管理体系结构,其中密钥和相关数据以端到端的保护形式进行管理。密钥可以基于现有的供应密钥以受信任的方式引入系统,也可以通过本地密钥生成以不受信任的方

    278、式引入系统。4.1.5 IAM车内信息娱乐应用程序由于与外界互联网相连,因此被入侵的风险很高,像这类应用程序在设计时一定是不被允许使用车身控制相关服务的。例如信息娱乐系统被外界攻击,然后被远程控制去使用制动服务,为了保障安全,必须要阻止这种信息娱乐应用程序对制动服务访问的任何尝试。日益增长的信息安全需求驱动了身份和访问管理(IAM)的概念,因为 AUTOSAR Adaptive 平台需085要和应用程序建立健壮和良好定义的信任关系。IAM 为 Adaptive 应用程序引入了特权分离,并针对攻击时的特权升级提供了保护。另外,在部署期间,IAM 能够使集成者提前验证 Adaptive 应用程序要

    279、求的资源访问权限。IAM 为来自适应应用程序对服务接口,Adaptive 平台基础功能簇和相关模型资源的的请求提供了访问控制框架。IAM 框架为 AUTOSAR Adaptive 平台堆栈和 Adaptive 应用程序的开发人员提供了一种机制,这种机制用于对每个应用程序的意图进行建模,根据访问请求提供访问控制决策,并执行控制访问。IAM 侧重于提供方法来限制 Adaptive 应用程序对 Adaptive 平台基础接口、服务接口与功能集群相关的明确资源接口(例如 KeySlots)的访问。特别对系统资源(如 CPU 或 RAM)的强制配额不包括在 IAM 中。在运行期间,IAM 的进程对 Ad

    280、ptive 应用程序是透明的,除非请求被拒绝并发出通知。远程 Adap-tive 平台提供的服务实例请求由 IAM 覆盖的,传入请求的 PDPs 必须由 Adaptive 应用程序实现。该框架旨在运行期间执行对 AUTOSAR 资源的访问控制。假设 Adaptive 应用程序将在启动时进行身份验证,并且现有受保护的运行时环境确保 Adaptive 应用程序被正确隔离,并且防止它们的特权升级(例如绕过访问控制)。考虑一个简单的应用场景,对于访问权限的描述,通常可以用一个访问权限矩阵来表示:图4.1-7 访问权限矩阵访问权限矩阵显示的是访问主体和访问客体之间的访问权限。所谓访问主体,是指一个想要获

    281、得其他服务访问权限的对象,通常是指系统中的一个进程;所谓访问客体,是指应当授权被访问的对象,通常它可以是指系统中的一个进程也可以是系统中的其他资源。访问权限相关的信息需要以清单文件的形式部署在系统中。对于这份清单文件,有两种组成形式:第一种,针对每一个服务和应用,从访问权限主体的角度,列举每个访问主体的访问意图,也就是每个访问主体拥有的其他服务或应用程序(访问客体)的访问权限;第二种,针对每一个服务和应用,从被访问的客体角度,列举出它支持被哪些其他服务和应用(访问主体)访问。对于访问主体,通常情况下它可访问的客体清单文件是不会随着时间推移而改变;但是对于一个访问客体,它的被访问清单会随着部署了

    282、新的应用而更新。0864.1.6 KeyM在一个加密功能中,密钥和证书的功能比重很大。首先,密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。许多加密算法需要使用到密钥,因此,就需要 KeyM 模块来管理密钥,而 KeyM 对于密钥的管理主要体现在更新和生成密钥方面。而证书以加密或解密的形式保障了用户网络交流中的信息和数据的完整性和安全性。KeyM 模块可以实现证书链的配置保存与验证,这使得网络中的信息和数据的安全性更高。AUTOSAR KeyM 模块由两个子模块组成:密钥子模块和证书子模块。密钥子模块用于初始化、更新和维护的密钥材料;证书子模块允许定义和配置证书,以便

    283、在生产时存储它们,并进一步用于多种用途。图4.1-8 AUTOSAR layered view with KEYM密钥子模块提供了一个 API 和配置项,用于引入或更新预定义的加密密钥材料。它充当一个关键客户端,解释从一个关键服务器提供的数据,并创建相应的关键材料,这些密钥被提供给加密服务管理器。成功安装密钥材料后,应用程序就能够进行加密操作。证书子模块提供了对证书进行操作的 API 和配置。允许配置证书链,在配置中将证书的属性和关系设置好,上层应用通过 API 将证书数据传给 KeyM 后,证书子模块将根据配置内容及 HSM 按照标准结构解析的证书存储配置的位置(NVM、CSM 或 RAM)

    284、。此外,证书子模块允许 BSW 模块和 SWC 在AUTOSAR 软件架构的中心点上更有效地使用证书进行操作。此类操作的示例包括验证完整的证书链或从运行时提供并验证的证书中检索元素。所需的加密操作(如验证证书签名)仍然由加密服务管理器中定义的相关加密作业执行。与 CP AUTOSAR 不同,AP AUTOSAR 平台的更新和配置、通信、持久性或诊断等服务,也需要加密服务作为其功能的一部分。因为架构差异的原因,AP AUTOSAR 平台会将需要用户自定义、差异性的功能在应用层去实现,所以应用程序可以定义所需的密钥插槽、加密提供程序和证书。当需要关键材料时,必须由自适应应用程序(例如 OEM ke

    285、y manager)配置,平台应指定槽型机器的关键槽。为了管理关键材料,一个专用的自适应应用程序(密钥管理器)可以指定相同的密钥插槽(即相同的参数和插槽型机器)。0874.1.7 IdsM车辆中的许多新功能建立在车载和后台服务之上,需要面对保护车辆免受网络攻击的挑战。为车辆的 E/E 架构配置了安全机制,更新签名软件、安全启动和安全车载通信系统正在逐步建立。目前,IDS 作为一种额外的安全机制正在引起 OEM 和供应商的关注。入侵检测系统管理器(IdsM)是一个基础软件模块(适用于 Classic AUTOSAR)或平台服务(适用于 Adaptive AUTOSAR),用于收集和集中聚合可能由

    286、车辆软件、通信或电子系统受到恶意攻击而导致的安全事件。软件组件 IdsM 提供了接收板载安全事件 SEv 通知的标准化接口。SEv 可以通过 BSW(Basic Software Modules)和 SW-C(application Software Components)实现的安全传感器上报。此外,可以用可选的上下文数据(如事件类型和可疑数据)报告 SEv,这些数据对于在后端执行的安全取证来说是有用的信息。除了收集,IdsM 还可以根据可配置的规则对 SEv 进行筛选。IdsM 将上报的 SEv 过滤并转换为合格的机载安全事件(QSEv),IdsM 进一步处理 QSEv,用于存储或转发。根据

    287、总体安全概念的不同,QSEv可以通过安全事件内存(Sem)在本地持久化,也可以传播到已配置的接收器,或者两者兼有。可用的接收器是诊断事件管理器(Dem)模块和 IDS 报告器模块(IdsR),它们可以将 QSEv 数据传递给后端中的安全操作中心(SOC)。在车辆内的每个安全相关或机器中,IdsM 模块或服务的实例会收集和过滤安全事件(可选地包括附加数据),以便将它们存储在本地安全事件内存(Sem)和/或通过车辆网络将它们转发到中央入侵检测系统报告器(IdsR)。例如,该 IdsR 可能位于远程信息处理单元内,使其能够通过蜂窝网络向 OEM 的安全操作中心(SOC)发送安全报告和相关数据。然后,

    288、安全事件管理(SIEM)分析这些信息,并在必要时用于制定和决定适当的防御或缓解措施以应对攻击。AUTOSAR 标准指出 BSW 模块、CDD 和 SWC 都可以充当安全传感器,安全传感器将安全事件(SEv)报告给 IdsM,AUTOSAR 标准化可以由 AUTOSAR BSW 报告的安全事件类型的子集。每个 BSW 的规格里列出了自己产生的安全事件类型,这些事件由相应模块报告,业务组件也可以报告在 AUTOSAR 中未标准化的自定义安全事件类型,可以使用安全性摘要(SecXT)指定由特定 ECU 报告的安全性事件类型的属性。AUTOSAR 入侵检测系统管理器是通用的、提供灵活的配置。它独立于底

    289、层通信系统,在上述限制和假设条件下可以应用于任何汽车领域。4.2 AUTOSAR 信息安全趋势分析当汽车朝智能网联化方向发展时,未来会和路边的基础设施、交管平台,云端的系统进行信息交互,来决策刹车还是加速,是保持车道还是变更车道。汽车也从单纯的交通工具变成了互联网的智能节点,智能网联汽车的前提是网联(Connected)。目前几种常见的汽车联网方式为:车与云端互联、车与消费电子互联、车与基础设施互联、车与车互联。当汽车接入网络的那一刻起,它已经从原来的信息孤岛,变成了万物互联中的一个节点,而网络安全也成了智能网联汽车必须面对的首要问题。AUTOSAR Classic 是大多数车辆平台的标准中间

    290、件,满足实时操作系统和功能安全的典型要求。多年来,它一直在不断发展,并提供了一系列用于安全车载通信或密钥和证书管理的安全工具。然而,车载计算机或域控制器将塑造未来的 E/E 架构作为中央应用程序,在高度自动化甚至全自动驾驶和 V2X 通信中,车辆将成为一个以软件为主导的系统,这需要集成更多比过去更加广泛和多样化的应用程序。与AUTOSAR Classic 不同,AUTOSAR Adaptive 基于与 LINUX 相关的操作系统,应用程序使用“AUTOSAR 088Runtime for Adaptive Applications”,简称 ARA。此外,自适应平台提供管理程序预配置分区,使不同

    291、供应商独立开发的不同 ASIL 类别的软件组件能够集成到车载计算机中并在其上安全运行。AUTOSAR Adaptive 与其面向服务的架构和额外的功能(如细粒度的无线更新)相一致,还整合了额外的措施并为汽车安全设定了新的标准。传统车内网络通信中,总线通信报文以明文方式传输,攻击者借助简单的采集分析工具对总线通信报文进行抓包提取,通过对原始通信报文的重放或篡改,对车辆进行攻击,可以造成车辆通信总线故障、功能异常,甚至影响行车安全等问题。AUTOSAR 平台提供了安全通信组件 SecOC,在协议数据单元层面为关键数据提供可行、具有资源有效特性的真实性机制。持续的网络信息安全风险管理正成为 VTA

    292、的要求,通过 IDS 车载入侵检测可以为整个车队提供信息安全保护。联合国第 155 号条例(UN R155)以及 ISO/SAE 21434 规定,需要在车辆全生命周期内对整个车队进行持续的网络风险管理。因此,持续的状态监测和基于风险的安全措施将成为汽车信息安全的重要组成部分。针对 V2X 和车辆信息安全,AUTOSAR 标准也提出了一系列的信息安全要求,并增加了入侵检测管理系统(IdsM)、消息签名的加密验证、端到端安全、证书管理、应用程序安全相关机制等。4.3 AUTOSAR 信息安全对策AUTOSAR Classic 和 Adaptive 为保护车辆软件、数据免受操纵和未经授权的访问提供

    293、了重要的模块,来解决汽车网络通信信息的机密性、新鲜性、完整性、真实性以及可用性等问题。针对数据安全,在 Classic 和 Adaptive 版本中,对安全相关应用程序所需的加密原语、密钥和证书的访问都是通过 AUTOSAR 特定的加密堆栈进行的。应用程序随后仅访问提供的接口,独立于它们各自的加密实现,并可移植到不同的 ECU。针对车内总线安全通信,AUTOSAR 标准 SecOC 功能模块为车内网络之间的通信提供了消息完整性、抗重放方面的能力。在协议数据单元层面(PDUs)SecOC 与 AUTOSAR 的通信系统协同,PDU Router负责对接收的消息进行路由,对发送的安全相关协议数据单

    294、元提供给 SecOC 模块。SecOC 随后增加或是处理安全相关信息后,把协议数据单元返回给 PDU Router,由 PDU Router 进行进一步的路由处理。对于车内以太网数据传输的安全,则通过 TLS 和 IPsec 提供真实性和机密性的通信服务。针对访问控制与身份鉴别,AUTOSAR 身份和访问管理模块为应用提供权限隔离以及受攻击时权限越级的保护功能,同时,还能方便集成人员在部署时就能验证应用对于资源的访问权限。自 R20-11 以来,基本的 IdsM 规范已被整合到 AUTOSAR Classic 和 AUTOSAR Adaptive 版本中。事实上,AUTOSAR R20-11

    295、版本是首次为 AUTOSAR 堆栈中的 DIDS 制定了一致的标准。然而,考虑到各种 ECU 的不同,AUTOSAR Classic 往往提供非常有限的资源,该版本中定义的功能范围代表了非常低的共同标准。仅定义了 IDS 的最基本的应用场景和核心的架构,主要目的应该是标准化车内安全事件,以及事件的发送机制,以便云端能理解并处理各种车型上送的安全事件。作为互联和自动驾驶趋势的一部分,与安全相关的车载功能不可避免地会增加。成熟的安全措施以及高安全级别的车载架构平台将有助于解决这些技术挑战。在未来,OEM 也将越来越多地建立基于高度连接的新商业模式,而这种连接需要得到保护。这给了 AUTOSAR A

    296、daptive 进一步发展的一个明确任务,那就是要比 AUTOSAR Classic 更强大地集成安全应用程序。089第5章汽车基础软件信息安全发展挑战汽车基础软件为汽车应用提供支撑性服务,由于其涉及面广泛,其发展面临更加严峻的信息安全挑战,已经成为汽车纵深防御体系的关键部分。从行业整体情况来看,汽车基础软件信息安全问题在法律法规、关键共性技术、行业协同等方面都存在挑战。本章在介绍整体的未来挑战后,重点关注汽车基础软件信息安全与汽车芯片,尤其是关注国密算法在汽车芯片应用与实现;本章还进一步阐述汽车基础软件信息安全与功能安全在分析与设计方面存在的挑战及其方案;最后本章简要概述了汽车基础软件信息安

    297、全产业化情况。5.1 未来的挑战汽车智能化与网联化的发展驱使着软硬件不断升级,电子电气架构朝着域集中式和中央计算式架构不断演进,汽车软件系统也变得更加复杂与开放。与此同时,汽车基础软件介于硬件与应用软件之间,用于屏蔽硬件差异并支撑上层应用,实现软硬件解耦,并提供可靠服务。在上述趋势下,汽车基础软件面临的信息安全问题日益突出。1.已出台汽车相关的政策与法律法规,但在汽车基础软件安全方面细化的法律法规仍需补充完善。目前,在法律法规建设方面,国内外智能网联汽车基础软件信息安全形势十分严峻,各国政府都对汽车基础软件信息安全投入了大量的资源,已初具成果。我国现今也已出台了有关智能网联汽车信息安全的法律法

    298、规,但在许多细化专业领域仍需要进一步落实,例如对于车载操作系统、中间件、虚拟机等基础核心技术服务的专业细分安全法律法规,现阶段受限于技术产业发展,部分基础软件核心技术尚在研究阶段,该领域法律法规还未能及时完善。标准建设方面,现阶段仍缺乏细分领域技术标准,导致商业化量产进程缓慢。建立符合行业主体良性发展的规范标准及相关政策,形成具有科学、完整、统一的机制,对于产业健康有序发展非常关键。2.部分核心技术仍未实现自主可控,行业整体在许多关键问题上仍存在技术挑战。当前,针对汽车基础软件信息安全的系统性解决方案的建设与应用仍存在技术缺口,包括车载芯片软件、车用操作系统、虚拟机、中间件等关键技术中仍面临着

    299、巨大的安全隐患和挑战。例如,硬件安全芯片已被用于保障智能网联汽车安全,相关外企研发出硬件安全模块(HSM,Hardware Security Mod-ule),并嵌入加密算法、访问控制、完整性检查等技术到汽车控制系统,但是目前 HSM 仍然不支持国密算法,存在技术壁垒,未能实现国产自主可控。此外,针对智能汽车操作系统的缓冲区溢出攻击、渗透扫描、漏洞扫描等行为使得智能汽车基础软件存在巨大的安全隐患,对于挖掘车用操作系统、虚拟机、中间件等核心组件服务的安全漏洞的能力有待进一步加强。与此同时,整体行业存在一些关键的技术问题尚未解决。例如,汽车由于资源受限性,使得一些传统网络安全技术难以直接应用于汽车

    300、,需要在安全性和轻量化之间做出平衡;基础软件的信息安全影响系统的功能安全,在复杂场景下如何实现自动驾驶的综合安全仍未解决;此外,基础软件信息安全在可用性、机密性、完整性等多个安全属性的增强、测试与验证方面都存在挑战。0903.产业主体协同性需加强,标准有效的汽车基础软件安全方案仍须行业协同构建。当前,行业上下游主体在跨部门、跨组织协同合作方面存在一定的障碍,基础软件安全生产过程管控与安全风险防护机制普遍尚未建立,进而无法定义明确的安全职责。在防范汽车基础软件网络安全风险方面缺乏处置和应对能力,尚未建设完善的基础软件供应链安全保障机制。此外,由于汽车是多产品、多方案的集成,保障智能汽车基础软件信

    301、息安全,需要多方协同。虽然行业目前已出现了诸如 AUTOSAR等实现标准,但它仅提供了一个通用性的框架,各方在具体实现细节和侧重点方面仍有差异,这使得集成不同产品与方案,仍然存在诸多冲突与挑战,需要产业主体协同构建标准有效的汽车基础软件安全方案。总的来说,智能网联汽车的体系大而复杂,在汽车信息安全防护上,基础软件的信息安全保障是汽车形成信息安全纵深防御体系的关键部分,在政策制定、关键技术、关键标准和多方协同上仍存在诸多挑战。5.2 汽车芯片和汽车基础软件信息安全当前,硬件安全芯片已经成为抵御攻击、保障智能网联汽车安全可控的重要手段,已有相关企业研发出硬件安全模块 HSM,将加密算法、访问控制、

    302、完整性检查嵌入到汽车控制系统,以加强 ECU 的安全性,提升安全级别。但是目前汽车电子行业的痛点主要包括垄断加剧、本土设计缺失、技术支持匮乏和供货没有保障等几大问题。与此同时,虽然汽车信息安全日益重要,但是国外半导体公司的产品并不支持国密算法,一款支持国密标准的国产汽车硬件安全模块对行业十分重要。国密算法是我国自主研发创新的一套数据加密处理系列算法,随着我国智能汽车信息安全的要求,需要将国密算法嵌入到硬件加密芯片中结合使用。但是在汽车行业,由于汽车芯片设计门槛高,研发周期长,资金投入多,很少有支持国密算法的汽车芯片,尤其是像高性能汽车处理器这样的芯片,目前国内市场缺乏支持国密的汽车处理器芯片。

    303、但为了保障车联网安全,越来越多的车厂引入国密算法,保障车辆通信安全。当前汽车在不同域上运行不同的操作系统,包括:1.高可靠功能安全处理器芯片运行 AUTOSAR 操作系统,提供的功能包括车机接口、safety 管理和车身控制功能;2.高安全密码处理器芯片运行 RTOS 操作系统,提供资源管理、HSM、密钥管理、生命周期管理、加解密算法的运算服务等功能;3.高性能处理器芯片运行 RTOS 或 AUTOSAR 系统,执行大数据量的计算、外设控制及显示相关的操作等功能,其中,各操作系统只可以通过 mailbox 通信,分别运行在物理隔离的硬件环境中。在芯片设计过程中也需要确保信息安全,芯片在设计时应

    304、考虑加密算法的安全性和独立性。其中,硬件加密模块同步传输加密的数据,可保障数据的安全性,例如可引入芯片监测功能,以防止恶意读取或者篡改数据,保障整个芯片的安全。高安全密码处理器芯片是芯片安全的核心,其中密码模块负责安全相关功能的处理部分,包括有对称密码算法、公钥密码算法、哈希算法和随机数发生器模块,具有 OTP(eFuse)存储密钥和芯片敏感信息,采用安全 Mailbox 与外部进行通信。高安全密码处理器芯片的软件部分包括 ROM 固件和系统固件,支持安全启动、安全算法、密钥管理、芯片自测试、芯片异常处理等功能。高安全密码处理器芯片要求分层次的隔离,首先,安全域外的软件硬件只能通过 Mailb

    305、ox 与安全域进行通信。第二,高安全密码域内硬件存储,有专门的硬件用于存储最敏感的信息,这部分内容,即便是高安全密码域内的 CPU 也无法访问,只能够通过硬件专用接口使用,使用过程有鉴权保护。0915.3 汽车基础软件信息安全与功能安全5.3.1 汽车基础软件信息安全和功能安全的分析方法模型由于汽车基础软件涉及的范围广,承载和服务的功能场景多样,不同 ECU 的功能各不相同,同一ECU 在不同场景下功能不同,相应的信息安全和功能安全分析方法需要进一步优化。针对汽车基础软件,功能安全和信息安全相互影响,且存在很多交叉重叠区域。在正向开发阶段,需要对基础软件及相关硬件载体进行功能安全和信息安全的并

    306、行设计和分析评估,充分分析并发现功能安全和信息安全的目标和范围,并为后续开展功能安全设计和信息安全加固方案提供指导。典型的信息安全分析方法包括:1.STRIDE 威胁分析模型是微软安全工程和通信部门开发的威胁建模的系统方法,是安全开发生命周期(SDL)中一部分,对系统面临的威胁进行分类从而辅助系统设计人员改进系统的安全性设计。2.攻击树模型将攻击目标逐级细分成单个攻击手段和相应的攻击路径,用于分析系统所面临的安全威胁。提供了一种思维方式,帮助开发者站在攻击者的角度来思考系统可能存在的漏洞,此方法很大程度上依赖于具备的黑客经验。3.HEAVENS 模型是较完整的风险评估的方法,在 SAE J30

    307、61 中有相应内容的介绍,其在汽车信息安全领域(包括汽车基础软件)具有很强的应用实际。影响等级指对汽车发动攻击后表示产生危害的相关等级,分为人身安全、财产、操作、隐私及法规等四类因子。现阶段,基于功能安全的危害分析,进一步开展针对信息安全的威胁分析,实现对基础软件的危害分析水平、风险评估能力以及安全目标设计的合理性。未来,汽车基础软件的功能安全设计,为其信息安全威胁场景识别、攻击影响程度分析、安全事件应急处置响应提供关键信息来源。同时,汽车基础软件的功能安全设计,也将受到信息安全对电子电气架构的安全策略部署及对策措施的影响。ISO 26262 标准中定义的整个功能安全工作流程,首先是从相关项定

    308、义开始的,继而进入危害事件分析、评估与危害事件相关的风险评估,这个识别和分析过程被称之为危害分析和风险评估(Hazard Analysis and Risk Assessment,简称为 HARA)。HARA 的目的是:识别可能导致 E/E 系统危害的潜在顶层故障类型,并结合具体行驶工况场景,来评估与其相关的危险程度,然后其结果被用来制定需要达成的安全目标(Safety Goal),从而保证车辆能够在故障条件下,在预期的故障响应时间(FTTI)之内能够进入预期的安全状态(Safe State)。结合汽车基础软件的功能定义和应用场景来定义安全防护措施,区分出汽车基础软件的基本功能和增量功能,来分

    309、别定义基线功能集和增量功能集。举例说明:对于网关产品,基础功能是完成车内的数据路由转发功能,部署防火墙功能是基线功能;而在某些场景下,增量功能可能是网关要支持远程程序升级的功能,则针对于增量功能需要部署刷新完整性和机密性校验措施,例如,刷新包的数字签名和刷新包加密存储措施。5.3.2 汽车基础软件信息安全加固机制与功能安全优化设计汽车基础软件研发离不开协作,例如,对于密钥等高度敏感数据的管理,包括密钥的生成、传递、存储、使用、更新、注销等环节,要实现完善的管理机制需要跨部门(研发、测试、生产和 IT 等部门),跨公司(整车厂 OEM、零部件供应商 Tier1 和后台运营公司等)之间的多方协作,

    310、确保在整个环节中做到敏感数据的妥善管理。除此之外,在整个汽车基础软件研发的生命周期内的诸多环节,都需要建立和强化协作机制。有必要提供对资产、威胁、安全属性和安全级别进行评估的列表。研发人员根据列表中的安全级别,确定开发优先级。有可能存在一个资产会存在多个威胁,因此这个资产也会有多个安全等级,在进行开092发的时候,通常的做法是关注安全等级最高的。一方面,针对的是由于安全相关的电子电气系统的一些故障行为而可能造成的一些危害,其中包括这些系统互相作用而可能造成的危害。ISO 26262 标准在汽车安全上提供了一个生命周期理念(管理,开发,生产,经营,服务,报废),并且在这些生命周期的各个阶段提供了

    311、必要的支持。标准覆盖了功能安全方面的整体开发过程(包括需求,设计,实施,集成,验证,确认和配置)。另一方面,针对的是恶意的网络攻击对财产、隐私、车辆操作及安全造成的威胁。所以,功能安全相关系统可以是信息安全相关系统,然而信息安全相关系统不全是功能安全相关。虽然信息安全和功能安全属于不同的两个技术领域,但是功能安全的技术开发流程可以应用于信息安全,例如风险评估、危害分析等流程。围绕汽车基础软件的产品信息安全开发能力,需要涵盖从系统开发、软硬件开发、生产、测试和运维等多方面的能力,然而目前很多公司没有办法打通并落地实施每个环节中的要求。首先,需要建立和加强信息安全的开发流程体系,其次,加强开发能力

    312、的建设,包括技术规范要求建设、开发流程体系建设、工具链建设等,此外,产品研发活动中的信息安全要求需要规范化。汽车基础软件上已经在部署一定的信息安全防护技术措施了。然而,由于不同汽车基础软件的应用场景和功能定义不尽相同,不同厂商的设计开发思路不尽相同,导致当前汽车基础软件的信息安全技术开发路线较难有统一的共识。而且,汽车基础软件因计算能力和系统资源的限制,较难部署复杂的信息安全防护措施。在具体的开发过程中还需要考虑多种技术限制,按需选择适合的技术方案并落地实施。5.4 汽车基础软件信息安全产业化智能网联汽车基础软件信息安全产业是一个新兴产业,其产业格局和产品形态仍处于初级探索阶段。根据中国汽车软

    313、件行业协会发布的2022 中国汽车软件产业发展白皮书(框架)显示,中国汽车软件行业从无到迈向标准化用了 30 年时间,目前处于快速发展时期,年增速保持在 11%以上,预计 2023年市场规模将达到 351 亿元。面对汽车软件产业的庞大规模,软件信息安全问题不容忽视。智能网联汽车对实时性、可靠性的要求比传统互联网要高得多,整车级的信息安全解决方案需要融合信息安全、汽车电子电气架构等多个领域的技术,主机厂与信息安全服务商等相关方之间还没有形成完整的产业链,这使得汽车信息安全产品落地更加困难。下面将从安全芯片、系统安全、数据通讯安全、漏洞挖掘四个方面来介绍汽车信息安全产业化现状。在安全芯片方面,具有

    314、数据加解密、身份认证鉴权、安全存储密钥功能和防攻击设计的安全芯片已经广泛应用在汽车行业,通过使用安全芯片来增强智能网联汽车安全防护已成为趋势。如 5.2 中所提到的主流汽车芯片制造商:英飞凌、恩智浦、Renesas 以及意法半导体,已生产出多款搭载硬件安全模块(HSM)的多核处理器,例如 AURIX TC397、MPC5748、Renesas R-Car、SPC5。HSM 作为安全处理器被广泛应用在汽车安全关键功能的 ECU 中,为 ECU 提供完整性检测、通信的加密保护、安全数据存储以及身份验证等服务。HSM 的引入使得 ECU 的主机核心可以将资源全部用于处理其它计算任务,这给 ECU 的

    315、制造厂商提供了方便且强大的即插即用安全解决方案,各制造商可以根据不同程度的安全需求定制方案。根据 360 Market Updates 的数据显示,HSM 市场预计将在 2026 年底达到 27.5 亿美元。OEM 和一级供应商正在提供的 HSM 固件产品主要包括:CycurHSM 是 ESCRYPT 的一款灵活的新 HSM 固件,其可以保护 ECU 的安全启动、安全通讯、安全更新以及车内零部件。Vector 作为知名的 AUTOSAR 底层软件供应商,基于在基础软件和网络信息安全领域的经验,开093发了用以支持 HSM 的固件 vHSM,可以支持目前大部分具有 HSM 的 MCU。EB ze

    316、ntur 是面向 HSM 的性能与资源优化解决方案,用于访问加密硬件加速器或为所选算法提供软件实现。同时也支持其他安全关键功能,如安全启动和固件更新,可集成到多种操作系统中,为车辆提供端到端的安全。在系统安全方面,由于汽车各个部件对安全需求程度不一样,通常需要使用不同的操作系统(安卓、QNX 等),而汽车上的软硬件资源是十分有限的。为此,汽车行业提出了车载虚拟机技术,能按照产品需求在不同的 GuestOS(VM)中分配硬件和软件资源。车载虚拟机技术对安全等级的要求很高,有能力提供此类安全产品的供应商非常少,大部分的虚拟化系统供应商都来自国外,主流的解决方案有:黑莓旗下的 QNX Hypervi

    317、sor 是目前成熟的 Hypervisor 操作系统,占据了高达 60%的市场份额,可提供通用的开发工具,以满足车辆中安全关键型和非安全型 ECU 的需求,并为安全通信、安全图形、安全系统库和中间件提供解决方案。ACRN Hypervisor 具备灵活、轻量级的特点,兼顾实时性和关键安全性,并通过开源平台为精简嵌入式开发进行优化。INTEGRITY Multivisor 是业界唯一经过安全认证的架构,可在各种多核 SoC 硬件上同时运行一个或多个 Guest OS 以及关键任务功能,能够在不影响安全或性能的情况下实现快速且成本效益最高的复杂系统设计。在有限资源的约束下,未来车载系统的安全防护方

    318、案将继续往轻量化方向发展。例如,在验证系统的完整性时,可采取仅度量关键对象、设计合适的度量点等轻量化方案。在数据通讯安全方面,安全隐患主要存在于云端、网络传输层、车载通信层、外部接口。因此需要分层构建入侵检测系统,采取主动防护的方案以保证数据通讯安全。在车载通信层,AUTOSAR 提出了基于消息验证码(MAC)和新鲜度值(FV)的安全板载通信模块(SecOC),以保证车载网络通信的完整性和真实性。在整车数据通讯安全方面,各厂商通过部署入侵检测系统(IDS)来识别对车辆的攻击,主要有:天融信推出的车载入侵检测系统搭载了车端安全检测引擎,以 SDK 形式轻量化部署于车端,可实时对车内安全事件进行深

    319、度检测,精准识别攻击和异常行为。不仅可以保障车内关键组件(T-BOX、中央网关等)的安全通信,同时能与云端平台进行联动,实现安全事件的预警、感知、评估。中汽创智开发的车辆入侵监测防御系统(IDPS)基于 AUTOSAR 架构设计,具备自适应、高性能的技术特点,支持报文的上下文检测以及信息熵检测,支持自动化规则生成,实现检测引擎和规则代码的解耦,大幅提高适配效率,实现了信息安全与功能安全联动的 MCU 入侵检测。以色列的汽车网络安全头部公司 Argus 长期专注于汽车网络信息安全解决方案的设计,在 2017年被大陆公司收购。Argus 通过分层的方式为车载网络、ECU 等关键功能提供了安全防护,

    320、在具有安全关键特性的 ECU 之间设立了安全通信通道,并制定了过滤规则库来保护 ECU,使用了上下文感知的启发式以及机器学习算法,能高效的检测并实时阻止针对车载网络的网络威胁和网络攻击。在漏洞挖掘方面,被广泛用于智能汽车和工业制造中的实时操作系统 RTOS 的代码规模不断扩大,越来越多新特性发布的同时也产生了很多潜在的安全漏洞,其中系统内核方面的漏洞尤其值得关注。根据统计,在过去的十几年中,CVE 漏洞信息库中新报告的漏洞中,最多的是 Linux 操作系统内核漏洞。094当前流行的漏洞挖掘方法主要有:静态分析、符号执行、污点分析、模糊测试等。从在各类操作系统上实际应用效果来看,由于污点分析和符

    321、号执行等方法受限于操作系统的代码复杂度,针对操作系统内核漏洞的挖掘效果并不理想。静态分析和模糊测试是当前操作系统内核测试方面较为主流的漏洞挖掘方法。代码静态分析工具 White Source SAST 提供了软件漏洞检测的解决方案,用于对应用程序源代码执行广泛的安全分析,通过自动化代码分析的方式,有效替代高要求并且耗时的人工代码审查过程,可以快速并准确地分析大型和复杂项目的源代码,提供准确的结果和低误报率。基于覆盖引导的模糊测试方法设计的内核模糊器是目前较为先进的内核模糊测试工具,其中以 Google 推出的 Syzkaller 内核模糊测试器使用最为广泛。汽车新四化的浪潮下,汽车基础软件相关

    322、产业整体发展较快,产品迭代、技术更新发展势头迅猛。从国产化水平来看,目前已经能在相关产品上看到一些国内厂商的身影。然而,从发展水平来看,仍然存在较大的短板。汽车基础软件介于硬件和软件之间,国内相关行业发展并不平衡,国内仍较多关注于基础软件向上层提供服务,例如入侵检测等应用,对于芯片、操作系统等偏下层的产业化仍与国际先进水平有差距。随着我国近年来对汽车芯片、操作系统、信息安全等方面的持续投入,相信很快会迎来汽车基础软件信息安全的快速发展。095第6章汽车基础软件信息安全标准化建议6.1 标准化的总体思路、目标信息安全是汽车基础软件产品安全及可靠运行的重要保障。一方面基础软件所具备的基础性机制和功

    323、能能够为汽车的上层应用软件提供信息安全方面的支撑,另一方面基础软件自身的安全性也对上层应用软件乃至系统整体的安全性产生影响。相比汽车的应用,从有利于产业生态发展的角度,汽车基础软件未来将更加开放和标准化,由于不可避免的设计或实现上的缺陷,对其脆弱性的认知会更加广泛,遭受安全威胁和攻击的可能性也越大。针对汽车基础软件的攻击,可以直接影响到汽车的功能安全和人身安全,也会涉及到重要数据及个人隐私数据等的安全。制定关于汽车基础软件的信息安全标准,对于定义汽车基础软件的安全基线,指导行业在汽车基础软件的需求、设计、开发、实现、验证等阶段同步开展信息安全相关的实践,具有重要的、积极的意义。如第二章所述,根

    324、据国家相关部委、标准化组织发布的关于智能(网联)汽车的标准化指导思想以及标准体系规划,有关汽车网络安全/信息安全的标准体系也正在加速建设中,其中也涉及了汽车基础软件信息安全的内容。因此有关汽车基础软件信息安全的标准建设,需要与目前已立项在研的关于汽车基础软件,如车载操作系统、车控操作系统等的国标、行标内容相协调,基于相关国标、行标所定义的有关汽车基础软件的框架及总体要求,从细化信息安全相关要求、提供参考规范的角度,开展团体标准的研制,作为国标、行标的补充,更利于指导开发实践。6.2 标准化建议表6.2-1 标准化建议标准化项目内容概述编制时间汽车基础软件信息安全生命周期指南从软件生命周期安全保

    325、障的角度,提出对汽车基础软件开发过程中与信息安全有关的过程要求,包括软件安全需求、安全设计、安全实现、安全测试、安全验证、安全评估、安全更新、安全消亡等环节,以及有关的支持过程要求。2023.01-2023.12车控操作系统信息安全技术规范针对车控操作系统的特点,从硬件安全架构的支持与利用、安全通信、应用软件安全防护、系统安全防护、安全可信启动、访问控制与身份鉴别、安全监测、日志与审计等方面对其信息安全技术给出规范性要求。2023.01-2023.12车载操作系统信息安全技术规范针对车载操作系统的特点,从硬件安全架构的支持与利用、安全通信、应用软件安全防护、系统安全防护、安全可信启动、访问控制

    326、与身份鉴别、安全监测、日志与审计等方面对其信息安全技术给出规范性要求。2023.01-2023.12096标准化项目内容概述编制时间车控操作系统信息安全测试规程根据车控操作系统信息安全技术规范的内容,给出对相应技术规范的测试方法、测试用例、测试步骤等的说明。2023.07-2024.06车载操作系统信息安全测试规程根据车载操作系统信息安全技术规范的内容,给出对相应技术规范的测试方法、测试用例、测试步骤等的说明。2023.07-2024.06汽车基础软件数据安全技术规范与测试方法基于相关法规、标准对汽车数据安全的要求,对汽车基础软件中涉及的数据分类分级、数据的采集、存储、传输、共享、访问、使用、

    327、销毁等生命周期活动的安全提出有关的技术要求与测试方法。2023.10-2024.09汽车基础软件代码安全技术规范与测试方法从汽车基础软件代码自身安全的角度,包括编码规范与规则、漏洞/脆弱性、以及相关安全加固技术的使用等,提出技术要求与测试方法。2023.10-2024.09汽车嵌入式设备密码应用规范基于硬件安全模块、安全芯片等提供的密码运算、密钥/证书存储、密钥/证书管理等方面的能力,规范有关硬件安全模块、安全芯片的驱动程序、抽象的访问接口,以及密码服务管理等方面的内容2024.01-2024.12097第7章汽车基础软件信息安全典型案例7.1 操作系统内核-中兴通讯7.1.1 背景描述车联网

    328、时代,汽车通过基础软件系统可与智能终端、互联网等进行连接,实现娱乐、导航、交通信息等服务。基础软件系统常基于 Linux、QNX 等操作系统内核开发,由于操作系统内核代码庞大且存在不同程度的安全漏洞,操作系统内核自身的安全脆弱性将直接导致应用系统的面临被恶意入侵、控制的风险。车载基础软件系统需要通过 Wi-Fi、蓝牙、移动通信(4G/5G 等)、V2X 等无线通信手段与人、其它车辆、交通专网、互联网等进行连接。上述无线通信方式自身可能就存在网络加密、认证等方面的安全问题,因而也会继承上述通信网络所面临的安全风险。针对这些问题,可以通过从操作系统内核层面采用由系统加固、主动防御、防火墙、入侵检测

    329、与防护系统(IDPS)、硬件安全加密服务等构成综合解决方案。7.1.2 实现概要基础软件系统的信息安全架构可以参考下图,从硬件、操作系统内核、基础中间件和服务,再到应用服务框架和应用,不同的层次采用不同的信息安全技术提供系统保障。图7.1-1 基础软件系统的信息安全架构在操作系统内核层面,可采用系统加固、安全启动,动态主动防御等技术来提高系统的安全水平。亦可采用防火墙、入侵检测系统(IDS)、网络分割等技术来应对来自网络的攻击。098操作系统内核功能安全模块描述:1.系统加固遵循最小化原则:移除不必要的服务程序,关闭不需要的端口和服务;移除开发、编译、调测类、网络嗅探类的服务和工具;去除安装、

    330、显示和调整系统安全策略的服务和工具;检查不应存在任何后门和隐藏接口。系统定期执行漏洞扫描,对发现的安全漏洞及时处理。2.现有的安全技术已经解决了大多数的信息安全威胁,是重要的系统防御手段,但是这些技术大多属于被动防御,不能解决越来越多的未知威胁。中兴操作系统内核实施“主动防御”策略,利用底层基础软件(操作系统、工具链)对整个系统引入动态、随机、多样的安全基因。使整个系统具有天然抵抗各种“病毒”(包括未知威胁)的能力。图7.1-2 主动防御技术路线主动防御技术改变攻击过程所依赖的系统规律,通过编译器产生具有随机、多样性特征的多变体,使攻击路径呈现为随机、多样的特征。具体采用了全局符号(全局变量、

    331、函数等)布局随机变化技术、关键数据结构布局随机变化技术、程序的地址空间(代码段、数据段等)随机变化技术,将单一空间下未知的安全问题转换为多维空间下确定的概率问题,显著提高了系统的安全性。3.防火墙可以提供针对特定端口或 IP 的访问控制实现防 DDos 攻击功能,实现对报文的安全过滤,拦截非法数据,避免其进入安全区域。防火墙的相关数据(如拦截数据流量、防火墙故障状态和防火墙规则数量等)也可以存储在相应的安全区域,并及时上报或转发其它模块处理。4.IDS 是计算机的监视系统,它通过实时监视系统,一旦发现异常情况就发出警告。IETF 将一个入侵检测系统分为四个组件:(1)事件产生器(Event g

    332、enerators),它的目的是从整个计算环境中获得事件,并向系统的其他部分提供此事件。(2)事件分析器(Event analyzers),它经过分析得到数据,并产生分析结果。(3)响应单元(Response units),它是对分析结果作出反应的功能单元,它可以作出切断连接、改变文件属性等强烈反应,也可以只是简单的报警。(4)事件数据库(Event databases)事件数据库是存放各种中间和最终数据的地方的统称,它可099以是复杂的数据库,也可以是简单的文本文件。7.1.3 实现详细(入侵检测)车载网络防火墙位于整车架构最外围,如 OBD 口或远程通信的入口。可以在网络层通过数据包过滤,

    333、基于目标地址及源地址对数据包进行过滤,也可以采用基于传输层会话控制能力的状态检测,建立状态连接表,来跟踪每一个进出网络的会话状态信息,监控了数据包是否符合会话所处的状态。针对 TCP,防火墙会对 TCP 头信息进行解析,用于确认是首次连接或已经建立通信,因此不仅能减少数据包穿过防火墙的时间,同时可以有效检测出 DoS 攻击。入侵检测系统根据入侵检测的行为分为两种模式:异常检测和误用检测。前者先要建立一个系统访问正常行为的模型,凡是访问者不符合这个模型的行为将被断定为入侵;后者则相反,先要将所有可能发生的不利的不可接受的行为归纳建立一个模型,凡是访问者符合这个模型的行为将被断定为入侵。这两种模式的安全策略是完全不同的,而且,它们各有长处和短处:异常检测的漏报率很低,但是不符合正常行为模式的行为并不见得就是恶意攻击,因此这种策略误报率较高;误用检测由于直接匹配比对异常的不可接受的行为模式,因此

    展开阅读全文
    提示  三个皮匠报告文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:中国汽车工业协会:中国汽车基础软件信息安全研究报告1.0(2022)(125页).pdf
    链接地址:https://www.sgpjbg.com/baogao/107203.html
    联系我们 - 网站声明 - 网站公告 - 侵权处理 - 免责声明 - 版权申诉 - 关于我们 - 常见问题 - 网站地图 - 用户协议 - 认证协议

    copyright@ 2008-2013        长沙景略智创信息技术有限公司版权所有
    公安局案号:湘公网安备 43010402001071号 | 工信部备案号:湘ICP备17000430号-2 | ICP经营许可证:湘B2-20190120 | 出版物经营许可证:新出发岳文字第43010420211号