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

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

2 相關(guān)工作

2.1 面向Hadoop平臺(tái)的加解密

如前文所述，面向Hadoop平臺(tái)的加解密主要聚焦于傳輸加密、存儲(chǔ)加密及其高性能實(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的安全使用。

在存儲(chǔ)加密方面，HBase支持HFile v3單數(shù)據(jù)項(xiàng)級(jí)的數(shù)據(jù)庫加密，使用兩級(jí)密鑰，并使用SASL協(xié)議和Kerberos協(xié)議分別為RPC和ZooKeeper進(jìn)行認(rèn)證。Apache Hadoop自2.6.0版本始添加了端到端的透明加解密機(jī)制，用戶可設(shè)置加密區(qū)，向加密區(qū)上傳/下載文件時(shí)，數(shù)據(jù)在客戶端自動(dòng)加解密，實(shí)現(xiàn)傳輸安全和存儲(chǔ)安全，支持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平臺(tái)中建立基于雙線性橢圓曲線的認(rèn)證和加密機(jī)制，并對(duì)數(shù)據(jù)訪問進(jìn)行審計(jì)，保護(hù)Hadoop平臺(tái)數(shù)據(jù)安全，但基于非對(duì)稱密鑰的運(yùn)算開銷較大，配置復(fù)雜。Wang等[4]借助Hadoop平臺(tái)和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平臺(tái)數(shù)據(jù)機(jī)密性，并進(jìn)行仿真驗(yàn)證。上述工作主要聚焦于Hadoop平臺(tái)下傳輸與存儲(chǔ)中加解密的透明性，忽略了Hadoop環(huán)境下對(duì)加解密的性能需求。

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

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

2.2 密鑰管理機(jī)制

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

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

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

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

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

1)一級(jí)密鑰管理

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

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

2)二級(jí)密鑰管理

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

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

3)三級(jí)密鑰管理

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

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

3.2 二級(jí)密鑰的快速存取

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

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

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

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

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

3.2.2 二級(jí)密鑰存取效率分析

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

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

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

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

在密鑰刪除方面，原有Hadoop方案需先獲取待刪除密鑰的當(dāng)前版本號(hào)n，隨后逐個(gè)移除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個(gè)鍵值對(duì)（一個(gè)密鑰描述信息的和一個(gè)密鑰數(shù)據(jù)），添加速度均為O(1)。而“密鑰串”結(jié)構(gòu)在添加時(shí)也添加2個(gè)鍵值對(duì)，時(shí)間與原有Hadoop方案相同。

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

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

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

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

3)存儲(chǔ)空間降低

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

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

如圖3所示，當(dāng)前，Hadoop發(fā)行版的寫入文件過程包括4個(gè)階段。1)客戶端準(zhǔn)備文件數(shù)據(jù)階段?？蛻舳藦臄?shù)據(jù)源中讀取數(shù)據(jù)，將該數(shù)據(jù)切分成多個(gè)固定長(zhǎng)度的數(shù)據(jù)分組，計(jì)算校驗(yàn)值，并將數(shù)據(jù)分組和校驗(yàn)值添加至發(fā)送隊(duì)列，消耗時(shí)間為T1。當(dāng)發(fā)送隊(duì)列已滿時(shí)，該階段會(huì)進(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ì)列，消耗時(shí)間為T2。3)DataNode接收到數(shù)據(jù)分組后，校驗(yàn)數(shù)據(jù)完整性，檢查后將數(shù)據(jù)寫入文件塊中，并向客戶端返回確認(rèn)信息ACK，消耗時(shí)間為T3。4)客戶端收到DataNode返回的確認(rèn)信息后，從待確認(rèn)隊(duì)列中刪除數(shù)據(jù)分組，消耗時(shí)間為T4。在需要發(fā)送多數(shù)據(jù)的情況下，這4個(gè)階段并發(fā)執(zhí)行，但每階段內(nèi)部的執(zhí)行是串行的，每個(gè)階段各由一個(gè)線程完成。

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

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

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

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

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

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

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

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

由于加密時(shí)間較長(zhǎng)，因此原始加密方式和流水線式加密方式具有如下特征

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于上述分析，本文給出多線程流水線式并發(fā)加解密算法流程，該流程包括3個(gè)部分的算法：明文讀取線程算法、加密線程算法、密文處理線程算法，如算法1～算法3所示。其中，inQ表示明文緩沖隊(duì)列，outQ表示密文緩沖隊(duì)列，list表示臨時(shí)鏈表，len表示數(shù)據(jù)源dataSource內(nèi)的待加密明文長(zhǎng)度，seq表示下一個(gè)明文段應(yīng)分配的序列號(hào)，ack表示密文緩沖隊(duì)列正在等待的密文段序列號(hào)，buffSize為每個(gè)明文段/密文段的長(zhǎng)度，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)境分別包括一個(gè)NameNode管理節(jié)點(diǎn)node 0、3個(gè)DataNode數(shù)據(jù)節(jié)點(diǎn)node1～node3、一個(gè)KMS服務(wù)器節(jié)點(diǎn)node4，以及若干Client客戶端節(jié)點(diǎn)模擬用戶訪問。根據(jù)Hadoop大數(shù)據(jù)平臺(tái)架構(gòu)，NameNode節(jié)點(diǎn)node0存儲(chǔ)文件密鑰節(jié)點(diǎn)，并管理3個(gè)DataNode數(shù)據(jù)節(jié)點(diǎn)，node2和node3為node1的備份節(jié)點(diǎn)，KMS服務(wù)器節(jié)點(diǎn)node 4管理和存儲(chǔ)一級(jí)密鑰（密鑰庫口令）和二級(jí)密鑰。拓?fù)淙鐖D6所示。

4.2 效果分析

4.2.1 二級(jí)密鑰的存取效率性能

本文所提密鑰串管理方案的關(guān)鍵在于存儲(chǔ)結(jié)構(gòu)的變化。為避免JDK（Java SE development kit）調(diào)用帶來的影響，本次實(shí)驗(yàn)共設(shè)置6組對(duì)比實(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ù)存儲(chǔ)過程無序列化。4)僅實(shí)現(xiàn)本文“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，作為空白對(duì)比。5)僅實(shí)現(xiàn)本文的“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，數(shù)據(jù)存儲(chǔ)過程無序列化，作為空白對(duì)比。6)僅實(shí)現(xiàn)本文“密鑰串”新方案的數(shù)據(jù)結(jié)構(gòu)，不實(shí)現(xiàn)加密過程，數(shù)據(jù)存儲(chǔ)過程無序列化，且刪除過程簡(jiǎn)化，作為空白對(duì)比。

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

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

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

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

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

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

圖7 多種方案的密鑰操作效率對(duì)比

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

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

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

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

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

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

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

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

5 結(jié)束語

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