铁路桥梁监测中基于短签名方案的数据传输协议

左黎明，胡凯雨，张梦丽，陈兰兰

(1.华东交通大学 理学院，南昌 330013； 2.华东交通大学 系统工程与密码学研究所，南昌 330013)(*通信作者电子邮箱limingzuo@126.com)

0 引言

随着我国经济发展、城市化水平提高和人们出行频繁，铁路作为国家的基础设施和大众化的交通工具扮演着越来越重要的角色[1]。铁路桥梁受行车密度大、列车的频繁碾压和潜在的人为因素与自然因素的影响使得桥梁结构产生局部变形、磨损和消耗。随着时间的推移，如果桥梁结构磨损到达一定程度时会对列车运行造成严重影响[2-3]。1981年，由尼日开往成都的成昆铁路列车运行至乌斯河站时，大渡河爆发泥石流冲垮铁路桥导致超过240人死亡或失踪[4]；2010年，由西安开往昆明的列车运行至石亭江大桥时，洪水导致大桥倾斜、桥墩倒塌、列车脱线、车厢悬空[4]。所以为保证列车安全运行，近年来国内外专家、学者对铁路桥梁智能监测进行了研究，如刘南平等[5]设计了以单片机为核心的铁路桥梁应变检测分析仪，对铁路桥梁在静载、动载情况下进行检测；石梅香[6]提出了基于AD(Analog Devices)7657的铁路桥梁检测数据采集系统，实现了对数据的同步采集；战家旺等[7]提出了基于列车动力响应的铁路桥梁损伤诊断方法；Chalouhi等[8]提出了机器学习在铁路桥梁损伤监测中的应用；王伟等[9]设计了一种基于大数据的铁路信号系统数据存储与分析系统。在开放式互联网环境下，数据交互过程存在信息泄露与篡改的网络安全隐患[10]，但上述监测方案并没有考虑到采集数据传输的安全性问题；而且在某些恶劣环境下，铁路桥梁监测点中的数据采集装置的计算、数据存储与传输能力等较差，因此需要一种数据长度较短、效率和安全性高的签名方案。基于身份的短签名的特点在于只需要签名端的身份信息而无需签名端的证书来验证签名的有效性，减少了数字证书的存储；且签名数据较短，签名速度较快，既保证了传输数据的安全性，又降低了对数据采集装置端的计算和存储数据能力的要求。

1984年，Shamir[11]首次提出基于身份的密码体制，同时构造了第一个基于身份的签名方案；Joux[12]在双线性对上构造了基于身份的数字签名方案，有效解决了方案中的密钥分发的问题；Boneh等[13]基于Joux思想利用双线性对构造了效率较高的基于身份的加密方案；同年的亚洲密码会上，Boneh等[14]又提出了短签名的概念，同时构造了一种签名长度仅为传统签名一半的短签名方案。随后人们将基于身份的签名方案和短签名方案相结合提出了一种基于身份的短数字签名方案。如蔡志伟等[15]提出了在标准模型下的基于分级身份的短签名方案;Asaar等[16]构造了一种基于身份的短代理环签名方案;Karati等[17]提出了在随机预言机模型下可证安全的基于身份的短签名方案;Meshram等[18]在随机预言机模型下使用部分离散对数实现了基于在线/离线身份的短签名方案。

本文在Boneh方案基本思想的基础上，根据特定应用场景的需求，构造了一种基于身份的高效短签名方案，该方案的签名过程仅使用1次哈希运算和1次倍点运算，验证过程仅使用1次哈希运算和2次双线性对运算;而且还以签名方案为基础设计了适用于铁路桥梁监测数据传输协议，在采集装置计算能力和传输能力较差情况下实现了实时采集数据包的安全认证和可靠传输。

1 相关基础

1.1 数据传输协议与系统原理

