特開 2023-64550 通信システム、通信方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023064550

(43)【公開日】2023-05-11

(54)【発明の名称】通信システム、通信方法及びプログラム

(51)【国際特許分類】

   H04L 9/12 20060101AFI20230501BHJP

   H04L 9/32 20060101ALI20230501BHJP

【ＦＩ】

H04L9/12

H04L9/32 200B

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2021174893

(22)【出願日】2021-10-26

(71)【出願人】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】奥田 哲矢

(72)【発明者】

【氏名】中林 美郷

(72)【発明者】

【氏名】前田 志温

(57)【要約】

【課題】ＱＫＤ又はＰＱＫＤにより鍵交換を行う機器の署名鍵が漏洩した場合であっても合意要件を保証すること。
【解決手段】一実施形態に係る通信システムは、暗号化プロトコルを実行する２以上の第１の機器と鍵交換プロトコルを実行する２以上の第２の機器とが含まれる通信システムであって、前記第２の機器は、他の第２の機器との間で前記鍵交換プロトコルにより共通鍵を生成する鍵交換部と、自身と同一拠点内のネットワークに接続されている前記第１の機器に対して、前記共通鍵を配送する鍵配送部と、を有し、前記第１の機器は、前記共通鍵による共通鍵暗号方式とデジタル証明書による認証付き電子署名とを用いて、他の第１の機器との間でデータ通信を行う通信部、を有する。
【選択図】図１

【特許請求の範囲】

【請求項1】

暗号化プロトコルを実行する２以上の第１の機器と鍵交換プロトコルを実行する２以上の第２の機器とが含まれる通信システムであって、
前記第２の機器は、
他の第２の機器との間で前記鍵交換プロトコルにより共通鍵を生成する鍵交換部と、
自身と同一拠点内のネットワークに接続されている前記第１の機器に対して、前記共通鍵を配送する鍵配送部と、を有し、
前記第１の機器は、
前記共通鍵による共通鍵暗号方式とデジタル証明書による認証付き電子署名とを用いて、他の第１の機器との間でデータ通信を行う通信部、を有する通信システム。

【請求項2】

前記鍵交換プロトコルは署名付きの耐量子鍵交換であり、
前記鍵配送部は、
自身と同一拠点内のネットワークに接続されている前記第１の機器との間で予め共有された事前共有鍵を用いて前記共通鍵を配送する、又は、自身と同一拠点内のネットワークに接続されている前記第１の機器との間で署名付きＤＨ鍵配送を行うことで前記共通鍵を配送する、請求項１に記載の通信システム。

【請求項3】

前記鍵交換プロトコルは量子鍵配送であり、
前記第２の機器間はセキュアなネットワークにより通信可能に接続されており、
前記鍵配送部は、
自身と同一拠点内のネットワークに接続されている前記第１の機器との間で署名付きＤＨ鍵配送を行うことで前記共通鍵を配送する、請求項１に記載の通信システム。

【請求項4】

前記通信部は、
前記共通鍵による共通鍵暗号方式とデジタル証明書による認証付き電子署名とを用いて、光トランスポートネットワークにより前記他の第１の機器との間でデータ通信を行う、請求項１乃至３の何れか一項に記載の通信システム。

【請求項5】

暗号化プロトコルを実行する２以上の第１の機器と鍵交換プロトコルを実行する２以上の第２の機器とが含まれる通信システムに用いられる通信方法であって、
前記第２の機器が、
他の第２の機器との間で前記鍵交換プロトコルにより共通鍵を生成する鍵交換手順と、
自身と同一拠点内のネットワークに接続されている前記第１の機器に対して、前記共通鍵を配送する鍵配送手順と、を実行し、
前記第１の機器が、
前記共通鍵による共通鍵暗号方式とデジタル証明書による認証付き電子署名とを用いて、他の第１の機器との間でデータ通信を行う通信手順、を実行する通信方法。

【請求項6】

請求項１乃至４の何れか一項に記載の通信システムに含まれる第１の機器又は第２の機器としてコンピュータを機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信システム、通信方法及びプログラムに関する。

【背景技術】

【0002】

量子計算機が実現した場合でも安全なデータ通信を行うため、量子鍵配送（ＱＫＤ：Quantum Key Distribution）や耐量子鍵交換（ＰＱＫＤ：Post-Quantum Key Exchange）により生成した鍵でデータを暗号化するセキュア光トランスポートネットワーク（ＳＯＴＮ：Secure Optical Transport Network）が検討されている。ＳＯＴＮではＱＫＤ又はＰＱＫＤによる鍵交換とデータ通信とが別々の機器で行われるため、例えば、２拠点間のデータ通信は４者間ネットワークで実現される。以下、ＱＫＤとＰＱＫＤをまとめて「ＸＫＤ」と呼び、ＱＫＤ又はＰＱＫＤにより鍵交換を行う機器を「ＸＫＤ装置」と呼ぶことにする。また、ＸＫＤ装置の鍵交換により生成された鍵を用いてセキュアなデータ通信を行う機器を「通信装置」と呼ぶことにする。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】RFC 2409「IKE： インターネット鍵交換」，インターネット＜ＵＲＬ：https://datatracker.ietf.org/doc/html/rfc2409＞

【非特許文献2】RFC 7296「インターネットキー交換プロトコルバージョン2（IKEv2）」，インターネット＜ＵＲＬ：https://datatracker.ietf.org/doc/html/rfc7296＞

