基于互联网设备的车辆安全空中下载通信协议方案

周奇才 王奕童 赵炯 熊肖磊

（1.同济大学，上海 201804；2.同济大学浙江学院，嘉兴 314051）

主题词：空中下载 安全通信 密钥管理

1 前言

空中下载（Over-The-Air，OTA）是一种从远程服务器下载更新包的技术，利用此技术对互联网汽车进行升级已成为趋势，但如果车辆在OTA过程中遭受网络攻击，则车内电子控制单元（Electronic Control Unit，ECU）可能被破坏或控制，从而对用户形成严重的安全威胁。

针对车辆安全下载升级的过程已有许多研究。Mahmud等[1]提出的一次性密钥组通信方案实现过程繁琐，而且无法防止针对特定目标的持续性攻击。Nilsson等[2-4]提出了基于Hash链认证的安全硬件空中更新（Secure Firmware updates Over The Air，SFOTA）方案，并深入操作系统层面规划权限管理和日志处理，但该方案缺少对目标车辆的认证过程和ECU密钥管理方案。Steger等[5-6]提出了基于不同场景的组通信方案升级流程以及使用区块链技术的软件认证流程，但增加了额外的基础设施和计算开销。Kuppusamy等[7]提出了车辆安全软件升级框架Uptane，可以有效抵抗大部分类型的攻击，并减少密钥泄露产生的危害，但仍无法阻止窃听攻击和局部升级攻击。

EVITA（E-safety Vehicle Intrusion Protected Applications）项目的移动终端空中下载（Firmware Over-The-Air，FOTA）方案[8]可以基于可信诊断工具确保OTA过程安全。Mansor等分析了其不足[9]，并描述了一种利用移动设备下载固件数据的方案[10]，但其前提条件是存在一个与车配对的可信移动设备，使方案具有很大局限性，且如果移动设备被恶意获取、使用或破解，不仅会泄露使用预共享密钥加密的固件包和ECU的解锁密钥，恶意用户还可以利用移动设备控制密钥的内容，实现选择明文攻击。

本文提出一个基于互联网设备的OTA更新包的安全通信协议方案，可以在不安全的网络及有风险的设备上实现安全通信，并参考Uptane软件模式提出一个简单密钥泄露保护方案。

2 系统模型

2.1 系统模型与前提条件

本文系统模型与EVITA项目的FOTA模型基本一致。车内的每一个通信节点具有不同等级的硬件安全模块（Hardware Security Modules，HSM）作为实现密码学算法和机密存储的安全模块，HSM的定义和等级划分依照EVITA项目定义。车辆中央通信单元（Central Communication Unit，CCU）是车内会话中心，拥有全功能的HSM。CCU也作为一个密钥管理（Key Master，KM）节点保存车内ECU的公钥或预备密钥。车内ECU根据功能需求拥有不同等级的HSM。车辆CCU与OEM服务器通过互联网设备进行连接，该设备可以是个人拥有的智能设备，也可以是主机厂或者供应商提供的网络终端，可以实现安全诊断、更新等传统诊断工具（Diagnostic Tool，DT）所具有的功能。因为智能手机具有较高的普及率、良好的运算性能以及便利性，所以本文以典型的移动设备（Mobile Device，MD）手机作为互联网设备进行相关分析，系统模型如图1所示。

图1 系统模型

系统的前提条件要求为：

a.OEM服务器：提供实现功能需求的APP；具有通过给定车辆信息（如VIN）获得相关CCU公钥、ECU密钥的能力；提供升级数据包。

b.MD（手机）：获取OEM提供的官方APP；连接目标CCU；具有一定的性能以满足运算需求。

c.CCU：存储正确的OEM公钥；具有EVITA项目定义的功能要求（包括全HSM等）；搜集并提供当前车内升级所需要的相关信息；作为车内KM拥有ECU的相关密钥。

d.ECU：具有EVITA项目定义的相关功能要求（包括HSM、升级功能等）；提供升级需要的相关信息（如ID、型号、版本号、升级状态等）。

e.手机APP：正确存储OEM公钥并可灵活替换；实现本文的通信协议和通用的密码算法；实现针对汽车的其他通信功能以及诊断功能（可选）。

2.2 威胁模型

基于Delov-Yao的网络攻击模型，定义攻击者的能力有：对OEM服务器到MD、MD到CCU、CCU到ECU之间的网络通信过程进行窃听、拦截、修改、参与会话及伪装成其他角色；入侵MD，得到通信协议的全部流程及OEM公钥，甚至获得MD私钥以及全部存储信息。

2.3 安全目标

定义目标为：在所有传输流程正确认证完成后，确保ECU接受到的数据具有机密性、完整性、可用性、可认证性和新鲜性。

3 协议框架描述

