HMACクライアントとサーバー間で共有秘密を配布する安全な方法は何ですか？
HMACを使用してhttp通信を保護する方法を探しています。私の理解では、このシナリオではクライアントとサーバーの両方が秘密を知っています。これは、シークレットを最初にクライアント（またはサーバー）で生成する必要があることを意味します。この時点では、片方だけが秘密を持っています。秘密は反対側にどのように渡されますか（または一度渡されない場合、どのようにしてそれを知るようになりますか？）これは一度であっても送信する必要はありませんか？他にどのようにして秘密がクライアントとサーバーの両方に知られるでしょうか？初期化中にそれを送信することが実際に行うことである場合、これを安全に行うにはどうすればよいですか？
これで、電子メールなどの別のチャネルが使用される可能性があることに気付きましたが、ユーザーの関与なしにHMACを自動的に確立する必要がある場合はどうなりますか？
まず、HMACはメッセージの発信者を確認するために使用され、送信者だけが秘密を必要とします。秘密保持には役に立たない。第二に、鍵の交換は難しいことです。サイドチャネルを介してそれを行うことができますが、それが難しいため、ほとんどのブラウザーは、ブラウザーと共にインストールされるルートCA証明書のプレインストールされたリストを使用してそれを行います。これは、ブラウザが特定のサーバーからの情報を信頼することを知っている方法です。
サーバーはクライアントが信頼できる秘密を知っているので、クライアントだけがサーバーが読み取ることができるセッションキーを送信し、その共有秘密を安全な通信に使用することができます。これがSSLの背後にある基礎であり、SSLが通常どおりに使用される理由は、それ以外の場合はすべてのクライアントに対して自分でキーの配布を行う必要があるためです。
編集：CodesInChaosが指摘したように、許可された当事者によるメッセージに対してMACが有効であることを検証するために、あらゆる種類の暗号化を使用できます。パブリック/プライベートである必要はありませんが、この特定のケースでは対称キーを使用するよりもパブリック/プライベートを処理する方が簡単なので、キー交換が問題であるという事実は変わりません。
自分の制約に疑問を投げかける必要があると思います。 HTTPの代わりにHTTP *[〜＃〜] s [〜＃〜]*を使用できた場合、すべてを委任することができます。この面倒でエラーが発生しやすいキー交換プロトコルは、関係するブラウザまたはオペレーティングシステムに送信されます。
実際、これは単なる Diffie-Hellman鍵交換 であり、古い問題に対する新しいソリューションを作成しようとすると、問題が発生します。
HendersonがHMACの設計は認証であると述べたように、実装する方がよい [〜＃〜] pgp [〜＃〜] 。 PGPでは、両方の当事者が秘密鍵を共有する必要はなく、データを暗号化するために相手側の公開鍵を送信するだけです。 HMACは、データの整合性のチェックにも役立ちます。したがって、安全な通信、認証、およびデータの整合性を同時に確保したい場合は、PGPとHMACの両方を組み合わせることができます。