支持高并發(fā)的Hadoop高性能加密方法研究

金偉，余銘潔，李鳳華，楊正坤，耿魁

（1.中國科學(xué)院信息工程研究所，北京 100093；2.中國科學(xué)院大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，北京 100049；3.中國科學(xué)技術(shù)大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，安徽 合肥 230027）

1 引言

Hadoop是一種可以對海量數(shù)據(jù)集進(jìn)行分布式存儲與處理的開源軟件框架，該框架通過搭建單一服務(wù)器或多臺服務(wù)器集群，為用戶提供高可用性、可擴(kuò)展性和高容錯性服務(wù)。目前，Hadoop平臺在電子憑據(jù)、醫(yī)療服務(wù)等結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的服務(wù)領(lǐng)域均占有廣泛的市場。

伴隨著Hadoop的快速發(fā)展，其安全問題也日益凸顯。據(jù)CVE（common vulnerabilities and exposures）漏洞列表顯示，從2013年到2019年6月，已暴露出的Hadoop漏洞數(shù)量共計(jì)21個，其中包括6個關(guān)于信息泄露的漏洞，這些漏洞帶來了嚴(yán)重的安全隱患。

為確保存儲在Hadoop平臺中的數(shù)據(jù)不被泄露，現(xiàn)有的典型技術(shù)包括訪問控制、數(shù)據(jù)加密等。其中，訪問控制作為數(shù)據(jù)保護(hù)的第一道防線，通過開啟Kerberos等身份認(rèn)證機(jī)制，確認(rèn)用戶真實(shí)身份，并通過Sentry、Ranger等組件為用戶對數(shù)據(jù)的訪問提供細(xì)粒度控制。然而，訪問控制具有邊界性，一旦數(shù)據(jù)脫離了數(shù)據(jù)控制域，訪問控制將會失效。相反，數(shù)據(jù)加密技術(shù)通過引入加密算法對大數(shù)據(jù)平臺中的關(guān)鍵數(shù)據(jù)進(jìn)行加密保護(hù)，以密文方式存儲和傳輸，即使數(shù)據(jù)脫離訪問控制域，也將為數(shù)據(jù)提供持續(xù)保護(hù)。目前，加密技術(shù)已成為確保Hadoop平臺中數(shù)據(jù)安全的“護(hù)城河”。

目前，Hadoop的加密包括傳輸加密和存儲加密。在傳輸加密方面，Hadoop平臺的多數(shù)組件已有SASL（simple authentication and security layer）、SSL/TLV（secure sockets layer/transport layer security）等成熟穩(wěn)定的傳輸協(xié)議實(shí)現(xiàn)數(shù)據(jù)高效加密傳輸；在存儲加密方面，Apache Hadoop自2.6.0版本起增加了KMS（key management server）密鑰管理模塊，并增加了透明加解密機(jī)制，允許用戶或管理員設(shè)置加密區(qū)，向加密區(qū)上傳/下載數(shù)據(jù)時，Hadoop平臺自動加密后進(jìn)行傳輸和存儲。然而，現(xiàn)有的KMS存在如下問題。

1)密鑰檢索效率低。當(dāng)前，Hadoop發(fā)行版中的加密區(qū)密鑰是按照密鑰名與版本號的散列值將密鑰散亂排列到HashTable中，相同密鑰的不同版本也散亂排列到HashTable中，這種散亂排列導(dǎo)致密鑰檢索效率低。

2)加解密性能低。Hadoop平臺本地文件加密過程包括以下3步：待加密明文準(zhǔn)備、明文加密和密文發(fā)送準(zhǔn)備。在當(dāng)前Hadoop發(fā)行版中，這3個步驟串行執(zhí)行，即在某個步驟執(zhí)行過程中其他步驟處于空閑狀態(tài)；在明文加密過程中，對明文的加密也是串行執(zhí)行。上述2種原因?qū)е录用苜Y源利用不充分、性能低。

3)加解密算法非國產(chǎn)。當(dāng)前，Hadoop發(fā)行版中主要采用的加解密算法是美國國家標(biāo)準(zhǔn)與技術(shù)研究院的AES（advanced encryption standard）算法，這些發(fā)行版不支持密碼算法動態(tài)配置。特別地，對中國來說，未采用國產(chǎn)密碼算法，使密碼應(yīng)用關(guān)鍵環(huán)節(jié)存在重要不可控因素，這可能導(dǎo)致在Hadoop平臺中“門是自家的，但鑰匙在別人手中”的后果。

針對上述問題，本文提出一種面向Hadoop平臺的高效密鑰管理方案，實(shí)現(xiàn)國產(chǎn)商用密碼算法補(bǔ)充AES算法，利用新的密鑰存儲結(jié)構(gòu)提高密鑰的存取效率，采用流水線方法異步優(yōu)化加解密算法處理流程，提升Hadoop平臺文件加解密速度。本文主要貢獻(xiàn)如下。

