汽车基础软件信息安全关键技术

来源:智能汽车开发者平台


一、信息安全基础概念

首先我们来了解一下信息安全的基础概念包括机密性、完整性、可用性、和不可抵赖性,每个属性的主要表现均不相同。

1. 机密性

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

2.完整性

该属性的关键是保护数据不被未授权方修改或删除,防止由于如通信或者固件被篡改导致的黑客利用。具体需要重点防护的数据包括车辆控制器内关键的配置参数、固件、操作系统、个人资料、通信报文信息等。常用于完整性保护的技术手段包括消息校验码、数字签名、安全启动等。

3. 可用性

可用性是在某个考察时间,系统能够正常运行的概率或时间占有率期望值。为保证可用性,可以采用冗余的方式进行,包括报文信号的冗余、传感器 / 控制器 / 执行器的冗余、控制信号通道的冗余以及供电等基础设施的冗余等。

4. 不可抵赖性

不可抵赖性主要应用在电子商务领域,如移动支付等场景,保证用户对自己行为的不可抵赖及对行为发生时间的不可抵赖。通过进行身份认证和数字签名可以避免对交易行为的抵赖,通过数字时间戳可以避免对行为发生的抵赖。


二、常见安全分析模型

1.STRIDE 安全建模

STRIDE安全建模方法最早是由微软提出的,主要应对六种威胁:身份假冒、篡改、抵赖、信息泄露、拒绝服务、特权提升,如下图。


那STRIDE分析方法的流程是什么呢?

第一步:绘制数据流图。根据功能逻辑,绘制数据在实体间的传递和存储。其中数据流图包含四个要素:实体、数据处理、数据存储、数据流。其中实体代表处理数据的用户、设备等实体;数据处理表示针对数据的处理过程,有输入输出路径;数据存储表示存储数据的内部实体,如数据库、消息队列、文件等;数据流表示实体与数据处理、数据处理之间或数据处理与数据存储之间的交互。


第二步:识别威胁。STRIDE威胁建模方法已经明确了每个数据流图元素具有不同的威胁,其中外部实体只有仿冒(S)、抵赖(R)威胁,数据流只有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,出来过程有所有六种(STRIDE)威胁,存储过程有篡改(T) ,信息泄露(I)、拒绝服务(D)威胁,但如果是日志类型存储则还有抵赖(R)威胁。具体可以对照如下表格进行识别。


第三步:确定应对措施。针对不同的威胁确定应对措施,如为检测存储数据的篡改可以通过消息校验码、签名等方式进行检测。若实体的假冒导致了危害,可以通过身份认证方式进行。参考的应对措施如下表:


第四步:安全验证。在威胁建模完成后,需要对整个过程进行回顾,不仅要确认缓解措施是否能够真正缓解潜在威胁,同时验证数据流图是否符合设计,代码实现是否符合预期设计,所有的威胁是否都有相应的缓解措施。最后威胁家命名报告留存档案,座位后续迭代开发、增量开发时威胁建模的参考依据。

2. HEAVENS 安全模型

根据 SAEJ3061 法规,可以使用 HEAVENS 安全模型进行风险等级评估,包括威胁等级评估,影响等级评估,并最终得到影响等级,并确定安全需求。


威胁分析 – 功能用例的描述是威胁分析过程的输入。威胁分析产生两个输出:(1)每个资产的威胁和资产之间的映射和(2)威胁与安全属性之间的映射以确定哪些安全属性因资产上下文中的特定威胁而受到影响。

风险评估 – 一旦确定了相关资产的威胁,下一步就是对威胁进行排序。这是风险评估期间所做的工作。威胁和资产之间的映射与威胁级别(TL)和影响级别(IL)参数一起用作输入。威胁级别参数(威胁级别(TL))和影响级别参数。作为风险评估的威胁分析 – 功能用例的描述是威胁分析过程的输入。





三、汽车基础软件信息安全生命周期

1、概念开发阶段

概念开发阶段主要的目的是通过整车功能,如远程控制功能、转向功能等的分析,应用信息安全分析模型识别信息安全漏洞,评估安全等级。针对安全等级较高的漏洞设计安全机制来应对黑客的攻击。