【非特許文献3】RFC 4301「インターネットプロトコルのためのセキュリティアーキテクチャ」，インターネット＜ＵＲＬ：https://datatracker.ietf.org/doc/html/rfc4301＞

【発明の概要】

【発明が解決しようとする課題】

【0004】

ここで、ＸＫＤ装置は他のＸＫＤ装置と鍵交換を行う場合、互いの認証のために電子署名が用いられることが一般的である。しかしながら、ＸＫＤ装置から署名鍵が漏洩した場合、通信装置間の合意要件（Agreement property）が保証されなくなるという問題がある。

【0005】

本発明の一実施形態は、上記の点に鑑みてなされたもので、ＱＫＤ又はＰＱＫＤにより鍵交換を行う機器の署名鍵が漏洩した場合であっても合意要件を保証することを目的とする。

【課題を解決するための手段】

【0006】

上記目的を達成するため、一実施形態に係る通信システムは、暗号化プロトコルを実行する２以上の第１の機器と鍵交換プロトコルを実行する２以上の第２の機器とが含まれる通信システムであって、前記第２の機器は、他の第２の機器との間で前記鍵交換プロトコルにより共通鍵を生成する鍵交換部と、自身と同一拠点内のネットワークに接続されている前記第１の機器に対して、前記共通鍵を配送する鍵配送部と、を有し、前記第１の機器は、前記共通鍵による共通鍵暗号方式とデジタル証明書による認証付き電子署名とを用いて、他の第１の機器との間でデータ通信を行う通信部、を有する。

【発明の効果】

【0007】

ＱＫＤ又はＰＱＫＤにより鍵交換を行う機器の署名鍵が漏洩した場合であっても合意要件を保証するができる。

【図面の簡単な説明】

【0008】

【図1】本実施形態に係る通信システムの全体構成の一例を示す図である。

【図2】本実施形態に係る通信装置のハードウェア構成の一例を示す図である。

【図3】本実施形態に係るＸＫＤ装置のハードウェア構成の一例を示す図である。

【図4】本実施形態に係る通信装置及びＸＫＤ装置の機能構成の一例を示す図である。

【図5】合意要件の一例を説明するための図である。

【図6】ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に事前共有鍵を用いた場合の一例を説明するための図である。

【図7】Ｆａｌｓｅ２に該当する攻撃例を説明するための図である。

【図8】ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に事前共有鍵を用いると共に、共通鍵メッセージ送受信に署名による認証を加えた場合の一例を説明するための図である。

【図9】ＩＫＥ間の鍵交換にＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に事前共有鍵を用いた場合の一例を説明するための図である。

【図10】ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に署名付きＤＨ鍵配送を用いた場合の一例を説明するための図である。

【図11】Ｆａｌｓｅ３－２に該当する攻撃例を説明するための図である。

【図12】ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に署名付きＤＨ鍵配送を用いると共に、共通鍵メッセージ送受信に署名による認証を加えた場合の一例を説明するための図である。

【図13】ＩＫＥ間の鍵交換にＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に署名付きＤＨ鍵配送を用いた場合の一例を説明するための図である。

【図14】ＩＫＥ間の鍵交換にＱＫＤ、ＩＫＥからＥＳＰへの鍵配送に署名付きＤＨ鍵配送を用いると共に、共通鍵メッセージ送受信に署名による認証を加えた場合の一例を説明するための図である。

【発明を実施するための形態】

【0009】

以下、本発明の一実施形態について説明する。本実施形態では、ＱＫＤ又はＰＱＫＤにより鍵交換を行うＸＫＤ装置の署名鍵が漏洩した場合であっても、通信装置間の合意要件が保証される通信システム１について説明する。

【0010】

＜通信システム１の全体構成例＞
本実施形態に係る通信システム１は、物理的に離れた拠点間で大容量かつ低遅延にセキュアなデータ通信を行うことが可能なＳＯＴＮを実現する通信システムである。各拠点のシステム環境である拠点環境Ｅには、１以上の通信装置１０と、ＸＫＤ装置２０と、当該拠点環境Ｅ内の通信ネットワークである拠点内ＮＷ３０とが含まれる。また、異なる拠点環境Ｅ間は、異なる拠点環境Ｅの通信装置１０間の通信に用いられる通信ネットワークである拠点間ＮＷ４０と、異なる拠点環境ＥのＸＫＤ装置２０間の通信に用いられる通信ネットワークである拠点間ＮＷ５０とで接続される。

【0011】

例えば、図１に示すように、本実施形態に係る通信システム１は、拠点Ａの拠点環境Ｅ_Ａと、拠点Ｂの拠点環境Ｅ_Ｂとが含まれる。また、拠点環境Ｅ_Ａには、通信装置１０Ａと、ＸＫＤ装置２０Ａと、拠点内ＮＷ３０Ａとが含まれる。同様に、拠点環境Ｅ_Ｂには、通信装置１０Ｂと、ＸＫＤ装置２０Ｂと、拠点内ＮＷ３０Ｂとが含まれる。なお、図１に示す例では、拠点ｘの拠点環境Ｅを「拠点環境Ｅ_ｘ」、通信装置１０を「通信装置１０ｘ」、ＸＫＤ装置２０を「ＸＫＤ装置２０ｘ」、拠点内ＮＷ３０を「拠点内ＮＷ３０ｘ」とそれぞれ表記している。

