CN109474909A - 用于ctcs-3级列控系统车地安全通信协议的密钥管理方法 - Google Patents

Abstract

本发明提供了一种用于CTCS‑3级列控系统车地安全通信协议的密钥管理方法，该方法包括：由CTCS‑3级列控系统中的安全相关设备分担其车地安全通信协议所要求的密钥管理功能，离线生成传输密钥和验证密钥的密钥本，并将所述密钥本存储于所述安全相关设备中，应用公钥密码体制根据所述传输密钥的密钥本为CTCS‑3级列控系统中的安全相关设备分配传输密钥，在传输密钥分配完成后，利用传输密钥，继续按照CTCS‑3级列控系统车地安全通信协议规定的方法建立安全通道，利用安全通道为安全相关设备分发验证密钥。本发明的方法通过安全相关设备执行密钥管理功能，改变了密钥管理过程中物理分发密钥的方式，降低了人工干预密钥管理的所带来的风险，提高了密钥的安全性。

Description

用于CTCS-3级列控系统车地安全通信协议的密钥管理方法

技术领域

本发明涉及车地安全通信技术领域，尤其涉及一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法。

背景技术

在CTCS(China Train Control System，中国列车控制系统)-3级列控系统中，OBU(On board Unit，车载列控设备)与地面RBC(Raid Block Cente，无线闭塞中心)通过如图1所示的GSM-R系统实现基于开放无线网络的双向数据信息交互。为保证车地列控关键信息的安全，以ETCSEuroradio功能接口规范及ETCS subset-037协议为基础，制定了CTCS-3级车地通信协议，该协议基于3DES对称加密算法保证系统车地间关键数据的安全传输。

CTCS-3级车地通信协议根据EN50159安全通信标准构建，现有技术中提供的CTCS-3级列控系统车载设备与RBC安全通信参考模型图如图2所示，其中CTCS-3级列控系统车地安全通信由该协议中安全功能模块(SFM)提供相关安全保护，该模块提供安全服务，即安全连接建立以及连接生存期内应用数据安全传输。其中，建立安全连接的前提是在设备进行通话前启动对等实体认证程序，用于对通信双方设备进行身份验证，该安全流程的实现依赖于设备间共享的认证密钥，并且在认证过程中，通信双方设备会基于认证密钥自动生成共享的会话密钥，以对设备间安全相关数据提供保护。可见，对等实体认证所需的认证密钥和有效的密钥管理是确保CTCS-3级车地通信安全的关键。

图3为现有技术中的Euroradio安全协议密钥管理图，Euroradio安全协议中，设置KMC(Key Management Centre，密钥管理中心)执行密钥管理功能，协议定义了三个级别的密钥，如下表1：

表1

根据表1，传输密钥包括两种密钥：K-TRANS1用于保护KMC与信号安全设备之间所交互消息的真实性和完整性。K-TRANS2用于加密保护KMC与信号安全设备之间交换的验证密钥。

K-KMC密钥也由两个密钥组成：K-KMC1用于保护KMC与KMC之间所交互的消息的真实性和完整性。K-KMC2用于通过加密来保护KMC之间所交换的验证密钥。

上述三个级别的密钥，传输密钥属于主密钥，验证密钥属于密钥加密密钥。主密钥为上层密钥，采用物理方式保护其安全性；验证密钥为中间层密钥，受主密钥的保护；会话密钥为底层密钥，由中间层密钥提供保护，其特点是上层密钥决定下层密钥的安全，但下层密钥的破译不会影响到上层密钥的安全，而KSMAC是由安全设备间自动生成的，所以传输密钥与验证密钥的管理是通信安全的关键。

具体的密钥管理功能如下：

(一)在同一密钥管理区域(简称KM域)内的密钥管理功能：

(1)传输密钥与验证密钥的生成和验证：由KMC负责在安全的环境下由授权人员和程序计算生成密钥，使密钥具有随机性与不可预测性；并由KMC对生成的密钥进行检查验证，以确保密钥具有相同强度。

(2)分配传输密钥：由KMC确定该密钥用于本域内的哪一对安全设备，通过授权人员(如KMC管理员)安装到设备中，未授权人员没有更改密钥的权限，接收方设备会确认接收并采取必要的措施使得传输密钥生效。

