eCryptfs詳解

本章節(jié)我們先用簡單用例驗證eCryptfs加密效果特點，使大家對方案有個整體感性認識，同時也會提供一個C版本用例作參考。其次對測試結果進行初步分析，接著詳細分析eCryptfs方案架構原理和核心機制，最后對關鍵業(yè)務流程代碼進行簡單梳理。

測試環(huán)境使用Ubuntu20.04虛擬機，因Ubuntu系統(tǒng)默認打開eCryptfs內(nèi)核配置（CONFIG_ECRYPT_FS=y），只需apt安裝用戶態(tài)工具ecryptfs-utils即可。

4.1、測試用例

下圖是一個腳本基礎測試用例。先創(chuàng)建test目錄和文件hello，之后使用 mount -t ecryptfs方式對test目錄進行加密，為避免命令行交互，將所有加密參數(shù)（passwd、cipher、key size等）通過命令行-o傳遞。加密后在test目錄創(chuàng)建新文件hello_encrypted。最后umount取消目錄加密。

從第一個測試用例可以觀察到的現(xiàn)象/特性有：

1、執(zhí)行mount，寫入hello_encrypted文件內(nèi)容后可以正確訪問，但umount后則為密文。說明eCryptfs作為堆疊加密文件系統(tǒng)，是通過mount/unmount操作來開關使能的。功能打開時，用戶讀寫操作是感知不到數(shù)據(jù)加解密過程的，即透明加密。

2、hello文件內(nèi)容在mount前寫入，在mount前后都能正確訪問（用例只測了讀操作，實際寫也可以）。說明eCryptfs支持非加密文件和加密文件在一個目錄內(nèi)混合存儲，并能正確訪問（實際操作強烈不建議，見下個用例）。

3、對于加密文件hello_encrypted，明文狀態(tài)下長度為16 Bytes，加密狀態(tài)下為12KB，變化比較明顯。

如果對上述測試用例稍加改動，調(diào)整mount -t ecryptfs參數(shù)，如改變passwd，取消no_sig_cache=y配置，打開文件名加密參數(shù)即ecryptfs_enable_filename_crypto=y，測試效果如下圖：

從第二個改動后的用例可以觀察到的現(xiàn)象/特性有 ：

4、ecryptfs支持文件名加密。因為文件名加密密鑰FNEK未在參數(shù)中指定，mount helper會提示/默認使用文件內(nèi)容加密密鑰（即圖中fnek_sig和fs_sig相同，需說明的是加密密鑰并非參數(shù)中的passwd，后續(xù)架構和密鑰管理章節(jié)會說明）。

5、雖然ecryptfs_passthrough特性仍打開，即允許加密和非加密文件共存，但與上一個用例效果不同。啟動文件名加密并mount后，未加密文件hello無法在test中顯示，umount后又可正常訪問。兩個用例中passthrough特性在不同參數(shù)下表現(xiàn)不同，因此實際應用中，強烈不建議加密和非加密文件在一個目錄混存。

另外補充一個現(xiàn)象/特性：

6、umount后，即加密的test目錄是可以直接傳輸/拷貝到其他主機/網(wǎng)絡進行存儲備份的。其他用戶使用時，只需用相同參數(shù)重新mount即可正確訪問。

關于用例中mount -t ecryptfs命令的相關參數(shù)匯總?cè)缦?，詳情可參考man ecryptfs手冊及ecryptfs-utils源碼。部分參數(shù)和意義會在架構分析和密鑰管理章節(jié)進一步說明。

需要說明的是，上述腳本用例的功能基本都可以用ecryptfs-utils提供接口API實現(xiàn)。下面是作者實現(xiàn)的一個C用例的部分代碼參考。因為C程序需引用ecryptfs.h頭文件并使用相關API函數(shù)，需要安裝libecryptfs-dev軟件包，并在編譯時指定-lecryptfs鏈接對應庫文件。

C用例中需要注意的是，mount操作前必須進行ecryptfs_add_passphrase_key_to_keyring，即將passphrase轉(zhuǎn)換成對應的key（實際為FEKEK，見后續(xù)分析），并注冊到內(nèi)核keyring，同時返回一個key_sig給用戶后續(xù)使用。

4.2、結果分析

從上節(jié)測試結果中，匯總相關測試項以及eCryptfs效果特性如下表，需要說明的有兩點：

一是對test目錄重復mount且每次使用不同密鑰的效果。從下圖用例看，對應passwd mount后生成的文件，只能在該mount context中正確訪問。這個用例僅為簡單說明，在參數(shù)變化情況下，例如文件名加密，情況可能更復雜和不確定，因此也不建議使用。

二是文件加密后大小變化問題，這個原因在于eCryptfs的方案本身設計。

文檔《eCryptfs v0.1 Design Document》和2007年論文《eCryptfs： a Stacked Cryptographic
Filesystem》。從中可看出加密文件格式會多增加一個header信息（預留一個page）。對于文件內(nèi)容則是按頁分塊加密。為了綜合性能考慮，故使文件大小做到page對齊，最小12KB。