靜態數據加密

出自 Arch Linux 中文维基

本文討論靜態數據加密軟體,該軟體即時加密/解密寫入/讀取塊設備磁碟分區或目錄的數據。塊設備的示例是硬碟驅動器、快閃記憶體驅動器和 DVD。

靜態數據加密僅應被視為作業系統現有安全機制的附屬品——專注於保護物理訪問,同時依賴系統的其他部分提供網絡安全和基於用戶的訪問控制等功能。

對於全盤加密 (Full-disk encryption,FDE),參閱Dm-crypt/加密整個系統

為什麼要使用加密?[編輯 | 編輯原始碼]

靜態數據加密確保文件始終以加密的形式存儲在磁碟上。這些文件只有在系統運行並由受信任的用戶解鎖時才以可讀形式提供給作業系統和應用程式(使用中的數據傳輸中的數據)。未經授權的人直接查看磁碟內容,只會發現混亂的隨機數據,而不是實際的文件。

例如,這可以防止未經授權的數據查看,當電腦或硬碟:

  • 處於當你離開時不受信任的人可能獲得使用機會的場所
  • 丟失或被盜,如筆記本電腦、上網本或外部存儲設備
  • 在維修店裡
  • 淘汰後被丟棄

此外,靜態數據加密還可用於增加一些安全性,以防止未經授權的篡改作業系統的嘗試——例如,可以獲得物理訪問權限的攻擊者趁你不在的時候安裝鍵盤記錄程序(keyloggers)或特洛伊木馬(Trojan)。

警告: 靜態數據加密並不能保護你的數據免受所有威脅。

你仍然容易受到以下威脅:

  • 攻擊者可以在系統運行時以及你已經解鎖並掛載磁碟的加密部分後闖入你的系統(例如通過Internet)。
  • 如果可獲得對計算機的物理訪問權限的攻擊者有資源,那麼他們能夠在電腦運行時(即使你使用了屏幕鎖),或在電腦運行不久,執行冷啟動攻擊
  • 一個政府實體,它不僅擁有輕鬆實施上述攻擊的資源,而且還可能使用各種脅迫技術簡單地迫使你放棄密鑰/密碼。如果執法機構懷疑你可能隱藏了一些他們感興趣的東西,那麼執法機構這樣做可能是合法的。
  • 橡膠軟管密碼分析。另請參閱XKCD #538

需要一個非常強大的磁碟加密設置(例如,具有真實性檢查和無明文引導分區的完整系統加密)才能有機會抵禦能夠在你使用系統之前篡改你的系統的專業攻擊者。即便如此,它也無法阻止所有類型的篡改(例如硬體鍵盤記錄器)。最好的補救措施可能是基於硬體的全盤加密可信計算

警告: 靜態數據加密也不會保護你免受某人簡單地擦除你的磁碟的侵害。 建議定期備份以確保數據安全。

系統數據加密[編輯 | 編輯原始碼]