协议主要流程分为4个部分，依次为：安全通信握手，用来生成本次通信的所有临时密钥，以保证整体过程的通信安全；车辆信息反馈，通过CCU完成车辆信息传输，用以生成合适的OTA更新数据；数据下载请求，MD从OEM服务器获得更新数据；升级数据包交付，MD将数据交付给CCU并转交给ECU。部分数据符号的定义如表1所示。

表1 符号定义与解释

在2.1节的系统条件下，服务器将采用某种方式通知（或CCU定期查询得知）ECU需要升级，并利用此协议进行数据包交付。

3.1 安全通信握手过程

安全通信握手过程可以在OEM服务器、CCU和ECU之间秘密分享Km1，在OEM、CCU和MD之间秘密分享Km2。其中Km1通过某种算法（如带固定填充的Hash算法等）生成会话密钥Ks1和MAC密钥Kc1，保证OEM对CCU和ECU的安全传输。Km2同样生成密钥Ks2和Kc2，用于OEM、MD、CCU的通信，起到保护会话机密性的作用。同时Km2还可以对APP的其他车辆诊断操作和通信信息进行保护。

此过程具体流程如图2所示。考虑到从MD发起请求起到OEM与CCU数据交互结束至少需要5次通信，故在此基础上增加2次密钥确认过程已经接近最简。

图2 安全通信握手流程

此流程可以保证发起请求和生成密钥的实体都是可信的。基于OEM与CCU之间具有互相认证的能力，OEM生成带有随机种子的签名包以验证本次会话确实有可信的CCU参与。而CCU生成的所有主密钥加密签名数据包，保证了密钥来源的合法且机密。对应图2，每次通信的数据构成如下：

OEM服务器接到OTA请求后，返回包含附带签名的数据包package1。package1含有时间戳和随机种子，用来特定此次会话。MD将该包转交给CCU，CCU则可以验证此次会话是否有OEM服务器参与，随后生成2个主密钥Km1和Km2，配合OEM服务器随机种子和车辆VIN一起封装在用OEM公钥加密的数据包package2内。CCU同时将Km2用MD公钥加密后与package2拼合在一起发送给MD。MD只能解析出Km2，并计算出相应会话密钥Ks2和MAC密钥Kc2，之后MD将package2转送给OEM服务器，OEM服务器验证完成后获得2个主密钥，之后验证密钥是否分享成功。

这一系列步骤完成后，后续通信数据均使用此过程生成的Kc2进行MAC加密，与原文拼接后使用Ks2对称加密。当传输敏感数据包时（如ECU解锁密钥），需利用Ks1和Kc1以同样的方式对包先进行加密，再嵌入整体消息并再次利用Kc2、Ks2进行加密（加密结构参见3.3节）。

3.2 车辆信息反馈过程

车辆信息反馈过程用来通知OEM服务器当前车辆的软件状态。车辆的信息数据可以在平时车辆使用过程中由CCU备份，具体流程如图3所示。

图3 车辆信息反馈流程

此过程完成后，OEM服务器可以根据相应的信息生成更新数据包。

3.3 数据下载请求过程

数据下载请求过程为MD从OEM服务器获得ECU解锁密钥和升级文件的过程，如图4所示。当有多个ECU需要升级时，则可以采用打包传输的方式，通过CCU分别传输到对应的ECU，以对抗局部升级攻击。

图4 下载请求流程

图4中，每次通信的数据结构与含义如下：

此过程完成后，MD会得到包含时间戳以及经过2次加密的ECU解锁密钥和升级数据包，由于MD无法获得主密钥Km1，所以MD无法得到具体数据包的内容，从而保证了在风险设备上的通信安全。

3.4 升级数据包交付过程

升级数据包的过程是CCU将数据包交付给ECU，同时保存ECU的备份数据，如图5所示。

图5 升级数据包交付流程

3.5 错误处理方式

在安全通信握手过程中的任何错误都会导致通信重置。通信重置是指由OEM服务器或CCU发送的一个数据包在发送或接收此信息后会复位成通信前的会话状态，此数据包也会附加上发信者的签名以防止干扰攻击。

在其他过程中的错误通信可以尝试恢复，即发送请求重复的信息，此信息也需要使用Ks1、Kc1进行加密。但当累计到一定次数的错误量或通信超时后，也将进行通信重置。

3.6 密钥泄露保护方案

密钥泄露对于只使用单个公、私钥的系统有致命打击。如果OEM服务器只使用单个私钥，一旦泄露，则所有安全手段都将无效化。Uptane框架提出了一个在软件层面上对抗密钥泄露的方案，本文参考其思路，提出一个用于保护网络通信的简明方案，可降低通信时密钥泄露的风险以及泄露后的威胁。方案中使用的概念有：

Root密钥：OEM生成的一个公、私钥对，用于签名认证其他密钥（期限会话密钥等），每个Root密钥的私钥都被机密地离线存放，不同Root密钥的私钥需要物理性地互相隔离。

