韓妍妍，張 齊，閆曉璇，劉培鶴，徐鵬格

（1.北京電子科技學(xué)院電子與通信工程系，北京 100070；2.西安電子科技大學(xué)通信工程學(xué)院，西安 710071）

（?通信作者電子郵箱zq_nulinuli@163.com）

0 引言

電子文件是指在機(jī)關(guān)、團(tuán)體、企事業(yè)單位和其他組織在處理公務(wù)過(guò)程中，通過(guò)計(jì)算機(jī)等電子設(shè)備形成、辦理、傳輸和存儲(chǔ)的文字、圖表、音頻、視頻等不同形式的信息記錄［1］。電子文件直到20世紀(jì)80年代末開始應(yīng)用于政府機(jī)關(guān)及企業(yè)，并逐步取代傳統(tǒng)的紙質(zhì)文件，隨之產(chǎn)生了電子文件管理系統(tǒng)和電子文件流轉(zhuǎn)系統(tǒng)。隨著新時(shí)代網(wǎng)絡(luò)安全問(wèn)題的突出，電子文件與各類信息安全緊密聯(lián)系，文件流轉(zhuǎn)直接關(guān)系到行政管理效率以及數(shù)字資產(chǎn)的流通安全，因此國(guó)內(nèi)外政府高度重視電子文件流轉(zhuǎn)系統(tǒng)創(chuàng)新，將其列為數(shù)字城市的重要內(nèi)容。而企業(yè)和學(xué)術(shù)界也積極響應(yīng)政府號(hào)召，研究和申請(qǐng)電子文件的相關(guān)專利［2-3］。

文件的可靠性和流轉(zhuǎn)過(guò)程的安全性［3］是巨大的短板，如電子文件流轉(zhuǎn)過(guò)程應(yīng)用節(jié)點(diǎn)多、程序覆蓋廣、數(shù)據(jù)傳輸量較大，純粹的中心化服務(wù)器架構(gòu)會(huì)產(chǎn)生巨大基礎(chǔ)設(shè)施建設(shè)成本和后臺(tái)維護(hù)成本，因此在大應(yīng)用量的前提下如何保證電子文件沒有遭到惡意篡改，且在不暴露內(nèi)容的情況下證明內(nèi)容完整可靠是一大難題；另一方面，傳統(tǒng)的電子文件流轉(zhuǎn)過(guò)程采用的是中心化模式，其應(yīng)用的前提是用戶基于信任原則選擇該應(yīng)用進(jìn)行文件傳輸，但實(shí)際應(yīng)用中攻擊者可以利用應(yīng)用程序漏洞偽造身份進(jìn)行非法訪問(wèn)，抹除系統(tǒng)的訪問(wèn)記錄，獲得文件閱讀權(quán)下載權(quán)，從而導(dǎo)致文件和秘密的泄露［4］；再者，在電子文件流轉(zhuǎn)過(guò)程中，傳統(tǒng)方式是采用數(shù)據(jù)庫(kù)對(duì)文件進(jìn)行存放，面對(duì)如今大規(guī)模的文件傳輸量，需要有既滿足安全性又能擺脫傳統(tǒng)數(shù)據(jù)庫(kù)限制的文件中轉(zhuǎn)存放平臺(tái)。在電子文件的發(fā)展前景中，如何解決電子文件流轉(zhuǎn)過(guò)程中的可靠性和安全性，使文件內(nèi)容不被輕易竊取、篡改，文件流轉(zhuǎn)過(guò)程日志清晰、透明是電子文件應(yīng)用領(lǐng)域和電子文件流轉(zhuǎn)亟須解決的問(wèn)題［5］。

對(duì)于以上電子公文流轉(zhuǎn)系統(tǒng)中存在的問(wèn)題，去中心化是一個(gè)解決現(xiàn)有問(wèn)題的有效選擇，近年來(lái)區(qū)塊鏈技術(shù)成為了學(xué)術(shù)界的研究熱點(diǎn)［6-7］，同時(shí)也在金融業(yè)、服務(wù)業(yè)、IT 界、政府管理等領(lǐng)域具有極高的應(yīng)用價(jià)值。本文利用區(qū)塊鏈技術(shù)的安全性、不可逆、防篡改、可追溯特性，借助云存儲(chǔ)［8-9］平臺(tái)進(jìn)行電子文件存放，提出一種基于區(qū)塊鏈［10-11］的電子文件流轉(zhuǎn)系統(tǒng)，通過(guò)將文件所有權(quán)轉(zhuǎn)換數(shù)據(jù)加蓋時(shí)間戳，使流轉(zhuǎn)過(guò)程連續(xù)、關(guān)聯(lián)、可追溯且誠(chéng)實(shí)可信，大幅提升電子文件流轉(zhuǎn)過(guò)程透明度和可信度，同時(shí)實(shí)現(xiàn)文件流轉(zhuǎn)溯源，實(shí)現(xiàn)防篡改日志功能［12］。

1 設(shè)計(jì)目標(biāo)與系統(tǒng)架構(gòu)

系統(tǒng)由區(qū)塊鏈數(shù)據(jù)保護(hù)、云平臺(tái)文件存儲(chǔ)和節(jié)點(diǎn)管理監(jiān)控三大部分組成：區(qū)塊鏈用于實(shí)現(xiàn)區(qū)塊鏈數(shù)據(jù)記錄、溯源功能；云平臺(tái)文件存儲(chǔ)用于文件中轉(zhuǎn)和存放；節(jié)點(diǎn)管理監(jiān)控保證聯(lián)盟鏈中節(jié)點(diǎn)的添加和正常運(yùn)轉(zhuǎn)。三部分進(jìn)行協(xié)調(diào)工作，共同實(shí)現(xiàn)系統(tǒng)功能。

1.1 設(shè)計(jì)目標(biāo)

1）文件流轉(zhuǎn)的安全性。電子文件在流轉(zhuǎn)過(guò)程中內(nèi)容容錯(cuò)。此外，文件所有權(quán)只有經(jīng)用戶簽名及礦工驗(yàn)證后才能更改。

2）系統(tǒng)可信性。系統(tǒng)應(yīng)具有抵御偽造區(qū)塊攻擊能力，從而保證區(qū)塊鏈所記錄數(shù)據(jù)的真實(shí)性。當(dāng)文件所有權(quán)存在爭(zhēng)議時(shí)可將賬本作為解決糾紛的依據(jù)。

