基于區塊鏈的敏感數據庫屬性加密算法

程大勇

數據安全是當前信息技術領域的一個重要課題，也是許多專家、軟件工作者共同關心的問題.目前的信息化環境下，所有的數據都是通過數據庫進行儲存和處理，因此，數據庫的安全性就是最終的保障［1］.雖然當前大多數主流的數據庫產品都具備了比較完備的安全保護措施，但隨著軟件系統的日益復雜化，一些漏洞也隨之顯現，導致數據庫的安全性問題頻發［2?5］.一旦使用者將資料上傳至云端服務器，便會喪失對資料的實際控制權，資料的安全性則由云端服務器決定.所以，常規的技術和方法只能提高黑客攻擊云服務器的難度，很難從根源上阻止用戶的信息泄露［6］.因此，為避免云端數據出現泄露風險，保持數據庫的機密是至關重要的.

劉格昌等［7］介紹了一種以可檢索密碼為基礎的區塊鏈密鑰保密機制.利用區塊鏈技術對關鍵資料進行存儲，能有效地阻止明文信息的泄露.通過引入雙線性圖的數學性質，構建一個區塊鏈碼的交易單，并在該交易單中添加一個密鑰，以實現對關鍵字的檢索.使用者可以利用可搜尋的私有密鑰建立特定的關鍵字搜尋.此方案在個人健康數據區塊鏈中應用，可有效地避免個人健康資料泄露問題，在11.23 s 內完成2 400 字的檢索.張人上等［8］針對擴展頻譜通信中存在的問題，提出了一種新的基于混沌的多源異質信息加密方法.基于多源異構的混沌映射，在混沌圖的路徑上，建立了多源異構的混沌序列，并由Merlay狀態機對其進行控制.在控制過程中給出一個子鍵發生的信號，在時間限制下通過特殊的閾值功能生成子鍵，然后使用該子鍵對多源異構的數據進行正向、反向異或和模式化，從而完成多源異構的擴頻異構信息編碼.實驗結果顯示：+10?13 的密鑰誤差不能對正確的資料進行解碼；圖像和音頻數據加密后相關性顯著降低；該算法的編碼時間從16.451 s到18.630 s 不等，均在上限以下.

基于以上研究背景，本文將區塊鏈技術應用到敏感數據庫屬性加密算法中，從而提高敏感數據的安全性.

1 敏感數據庫屬性加密算法設計

1.1 檢索敏感數據庫屬性

在加密敏感數據庫的屬性之前，先按照順序對敏感數據庫的屬性進行儲存［9］，通過計算檢索關鍵詞出現的概率，實現敏感數據庫的屬性檢索，具體步驟如下：

Step1：在敏感數據庫中，采集屬性信息pi，經過文檔轉換之后，獲取敏感數據庫屬性的信息層次，將其表示為：

其中：y代表敏感數據庫屬性信息的表征，Ωy代表不同屬性信息之間產生的映射集合，?y代表敏感數據庫中屬性信息的聚類中心，?代表敏感性屬性在敏感數據庫中所占的比例.

Step2：分類處理敏感數據庫的屬性信息，建立屬性檢索格式，即：

其中：Uk表示敏感數據庫中屬性信息的類別函數，φ(k)表示敏感數據庫中存在k種敏感屬性的概率.

Step3：假設數據庫中敏感屬性為S，將其劃分為Si={s1，s2，…，sn}，保證敏感 屬性滿足任意兩個數據的劃分.

Step4：將敏感數據庫屬性信息的劃分函數定義為f(sn)，該函數可以將敏感屬性sn分為兩個類別［10］，而且可以保證每一個類別中的敏感屬性值都比最初設定的閾值大.敏感數據庫中敏感屬性劃分的期望值為qi(qi∈sn)，計算公式為：

其中：(qs?qi)表示敏感數據庫屬性信息檢索的范疇參數，?表示敏感數據庫屬性信息的值，i表示敏感數據庫屬性的方位向量.

