JPWO2009090722A1 - バインディング更新方法及びその方法で用いられる移動端末 - Google Patents

バインディング更新方法及びその方法で用いられる移動端末 Download PDF

Info

Publication number
JPWO2009090722A1
JPWO2009090722A1 JP2009549913A JP2009549913A JPWO2009090722A1 JP WO2009090722 A1 JPWO2009090722 A1 JP WO2009090722A1 JP 2009549913 A JP2009549913 A JP 2009549913A JP 2009549913 A JP2009549913 A JP 2009549913A JP WO2009090722 A1 JPWO2009090722 A1 JP WO2009090722A1
Authority
JP
Japan
Prior art keywords
message
mobile terminal
terminal
token
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2009549913A
Other languages
English (en)
Inventor
森本　哲郎
哲郎 森本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2009090722A1 publication Critical patent/JPWO2009090722A1/ja
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/082—Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

必要なメッセージ数を減少させることにより、端末の消費電力を削減でき、両端末のバインディングアップデートにかかる処理時間を短縮できるバインディング更新方法などを提供する技術が開示され、その技術によれば第１の移動端末が所定の第１移動端末情報を含めた、所定の第２移動端末情報の取得のための第１の１組のメッセージを第２の移動端末へ送信し、第２の移動端末が所定の第２移動端末情報を含めた第２の１組のメッセージを送信し、第１の移動端末が、所定の第２移動端末情報に基づき生成した認証情報を付加した第３のメッセージを送信し、第２の移動端末が第３のメッセージへの応答情報を含めた、所定の第１移動端末情報に基づき生成した認証情報を付加した第４のメッセージを送信し、第１の移動端末からの認証情報が正当である場合にバインディング情報を更新し、第１の移動端末が第２の移動端末からの認証情報が正当である場合にバインディング情報を更新する。

Description