信息安全的实现并非是通过独立的安全机制可以实现的,需要进行信息安全纵深防御体系设计。从云端 - 车云通讯 - 车端控制器 - 应用软件 - 基础软件 - 硬件等多个维度进行层层防御,设计相应的安全措施提升安全性。基础软件的安全需求主要来自以下两个方面:

1. 实现更高一级来自于功能 / 控制器的信息安全需求。如特定控制器需实现加密通讯,基础软件需要保证安全通讯协议、密钥管理、加密认证、加密存储等功能

2. 基础软件自身安全的要求。为保证上述功能的安全实现不被绕过,基础软件还需保证自身的安全,如不存在公开漏洞、安全启动等。

2、产品开发阶段

软件安全需要基于完整的安全分析进行设计,从硬件的安全信任根开始,保证每层的程序调用都是基于经过验证的,包括程序完整性的验证,访问权限的验证,参数合理性验证等。

软件实现过程是一个容易引入信息安全问题的过程,有三个方面需要重点关注:

1. 开源代码。随着业界开源的范围越来越广,从操作系统到基础软件、加密算法,都有很多开源库供程序编写人员使用,虽加快了软件实现的速度,但是良莠不齐的开源库也会带来很多信息安全问题。有些开源库长期无人维护,已存在大量的漏洞,若不加鉴别直接使用,就会导致整个系统漏洞百出。因此在使用开源代码时,优先选择得到持续支持的开源库,并且持续关注其信息安全相关的补丁,并及时进行更新。

2. 开发周期长。汽车行业相较于功能先进性,控制器的稳定性是更加追求的要素。一款车型开发周期动辄 2-3 年,使用的软件版本也是相对成熟。这就会导致在车辆开发过程中,所使用的软件就可能被挖掘出多个漏洞,若不及时进行更新或者修复漏洞,刚上市的新车就可能有很多已知漏洞的存在。因此,在正式量产之前,一定需要对其产品进行漏洞扫描,防止已知漏洞的存在。

3. 开发人员信息安全意识缺乏。在程序开发过程中,由于进度要求,开发人员天然会更加关注功能的实现,而对信息安全的防护意识不足,导致实现的程序遗留了可以被黑客利用的漏洞。因此,加强开发人员的信息安全意识,加强程序释放过程中信息安全的检测势在必行。

在完成基础软件的开发后,需要针对其安全性进行测试,包括软件本身是否正确实现相关需求以及是否有未知漏洞两个方面进行测试。

1.静态代码检查,可以通过商业工具如 QAC 进行静态代码检查,保证其符合 CERT C 等信息安全代码规范;


2.需求一致性测试,通过单元测试、集成测试等方法,确定软件的实现与软件设计需求保持一致;


在保证软件实现与需求一致后,需要通过以下三种测试手段确认软件的安全性:

漏洞扫描,通过漏洞扫描软件如 defensecode 进行现有漏洞的扫描,防止软件存在已知漏洞;

模糊测试,通过大量的随机请求,测试软件的鲁棒性,探测其是否有未知漏洞;

渗透测试,通过专业渗透人员的分析,寻找程序逻辑中的漏洞,并尝试进行利用。若发现新的漏洞,则反馈给开发人员进行修正。

3.后开发阶段(生产、运维、报废)

在生产阶段,要保证基础软件和应用软件在产线的正常刷写。产线软件的注入需要保证刷写方经过认证,例如供应商完成基础软件的刷写,内部包含初始密钥。OEM 在产线刷写更新密钥、证书、配置等内容前,需首先完成与控制器的相互认证。

信息安全是一个动态的过程,在软件使用过程中,随着技术的进步,之前安全的软件可能会出现(或发现)新的漏洞。因此软件维护人员需持续监控最新的漏洞消息,及时更新相关软件补丁,保持软件的安全性。在更新过程中,也需保证对更新源的认证,更新软件完整性校验,版本校验,防止黑客利用更新的漏洞进行软件的恶意修改。

在车辆的使用过程中,控制器内可能存储了大量的用户使用信息。在车辆的报废 / 买卖,或者某一部件的更换的情况下,用户信息会有泄露风险。为保证车辆的数据安全,基础软件需支持敏感数据(如密钥、证书、用户资料、指纹识别信息等)的一键销毁。


