Hadoop作為一個開源的分布式編程框架，已逐漸成為計算機行業(yè)最新的潮流。其分布式文件系統(tǒng)(HDFS)，可存儲大量數(shù)據(jù)，具有高容錯性和吞吐量。然而，目前的HDFS不支持云內的數(shù)據(jù)加密，則使得數(shù)據(jù)的私密性成為一個至關重要的安全問題。為此我們提出了一種基于HDFS的混合加密方法。

一、HDFS的數(shù)據(jù)加密

為了實現(xiàn)數(shù)據(jù)存儲持久和讀取便捷，HDFS將文件分割成預定好數(shù)據(jù)大小的數(shù)據(jù)塊格式，集群則被分成一個負責管理元數(shù)據(jù)的主節(jié)點和多個存儲塊文件的數(shù)據(jù)節(jié)點。主節(jié)點是整個云存儲服務的入口，其中元數(shù)據(jù)包含的信息有命名空間、訪問控制信息、文件塊位置和文件塊的對應關系等。數(shù)據(jù)節(jié)點則是用來存儲云端數(shù)據(jù)文件，每一個經過客戶端分割后的文件塊都有唯一的ID進行標識。

1、系統(tǒng)架構

我們的安全目標是阻止攻擊者在入侵數(shù)據(jù)節(jié)點之后竊取文件信息。正如圖l所示，將加密和解密模塊放人數(shù)據(jù)節(jié)點中，模塊采用AES算法在對數(shù)據(jù)塊進行寫操作之前完成加密運算；反之，在對數(shù)據(jù)塊進行讀操作之前進行解密運算。一個數(shù)據(jù)塊用同一個存儲在數(shù)據(jù)節(jié)點上的密鑰進行加解密操作。密鑰管理模塊在數(shù)據(jù)節(jié)點中實現(xiàn)。相對于數(shù)據(jù)節(jié)點與主節(jié)點之間的通信協(xié)議維持不變，在客戶端和數(shù)據(jù)節(jié)點之間則加入了驗證協(xié)議和密鑰交換協(xié)議。

2、密鑰管理

如果密鑰以明文形式存儲在數(shù)據(jù)節(jié)點上，將無法保證僅僅通過加密文件操作就能確保用戶的私密性，因為攻擊者勢必能夠在惡意攻擊到數(shù)據(jù)節(jié)點后獲取到明文密鑰信息從而完成數(shù)據(jù)文件的解密操作。為了有效解決這個問題，采用非對稱加密算法RSA對AES密鑰進行加密，而后再將其存儲在數(shù)據(jù)節(jié)點中?？蛻舳素撠熒蒖SA密鑰對，并且存放其中的私鑰，公鑰則被主節(jié)點存儲在元數(shù)據(jù)中。圖2展示了混合加密方案的基本流程，其中，待加密文件被分成N個數(shù)據(jù)塊，分別為B1，B2，…，Bn，每個數(shù)據(jù)塊都有與其對應的AES密鑰kbn。

3、系統(tǒng)實現(xiàn)

采用Java庫函數(shù)中的JEC(Java CryptographyExtension)來實現(xiàn)加密算法。在AES加解密算法中選用CFB模式，該模式數(shù)據(jù)塊被細分成連續(xù)的16B小塊，末尾不足16 B的部分也不預補足。這樣選擇的原因是CFB模式滿足了AES加密后數(shù)據(jù)塊長度不變的特性，也就是說1個默認大小(64 MB)的數(shù)據(jù)節(jié)點數(shù)據(jù)塊在經過AES-CFB的加密后不會發(fā)生長度的改變，從而破壞整個系統(tǒng)的基礎環(huán)境設定。

（1）加密方案

加密模塊被加入在數(shù)據(jù)節(jié)點代碼中生成文件代碼段的位置。圖3描述了加密過程的時序?？蛻舳嗽诔跏蓟瘯r生成RSA密鑰對，然后公鑰被上傳到主節(jié)點中。當客戶端請求主節(jié)點創(chuàng)建一個文件時，主節(jié)點發(fā)回一個含有數(shù)據(jù)節(jié)點鏈表和客戶端RSA公鑰的元數(shù)據(jù)。對每個文件塊，客戶端從管道中發(fā)送公鑰到第一個數(shù)據(jù)節(jié)點而后將數(shù)據(jù)塊分包上傳。在接收到新的塊后數(shù)據(jù)節(jié)點生成一個AES會話密鑰用于加密數(shù)據(jù)塊文件，而之前的RSA公鑰則用來加密這個AES會話密鑰。最終，加密后的文件塊和加密后的AES密鑰分別獨立存儲在數(shù)據(jù)節(jié)點的本地磁盤中。后續(xù)的數(shù)據(jù)節(jié)點則通過管道接收加密后的文件塊信息，而無需重復加密工作，從而節(jié)省服務器資源。

