JP2017046179A - 端末支援システム、及び端末支援方法 - Google Patents

Abstract

【課題】通信ネットワークに接続される端末に応じて、適切にセキュリティに関する処理の支援を行う。【解決手段】端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムにおいて、端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、セキュア通信に関する処理の支援を実施する支援手段と、前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御手段とを備える。【選択図】図２

Description

本発明は、M2M（Machine-to-Machine）/IoT（Internet of Things)通信システムに関連するものであり、特に、M2M/IoT通信システムにおいて使用されるM2M/IoT端末の処理を支援するための技術に関連するものである。

有線・無線のネットワーク技術、及び、端末技術の発展により、これまでネットワークに繋がっていなかった家電やセンサ等のあらゆるモノがネットワークに繋がるInternet of things (IoT)や、人の手を介することなく動作するMachine-to-Machine（M2M）の普及が予想されている。

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エリアネットワークのフレームワーク," 電子情報通信学会信学技報, pp.165-170, Mar. 2015. "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端末は、従来からネットワークに繋がっているパソコンやスマートフォンよりもコスト要件が厳しく、処理性能やメモリ、そして、電力等において、様々な制約があることが予想される。このため、既存のセキュリティ技術を適用できない、若しくは、適用することが非効率な場合がある。

上記の問題に対して、様々な検討が行われているが、例えば非特許文献１では、ある程度性能があるエンティティを導入し、低機能なM2M/IoT端末が本来行うべき処理の一部をある程度性能があるエンティティに肩代わりしてもらうことでセキュリティを実現する技術が開示されている。この技術は、既存端末に修正を加える必要が無いため、導入が容易だと考えられる。

しかし、上記の技術を、性能が異なる様々な端末が繋がるM2M/IoT通信システムに導入するケースでは、当該技術の有効性を十分に発揮することができない可能性がある。なぜならば、低機能なM2M/IoT端末にとって役に立つ処理が、高機能なM2M/IoT端末にとっても役に立つとは限らず、場合によっては高機能なM2M/IoT端末に不必要な制約条件を増やすだけになりかねないからである。

例えば、高機能な端末が利用できる暗号化アルゴリズムよりも、M2M/IoT通信システム側で端末をサポートする際に用いる暗号化アルゴリズムの方が弱かった場合、上記技術を適用すると、高機能な端末が本来達成できるセキュリティレベルよりも低くなってしまう可能性がある。また、支援する必要がない端末を支援することで、本来不必要な負荷がM2M/IoT通信システムにかかる可能性がある。

本発明は上記の点に鑑みてなされたものであり、通信ネットワークに接続される端末に応じて、適切にセキュリティに関する処理の支援を行うことを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムであって、
端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、
セキュア通信に関する処理の支援を実施する支援手段と、
前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御手段と
を備えることを特徴とする端末支援システムが提供される。

また、本発明の実施の形態によれば、端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムが実行する端末支援方法であって、
前記端末支援システムは、端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、セキュア通信に関する処理の支援を実施する支援手段とを備え、
前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御ステップ
を備えることを特徴とする端末支援方法が提供される。

本発明の実施の形態によれば、通信ネットワークに接続される端末に応じて、適切にセキュリティに関する処理の支援を行うことを可能とする技術が提供される。

本発明の実施の形態における通信システムの全体構成図である。 本発明の実施の形態における端末支援システムの機能構成図である。 端末支援システムの動作を説明するためのシーケンス図である。 データベースの構成例を示す図である。 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統合管理基盤は、M2M/IoT端末の性能、若しくはサービス事業者の要望に応じて、M2M/IoT端末の支援をすることが可能である。これを可能ならしめるための要件は以下のとおりである。

要件1：サービス事業者は、M2M/IoT統合管理基盤に接続するM2M/IoT端末のセキュリティ支援要否に関する情報を予めM2M/IoT統合通信システムに設定できること。

要件2：サービス事業者がM2M/IoT統合管理基盤に対してM2M/IoT端末のセキュリティ支援要否に関する情報を設定しない場合、M2M/IoT統合管理基盤はM2M/IoT端末の性能を推定し、推定した端末性能を基に、M2M/IoT統合管理基盤で端末のセキュリティ支援要否を判定できること。

要件3：M2M/IoT統合管理基盤は、必要に応じて支援要否情報に基づいたセキュリティ支援を実施できること。

