AES暗号化モード（CBC ECB CTR OCB CFB）の選択方法は？

StackOverflow https://stackoverflow.com/questions/1220751

  •  10-07-2019
  •  | 
  •  

質問

どの状況でどちらが優先されますか？

さまざまなモードの評価基準のリストと、各基準の適用可能性についての議論をご覧ください。

たとえば、 基準の1つは「コードのサイズ」だと思います。 802.11ネットワークアダプタなどのマイクロコード組み込みシステムにとって重要な暗号化および復号化用。 CBCを実装するために必要なコードがCTRに必要なコードよりもはるかに小さい場合（これが本当かどうかはわかりませんが、これは単なる例です）、小さいコードのモードが優先される理由を理解できました。ただし、サーバーで実行するアプリを作成しており、使用しているAESライブラリがCBCとCTRの両方を実装している場合、この基準は無関係です。

「評価基準と各基準の適用可能性のリスト」の意味を参照してください。 ？

これは実際にはプログラミング関連ではありませんが、アルゴリズム関連です。

役に立ちましたか？

解決

  • 同じキーで複数のデータブロックを暗号化する場合、ECBは使用しないでください。

  • CBC、OFB、CFBは似ていますが、OFB / CFBの方が優れているのは、暗号化のみが必要であり、復号化は必要ないため、コードスペースを節約できます。

  • CBCは、CBC / OFB / CFBではなく、適切な並列化（速度など）が必要な場合に使用されます。

  • XTSモードは、ランダムにアクセス可能なデータ（ハードディスクやRAMなど）をエンコードする場合に最も一般的です。

  • OCBは、単一パスで暗号化と認証を許可するため、断然最良のモードです。ただし、米国には特許があります。

本当に知っておく必要があるのは、1ブロックのみを暗号化している場合を除き、ECBを使用しないことです。ストリームではなく、ランダムにアクセスされるデータを暗号化する場合は、XTSを使用する必要があります。

  • 常に一意の IV を暗号化するたびに使用する必要があり、それらは< href = "https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator" rel = "noreferrer">ランダム。それらがランダムであることを保証できない場合は、 nonce 、 IV 、そして明確な違いがあります。 nonce は、次の IV がこの問題を引き起こす可能性があります。

他のヒント

独自の暗号化の実装を回避できない場合は、長く厳しい検討を行ってください

問題のい真実は、この質問をしている場合、おそらく安全なシステムを設計および実装できないことです。

私のポイントを説明しましょう。Webアプリケーションを構築していて、セッションデータを保存する必要があるとします。各ユーザーにセッションIDを割り当て、セッションIDをセッションデータにマッピングするハッシュマップでサーバーにセッションデータを保存できます。しかし、その後、サーバー上でこの厄介な状態に対処する必要があり、ある時点で複数のサーバーが必要になると、事態は面倒になります。そのため、代わりに、セッションデータをクライアント側のCookieに保存するという考えがあります。もちろん、ユーザーがデータを読み取って操作できないように暗号化します。それでは、どのモードを使用する必要がありますか？ここに来ると、一番上の答えが表示されます（myforwikを1つだけ削除して申し訳ありません）。最初の1つ-ECB-はあなたのためではなく、複数のブロックを暗号化したい、次の1つ-CBC-は良さそうで、CTRの並列処理は必要なく、ランダムアクセスは必要ないので、 XTSと特許はPITAなので、OCBはありません。暗号ライブラリを使用すると、ブロックサイズの倍数しか暗号化できないため、パディングが必要であることがわかります。 PKCS7 を選択するのは、いくつかの深刻な暗号化規格で定義されているためです。 CBCが確かに安全ランダムIVと安全なブロック暗号を使用すると、機密データをクライアント側に保存していても安心できます。

サービスが実際にかなりの規模に成長してから数年後、ITセキュリティスペシャリストが責任ある情報開示で連絡します。彼女は、パディングオラクル攻撃を使用して、すべてのCookieを復号化できると言っています。 、パディングが何らかの理由で破損している場合、コードでエラーページが生成されるためです。

これは架空のシナリオではありません： Microsoftは、数年前までASP.NETにこの正確な欠陥がありました。

問題は、暗号化に関して多くの落とし穴があり、素人には安全に見えるが、知識のある攻撃者にとっては簡単に破れるシステムを構築することは非常に簡単です。

データを暗号化する必要がある場合の対処方法