【0012】

通信装置１０は、ＷＢＳ（White Box Switch）等の機器であり、拠点間ＮＷ４０を介して、他拠点の通信装置１０との間でセキュアなデータ通信を行う。より具体的には、通信装置１０は、ＥＳＰ（Encapsulated Security Payload）と呼ばれるプロトコルによりデータの暗号化を行った上で、拠点間ＮＷ４０を介して、他拠点の通信装置１０との間でセキュアなデータ通信を行う。このとき、通信装置１０は、自拠点のＸＫＤ装置２０から配送された鍵Ｋ（共通鍵Ｋ）を用いて、ＥＳＰによりデータの暗号化を行う。ここで、拠点間ＮＷ４０としては光トランスポートネットワーク（ＯＴＮ： Optical Transport Network）を想定するが、これに限られるものではない。

【0013】

ＸＫＤ装置２０は、拠点間ＮＷ５０を介して、ＱＫＤ又はＰＱＫＤと呼ばれるプロトコル（ＩＫＥ（Internet Key Exchange）プロトコルの一種）により他拠点のＸＫＤ装置２０との間で鍵交換を行って鍵Ｋを生成する機器である。ＸＫＤ装置２０は、拠点内ＮＷ３０を介して、当該鍵Ｋを自拠点の通信装置１０に配送する。なお、ＱＫＤにより鍵交換を行うことを明示するときはＸＫＤ装置２０を「ＱＫＤ装置２０」とも表記し、同様にＰＱＫＤにより鍵交換を行うことを明示するときはＸＫＤ装置２０を「ＰＱＫＤ装置２０」とも表記する。ここで、拠点内ＮＷ３０としてはＬＡＮ（Local Area Network）等を想定するが、これに限られるものではない。また、拠点間ＮＷ５０としては、ＸＫＤ装置２０がＱＫＤにより鍵交換を行う場合は光ファイバ専用線、ＸＫＤ装置２０がＰＱＫＤにより鍵交換を行う場合はインターネット又はＷＡＮ（Wide Area Network）を想定するが、これらに限られるものではない。

【0014】

このように、ＩＰｓｅｃ（Security Architecture for Internet Protocol）ではＩＫＥとＥＳＰとが同一機器で実行されるが、通信システム１によりＳＯＴＮを実現する際にはＩＫＥとＥＳＰとがそれぞれ別の機器で実行される（つまり、ＩＫＥがＸＫＤ装置２０、ＥＳＰが通信装置１０で実行される。）。

【0015】

なお、図１に示す通信システム１の全体構成は一例であって、これに限られるものではない。例えば、通信システム１には３つ以上の拠点環境Ｅが含まれていてもよいし、１つの拠点環境Ｅ内に複数の通信装置１０が含まれていてもよい。また、通信装置１０が含まれない拠点環境Ｅが存在してもよい。すなわち、本実施形態に係る通信システム１は少なくとも２以上の通信装置１０と少なくとも２以上のＸＫＤ装置２０とが含まれる４者間以上の通信に適用することが可能である。

【0016】

＜通信装置１０のハードウェア構成例＞
本実施形態に係る通信装置１０のハードウェア構成例を図２に示す。図２に示すように、本実施形態に係る通信装置１０は、外部Ｉ／Ｆ１１と、通信Ｉ／Ｆ１２と、プロセッサ１３と、メモリ装置１４とを有する。また、これらの各ハードウェアは、バス１５を介して通信可能に接続される。

【0017】

外部Ｉ／Ｆ１１は、記録媒体１１ａ等の外部装置とのインタフェースである。なお、記録媒体１１ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。

【0018】

通信Ｉ／Ｆ１２は、自拠点の拠点内ＮＷ３０及び拠点間ＮＷ４０に接続するためのインタフェースである。なお、通信装置１０は、自拠点の拠点内ＮＷ３０に接続するための通信Ｉ／Ｆ１２と拠点間ＮＷ４０に接続するための通信Ｉ／Ｆ１２の２つのインタフェースを有していてもよい。

【0019】

プロセッサ１３は、例えば、ＣＰＵ（Central Processing Unit）やＡＳＩＣ（application specific integrated circuit）等の各種演算装置である。メモリ装置１４は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の各種記憶装置である。

【0020】

なお、図２に示すハードウェア構成は一例であって、通信装置１０のハードウェア構成はこれに限られるものではない。例えば、通信装置１０は、図示しない種々のハードウェア（例えば、表示パネル等の表示装置、物理ボタンやタッチパネル等の入力装置等）を備えていてもよい。

【0021】

＜ＸＫＤ装置２０のハードウェア構成例＞
本実施形態に係るＸＫＤ装置２０のハードウェア構成例を図３に示す。図３に示すように、本実施形態に係るＸＫＤ装置２０は、外部Ｉ／Ｆ２１と、通信Ｉ／Ｆ２２と、プロセッサ２３と、メモリ装置２４とを有する。また、これらの各ハードウェアは、バス２５を介して通信可能に接続される。

【0022】

外部Ｉ／Ｆ２１は、記録媒体２１ａ等の外部装置とのインタフェースである。なお、記録媒体２１ａとしては、例えば、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリカード等が挙げられる。

【0023】