本発明は、バインディングアップデートにより経路の最適化がなされた通信端末間のバインディングを更新するバインディング更新方法及びその方法で用いられる移動端末に関する。
従来から、通信装置が移動しても移動前と同じＩＰアドレスを使い続けることができる技術としてモバイルＩＰが存在する。モバイルＩＰでは、ホームエージェント（home agent）が移動通信装置（mobile node）のホームアドレス（home address）あてのパケットを受信し、移動通信装置の気付アドレス（ＣｏＡ：Care-of Address）に転送する。このため、移動通信装置は移動に伴うアドレス変更によらず、ホームアドレスを用いた通信を継続できる。
また、パケットがホームエージェントを経由することによって移動通信装置と通信相手装置（ＣＮ：correspondent node）の通信経路が遠回りになることを改善するために、移動通信装置と通信相手装置の通信経路を直接結ぶ経路最適化（Route Optimization）技術が存在する。この経路最適化技術は、通信相手装置に移動通信装置のホームアドレスと気付アドレスの対応関係を記憶させることによって、気付アドレスを用いて通信することを特徴とする。この通信相手装置に移動通信装置のホームアドレスと気付アドレスの対応関係を記憶させる処理は、バインディング更新処理（ＢＵ：Binding Update）と呼ばれている。
通信相手装置に対するバインディング更新処理では、ホームエージェントに対するバインディング更新処理とは異なり、バインディング更新前処理（ＲＲ：Return Routability Procedure）を必要としている。ホームエージェントと移動通信装置との間では、信頼関係をあらかじめ築いておくことができるため、このバインディング更新前処理を必要としない。ホームエージェントに対するバインディング更新処理においては、移動通信装置がホームエージェントにホームアドレスに対する新しい気付アドレスを通知したとき、ホームエージェントは、事前に確立しておいた信頼関係（ＩＰｓｅｃ ＳＡなど）によって移動通信装置からのバインディング更新要求であることを確認することができる。
一方、通信相手装置の場合、すべての通信相手となる可能性のある通信装置に対して、バインディング更新処理を行う前に、移動通信装置と通信相手装置との間にあらかじめ信頼関係を確立しておくことは困難である。もし、信頼関係がない状態で通信相手装置がバインディング更新の要求に従ってしまうならば、移動通信装置に成りすました攻撃が容易になる。そして、攻撃者が通信相手装置にバインディング更新処理を行うと、移動通信装置へのパケットを不正な気付アドレスに転送させることが可能になる。これを防ぐ技術がバインディング更新前処理である。
具体的には、バインディング更新前処理では、ホームアドレステスト処理（Home Test）、気付アドレステスト処理（Care-of Test）を行う。これらの処理の結果をバインディング更新処理に反映させることによって、不正なバインディング更新処理を防いでいる。なお、従来技術として説明した、モバイルＩＰ、経路最適化、バインディング更新前処理については、後述する非特許文献１に記載されている。また、バインディング更新前処理の設計思想については、後述する非特許文献２に記載されている。
バインディング更新前処理についてもう少し詳しく説明する。ホームアドレステスト処理では、移動通信装置はＨｏＴＩ（Home Test Init）メッセージを通信相手装置に送信し、通信相手装置はＨｏＴ（Home Test）メッセージを返す。また、気付アドレステスト処理では、移動通信装置はＣｏＴＩ(Care-of Test Init)メッセージを通信相手装置に送信し、通信相手装置はＣｏＴ(Care-of Test)メッセージを返す。
移動通信装置は、通信相手装置から応答として返されたＨｏＴメッセージ及びＣｏＴメッセージに含まれるHome keygen token（Home token）、Care-of keygen token（Care-of token）をもとに鍵を生成し、その鍵でバインディング更新（ＢＵ）メッセージのメッセージ認証コード（ＭＡＣ:Message Authentication Code）を計算し、ＢＵメッセージに付加して送信する。
ＢＵメッセージを受信した通信相手装置は、メッセージ認証コードを確認することによって、移動通信装置から送信された正当なＢＵメッセージであると判断する。バインディング更新前処理の設計思想を説明している非特許文献２によると、このバインディング更新前処理は、通信相手装置がState（状態）を持つ必要がないように設計されている。つまり、ＨｏＴＩメッセージを受信したことがあるかどうか、ＣｏＴＩメッセージを受信したことがあるかどうかを、通信相手装置は記憶しておかなくてもＢＵメッセージの認証処理を行うことができる。
これは、攻撃者がＨｏＴＩメッセージやＣｏＴＩメッセージを用いて通信相手装置に対してＤｏＳ攻撃（Denial of Service Attack）を行った場合に、通信相手装置の被害を小さくするためである。また、ＨｏＴＩメッセージに対してＨｏＴメッセージを返す、ＣｏＴＩメッセージに対してＣｏＴメッセージを返す、というように１つの要求メッセージに対して１つの応答メッセージを返すようにしているのは、メッセージの増加（Amplification）を行わないようにするためである。これは、要求メッセージを１つ送ったときに、複数の応答メッセージを返す仕組みにした場合、攻撃者は１つのメッセージを送ることによって、複数のターゲットを攻撃することが可能になるためである。
"Mobility Support in IPv6"，RFC3775 "Mobile IP Version 6 Route Optimization Security Design Background",RFC4225
しかしながら、上記従来技術のＭＩＰｖ６では移動端末どうしがお互いにバインディングアップデートを行っているときに、その状況を効率的に利用できないという課題があった。つまり、従来の移動通信装置は、通信相手装置が自身に対してバインディングアップデートを行っている場合であっても、処理の効率化を目的としてバインディングアップデートの処理手順を変えることができなかった。
また、移動通信装置と通信相手装置が最適化経路を用いた通信を継続するためには、双方ともバインディングキャッシュを継続するために、定期的（７分ごと）にバインディングアップデートを行わなければならない。一方の装置（端末）のバインディングキャッシュを継続するだけでは不十分である。しかしながら、従来技術では、それぞれの装置が独立にバインディングアップデートを行うことしかできなかった。
具体的には、図１９Ａ、Ｂに示すように、端末Ａ（ＭＮ＿Ａ）と端末Ｂ（ＭＮ＿Ｂ）はそれぞれ独立に７分ごとにこのバインディングアップデートの処理を行い、相手端末に通知したバインディングキャッシュ（ホームアドレスと気付アドレスの情報）の寿命（Life Time）を更新していた。これにより、メッセージ数が多くなってしまう。
本発明は、上記の問題点に鑑み、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できるバインディング更新方法及びその方法で用いられる移動端末を提供することを目的とする。
上記目的を達成するために、本発明によれば、第１の移動端末と、前記第１の移動端末の通信相手である第２の移動端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法であって、前記第１の移動端末が前記第２の移動端末のバインディング情報を保持している場合に、前記第１の移動端末が、所定の第１移動端末情報を含めたメッセージであって、前記第２の移動端末から所定の第２移動端末情報を取得するための第１の１組のメッセージを前記第２の移動端末へ送信するステップと、前記第２の移動端末が、前記所定の第２移動端末情報を含めた第２の１組のメッセージを前記第１の移動端末へ送信するステップと、前記第１の移動端末が、前記第２の１組のメッセージに含まれた前記所定の第２移動端末情報に基づいて生成された認証情報を付加した第３のメッセージを前記第２の移動端末へ送信するステップと、前記第２の移動端末が、前記第３のメッセージに対する応答情報を含めたメッセージであって、前記所定の第１移動端末情報に基づいて生成された認証情報を付加した第４のメッセージを前記第１の移動端末へ送信するとともに、前記第１の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップと、前記第１の移動端末が、前記第４のメッセージに付加された前記第２の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップとを、有するバインディング更新方法が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明のバインディング更新方法において、前記第２の移動端末が、前記所定の第１移動端末情報を前記第２の１組のメッセージに含めて前記第１の移動端末へ送信し、
前記第１の移動端末は、前記第２の１組のメッセージに含まれる前記所定の第１移動端末情報を前記第３のメッセージに含めて前記第２の移動端末へ送信することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明のバインディング更新方法において、前記第２の移動端末が、前記所定の第１移動端末情報を前記第２の移動端末のみが復号できる形式で前記第２のメッセージに含めて送信することは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明のバインディング更新方法において、前記所定の第１移動端末情報は、前記第２の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の第２移動端末情報は、前記第１の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージは、前記第２の移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージは、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージは、前記第２の移動端末へのバインディングアップデートメッセージであり、前記第４のメッセージは、前記第１の移動端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
また、本発明によれば、移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、前記移動端末が前記通信相手端末のバインディング情報を保持している場合に、所定の移動端末情報を含めたメッセージであって、前記通信相手端末から所定の通信相手端末情報を取得するための第１の１組のメッセージを生成するメッセージ生成手段と、生成された前記第１の１組のメッセージを前記通信相手端末へ送信する送信手段と、前記所定の通信相手端末情報を含めた第２の１組のメッセージを前記通信相手端末から受信する受信手段と、受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、前記バインディング情報を更新する更新手段とを備え、前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信し、前記更新手段が、前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当であるか否かを判断し、正当である場合に前記バインディング情報を更新する移動端末が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明によれば、移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、所定の通信相手端末情報を含めたメッセージであって、前記移動端末から所定の移動端末情報を取得するための第１の１組のメッセージを受信する受信手段と、前記所定の移動端末情報を含めた第２の１組のメッセージを生成するメッセージ生成手段と、生成された前記第２の１組のメッセージを前記通信相手端末へ送信する送信手段と、前記受信手段を介して受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当である場合に前記バインディング情報を更新する更新手段とを備え、前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信する移動端末が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記第２の１組のメッセージに含まれる前記所定の移動端末情報を含めた前記第３のメッセージを生成することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記第１の１組のメッセージに含まれる前記所定の通信相手端末情報を含めた前記第２の１組のメッセージを生成することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第３のメッセージに含めることは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第２の１組のメッセージに含めることは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明の移動端末において、前記所定の移動端末情報が、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の通信相手端末情報が、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージが、前記通信相手端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージが、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージが、前記通信相手端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
また、本発明の移動端末において、前記所定の通信相手端末情報が、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の移動端末情報が、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージが、前記移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージが、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージが、前記通信相手端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
本発明のバインディング更新方法及びその方法で用いられる移動端末は、上記構成を有し、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
本発明の第１の実施の形態におけるメッセージ数の削減について説明するための図 本発明の第１の実施の形態におけるメッセージ数の削減について説明するための他の図 本発明の第１の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第１の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第２の実施の形態を説明するためのＭＩＰの基本原理について説明するための図 本発明の第２の実施の形態を説明するためのＭＩＰの基本原理について説明するための他の図 本発明の第２の実施の形態におけるメッセージ数の削減について説明するための図 本発明の第２の実施の形態についてさらに詳細に説明するための図 本発明の第２の実施の形態における両端末間での情報のやりとりの様子を示す図 本発明の第２の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第２の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第２の実施の形態における結合バインディングアップデートの開始側の移動端末の処理フローの一例を示すフローチャート 本発明の第２の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの一部を示すフローチャート 本発明の第２の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの他の一部を示すフローチャート 本発明の第３の実施の形態におけるメッセージ数の削減について説明するための他の図 本発明の第３の実施の形態における両端末間での情報のやりとりの様子を示す図 本発明の第３の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第３の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第３の実施の形態における結合バインディングアップデートの開始側の移動端末の処理フローの一例を示すフローチャート 本発明の第３の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの一部を示すフローチャート 本発明の第３の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの他の一部を示すフローチャート 従来の両端末間で行われるバインディングアップデートを説明するための図 従来の両端末間で行われるバインディングアップデートを説明するための他の図
＜第１の実施の形態＞
第１の実施の形態について説明する。図１Ａに示すような多くのメッセージ数を減らすため、図１Ｂに示すように、両端末が行うバインディングアップデートを同期させ、受信側の端末がメッセージを重ねて送信するよう構成した。
すなわち、図１Ｂに示すように、端末Ａから開始したバインディングアップデートの手順に、端末Ｂが同期してバインディングアップデートを行う（以降、結合バインディングアップデートとよぶ）。端末Ｂは、端末ＡからのＨｏＴＩに対してＨｏＴを応答として返すが、それと同時にＨｏＴＩを送信する。同様に、端末Ｂは端末ＡからのＣｏＴＩに対してＣｏＴを応答として返すと同時にＣｏＴＩを送信する。そして、端末Ｂは端末ＡからのＢＵに対して、ＢＡを応答として返すと同時にＢＵを送信する。このとき端末Ｂが送信するＨｏＴとＨｏＴＩを１つのメッセージにし、同様にＣｏＴとＣｏＴＩ、ＢＡとＢＵを１つのメッセージにすることによって、メッセージ数を削減することができる。
ここで、結合バインディングアップデートの開始側の移動端末（ここでは端末Ａ）について図２を用いて説明する。メッセージ生成部２０１は、通信相手端末（端末Ｂ）から情報Ｂ１、Ｂ２それぞれを取得するためのＨｏＴＩ、ＣｏＴＩメッセージそれぞれを生成する。送信部２０２は、生成されたＨｏＴＩ、ＣｏＴＩメッセージを端末Ｂへ送信する。受信部２０３は、情報Ｂ１を含むメッセージであって、情報Ａ１を取得するためのＨｏＴメッセージ、及び情報Ｂ２を含むメッセージあって、情報Ａ２を取得するためのＣｏＴメッセージを受信する。
認証情報生成部２０４は、情報Ｂ１、Ｂ２に基づいて認証コードをそれぞれ生成し、生成された認証コードは、送信部２０２によって端末Ｂへ送信される。更新部２０５は、受信部２０３を介して受信したコード情報であって、情報Ａ１、Ａ２に基づいて端末Ｂによって生成された認証コードが正当であるか否かを判断し、正当である場合にバインディング情報を更新する。記憶部２０６は、バインディングキャッシュなどの情報を格納する。
次に、結合バインディングアップデートの応答側の移動端末（ここでは端末Ｂ）について図３を用いて説明する。受信部３０１は、情報Ｂ１、Ｂ２を取得するためのＨｏＴＩ、ＣｏＴＩメッセージを端末Ａから受信する。メッセージ生成部３０２は、情報Ｂ１を含めたメッセージであって、端末Ａから情報Ａ１を取得するためのＨｏＴメッセージ、及び情報Ｂ２を含めたメッセージであって、端末Ａから情報Ａ２を取得するためのＣｏＴメッセージを生成する。
送信部３０３は、生成されたＨｏＴ、ＣｏＴメッセージを端末Ａへ送信する。認証情報生成部３０４は、受信部３０１を介して受信した情報Ｂ１、Ｂ２に基づいて認証コードを生成し、生成された認証コードは送信部３０３によって端末Ａに送信される。更新部３０５は、受信部３０１を介して受信した情報であって、情報Ｂ１、Ｂ２に基づいて端末Ａによって生成されたそれぞれの認証コードが正当であるか否かを判断し、正当である場合にバインディング情報を更新する。記憶部３０６は、バインディングキャッシュなどの情報を格納する。
＜第２の実施の形態＞
第２の実施の形態について説明する。まず、ＭＩＰの基本原理について説明する。図４には端末Ａからのバインディングアップデートの様子を示している。端末Ａは端末Ｂに気付アドレス（ＣｏＡ）が自身のアドレスであることを端末Ｂに証明しようとしている。そのため、端末Ｂに端末Ａのホームアドレス（ＨｏＡ）とＣｏＡにそれぞれメッセージを送信してもらい、その両方を受信したことを端末Ｂに示す。
簡単に説明すると、端末Ｂは端末ＡのＨｏＡあてに情報Ｂ１を送信し、端末ＡのＣｏＡあてに情報Ｂ２を送信する。端末ＡはＢ１とＢ２を用いて鍵データであるＫｅｙ（Ｂ１、Ｂ２）を生成し、その鍵データを用いて認証コードを生成する。端末Ｂは端末Ａからの認証コードを確認することによって、端末Ａが鍵データを正しく生成できたことを確認し、端末Ａが情報Ｂ１と情報Ｂ２を受信したと判定する。
より具体的に説明すると、端末ＡはＨｏＴＩを端末Ｂに送信し、情報Ｂ１をＨｏＴに含めて端末ＡのＨｏＡあてに送信させる。また、端末ＡはＣｏＴＩを端末Ｂに送信し、情報Ｂ２をＣｏＴに含めて端末ＡのＣｏＡあてに送信させる。そして、情報Ｂ１と情報Ｂ２を用いて鍵データであるＫｅｙ（Ａ１、Ａ２）を生成し、その鍵を用いて送信するＢＵメッセージの認証コードを生成し、認証コードをＢＵメッセージに付加して端末Ｂに送信する。端末Ｂは、ＢＵを受信するとＢ１とＢ２から鍵データを生成し、認証コードが正しいかどうか確認する。なお、図５は端末Ｂからのバインディングアップデートの様子を示している。
以上を踏まえて、上述した第１の実施の形態よりさらにメッセージ数を減らすことができる態様について図６を用いて説明する。この態様では、端末Ａが端末Ｂからの要求を受ける前に、端末ＢのＨｏＡに情報Ａ１を、ＣｏＡに情報Ａ２を送信する。これは、従来なら端末ＢからＨｏＴＩ、ＣｏＴＩメッセージを受信した後応答として返す情報である。しかし、端末Ａが端末Ｂのバインディングキャッシュを持っている場合、端末Ａは端末ＢのＨｏＡとＣｏＡを既に知っているため、図６に示すように、端末Ｂのバインディングアップデートの処理を端末Ａから開始することができる。
さらに、端末Ａは、端末Ｂに対するＨｏＴＩメッセージ６０１、ＣｏＴＩメッセージ６０３を用いて情報Ａ１と情報Ａ２を送信することによって、端末Ａのバインディングアップデートも同時に開始することができる。端末Ａは、端末Ｂからの応答メッセージであるＨｏＴメッセージ６０２、ＣｏＴメッセージ６０４を受信し、その応答メッセージに含まれる情報Ｂ１、Ｂ２を用いて鍵データ（Ｋｅｙ（Ｂ１、Ｂ２））を作成し、ＢＵメッセージ６０５を送信し、鍵データ（Ｋｅｙ（Ｂ１、Ｂ２））を生成できたことを示す。
端末Ｂは、そのＢＵメッセージ６０５を確認し、端末Ａのバインディングアップデートを承認するとともに、先に送られてきた情報Ａ１と情報Ａ２をもとに鍵データ（Ｋｅｙ（Ａ１、Ａ２））を生成し、ＢＵメッセージ６０５の応答としてＢＡメッセージ６０６を送る際に、端末Ｂが鍵データ（Ｋｅｙ（Ａ１、Ａ２））を生成できたことを示す。端末Ａは、そのＢＡメッセージ６０６を確認し、端末Ｂのバインディングアップデートを承認する。なお、端末Ａは承認完了の旨のメッセージ６０７を端末Ｂに送信するようにしてもよい。以上のように、本実施の形態の方法を用いることによって、第１の実施の形態と比較して、バインディングアップデートに要するメッセージ数を更に削減することができる。
ここで、第２の実施の形態をより詳細に説明する。端末Ａが端末Ｂからのバインディングアップデートを受け、端末ＢのホームアドレスＢ−ＨｏＡと気付アドレスＢ−ＣｏＡを知っている状態にあるとする。端末Ａは、端末Ｂにバインディングアップデートを行うとき、端末Ｂのバインディングキャッシュ情報を保持しているかどうかを確認する。保持していない場合には、通常のＭＩＰのバインディングアップデート処理を行う。一方、端末Ａが、端末Ｂのバインディングキャッシュ情報を保持している場合、図７に示すように、端末Ａと端末Ｂの両方のバインディングアップデートを同時に行うことを試みる。
端末Ａは、端末ＢのＨｏＡあてにＨｏＴＩを送信する。送信元アドレスは端末ＡのＨｏＡであり、端末Ｂからの応答メッセージＨｏＴは、この送信元アドレスである端末ＡのＨｏＡあてに送信される。メッセージＨｏＴＩには情報Ａ１が含まれる。端末Ｂは、ＨｏＴＩを受信すると、応答メッセージＨｏＴを端末Ａに送信する。端末ＢのＨｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＨｏＡであり、あて先アドレスは要求メッセージＨｏＴＩの送信元アドレスである端末ＡのＨｏＡである。
同様に、端末Ａは端末ＢのＣｏＡあてにＣｏＴＩを送信する。送信元アドレスは端末ＡのＣｏＡである。ＣｏＴＩメッセージには情報Ａ２が含まれる。端末Ｂは、ＣｏＴＩを受信すると、応答メッセージＣｏＴを端末Ａに送信する。端末ＢのＣｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＣｏＡであり、あて先アドレスは要求メッセージＣｏＴＩの送信元アドレスである端末ＡのＣｏＡである。
端末Ａは、応答メッセージのＨｏＴとＣｏＴに含まれる情報Ｂ１とＢ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＵメッセージに認証コードを付加して、端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信すると認証コードを確認し、端末Ａのバインディングキャッシュが正しいと判定し、寿命（Life Time）を延長する。また、端末Ｂは、応答メッセージであるＢＡを送信する際に、ＨｏＴＩとＣｏＴＩに含まれていた情報Ａ１とＡ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＡメッセージに認証コードを付加して、端末Ａに送信する。端末Ａは、ＢＡメッセージを受信すると認証コードを確認し、端末Ｂのバインディングキャッシュが正しいと判定し、寿命を延長する。
上述した様子について図８を用いて更に詳しく説明する。端末Ａは、ＨｏＴＩにA-Token-hを付加して端末Ｂに送信する。A-Token-hの生成方法は、原理的には任意でよく特に定める必要はない。しかし、従来技術のＭＩＰをできるだけ利用する方法として次のような生成方法が考えられる。
A-Token-h = HMAC SHA1 (B-HoA, A-Key, nonce)
なお、ここではトークン値の計算にハッシュ関数（HMAC SHA1）を用いる場合について述べるが、それ以外の関数あるいは生成式を用いるものであってもよい。
B-HoAとは端末Ｂのホームアドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがHome Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＨｏＴＩを受信しＨｏＴを応答として返す。ＨｏＴには、B-Token-h、B-nonce-hを含める。B-Token-hの計算方法は従来のＭＩＰとは異なる。従来のＭＩＰでは次のようにB-Token-hを計算した。
B-Token-h = HMAC SHA1 (A-HoA, B-Key, B-nonce-h)
本発明の方法では、次のように計算する。
B-Token-h = HMAC SHA1 (A-HoA, B-HoA, B-Key, B-nonce-h)
つまり、端末ＢのホームアドレスB-HoAを加えてB-Token-hを計算する。B-Token-hの計算に用いるA-HoAは、ＨｏＴＩメッセージの送信元アドレスであり、B-HoAはあて先アドレスである。また、ＨｏＴＩメッセージに含まれていたA-Token-hは、端末Ｂが保持する。例えば、端末Ａのバインディングキャッシュの中にHome Tokenを保持する領域を確保し、送信されてきた最新の値を保持するといった方法が考えられる。
端末Ａは、ＨｏＴＩの送信と並行してＣｏＴＩを送信してもよい。つまり、ＨｏＴを受信する前にＣｏＴＩを送信してよい。またＨｏＴＩの前にＣｏＴＩを送信してもよい。端末Ａは、ＣｏＴＩにA-Token-cを付加して端末Ｂに送信する。A-Token-cの生成方法は次のような方法が考えられる。
A-Token-c = HMAC SHA1 (B-CoA, A-Key, nonce)
B-CoAとは端末Ｂの気付アドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがCare-of Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＣｏＴＩを受信しＣｏＴを応答として返す。ＣｏＴには、B-Token-c、B-nonce-cを含める。B-Token-cの計算方法は従来のＭＩＰとは異なり、次のように計算する。
B-Token-c = HMAC SHA1 (A-CoA, B-CoA, B-Key, B-nonce-c)
つまり、端末Ｂの気付アドレスB-CoAを加えてB-Token-cを計算する。B-Token-cの計算にもちいるA-CoAは、ＣｏＴＩメッセージの送信元アドレスであり、B-CoAはあて先アドレスである。また、端末ＢはA-Token-cをA-Token-hと同様に保持しておく。端末Ａは、ＨｏＴＩメッセージの応答としてＨｏＴを受信し、ＣｏＴＩメッセージの応答としてＣｏＴを受信すると、それぞれのメッセージに含まれるB-Token-hとB-Token-cを用いて鍵データであるＫｅｙ Ｂを生成する。
Key B = HMAC SHA1 (B-Token-h, B-Token-c)
端末Ａはこの鍵データＫｅｙ Ｂを用いてＢＵメッセージの認証コードＢ−ＭＡＣを生成する。
B-MAC = HMAC SHA1 (Key B, BU message)
端末Ａは、ＢＵメッセージに次のデータのB-nonce-h、B-nonce-c、B-MAC、A-HoA、B-HoAを付加して端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信し、B-nonce-h、B-HoA、A-HoAを用いてB-Token-hを生成する。また、ＢＵメッセージの送信元アドレスA-CoA、あて先アドレスB-CoA、B-nonce-cを用いてB-Token-cを生成する。生成したB-Token-hとB-Token-cを用いてＫｅｙ Ｂを生成し、ＢＵメッセージに付加されているB-MACが正しいかどうか検査する。
Ｂ−ＭＡＣの検査結果が正しい場合には、端末Ｂは端末Ａのバインディングキャッシュの寿命の更新を行う。また新規の設定も可能である。一方、Ｂ−ＭＡＣの検査結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。また、端末Ｂは保持していた情報A-Token-hとA-Token-cを用いて次のように鍵データＫｅｙ Ａを生成する。
Key A = HMAC SHA1 (A-Token-h, A-Token-c)
端末Ｂはこの鍵データＫｅｙ Ａを用いてＢＡメッセージの認証コードＡ−ＭＡＣを生成する。
A-MAC = HMAC SHA1 (Key A, BA message)
端末Ｂは、ＢＡメッセージに、通常のＭＩＰと同様にＫｅｙ Ｂで生成した認証コードＢ−ＭＡＣを付加するとともに、新しいＫｅｙ Ａで生成した認証コードＡ−ＭＡＣを付加する。端末Ａは、ＢＡメッセージを受信し、Ｋｅｙ Ｂ及びＫｅｙ Ａを用いて認証コードを検証し、正しい場合には、端末Ｂのバインディングキャッシュの寿命の更新を行う。認証コードの検証結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。なお、上記ではＫｅｙ ＡとＫｅｙ Ｂを分ける場合で説明したが、合わせて一つの鍵データにしてもよい。例えば、次のように鍵データを生成してもよい。
Key AB = HMAC SHA1 (A-Token-h, A-Token-c, B-Token-h, B-Token-c)
次に、結合バインディングアップデートの開始側の移動端末について図９を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの送信について説明する。メッセージ作成部９０１は、結合バインディング判定部９０２に通常のバインディングアップデートか、結合バインディングアップデートかの判定を要求する。結合バインディング判定部９０２は、バインディングキャッシュ管理部９０３に、これからバインディングアップデートを行う相手端末からのバインディングキャッシュが登録されているかどうかを確認する。登録されていない場合には、通常のバインディングアップデートを行う。
結合バインディングアップデートを行う場合には、メッセージ作成部９０１はＡ−Ｔｏｋｅｎ生成部９０４にHome Token及びCare-of Tokenを生成させ、そのTokenを付加してＨｏＴＩメッセージ及びＣｏＴＩメッセージを生成し、メッセージ送信部９０５より送信する。Ａ−Ｔｏｋｅｎ生成部９０４で作成したHome Token及びCare-of TokenはＡ−Ｔｏｋｅｎ保存部９０６において保存しておく。
次に、ＨｏＴ／ＣｏＴの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージの応答メッセージであるＨｏＴ及びＣｏＴメッセージは、メッセージ受信部９０７によって受信される。受信したＨｏＴ及びＣｏＴに含まれる相手端末が生成したToken及びNonce-ID（応答側の移動端末がNonceの値を呼び出すための識別番号）はＢ−Ｔｏｋｅｎ保存部９０８及びＮｏｎｃｅ保存部９０９に保存される。
次に、ＢＵの送信について説明する。ＨｏＴメッセージとＣｏＴメッセージの両方を受信したとき、Ｂ−Ｔｏｋｅｎ保存部９０８にはHome TokenとCare-of Tokenの両方のTokenが揃っているため、それらのTokenを用いてＢ−Ｋｅｙ生成部９１０において鍵データを生成する。メッセージ認証コード生成部９１１は、Ｂ−Ｋｅｙ生成部９１０において生成された鍵データを用いてメッセージ認証コード（上述した認証コードに相当）を生成し、メッセージ作成部９０１に渡す。メッセージ作成部９０１では、生成されたメッセージ認証コードをＢＵメッセージに付加する。またＮｏｎｃｅ保存部９０９に保存しておいたNonce-IDもＢＵメッセージに付加する。そしてメッセージ送信部９０５よりＢＵメッセージを送信する。
次に、ＢＡの受信について説明する。ＢＡメッセージをメッセージ受信部９０７で受信し、メッセージ認証コード判定部９１２においてメッセージの判定を行う。メッセージの判定のために、Ａ−Ｋｅｙ生成部９１３は、Ａ−Ｔｏｋｅｎ保存部９０６に保存しておいたHome TokenとCare-of Tokenを取り出し、鍵データを生成する。メッセージ認証コード生成部９１１はＡ−Ｋｅｙ生成部９１３により生成された鍵データを用いてメッセージ認証コードを生成する。メッセージ認証コード判定部９１２は、その生成されたメッセージ認証コードと、ＢＵメッセージに付加されていたメッセージ認証コードを比較し、一致するかどうか判定する。
メッセージ認証コードが一致した場合に、バインディングキャッシュ管理部９０３にバインディングキャッシュを登録する。その後で、ＢＡメッセージに対する応答をメッセージ作成部９０１において作成し、メッセージ送信部９０５より送信する。
次に、結合バインディングアップデートの応答側の移動端末について図１０を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージをメッセージ受信部１００１で受信し、結合バインディングアップデートの場合には、メッセージに含まれるHome Token又はCare-of TokenをＡ−Ｔｏｋｅｎ保存部１００２に渡す。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１００３はB-Token（Home Token又はCare-of Token）を生成する。B-Tokenを生成するときに必要なNonce(home nonce又はcare-of nonce)はＮｏｎｃｅ管理部１００４より取得する。
B-Home Token = SHA1 (A-HoA, B-HoA, B-Key, B-home nonce)
B-Care-of Token = SHA1 (A-CoA, B-CoA, B-Key, B-care-of nonce)
次に、ＨｏＴ／ＣｏＴの送信について説明する。結合バインディングＢ−Ｔｏｋｅｎ生成部１００３より生成したToken及び生成に用いたNonceを呼び出すためのNonce-IDを取得し、応答メッセージに付加する。応答メッセージは受信メッセージがＨｏＴＩの場合にはＨｏＴメッセージであり、ＣｏＴＩの場合にはＣｏＴメッセージである。メッセージ作成部１００５が作成した応答メッセージは、メッセージ送信部１００６から送信される。
次に、ＢＵの受信について説明する。ＢＵメッセージをメッセージ受信部１００１で受信し、結合バインディングアップデートの場合には、結合バインディングＢ−Ｔｏｋｅｎ生成部１００３においてHome Token及びCare-of Tokenを生成する。Token生成のときには、受信したＢＵメッセージに含まれるNonce-IDを用いてＮｏｎｃｅ管理部１００４からNonceの値を取り出し、それを用いる。また、ＢＵメッセージに含まれるメッセージ認証コードをメッセージ認証コード比較部１００７に渡す。
結合バインディングＢ−Ｔｏｋｅｎ生成部１００３で生成したHome Token及びCare-of TokenをＢ−Ｋｅｙ生成部１００８に渡し、Ｂ−Ｋｅｙ生成部１００８において鍵データを生成する。そして、生成した鍵データを用いて、メッセージ認証コード生成部１００９において、メッセージ認証コードを生成する。生成したメッセージ認証コードとＢＵメッセージに含まれていたメッセージ認証コードが一致するかどうかをメッセージ認証コード比較部１００７で比較する。メッセージ認証コードが一致した場合は、バインディングキャッシュ管理部１０１１にバインディングキャッシュを設定又は更新する。
次に、ＢＡの送信について説明する。Ａ−Ｔｏｋｅｎ保存部１００２に保存しておいたTokenを用いてＡ−Ｋｅｙ生成部１０１０において鍵データを生成し、メッセージ認証コード生成部１００９でメッセージ認証コードを生成する。メッセージ作成部１００５は、生成されたメッセージ認証コードをＢＡメッセージに付加し、メッセージ送信部１００６よりＢＡメッセージを送信する。ＢＡメッセージに対する応答メッセージは、メッセージ受信部１００１で受信し、メッセージ認証コードを確認し、バインディングキャッシュ管理部１０１１においてバインディングキャッシュを更新する。
なお、上述したように、結合バインディングアップデートの開始側の移動端末と応答側の移動端末の構成が異なっているが、通常はすべての移動端末が開始側にも応答側にもなり得るため、移動端末は上述した開始側と応答側の機能それぞれを有することが好ましい。
次に、結合バインディングアップデートの開始側の移動端末の処理フローについて図１１を用いて説明する。図１１に示すように、移動端末は、バインディングアップデートを行おうとしている相手端末のバインディングキャッシュが存在しているかの確認処理を開始し（ステップＳ１１０１）、相手端末のバインディングキャッシュが存在しているか否かを判断する（ステップＳ１１０２）。バインディングキャッシュが存在する場合、移動端末は、相手端末のホームアドレスを用いたHome Token及び相手端末のＣｏＡを用いたCare-of Tokenを生成する（ステップＳ１１０３）。
そして、移動端末は、Home Tokenを含んだ結合バインディングアップデートのＨｏＴＩメッセージ、Care-of Tokenを含んだ結合バインディングアップデートのＣｏＴＩメッセージをそれぞれ送信する（ステップＳ１１０４）。移動端末は、応答メッセージのＨｏＴメッセージ、ＣｏＴメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１１０５）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１１０６）。
タイムアウト前に応答メッセージを受信した場合、移動端末はＢＵメッセージを生成する。すなわち、移動端末は、受信したＨｏＴ、ＣｏＴに含まれるTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、生成されたメッセージ認証コードを付加したＢＵメッセージを生成し、送信する（ステップＳ１１０７）。移動端末は、応答メッセージのＢＡメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１１０８）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１１０９）。
タイムアウト前に応答メッセージを受信した場合、移動端末は最初に送信したHome Token、Care-of Tokenから鍵データを生成し、ＢＡメッセージに含まれるメッセージ認証コードが正しいか否かの確認処理を開始する（ステップＳ１１１０）。メッセージ認証コードが正しいか否かを判断し（ステップＳ１１１１）、正しいと判断された場合、移動端末は、自身のバインディングキャッシュ及び相手端末のバインディングキャッシュの設定及び更新を行い、応答メッセージを送信する（ステップＳ１１１２）。
なお、ステップＳ１１０２において、バインディングキャッシュが存在しないと判断された場合には、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１１１３）。また、ステップＳ１１０６、Ｓ１１０９において、タイムアウト前に応答メッセージを受信できなかった場合、再送回数が所定の数値Ｎよりも小さければ再送を行う（ステップＳ１１１４、Ｓ１１１５）。また、ステップＳ１１１１において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの更新を行わないことを確認する（ステップＳ１１１６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（結合バインディングアップデートのメッセージの受信からそれに対する応答メッセージを送信するまで）について図１２Ａを用いて説明する。図１２Ａに示すように、移動端末は、ＨｏＴＩ又はＣｏＴＩを受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１２０１）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１２０２）、結合バインディングアップデートのメッセージである場合、受信した開始側の移動端末のHome Token又はCore-of Tokenを保持する（ステップＳ１２０３）。
移動端末は、Home Tokenの場合には両端末のホームアドレスを含め、Care-of Tokenの場合には両端末のＣｏＡを含めたTokenを生成する（ステップＳ１２０４）。生成されたTokenを付加して応答メッセージを生成し、応答メッセージを送信する（ステップＳ１２０５）。なお、ステップＳ１２０２において、結合バインディングアップデートのメッセージではないと判断された場合、移動端末は、従来のＭＩＰのバインディングアップデート処理として応答を送信する（ステップＳ１２０６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（ＢＵメッセージの受信からＢＡメッセージを送信するまで）について図１２Ｂを用いて説明する。図１２Ｂに示すように、移動端末は、ＢＵ（メッセージ）を受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１２１０）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１２１１）、結合バインディングアップデートのメッセージである場合、ＢＵに含まれるアドレス、Nonceの情報を用いてTokenを生成し、Tokenを用いて鍵データを生成し、付加されているメッセージ認証コードの確認処理を開始する（ステップＳ１２１２）。
移動端末は、メッセージ認証コードが正しいか否かを判断し（ステップＳ１２１３）、正しい場合には、バインディングキャッシュの設定、更新を行い、保持していた開始側の移動端末のTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、ＢＡメッセージに含めて送信する（ステップＳ１２１４）。なお、ステップＳ１２１１において、結合バインディングアップデートのメッセージでない場合、移動端末は、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１２１５）。また、ステップＳ１２１３において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの設定、更新を行わないことを確認する（ステップＳ１２１６）。
＜第３の実施の形態＞
第２の実施の形態と同様に、端末Ａが端末Ｂからのバインディングアップデートを受け、端末ＢのホームアドレスB-HoAと気付アドレスB-CoAを知っている状態にあるとする。端末Ａは、端末Ｂにバインディングアップデートを行うとき、端末Ｂのバインディングキャッシュ情報を保持しているかどうかを確認する。保持していない場合には、通常のＭＩＰのバインディングアップデート処理を行う。端末Ａが、端末Ｂのバインディングキャッシュ情報を保持している場合、端末Ａと端末Ｂの両方のバインディングアップデートを同時に行うことを試みる。なお、第３の実施の形態の説明においても、第２の実施の形態の説明で用いた図７を用いて説明する。
端末Ａは、端末ＢのＨｏＡあてにＨｏＴＩを送信する。送信元アドレスは端末ＡのＨｏＡであり、端末Ｂからの応答メッセージＨｏＴは、この送信元アドレスである端末ＡのＨｏＡあてに送信される。メッセージＨｏＴＩには情報Ａ１が含まれる。端末Ｂは、ＨｏＴＩを受信すると、応答メッセージＨｏＴを端末Ａに送信する。端末ＢのＨｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＨｏＡであり、あて先アドレスは要求メッセージＨｏＴＩの送信元アドレスである端末ＡのＨｏＡである。
同様に、端末Ａは、端末ＢのＣｏＡあてにＣｏＴＩを送信する。送信元アドレスは、端末ＡのＣｏＡである。ＣｏＴＩメッセージには情報Ａ２が含まれる。端末Ｂは、ＣｏＴＩを受信すると、応答メッセージＣｏＴを端末Ａに送信する。端末ＢのＣｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＣｏＡであり、あて先アドレスは要求メッセージＣｏＴＩの送信元アドレスである端末ＡのＣｏＡである。
端末Ａは、応答メッセージのＨｏＴとＣｏＴに含まれる情報Ｂ１とＢ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＵメッセージに認証コードを付加して、端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信すると認証コードを確認し、端末Ａのバインディングキャッシュが正しいと判定し、寿命（Life Time）を延長する。
そして、応答メッセージであるＢＡを送信する際に、ＨｏＴＩとＣｏＴＩに含まれていた情報Ａ１とＡ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＡメッセージに認証コードを付加して、端末Ａに送信する。端末Ａは、ＢＡメッセージを受信すると認証コードを確認し、端末Ｂのバインディングキャッシュが正しいと判定し、寿命を延長する。ここまでは第２の実施の形態で同様である。
次に第３の実施の形態におけるバインディング情報更新方式の特徴を説明する。端末Ａから２つの端末のバインディングアップデートを開始する場合、端末Ａから端末Ｂに情報Ａ１とＡ２を送り、端末Ｂに記憶させている。そのためセキュリティの観点から考えたとき、攻撃者が端末Ｂに異なる情報からなるＨｏＴＩ、ＣｏＴＩを大量に送りつけ、情報を覚えさせてメモリーを浪費させるという攻撃（ＤｏＳ攻撃）が想定される。これを防ぐために、端末ＢはＨｏＴＩメッセージ１３０１を受信し、情報Ａ１を取得するとその情報をＨｏＴメッセージ１３０２に含めて端末Ａに送り返すことも可能である。
その様子を図１３に示した。同様に、端末ＢはＣｏＴＩメッセージ１３０３を受信し、情報Ａ２をＣｏＴメッセージ１３０４に含めて端末Ａに送り返す。端末Ａは、送り返された情報Ａ１とＡ２をＢＵメッセージ１３０５に含めて端末Ｂに送信する。端末Ｂは、ＢＵメッセージ１３０５に含まれる情報Ａ１とＡ２を用いて鍵データであるＫｅｙ Ａ（Ａ１、Ａ２）を生成し、認証コードを作成する。そして、端末Ｂは生成されたＫｅｙ Ａ（Ａ１、Ａ２）をＢＡメッセージ１３０６に含めて端末Ａに送信する。なお、端末ＡはＫｅｙ Ａ（Ａ１、Ａ２）を確認し、端末Ｂのバインディングアップデートの承認をした場合、承認完了の旨のメッセージ１３０７を端末Ｂに送信するようにしてもよい。また、端末Ｂは、情報Ａ１及びＡ２を端末Ａに送り返すとき、署名、暗号化して送り返してもよい。署名を検証し、復号化してもとの情報に戻せるのは端末Ｂだけであるので、返送されるまでの間に改竄等される危険を防ぐことができるからである。
ここで、第３の実施の形態におけるメッセージシーケンスについて図１４を用いて詳しく説明する。端末Ａは、ＨｏＴＩにA-Token-hを付加して端末Ｂに送信する。A-Token-hの生成方法は、原理的には任意でよく特に定める必要はない。しかし、従来技術のＭＩＰをできるだけ利用する方法として、次のような生成方法が考えられる。
A-Token-h = HMAC SHA1 (B-HoA, A-Key, nonce)
B-HoAとは端末Ｂのホームアドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがHome Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＨｏＴＩを受信し、ＨｏＴを応答として返す。ＨｏＴにはB-Token-h、B-nonce-h、Sb(A-Token-h)を含める。B-Token-hの計算方法は従来のＭＩＰとは異なる。従来のＭＩＰでは次のようにB-Token-hを計算した。
B-Token-h = HMAC SHA1 (A-HoA, B-Key, B-nonce-h)
本発明の方法では、次のように計算する。
B-Token-h = HMAC SHA1 (A-HoA, B-HoA, B-Key, B-nonce-h)
つまり、端末ＢのホームアドレスB-HoAを加えてB-Token-hを計算する。B-Token-hの計算に用いるA-HoAは、ＨｏＴＩメッセージの送信元アドレスであり、B-HoAはあて先アドレスである。また、ＨｏＴメッセージに含めるSb(A-Token-h)は、端末ＢがA-Token-hを記憶しておくことを回避するための手段である。A-Token-hを暗号化し、端末Ａに送り返し、さらに端末ＡはＢＵに含めて端末Ｂへ送り返す。端末Ｂは、ＢＵに付加されたSb(A-Token-h)を復号化し、A-Token-hを取得し、A-Token-hを用いて鍵データＫｅｙ Ａを生成する。
端末Ａは、ＨｏＴＩの送信と並行して、ＣｏＴＩを送信してもよい。つまり、ＨｏＴを受信する前にＣｏＴＩを送信してもよい。またＨｏＴＩの前にＣｏＴＩを送信してもよい。端末Ａは、ＣｏＴＩにA-Token-cを付加して端末Ｂに送信する。A-Token-cの生成方法は次のような方法が考えられる。
A-Token-c = HMAC SHA1 (B-CoA, A-Key, nonce)
B-CoAとは端末Ｂの気付アドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがCare-of Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＣｏＴＩを受信し、ＣｏＴを応答として返す。ＣｏＴには、B-Token-c、B-nonce-c、Sb(A-Token-c)を含める。B-Token-cの計算方法は従来のＭＩＰとは異なり、次のように計算する。
B-Token-c = HMAC SHA1 (A-CoA, B-CoA, B-Key, B-nonce-c)
つまり、端末Ｂの気付アドレスB-CoAを加えてB-Token-cを計算する。B-Token-cの計算に用いるA-CoAは、ＣｏＴＩメッセージの送信元アドレスであり、B-CoAはあて先アドレスである。また、ＣｏＴメッセージに含めるSb(A-Token-c)は、ＨｏＴＩの処理と同様で、端末ＢがA-Token-cを記憶しておくことを回避するための手段である。
端末Ａは、ＨｏＴＩメッセージの応答としてＨｏＴを受信し、ＣｏＴＩメッセージの応答としてＣｏＴを受信すると、それぞれのメッセージに含まれるB-Token-hとB-Token-cを用いて鍵データＫｅｙ Ｂを生成する。
Key B = HMAC SHA1 (B-Token-h, B-Token-c)
端末Ａは、この鍵データを用いてＢＵメッセージの認証コードＢ−ＭＡＣを生成する。
B-MAC = HMAC SHA1 (Key B, BU message)
端末Ａは、ＢＵメッセージに次のデータのB-nonce-h、B-nonce-c、B-MAC、Sb(A-Token-h)、Sb(A-Token-c)、A-HoA、B-HoAを付加して、端末Ｂに送信する。
端末Ｂは、ＢＵメッセージを受信し、B-nonce-h、B-HoA、A-HoAを用いて、B-Token-hを生成する。また、ＢＵメッセージの送信元アドレスA-CoA、あて先アドレスB-CoA、B-nonce-cを用いてB-Token-cを生成する。生成したB-Token-hとB-Token-cを用いて、Ｋｅｙ Ｂを生成し、ＢＵメッセージに付加されているＢ−ＭＡＣが正しいかどうか検査する。Ｂ−ＭＡＣの検査結果が正しい場合には、端末Ｂは端末Ａのバインディングキャッシュの寿命の更新を行う。また新規の設定も可能である。一方、Ｂ−ＭＡＣの検査結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。
また、端末ＢはＢＵメッセージに含まれる情報Sb(A-Token-h)とSb(A-Token-c)の復号処理を行い、A-Token-hとA-Token-cを取得する。そして次のようにＫｅｙ Ａを生成する。
Key A = HMAC SHA1 (A-Token-h, A-Token-c)
端末Ｂはこの鍵データを用いてＢＡメッセージの認証コードＡ−ＭＡＣを生成する。
A-MAC = HMAC SHA1 (Key A, BA message)
端末Ｂは、ＢＡメッセージに、通常のＭＩＰと同様にＫｅｙ Ｂで生成した認証コードＢ−ＭＡＣを付加するとともに、新しいＫｅｙ Ａで生成した認証コードＡ−ＭＡＣを付加する。端末Ａは、ＢＡメッセージを受信し、Ｋｅｙ Ｂ及びＫｅｙ Ａを用いて認証コードを検証し、正しい場合には、端末Ｂのバインディングキャッシュの寿命の更新を行う。認証コードの検証結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。
なお、上記ではＫｅｙ ＡとＫｅｙ Ｂを分ける場合で説明したが、合わせて一つの鍵データにしてもよい。例えば、次のように鍵データを生成してもよい。
Key AB = HMAC SHA1 (A-Token-h, A-Token-c, B-Token-h, B-Token-c)
なお、端末ＡがA-Token-h、A-Token-cを記憶する場合について説明したが、ＢＵメッセージにA-nonce-h、A-nonce-cを含め、端末ＢよりＢＡメッセージに含めて折り返してもよい。この場合、端末Ａは、ＢＡメッセージを受信してからA-Token-h、A-Token-cをそれぞれA-nonce-hとA-nonce-cから生成することができ、記憶しておく必要がない。
なお、本発明ではA-Token-h、A-Token-cをそれぞれＨｏＴＩメッセージ、ＣｏＴＩメッセージに乗せたが、ほかの組み合わせであってもよい。例えば、A-Token-hをＣｏＴＩメッセージに乗せ、A-Token-cをＨｏＴＩメッセージに乗せてもよい。また、両方のTokenを同じメッセージに乗せてもよい。さらに、A-Token-h、A-Token-cを分割し、それぞれ分けてＨｏＴ、ＣｏＴメッセージに乗せてもよい。
なお、ＨｏＴＩメッセージを省略することも可能である。例えば、ＣｏＴＩの応答としてＨｏＴとＣｏＴを返すようにし、ＢＵにA-Token-hを含めてもよい。また同様に、ＣｏＴＩを省略することも可能である。この場合は、ＨｏＴＩの応答としてＨｏＴとＣｏＴを返すようにし、ＢＵにA-Token-cを含めてもよい。なお、端末ＡがＨｏＴＩを送信後、ＨｏＴを受信してからＣｏＴＩを送信してもよい。ＨｏＴに含まれる情報をＡが保持するのではなく、ＣｏＴＩに含めて送信し、ＣｏＴで折り返されるようにしてもよい。
なお、端末Ｂが従来ＭＩＰにしか対応していない端末の場合には、従来ＭＩＰは端末ＡからのＨｏＴＩ及びＣｏＴＩに対して、従来ＭＩＰと同様のＨｏＴ及びＣｏＴを返信する。端末Ａは、それによって端末Ｂが本発明のバインディングアップデートに対応していないことがわかるため、従来のＭＩＰのＢＵメッセージを送信する。
また、端末Ａと端末Ｂが同時に本発明のバインディングアップデートを行った場合には、次のような対応が考えられる。両方のバインディングアップデートをそのまま行ってもよい。ＨｏＴ、ＣｏＴを受信してからＢＵを送信するまでの待ち時間をランダムに設定することによって、一方のＢＵの送信を回避しやすくしてもよい。
また、両端末のバインディングアップデートを行った場合には、開始側と受信側のバインディングキャッシュの寿命の長さを変えてもよい。受信側の寿命をわずかに短くすることによって、次のバインディングアップデートの開始側が交代するようにしてもよい。なお、本発明の結合バインディングアップデート処理は、移動端末自ら行うのではなく、代理ノードが行ってもよい。
次に、結合バインディングアップデートの開始側の移動端末について図１５を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの送信について説明する。メッセージ作成部１５０１は、結合バインディング判定部１５０２に通常のバインディングアップデートか、結合バインディングアップデートかの判定を要求する。結合バインディング判定部１５０２は、バインディングキャッシュ管理部１５０３に、これからバインディングアップデートを行う相手通信端末からのバインディングキャッシュが登録されているかどうかを確認する。登録されていない場合には、通常のバインディングアップデートを行う。
結合バインディングアップデートを行う場合には、メッセージ作成部１５０１はＡ−Ｔｏｋｅｎ生成部１５０４によってHome Token（A-Token-h）及びCare-of Token（A-Token-c）を生成し、そのTokenを付加してＨｏＴＩメッセージ及びＣｏＴＩメッセージを生成し、メッセージ送信部１５０５より送信する。Ａ−Ｔｏｋｅｎ生成部１５０４で作成したHome Token及びCare-of TokenはＡ−Ｔｏｋｅｎ保存部１５０６において保存しておく。
次に、ＨｏＴ／ＣｏＴの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージの応答メッセージであるＨｏＴ及びＣｏＴメッセージは、メッセージ受信部１５０７によって受信される。受信したＨｏＴ及びＣｏＴに含まれる相手端末が生成したToken（B-Token-h、B-Token-c）及びNonce-ID（応答側移動端末がNonceの値を呼び出すための識別番号）はＢ−Ｔｏｋｅｎ保存部１５０８及びＮｏｎｃｅ保存部１５０９に保存される。また、相手端末によって付加されたSb(Home Token)及びSb(Care-of Token)は、Ｓｂ（Ｔｏｋｅｎ）保存部１５１０に保存される。
次に、ＢＵの送信について説明する。ＨｏＴメッセージとＣｏＴメッセージの両方を受信したとき、Ｂ−Ｔｏｋｅｎ保存部１５０８にはHome Token（B-Token-h）とCare-of Token（B-Token-c）の両方のTokenが揃っているため、それらのTokenを用いてＢ−Ｋｅｙ生成部１５１１において鍵データを生成する。
メッセージ認証コード生成部１５１２は、Ｂ−Ｋｅｙ生成部１５１１において生成された鍵データを用いてメッセージ認証コードを生成し、メッセージ作成部１５０１に渡す。メッセージ作成部１５０１では、生成されたメッセージ認証コードとＳｂ（Ｔｏｋｅｎ）保存部１５１０に保存しておいた２つのSb(Home Token)及びSb(Care-of Token)をＢＵメッセージに付加する。またＮｏｎｃｅ保存部１５０９に保存しておいたNonce-IDもＢＵメッセージに付加する。そして、メッセージ送信部１５０５よりＢＵメッセージを送信する。
次に、ＢＡの受信について説明する。ＢＡメッセージをメッセージ受信部１５０７で受信し、メッセージ認証コード判定部１５１５においてメッセージの判定を行う。メッセージの判定のために、Ａ−Ｋｅｙ生成部１５１４は、Ａ−Ｔｏｋｅｎ保存部１５０６に保存しておいたHome Token（A-Token-h）とCare-of Token（A-Token-c）を取り出し、鍵データを生成する。メッセージ認証コード生成部１５１２は、Ａ−Ｋｅｙ生成部１５１４により生成された鍵データを用いてメッセージ認証コードを生成する。メッセージ認証コード判定部１５１３は、その生成したメッセージ認証コードと、ＢＵメッセージに付加されていたメッセージ認証コードとを比較し、一致するかどうか判定する。
メッセージ認証コードが一致した場合には、バインディングキャッシュ管理部１５０３にバインディングキャッシュを登録する。その後で、ＢＡメッセージに対する応答をメッセージ作成部１５０１において作成し、メッセージ送信部１５０５より送信する。
次に、結合バインディングアップデートの応答側の移動端末について図１６を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージをメッセージ受信部１６０１で受信し、結合バインディングアップデートの場合には、メッセージに含まれるHome Token（A-Token-h）又はCare-of Token（A-Token-c）をＡ−Ｔｏｋｅｎ暗号・復号処理部１６０２に渡す。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３はB-Token（Home Token又はCare-of Token）を生成する。B-Tokenを生成するときに必要なNonce(home nonce又はcare-of nonce)はＮｏｎｃｅ管理部１６０４より取得する。
B-Home Token = SHA1 (A-HoA, B-HoA, B-Key, B-home nonce)
B-Care-of Token = SHA1 (A-CoA, B-CoA, B-Key, B-care-of nonce)
次に、ＨｏＴ／ＣｏＴの送信について説明する。Ａ−Ｔｏｋｅｎ暗号・復号処理部１６０２は、暗号化したデータ（Sb(Home Token（A-Token-h）)又はSb(Care-of Token（A-Token-c）)）をメッセージ作成部１６０５に渡し、メッセージ作成部１６０５は応答メッセージに付加する。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３より生成したToken（B-Token）及び生成に用いたNonceを呼び出すためのNonce-IDを取得し、応答メッセージに付加する。応答メッセージは受信メッセージがＨｏＴＩの場合にはＨｏＴメッセージであり、ＣｏＴＩの場合にはＣｏＴメッセージである。メッセージ作成部１６０５が作成した応答メッセージは、メッセージ送信部１６０６から送信される。
次に、ＢＵの受信について説明する。ＢＵメッセージをメッセージ受信部１６０１で受信し、結合バインディングアップデートの場合には、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３においてHome Token（B-Token-h）及びCare-of Token（B-Token-c）を生成する。Token生成のときには、受信したＢＵメッセージに含まれるNonce-IDを用いてＮｏｎｃｅ管理部１６０４からNonceの値を取り出し、それを用いる。また、ＢＵメッセージに含まれるSb(Home Token)及びSb(Care-of Token)をＡ−Ｔｏｋｅｎ暗号・復号処理部１６０２に渡し、復号化し、元のHome Token（A-Token-h）及びCare-of Token（A-Token-c）を取得する。
また、ＢＵメッセージに含まれるメッセージ認証コードをメッセージ認証コード比較部１６０７に渡す。結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３で生成したHome Token（B-Token-h）及びCare-of Token（B-Token-c）をＢ−Ｋｅｙ生成部１６０８に渡し、Ｂ−Ｋｅｙ生成部１６０８において鍵データを生成する。
そして、生成した鍵データを用いて、メッセージ認証コード生成部１６０９において、メッセージ認証コードを生成する。生成したメッセージ認証コードとＢＵメッセージに含まれていたメッセージ認証コードが一致するかどうかをメッセージ認証コード比較部１６０７で比較する。メッセージ認証コードが一致した場合は、バインディングキャッシュ管理部１６１０にバインディングキャッシュを設定又は更新する。
次に、ＢＡの送信について説明する。Ａ−Ｔｏｋｅｎ暗号・復号処理部１６０２によって復号化されたToken（A-Token-h、A-Token-c）を用いてＡ−Ｋｅｙ生成部１６１１において鍵データを生成し、メッセージ認証コード生成部１６０９でメッセージ認証コードを生成する。メッセージ作成部１６０５は、生成したメッセージ認証コードをＢＡメッセージに付加し、メッセージ送信部１６０６よりＢＡメッセージを送信する。ＢＡメッセージに対する応答メッセージは、メッセージ受信部１６０１で受信し、メッセージ認証コードを確認し、バインディングキャッシュ管理部１６１０においてバインディングキャッシュを更新する。
次に、結合バインディングアップデートの開始側の移動端末の処理フローについて図１７を用いて説明する。図１７に示すように、移動端末は、バインディングアップデートを行おうとしている相手端末のバインディングキャッシュが存在しているかの確認処理を開始し（ステップＳ１７０１）、相手端末のバインディングキャッシュが存在しているか否かを判断する（ステップＳ１７０２）。バインディングキャッシュが存在する場合、移動端末は、相手端末のホームアドレスを用いたHome Token（A-Token-h）及び相手端末のＣｏＡを用いたCare-of Token（A-Token-c）を生成する（ステップＳ１７０３）。
そして、移動端末は、Home Tokenを含んだ結合バインディングアップデートのＨｏＴＩメッセージ、Care-of Tokenを含んだ結合バインディングアップデートのＣｏＴＩメッセージをそれぞれ送信する（ステップＳ１７０４）。移動端末は、応答メッセージのＨｏＴメッセージ、ＣｏＴメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１７０５）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１７０６）。
タイムアウト前に応答メッセージを受信した場合、移動端末はＢＵメッセージを生成する。すなわち、移動端末は、受信したＨｏＴ、ＣｏＴに含まれるTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、生成されたメッセージ認証コード、ＨｏＴ、ＣｏＴに含まれていたSb(Home Token（A-Token-h）)、Sb(Care-of Token（A-Token-c）)を付加したＢＵメッセージを生成し、送信する（ステップＳ１７０７）。移動端末は、応答メッセージのＢＡメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１７０８）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１７０９）。
タイムアウト前に応答メッセージを受信した場合、移動端末は最初に送信したHome Token（A-Token-h）、Care-of Token（A-Token-c）から鍵データを生成し、ＢＡメッセージに含まれるメッセージ認証コードが正しいか否かの確認処理を開始する（ステップＳ１７１０）。メッセージ認証コードが正しいか否かを判断し（ステップＳ１７１１）、正しいと判断された場合、移動端末は、自身のバインディングキャッシュ及び相手端末のバインディングキャッシュの設定及び更新を行い、応答メッセージを送信する（ステップＳ１７１２）。
なお、ステップＳ１７０２において、バインディングキャッシュが存在しないと判断された場合には、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１７１３）。また、ステップＳ１７０６、Ｓ１７０９において、タイムアウト前に応答メッセージを受信できなかった場合、再送回数が所定の数値Ｎよりも小さければ再送を行う（ステップＳ１７１４、Ｓ１７１５）。また、ステップＳ１７１１において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの更新を行わないことを確認する（ステップＳ１７１６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（結合バインディングアップデートのメッセージの受信からそれに対する応答メッセージを送信するまで）について図１８Ａを用いて説明する。図１８Ａに示すように、移動端末は、ＨｏＴＩ又はＣｏＴＩを受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１８０１）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１８０２）、結合バインディングアップデートのメッセージである場合、Home Tokenの場合には両端末のホームアドレスを含めたTokenを生成し、Care-of Tokenの場合には両端末のＣｏＡを含めたTokenを生成する（ステップＳ１８０３）。
移動端末は、ＨｏＴＩ、ＣｏＴＩに付加されていたToken（A-Token-h、A-Token-c）を暗号化し、応答メッセージを生成し、送信する（ステップＳ１８０４）。なお、ステップＳ１８０２において、結合バインディングアップデートのメッセージではないと判断された場合、移動端末は、従来のＭＩＰのバインディングアップデート処理として応答を送信する（ステップＳ１８０５）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（ＢＵメッセージの受信からＢＡメッセージを送信するまで）について図１８Ｂを用いて説明する。図１８Ｂに示すように、移動端末は、ＢＵ（メッセージ）を受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１８１０）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１８１１）、結合バインディングアップデートのメッセージである場合、ＢＵに含まれるアドレス、Nonceの情報を用いてToken（B-Token-h、B-Token-c）を生成し、Tokenを用いて鍵データを生成し、付加されているメッセージ認証コードの確認処理を開始する（ステップＳ１８１２）。
移動端末は、メッセージ認証コードが正しいか否かを判断し（ステップＳ１８１３）、正しい場合には、バインディングキャッシュの設定、更新を行い、ＢＵに含まれている暗号化されたToken（A-Token-h、A-Token-c）を復号化し、鍵データを生成し、メッセージ認証コードを生成し、ＢＡメッセージに含めて送信する（ステップＳ１８１４）。なお、ステップＳ１８１１において、結合バインディングアップデートのメッセージでない場合、移動端末は、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１８１５）。また、ステップＳ１８１３において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの設定、更新を行わないことを確認する（ステップＳ１８１６）。
なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明に係るバインディング更新方法及びその方法で用いられる移動端末は、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できるため、バインディングアップデートにより経路の最適化がなされた通信端末間のバインディングを更新するバインディング更新方法及びその方法で用いられる移動端末などに有用である。
本発明は、バインディングアップデートにより経路の最適化がなされた通信端末間のバインディングを更新するバインディング更新方法及びその方法で用いられる移動端末に関する。
従来から、通信装置が移動しても移動前と同じＩＰアドレスを使い続けることができる技術としてモバイルＩＰが存在する。モバイルＩＰでは、ホームエージェント（home agent）が移動通信装置（mobile node）のホームアドレス（home address）あてのパケットを受信し、移動通信装置の気付アドレス（ＣｏＡ：Care-of Address）に転送する。このため、移動通信装置は移動に伴うアドレス変更によらず、ホームアドレスを用いた通信を継続できる。
また、パケットがホームエージェントを経由することによって移動通信装置と通信相手装置（ＣＮ：correspondent node）の通信経路が遠回りになることを改善するために、移動通信装置と通信相手装置の通信経路を直接結ぶ経路最適化（Route Optimization）技術が存在する。この経路最適化技術は、通信相手装置に移動通信装置のホームアドレスと気付アドレスの対応関係を記憶させることによって、気付アドレスを用いて通信することを特徴とする。この通信相手装置に移動通信装置のホームアドレスと気付アドレスの対応関係を記憶させる処理は、バインディング更新処理（ＢＵ：Binding Update）と呼ばれている。
通信相手装置に対するバインディング更新処理では、ホームエージェントに対するバインディング更新処理とは異なり、バインディング更新前処理（ＲＲ：Return Routability Procedure）を必要としている。ホームエージェントと移動通信装置との間では、信頼関係をあらかじめ築いておくことができるため、このバインディング更新前処理を必要としない。ホームエージェントに対するバインディング更新処理においては、移動通信装置がホームエージェントにホームアドレスに対する新しい気付アドレスを通知したとき、ホームエージェントは、事前に確立しておいた信頼関係（ＩＰｓｅｃ ＳＡなど）によって移動通信装置からのバインディング更新要求であることを確認することができる。
一方、通信相手装置の場合、すべての通信相手となる可能性のある通信装置に対して、バインディング更新処理を行う前に、移動通信装置と通信相手装置との間にあらかじめ信頼関係を確立しておくことは困難である。もし、信頼関係がない状態で通信相手装置がバインディング更新の要求に従ってしまうならば、移動通信装置に成りすました攻撃が容易になる。そして、攻撃者が通信相手装置にバインディング更新処理を行うと、移動通信装置へのパケットを不正な気付アドレスに転送させることが可能になる。これを防ぐ技術がバインディング更新前処理である。
具体的には、バインディング更新前処理では、ホームアドレステスト処理（Home Test）、気付アドレステスト処理（Care-of Test）を行う。これらの処理の結果をバインディング更新処理に反映させることによって、不正なバインディング更新処理を防いでいる。なお、従来技術として説明した、モバイルＩＰ、経路最適化、バインディング更新前処理については、後述する非特許文献１に記載されている。また、バインディング更新前処理の設計思想については、後述する非特許文献２に記載されている。
バインディング更新前処理についてもう少し詳しく説明する。ホームアドレステスト処理では、移動通信装置はＨｏＴＩ（Home Test Init）メッセージを通信相手装置に送信し、通信相手装置はＨｏＴ（Home Test）メッセージを返す。また、気付アドレステスト処理では、移動通信装置はＣｏＴＩ(Care-of Test Init)メッセージを通信相手装置に送信し、通信相手装置はＣｏＴ(Care-of Test)メッセージを返す。
移動通信装置は、通信相手装置から応答として返されたＨｏＴメッセージ及びＣｏＴメッセージに含まれるHome keygen token（Home token）、Care-of keygen token（Care-of token）をもとに鍵を生成し、その鍵でバインディング更新（ＢＵ）メッセージのメッセージ認証コード（ＭＡＣ:Message Authentication Code）を計算し、ＢＵメッセージに付加して送信する。
ＢＵメッセージを受信した通信相手装置は、メッセージ認証コードを確認することによって、移動通信装置から送信された正当なＢＵメッセージであると判断する。バインディング更新前処理の設計思想を説明している非特許文献２によると、このバインディング更新前処理は、通信相手装置がState（状態）を持つ必要がないように設計されている。つまり、ＨｏＴＩメッセージを受信したことがあるかどうか、ＣｏＴＩメッセージを受信したことがあるかどうかを、通信相手装置は記憶しておかなくてもＢＵメッセージの認証処理を行うことができる。
これは、攻撃者がＨｏＴＩメッセージやＣｏＴＩメッセージを用いて通信相手装置に対してＤｏＳ攻撃（Denial of Service Attack）を行った場合に、通信相手装置の被害を小さくするためである。また、ＨｏＴＩメッセージに対してＨｏＴメッセージを返す、ＣｏＴＩメッセージに対してＣｏＴメッセージを返す、というように１つの要求メッセージに対して１つの応答メッセージを返すようにしているのは、メッセージの増加（Amplification）を行わないようにするためである。これは、要求メッセージを１つ送ったときに、複数の応答メッセージを返す仕組みにした場合、攻撃者は１つのメッセージを送ることによって、複数のターゲットを攻撃することが可能になるためである。
"Mobility Support in IPv6"，RFC3775 "Mobile IP Version 6 Route Optimization Security Design Background",RFC4225
しかしながら、上記従来技術のＭＩＰｖ６では移動端末どうしがお互いにバインディングアップデートを行っているときに、その状況を効率的に利用できないという課題があった。つまり、従来の移動通信装置は、通信相手装置が自身に対してバインディングアップデートを行っている場合であっても、処理の効率化を目的としてバインディングアップデートの処理手順を変えることができなかった。
また、移動通信装置と通信相手装置が最適化経路を用いた通信を継続するためには、双方ともバインディングキャッシュを継続するために、定期的（７分ごと）にバインディングアップデートを行わなければならない。一方の装置（端末）のバインディングキャッシュを継続するだけでは不十分である。しかしながら、従来技術では、それぞれの装置が独立にバインディングアップデートを行うことしかできなかった。
具体的には、図１９Ａ、Ｂに示すように、端末Ａ（ＭＮ＿Ａ）と端末Ｂ（ＭＮ＿Ｂ）はそれぞれ独立に７分ごとにこのバインディングアップデートの処理を行い、相手端末に通知したバインディングキャッシュ（ホームアドレスと気付アドレスの情報）の寿命（Life Time）を更新していた。これにより、メッセージ数が多くなってしまう。
本発明は、上記の問題点に鑑み、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できるバインディング更新方法及びその方法で用いられる移動端末を提供することを目的とする。
上記目的を達成するために、本発明によれば、第１の移動端末と、前記第１の移動端末の通信相手である第２の移動端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法であって、前記第１の移動端末が前記第２の移動端末のバインディング情報を保持している場合に、前記第１の移動端末が、所定の第１移動端末情報を含めたメッセージであって、前記第２の移動端末から所定の第２移動端末情報を取得するための第１の１組のメッセージを前記第２の移動端末へ送信するステップと、前記第２の移動端末が、前記所定の第２移動端末情報を含めた第２の１組のメッセージを前記第１の移動端末へ送信するステップと、前記第１の移動端末が、前記第２の１組のメッセージに含まれた前記所定の第２移動端末情報に基づいて生成された認証情報を付加した第３のメッセージを前記第２の移動端末へ送信するステップと、前記第２の移動端末が、前記第３のメッセージに対する応答情報を含めたメッセージであって、前記所定の第１移動端末情報に基づいて生成された認証情報を付加した第４のメッセージを前記第１の移動端末へ送信するとともに、前記第１の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップと、前記第１の移動端末が、前記第４のメッセージに付加された前記第２の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップとを、有するバインディング更新方法が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明のバインディング更新方法において、前記第２の移動端末が、前記所定の第１移動端末情報を前記第２の１組のメッセージに含めて前記第１の移動端末へ送信し、
前記第１の移動端末は、前記第２の１組のメッセージに含まれる前記所定の第１移動端末情報を前記第３のメッセージに含めて前記第２の移動端末へ送信することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明のバインディング更新方法において、前記第２の移動端末が、前記所定の第１移動端末情報を前記第２の移動端末のみが復号できる形式で前記第２のメッセージに含めて送信することは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明のバインディング更新方法において、前記所定の第１移動端末情報は、前記第２の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の第２移動端末情報は、前記第１の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージは、前記第２の移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージは、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージは、前記第２の移動端末へのバインディングアップデートメッセージであり、前記第４のメッセージは、前記第１の移動端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
また、本発明によれば、移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、前記移動端末が前記通信相手端末のバインディング情報を保持している場合に、所定の移動端末情報を含めたメッセージであって、前記通信相手端末から所定の通信相手端末情報を取得するための第１の１組のメッセージを生成するメッセージ生成手段と、生成された前記第１の１組のメッセージを前記通信相手端末へ送信する送信手段と、前記所定の通信相手端末情報を含めた第２の１組のメッセージを前記通信相手端末から受信する受信手段と、受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、前記バインディング情報を更新する更新手段とを備え、前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信し、前記更新手段が、前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当であるか否かを判断し、正当である場合に前記バインディング情報を更新する移動端末が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明によれば、移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、所定の通信相手端末情報を含めたメッセージであって、前記移動端末から所定の移動端末情報を取得するための第１の１組のメッセージを受信する受信手段と、前記所定の移動端末情報を含めた第２の１組のメッセージを生成するメッセージ生成手段と、生成された前記第２の１組のメッセージを前記通信相手端末へ送信する送信手段と、前記受信手段を介して受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当である場合に前記バインディング情報を更新する更新手段とを備え、前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信する移動端末が提供される。この構成により、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記第２の１組のメッセージに含まれる前記所定の移動端末情報を含めた前記第３のメッセージを生成することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記第１の１組のメッセージに含まれる前記所定の通信相手端末情報を含めた前記第２の１組のメッセージを生成することは、本発明の好ましい態様である。この構成により、ＤｏＳ攻撃を受けた際の被害を抑えることができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第３のメッセージに含めることは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明の移動端末において、前記メッセージ生成手段が、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第２の１組のメッセージに含めることは、本発明の好ましい態様である。この構成により、他の端末に読み取られることを防ぐことができる。
また、本発明の移動端末において、前記所定の移動端末情報が、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の通信相手端末情報が、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージが、前記通信相手端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージが、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージが、前記通信相手端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
また、本発明の移動端末において、前記所定の通信相手端末情報が、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記所定の移動端末情報が、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、前記第１の１組のメッセージが、前記移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、前記第２の１組のメッセージが、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、前記第３のメッセージが、前記通信相手端末へのバインディングアップデートメッセージであることは、本発明の好ましい態様である。この構成により、適切な経路最適化を行うことができる。
本発明のバインディング更新方法及びその方法で用いられる移動端末は、上記構成を有し、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できる。
＜第１の実施の形態＞
第１の実施の形態について説明する。図１Ａに示すような多くのメッセージ数を減らすため、図１Ｂに示すように、両端末が行うバインディングアップデートを同期させ、受信側の端末がメッセージを重ねて送信するよう構成した。
すなわち、図１Ｂに示すように、端末Ａから開始したバインディングアップデートの手順に、端末Ｂが同期してバインディングアップデートを行う（以降、結合バインディングアップデートとよぶ）。端末Ｂは、端末ＡからのＨｏＴＩに対してＨｏＴを応答として返すが、それと同時にＨｏＴＩを送信する。同様に、端末Ｂは端末ＡからのＣｏＴＩに対してＣｏＴを応答として返すと同時にＣｏＴＩを送信する。そして、端末Ｂは端末ＡからのＢＵに対して、ＢＡを応答として返すと同時にＢＵを送信する。このとき端末Ｂが送信するＨｏＴとＨｏＴＩを１つのメッセージにし、同様にＣｏＴとＣｏＴＩ、ＢＡとＢＵを１つのメッセージにすることによって、メッセージ数を削減することができる。
ここで、結合バインディングアップデートの開始側の移動端末（ここでは端末Ａ）について図２を用いて説明する。メッセージ生成部２０１は、通信相手端末（端末Ｂ）から情報Ｂ１、Ｂ２それぞれを取得するためのＨｏＴＩ、ＣｏＴＩメッセージそれぞれを生成する。送信部２０２は、生成されたＨｏＴＩ、ＣｏＴＩメッセージを端末Ｂへ送信する。受信部２０３は、情報Ｂ１を含むメッセージであって、情報Ａ１を取得するためのＨｏＴメッセージ、及び情報Ｂ２を含むメッセージあって、情報Ａ２を取得するためのＣｏＴメッセージを受信する。
認証情報生成部２０４は、情報Ｂ１、Ｂ２に基づいて認証コードをそれぞれ生成し、生成された認証コードは、送信部２０２によって端末Ｂへ送信される。更新部２０５は、受信部２０３を介して受信したコード情報であって、情報Ａ１、Ａ２に基づいて端末Ｂによって生成された認証コードが正当であるか否かを判断し、正当である場合にバインディング情報を更新する。記憶部２０６は、バインディングキャッシュなどの情報を格納する。
次に、結合バインディングアップデートの応答側の移動端末（ここでは端末Ｂ）について図３を用いて説明する。受信部３０１は、情報Ｂ１、Ｂ２を取得するためのＨｏＴＩ、ＣｏＴＩメッセージを端末Ａから受信する。メッセージ生成部３０２は、情報Ｂ１を含めたメッセージであって、端末Ａから情報Ａ１を取得するためのＨｏＴメッセージ、及び情報Ｂ２を含めたメッセージであって、端末Ａから情報Ａ２を取得するためのＣｏＴメッセージを生成する。
送信部３０３は、生成されたＨｏＴ、ＣｏＴメッセージを端末Ａへ送信する。認証情報生成部３０４は、受信部３０１を介して受信した情報Ｂ１、Ｂ２に基づいて認証コードを生成し、生成された認証コードは送信部３０３によって端末Ａに送信される。更新部３０５は、受信部３０１を介して受信した情報であって、情報Ｂ１、Ｂ２に基づいて端末Ａによって生成されたそれぞれの認証コードが正当であるか否かを判断し、正当である場合にバインディング情報を更新する。記憶部３０６は、バインディングキャッシュなどの情報を格納する。
＜第２の実施の形態＞
第２の実施の形態について説明する。まず、ＭＩＰの基本原理について説明する。図４には端末Ａからのバインディングアップデートの様子を示している。端末Ａは端末Ｂに気付アドレス（ＣｏＡ）が自身のアドレスであることを端末Ｂに証明しようとしている。そのため、端末Ｂに端末Ａのホームアドレス（ＨｏＡ）とＣｏＡにそれぞれメッセージを送信してもらい、その両方を受信したことを端末Ｂに示す。
簡単に説明すると、端末Ｂは端末ＡのＨｏＡあてに情報Ｂ１を送信し、端末ＡのＣｏＡあてに情報Ｂ２を送信する。端末ＡはＢ１とＢ２を用いて鍵データであるＫｅｙ（Ｂ１、Ｂ２）を生成し、その鍵データを用いて認証コードを生成する。端末Ｂは端末Ａからの認証コードを確認することによって、端末Ａが鍵データを正しく生成できたことを確認し、端末Ａが情報Ｂ１と情報Ｂ２を受信したと判定する。
より具体的に説明すると、端末ＡはＨｏＴＩを端末Ｂに送信し、情報Ｂ１をＨｏＴに含めて端末ＡのＨｏＡあてに送信させる。また、端末ＡはＣｏＴＩを端末Ｂに送信し、情報Ｂ２をＣｏＴに含めて端末ＡのＣｏＡあてに送信させる。そして、情報Ｂ１と情報Ｂ２を用いて鍵データであるＫｅｙ（Ａ１、Ａ２）を生成し、その鍵を用いて送信するＢＵメッセージの認証コードを生成し、認証コードをＢＵメッセージに付加して端末Ｂに送信する。端末Ｂは、ＢＵを受信するとＢ１とＢ２から鍵データを生成し、認証コードが正しいかどうか確認する。なお、図５は端末Ｂからのバインディングアップデートの様子を示している。
以上を踏まえて、上述した第１の実施の形態よりさらにメッセージ数を減らすことができる態様について図６を用いて説明する。この態様では、端末Ａが端末Ｂからの要求を受ける前に、端末ＢのＨｏＡに情報Ａ１を、ＣｏＡに情報Ａ２を送信する。これは、従来なら端末ＢからＨｏＴＩ、ＣｏＴＩメッセージを受信した後応答として返す情報である。しかし、端末Ａが端末Ｂのバインディングキャッシュを持っている場合、端末Ａは端末ＢのＨｏＡとＣｏＡを既に知っているため、図６に示すように、端末Ｂのバインディングアップデートの処理を端末Ａから開始することができる。
さらに、端末Ａは、端末Ｂに対するＨｏＴＩメッセージ６０１、ＣｏＴＩメッセージ６０３を用いて情報Ａ１と情報Ａ２を送信することによって、端末Ａのバインディングアップデートも同時に開始することができる。端末Ａは、端末Ｂからの応答メッセージであるＨｏＴメッセージ６０２、ＣｏＴメッセージ６０４を受信し、その応答メッセージに含まれる情報Ｂ１、Ｂ２を用いて鍵データ（Ｋｅｙ（Ｂ１、Ｂ２））を作成し、ＢＵメッセージ６０５を送信し、鍵データ（Ｋｅｙ（Ｂ１、Ｂ２））を生成できたことを示す。
端末Ｂは、そのＢＵメッセージ６０５を確認し、端末Ａのバインディングアップデートを承認するとともに、先に送られてきた情報Ａ１と情報Ａ２をもとに鍵データ（Ｋｅｙ（Ａ１、Ａ２））を生成し、ＢＵメッセージ６０５の応答としてＢＡメッセージ６０６を送る際に、端末Ｂが鍵データ（Ｋｅｙ（Ａ１、Ａ２））を生成できたことを示す。端末Ａは、そのＢＡメッセージ６０６を確認し、端末Ｂのバインディングアップデートを承認する。なお、端末Ａは承認完了の旨のメッセージ６０７を端末Ｂに送信するようにしてもよい。以上のように、本実施の形態の方法を用いることによって、第１の実施の形態と比較して、バインディングアップデートに要するメッセージ数を更に削減することができる。
ここで、第２の実施の形態をより詳細に説明する。端末Ａが端末Ｂからのバインディングアップデートを受け、端末ＢのホームアドレスＢ−ＨｏＡと気付アドレスＢ−ＣｏＡを知っている状態にあるとする。端末Ａは、端末Ｂにバインディングアップデートを行うとき、端末Ｂのバインディングキャッシュ情報を保持しているかどうかを確認する。保持していない場合には、通常のＭＩＰのバインディングアップデート処理を行う。一方、端末Ａが、端末Ｂのバインディングキャッシュ情報を保持している場合、図７に示すように、端末Ａと端末Ｂの両方のバインディングアップデートを同時に行うことを試みる。
端末Ａは、端末ＢのＨｏＡあてにＨｏＴＩを送信する。送信元アドレスは端末ＡのＨｏＡであり、端末Ｂからの応答メッセージＨｏＴは、この送信元アドレスである端末ＡのＨｏＡあてに送信される。メッセージＨｏＴＩには情報Ａ１が含まれる。端末Ｂは、ＨｏＴＩを受信すると、応答メッセージＨｏＴを端末Ａに送信する。端末ＢのＨｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＨｏＡであり、あて先アドレスは要求メッセージＨｏＴＩの送信元アドレスである端末ＡのＨｏＡである。
同様に、端末Ａは端末ＢのＣｏＡあてにＣｏＴＩを送信する。送信元アドレスは端末ＡのＣｏＡである。ＣｏＴＩメッセージには情報Ａ２が含まれる。端末Ｂは、ＣｏＴＩを受信すると、応答メッセージＣｏＴを端末Ａに送信する。端末ＢのＣｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＣｏＡであり、あて先アドレスは要求メッセージＣｏＴＩの送信元アドレスである端末ＡのＣｏＡである。
端末Ａは、応答メッセージのＨｏＴとＣｏＴに含まれる情報Ｂ１とＢ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＵメッセージに認証コードを付加して、端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信すると認証コードを確認し、端末Ａのバインディングキャッシュが正しいと判定し、寿命（Life Time）を延長する。また、端末Ｂは、応答メッセージであるＢＡを送信する際に、ＨｏＴＩとＣｏＴＩに含まれていた情報Ａ１とＡ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＡメッセージに認証コードを付加して、端末Ａに送信する。端末Ａは、ＢＡメッセージを受信すると認証コードを確認し、端末Ｂのバインディングキャッシュが正しいと判定し、寿命を延長する。
上述した様子について図８を用いて更に詳しく説明する。端末Ａは、ＨｏＴＩにA-Token-hを付加して端末Ｂに送信する。A-Token-hの生成方法は、原理的には任意でよく特に定める必要はない。しかし、従来技術のＭＩＰをできるだけ利用する方法として次のような生成方法が考えられる。
A-Token-h = HMAC SHA1 (B-HoA, A-Key, nonce)
なお、ここではトークン値の計算にハッシュ関数（HMAC SHA1）を用いる場合について述べるが、それ以外の関数あるいは生成式を用いるものであってもよい。
B-HoAとは端末Ｂのホームアドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがHome Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＨｏＴＩを受信しＨｏＴを応答として返す。ＨｏＴには、B-Token-h、B-nonce-hを含める。B-Token-hの計算方法は従来のＭＩＰとは異なる。従来のＭＩＰでは次のようにB-Token-hを計算した。
B-Token-h = HMAC SHA1 (A-HoA, B-Key, B-nonce-h)
本発明の方法では、次のように計算する。
B-Token-h = HMAC SHA1 (A-HoA, B-HoA, B-Key, B-nonce-h)
つまり、端末ＢのホームアドレスB-HoAを加えてB-Token-hを計算する。B-Token-hの計算に用いるA-HoAは、ＨｏＴＩメッセージの送信元アドレスであり、B-HoAはあて先アドレスである。また、ＨｏＴＩメッセージに含まれていたA-Token-hは、端末Ｂが保持する。例えば、端末Ａのバインディングキャッシュの中にHome Tokenを保持する領域を確保し、送信されてきた最新の値を保持するといった方法が考えられる。
端末Ａは、ＨｏＴＩの送信と並行してＣｏＴＩを送信してもよい。つまり、ＨｏＴを受信する前にＣｏＴＩを送信してよい。またＨｏＴＩの前にＣｏＴＩを送信してもよい。端末Ａは、ＣｏＴＩにA-Token-cを付加して端末Ｂに送信する。A-Token-cの生成方法は次のような方法が考えられる。
A-Token-c = HMAC SHA1 (B-CoA, A-Key, nonce)
B-CoAとは端末Ｂの気付アドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがCare-of Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＣｏＴＩを受信しＣｏＴを応答として返す。ＣｏＴには、B-Token-c、B-nonce-cを含める。B-Token-cの計算方法は従来のＭＩＰとは異なり、次のように計算する。
B-Token-c = HMAC SHA1 (A-CoA, B-CoA, B-Key, B-nonce-c)
つまり、端末Ｂの気付アドレスB-CoAを加えてB-Token-cを計算する。B-Token-cの計算にもちいるA-CoAは、ＣｏＴＩメッセージの送信元アドレスであり、B-CoAはあて先アドレスである。また、端末ＢはA-Token-cをA-Token-hと同様に保持しておく。端末Ａは、ＨｏＴＩメッセージの応答としてＨｏＴを受信し、ＣｏＴＩメッセージの応答としてＣｏＴを受信すると、それぞれのメッセージに含まれるB-Token-hとB-Token-cを用いて鍵データであるＫｅｙ Ｂを生成する。
Key B = HMAC SHA1 (B-Token-h, B-Token-c)
端末Ａはこの鍵データＫｅｙ Ｂを用いてＢＵメッセージの認証コードＢ−ＭＡＣを生成する。
B-MAC = HMAC SHA1 (Key B, BU message)
端末Ａは、ＢＵメッセージに次のデータのB-nonce-h、B-nonce-c、B-MAC、A-HoA、B-HoAを付加して端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信し、B-nonce-h、B-HoA、A-HoAを用いてB-Token-hを生成する。また、ＢＵメッセージの送信元アドレスA-CoA、あて先アドレスB-CoA、B-nonce-cを用いてB-Token-cを生成する。生成したB-Token-hとB-Token-cを用いてＫｅｙ Ｂを生成し、ＢＵメッセージに付加されているB-MACが正しいかどうか検査する。
Ｂ−ＭＡＣの検査結果が正しい場合には、端末Ｂは端末Ａのバインディングキャッシュの寿命の更新を行う。また新規の設定も可能である。一方、Ｂ−ＭＡＣの検査結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。また、端末Ｂは保持していた情報A-Token-hとA-Token-cを用いて次のように鍵データＫｅｙ Ａを生成する。
Key A = HMAC SHA1 (A-Token-h, A-Token-c)
端末Ｂはこの鍵データＫｅｙ Ａを用いてＢＡメッセージの認証コードＡ−ＭＡＣを生成する。
A-MAC = HMAC SHA1 (Key A, BA message)
端末Ｂは、ＢＡメッセージに、通常のＭＩＰと同様にＫｅｙ Ｂで生成した認証コードＢ−ＭＡＣを付加するとともに、新しいＫｅｙ Ａで生成した認証コードＡ−ＭＡＣを付加する。端末Ａは、ＢＡメッセージを受信し、Ｋｅｙ Ｂ及びＫｅｙ Ａを用いて認証コードを検証し、正しい場合には、端末Ｂのバインディングキャッシュの寿命の更新を行う。認証コードの検証結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。なお、上記ではＫｅｙ ＡとＫｅｙ Ｂを分ける場合で説明したが、合わせて一つの鍵データにしてもよい。例えば、次のように鍵データを生成してもよい。
Key AB = HMAC SHA1 (A-Token-h, A-Token-c, B-Token-h, B-Token-c)
次に、結合バインディングアップデートの開始側の移動端末について図９を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの送信について説明する。メッセージ作成部９０１は、結合バインディング判定部９０２に通常のバインディングアップデートか、結合バインディングアップデートかの判定を要求する。結合バインディング判定部９０２は、バインディングキャッシュ管理部９０３に、これからバインディングアップデートを行う相手端末からのバインディングキャッシュが登録されているかどうかを確認する。登録されていない場合には、通常のバインディングアップデートを行う。
結合バインディングアップデートを行う場合には、メッセージ作成部９０１はＡ−Ｔｏｋｅｎ生成部９０４にHome Token及びCare-of Tokenを生成させ、そのTokenを付加してＨｏＴＩメッセージ及びＣｏＴＩメッセージを生成し、メッセージ送信部９０５より送信する。Ａ−Ｔｏｋｅｎ生成部９０４で作成したHome Token及びCare-of TokenはＡ−Ｔｏｋｅｎ保存部９０６において保存しておく。
次に、ＨｏＴ／ＣｏＴの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージの応答メッセージであるＨｏＴ及びＣｏＴメッセージは、メッセージ受信部９０７によって受信される。受信したＨｏＴ及びＣｏＴに含まれる相手端末が生成したToken及びNonce-ID（応答側の移動端末がNonceの値を呼び出すための識別番号）はＢ−Ｔｏｋｅｎ保存部９０８及びＮｏｎｃｅ保存部９０９に保存される。
次に、ＢＵの送信について説明する。ＨｏＴメッセージとＣｏＴメッセージの両方を受信したとき、Ｂ−Ｔｏｋｅｎ保存部９０８にはHome TokenとCare-of Tokenの両方のTokenが揃っているため、それらのTokenを用いてＢ−Ｋｅｙ生成部９１０において鍵データを生成する。メッセージ認証コード生成部９１１は、Ｂ−Ｋｅｙ生成部９１０において生成された鍵データを用いてメッセージ認証コード（上述した認証コードに相当）を生成し、メッセージ作成部９０１に渡す。メッセージ作成部９０１では、生成されたメッセージ認証コードをＢＵメッセージに付加する。またＮｏｎｃｅ保存部９０９に保存しておいたNonce-IDもＢＵメッセージに付加する。そしてメッセージ送信部９０５よりＢＵメッセージを送信する。
次に、ＢＡの受信について説明する。ＢＡメッセージをメッセージ受信部９０７で受信し、メッセージ認証コード判定部９１２においてメッセージの判定を行う。メッセージの判定のために、Ａ−Ｋｅｙ生成部９１３は、Ａ−Ｔｏｋｅｎ保存部９０６に保存しておいたHome TokenとCare-of Tokenを取り出し、鍵データを生成する。メッセージ認証コード生成部９１１はＡ−Ｋｅｙ生成部９１３により生成された鍵データを用いてメッセージ認証コードを生成する。メッセージ認証コード判定部９１２は、その生成されたメッセージ認証コードと、ＢＵメッセージに付加されていたメッセージ認証コードを比較し、一致するかどうか判定する。
メッセージ認証コードが一致した場合に、バインディングキャッシュ管理部９０３にバインディングキャッシュを登録する。その後で、ＢＡメッセージに対する応答をメッセージ作成部９０１において作成し、メッセージ送信部９０５より送信する。
次に、結合バインディングアップデートの応答側の移動端末について図１０を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージをメッセージ受信部１００１で受信し、結合バインディングアップデートの場合には、メッセージに含まれるHome Token又はCare-of TokenをＡ−Ｔｏｋｅｎ保存部１００２に渡す。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１００３はB-Token（Home Token又はCare-of Token）を生成する。B-Tokenを生成するときに必要なNonce(home nonce又はcare-of nonce)はＮｏｎｃｅ管理部１００４より取得する。
B-Home Token = SHA1 (A-HoA, B-HoA, B-Key, B-home nonce)
B-Care-of Token = SHA1 (A-CoA, B-CoA, B-Key, B-care-of nonce)
次に、ＨｏＴ／ＣｏＴの送信について説明する。結合バインディングＢ−Ｔｏｋｅｎ生成部１００３より生成したToken及び生成に用いたNonceを呼び出すためのNonce-IDを取得し、応答メッセージに付加する。応答メッセージは受信メッセージがＨｏＴＩの場合にはＨｏＴメッセージであり、ＣｏＴＩの場合にはＣｏＴメッセージである。メッセージ作成部１００５が作成した応答メッセージは、メッセージ送信部１００６から送信される。
次に、ＢＵの受信について説明する。ＢＵメッセージをメッセージ受信部１００１で受信し、結合バインディングアップデートの場合には、結合バインディングＢ−Ｔｏｋｅｎ生成部１００３においてHome Token及びCare-of Tokenを生成する。Token生成のときには、受信したＢＵメッセージに含まれるNonce-IDを用いてＮｏｎｃｅ管理部１００４からNonceの値を取り出し、それを用いる。また、ＢＵメッセージに含まれるメッセージ認証コードをメッセージ認証コード比較部１００７に渡す。
結合バインディングＢ−Ｔｏｋｅｎ生成部１００３で生成したHome Token及びCare-of TokenをＢ−Ｋｅｙ生成部１００８に渡し、Ｂ−Ｋｅｙ生成部１００８において鍵データを生成する。そして、生成した鍵データを用いて、メッセージ認証コード生成部１００９において、メッセージ認証コードを生成する。生成したメッセージ認証コードとＢＵメッセージに含まれていたメッセージ認証コードが一致するかどうかをメッセージ認証コード比較部１００７で比較する。メッセージ認証コードが一致した場合は、バインディングキャッシュ管理部１０１１にバインディングキャッシュを設定又は更新する。
次に、ＢＡの送信について説明する。Ａ−Ｔｏｋｅｎ保存部１００２に保存しておいたTokenを用いてＡ−Ｋｅｙ生成部１０１０において鍵データを生成し、メッセージ認証コード生成部１００９でメッセージ認証コードを生成する。メッセージ作成部１００５は、生成されたメッセージ認証コードをＢＡメッセージに付加し、メッセージ送信部１００６よりＢＡメッセージを送信する。ＢＡメッセージに対する応答メッセージは、メッセージ受信部１００１で受信し、メッセージ認証コードを確認し、バインディングキャッシュ管理部１０１１においてバインディングキャッシュを更新する。
なお、上述したように、結合バインディングアップデートの開始側の移動端末と応答側の移動端末の構成が異なっているが、通常はすべての移動端末が開始側にも応答側にもなり得るため、移動端末は上述した開始側と応答側の機能それぞれを有することが好ましい。
次に、結合バインディングアップデートの開始側の移動端末の処理フローについて図１１を用いて説明する。図１１に示すように、移動端末は、バインディングアップデートを行おうとしている相手端末のバインディングキャッシュが存在しているかの確認処理を開始し（ステップＳ１１０１）、相手端末のバインディングキャッシュが存在しているか否かを判断する（ステップＳ１１０２）。バインディングキャッシュが存在する場合、移動端末は、相手端末のホームアドレスを用いたHome Token及び相手端末のＣｏＡを用いたCare-of Tokenを生成する（ステップＳ１１０３）。
そして、移動端末は、Home Tokenを含んだ結合バインディングアップデートのＨｏＴＩメッセージ、Care-of Tokenを含んだ結合バインディングアップデートのＣｏＴＩメッセージをそれぞれ送信する（ステップＳ１１０４）。移動端末は、応答メッセージのＨｏＴメッセージ、ＣｏＴメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１１０５）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１１０６）。
タイムアウト前に応答メッセージを受信した場合、移動端末はＢＵメッセージを生成する。すなわち、移動端末は、受信したＨｏＴ、ＣｏＴに含まれるTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、生成されたメッセージ認証コードを付加したＢＵメッセージを生成し、送信する（ステップＳ１１０７）。移動端末は、応答メッセージのＢＡメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１１０８）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１１０９）。
タイムアウト前に応答メッセージを受信した場合、移動端末は最初に送信したHome Token、Care-of Tokenから鍵データを生成し、ＢＡメッセージに含まれるメッセージ認証コードが正しいか否かの確認処理を開始する（ステップＳ１１１０）。メッセージ認証コードが正しいか否かを判断し（ステップＳ１１１１）、正しいと判断された場合、移動端末は、自身のバインディングキャッシュ及び相手端末のバインディングキャッシュの設定及び更新を行い、応答メッセージを送信する（ステップＳ１１１２）。
なお、ステップＳ１１０２において、バインディングキャッシュが存在しないと判断された場合には、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１１１３）。また、ステップＳ１１０６、Ｓ１１０９において、タイムアウト前に応答メッセージを受信できなかった場合、再送回数が所定の数値Ｎよりも小さければ再送を行う（ステップＳ１１１４、Ｓ１１１５）。また、ステップＳ１１１１において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの更新を行わないことを確認する（ステップＳ１１１６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（結合バインディングアップデートのメッセージの受信からそれに対する応答メッセージを送信するまで）について図１２Ａを用いて説明する。図１２Ａに示すように、移動端末は、ＨｏＴＩ又はＣｏＴＩを受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１２０１）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１２０２）、結合バインディングアップデートのメッセージである場合、受信した開始側の移動端末のHome Token又はCore-of Tokenを保持する（ステップＳ１２０３）。
移動端末は、Home Tokenの場合には両端末のホームアドレスを含め、Care-of Tokenの場合には両端末のＣｏＡを含めたTokenを生成する（ステップＳ１２０４）。生成されたTokenを付加して応答メッセージを生成し、応答メッセージを送信する（ステップＳ１２０５）。なお、ステップＳ１２０２において、結合バインディングアップデートのメッセージではないと判断された場合、移動端末は、従来のＭＩＰのバインディングアップデート処理として応答を送信する（ステップＳ１２０６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（ＢＵメッセージの受信からＢＡメッセージを送信するまで）について図１２Ｂを用いて説明する。図１２Ｂに示すように、移動端末は、ＢＵ（メッセージ）を受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１２１０）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１２１１）、結合バインディングアップデートのメッセージである場合、ＢＵに含まれるアドレス、Nonceの情報を用いてTokenを生成し、Tokenを用いて鍵データを生成し、付加されているメッセージ認証コードの確認処理を開始する（ステップＳ１２１２）。
移動端末は、メッセージ認証コードが正しいか否かを判断し（ステップＳ１２１３）、正しい場合には、バインディングキャッシュの設定、更新を行い、保持していた開始側の移動端末のTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、ＢＡメッセージに含めて送信する（ステップＳ１２１４）。なお、ステップＳ１２１１において、結合バインディングアップデートのメッセージでない場合、移動端末は、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１２１５）。また、ステップＳ１２１３において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの設定、更新を行わないことを確認する（ステップＳ１２１６）。
＜第３の実施の形態＞
第２の実施の形態と同様に、端末Ａが端末Ｂからのバインディングアップデートを受け、端末ＢのホームアドレスB-HoAと気付アドレスB-CoAを知っている状態にあるとする。端末Ａは、端末Ｂにバインディングアップデートを行うとき、端末Ｂのバインディングキャッシュ情報を保持しているかどうかを確認する。保持していない場合には、通常のＭＩＰのバインディングアップデート処理を行う。端末Ａが、端末Ｂのバインディングキャッシュ情報を保持している場合、端末Ａと端末Ｂの両方のバインディングアップデートを同時に行うことを試みる。なお、第３の実施の形態の説明においても、第２の実施の形態の説明で用いた図７を用いて説明する。
端末Ａは、端末ＢのＨｏＡあてにＨｏＴＩを送信する。送信元アドレスは端末ＡのＨｏＡであり、端末Ｂからの応答メッセージＨｏＴは、この送信元アドレスである端末ＡのＨｏＡあてに送信される。メッセージＨｏＴＩには情報Ａ１が含まれる。端末Ｂは、ＨｏＴＩを受信すると、応答メッセージＨｏＴを端末Ａに送信する。端末ＢのＨｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＨｏＡであり、あて先アドレスは要求メッセージＨｏＴＩの送信元アドレスである端末ＡのＨｏＡである。
同様に、端末Ａは、端末ＢのＣｏＡあてにＣｏＴＩを送信する。送信元アドレスは、端末ＡのＣｏＡである。ＣｏＴＩメッセージには情報Ａ２が含まれる。端末Ｂは、ＣｏＴＩを受信すると、応答メッセージＣｏＴを端末Ａに送信する。端末ＢのＣｏＡで受信したメッセージの応答であるため、送信元アドレスは端末ＢのＣｏＡであり、あて先アドレスは要求メッセージＣｏＴＩの送信元アドレスである端末ＡのＣｏＡである。
端末Ａは、応答メッセージのＨｏＴとＣｏＴに含まれる情報Ｂ１とＢ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＵメッセージに認証コードを付加して、端末Ｂに送信する。端末Ｂは、ＢＵメッセージを受信すると認証コードを確認し、端末Ａのバインディングキャッシュが正しいと判定し、寿命（Life Time）を延長する。
そして、応答メッセージであるＢＡを送信する際に、ＨｏＴＩとＣｏＴＩに含まれていた情報Ａ１とＡ２を用いて鍵データを生成し、その鍵データを用いて認証コードを生成し、ＢＡメッセージに認証コードを付加して、端末Ａに送信する。端末Ａは、ＢＡメッセージを受信すると認証コードを確認し、端末Ｂのバインディングキャッシュが正しいと判定し、寿命を延長する。ここまでは第２の実施の形態で同様である。
次に第３の実施の形態におけるバインディング情報更新方式の特徴を説明する。端末Ａから２つの端末のバインディングアップデートを開始する場合、端末Ａから端末Ｂに情報Ａ１とＡ２を送り、端末Ｂに記憶させている。そのためセキュリティの観点から考えたとき、攻撃者が端末Ｂに異なる情報からなるＨｏＴＩ、ＣｏＴＩを大量に送りつけ、情報を覚えさせてメモリーを浪費させるという攻撃（ＤｏＳ攻撃）が想定される。これを防ぐために、端末ＢはＨｏＴＩメッセージ１３０１を受信し、情報Ａ１を取得するとその情報をＨｏＴメッセージ１３０２に含めて端末Ａに送り返すことも可能である。
その様子を図１３に示した。同様に、端末ＢはＣｏＴＩメッセージ１３０３を受信し、情報Ａ２をＣｏＴメッセージ１３０４に含めて端末Ａに送り返す。端末Ａは、送り返された情報Ａ１とＡ２をＢＵメッセージ１３０５に含めて端末Ｂに送信する。端末Ｂは、ＢＵメッセージ１３０５に含まれる情報Ａ１とＡ２を用いて鍵データであるＫｅｙ Ａ（Ａ１、Ａ２）を生成し、認証コードを作成する。そして、端末Ｂは生成されたＫｅｙ Ａ（Ａ１、Ａ２）をＢＡメッセージ１３０６に含めて端末Ａに送信する。なお、端末ＡはＫｅｙ Ａ（Ａ１、Ａ２）を確認し、端末Ｂのバインディングアップデートの承認をした場合、承認完了の旨のメッセージ１３０７を端末Ｂに送信するようにしてもよい。また、端末Ｂは、情報Ａ１及びＡ２を端末Ａに送り返すとき、署名、暗号化して送り返してもよい。署名を検証し、復号化してもとの情報に戻せるのは端末Ｂだけであるので、返送されるまでの間に改竄等される危険を防ぐことができるからである。
ここで、第３の実施の形態におけるメッセージシーケンスについて図１４を用いて詳しく説明する。端末Ａは、ＨｏＴＩにA-Token-hを付加して端末Ｂに送信する。A-Token-hの生成方法は、原理的には任意でよく特に定める必要はない。しかし、従来技術のＭＩＰをできるだけ利用する方法として、次のような生成方法が考えられる。
A-Token-h = HMAC SHA1 (B-HoA, A-Key, nonce)
B-HoAとは端末Ｂのホームアドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがHome Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＨｏＴＩを受信し、ＨｏＴを応答として返す。ＨｏＴにはB-Token-h、B-nonce-h、Sb(A-Token-h)を含める。B-Token-hの計算方法は従来のＭＩＰとは異なる。従来のＭＩＰでは次のようにB-Token-hを計算した。
B-Token-h = HMAC SHA1 (A-HoA, B-Key, B-nonce-h)
本発明の方法では、次のように計算する。
B-Token-h = HMAC SHA1 (A-HoA, B-HoA, B-Key, B-nonce-h)
つまり、端末ＢのホームアドレスB-HoAを加えてB-Token-hを計算する。B-Token-hの計算に用いるA-HoAは、ＨｏＴＩメッセージの送信元アドレスであり、B-HoAはあて先アドレスである。また、ＨｏＴメッセージに含めるSb(A-Token-h)は、端末ＢがA-Token-hを記憶しておくことを回避するための手段である。A-Token-hを暗号化し、端末Ａに送り返し、さらに端末ＡはＢＵに含めて端末Ｂへ送り返す。端末Ｂは、ＢＵに付加されたSb(A-Token-h)を復号化し、A-Token-hを取得し、A-Token-hを用いて鍵データＫｅｙ Ａを生成する。
端末Ａは、ＨｏＴＩの送信と並行して、ＣｏＴＩを送信してもよい。つまり、ＨｏＴを受信する前にＣｏＴＩを送信してもよい。またＨｏＴＩの前にＣｏＴＩを送信してもよい。端末Ａは、ＣｏＴＩにA-Token-cを付加して端末Ｂに送信する。A-Token-cの生成方法は次のような方法が考えられる。
A-Token-c = HMAC SHA1 (B-CoA, A-Key, nonce)
B-CoAとは端末Ｂの気付アドレスであり、A-Keyとは端末Ａの秘密鍵である。nonceは端末ＡがCare-of Tokenを生成するときに使用する乱数である。端末Ｂは、端末ＡからのＣｏＴＩを受信し、ＣｏＴを応答として返す。ＣｏＴには、B-Token-c、B-nonce-c、Sb(A-Token-c)を含める。B-Token-cの計算方法は従来のＭＩＰとは異なり、次のように計算する。
B-Token-c = HMAC SHA1 (A-CoA, B-CoA, B-Key, B-nonce-c)
つまり、端末Ｂの気付アドレスB-CoAを加えてB-Token-cを計算する。B-Token-cの計算に用いるA-CoAは、ＣｏＴＩメッセージの送信元アドレスであり、B-CoAはあて先アドレスである。また、ＣｏＴメッセージに含めるSb(A-Token-c)は、ＨｏＴＩの処理と同様で、端末ＢがA-Token-cを記憶しておくことを回避するための手段である。
端末Ａは、ＨｏＴＩメッセージの応答としてＨｏＴを受信し、ＣｏＴＩメッセージの応答としてＣｏＴを受信すると、それぞれのメッセージに含まれるB-Token-hとB-Token-cを用いて鍵データＫｅｙ Ｂを生成する。
Key B = HMAC SHA1 (B-Token-h, B-Token-c)
端末Ａは、この鍵データを用いてＢＵメッセージの認証コードＢ−ＭＡＣを生成する。
B-MAC = HMAC SHA1 (Key B, BU message)
端末Ａは、ＢＵメッセージに次のデータのB-nonce-h、B-nonce-c、B-MAC、Sb(A-Token-h)、Sb(A-Token-c)、A-HoA、B-HoAを付加して、端末Ｂに送信する。
端末Ｂは、ＢＵメッセージを受信し、B-nonce-h、B-HoA、A-HoAを用いて、B-Token-hを生成する。また、ＢＵメッセージの送信元アドレスA-CoA、あて先アドレスB-CoA、B-nonce-cを用いてB-Token-cを生成する。生成したB-Token-hとB-Token-cを用いて、Ｋｅｙ Ｂを生成し、ＢＵメッセージに付加されているＢ−ＭＡＣが正しいかどうか検査する。Ｂ−ＭＡＣの検査結果が正しい場合には、端末Ｂは端末Ａのバインディングキャッシュの寿命の更新を行う。また新規の設定も可能である。一方、Ｂ−ＭＡＣの検査結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。
また、端末ＢはＢＵメッセージに含まれる情報Sb(A-Token-h)とSb(A-Token-c)の復号処理を行い、A-Token-hとA-Token-cを取得する。そして次のようにＫｅｙ Ａを生成する。
Key A = HMAC SHA1 (A-Token-h, A-Token-c)
端末Ｂはこの鍵データを用いてＢＡメッセージの認証コードＡ−ＭＡＣを生成する。
A-MAC = HMAC SHA1 (Key A, BA message)
端末Ｂは、ＢＡメッセージに、通常のＭＩＰと同様にＫｅｙ Ｂで生成した認証コードＢ−ＭＡＣを付加するとともに、新しいＫｅｙ Ａで生成した認証コードＡ−ＭＡＣを付加する。端末Ａは、ＢＡメッセージを受信し、Ｋｅｙ Ｂ及びＫｅｙ Ａを用いて認証コードを検証し、正しい場合には、端末Ｂのバインディングキャッシュの寿命の更新を行う。認証コードの検証結果が正しくなかった場合には、メッセージを破棄することやエラーメッセージを返すといった対応を取る。
なお、上記ではＫｅｙ ＡとＫｅｙ Ｂを分ける場合で説明したが、合わせて一つの鍵データにしてもよい。例えば、次のように鍵データを生成してもよい。
Key AB = HMAC SHA1 (A-Token-h, A-Token-c, B-Token-h, B-Token-c)
なお、端末ＡがA-Token-h、A-Token-cを記憶する場合について説明したが、ＢＵメッセージにA-nonce-h、A-nonce-cを含め、端末ＢよりＢＡメッセージに含めて折り返してもよい。この場合、端末Ａは、ＢＡメッセージを受信してからA-Token-h、A-Token-cをそれぞれA-nonce-hとA-nonce-cから生成することができ、記憶しておく必要がない。
なお、本発明ではA-Token-h、A-Token-cをそれぞれＨｏＴＩメッセージ、ＣｏＴＩメッセージに乗せたが、ほかの組み合わせであってもよい。例えば、A-Token-hをＣｏＴＩメッセージに乗せ、A-Token-cをＨｏＴＩメッセージに乗せてもよい。また、両方のTokenを同じメッセージに乗せてもよい。さらに、A-Token-h、A-Token-cを分割し、それぞれ分けてＨｏＴ、ＣｏＴメッセージに乗せてもよい。
なお、ＨｏＴＩメッセージを省略することも可能である。例えば、ＣｏＴＩの応答としてＨｏＴとＣｏＴを返すようにし、ＢＵにA-Token-hを含めてもよい。また同様に、ＣｏＴＩを省略することも可能である。この場合は、ＨｏＴＩの応答としてＨｏＴとＣｏＴを返すようにし、ＢＵにA-Token-cを含めてもよい。なお、端末ＡがＨｏＴＩを送信後、ＨｏＴを受信してからＣｏＴＩを送信してもよい。ＨｏＴに含まれる情報をＡが保持するのではなく、ＣｏＴＩに含めて送信し、ＣｏＴで折り返されるようにしてもよい。
なお、端末Ｂが従来ＭＩＰにしか対応していない端末の場合には、従来ＭＩＰは端末ＡからのＨｏＴＩ及びＣｏＴＩに対して、従来ＭＩＰと同様のＨｏＴ及びＣｏＴを返信する。端末Ａは、それによって端末Ｂが本発明のバインディングアップデートに対応していないことがわかるため、従来のＭＩＰのＢＵメッセージを送信する。
また、端末Ａと端末Ｂが同時に本発明のバインディングアップデートを行った場合には、次のような対応が考えられる。両方のバインディングアップデートをそのまま行ってもよい。ＨｏＴ、ＣｏＴを受信してからＢＵを送信するまでの待ち時間をランダムに設定することによって、一方のＢＵの送信を回避しやすくしてもよい。
また、両端末のバインディングアップデートを行った場合には、開始側と受信側のバインディングキャッシュの寿命の長さを変えてもよい。受信側の寿命をわずかに短くすることによって、次のバインディングアップデートの開始側が交代するようにしてもよい。なお、本発明の結合バインディングアップデート処理は、移動端末自ら行うのではなく、代理ノードが行ってもよい。
次に、結合バインディングアップデートの開始側の移動端末について図１５を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの送信について説明する。メッセージ作成部１５０１は、結合バインディング判定部１５０２に通常のバインディングアップデートか、結合バインディングアップデートかの判定を要求する。結合バインディング判定部１５０２は、バインディングキャッシュ管理部１５０３に、これからバインディングアップデートを行う相手通信端末からのバインディングキャッシュが登録されているかどうかを確認する。登録されていない場合には、通常のバインディングアップデートを行う。
結合バインディングアップデートを行う場合には、メッセージ作成部１５０１はＡ−Ｔｏｋｅｎ生成部１５０４によってHome Token（A-Token-h）及びCare-of Token（A-Token-c）を生成し、そのTokenを付加してＨｏＴＩメッセージ及びＣｏＴＩメッセージを生成し、メッセージ送信部１５０５より送信する。Ａ−Ｔｏｋｅｎ生成部１５０４で作成したHome Token及びCare-of TokenはＡ−Ｔｏｋｅｎ保存部１５０６において保存しておく。
次に、ＨｏＴ／ＣｏＴの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージの応答メッセージであるＨｏＴ及びＣｏＴメッセージは、メッセージ受信部１５０７によって受信される。受信したＨｏＴ及びＣｏＴに含まれる相手端末が生成したToken（B-Token-h、B-Token-c）及びNonce-ID（応答側移動端末がNonceの値を呼び出すための識別番号）はＢ−Ｔｏｋｅｎ保存部１５０８及びＮｏｎｃｅ保存部１５０９に保存される。また、相手端末によって付加されたSb(Home Token)及びSb(Care-of Token)は、Ｓｂ（Ｔｏｋｅｎ）保存部１５１０に保存される。
次に、ＢＵの送信について説明する。ＨｏＴメッセージとＣｏＴメッセージの両方を受信したとき、Ｂ−Ｔｏｋｅｎ保存部１５０８にはHome Token（B-Token-h）とCare-of Token（B-Token-c）の両方のTokenが揃っているため、それらのTokenを用いてＢ−Ｋｅｙ生成部１５１１において鍵データを生成する。
メッセージ認証コード生成部１５１２は、Ｂ−Ｋｅｙ生成部１５１１において生成された鍵データを用いてメッセージ認証コードを生成し、メッセージ作成部１５０１に渡す。メッセージ作成部１５０１では、生成されたメッセージ認証コードとＳｂ（Ｔｏｋｅｎ）保存部１５１０に保存しておいた２つのSb(Home Token)及びSb(Care-of Token)をＢＵメッセージに付加する。またＮｏｎｃｅ保存部１５０９に保存しておいたNonce-IDもＢＵメッセージに付加する。そして、メッセージ送信部１５０５よりＢＵメッセージを送信する。
次に、ＢＡの受信について説明する。ＢＡメッセージをメッセージ受信部１５０７で受信し、メッセージ認証コード判定部１５１５においてメッセージの判定を行う。メッセージの判定のために、Ａ−Ｋｅｙ生成部１５１４は、Ａ−Ｔｏｋｅｎ保存部１５０６に保存しておいたHome Token（A-Token-h）とCare-of Token（A-Token-c）を取り出し、鍵データを生成する。メッセージ認証コード生成部１５１２は、Ａ−Ｋｅｙ生成部１５１４により生成された鍵データを用いてメッセージ認証コードを生成する。メッセージ認証コード判定部１５１３は、その生成したメッセージ認証コードと、ＢＵメッセージに付加されていたメッセージ認証コードとを比較し、一致するかどうか判定する。
メッセージ認証コードが一致した場合には、バインディングキャッシュ管理部１５０３にバインディングキャッシュを登録する。その後で、ＢＡメッセージに対する応答をメッセージ作成部１５０１において作成し、メッセージ送信部１５０５より送信する。
次に、結合バインディングアップデートの応答側の移動端末について図１６を用いて説明する。まず、ＨｏＴＩ／ＣｏＴＩの受信について説明する。ＨｏＴＩ及びＣｏＴＩメッセージをメッセージ受信部１６０１で受信し、結合バインディングアップデートの場合には、メッセージに含まれるHome Token（A-Token-h）又はCare-of Token（A-Token-c）をＡ−Ｔｏｋｅｎ暗号・復号処理部１６０２に渡す。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３はB-Token（Home Token又はCare-of Token）を生成する。B-Tokenを生成するときに必要なNonce(home nonce又はcare-of nonce)はＮｏｎｃｅ管理部１６０４より取得する。
B-Home Token = SHA1 (A-HoA, B-HoA, B-Key, B-home nonce)
B-Care-of Token = SHA1 (A-CoA, B-CoA, B-Key, B-care-of nonce)
次に、ＨｏＴ／ＣｏＴの送信について説明する。Ａ−Ｔｏｋｅｎ暗号・復号処理部１６０２は、暗号化したデータ（Sb(Home Token（A-Token-h）)又はSb(Care-of Token（A-Token-c）)）をメッセージ作成部１６０５に渡し、メッセージ作成部１６０５は応答メッセージに付加する。また、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３より生成したToken（B-Token）及び生成に用いたNonceを呼び出すためのNonce-IDを取得し、応答メッセージに付加する。応答メッセージは受信メッセージがＨｏＴＩの場合にはＨｏＴメッセージであり、ＣｏＴＩの場合にはＣｏＴメッセージである。メッセージ作成部１６０５が作成した応答メッセージは、メッセージ送信部１６０６から送信される。
次に、ＢＵの受信について説明する。ＢＵメッセージをメッセージ受信部１６０１で受信し、結合バインディングアップデートの場合には、結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３においてHome Token（B-Token-h）及びCare-of Token（B-Token-c）を生成する。Token生成のときには、受信したＢＵメッセージに含まれるNonce-IDを用いてＮｏｎｃｅ管理部１６０４からNonceの値を取り出し、それを用いる。また、ＢＵメッセージに含まれるSb(Home Token)及びSb(Care-of Token)をＡ−Ｔｏｋｅｎ暗号・復号処理部１６０２に渡し、復号化し、元のHome Token（A-Token-h）及びCare-of Token（A-Token-c）を取得する。
また、ＢＵメッセージに含まれるメッセージ認証コードをメッセージ認証コード比較部１６０７に渡す。結合バインディングＢ−Ｔｏｋｅｎ生成部１６０３で生成したHome Token（B-Token-h）及びCare-of Token（B-Token-c）をＢ−Ｋｅｙ生成部１６０８に渡し、Ｂ−Ｋｅｙ生成部１６０８において鍵データを生成する。
そして、生成した鍵データを用いて、メッセージ認証コード生成部１６０９において、メッセージ認証コードを生成する。生成したメッセージ認証コードとＢＵメッセージに含まれていたメッセージ認証コードが一致するかどうかをメッセージ認証コード比較部１６０７で比較する。メッセージ認証コードが一致した場合は、バインディングキャッシュ管理部１６１０にバインディングキャッシュを設定又は更新する。
次に、ＢＡの送信について説明する。Ａ−Ｔｏｋｅｎ暗号・復号処理部１６０２によって復号化されたToken（A-Token-h、A-Token-c）を用いてＡ−Ｋｅｙ生成部１６１１において鍵データを生成し、メッセージ認証コード生成部１６０９でメッセージ認証コードを生成する。メッセージ作成部１６０５は、生成したメッセージ認証コードをＢＡメッセージに付加し、メッセージ送信部１６０６よりＢＡメッセージを送信する。ＢＡメッセージに対する応答メッセージは、メッセージ受信部１６０１で受信し、メッセージ認証コードを確認し、バインディングキャッシュ管理部１６１０においてバインディングキャッシュを更新する。
次に、結合バインディングアップデートの開始側の移動端末の処理フローについて図１７を用いて説明する。図１７に示すように、移動端末は、バインディングアップデートを行おうとしている相手端末のバインディングキャッシュが存在しているかの確認処理を開始し（ステップＳ１７０１）、相手端末のバインディングキャッシュが存在しているか否かを判断する（ステップＳ１７０２）。バインディングキャッシュが存在する場合、移動端末は、相手端末のホームアドレスを用いたHome Token（A-Token-h）及び相手端末のＣｏＡを用いたCare-of Token（A-Token-c）を生成する（ステップＳ１７０３）。
そして、移動端末は、Home Tokenを含んだ結合バインディングアップデートのＨｏＴＩメッセージ、Care-of Tokenを含んだ結合バインディングアップデートのＣｏＴＩメッセージをそれぞれ送信する（ステップＳ１７０４）。移動端末は、応答メッセージのＨｏＴメッセージ、ＣｏＴメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１７０５）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１７０６）。
タイムアウト前に応答メッセージを受信した場合、移動端末はＢＵメッセージを生成する。すなわち、移動端末は、受信したＨｏＴ、ＣｏＴに含まれるTokenを用いて鍵データを生成し、メッセージ認証コードを生成し、生成されたメッセージ認証コード、ＨｏＴ、ＣｏＴに含まれていたSb(Home Token（A-Token-h）)、Sb(Care-of Token（A-Token-c）)を付加したＢＵメッセージを生成し、送信する（ステップＳ１７０７）。移動端末は、応答メッセージのＢＡメッセージを待つと同時にタイマーをスタートさせる（ステップＳ１７０８）。移動端末は、タイムアウト前に応答（メッセージ）を受信したか否かを判断する（ステップＳ１７０９）。
タイムアウト前に応答メッセージを受信した場合、移動端末は最初に送信したHome Token（A-Token-h）、Care-of Token（A-Token-c）から鍵データを生成し、ＢＡメッセージに含まれるメッセージ認証コードが正しいか否かの確認処理を開始する（ステップＳ１７１０）。メッセージ認証コードが正しいか否かを判断し（ステップＳ１７１１）、正しいと判断された場合、移動端末は、自身のバインディングキャッシュ及び相手端末のバインディングキャッシュの設定及び更新を行い、応答メッセージを送信する（ステップＳ１７１２）。
なお、ステップＳ１７０２において、バインディングキャッシュが存在しないと判断された場合には、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１７１３）。また、ステップＳ１７０６、Ｓ１７０９において、タイムアウト前に応答メッセージを受信できなかった場合、再送回数が所定の数値Ｎよりも小さければ再送を行う（ステップＳ１７１４、Ｓ１７１５）。また、ステップＳ１７１１において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの更新を行わないことを確認する（ステップＳ１７１６）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（結合バインディングアップデートのメッセージの受信からそれに対する応答メッセージを送信するまで）について図１８Ａを用いて説明する。図１８Ａに示すように、移動端末は、ＨｏＴＩ又はＣｏＴＩを受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１８０１）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１８０２）、結合バインディングアップデートのメッセージである場合、Home Tokenの場合には両端末のホームアドレスを含めたTokenを生成し、Care-of Tokenの場合には両端末のＣｏＡを含めたTokenを生成する（ステップＳ１８０３）。
移動端末は、ＨｏＴＩ、ＣｏＴＩに付加されていたToken（A-Token-h、A-Token-c）を暗号化し、応答メッセージを生成し、送信する（ステップＳ１８０４）。なお、ステップＳ１８０２において、結合バインディングアップデートのメッセージではないと判断された場合、移動端末は、従来のＭＩＰのバインディングアップデート処理として応答を送信する（ステップＳ１８０５）。
次に、結合バインディングアップデートの応答側の移動端末の処理フロー（ＢＵメッセージの受信からＢＡメッセージを送信するまで）について図１８Ｂを用いて説明する。図１８Ｂに示すように、移動端末は、ＢＵ（メッセージ）を受信し、結合バインディングアップデートのメッセージかどうかの判定処理を開始する（ステップＳ１８１０）。移動端末は、結合バインディングアップデートのメッセージか否かを判断し（ステップＳ１８１１）、結合バインディングアップデートのメッセージである場合、ＢＵに含まれるアドレス、Nonceの情報を用いてToken（B-Token-h、B-Token-c）を生成し、Tokenを用いて鍵データを生成し、付加されているメッセージ認証コードの確認処理を開始する（ステップＳ１８１２）。
移動端末は、メッセージ認証コードが正しいか否かを判断し（ステップＳ１８１３）、正しい場合には、バインディングキャッシュの設定、更新を行い、ＢＵに含まれている暗号化されたToken（A-Token-h、A-Token-c）を復号化し、鍵データを生成し、メッセージ認証コードを生成し、ＢＡメッセージに含めて送信する（ステップＳ１８１４）。なお、ステップＳ１８１１において、結合バインディングアップデートのメッセージでない場合、移動端末は、従来のＭＩＰのバインディングアップデートを開始する（ステップＳ１８１５）。また、ステップＳ１８１３において、メッセージ認証コードが正しくないと判断された場合、バインディングキャッシュの設定、更新を行わないことを確認する（ステップＳ１８１６）。
なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明に係るバインディング更新方法及びその方法で用いられる移動端末は、両端末が行うバインディングアップデートにおいて必要なメッセージ数を減少させることができ、メッセージ数の削減により端末の消費電力を削減でき、さらに両端末のバインディングアップデートにかかる処理時間を短縮できるため、バインディングアップデートにより経路の最適化がなされた通信端末間のバインディングを更新するバインディング更新方法及びその方法で用いられる移動端末などに有用である。
本発明の第１の実施の形態におけるメッセージ数の削減について説明するための図 本発明の第１の実施の形態におけるメッセージ数の削減について説明するための他の図 本発明の第１の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第１の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第２の実施の形態を説明するためのＭＩＰの基本原理について説明するための図 本発明の第２の実施の形態を説明するためのＭＩＰの基本原理について説明するための他の図 本発明の第２の実施の形態におけるメッセージ数の削減について説明するための図 本発明の第２の実施の形態についてさらに詳細に説明するための図 本発明の第２の実施の形態における両端末間での情報のやりとりの様子を示す図 本発明の第２の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第２の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第２の実施の形態における結合バインディングアップデートの開始側の移動端末の処理フローの一例を示すフローチャート 本発明の第２の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの一部を示すフローチャート 本発明の第２の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの他の一部を示すフローチャート 本発明の第３の実施の形態におけるメッセージ数の削減について説明するための他の図 本発明の第３の実施の形態における両端末間での情報のやりとりの様子を示す図 本発明の第３の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の第３の実施の形態に係る他の移動端末の構成の一例を示す構成図 本発明の第３の実施の形態における結合バインディングアップデートの開始側の移動端末の処理フローの一例を示すフローチャート 本発明の第３の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの一部を示すフローチャート 本発明の第３の実施の形態における結合バインディングアップデートの応答側の移動端末の処理フローの他の一部を示すフローチャート 従来の両端末間で行われるバインディングアップデートを説明するための図 従来の両端末間で行われるバインディングアップデートを説明するための他の図

