ecryptfs 文件系統的資訊洩露
我想知道ecryptfs 文件系統可能會洩露哪些資訊。如果您在使用桌面安裝程序時選中“加密主目錄”框，這就是 Ubuntu 使用的，因此可能被廣泛使用。它的主要特點：
- 每個文件都單獨加密並儲存在底層文件系統中
- 每個文件的大小填充為 4096 字節的倍數，最小為 12288（目錄和軟連結除外）
- 文件名和目錄名被加密
- 目錄結構保持不變
（注意我還沒有找到關於上述內容的規範，這是通過觀察我自己的文件系統得出的——
/home/.ecryptfs/USERNAME/.Private如果你想檢查自己的文件系統，它就儲存在其中）。因此，假設您無法破解加密密鑰，那麼您將無法檢查文件的內容。然而，仍有一些資訊需要檢查，正如流量分析可以從加密的通信數據中推斷出有用的資訊一樣，我想知道有多少人可以從目錄結構和近似文件大小中計算出多少。
當然，您可以從文件大小計算出哪些目錄和文件包含音樂、影片和照片。您甚至可以弄清楚存在哪些音樂和影片。由於它們的配置/記憶體目錄模式 - firefox vs chrome 等，您可能會計算出一些正在使用的應用程序。
還有別的事嗎？是否有可以推斷出的標準分析？有什麼其他的想法嗎？
（我必須承認，當我開始寫這個問題時，我假設文件大小沒有填充 - 我確信有）。
（**披露：**我是您所詢問的功能的作者（好問題！）。）
Ubuntu 的加密主目錄功能使用 eCryptfs 作為文件系統加密技術。eCryptfs 是一個直接內置在 Linux 核心中的分層文件系統。它將一個目錄安裝在另一個目錄之上。頂層目錄實際上只是一個“虛擬”掛載點。應用程序（和人類）可以在該目錄中操作並讀取和寫入數據，而無需知道或被下面發生的加密所困擾。較低的目錄是實際加密文件儲存在磁碟上的位置。
這種方法有幾個優點。與 dmcrypt 或全盤加密不同，您不必預先分配固定數量的專用於加密的空間。您還可以將更多加密的內容限制為您真正獨特的資訊（提高整體系統性能和功耗）。使用者之間有一些權限分離，每個使用者都有自己唯一的掛載點和加密密鑰。並且這個特殊的功能與 PAM 掛鉤，因此您的目錄會在您登錄時自動掛載，並在您註銷時解除安裝。此外，每個文件都使用一個唯一的、隨機生成的名為“fek”的密鑰（儲存在文件的標題中，並用 MOUNT 密碼片語包裝）進行加密。
另一方面，您應該注意一些事項 - 現在是您問題的重點！
- 上下文件結構幾乎相同，可能會推導出一些文件名（基於預設的Ubuntu主目錄骨架）
- 文件權限、文件所有權和文件時間戳未加密（因此具有奇怪權限的文件，如 0123 可能會脫穎而出）
- 加密文件名將上層明文文件名限制為大約 160 個字元（因為文件名加密需要一些填充）
- 如果您使用的是 Ubuntu Encrypted Home，則交換絕對應該被加密，因為記憶體中的任何內容都可以隨時交換到磁碟（當然，如果您使系統休眠）
- 當文件系統被主動掛載時，只有 Unix 執行時自由訪問控制可以保護您免受系統上其他使用者的影響（注意主目錄是權限 0700）
- 當文件系統被主動掛載時，eCryptfs 不會保護您免受 root 使用者的侵害
- 除非您將您
~/.ecryptfs/wrapped-passphrase的本地系統移到可移動媒體（如 U 盤或快閃記憶體盤）上，否則您的登錄密碼是加密的弱點現在，儘管如此，我仍然相信 Ubuntu 的 Encrypted Home 在安全性和可用性之間取得了出色的平衡。設置起來很簡單，並且使用良好的登錄密碼，它可以為您的所有數據提供極其強大的保護，
$HOME防止離線攻擊。換句話說，如果有人偷了你的筆記型電腦，啟動了一張 Live CD 並開始探勘你的$HOME/.Private加密數據，他們可能會收集一些關於你的文件名、目錄結構和時間戳的資訊。但是要獲取任何特定文件的內容，他們將需要以下之一：
- 您的登錄密碼和包裝密碼文件
- 明文、128 位長、隨機 MOUNT 密碼（儲存在包裝密碼文件中）
- 有足夠的時間在 2 中強制使用 128 位密鑰。
- AES256 中的缺陷
eCryptfs 資訊洩露可以通過各種渠道發生。最嚴重和最常見的洩漏點是交換。如前所述，Ubuntu 現在對其進行了加密，但有人告訴我，啟用該功能會破壞休眠。其他發行版不一定會在使用 eCryptfs 時確保對交換進行加密。
eCryptfs 沒有特別努力防止記憶體中的密鑰擴散。您可以通過在 VM 中執行 eCryptfs、保存狀態並在記憶體映像中搜尋您的密鑰材料來了解該問題的嚴重程度。將密鑰儲存在 USB 驅動器上對任何有權訪問程序/核心記憶體的使用者（例如 root）沒有多大幫助。如果沒有額外的核心加固和/或 MAC，eCryptfs 對惡意 root 使用者完全無效。我也不會重複幾乎所有通用電腦的加密系統都容易受到的冷啟動或 DMA 攻擊。
正如其他人所提到的，應用程序可以在任何地方寫入敏感數據，包括 /tmp 或 /var 下的位置。試圖在每個應用程序的基礎上確定這一點是棘手的。
您當然可以使用分析和機器學習技術來推斷有關正在寫入的數據類型和寫入數據的應用程序的資訊。例如，我已經成功地應用了一個 kNN 模型，其特徵只是 eCryptfs 在一段時間內讀寫的次數。如果/當 eCryptfs 在 NFS/SMB 上工作時，那將是一個洩漏。其他更容易觀察到的特徵，例如近似文件大小、近似文件名長度和目錄結構，可以揭示您儲存的數據類型。例如，我可以輕鬆地確定您的盒子上是否有 Tor 或 TrueCrypt 的原始碼，因為它的文件/目錄結構的數量非常低。
Ninefingers 提到的展示文稿中的 CBC 攻擊不適用於 eCryptfs 或 BitLocker，它們都具有 4096 字節的 CBC 範圍和不可預測的 IV。我查看了 XTS 規範，我沒有看到它比帶有 AES-CBC 和 Elephant 擴散器的 BitLocker 更安全。
儘管 eCryptfs 有弱點，但總比沒有好，而且 eCryptfs 部署的便利性使得人們更有可能加密而不是不加密。也就是說，如果您想要獲得最佳保護，以保護您盒子中物理驅動器上的靜態數據的機密性，我建議您使用 Win7+BitLocker+TPM 部署 FVE，而不是使用 Linux 對每個文件進行加密+eCryptfs。
（編輯：有人告訴我我應該在這樣的文章上聲明我的信譽。我設計/實現了 eCryptfs 的加密，並且我在 Microsoft BitLocker 團隊擔任高級開發人員幾年。）