图1为桥梁监测中数据传输协议的系统架构，包括采集装置端和云服务器端。数据采集装置分布在每个桥梁监测点并固定于铁轨与桥梁之间。数据采集装置以树莓派(Raspberry Pi)[19]为控制中心，并包含压力传感器、定位传感器、振弦式传感器、振动测量传感器、加速度传感器、噪声传感器、图像传感器等各种传感器。

数据采集装置中的树莓派设计了签名模块、信息处理模块和GPRS(General Packet Radio Service)通信模块。云服务器中配置了身份认证模块、信息处理模块和密钥生成中心(Key Generator Center， KGC)。数据采集装置中的传感器每隔一段时间收集监测点的位置、桥梁的应变压力、振动信号和周围的噪声等数据后发送给树莓派，树莓派接收数据后对其进行签名，通过GPRS通信模块向云服务器发送数据。云服务器接收数据后对签名进行验证。

图1 系统架构

1.2 可证安全的基于身份的数字签名

1.2.1 基础定义

定义1 双线性对 (Bilinear Pairing)。设G1为q阶加法循环群，G2为q阶乘法循环群，P为G1的生成元，称映射e:G1×G1→G2为双线对，如果e满足以下三条性质:

2)非退化性：对任意的M,N∈G1，使得e(M,N)≠1。

1.2.2 基于身份的签名定义

基于身份的签名方案的签名算法如下：

1)系统初始化算法(Setup)：KGC输入安全参数1λ(λ∈N)，输出系统主密钥s和系统参数params，KGC秘密保存s并公布参数params；

2)私钥解析算法(KeyEx)：输入用户身份ID∈{0,1}*，KGC利用系统主密钥s和系统参数params解析出用户的私钥dID，并通过安全信道将私钥dID发生给用户；

3)签名生成算法(Sign)：输入系统参数params、用户私钥dID和消息m∈{0,1}*，输出对应签名(m,S)；

4)签名验证算法(Verify)：输入系统参数params、用户身份ID和签名(m,S)，验证该签名是否是身份ID的合法签名，如果签名有效，则返回1，否则返回0。

1.2.3 攻击者模型

基于身份的数字签名通常假定密钥生成中心是安全可靠的，攻击者来自恶意的用户。本文方案与传统的基于身份的签名方案有所不同，是为特定环境下的应用场景设计的，云服务器的信息管理系统包含密钥生成、数据处理和身份认证，保存了所有数据采集装置端的身份ID和对应公钥，既负责密钥生成，也负责对数据进行认证和处理，因此可以对密钥替换攻击进行防范。在这种情况下敌手能力受限，能力要弱于攻击一般基于身份的数字签名的敌手。针对本文方案的安全模型可以通过挑战者Challenger和签名攻击算法Adversary之间进行如下的攻击游戏来描述。值得注意的是，在伪造攻击之前，询问过程可以是多项式有界次。

1)挑战者Challenger运行系统初始化算法，产生系统参数params和系统密钥s，把params发送给攻击算法Adversary。

2)攻击算法Adversary适应性地执行下面一系列随机预言机询问：

a)Hash询问：对Adversary的每条Hash值的查询，挑战者Challenger产生相应的哈希值H，并将H发送给Adversary；

b)私钥解析询问：Adversary根据自己的需要向挑战者Challenger询问用户ID的私钥，Challenger运行私钥解析算法产生私钥dID，并将私钥dID发送给Adversary；

c)签名询问：Adversary根据自己的需要向挑战者Challenger询问身份ID关于任意消息m的签名，Challenger运行签名生成算法产生相应签名S，并将签名S发送给Adversary。

3)Adversary生成一个身份ID*(ID*的私钥没有泄露)的消息签名对(m*,S*)，如果满足下面条件，则Adversary在该游戏中获胜：

a)Verify(params,ID*,M*,S*)=1；

b)ID*从来没有提交给私钥解析预言机；

c)(ID*,m*)从来没有提交给签名预言机。

2 基于身份的短签名方案构造