Claims (12)

  1. 第１の移動端末と、前記第１の移動端末の通信相手である第２の移動端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法であって、
    前記第１の移動端末が前記第２の移動端末のバインディング情報を保持している場合に、
    前記第１の移動端末が、所定の第１移動端末情報を含めたメッセージであって、前記第２の移動端末から所定の第２移動端末情報を取得するための第１の１組のメッセージを前記第２の移動端末へ送信するステップと、
    前記第２の移動端末が、前記所定の第２移動端末情報を含めた第２の１組のメッセージを前記第１の移動端末へ送信するステップと、
    前記第１の移動端末が、前記第２の１組のメッセージに含まれた前記所定の第２移動端末情報に基づいて生成された認証情報を付加した第３のメッセージを前記第２の移動端末へ送信するステップと、
    前記第２の移動端末が、前記第３のメッセージに対する応答情報を含めたメッセージであって、前記所定の第１移動端末情報に基づいて生成された認証情報を付加した第４のメッセージを前記第１の移動端末へ送信するとともに、前記第１の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップと、
    前記第１の移動端末が、前記第４のメッセージに付加された前記第２の移動端末からの前記認証情報が正当である場合に前記バインディング情報を更新するステップとを、
    有するバインディング更新方法。
  2. 前記第２の移動端末は、前記所定の第１移動端末情報を前記第２の１組のメッセージに含めて前記第１の移動端末へ送信し、
    前記第１の移動端末は、前記第２の１組のメッセージに含まれる前記所定の第１移動端末情報を前記第３のメッセージに含めて前記第２の移動端末へ送信する請求項１に記載のバインディング更新方法。
  3. 前記第２の移動端末は、前記所定の第１移動端末情報を前記第２の移動端末のみが復号できる形式で前記第２の１組のメッセージに含めて送信する請求項２に記載のバインディング更新方法。
  4. 前記所定の第１移動端末情報は、前記第２の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記所定の第２移動端末情報は、前記第１の移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記第１の１組のメッセージは、前記第２の移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、
    前記第２の１組のメッセージは、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、
    前記第３のメッセージは、前記第２の移動端末へのバインディングアップデートメッセージであり、
    前記第４のメッセージは、前記第１の移動端末へのバインディングアップデートメッセージである請求項１に記載のバインディング更新方法。
  5. 移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、
    前記移動端末が前記通信相手端末のバインディング情報を保持している場合に、
    所定の移動端末情報を含めたメッセージであって、前記通信相手端末から所定の通信相手端末情報を取得するための第１の１組のメッセージを生成するメッセージ生成手段と、
    生成された前記第１の１組のメッセージを前記通信相手端末へ送信する送信手段と、
    前記所定の通信相手端末情報を含めた第２の１組のメッセージを前記通信相手端末から受信する受信手段と、
    受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、
    前記バインディング情報を更新する更新手段とを備え、
    前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、
    前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信し、
    前記更新手段が、前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当であるか否かを判断し、正当である場合に前記バインディング情報を更新する移動端末。
  6. 移動端末と、前記移動端末の通信相手である通信相手端末との間の経路最適化を実現可能とさせるバインディング情報を更新するバインディング更新方法で用いられる前記移動端末であって、
    所定の通信相手端末情報を含めたメッセージであって、前記移動端末から所定の移動端末情報を取得するための第１の１組のメッセージを受信する受信手段と、
    前記所定の移動端末情報を含めた第２の１組のメッセージを生成するメッセージ生成手段と、
    生成された前記第２の１組のメッセージを前記通信相手端末へ送信する送信手段と、
    前記受信手段を介して受信した前記所定の通信相手端末情報に基づいて認証情報を生成する認証情報生成手段と、
    前記受信手段を介して受信した情報であって、前記所定の移動端末情報に基づいて前記通信相手端末により生成された認証情報が正当である場合に前記バインディング情報を更新する更新手段とを備え、
    前記メッセージ生成手段が、前記認証情報生成手段によって生成された前記認証情報を付加した第３のメッセージを生成し、
    前記送信手段が、生成された前記第３のメッセージを前記通信相手端末へ送信する移動端末。
  7. 前記メッセージ生成手段は、前記第２の１組のメッセージに含まれる前記所定の移動端末情報を含めた前記第３のメッセージを生成する請求項５に記載の移動端末。
  8. 前記メッセージ生成手段は、前記第１の１組のメッセージに含まれる前記所定の通信相手端末情報を含めた前記第２の１組のメッセージを生成する請求項６に記載の移動端末。
  9. 前記メッセージ生成手段は、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第３のメッセージに含める請求項７に記載の移動端末。
  10. 前記メッセージ生成手段は、前記所定の通信相手端末情報を前記移動端末自身のみが復号できる形式で前記第２の１組のメッセージに含める請求項８に記載の移動端末。
  11. 前記所定の移動端末情報は、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記所定の通信相手端末情報は、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記第１の１組のメッセージは、前記通信相手端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、
    前記第２の１組のメッセージは、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、
    前記第３のメッセージは、前記通信相手端末へのバインディングアップデートメッセージである請求項５に記載の移動端末。
  12. 前記所定の通信相手端末情報は、前記移動端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記所定の移動端末情報は、前記通信相手端末のホームアドレス及び気付けアドレス（ＣｏＡ：Ｃａｒｅ Ｏｆ Ａｄｄｒｅｓｓ）を基に生成されたトークン（Ｔｏｋｅｎ）であり、
    前記第１の１組のメッセージは、前記移動端末に対するホームアドレステスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ）及び気付けアドレステスト（Ｃａｒｅ−Ｏｆ Ｔｅｓｔ Ｉｎｉｔ）の開始を要求するメッセージであり、
    前記第２の１組のメッセージは、前記第１の１組のメッセージに応答するＨｏＴメッセージ及びＣｏＴメッセージであり、
    前記第３のメッセージは、前記通信相手端末へのバインディングアップデートメッセージである請求項６に記載の移動端末。