3）系統(tǒng)擴(kuò)展性。利用云平臺(tái)完成文件存儲(chǔ)，應(yīng)考慮到后續(xù)系統(tǒng)維護(hù)和拓展使用，通過(guò)擴(kuò)充云平臺(tái)功能增加系統(tǒng)新功能和新需求，從而適應(yīng)更復(fù)雜的系統(tǒng)要求。

4）系統(tǒng)高效性。底層區(qū)塊鏈中數(shù)據(jù)的存儲(chǔ)需要通過(guò)認(rèn)證節(jié)點(diǎn)確認(rèn)交易并打包成區(qū)塊后才能完成［13］，此時(shí)存在數(shù)據(jù)效率低下問(wèn)題，需要進(jìn)行優(yōu)化解決。

1.2 技術(shù)架構(gòu)

本文電子文件流轉(zhuǎn)方案的技術(shù)架構(gòu)如圖1 所示，系統(tǒng)分為三部分：用戶、云端和授權(quán)節(jié)點(diǎn)。

客戶端 用戶在系統(tǒng)中通過(guò)用戶ID完成身份記錄并進(jìn)行驗(yàn)證，依據(jù)ID可獲取系統(tǒng)中唯一身份標(biāo)識(shí)的公私鑰對(duì)，實(shí)現(xiàn)用戶的登錄操作。當(dāng)用戶連接客戶端后，用戶關(guān)于文件的上傳、下載和所有權(quán)交易均通過(guò)客戶端進(jìn)行操作，交易如圖2所示。

用戶對(duì)文件進(jìn)行交易時(shí)，首先在客戶端上進(jìn)行文件的上傳，文件存儲(chǔ)在云端后即在底層區(qū)塊鏈獲得該文件的所有權(quán)記錄。用戶通過(guò)客戶端，在區(qū)塊鏈操作交易數(shù)據(jù)TX，區(qū)塊鏈網(wǎng)絡(luò)調(diào)用協(xié)議接口將交易數(shù)據(jù)發(fā)送到電子文件流轉(zhuǎn)區(qū)塊鏈網(wǎng)絡(luò)中，新區(qū)塊鏈NB 入鏈時(shí)交易即生效。用戶可以通過(guò)調(diào)用智能合約S 控制云端C，實(shí)現(xiàn)電子文件所有權(quán)的轉(zhuǎn)讓、權(quán)限賦予或查詢功能。

圖1 電子文件流轉(zhuǎn)示意圖Fig.1 Schematic diagram of electronic file circulation

圖2 客戶端用戶文件所有權(quán)交易流程Fig.2 Transaction process of client-side user file ownership

授權(quán)節(jié)點(diǎn) 即礦工，主要負(fù)責(zé)驗(yàn)證和打包電子文件流轉(zhuǎn)交易。系統(tǒng)需預(yù)先指定一定數(shù)目的節(jié)點(diǎn)為記賬人，每個(gè)區(qū)塊的生成由需要授權(quán)節(jié)點(diǎn)經(jīng)共識(shí)機(jī)制進(jìn)行認(rèn)證方可鏈入，其他接入節(jié)點(diǎn)可以參與交易，但不過(guò)問(wèn)記賬過(guò)程和區(qū)塊認(rèn)證，當(dāng)需要進(jìn)行交易數(shù)據(jù)查詢時(shí)，第三方可以對(duì)區(qū)塊鏈中交易信息限定查詢。當(dāng)系統(tǒng)中有用戶發(fā)起文件流轉(zhuǎn)交易時(shí)，授權(quán)節(jié)點(diǎn)將交易請(qǐng)求數(shù)據(jù)通過(guò)電子文件流轉(zhuǎn)區(qū)塊鏈共識(shí)機(jī)制，經(jīng)本地運(yùn)算產(chǎn)生的新區(qū)塊，會(huì)廣播到每個(gè)節(jié)點(diǎn)，當(dāng)超過(guò)半數(shù)授權(quán)節(jié)點(diǎn)確認(rèn)了該區(qū)塊的有效性后和合法性后，此次的交易才會(huì)被寫入?yún)^(qū)塊鏈存儲(chǔ)，通過(guò)記錄父塊哈希鏈接到區(qū)塊鏈上，如圖3 所示。該過(guò)程中智能合約是提前部署于區(qū)塊鏈上的自動(dòng)執(zhí)行代碼，通過(guò)自動(dòng)觸發(fā)執(zhí)行，可以滿足不受干預(yù)地進(jìn)行電子文件的轉(zhuǎn)讓、權(quán)限賦予或查詢等操作，保障電子文件所有權(quán)的權(quán)威性。

圖3 電子文件區(qū)塊生成與鏈接Fig.3 Generation and link of electronic file blocks

云端 完成文件的存放與流轉(zhuǎn)，如圖4所示。

當(dāng)用戶A 在登錄客戶端后將文件上傳至云端時(shí)，用戶會(huì)同時(shí)將文件F的哈希值以及對(duì)文件哈希值的數(shù)字簽名發(fā)送至云端進(jìn)行確認(rèn)。上傳內(nèi)容①中包含的內(nèi)容為：

其中：Hash(F)為文件F 的哈希值，Sig(Hash(F))為該哈希值的數(shù)字簽名，GA為用戶A 的公鑰。云端先進(jìn)行文件哈希值及用戶A 的簽名的驗(yàn)證，通過(guò)驗(yàn)證后向用戶A 返回文件所屬的唯一憑證以及對(duì)此關(guān)于云端的數(shù)字簽名。返回憑證②中包含的內(nèi)容為：

其中：I 為文件所屬憑證，GC為云端的公鑰。用戶A 以簽名驗(yàn)證的方式對(duì)接收到的信息進(jìn)行文件流轉(zhuǎn)操作。文件流轉(zhuǎn)操作首先進(jìn)行但是文件所有權(quán)的轉(zhuǎn)移，隨著所有權(quán)的變化，憑證I也會(huì)同時(shí)發(fā)生變化，云端文件只有擁有憑證I 的人才能進(jìn)行下載。在云端中進(jìn)行文件的轉(zhuǎn)存一方面提高了文件流轉(zhuǎn)效率，同時(shí)能夠有效防止流轉(zhuǎn)過(guò)程中重要電子文件的隨意瀏覽。