Step5：根據敏感數據庫中敏感屬性劃分的期望值，構建敏感數據庫屬性的檢索序列［11］，即：

其中：Φ(k，b) 表示敏感數據庫屬性在檢索過程中的時間序列表示敏感數據庫屬性檢索的時間間隔.

Step6：利用敏感數據庫屬性的檢索序列，建立敏感數據庫屬性集合，表示為：

根據以上過程，檢索出敏感數據庫的屬性，為敏感數據庫中重復屬性的刪除提供依據.

1.2 刪除敏感數據庫內的重復屬性

根據敏感數據庫屬性的檢索情況，刪除敏感數據庫內的重復屬性.假設R=[R1，R2，…，Rk，…，Rn]T表示待刪除的重復屬性樣本集合，為了保證敏感數據庫的安全性，通常將備份的屬性保存在遠程終端［12］，得到變換處理后的屬性信息，即：

其中：G?a代表變換處理算子.如果敏感數據庫內的屬性信息存在非高斯性，通過公式（7）計算出屬性信息的混合累積情況：

其中：K表示敏感數據庫內屬性信息的帶寬，g(j)代表濾波函數，j表示敏感數據庫的屬性信息，ε表示敏感數據庫中存在非高斯性的屬性信息.

采用Fourier 變換方法［13］，對敏感數據庫的屬性特征進行累積，實現敏感數據庫屬性信息之間分配關系的配比，利用式（8）可以得到期望輸出，即：

其中：HO代表分配敏感數據庫屬性信息之間關系的配比，k代表屬性信息的訓練樣本數量，J代表總訓練樣本數量.

根據敏感數據庫屬性信息之間分配關系的配比［14］，可以得到刪除重復屬性的輸出，即：

通過敏感數據庫屬性信息的變換處理，計算出屬性信息的混合累積情況，根據敏感數據庫屬性信息之間分配關系的配比，刪除敏感數據庫內的重復屬性.

1.3 設計敏感數據庫屬性加密算法

將敏感數據庫內的重復屬性刪除之后，區塊鏈可以通過對敏感數據庫屬性進行加密［15］，達到保護敏感數據庫的目的.假設s?Key代表區塊鏈生成的私有密鑰，g?Key表示區塊鏈生成的公有密鑰，每個區塊的產生速率會對區塊鏈的安全產生影響［16］，如果利用V表示每個區塊的產生速率，可以反映出每次組隊所需的工作負荷與期望結果.每個區塊的產生速率與區塊鏈的安全程度呈現相反的關系，因此可以使用1/V描述區塊的安全程度.假設B表示一個區塊鏈中的交易量，σs表示區塊的尺寸，td表示每個加密回合所用的時長，其關系可以表示為：

區塊在敏感數據庫中生成的時間間隔為ti，與每個加密回合所用的時長之間屬于正比例關系［17］，因此將上式改寫為：

通過上式可以發現，區塊鏈中的交易量、區塊在敏感數據庫中生成的時間間隔和區塊的尺寸都會影響敏感數據庫的安全性［18］.

區塊在敏感數據庫中生成的時間間隔與區塊的尺寸之間存在著如下關系：

其中：N表示敏感屬性在敏感數據庫中的平均尺寸，B*表示單位時間內敏感數據庫中某一屬性的檢索數量，F(X，V)表示敏感數據庫中敏感屬性的聚類函數.

根據每個加密回合所用的時長、區塊的尺寸、區塊鏈中的交易量、區塊在敏感數據庫中生成的時間間隔與區塊鏈安全性之間的關系，合理調整其中一個指標，通過私有密鑰和公有密鑰完成敏感數據庫屬性的加密.

2 實驗分析

2.1 搭建實驗平臺