通信Ｉ／Ｆ２２は、自拠点の拠点内ＮＷ３０及び拠点間ＮＷ５０に接続するためのインタフェースである。なお、ＸＫＤ装置２０は、自拠点の拠点内ＮＷ３０に接続するための通信Ｉ／Ｆ２２と拠点間ＮＷ５０に接続するための通信Ｉ／Ｆ２２の２つのインタフェースを有していてもよい。

【0024】

プロセッサ２３は、例えば、ＣＰＵやＡＳＩＣ等の各種演算装置である。メモリ装置２４は、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＲＡＭ、ＲＯＭ等の各種記憶装置である。

【0025】

なお、図３に示すハードウェア構成は一例であって、ＸＫＤ装置２０のハードウェア構成はこれに限られるものではない。例えば、ＸＫＤ装置２０は、図示しない種々のハードウェア（例えば、表示パネル等の表示装置、物理ボタンやタッチパネル等の入力装置等）を備えていてもよい。

【0026】

＜通信装置１０及びＸＫＤ装置２０の機能構成＞
本実施形態に係る通信装置１０及びＸＫＤ装置２０の機能構成例を図４に示す。

【0027】

≪通信装置１０≫
図４に示すように、本実施形態に係る通信装置１０は、セキュア通信部１０１と、鍵取得部１０２と、記憶部１０３とを有する。セキュア通信部１０１及び鍵取得部１０２は、例えば、通信装置１０にインストールされた１以上のプログラムが、プロセッサ１３に実行させる処理により実現される。また、記憶部１０３は、例えば、メモリ装置１４により実現される。

【0028】

セキュア通信部１０１は、ＸＫＤ装置２０から配送された鍵Ｋを用いて、他拠点の通信装置１０との間でセキュアなデータ通信（すなわち、共通鍵Ｋを用いた共通鍵暗号方式によるメッセージ送受信）を行う。このとき、セキュア通信部１０１は、後述するＳＡ（Security Association）と呼ばれるパラメータに従ってセキュアなデータ通信を行う。

【0029】

鍵取得部１０２は、ＸＫＤ装置２０から配送された鍵Ｋを取得する。鍵取得部１０２によって取得された鍵Ｋは、記憶部１０３のセキュアな記憶領域に格納される。

【0030】

記憶部１０３には、ＸＫＤ装置２０から配送された鍵Ｋが格納される。また、記憶部１０３には、他拠点の通信装置１０との間でセキュアなデータ通信を行うためのＳＡと呼ばれるパラメータも格納される。すなわち、記憶部１０３には、ＳＡデータベースも含まれる。なお、ＳＡとは、他拠点の通信装置１０との間でセキュアなデータ通信を行う際に用いられるパラメータであり、ＳＰＩ（Security Parameter Index）の値、「トンネル」等といったモード、「ＥＳＰ」といったプロトコル名、「ＡＥＳ」等といった暗号化方式、鍵Ｋの値、「ＨＭＡＣ－ＳＨＡ１」等といった認証方式といった情報等が含まれる。なお、本実施形態では、ＳＡに指定されているプロトコル名は「ＥＳＰ」であるものとする。

【0031】

≪ＸＫＤ装置２０≫
図４に示すように、本実施形態に係るＸＫＤ装置２０は、鍵交換部２０１と、鍵配送部２０２と、記憶部２０３とを有する。鍵交換部２０１及び鍵配送部２０２は、例えば、ＸＫＤ装置２０にインストールされた１以上のプログラムが、プロセッサ２３に実行させる処理により実現される。また、記憶部２０３は、例えば、メモリ装置２４により実現される。

【0032】

鍵交換部２０１は、他拠点のＸＫＤ装置２０との間でＱＫＤ又はＰＱＫＤにより鍵交換を行って鍵Ｋを生成する。

【0033】

鍵配送部２０２は、鍵交換部２０１により生成した鍵Ｋを自拠点の通信装置１０に配送する。なお、鍵配送部２０２は、例えば、自拠点内のすべての通信装置１０ではなく、自拠点内の予め決められた通信装置１０にのみ鍵Ｋを配送してもよい。

【0034】

記憶部２０３には、鍵交換部２０１が鍵交換を行う際に必要な情報が格納される。また、記憶部２０３は、自身の署名鍵等も格納される。なお、署名鍵とは、データの改ざんを防止するために、そのデータに対して電子署名（デジタル署名）を付与するための鍵のことである。

【0035】

＜ＳＯＴＮ信頼性モデルと攻撃者の想定＞
本実施形態に係る通信システム１の安全性を検証するために、以下のＳＯＴＮ信頼性モデルと攻撃者を想定する。

【0036】

≪ＳＯＴＮ信頼性モデル≫
・通信装置１０及びＸＫＤ装置２０とそれらの製造ベンダは信頼する。

【0037】

・ＸＫＤ装置２０がＱＫＤにより鍵交換を行う場合、拠点間ＮＷ５０（光ファイバ専用線）上では各ＸＫＤ装置２０は互いに認証済みであり、盗聴・改ざんが不可能であるとする。

【0038】

・ＸＫＤ装置２０がＰＱＫＤにより鍵交換を行う場合、拠点間ＮＷ５０（インターネット又はＷＡＮ）上では各ＸＫＤ装置２０は必ずしも認証済みではなく、盗聴・改ざんが可能であるとする。

【0039】