圖4 云存儲(chǔ)文件所有權(quán)流轉(zhuǎn)過(guò)程Fig.4 Process of cloud storage file ownership transfer

1.3 智能合約設(shè)計(jì)與執(zhí)行

智能合約［14］在該方案中作為邏輯層，本文對(duì)智能合約的結(jié)構(gòu)及執(zhí)行流程進(jìn)行了針對(duì)性設(shè)計(jì)，如圖5所示。

圖5 電子文件所有權(quán)流轉(zhuǎn)合約結(jié)構(gòu)Fig.5 Contract structure for circulation of ownership transfer of electronic files

文件流轉(zhuǎn)合約的索引部分主要由合約編號(hào)Num(S)、所在區(qū)塊鏈編號(hào)Num(block)及合約內(nèi)容的哈希值Hash(S)組成，有利于挖礦節(jié)點(diǎn)對(duì)交易信息中的關(guān)聯(lián)合約進(jìn)行追蹤和執(zhí)行。

節(jié)點(diǎn)A向B進(jìn)行文件F的流轉(zhuǎn)交易，并且此交易入鏈生效后，挖礦節(jié)點(diǎn)D追蹤到交易所屬的智能合約，并根據(jù)合約自動(dòng)執(zhí)行以下步驟：

1）驗(yàn)證交易所屬文件F 的標(biāo)識(shí)與哈希值是否和合約中一致。

2）驗(yàn)證交易發(fā)起方的公鑰是否是合約中的當(dāng)前用戶。

3）驗(yàn)證交易信息中發(fā)起方的數(shù)字簽名。

4）驗(yàn)證交易接收方是否屬于合約中的用戶集。

5）若以上步驟均通過(guò)驗(yàn)證，則挖礦節(jié)點(diǎn)D 向云端C 發(fā)出文件所有權(quán)變更的指示。內(nèi)容如下：

云端C 在收到指示后，通過(guò)找到文件F 后核對(duì)哈希值，一致后再驗(yàn)證節(jié)點(diǎn)D的數(shù)字簽名，通過(guò)即認(rèn)為此指示有效。

通過(guò)調(diào)用部署在電子文件流轉(zhuǎn)區(qū)塊鏈上的智能合約，將自己的文件所有權(quán)轉(zhuǎn)移給接收者，寫入新的區(qū)塊并鏈接到區(qū)塊鏈上。由于區(qū)塊鏈本身具有不可篡改的特性，每一筆交易中都包含相應(yīng)的時(shí)間戳和文件的特征值，因此能防止文件被惡意篡改和刪除。

1.4 電子文件所有權(quán)交易流程

具體流程如下：

1）發(fā)起交易。電子文件流轉(zhuǎn)區(qū)塊鏈網(wǎng)絡(luò)中的客戶端發(fā)起的交易TX，主要結(jié)構(gòu)如圖6所示。

圖6 文件所有權(quán)交易結(jié)構(gòu)Fig.6 Transaction framework of file ownership

交易信息主要包括兩種：一種是在特定的條件下進(jìn)行部署的智能合約S；另一種是通過(guò)已部署合約產(chǎn)生的消息調(diào)用M。若用戶發(fā)起交易T 時(shí)交易的接收方賬戶地址為空，交易類型為部署一份新的合約S；若交易T的接收方賬戶地址不為空，此時(shí)交易類型為調(diào)用已部署的智能合約進(jìn)行交易，其中T調(diào)用的M中包括交易接收方的賬戶地址、合約接口等數(shù)據(jù)。

2）創(chuàng)建區(qū)塊。電子文件流轉(zhuǎn)區(qū)塊鏈中礦工創(chuàng)建區(qū)塊的過(guò)程為：授權(quán)節(jié)點(diǎn)同步區(qū)塊鏈并對(duì)交易池中的未確認(rèn)交易進(jìn)行收集和驗(yàn)證，主要驗(yàn)證該文件所有人的交易簽名合法性及賬戶合法性。然后授權(quán)節(jié)點(diǎn)采用工作量證明機(jī)制（Proof-of-Work，PoW）對(duì)區(qū)塊進(jìn)行打包，即將Bp的區(qū)塊頭、隨機(jī)數(shù)值、確認(rèn)交易的哈希值通過(guò)哈希算法后得到的哈希值小于Bp 中所設(shè)定的挖礦目標(biāo)Target，則節(jié)點(diǎn)成功創(chuàng)建出該電子文件流轉(zhuǎn)區(qū)塊B。最后，授權(quán)節(jié)點(diǎn)向全網(wǎng)記賬節(jié)點(diǎn)廣播創(chuàng)建成功的電子文件流轉(zhuǎn)區(qū)塊，其余的記賬節(jié)點(diǎn)會(huì)對(duì)該區(qū)塊進(jìn)行驗(yàn)證，判斷其交易是否具備合法性，從而開始新一輪的記賬權(quán)競(jìng)爭(zhēng)。底層區(qū)塊鏈中文件所有權(quán)信息入鏈后，自動(dòng)觸發(fā)文件流轉(zhuǎn)的智能合約，進(jìn)行云端文件所有權(quán)變更。

3）云端文件所有權(quán)變更。云端變更文件F的具體流程如圖7所示。

圖7 云端文件所有權(quán)變更流程Fig.7 File ownership transfer process on cloud platform

由于方案基于聯(lián)盟鏈進(jìn)行設(shè)計(jì)，所以挖礦節(jié)點(diǎn)負(fù)責(zé)執(zhí)行智能合約，當(dāng)新區(qū)塊生成時(shí)，每個(gè)挖礦節(jié)點(diǎn)D對(duì)區(qū)塊中的交易TX 所對(duì)應(yīng)的智能合約S 進(jìn)行驗(yàn)證。驗(yàn)證通過(guò)后自動(dòng)執(zhí)行合約，將所有權(quán)變更指示發(fā)送至云端C，云端在收到超過(guò)50%的挖礦節(jié)點(diǎn)發(fā)送的同一文件F 的相同變更指示后，將文件F 的所有權(quán)變更為本次交易的接收方。至此，文件所有權(quán)變更結(jié)束，交易接收方可通過(guò)交易發(fā)起方給予的文件憑證I 登錄云端，下載相應(yīng)文件F，文件流轉(zhuǎn)流程結(jié)束。

2 系統(tǒng)實(shí)現(xiàn)

2.1 系統(tǒng)開發(fā)環(huán)境