ライブ接続にはTLSを使用します（証明書と発行者チェーンのホスト名を必ず確認してください）。 TLSを使用できない場合は、システムがタスクに対して提供する必要がある最高レベルのAPIを探し、システムが提供する保証と、保証しないものをより重要に理解してください。上記の例では、 Play のようなフレームワークはクライアント側のストレージ機能、しばらくすると保存されたデータは無効になりませんが、クライアント側の状態を変更した場合、攻撃者は気付かずに以前の状態を復元できます。

高レベルの抽象化が利用できない場合は、高レベルの暗号化ライブラリを使用します。顕著な例は NaCl であり、多くの言語バインディングを備えた移植可能な実装はナトリウム。このようなライブラリを使用すると、暗号化モードなどを気にする必要はありませんが、ノンスを2回使用しないなど、高レベルの抽象化よりも使用の詳細に注意する必要があります。

somの場合たとえば、既存のシステムと特定の方法で対話する必要があるため、高レベルの暗号化ライブラリを使用できない場合、徹底的に自分自身を教育する方法はありません。 Ferguson、Kono、Schneierによる暗号工学を読むことをお勧めします。必要なバックグラウンドがなくても安全なシステムを構築できると信じ込まないでください。暗号化は非常に微妙であり、システムのセキュリティをテストすることはほとんど不可能です。

モードの比較

暗号化のみ：

  • パディングが必要なモード： 例のように、パディングは一般的に危険です。なぜなら、パディングはオラクル攻撃のパディングの可能性を開くからです。最も簡単な防御策は、復号化の前にすべてのメッセージを認証することです。下記参照。
    • ECB はデータの各ブロックを個別に暗号化し、同じプレーンテキストブロックは同じ暗号文ブロックになります。 ECB WikipediaページでECB暗号化Tuxイメージをご覧くださいこれが深刻な問題である理由。 ECBが受け入れられるユースケースは知りません。
    • CBC にはIVがあるため、メッセージが暗号化されるたびにランダム性が必要です。メッセージの一部を変更するには、変更後にすべてを再暗号化する必要があります。1つの暗号文ブロックの送信エラーにより、平文が完全に破壊されます次のブロックの復号化を変更します。復号化は並列化できますが、暗号化はできません。平文はある程度順応性があります-これは問題になる可能性があります。
  • ストリーム暗号モード：これらのモードは、プレーンテキストに依存する場合と依存しない場合があるデータの擬似ランダムストリームを生成します。一般にストリーム暗号と同様に、生成された擬似ランダムストリームはプレーンテキストとXORされて、暗号テキストが生成されます。ランダムストリームのビットを好きなだけ使用できるので、パディングはまったく必要ありません。この単純さの欠点は、暗号化が完全に malleable であるということです。攻撃者は、平文p1、暗号文c1、および擬似ランダムストリームrに関して好きな方法で変更でき、攻撃者は暗号文c2 = c1＆＃8853; dの復号化がp2 = p1＆ ＃8853; d、p2 = c2＆＃8853; r =（c1＆＃8853; d）＆＃8853; r = d＆＃8853; （c1＆＃8853; r）。また、2つの暗号文c1 = p1＆＃8853; rおよびc2 = p2＆＃8853; rの場合と同じ擬似ランダムストリームを2回使用してはなりません。攻撃者は2つの平文のxorをc1＆＃8853; c2 = p1＆＃として計算できます8853; r＆＃8853; p2＆＃8853; r = p1＆＃8853; p2。また、元のメッセージが攻撃者によって取得された可能性がある場合、メッセージを変更するには完全な再暗号化が必要であることを意味します。以下のすべてのスチーム暗号モードは、ブロック暗号の暗号化操作のみを必要とするため、暗号によっては、非常に制限された環境で一部の（シリコンまたはマシンコード）スペースを節約できます。
    • CTR はシンプルで、プレーンテキストに依存しない疑似ランダムストリームを作成します。異なるナンス/ IVからカウントアップして異なるメッセージを取得し、最大メッセージ長を掛けます。オーバーラップが防止され、ノンスメッセージ暗号化を使用すると、メッセージごとのランダム性なしで暗号化が可能になり、復号化と暗号化は並列化が完了し、送信エラーは間違ったビットにのみ影響します
    • OFB は、平文とは異なるpseから独立した擬似ランダムストリームも作成します

2011年にPhil Rogawayによって正式な分析が行われました。こちら。セクション1.6では、ここに書き直した要約を太字で追加します（あなたが短気な場合、彼の推奨はCTRモードを使用することですが、以下のメッセージの整合性と暗号化に関する私の段落を読むことをお勧めします）。

