VeraCryptおよびLUKSで暗号化されたボリュームは、データ破損に対してどの程度回復力がありますか?


19

質問は部分的に回答されましたが、それは私がまさに探しているものではありません。Update 1ダウンベアを参照

私はVeraCryptとLUKSでいくつかのファイルシステムを暗号化することを計画していますが、単一の問題が発生すると、パーティションを再度マウントできず、その中に保存されているすべてのデータが失われるのではないかと心配です。(破損したセクター/ブロック、書き込み操作中の電源障害、ファイルシステムエラーなど)

また、VeraCryptはTrueCryptの修復ツールを分岐した可能性がありますが、実際のケースについて詳しく調べているわけではありません。

RAIDとバックアップ/ボールトについても知っていますが、探しているものではありません。

質問は次のとおりです。暗号化されたパーティション自体は、VeraCryptとLUKSを使用してどの程度回復力がありますか?

アップデート1

私の質問は、マスターキー、メタデータ、またはヘッダーを保存することではなく、暗号化されたパーティションとそのデータの復元力についてです。この問題は、7zipの固体アーカイブに似ています。1つのビットが途中で破損すると、アーカイブ全体が失われます。

暗号化されたパーティションも同様に脆弱ですか?(マスターキー、メタデータ、ヘッダーを除く)

PS:すぐに答えなければ申し訳ありませんが、私は世界中で仕事と旅行をしています(この投稿に関連するものです)。しかし、私は間違いなく返事をします。

回答:


13

実際には、マスターキーとメタデータを適切にバックアップしていれば、暗号化を使用してもほとんど使用しなくても回復力があります。

メタデータとは別に、破損は破損したビットのブロックだけに影響し、ほとんどの場合は16バイトになります。

キーやツール(パスワードやVeracrypt / LUKSなど)を使用したデータ破損のほとんどの状況では、通常の暗号化ディスクの使用と同じように、非暗号化ディスクと同じアクセス権があります。暗号化は、通常よりも追加の手順(暗号化されたパーティションを開く)のみを追加します。したがって、この場合、暗号化されていないデータのように動作します。

VeracryptまたはLuksでは、パスワードで暗号化されたマスターキーをディスクに保存する必要があります。このセクターを損傷すると、永続的なデータが失われます。これは、両方のソフトウェアで簡単に実行できるマスターキーバックアップ(サイズが数キロバイト)で簡単に解決できるため、すべてのユーザーに強くお勧めします。

非メタデータに関する詳細

VeracryptとLuksは現在XTSを使用しています。このモードでは、すべてのブロックのキーが計算されます。簡略化すると、ブロックを暗号化iするには、マスターキーとブロック番号で生成されたキーを使用します。したがって、あるブロックを別のブロックから独立して暗号化します。一部の情報が破損した場合、そのブロックに制限されます。

XTSでは、ブロックをサブブロック(通常16バイト)に分割し、キーを作成して、そのサブブロックを暗号化します。つまり、少し変更すると、この16バイトのみが影響を受けます。

テストとして、Luksボリュームの1ビットを変更すると、元のファイルの16バイトが意味不明に変更されますが、他の496は変更されません。7zipファイルでは、すべてのバイトがチェーンされているストリームメソッドを使用するため、1バイトの変更が残りのすべてに影響します。これはここでは当てはまりません。

暗号化されたデータだけを比較してプレーンテキストを変更するときと場所を16バイトの精度で知ることができるように、これを問題と考える人もいます。

これに関するより興味深い情報はこれらのリンクで見つけることができます:

/crypto/6185/what-is-a-tweakable-block-cipher

/security/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

マスターキーの詳細

ルークス

LUKSのパーティション(またはディスク)の先頭には、メタデータ、暗号化方法、その他のパラメーター、8つのキースロットが格納されたいくつかのセクターがあります。ディスクの暗号化と復号化には、LUKSコンテナの作成時に生成される大きな乱数であるマスターキーを使用します。保存するには、パスワードで暗号化ハッシュ関数を何度も繰り返し、そのスロットに特定のキーを生成することにより、パスワードでマスターキーを暗号化します。同じディスクに対して8つの異なるパスワードを使用できます。各パスワードは、スロット内の異なるパスワードでマスターキーを暗号化します。パスワードを変更すると、すべてのパーティションを変更するのではなく、マスターキーを暗号化するのと同じくらい簡単になります。

そのため、このスロットとメタデータが破損すると、復号化に実際に使用されるマスターキーを回復できず、ディスク上のすべてのデータが失われます。これは、すべてのデータを迅速に破壊する簡単な方法です。ただし、ボリュームヘッダーのバックアップがある場合は、簡単に復元できます。

以下は、https: //gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recoveryから抽出されたバックアップに関するLUKS FAQのコピーです

6.2 LUKSヘッダーをバックアップするにはどうすればよいですか?

LUKSパーティションの先頭から適切なバイト数をコピーすることもできますが、最良の方法は、cryptsetupのコマンドオプション「luksHeaderBackup」を使用することです。これにより、LUKSパーティションの作成で非標準のパラメーターが使用された場合のエラーからも保護されます。例:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

