左黎明，胡凱雨，張夢麗，陳蘭蘭

(1.華東交通大學 理學院，南昌 330013； 2.華東交通大學 系統(tǒng)工程與密碼學研究所，南昌 330013)(*通信作者電子郵箱limingzuo@126.com)

0 引言

隨著我國經(jīng)濟發(fā)展、城市化水平提高和人們出行頻繁，鐵路作為國家的基礎設施和大眾化的交通工具扮演著越來越重要的角色[1]。鐵路橋梁受行車密度大、列車的頻繁碾壓和潛在的人為因素與自然因素的影響使得橋梁結構產(chǎn)生局部變形、磨損和消耗。隨著時間的推移，如果橋梁結構磨損到達一定程度時會對列車運行造成嚴重影響[2-3]。1981年，由尼日開往成都的成昆鐵路列車運行至烏斯河站時，大渡河爆發(fā)泥石流沖垮鐵路橋?qū)е鲁^240人死亡或失蹤[4]；2010年，由西安開往昆明的列車運行至石亭江大橋時，洪水導致大橋傾斜、橋墩倒塌、列車脫線、車廂懸空[4]。所以為保證列車安全運行，近年來國內(nèi)外專家、學者對鐵路橋梁智能監(jiān)測進行了研究，如劉南平等[5]設計了以單片機為核心的鐵路橋梁應變檢測分析儀，對鐵路橋梁在靜載、動載情況下進行檢測；石梅香[6]提出了基于AD(Analog Devices)7657的鐵路橋梁檢測數(shù)據(jù)采集系統(tǒng)，實現(xiàn)了對數(shù)據(jù)的同步采集；戰(zhàn)家旺等[7]提出了基于列車動力響應的鐵路橋梁損傷診斷方法；Chalouhi等[8]提出了機器學習在鐵路橋梁損傷監(jiān)測中的應用；王偉等[9]設計了一種基于大數(shù)據(jù)的鐵路信號系統(tǒng)數(shù)據(jù)存儲與分析系統(tǒng)。在開放式互聯(lián)網(wǎng)環(huán)境下，數(shù)據(jù)交互過程存在信息泄露與篡改的網(wǎng)絡安全隱患[10]，但上述監(jiān)測方案并沒有考慮到采集數(shù)據(jù)傳輸?shù)陌踩詥栴}；而且在某些惡劣環(huán)境下，鐵路橋梁監(jiān)測點中的數(shù)據(jù)采集裝置的計算、數(shù)據(jù)存儲與傳輸能力等較差，因此需要一種數(shù)據(jù)長度較短、效率和安全性高的簽名方案?；谏矸莸亩毯灻奶攸c在于只需要簽名端的身份信息而無需簽名端的證書來驗證簽名的有效性，減少了數(shù)字證書的存儲；且簽名數(shù)據(jù)較短，簽名速度較快，既保證了傳輸數(shù)據(jù)的安全性，又降低了對數(shù)據(jù)采集裝置端的計算和存儲數(shù)據(jù)能力的要求。

1984年，Shamir[11]首次提出基于身份的密碼體制，同時構造了第一個基于身份的簽名方案；Joux[12]在雙線性對上構造了基于身份的數(shù)字簽名方案，有效解決了方案中的密鑰分發(fā)的問題；Boneh等[13]基于Joux思想利用雙線性對構造了效率較高的基于身份的加密方案；同年的亞洲密碼會上，Boneh等[14]又提出了短簽名的概念，同時構造了一種簽名長度僅為傳統(tǒng)簽名一半的短簽名方案。隨后人們將基于身份的簽名方案和短簽名方案相結合提出了一種基于身份的短數(shù)字簽名方案。如蔡志偉等[15]提出了在標準模型下的基于分級身份的短簽名方案;Asaar等[16]構造了一種基于身份的短代理環(huán)簽名方案;Karati等[17]提出了在隨機預言機模型下可證安全的基于身份的短簽名方案;Meshram等[18]在隨機預言機模型下使用部分離散對數(shù)實現(xiàn)了基于在線/離線身份的短簽名方案。

