目錄
摘 要 I
Abstract II
第 1 章 緒論 1
1.1研究背景與研究意義 1
1.2國內外研究現狀 2
1.2.1養老系統的研究現狀 2
1.2.2區塊鏈技術的研究現狀 3
1.3論文工作與結構 4
1.3.1論文工作 4
1.3.2論文結構 5
1.4本章小結 5
第 2 章 相關原理與技術介紹 7
2.1區塊鏈基本知識與技術 7
2.1.1區塊鏈基本知識與架構 7
2.1.2智能合約 9
2.1.3共識機制 9
2.1.4Hyperledger Fabric網絡 10
2.2密碼學基礎 11
2.2.1哈希函數 11
2.2.2對稱加密技術 13
2.2.3公鑰加密技術 14
2.2.4數字簽名技術 16
2.3系統開發技術 16
2.3.1Springboot 17
2.3.2MCV模式 17
2.3.3Docker容器技術 17
2.4本章小結 18
第 3 章 基于區塊鏈的養老信息管理平臺的系統設計 19
3.1需求分析 19
3.1.1功能性需求分析 19
3.1.2非功能性需求分析 19
3.2系統總體架構設計 20
3.3系統功能模塊設計 21
3.3.1系統總體設計 21
3.3.2用戶模塊設計 22
3.3.3機構模塊設計 24
3.4智能合約設計 25
3.4.1鏈碼數據結構設計 26
3.4.2智能合約功能設計 27
3.5本章小結 28
第 4 章 基于區塊鏈的養老信息管理平臺的實現 29
4.1SDK開發 29
4.1.1Fabric證書注冊和登記用戶 29
4.1.2SDK調用智能合約 30
4.2用戶模塊 30
4.2.1用戶注冊功能 31
4.2.2用戶登錄 32
4.2.3查看隱私數據 34
4.2.4上傳隱私數據 35
4.2.5上傳一般數據 37
4.3機構用戶模塊 38
4.3.1機構注冊 38
4.3.2一般數據查看 39
4.4數據審核模塊 40
4.4.1用戶審核 41
4.4.2一般數據審核 42
4.4.3隱私數據審核 43
4.5本章小結 45
第 5 章 系統測試 46
5.1功能測試 46
5.1.1注冊、登錄測試 46
5.1.2數據添加與查看測試 46
5.1.3數據審核測試 47
5.1.4數據加密測試 48
5.1.5數據上鏈測試 48
5.2性能測試 49
5.2.1加密性能測試 49
5.2.2哈希性能測試 49
5.3本章小結 50
第 6 章 總結與展望 51
6.1本文主要工作 51
6.2展望 51
參考文獻 52
致 謝 52
第 1 章 緒論
1.1研究背景與研究意義
2019年,聯合國發文稱“全球人口一大重要趨勢就是人口老齡化”[1],同時,我國 也面臨著相關挑戰。早在上個世紀末,我國60周歲及以上人口就達到全國的10%以上, 截至2020年底,我國老齡化人口約占總人口的18.7%,高達2.64億[2]。而這一比例將在未 來的30內年不斷提高,直至維持在總人口的30%左右。因此,在人口急劇老齡化的社會 大背景下,如何實現高效的養老是亟須解決的問題。
我國養老模式一般分為三種,社區養老,家庭養老和機構養老[3]。社區養老和家庭 養老雖然可以在很大程度上解決不少老人養老的問題,但是這兩種模式很難完全覆蓋 所有老人的養老問題。例如:某老人經歷過手術并且具有三高,這時候,我們很難要 求老人的子女或者社區員工具備專業的護理知識。因此,機構養老作為一種補充是十 分必要的。但是目前市面上的養老機構基本采用的都是中心化的信息管理系統,而這 種中心化的管理系統容易導致老人的相關信息尤其是隱私數據得不到保障,無論是基 于內部的惡意管理人員的操作還是外部的黑客攻擊竊取,一旦信息泄露,這無疑對老 人是一種巨大的傷害。
而區塊鏈技術和國密技術的出現給上述問題的解決提供了一種全新的思路。區塊 鏈技術是一種去中心化的技術,數據的確認是各個節點“合力”的結果。雖然數據存 入區塊鏈中,可以避免“一言堂”的情況,但數據一旦上鏈,就必須公開,可是老人 信息中的隱私部分顯然不能夠被公開。而國密算法的出現則可以有效應對這種情況, 國密算法雖然起步晚,但其安全性高,以SM3為例,目前仍然沒有單位或者個人可以 人為制造碰撞。
因此,本文研究基于區塊鏈技術的養老信息管理平臺。將區塊鏈和國密加密技術 應用于養老信息管理不僅能夠解決隱私數據泄露的問題,而且能夠提高其余一般數據 的傳輸速度。此外,區塊鏈獨有的時間戳技術也可以證明老人何時在哪家養老機構, 具有一定的法律效應。
本課題研究基于區塊鏈技術的養老信息管理平臺,其研究意義如下:
(1)去中心化。目前養老信息管理系統采用的是中心化的工作模式,這就使得老人的 很多信息實質上是由管理員在控制。但是由于商業競爭以及沒有統一的規定,各家機構 的數據模型設計并不一致,這就為老人在更換機構的時候帶來了數據交換的困難。而采 用了區塊鏈技術的養老信息管理系統可以讓大家共同記錄和存儲數據,從而解決了上述 問題。
(2)利用國密加密避免隱私泄露。本文利用SM2公鑰加密對隱私數據加密,使得老人 的隱私數據只有自己能解密。同時也利用SM4分組加密算法對通用數據進行加密,使得 一些必要數據被機構和老人共同擁有,在保證了服務的及時性的同時,也避免了服務器 被黑客攻破而造成數據泄露等問題。
(3)具有一定的法律效應。首先每個區塊形成的時候都會有時間戳,所以這個區塊里 面的內容具備一定的時效性證明。其次由于區塊鏈本身使用的是分布式網絡,在這種網 絡結構下,除非黑客能夠在很短的時間內攻破50%以上的節點,要不然無法對數據產生 “破壞”。雖然這種情況有理論上的可能性,但是如果區塊鏈中的節點數目達到了一定 規模,那這種情況在現實中極其難發生。
1.2國內外研究現狀
1.2.1養老系統的研究現狀
相對于我國,國外西方發達國家進入老齡化社會的時間更早,因此西方學者對于養 老的研究早于我國。根據知網檢索,養老信息管理系統概念最早始于1890年,由George Baber在《0ur elderly care System》[4]一書文提出,但該文中主要介紹的是關于養老金信息 的管理。之后,在較長的一段時間內,國外學術界對于養老信息管理系統的研究都是圍 繞著對養老金和養老金制度的管理進行的。直至1922年,Brundage Dean K在《Records of the Small Sick-Benefit Association as a Source of Statistics for the Factory Medical Department》 [5]一文中另辟蹊徑,提出了醫療記錄和醫療津貼管理系統,此時的醫療記錄 還只是局限于一些小病。雖然該文并未直接對養老信息管理系統進行研究,但是其研究 內容,為后續的醫療記錄管理系統的研究開辟了道路,而醫療記錄又是養老信息的重要 組成內容,醫療記錄管理系統也是養老信息管理系統的前身。1970年,Gledhill V X[6]等 人指出:應將醫療記錄的存儲和檢索任務交給計算機,以期減少人力資源和物力資源的 消耗。在 1997年,由Marcelo Sosa-Iudicissa等一眾學者在《An Information system for the Elderly and Disabled People》 [7]一文中完整的提出了比較完整的養老信息管理系統,之后 的養老信息管理系統主要是針對不同的場景而進行具體設計的,如針對孤寡老人的系統 應該有報警功能,香港社區養老系統應該具有遠程協助功能等,到了2019年, Masakazu Washio,Chikako Kiyohara等人在《Health Issues and Care System for the Elderly》[8]一文中 詳細的提出了老人常見的各種病癥以及對應的護理策略,并且還兼顧到了老人照顧者的 信息。
國內的養老信息管理系統起步較晚,早期的系統也是與金融相關的,如:楊慶中提 出的養老保險基金交易支付系統[9]。之后,我國在上世紀90年代確定了養老的相關法律, 至此,我國的養老信息管理系統進行了高速的發展,這一方面是得益于外國提前進入了 老齡化社會,有對應的參考內容,另一方面也得益于我國政府和學者的共同努力。
2001年,劉杰提出了一種關于養老保險和個人信息的信息管理系統的設想[10]。之后 不斷有學者在此基礎上設計,開發修改和完善相應的功能。 2010年,張燕萍研究并設計 出居家養老服務信息管理系統[11],這是國內較早設計的比較完善的養老信息服務管理系 統,之后,張冠湘提出社區養老系統[12],這將養老系統擴充到了其他場景。隨著物聯網 技術的發展,很多學者提出將物聯網技術融入養老系統中,實現智能家居和養老系統的 融合,并由此衍生出一系列的相關系統,如:基于物聯網技術的智能社區居家養老系統 [13]等。但是由于我國目前大部分老人經濟水平沒有那么高并且大部分老人也很難去適應 智能家居的使用,所以之后基于物聯網的養老信息服務系統雖然有一定發展,但并沒有 在質的程度上有非常大的突破,且智能家居的大規模應用仍然存在很多阻力,如:不同 的廠商并不開放彼此的接口。
1.2.2區塊鏈技術的研究現狀
區塊鏈技術并不像養老信息管理系統那樣歷史悠久,它的首次出現是在Satoshi Nakamoto發表的一文《Bitcoin:A Peer-to-Peer Electronic Cash System》[14]中。作者在文中 闡述了一個由多方參與且共同維護的電子現金系統。之后隨著時代的發展,人們愈發意 識到“信任”在商業領域中的重要性[15],而Bitcion系統中的不可篡改,去中心化等特性 引發了學者們的思考。之后,各種區塊鏈的應用接踵而至。
按照準入機制的不同,區塊鏈一般可以分為三種:公有鏈,私有鏈和聯盟鏈[16],公 有鏈的主要代表——“比特幣”系統,公有鏈,顧名思義即“公共的”鏈,因此在公有 鏈系統中,用戶不需要被授權,即可自由加入或者退出區塊鏈網絡。雖然這是真正意義 上的去中心化的網絡結構,但是這種網絡結構無法阻止大量的非誠實節點的接入。私有 鏈僅在某個組織內部使用,它的規則也由內部組織所確定,因此私有鏈的節點一般并不 多,其交易速度比其他類型的區塊鏈快很多。聯盟鏈僅僅限于聯盟組織成員,因此在聯 盟鏈上的記賬規則和讀寫權限是由聯盟的內部成員所決定的,其去中心化程度介于公有 鏈和私有鏈之間。目前應用最為廣泛的聯盟鏈技術是超級賬本(HyperLedger)。
目前,區塊鏈的應用有如下三種:
(1) 數字貨幣:區塊鏈自誕生開始就與數字貨幣具有聯系,數字貨幣是一種不被管 制、數字化的貨幣,通常由虛擬社區創始人創立發行規則,其受眾也是虛擬社區的成 員。但是數字貨幣不等同于電子貨幣,它不與法幣掛鉤,最常見的數字貨幣有比特幣 等。
(2) 金融應用:由于區塊鏈與數字貨幣緊密結合,所以區塊鏈在金融應用方面具有 天然的優勢。與區塊鏈結合緊密的金融應用有:保險業務、資產證券等。
(3 )區塊鏈+:隨著區塊鏈在金融應用中的成功應用,其技術也漸漸體現出其價 值。于是不斷有學者嘗試將區塊鏈與別的行業結合,簡稱“區塊鏈+”。
除了考慮到區塊鏈應用場景的發展之外,不少學者也對區塊鏈中采用的密碼技術提 出了自己的看法與改進。
2017年,Jeme 1等學者基于密文策略屬性加密(CP-ABE)方案設計了一種利用雙密 鑰共同加密數據的方案[17],雙密鑰分別為K1,K2,其中,K2需要通過具有時間屬性 的加密方案(基于CP-ABE)再次進行加密,這保證了區塊鏈中的節點必須在規定時間 要求下,同時擁有密鑰K1和K2才可以訪問數據,雖然這一方案的設計有利于提高用戶 對數據的控制權限,但由于CP-ABE方案本身為中心化方案,因此Jeme 1學者的方案僅適 合私有鏈場景。另外,由于該方案涉及多次加密,實現較為復雜。
2018年,Ferri Andrianto Susilo等人采用了帶有Rijndael 256的密碼對稱算法與區塊鏈 應用結合[18]。雖然對比Jeme 1等人的算法,該算法速度快且便于設計,但是由于該方案采 用對稱密碼算法,所以其也很難在公有鏈或聯盟鏈等場景中完全適用。
2019年,楊亞濤【I9】等人為了解決區塊鏈中可能存在的泄露隱私問題,在SM9算法之 上,提出了一種基于身份的群簽名方案,對比Ferri Andrianto Susilo等人的方案,該方案 將隱私保護拓展到了聯盟鏈。
之后,仍然有很多學者不斷提出與區塊鏈結合的加密方案,但也有學者考慮從“密 鑰”入手,其中較為出名的就是Albakri等人采用令牌預加載的方式[20],提出了輕量級二 元多項式的密鑰管理方案,雖然,此方案能夠減少區塊鏈在建立密鑰時的開銷,但該方 案缺乏密鑰撤銷機制且也難以對密鑰進行溯源。
同年十月,我國密碼法落地,各行各業掀起一股“國密風”。次年,章建聰[21]等人 便對超級賬本Fabric進行了國密改造,在其論文中,“國密改造”改變的是聯盟鏈底層采 用的加密方案,經過改造的Fabric符合我國監管。
1.3論文工作與結構
1.3.1論文工作
當前養老信息管理系統存在兩大問題,一方面,不同的養老機構采用不同的養老信 息系統,而每家需要的數據內容和格式都不盡相同,而這就會導致老人如果已經在一家 被提供了服務之后,想換一家新的機構,即便上一家機構不“刻意”為難,數據也很難 遷移。另一方面,由于目前的養老系統都采用中心化的工作方式,這就導致數據容易被 中心管理員篡改或刪除,甚至泄露。這種情況無疑會給老人帶來巨大的打擊。
此外,根據商用密碼應用安全性評估聯合委員調查,目前我國大部分企業仍會
選擇SHA1024等不安全的加密方式[22],在這種加密方式下工作的系統,如果數據一 旦被黑客等惡意的第三方獲取,那么也會造成隱私的泄露。針對這些問題,本文提 出了基于區塊鏈技術的養老信息管理平臺,之后設計并實現相關系統。本文主要研究 工作內容如下:
(1) 針對當前市面上常見的養老系統采用的中心化管理方式這一情況 ,本文提 出利用區塊鏈存放老人的信息,并將信息的控制權“真正”的交予老人,從而保證機 構或攻擊者無法篡改數據信息。
(2) 采用哈希函數國密標準算法SM3來計算并存儲用戶口令的哈希值,確保在 數據庫被攻破的情況下,攻擊者仍然無法獲得用戶口令的明文,保障了用戶帳號口
令的安全性。
(3) 本文將數據分為隱私數據和一般數據并分別采用不同的加密方案,對于隱 私數據,本文采用SM2算法加密[23],在無老人私鑰授權的情況下,他人(包括機構) 只能看到對應的密文。此外,由于機構是養老服務的提供者,因此他們必然需要了解 到一些相關信息,對于這部分信息,本文采用SM4加密方案[24],密鑰由機構和用戶共 同保存。將數據劃分最大的好處在于,即便管理員泄露了他所知道的信息,這部分信 息也不會對老人的隱私安全產生重大影響。
(4) 最后,本文應當對設計的系統進行測試,主要測試分為加密模塊測試和數 據上鏈測試,除此之外還應實現登錄等常規功能的測試。并在此基礎之上,進行加 密和哈希算法的時間測試。
1.3.2論文結構
全文分為六個章節,每章節主要內容如下:
第1章,緒論。本章介紹了國內外養老系統和區塊鏈系統研究現狀,并針對國內市面 上養老系統的部分痛點,提出相關方案并確定相關技術手段。
第2章,相關原理與技術介紹。由于區塊鏈技術并非單獨發展的技術,它是過去很多 技術的融合,因此本章主要介紹區塊鏈基礎知識。除了關于區塊鏈的知識,本章還介紹 了密碼學的相關內容,以及部分開發技術。
第3章,基于區塊鏈的養老信息管理平臺的系統設計。任何系統在實現之前都必須考 慮到它所面臨的需求,因此本章首先進行需求分析,再從用戶與機構兩種角度來設計有 關系統的功能和方案,最后,根據實際需求,設計智能合約。
第4章,基于區塊鏈的養老信息管理平臺的實現。有了第三章的分析,本章首先對 SDK進行開發,并以添加某用戶為例給出了相關代碼說明,之后,按照用戶與機構的角 度對其功能進行了開發,但鑒于用戶功能較為復雜,因此將用戶模塊拆分為用戶數據模 塊和數據審核模塊并分別說明。
第5章,系統測試。雖然在第四章,我們已經對系統進行了實現,但是仍需判斷系統 是否符合預期,尤其是是否完成第三章所設計的功能。因此,本章首先給出了系統的功 能性測試,之后分別對國密算法,哈希算法進行了時間上的測試。一來,可以知道對比 未采用加密和哈希手段區塊鏈系統而言,本系統采用的加密和哈希方案所帶來的開銷是 否在可承受范圍內;二來,可以判斷出將數據區分為隱私數據和一般數據并對一般數據 采用對稱加密,是否可以有效系統開銷。
第6章,總結與展望。首先對1-5章的內容進行了回顧,并指出本文所設計的系統的 意義所在。在此基礎上,切實地提出該系統在開發或測試中仍存在的問題,并展望完善 后續功能。
1.4本章小結
本章主要對研究內容以及相關問題進行了大致描述,通過分析國內外關于養老系統 以及區塊鏈的現狀,總結其中存在的部分問題,并在此基礎之上確立要解決的有關問 題。
第 2 章 相關原理與技術介紹
2.1區塊鏈基本知識與技術
2.1.1區塊鏈基本知識與架構
不同于人工智能等其他新興的技術,區塊鏈技術是由公鑰加密技術,分布式處理技 術,時間戳技術,數字簽名等技術組合而成的新型技術[25]。在區塊鏈網絡中,除創世區 塊以外,每一個區塊都擁有上一個區塊的哈希值,如圖2-1所示,正是因為這種形如 “鏈”式的數據結構,人們也稱其為“區塊鏈”。
圖2-1 區塊結構圖
簡單來講,區塊鏈是將具有時序先后的數據打包到不同的數據區塊中并將其鏈接而 成的區塊集。而從本質上來講,區塊鏈則是“非刪除型”的共享數據庫,存儲在這個數 據庫中的數據會通過非對稱加密等手段實現數據的保密性和不可篡改性。因此,區塊鏈 也可以認為是一個利用多種手段保護數據安全并由多方共同維護的一個不可篡改的共識 賬本。
區塊鏈網絡中的節點分為記賬節點和非記賬節點兩種,其中非記賬節點也稱之為輕 節點。無論記賬或非記賬節點在區塊鏈網絡中都可以進行交易。其中,非記賬節點不參 與賬本的維護,它們也無法將交易打包成區塊并提交到區塊鏈網絡中,它們只是交易內 容的產生者。相比起非記賬節點,記賬節點的功能則“豐富”的多,它們不僅可以產生 交易,還具有賬本維護、產生區塊等功能[26]。
區塊鏈的架構一般分為六層[27],如圖2-2所示,自下而上分別是:
(1) 數據層:數據區塊是數據層的核心內容,每個區塊都包含了交易,區塊頭,交 易數量等內容,對于區塊而言,最核心的就是區塊頭。區塊頭的生成運用了很多技術, 如時間戳技術和鏈式技術可以保證每個區塊按照時序進行鏈接,而非對稱加密技術則用 來保證數據的安全性,其中,鏈式技術中采用了Merkle樹[28啲結構。Merkle樹和Hash算 法往往是共同使用的,Hash算法用來將交易內容映射為固定長度的二進制值(簡稱為哈 希值),再利用Merkle樹的性質,將剛剛形成的哈希值不斷兩兩結合取哈希,最后形成 的根成為Merkle根。
(2) 網絡層:網絡層的主要功能就是實現區塊鏈中不同節點之間的交流。由于區塊 鏈沒有中心服務器,因此用戶之間只能夠點對點交換信息,由此組成的網絡即為 P2P 組 網。
(3) 共識層:由于區塊鏈是分布式存儲的,每個節點理論上都可以在本地生成新的 區塊并記賬,如果任由每個節點都在本地進行上述操作,會對區塊鏈網絡造成巨大破 壞。因此共識層就是讓分散在P2P網絡中的記賬節點通過共識機制去保證所有誠實的節點 保留的副本是一致的。目前已經有的共識機制有Pow (工作量證明)、Pos (權益證明) 等。
( 4)激勵層:激勵層的主要作用就是提供一些“獎勵”并以此鼓勵節點參與記賬和 賬本維護。常見的激勵手段有:“挖塊獎勵”和“交易扣費”,但是激勵層并非所有的 區塊鏈系統都有,因為在有的區塊鏈系統中,就并不天然具有類似“比特幣”那樣的代 幣。
(5)合約層:智能合約是合約層的核心內容。智能合約本質上是存儲在區塊鏈上的 一段代碼,這段代碼會被區塊鏈上相應的操作(例如轉賬等)所觸發,觸發后會執行相 應的功能。智能合約的使用可以減少巨額的信任成本。
(6)應用層:應用層是用戶與區塊鏈系統交互的界面層。
2.1.2智能合約
智能合約的定義最早可以追溯到1994年,由一位法律學家尼克薩博(Nick Szabo) 提出畫,定義如下:“一個智能合約是一套以數字形式定義的承諾(commitment),包 括合約參與方可以在上面執行這些承諾的協議。”,雖然當時沒有對應的應用。由于智 能合約是以數字形式定義下來的合約,因此對于智能合約而言,它天然具有被計算機編 碼的功能。如今,它已經被廣泛應用在區塊鏈系統中。
智能合約和現代的紙質合同有一些相似之處,區別在于它是數字化的,只要觸發器 滿足條件時,它就會執行相應的合約內容并產生結果。多數情況下,參與智能合約的多 方彼此之間并不認識,因此,為了交易的公正,智能合約除了數字化的特點之外,還應 該具有透明性和開放性。
智能合約是由一系列行為規則、初始狀態、對應操作和觸發條件組成的[30]。它以代 碼的形式存儲在區塊鏈中,并通過廣播的方式發送給區塊鏈網絡中的每個節點。節點在 接收到智能合約之后會驗證其正確性,通過后才可以存儲在本地并部署。值得注意的 是,如果某個節點存儲并部署了智能合約,則該智能合約一般無法被篡改。因此智能合 約設計不僅僅是合約代碼的設計,還需要考慮到合約運行的環境等其他因素。表2-1是三 個主流平臺的智能合約的分析。
表2-1 智能合約分析表
平臺 Bitcoin Ethereum Fabric
程序語言 腳本語言 Solidity Golang
圖靈完備 非完備 夂
完備 夂
完備
代幣 比特幣 以太幣 無代幣
雖然不少專家學者認為比特幣系統的腳本語言是智能合約,因為其符合智能合約的 某些特點,如:公開透明,自動處理等,但是其并非正真意義上的智能合約,因為無論 從圖靈完備性還是編碼的可擴展性而言,其相對于后兩個區塊鏈平臺的智能合約而言都 有不小的差距。因此,學術界主流的觀點認為第一個較為完備的智能合約是以太坊智能 合約。智能合約的出現使得區塊鏈的應用場景不僅僅局限于轉賬交易。
雖然智能合約有很多優點,但其并非“完美”,甚至它的某些優點也有可能是缺 點,比如:一旦部署無法更改,這種不可更改性雖然保證了交易不會因為合約的更改而 遭到破壞,但也失去了一定的拓展性。
2.1.3共識機制
共識機制技術是區塊鏈眾多核心技術之一,簡單來講,共識就是讓不同群體或個體 能至少在某一方面達成的共同意見,而共識機制就是達成和維護這個共同意見的方式 [31]。由于區塊鏈系統是一個非中心化的系統且它的節點是分布式的,因此由眾多節點組 成的區塊鏈網絡采用的通信方式為異步通信,而區塊鏈系統為了讓眾多節點達成一致, 當鏈路發生更新時,就需要網絡中的主機同步復制該狀態。而主機復制狀態采用的通信 方式為異步通信,但異步通信不同于同步通信,這種通信方式更容易受到網絡擁塞的影 響而導致數據的不一致,從而傳播錯誤信息。故區塊鏈網絡中就需要設置某種機制來控 制錯誤信息寫入區塊鏈中。
目前,常用的共識機制主要有:
(1) Proof of Work(POW)機制[32]:工作量證明機制,這種機制規定如果某個節點需 要爭奪記賬權,它必須能夠自證完成了一定量的工作,為了保證“量”,工作往往是由 系統來確定,如果它能夠完成規定的工作并且大家檢驗之后發現它確實完成了相應的工 作,此時系統的其他節點應該認可它擁有這個區塊的記賬權,但是這種機制比較消耗能 源,因此很難大規模商用。
(2) Proof of Stake(POS)機制[33]:這種機制最早出現在點點幣中,它引入了一個新 的概念一一幣齡(CoinAge),即幣量乘以持有的天數。該機制規定,當某個節點擁有的幣 齡越大,它獲得記賬的概率越大。雖然這種機制不需要采用工作量來證明自己并非一個 “僵尸”節點,但是這容易形成“富者恒富”的局面。
(3) Delegated Proof of Stake(DPOS)機制[34]:該機制利用民主選舉去削弱POS機制帶 來的影響,它規定擁有代幣的人投票給固定的節點,由這些節點去推選代理人,再由代 理人負責驗證和記賬。它的出現大大降低了運算的需求,減少了能源消耗。
(4) POOL驗證池機制:它不同于以上三種機制,這種機制內并不含代幣,它是基 于分布式技術和數據驗證機制而設計的。
2.1.4Hyperledger Fabric網絡
由于本文實驗實現采用的區塊鏈環境為Fabric網絡,因此本節對Hyperledger Fabric中 的節點以及其作用進行簡單介紹[35]。
Fabric[36]中的節點一般包含客戶端節點、Peer節點,CA節點和0rder節點:
(1) 客戶端節點:客戶端一般也指應用程序,它是用戶最終操縱的實體或實體程 序,其一般無法直接與區塊鏈網絡產生交互,而是需要與一個Peer節點或0rder節點進行 連接才可與區塊鏈網絡產生交互。客戶端向EndorserPeer節點(背書節點)提交提案,當 EndorserPeer節點收集到一定數目的背書之后,則會向0rder節點廣播交易,之后再進行排 序,生成交易的區塊。
(2) CA節點:CA(Certificate Authority)節點是Fabric中的證書頒發節點,用于證明 操作用戶的身份。
(3) Peer節點:區塊鏈中的每個組織都可以擁有若干個Peer節點,以Peer節點承擔 的任務不同可以分為四種Peer節點:EndorserPeer節點、LeaderPeer節點、CommitterPeer 節點、AnchorPeer節點。其中,EndorserPeer節點也稱背書節點,這類節點會執行相關交 易方案并對執行的結果進行背書,LeaderPeer節點也稱主節點,這類節點主要負責與 Order節點進行通信,并從0rder節點處獲知最新的區塊,用來在組織內部進行同步。 LeaderPeer節點可以指定,也可以選舉產生。CommitterPeer也稱記賬節點,主要負責從 Order節點中接受區塊內的交易,然后判斷交易是否有效,如果有效,再將有效交易寫入 到其通道的副本中。AnchorPeer節點也稱錨節點,這類節點允許在一個通道(channel) 上被別的Peer節點發現,舉例說明:假設通道peerO有三個組織分別為org1,org2,org3, 其中每個組織的錨節點為peer 0.orgi, i e {1,2,3},如果org1的錨節點peer0.org1連接到了 org2的錨節點peer0.org2,而peer0.org2正好"知道"org3的錨節點peer0.org3,那么 peer0.org2 會告訴 peer0.org1 peer0.org3 在哪里,之后 peer0.org]可以直接與 peer0.org3 交 互。值得注意的是,每個Peer節點一定是記賬節點,除了記賬節點這一身份外,它也可以 擔任別的角色。
(4)Order節點:Order節點也稱排序節點,這類節點主要接收已經被背書過的交 易,并對未打包的交易進行排序,生成區塊并廣播給Peer節點,但這類節點并不會考慮區 塊內的交易是否具有合法性,它能決定的僅僅是處理交易的順序。
2.2密碼學基礎
2.2.1哈希函數
哈希函數也稱“hash”函數,它是一種可以將任意長度的輸入轉化成固定長度的輸 出的函數,其中,輸出一般也被稱為哈希(hash)值hl。哈希函數一般被形式化的描述成: hash(x) t y, x e {0,1}*, y e{0,1}"。在密碼學中,哈希函數應該具有如下特性:
(1) 單向性:對于輸入x,xe{0,1}*,我們可以計算出哈希值hash(x) = y,而給定哈 希值 y ,我們無法求出輸入 x 。
(2) 快速性:對于哈希操作而言,輸入越長,它形成哈希值的時間也越長,所以一 個優秀的哈希算法對于常規輸入的計算時間應在系統所允許的時間內。
(3) 抗碰撞性:對于輸入x,hash(x) = y,很難找x,x1豐x,使得h(xj = y。
(4) 敏感性:對于任意兩個輸入比特串x,兀,如果x和兀內容相差很小甚至只有某 一位發生變化,那么輸出也會存在很大差異甚至完全不同。
(5) 一致性:對于輸入x,x1,如果x = x1,則hash(x) = hash(x)。 正是因為哈希函數擁有以上特性,因此區塊鏈設計中常采用這種技術來驗證信息是
否被篡改。在比特幣中采用的就是SHA-256哈希方案[38]。
本文中使用到的哈希函數有SM3,接下來簡單介紹SM3算法[39]。
假定對長為l的比特串m進行哈希,其中I < 264,SM3的步驟分為3步:消息填充, 消息擴展、迭代壓縮。
在介紹SM3算法之前,先規定初始函數,分別如下:
( 1 )消息填充。
1 )在 m 末尾添加比特“ 1 ”;
2)再在末尾添加k個“0”,k為滿足l +1 + K三448(mod512)的最小非負整數。
3)再在末尾添加64位的比特串形成m,該64的比特串為l的二進制表示。
( 2 )消息擴展。
1)將消息m'按512比特切割分組:記m' = B⑼B⑴…B("宀,其中n = (l + k + 65)/512。
2) 將B()分為16個字W0W1W ;
3)設置計數 變量 j , j 從16 增加 至67, 單次步長 為 1 , 重復進 行 操作 :
W j P W一16 十化一9 十 W一3 «< 1 5))十 W一13 <<< 7)十化一6。 ,
4) 設置計數變量j , j從0增至63,單次步長為1,重復執行:W:= W十必+4。
( 3)迭代壓縮
1)按照(2)的第一步對消息m進行操作。
2)設置計數器i, i從0增至n-1,依次執行:V(i+1) = CF(V(),B(i)),其中CF為壓縮 函數,V⑼為 7380166f 4914b2b9172442d7da8a0600a96f 30bc163138aae38dee4db0fb0e4e 的256比特值。
其中CF函數具體過程如下:
a:設字寄存器 A,B,C,D,E,F,G,H ,中間變量SS1,TT1,SS2,TT2。 b: ABCDEFGHjV(i)
c:設置計數變量j , j從0增加至63,單次步長為1,依次進行以下操作: c 1 : SS1j ((A <<<12) + E + (Tj << j)) <<< 7
c2: SS2 j SS1 十(A <<<12) c3: TT1 j FF1 (A, B, C) + D + SS2 + W: c4: TT2jGGj(E,F,G)+H +SS1+Wj
c5:D jC
c6:C j B <<< 9
c7:B j A c8: A jTT1
c9:H j G
c10:G j F <<<19
c11: F J E
c2: E J P0(TT2)
d: K(i+1) JABCDEFGH^V(i)
3)輸出雜湊值y = V(n)。
2.2.2對稱加密技術
對稱加密技術出現的時間非常早,幾乎可以追溯到古羅馬時期。這種技術要求數據 在加解密時采用同一密鑰,因此如果要保證數據的安全性,則至少要保證兩點:
(1)加解密的雙方不能夠泄露密鑰。
(2)通信時,要保證密鑰傳輸信道的可靠性。
當然,做到以上兩點也未必就能保證密文不被解密出來,這還與算法自身,密鑰長 度等有關系。如今,在對稱加密領域中,分組加密技術尤為重要。大家熟知的DES、 3DES、國密SM4都采用了分組加密技術。由于本文采用了SM4加密技術,下面簡單介紹 SM4技術。
SM4算法主要由輪密鑰生成,數據加密,密文解密三個部分組成。設加密密鑰為 MK = (MK0,M&,MK2,MK3) e (Z;2)4,其中Z;為比特長度為n的二進制序列集合。
(1)輪密鑰生成:
1)設 系 統 參 數 值 FK0 = (A3B1BAC6),FK1 = (56AA3350), FK2 =(677D9197) , FK3 = (B27022DC);
2)計算(MK0 十FK0,MK、十F&,MK2 十FK2,MK3 十FK3) = (K0,{,K2,K3);
3)設置計數器i,i從0增至31,單次步長為1,分別計算:
毗=心+4 =心十L(z(Ki+h十Ki+h十Kg十CKJ),在該公式中:
a)CKi = (cki0, cki j, cki2.cki3) e (Z 2)4, cki j = (4i + j) x 7(mod256)
b)設輸入 A = (a0,a”a2,a3) e (Z2),則廠(A) = (Sbox(a0),Sbox(a1),Sbox(a2),Sbox(a3)), 記廠(A) = B。其中Sbox表如圖2-3所示。
c)L'(B) = B十(B <<<13)十(B <<<23)
4)輸出輪密鑰(rk0,rk[,…,rk31)。
(2)數據加密,設明文為(X0,耳X2,X3) e (Z22)4。
1)設置計數器i,i = 1,2,3…,31,分別計算:Xi+4 = X,十L(t(Xm十Xi+2十X,+3十rk)) ,在該公式中:
a)t函數與輪密鑰生成中第三步的廠函數一致。
b)L(B) = B 十(B <<< 2)十(B <<< 10)十(B <<< 18)十(B <<< 24)。
2)輸出密文為: (X35,X34,X33,X32)。
( 3)解密:
解密算法與加密算法一致,但輪密鑰為初始輪密鑰的逆序,即為(rk31, rk30,…,rk1)
2.2.3公鑰加密技術 公鑰加密技術也稱非對稱加密技術[42],公鑰加密與對稱加密最大的區別在于它的加 密密鑰和解密密鑰不同。公鑰加密最早的思想由James Ellis在1970年1月的一篇題為“非 秘密加密的可能性” 一文中提出的。之后,Diffie和Hellman在1976年提出了較為完整的 公鑰密碼體制[43],這也標志著公鑰密碼體制思想的正式形成,不過,他們兩個人并未提 出關于公鑰密碼體制相關方案。
公鑰加密的主要思想是利用公鑰加密,形成密文,再利用私鑰解密密文,形成明 文,具體過程如圖2-4。
PubBob Pr i Bob
Alice 明文M 密文C 明文M Bob
圖2-4 公鑰加密示意圖
下面,我們以Alice發送消息給Bob進行舉例,具體說明公鑰加密相關流程。
(1) Bob產生公私鑰對PbBob和PiBob,其中,公鑰為PbBob,私鑰為PiBob。
(2) Bob將PbBob公開,并保留PiBob。
(3) Alice利用PbBob對明文M進行加密得到C ,即計算:Enc(PbBob, M) = C ,并 將C發送給Bob。
( 4 ) Bob 在 獲得 密 文 C 后 , 利 用 PiBob 進 行 解 密 得 到 明 文 M , 即 計 算 :
Dec(PiBob,C)=M。
常見的公鑰加密方案大多根據某一數學問題求解困難設計而成。常見的困難性問題 有三種:
(1) 大數因數分解問題[44]:設已知a, 0均為大素數,計算a*fi = m容易,而已 知m ,推導出m = a*0困難。RSA加密體制就是基于這一困難性問題設計而來。
(2) 離散對數問題[45]:由于并非所有的離散對數困難問題求解都很困難,因此,如 果基于此類困難問題來設計密碼方案需要選擇合適的群G。設乘法群(G,?),一個n階元 素ae G和元素0e〈a〉,此困難性問題被定義為:找到一個整數a , 0 < a < n -1 ,滿足 a= 0是困難的。經典的ElGamal[46]算法就是基于此假設設計而成。
(3 )橢圓曲線上的離散對數問題[47]:取橢圓曲線上某點G為基點,如果已知 k,k e Z ,求解K = kG是容易的,而已知K,卻難以求解k。相對于基于大數分解困難性 假設而設計密碼方案,基于橢圓曲線上的離散對數困難設計的密碼方案能實現在同等加 密安全程度上,使用的密鑰長度更短。例如:SM2算法采用256位密碼的安全性高于RSA 算法的2048位密碼。
由于本文主要使用到的國密公鑰加密算法為SM2, SM2算法主要由三部分組成,分 別是密鑰生成、加密、解密。以用戶A向用戶B發送消息明文M為例,具體解釋如下:
(1) 密鑰生成。SM2生成密鑰對的過程如下:
1) 定義素域Fp ( p為不低于5的素數)上的橢圓曲線為y: =x3 + ax + b ,其中 a,b e Fp且(4a? + 27b2)modp豐0 ,記該橢圓曲線上有理點(含無窮遠點)組成的集合為 E(Fp)。
2) 選取點G為E(Fp)上的基點,G = (xG,yG),其中xG,yG eFp ,并規定n為G的 階。
3) 用戶B的私鑰為dB , d e[1, n - 2],其中n為G的階。
4) 獲取用戶B的公鑰PB , PB = [dB]G = (xB,yB)。
(2) 加密。加密過程如下:
1) 選取隨機數k e[1, n -1];
2) 計算G = [k]G =(兀,必),并將G的數據類型轉為比特數據類型;
3) 計算S = [h]PB = (x2,y2),如果S為無窮遠點,則報錯并終止加密算法的執行,其 中,h = m /n , m 為 E(Fp)的階;
4) 將x2,y2的數據類型轉為比特數據類型;
5) 計算/ = KDF (x2|| y2, klen),如若t全0,則重新執行加密算法,其中klen為M比 特長度;
6) 計算 C2 = M 十 t ;
7) 計算C3 = Hash(x2 ||M || y2);
8) 發送密文C = C1|| C3|| C2。
(3)解密。解密過程如下:
1) 取出C中的比特串C1,將C1轉為E(Fp)上的點,并驗證C1是否滿足設置的橢圓曲 線方程,如果不滿足,則報錯并終止解密算法的執行;
2) 計算S = [h]C1,如果S為無窮遠點,則報錯并終止該算法的執行;
3) 計算d]C1 =(D,y2),并將x2,y2的數據類型轉為比特數據類型;
4) 計算t = KDF(x2 || y2,klen),若t全0,則報錯并終止該算法的執行;
5) 取出C中比特串C2,計算M' = C2十t ;
6) 計算u = Hash(x2 || M' || y2),從C中選取C3,如果u豐C3,則報錯并終止該算法。
7) 輸出明文M'。
2.2.4數字簽名技術
數字簽名類似于物理簽名,它的作用是保證簽名的一方對其簽署的內容進行信任背 書[40]。但數字簽名并非物理簽名的圖像化,它使用了公鑰加密和哈希函數兩種技術手段 來實現,以保證簽名的不可否認性和難偽造性。
下面以用戶A (假設A的公私鑰分別為PbA, PiA)對文件M簽名并發送給用戶B , 用戶B驗簽為例具體說明:
(1) A對文件M進行哈希運算Hash(M) = sum , sum為M的文件摘要。
(2) A進行私鑰簽名計算sig(sum,PiA) = Dig ,其中Dig為數字簽名。
(3) A 發送M,Dig 給B。
(4) B進行驗證計算ver(PbA,Dig,M),如果計算結果為1則驗證成功,如果計算結 果為0,則驗證失敗[41]。
常見的比特幣應用就是利用數字簽名技術以保護交易的正常運行。數字簽名運行過 程如圖2-5所示。
圖2-5 數字簽名過程
2.3系統開發技術
2.3.1Springboot
Springboot[48]是用來簡化Spring開發過程的新框架。相對于Spring框架,它主要的特 性有以下方面:
(1) 可以直接建立java項目,使用時直接打成jar包,無需其他操作。
(2) Springboot提供了 .pom文件來簡化Maven的配置。
(3 )不同于Spring, Springboot在其應用程序中內置了 Servlet容器,這就使得 Springboot項目不需要以war包的形式來部署。
(4) Springboot可以對基于http等協議的項目進行實時監控。
(5) 不需要編寫大量代碼來實現Spring的配置,而是通過條件注解來實現的,即不 需要通過xml配置即可實現Spring的配置。
2. 3. 2 MCV模式
MVC是軟件設計中的一種架構模式,這種模式將軟件系統劃分為三個最基本的部 分:模型(Model)、視圖(View)以及控制器(Controller) [49]。其中模型層負責程序 功能的實現,數據庫的管理和設計等功能,視圖層負責界面設計,控制層負責邏輯處 理,轉發請求等功能。以下是三種組件的互動內容:
(1) 模型(Model):模型層可以對數據進行直接訪問,尤其是對數據庫的訪問。 它的運行不依賴視圖層和控制層,即它不去關心它會以何種形式被演示或操作。但是模 型層種的數據變化需要通過某種刷新機制被顯示,為了這種機制的實現,視圖層需要預 先再模型層上注冊,只有這樣,視圖層才可以了解模型層上的改變。
(2) 視圖(View):視圖層也稱界面層,它負責將后臺或者數據庫的數據顯示到前 臺。在視圖層中并不會涉及到程序的邏輯問題,因此為了實現視圖層的更新功能,視圖 層需要監視模型層。
(3) 控制器層(Controller):由于從模型層取得數據較為“原始”,而界面層是豐 富多彩的,因此需要一個中間層去處理這些數據,使得數據符合項目邏輯或其他要求, 從而讓數據更好的為界面層所用。
MVC的優點在于其耦合性較低,因此比較利于開發,也利于以后的升級換代,但是 對于小型系統使用MVC模式不僅不會降低工作量,反而會帶來一定量的工作量。
2. 3. 3 Docker容器技術
在過去,一個產品從研發成功到順利上線,需要對操作系統,運行環境,應用配置 等都做出相應的操作,這就使得一個產品的生命周期較長,而產品版本更迭升級之后, 更是要做出大量的修改。但Docker容器的出現,給這一現象提供了一個解決方案。
Docker容器技術與其他的容器技術相同,是一種虛擬化方案[50],與傳統意義上的虛 擬機不同,Docker可以直接運行在操作系統上,因此某個軟件可以利用這一特性將原本 運行的環境也復制到新的系統中。Docker容器技術打破了過去常見的“僅在開發者機器 上可以工作”的局面。因此,本系統采用Docker容器技術,加強系統的可移植性。
2.4本章小結
本章主要介紹了有關系統開發的部分基礎知識。一開始,本章介紹了區塊鏈的基礎 知識和有關技術,如智能合約。接著,對本文核心亮點密碼學進行了部分介紹,主要介 紹了公鑰加密等相關知識。最后對系統實現所需要的相關技術進行了簡單介紹,為后面 幾章的內容做了一個技術層面的鋪墊。
第 3 章 基于區塊鏈的養老信息管理平臺的系統設計
本文設計的系統主要解決老人信息管理權的錯位問題和數據隱私安全問題,考慮到 直接實現該系統具有一定的困難,因此,本章首先給出需求分析,再根據相關需求分析 給出平臺總體設計,然后再介紹每個模塊的設計方案,最后,對智能合約的數據結構設 計和功能設計做出有關說明。
3.1需求分析
傳統的養老信息管理平臺具有不少痛點,如:存在數據壁壘,隱私數據容易被篡 改或竊取,數據擁有主體不清等。針對這些痛點,新的系統應當滿足加密性、去中心 化等特性,因此本文將區塊鏈技術與養老系統相結合,設計出基于塊鏈的養老信息管理平 臺并對平臺的需求分析和系統架構進行闡述。
一個優秀的系統離不開優秀的系統設計,而系統設計中最核心的部分就是需求分 析。需求分析通常分為功能性需求分析[51]和非功能性需求分析[52],功能性需求分析指的 是系統應當實現哪種功能,達成什么樣的目的。而非功能性需求分析指的是功能以外的 標準,比如響應速度等。
3.1.1功能性需求分析
本文所設計的養老系統與傳統的養老系統最大的區別在于養老信息的所有權不再歸 于養老機構。因此,在本系統中,主要角色對象是老人,而養老機構只有查看信息的權 限,并沒有修改或者其他權限。而老人信息與一般信息不同之處在于,他們的信息中包 含了個人隱私,因此必須對老人信息進行加密,可機構作為服務者,也必須對老人的部 分信息具有知情權,故本文為了平衡這種矛盾,將老人的信息分為隱私信息和一般信 息,其中,對于隱私信息采用SM2加密,對于一般信息采用SM4加密。本系統實現功能 如下:
(1) 準入控制功能:與一般的系統不同,由于本系統對于信息審核功能采用拜占庭 算法,如果按照傳統機構所設計的“申請即可入”這一模式,那么攻擊方只需不斷申請
“人頭” ,就可以輕易實現對系統的破壞,因此本系統中申請注冊對象需要經過系統在 冊老人總數的1/2及以上才可以申請成功。
(2) 信息上傳功能:平臺用戶可以在系統中傳入相關信息(包括隱私信息和一般信 息),但是上傳之后不會立即寫入區塊,需等待有節點為其背書之后,方可寫入區塊。
(3) 數據加密功能:將老人數據分為隱私數據和一般數據,其中隱私數據利用國密 SM2算法進行加密,一般數據利用SM4算法進行加密。
(4) 驗證功能:對于某一用戶提出的數據上傳申請,系統內部人員可以通過審核明 文或驗證身份的方式來決定是否同意其數據上傳的申請。
3.1.2非功能性需求分析
非功能性需求雖然不同于功能性需求,它不局限于某些“硬性”功能的實現,但它 對于一個系統的生命周期和市場接受度有著很大的關系,例如:
(1)響應時間:由于系統的開發采用的是前后端分離模式,數據從前臺傳過來之后 還需要進行加密操作,加密之后,再調用SDK與區塊鏈進行交互,然后才寫入數據庫。 而類似于MySq 1等關系型數據庫具有交互快等特點,因此利用此類數據庫可以在極大程度 上降低交互時間。
(2)頁面外觀:本系統為養老系統,因此用戶多為老年人,所以系統界面應該設計 得盡量簡單且具有邏輯性,以保證老人可以在短時間內進行上手操作。在此基礎之上, 還需考慮字體大小,顏色護眼等需求。
(3)耦合度:耦合度的高低本質上并不會影響系統的體驗,甚至高耦合度的系統在 響應時間上還快于低耦合度的系統,但是一個系統往往要面臨更新換代,因此對于一個 系統而言,過高的耦合度勢必不利于系統的升級或修改,故系統在設計的時候往往應該 盡量保持低耦合度。而常見的Fabric網絡則是“可插拔”式的網絡,利用此網絡開發可有 效降低其耦合度。
3.2系統總體架構設計
常見的系統分為B/S架構和C/S架構,考慮到系統的易用性和開發的便捷性,本文所 設計的基于區塊鏈的養老信息管理服務平臺采用B/S架構,并將架構分為三層,如圖3-1 所示。
圖3-1 系統架構設計圖
由圖3-1可見,本文系統架構分為瀏覽器、Springboot框架的服務器端以及數據庫三 層。下面介紹該三層的具體情況:
(1)瀏覽器:瀏覽器是用戶與系統打交道的最頂層,屬于系統的界面層。由于本系 統采用的框架在底層封裝了jQueryl53],因此可以用JavaScript直接開發。此外,對于數據前 后臺交互,本系統采用ajax技術進行異步更新,這可以讓網頁不重新加載的情況下進行數 據更新。
(2) Springboot框架:Springboot是一種快速開發網頁的框架,本文采用Springboot+ MVC的模式進行開發。采用這種模式的最主要原因是可以將項目直接打成jar包直接運行 在Docker容器中。MVC也稱三層模型。第一層為模型層,主要定義實體,第二層為控制 層,這一層的功能最為豐富和多變,主要負責邏輯處理,第三層為視圖層,也叫界面 層,主要負責將內容填充到htm 1網頁中并傳給瀏覽器,由瀏覽器顯示出來。
(3) 數據庫系統Database:數據庫系統分為兩塊,一塊是Mysq 1數據庫,用來存放用 戶有關數據,一塊是區塊鏈網絡,當用戶上傳數據時,會對數據進行審核,只有審核人 數到達一定比例時才可以傳入區塊鏈網絡中。
3.3系統功能模塊設計
3.3.1系統總體設計
根據前文分析,基于區塊鏈的養老信息管理平臺從用戶使用角度分為兩大模塊:用 戶模塊和系統模塊。具體功能設計如圖3-2所示。
圖3-2 功能設計
3.3.2用戶模塊設計
用戶模塊又分為用戶數據和數據審核兩個功能模塊,用戶數據模塊主要實現以下功 能:
(1) 用戶登錄:用戶在進入系統時,需要提供已經被創建的用戶的賬號密碼以確認 其有權進入系統進行數據查看等操作。
(2) 用戶注冊:用戶第一次進入系統,并沒有賬號和密碼,因此應當允許用戶進行 注冊。
(3) 隱私數據查看:用戶可以查看自己所的隱私數據,對于他人的隱私數據只能查 看到密文。
(4) 個人數據上傳:可以上傳個人的一般數據和隱私數據,其中隱私數據用私鑰加 密,一般數據用對稱密鑰加密。
(5) 一般數據查看:用戶可以查看自己的一般數據。 數據審核模塊主要實現以下功能:
(1) 用戶審核:為了防止惡意的第三方發起“人頭”攻擊,因此對于申請的用戶必 須要經過在冊同戶的審核,只有達到比例時,才為其在區塊鏈網絡上進行注冊。
(2) 一般數據審核:由于一般數據并不像隱私數據那樣“敏感”,因此對于一般數 據,系統給出明文,由用戶審核,當達到比例時才可以寫入。
(3) 隱私數據審核:隱私數據不同于一般數據,它不應在沒有數據所有者的同意下 而顯示出明文,但上鏈又需要有用戶為其背書,因此本系統利用簽名算法以驗證隱私數 據是否來自于系統內部成員。
如圖3-3所示,本系統中的用戶初始并沒有賬號密碼,因此必須要先注冊,為了防止 用戶惡意注冊,本系統注冊的用戶會先寫入數據庫,但并不會立即寫入區塊鏈,如果本 系統中同意其申請通過的用戶數目在達到系統在冊人數總數的1/2及以上的時候,才可以
通過智能合約為其在區塊鏈上注冊身份,并為其分配私鑰,公鑰和對稱密鑰。
數據庫
圖3-3 用戶注冊與登錄
當用戶登入系統后,可以上傳信息,不過上傳的信息分為隱私信息和一般信息,隱 私信息應采用SM2加密手段進行加密,私鑰由用戶本人保管,一般信息則會采用SM4加 密手段進行加密并將此對稱密鑰共享給其所在的管理機構。
對于隱私數據,由于其并非是需要經常修改的信息,因此對于隱私數據,在采用加 密技術之后,會立即將密文數據存入數據庫中,但并不會立即上傳至區塊鏈中。因為, 老人難免會填錯數據,如果立即上傳至區塊鏈中,則會對區塊鏈網絡帶來額外的空間上 的消耗,故本系統需要統計愿意為該信息背書的人。對于數據上鏈這一功能的實現需要 通過后續的審核功能才可以,如圖3-4所示:
圖3-4 用戶上傳傳隱私數據
而對于一般數據,機構需要用其為用戶進行服務,因此,必不可免需要提供給機 構。此外,在一般數據中,大部分數據(如體檢指標)是需要定期修改的。因此,對于 一般數據而言,如果采用SM2加密方法,一來會帶來時間上的巨大開銷,二來SM2加密 后的密文要長于SM4加密后的明文,綜合考慮,對于這部分數據,我們采用SM4加密方 案。如圖3-5所示:
本系統的隱私數據和一般數據的審核功能是為了統計愿意為信息背書的人員名單, 因此統計的人數大于區塊鏈網絡在冊人數的2/3時才可以,需要注意的是,可以背書的人 也必須是區塊鏈網絡在冊人員,否則無法背書。以A用戶舉例,A用戶如果上傳信息,信 息會立即進入數據庫的審核列表中,當背書的人到了2/3人數時,數據會從審核列表中進 入已通過審核列表中,并開始調用相關代碼,執行數據上鏈操作,但是與之對應的是, 拒絕的人數如果超過了系統在冊人數總數的1/3時,則該信息直接被刪除,無需其它人繼 續審核該數據,從而降低系統開銷。
用戶功能模塊的Springboot后臺具體方法如下:
表3-1 用戶功能函數表
函數名 參數類型 說明
Addtesto1d() Testo1d 注冊用戶
Logincheck() String,Session 用戶/機構登錄核實
Getpridata() Integer 獲取隱私數據
Getpubdata() Integer 獲取一般數據
Addpridata() Integer 上傳隱私數據
Addpridata() Integer 上傳一般數據
Checktesto1d() Integer 審核用戶信息
Checktestpri() Integer 審核隱私數據
Checktestpub() Integer 審核一般數據
3.3.3機構模塊設計
機構管理模塊有機構登錄,機構注冊,一般數據查看三種功能,具體功能解釋如 下:
(1) 機構登錄:機構用戶在登錄時,與普通用戶一樣,也需要通過賬號和密碼的測 試才可以進入系統進行其余操作。
(2) 機構注冊:當某個新的機構用戶想使用本系統時,需要按表格填寫相關數據, 填寫完成之后,注冊成功。
(3) 一般數據查看:機構只可以查看本機構用戶的一般數據。
當機構用戶第一次進入本系統時,由于其在數據庫中沒有信息,因此他無法進入系
統,此時,用戶可以自行選擇注冊機構用戶,需要注意的是,機構用戶與普通用戶不 同,由于其權限低,且不能參與系統維護,因此其注冊的信息只需要進入數據即可,不 必調用SDK碼為其在區塊鏈網絡中注冊身份。如圖3-6所示:
盡管在本系統中,機構用戶的重要程度不如普通用戶,因為其權限相對有限,但是 出于系統安全考慮,也不應在數據庫中存儲其密碼明文,所以也應當用哈希的手段將其 口令映射化。
最后,對于機構用戶的查看一般數據功能,它只能看屬于它的用戶的一般數據,且 由于機構用戶擁有自身名下每個用戶的對稱密鑰,因此機構用戶可以直接看到一般數據 的明文。考慮到商業競爭關系,即便某個機構有其他機構用戶下的普通用戶的對稱密 鑰,它也無法看到該普通用戶的一般數據,因為系統不會為其提供密文。舉例:假使機 構A知道機構B下的用戶C的對稱密鑰,機構A也看不到用戶C的一般數據。
機構功能模塊的Springboot后臺具體方法如表3-2:
表3-2 機構模塊后臺功能函數表
函數名 參數類型 說明
Addtestorg Testorg 注冊機構
Logincheck() String,Session 用戶/機構登錄核實
Getpublist() PageIn 獲取一般數據列表
3.4智能合約設計
智能合約的設計體現在Hyperledger Fabric中主要就是鏈碼的設計。鏈碼是一種安裝在 Peer節點上的程序,一般的Hyperledger Fabric中的鏈碼是由Go語言編寫的,而如果利用其 他語言(如java, JavaScript等語言)調用相關鏈碼一般需要對應的Fabric-SDK作為接口。
在養老信息管理平臺中,智能合約的功能主要體現在由客戶端使用SDK對區塊鏈賬 本進行更新與查詢的過程中。智能合約設計的相關功能有:用戶的注冊,隱私數據和一
般數據的上傳,查詢等。
3.4.1鏈碼數據結構設計
在設計智能合約之前,應該先對系統中的用戶和有關數據進行數據結構的設計。對
于用戶而言,ID是其唯一身份標識,因此ID不可以由用戶自定義生成。其余數據由用戶 自行定義,通過前端獲取。用戶鏈碼數據結構設計具體如下表:
表3-3 用戶鏈碼數據結構設計表
字段 數據類型 含義
Id String 用戶的唯一 ID標識
Account String 用戶自定義賬號
Name String 用戶自定義姓名
Sex String 用戶性別
Pwd String 用戶自定義密碼
Orgid String 用戶選擇的機構的ID
Pub String 系統為用戶分配的公鑰
Ikey String 系統為用戶分配的對稱密鑰
對于隱私數據而言,其包含的用戶信息一般而言是比較重要且不太經常需要修改的 消息。針對隱私數據設計的數據結構如表3-4所示。其中,Prild是每個隱私數據的唯一標 識,Oldid代表了這個信息屬于哪位老人,其余為單獨設置的一些隱私數據類型。
表3-4 隱私數據鏈碼數據結構設計表
字段 數據類型 含義
PriId String 隱私數據的唯一 ID標識
Oldid String 用戶的唯一 ID
Cid String 用戶身份證號碼
Phonenumber String 用戶手機號碼
Contact String 用戶自定義緊急聯系人
CPhone String 緊急聯系人手機號碼
對于一般數據而言,其包含一般是用戶需要經常修改或者上傳的信息,而區塊鏈是 不可篡改的,存入區塊鏈中的數據也不會被刪除,因此為了減少數據和時間的開銷,我 們對一般數據的加密方案做了一些修改,即使用對稱加密技術將前臺將一些信息存入區 塊鏈網絡中。具體一般數據結構體如表3-5所示。
表3-5 一般數據鏈碼數據結構設計表
字段 數據類型 含義
PubId String 一般數據的唯一 ID標識
Oldid String 用戶的唯一 ID
Pressure String 用戶血壓
Sugar String 用戶血糖
Acid String 尿酸
3.4.2智能合約功能設計
智能合約的設計主要在于鏈碼上各個函數的設計。鏈碼中最重要的函數有兩個,分 別是Init函數和Invoke函數。Init函數是鏈碼實例化時會用到的函數,一般用來進行初始化 操作。Invoke函數并非某具體系統功能函數,而是一種調用函數。智能合約中所有函數的 調用都是通過Invoke方法調用其函數名實現的,即Invoke方法的參數就是其他方法的函數 名。除了這兩個函數之外,本系統還要設計別的函數功能,如查詢用戶、查詢隱私數 據、上傳隱私數據等,如表3-6所示。
表3-6 智能合約方法列表
字段 參數 含義
Init() - 鏈碼初始化
Invoke() 函數名 調用其他函數
QueryOld() Id 查詢用戶
QueryPri() PriId 查詢隱私數據
QueryPub() PriId 查詢一般數據
AddOld() OldId,Info 注冊用戶
AddPub() PubId,Info 添加一般數據
AddPri() PriId,Info 添加隱私數據
由于本文中的智能合約主要用來與Fabric網絡進行交互,因此下面主要介紹本文設計
的系統如何通過鏈碼解決數據壁壘問題。
如果所有機構都采用本系統的軟件并誠實上傳數據,則數據壁壘不會存在,但鑒于 部分非誠實的機構可能會對系統做出部分修改,故而導致了數據壁壘的存在。對于壁壘 的存在大致有兩種可能,一是數據格式不對,二是數據字段不同。本系統在鏈碼設計中 為系統的隱私數據和一般數據都設置了相應的數據結構,用戶無法通過智能合約的上傳 功能上傳不同的數據類型。此外,為了避免數據格式的錯誤,我們不僅在前端進行了數 據格式的限制和提示,也利用了用戶審核來盡可能的避免該問題的出現。
3.5本章小結
本章以不同用戶的視角,將基于區塊鏈的養老信息管理平臺的系統功能分為普通用 戶模塊和機構用戶模塊并對每個模塊中的功能進行了簡單的分析與設計。之后再對智能 合約的數據結構和功能模塊進行了設計。
第 4 章 基于區塊鏈的養老信息管理平臺的實現
本章針對上一章節的需求分析與系統設計,完成并實現了有關功能。本章主要對系 統的每個功能和模塊進行了具體的介紹,并給出相應的效果圖。其中對于上一章節的絕 大部分功能都有介紹,但對于部分技術手段較為重復的功能不過多敘述。
4.1SDK開發
為了使養老信息管理系統能夠與區塊鏈網絡進行交互,系統必須采用Hyperledger- Fabric 官方發布的第三方接口來實現有關功能。由于本系統在PC端上的界面和功能是基于 SpringBoot框架實現的,因此我們使用java版本的SDK[54]進行開發。該SDK可以幫助Web 后端來管理區塊鏈網絡中的通道和智能合約,通常的功能包括創建Channel、安裝和實 例化合約、注冊用戶,實例查詢等。具體交互如圖4-1所示。
圖4-1 區塊鏈交互示意圖
4.1.1Fabr i c證書注冊和登記用戶
對于任意一個系統而言,注冊和登記用戶功能都是十分重要的。一般添加用戶時, 需要向其授發證書。證書授發的形式有很多種,本系統中采用的是第三方證書,下面以 添加用戶名為“chenmingquan"的用戶為例,提供相關示例代碼。
代碼如下:
//獲取CA
FabricCAClient caClient 二 new
FabricCAClient("http://192. 168. 70. 42", null);
//添加用戶
UserContext register = new UserContext ();
register. setName("chenmingquan"); register. setAffiliation("org1");
//設置操作用戶
Enrollment enrollment 二 caClient.enroll("admin", "adminpw"); UserContext registar = new UserContext();
registar. setName("admin"); registar. setAffiliation("org1");
//賦予操作用戶證書
registar. setEnrollment(enrollment);
//注冊用戶
String secret 二 caClient.register(registar,register);
4.1.2SDK調用智能合約
智能合約的存在是為了方便用戶操作圖形界面與區塊鏈網絡打交道,但是目前很多 圖形化的界面都是由java語言開發,一方面是因為java語言開發簡潔,另一方面,是因為 java語言有良好的跨平臺性。因此,為了本系統的開發的兼容性,系統選擇的界面開發語 言為java。但是,Fabric天然就支持Go語言的開發,因此,為了魚和熊掌兼得,系統的開 發必然要用SDK來調用智能合約。下面,以查詢鏈碼為例,展示SDK調用合約的過程。
//獲取通道名
Channel channel = getChannel (channelName);
//獲取所有待查詢的Peer節點
for (Peerp : peers) {
channel. addPeer(p);
}
channel. initialize();
HashMap map = new HashMap();
//設置查詢方法對象
QueryByChaincodeRequest queryByChaincodeRequest 二
hfClient. newQueryProposalRequest();
ChaincodeID. Builder builder =
ChaincodeID. newBuilder(). setName (chaincodeName); queryByChaincodeRequest. setChaincodeID(builder. build()); queryByChaincodeRequest. setArgs(args);
//合約功能名
queryByChaincodeRequest. setFcn(funcName);
4.2用戶模塊
4.2.1用戶注冊功能
用戶注冊功能流程圖如圖4-2所示。
圖4-2 用戶注冊流程圖
注冊功能主要分為以下幾步實現:
(1)用戶通過前端點擊注冊,之后進入注冊界面,在注冊界面需要填寫有關信息,
填寫完成之后點擊注冊按鈕即可。注冊界面如圖4-3所示。
圖4-3 用戶注冊表單
(2)用戶填寫完注冊內容以后,系統會將表單發送給服務器,服務器會監聽傳來的 POST請求。
(3)根據請求尋找對應的處理方法,在方法中,首先要判斷該用戶注冊的賬號是否 已經存在,如果存在則提示您注冊的賬號已存在,如果不存在則進行下一步。如圖4-8所 示。
(4)調用SM2算法的公私鑰生成算法,為用戶分配相應的公私鑰對。
(5)調用SM4密鑰生成算法,并將密鑰存儲至數據庫中。
(6)將用戶填寫的密碼利用SM3算法進行哈希之后存入數據庫之后,注冊成功。關 鍵代碼如下所示:
//產生公私鑰對的拼接
SM2KeyV0SM2Key = securityTestAll. generateSM2Key();
String key=sm2Key. getPriHexInSoft()+"|"+sm2Key. getPubHexInSoft ();
System. out. println(key);
St ring [] s=key. spl it ("\\ | ");
if (t es t. get Sex (). equals ("0")) {
test. setSex("男");
}
else {
t es t. set Sex ("女");
}
test. setPri (s [0]);
test, set Pub (s[l]);
St ring oldid= (S tring)session.ge tAtt rib ut e ("oldid");
test_pridata testPridata二new test_pridata();
testPridata. setOldid(Integer. parseInt(oldid));
testPridata. setPri (s [0]);
test Prida ta. set Pub (s[1]);
//插入SM4算法生成的密鑰
test. setlkey (securityTestAll. generateSM4Key());
//生成簽名,他人審核隱私數據時需要使用
String s1="I LOVE Y";
St ring s2 = Util. byteToHex(s1. getByt es ());
SM2SignVO sign =securityTestAll. genSM2S/gnature(s[0], s2); test. setSgin(sign. getSm2_signForSoft ());
//添加用戶
test_oldService. addtest(test);
4.2.2用戶登錄
用戶進入系統前需要進行身份驗證,一般稱之為登錄。用戶登錄的流程圖如圖4-4所 示。
I
否
數據庫對比轄
是
是
蚣系統
()v
圖4-4 用戶登錄流程圖
用戶登錄功能分為以下幾步:
(1)進入系統之后,系統會提示有信息提供,用戶需要根據指定信息進行填寫。如 圖4-5所示。
圖4-5 用戶登錄界面
2)如果不填寫直接點擊登錄,會進行提示“請輸入賬號或密碼”。
(3)填寫完成后,會將填寫的密碼進行SM3哈希并與數據庫中的內容進行比對。比
對成功后進行下一步。
(4) 比對成功之后,獲取該用戶的信息,將用戶的ID作為參數調用查詢SDK方法, 查詢區塊鏈中是否存在此人。如果存在則進行下一步。
(5) 將區塊鏈中查詢的用戶與數據庫中的用戶進行比對,一致則進入系統,不一致 則無法進入系統。系統如圖4-6所示:
圖4-6 系統界面圖
圖4-7 查看隱私數據流程圖
查看隱私數據功能的流程圖如圖4-7所示。
(1)用戶登錄之后,會利用Session記錄用戶的ID,在用戶查看隱私數據的時候,要 先獲取到該Session的內容。
(2)獲取完之后,通過該Session去獲知當前請求用戶的ID,并將該ID作為調用的 SDK方法的參數,由該SDK方法調用Query方法查詢數據,查詢之后獲得的內容是密文。 相關智能合約代碼為:
//查詢功能
func (t *testold) querytestold(stub shim. ChaincodeStublnterface, args []string) pb.Response{
if(len (args)!=1) {
//返回錯誤信息
return shim. Error("except one arg")
}else{
value, err :=stub.GetState(args[0]) if(err!=nil){
shim. Error("no data found")
}
//返回成功信息
return shim. Success(value)
}
}
3)從后臺返回密文后,不會立即展示到前臺,而是需要獲取用戶的私鑰對其解
宓
uLj o
4)解密成功則將解密后的明文顯示在表單中,如果解密失敗,則顯示由錯誤私鑰
計算得來的亂碼。具體顯示成功頁面如圖4-8所示:
私有數據列表
圖4-8 用戶查看隱私數據
4.2.4上傳隱私數據
添加隱私數據功能的流程圖如圖4-9所示,
具體過程為:
(1)用戶點擊上傳數據之后,會顯示上傳表單,用戶需要按照提示輸入相關數據, 上傳界面如圖4-10所示。
(2) 如果用戶沒有輸入,則會提示他“數據不為空”。如果全部輸入之后會進入到 下一步。
(3) 用戶點擊了保存按鈕之后,會調用Controller層的上傳方法,之后會通過登錄的 Session獲取數據庫中的用戶信息。
(4) 根據用戶信息的公鑰對上傳的數據進行SM2加密。
(5) 將加密之后的密文存入數據庫中。其中關鍵代碼如下所示:
//數據上傳
//獲取Sessi on
St ring oldid= (S tring)session.ge tAtt rib ut e ("oldid");
//獲取老人信息
test_old testOld二testOldService. findtest(Integer. parselnt(oldid));
//SM2加密
String phone=
com. book. manager. util. encryp t. test.write. Enc( testO ld. get Pub (), test. get Phon enumber ());
St ring cid=wr ite. Enc( testO ld. get Pub (), test.get Cid());
St ring person=wr ite. Enc( testO ld. get Pub (), test.get Person ());
St ring perphone二wr ite. Enc( testO ld. get Pub (), test. get Perphone ());
//設置數據內容
test. setOldid(Integer. parselnt(oldid));
test. set Pub (testO ld. get Pub ()); test.setPri (testOld. getPri ());
test. setPhonenumber (phone);
test. setCid(cid);
test. setPerson(person);
test. setPerphone(perphone);
4.2.5上傳一般數據
圖4-11 上傳一般數據流程圖
上傳隱私數據的流程圖如圖4-11所示。具體過程如下:
(1)用戶點擊上傳一般數據,之后會一般數據表單,用戶需要按照提示填寫相關數 據。
(2)填寫完成之后,會判斷用戶是否填寫有關信息,若用戶沒有填寫信息,則會提 示“信息為空”。如果按照提示正確填寫之后則會進行下一步。
(3)讀取用戶的對稱密鑰,對信息利用SM4算法進行加密,加密的關鍵代碼如下所 示。
//對稱秘鑰加密(ECB)
public static String SM4EncForECB(String key, String text) {
SM4Utils sm4 = new SM4Utils();
sm4. secretKey = key;
sm4. hexString = true;
String cipherText 二 sm4. encryptData_ECB(text);
return cipherText;
}
( 4)加密之后,將密文存入數據庫。
4.3機構用戶模塊
由于機構用戶在實際中需要經常更新數據表單,因此機構用戶的操作都僅僅與數據 庫打交道。其中,部分功能的實現方式與之前的用戶模塊的功能類似,對于這部分功 能,不再贅述。
4.3.1機構注冊
機構登錄的流程圖如圖4-12所示。具體過程為:
(1)用戶點擊注冊之后,可以選擇注冊為機構用戶,具體截圖如圖4-13:
養老系統后臺登錄
沒有嗨?注冊T
圖4-13 機構登錄界面
(2)即用戶選擇狀態為“管機構”時,點擊注冊即可跳入注冊界面,之后按照提示 填寫表單。
(3)表單填寫完畢之后,點擊注冊,之后觸發scrpit腳本,判斷是否填寫完整,如果 填寫完整,則進入下一步。
(4)利用ajax技術發送POST請求,根據相關方法連接數據庫,查找是否已經存在表 單中填寫的賬號。如果存在,則直接提示“賬號已存在”,然后返回登錄界面。
( 5)如果不存在,則插入數據庫,并提示“添加成功”。關鍵代碼如下:
type : "POST",
contentType: "application/json;charset=UTF-8",
//請求地址
url : "/test/add",
//數據,json字符串
data : JSON. stringifyjson),
//請求成功
success : function(result) {
console. log (result);
//獲取集合屬性
var data = result. data;
var code = result.code;
if (code == 200) {
javaex. message({
con tent :"添加成功",
type : success
});
//跳轉至列表
set Timeout (func ti on() { window. loca ti on. href="/login";}, 1500)
}
},
4.3.2一般數據查看
圖4-14 機構一般數據查看流程圖 機構用戶可以查看選擇了它的所有用戶,功能流程圖如圖4-14所示。具體過程如 下:
(1)機構用戶登錄之后,會將其Id放入名為“org”的Session之中,之后通過讀取 Session 獲取該ID。
(2)連接數據庫,在數據庫中查找所有在該機構的用戶的一般信息。
(3)依次利用每位用戶的對稱密鑰進行解密,并返回結果列表。關鍵代碼如下所 示:
List<test_pubdataOut〉 testOuts = new ArrayList<〉();
//逐條信息處理
for (test_ pubda ta test : pageInfo. get Lis t()) {
//分別解密數據
test. setAcid(securityTestAll. SM4DecForECB(test, getIkey(), test, getAcid())); test, set Pressure (secur ity Tes tAll. SM4DecForECB(lest.getI key (), test.get Press ure ()));
test, set Sugar (secur ity Tes tAll. SM4DecForECB(lest.getI key (), test.get Sugar ()) );
//定義新對象接受
test_pubdataOut out 二 new test_pubdataOut(); BeanUtil. copyProperties(test, out);
//插入列表中
testOuts. add (out);
}
4.4數據審核模塊
雖然數據審核功能是用戶功能模塊的組成部分,但是由于數據審核部分包含三個子 功能,因此,我們單獨列出該功能。
4.4.1用戶審核
機構審核主要的目的是為了防止有人惡意注冊用戶信息,并向系統發送數據,為系 統帶來不必要的開銷,因此,為了保證系統穩定運行,在用戶剛注冊時,不會立即允許 其登錄進入系統,而是需要系統內部人員審核,審核人數在1/2及以上才可以通過,但如 果需要全體人員的1/2都同意,難免在系統效率上大打折扣,因此在此功能中,該系統內 部人員特指與申請人同一機構的在冊人員。其流程圖如圖4-15所示。
該功能的具體過程為:
(1)系統內部用戶選用此功能時,會通過POST請求,調用相關的Controller方法, 通過該方法執行以下操作。
(2)首先與數據庫進行連接,獲取狀態為未登記在區塊鏈的用戶。
(3)系統內部用戶可以選擇是否通過給予其資質,但是給予了通過之后,無法再點 擊拒絕。
(4)每次點擊之后,都會審核通過人數是否超過系統總人數的1/2。如果超過之后, 會將信息傳入區塊鏈中。具體列表如圖4-16所示。
序號 姓名 年齡 mo 操作
13chen 100 女 ]通過卄拒絕|
14陳明權 122 男 |搐甘| |拒絕|
15chen 111 女 |搐甘| |拒絕|
16ccc 123 男 |通過卄拒絕|
17chenmingquan 123 男 | 誦討 | | 拒絕 |
18dnf 123 男 |誦討| |拒絕|
圖4-16 用戶審核列表
4.4.2一般數據審核
為了避免惡意添加數據,導致系統不必要的開銷,因此設置了數據審核,避免有人 惡意上傳數據。該功能的流程圖如圖4-17所示。
圖4-17 一般數據審核流程圖
該功能的具體過程為:
(1)用戶登錄之后,通過Session獲取用戶信息,并將數據庫中未上鏈的信息依次利 用對應的對稱密鑰解密成明文,將明文組成列表輸出。
(2)用戶可以自行點擊“數據上鏈”按鈕或者“拒絕”按鈕。如果用戶之前已經進 行過審核,則會跳出“您已審核”的彈框。
(3)因為列表顯示的是明文,如果用戶點擊“數據上鏈”按鈕,則意味該用戶認可 上傳的數據,因此通過人數加一,之后判斷通過人數是否達到2/3以上,如果達到,則利 用相關SDK,更新區塊鏈數據。如果沒有,將該用戶的ID放入通過列表中。其中,該功 能涉及到的智能合約的關鍵代碼為:
//上傳功能
func (t *testold) savetestPub(stub shim. ChaincodeStublnterface, args
[]string) pb. Response {
//數據違規
if(len(args)!=2) {
return shim. Error("want two string")
}else{
err:=stub. PutState(args[0], []byte(args[l]))
//上傳失敗
if(err!=nil) {
ret urn shim. Error (err. Error ())
}
//上傳成功
return shim. Success(nil)
}
}
(4)如果用戶點擊“拒絕”按鈕,則拒絕人數加一,之后判斷人數是否達到總人數
的1/3,如果達到,則刪除該信息即可。數據界面如圖4-18所示:
序號 尿酸0 血壓() 血糖0 日期() () 操作0
1 120 80/120 130 2021 -02-04105:35:31.000+00:00 鳥I 城上鏈
2 125 90/130 140 2021 -02-03T05:40:12.000+00:00 城上鏈I 拒絕
3 130 110/160 120 2021 -02-10T05:41 :59.000+00:00 琳上鏈
圖4-18 一般數據列表
4.4.3隱私數據審核
由于隱私數據具有很強的隱私性,因此隱私數據不可以像一般數據直接解密給出明
文。該功能的流程圖如圖4-19所示:
該功能的具體過程為:
(1) 與一般數據審核功能一樣,隱私數據審核功能一開始也是通過讀取登錄界面設 置的Session來獲得當前登錄的用戶。之后連接數據庫,獲取所有存入數據庫中未被審核 的隱私數據,這里的隱私數據應該是密文。
(2) 系統會設置一個語句,然后對這句話進行簽名。系統內部用戶審核狀態時,可 以選擇“驗證簽名”按鈕,也可以直接點擊“拒絕”按鈕。如果直接點擊拒絕按鈕,則 按照第四步執行。
(3)當用戶點擊驗證簽名之后,會調用SM2的驗簽算法。如果驗證通過,通過人數 加一,再驗證人數是否達到占比,若達到,則連接區塊鏈,并更新數據。如果驗證不通 過,也按照第四步執行。關鍵代碼為:
public boolean Sign(Integer ID)
{
//獲取隱私數據信息
test_pridata t= findtest_priata(id);
//獲取所屬老人
test_old testOld=testOldService. findtestByOldid(t. getOldid());
//獲取簽名
St ring sign=testO ld. get Sign();
//系統定義簽名語句
String s1="I LOVE Y";
//驗簽
boolean b=
s. verifySM2Signature (testO ld. get Pub (),Util. byteToHex(s1. getByt es()), sign);
return b;
}
4)拒絕人數加一,并判斷拒絕人數是否達到1/3,如果達到,則刪除該數據。數據
圖4-20 隱私數據審核表
4.5本章小結
本章從智能合約的鏈碼和數據結構設計,SDK的開發以及每個模塊的實現和設計等 多個角度對基于區塊鏈的養老信息管理系統進行了闡述。在部分模塊中,給出系統的實 現效果圖和部分功能的關鍵代碼。
第 5 章 系統測試
系統測試是一個系統生命周期中必不可少的一部分。開發人員可以通過系統的功能 測試和性能測試來判斷系統是否符合預期。對于系統功能的測試,我們采用的測試方法 為黑盒測試,并針對養老信息管理系統的每個功能設計了相關測試用例,并于最后測試 數據是否可以被加密。在性能測試上,對不同的算法進行了時間測試,從而獲知采用的 部分手段是否會帶來時間或空間上的改進。
5.1功能測試
5.1.1注冊、登錄測試
注冊和登錄功能是系統的重要功能之一。首先對用戶注冊等功能進行測試并接著對 機構注冊功能進行測試,測試表如表5-1所示。
表5-1 注冊功能測試表
測試編號 測試功能 預期結果 是否通過測試
A1 用戶注冊 注冊成功 是
A2 用戶登錄 登錄成功,顯示用戶界
面 是
A3 用戶重復注冊 注冊失敗并提示 是
A4 機構注冊 注冊成功 是
A5 機構登錄 登錄成功,顯示機構界
面 是
A6 機構重復注冊 注冊失敗并提示 是
由于用戶注冊登錄功能與機構注冊登錄有很大相似性,因此我們僅以用戶注冊登錄 作為測試用例來說明如何測試:首先,注冊一個未被注冊過的用戶,記為A,此時應該提 示“注冊成功”,當再次注冊用戶A時,則應該提示“賬號已存在”。對于登錄這一功 能,兩者稍微有些區別 ,機構登錄不需要與區塊鏈進行互通,只要數據庫存在即可,但 是用戶登錄需要與區塊鏈互通,因此為了測試這一功能,我們在注冊第一個用戶時,可 以先取消人數審核限制并直接在區塊鏈和數據庫中注冊該用戶信息。最后測試結果如上 所示,全部通過測試。
5.1.2數據添加與查看測試
數據添加與查看是系統的核心功能,具體功能測試表如表5-2所示。
表5-2 數據添加與查看測試表
測試編號 測試功能 預期結果 是否通過測試
B1 隱私數據上傳 成功上傳 是
B2 一般數據上傳 成功上傳 是
B3 查看隱私數據 顯示最近隱私數據 是
B4 查看一般數據 顯示最近一般數據 是
B5 機構查看一般 顯示一般數據列表 是
數據
首先,利用剛剛注冊的A用戶,進行隱私數據和一般數據表單的填寫,填寫完成并提 交之后,再次登錄A用戶賬戶,查看是否可以顯示出剛剛填入的數據,如果可以,則上傳 數據功能測試成功。對于機構查看一般數據這一功能,需要約3-4個用戶上傳數據(因為 僅有一個用戶的一般數據時,機構查看到的數據具有偶然性),因此,再注冊2個用戶, 然后依次上傳數據,最后,登錄機構賬號,查看是否能顯示出所有用戶的一般數據的明 文。結果如上所示,均為通過。
5.1.3數據審核測試
數據審核功能是本系統一大特色功能。具體功能測試表如表5-3所示。
表5-3 數據審核測試表
測試編號 測試功能 預期結果 是否通過測試
C1 用戶審核 1.審核通過
2.審核失敗 是
C2 一般數據審核 1.審核通過
2.審核失敗 是
C3 隱私數據審核 1.審核通過
2.審核失敗 是
對于用戶審核的測試,首先,注冊新用戶B,然后依次登錄已經存在的3個用戶,分 別選擇“通過”、“拒絕”、“通過”。然后,再次登錄用戶B,如果可以進入系統則測 試“審核通過”功能成功。再注冊用戶C,加上剛剛注冊的用戶B,系統中應該有四個用 戶,登錄三個用戶,都選擇“拒絕”,再登錄用戶C,看是否能進入系統,如果不能進入 系統,則測試“審核失敗”功能成功。兩個都測試通過,才能判斷該功能符合預期。
一般數據和隱私數據的審核過程類似,但一般數據顯示的是數據明文,用戶可以根 據顯示內容自行選擇“通過”或者“拒絕” ,而隱私數據顯示的是數據密文,用戶可以
通過驗證簽名來自行選擇是否通過該信息的審核。因此對于這兩個功能而言,測試過程 為:用戶B分別上傳一般數據和隱私數據,之后利用別的賬號進行審核,如果審核通過的 人數超過2/3,則審核通過,如果拒絕的人數達到1/3,則審核失敗。測試結果如表5-3所 示,審核均通過。
5.1.4數據加密測試 數據加密并非系統的單獨功能,而是對于其他功能的數據存儲要求,對于系統的安 全性具有重大意義。
表5-4 數據加密測試表
測試編號 測試功能 預期結果 是否通過測試
D1 隱私數據加密 數據庫存儲密文 是
D2 一般數據加密 數據庫存儲密文 是
由于直接查閱數據庫,顯示的效果不太理想,因此我們直接編寫測試頁面,通過直
接讀取數據庫內容展示出相關內容,具體如圖5-1和5-2所示。
圖5-1 隱私數據密文圖
圖5-2 一般數據密文圖
根據圖5-1和圖5-2所示,數據存儲在數據庫中的內容是密文,因此加密測試通過。
5.1.5數據上鏈測試
與加密功能一樣,數據上鏈功能并非系統單獨功能,也是對于數據處理的一種要 求。具體如圖5-3、圖5-4以及圖5-5所示。
root^cmq-virtual?Eauhtn亡:/hofne/unq# peer chatncode query -C mychannell -n testo Id -c ? fArgs" : [••query•* }?
<MId" : ”13" , **Account" : "123456” , "Name*': "chert" . "Sex" : H l'1, "Pwd,': ,,6EeF9E14344C54O6AO CF5A3B4DFB66SF87F4A771A31F7EDBB5C72B74A32B2今57H,"O「gi0“:n1","Pub":H©46273c219c8 691f5d7c88ce3bef556d36a7a9296472e5bd45743aca45196a4aace493222fdfe6db577260d46cl fill06cdb9b96951dl25e34d3fc8906d7659972c** , **Ikey,4 : •*ft7c29b75115f4bsfblc55c24e4f928 f7M}
圖5-3 用戶查詢
圖5-4 隱私數據查詢
root:@c:mq - vi. rtuaT - machi.ne : /nome/crnq# pee r chai.n<=ode query mychannel 1 - n tes t p
ub -c * <"Args":["query","9"r
fPubld" : "9” . "Oldld” : ”l_m” , ••Pressure" : r, 23Te^32bQGb±±Ab±3t>27±7■f!ecQ■f!77 7±^^, r "Sugar" :“ O.d233544ab7a3a6:199202u4C)b4492843" , ** AcxdM : M 9ce7T 9 8 5 5 3 3a 5 548 28 38 a f f b la bd 3 1 e6,r 3-
圖5-5 一般數據查詢
經過查詢,可以找到上傳的數據,因此數據上鏈測試成功。
5.2性能測試
5.2.1加密性能測試
本文主要用到加密功能為SM2公鑰加密和SM4私鑰加密兩種加密方案,該測試方案 主要對兩種加密方案進行了時間性能的測試,測試的數據量在20B至160B之間。具體如 圖5-6所示。
The encryption time(ms)
25
15
10
0
10B 20B 40B 80B 160B
'SM2 SM4
圖5-6 SM2與SM4加密時間
根據測試,可知SM2單次加密時間在19ms左右,SM4單次加密時間在5ms左右。雖 然,用了加密方案之后會帶來時間的消耗,但是顯然,這些時間的消耗并不會給用戶帶 來明顯的延遲感。另外,根據此圖也可知,將數據性質進行區分,并對一般數據采用 SM4加密手段能夠減少系統的性能消耗。
5.2.2哈希性能測試
本文主要用測試了 SHA-1、SHA-256、SM3三種哈希方案,測試的數據量在10B- 100KB之間。
對比三種哈希算法,我們可以發現,在數據量較小時(數據量在10B-1KB時), SM3的哈希速度最快,而數據量增大時,SM3算法的哈希時間會隨著數據的增加而陡 增。SHA-1方案在數據量很小時的哈希速度雖然沒有SM3快,但是當數據量增大時,其表 現最好,且從曲線上看,它對于數據量增加的“敏感度”遠低于其他兩種方案。 SHA- 256的哈希速度在數據量較小時速度最慢,在高數據量時,介于其余兩種方案之間。
由于在本文中是對用戶密碼進行哈希,而一般來講,用戶密碼數據量較小,所以僅 考慮少量數據哈希所消耗的時間而言,使用SM3的方案效果好一點。但是,SM3哈希完 成之后的固定長度為256比特,而SHA-1哈希完成之后為160位,且SHA-1算法在低數據情 況下單次哈希時間也僅為8ms左右,不會影響用戶體驗。因此在不考慮安全性的情況下, SHA-1的綜合性能高于SM3。
5.3本章小結
本章首先給出功能性測試,并在此基礎之上,驗證了數據是否成功加密和成功上鏈 這兩項非功能性要求。最后,在性能測試部分,主要對本文用的加密手段和哈希手段進 行了時間的單獨測試,已檢驗本系統相對于非加密的系統所用去的額外花銷是否在用戶 可承受范圍內。
第 6 章 總結與展望
6.1本文主要工作
本文主要針對目前主流養老系統所存在的一些問題,利用國密技術與區塊鏈技術, 設計一種新的養老信息管理平臺。首先,本文梳理了有關區塊鏈技術的相關知識,并在 此基礎之上對系統框架和主流開發技術進行了闡述。其次,針對當前的養老系統存在的 信息控制權錯位問題,本文提出了基于區塊鏈的養老信息管理平臺的理念。接著,進一 步出于用戶安全考慮,本文將國密算法與系統相結合,讓該系統具有了較高的安全性。 再然后,本文依次以不同用戶的角度來實現有關功能,如隱私數據和一般數據的上傳與 查看等功能。最后,完成了基于區塊鏈的養老信息管理平臺的開發與測試。
該系統主要解決的問題,包括:
(1) 本文提出將區塊鏈技術與養老信息管理系統相結合,以解決傳統養老信息管理 存在的中心信任問題。并通過分析主流的區塊鏈平臺,確定了區塊鏈的開發框架,最 后,對基于區塊鏈的養老信息管理系統進行了設計與實現。
(2) 采用國密標準算法保護數據的機密性,并且為了提高加解密的效率,將數據分
為隱私數據和一般數據,分別采用公鑰加密算法SM2和對稱加密算法SM4進行加密。
(3)采用哈希函數國密標準算法SM3來計算并存儲用戶口令的哈希值,確保在數據 庫被攻破的情況下,攻擊者仍然無法獲得用戶口令的明文,保障了用戶帳號口令的安全 性。
6.2展望
由于區塊鏈技術和現實養老事業的復雜性,本文僅對原型系統進行了實現,雖然該 系統在實驗室環境下的實現了有關功能,但它難以支撐具有高并發分布式的場景。同 時,因為現實養老的復雜性和多樣性,本文僅對一部分的養老數據進行了采集,對標完 全的現實應用仍有一定差距,因此本文還有待進一步完善。
下一步工作的主要方向有:
(1) 做好數據采集工作,讓系統更加符合現實使用場景,例如,加入代幣功能,開 發線上機構扣款等功能。
(2) 本系統只是在實驗室環境下模擬了幾個單機之間的交互,并未考慮到現實用戶 網絡上的復雜性,因此后期需要改進系統部分功能,例如:利用智能合約實現數據審核 功能,而并非利用前端界面進行數據統計。
(3) 充分學習共識機制,設計出符合本系統的共識機制并對驗證機制進行優化,以 此提升平臺性能。
參考文獻
[1]王志理. 世界人口增速放緩 人類進入低增長時代——《世界人口展望2019》研討會在 京召開[J].人口與健康,2019(07): 14-15.
[2]第七次全國人口普查主要數據公布人口總量保持平穩增長[J].西北人口,2021,42, 03: 127.
⑶ 王皓田.我國養老服務發展的政策演變與發展路徑[J].中國經貿導刊,2020(06):73- 77.
[4]George Baber. Our elderly care System[J]. The North American Brundage Dean K. Review, 1890, 150(402): 663-664.
[5]Dean Brundage. Records of the Small Sick-Benefit Association as a Source of Statistics for the Factory Medical Department[J]. Public Health Reports (1896-1970), 1922, 37(8) : 413-422.
[6]Gledhill V X, McPherson T A, Mackay I R. The application of computers to medical records: a computer system for the storage and retrieval of medical records[J] . Australasian annals of medicine, 1970, 19(1): 16-23.
[7]Marcelo Sosa-Iudicissa, Nora Oliveri, Carlos A. Gamboa, Jean Roberts, Maria Fernanda Cabrera , Maria Teresa Arredondo, Maria Elena Hernando , Francisco Del Pozo . An Information system for the Elderly and Disabled People[M]. IOS Press, 1997-06-15.
[8]Masakazu Washio , Chikako Kiyohara. Health Issues and Care System for the Elderly[M]. Springer, Singapore, 2019-01-01.
[9]楊慶中.農村地區社會養老保險基金交付系統的模型[J].數學的實踐與認識,1989,03 : 6-11.
[10]劉杰.說說基層養老保險個人賬戶信息管理系統的開發[J].勞動世界,2001, 01: 39- 40.
[11]張艷萍.基于Struts的長春市居家養老系統的設計與實現[D].吉林大學,2010.
[12]張冠湘.社區健康養老信息系統的設計與實現[D].大連理工大學,2013.
[13]劉君哲,劉朝霞,陶艷芳.基于物聯網技術的智能居家養老社區的研究[J].電子測試 , 2019, 11: 86-87.
[14]Nakamoto, S. Bitcoin: A Peer-to-Peer electronic cash system. Technical report, 2008. https://bitcoin.org/bitcoin.pdf
[15]馮麗艷,肖翔,趙天驕.社會責任、商業信任與商業信用成本[J].北京工商大學學報 (社會科學版), 2016, 31(01): 64-74.
[16]董友康.基于區塊鏈的安全電子投票系統的設計與實現[D].北京交通大學,2019.
[17]Jemel M, Serhrouchni A. Decentralized access control mechanism with temporal dimension based on blockchain[C]. IEEE 14th International Conference on E-Business Engineering, 2017: 177-182.
[18] Ferri Andrianto Susilo, Yaya Sudarya Triana. Digital supply chain development in blockchain technology using Rijndael algorithm 256[J]. IOP Conference Series: Materials Science and Engineering, 2018, 453(1): 1-11.
[19]楊亞濤,蔡居良,張筱薇,袁征.基于SM9算法可證明安全的區塊鏈隱私保護方案J]. 軟件學報, 2019, 30(06): 692-1704.
[20]A. Albakri, L. Harn , M. Maddumala. Polynomial-based Lightweight Key Management in a Permissioned Blockchain[C]. IEEE Conference on Communications and Network Security, 2019: 1-9.
[21]章建聰,邱云翔,金泓鍵.超級賬本Fabric平臺SDK國密改造方案研究[J].網絡安全 技術與應用, 2020, 03: 37-39.
[22]王榕,謝瑋,曹珩,路鵬.我國商用密碼管理現狀與發展對策建議[J]•信息安全與通 信保密, 2020, 03: 83-90.
[23]GB/T 32918. 4-2016,信息安全技術,SM2橢圓曲線公鑰密碼算法,第4部分:公鑰加 密算法[S].
[24]GB/T 32907-2016,信息安全技術,SM4分組密碼算法[S].
[25]David Shibin, Kathrine Jaspher. Digital Signature Algorithm for M-Payment Applications Using Arithmetic Encoding and Factorization Algorithm[J] . Journal of Cases on Information Technology, 2021, 23(3): 11-26.
[26]Pass R, Seeman L, Shelat A. Analysis of the blockchain protocol in asynchronous networks[C] . Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2017: 643-673.
[27]何渝君,龔國成.區塊鏈技術在物聯網安全相關領域的研究[J].電信工程技術與標準 化, 2017, 30(05): 12-16.
[28]Vakili, Vahid Tabataba, Tohidi, Hamed. Lightweight authentication scheme for smart grid using Merkle hash tree and lossless compression hybrid method[J]. IET communications, 2018, 12(19): 2478-2484.
[29]Nick Szabo. Smart Contracts: Building Blocks for Digital Markets[J]. Extropy, 1994, 3 (16): 1-11.
[30]Anqi Ji. Research on the characteristics of intelligent contract and its accounting application based on block chain technology[C]. 2019 6th International Conference on Machinery, Mechanics, Materials and Computer Engineering, 2019: 213-217.
[31]劉明熹,甘國華,程郁琨,肖琳,劉帥,房勇.區塊鏈共識機制的發展現狀與展望[J]. 運籌學學報, 2020, 24(01): 23-39.
[32]阮娜, 劉漢卿, 斯雪明. 采用工作量證明共識機制的區塊鏈中挖礦攻擊者間的“鯰魚
效應” [J].計算機學報,2021,44(01): 177-192.
[33]SHI Liucheng, GUO Zhaozhong. Baguena: A Practical Proof of Stake Protocol with a obust Delegation Mechanism[J]. Chinese Journal of Electronics, 2020, 29(05): 887-898.
[34]Xiaolin Gong, Xiaorui Zheng, Jiancheng Fang, Gang Liu. Optimized layout methods based on optimization algorithms for DPOS[J]. Aerospace Science and Technology, 2019, 84: 484-496.
[35]高云,嚴悍.Hyperledger Fabric區塊鏈軟件架構中的中間件設計[J].計算機與數字工 程,2020, 48(09): 2195-2200+2274.
[36]高凡.Hyperledger Fabric中的交易內容隱私保護技術研究[D].北京交通大學,2020.
[37]Velmurugadass, Dhanasekaran, Shasi Anand, Vasudevan. Enhancing Blockchain security in cloud computing with IoT environment using ECIES and cryptography hash algorithm[J]. Materials Today: Proceedings, 2021, 37(P2): 2653-2659.
[38]Vikas Singhal, Yash Kumar Shukla, Navin Prakash. Image Steganography embedded with Advance Encryption Standard (AES) securing with SHA-256[J]. International Journal of Innovative Technology and Exploring Engineering, 2020, 9(8): 641-648.
[39]GB/T 32905-2016,信息安全技術,SM3密碼雜湊算法[S].
[40]David Shibin, Kathrine Jaspher. Digital Signature Algorithm for M-Payment Applications Using Arithmetic Encoding and Factorization Algorithm[J]. Journal of Cases on Information Technology, 2021, 23(3), 11-26.
[41]Hanif Muhammad Shehzad, Bilal Muhammad. A Metric Learning Approach for Offline Writer Independent Signature Verification[J]. Pattern Recognition and Image Analysis, 2021, 30(4): 795-804.
[42]趙玉超.一種基于非對稱加密算法的安全高效身份認證協議[J].工業技術創新,2020, 07(06): 103-107.
[43]Whitfield Diffie, Martin E. Hellman. New Directions in Cryptography[C] . IEEE on Information Theory, 1976: 644-654.
[44]索南仁欠.一種基于大數分解困難性的群盲簽名方案[J].青海師范大學學報(自然科 學版), 2007(04): 1-4.
[45]舒紅章,張璇•基于離散對數與零空間的合成HMAC網絡編碼方案[J].軟件導刊, 2020, 19(09): 238-245.
[46]方立嬌,李子臣,丁海洋.基于ElGamal的同態交換加密水印算法[J].計算機系統應 用, 2021, 30(05): 234-240.
[47]Benssalah Mustapha, Sarah Izza, Drouiche Karim. An Efficient RFID Authentication Scheme Based on Elliptic Curve Cryptography for Internet of Things[J]. Wireless Personal Communications, 2020, 117(3): 2513-2539.
[48]田海晴.基于SpringBoot和Vue框架的共享運營管理平臺的設計與實現[D].山東大學,
2020.
[49]甘勇,莊園,張鶴林.基于Spring MVC的機構編制地區信息系統[J]•信息技術與信 息化, 2020, 10: 96-99.
[50]文博,劉莎莎,龔雨菲.Docker技術在企業系統軟件快速部署方面的應用[J].江蘇科 技信息, 2021, 38(02): 57-59.
[51]周鵬,張譽,張德杰,張碩•“智能家居”養老系統功能性需求及接受度調研分析[J]. 市場觀察, 2020, 09: 33.
[52]Rao, A Ananda, Gopichand, M. Four Layered Approach to Non-Functional Requirements Analysis[J]. International Journal of Computer Science Issues, 2011, 8(6): 371-379.
[53]Lee Seon Ung, Moon Il Young. A Study of User Interaction Using jQuery in Web Application[J]. The Journal of Advanced Navigation Technology, 2011, 15(4): 626-631.
[54]劉鎮江,戚湧,嚴悍.Fabric區塊鏈SDK連接配置方法研究[J].計算機應用研究,2020, 37(S1): 215-217+220.