復元するには、逆のコマンドを使用します、すなわち

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

復元するヘッダーが不明な場合は、まず現在のヘッダーのバックアップを作成してください!次のように、デタッチされたヘッダーに--headerオプションを使用することにより、ヘッダーファイルを復元せずにテストすることもできます。

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

それがあなたのキースロットのロックを解除するなら、あなたは良いです。もう一度デバイスを閉じることを忘れないでください。

状況によっては(ヘッダーが破損している)、これは失敗します。次に、次の手順を使用します。

最初にマスターキーのサイズを決定します。

cryptsetup luksDump <device>

フォームの行を与えます

MK bits:        <bits>

古いデフォルトでは256、新しいデフォルトでは512に等しいビットを使用します。256ビットは、ヘッダーの合計サイズが1'052'672バイトに等しく、512ビットが2MiBの1つです。(項目6.12も参照)luksDumpが失敗した場合、2MiBを想定しますが、それを復元する場合は、ファイルシステムの最初の1M程度を復元することもできることに注意してください。ヘッダーサイズを特定できなかった場合は、ファイルシステムを変更しないでください!これにより、大きすぎるヘッダーバックアップを復元しても安全です。

次に、ヘッダーをファイルにダンプします。それを行うには多くの方法がありますが、私は次のことを好みます:

head -c 1052672 <device>  >  header_backup.dmp

または

head -c 2M <device>  >  header_backup.dmp

2MiBヘッダー用。ダンプファイルのサイズを確認してください。このようなバックアップを復元するには、luksHeaderRestoreを試すか、より基本的な

cat header_backup.dmp  >  <device>

ベラクリプト

VeracryptはLUKSに似ています。Truecryptを使用していたので、私はそれを使用していませんが、一般的な考えは保持されます。

Veracryptにはキースロットが1つしかないため、同時に複数のパスワードを持つことはできません。ただし、隠しボリュームを作成することもできます。パーティション(またはディスクやファイル)の最後にメタデータが保存されます。隠しボリュームには異なるマスターキーがあり、パーティションの終わりを重複スペースとして使用します。バックアップする必要があるという考え方は同じです。これはで行うことができるTools -> Backup Volume HeaderTools -> Restore Volume Header。システムの暗号化では、損傷が発生した場合にTruecryptローダーとキーを回復するキーバックアップを備えた起動可能なディスクを作成していました。それは何かを暗号化する前に行われ、私が知る限り、Veracryptは同じ方法を続けます。

詳細については、このリンクhttps://veracrypt.codeplex.com/wikipage?title=Program%20Menuを参照してください

バックアップキーに関するセキュリティの考慮事項

たとえば、漏洩したパスワードがあり、ボリュームパスワードを新しく強力で安全なパスワードに変更した場合、バックアップにアクセスできるユーザーは、古いパスワードでファイルを解読できます。バックアップは、基本的に(古い)パスワードで暗号化されたマスターキーです。そのため、パスワードを変更するときは、新しいバックアップを作成して古いバックアップを破棄する必要もあります。また、データを完全に破壊することは非常に難しい場合があります。

そのパスワードであなたが持っているすべてのバックアップに対して、そのパスワードでデータを解読する可能な方法です。たとえば、これはVeracryptで使用できます。たとえば、「Universal Password」(企業の場合)を使用してバックアップし、別のパスワードに変更します。だからIT部門。誰かがパスワードを紛失した場合でも、そのボリュームへのアクセスを回復できます(マスターパスワードと考えますが、以前のマスターキーと混同しないでください)。

最終的な考え(TL; DR)

マスターキーで特定のセクターが破損する可能性は、完全なディスク障害が発生するよりも少なくなります。したがって、このデータが重要な場合は、ボリュームヘッダー(マスターキー)だけではなく、バックアップを作成する必要があります。

また、データの破損はほとんど拡散せず(16バイト)、ほとんどの用途で受け入れられます。

そのため、パーティションまたはディスクの中央の不良ブロックは、そのブロックのみに影響します。また、セクタ内の数ビットエラーはそのセクタに制限されており、512バイトのセクタ全体には影響しません。

更新(2017年1月23日):OPコメントに基づいて情報を追加します。


1
うわー、それは非常に広範囲かつ有益な答えでした、どうもありがとう!ただし、私の質問は、マスターキーとメタデータではなく、暗号化されたパーティションとデータ自体の復元力に関するものです。この問題は、7zipの固体アーカイブに似ています。1つのビットが途中で破損すると、アーカイブ全体が失われます。暗号化されたパーティションは同じように機能しますか?(マスターキーとメタデータは除外)
X.LINK

4

以下に、VeraCrypt / TrueCryptコンテナーの復元力に関するいくつかの情報をまとめました。

Veracryptデータ破損から:

TC / VCは、ボリュームヘッダーをボリュームの最初と最後の2つの場所に保存します。最初のものがメインのもので、最後のものがバックアップ用です。通常、このメカニズムは、ドライブの一部が損傷または破損している場合にアクセスを可能にするのに十分です。これは、損傷が多くの場合局所的だからです。ドライブの開始と終了の両方で損傷が発生した場合、ドライブはほぼ確実に停止しています。