本文在Boneh方案基本思想的基礎上，根據(jù)特定應用場景的需求，構造了一種基于身份的高效短簽名方案，該方案的簽名過程僅使用1次哈希運算和1次倍點運算，驗證過程僅使用1次哈希運算和2次雙線性對運算;而且還以簽名方案為基礎設計了適用于鐵路橋梁監(jiān)測數(shù)據(jù)傳輸協(xié)議，在采集裝置計算能力和傳輸能力較差情況下實現(xiàn)了實時采集數(shù)據(jù)包的安全認證和可靠傳輸。

1 相關基礎

1.1 數(shù)據(jù)傳輸協(xié)議與系統(tǒng)原理

圖1為橋梁監(jiān)測中數(shù)據(jù)傳輸協(xié)議的系統(tǒng)架構，包括采集裝置端和云服務器端。數(shù)據(jù)采集裝置分布在每個橋梁監(jiān)測點并固定于鐵軌與橋梁之間。數(shù)據(jù)采集裝置以樹莓派(Raspberry Pi)[19]為控制中心，并包含壓力傳感器、定位傳感器、振弦式傳感器、振動測量傳感器、加速度傳感器、噪聲傳感器、圖像傳感器等各種傳感器。

數(shù)據(jù)采集裝置中的樹莓派設計了簽名模塊、信息處理模塊和GPRS(General Packet Radio Service)通信模塊。云服務器中配置了身份認證模塊、信息處理模塊和密鑰生成中心(Key Generator Center， KGC)。數(shù)據(jù)采集裝置中的傳感器每隔一段時間收集監(jiān)測點的位置、橋梁的應變壓力、振動信號和周圍的噪聲等數(shù)據(jù)后發(fā)送給樹莓派，樹莓派接收數(shù)據(jù)后對其進行簽名，通過GPRS通信模塊向云服務器發(fā)送數(shù)據(jù)。云服務器接收數(shù)據(jù)后對簽名進行驗證。

圖1 系統(tǒng)架構

1.2 可證安全的基于身份的數(shù)字簽名

1.2.1 基礎定義

定義1 雙線性對 (Bilinear Pairing)。設G1為q階加法循環(huán)群，G2為q階乘法循環(huán)群，P為G1的生成元，稱映射e:G1×G1→G2為雙線對，如果e滿足以下三條性質(zhì):

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

1.2.2 基于身份的簽名定義

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

1)系統(tǒng)初始化算法(Setup)：KGC輸入安全參數(shù)1λ(λ∈N)，輸出系統(tǒng)主密鑰s和系統(tǒng)參數(shù)params，KGC秘密保存s并公布參數(shù)params；

2)私鑰解析算法(KeyEx)：輸入用戶身份ID∈{0,1}*，KGC利用系統(tǒng)主密鑰s和系統(tǒng)參數(shù)params解析出用戶的私鑰dID，并通過安全信道將私鑰dID發(fā)生給用戶；

3)簽名生成算法(Sign)：輸入系統(tǒng)參數(shù)params、用戶私鑰dID和消息m∈{0,1}*，輸出對應簽名(m,S)；

4)簽名驗證算法(Verify)：輸入系統(tǒng)參數(shù)params、用戶身份ID和簽名(m,S)，驗證該簽名是否是身份ID的合法簽名，如果簽名有效，則返回1，否則返回0。

1.2.3 攻擊者模型

基于身份的數(shù)字簽名通常假定密鑰生成中心是安全可靠的，攻擊者來自惡意的用戶。本文方案與傳統(tǒng)的基于身份的簽名方案有所不同，是為特定環(huán)境下的應用場景設計的，云服務器的信息管理系統(tǒng)包含密鑰生成、數(shù)據(jù)處理和身份認證，保存了所有數(shù)據(jù)采集裝置端的身份ID和對應公鑰，既負責密鑰生成，也負責對數(shù)據(jù)進行認證和處理，因此可以對密鑰替換攻擊進行防范。在這種情況下敵手能力受限，能力要弱于攻擊一般基于身份的數(shù)字簽名的敵手。針對本文方案的安全模型可以通過挑戰(zhàn)者Challenger和簽名攻擊算法Adversary之間進行如下的攻擊游戲來描述。值得注意的是，在偽造攻擊之前，詢問過程可以是多項式有界次。

1)挑戰(zhàn)者Challenger運行系統(tǒng)初始化算法，產(chǎn)生系統(tǒng)參數(shù)params和系統(tǒng)密鑰s，把params發(fā)送給攻擊算法Adversary。

2)攻擊算法Adversary適應性地執(zhí)行下面一系列隨機預言機詢問：