(3)分配验证密钥：KMC确定该密钥用于本域内的哪一对安全设备，再由KMC通过传输密钥加密后保密发送并以安全的方式安装给相应安全实体，安全实体设备会确认接收并采取必要的措施使得验证密钥生效,且该密钥应当可靠、安全地存放。

(4)更新验证密钥：由KMC管理员根据预先规定的更新计划，或在检测到密钥失效、不具有保密性时更新验证密钥。

(5)删除验证密钥：由KMC管理员启动密钥删除程序，以安全的方式删除所有相关信息(包括安全实体设备中安装的密钥)，除了KMC管理范围内存档的密钥。

(6)存档密钥和KM实施

KMC以保密且可靠的方式处理与密钥相关的事务，包括分配密钥给安全实体以及检测密钥所处状态(正在使用、删除或者失效)等。

(二)不同密钥管理区域之间的密钥管理功能：

定义KM域：KMC管理员根据铁路运行情况，确定KM域中所包含的车载及轨旁实体设备；

安装KMC:KMC管理员应确保所有设计和配置任务的完整性，使配置了KMC的设备能够以预期安全性执行以下操作——生成密钥、向其他KMC发送密钥、接收来自其他KMC的密钥、撤销(删除)密钥、存档密钥、验证密钥、生成活动日志。

分配K-KMC密钥：KMC管理员应根据需求为每个需要离线密钥交换的KMC分配一个K-KMC。具体有三种分配方式：a)由一名KMC管理员生成和验证密钥，并将其分发给其他KMC；b)每个KMC管理员生成密钥的一部分并分发给其他KMC，然后众KMC都验证密钥是否为弱密钥或半弱密钥，如果验证通过，则使用该密钥；c)两个KMC管理员都从一个独立的负责密钥生成和验证的密钥生成方接收密钥。具体分配方式由密钥管理中心管理员共同决定。

生成验证密钥：KMC按照系统互操作应用的安全需求生成验证密钥。

验证密钥交互：KMC(递交方与接收方)之间交换验证密钥(由K-KMC2加密)，递交方管理员应确定该密钥所属车载设备以及将与该车载设备建立连接的RBC实体，并保证RBC设备列表能够接受该车载设备，接收方管理员应确认接收并执行后续操作。

更新验证密钥：要求进行交互的KMC事先协调一致，只有发送了验证密钥交互请求的KMC才能更新密钥相关信息，接收方KMC的管理员向请求发起方确认收到请求，并执行密钥更新。

删除验证密钥:KMC管理员可以请求其他KMC管理员删除密钥，且KMC管理员应能够保证删除所有相关的密钥副本，在完成删除后向请求发起方回复删除完成。验证密钥删除操作可由其生成方KMC使用删除请求来触发，也可由其接收方KMC使用删除通知来触发。

删除K-KMC：KMC管理员可以要求其他KMC管理员删除K-KMC，并保证所有相关的密钥副本已经被删除。

存档密钥及KM交互：KMC管理员应该在生成的密钥时安全地储存所有信息。

对于CTCS-3级列控系统，在开放式传输系统中，传输密钥和验证密钥的生成、分配、更新存储等均由铁路专业部门负责。在同一铁路管理区域内只设置一个密钥管理中心机构，为其配备专门负责密钥管理的计算机设备，由具有相应权限的密钥管理人员协同负责本域的密钥管理工作。并且在同一密钥管理区域内，规定统一使用相同的传输密钥，不同的通信接口间也可统一使用相同的验证密钥值。其中传输密钥文件的发布和传递在封闭环境中由专人负责实施，验证密钥的更新与取值均由KMC负责，且验证密钥由传输密钥加密后进行发布，或者将传输密钥与加密后的验证密钥一起下载到终端设备中(RBC或车载设备)，然后由终端设备通过传输密钥计算得出验证密钥。

在现有技术中，传输密钥的管理方案的缺点如下：

3DES加密算法安全性较高，但前提是通信双方能够安全可靠的分配共享密钥。下表2为几种对称密钥共享的通用方式以及对应特点，(记通信双方为A和B):

表2

Euroradio安全协议下的三个级别的密钥中，传输密钥通过方式二(即由密钥管理中心选择密钥通过物理方式(如U盾))、受人为干预实现共享，验证密钥通过方式四，即由中心决定安全实体A和B要共享的密钥，再通过中心与A、B间的传输密钥加密后分别发送给A、B，会话密钥则由信号安全设备间共享的验证密钥通过密钥生成算法自行生成以实现共享。

