基于區塊鏈的物聯網大壩監測系統架構①

胡忠啟,趙 鋒,李雪強,閻 峻,江 帆

1(華東桐柏抽水蓄能發電有限責任公司,杭州 310003)

2(國網新源控股有限公司,北京 100761)

為了保水并幫助減輕洪水,通常,需要在暴雨之前、之中和之后測量水深以確保水壩的安全性,因此,不斷監測水庫中的水位和天氣狀況對降低洪水災害的危險至關重要[1].但由于大壩周圍環境的干擾,大壩監控設備布置稀疏等原因,導致大壩監測數據不可靠和不安全[2],因此制定一個可靠安全的大壩監控方案以確保數據的安全性和可靠性是十分有必要的.

近年來,云計算和物聯網[3,4]的發展催生了一套新的智能服務和應用程序,在這種情況下,云和物聯網在大壩監控中的結合使用將提供應對水挑戰的新方法.文獻[5]研究了水力發電廠結構大壩安全監控系統,該系統使用標準協議XMPP 在安裝在聽診儀器上的不同傳感器之間提供通信服務.文獻[6]描述了在特定的大壩安全管理系統中應用物聯網的可能性,定義了一個新的數據采集模塊,用于與監控網絡中的傳感器通信.文獻[7]為了減少了人工干預大壩結構的施工和運營成本,提出了智能水壩結構化系統,將物聯網、智能監控、云計算和控制技術智能地集成在一起,以在整個生命周期內實施實時,在線進行個人管理與分析,并對其性能進行控制.文獻[8]提出了一種新穎的集成信息系統,它結合了物聯網(IoT)、云計算、地理信息學以及電子科學用于環境監測和評估.文獻[9]基于物聯網和5G 無線網絡,利用傳感器數據構建尾礦壩多關鍵信息系統,包括潛水線,水庫水位,尾礦壩內部和外部變形等穩定性指標,應用云平臺基于實時監測數據預測潛水線的未來狀態.文獻[10]分析了當前我國水庫大壩安全管理存在的問題,并以F 大壩為例,探討了基于物聯網技術與云技術的大壩安全管理系統的具體建構.但以上這些工作沒有提供全球大壩監測解決方案,而且,它們非常昂貴,并且不提供可伸縮性和安全性.

本文提出了一種基于區塊鏈(BC)[11,12]技術并由傳感器云和無人機云組成的系統架構,包括:(1)一組傳感器小云,用于測量各種數據,例如天氣狀況,水質和水位以及大壩的結構狀態;(2)由無人機提供商控制的一組無人機小云,負責數據傳輸.BC 技術可以解決與數據偽造和重播有關的潛在安全威脅,保證數據完整性和數據不可偽造性.其中,傳感器云的使用可以帶來了許多益處,包括解決方案的普遍性,可伸縮性和可重用性.而且,小云可以服務于各種應用,例如,集成了一組用于測量氣候條件的傳感器的氣象站可以同時用于設計應用程序和其他解決方案,例如農業監測.而使用UAV 云進行數據傳輸,可以有效解決面積大而基礎設施較少、部署的傳感器形成遙遠且孤立的小云地區的數據傳輸問題.

1 系統架構

1.1 系統架構描述

本文設計的體系結構的目標是使DMC 能夠確保數據完整性,數據支付的可追溯性以及行為人的報酬.圖1為系統架構圖,圖2為系統流程圖.

圖1 系統架構

傳感器云[13]:由散布在該區域并提供各種數據的一組傳感器云組成.每個小云與控制和配置傳感器的WSN(氣象站)代理進行交互.每個小云均包含一組傳感器和一個固定的收集點(CP),具體包括:(1)一個或多個氣象站,這些氣象站安裝在農場的露天環境中;(2)一套水位和水質傳感器,用于測量物理和化學水參數;(3)一組用于監測大壩結構狀態的傳感器.其中,固定CP 具有更多的計算和通信資源.每個CP 執行:(1)從小云收集和聚合傳感器數據;(2)審計:它驗證是否從無人機提供商那里收到了發票中所有元組的付款.