1)提出基于國產(chǎn)商用密碼算法的Hadoop平臺三層密鑰管理體系，對密鑰庫口令、加密區(qū)密鑰、文件密鑰這三層密鑰逐級加密，確保密鑰安全。

2)針對密鑰檢索效率低的問題，設(shè)計(jì)“密鑰串”存儲結(jié)構(gòu)，該結(jié)構(gòu)能夠緊湊組織二級密鑰的存儲，提高密鑰存取效率。

3)針對加解密性能低的問題，提出了異步流水模式的并發(fā)加解密方案，替代Hadoop原有的串行加解密流程，提高Hadoop文件加解密效率。

4)實(shí)現(xiàn)了基于商用密碼算法的Hadoop平臺三層密鑰管理，實(shí)驗(yàn)結(jié)果表明，本文方法可有效提升Hadoop平臺數(shù)據(jù)加解密效率。

2 相關(guān)工作

2.1 面向Hadoop平臺的加解密

如前文所述，面向Hadoop平臺的加解密主要聚焦于傳輸加密、存儲加密及其高性能實(shí)現(xiàn)。

在傳輸加密方面，Hadoop主要使用SASL認(rèn)證框架，從認(rèn)證、消息完整性、機(jī)密性等多方面保護(hù)客戶端與服務(wù)器之間交換的數(shù)據(jù)[1]。在Apache Hadoop 2.9.2版本中，Hadoop服務(wù)可開啟RPC（remote procedure call）數(shù)據(jù)加密。Apache Hadoop自2.5.2版本始支持SSL/TLS v1，Apache Hive自1.0版本起添加SSLv2協(xié)議。HDFS（Hadoop distributed file system）、YARN（yet another resource negotiator）、MapReduce、Oozie等組件均支持SSL網(wǎng)絡(luò)傳輸，并且不影響KMS和HttpFS的安全使用。

在存儲加密方面，HBase支持HFile v3單數(shù)據(jù)項(xiàng)級的數(shù)據(jù)庫加密，使用兩級密鑰，并使用SASL協(xié)議和Kerberos協(xié)議分別為RPC和ZooKeeper進(jìn)行認(rèn)證。Apache Hadoop自2.6.0版本始添加了端到端的透明加解密機(jī)制，用戶可設(shè)置加密區(qū)，向加密區(qū)上傳/下載文件時，數(shù)據(jù)在客戶端自動加解密，實(shí)現(xiàn)傳輸安全和存儲安全，支持AES、3DES（triple data encryption algorithm）和RC4（rivest cipher 4）等多種算法，其中AES算法速度最快，但文件加密模式僅支持“AES/CTR/NoPadding”（CTR為counter，表示計(jì)數(shù)器模式；NoPadding表示無補(bǔ)?。?。梁勝昔等[2]提出一種HDFS混合加密保護(hù)方案，支持AES、RC4混合加密模式，可用于實(shí)現(xiàn)云數(shù)據(jù)安全共享。文獻(xiàn)[3]在Hadoop平臺中建立基于雙線性橢圓曲線的認(rèn)證和加密機(jī)制，并對數(shù)據(jù)訪問進(jìn)行審計(jì)，保護(hù)Hadoop平臺數(shù)據(jù)安全，但基于非對稱密鑰的運(yùn)算開銷較大，配置復(fù)雜。Wang等[4]借助Hadoop平臺和Sqoop組件，分布式處理數(shù)據(jù)庫的加密運(yùn)算，保護(hù)海量數(shù)據(jù)安全。

在加密算法替換與補(bǔ)充方面，Song等[5]在HDFS透明加密機(jī)制含有AES算法的基礎(chǔ)上，添加了ARIA分組加密算法，使HDFS加密系統(tǒng)雙算法可選。Lin等[6]提出了HDFS-RSA算法和HDFS-Pairing算法2種實(shí)現(xiàn)補(bǔ)充，使用混合加密機(jī)制保護(hù)Hadoop平臺數(shù)據(jù)機(jī)密性，并進(jìn)行仿真驗(yàn)證。上述工作主要聚焦于Hadoop平臺下傳輸與存儲中加解密的透明性，忽略了Hadoop環(huán)境下對加解密的性能需求。

在高性能實(shí)現(xiàn)方面，Bhatotia等[7]使用GPU提升Hadoop的計(jì)算和存儲速度。Cloudera與Intel合作的Rhino項(xiàng)目為HBase 0.98貢獻(xiàn)了關(guān)鍵的安全特性。它提供了數(shù)據(jù)單元（cell）級別的加密和細(xì)粒度訪問權(quán)限控制的功能。同時，Intel研制的AES-NI可為HDFS提供硬件加速。Cohen等[8]使用可信平臺模塊（TPM,trusted platform module）進(jìn)行密鑰保護(hù)，應(yīng)用AES-NI指令集進(jìn)行硬件加速，最高計(jì)算速度可達(dá)1.84 GB/s，是同數(shù)量級軟件加密速度的18倍。