≪攻撃者≫
・拠点内ＮＷ３０、拠点間ＮＷ４０、拠点間ＮＷ５０のすべてに盗聴・改ざんを意図する攻撃者を想定する。

【0040】

＜安全性要件に関する検証項目＞
以下、一例として、図１に示す通信システム１の構成において、拠点Ａ側をイニシエータ（initiator）、拠点Ｂ側をレスポンダ（responder）としてデータ通信を行う場合を想定する。また、以下では、通信装置１０Ａを「ＥＳＰｉ」、通信装置１０Ｂを「ＥＳＰｒ」、ＸＫＤ装置２０Ａを「ＩＫＥｉ」、ＸＫＤ装置２０Ｂを「ＩＫＥｒ」とも表記すると共に、通信装置１０を単に「ＥＳＰ」、ＸＫＤ装置２０を単に「ＩＫＥ」とも表記することにする。更に、これら「ＥＳＰｉ」、「ＥＳＰｒ」、「ＩＫＥｉ」、「ＩＫＥｒ」のことをエンティティとも呼ぶことにする。

【0041】

ここで、図５に示すように、互いに通信に行うエンティティ間の合意要件を（Ａ１）～（Ａ８）で表す。合意要件（Ａ１）～（Ａ２）は以下の通りである。

【0042】

（Ａ１）ＩＫＥｒからＩＫＥｉへの合意
（Ａ２）ＩＫＥｉからＩＫＥｒへの合意
（Ａ３）ＩＫＥｉからＥＳＰｉへの合意
（Ａ４）ＥＳＰｉからＩＫＥｉへの合意
（Ａ５）ＩＫＥｒからＥＳＰｒへの合意
（Ａ６）ＥＳＰｒからＩＫＥｒへの合意
（Ａ７）ＥＳＰｒからＥＳＰｉへの合意
（Ａ８）ＥＳＰｉからＥＳＰｒへの合意
なお、合意（agreement）とは２者間（例えば、甲及び乙間）でセキュアな通信を行う際における鍵の共有に関する合意を意味し、例えば、甲から乙への合意とは、甲が乙と共有した扱っている鍵を、乙も甲と共有した鍵として扱っている、ということを意味する。なお、合意に関するより詳細な説明は、例えば、参考文献１等を参照されたい。

【0043】

このとき、安全性に関する検証項目として以下の（Ｓ１）、（Ｓ２）、（ＰＦＳ）、（ＫＣ）、及び（ＫＣＩ）を検証する。

【0044】

・（Ｓ１）共通鍵Ｋの秘匿性。

【0045】

・（Ｓ２）ＥＳＰｉとＥＳＰｒ間のメッセージの秘匿性。

【0046】

・（ＰＦＳ）或るエンティティの署名鍵が漏洩したときの過去の共通鍵Ｋ及びメッセージの秘匿性。

【0047】

・（ＫＣ）或るエンティティの署名鍵が漏洩したときに（Ａ１）～（Ａ８）が満たされるか否か。

【0048】

・（ＫＣＩ）或るエンティティの署名鍵が漏洩したときに他方になりすませるか否か。

【0049】

＜実施例＞
以下、本実施形態に係る通信システム１の実施例について説明する。

【0050】

［実施例１］
本実施例では、ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵交換に事前共有鍵（ＰＳＫ：Pre-Shared Key）を用いる場合について説明する。ここで、事前共有鍵は、拠点毎に、信頼できる鍵設定者によって当該拠点内の通信装置１０及びＰＱＫＤ装置２０に設定される。

【0051】

このとき、通信システム１の鍵交換及びデータ通信を図６に示す。図６に示すように、まず、ＰＱＫＤ装置２０Ａの鍵交換部２０１とＰＱＫＤ装置２０Ｂの鍵交換部２０１はＰＱＫＤ（自身の署名鍵を用いた署名付き鍵交換）により鍵Ｋをそれぞれ生成する（ステップＳ１０１）。

【0052】

次に、ＰＱＫＤ装置２０Ａの鍵配送部２０２は、事前共有鍵を用いた共通鍵暗号方式により当該鍵Ｋを通信装置１０Ａに配送する（ステップＳ１０２－１）。これにより、通信装置１０Ａの鍵取得部１０２は、当該鍵Ｋを取得する。同様に、ＰＱＫＤ装置２０Ｂの鍵配送部２０２は、事前共有鍵を用いた共通鍵暗号方式により当該鍵Ｋを通信装置１０Ｂに配送する（ステップＳ１０２－２）。これにより、通信装置１０Ｂの鍵取得部１０２は、当該鍵Ｋを取得する。

【0053】

そして、通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式によりメッセージの送受信を行う（ステップＳ１０３）。すなわち、通信装置１０のセキュア通信部１０１は、ＳＡに指定されたモード、暗号化方式、認証方式等によりメッセージの送受信を行う。なお、セキュア通信部１０１がＳＡに指定されたモード、暗号化方式、認証方式等を利用してメッセージの送受信を行うことは、以降も同様である。

【0054】

上記の図６で説明した方式に関する安全性の検証結果を以下の表１に示す。

【0055】

【表1】