無人機云:由一組無人機小云組成,并與無人機代理進行交互.無人機云可以通過添加更多無人機提供商來提供可伸縮性,并且可以為許多應用程序提供服務.每個小云均由提供商控制,并由一組基站(BS),一組維護中心和一組無人機(例如四旋翼飛機)組成.無人機從CP 收集數據并將其傳輸給提供商.無人機作用有:(1)接收和存儲請求:它從DMC 接收請求,然后將其存儲以供以后驗證;(2)選擇將要處理請求的無人機提供商;(3)發票的產生:它創建一個發票,其中包含與給定請求有關的錨定到BC 的元組列表,然后將其發送給DMC 以接收付款;(4)審計:它驗證是否收到發送給DMC 的元組列表的付款;(5)無人機供應商付款:從DMC 收到付款并核實無人機供應商的發票后,代理將繼續向提供商付款.無人機提供商:(1)選擇將請求服務的候選無人機;(2)無人機路徑規劃:它發出命令以調整無人機的飛行運動;(3)數據傳遞:它將無人機收集的數據(相關的大壩監測服務)傳遞給DMC 和BC;(4)審計:它驗證是否從無人機代理那里收到了發票中所包含的元組的付款;(5)付款:在收到代理的付款并核實從CP 收到的發票后,它開始向CP 支付.

大壩監控中心(DMC)負責:(1)請求發送和數據接收:它將數據收集請求發送到UAV 代理,并從UAV提供商接收收集的感測數據;(2)審計:它驗證是否收到了從無人機代理收到的發票中包含的所有元組;(3)向無人機代理付款:在驗證收到的發票,驗證數據并執行審計功能之后,DMC 繼續向無人機代理付款.

圖2 系統流程圖

1.2 系統要求

為了有效地在地面傳感器和DMC 之間傳輸數據,設計的方案必須得到數據保護并面向云,并且必須確保參與者的支付,具體需要滿足以下要求:

可擴展性:在大型且基礎設施較差的區域(例如水壩站點),通過采用云概念,可以通過增加設備數量或添加更多資源來確保擴展能力.傳感器云可以增加同一云中傳感器的數量,可以添加更多CP 或更多資源.此外,通過增加更多的UAV 提供商、UAV 和更多的資源也可提升擴展性,且這種增加不會影響請求處理和數據傳遞.

身份驗證:為了確保數據真實可靠且防止數據被篡改,DMC 需要對數據來源進行身份驗證,這可以通過按原點對數據對象進行簽名登記來完成.此外,為了確保請求來源是可信的,CP 需要驗證請求來源,這可以通過DMC,UAV 代理和UAV 提供商簽署請求來完成.

完整性:為了保護請求、數據和聲音的完整性,可以對數據進行簽名、哈希處理,然后將處理后的數據上傳到BC.數據完整性由塊挖掘過程中使用的共識機制(即永久證明)保證,通過定期向BC 網絡請求BC收據,DMC 可以隨時驗證數據完整性.請求的完整性和不可偽造性可以通過將數字附加到已簽名的請求中來提供,區塊鏈網絡區通過檢查發票中是否包含請求編號,驗證元組列表以及驗證是否已支付此請求來提供發票的完整性和不可偽造性.

跟蹤數據支付:本文所設計的系統中,無人機代理負責從DMC 接收請求,而無人機提供商則負責從CP收集數據并將其傳遞到DMC.若要保證系統的有效性,則要將無人機云完成的數據支付任務可靠地追溯到其來源,并應該跟蹤每個操作.UAV 代理應驗證與給定請求相關的數據是否已正確發送到DMC.UAV 提供商應跟蹤UAV 收集的數據是否來自真實的CP.CP 應驗證:(1)收集的數據是否已支付給無人機提供商;(2)這些數據是否已經很好地固定在了基站;(3)這些數據是否被發送到DMC.

付款:為保證支付的可靠性,付款僅在數據和發票驗證之后執行.例如,DMC 可以在驗證真實性,數據完整性,總請求持續時間和發票付款后,繼續向UAV 代理付款.付款金額取決于元組中包含的度量數量.為了支付這些實體,應使用支付系統,該系統應利用存儲在BC 中的數據.因此,支付系統應依賴于BC 技術,例如比特幣網絡.