但是，CPU層面的硬件加速僅適用于X86處理器，對硬件品牌要求高，操作系統(tǒng)支持的通用性較差，無法廣泛適配Hadoop平臺的各種服務(wù)器機(jī)型，并且，AES-NI主要針對AES算法，對于其他算法的速度暫無提升。

2.2 密鑰管理機(jī)制

目前，針對Hadoop系統(tǒng)的密鑰管理的研究相對較少，但從云環(huán)境密鑰管理出發(fā)，已有很多研究可供借鑒。本文從云環(huán)境密鑰管理入手，對相關(guān)研究進(jìn)行論述。

Zhou等[9]針對面向群組的應(yīng)用中層次化訪問控制的密鑰管理問題，從密鑰管理拓?fù)淠Ｐ?、密鑰更新方法與策略等方面分析了安全分發(fā)和密鑰更新的典型需求，枚舉了密鑰管理方案所需機(jī)制。Kandah等[10]針對大數(shù)據(jù)環(huán)境下無線傳感網(wǎng)動態(tài)環(huán)境低耗能密鑰分發(fā)需求，提出了中心狀態(tài)鏈接（CSC,centralized stateful connection）方案，動態(tài)地管理傳感網(wǎng)密鑰，并通過公鑰加密對稱密鑰，然后使用對稱密鑰加密傳輸數(shù)據(jù)，從而減少開銷。Albakri等[11]提出了一種基于多項(xiàng)式的輕量級層次密鑰機(jī)制，管理霧節(jié)點(diǎn)（fog node）與其他用戶設(shè)備間的密鑰共享，有效保證物聯(lián)網(wǎng)設(shè)備安全接入的同時，不增加用戶設(shè)備的存儲空間占用。

3 Hadoop平臺密鑰管理架構(gòu)

3.1 基于商密算法的三層密鑰管理體系

如圖1所示，本文所提架構(gòu)采用三層密鑰管理體系對Hadoop平臺中的海量密鑰進(jìn)行保護(hù)和管理。其中，一級密鑰為加密區(qū)密鑰庫口令，將該口令采用SM3單向函數(shù)進(jìn)行散列處理后用于加密二級密鑰，該口令存儲在本地文件中；二級密鑰為加密區(qū)密鑰，該密鑰與加密區(qū)綁定（即加密區(qū)與二級密鑰存在一一映射關(guān)系），并用散列化后的一級密鑰加密，將加密后的二級密鑰存儲在加密區(qū)密鑰庫中；三級密鑰為文件密鑰，用于加解密存儲在加密區(qū)中的文件，文件密鑰使用二級密鑰加密，以密文方式存儲在NameNode文件目錄的擴(kuò)展屬性中。

1)一級密鑰管理

一級密鑰即密鑰庫口令，在KMS部署時，由管理員進(jìn)行配置，以明文的形式存儲于本地文件中。當(dāng)KMS啟動時，從文件中讀取口令，以字節(jié)數(shù)組的形式存儲在內(nèi)存中。當(dāng)KMS加載或存儲加密區(qū)密鑰時，對該口令使用SM3單向函數(shù)散列處理，用散列化的口令對二級密鑰進(jìn)行加密或解密。

圖1 三層密鑰管理結(jié)構(gòu)

2)二級密鑰管理

二級密鑰即加密區(qū)密鑰，用來加密指定加密區(qū)內(nèi)所有文件的密鑰，二級密鑰包含8個部分：密鑰名、密鑰長度、密鑰、所采用的加密算法、生成時間、當(dāng)前密鑰版本號、密鑰描述信息以及用戶自定義屬性，二級密鑰由散列化后的密鑰庫口令加密，并以文件等方式存儲在密鑰庫中。

當(dāng)某空文件目錄被用戶指定為加密區(qū)后，它會與用戶所指定的二級密鑰綁定，該密鑰即成為該目錄的加密區(qū)密鑰，其密鑰名存儲在該目錄的擴(kuò)展屬性中。二級密鑰可以更新，在二級密鑰更新后，KMS采用新版本密鑰對加密區(qū)內(nèi)新文件的密鑰進(jìn)行加密。注意：舊文件的密鑰仍以舊二級密鑰加密。

3)三級密鑰管理

三級密鑰即文件密鑰，用于加解密上傳至加密區(qū)的文件。每個文件擁有獨(dú)立的文件密鑰，經(jīng)二級密鑰加密后，密態(tài)存儲在NameNode文件系統(tǒng)的文件擴(kuò)展屬性中，與文件名的文件屬性綁定。

文件的密鑰由KMS隨機(jī)生成，并由該文件所在加密區(qū)的二級密鑰加密。NameNode將二級密鑰名、版本號和密態(tài)的三級密鑰存儲在文件INode節(jié)點(diǎn)的擴(kuò)展屬性中，并與文件永久綁定。加解密文件時，NameNode將該文件所在加密區(qū)的二級密鑰名、版本號和密態(tài)的文件密鑰發(fā)送給客戶端，客戶端再將這三部分?jǐn)?shù)據(jù)發(fā)送給KMS。KMS根據(jù)加密區(qū)密鑰名和版本號查詢存儲在密鑰庫中的加密區(qū)密鑰，然后對密態(tài)文件密鑰進(jìn)行解密，得到明文的文件密鑰，并以HTTPS協(xié)議封裝后發(fā)送給客戶端，客戶端收到文件密鑰后即可對文件執(zhí)行加解密操作。