ここで、「ＫＣ ＩＫＥｉ」及び「ＫＣＩ ＩＫＥｉ」はＩＫＥｉの署名鍵が漏洩したときのＫＣ及びＫＣＩをそれぞれ表し、「ＫＣ ＩＫＥｒ」及び「ＫＣＩ ＩＫＥｒ」はＩＫＥｒの署名鍵が漏洩したときのＫＣ及びＫＣＩをそれぞれ表す。また、表中の「Ｔｒｕｅ」は要件を満たすことを表し、「Ｆａｌｓｅ１」は漏洩した署名鍵による自明ななりすましが可能なことを表し、「Ｆａｌｓｅ２」は漏洩した署名鍵により偽のＩＫＥとして他方のＩＫＥ側になりすましを行い、ＥＳＰ間の合意を破ることが可能なことを表す。

【0056】

上記の表１に示されるように、ＩＫＥｉの署名鍵が漏洩した場合は（Ａ８）の合意が破られてしまい、ＩＫＥｒの署名鍵が漏洩した場合は（Ａ７）の合意が破られてしまう。例えば、図７に示すように、ＰＱＫＤ装置２０Ａの署名鍵が攻撃者に漏洩した場合、この署名鍵により攻撃者はＰＱＫＤ装置２０Ａになりすまし、ＰＱＫＤ装置２０Ｂと鍵交換を行って偽の鍵Ｋ'を共有することが可能となる。そして、偽の鍵Ｋ'はＰＱＫＤ装置２０Ｂから通信装置１０Ｂに配送されるため、攻撃者は、偽の鍵Ｋ'を用いた共通鍵暗号方式によるメッセージ送受信を通信装置１０Ｂと行うことが可能となり、（Ａ８）の合意が破られてしまう。

【0057】

そこで、本実施例では、図６のステップＳ１０３のメッセージ送受信の際に証明書（デジタル証明書）による相互認証を導入する。なお、証明書による認証とは、電子署名を検証するための公開鍵に対して認証局（ＣＡ：Certificate Authority）から発行された証明書を付加することで、その電子署名によってデータの改ざんだけでなく、なりすましも防止できるようにする技術である。

【0058】

本実施例における通信システム１の鍵交換及びデータ通信を図８に示す。なお、各通信装置１０は自身の署名鍵を保持しており、この署名鍵に対応する公開鍵（署名検証鍵）には認証局から発行された証明書が付加されているものとする。また、ステップＳ１０１、ステップＳ１０２－１及びステップＳ１０２－２は図６と同様であるため、その説明を省略する。

【0059】

通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式により、自身の署名鍵で電子署名を付加したメッセージの送受信を行う（ステップＳ１０３'）。これにより、各通信装置１０のセキュア通信部１０１は、他の通信装置１０から受信したメッセージの署名を検証する際になりすましも検知できるため、上記のＦａｌｓｅ２に該当する攻撃を防止することが可能となる。

【0060】

上記の図８で説明した方式に関する安全性の検証結果を以下の表２に示す。

【0061】

【表2】

上記の表２に示されるように、本実施例における通信システム１では、ＩＫＥｉの署名鍵やＩＫＥｒの署名鍵が漏洩した場合であっても、（Ａ７）や（Ａ８）の合意が破られることはない。

【0062】

［実施例２］
本実施例では、ＩＫＥ間の鍵交換にＱＫＤ、ＩＫＥからＥＳＰへの鍵交換に事前共有鍵（ＰＳＫ）を用いる場合について説明する。

【0063】

このとき、本実施例における通信システム１の鍵交換及びデータ通信を図９に示す。図９に示すように、まず、ＱＫＤ装置２０Ａの鍵交換部２０１とＱＫＤ装置２０Ｂの鍵交換部２０１はＱＫＤにより鍵Ｋをそれぞれ生成する（ステップＳ２０１）。

【0064】

次に、ＱＫＤ装置２０Ａの鍵配送部２０２は、事前共有鍵を用いた共通鍵暗号方式により当該鍵Ｋを通信装置１０Ａに配送する（ステップＳ２０２－１）。これにより、通信装置１０Ａの鍵取得部１０２は、当該鍵Ｋを取得する。同様に、ＱＫＤ装置２０Ｂの鍵配送部２０２は、事前共有鍵を用いた共通鍵暗号方式により当該鍵Ｋを通信装置１０Ｂに配送する（ステップＳ２０２－２）。これにより、通信装置１０Ｂの鍵取得部１０２は、当該鍵Ｋを取得する。

【0065】

そして、通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式によりメッセージの送受信を行う（ステップＳ２０３）。

【0066】

上記の図９で説明した方式に関する安全性の検証結果を以下の表３に示す。

【0067】

【表3】

ここで、ＸＫＤ装置２０がＱＫＤにより鍵交換を行う場合、拠点間ＮＷ５０は光ファイバ専用線であり、各ＱＫＤ装置２０は互いに認証済みである。このため、拠点間ＮＷ５０上では盗聴・改ざんが不可能であり、ＩＫＥの署名鍵漏洩に関する安全性要件はいずれも検討する必要がない。

【0068】

［実施例３］
本実施例では、ＩＫＥ間の鍵交換にＰＱＫＤ、ＩＫＥからＥＳＰへの鍵交換に署名付きＤＨ（Diffie-Hellman）鍵配送（これは、ｓｉｇｎＤＨともいう。）を用いる場合について説明する。ここで、ｓｉｇｎＤＨとは、電子署名付きのＤＨ鍵配送（又は、ＤＨ鍵交換とも呼ばれる。）により鍵の配送又は交換を行う手法のことである。なお、各通信装置１０も自身の署名鍵を保持しているものとする。