由上述可知，传输密钥需要通过离线的安全物理通道进行分发，在通信双方之间长期共享，具有永久性特点，且其分发过程通常离不开操作人员的参与，因此分发共享传输密钥可能出现以下情况：操作人员未达到要求或者操作失误、物理通道不够安全或者密钥由于长期不变而被破解泄露。以上情况将导致传输密钥失去安全保障，导致之后与该密钥相关的所有过程都会失去安全保障。此外，主密钥和二级密钥的分发、更新以及存储等功能都要依赖密钥管理中心来完成，如果密钥管理中心崩溃、受到攻击威胁，或者中心与安全设备之间的通道被破坏，甚至中心被恶意伪装的中心替代，那么整个安全通信将不再安全。

目前在CTCS-3级列控系统中，传输密钥的管理除了需要专门的密钥管理中心机构以外，其生成、分配以及安装还要求安全封闭的环境以及被严格授权的人员，而GSM-R网络是开放式网络环境，所以传输密钥管理需要额外为其设置安全封闭的环境并分配管理人员；并且在同一密钥管理区域内，通常统一使用相同的传输密钥，不同的通信接口间也可统一使用相同的验证密钥值，且验证密钥由传输密钥加密保护，又由于传输密钥长期不变，传输密钥很可能会被破解，而只要有一个通信接口间的传输密钥被破解，则整个区域内的通信都会失去安全性。

发明内容

本发明的实施例提供了一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法，以克服以上问题。

为了实现上述目的，本发明采取了如下技术方案。

一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法，取消CTCS-3级列控系统车地安全通信协议所要求设置的密钥管理中心，由CTCS-3级列控系统中的安全相关设备分担车地安全通信协议所要求的密钥管理功能，所述方法包括：

离线生成传输密钥和验证密钥的密钥本，并将所述密钥本存储于所述CTCS-3级列控系统中的安全相关设备中；

应用公钥密码体制根据所述传输密钥的密钥本为CTCS-3级列控系统中的安全相关设备分配传输密钥；

在传输密钥分配完成后，利用所述传输密钥基于CTCS-3级列控系统车地安全通信协议建立安全通道，利用所述安全通道为所述安全相关设备分发验证密钥。

进一步地，所述的安全相关设备包括：地面无线闭塞中心RBC和车载设备OBU。

进一步地，所述的通过CTCS-3级列控系统中的安全相关设备生成传输密钥和验证密钥的密钥本，包括：