3.2 二級密鑰的快速存取

如上所述，客戶端對文件加解密前，需等待KMS返回明文的文件密鑰。而KMS在解密密態(tài)的文件密鑰并將明文的文件密鑰返回給客戶端前，需要根據(jù)二級密鑰名與版本號從密鑰庫中讀取該文件所在加密區(qū)的二級密鑰，因此二級密鑰的讀取速度是制約文件密鑰的解密性能的關(guān)鍵因素之一。現(xiàn)有方案中二級密鑰的元數(shù)據(jù)、不同密鑰、相同密鑰名的不同版本均散落在HashTable中，并使HashTable空間占用率高，導(dǎo)致需要對HashTable頻繁擴(kuò)容與復(fù)制，二級密鑰的存取效率低下。針對上述問題，本文設(shè)計(jì)了更為便捷高效的二級密鑰存取結(jié)構(gòu)，以降低文件加解密時延。

3.2.1 二級密鑰的數(shù)據(jù)結(jié)構(gòu)

為了使密鑰的組織不松散，本文設(shè)計(jì)了“密鑰串”新方案，其數(shù)據(jù)結(jié)構(gòu)如圖2所示。首先，將同一密鑰名對應(yīng)的各版本密鑰依版本號組織在ArrayList中（即ArrayList的下標(biāo)為該密鑰的版本號）；然后，將ArrayList與該密鑰的元數(shù)據(jù)節(jié)點(diǎn)組成一個KeyChain，這樣同一密鑰名對應(yīng)的元數(shù)據(jù)信息和密鑰信息均有序地組織在一起，通過密鑰名即可獲取該密鑰相關(guān)的全部信息。不同密鑰名對應(yīng)的KeyChain以的形式存儲在一個HashTable中，以keyName的hash值排列。

生成或更新密鑰時，在對應(yīng)密鑰名的ArrayList中順序添加新生成的密鑰，并更新元數(shù)據(jù)節(jié)點(diǎn)即可。查找密鑰時，先由密鑰名找到當(dāng)前密鑰名的KeyChain節(jié)點(diǎn)，再根據(jù)版本號直接讀取ArrayList下標(biāo)，獲取對應(yīng)版本的密鑰，操作簡捷、直接。

刪除密鑰時，不需要遍歷同一密鑰名的各個版本，只需將一個密鑰的節(jié)點(diǎn)移出HashTable即可。在密鑰使用的過程中，會對HashTable同步上鎖，以保證密鑰在使用過程中不會被誤刪導(dǎo)致數(shù)據(jù)錯誤。

3.2.2 二級密鑰存取效率分析

以“密鑰串”新方案組織內(nèi)存中的二級密鑰，可達(dá)到減少時間、降低空間、提升效率的效果，簡析如下。

1)查詢/刪除效率提升，新增/更新效率穩(wěn)定

圖2 二級密鑰數(shù)據(jù)結(jié)構(gòu)

在密鑰查詢方面，原有Hadoop方案的查詢需先經(jīng)過密鑰名或密鑰別名的hash值定位，隨后在同hash值的鏈表中依次匹配，效率為O(1)[+O(m)]。“密鑰串”新方案則是先通過密鑰名獲取ArrayList，再使用版本號作為ArrayList的下標(biāo)直接獲取密鑰，效率為O(1)[+O(n)]+O(1)。其中，O(m)和O(n)分別為2種結(jié)構(gòu)的HashTable中發(fā)生沖突時遍歷鏈表節(jié)點(diǎn)所需時間。在總密鑰數(shù)量相同時，“密鑰串”新方案的沖突概率遠(yuǎn)小于原有Hadoop方案，因此O(n)

在密鑰刪除方面，原有Hadoop方案需先獲取待刪除密鑰的當(dāng)前版本號n，隨后逐個移除HashTable中的密鑰節(jié)點(diǎn)，最后移除元數(shù)據(jù)節(jié)點(diǎn)，故刪除效率為O(n+1)?！懊荑€串”新方案則是根據(jù)待刪除的密鑰名直接移除KeyChain節(jié)點(diǎn)，刪除效率為O(1)，與密鑰版本數(shù)量無關(guān)。

在密鑰增加方面，原有Hadoop方案直接向HashTable中添加2個鍵值對（一個密鑰描述信息的和一個密鑰數(shù)據(jù)），添加速度均為O(1)。而“密鑰串”結(jié)構(gòu)在添加時也添加2個鍵值對，時間與原有Hadoop方案相同。