传输协议中的云服务器的信息管理系统包含了密钥生成中心(KGC)，且每个数据采集装置均有唯一标识身份的装置编号ID，利用装置编号作为每一个装置的记录索引，可以实现高速的信息查询与检索。其次，在数据采集过程中，希望传输数据长度尽可能地短，以提高效率，因此在协议中采用基于身份的短签名方案对数据进行签名。KGC利用数据采集装置编号ID生成各自对应的签名私钥，并以编号ID为索引记录对应公钥到相应的数据表中，在装置初始化时注入其对应私钥和公钥。为叙述方便，称编号为ID的数据采集装置为一个身份为ID的用户，云服务端为验证者。

本文方案由以下四个算法组成：

3)签名生成算法(Sign)：给定消息m，用户利用自己的私钥dID进行如下操作：

a)计算h=H2(m,ID,T,QID)，其中参数T为时间戳。T会随消息m一起发送给云服务器，便于云服务器对装置实时采集数据进行管理与索引。

b)计算S=dIDh，则S就构成了用户ID对消息m的签名。

4)签名验证算法(Verify)：对于给定消息/签名对(m,S),验证者计算如下:

a)计算h=H2(m,ID,T,QID)。

b)当且仅当等式e(S,QID)=e(h,P)成立时接受签名S，否则拒绝接受签名S。等式的正确性证明如下：

3 方案安全性与性能分析

3.1 安全性分析

下面证明在随机预言机模型及Inv-CDH困难问题假设下，本文提出的基于身份的短签名方案在适应性选择消息和身份攻击下是存在性不可伪造的。

证明 假定Challenger有一个Inv-CDH困难问题的实例为nP，mP∈G1，需输出mn-1P。

Challenger的目标是通过调用签名攻击算法Adversary来解决上述困难问题。在游戏中假定对任意用户身份ID，签名攻击算法Adversary在进行私钥解析询问、签名询问以及输出签名之前都询问过关于用户身份ID的H1和H2预言机，而且Adversary不会对预言机发起两次相同的询问。不妨把目标身份ID*的相关参数嵌入到困难问题的条件中。

Challenger在系统初始化后公布系统参数params=〈λ,G1,G2,e,q,P,Ppub,H1,H2〉,同时将系统参数params发送给签名攻击算法Adversary。则签名攻击算法Adversary向挑战者Challenger适应性执行下面一系列随机预言机询问：

1)H1询问：Challenger维护一个列表ListH1，该列表由数组(IDi,Ki)组成，当Adversary向Challenger提交一个身份ID的H1询问时，Challenger进行如下操作：

a)如果提交身份ID=ID*，Challenger终止询问，并输出“FAILURE”(该事件发生用Event1表示)。

2)私钥解析询问：Challenger维护一个列表ListE，该列表由数组(IDi,dIDi)组成，当Adversary向Challenger提交一个关于身份ID的私钥解析询问时，Challenger从列表ListH1中恢复数组对应的(ID,a)，再进行以下操作：

a)如果身份ID≠ID*，则Challenger把(a+s)作为dID，将(ID,dID)添加到列表ListE中，并返回dID给Adversary；

b)否则，Challenger终止询问，并输出“FAILURE”(该事件发生用Event2表示)。

3)H2询问：Challenger维护一个列表ListH2，该列表由数组(IDi,mi,Ti,Qi,hi)组成，当Adversary向Challenger提交(ID,mID)的H2询问时，Challenger进行以下操作：

a)如果ID=ID*，Challenger将mP作为H2(ID,mID,T,QID)的值返回给Adversary，同时将(ID,mID,T,QID,mP)保存到列表ListH2中；

4)公钥询问:Challenger维护一个由数组(IDi,di,Qi)组成的列表Listpk。当Adversary向Challenger提交ID的公钥询问时，Challenger进行以下操作：

a)如果列表中已存在询问的答案，则返回相应的答案给Adversary；

b)如果ID=ID*，Challenger将nP作为公钥返回给Adversary，同时将(ID,⊥,nP)保存到列表Listpk中，其中⊥表示为空；

5)签名询问：当Adversary向Challenger提交一个(ID,mID)的签名询问时，首先Challenger从ListH2中恢复数组列表(ID,mID,T,QID,h)，然后进行以下操作：