Root密钥组：OEM所有Root密钥的集合，至少包含3对Root密钥，组内每个Root密钥的公钥至少被组内过半数的其他Root密钥的私钥签名。

Root公钥组：Root密钥组内的所有公钥的集合，在每台车辆出厂时的CCU中预存。

期限会话密钥对：由OEM定期生成的一个公、私钥对，此密钥有生效期限，在期限内起到此协议中的OEM公、私钥的作用。

考虑密钥泄露情况，包括期限会话密钥泄露（即OEM私钥泄露）和Root密钥泄露。期限会话密钥过期后或发生密钥泄露时，可以采用如图6所示的过程进行替换：OEM生成新期限会话密钥作为OEM会话的公、私钥，Root密钥组中过半数的密钥对此新密钥中的公钥进行签名；OEM发送新公钥给CCU；经过Root公钥组认证后，CCU替换OEM公钥。

图6 期限会话密钥处理过程

这种方式不仅可以减少密钥泄露的长期风险，同时可以灵活处理公钥撤销的过程。但在期限会话密钥泄露后与密钥替换前的时间段内，无法保证通信的机密性，故推荐在软件数据认证基础上增加对策。

如果Root组的单个密钥泄露，短期内并不会产生风险，这是因为单个Root密钥并不能生成合法的期限会话密钥或Root密钥，也不能变更其他Root密钥的有效性。因为存在物理隔离，短期内大量密钥泄露是几乎不可能的，所以及时发现即可安全变更CCU中保存的Root公钥。处理过程如图7所示：OEM移除泄露的Root密钥，生成废弃信息；OEM生成新的Root密钥，与废弃信息合并成替换数据包，并利用Root组中的过半数密钥进行签名，同时将包发送至CCU；CCU获取替换数据包后，利用预存的Root公钥组认证，更新Root公钥。

图7 Root组单个密钥泄露处理过程

4 协议分析与理论证明

本节主要对协议的安全性进行软件分析和理论分析。如果能够保证安全通信握手过程中的主密钥Km1得到了安全分享，那么在OEM密钥安全的情况下，由于后续的ECU接收到的数据都由经加密、MAC、增加时间戳的方式传输，所以可以保证ECU接收到的数据的机密性、完整性、可用性和新鲜性。故可以认为系统安全性等价于主密钥Km1是否达成安全目标，所以本文针对主密钥Km1的信息安全性进行分析。

4.1 Scyther建模分析

Scyther是一个形式化分析工具，可以对通信协议中的安全问题进行分析并针对漏洞给出攻击图。建模针对第一阶段安全通信握手流程，由于Scyther对时间戳的支持度有限，模型利用随机数ts作为令牌，进行一定程度的替代。为减少运算量，对签名过程使用整体私钥加密的方式进行替代，软件略微减少最大运行次数以减少运算时间，通信模型选择默认的D-Y模型。

运行结果是Km1、Km2的机密性在没有密钥泄露的情况下成立，如图8所示。而当放弃MD的公钥系统，即MD为不可信任或受到安全威胁的状态时，Km1依旧是机密的，而Km2却存在风险，如图9所示，这与预期保持一致。

图8 密钥安全时Scyther验证结果

图9 MD设备有风险时Scyther验证结果

4.2 密钥安全传输理论分析

基于安全目标定义，对主密钥Km1的安全要求逐个分析：

a.新鲜性：所有消息都附带时间戳，在消息来源可靠的条件下，可以保证消息的新鲜性。同时，OEM服务器和需要升级的CCU代理可以互相认证，并且OEM生成了随机种子作为会话的标识，故攻击者无法依靠重放截获的密钥分享信息中控制主密钥，从而保证了主密钥的新鲜性。

b.机密性：所有主密钥均由CCU生成，且被CCU签名，所以相关内容都不可能被第三方控制（除非重放攻击，但新鲜性的证明已经排除这一点）。因为包含主密钥Km1的所有数据包都被OEM或CCU的公钥加密，所以无法被MD或其他攻击者获取，可以保证机密性。

c.完整性、可认证性、可用性：安全通信握手的前5次通信都附加了数字签名，所以在验证成功后可以保证主密钥Km1具有这些性质。

这样，因为主密钥Km1的信息安全得以保障，所以可以认为安全目标达成。

5 结束语

本文分析了车辆OTA升级技术的研究与进展，提出一种利用互联网设备进行安全OTA更新包通信的协议框架及一个简化的密钥泄露保护方案。通过理论分析和形式化工具Scyther进行建模，证明了其有效性。但本研究细节仍不完善，在加密算法的选择上还需进一步测试，对于特殊通信状况和不同实际硬件的特殊性还缺少考虑，后续将会对协议进行轻量化及完善化研究。