在密鑰更新方面，更新流程為：首先，查詢該密鑰名的當(dāng)前元數(shù)據(jù)信息，獲取版本號并自加1，更新元數(shù)據(jù)；其次，添加新版本的密鑰信息鍵值對。原有Hadoop方案獲取元數(shù)據(jù)節(jié)點(diǎn)、更新元數(shù)據(jù)節(jié)點(diǎn)、新增密鑰節(jié)點(diǎn)，效率均為O(1)[+O(m)]；“密鑰串”新方案在相同步驟下的效率均為O(1)[+O(n)]+O(1)。同理，在密鑰名多、版本少的情況下，“密鑰串”新方案的效率會退化為與原有Hadoop方案類似。

2)擴(kuò)容次數(shù)減少，內(nèi)存組織速度加快

采用HashTable作為存儲加密區(qū)密鑰的數(shù)據(jù)結(jié)構(gòu)，在加密區(qū)密鑰數(shù)量達(dá)到閾值時會觸發(fā)擴(kuò)容。HashTable的最小數(shù)組元素數(shù)量為n=11，閾值為數(shù)組長度的，即最初數(shù)組元素數(shù)量達(dá)到時即觸發(fā)擴(kuò)容，擴(kuò)容后長度為n'=2n+1。當(dāng)加密區(qū)密鑰數(shù)量很大時，頻繁觸發(fā)HashTable擴(kuò)容會耗費(fèi)大量時間空間。

原有Hadoop方案中，新建一個二級密鑰會在HashTable中添加2個元素，更新一次再添加一個元素；而新方案中，新建一個密鑰只會在HashTable中添加一個元素，更新密鑰不添加元素。因此，原有Hadoop方案中HashTable的元素數(shù)量會頻繁到達(dá)閾值，觸發(fā)擴(kuò)容；而新方案的元素數(shù)量相對穩(wěn)定，不會頻繁觸發(fā)擴(kuò)容。

3)存儲空間降低

輸出至文件存儲時，不再采用Java自身的序列化機(jī)制，而是采用TLV（tag-length-value）格式緊湊輸出。存儲一個相同內(nèi)容的密鑰時，Java序列化將輸出2.48 KB大小，而TLV格式的輸出僅需1.64 KB，節(jié)省的存儲空間。

3.3 三級密鑰異步調(diào)度加解密文件

如圖3所示，當(dāng)前，Hadoop發(fā)行版的寫入文件過程包括4個階段。1)客戶端準(zhǔn)備文件數(shù)據(jù)階段?？蛻舳藦臄?shù)據(jù)源中讀取數(shù)據(jù)，將該數(shù)據(jù)切分成多個固定長度的數(shù)據(jù)分組，計(jì)算校驗(yàn)值，并將數(shù)據(jù)分組和校驗(yàn)值添加至發(fā)送隊(duì)列，消耗時間為T1。當(dāng)發(fā)送隊(duì)列已滿時，該階段會進(jìn)入阻塞狀態(tài)直到發(fā)送隊(duì)列有空閑位置。2)客戶端從發(fā)送隊(duì)列中獲取數(shù)據(jù)分組，將其通過網(wǎng)絡(luò)傳輸給數(shù)據(jù)節(jié)點(diǎn)DataNode，并添加該數(shù)據(jù)分組至待確認(rèn)隊(duì)列，消耗時間為T2。3)DataNode接收到數(shù)據(jù)分組后，校驗(yàn)數(shù)據(jù)完整性，檢查后將數(shù)據(jù)寫入文件塊中，并向客戶端返回確認(rèn)信息ACK，消耗時間為T3。4)客戶端收到DataNode返回的確認(rèn)信息后，從待確認(rèn)隊(duì)列中刪除數(shù)據(jù)分組，消耗時間為T4。在需要發(fā)送多數(shù)據(jù)的情況下，這4個階段并發(fā)執(zhí)行，但每階段內(nèi)部的執(zhí)行是串行的，每個階段各由一個線程完成。

特別地，當(dāng)需要向加密區(qū)寫入文件時，需要在客戶端對文件進(jìn)行加密，其加密過程在上述第一階段完成，即客戶端待發(fā)送數(shù)據(jù)分組為密文。具體地，第一階段可細(xì)化為3個步驟。步驟1，從明文數(shù)據(jù)源（例如客戶端的明文文件）中獲取明文，消耗時間為t1；步驟2，將明文加密為密文，消耗時間為t2；步驟3，將密文打包為固定長度的數(shù)據(jù)分組，并計(jì)算校驗(yàn)和，添加至發(fā)送隊(duì)列，消耗時間為t3。當(dāng)前，Hadoop版本存在如下問題使加解密效率低：1)這3個步驟串行執(zhí)行，不能并發(fā)執(zhí)行，存在加密空閑期，導(dǎo)致資源利用不充分；2)同步驟1和步驟3相比，步驟2耗時較長，即使這3個步驟并發(fā)執(zhí)行，也會使步驟1和步驟3需要等待步驟2完成，導(dǎo)致長時間阻塞。針對上述問題，本文提出了多線程流水線式并發(fā)加解密方案。

