web-dev-qa-db-ja.com

パフォーマンスとセキュリティの観点から、「DH-group14-sha1 with hmac-sha2-256」と「DH-group-exchange-sha256 with hmac-sha2-256」のどちらが優れていますか？

私たちの製品（組み込みシステム）では、これまでdiffie-hellman-group1-sha1とhmac-sha1を使用していました。ただし、セキュリティ上の懸念から、鍵の交換にはdiffie-hellman-group14を、HMACにはhmac-sha2-256を使用する予定です。

Diffie-hellman-group14-sha1とhmac-sha2-256を併用しても問題ありませんか。パフォーマンスとセキュリティの観点から、diffie-hellman-group14-sha1とhmac-sha2-256の組み合わせは良いでしょうか？

Diffie-hellman-group-exchange-sha256とhmac-sha2-256の組み合わせを使用すると、パフォーマンスに大きな影響があります。

組み込みシステムを使用しているので、セキュリティとパフォーマンスのバランスを微調整したいと考えています。

意見をいただければ幸いです。

sshkey-exchangehmacdiffie-hellmansha256
3
Rakesh Gupta

この質問の述べられていないコンテキストはSSHサーバーです。これらはSSHトランスポートプロトコルの交渉可能な暗号化オプションです。これを示すために質問を更新することができます。

あなたの質問の形から、私はまず何かを片付けたいです。あなたが尋ねるとき：

Hiff-hellman-group14-sha1をhmac-sha2-256と一緒に使用しても問題ありませんか？パフォーマンスとセキュリティの観点から、diffie-hellman-group14-sha1とhmac-sha2-256の組み合わせは良いでしょうか？

...これは、これらのアルゴリズムの単なる組み合わせに懸念事項があると考えていることを示しているようです。ありません。それらは完全に独立しています。これら：

  • diffie-hellman-group1-sha1
  • diffie-hellman-group14
  • diffie-hellman-group-exchange-sha256

...は鍵交換アルゴリズムです。これらは、トランスポートプロトコルの早い段階でセッションキー（暗号化/ MAC）を確立するために使用され、プロセスでサーバーを認証します。これら：

  • hmac-sha1
  • hmac-sha2-256

...は、プロトコルによって後で送信されるユーザーデータの整合性チェックを実装するために使用されるMACアルゴリズムの名前です。これらは後で使用され、鍵交換の出力から派生した鍵が使用されます。 SHA-1とSHA-256の「混在」に問題があると思うために質問している場合、私が知る限り、このシナリオでそれを心配する理由はありません。

Diffie-hellman-group-exchange-sha256とhmac-sha2-256の組み合わせを使用すると、パフォーマンスに大きな影響がありますか？.

これで、SSH Diffie-Hellman鍵交換の「グループ交換」バージョンが導入されました。これにより、サーバーは、「group1」および「group14」交換で規定された固定グループの代わりに、ローカルに構成されたDiffie-Hellmanパラメータ（有限グループ）を使用できます。パフォーマンスへの影響は、提供するグループによって決定され、主に問題のグループのサイズによって決まります。より小さなグループを使用することでオーバーヘッドを削減でき、それに応じてセキュリティも低下します。クライアントはサイズごとに係数を要求するため、クライアントを満足させるのに十分な大きさのグループを提供する必要があることに注意してください。

2
Richard E. Silverman

他の答えは質問に答えるようには見えません、用語の使い方と悪い仮定を明確にするだけです。したがって、どちらが良いかを知りたい場合は、diffie-hellman-group14-sha1とdiffie-hellman-group14-sha1のどちらを使用するかを次に示します。

問題の一部は、SHA2とSHA1の間です。 SHA2はSHA1よりも強力で、diffie-hellman-group-exchange-sha256はSHA2です。

もう1つは、交換で使用される素数です。 group14素数は強い（2048ビット）と見なされますが、それらは公に知られています。グループ交換素数は、素数のサーバー側リストとクライアント側の制限に依存します。 Linux上のOpenSSHでは、これらを含む/ etc/ssh/moduliファイルがあります。そのファイルはディストリビューションによって提供されるため、それらも公に知られていますが、変更することができます。

現在の各サイズの数を確認するには、次のようにします。

awk '$1 != "#" {print $5+1}' /etc/ssh/moduli | sort | uniq -c

私がテストしたいくつかのUbuntu 16.04システムで同じことを言うのはどれですか。

 49 1536
 40 2048
 37 3072
 38 4096
 37 6144
 36 7680
 29 8192

したがって、グループ交換では1536サイズの非常に小さいキーを使用する可能性があります。したがって、group14（Oakley Group 14、サイズ2048）に一致する最も小さいキーをすべて削除する場合、（sha256がsha1よりも優れているため）おそらくより良いはずです。あなたはそれらを公に知られないように制御することができます。いずれにしても、クライアントが独自の最小値と最大値を制限している場合、サイズの変更は効果がない可能性がありますが、問題はありません。または、大きいサイズを好むがminが低い場合、LogJamのようなダウングレード攻撃が機能する可能性があります。

2048以上の素数のみを含むようにファイルをトリミングするには（まだ公表されています）、おそらく次のようにします。

awk '$1 == "#" || $5 >= 2048 {print $0}' /etc/ssh/moduli > /etc/ssh/moduli.tmp
mv /etc/ssh/moduli /etc/ssh/moduli.bak.$(date +%s)
mv /etc/ssh/moduli.tmp /etc/ssh/moduli

そして、おそらく知られていない（もちろん重複する可能性がある）ユニークな素数の新しいファイルを作成するには、それらを生成できます（これには数時間かかる場合があります）。

mv /etc/ssh/moduli /etc/ssh/moduli.bak.$(date +%s)
ssh-keygen -G /tmp/moduli -b 2048
ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli

この後、sshdを再起動することをお勧めします。

https://blog.gdssecurity.com/labs/2015/8/3/ssh-weak-diffie-hellman-group-identification-tool.html も参照してください

0
Peter