a)Hash詢問：對Adversary的每條Hash值的查詢，挑戰(zhàn)者Challenger產(chǎn)生相應的哈希值H，并將H發(fā)送給Adversary；

b)私鑰解析詢問：Adversary根據(jù)自己的需要向挑戰(zhàn)者Challenger詢問用戶ID的私鑰，Challenger運行私鑰解析算法產(chǎn)生私鑰dID，并將私鑰dID發(fā)送給Adversary；

c)簽名詢問：Adversary根據(jù)自己的需要向挑戰(zhàn)者Challenger詢問身份ID關于任意消息m的簽名，Challenger運行簽名生成算法產(chǎn)生相應簽名S，并將簽名S發(fā)送給Adversary。

3)Adversary生成一個身份ID*(ID*的私鑰沒有泄露)的消息簽名對(m*,S*)，如果滿足下面條件，則Adversary在該游戲中獲勝：

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

b)ID*從來沒有提交給私鑰解析預言機；

c)(ID*,m*)從來沒有提交給簽名預言機。

2 基于身份的短簽名方案構造

傳輸協(xié)議中的云服務器的信息管理系統(tǒng)包含了密鑰生成中心(KGC)，且每個數(shù)據(jù)采集裝置均有唯一標識身份的裝置編號ID，利用裝置編號作為每一個裝置的記錄索引，可以實現(xiàn)高速的信息查詢與檢索。其次，在數(shù)據(jù)采集過程中，希望傳輸數(shù)據(jù)長度盡可能地短，以提高效率，因此在協(xié)議中采用基于身份的短簽名方案對數(shù)據(jù)進行簽名。KGC利用數(shù)據(jù)采集裝置編號ID生成各自對應的簽名私鑰，并以編號ID為索引記錄對應公鑰到相應的數(shù)據(jù)表中，在裝置初始化時注入其對應私鑰和公鑰。為敘述方便，稱編號為ID的數(shù)據(jù)采集裝置為一個身份為ID的用戶，云服務端為驗證者。

本文方案由以下四個算法組成：

3)簽名生成算法(Sign)：給定消息m，用戶利用自己的私鑰dID進行如下操作：

a)計算h=H2(m,ID,T,QID)，其中參數(shù)T為時間戳。T會隨消息m一起發(fā)送給云服務器，便于云服務器對裝置實時采集數(shù)據(jù)進行管理與索引。

b)計算S=dIDh，則S就構成了用戶ID對消息m的簽名。

4)簽名驗證算法(Verify)：對于給定消息/簽名對(m,S),驗證者計算如下:

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

b)當且僅當?shù)仁絜(S,QID)=e(h,P)成立時接受簽名S，否則拒絕接受簽名S。等式的正確性證明如下：

3 方案安全性與性能分析

3.1 安全性分析

下面證明在隨機預言機模型及Inv-CDH困難問題假設下，本文提出的基于身份的短簽名方案在適應性選擇消息和身份攻擊下是存在性不可偽造的。

證明 假定Challenger有一個Inv-CDH困難問題的實例為nP，mP∈G1，需輸出mn-1P。

Challenger的目標是通過調(diào)用簽名攻擊算法Adversary來解決上述困難問題。在游戲中假定對任意用戶身份ID，簽名攻擊算法Adversary在進行私鑰解析詢問、簽名詢問以及輸出簽名之前都詢問過關于用戶身份ID的H1和H2預言機，而且Adversary不會對預言機發(fā)起兩次相同的詢問。不妨把目標身份ID*的相關參數(shù)嵌入到困難問題的條件中。

Challenger在系統(tǒng)初始化后公布系統(tǒng)參數(shù)params=〈λ,G1,G2,e,q,P,Ppub,H1,H2〉,同時將系統(tǒng)參數(shù)params發(fā)送給簽名攻擊算法Adversary。則簽名攻擊算法Adversary向挑戰(zhàn)者Challenger適應性執(zhí)行下面一系列隨機預言機詢問：

1)H1詢問：Challenger維護一個列表ListH1，該列表由數(shù)組(IDi,Ki)組成，當Adversary向Challenger提交一個身份ID的H1詢問時，Challenger進行如下操作：

a)如果提交身份ID=ID*，Challenger終止詢問，并輸出“FAILURE”(該事件發(fā)生用Event1表示)。