2 區塊鏈技術

2.1 使用區塊鏈保護系統

本文將BC 技術用作響應系統要求的潛在解決方案,BC 可被視為分布式和公共分類帳,本文使用混合BC網絡[14],即使用公共比特幣BC 來支付操作,使用私有BC 來存儲數據并確保其完整性和可追溯性[15].

大壩和無人機提供商的結合起到共識節點的作用,要加入BC 網絡,實體應具有從證書頒發機構獲得的證書,且實體之間的所有交互都存儲在BC 中.對于數據事務,將從CP 收集的每個數據都視為一個對象,并由UAV 提供商將其散列和錨定到BC 網絡中.數據錨定帶來許多好處:(1)通過哈希函數和共識機制提供了數據完整性和防篡改功能;(2)數據以分布式方式永久存儲,以確保穩定性,可用性和彈性.(3)BC 使生成任何上載數據的收據成為可能.

UAV 提供商執行以下操作:(1)將散列數據發布到BC 網絡:將接收到的元組進行哈希處理,然后將處理后的數據發布到BC.BC 將為每個哈希元組提供一個標識,并將這些標識發送給UAV 提供商.上傳每個數據元組將有助于以后驗證數據完整性,并提供使UAV提供商的任務可追溯的指紋.(2)儲存BC 網絡給定的元組身份:從BC 網絡接收到元組的身份后,UAV 提供商會將其存儲在DMC、UAV 代理和CP 可以訪問的安全平臺中.平臺為每個請求號存儲元組的數量,它們的相應CP 以及從BC 網絡接收到的元組的標識.

CP 通過確保UAV 收集的每個元組是否已支付給其提供商和BC 來跟蹤UAV 提供商的支付任務.每個CP 將訪問UAV 提供商的平臺,以驗證元組號是否已更改,以及是否具有BC 給出的身份.

UAV 代理通過訪問由UAV 提供商創建的平臺來跟蹤UAV 提供商的支付任務,以提取與給定請求相關的元組,然后驗證每個元組是否具有來自BC 網絡的相應標識.

為了提供數據完整性保護和驗證,DMC 在從UAV提供商的平臺接收到元組的身份后,要求為每個元組提供BC 收據.通過將數據庫中計算的哈希值與生成的BC 收據中的目標哈希值進行比較,可以驗證每個元組.

2.2 區塊鏈上的數據操作

為了體現應用區塊鏈的大壩數據傳輸的安全性和可靠性,下面將詳細介紹數據如何在BC 上生成、傳輸和驗證.

(1)請求生成和傳遞

DMC 請求可以定期生成,也可以在事件發生時生成,請求時間可以根據實際水質進行調整.DMC 向UAV(無人機)代理發送一個請求,包括一個隨機請求號、請求的最大持續時間、安全時間戳和請求位置:

這個請求用DMC 的私鑰簽名并發送給UAV 代理:

其中,sigreqDMC=SS>KDMC(ReqDMC),S是簽名算法(非對稱加密),S KDMC是DMC 的私鑰.無人機代理通過驗證請求中包含的數字簽名來驗證DMC 的真實性,它驗證timeDMC是否包含在請求中,并將其與其時鐘時間進行比較.然后,無人機代理選擇一個候選的UAV 提供商并命令它處理這個請求:

其中,CertBr是它的證書,TimeBr是它的安全時間戳.發送給UAV 提供商的請求是:

其中,sigreqBr=SSKBr(ReqBr),S KBr是無人機代理的私鑰.提供商驗證無人機代理的真實性,它從網絡中選擇一架無人機,命令它飛越請求的位置.然后,提供商驗證TimeBr并將其與其時鐘時間進行比較,并通過添加它的時鐘時間和證書構建了下面的請求:

最后,提供商將請求發送到無人機:

其中,sigreqPr=SSKPr(ReqPr)是提供商的私鑰,UAV (無人機)驗證接收請求的真實性.