為了驗證文中算法在實際應用中的性能，采用DRM 系統作為測試平臺，對DRM 系統的敏感數據庫進行屬性加密，實驗平臺頁面如圖1 所示.

實驗過程中，選擇Windows7 操作系統執行實驗平臺，實驗平臺運行的環境參數如下：

硬件環境：PC 主頻2 GHz.

處理器：Intel（R）Core（TM）2 Duo T6500 2.10 GHz 的CPU.

內存：4 GB.

編程環境：Eclipse+Oracle9 數據庫.

2.2 實驗數據

實驗所使用的數據來自某一大型企業員工的基本信息，以員工的姓名、電話、電子郵箱和月基本工資共同組成敏感數據庫，在敏感數據庫中，一共包括5 000 份員工基本信息的敏感數據樣本，選擇其中1 000 份敏感數據樣本用于實驗測試，其中部分敏感數據如表1所示.

表1 實驗數據樣本

通過對敏感數據庫的屬性進行加密，可以保證表1 中員工基本信息的敏感數據具有較高的安全性.

2.3 加密效果測試

分別在噪聲干擾和濾波干擾下，模擬惡意攻擊行為，對敏感數據進行攻擊，采用文中算法對敏感數據庫的屬性進行加密之后，測試了攻擊攔截比例，結果如圖2 所示.

圖2 攻擊攔截比例測試結果

由圖2 的結果可知，文中算法在區塊鏈的支撐下，對員工基本信息的敏感數據進行加密之后，不會受到噪聲和濾波的干擾，對攻擊的攔截比例均在80%以上，說明文中算法對敏感數據庫的屬性加密效果較好.

2.4 性能對比分析

為了突出文中算法在敏感數據庫屬性加密性能中的優勢，引入基于可搜索加密的算法和基于混沌系統的算法作對比，進行安全性測試和魯棒性測試.

2.4.1 安全性對比

安全性測試中，以DRM 系統為依據，測試敏感數據遭受攻擊的成功率，結果如圖3 所示.

圖3 攻擊成功率測試結果

由圖3 的結果可知，當敏感數據庫的屬性被攻擊的時候，利用基于可搜索加密的算法對敏感數據庫的屬性進行加密，使得攻擊者的成功率超過了25%，原因是可搜索加密對敏感數據庫的屬性搜索存在一定誤差，導致攻擊成功率偏高，降低了敏感數據庫的安全性；采用基于混沌系統的加密算法時，對敏感數據庫的屬性加密之后，攻擊成功率雖然有所下降，但是仍然超過了20%；然而采用文中算法對敏感數據庫的屬性加密時，攻擊成功率可以控制在10%以內，提高了敏感數據庫的安全性.

2.4.2 魯棒性測試

敏感數據遭受攻擊之后，利用信息損失率衡量加密的魯棒性，結果如圖4 所示.

圖4 敏感數據的信息損失率測試結果

從圖4 的結果可以看出，當敏感數據受到攻擊之后，會出現信息損失嚴重的現象，采用基于可搜索加密的算法和基于混沌系統的算法時，隨著敏感數據量的增加，其信息損失率也在不斷增加，說明這兩種方法會導致敏感數據的信息大量損失，造成敏感數據的質量下降；而采用文中算法時，由于使用了區塊鏈，隨著敏感數據量的增加，雖然敏感數據的信息損失率有上升的趨勢，但是始終在20%以內，說明文中算法通過引入區塊鏈可以保護敏感數據的安全性.

3 結語

本文研究將區塊鏈應用于敏感數據庫屬性加密算法設計，通過實驗測試發現，該算法具有較好的加密效果和性能，可以保護敏感數據的安全性.但是本文的研究還存在諸多不足，在今后的研究中，應考慮到用戶之間的可信度因素.對于可信用戶而言，由于不同的用戶需要不同的密鑰，所以要對密鑰的設置進行特殊處理；對于不可信用戶而言，多密鑰管理值得進一步研究.