ドライブが破損または破損した場合、暗号化を使用しない場合と同じデータ損失が発生することに注意してください。これは、ボリュームをマウントできる場合でも、そこに読み込まれたデータが破損する可能性があることを意味します。そのため、暗号化はデータの破損から保護されないため、データのバックアップを常に考慮してください。

VeraCrypt FAQから:

VeraCryptボリュームの一部が破損するとどうなりますか?

暗号化されたデータでは、1ビットの破損ビットが通常、それが発生した暗号文ブロック全体を破損します。VeraCryptが使用する暗号文ブロックサイズは16バイト(つまり、128ビット)です。VeraCryptで使用される操作モードにより、ブロック内でデータ破損が発生しても、残りのブロックは影響を受けません。

VeraCryptボリュームの暗号化されたファイルシステムが破損した場合、どうすればよいですか?

VeraCryptボリューム内のファイルシステムは、通常の暗号化されていないファイルシステムと同様に破損する可能性があります。その場合は、オペレーティングシステムに付属のファイルシステム修復ツールを使用して修正できます。Windowsでは、「chkdsk」ツールです。VeraCryptは、VeraCryptボリュームでこのツールを簡単に使用する方法を提供します。メインのVeraCryptウィンドウ(ドライブリスト)でマウントされたボリュームを右クリックし、コンテキストメニューから[ファイルシステムの修復]を選択します。

その場合、小さなデータの破損はローカルにのみ影響し、コンテナ全体は破壊されません。ただし、リカバリはより複雑になる可能性があるため、ボリューム/パーティション全体、特にシステムドライブを暗号化することはお勧めしません。特にボリュームヘッダーについては、適切なバックアップを作成してください。また、実際のディスクまたはフォルダーと同様に、ディスク/ファイルヘッダーの破損によりデータの回復が困難になり、高度なユーティリティが必要になる場合があることを忘れないでください。

LUKSにはディスク上に2番目のヘッダーがないため、バックアップの保持にはさらに注意する必要があります。


私はそれらを読みましたが、これはまだ少し混乱しています。コンテナ内のコンテナのヘッダーとファイルシステムを介したリカバリとは別に、コンテナ自体の真ん中にある不良セクタが完全に死んでマウントできなくなることはありませんか?私はそれを正しく理解するかもしれませんが、暗号文ブロックは、物理的な不良セクタがあるまだマウント可能な非ソリッド7-zipアーカイブ/暗号化されていないext3の内部とまったく同じように機能しますか?
X.LINK

暗号化されたボリュームについて話すことはできませんが、暗号化された暗号文の単一ビットを変更すると、ブロック全体のゴミが吐き出されます。ブロックサイズは128バイトまたは256バイトまたは4kbです。暗号化テキストの残りの部分が復号化されるのを防ぐことはできません。暗号化アルゴリズムがガベージが悪いことを知る方法はありません。チェックサムなどはありません(AES-CBCの場合)。そのブロックがテキストファイル内にある場合、メモ帳ではゴミのように見えます。ディレクトリ構造の一部である場合、ファイルシステムは文字化けして表示され、が必要になりますchkdsk
クロエ

@ X.LINK:不良ビットは、16バイトの「セクター」全体を破損します。そのセクターの場所に応じて、未使用の領域に落ちても結果は何もないか、ファイル内のその場所のゴミか、最悪の場合、回復ユーティリティの使用を必要とする不正なディレクトリ構造になります。これは、未使用のセクター、ファイルデータ、ディスクテーブルがある物理ディスクと非常によく似ており、バックアップも同様のガイドラインに従う必要があります。
harrymc

0

人々が提供したすべての答えのおかげで、決定的な答えは100%完成しています。

最近は時間があまりないので、後で「自分の」回答を編集します。ここで人々が出したすべての答えは完全に有用なので、これは彼らが言ったことの要約に加えて、私の調査結果にもなります。

とにかく、ここで私が出会った多くの混乱を解く私の発見の1つがあり、それは主に懸念しています...それは過度に誤って使用されている用語であるため、ブロックが意味するものです

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

また、ここで物事について話すための「標準的な」方法を見つけ、「ブロック」の混乱を避けます。

/superuser/1176839/what-are-every-possible-names-of-hard-drives-structure-parts

要するに、「400」という単語を含む暗号化されたブロックを「800」に変更できます。これは、「これは通常のファイルシステムのように振る舞う」と信じるのではなく、暗号化されたブロックレベルのレイヤーが完全に非固体であることを意味します(Veracrypt FAQ)。

また、2か月前にそのリンクにつまずいたはずです。

/unix/321488/full-image-of-internal-hdd-drive-dd-dd-rescue-with-truecrypt-bad-sectors/

VeraCryptはTrueCryptのフォークであるため、確かに同じように機能します。

PS:

追加の回答は引き続き歓迎し、私の「自分の」回答に追加されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.