(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-10
(45)【発行日】2023-10-18
(54)【発明の名称】制御方法、デバイス及び制御システム
(51)【国際特許分類】
H04L 9/32 20060101AFI20231011BHJP
G06F 21/44 20130101ALI20231011BHJP
【FI】
H04L9/32 100B
G06F21/44
(21)【出願番号】P 2020004022
(22)【出願日】2020-01-14
【審査請求日】2022-09-08
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】中村 洋介
(72)【発明者】
【氏名】二村 和明
【審査官】中里 裕正
(56)【参考文献】
【文献】特開2019-213131(JP,A)
【文献】米国特許出願公開第2016/0337464(US,A1)
【文献】米国特許出願公開第2019/0116158(US,A1)
【文献】BOVET, G. and HENNEBERT, J.,Distributed Semantic Discovery for Web-of-Things Enabled Smart Buildings,2014 6th International Conference on New Technologies, Mobility and Security (NTMS),2014年,pp.1-5
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G06F 21/44
JSTPlus/JMEDPlus/JST7580(JDreamIII)
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
デバイスが実行する制御方法において、
前記デバイスの仕様情報を端末装置に送信した後、前記仕様情報により生成された第1のリクエストを前記端末装置から受信すると、前記第1のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第1のリクエストを実行するか否かを判定する
処理をコンピュータが実行することを特徴とするデバイスの制御方法。
【請求項2】
デバイスと端末装置とを有するシステムを制御する制御方法であって、
前記デバイスによって
前記端末装置に宛てて送信される
前記デバイスの仕様情報であって、前記端末装置によって前記デバイスに宛てて送信されるリクエストに関する情報が記述された仕様情報が前記端末装置によって受信される前に、前記仕様情報の内容を変更し、
前記仕様情報に、前記変更する処理による変更の内容を変更履歴として記述し、
前記仕様情報に記述された前記変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証
し、
前記デバイスが、前記仕様情報を端末装置に送信した後、前記仕様情報により生成された第2のリクエストを前記端末装置から受信すると、前記第2のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第2のリクエストを実行するか否かを判定する
処理をコンピュータが実行することを特徴とする制御方法。
【請求項3】
前記判定する処理は、前記第1のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記端末装置によって前記デバイスに送信されるリクエストのヘッダに記述された所定のパラメータであって、通信経路上のプロキシを特定する情報及び各プロキシにおける認証方式が少なくとも記述されたパラメータを読み取ることにより取得された前記仕様情報に定義された前記仕様情報が前記端末装置に到達するまでに経由した通信装置と、の比較結果に基づき、前記第1のリクエストを実行するか否かを判定することを特徴とする請求項1に記載のデバイスの制御方法。
【請求項4】
前記変更する処理は、前記仕様情報に含まれるタグに対応する値のうちの少なくともいずれかを変更し、
前記記述する処理は、人間が読み取り可能な情報を記述するためのタグの値に、前記変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述することを特徴とする請求項2に記載の制御方法。
【請求項5】
前記端末装置と前記デバイスとの間の通信経路上に備えられた1つ以上のプロキシが前記変更する処理を実行し、
前記記述する処理は、前記仕様情報に、前記変更する処理による変更の内容及び当該変更を行ったプロキシを特定する情報を変更履歴として記述することを特徴とする請求項2又は4に記載の制御方法。
【請求項6】
前記端末装置と前記デバイスとの間の通信経路上に備えられた第1のプロキシが、前記変更する処理及び前記記述する処理を実行し、
前記第1のプロキシが、前記記述する処理によって前記変更の内容が記述された前記仕様情報からハッシュを生成する処理をさらに実行し、
前記通信経路上に備えられた第2のプロキシが、前記生成する処理によって生成されたハッシュの正当性を検証し、検証結果を前記仕様情報に記述する処理を実行することを特徴とする請求項2、4又は5に記載の制御方法。
【請求項7】
端末装置からのリクエストを受信するデバイスであって、
前記デバイスの仕様情報を前記端末装置に送信した後、前記仕様情報により生成された第1のリクエストを前記端末装置から受信すると、前記第1のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第1のリクエストを実行するか否かを判定する判定部と、
を有することを特徴とするデバイス。
【請求項8】
端末装置と、デバイスと、前記端末装置と前記デバイスとの間の通信経路上に備えられたプロキシと、を有する制御システムであって、
前記デバイスは、
前記デバイスの仕様情報を前記端末装置に送信した後、前記仕様情報により生成された第1のリクエストを前記端末装置から受信すると、前記第1のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第1のリクエストを実行するか否かを判定する判定部と、
を有することを特徴とする制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、制御方法、デバイス及び制御システムに関する。
【背景技術】
【0002】
Web技術により全てのIoT(Internet of Things)デバイスを扱えるようにするWoT(Web of Things)という概念が、W3C(World Wide Web)により提唱されている。WoTでは、API等のプロファイルを統一形式で記述するためのTD(Thing Description)によるIoTデバイスへのアクセスが可能になる。
【0003】
また、アプリケーションとIoTデバイスが異なるネットワークに存在する場合、アプリケーションがIoTを扱えるようにするために、ネットワーク間にプロキシが設けられる場合がある。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2007-110180号公報
【文献】特開2015-58896号公報
【文献】特開2018-121328号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上記の技術では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することが困難な場合があるという問題がある。
【0006】
例えば、アプリケーションは、IoTデバイスにより発行されたTDを受け取り、当該受け取ったTDに記述された内容に従い、IoTデバイスに宛てたWebリクエストを送信する。このとき、上記のようにアプリケーションとIoTデバイスとの間にプロキシが設けられている場合、Webリクエストがプロキシに向けられるようにするためにTDを書き換えておく必要がある。そして、TDが書き換えられた場合、IoTデバイスは、プロキシを経由したWebリクエストを受け取ることになる。
【0007】
ここで、初めにIoTデバイスから発行されるTDは、Webリクエストがプロキシを経由することを想定したものではないため、IoTデバイスは、プロキシ経由で送られてきたWebリクエストが正当なものであるか否かを判断することができない場合がある。
【0008】
1つの側面では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することを目的とする。
【課題を解決するための手段】
【0009】
1つの態様において、制御方法は、コンピュータに、デバイスの仕様情報を端末装置に送信した後、仕様情報により生成されたリクエストを端末装置から受信すると、リクエストを実行するか否かを判定する処理を実行させる。制御方法は、コンピュータに、リクエストがデバイスに到達するまでに経由した通信装置と、仕様情報が端末装置に到達するまでに経由した通信装置との比較結果に基づき判定する処理を実行させる。
【発明の効果】
【0010】
1つの側面では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することができる。
【図面の簡単な説明】
【0011】
【
図1】
図1は、WoTシステムの各装置の配置例を示す図である。
【
図2】
図2は、制御システムの構成例を示すブロック図である。
【
図3】
図3は、制御システムの構成例を示すブロック図である。
【
図4】
図4は、プロトコルの変更前後のTDの例を示す図である。
【
図5】
図5は、認証方式の変更前後のTDの例を示す図である。
【
図6】
図6は、変更対象リストの一例を示す図である。
【
図7】
図7は、HTTPリクエストの一例を示す図である。
【
図8】
図8は、TDの変更処理の流れを示すフローチャートである。
【
図9】
図9は、リクエストの検証処理の流れを示すフローチャートである。
【
図10】
図10は、ハッシュ検証履歴が記述されたTDの例を示す図である。
【発明を実施するための形態】
【0012】
以下に、本発明に係る制御方法、デバイス及び制御システムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
【実施例1】
【0013】
まず、
図1を用いて、WoTを実現するためのWoTシステムについて説明する。
図1は、WoTシステムの各機能の配置例を示す図である。システムは、ローカルネットに配置されるIoTデバイス及びインターネットに配置されるWebアプリを有する。
【0014】
Webアプリは、IoTを直接扱えない場合がある。そのような場合、インターネットとローカルネットの間にあるプロキシが双方のIFの差を吸収する。具体的には、プロキシはIPアドレス及びデータ等の書き換えを行い、また、クライアント機能を有する。IoTデバイスは、プロキシ向けIFを介して、TDをプロキシに受け渡す。
【0015】
IoTデバイスが出力するTDには、API詳細として、URL in localが記載される。プロキシは、TDを書き換え、Webアプリに受け渡す。書き換えた後のTDには、API詳細として、URL in global等が記載される。また、いずれのTDにも各種の入出力パラメータが記載され得る。
【0016】
ここで、
図1に示すようなシステムにおいては、WebアプリとIoTデバイスとの間の信頼を確保するためには、例えば以下の4つの検知又は検証が行われる必要がある。すなわち、(1)Webアプリとプロキシ間でのTDの不正書き換えの検知、(2)プロキシにおけるTD書き換えの正当性の検証、(3)書き換え以前のTDの正当性の検証、(4)Webアクセスの信頼性の検証である。
【0017】
1つの側面では、本実施例は上記の検知及び検証を行うことを目的とするものである。特に、本実施例によれば、従来の技術では困難であった上記の(2)と(4)の検証を行うことができる。
【0018】
[機能構成]
図2及び
図3を用いて、実施例に係る制御システム1の構成を説明する。
図2及び
図3は、制御システムの構成例を示すブロック図である。
図2及び
図3に示すように、制御システム1は、デバイス10、プロキシ20及び端末装置30を有する。
【0019】
デバイス10は、例えば自動車、家電、ウェアラブル装置、センサ等のIoTデバイスである。プロキシ20は、例えばプロキシ機能を備えたサーバである。端末装置30は、Webアプリのクライアントとして機能する端末である。また、端末装置30は、Webアプリを提供するサーバであってもよい。なお、制御システム1の各装置は、
図1で示したシステムの各装置と同様の機能を有するものとする。
【0020】
図2は、デバイス10が端末装置30にTDを送信する際に使用される各装置の機能を処理部として表している。一方、
図3は、端末装置30がデバイス10に対しWebアクセスをする際に使用される各装置の機能を処理部として表している。
【0021】
(TDの送信)
まず、デバイス10がTDを送信する際に使用される各処理部について説明する。
図2に示すように、プロキシ20は、ハッシュ検証部201、検証履歴記述部202、変更部203、変更履歴記述部204、生成部205及び変更対象リスト206を有する。また、端末装置30は、TD取得部301、ハッシュ検証部302、検証履歴検証部303、変更対象取得部304及び変更履歴検証部305を有する。
【0022】
デバイス10は、TD501を端末装置30に宛てて送信する。デバイス10は、任意のタイミングでTDを送信することができる。例えば、デバイス10は、デバイス10がネットワークに追加された際に自動的にTDを送信してもよいし、手動で操作されることによりTDを送信してもよいし、端末装置30やプロキシ20等の他の装置からの要求に応じてTDを送信してもよい。このとき、TD501は、デバイス10と端末装置30との間の通信経路上にあるプロキシ20によって受信される。ハッシュ検証部201は、デバイス10によって送信されたTD501のハッシュを検証する。検証履歴記述部202は、ハッシュ検証部201によってTD501が正当なものであると検証された場合、検証履歴をTD501に記述する。
【0023】
変更部203は、TD501が端末装置30によって受信される前に、TD501の内容を変更する。また、変更履歴記述部204は、TD501に、変更する処理による変更の内容を変更履歴として記述する。TD502は、変更履歴記述部204によってTD501に変更履歴が記述されたものである。なお、TDは仕様情報の一例である。また、TD501は、デバイス10によって端末装置30に宛てて送信されるTDであって、端末装置30によってデバイス10に宛てて送信されるリクエストに関する情報が記述されたTDである。なお、リクエストには、HTTPリクエスト等のWebリクエストが含まれる。
【0024】
例えば、プロキシ20がWebsocketに非対応であって、HTTPに対応している場合、変更部203は、TD501に記述されたAPIのプロトコルをWebsocketからHTTPに書き換えることができる。その際、変更履歴記述部204は、プロトコルが書き換えられたことを変更履歴としてTD501に記述する。
【0025】
図4は、プロトコルの変更前後のTDの例を示す図である。TD501は、プロキシ20によって受信された時点のTDである。TD502は、検証履歴記述部202による検証履歴の記述、変更部203による内容の変更、及び変更履歴記述部204による変更履歴の記述が行われた後のTDである。
【0026】
ここで、TDに含まれるdescriptionタグの値は、オブジェクトを要素とする配列である。また、オブジェクトは、1つ以上の"key":"value"の組を持つものとする。また、descriptionタグは、Human Readable情報、すなわち人間が読み取り可能な情報を記述するためのタグの一例である。
【0027】
検証履歴記述部202は、descriptionタグの配列の第1要素に、TD提供元を示すオブジェクト、及びハッシュ確認者を示すオブジェクトを記述する。ハッシュ確認者は、ハッシュ確認を行った主体であり、プロキシ等の装置である。
【0028】
図4のTD502の「"source":"sensor1"」は、TD提供元を示すオブジェクトである。当該オブジェクトは、TD提供元、すなわち「source」が「sensor1」であることを示している。なお、「sensor1」はデバイス10を識別するための文字列である。
【0029】
図4のTD502の「"checker":"Lproxy"」は、ハッシュ確認者を示すオブジェクトである。当該オブジェクトは、ハッシュ確認者、すなわち「checker」が「Lproxy」であることを示している。なお、「Lproxy」はプロキシ20を識別するための文字列である。なお、TDに検証履歴が記述されていることは、正当性が検証されたことを示している。このため、検証履歴記述部202は、正当であったか否かを明示的に記述する必要はない。
【0030】
変更部203は、hrefタグの値を変更することで、プロトコルを書き換える。
図4に示すように、変更部203は、hrefタグの値を「ws://xxx/get_temp」から「http://xxx/get_temp」に書き換える。
【0031】
変更履歴記述部204は、descriptionタグの配列の第2要素に、TDの変更を行った変更者を示すオブジェクト、変更前の情報を示すオブジェクト、及び変更後の情報を示すオブジェクトを記述する。TDの変更を行った変更者は、TDの変更を行った主体であり、プロキシ等の装置である。
【0032】
図4のTD502の「"place":"Rproxy"」は、TDの変更を行った変更者を示すオブジェクトである。当該オブジェクトは、変更者、すなわち「place」が「Rproxy」であることを示している。なお、「Rproxy」はプロキシ20を識別するための文字列である。
【0033】
図4のTD502の「"orig-p":"websocket"」は、変更前の情報を示すオブジェクトである。当該オブジェクトは、変更前のプロキシ、すなわち「orig-p」が「websocket」であることを示している。
【0034】
図4のTD502の「"modify-p":"http"」は、変更後の情報を示すオブジェクトである。当該オブジェクトは、変更後のプロキシ、すなわち「modify-p」が「http」であることを示している。
【0035】
このように、変更履歴記述部204は、人間が読み取り可能な情報を記述するためのタグの値に、変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述する。
【0036】
変更部203は、TDに含まれるタグに対応する値のうちの少なくともいずれかを変更することができる。変更部203が値を変更するタグは、hrefタグに限られない。例えば、変更部203は、認証方式を表すsecurityタグの値を変更してもよい。
【0037】
図5は、認証方式の変更前後のTDの例を示す図である。
図5の例では、変更部203は、securityタグの値を「{"schema":"nosec"}」から「{"schema":"basic"}」に書き換える。TD502aは、検証履歴記述部202による検証履歴の記述、変更部203による内容の変更、及び変更履歴記述部204による変更履歴の記述が行われた後のTDである。
【0038】
図5のTD502aの「"place":"Rproxy"」は、TDの変更を行った変更者を示すオブジェクトである。当該オブジェクトは、変更者、すなわち「place」が「Rproxy」であることを示している。
【0039】
図5のTD502aの「"orig-p":"nosec"」は、変更前の情報を示すオブジェクトである。当該オブジェクトは、変更前の認証方法、すなわち「orig-p」が「nosec」であることを示している。
【0040】
図5のTD502aの「"modify-p":"basic"」は、変更後の情報を示すオブジェクトである。当該オブジェクトは、変更後の認証方法、すなわち「modify-p」が「basic」であることを示している。
【0041】
図2に戻り、生成部205は、変更履歴記述部204によって変更履歴が記述されたTD502のハッシュを生成する。プロキシ20は、TD502をハッシュとともに端末装置30に送信する。
【0042】
端末装置30のTD取得部301は、TD502を取得する。ハッシュ検証部302は、デバイス10によって送信されたTD502のハッシュを検証する。また、検証履歴検証部303は、プロキシ等で行われたハッシュの検証の正当性を検証する。検証履歴検証部303は、TD502のハッシュ検証履歴を基に、プロキシ20によって行われたハッシュ検証の正当性を検証する。
【0043】
変更履歴検証部305は、TDに記述された変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証する。変更対象取得部304は、プロキシ20から変更対象リスト206を取得する。変更対象リスト206は、変更が許可されているタグ及び変更の内容を規定した情報である。変更対象リスト206は、プロキシ20ではなく、端末装置30又は他の装置によって保持されていてもよい。
【0044】
図6は、変更対象リストの一例を示す図である。
図6に示すように、変更対象リスト206には、値の変更が許可されたタグの名称が少なくとも含まれ、変更の内容がさらに含まれていてもよい。「{"tag":"href"}」は、hrefタグの値の変更が許可されていることを示している。また、「{"tag":"href","rewrite":"http"}」は、hrefタグによって示されるプロトコルを「http」に変更することが許可されていることを示している。
【0045】
(Webアクセス)
次に、端末装置30がデバイス10に対してWebアクセスをする際に使用される各処理部について説明する。
図3に示すように、デバイス10は、TD取得部151、判定部152、提供部153及び認証部154を有する。また、プロキシ20は、要求部251、経路情報記述部252、再構成部253、提供部254及び認証部255を有する。また、端末装置30は、要求部351を有する。
【0046】
まず、端末装置30の要求部351は、デバイス10に宛ててリスエストを送信する。プロキシ20の提供部254は、Webサーバとして機能する。つまり、提供部254は、要求部351によって送信されたリクエストを受信する。また、認証部255は、提供部254が受信したリクエストの認証を行う。再構成部253は、URLの変換等によりリクエストを再構成する。
【0047】
ここで、経路情報記述部252は、経路に関する情報をリクエストに記述する。
図7に示すように、経路情報記述部252は、HTTPリクエストに情報を記述する。
図7は、HTTPリクエストの一例を示す図である。
【0048】
経路情報記述部252は、情報を記述するための独自パラメータをリクエストに追加する。このとき、経路情報記述部252は、HTTPリクエストのヘッダにパラメータを入れる場合の慣例に従い、「X-」から始まるキーを設定する。
図7に示すように、経路情報記述部252は、キーが「X-Auth-History」であるパラメータをHTTPリクエストのヘッダに追加する。
【0049】
経路情報記述部252は、例えば認証場所及び認証方式を記述する。
図7のパラメータ「X-Auth-History」のオブジェクトのうち「{"place":"Rproxy","method":"basic"}」は、認証場所が「Rproxy」であり、認証方式が「basic」であることを示している。また、HTTPリクエストが複数のプロキシを経由した場合、経路情報記述部252は、パラメータ「X-Auth-History」にさらにオブジェクトを追加する。「{"place":"Lproxy","method":"nosec"}」は、認証場所が「Lproxy」であり、認証方式が「nosec」であることを示している。なお、「nosec」は、認証がないことを示している。
【0050】
要求部251は、クライアントとして機能する。つまり、要求部251は、再構成部253によって再構成され、経路情報記述部252によって記述が行われたリクエストをデバイス10に送信する。
【0051】
デバイス10の提供部153は、Webサーバとして機能する。つまり、提供部153は、プロキシ20の要求部251によって送信されたリクエストを受信する。また、認証部154は、提供部153が受信したリクエストの認証を行う。
【0052】
TD取得部151は、端末装置30によってデバイス10に宛てて送信されるリクエストの通信経路をあらかじめ定義したTDを取得する。ここで、TD取得部151が取得するTDは、端末装置30が取得したTDと同じものである。つまり、TD取得部151は、TD502をプロキシ20を取得する。
【0053】
TD取得部151は、端末装置30によってデバイス10に送信されるリクエストのヘッダに記述された所定のパラメータを読み取ることによりTDを取得する。例えば、
図7に示すように、HTTPリクエストには、通信経路上のプロキシ20を特定する情報である「place」及び各プロキシ20における認証方式である「method」が少なくとも記述されている。TD取得部151は、HTTPリクエストから読み取った情報を基にプロキシ20に接続し、TD502を取得する。
【0054】
判定部152は、デバイス10のTDを端末装置30に送信した後、TDにより生成されたリクエストを端末装置30から受信すると、リクエストを実行するか否かを判定する。判定部152は、リクエストがデバイス10に到達するまでに経由した通信装置と、TDが端末装置30に到達するまでに経由した通信装置との比較結果に基づき判定する。TDは、TD取得部151によって取得される。リクエストは、プロキシ20によって送信され、提供部153によって受信される。
【0055】
図7に示すように、HTTPリクエストには、「Lproxy」を少なくとも経由したことが示されている。また、
図4に示すように、TD502にも、「Lproxy」を少なくとも経由したことが示されている。この場合、判定部152は、通信経路上の少なくとも一部のプロキシが一致しているため、リクエストを実行すると判定する。
【0056】
判定部152は、第1のリクエストが経由した通信経路と、TD取得部151によって取得されたTDによって定義された通信経路との少なくとも一部が一致する場合にリクエストを実行すると判定してもよい。また、判定部152は、第1のリクエストが経由した通信経路と、TD取得部151によって取得されたTDによって定義された通信経路とが完全一致する場合にリクエストを実行すると判定してもよい。
【0057】
[処理の流れ]
図8を用いて、TDの送信時におけるTDの変更処理の流れを説明する。
図8は、TDの変更処理の流れを示すフローチャートである。まず、デバイス10はTDのハッシュを生成する(ステップS101)。次に、プロキシ20がTDを取得する(ステップS102)。そして、プロキシ20はハッシュを検証する(ステップS103)。ここで、プロキシ20は、ハッシュ検証履歴をTDに付与する(ステップS104)。
【0058】
プロキシ20は、TDを書き換える(ステップS105)。例えば、プロキシ20は、プロトコル及び認証方式等を書き換える。そして、プロキシ20は、変更履歴をTDに記述する(ステップS106)。さらに、プロキシ20は、書き換え及び変更履歴の記述が行われたTDのハッシュを生成する(ステップS107)。
【0059】
端末装置30、すなわちアプリは、プロキシ20からTDを取得する(ステップS108)。ここで、端末装置30は、取得したTDのハッシュを検証する(ステップS109)。さらに、端末装置30は、ハッシュ履歴を検証する(ステップS110)。そして、端末装置30は、変更対象リストを取得(ステップS111)し、変更履歴と変更対象リストの一致を確認する(ステップS112)。
【0060】
図9を用いて、Webアクセス時におけるリクエストの検証処理を説明する。
図9は、リクエストの検証処理の流れを示すフローチャートである。まず、端末装置30、すなわちアプリがプロキシ20へWebリクエストを送信する(ステップS201)。
【0061】
プロキシ20は、リクエストを受信し(ステップS202)、認証を行う(ステップS203)。さらに、プロキシ20は、URL変換等によりリクエストを再構成する(ステップS204)。
【0062】
そして、プロキシ20は、プロキシID、認証情報を経路履歴としてリクエストに付加する(ステップS205)。プロキシ20は、デバイス10へリクエストを送信する(ステップS206)。
【0063】
デバイス10は、リクエストを受信し(ステップS207)、認証を行う(ステップS208)。ここで、デバイス10は、プロキシ20からアプリが取得したTDを取得する(ステップS209)。そして、デバイス10は、取得したTDのハッシュ履歴及び変更履歴と、リクエストに記述された経路履歴とを比較し一致を確認する(ステップS210)。
【0064】
[効果]
判定部152は、デバイス10のTDを端末装置30に送信した後、仕様情報により生成されたリクエストを端末装置30から受信すると、リクエストを実行するか否かを判定する。判定部152は、リクエストがデバイス10に到達するまでに経由した通信装置と、TDが端末装置30に到達するまでに経由した通信装置との比較結果に基づき判定する。このように、IoTデバイスであるデバイス10は、アプリケーションを実行する端末装置30によって送信されるリクエストの実際の通信経路と書き換え済みのTDに基づく通信経路とを比較する。この結果、実施例1によれば、アプリケーションからIoTデバイスへのアクセスの正当性を検証することができる。つまり、実施例1によれば、Webアクセスの信頼性の検証が可能になる。
【0065】
変更部203は、デバイス10によって端末装置30に宛てて送信されるTDであって、端末装置30によってデバイス10に宛てて送信されるリクエストに関する情報が記述されたTDが端末装置30によって受信される前に、TDの内容を変更する。変更履歴記述部204は、TDに、変更する処理による変更の内容を変更履歴として記述する。変更履歴検証部305は、TDに記述された変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証する。このように、端末装置30は、TD自体の記述内容を基にTDの正当性を検証することができる。この結果、実施例1によれば、プロキシにおけるTD書き換えの正当性の検証が可能になる。
【0066】
判定部152は、リクエストがデバイス10に到達するまでに経由した通信装置と、パラメータを読み取ることにより取得したTDに定義された、TDが端末装置30に到達するまでに経由した通信装置と、の比較結果に基づきリクエストを実行するか否かを判定する。パラメータは、端末装置30によってデバイス10に送信されるリクエストのヘッダに記述されたものである。パラメータには、所定の通信経路上のプロキシを特定する情報及び各プロキシにおける認証方式が少なくとも記述されている。これにより、デバイス10は、プロキシ20に接続し、TDを取得することができる。
【0067】
変更部203は、TDに含まれるタグに対応する値のうちの少なくともいずれかを変更する。変更履歴記述部204は、人間が読み取り可能な情報を記述するためのタグの値に、変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述する。このように、プロキシ20は、例えばdescriptionタグの値に情報を記述する。この結果、実施例1によれば、既存のTDのフォーマットを変更することなく、検証のための情報を追記することが可能になる。
【0068】
なお、上述の例では、デバイス10と端末装置30との間のプロキシは1つであった。一方で、デバイス10と端末装置30との間のプロキシは1つであっても複数であってもよい。つまり、端末装置30とデバイス10との間の通信経路上に備えられた1つ以上のプロキシ20が変更する処理を実行する。そして、各プロキシの変更履歴記述部204は、TDに、変更する処理による変更の内容及び当該変更を行ったプロキシを特定する情報を変更履歴として記述する。
【0069】
ここで、一例として、デバイス10と端末装置30との間に第1のプロキシと第2のプロキシが存在する場合のTDの変更処理について説明する。端末装置30とデバイス10との間の通信経路上に備えられた第1のプロキシが、変更する処理及び記述する。さらに、第1のプロキシが、記述する処理によって変更の内容が記述されたTDからハッシュを生成する処理をさらに実行する。そして、通信経路上に備えられた第2のプロキシが、第1のプロキシによって生成されたハッシュの正当性を検証し、さらに検証結果をTDに記述する。
【0070】
図10は、ハッシュ検証履歴が記述されたTDの例を示す図である。この場合、各プロキシは、Key値にナンバリングして区別をつける。例えば、第1のプロキシはKey値として「source」及び「checker」を使う。そして、第2のプロキシはKey値として「source2」及び「checker2」を使う。
【0071】
[システム]
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値等は、あくまで一例であり、任意に変更することができる。
【0072】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、CPU及び当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0073】
[ハードウェア]
図11は、ハードウェア構成例を説明する図である。
図11に示すように、デバイス10は、通信インタフェース10a、HDD(Hard Disk Drive)10b、メモリ10c、プロセッサ10dを有する。また、
図11に示した各部は、バス等で相互に接続される。また、プロキシ20及び端末装置30も同様に、
図11に示すようなハードウェア構成を有していてもよい。
【0074】
通信インタフェース10aは、ネットワークインタフェースカード等であり、他のサーバとの通信を行う。HDD10bは、
図3に示した機能を動作させるプログラムやDBを記憶する。
【0075】
プロセッサ10dは、
図3に示した各処理部と同様の処理を実行するプログラムをHDD10b等から読み出してメモリ10cに展開することで、
図3等で説明した各機能を実行するプロセスを動作させるハードウェア回路である。すなわち、このプロセスは、デバイス10が有する各処理部と同様の機能を実行する。具体的には、プロセッサ10dは、TD取得部151、判定部152、提供部153及び認証部154と同様の機能を有するプログラムをHDD10b等から読み出す。そして、プロセッサ10dは、TD取得部151、判定部152、提供部153及び認証部154等と同様の処理を実行するプロセスを実行する。
【0076】
このようにデバイス10は、プログラムを読み出して実行することで学習類方法を実行する情報処理装置として動作する。また、デバイス10は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、デバイス10によって実行されることに限定されるものではない。例えば、他のコンピュータ又はサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【0077】
このプログラムは、インターネット等のネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD-ROM、MO(Magneto-Optical disk)、DVD(Digital Versatile Disc)等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【符号の説明】
【0078】
1 制御システム
10 デバイス
20 プロキシ
30 端末装置
151 TD取得部
152 判定部
153 提供部
154 認証部
201 ハッシュ検証部
202 検証履歴記述部
203 変更部
204 変更履歴記述部
205 生成部
206 変更対象リスト
251 要求部
252 経路情報記述部
253 再構成部
254 提供部
255 認証部
301 TD取得部
302 ハッシュ検証部
303 検証履歴検証部
304 変更対象取得部
305 変更履歴検証部
351 要求部
501、502、502a TD