雖然僅加密用戶數據本身(通常位於家目錄中,或在數據 DVD 等可移動媒體上)是最簡單且侵入性最小的方法,但是它有一些明顯的缺點。 在現代計算機系統中,有許多後台進程可能會在硬碟驅動器的非加密區域中緩存和存儲有關用戶數據或部分數據本身的信息,例如:

  • 交換分區(swap)
  • /tmp(用戶應用程式創建的臨時文件)
    • (可能的補救措施:避免此類應用程式;在ramdisk內掛載/tmp
  • /var (日誌文件和資料庫等;例如,mlocate將所有文件名的索引存儲在/var/lib/mlocate/mlocate.db中)

解決辦法就是對系統和用戶數據都進行加密,阻止未經授權的對可能被系統緩存的隱私數據的物理訪問。不過,這樣也帶來了一個缺點——必須在啟動時對磁碟的加密部分進行解鎖。系統數據加密的另一個好處是,它給具有物理訪問權限的人安裝諸如 鍵盤記錄器或 rootkits 之類的惡意軟體帶來了麻煩。

可用方法[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因: Ext4ZFS,可能還有其他的文件系統,提供(原生(native))加密。 (在 Talk:靜態數據加密 中討論)

所有靜態數據加密方法都是這樣操作的:雖然磁碟實際存放的是加密數據,但只要加密容器(即磁碟中存放加密數據的邏輯部分)被「解鎖」並被掛載,那麼作業系統和應用程式就會把它 "看成 "相應的普通的可讀數據。

為此,用戶需要提供一些「機密信息」(通常採用密鑰文件和/或密碼短語的形式),從這些信息中可以派生出實際的加密密鑰(並在會話期間存儲在內核密鑰環中)。

如果你對這種操作完全不熟悉,還請閱讀下文#加密是怎麼運作的的部分。

可用的靜態數據加密方法可以按其操作層分為兩種類型:

堆棧式文件系統加密[編輯 | 編輯原始碼]

作為堆疊在已有文件系統之上的層而實現的堆棧式文件系統加密方案,使所有寫入啟用加密的文件夾的文件在底層文件系統將其寫入磁碟之前就被即時加密,並在文件系統從磁碟讀取它們時被解密。這樣,文件以加密的形式存儲在宿主文件系統中(意味著它們的內容,通常還有它們的 文件/文件夾名稱,都被長度大致相同的隨機數據所取代),但除此之外,它們仍然以正常的文件/符號連結/硬連結等形式存在於該文件系統中,如同沒有加密一樣。

它的實現方式是,為了解鎖宿主文件系統中存儲原始加密文件的文件夾("下層目錄"),它被掛載(使用一個特殊的堆疊的偽文件系統)到它本身或可選的不同位置("上層目錄"),然後相同的文件以可讀的形式出現——直到它再次被卸載,或系統被關閉。

此類別中可用的加密方案是eCryptfsEncFS

雲存儲優化[編輯 | 編輯原始碼]

如果你正在部署堆棧式文件系統加密,以實現與第三方控制的位置(如雲存儲服務)的零知識同步(zero-knowledge synchronization),你可能需要考慮替代 eCryptfs 和 EncFS 的方案,因為他們並不是為了通過 Internet 傳輸文件這一目的而優化的。有一些解決方案是為了這個目的而設計的:

請注意,一些雲存儲服務直接通過他們自己的客戶端應用程式提供零知識加密(zero-knowledge encryption)。

塊設備加密[編輯 | 編輯原始碼]

另者,塊設備加密(block device encryption)方法操作於文件系統層之下,確保寫入某個塊設備(即整個磁碟、分區或充當迴環設備的文件)的所有內容都是加密的。這意味著當塊設備處於脫機(offline)狀態時,它的整個內容看起來就像一大團隨機數據(a large blob of random data),無法確定它包含什麼樣的文件系統和數據。通過一種特殊方式將受保護的容器(在本例中為塊設備)掛載到任意位置,再次訪問數據。

Arch Linux 中提供了以下幾種「塊設備加密」方案:

loop-AES
loop-AES 是 cryptoloop 的繼任者,是一種安全、快速的系統加密解決方案。然而,loop-AES 被認為不如其他選擇易用(less user-friendly),因為它需要非標準內核支持(non-standard kernel support)。
dm-crypt
dm-crypt 是由 Linux 內核提供的標準設備映射器加密(standard device-mapper encryption)功能。喜歡全面掌握分區及密鑰管理的各個方面的人直接用它就行了。對 dm-crypt 的管理是通過 cryptsetup 用戶空間實用程序完成的。它可用於以下類型的塊設備加密:LUKS(默認)plain,並且具備有限的用於 loopAESTruecrypt 設備的功能。
  • 默認情況下使用的 LUKS 是一個額外的便利層,它將 dm-crypt 所需的所有設置信息存儲在磁碟本身上,並抽象分區和密鑰管理,以提高易用性和加密安全性。
  • plain 模式下的 dm-crypt,作為原始的內核功能,並沒有採用便利層。用它來應用(與 LUKS 類型)同樣的加密強度是比較困難的。這樣做時,會產生更長的密碼或密鑰文件(二者被統稱為 keys)。但是,它具有其他優點,描述於下文#塊設備加密與堆棧式文件系統加密的對比[損壞的連結:無效的章節]之中。
TrueCrypt/VeraCrypt
一種可移植(portable)格式,支持整個磁碟/分區或文件容器的加密,兼容所有主流作業系統。對 TrueCrypt 的開發於2014年5月被其開發者停止。其分支 VeraCrypt 於2016年被審計。

關於選定的操作層的實際含義,參閱下文#塊設備加密與堆棧式文件系統加密的對比[損壞的連結:無效的章節],以及對 eCryptfs的總體描述。參閱Category:Encryption,了解下表比較的方法的可用內容,以及未包括在表中的其他工具。

塊設備加密與堆棧式文件系統加密的對比[編輯 | 編輯原始碼]

塊設備加密 堆棧式文件系統加密
加密 整個塊設備 文件
加密數據的容器可能是…… 作為迴環設備的磁碟或磁碟分區/文件 現有文件系統中的目錄
與文件系統的關係 在文件系統層下運行:不關心加密塊設備的內容是文件系統、分區表、LVM 設置還是其他任何內容 向現有文件系統添加一個附加層,以在文件被寫入/讀取時自動加密/解密文件
加密文件元數據(文件數、目錄結構、文件大小、權限、最後修改時間等)
(使用 'discard' 可能會暴露文件的大小)
部分
(只有名稱被加密,所有其他元數據都是可見的)
可被用於自定義加密整個硬碟驅動器(包括分區表)
可被用於加密交換(swap)空間
可被用作加密數據容器而無需預分配固定大小的空間
(使用 'discard' 可能允許少有分配的容器,代價是暴露文件的大小)
可被用於保護沒有塊設備訪問的現有文件系統,例如NFS 或 Samba 共享、雲存儲等 1
允許對加密文件進行基於文件的脫機備份
  1. 額……這些文件系統中的單個文件可以用作容器(虛擬環回設備!)但實際上,人們就不會再使用文件系統(及其提供的功能)了

比較表[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因: 填寫空白處。為複選標記/交叉點添加來源。(salt)、密鑰槽替代(key-slot diffusion)以及 密鑰擦除(key scrubbing)分別是什麼? (在 Talk:靜態數據加密 中討論)

「dm-crypt +/- LUKS」 一欄表示 dm-crypt 在 LUKS("+")和 plain("-")加密模式下的功能。如果一個特定的功能需要使用LUKS,這將以「(用 LUKS)」表示。同樣,「(不用 LUKS)」表示使用 LUKS 對實現該功能起反作用,應該使用 plain 模式。

概要(Summary) Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
加密類型 塊設備 塊設備 塊設備 原生文件系統或塊設備 堆棧式文件系統 堆棧式文件系統 堆棧式文件系統 原生文件系統
說明(Note) 存在時間最長的;可能是最快的;適用於遺留系統(legacy systems) Linux 上塊設備加密的事實標準;非常靈活 TrueCrypt 的受維護分支,支持 TrueCrypt 和 VeraCrypt 卷(volume) 加密功能相對較新(2019 年);由 ZVOL 提供被加密的塊設備 比EncFS稍快;可在系統之間轉移的單個加密文件 最易用的一種;支持非 root 管理 有抱負的 EncFS 的繼任者 默認用於 Chrome OS 和 Android 加密
在 Arch Linux 中的可用性 需要手動編譯、定製內核 內核模塊:已隨默認內核一起提供;工具:device-mappercryptsetup veracrypt ZFS#安裝 內核模塊:已隨默認內核一起提供;工具:ecryptfs-utils encfs gocryptfs 內核模塊:已隨默認內核一起提供;工具:fscrypt
許可協議(License) GPL GPL Apache License 2.0,一些部分受 TrueCrypt License v3.0 約束 CDDL GPL GPL MIT GPL (內核)、Apache 2.0 (用戶空間工具)
加密實現於…… 內核空間 內核空間 內核空間 內核空間 內核空間 用戶空間(FUSE 用戶空間(FUSE 內核空間
加密元數據存於…… 用 LUKS:LUKS 標頭 (已解密的)設備之首/尾 (格式規範) DSL(數據集和快照層;報告(talk)/幻燈片(slides)) 每個加密文件的標頭 每個 EncFs 容器頂層的控制文件 每個文件系統根目錄下的 .fscrypt 目錄
封裝的加密密鑰存於…… 用 LUKS:LUKS 標頭 (已解密的)設備之首/尾 (格式規範) DSL(數據集和快照層;報告(talk)/幻燈片(slides)) 密鑰文件可被存儲在任何地方 密鑰文件可被存儲在任何地方

[1][2]

每個文件系統根目錄下的 .fscrypt 目錄
可用功能 Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
Non-root users can create/destroy containers for encrypted data 受限
提供圖形用戶界面(GUI)

可選的

支持登錄時自動掛載

利用 systemd 和 /etc/crypttab

支持在不活動的情況下自動卸載 ?
[3]
安全特性 Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
支持的密碼(cipher) AES AES、Anubis、CAST5/6、Twofish、Serpent、Camellia、Blowfish …… (內核 Crypto API 提供的每一種密碼(cipher)) AES、Twofish、Serpent、Camellia、Kuznyechik AES AES、Blowfish、Twofish... AES、Blowfish、Twofish,以及其餘所有在此系統上可用的密碼(cipher) AES AES、ChaCha12
完整性(校驗)(Integrity) 可選於 LUKS2 CCM、GCM 無(默認模式)
HMAC (paranoia 模式)
GCM
支持加鹽
(用 LUKS)
支持級聯多個密碼(Support for cascading multiple ciphers) 不在一個設備中,但塊設備可以級聯

AES-Twofish、AES-Twofish-Serpent、Serpent-AES、Serpent-Twofish-AES、Twofish-Serpent

支持密鑰槽替代(key-slot diffusion)
(用 LUKS)
保護密鑰不被擦除
(不用 LUKS)
支持為相同的加密數據設置多個(獨立可撤銷的)密鑰
(用 LUKS)
性能特點 Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
多線程支持
[4]
硬體加速加密(Hardware-accelerated encryption)支持
[5]
塊設備加密特有的 Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS
支持(手動)就地調整加密塊設備的大小
堆棧式文件系統加密特有的 ZFS eCryptfs EncFS gocryptfs fscrypt
支持的文件系統 ZFS ext3、ext4、xfs (附有警告,with caveats)、jfs、nfs …… ext3、ext4、xfs (附有警告,with caveats)、jfs、nfs、cifs ……

[6]

任何 ext4、F2FS、UBIFS
能加密文件名
zfs(8)
加密文件名
[7]
稀疏文件的優化處理(Optimized handling of sparse files)
兼容性 & 流行度 Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS eCryptfs EncFS gocryptfs fscrypt
支持的 Linux 內核版本 2.0 或更新 CBC-mode 自 2.6.4 以來,ESSIV 2.6.10,LRW 2.6.20,XTS 2.6.24 2.6.32 或更新(截至 0.8.3) 2.4 或更新 4.1 或更新
也可以從Windows 訪問加密數據
OpenZFS on Windows (倉庫)
否 (需要管理員權限) 是 (cppcryptfs 埠,cppcryptfs port)
也可以從 Mac OS X 訪問加密數據
OpenZFS on OS X (倉庫)

[8]
是 (測試版質量,beta quality)
也可以從 FreeBSD 訪問加密數據
ZFS on FreeBSD (內置,native; 倉庫)

[9]
被用於 Debian/Ubuntu安裝程序(系統加密)
Fedora 安裝程序
Android、Chrome OS

準備[編輯 | 編輯原始碼]

選擇設置[編輯 | 編輯原始碼]

根據你的目的(請閱讀上文#為什麼要使用加密?)及系統參數選取合適的加密設置。

此外,你需要回答下列問題:

你想抵禦什麼樣的「攻擊者」?
  • 在你的系統被關閉、被盜等情形下窺探你的磁碟的普通用戶
  • 可在你使用你的系統前後反覆獲得讀寫權限的專業密碼分析員
  • 任何介於這兩者之間的人
你想加密什麼?
  • 僅用戶數據
  • 用戶數據和系統數據
  • 僅機密數據,也就是你的數據的子集
交換分區(swap)、/tmp 等,應如何處理?
  • 禁用或掛載為 ramdisk
  • 被加密的交換分區
    • 將交換文件作為全盤加密的一部分
    • 單獨加密交換分區
應如何解鎖磁碟的加密部分?
  • 使用密碼
    • 同帳戶登錄密碼
    • 不同於帳戶登錄密碼
  • 使用密鑰文件(例如將其置於隨身攜帶的或保存在安全地方的U盤上)
  • 二者兼有
何時 解鎖磁碟的加密部分?
  • 引導前
  • 引導過程中
  • 登錄帳戶時
  • 按需手動解鎖(帳戶登錄後)
應如何滿足多用戶需求?
  • 不需要
  • 使用每個用戶都知道的共享密碼(或密鑰文件)
  • 用於磁碟的同一加密部分的,被獨立分發的、可撤銷的密碼(或密鑰文件)
  • 為不同的用戶分配磁碟的加密部分

接下來你可以做出所需的技術選擇(參閱上文#可用方法,以及下文#加密是怎麼運作的),關於:

  • 塊設備加密與堆棧式文件系統加密的對比
  • 密鑰管理
  • 密碼及操作模式
  • 元數據存儲
  • 「下層目錄」的位置(在堆棧式文件系統加密的情況下)

示例[編輯 | 編輯原始碼]

在實踐中,結果可能是這樣的:

示例 1
僅利用用戶的家目錄(home directory)裡的一個被用 EncFS 加密的路徑名為 ~/Private 的虛擬文件夾的簡單的(內部硬碟驅動器)用戶數據加密
  • 被 on-disk 存儲的文件的加密版本位於 ~/.Private(encrypted versions of the files stored on-disk in ~/.Private
  • 使用專用密碼按需解鎖
示例 2
部分系統加密,每個用戶的主目錄用 ECryptfs 加密
  • 使用帳戶登錄密碼,在各個用戶登錄時被解鎖
  • 具有用LUKS的dm-crypt加密的 swap/tmp 分區,使用每個會話自動生成的一次性密鑰
  • 禁止 slocate(及類似的應用程式)索引或緩存 /home 的內容
示例 3
系統加密——具有用LUKS的dm-crypt加密的整個硬碟驅動器,/boot 分區除外(不過,用 GRUB 引導時,/boot 可被加密)
  • 使用密碼或帶有密鑰文件的 U 盤,在引導期間解鎖
  • 每個用戶可能有不同的密碼/密鑰——可獨立撤銷的
  • 可用 LUKS on LVM 實現跨驅動器加密或靈活性分區布局
示例 4
隱藏式/plain 系統加密——具有 plain dm-crypt 加密的整個硬碟驅動器
  • USB-boot,使用專用密碼 + 帶有密鑰文件的U盤
  • 在掛載前檢查數據完整性
  • /boot 分區位於上述U盤上
示例 5
文件容器加密——將預分配的文件用作用戶數據的加密容器

當然還有許多其他的組合。你應該仔細計劃什麼樣的設置適合你的系統。

選用強密碼[編輯 | 編輯原始碼]

參閱 Security#Passwords.

準備磁碟[編輯 | 編輯原始碼]

在一(部分)磁碟上設置加密之前,先考慮安全地擦除它。這包括用零字節或隨機字節的流覆蓋整個驅動器或分區,並且出於以下一個或兩個原因而做:

防止恢復以前存儲的數據

當文件系統創建或修改這些特定扇區所保存的數據時,磁碟加密不會改變單個扇區僅按需覆蓋的事實(請參閱下面的#加密是怎麼運作的。文件系統認為「當前未使用」的扇區不會被觸及,並且可能仍包含來自先前文件系統的數據殘餘。確保無法恢復之前存儲在驅動器上的所有數據的唯一方法是手動擦除它。 為此,使用零字節或隨機字節都沒有關係(儘管使用零字節擦除會快得多)。

防止洩露加密驅動器上的使用模式

理想情況下,磁碟的整個加密部分應該與均勻隨機數據無法區分。這樣,未經授權的人就無法知道哪些扇區以及多少個扇區實際上包含加密數據——這本身可能是一個理想的目標(作為真正機密性的一部分),也可以作為抵禦試圖破解加密的攻擊者的額外屏障。 為了實現這個目標,使用高質量隨機字節擦除磁碟至關重要。

第二個目標僅與塊設備加密結合使用才有意義,因為在堆棧式文件系統加密的情況下,無論如何都可以輕鬆定位加密數據(以獨特的加密文件的形式出現於宿主文件系統中)。另請注意,即使你只打算加密特定文件夾,如果你想刪除以前以未加密形式存儲在該文件夾中的文件,則必須擦除整個分區(由於磁碟碎片)。如果同一分區上還有其他文件夾,則必須備份它們,然後再將它們移回。

確定要執行哪種磁碟擦除後,請參閱文章 安全擦除磁碟 以獲取技術說明。

提示:在決定使用哪種方法對硬碟驅動器進行安全擦除時,請記住,只要驅動器被用作加密驅動器,就不需要多次執行此操作。

加密是怎麼運作的[編輯 | 編輯原始碼]

本節旨在作為對常規磁碟加密的核心設置的概念和過程的高級介紹。

它不涉及技術或數學細節(請查閱相應的文獻),但應該讓系統管理員大致了解不同的設置選擇(尤其是關於密鑰管理)如何影響可用性和安全性。

基本原則[編輯 | 編輯原始碼]

出於磁碟加密的目的,每個塊設備(或堆棧式文件系統加密情況下的單個文件)被劃分為等長的扇區,例如 512 字節(4,096 位)。然後在每個扇區的基礎上進行加密/解密,因此磁碟上塊設備/文件的第 n 個扇區將存儲原始數據的第 n個扇區的加密版本。

每當作業系統或應用程式從塊設備/文件請求某個數據片段時,包含數據的整個扇區(或扇區們)將被從磁碟讀取,被即時解密,並被臨時存儲在內存中:

           ╔═══════╗
  扇区 1   ║“???……”║
           ╠═══════╣         ╭┈┈┈╮
  扇区 2   ║“???……”║         ┊ 密钥 ┊
           ╠═══════╣         ╰┈┬┈╯
          :              :              │
           ╠═══════╣             ▼             ┣┉┉┉┉┉┉┉┫
  扇区 n   ║“???……”║━━━━━(解密)━━━━▶┋“甲乙丙……”┋   扇区 n
           ╠═══════╣                            ┣┉┉┉┉┉┉┉┫
          :              :
           ╚═══════╝

              磁盘上加密的                                RAM 中解密的数据
              块设备或文件                      
        

同樣,在每次寫入操作中,所有受影響的扇區都一定會被徹底地重加密(而其餘扇區不受影響)。

為了能夠對數據進行解密/加密,磁碟加密系統需要知道與之相關的唯一的秘密 "鑰匙"。每當要掛載相關的加密塊設備或文件夾時,必須提供與其相對應的密鑰(以下稱為「主密鑰」)。

密鑰的熵對於加密的安全性至關重要。一個隨機生成的一定長度的字節串,例如32位元組(256比特),雖具有所需的安全性,卻沒法記憶,也無法在掛載期間手動應用。

出於這個原因,有兩種技術被用作輔助手段。第一種是應用密碼學來增加主密鑰的熵值,通常涉及一個單獨的人類友好的口令。對於不同類型的加密,#比較表列出了各自的特點。第二種方法是創建一個具有高熵的密鑰文件,並將其存儲在與要加密的數據驅動器分開的介質上。

另請參閱維基百科:認證加密(英文頁面)

密鑰、密鑰文件和密碼短語[編輯 | 編輯原始碼]

以下是如何使用密鑰文件來存儲、加密保護主密鑰的示例:

存儲在明文密鑰文件中

簡直(以可讀形式)將主密鑰存儲在文件中是最簡單的選擇。該文件——被稱為「密鑰文件」——可以放置於你保存在安全位置的 U 盤上,並且僅在你想要掛載磁碟的加密部分時(例如在啟動或登錄期間)將它連接到計算機。

以受密碼保護的形式存儲在密鑰文件或磁碟本身中

主密鑰(以及加密數據)可以使用一段必須記下來且每次你想要掛載加密的塊設備或文件夾時都必須輸入的保密密碼短語(secret passphrase)進行保護。有關詳細信息,請參閱下面的#加密的元數據

給每個會話隨機生成一個臨時的

在某些情況下,例如在加密交換空間(swap)或 /tmp 分區時,根本不需要保留永久的主密鑰。可以給每個會話隨機生成一個新的一次性密鑰,而無需任何用戶交互。這意味著一旦被卸載,寫入相關分區的所有文件都不能被任何人再次解密——在那些特定的用例中,這非常好。

加密的元數據[編輯 | 編輯原始碼]

加密技術經常使用密碼函數來增強主密鑰本身的安全性。在掛載加密設備時,密碼或密鑰文件通過這些(密碼函數)傳遞,只有結果才能解鎖主密鑰以解密數據。

一個常見的設置是(通過一種「密鑰導出函數(key derivation function)」)對密碼短語(passphrase)應用所謂的「密鑰拉伸(key stretching)」,並使用生成的增強密碼短語作為掛載密鑰來解密(之前以加密的形式存儲的)實際的主密鑰:

 ╭┈┈┈┈┈┈┈╮                           ╭┈┈┈┈┈╮
 ┊ 挂载密码短语 ┊━━━━⎛密钥导出⎞━━━▶┊ 挂载密钥 ┊
 ╰┈┈┈┈┈┈┈╯   ,──⎝  函数  ⎠        ╰┈┈┬┈┈╯
 ╭──╮          ╱                               │
 │ 盐 │────´                                  │
 ╰──╯                                           │
 ╭───────╮                                 ▼           ╭┈┈┈┈╮
 │ 加密的主密钥 │━━━━━━━━━━━━━━━(解密)━━━▶┊ 主密钥 ┊
 ╰───────╯                                              ╰┈┈┈┈╯

密鑰導出函數(如 PBKDF2 或 scrypt)刻意地放慢速度(它應用一個哈希函數的多次迭代,例如 HMAC-SHA-512 的 1000 次迭代),因此通過暴力破解來找到密碼短語變得不可行。對於認證用戶的正常用例,每個會話只需要計算一次,因此小的減速不是問題。 它(密鑰導出函數)還需要一個額外的數據塊,即所謂的「」,作為一個參數——在設置磁碟加密期間隨機生成一次,並被作為加密元數據的一部分不受保護地存儲。因為每次設置的值都不同,攻擊者無法使用密鑰導出函數的預計算表來加速暴力破解。

加密的主密鑰可以與加密的數據一起存儲在磁碟上。這樣,加密數據的機密性完全取決於保密密碼短語。

可以通過將加密的主密鑰存儲在密鑰文件中來獲得額外的安全性,例如U 盤。這提供了雙重身份驗證(two-factor authentication):現在訪問加密數據需要只有你知道的內容(密碼短語),以及只有你擁有的內容(密鑰文件)。

實現雙重身份驗證的另一種方法是增強上述密鑰檢索方案,以數學方式將密碼短語與從(位於U 盤或類似設備上的)一個或多個外部文件讀取的字節數據「結合」起來,然後將其傳遞給密鑰導出函數。任何文件都在考慮範圍之中,例如有助於#合理推諉[損壞的連結:無效的章節]的普通的JPEG圖像。不過,在這種情況下,它們仍然被稱為「密鑰文件」。

在其導出後,只要掛載了加密的塊設備或文件夾,主密鑰就會被安全地存儲在內存中(例如,在內核密鑰環中)。

不過,它通常不直接用於對磁碟數據進行加/解密。 例如,在堆棧式文件系統加密的情形中,每個文件都可以自動分配它自己的加密密鑰。每當文件要被讀取/修改時,這個文件密鑰首先需要用主密鑰進行解密,然後它本身才能用於對文件內容進行加/解密。

                           ╭┈┈┈┈┈╮
                           ┊  主密钥  ┊
   磁盘上的文件:          ╰┈┈┬┈┈╯
  ┌──────────┐       │
  ╎╭────────╮╎       ▼         ╭┈┈┈┈┈╮
  ╎│ 加密的文件密钥 │━━━(解密)━━▶┊ 文件密钥 ┊
  ╎╰────────╯╎                  ╰┈┈┬┈┈╯
  ╎┌────────┐╎                        ▼          ┌┈┈┈┈┈┈┈┈┈┐
  ╎│ 加密的文件内容 │◀━━━━━━━━━━(加/解密)━━▶┊ 可读取的文件内容 ┊
  ╎└────────┘╎                                    └┈┈┈┈┈┈┈┈┈┘
  └──────────┘

以類似的方式,在堆棧式文件系統加密的情形下,可以使用單獨的密鑰(例如,每個文件夾一個)來加密文件名。

在塊設備加密的情況下,每個設備使用一個主密鑰,因此使用所有數據。一些方法提供了為同一設備分配多個密碼短語/密鑰文件的特性,而另一些方法則沒有。有些使用上述函數來保護主密鑰,有些則把密鑰安全的控制權完全交給用戶。通過 dm-crypt 在 plain 或 LUKS 模式下使用的加密參數解釋兩個例子。

當比較兩種模式使用的參數時,我們注意到 dm-crypt plain 模式有關於如何定位密鑰文件的參數(如--keyfile-size--keyfile-offset)。dm-crypt LUKS 模式不需要這些,因為每個塊設備在開頭都包含一個帶有加密元數據的標頭。標頭包括使用的密碼、加密的主密鑰本身以及派生解密所需的參數。後面的參數又來自於主密鑰初始加密時使用的選項(如--iter-time--use-random)。

對於不同技術的優/缺點,請參考#比較表或瀏覽特定頁面。

另請參閱:

密碼和操作模式[編輯 | 編輯原始碼]

用於在相對於給定加密密鑰彼此對應的未加密和加密數據(所謂的「明文(plaintext)」和「密文(ciphertext)」)之間進行轉換的實際算法稱為「密碼(cipher)」。

磁碟加密採用「塊密碼(block cipher)」,它對固定長度的數據塊進行操作,例如16 字節(128 位)。在撰寫本文時,主要使用的是:

塊大小 密鑰大小 注釋
AES 128 bits 128、192 或 256 bits 經 NSA 批准用於保護「機密」和「絕密」機密的美國政府信息(當使用 192 或256位的密鑰大小時)
Blowfish 64 bits 32–448 bits 最早公開的無專利安全密碼之一,因此在 Linux上非常成熟
Twofish 128 bits 128、192 或 256 bits 作為 Blowfish的繼任者而開發,但尚未得到廣泛使用
Serpent 128 bits 128、192 或 256 bits 被認為是入圍AES決賽的五個算法中最安全的[10][11][12].

加/解密扇區(見上文[損壞的連結:無效的章節])是通過將其劃分為與密碼的塊大小相匹配的小塊來實現的,並遵循特定的規則集(所謂的「操作模式(mode of operation)」)將密碼連續地應用於各個塊。

僅將其不加以修改地單獨應用於每個區塊(被稱為 "電子編碼本(electronic codebook,ECB)"模式)是不安全的。因為如果相同的 16 字節明文總會產生相同的16 字節密文,攻擊者可輕易識別出存儲在磁碟上的密文中的加密模式。

實踐中使用的最基本(且常見的)操作模式是「密碼分組連結(cipher-block chaining,CBC)」。使用此模式加密扇區時,每個明文數據塊以數學方式與前一個塊的密文組合,然後使用密碼對其進行加密。對於第一個塊,由於它之前沒有密文,因此使用了一個特殊的預生成的數據塊(data block),該數據塊與扇區的加密的元數據(cryptographic metadata)一起存儲,稱為「初始化向量 (initialization vector,IV)」:

                                          ╭─────╮
                                          │初始化向量│
                                          ╰──┬──╯
           ╭  ╠═════╣       ╭─密钥    │      ┣┉┉┉┉┉┫
           │  ║          ║       ▼          ▼      ┋          ┋       . 开始
           ┴  ║"????????"║◀━(密码)━━━(+)━━┋"Hello, W"┋ 块  ╱╰──┐
        文件或 ║          ║                           ┋          ┋ 1   ╲╭──┘
      块设备的 ║          ║-─────────╮      ┋          ┋       '
      n 号扇区 ╟─────╢       ╭─密钥    │      ┠┉┉┉┉┉┨
           ┬  ║          ║       ▼          ▼      ┋          ┋
           │  ║"????????"║◀━(密码)━━━(+)━━┋"orld!!!!"┋ 块
           │  ║          ║                           ┋          ┋ 2 
           │  ║          ║-─────────╮      ┋          ┋
           │  ╟─────╢                   │      ┠┉┉┉┉┉┨
           │  ║          ║                   ▼      ┋          ┋
          :   :   ...   :        ...         ...     :   ...   :  ...

                磁盘上的密文                             RAM 中的明文

類似地,在解密時,程序是反過來的。

對應於每個扇區的唯一的初始化向量的生成是值得注意的。最簡單的選擇是把現成的數值(如扇區號碼)以某種可預見的方式計算。但這將給可以重複訪問系統的攻擊者執行所謂的水印攻擊以可乘之機。為了預防這種情況,可以使用一種稱為 「加密的鹽扇區初始化向量 (Encrypted salt-sector initialization vector,ESSIV)」的方法來生成初始化向量,使它們在潛在攻擊者看來完全隨機。

還有許多其他更複雜的操作模式可用於磁碟加密,它們已經提供了針對此類攻擊的內置安全性(因此不需要 ESSIV)。 有些還可以額外保證加密數據的真實性(即確認它沒有被無權訪問密鑰的人修改/損壞)。

另請參見:

合理推諉[編輯 | 編輯原始碼]

參見 Wikipedia:Plausible deniability.

用於磁碟加密場景的數據備份[編輯 | 編輯原始碼]

為防止數據丟失,製作用戶數據的備份。一般來說,你的被加密數據的備份也應該加密。

塊設備加密[編輯 | 編輯原始碼]

有多種選擇:你可以將加密容器(encryption container)所在的磁碟塊設備(disk block device)備份為映像(image),例如 /dev/sdx;也可以備份加密容器內的文件系統,例如 /dev/mapper/dm_name;亦可備份裡面的文件,例如使用 rsync。 以下部分列出了每個選項的優點和缺點。

磁碟塊設備備份[編輯 | 編輯原始碼]

磁碟塊設備備份會:

  • 按原樣加密,具有與工作副本(working copy)相同的安全級別
  • 包含你的 LUKS 標頭
  • 總是和磁碟塊設備一樣大
  • 難以使用高級備份策略,例如增量備份、壓縮或重複數據刪除
  • 易於恢復到新磁碟因其亦恢復加密容器

文件系統或文件備份[編輯 | 編輯原始碼]

文件系統或文件備份,它:

  • 按原樣加密
  • 應在通過網絡傳輸之前或保存到磁碟時進行加密。需做額外的工作
  • 未必具有與工作副本相同的安全級別
  • 不包含你的LUKS標頭
  • 僅與文件系統上的已用空間一樣大,比如看看partclone
  • 可使用高級備份策略,例如增量備份、壓縮或重複數據刪除
  • 需要手動將加密容器恢復到新磁碟,例如通過恢復 LUKS 標頭的備份

LUKS 標頭備份[編輯 | 編輯原始碼]

如果使用 LUKS,則可以對 LUKS 標頭進行備份:定期檢查與同步這些備份是有意義的,尤其是在密碼已被撤銷的情況下。

但是,如果你有數據備份,並且想要恢復它,你可以使用 cryptsetup 從頭開始重新創建 LUKS 加密分區,然後恢復數據,因此備份 LUKS 標頭不如備份數據重要。