李春杰+張啟軍+譚嘉瑞+顏智潤

摘 要：對文件內容加密，可有效解決數據泄露問題。目前傳統(tǒng)的第三方軟件多采用非透明式加密，對用戶而言，操作不便；新型的堆疊式文件加密方案可以有效解決透明性問題，但此類設計方案實施較為復雜，并存在內核版本依賴性。文中采用Hook機制，通過監(jiān)控用戶對指定文件目錄進行操作，捕獲用戶對該目錄具體文件的訪問；自動調用應用層的加解密模塊，完成對具體文件的加解密，解決透明性問題。由于該系統(tǒng)的加解密功能在應用層實現，與具體文件系統(tǒng)無關，因此又可以有效簡化系統(tǒng)設計，災難恢復性強，穩(wěn)定性高。

關鍵詞：數據加密；進程間約束；消息Hook機制；鎖機制

中圖分類號：TP309.7；TP316.81 文獻標識碼：A 文章編號：2095-1302（2018）02-00-03

0 引 言

最近幾年，基于Linux內核開發(fā)的操作系統(tǒng)逐漸從服務端走向用戶終端。尤其某些單位，從服務器到個人終端都以Linux作為系統(tǒng)支撐。因此，對于存放在Linux上的敏感數據進行加密保護，已成為一個急需解決的問題。

多數第三方加密軟件均采用非透明式文件存儲方式，需要用戶在打開指定文件時調用解密模塊；同樣，當用戶關閉文件時，需要調用加密模塊，導致體驗效果不好。

新型堆疊式文件加密系統(tǒng)[1]雖然可以解決用戶透明性問題，但需要重新設計一個新的文件管理層，用以對文件加密，因此需要對加密文件系統(tǒng)進行重新設計。此類方案對于設計者而言，需要深入掌握Linux各方面的知識，如文件系統(tǒng)管理、內存管理、驅動設計等。雖然設計方案在理論上可行，但在系統(tǒng)的具體實現過程中卻十分復雜，而且開發(fā)周期長，成本昂貴，短期內看不出測試結果。

1 整體方案設計

該系統(tǒng)使用文件鎖[2]和消息Hook機制[3]進行設計，既可以有效解決用戶透明性問題，又可以降低整體設計難度。如圖1所示，系統(tǒng)中目錄A作為被監(jiān)控目錄，用于存放需要加密的文件，目錄B可以視為緩存目錄或者備份目錄。當明文文件被存放到目錄A中時，加密子進程在目錄B中創(chuàng)建一個新的臨時文件，用以保存加密之后的密文。當明文文件加密完成后，再利用目錄B中的臨時密文文件替換目錄A中的文件。同樣，當需要對目錄A中的密文文件解密時，讀取目錄B中的臨時密文文件，然后調用解密子進程對其解密，最后將解密之后的數據覆蓋目錄A的密文文件。

整體方案只需調用Linux提供的接口就可以完成設計，且絕大部分數據處理過程都位于應用層。即便系統(tǒng)遇到不可控因素而產生災難性后果，也可以在現有文件系統(tǒng)中找到保存完整的加密數據，對其進行解密操作，有效解決文件恢復問題?？梢钥闯?，基于應用層的方案設計無須對Linux內核進行深層次的修改，降低了開發(fā)難度。

2 關鍵技術點

目錄A和目錄B間的數據交換需要多個子進程先后進行協(xié)調工作，包括維護子進程、加密子進程、解密子進程。如果用戶操作目錄A以及目錄A中的文件，那么維護子進程就能夠捕捉到用戶的操作，并且通知其他子進程進行后續(xù)操作。

系統(tǒng)方案的設計需要解決兩個技術點，即監(jiān)控目錄和進程間控制。

2.1 監(jiān)控目錄

在Linux內核最新版本中添加了監(jiān)控操作文件的消息Hook模塊，即inotify，利用inotify作為實現監(jiān)控目錄的核心。

監(jiān)控模塊經過初始化后，返回相應的監(jiān)控實例id，然后將需要監(jiān)控的對象路徑添加到監(jiān)控實例中，這些對象可以是文件，也可以是文件目錄。若不監(jiān)控該對象，則可以從監(jiān)控實例中移除。

監(jiān)控用戶操作文件并產生消息隊列的過程如圖2所示。當用戶對監(jiān)控目錄A中的文件進行操作時，消息Hook模塊便對虛擬文件系統(tǒng)（VFS）進行監(jiān)控，將用戶的操作類型通過消息方式發(fā)送到應用層的消息隊列中，使得后臺維護子進程（通過輪詢方式）能夠實時捕捉。