a)如果ID≠ID*，则Challenger从列表ListE获得对应数组(ID,dID)，计算S=dIDh，则S即为身份为ID对消息mID的签名。Challenger将S返回给Adversary。

b)否则，Challenger终止询问，输出“FAILURE”(该事件发生用Event3表示)。

2)只有当事件Event1、Event2和Event3不发生时，对私钥解析询问和签名预言机询问所得到的答案才是有效的。

3)如果事件Event1、Event2和Event3都不发生时，则Challenger能解决Inv-CDH问题的一个实例。则可得事件Event1、Event2和Event3都不发生的概率为：

3.2 方案性能分析与比较

表1给出了本文方案与经典的短签名方案以及近几年签名方案的椭圆曲线版本之间的性能比较。表1中：PM1表示G1上的倍点运算，PM2表示G2上的乘运算，E表示双线性对运算，H表示哈希运算。

在签名阶段本文方案需要1次G1上的倍点运算和1次哈希运算，Boneh方案[14]需要1次G1上的倍点运算和1次哈希运算，而Karati方案[17]要2次G1上的倍点运算和1次哈希运算，Fangguo Zhang方案[20]需要1次倍点运算和1次哈希运算，Leyou Zhang方案[21]需要3次G1上倍点运算和1次哈希运算。在签名验证阶段本文方案需要2次双线性对运算和1次哈希运算， Boneh方案[14]同样需要2次双线性对运算和1次哈希运算，而Karati方案[17]需要2次双线性对和1次G1上的倍点运算和1次哈希运算，Fangguo Zhang方案[20]需要2次双线性对运算、2次倍点运算和1次哈希运算，Leyou Zhang方案[21]需要3次双线性对运算、1次G1上的倍点运算和1次G2上的乘运算和1次哈希运算。因此，本文方案接近Boneh方案[14]，但对比其他方案具有效率优势。

表1 各方案性能比较

通过上述性能比较可知，相比其他签名方案，本文方案在签名和验证阶段的计算复杂性较低，且生成的签名长度相对较短，在特定应用场景下具有良好的适用性。本文方案的不足在于它考虑的敌手是特定应用场景下的敌手，所考虑的敌手能力比一般的普通方案的敌手能力要弱。而事实上，由于铁路桥梁的环境影响，传感器网络接入和传输均受到多重限制，敌手攻击的能力也比一般情况下要弱，因此基于该方案设计的监测数据传输协议的安全性在此环境下相对较高。

4 协议设计与实现中的关键技术

4.1 数据封包设计

在协议交互的过程中，为保证数据采集装置(用户)与云服务器(验证者)的数据安全性传输，设计格式形如ID#Data#T#Sign(Hash(ID#Data#T))的数据封包。其中“#”表示数据连接符号，Data表示编号为ID数据采集装置各个传感器获取的数据，T表示时间戳，Hash(ID#Data#T)表示对数据进行哈希运算，Sign(Hash(ID#Data#T))表示对哈希数据进行签名。

4.2 信息处理模块设计

数据采集装置中的信息处理模块用于将签名模块生成的签名数据、传感器数据Data、数据采集装置编号ID和时间戳T组成上述的数据封包格式，并通过GPRS通信模块向云服务器发送数据。云服务器中的信息处理模块对收到的数据封包根据数据连接符“#”进行解析，获取封包中的数据。

4.3 协议交互流程设计

图2为协议中数据采集装置(用户)与云服务器(验证者)进行交互的流程，包括以下步骤：

传感器→信息处理模块：数据采集装置中的传感器每隔一定时间收集到桥梁的位置、桥梁固有频率、桥梁的应变压力和周围噪声等数据Data，并将数据发送给信息处理模块。