これらのほとんどはIVがランダムである必要があることに注意してください。これは予測不可能であるため、暗号化セキュリティで生成する必要があります。ただし、「nonce」のみを必要とするものもあります。これは、そのプロパティを要求せず、代わりに再利用しないことだけを要求します。したがって、ノンスに依存するデザインは、ノンスに依存するデザインよりもエラーが発生しにくいです（そして、私は、CBCが適切なIV選択で実装されていない多くのケースを見てきました）。したがって、IVがノンスである場合に機密性が達成されないというRogawayのような言葉が私に太字を追加したことがわかります.IV暗号的に安全な（予測できない）IVを選択した場合、問題はありません。ただし、そうしないと、優れたセキュリティプロパティが失われます。 これらのモードのいずれにもIVを再使用しないでください。

また、メッセージの整合性と暗号化の違いを理解することも重要です。暗号化はデータを隠しますが、攻撃者は暗号化されたデータを変更できる可能性があり、メッセージの整合性を確認しないと、結果がソフトウェアによって受け入れられる可能性があります。開発者は「ただし、変更されたデータは復号化後にガベージとして戻る」と言いますが、優れたセキュリティエンジニアは、ガベージがソフトウェアで有害な動作を引き起こす可能性を見つけ、その分析を実際の攻撃に変えます。暗号化が使用された多くのケースを見てきましたが、暗号化よりもメッセージの整合性が本当に必要でした。必要なものを理解します。

GCMには暗号化とメッセージ整合性の両方がありますが、非常に壊れやすい設計であると言えます。IVを再利用すると、ねじ込まれます。攻撃者はキーを回復できます。他のデザインは壊れにくいので、個人的には、実際に見た貧弱な暗号化コードの量に基づいてGCMを推奨することを恐れています。

メッセージの整合性と暗号化の両方が必要な場合、2つのアルゴリズムを組み合わせることができます。通常、CBCとHMACが表示されますが、CBCに結び付ける理由はありません。知っておくべき重要なことは、最初に暗号化してから、MAC暗号化されたコンテンツ、その逆ではありません。また、IVはMAC計算の一部である必要があります。

IPの問題を認識していません。

Rogaway教授の優れた点について：

暗号モードをブロックします。暗号化は行いますが、メッセージの整合性は含めません

ECB ：ブロック暗号。モードは、各nビット断片を個別に暗号化することにより、nビットの倍数であるメッセージを暗号化します。 セキュリティプロパティが弱い。ブロックの位置と時間の両方でブロックの均等性が漏れるメソッドです。かなりのレガシー価値、および他のスキームの構成要素としての価値がありますが、モードはそれ自体では一般的に望ましいセキュリティ目標を達成しないため、慎重に使用する必要があります。 ECBは、「汎用」機密性モードと見なされるべきではありません。

CBC ：IVベースの暗号化スキーム。このモードは確率的暗号化スキームとして安全であり、ランダムなIVを想定して、ランダムなビットと区別できません。 IVが単なるナンスである場合、機密性は達成されません、またはスキームが使用する同じキーの下で暗号化されたナンスである場合は、標準で誤って提案されています。暗号文は非常に順応性があります。選択された暗号文攻撃（CCA）セキュリティはありません。多くのパディング方法の正しいパディングオラクルが存在すると、機密性は失われます。暗号化は本質的にシリアルであることから非効率的です。広く使用されているモードのプライバシーのみのセキュリティプロパティは、頻繁に悪用されます。 CBC-MACアルゴリズムの構成要素として使用できます。 CTRモードよりも重要な利点はありません。

CFB ：IVベースの暗号化スキーム。モードは確率的暗号化スキームとして安全であり、ランダムなIVを想定して、ランダムビットと区別できないようにします。 機密性は、IVが予測可能な場合は達成されません。また、標準で誤って提案されているように、スキームで使用される同じキーで暗号化されたナンスによって作成された場合もありません。暗号文は順応性があります。 CCAセキュリティなし。暗号化は本質的にシリアルであることから非効率的です。スキームはパラメーターs、1＆＃8804;に依存します。 s＆＃8804; n、通常はs = 1またはs =8。sビットのみを処理するために1つのブロック暗号呼び出しが必要な場合は非効率的です。このモードでは、興味深い＆＃8220;自己同期化＆＃8221;プロパティ;任意の数のs-bit文字を暗号テキストに挿入または削除すると、正しい復号化が一時的に中断されるだけです。