JP2009549913A 2008-01-18 2008-12-26 バインディング更新方法及びその方法で用いられる移動端末 Withdrawn JPWO2009090722A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2008009457 2008-01-18
JP2008009457 2008-01-18
PCT/JP2008/004020 WO2009090722A1 (ja) 2008-01-18 2008-12-26 バインディング更新方法及びその方法で用いられる移動端末

Publications (1)

Publication Number Publication Date
JPWO2009090722A1 true JPWO2009090722A1 (ja) 2011-05-26

Family

ID=40885133

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009549913A Withdrawn JPWO2009090722A1 (ja) 2008-01-18 2008-12-26 バインディング更新方法及びその方法で用いられる移動端末

Country Status (3)

Country Link
US (1) US20100278112A1 (ja)
JP (1) JPWO2009090722A1 (ja)
WO (1) WO2009090722A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009087738A1 (ja) * 2008-01-09 2009-07-16 Panasonic Corporation バインディング更新方法及びその方法で用いられる移動端末
EP2509277A1 (en) 2011-04-05 2012-10-10 Research In Motion Limited System and method for shared binding maintenance
CN104660416B (zh) * 2015-02-13 2018-08-28 飞天诚信科技股份有限公司 一种语音认证系统和设备的工作方法
CN110730063B (zh) * 2018-07-16 2022-11-11 中国电信股份有限公司 安全验证方法、系统、物联网平台、终端和可读存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE503357T1 (de) * 2003-08-06 2011-04-15 Motorola Inc Verfahren zur validierten kommunikation
EP1933520A1 (en) * 2006-12-15 2008-06-18 Matsushita Electric Industrial Co., Ltd. Local mobility anchor relocation and route optimization during handover of a mobile node to another network area