本系統(tǒng)基于Windows 環(huán)境進(jìn)行開發(fā)，前后端均采用Java語(yǔ)言進(jìn)行實(shí)現(xiàn)，在MyEclipse 平臺(tái)進(jìn)行系統(tǒng)開發(fā)，數(shù)據(jù)庫(kù)使用MySQL，利用SQLyog 進(jìn)行數(shù)據(jù)庫(kù)界面化管理，系統(tǒng)界面使用HTML進(jìn)行實(shí)現(xiàn)。

2.2 文件上傳功能實(shí)現(xiàn)

2.2.1 用戶登錄連接

在本系統(tǒng)中用戶登錄是通過(guò)端口連接實(shí)現(xiàn)客戶端連接的，連接成功后加入系統(tǒng)的每一個(gè)用戶設(shè)置用戶ID 作為登錄密碼，該ID 是用戶生成公私鑰的基本依據(jù)。系統(tǒng)中會(huì)將用戶ID 通過(guò)算法計(jì)算生成合法的用戶公鑰地址，公鑰地址是用戶在本系統(tǒng)中唯一的身份標(biāo)識(shí)，成為區(qū)塊鏈賬戶后才正式完成系統(tǒng)登錄，可以對(duì)系統(tǒng)應(yīng)用進(jìn)行訪問(wèn)。登錄過(guò)程中會(huì)對(duì)用戶的資料進(jìn)行統(tǒng)一驗(yàn)證管理。

1）用戶連接客戶端。

輸入要連接的IP 地址和連入的端口，通過(guò)ClientStart 類中的Socket（ip，port）方法根據(jù)IP 和端口進(jìn)行socket 連接，連接成功即完成與服務(wù)器的連接，并使用Receive 類中g(shù)etInputStream（）與getOutputStream（）方法打開I/O 流，接收客戶端發(fā)送的數(shù)據(jù)及向其發(fā)送信息。

2）公私鑰獲取。

①處理用戶ID。使用getText（）.trim（）方法從用戶端界面接收到用戶輸入的ID，轉(zhuǎn)為字符串形式后先進(jìn)行SM2、SM3參數(shù)準(zhǔn)備，由于SM2、SM3函數(shù)的相關(guān)運(yùn)算均基于字節(jié)型字符串，因此用戶端通過(guò)使用Base58.decodeBase58（id）方法將用戶ID 轉(zhuǎn)化為Base58 編碼形式，以字節(jié)型數(shù)組存儲(chǔ)，從而進(jìn)行下一步加密處理。

②獲取私鑰。調(diào)用SM3 函數(shù)中的getHashBytes（）方法將Base58 編碼方式的ID 字節(jié)型數(shù)組進(jìn)行SM3 哈希運(yùn)算，所得256 位字節(jié)型數(shù)組結(jié)果通過(guò)Base58.encodeBase58（）方法進(jìn)行填充、分塊、迭代壓縮，得到的32 字節(jié)字符串即為用戶獲取的私鑰地址。

③獲取公鑰。經(jīng)SM3 運(yùn)算得到的私鑰通過(guò)SM2 函數(shù)的generatePubkeyFromPrikey（）方法將私鑰與SM2 算法的基點(diǎn)進(jìn)行橢圓曲線的倍點(diǎn)運(yùn)算，得到密鑰對(duì)，其中公鑰使用gmcuser.formatPublicKey（）方法以［x‖y］形式存儲(chǔ)為字節(jié)型數(shù)組，共有64字節(jié)數(shù)據(jù)，以供SM2算法的簽名運(yùn)算。用戶ID 獲取公私鑰對(duì)如圖8所示。

圖8 輸入用戶ID獲取公私鑰對(duì)Fig.8 Input user ID to obtain public-private key pair

3）交易地址獲取。

考慮到64 字節(jié)數(shù)據(jù)量的公鑰較為占用空間，且用戶難以直接使用位數(shù)較多的地址進(jìn)行交易的情況，用戶在使用SM2算法產(chǎn)生公私鑰對(duì)后，將公鑰進(jìn)行兩次SM3運(yùn)算，并取結(jié)果的前16 字節(jié)處理生成位數(shù)較短的節(jié)點(diǎn)交易地址，便于用戶間進(jìn)行交易。地址生成后，將16 字節(jié)數(shù)據(jù)通過(guò)Base58.encodeBase58Check（）方法轉(zhuǎn)化為Base58 編碼形式字符串并輸出，用戶作為交易接收方時(shí)，將此作為交易輸出地址發(fā)送至交易發(fā)起方以生成交易信息。

2.2.2 電子文件上傳和登記

文件上傳由客戶端發(fā)起，用戶需要形成文件哈希作為文件標(biāo)記，用于云端存放時(shí)的標(biāo)識(shí)。云端接收后，需要在本地進(jìn)行哈希運(yùn)算，且結(jié)果需要同用戶的哈希值一致。

1）打開本地文件并上傳。獲取電子文件本地地址如圖9所示，打開本地文件并通過(guò)getSelectedFile（）選擇上傳文件，使用file.getAbsolutePath（）方法獲取絕對(duì)路徑，以字符串形式導(dǎo)出文件地址后發(fā)起上傳。

圖9 獲取電子文件本地地址Fig.9 Obtaining local address of electronic file

2）文件上傳。上傳的地址作為用戶節(jié)點(diǎn)交易地址，系統(tǒng)按照給定路徑在本地需找上傳文件。通過(guò)對(duì)文件數(shù)據(jù)內(nèi)容以字節(jié)的形式進(jìn)行讀取操作，獲取文件內(nèi)容后將內(nèi)容轉(zhuǎn)為GBK編碼形式。文件內(nèi)容編碼后經(jīng)SM3 運(yùn)算生成文件哈希值，作為該文件的完整性標(biāo)識(shí)。文件上傳時(shí)需以固定數(shù)據(jù)格式消息集通過(guò)socket 連接發(fā)送至云端。根據(jù)信息格式，將上傳文件｛S3=（"1，"+wenjianming+"，"+Hash+"，"+Address+"，"+AlartTxt1）｝數(shù)據(jù)包的形式傳至云端，實(shí)現(xiàn)文件內(nèi)容存儲(chǔ)和索引記錄，其中：wenjianming 是上傳文件名稱，Hash 指文件經(jīng)SM3 算法生成的數(shù)字摘要，用于防止文件上傳過(guò)程中發(fā)生內(nèi)容篡改；Address 是上傳方節(jié)點(diǎn)地址，作為文件發(fā)送方證明；AlartTxt1指文件的十六進(jìn)制字符串內(nèi)容。

