一、概述
加密是最常見的資料安全保護技術，在資料生命周期各階段均有應用。從應用場景和技術實踐上，按加密對象、使用者是否感覺、加密算法等次元，有多種分類及應對方案，并在主流作業系統如Windows、Linux、Android中有廣泛應用。
本文是Linux核心安全技術系列第二篇，主要介紹磁盤加密技術及主流執行個體。首先介紹磁盤加密技術背景，包括應用場景、威吓模型、技術線路分類等；其次介紹磁盤加密的兩種執行個體，即全盤加密FDE和檔案系統加密FBE，重點介紹Linux系統和核心主流FBE執行個體；最後以eCryptfs為例，詳細分析其原理和應用。
Linux核心安全技術系列第一篇：Linux核心安全技術——開源演進回顧
1.1、說明
資料在其生命周期各階段的資訊安全風險有很多，如假冒、盜改、洩漏、越權通路、DoS拒絕通路等，一些成熟的方法通常能夠解決消除多種風險。本文主要介紹磁盤加密技術，主要注意的是資料洩露、機密性維數，其他維數風險和保護不過多涉及。
1.2、簡要術語和術語
本文使用的縮略語和技術語說明如下：
二、技術背景介紹
2.1、威脅模型
資料生命周期管理（Data Lifecycle Management）通常将資料計劃分為生産、存儲、使用、分享、銷售、歸檔幾個階段。并從資訊安全維護度，則一般将資料規劃分為三種狀态，即：Data in使用、移動/傳輸中的資料、靜态資料。
Data in Motion/Transit，即資料傳輸場景，是大家最熟悉、技術發展最成熟的安全場景。例如基于SSL/TLS協定的Https應用，基于SSH協定的SCP/SFTP應用等。這些技術對資料的安全保護不隻是包加密傳，也包含雙向身份證明、完整性保護等。
Data in Use，即資料使用場景。此時資料存儲在系統DRAM、Cache、CPU Register中，一般明文存在。但在一些高安全場景下，為防止側面資訊攻擊（如Cold開機攻擊擷取DRAM中鍵資訊），業界也提出了Full Memory Encryption全記憶體加密技術。如Intel的TME（Total Memory Encryption）、AMD的SME（Secure Memory Encryption）等。FME使能時系統DRAM資料全部為加密存儲，C PU通過特定硬體加解密引誘分離在讀資料時做解密加密操作，加解密解密一般每次開機時一次生成。
Data at Rest，即資料（保持持久化）存儲場景。此時資料屬于非活動狀态未使用，存儲在磁盤等非易失性。安全風險主要有非授權通路、裝置丢失導緻資料洩漏等。常見保護方式包括實體/網絡層面的隔離和通路控制、以及資料（落盤）加密。對于加密存儲的磁盤資料，即使裝置（如PC/手機）失敗，攻擊者拆出硬碟或Flash工具，也隻能讀取到器具中的密文，保證密鑰資料機密性。
2.2、技術路線
加密是防止資料洩漏、保證機密性的有效手段。按照不同維數，加密技術/方案可以有多種分類，簡單彙總如下：
需要說明的是，幾種方案互不相幹，一種方案通常符合/多種特征/技術。例如本文要介紹的磁盤加密技術磁盤加密，其加密對象一般是整個磁盤或檔案系統，但來自資料狀态次元看屬于資料加密技術，從使用者次元看屬于透明加密技術，從加密算法次元看采用加密技術。
下面簡單介紹分類幾個涉及的技術概念/術語，詳情可查閱文末參考連結，及後續章節中的詳細分析。
- 靜态資料加密
資料在靜态狀态下保持加密的技術，參考https://wiki.archlinux.org/title/Data-at-rest_encryption說明，加密對象一般為磁盤（塊裝置）、檔案系統目錄，加解密過程采用透明加密技術。
- 透明加密
透明加密，也稱為實時加密或即時加密。特點是資料在使用過程中自動完成加解密，消耗使用者幹預。
三、磁盤加密技術
如上節所述，磁盤加密磁盤加密，目标是保護靜态下的資料的機密性，加密對象是整個磁盤/分區、或者檔案系統，采用實時加解密技術。更多介紹可參考https://en .wikipedia.org/wiki/Disk_encryption 。
磁盤加密技術從加密對象、軟硬體實作、檔案系統特征等次元，也可以有多種分類。 首先，根據加密對整個市場的影響磁盤，還是檔案系統，可分為全磁盤加密和檔案系統級加密（也稱為基于檔案的加密）兩大類。
3.1、FDE
全盤加密全盤加密在實作上有硬體、軟體兩種方案。兩者核心原理類似，差別是加解密核心功能所在主體是軟體還是硬體，其它軟體解決方案不能真正加密整個硬碟（啟動分區一般不加密） ），而硬體方案基于硬體的全盤加密則具備整個硬碟加密能力。硬體FDE方案主要産品是自加密硬碟自加密硬碟，一般由記憶體組成零部件廠商、安全廠商提供。關于硬體 FDE 方案和 SED 産品技術，可參見文末基于硬體的全磁盤加密和 SED 相關連結。
硬體和軟體FDE方案核心原理及流程類似，統一抽像說明如下：
在初始化或FDE時，會随機建立一個磁盤資料加密DEK（磁盤加密密鑰，使用者無權限），同時要求使用者輸入一個AK（身份驗證密鑰）用于加密保護DEK。在使用時，需使用者先輸入AK驗證并破解DEK，其後作業系統才能使用DEK通路加密碼盤上的資料。下圖是一個軟體FDE的描述。
由于需執行特定程式展示UI提供使用者輸入AK并驗證，故這部分啟動代碼不能加密。引出了相應的Pre-Boot Authentication及PBA環境的概念。
在PBA實作上，硬體FDE方案（SED産品）一般出廠時内嵌Pre-Boot環境（小型作業系統或bootloader），上電後先運作Pre-Boot程式并驗證AK，再進行正常的加載引導等。
軟體FDE方案采用不加密啟動分區的方式，一般在初始ramdisk內建PBA功能并驗證完成。
軟體FDE方案發展曆史之久，主導OS環境成熟方案，例如Windows下的BitLocker、Apple OS/X下的FileVault、以及Linux/UNIX生态下的dm-crypt/LUKS。另外也有不依的賴作業系統的第三方FDE方案，如TrueCrypt、VeraCrypt等。更多軟體FDE方案可以參考連結https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software及下圖。
對Linux下dm-crypt/LUKS方案感興趣的同學可以在Ubuntu虛拟機上測試研究。下面是幾個關鍵場景截圖：Ubuntu虛拟機安裝時使能磁盤加密配置、啟動階段PBA驗證、系統主分區sda5加密後的磁盤類型（可看到boot分區sda1未加密）。
3.2、FBE
File-Based Encryption，又稱檔案系統級加密，檔案系統加密。相比于FBE，第二個名字更能展現基于檔案系統的技術特點的方案。而基于檔案系統的特點，涉及決定了隻能由軟體實作，其他方面決定了各個方案的差異也主要圍繞在檔案系統中。
常見FBE方案，一般分為Stackable cryptographic filesystem 和Native/General filesystem with encryption兩種。
第一個，新增一個加解密檔案系統，包含在現有存儲軟體棧的相關層。例如Linux核心自v2.6.19開始支援，已經很成熟穩定的eCryptfs方案，就是在VFS -> Native FS層其中加入新加解密檔案系統支援。類似還有基于使用者狀态檔案系統FUSE的各種方案。
第四，在現有檔案系統中引入加解密功能。例如Linux核心自v4.1支援的Ext4檔案系統加密，自v4.2支援的F2FS檔案系統加密，自v4.10以後支援的UBIFS檔案系統加密。需要說明的是，核心中Ext4、F2FS、ubifs共享加解密功能子產品，即核心fscrypt特性。另外，Android系統引入的FBE方案，底層核心實作同樣基于F2FS+fscrypt。
兩種類型及更多行業FBE現實，可參考連結https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems 及下圖：
和FDE方案相比，FBE有幾個表現着的特點：
1、支援單一的目錄或檔案加密，方友善使用配置。隻加密目标對象，不加密整磁盤，降低了系統加解密載營銷。
2、支援不同目錄/檔案使用不同加密匙。
3、加密目錄和非加密目錄并存（甚至一個加密目錄中加密和非加密檔案也可以并存）。加密目錄檔案的備份傳輸靈活友善。
更多FDE和FBE的詳細對比，以及Linux中FBE具體實作，請參看後續章節。
3.2、FDE與FBE
前面分析已經知道，軟體FDE和FBE都是基于檔案系統，差異主要是在檔案系統實際出現差異，整理比較如下：
【說明】軟體FDE/FBE主要是指其加解密功能主體在軟體（檔案系統）實作，并不意味着不使用硬體，而是為了提高性能，另外利使用類似Crypto Engine等硬體引擎來加速。
從整個系統軟體硬體結構分析，可将硬體FDE、軟體FDE、以FBE現實和系統軟體硬體結構的相關位置描述如下圖：
上層使用者，磁盤加密方案，越往上層使用者實作使用配置越靈活，但性能較差；越往下層實作越不靈活，但對越透明且性能很好。結合前面的文字描述，将FDE和FBE兩種方案的差異對比整理如下：
3.3、Linux系統FBE
從Linux系統軟體架構看，典型的FDE和FBE執行個體分發如下圖，包括基于dm-crypt的軟體FDE方案、基于通用檔案系統的fscrypt FBE方案、基于VFS的eCryptfs FBE方案，以及衆多基于FUSE的FBE方案。
前面章節已經簡單介紹了基于dm-crypt的FDE方案在ubuntu虛拟機上的試驗情況，這裡先簡單介紹Linux系統和核心的幾種軟體件FBE執行個體和特殊點，後續章節會以eCryptfs為例子做詳細分析。
基于保險絲的
FUSE即Filesystem in Userspace，使用者狀态檔案系統。FUSE設計初衷就是為友善使用者不修改編譯内部的情況下，在使用者空間實際制定檔案系統。FUSE架構原理和實際如下圖，核心狀态FUSE和使用者狀态libfuse為App –> VFS -> 使用者檔案系統連結服務，使用者定義實作主要在使用者級檔案系統部分。
由于自然的生命力，基于FUSE實踐發現FBE的方法有很多，例如gocryptfs、EncFS、CryFS、securefs等。但是，FUSE引入的多次系統調用和選擇性開發，也導緻基于FUSE的FBE方案通常性能不佳好gocryptfs項目項目有個個個個個f f f各各各連結連結連結連結連結https://nuetzlich.net/gocryptfs/comparison/）
首先是各種stackable FBE方法介紹和整體特點，從數量上看，FUSE FBE方法占絕大部分，非FUSE方法隻有eCryptfs。
其次，相對于eCryptfs，FUSE方案在性能上整體處于優勢。盡管gocryptfs在順序讀上性能不會出錯，但在其他測試如解壓、MD5計算、目錄遞歸通路/删除等測試項上看，功勢也比較明示。這和我們在3.2章節比FDE和FBE、以及分析磁盤加密在軟體棧不同層實際現在的效果差異是一樣的。
更多關于FUSE FBE各方案的特點，如檔案内容加密、檔案名加密等，可參考上述各對比連結或方案首頁，在此不詳細介紹。
eCryptfs
eCryptfs衍生于Cryptfs項目，早期方案和設計思想源自2005和2007的兩篇論文，即《eCryptfs: an enterprise-class cryptographic filesystem for Linux》和《eCryptfs: a Stacked Cryptographic Filesystem》。目分成核心部分和使用者狀态部分，内部狀态代碼于v2.6.19版本結合進入社群主線，使用者狀态代碼在軟體包ecryptfs-utils中維護。
eCryptfs 和上面介紹的 FUSE 方案一樣，也屬于 stackable FBE 類型，故不依賴于 OS 底層檔案系統類型，可以在各種檔案系統之上檢視，靈活很好。也支援對不同檔案、目錄加密，以及檔案名加密。
目前eCryptfs項目社群開源活躍度不高，早期使用者/産品不斷遷移，但其方案和設計原理仍然值得深入學習分析。詳細詳細測試驗證和原理分析請見第4章。
加密檔案
fscrypt 是在核心檔案系統上實作的一個原生 FBE 方案。fscrypt 特性還包括核心态和使用者态兩個部分，核心态部分是在 fs/crypto 目錄的實作公共使用加解密子產品，支援ext4、F2FS、UBIFS檔案系統集合使用。使用使用者狀态工具fscrypt則現實各種指令行工具方使用。
fscrypt作為FBE方案，支援不同目錄/檔案采用不同密鑰，對于中繼資料，fscrypt支援檔案名檔案名加密，其他中繼資料如時間戳、大小、屬性等不加密。大的應用即Android采用的FBE方法，結合F2FS檔案系統，對手機上的資料進行靜态資料加密保護。本文受限于篇幅，不做詳細分析。
四、eCryptfs詳解
本章節我們先用簡單的例子驗證eCryptfs加密效果特點，使大家對方案有一個整體的認知，同時也提供一個C版本本示例作參考。其次測試對結果進行初步分析，接着詳細分析eCryptfs方案架構原理和核心機制，最後對關鍵業務流程代碼進行簡單梳理。
測試使用環境Ubuntu 20.04虛拟機，因Ubuntu系統預設打開eCryptfs核心配置（CONFIG_ECRYPT_FS=y），隻需apt安裝使用者态工用ecryptfs-utils即可。
4.1、測試用例
下圖是一個腳本基礎測試用例。先建立測試目錄和檔案hello，之後使用mount -t ecryptfs方式對測試目錄進行加密，以免免指令行交際，将所有加密參數（passwd、cipher、key size等）通過指令行-o傳遞。加密後在測試目錄建立新檔案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_en able_filename_crypto=y，測試效果如下圖：
從第2個修改後的用例可以觀察到的現像/特性有：
4、ecryptfs支援檔案名加密。由于檔案名加密鎖FNEK未在參數中指定，mount helper會提示/預設使用檔案内含密鎖（即圖中） fnek_sig和fs_sig一緻，需要說明的是加密密匙并非參數字中的passwd，後續結構和密碼管理章節會說）。
5、雖然ecryptfs_passthrough特性仍然打開，即允許加密和非加密檔案共存，但與上一個用例效果不同。啟動檔案名加密并挂載後，未加密檔案hello無法在測試中顯示，umount後又可正常通路。兩個用例中passthrough特性在不同參數字下表現出不同，是以實際應用中，強烈不建議加密和非加密檔案在一個目錄混存。
另外補充一個現像/特性：
6、umount後，即加密的測試目錄是可以直接傳輸/選擇到其他主機/網絡進行存儲備份的。其他使用者使用時，隻需要使用相關同參數重新山即可正确通路。
關于用例中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目錄重複挂載且每次使用不同密鑰的效果。從下圖例子看，對應passwd挂載後生成的檔案，隻能在該挂載上下文中正确通路。這這個例子簡單說明，在參數情況變化下，例如檔案名加密，情況可能更複雜和不确定，是以也不建議使用。
二是檔案加密後大小變化問題，這個原因提出了eCryptfs的方案本身設計。下圖是eCryptfs明文和密文的映射關系及論文中的說明，分别出自2006年設計文檔《eCryptfs v0.1設計文檔》和2007年論文《eCryptfs: a Stacked Cryptographic Filesystem》。初步可見加密格式檔案會多增加一個标題資訊（組建一個頁面）。對于檔案内容按頁分塊加密。為了綜合性能力思考，故使檔案大小做到頁面對齊，最小12KB。
從方案設計和檔案格式看，加密對于小檔案來說丢失有點大，檔案越大影響越小。下圖分别用4M、40M、400M檔案測試對比結果，知道源檔案大小，加密後的檔案大小增加8KB。
4.3、整體架構
eCryptfs整體架構如下圖，主要是核心子產品eCryptfs以及使用者态程序ecryptfsd。ecryptfsd程序隻在使用key類型為openssl模式時需要，使用passphrase模型（如上描述測試用例）時不需要。ecryptfs-utils可作為使用者狀态輔助工具或C接口程式設計參考。
應用程式發起系統調用時先經過VFS，判斷目錄類型為eCryptfs時調用eCryptfs子產品的注冊函數。之後eCryptfs根根據mount session中儲存的密鑰簽名參數從keyring中找到對應用密匙（FEKEK），再調用crypto子產品API完成檔案加解密。
eCryptfs核心加解密機制如下圖，主要結論如下：
1、FEK（檔案加密密鑰）唯一，即每個檔案的加密密鑰均不同，是随檔案建立時生成的一個随機數。
2、每個檔案的FEK經過FEKEK（File Encryption Key Encryption Key）加密保，加密後FEK稱為EFEK（Encrypted File Encryption Key），并儲存在eCryptfs加密檔案的header資訊中（如前所述） 0區）。
3、passphrase模式下，FEKEK是基于使用者passphrase_passwd派生而來，派生方式是哈希計算（參考代碼分析章節）。
4、檔案内容按照頁面大小（Data Extent）進行塊加密。
核心過程可簡單描述為：
1、新檔案加密時，生成随機數FEK，對檔案内容進行分塊加密并存儲。根據使用者上傳的key_sig參數從keyring找到對應的FEKEK ，用FEKEK加密FEK，生成EFEK并儲存在檔案header中。
2、解密時，同樣根絕key_sig找到FEKEK，用FEKEK解密EFEK後得到FEK，再用FEK解密檔案内容。
4.4、按鍵管理
從上節中我們了解到eCryptfs核心機制作中主要有兩個KEY，即FEKEK和FEK，前者和使用者輸入passphrase_passwd有關，後者是每個檔案唯一的随機數。下面結合ecryptfs-utils源碼，分别介紹這兩個關鍵的生成過程。
1、用使用者passphrase_passwd 到FEKEK的轉換
從C測試用例中看，opt參數隻有key_sig資訊，并不指定FEKEK。而mount操作前提示已添加對應key（FEKEK）到核心keyring。腳本指令實際上是挂載助手協助（隐式）完成了添加密鑰環的操作。
核心函數即C示例中調用的ecryptfs_add_passphrase_key_to_key_ring，該函數的調用關系如下圖：
首先ecryptfs_generate_passphrase_auth_tok會根據使用者輸入的passphrases資訊、salt資訊（參數指定，ecryptfs-utils有一個預設值ECRYPTFS_DEFAULT_SALT如下圖），在generate_pass phrase_sig函數中進行哈希計算，将結果記錄在變量fekek中，然後對fekek再進行一次hash計算，結果記錄為passphrase_sig/auth_token_sig，并傳回給使用者後續使用（key_sig）。
generate_payload則為每次會話建立一個auth_tok結構體，記錄更多加解密相關資訊。
最後調用ecryptfs_add_auth_tok_to_keyring中，将對應的FEKEK、key_sig、salt等資訊都添加到keyring中。至此就完成了從passphrase_passwd到FEKEK的轉換和核心keyring添加。
2、FEK的生成過程
FEK 作為檔案内容加密密鑰，是每個檔案唯一的随機數。生成時機是在 create 系統調用階段，具體是在核心函數 ecryptfs_new_file_context 和 ecryptfs_generate_ new_key中完成，代碼見下。
4.5、代碼分析
本節将eCryptfs方案核心流程的代碼調用關系進行了簡單整理并羅列，供讀者參考和對照閱讀，不做詳細劃分析。
1、挂載過程關鍵函數調用。
從mount_crypt_stat key結構體，以及tokens結構體中可以看出，mount opt隻接受key簽名資訊。
2、建立過程關鍵函數調用。
create過程中建立新檔案，此時ecryptfs_crypt_stat結構體中儲存了檔案中每個的加密參數資訊。
3、open過程關鍵函數調用。
4、讀寫過程關鍵函數調用。
五、總結
首先介紹了磁盤加密技術背景，包括威脅模型、技術路線和特點，以及根據加密對象差異，分别介紹推出了FDE和FBE兩種磁盤加密方案，包括軟硬體實作、檔案系統實作差異等，并做出對比分析。最後重點介紹了Linux系統中典型的FBE方案及特點，并以eCryptfs為例進行了詳細分析。
希望能幫助閱讀者對磁盤加密技術概念、FDE和FBE差別、行業FBE方案特點、以及FBE實用關鍵技術能一步了解。限于篇幅，很多技術細節和方案無法再深入展開，如fscrypt。希望在後續文章中能結合Android FBE對fscrypt做進一步分享。
參考資料：
使用中的資料 https://en.wikipedia.org/wiki/Data_in_use
傳輸中的資料 https://en.wikipedia.org/wiki/Data_in_transit
靜态資料 https://en.wikipedia.org/wiki/Data_at_rest
靜态資料加密 https://wiki.archlinux.org/title/Data-at-rest_encryption
磁盤加密 https://en.wikipedia.org/wiki/Disk_encryption
全磁盤加密 https://en.wikipedia.org/wiki/Disk_encryption#Full_disk_encryption
預啟動身份驗證 https://en.wikipedia.org/wiki/Pre-boot_authentication
什麼是全盤加密 https://specopssoft.com/blog/what-is-full-disk-encryption/
基于硬體的全盤加密 https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
自加密驅動器 https://wiki.archlinux.org/title/Self-encrypting_drives
磁盤加密軟體 https://en.wikipedia.org/wiki/Disk_encryption_software
磁盤加密軟體比較 https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
檔案系統級加密 https://en.wikipedia.org/wiki/Filesystem-level_encryption
加密檔案系統清單 https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems
使用者空間的檔案系統，FUSE https://en.wikipedia.org/wiki/Filesystem_in_Userspace
基于 FUSE 的 FBE 對比 https://nuetzlich.net/gocryptfs/comparison/
fscrypt 核心文檔 https://docs.kernel.org/filesystems/fscrypt.html
eCryptfs 文檔 https://www.ecryptfs.org/documentation
eCryptfs Linux 手冊頁 https://linux.die.net/man/7/ecryptfs
2005.07 eCryptfs：Linux 的企業級加密檔案系統 https://web.archive.org/web/20080916022422/http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
2006.03 eCryptfs v0.1 設計文檔 http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs_design_doc_v0_1.pdf
2007.05 eCryptfs：堆疊式加密檔案系統 http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs-article.pdf
2016.01動态加密技術綜述，梁金千 http://blog.nsfocus.net/dynamic-encryption-technology-review/
2017.09 檔案系統和塊層加密：理論、實踐和改進 https://www.snia.org/educational-library/file-system-and-block-layer-encryption-theory-practice-and-improvement- 2017年