應當注意到，HDFS文件系統(tǒng)會定期檢查存儲在數(shù)據(jù)節(jié)點中文件塊的CRC(Cyclic RedundancyCheck)冗余校驗碼，以確保存儲在云端數(shù)據(jù)的可靠性，以防應為存放時間長久由于磁盤錯誤而引起的數(shù)據(jù)失效問題?？蛻舳嗽诎l(fā)送數(shù)據(jù)前為每個數(shù)據(jù)塊計算出一個512 B的CRC冗余校驗碼，一并將其上傳至數(shù)據(jù)節(jié)點中。數(shù)據(jù)節(jié)點會周期性的計算磁盤內數(shù)據(jù)塊的CRC冗余校驗碼，并與初始的CRC冗余校驗碼相比較，以確保文件的可靠性。由于加密后的數(shù)據(jù)塊的CRC32冗余校驗碼必然與明文時的不同，所以在加密后還需重新計算一個新的CRC冗余校驗碼，以應對這一機制。

（2）解密方案

正如圖4所示，在數(shù)據(jù)節(jié)點接收到客戶端的讀數(shù)據(jù)請求后，將首先發(fā)送給客戶端所讀數(shù)據(jù)塊相對應的AES密鑰的密文。客戶端用RSA私鑰解密后再將AES密鑰明文發(fā)回給數(shù)據(jù)節(jié)點。最后，有數(shù)據(jù)節(jié)點完成數(shù)據(jù)塊的解密工作后發(fā)還給客戶端。

二、性能測試

1、測試環(huán)境

實驗在1個只有2臺機器的環(huán)境中進行。主節(jié)點硬件配置為Intel Xeon 8-core 2.00 GHz，10 GB內存，1TB硬盤。數(shù)據(jù)節(jié)點硬件配置為Intel Xeon 16-core 2.20 GHz．20 GB內存，2TB硬盤。數(shù)據(jù)副本設為1。

2、改進系統(tǒng)與原生系統(tǒng)的對比測試

在上述加解密方案中，系統(tǒng)開銷可分為兩部分。一部分是數(shù)據(jù)塊加解密運算的開銷，另一部分開銷則是花費在密鑰管理，CRC冗余校驗碼的重新計算上。將對包含加解密運算的系統(tǒng)總開銷和不含加解密才做的新系統(tǒng)架構開銷分別進行測試，并與原生系統(tǒng)進行詳盡的對比。

（1）加密測試

在加密測試環(huán)節(jié)，我們通過上傳不同大小的文件，對包含加密運算的新系統(tǒng)和原生系統(tǒng)在寫操作下的吞吐量進行了對比。如圖5所示，新系統(tǒng)和原生系統(tǒng)的吞吐量分別在上傳512 MB和256 MB的時候達到頂峰。性能的衰減隨著上傳文件塊的大小變化而變化，在文件大小為256 MB時，衰減為最大，達到53%；當數(shù)據(jù)塊大小為8 MB時，衰減為最小，低于33%。

很明顯可以看出，性能的衰減主要是因為加密操作的引入，因為若新架構的系統(tǒng)不進行加密運算，則增加的系統(tǒng)開銷不足2%。因為大量的AES加密運算消耗了一定量的CPU資源，使得本來專注于HDFS系統(tǒng)調度的CPU不得不增加其在運算中的開銷。后續(xù)研究中，將引入通用計算技術( GPGPU)，徹底改觀HDFS系統(tǒng)吞吐量大幅衰減的現(xiàn)象。

（2）解密測試

通過與加密測試相對應的測試方法，分別讀取在加密測試環(huán)節(jié)中上傳至數(shù)據(jù)節(jié)點中的文件，從而評估解密環(huán)節(jié)的性能開銷。如圖6所示，讀取速度1.4倍于寫入速度，因為磁盤的讀取速度比寫入速度要高。由于解密運算和加密運算占用的CPU資源是一樣多的，所以解密階段的性能衰減比加密階段高出了75%，但新架構帶來的系統(tǒng)額外開銷依然在2%以內。

admin

收藏 海報分享