(2)數據報告

收到請求后,每個CP 都會注冊請求的最后時間戳,在驗證了UAV 提供商的真實性之后,它將匯總的數據發送到UAV,然后,UAV 使用DMC 的公鑰加密其數據.事實上,UAV是在登記階段發送給CPs 的,這個數據條目可以構造為一個元組,其中包含元組編號、加密數據(使用公鑰加密)、度量值的數目、請求編號、請求的最大持續時間、證書和安全時間戳:

然后用CP 的私鑰簽署每個元組:

其中,TupleCPisigned={TupleCPi,sigTupleCPi}.UAV 從CP接收所有元組,然后將它們轉發給UAV 提供商,UAV 提供商將構造一個連接元組塊Block=＜TupleCP1signed,···,TupleCPnsigned,Tuplequadsigned＞然后將其發送到DMC,其中Tuplequadsigned與無人機收集的數據相關.在每個接收到元組之后,DMC 向UAV 提供商發送確認(ACK).

(3)將數據發布到BC 網絡

在向DMC 發送數據之后,UAV 提供商散列元組,構造一個由連接的散列元組組成的塊

ACK 也是散列的,無人機提供商將元組和ACK都上傳到BC 中,因此散列元組和ACK 都將存儲在數據存儲中,這可以通過層級來實現,因為它提供了一個向BC 上傳和發布數據的平臺.執行中,每個元組都將被散列,然后與其他元組一起存儲在BC 網絡中的一個事務中,并最終轉換為默克爾樹節點,根節點將錨定在遵循Chainpoint 3.0 協議的BC 事務中,該協議為每個元組提供時間戳證明.每個被散列化的元組都有一個標識,用于檢索BC 收據(即驗證交易的證據),UAV提供商檢索哈希元組的身份,然后,提供商將哈希元組存儲在一個可由DMC 訪問的安全平臺上,以便進行完整性驗證,平臺為每個請求存儲:序列號、元組數、它們的CP 以及散列元組的標識,并由無人機代理和CPs對無人機供應商的支付任務進行驗證.

(4)由DMC 進行數據驗證

在每個接收到的元組塊之后,DMC 驗證安全時間戳,它計算請求支付的持續時間和數據報告的持續時間,然后計算總的請求持續時間,即延遲時間之和,并將其與最大持續時間進行比較.如果總請求持續時間超過最大持續時間,則DMC 不驗證接收到的數據,反之,DMC 驗證接收到的數據并訪問無人機供應商的安全平臺,以提取元組的身份.為了驗證每個元組,DMC向BC 發送一個請求并等待BC 收據,每個元組將通過比較計算得到的散列和生成的BC 收據中的目標哈希值來驗證.此外,DMC 必須驗證BC 收據的格式和內容,并且必須確認一個元組的摩爾根存儲在BC 中.

(5)發票的生成和驗證

發票生成:3 個參與者負責生成發票:①無人機代理:對于每個請求,它檢索所有相應的元組,生成發票,并將其發送給DMC,以便日后支付;②無人機供應商:它準備發票,并將其發送給無人機代理,以便日后支付;③CP:每個CP 生成發票,并將其發送給無人機供應商,以便日后支付.每張發票包含號碼、元組列表、寄件人的比特幣地址以及準確的BTC 值,支付的數量取決于度量值的數量和一個塊中包含的元組的數量,因此,可以將支付的數量計算為固定價格之和,以及塊中包含的所有元組的度量值數乘以每個單位數據的價格.

發票核對:3 個行為體(即DMC、UAV 代理和UAV 提供商)負責發票核對.在收到發票后,DMC 驗證發票中的元組列表和數據庫中為給定請求存儲的元組列表,UAV 代理通過比較包含在發票中的元組和從BC 檢索到的元組來驗證每個發票,以及UAV 提供商通過比較包含在發票中的元組和存儲在其平臺中的元組來驗證每個發票.

(6)付款