3.3.1 文件加密并發(fā)調(diào)度

為了解決加密空閑導(dǎo)致的低效率問題，必須盡可能確保加密過程不間斷。為此，本文提出基于流水線的并發(fā)加密方案，如圖4所示。

每條流水線至少包括3個線程：明文讀取線程、加密線程和密文處理線程。其中，明文讀取線程從明文數(shù)據(jù)源中讀取固定長度的明文，將其寫入明文緩沖隊(duì)列；加密線程從明文緩沖隊(duì)列中讀取固定長度的明文進(jìn)行加密，將得到的密文寫入密文緩沖隊(duì)列，在實(shí)際中可設(shè)置多個加密該線程（具體見3.3.2節(jié)）；密文處理線程從密文緩沖隊(duì)列中取出密文計(jì)算校驗(yàn)和，封裝并添加至發(fā)送隊(duì)列。從圖4可以看出，該流水線式調(diào)度方案中加密過程幾乎不間斷，加密資源被充分利用。

在Hadoop原加密流程的第一階段中，第k個數(shù)據(jù)段從明文數(shù)據(jù)源到進(jìn)入發(fā)送隊(duì)列總耗時T1(k)為

圖3 當(dāng)前Hadoop發(fā)行版的寫入文件過程

圖4 基于流水線的并發(fā)加密方案

若明文被切分為m個數(shù)據(jù)段，并且加密速度比文件讀寫速度慢，那么發(fā)送隊(duì)列不會滿，即第一階段不會進(jìn)入阻塞狀態(tài)，因此第一階段的總耗時為

由于加密時間較長，因此原始加密方式和流水線式加密方式具有如下特征

在式(3)情況下，流水線加密方式的第一階段總耗時為

由式(2)和式(4)可以得到

由于時間始終為正數(shù)，因此有

即流水線式的加密過程能縮短明文從數(shù)據(jù)源讀取經(jīng)過加密后被寫入密文緩沖隊(duì)列的總時間。

此外，式(5)可以說明流水線方案比原Hadoop方案縮短的時間包含2個部分，一是明文讀取線程與加密線程的并發(fā)時間，二是加密線程與密文處理線程的并發(fā)時間，這兩部分分別對應(yīng)式(5)最右側(cè)表達(dá)式中的第一項(xiàng)與第二項(xiàng)。

3.3.2 數(shù)據(jù)分段加密與同步

為了解決明文加密時間長問題，本文在上述流水線中設(shè)置多個加密線程，每個加密線程均可從明文緩沖隊(duì)列里取明文數(shù)據(jù)，并將加密得到的密文放入密文緩沖隊(duì)列，實(shí)現(xiàn)多段明文數(shù)據(jù)的并發(fā)加密，從而縮短整個明文的加密時間。

在分段加密中每個加密線程加密時間不相同，可能導(dǎo)致同步問題。例如，加密線程A1和A2順序取明文段P1和P2，并獨(dú)立加密，若A2對P2的加密時間小于A1對P1的加密時間，則可能導(dǎo)致P2的密文先寫入密文緩沖隊(duì)列，從而導(dǎo)致亂序密文。為此，本文提出基于密文排序的多加密線程密文同步方案。

該方案為每一個明文段/密文段依照其先后順序依次分配唯一的遞增整數(shù)序列號seq，相鄰數(shù)據(jù)段序列號之差為1。為了對密文進(jìn)行重組排序，采用臨時鏈表tmpList來按照seq序列號順序存儲密文段。當(dāng)密文緩沖隊(duì)列接收到來自臨時鏈表中序列號為n的密文段后，通過設(shè)置與臨時鏈表共享的等待序列號ackSeq為n+1來告知臨時鏈表：下一個需要發(fā)送的密文段序列號為n+1；當(dāng)臨時鏈表中第一個密文段序列號為ackSeq時，它將該密文段發(fā)送給密文緩沖隊(duì)列，并從臨時鏈表中移除。

圖5給出了一個例子，在該例中，3個加密線程（記為encrypt1、encrypt2和encrypt3）分別加密第6、4、8段明文（即encrypt1=6，encrypt2=4，encrypt3=8）。臨時鏈表tmpList中按序存儲第5、7段密文，記為tmpList={5,7}。密文緩沖隊(duì)列中已有密文2、3，正在等待第4段密文的寫入，記為outQueue={2,3}，ackSeq=4。圖5的編號①～⑩為第4段明文與第8段明文先后加密完成時本文算法所執(zhí)行的10個步驟。

步驟1加密線程2加密完第4段明文后，將第4段密文按序插入臨時鏈表中，此時tmpList={4,5,7}。

步驟2臨時鏈表判斷首元素序列號4是否與ackSeq相等，判斷結(jié)果為“是”，然后將第4段密文從臨時鏈表中移除，添加至密文緩沖隊(duì)列中，此時tmpList={5,7}，outQueue={2,3,4}。