2)私鑰解析詢問：Challenger維護一個列表ListE，該列表由數(shù)組(IDi,dIDi)組成，當Adversary向Challenger提交一個關于身份ID的私鑰解析詢問時，Challenger從列表ListH1中恢復數(shù)組對應的(ID,a)，再進行以下操作：

a)如果身份ID≠ID*，則Challenger把(a+s)作為dID，將(ID,dID)添加到列表ListE中，并返回dID給Adversary；

b)否則，Challenger終止詢問，并輸出“FAILURE”(該事件發(fā)生用Event2表示)。

3)H2詢問：Challenger維護一個列表ListH2，該列表由數(shù)組(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維護一個由數(shù)組(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中恢復數(shù)組列表(ID,mID,T,QID,h)，然后進行以下操作：

a)如果ID≠ID*，則Challenger從列表ListE獲得對應數(shù)組(ID,dID)，計算S=dIDh，則S即為身份為ID對消息mID的簽名。Challenger將S返回給Adversary。

b)否則，Challenger終止詢問，輸出“FAILURE”(該事件發(fā)生用Event3表示)。

2)只有當事件Event1、Event2和Event3不發(fā)生時，對私鑰解析詢問和簽名預言機詢問所得到的答案才是有效的。

3)如果事件Event1、Event2和Event3都不發(fā)生時，則Challenger能解決Inv-CDH問題的一個實例。則可得事件Event1、Event2和Event3都不發(fā)生的概率為：

3.2 方案性能分析與比較

表1給出了本文方案與經(jīng)典的短簽名方案以及近幾年簽名方案的橢圓曲線版本之間的性能比較。表1中：PM1表示G1上的倍點運算，PM2表示G2上的乘運算，E表示雙線性對運算，H表示哈希運算。

在簽名階段本文方案需要1次G1上的倍點運算和1次哈希運算，Boneh方案[14]需要1次G1上的倍點運算和1次哈希運算，而Karati方案[17]要2次G1上的倍點運算和1次哈希運算，F(xiàn)angguo Zhang方案[20]需要1次倍點運算和1次哈希運算，Leyou Zhang方案[21]需要3次G1上倍點運算和1次哈希運算。在簽名驗證階段本文方案需要2次雙線性對運算和1次哈希運算， Boneh方案[14]同樣需要2次雙線性對運算和1次哈希運算，而Karati方案[17]需要2次雙線性對和1次G1上的倍點運算和1次哈希運算，F(xiàn)angguo Zhang方案[20]需要2次雙線性對運算、2次倍點運算和1次哈希運算，Leyou Zhang方案[21]需要3次雙線性對運算、1次G1上的倍點運算和1次G2上的乘運算和1次哈希運算。因此，本文方案接近Boneh方案[14]，但對比其他方案具有效率優(yōu)勢。

表1 各方案性能比較

通過上述性能比較可知，相比其他簽名方案，本文方案在簽名和驗證階段的計算復雜性較低，且生成的簽名長度相對較短，在特定應用場景下具有良好的適用性。本文方案的不足在于它考慮的敵手是特定應用場景下的敵手，所考慮的敵手能力比一般的普通方案的敵手能力要弱。而事實上，由于鐵路橋梁的環(huán)境影響，傳感器網(wǎng)絡接入和傳輸均受到多重限制，敵手攻擊的能力也比一般情況下要弱，因此基于該方案設計的監(jiān)測數(shù)據(jù)傳輸協(xié)議的安全性在此環(huán)境下相對較高。

4 協(xié)議設計與實現(xiàn)中的關鍵技術

4.1 數(shù)據(jù)封包設計

在協(xié)議交互的過程中，為保證數(shù)據(jù)采集裝置(用戶)與云服務器(驗證者)的數(shù)據(jù)安全性傳輸，設計格式形如ID#Data#T#Sign(Hash(ID#Data#T))的數(shù)據(jù)封包。其中“#”表示數(shù)據(jù)連接符號，Data表示編號為ID數(shù)據(jù)采集裝置各個傳感器獲取的數(shù)據(jù)，T表示時間戳，Hash(ID#Data#T)表示對數(shù)據(jù)進行哈希運算，Sign(Hash(ID#Data#T))表示對哈希數(shù)據(jù)進行簽名。

4.2 信息處理模塊設計