發票確認后,付款人將開始付款.比特幣是一種加密貨幣系統,吸引了大量感興趣的用戶,為了在收款人和付款人之間進行比特幣轉賬,雙方都必須有錢包.本文使用BIP3 支付協議,它代表了商家和客戶之間的通信協議.

在驗證請求持續時間,每個收到的元組和每個收到的BC 收據確認之后,DMC 繼續支付UAV 代理的款項.UAV 代理在收到DMC 的付款后就向無人機提供商支付任務的費用.無人機供應商在收到無人機代理的付款后,向CPs 支付傳感任務的費用.支付是通過比特幣交易實現的,每個支付人在執行付款并從收款人收到應收款項后,在BC 網絡中登記給定請求的最后一次付款時間,以避免為同一請求號碼支付兩次付款.

(7)攻擊檢測

本文設計的系統偵測到的可能攻擊包括:

①數據和請求偽造:無人機供應商可能通過注入非法數據和準備未經授權的付款來偽造數據,這可通過BC 網絡檢測到.執行中,UAV 提供商可以偽造數據,而不是發送UAV 收集的數據,但由于本文設計通過證書和數字簽名的驗證對數據進行了身份驗證,因此不會發生這種攻擊.此外,由UAV 代理實現的請求偽造可以被CP 檢測到,因為每個請求必須包含DMC的請求號和安全時間戳,因此數據的真實性可以得到很好的保證.

②數據和請求回放:CP 可能會嘗試向候選無人機發送舊數據.本設計中,DMC 可以通過每個元組中包含的時間戳和請求號來驗證數據,同時由于元組存儲在BC 網絡中,因此,DMC 可以檢測到這些舊數據已經存在于BC 網絡中.此外,由于CP 注冊了每個請求的最后時間戳,因此可以檢測到請求回放.

③偽造發票:這種攻擊可通過接收不是真實來源產生的發票來實現.這可由發票接收者檢測到,3 個發票接收者(DMC、UAV 代理和UAV 提供商)接受到發票信息后,通過比較核對來排除偽造的發票.此外,發票和請求號碼存儲在接收方的數據庫中,以便于進行發票驗證.另外,即使DMC 沒有接收數據,CPs 也可以生成發票,UAV 提供商在從DMC 為每個接收到的元組接收ACK 時檢測到這種攻擊,因此,CP 只有在接收到ACK 之后才支付.

④雙重付款:可以通過收到相同的發票,從而為相同的請求號碼支付兩次.這可由支付者檢測到,因為每個發票包含發票和請求號碼.此外,對于每個請求,付款人在BC 網絡中登記最后一次付款時間,因此,付款人可以隨時核實發票上的要求編號是否已經付款.

⑤拒絕支付:例如,即使在收到發票后,DMC 也可以拒絕支付給無人機代理.這可通過在接收到每個元組之后,DMC 向UAV 提供商發送一個ACK 檢測到,發送的ACK 與元組一起上傳到BC 網絡中,因此,DMC 不能拒絕付款.

3 仿真結果與分析

3.1 系統工作性能分析

在這一部分,本文旨在分析所提出的工作的性能.本文考慮了邊長長度為L=1.5 km 的正方形監測區,并將整個區域劃分為邊長長度為l=0.5 km 的正方形分區網格,在每個傳感器采集數據的子區域中心都有一個CP.

假設所有的無人機都遵循同樣的軌跡.在接收到無人機供應商的請求后,候選無人機會檢查一組CP,然后將收集到的數據轉發給無人機供應商.假定無人機對指揮中心的重訪時間為常數,模擬中使用的參數總結在表1中.

表1 參數設置

為了所提出的模型,本文計算數據傳遞延遲比率,并在對應于數據交互生成時間的每個時隙上,利用均勻隨機分布來設置事件發生概率(警報生成),警報的大小定義為:

其中,Lpay是傳感器數據包有效載荷的長度,LH是CP的聚合包的頭的長度;Nbalerts是警報的數量.

支付延遲等于:

