eCryptfs詳解

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

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

4.1、測試用例

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

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

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

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

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

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

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

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

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

另外補充一個現象/特性：

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

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

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

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

4.2、結果分析

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

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

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

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