これらの要件を考慮し、本実施の形態では、M2M/IoT統合管理基盤において、M2M/IoT端末の情報を管理する端末情報管理機能、接続M2M/IoT端末の性能を推定できる端末性能推定機能、接続M2M/IoT端末のセキュリティ支援要否を判定する端末支援要否判定機能、及び、実際に端末のセキュリティ支援を実施する端末セキュリティ支援機能を備えている。

以下では、本実施の形態におけるM2M/IoT統合管理基盤の構成をより具体的に説明する。なお、M2M/IoT統合管理基盤は、端末のセキュリティ支援に関わる機能以外の種々の既存機能を含む。そこで、M2M/IoT統合管理基盤において、端末のセキュリティ支援に関わる構成を「端末支援システム」と呼ぶことにする。また、以下では、M2M/IoT-GWをGWと呼び、M2M/IoT-PFをPFと呼ぶ場合がある。

（端末支援システムの機能構成について）
図２に、本実施の形態における端末支援システムの機能構成例を示す。なお、図２には、端末支援システムにおける各機能部が、M2M/IoT-PF内か、M2M/IoT-GW内かのいずれの側に備えられているかを示すために、M2M/IoT-PFとM2M/IoT-GWを点線枠で示している。

図２に示すように、端末支援システムは、PF側端末情報管理機能１０、端末支援要否判定機能２０、端末セキュリティ支援機能３０、GW側端末情報管理機能４０、及び、端末性能推定機能５０を有する。

PF側端末情報管理機能１０は、端末情報入力受付部１１、PF側端末情報同期部１２、及び端末情報DB１３を備える。また、端末セキュリティ支援機能３０は、通信プロキシ部３２、及び、各支援技術部３３を備える。更に、GW側端末情報管理機能４０は、GW側端末情報同期部４１、端末情報取得部４２、及び接続端末情報DB４３を備える。

ここで、PF側のPF側端末情報管理機能１０と端末支援要否判定機能２０に関し、これらはそれぞれ１つの装置（コンピュータ）で構成してもよいし、それぞれ複数装置で構成してもよい。また、PF側端末情報管理機能１０と端末支援要否判定機能２０を１つの装置で構成してもよい。また、PF側端末情報管理機能１０と端末支援要否判定機能２０に関し、これら機能の中に、既存のPFの機能を含んでもよいし、既存のPFの機能を含まずに端末支援のための機能のみとしてもよい。

また、各GWの側に備えられる端末セキュリティ支援機能３０、GW側端末情報管理機能４０、そして端末性能推定機能５０に関し、これらはそれぞれ１つの装置（コンピュータ）で構成してもよいし、それぞれ複数装置で構成してもよい。また、端末セキュリティ支援機能３０、GW側端末情報管理機能４０、及び端末性能推定機能５０を１つの装置で構成してもよい。また、端末セキュリティ支援機能３０、GW側端末情報管理機能４０、及び端末性能推定機能５０に関し、これら機能の中に、既存のGWの機能を含んでもよいし、既存のGWの機能を含まずに端末支援のための機能のみとしてもよい。

また、図２に示す各機能の配置は一例に過ぎない。例えば、端末支援要否判定機能２０をGW側に備えてもよいし、各DBを分散配置してもよい。

更に、本実施の形態では、M2M/IoT-PFとM2M/IoT-GWからなる構成を前提としているために、M2M/IoT-PF側とM2M/IoT-GW側に端末支援システムの機能を分けて配置しているが、M2M/IoT-PFとM2M/IoT-GWからなる構成を前提としない通信システムに本発明を適用する場合には、例えば、端末情報管理機能、端末支援要否判定機能、端末セキュリティ支援機能等を一体として（例えば１つの装置に）備えることとしてもよい。

＜各機能部の概要＞
PF側端末情報管理機能１０、端末支援要否判定機能２０、端末セキュリティ支援機能３０、GW側端末情報管理機能４０、及び端末性能推定機能５０の概要は以下のとおりである。なお、各機能の詳細な処理内容（シーケンス）やDBの内容の例については後述する。

PF側端末情報管理機能１０は、M2M/IoT 端末の識別子、紐づいているM2M/IoTアプリ（サービス事業者）の識別子、M2M/IoT 端末の性能情報等の端末情報を管理する機能である。また、本実施の形態では、GW側端末情報管理機能４０として、GW側にも端末情報を管理する機能が備えられている。例えば、PF側端末情報管理機能１０はPFに接続する全端末の情報を保有し、GW側端末情報管理機能４０は自GW配下の端末に関する一部の情報を保有する。これにより、M2M/IoT端末の接続の都度、GW側からPF側への問い合わせを行うといった処理を行う必要がなくなり、トラヒックやシステムの応答速度等の観点から効率的な処理を実現できる。

