IPSecベースのVPNを扱うとき、対称鍵交換にわずかな「問題」があることを理解しています。 VPN経由で送信される情報の機密性を保証するために使用されるため、VPN経由でキーを送信することはできません。したがって、ある種の代替ルートを使用する必要があります。
これで、IPSecにはこのためのプロセス、IKEが含まれていることがわかりました。しかし、IKEはVPN内で機能しますか?私はこれについて興味深い記事を見つけましたが、私の現在の質問が答えられるところに達すると、それは突然後戻りし、DES、AES、Blowfish、RC4などのいくつかの一般的なアルゴリズムを想定したままになっているようです。が使用され、暗号化された鍵は平文で送信されるだけです。
これがこの記事です: http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf (セクション2.2)
では、IPSecを使用するVPNでの対称キー転送に関しては、キーはどのように送信されるのでしょうか。
[〜#〜] ike [〜#〜] ウィキペディアのページをチェックアウトすると、対称キーが確立される方法が説明されます。 IKEは2つのフェーズで構成されています。フェーズ1は、キーを送信するための安全なチャネルを確立するIKE-SAをネゴシエートします。キーは、以降の通信を暗号化するために使用されます。フェーズ2では、IPSecによって保護されるトラフィックに使用されるアルゴリズムやキーなどを含むIPSec-SAを確立します。 Wikiページには、IKEがDiffie-Hellman鍵交換を使用して、鍵の導出に使用される共有秘密を作成することが記載されています。これが一部に役立つことを願っています。
対称暗号化の場合、キーは通常事前共有であり、接続がさらに安全でなくなるため、ネットワーク経由で転送されません。また、この接続を確立する前に、安全でないネットワークを介して安全な接続をセットアップするために必要なキーを転送する方法は?それ無理。
また、IKEプロトコルは、新しい接続を確立したり、既存の接続を維持したりするときに常に使用されるため、実際のIPsecワークフローについて、ユーザー側で誤解があるはずです。
[〜#〜] ike [〜#〜] は、2台のマシン間でセッションキーを確立するためのプロトコルです。マシンは、その鍵合意を行うためのアルゴリズムをネゴシエートします。そのためのアルゴリズムには2つのタイプがあります。
事前共有鍵を使用する場合:2つのマシンはすでにで共通の秘密値を共有し、それを拡張します。その元の秘密がどのように共有されたのかは「範囲外」です。前回、事前共有キーを使用してIPsecを構成したとき、SSHセッション内でそのキーを手動で転送していました。
非対称暗号 の魔法で。これは共有secret;を必要としません。しかし、いくつかのルートpublicキーは合意する必要があります。 IKEでは、これは通常 X.509証明書 に依存します。
VPNはIPパケットを転送するためのシステム(保護層内)であるため、IKEを含め、IPパケット上で実行されるあらゆるものと互換性があるはずです。ただし、通常は逆の順序で行われます。IPsecはVPNです。それで、すでにVPNを持っているのなら、なぜIPsecに手を出さないのでしょうか?
実際のキーはフェーズ1のメッセージ3と4の間に交換されると思います。IPSECは、diffie helmanキー交換メカニズムを使用してキーを交換します。事前共有キーに関する限り、メッセージ5と6の間に使用されます。暗号化ではなく、ID確立のため。IDの詳細は、フェーズ1のメッセージ3および4の後に取得された対称鍵を使用して暗号化されます。