維護子進程通過讀取消息隊列[4]判斷產生的事件并調用對應的加密或解密子進程。通常用戶在訪問一個文件時，可能會產生連續(xù)多個消息事件。例如，用戶打開一個加密文件，監(jiān)控模塊首先產生IN_OPEN消息事件，然后產生IN_WRITE消息事件，最后產生IN_CLOSE消息事件。因此，在監(jiān)控一個對象時，需要維護子進程依次捕獲該對象所產生的一系列消息事件，判斷當前監(jiān)控對象需要進行的操作。

2.2 進程間控制

用戶使用編輯器等軟件打開目錄A中的密文文件，維護子進程自動調用加解密模塊完成文件解密過程，將解密之后的明文數據呈現給用戶。在解密過程中，采用文件鎖方式使用戶進程產生等待，便于解密模塊解密。

但多數編輯軟件在打開文件時不檢查文件鎖，而是直接讀取文件內容，因此用戶讀取的是密文數據。為了使這些軟件產生等待，在文件打開時，需要將這些軟件產生的進程強制性地檢查文件是否被鎖定。由于這些進程打開的文件最終都需要調用內核層中的open函數，所以需要修改Linux內核中系統(tǒng)定義的open部分[5]。

在Linux內核中需要添加文件鎖檢測函數，命名為myFlock。由于內核中Flock的系統(tǒng)定義只能提供給上層進行系統(tǒng)調用而不能直接被內核層的其他函數調用，所以需要在do_sys_open中調用自定義的鎖。由于內核中的函數都通過EXPORT_SYMBOL等方式輸出全局信號量[6]，因此，Flock和myFlock可以通過調用全局輸出的信號量來共享緩存隊列，從而使得其他進程在打開文件時強制檢查鎖。此外，內核層中進程之間的約束過程如下：

（1）在控制進程中，密文文件被維護子進程調用flock（），維護子進程持有加密文件鎖；

（2）將與密文文件相關的信息加入緩存隊列中；

（3）其他進程打開文件需要調用open（）函數，在do_sys_open（）返回文件描述符之前[7]，需要先調用myFlock（）自定義鎖；endprint

（4）若該文件是被監(jiān)控文件，則其他進程的訪問需要等待文件鎖釋放；

（5）do_sys_open（）將通過系統(tǒng)調用open（）返回文件描述符給其他進程；

（6）其他進程讀取文件。

文中詳述了利用文件鎖方式進行進程間控制的過程，使得多個并發(fā)進程能夠有序調度。如果打開的對象不是被監(jiān)控文件，那么其他進程在內核層中獲取鎖之后應該立即釋放文件鎖，避免整個系統(tǒng)被鎖死。

3 模塊方案設計

雖然系統(tǒng)中有多個子進程先后協(xié)調工作，但為了降低方案設計的復雜度，可以將系統(tǒng)分為加密過程和解密過程[8]兩部分。

3.1 讀解密操作

對于用戶而言，監(jiān)控目錄下存放的文件雖然以密文數據的形式存放在磁盤中，但當用戶訪問文件時，文件應當以明文形式呈現給用戶。

如圖3所示，當用戶打開一份密文文件時，需要先讓用戶等待。此時的監(jiān)控模塊產生IN_OPEN消息并插入到消息隊列中，然后維護子進程捕獲該消息，調用解密子過程直到解密完成后，返回維護子進程使得維護子進程釋放目錄A下的文件鎖，用戶再讀取解密文件時便可以獲得明文。系統(tǒng)的解密過程如下：

（1）維護進程初始化時會掃描目錄A下的文件及目錄，并把這些目錄和文件的絕對路徑放入到已加密文件的監(jiān)控鏈表中，同時給文件添加文件鎖（系統(tǒng)默認目錄A中已存在的文件為密文或目錄為空）；

（2）用戶打開目錄A中的加密文件2，監(jiān)控模塊產生IN_OPEN消息事件，由于文件鎖的存在，使得用戶進程產生等待；

（3）維護子進程通過不斷輪詢捕獲到該消息并查找已加密文件監(jiān)控鏈表，判斷該消息所代表的文件是否為密文；

（4）復制目錄A中的加密文件2到目錄B中；

（5）維護子進程調用解密程序，解密程序讀取目錄B中的加密文件2并解密，將解密之后的數據寫入目錄A中的解密文件2中；

（6）解密完成，解密程序將加密文件2從已加密文件監(jiān)控鏈表中移除，并將其添加到待加密的文件鏈表（在監(jiān)控目錄A中以明文形式存在的文件）中；

（7）維護子進程刪除目錄B中的加密文件2并釋放目錄A中解密文件2的文件鎖；

（8）用戶讀取解密文件2。