云端接收到數(shù)據(jù)包后將信息以“，”分割為字符串?dāng)?shù)組，將文件名，所有人及哈希存入云端文件索引數(shù)據(jù)庫(kù)，十六位文件內(nèi)容的字符串內(nèi)容則轉(zhuǎn)換為GBK 編碼形式的文件存于云端文件存儲(chǔ)區(qū)，至此完成文件的存儲(chǔ)和索引生成。此時(shí)云端會(huì)向用戶返回存儲(chǔ)成功的反饋，告知用戶端文件成功上傳。

2.3 文件所有權(quán)和流轉(zhuǎn)溯源查詢

2.3.1 文件所有權(quán)交易

電子文件交易合約是主要節(jié)點(diǎn)提前嵌套至系統(tǒng)中的執(zhí)行程序，當(dāng)交易信息滿足條件時(shí)自動(dòng)執(zhí)行。合約內(nèi)容必須按照固定格式存儲(chǔ)于區(qū)塊鏈中，格式如圖10所示。

圖10 文件所有權(quán)交易合約信息Fig.10 Contract information of file ownership transaction

用戶在客戶端輸入users 用戶集合發(fā)起合約上傳，用戶集中包含所有需要文件流轉(zhuǎn)的地址集。客戶端將文件名Name、文件Hash、users 打包為消息M，使用用戶私鑰對(duì)消息M 進(jìn)行SM2 簽名運(yùn)算，以固定格式的數(shù)據(jù)包發(fā)送至主要節(jié)點(diǎn)。格式與云端消息類似，如圖11所示。

圖11 用戶端發(fā)送交易信息Fig.11 Sending transaction information by client-side

用戶將上述信息以｛S3=（"1，"+Address+"，"+name+"，"+Hash+"，"+users+"，"+gongyao+"，"+sign0+"，"+sign1）｝的字符串形式將內(nèi)容發(fā)送至授權(quán)節(jié)點(diǎn)進(jìn)行記錄，sign0 與sign1 分別表示消息經(jīng)SM2算法所產(chǎn)生數(shù)字簽名的r與s。節(jié)點(diǎn)收到信息后將信息分割并進(jìn)行處理，判斷對(duì)比交易發(fā)起方的地址是否與節(jié)點(diǎn)本地生成的地址一致，以及簽名驗(yàn)證是否通過(guò)，均通過(guò)則生成新的合約，將合約記錄入鏈，并將合約在數(shù)據(jù)庫(kù)中的對(duì)應(yīng)索引值即新的合約編號(hào)發(fā)回合約請(qǐng)求節(jié)點(diǎn)。

當(dāng)用戶使用客戶端發(fā)起交易申請(qǐng)時(shí)，需輸入上傳合約后返回的合約編號(hào)、文件流轉(zhuǎn)目標(biāo)Address，讀取文件名Name、交易發(fā)起方的私鑰和上次交易編號(hào)，上次交易編號(hào)作為流轉(zhuǎn)憑證起溯源索引作用，如果是初次交易，則上次交易編號(hào)與合約編號(hào)相同。將｛合約編號(hào)+目標(biāo)地址+上次交易編號(hào)｝數(shù)據(jù)打包作為簽名內(nèi)容，使用私鑰進(jìn)行SM2 簽名，獲得sign0 和sign1 兩個(gè)簽名部分。底層區(qū)塊鏈網(wǎng)絡(luò)收到交易申請(qǐng)后，提取消息中的sign0 和sign1 與交易信息中被簽名的內(nèi)容進(jìn)行SM2 簽名驗(yàn)證，授權(quán)節(jié)點(diǎn)生成新區(qū)塊使用SM3 算法對(duì)當(dāng)前區(qū)塊鏈中所有未入鏈交易進(jìn)行提取，合并全部交易信息后在尾部加入隨機(jī)數(shù)，使用SM3算法生成哈希值，通過(guò)改變隨機(jī)數(shù)值更新哈希值直至該值滿足一定條件后，作為新區(qū)塊的哈希值進(jìn)行廣播。

節(jié)點(diǎn)在生成區(qū)塊后，對(duì)所有新入鏈的交易信息進(jìn)行提取處理，摘出交易信息中的交易接收方，同時(shí)追蹤該交易所屬合約，提取合約中的文件名與哈希值，鏈接MySQL數(shù)據(jù)庫(kù)，向云端發(fā)起socket連接，發(fā)送文件更名命令。云端收到底層區(qū)塊確認(rèn)信息后調(diào)用SM2算法驗(yàn)證簽名，驗(yàn)證通過(guò)且明確該公鑰屬于授權(quán)節(jié)點(diǎn)后，連接文件索引數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)庫(kù)中文件進(jìn)行更名處理，此時(shí)文件所有權(quán)屬于文件接收方，文件所有權(quán)交易完成。

2.3.2 文件流轉(zhuǎn)溯源查詢

接收端用戶在收到流轉(zhuǎn)文件新索引后通過(guò)客戶端請(qǐng)求下載，如圖12 所示，獲取文件名稱、私鑰、公鑰、地址和哈希值，將私鑰進(jìn)行編碼轉(zhuǎn)換。

圖12 接收端下載電子文件Fig.12 Downloading electronic file at the receiving terminal

云端接收到下載文件申請(qǐng)，對(duì)接收的信息進(jìn)行分割處理，利用簽名內(nèi)容1、簽名內(nèi)容2、文件信息m1 和公鑰進(jìn)行SM2 簽名驗(yàn)證，判斷申請(qǐng)人和文件是否存在，若存在，則將文件進(jìn)行解碼轉(zhuǎn)換為十六進(jìn)制字符串輸出，并用socket連接。

