(57)【特許請求の範囲】
【請求項１】
端末に対してセキュア通信に関する処理の支援を行う端末支援装置であって、
前記端末支援装置の負荷を監視する負荷監視手段と、
セキュア通信に関する処理の支援を実行する支援手段と、
前記端末支援装置に接続される全ての端末に対して前記支援を実行する方式である第１の方式と、前記端末支援装置に接続される端末に対して前記支援を実行するか否かを当該端末の性能に基づき判定し、実行すると判定される場合に当該支援を実行する方式である第２の方式とを、前記負荷に基づき切り替え、前記負荷が所定の閾値以上である場合に、前記端末支援装置に接続される端末の優先度に基づき前記支援を行うか否かを判定する第３の方式への切り替えを行う切替手段と
を備えることを特徴とする端末支援装置。
【請求項２】
前記切替手段は、前記端末の優先度を、少なくとも、当該端末の移動度指標と当該端末の位置情報のいずれかから判定する
ことを特徴とする請求項１に記載の端末支援装置。
【請求項３】
前記端末支援装置が、前記第１の方式を用いている場合において、前記切替手段は、前記第１の方式における１端末当たりの負荷が、前記第２の方式における１端末当たりの負荷の期待値よりも大きくなった場合に、前記第１の方式から前記第２の方式への切り替えを行う
ことを特徴とする請求項１又は２に記載の端末支援装置。
【請求項４】
端末に対してセキュア通信に関する処理の支援を行う端末支援装置が実行する端末支援方法であって、
前記端末支援装置の負荷を監視する負荷監視ステップと、
前記端末支援装置に接続される全ての端末に対して前記支援を実行する方式である第１の方式と、前記端末支援装置に接続される端末に対して前記支援を実行するか否かを当該端末の性能に基づき判定し、実行すると判定される場合に当該支援を実行する方式である第２の方式とを、前記負荷に基づき切り替え、前記負荷が所定の閾値以上である場合に、前記端末支援装置に接続される端末の優先度に基づき前記支援を行うか否かを判定する第３の方式への切り替えを行う切替ステップと、
前記切替ステップで切り替えられた方式に基づいて、セキュア通信に関する処理の支援を実行する支援ステップと
を備えることを特徴とする端末支援方法。
【請求項５】
前記切替ステップにおいて、前記端末支援装置は、前記端末の優先度を、少なくとも、当該端末の移動度指標と当該端末の位置情報のいずれかから判定する
ことを特徴とする請求項４に記載の端末支援方法。
【請求項６】
前記端末支援装置は、前記第１の方式を用いている場合に、前記切替ステップにおいて、前記第１の方式における１端末当たりの負荷が、前記第２の方式における１端末当たりの負荷の期待値よりも大きくなった場合に、前記第１の方式から前記第２の方式への切り替えを行う
ことを特徴とする請求項４又は５に記載の端末支援方法。
【請求項７】
コンピュータを、請求項１ないし３のうちいずれか１項に記載の端末支援装置における各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、M2M（Machine-to-Machine）/IoT（Internet of Things)通信システムに関連するものであり、特に、M2M/IoT通信システムにおいて使用されるM2M/IoT端末の処理を支援する技術に関連するものである。
【背景技術】
【０００２】
有線・無線のネットワーク技術、及び、端末技術の発展により、これまでネットワークに繋がっていなかった家電やセンサ等のあらゆるモノがネットワークに繋がるInternet of things (IoT)や、人の手を介することなく動作するMachine-to-Machine（M2M）の普及が予想されている。
【０００３】
なお、M2M/IoTサービスを提供する通信システムには種々の形態があるが、ここでは、例として、M2M/IoT-GW（ゲートウェイ）を介してM2M/IoT端末をネットワークに収容するGW収容型の通信システムを対象とする。
【０００４】
M2M/IoTの普及に伴い、これまでネットワークとの接点が無かった端末が、ネットワークと接点を持つことで、利便性が格段に向上する一方で、これまで考慮する必要が無かったネットワーク側からの脅威に対して、適切な対策を施す必要がある。例えば、これまで電気メータの検針は、電気メータが設置されている場所に人を派遣して、目視で値を読み取ることで実現していた。これに対して、スマートメータと呼ばれる、ネットワークに繋がった電気メータは、自動で値を記録し、ネットワーク経由でその値を転送できるため、現地に人を派遣する必要が無くなり、人件費のコスト削減等が期待できる。しかし、スマートメータのデータから、ユーザの在宅時間や行動パターンを類推できてしまう可能性があるため、スマートメータでやり取りされるデータを悪意のある第三者に盗み見されないよう対策を行う必要がある。
【０００５】
このように、端末をネットワークに繋げたことで、ネットワーク側からの脅威に対して、適切な対策を施す必要がある。
【０００６】
しかし、スマートメータをはじめとするM2M/IoT端末は、従来からネットワークに繋がっているパソコンやスマートフォンよりもコスト要件が厳しく、処理性能やメモリ、そして、電力等において、様々な制約があることが予想される。このため、既存のセキュリティ技術を適用できない、若しくは、適用することが非効率な場合がある。
【０００７】
上記の問題に対して、様々な検討が行われているが、例えば非特許文献１では、ある程度性能があるエンティティを導入し、低機能な端末が本来行うべきセキュリティ処理の一部をある程度性能があるエンティティに肩代わりしてもらうことでセキュリティを実現する技術が開示されている。
【０００８】
また、非特許文献２には、M2M/IoT-GW が、M2M/IoT-GWに繋がってきた端末の性能を推定してから、セキュリティ処理の支援が必要な低機能な端末のみを、非特許文献１の支援技術を利用して支援する技術が開示されている。端末の性能の推定方法としては、端末情報から推定する方法や、端末に対してTLS/DTLSを確立するためのHandshakeを試み、Handshakeを完遂できるM2M/IoT端末は高機能、完遂できないM2M/IoT端末は低機能とする等の方法がある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】R. Hummen, H. Shafagh, S. Raza, T. Voigt, K. Wehrle, "Delegation-based Authentication and Authorization for the IP-based Internet of Things," in Proceedings of Sensing, Communication, and Networking (SECON), pp.284-292, 2014.
【非特許文献２】M2M/IoT端末のセキュリティを必要に応じてネットワークで支援可能なアーキテクチャに関する位置検討,信学技報, vol. 115, no. 209, NS2015-83, pp. 71-76, 2015年9月
【非特許文献３】"The Transport Layer Security (TLS) Protocol Version 1.2" RFC 5246, IETF, 2008.
【非特許文献４】"E. Rescorla and N. Modadugu. Datagram Trinsport Layer Security Version 1.2" RFC 6347, IETF, 2012.
【非特許文献５】"Transport Layer Security (TLS) Session Resumption without Server-Side State" RFC 5077, IETF, 2008.
【発明の概要】
【発明が解決しようとする課題】
【００１０】
以下、M2M/IoT-GWに繋がってきた全ての端末に対してセキュリティ処理の支援を行う方式を方式Ａとし、上記の非特許文献２に開示されているように、端末の性能を推定してから、低機能な端末のみに対してセキュリティ処理の支援を行う方式を方式Ｂと呼ぶことにする。
【００１１】
方式Ａと方式Ｂとを比較すると、M2M/IoT-GWの負荷を抑制する観点では方式Ｂが有効だが、端末に対する支援処理時間の観点では方式Ａの方が有効である。これを図１を参照して説明する。図１は、端末からM2M/IoT-GWに到着するリクエストに対するM2M/IoT-GWの処理負荷と支援処理時間を、（ａ）方式Ａと、（ｂ）方式Ｂについて示した図である。なお、図１の（ｂ）方式Ｂについては、低機能端末の場合を示している。図中のtaは、支援に用いる処理時間であり、laは支援に用いる処理負荷であり、tdは、支援要否判定（端末性能推定等）に用いる時間であり、ldは支援要否判定に用いる処理負荷である。
【００１２】
図１に示すように、方式Ａでは、全ての端末に対して処理負荷laがかかる。一方、方式Ｂでは、低機能端末については、処理負荷ldと処理負荷laがかかるが、高機能端末については、処理負荷のみしかかからない。
【００１３】
しかし、方式Ａでは、支援処理時間が全ての端末に対してtaであるのに対し、方式Ｂでは、支援処理時間として、全ての端末に対してtdがかかり、低機能端末に対してはtaが更にかかる。支援処理時間が長いと、端末はデータ送信開始までにかかる時間（以下応答時間）が長くなり、利便性が低下する。このように、端末への応答時間とM2M/IoT-GWの負荷とはトレードオフの関係にあり、これらをバランスよく制御する技術が求められている。
【００１４】
本発明は上記の点に鑑みてなされたものであり、端末のセキュア通信に関する処理を支援する装置において、端末への応答時間と当該装置の負荷とを適切に制御することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の実施の形態によれば、端末に対してセキュア通信に関する処理の支援を行う端末支援装置であって、
前記端末支援装置の負荷を監視する負荷監視手段と、
セキュア通信に関する処理の支援を実行する支援手段と、
前記端末支援装置に接続される全ての端末に対して前記支援を実行する方式である第１の方式と、前記端末支援装置に接続される端末に対して前記支援を実行するか否かを当該端末の性能に基づき判定し、実行すると判定される場合に当該支援を実行する方式である第２の方式とを、前記負荷に基づき切り替え、前記負荷が所定の閾値以上である場合に、前記端末支援装置に接続される端末の優先度に基づき前記支援を行うか否かを判定する第３の方式への切り替えを行う切替手段と
を備えることを特徴とする端末支援装置が提供される。
【００１６】
また、本発明の実施の形態によれば、端末に対してセキュア通信に関する処理の支援を行う端末支援装置が実行する端末支援方法であって、
前記端末支援装置の負荷を監視する負荷監視ステップと、
前記端末支援装置に接続される全ての端末に対して前記支援を実行する方式である第１の方式と、前記端末支援装置に接続される端末に対して前記支援を実行するか否かを当該端末の性能に基づき判定し、実行すると判定される場合に当該支援を実行する方式である第２の方式とを、前記負荷に基づき切り替え、前記負荷が所定の閾値以上である場合に、前記端末支援装置に接続される端末の優先度に基づき前記支援を行うか否かを判定する第３の方式への切り替えを行う切替ステップと、
前記切替ステップで切り替えられた方式に基づいて、セキュア通信に関する処理の支援を実行する支援ステップと
を備えることを特徴とする端末支援方法が提供される。
【発明の効果】
【００１７】
本発明の実施の形態によれば、端末のセキュア通信に関する処理を支援する装置において、端末への応答時間と当該装置の負荷とを適切に制御することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】方式Ａと方式Ｂの支援処理時間を示す図である。
【図２】本発明の実施の形態における通信システムの全体構成図である。
【図３】本発明の実施の形態における端末支援システムの機能構成図である。
【図４】M2M/IoT-GWの動作の概要を説明するための図である。
【図５】方式Ｃにおける低機能端末に対する支援処理時間を説明するための図である。
【図６】GWにおける負荷と、支援処理時間の推移の例を説明するための図である。
【図７】方式Ｃにおける優先順位の決定方法の例を説明するための図である。
【図８】データベースの情報の例を示す図である。
【図９】方式Ｃにおける優先順位の決定方法の例を説明するための図である。
【図１０】データベースの情報の例を示す図である。
【図１１】端末支援システムの動作を説明するためのシーケンス図である。
【図１２】端末支援システムの動作を説明するためのシーケンス図である。
【図１３】TLS/DTLSのメッセージフロー（完全なHandshake）の例を示す図である。
【図１４】TLS/DTLSのメッセージフロー（省略されたHandshake）の例を示す図である。
【図１５】TLS/DTLSのメッセージフロー（完全なHandshake）の他の例を示す図である。
【図１６】TLS/DTLSのメッセージフロー（省略されたHandshake）の他の例を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、以下の実施の形態では、M2M/IoTを対象としているが、本発明はM2M/IoTに限らず、端末がサーバとの間でセキュア通信を行う通信システム全般に適用可能である。
【００２０】
（システム構成）
図２に、本実施の形態において前提としている通信システムの全体構成図を示す。M2M/IoTサービスを提供する通信システムは種々の形態があるが、本実施の形態では、図２に示すように、M2M/IoT-GW（ゲートウェイ）を介してM2M/IoT端末をネットワークに収容するGW収容型の通信システムを対象としている。
【００２１】
図２におけるM2M/IoT端末には、一般のPCのような高機能の端末や、センサのような低機能の端末等、種々の端末がある。例えば、M2M/IoT端末は、端末のメモリ容量やCPU、ディスプレイの有無、もしくは消費電力等で高機能、低機能、超低機能に分類できる。一例として、低機能の端末とは、例えば、メモリ（RAM、ROM）の性能が非常に限られた端末である。もちろん、他の方法で分類しても良い。また、分類数には特に限定はなく、２つに分類しても良いし、４つ以上に分類しても良い。以下、例として、高機能と低機能の２つに分類した場合について説明する。
【００２２】
図２に示すように、各M2M/IoT端末はエリアNW（ネットワーク）を介してM2M/IoT-GW（ゲートウェイ）に接続される。また、各M2M/IoT-GWは広域NWを介してM2M/IoT-PF（プラットフォーム）に接続される。M2M/IoT-PF（プラットフォーム）には各種のM2M/IoT-アプリ（アプリケーション）が接続される。
【００２３】
エリアNWは、例えば、WiFi（登録商標）、Bluetooth（登録商標）、ZigBee（登録商標）WiSUN（登録商標）等であるが、これらに限られない。M2M/IoT-GWは、エリアNWで通信できる範囲のM2M/IoT端末を収容し、収容する各M2M/IoT端末の通信をエリアNWと広域NWとの間で中継するシステム（１つの装置でもよいし、複数の装置でもよい）である。
【００２４】
広域NWは、例えば通信事業者（キャリア）のネットワークである。広域NW はインターネットであってもよい。M2M/IoT-PFは、複数M2M/IoTサービス（アプリ）における共通的な制御機能を提供するシステム（１つの装置でもよいし、複数装置でもよい）である。
【００２５】
M2M/IoT端末は、エリアNW、M2M/IoT-GW、広域NW、及びM2M/IoT-PFを介して、所望のM2M/IoTアプリと通信を行い、例えば、M2M/IoTアプリからセンサ制御命令を受信し、M2M/IoTアプリへセンサ値を送信する等の処理を行う。
【００２６】
なお、M2M/IoTサービスとしては様々なビジネスモデルが考えられるが、本実施の形態では、通信事業者（キャリア）が、ネットワーク、M2M/IoT-PF、及びM2M/IoT-GWをサービス事業者に提供し、サービス事業者がM2M/IoTアプリとM2M/IoT端末をエンドユーザに提供することを想定する。ただし、これに限られるわけではない。ここで、M2M/IoT-PFとM2M/IoT-GWとを含み、これらが広域NWで接続されて構成される通信システムをM2M/IoT統合管理基盤と呼ぶ。
【００２７】
以下では、本実施の形態におけるM2M/IoT統合管理基盤の構成をより具体的に説明する。なお、M2M/IoT統合管理基盤は、端末のセキュリティ支援に関わる機能以外の種々の既存機能を含む。そこで、M2M/IoT統合管理基盤において、端末のセキュリティ支援に関わる構成を「端末支援システム」と呼ぶことにする。また、以下では、M2M/IoT-GWをGWと呼び、M2M/IoT-PFをPFと呼び、M2M/IoT端末を端末と呼び、M2M/IoTアプリをアプリと呼ぶ場合がある。
【００２８】
（端末支援システムの機能構成について）
図３に、本実施の形態における端末支援システムの機能構成例を示す。なお、図２には、端末支援システムにおける各機能部が、M2M/IoT-PF内か、M2M/IoT-GW内かのいずれの側に備えられているかを示すために、M2M/IoT-PFとM2M/IoT-GWを点線枠で示している。
【００２９】
図３に示すように、端末支援システムは、端末情報管理機能１０、PF側のパケット中継機能２０、GW側のパケット中継機能３０、GW負荷監視・切替機能４０、セキュリティ支援機能５０、端末情報推定・管理機能６０を含む。
【００３０】
端末情報管理機能１０は、端末の識別子、紐づいているアプリ（サービス事業者）の識別子、端末の性能情報等の端末情報を管理（格納）するデータベースを有する。また、後述するように、当該データベースは、方式Ｃにおいて、端末の優先度を判定するために用いる情報を格納する。
【００３１】
本実施の形態では、端末情報推定・管理機能６０として、GW側にも端末情報を管理する機能が備えられている。例えば、端末情報管理機能１０はPFに接続する全端末の情報を保有し、端末情報推定・管理機能６０は自GW配下の端末に関する一部の情報を保有する。これにより、端末の接続の都度、GW側からPF側への問い合わせを行うといった処理を行う必要がなくなり、トラヒックやシステムの応答速度等の観点から効率的な処理を実現できる。
【００３２】
PF側のパケット中継機能２０は、GWとアプリとの間でパケットの中継を行う機能を有する。GW側のパケット中継機能３０は、端末とPFとの間でパケットの中継を行う機能を有する。また、GW側のパケット中継機能３０は、端末の端末情報（性能情報）を基に、端末を支援するかどうかを決定する機能を有する。例えば、方式Ｂにおいて、端末が、低機能であれば、支援を行うと判定し、そうでなければ、支援を行わないと判定する。ここで、端末情報がない場合には、端末情報推定・管理機能６０が端末の性能を推定する。更に、GW側のパケット中継機能３０は、後述する方式Ｃにおいて、低機能端末の優先度に応じて、支援を行うかどうかを判定する機能も有する。
【００３３】
GW負荷監視・切替機能４０は、GWの負荷を監視し、セキュリティ支援方式の切り替えを行う機能を有する。詳細は後述する。
【００３４】
セキュリティ支援機能５０は、端末支援要否判定結果に基づいて、端末のセキュリティ処理の支援を実施する。セキュリティ支援機能５０は、例えば、端末の代わりに処理負荷が高いTLS/DTLSのHandshakeをM2M/IoTアプリとの間で実施し、合意したセキュリティ情報を端末に送信し、その後、端末は当該セキュリティ情報を利用し、省略されたTLS/DTLSのHandshakeをM2M/IoTアプリとの間で実施する。
【００３５】
端末情報推定・管理機能６０は、端末情報（性能情報等）を保持するデータベースを有するとともに、端末情報の推定を行う機能を有する。端末情報推定・管理機能６０は、例えば、端末との間でTLS/DTLSを確立するためのHandshakeを試み、Handshakeを完遂できる端末は高機能、完遂できない端末は低機能とする等の方法により、端末性能を推定する。なお、この推定方法は一例であり、他の方法で推定してもよい。
【００３６】
本実施の形態に係るM2M/IoT-GWは、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現することが可能である。すなわち、当該M2M/IoT-GWの機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、当該機能部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００３７】
（GW負荷監視・切替機能４０の処理について）
本実施の形態では、GW負荷監視・切替機能４０により、端末の利便性（応答時間等）とGWの負荷のトレードオフをバランスよく制御することとしている。つまり、GW負荷監視・切替機能４０は、GWの負荷に応じて、全ての端末に対して支援を行う方式Ａ、支援を行うかどうかを判定し、支援を行うと判定した端末に対してのみ支援を行う方式Ｂ、及び、方式Ｃのいずれかを使用するよう、切り替えを行う。
【００３８】
ここで、方式Ｃは、処理しきれない数のアクセスが来たとき（GWの負荷が限界（所定の閾値）に達したとき）に、端末の優先度に応じて、支援するか否かを決定する方式である。例えば、支援が必要な端末１０個が同時にM2M/IoT-GWにアクセスしたとき、そのうちの７個までしかM2M/IoT-GWが処理できない場合、端末の位置情報や、端末の移動履歴から定まる優先度に基づいて、優先度の高い端末を優先的に支援する。なお、端末数が少なく、M2M/IoT-GWの負荷が限界に達し得ないことがわかっている場合等においては、方式Ｃを設けないこととしてもよい。
【００３９】
図４は、M2M/IoT-GWの動作の概要を説明するための図である。まず、端末からのアクセス数が少なく、M2M/IoT-GWの負荷が小さいときには、（ａ）に示すように方式Ａが用いられ、全端末のアクセスに対して支援が行われる。なお、M2M/IoT-GWから延びる太い矢線は、M2M/IoT-GWによる支援が行われることを示し、当該太矢線がない場合は、M2M/IoT-GWによる支援が行われないことを示す。
【００４０】
端末からのアクセスが増え、負荷が所定の条件を満たすと、（ｂ）の方式Ｂに切り替えられる。方式Ｂでは、端末からのアクセスがある度に、支援要否判定が行われ、支援要の端末（低機能端末）に対してのみ支援が行われる。
【００４１】
その後、更に負荷が増え、負荷が所定の閾値（これをξとする）に達した場合、（ｃ）の方式Ｃに切り替えられる。方式Ｃでは、低機能端末であっても、優先度が低いものは支援がなされない。
【００４２】
ここで、端末からM2M/IoT-GWに到着するリクエストに対するM2M/IoT-GWの処理負荷と支援処理時間は、方式Ａと方式Ｂについては図１を参照して説明したとおりである。
【００４３】
方式Ｃに関するM2M/IoT-GWの処理負荷と支援処理時間を図５に示す。前述したとおり、図中のtaは、支援に用いる処理時間であり、laは支援に用いる処理負荷であり、tdは、支援要否判定（性能推定等）に用いる時間であり、ldは支援要否判定に用いる処理負荷である。更に、tsは、優先度判定にかかる支援処理時間であり、lsは、優先度判定にかかる処理負荷である。図５に示すとおり、低機能端末であっても支援を行わない場合には、処理負荷が最大でls（＜la）に抑えられ、方式Ｂに比べて負荷を抑制できる。
【００４４】
ここで、方式Ａから方式Ｂに切り替える際の所定の条件の例を説明する。
【００４５】
方式Ａでは、端末の性能に関わらず、M2M/IoT-GWに接続した全ての端末のセキュリティ支援を行う。つまり、GWにかかる１リクエストあたりの負荷Lcは下記の式（１）のようになる。
【００４６】
Lc= lata                 （１）
一方、方式Ｂでは、端末の支援を行う前に、繋がってきた端末が高機能なのか低機能なのかを判定してから、低機能な端末に対してのみセキュリティ処理の支援を行う。つまり、高機能な端末の１リクエストあたりGWにかかる負荷はldtdとなる。低機能な端末の１リクエストあたりGWにかかる負荷は(ldtd + lata)となる。ここで、GWに繋がる端末の総数をNとし、高機能な端末の数をn(0≦n≦N)とすると、低機能な端末の数はN-nとなる。そのため、１リクエストあたりGWにかかる負荷の期待値は式（２）のようにLpとして定式化できる。
【００４７】
【数１】
0006514130.tif 000002
本実施の形態では、GW負荷監視・切替機能４０が、LcとLpを計算し、Lc＞Lpを満たす場合に、方式Ａから方式Ｂに切り替える。この条件「Lc＞Lpを満たすこと」をＡ−Ｂ切替条件と呼ぶことにする。
【００４８】
定性的なイメージとして、例えば、低機能端末が高機能端末よりもかなり多い場合には、支援要否判定を行わない分、方式Ａのほうが方式Ｂよりも負荷が低くなると想定される（つまり、Lc＜Lp）。一方、高機能端末が多い場合、方式Ａを続けていると、支援を行わなくてよいのにも関わらず、支援を行う場合が多くなる。つまり、Lc＞Lpを満たし、方式Ａから方式Ｂへの切り替えが行われる。なお、低機能端末のアクセスが多く、Lc＞Lpを満たさずに、負荷がξ以上になる場合には、方式Ａから方式Ｃへの切り替えが行われる場合もある。
【００４９】
図６（ａ）は、アクセス数に応じた方式と負荷の遷移のイメージを表す。また、図６（ｂ）は、図６（ａ）における各方式での、端末あたりの支援処理時間を示す。
【００５０】
図６（ａ）に示すように、この例では、アクセス数がn1になったときに、方式Ａから方式Ｂへの切り替えが行われる。そして、n1からn2の間は方式Ｂが継続され、n2の時点で負荷が閾値ξに達し、方式Ｃへ切り替えられる。
【００５１】
（方式Ｃの詳細）
次に、方式Ｃについてより詳細に説明する。前述したように、方式Ｃでは、パケット中継機能３０が、低機能端末の優先度（優先順位）に応じて、セキュリティ処理の支援を行うか否かを決定する。優先度の判定方法は特定の方法に限られないが、例えば、以下の方法がある。
【００５２】
＜優先度の判定方法の例１＞
図７は、優先度の判定方法の例１を説明するための図である。図７の例では、M2M/IoT-PF-Mに、M2M/IoT-GW-M、H、Yが接続されている。また、M2M/IoT-GW-Mに、移動しない低機能端末Aが接続され、M2M/IoT-GW-Hに、移動しない低機能端末Cが接続されている。また、頻繁に移動する低機能端末Bが、移動しながら各M2M/IoT-GWに接続される状況が示されている。
【００５３】
例１では、上記の頻繁に移動する低機能端末Bは、人に紐付いている端末である可能性が高いと推定できる。この場合、プライバシを保護する必要があるため、優先的にセキュリティ処理の支援を行うと判定する。より具体的な処理例を以下で説明する。
【００５４】
例えば、PFの端末情報管理機能１０は、図８に示す情報を含むデータベースを保持している。図８に示すとおり、当該データベースは、端末毎に、前アクセスGW（現アクセスGWの直前にアクセスしていたGW）の（GW-ID、アクセス開始時間、アクセス終了時間）と、現アクセスGWの（GW-ID、アクセス開始時間、アクセス終了時間）と、移動度指標を保持する。
【００５５】
移動度指標は、例えば所定時間内（現時点から過去に向けての所定時間内）に、あるGWから別のGWに移動した回数を用いる場合もあるが、この限りではない。所定時間内にあるGWから移動しなかった場合は１とする（当該GWへの移動が１回あったとみなす）。この回数のカウントは、例えば、パケット中継機能３０が、端末からの接続を受けた場合に、それを端末情報管理機能１０に通知することで、端末情報管理機能１０により行われる。また、回数は、端末毎に所定時間毎にリセットされる。なお、当該データベースをGWの端末情報推定・管理機能６０が保持してもよい。
【００５６】
例えば、GWのパケット中継機能３０は、端末情報管理機能１０のデータベースから、判定対象の端末の性能情報（低機能端末を示す）と移動指標を取得し、当該移動指標の値が大きい低機能端末を支援対象の端末とする。移動指標の値が大きいとは、例えば、所定の閾値よりも大きいことである。
【００５７】
＜優先順位の判定方法の例２＞
図９は、優先度の判定方法の例２を説明するための図である。図９の例では、低機能端末Aが公園に位置し、低機能端末Bが個人の家に位置し、低機能端末Cが個人所有の畑に位置することが示されている。
【００５８】
例２では、プライベートな空間（個人の家、個人の私有地等）に位置している端末は、プライバシを保護する必要があると考え、優先的にセキュリティ処理の支援を行うこととしている。より具体的な処理例を以下で説明する。
【００５９】
例えば、PFの端末情報管理機能１０は、図１０に示す情報を含むデータベースを保持している。図１０に示すとおり、当該データベースは、端末毎に、現アクセスGWの（GW-ID、アクセス開始時間、アクセス終了時間）と、位置情報を保持する。なお、当該データベースをGWの端末情報推定・管理機能６０が保持してもよい。
【００６０】
位置情報はどのような方法で取得してもよい。例えば、端末がGPS機能を有する場合は、パケット中継機能３０が、端末からの接続時にGPSによる位置情報を取得し、PFに通知する。また、端末が接続するエリアNWの情報（無線AP-ID、基地局ID等）を、エリアNWから取得して、それを位置情報としてもよい。取得した位置情報は端末情報管理機能１０のデータベースに格納される。
【００６１】
また、例えば、端末情報管理機能１０（あるいは端末情報推定・管理機能６０）は、位置（エリア）毎に、当該位置がプライベート空間に属するか、パブリック空間に属するかのマップ情報を有しており、パケット中継機能３０は、端末（低機能端末）の位置と、当該マップ情報に基づき、端末がプライベート空間に属するか、パブリック空間に属するかを判定し、プライベート空間に属する場合に、優先的にセキュリティ処理の支援を行うと判定する。
【００６２】
（処理シーケンス）
次に、本実施の形態における端末支援システムの動作例を図１１、１２の処理シーケンスを参照して説明する。図中、実線は、低機能端末の処理の流れを示し、点線は高機能端末の処理の流れを示す。以下、高機能端末と低機能端末とで同様の処理が行われる場合、高機能端末と低機能端末とを区別せずに、「端末」と記述する。また、以下の例では、方式の切り替えについて、方式Ａから方式Ｂへの切り替え、方式Ｂから方式Ａへの切り替え、もしくは、方式Ｂから方式Ｃへの切り替えが生じる例を示している。
【００６３】
図１１の例では、まず、方式Ａから開始する。すなわち、ステップＳ１０１において、GW負荷監視・切替機能４０が、方式Ａでの監視を開始する。具体的には、M2M/IoT-GWの負荷の監視を開始する。また、GW負荷監視・切替機能４０は、パケット中継機能３０に対して方式Ａの処理を依頼する（ステップＳ１０２）。
【００６４】
端末からの通信が発生すると、端末はまずM2M/IoT-GW（パケット中継機能３０）との間に接続を確立する（ステップＳ１０３）。方式Ａでは、全ての端末に対してセキュリティ支援を行うので、パケット中継機能３０は、セキュリティ支援機能５０にセキュリティ支援を依頼する（ステップＳ１０４）。
【００６５】
セキュリティ支援機能５０は、端末の代わりにセキュリティプロトコルの処理負荷がかかる処理を代行する（ステップＳ１０５）。ここでは、端末に代わってDTLSのHandshakeを実行する。ステップＳ１０６では、アプリと合意したセキュリティ情報を端末に渡す。
端末は残りの処理負荷が軽い処理を実施し、アプリとエンドツーエンドのセキュア通信を実現する（ステップＳ１０７）。具体的には、DTLSの省略されたHandshakeを実施し、セキュア通信を確立する。なお、ステップＳ１０５、Ｓ１０６は、セキュア通信に関する処理の支援の例である。
【００６６】
ステップＳ１０８において、GW負荷監視・切替機能４０は、Ａ−Ｂ切替条件を満たすかどうかを判定し、Ｎｏの場合はステップＳ１０１に戻る。Ｙｅｓの場合、ステップＳ１０９に進み、GW負荷監視・切替機能４０は、方式Ｂでの監視を開始する。ステップＳ１１０では、GW負荷監視・切替機能４０は、パケット中継機能３０に、方式Ｂでの処理を依頼する。
【００６７】
その後、端末とパケット中継機能３０との間に接続が確立される（ステップＳ１１１）と、パケット中継機能３０は、端末情報推定・管理機能６０に対して当該端末の端末情報を問い合わせ、端末情報があればそれを取得する（ステップＳ１１２）。端末情報は、当該端末が低機能端末か高機能端末かを判断するための情報であり、性能情報であってもよいし、明示的に低機能端末／高機能端末を示す情報であってもよい。
【００６８】
ステップＳ１１３は、当該端末の端末情報を得られなかった場合に行われる推定処理を示す。この場合、当該推定処理を経て、パケット中継機能３０は、端末情報推定・管理機能６０から端末情報を取得する。推定処理は、前述したように、例えば、端末との間でTLS/DTLSを確立するためのHandshakeを試み、Handshakeを完遂できる端末は高機能、完遂できない端末は低機能とする等の方法で行われる。
【００６９】
ステップＳ１１４において、パケット中継機能３０は、接続してきた端末の端末情報に基づいて、セキュリティ支援を行うかどうかを判断する。端末情報に基づき、接続してきた端末が低機能端末であると判断される場合は、セキュリティ支援を行う。つまり、ステップＳ１０４〜Ｓ１０７と同様に、ステップＳ１１５〜Ｓ１１７が実行される。端末情報に基づき、接続してきた端末が高機能端末であると判断される場合は、セキュリティ支援を行わない。
【００７０】
図１２のステップＳ１１９において、GW負荷監視・切替機能４０は、Ａ−Ｂ切替条件を満たすかどうかを判定し、Ｎｏの場合はステップＳ１０１に戻り、方式Ａに切り替えられる。Ｙｅｓの場合、ステップＳ１２０に進み、GW負荷監視・切替機能４０は、GWの負荷が閾値ξ以上かどうかを判定し、負荷が閾値ξ以上でなければステップＳ１０９に戻り、方式Ｂでの処理を継続する。
【００７１】
負荷が閾値ξ以上の場合は、ステップＳ１２１に進み、方式Ｃの監視が開始される。ステップＳ１２２において、GW負荷監視・切替機能４０は、パケット中継機能３０に対して方式Ｃでの処理を行うように依頼する。
【００７２】
その後、端末とパケット中継機能３０との間に接続が確立される（ステップＳ１２３）と、パケット中継機能３０は、端末情報機能１０に対して当該端末の端末情報を問い合わせ、端末情報を取得する（ステップＳ１２４）。端末情報は、当該端末が低機能端末か高機能端末かを判断するための情報と、低機能端末については、前述したように優先度を判定するための情報（例：移動度指標、位置情報）が含まれる。
【００７３】
ステップＳ１２５において、パケット中継機能３０は、接続してきた端末の端末情報に基づいて、セキュリティ支援を行うかどうかを判断する。端末情報に基づき、接続してきた端末が優先度の高い低機能端末であると判断される場合は、セキュリティ支援を行う。つまり、ステップＳ１０４〜Ｓ１０７と同様に、ステップＳ１２６〜Ｓ１２８が実行される。端末情報に基づき、接続してきた端末が高機能端末もしくは優先度の低い低機能端末であると判断される場合は、セキュリティ支援を行わない。
【００７４】
（セキュリティ支援処理の具体例）
図１１のシーケンスにおけるステップＳ１０５〜Ｓ１０７等で示したセキュリティ処理の支援には、非特許文献１に記載された方法を利用している。
【００７５】
非特許文献１に記載された方法では、性能に制約がある低機能な端末（以下、端末D）の代わりに、高機能な端末（以下、端末DS）にセキュリティを確保するための処理の一機能を代行してもらうことで、低機能な端末でもセキュリティを実現する。
【００７６】
具体的には、低機能な端末Dとインターネット上にある端末RがDTLSを用いて通信したいユースケースにおいて、端末Dはメモリが十分にないことから、DTLSを実現するためのHandshakeをD自身が完遂できない。そのため、ここでは高機能な端末DSを導入し、端末Dの代わりに、まず端末DSが端末Rと完全なHandshakeを実施する。その後、端末DSは端末RとのHandshakeで合意した情報を端末Dに渡し、端末Dは、端末DSからもらった情報を基に、DTLSのセッション再開メカニズムを利用して、端末Rと省略されたHandshakeを実施することができる。
【００７７】
本実施の形態の端末支援システムにおいて、上記の端末DSはセキュリティ支援機能５０に相当し、端末Rはアプリに相当する。
【００７８】
上記の完全なHandshakeの詳細なシーケンス例を図１３に示す。通信の安全性の確保を目指して設計された技術として、例えば、非特許文献３に記載されたTLS、及び非特許文献４に記載されたDTLSという技術があり、図１３は、DTLSのシーケンスを示す。なお、DTLSはTLSと比べて、HelloVerifyRequestというメッセージ（図１３中Flight2）が多い点が異なる。
【００７９】
TLS/DTLSを利用する際には、まずHandshakeプロトコルで通信相手とのセッションを確立する。図１３はDTLS のHandshakeを示し、図１１のシーケンスにおけるステップＳ１０５での処理に相当する。ここでのセッションとは、クライアントとサーバ間で認証を行って相手を特定し、利用する暗号化アルゴリズムの情報や、通信データの圧縮方式の情報、暗号鍵の情報などを交換し、合意した状態を持つことを指す。なお、図１３のシーケンス自体は従来技術であることから、詳細な説明は省略する。
【００８０】
セッションを確立した後、ChangeCipherSpecプロトコルにより、平文の通信からHandshakeプロトコルで合意した暗号アルゴリズムを用いる暗号通信に切り替えることを通知する。その後、Recordプロトコルを通して、データの分割、圧縮、暗号化を行い、その間何らかの異常が発生した場合は、Alartプロトコルによりその異常を通信相手に通知するといった処理がなされる。
【００８１】
図１３に示したようなDTLSやTLSの完全なHandshakeは、CPU処理時間と情報をやりとりするのに必要な回数といった面で非常にコストがかかるので、実行時のコストを減らすために、TLS/DTLSはセッション再開のメカニズムを備えている。本メカニズムにより、クライアントとサーバが以前に通信していれば、Handshakeを完遂せずに、一気にデータ転送へと処理を進めることができる。
【００８２】
具体的には、セッションを再開できるように設定されたサーバはServerHelloメッセージでsession_idをクライアントに渡し、後で参照するためにmaster_secret（これはHandshakeプロトコルで共有した乱数及びpre_master_secretから生成される）をキャッシュする。クライアントは後でこのサーバと新規コネクションを開始するときに、このsession_idをClientHelloメッセージに含めて送信する。サーバはセッション再開に合意することを通知するために、同じsession_idをServerHelloに含めて送信する。この時点でHandshakeはスキップされ、保存されていたmaster_secretを使って暗号技術に関する鍵がすべて生成される。
【００８３】
この処理のDTLSでのシーケンス例を図１４に示す。図１４に示すClientHelloにてsession_idがサーバに送信され、ServerHelloにて同じsession_idがクライアントに通知されることで省略されたHandshakeが実行される。
【００８４】
図１０に示す例では、ステップＳ１０６にて、セキュリティ支援機能５０からsession_id等が端末に渡され、ステップＳ１０７で省略されたHandshakeが実行される。
【００８５】
上述した技術（図１３、図１４）では、セッション再開の仕組みとして、セッションを再開できるように設定されたサーバは、ServerHelloメッセージでsession_idをクライアントに渡し、後で参照できるようにmaster_secretをキャッシュしていたが、サーバが保持すべきセッション情報を暗号化してクライアントに送り、 セッションを再開する方法もある。この場合、クライアントから、セッション情報を送り返してもらい、サーバがその情報を復号し検証して問題がなければ、セッションを再開する。この仕組みは、非特許文献５に記載されている。この場合の完全なHandshakeシーケンス例を図１５に示す。図１５における図１３との差分は図１５の太字の部分である。
【００８６】
上記非特許文献５に基づく技術において、"暗号化されたセッション情報"は Session Ticketと呼ばれており、 Session Ticketを用いた接続の再開では、クライアントがSession TicketをClientHelloメッセージに含めて、サーバに送る。Session Ticketを受け取ったサーバは、受け取ったSession Ticketを復号して検証し、検証に成功した場合に接続の再開を行う。この時、Session Ticketを更新するのであればサーバは空のSessionTicket TLS Extensionを含むServerHelloをクライアントに返した後、新たな Session TicketであるNewSessionTicketをクライアントに返す。以降、サーバとクライアントはChange Cipher Spec、Finished を交換し、サーバは復号したSession Ticketから得たSessionの情報を用いてSessionを再開する。Session Ticketを更新しないのであればサーバはSession TLS Extensionを含まないServerHelloをクライアントに返し、Change Cipher SuiteとFinishedを交換してセッションを再開する。
【００８７】
この処理のシーケンス例を図１６に示す。図１６は、Session Ticketを更新する場合の例を示しており、空のSessionTicket TLS Extensionを含むServerHelloがクライアントに通知されている。
【００８８】
この技術を用いる場合、図１０に示す例では、ステップＳ１０６にて、セキュリティ支援機能５０からSession Ticket等が端末に渡され、ステップＳ１０７で省略されたHandshakeが実行される。
【００８９】
（実施の形態のまとめ）
以上、説明したように、本実施の形態により、端末に対してセキュア通信に関する処理の支援を行う端末支援装置であって、前記端末支援装置の負荷を監視する負荷監視手段と、セキュア通信に関する処理の支援を実行する支援手段と、前記端末支援装置に接続される全ての端末に対して前記支援を実行する方式である第１の方式と、前記端末支援装置に接続される端末に対して前記支援を実行するか否かを当該端末の性能に基づき判定し、実行すると判定される場合に当該支援を実行する方式である第２の方式とを、前記負荷に基づき切り替える切替手段とを備える端末支援装置が提供される。
【００９０】
実施の形態で説明したM2M/IoT-GWは、端末支援装置の例である。また、GW負荷監視・切替機能４０は、負荷監視手段と切替手段の例であり、セキュリティ支援機能５０は、支援手段の例である。方式Ａ、方式Ｂ、方式Ｃは、それぞれ第１の方式、第２の方式、第３の方式の例である。
【００９１】
前記切替手段は、前記負荷が所定の閾値以上である場合に、前記端末支援装置に接続される端末の優先度に基づき前記支援を行うか否かを判定する第３の方式への切り替えを行うこととしてもよい。
【００９２】
また、前記端末支援装置が、前記第１の方式を用いている場合において、前記切替手段は、前記第１の方式における１端末当たりの負荷が、前記第２の方式における１端末当たりの負荷の期待値よりも大きくなった場合に、前記第１の方式から前記第２の方式への切り替えを行うこととしてもよい。
【００９３】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００９４】
１０  端末情報管理機能
２０  パケット中継機能
３０  パケット中継機能
４０  GW負荷監視・切替機能
５０  セキュリティ支援機能
６０  端末情報推定・管理機能
【図１】
0006514130.tif 000003
【図２】
0006514130.tif 000004
【図３】
0006514130.tif 000005
【図４】
0006514130.tif 000006
【図５】
0006514130.tif 000007
【図６】
0006514130.tif 000008
【図７】
0006514130.tif 000009
【図８】
0006514130.tif 000010
【図９】
0006514130.tif 000011
【図１０】
0006514130.tif 000012
【図１１】
0006514130.tif 000013
【図１２】
0006514130.tif 000014
【図１３】
0006514130.tif 000015
【図１４】
0006514130.tif 000016
【図１５】
0006514130.tif 000017
【図１６】
0006514130.tif 000018