【0069】

このとき、通信システム１の鍵交換及びデータ通信を図１０に示す。図１０に示すように、ＰＱＫＤ装置２０Ａの鍵交換部２０１とＰＱＫＤ装置２０Ｂの鍵交換部２０１はＰＱＫＤ（自身の署名鍵を用いた署名付き鍵交換）により鍵Ｋをそれぞれ生成する（ステップＳ３０１）。

【0070】

次に、ＰＱＫＤ装置２０Ａの鍵配送部２０２と通信装置１０Ａの鍵取得部１０２は署名付きＤＨ鍵配送により鍵Ｋを通信装置１０Ａに配送する（ステップＳ３０２－１）。同様に、ＰＱＫＤ装置２０Ｂの鍵配送部２０２と通信装置１０Ｂの鍵取得部１０２は署名付きＤＨ鍵配送により鍵Ｋを通信装置１０Ａに配送する（ステップＳ３０２－２）。

【0071】

そして、通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式によりメッセージの送受信を行う（ステップＳ３０３）。

【0072】

上記の図１０で説明した方式に関する安全性の検証結果を以下の表４に示す。

【0073】

【表4】

ここで、「ＫＣ ＥＳＰｉ」及び「ＫＣＩ ＥＳＰｉ」はＥＳＰｉの署名鍵が漏洩したときのＫＣ及びＫＣＩをそれぞれ表し、「ＫＣ ＥＳＰｒ」及び「ＫＣＩ ＥＳＰｒ」はＥＳＰｒの署名鍵が漏洩したときのＫＣ及びＫＣＩをそれぞれ表す。また、「Ｆａｌｓｅ３－１」は、ＩＫＥの署名鍵が漏洩した場合に、その署名鍵により偽のＩＫＥとして他方のＩＫＥ側になりすましを行い、ＥＳＰ間の合意を破ることが可能なことを表す。「Ｆａｌｓｅ３－２」は、ＩＫＥの署名鍵が漏洩した場合に、その署名鍵により偽のＩＫＥとしてＥＳＰ側になりすましを行い、ＥＳＰ間の合意を破ることが可能なことを表す。なお、「－」は検証を行っていないことを表す（このことは以降も同様である。）。

【0074】

上記の表４に示されるように、ＩＫＥｉの署名鍵が漏洩した場合は（Ａ７）及び（Ａ８）の合意が破られてしまい、同様にＩＫＥｒの署名鍵が漏洩した場合も（Ａ７）及び（Ａ８）の合意が破られてしまう。例えば、図１１に示すように、ＰＱＫＤ装置２０Ａの署名鍵が攻撃者に漏洩した場合、この署名鍵により攻撃者はＰＱＫＤ装置２０Ａになりすまし、通信装置１０Ａと署名付きＤＨ鍵配送を行って偽の鍵Ｋ'を配送することができる。このため、攻撃者は、偽の鍵Ｋ'を用いた共通鍵暗号方式によるメッセージ送受信を通信装置１０Ａと行うことが可能となり、（Ａ７）の合意が破られてしまう。

【0075】

そこで、本実施例でも、実施例１と同様に、図１０のステップＳ３０３のメッセージ送受信の際に証明書（デジタル証明書）による相互認証を導入する。

【0076】

本実施例における通信システム１の鍵交換及びデータ通信を図１２に示す。なお、各通信装置１０の署名鍵に対応する公開鍵（署名検証鍵）には認証局から発行された証明書が付加されているものとする。また、ステップＳ３０１、ステップＳ３０２－１及びステップＳ３０２－２は図１０と同様であるため、その説明を省略する。

【0077】

通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式により、自身の署名鍵で電子署名を付加したメッセージの送受信を行う（ステップＳ３０３'）。なお、これは、図８のステップＳ１０３'と同様である。これにより、各通信装置１０のセキュア通信部１０１は、他の通信装置１０から受信したメッセージの署名を検証する際になりすましも検知できるため、上記のＦａｌｓｅ３－１及びＦａｌｓｅ３－２に該当する攻撃を防止することが可能となる。

【0078】

上記の図１２で説明した方式とすることで、上記の表４に示す検証結果は以下の表５のようになることが期待される。

【0079】

【表5】

上記の表５に示されるように、本実施例における通信システム１では、ＩＫＥｉの署名鍵やＩＫＥｒの署名鍵が漏洩した場合であっても、（Ａ７）や（Ａ８）の合意が破られることはない。また、ＰＱＫＤ装置２０から通信装置１０への鍵配送に署名付きＤＨ鍵配送を用いることで、例えば、実施例１及び２と比較して、事前共有鍵を設定する工数（特に、拠点内の通信装置１０数が多い場合の工数）が削減されると共に、鍵設定者を信頼できるか否かといった問題が解消される。

【0080】

［実施例４］
本実施例では、ＩＫＥ間の鍵交換にＱＫＤ、ＩＫＥからＥＳＰへの鍵交換に署名付きＤＨ鍵配送を用いる場合について説明する。なお、各通信装置１０も自身の署名鍵を保持しているものとする。

【0081】