OFB ：IVベースの暗号化スキーム。このモードは確率的暗号化スキームとして安全であり、ランダムなIVを想定して、ランダムなビットと区別できません。 IVがナンスの場合、機密性は達成されませんが、IVの固定シーケンス（カウンターなど）は正常に機能します。暗号文は非常に順応性があります。 CCAセキュリティなし。暗号化と復号化は、本質的にシリアルであることから非効率的です。任意のビット長の文字列をネイティブに暗号化します（パディングは不要です）。 CTRモードよりも重要な利点はありません。

CTR ：IVベースの暗号化スキーム。このモードは、ナンスIVを想定したランダムビットとの区別がつきません。ノンスベースの安全なスキームとして、モードは、ランダムIVを使用した確率的暗号化スキームとしても使用できます。ナンスが暗号化または復号化で再利用される場合、プライバシーの完全な障害。モードの並列性により、多くの場合、他の機密性モードよりも、一部の設定でははるかに高速になります。認証された暗号化スキームの重要な構成要素。 全体的に、通常、プライバシーのみの暗号化を実現するための最良かつ最新の方法。

XTS ：IVベースの暗号化スキーム。このモードは、調整可能なブロック暗号（強力なPRPとして安全）を各nビットチャンクに適用することで機能します。長さがnで割り切れないメッセージの場合、最後の2つのブロックは特別に扱われます。モードの使用が許可されているのは、ブロック構造のストレージデバイス上のデータの暗号化のみです。基礎となるPRPの幅が狭いこと、および端数の最終ブロックの処理が不十分なことが問題です。 （ワイドブロック）PRPセキュアブロック暗号よりも効率的ですが望ましくありません。

MAC（メッセージの整合性、暗号化は不可）

ALG1＆＃8211; 6 ：MACのコレクション。すべてがCBC-MACに基づいています。スキームが多すぎます。 VIL PRFとして安全であると証明されるものもあれば、FIL PRFとして安全であるものもあり、証明可能なセキュリティがないものもあります。一部のスキームでは、有害な攻撃が認められています。一部のモードには日付があります。キー分離は、それを備えたモードでは十分に対応されません。まとめて採用するのではなく、＆＃8220;最高の＆＃8221;を選択してくださいスキームが可能です。また、CMACを支持して、これらのモードのいずれも採用しないでください。 ISO 9797-1 MACの一部は、特に銀行業で広く標準化され使用されています。標準の改訂版（ISO / IEC FDIS 9797-1：2010）が間もなくリリースされます[93]。

CMAC ：CBC-MACに基づくMAC。モードは（VIL）PRF（基礎となるブロック暗号が優れたPRPであると仮定）として（誕生日限界まで）確実に安全です。 CBCMACベースのスキームのオーバーヘッドは本質的に最小限です。本質的にser

  1. ECB以外のすべて。
  2. CTRを使用する場合、メッセージごとに異なるIVを使用することが不可欠です。そうしないと、攻撃者は2つの暗号文を取得し、暗号化されていないプレーンテキストを取得できます。その理由は、CTRモードでは基本的にブロック暗号がストリーム暗号に変換されるため、ストリーム暗号の最初のルールは、同じKey + IVを2回使用しないことです。
  3. 実際に、モードの実装がどれほど難しいかに大きな違いはありません。一部のモードでは、暗号化方向で動作するのにブロック暗号のみが必要です。ただし、AESを含むほとんどのブロック暗号は、復号化を実装するのにそれほど多くのコードを必要としません。
  4. すべての暗号モードでは、メッセージが最初の数バイトで同一である可能性があり、攻撃者にこれを知られたくない場合、メッセージごとに異なるIVを使用することが重要です。

Wikipediaでこの情報を読むことから始めます-暗号モードの動作をブロック ？次に、ウィキペディアの参照リンクを参照して、 NIST：ブロック暗号モードの推奨事項操作。

広く利用可能なものに基づいて選択することができます。同じ質問がありましたが、これが私の限られた研究の結果です。

ハードウェアの制限

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

オープンソースの制限

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC

[1] http： //www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/ OpenAES-0.8.0.zip

1つの側面を知っています：CBCは各ブロックのIVを変更することでセキュリティを向上させますが、ランダムにアクセスされる暗号化コンテンツ（暗号化されたハードディスクなど）には適用できません。

したがって、シーケンシャルストリームにはCBC（および他のシーケンシャルモード）を使用し、ランダムアクセスにはECBを使用します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top