端末支援要否判定機能２０は、M2M/IoT端末の性能情報を基に、 M2M/IoT端末を支援するかどうか、支援する場合にどの支援技術を適用するか等を決定する機能である。

端末セキュリティ支援機能３０は、端末支援要否判定結果、若しくは、サービス事業者の要望に基づいて、M2M/IoT端末の支援を実施する機能である。図２に示すとおり、端末セキュリティ支援機能３０は、通信プロキシ部３２と、種々の支援技術部３３（支援技術１〜ｎ）を有する。

支援技術部３３の例として、例えば、M2M/IoT端末の代わりに処理負荷が高いTLS/DTLSのHandshakeをM2M/IoTアプリとの間で実施し、合意したセキュリティ情報をM2M/IoT端末に送信し、その後、M2M/IoT端末は支援技術部３３から受け取ったセキュリティ情報を利用し、省略されたTLS/DTLSのHandshakeをM2M/IoTアプリとの間で実施する。このような支援技術を用いる際、M2M/IoT端末と支援技術部３３は同一エリアNW内にあることが前提であるため、端末セキュリティ支援機能３０はGW内に備えている。

また、端末性能推定機能５０は、例えば、M2M/IoT端末との間でTLS/DTLSを確立するためのHandshakeを試み、Handshakeを完遂できるM2M/IoT端末は高機能、完遂できないM2M/IoT端末は低機能とする等の方法により、端末性能を推定する。なお、この推定方法は一例であり、他の方法で推定してもよい。図２の端末性能推定機能５０において、複数の端末性能推定技術を使用可能であることが示されている。

本実施の形態に係るPF側端末情報管理機能１０、端末支援要否判定機能２０、端末セキュリティ支援機能３０、GW側端末情報管理機能４０、及び端末性能推定機能５０はそれぞれ、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現することが可能である。すなわち、当該機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、当該機能部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

（処理シーケンス）
次に、本実施の形態における端末支援システムの動作例を図３の処理シーケンスを参照して説明する。

M2M/IoT端末からの通信が発生すると、M2M/IoT端末はまずM2M/IoT-GW（GW側端末情報管理機能４０）との間に無線接続を確立する（ステップＳ１０１）。これにより、GW側端末情報管理機能４０における端末情報取得部４２はM2M/IoT端末のMACアドレス等の端末情報を取得する。当該端末情報はGW側端末情報同期部４１に渡される。

GW側端末情報同期部４１は、例えばMACアドレスをキーに該当する端末のセキュリティ支援要否情報の有無を接続端末情報DB４３に問い合わせる（ステップＳ１０２）。ここで、該当する端末のセキュリティ支援要否情報が無ければ（ステップＳ１０２の無）、 GW側端末情報同期部４１は、PF側端末情報管理機能１０に問い合わせを行い、セキュリティ支援要否情報の有無を確認する（ステップＳ１０３）。なお、ステップＳ１０３での問い合わせは、GW側が情報をPF側と同期させるための依頼でもある（端末セキュリティ支援情報同期依頼）。

ここで、サービス事業者が予めセキュリティ支援要否情報を、端末情報入力受付部１１から端末情報DB１３に設定している、若しくは、過去にM2M/IoT端末がM2M/IoT-PF管轄の別のM2M/IoT-GWに繋がったことがある場合、端末情報DB１３の中に該当するM2M/IoT端末の情報が保存されている。従って、この場合、PF側端末情報管理機能１０におけるPF側端末情報同期部１２は、GW側端末情報管理機能４０に対して該当するセキュリティ支援要否情報（例：支援技術ｘ適用）を通知する（ステップＳ１０４、Ｓ１０５）。通知された情報を含む端末情報は接続端末情報DB４３に格納される。

一方、端末情報DB１３の中に該当するM2M/IoT端末の情報が保存されていない場合、PF側端末情報同期部１２は情報を保有していないことをGW側端末情報管理機能４０に通知する（ステップＳ１０４、Ｓ１０５）。

GW側端末情報管理機能４０におけるGW側端末情報同期部４１は、ステップＳ１０５で受信した情報に基づいて、端末の情報がある場合は端末性能推定の必要無しと判定し（ステップＳ１０６における否）、情報なしの場合は端末性能推定要と判定する（ステップＳ１０６における要）。

