web-dev-qa-db-ja.com

バックアップサーバーが信頼されていない場合の複製暗号化はどの程度堅牢ですか?

この質問 およびそれが参照する article に対する上位の回答は、攻撃者がTruecryptコンテナのスナップショットを長期にわたって見ることができる場合、暗号化が弱められることを説明しています。同じ答えは、暗号化されたデータをリモートサーバーに保存する問題に対して、 duplicity がより良い解決策である可能性があることを示唆しています。

誰かがこれについてもう少し詳しく説明できるかどうかを尋ねたかったのです。重複バックアップモデルでは、フルバックアップを使用してから、増分変更のバックアップを使用します。セキュリティの観点から、これは連続するスナップショットのバックアップの明らかな改善ですか?重複モデルには他の弱点がありますか? (私は厳密に暗号化のセキュリティの観点から意味します:バックアップ、ストレージスペース、帯域幅などを回復する時間を除きます)

7
SauceCode

厳密に暗号化した意味で、複製モデルには弱点がありません。

複製は、宛先サーバーが信頼されていない場合の脅威モデル用に特別に設計されています。すでに暗号化されたデータの差分を転送するのではなく、new暗号化ファイルを新しいキーで送信するため、増分バックアップが大幅に改善されます。ある特定の増分スナップショットと後の日付の別のスナップショットが類似していることを確認する方法はありません。各スナップショットは固定サイズです(デフォルトでは25 MiB)。攻撃者の観点から見ると、新しいスナップショットは25 MiB相当の完全に新しいファイル、25 MiB相当の増分変更、または25 MiB相当のメタデータ(ファイル削除レコードなど)を保持できます。これは、XTSモードを使用するブロックデバイスとは対照的です。XTSモードでは、時間の経過による変化を監視できるときに情報が漏洩する傾向があります。

Duplicityは、GnuPGを使用してファイルに署名し、完全性を保証します。 XTSモードはしばしば「貧乏人の可鍛性」と見なされますが、それは実際には非常に貧弱であり、16バイトの精度での変更が可能です。 Duplicityのデジタル署名により、CBCモードを使用している場合でも、変更されたビットが1つでも検出されます。

Duplicityのバックアップは、いくつかの段階で行われます。

  • rsyncは、ファイルのキャッシュされたレコードとファイルシステムの違いを比較するために使用されます
  • tarを使用して、25 MiB相当の増分変更を1つのファイルにアーカイブします。
  • gpgはtarballの暗号化と署名に使用されます
  • 暗号化されたtarballが一度に宛先サーバーに送信されます

XTSモードは、時間の経過に伴う変化が観察されると多くの情報を提供しますが、宛先サーバーが重複して確認できるのは、変更されたデータの量だけです。たとえば、50 MiBのファイルを取り、それをバックアップしてから、その半分を変更してから、増分バックアップを再度行うとします。 XTSでこれを行うと、変更された正確な領域が表示されます。重複があると、2つの暗号化された25 MiBファイルが表示され、後で別の暗号化された25 MiBファイルが表示されます。最初のバックアップと2番目の増分バックアップを比較して、変更されたデータを確認することはできません。わかるのは、どれだけ変化したかだけです。

信頼できないサーバーが重複して監視できる正確な情報は非常に限られています。

  • 保存されたデータの総量
  • 各バックアップで転送されたデータの量(変更の数にほぼ対応)
  • 保存されたデータのおおよそのサイズ(定期的な非増分完全バックアップのため)
4
forest