离线将一定数量的密钥随机进行排序，所述安全相关设备获取每个密钥对应的序号，计算每个密钥与其对应序号的hash值，该hash值记为H(密钥∣序号，对所述的传输密钥与验证密钥各生成一套包括序号、密钥和hash值的密钥本，将所述传输密钥与验证密钥的密钥本存储在CTCS-3级列控系统中所有需要安全通信的安全相关设备中。

进一步地，所述的应用公钥密码体制为CTCS-3级列控系统中的安全相关设备分配传输密钥，包括：

针对OBU首次或重新上电后，OBU与控车RBC1间部署传输密钥的情况一，采用非对称加密方式使所述RBC1与OBU获得所述传输密钥；

针对越区切换时，控车RBC从RBC1切换到RBC2，OBU与RBC2间部署传输密钥的情况二：

若同一OBU与各个RBC使用同一套传输密钥时，采用对称加密与非对称加密相结合的方式使所述RBC2与OBU获得所述的传输密钥，

若每对OBU与RBC都使用不同的传输密钥时，当车载电台只有一部电台正常时，采用对称加密与非对称加密相结合的方式使所述RBC2与OBU获得所述的传输密钥，当车载两部电台都正常时，则按所述情况一方式操作。

进一步地，所述的在传输密钥分配完成后，利用所述传输密钥建立安全通道，利用所述安全通道为所述安全相关设备分发验证密钥，包括：

Step1：在RBC和OBU已经安装了传输密钥KTRANS后，OBU向RBC发送验证密钥申请；

Step2：RBC收到所述验证密钥申请请求后，生成随机数Rc和Rd，在RBC保存的验证密钥本中查找Rc对应的验证密钥KMAC以及hash值，将该hash值记为Ha，计算s＝Rc+Rd,由KTRANS加密Ha以及s，并发给OBU；

Step3：OBU收到RBC发送过来的加密后的Ha以及s后，利用KTRANS解密得到Ha’和s’，在OBU保存的验证密钥本中查找Ha’对应的序号Rc’与验证密钥KMAC，计算Rd’＝s-Rc’，向RBC发送包括Rd’的反馈信息；

Step4：RBC收到所述反馈信息后，对比Rd与Rd’，若相等，则表示OBU与RBC之间验证密钥共享成功，RBC记录密钥序号Rc、Ha以及车载信息；若不相等，则重新发送Step2中信息，继续执行Step3、Step4。

进一步地，所述的方法还包括：

在车载设备重新上电时，重新分配传输密钥和验证密钥；

在验证密钥处理了一定数目的会话密钥、验证密钥失效或者不具有保密性后，对验证密钥进行更新，RBC向OBU发送密钥更新命令，执行验证密钥分配流程。

进一步地，所述的方法还包括：

在更新密钥后，RBC删除自己安装的旧密钥信息，并命令OBU删除对应的旧密钥信息，OBU向RBC确认密钥删除已经完成。

进一步地，所述的方法还包括：

RBC记录其管辖范围内所有与其建立安全连接的OBU对应的密钥信息，RBC为OBU分发传输密钥和验证密钥后，记录车载信息与对应的密钥序号，hash值以及密钥类型等信息；对于失效的密钥，将对应的密钥序号、hash值以及密钥类型记录到失效密钥本中。

由上述本发明的实施例提供的技术方案可以看出，本发明实施例的用于CTCS-3级列控系统车地安全通信协议的密钥管理方法采用取消密钥管理中心KMC方法，将CTCS-3级车地安全通信协议中密钥管理功能分散给CTCS-3级列控系统中各相关的每个安全相关设备(RBC、列控车载系统)，由这些与列控安全通信相关的各个设备共同合作，使系统不需要再设置专门的KMC机构；调整密钥管理功能特别是传输密钥的分配方式，解决该密钥分发以及安装受人为干预的弊端，并且使传输密钥能够经常得到更换，从而降低密钥因长期不变而面临遭到破解的安全风险。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中的GSM-R系统结构图；

图2是现有技术中提供的CTCS-3级列控系统车载设备与RBC安全通信参考模型图；

图3是现有技术中的Euroradio安全协议密钥管理图；

图4是本发明实施例提供的一种用于CTCS-3级列控系统车地安全通信协议的密钥管理示意图；

图5是本发明实施例提供的一种车载设备重新上电时与RBC间传输密钥的共享流程图；

图6是本发明实施例提供的一种车载设备与RBC之间验证密钥分配流程图。

具体实施方式

下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本发明实施例的一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法，旨在通过改变CTCS-3级列控系统车地通信中心式的密钥管理策略，并且改变了密钥管理过程中物理分发密钥的方式，降低人工干预密钥管理所带来的风险，并且对传输密钥的方案进行更新，以提高密钥的安全性。

为便于对本发明实施例的理解，下面将结合附图以具体实施例为例做进一步的解释说明，且实施例并不构成对本发明实施例的限定。

本发明实施例提供了一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法，该方法的实现原理示意图如图4所示，包括：

取消CTCS-3级列控系统车地安全通信协议所要求设置的密钥管理中心，由CTCS-3级列控系统中的安全相关设备分担其车地安全通信协议所要求的密钥管理功能，参照图4，包括：离线生成密钥本和密钥本的存储、传输密钥的分配、验证密钥的分配、密钥更新、密钥删除和密钥存档。上述安全相关设备包括：RBC和OBU。

离线生成密钥本和密钥本的存储的处理过程包括：

将一定数量的密钥随机进行排序，计算每个密钥对应序号的hash值，对所述的传输密钥与验证密钥各生成一套包括序号、密钥和hash值的密钥本，并将所述密钥本存储于所述安全相关设备中，需要密钥时根据随机序号以及hash值查表即可。

优选地，生成密钥本，包括为一定数量的合法192位密钥随机进行排序。

传输密钥的分配，包括：应用公钥密码体制为所述安全设备分配传输密钥，传输密钥分配完成后，通过所述传输密钥建立安全通道分发验证密钥。

情况一：在车载首次或重新上电后,车载设备OBU与第一地面无线闭塞中心RBC1间部署传输密钥：

图5是车载设备重新上电时与RBC间传输密钥的共享流程图，参照图5，分为两个阶段：

阶段1：通过一次Diffie-Hellman过程生成初步认证序号及静态双向认证因子(取素数q及其基数g)：

S11：OBU生成两个随机数a，Na，计算X＝g^amodq，并将X与Na发送给RBC1；

S12：RBC1收到OBU发送的消息后，生成两个随机数b，Nb,计算Y＝g^bmodq,并将Y与Nb以及Na发送给OBU；

S13：OBU收到RBC1发送的消息后，判断收到的Na与自己原有的Na是否相等，如果相等，则计算k_ab＝Y^amodq，R1＝f(k_ab)并发送Nb给RBC1。否则，协议终止；

S14：RBC1收到S13中OBU发来的Nb，判断收到的Nb与自己原有的Nb是否相等，如果相等，则计算k_ab＝X^bmodq,R1＝f(k_ab)。否则，协议终止。

其中，函数f以k_ab作为输入得到序号R1，设备可从自己保存的认证密钥本中查找R1对应的hash值，将该hash值作为通信双方之间的静态双向认证因子tf。

阶段2：生成共享的秘密序号，同时进行双向认证与验证。其中，ID_RBC1与ID_OBU为RBC1与OBU的CTCS ID,tf为所述静态双向认证因子，函数F为一个单向函数。

S21：OBU计算F(k_ab,tf)＝γ，F(ID_OBU,k_ab,γ)＝RA，再计算X1＝g^γ*RAmod q，同时计算生成γ^-1mod(n-1)，且γ与γ^-1mod(n-1)互质，并发送X1，X2给RBC1；

S22：RBC1计算F(k_ab,tf)＝γ，F(ID_RBC1,k_ab,γ)＝RB，再计算Y1＝g^γ*RBmod q，同时计算生成γ^-1mod(n-1)，且γ与γ^-1mod(n-1)互质，并发送Y1，Y2给OBU；

S23：OBU计算和并发送K1给RBC1；

S24：RBC1计算和 并发送K2给OBU；

S25：如果OBU计算key1^RAmod q＝K2成立，则OBU确认对方通信的是RBC1，即OBU认证RBC1成功，否则失败；

S26：如果RBC计算key2^RBmod q＝K1成立，则RBC1确认对方通信的是OBU，即RBC1认证OBU成功，否则失败。

S27：当S25和S26同时成立时，key1＝key2＝g^RA*RBmod q为双方共享的秘密数。

S28：OBU计算R2＝f(key1),从密钥本得序号R2对应传输密钥和hash值记为H1，发送H1至RBC1；RBC1计算R2＝f(key2)，从密钥本得序号R2对应传输密钥和hash值记为H2，判断H1＝H2成立，则传输密钥共享成功，否则重新执行S28。

情况二：越区切换，控车RBC从RBC1切换为第二地面无线闭塞中心RBC2时，OBU与RBC2间分配传输密钥：

RBC1与RBC2提前通过与上述两个阶段一样的方式得到共享的序号R2’。

若设定同一车载与各个RBC使用同一套传输密钥：

当控车RBC需要由RBC1切换为RBC2时，RBC1会向RBC2移交列车预告信息和进路请求信息，与此同时，RBC1用R2’加密序号R2所对应密钥本中的hash值发送给RBC2；

RBC2收到该信息后，用R2’解密，并从其密钥本中查找所得hash值对应序号，该序号即为R2，由此OBU与RBC2间即可确定传输密钥。

若设定每对OBU与RBC都使用不同的传输密钥：

若车载电台只有一部电台正常，当需要由RBC1切换为RBC2时，RBC1向RBC2发送密钥请求，RBC2收到消息后从密钥本随机选择密钥，并将对应的hash由R2’加密后发送给RBC1，再由RBC1处理后发给OBU；而若车载两部电台都正常，则按情况一操作。

验证密钥的分配。图6是车载设备与RBC之间验证密钥分配流程图，参照图5，验证密钥仍然由传输密钥负责为其提供安全防护，但在分配该密钥时，不直接将密钥加密传输，而是传输hash值，这样更好地保证了密钥的保密性。具体分为以下步骤：

S31：在RBC与车载设备已经安装了传输密钥情况下，车载设备向RBC发送验证密钥申请；

S32：RBC收到请求后生成随机数Rc和Rd，在验证密钥本中查找Rc对应的验证密钥以及hash值记为Ha，计算s＝Rc+Rd,由传输密钥加密Ha以及s，并发给OBU；

S33：OBU收到信息后利用传输密钥解密得到Ha’和s’，通过查密钥本得到对应序号Rc’与验证密钥，计算Rd’＝s-Rc’，然后向RBC发送反馈信息(包括Rd’)；

S34：RBC收到反馈信息后，对比Rd与Rd’，如果相等，则表示OBU与RBC之间验证密钥共享成功，RBC记录密钥序号Rc、Ha以及车载信息如CTCS-ID；如果不相等，则重新发送S32中的信息，继续执行S33和S34。

密钥更新。

传输密钥的更新：车载重新上电时，会重新分配密钥；

验证密钥的更新：在验证密钥处理了规定数目的会话密钥、验证密钥失效或者不具有保密性时更新。RBC向车载设备发送密钥更新命令，然后执行验证密钥分配流程。

密钥信息删除。

RBC负责删除所有密钥相关信息。在更新密钥后，RBC删除安装的旧密钥信息，并命令车载设备删除对应的旧密钥信息，车载设备会向RBC确认密钥删除已经完成。

存档密钥信息。

RBC记录其管辖范围内所有与其建立安全连接的车载设备对应的密钥信息。RBC为车载设备分发传输密钥和验证密钥后，记录车载信息与对应的密钥序号，hash值以及密钥类型等信息；对于失效的密钥，将对应的密钥序号，hash值以及密钥类型记录到失效密钥本中。

用本发明实施例的方法用于CTCS-3级列控系统车地安全通信协议的密钥管理的具体过程与前述方法实施例类似，此处不再赘述。

综上所述，本发明实施例通过将CTCS-3级车地安全通信协议中密钥管理功能分散给CTCS-3级列控系统中各相关的每个安全相关设备，由这些与列控安全通信相关的各个设备共同合作，使系统不需要再设置专门的密钥管理中心机构；调整传输密钥的分配方式，引入非对称加密算法，解决密钥分发以及安装受人为干预的弊端，并且使传输密钥能够经常得到更换，从而降低密钥因长期不变而面临遭到破解的安全风险。

本发明实施例不改变既有CTCS-3级列控系统车地安全通信协议中对安全数据的加密防护算法，仍然利用3DES算法保护数据交互过程，只对密钥管理功能进行调整。由车载和地面安全设备协调负责对传输密钥和认证密钥的管理功能(分配、更新、删除存档等)；对一定数量的合法192位密钥随机进行排序，并计算每个密钥与其对应序号的hash值，由此生成密钥本，传输密钥与验证密钥生成不同的密钥本，将两套密钥本事先存储在所有需要安全通信的设备(RBC、OBU)中；需要密钥时由通信双方协商得到随机数，再根据随机序号以及hash值查表即可。

本发明实施例改变了CTCS-3级列控系统车地通信中心式的密钥管理策略，并且改变了密钥管理过程中物理分发密钥的方式，降低了人工干预密钥管理的所带来的风险，并且此方案可以对传输密钥进行更新，密钥分配过程中防御各类攻击，如中间人攻击，重演攻击，猜测攻击等，提高密钥的安全性。

本发明实施例通过非对称加密机制实现传输密钥的分配，再由传输密钥保护认证密钥的分配，但密钥分发过程只交互密钥本中随机序号所对应的hash值，不再传输密钥本身。通信双方通过公钥机制协商得到传输密钥对应的序号，根据序号从密钥本中得到需要共享的传输密钥，并利用密钥本中的hash值验证设备的合法性，该方式实现传输密钥“一次一密”的分发共享，使传输密钥得到更新；对于验证密钥，RBC通过随机序号来确定其与车载设备间使用哪一个密钥，再由传输密钥加密此序号对应的hash值并发送给车载，车载根据hash值查密钥本即得其与RBC之间所要共享的验证密钥。

本领域普通技术人员可以理解：附图只是一个实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (8)

1.一种用于CTCS-3级列控系统车地安全通信协议的密钥管理方法，其特征在于，取消CTCS-3级列控系统车地安全通信协议所要求设置的密钥管理中心，由CTCS-3级列控系统中的安全相关设备分担车地安全通信协议所要求的密钥管理功能，所述方法包括：

离线生成传输密钥和验证密钥的密钥本，并将所述密钥本存储于所述CTCS-3级列控系统中的安全相关设备中；

应用公钥密码体制根据所述传输密钥的密钥本为CTCS-3级列控系统中的安全相关设备分配传输密钥；

在传输密钥分配完成后，利用所述传输密钥基于CTCS-3级列控系统车地安全通信协议建立安全通道，利用所述安全通道为所述安全相关设备分发验证密钥。

2.根据权利要求1所述的方法，其特征在于，所述的安全相关设备包括：地面无线闭塞中心RBC和车载设备OBU。

3.根据权利要求1或2所述的方法，其特征在于，所述的通过CTCS-3级列控系统中的安全相关设备生成传输密钥和验证密钥的密钥本，包括：

离线将一定数量的密钥随机进行排序，所述安全相关设备获取每个密钥对应的序号，计算每个密钥与其对应序号的hash值，该hash值记为H(密钥∣序号)，对所述的传输密钥与验证密钥各生成一套包括序号、密钥和hash值的密钥本，将所述传输密钥与验证密钥的密钥本存储在CTCS-3级列控系统中所有需要安全通信的安全相关设备中。

4.根据权利要求3所述的方法，其特征在于，所述的应用公钥密码体制为CTCS-3级列控系统中的安全相关设备分配传输密钥，包括：

针对OBU首次或重新上电后，OBU与控车RBC1间部署传输密钥的情况一，采用非对称加密方式使所述RBC1与OBU获得所述传输密钥；

针对越区切换时，控车RBC从RBC1切换到RBC2，OBU与RBC2间部署传输密钥的情况二：

若同一OBU与各个RBC使用同一套传输密钥时，采用对称加密与非对称加密相结合的方式使所述RBC2与OBU获得所述的传输密钥，

若每对OBU与RBC都使用不同的传输密钥时，当车载电台只有一部电台正常时，采用对称加密与非对称加密相结合的方式使所述RBC2与OBU获得所述的传输密钥，当车载两部电台都正常时，则按所述情况一方式操作。

5.根据权利要求1所述的方法，其特征在于，所述的在传输密钥分配完成后，利用所述传输密钥建立安全通道，利用所述安全通道为所述安全相关设备分发验证密钥，包括：

Step1：在RBC和OBU已经安装了传输密钥KTRANS后，OBU向RBC发送验证密钥申请；

Step2：RBC收到所述验证密钥申请请求后，生成随机数Rc和Rd，在RBC保存的验证密钥本中查找Rc对应的验证密钥KMAC以及hash值，将该hash值记为Ha，计算s＝Rc+Rd,由KTRANS加密Ha以及s，并发给OBU；

Step3：OBU收到RBC发送过来的加密后的Ha以及s后，利用KTRANS解密得到Ha’和s’，在OBU保存的验证密钥本中查找Ha’对应的序号Rc’与验证密钥KMAC，计算Rd’＝s-Rc’，向RBC发送包括Rd’的反馈信息；

Step4：RBC收到所述反馈信息后，对比Rd与Rd’，若相等，则表示OBU与RBC之间验证密钥共享成功，RBC记录密钥序号Rc、Ha以及车载信息；若不相等，则重新发送Step2中信息，继续执行Step3、Step4。

6.根据权利要求2至5任一项所述的方法，其特征在于，所述的方法还包括：

在车载设备重新上电时，重新分配传输密钥和验证密钥；

在验证密钥处理了一定数目的会话密钥、验证密钥失效或者不具有保密性后，对验证密钥进行更新，RBC向OBU发送密钥更新命令，执行验证密钥分配流程。

7.根据权利要求6所述的方法，其特征在于，所述的方法还包括：

在更新密钥后，RBC删除自己安装的旧密钥信息，并命令OBU删除对应的旧密钥信息，OBU向RBC确认密钥删除已经完成。

8.根据权利要求6所述的方法，其特征在于，所述的方法还包括：

RBC记录其管辖范围内所有与其建立安全连接的OBU对应的密钥信息，RBC为OBU分发传输密钥和验证密钥后，记录车载信息与对应的密钥序号，hash值以及密钥类型等信息；对于失效的密钥，将对应的密钥序号、hash值以及密钥类型记录到失效密钥本中。