接收端用戶獲得下載許可，調(diào)用數(shù)據(jù)流通過(guò)socket 取出數(shù)據(jù)，然后以String 的形式返回此字符串作為文件名，調(diào)用fileLength（）讀取文件長(zhǎng)度。根據(jù)directory 抽象路徑名和E：\FTCache 路徑符串創(chuàng)建一個(gè)新File 實(shí)例，判斷返回目錄名E：\FTCach 是否有實(shí)體存在，若失敗返回false，若成功則返回true，調(diào)用mkdir（）函數(shù)創(chuàng)建目錄。在目錄下，創(chuàng)建文件directory.getAbsolutePath（）+File.separatorChar+fileName，該流向File 對(duì)象表示的文件寫出數(shù)據(jù)進(jìn)行文件接收。從此輸入流中將最多1 024個(gè)字節(jié)的數(shù)據(jù)讀入一個(gè)byte數(shù)組中，返回值是返回讀入緩沖區(qū)的字節(jié)總數(shù)，當(dāng)已經(jīng)到達(dá)文件末尾而沒有更多的數(shù)據(jù)時(shí)，則返回-1。當(dāng)它返回-1 時(shí)，數(shù)據(jù)已經(jīng)復(fù)制完了while循環(huán)終止程序結(jié)束，則該文件接收成功。

當(dāng)授權(quán)節(jié)點(diǎn)接收到查詢申請(qǐng)時(shí)，會(huì)通過(guò)申請(qǐng)方提供的文件索引值在數(shù)據(jù)庫(kù)中進(jìn)行查詢，依據(jù)新舊索引值變化查找到對(duì)應(yīng)的文件流轉(zhuǎn)過(guò)程，從而完成文件的流轉(zhuǎn)溯源過(guò)程查詢。

3 系統(tǒng)測(cè)試

系統(tǒng)測(cè)試流程主要由用戶注冊(cè)、文件所有權(quán)轉(zhuǎn)讓、文件溯源查詢?nèi)糠纸M成。

3.1 用戶注冊(cè)

首先，用戶在客戶端輸入IP 地址和相關(guān)端口號(hào)，與服務(wù)器建立連接。用戶連接成功和失敗的效果圖分別為圖13所示。

圖13 用戶連接成功或失敗Fig.13 Success and fail of user connection

然后，用戶輸入用戶ID，生成相應(yīng)的公私鑰對(duì)及交易地址。生成的效果如圖14所示。

3.2 文件所有權(quán)轉(zhuǎn)讓

用戶上傳文件成功后向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起文件所有權(quán)交易申請(qǐng)，該交易需要先進(jìn)行智能合約的上傳和觸發(fā)，隨后將自動(dòng)實(shí)現(xiàn)文件所有權(quán)的轉(zhuǎn)換。電子文件流轉(zhuǎn)的智能合約是由主要節(jié)點(diǎn)提前嵌套至系統(tǒng)中的執(zhí)行程序，當(dāng)交易信息滿足條件時(shí)自動(dòng)執(zhí)行。

用戶 向云端上傳需進(jìn)行公證的電子文件。為防止電子文件傳輸誤差，用戶需要在文件末尾附加相關(guān)哈希值。效果圖如圖15所示。

圖14 輸入ID不同獲得公私鑰對(duì)Fig.14 Inputting different ID to obtain different public and private key pairs

云端 在接收文件后，需要對(duì)用戶提供的電子文件進(jìn)行哈希計(jì)算，與接收到的哈希值做對(duì)比。完成驗(yàn)證后，云端會(huì)向用戶返回存儲(chǔ)成功的反饋，告知用戶端文件成功上傳。若驗(yàn)證不通過(guò)，則該交易無(wú)效，節(jié)點(diǎn)不予記錄，同時(shí)向用戶返回報(bào)錯(cuò)信息。云端接收文件并進(jìn)行存儲(chǔ)如圖16所示。

圖15 選取上傳文件并完成上傳Fig.15 Choosing and uploading file

圖16 云端接收文件并進(jìn)行存儲(chǔ)Fig.16 Receiving and storing files on cloud platform

用戶 以（UserAddress+TxtName+TxtHash+sig+pk）形式向網(wǎng)絡(luò)廣播電子文件的合約信息。其中，UserAddress 為用戶的交易地址，TxtName 為文件名稱，TxtHash 為對(duì)應(yīng)的哈希值，sig為交易的簽名，pk為用于簽名驗(yàn)證的公鑰。用戶上傳文件成功后向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起文件所有權(quán)交易申請(qǐng)，該交易需要先進(jìn)行智能合約的上傳和觸發(fā)，隨后將自動(dòng)實(shí)現(xiàn)文件所有權(quán)的轉(zhuǎn)換。

礦工 首先驗(yàn)證用戶提供的公鑰UserAddress 與地址是否一致，接著對(duì)交易的簽名進(jìn)行驗(yàn)證。以上驗(yàn)證均通過(guò)則生成新的合約，并將合約記錄入鏈。若驗(yàn)證不通過(guò)，則該交易無(wú)效，節(jié)點(diǎn)不予記錄，同時(shí)向用戶返回報(bào)錯(cuò)信息。確認(rèn)合法的效果圖如圖17所示。

然后在生成區(qū)塊后，對(duì)所有新入鏈的交易信息進(jìn)行提取處理，摘出交易信息中的交易接收方，同時(shí)追蹤該交易所屬合約，提取合約中的文件名與哈希值，向云端發(fā)起文件更名命令，新區(qū)塊并入?yún)^(qū)塊鏈如圖18所示。

圖18 新區(qū)塊并入?yún)^(qū)塊鏈Fig.18 Adding new block into blockchain

云端 云端收到底層區(qū)塊確認(rèn)信息后調(diào)用SM2算法驗(yàn)證簽名，驗(yàn)證通過(guò)且明確該公鑰屬于授權(quán)節(jié)點(diǎn)后，連接文件索引數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)庫(kù)中文件owner 進(jìn)行更名處理，此時(shí)文件所有權(quán)屬于文件接收方，即為交易信息中的輸出方txout。

3.3 文件追溯查詢

用戶 在收到流轉(zhuǎn)文件新索引后通過(guò)客戶端向授權(quán)節(jié)點(diǎn)提出下載請(qǐng)求。

授權(quán)節(jié)點(diǎn) 當(dāng)收到查詢申請(qǐng)時(shí)，通過(guò)申請(qǐng)方提供的文件索引值在數(shù)據(jù)庫(kù)中進(jìn)行查詢，依據(jù)新舊索引值變化查找到對(duì)應(yīng)的文件流轉(zhuǎn)過(guò)程，從而完成文件的流轉(zhuǎn)溯源過(guò)程查詢。若請(qǐng)求合法，向云端發(fā)出同意該用戶下載文件指令。