四、汽车基础软件信息安全需求

信息安全的实现并非是通过独立的安全机制可以实现的,需要进行信息安全纵深防御体系设计。从云端 - 车云通讯 - 车端控制器 - 应用软件 - 基础软件 - 硬件等多个维度进行层层防御,设计相应的安全措施提升安全性。基础软件的安全需求主要来自以下两个方面:

1. 实现更高一级来自于功能 / 控制器的信息安全需求。如特定控制器需实现加密通讯,基础软件需要保证安全通讯协议、密钥管理、加密认证、加密存储等功能。

2. 基础软件自身安全的要求。为保证上述功能的安全实现不被绕过,基础软件还需保证自身的安全,如不存在公开漏洞、安全启动等。

1. 安全启动

安全启动(SecureBoot)是 MCU 的基本功能,通过硬件加密模块来实现,该机制必须独立于用户程序运行,不能被破坏。作为整个安全启动信任链的基础,安全启动必须主要用于在 MCU 启动之后,用户程序执行之前,对用户定义的 Flash 中关键程序的数据完整性和真实性进行验证,确定是否被篡改。如果验证失败,说明 MCU 处于不可信的状态,部分功能甚至整个程序不能运行。

2. 安全通信

在目前的车载网络中,大部分数据传输都是在没任何安全措施的情况下进行的。例如应用最广的CAN 通讯设计之初是没有考虑过信息安全问题的,其明文传输、报文广播传输、极少网络分段等特性,让进入整车网络的黑客如同进了游乐场,轻松便可以伪造报文对车辆进行控制。

SecOC 是在 AUTOSAR 软件包中添加的信息安全组件(组件位置及可应用的通讯方式如下图所示),该 Feature 增加了 CMAC 运算、秘钥管理、新鲜值管理和分发等一系列的功能和新要求。SecOC 模块在PDU 级别上为关键数据提供有效可行的身份验证机制,认证机制与当前的 AUTOSAR 通信系统无缝集成,同时对资源消耗的影响应尽可能小,以便为旧系统提供附加保护。


此外,车云通讯的安全性主要依靠 TLS/SSL 协议保证。TLS 协议采用主从式架构模型,用于在两个应用程序间透过网络创建起安全的连接,防止在交换数据时受到窃听及篡改。

3. 安全诊断

一些用于将例程或数据下载 / 上传到服务器以及从服务器读取特定内存位置的诊断服务可能需要进行身份验证。不正确的程序或下载到服务器的数据可能会潜在地损害电子设备或其他车辆部件,或可能违背车辆的排放或安全等标准。另一方面,当从服务器检索数据时,可能会违反数据安全性。因此需在这些服务执行前,要求客户证明其身份,在合法身份确认之后,才允许其访问数据和诊断服务。

所以安全诊断是通过某种认证算法来确认客户端的身份,并决定客户端是否被允许访问。可以通过对随机数种子生成的非对称签名进行验证或者通过基于对称加密算法的消息校验码来验证其身份。


4. 安全调试

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

5. 安全升级

随着越来越复杂的网络环境,在软件升级更新过程中,保证升级包的发布来源有效、不被篡改、数据不丢失以及升级内容不被恶意获取变得越来越重要。

传统升级过程升级包的数据基本上是以明文传输,数据校验方式也是安全性较低的散列算法。安全升级在传统升级基础上,一方面使用添加签名的固件和在固件验证过程中额外执行签名验证来增强固件完整性验证,保证数据来源可靠,数据完整没有被篡改;另一方面还增加了对通过服务器加密固件的解密功能,传输数据过程通过密文传输,有效的降低 OTA 无线更新时数据暴露的风险。


6. 安全存储

一次性可编程存储器 OTP(On Chip One Time Programmable ROM, On-Chip OTP ROM),也称为eFuse,是芯片中特殊存储模块,字段中的任何 eFuse 位都只能从 0 编程为 1(融合),只能被烧写一次,但是读取操作没有限制。安全存储还可以通过将 Flash 某些区域设置只读或者只写来实现,防止非法访问和篡改。Flash 保护区域的数量和大小会根据 Flash 的类型和该 Flash 块的大小而有所不同。


本文整理自中国汽车基础软件信息安全研究报告

最新文章