(57)【要約】【課題】鍵共有通信におけるネットワーク負荷および処理負荷を低減する。【解決手段】第１の乱数受信部３は、データ通信装置２から第１の暗号１６を受信する。第２の乱数送信部４は、第１の暗号１６から第１の秘密鍵１５を用いて第１の乱数１８を復号し、第２の乱数１９を第２の公開鍵１７を用いて第２の暗号２０に暗号化してデータ通信装置２に送信する。ハッシュ値受信部５は、第１のハッシュ値２２をデータ通信装置２から受信する。セッション鍵生成部６は、第１の秘密鍵１５で復号した第１の乱数１８および第２の乱数１９から第２のハッシュ値２１を生成し、第１のハッシュ値２２と第２のハッシュ値２１とが同じである場合に、第１の乱数１８と第２の乱数１９とにもとづいてセッション鍵２３を生成する。このような鍵共有通信において、データ通信装置１とデータ通信装置２は、３ウェイハンドシェークを実現する。【選択図】図１
2015126485.tif 000002
【特許請求の範囲】
【請求項１】
第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信し、前記第１の暗号を第１の秘密鍵で復号し、
第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信し、
前記第１の乱数と第２の秘密鍵で復号された前記第２の乱数とから生成された第１のハッシュ値を前記他のデータ通信装置から受信し、前記第１の秘密鍵で復号した前記第１の乱数と前記生成した前記第２の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、
前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成する、
ことを特徴とするデータ通信方法。
【請求項２】
前記第１の公開鍵は、前記他のデータ通信装置の識別情報であり、
前記第２の公開鍵は、前記データ通信装置の識別情報である、
ことを特徴とする請求項１記載のデータ通信方法。
【請求項３】
前記データ通信装置は、前記データ通信装置の記憶部に前記第１の公開鍵をあらかじめ保持し、
前記他のデータ通信装置は、前記他のデータ通信装置の記憶部に前記第２の公開鍵をあらかじめ保持する、
ことを特徴とする請求項２記載のデータ通信方法。
【請求項４】
第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信する第１の乱数受信部と、
前記第１の暗号を第１の秘密鍵で復号し、第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信する第２の乱数送信部と、
前記第１の乱数と第２の秘密鍵で復号された前記第２の乱数とから生成された第１のハッシュ値を前記他のデータ通信装置から受信するハッシュ値受信部と、
前記第１の秘密鍵で復号した前記第１の乱数と前記生成した前記第２の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、
前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成するセッション鍵生成部と、
を備えることを特徴とするデータ通信装置。
【請求項５】
第１のデータ通信装置と第２のデータ通信装置とのデータ通信方法において、
前記第１のデータ通信装置は、
第１の乱数を生成し、前記第１の乱数を第１の公開鍵で暗号化した第１の暗号を前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
前記第１のデータ通信装置から受信した前記第１の暗号から第１の秘密鍵で前記第１の乱数を復号し、第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記第１のデータ通信装置に送信し、
前記第１のデータ通信装置は、
前記第２のデータ通信装置から受信した前記第２の暗号から第２の秘密鍵で前記第２の乱数を復号し、生成した前記第１の乱数と復号した前記第２の乱数とから第１のハッシュ値を生成して前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
生成した前記第２の乱数と復号した前記第１の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成する、
ことを特徴とするデータ通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ通信方法、およびデータ通信装置に関する。
【背景技術】
【０００２】
通信機能を持った端末（データ通信装置）同士が互いに通信をおこなうことで、メッシュ状の通信ネットワークを形成したメッシュネットワークが知られている。メッシュネットワークでの通信は、ある端末から隣の端末へ、更に隣の端末へとデータがバケツリレー方式で伝送されて、目的の端末まで送信される。メッシュネットワークでは、個々の端末は、隣の端末と通信できればよいので、端末の破損等が発生しても代替経路を確保しやすく、障害に強いといわれている。そのため、通信インフラの設営が困難な地域でのインフラや、センサネットワーク、ＢＥＭＳ／ＨＥＭＳ（Building／Home Energy Management System）等への利用が期待されている。
【０００３】
一方で、メッシュネットワークでは、各端末が他の端末間の通信を中継するため、中継をおこなう端末での通信内容の盗聴が容易であり、通信の暗号化等による通信路のセキュリティ確保は重要な課題である。また、メッシュネットワークでは、ネットワークへの端末の参加・離脱が容易なため、不正な端末の追加を防ぐために、端末の認証も重要な課題である。さらに、センサネットワーク等では、端末の盗難の可能性もあり、盗まれた端末が解析されて、内部情報が漏洩することも考慮されなければならない。
【０００４】
たとえば、センサネットワーク構築に、端末の認証や通信路の暗号化をマスタ鍵方式の共通鍵暗号を利用する提案がある。この方式の最も基本的な利用では、すべての端末が同じ共通鍵を保持しており、安全性の担保はマスタ鍵を安全に保持することを安全性の担保として、同じ鍵（マスタ鍵）を用いて端末の認証と通信路の暗号化をおこなう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２０１３−５０３５６５号公報
【特許文献２】特開平１１−１０９８５４号公報
【非特許文献】
【０００６】
【非特許文献１】ZigBee Alliance,「ZigBeeテクニカル概要」https://docs.zigbee.org/zigbee-docs/dcn/08/docs-08-0127-00-0mwg-zigbee-technical-overview-don-sturek.pdf
【非特許文献２】W. Du, J. Deng, Y. Han and P. Varshney, "A Pairwise Key Pre-distribution Scheme for Wireless Sensor Networks," ACM Conf. CCS, pp.42-51, 2003
【非特許文献３】Dan Boneh, Matthew K. Franklin, Identity-Based Encryption from the Weil Pairing Advances in Cryptology - Proceedings of CRYPTO 2001 (2001)
【非特許文献４】M. Huang “Identity-Based Encryption (IBE) Cipher Suites for Transport Layer Security”, RFC Draft 2009年7月3日
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、マスタ鍵方式は、端末の盗難等により端末内のマスタ鍵が漏洩した場合、ネットワーク全体のセキュリティが低下するクラスブレーク（Class break）を生じる。
【０００８】
これに対して、任意の２つの端末間で異なる鍵をあらかじめ共通鍵として共有する方式（共通鍵共有方式）がある。共通鍵共有方式は、クラスブレークを防止できるが、端末数の増大につれて管理しなければならない鍵の数が膨大になるという問題がある。また、ある端末の盗難により端末内の情報が漏えいした場合、その端末に関する通信は、内部情報が漏洩した時点以降だけでなく、それ以前のすべての通信内容についても、情報が漏洩してしまうおそれがあり、これをＰＦＳ（Perfect Forward Secrecy）がないという。
【０００９】
そこで、クラスブレークの危険性があり、ＰＦＳを実現できない共通鍵を安全性の担保とする方式に代えて、公開鍵暗号ベースの技術によりセキュリティを確保する。公開鍵暗号ベースの認証・鍵共有プロトコルとして、たとえば、ＩＰｓｅｃ／ＩＫＥ（Internet Protocol security / Internet Key Exchange）やＳＳＬ／ＴＬＳ（Secure Sockets Layer / Transport Layer Security）がある。しかしながら、ＩＰｓｅｃ／ＩＫＥやＳＳＬ／ＴＬＳは、十分なリソースや通信環境を持つ端末やサーバ向けのものであり、センサネットワークを代表とするメッシュネットワークを構成する端末には不向きである。たとえば、メッシュネットワークは、十分なリソースを有しない端末でマルチホップ通信をおこなうため、公開鍵暗号処理が行われる鍵共有通信（ハンドシェーク：hand shake）の回数や、その通信量が小さいことが望ましい。また、メッシュネットワークは、公開鍵暗号処理の計算回数も少ない方が望ましい。
【００１０】
しかしながら、従来から提案されている公開鍵暗号ベースの技術は、ハンドシェークに４回以上の通信（４way hand shake）を必要とし、また、３回の通信（３way hand shake）であっても、公開鍵暗号処理の負荷や通信データ量が多い。
【００１１】
１つの側面では、本発明は、鍵共有通信におけるネットワーク負荷および／または処理負荷を低減できるデータ通信方法、およびデータ通信装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、以下に示すような、データ通信方法が提供される。データ通信方法は、第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信し、第１の暗号を第１の秘密鍵で復号し、第２の乱数を生成して、第２の乱数を第２の公開鍵で暗号化した第２の暗号を他のデータ通信装置に送信し、第１の乱数と第２の秘密鍵で復号された第２の乱数とから生成された第１のハッシュ値を他のデータ通信装置から受信し、第１の秘密鍵で復号した第１の乱数と生成した第２の乱数とから生成した第２のハッシュ値と、第１のハッシュ値とを比較し、第１のハッシュ値と第２のハッシュ値とが同じである場合に、第１の乱数と第２の乱数とにもとづいてセッション鍵を生成する。
【００１３】
また、以下に示すような、データ通信装置が提供される。データ通信装置は、第１の乱数受信部と、第２の乱数送信部と、ハッシュ値受信部と、セッション鍵生成部とを備える。第１の乱数受信部は、第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信する。第２の乱数送信部は、第１の暗号を第１の秘密鍵で復号し、第２の乱数を生成して、第２の乱数を第２の公開鍵で暗号化した第２の暗号を他のデータ通信装置に送信する。ハッシュ値受信部は、第１の乱数と第２の秘密鍵で復号された第２の乱数とから生成された第１のハッシュ値を他のデータ通信装置から受信する。セッション鍵生成部は、第１の秘密鍵で復号した第１の乱数と生成した第２の乱数とから生成した第２のハッシュ値と、第１のハッシュ値とを比較し、第１のハッシュ値と第２のハッシュ値とが同じである場合に、第１の乱数と第２の乱数とにもとづいてセッション鍵を生成する。
【発明の効果】
【００１４】
１態様によれば、データ通信方法、およびデータ通信装置において、鍵共有通信におけるネットワーク負荷および／または処理負荷を低減できる。
【図面の簡単な説明】
【００１５】
【図１】第１の実施形態のデータ通信装置におけるデータ通信方法の一例を示す図である。
【図２】第１の実施形態の鍵共有通信方式と従来方式との性能比較表の一例を示す図である。
【図３】第２の実施形態のセンサネットワークの構成の一例を示す図である。
【図４】第２の実施形態の端末装置の機能構成の一例を示す図である。
【図５】第２の実施形態の端末装置のハードウェア構成の一例を示す図である。
【図６】第２の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスの一例を示す図である。
【図７】第２の実施形態のハンドシェークフェーズにおけるサーバ側端末装置の処理の一例を示す図である。
【図８】第２の実施形態のハンドシェークフェーズにおけるクライアント側端末装置の処理の一例を示す図である。
【図９】第２の実施形態のデータ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理の一例を示す図である。
【図１０】第３の実施形態のデータ通信装置におけるデータ通信方法の一例を示す図である。
【図１１】第４の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスの一例を示す図である。
【図１２】第４の実施形態のハンドシェークフェーズにおけるサーバ側端末装置の処理の一例を示す図である。
【図１３】第４の実施形態のハンドシェークフェーズにおけるクライアント側端末装置の処理の一例を示す図である。
【図１４】第４の実施形態のデータ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理の一例を示す図である。
【図１５】第５の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信の一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して実施の形態を詳細に説明する。
［第１の実施形態］
まず、第１の実施形態のデータ通信装置におけるデータ通信方法について図１を用いて説明する。図１は、第１の実施形態のデータ通信装置におけるデータ通信方法の一例を示す図である。
【００１７】
データ通信装置１とデータ通信装置２は、有線または無線により通信可能に接続し、相互にデータ通信をおこなう。データ通信装置１とデータ通信装置２は、直接に接続してもよいし、１または２以上の中継装置を介してマルチホップに接続してもよい。データ通信装置２は、データ通信装置１にとって他のデータ通信装置であり、またデータ通信装置１は、データ通信装置２にとって他のデータ通信装置である。
【００１８】
データ通信装置１は、第１の乱数受信部３と、第２の乱数送信部４と、ハッシュ値受信部５と、セッション鍵生成部６とを備える。第１の乱数受信部３は、データ通信装置２から第１の暗号１６を受信する。なお、第１の暗号１６は、通信路中において不正に書き換えられていなければ、データ通信装置２が送信する第１の暗号９と同じである。データ通信装置２は、第１の乱数８を生成し、第１の乱数８を第１の公開鍵７を用いて第１の暗号９に暗号化して、データ通信装置１に第１の暗号９を送信する（図示しない第１の乱数送信部に相当）。
【００１９】
第２の乱数送信部４は、第１の暗号１６から第１の秘密鍵１５を用いて第１の乱数１８を復号する。第２の乱数送信部４は、第２の乱数１９を生成する。第２の乱数送信部４は、第２の乱数１９を第２の公開鍵１７を用いて第２の暗号２０に暗号化する。第２の乱数送信部４は、第２の暗号２０をデータ通信装置２に送信する。なお、第２の暗号１１は、通信路中において不正に書き換えられていなければ、データ通信装置１が送信する第２の暗号２０と同じである。データ通信装置２は、第２の暗号１１を受信する（図示しない第２の乱数受信部に相当）。データ通信装置２は、第２の公開鍵１７と対になる第２の秘密鍵１０を用いて第２の乱数１２を復号する。データ通信装置２は、第１の乱数８と第２の乱数１２とから第１のハッシュ値１３を生成する。データ通信装置２は、データ通信装置１に第１のハッシュ値１３を送信する（図示しないハッシュ値送信部に相当）。データ通信装置２は、第１の乱数８と第２の乱数１２とからセッション鍵１４を生成する。
【００２０】
ハッシュ値受信部５は、第１のハッシュ値２２をデータ通信装置２から受信する。なお、第１のハッシュ値２２は、通信路中において不正に書き換えられていなければ、データ通信装置２が送信する第１のハッシュ値１３と同じである。
【００２１】
セッション鍵生成部６は、第１の公開鍵７と対となる第１の秘密鍵１５で復号した第１の乱数１８と第２の乱数１９とから第２のハッシュ値２１を生成する。セッション鍵生成部６は、第１のハッシュ値２２と第２のハッシュ値２１とを比較し、第１のハッシュ値２２と第２のハッシュ値２１とが同じである場合に、第１の乱数１８と第２の乱数１９とにもとづいてセッション鍵２３を生成する。データ通信装置１が生成するセッション鍵２３は、第１の乱数１８と第１の乱数８とが一致し、第２の乱数１９と第２の乱数１２とが一致する場合に、データ通信装置２が生成するセッション鍵１４と一致する。なお、データ通信装置１とデータ通信装置２は、共通のセッション鍵生成方法によりセッション鍵を生成する。
【００２２】
このようにして、データ通信装置１は、データ通信装置２が保持するセッション鍵１４と共通のセッション鍵２３を保持することができる。このような鍵共有通信において、データ通信装置１とデータ通信装置２は、３回の通信（３ウェイハンドシェーク）を実現している。また、データ通信装置１は、１回目の通信において第１の暗号１６を受信し、２回目の通信において第２の暗号２０を送信することから、３回の通信における公開鍵暗号のデータ数は、「２」である。また、公開鍵暗号の処理回数は、データ通信装置１とデータ通信装置２のそれぞれにおいて「２」であり、データ通信装置１とデータ通信装置２とで「４」である。また、このような鍵共有通信において、データ通信装置１は、クラスブレークの危険性を有さず、ＰＦＳを実現する。すなわち、データ通信装置１は、データ通信装置２との通信方法において、鍵共有通信におけるネットワーク負荷および処理負荷を低減できる。
【００２３】
ここで、第１の実施形態の鍵共有通信方式と従来方式との性能比較について図２を用いて説明する。図２は、第１の実施形態の鍵共有通信方式と従来方式との性能比較表の一例を示す図である。
【００２４】
性能比較表２００は、第１の実施形態の鍵共有通信方式の性能と従来方式の性能とを比較可能に示す。性能比較表２００は、縦方向に第１の実施形態の鍵共有通信方式と従来方式と並べ、横方向に各方式の性能値を並べる。「新規」は、第１の実施形態の鍵共有通信方式を示す。従来方式は、「ＩＫＥ（ＲＳＡ）」、「ＴＬＳ（ＲＳＡ）ｃｌｉｅｎｔ認証付」、「ＴＬＳ（ＤＨＥ−ＲＳＡ）」、「ＴＬＳ（ＲＳＡ）」、および「ＴＬＳ（ＩＢＥ−ＨＵ）」がある。
【００２５】
性能評価項目は、ハンドシェーク、ＰＦＳ、公開鍵暗号処理回数、公開鍵暗号データ数、クラスブレークである。ハンドシェークは鍵共有通信の回数を示し、ＰＦＳはＰＦＳの有無を示し、公開鍵暗号処理回数は公開鍵暗号処理の回数を示し、公開鍵暗号データ数は送受信される公開鍵暗号のデータ数を示し、クラスブレークはクラスブレークの危険の有無を示す。
【００２６】
これによれば、「新規」は、ハンドシェーク「３」であり、他の従来方式と比較して最小である。このハンドシェーク「３」は、理論的に最小とされる値である。また、「新規」は、公開鍵暗号処理回数「４」であり、他の従来方式と比較して十分に小さい。また、「新規」は、公開鍵暗号データ数「２」であり、他の従来方式と比較して十分に小さい。このように、「新規」は、鍵共有通信におけるネットワーク負荷および処理負荷が他の従来方式と比較して小さい。なお、「ＴＬＳ（ＲＳＡ）」は、ハンドシェーク「３」、公開鍵暗号処理回数「３」、公開鍵暗号データ数「２」であり、数値データにおいて「新規」より優れ、クラスブレークの危険がないもののＰＦＳを実現できていない。これに対して、「新規」は、クラスブレークの危険がなく、さらにＰＦＳを実現するものであり、このような鍵共有通信方式は、従来方式の中に見当たらない。
【００２７】
［第２の実施形態］
次に、第１の実施形態の鍵共有通信方式をセンサネットワークに適用した第２の実施形態について説明する。まず、第２の実施形態のセンサネットワークについて図３を用いて説明する。図３は、第２の実施形態のセンサネットワークの構成の一例を示す図である。
【００２８】
センサネットワーク３０は、複数の端末装置４０を含んで構成される。端末装置４０は、１以上の他の端末装置４０と通信可能に接続する。センサネットワーク３０は、たとえば、任意の２つの端末装置４０をマルチホップ通信で接続するメッシュネットワークである。
【００２９】
センサネットワーク３０は、１以上の端末装置４０がゲートウェイ３１と接続し、ゲートウェイ３１を介してネットワーク３２（たとえば、インターネット）と接続する。
次に、端末装置４０の機能構成について図４を用いて説明する。図４は、第２の実施形態の端末装置の機能構成の一例を示す図である。
【００３０】
端末装置４０は、制御部４１と、通信部４２と、セッション確立部４５と、記憶部４６と、データ通信部４７と、暗号処理部４８とを備える。制御部４１は、端末装置４０を統括的に制御する。通信部４２は、他の端末装置４０との通信をおこなうインタフェースである。通信部４２は、送信部４３と、受信部４４を備え、送信部４３を介して他の端末装置４０にデータの送信をおこない、受信部４４を介して他の端末装置４０からデータの受信をおこなう。
【００３１】
セッション確立部４５は、他の端末装置４０とのセッション確立をおこなう。セッション確立部４５は、ハンドシェークフェーズにおける通信を制御する。記憶部４６は、セッション確立に用いる情報や、データ通信に用いる情報など、所要の情報を記憶する。データ通信部４７は、他の端末装置４０とのセッション確立後のデータ転送フェーズにおいてデータ通信を制御する。
【００３２】
暗号処理部４８は、暗号に関する処理をおこなう。暗号処理部４８は、ＩＤベース暗号処理部４９と、乱数生成部５０と、共通鍵暗号処理部５１を備える。ＩＤベース暗号処理部４９は、ＩＤベース暗号処理を実行する。ＩＤベース暗号処理部４９は、ハンドシェークフェーズにおいて、他の端末装置４０のＩＤ（IDentification）を公開鍵として暗号化対象データを暗号化し、自らのＩＤと対となる秘密鍵で復号対象データを復号する。ＩＤは、端末装置４０を一意に特定可能な識別情報である。ＩＤは、たとえば、端末装置４０に固有の名前、番号、アドレス、あるいはこれらの組み合わせなどである。乱数生成部５０は、所定の乱数生成アルゴリズムを用いて乱数を生成する。共通鍵暗号処理部５１は、データ転送フェーズにおいて、他の端末装置４０との間で共通する共通鍵（セッション鍵）を用いて、暗号化対象データの暗号化と復号対象データの復号とをおこなう。
【００３３】
次に、端末装置４０のハードウェア構成について図５を用いて説明する。図５は、第２の実施形態の端末装置のハードウェア構成の一例を示す図である。
端末装置４０は、プロセッサ５２によって装置全体が制御されている。プロセッサ５２には、バス５６を介してＲＯＭ（Read Only Memory）５３と、ＲＡＭ（Random Access Memory）５４と、インタフェース５５と、複数の周辺機器が接続されている。プロセッサ５２は、マルチプロセッサであってもよい。プロセッサ５２は、たとえばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ５２は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。
【００３４】
ＲＯＭ５３は、端末装置４０の電源遮断時においても記憶内容を保持する。ＲＯＭ５３は、たとえば、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）やフラッシュメモリなどの半導体記憶装置や、ＨＤＤ（Hard Disk Drive）などである。また、ＲＯＭ５３は、端末装置４０の補助記憶装置として使用される。ＲＯＭ５３には、ＯＳ（Operating System）のプログラムやファームウェア、アプリケーションプログラム、および各種データが格納される。
【００３５】
ＲＡＭ５４は、端末装置４０の主記憶装置として使用される。ＲＡＭ５４には、プロセッサ５２に実行させるＯＳのプログラムやファームウェア、アプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ５４には、プロセッサ５２による処理に必要な各種データが格納される。また、ＲＡＭ５４は、各種データの格納に用いるメモリと別体にキャッシュメモリを含むものであってもよい。バス５６に接続されている周辺機器としては、インタフェース５５、通信部４２、暗号処理部４８がある。インタフェース５５は、入出力装置と接続して入出力をおこなう。
【００３６】
以上のようなハードウェア構成によって、第２の実施形態の端末装置４０の処理機能を実現することができる。なお、第１の実施形態に示したデータ通信装置１，２も、図５に示した端末装置４０と同様のハードウェアにより実現することができる。また、第３の実施形態に示すデータ通信装置１０１，１０２、第４の実施形態として示す端末装置、第５の実施形態として示す端末装置も、図５に示した端末装置４０と同様のハードウェアにより実現することができる。
【００３７】
端末装置４０は、たとえばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、実施の形態の処理機能を実現する。端末装置４０に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。たとえば、端末装置４０に実行させるプログラムをＲＯＭ５３に格納しておくことができる。プロセッサ５２は、ＲＯＭ５３内のプログラムの少なくとも一部をＲＡＭ５４にロードし、プログラムを実行する。また端末装置４０に実行させるプログラムを、図示しない光ディスク、メモリ装置、メモリカードなどの可搬型記録媒体に記録しておくこともできる。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。メモリ装置は、インタフェース５５あるいは図示しない機器接続インタフェースとの通信機能を搭載した記録媒体である。たとえば、メモリ装置は、メモリリーダライタによりメモリカードへのデータの書き込み、またはメモリカードからのデータの読み出しをおこなうことができる。メモリカードは、カード型の記録媒体である。
【００３８】
可搬型記録媒体に格納されたプログラムは、たとえばプロセッサ５２からの制御により、ＲＯＭ５３にインストールされた後、実行可能となる。またプロセッサ５２が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００３９】
なお、第１の実施形態または第３の実施形態に示したデータ通信装置１，２，１０１，１０２、第４の実施形態または第５の実施形態として示す端末装置も、図５に示した端末装置４０と同様にプログラムを実行ことにより、実施の形態の処理機能を実現する。
【００４０】
次に、第２の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスについて、図６を用いて説明する。図６は、第２の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスの一例を示す図である。
【００４１】
２つの端末装置４０の一方がクライアント（クライアント側端末装置）５７であり、他方がサーバ（サーバ側端末装置）５８である。
第２の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスは、クライアント５７がサーバ５８に対して証明書を送付することを要しないので、サーバ５８からの通信となる。
【００４２】
［ステップＳ１１］サーバ５８は、クライアント５７のＩＤベース公開鍵で乱数Ｒｓを暗号化した暗号Ｅ（Ｒｓ）を、クライアント５７に送信する。乱数Ｒｓは、サーバ５８が生成する乱数である。
【００４３】
［ステップＳ１２］クライアント５７は、サーバ５８のＩＤベース公開鍵で乱数Ｒｃを暗号化した暗号Ｅ（Ｒｃ）を、クライアント５７に送信する。乱数Ｒｃは、クライアント５７が生成する乱数である。
【００４４】
［ステップＳ１３］サーバ５８は、サーバ５８の秘密鍵で暗号Ｅ（Ｒｃ）を復号し、復号した乱数Ｒｃと、乱数Ｒｓとから生成したハッシュ値（Ｈａｓｈ）を、クライアント５７に送信する。
【００４５】
クライアント５７は、クライアント５７の秘密鍵で暗号Ｅ（Ｒｓ）を復号し、復号した乱数Ｒｓと、乱数Ｒｃとから生成したハッシュ値と、サーバ５８から受信したハッシュ値とを照合し、２つのハッシュ値が一致した場合にセッションを確立する。
【００４６】
以上、ステップＳ１１からステップＳ１３が３回の鍵共有通信からなるハンドシェークフェーズである。以降、クライアント５７とサーバ５８は、それぞれが乱数Ｒｃと乱数Ｒｓとから生成するセッション鍵を用いてデータ通信（Ｄａｔａ通信）をおこなう（ステップＳ１４）。ステップＳ１４以降は、保護されたデータ通信が可能なデータ転送フェーズである。
【００４７】
次に、クライアント５７とサーバ５８がおこなう各処理について図７から図９を用いて説明する。まず、ハンドシェークフェーズにおけるサーバ側端末装置の処理について図７を用いて説明する。図７は、第２の実施形態のハンドシェークフェーズにおけるサーバ側端末装置の処理の一例を示す図である。
【００４８】
［ステップＳ２１］サーバ５８は、所定の乱数生成アルゴリズムにしたがい乱数Ｒｓ６０を生成する。
［ステップＳ２２］サーバ５８は、クライアント５７の公開鍵としてＩＤベースの公開鍵であるＣｌｉｅｎｔＩＤ６１を取得する。ＣｌｉｅｎｔＩＤ６１は、たとえば、クライアント５７の通信アドレスである。ＣｌｉｅｎｔＩＤ６１は、サーバ５８にとって既知の情報であり、たとえば、サーバ５８の記憶部４６が保持する情報である。そのため、サーバ５８は、クライアント５７からＣｌｉｅｎｔＩＤ６１を取得することを要さない。
【００４９】
［ステップＳ２３］サーバ５８は、ＣｌｉｅｎｔＩＤ６１を用いて乱数Ｒｓ６０を暗号化して暗号Ｅ（Ｒｓ）６２を得る。
［ステップＳ２４］サーバ５８は、暗号Ｅ（Ｒｓ）６２をクライアント５７に送信する。
【００５０】
［ステップＳ２５］サーバ５８は、暗号Ｅ（Ｒｃ）６３をクライアント５７から受信する。暗号Ｅ（Ｒｃ）６３は、クライアント５７がサーバ５８の公開鍵で乱数Ｒｃを暗号化した情報である。
【００５１】
［ステップＳ２６］サーバ５８は、サーバ５８の公開鍵と対となる秘密鍵であるサーバ秘密鍵６４を取得する。サーバ秘密鍵６４は、サーバ５８にとって既知の情報であり、たとえば、サーバ５８の記憶部４６が保持する情報である。
【００５２】
［ステップＳ２７］サーバ５８は、サーバ秘密鍵６４で暗号Ｅ（Ｒｃ）６３を復号し、乱数Ｒｃ６５を得る。
［ステップＳ２８］サーバ５８は、乱数Ｒｓ６０と乱数Ｒｃ６５を結合した結合値（Ｒｓ，Ｒｃ）６６を生成する。結合値（Ｒｓ，Ｒｃ）６６は、乱数Ｒｓ６０と乱数Ｒｃ６５を並べた情報である。
【００５３】
［ステップＳ２９］サーバ５８は、ハッシュ関数を用いたハッシュ値計算により、結合値（Ｒｓ，Ｒｃ）６６からハッシュ値（メッセージダイジェスト）６７を得る。ハッシュ関数は、たとえば、ＳＨＡ−１やＭＤ５などがある。
【００５４】
［ステップＳ３０］サーバ５８は、ハッシュ値６７をクライアント５７に送信する。
次に、ハンドシェークフェーズにおけるクライアント側端末装置の処理について図８を用いて説明する。図８は、第２の実施形態のハンドシェークフェーズにおけるクライアント側端末装置の処理の一例を示す図である。
【００５５】
［ステップＳ３１］クライアント５７は、暗号Ｅ（Ｒｓ）６８をサーバ５８から受信する。なお、暗号Ｅ（Ｒｓ）６８は、通信路中において不正に書き換えられていなければ、サーバ５８が送信する暗号Ｅ（Ｒｓ）６２と同じである。
【００５６】
［ステップＳ３２］クライアント５７は、クライアント５７の公開鍵（ＣｌｉｅｎｔＩＤ６１）と対となる秘密鍵であるクライアント秘密鍵６９を取得する。クライアント秘密鍵６９は、クライアント５７にとって既知の情報であり、たとえば、クライアント５７の記憶部４６が保持する情報である。
【００５７】
［ステップＳ３３］クライアント５７は、クライアント秘密鍵６９で暗号Ｅ（Ｒｓ）６８を復号し、乱数Ｒｓ７０を得る。
［ステップＳ３４］クライアント５７は、所定の乱数生成アルゴリズムにしたがい乱数Ｒｃ７１を生成する。
【００５８】
［ステップＳ３５］クライアント５７は、サーバ５８の公開鍵としてＩＤベースの公開鍵であるＳｅｒｖｅｒＩＤ７２を取得する。ＳｅｒｖｅｒＩＤ７２は、たとえば、サーバ５８の通信アドレスである。ＳｅｒｖｅｒＩＤ７２は、クライアント５７にとって既知の情報であり、たとえば、クライアント５７の記憶部４６が保持する情報である。そのため、クライアント５７は、サーバ５８からＳｅｒｖｅｒＩＤ７２を取得することを要さない。
【００５９】
［ステップＳ３６］クライアント５７は、ＳｅｒｖｅｒＩＤ７２を用いて乱数Ｒｃ７１を暗号化して暗号Ｅ（Ｒｃ）７３を得る。
［ステップＳ３７］クライアント５７は、暗号Ｅ（Ｒｃ）７３をサーバ５８に送信する。
【００６０】
［ステップＳ３８］クライアント５７は、ハッシュ値７４をサーバ５８から受信する。なお、ハッシュ値７４は、通信路中において不正に書き換えられていなければ、サーバ５８が送信するハッシュ値６７と同じである。
【００６１】
［ステップＳ３９］クライアント５７は、サーバ５８が乱数Ｒｓ６０と乱数Ｒｃ６５から結合値（Ｒｓ，Ｒｃ）６６を生成したのと同様にして、乱数Ｒｓ７０と乱数Ｒｃ７１を結合した結合値（Ｒｓ，Ｒｃ）７５を生成する。
【００６２】
［ステップＳ４０］クライアント５７は、サーバ５８と同様のハッシュ関数を用いたハッシュ値計算により、結合値（Ｒｓ，Ｒｃ）７５からハッシュ値７６を得る。
［ステップＳ４１］クライアント５７は、ハッシュ値７４とハッシュ値７６を比較、照合して照合結果７７を得る。照合結果７７は、ハッシュ値７４とハッシュ値７６が一致した場合に照合成功であり、ハッシュ値７４とハッシュ値７６が一致しない場合に照合失敗である。クライアント５７は、照合成功によりサーバ５８とのセッションを確立する。
【００６３】
次に、データ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理について図９を用いて説明する。図９は、第２の実施形態のデータ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理の一例を示す図である。
【００６４】
［ステップＳ４５］サーバ５８は、ステップＳ３０の実行後に、乱数Ｒｓ６０と乱数Ｒｃ６５とにもとづいて所定の鍵生成アルゴリズムにしたがいセッション鍵７８を生成する。
【００６５】
［ステップＳ４６］クライアント５７は、ステップＳ４１におけるハッシュ値の照合成功後に、乱数Ｒｓ７０と乱数Ｒｃ７１とにもとづいてサーバ５８と同様の鍵生成アルゴリズムにしたがいセッション鍵７９を生成する。
【００６６】
クライアント５７とサーバ５８は、セッション鍵７８（セッション鍵７９）を用いて保護されたデータ通信をおこなう（ステップＳ４７、ステップＳ４８）。サーバ５８は、クライアント５７と正常なデータ通信をおこなえることを確認することにより認証とする。
【００６７】
このように、クライアント５７とサーバ５８がおこなう鍵共有通信は、クライアント５７からサーバ５８への証明書の送付を不要にして、３ウェイハンドシェークを実現している。また、クライアント５７とサーバ５８がおこなう鍵共有通信は、公開鍵暗号処理回数が「４」であり、他の従来方式と比較して十分に小さく、公開鍵暗号データ数が「２」であり、他の従来方式と比較して十分に小さい。また、クライアント５７とサーバ５８がおこなう鍵共有通信は、クラスブレークの危険がなく、さらにＰＦＳを実現するものでありながら、鍵共有通信におけるネットワーク負荷および処理負荷を低減できる。
【００６８】
［第３の実施形態］
次に、第３の実施形態のデータ通信装置におけるデータ通信方法について図１０を用いて説明する。図１０は、第３の実施形態のデータ通信装置におけるデータ通信方法の一例を示す図である。
【００６９】
第３の実施形態は、第１の実施形態の鍵共有通信方式をもとにしたＴＬＳタイプのハンドシェークプロトコルである。
データ通信装置１０１とデータ通信装置１０２は、有線または無線により通信可能に接続し、相互にデータ通信をおこなう。データ通信装置１０１とデータ通信装置１０２は、直接に接続してもよいし、１または２以上の中継装置を介してマルチホップに接続してもよい。データ通信装置１０２は、データ通信装置１０１にとって他のデータ通信装置であり、またデータ通信装置１０１は、データ通信装置１０２にとって他のデータ通信装置である。
【００７０】
データ通信装置１０１は、第１の乱数受信部１０３と、第２の乱数送信部１０４と、完了メッセージ受信部１０５と、完了メッセージ確認部１０６とを備える。第１の乱数受信部１０３は、データ通信装置１０２から第１の暗号１１８を受信する。なお、第１の暗号１１８は、通信路中において不正に書き換えられていなければ、データ通信装置１０２が送信する第１の暗号１０９と同じである。データ通信装置１０２は、第１の乱数１０８を生成し、第１の乱数１０８を第１の公開鍵１０７を用いて第１の暗号１０９に暗号化して、データ通信装置１０１に第１の暗号１０９を送信する（図示しない第１の乱数送信部に相当）。
【００７１】
第２の乱数送信部１０４は、第１の暗号１１８から第１の秘密鍵１１７を用いて第１の乱数１１９を復号する。第２の乱数送信部１０４は、第２の乱数１２１を生成する。第２の乱数送信部１０４は、第２の公開鍵１２０を用いて第１の乱数１１９と第２の乱数１２１を第２の暗号１２２に暗号化する。第２の乱数送信部１０４は、第２の暗号１２２をデータ通信装置１０２に送信する。なお、第２の暗号１１１は、通信路中において不正に書き換えられていなければ、データ通信装置１０１が送信する第２の暗号１２２と同じである。データ通信装置１０２は、第２の暗号１１１を受信する（図示しない第２の乱数受信部に相当）。データ通信装置１０２は、第２の公開鍵１２０と対になる第２の秘密鍵１１０を用いて第１の乱数１１２と第２の乱数１１３を復号する。データ通信装置１０２は、第１の乱数１０８と第１の乱数１１２を比較する。データ通信装置１０２は、第１の乱数１０８と第１の乱数１１２が一致する場合に第１の乱数１０８と第２の乱数１１３とからセッション鍵１１４を生成する。データ通信装置１０２は、セッション鍵１１４を用いて完了メッセージ１１５を暗号化し、第３の暗号１１６を得る。なお、完了メッセージ１１５は、データ通信装置１０２がデータ通信装置１０１にセッション確立の完了を通知するメッセージである。データ通信装置１０２は、データ通信装置１０１に第３の暗号１１６を送信する（図示しない完了メッセージ送信部に相当）。
【００７２】
完了メッセージ受信部１０５は、第３の暗号１２４をデータ通信装置１０２から受信する。なお、第３の暗号１２４は、通信路中において不正に書き換えられていなければ、データ通信装置１０２が送信する第３の暗号１１６と同じである。
【００７３】
完了メッセージ確認部１０６は、第１の乱数１１９と第２の乱数１２１とからセッション鍵１２３を生成する。完了メッセージ確認部１０６は、セッション鍵１２３を用いて第３の暗号１２４を復号し、完了メッセージ１２５を得る。完了メッセージ確認部１０６は、完了メッセージ１２５を正しく復号することにより、データ通信装置１０２とセッション鍵を共有するセッション確立を確認する。
【００７４】
このようにして、データ通信装置１０１は、データ通信装置１０２が保持するセッション鍵１１４と共通のセッション鍵１２３を保持することができる。このような鍵共有通信において、データ通信装置１０１とデータ通信装置１０２は、３回の通信（３ウェイハンドシェーク）を実現している。また、データ通信装置１０１は、１回目の通信において第１の暗号１１８を受信し、２回目の通信において第２の暗号１２２を送信することから、３回の通信における公開鍵暗号のデータ数は、「２」である。また、公開鍵暗号の処理回数は、データ通信装置１０１とデータ通信装置１０２のそれぞれにおいて「２」であり、データ通信装置１０１とデータ通信装置１０２とで「４」である。また、このような鍵共有通信において、データ通信装置１０１は、クラスブレークの危険性を有さず、ＰＦＳを実現する。すなわち、データ通信装置１０１は、データ通信装置１０２との通信方法において、鍵共有通信におけるネットワーク負荷および処理負荷を低減できる。
【００７５】
したがって、第３の実施形態の鍵共有通信方式は、第１の実施形態および第２の実施形態の鍵共有通信方式と同等の性能を有する。
また、第３の実施形態の鍵共有通信方式は、クライアント５７とサーバ５８とで同じ種類の処理をおこなうため、端末装置４０がクライアント５７とサーバ５８の両機能の実現が要求されるメッシュネットワークに適している。
【００７６】
［第４の実施形態］
次に、第３の実施形態の鍵共有通信方式をセンサネットワークに適用した第４の実施形態について説明する。センサネットワーク３０の構成や端末装置４０の機能構成、ハードウェア構成は、第２の実施形態と同様であるため説明を省略する。また、第２の実施形態と同様の構成については、符号を同じにして説明を省略する。
【００７７】
まず、第４の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスについて、図１１を用いて説明する。図１１は、第４の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスの一例を示す図である。
【００７８】
第４の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信シーケンスは、クライアント５７がサーバ５８に対して証明書を送付することを要しないので、第２の実施形態と同様にサーバ５８からの通信となる。
【００７９】
［ステップＳ５１］サーバ５８は、クライアント５７のＩＤベース公開鍵で乱数Ｒｓを暗号化した暗号Ｅ（Ｒｓ）を、クライアント５７に送信する。乱数Ｒｓは、サーバ５８が生成する乱数である。
【００８０】
［ステップＳ５２］クライアント５７は、サーバ５８のＩＤベース公開鍵で乱数Ｒｃと乱数Ｒｓの結合値（Ｒｓ｜｜Ｒｃ）を暗号化した暗号Ｅ（Ｒｓ｜｜Ｒｃ）を、サーバ５８に送信する。乱数Ｒｃは、クライアント５７が生成する乱数である。
【００８１】
［ステップＳ５３］サーバ５８は、サーバ５８の秘密鍵で暗号Ｅ（Ｒｓ｜｜Ｒｃ）を復号し、復号した結合値（Ｒｓ｜｜Ｒｃ）から取り出した乱数Ｒｃと、乱数Ｒｓとからセッション鍵を生成する。サーバ５８は、セッション鍵を用いて完了メッセージを暗号化した暗号Ｅ（完了ｍｓｇ）を、クライアント５７に送信する。
【００８２】
クライアント５７は、乱数Ｒｃと乱数Ｒｓとからセッション鍵を生成し、セッション鍵で暗号Ｅ（完了ｍｓｇ）を復号し、完了メッセージが正しく復号されることにより、サーバ５８とセッション鍵を共有するセッション確立を確認する。
【００８３】
以上、ステップＳ５１からステップＳ５３が３回の鍵共有通信からなるハンドシェークフェーズである。以降、クライアント５７とサーバ５８は、それぞれが乱数Ｒｃと乱数Ｒｓとから生成するセッション鍵を用いてデータ通信（Ｄａｔａ通信）をおこなう（ステップＳ５４）。ステップＳ５４以降は、保護されたデータ通信が可能なデータ転送フェーズである。
【００８４】
次に、クライアント５７とサーバ５８がおこなう各処理について図１２から図１４を用いて説明する。まず、ハンドシェークフェーズにおけるサーバ側端末装置の処理について図１２を用いて説明する。図１２は、第４の実施形態のハンドシェークフェーズにおけるサーバ側端末装置の処理の一例を示す図である。
【００８５】
［ステップＳ６１］サーバ５８は、所定の乱数生成アルゴリズムにしたがい乱数Ｒｓ１３０を生成する。
［ステップＳ６２］サーバ５８は、クライアント５７の公開鍵としてＩＤベースの公開鍵であるＣｌｉｅｎｔＩＤ１３１を取得する。ＣｌｉｅｎｔＩＤ１３１は、たとえば、クライアント５７の通信アドレスである。ＣｌｉｅｎｔＩＤ１３１は、サーバ５８にとって既知の情報であり、たとえば、サーバ５８の記憶部４６が保持する情報である。そのため、サーバ５８は、クライアント５７からＣｌｉｅｎｔＩＤ１３１を取得することを要さない。
【００８６】
［ステップＳ６３］サーバ５８は、ＣｌｉｅｎｔＩＤ１３１を用いて乱数Ｒｓ１３０を暗号化して暗号Ｅ（Ｒｓ）１３２を得る。
［ステップＳ６４］サーバ５８は、暗号Ｅ（Ｒｓ）１３２をクライアント５７に送信する。
【００８７】
［ステップＳ６５］サーバ５８は、暗号Ｅ（Ｒｓ｜｜Ｒｃ）１３３をクライアント５７から受信する。暗号Ｅ（Ｒｓ｜｜Ｒｃ）１３３は、クライアント５７がサーバ５８の公開鍵で乱数Ｒｓと乱数Ｒｃの結合値を暗号化した情報である。
【００８８】
［ステップＳ６６］サーバ５８は、サーバ５８の公開鍵と対となる秘密鍵であるサーバ秘密鍵１３４を取得する。サーバ秘密鍵１３４は、サーバ５８にとって既知の情報であり、たとえば、サーバ５８の記憶部４６が保持する情報である。
【００８９】
［ステップＳ６７］サーバ５８は、サーバ秘密鍵１３４で暗号Ｅ（Ｒｓ｜｜Ｒｃ）１３３を復号し、結合値（Ｒｓ，Ｒｃ）１３５を得る。
［ステップＳ６８］サーバ５８は、結合値（Ｒｓ，Ｒｃ）１３５から乱数Ｒｓ１３６と乱数Ｒｃ１３７を抽出する。結合値（Ｒｓ，Ｒｃ）１３５は、乱数Ｒｓ１３６と乱数Ｒｃ１３７を並べた情報である。
【００９０】
［ステップＳ６９］サーバ５８は、乱数Ｒｓ１３０と乱数Ｒｓ１３６を照合し、照合結果１３８を得る。サーバ５８は、照合結果１３８が失敗の場合にクライアント５７とのセッション確立に失敗したと判断する。一方、サーバ５８は、照合結果１３８が成功の場合にステップＳ７０にすすむ。
【００９１】
［ステップＳ７０］サーバ５８は、乱数Ｒｓ１３０と乱数Ｒｃ１３７とにもとづいて所定の鍵生成アルゴリズムにしたがいセッション鍵１３９を生成する。
［ステップＳ７１］サーバ５８は、セッション鍵１３９を用いて完了ｍｓｇ（完了メッセージ）を暗号化し、暗号Ｅ（完了ｍｓｇ）１４０を得る。なお、完了メッセージは、サーバ５８がクライアント５７にセッション確立の完了を通知するメッセージである。
【００９２】
［ステップＳ７２］サーバ５８は、クライアント５７に暗号Ｅ（完了ｍｓｇ）１４０を送信する。
次に、ハンドシェークフェーズにおけるクライアント側端末装置の処理について図１３を用いて説明する。図１３は、第４の実施形態のハンドシェークフェーズにおけるクライアント側端末装置の処理の一例を示す図である。
【００９３】
［ステップＳ８１］クライアント５７は、暗号Ｅ（Ｒｓ）１４１をサーバ５８から受信する。なお、暗号Ｅ（Ｒｓ）１４１は、通信路中において不正に書き換えられていなければ、サーバ５８が送信する暗号Ｅ（Ｒｓ）１３２と同じである。
【００９４】
［ステップＳ８２］クライアント５７は、クライアント５７の公開鍵（ＣｌｉｅｎｔＩＤ１３１）と対となる秘密鍵であるクライアント秘密鍵１４２を取得する。クライアント秘密鍵１４２は、クライアント５７にとって既知の情報であり、たとえば、クライアント５７の記憶部４６が保持する情報である。
【００９５】
［ステップＳ８３］クライアント５７は、クライアント秘密鍵１４２で暗号Ｅ（Ｒｓ）１４１を復号し、乱数Ｒｓ１４３を得る。
［ステップＳ８４］クライアント５７は、所定の乱数生成アルゴリズムにしたがい乱数Ｒｃ１４４を生成する。
【００９６】
［ステップＳ８５］クライアント５７は、サーバ５８の公開鍵としてＩＤベースの公開鍵であるＳｅｒｖｅｒＩＤ１４５を取得する。ＳｅｒｖｅｒＩＤ１４５は、たとえば、サーバ５８の通信アドレスである。ＳｅｒｖｅｒＩＤ１４５は、クライアント５７にとって既知の情報であり、たとえば、クライアント５７の記憶部４６が保持する情報である。そのため、クライアント５７は、サーバ５８からＳｅｒｖｅｒＩＤ１４５を取得することを要さない。
【００９７】
［ステップＳ８６］クライアント５７は、乱数Ｒｓ１４３と乱数Ｒｃ１４４を結合し、結合値（Ｒｓ，Ｒｃ）１４６を生成する。
［ステップＳ８７］クライアント５７は、ＳｅｒｖｅｒＩＤ１４５を用いて結合値（Ｒｓ，Ｒｃ）１４６を暗号化して暗号Ｅ（Ｒｓ｜｜Ｒｃ）１４７を得る。
【００９８】
［ステップＳ８８］クライアント５７は、乱数Ｒｓ１４３と乱数Ｒｃ１４４とにもとづいてサーバ５８と同様の鍵生成アルゴリズムにしたがいセッション鍵１４８を生成する。
［ステップＳ８９］クライアント５７は、暗号Ｅ（Ｒｓ｜｜Ｒｃ）１４７をサーバ５８に送信する。
【００９９】
［ステップＳ９０］クライアント５７は、暗号Ｅ（完了ｍｓｇ）１４９をサーバ５８から受信する。なお、暗号Ｅ（完了ｍｓｇ）１４９は、通信路中において不正に書き換えられていなければ、サーバ５８が送信する暗号Ｅ（完了ｍｓｇ）１４０と同じである。
【０１００】
［ステップＳ９１］クライアント５７は、セッション鍵１４８で暗号Ｅ（完了ｍｓｇ）１４９を復号し、完了ｍｓｇ１５０を得る。
［ステップＳ９２］クライアント５７は、完了ｍｓｇ１５０が正しく復号されたことにより、サーバ５８とセッション鍵を共有するセッション確立を確認する。
【０１０１】
次に、データ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理について図１４を用いて説明する。図１４は、第４の実施形態のデータ転送フェーズにおけるサーバ側端末装置の処理とクライアント側端末装置の処理の一例を示す図である。
【０１０２】
クライアント５７とサーバ５８は、セッション鍵１４８（セッション鍵１３９）を用いて保護されたデータ通信をおこなう（ステップＳ１０１、ステップＳ１０２）。サーバ５８は、クライアント５７と正常なデータ通信をおこなえることを確認することにより認証とする。
【０１０３】
このように、クライアント５７とサーバ５８がおこなう鍵共有通信は、クライアント５７からサーバ５８への証明書の送付を不要にして、３ウェイハンドシェークを実現している。また、クライアント５７とサーバ５８がおこなう鍵共有通信は、公開鍵暗号処理回数が「４」であり、他の従来方式と比較して十分に小さく、公開鍵暗号データ数が「２」であり、他の従来方式と比較して十分に小さい。また、クライアント５７とサーバ５８がおこなう鍵共有通信は、クラスブレークの危険がなく、さらにＰＦＳを実現するものでありながら、鍵共有通信におけるネットワーク負荷および処理負荷を低減できる。
【０１０４】
［第５の実施形態］
次に、第４の実施形態の鍵共有通信方式を、ＴＬＳのハンドシェークプロトコルに適用した第５の実施形態の鍵共有通信方式について図１５を用いて説明する。図１５は、第５の実施形態のサーバ側端末装置とクライアント側端末装置との鍵共有通信の一例を示す図である。
【０１０５】
２つの端末装置４０の一方がクライアント（クライアント側端末装置）５７であり、他方がサーバ（サーバ側端末装置）５８である。
［ステップＳ１１１］クライアント５７は、ＣｌｉｅｎｔＨｅｌｌｏメッセージをサーバ５８に送信する。なお、ＣｌｉｅｎｔＨｅｌｌｏメッセージは、証明書の送付を要するものではなく、形式的にＴＬＳのハンドシェークプロトコルに適合させるものであることから、鍵共有通信にカウントしない。
【０１０６】
［ステップＳ１１２］サーバ５８は、ＳｅｒｖｅｒＨｅｌｌｏメッセージをクライアント５７に送信する。
［ステップＳ１１３］サーバ５８は、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージをクライアント５７に送信する。サーバ５８は、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージに、第４の実施形態で説明した暗号Ｅ（Ｒｓ）１３２を含ませることができる。
【０１０７】
［ステップＳ１１４］サーバ５８は、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージをクライアント５７に送信する。なお、このステップＳ１１２のＳｅｒｖｅｒＨｅｌｌｏメッセージからステップＳ１１４のＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージまでを一連のメッセージとすることができるので、鍵共有通信の１回（１回目）にカウントする。
【０１０８】
［ステップＳ１１５］クライアント５７は、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージをサーバ５８に送信する。クライアント５７は、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージに、第４の実施形態で説明した暗号Ｅ（Ｒｓ｜｜Ｒｃ）１４７を含ませることができる。
【０１０９】
［ステップＳ１１６］クライアント５７は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージをサーバ５８に送信する。
［ステップＳ１１７］クライアント５７は、Ｆｉｎｉｓｈｅｄメッセージをサーバ５８に送信する。なお、このステップＳ１１５のＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージからステップＳ１１７のＦｉｎｉｓｈｅｄメッセージまでを一連のメッセージとすることができるので、鍵共有通信の１回（２回目）にカウントする。
【０１１０】
［ステップＳ１１８］サーバ５８は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージをクライアント５７に送信する。クライアント５７は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージに、第４の実施形態で説明した暗号Ｅ（完了ｍｓｇ）１４０を含ませることができる。
【０１１１】
［ステップＳ１１９］サーバ５８は、Ｆｉｎｉｓｈｅｄメッセージをクライアント５７に送信する。なお、このステップＳ１１８のＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージからステップＳ１１９のＦｉｎｉｓｈｅｄメッセージまでを一連のメッセージとすることができるので、鍵共有通信の１回（３回目）にカウントする。
【０１１２】
このようにして、第５の実施形態の鍵共有通信方式は、ＴＬＳのハンドシェークプロトコルに適合する３ウェイハンドシェークを実現することができる。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、データ通信装置１，２，１０１，１０２、端末装置４０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０１１３】
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１１４】
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。
【０１１５】
また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤなどの電子回路で実現することもできる。
以上の実施の形態に関し、更に以下の付記を開示する。
【０１１６】
（付記１）  第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信し、前記第１の暗号を第１の秘密鍵で復号し、
第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信し、
前記第１の乱数と第２の秘密鍵で復号された前記第２の乱数とから生成された第１のハッシュ値を前記他のデータ通信装置から受信し、前記第１の秘密鍵で復号した前記第１の乱数と前記生成した前記第２の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、
前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成する、
ことを特徴とするデータ通信方法。
【０１１７】
（付記２）  前記第１の公開鍵は、前記他のデータ通信装置の識別情報であり、
前記第２の公開鍵は、前記データ通信装置の識別情報である、
ことを特徴とする付記１記載のデータ通信方法。
【０１１８】
（付記３）  前記データ通信装置は、前記データ通信装置の記憶部に前記第１の公開鍵をあらかじめ保持し、
前記他のデータ通信装置は、前記他のデータ通信装置の記憶部に前記第２の公開鍵をあらかじめ保持する、
ことを特徴とする付記２記載のデータ通信方法。
【０１１９】
（付記４）  第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信する第１の乱数受信部と、
前記第１の暗号を第１の秘密鍵で復号し、第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信する第２の乱数送信部と、
前記第１の乱数と第２の秘密鍵で復号された前記第２の乱数とから生成された第１のハッシュ値を前記他のデータ通信装置から受信するハッシュ値受信部と、
前記第１の秘密鍵で復号した前記第１の乱数と前記生成した前記第２の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、
前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成するセッション鍵生成部と、
を備えることを特徴とするデータ通信装置。
【０１２０】
（付記５）  第１のデータ通信装置と第２のデータ通信装置とのデータ通信方法において、
前記第１のデータ通信装置は、
第１の乱数を生成し、前記第１の乱数を第１の公開鍵で暗号化した第１の暗号を前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
前記第１のデータ通信装置から受信した前記第１の暗号から第１の秘密鍵で前記第１の乱数を復号し、第２の乱数を生成して、前記第２の乱数を第２の公開鍵で暗号化した第２の暗号を前記第１のデータ通信装置に送信し、
前記第１のデータ通信装置は、
前記第２のデータ通信装置から受信した前記第２の暗号から第２の秘密鍵で前記第２の乱数を復号し、生成した前記第１の乱数と復号した前記第２の乱数とから第１のハッシュ値を生成して前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
生成した前記第２の乱数と復号した前記第１の乱数とから生成した第２のハッシュ値と、前記第１のハッシュ値とを比較し、前記第１のハッシュ値と前記第２のハッシュ値とが同じである場合に、前記第１の乱数と前記第２の乱数とにもとづいてセッション鍵を生成する、
ことを特徴とするデータ通信方法。
【０１２１】
（付記６）  第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信し、前記第１の暗号を第１の秘密鍵で復号し、
第２の乱数を生成して、前記第２の乱数と前記復号した前記第１の乱数とを第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信し、
前記他のデータ通信装置が生成した前記第１の乱数と復号した前記第１の乱数とが同じである場合に前記第１の乱数と前記第２の乱数とから生成されたセッション鍵で暗号化された完了メッセージを受信し、
前記復号した前記第１の乱数と前記生成した前記第２の乱数とから前記セッション鍵を生成し、受信した前記セッション鍵で暗号化された完了メッセージを前記セッション鍵で復号して前記他のデータ通信装置との前記セッション鍵の共有を確認する、
ことを特徴とするデータ通信方法。
【０１２２】
（付記７）  前記第１の公開鍵は、前記他のデータ通信装置の識別情報であり、
前記第２の公開鍵は、前記データ通信装置の識別情報である、
ことを特徴とする付記６記載のデータ通信方法。
【０１２３】
（付記８）  前記データ通信装置は、前記データ通信装置の記憶部に前記第１の公開鍵をあらかじめ保持し、
前記他のデータ通信装置は、前記他のデータ通信装置の記憶部に前記第２の公開鍵をあらかじめ保持する、
ことを特徴とする付記７記載のデータ通信方法。
【０１２４】
（付記９）  第１の乱数が第１の公開鍵で暗号化された第１の暗号を他のデータ通信装置から受信する第１の乱数受信部と、
前記第１の暗号を第１の秘密鍵で復号し、第２の乱数を生成して、前記第２の乱数と前記復号した前記第１の乱数とを第２の公開鍵で暗号化した第２の暗号を前記他のデータ通信装置に送信する第２の乱数送信部と、
前記他のデータ通信装置が生成した前記第１の乱数と復号した前記第１の乱数とが同じである場合に前記第１の乱数と前記第２の乱数とから生成されたセッション鍵で暗号化された完了メッセージを受信する完了メッセージ受信部と、
前記復号した前記第１の乱数と前記生成した前記第２の乱数とから前記セッション鍵を生成し、受信した前記セッション鍵で暗号化された完了メッセージを前記セッション鍵で復号して前記他のデータ通信装置との前記セッション鍵の共有を確認する完了メッセージ確認部と、
を備えることを特徴とするデータ通信装置。
【０１２５】
（付記１０）  第１のデータ通信装置と第２のデータ通信装置とのデータ通信方法において、
前記第１のデータ通信装置は、
第１の乱数を生成し、前記第１の乱数を第１の公開鍵で暗号化した第１の暗号を前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
前記第１のデータ通信装置から受信した前記第１の暗号から第１の秘密鍵で前記第１の乱数を復号し、第２の乱数を生成して、前記第１の乱数と前記第２の乱数とを第２の公開鍵で暗号化した第２の暗号を前記第１のデータ通信装置に送信し、
前記第１のデータ通信装置は、
前記第２のデータ通信装置から受信した前記第２の暗号から第２の秘密鍵で前記第１の乱数と前記第２の乱数とを復号し、生成した前記第１の乱数と復号した前記第１の乱数とが同じである場合に前記第１の乱数と前記第２の乱数とからセッション鍵を生成し、完了メッセージを前記セッション鍵で暗号化した第３の暗号を前記第２のデータ通信装置に送信し、
前記第２のデータ通信装置は、
復号した前記第１の乱数と生成した前記第２の乱数とから前記セッション鍵を生成し、受信した前記第３の暗号を前記セッション鍵で復号して、前記第１のデータ通信装置との前記セッション鍵の共有を確認する、
ことを特徴とするデータ通信方法。
【符号の説明】
【０１２６】
１，２，１０１，１０２  データ通信装置
３，１０３  第１の乱数受信部
４，１０４  第２の乱数送信部
５  ハッシュ値受信部
６  セッション鍵生成部
３０  センサネットワーク
３１  ゲートウェイ
３２  ネットワーク
４０  端末装置
５７  クライアント
５８  サーバ
１０５  完了メッセージ受信部
１０６  完了メッセージ確認部
【図１】
2015126485.tif 000003
【図２】
2015126485.tif 000004
【図３】
2015126485.tif 000005
【図４】
2015126485.tif 000006
【図５】
2015126485.tif 000007
【図６】
2015126485.tif 000008
【図７】
2015126485.tif 000009
【図８】
2015126485.tif 000010
【図９】
2015126485.tif 000011
【図１０】
2015126485.tif 000012
【図１１】
2015126485.tif 000013
【図１２】
2015126485.tif 000014
【図１３】
2015126485.tif 000015
【図１４】
2015126485.tif 000016
【図１５】
2015126485.tif 000017