3

最初のケースでは、通信ごとに要求を識別する HMAC を生成する必要があるため、サーバーはそれを再生成して、クライアントが承認されていることを確認できます (HMAC は、サーバーのみが知っている秘密鍵で暗号化されており、一方、2 番目のサービスでは、サービスが証明書 (またはトークン) を 1 回発行するだけで済み、それを数分間維持する必要があります。15分-。もちろん、MITM 攻撃やリプレイ攻撃を防ぐには、すべての結果 (より多くの帯域幅とより多くの CPU 要件) を備えた SSL 経由でのみ送信する必要があります。

個人的には、1 番目はより単純であるだけでなく、より強力であることがわかりました。これは、各リクエストが独自のデータを持っているためです。2 番目は SSL 証明書の整合性に依存しています (署名された SSL 証明書を簡単にクラックできると言っているわけではありませんが、誰かがすべての通信ですべてのトラフィックが傍受される可能性があります)。

したがって、次の長所/短所があることがわかりました。

  • HMAC の長所: リクエストごとに一意のトークン。一意のデータを使用して署名とタイムスタンプを構成することにより、MITM およびリプレイ攻撃に対して非常に安全です。実装が簡単です。
  • HMAC の短所: トークンを再生成するために、単一のリクエストごとにサーバーが動作する必要があります。
  • トークン プロ: 複数のリクエストに対して 1 つのトークン。複数のクライアント アクションを必要とするサービスで役立ちます。
  • トークンの短所: すべての通信に SSL が必要です。

最終的な答えを得るにはいくつかのテストを設定する必要があると思いますが、誰かがすでにある程度の知識や過去の経験に基づいた考えを持っているかどうかを知りたい.

4

2 に答える 2

0

HTTP を介したパスワードベース (またはキーベース) のクライアント認証のみが必要な場合は、HMAC の方が適切なソリューションです。最新の HMAC は、暗号分析の点で、公開鍵アルゴリズムよりも信頼性が高くなります。

サーバー側でのランダム トークンの生成は、公開鍵の変換を実行するよりもオーバーヘッドが少なくなります。

PS問題が対称暗号で解決できる場合は、対称暗号で解決することをお勧めします。

于 2012-10-16T05:35:56.400 に答える
0

HMAC と PKI は、まったく異なる問題を解決するように設計されています。

メッセージが転送中に変更されないように保護しようとしている場合、HMAC はその問題を解決するように設計されており、うまく機能します。

転送中にメッセージが読み取られないようにする場合、唯一のオプションは PKI (SSL など) です。ただし、PKI は HMAC よりも厳密に強力な保証を提供します。結局のところ、メッセージを読み取れない場合、そのメッセージに意味のある変更を加えることは非常に困難です :)

HMAC で使用されるシークレットを PKI 経由で送信する場合、HMAC が PKI システムよりも安全であることは不可能であることに注意してください。結局のところ、PKI を破ると、HMAC シークレットを読み取ることができます。

SSL の帯域幅オーバーヘッドのほとんどは、ハンドシェーク プロセスにあります。SSL 経由で何かを送信する場合、残りの通信を SSL 経由で送信しない理由はほとんどありません。

于 2012-10-16T04:39:50.173 に答える