其中,TCr=(L2?l2)/(l×SCr)是行駛的總距離,除以巡航速度是爬升和下降的總數乘以爬升和下降所花費的時間(TCCl),TPr&trBS→DMC是處理收集的數據所需的時間和從BS 到DMC 的傳輸時間的總和,它等于BC 網絡的處理時間,并假設為是常數,TW是從傳感器產生數據到無人機到達的等待時間,TCol=S izealerts/Ratereception是UAV 從所有CP 收集聚合包所需的時間,TtrtoBS=S izealerts/Ratetransmisson是UAV 從CP 向BS 傳輸數據所需的時間.

支付延遲率定義為:

其中,Tflight=TCr+TCl&Des為無人機巡航、爬升、下降所花費的時間.

本文所提出系統的工作性能仿真結果如圖3,本文針對事件發生概率從0.1 到0.8 的變化模擬了支付延遲比率,從圖中可看出延遲比隨著生成事件概率的增加而增加.因為,當增加事件概率時,生成警報的機會就會增加,因此數據大小也會增加.因此,收集時間和傳輸到BS 的時間都增加了.同時還可觀察到,由于警報數量的大量增加,延遲比首先迅速增加(在概率值0.1 和0.2 之間),然后由于警報數量的緩慢增加而緩慢增加.

圖3 支付延遲率與事件發生的概率之比

圖4針對從120 s 到360 s 的重新訪問時間評估了數據傳遞延遲比.從圖中可以觀察到,隨著重訪時間的增加,支付延遲率會隨之增加.因為增加的重訪時間越多,數據大小的增加就越大,因此收集時間和到BS 的傳輸時間都會增加.而且,傳感器的等待時間也會隨著重訪時間的增加而增加.

圖4 支付延遲率與回訪時間之比

圖5中模擬了警報生成的時間相對于支付延遲率的變化,從20 s 到60 s 不等.從圖中可以觀察到,延遲比率隨著警報間隔時間的增加而減小.因為增加警報生成的時間越多,生成的數據就越少,傳遞延遲也就越少.同時還可觀察到,由于警報數量的大量減少,支付延遲比率首先迅速降低(在20 s 和30 s 之間),然后由于警報數量的緩慢減少而緩慢下降.

3.2 系統優勢比較

下面為了體現本文設計系統的優勢,將本文中的基于區塊鏈的物聯網大壩監測系統與普通的未應用區塊鏈的大壩監測系統進行比較.

為了體現系統的安全性和可靠性,本文從支付成果率著手分析比較.定義支付成功率為:

圖5 支付延遲率與警報內部計算時間之比

若CP 收到的支付次數等于CP 發出的支付次數,則意味著CP 每發出一次數據,都得到了相應的付款,數據在傳遞過程中處于安全狀態.若CP 收到的支付次數大于CP 發出的支付次數,則意味著在數據傳輸過程中存在著虛假支付、數據被盜取的問題.圖6為支付次數為1000 次(包括虛假支付次數)時的支付成功率比較圖.

圖6 支付成功率圖

從圖6可以看出,在支付次數為1000 次時,隨著虛假支付次數的增多,普通的未應用區塊鏈的大壩監測系統的支付成功率不斷降低,因為其沒有確保數據安全的審計與驗證.而本系統的支付成功率一直維持在0.9 左右,因為雖然虛假支付次數增加了,但是因為經過多層的審計與驗證,可以排除虛假支付,從而提高支付成功率.

4 結束語

本文提出了一種基于區塊鏈的由傳感器云和無人機云組成的系統架構,以用于監控大壩和確保數據的安全性與可靠性.其中,一組傳感器小云可提供各種數據,例如天氣狀況,水質和水位以及大壩的結構狀態,UAV 云可從傳感器收集數據以及將數據傳遞到DMC,而BC 技術確保了分布式的長期安全性,該技術提供了身份驗證,數據存儲和完整性以及UAV 云數據支付的可追溯性,有效的保證了大壩監測數據來源的可靠性,數據傳輸的安全性以及預防潛在的數據攻擊.最后本文通過評估數據傳遞延遲率來評估工作績效,仿真結果表明,所設計系統的延遲率所設計系統的延遲率與生成事件概率、重訪時間成正相關,與警報間隔時間成負相關,且具有更高的支付成功率.