步驟3密文緩沖隊(duì)列將等待序列號ackSeq增加1，此時ackSeq=5。

圖5 并發(fā)加密的密文重排序算法

步驟4臨時鏈表判斷首元素序列號5是否與ackSeq相等，判斷結(jié)果為“是”，然后將第5段密文從臨時鏈表中移除，添加至密文緩沖隊(duì)列中，此時tmpList={7}，outQueue={2,3,4,5}。

步驟5密文緩沖隊(duì)列將等待序列號ackSeq增加1，此時ackSeq=6。

步驟6臨時鏈表判斷首元素序列號7是否與ackSeq相等，判斷結(jié)果為“否”，不能向密文緩沖隊(duì)列中寫入第7段密文。

步驟7加密線程2從明文緩沖隊(duì)列中讀取明文段9并開始加密，此時encrypt2=9。

步驟8加密線程3加密完第8段明文后，將第8段密文按序插入臨時鏈表中，此時tmpList={7,8}。

步驟9臨時鏈表判斷首元素序列號7是否與ackSeq相等，判斷結(jié)果為“否”，不能向密文緩沖隊(duì)列中寫入第7段密文。

步驟10加密線程3從明文緩沖隊(duì)列中讀取明文段10并開始加密，此時encrypt3=10。

從上述例子可看出，盡管明文段4、5、7、8的加密不是按序完成的，但它們的密文會在臨時鏈表內(nèi)排序重組，從而確保將原本亂序的4個密文段順序?qū)懭朊芪木彌_隊(duì)列，所以本文方案能夠有效地解決多加密線程密文同步問題。

基于上述分析，本文給出多線程流水線式并發(fā)加解密算法流程，該流程包括3個部分的算法：明文讀取線程算法、加密線程算法、密文處理線程算法，如算法1～算法3所示。其中，inQ表示明文緩沖隊(duì)列，outQ表示密文緩沖隊(duì)列，list表示臨時鏈表，len表示數(shù)據(jù)源dataSource內(nèi)的待加密明文長度，seq表示下一個明文段應(yīng)分配的序列號，ack表示密文緩沖隊(duì)列正在等待的密文段序列號，buffSize為每個明文段/密文段的長度，stop表示明文是否讀取完畢。

4 實(shí)驗(yàn)分析

4.1 實(shí)驗(yàn)環(huán)境

基于本文架構(gòu)在局域網(wǎng)中搭建實(shí)驗(yàn)環(huán)境，實(shí)驗(yàn)環(huán)境分別包括一個NameNode管理節(jié)點(diǎn)node 0、3個DataNode數(shù)據(jù)節(jié)點(diǎn)node1～node3、一個KMS服務(wù)器節(jié)點(diǎn)node4，以及若干Client客戶端節(jié)點(diǎn)模擬用戶訪問。根據(jù)Hadoop大數(shù)據(jù)平臺架構(gòu)，NameNode節(jié)點(diǎn)node0存儲文件密鑰節(jié)點(diǎn)，并管理3個DataNode數(shù)據(jù)節(jié)點(diǎn)，node2和node3為node1的備份節(jié)點(diǎn)，KMS服務(wù)器節(jié)點(diǎn)node 4管理和存儲一級密鑰（密鑰庫口令）和二級密鑰。拓?fù)淙鐖D6所示。

4.2 效果分析

4.2.1 二級密鑰的存取效率性能

本文所提密鑰串管理方案的關(guān)鍵在于存儲結(jié)構(gòu)的變化。為避免JDK（Java SE development kit）調(diào)用帶來的影響，本次實(shí)驗(yàn)共設(shè)置6組對比實(shí)驗(yàn)。1)使用Hadoop原有方案的結(jié)構(gòu)，在本地實(shí)現(xiàn)HashTable和3DES加密算法。2)使用本文的“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，在本地實(shí)現(xiàn)HashTable和3DES加密算法。3)使用本文的“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，在本地實(shí)現(xiàn)HashTable和SM4加密算法，數(shù)據(jù)存儲過程無序列化。4)僅實(shí)現(xiàn)本文“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，作為空白對比。5)僅實(shí)現(xiàn)本文的“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，數(shù)據(jù)存儲過程無序列化，作為空白對比。6)僅實(shí)現(xiàn)本文“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，數(shù)據(jù)存儲過程無序列化，且刪除過程簡化，作為空白對比。

密鑰管理包括密鑰的生成、更新和查詢等，Hadoop平臺的二級密鑰均在KMS本地使用，不涉及分發(fā)的問題。因此依次測試各類結(jié)構(gòu)在以下4個生命周期的密鑰管理中所需的時間：創(chuàng)建n個密鑰，每個密鑰更新100個版本的密鑰，隨機(jī)查找n個密鑰，刪除所有密鑰。

圖6 所用實(shí)驗(yàn)部署環(huán)境

因每一次的操作耗時在納秒級，小量測試不足以區(qū)分各方案之間的優(yōu)劣。本文采用逐級遞增的大數(shù)據(jù)量進(jìn)行測試，即n的范圍為1～200（以10為單位遞增），以全部運(yùn)算之后的總時長進(jìn)行比較。