云端 接收到下載文件申請(qǐng)后，判斷文件地址是否正確和文件owner是否是下載申請(qǐng)人，當(dāng)判斷為true時(shí)則創(chuàng)建文件流，在當(dāng)前目錄中創(chuàng)建新文件并進(jìn)行操作，隨后判斷該文件是否存在。向用戶發(fā)出文件下載許可。

用戶 通過(guò)云端指定路徑即可下載目標(biāo)文件。

4 安全性分析

本章主要針對(duì)區(qū)塊偽造攻擊和篡改數(shù)據(jù)攻擊進(jìn)行安全說(shuō)明。當(dāng)惡意節(jié)點(diǎn)企圖通過(guò)篡改交易數(shù)據(jù)、延遲交易生效等方式進(jìn)行非法交易操作時(shí)，需要偽造新區(qū)塊保證惡意交易生效。考慮到惡意節(jié)點(diǎn)的攻擊方式為通過(guò)延遲當(dāng)前賬本中未入鏈交易的入鏈速度，通過(guò)連續(xù)生成區(qū)塊導(dǎo)致同樣輸入，不同輸出的交易生效的“雙花”交易。

下面假設(shè)正常節(jié)點(diǎn)生成新區(qū)塊的概率為Ps，惡意節(jié)點(diǎn)生成新區(qū)塊的概率為Pe，正常節(jié)點(diǎn)的個(gè)數(shù)為g，則若惡意節(jié)點(diǎn)發(fā)起一次偽造區(qū)塊操作，連續(xù)生成兩個(gè)新區(qū)塊的概率Pn為：

由式（4）可知，在節(jié)點(diǎn)算力不變的情況下，節(jié)點(diǎn)總數(shù)越多，惡意節(jié)點(diǎn)偽造區(qū)塊成功的概率越小，惡意節(jié)點(diǎn)需要提升算力，增大生成新區(qū)塊的概率，才能提高偽造成功率。本文通過(guò)降低惡意節(jié)點(diǎn)的區(qū)塊生成難度，達(dá)到提升惡意節(jié)點(diǎn)算力的效果。通過(guò)系統(tǒng)測(cè)試，本系統(tǒng)在正常節(jié)點(diǎn)數(shù)為5 時(shí)，惡意節(jié)點(diǎn)與正常節(jié)點(diǎn)的挖礦難度差距H=2 時(shí)，才能使生成新區(qū)塊所需平均時(shí)間與正常節(jié)點(diǎn)組基本一致。如圖19 所示，當(dāng)正常節(jié)點(diǎn)數(shù)為10 時(shí)，惡意節(jié)點(diǎn)與正常節(jié)點(diǎn)的挖礦難度差距H=3 仍比正常交易節(jié)點(diǎn)組生成區(qū)塊用時(shí)更長(zhǎng)，此時(shí)惡意節(jié)點(diǎn)的算力已大約為正常節(jié)點(diǎn)的8 倍。本文系統(tǒng)使用10 個(gè)節(jié)點(diǎn)進(jìn)行區(qū)塊生成，所用共識(shí)算法在惡意節(jié)點(diǎn)算力遠(yuǎn)大于正常節(jié)點(diǎn)時(shí)，仍能抵抗惡意節(jié)點(diǎn)的偽造區(qū)塊攻擊。

圖19 惡意節(jié)點(diǎn)偽造區(qū)塊攻擊用時(shí)Fig.19 Time of malicious node forged block attack

對(duì)于篡改數(shù)據(jù)攻擊，由于本文系統(tǒng)基于聯(lián)盟鏈設(shè)計(jì)，新區(qū)塊生成需要經(jīng)過(guò)全部在線主要節(jié)點(diǎn)投票決定是否作為有效區(qū)塊，當(dāng)票數(shù)超過(guò)50%才能生效。因此只有當(dāng)惡意節(jié)點(diǎn)超過(guò)當(dāng)前在線節(jié)點(diǎn)總和的半數(shù)，篡改數(shù)據(jù)才能成功。本文系統(tǒng)使用10 個(gè)主要節(jié)點(diǎn)進(jìn)行區(qū)塊生成，主要節(jié)點(diǎn)長(zhǎng)期在線，可以有效防止惡意節(jié)點(diǎn)通過(guò)多數(shù)投票達(dá)到篡改交易數(shù)據(jù)的目的。

5 性能測(cè)試

在本章的性能測(cè)試中，將實(shí)際運(yùn)行結(jié)果與預(yù)設(shè)功能進(jìn)行對(duì)比分析，得出本系統(tǒng)各部分功能正常且電子文件流轉(zhuǎn)過(guò)程順利，已滿足了電子文件的流轉(zhuǎn)要求。對(duì)系統(tǒng)的性能測(cè)試和仿真中，本系統(tǒng)能夠有效抵抗惡意攻擊，防止篡改文件所有權(quán)問(wèn)題的發(fā)生，相較于傳統(tǒng)電子文件流轉(zhuǎn)系統(tǒng)具備更高的安全性和不可篡改性。同時(shí)，系統(tǒng)的效率測(cè)試表明該系統(tǒng)的交易過(guò)程滿足系統(tǒng)需要，當(dāng)需要大批量文件流轉(zhuǎn)時(shí)可以通過(guò)增加授權(quán)節(jié)點(diǎn)數(shù)量縮短交易確認(rèn)時(shí)間，從而提升系統(tǒng)效率。

本系統(tǒng)基于Java 語(yǔ)言搭建聯(lián)盟鏈環(huán)境，使用數(shù)據(jù)庫(kù)完成區(qū)塊鏈數(shù)據(jù)存放，調(diào)用云平臺(tái)端口完成文件存放，故其安全性和穩(wěn)定性可以滿足要求。

系統(tǒng)的效率測(cè)試是對(duì)系統(tǒng)在正常使用下其系統(tǒng)運(yùn)行用時(shí)的測(cè)試。因系統(tǒng)中節(jié)點(diǎn)的文件上傳與下載工作用時(shí)主要取決于云端架構(gòu)、文件大小及網(wǎng)速等因素，與區(qū)塊鏈系統(tǒng)運(yùn)行效率不直接相關(guān)，故不進(jìn)行測(cè)試。本文主要對(duì)系統(tǒng)區(qū)塊鏈節(jié)點(diǎn)運(yùn)行部分進(jìn)行效率仿真與測(cè)試。

