(57)【要約】【課題】ＮＡＴやファイアウォールといった通信機器を経由したピアツーピア通信の中継を行う機器を介した通信路上で，通信当事者間の暗号化通信を実現する。【解決手段】ＮＡＴやファイアウォールといった通信機器を経由したピアツーピア通信を終端するプログラム上でＳＳＬ／ＴＬＳによるセッションを確立することで，中継を行う機器による通信内容の解読を防止する。【選択図】図１
2019062512.tif 000002
【特許請求の範囲】
【請求項１】
ＯＳＩ参照モデルのトランスポート層以上の通信層においてピアツーピア通信を中継する機器が存在する通信路上で，通信を終端する当事者間でＳＳＬ／ＴＬＳセッションを確立することで通信内容を暗号化し，通信を中継する機器による通信内容の解読を防止する通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】本発明は，ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）が策定するＯＳＩ参照モデル（非特許文献１参照）のトランスポート層以上の階層で中継を行う機器を経由した通信において，通信の当事者間で暗号化通信を行い，中継を行う機器における通信内容の解読を防止するものである。
【背景技術】
【０００２】家庭のＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）環境や，各種事業所のＬＡＮ環境でインターネット通信を行う場合，ルータが持つＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）機能（非特許文献２参照）により，ＩＰアドレスやポート番号が変換され通信が行われる。【０００３】また各種事業所のＬＡＮ環境からインターネット通信を行う場合，ファイアウォール機器により，通信可能な通信種別が制限されている環境が多い。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】“Ｔｈｅ  Ｂａｓｉｃ  Ｒｅｆｅｒｅｎｃｅ  Ｍｏｄｅｌ  ｏｆ  Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ（ＯＳＩ）”，ＩＳＯ／ＩＥＣ  ７  ４９８、１９８９年
【非特許文献２】Ｐ．Ｓｒｉｓｕｒｅｓｈ、Ｍ．Ｈｏｌｄｒｅｇｅ、Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ、“ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ  ａｎｄ  Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ”、ＲＦＣ２６６３、［ｏｎｌｉｎｅ］、１９９９年８月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２６６３〉
【発明の開示】
【発明が解決しようとする課題】
【０００５】このようなインターネット通信環境において，ピアツーピア通信を行う当事者はＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ；非特許文献３参照），あるいはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ；非特許文献４参照）等，ＯＳＩ参照モデルのトランスポート層に位置する通信プロトコルを用いて，リレーサーバ，あるいはリレーエージェント等と名付けられた通信の中継を行う機器に対する通信路を確立し，中継を行う機器を介した形で通信を行うことがある。【０００６】一方，通信当事者間での暗号化通信を実現するための暗号通信プロトコルとして広く普及しているＳＳＬ／ＴＬＳ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ；非特許文献５、非特許文献６、非特許文献７参照）では，ＯＳＩ参照モデルのトランスポート層において通信を終端するプログラム間での暗号化通信を行う。【０００７】中継を行う機器を介したピアツーピア通信を行う場合，通信当事者であるプログラムは，中継を行う機器上の中継プログラムとの間でトランスポート層の論理的な通信セッションを確立する。この通信においてＳＳＬ／ＴＬＳを使用する場合，通信内容の暗号化は，通信当事者であるプログラムと中継を行う機器上の中継プログラムとの間で行われる。【０００８】すると，中継を行う機器上の中継プログラムが通信内容を復号し，内容を解読することができる。このため通信の当事者は通信の中継経路を運用する者に，通信内容を解読され得るという潜在的な脅威を持つことになる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献３】Ｄｅｆｅｎｓｅ  Ａｄｖａｎｃｅｄ  Ｒｅｓｅａｒｃｈ  Ｐｒｏｊｅｃｔｓ  Ａｇｅｎｃｙ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｔｅｃｈｎｉｑｕｅｓ  Ｏｆｆｉｃｅ、“Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ”、ＲＦＣ７９３、［ｏｎｌｉｎｅ］、１９８１年９月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７９３〉
【非特許文献４】Ｊ．Ｐｏｓｔｅｌ、“Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ”、ＲＦＣ７６８、［ｏｎｌｉｎｅ］、１９８０年８月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７６８〉
【非特許文献５】Ｔ．Ｄｉｅｒｋｓ、Ｃ．Ａｌｌｅｎ、“Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．０”、ＲＦＣ２２４６、［ｏｎｌｉｎｅ］、１９９９年１月、［平成２９年９月２７日検索］、インターネットｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２２４６
【非特許文献６】Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、“Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．１”、ＲＦＣ４３４６、［ｏｎｌｉｎｅ］、２００６年４月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４３４６〉
【非特許文献７】Ｔ．Ｄｉｅｒｋｓ、Ｅ．Ｒｅｓｃｏｒｌａ、“Ｔｈｅ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．２”、ＲＦＣ５２４６、［ｏｎｌｉｎｅ］、２００８年８月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５２４６〉
【課題を解決するための手段】
【００１０】本発明は、図１に示すとおり、Ｐ２Ｐ  Ｅ２ＥＥクライアントとＰ２Ｐ  Ｅ２ＥＥエージェント，並びにリレーサーバより構成される。
【００１１】通信に先立ち，まずリレーサーバが特定のＴＣＰポートにおいて待受けを行う。
【００１２】Ｐ２Ｐ  Ｅ２ＥＥクライアント，およびＰ２Ｐ  Ｅ２ＥＥエージェントはリレーサーバに対して，自身の識別子を提示し，ＴＣＰコネクション，あるいはＷｅｂＳｏｃｋｅｔを用いた論理的なセッションを確立し，任意のタイミングで片方向，あるいは双方向の通信ができる状態にする。
【００１３】Ｐ２Ｐ  Ｅ２ＥＥクライアントは，コンピュータ１内のＴＣＰポート上で，外部プログラムからの待受けを行っており，ＴＣＰサーバとして振る舞う。
【００１４】Ｐ２Ｐ  Ｅ２ＥＥクライアントが外部プログラムからＴＣＰコネクションの確立を受けると，Ｐ２Ｐ  Ｅ２ＥＥクライアントは，リレーサーバを通じて，Ｐ２Ｐ  Ｅ２ＥＥエージェントに対する擬似的なＴＣＰコネクションを確立する。
【００１５】Ｐ２Ｐ  Ｅ２ＥＥエージェントは，コンピュータ２内で，ＴＣＰクライアントとしても振る舞い，擬似的なＴＣＰコネクションの確立時に外部サーバへのＴＣＰコネクションを確立する。この外部サーバのＩＰアドレスあるいはホスト名とＴＣＰのポート番号は，予めＰ２Ｐ  Ｅ２ＥＥエージェントが設定値として保持しているか，リレーサーバより擬似的なＴＣＰコネクションの確立時に指定されるものとする。なお，図１では外部サーバがＰ２Ｐ  Ｅ２ＥＥエージェントと同じコンピュータ上に位置しているが，別のコンピュータ上にあっても良い。
【００１６】Ｐ２Ｐ  Ｅ２ＥＥクライアントとＰ２Ｐ  Ｅ２ＥＥエージェント間で擬似ＴＣＰコネクションが確立された後，Ｐ２Ｐ  Ｅ２ＥＥクライアントとＰ２Ｐ  Ｅ２ＥＥエージェントの間では，この擬似ＴＣＰコネクション上でＳＳＬ／ＴＬＳのセッションが確立される。
【００１７】［００１４］から［００１５］で記述された擬似ＴＣＰコネクションの確立に際し，Ｐ２Ｐ  Ｅ２ＥＥクライアントはリレーサーバに通信相手であるＰ２Ｐ  Ｅ２ＥＥエージェントを識別するための識別子を添えて，擬似ＴＣＰコネクションの確立を要求する。また，Ｐ２Ｐ  Ｅ２ＥＥエージェントがリレーサーバから擬似ＴＣＰコネクションの確立を要求される場合には，当該擬似ＴＣＰコネクションの確立を要求しているＰ２Ｐ  Ｅ２ＥＥクライアントの識別子が添えられる。  ＴＣＰコネクションの確立後ＳＳＬ／ＴＬＳのセッション開始にあたって，Ｐ２Ｐ  Ｅ２ＥＥクライアントとＰ２Ｐ  Ｅ２ＥＥエージェントの間ではＳＳＬ／ＴＬＳのハンドシェークが行われるが，その時に交換されるＸ．５０９形式の公開鍵証明書によりお互いの正当性を相互に確認する。この時公開鍵証明書には共通名（Ｃｏｍｍｏｎ  Ｎａｍｅ）フィールドが備わっているが，Ｐ２Ｐ  Ｅ２ＥＥクライアント，あるいはＰ２Ｐ  Ｅ２ＥＥエージェントの識別子を共通名として備えた公開鍵証明書を使用する。
【００１８】以上の様に，擬似的なＴＣＰコネクションを確立し，その上でＳＳＬ／ＴＬＳセッションを確立することで，Ｐ２Ｐ  Ｅ２ＥＥクライアントとＰ２Ｐ  Ｅ２ＥＥエージェントの間には，中継する機器であるリレーサーバによる通信内容の読取りが困難な論理的通信路が確立される。
【発明の効果】
【００１９】利用者は、ＮＡＰＴやファイアウォール機器が介在する環境等，直接のピアツーピア通信が困難な環境においてピアツーピア通信を行う場合でも，中継路上の各種中継機器による通信内容の読取りの可能性を排除し，安全な通信を行う事ができる。
【発明を実施するための最良の形態】
【００２０】本件発明の具体的な実装の一例では、図２に示すように，Ｐ２Ｐ  Ｅ２ＥＥクライアントからリレーサーバ，およびＰ２Ｐ  Ｅ２ＥＥエージェントからリレーサーバに対して論理的通信路を確立するために，ＲＦＣ６４５５として定義されているＷｅｂＳｏｃｋｅｔプロトコル（非特許文献８参照）を使用する。【００２１】ＷｅｂＳｏｃｋｅｔはＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ；非特許文献９参照）、あるいは一般的にＨＴＴＰＳと呼ばれる（ＨＴＴＰ  ｏｖｅｒ  ＴＬＳ；非特許文献１０参照）を利用する通信プロトコルであるが，Ｐ２Ｐ  Ｅ２ＥＥクライアントからリレーサーバ，およびＰ２Ｐ  Ｅ２ＥＥエージェントからリレーサーバに対する通信内容も第三者による盗聴，改ざんから防御する必要があることから，Ｐ２Ｐ  Ｅ２ＥＥクライアントからリレーサーバ，およびＰ２Ｐ  Ｅ２ＥＥエージェントからリレーサーバに向かって確立されるＷｅｂＳｏｃｋｅｔ通信ではＨＴＴＰＳを利用する。【００２２】Ｐ２Ｐ  Ｅ２ＥＥクライアントからリレーサーバ，およびＰ２Ｐ  Ｅ２ＥＥエージェントからリレーサーバに対するＷｅｂＳｏｃｋｅｔを用いた論理的通信路が確立された後，Ｐ２Ｐ  Ｅ２ＥＥクライアント，およびＰ２Ｐ  Ｅ２ＥＥエージェントは，それぞれ４．リレーサーバに対して認証手続きを行うことで，各Ｐ２Ｐ  Ｅ２ＥＥクライアント，およびＰ２Ｐ  Ｅ２ＥＥエージェントの識別を，リレーサーバが行えるようにする。【００２３】図２において，Ｐ２Ｐ  Ｅ２ＥＥクライアント上の２．ＴＣＰサーバ兼ＴＬＳクライアントに対して１．外部プログラムからＴＣＰコネクションが確立されると，２．ＴＣＰサーバ兼ＴＬＳクライアントは同じくＰ２Ｐ  Ｅ２ＥＥクライアント内の３．ＴＣＰサーバ兼ＷｅｂＳｏｃｋｅｔクライアントに対してＴＣＰコネクションを確立する。【００２４】ＴＣＰコネクションが確立された３．ＴＣＰサーバ兼ＷｅｂＳｏｃｋｅｔクライアントは，リレーサーバ内の４．ＷｅｂＳｏｃｋｅｔサーバに対してＰ２Ｐ  Ｅ２ＥＥエージェント内の５．Ｗｅｂソケットクライアント兼ＴＣＰクライアントに対する擬似ＴＣＰコネクション確立要求を送信する。【００２５】３．ＴＣＰサーバ兼ＷｅｂＳｏｃｋｅｔクライアントから５．Ｗｅｂソケットクライアント兼ＴＣＰクライアントに対する擬似ＴＣＰコネクション確立要求を受信した４．ＷｅｂＳｏｃｋｅｔサーバは，５．Ｗｅｂソケットクライアント兼ＴＣＰクライアントに対してＴＣＰコネクション確立要求を送信する。【００２６】４．ＷｅｂＳｏｃｋｅｔサーバから擬似ＴＣＰコネクション確立要求を受信したＰ２Ｐ  Ｅ２ＥＥエージェント内の５．Ｗｅｂソケットクライアント兼ＴＣＰクライアントは，４．ＷｅｂＳｏｃｋｅｔサーバに対し擬似ＴＣＰコネクション確立成功の回答を返信する。【００２７】４．ＷｅｂＳｏｃｋｅｔサーバは５．Ｗｅｂソケットクライアント兼ＴＣＰクライアントから擬似ＴＣＰコネクション確立成功の回答を受信したのち，３．ＴＣＰサーバ兼ＷｅｂＳｏｃｋｅｔクライアントに対して擬似ＴＣＰコネクション確立成功の回答を返信する。【００２８】擬似ＴＣＰコネクションの確立成功後，２．ＴＣＰサーバ兼ＴＬＳクライアント��，擬似ＴＣＰ通信路上でＳＳＬ／ＴＬＳ通信の開始時に行われるハンドシェークを６．ＴＬＳサーバ兼ＴＣＰクライアントに対して行う。これによって２．ＴＣＰサーバ兼ＴＬＳクライアントと６．ＴＬＳサーバ兼ＴＣＰクライアントは通信相手の認証と暗号化通信に使用する暗号化アルゴリズムのネゴシエーションを一般的なＳＳＬ／ＴＬＳ通信のしくみに準じて行うことができる。【００２９】ＳＳＬ／ＴＬＳ通信のセッションが２．ＴＣＰサーバ兼ＴＬＳクライアントと６．ＴＬＳサーバ兼ＴＣＰクライアントの間で確立されると，６．ＴＬＳサーバ兼ＴＣＰクライアントは，７．外部サーバに対してＴＣＰコネクションを確立する。【００３０】［００２３］から［００２９］で記述された通信手順を図３として示す。【００３１】上記の手順を終えると，１．外部プログラムから２．ＴＣＰサーバ兼ＴＬＳクライアントに対してＴＣＰコネクションを通じて送信されたデータの内容は，透過的に６．ＴＬＳサーバ兼ＴＣＰクライアントから７．外部サーバに転送される。また，これとは反対に７．外部サーバから６．ＴＬＳサーバ兼ＴＣＰクライアントに対してＴＣＰコネクションを通じて送信されたデータの内容は，透過的に２．ＴＣＰサーバ兼ＴＬＳクライアントから１．外部プログラムに転送される。しかしながら，ＳＳＬ／ＴＬＳセッションは２．ＴＣＰサーバ兼ＴＬＳクライアントと６．ＴＬＳサーバ兼ＴＣＰクライアントの間で確立されているため，４．ＷｅｂＳｏｃｋｅｔサーバは，その通信内容を解読することができない。
【非特許文献】
【００３２】
【非特許文献８】Ｉ．Ｆｅｔｔｅ、Ｇｏｏｇｌｅ  Ｉｎｃ．Ａ．Ｍｅｌｎｉｋｏｖ、Ｉｓｏｄｅ  Ｌｔｄ．、“Ｔｈｅ  ＷｅｂＳｏｃｋｅｔ  Ｐｒｏｔｏｃｏｌ”、ＲＦＣ６４５５、［ｏｎｌｉｎｅ］、２０１１年１２月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６４５５〉
【非特許文献９】ＵＣ  Ｉｒｖｉｎｅ、Ｊ．Ｇｅｔｔｙｓ、Ｃｏｍｐａｑ／Ｗ３Ｃ、Ｊ．Ｍｏｇｕｌ、Ｃｏｍｐａｑ、Ｈ．Ｆｒｙｓｔｙｋ、Ｗ３Ｃ／ＭＩＴ、Ｌ．Ｍａｓｉｎｔｅｒ、Ｘｅｒｏｘ、Ｐ．Ｌｅａｃｈ、Ｍｉｃｒｏｓｏｆｔ、Ｔ．Ｂｅｒｎｅｒｓ−Ｌｅｅ、Ｗ３Ｃ／ＭＩＴ、“Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ”、ＲＦＣ２６１６、［ｏｎｌｉｎｅ］、１９９９年６月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２６１６〉
【非特許文献１０】Ｅ．Ｒｅｓｃｏｒｌａ、ＲＴＦＭ，Ｉｎｃ．、“ＨＴＴＰ  ｏｖｅｒ  ＴＬＳ”、ＲＦＣ２８１８、［ｏｎｌｉｎｅ］、２０００年５月、［平成２９年９月２７日検索］、インターネット〈ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２８１８〉
【産業上の利用可能性】
【００３３】本発明により、既存の通信プロトコルを利用しつつ，ピアツーピア通信における通信当事者間での暗号化通信を可能になり，利用者が通信路を運用する事業者による通信内容の傍受の心配なしにピアツーピア通信を行う事に貢献できる。【００３４】本発明では、暗号化通信の要点である通信相手の認証，並びに使用する暗号化アルゴリズムの決定手順として既存のＳＳＬ／ＴＬＳプロトコルおよびＸ．５０９として標準化された公開鍵証明書のしくみを利用することで，既存の認証機構，暗号化通信機構と同等のセキュリティレベルを利用者に提供することができる。
【図面の簡単な説明】
【００３５】
【図１】本発明を実現するための構成要素
【図２】本発明を実現するための最良の形態を構成する要素
【図３】本発明を実現するための最良の形態における通信手順
【図１】
2019062512.tif 000003
【図２】
2019062512.tif 000004
【図３】
2019062512.tif 000005