信息处理模块→签名模块：信息处理模块对数据采集装置唯一编号ID、传感器收集的数据Data和时间戳T进行哈希运算Hash(ID#Data#T)，将数据发送给签名模块。

签名模块→信息处理模块：数据采集装置中的签名模块获取哈希数据后进行签名Sign(Hash(ID#Data#T))。

数据采集装置→云服务器：数据采集装置的信息处理模块接收签名后，组成数据封包格式通过GPRS通信模块向云服务器发送封包。

信息处理模块→身份认证模块：云服务器信息处理模块接收数据封包对数据进行解析并将签名数据发送给身份认证模块。身份认证模块进行签名验证

Verify(Sign(Hash(ID#Data#T))。如果签名验证失败，则不接收数据，并将数据采集装置的位置标记为预警状态；否则，接收并保存数据。

图2 协议交互图

5 实验与仿真

在Windows 7 64位操作系统下，使用微软Visual Studio 2012开发平台，用C语言实现了本文方案，方案的核心代码如下：

//1)参数生成算法

element_ts,P,Pub;

elemet_init_Zr(s,pairing);

element_init_G1(P,pairing);

element_init_G1(Pub,pairing);

element_random(P);

//P是G1的生成元

element_random(s);

element_mul(Pub,s,P);

//计算等式Pub=sP

//2)私钥解析算法

element_tQID,sH1,H1,sH1invert,dID;

element_init_G1(QID,pairing);

//公钥QID

element_init_Zr(H1,pairing);

element_init_Zr(sH1,pairing);

element_init_Zr(sH1invert,pairing);

element_init_Zr(dID,pairing);

//私钥dID

element_from_hash(H1,ID,strlen(ID));

//H1=H1(ID,s)在实验程序方法hash中可忽略参数s

element_add(sH1,H1,s);

//sH1=s+H1(ID,s)

element_invert(sH1invert,sH1);

element_mul(QID,sH1invert,P);

//QID=(H1+s)-1*P

element_add(dID,sH1,s);

//dID=H1(ID,s)+s

//3)签名算法

element_th,hr,S;

element_init_G1(h,pairing);

element_init_G1(S,pairing);

element_from_hash(h,m,strlen(m));

//m为消息

//h=H2(m,ID,T,QID)实验程序中仅对

//消息m进行了hash,可忽略其他参数

element_mul(S,h,dID);

//签名S=h*dID

//4)签名验证算法

element_tLeft,Right;

element_init_GT(Left,pairing);

element_init_GT(Right,pairing);

element_pairing(Left,S,QID);

//Left=e(S,QID);

element_pairing(Right,h,P);

//Right=e(h,P);

element_printf("签名数据S=%B ",S);

element_printf("Left=%B ",Left);

element_printf("Right=%B ",Right);

在同一环境下(CPU为Intel i3 4150，内存为海力士Double-Data-Rate Three 8 GB，操作系统为Windows 7 64位操作系统)对几种经典的签名方案实现并多次运行进行耗时比较，结果如表2所示。由表2可知，本文方案运行平均总耗时约为0.152 s，其中签名和签名验证所消耗的平均时间分别为0.056 s、0.035 s。本文方案在方案总耗时上与经典方案Boneh[14]接近，但与Karati方案[17]相比，方案平均耗时减少了约13%，与Fangguo Zhang[20]方案相比，方案平均耗时减少了约6%，与Leyou Zhang[21]方案相比，方案平均耗时减少了约22%。

表2 各方案运行25次平均耗时比较

6 结语

本文针对现有的桥梁监测系统和设计方案在信息交互过程中缺乏安全性认证和数据完整性保护的缺点，构造了一种基于身份的短签名方案，并在此基础上设计了安全的桥梁监测数据交互协议。随后，对签名方案进行了安全性证明和实验仿真，结果表明签名方案计算量小，效率较高，可有效解决桥梁监测数据的完整性保护和身份可靠性认证问题。在下一步研究工作中，考虑到对数据采集装置的隐蔽性问题和本文方案的不足，具有用户匿名性的安全双因子认证方案[22-23]能适应高安全需求环境的用户身份认证，因此可以考虑在客户端设计上引入安全双因子认证方案。