節(jié)點(diǎn)在上傳文件至云端后，需在本地根據(jù)密鑰對(duì)及文件哈希值等信息生成相應(yīng)文件流轉(zhuǎn)合約。進(jìn)行文件流轉(zhuǎn)時(shí)，須根據(jù)返回的合約編號(hào)及流轉(zhuǎn)方的地址制作交易信息。本文定義節(jié)點(diǎn)生成智能合約所需平均時(shí)間Sm與生成交易信息平均用時(shí)Sq為：

式（5）～（6）中：Ti(m)與Ti(q)分別表示第i 次測(cè)試時(shí)節(jié)點(diǎn)生成智能合約與生成交易信息所用的時(shí)間。平均用時(shí)即為進(jìn)行20次實(shí)驗(yàn)之后所得的平均值。由圖20可知，在用戶密鑰對(duì)成功生成的情況下，成功制作一次智能合約與交易信息的平均時(shí)間分別為41.8 ms 與40.4 ms，因?yàn)楸疚南到y(tǒng)兩個(gè)功能步驟所需運(yùn)算類似，因此用時(shí)差距較小，并且用時(shí)均較短，在確保功能完整的情況下生成數(shù)據(jù)量較少，滿足聯(lián)盟鏈交易的要求。

圖20 節(jié)點(diǎn)生成智能合約和生成交易所用時(shí)間Fig.20 Times of nodes to generate smart contracts and generate transactions

交易信息由用戶發(fā)送至授權(quán)節(jié)點(diǎn)后，開始確認(rèn)交易信息。本文定義系統(tǒng)交易平均驗(yàn)證時(shí)間Stx與最短耗時(shí)Mtx為：

式（7）～（8）中：n為參與仿真測(cè)試的區(qū)塊數(shù)，Ti為主要節(jié)點(diǎn)對(duì)第i個(gè)區(qū)塊的驗(yàn)證時(shí)間，Pi為第i個(gè)區(qū)塊中所包含的交易個(gè)數(shù)，平均驗(yàn)證速度即為單位時(shí)間內(nèi)主要節(jié)點(diǎn)驗(yàn)證交易信息的平均次數(shù)。經(jīng)過(guò)節(jié)點(diǎn)的區(qū)塊驗(yàn)證仿真測(cè)試，在確認(rèn)交易信息無(wú)誤的情況下，授權(quán)節(jié)點(diǎn)驗(yàn)證區(qū)塊合法性的時(shí)間與該區(qū)塊所含的交易量間呈圖21關(guān)系。由圖21可知，本方案中授權(quán)節(jié)點(diǎn)平均驗(yàn)證通過(guò)一個(gè)區(qū)塊所需時(shí)間為34.2 ms，最快可達(dá)到20.1 ms，可算出不考慮共識(shí)算法消耗時(shí)間的情況下，系統(tǒng)平均交易速度為每秒29.2 次，最多可達(dá)49.7 次，交易次數(shù)滿足聯(lián)盟鏈應(yīng)用場(chǎng)景需要。

圖21 仿真環(huán)境下授權(quán)節(jié)點(diǎn)驗(yàn)證區(qū)塊合法性時(shí)間與所含交易量關(guān)系Fig.21 Relationship between time of authorized node verifying block legality and transaction volume in simulation

交易信息經(jīng)授權(quán)節(jié)點(diǎn)確認(rèn)入鏈后，開始執(zhí)行智能合約。本文定義節(jié)點(diǎn)執(zhí)行智能合約平均用時(shí)Sc及最短耗時(shí)Mc為：

式（9）～（10）中：Ti(F)為第i 次實(shí)驗(yàn)時(shí)節(jié)點(diǎn)在區(qū)塊鏈中找到交易信息所屬智能合約的時(shí)間，Ti(S)為節(jié)點(diǎn)根據(jù)交易信息，執(zhí)行對(duì)應(yīng)智能合約，向云端發(fā)送文件所屬權(quán)變更命令的時(shí)間，x為實(shí)驗(yàn)仿真次數(shù)。如圖22 所示，經(jīng)20 次仿真可知，在確認(rèn)交易信息無(wú)誤的情況下，成功追蹤到所屬智能合約的平均用時(shí)為25.5 ms，最短需要21.7 ms。在驗(yàn)證交易信息滿足所屬智能合約執(zhí)行條件的情況下，授權(quán)節(jié)點(diǎn)執(zhí)行一次智能合約，發(fā)送所屬權(quán)變更指令的平均用時(shí)為150.7 ms，最短需要101.1 ms。因此，節(jié)點(diǎn)執(zhí)行智能合約平均用時(shí)約172.4 ms。合約執(zhí)行時(shí)間較短，可以滿足電子文件流轉(zhuǎn)的實(shí)際需要。

圖22 仿真環(huán)境下授權(quán)節(jié)點(diǎn)追蹤合約用時(shí)Fig.22 Time of authorized node tracking contract in simulation

6 結(jié)語(yǔ)

將區(qū)塊鏈技術(shù)和云存儲(chǔ)技術(shù)相結(jié)合，極大程度地解決電子文件流轉(zhuǎn)中的一些問(wèn)題，同時(shí)二者相互結(jié)合并應(yīng)用于電子文件領(lǐng)域?qū)U(kuò)大區(qū)塊鏈技術(shù)的應(yīng)用場(chǎng)景，對(duì)推動(dòng)區(qū)塊鏈應(yīng)用具有一定理論和實(shí)踐意義。本文提出的電子文件流轉(zhuǎn)方案在可接受的時(shí)延范圍內(nèi)實(shí)現(xiàn)了文件的安全流轉(zhuǎn)和可信記錄，能夠根據(jù)區(qū)塊鏈記錄進(jìn)行流轉(zhuǎn)過(guò)程查詢，有效防止數(shù)據(jù)篡改和惡意攻擊，保證接入記錄的結(jié)果完整可信，保障整體系統(tǒng)運(yùn)行可靠、安全可用。為了弱化中心化環(huán)節(jié)系統(tǒng)的正常運(yùn)行，本系統(tǒng)采用輸入ID 作為用戶登錄的方法，自動(dòng)置入密鑰功能暫未實(shí)現(xiàn)，可以在下一步工作中繼續(xù)完善設(shè)備系統(tǒng)，實(shí)現(xiàn)自動(dòng)置入功能。