實(shí)驗(yàn)結(jié)果如圖7所示。由圖7可以得出多種方案中密鑰創(chuàng)建、更新、查詢、刪除的效率對比。圖7的共有特點(diǎn)是所有不加密的方案比同結(jié)構(gòu)的加密方案效率高，所有不使用序列化的方案比使用序列化的方案效率高，與已知常識一致。

在密鑰創(chuàng)建方面，“密鑰串”新方案比原有Hadoop方案速度快，使用無序列化的SM4加密方案比3DES加密方案速度快。在密鑰更新方面，當(dāng)前為少密鑰名、多版本號的情況，“密鑰串”新方案比原有Hadoop方案速度快，使用無序列化的SM4加密方案幾乎可與序列化的無加密方案速度持平。在密鑰查詢方面，“密鑰串”新方案比原有Hadoop方案速度快，可以提升Hadoop密鑰使用過程中的查詢效率。在密鑰刪除方面，只有第6組實(shí)驗(yàn)優(yōu)化了刪除流程，只需按密鑰名刪除整個節(jié)點(diǎn)、不需要逐個刪除密鑰，效率明顯優(yōu)于其他5組實(shí)驗(yàn)。與3.2.2節(jié)效率分析一致。

4.2.2 多線程流水線式并發(fā)加解密

圖7 多種方案的密鑰操作效率對比

本文所提出的流水線式并發(fā)加解密方案中，提高加解密速度的關(guān)鍵因素在于兩點(diǎn)：一是串行加解密改為流水線式加解密，將明文讀取、密文處理與加解密3個步驟并發(fā)執(zhí)行，從而縮短明文從數(shù)據(jù)源中被讀出經(jīng)過加密并打包添加至發(fā)送隊(duì)列的總時間；二是增加加解密線程的個數(shù)，使不同的明文段能夠同時加密，從而縮短整個明文的加密時間。

根據(jù)上述兩點(diǎn)因素，本實(shí)驗(yàn)測試了不加密、串行加密、流水線式加密、2線程并發(fā)加密、3線程并發(fā)加密以及4線程并發(fā)加密共6種條件下的文件寫入速度。由于同一時間內(nèi)，用戶可能會同時向加密區(qū)內(nèi)寫入多個文件，因此實(shí)驗(yàn)在上述各條件下分別測定了同時向加密區(qū)內(nèi)寫入1～5個文件所花費(fèi)的時間，根據(jù)寫入文件的總大小計(jì)算得出文件的寫入速度。實(shí)驗(yàn)結(jié)果如圖8所示，在明文數(shù)據(jù)段大小為8 KB下測得的寫入速度。

圖8 文件分段大小為8 KB時的加密寫入速度

從圖8中可以看出，不加密時文件寫入速度基本穩(wěn)定在2.2 Gbit/s左右，而HDFS原本的串行加密方式在同時寫入一個文件時，速度只有0.8 Gbit/s，與不加密時相比性能大打折扣。隨著同時寫入文件數(shù)的增大時，各文件的并發(fā)加密使加密資源逐漸被充分利用，從而寫入速度逐漸提升。

采用流水線式加密方案后，文件寫入速度相對于串行加密方式有小幅提升，與前面的分析一致，這部分速度的提升來自式(5)所計(jì)算的時間差。

采用多線程并發(fā)加解密方案后，可以看出，隨著加密線程數(shù)量的增多，文件寫入速度大幅提升。當(dāng)采用4個線程進(jìn)行并發(fā)加密時，即使同時只寫入一個文件，寫入速度也幾乎接近不加密的寫入速度。

與原有Hadoop方案的AES算法相比，替換SM4算法在串行方案中并不占優(yōu)，而在流水線式加密方案和多線程并發(fā)加解密方案中，快于原有Hadoop方案的AES算法。

由此可見，本文的多線程并發(fā)加解密方案確實(shí)能夠高效地完成文件加密，能夠使用戶在通過文件加密的方式保障安全性的同時，不損失文件讀寫的效率。

5 結(jié)束語

本文針對Hadoop平臺密鑰管理復(fù)雜、數(shù)據(jù)加解密性能低的問題，提出一種面向Hadoop平臺的高效密鑰管理方案，該方案通過Hadoop平臺三層密鑰管理體系，結(jié)合國產(chǎn)商用系列密碼算法，實(shí)現(xiàn)多級密鑰系統(tǒng)管理與保護(hù)，優(yōu)化二級密鑰組織方式提高密鑰的存取效率，流水線作業(yè)的異步調(diào)度加密資源，優(yōu)化文件加密的流程，提升加密性能，并通過密文重排機(jī)制，恢復(fù)異步加密數(shù)據(jù)的原有順序。模擬實(shí)驗(yàn)結(jié)果表明，該方案可以有效提升Hadoop靜態(tài)加密速度，同時減少空間占用。