分析IKE / IPSecの[IPSecの] [暗号] IKE / IPSecとTLS認証機構が比較的【のIPSec] [strongSwanの】strongSwanのPKIツールで自己署名証明書を生成しているNATトラバーサルメカニズム【のIPSec]特にハードコア

序文

：記事の続き、最終的にどのような[IPSecの] [暗号]少し異なるデジタル証明書をあります

この部分では、主にコンテンツの延長上に。抽象的には証明書が概念的であるかを理解するためにした後、我々はしようとしています

実用的な観点からは、一例として、2つのIKEv2およびTLSプロトコルに、合意の履行上のデジタル証明書認証に慣れます。

著者：classic_tong、日付：20190914

一 IKE

私は、このような実験環境を構築するためにstrongSwanのを使用しています。両当事者は、道の証明書を使用するように構成されています。

このような理由から、私は自己署名ルート証明書とIKEその証明書の署名当事者のそれぞれです。

参照するには、自己署名証明書の方法を生成します：[IPSecの] [strongSwanの] strongSwanのPKIツールを使用して自己署名証明書を生成します

1.1 strongSwanの設定

証明書を生成した後に良好であり、指定された場所に配置され、次のような構成を用います。

接続{ 
        ネット - ネット{ 
                remote_addrs = 192.168。8.103 
                ローカル{ 
                        AUTH = pubkeyで
                        本命 = t129Cert.pem 
                } 
                遠隔{ 
                        AUTH = pubkeyでの
                        idは = " C = CH、O = T9、CN = t9.tong.localhost " 
                }

ここでは、証明書のサブジェクトであるIDの設定を、見ることができます。（記事の内容に関する状況、ユーザーと名の間のロジックの明確なチェーンの確立を確認）

協議プロセスの1.2分析

まず、を参照特にハードコアIKE / IPSecのNATトラバーサルメカニズム解析[IPSecの] 第一章の、前提IKEの相互作用、継続的なフォローアップの内容を理解してください。

下記を参照してください、私たちが見ることができ、認証プロセスは、第二の相互作用で行われます。池の両側には、自分の名前を送って、自分の名前、およびコンテンツの秘密鍵で暗号化された認証メッセージは（、お互いを認証するために、彼らが通過します

当社の法的の身元を確認するために、証明書を復号化するための公開鍵）

著者： classic_tong、日付：20190914

私たちは、コンテンツの秘密鍵暗号化を使用し、RFCで良いを進めることに合意しました。相手方の内容が明確に復号化のようになりますので、正しいです。最後のパケットの内容について（すなわち、最初の通信パケットを）私たちに送信されます。

ユーザ認証応答概要は、第2の通信データパケットです。

具体的な内容は、以下を参照してくださいhttps://tools.ietf.org/html/rfc7296#section-2.15

1.3事前共有キー認証

ちなみに、秘密鍵認証方式事前共有。基本的な原理は同じです。しかし、事前共有秘密鍵の情報を付加する認証メッセージの計算、インチこれは、非共有キーの人々は、我々が計算され

デジタル署名認証データセグメント。：RFCを参照してくださいhttps://tools.ietf.org/html/rfc7296#section-2.15を

また、ID情報の通信データは、スクリーンショットを参照して、わずかに異なっています。

著者： classic_tong、日付：20190914

二つのTLS

TLS認証は少し複雑です。一つが言ったように、SAN URLとの証明書を関連付けることにより、名前の部分であるという名前を付けましょう。ブラウザに入力されたドメイン名は、証明書にSANフィールドに存在している必要があります。

論理チェーンを検証するユーザーの名前順。それから彼は、次のセクションを言うようになりました。相互作用図のシグナリングTLS初めて目：

私たちは、クライアントを検証する場合、クライアント証明書が送信され、証明書をサーバーを参照し、検証のためにサーバーにデータを検証し、私たちは、サーバが認証を行うために設計された送信し表示されていないことができます

メッセージセグメント。その理由は、これは、TLS認証メカニズムは、との相互作用のキーとの完全なメカニズムに含まれています。

参考：https://security.stackexchange.com/questions/139176/details-of-tls-certificate-verification

https://tools.ietf.org/html/rfc5246#section-7.4.9

2例を議論する協議とDH鍵の協議のRSAキーポイント。（私たちはこの問題について考えるようにアプリケーションを閲覧する一般的なHTTPSに立っているので、ここでは検証サーバを議論する唯一の単一のクライアントがあります）

1. RSAキーのネゴシエーションを使用する場合、クライアントは秘密鍵共有を行うために、サーバーに独自のコンテンツのセットを暗号化する公開鍵を使用しています。サーバーは、プライベートではない場合。矛盾している協議は、最後のクライアントが送信します

過去の仕上げ（11）メッセージが正しく復号されることはありません、サーバが正しい復号化を終了させることができる（13）を偽装できなかったメッセージを送り返します。

RSA鍵交換では、クライアントは、バイトのランダムシーケンスを生成し、RSA暗号化を行って使用して、公開鍵からサーバー" の証明書を。その後、クライアントは、サーバに、得られた暗号文を送信し、サーバがそれを解読することを期待（証明書から公開鍵に対応する秘密鍵を使用して）と対称鍵を生成するために、一緒に他の値と、KDFにランダムな値を使用しその結果、対称鍵で暗号化されたFinishedメッセージを送信します。クライアントは、Finishedメッセージを確認します。サーバーは、唯一の復号化RSA暗号化されたメッセージによって期待される対称鍵の生成に成功することができます。https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

コードの表示

2. DH、デジタル署名からなる秘密鍵（4）を使用してサーバ・メッセージを使用して、クライアントは公開鍵で検証することができます。

PFSとDHE / ECDHE鍵交換では、サーバーは、その短期キーに署名使ってプライベートに対応する鍵、公開鍵で証明書を送信して、これを して ServerKeyExchange。クライアントは、署名を検証し使用して、公開鍵から証明書を。HTTPS：// tools.ietf.org/html/rfc5246#appendix-F.1.1.3

コードの表示

著者： classic_tong、日付：20190914