需要注意的是待加密的文件鏈表中存放的是目錄A中未加密的明文文件節(jié)點，當用戶讀取文件數據或者其他操作結束之后便關閉該文件并產生IN_CLOSE消息事件，此時就需要維護線程通過讀取待加密的文件鏈表，重新對該目錄A中的明文文件進行加密處理。解密過程如圖4所示。

3.2 寫加密操作

存在于目錄A下的明文文件可以來源于從其他目錄轉移到目錄A中的新明文文件，或者用戶讀取目錄A中的密文文件時通過讀解密操作之后留下的明文文件。針對第二種情況，在上述解密操作過程中，后臺子進程已自動將解密文件相關信息添加到了待加密文件鏈表中，當IN_CLOSE消息到來時就可以通過加密程序對明文文件進行加密操作。然而，對于第一種情況，監(jiān)控模塊也會產生對應的IN_OPEN以及IN_CLOSE消息。因此，只要將監(jiān)控目錄中的新文件相關信息加入到待加密文件鏈表中，IN_CLOSE消息到來時就可通過加密程序對新明文文件進行加密操作。如圖5所示，系統(tǒng)的加密過程如下：

（1）訪問監(jiān)控目錄A并產生相應消息事件；

（2）如果是一份新明文文件N，那么監(jiān)控模塊將依次產生IN_OPEN和IN_CLOSE等多個重要的消息；

（3）維護進程首先掃描消息鏈表，得到IN_OPEN消息；

（4）將明文文件N的節(jié)點添加到待加密的文件鏈表中；

（5）維護子進程繼續(xù)掃描消息隊列；

（6）維護子進程掃描IN_CLOSE消息，在待加密文件鏈表里找到該消息代表的文件；

（7）調用加密程序對文件進行加密；

（8）加密程序完成后，將該文件節(jié)點從待加密文件鏈表中移除，并給該文件上鎖。

目錄A中的文件既存有明文文件，又存有密文文件。在寫加密操作中，一些待加密的文件都通過待加密文件鏈表維護。

4 測試結果

文件加密系統(tǒng)初始化運行，指定目錄A的絕對路徑。首先讀取路徑下的所有文件及子目錄。然后對整個目錄A的文件加密。最后，強行中止文件加密系統(tǒng)運行。如圖6所示，打開該目錄下的文件，顯示的是用戶無法閱讀的亂碼，如文本（txt），圖片（jpg）。

關閉上述所打開的文件，再重新啟動文件加密系統(tǒng)。因為已經運行過一次，所以需要讀取日志文件[9]，但發(fā)現所有文件都已被加密。

再打開上述文件，此時后臺維護子進程啟動，調用解密子進程完成文件解密過程，釋放文件鎖。如圖7所示，用戶讀取的文本（txt）為明文，圖片（jpg）無格式錯誤，能夠進行正常預覽。

5 結 語

本文主要采用文件鎖和消息Hook機制進行系統(tǒng)設計，因此需要多個子進程之間的協(xié)調工作?；趹脤拥脑O計，降低了整個系統(tǒng)的實現復雜度。同時，兼容了各種文件系統(tǒng)格式，通過對監(jiān)控目錄的備份保證了數據的可恢復性。解密之后的文件可以對文件內容進行Hash校驗[10]，從而確定解密之后的文件是否與原始文件的內容相同。

參考文獻

[1]刑常亮，卿斯?jié)h，李麗萍.一個基于Linux的加密文件系統(tǒng)的設計與實現[J].計算機工程與應用，2005，41（17）：101-104.

[2] Randal E Bryant ， David OHallaron.Computer Systems： A Programmers Perspective[M].北京：機械工業(yè)出版社，2011.

[3]劉剛，趙劍川. Linux系統(tǒng)移植[M].北京：清華大學出版社，2011.

[4]邱鐵，周玉，鄧瑩瑩.Linux內核API完全參考手冊[M].北京：機械工業(yè)出版社，2011.

[5] Wolfgang Mauerer. Professional Linux Kernel Architecture[M]. 北京：人民郵電出版社，2008.

[6] Neil Matthew，Richard Stones. Beginning Linux Programming [M].北京：人民郵電出版社，2000.

[7]龐麗萍，鄭然.操作系統(tǒng)原理與Linux系統(tǒng)實驗[M].北京：機械工業(yè)出版社，2011.

[8]解雙建，原亮，郝琳，等.一種有效的RSA算法改進方案[J].計算機應用，2010，30（9）：2293-2397.

[9]劉斌.基于Linux的文件實時備份系統(tǒng)設計與實現[D].保定：華北電力大學，2014.

[10]徐術坤.Hash算法的研究及應用[D].武漢：湖北工業(yè)大學，2006.endprint