數(shù)據(jù)采集裝置中的信息處理模塊用于將簽名模塊生成的簽名數(shù)據(jù)、傳感器數(shù)據(jù)Data、數(shù)據(jù)采集裝置編號ID和時間戳T組成上述的數(shù)據(jù)封包格式，并通過GPRS通信模塊向云服務器發(fā)送數(shù)據(jù)。云服務器中的信息處理模塊對收到的數(shù)據(jù)封包根據(jù)數(shù)據(jù)連接符“#”進行解析，獲取封包中的數(shù)據(jù)。

4.3 協(xié)議交互流程設計

圖2為協(xié)議中數(shù)據(jù)采集裝置(用戶)與云服務器(驗證者)進行交互的流程，包括以下步驟：

傳感器→信息處理模塊：數(shù)據(jù)采集裝置中的傳感器每隔一定時間收集到橋梁的位置、橋梁固有頻率、橋梁的應變壓力和周圍噪聲等數(shù)據(jù)Data，并將數(shù)據(jù)發(fā)送給信息處理模塊。

信息處理模塊→簽名模塊：信息處理模塊對數(shù)據(jù)采集裝置唯一編號ID、傳感器收集的數(shù)據(jù)Data和時間戳T進行哈希運算Hash(ID#Data#T)，將數(shù)據(jù)發(fā)送給簽名模塊。

簽名模塊→信息處理模塊：數(shù)據(jù)采集裝置中的簽名模塊獲取哈希數(shù)據(jù)后進行簽名Sign(Hash(ID#Data#T))。

數(shù)據(jù)采集裝置→云服務器：數(shù)據(jù)采集裝置的信息處理模塊接收簽名后，組成數(shù)據(jù)封包格式通過GPRS通信模塊向云服務器發(fā)送封包。

信息處理模塊→身份認證模塊：云服務器信息處理模塊接收數(shù)據(jù)封包對數(shù)據(jù)進行解析并將簽名數(shù)據(jù)發(fā)送給身份認證模塊。身份認證模塊進行簽名驗證

Verify(Sign(Hash(ID#Data#T))。如果簽名驗證失敗，則不接收數(shù)據(jù)，并將數(shù)據(jù)采集裝置的位置標記為預警狀態(tài)；否則，接收并保存數(shù)據(jù)。

圖2 協(xié)議交互圖

5 實驗與仿真

在Windows 7 64位操作系統(tǒng)下，使用微軟Visual Studio 2012開發(fā)平臺，用C語言實現(xiàn)了本文方案，方案的核心代碼如下：

//1)參數(shù)生成算法

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中可忽略參數(shù)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,可忽略其他參數(shù)

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("簽名數(shù)據(jù)S=%B ",S);

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

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

在同一環(huán)境下(CPU為Intel i3 4150，內(nèi)存為海力士Double-Data-Rate Three 8 GB，操作系統(tǒng)為Windows 7 64位操作系統(tǒng))對幾種經(jīng)典的簽名方案實現(xiàn)并多次運行進行耗時比較，結果如表2所示。由表2可知，本文方案運行平均總耗時約為0.152 s，其中簽名和簽名驗證所消耗的平均時間分別為0.056 s、0.035 s。本文方案在方案總耗時上與經(jīng)典方案Boneh[14]接近，但與Karati方案[17]相比，方案平均耗時減少了約13%，與Fangguo Zhang[20]方案相比，方案平均耗時減少了約6%，與Leyou Zhang[21]方案相比，方案平均耗時減少了約22%。

表2 各方案運行25次平均耗時比較

6 結語

本文針對現(xiàn)有的橋梁監(jiān)測系統(tǒng)和設計方案在信息交互過程中缺乏安全性認證和數(shù)據(jù)完整性保護的缺點，構造了一種基于身份的短簽名方案，并在此基礎上設計了安全的橋梁監(jiān)測數(shù)據(jù)交互協(xié)議。隨后，對簽名方案進行了安全性證明和實驗仿真，結果表明簽名方案計算量小，效率較高，可有效解決橋梁監(jiān)測數(shù)據(jù)的完整性保護和身份可靠性認證問題。在下一步研究工作中，考慮到對數(shù)據(jù)采集裝置的隱蔽性問題和本文方案的不足，具有用戶匿名性的安全雙因子認證方案[22-23]能適應高安全需求環(huán)境的用戶身份認證，因此可以考慮在客戶端設計上引入安全雙因子認證方案。