13

機密性と認証の両方を保証するメッセージの構成要素として、AES256 CBC + HMAC SHA-256 を使用することを考えています。

特に、次のシナリオを検討してください。

  • Alice は Bob に属する公開鍵を所有しています (鍵交換とアルゴリズムはこの質問の範囲外です)。Alice は、Bob と共有されている識別キー K を持っており、これを使用して自分自身を識別することができます。鍵 K を知っているのは Alice と Bob だけです。
  • Alice は、Bob の公開鍵を使用して (nonce || K) を暗号化します。
  • Bob はパケットを復号化し、K と nonce を取得しました。
  • Bob は SHA-256 と SHA256(K || nonce) を使用して、256 ビットの K(e) を生成します。
  • Bob は SHA-256 と SHA256(K || nonce + 1) を使用して、256 ビットの K(s) を生成します。

ここで、ボブがアリスに送信したいすべてのパケットに対して、ボブは次のことを実行します。

  • 新しいランダムな 128 ビット IV を作成する
  • IV と K(e) をキーとして使用してメッセージを暗号化します。
  • K(s) をキーとし、(IV || 暗号化されたメッセージ) をデータとする SHA-256 HMAC を作成します。
  • 最後に (IV || HMAC || 暗号文) を Alice に送信します

Alice も K(e) と K(s) を計算し、Bob からデータを受信するときに次の手順に従います。

  • メッセージを IV、暗号文、および HMAC に分割します。
  • K(s)、IV、および暗号文を使用して HMAC を計算します。
  • HMAC と送信された HMAC を比較します。これが一致する場合、Alice はこのメッセージが Bob によって送信されたメッセージとして認証されたと見なし、そうでない場合は破棄されます。
  • Alice は K(e) を使用してメッセージを復号化します。

このプロトコルは、ボブ以外の誰もアリスが公開鍵を使用して暗号化して送信した暗号化されたメッセージを読むことができないと仮定して、アリスがボブからのメッセージのみを復号化することを保証しますか?

つまり、この方法で作成されたメッセージは、機密性と認証の両方を保証しますか?

注: プロトコルで Bob が複数のメッセージを送信する必要がある場合、リプレイ アタックを回避するために、このスキームを少し変更する必要があります。

PS AES-GCM/CCM を認識していますが、このスキームは、ほとんどの暗号化パッケージに含まれる基本的な AES、SHA、および HMAC アルゴリズムで機能します。このソリューションも遅くなる可能性がありますが、それも問題の範囲外です。

4

3 に答える 3

19

基本的に、SSL/TLSを再作成しています。これは、独自のプロトコルを構築する際の通常の警告を意味し、独自のプロトコルを書き換えるのではなく、既存のライブラリで TLS を使用することを強くお勧めします。

そうは言っても、暗号化には CBC 付きの AES を使用し、整合性には HMAC を使用するのが適切です。暗号化 + 整合性モード (ご存知のとおり) が組み合わされており、CBC + HMAC は一種の「古い学校」ですが、害はありません。「科学的に承認された」方法で物事を行っています: 暗号化してから、暗号化された文字列を MAC します (そして、IV を忘れないでください: IV を忘れるのは古典的な間違いです)。

あなたの鍵の派生はやや弱いかもしれません。SHA-256 が完全なランダム オラクルのように動作する場合は完璧ですが、SHA-256 がランダム オラクルのように動作しないことが知られています (いわゆる長さ拡張攻撃のため)。これは、HMAC が HMAC であり、MAC キーとデータの連結を単純に (1 回) ハッシュするのではなく、2 つのネストされたハッシュ関数呼び出しを使用する理由と似ています。TLS は、問題を回避する特定のキー派生関数 (TLS 仕様では「PRF」と呼ばれます) を使用します。この関数は SHA-256 (実際には HMAC/SHA-256) で構築されており、一般的な SHA-256 実装の周りに実装できます。

(あなたのキー導出プロセスを攻撃する方法を知っていると言っているのではありません。これを適切に作成するのは難しいことであり、そのセキュリティは何百人もの暗号学者による何年にもわたる精査の後にのみ評価される可能性があるということです。これが、関数を再利用し、すでに徹底的に検討されたプロトコルは、基本的には良い考えです。)

TLS には、「クライアント ランダム」と「サーバー ランダム」と呼ばれる2 つのノンスがあります。あなたの提案では、「クライアントランダム」しかありません。ここで失われるものは、セキュリティに関して、ちょっと不明確です。慎重な戦略は、サーバー ランダム (つまり、ボブによって選択された別のナンス) を含めることです。回避したいのは、Alice と Bob が双方向でプロトコルを実行し、攻撃者が Alice から Alice 自身にメッセージを送信する場合です。攻撃者ができることの完全な分析は複雑です (これは暗号化の全分野です)。一般的に言えば、両方向のナンスはいくつかの問題を回避する傾向があります。

複数のパケットを送信すると、パケットの損失、重複したパケット (「リプレイ攻撃」)、および順不同で到着するパケットに関する問題が発生する可能性があります。TLS のコンテキストでは、データが厳密な順序で転送されることを (通常の条件下では、アクティブな攻撃はカウントしない) 既に保証しているメディア上で TLS が使用されるため、これは「通常」発生するべきではありません。したがって、TLS は、MAC に入るデータにシーケンス番号を含めます。これにより、リプレイ、レコードの紛失、レコードの並べ替えなど、攻撃者による変更が検出されます。可能であれば、シーケンス番号も使用する必要があります。

于 2011-03-08T17:34:32.373 に答える
2

前述の質問に対する答えはノーです。アリスがボブからのメッセージのみを復号化するという保証はありませんが、それは、ボブだけがKを知っていると規定していないためです。Kを知っているのが Alice と Bob の 2 人だけである場合、問題の核心は、鍵生成プロトコルが正しいかどうかです。(HMAC-SHA256 と AES256 は意図されたとおりに使用しているだけなので、残りは無視できると思います。)

生成プロトコルは悪くありませんが、改善の余地があります。共有シークレットからキーを作成するための一般的な方法は、「キー派生関数」を使用することです。これらの関数は、ここで行ったのと同様の方法でハッシュを使用しますが、ブルート フォース攻撃を阻止するために意図的に遅くしています。 PBKDF2は、a) 512 ビット (またはそれ以上) のキー データを導出でき、b) 利用可能なプリミティブで構成できるため、あなたが望むもののようです。つまり、SHA256 と HMAC-SHA256 です。

于 2011-03-08T17:03:05.157 に答える
1

PKI を使用したくない場合は、TLS-PSK を参照してください。あなたが自分で解決している正確な問題を解決するように見えるでしょう。RFC 4279 (および追加の暗号スイートについては 5487) を参照してください。

于 2013-12-09T10:42:03.847 に答える