端末性能推定要の場合、例えばGW側端末情報同期部４１は、端末性能推定機能５０に対して、該当端末についての端末性能の推定依頼を行う（ステップＳ１０７）。依頼を受けた端末性能推定機能５０は、例えば前述した手法を用いてM2M/IoT端末の性能を推定する（ステップＳ１０８）。

端末性能推定機能５０は、推定結果をGW側端末情報管理機能４０に返却する（ステップＳ１０９）。GW側端末情報管理機能４０において、例えばGW側端末情報同期部４１が推定結果を受け取るが、GW側端末情報同期部４１は、当該推定結果の性能情報を接続端末情報DB４３に保存せずに、端末支援要否判定機能２０に渡す（ステップＳ１１０）。

M2M/IoT端末の性能情報を受け取った端末支援要否判定機能２０は、端末の性能情報に基づいて、端末支援要否判定を実施する。例えば、端末支援要否判定機能２０は、性能推定の結果が「低機能」である場合に支援技術１を適用する、といった判定を行う。また、例えば、性能推定により、端末のRAMが3.5KiB（KiB＝1024bytes）という結果が得られた場合に、超低機能の端末にクラス分けして、支援技術２を適用する、という判定を行うこともできる。もちろん、この数値は一例である。また、RAMではなく、CPUや消費電力で高機能や低機能を判断することとしてもよい。

端末支援要否判定機能２０は、支援要否判定結果をGW側端末情報管理機能４０に通知する（ステップＳ１１１）。

GW側端末情報管理機能４０におけるGW側端末情報同期部４１は、ステップＳ１１１で受信したM2M/IoT端末の支援要否判定結果を含む端末情報を接続端末情報DB４３に保存する（ステップＳ１１２）。

また、GW側端末情報同期部４１は、支援要否判定結果を含むM2M/IoT端末の情報をPF側端末情報管理機能１０に送り、登録（同期）を依頼する（端末セキュリティ支援情報同期依頼）（ステップＳ１１３）。ステップＳ１１３で情報を受信したPF側端末情報管理機能１０におけるPF側端末情報同期部１１は、当該情報を端末情報DB１３に保存する（ステップＳ１１４）。

M2M/IoTアプリからM2M/IoT端末へのセキュア通信の要求が発生すると（ステップＳ１１５）、M2M/IoT-PFはM2M/IoT端末が接続しているM2M/IoT-GW（端末セキュリティ支援機能３０）を特定し、当該要求を端末セキュリティ支援機能３０に転送する（ステップＳ１１５）。

端末セキュリティ支援機能３０において、例えば通信プロキシ部３２が、当該セキュア通信の要求を一旦保持（プロキシ）する。その後、通信プロキシ部３２は、GW側端末情報管理機能４０における接続端末情報DB４３を参照し、当該セキュア通信の要求の宛先であるM2M/IoT端末のセキュリティ支援要否情報を取得する（ステップＳ１１６、Ｓ１１７）。

そして、通信プロキシ部３２は、接続端末情報DB４３から取得したセキュリティ支援要否情報に基づき端末セキュリティ支援の要否を判定する（ステップＳ１１８）。

端末セキュリティ支援が不要な場合（ステップＳ１１８における否）、通信プロキシ部３２は、保持していたセキュア通信の要求をそのままM2M/IoT端末に渡す（ステップＳ１１９）。これにより、M2M/IoT端末自身によるセキュリティプロトコルによるセキュア通信が実施される（ステップＳ１２０）。

一方、端末セキュリティ支援が要の場合（ステップＳ１１８における要）、例えば、通信プロキシ部３２は、セキュリティ支援要否情報に基づいて適用する支援技術（例：支援技術１）を決定し、当該支援技術に対応する支援技術部３３に当該M2M/IoT端末に対するセキュリティ支援の実施を指示する。

指示を受けた支援技術部３３は、支援技術を適用する。図３に示す例の場合、支援技術部３３は、M2M/IoT端末の代わりにセキュリティプロトコルの処理負荷がかかる処理を代行し（ステップＳ１２１）、その処理結果をM2M/IoT端末に渡す（ステップＳ１２２）。M2M/IoT端末は残りの処理負荷が軽い処理を実施し、M2M/IoTアプリ（サービス事業者アプリ）とエンドツーエンドのセキュア通信を実現する（ステップＳ１２３）。

