ディスク暗号化は、ストレージ メディアがセクター アドレス指定可能なデバイス (ハード ディスクなど) である場合の、保存データ保護の特殊なケースです。この記事では、この問題の暗号化の側面について説明します。概要については、 「ディスク暗号化」を参照してください。この問題に特化したさまざまなソフトウェア パッケージとハードウェア デバイスについては、「ディスク暗号化ソフトウェア」および「ディスク暗号化ハードウェア」を参照してください。
問題の定義
ディスク暗号化方法は、次の 3 つの異なる特性を提供することを目的としています。
- ディスク上のデータは機密に保たれるべきです。
- データがディスク上のどこに保存されているかに関係なく、データの取得と保存は両方とも高速に行われる必要があります。
- 暗号化方法はディスク領域を無駄にしてはいけません (つまり、暗号化されたデータに使用されるストレージの量は、プレーンテキストのサイズよりも大幅に大きくなってはなりません)。
最初の特性では、データの機密性を保つ 敵を定義する必要があります。ディスク暗号化の分野で研究されている最強の敵には、次のような能力があります。
- いつでもディスクの生のコンテンツを読み取ることができます。
- ディスクに任意のファイルを暗号化して保存するよう要求できます。
- ディスク上の未使用セクターを変更し、その復号を要求することもできます。
時間の経過とともに、そのような攻撃者が判断できる唯一の情報が、セクター内のデータが前回調べたときから変更されたかどうかだけである場合、その方法は優れた機密性を提供します。
2番目のプロパティでは、ディスクを複数のセクター(通常は512バイト)に分割する必要があります(ブロック暗号は、最大4096ビットの長さのブロックで構成され、それぞれが独立して暗号化および復号化されます。また、データの機密性を保つには、暗号化方式を微調整可能にする必要があります。つまり、2 つのセクターをまったく同じ方法で処理することはできません。そうしないと、攻撃者はディスクの未使用セクターにコピーして復号化を要求することで、ディスクの任意のセクターを復号化できます。通常のブロック暗号の目的は、任意の秘密鍵のランダムな順列を模倣することですが、微調整可能な暗号化の目的は、任意の秘密鍵と任意の既知の微調整のランダムな順列を模倣することです。
3 番目の特性は、一般的に議論の余地がありません。ただし、ストリーム暗号の使用を間接的に禁止します。ストリーム暗号では、セキュリティ上、同じ初期状態を 2 回使用しない (セクターが異なるデータで更新される場合に該当) ことが求められるためです。そのため、暗号化方式では、ディスク上のセクターごとに個別の初期状態を格納する必要がありますが、これはスペースの無駄のように思えます。代替手段であるブロック暗号は、特定のブロック サイズ (通常は 128 ビットまたは 256 ビット) に制限されます。このため、ディスク暗号化では主に、暗号化ブロックの長さをディスク セクター全体に拡張する連鎖モードを研究します。すでに挙げた考慮事項により、よく知られている連鎖モードのいくつかは不適切です。たとえば、微調整できないECB モードや、ブロック暗号をストリーム暗号に変換するモード ( CTR モードなど) などです。
これら 3 つの特性は、ディスクの整合性を保証するものではありません。つまり、敵対者が暗号文を変更したかどうかはわかりません。これは、ディスクの整合性を絶対的に保証することが不可能なことが一因です。敵対者は、どのような場合でも、このようなチェックを回避して、ディスク全体を以前の状態に戻すことができます。絶対的ではないレベルのディスク整合性が必要な場合は、暗号化されたディスク内で、メッセージ認証コードを使用してファイルごとに実現できます。
追加のスペースを取ることが許容される場合
ディスク暗号化は長さを維持するべきであると以前は一般的に受け入れられていましたが、いくつかの追加機能により余分なスペースの使用が正当化されています。1つの例は認証暗号化で、セクターの整合性を保証する代わりに余分なスペースを使用します。この保証の1つの用途は、攻撃者がファイルシステムを破壊してカーネルバグを引き起こすのを防ぐことです。[1]
狭いブロックと広いブロック
ディスク暗号化方式も、「ナローブロック」方式と「ワイドブロック」方式に区別されます。セクターサイズの平文の場合、ナローブロック方式では複数のブロックで暗号化しますが、ワイドブロック方式では 1 つのブロックで暗号化します。LRW、XES、XTS などのナローブロック方式では、攻撃者がブロックの粒度を利用してトラフィック分析と再生を実行できます。[2]ワイドブロック暗号は、平文のどこかが変更されても暗号文全体を認識できないようにするのが理想的です。[3]
ブロック暗号ベースのモード
ほとんどの暗号化方式と同様に、ブロック暗号ベースのディスク暗号化では、暗号のブロック サイズ (通常 128 ビット) よりも大量のデータを暗号化できる操作モードが使用されます。したがって、モードとは、暗号の単一ブロック操作を繰り返し適用する方法に関する規則です。
暗号ブロック連鎖 (CBC)
暗号ブロック連鎖(CBC) は、暗号化の前に、前のブロックの暗号文と現在のブロックの平文を 排他的論理和する一般的な連鎖モードです。
最初のブロックには「前のブロックの暗号文」がないので、初期化ベクトル(IV) を使用する必要があります。これにより、CBC はいくつかの方法で調整可能になります。
CBC にはいくつかの問題があります。たとえば、 IV が予測可能な場合、攻撃者はディスクに「ウォーターマーク」を残すことができます。つまり、暗号化後でも識別可能な特別に作成されたファイルまたはファイルの組み合わせを保存します。ウォーターマークを作成する正確な方法は、IV を提供する正確な関数によって異なりますが、一般的なレシピは、最初のブロックとが同一の 2 つの暗号化セクターを作成することです。この 2 つは、 によって互いに関連付けられます。したがって、 の暗号化はの暗号化と同一であり、ディスクにウォーターマークが残ります。ディスク上の「同じ-異なる-同じ-異なる」の正確なパターンを変更して、ウォーターマークを特定のファイルに固有のものにすることができます。
ウォーターマーク攻撃から保護するために、暗号またはハッシュ関数を使用してキーと現在のセクター番号から IV を生成し、攻撃者が IV を予測できないようにします。特に、ESSIV アプローチでは、CTR モードのブロック暗号を使用して IV を生成します。
暗号化ソルトセクター初期化ベクトル (ESSIV)
ESSIV は、ディスク暗号化で使用するブロック暗号化の初期化ベクトルを生成する方法です。IV を生成する通常の方法は、タイムスタンプやセクター番号などに基づく予測可能な数字のシーケンスであり、透かし攻撃などの特定の攻撃を許します。ESSIV は、セクター番号 SN とキーのハッシュの組み合わせから IV を生成することで、このような攻撃を防ぎます。ハッシュ形式のキーとの組み合わせにより、IV が予測不可能になります。[4] [5]
ESSIVはClemens Fruhwirthによって設計され、バージョン2.6.10以降Linuxカーネルに統合されていますが、同様のスキームは2000年からOpenBSDのスワップ暗号化用のIVを生成するために使用されています。[6]
ESSIVはdm-crypt [7]およびFreeOTFEディスク暗号化システムによってオプションとしてサポートされています。
可塑性攻撃
CBC(ESSIVの有無にかかわらず)は機密性を保証しますが、暗号化されたデータの完全性は保証しません。平文が攻撃者に知られている場合、2番目の平文ブロックごとに攻撃者が選択した値に変更し、その間のブロックをランダムな値に変更することができます。これは、CBCまたはCBC-ESSIVモードのディスク暗号化に対する実用的な攻撃に使用できます。[8]
リスコフ、リベスト、ワグナー(LRW)
調整可能なナローブロック暗号化(LRW)[9]は、 Liskov、Rivest、およびWagner [10]によって導入された操作モードのインスタンス化です(定理2を参照)。このモードでは、2つのキーを使用します。はブロック暗号のキーで、はブロックと同じサイズの追加キーです。たとえば、256ビットキーのAESの場合、は256ビットの数値で、は128ビットの数値です。論理インデックス(調整)を使用してブロックを暗号化するには、次の式を使用します。
ここで、乗算と加算は有限体( AES の場合)で実行されます。事前計算を行うと、セクターごとに 1 回の乗算のみが必要になります (バイナリ有限体での加算は単純なビット単位の加算、つまり xor であることに注意してください)。、ここで はのすべての可能な値について事前計算されます。この操作モードでは、ブロックごとに 1 回の暗号化のみが必要であり、軽微な漏洩を除いて上記のすべての攻撃から保護します。軽微な漏洩とは、ユーザーがセクター内の 1 つの平文ブロックを変更した場合、1 つの暗号文ブロックのみが変更されることです。(これは ECB モードの漏洩と同じではないことに注意してください。LRW モードでは、異なる位置にある等しい平文が異なる暗号文に暗号化されます。)
LRW にはセキュリティ上の懸念があるため、この動作モードは現在 XTS に置き換えられています。
LRW はBestCryptで採用されており、 dm-cryptおよびFreeOTFEディスク暗号化システムのオプションとしてサポートされています。
XOR-暗号化-XOR (XEX)
もう一つの調整可能な暗号化モードであるXEX(xor-encrypt-xor)は、Rogaway [11]によって設計され、1つのデータユニット(たとえば、ディスクセクター)内の連続するブロック(使用される暗号に関して)を効率的に処理できるようにします。調整は、セクターアドレスとセクター内のブロックのインデックスの組み合わせとして表されます(Rogaway [11]によって提案された元のXEXモードでは、複数のインデックスが許可されています)。暗号文は、次のようにして取得されます。
どこ:
- 平文である、
- セクター番号です。
- は多項式によって定義されるの原始元、すなわち数2である。
- セクター内のブロック番号です。XEX では を使用し、XTS では を使用します。
LRW モードの基本的な操作 (AES 暗号とガロア体の乗算) は、ガロア/カウンター モード(GCM) で使用される操作と同じであるため、汎用 LRW/XEX/GCM ハードウェアのコンパクトな実装が可能になります。
本来のXEXには弱点がある。[12]
暗号文窃取機能を備えた XEX ベースの調整コードブック モード (XTS)
暗号文の窃取は、例えば 520 バイトのセクターと 16 バイトのブロックなど、ブロックサイズで割り切れないサイズのセクターをサポートします。XTS-AES は、2007 年 12 月 19 日[13]にIEEE P1619として標準化されました。[14] XTS 標準では、IV 暗号化とブロック暗号化に異なるキーを使用する必要があります。これは、単一のキーのみを使用する XEX とは異なります。[11] [15] : 1–4 結果として、AES -256 および AES-128 暗号化を希望するユーザーは、それぞれ 512 ビットと 256 ビットのキーを提供する必要があります。XTS が CCA セキュアであるためには、2 つのキー (つまり、XTS キーの両方の半分) が異なっている必要があります。これは、XTS がから始まるシーケンスを計算するためです。これは、 から始まる XEX とは異なります。[11] : 7 [15] : 6
2010 年 1 月 27 日、NIST は最終版の特別刊行物 (SP) 800-38E [16]を発表しました。SP 800-38E は、IEEE Std 1619-2007 で標準化された暗号化モジュールの XTS-AES モードの動作に関する推奨事項です。この刊行物は、IEEE Std 1619-2007 を参照してAESアルゴリズムの XTS-AES モードを承認していますが、1 つの追加要件があり、暗号化された各データ ユニット (通常はセクターまたはディスク ブロック)の最大サイズを2 20 AES ブロックに制限しています。SP 800-38E によると、「認証またはアクセス制御がない場合、XTS-AES は、暗号化されたデータの不正な操作に対して、他の承認された機密性のみのモードよりも強力な保護を提供します。」
XTSは、BestCrypt、Botan、NetBSDのcgd、[17] dm-crypt、FreeOTFE、TrueCrypt、VeraCrypt、[18] DiskCryptor、FreeBSDのgeli、OpenBSDソフトレイドディスク暗号化ソフトウェア、OpenSSL、Mac OS X LionのFileVault 2、Windows 10のBitLocker [19]、wolfCryptでサポートされています。
XTS の弱点
XTS モードはデータの操作や改ざんに対して脆弱であり、操作や改ざんが懸念される場合、アプリケーションはデータの変更を検出する手段を採用する必要があります。「認証タグがないため、暗号文 (元のテキストまたは攻撃者によって変更されたもの) はプレーンテキストとして復号化され、変更を検出する組み込みメカニズムはありません。最善の方法は、暗号文の変更によってプレーンテキストが完全にランダム化されるようにし、この変換を使用するアプリケーションがプレーンテキストに十分な冗長性を含めて、そのようなランダムなプレーンテキストを検出して破棄できるようにすることです。」これには、ZFSまたはBtrfsで行われているように、ディスク上のすべてのデータとメタデータのチェックサムを維持する必要があります。ただし、 ext4やNTFSなどの一般的なファイル システムでは、メタデータのみが改ざんから保護されており、データ改ざんの検出は存在しません。[20]
このモードは、セクターおよび 16 バイト ブロックに対するトラフィック分析、リプレイ、ランダム化攻撃の影響を受けやすい。特定のセクターが書き換えられると、攻撃者は細粒度 (16 バイト) の暗号文を収集でき、これを分析またはリプレイ攻撃 (16 バイトの粒度) に使用できる。セクター全体のブロック暗号を定義することは可能だが、残念ながらパフォーマンスは低下する (下記参照)。[2]
CBC–マスク–CBC (CMC) と ECB–マスク–ECB (EME)
CMC と EME は、LRW に関して前述した軽微な漏洩に対しても保護します。残念ながら、その代償としてパフォーマンスが 2 倍低下します。各ブロックを 2 回暗号化する必要があります。セクター レベルでの同じ漏洩はいずれにしても避けられないため、多くの人はこれをコストが高すぎると考えています。
Halevi と Rogaway によって導入された CMC は、CBC–mask–CBC の略です。セクター全体が CBC モード ( を使用) で暗号化され、暗号文は で XOR 演算してマスクされ、最後のブロックから CBC モードで再暗号化されます。基礎となるブロック暗号が強力な疑似ランダム置換(PRP) である場合、セクター レベルではスキームは調整可能な PRP です。1 つの問題は、復号化するために、すべてのデータを 2 回連続して通過させる必要がある ことです。
この問題を解決するために、Halevi と Rogaway は EME (ECB–mask–ECB) と呼ばれる並列化可能な変種を導入しました。これは次のように動作します。
- 平文は と排他的論理和され、異なる量だけ左にシフトされ、暗号化されます: ;
- マスクは次のように計算されます: 、ここでおよび;
- 中間暗号文はマスクされます:および の場合;
- 最終的な暗号文は次のように計算されます。
LRW や CMC とは異なり、キーは 1 つしかないことに注意してください。
CMCとEMEはSISWGによって標準化が検討されました。EMEは特許取得済みであるため、主にサポートされるモードとしては好ましくありません。[21]
HCTRとHCTR2
HCTR(2005)は、長さ保存、ワイドブロック、調整可能なブロック暗号の動作モードです。[22]しかし、仕様にバグがあり、セキュリティ証明にもバグがあり、主張されているセキュリティレベルが無効になっています。HCTR2(2021)は、これらの問題を修正し、セキュリティ、パフォーマンス、柔軟性を向上させた変種です。[23] HCTR2は、バージョン6.0以降のLinuxカーネルで利用できます。
HCTRとHCTR2は、XCTRと呼ばれるカスタムブロック暗号モードを使用します。HCTR2には通常、AES-128-XCTRが使用されます。HCTR2は、POLYVALと呼ばれる多項式ハッシュ関数を使用します。HCTR2は、AES命令とキャリーレス乗算命令を備えた最新のプロセッサで効率的です。[23]
ストリーム暗号モード
2018年にGoogleの従業員によって公開されたHBSH(ハッシュ、ブロック暗号、ストリーム暗号、ハッシュ)構造により、ディスク暗号化に高速ストリーム暗号を使用できるようになりました。ローエンドのAndroidデバイスで使用されているAdiantumスキームでは、 NH、256ビットAdvanced Encryption Standard(AES-256)、ChaCha12、およびPoly1305が具体的に選択されています。この構造は調整可能で、ブロックが広いです。データに対して3回のパスが必要ですが、ARM Cortex-A7( AES命令セットがない)上のAES-128-XTSよりも高速です。[24] Linuxカーネルバージョン5.0以降で使用できます。
2023年、アルド・ガンシング、ジョアン・デイメン、バート・メニンクは、ストリーム暗号も使用する「ダブルデッカー」構造を発表しました。これもまた調整可能で、ブロックが広いです。[3]
特許
認証付き暗号化方式IAPMは暗号化と認証タグを提供しますが、IAPMモードの暗号化コンポーネントは上記のLRWおよびXEX方式を完全に記述し、したがって暗号文窃取の側面のないXTSです。これは米国特許6,963,976の図8と図5に詳細に説明されています。[25]
参照
- データの残留
- コールドブート攻撃
- ディスク暗号化ソフトウェア
- ディスク暗号化ハードウェア
- IEEE P1619、ストレージデータの暗号化の標準化プロジェクト
参考文献
- ^ Poettering, Lennart. 「一般的な Linux ディストリビューションにおける認証ブートとディスク暗号化の奇妙な状態」0pointer.net。
- ^ Thomas Ptacek、Erin Ptacek (2014-04-30)。「XTS は不要」。
- ^ ab Aldo Gunsing、Joan Daemen、Bart Mennink。デッキベースのワイドブロック暗号モード(PDF)。ブロック暗号の動作モードに関する第3回NISTワークショップ2023。
- ^ Fruhwirth, Clemens; Schuster, Markus (2005 年 12 月)。「秘密メッセージ: DM-Crypt、LUKS、cryptsetup によるハードディスク暗号化」(PDF)。Linux Magazine。第 61 号。pp. 65–71。2024年8 月 22 日閲覧。
- ^ Fruhwirth, Clemens (2005 年 7 月 18 日). 「ハードディスク暗号化の新しい方法」(PDF) .ウィーン工科大学. 2024 年8 月 22 日閲覧。
- ^ Provos, Niels (2000). 仮想メモリの暗号化(PDF) .第 9 回 USENIX セキュリティ シンポジウム. コロラド州デンバー。
- ^ Milan Broz. 「DMCrypt dm-crypt: Linuxカーネルデバイスマッパー暗号ターゲット」. gitlab.com . 2015年4月5日閲覧。
- ^ Jakob Lell (2013-12-22). 「CBC 暗号化 LUKS パーティションに対する実用的な可変性攻撃」
- ^ 最新のSISWGおよびIEEE P1619ドラフトと会議情報はP1619ホームページ[1]に掲載されています。
- ^ M. Liskov、R. Rivest、D. Wagner。調整可能なブロック暗号[2] 2008年12月5日にWayback Machineにアーカイブ、CRYPTO '02 (LNCS、第2442巻)、2002年。
- ^ abcd Rogaway, Phillip (2004-09-24). 「調整可能なブロック暗号の効率的なインスタンス化と OCB および PMAC モードの改良」(PDF)。コンピュータサイエンス学部(PDF)。 カリフォルニア大学デービス校。
- ^ 峰松和彦 (2007)。「XEX および LRW モードのセキュリティ分析の改善」(PDF)。暗号学の特定分野。コンピュータサイエンスの講義ノート。第 4356 巻。pp. 96–113。doi : 10.1007 / 978-3-540-74462-7_8。ISBN 978-3-540-74461-0。
- ^ Karen McCabe (2007 年 12 月 19 日)。「IEEE がデータ暗号化の標準を承認」IEEE 標準協会。2008 年 3 月 6 日時点のオリジナルよりアーカイブ。
- ^ ブロック指向ストレージデバイス上のデータの暗号化保護に関するIEEE標準。2008年4月18日。pp. 1–40。doi :10.1109 / IEEESTD.2008.4493450。ISBN 978-0-7381-5363-6。
{{cite book}}:|journal=無視されました (ヘルプ) - ^ ab リスコフ、モーゼス;峰松 和彦 (2008-09-02) 「XTS-AESに関するコメント」(PDF)。
- ^ Morris Dworkin (2010 年 1 月)。「ブロック暗号の動作モードに関する推奨事項: ストレージ デバイスの機密性のための XTS-AES モード」(PDF)。NIST 特別出版物 800-38E。米国国立標準技術研究所。doi :10.6028/ NIST.SP.800-38E。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ 「NetBSD 暗号化ディスクドライバー」。2019 年 1 月 8 日時点のオリジナルよりアーカイブ。2019 年 1 月 7 日閲覧。
- ^ 「動作モード」。VeraCryptドキュメント。IDRIX。2017年 10 月 13 日閲覧。
- ^ 「BitLocker の新機能」。2015 年 11 月 12 日。2015 年 11 月 15 日に閲覧。
- ^ ブロック指向ストレージデバイス上のデータの暗号化保護の標準(PDF)、IEEE P1619/D16、2007、p. 34、2016年4月14日のオリジナル(PDF)からアーカイブ、 2012年9月14日取得
- ^ P. Rogaway、「従来のブロック暗号からワイドブロックサイズのブロック暗号を構築するためのブロック暗号モードの動作」、米国特許出願 20040131182 A1。
- ^ Wang, Peng; Feng, Dengguo; Wu, Wenling (2005). 「HCTR: 可変入力長暗号化モード」.情報セキュリティと暗号学. コンピュータサイエンスの講義ノート. 第3822巻. pp. 175–188. doi :10.1007/11599548_15. ISBN 978-3-540-30855-3。
- ^ ab 「HCTR2による長さ保存暗号化」2021年。
- ^ Crowley, Paul; Biggers, Eric (2018 年 12 月 13 日)。「Adiantum: エントリーレベル プロセッサ向け長さ保存暗号化」。IACR Transactions on Symmetric Cryptology : 39–61。doi : 10.13154 /tosc.v2018.i4.39-61。
- ^ * 米国特許第6,963,976号、「対称鍵認証暗号化方式」(2000年11月出願、2005年11月発行、2022年11月25日に失効)[3] 2018年8月11日にWayback Machineにアーカイブ[4]。
さらに読む
- S. Halevi および P. Rogaway、「調整可能な暗号化モード」、CRYPTO '03 (LNCS、第 2729 巻)、2003 年。
- S. HaleviとP. Rogaway、「並列化可能な暗号化モード」 [5]、2003年。
- 暗号化共有ストレージメディアの標準アーキテクチャ、IEEEプロジェクト1619(P1619)、[6]。
- SISWG、鍵バックアップフォーマットの草案提案[7]、2004年。
- SISWG、調整可能なワイドブロック暗号化の草案提案[8]、2004年。EME-32-AESについて説明
- ジェームズ・ヒューズ、暗号化ストレージ - 課題と方法[9] 2006-05-18 にアーカイブされたWayback Machine
- J. Alex Halderman、Seth D. Schoen、Nadia Heninger、William Clarkson、William Paul、Joseph A. Calandrino、Ariel J. Feldman、Jacob Appelbaum、およびEdward W. Felten (2008-02-21)。「Lest We Remember: 暗号化キーに対するコールドブート攻撃」(PDF)。プリンストン大学。2008-05-14 のオリジナル(PDF)からアーカイブ。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要ですCS1 maint: multiple names: authors list (link) - Niels Fergusson (2006 年 8 月)。「AES-CBC + Elephant Diffuser: Windows Vista 用のディスク暗号化アルゴリズム」(PDF) 。Microsoft。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - Chakraborty, Debrup; López, Cuauhtemoc Mancillas; Sarkar, Palash (2018 年 4 月)。「ディスク暗号化: 長さを保持する必要があるか?」(PDF)。Journal of Cryptographic Engineering。8 (1): 49–69。doi : 10.1007 /s13389-016-0147-0。S2CID 4647765 。
外部リンク
- ストレージのセキュリティワーキンググループ SISWG。
- 「eSTREAM プロジェクト」。2012 年 4 月 15 日にオリジナルからアーカイブ。2010年 3 月 28 日に取得。