このとき、通信システム１の鍵交換及びデータ通信を図１３に示す。図１３に示すように、ＱＫＤ装置２０Ａの鍵交換部２０１とＱＫＤ装置２０Ｂの鍵交換部２０１はＱＫＤにより鍵Ｋをそれぞれ生成する（ステップＳ４０１）。

【0082】

次に、ＱＫＤ装置２０Ａの鍵配送部２０２と通信装置１０Ａの鍵取得部１０２は署名付きＤＨ鍵配送により鍵Ｋを通信装置１０Ａに配送する（ステップＳ４０２－１）。同様に、ＱＫＤ装置２０Ｂの鍵配送部２０２と通信装置１０Ｂの鍵取得部１０２は署名付きＤＨ鍵配送により鍵Ｋを通信装置１０Ａに配送する（ステップＳ４０２－２）。

【0083】

そして、通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式によりメッセージの送受信を行う（ステップＳ４０３）。

【0084】

上記の図１３で説明した方式に関する安全性の検証結果を以下の表６に示す。

【0085】

【表6】

上記の表６に示されるように、ＩＫＥｉの署名鍵が漏洩した場合は（Ａ７）の合意が破られてしまい、ＩＫＥｒの署名鍵が漏洩した場合は（Ａ８）の合意が破られてしまう。なお、ＸＫＤ装置２０がＱＫＤにより鍵交換を行う場合、拠点間ＮＷ５０上では盗聴・改ざんが不可能であるため、（Ａ１）及び（Ａ２）は検討不要である点に留意されたい。また、拠点間ＮＷ５０上ではＱＫＤ装置２０は互いに認証済みであるため攻撃者は他方のＩＫＥ側になりすましを行うことができず、ＩＫＥｉの署名鍵が漏洩した場合であっても実施例３と異なり（Ａ８）の合意は破られず、同様にＩＫＥｒの署名鍵が漏洩した場合であっても実施例３と異なり（Ａ７）の合意は破られない。

【0086】

そこで、本実施例でも、実施例３と同様に、図１３のステップＳ４０３のメッセージ送受信の際に証明書（デジタル証明書）による相互認証を導入する。

【0087】

本実施例における通信システム１の鍵交換及びデータ通信を図１４に示す。なお、各通信装置１０の署名鍵に対応する公開鍵（署名検証鍵）には認証局から発行された証明書が付加されているものとする。また、ステップＳ４０１、ステップＳ４０２－１及びステップＳ４０２－２は図１３と同様であるため、その説明を省略する。

【0088】

通信装置１０Ａのセキュア通信部１０１と通信装置１０Ｂのセキュア通信部１０１は、鍵Ｋを用いた共通鍵暗号方式により、自身の署名鍵で電子署名を付加したメッセージの送受信を行う（ステップＳ４０３'）。なお、これは、図１２のステップＳ３０３'と同様である。これにより、各通信装置１０のセキュア通信部１０１は、他の通信装置１０から受信したメッセージの署名を検証する際になりすましも検知できるため、上記のＦａｌｓｅ３－２に該当する攻撃を防止することが可能となる。

【0089】

上記の図１４で説明した方式に関する安全性の検証結果を以下の表７に示す。

【0090】

【表7】

上記の表７に示されるように、本実施例における通信システム１では、ＩＫＥｉの署名鍵やＩＫＥｒの署名鍵が漏洩した場合であっても、（Ａ７）や（Ａ８）の合意が破られることはない。また、ＱＫＤ装置２０から通信装置１０への鍵配送に署名付きＤＨ鍵配送を用いることで、例えば、実施例１及び２と比較して、事前共有鍵を設定する工数（特に、拠点内の通信装置１０数が多い場合の工数）が削減されると共に、鍵設定者を信頼できるか否かといった問題が解消される。

【0091】

＜まとめ＞
以上のように、本実施形態に係る通信システム１では、ＰＱＫＤ又はＱＫＤによる鍵交換を実現するＩＫＥとして機能する機器とＥＳＰとして機能する機器とで構成される４者間以上のネットワークにおいて、ＥＳＰとして機能する機器間の通信を共通鍵暗号方式とデジタル証明書による相互認証付き電子署名とで構成する。これにより、ＩＫＥとして機能する機器の署名鍵が漏洩した場合であっても、ＥＳＰとして機能する機器間の合意要件が保証される。このため、例えば、ＥＳＰ間の通信をＯＴＮで構成し、本実施形態に係る通信システム１によりＳＯＴＮを実現する場合に、従来技術よりもセキュアなネットワークを構築することが可能となる。

【0092】

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。

【0093】

［参考文献］
参考文献１：「Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2」, Cas Cremers, ESORICS 2011.

【符号の説明】

【0094】

１ 通信システム
１０ 通信装置
１１ 外部Ｉ／Ｆ
１１ａ 記録媒体
１２ 通信Ｉ／Ｆ
１３ プロセッサ
１４ メモリ装置
１５ バス
２０ ＸＫＤ装置
２１ 外部Ｉ／Ｆ
２１ａ 記録媒体
２２ 通信Ｉ／Ｆ
２３ プロセッサ
２４ メモリ装置
２５ バス
３０ 拠点内ＮＷ
４０ 拠点間ＮＷ
５０ 拠点間ＮＷ
１０１ セキュア通信部
１０２ 鍵取得部
１０３ 記憶部
２０１ 鍵交換部
２０２ 鍵配送部
２０３ 記憶部
Ｅ 拠点環境

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】