（DBの構成例）
次に、本実施の形態におけるDBの構成例を説明する。PF側の端末情報DB１３とGW側の接続端末情報DB４３の構成例を図４に示す。なお、PF側の端末情報DB１３とGW側の接続端末情報DB４３をまとめて端末情報格納手段と称してもよい。

図４（ａ）は端末情報DB１３の構成例を示す。図４（ａ）に示すように、端末情報DB１３は、サービス事業者ID、端末MACアドレス、端末性能、接続GW、共有鍵、端末支援要否希望を格納している。図４（ａ）の例では、端末性能が高機能であることをAで示し、低機能であることをBで示し、超低機能であることをCで示している。また、端末支援要否希望については、不要を0で示し、支援技術１の適用を希望することを１で示し、支援技術2の適用を希望することを２で示している。

図４（ｂ）は接続端末情報DB４３の構成例を示す。図４（ｂ）は、例として、GW識別子がMusashino-01であるGWにおける接続端末情報DB４３の構成例を示している。図４（ｂ）に示すように、接続端末情報DB４３は、端末MACアドレス、共有鍵、端末支援要否判定結果を格納している。

図４（ｂ）に示す情報は、図４（ａ）において、（Ａ）、（Ｂ）、（Ｃ）に示されるレコードの情報に対応する。

ここで、例えば図４（ａ）における（ア）に示すように、端末支援要否希望の欄に値が設定されている場合、サービス事業者が端末支援システムに対して設定を行っていることを示す（ここでは「不要」を示す）。なお、端末支援要否希望の欄には、端末性能に基づく判定結果が設定される場合もある。

また、（イ）に示すように、値が設定されていない場合（Nullの場合）、サービス事業者が端末支援システムに対して設定を行っていないことを示す。また、（ウ）は、端末性能の推定結果が記録されていることを示す。更に、図４（ｂ）の（エ）に関し、当該端末に対してサービス事業者は端末支援要否希望を出していないが、端末性能が低いことから、端末支援要否判定の結果として、支援技術２を適用する旨の情報が記録されている。

（支援技術の具体例）
図３のシーケンスにおけるステップＳ１２１〜Ｓ１２３で示した支援技術は、非特許文献１に記載された方法を利用している。

非特許文献１に記載された方法では、性能に制約がある低機能な端末（以下、端末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が実行される。

また、支援技術の他の例として、図９に示すように、無線区間はWEP、WPA等の無線の暗号化方式を利用し、GW以降はTLSやIPsec等のプロトコルを利用する技術がある。当該支援技術に対応する支援技術部３３は、無線区間から受信した暗号化されたデータを復号化し、復号化したデータに対し、TLSやIPsec等のプロトコルに従って暗号化を施して送信する。また、支援技術部３３は、広域NWからTLSやIPsec等で受信したデータを復号化し、WEP、WPA等の無線の暗号化方式で暗号化して送出する。

（実施の形態のまとめ、効果）
以上、説明したように、本実施の形態では、 端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムであって、端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、セキュア通信に関する処理の支援を実施する支援手段と、前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御手段とを備える端末支援システムが提供される。

前記支援手段は、例えば複数の支援技術に対応する複数の支援機能部を有し、前記端末に対して処理の支援を実行すると判定する場合において、前記制御手段は、前記端末についての端末支援要否を示す情報に基づいて支援技術を決定し、当該支援技術に対応する支援機能部に支援の実施を指示することとしてもよい。

前記端末支援システムは、前記端末情報格納手段の中に前記端末についての端末支援要否を示す情報が存在しない場合に、当該端末との間でセキュア通信を試みることにより当該端末の性能を推定する端末性能推定手段と、前記端末性能推定手段により推定された性能に基づいて、前記端末に対する支援要否を決定する端末支援要否判定手段とを備えることとしてもよい。

前記支援手段は、例えば、前記端末の代わりに、前記セキュア通信要求の要求元との間でセキュリティプロトコルの処理を実行し、当該処理の結果を前記端末に渡すことにより、当該端末と前記セキュア通信要求の要求元との間でセキュア通信を実行させることができる。

図１０は、本実施の形態における端末支援システムの特徴的な動作を示した図である。図１０に示すように、高機能端末は、自身でセキュリティ技術を適用できるため、GWによる支援を受けることなくセキュア通信を実行する（ステップＳ１、Ｓ２）。また、低機能端末は、例えば、図３のステップＳ１２１〜Ｓ１２３に示した支援技術を適用することでセキュア通信を実行できる（ステップＳ１１〜Ｓ１３）。また、超低機能端末は、例えば、図９に示したような支援技術を適用することでセキュア通信を実行できる（ステップＳ２１〜Ｓ２３）。

