在將數據備份到不受信任的主機之前加密數據時使用正確的加密算法?
我正在編寫一個(非生產/概念證明)備份程序,該程序從您的電腦中獲取文件,將它們拆分為塊,然後讓其他對等方儲存這些塊以創建異地備份。
這些對等方可能是您不想向其披露備份內容的其他方。
這些對等點以點對點的方式工作,允許他們從任何擁有副本的人那裡獲取塊的副本。這意味著複製備份的對等方可以連接到正在備份的機器並從文件中間請求一個塊。
因此,對於正在備份的機器來說,在將數據作為一個塊發送給對等方之前,使用對稱密碼對數據進行本地加密似乎是件好事。
通常,我會認為“使用 AES”。但我隱約知道有一些模式,比如CBC。而且我認為像這樣的鍊式模式會使高效地打開文件、尋找靠近中間的某個位置、讀取一段數據、對其進行加密並得出與它相同的密文變得非常困難從文件的開頭開始並按順序加密所有塊,直到該位置。
做全盤加密的人是怎麼做到的?是否類似於他們用於 Python 的東西(如果重要,則為 3.x)?
為什麼不
gpg
呢?這些庫已經編寫並開源,因此您不必重新創建 wheel。將文件拆分為塊,然後添加一個控製文件,添加您需要將文件保存在一起並屬於正確人員的任何元數據。使用使用者的密鑰加密每個塊,並將其放在不受信任的主機上。然後,他將是唯一可以解密文件的人。假設不受信任的主機不刪除塊。
磁碟加密和線上備份具有不同的執行緒模型。適合一個人的不一定適合另一個人。
磁碟加密通常只能防止一種威脅:磁碟被盜。通過這種威脅,攻擊者獲得了一個加密形式的數據版本,目標是維護數據的機密性。
線上備份系統需要防禦另外兩個重要威脅。如果攻擊者能夠訪問儲存備份的伺服器,他們就可以訪問多個版本的加密數據。因此,重要的是連續密文之間的差異不會過多地揭示明文。此外,當您從備份恢復時,驗證備份是否真實非常重要。有權訪問伺服器的攻擊者可能已經破壞了密文,即使他們無法破譯它。
磁碟加密通常使用XTS 模式。XTS 獨立加密每個磁碟塊。一個塊的連續版本使用相同的密鑰和 IV 加密,這可以揭示一個共同的前綴,但僅此而已。(XTS 的延展性不是很強,不像 CTR,重複計數器值會立即失敗。)XTS 根本不保護數據的真實性。磁碟加密通常不會嘗試驗證真實性或完整性,因為在通常的威脅模型中它不是必需的,並且它對性能有很大影響¹。
對於線上備份,您需要某種形式的認證加密。認證加密保護兩件事:
- 數據的機密性:沒有密鑰,攻擊者只知道大概的大小。通過相同數據的連續版本,攻擊者可以大致了解數據的哪些部分發生了變化。
- 數據的真實性:當你讀回一些數據並驗證它是正確的,你就知道數據是真實的。這裡有一個微妙之處:真正的數據仍然可能放錯地方——它可能來自磁碟上的不同位置,或者來自不同的版本。
為了確保數據是真實的,而無需進行身份驗證並將其作為單個消息全部讀取,您可以使用雜湊樹結構。每個數據塊(或每個文件,取決於您如何建構數據)都有一個身份驗證標籤,並且這些塊/文件被組織在有身份驗證標籤的集合中,並且這些集合被組織在超集中,依此類推,直到你到了根源。要驗證塊是否真實,您需要:
- 驗證其身份驗證標籤是否正確;
- 讀取包含該塊的集合併檢查它是否包含正確的身份驗證標籤;
- 計算和驗證集合的認證標籤;
- 讀取包含該集合的超集,依此類推,直到根。
通過這些驗證,您可以單獨檢索文件(加上檢索父集的少量成本),並確信攻擊者沒有
confidential_data.txt
替代public_mailing.txt
. 您也可以確信攻擊者沒有安排database_schema.txt
從上個月database.db
開始從上週返回。仍然有一個限制:攻擊者可以安排返回一個過時的備份,只要它們返回一致的數據。為避免這種情況,您需要記住上次備份的日期或版本。¹如果您需要真實性保護,則無法進行管道讀取:您必須讀取整個數據塊並對其進行驗證,然後才能將第一個字節提供給閱讀器。此外,為了防止塊重新排序或版本混合匹配,您必須驗證密文是磁碟上該位置的正確密文並且是正確的版本,這意味著寫入需要更新更多元數據。