Also Published As

Publication number Publication date
US20100278112A1 (en) 2010-11-04
WO2009090722A1 (ja) 2009-07-23

Similar Documents

Publication Publication Date Title
JP4841842B2 (ja) 移動無線通信装置におけるコンタクトの認証及び信頼できるコンタクトの更新
JP6382241B2 (ja) リンク設定および認証を実行するシステムおよび方法
CN1714560B (zh) 移动ip中的动态会话密钥产生及密钥重置的方法和装置
US7881468B2 (en) Secret authentication key setup in mobile IPv6
CN101965722B (zh) 安全性关联的重新建立
ES2263811T3 (es) Procedimiento para auntentificacion de usuario en un terminal, sistema de autentificacion, terminal y dispositivo de autorizacion.
CN101176328A (zh) 用于保护前缀范围绑定更新的安全的系统、关联方法和设备
JP2010532107A (ja) ソフトｓｉｍクレデンシャルのセキュア転送
JP2012110009A (ja) エンティティの認証と暗号化キー生成の機密保護されたリンクのための方法と構成
JP2007036641A (ja) ホームエージェント装置、及び通信システム
JP4536934B2 (ja) セルラー通信システム用認証方法
KR20060052969A (ko) 승인된 통신 방법
WO2008040178A1 (fr) Procédé et dispositif de mise à jour d'association entre un noeud mobile et un noeud correspondant
WO2009090722A1 (ja) バインディング更新方法及びその方法で用いられる移動端末
KR101767889B1 (ko) 단말 식별 방법 및 이를 위한 장치
KR100522600B1 (ko) 모바일 노드와의 접속을 제공하는 라우터 및 그 라우팅 방법
WO2009012676A1 (fr) Procédé et équipement pour générer une adresse temporaire, procédé et système pour améliorer la sécurité d'optimisation de route
JP4462554B2 (ja) 経路修復方法およびシステム
JPWO2009066439A1 (ja) 通信方法、通信システム、モバイルノード及び通信ノード
US8145906B2 (en) Binding update method in MIPv6
JPWO2008087999A1 (ja) 通信方法、通信システム、移動通信装置及び相手先通信装置
CN102484659A (zh) 用于生成移动ip网络中密码生成地址的方法和网络节点
Yang et al. A secure mobile IP registration protocol
JP2007281892A (ja) 秘密鍵生成装置および秘密鍵生成方法
WO2009087738A1 (ja) バインディング更新方法及びその方法で用いられる移動端末

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111027

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20120405