このように、本実施の形態における端末支援システムによって、M2M/IoT-GWに繋がる多種多様な端末に対して、サービス事業者の要望、若しくは、端末のCPUやメモリといった性能に応じて、暗号化を実現するための支援ができる。すなわち、自身でセキュリティ技術を適用できないような低機能な端末であっても、GW側の助けを借りてセキュリティを担保することができる。また、自身でセキュリティ技術を適用できる高機能な端末は、自身でセキュリティを担保することで、GW支援によるセキュリティレベルの低下を防ぐことができ、また、不必要なGW支援によるGW負荷を発生させることがないという効果がある。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０ PF側端末情報管理機能
１１ 端末情報入力受付部
１２ PF側端末情報同期部
１３ 端末情報DB
２０ 端末支援要否判定機能
３０ 端末セキュリティ支援機能
３２ 通信プロキシ部
３３ 支援技術部
４０ GW側端末情報管理機能
４１ GW側端末情報同期部
４２ 端末情報取得部
４３ 接続端末情報DB
５０ 端末性能推定機能

Claims (8)

1. 端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムであって、
   端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、
   セキュア通信に関する処理の支援を実施する支援手段と、
   前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御手段と
   を備えることを特徴とする端末支援システム。
2. 前記支援手段は、複数の支援技術に対応する複数の支援機能部を有し、
   前記端末に対して処理の支援を実行すると判定する場合において、前記制御手段は、前記端末についての端末支援要否を示す情報に基づいて支援技術を決定し、当該支援技術に対応する支援機能部に支援の実施を指示する
   ことを特徴とする請求項１に記載の端末支援システム。
3. 前記端末情報格納手段の中に前記端末についての端末支援要否を示す情報が存在しない場合に、当該端末との間でセキュア通信を試みることにより当該端末の性能を推定する端末性能推定手段と、
   前記端末性能推定手段により推定された性能に基づいて、前記端末に対する支援要否を決定する端末支援要否判定手段と
   を備えることを特徴とする請求項１又は２に記載の端末支援システム。
4. 前記支援手段は、前記端末の代わりに、前記セキュア通信要求の要求元との間でセキュリティプロトコルの処理を実行し、当該処理の結果を前記端末に渡すことにより、当該端末と前記セキュア通信要求の要求元との間でセキュア通信を実行させる
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載の端末支援システム。
5. 端末に対してセキュア通信に関する処理の支援を実施するための端末支援システムが実行する端末支援方法であって、
   前記端末支援システムは、端末毎に端末支援要否を示す情報を格納できる端末情報格納手段と、セキュア通信に関する処理の支援を実施する支援手段とを備え、
   前記端末支援システムに接続される端末に対するセキュア通信要求を受信した場合に、前記端末情報格納手段を参照し、当該端末についての端末支援要否を示す情報を取得し、当該情報に基づいて前記端末に対して処理の支援を実行するか否かを判定し、前記端末に対して処理の支援を実行しないと判定した場合に、前記端末に前記セキュア通信要求を送信し、前記端末に対して処理の支援を実行すると判定した場合に、前記支援手段に対して支援の実施を指示する制御ステップ
   を備えることを特徴とする端末支援方法。
6. 前記支援手段は、複数の支援技術に対応する複数の支援機能部を有し、
   前記制御ステップにおいて、前記端末支援システムは、前記端末に対して処理の支援を実行すると判定する場合において、前記端末についての端末支援要否を示す情報に基づいて支援技術を決定し、当該支援技術に対応する支援機能部に支援の実施を指示する
   ことを特徴とする請求項５に記載の端末支援方法。
7. 前記端末情報格納手段の中に前記端末についての端末支援要否を示す情報が存在しない場合に、当該端末との間でセキュア通信を試みることにより当該端末の性能を推定する端末性能推定ステップと、
   前記端末性能推定ステップにより推定された性能に基づいて、前記端末に対する支援要否を決定する端末支援要否判定ステップと
   を備えることを特徴とする請求項５又は６に記載の端末支援方法。
8. 前記支援手段は、前記端末の代わりに、前記セキュア通信要求の要求元との間でセキュリティプロトコルの処理を実行し、当該処理の結果を前記端末に渡すことにより、当該端末と前記セキュア通信要求の要求元との間でセキュア通信を実行させる
   ことを特徴とする請求項５ないし７のうちいずれか１項に記載の端末支援方法。

Images